PREDMET

SE410-ANALIZA ZAHTEVA ZA SOFTVER

Seminarski Rad :

Uticaj kavliteta zahteva na kvalitet softverskog proizvoda

AUTOR
Aleksandar MIljković 1456
Student Master studija : Bezbednost Informacija
aleksandar.miljkovic.1456@metropolitan.ac.rs.rs

U Beogradu, januar 2012

Mentor:
Prof. dr Svetlana Cvetanović
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Sadržaj

Uticaj kavliteta zahteva na kvalitet softverskog proizvoda......................................................................1

Sadržaj....................................................................................................................................................2

1.Uvod....................................................................................................................................................3

2.Pojam softverskog inžinjerstva............................................................................................................4

3.Standardi softverskog inžinjeringa.......................................................................................................4

3.1.Prednosti primene IT standarda...................................................................................................5

3.2.Ključni standardi za oblast SE........................................................................................................5

4.Faze zivotnog ciklusa softvera.............................................................................................................6

5.Pojam Zahteva.....................................................................................................................................7

5.1.Prikupljanje zahteva.....................................................................................................................7

5.2.Prikupljanje zahteva I modelovanje sistema.................................................................................8

5.3.Značaj faze prikupljanja zahteva...................................................................................................9

5.3.1Sprovedene ankete.................................................................................................................9

5.4.Proces prikupljanja zahteva I specifikacija..................................................................................11

5.4.Pisanje Zahteva...........................................................................................................................11

6.Dokumentacija sistema kvaliteta za obezbeđivaje kvaliteta softvera................................................13

7.Zaključak............................................................................................................................................15

Literatura..............................................................................................................................................17

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 2 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

1.Uvod

Pri razvoju bilo kog složenijeg softverskog projekta, neophodno je definisati precizno sve faze
životnog ciklusa softvera. Ovde je poseban značaj dat prvoj fazi razvoja, prikupljanju zahteva od
naručioca, jer od njega zavise i ostale faze.

Ukoliko u ovoj fazi nastanu propusti i greške, one će se provlačiti i kroz ostale faze i negativno
uticati na realizovanje softvera. Zbog toga je neophodno precizno definisati zahteve od naručioca, te
zahteve ako je moguće zapisati i u tom obliku analizirati zajedno sa naručiocom, kako bi bili sigurni da
su zahtevi precizno definisani. Ukoliko dođe do grešaka, povećaće se vreme potrebno za njihovo
otkrivanje u narednim fazama životnog ciklusa, a samim tim i troškovi se višestruko uvećavaju.

Postavlja se pitanje da li je specifikacija zahteva u životnom ciklusu softvera gubljenje

vremena i ko ima koristi od toga?

Specifikacija zahteva je značajna 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 očekuju. Najviše koristi
imaju korisnici jer znaju šta će dobiti kao rezultat na kraju. Obično razvoj softverskog proizvoda
počinje kada naručioc utvrdi da su zahtevi dobro prikupljeni. Npr. ako naručioc želi da na sajt o
kupovini uključi listu želja, on će analizirati zahteve i tražiti da se doda lista želja, ako već ne postoji.
Na taj način, sa povećanjem uloge korisnika u kreiranju zahteva, utiče se na dalje faze razvoja.

Ako se radi o manjim projektima, jedna osoba može raditi na svim fazama životnog ciklusa
softvera, odnosno sama realizovati projekat. Međutim, ako je projekat veći, mora raditi veći broj ljudi
na njemu, a samim tim mora se vršiti i analiza zahteva projekta kao prva i najvažnija faza životnog
ciklusa softvera.

Proces otkrivanja zahteva korisnika predstavlja prvi korak u razumevanju problema koji
softver treba da reši. Prevashodno ljudska aktivnost, prepoznavanje stakeholdera i uspostavljanje
veze između razvojnog tima i kupca čine najvažnije faktore u procesu prikupljanja, obrade i validacije
zahteva.

Od fundamentalnog značaja je dobra komunikacija na relaciji softverski korisnik – softver

inženjer. Bez dobrog komunikacionog kanala na realaciji korisnik – proizvođač softvera postoje
ogromne šanse da se dobije softver koji ne ispunjava u većoj ili manjoj meri ono što se od njega
očekuje.

