Programsko inženirstvo 2009/2010 Vprašanja za obnovo snovi

1. Opiši časovno odvisnost pričakovane pogostosti pojavljanja napak programskih produktov.

2. Navedi primer usodne napake in v smislu programskega inţenirstva komentiraj razloge za

prisotnost napake v končnem produktu.

Mars Climate Orbiter (1999)

Uničen ob vstopu v Marsovo atmosfero zaradi prehitrega spusta.

Programska oprema je bila podedovana od predhodnika.

Razvojne ekipe so uporabljale različne sisteme enot in niso bile usklajene. Testiranje ni bilo

zadostno.

3. Kateri je glavni kriterij uspešnosti programskih produktov?

Programska rešitev je lahko uspešna če:

je zaključen razvoj

je uporabna

je uporabljena

4.Navedi vsaj 5 (od 8) smernic inţenirskega pristopa v razvoju produktov.

Ocenjevanje stroškov/vloţkov

Določitev faz v razvoju

Spremljanje napredovanja projekta

Določitev končnih produktov

Obseţno testiranje

5. Opiši vlogo projektnega vodje in njegove izzive.

Upoštevanje uporabnikov (nejasno definirane zaheve,enostavnost uporabe)

Upoštevanje članov razvojnega tima (pozornost posvečena načinu razvoja)

Upoštevanje managementa (ekonomska uspešnost, povrnitev vloţkov, časovni rok)

6. Kaj razumemo pod etično odgovornostjo programskega inţenirja?

Programski inţenir ima širše odgovornosti kot le uporabo tehničnega znanja:

Zaupnost. Spoštovanje zaupnosti in varovanje podatkov delodajalcev in strank.

Kompetence. Spoštovanje nivoja svojih pristojnosti.

Intelektualne pravice. Varovanje intelektualnih pravic delodajalca, strank in partnerjev.

Zlorabe. Računalnikov in tehničnih znanj se ne sme zlorabljati. Obseg zlorab je širok – od

nameščanja neodobrenih programov na sluţbeni računalnik ali igranja iger, do razširjanja virusov

in vdorov v siteme.

7. Katere lastnosti morajo biti določene za vsak korak programskega procesa?

mora imeti jasno zastavljene cilje

zahteva ljudi s specifičnimi znanji

temelji na jasnih vhodnih parametrih

rezultira v dobro definiranih izhodnih rezultatih

definiran je čas začetka ter čas konca

uporablja specifične tehnike, orodja, smernice, dogovore, standarde…

Mora biti izvršen po projektnem planu, ki določa trajanje, sredstva (resources), omejitve…

Dajati mora informacije za vodstvo (management), ki omogoča korektivne

Korak se konča z pregledom (Verifikacija & Validacija):

Verifikacija – preveri konsistentnost izhodnih rezultatov z vhodnimi parametri

Validacija – preveri konsistentnost s potrebami uporabnika

8. Naštej faze programskega procesa.

Definicija problema

Študija izvedljivosti

Analiza in definiranje zahtev

Načrtovanje sistema

Načrtovanje programa

Izvedba

Testiranje

Prevzem in izdaja

Obratovanje in vzdrţevanje

9. Kakšen je namen definicije problema in na katera štiri vprašanja je potrebno odgovoriti v tem

koraku programskega procesa?

4 vprašanja (Uporabnik in menadţment se morejo strinjati, izogibati dvoumnosti):

Kaj je problem?

Kje se problem pojavi in kdo ga občuti?

Zakaj se problem sploh pojavi?

Kako se problem lahko natančneje razišče?

Rezultat definicije problema je dokument - opis problema (1-2 strani):

naziv projekta,

jedrnat opis problema,

cilji projekta,

morebitne začetne ideje o moţnih rešitvah,

potreben čas in stroški za naslednji korak – študijo izvedljivosti,

groba ocena celotnih stroškov projekta.

10. Na katera tri temeljna vprašanja mora odgovoriti študija izvedljivosti?

Ali je projekt tehnično izvedljiv?

Ali je projekt ekonomsko upravičen?

Ali je projekt operativno izvedljiv (zakoni, kultura, dogovori)?

11.Kakšen je namen analize in definiranja zahtev?

Rezultat je specifikacija zahtev - popoln opis obnašanja sistema:

Analizo in definiranje zahtev izvaja sistemski analitik.

Napačna, nepopolna nekonsistentna ali dvoumna specifikacija zahtev so pogosto vzrok za

neuspeh projektov in spore.

12.Kakšne lastnosti morajo imeti zahteve navedene v specifikaciji zahtev?

Uvod (namen, obseg, definicije, reference na druge dokumente)

Splošni opis (relacije z drugimi sistemi, pregled funkcij/komponent, značilnosti uporabnikov)

Opis zahtev vsake posamezne komponente (opis, vhodi, obdelava, izhodi)

Zahteve zunanjih vmesnikov (formati, strojna oprema, povezave z drugimi programi/sistemi)

Zahteve po prepustnosti sistema (performance)

Omejitve pri načrtovanju (standardi, omejitve strojne opreme…)

Ostale zahteve

13.Naštej prednosti formalnih programskih procesov (vsaj 5 od 8).

Boljši nadzor nad sredstvi.

Boljši odnos s stranko.

Krajši čas razvoja.

Niţji stroški.

Višja kvaliteta in zanesljivost.

14. Opiši linearni model razvoja programskih produktov ter opiši njegove prednosti in slabosti.

Faze si sledijo ena za drugo in se ne prekrivajo. Naslednja faza se začne po zaključeni

predhodni fazi. Vsaka faza se zakljči s pregledom oziroma 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. 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

Prednosti:

preglednost,

ločenost faz,

stalen nadzor nad kvaliteto,

dober nadzor nad stroški.

15. Kakšen je lahko namen izgradnje prototipov programskih produktov.

Prvotni namen prototipa je pomoč stranki in razvijalcem pri razumevanju zahtev sistema.

Uporabniki lahko preverijo kako se odraţajo njihove zahteve.

Prototip razkrije napake in manjkajoče zahteve.

