ANALIZA ZAHTEVA U RAZVOJU SOFTVERA REQUIREMENT ANALYSIS IN SOFTWARE DEVELOPMENT

Olga Risti, Vlade Uroevi Tehniki fakultet, aak Sadraj - Pri razvoju bilo kog sloenijeg softverskog projekta, neophodno je definisati precizno sve faze ivotnog ciklusa softvera. Ovde je poseban znaaj dat prvoj fazi razvoja, prikupljanju zahteva od naruioca, jer od njega zavise i ostale faze. Ukoliko u ovoj fazi nastanu propusti i greke, one e se provlaiti i kroz ostale faze i negativno uticati na realizovanje softvera. Zbog toga je neophodno precizno definisati zahteve od naruioca, te zahteve ako je mogue zapisati i u tom obliku analizirati zajedno sa naruiocom, kako bi bili sigurni da su zahtevi precizno definisani. Ukoliko doe do greaka, poveae se vreme potrebno za njihovo otkrivanje u narednim fazama ivotnog ciklusa, a samim tim i trokovi se viestruko uveavaju. Abstract - In developing any complex software project, it is necessary to precisely define all the phases of the software life cycle. Here is a special significance given the first stage of development, raising the request of the stakeholder, because of the subject and the other phases. If at this stage arising omissions and errors, they will wriggle through the other stages and negatively affect the software realization. It is therefore necessary to define precisely the requirements of the customer, and requests if possible record in the form of review, together with stakeholder, to ensure that requirements are precisely defined. If errors, increase the time needed for their discovery in the coming phases of the software life cycle, and therefore the costs are increased manifold. 1. UVOD Termin softversko inenjerstvo se prvi put pojavio 1968 godine na NATO konferenciji u Nemakoj. Poslednjih 30 godina, softversko inenjerstvo predstavlja metaforu za proces razvoja softvera. Softversko inenjerstvo je danas prihvaeno kao akademski pojam i koristiti se na velikom broju univerziteta koji poseduju naune oblasti tog tipa, ili pak predmete koji imaju ovo ime. Projekti vezani za softversko inenjerstvo odnose se na definisanje ovog pojma i jedna od definicija je prema IEEE: Softversko inenjerstvo predstavlja primenu semantike, ureenosti, odreenog prilaza pri razvoju, izradi i odravanju softvera, a to znai primenu inenjerskih principa na razvoj softvera. Poto se softver koristi sve vie i preuzima vitalne funkcije u organizacijama i drutvu, znaajno je da bude to pouzdaniji, efikasniji i da postoji mogunost izmene, dopune itd. Softversko inenjerstvo je nelinearno. Na slici 1 je prikazano da vei projekti uglavnom mogu biti izraeni u potpunosti za 12 meseci. Jedan od uzroka nastanka softverskih greki je da se ne potuje raspored izrade projekta, kao i da je procena kompletnosti projekta loa. Proizvod softverskog inenjerstva je softverski sistem.
%

Vreme u mesecima

Slika 1. Realizacija softvera za 12 meseci Softver koji se razvija mora zadovoljiti zahteve naruioca. Gotovo da ne postoji softver bez greke. Za neke softvere, broj greaka nee uticati na kvalitet i rad samog softvera, dok u nekim sluajevima, greke mogu izazvati katastrofu. Zbog toga je neophodno da se potujui metodologiju razvoja softvera unapred precizno definiu faze razvoja softvera, zatim, tim koji e razvijati softver, sa preciznom podelom posla, a pored ostalog potrebno je utvrditi i vreme koje je potrebno da bi se razvio softver. Nije isto kada se vri razvoj softvera za neku svemirsku letilicu i za obraun plata u nekoj organizaciji. U oblasti softvera osnovni problem je bio u tome to je slonost problema za raavanje rasla bre od tehnologije za razvoj softvera. Cena softvera zavisila je vie od rada nego od tehnologije, tako da je ljudski rad potreban za razvoj softvera bio proporcionalan veliini (sloenosti) softvera. Kako se sloenost softvera u toku godina poveavala, poveavao se i ljudski rad potreban za njegov razvoj. 2. FAZE IVOTNOG CIKLUSA SOFTVERA Termin ivotni ciklus softvera se odnosi na organizacionu emu procesa konstruisanja (razvoja) softvera. Mada se ovaj pojam moe definisati na razne naine, a osnovni cilj je da se na kraju dobije kvalitetan softver. ivotni ciklus u obliku vodopada (waterfall) je obino precizno definisan i ne moe se menjati. Kod ovog oblika realizacija softvera ide od vrha prema dnu, iz jednog koraka ivotnog ciklusa u drugi. Osnovna

