B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

1. Izpitna vprašanja PRI

Powerpoint: 02._pi_programsko_inženirstvo (predavanja)

1. Zakaj potrebujemo programsko inženirstvo?

Potreba po programskem inženirstvu se je pojavila zaradi krize programske opreme v 60-tih letih.
Leta 1968 so na konferenci pod pokroviteljstvom organizacije NATO prvič skovali izraz programsko
inženirstvo. Izraz je bil prvotno mišljen nekoliko provokativno, da bi odgovorili na dilemo, ali je
možno programsko opremo zgraditi na podoben način, kot se gradijo mostovi in hiše, s pomočjo
zdrave teoretične podlage in preizkušenih konstrukcijskih metod, tako kot v drugih inženirskih
disciplinah.

Bistvene značilnosti programskega inženirstva so:

1. Osnovni cilj programskega inženirstva je uporabna in kvalitetna programska oprema.
Programska oprema, ki je rezultat sistematičnega razvojnega dela, je veliko več kot
računalniški program, ki je le rezultat programiranja. Sistemski programski produkt naj bi bil
ustrezno testiran, dokumentiran in povezljiv v širšo celoto, na bi ga bilo tudi enostavno
vzdrževati in uporabljati (vidiki kvalitete).
2. Programsko inženirstvo zanima predvsem gradnja velikih sistemov. (večji programi in
običajno tudi večje število med seboj povezanih programov)
3. Pri velikih sistemih je težko hkrati nadzorovati vse podrobnosti. Kompleksnosti se običajno
lotimo tako, da večje probleme razdelimo na manjše in obvladljive. Delitev mora biti na
podprobleme taka, da so ločnice med njimi čim bolj jasne in preproste. Pri programskem
inženirstvu tako delitev dosežemo s programskimi moduli, ki skrbijo za določeno nalogo.
Velika večina programskih sistemov ni kompleksna zaradi kompleksnosti problema, ki ga
rešuje, temveč zato, ker mora hkrati obvladovati veliko število podrobnosti.
4. Pri razvoju velikih sistemov, ki zahtevajo veliko časa in ljudi, je učinkovitost izrednega
pomena. Potrebno je kontrolirati stroške in čas razvoja, saj skupine za razvoj programske
opreme tekmujejo pri tem z drugimi razvojnimi skupinami. Potrebe po novih aplikacija pa
tudi prekašajo obstoječe zmogljivosti.
5. Za razvoj programske opreme se je zato uveljavil projektni način dela, ki omogoča:
1) skrbno načrtovanje dela in
2) njegovo delitev med posameznimi razvijalci,
3) kontrolo časa, stroškov in drugih zmogljivosti
4) delitev odgovornosti
5) organizacijo komunikacij
6) nadzor kvalitete opravljenega dela

Programsko inženirstvo potrebujemo za preprost pogled na razvoj programov:

specifikacija problema → končni program

- Za učinkovit razvoj programske opreme

Po nastanku prvega računalnika v 40-ih letih se začne hitri razvoj programiranja, ki

povzroči naslednje probleme:
- hitro rast velikosti in količine programov
- neformalni pristop razvoju temeljni na individualnih potrebah programerjev, ki so
obenem uporabniki programov
- rast števila programerjev

1|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

V 60 letih je nastala t.i. programska kriza:

- programi niso kakovostni.
- zamude na razvojnih projektih.
- preseganje načrtovanih budžetov.
- neučinkovitost programov.
- problemi pri vzdrževanju programov.

Več kot 50% slabih projektov.

Ravno zaradi nje so v letih 1968 in 1969 začetki programskega inženirstva

(pokrovitelj NATO).

Inženirstvo je disciplina, ki se ukvarja z metodologijami, ki so učinkovite pri izgradnji

velikih in kompleksnih sistemov.

Programsko inženirstvo je:

- sistematični pristop k razvoju velikih in kompleksnih programov.
- je uporaba sistematičnih, discipliniranih, kvantificiranih pristopov k razvoju,
izvajanju in vzdrževanju programskih izdelkov, oz. uporaba inženirstva na
programski izdelek.
- je znanost in umetnost izgradnje kompleksnih programskih izdelkov:
o pravočasno,
o s predvidenimi stroški,
o s sprejemljivimi performansami,
o s pravilnimi funkcionalnostmi.

Programsko inženirstvo je uporaba sistematičnega, discipliniranega in določljivega

pristopa k razvoju, uporabi in vzdrževanju programske opreme, t.j., uporaba inženirstva
na področju programske opreme. IEEE Std. 610.12

2. Pojasni razmerje med sistemskimi stroški in stroški

programske opreme. Kaj je značilno za stroške PO?

- Stroški programske opreme dominirajo med sistemskimi stroški. Stroški

programske opreme na osebnem računalniku so pogosto večji od stroškov
strojne opreme.

- Pri programski opremi so stroški vzdrževanja večji od stroškov razvoja.

- Programsko inženirstvo se ukvarja (med ostalim) z učinkovitim razvojem

programske opreme.

Sistemski – stroški ki so potrebni za cel sistem

