zivotni ciklus is-a

8/10/2019 Zivotni ciklus IS-a

1/24

Informacioni sistemi u saobradaju i komunikacijama PREDAVANJE 3.

ivotni ciklus informacion ih s i s t ema

injenica je a nita ne moe vjeno funkcionirati ureeno i izve eno po bilo kom aspektu tehnolokom, funkcionalnom, poslovnom it , a a se ne mora je nom pristupiti promjenama,prilagoavanjima ili nekim slinim intervencijama. Tome nisu izuzetak ni informacioni sistemi.Informacioni sistemi zastarijevaju i takva egzistencijalna faza je poznata pod imenom deterioracijainformacionih sistema. Deterioracija sistema se ne mora manifestirati u nekoj fizikalnoj formi, ved tomoe biti kroz ruge forme, na primjer povedanje trokova koritenja sistema ili smanjenjem nivoaza ovoljnosti korisnika postojedim stanjem sistema. Temeljni princip o nosno zahtjev koji se stavlja preanalizu i izajn informacionih sistema jeste a prepoznaju vrijeme eci no izraene p otrebe za

mo ifikacijom ili zamjenom postojedeg sistema. Drugi temeljni princip se ogle a u a ekvatnoj pripremiza trenutak nastanka eterioracije sistema i to na je an sistematiziran nain.

Na slici 9 . ilustriran je ivotni ciklus informacionih sistema,(Information Systems Life Cycle ISLC) kojiukljuuje fazu razvoja sistema dizajn, zatim fazu implementacije sistema, fazu njegovog rada ikoritenja o ravanje i konano, fazu zastarjelosti sistema obsolentnost sistema.

Informacioni sistemi rijetk o oivljavaju a su etoriorirali fiziki, ved postaju tehnoloki i tehnikizastarjeli. Kao takvi, informacioni sistemi nisu sposobni a prate i izvravaju tehnoloki napre nefunkcionalne zahtjeve, za razliku od novije dizajniranih sistema. Nije rijedak sluaj a se obsolentnostsistema pokazuje sama o sebe u formi povedanja operativnih trokova ili u iskazanoj potrebi povedanogbroja osoblja za njegovo opsluivanje. Meutim, u generalnom smislu proirenje bilo funkcionalno,tehniko i/ili tehnoloko se vie preferira nego zamjena istog. Sistemska proirenja ili na ogra njapre stavljaju glavne mo ifikacije ko nekog postojedeg sistema.

Slika. ivotni ciklus informacionih sistema


2/24

Pretho no opisani ivotni ciklus informacionog sistema je linearnog karaktera i ovakva implementacijase obavlja faza po faza i kao takva ima veliki broj mana. Ove mane se mogu sublimirati kroz slje edeinjenice. Prvo, uvoenje "globalno" planiranog informacionog sistema moe ovesti o o reenihpotekoda u implementaciji je ne funkcije, ta funkcija moe a zakoi alju implementacijuinformacionog sistema i uspori ostale faze. Ovakvim pristupom moe a se ogo i a neke funkcije kojeu postojedem informacionom sistemu obro funkcioniu bu u o sjeene neko vrijeme. Dalj e, postojipotreba a se vre prepravke u fazi implementacije ranijih faza, to alje ometa ostale poslove, o laeimplementaciju i slino. Sistem ko kojeg se koristi linearni pristup je teak i skup za o ravanje.

Nain a se izbjegnu problemi sa linearnim ivotnim ciklusom je koritenje tzv. evolucionog ivotnogciklusa. Kod ovog principa projektovanja informacionog sistema izdvoji se jedna funkcija koja je veoma je nostavna i ima veoma je nostavne veze sa ostalim ijelovima informacionog sistema. Vri s eautomatizacija ove funkcije i kreira se tzv. prototip. Ova funkcija se "puta u ivot" i provjerava kakofunkcionie. Kontrola se obavlja zaje no sa ra nicima koji ra e ili koriste taj io informacionog sistema.Ako funkcija ne zadovoljava postavljene za atke vri se mo ifikovanje, o nosno funkcija evoluira. Ka a

se za ovoljimo nainom na koji je funkcija implementirana prelazimo na realizaciju neke sloenijefunkcije koja "sa ri pretho nu". Evolucioni pristup akle polazi o najje nostavnijih funkcija i ide kasloenim. Naravno u je nom trenutku moe poeti implementacija vie je nostavnih funkcija koje setrebaju spajati u je nu sloeniju.

Meutim i evolucioni ivotni ciklus ima mana. ta ako se esi a lju i koji implementiraju dvije funkcije jednog podsistema informacionog sistema formiraju baze podataka i elementarne podatke tako da ih jeteko uklopiti u je nu cjelinu? A ta ako implementacijom nekih po sistema bu u potroena svasre stva koja su planirana za itav sistem?

Nije teko zakljuiti a se ipak prije same realizacije informacionog sistema evolucionim pristupommoraju izvriti neke operacije na globalnom nivou - linearnim pristupom. Ove operacije su obino vezaneza definisanje globalnog modela podataka, centralne baze podataka i pravila pristupa bazama podataka,esto se efiniu i po sistemi i napravi se ogovor o povezivanju po sistema, raspo jele har verskh,softverskih i lju skih resursa. Zatim se pree na realizaciju poje inih funkcija pomodu prototipa(meto om uzastopnih pokuaja) .

ivotni vijek informacionih sistema ukljuuje slije ede promjene ko postojedih poslovnih informacionihsistema: zamjene (novi sistem), nadogradnja (dodavanje novih komponenti) i glavne modifikacije( opuna i/ili zamjena ijelova sistema). Proirenje/na dogradnja sistema predstavlja glavnu modifikacijuegzistirajudeg sistema. Proirenja sistema se po razumijevaju kao je na manja verzija zamjenekompletnog sistema. Proce uralni koraci u okviru ivotnog ciklusa razvoja sistema postoje i efinirani su

i za t emeljne mo ifikacije i za kompletnu zamjenu sistema. Druga razlika koja postoji izmeu temeljnihmodifikacija sistema i minornih modifikacija se zasniva na tome da pod prvim vidom modifikacijapo razumijevamo o avanje sasvim novih i o ta a nepostojedih funkcija, dok pod minornimmo ifikacijama se po razumijevaju aktivnosti re ovnog o ravanja.

Informacioni sistemi stare ili postaju prevazieni i ako nisu na vrijeme zamjenjeni i/ili mo ificirani, oniumiru. Analitiari IS moraju prepoznati pre stojedu smr t sistema i napraviti plan u skladu s tim. ivot


3/24

nekog informacionog sistema se sastoji o pet imenzija i smrt se moe esiti u bilo kojoj o njih. To su:raunovo stvena, tehnoloka, fizika imenzija, imenzija oekivanja korisnika i spoljnog uticaja.

Raunovo stvena imenzija. U svakoj profitnoj organizaciji vodi se amortizacija kapitalne opreme.Amortizacija raunarske opreme, obino u praksi, je pet go ina. Amortizacioni vijek informacionogsistema rijetko korelira s njegovim fizikim vijekom. Pa ipak, O jel IS moe lako oprav ati opunusistema koji, prema knjigovo stvu, vie ne postoji. Zbog toga, esto se eava a neki informacionisistemi umiru knjigovo stvenom smrdu. Mnoge komercijalne firme ne priklanjaju se timknjigovo stvenim zakonima i ivotni ciklusi njihovih sistema su ui u o nosu na knjigovo stveni opis.Jo uoljiviji je ovakav sluaj u nekomercijalnim firmama ka a su raunarski sistemi tri puta ue uprimjeni u odnosu na profitno orjentirane firme.