mana ovog tipa ivotnog ciklusa je to se nekad sloeni sistemi i procesi predstavljaju suvie pojednostavljeno. Meutim, dobri softverski inenjeri gotovo nikad se ne pridravaju striktno svakog koraka u toku razvoja ivotnog ciklusa softvera, jer je esto potrebno promeniti samo redosled izvoenja nekih koraka. Rukovodstvu na viem nivou odgovara ovaj prilaz jer mogu jednostavno pratiti sve faze razvoja softvera. Softverski eksperti, esto zanemaruju direktive rukovodee strukture, pa neke korake u razvoju ivotnog cikusa koriste vie puta. Ovakav spiralni ivotni ciklus softvera koji se poslednjih godina sve vie koristi i opisuje u literaturi, sve vie potiskuje waterfall prilaz. Sve faze u razvoju softvera ostaju iste, samo se njihova primena menja. Faze razvoja ivotnog ciklusa softvera su sledee: 1. Zahtevi-slue za definisanje problema koji se reavaju 2. Projektovanje (modeliranje)-najkreativniji deo ivotnog ciklusa softvera u kome se utvruje sloenost u toku procesa razvoja softvera 3. Kodiranje-predstavlja osnovu u softvera jer se pie kod programa toku razvoja

Da bi se razumeli zahtevi ne bitno je da li se koristi agilno inenjerstvo, ekstremno programiranje, prototipsko programiranje, modeliranje ili neka druga metodologija. Najbitnije je da se ispravno definiu zahtevi i da naruioc to razume, ili softver nee biti od koristi, bez obzira to su ostale faze u razvoju softvera perfektno odreene. Faza prikupljanja zahteva treba da obuhvati istraivanje funkcionanosti i ponaanja softvera koji se razvija. U procesu prikupljanja zahteva je dat opis zahteva koji e se koristiti kao ulaz u fazu projektovanja softverskog proizvoda. Prikupljanje zahteva je znaajna faza u razvoju softverskog proizvoda, pa je neophodno obratiti posebnu panju da se razume sve to je neophodno da bi se krenulo u narednu fazu razvoja softvera (projektovanje). Da bi se isporuio koristan i primenljiv softverski proizvod, sa najniim trokovima za organizaciju, ova fazu razvoja softvera je najznaajnija. Zbog toga se nastoji da se u ovoj fazi utvrde potrebe posla koji e softver obavljati, tako da se ti zahtevi kasnije u fazi projektovanja konkretizuju u plan. U fazi projektovanja se odreuju alati za programiranje, ureaji koji se koriste i kako e biti konstruisani. Pravilno prikupljeni zahtevi e uticati da se ostale faze minimalno kasnije dorauju. Na slici 2 je prikazan proces prikupljanja zahteva kao deo ivotnog ciklusa razvoja softvera. Proces prikupljanja zahteva utvruju rad i odreuje koji proizvodi najbolje pomau u radu. Kao izlaz iz ovog procesa, specifikacija zahteva obezbeuje kompletan opis potrebnih funkcionalosti i ponaanja proizvoda. Modeliranje sistema stvara radne modele funkcija i podataka neophodnih za softver, kao i modele koji su neophodni za prikupljanje zahteva. Projektovanje softvera pretvara abstraktnu specifikaciju i projekat koji je pogodan u svarnosti. Ovaj dijagram treba sagledati kao iterativan proces. Kompletna specifikacija zahteva se uglavnom ne proizvodi pre poetka projektovanja i konstrukcije.
elje i potrebe korisnika Informacije o oceni Predvieno radno okruenje Zahtevi Modeli Specifikacija zahteva Informacije o projektu Testiranje i otklanjanje greaka Prikupljanje zahteva

