Visoka tehnolo ka kola strukovnih studijaStudijski program: Informacione tehnologije

Predmet: Menad ment informacionih sistema

Tema: Projektovanje informacionih sistema

-Seminarski rad-

Studenti:

Mentor:

SADR AJ 1. Planiranje razvoja informacionog sistema .............................................. 1 1.1. Modaliteti razvoja informacionog sistema ............................................. 3 2.1. Analiza izvodljivosti, tro kova i koristi projekta ...................................... 7 2.2. Strategija i planiranje razvoja informacionog sistema ............................ 10 2.3. Modeli razvoja informacionih sistema .................................................... 16 2.4. Metodologija razvoja informacionih sistema .......................................... 27 2.5. Savremeni postupci razvoja informacionog sistema .............................. 29 Literatura.31

2

1. Planiranje razvoja informacionog sistema1.1. Modaliteti razvoja informacionog sistema1.1.1. Vlastiti razvoj informacionog sistema

Postoje razli iti modaliteti razvoja informacionog sistema. U ovom seminarskom e biti razmatrani modaliteti razvoja koji se naj e e koriste. Razvoj vlastitim informati kim snagama podrazumeva osposobljavanje i anga ovanje netehni kog osoblja, kao i povremeno ili dugoro no anga ovanje spoljnih saradnika. Prednosti ovakvog pristupa su fleksibilnost, kreativnost i pove anje stru nosti vlastitog osoblja. Nedostaci su da ovaj pristup zahteva zna ajno vreme i napor, razvoj je skuplji i dugotrajniji i mo e pove ati gomilanje zaostalog posla. Razvoj vlastitim snagama ima smisla kada se radi o programskoj podr ci koja je posebnost organizacije, takva da ne postoje gotova re enja na tr i tu ili takva da organizacija pomo u nje posti e komparativnu prednost u odnosu na konkurenciju. Postoje dodatni ili posebni razlozi kao to su pove ana tajnost podataka i poslovnih procesa ili pove ana za tita IS. 1.1.2. Spoljni razvoj informacionog sistema Anga ovanje spoljnih saradnika za razvoj informacijskog sistema, ili njegovih delova, podrazumeva pru anje pomo i u obrazovanju radnika informati ke struke, pomo pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja. Tako e se podrazumeva kodiranje (generisanje) celovitog programskog sistema, upravljanje izvo enjem i/ili nadzor izvo enja, kao i konsultativna pomo prilikom ugradnje slo enih poslovnih funkcija. Varijante su slede e: ugovoreni razvoj, odnosno ugovara se isporuka gotovog proizvoda ili dugoro na saradnja sa isporu iocem, uz izdvajanje vlastitog informati kog odela u glavnog izvo a a. Mogu a varijanta je i nala enje strate kog partnera na du i vremenski period, npr. softverske ku e. Prednosti su vi estruke. IS ili njegovi delovi izra uju se po meri naru ioca, Sistem je prilago en organizaciji/poslovanju, a po mogu nosti treba istovremeno pobolj ati organizaciju/poslovanje poslovnog sistema.3

Ovakav razvoj podrazumeva dugotrajan postupak i odgovaraju u visoku cenu. Nedostaci i rizici su tako e prisutni. Dolazi do gubitka poverljivih informacija, gubitka nadzora nad sada njim i/ili budu im razvojem, kao i gubitak vlastite stru nosti. Nu no je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogu nost odlu ivanja. 1.1.3. Nabavka gotovih aplikacija Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe. Po eljno je da se mogu prilagoditi potrebama. Primeri 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 specijalisti ke aplikacije za odre ene namene. Mogu se nabaviti slede i sistemi za upravljanje poslovanjem, koji nose komercijalne nazive: Enterprise Resource Planning (ERP) systems, SAP, BAAN. Celoviti sistemi za podr ku poslovanju, uglavnom, podr avaju slede e aplikacije: finansijsko poslovanje , proizvodnju (manufacturing), robno-materijalno poslovanje (material management/distribution), upravljanje ljudskim resursima i plate (CG management, payroll). 1.1.4. Nabavka poslovnih aplikacija Slede i modalitet razvoja IS je nabavka i prilago avanje postoje ih doma ihposlovnih aplikacija. Prednost ovog pristupa je uskla enost va e im uslovima, npr. propisima, ta olak ava prilago avanje aplikacija organizaciji/poslovanju. Nedostatci su nepostojanje ili manjkavost pojedinih komponenti, mestimi na tehnolo ka zastarelost, prekapacitiranost dobavlja a. Modaliteti ovakvog pristupa su slede i: otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz samostalno odr avanje. Nabavka gotovih stranih poslovnih aplikacija, tako e, ima svoje prednosti i nedostatke. Prednosti su rasko na funkcionalnost i kompatibilnost sa svetskim poslovnim standardima, dok se nedostatci ogledaju u neprilago enosti doma im uslovima i konkretnoj organizaciji/poslovanju, ta zahteva istovremeno prilago avanje programske opreme i promenu organizacije/poslovanja. Prilago avanje se obavlja sli no razvoju, ta mo e uzrokovati da re enja gube mogu u komparativnu prednost (brzinu i lako u primene). Glomazni paketi mogu4

zahtevati anga ovanje velikog broja konsultanata. Mogu i modalitet nabavke je da se prilago avanje vr i vlastitim snagama uz savetovanje i pomo dobavlja a. 1.1.5. Kriterijumi za dono enje odluke o nabavci Op ti kriterijumi za dono enje odluke o razvoju IS su: cena, funkcionalnost, kapacitet, brzina, broj korisnika, mogu nost obuke i trajne podr ke, kredibilitet i odr ivost dobavlja a na tr i tu, to se dokazuje referensama, elasti nost, tj. mogu nost prilago avanja i prepravki, raspolo ivost dokumentacije. U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost, interoperabilnost), tehni ke mogu nosti (Client-Server, OLTP, OLAP), referense dobavlja a (prisutnost dobavlja a na lokalnom tr i tu) i podr ka korisnicima. Pod podr kom korisnicima se podrazumjeva: kolovanje, tehni ke konsultacije, odr avanje (dinamika razvoja i mogu nosti nabavke novih verzija), blagovremeno otklanjanje problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitih aplikacija. 1.1.6. Nabavka izvedenog programskog koda Prednosti nabavke izvedenog koda su: izvedeni kd je jeftiniji, brigu I odgovornost o njegovom odr avanju preuzima isporu ilac, uz izuzetak nekih op te 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 izvedenog koda, obzirom na korisnika, su: izvedeni kd podrazumijeva potpunu zavisnost od isporu ioca, ne postoji mogu nost prilago avanja specifi nim vlastitim potrebama, osim putem posebnog dogovora sa isporu iocem. Dodatna prilago avanja lako mogu postati predmetom ucjene. Tako e, ne postoji mogu nost razvoja programske opreme vlastitim snagama. 1.1.7. Nabavka izvornog programskog koda Prednosti nabavke izvornog programskog koda su znatne. Izvorni kod omogu ava stalni razvoj i pra enje vlastitih posebnosti, to se mo e pokazati kao prednost u odnosu na konkurenciju. Osim toga, pru a mogu nost prilag avanja vlastitim potrebama, ta daje elasti nost pri promjenama organizacije poslovanja. Nema bojazni da e nakon prve potrebne izmjene prestati upotreba IS zbog toga to isporu ilac nije trenutno dostupan, postavlja nerazumne uslove ili je u5