Stroški Programske opreme- so večji od stroška HW, stroški vzdrževanja večji od
stroškov razvoja (stroški od zagona do produkcije in stroške od produkcije do ukinitve –
pri vzdrževanju
Glej krivuljo

2|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

3. Kaj pri definiciji programskega inženirstva poudarja

Parnas?

Parnas poudarja, da je programsko inženirstvo »več-osebni razvoj več-verzijskega

programskega izdelka.« (Parnas, 1978)

Programski izdelek bo vedno pomemben za več kot eno osebo (bo najmanj en
razvijalec in en uporabnik, v večini primerov pa bo več razvijalcev). Za uspešen projekt
razvoja programske rešitve je potrebna skrbna in obsežna komunikacija med razvijalcem
in uporabnikom. Pomembna pa je tudi skrbna in obsežna komunikacija med razvijalci
samimi. Potrebno je jasno določiti odgovornosti posameznega razvijalca. Vsak razvijalec
mora vedeti kaj se zahteva od njega, da naredi in kaj se lahko pričakuje od drugih. Vsi
razvijalci zahtevajo jasen opis lastnosti sistema (strojne in programske opreme).

Uspešni izdelki programske opreme se razvijajo, a starejše verzije še vedno obstajajo.

Tudi v primerih, ko želijo popolnoma nadomestiti staro verzijo z novo, se določeni kupci
odločijo, da še naprej uporabljajo staro verzijo. Včasih se razvija nova verzija, ki se
namerava izvajati na novi platformi, je namenjena novemu segmentu kupcev ali pa
zagotavljajo drugačne storitve od stare verzije. Starejše verzije pa ostanejo in the
product line.

Programske rešitve so lahko:

1. Novi izdelki so razviti »iz nič«.

2. Novi izdelki so razviti iz nič, ampak lahko ponovno uporabite kakšno staro kodo.
Nekatere ponovno uporabljene kode so lahko modificirane (spremenjene).

3. Nove verzije so izdelane tako, da so narejene na podlagi spremembe obstoječe

verzije.

4. Povzeti programi so lahko razviti za družino, nato pa prilagojeni za točno

določenega družinskega člana.

5. Izdelki so lahko sestavljeni iz modulov, med katerimi imajo nekateri več

zamenljivih izvedb implementacij

6. Nekatere verzije so lahko podskupin ali razširitev drugih različic.

Linija izdelkov je lahko narejena s kombinacijo teh metod oz. tehnik.

4. Kaj je programski izdelek? Kakšne vrste programskih

izdelkov poznamo?

Programski izdelek (ang. software) je množica programov in pripadajoče

dokumentacije, ki se predajo uporabniku. Pogosto se uporablja tudi izraz programska
oprema (PO). PO je: abstraktna, kompleksna, fleksibilna, težko merljivih lastnosti.

Programske izdelke delimo na:

- Generični izdelki: samostojni sistemi, ki jih je razvilo neko podjetje in jih
prodajajo na odprtem trgu.
- Izdelki po meri: sistemi, ki jih je razvilo določeno pogodbeno podjetje za
posameznega naročnika.

3|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

5. Naštej nekaj tem programskega inženirstva.

Osnovne teme programskega inženirstva so:

1. Izgradnja velikih programskih sistemov.
2. Upravljanje s kompleksnostjo.
3. Evolucija programskih izdelkov.
4. Učinkovitost razvoja programskih izdelkov.
5. Upravljanje s komunikacijo pri razvoju velikih programskih izdelkov.
6. Dobava učinkovitega programskega izdelka.

6. Naštej nekaj aktivnosti programskega inženiringa (ki ni

programiranje).

Nekaj aktivnosti programskega inženiringa:

1. Sistemski inženiring
o Izbira razvojnega procesa in izobraževanje
2. Zahteve
o zbiranje,
o analiza in
o oblikovanje

3. Izbira tehnologije in izobraževanje

4. Načrtovanje – oblikovanje
o arhitektura,
o komponente in
o moduli
5. Kodiranje – programiranje
o test modulov in
o odprava napak
6. Integracija
o izgradnja,
o integracijski test in
o management konfiguracij
7. Test celotnega sistema
o performančni test in optimizacija,
o test sprejemljivosti in
o beta testiranje
8. Namestitev
o dobava in
o inštalacija
9. Produkcija
o vzdrževanje in
o nadgradnje

10. Podporne aktivnost

11. Projektno vodenje

o stiki z naročnikom,
o izboljševanje procesov,
o izobraževanje in

4|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

o dokumentacija

7. Kakšni so lahko projekti razvoja programske opreme

(glede na doseg in glede na tehnične procese)?

Glede na doseg so projekti lahko:

1. novi projekti
2. korektivni - odprava napak
3. adaptivni - spremembe zaradi sprememb okolja (npr. OS, PB, zakonodaje, ...)
4. nadgradnje – dodatne funkcionalnosti
5. re-inženirski – notranje spremembe (npr. zaradi lažjega vzdrževanja)
6. integracijski – oblikovanje novih sistemov z združitvijo manjših celot in
komponent

Glede na tehnične procese so projekti lahko:

1. razvojni projekti (ang. development project).

2. projekti integracije in verifikacije (ang. integration & verification projects).
3. projekti vzdrževanja (ang. maintenance projects).

8. Katere so osnovne faze življenjskega cikla programske

opreme?

Življenjski cikel razvoja programske opreme (ang. software development life cycle SDLC)
je zaporedje razpoznavnih korakov skozi katere gre programski izdelek:

1. študija izvedljivosti (ang. feasibility study),

2. analiza in specifikacija zahtev (ang. requirements analisys and specification),
3. načrtovanje (ang. design),
4. izgradnja (ang. implementation),
5. testiranje (ang. testing),
6. namestitev in vzdrževanje (ang. installation and maintenance).

9. Opiši značilnosti posamezne faze življenjskega cikla

programske opreme.

Študija izvedljivosti:
- Je namenjena predhodni odločitvi o začetku projekta razvoja:
1. Kaj je obseg predlaganega projekta?
2. Ali je projekt tehnično izvedljiv?
3. Kakšne bodo koristi od projekta?
4. Kakšni so stroški, časovnica?

- Pelje k odločitvi gremo ali ne gremo v izvedbo projekta.

Analiza in specifikacija zahtev:

- Osnovni cilj je opis problema, ki ga je potrebno rešiti in definiranje zahtev
skladno s:
o podanim problemom in

5|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

o okoljem, kateremu je sistem namenjen (npr. strojna oprema, programska

oprema, uporabniki, zakonodaja, ...).
- Osnovni dokument te faze je specifikacija zahtev.
- Zahteve definirajo funkcionalnosti sistema iz vidika naročnika: kaj naročnik
potrebuje in ne kaj je povedal, da potrebuje
- Zahteve se lahko določijo v samostojni študiji ali lahko nastanejo inkrementalno.

Načrtovanje:
- Načrt (ang. design) opisuje sistem iz vidika razvijalca:
o kako naj sistem dela tisto, kar bi moral?
- Načrt sistema:
o vzpostavlja arhitekturo, ki ustreza zahtevam po strojni in programski
opremi.
- Načrt programa:
o predstavlja programske funkcionalnosti v takšni obliki, da se lahko
pretvorijo v enega ali več izvršljivih programov.
- Osnovni dokument je načrt sistema oz. tehnična specifikacija.

Izgradnja:
- To je faza pri kateri se programirajo moduli sistema.
- Osnovni cilj je narediti:
o berljivo,
o zanesljivo,
o za nadgradnje enostavno ter
o dobro dokumentirano programsko kodo.
- Poudarek ni na učinkovitosti, čeprav je tudi ta pomemben vidik programiranja.
- Rezultat te faze je program, ki se lahko izvaja (in ne prevaja, kakor menijo eni
razvijalci)

Testiranje:
- Testiranje pomeni izvajanje programa z namenom iskanja pomanjkljivosti v
PO.
- V novejših modelih razvoja se vse več prepleta s fazo izgradnje.
- Načrtovanje testnih aktivnosti začne s fazo specifikacije zahtev.
- Pravilo: vsako pomanjkljivost je bolj poceni odpraviti, če je najdemo čim
bolj zgodaj v razvojnem ciklu.

Namestitev in vzdrževanje:
- Po dobavi/namestitvi v produkcijsko okolje naročnika sledi faza vzdrževanja.
- Osnovni namen vzdrževanja je:
 odprava vseh pomanjkljivosti skritih napak (odkritih po dobavi).
 prilagajanje sistema spremenjenim zahtevam.
 izboljševanje sistema.
- Cilj te faze je zagotoviti nemoteno izvajanje programske opreme pri
uporabniku.
- Vzdrževanje programske opreme je potrebno zaradi odpravljanja napak po
končanem razvoju in zaradi spremenjenih zunanjih okoliščin, v katerih sistem
deluje.

Dodaten aktivnosti, ki so nujne za funkcioniranje življenjskega cikla:

- Upravljanje z namenom zaključevanja projektov v dogovorjenih obsegih (rok,
stroški, kakovost)

6|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

- Dokumentiranje z namenom upravljanja s kompleksnostjo programske opreme

(tehnična dokumentacija) in timskega dela (projektna dokumentacija)

7|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

10. Čemu je namenjena študija izvedljivosti?

Študija izvedljivosti je namenjena predhodni odločitvi o začetku projekta razvoja:

- kaj je obseg predlaganega projekta?
- ali je projekt tehnično izvedljiv?
- kakšne bodo koristi od projekta?
- kakšni so stroški, časovnica?

Odgovori na vprašanja:

1. ali je projekt tehnično izvedljiv

2. ali je projekt ekonomsko upravičen
3. ali je projekt operativno izvedljiv (zakoni, kultura, dogovori)
4. kakšne prednosti prinaša projekt
5. kakšen je obseg predlaganega projekta

Študija izvedljivosti pelje k odločitvi: gremo ali ne gremo v izvedbo projekta.

11. Kakšna je razlika med analizo in načrtovanjem?

Analiza in specifikacija zahtev:

- Ugotavljanje podrobnih naročnikovih potreb (kaj?).
- Osnovni cilj je opis problema, ki ga je potrebno rešiti in definiranje zahtev skladno
s podanim problemom in okoljem.
- Osnovni dokument te faze je specifikacija zahtev.
- V tej fazi dobimo odgovor na vprašanje: KAJ POTREBUJEMO oz. kaj na bi
grajeni programski sistem zagotavljal

Načrtovanje:
- Opisuje sistem iz vidika razvijalca (kako naj sistem dela tisto, kar bi moral?)
- Vzpostavlja arhitekturo, ki ustreza zahtevam po strojni in programski opremi.
- Osnovni dokument je načrt sistema oz. tehnična specifikacija.
- Predstavlja programske funkcionalnosti v takšni obliki, da se lahko pretvorijo v
enega ali več izvršljivih programov
- V tej fazi odgovorimo na vprašanje: KAKO NAREDITI oz. kako bomo zadovoljili
identificirane zahteve – obnašanje sistema

12. Zakaj se zahteve spreminjajo? (ni v ppt)

Zahteve definirajo funkcionalnosti sistema iz vidika naročnika: kaj naročnik potrebuje in

ne kaj je povedal, da potrebuje!

Zahteve se spreminjajo iz različnih razlogov:

- zahteve spremeni naročnik oziroma uporabnik,
- pojavi se nova tehnologija (strojna oprema, programska oprema),
- spremeni se okolje uporabnika
- lahko se spremeni zakonodaja,…

8|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

13. Zakaj programiranje predstavlja samo del celotnih

stroškov razvoja? (ni v ppt)

Programiranje predstavlja samo del celotnih stroškov, ker je potrebno tudi načrtovanje,
testiranje in ustrezna namestitev programske ter strojne opreme v produkcijsko okolje
naročnika. Nato sledi tudi faza vzdrževanja, kjer je znano, da so stroški celo večji kot v
fazi razvoja. Prav tako odpravljanje hib zahtev včasih zajema do 40% vseh stroškov na
projektu

V fazi razvoja programske rešitve predstavljajo stroške tudi samo načrtovanje, testiranje,
ustrezna namestitev programske in strojne opreme. V fazi vzdrževanja pa so stroški celo
večji kot v sami faza razvoja (vplivajo tehnični in ne-tehnični faktorji; se povečujejo z
obdobjem vzdrževanja, starost programske opreme (stari programski jeziki)). Večina
budžetov v velikih organizacijah je namenjena evoluciji obstoječe programske opreme in
ne razvoju nove.

14. S kakšnim namenom se izvaja vzdrževanje PO?

Osnovni namen vzdrževanja je:

- odprava vseh pomanjkljivosti skritih napak (odkritih po dobavi).
- prilagajanje sistema spremenjenim zahtevam.
- izboljševanje sistema.

Cilj te faze je zagotoviti nemoteno izvajanje programske opreme pri uporabniku.

Vzdrževanje programske opreme:

1. spremembe v programski opremi po namestitvi in začetku uporabe v
produkcijskem okolju
2. vzdrževanje po navadi ne vključujejo bistvene spremembe sistemske
arhitekture
3. spremembe s implementirajo skozi modifikacije obstoječih komponent sistema
ali dodajanjem novih

Spremembe programske opreme:

1. prihaja do novih zahtev – posledica uporabe sistema
2. spremembe v poslovnem okolju – okolju sistema
3. napake morajo biti odpravljene
4. dodajanje nove strojne in programske opreme v sistem
5. zmogljivost ali zanesljivost sistema se mora izboljšati

Sistemi se morajo vzdrževati, če želimo obdržati njihovo vredenost.

Ključni problem organizacije je implementacija in upravljanje s spremembami

sistema.

Tipi vzdrževanja:
1. odprava napak
 odpravljanje pomanjkljivosti v sistemu tako, da je skladen z zahtevami
2. prilagajanje različnim produkcijskim okoljem
 spremembe sistema, ki omogočajo delovanje v drugačnem okolju (SO, OS,
…) glede na začetno namestitev.
3. Dodajanje novih ali spreminjanje obstoječih funkcionalnosti:
 Spreminjanje sistema tako, da izpolnjuje nove zahteve

9|Stran
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Powerpoint: 03._pi_modeli_razvoja (predavanja)

15. Opiši model razvoja Code&Fix; prednosti in

pomanjkljivosti.

Je zares slaba in zares pogosta rešitev.

Prednosti: ni dodatnega dela, ni potrebno posebno znanje.

Pomanjkljivosti: ni mogoče oceniti proces, težko je koordinirati več razvijalcev.

Uporabno za razvoj enouporabniških programov: začni s prazno kodo in debugiraj, dokler
ne začne delati prav.

Težave:
1. Ni specifikacija
2. Ni načrta izvedbe
3. Ni določenih faz
4. Ni mejnikov
Neprimeren pristop:
1. Nemogoč nadzor na tekom projekta
2. Težavno zagotavljanje kvalitete
3. Visoka obremenjenost stranke, padec zaupanja v produkt

 Development
------- Maintenance

16. Opiši model slapa; prednosti in pomanjkljivosti.

Vsaka faza v zaporedju življenjskega cikla mora biti povsem zaključena, pred začetkom
naslednje.

Ob zaključku vsake faze kontrole glede na zastavljene cilje (roki, kakovost, obseg).

Prednosti:
1. merljivost napredka.
2. pridobljene izkušnje iz predhodnih projektov se lahko uporabijo za oceno napora
za podobnih korakov pri bodočih projektih.

10 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

3. izgradnja programskih modulov, ki se lahko ponovno uporabijo pri drugih

projektih.
4. enostaven za naročnika.
Slabosti:
Originalni model slapa (kako mnogi interpretirajo) ne omogoča iteracijo:
1. neprilagodljiv.
2. zahteve se v resnici spreminjajo s časom.
3. ne ustreza dejanskem razvoju PO.
4. vsiljuje strukturo projektnega vodenja – ni jasno kako izdelki iz ene faze prehajajo
v drugo.
5. razvoj ne vidi kot reševanje problemov.
6. vzdrževanje ni dobro podprto.

 faze si sledijo ena za drugo in se ne prekrivajo. Naslednja faza se začne po

zaključeni predhodni fazi.
 Vsaka faza se zaključi s pregledom oz. testiranjem.
 Možen le v primeru dobro določenih zahtev/ciljev in jasnega načina izvedbe, saj je
upoštevanje kasnejših sprememb težavno.
 Zahteva potrpljenje stranke – delujoča verzija ji je na voljo šele ob predaji
končnega produkta
 Prednosti:
1. Preglednost
2. Ločenost faz
3. Stalen nadzor nad kvaliteto
4. Dober nadzor nad stroški
 V praksi šele vsak naslednji korak omogoča širše/boljše razumevanje prejšnjih
faz, zato so pogosto nujne revizije predhodnih korakov- linearni model tega ne
omogoča.
 Linearni model s povratki:
1. Omogoča revizije predhodnih korakov
2. Možna je izvedba z delnim prekrivanjem faz

17. Zakaj je model slapa nerealen? (ni v ppt)

1. veliko tveganje, saj je težko zagotoviti, da je neka faza do potankosti izdelana

pred prehodom na naslednjo (iz tega razloga nekatere različice modela slapa
uvajajo določeno mero pokrivanja med fazami),
2. prve delujoče rešitve nastanejo dokaj pozno v življenjskem ciklu,
3. večina težav se odkrije šele med testiranjem,
4. zmogljivosti ne morejo biti preverjene pred zaključkom kodiranja,

11 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

5. problem konsistentnega vzdrževanja obsežne dokumentacije.

Model ni primeren za kompleksne projekte s pogosto spreminjajočimi se zahtevami, kot

tudi manjše projekte z napetimi časovnimi roki.

Model slapa je nerealen, ker se zahteve nenehno spreminjajo, model slapa pa se ob

zaključevanju vsake faze cikla na spremembe ne odziva primerno, zato prihaja do napak
in sam razvoj ne sledi reševanju problemov. Model je neprilagodljiv in posledično tudi
vzdrževanje ni dobro podprto.

Njegova glavna pomanjkljivost je, da ne odraža resničnega razvojnega procesa. Skoraj

nikoli namreč ne velja, da najprej popolnoma zaključimo eno fazo, nato drugo, tretjo,
itd., ampak po potrebi med fazami prehajamo (npr. iz načrtovanja in programiranja se
večkrat vrnemo v analizo, ipd.). Po zaporednem pristopu pa prehod v že izvedene faze ni
mogoč. Zaradi pogostih sprememb, ki so značilne za današnja poslovna okolja, to
predstavlja še posebej veliko oviro, saj se moramo pogosto vračati v fazo analize.

Druga pomanjkljivost, ki se večkrat (neupravičeno) očita zaporednemu modelu je, da

vodi do velikih in kompleksnih monolitskih sistemov, ki jih težko vzdržujemo.

Kljub omenjenim slabostim pa velja, da se je zaporedni model v preteklosti izkazal kot

učinkovit pristop k gradnji velikih in kritičnih sistemov, še posebej tistih, kjer so bile
zahteve poznane ali vsaj dobro definirane. Prvine zaporednega pristopa zato tudi danes
najdemo v različnih razvojnih modelih.

18. Kakšna je razlika med code&fix modelom in modelom

slapa? (ni v ppt)

CODE&FIX model je uporaben za razvoj enouporabniških programov: »začni s prazno

kodo in debugiraj, dokler ne začne delati prav«. Posluša naročnika in spremembe, ter
prvo verzijo spreminjajo dokler naročnik ni zadovoljen. Nato sledi implementacija in
ukinitev.

MODEL SLAPA pa zbere vse zahteve, naredi načrt in ko je ta faza zaključena, ni

prilagodljiv na spremembe, zato prihaja v fazi implementacije, namestitve in vzdrževanja
do napak.

MODEL SLAPA razvoj ne vidi kot reševanje problemov in vsiljuje strukturo vodenja,
medtem ko je CODE&FIX sicer enostavnejši a bolj prisluhne spremembam.

19. Opiši inkrementalni model, prednosti in pomanjkljivosti.

Inkrementalni ali postopni model je zelo popularen model razvoja IS, pri katerem
razdelimo celoten problem na podprobleme ali module, ki jih rešujemo posebej in
neodvisno od ostalih. Aplikacijo tako razvijamo po delih, ki zajemajo le določen del
funkcionalnosti želenega sistema, vendar so obenem dovolj samostojni, da jih lahko
vključimo v produkcijo. Z moduli sčasoma pokrijemo celotno funkcionalnost in zaključimo
razvoj. Razvoj posameznih modulov jemljemo kot samostojne podprojekte.

Primeren za:
1. projekte, kjer imamo opravka s slabo definiranimi in spreminjajočimi se
zahtevami,
2. spremembami v proračunu,

12 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

- hitro razvijajočo se tehnologijo.

Ni primeren za:
1. majhne in kratkotrajne projekte,
2. projekte, kjer obstajajo majhna integracijska in arhitekturna tveganja.

Prednosti:
1. hitrejša izdelava prvih izdelkov,
2. možnost izkoriščanja spoznanj in izkušenj pridobljenih v začetnih iteracijah
tekom razvoja kasnejših iteracij,
3. zgodnejše odkrivanje potencialnih arhitekturnih in integracijskih tveganj,
4. sprotno nadzorovanje in analizo sprememb,
5. ugotavljanje problemov in takojšnjo izvedbo potrebnih popravkov.

Slabosti modela – odvisne od implementacije:

1. pomanjkljiva obravnava sistema kot celote (tako s poslovnega kot informacijskega
vidika),
2. potreba po dobro določenih vmesnikih (nekateri moduli se dokončajo mnogo pred
drugimi),
3. nevarnost odlaganja problematičnih modulov na kasnejše iteracije, z namenom
poslovodstvu prikazati zgodnje uspehe projekta.

Inkrementalni ali postopni model je zelo popularen model razvoja IS, pri katerem
razdelimo celoten problem na podprobleme ali module, ki jih rešujemo posebej in
neodvisno od ostalih. Aplikacijo tako razvijamo po delih, ki zajemajo le določen del
funkcionalnosti želenega sistema, vendar so obenem dovolj samostojni, da jih lahko
vključimo v produkcijo. Z moduli sčasoma pokrijemo celotno funkcionalnost in zaključimo
razvoj. Razvoj posameznih modulov jemljemo kot samostojne podprojekte.

Delitev projekta na podprojekte je velikokrat izvedena na osnovi določitve

pomembnosti posameznih funkcionalnih zahtev, njihove uvrstitve v module ter določitve
vrstnega reda izvedbe posameznih modulov. Prav tako popularen pristop je delitev, kjer
en modul ustreza enemu funkcionalnemu področju (začnemo s strateškim
planiranjem, nadaljujemo pa z naslednjimi fazami za vsak modul posebej). Posamezne
module na koncu integriramo v celotno rešitev.

Inkrementalni model v sebi skriva kar nekaj dobrih lastnosti. Ena pomembnejših je ta, da
dele končnega produkta že relativno zgodaj predamo v uporabo, kar poveča možnost za
odkrivanje in odpravljanje morebitnih napak in pomanjkljivosti. Velja tudi, da je razvoj IS

13 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

po inkrementalnem modelu v splošnem cenejši in manj tvegan, kot razvoj aplikacije v

enem kosu.

Kljub mnogim prednostim pa inkrementalni model ni primeren za vse vrste projektov.

Npr. ni za pričakovati, da bi sistem za kontrolo zračnega prometa lahko v praksi deloval,
dokler ne bi bil v celoti dokončan.

20. Zakaj se uporabljajo iterativni modeli razvoja?

Danes je poznanih več iterativnih modelov. Njihova skupna značilnost je postopen

razvoj, kar pomeni, da za razliko od zaporednega pristopa ne končujemo faz v celoti,
ampak le delno, cel cikel pa ponavljamo, dokler aplikacija ni zaključena.

Glavna prednost iterativnih modelov je v tem, da upoštevajo naravo razvojnega

procesa, ki večkrat zahteva, da se vračamo v predhodne faze. Med najbolj poznane
iterativne modele se uvršča Spiralni model.

Uporabimo:
1. v projektih, kjer ima izogibanje tveganju visoko prioriteto,
2. če poraba virov ni problematična,
3. če ima izvedba prednost pred funkcionalnostmi (te se lahko dodajo naknadno),
4. če je vodja projekta visoko izkušen,
5. če je bistvena visoka stopnja natančnosti in obstaja zahteva po močnemu nadzoru
nad dokumentacijo ter sprejemanju odobritev.

S pojavitvijo iterativnih modelov so se prvič pojavili prototipi, ki so iterativnim modelom

prinesli dodatne prednosti. Prototipi se danes uporabljajo v več ali manj vseh razvojnih
modelih, na njihovi osnovi pa se je razvil tudi poseben prototipni razvojni model.

21. Opiši prototipni model; prednosti in pomanjkljivosti.

Prototip omogoča uporabnikom, da vizualizirajo aplikacijo, ki še ni narejena. Uporaba pri

specifikaciji zahtev:
- koristna pri hitro se spreminjajočih zahtevah.
- ko se naročnik ne zavezuje pri specifikacijah.

Enkrat, ko so zahteve znane, se uporabi model slapa. Ko se začne načrtovanje, se

prototip zavrže:
- prototipi ne bi smeli biti osnova za izgradnjo (avtomatično generiranje kode).
- naročnik mora biti poučen o naravi prototipa (prototip ni % končnega izdelka).
Prednosti:
1. sposobnost prepoznavanja uporabnikovih informacijskih potreb na podlagi
testnega sistema.
2. omogoča realni prikaz pomembnih vidikov sistema že v zgodnji fazi razvoja.
3. izboljšuje vključenost končnih uporabnikov v projekt in komunikacijo med vsemi
vpletenimi stranmi.
4. omogoča identifikacijo nejasnih in pogrešanih funkcionalnosti.
Slabosti:
1. manj strog nadzor nad posameznimi fazami projekta.
2. nevarnost izdelave nepopolne ali neustrezne problemske analize pred izdelavo
prve različice prototipa.
3. pogosto prihaja do večjih sprememb zahtev.
4. lahko vodi do slabo načrtovanih sistemov.

14 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Prototipi se danes uporabljajo v več ali manj vseh razvojnih modelih, na njihovi osnovi pa
se je razvil tudi poseben prototipni razvojni model.

Prototipni model temelji na izdelavi prototipov, s katerimi označujemo predhodno

izdelane in navadno nepopolne verzije sistema. Uporaba prototipov v veliki meri olajša
komuniciranje z uporabnikom, zato jih uporabljamo v različnih fazah razvoja. Za
izdelavo prototipov so bila razvita posebna razvojna okolja, ki omogočajo vizualno
sestavljanje zaslonskih mask, izpisov in poizvedb ter vsebujejo mehanizme za
avtomatsko generiranje kode.

Izdelava prototipov kot tehnika razvoja aplikacij temelji na tesnem sodelovanju med
uporabnikom in analitikom. Ko se uskladita glede zahtev sistema, analitik razvije
prototip in ga da uporabniku v testiranje oziroma v uporabo. Ta analitiku sporoči, kaj
mu je pri prototipu všeč in kaj ne. Povratna informacija služi analitiku za pripravo
nove verzije prototipa. Proces traja, dokler uporabnik ni s prototipom zadovoljen.

Prototipi se navadno uporabljajo le kot del specifikacije sistema, za pridobitev

jasnejše podobe bodočega sistema in se v nadaljevanju zavržejo. Vendar pa obstajajo
tudi metode, ki tako izdelane prototipe izkoristijo kot osnovo za izdelavo produkcijskega
sistema (Rapid Application Development – RAD).

22. Kaj je prototip? Zakaj jih uporabljamo?

Prototip je pred serijsko izdelan predmet. V prvi vrsti je izdelan za testiranje izdelka in
odpravljanje morebitnih pomanjkljivosti pred serijsko proizvodnjo.
Prototip omogoča uporabnikom, da vizualizirajo aplikacijo, ki še ni narejena. Uporabljamo
jih pri specificiranju zahtev:
1. koristna pri hitro se spreminjajočih zahtevah.
2. ko se naročnik ne zavezuje pri specifikacijah.
Ko se začne načrtovanje, se prototip zavrže:
1. prototipi ne bi smeli biti osnova za izgradnjo (avtomatično generiranje kode).
2. naročnik mora biti poučen o naravi prototipa (prototip ni % končnega izdelka).

15 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

23. Opiši spiralni model; prednosti in pomanjkljivosti.

Združene prednosti modela slapa in prototipnega modela + ocena tveganja.

Podoben inkrementalnem modelu vendar je vsaka ponovitev je planirana z ocenom
tveganja in/ali oceno naročnika:
1. določitev ciljev in trenutnega statusa.
2. identifikacija tveganja in prioritet.
3. naslednja ponovitev obravnava največje tveganje in/ali najvišje prioritete.
4. ponovitev (vsaka ponovitev je po modelu slapa).
Prednosti:
1. zmanjšuj tveganje.
2. omogoča izbor najprimernejšega modela za razvoj posamezne ponovitve glede na
oceno tveganja.
Slabosti:
1. tesna povezanost in prilagojenost na vsak posamezen projekt, kar povečuje
kompleksnost in omejuje ponovno uporabljivost modela,
2. nejasen prehod iz ene ponovitve v drugo.

24.
A
g
i
l
n
e

metode: naštej in obrazloži štiri ključne vrednote agilnih

pristopov.

Skupina udeležencev - agilna koalicija, definira štiri ključne vrednote agilnih pristopov:
1. Posamezniki in interakcije pred procesi in orodji.
2. Delujoča programska oprema pred obsežno dokumentacijo.
3. Sodelovanje z uporabniki pred pogodbenimi pogajanji.
4. Odziv na spremembe pred togim sledenjem planu.

Agilne metode razvoja programske opreme so skupina metod razvoja programske

opreme, ki temelji na podobnih načelih. Osnovni principi so: vodenje projektov temelji na
konstantnem prilagajanju in kontroliranju; filozofija vodenja, ki spodbuja timsko delo,
samoorganizacijo in odgovornost; niz najboljših inženirskih praks, ki omogoča hiter

16 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

razvoj kvalitetne programske opreme ter poslovni pristop, ki omogoča večjo integracijo

naročnikovih potreb in ciljev podjetja.

25. Kaj se lahko in kaj se ne sme spreminjati tekom

timebox-inga pri agilnem programiranju?

1. določanje datuma za dobavo ponovitve.

2. datum se ne sme spreminjati.
3. dovoljena je samo sprememba zahtev (obsega).
4. kratko trajanje ponovitev (tedni in ne meseci).

Pri agilnem razvoju, to je kar se dela v manjših časovnih kosih, takrat se ne sme
spreminjati časa (čas se fiksira). Zmanjšala se bo funkcionalnost, če se časa ne da
povečati. Zahteve se lahko spreminjajo – predvsem na zmanjševanju, čas je pa fiksiran,
se ne spreminja.

26. Opiši Scrum metodo razvoja.

Scrum je najbolj popularna agilna metoda za razvoj programske opreme. Gre za

iterativen in inkrementalen način dela, ki zagotavlja jasnost in preglednost vsem
sodelujočim na projektu.

Scrum je v bistvu ogrodje oz. pristop k razvoju programske opreme in ne prava

metodologija, ki natančno predpiše vse stvari. Scrum ne predpisuje, kako je potrebno
skrbeti za seznam zahtev, ampak samo pove, da mora obstajati prioritiziran seznam
zahtev, ki določa, kaj se bo delalo v vsakem ciklu (sprint-u).

Dnevni
cikel

Zapis izdelka Zapis teka

30 dnevni
sprint

Sestanek –
predstavitev po
izvedbi teka

Sestanek - Standardi, tehnike,

planiranje teka priporočila, razvojna
orodja, procesi
1. Metodologija Scrum je zasnovana na prepričanju, da ima večina metodologij za
razvoj informacijskih sistemov napačno filozofsko osnovo.
2. Razvoj programskih rešitev ni definiran temveč empiričen proces, ki ga ni možno
dosledno ponavljati in zato potrebuje sproten nadzor ter prilagajanje.

17 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

3. Scrum predpostavlja, da živimo v zapletenem svetu in da je zatorej nemogoče

napovedati ali natančno planirati končno obliko izdelka, časovni okvir, stroške in
kvaliteto.
4. Nadzorovanje kaotičnih (empiričnih) procesov in nadzorovanje predvidljivih
(definiranih procesov) zahteva različne tehnike.
5. Klasična praksa upravljanja projektov - projekti so predvidljivi in odkloni od plana
so v prvi vrsti posledica človeških napak, neznanja ali slabe motivacije.

Pred sprint: planiranje pred sprintom– izdelajo se 3 zapisi:

1. zapis izdelkov (opisujejo poslovne in tehnološke funkcionalnosti izdelka),
2. zapis izdaje (podmnožica zapisa izdelka – funkcionalnosti izdaje),
3. zapis sprinta (podmnožica zapisa izdaje) - identificira in definira delo, ki ga mora
razvojna skupina opraviti v okviru posameznega sprinta,
4. določitev cilja oziroma poslovnega namena sprinta.
30 dnevni sprint - pravila:
1. člani skupine si razdelijo naloge,
2. vsi delajo po svojih najboljših močeh za dosego cilja,
3. vsi sodelujejo na dnevnih sestankih,
4. prioritete, saj razen v izjemnih primerih, med posameznim sprintom ne smejo
spreminjati,
5. v okviru sprinta ne obstaja noben podroben in dovršen plan,
6. dnevni sestanki: povečujejo opaznost dela posameznega člana skupine,
poenostavljajo izmenjavo znanja, preprečujejo podvajanje aktivnosti in
zagotavljajo integracijo njihovega dela.
Po sprint – sestanek:
1. ocena napredka, uporabnikom se predstavijo nove ali dopolnjene funkcionalnosti,
revizija projekta s tehničnega vidika.

Powerpoint: 04._pi_projektno_vodenje (predavanja)

27. Katere tri komponente usklajujemo pri projektih PI?

(nisem prepričana, da je prav)

Pri PI usklajujemo naslednje tri komponente:

1. trajanje,
2. stroški,
3. kakovost

Pri razvoju PO je pomembno usklajevanje teh treh, pogosto nasprotujočih si, zahtev.
Uspešen projekt mora zadovoljiti vse tri komponente. Za to mora skrbeti vodja projekta.

28. Kaj je projekt?

Nekaj definicij projekta:

- Časovno določen napor, da se izdela edinstven izdelek, storitev ali rezultat.
- Niz aktivnosti in nalog, ki imajo določeni cilj, ki mora izpolniti določene
specifikacije, imajo določen začetek in konec, omejena finančna sredstva, trošijo
vire ter so več funkcionalne.
- Množica različnih aktivnosti opravljenih v logičnem zaporedju zaradi doseganja
določenega rezultat. Vsaka aktivnost in tako celotni projekt imajo definiran
začetek in konec.
- Začasna stvaritev z vnaprej določenim začetkom in koncem, dosegom in viri.

18 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

29. Kaj predstavljajo interesne skupine (stakeholders)?

Kakšno tveganje lahko predstavljajo za projekt?

Interesne skupine (ang. stakeholders) so osebe ali organizacije, ki so aktivno vključene

v projekt ali na čigave interese lahko projekt pozitivno ali negativno vpliva.

Lahko vplivajo na projekt in na rezultate projekta (npr. naročniki, sponzorji, drugi

izvajalci, javnost, ...).

30. Kaj vsebuje načrt projekta?

Načrtovanje projektov (ang. Project Planing) vključuje:

1. določanje nalog, ki jih je potrebno opraviti, njihovih medsebojnih odvisnosti in
zaporedja izvajanja.
2. določanje zaporedja izvajanja nalog in potrebnih virov.
3. predvidevanje trajanja projekta.
4. predvidevanje stroškov na podlagi ocene velikosti in/ali kompleksnosti.
5. mehanizme sledenja in kontrole kakovosti.

31. Opiši WBS tehniko. Zakaj se uporablja?

Struktura razdelitve nalog (ang. Work Breakdown Structure - WBS):

1. tehnika za razdelitev posla na manjše naloge.
2. vključuje definicijo izdelkov (ang. deliverables) in ključnih datumov (ang.
milestones).
WBS drevo (ang. tree):
1. naloge so urejene po nivojih.
2. najvišji nivoji so običajno naloge, ki so skupne vsem projektom (npr.
specifikacija zahtev, načrtovanje, verifikacija).
3. naloge višjih nivojev se vejijo na več nalog na nižjem nivoju.
4. najnižji nivoji – listi drevesa - so naloge, ki jih je dejansko potrebno narediti.

Razširjena objektno zasnovana metoda za definiranje potrebnega dela je metoda WBS

(Work Breakdown Structure).Cilji projekta v obliki konkretnih izdelkov ali storitev so
postavljeni na vrh drevesnega diagrama. Vsak segment nato postopoma delimo na ožje
podcilje toliko časa, dokler ne pridemo do skupin opravil, ki tvorijo naravno (funkcijsko)
zaključene delovne celote. Za vsako od teh naravnih delovnih celot nato definiramo
potrebno aktivnost. Za označevanje segmentov v drevesni strukturi ponavadi
uporabljamo hierarhičen način označevanja oziroma številčenja. Po drevesni strukturi
lahko zlahka seštevamo zmogljivosti za segmente na različnih nivojih hierarhije.

32. Kaj je SRS dokument?

SRS dokument predstavlja osnovni dogovor med uporabnikom in izvajalcem:

1. Potrebno je zadovoljiti uporabnikove potrebe, vendar ni nujno, da uporabnik
razume tehnologijo
2. Razvijalci lahko razvijejo sistem vendar ni nujno, da poznajo problemsko
področje.

SRS je medij, ki omogoča premostitev vrzeli med uporabnikom in izvajalcem na način,

ki ga razumeta oba.

19 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Faza analize in specificiranja zahtev se zaključi z dokumentom »specifikacija zahtev«

(ang. Software Requirements Specification - SRS). SRS dokument specificira, kaj bodoči
sistem mora delati.

Kaj je SRS?
1. SRS dokument predstavlja osnovni dogovor med uporabnikom in izvajalcem.
2. SRS je medij, ki omogoča premostitev vrzeli med uporabnikom in izvajalcem na
način, ki ga razumeta oba.
3. SRS pomaga uporabnikom razumeti njihove potrebe.
4. SRS predstavlja referenco za validacijo končnega izdelka.
5. Kakovostni SRS je bistven za kakovostno PO.

SRS dokument po navadi vsebuje:

1. Funkcionalne zahteve – opisujejo interakcijo med sistemom in okolico

2. Ne-funkcionalne zahteve – lastnosti sistema, ki se ne morejo izraziti kot
funkcije
3. Omejitve sistema – stvari, ki jih sistem ne sme delati oz. na katere se ne more
vplivati

33. Naštej prednosti uporabe prototipov pri ustvarjanju SRS.

(ni v ppt?)

Prototip se uporablja takrat, ko zahteve niso jasne ali ko je potreben zgodnji feedback
interesnih skupin.

Prototip:
1. se izdela hitro na podlagi osnovnih zahtev,
2. se analizira zaradi natančnejšega določanja zahtev,
3. iz teh zahtev se razvije novi prototip,
4. proces se nadaljuje dokler zahteve niso zadosti jasno definirane.

34. Opiši osnovno delitev zahtev.

Powerpoint: 98_pi_specificiranje_zahtev (vaje) (samo to vprašanje)

Zahteve lahko klasificiramo na različne načine. Pogosta je delitev na:
1. funkcijske zahteve – opisujejo interakcijo med sistemom in okolico. (kaj
izdelek/sistem dela (prenos naročil…), merimo z Da/Ne)
2. ne-funkcijske zahteve - lastnosti sistema, ki se ne morejo izraziti kot funkcije
(kakovost(i), zmogljivost(i), kako hitro deluje, koliko uporabnikov lahko naenkrat
dela, na katerem OS deluje…), omejitve, merimo jih z kvantitativno)