16.Kakšne so prednosti izgradnje prototipov programskih produktov in kakšni so lahko njihovi

negativni vplivi na končni programski produkt?

Razvoj prototipov lahko razumemo kot aktivnost zmanjševanja rizika pri specificiranju zahtev.

Prototip je na voljo zgodaj v programskem procesu in lahko sluţi tudi za usposabljanje

uporabnikov in testiranje sistemov.

PREDNOSTI:

Hitra dobava. Včasih je bolj pomembna od funkcionalnosti ali od moţnosti dolgoročnega

vzdrţevanja.

Vključenost uporabnika povečuje verjetnost, da sistem ustreza uporabnikovim potrebam, hkrati

pa povečuje verjetnost uporabe sistema.

SLABOSTI:

Obstoječi procesi managementa predpostavljajo linearni model.

Razvoj prototipa zahteva dodatne sposobnosti razvijalcev.

Teţavnost vzdrţevanja. Neprestano spreminjanje negativno vpliva na strukturo sistema, zato je

dolgoročno vzdrţevanje teţavno.

17.V čem se prototipi programskih produktov razlikujejo od končnih programskih produktov?

Prototipi običajno ne ustrezajo nefunkcijskim zahtevam

Prototip je nedokumentiran.

Arhitektura/struktura prototipa ni namenjena kasnejšemu

Pri razvoju prototipa se pogosto/večinoma ne upošteva običajnih standardov kakovosti!

18.Opiši spiralni model razvoja programskih produktov.

Vsak cikel vsebuje faze linearnega modela.

V vsakem ciklu se izdela prototip.

Vsak cikel sestoji iz štirih kvadrantov:

Določitev ciljev, alternativ in omejitev.

Ocenjevanje alternativ, identifikacija tveganj.

Razvoj produkta trenutnega cikla.

Načrtovanje naslednjega cikla.

19.Kakšni so temeljni principi agilnih pristopov razvoja programskih produktov?

Razdelitev funkcionalnosti na majhne neodvisne sklope.

Spremembe zahtev so dobrodošle, četudi pozno.

Dnevno sodelovanje tehničnega in poslovnega osebja.

Neposredna vključenost predstavnika stranke v tim.

Najboljša je osebna komunikacija (na štiri oči)

Projekti naj temeljijo na motiviranih posameznik, ki jim je potrebno zaupati.

Enostavnost je vrednota

Timi naj se ogranizirajo sami

20. Opiši ekstremno programiranje

Potek:

Določitev zgodb (ang. stories) - lastnosti, ki jih ţeli stranka/uporabniki.

Ocena trajanja in stroškov za vsako zgodbo.

Izbira zgodb za naslednjo izdajo/verzijo.

Razdelitev nalog (ang. tasks) posamezne izdaje.

Priprava testnih primerov za vsako nalogo.

Programiranje v parih. Brez specializacije razvojnikov. Prisotnost predstavnika stranke.

Zvezna integracija.

22.Kaj so zrelostni nivoji programskih procesov?

Mera efektivnosti programskih procesov v podjetju 1.Začetna - uspešnost odvisna od posameznikov.

2.Ponovljiva - osnovno vodenje projektov. Proces je mogoče ponoviti na podobnih projektih.

3.Določena – programski procesi so dokumentirani, standardizirani in potrjeni znotraj podjetja.

Na teh procesih temeljijo vsi projekti podjetja.

4.Vodena – pri vseh projektih se meri vrsto indikatorjev, ki govorijo o uspešnosti projekta in s

tem porgramskega procesa.

5.Optimirana – stalno izboljševanje programskih procesov na podlagi kazalcev uspešnosti,

novih idej in tehnologij.

24. Navedi vsaj pet tipičnih razlogov za neuspeh programskih projektov!

Slaba kvaliteta - razviti sistem vsebuje napake

Nedoseganje ključnih rokov (čas dobave)

Preseganje omejenih stroškov

Nezadovoljevanje uporabnikovih potreb

Nezmoţnost ali teţavnost vzdrţevanja

Cena razvoja in vzdrţevanja je bistveno višja od pričakovane (ocenjene)

slabo razumevanje uporabnikovih potreb

nezadostno tehnično znanje članov razvojnega tima

Nerealna pričakovanja

Politični razlogi

25. Kakšen je namen projektnega vodenja?

Namen je vzpostavljanje okolja, ki bo privedlo do realizacije projekta, v skladu z zahtevami in

omejitvami.

Vodenje poteka na več področjih

Poslovno vodenje

Tehnično vodenje

Procesno vodenje

Vodenje ljudi

26. Na kakšen način lahko skrajšamo trajanje projekta (navedi tri načine).

Projekt lahko skrajšamo le s skrajšanjem trajanja aktivnosti na kritični poti.

Dodajanje zmogljivosti kritičnim aktivnostim?

Alternativne rešitve (nakup kompenent, outsourcing...)

27.Opiši graf izgorevanja. Čemu je namenjen?

Javno objavljen graf, ki prikazuje preostalo delo iz zaloge sprinta.

Vsakodnevno posodabljanje.

Nudi enostaven vpogled v napredovanje sprinta.

28. Katere tri vrste tveganj na projektih poznamo? Za vsako vrsto navedi primer!

Tveganje je verjetnost pojava za projekt škodljivih okoliščin:

Preobrat Stuffa: Stuff bo prenehal preden se bo končal projekt

Projektna tveganja vplivajo na časovni plan in sredstva.

Produktna tveganja vplivajo na kvaliteto in zmogljivost razvijane programske opreme.

Poslovna tveganja vplivajo na organizacijo, ki razvija programsko opremo.

29. Kateri dejavniki vplivajo na produktivnost? (navedi vsaj tri)

Izkušnje iz področja dela Izkušnje so bistvene za efektiven razvoj programov. Inţenirji, ki poznajo področje dela so

občajno najbolj produktivni.

Kvaliteta programskega procesa Ustreznost in kvaliteta programskega procesa bistveno vpliva na produktivnost.

Velikost projekta Večji projekti zahtevajo več časa za komunikacijo znotraj skupine. Manj časa je na voljo za

