Softversko Inzenjerstvo

1. Kvalitet i produktivnost konacnog softverskog proizvoda zavise od:

Vestine ljudi ukljucenih u projekat, procesa koji koriste razlicite zadatke u projektu i alata koji se koristi

Motivisanosti pojedinaca ukljucenih u razvojni proces od njegovog pocetka

Budzeta koji je stavljen na raspolaganje razvojnom timu za izradu softvera

Ne znam

2. Testiranje jedinice predstavlja:

Proveru da li svaka pojedinacna komponenta funkcionise

Proveru da li aplikacija radi sa drugim aplikacijama

Provera da li svi programi u aplikaciji rade zajedno

Ne znam

3. Kvalitet i produktivnost konacnog softverskog proizvoda zavise od:

Vestine ljudi ukljucenih u projekat, procesa koji koriste razlicite zadatke u projektu i alata koji se koristi

Motivisanosti pojedinaca ukljucenih u razvojni proces od njegovog pocetka

Budzeta koji je sastavljen na raspolaganje razvojnom timu za izradu softvera

Ne znam

4. Pouzdanost kao karakteristika dobrog softvera oznacava:

Da softver mora pouzdano da izvrsava sve definisane funkcije, da je bezbedan i siguran

Da softver ne sme nepotrebno da trosi sistemske resurse kao sto su memorija i procesorsko vreme

Da softver mora biti napravljen na takav nacin da moze lako da evoluira u skladu sa promenama zahteva korisnika

Da softver mora biti prihvatljiv za one korisnike za koje je napravljen

5. Pojam "prototip" oznacava:

Graficki prikaz elemenata korisnickog interfejsa

Nekompletna verzija softvera koji se razvija

Softverski alat dizajniran da podrzi aktivnosti zivotnog ciklusa razvoja softvera

Ne znam

6. Minimalne garancije u kontekstu specifikacije slucaja upotrebe predstavljaju:

Ono sto se desava nakon uspesnog izvrasavanja slucaja upotrebe

Rezultat realizovanog slucaja upotrebe

Ono sto sistem moze obecati, cak i kada se slucaj upotrebe nije uspesno realizovao

Ne znam

7. Efikasnost kao karakteristika dobrog softvera oznacava:

Da softver mora pouzdano da izvrasava sve definisane funkcije, da je bezbedan i siguran

Da softver mora biti napravljen na takav nacin da moze lako da evoluira u skladu sa promenama zahteva korisnika

Da softver ne sme nepotrebno da trosi sistemske resurse kao sto su memorija i procesorsko vreme

Da softver mora biti prihvatljiv za one korisnike za koje je napravljeno

8. Navesti koji od navedenih zahteva mozemo definisati kao skriveni zahtev:

Gotovina ce se iz bankomata dati korisniku nakon sto se izvadi kartica

Proces odrzavanja baze podataka ce se odvijati svake noci

Proces autorizacije ne sme da traje duze od jedne sekunde

Ne znam

9. Adapter dizajn patern:

Obezbedjuje jedinstveni interfejs za pristup jednom delu sistema

Konvertuje interfejs klase u drugi interfejs koji klijenti ocekuju

Prosledjuje obavestenja skupu pravila objekata o nekom dogadjaju koji se desio

Ne znam

10. Ukoliko zelimo da obezbedimo, da neka klasa ima samo jedan primerak koji ce biti dostupan sa dobro poznate tacke, koristicemo sledeci dizajn patern:

Facede

Singleton

Observer

Adapter

Composite

Ne znam

11. Ukoliko zelimo da upotrebimo postojecu klasu, a njen interfejs nije uskladjen sa interfejsom koji nam treba, koristicemo sledeci dizajn patern:

Facade

Singleton

Adapter

Observer

Composite

Ne znam

12. Navesti objekat koji se u dijagramu slucajeva upotrebe ne moze uzeti kao ucesnik:

Senzor

Baza podataka

Osoba

Oraganizaciona jedinica

13. Model kod koga se trazi da su svi korisnicki zahtevi dobro poznati pre pocetka razvoja softvera se naziva:

Metodologija za paralelni razvoj

Extreme Progrramming (xp) metodologija

Waterfall metodologija

Ne znam

14. Odrzivost kao karakteristika dobrog softvera oznacava:

Da softver mora pouzdano da izvrsava sve definisane funkcije, da je bezbedan i siguran

Da softver mora biti napravljen na takav nacin da moze lako da evoluira u skladu sa promenama zahteva korisnika

