1.

ta se modeluje dijagramima sekvence?

Naglaava redosled (sekvencu) ili konkurentnost interakcije .

Dijagrami sekvence predstavljaju ponaanje sluaja upotrebe koristei kao osnovu klase.
2.

ta se modeluje dijagramima kolaboracije?

Naglaava interakciju objekata.

Slue za prikaz sloenijih interakcija izmeu objekata i njihove meusobne povezanosti.
Fokusira se na kolaboracionoj strukturi i organizaciji izmeu objekata.
Modeluje link izmeu objekata .
Sastoji se od objekata, linkova, poruka .
3.

Razlika izmeu dijagrama sekvence i dijagrama kolaboracije.

Dijagram sekvence:Naglaava redosled (sekvencu) ili konkurentnost interakcije

Dijagram kolaboracije:Naglaava interakciju objekata
1.

ta se modeluje statechart dijagramima?

Statechart dijagram je pogodan za predstavljanje ponaanja sloenih sistema korienjem:

Vizuelnog formalizma
Bogatog alfabet modela
Modularnosti stanja
Paralelnog ponaanja
Statechart:
Modelovanje stanja
Zasnovano na automata modelima
Statechart gradivni blokovi
Stanja
Tranzicije
Napredne karakteristike
Kompozitna stanja
Paralelna stanja
1.

ta se modeluje dijagramima aktivnosti?

Omoguava modelovanje sloenog ponaanja

Koje se ne zasniva na interakcijama.
Ima paralelna ponaanja.
Predstavljanje tokova
Dobar za dizajn aktivnosti

1.

Objasniti ta su CASE alati i njihovu namenu.

Posebna grupa alata, koja automatizuje metode i procedure razvoja softvera i istovremeno:
skrauju vreme,
smanjuju trokove izrade i
podiu kvalitet razvijenog softverskog proizvoda.
To su programi koji automatizuju i podravaju jednu ili vie faza ivotnog ciklusa razvoja
sistema.
Namera ove tehnologije jeste da ubrza procese razvijanja sistema i pobolja njegov kvalitet.
CASE tehnologija
Poveanje produktivnosti u razvoju softvera pomou softvera
Inenjersko projektovanje softvera pomou raunara.
Softverski proizvod namjenjen automatizaciji izrade softvera
Njihova namena je:
Poveanje produktivnosti projektanata
Skraenje vremena izrade softvera |
Poveanje kvaliteta softvera
Unapreenje performansi sistema
Skup integrisanih raunarskih sistema za inenjering (CASE) i alate koji pomau razvoj
aplikacija u razvoju softvera, a koriste se za analizu poslovnih zahteva, projektovanje
aplikacija, generisanje koda aplikacije itd
2.

Nabrojati neke od komercijalnih i besplatnih CASE alata.

Komercijalni:
IBM Rational Rose
Borland Together
Microsoft Visio
Enterprise Arhitect
Besplatni:
Poseidon
Smart Drawn
Dia
ArgoUML

1.

Objasniti ta su to dizajn paterni i koja je njihova namena u softverskom

inenjerstvu

Dizajn patern
Reenje uestalog problema u dizajnu
Abstrakuje strukturu dizajna koji se ponavlja
Sastoji se od klasa i/ili objekata
Zavisnosti
Strukture
Interakcije
Konvencije
Eksplicitno imenuje i specificira strukturu i dizajn
Destilie iskustvo u dizajnu
Dizajn patern ima 4 osnovna dela:
Ime
Problem
Reenje
Posledice
Jezika i implementaciona nezavisnost
Mikro arhitektura
Usklaenost sa postojeim metodologijama
Nema mehanike primene
Programer mora prevesti reenje u konkretne pojmove u kontekstu aplikacije
2.

Objasniti zbog ega su nam potrebni dizajn paterni?

Viestruka upotreba znanja

Problemi nisu jedinstveni. Viestruko korienje prethodnog iskustva moe biti korisno.
Paterni nam daju savete gde da traimo probleme.
Uspostavljaju zajedniku terminologiju
Lake je rei: Ovde nam treba Facade .
Obezbeuju vei stepen apstrakcije
Oslobaa nas potrebe za rad sa previe detalja u ranim fazama
3.

Struktura dizajn paterna.

Ime paterna i klasifikacija - Saeto izlae sutinu

Namena - Kratak iskaz o tome ta patern radi
Motivacija - Scenario koji ilustruje problem projektovanja i nain na koji strukture klasa i
objekata u paternu reavaju taj problem.
Primenjivost - Na koje situacije se patern moe primeniti.
Struktura - Grafiki prikaz klasa u paternu.
Uesnici - Klase i/ili objekti koji uestvuju u paternu kao i njihove odgovornosti.
Saradnja - Kako uesnici sarauju da bi izvrili svoje odgovornosti.
3

Posledice - Koje su prednosti i nedostaci korienja paterna