razvoj, kar zmanjša produktivnost.

Tehnologija Uporaba primernih orodij (npr. CASE) vpliva na večjo produktivnost.

Delovno okolje Tiho delovno okolje, ki nudi določeno stopnjo zasebnosti ter ločeni prostori za debate in

sestanke prispevajo k večji produktivnosti.

30.Opiši kako je organizirana skupina glavnega programerja. Kakšne so prednosti in slabosti

takšne organizacije skupine?

Skupino vodi glavni programer, ki prevzema vse naloge načrtovanja in izvedbe. Pri opravljanju

nalog mu pomagajo člani skupine.

V primeru njegove odsotnosti vodilno vlogo prevzame namestnik.

Vsakršna (daljša) odsotnost glavnega programerja lahko povzroči neuspeh projekta.

Vloga glavnega programerja je zahtevna in ustrezen kader redek.

31.Naštej vsaj 5 vlog projektnega vodje!

Vodenje

Organizacija

Komunikacija

Finance

Team building

Pohvale in nagrajevanje

Grajanje in kaznovanje

32.Opiši lastnosti, ki naj bi jih imel idealni projektni vodja.

Oseba, ki ve kaj bo šlo narobe še preden do tega dejansko pride.

Potrebne so izkušnje.

Pomagajo podatki predhodnih projektov.

33. Opiši potek izoblikovanja skupin.

1.Organizacija in informiranje – seznanjanje z nalogo in načinom dela.

2.Nastanek konfliktov – začetek dela, neskladja v smeri iskanj arešitev.

3.Sodelovanje – izoblikovanje skupinskih norm.

4.Stabilizacija – skupina je optimalna za izvajanje svojih nalog.

34.Katere lastnosti so pomembne pri izbiri članov projektne skupine?

Izkušnje iz področja dela – zelo pomembno, vsaj kateri od članov.

Izkušnje iz razvojne platforme – manj pomembno.

Izkušnje iz programskega jezika – pomembno le kratkotrajno.

Sposobnost reševanja problemov – ključno za inţenirsko delo.

Izobrazba – izkazuje sposobnosti učenja.

Komunikacijske sposobnosti – pomembno za delovanje skupine.

Prilagodljivost – pomembna za reševanje zelo različnih problemov.

Odnos do dela – zelo pomemben pozitiven odnos do dela in pripravljenost za dodatno učenje.

Osebnostne lastnosti – teţko oceniti, člani skupine morajo biti “zdruţljivi”.

35. Kaj je kontekstualni diagram? Katere elemente prikazuje?

Določa obseg sistema - določa meje sistema.

Vsebuje:

en porces, ki ponazarja celoten sistem,

vse izvore in ponore podatkov – zunanje objekte,

podatkovne tokove, ki sistem povezujejo z zunanjimi objekti - izvori in ponori.

36.Opiši razlike med implicitnimi in eksplicitnimi modeli.

Implicitni modeli:

- Implicitni modeli niso ubesedeni.

- Implicitni modeli se s časom spreminjajo.

- Naročnik in sistemski analitik ne govorita istega “jezika”.

- Vsega implicitnega znanja se ne da fomralno zapisati.

37. Navedi vsaj pet primerov nefunkcijskih zahtev.

- Moţnost testiranja

- moţnost vzdrţevanja

- razširljivost

- uporabljivost

- varnost

38. Navedi načine seznanjanja s problemom in zbiranja zahtev (vsaj 5)!

- Študij literature

- Nasveti strokovnjakov

- Spraševanje

- Izpeljave iz obstoječega sistema

- Izdelava prototipov

39. Kaj so atomske zahteve?

-Atomske zahteve: Zahteve so atomske, ce:natancno dolocajo potrebo ne da bi jih bilo

treba deliti na vec zahtev, so merljive,so preverljive (testabilne),so sledljive.

40.Kakšen je namen analize zahtev? (Kakšna vprašanja si zastavljamo za dosego cilja?)

Ali je vsaka od zahtev skladna s cilji novega sistema?

Ali je vsaka zahteva resnično potrebna za dosego ciljev sistema?

Ali je vsaka zahteva jasna in nedvoumna?

Ali ima vsaka zahtev jasen izvor (kdo to zahteva)?

Ali si katere od zahtev nasprotujejo?

Ali je vaka od zahtev tehnično izvedljiva v okviru danega okolja?

41.Kaj razumeš pod pojmom „primer uporabe“. Navedi primer (poljuben)

Primer uporabe opisuje interakcijo med akterji in sistemom za nek scenarij uporabe sistema:

Opisuje funkcijo, ki jo sistem nudi uporabniku.

Opisuje celovito interakcijo uporabnika s sistemom, torej obseţne procese, od začetka do

konca uporabe.

Z njim uporabnik doseţe nek cilj.

Za definiranje primerov uporabe je potrebno razumevanje zahtev.

Primer uporabe določimo za vsak dogodek sistema.

Podrobno jih opišemo z opisom primera uporabe in ilustriramo z diagramom primera uporabe

42. Opiši vsebino opisa primera uporabe.

Naziv primera uporabe

Akterji: navedba vseh udeleţenih akterjev.

Zahteve: zahteve povezane s primerom uporabe (tudi vir zahteve).

Triger: vzrok za začetek aktivnosti.

Osnovni potek: tok aktivnosti za običajno uspešno interakcijo – seznam korakov. Začne se ob

trigerju in konča ob uspešnem zaključku.

Stanje po zaključku

Pričakovan rezultat primera uporabe.

Alternativni poteki: opisujejo ostale moţne uspešne in neuspešne poteke, kot tok aktivnosti podan

s seznamom korakov. Začejo in končajo se lahko kjer koli, glede na druge poteke.

Alternativni poteki lahko izhajajo iz drugih alternativnih potekov.

Razno: komentarji primera uporabe in povezave z drugimi primeri uporabe

44. Katere naloge vključuje načrtovanje sistema? (vsaj 6 od 8)

Načrtovanje sistema je aktivnost s katero preslikamo model specifikacije zahtev v načrtovalski

model sistema

