SEMINARSKI RAD

Predmet: Informacioni sisemi

TEMA:

Razvoj informacionih sistema

MENTOR: STUDENT:

Doc. 799/10-V

Pojam razvoja informacionih sistema

Razvoj racunarske tehnologije i informacionih tehnologija uopte, koincidirao je sa porastom populacije korisnika, irenjem informacionih zahteva i promenama koje karakteriu savremeni stil ivota, a posebno savremeno poslovanje. U razvoju informacionih sistema centralno mesto zauzima razvoj softvera. Uopte posmatrano, trend rasta informacionih potreba i razvoja informacionih tehnologija nije praen adekvatnim razvojem programskih proizvoda, pa neki autori ovakvu situaciju karakteriu i kao softversku krizu. Razvoj programskih proizvoda, kao disciplina se od sedamdesetih godina prolog veka zove i softversko inenjerstvo, a zapravo se odnosi na metodoloki pristup razvoju ovih proizvoda sa ciljem da se u zadatim vremenskim rokovima, primenom odreenih tehnika projektovanja, dostigne potreban kvalitet finalnog proizvoda.Osnovni problemi razvoja i upravljanja razvojem informacionih sistema jesu problemi savladavanja njihove sloenosti i realizacije softverskih reenja koja su adekvatna potrebama sistema. Korienjem sledea dva metodoloka principa moe se savladati sloenost sistema:

dekompozicija sloenog sistema na manje, lake savladive delove podela celokupnog procesa razvoja informacionog sistema na faze.Za dekompoziciju sloenog sistema na manje, lake savladive delove koristi se strukturalni pristup i objektno-orijentisani pristup. Strukturirani pristup je opta tehnika u realizaciji programskog proizvoda i moe se koristiti u okviru faza snimanja i analize, projektovanja i dekomponovanja sloenog sistema na manje sloene podsisteme, nezavisna izgradnja podsistema,integracija nezavisno izgraenih komponenti u jedinstvenu celinu i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.Na raspolaganju su razni CASE alati koji se koriste u struktuiranom pristupu i koji su se poslednjih dvadesetak godina intenzivno razvijali. Struktuirani pristup razvoja informacionih sistema zasnovan je na specifikaciji funkcija sistema, dok je objektivno-orijentisani pristup zasnovan na injenici da sistem predstavlja skup meusobno povezanih objekata, gde se stanje sistema sagledava kao stane objekata posmatranog sistema, a operacija nad objektima kao realizacija funkcija sistema. Danas se u razvoju informacioni sistema sve vie koristi objektivno-orijentisani pristup.

Faze razvoja informacionih sistemaKoristei se analogijom sa ivim organizmima smatra se da upravljaki informacioni sistemi nastaju, rastu, sazrevaju i nestaju, pa se taj proces naziva izrazom "ivotni ciklus sistema", koji u pojedinim sluajevima moe trajati samo nekoliko meseci, a u drugim nekoliko godina. ivotni ciklus informacionog sistema zasnovan na informacionim tehnologijama ukljuuje nekoliko faza: planiranje

analiza

dizajn

implementacija

odravanje

Planiranje razvoja informacionih sistema je jedna od najznaajnijih i najteih funkcija u savremenom menadmentu. Planiranje razvoja informacionih resursa neke organizacije zahteva postizanje arhitekturalnog okvira u koji e posebni delovi sistema biti skladno uklopljeni i koji e omoguiti etapni razvoj informacionog sistema i da razne posebne podsisteme u organizaciji mogu da izgranuju razni timovi ljudi, da se uspeno planiraju i racionalno koriste neophodni i raspoloivi resursi. Osnovna svrha planiranja i postavljanja arhitektualnog okvira jeste postizanje konzistentnosti informacija. Pod planiranjem se ovde podrazumeva racionalno odabiranje i postavljanje ciljeva, odabiranje strategije, politike, programa, projekata i akcija za njihovo postizanje, pri emu je cilj shvaen kao eljeno budue stanje koje organizacija nastoji da postigne u razvoju svog informacionog sistema.

Analiza informacionog sistema je druga po redu faza u procesu ivotnog ciklusa razvoja informacionog sistema. Analizom se nastoje doznati vane informacije o tri kljuna aspekta analize:

a) analiza i opisivanje objekt-sistema,

b) analiza postojeeg informacionog sistema, i

c) identifikacija poslovnih i korisnikih informacionioh zahteva.

Dizajn informacionog sistema treba da u potpunosti odgovori na pitanje: kako e sistem omoguiti zadovoljavanje informacionih potreba korisnika? U ovoj fazi razvoja sistema koncipira se logiki model novog sistema, razvija model i projektuje baza podataka, razvija model procesa, specifikuju manuelne i automatizovane procedure, projektuju ulazno/izlazne ekranske forme, izvetaji, tampana dokumenta, procedure dijaloga korisnika sa sistemom, specifikacija raunarskih programa i dizajn programskih modula, dizajn sistema kontrole i mnogi drugi aspekti i detalji dizajnerskog posla. Dizajn sistema moe biti definisan kao crtanje, oblikovanje, planiranje, skiciranje, odnosno araniranje mnogih posebnih elemenata i njihovo slaganje u monu i jedinstvenu celinuImplementacija informacionog sistema je veoma znaajna i u veini sluajeva, sa stanovita krajnjih korisnika, kljuna faza razvoja. Moe sistem biti planiran, analiza sprovedena, dizajn zamiljen i realizovan na zavidnom ekspertskom nivou, ali e njegova funkcionalnost i uspenost zavisiti od naina planiranja i realizacije njegove implementacije. Takav plan i njegova realizacija obuhvata mnoge vane aspekte implementacije:

a) priprema implementacije,

b) implementacija i testiranje tehnologije,

c) programiranje,

d) testiranje programskih proizvoda,

e) testiranje inputa, autputa, baza podataka i kontrolnih procedura,

f) edukacija korisnika,

