1190887507 p is

prof. dr ing poliuk e. jaroslav

projektovanje

informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2

Prof. dr ing Poliuk E. Jaroslav PROJEKTOVANJE INFORMACIONIH SISTEMA

Kompjuterska obrada knjige: autor E-mail: [email protected]

Sva prava zadrava autor.


3

PREDGOVOR

"Klasina predstava o svemiru, koji se sastoji od materije i energije, mora da ustupi mjesto predstavi o svijetu sastavljenom od tri komponente: energije, materije i informacija, jer bez informacija organizovani sistemi nisu mogui. Jedino mogue materijalistiko tumaenje odravanja organizovanosti je neprekidno izvlaenje iz spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju" [A. Lerner, 2003].

Predvianje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA, vodea u svijetu u analizi kretanja u oblasti globalne industrije informatike tehnologije, glasi: Trend automatizacije informatikih tehnologija e imati veliki uticaj na razvoj softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehniku podrku i umreavanje. Neka informatika zaduenja e biti vea, neka e biti umanjena, neka prebaena u druge dijelove kompanije, a neka e biti ukinuta".

Specijalizovani informatiki radnici, koji se istiu samo svojim poznavanjem informatikih tehnologija i vjetinama vezanim za raunare, bez posjedovanja drugih funkcionalnih znanja, bie manje potrebni, predviaju Gartner-ovi analitiari. Prosjeno informatiko odijeljenje u srednjim i velikim kompanijama e do 2010. godine biti za trideset procenata manje, tvrde analitiari trita kompanije Gartner, i zakljuuju: Informatiki radnici budunosti e biti zaposleni u jednom od etiri glavna podruja: tehnolokoj infrastrukturi, projektovanju i upravljanju informatikim sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima.

Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, raena na osnovu dostupne literature i obrauje savremeni pristup projektovanju IS. Izvori, na osnovu kojih je nastala ova knjiga, jednim dijelom su navedeni u samom tekstu knjige, dok je cjelovit pregled dan u okviru pregleda koritene literature. Zahvaljujem se autorima iji su manji dijelovi radova, u djelimino izmijenjenom obliku, uli u sastav ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglaeno, taj propust e rado biti naknadno otklonjen. U pojedinim sluajevima bilo je nemogue razgraniiti autorstvo pojedinih tekstova, jer se isti ili slian tekst mogao nai u razliitim izvorima.

Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalistikog studija Elektrotehnikog fakulteta u Podgorici i moe posluiti kao potrebna literatura.


4

Knjiga moe korisno posluiti projektantima IS, kao i svima koji se bave razvojem savremenih IS ili ele da se detaljnije upoznaju sa ovom oblasti.

U Podgorici, septembar 2007. god. Autor


5

SADRAJ 1. Opte o informacionim sistemima ........................................................... 9

1.1. Uvod ...................................................................................................... 9 1.2. Pojam informacionog sistema................................................................ 11 1.3. Elementi i osobine sistema i informacionih sistema .............................. 13 1.4. Vrste informacionih sistema .................................................................. 15 1.5. ivotni ciklus razvoja sistema ................................................................ 16 1.6. Kompleksnost razvoja informacionog sistema ...................................... 18

2. Planiranje razvoja informacionog sistema .............................................. 21 2.1. Modaliteti razvoja informacionog sistema ............................................. 21 2.2. Analiza izvodljivosti, trokova i koristi projekta ...................................... 27 2.3. Strategija i planiranje razvoja informacionog sistema ............................ 30 2.4. Modeli razvoja informacionih sistema .................................................... 38 2.5. Metodologija razvoja informacionih sistema .......................................... 48 2.6. Savremeni postupci razvoja informacionog sistema .............................. 51

3. Uvod u projektovanje i definisanje zahtjeva za informacionim sistemom ........................................................................... 57

3.1. Uvod u projektovanje i izgradnju informacionog sistema ....................... 57 3.2. Definisanje zahtjeva za informacionim sistemom ................................... 60

4. Analiza sistema ........................................................................................... 67 4.1. Uvod u analizu sistema .......................................................................... 67 4.2. Aktivnosti analize ................................................................................... 67 4.3. Definisanje zahtjeva koje sistem mora posjedovati ............................... 69

5. Modeliranje funkcija i procesa .................................................................. 77 5.1. Uvod u modeliranje funkcija i procesa ................................................... 77 5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnolokih procesa ................................................... 83 5.3. Modeliranje toka podataka ..................................................................... 89 5.4. Elementarni procesi ............................................................................... 98


6

6. Modeliranje podataka ............................................................................... 101 6.1. Osnovni pojmovi modela podataka ...................................................... 101 6.2. Razvoj modela podataka ..................................................................... 111 6.3. Logiko modeliranje podataka ............................................................. 116

7. Modeliranje dogaaja ................................................................................. 123 7.1. Modeliranje procesa voeno dogaajima .............................................. 123 7.2. Matrica entiteti/dogaaji ......................................................................... 124 7.3. Model istorije ivota entiteta .................................................................. 128 7.4. Dijagram prelaza stanja ............................................ 129 7.5. Mape dijaloga .. 130

8. Inenjerski pristup izgradnji IS ................................................................. 132 8.1. Uvod ...................................................................................................... 132 8.2. Programsko inenjerstvo ....................................................................... 133 8.3. Informaciono inenjerstvo ..................................................................... 134 8.4. Sistemsko inenjerstvo ......................................................................... 135 8.5. CASE proizvodi ..................................................................................... 136 8.6. Reverzno inenjerstvo ........................................................................... 148

9. Oblikovanje i arhitektura informacionog sistema .................................. 151 9.1. Oblikovanje (dizajn) sistema ............................................................... 151 9.2. Arhitektura informacionog sistema ..................................................... 153

10. Dizajn baza podataka ................................................................................ 162 10.1. Uvod u dizajn baza podataka ............................................................. 162 10.2. Normalizacija ...................................................................................... 163 10.3. Denormalizacija .................................................................................. 164 10.4. Ugradnja pravila za ouvanje integriteta ............................................ 165 10.5. Podeavanje baze podataka .............................................................. 166 10.6. Trigeri u relacionim bazama podataka ............................................... 168 10.7. Implementaciono projektovanje, generisanje i programiranje BP pomou CASE alata ............................................... 176 10.8. ifarski sistem .................................................................................... 180

10.9. Rjenik podataka katalog ................................................................ 181

11. Dizajn programske podrke ..................................................................... 186 11.1. Specifikacija i dizajn programske podrke ......................................... 186 11.2. Pristup oblikovanju programa ............................................................. 186 11.3. Strukturirani dizajn ............................................................................. 187 11.4. Dizajn interfejsa .................................................................................. 191 11.5. Ulanavanje procedura .................................................................... 194 11.6. Organizacija modula i aplikacija ........................................................ 195 11.7. Standardizacija i modularnost programske podrke ....................... 196


7

12. Implementacija informacionog sistema .................................................. 201 12.1. Izrada sistema .................................................................................... 201 12.2. Programiranje (kodiranje) .................................................................... 201 12.3. Pristup programiranju ......................................................................... 202

12.4. Programski standardi i preporuke ...................................................... 204 12.5. Provjera ispravnosti informacionog sistema ....................................... 209 12.6. Izrada dokumentacije ......................................................................... 211

13. Logiko projektovanje programa i programski jezici ............................. 213 13.1. Dijagram toka (blok dijagram, algoritam) ............................................ 213 13.2. Strukturirani prirodni jezik (pseudokod) .............................................. 216 13.3. Akcioni dijagram ................................................................................. 221 13.4. Stablo odluivanja .............................................................................. 222 13.5. Tabele odluivanja .............................................................................. 224 13.6. Struktogram ........................................................................................ 225 13.7. Programski jezici ................................................................................ 226

14. Organizacija i upravljanje projektom ....................................................... 233 14.1. Generiki modeli organizacije ............................................................ 233 14.2. Organizacija i timski rad ..................................................................... 233 14.3. Modeli timova ..................................................................................... 234 14.4. Organizacija velikih projekata ............................................................ 235 14.5. Upravljanje projektom ........................................................................ 236 14.6. Planiranje projekata ........................................................................... 236 14.7. Tehnike za vremensko planiranje ...................................................... 237 14.8. Izrada plana ....................................................................................... 238 14.9. Prikaz plana ....................................................................................... 239 14.10. Raspodjela zadataka ....................................................................... 240 14.11. Evidencija projekta .......................................................................... 241 14.12. Praenje napretka (izvrenja) projekta ............................................ 242 14.13. Preporuke za planiranje poslova ..................................................... 243

15. Primjena i odravanje informacionog sistema ....................................... 245 15.1. Uvoenje sistema u primjenu ............................................................. 245 15.2. Obuka korisnika IS ............................................................................. 246 15.3. Odravanje informacionog sistema .................................................... 246 15.4. Poboljanje sistema i reinenjerstvo .................................................. 247 15.5. Elementi konfiguracije ........................................................................ 248

Literatura .......................................................................................................... 251


8


9

1. Opte o informacionim sistemima

1.1. Uvod

Projektovanje informacionih sistema (IS) je kompleksna kreativna djelatnost koja zahtijeva sistemski pristup, metodologiju primjerenu tehnolokim mogunostima. Za organizaciju koja modernizuje IS, i prati dostignua u tehnologiji i metodologiji projektovanja, nije svrsishodno teiti za standardom koji bi vrsto definisao pristup, metodu, sredstva i dokumentaciju, ne uzimajui u obzir vrstu primjene, stepen razvoja IS, karakteristike korisnika i osobine realnog sistema u kome IS djeluje.

Brzi tehnoloki razvoj zahtjeva da se dugorono zna ta se hoe. Neophodno je imati strategijsku sliku razvoja IS, koja e obezbjediti kompatibilnost sistema i biti fleksibilna u prihvatanju nove tehnologije. Totalno integrisani IS je nedostian i nepotreban. Ono to je potrebno je dovoljno slobode kako bi korisnici mogli da razvijaju svoju inicijativu u kreiranju sistema koji im je potreban. Pri tome je potrebno potovanje pravila koja e omoguiti da razmjenjuju podatke, ta podrazumjeva zajedniku mreu za prenos, zajedniki model podataka i njihov standardni oblik.