4. Otklanjanje greaka-Ne postoji ni jedan softverski proizvod imalo sloeniji koji nema greaka. Ova faza je povezana sa narednom. 5. Testiranje-softver se izvrava na jednostavnim primerima kako bi se utvrdilo da li radi ono to se od njega zahteva i da li su sve greke ispravljene. 6. Ocenjivanje softvera-ima za cilj da utvrde da li je testiranje dobro izvedeno i da li je dobijen kvalitetan softverski proizvod. 7. Odravanje-poslednja faza ivotnog ciklusa koja je ujedno i najznaajnija, jer ako je neophodno izvriti izmene u softveru, potrebno je da se projektuje tako da su mogue izmene na to jednostavniji nain. 3. TA SU ZAHTEVI? Ako realizatori softvera razumeju ta softver treba da postigne za krajnjeg korisnika i kako da postigne taj cilj, onda e brzo i efikasno odraditi projekat. Da bi se sve to razumelo, neophodno je da se razume vrsta posla koju e obavljati softver za svog korisnika i kako e uticati na rad i postii odgovarajui cilj. ta softver obavlja za korisnika i koja ogranienja mora zadovoljiti predstavljaju zahteve softvera. Osnovno je da se razumeju zahtevi korisnika softvera bez obzira o kom se poslu radi, da li je re o softveru koji se koristi u nauci, trgovini, bankarstvu, za obradu teksta itd. Takoe nije bitno koji e se programski jezik ili razvojni alti koristiti za konstrukciju softvera.

Ocenjivanje i odravanje softvera

Informacije o testiranju

Proizvod

Projektovanje (modeliranje) sistema Model sistema

Kodiranje softvera

Specifikacija projekta

Slika 2. Proces prikupljanja zahteva kao deo ivotnog ciklusa softvera

Kada se proizvod jednom kreira, on se koristi i odmah krene da se razvija. Softver mora imati mogunost proirenja u zavisnosti od novih zahteva korisnika u pogledu funkcionalnosti. Ako se koristi proces gde je funkcionalnost znaajna, takav proizvod e uticati na radnu praksu. Npr. ako su zahtevi fleksibilni, to e uticati na promenu isporuivanja softvera. Razvoj softvera i njegovih zahteva je proces koji se ne moe kontrolisati ili odrediti, ali ga moramo prihvatiti. Softverski zahtevi nisu definitivni u momentu kreiranja softvera. Oni se vremenom menjaju, tako da svi zahtevi moraju biti fleksibilni. 3. PRIKUPLJANJE ZAHTEVA I MODELIRANJE SISTEMA Prikupljanje zahteva i modeliranje sistema je znaajno i kada se posmatra od strane moderatora sistema i od analitara sistema. Na poetku je znaajnija aktivnost prikupljanja zahteva. Analitiar zahteva se orjentie na cilj koji softver treba da ispuni, zaposlene koji e koristiti softver, oblast rada i eljeni izlazni rezultat. Upoznavanje s radom softvera raste vremenom, tako da modeli postaju mnogo precizniji i stvaraju znaajne informacije koje se koriste pri prikupljanju zahteva. Jaz izmeu prikupljanja zahteva i modeliranja sistema varira u zavisnosti od procesa razvoja softverskog proizvoda. Na poetku, modeliranje je minimalno, dok se maksimalno radi na prikupljanju i ocenjivanju zahteva. Kako faze razvoja softvera odmiu tako i aktivnost modeliranja raste. Modeli se mogu koristiti da opiu softver ili princip njegovog rada. U skladu sa tim se koristi kao dnevnik podataka ili neophodan scenario ili prikaz procesa, tako da je pogodna alternativa tekstualnoj specifikaciji. Prednost modeliranja sistema je dobra dokumentovanost. Zato je neophodno praviti modele softvera da bi se razumelo ta taj softver treba da radi. Ono to je najznaajnije jeste da mora postojati veza izmeu modeliranja i prikupljanja zahteva. 4. ZNAAJ FAZE PRIKUPLJANJA ZAHTEVA Softverski proizvod moe biti bilo kog tipa. Da bi se kreirao moe se krenuti i od crtea, a mogu se koristiti open source komponente ili neki drugi programski alati, to naravno zavisi od samog softvera koji se kreira. Neophodno je da se razumeju svih zahtevi pre nego se krene u fazu konstruisanja. Ispravni zahtevi nastaju samo kada se dobro razume ta softver treba da radi. Samo kada su ispravno prikupljeni zahtevi, pravilno e se projektovati i programirati softver, pa e samim tim i zadovoljiti potrebe korisnika. Na alost zahtevi se esto ne razumeju i to je ak prema nekim istraivanjima oko 60% greaka potie iz faze prikupljanja zahteva. Tako da zaposleni u razvoju softvera imaju mogunost da eliminiu veliku koliinu greaka ako detaljno izvre prikupljanje zahteva, a ne da brzo preu u narednu fazu razvoja. Kao rezultat, mnogo puta se desilo da je cena softvera bila mnogo vea, to je