Implementacija - Saveti i tehnike za implementaciju paterna
4. Osnovni tipovi GoF paterna prema njihovoj nameni.
Objasniti ime se bavi svaki od tipova paterna.
Creational (pravljenje) paterni:
Bave se postupkom inicijalizacije i konfigurisanja objekata.
Structural (struktura) paterni:
Bave se sastavljanjem klasa i objekata.
Behavioral (ponaanje) paterni:
Opisuju kako klase ili objekti meusobno utiu jedni na druge i kako dele odgovornosti.
5. Objasniti namenu i problem koji se reava za sledee dizajn paterne: Singleton,
Facade, Composite, Command, Template method, Observer, Adapter i Prototype.
Singleton
Namena
Obezbeuje da klasa ima samo jedan primerak (instancu) i daje mu globalnu taku pristupa.
Problem
Za neke klase je vano da imaju samo jednu instancu. Mada u sistemu moe da bude mnogo
tampaa, trebalo bi da postoji samo jedan spuler za tampanje. Trebalo bi da postoji samo
jedan sistem datoteka i jedan upravlja prozorima.
Reenje
Reenje je da se sama klasa uini odgovornom za uvanje zapisa o svojoj sopstvenoj
instanci.
Klasa moe obezbediti da se ne moe kreirati druga instanca (spreavanjem zahteva za
kreiranje novih objekata), kao i nain za pristup kreiranoj instanci.
Facade (Fasada)
Problem: Nema enkapsulacije
Operator mora da zna puno: strukturu + ponaanje
Preduslovi
Spretnost
Duplira metode
Slabija vidljivost funkcionalnosti podsistema.
Namena
Obezbeuje jedinstveni interfejs za skup interfejsa jednog podsistema.
Facade definie interfejs vieg nivoa da bi se podsistem lake koristio.
Primenjivost
Koristite Facade u sledeim sluajevima
Kada sloenom podsistemu hoete da date jednostavan interfejs.
Kada hoete da raslojite podsisteme. Upotrebite Facade za definisanje ulazne take za
svaki nivo podsistema.
4

Composite (Sastav)
Apstraktna osnovna klasa (Component) definie jedinstveno ponaanje.
Primitive i Composite klase su podklase.
Composite definie ponaanje komponenti koje imaju decu i uva komponente decu.
Posledice:
Dobre
Olakava dodavanje novih vrsta komponenti.
Pojednostavljuje posao klijentu koji obino ne znaju da li imaju posla sa listom ili sa
sloenom komponentom.
Loe
Moe da dovede do previe uoptenog dizajna, ime se tee postavljaju ogranienja za
komponente sastava.
Command (Komanda)
Poznat takoe kao Action (akcija), Transaction (transakcija)
Namena
Enkapsulira zahtev kao objekat ime omoguava parametrizaciju klijenata sa razliitim
zahtevima, redovima za ekanje, ili zahtevima za formiranje dnevnika rada, i podrava
operacije ije se dejstvo moe ponititi.
Kada hoete da parametrizujete objekte akcijom koju treba da izvre
Kada elite da navedete, poreate i izvrite zahteve u razliito vreme
Kada hoete da podrite ponitavanje akcije.
Kada hoete da podrite evidentiranje promena da bi se one mogle ponovo primeniti
Problem
Potrebno je da prosleuje zahteve objekata bez ikakvog znanja o operaciji koja se
zahteva ili o primaocu zahteva
Template method (ablonski metod)
Namena
Definie skelet algoritma u nekoj operaciji preputajui implementaciju nekih koraka potklasi.
Template metod dozvoljava da potklase redefiniu neke korake altoritma ne menjajui
strukturu altoritma.
Za impementiranje nepromenljivih delova algoritma na jednom mestu i preputanje
implementacije ponaanja koje se menja potklasama.
Kada ponaanje zajedniko za potklase treba izdvojiti i staviti u zajedniku klasu da bi se
izbeglo dupliranje koda.
Za kontrolu proirivanja potklasa. Moete da definiete ablonski metod koji na odreenim
takama poziva priljuene operacije i tako doputa proirivanje samo u tim takama.

Observer (posmatra)
Namena
Definie zavisnost jedan prema vie meu objektima da bi prilikom promene stanja jednog
objekta svi
zavisni objekti bili obaveteni i automatski aurirani.
Takoe poznat kao: Zavisnici (Dependents), izdavanje-pretplata (publish- subscribe)
Problem
Kako upravljati zajednikim sporednim efektom (npr. potreba za odravanjem konzistentnosti
izmeu povezanih objekata) podele sistema u kolekciju kooperirajuih klasa bez vrstog
spajanja klasa, - to smanjuje mogunost ponovne upotrebe klasa.
Resenje:
Observer patern opisuje kako uspostaviti ove relacije.
Kljuni objekti u ovom paternu su subjekat i posmatra.
Subjekat moe imati bilo koji broj zavisnih posmatraa.
Svi posmatrai se obavetavaju kada subjekat promeni stanje.
Na osnovu toga svaki posmatra e zatraiti od subjekta da sinhronizuje svoje stanje sa
njegovim.
Primenjivost:
Kada apstrakcija ima dva aspekta ok kojih jedan zavisi od drugoga. Enkapsuliranje tih
aspekata u zasebne objekte omoguava njihovo nezavisno menjanje i viekratnu upotrebu.
Kada promena u jednom objektu zahteva promene u drugim objektima, a ne znate koliko
drugih objekata treba promeniti
Kada objektu treba omoguiti da obavetava druge objekte bez ikakve pretpostavke o tome
koji su to objekti. Drugim reima, kada ne elite da ti objekti budu tesno vezani.
Adapter
Konvertuje interfejs klase u drugi interfejs koji klijenti oekuju.
Adapter omoguava saradnju klasa koje inae ne bi mogle da sarauju zbog nekompatibilnih
interfejsa.
Namena
Konvertuje interfejs klase u drugi interfejs koji klijenti oekuju. Adapter omoguava saradnju
klasa koje inae ne bi mogle da sarauju zbog nekompatibilnih interfejsa.
Takoe poznat kao: Wrapper (uvija)
Problem:
Editor za crtanje (DrawingEditor) omoguava korisnicima da crtaju i rasporeuju grafike
elemente. TextShape se znatno tee implementira, pa je korisno iskoristiti postojei tekst
editor (TextView) koji nije projektovan u skladu sa klasama Shape.
Resenje:
Jedan nain reavanja problema je da se napravi klijentska klasa (TextShape) koja e
adaptirati editor (TextView) i modifikovati interfejs da odgovara aplikaciji. Ovo se moe uraditi
na dva naina:
- Dodatnim izvoenjem TextView klase ili
- uvanjem reference na TextView klasu unutar TextShape klase.
6