Proces prikupljanja zahteva korisnika je složen i ozbiljan proces. Neophodno mu je prići sa

puno ozbiljnosti i uz poštovanje standarda i preporuka. Potrebno je ispoštovati proceduru da se sve
dokumentuje u okviru ovog procesa, kako bi se mogle ispratiti izmene i kako bi se proizvođač softvera
zaštitio od korisnika koji su u međuvremenu promenili delove zahteva.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 3 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

2.Pojam softverskog inžinjerstva

Termin softversko inženjerstvo se prvi put pojavio 1968 godine na NATO konferenciji u
Nemačkoj. Poslednjih 30 godina, softversko inženjerstvo predstavlja metaforu za proces razvoja
softvera. Softversko inženjerstvo je danas prihvaćeno kao akademski pojam i koristiti se na velikom
broju univerziteta koji poseduju naučne oblasti tog tipa, ili pak predmete koji imaju ovo ime.

Projekti vezani za softversko inženjerstvo odnose se na definisanje ovog pojma i jedna od

definicija je prema IEEE: „Softversko inženjerstvo predstavlja primenu semantike, uređenosti,
određenog prilaza pri razvoju, izradi i održavanju softvera, a to znači primenu inženjerskih principa na
razvoj softvera“.

Pošto se softver koristi sve više i preuzima vitalne funkcije u organizacijama i društvu,
značajno je da bude što pouzdaniji, efikasniji i da postoji mogućnost izmene, dopune itd.

Jedan od uzroka nastanka softverskih greški je da se ne poštuje raspored izrade projekta, kao i
da je procena kompletnosti projekta loša. Proizvod softverskog inženjerstva je softverski sistem.
Softver koji se razvija mora zadovoljiti zahteve naručioca.

Gotovo da ne postoji softver bez greške. Za neke softvere, broj grešaka neće uticati na kvalitet
i rad samog softvera, dok u nekim slučajevima, greške mogu izazvati katastrofu. Zbog toga je
neophodno da se poštujući metodologiju razvoja softvera unapred precizno definišu 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.

U oblasti softvera osnovni problem je bio u tome što je složnost problema za rašavanje rasla
brže od tehnologije za razvoj softvera. Cena softvera zavisila je više od rada nego od tehnologije, tako
da je ljudski rad potreban za razvoj softvera bio proporcionalan veličini (složenosti) softvera. Kako se
složenost softvera u toku godina povećavala, povećavao se i ljudski rad potreban za njegov razvoj.

3.Standardi softverskog inžinjeringa

Da bi se oblast softverskog inžinjeringa pokrila neophodnim standardima, uložen je ogroman

trud i rad na međunarodnom, regionalnom i nacionalnom nivou.

Proces donošenja i revizije već donetih standarda je stalan i sve obuhvatniji. U svetu softvera
tako danas egzistira više od 1000 standarda, a u svetu softverskog inženjerstva ima ih više od 350
aktuelnih.

Standard je potvrđen uzorak u odnosu na koji drugi predmeti mogu da budu mereni ili
procenjeni.Standard je objavljen dokument koji sadrži tehničke specifikacije ili druge kriterijume
neophodne da osiguraju da će materijal ili metoda dosledno da zadovolji potrebe za koje je
predviđen.
Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog
proizvoda

Page 4 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Ne treba očekivati da su svi međunarodni standardi savršeno sistematizovani,usklađeni po

metodologiji i sadržaju, ali su van svake sumnje snažno sredstvo, uz čiju pomoć se može vršiti
unapređenje projektantskih metoda i obezbediti kvalitet gotovih softverskih proizvoda.

Slika 1.Pozicija standarda u organizaciji.

3.1.Prednosti primene IT standarda

Neke od prednosti primene standarda su :

 Doprinose stvaranju efikasnog,ekonomičnog, pouzdanijeg i sigurnijeg upravljanja

informacijama
 Olakšavaju tranziciju IT funkcije iz jednog stanja u drugo
 Stvaraju preduslove za brz i efikasan reinženjering
 Omogućavaju ravnopravnije učešće ponuđača u tenderima

