Professional Documents
Culture Documents
DAS Razvojno Oruženje
DAS Razvojno Oruženje
DAS Razvojno Oruženje
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.
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.
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.
programa
pripadajue
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.
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
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.
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.
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.
Trokovi variraju zavisno od vrste sistema koji se razvija, kao i zahtjeva po pitanju
perofrmansi i pouzdanosti.
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.
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.
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:
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.
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.