g) konverzija sistema.

Proces razvoja informacionih sistemaRazvoj informacionih sistema je sloen i dugtrajan proces koji podrazumeva niz faza i aktivnosti, od planiranja razvoja do zastarevanja sistema, od njegove zamene i povlaenja iz upotrebe. Neophodno je dobro projektovati i pripremiti uvoenje informacionog sistema i zato to njegov razvoj predstavlja znaajnu finansijsku investiciju, kako u obliku dugoronih investicija, tako i u obliku neposrednih trokova.

Model razvoja informacionih sistemaSoftverski inenjering ine skupovi koraka koji ukljuuju metode, alate i procedure. Ti koraci su zasnovani na razvojnim principima i upuuju na modele razvoja softvera u softverskom inenjeringu. Model razvoja se odabira u zavisnosti od prirode projekta i aplikacije, tehnike orijentacije ljudi koji e uestvovati u razvoju, metoda i alata koji e se upotrebljavati pri razvoju, naina kontrole i samih proizvoda koji se zahtevaju. Principi razvoja obzirom na metodoloke korake se meusobno razlikuju po tome koliki znaaj pridaju pojedinim fazama u razvoju softvera, koliko ih detaljno posmatraju i u kojem redosledu izvravaju. Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki softverski sistemi i prikazuju razliite poglede na proces razvoja softvera. Osnovni razlog njihove pojave je bila elja da se obezbedi uoptena ema razvoja softvera, koja bi sluila kao osnova u planiranju, organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju aktivnostima razvoja softvera. Uopteno, modeli su apstrakcije koje pomau u procesu razvoja softvera. Primarni cilj kreiranja modela je da se obezbede softverski proizvodi koji odgovaraju zahtevima korisnika.

U zavisnosti od znaaja koji se pojedinim fazama i aktivnostima razvoja softvera pridaje, zatim forme organizacije i upravljanja razvojem, kao i iskustva zaposlenih prirode proizvoda, razlikuju se:

Preskriptivni modeli razvoja konvencionalni modeli sa delimino razliitim tokom procesa razvoja ali sa istim generikim aktivnostima;

Model vodopadaInkrementalni modeli razvoja:

Inkrementalni model,

RAD model,

Razvojni modeli:

Model prototipskog razvoja,

Spiralni model,

Istovremeni model razvoja (Concurrent Development)

Specijalizovani modeli:

Model zasnovan na komponentama,

Model zasnovan na formalnim metodama,

Model unificiranog procesa razvoja (Unified Process)

Modeli agilnog razvoja:

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

Scrum

Feature Driven Development (FDD)

Agile Modeling (AM)

Model vodopada

Model je uveo W. Royce 1970. godine. Prema njemu razvoj softvera zahteva sistematian pristup jer se odvija po strogo definisanom sekvencijalnom redosledu koraka postepenim prevonenjem rezultata od prve do poslednje faze razvoja softvera. Razvoj zapoinje na sistemskom nivou da bi se nastavio preko analize, projektovanja, kodiranja, testiranja i zavrio odravanjem. Faze i aktivnosti razvoja prema ovom modelu su sledee:

Analiza i definisanje zahteva sistema - Obzirom da softver predstavlja samo deo nekog sistema, rad na razvoju softvera zapoinje definisanjem zahteva prema svim elementima sistema i alociranjem jednog dela adekvatnih i odrenenih zahteva prema softveru. Ovaj sistemski pogled je posebno znaajan kada se softver povezuje sa ostalim elementima strukture kao to su hardver, menver (organizacija i zaposleni), podaci i dr.

Analiza i definisanje zahteva softveru Ovom fazom i njenim aktivnostima se intenzivira prikupljanje specifinih i posebnih zahteva softveru. Da bi softverski inenjer razumeo prirodu softvera koji treba razviti, on mora razumeti domen koji informacija ima za softver kao i zahtevane funkcije, performanse i menusobne veze. Projektovanje ili dizajn softvera - Projektovanje softvera je faza razvoja koju ini vie aktivnosti, a koje se fokusiraju na nekoliko aspekata razvoja softvera: korisniki interfejs, ulazne ekranske forme, izlaze, bazu podataka, procedure obrade i sistemsku kontrolu. Ova faza prevodi zahteve korisnika u odreneni softverski proizvod koji se moe oceniti sa aspekta kvaliteta pre nego to zapone kodiranje. Kodiranje Ovom fazom se izvrava zadatak prevoenja rezultat projektovanja u mainski prepoznatljivu formu. Ukoliko je projektovanje uraeno dovoljno detaljno, tada se kodiranje obavlja mehaniki.

Testiranje - Kada se jednom izgenerie kod programa, tada zapoinje njegovo testiranje. Testiranje se svodi na unutranju logiku softvera, sa ciljem da se svi iskazi provere odnosno da se proveri da li su isti tani. Takoe, testiranje se svodi i na spoljnu funkciju softvera, da bi se otkrile greke i proverilo da li e definisani ulazi proizvesti rezultate koji se podudaraju sa identifikovanim zahtevima.

Odravanje - Softver e sigurno pretrpeti odrenene izmene nakon to se distribuira korisniku. Potrebe za izmenama se javljaju zbog proirenja funkcija ili performansi koje zahteva korisnik, zbog potreba da se softver prilagonava promenama koje uzrokuje promenjeno okruenje ili zbog razvoja tehnologija koje se upotrebljavaju.

Primena ovog modela se predlae u sledeim situacijama:

prilikom razvoja softvera koji je po osnovnim karakteristikama jedinstven i ima zadatak da zadovolji posebne zahteve korisnika, koji jo do tada nisu realizovani u sistemima drugih organizacija i ne mogu se ire upotrebiti,

kada korisnik jednoznano moe definisati svoje zamisli i potrebe u odnosu na softver, koji na toj bazi izgranen ne sadri suvine komponente i funkcionie veoma brzo i uspeno, postoji dovoljno vremena i strpljenja kod korisnika za dugi period razvoja i