3.2.Ključni standardi za oblast SE

 ISO/IEC TR 19759:2005 – Vodič kroz osnove znanja softverskog inženjeringa (SWEBOK)

 ISO/IEC 12207 - faze životnog ciklusa softvera i standardi koji ga dopunjavaju
 ISO/IEC TR 15504 – SPICE - vrednovanje sposobnosti softverskih organizacija
 ISO 9001:2000/TickIT - praćenje upotrebljivosti softvera u procesu isporuke, nabavke,
održavanja i razvoja [2]
 ISO 9126: Softverski inženjering – Kvalitet proizvoda
 ISO/IEC 14598 - Vrednovanje softverskog proizvoda
 ISO/IEC 27000 – Upravljanje sigurnošću IS
 ISO/IEC 20000 – Upravljanje IT uslugom

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 5 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

4.Faze zivotnog ciklusa softvera

Termin životni ciklus softvera se odnosi na organizacionu šemu procesa konstruisanja

(razvoja) softvera. Mada se ovaj pojam može definisati na razne načine, a osnovni cilj je da se na kraju
dobije kvalitetan softver.

Faze razvoja životnog ciklusa softvera su sledeće:

1. Zahtevi-služe za definisanje problema koji se rešavaju

2. Projektovanje (modeliranje)-najkreativniji deo životnog ciklusa softvera u kome se utvrđuje
složenost u toku procesa razvoja softvera
3. Kodiranje-predstavlja osnovu u toku razvoja softvera jer se piše kod programa
4. Otklanjanje grešaka-Ne postoji ni jedan softverski proizvod imalo složeniji koji nema grešaka.
Ova faza je povezana sa narednom.
5. Testiranje-softver se izvršava na jednostavnim primerima kako bi se utvrdilo da li radi ono što
se od njega zahteva i da li su sve greške ispravljene.
6. Ocenjivanje softvera-ima za cilj da utvrde da li je testiranje dobro izvedeno i da li je dobijen
kvalitetan softverski proizvod.
7. Održavanje-poslednja faza životnog ciklusa koja je ujedno i najznačajnija, jer ako je
neophodno izvršiti izmene u softveru, potrebno je da se projektuje tako da su moguće
izmene na što jednostavniji način.

Slika 2.Faze u razvoju softvera

Pošto je tema ovog seminrskog rada vezana za uticaj kvaliteta zahteva na kvlitet
softverskog proizvoda,najviše pažnje će biti posvećeno samim zahevima kao I prcesima koji ih
karakterišu.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 6 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

5.Pojam Zahteva

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 postići
odgovarajući cilj.

Šta softver obavlja za korisnika i koja ograničenja 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.

Takođe nije bitno koji će se programski jezik ili razvojni alati koristiti za konstrukciju
softvera.Da bi se razumeli zahtevi ne bitno je da li se koristi agilno inženjerstvo, ekstremno
programiranje, prototipsko programiranje, modeliranje ili neka druga metodologija. Najbitnije je da se
ispravno definišu zahtevi i da naručioc to razume, ili softver neće biti od koristi, bez obzira što su
ostale faze u razvoju softvera perfektno određene.

5.1.Prikupljanje zahteva

Faza prikupljanja zahteva treba da obuhvati istraživanje funkcionanosti i ponašanja 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 značajna faza u razvoju softverskog proizvoda, pa je neophodno

obratiti posebnu pažnju da se razume sve što je neophodno da bi se krenulo u narednu fazu razvoja
softvera (projektovanje). Da bi se isporučio koristan i primenljiv softverski proizvod, sa najnižim
troškovima za organizaciju, ova fazu razvoja softvera je najznačajnija.

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 određuju alati za
programiranje, uređaji koji se koriste i kako će biti konstruisani.

Pravilno prikupljeni zahtevi će uticati da se ostale faze minimalno kasnije dorađuju.Na slici je
prikazan proces prikupljanja zahteva kao deo životnog ciklusa razvoja softvera.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 7 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Slika 3.

Proces prikupljanja zahteva utvrđuju rad i određuje koji proizvodi najbolje pomažu u radu.
Kao izlaz iz ovog procesa, specifikacija zahteva obezbeđuje kompletan opis potrebnih funkcionalosti i
ponašanja 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 početka projektovanja i konstrukcije.