me uvremenu nestao sa tr i ta. Uvidom u kvalitetna gotova rje enja poma e se razvoju vlastitih informati kih radnika. Male narud be izvornog koda su, tako e, prisutne. Izvorni kd je vi estruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. Naru ilac se izla e isku enju da nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad i izgubi pravo na odr avanje. Odr avanje je skuplje ukoliko se radi o programskoj opremi podlo noj promjenama. Sni enje cijene izvornog koda mo e se posti i automatizacijom kodiranja, upotrebom generatora izvornog koda. Preporuke za izbor programskog koda su slede e. Izvedeni kod treba preporu iti u slede im slu ajevima: kada se radi o standardnim, masovno prodavanim aplikacijama, kada korisnik nema vlastite informati ke stru njake, kada se radi o visokostru nim aplikacijama koje se ne e mnogo mijenjati, a korisnik nema namjeru da se baviti detaljima te struke, kada korisnik nema novaca ili elje za vlastiti informati ki razvoj. Izvorni kd treba preporu iti onda: kada programska oprema predstavlja strate ku investiciju, kada korisnik raspola e kompetentnim informati arima ili ima motiva razvijati vlastitu informati ku djelatnost, kada isporu ilac ne mo e preuzeti obavezu odr avanja ili ne mo e garantovati da e ostati na tr i tu, kada na tr i tu ne postoji IS koji odgovara potrebama, ne mo e se povoljno kupiti sli an, a korisnik raspola e vlastitim informati kim snagama dovoljnim za projektovanje novog. 1.1.8. Izbor modaliteta razvoja Odre ivanje mogu ih rje enja podrazumjeva identifikaciju re enja na osnovu poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija ra unarske opreme i programske podr ke, te odabrana tehnolo ka arhitektura, dok su izlazi mogu a rje enja novog sistema i njihove karakteristike. Analiza izvodljivosti alternativnih rje enja se sastoji od procjena alternativa obzirom na tehni ku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi su karakteristike mogu ih rje enja, karakteristike i cijene hardvera i softvera, referense I uslovi dobavlja a, a izlazi analiza izvodljivosti za svako mogu e rje enje. Prijedlog rje enja sistema koji e se oblikovati i ugraditi se donosi na osnovu izbora onog rje enja koje ima6

najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti, plan projekta, procjena veli ine projekta, a izlazi prijedlog sistema sa usvojenim promjenama dizajna predlo enog sistema.1.1.9. Izbor dobavlja a proizvoda ili usluga

Definisanje kriterijuma i opcija, kod izbora dobavlja a proizvoda ili usluga, vr i se na osnovu slijede ih ulaza i izlaza. Ulazi sadr e specifikacije zahtjeva za programsku podr ku i ra unarsku opremu: funkcionalnost, dodatna svojstva, klju ne parameter performansi.. . Izlazi su lista potencijalnih dobavlja a proizvoda ili usluga, te kriterijumi za izbor. Kod prikupljanja ponuda treba potencijalnom dobavlja u uputiti zahtjev za dostavljanje referensi (kada postoje razli iti dobavlja i i/ili proizvodi, a eli se odabrati najbolje rje enje, prikupljaju se ponude koje su skup referensi"), kao i zahtjev za dostavljanje ponude sa informacijama o konfiguracijama, cenama, odr avanju (kada se odre eni proizvod mo e nabaviti od razli itih dobavlja a). Izbor ponuda se obavlja slijede im redoslijedom: (1) provjera sadr aja ponuda, (2) izrada rang liste, po eljno odvojenim ocjenjivanjem pojedina nih ponuda, (3) izbor objektivno najboljeg ponu a a (to se, na alost, vrlo te ko uklapa u zakonske odredbe po kojima treba ta no specificirati to se eli, a mora se kupiti najjeftinije). Ugovaranje posla se zavr ava sklapanjem ugovora koji defini e uslove saradnje, isporuke i naplate, integracije sa postoje im sistemom, odr avanja i sli no. Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zami ljeno. Izvr ilac projekta treba biti stimulisan proporcionalno ostvarenoj, u praksi dokazanoj i od korisnika prihva enoj, funkcionalnosti sistema. 2.1. Analiza izvodljivosti, tro kova i koristi projekta2.1.1. Analiza izvodljivosti projekta

Za pojedine projekte se vr i analiza njihove izvodljivosti, odnosno mjerenje korisnosti, prakti nosti i isplativosti projekta IS. Ove analize treba da se vr e tokom planiranja, ali i kasnije, npr. nakon faze sistemske analize. Nakon odluke o pokretanju projekta slo enost i opseg projekta se mogu promijeniti, te po etno izvodljiv projekat mo e postati neizvodljiv. Prakti no gledano, to nost procjene izvodljivosti raste sa dubinom analize. Studija izvodljivosti (feasibility study) sadr i: (1) detaljnu provjeru projekta, koju provode sistem analiti ari, (2) procjenu da li je projekat izvodljiv obzirom na raspolo ivasredstva, (3) procjenjuje se da li projekat omogu ava pobolj anja, (4) radi se izvje taj o izvodljivosti i prezentira se relevantnim u esnicima radi7

komentara i mi ljenja (mo e biti dio idejnog re enja), (5) eventualni povratak u studiju izvodljivosti, odnosno revidirani izvje taj.2.1.2. Izvje taj o izvodljivosti projekta

Izvje taj o izvodljivosti projekta sa injavaju slijede e analize: organizaciono - operativna izvodljivost, tehni ko - tehnolo ka izvodljivost, vremenska izvodljivost, ekonomska izvodljivost. Analiza organizaciono - operativne izvodljivosti projekta sadr i procjenu hitnosti re avanja problema (planiranje), kao i procjenu prihvatljivosti rje enja (kasnije faze). Tu se neminovno name u i slijede a pitanja: Vrijedi li re avati problem? i Da li predlo eno rje enje re ava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno proto nost i odziv sistema u odnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, a urne, ta ne, korisne), ekonomiske aspekte (gde spadaju problemi tro kova i mogu nosti u teda), kontrolu (u prvom redu sigurnost i za titu podataka), efikasnost (odnosno pobolj avanje upotrebe raspolo ivih resursa: ljudi, opreme, novca, itd.), kao i usluge (po eljni i pouzdani servisi, elasti nost i mogu nost prilago avanja, zadovoljstvo). Ni ta manje bitni nisu ni odgovori na sliede a pitanja: Koji je stav korisnika prema re enju? i Da li e se sistem koristiti? Neophodni su podr ka uprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uo iti otpore ulozi ili tehni kim rje enjima sistema i predlo iti na ine njihovog otklanjanja. Krajnjeg korisnika treba na vreme pripremiti za promenu radnog okru enja i procedura. Procjena upotrebljivosti sistema se najlak e mo e izvr iti kori tenjem prototipa. Potrebno je pravilno oceniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primene sistema. Namjeniti jednostavni interfejs za po etnike i povremene korisnike, slo enije operacije za iskusne korisnike. Obezbediti da korisnik daje prednost ponu enom re enju u odnosu na postoje i na in rada. Analiza tehni ko - tehnolo ke izvodljivosti projekta sadr i procenu mogu ih re enja i alternativa. U prvom redu potrebno je izvr iti procjenu stanja na tr i tu opreme, procjenu postoje ih rje enja u drugim organizacijama (tamo gde je mogu e), kao i procjenu primjenjivosti razli itih tehnologija. Veoma bitna osobina je da se zastupljena tehnolo ka rje enja mogu jednostavno primijeniti. Raspolo ivost tehnologije podrazumijeva da se primjenljiva tehnologija mo e nabaviti. Ako je re o gotovom rje enju, ima li to re enje potrebne karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Ni ta manje bitno nije ni injenica da li postoje potrebni stru njaci za primjenu nove8

tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija mo e savladati. Analiza vremenske izvodljivosti projekta treba da d odgovor da li su predvi eni rokovi ostvarivi, obzirom na raspolo ivu stru nost. O ekivano vrijeme zavr etka mo e biti po eljno ili obavezno. Bolje je isporu iti ispravan sistem dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme! Ekonomska izvodljivost projekta e biti obja njena preko analiza i uporedbe ukupnih tro kova - koristi (cost-benefit analysis (CBA)). Tro kovi i korist mogu biti mjerljivi (npr. cena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr. zadovoljstvo korisnika, brzina odlu ivanja, dobra referensa). Finansijski tro ak i korist se mogu izraziti formulama: (1) razlika korist tro ak u nekom razdoblju (Net Present Value), (2) povrat investicije (korist tro ak)/tro ak (Internal Rate of Return), (3) trenutak u kojem korist nadvlada tro ak (Payback Point). CBA ra una tro kove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Dana nja vrijednost onoga to e postati $1,00 nakon n godina u budu nosti, ako se uzmu u obzir kamate I iznosi: PV = 1/(1 + I)n = (1 + I) n Razlika predstavlja kamatu koja se mo e zaraditi tim novcem ($ ozna ava nov anu jedinicu u bilo kojoj valuti).. Primeri: Tro kovi razvoja od $100.000 imaju trenutnu vrednost od $100.000 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 obi no dijeli sa du inom trajanja projekta kako bi se dobio godi nji ROI. Nizak ROI (~ manji od 10%godi nje)mo e pokazivati da je korist preniska da bi bila isplativa. Odnos tro ak/korist je prikazan tabelom 2.2 i grafi kim prikazom tabele. Primer: Analiza tro ak korist

9

Tabela 2.2.

2.2. Strategija i planiranje razvoja informacionog sistema 2.2.1. Definisanje poslovne strategije Poslovni ciljevi zahtjevaju definisanje poslovne strategije, odnosno planiranje akcija za postizanje ciljeva. Uprava defini e viziju i misiju poslovnog sistema, tj. strategijske ciljeve. Na osnovu strategijskih ciljeva se defini u poslovni ciljevi i odre uju zadaci, kojima e poslovni sistem u nekom razdoblju ispuniti svoju10

misiju. Pri tome se dobijaju odgovori: ta se eli posti i (prepoznatljivost, kvalitet, prihodi), kako eljeno posti i (promjenom organizacije, pobolj anjem sistema administracije), kako ostvariti pove anje proizvodnje ulaganjem u nove proizvodne tehnologije, uz istovremeno odr avanje kvaliteta proizvoda, i kako osigurati zadovoljstva i radne sposobnosti zaposlenih do kolovavanjem i mogu nostima napredovanja. inioci koji utje u na postavljanje ciljeva su slijede i: ograni enja (organizaciona, finansijska, zakonska), potrebe i elje uprave, poslovodstva, zaposlenih (ugled, uticaj), vremenski okviri, gde je kratkoro no razdoblje obi no manje od 2 godine, srednjoro no 2 do 5 godina i dugoro no vi e od 5 godina. 2.2.2. Planiranje razvoja informacionog sistema Planiranje razvoja informacionog sistema treba da d odgovor na slijede a pitanja: ime se poslovni sistem bavi (grana, proizvodi, tr i te, konkurencija)? Koji su problemi, zadaci i ciljevi poslovnog sistema? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slu e, koje i kakve podatke sadr e? Postoje li aplikacije iji je razvoj u toku? U kojem su stadijumu razvojni projekti? Koje su potrebne aplikacije? Koji su raspolo ivi resursi (osoblje, tehni ka sredstva, tehnologija)? Razlozi zbog kojih treba planirati IS su vi estruki. Na primjer, u Poslovnom sistemu koji se sastoji od vi e cjelina, kao to su Uprava, Finansije, Proizvodnja I Informatika esto postoji vi e razli itih tehni kih sistema ili aplikacija, takozvanih informati kih ostrva. To ima za posljedicu umno avanje informacija uz razli ito tuma enje u razli itim dijelovima, nepotpunost informacija, naro ito kada svaka Celina prikuplja samo njoj va ne informacije, problem povezivanja informacija pri poku aju celovite interpretacije, kao i problem razli itog poslu ivanja, razmjene podataka I odr avanja. 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 te ko izvodljivo u uslovima pre ivljavanja. Sastoji se od uspostave smjera i prioriteta uskla ivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podr ka promjeni poslovnog sistema i poslovnih procesa. Jo se mogu navesti primene metoda analize i dizajna za prou avanje poslovnog sistema, sa ciljem definisanja op teg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi.11