U prolosti je razvoj programskih proizvoda bio oslonjen na razliite tipove alata za programiranje. U prvoj fazi razvoja u upotrebi su bili mainski jezici (jezici 1. generacije), ija je itljivost bila veoma mala i koji su zavisili od hardvera. U drugoj fazi se koriste asembleri (jezici 2. generacije), koji su, takoe, bili zavisni od hardvera i teko itljivi. Poslije jezika 1. i 2. generacije, u treoj fazi, u upotrebu su uli jezici 3. generacije (3rd generation languages (3GL)). Jezici 3. generacije su, kao i mainski jezici i asembleri, proceduralno orijentisani. Sa jezicima 3GL, u upotrebu je ula i tehnika strukturiranog programiranja. Bitna karakteristika 3GL je njihova nezavisnost od hardvera.

Osnovna prednost uvoenja u upotrebu jezika 3. generacije je bilo poveanje produktivnosti programiranja, odnosno poveanje kvaliteta i brzine realizacije programskih proizvoda. Sa druge strane, poveanje produktivnosti je uzrokovalo smanjenje performansi (brzine rada) tadanjih programskih proizvoda i funkcionalnosti (irine primjene) 3GL. Problem smanjenja performansi je rjeavan uvoenjem u upotrebu sve monijeg hardvera, a problem smanjene funkcionalnosti je rjeavan


10

tehnikom povezivanja programa, pisanih pomou 3GL, sa asemblerskim programima, ili daljim poveanjem mogunosti samih 3GL.

Meutim, oekivanja da e programski proizvodi, koji su razvijeni upotrebom 3GL,

pratiti potrebe krajnjih korisnika i mogunosti hardvera se ve 70-ih godina nisu ostvarila, to je dovelo do fenomena nazvanog softverska kriza. Osnovni pojavni oblik softverske krize je bio u tome da oekivani efekti od razvoja programskih proizvoda brzo izostaju, bez obzira na znatno poveanje ulaganja u ovu djelatnost, to je ilustrovano dijagramom na slici 1.1. Identifikovani su slijedei problemi kroz koje se softverska kriza prelamala. Programiranje upotrebom 3GL je bilo neefikasno i dugotrajno. Najvei dio programerskog vremena je odlazio na odravanje postojeih programskih proizvoda, to je blokiralo dalji razvoj IS.

Tvrdnja da je najvei dio programerskog vremena odlazio na odravanje postojeih programskih proizvoda se moe potkrijepiti slijedeim statistikim podacima. Prema tim podacima 64% greaka pri razvoju IS se pravilo u toku analize korisnikih zahtjeva i projektovanja IS, dok se preostalih 36% greaka pojavljivalo tokom realizacije IS. Od pomenutih 64% ranih greaka, svega 30% je otklonjeno prije isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje greaka iz poetnih faza razvoja programskih proizvoda dovodi do eksponencijalnog rasta trokova uvoenja u upotrebu i odravanje proizvoda. Tako, na primjer, otklanjanje strateke greke u fazi odravanja kota 100 puta vie nego kad se greka otkrije na poetku rada na projektu. Ovo je dovelo do jedne neprirodne raspodjele finansijskih sredstava, uloenih u razvoj IS, prema kojoj preko 70% ukupnih sredstava uloenih u razvoj IS odlazi na njegovo odravanje [Mogin et al. 2000].

Slika 1.1. Grafiki prikaz fenomena softverska kriza. Poveanje cijene odravanja i neefikasno programiranje su doveli do velikih zakanjenja u realizaciji projekata IS. Prema nekim podacima, veliki projekti u SAD su

Oekivani efekti ulaganja

Ulaganje u softver, hardver, ljudske resurse i razvoj programskog proizvoda


11

1985. godine kasnili od 30 do 45 mjeseci. U skladu sa navedenim injenicama, vremenom su identifikovani slijedei uzroci softverske krize:

1. Projektovanje IS bez primjene odgovarajue metodologije dovodi do loeg projekta, pojave velikog broja greaka i prekoraenja zadanih vremenskih rokova zavretka projekta;

2. Nedostatak softverskih alata, koji bi podrali projektovanje IS ili automatizovali postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo, takoe, vodi ka nekvalitetnom projektu uslijed oteanog rukovoenja projektom, fragmentiranog i nekonzistentnog dokumentovanja i neusaglaenosti dijelova projekta IS;

3. Nedostatak odgovarajuih softverskih alata za razvoj aplikacija IS, to vodi ka neefikasnoj realizaciji i odravanju IS.

Svi ovi uzroci su doveli do prethodno opisanih posljedica. Rjeenje softverske krize je, prema tome, trebalo traiti u otklanjanju navedena tri uzroka. To je vodilo ka formalizaciji metodologija i tehnika projektovanja IS i pojavi CASE proizvoda i jezika 4. generacije (4th generation languages (4GL)), kao podrke odgovarajuim tehnikama i metodologijama.

1.2. Pojam informacionog sistema

Metodologija razvoja informacionih sistema (IS) treba da bude opta, primjenljiva na sisteme bilo koje vrste, odnosno na neki "opti sistem". Zahtjeva da se precizno definie ta se pod pojmom IS podrazumjeva, koje su njegove funkcije i kakav je njegov poloaj u sistemu u kome djeluje. Iz tih razloga je potrebno poi od slijedeih optih pojmova i definicija.

Sistem je skup objekata i njihovih veza (medjusobno povezanih objekata). Objekti u sistemu se opisuju preko svojih svojstava koja se nazivaju atributima.

Objekti nekog sistema su povezani sa objektima van njegovih granica, a ovi sa nekim drugim "daljim" i tako dalje. Granice sistema definiu skup objekata koji e se u tom sistemu posmatrati. Zato je neophodno odrediti granice sistema koje izoluju objekte od interesa od "okoline" sistema. Dejstvo okoline na sistem naziva se "ulaz", a dejstvo sistema na okolinu "izlaz" sistema. Sistem na slici 1.2 moe predstavljati poslovni sistem, mreu puteva ili ulica, sistem za prenos elektrine energije, cirkulaciju


12

dokumenata unutar nekog poslovnog sistema, kretanje materijala koji se obrauje, itd. Objekti u sistemu mogu biti veoma razliiti, a veze izmedju objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri naina: razmjenom materije, energije ili informacija.

Slika 1.2. Opti prikaz sistema.

Rije informacija, u svakodnevnom govoru, ima smisao obavjetavanja, objanjenja, prenoenja znanja. Za pojam informacije uobiajene su slijedee definicije:

"Informacija je kapacitet poveanja znanja" [I. Wilson, 1975]; "Informacija je neto to ukida ili smanjuje neodreenost" [N. Winer, 1979].

Iz ugla upravljanja i donoenja odluka, informacija se moe razmatrati kao svaka vrsta znanja ili poruka koja moe da se upotrijebi za poboljanje upravljanja u nekom sistemu. Ako se poveu definicije pojmova sistema i informacije, moe se izvesti slijedea opta definicija informacionog sistema:

Informacioni sistem (eng. Information System) je sistem u kome se veze izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija.

Takoe, informacioni sistemi su sastavni deo upravljanja ("odranja eljene organizovanosti") nekog sistema. Iz tog ugla posmatranja moe im se pridodati atribut "upravljaki" i definisati upravljaki IS kao sistem koji prenosi, uva i obrauje podatke pretvarajui ih u informacije potrebne za upravljanje.

Pojmovi podatak i informacija se, u svakodnevnom govoru, koriste kao sinonimi. Medjutim, za precizno razgranienje koncepata o kojima se govori, neophodno je i ova dva pojma precizno definisati i razgraniiti.

OKOLINA

ULAZ IZLAZ (interfejs)

O1 O2

O3 On


13

Podatak je kodirana predstava o nekoj injenici iz realnog svijeta, on je nosilac informacije i slui za tehniko uobliavanje informacija, kako bi se one mogle sauvati ili prenijeti.

Informacija je protumaeni podatak o pojavi koju podatak prikazuje.

Krajnje tumaenje nekom podatku daje sam primalac (ovjek), uz pomo razliitih postupaka obrade podataka. Osnovna funkcija IS je uvanje i prenos podataka o injenicama iz sistema i njegove okoline i njihova obrada u informacije koje zahtjeva korisnik.

Znanje se gradi na osnovu novih informacija koje se nadovezuju na postojee znanje.

Isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u zavisnosti o njihovom znanju.

1.3. Elementi i osobine sistema i informacionih sistema

Mogu se izdvojiti slijedei elementi sistema i definisati njihove glavne osobine:

1. Podsistemi, odnosno komponente koje pripadaju sistemu;

2. Granice, definiu opseg i domaaj sistema;

3. Okolina je sve to je izvan granica sistema, ali se jo uvijek tie sistema;

4. Ulazi su elementi koji ulaze u sistem iz okoline;

5. Izlazi su elementi koji naputaju sistem;

6. Interfejs je veze izmeu sistema i njegove okoline;

7. Ogranienja, koja sainjavaju unutranji i vanjski inioci koji odreuju i ograniavaju funkcionisanje sistema;

8. Karakteristike, koje opisuju organizaciju, interakciju, meuzavisnost i integrisanost.

Organizacija je struktura i poredak, odnosno hijerarhijske veze koje odreuju formalnu komunikaciju i upravljaki lanac (npr. ustanova, preduzee). Interakcija predstavlja nain na koji pojedine komponente sarauju sa drugim komponentama (npr. Nabavka sa Proizvodnjom, Proizvodnja sa Prodajom). Meuzavisnost pokazuje


14

da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati, dok je integrisanost mjera povezanosti komponenti.