bilo posledica loeg prikupljanja i analize zahteva na poetku razvoja softvera. Samim tim je i kvalitet loiji. Programiranje je konstruisanje reavanja problema. Moe se dobiti vei broj iteracija kao reenje. Bez razumevanja potreba korisnika i predstaviti im reenje u radnom okruenju, samo reenje problema nee biti mnogo bolje od korisnikove percepcije za taj problem. Trokovi dobrog prikupljanja zahteva i analize sistema su beznaajni u poreenju sa trokovima loeg prikupljanja zahteva. Greke koje nastanu u ovoj fazi viestruko uveavaju trokove otklanjanja greaka u narednim fazama razvoja softvera. 5. PROCES PRIKUPLJANJA ZAHTEVA Proces prikupljanja zahteva i specifikacija zahteva se mogu primeniti na skoro sve vrste aplikacija u bilo kojoj vrsti razvojnog okruenja. Bez obzira da li se radi o kreiranju korisnikih sistema, sistema iz povezanih delova, komercijalnih softvera, open source softvera ili izmena u ve postojeem softveru, neophodno je da se istrauje, razumeju i uvode zahtevi. Pri opisu procesa neophodno je od samog poetka koristititi prikupljanje zahteva. U ovoj fazi e se pronai mnogo znaajnih stvari koji e biti realizovani u samom procesu, a koji e uticati na produktivnost i tanost. Hiljade organizacija ve primenjuje ovaj proces u fazama razvoja. Zahtevi kao proces ne mogu se posmatrati u smislu razvoja softvera u obliku vodopada. Softverske firme i korisnici se salu u jednoj stvari, a to je da ako elimo da kreiramo pravi softverski proizvod, neophodno je da se koriste odgovarajui zahtevi. Da bi se pronali i kompletirali zahtevi neophodena je neka vrsta sistematskog procesa. Na slici 3 je prikazan jedan takav proces koji je sveobuhvatan i koji prikazuje aktivnosti i njegove isporuke. Ovde se koristi opis toka podataka na odreeni nain. Kada se posmatra ovaj dijagram, treba imati u vidu da se proces ponavlja i razvija. Svaka aktivnost je predstavljena u pravougaoniku i njegova isporuka (predstavljena dokumentom ili strelicom) je prikazana na slici.
Skup zahteva Zahtevi za eksperiment Prototip zahteva Potencijalni zahtevi Specifikacija zahteva

elje i potrebe Naruioc softvera Templejti zahteva

Potencijalni zahtevi Pisanje zahteva

Formalizovani Prihvatanje potencijalni zahteva zahtev Utvrivanje kvaliteta zahteva Naruioc softvera Odbijanje

Slika 3. Prikaz aktivnosti i isporuka