Drugi metod ima prednost nad prvim jer se klijentska hijerarhija ne poveava u dubinu

Prototype (prototip)
Namena
Odreuje vrste objekata koji se prave koristei prototipski primerak i pravi nove objekte
kopiranjem tog prototipa.
Problem:
Okruenje u primeru obezbeuje apstraktnu klasu Graphic za grafike komponente, npr.
beleke i note. Osim toga, ona obezbeuje apstraktnu klasu Tool za definisanje alata poput
onih u paleti.
Okruenje takoe definie GraphicTool podklasu za alate koji kreiraju instance grafikih
objekata i dodaje ih u dokument.
GraphicTool klasa pripada okruenju dok su alati za beleke i note specifini u naoj
aplikaciji. GraphicTool ne zna kako da kreira instance naih muzikih klasa. Mogli bismo da
napravimo podklase
GraphicTool za svaku vrstu muzikog objekta, ali tako bi nastalo mnogo podklasa koje bi se
razlikovale samo po vrsti muzikog objekta koji instanciraju. Sastavljanje objekata je
fleksibilna alternativa za potklase.
Primenjivost:
Prototype treba da se koristi kada sistem ne sme da zavisi od toga kako se njegovi proizvodi
prave,
sastavljaju i predstavljaju,
Kada se klase koje treba instancirati odreuju u vreme izvravanja, na primer dinamikim
uitavanjem
1. Objasniti pojam testiranja softvera.
Testiranje softvera predstavlja proces analize elementa softvera kako bi se utvrdila razlika
izmeu postojeeg stanja i zahteva (tj., bagovi) i kako bi se ustanovile karakteristike softvera
2. Objasniti pojam pouzdanosti softvera.
Pouzdanost je sposobnost sistema ili njegove komponente da izvri zahtevane funkcije pod
definisanim uslovima u odreenom vremenskom periodu.
3. Objasniti pojmove validacija i verifikacija softvera.
Validacija:
proces evaluacije sistema ili komponente za vreme ili na kraju procesa razvoja da bi se
utvrdilo da li zadovoljava zahteve definisane od korisnika
Validacija: Da li kreiramo pravi proizvod?
Verifikacija:
proces evaluacije sistema ili komponente kako bi se utvrdilo da li proizvod korektno
implementira odreenu funkciju
Verifikacija: Da li kreiramo proizvod na pravi nain?
7

Verifikacijom se utvruje da li proizvod zadovoljava zahteve definisane tokom

prethodnih aktivnosti tokom ivotnog ciklusa, dok validacija proverava da li sistem
zadovoljava korisnike zahteve na kraju ivotnog ciklusa.

4. Objasniti pojmove: propust, nedostatak, otkaz i greka u kontekstu razvoja softvera.

Propust (Mistake)
ljudska akcija koja dovodi do pogrenog rezultata.
Nedostatak (Fault ili Defect)
pogrean korak, proces ili definicija podataka u programu.
Otkaz (Failure)
nemogunost sistema ili njegove komponente da izvri zahtevanu funkciju u skladu sa
definisanim zahtevima.
Greka (Error)
razlika izmeu izraunate, uoene ili izmerene vrednosti ili uslova i stvarne, definisane
ili teoretski ispravne vrednosti ili uslova.
5. Objasniti ta predstavlja kvalitet softvera.
Kvalitet predstavlja ispunjenje zahteva.
Prema ovoj definiciji, da bi imali kvalitetan proizvod zahtevi moraju biti merljivi, a zahtevi e
biti ispunjeni ili nee biti ispunjeni.
Korisnik definie kvalitet kao ispunjenost odreenim korisnikovih potreba za proizvodom ili
uslugom.
6. Na koji nain se postie saglasnost oko kvaliteta softvera?
Kvalitet zahteva saglasnost, uglavnom top menadmenta.
Mnogi veruju da je nemogue napraviti proizvod ili servis bez greke, i smatraju odreeni
stepen greaka kao normalan i prihvatljiv.
Kvalitet je esto vezan sa trokovima, to znai da vei kvalitet znai i vee trokove.
Kvalitet zahteva detaljnu specifikaciju zahteva kako bi se konani proizvod mogao
kvantitativno uporediti sa ovim specifikacijama.
Praenje jasno definisanih standarda i procedure. Tehniki orjenitisana lica esto smatraju
da standardi gue njihovu kreativnost.
7. Uticaj prevencije i detekcije na kvalitet softverskog proizvoda.
Kvalitet se ne moe postii procenom ve gotovog proizvoda, stoga je prvenstveni cilj
spreiti gubitak kvaliteta i omoguiti procenu kvaliteta korienjem standarda za razvoj
softvera.
Osim procene proizvoda, i procena procesa je znaajna za obezbeivanje kvaliteta (npr.
dokumentacija za korienje standarda za kodiranje, upotreba drugih standarda, metoda i
alata, procedura za backup podataka...)
Upravljanje kvalitetom smanjuje trokove razvoja - ranije otkrivanje nedostataka smanjuje
kasnije znatno vee trokove.
8

