SKUSKA

Question 1

Meranie softvéru - základný princíp

Answer 1

Meranie je niečo, čo nedostaneme priamo jednoduchým kliknutím na tlačidlo vo zvolenom
IDEčku. Pri meraní si musíme najprv zvoliť dáta, nad ktorými budeme meranie vykonávať.
Výsledok, kt získame v procese merania závisí od voľby dát, ktorá by mala reflektovať naše
porozumenie programu. Hlavný cieľ merania je
* znížiť počet ľudí potrebných na vývoj SW
* šetriť čas
* šetriť personál
* šetriť ďalšie požiadavky potrebné pri vývoji

Question 2

Rozdieľ medzi validáciou a verifikáciou

Answer 2

Validácia je overenie, či je program užitočný pre používateľa.
Verifikácia je overenie, či program správne spĺňa požiadavky definované v počiatočnej fáze
vývoja softvéru.

Question 3

Modelovanie a čo je za tým

Answer 3

Pri modelovaní riešime 3 základné otázky
* ako sa má systém správať v skutočnosti
* ako sa má správať model
* čo by malo byť v kóde.
Model je všetko s výnimkou toho, čo nemôže byť formalizované. Model v reálnom svete zahŕňa požiadavky na funkcionalitu alebo na použiteľnosť softvéru v konečnom svete.

Question 4

Limity modelovania

Answer 4

Nie všetko môže byť zahrnuté do modelu. Model má určité pragmatické, teoretické
a technické limity.

Nie všetko, čo chceme modelovať, musí byť modelované.
Existujú morálne, ekonomické, sociálne a politické limity.

Question 5

Návrh softvéru a problémy spojené s ním

Answer 5

Softvérové inžinierstvo je o určitom stúpajúcom leveli abstrakcie. Základnou otázkou
v počiatočnej fáze návrhu softvéru je, či skutočne rozumieme doméne v kt projekt ideme
vyvíjať. Medzi metódy a teórie zaoberajúcu sa počiatočnou fázou návrhu sw patrí
* doménové inžinierstvo – zaoberá sa opisom domény
* inžinierstvo požiadaviek – zaoberá sa opisom požiadaviek
* dizajn
Problémy spojené so softvérovým inžinierstvom sú:
* Je vyvíjaný program spustiteľný - prenesenie teoretických algoritmov do
„počítačového sveta“?
* Materializácia plánu v určitom smere
* Testovanie - pretože náš plánovaný vývoj môže zlyhať
Problémy spojené s evolúciou softvéru
* Nevyvíja sa samotný softvér, ale vyvíja sa naše porozumenie problému. Na počiatku
máme určitý model, z ktorého sa vyvíja zdrojový kód. Zdrojový kód musí spĺňať
požiadavky hardvéru. Z kódu je vybudovaný mentálny model – jeho úlohou je
zjednodušiť porozumenie softvéru
Withov zákon: Rýchlosť softvéru sa spomaľuje rýchlejšie ako stúpa rýchlosť hardvéru.
Moorov zákon: Počet tranzistorov v integrovanom obvode mikroprocesora sa zdvojnásobuje
každých 18 mesiacov.
Gateov zákon: Rýchlosťsoftvéru sa zdvojnásobuje každých 18 mesiacov.
Niektoré iné problémy spojené so softvérovým inžinierstvom
* Problém zastavenie programu
* Godelov teorém
Niekedy si nemôžeme dovoliťriešiť problém algoritmicky
* Problém triedenia, Hanoiskych veží, šach
* Problémy zaberajúce exponenciálny čas
Niekedy skrátka len nevieme ako
* Problém obchodného cestujúceho, problém plánovania
* P=NP problém
Softvér je súčasťou každej civilizácie a života v intersticiálnom priestore. Komplexnosť
softvérových systémov v súčasnosti narastá – komplexnosť softvéru ovplyvňujepoužívateľov
ale aj vývojárov a všetkých, ktorý sa na vývoji softvéru podieľajú.

Question 6

Inžinierstvo softvéru a ostatné typy „inžinierstva“

Answer 6