U praksi situacija je slijede a. Umjesto prema strategijskom planu, poslovni sistem se "dovodi u red" tokom informatizacije i pomo u informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budu i da se dizajnom sistema predla u ili name u pobolj anja. 2.2.3. Odabir i pokretanje projekta Prvenstveno pokreta i promjena su korisnici, odnosno njihovo nezadovoljstvo aplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokuje nedostatak podataka, to nagla ava potrebu uvo enja 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). Pokreta i promjena mogu biti I pokazatelji poslovanja (npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno pove anje tro kova), kao i zastarila tehnologija (npr. zastario razvojni alat i prisutan problem njihovog odr avanja, zastario interfejs Internet-a, zastarile BP). Odabir projekta se vr i na osnovu prijedloga projekta, koga sastavlja sponzor projekta (organizator, predlaga ). Prijedlog projekta sadr i sa etak projekta (naziv, cilj, svrha), poslovne potrebe, o ekivanu funkcionalnost, o ekivanu korist, kao i posebnosti i ograni enja. Radna grupa za odabir projekta odobrava projekat. Prije pokretanja projekta potrebno je izvr iti snimak stanja, odnosno prethodno istra ivanje, tj. istra ivanje koje prethodi projektu, prepoznavanje problema i potreba, kao i tra enje odgovora na pitanje "Da li je projekt vrijedan pa nje?". Slijedi faza prou avanja problema, produbljivanje snimka, postavljanje ciljeva, prijedlozi rje enja, procjena izvodljivosti, tra enje odgovora na pitanja "Da li su problemi vrijedni re avanja? i "Da li je gradnja isplativa?". Planiranje projekta, odnosno organizacija i upravljanje projektom, sastoji se od slijede ih aktivnosti: izrada plana rada, oformljenje projektantske ekipe (uklju ivanje u esnika iz razli itih djelatnosti, npr. radnici razli itih poslovnih podru ja ili organizacijskih jedinica, uprava, vanjski konsultanti), pri emu je va no osigurati predanost u esnika zajedni kom cilju, i, na kraju, uspostava upravljanja i nadzora projekta.

12

2.2.4. Snimanje stanja Snimanje stanja omogu ava brzo istra ivanje i evaluaciju problema, mogu ih prilika i direktiva. Pod problemom se podrazumjeva ne eljena situacija koja sprje ava potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadataka. Mogu a prilika je mogu nost pozitivne promjene, ak i kada ne postoji problem, dok je direktiva zahtjev ili ograni enje koji su nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim uticajem (npr. zakon). Mogu e je opciono provo enje procjena mogu ih tehni kih rje enja, pri emu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazama, kao i odre ivanje dosega projekta i po etnog plana projekta. Snimanje poslovnog sistema se sastoji od pregleda poslovnih planova, ako takvi postoje ili nisu tajna, prikupljanja informacija, naj e e intervjuisanjem korisnika, vlasnika i vi ih rukovodilaca, kao i evidentiranja problema i prijedloga. Snimanje stanja obuhvata identifikaciju korisnika i opsega postoje eg (postoje ih) IS, uo avanje problema i nedostataka postoje eg IS, procjenu potreba za nadogradnjom (pobolj anjima), pocjenu potreba za izmjenama (prilago avanjem i popravkama) I procjenu potreba za izradom novih IS ili podsistema IS .2.2.5. Planiranje projekta

Planiranje projekta podrazumjeva odre ivanje namjene projekta i izdvajanje zadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Domet I razgrani enje projekata ili podprojekata (System boundary, Constraints, Objectives, Permissions, End products (SCOPE)) daje odgovore na slijede a pitanja: Koje su granice sistema? Koji e zahtjevi biti ispunjeni? ta ne mo e biti napravljeno? ta ne e biti napravljeno? Ko e, kako i pod kojim uslovima mo i koristiti rje enje? Kako se mjeri ili odre uje uspjeh (neuspjeh)? Kako e se znati da je projekat gotov? Vremensko planiranje obuhvata odre ivanje prioritetnih zadataka i vremenskih okvira prioriteta. Izrada po etnog (preliminarnog) plana razvoja IS zapo inje podjelom projekta u manje cjeline i odre ivanje redoslijeda realizacije pojedinih podprojekata. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada I raspodjela poslova, kao i odre ivanje prioriteta. Nastoji se prona i takva podjela posla na cjeline da cjelinu mo e obaviti jedna osoba ili ekipa, da se cjelina mo e obaviti jednom metodom i posao zavr i jednim13

proizvodom (dokumentom, aplikacijom ili podsistemom). Po etni plan razvoja IS sadr i nazive podprojekata i omogu ava doradu I a uriranje u skladu sa napretkom projekta. Mo e se koristiti za prezentaciju projekta radi tra enja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta mo e poslu iti kao interni ugovor projekta .

Primer: Po etni (preliminarni) plan informacionog sistema 1. Nabavka sistema za upravljanje bazama podataka; 2. Obuka op te informati ke pismenosti za rukovodioce odjeljenja; 3. Obuka za programere u jeziku za upravljanje bazama podataka; 4. Obuka za administratore baze podataka; 5. Izrada prototipa programske podr ke za i-tu fazu realizacije; 6. Izrada - verzije aplikacije; 7. Testiranje - verzije u informacionim sistemima; 8. Uklanjanje uo enih nedostataka i izrada - verzije programa; 9. Obuka za odabrane korisnike na - verziji; 10. Testiranje kod korisnika u paralelnom radu sa dosada njim programom; 11. Uklanjanje nedostataka i izrada stabilne verzije; 12. Zamjena dotada njeg programa novim programom, uz preuzimanje podataka; 13. Obuka za ostale korisnike; 14. Uvo enje kori tenja programa kod ostalih korisnika; 15. Obuka za upoznavanje sa mogu nostima programa za odabrano poslovodstvo; 16. Prikupljanje primjedbi korisnika i novih zahtjeva; 17. Izrada slijede e faze/verzije programa. Povratak na ta ku 5). 2.2.6. Odre ivanje poslovnih ciljeva Za projekte koji pro u po etnu selekciju vr i se produbljivanje analize problema. Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni re avanja i da li je gradnja IS isplativa. Vr i se detaljnija analiza problema, njihovih uzroka i posljedica, imaju i na umu misao: "Ne poku avaj popraviti prije nego shvati kako radi!" Tako e je potrebno izvr iti analizu poslovnih procesa odgovaraju i na pitanja: Koji su najve i problemi? Koja su mogu a rje enja problema? Kako informatizacija mo e pomo i? kao i grubo modeliranje postoje eg sistema. Mogu se koristiti razli ite formalne metode, od kojih su najzna ajnije:14