visoki razvojni trokovi i saobrazno potrebna finansijska sredstva nisu ograniavajui faktor razvoja.

Slabost modela je nedostatak povratne sprege izmenu koraka koji nisu sukcesivni i ne odvijaju se u sekvencijalnom redosledu. Takoe, kao nedostaci se navode sledee injenice:

realni projekti veoma retko prate modelom definisani sekvencijalni tok, a iteracije uvek izazivaju ili se kod njih javljaju problemi u primeni modela,

uvek je teko za korisnika da u poetku rada na razvoju softvera navede eksplicitno sve svoje zahteve (a to model zahteva), jer se teko prilagoava neizvesnosti koja uglavnom egzistira na startu,

kupac mora biti veoma strpljiv i istrajan jer e mu radne verzije programa biti dostupne tek na kraju aktivnosti razvoja softvera,

greke koje se ne otklone u fazi testiranja programa, mogu imati stravino distorziono dejstvo na projekat razvoja.Inkrementalni model

U ovom modelu razvoja se prvobitno potpuno razvija inicijalni podskup funkcija softvera, a zatim se sukcesivnim koracima razvijaju, kao nadgradnja prethodnog koraka, stalno novije i komplikovanije verzije. Projektovanje softvera se izvodi u prvom koraku, ali se uvonenje softvera odvija sukcesivnom razradom (usavravanjem inicijalnog podskupa). Softver se razvija malim dodacima (inkrementima) kojima se moe jednostavno i lako upravljati. Svaki inkrement dodaje postojeem softveru pojedine nove funkcije, pri emu se postojee zadravaju. Prednost ovakvog razvoja je u tome da se dodaci odnosno nove funkcije lake razumeju i testiraju. Korienje mogunosti da se stalno dodaju nove funkcionalnosti softverskom proizvodu, daje mogunost ugradnje bogatog korisnikog iskustva u redefinisani proizvod na manje skup nain. Ovaj model predstavlja kombinaciju klasinog modela ivotnog ciklusa softvera sa iterativnim mogunostima razvoja. On takone obezbenuje nain da se periodino distribuira auriranje i odravanje softvera razliitim korisnicima. Posebno je popularan i koriste ga u softverskim kuama.Model prototipskog razvojaModel prototipskog razvoja se koristi da bi se za potrebe korisnika razvio inicijalni model budueg softvera koji simulira njegove stvarne funkcije sa ciljem da korisnik da svoje miljenje i odlui koji i kakvi su njegovi zahtevi. Kod razvoja softvera po ovom modelu korisnik ve u najranijem stadijumu moe videti na koji e se nain zadovoljiti njegovi zahtevi. Komponente razvijenog softvera esto predstavljaju samo korisniki interfejs. Implementacija kostura ovog interfejsa je sa eljom da se obezbedi mogunost za povratnu spregu od korisnika, pre nego da se specificira i projektuje konana verzija reenja. Model obino prihvata neku vrstu funkcionalne specifikacije softvera kao ulaz, koji se simulira, analizira i izvrava. Ova tehnologija omoguuje da aktivnosti projektovanja softvera budu inicijalno preskoene ili premotene. Takoe, omoguuje da se brzo izgrade primitivne verzije softvera, koje kasnije korisnik moe i sam razvijati. Kljuna prednost ovog modela je to stalno obezbenuje radne verzije sistema koje razvija i to u veoj meri od drugih modela angauje korisnika na razvoju, te unaprenuje kvalitet procesa.Model prototipskog razvoja se najee upotrebljava i daje solidne rezultate u situacijama:

kada su od strane korisnika samo uopteno definisani ciljevi razvoja softverskog proizvoda, ali ne i detalji u pogledu ulaza, procedura i izlaza,

kada je mogue simulirati rad softvera da bi korisnik mogao videti kako e budui softverski proizvod funkcionisati i

kada same razvojne organizacije ele proveriti efikasnost algoritama ili adaptibilnost sistema.

Prototipski razvoj omoguuje onome koji razvija softver da kreira model softvera. Model uobiajeno moe imati tri oblika:

prototip u obliku papira koji opisuje vezu oveka i maine na nain da korisniku omogui razumevanje tog odnosa,

radni prototip koji implementira neke od funkcija postavljenih kao zahtevi softverskom proizvodu ili

realni program koji izvrava deo ili celinu zahtevanih funkcija.

Ovaj model ima i svoje nedostatke odnosno primena modela prototipskog razvoja moe biti diskutabilna iz dva razloga:

Korisnik uoava radnu verziju softvera neznajui na koji su nain delovi softvera menusobno povezani, neznajui da u brzini realizacije nisu razmatrani aspekti kvaliteta ili odravanja u duem vremenskom periodu. Kada done do informacija da je potrebno izvriti "remont" ili dalju dogradnju jo ne uvedenog softverskog proizvoda, korisnik se osea prevarenim i insistira da se putem izvesnih intervencija brzo realizuje njemu potreban proizvod. Upravljanje razvojem softvera u ovakvim situacijama postaje nekontrolisano.

Projektant esto ini kompromise u implementaciji sa ciljem da izgraneni prototip to pre stavi u funkciju. Neadekvatan operativni sistem ili programski jezik se jednostavno upotrebljavaju samo zato to su raspoloivi ili poznati; neefikasan algoritam se primenjuje samo da bi se demonstrirala sposobnost softvera. Nakon izvesnog vremena, zaboravlja se na nain odabira i njihove uzroke te ovako manje idealna reenja ili bolje reeno manje kvalitetna reenja ostaju integralni deo konanog softverskog reenja.

Zbog toga, znaajno je da se projektant i korisnik, u cilju efikasnosti ovog modela, dogovore i definiu pravila igre na poetku procesa razvoja softvera. Drugim reima oni se moraju sloiti da se prototip razvija kao mehanizam za definisanje zahteva, a softver se razvija u cilju zadovoljenja kriterijuma kvaliteta i mogunosti odravanja.