História softvérového inžinierstva je o stúpajúcom leveli abstrakcie. Softvérové inžinierstvo
preniká do všetkých oblasti života, preto je ťažké pre softvérových inžinierov dobre rozumieť
doméne, v ktorej sa chystajú pracovať. Nerozumieme dobre doméne? Použijeme správnu
literatúru alebo vhodný web.
Ostatne typy inžiniestrva sú:
* doménové inžinerstvo a opis domény
* inžinerstvo požiadaviek a charakteristika požiadaviek
* dizajn

Question 7

Evolúcia, údržba a pochopenie softvéru

Answer 7

Evolúcia softvéru je fáza vo vývoji softvéru, kedy sa softvér používa, prispôsobuje novým
požiadavkám, ktoré sú doňho zaimplementovavané. Pochopenie softvéru znamená
pochopenie jeho funkcionality. Pochopenie softvéru je individuálna úloha. Softvérový inžinier
pri nej využíva rôzne pomocné nástroje nato aby si túto úlohu uľahčil.

Question 8

Komplexnosť softvéru

Answer 8

Programátori sú stále obklopení komplexnosťou softvéru, nedokážu sa jej vyhnúť.
Navrhované aplikácie sú komplexné lebo programátori sú ambiciózni pri používanie pc
a používajú ich čoraz viac sofistikovaným spôsobom.

Question 9

Pochopenie, algoritmizácia a programovanie

Answer 9

Počiatočná práca programátora spočíva v pochopení problému, ktorý sa chystá riešiť jeho
program. Pochopenie programu je pre riešenie problému kľúčové. Často sa stáva, že
programátor nevie naprogramovať riešenie nejakej úlohy, to ale neznamená, že neexistuje
algoritmus, ktorý daný problémrieši. Algoritmus je overený matematický postup na riešenie
daného programu. Programovanie je prevedenie tohto matematického postupu do
konkrétneho programovacieho jazyka.

Question 10

Úplnosť súboru požiadaviek

Answer 10

Veľa vývojárov by chcelo aby boli požiadavky na výsledný produkt kompletné. Úplné
požiadavky ale nie je možné skonštruovať. Aj v najlepšom prípade sú požiadavky len
približné.

Question 11

Lehmanove pravidlá evolúcie softvéru - o zmenách

Answer 11

Softvér typu E je pravidelne používaný, teda musí byť pravidelne apdejtovaný aby bol
progresívny a uspokojoval požiadavky používateľov

Question 12

Lehmanove pravidlá evolúcie softvéru - o komplexnosti

Answer 12

Pri vývoji softvéru typu E sa jeho komplexnosť (zložitosť) zvyšuje ak sa úmyselné nepracuje na
jej udržaní alebo na jej znižovaní.

Question 13

Lehmanove pravidlá evolúcie softvéru - o samoregulácii

Answer 13

Softvér typu E má vlastnosť samoregulácie.

Question 14

Lehmanove pravidlá evolúcie softvéru - o stabilite

Answer 14

Miera globálnej aktivity v rozvíjajúcom sa systéme typu E ma tendenciu zostať konštantná
počas celej životnosti produktu.

Question 15

Lehmanove pravidlá evolúcie softvéru - o raste kvality

Answer 15

Funkčný obsah softvéru typu E sa musí vo svojom životnom cykle pravidelne zvyšovať tak,
aby viac a viac uspokojoval potreby zákazníka.

Question 16

Lehmanove pravidlá evolúcie softvéru - o znižovaní kvality

Answer 16

Kvalita softvéru typu E bude klesať, ak nebude pravidelne prispôsobovaná zmenám
v operačných systémoch.

Question 17

GQM

Answer 17

Metóda GQM (Goals, questions, metrics – metóda cieľov, otázok a metrik) pozostáva zo 6
krokov. Prvé 3 kroky súvisia s obchodnými cieľmi
1. Nastaviť projektové ciele tak, aby sa zabezpečila kvalita výsledného produktu
2. Položiť si otázky (v závislosti od modelu), ktoré budú definovať ciele tak špecificky ako to
je možné
3. Špecifikovať vlastnosti produktu, ktoré budú merané v úmysle dosiahnutia kvality
výsledného produktu
Ďalšie 3 kroky opisujú spôsob ako zbierať dáta a vyvíjať dáta v úmysle vhodne sa rozhodnúť
4. Vypracovať metódu na zber dát
5. Zberať a analyzovať dáta realtimovo s ohľadom na softvérový vývoj
6. Analyzovať obdŕžaný výsledok po ukončení projektu v záujme zabezpečiť lepší vývoj
v budúcnosti
Ciele GQM metódy:
1. Definovať ciele a úmysel projektu
2. Rozdeliť špecifikáciu na otázky
3. Vybrať vhodnúmetriku
Atribúty merajú to, čo chceme merať, metriky merajú to, čo sa môže merať.