Načrtovanje sistema vključuje:

definicijo načrtovalskih ciljev,

dekompozicijo sistema na podsisteme,

izbiro ţe izdelanih komponent,

relacije med podsistemi (programsko opremo) in strojno opremo,

izbira infrastrukture za upravljanje s persistentnimi podatki,

določitev politike nadzora dostopa,

izbira mehanizma globalnega kontrolnega toka,

obravnavanje mejnih primerov.

45. Kaj razumeš pod pojmom „povezanost podsistemov“? Kakšne vrste povezanosti poznaš?

Povezanost govori o odvisnosti med dvema podsistemoma.

Če sta dva podsistema močno povezana, bodo imele spremembe enega od podsistemov vpliv na

delovanje drugega podsistema.

Zaţeljeno je, da so podsistemi povezani kar se da šibko (S tem je doseţen manjši vpliv napak in

sprememb enega podsistema na delovanje drugega podsistema).

Ločimo več tipov povezanosti: Content - ko ena komponenta "tajno" spremeni interni podatek druge komponente

Common - kadar se uporabljajo globalne spremenljivke

Control - če ena procedura kliče drugo proceduro z navedbo ukaza, ki eksplicitno določa

delovanje druge procedure

Stamp - ko je eden od razredov uporabljen kot tip argumenta neke metode (drugega razreda)

Data - kadar so tipi argumentov metod primitivni ali pa enostavni razredi knjiţnic

Routine Call - kadar ena rutina (oz. metoda v OO sistemu) kliče drugo

Type use - kadar modul uporablja podatkovni tip določen v drugem modulu

46. Kaj razumeš pod pojmom „kohezija podsistemov“ Kakšne vrste kohezije

Kohezija govori o notranji povezanosti znotraj podsistema.

Kohezija je velika, če podsistem zdruţuje medseboj odvisne oz. povezane komponente ter ne

vsebuje ostalih, nepovezanih komponent.

Zaţeljena je velika kohezija podsistema, kajti takšni podsistemi so laţji za razumevanje in

spreminjanje.

Ločimo več tipov kohezije: Functional - doseţena takrat, kadar je zdruţena vsa koda, namenjena pridobivanju določenega

rezultata, ostala koda pa ni vključena

Layer - v sloj je zdruţeno vse potrebno za zagotavljanje oz. dostopanje do mnoţice povezanih

storitev

Communicational - vsi moduli, ki dostopajo oz. uporabljajo določene podatke so zdruţeni

(npr. v en razred), vse ostalo ni vključeno.

Sequential - zdruţene so procedure v katerih ena procedura priskrbi vhodne podatke za drugo

proceduro, vse ostalo ni vključeno

Procedural - zdruţene so procedure, ki so uporabljene ena za drugo

Temporal - zdruţene so operacije, ki se izvajajo v isti fazi izvajanja programa, vse ostalo ni

vključeno

Utility - zdruţene so operacije, ki ne morejo biti logično vključene v ostale kohezivne enote

47.Kaj so arhitekturni vzorci? Navedi primer.

Vzorec je:

Dokumentacija rešitve ponavljajočega se problema.

Rešitev je večkrat preizkušena in splošno priznana.

Rešitev podaja način reševanja, ne pa neposredne rešitve, ki je odvisna od dejanskega

reševanega problema.

48.Naštej vsaj 4 skupine načrtovalskih ciljev in za vsako podaj primer.

V splošnem lahko načrtovalske cilje izberemo iz seznama splošno ţeljenih kvalitet programskih

produktov, ki jih uredimo v pet skupin:

učinkovitost - odzivni čas, prepustnost, pomnilnik

zanesljivost - robustnost, zanseljivost, razpoloţljivost, odpornost,

cena - cena razvoja, namestitve, nadgradnje, vzdrţevanja, administriranja

zmožnost vzdrževanja - razširljivostm spremenljivost, prilagodljivost, prenosljivost, čitljivost

uporabniške zahteve - koristnost, uporabnost

50.Kakšen je lahko namen dedovanja?

Dedovanje se uporablja za doseganje dveh različnih ciljev:

Razvrščanje razredov v skupine (taksonomija) Uporablja se v fazi analize zahtev

Za identifikacijo objektov, ki so medsebojno hierarhično odvisni.

Pripomore k razumljivosti modelov.

Ponovna uporaba Uporablja se v fazi načrtovanja objektov.

Pripomore k moţnosti uporabe obstoječih objektov ter moţnosti njihovega spreminjanja in

rezširjanja

51.Kakšne prednosti ima delegiranje pred dedovanjem?

Delegiranje

+ Fleksibilnost

+ Omogočeno za vse programske jezike - Slabša učinkovitost, zaradi ovijanja (encapsulation)

Dedovanje

+ Enostavnost

+ Podprto v mnogih programskih jezikih

+ Enostavno dodajanje novih funkcionalnosti

- Izpostavljenost detajlov osnovnega razreda

- Vsaka sprememba osnovnega razreda zahteva spremmebo dedovanega razreda

52.Kaj pomeni „odvisnost“ pri načrtovanju programov? Navedi tri primere!

Odvisnost je prisotna, če sprememba enega elementa programa lahko zahteva spremembo

nekega drugega elementa programa.

Odvisnost je glavni vir teţav pri vzdrţevanju programskih produktov.

Pri načrtovanju teţimo k čim manjši odvisnosti

Dinamična odvisnost (ang. dynamic connascence):

Odvisnost izvajanja – npr. pred uporabo potrebna inicializacija.

Časovn aodvisnost – npr. ukaz za zaustavitev obsevalne naprave mora slediti ukazu za vklop

naprave v manj kot 50 milisekundah.

Odvisnost vrednosti – npr. aritmetična omejitev – vsota vseh kotov trikotnika je vedno enaka

180 stopinj.

Statična...

53.Kaj je Liskov princip zamenjave?

Razred S “ustreza” razredu T, če je mogoče vsak objekt razreda T nadomestiti z

objektom razreda S, ne da bi pri tem ogrozili pravilnost delovanja programa. Če osnovni razred zadosti zahtevam aplikacije, potem mora tudi LSP nadomestni razred

