Menadzment informacione tehnologije

8/3/2019 Menadzment informacione tehnologije

1/30

Visoka tehnolo ka kola strukovnih studija abac

Studijski program: Informacione tehnologije

Predmet : Menad ment informacionih sistema

Tema: P rojektovanje informacionih sistema

-Seminarski rad-

Studenti: Mentor:

(Uro Brati , 4-99/2009, ( mr Svetlana Jevremovi )

Ivan Petrovi 4-90/2009,

or e Doki 154/2007)


2/30

SADR AJ

1. Planiranje razvoja informacionog sistema .............................................. 11.1. Modaliteti razvoja informacionog sistema............................................. 1 2.1. Analiza izvodljivosti, tro kova i koristi projekta...................................... 72.2. Strategija i planiranje razvoja informacionog sistema............................ 10 2.3. Modeli razvoja informacionih sistema.................................................... 16 2.4. Metodologija razvoja informacionih sistema.......................................... 272.5. Savremeni postupci razvoja informacionog sistema.............................. 29


3/30

1. Planiranje razvoja informacionog sistema

1.1. Modaliteti razvoja informacionog sistema

1.1.1. Vlastiti razvoj informacionog sistema

Postoje razli iti modaliteti razvoja informacionog sistema. U ovom seminarskome biti razmatrani modaliteti razvoja koji se naj e e koriste. Razvoj vlastitim

informati kim snagama podrazumeva osposobljavanje i anga ovanje netehni kosoblja, kao i povremeno ili dugoro no anga ovanje spoljnih saradnika. Prednostiovakvog pristupa su fleksibilnost, kreativnost i pove anje stru nosti vlastitoosoblja. Nedostaci su da ovaj pristup zahteva zna ajno vrieme i napor, razvoj jeskuplji 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 daorganizacija pomo u nje posti e komparativnu prednost u odnosu na konkurenciju. Postoje dodatni ili posebni razlozi kao to su pove ana tajnost podataka i poslovn

procesa ili pove ana za tita IS. 1.1.2. Spoljni razvoj informacionog sistema

Anga ovanje spoljnih saradnika za razvoj informacijskog sistema, ili njegovihdelova, podrazumeva pru anje pomo i u obrazovanju radnika informati ke struke pomo pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize ioblikovanja. Tako e se podrazumeva kodiranje (generisanje) celovitog programskog sistema,upravljanje izvo enjem i/ili nadzor izvo enja, kao i konsultativna pomo prilikomugradnje slo enih poslovnih funkcija. Varijante su slede e: ugovoreni razvoj,odnosno ugovara se isporuka gotovog proizvoda ili dugoro na saradnja saisporu 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, np. 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


4/30

pobolj ati organizaciju/poslovanje poslovnog sistema.

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 vlastitestru nosti. Nu no je da upravljanje projektom informatizacije na sebe preuzme vlastitokompetentno 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. Primeriaplikativnih paketa, koji se mogu nabaviti kao gotovi proizvodi, su: programski paketi za kancelarijsko poslovanje (npr . Microsoft Office ), programi za upravljanjedokumentima (npr . Lotus Domino ) ili specijalisti ke aplikacije za odre enenamene. Mogu se nabaviti slede i sistemi za upravljanje poslovanjem, koji nosekomercijalne nazive: Enterprise Resource Pl anning (ER P) systems, SA P , BAAN.Celoviti sistemi za podr ku poslovanju, uglavnom, podr avaju slede e aplikacije:finansijsko poslovanje , proizvodnju (manufacturing ), robno-materijalno poslovanje (materia l management/distribution ), upravljanje ljudskim resursima i plate (CG management, payro ll ).

1.1.4. Nabavka poslovnih aplikacija

Slede i modalitet razvoja IS je nabavka i prilago avanje postoje ih doma ih poslovnih 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 natehnolo ka zastarelost, prekapacitiranost dobavlja a. Modaliteti ovakvog pristupasu slede i: otkup izvornog koda i samostalna dorada ili kompletno odsustvoizvornog koda uz samostalno odr avanje. Nabavka gotovih stranih poslovnih aplikacija, tako e, ima svoje prednosti inedostatke. Prednosti su rasko na funkcionalnost i kompatibilnost sa svetskim poslovnim standardima, dok se nedostatci ogledaju u neprilago enosti doma imuslovima 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


