INTERNACIONALNI UNIVERZITET U NOVOM PAZARU

DEPARTMAN ZA RAUNARSKE NAUKE

SMJER: INFORMATIKA

Dizajn aplikativnog softvera

Biljeke sa predavanja doc.dr.Muzafera Saraevia

Biljeke priredili studenti:

Ervin Pepi, Edvin Cikoti.

Novi Pazar
2015,2016. godine

Uvodna rije
Intenzivan razvoj informatike i raunarstva u poslednjim decenijama uveo je
softver u sve oblasti ivota. Razvijeni su brojni softverski proizvodi sa vrlo
razliitim namjenama. Softver je postao neophodan u svim oblastima
drutva: privredi, obrazovanju, zdravstvu, medijima i komunikacijama, poslovanju,
politici, itd.
Generalno posmatrano, mogu se izdvojiti dvije vrste softvera: sistemski i
aplikativni softver.
Pod sistemskim softverom podrazumijevaju se programi niskog nivoa (low-level)
koji omoguavaju rad sa raunarskom opremom (hardverom). Moe se rei da
sistemski softver na neki nain oivljava hardver i omoguava njegovo
korienje.
U sistemski softver se ubrajaju operativni sistemi, razvojni alati za generisanje
pograma na razliitim programskim jezicima, mreni softveri, softveri za
upravljanje bazama podataka, programske biblioteke, razne vrste prevodioca, alati
za testiranje programa, itd. Sistemski softver obezbeuje osnovnu funkcionalnost
koja ini platformu za rad aplikativnog softvera. Aplikativni softver ine
programi napravljeni za specifinu svrhu, prema potrebama korisnika.
Ova vrsta softvera nije u direktnoj vezi sa hradverom, ve se u svom izvravanju
oslanja na sistemski softver, posebno na operativni sistem.
Aplikativni softver obuhvata poslovne aplikacije opte namjene (tekst procesore,
aplikacije za tabelarna izraunavanja, grafike aplikacije i sl.), aplikacije za kunu
upotrebu (igrice, edukativne aplikacije i dr.), industrijski softver, usluni softver,
web aplikacije, itd. Odnos sistemskog i aplikativnog softera je prikazan na slici 1.
U nekim sluajevima, nema jasne granice izmeu sistemskog i aplikativnog
softvera. Na primer, ne postoji saglasnost svetskih strunjaka oko toga da li je
pretraiva Internet Explorer deo operativnog sistema Windows ili nije.

Potreba za razvojem aplikativnog softvera moe da nastane kada korisnik eli da

rijei neki problem ili da dobije neku uslugu. Meutim, pre izrade softvera,

Slika 1 Mesto aplikativnog softvera u raunarskom okruenju

posebno ukoliko se radi o sloenom problemu, neophodno je sprovesti analizu

sistema. Pod analizom sistema se podrazumijeva sagledavanje problema i njegovo
razlaganje na potprobleme koji su razumljivi i rjeivi. Posebna panja u analizi se
mora posvetiti vezama izmeu potproblema, jer one mogu biti kljuni faktor u
nalaenju kompletnog reenja. Nakon to se problem razloi na potprobleme koji
mogu da se rijee (sa jasno definisanim meusobnim vezama), pristupa se sintezi
reenja. Svaki potproblem se najprije samostalno rjeava, a zatim se od dobijenih
parcijalnih rjeenja formira kompletno rjeenje problema. Postupak analize i
sinteze je ilustrovan na slici 2., na primjeru problema koji se moe razloiti na tri
potproblema: PP1, PP2 i PP3.
Rjeenje potproblema PP1 je R1, dok su R2 i R3 rjeenja potproblema PP2 i PP3,
respektivno. Spajanjem rjeenja R1, R2 i R3 dobija se rjeenje polaznog problema.
Rezultat sinteze rjeenja ukazuje na to da li posmatrani problem treba da se rjeava
izradom odgovarajueg softvera, ili se moe reiti na neki drugi nain. Ako se
utvrdi da je softver potreban, pristupa se njegovom razvoju.
Svaki problem koji se rjeava izradom softvera, moe se rjeiti na vie naina.
Naini se meusobno razlikuju po efikasnosti, preciznosti, razumljivosti,

korisnosti, mogunosti modifikovanja i drugim osobinama. Stoga, izrada softvera

zahteva posjedovanje znanja, ali i domiljatosti i vetine.
Osnovni cilj u izradi softvera jeste da softver bude sveobuhvatan, stabilan,
razumljiv, da se lako odrava i radi efiksano ono zbog ega je napravljen.
Nerazumljivost napisanog programa naruava njegov kvalitet, iako ponekad
postoji pogreno miljenje da je takav program izuzetan, zato to niko osim
autora ne moe da ga shvati.

Slika 2Analiza sistema i sinteza rjeenja