Tehnoloka imenzija. Ukoliko konkurencija uvede u primjenu sisteme bazirane na novijoj tehnologiji,to je jasan in ikator firmi a se tehnoloka imenzija njihovog sistema, najblae reeno, morapreispitati.

Fizika imenzija. Informacioni sistemi, ipak, na neki nain oivljavaju fizikalno troenje. To znai a jestalno prisutno pitanje njegove zamjene, nadogradnje ili potpunog izbacivanja iz upotrebe (smrti). Zaovo se moe nadi mnotvo primjera u praksi.

Dimenzija oekivanja korisnika. Je an informacioni sistem moe ra iti unutar svog pro uenogknjigovo stvenog vijeka, ali ne smije biti tehnoloki prevazien, niti pokazivati znakove fizikeeteriozacije ili istroenosti. Pa ipak, to moe biti neuspjeh. Zato? Jer su se promijenila oekivanjakorisnika koja je gajio ko uvoenja informacionog sistema. Nije vano koliko sistem izgle a obro, vedkoliko je sistem oprav ao oekivanja korisnika.

Dimenzija spoljnog uticaja. Sticajem okolnosti, moe se traiti a informacioni sistem mora bitidopunjen zbog spoljnog uticaja koji firma trpi za takvu dopunu. Na primjer, firma A insistira od firme Ba konvertuje svoje HW/SW aplikacije koje koristi. Ima mnotvo rugih primjera g je se ovakav spoljniuticaj manifestira kroz pragmatian zahtjev za na ogra njom/zamjenom sistema.

Razvoj in fo rm acion ih s i s t em a

Pojam razvoja informacionih sistema obuhvata sve aktivnosti vezane za planiranje, projektovanje,izgra nju, uvoenje i testiranje informacionih sistema. Obzirom da se organizacioni ambijenti itehnologije tokom vremena mijenjaju, javljaju se potrebe za novim sistemima ili su potrebne znaajnije

izmjene postojedih sistema a bi nastavili a ispunjavaju ciljeve zbog kojih se primjenjuju. Ovo ukazujena injenicu a je razvoj IS kontinuiran (neprekidan) proces. Uspjeh projekata zavisi od pristupa razvojuinformacionih sistema.

Informacijski ininjering predstavlja primjenu meusobno povezanih formalnih tehnika za planiranje,analizu, dizajn i izradu informacijskih sistema na raz ini cijelog pre uzeda ili u njegovom vedem ijelu.


4/24

U poetku su se informacijski sistemi poje inih o jela razvijali neovisno je ni o rugih tako a je, npr.o jel finansija imao o vojen informacijski sistem o ka rovske slube. Nastajali su takozvani"informacijski otoci", izmeu kojih nije bio uspostavljen tok informacija. Ako firma ima ure e u vierava, one avno je bila praksa a svaka rava ima o vojeni informacijski sistem, to je bilo potrebnozbog razlika u zakono avstvu, lokalnim obiajima i problemom sa u aljenom po rkomkorisnicima. Takvi sistemi su najede imali razliite strukture po ataka. Problem se pojavljivao koizvjetavanja, jer nije postojao je nostavan nain a se po atke iz raznoro nih informacijskih sistemaobjedini, kako bi se dobila slika stanja cijele kompanije.

Je an o za ataka informacijskog inenjeringa je spajanje raz vojenih informacijskih sistema u je nulogiku cjelinu, iz koje se mogu dobivati objedinjeni podaci.

Razvoj informacionih sistema je kompleksna djelatnost koja zahtijeva sistemski pristup, metodologijuprimjerenu tehnolokim i rugim mogudnostima. Osnovni cilj razvoja informacionog sistema je izgra itisistem koji radi i koji je pouzdan, unutar zadanih granica. To podrazumijeva izgraditi sistem kojizadovoljava poslovne ciljeve, prema zahtjevima korisnika, u prihvatljivom vremenu i po opravdanoj

cijeni. Neki od problema koji se mogu pojaviti prilikom razv oja IS su: prekoraenje planiranog vremena ifinansijskih sre stava, neispunjavanje zahtjeva, o nosno neo govarajudi sistem, nepouz anost,nesigurnost, neelastinost IS u primjeni, kao i tekode u o ravanju IS.

Za organizaciju ili firmu koja modernizuje IS i prati ostignuda u tehnologiji i meto ologiji projektovanja,nije svrsisho no teiti za stan ar om koji bi vrsto efinisao pristup, meto u, sre stva i okumentaciju,ne uzimajudi u obzir vrstu primjene, stepen razvoja IS, karakteristike korisnika i osobine realnog sistemau kome IS jeluje. Brzi tehnoloki razvoj zahtjeva a se ugorono zna ta se hode. Neopho no je imatistrategijsku sliku razvoja IS, koja de obezbje iti kompatibilnost sistema i biti fleksibilna u prihvatanjunove tehnologije. Pri r azvoju IS potrebno je omoguditi razmjenu po ataka izmeu korisnika, topo razumijeva zaje niku mreu za prenos, zaje niki mo el po ataka i njihov stan ar ni oblik.

U prolosti je razvoj programskih proizvo a bio oslonjen na razliite tipove alata za pr ogramiranje. Uprvoj fazi razvoja u upotrebi su bili mainski jezici (jezici 1. generacije), ija je itljivost bila veoma mala ikoji su zavisili o har vera. U rugoj fazi se koriste asembleri (jezici 2. generacije), koji su, takoe, bilizavisni od hard vera i teko itljivi. Poslije jezika 1. i 2. generacije, u tredoj fazi, u upotrebu su uli jezici 3.generacije (3rd generation languages - 3GL). Jezici 3. generacije su, kao i mainski jezici i asembleri,proceduralno orijentisani. Sa jezicima 3GL, u upo trebu je ula i tehnika strukturiranog programiranja.Bitna karakteristika 3GL je njihova nezavisnost o har vera. Osnovna pre nost uvoenja u upotrebu jezika 3. generacije je bilo povedanje pro uktivnosti programiranja, o nosno povedanje kvaliteta i brzin erealizacije programskih proizvo a. Sa ruge strane, povedanje pro uktivnosti je uzrokovalo smanjenje

performansi (brzine ra a) ta anjih programskih proizvo a i funkcionalnosti (irine primjene) 3GL.Problem smanjenja performansi je rjeavan uvoenjem u upotrebu sve modnijeg har vera, a problemsmanjene funkcionalnosti je rjeavan ili aljim povedanjem mogudnosti 3GL.

Meutim, oekivanja a de programski proizvo i, koji su razvijeni upotrebom 3GL, pratiti potrebekrajnjih korisnika i mogudnosti har vera se ved 70-ih go ina nisu ostvarila, to je ovelo o fenomenanazvanog softverska kriza. Osnovni pojavni oblik softverske krize je bio u tome a oekivani efekti orazvoja programskih proizvo a brzo izostaju, bez obzira na znatno povedanje ulaganja u ov u djelatnost.