8. ta sve utie na ukupne trokove upravljanja kvalitetom.

Objasniti svaku komponentu.
Ukupni trokovi efikasnog upravljanja kvalitetom predstavljaju sumu trokova etiri
komponente:
Spreavanje (prevention) sastoji se od akcija na spreavanju pojave nedostataka
na prvom mestu.
Kontrola (inspection) sastoji se od merenja, evaluacije i kontrolisanja
proizvoda prema standardima i specifikacijama.
Unutranji otkaz oni trokovi koji se javljaju zbog otklanjanja nedostataka pre
njegove konane isporuke.
Spoljanji otkaz - trokovi otklanjanja nedostataka nakon isporuke proizvoda.

9. Objasniti pojmove: obezbeivanje kvaliteta, kontrola kvaliteta, funkcija kontrolisanja

i testiranje softvera.
Obezbeivanje kvaliteta softvera:
Kvalitet softvera se obezbeuje upotrebom definisanih smernica za kontrolu kvaliteta.
este su nedoumice oko znaenja pojmova: obezbeivanje kvaliteta, kontrola kvaliteta,
funkcija, kontrolisanja i testiranje softvera.
Obezbeivanje kvaliteta je funkcija odgovorna za upravljanje kvalitetom.
Kvalitet softvera se postie praenjem plana za obezbeivanje kvaliteta softvera koji definie
metode koje e se koristiti u projektu kako bi kreirana dokumenta i proizvodi na kraju svake
faze bili visokog kvaliteta.
Kontrola kvaliteta:
Procesi i metode koji se koriste za proces praenja i ispunjenosti zahteva.
Fokusira se na praenju i uklanjanju nedostataka pre isporuke proizvoda.
Kontrola kvaliteta je u odgovornosti organizacione jedinice koja izrauje proizvod.
Najee obuhvata: kontrolu specifikacija, kontrolu koda i dokumenata i kontrolu
meuproizvoda koji se isporuuju korisniku.
Funkcija kontrolisanja:
Bavi se obeleavanjem, praenjem i kontrolisanjem promena u softverskim elementima
sistema.
Kontrolie evoluciju softverskog sistema praenjem verzija softverskih komponenti i njihovih
relacija.
Namena je da se identifikuju relacije izmeu softverskih komponenti i da se prati njihova
evolucija kroz ivotni ciklus.
Testiranje softvera:
Popularna strategija za upravljanje rizikom.
Koristi se da verifikuje da li su ispunjeni funkcionalni zahtevi.
Ogranienje ovog pristupa je da u vreme kada se realizuje testiranje, prekasno je da se
9

kvalitet ugradi u proizvod.

10. Objasniti osnovne komponente za obezbeivanje kvaliteta softvera.

Testiranje softvera
Popularna strategija za upravljanje rizikom.
Koristi se da verifikuje da li su ispunjeni funkcionalni zahtevi.
Ogranienje ovog pristupa je da u vreme kada se realizuje testiranje, prekasno je da se
kvalitet ugradi u proizvod.
Upravljanje konfiguracijom softvera
Bavi se obeleavanjem, praenjem i kontrolisanjem promena u softverskim elementima
sistema.
Kontrolie evoluciju softverskog sistema praenjem verzija softverskih komponenti i njihovih
relacija.
Namena je da se identifikuju relacije izmeu softverskih komponenti i da se prati njihova
evolucija kroz ivotni ciklus.
Kontrola kvaliteta
Procesi i metode koji se koriste za proces praenja i ispunjenosti zahteva.
Fokusira se na praenju i uklanjanju nedostataka pre isporuke proizvoda.
Kontrola kvaliteta je u odgovornosti organizacione jedinice koja izrauje proizvod.
Najee obuhvata: kontrolu specifikacija, kontrolu koda i dokumenata i kontrolu
meuproizvoda koji se isporuuju korisniku.
11. Objasniti sve trokove obuhvaene cenom kvaliteta.
Cena kvaliteta moe biti podeljena na trokove:
Prevencije (planiranje kvaliteta, formalna tehnika recenzija, oprema za testiranje,
obuka)
Procene - aktivnosti kojima se vri detaljna analiza svakog procesa (inspekcija
unutranjih i meuprocesa, kalibracija i odravanje opreme, testiranje)
Cena trokova otkaza obuhvata one trokove kojih ne bi bilo u sluaju da je
proizvod isporuen korisniku bez defekata.
Mogu se podeliti na interne i eksterne otkaze.
Trokovi internih otkaza obuhvataju ponovni rad, popravku, analiza otkaza
Trokovi eksternih otkaza obuhvataju analizu primedbi, povratak i zamenu proizvoda,
odravanje podrke, rad u okviru garancije.
12. Merenje pouzdanosti softvera.
Verovatnoa da e kompjuterski program funkcionisati bez otkaza u specifinom okruenju u
odreenom vremenskom periodu.
Jednostavan nain za merenje pouzdanosti je meantime-between-failure (MTBF)
MTBF = MTTF + MTTR
MTTF (mean-time-to-failure)
MTTR (mean-time-to-repair)
10

13. Merenje dostupnosti softvera.