Danas u svetu postoji veliki broj proizvoaa softvera. Svaki od njih se trudi da
napravi softver bez mana. Meutim, praktino ne postoji softver bez
nedostataka. Neki nedostaci se pojave odmah nakon putanja softvera u rad, dok je
za druge potrebno znatno vie vremena. Ni za jedan softver se ne moe garantovati
da za svo vreme primjene nee ispoljiti nijedan nedostatak.

Da bi softver bio to bolji, pri njegovoj izradi mora se voditi o raznim aspektima,
kao to su:
Neovlaena upotreba sistema,
Trite softvera,
Obezbjeivanje kvaliteta.
Za softver je vano da dobro radi u svim uslovima u kojima moe da se nae.
Zato, pri njegovoj izradi treba voditi rauna i o moguoj neoekivanoj upotrebi
sistema. Do neoekivane upotrebe moe da doe zbog pokuaja zloupotrebe
softvera, ili zbog nestrunog rukovanja od strane korisnika. Na primjer, est je
sluaj zlonamjernih napada na web stranice dravnih organa ili drugih organizacija.
Zato, pri izradi ovih web stranica, treba sprovesti odreene mjere zatite sadraja.
U praksi je est i sluaj nestrunog rukovanja, posebno kada se korisnici susreu sa
novom tehnologijom.
Zbog velike konkurencije na tritu softvera, da bi opstali, proizvoai moraju u
relativno kratkim vremenskim periodima da isporuuju nove proizvode. To im
ostavlja nedovoljno vremena za testiranje programa, pa su greke u programima
ee. Kada se uoi neki nedostatak u softveru, proizvoa mora vrlo brzo da
reaguje i da ga otkloni. On to moe da uini na dva naina: da ispravi greku
mijenjanjem dijela postojeeg softvera, ili da generie novi softver. Donoenje
prave odluke u ovoj situaciji je od izuzetne vanosti. Naime, ako je nedostatak
koncepcijske prirode, tj. ako je nastao zbog loe isprojektovanog sistema, njegovo
otklanjanje izmjenom diela kda moe da prouzrokuje nove, moda i vee
probleme. Ima situacija u kojima je isplativije ponovo razviti cijeli sistem, nego
popravljati stari koji se ne moe popraviti. U svakom sluaju, donoenje odluke je
najbolje prepustiti nekom iskusnom projektantu.

Uvod u dizajn aplikativnog softvera

(softversko inenjerstvo)
Razlog zbog kojeg je nastao aplikativni softver moemo rei da su
prvenstveno finansije odnosno projekti koji su premaili planirane trokove i
rokove.
Tehnike individualnog programiranja se ne mogu uspjeno preslikati na velike
programe gdje uestvuje veliki broj programera. Potreba za sloenijim metodama
razvoja softvera koje bi bile u stanju da kontroliu kompleksnost velikog
softverskog projekta.
Ekonomija svih razvijenih nacija je zavisna od kvalitetnog softvera. Sve vie
sistema kotrolie se pomou softvera. Primjene se stalno poveavaju po veliini,
sloenosti i potrebama distribuiranosti, a kao veliki problem moemo rei da je
nedostatak kvalifikovanih strunjaka.

Istraivanje iz 2006
Standish Group (www.standishgroup.com) je izvrila analizu softversih
projekata u dravnom privatnom sektoru u SAD-u i ustanovila:
35% projekata je kompletirano na vrijeme i s predvianjem budetom,
19% projekata razvoja programske podrke je obustavljeno prije zavrekta,
46% je zavreno ali prokraen je budet, vremenski rok i imaju manje
funkcionalnih mogunosti nego to je bilo specificrano na poetku.

Softverski proizvod ili softver

Softverski proizvod je skup raunarskih
dokumentacije, koji je stvoren zato da bi se prodao.

programa

pripadajue

Jedan softverski proizvod treba da ima sljedee atribute kvaliteta:

Mogunost odravanja mijenjanje u skladu s promijenjenim potrebama
korisnika.
Pouzdanost i sigurnost softver se mora ponati na predvidiv nain.

 Efikasnost softver mora imati zadovoljavajue performanse i koristiti

hardverske resurse na tedljiv nain.
Upotrebljivost softver treba da radi ono to korisnici od njega oekuju, a
korisniki interfejs treba da bude zadovoljavajui, i za njega mora postojati
dokumentacija.
Softverski proizvod moe biti razvijen za odreenog klijenta ili za trite genralno.
Softverski proizvod moe biti:
Generiki razvijen sa namjerom da se proda velikom broju razliitih
klijenata, npr:
o Microsoft Office
Narueni (bespoke, custom) razvijen za odreenog klijenta prema
zahtijevanoj specifikaciji na primjer:
o Kontrolni sistem za elektronske ureaje,
o Sistem napravljen da podri odrene djelove poslovnog procesa,
o Sistemi za kontrolu klima ureaja.