5/30

mogu u komparativnu prednost (brzinu i lako u primene). Glomazni paketi moguzahtevati anga ovanje velikog broja konsultanata. Mogu i modalitet nabavke je dase prilago avanje vr i vlastitim snagama uz savetovanje i pomo dobavlja a.

1.1.5. K riterijumi 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), referensedobavlja 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), blagovremenootklanjanje problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitihaplikacija.

1.1.6. Nabavka izvedbenog program skog koda

Prednosti nabavke izvedbenog koda su: izvedbeni kd je jeftiniji, brigu iodgovornost o njegovom odr avanju preuzima isporu ilac, uz izuzetak nekih op primjenjivih komercijalnih programa. Prednost izvedbenog koda je i ta da se nemora kupiti (skupi) razvojni programski alat u kojem je programski proizvodrazvijan. Mane izvedbenog koda, obzirom na korisnika, su: izvedbeni kd podrazumijeva potpunu zavisnost od isporu ioca, ne postoji mogu nost prilago avanjaspecifi nim vlastitim potrebama, osim putem posebnog dogovora sa isporu iocem. Dodatna prilago avanja lako mogu postati predmetom ucjene. Tako e, ne postojimogu nost razvoja programske opreme vlastitim snagama.

1.1.7. Nabavka izvornog program skog koda

Prednosti nabavke izvornog programskog koda su znatne. Izvorni kod omogu avastalni razvoj i pra enje vlastitih posebnosti, to se mo e pokazati kao prednost uodnosu na konkurenciju. Osim toga, pru a mogu nost prilag avanja vlastitim potrebama, ta daje elasti nost pri promjenama organizacije poslovanja. Nema


6/30

bojazni da e nakon prve potrebne izmjene prestati upotreba IS zbog toga toisporu ilac nije trenutno dostupan, postavlja nerazumne uslove ili je ume uvremenu nestao sa tr i ta. Uvidom u kvalitetna gotova rje enja poma e serazvoju vlastitih informati kih radnika. Male narud be izvornog koda su, tako e, prisutne. Izvorni kd je vi estruko skuplji od izvedbenog. Potrebna je razvojnavarijanta programskog alata u kojem je IS razvijen. Naru ilac se izla e isku enjuda nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad iizgubi pravo na odr avanje. Odr avanje je skuplje ukoliko se radi o programskojopremi podlo noj promjenama. Sni enje cijene izvornog koda mo e se posti iautomatizacijom kodiranja, upotrebom generatora izvornog koda.

Pre poruke za izbor program skog 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 rje enja na osnovu poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija ra unarskeopreme i programske podr ke, te odabrana tehnolo ka arhitektura, dok su izlazimogu a rje enja novog sistema i njihove karakteristike. Analiza izvodljivosti alternativnih rje enja se sastoji od procjena alternativaobzirom na tehni ku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi sukarakteristike mogu ih rje enja, karakteristike i cijene hardvera i softvera,referense I uslovi dobavlja a, a izlazi analiza izvodljivosti za svako mogu erje enje. Prijedlog rje enja sistema koji e se oblikovati i ugraditi se donosi naosnovu izbora onog rje enja koje ima najbolju ukupnu kombinaciju izvodljivosti.


7/30


8/30

komentara i mi ljenja (mo e biti dio idejnog re enja), (5) eventualni povratak ustudiju izvodljivosti, odnosno revidirani izve taj.