35. Naštej in opiši nekaj lastnosti zahtev.

1. Realističnost – ali so zahteve tehnično, finančno, časovno ali operativno

izvedljive.
2. Pravilnost – vsaka zahteva predstavlja neko željeno lastnost končnega sistema.
3. Popolnost – vse željene lastnosti sistema so specificirane (najtežje). Pravilnost in
popolnost sta ozko povezani.
4. Preverljivost – ali se lahko preveri ali je zahteva implementirana pravilno ali ne?
5. Sledljivost – možnost sledenja spremembam zahteve skozi SDLC.
6. Nedvoumnost – vsaka zahteva ima natančno en pomen – pogost vzrok za
napake. Pomembna lastnost, ker se pogosto uporablja naravni jezik.

20 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

7. Preverljivost – mora obstajati učinkovit način preverjanja ali je zahteva

implementirana pravilno ali ne.
8. Konsistentnost – dve različni zahtevi se ne smeta nasprotovati.
9. Urejenost po pomembnosti – potreba po postavljanju prioritet.
10. Stabilnost – zmanjševanje tveganja pri spremembi zahtev.

36. Naštej in opiši nekaj najbolj pogostih napak v

specifikacijah.

1. ne-strukturirane specifikacije: specifikacije napisane v obliki prostega spisa:

težko spreminjanje, niso natančne, običajno dvoumne, protislovne, ...
2. hrup: del besedila, ki ne vsebuje informacije relevantne za problem.
3. pomanjkanje: pomembni vidiki zahtev manjkajo.
4. preveč specificiranja: specificiranje rešitve problema – to je potrebno prepustiti
fazi oblikovanja (design).
5. nasprotja: lahko nastopajo, če se ista zadeva pojavlja večkrat na različne načine.
6. dvoumnosti: nekvantificirane zahteve.
7. referenciranje naprej: sklicevanje na del specifikacij, ki šele sledi.
8. pobožne želje: opis zadev, ki so realno zelo težko izvedljive.

37. Naštej in opiši pomanjkljivosti uporabe naravnega jezika

pri specifikaciji zahtev.

Pomanjkljivosti govornega jezika:

1. nejasen - težko je doseči jasnost in ob tem berljivost.
2. zmeda v zahtevah - funkcionalne in ne-funkcionalne zahteve so pomešane.
3. združenost zahtev – več različnih zahtev je združeno.
4. dvoumnost – bralci in pisci zahtev morajo razumeti specifikacije na isti način.
Naravni jezik je dvoumen, zaradi česa je predhodno težko doseči.
5. pomanjkanje modularnosti – strukture naravnega jezika so pomanjkljive v
izražanju strukture sistemskih zahtev.