Softversko inenjerstvo
Softversko inenjerstvo je nauna disciplina koja se bavi svim aspektima
proizvodnje softvera, ili drugaije reeno softversko inenjerstvo se bavi
modelima, metodama i alatima koji su nam potrebni da bi na to jeftiniji nain
mogli proizvoiti to kvalitetniji softveri.
Primjena sistematinog i organizovanog pristupa, funkcionisanju i odravanju
softvera, to predstavlja primjenu inenjerstva na softver. (IEEE Std 610-1990.)
Kao ulazne podatke moemo rei da su to opisi problema od strane klijenta, a
izlazni jeste da na kraju dobijemo softverski sistem kao dugorono rjeenje
klijentovog zahtjeva.
Naravno treba napomenuti da programeri nisu ti koji samo slijede instrukcije, ve
oni su vie kao efovi kuhinje koji nadgledaju sav rad, a ne samo kuhari koji
slijede recept.

Razlika izmeu softverskog inenjerstva i raunarskih

nauka
Raunarske nauke (eng.computer science)su orijentisane na teorije i metode
u vezi s raunarom neposredno dok je softversko inenjerstvo orijentisano na
praktine probleme koji se javljaju pro proizvodnji programske podrke softvera.
Neka znanja iz domena raunarskih nauka su znaajna za programske inenjere na
isti nain to su neka znanja iz domena fizike znaajna za inenjere elektrotehnike.

Razlika izmeu softverskog inenjerstva i sistemskog

inenjerstva
Sistemsko inenjerstvo (eng.system engineering) je orijentisano na sve
aspekte sloenih sistema u kojima programska podrka igra glavnu ulogu.
Sistemsko inenjerstvo je orijentisano i na razvoj tehnike podrke, politike
razvoja i procesa projektovanja kao i postavljanja sistema.
Sistemsko inenjerstvo je starija disciplina od softverskog inenjerstva.

Softverski proces
Softverski proces je skup aktivnosti i pripadajuih rezultata iji je cilj razvoj
ili evolucija softvera.
Osnovne karakteristike softverskog procesa su:
Specifikacija,
odravaje.

dizajniranje,

implementacija,

verifikacija,

validacija

Dok generike aktivnosti u svim softverskim procesima su:

Specifikacija softvera ta bi sistem trebao da radi (funkcionalnosti
softvera) i koja ogranienja moraju biti ispotovana.
Razvoj softvera produkcija softvera prema zadatoj specifikaciji.
Validacija softvera provjera valjanosti (da li je to to je naruilac traio),
Odravanje softvera dorada programa izmjena u zahtjevima naruioca.

Modeli softverskog procesa

Model za softverski proces je idealizovani prikaz softverskog procesa, kojim
se odreuje poeljni nain odvijanja i meusobnog povezivanja osnovnih
aktivnosti. Npr:
Model moe zahtijevati sekvencijalno odnosno simltano odvijanje aktivnosti.
Razliiti pristupi u ivotnom ciklusu softvera su potrevni i svaki pristup je pogodan
za odeenu primjenu.
Pojednostavljen prilaz softverskog procesa, posmatran iz odreene
perspektive, ili drugaije reeno model je prikaz softverskog procesa, kojim se
odreuje poeljni nain odvijanja i meusobnog povezivanja aktivnosti.
Primjeri perspektiva:
Tok procesa (workflow) prikazuje redosljed aktivnosti,
o Na primjer:
Model se moe zahtijevati sekvencijalno ili simultano odvijanje
aktivnosti.
Tok podataka (Data-flow)prikazuje tok informacija,
Uloge/akcije (Role/action)prikazuje ta ko radi.
Prmjeri modela:

Model vodopada(waterfall model)

Sofverski proces je graen kao niz vremenski odvojenih aktivnosti.
Kao prednosti modela vodioada navst emo sljedee:
Model omoguuje lako praeneje stanja u kome se softverski proces nalazi.
Model je dobro prihvaen od rukovodstva.
A nedostaci su:
Faze je u praksi teko razdvojiti, pa dolazi do naknadnog otkrivanja greaka
i vraanje u predhodne faze.

 Zbog tendencije da se zbog poovanja rokova u odreenom trenutu zamrzne

pojedina faza, moe se desiti da je sistem u trentu putanja u rad ve
neauran i zastareo.
Model treba koristiti za velike sisteme gdje postoje jasni zahtjevi.

Model evolucijsko ravoja ili prototispki model

Na osnovu priblinog opisa problema razvija se polazna verzija sistema koja
se pokazuje korisniku.
Na osnovu korisnikovih primjedbi, ta polazna verzija se poboljava, opet pokazuje
itd.
Nakon dovoljnog broja iteracija dobija se konana verzija sistema. Unutar svake
iteracije, osnovne aktivnosti se obavljaju simultani i ne razdvajaju se.

Slika 3 protoipski model