Za informacione sisteme se mogu izdvojiti bitni elementi i definisati njihovne glavne osobine: (1) sistemi za obavjetavanje, odnosno informacioni sistemi; (2) sistemi za upravljanje informacijama vanim za organizaciju i drutvo; (3) sistemi za upravljanje sadrajem ljudskih aktivnosti [Checkland, 1980].

Pojam informacionog sistema podrazumijeva sisteme koji su podrani raunarom, tj. raunarski (kompjuterizovani, kompjuterski) i sisteme koji se ne oslanjaju na raunare, ali obrauju informacije. Namjena IS je prikupljanje i pruanje informacija korisnicima u jednom ili vie poslovnih sistema, te se mogu nazvati organizacioni IS. Korisnici informacionih sistema su poslovodstvo, radnici (zaposleni, osoblje), klijenti i drugi. Upravljanje informacijama se obavlja bez obzira na vrstu sistema, a sainjavaju ga: prikupljanje podataka, zapisivanje i pamenje podataka, obrada podataka, skladitenje i pronalaenje informacija, kao i prikaz informacija u odgovarajuem obliku.

Informacioni sistem je podsistem poslovnog sistema. Sainjavaju ga ulazni podaci i izlazne informacije, procesi (obrada podataka o stanjima stvarnog sistema) i izvrioci (osobe, programi, raunari). Poslovne sisteme sainjavaju materijalni ulazi i izlazi (sirovine, energija, proizvodi) i informacioni tokovi (poruke, dokumenti). Ulaz u neki poslovni sistem predstavlja izlaz iz nekog drugog poslovnog sistema. Poslovni sistemi sadre procese (npr. obrada, prerada, proizvodnja), povratne veze (npr. poreenje plana i realizacije), skladita podataka (informacija), izvrioce (osobe, maine, alati, sirovine), skladita materijala, ... .

Informacioni sistem odreuju slijedee karakteristike: sloena okolina, koju je teko u potpunosti definisati, sloeni interfejs prema okolini, koji ukljuuje razliite ulaze i izlaze, sloene veze izmeu ulaza i izlaza (strukturno i algoritmiki), kao i veliki obim i sloenost podataka. Problemi projektovanja, izrade i odravanja IS se prevazilaze zbog vanosti IS za jedan poslovni sistem. Informacija je postala upravljaki resurs jednake vanosti kao to su vlasnitvo (osnovna sredstva), ljudski resursi ili kapital. Informacioni sistem sadri/predstavlja znanje organizacije koju podrava. IS i aplikacije pokazuju se prijeko potrebnim za odravanje konkurentnosti ili postizanje kompetitivnog prestia poslovnog sistema. Poslovni sistemi u kojima se IS primjenjuju visoko su zavisni o stalnoj raspoloivosti IS kroz due vrijeme.


15

1.4. Vrste informacionih sistema

Mogu se izdvojiti slijedee vrste informacionih sistema:

1. Transakcioni informacioni sistemi (TIS) [Transaction Processing System (TPS), sinonim Data Processing System], ija je namjena da evidentiraju i obrauju podatke o poslovnim transakcijama;

2. Upravljaki informacioni sistemi (UIS) [Management Information System (MIS)], koji imaju zadatak da podravaju upravljaku funkciju na osnovu dokazanih matematikih/statistikih metoda;

3. Sistemi za podrku odluivanju (SPO) [Decision Support System (DSS)], koji slue za odluivanje na osnovu nestrukturiranih podataka iz razliitih izvora;

4. Izvrni informacioni sistemi [Executive Information System (EIS)], koji predstavljaju podvarijantu IS za izvrne rukovodioce;

5. Ekspertni sistemi (ES) [Expert Systems (ES)], odnosno sistemi sa ugraenim znanjem i simulacijom zakljuivanja;

6. Sistemi za automatizaciju kancelarijskog poslovanja [Office Automation Systems (OAS)];

7. Sistemi za grupnu podrku [Group Support System, Groupware (GSS)].

Upravljanje i nivoi IS su prikazani tabelom 1.1.

Tabela 1.1.

Informacioni sistem

Informacije, kada

Korisnici, ko

Upravljanje

Transakcioni Obrada podataka, dnevno

Nie poslovodstvo Operativno

Upravljaki Zbirne, periodino Srednje poslovodstvo

Taktiko (trendovi)

Za podrku odluivanju

Sintetizovane, ad hoc

Vie poslovodstvo, uprava

Strategijsko (ta ako, )


16

1.5. ivotni ciklus razvoja sistema (Systems Development Life-Cycle (SDLC))

1.5.1. Pojam ivotnog ciklusa razvoja

Naziv ivotnog ciklusa razvoja zavisi od konteksta u kome je upotrebljen. Mogu

se izdvojiti slijedei nazivi ivotnog ciklusa: ivotni ciklus razvoja IS, ivotni ciklus razvoja softvera i ivotni ciklus razvoja aplikacija. Praenje ivotnog ciklusa obezbjeuje konzistentan i standardizovan nain razvoja IS. Svrha praenja ivotnog ciklusa razvoja omoguava pravilno planiranje, izvravanje i nadzor razvojnog projekta.

ivotni ciklus definie faze i zadatke (aktivnosti), koje nuno treba obaviti tokom razvoja, bez obzira na veliinu sistema koji se gradi. Svaka pojedina aktivnost proizvodi skup rezultata. Ciklus osigurava kontrolne toke za praenje napretka, procjenu postignutih rezultata i donoenje odluka o daljnjim koracima. Projekat prolazi kroz faze ivotnog ciklusa.

Primjer: Za ivotni ciklus razvoja softvera mogu se definisati slijedee faze i zadaci:

Potreba analize i dizajna (Requirements Analysis & Specification); Konceptualni/sistemski dizajn (Conceptual/System Design); Detaljni/programski dizajn (Detailed/Program Design); Implementacija/kodiranje (Implementation/Coding); Pojedinano i integralno testiranje (Unit & Integration Testing); Sistemsko testiranje (System Testing); Predaja sistema (System Delivery).

1.5.2. ivotni ciklus i faze razvoja informacionog sistema

Za ivotni ciklus razvoja IS (slika 1.3) potrebno je definisati mnogo kompleksnije faze.

Strategijsko planiranje razvoja IS poinje snimanjem stanja (inicijalna strategija). Doprinosi odreivanju poslovnih ciljeva, identifikovanju problema i ideja, odreivanju naina njihovog rjeavanja, te definisanju zahtjeva koji se postavljaju pred sistem. Sadri studiju izvodljivosti, odnosno preglednu analizu problemskog podruja i


17

odreivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada, odreivanja kadrova za projekat, upravljanje i nadzor projekta. Poslovni cilj je izrada glavnog projekta informatizacije.

Analiza zahtjeva je detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi. Vri se detaljna analiza postojeeg sistema, problema i poslovnih zahtjeva. Specifikacija zahtjeva je detaljni opis zahtjeva za IS, oblikovan tako da ga razumiju dizajneri. Predstavlja model budueg sistema.

Oblikovanje sistema, odnosno dizajn (modeliranje) IS, predstavlja pogled projektanta na budui IS. Slui za donoenje odluke o tome kako graditi sistem. Sadri dizajn potrebnih rjeenja. Postoje rjeenja koja ne treba dizajnirati. Detaljni dizajn predstavlja razradu rjeenja, odnosno izradu tehnolokog modela IS (pogled izvoaa). Potrebno je izvriti dizajn arhitekture, interfejsa, pohranjivanja podataka i programa, drugim rijeima izvriti tehniku specifikaciju sistema.

Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP), kodiranje procesa (funkcija) novog IS, a vri se nakon odabira raunarske platforme. Testiranje je provjera ugraenih komponenti. Integracija i provjera sistema je udruivanje dijelova i provjera cjeline, da bi se dokazalo da sistem radi (da je ispravno napravljen), te da radi ono to je zahtijevano (da je napravljen pravi sistem koji ispunjava zahtjeve korisnika).

Slika 1.3. Dijagram ivotnog ciklusa i faza razvoja IS [Fertalj & Kalpi, 2005].


18

Uvoenje u primjenu sistema predstavlja prenoenje radnih aktivnosti i konverzija podataka sa starog na novi sistem. Odravanje se sastoji od izmjena sistema radi poboljanja njegovih radnih karakteristika (performansi), poboljanja ili prilagoavanja naina upotrebe. Odravanje podrazumjeva i podrku dobavljaa opreme, pomo tehnikog osoblja korisnicima informacionog sistema u toku njegove upotrebe, kao i izradu plana odravanja.

Novi razvojni ciklus se provodi nakon preispitivanja itavog sistema i konstatacije da su potrebne vee izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. Novi razvojni ciklus, najee, predstavlja novi projekat.

Na slici 1.4 su navedene tipine faze ivotnog ciklusa razvoja softvera, bez naglaavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima.

Slika 1.4. Prikaz faza ivotnog ciklusa razvoja softvera.

1.6. Kompleksnost razvoja informacionog sistema

1.6.1. Ciljevi i problemi razvoja informacionih sistema

Osnovni cilj razvoja informacionog sistema je izgraditi sistem koji radi i koji je pouzdan, unutar zadanih granica. To podrazumjeva izgraditi sistem koji zadovoljava poslovne ciljeve, prema zahtjevima korisnika, u prihvatljivom vremenu i po opravdanoj


19

cijeni. Neki od problema koji se mogu pojaviti prilikom razvoja IS su: prekoraenje planiranog vremena i finansijskih sredstava, neispunjavanje zahtjeva, odnosno neodgovarajui sistem, nepouzdanost, nesigurnost, neelastinost IS u primjeni, kao i tekoe u odravanju IS. Oko 70% informacionih sistema u svijetu se smatra neuspjenim.