Question 18

Demeterin zákon

Answer 18

Demeterin zákon je jednoduché pravidlo pre návrh objektovo orientovaných systémov. Jeho
znenie je:
Metóda f (function) triedy C (Class) by mala volať len
* Metódy rovnakej triedy C
* Metódy objektov vytvorených metódou f
* Metódy objektov predaných ako argument metóde f
* Metódy objektov, ktoré sú inštančnoupremennou triedy C

Question 19

Spojenie (coupling)

Answer 19

História nejakej triedy je definovaná ako prvok <t,s>, kde každý prvok (každý objekt) má
v konkrétnom čase t konkrétny stav s. Zmena prvku t1 spojeného v histórii s iným prvkom t2
spôsoby zmenu iného prvku v histórii.
Ak dve objekty spolu spolupracujú, potom je hodnota spojenia u oboch zvýšená o 1. To však
nie je závisle na aktuálnych volaniach medziobjektmipočas spustenia programu.
Rozlišujeme:
* CBO (Coupling between objects) – trieda je spojená s inou triedou ak používa jej
metódy alebo atribúry, alebo ak používa metódy alebo atribúty jej rodiča
* NFMA(Number of forgein methohds accessed)- trieda je spojená s inou triedou ak
používa jej metódy alebo atribúry, ale nie ak používa metódy alebo atribúty jej rodiča
* Optimálne spojenie (optimal coupling) – spojenie používané v AI
* RFC (Response set for a class)- RFC je množina metód, kt môžu byť volané priamo
z danej metódy. Nezahrňuje sa dedičstvo a nepriame volanie metód.
* TCOF (Total coupling factor)-súčet spojení medzi triedami v danom balíku

Question 20

Súdržnosť (cohesion)

Answer 20

Súdržnosť je doplnkom k spojeniu. Popisuje úroveň sémantického spojenia jednotlivých
prvkov. Vysoká súdržnosť je znakom toho, že jednotlivé prvky sú na sebe veľmi závislé. Ak
trieda nie je súdržná je náročná na údržbu.

Question 21

Čo je testovanie?

Answer 21

Testovanie je proces spúšťania programov s cieľom odhalenia chýb v nich.

Question 22

Kedy testovať softvér a kedy iný produkt?

Answer 22

Testovanie je časť vývoja programu, ktorá nemôže byť automatizovaná. Testovanie by malo
prebiehať počas celého vývoja programu, tak aby sa skrátil jeho vývoj. V tom sa vývoj
softvéru líši od vývoja ostatných inžinierskych produktov, kde fáza testovania prebieha
výhradne po fáze produkcie.

Question 23

Matematická notácia pre testovanie

Answer 23

Definujeme funkciu y=f(x) a program p, ktorého vstup je x a na výstupe poskytne riešenie
funkcie f(x). Nech d=(d1,d2,…dn), kde di
je množina dát na vstupe do programu p. Môžeme
povedať, že program p je správny, z pohľadu funkcie f, keď pre každý vstup di
i=1,2…n platí
p(di)=f. Zápis p(di)=f znamená, že program p nad vstupom di realizuje výpočet popísaný
funkciou f. Tato funkcia sa týka správnosti výpočtu.

Ak nedokážeme nájsť takú množinu dát di ktorá je validná (takže platí p(di)≠f), potom
program p je chybný. Ak vieme dokázať, že pre každý validný vstup dj z množiny di platí, že
p(di)=fpotom je program validný. V skutočnosti je nemožné nájsť funkciu f pre všetky vstupy,
len pre validné vstupy.

Question 24

Nedostatok, zlyhanie, chyba

Answer 24