38. Kaj je primer uporabe. Od česa je sestavljen.

Powerpoint: 97_pi_use_cases (vaje) (samo to vprašanje)

Primeri uporabe (ang. Use Case) predstavlja neko funkcionalnost sistema oz. opisuje
sistem iz vidika uporabe sistema zunanjega uporabnika (kako zunanji uporabnik
uporablja sistem). Le a funkcionalne zahteve se uporablja use case.

Npr.: primeri uporabe spletne banke:

- plačilo položnice
- prenos denarja iz računa na račun
- pregled stanja računa
- ...

Primer uporabe je lahko v:

1. Opisni obliki
2. Obliki scenarija
3. Opisa dialoga
4. Grafična predstavitev – use case diagram – prikazuje funkcionalnost sistema v
smislu akterjev in njihovih ciljev pri uporabi sistema, hkrati pa tudi povezanost
primerov uporabe. Je grafična predstavitev uporabnikov, sistema in primerov
uporabe.

21 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

39. Kaj je diagram primerov uporabe? Kakšni so osnovni

gradniki diagrama?

Powerpoint: 97_pi_use_cases (vaje) (samo to vprašanje)

Diagram primerov uporabe je grafična predstavitev uporabnikov, sistema in primerov
uporabe. (poleg opisnega dela omogočajo grafično predstavitev, ki še bolj posploši
pogled v samo delovanje sistema in interakcije uporabnika s sistemom)

Osnovni gradniki diagramov primera uporabe so:

1. Uporabnik, agent, akter – tisti, ki uporablja sistem (primarni akter –
stimulira sistem, da reagira (ponuja); sekundarni akter – odgovarja na
zahteve sistema (sprejema) – vsaka vloga je potencialni aker
2. Sistem
3. Primer uporabe
4. Povezave med primeru uporabe – osnovna povezava, include (uporablja
se, ko želimo izvesti: dekompozicijo zapletenega obnašanja sistema,
centralizacija splošnega obnašanja sistema; pomeni, da osnovni primer
uporabe obveznost vključuje drugi primer uporab), exclude (pomeni, da
osnovno obnašanje primera uporabe lahko razširimo z drugim primerov
uporabe; smer je iz drugega v osnovni: osnovni primer uporabe ne ve, s
katerim primerom je razširjen)

40. Opiši osnovne komponente zapisa primera uporabe.

Podaj primer.

1. Primer uporabe: Ažuriraj polico (naziv)

2. ID: PU2 (ID)
3. Agent: Zavarovalniški uradnik (ZU)
4. Predpogoj: Polica že obstaja (kaj mora obstajati, da se aktivnost izvede)
5. Sprožilec: Stranka želi spremeniti upravičenca (katera aktivnost sproži uporabo)
6. Tok dogodkov: (ko je vse v redu, če ni težav, kako se bo izpeljal primer uporabe;
glavni tok je eden, alternativnih je lahko več))
- ZU (zavarovalniški uradnik) odpre obstoječo polico
- ZU vpiše novo vrednost atributa
- Sistem vpraša za potrditev spremembe
- IF ZU potrdi spremembo THEN
- Sistem shrani novo vrednost
- ELSE sistem ne shrani nove vrednosti

22 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

7. Rezultat: Atribut police je ažurirana

8. Alternativni tok: (kaj narediti, če kakšna stvar ni šla v redu v toku podatkov)
1. zavarovalniška storitev (vrsta police) je zastarela:
- ZU preveri ali stranka želi spremeniti zavarovalniško storitev.
- IF da, potem pojdi na primer uporabe ZAMENJAJ zavarovalniško storitev.

Powerpoint: 06._pi_oblikovanje (predavanja)

41. Kaj je programska arhitektura?

Programska arhitektura – množica odločitev na višjem nivoju (abstrakcije).

1. opravljajo se zgodaj v razvojnem ciklu in vplivajo na nadaljnje korake
oblikovanja.
2. NI določen izdelek ali faza življenjskega cikla.

Razdelitev sistema na osnovne komponente in definiranje njihovega medsebojnega

delovanja.

Osnovni namen programske arhitekture:

1. Sredstvo komunikacije med vsemi vključenimi v razvoj programskega izdelka.
Povečuje razumljivost.
2. Odločitve zgodnje faze oblikovanja na podlagi predvidevanja načina
implementacije kakovosti in možnosti doseganja zahtev, globalne strukture
sistema, ki določa razdelitev nalog na projektu. Opis implementacije
programske rešitve.
3. Predpogoj za ponovno uporabo programskega izdelka. Potrebno je omogočiti
enostavno evolucijo, analizo in upravljanje. Arhitektura programskega
izdelka ima koncept produktne linije – večnamenske izkoriščenosti.

Arhitektura je pogojena z:
1. zahtevami,
2. razvojno organizacijo,
3. tehničnim in organizacijskim okoljem.
Medsebojno delovanje arhitekture in okolja je ciklični proces.
Arhitektura sistema je sestavljena iz:
1. Komponent, ki vsebujejo algoritme za obdelavo podatkov.
2. Povezavah, ki omogočajo komunikacijo.
3. Topologijo s katero se opisuje kako so komponente in povezave organizirane.
4. Omejitve s katerimi so določena pravila pravilnega funkcioniranja zgoraj
navedenih elementov.

Faze oblikovanja:
1. Načrt arhitekture sistema je določanje podsistemov medsebojnih povezav in
njihove vloge pri izvrševanju zahtevanih funkcionalnosti sistema, fokus je na
zmogljivosti sistema.
2. Oblikovanje podsistemov – definicija abstrakne specifikacije za vsak podsistem.
3. Oblikovanje vmesnikov – definiranje vmesnika za vsak podsistem.
4. Oblikovanje komponent – dekompozicija podsistema na manjše enote –
komponente.
5. Oblikovanje podatkovne strukture.
6. Oblikovanje algoritmov.

23 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

42. Kaj pomenita kohezija in uparjenost pri razdelitvi

sistema na module?

Osnovne lastnosti po katerih primerjamo razdelitev na module:

1. kohezija (ang. cohesion) – mera s katero se definira koliko so deli komponent
med seboj povezani (npr. programi/moduli so kohezivni, če so vsi ukazi povezani
z vsemi izhodi, razredi so kohezivni, če vse lastnosti uporabljajo vse metode).
Zaželjeno je imeti čim večjo kohezijo.

2. uparjenost (ang. coupling) – mera medsebojne povezanosti modulov. Visok nivo

uparjenosti predstavlja veliko odvisnost med moduli – spremembe v enem
modulu, povzročijo spremembe v drugem modulu. Dobro je imeti slabo uparjenost
(ang. loose coupling).

Cilj je večja kohezivnost in manjša uparjenost.

Kohezija – notranja lastnost programskih modulov, pri načrtovanju (moduli morajo biti
čim manjši)

1. Na kakšen način so vhodi povezani z izhodi, čim bolj so povezani imamo večjo
kohezijo
2. Imamo 4 vhode in vsi vplivajo na en izhod – tu je kohezija velka
3. Imamo 4 vhode in dva vplivata na en izhovd dva pa na drugi izhod – tu kohezija
ni tako velika – lahko bi se razdelino na dva dela
4. Hočemo čim več kohezivnih modulov

Uparjenost

1. Imamo več različnih modulov, kako bodo vplivali drug na drugega, morajo čim
manj vplivati eden na drugega
2. Če spremenimo enega, kateri ostali moduli bodo zahtevali spremembe – tisti, ki
so med seboj uparjeni – visoka uparjenost – tega ne želimo, želimo, da so moduli
med seboj čim manj soodvisni – čim manjšo uparjenost
3. To sos tvari, ki so stvar načrtovanja, kjer načrtujemo programske module,
določimo vhode in izhode in lahko vplivamo na kohezijo in uparjenost

Powerpoint: 07._pi_verifikacija_in_validacija (predavanja)

43. Definiraj napako/hibo in pomanjkljivost/odpoved. Podaj

primer.

Napaka, hiba, hrošč (ang. error, fault, bug, defect) je napačno vneseni podatek, korak,
proces ali inštrukcija v izvirni kodi ali pripadajočem dokumentu, ki jo je povzročila
človeška nepazljivost. Je vzrok za pomanjkljivost oz. odpoved.

Pomanjkljivost , odpoved (ang. failure) programske opreme je manifestacija napake

pri izvajanju programske opreme.

- s testiranjem PO najdemo pomanjkljivosti, ki so povzročene z napakami.

- ena pomanjkljivost je lahko povzročena z večimi napakami in ena napaka lahko
povzroči več pomanjkljivosti.

24 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

44. Kaj je testiranje programske opreme?

1. Testiranje je proces izvajanja komponent ali celotnega programa pri

določenih pogojih ter opazovanje rezultatov.
2. Proces analize posameznih delov programske opreme z namenom ugotavljanje
razlik med zahtevami in dejanskim obnašanjem PO.
3. Testiranje je aktivnost ocenjevanja in izboljšanja kakovosti programske
opreme z ugotavljanjem pomanjkljivosti in napak.

45. Kakšna je razlika med verifikacijo in validacijo?

Proces verifikacije (ang. verification) je proces preverjanja ali PO in dokumentacija

ustreza zahtevami:
- ali izdelek gradimo pravilno (ang. are we building the product right?)

Proces validacije (ang. validation) je proces preverjanja ali PO in dokumentacija

ustreza pričakovanjem/potrebam uporabnika:
- ali gradimo pravi izdelek (ang. are we building the right product?)

46. Kaj je pregled (inspection/walktrough)?

Pregledi/inšpekcije:
- formalni timski pristop preverjanja dokumentov.
- možna uporaba kontrolnih list (ang. check-lists).
- možna uporaba scenarijev/vlog.
- walkthrough – skupina tekom sestanka gre po izvorni kodi, vsak član igra vlogo
določene dele kode.
- lahko se uporabijo v vseh fazah življenjskega cikla.
Potek pregleda:
- sestanek;
- tipično 3-5 oseb
- zahteva največ do 2 uri vnaprejšnje priprave.
- Traja manj kot 2 uri
Poročilo:
- kaj je bilo pregledano;
- kdo je pregledoval;
- kakšne so najdbe.
Sklep pregleda je lahko:
- izdelek se lahko potrdi brez dopolnitev;
- delno sprejet – potrebne določene dopolnitve brez dodatnega pregleda;
- zavrnjen – potrebne dopolnitve z dodatnim pregledom.

47. Kaj je kakovost programske opreme?

Kakovost programske opreme je skladnost z:

- dokumentiranimi funkcionalnimi in performančnimi zahtevami,
- dokumentiranimi razvojnimi standardi,
- posrednimi lastnostmi, ki jih pričakujemo v vseh profesionalno razvitih
programskih izdelkih.

Da program mora delati za tisto, za kar je bil načrtovan. Kakovost programa kako deluje.

25 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

48. Naštej in opiši nekaj atributov kakovosti programske

opreme.

1. Pravilnost – ali se obnaša skladno z zahtevami (absolutni).

2. Zanesljivost – verjetnost, da se bo sistem v določenem časovnem obdobju
obnašal skladno z zahtevami.
3. Robustnost – ali se obnaša pravilno tudi v okoliščinah, ki niso prvotno
predvidene?
4. Učinkovitost – kakšna je izraba virov?
5. Uporabnost - stopnja do katere je sistem uporaben in enostaven za uporabo.
6. Vzdržljivost – kako enostavno je spreminjati sistem po začetnem zagonu?
7. Popravljivost – koliko dela je potrebno za odpravljanje napak?
8. Prilagodljivost – koliko dela je potrebno za prilagodljivost zahtevam po
spremembah (sistema in procesa)
9. Prenosljivost – koliko dela je potrebno za prenos v novo okolje oz. platformo?
10. Preverljivost – ali je enostavno preveriti v kakšni meri so posamezni atributi
veljavni?
11. Razumljivost – ali je lahko razumeti sistem?

Powerpoint: 08._pi_metrike (predavanja)

49. Opiši postopek ocenjevanja napora s pomočjo

funkcijskih točk (FP).

1. Meritev produktivnosti, empirično preizkušena.