Verovatnoa da e softver funkcionisati prema zahtevima u datom vremenskom trenutku:
Dostupnost = [ MTTF / ( MTTF + MTTR ) ] x 100%
14. Navesti i objasniti osnovne faktore koji utiu na kvalitet softvera.
Faktori koji utiu na kvalitet softvera mogu se grupisati u dve osnovne grupe:
Faktorikojisemogudirektnomeriti,
Faktorikojisemogumeritiindirektno.
Korektnost
stepen do kojeg program zadovoljava svoje specifikacije i korisnikove zahteve.
Pouzdanost
stepen do kog se moe oekivati da program izvri funkc. sa zahtevanom preciznou
Efikasnost
koliina raunarskih resursa i koda potrebnog da program izvri svoje funkcije.
Integritet
stepen do koga pristup softveru i podacima neautorizovane osobe moe biti
kontrolisan
Upotrebljivost
napor koji se ulae za uenje, korienje, pripremu ulaza I interpretaciju izlaza program
Odrivost
napor koji je potrebno uloiti u lociranje i popravljanje greke u programu.
Fleksibilnost
napor koji je potrebno uloiti u modifikovanje operacionog programa.
Proverljivost
napor koji se ulae za testiranje programa da bi se proverilo da li izvrava funkcije.
Portabilnost
napor uloen za prenos programa sa jednog hardvera ili softversk. okruenja na drugo
Mogunost ponovnog korienja (reusability)
Interoperabilnost
napor potreban da spoji jedan sistem sa drugim.
15. Objasniti osnovne ciljeve i principe testiranja softvera.
Testiranje je proces izvrenja programa sa ciljem pronalaenja greke.
Dobar plan izvrenja testa je onaj koji ima veliku verovatnou pronalaenja jo neotkrivene
greke.
Uspean test je onaj koji otkrije jo neotkrivenu greku.
Pareto princip vai za testiranje softvera (80% greaka neotkrivenih u toku testiranja e se
verovatno nalaziti u 20% komponenti).
Problem je izolovati ove sumnjive komponente i detaljno ih testirati.
Testiranje treba zapoeti na malo i napredovati na veliko
(najpre sa individualnim komponentama a zavriti sa sistemom kao celinom).
Potpuno testiranje nije mogue.
11

Radi to vee efikasnosti, testiranjem treba da upravlja nezavisna, trea strana

(pod efikasnou se misli na najveu verovatnou pronalaenja greaka)

16. Navesti i objasniti osnovne karakteristike od kojih zavisi mogunost testiranja

softvera.
Skup karakteristika koje vode do softvera koji se moe testirati:
Operativnost (operability) to bolje radi, efikasnije se moe testirati
Sistem ima malo bagova,
Nema bagova koji blokiraju izvrenje testova,
Proizvod se razvija kroz funkcionalne faze (mogu istovremeni razvoj i testiranje)
Vidljivost (observability) Ono to vidi je ono to testira
Za svaki ulaz se generie drugaiji izlaz,
Stanje sistema i promenljive su vidljive u vreme izvrenja,
Ranija stanja sistema i promenljive su vidljive,
Upravljivost (controllability) to bolje moemo kontrolisati softver, bolje moemo
automatizovati i optimizovati testove
Svi mogui izlazi se mogu generisati kroz neku kombinaciju ulaza,
Sav kod je izvran kroz neku kombinaciju ulaza,
Stanje i promenljive softvera i hardvera se mogu direktno kontrolisati od strane inenjera
testa,
Ulazni i izlazni formati su konzistentni i struktuirani,
Mogunost dekomponovanja (decomposability) kontrolisanjem opsega testiranja,
moemo bre izolovati probleme i izvriti pametnije ponavljanje testa
Softverski sistem je izgraen od nezavisnih modula,
Softverski moduli se mogu testirati nezavisno.
Jednostavnost (simplicity) to manje stvari za testiranje, bre emo zavriti test
Funkcionalna jednostavnost,
Strukturna jednostavnost,
Jednostavnost programskog koda.
Stabilnost (stability) to manje promena, manje je poremeaja u testiranju
Promene softvera su retke,
Promene softvera su kontrolisane,
Promene softvera ne naruavaju postojee testove,
Razumljivost (understendability) to vie informacija imamo, pametnije emo
testirati
Dizajn je razumljiv,
Zavisnosti izmeu internih, eksternih i deljenih komponenti su razumljive i jasne,
Tehnika dokumentacija je odmah dostupna, dobro organizovana, detaljna i tana.
17. Navesti i objasniti osnovne karakteristike dobrog testa.
Dobar test ima veliku verovatnou pronalaenja greke.
12