1. Analiza kriti nih faktora uspjeha (Critical Success Factors (CSF)), odnosno inilaca, kojima poslovodstvo posve uje posebnu pa nju. 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 uo avanje podataka povezanih sa procesima; 3. Analiza izvodljivosti i procjena tro kova - koristi. 2.2.7. Uzroci i posljedice problema, ciljevi i ograni enja Istra ivanje uzroka problema, koji mogu biti raznovrsni, se mogu ilustrovati na slijede em jednostavnom primjeru: Zadatak analiti ara je da razdvoji uzroke i posljedice problema. Drugi primjer: Dug red u videoteci nije poseban problem, a mo e biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica ru nog unosa podataka i izdavanja ra una. U razmatranom primjeru analiti ar 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 mogu ih ciljeva: pomo i reorganizaciju u tr i no orijentisanom poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima I mjestu nastanka svakog tro ka u sistemu, uskladiti hijerarhiju odlu ivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utro ak novca za ... . Ograni enja mogu biti slijede a: osoblje (npr. odjel informatike smije zaposliti najvi e tri stalno zaposlena radnika), materijalni tro ak (npr. nabavka kancelarijskog I potro nog materijala ne smije prema iti XXX ), ra unarska oprema (npr. projekat se mora obaviti bez nabavke novog hardvera ili po eljno je da tro ak opreme predstavlja najmanje 33% bud eta), finansijska sredstva (npr. ukupni bud et projekta je XXXXX ) ili naknade izvo a ima ne smiju prekora iti XX% ukupnog iznosa). 2.2.8. Modeliranje postoje eg sistema Svrha modeliranja postoje eg sistema je preciziranje dometa projekta, kao i verifikacija razumijevanja problema i usagla avanje percepcije sistema i stavova izme u u esnika (korisnici, informati ari). Pri tome primjeniti taktiku skrivanja zanemarivanja detalja i usredoto enje na ono to je zaista va no (npr. izbjegavanje prou avanja tehni kih detalja u ranim fazama).15

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

2.2.9. Planiranje informacionog sistema Planiranje informacionog sistema se sastoji od analize problema, povoljnih prilika i mogu ih rje enja problema, definisanja ciljeva i zadataka informacionog sistema, kao I procjena ograni enja. Tu spada ponovna procjena i preciziranje opsega projekta, a po potrebi i revizija glavnog plana. Tokom izvo enja projekta esto se doga a polagano, ali zna ajno, pove anje obima uslijed pogre ne procjene ili razli itog tuma enja ciljeva izme u korisnika i izvo a a, tzv. puze i domet projekta. Granice projekta moraju biti definisane to je mogu e preciznije. Time se kasnije pove anje projekta, mo da, ne e ukloniti, ali e se barem mo i kontrolisati. Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspje nosti. Planira se prototip koji se mo e uspje no i brzo realizirati (npr. 3 do 9 mjeseci, u zavisnosti o veli ini itavog projekta). Po eljno je realizovati takav prototip koji e omogu iti procjenu mogu ih tehni kih rje enja IS (alternativa) i prijedlog najboljeg rje enja, a pored toga vratiti ulo enu investiciju. Na kraju se (opet!) mo e o ekivati pokretanje, odbacivanje, odga anje ili prilag avanje (ostalih, pojedinih) projekata. 2.3. Modeli razvoja informacionih sistema2.3.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 re o informacionom sistemu, tada se svaka faza istovremeno primjenjuje na svaki od podsistema, u okviru identifikovane arhitekture IS. Istovremeno se, tako e, projektuje I sema baze podataka IS. Realizacija naredne faze ne zapo inje dok se teku a faza ne zavr i. Gre ke iz prethodnih faza, otkrivene u teku oj, zahtjevaju da se one otklone I dokumentuju vra anjem u prethodne i prolaskom kroz sve faze koje slijede iza fazegde je gre ka napravljena. Ovakav na in primene metodologije ivotnog ciklusa i16

strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primene metodologije ivotnog ciklusa. Dobre strane ovog pristupa su: integrisanost IS, dobra dokumentovanost i prakti no istovremeni zavr etak svih podsistema IS. Zahvaljuju i dobroj dokumentovanosti pojednostavljeno je odr avanje aplikacija IS. Tako e, ovaj pristup daje dobre garancije da e, u kona nom vremenu, do i do zadovoljavaju eg rje enja 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 vi estruki, a neki od njih su slijede i [Mogin et al. 2000]: 1. U sekvencijalnom modelu primene metodologije ivotnog ciklusa krajnji korisnik nije dovoljno uklju en u proces razvoja programskog proizvoda; 2. Izme u po etka projekta i prvih operativno primjenljivih rezultata kod korisnika vremenski interval je dosta dug; 3. esto se javlja potreba da se precizni, metodolo ki 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 ulo e zna ajna finansijska sredstva. Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisni ki zahtjevi esto otkrivaju tek u fazi uvo enja aplikacije u upotrebu, to je jako kasno jer se korekcija gre aka i odr avanje komplikuju, a produ ava se vrijeme potrebno za dobijanje kona nog rje enja aplikacije. U cilju izbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni, inkrementalni, spiralni, zvjezdasti, V model i drugi manje zna ajni modeli. Mogu se izdvojiti slijede e varijante sekvencijalnog (vodopadnog) modela: klasi ni vodopadni model, pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj. Klasi ni 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 okru enje, gde postoje razra ene procedure ru ne obrade ili ra unarski sistem koji treba unaprijediti. Nedostaci ovog modela su izra eni u slu aju gre aka ili novih/promijenjenih zahtjeva, kao i u potrebi uvo enja prema gore (bottom up) modula, podsistema i sistema. Sistem nije upotrebljiv dok nije u potpunosti gotov. Problem predstavlja i predod ba o proizvodu na osnovu pisane specifikacije. Pseudostrukturirani vodopadni model (slika 2.1(b)) sadr i povratnu vezu i mogu nost promjene rezultata prethodnih faza. Ovaj model razvoja IS omogu ava primjenu tehnika strukturiranog programiranja.17

(a)

(b)

Slika 2. 1. Uporedni prikaz klasi nog razvoja (a), pseudostrukturiranog i radikalnog razvoja (b).Radikalni (strukturirani) razvoj (slika 2.1(b)) omogu ava da se aktivnosti razli itih faza mogu obavljati istovremeno. Dozvoljava kori tenje rje nika podataka, programskih jezika etvrte generacije (4GL) i generatora aplikacija. Prikladan je kada se unaprijed ne zna kona ni izgled sistema. 2.3.2. V model razvoja informacionog sistema V model razvoja IS (slika 2.2) omogu a definisanje rezultata (proizvoda) pojedinih faza koji se proslije uju u slijede e faze. Tim rezultatima se testiraju elementi IS na razli itim stepenima razvoja.

18