Spiralni model

Spiralni model je razvijen od. B Boehma 1988. godine, da bi se objedinile dobre osobine modela vodopada i modela prototipskog razvoja uz istovremeno ukljuivanje aktivnosti analize rizika. Model se predstavlja spiralom na kojoj su definisane etiri faze razvoja:

planiranje faza koju ine aktivnosti odrenivanja ciljeva, alternativa i ogranienja,

analiza rizika faza koju ine aktivnosti analize alternativa i identifikovanja rizika,

inenjering faza razvoja novih nivoa proizvoda i

ocenjivanje faza procene rezultata inenjeringa.

Posmatranjem spirale, svakom iteracijom se progresivno razvijaju kompletnije i potpunije verzije softvera. Tokom prvog ciklusa kretanja spiralom, prikupljaju se zahtevi i planira projekat razvoja, da bi se izvrila analiza rizika inicijalnih zahteva. Ukoliko analiza rizika indicira neizvesnosti u zahtevima, tada se moe upotrebiti prototipski razvoj da bi se zahtevi detaljnije spoznali. U iste svrhe, mogu se koristiti simulacija ili druge vrste modela.

Svaki ciklus razvoja na spirali, zahteva analizu rizika i donoenje odluke "nastaviti" ili "ne nastaviti" sa daljim razvojem. Ukoliko je rizik isuvie velik i ulaganja nesrazmerno visoka u odnosu na efekte koji se oekuju, terminira se dalji rad i zadrava u upotrebi proizvod nastao u prethodnom ciklusu ili prethodnim ciklusima. Svaki novozapoeti ciklus spirale donosi kompletniji proizvod, ali i znaajnije i vie trokove.

Tipina raspodela vremena, za koja ipak treba rei da variraju od ciklusa do ciklusa, je:

planiranje i dizajn 20%,

procena rizika 5%,

realizacija (sa testiranjem) 40%,

revizija 15% i

ocenjivanje 20%.

Model omoguuje brzu reakciju na uoene rizike, a primenom prototipskog razvoja prua mehanizam za njihovo smanjenje. Tako se primenom ovog modela rizici mogu smanjiti pre nego to izazovu vee probleme i velike trokove. Model podrava sistematski pristup preuzet iz modela vodopada uz mogunost izvonenja iteracija. I pored velikog broja prednosti, model poseduje i nedostatke. Nedostatak ovog modela je odsustvo veze prema postojeim standardima, odnosno ne postojanje standarda za ovaj nain razvoja softvera. Takoe, model zahteva vie uniformnosti i konzistentnosti u razvoju. Velike probleme stvara situacija kada se na vreme ili uopte ne otkriju rizici. Konano, model je relativno nov i nije bio iroko primenjivan. Stoga, bie potrebno jo dosta vremena da se sa vie sigurnosti i verovatnoe prine njegovoj ozbiljnijoj primeni.

Model zasnovan na komponentama

Osnovni pristup u ovom modelu je konfigurisati i specijalizirati ve postojee komponente softvera u novi aplikativni sistem. Meutim, osobine komponenti zavise od njihove veliine, kompleksnosti i funkcionalnih mogunosti. Veina pristupa pokuava da iskoristi sline komponente obzirom na zajednike strukture podataka sa algoritmima za njihovu manipulaciju. Drugi pristupi pokuavaju da iskoriste komponente funkcionalno slinih kompletnih sistema ili podsistema kao to su korisniki interfejs. Postoje i brojni naini iskoriavanja softverskih komponenti za razvoj softverskih sistema. Svi ovi pokuaji i nastojanja zagovaraju inicijalnu upotrebu ve uranenih komponenti u specificiranju strukture ili detaljnom dizajnu komponenti radi ubrzavanja postupka implementacije. Ove komponente se mogu upotrebiti i pri prototipskom razvoju softvera ukoliko je raspoloiva takva tehnologija. Viestruko korienje softvera je proces ukljuivanja u novi proizvod pojedinih komponenti:

prethodno testiranog koda,

prethodno proverenog dizajna,

pretnodno razvijene i koriene specifikacije zahteva i

prethodno korienih procedura za testiranje.

Koristi koje sa sobom donosi ponovno korienje komponenti razvijenog softvera su sledee:

podie robustnost softvera,

poveava produktivnost izrade softvera,

poveava kvalitet softvera,

smanjuje trokove razvoja softvera,

tedi odnosno skrauje vreme izrade,

zadovoljava ciljeve softverskog inenjeringa,

iri korienje softvera,

obezbenuje adekvatnu dokumentaciju,

olakava odravanje softvera,

modelira sistem za lake razumevanje i dr.Model unificiranog procesa razvoja

Za razliku od prethodno opisanih modela razvoja softvera, Ivar Jacobson, Grady Booch i James Rumbaugh su 1999. godine objavili USDP model unificiranog procesa razvoja softvera. Ovaj model opisuje proces razvoja korienjem UML - objedinjenog jezika za modelovanje u objektno-orijentisanom razvoju softvera.

Ovaj model se zasniva na 3 osnovna principa - osnovu ine dijagrami sluajeva korienja, u centru modela se nalazi njegova arhitektura koja sazreva sa razvojem novih dijagrama korisnika i razvija se kroz iteracije koje donose nove inkremente konanog proizvoda. Sutinski posmatrano, u svakoj od iteracija odvijaju se analiza, projektovanje, implementacija i testiranje proizvoda. Prema autorima, model se moe opisati kao proces klasificiranja iteracija, koje se mogu podeliti u 4 grupe:

u prvoj grupi se nalaze poetne iteracije interakcija sa stekholderima, tj. znaajnim uesnicima u razvoju softvera,

drugu grupu sainjavaju razranene iteracije elja i potreba korisnika,

iteracije konstruisanja inicijalnih operacionih mogunosti sainjavaju treu grupu i