prednosti modela evolucijskog razvoja:

Model proizvodi brz odgovor na zahtjeve korisnika.
Postoji mogunost da se specifikacija postepeno razvija u skladu sa sve
boljim razumijevanjem problema.
Nedostaci modela:
Proces nije transparentan za rukovodstvo, tj.oni ne mogu ocijeniti dio posla
je obavijen i kada e sistem biti zavren.
Konani sistem je obino loe strukturiran zbog stalnih promjena, i
nepogodan za odravanje.

 Zahtjevaju se posebni alati i natprosjeni softverski inenjeri.

Model se uspjeno koristi za razvoj malih sistema kratkim ivotnim vijekom,
pogotvu za sisteme sa nejasnim zahtjevima.

Model orijentisan ka ponovnoj upotrebi(reuse-oriented

development)
Model polazi od pretpostavke da ve postoje gotove i upotrebljive softverske
cjeline ili djelovi ranije razvijenih sistema.
Novi sistem treba u to veoj mjeri realizovati spajanjem postojeih djelova.

Slika 4 Model orijentisan ka ponovnoj upotrebi(reuse-oriented development)

Prednosti modela
Smanjuje se koliina softvera koga stvarno treba raviti, ime se smanjuje
vrijeme, troak i rizik.
Stavlja se oslonav na proverene i dobro testirane delove softvera.
Mane modela
Zbog kompromisa u specifikaciji mogue je da sistem nee u potpunosti
odgovarati stvarnim potrebama korisnika.
Delimino je izgubljena kotrola nad evolucijom sistema, budui da ne
upravljamo razvojem novih verzija korienja djelova.
Oekuje se da e ovaj model postati prevladajui u sadanjem vremenu, jer
je broj gotovih rjeenja sve vei, a korisnici imaju sve manje vremena za
ekanje rjeenja.

Model inkrementalnog razvoja

Hibrid modela vodopada i modela evolijskog razvoja.
Sistem se opet razvija u nizu iteracija, ali pojedina iteracija ne dorauje ve
realizovani dio sistema, ve mu dodaje sasvim novi inkrement.
Razvoj jednog inkrementa u okviru jedne iteracije odvija se po bilo kom modelu
na primjer vodopad.

Slika 5Model inkrementalnog razvoja

Prednosti modela:
Proces je prilino transparentan za rukovodstvo, jer je vidljivo do kog smo
inkrementa doli.
Korisnici ne moraju dugo ekati da bi dobili prvi inkrement koji zadovoljava
njihove potrebe. Razvoj slijedi prioritete.
Mane modela:
Ponekad je teko podijelti korisnike zahtjeve u smislene inkremente.
Budui da cjelokupni zahtjevi nisu dovoljno razraeni na poetku, teko je
odrediti zajednike module koji su potrebni raznim inkrementima i koji bi
morali biti implementirani u prvom inkrementu.
Ovo je vrlo upotrebljiv model koji se intezivno koristi u praksi, na primjer u
varijanti extreme programming.

Agilne metode(eng.Agile methods)

Glavna karakterstika je fleksibilnost. Treba brzo odgovoriti na zahtjeve
trita, mogunosti dodavanja i mijenjanja zajteva u kasnim fazama ivotnog
ciklusa.
Agilne metode su najpogodnije za male/srednje poslovne sisteme, skrauju vrijeme
ivotnog ciklusa softvera (ime se ubrzaa razvoj softvera), tako to se prvo razvija
prototip, a zatim integrie funkcionalnost. Na ovaj nain se brzo odgovara na
zahteve naruioca posla.
Agilni manifest:
Pojedinci imaju veu vanost od procesa alata. Timovi se samoorganizuju i
komuniciraju direktno licem u lice, a ne preko dokumentacije.
Uloiti vrijeme u izradu softvera, umjesto u izradu dokumentacije. Primarno
mjerilo uspjeha je stepen do koga softver radi ispravno.
Zajedniki rad sa naruiocem u kljunim aspektima razvojnog procesa.
Cilj je odgovoriti na promjene, a ne na planiranje i praenje plana, jer je
nemogue da se svi zahtjevi predvide na poetku razvjnog procesa.

Ekstremno programiranje (eng.ekstreme programing)

Skup tehnika za nivelisanje kreativnosti projektnog tima uz minimizaciju
prekomjernog administriranja.

Karakteristike XP-a
Nove verzije mogu biti napravljene vie puta dnevno. Inkrementi se daju
kupcu svakih 15 dana.
Svi testovi moraju biti uraeni za svaku verziju i verzija se prihvata samo ako su
testovi bili uspjeni.

Metoda razvoja softvera

Metod razvoja softvera je konkretizavija odabranog modela za softverski
proces. Metoda uvodi specifnu terminologiju, dijeli osnovne aktivnosti u pod
aktivnosti itd.

Trokovi softverskog proizvoda