zadostiti istim zahtevam, tako da s stališča vmesnika deluje povsem enako in da za enake

argumente enake rezultate.

Če ţelimo da je nek razred S podtip razreda T, mora S “ustrezati” T.

54.Kaj je ovijanje?

Ovijanje je proces zaokroţanja elementov z določanjem abstrakcije, ki določa strukturo in

obnašanje elementov.

Ovijanje sluţi za ločevanje “pogodbenih” vmesnikov (določenih z abstrakcijo) od

implementacije.

55.Kaj je kohezija razreda? Kakšne kohezije si ţelimo?

Meri medsebijno povezanost metod zunanjega vmesnika razreda. Kako zaključeno deluje razred v smislu implementacije abstrakcije.

Želimo visoko kohezijo! Kvantitativna mera kohezije razreda ne obstaja.

Simptomi nizke kohezije:

Razred vsebuje nekaj komponent, ki niso definirane za vse objekte razreda. Eventuelno

izboljšanje z ločitvijo v dva razreda.

56. Kakšne prednosti prinaša modularnost?

Modularen program sestoji iz dobro definiranih, konceptualno enostavnih in neodvisnih enot -

modulov, ki komunicirajo preko dobro definiranih vmesnikov.

Prednosti modularnosti

enostavnejše razumevanje in razlaganje,

enostavnejše dokumentiranje,

enostavnejše spreminjanje,

enostavnejše testiranje in razhroščevanje,

enostavnejše nastavljanje.

57. Kaj so načrtovalski vzorci? Kako delimo načrtovalske vzorce? Navedi primer načrtovalskega

vzorca.

Načrtovalski vzorci so:

Elegantna rešitev, ki začetnikom ni samoumevna.

Neodvisni od sistema, programskega jezika ali domene aplikacije.

Dokazano uspešni v realnih OO sistemih.

Enostavni, vsebujejo le nekaj razredov.

Večkrat uporabni in na tak splošen način tudi dokumentirani.

Določa jih:

Ime vzorca

Problem – načrtovalski vzorci vsebujejo opis problema, za katerega je primerno uporabiti

vzorec.

Rešitev – načrtovalski vzorci podajajo elemente in njihove medsebojne relacije, ki tvorijo

rešitev problema.

Posledice – rezultati in posledice uporabe načrtovalskega vzorca.

Delitev:

Glede na namen:

Kreacijski - Določajo proces kreiranja objektov

Strukturni - Določajo kompozicijo razredov in objektov

Vedenjski - Določajo način interakcije med razredi in porazdelitev odgovornosti.

Glede na področje delovanja:

Razredni - Vzorec se ukvarja z razredi in njihovimi medsebojnimi relacijami, ki so določene z

dedovanjem in so statične.

Objektni - Vzorec se ukvarja z relacijami med objekti, ki so dinamične in se lahko spreminjajo

v času izvajanja.

58.Kakšne principe pri načrtovanju grafičnih uporabniških vmesnikov poznaš?

Principi pri načrtovanju GUI:

Uporaba miselnih modelov

Uporaba metafor

Evidentnost funkcionalnosti

Princip povezanosti

Princip povratnih informacij

Omejitve

59.Kaj je miselni model? Ali je relacija med pravilnostjo in efektivnostjo miselnih modelov?

Miselni modeli so človekov lastni in osebni način razumevanja sveta. Ljudje izoblikujemo miselne modele preko izkušenj, vzgoje, šolanja, navodil…

Miselni modeli so v principu pogosto napačni, a kljub temu efektivni

Pri razvoju programskih produktov se ukvarjamo z več modeli:

Implementacijski model

Sistemski model

Uporabniški miselni model

Primer pravilnost/efektivnost:

Računalniški zaslon: mnogi uporabniki vidijo zaslon kot centralni in bistveni del računalnika.

Nepravilen a efektiven miselni model.

60.Kakšna je razlika med funkcijskimi in strukturnimi mentalnimi modeli?

Funkcijski - Vedenje o tem KAKO, ne pa tudi ZAKAJ. (Primer: ugašanje PC pred izklopom)

Strukturni - Razumevanje komponent in njihove medsebojne odvisnosti (ZAKAJ) - Omogoča

reševanje problemov!

61.Kaj je konceptualni model?

Uporabniški miselni modeli niso neposredno pod nadzorom načrtovalca sistema.

Uporabniški miselni model, kakršnega bi si ţeleli, imenujemo (uporabnikov) konceptualni

model.

Kako naj uporabnik pridobi pravi miselni model?

šolanje

dokumentacija

interakcija s sistemom (uporaba)

62.Kaj je metafora (pri načrtovanju GUI)? Navedi primer! Ali je uporaba metafor vedno

smiselna?

Metafore v primeru uporabniških vmesnikov tipično poudarjajo podobnosti z realnim svetom

oziroma obstoječimi konceptualnimi modeli.

Primeri metafor:

Namizje (ang. desktop metaphor) : inbox, folder, trash...

Spletne trgovine: nakupovalni voziček, blagajna...

Uporabljene so le bistvene lastnosti (npr. pri nakupovalnem vozičku nas ne zanima njegova

velikost).

Pretirano izkrivljanje uporabniškega vmesnika ni priporočljivo.

Koristno je uporabiti le tiste lastnosti, ki prispevajo k enostavnosti in razumljivosti.

Namesto pretiranega izkrivljanja uporabniškega vmesnika z metaforami je priporočeno

idiomatično načrtovanje.

Idiomatično načrtovanje – uporaba novih simbolov, ki se jih je potrebno naučiti in postanejo

značilni za določene objekte, lastnosti.

63.Navedi primer evidentne funkcionalnosti povezanih z GUI!

Evidentna funkcionlnost (affordance) je bistveno pomembnejša kot uporabniška navodila –

uporabniku postane način dela evidenten ţe iz predmeta samega (npr. iz izgleda uporabniškega

vmesnika).

Primeri:

Kodak DC-290: evidentno nakazano kako naj uporabnik drţi fotoaparat,