Da bi postigao ovo, tester mora razumeti softver i pokuati da razvije mentalnu sliku
toga kako bi softver mogao da otkae.
Dobar test nije redundantan.
Vreme i resursi testiranja su ogranieni. Nema svrhe izvravati test koji ima istu svrhu
kao i ve izvreni test.
Dobar test treba da bude najbolji svoje vrste.
U grupi testova koji imaju istu namenu potrebno je izabrati onaj sa najveom
verovatnoom otkrivanja greaka.
Dobar test ne treba da bude ni previe jednostavan ni previe sloen.
18. Navesti i objasniti osnovne aktivnosti procesa testiranja softvera.
Testiranje se sastoji od sledeih aktivnosti:
Planiranje testiranja
(odreduje se predmet, cilj i razlog testiranja (na osnovu zahteva, modela i drugih ulaza
testiranja), gde se testiranje vri, kada se vri i ko izvrava testove)
Dizajn testova
(odreduje kako se sprovodi testiranje na osnovu artefakta tj. test primera)
Implementacija testova
(pravljenje viestruko upotrebljivih test scriptova koji realizuju test primere)
Izvravanje testova
(izvravanje implementacije testa radi provere funkcionalnosti sistema)
Evaluacija testova
(procena testova tj. validnosti izvravanja testa, analiza izlaza, pregled zbirnih
rezultata, uticaj promene zahteva i ulaza na plan testiranja)
19. Navesti i objasniti osnovne tehnike testiranja softvera.
Tipovi testiranja:
Recenzija (review)
formalni stastanak na kome se artefakt ili skup artefakata predstavlja korisniku ili
drugim stranama koje uestvuju u procesu odobravanja ili komentarisanja.
Inspekcija (inspection)
fomalna tehnika procene u kojoj se artefakti detaljno pregledaju. Pregled vre osobe
koje nisu autori, da bi se lake uoile greke i drugi problemi.
Pregledi (walkthrough)
Tehnika pregleda u kojoj autor upoznaje ostale clanove tima sa elementima artefakta
koji je izgradio. Ostali lanovi uestvuju aktivno u raspravi.
1. Jedinino testiranje (unit testing)
primenjuje se na pojedine klase, module ili komponente programskog koda. Ova
tehnika deli se na tehnike bele i crne kutije.
2. Integraciono testiranje
primenjuje se na softverski sitem kao celinu.
3. U testiranja vieg reda spadaju:
testiranje sigurnosti (security testing): da li su funkcije dostupne onim i samo onim
korisnicima kojima su i namenjene.
13

testiranje koliine podataka verifikovanje da li softver moe obraditi veliku kolicinu

podataka.
testiranje upotrebljivosti (usability testing) estetski aspekti, konzistentnost
korisnickog interfejsa, korisnicka dokumentacija.
testiranje integriteta (integrity testing) robusnost(otpornost na otkaze),
konzistentna upotreba resursa i sl.
test u stresnim uslovima (stress testing) vrsta testa pouzdanosti sistema pod
nenormalnim uslovima (velika opterecenja sistema, nedovoljno memorije ili drugih
resursa, neraspoloivi servisi i sl.).
etalonski test - uporedenje performansi novog sistema sa nekim, referentnim,
poznatim sistemom.
test zaguenja provera da li sistem moe da zadovolji viestruke zahteve razlicitih
aktera za istim resursom.
test optereenja vrsta testa performansi kojim se procenjuju operativni limiti
nepromenjivog sistema pod razlicitim opterecenjima ili razlicitih konfiguracija sistema
pri istom opterecenju. Najcece se mere protok i vreme odziva (srednja i granicna
vrednost).
test konfiguracije (configuration testing) testira ponaanje softvera u razlicitim
hardversko/softverskim okruenjima.
test instalacije (installation testing) testira instaliranje softvera na razlicitim
sistemima i u razliitim situacijama (npr. prekid napajanja ili nedovoljno prostora na
disku).

4. Regresiono testiranje
na osnovu jednom razvijenog testa vie puta se sprovodi testiranje softvera (tipicno
nakon neke izmene u softveru da bi se utvrdilo da nisu pokvarene funkcionalnosti
softvera).

14

20. Objasniti osnovne karakteristike Black-box i White-box testiranja softvera

Black box (funkcionalno) testiranje
Tretira program ili sistem kao
To jest, testiranje ne gleda programski kod ili unutranju strukturu sistema.
Ukoliko su poznate funkcije koje sistem treba da izvri, testovi se mogu usmeriti ka
demonstraciji da je svaka funkcija potpuno operaciona i u isto vreme da trae greke u
svakoj funkciji
Programu se alju ulazni podaci, prati se izlaz i donosi se odluka da li je sistem proao
ili pao test.
Ponekad nemamo mogunost pristupa programskom kodu.
White box (strukturno) testiranje
Poznato i kao glass-box.
Obuhvata ispitivanje interne strukture programa ili sistema.
Ukoliko je poznato interno funkcionisanje proizvoda, testovi se mogu usmeriti ka
utvrivanju da svi mehanizmi, tj. interne operacije funkcioniu prema specifikacijama
Testni podaci se dobijaju ispitivanjem logike programa ili sistema, bez brige o
zahtevima koje treba da zadovolji.
21. Objasniti osnovne strategije za testiranje softvera.
U kontekstu spirale to su:
Testiranje jedinice
Kod
Integraciona testiranja
Dizajn
Validacija testiranja
Zahtevi
15

 Sistemska testiranja
Sistemski inzenjering

Koraci za testiranje softvera:

Testiranje pravca
Kod
Dizajn
Zahtevi

22. Navesti i objasniti osnovne CASE alate za testiranje softvera.

Test manager:
upravlja testiranjem tako to pokree softver koji se testira za razne test podatke.
Generator test podataka:
generie test primere koji odgovaraju specifikaciji, i to izborom iz baze primera ili
gerenirsanjem sluajnih vrednosti korektnog oblika.
Prorok:
daje prognozirane (oekivane) rezultate testa. Prorok moe biti prethodna verzija
softvera koji testiramo, ili prototip.
Komparator datoteka:
otkriva razlike izmeu stvarnih i oekivanih rezultata testa.
16