6. PISANJE ZAHTEVA Osnovni problem u procesu razvoja softvera je nerazumevanje zahteva. Da bi se to izbeglo, analitiari moraju pisati svoje zahteve na analizirani nain i obezbediti da programeri to razumeju da se sloe sa napisanim zahtevima pre nego to krenu u naredne faze razvoja. To znai da analitiari piu zahteve da bi obezbedili da svi koji uestvuju u razvoju podjednako razumeju ta je potrebno da se radi. Moda e se initi da ja zapisivanje zahteva predstavlja tekoe, ali je to jedini nain da bi se obezbedilo davanje znaaja zahtevima kako bi se isporueni softver testirao. Jedino dobra komunikacija izmeu analitiara i programera obezbeuje da se dobijeni softverski proizvod kreira na vreme i ispravno. Analitiari prikupljaju i piu zahteve za naruioce projekta. Tako da zahtevi postaju poslovni zahtevi, tako da se moraju pisati koristei poslovni jezik kako bi i naruioci mogli razumeti i oceniti njihovu ispravnost. Naravno, zahtevi moraju biti u pisanoj formi jer i dizajneri i drugi tehniari mogu precizno napraviti ono to klijent trai. Da bi se obezbedila ova ispravnost i da bi zahtevi bili istestirani, analitiari svakom zahtevi dodaju dodatni kriterijum. To predstavlja merenje zahteva, tako da oni koji testiraju mogu precizno odrediti da li je zadovoljen zahtev. Analitiari koriste razne alate za kreiranje jednostavnih specifikacija. Jedan od najee korienih se odnosi na primenu templejta (ablona) za specifikaciju zahteva i to u obliku kontrolne liste pomou kojih se zapisuje specifikacija dokumenata. Naravno, pisanje aktivnosti nije razdvojeno od aktivnosti, ve je integisano sa aktivnostima koje utvruju prototip i kvalitet. Da bi se dobili ispravni zahtevi, neophodno je aktivnosti posmatrati izdvojene. Alternativa za pisanje funkcionalnih zahteva je formiranje modela. Postoje razne vrste modela, a koji e se koristiti zavisi od modelara. Prvo je neophodno da se razume problem koji se reava. Takoe, treba imati u vidu da modeli ne zadovoljavaju funkcionalne zahteve. Svaki model koji se formira mora biti argumentovan sa ispisanim zahtevima za nefunkcionalne zahteve. Na kraju, mora se razmatrati osnovni razlog zbog koga se zapisuju zahtevi. Zato je neophodno da analitiar dobro razume zahteve, kako bi mogao da ih pravilno ispie. Ako zahtevi nisu razumljivi, i usklaeni sa onim to ele naruioci, onda i bilo kakav pokuaj pisanja zahteva predstavljae nitavne podatke, koji e biti brzo uoeni kada zahtevi dou do procene kvaliteta.

Zapisivanjem zahteva se opisuje softverski proizvod sa poslovne take gledita. Obino se taj opis naziva specifikacija, i taj termin se koristi za bilo koji opis koji je zapisan ili ne. Ova aktivnost se moe smatrati formiranjem specifikacije, gde se zahtevi postupno obrauju deo po deo. Pisanje zahteva se uglavnom izvodi u toku aktivnosti prikupljanja zahteva i formiranju prototipa. Na ovaj nain se ideje konkretizuju u zahteve koji se mogu testirati. To su formalizovani zahtevi. 7. ZAKLJUAK Postavlja se pitanje da li je specifikacija zahteva u ivotnom ciklusu softvera gubljenje vremena i ko ima koristi od toga? Specifikacija zahteva je znaajna za svakoga ko ima bilo kakve veze sa projektom koji se radi. Projektanti znaju ta treba da projektuju, oni koji testiraju, kakav je izlaz koji oekuju. Najvie koristi imaju korisnici jer znaju ta e dobiti kao rezultat na kraju. Obino razvoj softverskog proizvoda poinje kada naruioc utvrdi da su zahtevi dobro prikupljeni. Npr. ako naruioc eli da na sajt o kupovini ukljui listu elja, on e analizirati zahteve i traiti da se doda lista elja, ako ve ne postoji. Na taj nain, sa poveanjem uloge korisnika u kreiranju zahteva, utie se na dalje faze razvoja. Ako se radi o manjim projektima, jedna osoba moe raditi na svim fazama ivotnog ciklusa softvera, odnosno sama realizovati projekat. Meutim, ako je projekat vei, mora raditi vei broj ljudi na njemu, a samim tim mora se vriti i analiza zahteva projekta kao prva i najvanija faza ivotnog ciklusa softvera. LITERATURA [1] Risti O., Mari A., Uloga menadmena u softverskom inenjerstvu, Nauno struni skup "Industrijski menadmen i razvoj", Fakultet za industrijski menadement, Kruevac, 2007, s. 100105. [2] Marasco J., The Software Development Edge: Essays on Managing Successful Projects, Addison Wesley Professional, ISBN: 0-32-132131-6, 2005, 336 p. [3] http://www.construx.com/