Cilj svake metodologije i metode razvoja informacijskog sustava je izgraditi i uvesti uspješan sustav čiji se uspjeh može pripisati izvršenju ciljeva sustava i produktivnosti, odnosno sustav treba zadovoljiti utvrđene zahtjeve, biti razvijan na vrijeme i unutar planiranih financijskih sredstava. Da bi se otkrio nedostatak jedne ili više metoda u postizanju navedenih ciljeva, treba istraživati zapreke postizanja kvalitete i produktivnosti.

Kvaliteta informacijskog sustava procjenjuje se prema tome da li sustav zadovoljava točno određene zahtjeve. Poteškoće mogu biti slijedeće vrste:

• Definicija zadatka nije dobra i rješava se drugi problem. Zahtjevi korisnika u kasnim fazama projekta su u raskoraku s njihovim utvrđenim zahtjevima na početku projekta ili su u raskoraku s drugim korisničkim zahtjevima. Zahtjevi mogu uključivati neprimjećeni problem u implementaciji koji se otkrije tek kasnije u procesu razvoja. Zahtjevi se stalno mijenjaju zbog vanjskih događaja kao što su promjene zakona ili političke okolnosti.
• Prihvatljivost i lakoća korištenja nisu zadovoljavajući. Sustav bi trebao biti koristan i prihvatljiv, kreirajući alat koji će korisnici moći lako koristiti kako bi lakše postigli ciljeve koji su vezani za njihov posao, i tako povećavajući njihovo zadovoljstvo s poslom.
• Ne analiziraju se potrebne informacije za odabrani posao. Pitanje je treba li se usmjeriti na formulaciju problema i njegovo rješavanje ili na rješenje projekta cjeline u kojoj će problemi nestati.
• Pokretač posla je politički element a ne unapređenje posla i kontrola projekta je slaba. Plan aktivnosti treba biti baziran na strategiji poslovanja a suprotnosti pojedinaca i njihovi pojedinačni ciljevi treba rješavati konsenzusom.

3.1 Mijenjanje zahtjeva i postupni razvoj u metodici MIRIS

Ako je definicija zahtjeva pogrešna, onda takav mora biti i razvijeni sustav. Često se zahtjevi mijenjaju iz slijedećih razloga:

• Korisnici ne znaju svoje zahtjeve;
• Korisnici se ne slažu oko svojih zahtjeva;
• Problemi u komunikaciji između analitičara i korisnika potiču nerazumijevanje onoga što će sustav donijeti u vezi sa zahtjevima;
• Organizacijsko okruženje se promijenilo u vremenu dok je sustav bio u razvoju.

Prema Boehmu i njegovom promišljanju "razvijanje sustava iz zahtjeva slično hodanju po vodi - lakše je kada je zaleđeno". Smrzavanje zahtjeva u obliku nekog ugovornog dokumenta je obrambeni pristup od strane odjela za IS, koji samo potkrepljuje analitičarov stav da sustav radi ono za što je specificiran, što još uvijek ne mora biti ono što korisnik treba. Prototipiranje je korak koji će dozvoliti nekoj povratnoj vezi da prilagodi promjene u zahtjevima naknadnim razvojnim aktivnostima.

U slučaju velikih sustava poželjan je postupni razvoj i postupna isporuka pojedinih izvedbenih projekata. Ovo uključuje podjelu sustava da bude razvijen/isporučen u samozaustavljive, funkcionalne i korisne dijelove koji mogu biti isporučeni u relativno kratkom vremenskom periodu. Skraćeno vrijeme isporuke prati manje promjene zahtjeva i lakše je održavanje manjih izmjena.

Psihološki posljedica je povećana motivacija razvojnog tima kroz pozitivnu korisničku povratnu vezu i pojačano povjerenje korisnika u one koji razvijaju. Poteškoće kod postupnog razvoja svode se na pitanje kako podijeliti sustav i odrediti prioritete pojedinih izvedbenih projekata. Na ova pitanja odgovara analiza u glavnom projektu.

Pitanje je kako postići konsenzus zahtjeva za novi sustav pomoću sudjelovanja, rasprave i spajanja korisničkih pogleda sa rješavanjem razlika među korisnicima za iste funkcije na različitim lokacijama, ako izmjena funkcija zadire u povijest i traži izmjenu prošlih ugovora. Postupni razvoj u uvođenje po lokacijama korisnika jedino je moguće rješenje.

Neuočeni problemi najbolje se rješavaju postupnim razvojem.

© Mile Pavlić, Ris d.o.o. Rijeka