Generator izvetaja:
oblikuje izvetaj o rezultatima testiranja.
Dinamiki analizator:
broji koliko puta se pojedina naredba programa izvrila tokom testiranja.
1. Pojam odravanja softvera.
Proces modifikovanja softverskog sistema ili komponente nakon isporuke radi otklanjanja
greaka, poboljanja performansi ili drugih atributa, ili prilagoavanja promenljivom okruenju.
Odravanje programa nakon to je stavljen u upotrebu
Softverski proizvod se podvrgava modifikaciji koda ili dokumentacije usled problema ili
potrebe za unapreenjem.
Cilj je modifikovanje postojeeg softverskog proizvoda dok se istovremeno ouvava njegov
integritet
Izmene se implementiraju modifikovanjem postojeih komponentii dodavanjem novih
komponenti sistemu
2. Pojam evolucije softvera.
Skup aktivnosti, tehnikih I upravnih, koje obezbeuju da softver nastavi da ispunjava
organizacione I poslovne ciljeve na isplativ nain
Sve programerske aktivnosti iji je cilj generisanje nove verzije softvera na osnovu starije
operacione verzije
Primena aktivnosti I procesa odravanja softvera kojima se generie nova operativna verzija
softvera sa novim funkcionalnostima ili karakteristima u odnosu na prethodnu operativnu
verziju pri emu su obuhvaene I aktivnosti obezbeivanja kvaliteta
3. Navesti i objasniti vrste odravanja softvera.
Adaptivno odravanje
Modifikacija softverskog proizvoda izvrena nakon isporuke da bi se ouvala
upotrebljivost softverskog proizvoda u promenjenom ili promenljivom okruenju."
Korektivno odravanje
Ispravljaju se uoene greke. Moe se raditi o grekama u kodiranju, u oblikovanju,
odnosno u specifikaciji."
Perfekcijsko odravanje
Modifikacija softverskog proizvoda nakon isporuke radi unapreenja performansi ili
dodavanja novih karakteristika.
Preventivno odravanje
Modifikacija softverskog proizvoda nakon isporuke radi utvrivanja I korigovanja
latentnih greaka u softverskom proizvodu pre nego to one nanesu tetu."
4. Navesti i objasniti osnovne razloge za evoluciju softvera.
Promene korisnikih zahteva
17

 Proirenja ili modifikacije koje je zahtevao korisnik

Otklanjanja bagova
Planirane aktivnosti otklanjanja
Nuno otklanjanje (uglavnom skupo zbog velikog pritiska)
Promene formata podataka
Y2K, Euro, poreske rate, potanski kodovi, telefonski brojevi,...
Novi standardi: UML, XML, COM, DCOM, CORBA, ActiveX, WAP
Hardverske promene
Poveanje efikasnosti
5. Objasniti pojam starenje softvera.
Neophodno je da nauimo kako da spreimo efekte starenja Programi, kao I ljudi stare.
Starenje ne moemo spreiti, ali moemo razumeti njegove uzroke, preuzeti korake da
ograniimo njegove efekte, privremeno otklonimo neke od teta koje je izazvalo I pripremimo
se za dan kada softver vie nee biti upotrebljiv.

6. Navesti i objasniti razloge za starenje softvera.

Odravanje
Nefleksibilnost od poetka projekta
Nedovoljna ili nekonzistentna dokumentacija
Pritisak krajnjih rokova
Dupliranje funkcionalnosti (dupliranje koda)
Nedostatak modularnosti
Mogue reenje: reininjerstvo
7. Objasniti pojam legacy sistemi. (nasleeni sistemi)

Bilo kakvi informacioni system koji se opire promenama

Postojei kompjuterski system ili aplikacioni program koji se nastavlja koristiti jer
korisnik (najee organizacija) ne eli da ga zameni ili redizajnira.
Mnogi ljudi koriste ovaj pojam da ukau na zastarele sisteme.
Sa tehnolokog aspekta
ak I kompletno funkcionalan I odriv system se moe smatrati zastarelim ukoliko
koristi prevazienu tehnologiju.
Sa ekonomskog aspekta
system se moe smatrati zastarelim ukoliko ne moe da prati tempo promena u
poslovnom domenu.
8. Navesti i objasniti probleme i razloge za korienje legacy sistema.
Problemi:
esto se izvravaju na zastarelom hardveru
Teko se odrava, unapreuje I proiruje
Opti nedostatak razumevanja sistema:
18

 Nema osoba koje mogu objasniti kako funkcionie

Dokumentacija ili uputstva su se izgubili tokom godina
Teka je integracija sa novim sistemima
Razlozi za korienje:
Trokovi redizajna sistema su preterano visoki jer je system veliki, monolitski i/ili kompleksan.
Sistem zahteva 100% dostupnost, pa ne moe biti stavljen van upotrebe.
Nain na koji system funkcionie nije dobro shvaen.
Korisnik oekuje da system moe biti jednostavno zamenjen kada to bude neophodno.
Sistem radi zadovoljavajue, I vlasnik ne vidi razlog za njegovu promenu.

9. Navesti i objasniti Lehman-ove zakone.

Nunost menjanja
Softver koji se zaista koristi u stvarnom svetu nuno se mora menjati jer u protivnom
ubrzo postaje neupotrebljiv.
Poveanje sloenosti
Dok se softver menja, njegova struktura tei tome da postane sve sloenija. Da bi se
ouvala jednostavnost strukture, potrebno je uloiti dodatni trud I resurse.
Ograniena brzina unapreivanja
Koliina novosti koju pojedino izdanje softvera moe doneti otprilike je konstantna I
karakteristina za taj softver.
10. Navesti i objasniti osnovne faktore koji utiu na cenu odravanja softvera.
Celovitost polazne specifikacije
Ukoliko odmah ukljuimo sve zahteve, kasnije e biti manje perfekcijskog odravanja.
Kvalitet dizajna
Dobar dizajn je jeftiniji za odravanje.
Smatra se da su sa stanovita odravanja najbolji objektno-orjentisani sistemi, koji se sastoje
od malih modula sa jakom unutranjom kohezijom I labavim vezama prema spolja.
Nain implementacije
Kod u stroem jeziku poput Jave lake se odrava nego kod u jeziku poput C-a. Struktirirani
kod (if, while) sa smisleno imenovanim varijablama razumljiviji je od kompaktnog koda s
mnogo goto naredbi.
Stepen verificiranosti
Dobro verificirani softver ima manje greaka pa e zahtevati manje korekcijskog odravanja.
Stepen dokumentovanosti
19

uredna, dobro struktuirana I celovita dokumentacija olakava razumevanje softvera, pa na taj

nain pojeftinjuje odravanje.
Nain upravljanja konfiguracijom
Ukoliko se primenjuju metode, alati I organizacijska pravila upravljanja konfiguracijom, tada je
odravanje na dugi rok jeftinije.
Starost softvera
to je softver stariji, to je skuplji za odravanja, budui da mu se graa degradirala, zavistan
je od zastarelih razvojnih alata, a dokumentacija mu je postal neaurna.
Svojstva aplikacijskog domena
Ako je re o stabilnom domenu gde se poslovna pravila retko menjaju, tada e se retko
pojavljivati potreba za perfekcijskim odravanjem u svrhu usklaivanja s novim pravilima.
Stabilnost razvojnog tima
Odravanje je jeftinije ako se njime bave originalni razvijai softvera, jer oni ne moraju troiti
vreme na upoznavanje sa softverom.
Stabilnost platforme
Ako smo softver implementirali na platform koja e jo dugo biti savremena, tada nee trebati
adaptacijsko odravanje.

11. Navesti i objasniti osnovne tehnike odravanja softvera

(redokumentovanje, restruktuiranje, reverzni inenjering, reinenjering).
Redokumentovanje
Obuhvata statiku analizu izvornog koda da bi se proizvela dokumentacija sistema.
Moemo da ispitamo upotrebu promenljivih, pozive komponenti, putanje upravljanja,
veliinu komponenti, pozivajue parametre, putanje testiranja...
Informacije koje proizvede statika analiza mogu da budu grafike ili tekstualne.
Reverzni inenjering
Proces reverznog inenjeringa evoluira kroz est koraka:
Ralanjivanje izvornog koda u formalne jedinice,
Semantiki opis formalne jedinice I kreiranje funkcionalnih jedinica,
Opis linkova za svaku jedinicu (dijagram ulazno/izlaznih jedinica),
Kreiranje mape svih jedinica I onoga to sledi od uzastopno povezanih jedinica,
Deklaracije I semantiki opis sistemskih aplikacija,
Stvaranje anatomije sistema
Reverzni (obrnuti) inenjering se definie kao process analiziranja predmeta sistema u cilju
identifikacije sistemskih komponenti, njihovih meusobnih odnosa I kreiranja prezentacije
sistema u drugom obliku ili na viem nivou apstrakcije.
U skladu sa tim, reverzni inenjering je process ispitivanja, nije process promena I zato ne
ukljuuje menjanje softvera prilikom ispitivanja.
Reinenjering
Softverski reinenjering je aktivnost koja:
Poboljava razumevanje softvera, ili
20

Priprema I poboljava sam softver, obino za poveanu sposobnost odravanja,

ponovno korienje, ili evoluciju.

---------------------------------------------------------------------------------------------------------------------------Navesti i objasniti sve komponente koje utiu na ukupne trokove kojima se postie efikasno
upravljanje kvalitetom softvera
---------------------------------------------------------------------------------------------------------------------------Objasniti namenu i problem koji se reava korienjem Singleton dizajn paterna
---------------------------------------------------------------------------------------------------------------------------Objasniti ta su to legacy sistemi i koji su razlozi za njihovo korienje uprkos problemima
---------------------------------------------------------------------------------------------------------------------------Objasniti razliku izmeu pojmova verifikacija i validacija
---------------------------------------------------------------------------------------------------------------------------Objasniti namenu i problem koji se reava korienjem Facade dizajn paterna
---------------------------------------------------------------------------------------------------------------------------Navesti i objasniti osnovne razloge za evoluciju softvera
---------------------------------------------------------------------------------------------------------------------------Navesti i objasniti osnovne faktore kvaliteta softvera
---------------------------------------------------------------------------------------------------------------------------Objasniti namenu i problem koji se reava korienjem Adapter dizajn paterna
---------------------------------------------------------------------------------------------------------------------------Navesti i objasniti osnovne vrste odravanja softvera
---------------------------------------------------------------------------------------------------------------------------Objasniti namenu i problem koji se reava korienjem Command dizajn paterna.
---------------------------------------------------------------------------------------------------------------------------Objasniti razliku izmeu pojmova white-box testiranje i black-box testiranje.
---------------------------------------------------------------------------------------------------------------------------Navesti i objasniti osnovne Lehman-ove zakone odravanja softvera.
---------------------------------------------------------------------------------------------------------------------------21