Kada se proizvod jednom kreira, on se koristi i odmah krene da se razvija. Softver mora imati
mogućnost proširenja u zavisnosti od novih zahteva korisnika u pogledu funkcionalnosti. Ako se koristi
proces gde je funkcionalnost značajna, takav proizvod će uticati na radnu praksu. Npr. ako su zahtevi
fleksibilni, to će uticati na promenu isporučivanja softvera.

Razvoj softvera i njegovih zahteva je proces koji se ne može 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.

5.2.Prikupljanje zahteva I modelovanje sistema

Prikupljanje zahteva i modeliranje sistema je značajno i kada se posmatra od strane

moderatora sistema i od analitčara sistema. Na početku je značajnija aktivnost prikupljanja zahteva.
Analitičar zahteva se orjentiše 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 značajne informacije koje se koriste pri prikupljanju zahteva. Jaz između prikupljanja zahteva i
modeliranja sistema varira u zavisnosti od procesa razvoja softverskog proizvoda. Na početku,
modeliranje je minimalno, dok se maksimalno radi na prikupljanju i ocenjivanju zahteva. Kako faze
razvoja softvera odmiču tako i aktivnost modeliranja raste. Modeli se mogu koristiti da opišu softver ili

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 8 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

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 najznačajnije jeste da mora
postojati veza između modeliranja i prikupljanja zahteva.

5.3.Značaj faze prikupljanja zahteva

Softverski proizvod može biti bilo kog tipa. Da bi se kreirao može se krenuti i od crteža, 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 istraživanjima oko 60% grešaka
potiče iz faze prikupljanja zahteva. Tako da zaposleni u razvoju softvera imaju mogućnost da eliminišu
veliku količinu grešaka ako detaljno izvrše prikupljanje zahteva, a ne da brzo pređu u narednu fazu
razvoja. Kao rezultat, mnogo puta se desilo da je cena softvera bila mnogo veća, što je bilo posledica
lošeg prikupljanja i analize zahteva na početku razvoja softvera. Samim tim je i kvalitet lošiji.

Programiranje je konstruisanje rešavanja problema. Može se dobiti veći broj iteracija kao
rešenje. Bez razumevanja potreba korisnika i predstaviti im rešenje u radnom okruženju, samo
rešenje problema neće biti mnogo bolje od korisnikove percepcije za taj problem.

Troškovi dobrog prikupljanja zahteva i analize sistema su beznačajni u poređenju sa

troškovima lošeg prikupljanja zahteva. Greške koje nastanu u ovoj fazi višestruko uvećavaju troškove
otklanjanja grešaka u narednim fazama razvoja softvera.

5.3.1Sprovedene ankete [5]

5.3.1.1.Grupa Standish
Grupa Standish [3]je 1994 god. ispitala ishode više od 8 000 softverskih projekata u preko 350
kompanija:

 35% softverskih projekata je otkazano pre nego što su završeni

 u velikim kompanijama, samo je 9% projekata isporučeno na vreme i u okviru budžeta, u

malim kompanijama 16%.

Slična situacija se ponavlja i u narednim godinama, pri čemu je neizbežna činjenica da

razvojne organizacije imaju problema sa isporukom odgovarajućeg sistema na vreme i u okviru
budžeta.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 9 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Najteži segment u izgradnji softvera jeste precizno odlučivanje šta da se razvija. Nijedan drugi
deo aktivnosti na konceptualnom nivou nije tako težak kao uspostavljanje detaljnih tehničkih zahteva.
Nijedan drugi deo aktivnosti ne može u tom stepenu učiniti lošim rezultujući sistem, kao loše
formulisani zahtevi. Grupa Standish (1995) je tražila od učesnika istraživanja da objasne uzroke
neuspeha projekata:

1. nekompletni zahtevi (13,1%);

2. nedovoljno učešće korisnika (12,4%);

3. nedostatak resursa (10,6%);

4. nerealna očekivanja (9,9%);

5. odsustvo podrške rukovodstva (9,3%);

6. izmene zahteva i specifikacija (8,7%);

7. odsustvo planiranja (8,1 %),

8. sistem više nije bio potreban (7,5%)

U gotovo svim razlozima uključen je i proces definisanja zahteva. Nijedan drugi deo nije toliko
teško naknadno ispravljati. Greške u zahtevima mogu da budu vrlo skupe ako nisu otkrivene i
ispravljene u ranim fazama procesa razvoja. Greške u zahtevima se propagiraju i kulminiraju
prolaskom kod ostale faze razvoja.