prelazne iteracije kompletiranja proizvoda su etvrta, konana iteracija razvoja softvera prema ovom modelu.Agilni modeli razvoja

esta kanjenja projekata razvoja softvera, probijanje budeta i postavljenih vremenskih rokova u njihovoj realizaciji, permanentni rast sloenosti tehnologije i uestale promene korisnikih zahteva, doveli su krajem dvadesetog veka do pojave novih modela razvoja. Nastali su agilni modeli, po osobinama mnogo gipkiji i prilagodljiviji promenama, koji omoguuju korisnicima aktivno uee tokom svih faza i aktivnosti razvoja. Agilni pristup se dakle suoio sa osnovnim problemom savremenog i ujedno brzog razvoja softvera. Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme i trokove razmene informacija izmenu osoba koje uestvuju u razvoju na nain da skrate vremenski period od donoenja odluke do povratne informacije o posledici te odluke. Polazne pretpostavke agilnih modela su bile da je turbulentnim poslovnim i tehnolokim okruenjima neophodan proces razvoja softvera koji istovremeno kreira promene, ali brzo i odgovara na iste. Istovremeno, proces koji ukljuuje odgovorne uesnike i njihovu dobru organizaciju. Uesnicima odnosno njihovom talentu, vetinama i sposobnostima, kao i njihovoj menusobnoj komunikaciji se poklanja posebna panja. Usmerenost na uesnike je i najznaajnija osobina agilnih modela, prema pojedincima se prilagonava i kompletan proces razvoja.

U agilnim razvojnim timovima, kompetencije pojedinaca predstavljaju kritian faktor uspenosti projekta. Prema agilnim modelima, ukoliko su pojedinci na projektu dovoljno kvalitetni, tada oni mogu uz bilo koji proces razvoja realizovati oekivani cilj. U suprotnom, nema procesa razvoja koji moe nadomestiti njihovu nekompetentnost. Istovremeno, nedostatak korisnike podrke moe lako unititi projekat razvoja, kao to i neadekvatna podrka moe spreiti zavretak projekta.

Agilni razvoj nije prikladan za sve situacije. Nametanje agilnih principa procesno usmerenim i nekooperativnim organizacijama ne dovodi do uspeha. Nametanje izuzetno promenljivog procesa mirnim i staloenim timovima, vodi sigurno raspadu tima. Takoe, agilni razvoj se teko izvodi u timovima sa veim brojem lanova. Najvie uspeha u agilnom razvoju pokazuju timovi do devet lanova. Agilni razvoj se pokazao kao uspean u ekstremnim, kompleksnim i visokopromenljivim projektima. Okruenje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na ljude i saradnju.

Kombinovani modeli

Napred opisani modeli su uglavnom prikazivani kao alternativni, a manje kao komplementarni modeli softverskog inenjeringa. Meutim, u mnogim situacijama modeli se mogu kombinovati tako da se postignu prednosti od svih na samo jednom projektu. Spiralni model je i sam primer dobre kombinacije dva modela, ali i drugi modeli mogu posluiti kao osnova na koju e se integrisati neki modeli.Ne treba biti dogmatian u izboru odrenenog modela u softverskom inenjeringu. Priroda aplikacije e diktirati model koji bi trebalo primeniti. Kombinovanjem modela, rezultat postignut u celini moe biti povoljniji nego to bi to bio prosti zbir rezultata postignutih pojedinim modelima.ivotni ciklus softvera

Razvoj softvera predstavlja ciklus aktivnosti u razvoju, korienju i odravanju softvera. Tokom ivota, softver prolazi kroz vie faza razvoja: od zaetka, preko inicijalnog razvoja, produktivnog funkcionisanja, odravanja do povlaenja. ivotni ciklus razvoja softvera mogao bi biti karakterisan sledeim aktivnostima:

Inicijalizacija sistema je aktivnost u kojoj se navodi poreklo softvera. Primarni cilj inicijalizacije je realizacija novog softvera kojim se zamenjuju ili dopunjuju postojea softverska reenja.

Analiza i specificiranje zahteva je aktivnost u kojoj se identifikuju problemi koje je potrebno reiti novim softverom. Proces softverskog inenjeringa odreuje ta se mora uiniti da bi se problemi reili. Podaktivnosti ove aktivnosti su: identifikacija zahteva, analiza i predstavljanje zahteva i razvoj kriterijuma i procedura za prihvatanje novog softvera.

Specifikacija funkcija je aktivnost u kojoj se identifikuju i formalizuju podaktivnosti kao to su: definisanje predmeta obrade, identifikovanje atributa i veza objekata i operacija koje transformiu ove objekte I utvrnivanje ogranienja koja odrenuju ponaanje softvera.

Strukturiranje delova i izbor je aktivnost kojom se na osnovu identifikovanih zahteva i specifikacije funkcija strukturira softver na takve delove kojima se moe upravljati, a koji predstavljaju logike celine. Nakon toga se vri izbor I opredeljenje, da li novi, postojei ili softverski sistem koji se moe ponovo koristiti odgovara takvim celinama.

Specifikacija strukture je aktivnost u kojoj se definiu menusobne veze izmenu delova strukture i interfejs izmenu modula sistema, na nain koristan za njihov detaljni dizajn i upravljanje celokupnom konfiguracijom. Specifikacija detaljnih komponenti dizajna je aktivnost u kojoj se definiu procedure putem kojih se izvori podataka svakog pojedinog modula transformiu iz potrebnih ulaza u zahtevane izlaze.

Implementacija komponenti i otklanjanje nedostataka je aktivnost u kojoj se kodiraju dizajnirane procedure i procesi i pretvaraju u izvorni kod.

Integracija i testiranje softvera je aktivnost koja afirmie i odrava celokupnu integralnost komponenti softvera putem verifikacije konzistentnosti i kompletnosti uvedenih modula, verifikujui izvorni interfejs, vezu softvera sa specifikacijama i uporenujui performanse sistema i podsistema sa identifikovanim zahtevima.