5/24

Programiranje upotrebom 3GL je bilo neefikasno i ugotrajno, a najvedi io programerskog vremena jeo lazio na o ravanje postojedih programskih proizvo a, to je blokiralo alji razvoj IS. Tvr nja a jenajvedi io programerskog vremena o lazio na o ravanje postojedih programskih proizvo a se moepotkrijepiti slije edim statistikim po acima. Prema tim po acima 64% greaka pri razvoju IS se pravilo utoku analize korisnikih zahtjeva i projektovanja IS, ok se preostalih 36% greaka pojavljivalo tokomrealizacije IS. O pomenutih 64% ranih greaka, svega 30% je otklonjeno prije isporuke softvera. Pritome, kasno otkrivanje i otklanjanje greaka iz poetnih faza razvoja programskih proizvo a ovo i oeksponencijalnog rasta trokova uvoenja u upotrebu i o ravanje proizvo a. Tako, na primjer,otklanjanje strateke greke u fazi o ravanja kota 100 puta vie nego ka se greka otkrije na poetkura a na projektu. Ovo je ovelo o je ne nepriro ne raspo jele finansijskih sre stava, uloeni h urazvoj IS, prema kojoj preko 70% ukupnih sre stava uloenih u razvoj IS o lazi na njegovo o ravanje.

Povedanje cijene o ravanja i neefikasno programiranje su oveli o velikih zakanjenja u realizacijiprojekata IS. Prema nekim podacima, veliki proje kti u SAD su 1985. go ine kasnili o 30 o 45 mjeseci.Vremenom su i entifikovani slije edi uzroci softverske krize:

Projektovanje IS bez primjene o govarajude meto ologije ovo i o loeg projekta, pojavevelikog broja greaka i prekoraenja za anih vremenskih rokova zavretka projekta .

Ne ostatak softverskih alata, koji bi po rali projektovanje IS ili automatizovali postupkeprojektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo vodi ka nekvalitetnom projektuuslije oteanog rukovoenja projektom, fragmentiranog i nekonzistentnog dokumentovanja ineusaglaenosti ijelova projekta IS .

Ne ostatak o govarajudih softverskih alata za razvoj aplikacija IS, to vo i ka neefikasnojrealizaciji i o ravanju IS.

Svi ovi uzroci su doveli do prethodno opisanih poslje ica. Rjeenje softverske krize je, prema tome,

trebalo traiti u otklanjanju nave ena tri uzroka. To je vo ilo ka formalizaciji meto ologija i tehnikaprojektovanja IS i pojavi CASE proizvoda i jezika 4. generacije (4th generation languages - 4GL ), kaopo rke o govarajudim tehnikama i meto ologijama.

Razvoj raunarske tehnologije i informacionih tehnologija uopte, praden je porastom populacijekorisnika, irenjem informacionih zahtjeva i promjenama koje karakteriu savremeni stil ivota, aposebno savremeno poslovanje. U razvoju informacionog sistema centralno mjesto ima razvoj softvera ibaza podataka. Razvoj programskih proizvoda, kao disciplina se od 70 tih go ina prolog stoljeda, zovei softversko inenjerstvo, a zapravo se odnosi na metodol oki pristup razvoju ovih proizvo a sa ciljem ase u za atim vremenskim rokovima, primjenom o reenih tehnika projektovanja, ostigne potrebankvalitet finalnog proizvoda.

Problemi razvoja informacionih sistema

Osnovni problemi razvoja i upravljanja razvojem informacionih sistema jesu problemi savladavanjanjihove sloenosti i realizacije programskih rjeenja koja su a ekvatna potrebama sistema. Koritenjemslje eda va meto oloka principa moe se savla ati sloenost sistema:


6/24

dek ompozicija sloenog sistema na manje, lake savla ive ijelove, podjela cjelokupnog procesa razvoja informacionog sistema na faze.

Za ekompoziciju sloenog sistema na manje, lake savla ive ijelove koristi se strukturirani pristup iobjektno orjentisa ni pristup. Strukturirani pristup je opta tehnika u realizaciji programskog proizvoda imoe se koristiti u okviru faza snimanja i analize, projektovanja i programiranja, a zasniva se naslje edim principima:

postepeno ekomponovanje sloenog sistema na manje sloene po sisteme, nezavisna izgradnja podsistema, integracija nezavisno izgraenih komponenti u je instvenu cjelinu , i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.

Primjer ekompozicije moe biti razvoj IS po njegovim komponentama, tj. moe se o vojeno razvijatikomunikacijska komponenta o softvera i sl. Naravno, pri tome se mora vo iti rauna o relacijama

izmeu komponenti jer zaje nikim jelovanjem i relacijama poje inih komponenti IS moe izvritifunkciju zbog koje je projektovan.

Na raspolaganju su i razni CASE alati koji se koriste u strukturiranom pristupu i koji su se posljednjih 20 tak godina intenzivno razvijali. Strukturirani pristup razvoja informacionih sistema zasnovan je naspecifikaciji funkcija sistema, dok je objektno orjentisani pristup zasnovan na injenici a sistempre stavlja skup meusobno povezanih objekata, g je se stanje sistema sagle ava kao stanje objekataposmatranog sistema, a operacije nad objektima kao realizacija funkcija sistema. Danas se u razvojuinformacionih sistema sve vie koristi objektno orjentisani pristup.

Osnovni ciljevi razvoja informacionih sistema su:

izgraditi sistem koji radi i koji je pouzdan, unutar zadanih granica, izgraditi sistem koji zadovoljava poslovne ciljeve, prema zahtjevima korisnika, izgraditi sistem u prihvatljivom vremenu i po opravdanoj cijeni.

U cilju efikasnijeg i breg razvoja informacionog sistema neminovno je a svi lanovi razvojnog timabu u naisto sa principima razvoja sistema. Po velikom broju strunjaka iz oblaszi ICT tehnologija,principi razvoja informacionog sistema se mogu klasificirati u tri grupe:

opti principi, principi u realizaciji razvoja (esto pominjani kao mo eli razvoja), principi prilaza razvoju (u literaturi poznati kao filozofije razvoja).

Najvaniji principi razvoja informacionih sistema su:

ukljuivanje vlasnika i korisnika u proces razvoja sistema, utvrivanje kljunih faza i aktivnosti u razvoju informacionih sistema, utvrivanje stan ar a za konzistent an razvoj i dokumentiranje aktivnosti razvoja,


7/24

ocjena finansijskih ulaganja u informacione sisteme, sloboda da se procijeni ili revidira projekat IS sa aspekta trokova, vremena ili ciljeva, strukturiranje i konkretizovanje svake faze, procjena sposobnosti informacionog sistema za rast i promjene.

Faktori uspj enog razvoja IS su mnogobrojni i razliitog znaenja. Oni mogu doprineti razvoju ISdefinisanih karakteristika, na vrijeme i u okviru planiranog bu eta.

Faktori znaajni za uspjean razvoj IS su slje edi:

po rka najvieg rukovo stva, ukljuivanje korisnika u sve faze razvoja, koritenje dokazane metodologije razvoja IS, jasno definisanje ciljeva i zadataka sistema, fokusiranost na najvanije probleme i povoljne okolnosti,