Potpuna cijena razvoja softvera ima raspodjelu kao na slici:

Slika 6 Prikaz trokova izrade softvera

Trokovi variraju zavisno od vrste sistema koji se razvija, kao i zahtjeva po pitanju
perofrmansi i pouzdanosti.

Case alati (eng. Computer Aided Software Engineering)

Case alati su softverski paketi koji daju automatizovanu podrku za pojedine
aktivnosti unutar softverskog procesa.
Alati su napravljeni u skladu sa odreeno metodom razvoja softvera,
implementiraju pravila iz te metode, sadre editore za odgovarajue dijagrame i
slue za izradu odgovarajue dokumentacije.
Case alati namijenjeni za podrku analize i razvoja se nazivaju upper CASE alati
jer podravaju rane faze.
Case alati koji podravaju implementaciju i testiranje kao to su su debuggers,
prgram anaysis system, test case generators, program editors se nazivaju lowerCASE alati.

Uesnici u razvoju softverskog procesa

Broj osoba koje rade na razvoju softvera zavisi od veliine i sloenosti
projekta ali uvijek se uloge jasno razlikuju.
Uloge mogu biti sljedee:
Kupac: - kompanija koja palaa za softverski sistem koji se razvija.
Korisnik stvarno radi na sistemu
Razvojni tim pravi softverski sistem za kupca tj.naruioca sastoji se od
softverskih inenjera, ali svaki od njih moe da se specijalizuje za poseban
aspekt razvojnog procesa.

ivotni ciklus softvera (eng.Software lifecycle)

Proces razvoja softvera se moe predstaviti nizom koraka poev od
formulisanja osnovnih koncepata, preko implementacije do isporuke i odravanja,
naziva se ivotni ciklus softvera.
Moemo izdvojiti sljedee cikluse razvoja softvera:

Analiza zahtjeva i specifikacija

Projetkovanje
Implementacija
Testiranje
Integracija
Isporuka
Odravanje

Svaka faza ivotnog ciklusa ima sopstvene aktivnosti i resurse.

Slika 7 Faze ivotnog ciklusa relativni trokovi

60% - 70% svih greaka otkrivenih u velikim projektima su nastale u fazi

definisanja ili u fazi projektovanja.
Zadatak softvesrkog inenjerstva je ne samo da se rano otkriju greke u ivotnom
ciklusu, ve i prevencija da ne doe do greaka.

Kratak praktini opis ivotnog ciklusa

Projekat zapoinje klijentovim zahtjevima za novi sistem.
Kreira se funkcionalna specifikacija za klijenta. To je lista zahtjeva koji
sistem mora zadovoljavati.
Jednom, kada kiljent prohvati Funkcionalnu specifikaciju, kreira se
specifikacija dizajna. Ovim se definie kako e sistem biti razvijen.
Softver se testira prema specifikaciji dizajna.
Softver se testira da se provjeri da li odgovara specifikacija dizajna.
Softver se testira prema funkcionalnoj specifikaciji dizajna.
Softver se testira prema funkcionalnoj specifikaciji, odnosno da li
zadovoljava sve zahtjeve?
Jedanput kada se testiranje uspjeno zavri, softver se isporuuje i instalira.
Softver se zatim odrava prema zahtjevima klijenata.

Naravno da ivotni ciklus mora sadrati odreene procedure, pa moemo rei da su

to:
Definisanje ciljeva odreivanje glavnih ishoda tj.rezultata projekta.
Analiza zahtjeva i specifikacija, tj prikupljanje, pregled i formulisanje
klijentskih zahtjeva i procjena moguih ogranienja.
Generalni dizajn generalni zahtjev u pogledu arhitetkure aplikacije.
Detaljni dizajn precizira definiciju svake komponente aplikacije.
Programiranje je implementacija pomou nekog programskog jezika u
cilju kreiranja funkcija budueg sistema, koje su definisane tokom faze
dizajna.
Testiranje modula aplikacije individulano testiranje svakog omdula
aplikacije da se osigura da su kreirani prema poetnoj specifikaciji.
Integracija osigurava da se razliiti moduli integriu u jednu aplikaciju.
Beta testiranje (ili debugging), provejrava da li softver odgovara na poetne
zahtjeve.
Dokumentacija dokumentuje neophodne informacije za korisnike softvera
i buduo razvoj.
Implementacija.
Odravanje sve korekcije (korektivno odravanje )i manji sofverski
update (tekue odravanje).

lanovi razvojnog tima

Analitiar zahtjeva komunicira sa kupcem, da bi se ono to kupac hoe
razloilo na pojedinane zahtjeve. Kada zahtjevi postanu dokumentovani,
analitiar radi sa projektantima na generisanju opisa funkcija sistema.
Programeri - piu kod koji implementira no je to je formulisano u zahtjevima.
Testni inenjeri rade na otkrivanju greaka koje prave programeri. Kada
razvojni tim bude zadovoljan sa kvalitetom sistema, tim za testiranje i kupac
zajedno rade na verifikovanju cjelokupnog sistema u odnosu na postavljene
zahtjeve.
Instruktori obuavaju korisnike za operativno korienje sistema.