Da softver ne sme nepotrebno da trosi sistemske resurse kao sto su memorija i procesorsko vreme

Da softver mora biti prihvatljiv za one korisnike za koje je napravljen

15. Efikasnost kao karakteristika dobrog softvera oznacava:

Da softver mora pouzdano da izvrasava sve definisane funkcije, da je bezbedan i siguran

Da softver mora biti napravljen na takav nacin da moze lako da evoluira u skladu sa promenama zahteva korisnika

Da softver ne sme nepotrebno da trosi sistemske resurse kao sto su memorija i procesorsko vreme

Da softver mora biti prihvatljiv za one korisnike za koje je napravljeno

16. Granicne klase predstavljaju:

Klase koje se bave komunikacijom izmedju okoline sistema i njegove unutrasnjosti

Klase koje obezbedjuju komunikaciju sa bazom podataka

Klase koje se bave skladistenjem i upravljanjem info. u sistemu

Ne znam

17. Interaktivne aplikacije su:

Kontrolni sistemi koji kontrolisu i upravljaju hardverskim uredjajima

Aplikacije namenjene prvenstveno licnoj upotrebi i zabavi korisnika

Aplikacije koje se izvrsavanju na udaljenom racunaru, a kojima korisnici pristupaju sa svojih personalnih racunara ili terminala

Ne znam

18. Singleton dizajn patern:

Obezbedjuje da klasa ima samo jednu instancu kojoj se uvek pristupa

Obezbedjuje jedinstveni interfejs za pristup jednom delu sistema

Definise ponasanje komp. koje imaju decu i cuva komponente decu

Ne znam

19. Pojam "mockup" predstavlja:

Graficki prikaz elemenata korisnickog interfejsa

Nekompletna verzija softvera koji se razvija

Softver ciji je zahtev da simulira samo nekoliko aspekata funkcionalnosti eventualnog softvera

Softverski alat dizajniran da podrzi aktivnosti zivotnog ciklusa razvoja softvera

20. Nasledjivanje u dijagramima slucajeva upotrebe se koristi za:

Definisanje relacije u kojoj jedan slucaj upotrebe prosiruje prostojece funkcionalnosti drugog slucaja upotrebe

Definisanje relacije u kojoj jedan slucaj upotrebe koristi prostojece funkcionalnosti drugog slucaja upotrebe

Definisanje relacije u kojoj jedan slucaj upotrebe dete nasledjuje ponasanje roditeljskog slucaja upotrebe

Ne znam

21. Observer dizajn patern:

Obezbedjuje jedinstveni interfejs za pristup jednom delu sistema

Konvertuje interfejs klase u drugi interfejs koji klijenti ocekuju

Prosledjuje obavestenja o skupu pravila objekata u nekom dogadjaju koji se desio

Ne znam

22. Dijagram razmestaja:

Prikazuje staticki pregled hardverske konfiguracije i sof. komponenti koje se izvrsavaju na tim cvorovima

Prikazuje kolaboraciju izmedju objekata prlikom modelovanja ponasanja slucaja upotrebe

23. Validacija softvera kao aktivnost softverskog procesa obuhvata:

Aktivnosti koje inzenjeri preduzimaju kako bi se proverilo da li softver ispunjava korisnicke zahteve

Aktivnosti koje korisnici i inzenjeri preduzimaju radi definisanja softvera koji treba izraditi

Aktivnosti koje inzenjeri preduzimaju kako bi se softver modifikovao u skladu sa promenama zahteva korisnika i trzista

Aktivnosti koje inzenjeri ukljuceni u proces razvoja softvera preduzimaju u cilju dizajniranja i implementacije softvera

24. Composite dizajn patern:

Definise ponasanje komponenti koje imaju decu i cuva komponente decu

Prosledjuje obavestenje skupu objekata o nekom dogadjaju koji se desio

Konvertuje interfejs klase u drugi interfejs koji klijenti ocekuju

Ne znam

25. Extend relacija u dijagramima slucajevima upotrebe se koristi za:

Dekomponovanje slozenog ponasanja i centralizovanje zajednickog ponasanja

Definisanje relacije u kojoj slucaj upotrebe dete nasledjuje ponasanje roditeljskog slucaja upotrebe

Ukljucivanje drugih slucajeva upotrebe u odredjenim tackama prosirenja

Ne znam

26. Dijagram slucajeva koriscenja (Use Case):

Opisuje ponasanje ciljnog sistema posmatrajuci iz aspekta spoljasnje sredine