2. Motivacija: definirati in meriti količino proizvedene vrednosti/funkcionalnosti v
količini časa.
3. Princip: določiti kompleksnost aplikacije skozi
funkcijske točke.
Postopek je tak, da je
- V specifikacijah prešteti funkcije:
 število vhodov
 število izhodov
 število datotek
 število poizvedb
 število vmesnikov
- Te se obtežijo glede na kompleksnost
- Poleg teh posamično obteženih funkcijskih točk, so še
drugi faktorji, ki vplivajo na projekt kot celoto (cca 35) – kazalniki
kompleksnosti. Vsaki se oceni od 0 (nima vpliva) do 5 (bistven):
 ali je hitrost kritična?
 ali je interno procesiranje kompleksno?
 ali se sistem uporablja na enem ali
večih strežnikih?
 ali je načrtovano, da bo koda ponovno
uporabljena?
 ali bo procesiranje distribuirano?
 ...

26 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

1. Motivacija: definirati in meriti količino proizvedene vrednosti/funkcionalnosti v

količini časa.
 ne glede na modele, je odvisno od naših ocen. Imamo različne programske
jezike, kako bi šteli funkcionalnost programa i- s funkcijskimi točkami
poskušamo oceniti funkcionalnost programa. Funkcijske točke lahko tudi
pretvorimo v vrstice kode, če imamo pretvornik za posamezne programske
jezike.
2. Princip: določiti kompleksnost (velikost) aplikacije skozi funkcijske točke.
3. Meritev produktivnosti, empirično preizkušena.

50. Napiši in pojasni osnovno formulo za oceno napora.

Ekspertno ocenjevanje, ko damo nekim posameznikom, da rečejo koliko časa bo

trajalo, dobro le če so izkušeni ocenjevalci, temelji na predhodnih izkušnjah, koliko časa
so projekti trajali, še malo obrazložijo to oceno

Ocenjevanje na podlagi podobnosti projektov, razbijemo na niz funkcionalnosti in

ocenimo na podlagi podobnih projektov koliko časa bo trajala določene funkcionalnost

51. Pojasni Rayleighovo krivuljo.

52. Pojasni Putnamovo krivuljo.

Odvisnost Potrebno je upoštevati nelinearnost:

- V določenem območju ni mogoče narediti projekt ne glede na vire.
- V določenem območju sicer pohitrimo razvoj vendar ne sorazmerno vložkom.

27 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

- V določenem področju je dodajanje virov sorazmerno pohitritvi projekta.

Odvisno od atributov projekta.

53. Opiši GQM metodo za določanje metrik. Podaj primer.

GQM (ang. Goal-Question-Metrics) metoda omogoča določanje metrike skladno z nekim

poslovnim ciljem.
Postopek:
- najprej določimo cilje (G)
- glede na cilje zastavimo vprašanja (Q) na katera moramo odgovoriti če želimo
vedeti ali smo cilje dosegli
- za vsako vprašanje izberemo ustrezne metrike (M) s katerimi ugotavljamo
kakšno je trenutno stanje – odgovor na zastavljeno vprašanje.

C1. Maksimiranje
V1. koliko naročnikov
naročnikovega M1. število hib glede na resnost
ima težave
zadovoljstva

C2. Minimiziranje V1. kje je največ M1. človek/mesec po

napora ponovnega dela izdelku/komponenti/fazi

V2. kakšen je celotni M1. človek/mesec po

 
cikel vzdrževanja izdelku/komponenti/fazi

V3. kakšna je
  M1. število hib v produkciji
vzdrževalnost izdelka

    M2. gostota hib

    M3. stabilnost kode

M4. število modulov, ki ijh je

    potrebno popraviti, da bi se
odpravila ena hiba

Powerpoint: 09._pi_vzdrzevanje_po (predavanja)

28 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

54. Naštej in opiši tipe/vrste vzdrževanja.

Odprava napak:
- odpravljanje pomanjkljivosti v sistemu tako, da je skladen z zahtevami.
Prilagajanje različnim produkcijskim okoljem:
- spremembe sistema, ki omogočajo delovanje v drugačnem okolju (SO, OS, ...),
glede na začetno namestitev.
Dodajanje novih ali spreminjanje obstoječih funkcionalnosti:
- spreminjanje sistema tako, da izpolnjuje nove zahteve.

Fault repair
(17%)

Functionality
Software addition or
adaptation modification
(18%) (65%)

55. Kaj je

reinženiring sistema?

Reinženiring sistema je sprememba strukture ali ponovno pisanje določenega dela

starega sistema brez sprememb funkcionalnosti. Uporabno v primerih, ko se samo
nekateri moduli sistema pogosto spreminjajo oz. zahtevajo vzdrževanje. Reinženiring
vsebuje dodatni napor v smeri lažjega vzdrževanja modulov. Potrebno je izdelati tudi
novo dokumentacijo.
Prednosti:
- zmanjšanje tveganja – novi razvoj predstavlja visoko tveganje (nove tehnologije,
razvojni timi, ...).
- zmanjšanje stroškov – reinženiring obstoječe je bistveno cenejši od razvoja nove
programske opreme.

29 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

56. Primeri izpitnih nalog PRI

1. Naloga: Diagram primerov uporabe za igro 'Space invaders'.

- določite akterje,
- opišite osnovne primere uporabe (cilji akterjev) ,
- narišite diagram primerov uporabe.

Akter:

- samo igralec

Opiši osnovne primere uporabe: PRIMERI UPORABE

- klik levo
- klik desno
- klik strelja

STRELJA, SLEDIMO IZSTRELKU, LAHKO ZADENE OVIRO, VESOLJCE ALI NIČ

SISTEM GENERIRA IN PREMIKA VESOLJCE
Klik levo: če kliknemo levo se bo premaknil v levo
Klik desno: če kliknemo desno se bo premaknil v desno
Klik strelja:
ID: NPR. 1
NAZIV: KLIK LEVO
AKTER: IGRALEC
PREDPOGOJ: NAČELOMA GA NI
SPROŽILEC: ŽELIMO ZADETI VESOLJCA NA LEVI STRANI
TOK DOGODKOV: KLIKNEMO LEVO, SE PREMNEMO V LEVO
REZULTAT: SMO SE PREMAKNILI LEVO
ALTERNATIVNI TOK: GA NI
OPIS: PODAMO KORAKE, KAJ SE ZGODI, KO ZAŽENEMO AKTIVNOST
1. Primer uporabe: Ažuriraj polico (naziv)
2. ID: PU2 (ID)

30 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

3. Agent: Zavarovalniški uradnik (ZU)

4. Predpogoj: Polica že obstaja (kaj mora obstajati, da se aktivnost izvede)
5. Sprožilec: Stranka želi spremeniti upravičenca (katera aktivnost sproži uporabo)
6. Tok dogodkov: (ko je vse v redu, če ni težav, kako se bo izpeljal primer uporabe;
glavni tok je eden, alternativnih je lahko več))
- ZU (zavarovalniški uradnik) odpre obstoječo polico
- ZU vpiše novo vrednost atributa
- Sistem vpraša za potrditev spremembe
- IF ZU potrdi spremembo THEN
- Sistem shrani novo vrednost
- ELSE sistem ne shrani nove vrednosti
7. Rezultat: Atribut police je ažurirana
8. Alternativni tok: (kaj narediti, če kakšna stvar ni šla v redu v toku podatkov)
2. zavarovalniška storitev (vrsta police) je zastarela:
- ZU preveri ali stranka želi spremeniti zavarovalniško storitev.
- IF da, potem pojdi na primer uporabe ZAMENJAJ zavarovalniško storitev.

2. Naloga: Diagram primerov uporabe za avtomat za kino

vstopnice
Marjan je upravitelj kina in želi narediti avtomat za vstopnice. Vi ste sistemski analitik, ki
mora opisati, kaj naročnik želi v obliki množice primerov uporabe. Predpostavke:
- prikazuje se samo en film hkrati.
- čas predstav je vedno enak vsak dan. Vstopnice imajo vedno isto ceno.
- samo upravitelj lahko spreminja/dodaja filme ter določa ostale podatke, ki so
potrebni za nakup vstopnic.
- obiskovalci lahko samo kupujejo vstopnice.
Določite akterje, opišite osnovne primere uporabe (cilji akterjev) in narišite diagram. Pri
opisu primerov uporabe uporabite obliko scenarija.

Marjan je upravitelj kina in želi narediti avtomat za vstopnice. Vi ste sistemski analitik, ki
mora opisati, kaj naročnik želi v obliki množice primerov uporabe. Predpostavke:

 prikazuje se samo en film hkrati. To je odvečen podatek

 čas predstav je vedno enak vsak dan to je odvečen podatek Vstopnice imajo
vedno isto ceno.ne gre za nobeno računanje
 samo upravitelj lahko spreminja/dodaja filme ter določa ostale podatke, ki so
potrebni za nakup vstopnic.
 obiskovalci lahko samo kupujejo vstopnice.

Določite akterje, opišite osnovne primere uporabe (cilji akterjev) in narišite diagram. Pri
opisu primerov uporabe uporabite obliko scenarija potek dogodkov, ki opisujejo primer
uporabe.
IMAMO DVA AKTERJA
Gledalec
Administrator(upravitelj)
PRIMERI UPORABE ADMINISTRATORJA:
Lahko dodaja filme
Določa cene vstopnice
Določa spored

31 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

PRIMERI UPORABE GLEDALCA:

Nakup vstopnice

3. Naloga: Naštejte vsaj n funkcionalnih zahteve za ...

Kar mora sistem znati narediti – npr. omogoči nakup vstopnic

4. Naloga: Naštejte vsaj n ne-funkcionalnih zahtev za ...

Njegovi kakovostni atributi, uporabnost, hitrost, barva, lastnost – npr. deluje

na elektriko 220V, narejeno iz kovinskega ohišja, ne sme biti težji od 90 kg

5. Naloga: Testiranje modula za izračun BMI

Modul, ki ima dva vhoda: težo osebe v kg in višino osebe v cm, računa BMI (ang. Body
Mass Index) na podlagi formule:
BMI = (teža)/(višina)2 [kg/m2]