3D gumb: Samoumevno kaţe na moţnost, da ga pritisnemo!

64.Opiši princip povratnih informacij pri načrtovanju GUI!

Posredovanje povratnih informacij nazaj uporabniku:

Katera aktivnost se je dejansko izvedla / se izvaja.

Kakšni so rezultati predhodne aktivnosti.

Povratne informacije morajo biti pravočasne!

Primeri:

Tipkovnice bi lahko bile povsem tihe, pa vendar uporabniki ob pritisku tipke pričakujemo

“klik”.

Premikanje miške po zaslonu. Kadar je sistem prezaposlen in miška zaostaja, je uporabnikom

neudobno.

65.Na kakšen način lahko omejitve koristijo uporabniškim vmesnikom? Navedi primer!

Omejitve predstavljajo način za olajšanje interakcije uporabnika s sistemom.

Omejitve so lahko fizične, semantične, kulturne, logične.

Omejitve lahko omejujejo uporabo določenih aktivnosti:

Določene aktivnosti ne smejo biti izvedene.

Določene aktivnosti morajo biti izvedene.

Z omejitvami lahko podrobneje določimo uporabnikove moţnosti, npr. pri vnosu podatkov.

Omejitev moţnosti izbire (radio box, on/off gumbi, seznami…)

Uporabnika je pri interakciji potrebno omejiti na funkcionalnost, ki jo nudi aplikacija.

Primer: izbira spola pri spletni anketi: slabo - vpis v npr. text box, dobro (omejitev) - radio button za

izbiro M ali Ţ

66.Primerjaj analogni in digitalni prikaz podatkov. Kakšne so prednosti in slabosti obeh?

Digitalna predstavitev

Kompakten prikaz zavzame malo prostora.

Podajanje natančnih vrednosti

Analogna predstavitev

Hitro podajanje pribliţnih vrednosti.

Moţnost podajanja relativnih vrednosti

Boljša indikacija izjemnih vrednosti

67. Za kaj naj bi se uporabljala pogovorna okna? Kakšne lastnost naj imajo?

Pogovorna okna se uporabljajo za prikaz dodanih informacij o delovanju sistema. Predstavljajo prekinitev oziroma motnjo normalnega toka uporabe sistema.

Pogovornim oknom se je priporočljivo izogibati.

Primarna interakcija s sistemom naj se dogaja v primarnem oknu, ne v pogovornih oknih.

Ločimo štiri 4 tipe pogovornih oken:

Lastnosti – uporabniku predstavi lastnosti (značilnosti) izbranega objekta.

Funkcije – nadzor nad izvajanjem posamezne operacije, npr. črkovanje, tiskanje.

Objave – podajajo kratek opis problema, npr. obvestila o napakah.

Procesi – uporabnika informirajo, da se progam za določen čas ni sposoben normalno odzivati

Zahtevana pogovorna okna so lahko velika in na zaslonu dominantna.

Nezahtevana pogovorna okna naj bodo manjša in nevsiljiva.

Pogovorna okna imajo prehoden značaj.

Nezahtevanim pogovornim oknom se je potrebno izogibati.

68.Kaj razumemo pod pojmoma prepad izvajanja in prepad vrednotenja?

Ko uporabnik ţeli opraviti določeno nalogo, se srečamo s tremi aktivnostmi.

Določanje ciljev – kaj uporabnik ţeli, kaj pričakuje od naprave in kakšen je njegov namen

Izvajanje – kako uporabnik doseţe cilje z uporabo dane naprave?

Vrednotenje – kako uporabnik ve ali je dosegel zastavljene cilje?

Srečamo se z dvema razkorakoma med ţelenim in dejanskim obnašanjem naprave.

Prepad izvajanja razlike med uporabnikovimi nameni in aktivnostmi, ki so na voljo.

Prepad vrednotenja trud, ki je potreben, da uporabnik interpretira stanje naprave.

stopnja zadovoljstva uporabnika glede na namene in pričakovanja.

69.Katere lastnosti so pomembne pri vrednotenju GUI?

Čas učenja – koliko časa potrebuje uporabnik, da je zmoţen učinkovito uporabljati sistem.

Hitrost dela – kako se hitrost odzivanja sistema sklada z uporabnikovimi potrebami oziroma

navadami.

Robustnost – kako toleranten je sistem do uporabniških napak.

Prilagodljivost – kako močno je sistem vezan na en sam način uporabe.

Zanesljivost – kakšna je pogogstost napak v delovanju sistema.

Uporabniško zadovoljstvo – subjektivno mneneje uporabnikov glede uporabe sistema.

Ponavljajoče operacije – pogostost uporabe posameznih ukazov uporabniškega vmesnika

70.Opiši razliko med verifikacijo in validacijo.

Verifikacija Posamezne komponente so testirane glede na skladnost s specifikacijami programa

Posamezne komponente so zdruţene v programski sistem in testirane glede na specifikacije

sistema

Validacija Poteka po vnaprej pripravljenem načrtu, ki izhaja iz specifikacij zahtev. Preverja se skladnost

sistema z zahtevami

71.Navedi nekaj napotkov udeleţencem recenzij (recenzentom in/ali avtorjem)!

Pozitiven pristop recenzentov:

Sprašuj namesto da grajaš. Npr. namesto “Tu nisi upošteval standardov!” uporabi “Kakšen je razlog za uporabo

uporabljenega pristopa?”

Izogibaj se vprašanjem tipa “Zakaj”. Npr. namesto “Zakaj tukaj nisi upošteval standardov?” uporabi “Kakšen je razlog za

odstopanje od standardov...”

Ne pozabi na pohvalo. Pomembno je opaziti tudi pozitivno, npr. kreativne rešitve. To avtorju da vedeti, da njegovo

delo vidimo širše kot le vrsto napak.

Tema recenzije naj bo delo in ne avtor. Namen recenzije je prispevek k kvaliteti in ne opredeljevanje o lastnostih in sposobnostih

avtorja.

Zavedaj se, da obstaja več kot ena možna (dobra) rešitev. Čeprav je avtor nekaj naredil drugače kot bi ti, to ni nujno narobe.