5.3.1.2.Boehm i Papaccio
Boehm i Papaccio (1988) izveštavaju da ako tokom procesa definisanja zahteva otkrivanje i
otklanjanje problema u zahtevima košta 1 dolar, odgovarajuća ispravka košta 5 dolara u fazi dizajna,
10 dolara tokom kodiranja, 20 dolara tokom pojedinačnog testiranja, a više od 200 dolara nakon
isporuke sistema.

Zato vredi izdvojiti vreme i sredstva na razumevanje problema i njegovog konteksta da bi se

na samom početku dobili ispravni zahtevi. Izmedju 40% i 60% softverskih grešaka i defekata rezultat
su lošeg softverskog managementa i loše definisanih zahteva (www.softwareprojects.org).
Jednostavnije rečeno, polovina problema bi se mogla odstraniti ako se stvari jasno postave na samom
početku, šta kupac očekuje od projekta i ako se dobro upravlja projektom. Programiranje može da
bude dobro i da razvojni tim odlično uradi svoj posao, ali sa razlikom da nisu uradili ono što je traženo.

5.4.Proces prikupljanja zahteva I specifikacija

Proces prikupljanja zahteva i specifikacija zahteva se mogu primeniti na skoro sve vrste
aplikacija u bilo kojoj vrsti razvojnog okruženja. Bez obzira da li se radi o kreiranju korisničkih sistema,

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 10 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

sistema iz povezanih delova, komercijalnih softvera, open source softvera ili izmena u već postojećem
softveru, neophodno je da se istražuje, razumeju i uvode zahtevi.

Pri opisu procesa neophodno je od samog početka koristititi prikupljanje zahteva. U ovoj fazi
će se pronaći mnogo značajnih stvari koji će biti realizovani u samom procesu, a koji će uticati na
produktivnost i tačnost. Hiljade organizacija već primenjuje ovaj proces u fazama razvoja.

Softverske firme i korisnici se salžu u jednoj stvari, a to je da ako želimo da kreiramo pravi
softverski proizvod, neophodno je da se koriste odgovarajući zahtevi. Da bi se pronašli i kompletirali
zahtevi neophodena je neka vrsta sistematskog procesa.

Slika 4.

Na slici je prikazan jedan takav proces koji je sveobuhvatan i koji prikazuje aktivnosti i njegove
isporuke. Ovde se koristi opis toka podataka na određeni način. 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.

5.4.Pisanje Zahteva

Osnovni problem u procesu razvoja softvera je nerazumevanje zahteva. Da bi se to izbeglo,

analitičari moraju pisati svoje zahteve na analizirani način i obezbediti da programeri to razumeju da
se slože sanapisanim zahtevima pre nego što krenu u naredne faze razvoja. To znači da analitičari pišu
zahteve da bi obezbedili da svi koji učestvuju u razvoju podjednako razumeju šta je potrebno da se
radi. Možda će se činiti da ja zapisivanje zahteva predstavlja teškoće, ali je to jedini način da bi se
obezbedilo davanje značaja zahtevima kako bi se isporučeni softver testirao.

Jedino dobra komunikacija između analitičara i programera obezbeđuje da se dobijeni

softverski proizvod kreira na vreme i ispravno. Analitičari prikupljaju i pišu zahteve za naručioce
projekta. Tako da zahtevi postaju poslovni zahtevi, tako da se moraju pisati koristeći poslovni jezik
kako bi i naručioci mogli razumeti i oceniti njihovu ispravnost. Naravno, zahtevi moraju biti u pisanoj
formi jer i dizajneri i drugi tehničari mogu precizno napraviti ono što klijent traži.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 11 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Da bi se obezbedila ova ispravnost i da bi zahtevi bili istestirani, analitičari svakom zahtevi

dodaju dodatni kriterijum. To predstavlja merenje zahteva, tako da oni koji testiraju mogu precizno
odrediti da li je zadovoljen zahtev.

Analitičari koriste razne alate za kreiranje jednostavnih specifikacija. Jedan od najčešće

korišćenih se odnosi na primenu templejta (šablona) za specifikaciju zahteva i to u obliku kontrolne
liste pomoću kojih se zapisuje specifikacija dokumenata.

Naravno, pisanje aktivnosti nije razdvojeno od aktivnosti, već je integisano sa aktivnostima

koje utvrđuju 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
rešava. Takođe, 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 kogase zapisuju zahtevi. Zato je neophodno
da analitičar dobro razume zahteve, kako bi mogao da ih pravilno ispiše. Ako zahtevi nisu razumljivi, i
usklađeni sa onim što žele naručioci, onda i bilo kakav pokušaj pisanja zahteva predstavljaće ništavne
podatke, koji će biti brzo uočeni kada zahtevi dođu do procene kvaliteta.

Zapisivanjem zahteva se opisuje softverski proizvod sa poslovne tačke gledišta. Obično se taj
opis naziva specifikacija, i taj termin se koristi za bilo koji opis koji je zapisan ili ne. Ova aktivnost se
može smatrati formiranjem specifikacije, gde se zahtevi postupno obrađuju deo po deo.

Pisanje zahteva se uglavnom izvodi u toku aktivnosti prikupljanja zahteva i formiranju

prototipa. Na ovaj način se ideje konkretizuju u zahteve koji se mogu testirati. To su formalizovani
zahtevi.

Slika 5. Proces evidentiranja zahteva

Na slici je prikazan proces evidentiranja zahteva. Izvršilac tih zadataka je analitičar zahteva ili
analitičar sistema. Analitičar zahteva prvo radi sa naručiocima na izvodenju zahteva: postavlja pitanja,
ispituje aktuelno ponašanje ili demonstrira slične sisteme . Nakon toga zahtevi se evidentiraju u
sklopu modela ili prototipa. Kada se postigne dobro razumevanje zahteva, posao se nastavlja izradom
Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog
proizvoda

Page 12 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

specifikacije, u kojoj se odlučuje koji će delovi zahtevanog ponašanja biti implementirani u softveru.
Analitičar zahteva čini most u komunikaciji izmedju svih zainteresovanih strana u projektu .

Tokom validacije, proverava se da li specifikacija odgovara onome što naručilac želi da vidi u
finalnom proizvodu. Aktivnosti analize i validacije mogu da otkriju probleme ili propuste u modelu ili
specifikaciji, što prouzrokuje ponovne posete naručiocu i revidiranje modela i specifikacije.

Krajnji ishod tog procesa je specifikacija softverskih zahteva (Software Requirements

Specification, SRS), koja se koristi za komunikaciju sa drugim članovima razvojnog tima (koji rade na
dizajnu, testiranju i održavanju), o tome kako konačni proizvod treba da se ponaša.

Slika 6.

6.Dokumentacija sistema kvaliteta za obezbeđivaje kvaliteta softvera

Jedan od mogućih pristupa u obezbeđenju kvalita softvera je i definisanje potrebne

dokumentacije sistema kvaliteta koja bi se odnosila na softver. Ova dokumentacija bi trebalo da
obezbedi da softverski proizvod koji se isporučuje kupcu ili koristi u preduzeću zadovoljava
ustanovljene i ugovorene tehničke zahteve.

Ova dokumentacija bi takođe morala da obezbedi prijem softverskog projekta i do obezbedi

da se sve politike, standardi, iskustva iz prakse, procedure i procesi primenjuju u toku trajanja
projekta po unapred utvrđenom redosledu.

Neki od relevantnih IEEE standarda su korišćeni da bi se „pokrila“ sva značajna mesta u toku
životnog ciklusa razvoja proizvoda i da bi se učinilo da preporučena dokumentacija za obezbeživanje
kvaliteta softvera bude što potpunja:

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 13 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

ƒ IEEE 730, Standard za planove obezbeđenja kvaliteta softvera, propisuje minimum od:

Specifikacije zahteve softvera , Opisa projekta softvera , Plana softverske verifikacije i validacije,
Izveštaja o softverskoj verifikaciji i validaciji Korisničke dokumentacije, Plana upravljanja softverskom
konfiguracijom

ƒ IEEE 828, Standard za planove upravljanja dokumentacijom

ƒ IEEE 829, Standard za dokumentaciju za softversko testiranje

ƒ IEEE 830, Preporučena praksa za zahteve softverske specifikacije

ƒ IEEE 1008, Standard za jedinično (unit) testiranje softvera

ƒ IEEE 1012, Standard za planove softverske verifikacije i validacije