2.1.2. Izve taj o izvodljivo sti 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 izvodljivo sti projekta sadr i procjenuhitnosti 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 uodnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, a urneta ne, korisne), ekonomiske aspekte (gde spadaju problemi tro kova i mogu nostu teda), kontrolu (u prvom redu sigurnost i za titu podataka), efikasnost (odnosno pobolj avanje upotrebe raspolo ivih resursa: ljudi, opreme, novca, itd.), kao iusluge (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 stavkorisnika prema re enju? i Da li e se sistem koristiti? Neophodni su podr kauprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uo iti otporeulozi 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 korisnikaza postizanje pune primene sistema. Namjeniti jednostavni interfejs za po etnike i povremene korisnike, slo enijeoperacije za iskusne korisnike. Obezbediti da korisnik daje prednost ponu enomre enju u odnosu na postoje i na in rada. Analiza tehni ko - tehnolo ke izvodljivo sti projekta sadr i procenu mogu ihrje 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 jemogu 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 primjenljivatehnologija 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 tamanje bitno nije ni injenica da li postoje potrebni stru njaci za primjenu nove


9/30

tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija mo esavladati.

Analiza vremen ske izvodljivo sti projekta treba da d odgovor da li su predvi eni rokovi ostvarivi, obzirom na raspolo ivu stru nost. O ekivano vrijemezavr etka mo e biti po eljno ili obavezno. Bolje je isporu iti ispravan sistem dvamjeseca kasnije, nego neispravan ili beskoristan na vrijeme!Ekonom ska izvodljivo st projekta e biti obja njena preko analiza i uporedbeukupnih tro kova - koristi (cost-benefit ana l ysis (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) razlikakorist tro ak unekom razdoblju(Net P resent Va l ue ), (2) povrat investicije(korist tro ak ) /tro ak (Interna l Rate of Return ), (3) trenutak u kojem korist nadvlada tro ak ( P ayback P oint ). CBA ra una tro kove i korist projekta kao trenutnu vrijednost ( P resent Va l ue(PV)). Dana nja vrijednost onoga to e postati $1,00 nakon n godina u budu nosti, ako se uzmu u obzir kamate I iznosi:

P V = 1/(1 + I )n = (1 + I ) nRazlika predstavlja kamatu koja se mo e zaraditi tim novcem ($ ozna avanov 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 inomtrajanja projekta kako bi se dobio godi nji ROI. Nizak ROI (~ manji od10 %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


10/30

Tabela 2.2.

2.2. Strategija i planiranje razvoja informacionog sistema

2.2.1. Defini sanje poslovne strategije

Poslovni ciljevi zahtevaju definisanje poslovne strategije, odnosno planiranjeakcija za postizanje ciljeva. Uprava defini e viziju i misiju poslovnog sistema, tj. strategijske ciljeve. Na osnovu strategijskih ciljeva se defini u poslovni ciljevi iodre uju zadaci, kojima e poslovni sistem u nekom razdoblju ispuniti svoju


11/30

misiju. Pri tome se dobijaju odgovori: ta se eli posti i (prepoznatljivost, kvalitet prihodi), kako eljeno posti i (promjenom organizacije, pobolj anjem sistemaadministracije), kako ostvariti pove anje proizvodnje ulaganjem u nove proizvodntehnologije, uz istovremeno odr avanje kvaliteta proizvoda, i kako osiguratizadovoljstva i radne sposobnosti zaposlenih do kolovavanjem i mogu nostimanapredovanja. 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 nomanje od 2 godine, srednjoro no 2 do5 godina i dugoro no vi e od5 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 Poslovnomsistemu koji se sastoji od vi e cjelina, kao to su Uprava, Finansije, Proizvodnja iInformatika esto postoji vi e razli itih tehni kih sistema ili aplikacija, takozvaniinformati kih ostrva. To ima za posljedicu umno avanje informacija uz razli itotuma enje u razli itim dijelovima, nepotpunost informacija, naro ito kada svakaCelina prikuplja samo njoj va ne informacije, problem povezivanja informacija pr 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 jete ko izvodljivo u uslovima pre ivljavanja. Sastoji se od uspostave smjera i prioriteta uskla ivanja informacionih servisa u skladu sa misijom, vizijom iciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podr ka promjeni poslovnogsistema i poslovnih procesa. Jo se mogu navesti primene metoda analize i dizajnaza prou avanje poslovnog sistema, sa ciljem definisanja op teg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi. U praksi situacija je slijede a. Umjesto prema strategijskom planu, poslovni


12/30

sistem se "dovodi u red" tokom informatizacije i pomo u informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budu i dase dizajnom sistema predla u ili name u pobolj anja.

2.2.3. Odabir i pokretanje projekta

Prvenstveno pokreta i promjena su korisnici, odnosno njihovo nezadovoljstvoaplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokujenedostatak podataka, to nagla ava potrebu uvo enja novih funkcija. Nezadovoljstvo podacima nastaje uslijed njihove nepouzdanosti, nedostupnosti,manjkavosti, a nezadovoljstvo reorganizacijom nastaje uslijed promjeneorganizacione strukture, promjene poslovnih procesa (npr . promjene naUniverzitetu uzrokovane novim zakonom). Pokreta i promjena mogu biti I pokazatelji poslovanja (npr . pad prodaje, uska grla proizvodnje, neplanirano inejasno pove anje tro kova), kao i zastarila tehnologija (npr . zastario razvojni alati 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 prethodnoistra 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 odslijede ih aktivnosti: izrada plana rada, oformljenje projektantske ekipe(uklju ivanje u esnika iz razli itih djelatnosti, npr . radnici razli itih poslovnih podru ja iliorganizacijskih jedinica, uprava, vanjski konsultanti), pri emu je va no osigurati predanost u esnika zajedni kom cilju, i, na kraju, uspostava upravljanja i nadzora projekta. 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 kojasprje 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


13/30

procjena mogu ih tehni kih rje enja, pri emu treba imati na umu da to treba bitidetaljnije 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 ievidentiranja problema i prijedloga. Snimanje stanja obuhvata identifikacijukorisnika i opsega postoje eg (postoje ih) IS, uo avanje problema i nedostataka postoje eg IS, procjenu potreba za nadogradnjom (pobolj anjima), pocjenu potrebza izmjenama (prilago avanjem i popravkama) I procjenu potreba za izradomnovih IS ili podsistema IS.

2.2.5. Planiranje projekta

Planiranje projekta podrazumjeva odre ivanje namjene projekta i izdvajanjezadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Dometirazgrani enje projekata ili podprojekata (System boundary, Constraints,Objectives, P ermissions, 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 vremenskihokvira 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 pofazama, obavlja razrada I raspodjela poslova, kao i odre ivanje prioriteta. Nastojise prona i takva podjela posla na cjeline da cjelinu mo e obaviti jedna osoba iliekipa, da se cjelina mo e obaviti jednom metodom i posao zavr i jednim

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.


14/30

Primer: Po etni (preliminarni) plan informacionog sistema1. 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. Z amjena 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 ku5).

2.2.6. Odre ivanje poslovnih ciljeva Z a 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 dali 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 kakradi!" 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:1. Analiza kriti nih faktora uspjeha (Critica l Success Factors (CSF)), odnosno

inilaca, kojima poslovodstvo posve uje posebnu pa nju. Ti inioci trebasrazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr . brzi odgovor na


15/30

zahtjeve klijenata, odnos cijene i kvaliteta proizvoda,... );2. Planiranje poslovnog sistema ( Business Systems Pl anning (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 naslijede em jednostavnom primjeru:Z adatak 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 vlasnikavideoteke 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 hijerarhijuodlu ivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utro ak novcaza ... . Ograni enja mogu biti slijede a: osoblje (npr . odjel informatike smije zaposlitinajvi e tri stalno zaposlena radnika), materijalni tro ak (npr . nabavkakancelarijskog I potro nog materijala ne smije prema iti XXX ), ra unarskaoprema (npr . projekat se mora obaviti bez nabavke novog hardvera ili po eljno jeda tro ak opreme predstavlja najmanje33 % bud eta), finansijska sredstva (npr . ukupni bud et projekta je XXXXX ) ili naknade izvo a ima ne smiju prekora iXX% ukupnog iznosa).

2.2.8. Modeliranje postoje eg sistema

Svrha modeliranja postoje eg sistema je preciziranje dometa projekta, kao iverifikacija razumijevanja problema i usagla avanje percepcije sistema i stavovaizme 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). 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


16/30

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 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 anjeobima uslijed pogre ne procjene ili razli itog tuma enja ciljeva izme u korisnikaizvo a a, tzv. puze i domet projekta. Granice projekta moraju biti definisane to jemogu e preciznije. Time se kasnije pove anje projekta, mo da, ne e ukloniti, alie 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 brzorealizirati (npr . 3 do 9 mjeseci, u zavisnosti o veli ini itavog projekta). Po eljno jerealizovati takav prototip koji e omogu iti procjenu mogu ih tehni kih rje enja(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 sistema

2.3.1. Sekvencijalni (vodopadni) model razvoja informacionog sistema

Polazna pretpostavka metodologije ivotnog ciklusa je da se faze razvoja realizujustrogo sekvencijalno, istovremeno za cijeli programski proizvod. Kada je re oinformacionom 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 dase one otklone I dokumentuju vra anjem u prethodne i prolaskom kroz sve fazekoje slijede iza fazegde je gre ka napravljena. Ovakav na in primene metodologije

ivotnog ciklusa istrukturiranog pristupa se zove sekvencijalni ili vodopadni(waterfa ll) model primene metodologije ivotnog ciklusa. Dobre strane ovog pristupa su:integrisanost IS, dobra dokumentovanost i prakti no istovremeni zavr etak svih


17/30

podsistema IS. Z ahvaljuju i dobroj dokumentovanosti pojednostavljeno jeodr avanje aplikacija IS. Tako e, ovaj pristup daje dobre garancije da e, ukona nom vremenu, do i do zadovoljavaju eg rje enja programskog proizvoda,

ime se smanjuje rizik od neuspjeha razvoja. Sekvencijalni pristup, pored dobrihosobina, ne daje uvijek prave efekte kada je u pitanju ostvarenje prethodnodefinisanih ciljeva. Uzroci su vi estruki, a neki od njih suslijede i [ Mogin et a l . 2000] :1. U sekvencijalnom modelu primene metodologije ivotnog ciklusa krajnjikorisnik nije dovoljno uklju en u proces razvoja programskog proizvoda;2. Izme u po etka projekta i prvih operativno primjenljivih rezultata kod korisnikvremenski interval je dosta dug;3. esto se javlja potreba da se precizni, metodolo ki kompleksni projektantskikoraci izvode na osnovu nedovoljno precizno identifikovanih informacionihzahtjeva;4. Umjesto da to bude postupno, postoji potreba da se u razvoj IS odjednomulo e zna ajna finansijska sredstva. Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodnoneidentifikovani korisni ki zahtjevi esto otkrivaju tek u fazi uvo enja aplikacije 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 ciljuizbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni, inkrementalni, spiralni, zvjezdasti, V model i drugimanje zna ajni modeli. Mogu se izdvojiti slijede e varijante sekvencijalnog(vodopadnog) modela: klasi ni vodopadni model, pseudostrukturirani vodopadnimodel i radikalni (strukturirani) razvoj. K lasi ni vodo padni model (slika 2.1(a)) redoslijedno (sekvencijalno) napredujeiz 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 trebaunaprijediti. Nedostaci ovog modela su izra eni u slu aju gre aka ilinovih/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. Pseudo strukturirani vodo padni model (slika 2.1(b)) sadr i povratnu vezu imogu nost promjene rezultata prethodnih faza. Ovaj model razvoja IS omogu ava primjenu tehnika strukturiranog programiranja.


18/30

(a) (b)

Slika 2. 1. Uporedni prikaz klasi nog razvoja (a), pseudostrukturiranog iradikalnog razvoja (b).R adikalni (strukturirani) razvoj (slika 2.1(b)) omogu ava

da se aktivnosti razli itih faza mogu obavljati istovremeno. Dozvoljava kori tenjerje nika podataka, programskih jezika etvrte generacije (4GL) i generatoraaplikacija. Prikladan je kadase 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 testirajuelementi IS na razli itim stepenima razvoja.


19/30

Slika 2.2. Primer V modela.

2.3.3.Prototi pski model razvoja informacionog sistema Uz strukturirani pristup, prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se mo e primjeniti u okviru metodologije ivotnogciklusa. Prototipski pristup postaje u punoj meri prakti no primenljiv (iako je idejao 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 saokru enjem etvrte generacije. U zavisnosti od njegove namjene, mogu se uo itislijede e tri vrste prototipskog modela. Mode l opona anja (model u prirodnojveli ini), odnosno jednoekranski ilivi eekranski model kojim se prikazuje kako izgledati dio sistema (npr . interfejs),istra iva ki mode l , za istra ivanje dijelovasistema kako bi se provjerile neke klju ne postavke (npr . provjera performansiodre enog modula) i, na kraju,ugradbeni mode l , tj. tra enje razli itih na ina nakoje se sistem mo e izgraditi (npr . koji sistem za upravljanje BP, programski jezik,ra unari). Prototip mo e postupno, doradom, da postane dio zavr nog IS.


20/30

Prototipski razvoj podrazumijeva interaktivni pristup, obi no kori tenjem4GL. R adni model daje se na uvid korisniku i omogu ava korisniku stvaranje slike oizgledu sistema. Korisnik daje primjedbe za popravku i pobolj anja, ime se sti e bolja slika o zahtjevima korisnika. Ujedno se uklanjaju mogu a iznena enja nakraju 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 ineuspjeh zamjene prototipa radnim sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad ne e biti napravljene, kao inemogu nost ispravne procjene i planiranja resursa.

Slika 2.3. Dijagram brzog razvoja prototipa.


21/30

Ograni eni/strukturirani razvoj prototipa slu i kao sredstvo za odre ivanjezahtjeva. Dobija senefunkciona l ni prototip (koji se ne mo e koristiti u obavljanjuradnih zadataka korisnika, a sadr i izgled ekranskih formi, menija i izvje taja), i

se razvoj u odre enom trenutku prekida i slijedi faza oblikovanja sistema

(slika2.4).

Slika 2.4. Dijagram ograni enog/strukturiranog razvoja prototipa.


22/30

Prakti ni aspekti primene prototipskog pristupa su vi estruki. Re je, uglavnom,o injenicama proisteklim iz iskustva u prakti noj primjeni prototipskog pristupa. Z bog toga, mo e se re i da su te injenice prije savjetodavnog, nego formalnostrogog karaktera. Op te preporuke za primjenu prototipskog pristupa su slijede e[ Mogin et a l . 2000] :1. Potrebno je, prije po etka primene prototipskog pristupa, precizno definisatistandarde za izgled korisni kog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti sa mogu nostima odabranog CASE proizvoda, agenerator programskog koda upotrebljenog CASE proizvoda treba prilagoditiza programiranje i izgled korisni kog interfejsa, a sve u cilju postizanja bolje podr ke standarda;

2. Preporu uje se dekomponovanje cjeline IS na manje projekte, a zatimdefinisanje ni eg stepena me usobne integracije informacionih podsistema, uodnosu na klasi nu primjenu metodologije ivotnog ciklusa;3. Kako korisnik ne bi bio doveden u zabludu, prilikom predaje korisniku prototipaaplikacije, obavezno ga upoznati sa injenicom da je u pitanju prototip a nekona no rje enje. Pri tome treba precizirati na in upotrebe prototipa od stranekorisnika; 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 zamorakrajnjih korisnika i projektantskog tima;5. Treba se orijentisati prete no kaodbacivim prototipovima ap l ikacija , ukoliko se

eli posti i to kra e vrijeme dolaska do prototipa, jer se time izrada samog prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatorakoda, 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 ume 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 predstrukturiranjasvjesno odustaje, ili kada je takvo prestrukturiranje nemogu e izvr iti zbogizmjena u shemi BP;7. Prototip aplikacije mo e da predstavlja rje enje koje je dobijeno pomo ugeneratora koda nekog CASE proizvoda, prvenstveno na osnovu specifikacijakonceptualnog nivoa. To zna i da se detalji, koji se defini u tek uimplementacionom projektu, a nisu podr ani odgovaraju im generatorom, nerealizuju u okviru prototipa aplikacije kako slijede a generisanja ne bi uni tilatako isprogramirane cjeline. Na taj na in se posti e kratko vrijeme izrade prototipskog rje enja, ali ne i njegova potpuna funkcionalnost;


23/30

8. Ako je mogu e, u prototip aplikacije treba uklju iti i odgovaraju e izvje taje, jtada 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 prototipskorazvoja, su slijede e. Iterativni pristup mmo e dovesti do zamora krajnjih korisnikai projektanata. U cilju izbjegavanja problema, posebno treba obratiti pa nju na preporuke3 i 4. Upotreba generatora koda je mogu a tek kada je formiranodgovaraju i dio sheme BP, a sa druge strane treba koristiti prototip aplikacijeupravo da bi se pribavile sve relevantne informacije za strukturiranje sheme BP,

to zna i da su ova dva zahtjeva me u sobom u suprotnosti. Primjena preporuka5, 7 i 9 vodi ubla avanju ovog konflikta. Ako se radi oneodbacivim prototipovima (neodbacivi prototipovi se evolutivnim pode avanjem pretvaraju u kona na rje enja aplikacija), dorada izgenerisanih aplikacija mo e bitzamoran I vremenski zahtjevan posao. U cilju pribli avanja korisni koginterfejsa I funkcionalnosti generisane aplikacije kona nom rje enju, odnosnoolak avanja postupka dorade izgenerisanih aplikacija, va no je preduzeti mjere predvi ene preporukom1. 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 preporuke5 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 funkcijiubla avanja ovog problema. Ako je re o manje iskusnim korisnicima ili projektantima, mo e se dogoditi da primjena prototipskog pristupa ne ostvari jadanod osnovnih ciljeva, odnosno pravovremeno identifikovanje informacionihzahtjeva, 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 razvojuintegrisanih IS, jer insistiranje na brzom uvo enju aplikacija u funkciju dovodi do parcijalizacije IS. Z bog toga je va no obratiti pa nju na preporuku 2. Aplikacijekoje se razvijaju samo primjenom prototipskog pristupa mogu postati izolovanaostrva. Imaju i u vidu tu injenicu, direktna primjena isklju ivo prototipskog pristupa je mogu a u slu aju da treba razvijati skoro izolovane podsisteme saniskim 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


24/30

od modela primene metodologije ivotnog ciklusa. U tom smislu, posebnozna ajnu ulogu ima evolutivni pristup razvoju IS.

2.3.4. Evolutivni model razvoja informacionog sistema

Primjena IS menja 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 sezasniva primjena sekvencijalnog modela metodologije ivotnog ciklusa, je darealizacija naredne faze ne zapo inje dok se teku a faza ne zavr i. Uo ava se daupravo primjena ovog principa, kod nekih projekata, mo e intenzivirati negativneefekte primene metodologije ivotnog ciklusa. Evolutivni model primene metodologije ivotnog ciklusa, nasuprotsekvencijalnom, 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, 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 naosnovu pretpostavke da ne treba odjednom realizovati kompletnu fazu i utro iti zato veliku koli inu vremena i novca, u situaciji kada se projektantske aktivnostiizvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednufazu treba da obezbjedi bolju osnovu za kasniji uspje ni zavr etak prethodne faze. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problemnedovoljno precizno identifikovanih informacionih zahtjeva, smatra se dan jegova prakti na primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupomkao metodom za ta no utvr ivanje informacionih zahtjeva. Z a utvr ivanjeinformacionih 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 shemomintegrisane BP. Drugim re ima, potprojekti se ponovo posmatraju kao cjelina i nanjih se primenjuju, ne to izmjenjeni, koraci konceptualnog i implementacionog projektovanja, kao pri primjeni sekvencijalnog modela metodologije ivotnogciklusa. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnogmodela 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 finansijskihsredstava odjednom, a ne postupno.


25/30

Prema drugoj varijanti, potprojekti se realizuju me usobno nezavisno i mogu bitifazno pomereni u vremenu. Na taj na in se re avaju problem dugog vremenskogintervala od po etka projekta do pojave prvih rezultata i potrebe ulaganjaodjednom finansijskih sredstava. Ovakav nezavisan rad, me utim, mo e dovesti doni eg stepena integrisanosti IS.

Slika 2.5. Mogu i evolutivni model primene metodologije ivotnog ciklusa.

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

2.3.5. Spiralni i zvezda sti model razvoja informacionog sistema

Kodspiralnog modelaprimene metodologije ivotnog ciklusa,na po etku svake

faze provodi se procjena rizika. Nastoje se utvditi mogu i rizici i razrije iti ih prijenastavka (uklanjanjem ili svo enjem na najmanju mogu u mjeru). U slu aju da jerizik prevelik, projekat se prekida(slika 2.6).


26/30

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 jednufazurazvoja i to: analizu, oblikovanje, izradu i integraciju. Faza mo e bitirealizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvojadonosi 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. Z vezdasti model, slika 2.7(b),ne uvodi stroga ograni enjau redosledu primenefaza i koraka metodologije ivotnog ciklusa. To ne zna i da prirodnog redosleda


27/30

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

2.4. Metodologija razvoja informacionih sistema

2.4.1. Uvod u metodologiju razvoja informacionog sistema

Metodologija se mo e definisati kao metoda + idejni pristup. Sadr i u sebikolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenihfilozofijom, 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[Check l and , 1994]. Komponente metodologije semogu razvrstati u slijede ih pet ta aka:1. Etape projekta;2. Z adaci 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 eomogu iti da se zadaci izvr avaju na standardne i provjerene na ine, osiguraefikasan nadzor sa ciljem uo avanja gre aka u ranim fazama. Osim navedenog, ciljmetodologije je da omogu i elasti ne promjene poslovanja i tehnologije (npr . odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom e se uklonitad hoc re avanje problema, odredi ili uka e kada i u kojoj mjeri je potrebnouklju ivanje korisnika, te poti e i omogu ava uklju ivanje korisnika kada se za touka e potreba. Metodologija omogu ava da se dovoljno pa nje posveti analizi poslovanja, ime e se osigurati izrada sistema koji odgovara poslovanju izahtjevima korisnika. Jeftinije je otkriti i popraviti gre ku u ranim fazama, jer jelak e popraviti dokumentaciju nego mijenjati programski kd. Izmjene u kasnijimfazama zahtjevaju promjene rezultata prethodnih faza. Lak e je prona i gre kutokom faze u kojoj je nastala, nego tra iti je i popravljati na osnovu posljedi nihu inaka primije enih u kasnijim fazama.


28/30

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 metodologijaivotnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijede i

pristupi razvoju. Usmjereno st proce sima (npr . SA/SD), koji je za korisnika jednostavniji pristup jer omogu ava opisivanje specifi nih funkcija. Prisutan je problem odre ivanjanivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna pa nja je posve enamodelu podataka, ta za posljedicu mo e imati neodgovaraju i model baze podataka i ote anu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjereno st podacima (npr . IEM) obezbje uje slo eniji opis strukture podataka,ali jednostavnije tokove podataka. Procesi se defini u analizom podataka (grupi uoko podataka) i br e konvergira kraju, jer je skup objekata (entiteta) modela

kona an. Po etak razvoja defini sanjem doga aja (npr . JSD) je primjereniji sistemima zarad u stvarnom vremenu.


29/30

2.4.3. K omercijalne metodologije za razvoj informacionog sistema Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionihsistema 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 sistema

2.5.1. Brzi razvoj aplikacija

Brzi razvoj aplikacija ( Rapid App l ication Deve l opment (RAD)) je efikasna izrada programskog proizvoda u relativno kratkom vremenu. Ovo se posti e sistemskom ivremenski sa etom primjenom slijede ih tehnika i alata: aktivno i efikasnouklju ivanjekorisnika, odgovaraju e upravljanje projektom, ispravna upotreba metoda i tehnikrazvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao iupravljana izrada prototipa. RAD se obavlja malim ekipama u trajanju od60 do 120 dana (pribli no 20 sedmica) za podsistem veli ine od 25 do 30 relacija (tabela). Cena postignutogubrzanja mo e biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzinane postane sebi svrhom, jer tada vodi u improvizaciju (izradu priru nih rje enja) iprljavi razvoj. Faze brzog razvoja su:


30/30

1. JEM ( J oint Enterprise Mode l ing ) zdru eno modeliranje organizacije,odnosno sjednice na kojima poslovodstvo i analiti ari tra e na ine usmjerenjaorganizacije i na ine kako je u initi kompetentnom. Istra uju se ciljeviorganizacije, problemi, kriti ni inioci uspjeha te strategijske mogu nosti;2. JRP ( J oint Requirements Pl anning ) zdru eno planiranje zahtjeva, odnosnoanaliza zahtjeva za razmatrani poslovni sistem. Prou avaju se funkcijesistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istra uju idefini u informacione potrebe;3. JAD ( J oint App l ication Design ) zdru eno oblikovanje aplikacija. Nastoji seoblikovati sistem tako da potpuno odgovara zahtjevima. Z ahtijeva tijesnusaradnju korisnika, projektanta i menad era;4. Konstrukcija - iterativna izrada prototipa;5. Z avr etak projekta - provjera rada, izrada dokumentacije, obuka korisnika. Primjer: RAD projekat. Sedmice 1-4 pokretanje projekta, istra ivanje, priprema JRP sjednice, obavljanje JRPsjednice, 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

Documents

Menadzment informacione tehnologije