Prosjeno kotanje projekta prema The CHAOS Report [Standish Group, 1994, http://www.standishgroup.com] iznosi: velike kompanije 2,32 miliona $, srednje kompanije 1,33 miliona $ i male kompanije 434 hiljade $. Prosjeno prekoraenje trokova je 189%, a prosjeno prekoraenje rokova 222%. Projekti zavreni na vrijeme, u okviru predvienih sredstava i sa predvienim funkcijama, sainjavaju 16,2%, a projekti zavreni i u funkciji, ali uz vee trokove, due trajanje i/ili reduciranu funkcionalnost 52,7%. Prekinutih projekata je 31,1%. Procenat uspjenih i neuspjenih projekata IS prema Standish Group, 2002. iznosi 34% uspjenih projekata i 17% potpunih neuspjeha.

1.6.2. Neki primjeri neuspjenih projekata i sistema

London Ambulance System (1992): Nakon uvoenja u eksploataciju IS se dva puta "raspao" zbog niza greaka, naroito zbog greaka u upravljanju razvojem IS. Neposredni troak je bio relativno nizak (9 miliona ), ali se vjeruje da su neki ljudi umrli, jer se do njih nije stiglo na vrijeme.

Taurus (1993): Projekat sistema automatizovanih transakcija Londonske berze prekinut je nakon 5 godina razvoja i troka od 75 miliona , te posljedini gubitak klijenata od 450 miliona . Ukupni gubici smatra se da su neizraunljivi.

Denver Airport (1994): Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odlaganje otvaranja vazdune luke u trajanju od 16 mjeseci, uz trokove od 1,1 miliona $/dan.

Ariane 5 (1996): Raketa eksplodirala u lanseru radi niza softverskih greaka.

1.6.3. Uzroci neuspjeha projekata informacionih sistema

Razlozi neuspjenih projekata IS su razliiti. Mogu se izdvojiti slijedei razlozi: sloenost aplikacija, nedostatak usmjerenosti korisniku, zanemarivanje okruenja


20

organizacije, pretjerani optimizam, izostanak praenja napretka i nedostatak komunikacije izmeu korisnika i izvoaa.

U naem okruenju uzroci neuspjeha se, uglavnom, ne istrauju, a informacije o neuspjenim projektima nerado se objavljuju. Meu najeim uzrocima moe se pretpostaviti da su: loa organizacija i voenje projekata, oslonac na vanjske projektante i savjetnike, delegirano upravljanje projektima, nerealno planiranje, formalno izvjetavanje o napretku, formalni nadzor nad projektom, kao i podcijenjena uloga vlastitih strunjaka. Ne treba iskljuiti i slijedee uzroke neuspjeha: loa izvedba projekata, neodgovarajua analiza sistema, greke u dizajnu i kontroli kvaliteta, neodgovarajui CASE alati i krivo koritenje, pa ak i svojevrsna zloporaba CASE alata. Mnogi sistemi su propali, ili su bili odbaeni, jer su se izvoai trudili napraviti lijepa programska rjeenja, a nisu razumjeli sutinu poslovnog sistema i poslovanja.

1.6.4. Poboljanje uspjenosti informacionih sistema

Da bi se poboljala uspjenost IS potrebno je:

projektovanje IS, planiranje, upravljanje izvedbom, praenje napretka, ukljuivanje korisnika.

Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe, a informatiar upoznaje(?) poslovanje i zna(?) kako izraditi IS. Vano je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogunostima i koristima uvoenja IS, naroito jer donosi konane (za poslovni sistem sudbonosne) odluke.


21

2. Planiranje razvoja informacionog sistema

2.1. Modaliteti razvoja informacionog sistema

2.1.1. Vlastiti razvoj informacionog sistema Postoje razliiti modaliteti razvoja informacionog sistema. U ovoj knjizi e biti razmatrani modaliteti razvoja koji se najee koriste. Razvoj vlastitim informatikim snagama podrazumjeva osposobljavanje i angairanje netehnikog osoblja, kao i povremeno ili dugorono angaovanje spoljnih saradnika. Prednosti ovakvog pristupa su fleksibilnost, kreativnost i poveanje strunosti vlastitog osoblja. Nedostaci su da ovaj pristup zahtijeva znaajno vrijeme i napor, razvoj je skuplji i dugotrajniji i moe poveati gomilanje zaostalog posla.

Razvoj vlastitim snagama ima smisla kada se radi o programskoj podrci koja je posebnost organizacije, takva da ne postoje gotova rjeenja na tritu ili takva da organizacija pomou nje postie komparativnu prednost u odnosu na konkurenciju. Postoje dodatni ili posebni razlozi kao to su poveana tajnost podataka i poslovnih procesa ili poveana zatita IS.

2.1.2. Vanjski razvoj informacionog sistema

Angaovanje vanjskih saradnika za razvoj informacijskog sistema, ili njegovih dijelova, podrazumjeva pruanje pomoi u obrazovanju radnika informatike struke, pomo pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja. Takoe se podrazumjeva kodiranje (generisanje) cjelovitog programskog sistema, upravljanje izvoenjem i/ili nadzor izvoenja, kao i konsultativna pomo prilikom ugradnje sloenih poslovnih funkcija. Varijante su slijedee: ugovoreni razvoj, odnosno ugovara se isporuka gotovog proizvoda ili dugorona saradnja sa isporuiocem, uz izdvajanje vlastitog informatikog odjela u glavnog izvoaa. Mogua varijanta je i nalaenje stratekog partnera na dui vremenski period, npr. softverske kue.

Prednosti su viestruke. IS ili njegovi dijelovi izrauju se po mjeri naruioca, sistem je prilagoen organizaciji/poslovanju, a po mogunosti treba istovremeno poboljati organizaciju/poslovanje poslovnog sistema. Ovakav razvoj podrazumijeva dugotrajan postupak i odgovarajuu visoku cijenu.


22

Nedostaci i rizici su takoe prisutni. Dolazi do gubitka povjerljivih informacija, gubitka nadzora nad sadanjim i/ili buduim razvojem (zavisnost o dobavljau), kao i gubitak vlastite strunosti.

Nuno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogunost odluivanja.

2.1.3. Nabavka gotovih aplikacija

Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe. Poeljno je da se mogu prilagoditi potrebama. Primjeri aplikativnih paketa, koji se mogu nabaviti kao gotovi proizvodi, su: programski paketi za kancelarijsko poslovanje (npr. Microsoft Office), programi za upravljanje dokumentima (npr. Lotus Domino) ili specijalistike aplikacije za odreene namjene.

Mogu se nabaviti slijedei sistemi za upravljanje poslovanjem, koji nose komercijalne nazive: Enterprise Resource Planning (ERP) systems, SAP, BAAN, J.D. Edvards, Peoplesoft. Cjeloviti sistemi za podrku poslovanju, uglavnom, podravaju slijedee aplikacije: finansijsko poslovanje (accounting), proizvodnju (manufacturing), robno-materijalno poslovanje (material management/distribution), upravljanje ljudskim resursima i plate (CG management, payroll).

2.1.4. Nabavka poslovnih aplikacija

Slijedei modalitet razvoja IS je nabavka i prilagoavanje postojeih domaih poslovnih aplikacija. Prednost ovog pristupa je usklaenost vaeim uslovima, npr. propisima, ta olakava prilagoavanje aplikacija organizaciji/poslovanju. Nedostatci su nepostojanje ili manjkavost pojedinih komponenti, mjestimina tehnoloka zastarjelost, prekapacitiranost dobavljaa. Modaliteti ovakvog pristupa su slijedei: otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz samostalno odravanje.

Nabavka gotovih stranih poslovnih aplikacija, takoe, ima svoje prednosti i nedostatke. Prednosti su raskona funkcionalnost i kompatibilnost sa svjetskim poslovnim standardima, dok se nedostatci ogledaju u neprilagoenosti domaim uslovima i konkretnoj organizaciji/poslovanju, ta zahtijeva istovremeno prilagoavanje programske opreme i promjenu organizacije/poslovanja. Prilagoavanje se obavlja slino razvoju, ta moe uzrokovati da rjeenja gube moguu komparativnu prednost (brzinu i lakou primjene). Glomazni paketi mogu zahtijevati angaovanje velikog broja


23

konsultanata. Mogui modalitet nabavke je da se prilagoavanje vri vlastitim snagama uz savjetovanje i pomo dobavljaa.

2.1.5. Kriterijumi za donoenje odluke o nabavci

Opti kriterijumi za donoenje odluke o razvoju IS su:

cijena, funkcionalnost, kapacitet, brzina, broj korisnika, mogunost obuke i trajne podrke, kredibilitet i odrivost dobavljaa na tritu, to se dokazuje referensama, elastinost, tj. mogunost prilagoavanja i prepravki, raspoloivost dokumentacije.

U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost, interoperabilnost), tehnike mogunosti (Client-Server, OLTP, OLAP), referense dobavljaa (prisutnost dobavljaa na lokalnom tritu) i podrka korisnicima. Pod podrkom korisnicima se podrazumjeva: kolovanje, tehnike konsultacije, odravanje (dinamika razvoja i mogunosti nabavke novih verzija), blagovremeno otklanjanje problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitih aplikacija.

2.1.6. Nabavka izvedbenog programskog koda

Prednosti nabavke izvedbenog koda su: izvedbeni kd je jeftiniji, brigu i odgovornost o njegovom odravanju preuzima isporuilac, uz izuzetak nekih opte primjenjivih komercijalnih programa. Prednost izvedbenog koda je i ta da se ne mora kupiti (skupi) razvojni programski alat u kojem je programski proizvod razvijan.

Mane izvedbenog koda, obzirom na korisnika, su: izvedbeni kd podrazumijeva potpunu zavisnost od isporuioca, ne postoji mogunost prilagoavanja specifinim vlastitim potrebama, osim putem posebnog dogovora sa isporuiocem. Dodatna prilagoavanja lako mogu postati predmetom ucjene. Takoe, ne postoji mogunost razvoja programske opreme vlastitim snagama.

2.1.7. Nabavka izvornog programskog koda

Prednosti nabavke izvornog programskog koda su znatne. Izvorni kd omoguava stalni razvoj i praenje vlastitih posebnosti, to se moe pokazati kao prednost u odnosu na konkurenciju. Osim toga, prua mogunost prilagavanja vlastitim


24