Upravljanje softverskim projetkom

Potrebno je zato da bi se softver razvio na vrijeme i u okviru planiranih trokova.
Posao upravljanja projektom obavlja softverski menader.

Osobine softversog projekta

Razlikuje se od klasinog tehnikog projekta u sljedeem.
Proizvod je neopipljiv. Teko je vidjeti rezultat i procijeniti koliki dio posla
je obavljen.
Nema standardnog procesa. Postoje razne metode i alati, ali se ne zna ta je
najpogodnije u datim okolnostima.
Projekat je obino neponovljiv. Stara iskustva obino nisu prmjenjiva.
Pojavljuju se nepredvieni problemi. Tehnologija se brzo mijenja.
Zbog ovih osobina, upravljanje softverskim projektom je izuzetno teak
menaderski zadatak i zahtjeva izuzetno dobrog menadera.
Poslovi softverskog menadera izmeu ostalog ukljuuju i sljedee:

Pisanje predloga projekta,

Procjenjivanje trokova projekta,
Planiranje i praenje projketa,
Izbor i ocjenjivanje saradnika,
Pisanje izvjetaja i prezentovanje.

Planiranje i praenje projekta

Uvod definisanje i ogranienja.

Organizacija rasporeivanje ljudi i drugih resursa na aktivnosti.
Analiza rizika opisivanje moguih rizika i strategija smanjenja rizika.
Resursi hardverski i softverski zahtjevi.
Podjela poslova aktivnosti, ogranienja, zadaci.

 Raspored rada definisanje trajanja aktivnosti, njihova meuzaivsnost,

alokacija zadataka.
Mehanizam izvjetavanja praenje izvrenja aktivnosti, izvjetaj
rukovodstva.

Upravljanje rizicima
Rizini inioci po Boehmu :

Manjak osoblja,
Nerealni rokovi i budeti,
Razvoj pogrenih softverskih funkcija.
Razvoj pogrenoh korisnikog interfejsa,
Pozlaivanje (dodavanje vie nego to je potrebno),
Neprekidni niz izmjena u zahtjevima,
Nedostatak preformansi u realnom vremenu.

Zahtjevi i specifikacija za dizajniranje

aplikativnog softver
Prije poetka bilo kakve izrade softvera potrebno je da prikupimo odreene
specfikiacije koje su nam potrebne za dizajniranje istog. Pa bi zahtjevi i
specifikacije za dizajniranje softvera mogle biti:
Poetna faza softverskog procesa.
Analiziraju se zahtjei budeg sistema.
Rezultat je dokument o zahtjevima, koji opisuje ta sistem treba da radi.

ta je zahtjev
Zahtjev moe biti opisan na visokom nivou apstrakcije(bez detalja,
uopten)ili kao detaljni funkcionalni zahtjev.
Zahtjevi mogu imati dvojnu ulogu:
1. Osnova ugovaranje novog posla (tada moraju biti razumljivi za
interpretacije)
2. Osnova samog ugovora (tada moraju biti detaljno opisani).

Vrste zahtjeva
Kao glavnu podjelu ili grupaciju zahtjeva moemo rei da se dijele na :
Korisniki (user requirements)
o Iskazi u govornom jeziku plus dijagrami sa uslugama koje sistem
treba da prui, kao i ogranienja koja moraju postojati u sistemu.
Pie se za klijenta.
o Primjer: LIBSYS sistem treba da vodi evidenciju o svim
zahtjevima za dobijanje licence za tampanje udbenika u cijeloh
zemlji.
Sistemki zahtjevi (system requirements)
o Strukturirani dokument koji daje detaljni opis funkcija sistema,
usluga i operativnih ogranienja. Definie ta treba da se
implementira, tako da moe biti deo ugovora izmeu klijenta i
izvrioca. Ovaj dokument e naziva i funkcionalna specifikacija.

o Primjer: svi formulari za zahtjeve LIBSYS sistem moraju biti

indeksirani po autoru, naslovu i dobavljau.
o Zahtjevi koji se upuuju LIBSYS sistemu se moraju uvati pet
godina od datuma prijema.

Funkcionalni i nefunkcionalni zahtjevi

Funkcionalni zahtjevi
o Opisuju ta sistem treba da obezbijedi, kako sistem treba da reaguje
na odgovarajue ulaze i kako sistem treba da se ponaa u
specifinim situacijama. Nekada ovi zahtjevi opisuju i ta sistem ne
bi smio da radi.
Nefunkcionalni zahtjevi
o Ogranienja funkcionalnosti sistema, npr.vremenska ogranienja i
ogranienja uslijed standarda. Najee se odnose na sistem kao
cjelinu, a ne na pojedinu funkciju.
Problemi u zahtjevima:
Problemi nastaju kada zahtjevi nisu dovoljno dobro opisani. Dvosmisleni
zahtjevi se mogu interpretirati na razliite naine od strane korisnika i
softverskih inenjera.
Korisniko vienje preglednici za svaki razliit tip dokumenta;
Vienje inenjera obezbijediti tekstualni preglednik sa prikazom
sadraja fajlova.

Kompletnost i konzistentnost zahtjeva

U principu, zahtjevi treba da zadovolje i kompletnost i konzistentnost.
Kompletnost
o Treba da sadre opise svih zahtijevanih specifinosti.
Konzistentnost
o Ne smije da postoji kontradiktornost u opisima zahtjeva.
U praksi je gotovo nemogue proizvesti kompletan i konzistentan dokument o
zahtjevima.
Ono to je glavno jeste da je potrebno da razumijemo osnovne probleme i
potrebe naruioca.
Primjer sistema:

 Genrisanje platnih lisita:

o Listie treba izdavati na 15 dana,
o Direktna uplata depozita za radnike sa odreenom visinom plate,
o Pristup sistemu za obraun plate sa vie razliitih lokacija u okviru
kompanije.
o Obavezan prikaz opisa naina prorauna palte na samom lisitu.
Mi kao kreatori sistema traimo zahtjeve koji identifikuju:
Kljune entitete (npr: radnik je osoba koju plaa kompanija),
Entitete koji nameu ogranienja (npr: radnik ne moe biti plaen vie od
40 sati nedeljno)
Odnose mou entitetima (npr: ranika X nadgleda radnik Y i saki radnik
ima nekog nadreenog radnika).
Bitno je napomenuti da zahtjevi ne odreuju nain implementacije sistema,
zahtjevi su okrenuti nrauiocu i problemu a ne rjeavanju ili implementaciji.
Zahtjevi oznaavaju kakvo ponaanje naruilac eli, bez opisa kako e to
ponaanje biti ostvareno.

Specifikacija:
Proces evidentiranja zahtjeva
U toku ove faze pravi se odluka koje zahtjeve e softverski sistem da
ispuni. Nasuprot zahtjevima koji realizuju hardverski ureaju, drugi softverski
sistemi, operatori ili korisnici.
Aktivnosti specifikacije se moe podijeliti u podaktivnosti:
Studija izvodljivosti:
o Procjenjuje se da li se uoene potrebe korisnika mogu zadovoljiti
uz pomo dostupnih hardverskih i softverskih tehnologija, da li bi
predloeni sistem bio isplativ u poslovnom smislu, i da li sistem
moe biti razvijen s raspoloivim budetom.
Prikupljanje i analiza zahtjeva:
o Prikupljaju se zahtjevi, tako to se posmatraju postojei sistemi,
analiziraju radni sistemi, analiziraju radni procesi, intervjuiu
budui korisnici i njihovi rukovodioci, idt. Na taj nain stvaraju se
modeli sistema, a ponekad i prototipovi, sve u cilju boljeg
razumijevanja sistema koga treba kreirati.
Utvrivanje zahtjeva:

o Informacije skupljene analizom pretvaraju se u tekstove koji

definiu zahtjeve. Postoje dva nivoa u opisivanju zahtjeva:
Korisniki zahtjevi ,
Zahtjevi za sistem.
Validacija zahtjeva:
o Provjerava se da li su zahtjevi realni (mogu da se ostvare
raspoloivom tehnlogijom i budetom), konzistentni (nisu u
meusobnom konfliktu), i potpuni (ukljuene su sve potrebne
funkcije i ogranienja).

Nain odvijanja podaktivnosti

Slika 8 Nain odvijanja podaktivnosti

Vrste dokumenata za opis zahtjeva

Rezultat specifikacije su dokumenti koji opisuju zahtjeve.
Korisniki zahtjevi:
o To je manje precizan tekst u prirodnom jeziku, prilagoen krajnjim
korisnicima.
Sistemki zahtjevi:
o Detaljan i precizan opis funkcija sistema i ogranienja. Moe
sluiti kao temelj ugovora izmeu kupca i razvijaa softvera. Slui
softverskim ienjerima kao polazite za dizajniranje. Pisan je u
donekle strukturiranom prirodnom jeziku.
Modeli sistema:
o To su dijagrami koji opisuju ponaanje sistema na nain koji je
preizniji od prirodnog jezika. Nastaju tokom analize zahtjeva kao

sredstvo komunikacije izmeu razvijaa softvera i buduih

