of 22/22
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)

Vprašanja - Reedit

  • View
    97

  • Download
    6

Embed Size (px)

Text of Vprašanja - Reedit

Programsko inenirstvo 2009/2010 Vpraanja za obnovo snovi 1. Opii asovno odvisnost priakovane pogostosti pojavljanja napak programskih produktov.

2. Navedi primer usodne napake in v smislu programskega inenirstva komentiraj razloge za prisotnost napake v konnem produktu. Mars Climate Orbiter (1999) Unien ob vstopu v Marsovo atmosfero zaradi prehitrega spusta. Programska oprema je bila podedovana od predhodnika. Razvojne ekipe so uporabljale razline sisteme enot in niso bile usklajene. Testiranje ni bilo zadostno. 3. Kateri je glavni kriterij uspenosti programskih produktov? Programska reitev je lahko uspena e: je zakljuen razvoj je uporabna je uporabljena 4.Navedi vsaj 5 (od 8) smernic inenirskega pristopa v razvoju produktov. Ocenjevanje strokov/vlokov Doloitev faz v razvoju Spremljanje napredovanja projekta Doloitev konnih produktov Obseno testiranje 5. Opii vlogo projektnega vodje in njegove izzive. Upotevanje uporabnikov (nejasno definirane zaheve,enostavnost uporabe) Upotevanje lanov razvojnega tima (pozornost posveena nainu razvoja) Upotevanje managementa (ekonomska uspenost, povrnitev vlokov, asovni rok)

6. Kaj razumemo pod etino odgovornostjo programskega inenirja? Programski inenir ima ire odgovornosti kot le uporabo tehninega znanja: Zaupnost. Spotovanje zaupnosti in varovanje podatkov delodajalcev in strank. Kompetence. Spotovanje nivoja svojih pristojnosti. Intelektualne pravice. Varovanje intelektualnih pravic delodajalca, strank in partnerjev. Zlorabe. Raunalnikov in tehninih znanj se ne sme zlorabljati. Obseg zlorab je irok od nameanja neodobrenih programov na slubeni raunalnik ali igranja iger, do razirjanja virusov in vdorov v siteme. 7. Katere lastnosti morajo biti doloene za vsak korak programskega procesa? mora imeti jasno zastavljene cilje zahteva ljudi s specifinimi znanji temelji na jasnih vhodnih parametrih rezultira v dobro definiranih izhodnih rezultatih definiran je as zaetka ter as konca uporablja specifine tehnike, orodja, smernice, dogovore, standarde Mora biti izvren po projektnem planu, ki doloa trajanje, sredstva (resources), omejitve Dajati mora informacije za vodstvo (management), ki omogoa korektivne Korak se kona z pregledom (Verifikacija & Validacija): Verifikacija preveri konsistentnost izhodnih rezultatov z vhodnimi parametri Validacija preveri konsistentnost s potrebami uporabnika

8. Natej faze programskega procesa. Definicija problema tudija izvedljivosti Analiza in definiranje zahtev Nartovanje sistema Nartovanje programa Izvedba Testiranje Prevzem in izdaja Obratovanje in vzdrevanje

9. Kaken je namen definicije problema in na katera tiri vpraanja je potrebno odgovoriti v tem koraku programskega procesa? 4 vpraanja (Uporabnik in menadment se morejo strinjati, izogibati dvoumnosti): Kaj je problem? Kje se problem pojavi in kdo ga obuti? Zakaj se problem sploh pojavi? Kako se problem lahko natanneje razie? Rezultat definicije problema je dokument - opis problema (1-2 strani): naziv projekta, jedrnat opis problema, cilji projekta, morebitne zaetne ideje o monih reitvah, potreben as in stroki za naslednji korak tudijo izvedljivosti, groba ocena celotnih strokov projekta. 10. Na katera tri temeljna vpraanja mora odgovoriti tudija izvedljivosti? Ali je projekt tehnino izvedljiv? Ali je projekt ekonomsko upravien? Ali je projekt operativno izvedljiv (zakoni, kultura, dogovori)? 11.Kaken je namen analize in definiranja zahtev? Rezultat je specifikacija zahtev - popoln opis obnaanja sistema: Analizo in definiranje zahtev izvaja sistemski analitik. Napana, nepopolna nekonsistentna ali dvoumna specifikacija zahtev so pogosto vzrok za neuspeh projektov in spore. 12.Kakne lastnosti morajo imeti zahteve navedene v specifikaciji zahtev? Uvod (namen, obseg, definicije, reference na druge dokumente) Sploni opis (relacije z drugimi sistemi, pregled funkcij/komponent, znailnosti 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 nartovanju (standardi, omejitve strojne opreme) Ostale zahteve 13.Natej prednosti formalnih programskih procesov (vsaj 5 od 8). Bolji nadzor nad sredstvi. Bolji odnos s stranko. Kraji as razvoja. Niji stroki. Vija kvaliteta in zanesljivost.

14. Opii linearni model razvoja programskih produktov ter opii njegove prednosti in slabosti.

Faze si sledijo ena za drugo in se ne prekrivajo. Naslednja faza se zane po zakljueni predhodni fazi. Vsaka faza se zaklji s pregledom oziroma testiranjem. Moen le v primeru dobro doloenih zahtev/ciljev in jasnega naina izvedbe, saj je upotevanje kasnejih sprememb teavno. Zahteva potrpljenje stranke delujoa verzija ji je na voljo ele ob predaji konnega produkta. V praksi ele vsak naslednji korak omogoa ire/bolje razumevanje prejnjih faz, zato so pogosto nujne revizije predhodnih korakov Linearni model tega ne omogoa Prednosti: preglednost, loenost faz, stalen nadzor nad kvaliteto, dober nadzor nad stroki. 15. Kaken je lahko namen izgradnje prototipov programskih produktov. Prvotni namen prototipa je pomo stranki in razvijalcem pri razumevanju zahtev sistema. Uporabniki lahko preverijo kako se odraajo njihove zahteve. Prototip razkrije napake in manjkajoe zahteve. 16.Kakne so prednosti izgradnje prototipov programskih produktov in kakni so lahko njihovi negativni vplivi na konni programski produkt? Razvoj prototipov lahko razumemo kot aktivnost zmanjevanja rizika pri specificiranju zahtev. Prototip je na voljo zgodaj v programskem procesu in lahko slui tudi za usposabljanje uporabnikov in testiranje sistemov. PREDNOSTI: Hitra dobava. Vasih je bolj pomembna od funkcionalnosti ali od monosti dolgoronega vzdrevanja. Vkljuenost uporabnika poveuje verjetnost, da sistem ustreza uporabnikovim potrebam, hkrati pa poveuje verjetnost uporabe sistema. SLABOSTI: Obstojei procesi managementa predpostavljajo linearni model. Razvoj prototipa zahteva dodatne sposobnosti razvijalcev. Teavnost vzdrevanja. Neprestano spreminjanje negativno vpliva na strukturo sistema, zato je dolgorono vzdrevanje teavno.

17.V em se prototipi programskih produktov razlikujejo od konnih programskih produktov? Prototipi obiajno ne ustrezajo nefunkcijskim zahtevam Prototip je nedokumentiran. Arhitektura/struktura prototipa ni namenjena kasnejemu Pri razvoju prototipa se pogosto/veinoma ne upoteva obiajnih standardov kakovosti! 18.Opii spiralni model razvoja programskih produktov. Vsak cikel vsebuje faze linearnega modela. V vsakem ciklu se izdela prototip. Vsak cikel sestoji iz tirih kvadrantov: Doloitev ciljev, alternativ in omejitev. Ocenjevanje alternativ, identifikacija tveganj. Razvoj produkta trenutnega cikla. Nartovanje naslednjega cikla. 19.Kakni so temeljni principi agilnih pristopov razvoja programskih produktov? Razdelitev funkcionalnosti na majhne neodvisne sklope. Spremembe zahtev so dobrodole, etudi pozno. Dnevno sodelovanje tehninega in poslovnega osebja. Neposredna vkljuenost predstavnika stranke v tim. Najbolja je osebna komunikacija (na tiri oi) Projekti naj temeljijo na motiviranih posameznik, ki jim je potrebno zaupati. Enostavnost je vrednota Timi naj se ogranizirajo sami 20. Opii ekstremno programiranje Potek: Doloitev zgodb (ang. stories) - lastnosti, ki jih eli stranka/uporabniki. Ocena trajanja in strokov 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.Zaetna - uspenost odvisna od posameznikov. 2.Ponovljiva - osnovno vodenje projektov. Proces je mogoe ponoviti na podobnih projektih. 3.Doloena 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 uspenosti projekta in s tem porgramskega procesa. 5.Optimirana stalno izboljevanje programskih procesov na podlagi kazalcev uspenosti, novih idej in tehnologij.

24. Navedi vsaj pet tipinih razlogov za neuspeh programskih projektov! Slaba kvaliteta - razviti sistem vsebuje napake Nedoseganje kljunih rokov (as dobave) Preseganje omejenih strokov Nezadovoljevanje uporabnikovih potreb Nezmonost ali teavnost vzdrevanja Cena razvoja in vzdrevanja je bistveno vija od priakovane (ocenjene) slabo razumevanje uporabnikovih potreb nezadostno tehnino znanje lanov razvojnega tima Nerealna priakovanja Politini razlogi 25. Kaken je namen projektnega vodenja? Namen je vzpostavljanje okolja, ki bo privedlo do realizacije projekta, v skladu z zahtevami in omejitvami. Vodenje poteka na ve podrojih Poslovno vodenje Tehnino vodenje Procesno vodenje Vodenje ljudi 26. Na kaken nain lahko skrajamo trajanje projekta (navedi tri naine). Projekt lahko skrajamo le s skrajanjem trajanja aktivnosti na kritini poti. Dodajanje zmogljivosti kritinim aktivnostim? Alternativne reitve (nakup kompenent, outsourcing...) 27.Opii 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 okoliin: Preobrat Stuffa: Stuff bo prenehal preden se bo konal 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) Izkunje iz podroja dela Izkunje so bistvene za efektiven razvoj programov. Inenirji, ki poznajo podroje dela so obajno najbolj produktivni. Kvaliteta programskega procesa Ustreznost in kvaliteta programskega procesa bistveno vpliva na produktivnost. Velikost projekta Veji projekti zahtevajo ve asa za komunikacijo znotraj skupine. Manj asa je na voljo za razvoj, kar zmanja produktivnost. Tehnologija Uporaba primernih orodij (npr. CASE) vpliva na vejo produktivnost. Delovno okolje Tiho delovno okolje, ki nudi doloeno stopnjo zasebnosti ter loeni prostori za debate in sestanke prispevajo k veji produktivnosti. 30.Opii kako je organizirana skupina glavnega programerja. Kakne so prednosti in slabosti takne organizacije skupine? Skupino vodi glavni programer, ki prevzema vse naloge nartovanja in izvedbe. Pri opravljanju nalog mu pomagajo lani skupine. V primeru njegove odsotnosti vodilno vlogo prevzame namestnik. Vsakrna (dalja) odsotnost glavnega programerja lahko povzroi neuspeh projekta. Vloga glavnega programerja je zahtevna in ustrezen kader redek. 31.Natej vsaj 5 vlog projektnega vodje! Vodenje Organizacija Komunikacija Finance Team building Pohvale in nagrajevanje Grajanje in kaznovanje 32.Opii lastnosti, ki naj bi jih imel idealni projektni vodja. Oseba, ki ve kaj bo lo narobe e preden do tega dejansko pride. Potrebne so izkunje. Pomagajo podatki predhodnih projektov.

33. Opii potek izoblikovanja skupin. 1.Organizacija in informiranje seznanjanje z nalogo in nainom dela. 2.Nastanek konfliktov zaetek dela, neskladja v smeri iskanj areitev. 3.Sodelovanje izoblikovanje skupinskih norm. 4.Stabilizacija skupina je optimalna za izvajanje svojih nalog. 34.Katere lastnosti so pomembne pri izbiri lanov projektne skupine? Izkunje iz podroja dela zelo pomembno, vsaj kateri od lanov. Izkunje iz razvojne platforme manj pomembno. Izkunje iz programskega jezika pomembno le kratkotrajno. Sposobnost reevanja problemov kljuno za inenirsko delo. Izobrazba izkazuje sposobnosti uenja. Komunikacijske sposobnosti pomembno za delovanje skupine. Prilagodljivost pomembna za reevanje zelo razlinih problemov. Odnos do dela zelo pomemben pozitiven odnos do dela in pripravljenost za dodatno uenje. Osebnostne lastnosti teko oceniti, lani skupine morajo biti zdruljivi. 35. Kaj je kontekstualni diagram? Katere elemente prikazuje? Doloa obseg sistema - doloa 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.Opii razlike med implicitnimi in eksplicitnimi modeli. Implicitni modeli: - Implicitni modeli niso ubesedeni. - Implicitni modeli se s asom spreminjajo. - Naronik in sistemski analitik ne govorita istega jezika. - Vsega implicitnega znanja se ne da fomralno zapisati. 37. Navedi vsaj pet primerov nefunkcijskih zahtev. - Monost testiranja - monost vzdrevanja - razirljivost - uporabljivost - varnost 38. Navedi naine seznanjanja s problemom in zbiranja zahtev (vsaj 5)! - tudij literature - Nasveti strokovnjakov - Spraevanje - Izpeljave iz obstojeega 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.Kaken je namen analize zahtev? (Kakna vpraanja si zastavljamo za dosego cilja?) Ali je vsaka od zahtev skladna s cilji novega sistema? Ali je vsaka zahteva resnino 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 tehnino 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 obsene procese, od zaetka do konca uporabe. Z njim uporabnik dosee nek cilj. Za definiranje primerov uporabe je potrebno razumevanje zahtev. Primer uporabe doloimo za vsak dogodek sistema. Podrobno jih opiemo z opisom primera uporabe in ilustriramo z diagramom primera uporabe

42. Opii vsebino opisa primera uporabe. Naziv primera uporabe Akterji: navedba vseh udeleenih akterjev. Zahteve: zahteve povezane s primerom uporabe (tudi vir zahteve). Triger: vzrok za zaetek aktivnosti. Osnovni potek: tok aktivnosti za obiajno uspeno interakcijo seznam korakov. Zane se ob trigerju in kona ob uspenem zakljuku. Stanje po zakljuku Priakovan rezultat primera uporabe. Alternativni poteki: opisujejo ostale mone uspene in neuspene poteke, kot tok aktivnosti podan s seznamom korakov. Zaejo in konajo 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 vkljuuje nartovanje sistema? (vsaj 6 od 8) Nartovanje sistema je aktivnost s katero preslikamo model specifikacije zahtev v nartovalski model sistema Nartovanje sistema vkljuuje: definicijo nartovalskih ciljev, dekompozicijo sistema na podsisteme, izbiro e izdelanih komponent, relacije med podsistemi (programsko opremo) in strojno opremo, izbira infrastrukture za upravljanje s persistentnimi podatki, doloitev politike nadzora dostopa, izbira mehanizma globalnega kontrolnega toka, obravnavanje mejnih primerov. 45. Kaj razume pod pojmom povezanost podsistemov? Kakne vrste povezanosti pozna? Povezanost govori o odvisnosti med dvema podsistemoma. e sta dva podsistema mono povezana, bodo imele spremembe enega od podsistemov vpliv na delovanje drugega podsistema. Zaeljeno je, da so podsistemi povezani kar se da ibko (S tem je doseen manji vpliv napak in sprememb enega podsistema na delovanje drugega podsistema). Loimo ve tipov povezanosti: Content - ko ena komponenta "tajno" spremeni interni podatek druge komponente Common - kadar se uporabljajo globalne spremenljivke Control - e ena procedura klie drugo proceduro z navedbo ukaza, ki eksplicitno doloa 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 knjinic Routine Call - kadar ena rutina (oz. metoda v OO sistemu) klie drugo Type use - kadar modul uporablja podatkovni tip doloen v drugem modulu

46. Kaj razume pod pojmom kohezija podsistemov Kakne vrste kohezije Kohezija govori o notranji povezanosti znotraj podsistema. Kohezija je velika, e podsistem zdruuje medseboj odvisne oz. povezane komponente ter ne vsebuje ostalih, nepovezanih komponent. Zaeljena je velika kohezija podsistema, kajti takni podsistemi so laji za razumevanje in spreminjanje. Loimo ve tipov kohezije: Functional - doseena takrat, kadar je zdruena vsa koda, namenjena pridobivanju doloenega rezultata, ostala koda pa ni vkljuena Layer - v sloj je zdrueno vse potrebno za zagotavljanje oz. dostopanje do mnoice povezanih storitev Communicational - vsi moduli, ki dostopajo oz. uporabljajo doloene podatke so zdrueni (npr. v en razred), vse ostalo ni vkljueno. Sequential - zdruene so procedure v katerih ena procedura priskrbi vhodne podatke za drugo proceduro, vse ostalo ni vkljueno Procedural - zdruene so procedure, ki so uporabljene ena za drugo Temporal - zdruene so operacije, ki se izvajajo v isti fazi izvajanja programa, vse ostalo ni vkljueno Utility - zdruene so operacije, ki ne morejo biti logino vkljuene v ostale kohezivne enote 47.Kaj so arhitekturni vzorci? Navedi primer. Vzorec je: Dokumentacija reitve ponavljajoega se problema. Reitev je vekrat preizkuena in splono priznana. Reitev podaja nain reevanja, ne pa neposredne reitve, ki je odvisna od dejanskega reevanega problema. 48.Natej vsaj 4 skupine nartovalskih ciljev in za vsako podaj primer. V splonem lahko nartovalske cilje izberemo iz seznama splono eljenih kvalitet programskih produktov, ki jih uredimo v pet skupin: uinkovitost - odzivni as, prepustnost, pomnilnik zanesljivost - robustnost, zanseljivost, razpololjivost, odpornost, cena - cena razvoja, namestitve, nadgradnje, vzdrevanja, administriranja zmonost vzdrevanja - razirljivostm spremenljivost, prilagodljivost, prenosljivost, itljivost uporabnike zahteve - koristnost, uporabnost 50.Kaken je lahko namen dedovanja? Dedovanje se uporablja za doseganje dveh razlinih ciljev: Razvranje razredov v skupine (taksonomija) Uporablja se v fazi analize zahtev Za identifikacijo objektov, ki so medsebojno hierarhino odvisni. Pripomore k razumljivosti modelov. Ponovna uporaba Uporablja se v fazi nartovanja objektov. Pripomore k monosti uporabe obstojeih objektov ter monosti njihovega spreminjanja in rezirjanja

51.Kakne prednosti ima delegiranje pred dedovanjem? Delegiranje + Fleksibilnost + Omogoeno za vse programske jezike - Slaba uinkovitost, 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 nartovanju programov? Navedi tri primere! Odvisnost je prisotna, e sprememba enega elementa programa lahko zahteva spremembo nekega drugega elementa programa. Odvisnost je glavni vir teav pri vzdrevanju programskih produktov. Pri nartovanju teimo k im manji odvisnosti Dinamina 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. aritmetina omejitev vsota vseh kotov trikotnika je vedno enaka 180 stopinj. Statina... 53.Kaj je Liskov princip zamenjave? Razred S ustreza razredu T, e je mogoe 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 stalia 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 zaokroanja elementov z doloanjem abstrakcije, ki doloa strukturo in obnaanje elementov. Ovijanje slui za loevanje pogodbenih vmesnikov (doloenih z abstrakcijo) od implementacije. 55.Kaj je kohezija razreda? Kakne kohezije si elimo? Meri medsebijno povezanost metod zunanjega vmesnika razreda. Kako zakljueno 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 izboljanje z loitvijo v dva razreda.

56. Kakne prednosti prinaa modularnost? Modularen program sestoji iz dobro definiranih, konceptualno enostavnih in neodvisnih enot modulov, ki komunicirajo preko dobro definiranih vmesnikov. Prednosti modularnosti enostavneje razumevanje in razlaganje, enostavneje dokumentiranje, enostavneje spreminjanje, enostavneje testiranje in razhroevanje, enostavneje nastavljanje. 57. Kaj so nartovalski vzorci? Kako delimo nartovalske vzorce? Navedi primer nartovalskega vzorca. Nartovalski vzorci so: Elegantna reitev, ki zaetnikom ni samoumevna. Neodvisni od sistema, programskega jezika ali domene aplikacije. Dokazano uspeni v realnih OO sistemih. Enostavni, vsebujejo le nekaj razredov. Vekrat uporabni in na tak sploen nain tudi dokumentirani. Doloa jih: Ime vzorca Problem nartovalski vzorci vsebujejo opis problema, za katerega je primerno uporabiti vzorec. Reitev nartovalski vzorci podajajo elemente in njihove medsebojne relacije, ki tvorijo reitev problema. Posledice rezultati in posledice uporabe nartovalskega vzorca. Delitev: Glede na namen: Kreacijski - Doloajo proces kreiranja objektov Strukturni - Doloajo kompozicijo razredov in objektov Vedenjski - Doloajo nain interakcije med razredi in porazdelitev odgovornosti. Glede na podroje delovanja: Razredni - Vzorec se ukvarja z razredi in njihovimi medsebojnimi relacijami, ki so doloene z dedovanjem in so statine. Objektni - Vzorec se ukvarja z relacijami med objekti, ki so dinamine in se lahko spreminjajo v asu izvajanja. 58.Kakne principe pri nartovanju grafinih uporabnikih vmesnikov pozna? Principi pri nartovanju 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 nain razumevanja sveta. Ljudje izoblikujemo miselne modele preko izkuenj, vzgoje, olanja, navodil Miselni modeli so v principu pogosto napani, a kljub temu efektivni Pri razvoju programskih produktov se ukvarjamo z ve modeli: Implementacijski model Sistemski model Uporabniki miselni model Primer pravilnost/efektivnost: Raunalniki zaslon: mnogi uporabniki vidijo zaslon kot centralni in bistveni del raunalnika. Nepravilen a efektiven miselni model. 60.Kakna je razlika med funkcijskimi in strukturnimi mentalnimi modeli? Funkcijski - Vedenje o tem KAKO, ne pa tudi ZAKAJ. (Primer: ugaanje PC pred izklopom) Strukturni - Razumevanje komponent in njihove medsebojne odvisnosti (ZAKAJ) - Omogoa reevanje problemov! 61.Kaj je konceptualni model? Uporabniki miselni modeli niso neposredno pod nadzorom nartovalca sistema. Uporabniki miselni model, kakrnega 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 nartovanju GUI)? Navedi primer! Ali je uporaba metafor vedno smiselna? Metafore v primeru uporabnikih vmesnikov tipino poudarjajo podobnosti z realnim svetom oziroma obstojeimi konceptualnimi modeli. Primeri metafor: Namizje (ang. desktop metaphor) : inbox, folder, trash... Spletne trgovine: nakupovalni voziek, blagajna... Uporabljene so le bistvene lastnosti (npr. pri nakupovalnem voziku nas ne zanima njegova velikost). Pretirano izkrivljanje uporabnikega vmesnika ni priporoljivo. Koristno je uporabiti le tiste lastnosti, ki prispevajo k enostavnosti in razumljivosti. Namesto pretiranega izkrivljanja uporabnikega vmesnika z metaforami je priporoeno idiomatino nartovanje. Idiomatino nartovanje uporaba novih simbolov, ki se jih je potrebno nauiti in postanejo znailni za doloene objekte, lastnosti.

63.Navedi primer evidentne funkcionalnosti povezanih z GUI! Evidentna funkcionlnost (affordance) je bistveno pomembneja kot uporabnika navodila uporabniku postane nain dela evidenten e iz predmeta samega (npr. iz izgleda uporabnikega vmesnika). Primeri: Kodak DC-290: evidentno nakazano kako naj uporabnik dri fotoaparat, 3D gumb: Samoumevno kae na monost, da ga pritisnemo! 64.Opii princip povratnih informacij pri nartovanju GUI! Posredovanje povratnih informacij nazaj uporabniku: Katera aktivnost se je dejansko izvedla / se izvaja. Kakni so rezultati predhodne aktivnosti. Povratne informacije morajo biti pravoasne! Primeri: Tipkovnice bi lahko bile povsem tihe, pa vendar uporabniki ob pritisku tipke priakujemo klik. Premikanje mike po zaslonu. Kadar je sistem prezaposlen in mika zaostaja, je uporabnikom neudobno. 65.Na kaken nain lahko omejitve koristijo uporabnikim vmesnikom? Navedi primer! Omejitve predstavljajo nain za olajanje interakcije uporabnika s sistemom. Omejitve so lahko fizine, semantine, kulturne, logine. Omejitve lahko omejujejo uporabo doloenih aktivnosti: Doloene aktivnosti ne smejo biti izvedene. Doloene aktivnosti morajo biti izvedene. Z omejitvami lahko podrobneje doloimo uporabnikove monosti, npr. pri vnosu podatkov. Omejitev monosti 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. Kakne so prednosti in slabosti obeh? Digitalna predstavitev Kompakten prikaz zavzame malo prostora. Podajanje natannih vrednosti Analogna predstavitev Hitro podajanje priblinih vrednosti. Monost podajanja relativnih vrednosti Bolja indikacija izjemnih vrednosti

67. Za kaj naj bi se uporabljala pogovorna okna? Kakne 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 priporoljivo izogibati. Primarna interakcija s sistemom naj se dogaja v primarnem oknu, ne v pogovornih oknih. Loimo tiri 4 tipe pogovornih oken: Lastnosti uporabniku predstavi lastnosti (znailnosti) 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 doloen as ni sposoben normalno odzivati Zahtevana pogovorna okna so lahko velika in na zaslonu dominantna. Nezahtevana pogovorna okna naj bodo manja in nevsiljiva. Pogovorna okna imajo prehoden znaaj. Nezahtevanim pogovornim oknom se je potrebno izogibati. 68.Kaj razumemo pod pojmoma prepad izvajanja in prepad vrednotenja? Ko uporabnik eli opraviti doloeno nalogo, se sreamo s tremi aktivnostmi. Doloanje ciljev kaj uporabnik eli, kaj priakuje od naprave in kaken je njegov namen Izvajanje kako uporabnik dosee cilje z uporabo dane naprave? Vrednotenje kako uporabnik ve ali je dosegel zastavljene cilje? Sreamo se z dvema razkorakoma med elenim in dejanskim obnaanjem 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 priakovanja. 69.Katere lastnosti so pomembne pri vrednotenju GUI? as uenja koliko asa potrebuje uporabnik, da je zmoen uinkovito uporabljati sistem. Hitrost dela kako se hitrost odzivanja sistema sklada z uporabnikovimi potrebami oziroma navadami. Robustnost kako toleranten je sistem do uporabnikih napak. Prilagodljivost kako mono je sistem vezan na en sam nain uporabe. Zanesljivost kakna je pogogstost napak v delovanju sistema. Uporabniko zadovoljstvo subjektivno mneneje uporabnikov glede uporabe sistema. Ponavljajoe operacije pogostost uporabe posameznih ukazov uporabnikega vmesnika 70.Opii razliko med verifikacijo in validacijo. Verifikacija Posamezne komponente so testirane glede na skladnost s specifikacijami programa Posamezne komponente so zdruene v programski sistem in testirane glede na specifikacije sistema Validacija Poteka po vnaprej pripravljenem nartu, ki izhaja iz specifikacij zahtev. Preverja se skladnost sistema z zahtevami

71.Navedi nekaj napotkov udeleencem recenzij (recenzentom in/ali avtorjem)! Pozitiven pristop recenzentov: Sprauj namesto da graja. Npr. namesto Tu nisi upoteval standardov! uporabi Kaken je razlog za uporabo uporabljenega pristopa? Izogibaj se vpraanjem tipa Zakaj. Npr. namesto Zakaj tukaj nisi upoteval standardov? uporabi Kaken je razlog za odstopanje od standardov... Ne pozabi na pohvalo. Pomembno je opaziti tudi pozitivno, npr. kreativne reitve. To avtorju da vedeti, da njegovo delo vidimo ire 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 mona (dobra) reitev. eprav je avtor nekaj naredil drugae 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 monosti boljih reitev Naredi seznam stvari na katere se bodo osredotoili recenzenti. S seznamom ponovno preglej svoje delo in popravi morebitne najdene napake. S tem bo ne le zmanjal tevilo najdenih napak, pa a tudi skrajal as revizije. Pomagaj vzdrevati standarde. Ponudi dopolnitev standardov za tisto, karje bilo dogovorjeno in ni vkljueno v obstojee standarde. Na ta nain dokumentirana reitev bo v pomo pri naslednjih delih in recenzijah. 72. Kaj pomeni, e je testiranje uspeno? Test je uspeen, 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. Kakna 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.Opii 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 ciklomatine kompleksnosti - mere logine kompleksnosti programa. Izraun ciklomatine kompleksnosti V(G) na osnovi grafa izvajanja G: V(G) = tevilo enostavnih odloitev + 1 V(G) = tevilo vsebovanih podroij grafa + 1 Za nartovanje osnovnih poti ne potrebuje grafa, res pa ta olaja sledenje potem. Clikomatino kompleksnost doloi s tetjem enostavnih loginih odloitev. Kompleksne odloitve se teje za dve ali ve enostavnih. Testiranje osnovnih poti je posebno pomembno pri kritinih modulih.

75. Kaj je ciklomatina kompleksnost? tevilo neodvisnih poti je odvisno od ciklomatine kompleksnosti - mere logine kompleksnosti programa. 76.Kaj so ekvivalentne particije ? Ekvivalentne particije je postopek za doloanje razredov vhodnih podatkov iz katerih izberemo testne podatke. Ekvivalentni razred je skupina veljavnih ali neveljavnih vhodnih pogojev. Glede na doloitev vhodnih pogojev doloimo ekvivalentne razrede na naslednji nain: Vhodni pogoj je doloen s podrojem doloi en veljaven in dva neveljavna ekvivalentna razreda. Vhodni pogoj je specifina vrednost - doloi en veljaven in dva neveljavna ekvivalentna razreda. Vhodni pogoj je doloen s pripadnostjo mnoici - doloi en veljaven in en neveljaven ekvivalentni razred. Vhodni pogoj je logina vrednost (ang. boolean) - doloi en veljaven in en neveljaven ekvivalentni razred.

77.Opii test enote Obsega testiranje posameznih komponent oziroma enot . Testiranje temelji na izvorni kodi (strukturno testiranje / white-box) Tipino je test enote odgovornost razvijalca. Izvedba testa je odvisna od izkuenj razvijalca. Za testiranje enote pripravimo testni gonilnik (ang. driver). e enota uporablja druge enote, le te v im veji meri nadomestimo z 78.Opii eno od strategij integracijskega testiranja. Testiranje skupine komponent, ki so zdruene v sistem ali podsistem. Odgovornost neodvisne testne skupine. Testiranje temelji na specifikacijah sistema vedenjsko testiranje (black-box). Glavna teava je lokalizacija napak, ki jo je mogoe reevati z inkrementalno integracijo. 79.Kako poteka testiranje pritiska in kako vrednotimo rezultate? Testiranje sistema ob obremenitvi veji od najveje nartovane. Pogosto pokae 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. Natej vsaj 4 dokumente, ki jih za dokumentiranje testiranja predlaga standard IEEE 829! Standard IEEE 829 doloa skupino priporoil za dokumentiranje testiranja programskih produktov. IEEE 829 doloa osem razlinih dokumentov, ki pokrivajo tri korake testiranja: Priprava na testiranje Izvajanje testiranja Zakljuek testiranja IEEE 829 je dobro izhodie za doloitev 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: Nart testiranja (ang. test plan) Nart poteka testiranja. Okvirno doloa 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 doloitev testov vkljno s priakovanimi razultati. Specifikacija testnih primerov (ang. test case specification) Doloitev testnih primerov s testnimi podatki. Testni postopek (ang. test procedure) Opis praktine izvedbe testiranja. Poroilo 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. Poroilo testnih incidentov (ang. test incident report) Seznam dogodkov, ki jih je potrebno dodatno raziskati in njihovim detajlnim opisom Zakljuek testiranja: Poroilo testiranja (ang. test summary report) Povzetek testiranja in sklep o rezultatu testiranja. 81. Kaken je namen vzdrevanja programskih produktov? Katere tiri vrste sprememb vkljuuje vzdrevanje? Vzdrevanje pomeni spremembe programskega produkta po izdaji z namenom: odpravljanja napak, izboljanja zmogljivosti prilagoditve produkta spremenjenemu okolju. prilagajanje novim zahtevam V veini primerov je izhodie obstojei produkt, ki mu dodajamo nove funkcionalnosti. Gre za neskladje z linearnim modelom.Vzdrevanje je kljuno za ohranjanje uporabe produkta! Vrste sprememb: Korektivne spremembe odpravljanje napak. Adaptivne spremembe prilagajanje spremenjenim pogojem. Perfektivne spremembe izboljanje programskega produkta. Preventivne spremembe odpravljanje poslabevanja programskega produkta.

83. O em govorijo Lehmanovi zakoni? Predstavi enega izmed Lehmanovih zakonov! Meir Manny Lehman je glede na potrebo po vzdrevanju 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 reitvi 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 slabe zadovoljujejo potrebe uporabnikov. Odstopanje med sistemom in njegovim podrojem delovanja ustvarja povratno zanko, ki spodbuja spreminjanje sistema. 6) Zakon o stalni rasti e elimo ohranjati zadovoljstvo uporabnikov, se morajo funkcijske zmonosti programskega produkta ves as ivljenjske dobe poveevati. Vsaki izvedbi sistema je zahteve potrebno omejiti. Izpuene ali prezrte lastnosti bodo sproile nadaljnje zahteve po spremembah. To je povratna zanka od uporabnikov. 2) Zakon o poveevanju kompleksnosti Z razvojem (spreminjanjem) sistema se kompleksnost sistema poveuje, razen e se kompleksnosti z dodatnim vloenim delom ne zmanjuje. e se spreminjanje sistema dogaja brez premisleka o njegovi strukturi, se kompleksnost sistema poveuje in oteuje 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 manja. 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 mnoici predpostavk in ne glede na njihovo veljavnost v doloenem trenutku, bo spreminjajoi svet na njih vplival v smeri njihovega zavraanja. 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 prili z bolj svee formuliranimi predpostavkami. 85. Kaj razumemo pod pojmom upravljanje konfiguracij? Vsak programski projekt proizvede veliko razlinih 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 nain delovanja sistemov za nadzor verzij! Copy-modify-merge Lock - modify - unlock

87.emu sluijo vejitve pri uporavljanju konfiguracij? Vejitev pomeni istoasni 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. Kakna je povezava med avtorskimi pravicami in licennimi pogodbami? Lastnik programskega produkta ima doloene ekskluzivne pravice. Osnovne so avtorske pravice , ki lastniku dajejo pravice: lastne uporabe produkta, doloanja kako je produkt lahko uporabljen, doloanja kdo lahko uporablja produkt, doloanja kdo lahko produkt spremeni, doloanja 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 licenne pogodbe. Nakup licence ne pomeni nakupa programskega produkta, pa pa le nakup omejenega nabora pravic za uporabo produkta.