potrebama, ta daje elastinost pri promjenama organizacije poslovanja. Nema bojazni da e nakon prve potrebne izmjene prestati upotreba IS zbog toga to isporuilac nije trenutno dostupan, postavlja nerazumne uslove ili je u meuvremenu nestao sa trita. Uvidom u kvalitetna gotova rjeenja pomae se razvoju vlastitih informatikih radnika.

Mane narudbe izvornog koda su, takoe, prisutne. Izvorni kd je viestruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. Naruilac se izlae iskuenju da nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad i izgubi pravo na odravanje. Odravanje je skuplje ukoliko se radi o programskoj opremi podlonoj promjenama.

Snienje cijene izvornog koda moe se postii automatizacijom kodiranja, upotrebom generatora izvornog koda.

Preporuke za izbor programskog koda su slijedee. Izvedbeni kd treba preporuiti u slijedeim sluajevima:

kada se radi o standardnim, masovno prodavanim aplikacijama, kada korisnik nema vlastite informatike strunjake, kada se radi o visokostrunim aplikacijama koje se nee mnogo mijenjati, a

korisnik nema namjeru da se baviti detaljima te struke, kada korisnik nema novaca ili elje za vlastiti informatiki razvoj.

Izvorni kd treba preporuiti onda:

kada programska oprema predstavlja strateku investiciju, kada korisnik raspolae kompetentnim informatiarima ili ima motiva razvijati

vlastitu informatiku djelatnost, kada isporuilac ne moe preuzeti obavezu odravanja ili ne moe garantovati

da e ostati na tritu, kada na tritu ne postoji IS koji odgovara potrebama, ne moe se povoljno

kupiti slian, a korisnik raspolae vlastitim informatikim snagama dovoljnim za projektovanje novog.

2.1.8. Izbor modaliteta razvoja

Odreivanje moguih rjeenja podrazumjeva identifikaciju rjeenja na osnovu poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija raunarske opreme i programske podrke, te odabrana tehnoloka arhitektura, dok su izlazi mogua rjeenja novog sistema i njihove karakteristike.

Analiza izvodljivosti alternativnih rjeenja se sastoji od procjena alternativa obzirom na tehniku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi su


25

karakteristike moguih rjeenja, karakteristike i cijene hardvera i softvera, referense i uslovi dobavljaa, a izlazi analiza izvodljivosti za svako mogue rjeenje.

Prijedlog rjeenja sistema koji e se oblikovati i ugraditi se donosi na osnovu izbora onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti, plan projekta, procjena veliine projekta, a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloenog sistema.

2.1.9. Ocjenjivanje kriterijuma za izbor sistema

Na osnovu opisa karakteristika ne moe se sa sigurnou procijeniti koji je sistem najbolji. Da bi se pravilno uporedio znaaj razliitih kriterijuma koristi se sistem bodovanja. Procedura bodovanja kriterijuma je slijedea. Odredi se teinski faktor za svaki kriterijum (npr. od 1 do 4). Oni kriterijumi koji su znaajniji u uporedbi sistema dobivaju vee teinske faktore. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. od 0 do 5). Dodjeljena ocjena se pomnoi teinskim faktorom kriterijuma za koji je donesena, te se dobije broj bodova [Fertalj & Kalpi, 2005].

Primjer: Analiza izvodljivosti za mogua rjeenja. Tabela 2.1.

Operativni sistem 2 4 8 4 8 1 2 3 6 Baza podataka 1 4 4 4 4 2 2 1 1 Brzina pretraivanja i dohvat podataka 4 5 20 4 16 1 4 4 16 Programski jezik 1 4 4 5 5 2 2 2 2 Raspoloiv izvorni kod 1 0 0 0 0 5 5 0 0 Korisniki interfejs 2 5 10 5 10 3 6 3 6 Integrisani sistem pomoi (on-line help) 2 5 10 0 0 0 0 0 0 Dokumentacija (na papiru) 2 4 8 0 0 0 0 4 8 Mogunosti aplikacije 4 5 20 1 4 2 8 5 20 Integracija sa drugim aplikacijama 3 4 12 3 9 0 0 0 0 Brzina ispisa rauna 4 2 8 3 12 5 20 5 20 Rad sa razliitim tampaima 3 5 15 5 15 0 0 0 0 Rad u mrei 1 5 5 0 0 0 0 0 0 Vrijeme obuke korisnika 1 3 3 5 5 5 5 3 3 Arhiviranje podataka 2 5 10 0 0 5 10 5 10 Upotreba konfiguracije za druge poslove 3 5 15 5 15 0 0 3 9 Broj instalisanih paketa 1 3 3 2 2 5 5 5 5 Datum prve instalacije 1 3 3 3 3 5 5 5 5 Cijena paketa 2 2 4 5 10 4 8 2 4 Cijena raunara i sistemskog softvera 3 3 9 2 6 5 15 3 9 Ukupno bodova: 171 124 97 124

Teinski Super Video Video Boss Video ZZ Video Karakteristike: faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi


26

Na kraju se saberu dodjeljeni bodovi po svim kriterijumima za svaki sistem: n

Si = 3sij wj j =1

gdje su: Si = ukupna vrijednost i - tog rjeenja, sij = vrijednost j - tog kriterijuma za i - to rjeenje, wj = vanost ili teina j - tog kriterijuma.

Najbolji je onaj sistem sa najveim brojem bodova (npr. Super Video, tabela 2.1). esto se mogu javiti slijedee nedoumice:

ta uiniti kada su sistemi (pod)jednako bodovani? ta uiniti ako pojedino svojstvo ima vie podsvojstava?

2.1.10. Izbor dobavljaa proizvoda ili usluga

Definisanje kriterijuma i opcija, kod izbora dobavljaa proizvoda ili usluga, vri se

na osnovu slijedeih ulaza i izlaza. Ulazi sadre specifikacije zahtjeva za programsku podrku i raunarsku opremu: funkcionalnost, dodatna svojstva, kljune parametre performansi, ... . Izlazi su lista potencijalnih dobavljaa proizvoda ili usluga, te kriterijumi za izbor.

Kod prikupljanja ponuda treba potencijalnom dobavljau uputiti zahtjev za dostavljanje referensi (kada postoje razliiti dobavljai i/ili proizvodi, a eli se odabrati najbolje rjeenje, prikupljaju se ponude koje su skup referensi"), kao i zahtjev za dostavljanje ponude sa informacijama o konfiguracijama, cijenama, odravanju (kada se odreeni proizvod moe nabaviti od razliitih dobavljaa).

Izbor ponuda se obavlja slijedeim redoslijedom: (1) provjera sadraja ponuda, (2) izrada rang liste, poeljno odvojenim ocjenjivanjem pojedinanih ponuda, (3) izbor objektivno najboljeg ponuaa (to se, naalost, vrlo teko uklapa u zakonske odredbe po kojima treba tano specificirati to se eli, a mora se kupiti najjeftinije).

Ugovaranje posla se zavrava sklapanjem ugovora koji definie uslove saradnje, isporuke i naplate, integracije sa postojeim sistemom, odravanja i slino. Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zamiljeno.

Izvrilac projekta treba biti stimulisan proporcionalno ostvarenoj, u praksi dokazanoj i od korisnika prihvaenoj, funkcionalnosti sistema.


27

2.2. Analiza izvodljivosti, trokova i koristi projekta

2.2.1. Analiza izvodljivosti projekta

Za pojedine projekte se vri analiza njihove izvodljivosti, odnosno mjerenje korisnosti, praktinosti i isplativosti projekta IS. Ove analize treba da se vre tokom planiranja, ali i kasnije, npr. nakon faze sistemske analize. Nakon odluke o pokretanju projekta sloenost i opseg projekta se mogu promijeniti, te poetno izvodljiv projekat moe postati neizvodljiv. Praktino gledano, tonost procjene izvodljivosti raste sa dubinom analize.

Studija izvodljivosti (feasibility study) sadri: (1) detaljnu provjeru projekta, koju provode sistem analitiari, (2) procjenu da li je projekat izvodljiv obzirom na raspoloiva sredstva, (3) procjenjuje se da li projekat omoguava poboljanja, (4) radi se izvjetaj o izvodljivosti i prezentira se relevantnim uesnicima radi komentara i miljenja (moe biti dio idejnog rjeenja), (5) eventualni povratak u studiju izvodljivosti, odnosno revidirani izvjetaj.

2.2.2. Izvjetaj o izvodljivosti projekta

Izvjetaj o izvodljivosti projekta sainjavaju slijedee analize:

organizaciono - operativna izvodljivost, tehniko - tehnoloka izvodljivost, vremenska izvodljivost, ekonomska izvodljivost.

Analiza organizaciono - operativne izvodljivosti projekta sadri procjenu hitnosti rjeavanja problema (planiranje), kao i procjenu prihvatljivosti rjeenja (kasnije faze). Tu se neminovno nameu i slijedea pitanja: Vrijedi li rjeavati problem? i Da li predloeno rjeenje rjeava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno protonost i odziv sistema u odnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, aurne, tane, korisne), ekonomiske aspekte (gdje spadaju problemi trokova i mogunosti uteda), kontrolu (u prvom redu sigurnost i zatitu podataka), efikasnost (odnosno poboljavanje upotrebe raspoloivih resursa: ljudi, opreme, novca, itd.), kao i usluge (poeljni i pouzdani servisi, elastinost i mogunost prilagoavanja, zadovoljstvo).

Nita manje bitni nisu ni odgovori na slijedea pitanja: Koji je stav korisnika prema rjeenju? i Da li e se sistem koristiti? Neophodni su podrka uprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uoiti otpore ulozi ili tehnikim


28

rjeenjima sistema i predloiti naine njihovog otklanjanja. Krajnjeg korisnika treba na vrijeme pripremiti za promjenu radnog okruenja i procedura. Procjena upotrebljivosti sistema se najlake moe izvriti koritenjem prototipa. Potrebno je pravilno ocjeniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema. Namjeniti jednostavni interfejs za poetnike i povremene korisnike, sloenije operacije za iskusne korisnike. Obezbjediti da korisnik daje prednost ponuenom rjeenju u odnosu na postojei nain rada.