Provera dokumentacije i uvonenje softvera je aktivnost koja obuhvata izradu sistemske dokumentacije i uputstava za korisnika. To su dokumenta koja su po formi pogodna za proveru i kao podrka sistema.

Obuka i upotreba je aktivnost koja obezbenuje korisnike softvera sa instrukcijama i uputstvom za razumevanje mogunosti i ogranienja u cilju efektivne upotrebe sistema.

Odravanje softvera je aktivnost koja podrava operacije sistema u ciljnom okruenju na nain da obezbedi potrebna unaprenenja, proirenja, popravke, zamene i dr. Odravanje je stalni proces koji se realizuje putem iteracije aktivnosti koje mu prethode.

Povlaenje softvera je poslednja aktivnost u ivotnom ciklusu. To nije ni malo jednostavna aktivnost jer se softver razmatran kao beskoristan ipak smatra proizvodom koji bi se mogao u delovima ponovo upotrebiti. One komponente softvera koje su ve jednom testirane su ekonomski pogodnijeod novih koje e se tek razvijati.

Ovakav konceptualni model na visokom stepenu apstrakcije primenjen u razvoju softvera se naziva ivotnim ciklusom softvera. On predstavlja optu metodologiju, kod koje se za realizaciju pojedinih aktivnosti razvoja primenjuju razliite metode, uz primenu razliitih modela razvoja softvera.

Resursi informacionih sistema

Informacioni sistem je sociotehniki sistem koji upotrebljava, organizuje i efektivno i efikasno koristi odreene resurse.

Resursi informacionog sistema su:

a) ljudski resursi

b) hardverski resursi

c) softverski resursi

d) resursi podataka i

e) resursi raunarskih mrea.

Ljudski resursi su neophodni za funkcionisanje informacionih sistema. IT specijalisti i krajnji korisnici IS ine ljudske resurse. IT specijalisti su ljudi koji razvijaju, implementiraju, ocenjuju i odravaju IS. Ljudski resursi su organizovani u IC (Informacionom centru) i zavisno od dimenzija organizacione strukture IC, a pre svega od podele rada, mogu biti: projektanti informacionih sistema, sistem analitiari, programeri, administratori baza podataka, softver inenjeri, specijalisti za hardver i mree, operateri i drugi. Strunjaci ovih profila vre odrenene poslove, izvravaju konkretne radne zadatke. Krajnji korisnici su ljudi koji koriste informacioni sistem i njegove informacione produkte u svakidanjem radu. To mogu biti menaderi, analitiari, inenjeri, istraivai, komercijalisti, raunovoe, tehniko osoblje i drugi. Veina zaposlenih u organizaciji su krajnji korisnici informacionog sistema.

U hardverske resurse spadaju celokupni raunarski resursi koji tehniki podravaju rad informacionog sistema. Raunarski sistemi: serveri baza podataka (veliki i raunari opte namene), serveri aplikacija (mini raunari), radne stanice (mikro raunari), periferne jedinice (tampai, tastature, monitori, magnetni i optiki itai i drugi), elektromagnetni mediji za smetaj podataka (diskovi, diskete, optiki diskovi, magnetne trake), zajedno ine integralnu tehniku podrku i hardverski resurs informacionih sistema.

Softverski resursi ukljuuju sve vrste programskih instrukcija i procedura. Operativni sistemi, programi prevodioci, sistemi za upravljanje bazama podataka, statistiki paketi, OLAP softver i mnogi korisniki programi (aplikativni softver) predstavljaju resurs informacionih sistema od ogromnog znaaja i znaajnu intelektualnu investiciju organizacije. Niz procedura koje upuuju korisnika kako da koristi svoj IS, su takone znaajan softverski resurs. Podaci, informacije i znanje su resurs ne samo IS, nego i organizacije, podjednako vaan kao i drugi resursi. Ovaj resurs se esto organizuje u bazama podataka (podaci i informacije), dimenzionalnim bazama podataka u Data Warehouse (ekstrahirani i agregirani podaci i informacije), bazama znanja, Knowledge Warehouse i dr.

Resursi raunarskih mrea, lokalnih i globalnih, sa aktivnom i pasivnom mrenom opremom, urenajima i instalacijama, su okosnica telekomunikacionog podsistema informacionog sistema. Telekomunikacione mree, kao to su intranet, ekstranet i internet, su postale neminovnost uspenog funkcionisanja organizacije i integralnih informacionih sistema. Ovi resursi ukljuuju:

a) komunikacione medije, kao to su koaksijalni kablovi, fiber-optiki kablovi, mikrotalasni

sistemi, satelitski komunikacioni sistemi i dr.b) mrenu opremu: ruteri, svievi, modemi, habovi, razne vrste prikljuaka i druga mrena

oprema

c) komunikacioni kontrolni softver.

Integracija informacionih sistema