Slika 2.2. Primer V modela. 2.3.3. Prototipski model razvoja informacionog sistema Uz strukturirani pristup, prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se mo e primjeniti u okviru metodologije ivotnog ciklusa. Prototipski pristup postaje u punoj mjeri prakti no primjenljiv (iako je ideja o prototipskom pristupu u softverskom in enjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda, koji su integrisani sa okru enjem etvrte generacije. U zavisnosti od njegove namjene, mogu se uo iti slijede e tri vrste prototipskog modela. Model opona anja (model u prirodnoj veli ini), odnosno jednoekranski ilivi eekranski model kojim se prikazuje kako e izgledati dio sistema (npr. interfejs), istra iva ki model, za istra ivanje dijelova sistema kako bi se provjerile neke klju ne postavke (npr. provjera performansi odre enog modula) i, na kraju, ugradbeni model, tj. tra enje razli itih na ina na koje se sistem mo e izgraditi (npr. koji sistem za upravljanje BP, programski jezik, ra unari). Prototip mo e postupno, inkrementalnom doradom, da postane dio zavr nog IS.19

Prototipski razvoj podrazumijeva iteraktivni pristup, obi no kori tenjem 4GL. Radni model daje se na uvid korisniku i omogu ava korisniku stvaranje slike o izgledu sistema. Korisnik daje primjedbe za popravak i pobolj anja, ime se sti e bolja slika o zahtjevima korisnika. Ujedno se uklanjaju mogu a iznena enja na kraju razvoja. Savremeni softverski alati omogu avaju brzu izradu prototipa. Funkcionalni prototip dogradnjom mo e 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), pove anju kreativnosti i brzini razvoja. Nedostaci su u tome to se zaboravlja da prototip nije pravi sistem, mogu i neuspjeh zamjene prototipa radnim sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad ne e biti napravljene, kao i nemogu nost ispravne procjene i planiranja resursa. Ograni eni/strukturirani razvoj prototipa slu i kao sredstvo za odre ivanje zahtjeva. Dobija se nefunkcionalni prototip (koji se ne mo e koristiti u obavljanju radnih zadataka korisnika, a sadr i izgled ekranskih formi, menia i izvje taja), iji se razvoj u odre enom trenutku prekida i slijedi faza oblikovanja sistema (slika2.4).

Slika 2.3. Dijagram brzog razvoja prototipa.

20

Slika 2.4. Dijagram ograni enog/strukturiranog razvoja prototipa. Prakti ni aspekti primene prototipskog pristupa su vi estruki. Re je, uglavnom, o injenicama proisteklim iz iskustva u prakti noj primjeni prototipskog pristupa. Zbog toga, mo e se re i da su te injenice prije savjetodavnog, nego formalno strogog karaktera. Op te preporuke za primjenu prototipskog pristupa su slijede e [Mogin et al. 2000]: 1. Potrebno je, prije po etka primene prototipskog pristupa, precizno definisati standarde za izgled korisni kog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti sa mogu nostima odabranog CASE proizvoda, a generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi za programiranje i izgled korisni kog interfejsa, a sve u cilju postizanja bolje podr ke standarda;

21

2. Preporu uje se dekomponovanje cjeline IS na manje projekte, a zatim definisanje ni eg stepena me usobne integracije informacionih podsistema, u odnosu na klasi nu primjenu metodologije ivotnog ciklusa; 3. Kako korisnik ne bi bio doveden u zabludu, prilikom predaje korisniku prototipa aplikacije, obavezno ga upoznati sa injenicom da je u pitanju prototip a ne kona no rje enje. Pri tome treba precizirati na in upotrebe prototipa od strane korisnika; 4. Ne treba praviti vi e od tri prototipa jedne aplikacije, ukoliko je to mogu e, kako se ne bi produ ilo ukupno vrijeme izrade aplikacije i do lo do zamora krajnjih korisnika i projektantskog tima; 5. Treba se orijentisati prete no ka odbacivim prototipovima aplikacija, ukoliko se eli posti i to kra e vrijeme dolaska do prototipa, jer se time izrada samog prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatora koda, a koristi BP ija shema ne mora biti blizu kona nog rje enja); 6. Rade i sa prototipom aplikacije, korisnik treba da upotrebljava isklju ivo test podatke. On mora biti prethodno pripremljen na injenicu da, ukoliko u me uvremenu do e do prestrukturiranja sheme BP, uneseni test podaci mogu biti izgubljeni. Do gubitka test podataka mo e do i u situaciji kada je za njihovo prestrukturiranje potrebno ulo iti veliki napor, pa se od predstrukturiranja svjesno odustaje, ili kada je takvo prestrukturiranje nemogu e izvr iti zbog izmjena u shemi BP; 7. Prototip aplikacije mo e da predstavlja rje enje koje je dobijeno pomo u generatora koda nekog CASE proizvoda, prvenstveno na osnovu specifikacija konceptualnog nivoa. To zna i da se detalji, koji se defini u tek u implementacionom projektu, a nisu podr ani odgovaraju im generatorom, ne realizuju u okviru prototipa aplikacije kako slijede a generisanja ne bi uni tila tako isprogramirane cjeline. Na taj na in se posti e kratko vrijeme izrade prototipskog rje enja, ali ne i njegova potpuna funkcionalnost; 8. Ako je mogu e, u prototip aplikacije treba uklju iti i odgovaraju e izvje taje, jer tada korisnik lak e sagledava upotrebljivost aplikacije; 9. Re enja IS, istih ili sli nih poslovnih sistema, mogu biti dobra osnova u primjeni prototipskog razvoja. Pote ko e koje se mogu izbje i primjenom prethodno opisanih preporuka, a koje se mogu javiti prilikom primene prototipskog razvoja, su slijede e. Iterativni pristup mmo e dovesti do zamora krajnjih korisnika i projektanata. U cilju izbjegavanja problema, posebno treba obratiti pa nju na preporuke 3 i 4. Upotreba generatora koda je mogu a tek kada je formiran odgovaraju i dio sheme BP, a sa druge strane treba koristiti prototip aplikacije upravo da bi se pribavile sve relevantne informacije za strukturiranje sheme BP, to zna i da su ova dva zahtjeva me u sobom u suprotnosti.22