Opisuje tok kontrole ciljnog sistema, izrazavanje slozenih poslovnih pravila i operacija

Opisuje strukturne relacije izmedju softverskih komponenti sistema

Ne znam

27. Najjednostavniji model razvoja softvera sa najmanje planiranja unapred se naziva:

Build and Fix model

Waterfall metodologija

Spiralni model

Extreme Programming (xp) metodologija

Metodologija za paralelni razvoj

28. Relacija "realizuje" u dijagramu klasa se koristi da prikaze:

Da odredjena klasa implementira neki interfejs

Da odredjena klasa koristi funkcionalnosti druge klase

Da odredjena klasa nasledjuje roditeljsku klasu

Ne znam

29. Specifikacija softvera kao aktivnost soft. procesa obuhvata:

Aktivnosti koje inzenjeri preduzimaju kako bi se proverilo da li softver ispunjava korisnicke zahteve

Aktivnosti koje korisnici i inzenjeri preduzimaju radi definisanja softvera koji treba izraditi

Aktivnosti koje inzenjeri preduzimaju kako bi se softver modifikovao u skladu sa promenama zahteva korisnika i trzista

Aktivnosti koje inzenjeri ukljuceni u proces razvoja softvera preduzimaju u cilju dizajniranja i implementacije softvera

30. Interfejs predstavlja:

Posebnu klasu koja se koristi za komunikaciju sa krajnjim korisnikom

Skup pravila koja svaka klasa koja ga implementira mora postovati

Klasa koja ima samo atribute

Ne znam

31. Dijagram klasa:

Prikazuje domenske koncepte u formi domenskog modela, prikazuje njihove medjusobne relacije, operacije i atribute

Prikazuje strukturne relacije izmedju softverskih komponenti sistema

Prikazuje kolaboraciju izmedju objekata prilikom modelovanja ponasanja slucaja upotrebe

Ne znam

32. Izvodljivost je pojam koji oznacava:

Procenu koliku ce korist kompanija imati od sistema i da li je moguce realizovati sistem analizom razlicitih aspekata

Procenu da li razvojni tim ima dovoljno ljudi na raspolaganju da u datom vremenskom roku implementira sistem

Procenu da li se ekonomski isplati realizovati odredjeni info. sistem

Ne znam

33. Ukoliko zelimo da definisemo zavisnost jedan prema vise medju objektima da bi se prilikom promene stanja objekata svi zavisni objekti bili obavesteni koristicemo sledeci dizajn patern:

Facade

Singleton

Adapter

Observer

Composite

34. Facade dizajn patern:

Definise ponasanje komponenti koje imaju decu i cuva komponentu decu

Obezbedjuje jedinstveni interfejs za pristup jednom delu sitema

Konvertuje interfejs klase u drugi interfejs koji klijenti ocekuju

Ne znam

35. Testiranje integracije predstavlja:

Proveru da li svaka pojedinacna komponenta funkcionise

Proveru da li aplikacija radi sa drugim aplikacijama

Proveru da li svi programi u aplikaciji rade zajdeno

Ne znam

36. Zivotni ciklus razvoja softvera u fazi planiranja obuhvata sledece aktivnosti:

Razvoj programskog koda

Proucavanje trenutnog sistema, utvrdjivanje korisnickih zahteva i predlaganje resenja

Definisanje i razvoj detalja sistema

Pregled projektnih zahteva i analizu prioriteta projektnih zahteva

Reviziju sistema i identifikovanje resenja

37. Include relacija u dijagramima slucajeva upotrebe se koristi za:

Definisanje relacija u kojoj jedan slucaj upotrebe prosiruje postojece funkc. drugog slucaja upotrebe

Dekomponovanje slozenog ponasanja i cenralizovanje zajednickog ponasanja

Ukljucivanje drugih slucajeva upotrebe u odredjenim tackama prosirenja

Ne znam

38. Kljucne apstrakcije predstavljaju:

Bitne koncepte dobijene identifikovanejm najapstraktnijih klasa u dijagramu klasa

Skup abstraktnih klasa u dijagramu klasa

Bitne koncepte identifikovane tokom poslovnog modelovanja i analize zahteva

Ne znam

39. Analiticar sistema je:

Osoba koja vrsi analizu postojeceg informacionog sistema ili zahteva korisnika

Osoba angazovana na implementaciji informacionog sistema

Osoba odgovorna za dizajn i razvoj informacionog sistema