korisnika.
Dokument o zahtjevima:
o Rije je o konanom rezultatu specifikacije, dobijenom kao unija
svih prethodno opisanih dokumenata.
Korisniki zahtjevi
1. Softver mora da prui naine predstavljanja i pristupa eksternim
fajlovima kreiranim drugim alatima.
Sistemski zahtjevi
1. Korisniku treba pruiti mogunost definisanja tipa eksternih fajlova.
2. Svaki tip eksternog fajla moe imati dodijeljen alat koji se otvara.
3. Svakai tip eksternog fajla se moe predstaviti specijalnom ikonom na
ekranu.

Razlika izmeu definicije i specifikacija zahtjeva

Definicija zahtjeva:
o Namijenjena poslovnom auditorijumu (kupci, korisnici),
o Osnova ugovora ta treba isporuiti kupcu
o Piu je naruilac u analitiar
Specifikacija zahtjeca:
o Namijenjena tehnikom auditorijumu (projektanti)
o Referencira samo one entitete kojima moe da pristupi iz sistema
posredstvom interfejsa.
o Pie je analitiar.

Slika 9 Unija definicije i specifikacije

Doprinos procesu evidentiranja zahtjeva daju sljedei

subjekti:

Klijenti koji finansiraju razvoj softvera.

Kupci, koji kupuju softver,
Korisnici, oni koji poznaju postojei i koji e koristiti budui sistem.
Eksperti iz date oblasti primjene.
Pravnici i revizori, koji poznaju propise potrebne za dati sistem.
Sofverski inenjeri.

Dopunska sredstva

Raspoloiva dokumentacija
Posmatranje postojeeg sistema
Intervjuisanje korisnika
Uenje od korisnika

Moemo navesti jedan primjer kako korisnici i projektanti vide jedni druge,
gdje esto dolazi do nesporazuma.
Kako korisnici i projektanti vide jedni druge

Vienje korisnika
Projektanti ne razumiju operativne
potrebe.
Ne mogu jasno da prevedu
navedene potrebe u system.
Stavljaju veliki naglasak na tehnika
pitanja.
Projektanti uvijek kasne.
Uvijek premauju budet.
Sve vrijeme govore ne.
Hoe da nam kau da radimo svoj
posao.

Vienje projektanata
Korisnici ne znaju ta hoe.
Sve hoe odmah.
Nisu sposobni da obijasne ta im
treba.
Nemaju volju za compromise.
Ne ele da preuzmu odgovornost za
sistem.
Ne umiju da dodijele prioritete
svojim potrebama.
Ne mogu da prate rokove.

Modeliranje sistema
Modeli predstavljaju vaan most izmeu specifikacije i dizajniranja
sistema. Daje pojednostavljenu sliku sistema. Model posmatra sistem iz neke
odreene prespektive, pa istie neke njegove osobine a zanemaruje druge.
Najvanije perspektive su:
Kontekst: odreuje se granica izmeu sistema i njegove okoline.
Ponanje: promatraju se transformacije podataka, reakcije sistema na
dogaaje, i promjene njegovih sistema.
Struktura: modelira se arhitektura samog sistema ili graa podataka koje
on obrauje.
Da bi dobili celovitu sliku o sistemu, moramo imati nekoliko kompletiranih
modela koji ga posmatraju.

Modeli u fazi definisanja i specfikovanja zahtjeva

Kontekst: Model toka podataka za koji se koristi UML use-case dijagram.
Ponaanje: dinamiki model dijagram sekvenci (sequence diagram).
Struktura: model entiteta, veza i atributa dijagram klasa (class diagram).

Dijagram sluajeva korienja

Koristi se na poetku novog projekta za opis sutinskih funkcija na
najviem nivou apstrakcije.
Modeluju samo funkcionalnost sistema koju moe da inicira neki od uesnika iz
okruenja.
Sistema za biblioteku.
Granice sistema prikazane
Uesnici akteri
Sluajevi korienja

Model entiteta veza i atributa

Posmatra sistem iz perspektive strukture i opisuje grau podataka.
Navodi se entiteti, veze meu entitetima i atributi.

Opsiuje se funkcionalnost veza(1:1, 1:n, m:n)

Dijagram klasa
Prestvalja entitete i meusobne odnose
Korisni najprije pristupa katalogu biblioteke da vidi da li je odreeni dokument
dostupan u elektronskom obliku,
Zatim trai da mu se taj elektronski dokument dostavi preko mree. Zbog zatite
autorskih prava, od korisnika se zahtjeva da prihvati ugovor o licenciranju.
Mreni server na kraju alje dokument kompresovanom obliku.

Model ponaanje objekta

Dijagram sekvence
Pokazuje veze izmeu klasa koje se uspostavljaju time to objekti jedne
klase pokreu operacije druge klase.
Trag dogaaja je grafiki opis niza dogaaja koji se razmenjuju izmeu
entiteta u stvarnosti.

 Vodoravna linija dogaaj ili interakcija meu entitetima.

Vrijeme tee odozgo na dolje.
Jedan graf = jedno ponaanje.