Primjena preporuka 5, 7 i 9 vodi ubla avanju ovog konflikta. Ako se radi o neodbacivim prototipovima (neodbacivi prototipovi se evolutivnim pode avanjem pretvaraju u kona na rje enja aplikacija), dorada izgenerisanih aplikacija mo e biti zamoran I vremenski zahtjevan posao. U cilju pribli avanja korisni kog interfejsa I funkcionalnosti generisane aplikacije kona nom rje enju, odnosno olak avanja postupka dorade izgenerisanih aplikacija, va no je preduzeti mjere predvi ene preporukom 1. Usagla avanje podataka, unesenih putem neodbacivog prototipa sabitno prestrukturiranom shemom BP, je esto vremenski zahtjevan i neizvjestan posao. U cilju izbjegavanja problema, posebno treba obratiti pa nju na preporuke 5 i 6. Intervencije na prototipu kod korisnika mogu stvoriti la ni utisak da je projektovanje IS trivijalan posao. Da bi se problem izbjegao, posebno treba obratiti pa nju na preporuku. 3. Primjena preporuke 9, ako za nju postoje uslovi, mo e biti u funkciji ubla avanja ovog problema. Ako je re o manje iskusnim korisnicima ili projektantima, mo e se dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva, odnosno pravovremeno identifikovanje informacionih zahtjeva, a da pri tome projektant ne uo i takav propust na vrijeme. Primjena preporuka 8 i 9 mo e pozitivno uticati na ubla avanje ili izbjegavanje ovog problema. Primena prototipskog pristupa IS je pokazala da on nije primeren razvoju integrisanih IS, jer insistiranje na brzom uvo enju aplikacija u funkciju dovodi do parcijalizacije IS. Zbog toga je va no obratiti pa nju na preporuku 2. Aplikacije koje se razvijaju samo primjenom prototipskog pristupa mogu postati izolovana ostrva. Imaju i u vidu tu injenicu, direktna primjena isklju ivo prototipskog pristupa je mogu a u slu aju da treba razvijati skoro izolovane podsisteme sa niskim stepenom me usobne integracije. Sa druge strane, o ekuje se da prototipski pristup do ivi svoju punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primene metodologije ivotnog ciklusa. U tom smislu, posebno zna ajnu ulogu ima evolutivni pristup razvoju IS. 2.3.4. Evolutivni model razvoja informacionog sistema Primjena IS mijenja pogled korisnika, a njegove potrebe se menjaju (rastu) tokom primene. Mo e se zaklju iti da IS raste sa poslovnim sistemom koga podr ava. Te iste pojave su prisutne i u razvoju IS. Jedan od osnovnih principa, na kome se zasniva primjena sekvencijalnog modela metodologije ivotnog ciklusa, je da realizacija naredne faze ne zapo inje dok se teku a faza ne zavr i. Uo ava se da upravo primjena ovog principa, kod nekih projekata, mo e intenzivirati negativne23

efekte primene metodologije ivotnog ciklusa. Evolutivni model primene metodologije ivotnog ciklusa, nasuprot sekvencijalnom, predvi a da je za odre ene faze ivotnog ciklusa programskog proizvoda mogu e da naredna faza zapo ne prije nego to se prethodna zavr i, to dovodi do odre enog stepena paralelizma u realizaciji tih faza. Prema tome, faze ivotnog ciklusa po inju da se sprovode iterativno. Do ove ideje se do lo na osnovu pretpostavke da ne treba odjednom realizovati kompletnu fazu i utro iti za to veliku koli inu vremena i novca, u situaciji kada se projektantske aktivnosti izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednu fazu treba da obezbjedi bolju osnovu za kasniji uspje ni zavr etak prethodne faze. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva, smatra se da njegova prakti na primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom, kao metodom za ta no utvr ivanje informacionih zahtjeva. Za utvr ivanje informacionih zahtjeva se prete no primenjuju odbacivi prototipovi. Primenjuju se dvije varijante evolutivnog pristupa. Prema prvoj, nakon utvr ivanja preciznih informacionih zahtjeva, rezultati konceptualnog i implementacionog projektovanja BP se integri u, a projekti podsistema se usagla avaju sa shemom integrisane BP. Drugim re ima, potprojekti se ponovo posmatraju kao cjelina i na njih se primenjuju, ne to izmjenjeni, koraci konceptualnog i implementacionog projektovanja, kao pri primjeni sekvencijalnog modela metodologije ivotnog ciklusa. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije ivotnog ciklusa i prototipskog pristupa, ali ne re ava problem dugog vremenskog intervala od po etka projekta do pojave prvih, operativno primjenljivih rezultata kod korisnika, i potrebe ulaganja finansijskih sredstava odjednom, a ne postupno. Prema drugoj varijanti, potprojekti se realizuju me usobno nezavisno i mogu biti fazno pomereni u vremenu. Na taj na in se re avaju problem dugog vremenskog intervala od po etka projekta do pojave prvih rezultata i potrebe ulaganja odjednom finansijskih sredstava. Ovakav nezavisan rad, me utim, mo e dovesti do ni eg stepena integrisanosti IS.

24

Slika 2.5. Mogu i evolutivni model primene metodologije ivotnog ciklusa. Na slici 2.5 je prikazan mogu i evolutivni model primene metodologije ivotnog ciklusa. Razvoj se vr i u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporu uje i koji generi e naredne zahteve.

2.3.5. Spiralni i zvezdasti model razvoja informacionog sistemaKod spiralnog modela primene metodologije ivotnog ciklusa, na po etku svake faze provodi se procjena rizika. Nastoje se utvditi mogu i rizici i razrije iti ih prije nastavka (uklanjanjem ili svo enjem na najmanju mogu u mjeru). U slu aju da je rizik prevelik, projekat se prekida (slika 2.6).

25

Slika 2.6. Dijagram procene rizika. Spiralni model metodologije ivotnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni tro ak, a na x osi svaka petlja spirale predstavlja jednu fazurazvoja i to: analizu, oblikovanje, izradu i integraciju. Faza mo e biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.

1. Analiza rizika, procjena alternativa; 2. Razvoj i verifikacija slijede eg proizvoda; 3. Planiranje slijede e faze; 4. Pregled odre ivanje ciljeva, alternativa i ograni enja. (a) (b) Slika 2.7. Spiralni (a) i zvezdasti (b) model metodologije ivotnog ciklusa. Zvezdasti model, slika 2.7(b), ne uvodi stroga ograni enja u redosledu primene faza i koraka metodologije ivotnog ciklusa. To ne zna i da prirodnog redosleda26

izvr avanja odre enih koraka metodologije u ovom modelu nema, ve da on zavisi od vi e faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno in enjerstvo, ili potreba za rein enjeringom postoje eg IS, mogu zahtjevati potpuno obrnuti redoslijed primene faza ivotnog ciklusa (primjena "odozdo na gore").