Analiza tehniko - tehnoloke izvodljivosti projekta sadri procjenu moguih rjeenja i alternativa. U prvom redu potrebno je izvriti procjenu stanja na tritu opreme, procjenu postojeih rjeenja u drugim organizacijama (tamo gdje je mogue), kao i procjenu primjenjivosti razliitih tehnologija.

Veoma bitna osobina je da se zastupljena tehnoloka rjeenja mogu jednostavno primijeniti. Raspoloivost tehnologije podrazumijeva da se primjenljiva tehnologija moe nabaviti. Ako je rije o gotovom rjeenju, ima li to rjeenje potrebne karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Nita manje bitno nije ni injenica da li postoje potrebni strunjaci za primjenu nove tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija moe savladati.

Analiza vremenske izvodljivosti projekta treba da d odgovor da li su predvieni rokovi ostvarivi, obzirom na raspoloivu strunost. Oekivano vrijeme zavretka moe biti poeljno ili obavezno. Bolje je isporuiti ispravan sistem dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme!

Ekonomska izvodljivost projekta e biti objanjena preko analiza i uporedbe ukupnih trokova - koristi (cost-benefit analysis (CBA)). Trokovi i korist mogu biti mjerljivi (npr. cijena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr. zadovoljstvo korisnika, brzina odluivanja, dobra referensa).

Finansijski troak i korist se mogu izraziti formulama: (1) razlika korist troak u nekom razdoblju (Net Present Value), (2) povrat investicije (korist troak)/troak (Internal Rate of Return), (3) trenutak u kojem korist nadvlada troak (Payback Point).

CBA rauna trokove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Dananja vrijednost onoga to e postati $1,00 nakon n godina u budunosti, ako se uzmu u obzir kamate I iznosi:

PV = 1/(1 + I)n = (1 + I) n

Razlika predstavlja kamatu koja se moe zaraditi tim novcem ($ oznaava novanu jedinicu u bilo kojoj valuti). .

Primjeri:

Trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000;


29

Korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo:

$30.000 / (1 + 0.08)5 = $20.417

Povrat investicije (Return On Investment (ROI)) se obino dijeli sa duinom trajanja projekta kako bi se dobio godinji ROI. Nizak ROI (~ manji od 10% godinje) moe pokazivati da je korist preniska da bi bila isplativa. Odnos troak/korist je prikazan tabelom 2.2 i grafikim prikazom tabele.

Primjer: Analiza troak korist [Fertalj & Kalpi, 2005]. Tabela 2.2.


30

2.3. Strategija i planiranje razvoja informacionog sistema

2.3.1. Definisanje poslovne strategije

Poslovni ciljevi zahtjevaju definisanje poslovne strategije, odnosno planiranje akcija za postizanje ciljeva. Uprava definie viziju i misiju poslovnog sistema, tj. strategijske ciljeve. Na osnovu strategijskih ciljeva se definiu poslovni ciljevi i odreuju zadaci, kojima e poslovni sistem u nekom razdoblju ispuniti svoju misiju. Pri tome se dobijaju odgovori: ta se eli postii (prepoznatljivost, kvalitet, prihodi), kako eljeno postii (promjenom organizacije, poboljanjem sistema administracije), kako ostvariti poveanje proizvodnje ulaganjem u nove proizvodne tehnologije, uz istovremeno odravanje kvaliteta proizvoda, i kako osigurati zadovoljstva i radne sposobnosti zaposlenih dokolovavanjem i mogunostima napredovanja.

inioci koji utjeu na postavljanje ciljeva su slijedei: ogranienja (organizaciona, finansijska, zakonska), potrebe i elje uprave, poslovodstva, zaposlenih (ugled, uticaj), vremenski okviri, gdje je kratkorono razdoblje obino manje od 2 godine, srednjorono 2 do 5 godina i dugorono vie od 5 godina [Awad, 1985].

2.3.2. Planiranje razvoja informacionog sistema

Planiranje razvoja informacionog sistema treba da d odgovor na slijedea

pitanja:

ime se poslovni sistem bavi (grana, proizvodi, trite, konkurencija)? Koji su problemi, zadaci i ciljevi poslovnog sistema? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slue, koje i kakve podatke sadre? Postoje li aplikacije iji je razvoj u toku? U kojem su stadijumu razvojni

projekti? Koje su potrebne aplikacije? Koji su raspoloivi resursi (osoblje, tehnika sredstva, tehnologija)?

Razlozi zbog kojih treba planirati IS su viestruki. Na primjer, u Poslovnom sistemu koji se sastoji od vie cjelina, kao to su Uprava, Finansije, Proizvodnja i Informatika esto postoji vie razliitih tehnikih sistema ili aplikacija, takozvanih informatikih ostrva. To ima za posljedicu umnoavanje informacija uz razliito tumaenje u razliitim dijelovima, nepotpunost informacija, naroito kada svaka cjelina prikuplja samo njoj vane informacije, problem povezivanja informacija pri pokuaju cjelovite interpretacije, kao i problem razliitog posluivanja, razmjene podataka i odravanja.


31

Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici. Strategojsko planiranje IS je prikladno za stabilne poslovne sisteme. U praksi je teko izvodljivo u uslovima preivljavanja. Sastoji se od uspostave smjera i prioriteta usklaivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podrka promjeni poslovnog sistema i poslovnih procesa. Jo se mogu navesti primjene metoda analize i dizajna za prouavanje poslovnog sistema, sa ciljem definisanja opteg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi.

U praksi situacija je slijedea. Umjesto prema strategijskom planu, poslovni sistem se "dovodi u red" tokom informatizacije i pomou informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budui da se dizajnom sistema predlau ili nameu poboljanja.

2.3.3. Odabir i pokretanje projekta

Prvenstveno pokretai promjena su korisnici, odnosno njihovo nezadovoljstvo aplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokuje nedostatak podataka, to naglaava potrebu uvoenja novih funkcija. Nezadovoljstvo podacima nastaje uslijed njihove nepouzdanosti, nedostupnosti, manjkavosti, a nezadovoljstvo reorganizacijom nastaje uslijed promjene organizacione strukture, promjene poslovnih procesa (npr. promjene na Univerzitetu uzrokovane novim zakonom). Pokretai promjena mogu biti i pokazatelji poslovanja (npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno poveanje trokova), kao i zastarila tehnologija (npr. zastario razvojni alat i prisutan problem njihovog odravanja, zastario interfejs Internet-a, zastarile BP).

Odabir projekta se vri na osnovu prijedloga projekta, koga sastavlja sponzor projekta (organizator, predlaga). Prijedlog projekta sadri saetak projekta (naziv, cilj, svrha), poslovne potrebe, oekivanu funkcionalnost, oekivanu korist, kao i posebnosti i ogranienja. Radna grupa za odabir projekta odobrava projekat. Prije pokretanja projekta potrebno je izvriti snimak stanja, odnosno prethodno istraivanje, tj. istraivanje koje prethodi projektu, prepoznavanje problema i potreba, kao i traenje odgovora na pitanje "Da li je projekt vrijedan panje?".

Slijedi faza prouavanja problema, produbljivanje snimka, postavljanje ciljeva, prijedlozi rjeenja, procjena izvodljivosti, traenje odgovora na pitanja "Da li su problemi vrijedni rjeavanja? i "Da li je gradnja isplativa?".

Planiranje projekta, odnosno organizacija i upravljanje projektom, sastoji se od slijedeih aktivnosti: izrada plana rada, oformljenje projektantske ekipe (ukljuivanje


32

uesnika iz razliitih djelatnosti, npr. radnici razliitih poslovnih podruja ili organizacijskih jedinica, uprava, vanjski konsultanti), pri emu je vano osigurati predanost uesnika zajednikom cilju, i, na kraju, uspostava upravljanja i nadzora projekta.

2.3.4. Snimanje stanja

Snimanje stanja omoguava brzo istraivanje i evaluaciju problema, moguih prilika i direktiva. Pod problemom se podrazumjeva neeljena situacija koja sprjeava potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadataka. Mogua prilika je mogunost pozitivne promjene, ak i kada ne postoji problem, dok je direktiva zahtjev ili ogranienje koji su nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim uticajem (npr. zakon). Mogue je opciono provoenje procjena moguih tehnikih rjeenja, pri emu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazama, kao i odreivanje dosega projekta i poetnog plana projekta.

Snimanje poslovnog sistema se sastoji od pregleda poslovnih planova, ako takvi postoje ili nisu tajna, prikupljanja informacija, najee intervjuisanjem korisnika, vlasnika i viih rukovodilaca, kao i evidentiranja problema i prijedloga. Snimanje stanja obuhvata identifikaciju korisnika i opsega postojeeg (postojeih) IS, uoavanje problema i nedostataka postojeeg IS, procjenu potreba za nadogradnjom (poboljanjima), pocjenu potreba za izmjenama (prilagoavanjem i popravkama) i procjenu potreba za izradom novih IS ili podsistema IS (Tabela 2.3).

Primjer: Postojei problemi i prijedlozi rjeenja [Fertalj & Kalpi, 2005]. Tabela 2.3. Kratko obrazloenje problema, mogunosti ili direktive

Hitnost Vidljivost Korist Prioritet Predloeno rjeenje

1. Vrijeme odgovora na narudbu mjereno od vremena zaprimanja narudbe do isporuke klijentu se povealo na prosjeno 15 dana.

HITNO

Visoka 175000 2 Novi razvoj

2. Nedavno preuzimanje kompanija: Privatna predstava i Filmsko platno nametnulo je poveanje zahtjeva za protokom informacija i dokumenata.

6 mjeseci

Srednja 75000 2 Novi razvoj

3. Trenutno 3 razliita sistema za unos narudbi servisiraju odjele za audio, video i video igre. Svaki sistem ima vlastiti interfejs prema razliitom skladinom sistemu, pa treba objediniti skladinu evidenciju.

6 mjeseci

Srednja 515000 2 Novi razvoj