jednostavan i odgovaraju di dizajn, obar program obuke svih ukljuenih osoba, adekvatan plan implemantacije poslij e zavretka projekta, obro efinisan i organizovan program o ravanja.

Planiranje razvoja informacionog sistema

Planiranje razvoja informacionog sistema treba a odgovor na sl je eda pitanja:

ime se poslovni sistem bavi (grana, proizvo i, trite, konkurencija)?

Koji su problemi, zadaci i ciljevi poslovnog sistema? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slue, koje i kakve po atke sa re? Postoje li aplikacije iji je razvoj u toku? U kojem su sta ijumu razvojni projekti? Koje su potrebne aplikacije? Koji su raspoloivi resursi (osoblje, tehnika sre stva, tehnologija)?

Razlozi zbog kojih treba planirati IS su viestruki. Na primjer, u poslovnom sistemu koji se sasto ji o viecjelina kao to su uprava, finansije, proizvodnja i i nformatika esto postoji vie razliitih tehnikih

sistema ili aplikacija, takozvanih informatikih ostrva. To ima za poslje icu umnoavanje informacija uzrazliito tumaenje u razliitim ijelovima, nepotpunost informacija, naroito ka a svaka cjelina prikupljasamo njoj vane informacije, problem povezivanja informacija pri pokuaju cjelovite interpretacije, kao iproblem razliitog posluivanja, razmjene po ataka i o ravanja.

Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili provodi se kao reakcija napromjene u poslovnoj politici. Strategijsko planiranje IS je prikladno za stabilne poslovne sisteme. Upr aksi je teko izvo ljivo u uslovima preivljavanja. Sastoji se o uspostave smjera i prioriteta


8/24

usklaivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranjaIS u skladu sa strategijom razvoja poslovnog sistema , tako a informatizacija bu e po rka promjeniposlovnog sistema i poslovnih procesa. Jo se mogu navesti primjene metoda analize i dizajna zaprouavanje poslovnog sistema, sa ciljem efinisanja opteg (sveobuhvatnog) plana i arhitekture IS ijirazvoj slijedi. U praksi situacija je slije eda. Umjesto prema strategijskom planu, poslovni sistem se" ovo i u re " tokom informatizacije i pomodu informatizacije. Analizom sistema evidentiraju seproblemi i slabosti poslovnih procesa, bu udi a se izajnom sistema pre lau ili namedu poboljanja.

O reivanje mogudih rjeenja za razvoj IS po razumjeva i entifikaciju rjeenja na osnovu poslovnihzahtjeva postavljenih tokom analize. Ulazi su specifikacija raunarske opreme i programske po rke, teodabrana tehn oloka arhitektura, ok su izlazi moguda rjeenja novog sistema i njihove karakteristike.Analiza izvo ljivosti alternativnih rjeenja se sastoji o procjena alternative obzirom na tehniku,operativnu, ekonomsku i vremensku izvodljivost. Ulazi su uslovi d obavljaa, a izlazi analiza izvo ljivostiza svako mogude rjeenje. Prije log rjeenja sistema koji de se oblikovati i ugra iti se onosi na osnovuizbora onog rjeenja koje ima najbolju ukupnu kombinaciju izvo ljivosti. Ulazi su napravljena analiza

izvodl jivosti, plan projekta, procjena veliine projekta, a izlazi prije log sistema sa usvojenimpromjenama izajna pre loenog sistema.

Postoje razliiti mo aliteti razvoja informacionog sistema o kojih su neki objanjeni u nastavku.

Razvoj vlastitim informa tikim snagama po razumjeva osposobljavanje i angairanje netehnikogosoblja, kao i povremeno ili ugorono angaovanje sara nika. Pre nosti ovakvog pristupa sufleksibilnost, kreativnost i povedanje strunosti vlastitog osoblja. Ne ostaci su a ovaj pris tup zahtijevaznaajno vrijeme i napor, razvoj je skuplji i ugotrajniji i moe povedati gomilanje zaostalog posla. Razvojvlastitim snagama ima smisla ka a se ra i o programskoj po rci koja je posebnost organizacije, takva ane postoje gotova rjeenja na tritu ili takva a organizacija pomodu nje postie komparativnu pre nostu o nosu na konkurenciju. Postoje o atni ili posebni razlozi kao to su povedana tajnost po ataka iposlovnih procesa ili povedana zatita IS.

Angaovanje vanjskih sara nika za razvoj informacijskog sistema, ili njegovih dijelova, podrazumjevapruanje pomodi u obrazovanju ra nika informatike struke, pomod pri analizi poslovnog sistema ioblikovanju IS ili obavljanje analize i oblikovanja. Takoe se po razumjeva ko iranje (generi sanje)cjelovitog programskog sistema, upravljanje izvoenjem i/ili na zor izvoenja, kao i konsultativnapomod prilikom ugra nje sloenih poslovnih funkcija. Varijante su slije ede: ugovoreni razvoj, o nosnougovara se isporuka gotovog proizvoda ili dugor ona sara nja sa isporuiocem, uz iz vajanje vlastitoginformatikog o jela u glavnog izvoaa. Moguda varijanta je i nalaenje stratekog partnera na uivremenski perio , npr. softverske kude. Pre nosti su viestruke. IS ili njegovi ijelovi izrauju se po mjeri

naruioca, sistem je prilagoen organizaciji/poslovanju, a po mogudnosti treba istovremeno poboljatiorganizaciju/poslovanje poslovnog sistema. Ovakav razvoj podrazumijeva dugotrajan postupak io govarajudu visoku cijenu. Nedostaci i rizici su t akoe prisutni. Dolazi o gubitka povjerljivihinformacija, gubitka na zora na sa anjim i/ili bu udim razvojem (zavisnost o obavljau), kao i gubitakvlastite strunosti. Nuno je a upravljanje projektom informatizacije na sebe preuzme vlastitokompete ntno osoblje koje ima mogudnost o luivanja.


9/24

Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe.Poeljno je a se mogu prilago iti potrebama. Primjeri aplikativnih paketa, koji se mogu nabaviti kaogotovi proizvodi, su: programski paketi za kancelarijsko poslovanje (npr. Microsoft Office ), programi zaupravljanje dokumentima (npr. Lotus Domino ) ili specijalistike aplikacije za o reene namjene. Mogu senabaviti slije edi sistemi za upravljanje poslovanjem, koji nose komercijalne nazive: Enterprise ResourcePlanning (ERP) systems, SAP, BAAN, J.D. Edvards, Peoplesoft. Cjeloviti sistemi za po rku poslovanju,uglavnom, po ravaju slije ede aplikacije:

finansijsko poslovanje (accounting), proizvodnju (manufacturing), robno-materijalno poslovanje (material management/distribution), upravljanje ljudskim resursima i plate (CG management, payroll).

Zahvaljujudi napretku tehnologije pojavile su se i gotove aplikacije za transportna pre uzeda koje su jouvijek u razvoju. Je na takva aplikacija je IS Transport Comman er koji svoju primjenu ved nalazi u nama

susje noj zemlji Srbiji ali na po ruju Bosne i Hercegovine ovakvi gotovi informacioni sistemi jo nisuzaivjeli. Svakako a se i takav gotov informacioni sistem treba prilagoditi potrebama transportnogpre uzeda koje de ga koristit jer je svako samo po sebi specifino.