Informacioni sistem organizacije treba da je integralan, da integrie sve funkcije, procese i sve vrste informacionih sistema. Integracija se postie, pre svega, kroz kompozitni ili cross/function sistem, koji daje potporu svim poslovnim funkcijama, procesima, aktivnostima, operacijama i podrava odluivanje svih nivoa menadmenta i koji ima integrisane informacione resurse koje koriste sve aplikacije i korisnici. Mnogi autori smatraju da akronim MIS ukljuuje sve vrste informacionih sistema. OLTP je najznaajniji izvor podataka za druge sisteme, gde su DW, pre svega, a zatim MIS i EIS, primarni primaoci podataka. DW je centralno spremite podataka i izvor za razvoj aplikacija u sistemima kao to su MIS, DSS, EIS. Podaci se, prema tome, razmenjuju izmeu pojedinih vrsta informacionih sistema i u kontekstu drugog sistema koriste za striktne namene. Uvek se postavlja pitanje: kako, koliko iroko i vrsto sistem treba integrisati? Odluku o stepenu integracije bi trebalo zasnivati na jasnim kriterijumima i preciznim merama integracije. Najvanije je u inegracionom konceptu postii efektivan i efikasan tok podataka i informacija izmenu pojedinih sistema. Integracija je kompleksan proces, prouzrokuje znaajne trokove, zahteva vreme i znanje, i ima svoje, ne male, trokove operativnog funkcionisanja. Svaka organizacija mora imati svoj pogled na integraciju, i ne postoji "taan nivo" integracije koji se moe preporuiti. Drugo pitanje se tie ivota i smrti informacionog sistema. Koristei se analogijom sa ivim organizmima, smatra se da ovakvi informacioni sistemi zasnovani na raunaru nastaju, rastu, sazrevaju i nestaju, pa se taj proces oznaava izrazom "ivotni ciklus sistema" koji u pojedinim sluajevima moe trajati samo nekoliko meseci, a u drugim nekoliko godina. Ugrubljeno posmatrano, ivotni ciklus informacionog sistema zasnovanog na raunaru ukljuuje nekoliko faza: planiranje sistema, analizu i oblikovanje sistema, testiranje i odravanje sistema, implementaciju, kontrolu i ocenjivanje sistema.

CASE alati

Primena objektnog ili strukturiranog pristupa razvoju sistema se najee odnosi na crtane razliitih dijagrama. Svaka izmena jednog dijagrama mora da bude praena izmenom dijagrama koji su u nekoj relaciji sa njime, tako da sloenost sistema, a time i dijagrama koji ga opisuju, uslovljava metod izrade dijagrama: manuelno je izvodljivo projektovanje jednostavnijih sistema sa nekoliko desetina, ne vie od sto, entiteta. U suprotnom, runo modeliranje sloenijih sistema, izrada konzistentne projektne dokumentacije i kontrola kmpletnosti projekta, sa aspekta vremena i trokova projektovanja, mogunosti percepcije i koncentrisanosti ljudi iz projektnog tima, a posebno sa stanovita kvaliteta takvog rada, postaju neizvestan i nepredvidiv poduhvat. Kod manuelnog projektovanja greke se kasno uoavaju i onda ih je teko otkloniti.Da bi se prevazisla brojna ogranienja manuelnog projektovanja, ali i mogunosti projektovanja prilagodile potrebama razvoja veoma sloenih sistema, razvijeni su softverski proizvodi- alati, namenjeni podrci i automatizaciji izvizvravaanja zadataka u postupku izrade softverskih proizvoda. Nazvani su CASE alati, prema skraenici od rei na engleskom jeziku Computer Aided Software Engineering, to bi u prevodu znailo kompjuterski podran softverski inenjring.CASE alati su zamiljeni da obezbede zadovoljavajui kvalitet izrade softverskog proizvoda i softverskog proizvoda i projektne dokumentacije, kao i realizaciju samog projekta. Upotreba CASE alata treba da omogui poveanje produktivnosti projektnog tima, skrati vreme projektovanja i programiranja i omogui jednostavno i jeftino odravanje softverskog proizvoda. Da bi se postigli ovi ciljevi, CASE alati su koncipirani tako da obezbede to vii stepen automatizacije u obavljanu razliitih zadataka:

izradi dijagrama projektovanju konceptualne i implementacione eme baze podataka

projektovanju programskih specifikacija aplikacija

generisanju programskog koda

sprovoenju izmena

integraciji percijalnih rezultata projektovanja u konzistentnu celinu voenju projektne dokumentacije

kontroli konzistentnosti, kompletnosti i kvaliteta projekta i dr.CASE alati pomau korisnicima prilikom izrade specifikacije zahteva, sa svim dijagramima i definicijama svih entiteta. Treba istai da CASE alate ne ine samo alati koji pomau u prvim fazama razvoja sistema, kao to su analiza i projektovanje. CASE alati omoguavaju i generalisanje koda. Ovi alati su naroito pogodni za brzi razvoj sistema, metodom izrade prototipa. pomou njih se moe brzo izraditi korisniki interfejs, specificirati izgled ekrana i formirati izvestaji i to u saradnji sa korisnicima sistema. Potom generator koda, koji je sastavni deo CASE alata, automatski generie potreban programski kod.Stupanj razvijenosti informacionog sistema

Razvoj novih informatikih tehnologija ne samo to omoguava da se pobolja efektivnost i efikasnost procesa rada koji se tim tehnologijama podrava, nego implikuju promene u tom procesu rada, a evolucionistiki model razvoja informacionih sistema - kojeg je razvio Richard Nolan sa saradnicima - smatra se jednim od poetnikih pokuaja prouavanja interakcije informacionih tehnologija i poslovnih procesa. Nolanov model nastao je 1974. godine na osnovu empirijskog istraivanja na zaunujuem malom broju organizacija.Nalazi istraivanja su ukazali da su sve organizacije koje su poele da se koriste raunarskom tehnikom suoene sa vrlo slinim problemima i da krivulja budeta odeljenja za IT sledi oblik latinskog slova "S". Ta krivulja moe da se podeli u etiri razliita dela koji predstavljaju etiri stupnja razvoja na raunarima zasnovanog informacionog sistema kroz koje svaka organizacija mora da proe: inicijacija, ekspanzija (kontagion), formalizacija i zrelost. Model je na osnovu rezultata dodatnih istraivanja, na neto veem broju organizacija, inoviran 1979. godine tako to je u model ukljueno nekoliko novina:

Prihvatanje ideje da se upravljanje kompjutacijom u organizaciji moe razvrstati u dve kategorije. Prvoj je svojstvena stroga usmerenost na obezbenivanje efikasnosti upotrebe kompjutacije, a drugoj odsustvo stroge usmerenosti na efikasnost upotrebe kompjutacije;

Zastupanje uverenja da se krivuljom S oblika moe opisati i krivulja uenja organizacije u nastojanju da uspeno kontrolie kompjutaciju;