4. Postoji nedostatak pristupa informacijama nunim za upravljanje i donoenje odluka. Ovo e se jo pogorati preuzimanjem dva dodatna sistema za obradu narudbi (iz Privatna predstava i Filmsko platno).

12 mjeseci

Niska 15000 3 Nakon razvoja novog sistema, pruiti korisnicima lako savladive alate za pisanje izvjetaja.

5. Izraena je nedoslijednost (nekonzistentnost) izmeu podataka u evidencijama lanova i narudbi.

3 mjeseca

Visoka 35000 1 Brza ispravka, a zatim novi razvoj.


33

6. Sistemi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni sa onim u Zvuna pozornica. Problemi sa podacima obuhvataju nedoslijednosti u podacima i nedostatak upravljanja ulazom i izmjenama.

6 mjeseci

Srednja nepozna- ta

2 Novi razvoj, dodatna ocjena koristi moe poveati aurnost.

7. Postoji mogunost uvoenja sistema naruivanja putem Interneta, ali su sigurnost i kontrola pristupa problematini.

12 mjeseci

Niska nepozna- ta

4 Budue verzije tek razvijenog sistema.

8. Postojei sistem unosa narudbi nije kompatibilan sa planiranim sistemom za automatsku identifikaciju (tapiasti kod) koji se razvija za skladite.

3 mjeseca

Visoka 65000 1 Brza ispravka, a zatim novi razvoj.

Vidljivost: U kojoj mjeri e rjeenje ili novi sistem biti vidljivi korisnicima.

Korist: Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo troak u jednoj godini.

2.3.5. Planiranje projekta

Planiranje projekta podrazumjeva odreivanje namjene projekta i izdvajanje zadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Domet i razgranienje projekata ili podprojekata (System boundary, Constraints, Objectives, Permissions, End products (SCOPE)) daje odgovore na slijedea pitanja:

Koje su granice sistema? Koji e zahtjevi biti ispunjeni? ta ne moe biti napravljeno? ta nee biti napravljeno? Ko e, kako i pod kojim uslovima moi koristiti rjeenje? Kako se mjeri ili odreuje uspjeh (neuspjeh)? Kako e se znati da je projekat gotov?

Vremensko planiranje obuhvata odreivanje prioritetnih zadataka i vremenskih okvira prioriteta. Izrada poetnog (preliminarnog) plana razvoja IS zapoinje podjelom projekta u manje cjeline i odreivanje redoslijeda realizacije pojedinih podprojekata. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada i raspodjela poslova, kao i odreivanje prioriteta. Nastoji se pronai takva podjela posla na cjeline da cjelinu moe obaviti jedna osoba ili ekipa, da se cjelina moe obaviti jednom metodom i posao zavri jednim proizvodom (dokumentom, aplikacijom ili podsistemom).

Poetni plan razvoja IS sadri nazive podprojekata i omoguava doradu i auriranje u skladu sa napretkom projekta. Moe se koristiti za prezentaciju projekta radi traenja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta moe posluiti kao interni ugovor projekta (tabela 2.4).


34

Primjer: Poetni (preliminarni) plan informacionog sistema, tabela 2.4. Tabela 2.4.

1. Nabavka sistema za upravljanje bazama podataka; 2. Obuka opte informatike pismenosti za rukovodioce odjeljenja; 3. Obuka za programere u jeziku za upravljanje bazama podataka; 4. Obuka za administratore baze podataka; 5. Izrada prototipa programske podrke za i-tu fazu realizacije; 6. Izrada - verzije aplikacije; 7. Testiranje - verzije u informacionim sistemima; 8. Uklanjanje uoenih nedostataka i izrada - verzije programa; 9. Obuka za odabrane korisnike na - verziji; 10. Testiranje kod korisnika u paralelnom radu sa dosadanjim programom; 11. Uklanjanje nedostataka i izrada stabilne verzije; 12. Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka; 13. Obuka za ostale korisnike; 14. Uvoenje koritenja programa kod ostalih korisnika; 15. Obuka za upoznavanje sa mogunostima programa za odabrano poslovodstvo; 16. Prikupljanje primjedbi korisnika i novih zahtjeva; 17. Izrada slijedee faze/verzije programa. Povratak na taku 5).

2.3.6. Izvjetaj o projektu

Izvjetaj o projektu obrauje probleme i dostignua projekta, a moe imati oblik prikazan tabelom 2.5. Tabela 2.5.

Saetak - Saetak prijedloga - Kratko obrazloenje

oekivanih koristi - Kratko objanjenje

sadraja izvjetaja Prikupljene informacije

- Kratak opis projektnog zadatka - Kratko objanjenje provedenih

aktivnosti injenice i zakljuci

(moe se potkrijepiti matricom problema i moguih rjeenja) - Problemi i analiza problema - Mogunosti i analiza mogunosti - Direktive i implikacije

Detaljan prijedlog - Obrazloenje prijedloga

* Hitne prepravke * Brze prepravke

* Unapreenja * Novi razvoj

- Plan projekta * Poetni ciljevi projekta * Poetni glavni plan projekta (na nivou faza) * Detaljni plan za slijedeu fazu

Prilozi - Zahtjev za uslugama sistema - Matrica obrazloenja problema

- (ostala dokumentacija)


35

2.3.7. Odreivanje poslovnih ciljeva

Za projekte koji prou poetnu selekciju vri se produbljivanje analize problema. Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rjeavanja i da li je gradnja IS isplativa. Vri se detaljnija analiza problema, njihovih uzroka i posljedica, imajui na umu misao: "Ne pokuavaj popraviti prije nego shvati kako radi!" Takoe je potrebno izvriti analizu poslovnih procesa odgovarajui na pitanja:

Koji su najvei problemi? Koja su mogua rjeenja problema? Kako informatizacija moe pomoi?

kao i grubo modeliranje postojeeg sistema.

Mogu se koristiti razliite formalne metode, od kojih su najznaajnije:

1. Analiza kritinih faktora uspjeha (Critical Success Factors (CSF)), odnosno inilaca, kojima poslovodstvo posveuje posebnu panju. Ti inioci treba srazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr. brzi odgovor na zahtjeve klijenata, odnos cijene i kvaliteta proizvoda, ... );

2. Planiranje poslovnog sistema (Business Systems Planning (BSP)) firme IBM, odnosno analiza poslovnih procesa analizom od vrha prema dolje i uoavanje podataka povezanih sa procesima;

3. Analiza izvodljivosti i procjena trokova - koristi.

2.3.8. Uzroci i posljedice problema, ciljevi i ogranienja

Istraivanje uzroka problema, koji mogu biti raznovrsni, se mogu ilustrovati na slijedeem jednostavnom primjeru:

Zadatak analitiara je da razdvoji uzroke i posljedice problema.

Drugi primjer: Dug red u videoteci nije poseban problem, a moe biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica runog unosa podataka i izdavanja rauna.

Problem: pad prodaje Vidljivi znak: poveani opoziv (storno) narudbi Razlog: nezadovoljstvo kupaca Uzrok: spor sistem za naruivanje


36

U razmatranom primjeru analitiar treba razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan.

Primjeri poslovnih ciljeva mogu biti raznovrsni. Ovdje e biti navedeni, kao primjeri, neki od moguih ciljeva: pomoi reorganizaciju u trino orijentisanom poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troka u sistemu, uskladiti hijerarhiju odluivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utroak novca za ... .

Ogranienja mogu biti slijedea: osoblje (npr. odjel informatike smije zaposliti najvie tri stalno zaposlena radnika), materijalni troak (npr. nabavka kancelarijskog i potronog materijala ne smije premaiti XXX ),raunarska oprema (npr. projekat se mora obaviti bez nabavke novog hardvera ili poeljno je da troak opreme predstavlja najmanje 33% budeta), finansijska sredstva (npr. ukupni budet projekta je XXXXX ) ili naknade izvoaima ne smiju prekoraiti XX% ukupnog iznosa).

Analiza uzroka i posljedice problema, njihovi ciljevi i ogranienja su prikazani u tabeli 2.6 [Fertalj & Kalpi, 2005]. Tabela 2.6.

ANALIZA UZROKA I POSLJEDICA

CILJEVI I OGRANIENJA SISTEMA Problem ili mogunost Uzroci i posljedice Ciljevi sistema Ogranienja sistema

1. Vrijeme odgovora na narudbu je neprihvatljivo dugo.

1. Promet je povean, a broj slubenika smanjen. Vrijeme obrade narudbe je isto.

2. Sistem previe zavisi o runom unosu. Pojedine vrijednosti se unose vie puta. Posljedica je da se narudbe obrauju due nego je potrebno.

3. Sredinji raunar radi na maksimumu svoga kapaciteta, ta se ogleda u sporijem radu aplikacije za unos narudbi. Budui da slubenici pokuavaju bre raditi, poveao se broj greaka pri unosu.

1. Smanjiti vrijeme unosa pojedine narudbe za 30%.

2. Runi unos narudbi svesti na 50% ukupnog broja.

3. Na ekranskoj formi raunara za runi unos smanjiti broj potrebnih pritisaka na tastaturu.

4. Prenijeti unos podataka sa sredinjeg raunara na PC.

5. Zamjeniti postojee obrasce za prikupljanje narudbi mrenim sistemom izmeu skladita i prodaje, tako da se eliminie upotreba

1. Broj zaposlenih u obradi narudbi se ne moe poveati.

2. Novi sistem mora biti kompatibilan sa postojeim Windows XX standardom.

3. Novi sistem mora biti kompatibilan sa ve odabranim sistemom za automatsku identifikaciju tapiastim kodom.


37

4. Obrasci za prikupljanje narudbi iz skladita nisu oblikovani za racionalno popunjavanje, to dodatno usporava unos narudbi.

papirne dokumentacije.

2.3.9. Modeliranje postojeeg sistema

Svrha modeliranja postojeeg sistema je preciziranje dometa projekta, kao i verifikacija razumijevanja problema i usaglaavanje percepcije sistema i stavova izmeu uesnika (korisnici, informatiari). Pri tome primjeniti taktiku skrivanja - zanemarivanja detalja i usredotoenje na ono to je zaista vano (npr. izbjegavanje prouavanja tehnikih detalja u ranim fazama).