2.4. Metodologija razvoja informacionih sistema2.4.1. Uvod u metodologiju razvoja informacionog sistema Metodologija se mo e definisati kao metoda + idejni pristup. Sadr i u sebi kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih filozofijom, koji potpoma u izgradnju informacionih sistema. Metodologija predstavlja skup na ela izrade IS, koji se u odre enoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland, 1994]. Komponente metodologije se mogu razvrstati u slijede ih pet ta aka: 1. Etape projekta; 2. Zadaci za svaku pojedinu etapu; 3. Izlazi (projektna dokumentacija); 4. Preporuke (vodi ) upotrebe odabranih tehnika i pomagala; 5. Na in upravljanja projektom i nadzorom projekta. Cilj metodologije je da omogu i sistemski postupak razvoja kojim e se mo i pratiti napredak, uspostavi komunikaciju izme u u esnika uklju enih u izgradnju IS (poslovodstvo, korisnici, analiti ari, programeri), osigura skup tehnika koje e omogu iti da se zadaci izvr avaju na standardne i provjerene na ine, osigura efikasan nadzor sa ciljem uo avanja gre aka u ranim fazama. Osim navedenog, cilj metodologije je da omogu i elasti ne promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom e se ukloniti ad hoc re avanje problema, odredi ili uka e kada i u kojoj mjeri je potrebno uklju ivanje korisnika, te poti e i omogu ava uklju ivanje korisnika kada se za to uka e potreba. Metodologija omogu ava da se dovoljno pa nje posveti analizi poslovanja, ime e se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti gre ku u ranim fazama, jer je lak e popraviti dokumentaciju nego mijenjati programski kd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lak e je prona i gre ku tokom faze u kojoj je nastala, nego tra iti je i popravljati na osnovu posljedi nih u inaka primije enih u kasnijim fazama.

27

Slika 2.8. Relativno trajanje i cena otkrivanja gre aka u razli itim fazama. Relativno trajanje i cena otkrivanja gre aka u razli itim fazama razvoja IS prikazani su na slici 2.8.2.4.2. Pristup razvoju informacionog sistema

Tokom projektovanja IS primenjuju se, uglavnom, sve vrste modela metodologija ivotnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijede i pristupi razvoju. Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup jer omogu ava opisivanje specifi nih funkcija. Prisutan je problem odre ivanja nivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna pa nja je posve ena modelu podataka, ta za posljedicu mo e imati neodgovaraju i model baze podataka i ote anu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjerenost podacima (npr. IEM) obezbje uje slo eniji opis strukture podataka, ali jednostavnije tokove podataka. Procesi se defini u analizom podataka (grupi u oko podataka) i br e konvergira kraju, jer je skup objekata (entiteta) modela kona an. Po etak razvoja definisanjem doga aja (npr. JSD) je primjereniji sistemima za rad u stvarnom vremenu.

28

2.4.3. Komercijalne metodologije za razvoj informacionog sistema Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su navedeni u originalu: AD/Cycle (Application Development Cycle), BSP (Business System Planning), CASE*Method, IEM (Information Engineering Methodology, Martin), JSD/JSP (Jackson System Development/ Jackson System Programming), SA/SD (Structured Analysis / Structured Design), SASS (Structured Analysis and System Specification), SSM/M (Soft Systems Method / Multiview), SSA (Structured System Analysis), SSADM (Structured System Analysis and Design Method), Yourdon (Yourdon Structured Method). Objektno usmjerene metodologije: Yourdon/OO (Yourdon / Object Oriented), OMT (Object Modelling Technique), BOOCH (Booch93), Schlaer-Mellor, Unified Modelling Process (Rational). 2.5. Savremeni postupci razvoja informacionog sistema2.5.1. Brzi razvoj aplikacija

Brzi razvoj aplikacija (Rapid Application Development (RAD)) je efikasna izrada programskog proizvoda u relativno kratkom vremenu. Ovo se posti e sistemskom i vremenski sa etom primjenom slijede ih tehnika i alata: aktivno i efikasno uklju ivanje korisnika, odgovaraju e upravljanje projektom, ispravna upotreba metoda i tehnika razvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao i upravljana izrada prototipa. RAD se obavlja malim ekipama u trajanju od 60 do 120 dana (pribli no 20 sedmica) za podsistem veli ine od 25 do 30 relacija (tabela). Cena postignutog ubrzanja mo e biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu priru nih rje enja) i prljavi razvoj. Faze brzog razvoja su:

29

1. JEM (Joint Enterprise Modeling ) zdru eno modeliranje organizacije, odnosno sjednice na kojima poslovodstvo i analiti ari tra e na ine usmjerenja organizacije i na ine kako je u initi kompetentnom. Istra uju se ciljevi organizacije, problemi, kriti ni inioci uspjeha te strategijske mogu nosti; 2. JRP (Joint Requirements Planning) zdru eno planiranje zahtjeva, odnosno analiza zahtjeva za razmatrani poslovni sistem. Prou avaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istra uju i defini u informacione potrebe; 3. JAD (Joint Application Design) zdru eno oblikovanje aplikacija. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. Zahtijeva tijesnu saradnju korisnika, projektanta i menad era; 4. Konstrukcija - iterativna izrada prototipa; 5. Zavr etak projekta - provjera rada, izrada dokumentacije, obuka korisnika. Primjer: RAD projekat. Sedmice 1-4 pokretanje projekta, istra ivanje, priprema JRP sjednice, obavljanje JRP sjednice, priprema JAD sjednice; Sedmice 5-9 prva JAD sjednica, po etak dizajna, konsolidacija JAD dizajna i prototipa, prototipovi za test uporabljivosti, druga JAD sjednica, zavr etak dizajna; Sedmice 10-14 razvoj i testiranje, priprema konverzije, planiranje zavr etka; Sedmice 15-20 izrada dokumentacije, priprema obuke, obuka, zavr no testiranje, zavr etak.

30

Zaklju ak

Informacioni sistem predstavlja na in obrade informacije sa ciljem pravovremenog dobijanja saznanja neophodnih za dalje delovanje. Pod Informacionim sistemom podrazumevaju se medusobno i funkcionalo povezani procesi prikupljanja, preno enja, obrade, kori cenja i cuvanja podataka. Potreba za uvodenjem informacionog sistema se ogleda u mogucnosti pokrivanja svih informacionih tokova u upravljanju odredenim Poslovnim sistemom, u skladu sa prirodom i zadacima koji se obavljaju u sistemu. Od Informacionog sistema se ocekuje da obezbedi osnovu za izvr avanje razli itih zadataka i zahteva koje u esnici postavljaju sistemom. Time se iskazuje potreba za kompleksnim i efikasnim informacionim tehnologijama nephodnim za izgradunju i funkcionisanje Informacionog sistema. Povezivanje pod sistema Informaconog sistema u jednistvenu, funkcionalnu i ekonomicnu celinu, posti e se pomocu baza ili banke podata, u okviru kojih se memori u svi relevantni podaci neophodni za funkcionisanje Poslovnog sistema.

31

Literatura: prof. dr ing Poli uk E. Jaroslav Projektovanje informacionih sistema

32