Nedostatok (fault) je slabosť v návrhu alebo implementácii, ktorá môže viesť k zlyhaniu
programu. Nedostatok je najčastejšie spôsobený nedostatočným pochopením problému,
ktorý program rieši.
Zlyhanie (failure) je neschopnosť systému alebo komponentu systému vykonať výpočet daný
funkciou podľa špecifikovaných požiadaviek.
Chyba (error) nastáva pri nezhode medzi výstupom, ktorý bol vyprodukovaný programom
a výstupom, ktorý bol pozorovaný, alebo meraný v skutočnom svete.

Question 25

Testovanie – biela skrinka (white box)

Answer 25

Testovanie bielou skrinkou je testovanie z vnútra. Aplikujeme pri ňom naše znalosti ohľadom
kódu v závislosti od návrhu systému a systémových požiadaviek, popísaných v špecifikácii
programu. Ide o verifikáciu programu. (skrátka vidíme zdrojový kód, takže podľa neho vieme
prísť na to, čo a ako testovať)

Question 26

Testovanie – čierna skrinka (black box)

Answer 26

Testovanie čiernou skrinkou je testovanie z vonku programu, bez akýchkoľvek znalosti o kóde
len na základe požiadaviek v špecifikácii (tieto požiadavky sú často charakterizované len na
užívateľskom leveli). Ide o verifikáciu aj validáciu programu. (skrátka nevidíme zdrojový kód,
takže nevieme otestovať všetky jeho vetvy, testujeme len na základe špecifikácie, čo približne
má robiť program)

Question 27

Testovanie – sivá skrinka (gray box)

Answer 27

Testovanie metodou sivej skrinky je kombináciou testovania bielej skrinky a testovania
čiernej skrinky. Cieľom tohto testovania je nájsť prípadné chyby v kóde v dôsledku
nesprávnej štruktúry alebo nesprávneho použitia aplikácii. Pri testovaní pomocou sivej
skrinky tester sčasti pozná internú štruktúru aplikácie, ktorá zahŕňa dokumentáciu, interné
dáta a používané algoritmy.
Testovanie pomocou sivej skrinky si vyžaduje znalosť vysokého levelu testovania a detailnej
dokumentácie aplikácie, ktorá bude využitá pri definovaní jednotlivých testov.

Question 28

Pochopenie programu, pomocné nástroje

Answer 28

Pochopenie programu znamená pochopenie jeho funkcionality. Pochopenie programu je
individuálna úloha. Softvérový inžinier pri nej využíva rôzne pomocné nástroje nato aby si
túto úlohu uľahčil.

Question 29

Architektúra testovania

Answer 29

Testovanie by malo byť systematizované a prebiehať podľa presne stanoveného postupu.

Review a testovanie môže zmeniť náš pohľad na systém samotný. Jadrom vývoja programu je
rýchla reakcia a porozumenie programu. Evolúcia je pomalá reakcia.

Question 30

Testvér

Answer 30

Testvér je program, ktorý slúži na testovanie programu. Testvér pozostáva z blackbox testov,
gray box testov a white box testov v samostatných moduloch programu. Tester využíva
moduly v testvéry na otestovanie funkcionality programu.

Question 31

Dokumentácia k testovaniu

Answer 31

Dokumentácia k testovaniu pozostáva z
* subjektu testovania alebo jeho časti
* cieľov testovania = objektu testovania
* metód testovania = procedúr testovania
* testovacích dát = vstupov a očakávaných výstupov
* výsledku testovania = skutočne vyprodukovaného výstupu
* verdiktu testovania = vyjadrenie sa k výsledku testovania (bolo úspešné/neúspešne)
s ohľadom na testované dáta
Dokumentácia k testovaniu často pozostáva z rôznych screenshotov.

Question 32

Zmeny v softvéri

Answer 32

Zmeny v softvéry môžu byť
* nevyhnutné zmeny
o nové požiadavky od zákazníka
o prispôsobovanie sa buisiness prostrediu
o oprava chýb
o prispôsobovanie sa novému hardwaru
o zlepšovanie výkonu sw
Pokiaľ sa rozhodujeme pre zmeny v sw, stále si je potrebné položiť otázku či je výhodnejšie
softvér meniť alebo vyvinúť nový softvér.

Question 33

Život softvéru

Answer 33