Pozitiven pristop avtorjev:

Zavedaj se, da recenzirano delo nisi ti. Razvoj je kreativni proces in normalno je, da si na svoje delo navezan. Vendar pa recenzenti ne

ţelijo povedati, da si nisi dober razvijalec. Njihova naloga je pokazati na pomanjkljivosti in

moţnosti boljših rešitev

Naredi seznam stvari na katere se bodo osredotočili recenzenti.

S seznamom ponovno preglej svoje delo in popravi morebitne najdene napake. S tem boš ne le

zmanjšal število najdenih napak, pač a tudi skrajšal čas revizije.

Pomagaj vzdrževati standarde. Ponudi dopolnitev standardov za tisto, karje bilo dogovorjeno in ni vključeno v obstoječe

standarde. Na ta način dokumentirana rešitev bo v pomoč pri naslednjih delih in recenzijah.

72. Kaj pomeni, če je testiranje uspešno?

Test je uspešen, če je z njim najdena prej nepoznana napaka. Dober testni primer je tisti, za katerega obstaja velika verjetnost da bo razkril še ne odkrito

napako.

73. Kakšna je razlika med strukturnim in vedenjskim testiranjem?

Strukturno testiranje (white-box testing) Testiranje temelji na poznavanju notranje strukture porgrama.

Vedenjsko testiranje (black-box testing) Testiranje temelji na (deklariranih) zunanjih lastnostih sistema.

74.Opiši princip testiranja osnovnih poti?

Neodvisna pot je pot skozi program, ki vsebuje vsaj en nov del programske kode ali nov pogoj.

Vsaj en del poti ni vsebovan v drugih neodvisnih poteh.

Število neodvisnih poti je odvisno od ciklomatične kompleksnosti - mere logične

kompleksnosti programa.

Izračun ciklomatične kompleksnosti V(G) na osnovi grafa izvajanja G:

V(G) = število enostavnih odločitev + 1

V(G) = število vsebovanih področij grafa + 1

Za načrtovanje osnovnih poti ne potrebuješ grafa, res pa ta olajša sledenje potem.

Clikomatično kompleksnost določiš s štetjem enostavnih logičnih odločitev. Kompleksne

odločitve se šteje za dve ali več enostavnih.

Testiranje osnovnih poti je posebno pomembno pri kritičnih modulih.

75. Kaj je ciklomatična kompleksnost?

Število neodvisnih poti je odvisno od ciklomatične kompleksnosti - mere logične

kompleksnosti programa.

76.Kaj so ekvivalentne particije ?

Ekvivalentne particije je postopek za določanje razredov vhodnih podatkov iz katerih

izberemo testne podatke. Ekvivalentni razred je skupina veljavnih ali neveljavnih vhodnih pogojev.

Glede na določitev vhodnih pogojev določimo ekvivalentne razrede na naslednji način:

Vhodni pogoj je določen s področjem – določi en veljaven in dva neveljavna ekvivalentna

razreda.

Vhodni pogoj je specifična vrednost - določi en veljaven in dva neveljavna ekvivalentna

razreda.

Vhodni pogoj je določen s pripadnostjo množici - določi en veljaven in en neveljaven

ekvivalentni razred.

Vhodni pogoj je logična vrednost (ang. boolean) - določi en veljaven in en neveljaven

ekvivalentni razred.

77.Opiši test enote

Obsega testiranje posameznih komponent oziroma enot .

Testiranje temelji na izvorni kodi (strukturno testiranje / white-box)

Tipično je test enote odgovornost razvijalca.

Izvedba testa je odvisna od izkušenj razvijalca.

Za testiranje enote pripravimo testni gonilnik (ang. driver).

Če enota uporablja druge enote, le te v čim večji meri nadomestimo z

78.Opiši eno od strategij integracijskega testiranja.

Testiranje skupine komponent, ki so zdruţene v sistem ali podsistem.

Odgovornost neodvisne testne skupine.

Testiranje temelji na specifikacijah sistema – vedenjsko testiranje (black-box).

Glavna teţava je lokalizacija napak, ki jo je mogoče reševati z inkrementalno integracijo.

79.Kako poteka testiranje pritiska in kako vrednotimo rezultate?

Testiranje sistema ob obremenitvi večji od največje načrtovane.

Pogosto pokaţe neodkrite napake.

Ob prekomerni obremenitvi prihaja do napak

Ki pa ne smejo biti katastrofalne.

Ne sme priti do nedovoljenega izpada storitve ali izgube podatkov

Posebno pomembno pri porazdeljenih sistemih.

80. Naštej vsaj 4 dokumente, ki jih za dokumentiranje testiranja predlaga standard IEEE 829!

Standard IEEE 829 določa skupino priporočil za dokumentiranje testiranja programskih

produktov.

IEEE 829 določa osem različnih dokumentov, ki pokrivajo tri korake testiranja:

Priprava na testiranje

Izvajanje testiranja

Zaključek testiranja

IEEE 829 je dobro izhodišče za določitev testnih dokumentov. Vendar pa morajo biti

dokumenti prirejeni ali spremenjeni, tako da ustrezajo potrebam projekta.

Dokumente uporabljaj tako, da zadovoljijo potrebe in ne kot same sebi namen!

Priprava na testiranje:

Načrt testiranja (ang. test plan) Načrt poteka testiranja. Okvirno določa kako bo potekalo testiranje: kaj bo testirano, kdo bo

testiral, kako bo testirano in kdaj bo testiranje potekalo.

Specifikacija testa (ang. test design dpecification) Generalna določitev testov vkljčno s pričakovanimi razultati.

Specifikacija testnih primerov (ang. test case specification) Določitev testnih primerov s testnimi podatki.

Testni postopek (ang. test procedure) Opis praktične izvedbe testiranja.

Poročilo predaje v testiranje (ang. test item transmittal report) Navaja kaj je bilo predano v postopek testiranja.

Izvajanje testiranja:

Dnevnik testiranja (ang. test log)

Seznam vseh izvedenih testov z detajli, podani v časovnem zaporedju.

Poročilo testnih incidentov (ang. test incident report)