Promena usmerenosti na upravljanje podacima organizacije kao resursom;

Uvonenje jo dva stupnja razvoja i u toj verziji model operie sa sledeim stupnjevima: inicijacija, ekspanzija, kontrola, integracija, administracija podataka i zrelost.Novijom verzijom iz 1979. godine razvoj modela nije okonan. Najnoviji razvoj modela ukljuuje tranziciju ka eri savremenih informacionih struktura, novih informacionih tehnologija i doputa formiranje modela sa vie od est razvojnih stupnjeva. Ipak, u ovom tekstu autori e zadrati Nolanov koncept od est stupnjeva, ali opisujui ih izvriemo neke inovacije u tim opisima, kao logika posledica osvedoenih tranzicija. Inicijacija je poetni stupanj uvonenja elektronske obrade podataka, nabavlja se raunarska i druga oprema sa svrhom da se neki obimniji i/ili sloeniji procesi obrade podataka automatizuju i da se smanje funkcionalni trokovi. Uloena sredstva u opremu i trokovi odravanja su relativno mali, oprema je rasuta po pojedinim odeljenjima, a najee je locirana u sektoru za raunovodstvo i finansije. Znanja korisnika su niska, planiranje i kontrola obrade podataka slabi, a organizacioni modaliteti funkcije automatske obrade podataka su po pravilu usredsreneni na specijalistiko tehnoloko uenje.Ekspanzija je faza koja je prirodni nastavak prethodne i koja znaajno proiruje primenu sistema automatske obrade podataka na mnoga nova podruja u organizaciji. irenje primene informacionih tehnologija je posledica uvinanja mnogih prednosti koje ona omoguava. Razumljivo je da time raste i volumen ulaganja i trokovi funkcionisanja neplanskog I nekontrolisanog irenja i primene takone rastu. U ovoj fazi rasta primetan je povrni entuzijazam, planiranje i kontrola su jo slabiji, ali znaajna novina je zapoljavanje korisniki orijentisanih programera i znaajnija proliferacija portfolio aplikacija.

Kontrola je ponajvie znaajna po planiranju i nadzoru automatske obrade podataka u organizacijama. Menadment uvina da nekontrolisano rastu ulaganja i trokovi funkcionisanja i odravanja, i zato nastoje da formalizuju planiranje i kontrolu, entuzijazam se svodi u normalne okvire, pojaava se korisnika odgovornost, organizacioni modaliteti se uzdiu na nivo sredinjeg menadmenta, vri se upgrade dokumentacije i restruktuiranje postojeih aplikacija, menadment nastoji da neki pravci razvoja idu u smeru podrke odluivanju i menadmentu.

Integracija je pristup povezivanja ranije parcijalno razvijenih i zasebnih aplikacija, mogu zahvaljujui razvoju informacionih tehnologija i neophodan sa stanovita razvoja menadmenta organizacije. Integracija postojeih aplikacija je mogua, pre svega, zahvaljujui razvoju tehnologije baza podataka. Uspostavljaju se sistemi planiranja i kontrole, snai proces uenja o odgovornosti, formiraju se timovi za sprovonenje korisnosti raspoloivih informatikih resursa i racionalne korisnike upotrebe i rauna. Faza integracije je zaetak procesa razvoja integralnih informacionih sistema.

Administracija podataka je faza radikalne promene pristupa i pogleda na razvoj informacionih sistema. Podaci i informacije se shvataju kao jedan od resursa organizacije, koji stoji na raspolaganju svim korisnicima, koji dele korisnici, koji je podjednako vredan kao i drugi resursi i kojim treba odgovorno i svrsishodno upravljati. Posebno zanimanje se javlja za ulogu administratora baza podataka, svesnost korisnika se uzdie na nivo efektivne odgovornosti, sistem je organizaciono integralna celina, podravana savremenim informacionim arhitekturama, koje podrazumevaju savremene raunarske mree, razliite softverske platforme, klijent/server aplikacije, proliferaciju verzija obrade podataka, konektivnost sistema i obezbenivanje standarda za konektivnost. Zrelost je esta, poslednja faza Nolanovog modela. Akceptirana je integrisana i podeljena odgovornost osoblja informacionog centra i korisnika, podaci, informacije i informacioni sistem su strategijski resursi koji se planiraju, upravlja se izvorima podataka, a portfolio aplikacije su integrisano "ogledalo" informacionih tehnologija. Razvoj potpuno integrisanih sistema se oslanja na paradigmu planiranja resursa organizacije, DSS (Decision Support Systems) aplikacije se razvijaju na podlozi nove informatike arhitekture DW (Data Warehouse) sistema i primat preuzima poslovna inteligencija. Procenjivanje uspenosti informacionog sistemaPostoji nekoliko kompleksa i klasifikacija kriterijuma za ocenjivanje kvaliteta i uspenosti informacionog sistema organizacije: pregled kriterijuma koji su dali DeLone i McLean, pregled kriterijuma koji predlau Bailey i Pearson kriterijum koje navode Avison i Fitzgerald Burch i Grudnitski i drugi. Kriterijumi ocenjivanja kvaliteta i uspenosti informacionog sistema koji se tiu zadovoljstva korisnika informacionim sistemom se u okviru koncepcije TQM smatraju vrhunskom validacijom informacionog sistema. O relativnoj znaajnosti pojedinih kriterijuma uspenosti informacionog sistema ima vrlo malo empirijskih istraivanja. Dobijene rezultate ocenjivanja kvaliteta i uspenosti informacionog sistema organizacije treba statistiki obraditi i iz dobijenih statistika izluiti vredne informacije radi validacije informacionog sistema. Statistike procedure za analizu rezultata dobijenih skalom za ocenjivanje IS mogu biti: aritmetike sredine i standardne devijacije za svaku stavku, interkorelacije stavki, viestruka regresija stavke/skala, pouzdanost skale (Cronbachova alfa), analiza varijanse, komponentna i faktorska analiza, i druge.