Život softvéru pozostáva ztýchto fáz:
vývoj softvéru → evolúcia softvéru → údržba softvéru → dôchodok softvéru
vývoj softvéru – fáza, kedy sa softvér formuje, vyvíja
evolúcia softvéru – fáza, kedy sa softvér používa, prispôsobuje novým požiadavkám, ktoré sú
doňho zaimplementovavané
údržba softvéru -fáza kedy sa softvér už nepospôsobuje novým požiadavkám, nepridáva sa
nová funkcionalita, len sa opravujú staré chyby
fáza dôchodku– konečná fáza, softvér sa stále používa ale nie su v ňom žiadne zmeny

Question 34

Proces evolúcie (implementácia zmien)

Answer 34

OBR

Question 35

Evolúcia v agilných metódach vývoja softvéru

Answer 35

Evolúcia je kontinuálne vylepšovanie vyvíjaného programu v závislosti na systéme.
Základným princípom evolúcie systému je automatizované regresné testovanie.
Základným princípom dokumentácie programu sú užívateľské príbehy (user stories), ktoré sú
vyjadrenímzmeny v systéme.

Question 36

Staré/Zastaralé systémy, problémy

Answer 36

Systém je zastaraný vtedy, ak je jeho základom technológia, ktorá už ďalej nie je používaná,
alebo ak je napišaný v programovacom jazyku, ktorý sa už ďalej nepoužíva. Zastarané
systémy často využívajú zastarané hardvérové riešenia, procesy a procedúry (zastarané
technologické systémy, zastaraný hardvér, softvér, zastarané knižnice alebo procesy).

Question 37

Prvky starších systémov

Answer 37

OBR

Question 38

Stratégie evolúcie starších a zastaralých systémov

Answer 38

• systém nízkej kvality a nízkej obchodnej hodnoty => scrap
• systém nízkej kvality a vysokej obchodnej hodnoty => nahradí sa
• systém vysokej kvality a nízkej obchodnej hodnoty => nahradí sa s COTS, udržiava sa
  alebo sa vyvíja
• systém vysokej kvality a vysokej obchodnej hodnoty => používa sa, udržiava sa alebo
  sa mení ak je to možné

Question 39

Meranie starších a zastaralých systémov

Answer 39

Pri meraní je potrebné rozlišovať pojmy:
* údržba = zmena používateľského softvéru
* evolúcia = zmena generického softvéru
Typy údržby softvéru
* oprava chýb softvéru
* prispôsobovanie prostrediu
* úprava funkcionality
* pridanie novej funkcionality do softvéru

Question 40

Typy údržby

Answer 40

oprava chýb softvéru
* prispôsobovanie prostrediu
* úprava funkcionality
* pridanie novej funkcionality do softvéru

Question 41

Predikcia údržby, predikcia zmien

Answer 41

Predikcia údržby pozostáva z
* zistenia, ktorá časť systému môže spôsobiť problémy alebo zistenie, ktorá časť
systému je najnáročnejšia na údržbu
* komplexnýchmetrík
* procesných metrík
Predikcia zmien
* predikcia zmien hovorí o počte zmien v programe a o porozumení vzťahov medzi
systémom a vývojovým prostredím
* úzko prepojené systémy sú také systémy, pri ktorých zmene dochádza aj k zmenám
v prostredí

Question 42

Reengineering, prerábanie softvéru

Answer 42

Reengineering je nahradzovanie alebo prepísanie časti kódu novou časťou kódu bez zmeny
funkcionality. Je akceptovaný v úseku kódu, ktorého údržba nie je náročná. Reengineering
robí softvér ľahšie udržateľný, redukuje jeho cenu a riziko výskytu chýb v softvéry.

Question 43

Refaktorizácia ako forma údržby

Answer 43

Refaktorízácia je proces, ktorý pokračuje v priebehu vývoja aj evolúcie. Je to zmena kódu, bez
zmeny štruktúry, degradácie kódu a zmeny funkcionality kódu.

Question 44

Zapáchajúce nedostatky - bad smells

Answer 44

• duplicita v kóde
• dlhé metódy
• switche
• nahromadzovanie dát
• nič nehovoriace úseky kódu

Question 45

Testovanie použiteľnosti

Answer 45