ƒ IEEE 1016, Vodič za opis softverskog projekta

ƒ IEEE 1028, Standard za softverske kontrole i audite

ƒ IEEE 1042, Vodič za planove upravljanja softverskim konfiguracijama

ƒ IEEE 1044, Standard klasifiakcije softverskih anomalija

ƒ IEEE 1045, Standard za metriku softverske produktivnosti

ƒ IEEE 1058.1, Standard za planove upravljanje softverskim projektima

ƒ IEEE 1059, Vodič za planove softverske verifiakcije i validacije

ƒ IEEE 1061, Standardi za metriku metodologije kvaliteta softvera

ƒ IEEE 1063, Standard za korisničku dokumentaicju softvera

ƒ IEEE 1074, Standard za razvoj SDLC procesa

ƒ IEEE 1219, Standard za softversko održavanje

ƒ IEEE 1233, Vodič za razvoj specifikacije zahteva sistema

7.Zaključak

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 14 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Kvalitet softvera je više dimenzionalni koncept koji se ne može jednostavno definisati. Za

ostvarivanje potrebnog kvaliteta softvera od velikog je značaja određivanje modela kvaliteta softvera ,
definisanje dokumentacije sistema što sa sobom povlači korektno prikupljanje I definsanje zahteva
softvera. Ukoliko se prilikom uzimanja zahteva načini greška, bilo usled pogrešno uzetih zahteva, lošeg
pristupa analizi zahteva ili nečeg trećeg, ta greška će se odraziti na konačni proizvod. Tada, konačni
proizvod, ukoliko uopšte bude implementiran, neće posedovati očekivanu funkcionalnost.

Što se dalje odmiče u procesu imlementacije softverskog sistema, to je otklanjanje grešaka

načinjenih u procesu prikupljanja zahteva skuplje i dugotrajnije. Nameće se zaključak de je proces
prikupljanja i evidentiranja zahteva veoma važan deo softverskog inženjerstva. To je deo aktivnosti
kome se mora pristupiti vrlo ozbiljno, u skladu sa standardima.

Studija koju je sprovela Jet Propulsion Laboratory (JPL) [9] pokazuje da cena detekcije i
uklanjanja grešaka raste po stopi od 10 puta kako se softverski proizvod kreće kroz svoj životniciklus
(definisanje zahteva, dizajn, implementacija,testiranje, puštanje u rad). Ova studija je pokazala da je
cena detektovanja i ispravljanja greške u softverskom proizvodu stoji u razmeri 1:10:100:1000 (zahtevi
: dizajn :implementacija/testiranje : eksploatacija).

Slika 7.Posledica loših zahteva

Iz svega ovoga se vidi koliko detekcija i ispravljanje softverskih grečaka može biti skupa
aktivnost. Ako svemu ovome dodamo rastuće zahteve za kvalitetom i pouzdanošću softvera koje
potrošači postavljaju pred softversku industriju,jasno je da samo implementacija sistema kvaliteta i
obezbeđenje kvaliteta softvera može doneti pozitivne rezultate.

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 15 of 16
 SE410-ANALIZA ZAHTEVA ZA SOFTVER 2013

Literatura

[1] http://elearning.metropolitan.edu.rs

[2] http://sr.wikipedia.org/sr-el/ISO_9000

[3] http://blog.standishgroup.com/

[4] http://www.scribd.com/doc/27709712/42/SCM-plan

[5] http://www.scribd.com/doc/70843779/VaznostFazeDefinisanjaZahtevaPajic

[6] http://www.win.tue.nl/~aserebre/2IS55/2009-2010/2.pdf

[7] http://www.itvestak.org.rs/ziteh_04/radovi/ziteh-07.pdf

[8] http://www.its.edu.rs/cms/mestoZaUploadFajlove/tehnike
%20IStrategijeUnapredjenjaSoftverskogKodaCveticBranko%E2%80%A6.pdf

[9] http://en.wikipedia.org/wiki/Software_requirements_specification

[10] http://www.preduzetnickiservis.rs/sr/sertifikacija-standardizacija-i-standardi/iso-standardi/?
tmpl=print

Aleksandar Miljkovic 1456 Uticaj kvaliteta zahteva na kvalitet softverskog

proizvoda

Page 16 of 16