Kreirati globalni, okvirni, grubi model sistema i to: model organizacije i resursa (kontekst, organizaciona struktura, prostorni raspored sredstava), globalni model procesa (funkcionalna dekompozicija, tok kljunih poslovnih procesa, kruenje dokumenata i protok informacija) i globalni model entiteti-veze (kategorije podataka, klase podataka (ne klase objekata!)).

2.3.10. Planiranje informacionog sistema

Planiranje informacionog sistema se sastoji od analize problema, povoljnih prilika i moguih rjeenja problema, definisanja ciljeva i zadataka informacionog sistema, kao i procjena ogranienja. Tu spada ponovna procjena i preciziranje opsega projekta, a po potrebi i revizija glavnog plana.

Tokom izvoenja projekta esto se dogaa polagano, ali znaajno, poveanje obima uslijed pogrene procjene ili razliitog tumaenja ciljeva izmeu korisnika i izvoaa, tzv. puzei domet projekta. Granice projekta moraju biti definisane to je mogue preciznije. Time se kasnije poveanje projekta, moda, nee ukloniti, ali e se barem moi kontrolisati.

Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspjenosti. Planira se prototip koji se moe uspjeno i brzo realizirati (npr. 3 do 9 mjeseci, u zavisnosti o veliini itavog projekta). Poeljno je realizovati takav prototip koji e omoguiti procjenu moguih tehnikih rjeenja IS


38

(alternativa) i prijedlog najboljeg rjeenja, a pored toga vratiti uloenu investiciju. Na kraju se (opet!) moe oekivati pokretanje, odbacivanje, odgaanje ili prilagavanje (ostalih, pojedinih) projekata.

Tabela 2.7 prikazuje idejno rjeenje plana razvoja IS. Tabela 2.7.

Saetak - Saetak prijedloga - Saetak problema, mogunosti i

direktiva - Kratki navod ciljeva unapreenja

sistema - Kratki navod sadraja izvjetaja

Poznate informacije - Popis odranih razgovora i

kordinisanih grupnih sastanaka - Popis ostalih izvora informacija - Opis tehnika koritenih u analizi

Pregled postojeeg sistema - Strategijske odrednice - Modeli postojeeg sistema * Model interfejsa (kontekst) * Model resursa (prostor) * Model procesa (funkcija) * Model podataka (kategorije)

Analiza postojeeg sistema * problemi, mogunosti i analiza uzroka

i posljedica za pojedine elemente - Performanse - Informacije - Ekonomija - Kontrola - Djelotvornost - Usluge (servisi)

Detaljni prijedlozi - Ciljevi i prioriteti unapreenja sistema - Preporuke unapreenja sistema - Plan projekta * Precizirati domet projekta * Revidirati glavni plan * Detaljni plan za slijedei korak

Dodaci - Modeli sistema (ako nisu dio studije) - (ostala dokumentacija prema potrebi)

2.4. Modeli razvoja informacionih sistema

2.4.1. Sekvencijalni (vodopadni) model razvoja informacionog sistema

Polazna pretpostavka metodologije ivotnog ciklusa je da se faze razvoja realizuju

strogo sekvencijalno, istovremeno za cijeli programski proizvod. Kada je rije o informacionom sistemu, tada se svaka faza istovremeno primjenjuje na svaki od podsistema, u okviru identifikovane arhitekture IS. Istovremeno se, takoe, projektuje i shema baze podataka IS. Realizacija naredne faze ne zapoinje dok se tekua faza ne zavri. Greke iz prethodnih faza, otkrivene u tekuoj, zahtjevaju da se one otklone i dokumentuju vraanjem u prethodne i prolaskom kroz sve faze koje slijede iza faze


39

gdje je greka napravljena. Ovakav nain primjene metodologije ivotnog ciklusa i strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primjene metodologije ivotnog ciklusa. Dobre strane ovog pristupa su: integrisanost IS, dobra dokumentovanost i praktino istovremeni zavretak svih podsistema IS. Zahvaljujui dobroj dokumentovanosti pojednostavljeno je odravanje aplikacija IS. Takoe, ovaj pristup daje dobre garancije da e, u konanom vremenu, doi do zadovoljavajueg rjeenja programskog proizvoda, ime se smanjuje rizik od neuspjeha razvoja.

Sekvencijalni pristup, pored dobrih osobina, ne daje uvijek prave efekte kada je u pitanju ostvarenje prethodno definisanih ciljeva. Uzroci su viestruki, a neki od njih su slijedei [Mogin et al. 2000]:

1. U sekvencijalnom modelu primjene metodologije ivotnog ciklusa krajnji korisnik nije dovoljno ukljuen u proces razvoja programskog proizvoda;

2. Izmeu poetka projekta i prvih operativno primjenljivih rezultata kod korisnika vremenski interval je dosta dug;

3. esto se javlja potreba da se precizni, metodoloki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva;

4. Umjesto da to bude postupno, postoji potreba da se u razvoj IS odjednom uloe znaajna finansijska sredstva.

Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisniki zahtjevi esto otkrivaju tek u fazi uvoenja aplikacije u upotrebu, to je jako kasno jer se korekcija greaka i odravanje komplikuju, a produava se vrijeme potrebno za dobijanje konanog rjeenja aplikacije. U cilju izbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni, inkrementalni, spiralni, zvjezdasti, V model i drugi manje znaajni modeli. Mogu se izdvojiti slijedee varijante sekvencijalnog (vodopadnog) modela: klasini vodopadni model, pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj.

Klasini vodopadni model (slika 2.1(a)) redoslijedno (sekvencijalno) napreduje iz faze u fazu. Nisu dozvoljene naknadne promjene rezultata prethodnih faza. Prikladan je velikim projektima (investicijama), za dobro definisano okruenje, gdje postoje razraene procedure rune obrade ili raunarski sistem koji treba unaprijediti. Nedostaci ovog modela su izraeni u sluaju greaka ili novih/promijenjenih zahtjeva, kao i u potrebi uvoenja prema gore (bottom up) modula, podsistema i sistema. Sistem nije upotrebljiv dok nije u potpunosti gotov. Problem predstavlja i predodba o proizvodu na osnovu pisane specifikacije.


40

Pseudostrukturirani vodopadni model (slika 2.1(b)) sadri povratnu vezu i mogunost promjene rezultata prethodnih faza. Ovaj model razvoja IS omoguava primjenu tehnika strukturiranog programiranja.

(a) (b)

Slika 2. 1. Uporedni prikaz klasinog razvoja (a), pseudostrukturiranog i radikalnog razvoja (b).

Radikalni (strukturirani) razvoj (slika 2.1(b)) omoguava da se aktivnosti

razliitih faza mogu obavljati istovremeno. Dozvoljava koritenje rjenika podataka, programskih jezika etvrte generacije (4GL) i generatora aplikacija. Prikladan je kada se unaprijed ne zna konani izgled sistema.

2.4.2. V model razvoja informacionog sistema

V model razvoja IS (slika 2.2) omogua definisanje rezultata (proizvoda) pojedinih faza koji se proslijeuju u slijedee faze. Tim rezultatima se testiraju elementi IS na razliitim stepenima razvoja.

Analiza

Oblikovanje

Izrada

Evaluacija

Primjena

Analiza

Oblikovanje

Izrada

Evaluacija

Primjena


41

Slika 2.2. Primjer V modela.

2.4.3. Prototipski model razvoja informacionog sistema

Uz strukturirani pristup, prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se moe primjeniti u okviru metodologije ivotnog ciklusa. Prototipski pristup postaje u punoj mjeri praktino primjenljiv (iako je ideja o prototipskom pristupu u softverskom inenjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda, koji su integrisani sa okruenjem etvrte generacije. U zavisnosti od njegove namjene, mogu se uoiti slijedee tri vrste prototipskog modela. Model oponaanja (model u prirodnoj veliini), odnosno jednoekranski ili

Analiza

Specifikacija zahtjeva

Strukturirano oblikovanje

Model sistema

Detaljno oblikovanje

Dizajn modula

Kodiranje i testiranje

Scenariji aplikacije

Ogledni sluajevi

Ogledni sluajevi

Test prihvatljivosti

Testirani sistem

Integracija sistema

Testirani softver

Integracija modula

Testirani moduli


42

vieekranski model kojim se prikazuje kako e izgledati dio sistema (npr. interfejs), istraivaki model, za istraivanje dijelova sistema kako bi se provjerile neke kljune postavke (npr. provjera performansi odreenog modula) i, na kraju, ugradbeni model, tj. traenje razliitih naina na koje se sistem moe izgraditi (npr. koji sistem za upravljanje BP, programski jezik, raunari).

Prototip moe postupno, inkrementalnom doradom, da postane dio zavrnog IS. Prototipski razvoj podrazumijeva iteraktivni pristup, obino koritenjem 4GL. Radni model daje se na uvid korisniku i omoguava korisniku stvaranje slike o izgledu sistema. Korisnik daje primjedbe za popravak i poboljanja, ime se stie bolja slika o zahtjevima korisnika. Ujedno se uklanjaju mogua iznenaenja na kraju razvoja.

Savremeni softverski alati omoguavaju brzu izradu prototipa. Funkcionalni prototip dogradnjom moe da postane radni sistem (slika 2.3). Ovakav pristup razvoju IS je prikladan za male projekte. Prednosti su u iteracijama promjena (korisnici se smiju predomisliti), poveanju kreativnosti i brzini razvoja. Nedostaci su u tome to se zaboravlja da prototip nije pravi sistem, mogui neuspjeh zamjene prototipa radnim sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad nee biti napravljene, kao i nemogunost ispravne procjene i planiranja resursa.

Ogranieni/strukturirani razvoj prototipa slui kao sredstvo za odreivanje zahtjeva. Dobija se nefunkcionalni prototip (koji se ne moe koristiti u obavljanju radnih z

1190887507 p is

Documents