Testovanie použiteľnosti je testovanie, ktorého cieľom je určiť do akej miery je softvér
zrozumiteľný, ľahko naučiteľný, ľahkou používateľný a zaujímavý pre používateľov ak ho
používajú podľa špecifikovaných podmienok.

Question 46

Constantine-ov zákon

Answer 46

Štruktúra kódu je stála vtedy ak je súdržnosť (cohesion) kódu vysoká a spojenie (coupling)
nízky. Súdržnosť pojednáva o komunikácii vnútri modulu a spojenie o komunikácii medzi
modulmi.

Question 47

Mooreov zákon

Answer 47

Každých 18 mesiacov sa počet čipov v integrovanom obvode zdvojuje.

Question 48

Zelený softvér

Answer 48

Ciele:
* vyvíjaťhardware, ktorý šetrí energiu
* vyvíjaťsoftware, ktorý šetrí energiou
* šetriť energiu pomocou umiestnenia hardwaru
K vývoju softvéru, ktorý je skutočne zelený potrebujeme
* vyvinúťnový pracujúci hardware
* vyvinúť energicky efektívny softvér
* učiť užívateľov šetriť energiu pri používaní softvéru
* uistiť sa, že energiu, ktorú používame je skutočne zelená

Question 49

Invazívne meranie spotreby

Answer 49

invazívne => zasahujeme do kódu,

1. rozbehnutie white-box testy na pozícii v kóde o ktorej vieme, že spôsobuje nadmernú
   spotrebu energie. Po rozbehaní určitého minimálneho počtu testov, môžeme stanoviť,
   vykonanie ktorého testu zabralo najviac energie.
2. vyžaduje si pridanie príkazov do kódu, ktorými sa spustí/zastaví meranie

Question 50

Neinvazívne meranie spotreby

Answer 50

invazívne => nezasahujeme do kódu,

1. Meriame spotrebu energie systému s a bez spustenej aplikácie. Po vykonaní štatisticky
   vhodného merania, môžemvykonať výpočet spotreby pre spustenú aplikáciu
2. Zaznačíme spotrebu energie programom na hosťujúcom systéme pomocou známych
   procesov. Potom pozorujeme správanie zvoleného procesu na hosťovskom PC.
   Nameraná hodnota je značí spotrebu energie CPU, spotrebu energie pamäťou atď.

Question 51

Produktové línie

Answer 51

Pod pojmom produktová línia rozumieme viacero produktov, ktoré majú mnohé svoje súčasti
podobné ale odlišujú sa len v istých aspektoch. Ako jednoduché kritérium pre produktovú
líniu by sme mohli povedať, že dva produkty sú súčasťou produktovej línie ak zdieľajú
približne 80% zdrojového kódu. Príkladom produktovej línie je napríklad softvér pre
automobil, ktorý môže fungovať stále rovnako, no variabilita jeho správania spočíva napr.
v rôznej klimatizácii, GPS, elektrických oknách…
Pre produktové línie je dôležité zabezpečiť možnosť uchovania konfigurácie konkrétneho
produktu a taktiež možnosť aktualizovať produkt na základe nových verzií jednotlivých
komponentov, ktoré tvoria danú konfiguráciu.

Question 52

Znovupoužitie artefaktov pri evolúcii na úrovni komponentov

Question 53

Znovupoužitie artefaktov pri evolúcii na úrovni aplikácií

Question 54

Softvér typu E

Answer 54

(evolution-based) je softvér, kt implementuje počítačové aplikácie z reálneho
sveta. Tento softvér musí byť súvisle vyvíjaný tak, aby spĺňal užívateľove požiadavky počas
niekoľkých rokov požívania a niekoľkých releasov.

Question 55

Softvér typu P

Question 56

Softvér typu S

Answer 56

(specification-based) je softvér, kt implementuje počítačové aplikácie zo
špecifického sveta, napr. riešenie rovníc vo fyzike, matematický softvér na riešenie
diferenciálnych rovníc…

Question 57

Ciele profilácie softvéru

Question 58

Invazívne postupy profilácie

Question 59

Neinvazívne postupy profilácie

Question 60

Správa a plánovanie verzií softvéru

Question 61

Balenie komponentov pri ich znovupoužití

Question 62

Balenie aplikácií pri ich znovupoužití

Question 63

Evolúcia integrovaných systémov

Question 64

Evolúcia vnorených systémov