Ne znam

40. Entitetske klase predstavljaju:

Klase korisnickog interfejsa

Klase koje se mogu opisati kao kljucne za funkcionisanje odredjenog dela sistema

Skladista informacija u sistemu

Ne znam

41. Zivotni ciklus razvoja softvera u fazi dizajna obuhvata sledece aktivnosti:

Razvoj programskog koda

Proucavanje trenutnog sistema, utvrdjivanje korisnickih zahteva i predlaganje resenja

Definisanje i razvoj detalja sistema

Pregled projektnih zahteva i analiza prioriteta projektnih zahteva

Reviziju sistema i identifikovanje resenja

42. Kontrolne klase predstavljaju:

Klase koje kontrolisu pristup odredjenim delovima sistema, npr bazi podataka

Koje se koriste za modelovanje ponasanja za jedan slucaj upotrebe

Klase koje kontrolisu prava pristupa korisnika

Ne znam

43. Dijagram aktivnosti:

Opisuje ponasanje ciljnog sistema posmatrajuci iz aspekta spoljasnje sredine

Omogucava opisivanje toka kontrole ciljnog sistema, istrazivanje slozenih poslovnih operacija i pravila

Prikazuje kolaboraciju izmedju objekata prilikom modelovanja ponasanja slucaja upotrebe

Ne znam

Softversko Inzenjerstvo

1. Kvalitet i produktivnost konacnog softverskog proizvoda zavise od:

2.

What first name or nickname would you like us to use?

2. Testiranje jedinice predstavlja:

3. Kvalitet i produktivnost konacnog softverskog proizvoda zavise od:

4. Pouzdanost kao karakteristika dobrog softvera oznacava:

5. Pojam "prototip" oznacava:

6. Minimalne garancije u kontekstu specifikacije slucaja upotrebe predstavljaju:

7. Efikasnost kao karakteristika dobrog softvera oznacava:

8. Navesti koji od navedenih zahteva mozemo definisati kao skriveni zahtev:

9. Adapter dizajn patern:

10. Ukoliko zelimo da obezbedimo, da neka klasa ima samo jedan primerak koji ce biti dostupan sa dobro poznate tacke, koristicemo sledeci dizajn patern:

11. Ukoliko zelimo da upotrebimo postojecu klasu, a njen interfejs nije uskladjen sa interfejsom koji nam treba, koristicemo sledeci dizajn patern:

12. Navesti objekat koji se u dijagramu slucajeva upotrebe ne moze uzeti kao ucesnik:

13. Model kod koga se trazi da su svi korisnicki zahtevi dobro poznati pre pocetka razvoja softvera se naziva:

14. Odrzivost kao karakteristika dobrog softvera oznacava:

15. Efikasnost kao karakteristika dobrog softvera oznacava:

16. Granicne klase predstavljaju:

17. Interaktivne aplikacije su:

18. Singleton dizajn patern:

19. Pojam "mockup" predstavlja:

20. Nasledjivanje u dijagramima slucajeva upotrebe se koristi za:

21. Observer dizajn patern:

22. Dijagram razmestaja:

23. Validacija softvera kao aktivnost softverskog procesa obuhvata:

24. Composite dizajn patern:

25. Extend relacija u dijagramima slucajevima upotrebe se koristi za:

26. Dijagram slucajeva koriscenja (Use Case):

27. Najjednostavniji model razvoja softvera sa najmanje planiranja unapred se naziva:

28. Relacija "realizuje" u dijagramu klasa se koristi da prikaze:

29. Specifikacija softvera kao aktivnost soft. procesa obuhvata:

30. Interfejs predstavlja:

31. Dijagram klasa:

32. Izvodljivost je pojam koji oznacava:

33. Ukoliko zelimo da definisemo zavisnost jedan prema vise medju objektima da bi se prilikom promene stanja objekata svi zavisni objekti bili obavesteni koristicemo sledeci dizajn patern:

34. Facade dizajn patern:

35. Testiranje integracije predstavlja:

36. Zivotni ciklus razvoja softvera u fazi planiranja obuhvata sledece aktivnosti:

37. Include relacija u dijagramima slucajeva upotrebe se koristi za:

38. Kljucne apstrakcije predstavljaju:

39. Analiticar sistema je:

40. Entitetske klase predstavljaju:

41. Zivotni ciklus razvoja softvera u fazi dizajna obuhvata sledece aktivnosti:

42. Kontrolne klase predstavljaju:

43. Dijagram aktivnosti: