Tarkvaratehnika kordamisküsimused (0)

TARKVARATEHNIKA  KORDAMISKÜSIMUSED 
  
1. Mis on tarkvaratehnika? 
Software  engineering  
 
! ​
“Engineers Australia” definitsioon: ​
Tarkvaratehnika ​
on ti mide poolt rakendatav distsipli n 
tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefekti vset  tarkvara  mis rahuldab 
kasutajate nõudmisi ja mida saab hooldada teatud ajaperioodi vältel. 
 
IEEE definitsioon: Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava 
lähehemisvi si rakendamine tarkvara arendamisele, käitamisele ja hooldamisele, see 
tähendab, inseneriteaduste rakendamine tarkvarale.  
 
Tarkvaraarendus  ​
on nõrgem termin, kus tingimata ei kasutata protsesse, tööri stu, 
standardeid, jne. Tarkvaraarendus on progemine + konfigursatsiooni haldus. 
 
Tarkvaratehnika ei ole ainult programmi kirjutamine, vaid teemad hõlmavad ka kvaliteeti, 
ajakavasid, tasuvust ning põhimõtete ja korra tundmist ja rakendamist.  
 
Tarkvaratehnikas hal atakse ja kontrol itakse: 
● Kvaliteeti  
● Keerukust  
● Ressursse: eelarvet, aega, inimesi  
● Riske 
 
! ​
Tarkvaratehnika e. tarkvara  inseneeria  on ​
professionaalsele tarkvaraarendusele suunatud 
distsipli n​
, mis tegeleb sel ega, ​
kuidas organiseerida tarkvaraarendust  
 
2. Miks vajame tarkvaratehnikat?  
Kõrgenenud nõudmised tarkvara arendamisele 
● suuremad süsteemid  
● keerulisemad süsteemid;  
● ki remini.  
 
Suuremastaabiline programmeerimine vrdl väiksemastaabiline programmeerimine. 
Näiteks: 
● Asjalik mees või naine suudab ehitada tööri stakuuri oma maja või suvila juurde. Kas 
seesama inimene saab hakkama ka 30­ korruselise kontorihoone püstipanekuga?  
● Insener suudab valmis programmeerida lihtsa kontrol eri. Kas seesama insener saab 
hakkama ka lennuli kluse kontrol süsteemi programmeerimisega? 
 
3. Milleks tarkvaratehnika?  
Tarkvara tööstuse kri s 1965 ­ 1985 (tarkvara arenduse edukus): 
 
 
Terminit „tarkvaratehnika“ (software engineering) kasutati esimest korda NATO Software 
Engineering Conference 1968 raames GarmishPartenkirchenis, Saksamaal. 
See oli mõeldud ühe ideena (tarkvaratehnika kui distsipli n), kuidas tul a toime 
tarkvaratööstuse kri siga. 
 
4. Tarkvaratehnika „point“?  
● Tarkvaratehnika = tarkvara ​
inseneeria​
. 
● Tarkvaratehnika on suunatud ​
professionaalsele ​
tarkvaraarendusele (on olemas ka 
personaalne tarkvaraarendus ­ sel ega ei tegele). 
● Tarkvaratehnika ei tegele  tarkvaraarenduse  endaga (nt programmeerimiskeeled, 
algoritmid ) vaid sel ega, ​
kuidas organiseerida​
 ­ tarkvaraarendust ehk kuidas erinevad 
blokid kokku panna, mitte et kuidas neid luua 
 
5. Mis on tarkvara(toode)?  
! ​
Tarkvaratooted koosnevad valjatöötatud programmidest ja nende dokumentatsioonist.  
 
! Tarkvaratoode on alati osa mingist laiemast sotsiotehnilisest  süsteemist . 
 
6. Kvaliteetse tarkvara atribuudid.  
● Evib nõutud funktsionaalsust 
● Hooldatav 
○ Tarkvara peab arenema, et vastata muutuvatele vajadustele. Tuleb arvestada 
tarkvara loomise protsessis, et peab olema hooldatav.  
● Usaldusväärne  
○ Tarkvara peab olema töökindel  
● Efekti vne  
○ Tarkvara ei tohi raisata süsteemi ressursse  
● Vastuvõetav  
○ Tarkvara peab olema aktsepteeritud kasutajate poolt, kel e jaoks ta on 
loodud. See tähendab, et tarkvara peab olema arusaadav, kasutatav ja 
ühilduv teiste süsteemidega. 
○ Tarkvara peab rahuldama kliendi vajadusi. Kasutaja peab aru saama, mida 
tarkvara teeb (peab olema arusaadav).  
 
7. Tarkvaratehnika huvigrupid.  
●  Klient  ­ tel ija, nt mingi ettevõte 
●  Arendaja  
● Kasutaja 
1 
 
8. Tarkvaratehnika kui distsipliini eesmärgid.  
● Kuluefekti vne tarkvaraarendus ­ töö tuleb korraldada ni , et tuleb ots otsaga kokku 
● Tarkvaraarenduse organiseerimine kogu tarkvara elukaare ulatuses, arvestades 
organisatsiooniliste (inimeste) ja rahaliste pi rangutega ­ kuidas inimeste tööd 
organiseerida 
●  Hõlmata tarkvaraarenduse kõiki aspekte, mitte ainult tehnoloogiad!  
 
! ​
Tarkvaratehnika eesmärgiks on ​
kuluefekti vne​
 tarkvaraarendus ​
kogu tarkvara elukaare 
ulatuses.  
 
9. Tarkvaratehnika kontekst.  
● Tarkvaratehnika ei ole isoleeritud distsipli n vaid osa laiemast süsteemitehnikast. 
● Tarkvarasüsteemid ei ole isoleeritud süsteemid vaid sotsiaalsete süsteemide osad 
=> sotsiotehniline süsteem. 
 
Sotsiotehniline süsteem on tehniline süsteem, mis on pandud sotsiaalsesse konteksti ehk 
organisatsiooni kontektsti ning toetatab sel e organisatsiooni tööd, sel e organisatsiooni 
inimeste tööd ja protsesse sel es organisatsioonis. 
 
10. Mis on süsteem?  
● Süsteem on üksteisega ühendatud olemite (elementide) või komponentide hulk, mis 
moodustavad keerulise terviku või täidavad ​
koos​
 keerulist funktsiooni.  
● Süsteem võib sisaldada tarkvara, mehhaanilist, elektrilist ja elektroonilist ri stvara 
(tehniline pool süsteemist) ja ol a opereeritud inimeste poolt (sotsiaalne pool 
süsteemist). 
● Süsteemi komponentide omadused ja käitumine sõltuvad teistest süsteemi 
komponentidest. 
 
11. Süsteemi kategooriad ja nende seletused. 
1. Tehnilised süsteemid 
○ Süsteemid, mis sisaldavad ri st­ ja tarkvara ning kus kasutajaid ja 
kasutusprotsesse ei käsitleta süsteemi osadena. 
○ Tehniline süsteem ei ole iseendast teadlik. 
2. ! ​
Sotsio ­tehnilised süsteemid 
○ Süsteemid, mis sisaldavad ni  tehnilisi süsteeme kui ka inimesi, kes 
kasutavad tehnilisi süsteeme ja suhtlevad nendega ning kasutusprotsesse. 
○ Süsteem, mis koosneb ri stvarast, tarkvarast ja inimestest 
○ Sotsio­tehnilise süsteemi karakteristikud:   
■ Esilekerkiv käitumine: süsteemi kui terviku omadused sõltuvad 
süsteemi komponentidest ja seostest nende vahel 
■ Mittemääratud käitumine: süsteem ei anna alati sama väljundit sama 
sisendi puhul, sest et süsteemi käitumine sõltub inimoperaatoritest 
(inimestest) ning ri stvara, tarkvara ja andmete muudatustest.  
Me ei saa ennustada süsteemi käitumist. 
○ Sotsio­tehniliste süsteemide “kihiline tort”: 
2 
 
 
Küsimus: Mis on sotsio­tehniline süsteem? Mis on sotsio­tehnilise süsteemi erinevus 
tehnilisest süsteemist? 
 
12. Mis on süsteemitehnika?  
● Sotsio­tehniliste süsteemide spetsifitseerimise, kavandamise, realiseerimise, 
valideerimise, instal eerimise ja hooldamise protsess.  
● Sel es kursuses pi rdume tarkvaratehnikaga, süsteemitehnikat ei käsitle. 
 
13. Millised on parimad tarkvaratehnika meetodid?  
Erinevat tüüpi meetodid erinevat li ki süsteemidele. Ei ole olemas parimat meetodit kõige 
jaoks. 
 
14. Tarkvararakenduse liigid.  
● Kohalikud ( stand ­alone)  rakendused , nt. MS Office ja fotode manipuleerimise 
süsteemid 
● Interakti vsed transaktsioonipõhised rakendused, nt. pangarakendused ja 
e­kaubanduse rakendused   
● Mähisrakendused (embedded control systems), nt. ABS­pidureid ja mikrolaineahju 
kontrol ivad süsteemid   
● Andmetöötlusrakendused (batch processing systems), nt. arvete ja palgaarvestuse 
süsteemid  Meelelahutusrakendused, nt. mängud   
● Model eerimis­ ja simulatsioonirakendused   
● Andmekogumisrakendused (data col ection systems), nt. keskkonna kohta andmeid 
koguvad süsteemid   
● Süsteemide süsteemid (systems of systems) 
 
15. Mis on protsess?  
! Protsess ​
on sammude jada, mis hõlmab tegevusi, pi ranguid ja ressursse mingit li ki tulemi 
loomiseks.  
 
Pi rangud ­ nt seadusandlusest tulenevad pi rangud, tehnikast endast tulenevad pi rangud 
(mida suudab teha, mida ei suuda teha). 
Ressursid  ­ nt inimesed, loodusressursid, arvutusressursid 
 
Näiteid protsessidest: 
3 
● Õppimine 
● Organisatsiooni äriprotsessid 
● E­pangas ülekande tegemine 
 
16. Mis on tarkvara arendusprotsess e. tarkvaraprotsess? 
! Tarkvaraprotsess ​
on sammude jada, mil e eesmärgiks on tarkvara loomine ja haldamine. 
Üldistatud tegevused tarkvaraprotsessides:  
● Spetsifitseerimine – mida süsteem peab tegema ja mis on pi rangud tema 
arendamisel?   
● Arendamine –  tarkvarasüsteemi  tootmine ( mõtleme  kodeerimist) 
●  Valideerimine  – kas toodetud tarkvarasüsteem on see, mida kasutaja soovis?   
●  Evolutsioon  – tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele 
nõudmistele 
 
Üldistatud ​
tähendab, et tegevused toimuvad mitmetest kohtades ja on hajutatud, nt 
erinevates iteratsioonides. Nt valideerimine ei toimu üks kord, toimub pidev 
ümberspetsifitseerimine, evolutsiooni osas on vaja live’s asju ümber teha vastavalt klientide 
vajadustele.  
 
!​
 Tarkvaraprotsess koosneb tegevustest, mis on vajalikud tarkvaratoodete  arendamiseks . 
Nende tegevuste ​
organiseerimisega ​
tegelebki tarkvaratehnika.  
 
17. Tarkvaraprotsessi mudel.  
● Tarkvaraprotsessi lihtsustatud esitus teatud vaatepunktist. 
○ Mudel on lihtsustatud esitus keerulisest asjast. 
● Näited vaatepunktidest:   
○ Tegevusekeskne (activity­centric) vaatepunkt: tegevuste jada. Nt BPM. 
○ Andmekeskne (data­centric) vaatepunkt: andmevood. Nt andmevoogude 
diagrammid. 
○ Rol ikeskne (role­centric või agent­centric) vaatepunkt: kes mida teeb?   
○ Tulemikeskne (product­centric) vaatepunkt: mis on iga tegevuse tulem? Ja 
kuidas see on sisendiks järgmisele tegevusele? 
 
18. Plaanipõhine vs  agiilne  tarkvaraprotsess.  
On olemas kahte li ki tarkvaraprotsesse: 
● Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu 
kriteeriumiks on plaani järgmine 
● Agi lne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus 
 
Ei saa öelda, et kumb on õigem. Oleneb sel est, mida luuakse ja konkreetsest rakendusest. 
Teatud li ki rakenduste puhul on õigustatud plaanipõhine protsess ­ nt missioonikri tilised 
rakendused. 
 
19. Tarkvaraprotsessi mudelite tüübid.  
! 
●  Kosk    
4 
● Iterati vne arendamine   
● Komponendipõhine arendamine 
 
Tegelikult on mudeleid veel, aga si n aines ei käsitle. 
 
 
 
20. Kirjelda Kose mudeli koos puudustega ja eelistega.  
 
Kõik sammud on järjest. 
 
Puudused:   
● Saab kasutada ainult si s, kui nõuded on fikseeritud   
● Iga tarkvaraprotsessi etapp peab olema lõpetatud enne kui alustatakse järgmist 
etappi    
● Kliendi tagasiside tuleb ainult lõpus. Si s enam ei saa või on kal is muudatusi teha. 
Eelised:   
● Plaanipärane arendus aitab koordineerida arendustööd suurte süsteemide loomisel, 
kui süsteemi arendatakse erinevates kohtades (nt maailma eripaikades). 
 
21. Mis on modifitseeritud kose mudel?  
5 
 
Nooled on mõlemas suunas. isegi kui asi on live’s, saab nõuete juurde tagasi tul a. Aga 
nende muutmisel tuleb jäl e kõik sammud sama kose mudeli alusel läbi käia. Ei ole pi savalt 
agi lne, iterati vne. 
 
22. Mis on  iteratiivne  arendamine? Eelised ja puudused?  
 
Agi lne on iterati vse arendamise üks alamli k. 
 
Eelised:   
● Klient saab anda tagasisidet kogu tarkvaraprotsessi jooksul   
● Kliendi tagasisidet on odavam arvestada – peab vähem ümber tegema   
● Klient saab hakata tarkvara varem kasutama   
Puudused:   
● Tarkvaraprotsess ei ole läbipaistev ega lõpuni dokumenteeritud 
● Tarkvarasüsteemi struktuur degradeerub ( entroopia  ehk korrastamatus suureneb ja 
vigade  arv kasvab) → tekib vajadus kasutada koodi refaktoreerimist! 
 
23. Mis on komponendipõhine tarkvaraarendus, puudused ja eelised? Mis tüübid on 
olemas?  
6 
 
 
Püüame valmisolevad osad kokku panna ja minimiseerida uute osade kirjutamist. 
Nõudeid muudame vastavalt sel ele, mil ised komponendid on saada. 
See võib ol a ni  kose mudelil põhinev kui ka iterati vne. 
 
Tarkvarakomponenttide tüübid: 
●  Veebiteenused  
● Objektiraamistike (nt .NET või J2EE) osad   
● COTS (Commercial­off­the­shelf) süsteemid 
 
Eelised:   
● Väiksemad riskid   
● Spetsialistide parem kasutamine   
● Parem vastavus standarditele   
● Ki rem arendusprotsess   
Puudused:   
● Suuremad hoolduskulud   
● Komponentide teegi ülalpidamine ­ sel eks on vaja eraldi metoodikat ja süsteeme, 
toob kaasa ka lisakulusid 
● Korduvkasutatavate komponentide leidmine, neist arusaamine ja nende 
kohandamine 
 
24. Mis on kõige parem tarkvaraprotsessi mudel?  
Ei saa välja tuua ühte kolmest mudelist, mis on kõige parem. 
 
25. Millist tarkvaraprotsessi mudelit kasutatakse kõige rohkem?  
Kõige rohkem kasutatakse  kombinatsiooni  erinevatest mudelitest. Puhtaid mudeleid väga ei 
kasutata, seega ei saa öelda, et ühte või teist kasutatakse kõige rohkem. 
 
26. Mis on tarkvaraarenduskulud? Kuidas nad jaotuvad?  
Koosnevad:   
● Arenduskulud   
● Evolutsiooni ja hoolduse kulud  
 
Kulud sõltuvad arendatava süsteemi tüübist ja süsteemile esitatud nõudmistest nagu näiteks 
jõudlus ja töökindlus. 
 
Tarkvarasüsteemi arendamise ja evolutsiooni kulude vahekord: 
7 
 
 
Evolutsioon on kõik, mis tuleb peale live’i andmist. 
 
Tarkvara ​
arenduskulude jaotus​
 sõltub arendatava süsteemi tüübist ja kasutatavast 
tarkvaraprotsessi mudelist  
● Pöidlareegel, mis näitab, kuidas arenduskulud sõltuvad arendatava süsteemi tüübist:  
 
● Tarkvara arenduskulude jaotuse sõltuvus kasutatavast tarkvaraprotsessi mudelist:  
 
 
27. Tarkvarainseneri professionaalsus.  
● Tarkvaratehnika on laiem pelgalt tehniliste oskuste rakendamisest   
● Tarkvarainsenerid peavad käituma ausal ja eetiliselt vastutustundlikul vi sil, kui 
soovivad ol a respekteeritud professionaalidena   
● Eetiline käitumine on rohkem kui pelgalt seaduste järgimine 
 
28. Inimloomus ja eetika.  
Filosoofiliselt on 2 koolkonda: 
1. Need, kes arvavad, et ​
inimene on loomult hea​
. Inimene teeb halba (nt 
massihävitusrelvade valmistamine, häkkimine jmt), kuna inimene ei tea, et tal e 
endale kasulik tegevus on ühiskonnale halb. 
8 
2. Need, kes arvavad, et ​
inimene on loomult halb​
. On 2 võimalust, kuidas halva 
tegemist vältida: 
○ Eetikakoodeksid ­ tarkvaratehnikas pannakse paika eetika reeglid 
tarkvaratehnika professionaali jaoks (vt järgmine punkt vastutuse aspektid) 
○  
 
29. Tarkvarainseneri professionaalse vastutuse aspektid.  
! ​
Tarkvarainseneril on ​
eetilised  kohustused​
, mis ei pi rdu vaid tehniliste oskuste 
rakendamisega. 
 
● Konfidentsiaalsus   
○ Tarkvarainsener peab respekteerima oma tööandja ja klientide 
konfidentsiaalsust, sõltumata sel est, kas formaalne leping konfidentsiaalsuse 
kohta on al a kirjutatud   
●  Kompetents    
○ Tarkvarainsener ei tohi anda väära ettekujutust oma kompetentsist. Ta ei tohi 
võtta teadlikult vastu tööd, mis on väljaspool tema kompetentsi 
● Intel ektuaalne omand   
○ Tarkvarainsener peab olema teadlik kohalikest seadustest ja määrustest, mis 
sätestavad intel ektuaalse omandi kasutamise näiteks patentide ja 
kopeerimisõiguse näol. Ta peab olema ettevaatlik, et tööandjate ja klientide 
intel ektuaalne omand oleks kaitstud 
● Arvuti väärkasutus   
○ Tarkvarainsener ei tohi kasutada oma tehnilisi oskusi teiste inimeste arvutite 
väärkasutamiseks. Väärkasutus katab vahemiku suhteliselt triviaalsest 
(näiteks mängude mängimine tööandja arvutil) kuni äärmiselt tõsiseni (vi ruste 
levitamine ja teiste arvutite ründamine) 
 
30. ACM/IEEE eetikakoodid ja printsiibid ning nende seletused.  
ACM ja IEEE li kmed al kirjastavad li tumisel vastava organisatsiooni eetikakoodeksi. 
Eetikakoodeks sisaldab kaheksat põhimõtet professionaalsete tarkvarainseneride käitumise 
ja otsustuste jaoks. 
 
8 printsi pi: eetikakoodeksist: 
● PUBLIC   
○ Software engineers shal  act consistently with the public interest.   
●  CLIENT  AND EMPLOYER   
○ Software engineers shal  act in a manner that is in the best interests of their 
client and employer consistent with the public interest.   
● PRODUCT   
○ Software engineers shal  ensure that their products and related modifications 
meet the highest professional standards possible. 
● JUDGMENT   
○ Software engineers shal  maintain integrity and independence in their 
professional judgment.   
● MANAGEMENT   
9 
○ Software engineering managers and leaders shal  subscribe to and promote 
an ethical approach to the management of software  development  and 
maintenance. 
● PROFESSION   
○ Software engineers shal  advance the integrity and reputation of the 
profession consistent with the public interest. 
● COLLEAGUES   
○ Software engineers shal  be fair to and supportive of their col eagues.   
● SELF   
○ Software engineers shal  participate in lifelong learning regarding the practice 
of their profession and shal  promote an ethical approach to the practice of 
the profession. 
 
31. Eetilised dilemmad.  
Tuleb ette teatud olukordi, kus tuleb teha valikuid. Näiteid: 
● Põhimõtteline mittenõustumine firma juhtkonna poli tikaga?   
● Sinu tööandja käitub ebaeetilisel vi sil väljastades ohutuskri tilise süsteemi ilma seda 
testimata?   
● Osalemine massihävitusrelvade või tuumarelvade valjatöötamisel? 
 
32. Eetiliste dilemmade põhipunktid.  
 
 
33. Tarkvara nõuete koostamise tehnikad ja lähenemised. ( Requirements  Engineering)  
! ​
Enne kui hakata kui tarkvara kirjutama, tuleks läbi mõelda ja esitada nõuded süsteemile. 
Enne kui nõudeid kirjutama hakata, tuleb esitada ​
domain ​
 ehk valdkonna mudel. 
 
! ​
Nõuded tuleb esitada mõõdetaval kujul. 
 
Ärianalüütik saab info kliendilt/tel ijalt ja paneb sel e nõuete kujul kirja. Edasi lisab omapoolse 
info süsteemianalüütik (lisab süsteemi arhitektuuri). Lõpuks programmeerija kirjutab koodi. 
 
Kõigepealt  paneme kirja süsteemiga seotud mõisted ja si s saame kirja panna nõuded 
süsteemile. 
 
What is Requirements Engineering (RE) ? 
● The problem world & the machine solution 
○ To make sure a software solution “correctly” solves some realworld problem, 
we must first ful y understand and  define  ... 
– what ​
problem ​
needs  to be solved in the real world 
– the ​
context  ​
in which the problem arises 
○ Example: car control 
– Problem: manual handbrake release can be inconvenient in certain 
situations 
– Context: car driving, braking, driver ’s intent,  safety  rules, … 
● The scope of RE: the ​
WHY​
, WHAT and WHO dimensions 
10 
○ Miks küsimuste tuleb küsida analüütikul sel e pärast, et võib­ol a klient ei tea 
või ei oska ennast väljendada õigesti, et mida ta tegelikult tahab. 
●  Types  of statements involved: descriptive vs. prescriptive 
● Categories of requirements:  functional  vs. non­functional 
● The requirements lifecycle: actors, processes, products 
● Target qualities and defects to avoid 
● Types of software projects 
● Requirements in the software lifecycle 
● Relationship to other disciplines 
 
On as­is süsteem ja to­be süsteem. Üritame vi a as­is süsteemi paremasse olukorda. Nt 
kuidas vi a auto süsteem sel isesse olukorda, et ta saaks juhita li klusesse lasta? 
 
Kõiki nõudeid ei saa alati täita, kuna see võib ol a li ga kal is. Nõuded tuleb alati valideerida 
ka nt protsesijuhi või juhtidega, eriti si s kui analüüsis osaleb mõni töötaja ise. Tööötaja ei 
pruugi tahta või osata näha suuremat vaadet, eriti kui tegemist on töötajate optimeerimise 
projektiga. 
 
34. Millest koosneb tarkvara nõuded?  
! ​
Nõuded tuleks esitada mõõdetaval kujul. 
 
Nõuetel on klassifikatsioon soft ja  hard .  
Pehmed nõuded on halvad. Nt: Me tahame midagi paremat. Me tahame et ettevõtte kasum 
kasvaks. Me tahame, et me tarkvara oleks ki re. Süsteem peab olema turvaline. 
Pehmed nõuded ei ole mõõdetavad. 
 
Hard nõue ja mõõdetav: 
Tarkvara peab vastama 2  sekundiga . Turvalisus peab vastama ISKE standardi mingile 
konkreetsele levelile. 
 
EE näide analüüsi ja nõuete kohta: 
● Protsessi analüüs 
–AS­IS kaardistus ja TO­BE kirjeldamine (ei nimeta IT süsteeme) 
● Ärilised funktsionaalsed nõuded 
–Süsteem peab tegema … 
● Ärilised mittefunktsionaalsed nõuded 
–Peab teenindama 1000 üheaegset kasutajat 
–Peab olema kättesaadav välisvõrgus 
–Peab saama kasutada õues päikese käes 
● Süsteemsed mittefunktsionaalsed nõuded 
–Mil iseid tehnoloogiaid kasutame 
–Kuidas toimub logimine 
–Kuidas süsteemi konfigureeritakse 
 
35. Miks on vaja kirjutada nõuded?  
Why engineer requirements? 
11 
● The requirements problem: facts, data, citations 
● Role and stakes of Requirements Engineering   
 
Nõuete kaardistus ja süsteemi analüüs: 
! ​
Mil ist probleemi me sel e projektiga lahendame? 
Kui sel ele küsimusele pole selget ja ühelauselist vastust, si s projekt rohelist tuld  ei tohiks 
saada. 
 
Miks on EE­s nõuete kaardistus vajalik? 
• Suures ettevõttes vananeb ni  dokumentatsioon kui teadmus tohutu ki rusega 
•Segadused vastutusvaldkondades 
•Informatsiooni kogutakse „igaks juhuks“ 
•Tehakse poolikuid lahendusi 
•Dubleeriv aruandlus –vastukäivad tulemused 
•Andmete väärkasutus 
•„Nendega on pidev mure, ma teen ise“ ­sündroom 
 
 
 
36. Parimad praktikad nõuete kirjeldamiseks. Too näited.  
 
 
37. Tuleta meelde, mis maailma probleemid olid käsitletud. Ja mis lahendused arvutite 
poolt olid pakutud. Nimeta need ja seleta lahti. 
  
38. Nõuete esialgne definitsioon. Millised veel on nõuete definitsioonid?  
Esialgne definitsioon: 
 
Coordinated ​
set of ​
activities  ​
... 
–for ​
exploring, evaluating, documenting, consolidating, revising​
 and ​
adapting​
 the ​
objectives, 
capabilities, qualities, constraints​
 & ​
assumptions ​
on a software­intensive ​
system 
12 
– based  on ​
problems ​
raised by the system­​
as­is​
 and ​
opportunities ​
provided by new 
technologies 
 
Veel definitsioone: 
! ​
Requirements definition must say ... 
– ​
why ​
a new system is needed, based on current or foreseen conditions, 
– ​
what ​
system features wil  satisfy this context, 
– ​
how ​
the system is to be constructed 
RE is concerned with the real­world ​
goals ​
for, ​
functions  ​
of, ​
constraints ​
on software systems; 
and with their 
– ​
link  ​
to precise ​
specifications of software behavior​
, 
– ​
evolution ​
over time and families 
 
39. Mis vahe nende mõistete vahel on: Süsteemi nõuded ja tarkvara nõuded?  
 
Nt isesõitev auto ­ lisaks konkreetsele auto nõuetele tuleks vaadata laiemalt süsteemi, nt et 
mil eks iseseisvat autot üldse vaja on. 
Nõudeid tuleb vaadata laiemalt kui ainult tarkvara, st süsteemi tasemel. 
 
Kõige pealt on süsteemi nõuded ja süsteemi nõuetest tulevad tarkvara nõuded. 
 
Nt süsteem: lennujaama rongide juhtimissüsteem. Süsteemi taseme nõue/eesmärgiks on: 
Teenindada rohkem reisijaid/kliente. Li kumise aeg peab olema optimaalne, minimaalne. 
Tarkvara nõuded/eesmärgid nt: Kontrol ib rongide asetust. Hoiab rongi uksi kinn jne. 
 
40. Nõuete kolm mõõdikud koos seletustega.  
13 
 
Tuleb panna paika to­be süsteemi eesmärgid, sel est tulevad nõuded (sh pi rangud). 
Nt isesõitva auto puhul: ta peab täitma käsu, et sõita punktist A punkti B. 
Ta peab suutma endale valida parima tee ja peab li klema ohutult. 
Auto peab li kluseeskirjadest kinni pidama. 
Peab suutma ise parkida.  
 
Nõudeid tulevases süsteemi hakkavd täitma teatud agendid. Ni  kaua räägime eesmärkidest 
kuni ta ei ole omistatud agendile, kes hakkab seda eesmärki täitma (si s muutub nõudeks). 
 
 
14 
 
 
 
41. Types of statements involved: descriptive vs. Prescriptive  
15 
 
Descriptive ­ kirjeldav. 
Prescriptive ­ tulevikku vaatav, eesmärgipärane.  
 
! ​
Nõue on midagi, mida me veel ei oma ehk kuhu me tahame jõuda/midagi saavutada või 
mida me tahame hoida (nt hoiame süsteemi turvalise, et võõrad ei saaks andmetele ligi). 
 
Nt tarkvara nõue: Kui rongi ki rus on suurem kui 0, si s peavad olema rongi uksed kinni. 
Süsteemi nõue on: Rongiga sõitmine peab olema turvaline ­> Rongi uksed peavad olema 
kinni. 
So funktsionaalne nõue. 
 
42. Categories of requirements: functional vs. non­functional  
 
 
16 
Nt panga süsteemi funktsioonid: Laenu andmine. Konto avamine. Makse tegemine. 
Funktsionaalsed nõuded kirjeldavad funktsioonide täitmist. 
 
Mittefunktsionaalsed nõuded: ki rus (ajaline ja ruumiline, sh mälumaht), turvalisus (inimesed, 
andmekaitse), kvaliteedinõuded, … 
 
43. A taxonomy of non­functional requirements  
 
Ka välja töötamise nõuded on tähtsad. Üheks nõudeks võib ol a hind või nt välja töötamise 
aeg. 
Mittefunktsionaalne nõue on ka see, et  muudatuste  sisse vi mine peab olema lihtne (seda 
vaja arvestada tarkvara loomisel). Nt käibemaksu määr on täna 20% ­ halb võimalus on see 
väärtus koodi sisse kirjutada (kus seda kasutada on vaja). Õigem on teha andmebaasi väli ja 
muuta väärtust seal, kui seadusandlus muutub. 
Arhitektuursed nõuded. 
Nõue süsteemi instal imise kohta ­ need tuleb ka paika panna. 
Usabaility on mittefunktsionaalne nõue ­ nt erivajadustega inimesed peavad saama süsteemi 
kasutada. 
Süsteemi üleval oleku aeg ­ nt peab olema üleval 99%. Lepitakse kokku SLA­s (service level 
agreement) 
 
! ​
Nõuded peavad olema mõõdetavad ja testitavad. 
 
44. The requirements lifecycle: actors, processes, products  
 
 
45. The requirement engineering process  
17 
 
 
18 
 
 
 
19 
 
 
46. Requirement engineering: an iterative process  
 
Kogu protsess käib mitu korda läbi. 
 
47. Target qualities and defects to avoid  
20 
 
Kõik osapooled peavad olema rahuldatud ­ seda tuleb vaadata nõuete kirjeldamisel.. 
Osapoolteks on nt kasutajad, omanik/tel ija ja täidevi jad.  
 
! Nõudeid peab olema võimalik täita. 
Nt nõue: kui midagi tuleb rongi teele ette , si s rong peab seisma jääma. Seda ei saa täita, 
kuna rong ei saa koheselt seisma jääda ­ loodusseaduste vastane. 
Saab täita nõuet, et kui midagi tuleb rongi teele ette, si s peab hakkama rong kohe 
pidurdama. 
 
 
Enne kui hakkate programmerima, mõelge nõuded läbi. Ni  on palju odavam. 
 
48. Types of software projects  
 
21 
 
49. Requirements in the software lifecycle 
 
  
50. Relationship to other disciplines  
 
 
51. The requirements problem: facts, data, citations  
 
 
52. Role and stakes of requirement engineering.  
 
 
53. Obstacles to good requirements engineering practice.  
 
54. Millest koosneb tarkvarakvaliteet? Miks?  
Väga lühidalt on kvaliteet toote vastavus nõuetele.  
Keerukate toodete puhul tuleb vastavuse hindamisel arvesse võtta ka toote loomise 
protsessi. Seega seob kvaliteet ​
toote​
, nõuded tootele ja tootmise protsessi.  
Tarkvara kvaliteet = toode + nõuded + protsessid 
 
Kui tarkvara ei ole kvaliteetne, si s näiteks internetipangas võib raha minna valele kontole, 
lennukis tekivad lendamisel probleemid ja inimesed saavad surma. 
 
Nõuetele vastavuse kontrol imine on ainult üks osa kvaliteedist. 
 
Kvaliteeti ei saa testida. Saab testida näiteks nõuetele vastavust. 
Halvasti arendatud süsteemi pole võimalik kontrol i abil heaks muuta.  
Lõpptulemus sõltub kogu arendusprotsessist:  
● sealhulgas vajadustele vastavast ri stvarast  
● tarkvara arenduse meetoditest ja vahenditest  
● projekti­ ja kvaliteedihaldusest • organisatsioonist  
● standarditest 
 
55. Mis võiks olla kvaliteet? 
● Kvaliteet kui ideaal (arvamus ühelt arutelult: "tarkvara kvaliteeti pole olemas, kogu 
aeg on ki rustamine ja pole aega ühte asja valmis saada, juba tuleb järgmine") – 
ideaalset kvaliteeti ei pruugi tõesti olemas ol a; tihti on see mitte saavutatav ja 
ebaotstarbekas.  
● Kvaliteet kui mingi tootja või kaubamärgiga kaasas käiv omadus ("see on 
kvaliteettoode") – sel ine teadmine võib anda kasulikku infot hankimisel. Näiteks 
iPhone’i peetakse kvaliteetseks, aga ka neil on tarkvaras palju vigu. 
● Kvaliteet kui suhe toote, nõuete, protsesside vahel ("hinnataset arvestades oli hotel i 
kvaliteet väga hea") – sel ine suhe on alati olemas ja abiks hinnaefekti vsel 
tegutsemisel kõigis rol ides.  
22 
● Kvaliteet kui mõõt – mõõt on alati olemas (ka näiteks si s, kui "sel e süsteemi 
kvaliteet on madal"). 
 
56. Millest koosneb tarkvaratoode?  
Tarkvaratoode koosneb järgmistest komponentidest: 
● Arenduse käigus hangitud infotehnoloogiavahendid: ri stvara, standardtarkvara, 
sideseadmed. Kvaliteedi vaates saab toetuda ka teiste kogemustele, kui keegi on 
varem samu asju kasutanud. 
● Arenduse käigus tehtud töö: täitja arendatud tarkvara (sealhulgas lähtekood, 
objektkood, täitmiskood jm); instal atsioonid, kohandamised, muudatused; 
andmehõive. 
● Muudatused tel ija organisatsioonis, protsessides, töökorralduses... Oluline, et kes 
teeb muudatusi, kuidas neid sisse vi a, kes jälgib? 
● Metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste 
tegemine. 
● Projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi (nt 
organisatsioon , mil e jaoks tarkvara arendatakse) kohta; loodavate objektide kohta 
(programmi/testimise dokumentatsioon); instal eerimise ja seadistamise kohta; 
arenduse (sh testimise) kohta. 
● Teadmised projekti tulemuste kasutamisest; objektsüsteemist (süsteemianalüüs või 
vajalikud muudatused seadusandluses); projektist; arendusest.  
● Õigused tööks, arendamiseks, levitamiseks. Kas koodi omand on tael ija või arendaja 
omand? 
● Vahendid hoolduseks, muudatusteks, arenduseks. 
 
57. Nimeta erinevate osapoolte erinevad nõuded.  
Erinevatel osapooltel on erinevad nõuded (erinevad inimesed näevad erinevaid asju…): 
● Omanik võib nõuda, et süsteem oleks kuluefekti vne;  
● Kasutaja võib soovida loetavat kirja ekraanil;  
● Hooldaja näeks heameelega arusaadavat koodi;  
● jne.  
Need nõuded tuleb kirja panna ja sel e alusel pärast testida. 
23 
 
 
58. Nimeta süsteemi kvaliteedi nõuded vastavalt EVS­ISO/IEC 25010:2011 standardile.  
 
Funktsionaalsusega on seotud ainult 1 tulp, ülejäänud on mittefunktsionaalsed. 
 
59. Mis on funktsionaalne nõue? Too näited.  
Vastavad küsimusele: ​
„Mida ​
peab tarkvara tegema?“  
Näide: Süsteem peab võimaldama kauba tel imist. 
 
Tavalised  on need:  
1. Ärinõudmised, ärireeglid, standardid  
2. Funktsionaalsus  
24 
 
 
 
60. Mis on mittefunktsionaalne nõue? Too näited.  
Vastab küsimusele: ​
„Kuidas ​
tarkvara peab vajalikke funktsioone täitma?“  
Näide: Süsteemi vastuse aeg peab jääma etteantud pi ridesse; Süsteem peab teatud 
ajavahemike jooksul tõrgeteta töötama.  
 
Tavalised need on:  
1. Süsteemsed nõudmised ja pi rangud  
2. Tõhusus, turvalisus, töökindlus, kasutajali des (kasutajamugavus) jne  
3. Muud pi rangud  
 
61. Nimeta nõue, mis on testitav.  
Nõuete püstitamisel on oluline, et nad oleksid testitavad!  
 
Testitavad nõuded: 
1. Nõue: Süsteem peab väljastama jooksva hetke laoseisu.  
2. Nõue: Süsteemi töö võib kuu aja pikkuses ekspluatatsioonis keskkonnas X, 
kasutusakti vsuse Y ja kasutuslaadi Z korral ol a häiritud maksimaalselt ühe tunni 
jooksul. 
 
62. Nimeta nõue, mis on mittetestitav.  
Mittetestiv nõue: Süsteem peab olema töökindel.  
25 
Si n ei tea, et mida töökindluse al  mõeldakse. Kui kirjutada see nõue ümber ni  nagu 
eelmises punktis testitav nõue 2, si s on OK.  
 
63. Mis on reaalne nõue?  
Nõue võib ol a testitav, kuid ebareaalne, ebamõistlik, ebapi savalt spetsifitseeritud jne.  
 
Näide: Süsteemi vastuse aeg peab jääma al a 3 sekundi.  
 
See on üldiselt reaalne nõue, aga testimiseks on si n li ga vähe informatsiooni. Mis peab 3 
sekundiga juhtuma? ­ kas peab avanema esileht, kas peame saama mingi otsingu tulemuse 
(tuleb arvestada konkreetse päringu aega andmebaasist) vmt.  
 
64. Mis on mittereaalne nõue?  
Mittereaalne nõue on sel ine nõue, mis ei ole reaalne. 
 
65. Milline nõue on hea nõue?  
Hea nõue on: 
● Üheselt mõistetav ­ testija saab aru samamoodi kui saab aru arendaja. Kui kel egi 
jaoks ei ole nõudes olevad sõnad arusaadavad, si s tuleb ümber sõnastada. 
● Selge ja lühike 
● Täpne, arusaadav 
● Realiseeritav 
● Sõltumatu 
● Vajalik ja aktuaalne 
● Täielik, kõik info ühe nõue juures 
 
Näide 1: 
Võiks paremini: Kasutaja võib sisestada lennujaama koodi. Võib sisestada ka lähedal asuva 
linna, et kasutaja ei peaks meeles pidama kõiki lennujaamade koode, kuid süsteem peab 
teadma lennujaamade koode.  
Hea: Kasutaja võib otsida lennujaama sisestades linna või lennujaama koodi 
 
Näide 2: 
Võiks paremini: Kasutaja ei saa sisestada parooli, mis on pikem kui 15 sümbolit. 
Hea: Kasutaja ei saa sisestada parooli, mis on pikem kui 15 sümbolit. Kui kasutaja sisestab 
pikema parooli kui 15 sümbolit, vastab süsteem sel ele veateatega. 
! Oluline tuua välja, et kuidas süsteem peab reageerima, kui on veaolukord. 
 
66. Kas nõue peab olema koguaeg testitav?  
Jah, nõuded peavad olema koguaeg testitavad. 
Otstarbekas on püstitada testitavad nõuded, muidu ei saa nende täidetust hinnata.  
 
67. Mis on tarkvaraprotsessid?  
Tarkvara model eerib tegelikkust ja võib ol a väga keerukas, samuti võib ol a väga keerukas 
sel e arendus.  
26 
Et sel e keerukusega hakkama saada, on tarkvaraga seonduvaid tegevusi, tulemeid, 
dokumentatsiooni jne mõistlik kuidagi struktureerida.  
Seda saab teha protsesside ja elutsükli mudelite abil.  
Tuleks eristada tarkvara elutsükli mudeleid ja protsessiraamistikke.  
Teenuste protsesside raamistikud: ISO/IEC 12207, CMMI, COBIT, ITIL.  
Nad hõlmavad väga mitmesuguseid protsesse, mitte ainult ​
tarkvara arendust​
. Näiteid 
protsessidest: ​
hankimine, tarnimine, ekspluatatsioon, hooldus, konfiguratsiooni haldus, 
muudatuste haldus​
 jne. 
 
68. Millistest komponentidest koosneb elutsüklimudel?  
Elutsükli mudelid:  Scrum ,  Kanban , Koskmudel, V­mudel  ... 
! ​
Peab oskama erinevaid mudeleid omavahel võrrelda. 
 
 
 
69. Kirjelda V­mudeli.  
Tarkvaraarenduse tegevuste ja testimistasemete V­mudelit peetakse ka koskmudeli 
edasiarenduseks.  
V­ mudelis  on arendus­ ja testtegevused paigutatud sümmeetriliselt ni , et igale 
arendustegevusele vastab sobiv kontrol imisvi s.  
 
 
 
27 
70. Mis on  testimine ?  
Kitsamas mõttes on testimine tarkvara täitmine / käivitamine kontrol imaks, kas ta vastab 
ettenähtud nõuetele ning leidmaks vigu.  
 
Laiemas mõttes on testimine tarkvara analüüsi protsess eesmärgiga leida erinevusi 
olemasolevate ja nõutud tingimuste vahel ning hinnata tarkvara omadusi.  
 
Testimist võib laias mõttes määratleda ka kui kõikidest elutsükli tegevustest (ni  staatilistest 
kui ka dünaamilistest) koosnevat protsessi, mis puudutab ​
tarkvara ​
ja sel ega seotud ​
toodete 
planeerimist​
, ​
ettevalmistust ​
ja ​
hindamist ​
ning mil e eesmärk on kindlaks teha​
 toodete 
vastavus spetsifitseeritud nõuetele​
, näidata et nad ​
vastavad eesmärgile​
 ning ​
leida defekte​
.  
 
 
 
71. Kui korraldad testimist, mida peale nõuetest ja protsessist peaks veel teadma?  
Efekti vseks testimiseks ei pi sa vaid süsteemist. On vaja teada ​
nõudeid ​
ja ​
protsesse​
, mis 
omakorda tulenevad: 
● Ülesande püstitusest 
● Organisatsioonist 
● Seadusandlusest 
● Standarditest 
● Riskianalüüsist 
● Headest tavadest 
● Kasutajatest 
● Kasutusvi sist jne 
 
72. Kuidas võiks jagada testimismeetodeid? Mis kaks põhilist meetodi on? Miks?  
1. Staatiline testimine (static testing) – süsteemi või komponendi (koodi või dokumendi) 
testimine ilma testitavat tulemit käivitamata​
: 
○  Läbivaatus  (review)  
○ Staatiline analüüs (static analysis)  
 
2.  Dünaamiline  testimine – testimine, mil e käigus testitavat ​
tarkvara käivitatakse  
○ “tavaline testimine” 
28 
 
73. Kus leitud viga on kõige odavam parandada?  
 
 
74. Räägi statistikast läbivaatuse kohta.  
● Tarkvara inspektsioon võimaldab leida 70%­80% vigadest enne funktsionaalset 
testimist. 
Standup on ka läbivaatus, probleeme saab kohe lahendada. 
● Tunni jooksul leitav vigade keskmine arv  
○ Funktsionaalne valge kasti testimine – 0.282  
○ Funktsionaalne musta kasti testimine – 0.322  
○ Läbvaatused – 1.056  
● • Reeve’i rusikareegel – iga inspektsiooni käigus leitud viga säästab 9.3 töötundi 
 
75. Valge kasti testimine.  
Testijal on juurdepääs sisemistele andmestruktuuridele ja algoritmidele (ja koodile, mida 
rakendatakse). Testija püüab süstemaatiliselt läbida programmi mingeid osasid, näiteks 
lauseid , harusid, teid.  
 
Valge kasti testimise tüübid on:  
● Rakendusli deste (API) testimine​
 – rakendust  testitakse  avalike ja privaatsete 
rakendusli deste kaudu  
● Koodi ulatus​
 – luuakse teste, mis testivad koodi ulatust. Näiteks testi disainer võib 
luua testi, mil e käigus kõiki avaldisi (lauseid/käske) programmis käivitatakse 
vähemalt ühe korra.  
● Vigade süstimine​
 – koodi ulatuse parandamine kontrol ides, kas tarkvara töötab 
vigade lisamisel  
● Staatiline testimine​
 – valge kasti testimine hõlmab kogu staatilist testimist 
 
76. Musta kasti testimine.  
Testimine kohtleb tarkvara kui "musta kasti", teadmata midagi sel e sisemisest teostusest.  
Musta kasti testimismeetodite hulka kuuluvad:  
29 
● Spetsifikatsiooni põhine testimine  
● Juhuslikud sisendid ja lisatud vead  
● Uurimuslik testimine  
● Pi rväärtuste analüüs  
● Suitsu testimine  
● Kasutusmugavuse testimine 
 
77. Halli kasti testimine.  
Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele 
testjuhtumite koostamisel, kuid testimine vi akse läbi kasutaja või musta kasti tasemel. 
 
Hal i kasti testimise al a kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja 
väljaspool testitavat süsteemi andmeid muuta.  
 
Hal i kasti testimine võib hõlmata ka pöördprojekteerimist leidmaks näiteks pi rväärtusi või 
tõrketeateid. 
 
78. Testimise tasandid. Nimeta need ja seleta lahti. Too näited.  
 
Unit  testid on väga tähtsad. Kui on unit testidega kaetud suur osa koodist ja erinevad 
variandid, on hiljem lihtsam üles leida, kus on viga ja kergemini analüüsida. 
 
Testimise tasandid: 
1. Ühiktestimine (Unit test) 
Ühiktestimisel vastab üks test konkreetsele koodi osale, tavaliselt funktsioonile. 
Objektorienteeritud  keskkonnas testitakse klasside tasemel ja minimaalsesse testi 
kaasatakse ka konstruktorid ja destruktorid.  
Ühikteste kirjutavad arendajad tavaliselt valge kasti sti lis, et kontrol ida, kas mingi 
funktsioon töötab, nagu ette nähtud.  
30 
Ühe funktsiooni kohta võib ol a mitu testi, et kontrol ida funktsiooni töötamist 
pi rväärtustel või erinevaid koodi harusid.  
Ühiktestimisega ei saa tagada terve tarkvaratoote õigsust. Pigem kontrol itakse 
sel ega, kas erinevad tarkvara osad töötavad üksteisest eraldi. 
 
2. Lõimumise testimine (Integration testing) 
Kontrol itakse, kas komponentide vahelised li desed vastavad tarkvara disainile. 
Tarkvara komponente võib integreerida järk­järgult või ühekorraga.  
Tavaliselt eelistatakse vi mast, sest ni  saab ki remini leida ja parandada vigu 
li destes. Sel ine testimine paljastab defektid li destes ja vastastikustes toimetes 
integreeritud komponentide ( moodulite ) vahel.  
Integreeritakse ja testitakse järjest suuremaid tarkvara komponentide gruppe, mis 
vastavad arhitektuurilise disaini elementidele, kuni kogu tarkvara töötab ühtse 
süsteemina. 
 
3. Süsteemi testimine (System test) 
Testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele vastavust. 
Musta kasti testimine.  
 
 
4. Süsteemi integratsiooni testimine (Integration test) 
Kinnitatakse, et süsteem on integreeritud mistahes välise või kolmanda osapoole 
süsteemiga, mis on määratletud süsteemi nõuetes.  
Nt kas andmed tulevad teisest süsteemist, kas saadetakse andmed tesied süsteemi 
ja salvestatakse need sinna. 
Nt nõue, et tarkvara peab töötama erinevatel op. süsteemidel  ­ testitakse kõikides 
süsteemides. 
 
5. Regressioonitestimine  
Eesmärgiks on otsida vigu pärast koodi olulist muutmist.  
Tavaline regressioonitestimise meetod on läbi vi a varem kasutatud teste, et 
kontrol ida, kas eelnevalt kindlaks tehtud rikked on taas esile kerkinud.  
Regressioonitestimise ulatus sõltub arendustegevuse etapist ja lisatud 
funktsionaalsuse kaalukusest.  
31 
Testimine võib ol a täielik, kui muudatused on riskantsed või neid tehakse arenduse 
hilistes järkudes, või osaline, kui muudatused tehakse vara või ei ole eriti riskantsed. 
 
6. Vastuvõtu testimine (Acceptance test) 
Vastuvõtu testimine võib tähendada kahte asja:  
1. Vi akse läbi proovitest, et kontrol ida, kas uus tarkvara komponent on vastuvõetav 
peamisse testimise protsessi, näiteks enne lõimumis­ või regressioonitestimist.  
2. Kliendi tehtud testimist, tihti tema enda arenduskeskkonnas ja ri stvaral, 
nimetatakse kasutaja vastuvõtu testimiseks. 
 
TODO: Too näited. 
 
79. Testimise tüübid. Nimeta ja seleta lahti. Too näited.  
1. Funktsionaalne testimine 
○ Riskipõhine 
■ Riskipõhise testimise idee on testida esmalt tootega seotud kri tilisi 
riske. 
○  Uuriv  testimine 
■ Uuriv testimine (exploratory testing) on mitteformaalne tarkvara 
testimise tehnika, mil e puhul testija hindab testide kavandamist nende 
täitmise käigus ja kasutab saadud informatsiooni uute ja paremate 
testide projekteerimiseks 
○ Suitsu testimine 
■ Suitsutestimisel (smoke testing) täidetakse alamhulk kõigist testidest 
selgitamaks, kas põhilised funktsioonid töötavad. Nimetus tuleneb 
elektroonikatööstusest (seadme esmane sisselülitamine). 
 
2. Ekspertteadmiste testimine 
○ Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata. 
Tõenäoliste vigade leidmine võib sõltuda mitut sorti eelteadmistest, mil eks 
on:  
■ üldised teadmised  
■ teadmised konkreetse rakendusvaldkonna kohta  
■ teadmised ri st­ või tarkvarakeskkonna (näiteks konkreetse 
programmeerimiskeele) kohta  
■ teadmised mingi vigade tüübi kohta (näiteks tüüpilised infoturbega 
seotud kodeerimise vead). 
■ teadmised arendusmetoodika kohta  
■ teadmised konkreetse arendaja või tel ija kohta jne 
■ ! kasutusmugavuse testimine 
 
3. Mittefunktsionaalne testimine 
○ Jõudlustestimine 
■ Jõudlustest kontrol ib, kui ki resti tarkvara töötab kindla koguse 
andmete või kasutajatega.  
○ Koormustestimine 
32 
■ Koormustestimisega kontrol itakse, kas tarkvara suudab püsivalt 
töötada kindlal koormusel. Kui koormustestimist tehakse 
mittefunktsionaalselt, si s nimetatakse seda tihti vastupidavuse 
testimiseks.  
 
Jõudlustestimise ja koormustestimise al  mõistetakse tihti sama asja. 
 
○ Stabi lsus testimine 
■ Stabi lsuse testimine kontrol ib, kas tarkvara on võimeline pidevalt 
töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord 
vastupidavuse testimiseks. 
 
○ Kasutatavuse testimine 
■ Kasutuse katsetamine on vajalik, et kontrol ida, kas kasutajali dest on 
lihtne kasutada ja mõista. 
 
○ Turvalisuse testimine 
■ Turvalisuse testimine on oluline tarkvara puhul, mis töötleb 
konfidentsiaalseid andmeid, et vältida süsteemi häkkimist või 
ründamist. 
 
○ Destrukti vne testimine 
■ Destrukti vsel testimisel üritatakse tekitada tõrkeid 
tarkvaraprogrammis või käivituskeskkonnas, et testida sel e 
robustsust. Tehakse teste, et jookseks kokku, nt ülekoormus jmt. 
 
80. Millest koosneb testimise protsess?  
 
 
33 
● Nõuete analüüs​
. Katsetamine peaks algama tarkvaraarenduse elutsükli nõuete 
faasis. Sel el etapil töötavad testijad arendajatega, et teha kindlaks, mil ised tarkvara 
aspektid on testitavad ja mil iste parameetritega need testid töötavad. 
● Testimise planeerimine​
. Testimise strateegia, plaani ja testimiskeskkonna loomine. 
Kuna testimisel on palju tegevusi, si s on plaan vajalik.  
● Testide arendamine​
. Tarkvara testimiseks kasutatavate protseduuride, 
stsenaariumite, testjuhtumite, andmekogude ja skriptide loomine. 
● Testide täitmine​
. Testijad käivitavad testid plaanide ja testimise dokumentide alusel 
ja seejärel teavitavad arendusmeeskonda leitud vigadest.  
● Testide aruandlus​
. Kui testimine on lõpetatud, loovad testijad mõõtarve ja teevad 
lõpliku aruande testimise kohta ja sel e kohta, kas tarkvara on valmis väljastamiseks. 
● Testitulemuste või vigade analüüs​
. Seda teeb arendusmeeskond tavaliselt koos 
kliendiga, et otsustada, mil iseid vigu tuleks parandada, mil ised tagasi lükata (st leiti, 
et tarkvara töötab korralikult) ja mil iseid vigu parandada mil algi tulevikus. 
● Vigade uuesti testimine​
. Kui arendusmeeskond on üritanud viga parandada, si s 
testitakse seda uuesti.  
● Regressioonitestimine​
. Tihti luuakse teatud hulgast testidest koosnev väike 
testprogramm iga uue, muudetud või parandatud tarkvara versiooni kohta, et tagada, 
et vi mased muudatused midagi ei lõhkunud ja et tarkvaratoode tervikuna töötab 
endiselt õigesti.  
● Testimise lõpetamine​
. Kui katse vastab lõpetamise kriteeriumitele, si s tegevused 
nagu väljundi püüdmine, õppetunnid, tulemused, logid ja projektiga seotud 
dokumendid  arhiveeritakse ja neid kasutatakse vi tena tulevastes projektides. 
 
81. Millal lõpetada testimist?  
Testimise resultati vsust pole kerge hinnata. Seepärast pole ka testimise mahu üle 
otsustamine kerge.  
 
Ideaalselt ​
peaks testimise maht sõltuma tarkvarale esitatud nõuetest ­ testitakse seni, kuni 
need on rahuldatud. ​
Praktiliselt ​
tehakse ni  vaid tõesti kri tiliste rakenduste korral. Põhjusi on 
palju, näiteks: 
● nõudeid ja nende rahuldatust on raske hinnata;  
● töö tuleb ki resti üle anda;  
● on olemas eelnev kogemus ja see määrabtestimise mahu;  
●  rakendus  ei ole kri tiline (kui midagi juhtub, keegi eriliselt ei kannata) jne 
 
Kriteeriumid testimise lõpetamiseks: 
● Esimesed testid jooksid läbi  
● Kasutaja ei oska rohkem tahta  
● Testimise (või halvemal juhul süsteemiarenduse) aeg või raha on läbi  
● Eelmine kord testisime samapalju ja oli hea kül   
● Süsteemi üleandmise tähtaeg on käes  
● Paistab, et edasine testimine ei anna uusi vigu  
● Pole enam huvitav, tahaks midagi muud teha  
● ja ni  edasi 
● Kõik ekvivalentsiklassid (pi rjuhud) peavad olema testitud  
34 
● Testimine peab vastama haruadekvaatsuse kriteeriumile  
● Olulisemad andmekombinatsioonid peavad olema testitud  
● Andmepõhise testimise pi rjuhud peavad olema testitud  
● V% lisatud vigadest peavad olema avastatud  
● Tarkvara töökindlus peab olema P% 
 
Peaks panema kirja lepingusse, et mis tingimustel testimine lõpetatakse. 
 
 
 
 
82. Mida teha, kui testida ei saa?  
Näide: Ri giameti süsteemis testiti dokumenti, digial kirjastati. Hiljem helistati ja taheti tagasi 
võtta, kuna dokument oli “mõtetu”. 
Ilma kokku leppimata ei ole mõtet testida.  
Live süsteeme ilma testimata ärge häkkige! See on karitatav. 
 
83. Kas igaüks võib olla testija?  
Jah, võib kül . Tänapäeval puutuvad kõik inimesed kokku tarkvaraga. 
Teatud tingimused peaksid olema täidetud. Näiteks 3 juhtu: 
 
● kasutatavuse testimine ­ võetakse inimesed tänavalt, antakse neile tarkvara 
testperioodiks kasutamiseks. 
● kui inimesel on olemas hea tahtmine ja on kirjutatud põhjalikud kasutusjuhud. 
● kui inimesel on hea juhendaja ja mentor, kes aitab takistustest üle. 
 
Asi ei õnnestu, kui kogenematu inimene pannakse testima midagi suurt ja mil ega ta ei ole 
enne kokku puutunud, pole ka juhendajat. 
 
84. Testijale abiks omadused ja oskused.  
● Detailid, detailid, detailid ­ detailide nägemise oskus ja omadus (seda ei saa õpetada, 
osadele inimestele on pisivigade leidmine loomulik) 
35 
● Üldistamine ja järelduste tegemine. Vahest tuleb asja vaadata kaugemalt ja zoomida 
detailidest välja, et vigu leida. 
● Oskus näha suurt pilti ­ tööd on parem teha, kui sa tead suuremat pilti, miks sa 
midagi teed ja mil e jaoks. 
● Oskus ja julgus küsida küsimusi. Ka teravaid küsimusi. Aga vi sakalt. ­ Miks see on 
ikka ni  on lahendatud? Miks see spekis ni  kirjas on? Kas klient tahtiski seda? 
● Uudishimu ­ kui ei huvita, si s ei tule testimine hästi välja. Tulemus on heal juhul 
keskpärane, pigem vilets. Peab olema uudishimu, et “mis si s, kui”… (nt seda nuppu 
ka vajutan, seda nuppu 2 korda ki resti vajutan jne). 
● Suhtlemisoskus ­ suhtlemine arendajaga, projektijuhiga, analüütikuga. Nt analüütik 
pani kirja ühtmoodi, arendaja tegi teisiti...Aga mida klient tahtis? Tuleb mõelda ja 
selgitada. 
● Lugemisoskus ­ arendaja tavaliselt väga palju spekki ei loe. Testija peab seda 
tegema. 
● Kirjutamisoskus ­ oskus panna kirja, et mis on testimise seis (raport, mis sisaldab 
olulist). 
 
Erialased oskused ja teadmised peavad ka lisaks nendele omadustele olema. 
 
85. Valik jaotusi testimisele.  
Praktikast: 
1. Arendus testimine​
 ja ​
vastuvõtutestimine 
● Arendus testimine ­ testitakse arenduse juures, testija on arendusti mi osa ja 
saab arendajatelt ki resti vastuse, kuna nad on käepärast. Testija mõõdupuu 
on see, et kui palju ta leiab vigu ja kui palju saab parandatud ­ kui hästi ta 
saab arendajatega läbi. Tarkvara ei tohiks enne minna majast välja kliendile, 
kui testija on öelnud, et tema poolt on OK. 
● Vastuvõtutestimine ­ testija esindab otseselt klienti. Ta ei saa mõjutada 
arenduse kvaliteeti, saab raporteerida vigu ja loota, et need saavad 
parandatud. Sel e testimise aeg on see, kust tihti projekti lõpus 
hammustatakse aega maha ­ tähtaeg paigas, aga arendajad lasevad oma aja 
üle. 
 
2. Dünaamiline​
 ja ​
staatiline testimine 
● Dünaamiline testimine ­ testija reaalselt kasutab programmi, annab sisendeid 
ja ootab väljundeid, vaatab kas väljundid vastavad ootustele. So musta kasti 
testimine. Sel ele on suurem osa. 
● Staatiline testimine ­ programmi käivitamist ei toimu. Vaadatakse muid asju. 
Nt kasutajajuhendid käivad ka si a al a. So valge kasti testimine. Sel el on 
väiksem osa, kuna see nõuab tihti suuremat kogemust. 
 
3. Checkimine ​
ja ​
testimine ​
­ see on koolkondade vaheline võitlus 
● Checkimine ­ so klassikaline testimine: dokumentatsioon võetakse ette, 
tehakse testilood ja testiplaanid, antakse projekti lõpus testijatele testimiseks. 
36 
● Testimine ­ so uuriv testimine: istud programmi taha, vaatad mida programm 
teeb, planeerid samal ajal teste (testjuhud, testplaanid) ja samal ajal käitad 
neid. Rakendatakse testijate kogemust. 
 
4. Regressioonitestimine​
 ja ​
re­testimine ​
­  
● Regressioonitestimine ­ vaatad, et programm ei ole muutunud mujal, kui seal, 
kus sa tahad, et ta oleks muutunud. Kontrol , et programm mujal töötab 
endiselt. 
● Re­testimine ­ see on mingi veaparanduse üle testimine, et kas viga on 
parandatud ja korras. Sel ele võib järgneda regressioonitestimine. 
 
5. Funktsionaalne​
 ja ​
mittefunktsionaalne testimine 
● Funktsionaalne testimine ­ testitakse funktsioone, mida programm peab 
täitma. 
● Mittefunktsionaalne testimine ­ jõudlus­, koormus­, stressitestid jmt, andmete 
turvaline hoidmine.  
 
6. Manuaalne ​
ja ​
automatiseeritud testimine 
● Manuaalne testimine ­ inimene teeb. Testija vaatab reaalselt asjale otsa, kas 
programm teeb seda, mida vaja. Mõnikord on see ki rem, lihtsam ja odavam, 
kui automatiseerida. 
● Automaatne testimine ­ st et testijaid ei ole vaja, kõik käib automaatselt. Seda 
saab teha kuni mingile maale ­ teha kuni graafilise kasutajali deseni. Mis 
läheb sinnani ja üles poole, on li ga kal is ja ajamahukas automatiseerida. 
Oluline on automaattestid pärast ka töös hoida (nt kui programmi 
muudetakse). 
 
Mil ist testimist valida järgmiste näidete puhul? 
1. Desktop nimegeneraator lapsele nime valimiseks ­ ei ole tegemist kri tilise 
süsteemiga, pi sab manuaalsest testimisest. 
2. Netipanga raha ülekandmis rakendus ­ teha kõik testid, mis pähe tulevad. Kindlasti 
testida turvalisust ja ki rust. 
 
86. Testijaks olemise võlud.  
1. Palju huvitavaid projekte ­ testija tavaliselt saab kogeda rohkem erinevaid projekte, 
kui arendaja, kuna lihtsam on projekte/programme vahetada. 
2. Kogu aeg on põnev 
3. Saab kombata pi re ­ lisaks programmile, ka stressitaluvust ja töövõimet saab 
kombata. 
4. Suhelda saab palju ja paljudega ­ oluline ka info jagamine ti miga. 
5. Zen töö ­ kui vahest viskab kopa ette, si s saad stressi maandamiseks vahelduseks 
oma ette uurida programmi, testida testilugude järgi.  
 
87. Mis on tarkvara  arhitektuur ?  
● Tarkvara arhitektuuri  kontseptsioon  on pärit Edsger Dijkstra 1968 ja David Parnas 
1970 aastate uurimistöödest 
37 
● Tarkvara arrhitektuuri definitsioonid: 
○ Süsteemi il ustratsioon, mis aitab arusaada süsteemi käitumisest. (Software 
Engineering Institute ​
http://www.sei.cmu.edu/​
) 
○ Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, 
hõlmates tarkvara elemente, seoseid nende vahel ja elementide ning seoste 
omadusi.(wikipedia) 
○ ! Arhitektuur on  vundament  millele, tarkvara ehitatakse.​
 Arhitektuuri 
mudel defineerib vundamendi visiooni (agilemodeling) 
Vundament oleneb sel est, et mida sinna peale ehitatakse (paral eel maja 
ehitusega). 
 
88. Erinevused funktsionaalsest disainist.  
IEEE 1990 sõnastikust erinevate disaini mõisted:  
● Arhitektuurne disain​
 ­ protsess, mil e käigus  defineeritakse  ​
ri stvara​
 ja ​
tarkvara 
komponendid ja nende li desed, kujundamaks välja raamistikku tarkvara 
arendamiseks. 
! ​
Arhitektuuri osad on ni  ri stvara kui tarkvara. 
● Eeldisain ­ protsess, mil e käigus analüüsitakse arhitektuuri alternati ve ja 
defineeritakse arhitektuur, komponendid, li desed igale tarkvara komponendile. 
● Detaildisain ­ eeldisaini tulemi laiendamine/täpsustamine saavutamaks vajalikku 
täpsust arendamise alustamiseks 
● Funktsionaaldisain​
 ­ protsess, mil e käigus defineeritakse seosed süsteemi 
komponentide vahel. 
 
● Arhitektuur on disain aga mitte kõik disainid ei ole arhitektuur 
● Arhitektuuri juhivad mittefunktsionaalsed nõuded, funktsionaaldisaini juhivad 
funktsionaalsed nõuded 
● Pseudo kood kuulub detaildisaini dokumentatsiooni 
● UML komponendi­, paigaldus­ ja paketidiagrammid on enamasti arhitektuuri 
dokumentatsioonis 
● UML klassi­, objekti­, käitumisdiagrammid funktsionaaldisaini dokumentatsiooni 
 
89. Mis on arhitektuuri erosioon.  
Oletame, et meil on valitud 3­kihiline arhitektuur. Me oleme kokku leppinud, et suhtlus käib 
oma lähima kihiga. Arhitektuur on paigas, arendajad hakkavad programmeerima. Ühel 
hetkel üks arendaja otsustab kokkulepitut eirata ja control erist otse teenuskihti pöörduda.  
Kui üks maja akna klaas lõhutakse ära, si s hiljem läheb järgmine katki ja ni  kuni sel eni, et 
maja kukub kokku. 
 
Arhitektuuri mõistes on kaos. Puudub vundament, mil e peale asju üles ehitada. 
 
38 
 
90. Klient­ server  arhitektuur.  
Arhitektuur on tavaliselt erinevate mustrite kombinatsioon. Iga muster lahendab oma 
probleeme. Järgnevalt mõned mustrid. 
 
 
Kliendid suhtlevad serveriga, üksteisega otse ei suhtle. 
 
● Client­Queue­Client süsteem 
● P2P 
● Aplikatsioonide server 
 
Nt Skype on sel ine lahendus, mil e puhul suhlus käib läbi serverite. 
 
Kasu​
: 
● Kõrgem turvalisus 
● Andmed on tsentraliseeritud 
● Kerge hal ata ­  keerukus  on serveris 
 
91. Komponentidel põhinev arhitektuur. 
39 
 
 
Süsteem on ära jaotatud komponentideks. Igal komponendil on mingi ülesanne süsteemi 
sees. 
  
Mustri omadused: 
● taaskasutatav 
● asendatav ­ kui üks komponent on aeglane, saab asendada sel e välja 
● laiendatav 
● kapseldatud ­ igal komponendil on temale spetsi filine käitumine ja lahendab ühte 
konkreetset  ülesannet 
● sõltumatus ­ oma töös on võimalikult iseseisev 
 
Kasu​
: 
● kerge paigalda 
● kerge ehitada ­ ei pea tervet süsteemi korraga haldama 
● odav hind ­ kui midagi on katki, si s saab ainult sel e ühe komponendi välja vahetada 
● taaskasutatav ­ kui teha mitu rakendust ja nad jagavad funktsionaalsust, saab kasutada 
olemasolevat komponenti 
● lahendab tehnilist keerukust ­ saab jagada ärilise keerukuse komponentide kaupa 
 
See on üsna laialdaselt kasutatav arhitektuur. 
 
92. Kihiline arhitektuur.  
40 
 
Komponentide arhitektuur ja kihiline arhitektuur ei ole üksteist asendavad. 
 
Kihiline arhitektuur on üks enim kasutatav lahendus. Paneb paika, kes kel e poole võib 
pöörduda. Kasutaja suhtleb kasutajali desega. Kasutajali dese kiht suhtleb teenuskihiga või 
ärikihiga, mil e al  on andmekiht ja sel e al  andmebaas. 
 
Kõiki kolme kihti läbivad, turvalisuskoht, suhtluskiht ja Operational Management. 
 
Omadused: 
● abstraktne 
● kapseldatud ­ igal kihil on oma ülesanne, nt teenuse kiht ei tegele kasutajale UI 
joonistamisega 
● selgelt defineeritud kihid 
● taaskasutatav 
● nõrgalt seotud ­ seoses ainult oma eelmise ja järgmise kihiga, kihid ei hüppa üksteisest üle 
 
Kasud ​
: 
● abstraktne 
● manageeritav 
● isoleeritud 
● jõudlus ­ lihtsam jõudlust hal ata. Si s saab kergemini defineerida, kus kihis probleem on, 
nt andmebaasi päringud on aeglased ­ ei ole mõtet UI­d optimeerima hakata. 
● taaskasutatav 
● testitav 
 
93. Message bus.  
41 
 
Rakendused reeglina ei ole iseseisvad. Nt x­tee, mil ega enamus avaliku sektori rakendused 
suhtlema peavad / andmeid vahetama. Nt Active Directory. 
 
Kõik rakendused peavad üksteisega suhtlema ni , et kõik käib läbi ESBi. Peavad teadma 
ainult seda, kuidas ühendus käib ESBiga. Kõik loogika on ehitatud ESBi, nt andmete 
arusaadavaks tegemine teise  rakenduse  jaoks.  
 
Kasud​
: 
● laiendatavus 
● nõrgalt seotud 
● skaleeritavus 
● aplikatsioonide lihtsus 
 
94. N­tier.  
 
Sarnaneb kihilisele arhitektuurile, aga kihid on ​
ri stvara​
 sees. 
Kuskil on veebibrauser (esitluse kiht) ­> veebiserver (ühenduse loomiseks) ­> 
applikatsioonid ­> andmebaas. Asuvad füüsiliselt erinevates masinates. 
 
Kasud​
: 
42 
● hal atavus 
● skaleeritavus ­ see on põhimõtteliselt laiendamine. Kui jõudlusest jääb puudu, paned ühe 
purgi juurde. Kui jääb veel puudu, paned veel ühe jne. Nt pilveteenused töötavad mitmes 
arvutis ja neid pannakse juurde. 
● paindlikus 
● kättesaadavus 
 
95. Objekt orienteeritud arhitektuur.  
 
 
Objektorienteeritud programeerimine. Luuakse objektid. Igal objektil oma ülesanne. Objekte 
saab laiendada ja omavahel sisuda. 
 
Omadused: 
● abstraktsioon 
● kompositsioon 
● pärilus 
● kapseldamine 
● polümorfism ­ eraldatus 
● eraldatus 
 
Kasu: 
● arusaadavus ­ objektid peegeldavad tegelikku maailma 
● taaskasutatavus ­ klassist saab luua alamklasse, klassi saab laiendada, kasutada osaliselt 
jmt 
● testitavus ­ saab testida klasside kaupa, see lihtsustab testimist 
● laiendatavus 
● kõrge kohesi vsus ­ tugevalt seotud funktsionaalsus on ühendatud samasse klassi.  
 
96. DDD arhitektuur.  
Domain Driven Design. 
 
Objektorienteeritud arhitektuur kus lähtutakse ärilisest domeenist. Räägitakse ärikeeles, 
kasutatakse klassides neid nimesid, mida äri on ette öelnud. Nt kui äri ütleb Auto, si s ei ole 
Sõiduk, vaid ongi klass Auto. 
 
43 
Kasu: 
● äriline mõistmine ­ kasutatakse samu mõisteid ja kõik räägivad samas keeles 
● OO kasud 
 
97. Teenus orienteeritud arhitektuur.  
SOA. Oli kuum teema ca 6­7 aastat tagasi 
Suurtes süsteemides läks haldamine keeruliseks ja reeglina prooviti alguses ilma hakkama 
saada. 
 
 
Rakendused suhtlevad omavahel. Rakenduste vahel lepitakse kokku, mil ised on andmed, 
mil ised on andmestruktuurid jmt. Suhtlemine toimub alati lepingu alusel.  
 
Nt  SOAP , kus xml­ga vahetatakse andmeid. Kõigepealt jagatakse wsdl­ga lubadusi, mina 
tahan saadan sel iseid asju ja mul on sel ised teenused.  
 
Omadused: 
● autonoomne ­ iga teenus on iseisev 
● jagatav 
● nõrgalt seotud ­ üks teenus ei eelda, et teine on ilmtingimata olemas 
● jagatakse lepingut ja skeemi, mitte sisemisi klasse. Saan sisemiselt klasse muuta, aga 
tuleks jälgida kokku lepitud lepingut, et teised jääks tööle. 
 
Kasu​
: 
44 
● abstraktsus 
● leitavus ­ iga süsteem vastutab oma osa eest ja lepingute süsteemi kaudu on teada, mis 
kus on 
● ​
! ​
erinevad platvormid ­ igal rakendusel võib ol a oma platvorm, saab suhtema panna nt 
java  rakenduse .net rakendusega 
● ratsionaalsus 
 
98. Monoliitne arhitektuur.  
Funktsionaalselt eristatavad osad ei ole lahutatud komponendid 
Tekib tavaliselt si s kui lahendada ülesanne ni , et ei mõtle arhitektuurile.  
Osadel juhtudel on oma kohal, nt lihtsates koolitöödes ei ole mõtet ESBi kasutada. 
 
99. Mikroteenused.  
See on vi maste aastate väga pop sõna. See on taasleitud vana. Mikroteenused tulid koos 
pilveteenusega, kus on vaja teenused ja ei saa ehitata ühte suurt rakendust. 
 
Sarnane teenus orienteeritud arhitektuurile, aga: 
● Teenused on väiksemad 
● Teenused komponentide vahel mitte erinevate rakenduste vahel 
 
Kasud 
● Sama mis teenusorienteeritud arhitektuuril 
● Lihtsalt skaleeritav 
● Tehnoloogiste valikute muutmise osas vabam 
 
100. Kuidas valida arhitektuuri? 
Mõtle… 
● Kuidas kasutajad kasutavad loodavat süsteemi ­ mil e jaoks süsteemi ehitate? Nt onine vs 
offline süsteem. 
● Kuidas süsteemi paigaldada ­ kas süsteemi peab paigaldama või teeb seda süsteem 
automaatselt (masin)? 
● Mil ised on mittefunktsionaalsed nõuded: turvalisus, jõudlus, paral eelsus, multikeelsus, 
konfiguratsioon (konfiparameetrid koodis või andmebaasist hal atavad?) 
● Kuidas saavutada paidlikus ja hal atavus läbi aja 
● Mil ised on arhitektuursed trendid, mis võivad mõjutada süsteemi praegu või tulevikus ­ ära 
vali kõige trendikamaid ja uuemaid, kui ei saa väga riskida, nendega võib probleem kaasa 
tul a 
 
Võtme jõud, mis mõjutavad arhitektuuri: 
● Kasutaja volitused ­ kasutaja kogemus: ära dikteeri.  
● Turu küpsus ­ kasuta valmis komponente, ära leiuta jalgratast 
● Paidlik disain ­ taaskasutatavus, hal atavus, skaleeritavus 
● Tuleviku trendid 
 
Ei ole olemas universaalset arhitektuuri mustrit, mida valida. Kõik sõltub kliendist, süsteemist 
jmt. 
45 
 
101. Arhitektuuri disain.  
! ​
Ära üle inseneeri. Ära tee eeldusi, mida ei saa kontrol ida. 
 
Disainimisel küsi kliendi käest nt päringute arvu, klientide arvu prognoosi jmt. Pole mõtet 
eeldada, et tuleb miljon klienti korraga, kui Eesti turg on sel eks li ga väike ja seda kunagi ei 
juhtu. 
 
Disainimisel mõtle järgmistele asjadele: 
● Mis on fundamentaalsed osad arhitektuurist, mil e valesti tegemine on väga suure riskiga 
süsteemi toimimisele 
● Mil ine osa süsteemist on suurima muutumise tõenäosusega. 
● Mil iste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta 
● Mil ised on võtme eeldused ja kuidas neid kontrol ida 
● Mis võib põhjustada süsteemi ümber disainimise 
 
! Tarkvaraarhitektuuri disainimeks ei ole universaalset, aksepteeritud protsessi. 
 
102. Nimeta ja seleta lahti arhitektuuri disainimise protsessid. ka 
1. ADD​
 (Attribute Driven Design) töötati välja Carnegie Mel on Ülikooli pool 
● Väljakutsed 
○ Mil ine arhitektuur kataks kõige paremini kasutajate vajadusi 
○ Kuidas täita kujuteldava süsteemi nõudeid 
○ Kuidas otsustada, mil ine arhitektuuri strateegia on sobilik 
○ Kuidas hinnata nõuete täitmisel tehtavate kompromisside mõjusid 
 
ADD on rekursi vne, st et protsessi korratakse ja korratakse 
● 1. osa taktika 
○ Kontrol i, et nõuded oleks pi savad. 
○ Vali süsteemi osa, mida komponentideks lahutada 
○ Identifitseeri arhitektuuri juhtivad nõuded 
○ Vali kontseptsioon, mis täidab juhtivad nõuded 
● 2. osa dokumenteerimine 
○ Algväärtusta arhitektuuri elemendid ja jaota vastutused 
○ Defineeri elementide li desed 
○ Verifitseeri ja vi mistle nõudeid ning määra nende pealt pi rangud 
elementidele. 
● Korda samme kõikide süsteemi osade kohta 
 
ADD kasu​
: Nõuete vahelised kompromissid tulevad varajases staadiumis välja, mis 
omakorda aitab valida parima arhitektuuri nõuete katmiseks. 
 
2. Won Kim​
 is Senior Advisor at Samsung Electronics and Distinguished Professor at 
SungKyunKwan University 
1. Koosta esialgne paigaldusplaan(deployment plan). See annab ülevaate 
kasutatavast keskkonnast. 
46 
2. Mängi esialgsed kasutuslood läbi paigaldusplaani peal. See peaks sisaldama 
andmevooge läbi keskkonna, andmete sisenemisi, väljastamist ja tal etamist põhi 
andmetüüpidega. 
3. Grupeeri ja prioritiseeri nõuded. 
4. Vali üks kuni mitu mustrit moodulite vaatele ja defineeri kaetud nõuded 
5. Vali üks kuni mitu mustrit komponentide vaatele ja defineeri kaetud nõuded 
6. Vali üks kuni mitu mustrit paigutusvaatele ja defineeri kaetud nõuded 
7. Teosta järelkontrol  arhitektuurile 
8. itereeri punkte 1­7 
3. Agiilne arhitektuur ​
­ ei ole jäik protsess, on pigem mõttevi s (guideline). 
● Arhitektuur ei ole mitte midagi erilist 
● Karda kivisse raiutud arhitektuuri 
● Igal süsteemil on arhitektuur 
● Arhitektuur skaleerub 
● Arhitektuur evoleerub ­ arhitektuuri muudetakse teadlikult. Vastupidiselt 
erosioonile, kus arhitektuuri lõhutakse. 
 
 
Kes vastutab arhitektuuri eest agi lse arhitektuuri puhul? Kõik on vastutavad. Ei ole 
üks  arhitekt , kes vastutab, vaid kogu ti m vastutab. 
Probleem: 
● vahel inimesed ei ole üksteisega nõus 
● suurtes ti mides skaleeruvus 
Sel isel juhul valitakse arhitektuurile üks omanik/vastutaja, kes aitab alumistel ti midel 
jõuda ühistele arusaamisel. Kui laat läheb väga suureks, si s keegi, kes tõuseb püsti 
ja ütleb, et mina võtan nüüd otsuse vastu. 
47 
 
103. Kes on arhitektuuri omanik?  
Agi lne arhitektuur 
 
Kes vastutab arhitektuuri eest agi lse arhitektuuri puhul? Kõik on vastutavad. Ei ole üks 
arhitekt, kes vastutab, vaid kogu ti m vastutab. 
Probleem: 
● vahel inimesed ei ole üksteisega nõus 
● suurtes ti mides skaleeruvus 
Sel isel juhul valitakse arhitektuurile üks omanik/vastutaja, kes aitab alumistel ti midel jõuda 
ühistele arusaamisel. Kui laat läheb väga suureks, si s keegi, kes tõuseb püsti ja ütleb, et 
mina võtan nüüd otsuse vastu. 
 
104. Kuidas toimub töötamine arhitektuuriga suures meeskonnas?  
Agi lne arhitektuur 
 
● Arhitektuuri juhitud lähenemine 
● Featuuri juhitud lähenemine 
● Avatud lähtekoodi lähenemine 
● Kombinatsioon eelnevatest 
 
Agi lne arhitektuuri loomine on iterati vne. 
Arhitekt ei tohi ol a egoist, ta peab arvestama teiste arvamust ja vi ma sisse muudatusi. 
Kaasata tuleb ka tel ija, ei toh arvata, et tel ija on rumal ja ta ei tea midagi. 
 
 
 
105. Arhitektuuri testimine.  
Küsi endalt: 
48 
○ Mil istele eeldustele tugineb arhitektuur 
○ Mil iseid nõudeid arhitektuur katab 
○ Mis on sel e arhitektuuri võtme riskid 
○ Mil iste meetmetega leevendada riske ­ valitud riskid peavad olema teadlikud 
○ Mil moel on see arhitektuur edasiminek vi mase kandidaadi/baas arhitektuuri suhtes. 
 
106. Agiilne arhitektuur.  
● Nõuded juhivad arhitektuuri, va kui sa häkid. 
● Model eeri ­ ära joonista ainult paberile. 
● Ära unusta alternati ve ­ kui tekib viga, si s mõtle alati, kas alternati v lahendaks sel e 
vea. 
● Arvesta äri kitsendustega ­ räägi varakult arhitektuur läbi 
● Lenda valguski rusel 
○ Ole ni  väle kui võimalik ­ ära istu 2 kuud kapis ja mõtle asju välja, tagasisidet 
on vaja ki resti 
○ Ära kirjuta 50 lehekülge kui 5 kõlbab 
○ Ära kirjuta 5 lehekülge, kui pilt kõlbab 
○ Ära joonista pilti, kui metafor kõlbab 
○ ! ​
TAGRI ­ They Ain’t Gonna Read It. 
● Tõesta oma arhitektuur ­ parim tõestus on kood (ni  kaua kuni pole arendatud on 
valikud ja otsused tühi õhk) 
● Kommunikeeri oma arhitektuuri ­ sh ti mile ja klienidle tagasiside saamiseks 
● Mõtle tulevikule aga ära üle pinguta 
 
Tavalise praktika ja agiilse praktika erisused 
Tavaline praktika 
● Arhitektid tõstetakse või veel hul em tõstavad end ise kõrgemale pjedestaali astmele 
● Arhitektid on li ga hõivatud, et "määrida" oma käsi koodi kirjutamisega 
● Arhitektuuri mudelid on pi savalt robustsed, et lahendada ka tulevikus tekkivaid probleeme 
● Eesmärk on luua lõplik arhitektuur võimalikult vara 
● Hästi dokumenteeritud mudelid 
● Arhitektuuri mudeleid presenteeritakse vaid "sobilikele kuulajatele" ­ enamus on rumalad, 
nad ei saa ni kuini  aru 
● Arhitektuurile tehakse enne järelkontrol  ja seejärel läheb arhitektuur arendamisele 
 
Agi lne praktika 
● Arhitektidel on alandlikkust tunnistada et nad ei oska vee peal käia (ei ole jumalad) 
● Arhitektid osalevad akti vselt arendustegevuses (et tajuda probleeme, mis valitud 
arhitektuur põhjustab). Nad on meeskonna konsultandid 
● Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Kül  aga on nad 
enesekindlad sel es, et homseid probleeme saab lahendada homme 
● Arhitektuur tekib iterati vselt koos arendusega 
● Valguski rus. Dokumenteeri ni  palju kui on vaja kommunikatsiooniks. 
● Mudeleid kommunikeeritakse avalikult kõigile osapooltele (ti m, klient, DBA­d jt), ka 
poolikuid, et saada tagasisidet 
● Arhitektuuri kontrol itakse eksperimentidega 
49 
 
107. Veebirakenduse arhitektuur.  
! ​
Arhitektuuri point 
● Haldab keerukust 
● Mõeldud inimestele 
 
Näide enterprise süsteemist, mil ega tuleb tegeleda ­ EMT backend: 
● 4 miljonit rida koodi  
● kirjutatud 15 aasta jooksul  
● 10 tarkvarafirma poolt  
● 20 andmebaasi  
● 1000 tabelit andmebaasis 
 
Ühes süsteemis võib ol a korraga kasutusel mitu arhitektuuri: 
● klient­server.  
● kihiline & N­tier  
● objekt­orienteeritud  
● komponentidel põhinev  
● mikroteenustega 
 
108. Nimeta universaalsed põhimõtted ja seleta need lahti.  
Kõige olulisemad põhimõtted 
■​
 High cohesion  
● Süsteem kui suur tervik jaotatud tükkideks.  
● Iga tükk lahendab ainult ühte probleemi või alamprobleemi ning teeb seda hästi. 
● Näide (paremal high): 
 
■​
 Low coupling  
● moodulil vähe sõltuvusi 
● puuduvad ringsõltuvused 
● Näide: 
50 
 
Sigri­migrist on raske aru saada, et kes kel ega suhtleb. 
■ ​
Loose coupling 
● selgelt defineeritud li desed 
● sisemiste detailide varjamine ­ näitab kui palju üks kast teise sisse näha tohib 
 
List on li des, ArrayList, LinkedList on realisatsioonid. 
 
Need 3 põhimõtet kehtivad ni  arhitektuuri kui ka tarkvara disaini puhul. 
 
109. Hea arhitektuuri eelised ja nende seletused.  
Hea arhitektuuri eelised on:  
● Rakendust on ​
kerge lugeda  
○ igal tükil selge eesmärk 
○ silme ees ainult oluline 
○ parem ülevaade struktuurist 
● Rakendust on ​
kerge kasutada  
○ Kasutatav komponent võib ol a 
■ koodina rakenduse sees 
■ teegina rakenduse küljes 
■ veebiteenuse taga 
● Rakendust on ​
kerge muuta  
○ Kõigepealt tuleb aru saada  
○ muudatuste pi ratud mõju süsteemile (“ripple effect”) ­ saab aru, et mis midagi 
muudab + väike muudatus ei tähenda poole süsteemi ümber kirjutamist 
51 
● Rakendust on ​
kerge testida 
○ võimalik isoleerida ja mock’ida  
■ sõltuvuste asemel dummy’d  
■ kerge eri situatsioone läbi mängida 
 
110. HTTP protokoll.  
 
 
● Üldlevinud 
● Kerge kasutada  
● Kerge testida 
● Sobib peaaegu igale poole 
● Palju töövahendeid 
 
Oma formaadid ja pi rid. 
 
111. HTTP päring  
HTTP päring koosneb ​
päringust, päistest ja andmetest. 
Päised on tekstilised ​
nimi:väärtus paarid​
, mil e lõpetab tühi rida. 
Andmed ​
saadetakse ainult osade päringute puhul (näiteks POST).  
 
Näide: 
 
Reavahed on olulised, selge algus ja lõpp. 
 
112. HTTP vastus  
HTTP vastus koosneb ​
vastusest, päistest ja andmetest​
 (dokumendist). 
 Vastuses sisalduv kood näitab kas päring õnnestus:  
 
Järgnevad päised, mil est Content­Type päis on kohustuslik! 
52 
Päised lõpetab tühi rida. 
 
Näide: 
 
 
113. Nimeta veebirakenduste liike ja seleta need lahti.  
3 suuremat li ki: 
1. Thin­client veebirakendused  
● Server koostab HTML’i  
● Pi ratud interakti vsus ­ kogu veebilehe uuendamine korraga 
● Näiteks  
○ lihtsamad rakendused  
○ registreerimisvormid 
 
2. Fat­client veebirakendused 
● “Web 2.0”  
● Server edastab koodi ja andmed, ei koosta ise HTMLi 
● Ekraanipilt valmib kliendi poolel  
● Võimaldab teha interakti vseid rakendusi ­ ei pea uuendama kogu UId, saab 
uuendada ainult veebilehe osasid 
● Asendab sageli arvutiprogramme  
● Näiteks Gmail. 
 
3. Veebiteenused 
● REST li desega 
○ Süsteemide ühendamiseks 
○ Standardse HTTP abil GET, POST, DELETE 
○ Sageli JSON andmeformaadis 
● SOAP (lõputu peavalu al ikas!) ­ tegemist standardiga, mis ühes kohas võib 
töötada aga teises koha mitte; formaat on keeruline; vanakooli standard, mis 
eksisteeris enne RESTi. 
 
114. Veebirakendus JAVAs.  
● Veebirakendus on pakendatud .war faili sisse  
○ tavaline zip fail  
● Paigutatakse java serverisse  
○ teise nimega  konteiner   
○ vastutab HTTP protokol i/suhtluse eest 
○ Java konteinerid: 
53 
● Tomcat ­ 70% kasutab seda 
● Jetty  
● TomEE  
● Wildfly 
○ Moodsad alternati vid Java konteinerile: 
● Konteiner lisatakse teegina rakenduse sisse  
● Käivitatakse otse käsurealt  
● Pakendatakse standardse java arhi vina (jar) 
 
 
 
115. Servlet API  
Konteiner, mis tegeleb java suhtlusega pakub ette li dese, mil ega saab välismaailmaga 
suhelda. Seda nimetatakse Servlet API­ks. 
 
Si n on näitena klass, mis peab extendima HttpServleti klassi: 
 
 
 
Java rakendustes MVC realiseerimiseks võiks kasutada ​
Spring ​
frameworki ­ muudab MVC 
realiseerimise lihtsamaks. 
 
116. Model view controller  
Hea vi s veebirakenduse puhul koodi organiseerida. 
Si n käsitled kui disainimuster, aga võib ol a ka arhitektuuri muster. 
 
Rakenduse kood jagatud 3 komponendi vahel (igal tükil oma eesmärk ja defineeritud mis 
mil ega suhtleb):  
● model  
○ andmemudel  
○ äriloogika  
● view  
○ kasutajali dese genereerimine ­ html, html gerereerimine. Ei tegele 
äriloogikaga, ei tea andmebaasist midagi. 
● control er  
54 
○ vahendaja maailma ja rakenduse vahel  
○ suhtleb äriloogikaga  
○ otsustab mil ist view’d näidata 
 
 
FAT Client 
● staatiline html leht + javascript 
● ajax kaudu andmete lugemine ja kirjutamine  
● kontrol er vahendab andmeid  
○ sisuliselt REST li des, so: 
● Lihtsustatud kontrol er  
● Ainult töötleb andmeid  
● Ei tegele kasutajali desega 
 
MVC eelised 
● Väga hea vastutuste jagamine  
● Lihtne testida  
● Parem interakti vsus ja kasutajamugavus 
 
117. JSP  
Java Server Pages 
● Tekstifail HTML genereerimiseks 
● Kompileeritakse servletiks 
● Custom tagid keeruliste lehtede ehitamiseks 
 
 
 
118. JAX­RS  
● Standard REST­li deste ehitamiseks  
● Kerge andmeid JSON ja XML formaadist konverteerida 
55 
 
119. Starter KITS  
● Kõik ühes kogumikud, sh server  
○ Spring Boot  
○ Dropwizard 
 
120. Alternatiivid servletile  
● Play! Framework  
●  Spark  Framework 
● Grizzly 
● ... 
 
121. Nimeta tööriistu ja raamistike veebirakenduse jaoks.  
Tööri stad: 
●  
 
Raamistikud: 
● Play! Framework  
● Spark Framework 
● Ruby on Rails 
 
 
 
122. Riskide võrdlus 
Iterati vne vs kosemudel (si n on võetud äärmused, tegelikkuses ei kasutata puhast mudelit 
praktikas väga): 
 
 
Kose mudele puhul hakkavad riskid vähema al es testimise juures. 
56 
Interati vsel juhul tegeleme suuremate riskidega juba projekti alguses. 
 
123. Nimeta manifesto agiilse tarkvaraarendamiseks ja seleta need lahti.  
Agi lse tarkvaraarenduse manifestis on 4 põhimõtet: 
● Indivi did ja interaktsioonid on olulisemad kui protsessid ja tööri stad. 
● Töötav tarkvara on olulisem, kui põhjalik dokumentatsioon 
● Koostöö kliendiga on olulisem, kui lepinguläbirääkimised 
● reageerimine muutunud oludele on olulisem, kui aglse plaani järgimine 
 
 
Rõhuasetused muudeti. 
 
Agile’i aluseks on: 
Our highest ​
priority 
is to satisfy the ​
customer 
through ​
early and continuou​
s ​
delivery 
of valuable ​
software​
. 
Kõik muu on teisejärguline. 
 
Working software​
 is the 
primary ​
measure  of progress​
. 
See, et on olemas nõuded vmt, ei loe midagi. 
 
Welcome ​
changing requirements​
, 
even ​
late  in development​
. 
Muudatustega tuleb arvestada. Valmiv tarkvara peab vastama reaalsele vajadusele, 
mitte sel ele, mil es alguses kokku lepiti. 
 
124. Agiilse meetodi printsiibid. Seleta lahti.  
57 
 
 
● Customer involvment ­ kliendi osalemine tarkvara arenduse protsessis ​
pidevalt​
. 
● Incremental delivery ­ mitte suure paugu meetod, vaid inkrementaalselt anname välja 
iseseisvaid töötavaid tükke (osa asju võib ol a mockupide või dummyde tasemel) 
● People not process ­ rõhk pööratud arendusti mi oskustele ja kuidas töö on 
organiseeritud. 
● Embrace  change  ­ muutuste juhtimine; Nõuded võivad muutuda, sel eks tuleb 
inimestel valmis ol a. 
● Maintain simplicity ­ säilitada lihtsus ja püüda kõrvaldada keerukust psühhotehnilisest 
süsteemist. Sihitud ni  tarkvarale kui ka tarkvara arendus protsessile. 
 
125. Agiilsete metodoloogiate maastik.  
 
58 
 
126. eXterme Programming.  
The  eXtreme  Pogramming release cycle: 
 
 
XP praktikad: 
 
59 
 
 
! ​
XP­s rõhk koodil ja programmeerimise organiseerimisel. 
 
Extreme programming 
a software­development ​
discipline 
that ​
organises ​
people 
to produce ​
higher­quality​
 software 
more ​
productively 
Läbi distsipli ni ja korduva tegevuse saavutatakse hea kvaliteet. 
 
XP @ codeborne 
PROJECT  
● customer describes problem ­ tavaliselt aitame küsimustega 
● we give rough estimate ­ nt 3 kuuga saame esimese release’ga live’i, aga osa 
fnõudeid ei ole si s veel täidetud ja töö jätkub 
● we agree on: hourly price, approximate scope or time 
 
KICK­OFF ­ osaleb kogu codeborne’i team + kliendi esindaja(d) 
● storytel ing ­ kirjeldatakse  user  story’d (nt kasutaja saab sisse logida, kasutaja näeb 
IP­s oma kontode saldosid); klient määrab ära prioriteedid user story’dele ­ sel est 
alustatakse süsteemi ehitamist. 
● customer + the whole team 
 
ITERATION MEETING ­ esimene kick­off meetingul; alati on koosolekutel kogu ti m kohal; 
iga nädal näidatakse kliendile töötavat tarkvara, mida me tegime ­ see on mõõdetav tulemus 
● every week 
● story details are discussed 
● customer defines priority 
60 
● demo of added functionality ­ raha küsitakse ainult si s töötundide eest, kui 
suudetakse kliendile demoda ja üle anda mingi osa tarkvarast. Kui midagi ei ole OK, 
si s klient saab sel e välja tuua ja tehakse user strory’d juurde. 
 
DAILY  WORK 
● stand­up meeting ­ orginaalis mis tehti eile? mis tehakse täna? probleemid? Seal 
tulevad välja kommunikatsiooniprobleemid, mööda rääkimised 
●  open  workspace 
 
DEVELOPMENT 
● pair programming ­ ühe arvuti taga 2 inimest, tegelevad ühe ülesande 
lahendamisega, korda mööda kirjutavad, kogu aeg käib  code ­review; aitab fookust 
hoida, ei loe vahepeal e­maile jmt. Kogemus näitab, et ni  on töö efekti vsem! Paaris 
programmeerimine on hea vi s, kuidas õppida ­ ni  õpib paari kuuga rohkem kui paari 
aastaga ülikoolis. 
● test­driven development ­ kõige pealt kirjutame lihtsa unit testi, peale seda kirjutame 
funktsionaalsuse mis rahuldab testi. Kasutajali dese tasemel on keeruline, aga muidu 
lihtne. Käib hästi kokku paaris programmeerimisega. Üks kirjutab testi ja teine peab 
sel ele funktsiooni kirjutama. 
● refactoring ­ koodi loetvause parandamine funktsionaalsust muutmata 
 
BDUF? ­ Big design up front 
● simple design 
● (just enough design) 
Hiljem disaini täiendada ei ole probleem, kui on olemas testid ja jälgitakse refactor 
põhimõtteid. 
Inimesed ei ole tihti suutelised suurt disaini pilti välja mõtlema, väikeste tükkidena on 
lihtsam. 
 
DEVELOPMENT 
● col ective code ownership ­ kõik võivad suvalises punktis muudatusi teha 
● automated acceptance tests ­ tehakse enne kui midagi kliendile üle antakse; 
süsteemi testid, mis antakse üle ka kliendile (on koodi osa) 
 
DELIVER 
●  continuous  integration ­ tähendab, et kui keegi mingit koodi 
muudab/versioonihaldusesse lisab, si s kood korjatakse versioonihaldusest üles, 
tehakse  build , lähevad testid käima, kui on probleem si s teavitus teamile e­mailile. 
● continuous deployment 
 
CUSTOMER COLLABORATION ­ klient saab nt arendusserveris/testserveris rakendust 
vaadata ­ saab anda kohe tagasisidet, et kas ta mõtles ni  ja soovib seda; mida ki remini 
tagasiside tuleb, seda lihtsam muudatusi teha; kliendiga suhtlus chati vormis ­ skype, fleep 
jmt 
●  frequent  discussions 
● immediate feedback 
61 
 
KEEP  GOING 
● sustainable pace 
● estimates ­> velocity ­ iga story on 1 story point. Kui esimestel nädalatel tehakse ca 
3­4 story’t nädalas (3­4 punkti), si s sel e pealt saab ennustada, et kaua kõikide 
story’de realiseerimine aega võiks võtta ­ see on tagasisde ka kliendile. 
 
RELEASE 
● ASAP ­ soovitame klientidel funktsionaalsus vi a võimalikult ki resti lõppkasutajani. 
Seal on järgmine feedbacki tase. Nt saab anda kasutada pi ratud kasutajate hulgale. 
Panga internetipank kõigepealt kasutussse panga töötajatele. 
 
IMPROVE  
● continuous learning ­ iga nädal 1 tund koosoleku ruumis teemade arutamine, keegi 
räägib mil estki mida ta on teada saanud/uurinud 
● retrospective ­ igaüks pakub välja Keep (mis hästi?), Problem (nt iga kord tulevad 
mingid vead välja release’i käigus, kuidas seda parendada?), Retry (uued ideed, et 
projekt veel paremini li guks) 
 
127. XP väärtused.  
XP values: 
● improve ​
communication​
 ­ erinevatel tasemetel, nt programmeerijad omavahel, 
suhtlus kliendiga 
● seek ​
simplicity ​
­ lihtsamaid lahendusi tuleb otsida 
● get ​
feedback​
 ­ igast tegevusest on vaja saada tagasisidet, et sel ele reageerida 
● proceed with ​
courage​
 ­ julgus katsetada muudatusi teha 
 
128. Scrum? Kõik, mis oli loengus. Seletada lahti kõik mõisted, tegevused ja osalejad.  
! ​
Scrumis on rõhk projektijuhtimisel, projekti haldusel. 
 
Scrumi alused​
: 
62 
 
Kui on ära tehtud 3 jagamist (split), si s tuleb teha 2 optimiseerimist (optimize). 
Srumis on oluline ka tarkvaraarendusprotsessi efekti vsuse mõõtmine (lisaks sel le, et 
protsess optimeeritakse). 
 
Scrumi mõisted​
: 
 
 
Osalejad / Rol id: 
● Product owner 
○ Define the features of the product 
○ Decide on release date and content 
○ Be  responsible  for the profitability of the product (ROI) 
○ Prioritize features according to market  value  
63 
○ Adjust features and priority every iteration, as needed 
○ Accept or reject work results 
● ScrumMaster 
○ Represents management to the project 
○ Responsible for enacting Scrum values and practices 
○ Removes impediments 
○ Ensure that the team is ful y functional and productive 
○ Enable close cooperation across al  roles and functions 
○ Shield the team from external interferences 
● The team 
○ Typical y 5­9 people 
○ Cross­functional: 
■ Programmers, testers, user experience designers, etc. 
○ Members should be ful ­time 
■ May be exceptions (e.g., database administrator) 
○ Teams are self­organizing 
■ Ideal y, no titles but rarely a possibility 
○ Membership should change only between sprints 
 
Scrumi raamistik: 
 
Sprint  on iteratsioon. Iga sprindi alguses on planeerimine, kus jaotatakse user story’d 
taskideks. Sel est tekib backlog. Edasi tuleb taskid 1­4 nädalaga realiseerida. Asja jälgib 
boss ehk ScrumMaster. Iga 24h järel on standup igapäevased koosolekud, kus küsitakse: 
Mida tegid eile? Mida teed täna? Ega probleeme ei ole? 
Burndown näitab, kui efekti vselt taske realiseerime. 
Iga sprindi lõpus on Sprint Review ja Retrospective. 
Kui asi antakse üle Product Ownerile, si s tehakse project retrospekti v ­ mis oli hästi? mis 
kehvasti? mida võiks teha teisiti? 
64 
 
Potential y shippable product increment​
: 
 
 
Product backlogi näide​
 (koosneb user story’dest): 
 
Rol  ei pea alati olema inimine, nt robot Googlebot. 
Igale story’e pannakse juurde äriväärtus. 
 
Sprint backlogi näide​
: 
 
65 
 
User story’d on jaotatud väiksemateks taskideks. 
 
Burndown chart’i näide​
: 
 
 
129. Mis on kasutuslugu?  
Üldkuju: As a user playing some role, I must be able to perform some activities [in order to 
achieve some goal] 
 
Backlogide granulaarsus​
: 
66 
 
 
Epic , feature, user story​
: 
 
 
Näide: 
● Epic: 
○ Al ow the customer to manage its own account via the Web 
● Feature: 
○ Editing the customer information via the web portal 
● User story: 
○ As a customer, I want to be able to modify the customer information so that I 
can keep the customer information up to date. 
 
67 
 
 
130. Kanban.  
Kanban on oluliselt lihtsam kui Scrum. Töötab konveier põhimõttel. 
 
Kanbanis on 3 põhimõtet: 
● Pul  Value through the Value Stream 
○ Kui järgmine etapp on mingi asja ära ​
PULL​
’inud, si s eelmine avastab, et tal 
on tühi koht ja saab uue asja võta sinna. 
● Limit WIP 
○ Neljas esimeses etapis on tööde arv pi ratud. Nt To do listis ei tohi ol a 
rohkem kui 5 tööd ­ sinna saab ühe veel juurde võtta. 
● Make it visible! 
○ Kanban board’i kasutatakse sel eks 
 
 
Kanbani ideoloogia​
: 
● “Lean” – keskendu sel ele, mida klient vajab 
○ Don’t build features that nobody needs right now 
○ Don’t write more specs than you can code 
○ Don’t write more code than you can test 
○ Don’t test more code than you can deploy 
● Väldi inimeste või ressursside ülekoormamist 
● Väldi ebaühtlast töökoormust 
● Väldi tegevusi, mis ei lisa väärtust 
 
68 
Kanbani näide: 
 
 
 
131. Minimal Marketable Feature (MMF)  
Kanban kasutab samade asjade kohta erinevaid termineid. Näiteks MMF (Kanban) = 
Potential y Shippable Product Increment, Feature (Scrum) 
 
● A minimal marketable feature (MMF)​
 is a chunk of functionality that delivers a subset 
of the customer’s requirements, and that is capable of returning value to the 
customer when released as an independent entity 
● Think of it this way: Gather up al  the stories that share the same SO THAT clause 
representing the GOAL — that is your MMF! 
● Eesmärk väljendab MMFi. Kokku on need ​
kasutuslood​
, mil el kõigil on üks ja ​
sama 
eesmärk​
. 
 
132. Eesmärgi mudel  
Eesmärgi mudeli näide: 
69 
 
Eesmärgid võivad ol a erinevatel tasanditel (“kastikesed”). 
Eesmärgi mudel on üks vi s nõuete esitamiseks. 
“pilvekesed” on mittefunktsionaalsed nõuded. 
 
133. Kanban vs Scrum  
Kanbani võimalikud eelised Scrumi ees​
: 
● Lihtsus! 
● Puudub suurte Backlogide haldamine 
● Puudub “time boxing” Sprint Backlogide jaoks ­ iga iteratsiooni kohta ei ole öeldud, et 
sel e iteratsiooni jaoks on ni  palju aega 
● Puuudub arendamise edukuse hindamine ja mõõtmine 
 
Scrum vs Kanban 
● Kanban limits WIP per workflow state,  while  Scrum limits WIP per iteration 
● Scrum Board is reset between each iteration 
● Scrum prescribes crossfunctional teams, while Kanban could have specialised teams 
● Scrum Sprint backlog items must fit in a Sprint, while Kanban can have long running 
items 
● Kanban daily meetings focus on changes on the board, while Kanban focuses on 
assignments of each person ((yesterday, today, problems) 
● Scrum estimates and measures progress, while this is optional in Kanban 
 
134. Mis on mudel? Kus kasutatakse? Milleks on mudeleid vaja?  
Mudel​
: 
● A hypothetical, simplified description of a complex entity or process 
● “A model should be as complex as it needs, but not more complex”, David Lorge 
Parnas 
● What features (reaalsest maailmast)... 
70 
○ are important? 
○ can be ignored? 
 
Mudeli näited​
: 
● A model of the solar system 
● The model of a gold mine 
● The model of a chemical plant 
● Air traffic simulator 
 
Mudel tarkvara süsteemide ehitamiseks 
UML​
: 
The Unified Modeling Language (UML) has gained broad industry acceptance as the 
industry­standard language for specifying, visualizing, constructing, and documenting the 
artifacts of software systems. It simplifies the complex process of software design, making a 
"blueprint" for construction. The UML definition was led by  Rational  Software's 
industryleading methodologists, Grady Booch, Ivar Jacobson, and Jim Rumbaugh.  
 
Mil eks on mudeleid vaja​
? 
● Et planeerida ja ehitada keerukaid süsteeme 
● Vahendid, et soodustada diskussiooni olemasoleva või loodava süsteemi üle 
● Vahendid dokumenteerimaks olemasolevat süsteemi 
● Detailne süsteemi esitus, mil est saab (osaliselt) genereerida süsteemi realisatsiooni 
 
135. Tarkvaratehnika vaated.  
● Omaniku vaade 
● Kavandaja vaade 
● Ehitaja vaade 
 
136. Liikumine ühelt vaatelt järgmisele. 
71 
 
  
137. Tarkvaraprotsessi etapid.  
1. Nõuete esiletoomine ja analüüs 
2. Kavandamine e. disain 
a. Arhitektuuriline kavandamine 
b. Detailne kavandamine 
3. Realiseerimine 
4. Testimine 
5. Hooldus ja evolutsioon 
 
138. Iteratiivne arendamine: Rational Unified Process (RUP)  
72 
 
RUPi mudeli faaside selgitused: 
● Inception: äriline analüüs 
● Elaboration: nõuete analüüs, arhitektuuriline disain, arendusplaan 
● Construction: detailne kavandamine, realiseerimine ja testimine 
● Transition: süsteemi käitamine 
 
RUP kui kosk: 
 
 
73 
Iterati vne RUP: 
 
 
139. Modelleerimine.  
Igal etapis ja igas faasis on oma „tehised“ (artefacts): graafilised ja tabulaarsed mudelid, 
dokumendid, kood jne. 
 
140. Mudelite klassifikatsioon.  
 
 
74 
141. Käitumise analüüs.  
Tegeleb ja vastab küsimustele: 
● Mis eesmärke süsteem peaks saavutama? 
● Mil ised rol id on nende eesmärkide saavutamiseks vajalikud? 
● Mida süsteem peaks tegema? 
 
1. Eesmärgimudel 
 
 
2. Tegevusdiagramm (UML) 
 
3. Kasutuslugu 
● Kui (rol ) ma tahan (sooritada midagi) et (saavutada eesmärk) 
● Näide 1: As a Receptionist I want to Register patient so that Monitor health 
condition 
● Näide 2: As a Sel er I want to Ship order to Provide product 
 
142. Interaktsioonide analüüs.  
75 
Kuidas süsteem peaks suhtlema kasutajaga ja teiste süsteemidega? 
1. Kasutusjuhu diagramm 
 
 
 
2. Kasutusjuht tabelina 
 
 
143. Struktuuri analüüs.  
● Mis osadest süsteem koosneb ja kuidas need on omavahel seotud? 
76 
● Mil ist tüüpi olemite kohta peaks süsteem informatsiooni esitama ja kuidas need 
olemid on omavahel seotud? 
1. Kontekstidiagramm 
 
2. Klassidiagramm ­ pärimine 
 
3. Klassidiagramm ­ agregatsioon 
 
77 
4. Klassidiagramm ­ assotsisatsioonid 
 
 
144. Interaktsioonide disain.  
Mil iseid teateid süsteemi osad vahetavad omavahel ja kasutajaga? 
 
1. Jadadiagramm​
: 
 
 
145. Struktuuri disain.  
Mil ist informatsiooni tuleb süsteemis esitada? 
 
1. Detailne klassidiagramm​
: 
78 
 
 
146. Käitumise disain.  
Kuidas süsteemi olemid käituvad? 
 
1.  Olekudiagramm ​
: 
Meditsi nilabori olemi “Tel imus” olekudiagramm 
 
 
 
 
79 
 
 
147. Kuidas on varem arhitektuurist mõeldud  
● Maja ehitades on mõistlik vundamendist hästi aru saada 
● “ …al  these must be built with due reference to ​
durability​
, ​
convenience ​
and ​
beauty​
” 
(Marcus Vitruvius Pol io, 80­70 eKr.­ 15 pKr). Kõik need tingimused peavad olema disaini 
otsuste tegemisel arvesse võetud. 
● Minge kõndige vanalinnas... (vanalinna paral eel arhitektuuriga): 
○ Tal inna vanalinna on sadu aastaid “arendatud“! 
○ Osad ajad kehtivad jätkuvalt, osad asjad ei kehti 
○ Jäl egi sama printsi p: asjad, kui miski jääb, on ta kasulikum, kui see, mis kaob 
○ Ri as vanalinna ei ole, sest seal oli ühel hetkel inimestel raha uusi maju ehitada 
○ ! Tallinna vanalinnas kehtiv kehtib ka tarkvarale, ainult et palju lühemal 
ajaksaalal ​
­ keegi alguses disainib asja valmis ja si s lastakse hulk “lol e” peale, 
kes disainiga ei arvesta 
 
148. Moodsa süsteemiarhitektuuri mõtte juured  
 
149. Arhitektuuri olemus  
 
150. Arhitektuuri roll  
 
151. Mis on arhitektuur?  
 
 
152. Mis on keerukus ja miks on see oluline?  
80 
Keerukuse ​
definitsioone on erinevaid:  
1. Süsteemi elementide, nende li kide, nende omavaheliste seoste ja seoste li kide 
kaudu  
○ Levinud, intuiti vne ja paljude variatsioonidega  
○ Sõltub elementide arvust ja nende omavahelisest seosest 
2. Keerukus vs. keerulisus  
○ Keerulisuse omadus on süsteemi omadus näida keeruline  
3. Dünaamiline keerukus ilmneb läbi süsteemi osade omavahelise interaktsiooni ​
ajas  
○ Keerukus kui entroopia määr  
○ Keerukus kui pakitavuse määr  
○ Keerukus kui loogiline või termodünaamiline sügavus  
○ Keerukus kui sisendi ja väljundi seos  
○ Keerukus kui fraktaaldimensioon  
○ Keerukus kui alamsüsteemide hulk  
 
! ​
Keerukusest rääkides on oluline kokku leppida parasjagu kasutatavas definitsioonis​
. 
 
 
Kui lisada süsteemi elemente juurde, si s keerukus kasvab eksponendina. Kuskil on alati 
võimete pi r, nt organisatsioonis olevate inimeste võime keerukust juhtida jm. 
Keerukus toob endaga kaasa riske. 
 
153. Riigi kui selle arhitektuur  
How to architect a  country ? And not mess up doing it. 
The chal enge  
● There are many architects in public sector but few (if any) with a similar scope  
● No literature to go back to  
● Enterprise architecture does not help much  
○ Although Estonia is comparable to a large enterprise  
○ Regardless of what they say, EA is usual y focused on information systems, 
rather than the enterprise per se  
○ Value generation in public sector is much different  
○ No real way to tie in legal structures important in public  setting  
 
That one can’t influence something does not mean one does not need to understand it  
81 
While I can’t change Estonian constitution or organisational structure, I need to understand it 
so the things I ​
can ​
change fit. 
 
How to ​
think ​
about a ​
country​
?  
● Many equal y feasible approaches  
○ “It is a way to organise us living together“  
○ “It is a hostile entity that is not to be trusted“  
○ “It is a conduct of Gods wil “  
● The domain of legal and philosophical thinkers  
● Embodied, to an extent, in constitution  
● Thus very hard (if at al  possible) to influence 
● Has a massive influence on acceptable ways the functions of a state can be 
executed 
 
Function ​
of a country  
What does a country ​
do​
 anyway? 
● Function of a system is emergent by definition 
● Function is fundamental y driven by whoever has the highest power in the current 
setting 
○ The people, in Estonian case  
○ Partly captured in legislation  
● There are many ways to think of the function  
○ Business process analysis, use case analysis etc. 
 
Form ​
of a country  
What ​
is​
 a country? 
Three main categories of form  
● Peopleware  
○ How are the people embodying the country organised? 
○ Administrative setup, business processes  
○ Organisational entities and their roles  
● Software  
○ The obvious bureaucracy automation  
○ But also e­mail servers, sensor networks etc.  
● Hardware  
○ The  physical  artefacts supporting the first two  
○ Cold rooms, cables and servers • But also physical office buildings and their 
layout 
 
Architectural model of a country  
82 
 
Main idea​
: A holistic model of a country al owing to explore complex relationships spanning 
disciplines 
 
Applying the model  
● Software: Is the software built to survive loss of access to other services?  
● Peopleware: How can responsibility for data be executed across borders and 
physical distance?  
● Functions: Does the function make sense in isolation (people registry without 
document  registry)? 
● Constitution: To what extent can a country exist in exile? 
 
Enterprise Service Bus ­ ettevõtte si ni arhitektuur. Eesti ri gi arhitektuur on väga sarnane 
sel ele. 
 
154. Riigi infosüsteemi kui terviku kontekstis ja miks on see oluline?  
 
 
155. Süsteemid ja nende dünaamika  
Vi ekümnendatel hakati mõtlema keerulistest süsteemidest  
● Asjade keskmes oli MIT  
○ Forrester ja system dynamics  
○ Wiener ja küberneetika  
● Peamine probleem: kuidas juhtida keerulisi süsteeme soovitud suunas?  
● Leiti, et ükski mõju ei levi koheselt ­ kehtib kõikides süsteemides 
● Kuidas muuta sisendit soovitud väljundi saamiseks? Nt kui on palju sisendeid, aga 
vähe väljundeid? 
●  Järeldused on suhteliselt lihtsad, aga vi vad ki resti keerulise matemaatikani!  
 
! ​
Keeruliste süsteemide käitumises on kindlad, universaalsed, seaduspärasused 
 
156. ICBM ja nende ohutus  
● Koos massi vse tuumaarsenaliga sündis ka vajadus neid kuidagi ohutuna hoida.  
83 
● Vastupidiselt sel ele, mida räägiti omal ajal telekas, oli mure sel ega, et maailma mitte 
vastu taevast lasta. 
● Süsteem on väga keeruline. Igal sammul on inimene kaasatud, aga inimene sõltub 
masinast (inimene üksi ei tee midagi). 
● Tekkis väga keeruline sotsiotehniline süsteem. Globaalne haare: radarijaamad, 
komandopunktid, raketibaasid. 
● Et kõike ohutuna hoida, tuli mõelda süsteemist kui tervikust ­ masinad, inimesed, 
tarkvara ja nendevahelised suhted. Tuli mõelda välja süsteemne lähenemine, et 
kogemata midagi ei juhtuks. Sündis süsteemiohutus kui teadus.  
●  
● Hea näide: USA tuumalaevastikus pole olnud ühtegi reaktoriga seotud intsidenti 
rohkem kui 60 aasta jooksul  
 
!​
 ​
Süsteemides mõtlemine on praktiliselt kasulik​
. 
 
157. Tänapäevased keerulised süsteemid  
● Süsteemid lihtsamaks kohe kindlasti ei lähe 
● Me mitte ei kasuta enam tarkvara vaid elame koos tarkvaraga  
● Tarkvara moodustab loomuliku, lahutamatu ja sageli nähtamatu osa meie 
igapäevaelust  
● Teile vast loomulik, minu põlvkonnale tuleb üle rõhutada  
● Järelikult tuleb tarkvarast rääkida koos inimesega  
● Targa tolmu puhul ületab paigalduse hind kübeme hinna: majanduslik mõte on osa 
süsteemist, Vahel on süsteemi paigaldamine kal im kui süsteemi enda maksumus 
●  Facebooki tarkvara peegeldab ja mõjutab teie sotsiaalset võrgustikku  
● Kuidas toimus Tesla autopiloodi lansseerimine ­ öösel sai auto tarkvara update’i ja 
hommikul sõitis auto ise. See oli võimalik, kuna vajalikud komponendid olid autosse 
juba paigaldatud.  Kõik aastad, mis inimene autot juhtis, koguti infot inimese 
otsustest ja võrreldi neid arvuti (konkreetses autos olnud) tehtud otsustega. Kui 
erinevused puudusid kahes otsuses (arvuti oli sama tark kui inimene), sai autopiloodi 
päriselt kasutusele võtta. Tegemist süsteemse lähenemisega, inimesed on süsteemi 
lahutamatu osa. Eraldi testijate palkamine oleks olnud väga kal is, autojuhid olid 
testijad. 
 
! ​
Süsteemides mõtlemine on tänapäeval vältimatu​
. 
 
158. Süsteemi definitsioon ja süsteemimõtlemine  
Süsteem ​
on hulk olemeid ja nende seoseid mil ede funktsionaalsus on suurem kui üksikute 
olemite funktsionaalsuse summa. 
 
Süsteemimõtlemine ​
on vi s mõelda küsimusest, olukorrast või probleemist eksplitsi tselt kui 
süsteemist.  
[Crawley 2015] 
 
Mida see tähendab?  
• Süsteemimõttelemine on üks vi s asjadest mõelda  
84 
• nagu loovmõtlemine või loogiline arutelu 
• sel isena ei ole ta formaalne teadus  
• Temast võib mõelda kui süsteemidünaamika pehmest versioonist  
• Süsteemidünaamika kirjeldab süsteemi osade interaktsiooni läbi matemaatika  
• Süsteemimõtlemine kirjeldab samu interaktsioone kuid verbaalselt  
• Vahel ei ole model eerimiseks pi savalt andmeid või on kommunikatsioon täpsusest 
olulisem  
• Süsteemi definitsiooni on sisse ehitatud ​
emergents (emergence)​
: uute funktsioonide 
esilekerkimine. Tervik teeb midagi rohkemat kui üksikud tükid. teatud juhtudel hakkab 
süsteem tegema midagi, mida teda ei ole pandud tegema. Nt tuuletunnelid ­ üksikud majad 
OK, aga kui panna palju maju kokku, si s tekivad tuuletunnelid. Inimesed on surma saanud. 
Sel le tuleb ehitamisel mõelda. 
 
! ​
Süsteemimõtlemine on just insenerivaldkondades sobiv vi s probleemidest mõelda​
. 
 
159. Arhitektuur süsteemimõtlemise kontekstis  
! ​
Arhitektuur on süsteemi osade ja nende omavaheliste seoste abstraktne kirjeldus.  
 
• Ni  lihtne ongi  
• Veel üldisemat määratlust on keeruline leida  
• Samas on ka kõik ära öeldud  
• Ni  võib kirjeldada kõike: organisatsiooni, inimest, tarkvara jne.  
• Kuid lihtsus on petlik ­ lihtne definitsioon on petlik, süsteemid ei ole ni  lihtsad 
• Süsteemi osad võivad ol a organisatsioon, inimene, tarkvara jne.  
• Seosed võivad ol a ni  füüsilised kui mõju avaldavad  
• Kirjeldada võib neid kõiki väga mitmel vi sil (ni  seda mis on või kuidas toimub) 
 
160. Vorm, funktsioon ja kontseptsioon 
● Süsteemi definitsioonis on juttu funktsioonist 
● Arhitektuuri definitsioonis on juttu vormist 
● Kuidas ühest teiseni jõuda? 
○ Kuidas valida funktsiooni täitmiseks sobiv vorm? 
○ Seda tavaliselt peetaksegi arhitekti tööks  
● Appi tuleb kontseptsioon  
○ Hulk mõttemal e süsteemi funktsiooni vormiga sidumiseks  
○ Kuidas me süsteemist mõtleme? 
○ Põhjus, miks Brooksi arvates tarkvara ja​
 tarkvara ehitamine on põhimõtteliselt 
keeruline 
 
Näide: startup ostab amazonist kredi tkaardiga virtuaalsed serverid ja putitab kuidagi käima; 
pank võtab kõigepealt konsultandid ja ostab lõpuks suured füüsilised serverid, testib pikalt ja 
palju. Mõlemal juhul on funktsioon sama, aga vorm erinevad. Mõlemad on sobilikud, valik 
sõltub kontseptsioonist. 
 
! ​
Vorm ja funktsioon on süsteemi omadused, kontseptsioon mõtteline vi s ühest teise 
jõudmiseks​
. 
85 
 
Vorm ​
on see, mis süsteem ​
on 
Funktsioon on see, mida süsteem ​
teeb, 
Kontseptsioon ​
on see, kuidas neist ​
mõelda​
, kuidas jõuda funktsioonist vormini. 
 
! ​
Arhitekti töö seisneb töös vormi, funktsiooni ja kontseptsiooni kui tervikuga​
. 
 
Vorm on see, mis on ­ nt laual on jalad, plate, jooksevad juhtmed välja (füüsiline) 
Funktsioon on see, mis toimub, so kasulik väärtus. 
 
Kulu tuleb vormist, see maksab raha. 
Süsteemi arhitektuur määrab ära maksimaalse kasu/väärtuse (system added value), mida 
süsteem võib toota. 
 
161. Arhitekti roll  
● Arhitekti üks olulisi rol e on ​
keerukuse juhtimine  
● Arhitektuur on vaadeldav rea otsustena  
● Arhitekt, võttes arvesse  
○ kontsepsiooni,  
○ sisendprotsesse ja nende ebamäärasust,  
○ projekti kolmnurka (aeg, raha, funktsionaalsus),  
○ ja muid teadaolevaid pi ranguid,  
teeb otsuseid, mis võimaldavad keerukuse kasvust võimalikult palju kasu saada  
 
!​
 ​
Keerukuse juhtimine on väga oluline ja väga keeruline arhitekti rol ​
. 
 
Kui keegi keerukust ei juhi, si s süsteemid kasvavad üle pea, lähevad li ga keeruliseks. Ei 
osata enam asju juurde ehitada. Arhitekt on ainuke, keda projektis tõeliselt huvitab keerukus 
ja sel e vaos hoidmine, seega ta peab sel ega tegelema. 
 
162. Miks koodi disain on vajalik?  
● Longevity. 
● Code is used for years and years. 
 
Enamus koodi, mida me kirjutame professionaalselt, on pika elueaga. Nt 10 aastat hiljem on 
endiselt kasutusel kood, mida ma kunagi kirjutasin. Sel e pärast on koodi disain ja loetavus 
oluline, et kas on endiselt arusaadav ­ ni  endale kui ka teistele. 
 
86 
Disain mõjutab produkti vsust. Kui lihtsalt kirjutada ja kirjutada ning disainile mitte tähelepanu 
pöörata, si s koodi kvaliteet hakkab langema ja see tõmbab al a produkti vsust. Iga lisatava 
funktsionaalsuse lisamine muutub keerulisemaks. 
 
 
 
163. Clean Code  
! ​
“You know you are working on clean code when each routine you read turns out to be 
pretty much what you expected.”  
–Ward Cunningham 
inventor of Wiki and Fit 
co­inventor of eXtreme Programming 
 
164. Koodi lihtsa disaini neli elementi ja näited  
! ​
Tähtsuse järjekorras: 
1. Passes al  tests ­ testid on olemas ja töötavad 
2. No duplication ­ ei ole copy­paste’i 
3. Expresses intent ­ väljendab kavatsust, mis programmeerijal oli; et mida see 
funktsionaalsus peab tegema, seda ta ka teeb 
4. Smal  
Kent Beck 
— Creator of Extreme Programming, author of JUnit 
 
NAMING ­ nimede panemine 
variables, methods, classes, … 
 
CORRECT ​
ENGLISH ​
ONLY, PLEASE! 
• Word­for­word translation might not be the correct solution 
• Use correct domain terminology ­ ask domain experts what they use 
Kasuta termineid, mis äri tel ija kasutab oma tel imuses ja igapäevatöös! Oluliselt lihtsam on 
aru saada, eriti hiljem kui koodi lugeda. 
87 
• Spel ing and grammar 
• Can you read your code like a story? 
 
Kui miksida erinevaid keeli (ENG, EST), si s tuleb sel est segapudru. Inglise keel on 
universaalne vahend, sobib kõigile olenemata mis on programmeerija emakeel. 
 
Mida suurem on nime nähtavus, seda olulisem on ​
õige ​
nime panemine. Nt klassi nimi 
olulisem kui  muutuja  nimi kuskil sisemises klassis. 
 
Halb näide: 
 
Hea näide sama asja kohta: 
 
 
Veel üks hea näide: 
 
88 
 
Nt col ection on mitmuses, muutuja on ainsuses. 
Map nimi peab vi tama sel ele, et seal on mingi map taga (seos). 
Ühikud tuleks muutuja nimele juurde panna, nt queryIntervalSeconds. Si s on alati teada, et 
kui vastus on 12, si s see on sekundites. 
findCardsBelongingTo(Customer customer) ­ muutuja nimed panna sel ised, et lause kokku 
on loogiline ja ütleb, et mida ta teeb. 
 
Purpose ja context on olulised nimede panemisel. 
 
USE THE SAME TERM CONSISTENTLY 
Tüüpilised näited, mida aetakse segi. Kasuta alati seda, mis on sinu kontektis õige. 
• Customer – Client – Party – Counterparty 
Tarkvara ehitades vältige sõna Client, kuna sel el on palju tähendusi ja kasutatakse 
erinevates varjundites. Kliendi kohta kasutada Customer. Firmad, kel ega suheldada ­ Party 
või Counterparty. 
• state – status 
• Contract – Agreement 
• get – load – fetch – find – retrieve 
• regCode – regNumber – personalCode 
EE isikukood on personalCode 
• … and don’t reuse the same term in another meaning/context 
 
A GOOD FUNCTION 
• short 
• very few indentation levels 
Kui on mitu taset treppi, si s on vihje sel ele, et funktsioon on li ga pikk. 
• does only one thing ­ only one level of abstraction 
Funktsioon ei tohi tegelda mitme asjaga. 
• “Functions should do one thing. 
They should do it wel . 
They should do it only.” 
89 
—Robert “Uncle Bob” Martin 
 
Halb näide: 
 
Iseenesest ei ole pikk funktsioon, aga ta tegeleb mitme tegevuse/asjaga! See teeb sel est 
arusaamist, testimist keerukamaks. 
 
Hea näide sama asja kohta: 
 
 
Tehtud ümber ni , et on 6 meetodit 1 meetodi asemel. Iga meetod teeb ühte asja. 
Exeption handling panna eraldi meetodisse. 
90 
Saab testida eraldi. Kui muudatus on vaja teha (nt muutub kuupäevade formaat, või on 
lubatud veel mingid formaadid), si s tuleb muuta ainult seda ühte meetodit ja ülejäänud jääb 
paika. 
 
FUNCTION ARGUMENTS ­ parameetrite arv 
• Less is more! 
• Ideal y none, one and two are OK 
• Three is usual y too much, anything more is a design smel  
 
Kui on rohkem kui üks parameeter, si s tihti funktsioon ei tegele enam ühe asjaga, nagu 
eelnevalt oli räägitud. 
Kui on üks parameeter, si s välja kutsuja saab paremini aru, et mis parameeter tuleb ette 
anda ja tõenäoliselt saab ka õigema vastuse. Kui on palju parameetreid, si s otsitakse neid 
kuskile kokku. 
 
Kui ühel funktsioonil on palju parameeterid, si s teha eraldi klass, mis tegeleb sel e 
tegevusega, mida see funktsioon enne tegi. Klassi luua erinevad meetodid. Nt oli funktsioon 
registerNewAgreement, kuhu tuli lepingu parameetrid ette anda. 
 
Boolean parameetrid on mõnel juhul OK. Aga ol a ettevaatlik sel e kasutamisega, sest vahel 
ei ole selgelt aru saada, et mida see kood si s täpselt tähendab. 
 
NO SIDE­EFFECTS 
• A function that seems to be read­only according to its name, should behave as such 
• If a function changes state then name it accordingly 
 
Õigel funktsioonil ei ole kõrvalmõjusid, st et kui funktsiooi nimest loeb välja, et ta ainult 
annab andmeid, si s ta ei tohiks andmeid muuta jmt. 
 
Näide halvast koodist: 
 
Ei tohiks lähtuvalt nimest getAmount, si s ei tohiks staatust muuta. 
 
Näide halvast koodist: 
91 
 
Si n nimi ütleb, et ta kontrol ib ainult parooli, tegelikul laadis IP profi li ka lisaks. 
 
Lahendati ni , et funktsioon jäi tegema 2 asja, aga muudeti nime, et oleks aru saada, et ta 
teeb 2­te asja ehk hea näide samast asjast: 
 
 
Kõik get meetodid võiks ühesugused välja näha, näiteks: 
 
 
NO COMMENTS! 
Kommentaarid on saatanast, mida vähem kirjutada neid, seda parem. 
92 
• Comments lie: 
• You cannot tie them to code 
• You cannot refactor them 
• You cannot test them 
• The truth is in the code 
• Do not use a comment when an appropriately named variable or function would do! 
 
Halb näide: 
 
 
Hea näide sama asja kohta ilma kommentaarideta: 
 
Muutuja nimed on muudetud arusaadavaks. 
 
Halb asi on ka koodi välja kommenteerimine. Kui mingit meetodit ei ole enam vaja, si s 
kustutada see meetod ära. Kui tulevikus läheb seda meetodit uuesti vaja, si s leiab sel e 
versiooni haldusest. 
 
WHEN ARE COMMENTS OK? 
Osadel juhtudel me ei pääse kommentaaridest. 
“The proper use of comments is to compensate for our failure to express ourselves in code.” 
• Legal comments ­ nt litsentide kohta 
93 
• Warning of consequences ­ vahel on oluline panna kommentaar, et miks midagi on tehtud. 
Nt open source tarkvara kasutamise tõttu tehtud workaround open source tarkvara bugi tõttu 
ja sel e pärast peab rea koodi juurde lisama. Nt kui mõni meetod on väga ressursimahukas, 
täitmine võtab kaua aega ­ si s väljakutsuja teab, et mida ta välja kutsub ja mis tagajärjed on. 
• TODO comments 
• Amplification 
• javadocs in ​
public ​
APIs ­ avalikult välja antud, ei saa suhelda ja kommentaarid on vajalikud 
 
KEEP YOUR CODE CLEAN! 
 
THE BOY SCOUT RULE 
Leave the campground cleaner than you found it. 
Can you imagine working on a project where code simply got better as time passed? 
Do you believe that any other option is professional? 
See on professionaalne suhtumine. 
 
165. Objektorienteeritud disain  
Suuremad ja kõige olulisemad kontseptsioonid koodi disaini kohta. 
 
1. INTERFACES AND  ABSTRACT  CLASSES 
Ignore  implementation details 
Program to interfaces 
 
JAVA COLLECTIONS API ­ so package, mil est üle ega ümber ei saa 
• ​
Iterable 
• ​
Collection  
• ​
List​
: ArrayList, LinkedList 
99% juhtudel kasutada ArrayListi 
• ​
Set​
: HashSet, LinkedHashSet 
• ​
SortedSet​
: TreeSet 
Sorted näitab, et asjad on kindlas järjekorras. Saab kasutada ka 
kombinatsiooni Set ­> TreeSet. 
• ​
Map​
: HashMap, LinkedHashMap 
• ​
SortedMap​
: TreeMap 
 
Boldiga on abstraktsed klassid / interface’d, mitte­boldiga on konkreetsed 
implementatsioonid. 
 
 
JAVA.IO 
• byte based I/O ­ Tegeleb baitidega. Kasutada, kui tegeletakse ka andmetega 
väljaspoolt javat. 
• ​
InputStream ​
& ​
OutputStream 
• FileInputStream, SocketInputStream, ByteArrayInputStream, 
GZIPInputStream 
94 
• character based I/O ­ Tegeleb characteridega. Kasutada kui ainult java sisene 
rakendus, seal on osad asjad juba lahendatud ­ nt täpitähed. 
• ​
Reader ​
& ​
Writer  
• FileWriter, StringWriter, OutputStreamWriter 
 
2. DEPENDENCY INJECTION INVERSION OF CONTROL 
• The Hol ywood Principle: Don’t cal  us – we’l  cal  you 
• Don’t create your dependencies ­ they wil  be given 
to you 
• Cleaner design 
• Easier to test 
 
3. FAVOR COMPOSITION OVER INHERITANCE 
• Inheritance is for “is­a” relationships ­ when the same interface is most logical 
• Composition is for “consists­of”, “contains”, “uses”, “has” relationships ­ 
providing decoupling – independence of each other's changes 
 
4. IMMUTABILITY 
• An immutable object is an object whose state cannot be modified after it is created 
• What is the most common immutable object in the Java SDK? 
• Why? 
Caching, thread­safety, map keys 
 
166. Disaini mustrid  
PATTERNS  
• Common solutions to frequent problems arising in object­oriented design 
• A systematized catalog of solutions by skil ed and experienced developers 
• Simplifies communication between developers – “we are using the Strategy pattern” 
 
CREATIONAL PATTERNS 
the process of object creation 
Factory  Method 
Abstract Factory 
Builder 
Prototype 
Singleton 
 
STRUCTURAL PATTERNS 
the composition of classes 
Decorator 
Adapter (Wrapper) 
Proxy 
Façade 
Flyweight 
Bridge 
Composite 
95 
Nul  Object 
 
BEHAVIORAL PATTERNS 
how classes or objects interact and distribute responsibility 
Template method 
Observer (Publish­Subscribe, Listener) 
Interpreter 
Memento 
Chain of Responsibility 
 
BEHAVIORAL PATTERNS 
how classes or objects interact and distribute responsibility 
Template method 
Observer (Publish­Subscribe, Listener) 
Interpreter 
Memento 
Chain of Responsibility 
State 
Command 
Strategy 
Iterator 
Visitor 
Mediator 
 
Refactoring to Patterns 
Avoid: 
­ over­engineering 
­ under­engineering 
 
!​
 “A designer knows he has achieved perfection not when there is nothing left to add, but 
when there is nothing left to take away.” 
–Antoine de Saint­Exupery 
 
 
 
167. Finants­ või tehnoloogiaettevõtted?  
Finantsmaailmas ei tegutse enam ammu ainult pangad. Üritatakse äri üle võtta ja teenust 
pakkuda ki remini, paremini. Nt Transferwise, Kickstarter, … 
Kutsutakse sel iseid ettevõtteid FINTECH ettevõteteks. 
 
Samas ka muudes finantsettevõtes: 
96 
Tehnoloogia  ei ole lihtsalt vahend. Üha rohkem ​
äri sisu​
 ja ​
tarkust ​
on tehnoloogias kinni. 
 
LHV teeb koostööd startupidega, kes püüavad pankade äri ära võtta. 
 
168. «Äri», kelle jaoks IT taust on juba eeldus.  
IT­taustaga ametid LHVs: 
•Analüütik 
•Arendaja 
•Kvaliteedispetsialist 
•Administraator 
•IT­tugi 
 
Aga see ei ole kõik. 
«Äri», kel e jaoks IT taust on juba eeldus: 
•Tootearendus 
•Ärianalüüs 
•Andmeanalüüs 
•Kasutajamugavuseanalüüs(UI, UX) 
•Protsessideoptimeerimine 
•Front­endarendusja prototüüpimine 
•Turundus, SEO&SEM 
•jne 
 
Üks suuremaid takistusi maailmas digial kirja lendamiseks on, et pole pi savalt juriste, kes 
saaks aru, kuidas digial kiri töötab, et saaks seadusemuudatusi sisse vi a. 
 
«Äri saab aru, mis on IT võimalused» 
«IT saab aru, mis on äri eesmärgid» 
Sel est enam ei pi sa. 
 
Agi lne arendus ei ole mingi «asi, mida IT teeb» 
Äri peab arenema agi lselt.  
Äri ja tehnoloogia arenevad koos. 
 
169. Lean põhimõtted.  
“Lean” – keskendu sel ele, mida klient vajab 
● Don’t build features that nobody needs right now 
● Don’t write more specs than you can code 
● Don’t write more code than you can test 
● Don’t test more code than you can deploy 
 
Ehita õiget asja 
● Iteratsioonid /tagasiside ­ läbi sel e saab valideerida 
● MVP ­ kõige pisem tükk, mida saab kasutajale anda ja mil e pealt saab tagasisidet 
● Mõõdikud 
○ Miks, mida, kuidas mõõta? 
97 
○ Kuidas aru saada, et midagi muutub paremaks, ki remaks, efekti vsemaks? 
○ Actionable metrics (nende pealt saab otsuseid teha) vs. Vanity metrics (ilusad 
graafikud, aga midagi tarka tihti peale hakata pole) ­ oluline muuta asju, mida 
päriselt ka vaja on mõõta. 
 
Ehita asi õigesti 
● „Raiskamise“ minimiseerimine ­ ära tee asju sel iselt, et keegi ei taha kasutada 
● Kvaliteedi sisse ehitamine 
 
Pidev areng 
● Isiklik areng ja meeskonna areng peab olema, toodet tuleb paremaks teha jmt 
 
170. Arenduse infrastruktuur ja konfiguratsioonihaldus  
 
171. Mida endast kujutab arenduse infrastruktuur? 
  
 
Inimesed: 
• Oluliseim komponent 
• Suhted ja suhtlemine on nagu õli, mis paneb kogu masinavärgi 
tööle 
• Tööri stad üksi tööd ei tee 
• Klient, testija, arendaja ... 
 
 
172. Milleks hallata nõudeid?  
! ​
Nõuetest arusaamine on eduka projekti alus. 
 
Mil eks nõudeid hal ata? 
• Muutuvad ajas 
• Ununevad 
• Olulisus muutub 
• Tekivad ja kaovad 
98 
• Folkloor 
• Ebakõlad/vead 
• Progressi jälgimine 
 
 
 
Mil ega hal ata? 
• Tekstiredaktor 
• Google Docs 
• Joonistamise vahendid (mocuping/wireframing) 
• Pivotal Tracker (www.pivotaltracker.com) 
• JIRA ( https://www.atlassian.com/software/jira ) 
• ... 
 
Nõuete osas praktilisi näpunäiteid: 
• Vahendite puhul alusta minimaalsest, mis sul on vajalik 
• Pane kirja koos kliendiga 
• Tee võimalikult väikeseks 
• Räägi 
 
173. Milleks planeerida? 
! ​
Plans are worthless, but planning is everything. 
Dwight D. Eisenhowe​
r 
 
Planeerimine​
: 
• Alusta väga üldisest 
• Planeerimine ei ole ainult kuupäevad, mil al asi peab valmis olema 
• Nõuete olemasolu/puudumine annab plaanidele uue mõõtme 
• Resursside olemasolu/puudumine 
• Plaane tuleb ümber vaadata ja muuta vastavalt olukorrale 
• Plaan on realistlik kuni 2 nädalat ette 
 
Planeermise vahendid​
: 
• Paber, pli ats. Whiteboard 
• Excel 
• MS Project 
• JIRA, Pivotal Tracker 
! ​
Hea vahend on osa nõuete haldusest. 
99 
 
Arendusvahendid​
: 
• “notepad” 
• vi/vim 
• Eclipse 
• NetBeans 
• Intel iJ IDEA 
• XCode 
• AppCode 
• Visual Studio 
• + 100 muud vahendit lisaks 
 
• Õigesti valitud vahend võib tõsta arendaja produkti vsust väga palju 
• Õpi oma vahendit kasutama ja tunne sel e võimalusi 
• Kasuta shortcute 
• Ära aja pilti li ga kirjuks 
 
Planeerimise ajal mõtle: 
 
  
174. Versioonihaldus.  
Versioonihaldus: 
• Ajalugu. Seotus nõuetehaldusega 
• Muudab arenduse paindlikumaks. 
• Meeskonnatöö 
• Ausaamise, mil ine lähtekood on hetkel toodangus 
• Kes sel e si a tegi? 
 
Miks versioniseerida? 
 
 
Hajusad vahendid 
• Git /  GitHub  
• Mercurial 
100 
• TeamWare 
Tsentraliseeritud vahendid 
• SVN 
• CVS 
• Perforce 
• Microsoft TFS 
 
GIT: 
 
 
SVN: 
101 
 
 
GitHub ( https://github.co m) 
BitBucket ( https://bitbucket.org )­ Rohkem kui ainultversioonihaldus 
• Projekti kodu: 
• Lähtekood 
• Wiki 
• Reli sid 
• Veahaldus 
• Harud (branch) ­ luuakse repositooriumi peaharust eraldi haru 
• Projektid arendatakse harus ja mergetakse peaharru 
• Harus arendatakse eksperimentaalset osa 
• Ainult pikad projektid harus, lühemad peaharus 
• Mil eks peaks harudega ettevaatlikult ringi käima? 
 
175. Build/Deploy. Toodangusse minek.  
Iga commiti järgi peab tekkima veendumus, et töötab ka kood, mis on koodihoidlast 
kättesaadav. 
 
Continuous integration: 
• Kompileerib vajadusel koodi 
• Koodianalüsaator? 
• Paigaldab rakenduse 
• Käivitab unit testid 
• Käivitab funktsionaalsed (UI) testid 
 
Build/deploy vahendid: 
• Shel  script 
• Ant script 
• Jenkins ( http://jenkins­ci.org/ ) 
• Atlassion Bamboo ( https://www.atlassian.com/software/bamboo ) 
• Cruise Control ( http://cruisecontrol.sourceforge.net/ ) 
• Travis CI ( https://travis­ci.org ) 
102 
• Circle CI ( https://circleci.co m) 
 
Toodangusse minek: 
• Väldi käsitööd. Sel ega kaasnevad vead. 
• Kasuta seda tulemust, mis sa continuous integration vahenditega juba valmis tegid. 
• Kui ei saa si s tee selgeks, miks ei saa. Elimineeri need põhjused ja kasuta ikka. 
• Kui si s ka ei saa si s kasuta vähemalt samu build skripte. 
• ... muudmoodi li gub asi kontrol imatuse suunas. 
 
Sõltuvuste haldus: 
• Sõltuvused koos lähtekoodiga repositooriomis 
• Sõltuvused hal atakse vahenditega 
• Ivy, Maven 
 
Rakenduse konfiguratsioon: 
• Dünaamiline, sõltub keskkonnast 
• Staatiline, luuakse rakenduse ehitamisel 
• healthy mix 
 
Konfiguratsioon: 
• .properties fail, .ini fail, .yaml 
• XML, servlet 
• andmebaas 
• JNDI 
• lähtekood 
• ... 
 
! ​
Proovi saavutada olukord, kus versioonihaldusest tulev asi on kompileeruv ja vajadusel 
pakenduv kohe, ilma lisakonfigureerimisteta. 
 
176. Virtualiseerimine.  
Mil eks? 
• Arendus mitmele operatsioonisüsteemile 
• Arendus 
• Testimine 
• Erinevatele operatsioonisüsteemidele kompileerimine (continuous integration) 
 
Töölaua/serveripargi vitualiseerimise vahendid: 
• Paral els Desktop 
• VM Ware Workstation 
• Virtualbox ­ tasuta 
 
 
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ 
 
Näited: Mida küsiti eksamil eelmisel aastal? 
103 
 
● Kvaliteetse tarkvara funktsionaalsed ja mittefunktsionaalsed atribuutid.  
 
● Metoodikad tarkvaraarenduses ja mida nad kirjeldavad.  
 
● Erinevate tarkvarasüstemide nõuete kirjeldamine. Näiteks panga veebi 
iseteeninduskeskkond, iPhone aplikatsioon jne. Nõuete vastavus nõuete kolmele 
olulisele omadusele.  
 
● Komponentidel, teenustel jne. põhinevad arhitektuurid. Erinevate arhitektuuride 
positi vsed ja negati vsed omadused, kasutusvaldkonnad.  
 
● Mudeli olemus ja mudelite klassifitseerimine.  
 
● Tarkvarasüsteemi kvaliteediatribuutid ni  lõppkasutaja, arendaja ja kui äri 
vaatenurgast. Igaühe mõju süsteemi arhitektuuriotsustele.  
 
● Testitasemete (test levels) teooria ja erinevate tasemete kirjeldused.  
 
● Clean Code põhimõtted ja erinevatele reeglite vastavus.  
 
● Tarkvara arendusmetoodikate (XP, Scrumi, Kanban, jne.) elemendid ja nende 
kirjeldused.  
 
● Olulised protsessid ja tegevused IT­teenuse toetamise juures.  
 
● Tsentraalse ja hajutatud mudeliga versioneerimise vahendid ja erinevused nende 
kahe mudeli vahel.  
104