Seznam dogodkov, ki jih je potrebno dodatno raziskati in njihovim detajlnim opisom

Zaključek testiranja:

Poročilo testiranja (ang. test summary report)

Povzetek testiranja in sklep o rezultatu testiranja.

81. Kakšen je namen vzdrţevanja programskih produktov? Katere štiri vrste sprememb vključuje

vzdrţevanje?

Vzdrževanje pomeni spremembe programskega produkta po izdaji z namenom:

odpravljanja napak,

izboljšanja zmogljivosti

prilagoditve produkta spremenjenemu okolju.

prilagajanje novim zahtevam V večini primerov je izhodišče obstoječi produkt, ki mu dodajamo nove funkcionalnosti. Gre

za neskladje z linearnim modelom.Vzdrţevanje je ključno za ohranjanje uporabe produkta!

Vrste sprememb:

Korektivne spremembe odpravljanje napak.

Adaptivne spremembe prilagajanje spremenjenim pogojem.

Perfektivne spremembe izboljšanje programskega produkta.

Preventivne spremembe odpravljanje poslabševanja programskega produkta.

83. O čem govorijo Lehmanovi zakoni? Predstavi enega izmed Lehmanovih zakonov!

Meir Manny Lehman je glede na potrebo po vzdrţevanju opredelil tri tipe programskih

produktov.

S-system: formalno definirani sistemi, ki v celotni ţivljenski dobi ne zahtevajo sprememb.

P-system: sistemi katerih zahteve temeljijo na aplikativni rešitvi problema. Potrebujejo

inkrementalno prilagajanje dejanskemu svetu.

E-system: sistemi vgrajeni v dejanski svet, zahtevajo stalno prilagajanje dejanskemu svetu.

Meir Manny Lehman je zbral 8 (4 obravnamo) zakonov evolucije programskih produktov.

1) Zakon o stalnosti spreminjanja ¨Sisteme je potrebno stalno prilagajati, sicer postopno vse slabše zadovoljujejo potrebe

uporabnikov. Odstopanje med sistemom in njegovim področjem delovanja ustvarja povratno

zanko, ki spodbuja spreminjanje sistema.

6) Zakon o stalni rasti ¨Če želimo ohranjati zadovoljstvo uporabnikov, se morajo funkcijske zmožnosti programskega

produkta ves čas življenjske dobe povečevati. Vsaki izvedbi sistema je zahteve potrebno omejiti.

Izpuščene ali prezrte lastnosti bodo sprožile nadaljnje zahteve po spremembah. To je povratna

zanka od uporabnikov.

2) Zakon o povečevanju kompleksnosti ¨Z razvojem (spreminjanjem) sistema se kompleksnost sistema povečuje, razen če se

kompleksnosti z dodatnim vloženim delom ne zmanjšuje. Če se spreminjanje sistema dogaja brez

premisleka o njegovi strukturi, se kompleksnost sistema povečuje in otežuje nadaljnje

spremembe. Nasprotno, če se sredstva porabijo tudi za boj proti kompleksnosti, jih je manj na

voljo za ostalo spreminjanje sistema. Ne glede na izbrano razmerje se hitrost rasti sistema

neizogibno manjša.

7) Zakon o upadanju kakovosti

¨Če se sistem striktno ne prilagaja spremembam v okolju, v katerem deluje, bo videti, da kakovost

sistema upada. Sistem je zgrajen na množici predpostavk in ne glede na njihovo veljavnost v

določenem trenutku, bo spreminjajoči svet na njih vplival v smeri njihovega zavračanja. Če se

teh predpostavk ne identificira in popravi, bo videti, da kakovost sistema upada, še posebej v

primerjavi z alternativnimi produkti, ki so na trg prišli z bolj sveže formuliranimi

predpostavkami.

85. Kaj razumemo pod pojmom „upravljanje konfiguracij“?

Vsak programski projekt proizvede veliko različnih izdelkov

Med vsemi izdelki obstajajo povezave.

Vse povezave med izdelki ter njihovo trenutno stanje imenujemo konfiguracija.

Če naredimo spremembo na enem izdelku, lahko to vpliva na vse z njim povezane izdelke.

Zaradi velikega vpliva sprememb izdelkov ter njihove pomembnosti pri razvoju programskega

produkta, je spremembe potrebno nadzirati in slediti.

Upravljanje konfiguracij je aktivnost nadzora nad evolucijo kompleksnih sistemov.

Glavne naloge dobrih sistemov upravljanja konfiguracij programskih produktov so:

Verzioniranje – upravljanje verzij vseh izdelkov projekta.

Kompozicija – sledenje odvisnosti med izdelki in s tem pomoč pri upravljanu sprememb.

Podpora razvoju – sinhronizacija objektov, koordiniranje razvoja, gradnja produktov.

Procesna podpora – nudenje povratne informacije o statusu projekta

86. Primerjaj copy-modify-merge in lock-modify-unlock način delovanja sistemov za nadzor

verzij!

Copy-modify-merge Lock - modify - unlock

87.Čemu sluţijo vejitve pri uporavljanju konfiguracij?

Vejitev pomeni istočasni obstoj dveh (aktivnih) vej razvoja istega izdelka konfiguracije.

Vejitev se uporablja za dva namena

Za izoliranje sprememb izdelka

Za kreiranje več variant istega izdelka

89. Kakšna je povezava med avtorskimi pravicami in licenčnimi pogodbami?

Lastnik programskega produkta ima določene ekskluzivne pravice. Osnovne so avtorske

pravice , ki lastniku dajejo pravice:

lastne uporabe produkta,

določanja kako je produkt lahko uporabljen,

določanja kdo lahko uporablja produkt,

določanja kdo lahko produkt spremeni,

določanja kdo lahko kopira in prodaja kopije produkta.

Vsaka uporaba (nakup) ne-lastnikov produkta je dovoljena le če ima ta sklenjen dogovor z

lastnikom v obliki licenčne pogodbe. Nakup licence ne pomeni nakupa programskega produkta,

pač pa le nakup omejenega nabora pravic za uporabo produkta.