Naj podlagi BMI naj program izpiše ali ima oseba telesno težo:
- premajhno (BMI pod 18.5),
- normalno (BMI med 18.5 in 25),
- prekomerno (BMI med 25 in 30),
- preveliko (BMI več kot 30).
Ustvarite ustrezne testne primere s katerimi boste preverili pravilno delovanje modula.

Izberem takšno težo in višino, da je rezultat formule tak in tak

Vsaj 4 testne primere, da preverimo če sistem deuje in kakšne mejne vrednosti

Primer tabele testiranja: (parkirišče)

ID
Opis/Potek Pričakovani
testnega
Vhodni podatki rezultati
primera
1 Vpiši A = 9, Vpiši v B = 9, pritisni Izračunaj V polju A+B = 18
A+B
2 Vpiši A = 9, pritisni Izračunaj A+B Javi napako, da ni
bila vnešena
vrednost v polje B
3 Vpiši B = 9, pritisni Izračunaj A+B Javi napako, da ni
bila vnešena
vrednost v polje A
4 Vpiši A = -9, Vpiši v B = -9, pritisni Izračunaj V polju A+B = -18
A+B
5 Vpiši A = -9, Vpiši v B = 9, pritisni Izračunaj V polju A+B = 0
A+B

6. Naloga: Testiranje modula za prestopno leto

Podan je modul, ki na vhodu dobi podatek o letu in izpiše, ali predstavlja vhodni podatek
predstavlja prestopno leto ali ne.
Pogoji za prestopno leto so naslednji:
Leto je prestopno, če je deljivo s 4, razen;
- v primeru, da je leto deljivo s 100, leto ni prestopno.
- v primeru, da je leto deljivo s 400 leto je prestopno.
Ustvarite ustrezne testne primere s katerimi boste preverili pravilno delovanje modula.

32 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

7. Naloga: Testiranje programskega modula

Indiana Jones najde v starem templju tri zlate kipce, ker pa ima samo dve roki, mora
enega pustiti tam. Napisan je program, ki bo prebral vrednosti vsakega od kipcev in
izpisal, katera dva kipca se najbolj splača vzeti s sabo.
Ustvarite ustrezne testne primere s katerimi boste preverili pravilno delovanje programa.

Tri kipce z vrednostjo – dve roki

Atribut je sorazmeren vrednosti tega kipca
Tri vrednosti na vhodu in na izgodu moramo dobiti dve največji vrednosti
Program od treh možnosti izbere dva največja, dve spremenjlivki in neznanki
Vsaj tri možnosti potrebno stestirati, če program deluje:
Prvi dve vrednosti največji
Prvega in tretjena največjega
Druga dva največja
Kakšne enake vrednosti, da vidimo kaj bo naredil

8. Naloga: Določanje arhitekture sistema za ...

- spletno knjižnico;
- aplikacijo, ki omogoča zajem in prikaz podatkov o temperaturi iz USB naprave na
računalniku, na katerem je priključena naprava;
- ...

SPLETNA KNJIŽNICA:

ODJEMALEC – BROWSER

SPLETNI STREŽNIK

Aplikacija

Imamo neko napravo, ki znotraj bere neko programsko logiko, ki pošilja podatke preko
nekega porta in na računalniku imamo program, ki prebere in prikaže te podatke

Primeri: telekomunikacijska omrežja (ISO/OSI model); spletne aplikacije, ...

33 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Primer – IS eIzvršbe (CURS)

Predstavitveni nivo
(JSR-286, JSF)

RMI Zunanji sistemi

predlagatelji
WS
SPIS
Poslovna logika JMS
WS ESB IMIS
(EJB) MAIL
KDD
FTP
BANKE
CUKOD
KRO

Podatkovni nivo
(DAO, JPA)

Zunanji sistemi
Podatkovna zbirka
Bazne procedure
(bazne procedure) CROS,
CUKOD (šifranti)

Notranji uporabnik Anonimni uporabnik

Zunanji uporabnik

Internet

JSF - notranji JSF - Odjemalec –

anonimni glavna pisarna
ePOS

SOAP

JSF - zunanji

WS Portal 6.1
RMI RMI
Baza
RMI
CUKOD

Bazni strežnik RMI

Bazne procedure

EJB
Entity Beans (JPA)
Baza
Message Beans (Stateless)
eIzvršbe JDBC JMS MQ

Bazni strežnik

Scheduler
Bazne procedure

WS (XSD) WS AS 7.0
Baza
CROS

Bazni strežnik

eIzvrbe adapter
JBOSS ESB

WS JMS FTP MAIL

SPIS IMIS BANKE KRO

KDD CUKOD Predlagatelji

34 | S t r a n
STEČAJI SI-TSA

Zunanji sistemi
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Primer – sistem za vizualizacijo senzorskih podatkov (ERSŠG Ljubljana –

vegova)

1. Senzorji + oddajnik (arduino) (MikroC)

2. Sprejemnik (arduino)
3. Odjemalec (C#)
4. Podatkovna baza (MySQL)
5. Dinamična spletna stran (PHP, HTML5, CSS, WebGL, Tree.js)

35 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

9. Naloga: Določanje meritev za metrike

Dopolni spodnjo tabelo tako, da za ustrezno metriko podate vsaj 2 vrsti meritev:

Metrika Meritev
Hitrost Koliko transakcij v minuti?
Velikost koliko RAMA in koliko prostora na disku
Zanesljivost koliko dejansko zadeva, da v nekem časovnem obdobju
imamo neko število okvar oz. obratno koliko časa deluje
brez napak
Robustnost ali bo aplikacija delala v nekih okoliščinah v katerih
originalno ni bila predvidena – ali bo delala na nekem
drugem sistemu – kako bi lahko naš sistem dali v neko
drugo okolje – da deluje v kombinaciji z drugim okoljem –
več nameščenih strežnikov – ali se bodo motili med seboj
(ali je občutljiva na temperature – npr. v primeru
industrijskega,proizvodnega sistema) – pogoji krivulje od
do, kaj če pustiš del časa na ekstremih ali bo delalo ali ne
Prenosljivost iz 2010 na 2014 windovse – različne verzije
informacijskega sistema, podatkovne baze,
informacijskega okolja, različni računalniki-vrste
procesorja, verzije baze, rezervnega okolja,
aplikacijskega strežnika, uporaba na različnih
napravah(računalnik, telefon, tablica) – prenesemo v
drugo okolje
Enostavnost uporabe koliko količino funckionalnosti oz. število korakov dokler
ne pridemo do začetka postopka (koliko klikov, da prideš
do spletne strani, ki jo rabiš) to število mora biti čim
manjše, kako hitro se uporabnik nauči uporabljati
aplikacijo (npr. v 3 dneh, če rabi 8 dni, zadeva ni
enostavna za uporabo), koliko potrebujemo časa, da se
naučimo, če gre za nadgradnjo sistema

Metrika je nek način kako opisujem nek atribut naše aplikacije

Koliko transakcij v minuti?

Če želimo namestiti neko aplikacijo sta za velikost vsaj dva parimetra koliko RAMA in
koliko prostora na disku, koliko rabimo še dodatnega za podatko in koliko osnovnega –
lahko so funkcijske točke-kako merim funkcionalnost nekega sistema

Zanesljivost – koliko dejansko zadeva, da v nekem časovnem obdobju imamo neko

število okvar oz. obratno koliko časa deluje brez napak

Robustnost – ali bo aplikacija delala v nekih okoliščinah v katerih originalno ni bila

predvidena – ali bo delala na nekem drugem sistemu – kako bi lahko naš sistem dali v
neko drugo okolje – da deluje v kombinaciji z drugim okoljem – več nameščenih
strežnikov – ali se bodo motili med seboj (ali je občutljiva na temperature – npr. v
primeru industrijskega,proizvodnega sistema) – pogoji krivulje od do, kaj če pustiš del
časa na ekstremih ali bo delalo ali ne

Prenosljivost – iz 2010 na 2014 windovse – različne verzije informacijskega sistema,

podatkovne baze, informacijskega okolja, različni računalniki-vrste procesorja, verzije
baze, rezervnega okolja, aplikacijskega strežnika, uporaba na različnih
napravah(računalnik, telefon, tablica) – prenesemo v drugo okolje

36 | S t r a n
 B2 – Visoka šola za poslovne vede – Programsko inženirstvo – izpitna vprašanja in naloge

Enostavnost uporabe – koliko količino funckionalnosti oz. število korakov dokler ne

pridemo do začetka postopka (koliko klikov, da prideš do spletne strani, ki jo rabiš) to
število mora biti čim manjše, kako hitro se uporabnik nauči uporabljati aplikacijo (npr. v
3 dneh, če rabi 8 dni, zadeva ni enostavna za uporabo), koliko potrebujemo časa, da se
naučimo, če gre za nadgradnjo sistema

Meritve – nekaj kar se da merit, kar nam da končne vrednost

1. Diagram primerov uporabe za avtomat za pijačo in prigrizke (samostojno

delo)

Ustvarite diagram primerov uporabe za avtomat za pijačo in prigrizke. Predvidevajte, da

avtomat občasno potrebuje tehnični servis (pomoč).
Določite akterje, opišite osnovne primere uporabe (cilji akterjev) in narišite diagram. Pri
opisu primerov uporabe uporabite opisno obliko.
Akterji:
- Kupec
- Vzdrževalec – polni avtomat
- Lastnik
- Serviser
Osnovni primeri uporabe:
Gledati z vidika sistema –kaj uporabnik od sistem dobi, kakšno funkcionalnost– kaj
ponuja sistem akterju
Pri kupcu:
- Vloži denar
- Izbere izdelek
- Pobere izdelek
- Pobere vrnjen denar
- Vloži ključek
- Prebere stanje sredstev na ključku
- Polni ključek s sredstvi
Pri vzdrževalcu:
- Polni izdelke
- Nastavlja menije s cenami
- Izloči poškodovane izdelke
Pri lastniku:
- Izračunati skupni izkupiček
- Ustvari obdobne izračune prometa
- Pobrati denar
Pri serviserju:
- Zabeleži napake
- Diagnostika nepravilne uporabe
- Odpravi napake
- Preveri delovanje aparata

37 | S t r a n