Nabavka i prilagoavanje postojedih omadih poslovnih aplikacija je modalitet razvoja IS koji imapre nost u usklaenosti vaedim uslovima, npr. propisima, ta olakava prilagoavanje aplikacijaorganizaciji/poslovanju. Ne ostaci su nepostojanje ili manjkavost poje inih komponenti, mjestiminatehnoloka zastarjelost, prekapacitiranost obavljaa.

Nabavka izvedbenog programskog koda ima prednosti k ao to su: izve beni k je jeftiniji, brigu io govornost o njegovom o ravanju preuzima isporuilac, uz izuzetak nekih opte primjenjivih

komercijalnih programa. Prednost izvedbenog koda je i ta da se ne mora kupiti (skupi) razvojniprogramski alat u kojem je programski proizvod razvijan. Mane izvedbenog koda, obzirom na korisnika,su: izve beni k po razumijeva potpunu zavisnost o isporuioca, ne postoji mogudnostprilagoavanja specifinim vlastitim potrebama, osim putem posebnog ogovora sa isporuio cem.Do atna prilagoavanja lako mogu postati pre metom ucjene. Takoe, ne postoji mogudnost razvojaprogramske opreme vlastitim snagama.

Nabavka izvornog programskog koda omogudava stalni razvoj i pradenje vlastitih posebnosti, to semoe pokazati kao pre nost u o nosu na konkurenciju. Osim toga, prua mogudnost prilagavanjavlastitim potrebama, ta aje elastinost pri promjenama organizacije poslovanja. Nema bojazni a denakon prve potrebne izmjene prestati upotreba IS zbog toga to isporuilac nije t renutno dostupan,postavlja nerazumne uslove ili je u meuvremenu nestao sa trita. Uvi om u kvalitetna gotova rjeenjapomae se razvoju vlastitih informatikih ra nika. Mane naru be izvornog ko a su, takoe, prisutne.Izvorni k je viestruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata ukojem je IS razvijen. Naruilac se izlae iskuenju a nekompetentno mijenja nabavljeni izvorni k ,onesposobi aplikaciju za ra i izgubi pravo na o ravanje. O ravanje je skuplje ukoliko se radi oprogramskoj opremi po lonoj promjenama. Snienje cijene izvornog ko a moe se postidiautomatizacijom kodiranja, upotrebom generatora izvornog koda.


10/24

1

Proces projektovanja informacionih sistema

Osnovni zadatak metodologije projektivanja informacionih sistema (PIS) je a prui recept koji de posaoprojektovanja IS uiniti to je mogude vie formaliziranim i stan ar izovanim. Za oekivanje je astan ar izacija u projektovanju IS treba a poveda pro uktivnost, smanji, trokove, poveda kvalitet.

Mutim, obzirom na postojanje razlika u stepenu razvoja IS i realnom sistemu u kojem djeluju,korisnicima IS, projektantima IS, kruta standardizacija ne mora uvijek da doprinese navedenimpozitivnim efektima. Zbog toga se problemu standardizacije u projektovanju IS pristupa kao problemuizbora strategije rj eavanja konkretnog problema i stan ar izaciji postupaka u okviru izabrane strategije.To znai a je neopho no razra iti meto ologiju izbora strategije i vie konkretnih stan ar a zao govarajudu strategiju. Izbor strategije i metodeje u okviru korisnika i samih projektanata.

Uspjean razvoj IS zaht jeva zaje niki ra korisnika i projektanata IS. Nuan pre uslov za kvalitetan iefikasan rad na razvoju IS je uspj ena komunikacija korisnika i projektanata. Osnovni problem koji seesto pojavljuje u projektovanju IS je a projektant zna kako, ali ne zna ta treba ura iti, ok korisnikzna ta, ali ne zna kako treba uraditi. Usp jena komunikacija izmeu korisnika i projektanata moe seuspostaviti ako postoji zaje niki jezik. S obzirom na brojne obre osobine grafikih jezika (mali brojsimbola, jednostavnost primj ene, prikaz slikom) razvijeno je vie grafikih jezika za opis raznih aspekataIS i time stvoreni preduslovi uspj ene komunikacije projektanta i kor isnika. Jedan od bitnih ciljevarazvoja stan ar izovanih sre stava i meto a projektovanja IS jeste efinisanje zaje nikog jezikakorisnika i projektanta.

Osnovna pitanja sa kojima se susredu projektanti IS jesu:

1. Kako savla ati sloenost IS kao objekta projektovanja?2. Kako projektovati Is, a a proces projektovanja IS omogudi brzu i sigurnu izgra nju IS, o nosno

koje metode, tehnike, postupke, korake, sredstva i alate koristiti, te savladaju problemisloenosti sistema?

Za savla avanje sloenosti sistema postoje sl je ede vije osnovne ideje:

I i eja: Proces projektovanja IS razloiti u faze ivotnog ciklusa, o nosno izvriti vremenskudekompoziciju procesa projektovanja IS.

II i eja: Izvriti ekompoziciju sistema koji se projektuju te pronadi skup relativ no jednostavnihdijelova koji su relativno jednostavno povezani.

Navedene ideje mogu se iskoristiti za definisanje standardne metodologije PIS.

Alati za projektovanje informacionih sistema

Izloeni meto oloki pristup moe se realizovati runo ma a sve njegove pre nosti olaze o izraaja uprojektovanju IS uz pomod raunara, o nosno ukoliko meto ologija obuhvata automatizovana sre stva


11/24

1

pomodu kojih de se izabrati mo el i meto oloke preporuke modi a realizuju , te koji de omoguditianalitiarima, projektantima i korisnicima da:

da brzo i potpuno otkriju nekonzistentnost, nepotpunost i protivrj enost opisa, a putemizvjetaja okumentuju IS na bilo kom nivou apstrakcije, na njima najpogo niji nain,

a ugra e razliite automatske i automatizovane meto e logikog i fizikog projektovanja BP iprograma bu udeg IS,

a omogudi automatizovano generisanje simulacionih programa pomodu kojih de se evaluiratiprojektna rj eenja u o nosu na raspoloive resurse,

a omogudi automatizovano generisanje prototipa bu ud eg IS, da bi se evaluirala konkretnareenja u o nosu na postavljene zahteve, o nosno prikazalo ta de korisnik stvarno obiti,

a poslui kao priro ni semantiki bogat interfejs za komunikaciju korisnika sa IS, da aktivno povezan sa IS formira jedan adapt ivni (samoorganizujudi) IS, koji de na osnovu izmene

okline i merenja svojih performansi, jednostavno i automatizovano menjati svoju strukturu isvoje karakteristike,

a omogudi korisnicima je nostavan i pro uktivan razvoj sopstvenih aplikacija.

Raunarom po rano softversko inenjerstvo poznato je anas po nazivom CASE (Computer Ai eSoftware Engineering). Softverski inenjering (software engineering) obuhvata poslove inicijalizacije,projektovanja, realizacije i prodaje softverskog proizvoda, te rukovanja svim resursima koji su vezani zataj proizvod. Dakle softverski i nenjering obuhvata iri skup aktivnosti posebno rukovo nih o samogprojektovanja i realizacije IS.

Koritenje kvalitetne meto ologije za razvoj softvera je veoma znaajan postupak u unaprijeenjacjelokupnog poslovanja pre uzeda. Je an o naina je i koritenje softvera koji u sebi ima informacije ostrukturi pre uzeda, pa tako i o strukturi (mo elu) po ataka. Ako se izmjene ra e na razini mo elapodataka, one se automatski propagiraju u sve dijelove aplikacije, gdje su potrebne. Automatski semijenja izgle formi, izvjetaja, pravila za unos i sl. Ovaj koncept, koritenje alata za mo eliranje nekogsistema i automatsko generiranje aplikacija na temelju tog modela se zove "Computer - Aided SystemsEngineering" - CASE. Iako ved ugo postoje, u praksi se u nekim segmentima razvoja aplikacija koristevie, a nekima manje. Vrlo su korisni u ijelovima koji su strogo i formalno efinirani, kao npr.generiranje relacijskog modela baze podataka na temelju mo ela. U rugim segmentima, kao to sugeneriranje obrazaca i izvjetaja, se koriste kao pomod ok finalna verzija u pravilu zahtijeva "rune"dorade. Je an o primjera generiranja objekata aplikacije pomodu mo ela se moe vi jeti i u aplikaci jiMS-Access, g je se na temelju "arobnjaka" i mo ela po ataka poje nostavljeno generiraju obrasci iizvjetaji.

CASE alati su svi alati zasnovani na primj eni raunara kao po rci u procesu softverskog inenjerstva. Osnovni ciljevi primjene CASE alata su:

povedanje pro uktivnost projektanata, skradivanje vremena izra e projekta, povedanje kvaliteta obijenog programskog proizvo a.


12/24

1

Primjena CASE alata zahtjeva dosljednu primj enu meto ologije koju po rava alat uz primjenu raunara.Koritenje CASE alata je int eraktivno, uz naglasak na koritenje raunarske grafike. Razmotrimo malodetaljnije karakteristike i aspekte primjene CASE alata u razvoju IS.

Horizontalna zastupljenost o reuje broj pokrivenih po ruja u posmatranoj fazi razvoja IS. Ako je brojpokr ivenih po ruja vedi to je i CASE alat bolji.

Vertikalna zastupljenost o re uje broj pokrivenih faza razvoja u posmatr anom po ruju razvoja IS. Ako je broj pokrivenih faza razvoja vedi to je i CASE alat bolji.

Kvalitet horizontalne i vertikalne zastupljenosti se ocjenjuje prema stepenu vertikalne i horizontalneintegrisanosti. Vertikalno integrisani CASE alati po ravaju je no ili vie po ruja razvoja IS tako a jemogud je nostavan prelazak iz je ne u rug u fazu razvoja (npr. a se u po ruju po ataka mo gupovezati opisi podataka, u fazi analize i dizajna sistema sa opisima u fazu implementacije). Horizontalnointegrisani CASE alati po ravaju je nu ili vie faza razvoja IS tako a su po ruja razvoja me usobnopovezana.

Izbor CASE alata o reen je prije svega izborom metodologije projektovanja IS. CASE alati kojiobuhvataju sve faze razvoja IS jednom metodom su rij etki. edi sluaj je a CASE alat sa ri vie tehnikasa vedim ili manjim stepenom integrisanosti.

U praksi je naalost est sluaj da korisnik bez prethodne usvojene metodologije projektovanja ISnabavlja CASE proizvod, nakon ega na osnovu tehnika koje mu nudi CASE alat formira metodologijuprojektovanja.

Zavisno o toga a li po ravaju samo poje ine za atke, poje ine faze ili cijeli ivotni ciklus u razvoju IS,koriste se sl je edi termini za blie o re ene CASE alata:

CASE tool (alati za automatizaciju jednog koraka),

CASE toolkit (alati za automatizaciju je ne faze ivotnog ciklusa), CASE workbench (alati za automatizaciju kompletnog ivotnog ciklusa), CASE environment (alati sa hardverskom po rkom za automatizovano projektovanje). takoe, ananje CASE alate moemo klasifikovati u sl je ede tip ove: alati za modeliranje struktura podataka, alati za izradu dijagrama toka podataka i hijerarhije modula, alati za izra u prototipa korisnikog interfejsa, generatori koda.


13/24

1

Slika. Faze projektiranja informacijskog sistema i CASE

U poslj e njih nekoliko go ina, velika panja se poklanja izra i CASE alata koji bi obuhvatali cijeli procesprojektovanja IS. Primjena takvih alata bi doprinijela da projektovanje bude na vrijeme i efikasnoobavljeno, bez preskakanja meto olokih koraka i prema zaht jevima korisnika. Time bi se povedalapouzdanost i kvalitet programskog proizvoda.


14/24

1

Metodologije razvoja informacionih sistema

Razlozi neuspjenih projekata IS su razliiti,a a mogu se iz vojiti slje edi: sloenost aplikacija, ne ostatakusmjerenosti korisniku, zanemarivanje okruenja organizacije, pretjerani optimizam, izostanak pradenjanapretka i ned ostatak komunikacije izmeu korisnika i izvoaa. Meu najedim uzrocima moe se

pretpostaviti a su: loa organizacija i voenje projekata, oslonac na vanjske projektante i savjetnike,delegirano upravljanje projektima, nerealno planiranje, formalno izvj etavanje o napretku, formalnina zor na projektom, kao i po cijenjena uloga vlastitih strunjaka.

Ne treba iskljuiti i slje ede uzroke neuspjeha: loa izve ba projekata, neo govarajuda analiza sistema,greke u izajnu i kontroli kvaliteta, neo govarajudi CASE alati i krivo koritenje, pa ak i svojevrsnazloporaba CASE alata. Mnogi sistemi su propali, ili su bili o baeni, jer su se izvoai tru ili napravitilijepa programska rjeenja, a nisu razumjeli sutinu poslovnog sistema i poslovanja.

Da bi se poboljala uspjenost IS potrebno je:

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

Korisnik poznaje poslovni proces i zna odrediti potrebe, a projektant upoznaje poslovanje i zna kakoizra iti IS. Vano je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnimmogudnostima i koristima uvoenja IS, naroito jer onosi konane (za poslovni sistem su bonosne)o luke. Sve ovo navo i na potrebu koritenja o reene meto ologije razvoja I S.

Metodologija razvoja informacionih sistema (IS) treba a bu e opta, primjenljiva na sisteme bilo kojevrste, o nosno na neki "opti sistem". Zahtjeva a se precizno efinie ta se po pojmom ISpodrazumjeva, koje su njegove funkcije i kakav je njegov poloaj u sistemu u kome jeluje. Meto ologijase moe efinisati kao meto a + i ejni pristup. Sa ri u sebi kolekciju proce ura, tehnika, alata iokumentacionih pomagala, potkrijepljenih filozofijom, koji potpomau izgra nju informacionih sistema

[Avison & Fitzgerald, 1995].

Meto ologija pre stavlja skup naela izra e IS, koji se u o reenoj situaciji svo i na meto u je instvenoprikladnu toj situaciji [Checkland, 1994]. Komponente meto ologije se mogu razvrstati u slije edih pettaaka:

1)

etape projekta,2) zadaci za svaku pojedinu etapu,3) izlazi (projektna dokumentacija),4) oreporuke (vo i) upotrebe o abranih tehnika i pomagala, 5) nain upravljanja projektom i na zorom projekta.


15/24

1

Cilj meto ologije je a omogudi sistemski postupak razvoja kojim de se modi pratiti napredak, uspostavikomunikaciju izmeu uesnika ukljuenih u izgra nju IS (poslovo stvo, korisnici, analitiari, programeri),osigura skup tehnika koje de omoguditi a se za aci izvravaju na stan ar ne i provjerene naine,osigura efikasan nadzor sa cil jem uoavanja greaka u ranim fazama. Osim nave enog, cilj meto ologije je a omogudi elastine promjene poslovanja i tehnologije (npr. o vajanjem analize i oblikovanja),

uokviri razvojnu strategiju kojom de se ukloniti ad hoc rjeavanje problema, o re i ili ukae ka a i u

kojoj mjeri je potrebno ukljuivanje korisnika, te potie i omogudava ukljuivanje korisnika ka a se za toukae potreba.

Meto ologija omogudava a se ovoljno panje posveti analizi poslovanja, ime de se osigurati izra asistema koji od govara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti greku u ranimfazama, jer je lake popraviti okumentaciju nego mijenjati programski k . Izmjene u kasnijim fazamazahtjevaju promjene rezultata pretho nih faza. Lake je pronadi greku tokom faze u kojoj je nastala,nego traiti je i popravljati na osnovu poslje inih uinaka primijedenih u kasnijim fazama.

Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su:

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).

Primjena neke o ovih meto ologija ne znai a de IS biti obar! Zahtjevi korisnika se mogu mijenjati uvremenu. Preporuene aktivnosti ne moraju uvijek biti prikla ne, primjenjive ili potrebne. Insistiranje naprovoenju propisanih proce ura vo i u zanemarivanje stvarnih problema, to za poslje icu moe imatiformalno dobro na pravljen, ali neuspjean sistem.


16/24

1

Vedina meto ologija je namijenjena analizi i oblikovanju. Rijetke meto ologije po ravaju sve fazeivotnog ciklusa (npr. IEM). Meto ologije treba a su po rane o govarajudim alatima za upravljanje iprojektovanje (CASE), to nije uvijek ispunjeno u praksi. Alternative komercijalnim meto ologijama jez rav razum, najbolje okazano u praksi, preice o rjeenja problema zasnovane na slinim iskustvima,kao i prilagoavanje razvojnog procesa.

Modeliranje je proces razvoja modela. Model nastaje procesom apstrakcije u kojem se prvo birajurelevantni objekti koje reprezentacija treba a sa ri, a zatim svakom objektu pri ruuju relevantnaobeleja koja se ele prikazati u okviru mo ela. Dakle, mo el procesa efinie re oslije ra zvojnih faza io reen je pristupom (para igmom) koja se primjenjuje. Model je pojednostavljena predstava orelevantnim karakteristikama sistema. Model je reprezenta cija nekih objekata, veza izmeu objekata iobiljeja (svo jstva, osobine, atributi), objeka ta i veza. Direktno postoji samo sistem, a svaka naapredstava o sistemu je model. S obzirom da je informacioni sistem model realnog sistema u komedjeluje, postupak projektovanja informacionog sistema svodi se na neku vrstu modeliranja realnogsistema.

Modeliranje podataka je proces koji po inje utvr ivanjem i analiziranjem potreba korisnika zainformacijama, a zavrava izgra njom stabilne ali prilago ljive baze po ataka. Stoga mo el po atakapojednostavljeno prikazuje karakteristike sistema preko skupa entiteta (objekata), njihovih atributa iveza. Pojedinim fazama izrade modela podataka odgovaraju razli ite razine apstrakcije i tuma enjapo ataka, pa se moe razlikovati:

konceptualni model podataka, logi ki model podataka, i fizi ki model podataka.

Konceptualno modeliranje provo i se u fazama stratekog planiranja informacijskog sistema. Dobrooblikovan konceptualni model zadovoljava sljede a na ela:

jedan podatak pohranjen je na jednom mjestu, po aci moraju biti to je vie mogu e me usobno neovisni.

Izvor podataka za izradu konceptualnog modela je dijagram tijeka podataka (dokumenata) izra en natemelju analize postoje ih i potrebnih po ataka. Za njegovu izra u u pravilu je na lean a ministratorpodataka.

Logiko modeliranje je definiranje logi kog modela podataka budu deg informacionog sistema. Proizlazi

iz konceptualnog modela i sastoji se od: oblikovanja logi kog modela podataka informacionog sistema ili nekog njegovog dijela

uporabom modela entiteti-veze, provjere logi kog modela u odnosu na konceptualni model i zahtjeve korisnika, vrednovanja logi kog modela od strane korisnika, i prevo enja modela entiteti-veze u logi ku shemu baze podataka (uglavnom na relacijski jezik)

primjenom pravila prevo enja.


17/24

1

Posao logi kog modeliranja obavlja se u suradnji administratora podataka i administratora bazapodataka.

Fiziko modeliranje podataka polazi od logi kog modela i definira fizi ku organizaciju baze podatakakoja je izabrana za odre eni informacijski sistem. Za taj posao na lean je a ministrator baze po ataka.

Model procesa je skup procesa koji mijenjanu stanje sistema i procesa pomodu kojih se formiraju izlazi izsistema. Realizovan na raunaru mo el procesa je skup programa koji auriraju bazu po ataka i skupprograma za izvetavanje. Stanje o objektima iz realnog sistema u informacionom sistemu predstavljamopo acima o tim objektima gra edi model podataka . Baza po ataka je fizika realizacija mo elapodataka. Za realizaciju informacionog sistema potrebni su i resursi kao nosioci informacionog sistema.To su npr: oprema, organizacione jedinice, radnici. Resursi potrebni za realizaciju informacionog sistemaopisuju se modelom resursa .

Metoda je propisan i jedno znano efinisan nain koritenja sre stava o nosno izvrenja nekogpostupka. Metoda je sveobuhvatna i detaljna verzija cijelog modela razvoja sistema, sa jasnospecificiranim poslovima za poje inu fazu razvoja i tehnikama koje de se korostiti. Meto a ukljuuje skupprocedura, tehnika, alata i dokumentacije koji su potrebni za razvoj IS. Sre stva ine fizika oprema, jezici i alati kojima se izvrava za atak o nosno vri operacija. Ov e demo po sre stvimapodrazumeva ti prvenstveno grafike jezike.

Osnovnu informacionog sistema ini baza po ataka (BP). Baza po ataka se moe efinisati kao kolekcijame usobno povezanih podataka koja modelira (prikazuje) objekte, veze objekata i veza posmatranogrealnog sistema. Ulazni podaci koji djeluju na informacioni siste m prihvataju se procesima za auriranje

baze podataka. Procesi za izvravanje, na osnovu baze podataka i ulaznih podataka, generiu izlaze izinformacionog sistema. Stanje realnog sistema se mijenja zbog djelovanja niza procesa. Ove procese izrealnog sistema opisujemo modelom procesa u informacionom sistemu.


18/24

1

Radni dijagram (workflow)

Radnim dijagramom prikazuje se slijed odvijanja procesa u nekom sistemu (najede u poslovnomsistemu). Procesi koji se odvijaju prema nekom redoslijedu prikazuju poslovnu tehnologiju sistema, aposlovna tehnologija sistema je o reena pravilima i proce urama koje su usvojene u tom sistemu.

Dakle, tehnologija rada je automatizacija procesa ili toka rada gdje dokumenti, informacije ili zadaciprelaze od jednog sudionika ka drug om na nain a su upravljani pravilima ili proce urama. Zbognave enih konstatacija se moe zakljuiti a radni dijagram (dijagram toka rada) prikazuje tehnologijurada i obino se izrauje najmanje va puta za svaki proces . P rvi puta se nacrta postojede stanje, znaikako se o reeni posao obavlja u trenutku analize. Drugi crte obino se ra i nakon to se prove estandardizacija procedura, dokumentacije i podataka. Ponekad se uspije provesti i preoblikovanjeposlovnih procesa, tako da se taj drugi radni d ijagram moe znaajno razlikovati o prvog.

esto se koriste razliite oznake za crtanje worflow ijagrama, a u vedini sluajeva se koriste oznake kojesu prikazane na slici.

Slika. Primjer simbola za kreiranje radnih dijagrama

Ra ni ijagram grafiki prikazuje proce ure ra a koje ne moraju nuno biti automatizirane. esto sezaboravlja da postoje poslovi u sustavu koji iz raznih razloga nede biti informatizirani, a o kojima trebavo iti rauna ka a se analizira sustav i projektira informacijski sustav. Ra ni ijagram prikazuje teprocese i upozorava g je je mogude kasnije usko grlo u poslovnoj tehnologiji. Na temelju razmatranjaradnog dijagrama ponekad se mogu promijeniti redoslijedi prioriteta izgradnje informacijskihpo sustava, jer se moe lake uoiti njihov utjecaj na cjelokupno poslovanje.

Odluka

Poetak Prekid

Proces

Bazaodataka

Spoj

Dokument

Runaoperacija

Zasloni

Tok procesa


19/24

1

Slika. Primjer radnog dijagrama kod Internet trgovine za prodaju cvijea


20/24

2

Slika. Primjer radnog dijagrama varijanta 1


21/24

2

esto se koriste i prilagoeni prikazi ra a, npr. ka a se eli upravi kompanije prezentirati opdatehnologija ra a, bez za iranja u etalje. Na taj nain se koncipira osnovna tehnologija, o reujupotrebe za resursima, uoavaju neloginosti u poslovanju kao i potrebe za intervencijama. Danasostupniprogramski alati za crtanje omogudavaju brzo skiciranje ra ne tehnologije. Primjer takvog

dijagrama je dat na slici.

Slika. Primjer radnog dijagrama varijanta 2


22/24

2

U praksi se zbog kvalitetnijeg i razumljivijeg prikaza veza meu organizacijskim ijelovimafirme koristimodel poslovnih procesa (MPP). U MPP procesi se dodjeljuju organizacijskim jedinicama (internim ilivanjskim) ili pojedincima ili grupama - plivade staze (eng. swim lines ) i njima su definiraneodgovornosti ( eng. Role ) za svaki proces.

Slika. Primjer primjene modela poslovnih procesa

GantogramiKako bi se bilo koji projeka t mogao u potpunosti uspjeno realizirati potrebno je to tanije isplaniratisve projektne aktivnosti. Postoje razliiti alati koji nam pomau u izra i plana projekta, a jedan odnaina je primjena Ganttov dijagrama (gantogram, Ganttov grafikon i M eto a grafikog prikazivanjainformacija). Ganttov dijagram je dobio ime po Henry-u Laurecu-u Gantt-u (1861- 1919), nauniku iininjeru koji ga je osmislio 1917. Gantogram je, u osnovi, ijagram koji se sastoji okoordinatnog sistema, u kojem je horizontala vrijeme, a vertikala resursi na kojima se odvijajupojedini radni nalozi, po operacijama i vremenom poetka i zavretka svake operacije. Dakle, zagantograme se moe redi a pre stavljaju metodu grafikog prikazivanja informacija koju se esto koristiza utvrivanje raspore a aktivnosti. Ganttov ijagram moe biti je nostavna verzija: grafikon iscrtanna papiru ili kompleksna automatizovana verzija izraena koritenjem programskih aplikacija poputMicrosoft Projector, GanttProject ili Excel.

Tipini Ganttov ijagram grafiki prikazuje pogreke u za atku, vr ijeme potrebno za kompletnu izraduza atka kao i procenat uraenog ela za atka. Svaki stubid (linija) pre stavlja je an zadatak svremenskim vre nostima, a re ovi sa raj za ataka. Gantogrami ilustriraju poetni i krajnji atumnekih nepromj enjivih i saetih elemenata projekta.


23/24

2

Uz projektno vrijeme vano je uzeti u obzir i vremensku rezervu. To je vede raspoloivo vrijeme oonog to je potrebno a bi se obavi la neka aktivnost. Najede se pojavljuje ko onih aktivnosti ko jenisu na kritinom putu. Kritini put je put koji u projektu traje naj ulje, o nosno zbroj trajanjaaktivnosti u njima je najvedi. Dakle, vremenska rezerva je zapravo vrijeme kojemu ne-kritina aktivnostmoe biti o goena bez a se o go i cijeli projekt.

Slika. Prijmer Gantograma

Bitno je napomenuti a ne mora biti samo je an kritini put. Ukoliko ih je vie, posebna panjase posveduje voritima ili no s. vorita ta a pre sta vljaju aktivnosti koje su zaje nike viekritinih puteva. Ukupno vrijeme potrebno ili p re vieno za o vijanje svih procesa u sustavu je

sustavno vrijeme, akle on a bi najkrade sustavno vrijeme bilo vrijeme kritinog puta. Vano je shvatitirazliku izmeu realnog tj. stvarnog vremena i planiranog vremena. Oni se takoer mogu paralelnoprikazivati na gantogramu jer pre stavljaju logike suprotnosti.

Naravno, bitni elementi za prikaz su i milestones/oznaivai koji su v ani ogaaji koji predstavljajuodnose aktivnosti , te oznauju poetak tj. kraj. Gant t bars ili poloeni stupci su glavni pokazatelj protokavremena unutar grafikona za neku aktivnost, na njima se milestones (prekretnice) postavljaju kaomarkeri tj. pokazivai vanih ogaaja. Sve to moe biti povezano linijama povezivanja. Dodatne linijesu linije koje pokazuju ovisnosti izmeu aktivnosti u projektu.


24/24

Slika. Primjer dinamikog plana I faze realnog projekta

Prednosti gantograma su:

preglednost i razumljivost, jednostavna i laka izrada (za mali broj aktivnosti), je nostavno prikazivanje zavrenosti.

Nedostaci gantograma su:

tekoda u izra i i nepregle nost ko velikog broja aktivnosti, ne vo i rauna o resursima ko rasporeivanja aktivnosti, prikazivanje zavrenosti je neprecizno i teko je znati ukupnu zavrenost u traenom trenutku, podaci koji se dobiju iz gantograma su nedovoljni za kontrolu odvijanja realizacije, pomodu njega je teko uoiti uvjetovanost poje inih aktivnosti.

zivotni ciklus is-a

Documents