Internacionalni univerzitet u novom pazaruDepartman za raunarske naukeSmjer: informatika

Dizajn aplikativnog softvera

Biljeke sa predavanja doc.dr.Muzafera Saraevia

Biljeke priredili studenti:Ervin Pepi, Edvin Cikoti.

Novi Pazar2015,2016. godine

Uvodna rijeIntenzivan 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, 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.Slika 1 Mesto aplikativnog softvera u raunarskom okruenju

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 2006Standish 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 softverSoftverski proizvod je skup raunarskih programa i pripadajue dokumentacije, koji je stvoren zato da bi se prodao. 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: Microsoft Office Narueni (bespoke, custom) razvijen za odreenog klijenta prema zahtijevanoj specifikaciji na primjer: Kontrolni sistem za elektronske ureaje, Sistem napravljen da podri odrene djelove poslovnog procesa, Sistemi za kontrolu klima ureaja.Softversko inenjerstvoSoftversko 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 naukaRaunarske 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 inenjerstvaSistemsko 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 procesSoftverski proces je skup aktivnosti i pripadajuih rezultata iji je cilj razvoj ili evolucija softvera.Osnovne karakteristike softverskog procesa su: Specifikacija, dizajniranje, implementacija, verifikacija, validacija i odravaje.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 procesaModel 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, 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 modelNa 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.prednosti modela evolucijskog razvoja:Slika 3 protoipski model

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.

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

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 razvojaHibrid 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 razvojaPrednosti 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-aNove 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 softveraMetod razvoja softvera je konkretizavija odabranog modela za softverski proces. Metoda uvodi specifnu terminologiju, dijeli osnovne aktivnosti u pod aktivnosti itd.Trokovi softverskog proizvodaPotpuna 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 lower-CASE alati.Uesnici u razvoju softverskog procesaBroj 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 OdravanjeSvaka 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 timaAnalitiar 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 projektaRazlikuje 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 rizicimaRizini 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 softverPrije 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 zahtjevZahtjev 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 zahtjevaKao glavnu podjelu ili grupaciju zahtjeva moemo rei da se dijele na : Korisniki (user requirements) 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. Primjer: LIBSYS sistem treba da vodi evidenciju o svim zahtjevima za dobijanje licence za tampanje udbenika u cijeloh zemlji.

Sistemki zahtjevi (system requirements) 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. Primjer: svi formulari za zahtjeve LIBSYS sistem moraju biti indeksirani po autoru, naslovu i dobavljau. Zahtjevi koji se upuuju LIBSYS sistemu se moraju uvati pet godina od datuma prijema.Funkcionalni i nefunkcionalni zahtjevi Funkcionalni zahtjevi 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 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 zahtjevaU principu, zahtjevi treba da zadovolje i kompletnost i konzistentnost. Kompletnost Treba da sadre opise svih zahtijevanih specifinosti. Konzistentnost 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: Listie treba izdavati na 15 dana, Direktna uplata depozita za radnike sa odreenom visinom plate, Pristup sistemu za obraun plate sa vie razliitih lokacija u okviru kompanije. 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 zahtjevaU 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: 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: 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: Informacije skupljene analizom pretvaraju se u tekstove koji definiu zahtjeve. Postoje dva nivoa u opisivanju zahtjeva: Korisniki zahtjevi , Zahtjevi za sistem. Validacija zahtjeva: 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 podaktivnostiSlika 8 Nain odvijanja podaktivnosti

Vrste dokumenata za opis zahtjevaRezultat specifikacije su dokumenti koji opisuju zahtjeve. Korisniki zahtjevi: To je manje precizan tekst u prirodnom jeziku, prilagoen krajnjim korisnicima. Sistemki zahtjevi: 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: 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: Rije je o konanom rezultatu specifikacije, dobijenom kao unija svih prethodno opisanih dokumenata.

Korisniki zahtjevi1. Softver mora da prui naine predstavljanja i pristupa eksternim fajlovima kreiranim drugim alatima.Sistemski zahtjevi1. 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: Namijenjena poslovnom auditorijumu (kupci, korisnici), Osnova ugovora ta treba isporuiti kupcu Piu je naruilac u analitiar Specifikacija zahtjeca: Namijenjena tehnikom auditorijumu (projektanti) Referencira samo one entitete kojima moe da pristupi iz sistema posredstvom interfejsa. 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 korisnikaMoemo navesti jedan primjer kako korisnici i projektanti vide jedni druge, gdje esto dolazi do nesporazuma.Kako korisnici i projektanti vide jedni drugeVienje 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.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.

Modeliranje sistemaModeli 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 zahtjevaKontekst: 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 korienjaKoristi 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 atributaPosmatra 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 odnoseKorisni 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 objektaDijagram 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.