Tarkvaratehnika kordamisküsimused (0)

5 Hindamata

Esitatud küsimused

  • Kuidas see on sisendiks järgmisele tegevusele ?
  • Kuidas viia auto süsteem sellisesse olukorda, et ta saaks juhita liiklusesse lasta ?
  • Millist probleemi me selle projektiga lahendame ?
  • Miks on EE­s nõuete kaardistus vajalik ?
  • Millist testimist valida järgmiste näidete puhul ?
  • Kes vastutab arhitektuuri eest agiilse arhitektuuri puhul ?
  • Kes vastutab arhitektuuri eest agiilse arhitektuuri puhul ?
  • Mida tegid eile ?
  • Kui asi antakse üle Product Ownerile, siis tehakse project retrospektiiv ­ mis oli hästi ?
  • Milleks on mudeleid vaja​ ?
  • Mis eesmärke süsteem peaks saavutama ?
  • Millised rollid on nende eesmärkide saavutamiseks vajalikud ?
  • Mida süsteem peaks tegema ?
  • Mis osadest süsteem koosneb ja kuidas need on omavahel seotud ?
  • Milliseid teateid süsteemi osad vahetavad omavahel ja kasutajaga ?
  • Millist informatsiooni tuleb süsteemis esitada ?
  • Kuidas süsteemi olemid käituvad ?
  • Kuidas muuta sisendit soovitud väljundi saamiseks ?
  • Mida see tähendab ?
  • Kuidas ühest teiseni jõuda ?
  • Kuidas valida funktsiooni täitmiseks sobiv vorm ?
  • Kuidas me süsteemist mõtleme ?
  • Miks, mida, kuidas mõõta ?
  • Kuidas aru saada, et midagi muutub paremaks, kiiremaks, efektiivsemaks ?
  • Milleks nõudeid hallata ?
  • Millega hallata ?
  • Miks versioniseerida ?
 
Säutsu twitteris

TARKVARATEHNIKA  KORDAMISKÜSIMUSED 
  

1. Mis on tarkvaratehnika? 
Software engineering 
 

! ​“Engineers  Australia ” definitsioon: ​
Tarkvaratehnika ​on tiimide poolt rakendatav  distsipliin  
tootmaks kõrgekvaliteedilist, suuremastaabilist ja hinnaefektiivset  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ähehemisviisi rakendamine  tarkvara   arendamisele , käitamisele ja hooldamisele, see 
tähendab, inseneriteaduste rakendamine tarkvarale.  
 
Tarkvaraarendus ​ on nõrgem termin, kus tingimata ei kasutata protsesse, tööriistu, 
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 hallatakse ja kontrollitakse: 
● Kvaliteeti  
● Keerukust  
● Ressursse:  eelarvet , aega, inimesi  
● Riske 
 
! ​Tarkvaratehnika e. tarkvara inseneeria on ​professionaalsele tarkvaraarendusele suunatud 
distsipliin​
, mis tegeleb sellega, ​
kuidas organiseerida tarkvaraarendust  
 

2. Miks vajame tarkvaratehnikat?  
Kõrgenenud nõudmised tarkvara arendamisele 

● suuremad süsteemid  
● keerulisemad süsteemid;  
● kiiremini.  
 
Suuremastaabiline  programmeerimine  vrdl väiksemastaabiline programmeerimine. 
Näiteks: 
Asjalik  mees või naine suudab ehitada tööriistakuuri oma maja või  suvila  juurde. Kas 
seesama inimene saab hakkama ka 30­  korruselise  kontorihoone püstipanekuga?  
● Insener suudab valmis programmeerida lihtsa kontrolleri. Kas seesama insener saab 
hakkama ka lennuliikluse kontrollsüsteemi programmeerimisega? 
 

3. Milleks tarkvaratehnika?  

Tarkvara tööstuse kriis 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 distsipliin), kuidas tulla toime 
tarkvaratööstuse kriisiga. 
 

4. Tarkvaratehnika „point“?  
● Tarkvaratehnika = tarkvara ​ inseneeria​. 

● Tarkvaratehnika on suunatud ​ professionaalsele ​tarkvaraarendusele (on olemas ka 
personaalne  tarkvaraarendus ­ sellega ei tegele). 
● Tarkvaratehnika ei tegele tarkvaraarenduse endaga (nt  programmeerimiskeeled
algoritmid ) vaid sellega, ​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  
● Efektiivne  
○ Tarkvara ei tohi raisata süsteemi ressursse  
● Vastuvõetav  
○ Tarkvara peab olema aktsepteeritud kasutajate poolt, kelle 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 ­ tellija, nt mingi ettevõte 
● Arendaja 

● Kasutaja 



 

8. Tarkvaratehnika kui distsipliini eesmärgid.  

● Kuluefektiivne tarkvaraarendus ­ töö tuleb korraldada nii, et tuleb ots otsaga kokku 
● Tarkvaraarenduse  organiseerimine  kogu tarkvara elukaare ulatuses, arvestades 
organisatsiooniliste (inimeste) ja rahaliste piirangutega ­ kuidas inimeste t ööd  
organiseerida 
●  Hõlmata tarkvaraarenduse kõiki aspekte, mitte ainult  tehnoloogiad !  
 
! ​
Tarkvaratehnika eesmärgiks on ​ kuluefektiivne​ tarkvaraarendus ​ kogu tarkvara elukaare 
ulatuses.  
 

9. Tarkvaratehnika kontekst.  

● Tarkvaratehnika ei ole isoleeritud distsipliin 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 selle organisatsiooni tööd, selle organisatsiooni 
inimeste tööd ja protsesse selles 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  riistvara  
(tehniline pool süsteemist) ja olla 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 riist­ 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 nii tehnilisi süsteeme kui ka inimesi, kes 
kasutavad tehnilisi süsteeme ja suhtlevad nendega ning kasutusprotsesse. 
○ Süsteem, mis koosneb riistvarast, 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 riistvara, tarkvara ja andmete muudatustest.  
Me ei saa ennustada süsteemi käitumist. 
○ Sotsio­tehniliste süsteemide “kihiline  tort ”: 



 
 
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, installeerimise ja hooldamise protsess.  
● Selles kursuses piirdume tarkvaratehnikaga, süsteemitehnikat ei käsitle. 
 

13. Millised on parimad tarkvaratehnika meetodid?  

Erinevat tüüpi meetodid erinevat liiki süsteemidele. Ei ole olemas parimat meetodit kõige 
jaoks. 
 

14. Tarkvararakenduse liigid.  

● Kohalikud ( stand ­ alonerakendused , nt. MS Office ja fotode manipuleerimise 
süsteemid 
● Interaktiivsed transaktsioonipõhised rakendused, nt. pangarakendused ja 
e­kaubanduse rakendused   
● Mähisrakendused (embedded  control  systems), nt. ABS­pidureid ja  mikrolaineahju  
kontrollivad süsteemid   
● Andmetöötlusrakendused ( batch   processing  systems), nt. arvete ja palgaarvestuse 
süsteemid  Meelelahutusrakendused, nt. mängud   
● Modelleerimis­ ja simulatsioonirakendused   
● Andmekogumisrakendused (data  collection  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, piiranguid ja ressursse mingit liiki tulemi 
loomiseks .  
 
Piirangud ­ nt seadusandlusest tulenevad piirangud, tehnikast endast tulenevad piirangud 
(mida suudab teha, mida ei suuda teha). 
Ressursid  ­ nt inimesed,  loodusressursid , arvutusressursid 
 
Näiteid protsessidest: 



● Õppimine 
● Organisatsiooni äriprotsessid 
● E­pangas ülekande tegemine 
 

16. Mis on tarkvara arendusprotsess e. tarkvaraprotsess? 

! Tarkvaraprotsess ​ on sammude jada, mille eesmärgiks on tarkvara loomine ja  haldamine
Üldistatud tegevused tarkvaraprotsessides:  
● Spetsifitseerimine – mida süsteem peab tegema ja mis on piirangud 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
○ Rollikeskne ( 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 liiki tarkvaraprotsesse: 

● Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu 
kriteeriumiks on plaani järgmine 
● Agiilne tarkvaraprotsess:  planeerimine  toimub sammude kaupa töö käigus 
 
Ei saa öelda, et  kumb  on õigem. Oleneb sellest, mida luuakse ja konkreetsest rakendusest. 
Teatud liiki rakenduste puhul on õigustatud plaanipõhine protsess ­ nt missioonikriitilised 
rakendused. 
 

19. Tarkvaraprotsessi mudelite tüübid.  

● Kosk   


● Iteratiivne arendamine   
● Komponendipõhine arendamine 
 
Tegelikult on mudeleid veel, aga siin aines ei käsitle. 
 





 
 

20. Kirjelda Kose mudeli koos puudustega ja eelistega.  




 
Kõik sammud on järjest. 
 
Puudused:   
● Saab kasutada ainult siis, kui nõuded on fikseeritud   
● Iga tarkvaraprotsessi etapp peab olema lõpetatud enne kui alustatakse järgmist 
etappi    
● Kliendi tagasiside tuleb ainult lõpus. Siis enam ei saa või on kallis 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?  



 
Nooled on mõlemas suunas. isegi kui asi on live’s, saab nõuete juurde tagasi tulla. Aga 
nende muutmisel tuleb jälle kõik sammud sama  kose  mudeli alusel läbi käia. Ei ole piisavalt 
agiilne, iteratiivne. 
 

22. Mis on iteratiivne arendamine? Eelised ja puudused?  




 
Agiilne on iteratiivse arendamise üks alamliik. 
 
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?  



 
 
Püüame valmisolevad osad kokku panna ja minimiseerida uute osade kirjutamist. 
Nõudeid muudame vastavalt sellele, millised komponendid on saada. 
See võib olla nii kose mudelil põhinev kui ka iteratiivne. 
 
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   
● Kiirem arendusprotsess   
Puudused:   
● Suuremad hoolduskulud   
● Komponentide teegi ülalpidamine ­ selleks 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



 




 
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 viisil, kui 
soovivad olla 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 talle 
endale kasulik tegevus on ühiskonnale halb. 





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 piirdu vaid tehniliste oskuste 
rakendamisega
 
● Konfidentsiaalsus   
○ Tarkvarainsener peab respekteerima oma  tööandja  ja klientide 
konfidentsiaalsust, sõltumata sellest, kas  formaalne  leping konfidentsiaalsuse 
kohta on alla 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 
Intellektuaalne  omand   
○ Tarkvarainsener peab olema teadlik kohalikest  seadustest  ja määrustest, mis 
sätestavad intellektuaalse omandi kasutamise näiteks patentide ja 
kopeerimisõiguse näol. Ta peab olema ettevaatlik, et tööandjate ja klientide 
intellektuaalne 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 (viiruste 
levitamine ja teiste arvutite ründamine) 
 

30. ACM/IEEE eetikakoodid ja printsiibid ning nende seletused.  

ACM ja IEEE liikmed allkirjastavad liitumisel vastava organisatsiooni eetikakoodeksi. 
Eetikakoodeks  sisaldab  kaheksat  põhimõtet  professionaalsete  tarkvarainseneride käitumise 
ja  otsustuste  jaoks. 
 

8 printsiipi: eetikakoodeksist: 
● PUBLIC   

○ Software engineers  shall  act consistently with the public interest.   
CLIENT  AND EMPLOYER   
○ Software engineers shall act in a  manner  that is in the  best  interests of their 
client and employer consistent with the public interest.   
● PRODUCT   
○ Software engineers shall ensure that their  products  and  related  modifications 
meet the highest professional standards possible. 
● JUDGMENT   
○ Software engineers shall maintain integrity and  independence  in their 
professional judgment.   
MANAGEMENT    



○ Software engineering managers and leaders shall subscribe to and promote 
an ethical  approach  to the management of software  development  and 
maintenance. 
PROFESSION    
○ Software engineers shall advance the integrity and reputation of the 
profession consistent with the public interest. 
● COLLEAGUES   
○ Software engineers shall be  fair  to and supportive of their colleagues.   
● SELF   
○ Software engineers shall  participate  in  lifelong   learning  regarding the  practice  
of their profession and shall 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 poliitikaga?   
● Sinu tööandja käitub ebaeetilisel viisil väljastades ohutuskriitilise 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/tellijalt ja paneb selle 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 siis 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  fully understand and define ...  < strong > -  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 selle pärast, et võib­olla 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:  actorsprocesses , 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 viia as­is süsteemi paremasse olukorda. Nt 
kuidas viia auto süsteem sellisesse olukorda, et ta saaks juhita liiklusesse lasta? 
 
Kõiki nõudeid ei saa alati täita, kuna see võib olla liiga kallis. Nõuded tuleb alati valideerida 
ka nt protsesijuhi või juhtidega, eriti siis 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 kiire. 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  - Milliseid 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: 
! ​
Millist probleemi me selle projektiga lahendame? 
Kui sellele küsimusele pole selget ja ühelauselist vastust, siis projekt rohelist  tuld   ei tohiks 
saada. 
 
Miks on EE­s nõuete kaardistus vajalik? 
• Suures ettevõttes vananeb nii  dokumentatsioon  kui teadmus tohutu kiirusega 
•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  will 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 
milleks  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. Liikumise aeg peab olema optimaalne, minimaalne. 
Tarkvara nõuded/eesmärgid nt: Kontrollib 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, sellest tulevad nõuded (sh piirangud). 
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 liiklema ohutult. 
Auto peab liikluseeskirjadest kinni  pidama
Peab suutma ise  parkida .  
 
Nõudeid  tulevases  süsteemi hakkavd täitma teatud  agendid . Nii kaua räägime  eesmärkidest  
kuni ta ei ole omistatud agendile, kes hakkab seda eesmärki täitma (siis 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 kiirus on suurem kui 0, siis 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: kiirus (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 olla hind või nt välja töötamise 
aeg. 
Mittefunktsionaalne nõue on ka see, et  muudatuste  sisse viimine 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 installimise 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/ tellija  ja täideviijad.  
 
! Nõudeid peab olema võimalik täita. 
Nt nõue: kui midagi tuleb rongi teele ette , siis  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, siis peab hakkama rong kohe 
pidurdama. 
 





 
Enne kui hakkate programmerima, mõelge nõuded läbi. Nii 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, siis näiteks internetipangas võib raha minna valele kontole, 
lennukis tekivad lendamisel probleemid ja inimesed saavad surma. 
 
Nõuetele vastavuse kontrollimine on ainult üks osa kvaliteedist. 
 
Kvaliteeti ei saa testida. Saab testida näiteks nõuetele vastavust. 
Halvasti arendatud süsteemi pole võimalik kontrolli abil heaks muuta.  
Lõpptulemus  sõltub kogu arendusprotsessist:  
● sealhulgas vajadustele vastavast riistvarast  
● 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 kiirustamine ja pole aega ühte asja valmis saada, juba tuleb järgmine") – 
ideaalset kvaliteeti ei pruugi tõesti olemas olla; tihti on see mitte saavutatav ja 
ebaotstarbekas.  
● Kvaliteet kui mingi tootja või kaubamärgiga kaasas käiv omadus ("see on 
kvaliteettoode") – selline 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 hotelli 
kvaliteet väga hea") – selline suhe on alati olemas ja abiks hinnaefektiivsel 
tegutsemisel kõigis rollides.  


22 
● Kvaliteet kui mõõt – mõõt on alati olemas (ka näiteks siis, kui "selle süsteemi 
kvaliteet on madal"). 
 

56. Millest koosneb tarkvaratoode?  
Tarkvaratoode koosneb järgmistest komponentidest: 

● Arenduse käigus hangitud infotehnoloogiavahendid: riistvara, 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); installatsioonid, kohandamised, muudatused; 
andmehõive. 
● Muudatused tellija organisatsioonis, protsessides, töökorralduses... Oluline, et kes 
teeb muudatusi, kuidas neid sisse viia, kes jälgib? 
● Metoodika: tulemuste kasutamine; tulemuste edasiarendamine; uute arenduste 
tegemine. 
● Projektdokumentatsioon kasutamise kohta (kasutajajuhendid); objektsüsteemi (nt 
organisatsioon , mille jaoks tarkvara arendatakse) kohta; loodavate objektide kohta 
(programmi/testimise dokumentatsioon); installeerimise 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 taellija 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 kuluefektiivne;  
● Kasutaja võib soovida loetavat kirja ekraanil;  
Hooldaja  näeks heameelega arusaadavat koodi;  
● jne.  
Need nõuded tuleb kirja panna ja selle 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 tellimist. 
 
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 piiridesse; Süsteem peab teatud 
ajavahemike  jooksul tõrgeteta töötama.  
 
Tavalised need on:  

1. Süsteemsed nõudmised ja piirangud  

2.  Tõhusus , turvalisus, töökindlus,  kasutajaliides  (kasutajamugavus) jne  

3. Muud piirangud  
 
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, 
kasutusaktiivsuse Y ja kasutuslaadi Z korral olla häiritud maksimaalselt ühe tunni 
jooksul. 
 

62. Nimeta nõue, mis on mittetestitav.  
Mittetestiv nõue: Süsteem peab olema töökindel.  




25 
Siin ei tea, et mida  töökindluse  all mõeldakse. Kui kirjutada see nõue ümber nii nagu 
eelmises punktis testitav nõue 2, siis on OK.  
 

63. Mis on reaalne nõue?  

Nõue võib olla testitav, kuid ebareaalne, ebamõistlik, ebapiisavalt spetsifitseeritud jne.  
 
Näide: Süsteemi vastuse aeg peab jääma alla 3 sekundi.  
 
See on üldiselt reaalne nõue, aga testimiseks on siin liiga 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 selline 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 kellegi 
jaoks ei ole nõudes olevad sõnad arusaadavad, siis 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 sellele 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 modelleerib tegelikkust ja võib olla väga keerukas, samuti võib olla väga keerukas 
selle arendus.  


26 
Et selle 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,  ekspluatatsioonhoolduskonfiguratsiooni  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.  
mudelis  on arendus­ ja testtegevused paigutatud sümmeetriliselt nii, et igale 
arendustegevusele vastab sobiv  kontrollimisviis .  
 





 
 


27 
70. Mis on  testimine ?  
Kitsamas mõttes on testimine tarkvara  täitmine  /  käivitamine  kontrollimaks, 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 (nii staatilistest 
kui ka dünaamilistest) koosnevat protsessi, mis puudutab ​ tarkvara ​ja sellega seotud ​
toodete 
planeerimist​
, ​
ettevalmistust ​
ja ​
hindamist ​
ning mille 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?  

Efektiivseks  testimiseks ei piisa vaid süsteemist. On vaja teada ​
nõudeid ​ja ​
protsesse​
, mis 
omakorda tulenevad: 
● Ülesande püstitusest 
● Organisatsioonist 
● Seadusandlusest 
● Standarditest 
● Riskianalüüsist 
● Headest  tavadest  
● Kasutajatest 
● Kasutusviisist 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, mille 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:  
● Rakendusliideste (API) testimine​  – rakendust testitakse avalike ja privaatsete 
rakendusliideste kaudu  
● Koodi ulatus​  – luuakse teste, mis testivad koodi ulatust. Näiteks testi  disainer  võib 
luua testi, mille käigus kõiki avaldisi (lauseid/käske) programmis käivitatakse 
vähemalt ühe korra.  
● Vigade süstimine​  – koodi ulatuse parandamine kontrollides, 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 selle sisemisest teostusest.  
Musta kasti testimismeetodite hulka kuuluvad:  


29 
● Spetsifikatsiooni põhine testimine  
Juhuslikud   sisendid  ja lisatud vead  
Uurimuslik  testimine  
Piirväärtuste  analüüs  
● Suitsu testimine  
● Kasutusmugavuse testimine 
 

77. Halli kasti testimine.  

Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja algoritmidele 
testjuhtumite koostamisel, kuid testimine viiakse läbi kasutaja või musta kasti tasemel. 
 
Halli kasti testimise alla kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja 
väljaspool testitavat süsteemi andmeid muuta.  
 
Halli kasti testimine võib hõlmata ka pöördprojekteerimist leidmaks näiteks piirvää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 stiilis, et kontrollida, kas mingi 
funktsioon töötab, nagu ette nähtud.  




30 
Ühe funktsiooni kohta võib olla mitu testi, et kontrollida funktsiooni töötamist 
piirväärtustel või erinevaid koodi harusid.  
Ühiktestimisega ei saa tagada terve tarkvaratoote õigsust. Pigem kontrollitakse 
sellega, kas erinevad tarkvara osad töötavad üksteisest eraldi. 
 
2. Lõimumise testimine (Integration testing) 
Kontrollitakse, kas komponentide vahelised liidesed vastavad tarkvara disainile. 
Tarkvara komponente võib integreerida järk­järgult või ühekorraga.  
Tavaliselt eelistatakse viimast, sest nii saab kiiremini leida ja parandada vigu 
liidestes. Selline testimine  paljastab   defektid  liidestes 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 viia varem kasutatud teste, et 
kontrollida, kas eelnevalt kindlaks tehtud  rikked  on taas esile kerkinud.  
Regressioonitestimise ulatus sõltub arendustegevuse etapist ja lisatud 
funktsionaalsuse kaalukusest.  




31 
Testimine võib olla 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. Viiakse läbi proovitest, et kontrollida, 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 riistvaral, 
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 kriitilisi 
riske. 
○ Uuriv testimine 
■ Uuriv testimine (exploratory testing) on  mitteformaalne  tarkvara 
testimise tehnika, mille 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, milleks 
on:  
■ üldised teadmised  
■ teadmised konkreetse rakendusvaldkonna kohta  
■ teadmised riist­ 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 tellija kohta jne 
■ ! kasutusmugavuse testimine 
 
3. Mittefunktsionaalne testimine 
○ Jõudlustestimine 
■ Jõudlustest kontrollib, kui kiiresti tarkvara töötab kindla koguse 
andmete või  kasutajatega .  
○ Koormustestimine 


32 
■ Koormustestimisega kontrollitakse, kas tarkvara suudab püsivalt 
töötada kindlal koormusel. Kui koormustestimist tehakse 
mittefunktsionaalselt, siis nimetatakse seda tihti vastupidavuse 
testimiseks.  
 
Jõudlustestimise ja koormustestimise all mõistetakse tihti sama asja. 
 
○ Stabiilsus testimine 
■ Stabiilsuse testimine kontrollib, kas tarkvara on võimeline pidevalt 
töötama kindla ajaperioodi jooksul. Seda nimetatakse mõnikord 
vastupidavuse testimiseks. 
 
○ Kasutatavuse testimine 
■ Kasutuse  katsetamine  on vajalik, et kontrollida, kas kasutajaliidest 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. 
 
○ Destruktiivne testimine 
■ Destruktiivsel testimisel üritatakse tekitada tõrkeid 
tarkvaraprogrammis või käivituskeskkonnas, et testida selle 
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. Sellel etapil töötavad testijad arendajatega, et teha kindlaks, millised tarkvara 
aspektid on testitavad ja milliste  parameetritega  need testid töötavad. 
● Testimise planeerimine​ . Testimise strateegia, plaani ja testimiskeskkonna loomine. 
Kuna testimisel on palju tegevusi, siis 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 selle kohta, kas tarkvara on valmis väljastamiseks. 
● Testitulemuste või vigade analüüs​ . Seda teeb arendusmeeskond tavaliselt koos 
kliendiga, et otsustada, milliseid vigu tuleks parandada, millised tagasi lükata (st leiti, 
et tarkvara töötab korralikult) ja milliseid vigu parandada millalgi tulevikus. 
● Vigade uuesti testimine​ . Kui arendusmeeskond on üritanud viga parandada, siis 
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  viimased  muudatused midagi ei lõhkunud ja et tarkvaratoode tervikuna töötab 
endiselt õigesti.  
● Testimise  lõpetamine ​ . Kui katse vastab  lõpetamise  kriteeriumitele, siis tegevused 
nagu väljundi  püüdmine , õppetunnid, tulemused, logid ja projektiga seotud 
dokumendid  arhiveeritakse ja neid kasutatakse viitena tulevastes projektides. 
 

81. Millal lõpetada testimist?  

Testimise resultatiivsust 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 nii vaid tõesti kriitiliste rakenduste korral. Põhjusi on 
palju, näiteks: 
● nõudeid ja nende rahuldatust on raske hinnata;  
● töö tuleb kiiresti üle anda;  
● on olemas eelnev kogemus ja see määrabtestimise mahu;  
rakendus  ei ole kriitiline (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üll  
● Süsteemi üleandmise tähtaeg on käes  
● Paistab, et edasine testimine ei anna uusi vigu  
● Pole enam huvitav, tahaks midagi muud teha  
● ja nii edasi 
● Kõik ekvivalentsiklassid (piirjuhud) peavad olema testitud  


34 
● Testimine peab vastama haruadekvaatsuse kriteeriumile  
● Olulisemad andmekombinatsioonid peavad olema testitud  
● Andmepõhise testimise piirjuhud 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: Riigiameti süsteemis testiti dokumenti, digiallkirjastati. 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üll. 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 millega 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 mille jaoks. 
● Oskus ja julgus küsida  küsimusi . Ka teravaid küsimusi. Aga viisakalt. ­ Miks see on 
ikka nii on  lahendatud ? Miks see spekis nii kirjas on? Kas klient tahtiski seda? 
● Uudishimu ­ kui ei huvita, siis ei tule testimine hästi välja. Tulemus on heal juhul 
keskpärane, pigem vilets. Peab olema uudishimu, et “mis siis, kui”… (nt seda nuppu 
ka vajutan, seda nuppu 2 korda kiiresti 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 arendustiimi osa ja 
saab arendajatelt kiiresti 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. Selle 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. Sellele on suurem osa. 
● Staatiline testimine ­ programmi käivitamist ei toimu. Vaadatakse muid asju. 
Nt kasutajajuhendid käivad ka siia alla. So valge kasti testimine. Sellel 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. Kontroll, et programm mujal töötab 
endiselt. 
● Re­testimine ­ see on mingi veaparanduse üle testimine, et kas viga on 
parandatud ja korras. Sellele 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 kiirem, 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 kasutajaliideseni. Mis 
läheb sinnani ja üles poole, on liiga kallis ja ajamahukas automatiseerida. 
Oluline on automaattestid pärast ka töös hoida (nt kui programmi 
muudetakse). 
 
Millist testimist valida järgmiste näidete puhul? 
1. Desktop nimegeneraator lapsele nime valimiseks ­ ei ole tegemist kriitilise 
süsteemiga, piisab manuaalsest testimisest. 
2. Netipanga raha ülekandmis rakendus ­ teha kõik testid, mis pähe tulevad. Kindlasti 
testida turvalisust ja kiirust. 
 

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  piire  ­ lisaks programmile, ka stressitaluvust ja töövõ imet  saab 
kombata. 
4. Suhelda saab palju ja paljudega ­ oluline ka info jagamine tiimiga. 
5. Zen töö ­ kui vahest viskab kopa ette, siis 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 illustratsioon, 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 sellest, et mida sinna peale ehitatakse (paralleel maja 
ehitusega). 
 

88. Erinevused funktsionaalsest disainist.  

IEEE 1990 sõnastikust erinevate disaini mõisted:  
● Arhitektuurne  disain ​  ­ protsess, mille käigus defineeritakse ​
riistvara​
 ja ​
tarkvara 
komponendid ja nende liidesed, kujundamaks välja raamistikku tarkvara 
arendamiseks. 
! ​
Arhitektuuri osad on nii riistvara kui tarkvara. 
● Eeldisain ­ protsess, mille käigus analüüsitakse arhitektuuri alternatiive ja 
defineeritakse arhitektuur, komponendid, liidesed igale tarkvara komponendile. 
● Detaildisain ­ eeldisaini tulemi laiendamine/täpsustamine saavutamaks vajalikku 
täpsust arendamise alustamiseks 
● Funktsionaaldisain​  ­ protsess, mille 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 controllerist otse teenuskihti pöörduda.  
Kui üks maja akna klaas lõhutakse ära, siis hiljem läheb järgmine katki ja nii kuni selleni, et 
maja  kukub  kokku. 
 
Arhitektuuri mõistes on kaos. Puudub vundament, mille 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 selline lahendus, mille puhul suhlus käib läbi serverite. 
 
Kasu​: 
● Kõrgem turvalisus 
● Andmed on tsentraliseeritud 
● Kerge hallata ­ 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 selle välja 
● laiendatav 
● kapseldatud ­ igal komponendil on temale spetsiifiline 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, siis saab ainult selle ü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 kelle poole võib 
pöörduda. Kasutaja suhtleb kasutajaliidesega. Kasutajaliidese kiht suhtleb teenuskihiga või 
ärikihiga, mille all on andmekiht ja selle all 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 hallata. Siis 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, millega enamus avaliku sektori rakendused 
suhtlema peavad / andmeid vahetama. Nt Active Directory. 
 
Kõik rakendused peavad üksteisega suhtlema nii, 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 ​
riistvara​
 sees. 
Kuskil on veebibrauser (esitluse kiht) ­> veebiserver (ühenduse loomiseks) ­> 
applikatsioonid ­> andmebaas. Asuvad füüsiliselt erinevates masinates. 
 
Kasud​ : 


42 
● hallatavus 
● 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 kohesiivsus ­ 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, siis 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, millised on andmed, 
millised on andmestruktuurid jmt. Suhtlemine toimub alati lepingu alusel.  
 
Nt SOAP, kus xml­ga vahetatakse andmeid. Kõigepealt jagatakse wsdl­ga lubadusi, mina 
tahan saadan selliseid asju ja mul on sellised 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 olla oma platvorm, saab suhtema panna nt 
java rakenduse .net rakendusega 
● ratsionaalsus 
 

98. Monoliitne arhitektuur.  

Funktsionaalselt eristatavad osad ei ole lahutatud komponendid 
Tekib tavaliselt siis kui lahendada ülesanne nii, et ei mõtle arhitektuurile.  
Osadel juhtudel on oma kohal, nt lihtsates koolitöödes ei ole mõtet ESBi kasutada. 
 

99. Mikroteenused.  

See on viimaste 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 ­ mille 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)? 
● Millised on mittefunktsionaalsed nõuded: turvalisus, jõudlus, paralleelsus, multikeelsus, 
konfiguratsioon (konfiparameetrid koodis või andmebaasist hallatavad?) 
● Kuidas saavutada paidlikus ja hallatavus läbi aja 
● Millised 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 
tulla 
 
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, hallatavus, 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 kontrollida. 
 
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 selleks liiga väike ja seda kunagi ei 
juhtu. 
 
Disainimisel mõtle järgmistele asjadele: 
● Mis on fundamentaalsed osad arhitektuurist, mille valesti tegemine on väga suure riskiga 
süsteemi toimimisele 
● Milline osa süsteemist on suurima muutumise tõenäosusega. 
● Milliste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta 
● Millised on võtme eeldused ja kuidas neid kontrollida 
● 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 Mellon Ülikooli pool 
● Väljakutsed 
○ Milline arhitektuur kataks kõige paremini kasutajate vajadusi 
○ Kuidas täita kujuteldava süsteemi nõudeid 
○ Kuidas otsustada, milline arhitektuuri strateegia on sobilik 
○ Kuidas hinnata nõuete täitmisel tehtavate kompromisside mõjusid 
 
ADD on rekursiivne, st et protsessi korratakse ja korratakse 
● 1. osa taktika 
○ Kontrolli, et nõuded oleks  piisavad
○ 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 liidesed 
○ Verifitseeri ja viimistle nõudeid ning määra nende pealt piirangud 
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 talletamist 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ärelkontroll arhitektuurile 
8. itereeri punkte 1­7 

3. Agiilne arhitektuur ​ ­ ei ole jäik protsess, on pigem mõtteviis (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 agiilse arhitektuuri puhul? Kõik on vastutavad. Ei ole 
üks arhitekt, kes vastutab, vaid kogu tiim vastutab. 
Probleem: 
● vahel inimesed ei ole üksteisega nõus 
● suurtes tiimides skaleeruvus 
Sellisel juhul valitakse arhitektuurile üks omanik/vastutaja, kes aitab alumistel tiimidel 
jõuda ühistele arusaamisel. Kui laat läheb väga suureks, siis keegi, kes tõuseb püsti 
ja ütleb, et mina võtan nüüd otsuse vastu. 


47 
 

103. Kes on arhitektuuri omanik?  
Agiilne arhitektuur 
 

Kes vastutab arhitektuuri eest agiilse arhitektuuri puhul? Kõik on vastutavad. Ei ole üks 
arhitekt, kes vastutab, vaid kogu tiim vastutab. 
Probleem: 
● vahel inimesed ei ole üksteisega nõus 
● suurtes tiimides skaleeruvus 
Sellisel juhul valitakse arhitektuurile üks omanik/vastutaja, kes aitab alumistel tiimidel jõuda 
ühistele arusaamisel. Kui laat läheb väga suureks, siis keegi, kes tõuseb püsti ja ütleb, et 
mina võtan nüüd otsuse vastu. 
 

104. Kuidas toimub töötamine arhitektuuriga suures meeskonnas?  
Agiilne arhitektuur 
 

● Arhitektuuri  juhitud   lähenemine  
● Featuuri juhitud lähenemine 
● Avatud lähtekoodi lähenemine 
● Kombinatsioon eelnevatest 
 
Agiilne arhitektuuri loomine on iteratiivne. 
Arhitekt ei tohi olla egoist, ta peab arvestama teiste arvamust ja viima sisse muudatusi. 
Kaasata tuleb ka tellija, ei toh arvata, et tellija on rumal ja ta ei tea midagi. 
 





 
 

105. Arhitektuuri testimine.  
Küsi endalt: 

48 
○ Millistele eeldustele tugineb arhitektuur 
○ Milliseid nõudeid arhitektuur katab 
○ Mis on selle arhitektuuri võtme riskid 
○ Milliste meetmetega leevendada riske ­ valitud riskid peavad olema teadlikud 
○ Mil moel on see arhitektuur edasiminek viimase kandidaadi/baas arhitektuuri suhtes. 
 

106. Agiilne arhitektuur.  
● Nõuded juhivad arhitektuuri, va kui sa häkid. 

● Modelleeri ­ ära joonista ainult paberile. 
● Ära unusta alternatiive ­ kui tekib viga, siis mõtle alati, kas alternatiiv lahendaks selle 
vea. 
● Arvesta äri kitsendustega ­ räägi varakult arhitektuur läbi 
● Lenda valguskiirusel 
○ Ole nii väle kui võimalik ­ ära istu 2 kuud kapis ja mõtle asju välja, tagasisidet 
on vaja kiiresti 
○ Ä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 (nii kaua kuni pole arendatud on 
valikud  ja otsused tühi õhk) 
● Kommunikeeri oma arhitektuuri ­ sh tiimile 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 hullem tõstavad end ise kõrgemale pjedestaali astmele 
● Arhitektid on liiga hõivatud, et "määrida" oma käsi koodi kirjutamisega 
● Arhitektuuri mudelid on piisavalt 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 niikuinii aru 
● Arhitektuurile tehakse enne järelkontroll ja seejärel läheb arhitektuur arendamisele 
 
Agiilne praktika 
● Arhitektidel on alandlikkust tunnistada et nad ei oska vee peal käia (ei ole jumalad) 
● Arhitektid osalevad aktiivselt arendustegevuses (et tajuda probleeme, mis valitud 
arhitektuur põhjustab). Nad on meeskonna konsultandid 
● Arhitektidel on alandlikkust tunnistada, et nad ei oska tulevikku ennustada. Küll aga on nad 
enesekindlad selles, et homseid probleeme saab lahendada homme 
● Arhitektuur tekib iteratiivselt koos arendusega 
● Valguskiirus. Dokumenteeri nii palju kui on vaja kommunikatsiooniks. 
● Mudeleid kommunikeeritakse avalikult kõigile osapooltele (tiim, klient, DBA­d jt), ka 
poolikuid, et saada tagasisidet 
● Arhitektuuri kontrollitakse eksperimentidega 


49 
 

107. Veebirakenduse arhitektuur.  
! ​
Arhitektuuri point 
● Haldab keerukust 

● Mõeldud inimestele 
 
Näide enterprise süsteemist, millega 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 olla 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 kellega suhtleb. 
■ ​
Loose coupling 
● selgelt defineeritud liidesed 
● sisemiste detailide varjamine ­ näitab kui palju üks kast teise sisse näha tohib 





 
List on liides, ArrayList, LinkedList on realisatsioonid. 
 
Need 3 põhimõtet kehtivad nii 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 olla 
■ koodina rakenduse sees 
■ teegina rakenduse küljes 
■ veebiteenuse taga 
● Rakendust on ​ kerge muuta  
○ Kõigepealt tuleb aru saada  
○ muudatuste piiratud 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 piirid. 
 

111. HTTP päring  
HTTP päring koosneb ​ päringust, päistest ja andmetest. 

Päised on tekstilised ​
nimi:väärtus paarid​ , mille 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, millest 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 liiki: 

1. Thin­client veebirakendused  
● Server koostab HTML’i  
● Piiratud interaktiivsus ­ 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 interaktiivseid rakendusi ­ ei pea uuendama kogu UId, saab 
uuendada ainult veebilehe osasid 
● Asendab sageli arvutiprogramme  
● Näiteks Gmail. 
 
3. Veebiteenused 
● REST liidesega 
○ Süsteemide ühendamiseks 
○ Standardse HTTP abil GET, POST, DELETE 
○ Sageli JSON andmeformaadis 
● SOAP ( lõputu  peavalu allikas!) ­ 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 protokolli/suhtluse eest 
○ Java konteinerid: 


53 
● Tomcat ­ 70% kasutab seda 
● Jetty  
● TomEE  
● Wildfly 
○ Moodsad alternatiivid Java konteinerile: 
● Konteiner lisatakse teegina rakenduse sisse  
● Käivitatakse otse käsurealt  
● Pakendatakse standardse java arhiivina (jar) 
 
 
 

115. Servlet API  

Konteiner, mis tegeleb java suhtlusega pakub ette liidese, millega saab välismaailmaga 
suhelda. Seda nimetatakse Servlet API­ks. 
 
Siin 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 viis veebirakenduse puhul koodi organiseerida. 

Siin käsitled kui disainimuster, aga võib olla ka arhitektuuri muster. 
 
Rakenduse kood jagatud 3 komponendi vahel (igal tükil oma eesmärk ja defineeritud mis 
millega suhtleb):  
● model  
○ andmemudel  
○ äriloogika  
● view  
○ kasutajaliidese  genereerimine  ­ html, html gerereerimine. Ei tegele 
äriloogikaga, ei tea andmebaasist midagi. 
● controller  


54 
○ vahendaja maailma ja rakenduse vahel  
○ suhtleb äriloogikaga  
○ otsustab millist view’d näidata 





 
 
FAT Client 
● staatiline html leht + javascript 
● ajax kaudu andmete lugemine ja kirjutamine  
● kontroller  vahendab  andmeid  
○ sisuliselt REST liides, so: 
● Lihtsustatud kontroller  
● Ainult töötleb andmeid  
● Ei tegele kasutajaliidesega 
 
MVC eelised 
● Väga hea vastutuste jagamine  
● Lihtne testida  
● Parem interaktiivsus ja kasutajamugavus 
 

117. JSP  
Java Server Pages 
● Tekstifail HTML genereerimiseks 

● Kompileeritakse servletiks 
● Custom tagid keeruliste lehtede ehitamiseks 
 





 
 

118. JAX­RS  
● Standard REST­liideste 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ööriistad: 
●  
 

Raamistikud: 
● Play! Framework  
● Spark Framework 
● Ruby on Rails 
 





 
 

122. Riskide võrdlus 

Iteratiivne vs kosemudel (siin on võetud äärmused, tegelikkuses ei kasutata puhast mudelit 
praktikas väga): 





 
 
Kose mudele puhul hakkavad riskid vähema alles testimise juures. 


56 
Interatiivsel juhul tegeleme suuremate riskidega juba projekti alguses. 
 

123. Nimeta manifesto agiilse tarkvaraarendamiseks ja seleta need lahti.  

Agiilse tarkvaraarenduse manifestis on 4 põhimõtet: 
● Indiviidid ja interaktsioonid on olulisemad kui protsessid ja  tööriistad
● 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 sellele, milles 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 olla mockupide või dummyde tasemel) 
● People not process ­ rõhk pööratud arendustiimi oskustele ja kuidas töö on 
organiseeritud. 
● Embrace  change  ­ muutuste juhtimine; Nõuded võivad muutuda, selleks tuleb 
inimestel valmis olla. 
● Maintain simplicity ­ säilitada lihtsus ja püüda kõrvaldada keerukust psühhotehnilisest 
süsteemist.  Sihitud  nii 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  distsipliini  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 siis 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) 
● storytelling ­ 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 ­ sellest 
alustatakse süsteemi ehitamist. 
● customer + the  whole  team 
 
ITERATION MEETING ­ esimene kick­off meetingul; alati on koosolekutel kogu tiim 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 siis töötundide eest, kui 
suudetakse kliendile demoda ja üle anda mingi osa tarkvarast. Kui midagi ei ole OK, 
siis klient saab selle 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 nii on töö efektiivsem! Paaris 
programmeerimine on hea viis, kuidas õppida ­ nii õ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. Kasutajaliidese tasemel on keeruline, aga muidu 
lihtne. Käib hästi kokku paaris programmeerimisega. Üks kirjutab testi ja teine peab 
sellele 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 
● collective 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, siis kood korjatakse versioonihaldusest üles, 
tehakse build, lähevad testid käima, kui on probleem siis teavitus teamile e­mailile. 
● continuous deployment 
 
CUSTOMER COLLABORATION ­ klient saab nt arendusserveris/testserveris rakendust 
vaadata ­ saab anda kohe tagasisidet, et kas ta mõtles nii ja soovib seda; mida kiiremini 
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), siis selle 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 viia võimalikult kiiresti lõppkasutajani. 
Seal on järgmine feedbacki tase. Nt saab anda kasutada piiratud 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 millestki 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 liiguks) 
 

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 sellele 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), siis tuleb teha 2 optimiseerimist (optimize). 
Srumis on oluline ka tarkvaraarendusprotsessi  efektiivsuse  mõõtmine (lisaks sellle, et 
protsess optimeeritakse). 
 
Scrumi mõisted​ : 





 
 
Osalejad / Rollid: 
● 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 fully functional and productive 
○ Enable close cooperation across all roles and functions 
○ Shield the team from external interferences 
● The team 
○ Typically 5­9 people 
Cross ­functional: 
■ Programmers, testers, user experience designers, etc. 
○ Members should be full­time 
■ May be exceptions (e.g., database administrator) 
○ Teams are self­organizing 
■ Ideally, 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. Sellest 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 efektiivselt taske realiseerime. 
Iga sprindi lõpus on Sprint Review ja Retrospective. 
Kui asi antakse üle Product Ownerile, siis tehakse project retrospektiiv ­ mis oli hästi? mis 
kehvasti? mida võiks teha teisiti? 


64 
 
Potentially shippable product increment​






 
 
Product backlogi näide​
 (koosneb user story’dest): 





 
Roll 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: 
○ Allow 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: 
● Pull Value through the Value Stream 
○ Kui järgmine etapp on mingi asja ära ​ PULL​’inud, siis eelmine avastab, et tal 
on tühi koht ja saab uue asja võta sinna. 
● Limit WIP 
○ Neljas esimeses etapis on tööde arv piiratud. Nt To do listis ei tohi olla 
rohkem kui 5 tööd ­ sinna saab ühe veel juurde võtta. 
● Make it  visible
○ Kanban board’i kasutatakse selleks 





 
 
Kanbani ideoloogia​

● “Lean” – keskendu sellele, 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) = 
Potentially 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 all 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​, millel kõigil on üks ja ​
sama 
eesmärk​ . 
 

132. Eesmärgi mudel  
Eesmärgi mudeli näide: 




69 
 
Eesmärgid võivad olla erinevatel tasanditel (“kastikesed”). 
Eesmärgi mudel on üks viis 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 
selle iteratsiooni jaoks on nii 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.  Rational publicity> 
 
Milleks 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, millest 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 
Iteratiivne 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? 
● Millised rollid on nende eesmärkide saavutamiseks vajalikud? 
● Mida süsteem peaks tegema? 
 
1. Eesmärgimudel 





 
 
2. Tegevusdiagramm (UML) 





 
3. Kasutuslugu 
● Kui (roll) 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 Seller 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 
● Millist 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.  

Milliseid teateid süsteemi osad vahetavad omavahel ja kasutajaga? 
 
1. Jadadiagramm​ : 





 
 

145. Struktuuri disain.  
Millist informatsiooni tuleb süsteemis esitada? 
 

1. Detailne klassidiagramm​ : 


78 
 
 

146. Käitumise disain.  
Kuidas süsteemi olemid käituvad? 
 
1. Olekudiagramm​ : 

Meditsiinilabori olemi “Tellimus” olekudiagramm 





 
 
 





 





79 
 
 

147. Kuidas on varem arhitektuurist mõeldud  

● Maja ehitades on mõistlik vundamendist hästi aru saada  
● “ …all these must be built with due  reference  to ​
durability​
, ​
convenience ​
and ​
beauty​
” 
(Marcus Vitruvius Pollio, 80­70 eKr.­ 15 pKr). Kõik need tingimused peavad olema disaini 
otsuste tegemisel arvesse võetud.  
● Minge kõndige vanalinnas... (vanalinna paralleel arhitektuuriga): 
○ Tallinna vanalinna on sadu aastaid “arendatud“!  
○ Osad ajad kehtivad jätkuvalt, osad asjad ei kehti 
○ Jällegi sama printsiip: asjad, kui miski jääb, on ta kasulikum, kui see, mis kaob 
○ Riias 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 siis lastakse hulk “lolle” 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 liikide, nende omavaheliste seoste ja seoste liikide 
kaudu  
○ Levinud, intuitiivne 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, siis keerukus kasvab eksponendina. Kuskil on alati 
võimete piir, 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 challenge  
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 usually 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 equally 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 will“  
● The domain of legal and philosophical thinkers  
● Embodied, to an extent, in constitution  
● Thus very hard (if at all 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 fundamentally 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 allowing 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 siini arhitektuur. Eesti riigi arhitektuur on väga sarnane 
sellele. 
 

154. Riigi infosüsteemi kui terviku kontekstis ja miks on see oluline?  
 
 

155. Süsteemid ja nende dünaamika  
Viiekü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 viivad kiiresti keerulise matemaatikani!  
 
! ​
Keeruliste süsteemide käitumises on kindlad,  universaalsed , seaduspärasused 
 

156. ICBM ja nende ohutus  

● Koos massiivse tuumaarsenaliga sündis ka vajadus neid kuidagi ohutuna hoida.  




83 
● Vastupidiselt sellele, mida räägiti omal ajal telekas, oli mure sellega, 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 kallim 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 kallis, 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 millede funktsionaalsus on suurem kui üksikute 
olemite funktsionaalsuse summa. 
 
Süsteemimõtlemine ​ on viis mõelda küsimusest, olukorrast või probleemist eksplitsiitselt kui 
süsteemist.  
[Crawley 2015] 
 
Mida see tähendab?  
• Süsteemimõttelemine on üks viis asjadest mõelda  


84 
• nagu loovmõtlemine või loogiline arutelu 
• sellisena 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 modelleerimiseks piisavalt 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, siis tekivad tuuletunnelid. Inimesed on surma saanud. 
Sellle tuleb ehitamisel mõelda. 
 
! ​
Süsteemimõtlemine on just insenerivaldkondades sobiv viis probleemidest mõelda​ . 
 

159. Arhitektuur süsteemimõtlemise kontekstis  
! ​

Arhitektuur on süsteemi osade ja nende omavaheliste seoste abstraktne kirjeldus.  
 
• Nii lihtne ongi  
• Veel üldisemat määratlust on keeruline leida  
• Samas on ka kõik ära öeldud  
• Nii võib kirjeldada kõike: organisatsiooni, inimest, tarkvara jne.  
• Kuid lihtsus on petlik ­ lihtne definitsioon on petlik, süsteemid ei ole nii lihtsad 
• Süsteemi osad võivad olla  organisatsioon , inimene, tarkvara jne.  
• Seosed võivad olla nii füüsilised kui mõju avaldavad  
• Kirjeldada võib neid kõiki väga mitmel viisil (nii 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õttemalle 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 krediitkaardiga 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 viis ü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 rolle 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 piiranguid,  
teeb otsuseid, mis võimaldavad keerukuse kasvust võimalikult palju kasu saada  
 
!​ ​
Keerukuse juhtimine on väga oluline ja väga keeruline arhitekti roll​. 
 
Kui keegi keerukust ei juhi, siis süsteemid kasvavad üle pea, lähevad liiga keeruliseks. Ei 
osata enam asju juurde ehitada. Arhitekt on ainuke, keda projektis tõeliselt huvitab keerukus 
ja selle vaos hoidmine, seega ta peab sellega 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. Selle pärast on koodi disain ja loetavus 
oluline, et kas on endiselt arusaadav ­ nii endale kui ka teistele. 
 





86 
Disain mõjutab produktiivsust. Kui lihtsalt kirjutada ja kirjutada ning disainile mitte tähelepanu 
pöörata, siis koodi kvaliteet hakkab langema ja see tõmbab alla produktiivsust. 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 all 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. Small 
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 tellija kasutab oma tellimuses ja igapäevatöös! Oluliselt lihtsam on 
aru saada, eriti hiljem kui koodi lugeda. 


87 
• Spelling and grammar 
• Can you read your code like a story? 
 
Kui miksida erinevaid keeli (ENG, EST), siis tuleb sellest 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 collection on mitmuses,  muutuja  on ainsuses. 
Map nimi peab viitama sellele, et seal on mingi map taga (seos). 
Ühikud tuleks muutuja nimele juurde panna, nt queryIntervalSeconds. Siis on alati teada, et 
kui vastus on 12, siis see on sekundites. 
findCardsBelongingTo(Customer customer) ­ muutuja nimed panna sellised, 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 sellel on palju tähendusi ja kasutatakse 
erinevates varjundites. Kliendi kohta kasutada Customer. Firmad, kellega 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 
 
GOOD  FUNCTION 
• short 
• very few indentation levels 
Kui on mitu taset treppi, siis on vihje sellele, et funktsioon on liiga 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 well. 
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 sellest 
arusaamist, testimist keerukamaks. 
 
Hea näide sama asja kohta: 





 





 
Tehtud ümber nii, 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), siis tuleb muuta ainult seda ühte meetodit ja ülejäänud jääb 
paika. 
 
FUNCTION ARGUMENTS ­  parameetrite  arv 
• Less is more! 
• Ideally none, one and two are OK 
• Three is usually too much, anything more is a design smell 
 
Kui on rohkem kui üks parameeter, siis tihti funktsioon ei tegele enam ühe asjaga, nagu 
eelnevalt oli räägitud. 
Kui on üks parameeter, siis välja kutsuja saab paremini aru, et mis parameeter tuleb ette 
anda ja tõenäoliselt saab ka õigema vastuse. Kui on palju parameetreid, siis otsitakse neid 
kuskile kokku. 
 
Kui ühel funktsioonil on palju parameeterid, siis teha eraldi klass, mis tegeleb selle 
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 olla ettevaatlik selle kasutamisega, sest vahel 
ei ole selgelt aru saada, et mida see kood siis 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, siis ta ei tohiks andmeid muuta jmt. 
 
Näide  halvast  koodist: 





 
Ei tohiks lähtuvalt nimest getAmount, siis ei tohiks staatust muuta. 
 
Näide halvast koodist: 





91 
 
Siin nimi ütleb, et ta kontrollib ainult parooli, tegelikul laadis IP profiili ka lisaks. 
 
Lahendati nii, 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, siis 
kustutada see meetod ära. Kui tulevikus läheb seda meetodit uuesti vaja, siis leiab selle 
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 selle pärast peab rea koodi juurde lisama. Nt kui mõni meetod on väga ressursimahukas, 
täitmine võtab kaua aega ­ siis 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 , millest ü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 Hollywood Principle: Don’t call us – we’ll call you 
• Don’t create your dependencies ­ they will 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 skilled 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 
Null 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 kiiremini, paremini. Nt Transferwise, Kickstarter, … 
Kutsutakse selliseid 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», kelle 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 digiallkirja lendamiseks on, et pole piisavalt juriste, kes 
saaks aru, kuidas digiallkiri töötab, et saaks seadusemuudatusi sisse viia. 
 
«Äri saab aru, mis on IT võimalused» 
«IT saab aru, mis on äri eesmärgid» 
Sellest enam ei piisa. 
 
Agiilne arendus ei ole mingi «asi, mida IT teeb» 
Äri peab arenema agiilselt.  
Äri ja tehnoloogia arenevad koos. 
 

169. Lean põhimõtted.  
“Lean” – keskendu sellele, 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 selle saab valideerida 
● MVP ­ kõige pisem tükk, mida saab kasutajale anda ja mille pealt saab tagasisidet 
● Mõõdikud 
○ Miks, mida, kuidas mõõta? 


97 
○ Kuidas aru saada, et midagi muutub paremaks, kiiremaks, efektiivsemaks? 
○ 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 selliselt, 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ööriistad üksi tööd ei tee 
• Klient, testija, arendaja ... 
 
 

172. Milleks hallata nõudeid?  
! ​
Nõuetest arusaamine on eduka projekti alus. 
 

Milleks nõudeid hallata? 
• Muutuvad ajas 
• Ununevad 
• Olulisus muutub 
• Tekivad ja kaovad 


98 
•  Folkloor  
• Ebakõlad/vead 
• Progressi  jälgimine  
 





 
 
Millega hallata? 
• 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, millal 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, pliiats. Whiteboard 
• Excel 
• MS Project 
• JIRA, Pivotal Tracker 
! ​
Hea vahend on osa nõuete haldusest. 


99 
 
Arendusvahendid​ : 
• “notepad” 
• vi/vim 
• Eclipse 
• NetBeans 
• IntelliJ IDEA 
• XCode 
• AppCode 
•  Visual  Studio 
• + 100 muud vahendit lisaks 
 
• Õigesti valitud vahend võib tõsta arendaja produktiivsust väga palju 
• Õpi oma vahendit kasutama ja tunne selle võimalusi 
• Kasuta shortcute 
• Ära aja pilti liiga kirjuks 
 
Planeerimise ajal mõtle: 





 
  

174. Versioonihaldus.  
Versioonihaldus: 
• Ajalugu. Seotus nõuetehaldusega 

• Muudab arenduse paindlikumaks. 
• Meeskonnatöö 
• Ausaamise, milline lähtekood on hetkel toodangus 
• Kes selle siia 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 
• Reliisid 
• 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 
• Milleks 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: 
• Shell 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. Sellega kaasnevad vead. 
• Kasuta seda tulemust, mis sa continuous integration vahenditega juba valmis tegid. 
• Kui ei saa siis tee selgeks, miks ei saa. Elimineeri need põhjused ja kasuta ikka. 
• Kui siis ka ei saa siis kasuta vähemalt samu build skripte. 
• ... muudmoodi liigub asi kontrollimatuse suunas. 
 
Sõltuvuste haldus: 
• Sõltuvused koos lähtekoodiga repositooriomis 
• Sõltuvused hallatakse 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.  
Milleks? 
• Arendus mitmele operatsioonisüsteemile 
• Arendus 

• Testimine 
• Erinevatele operatsioonisüsteemidele kompileerimine (continuous integration) 
 
Töölaua/serveripargi vitualiseerimise vahendid: 
• Parallels 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 
positiivsed ja negatiivsed omadused, kasutusvaldkonnad.  
 
● Mudeli olemus ja mudelite klassifitseerimine.  
 
● Tarkvarasüsteemi kvaliteediatribuutid nii 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 

-13200% sisust ei kuvatud. Kogu dokumendi sisu näed kui laed faili alla
Tarkvaratehnika kordamisküsimused #1 Tarkvaratehnika kordamisküsimused #2 Tarkvaratehnika kordamisküsimused #3 Tarkvaratehnika kordamisküsimused #4 Tarkvaratehnika kordamisküsimused #5 Tarkvaratehnika kordamisküsimused #6 Tarkvaratehnika kordamisküsimused #7 Tarkvaratehnika kordamisküsimused #8 Tarkvaratehnika kordamisküsimused #9 Tarkvaratehnika kordamisküsimused #10 Tarkvaratehnika kordamisküsimused #11 Tarkvaratehnika kordamisküsimused #12 Tarkvaratehnika kordamisküsimused #13 Tarkvaratehnika kordamisküsimused #14 Tarkvaratehnika kordamisküsimused #15 Tarkvaratehnika kordamisküsimused #16 Tarkvaratehnika kordamisküsimused #17 Tarkvaratehnika kordamisküsimused #18 Tarkvaratehnika kordamisküsimused #19 Tarkvaratehnika kordamisküsimused #20 Tarkvaratehnika kordamisküsimused #21 Tarkvaratehnika kordamisküsimused #22 Tarkvaratehnika kordamisküsimused #23 Tarkvaratehnika kordamisküsimused #24 Tarkvaratehnika kordamisküsimused #25 Tarkvaratehnika kordamisküsimused #26 Tarkvaratehnika kordamisküsimused #27 Tarkvaratehnika kordamisküsimused #28 Tarkvaratehnika kordamisküsimused #29 Tarkvaratehnika kordamisküsimused #30 Tarkvaratehnika kordamisküsimused #31 Tarkvaratehnika kordamisküsimused #32 Tarkvaratehnika kordamisküsimused #33 Tarkvaratehnika kordamisküsimused #34 Tarkvaratehnika kordamisküsimused #35 Tarkvaratehnika kordamisküsimused #36 Tarkvaratehnika kordamisküsimused #37 Tarkvaratehnika kordamisküsimused #38 Tarkvaratehnika kordamisküsimused #39 Tarkvaratehnika kordamisküsimused #40 Tarkvaratehnika kordamisküsimused #41 Tarkvaratehnika kordamisküsimused #42 Tarkvaratehnika kordamisküsimused #43 Tarkvaratehnika kordamisküsimused #44 Tarkvaratehnika kordamisküsimused #45 Tarkvaratehnika kordamisküsimused #46 Tarkvaratehnika kordamisküsimused #47 Tarkvaratehnika kordamisküsimused #48 Tarkvaratehnika kordamisküsimused #49 Tarkvaratehnika kordamisküsimused #50 Tarkvaratehnika kordamisküsimused #51 Tarkvaratehnika kordamisküsimused #52 Tarkvaratehnika kordamisküsimused #53 Tarkvaratehnika kordamisküsimused #54 Tarkvaratehnika kordamisküsimused #55 Tarkvaratehnika kordamisküsimused #56 Tarkvaratehnika kordamisküsimused #57 Tarkvaratehnika kordamisküsimused #58 Tarkvaratehnika kordamisküsimused #59 Tarkvaratehnika kordamisküsimused #60 Tarkvaratehnika kordamisküsimused #61 Tarkvaratehnika kordamisküsimused #62 Tarkvaratehnika kordamisküsimused #63 Tarkvaratehnika kordamisküsimused #64 Tarkvaratehnika kordamisküsimused #65 Tarkvaratehnika kordamisküsimused #66 Tarkvaratehnika kordamisküsimused #67 Tarkvaratehnika kordamisküsimused #68 Tarkvaratehnika kordamisküsimused #69 Tarkvaratehnika kordamisküsimused #70 Tarkvaratehnika kordamisküsimused #71 Tarkvaratehnika kordamisküsimused #72 Tarkvaratehnika kordamisküsimused #73 Tarkvaratehnika kordamisküsimused #74 Tarkvaratehnika kordamisküsimused #75 Tarkvaratehnika kordamisküsimused #76 Tarkvaratehnika kordamisküsimused #77 Tarkvaratehnika kordamisküsimused #78 Tarkvaratehnika kordamisküsimused #79 Tarkvaratehnika kordamisküsimused #80 Tarkvaratehnika kordamisküsimused #81 Tarkvaratehnika kordamisküsimused #82 Tarkvaratehnika kordamisküsimused #83 Tarkvaratehnika kordamisküsimused #84 Tarkvaratehnika kordamisküsimused #85 Tarkvaratehnika kordamisküsimused #86 Tarkvaratehnika kordamisküsimused #87 Tarkvaratehnika kordamisküsimused #88 Tarkvaratehnika kordamisküsimused #89 Tarkvaratehnika kordamisküsimused #90 Tarkvaratehnika kordamisküsimused #91 Tarkvaratehnika kordamisküsimused #92 Tarkvaratehnika kordamisküsimused #93 Tarkvaratehnika kordamisküsimused #94 Tarkvaratehnika kordamisküsimused #95 Tarkvaratehnika kordamisküsimused #96 Tarkvaratehnika kordamisküsimused #97 Tarkvaratehnika kordamisküsimused #98 Tarkvaratehnika kordamisküsimused #99 Tarkvaratehnika kordamisküsimused #100 Tarkvaratehnika kordamisküsimused #101 Tarkvaratehnika kordamisküsimused #102 Tarkvaratehnika kordamisküsimused #103 Tarkvaratehnika kordamisküsimused #104 Tarkvaratehnika kordamisküsimused #105
10 punkti Autor soovib selle materjali allalaadimise eest saada 10 punkti.
~ 105 lehte Lehekülgede arv dokumendis
2016-01-14 Kuupäev, millal dokument üles laeti
48 laadimist Kokku alla laetud
0 arvamust Teiste kasutajate poolt lisatud kommentaarid
zut Õppematerjali autor

Lisainfo

Sisukord

  • TARKVARATEHNIKA KORDAMISKÜSIMUSED 
  •  Mis on tarkvaratehnika? 
  • Software engineering
  • Tarkvaratehnika 
  • Tarkvaraarendus 
  •  Miks vajame tarkvaratehnikat?  
  •  Milleks tarkvaratehnika?  
  •  Tarkvaratehnika „point“?  
  •  Mis on tarkvara(toode)? 
  •  Kvaliteetse tarkvara atribuudid.  
  •  Tarkvaratehnika huvigrupid.  
  •  Tarkvaratehnika kui distsipliini eesmärgid.  
  •  Tarkvaratehnika kontekst.  
  •  Süsteemi kategooriad ja nende seletused. 
  • Küsimus: Mis on sotsio­tehniline süsteem? Mis on sotsio­tehnilise süsteemi erinevus 
  •  Mis on süsteemitehnika?  
  •  Millised on parimad tarkvaratehnika meetodid?  
  •  Tarkvararakenduse liigid.  
  • ! Protsess 
  •  Mis on tarkvara arendusprotsess e. tarkvaraprotsess? 
  • ! Tarkvaraprotsess 
  •  Tarkvaraprotsessi mudel. 
  •  Plaanipõhine vs agiilne tarkvaraprotsess.  
  •  Tarkvaraprotsessi mudelite tüübid.  
  •  Kirjelda Kose mudeli koos puudustega ja eelistega.  
  •  Mis on modifitseeritud kose mudel?  
  •  Mis on iteratiivne arendamine? Eelised ja puudused?  
  •  Mis on komponendipõhine tarkvaraarendus, puudused ja eelised? Mis tüübid on 
  •  Mis on kõige parem tarkvaraprotsessi mudel?  
  •  Millist tarkvaraprotsessi mudelit kasutatakse kõige rohkem?  
  •  Mis on tarkvaraarenduskulud? Kuidas nad jaotuvad?  
  •  Tarkvarainseneri professionaalsus.  
  •  Inimloomus ja eetika.  
  •  Tarkvarainseneri professionaalse vastutuse aspektid.  
  •  ACM/IEEE eetikakoodid ja printsiibid ning nende seletused.  
  •  Eetilised dilemmad.  
  •  Eetiliste dilemmade põhipunktid.  
  •  Tarkvara nõuete koostamise tehnikad ja lähenemised. (Requirements Engineering)  
  •  Millest koosneb tarkvara nõuded? 
  •  Miks on vaja kirjutada nõuded?  
  •  Parimad praktikad nõuete kirjeldamiseks. Too näited.  
  •  Tuleta meelde, mis maailma probleemid olid käsitletud. Ja mis lahendused arvutite 
  •  Nõuete esialgne definitsioon. Millised veel on nõuete definitsioonid?  
  •  Mis vahe nende mõistete vahel on: Süsteemi nõuded ja tarkvara nõuded?  
  •  Nõuete kolm mõõdikud koos seletustega.  
  •  Types of statements involved: descriptive vs. Prescriptive  
  •  Categories of requirements: functional vs. non­functional  
  •  A taxonomy of non­functional requirements  
  •  The requirements lifecycle: actors, processes, products  
  •  The requirement engineering process  
  •  Requirement engineering: an iterative process  
  •  Target qualities and defects to avoid  
  •  Types of software projects  
  •  Requirements in the software lifecycle 
  •  Relationship to other disciplines  
  •  The requirements problem: facts, data, citations  
  •  Role and stakes of requirement engineering.  
  •  Obstacles to good requirements engineering practice.  
  •  Millest koosneb tarkvarakvaliteet? Miks?  
  •  Mis võiks olla kvaliteet? 
  •  Millest koosneb tarkvaratoode?  
  •  Nimeta erinevate osapoolte erinevad nõuded.  
  •  Nimeta süsteemi kvaliteedi nõuded vastavalt EVS­ISO/IEC 25010:2011 standardile.  
  •  Mis on funktsionaalne nõue? Too näited.  
  •  Mis on mittefunktsionaalne nõue? Too näited.  
  •  Nimeta nõue, mis on testitav.  
  •  Nimeta nõue, mis on mittetestitav.  
  •  Mis on mittereaalne nõue?  
  •  Milline nõue on hea nõue?  
  • ! Oluline tuua välja, et kuidas süsteem peab reageerima, kui on veaolukord
  •  Kas nõue peab olema koguaeg testitav?  
  •  Mis on tarkvaraprotsessid?  
  •  Millistest komponentidest koosneb elutsüklimudel? 
  • Peab oskama erinevaid mudeleid omavahel võrrelda. 
  •  Kirjelda V­mudeli.  
  •  Mis on testimine?  
  •  Kui korraldad testimist, mida peale nõuetest ja protsessist peaks veel teadma?  
  •  Kuidas võiks jagada testimismeetodeid? Mis kaks põhilist meetodi on? Miks?  
  •  Kus leitud viga on kõige odavam parandada?  
  •  Räägi statistikast läbivaatuse kohta.  
  •  Valge kasti testimine.  
  •  Musta kasti testimine.  
  •  Halli kasti testimine.  
  •  Testimise tasandid. Nimeta need ja seleta lahti. Too näited.  
  • Ühiktestimine (Unit test) 
  • Lõimumise testimine (Integration testing) 
  • Süsteemi testimine (System test) 
  • Süsteemi integratsiooni testimine (Integration test) 
  • Regressioonitestimine 
  • Vastuvõtu testimine (Acceptance test)
  •  Testimise tüübid. Nimeta ja seleta lahti. Too näited.  
  • Funktsionaalne testimine 
  • Ekspertteadmiste testimine
  • Mittefunktsionaalne testimine 
  •  Millest koosneb testimise protsess?  
  •  Millal lõpetada testimist?  
  •  Kas igaüks võib olla testija?  
  •  Testijale abiks omadused ja oskused.  
  •  Valik jaotusi testimisele.  
  •  Testijaks olemise võlud.  
  •  Mis on tarkvara arhitektuur?  
  • http://www.sei.cmu.edu/
  •  Erinevused funktsionaalsest disainist.  
  • Arhitektuuri osad on nii riistvara kui tarkvara. 
  •  Mis on arhitektuuri erosioon.  
  •  Klient­server arhitektuur.  
  • Arhitektuur on tavaliselt erinevate mustrite kombinatsioon. Iga muster lahendab oma 
  •  Komponentidel põhinev arhitektuur. 
  •  Kihiline arhitektuur.  
  • Kasud
  •  Message bus.  
  •  N­tier.  
  •  Objekt orienteeritud arhitektuur.  
  • Kasu: 
  •  DDD arhitektuur.  
  •  Teenus orienteeritud arhitektuur.  
  •  Monoliitne arhitektuur.  
  •  Mikroteenused.  
  • Kasud 
  •  Kuidas valida arhitektuuri? 
  •  Arhitektuuri disain.  
  •  Nimeta ja seleta lahti arhitektuuri disainimise protsessid. ka 
  •  Kes on arhitektuuri omanik?  
  • Agiilne arhitektuur 
  •  Kuidas toimub töötamine arhitektuuriga suures meeskonnas?  
  •  Arhitektuuri testimine.  
  •  Agiilne arhitektuur. 
  • Tavalise praktika ja agiilse praktika erisused 
  •  Veebirakenduse arhitektuur.  
  •  Nimeta universaalsed põhimõtted ja seleta need lahti.  
  •  High cohesion  
  •  Low coupling
  • Loose coupling 
  •  Hea arhitektuuri eelised ja nende seletused.  
  •  HTTP protokoll.  
  •  HTTP päring  
  •  HTTP vastus  
  •  Nimeta veebirakenduste liike ja seleta need lahti.  
  • Veebiteenused 
  •  Veebirakendus JAVAs.  
  •  Servlet API  
  •  Model view controller  
  • MVC eelised 
  • Java Server Pages 
  •  JAX­RS  
  •  Starter KITS  
  •  Alternatiivid servletile  
  •  Nimeta tööriistu ja raamistike veebirakenduse jaoks.  
  •  Riskide võrdlus
  •  Nimeta manifesto agiilse tarkvaraarendamiseks ja seleta need lahti.  
  • Working software
  •  Agiilse meetodi printsiibid. Seleta lahti.  
  •  Agiilsete metodoloogiate maastik.  
  •  eXterme Programming.  
  •  XP väärtused.  
  •  Mis on kasutuslugu?  
  •  Kanban.  
  •  Minimal Marketable Feature (MMF)  
  •  Eesmärgi mudel  
  •  Mis on mudel? Kus kasutatakse? Milleks on mudeleid vaja?  
  •  Tarkvaratehnika vaated.  
  •  Liikumine ühelt vaatelt järgmisele. 
  •  Tarkvaraprotsessi etapid.  
  •  Iteratiivne arendamine: Rational Unified Process (RUP)  
  •  Modelleerimine.  
  •  Mudelite klassifikatsioon.  
  •  Käitumise analüüs.  
  •  Interaktsioonide analüüs.  
  •  Struktuuri analüüs.  
  •  Interaktsioonide disain.  
  •  Struktuuri disain.  
  •  Käitumise disain.  
  •  Kuidas on varem arhitektuurist mõeldud 
  • Maja ehitades on mõistlik vundamendist hästi aru saada  
  • Minge kõndige vanalinnas... (vanalinna paralleel arhitektuuriga): 
  • Tallinna vanalinna on sadu aastaid “arendatud“!  
  • Osad ajad kehtivad jätkuvalt, osad asjad ei kehti 
  • ! Tallinna vanalinnas kehtiv kehtib ka tarkvarale, ainult et palju lühemal 
  • ­ keegi alguses disainib asja valmis ja siis lastakse hulk “lolle” peale, 
  •  Moodsa süsteemiarhitektuuri mõtte juured  
  •  Arhitektuuri olemus  
  •  Arhitektuuri roll  
  •  Mis on arhitektuur?  
  • Keerukuse 
  •  Riigi kui selle arhitektuur 
  • Function 
  • Architectural model of a country  
  •  Riigi infosüsteemi kui terviku kontekstis ja miks on see oluline?  
  •  Süsteemid ja nende dünaamika  
  •  Tänapäevased keerulised süsteemid  
  •  Süsteemi definitsioon ja süsteemimõtlemine  
  • Süsteem 
  • Süsteemimõtlemine 
  •  Arhitektuur süsteemimõtlemise kontekstis  
  •  Vorm, funktsioon ja kontseptsioon
  • Kontseptsioon 
  •  Arhitekti roll  
  •  Miks koodi disain on vajalik?  
  • Ward Cunningham 
  •  Koodi lihtsa disaini neli elementi ja näited  
  •  Creator of Extreme Programming, author of JUnit 
  • Robert “Uncle Bob” Martin 
  •  Objektorienteeritud disain  
  • Iterable 
  • Collection 
  • SortedSet
  • SortedMap
  • InputStream 
  • OutputStream 
  • Reader 
  • Writer
  •  Disaini mustrid  
  • Antoine de Saint­Exupery 
  •  Finants­ või tehnoloogiaettevõtted?  
  •  «Äri», kelle jaoks IT taust on juba eeldus. 
  •  Lean põhimõtted.  
  •  Arenduse infrastruktuur ja konfiguratsioonihaldus  
  •  Mida endast kujutab arenduse infrastruktuur? 
  •  Milleks hallata nõudeid?  
  •  Milleks planeerida? 
  • Dwight D. Eisenhowe
  •  Versioonihaldus.  
  •  Build/Deploy. Toodangusse minek.  
  •  Virtualiseerimine.  
  • Näited: Mida küsiti eksamil eelmisel aastal? 

Teemad

  •  Mis on tarkvaratehnika? 
  •  Miks vajame tarkvaratehnikat?  
  •  Milleks tarkvaratehnika?  
  •  Tarkvaratehnika „point“?  
  •  Mis on tarkvara(toode)? 
  •  Kvaliteetse tarkvara atribuudid.  
  •  Tarkvaratehnika huvigrupid.  
  •  Tarkvaratehnika kui distsipliini eesmärgid.  
  •  Tarkvaratehnika kontekst.  
  •  Mis on süsteem?  
  •  Süsteemi kategooriad ja nende seletused. 
  • tehnilisest süsteemist? 
  •  Mis on süsteemitehnika?  
  •  Millised on parimad tarkvaratehnika meetodid?  
  •  Tarkvararakenduse liigid.  
  •  Mis on protsess?  
  •  Mis on tarkvara arendusprotsess e. tarkvaraprotsess? 
  •  Tarkvaraprotsessi mudel. 
  •  Plaanipõhine vs agiilne tarkvaraprotsess.  
  •  Tarkvaraprotsessi mudelite tüübid.  
  •  Kirjelda Kose mudeli koos puudustega ja eelistega.  
  •  Mis on modifitseeritud kose mudel?  
  •  Mis on iteratiivne arendamine? Eelised ja puudused?  
  •  Mis on komponendipõhine tarkvaraarendus, puudused ja eelised? Mis tüübid on 
  • olemas?  
  •  Mis on kõige parem tarkvaraprotsessi mudel?  
  •  Millist tarkvaraprotsessi mudelit kasutatakse kõige rohkem?  
  •  Mis on tarkvaraarenduskulud? Kuidas nad jaotuvad?  
  •  Tarkvarainseneri professionaalsus.  
  •  Inimloomus ja eetika.  
  •  Tarkvarainseneri professionaalse vastutuse aspektid.  
  •  ACM/IEEE eetikakoodid ja printsiibid ning nende seletused.  
  •  Eetilised dilemmad.  
  •  Eetiliste dilemmade põhipunktid.  
  •  Tarkvara nõuete koostamise tehnikad ja lähenemised. (Requirements Engineering)  
  • domain
  •  Millest koosneb tarkvara nõuded? 
  •  Miks on vaja kirjutada nõuded?  
  •  Parimad praktikad nõuete kirjeldamiseks. Too näited.  
  •  Tuleta meelde, mis maailma probleemid olid käsitletud. Ja mis lahendused arvutite 
  • poolt olid pakutud. Nimeta need ja seleta lahti. 
  •  Nõuete esialgne definitsioon. Millised veel on nõuete definitsioonid?  
  • why 
  • what 
  • how 
  •  Mis vahe nende mõistete vahel on: Süsteemi nõuded ja tarkvara nõuded?  
  •  Nõuete kolm mõõdikud koos seletustega.  
  •  Types of statements involved: descriptive vs. Prescriptive  
  •  Categories of requirements: functional vs. non­functional  
  •  A taxonomy of non­functional requirements  
  •  The requirements lifecycle: actors, processes, products  
  •  The requirement engineering process  
  •  Requirement engineering: an iterative process  
  •  Target qualities and defects to avoid  
  •  Types of software projects  
  •  Requirements in the software lifecycle 
  •  Relationship to other disciplines  
  •  The requirements problem: facts, data, citations  
  •  Role and stakes of requirement engineering.  
  •  Obstacles to good requirements engineering practice.  
  •  Millest koosneb tarkvarakvaliteet? Miks?  
  • Tarkvara kvaliteet = toode + nõuded + protsessid 
  •  Mis võiks olla kvaliteet? 
  •  Millest koosneb tarkvaratoode?  
  •  Nimeta erinevate osapoolte erinevad nõuded.  
  •  Nimeta süsteemi kvaliteedi nõuded vastavalt EVS­ISO/IEC 25010:2011 standardile.  
  •  Mis on funktsionaalne nõue? Too näited.  
  •  Mis on mittefunktsionaalne nõue? Too näited.  
  •  Nimeta nõue, mis on testitav.  
  •  Nimeta nõue, mis on mittetestitav.  
  •  Mis on reaalne nõue?  
  •  Mis on mittereaalne nõue?  
  •  Milline nõue on hea nõue?  
  •  Kas nõue peab olema koguaeg testitav?  
  •  Mis on tarkvaraprotsessid?  
  • tarkvara arendust
  •  Millistest komponentidest koosneb elutsüklimudel? 
  •  Kirjelda V­mudeli.  
  •  Mis on testimine?  
  •  Kui korraldad testimist, mida peale nõuetest ja protsessist peaks veel teadma?  
  •  Kuidas võiks jagada testimismeetodeid? Mis kaks põhilist meetodi on? Miks?  
  •  Kus leitud viga on kõige odavam parandada?  
  •  Räägi statistikast läbivaatuse kohta.  
  •  Valge kasti testimine.  
  •  Musta kasti testimine.  
  •  Halli kasti testimine.  
  •  Testimise tasandid. Nimeta need ja seleta lahti. Too näited.  
  • Ühiktestimine (Unit test) 
  • Lõimumise testimine (Integration testing) 
  • Süsteemi testimine (System test) 
  • Süsteemi integratsiooni testimine (Integration test) 
  • Regressioonitestimine 
  • Vastuvõtu testimine (Acceptance test)
  •  Testimise tüübid. Nimeta ja seleta lahti. Too näited.  
  • Funktsionaalne testimine 
  • Ekspertteadmiste testimine
  • Mittefunktsionaalne testimine 
  •  Millest koosneb testimise protsess?  
  • Nõuete analüüs
  • Testimise planeerimine
  • Testide arendamine
  • Testide täitmine
  • Testide aruandlus
  • Testitulemuste või vigade analüüs
  • Vigade uuesti testimine
  • Regressioonitestimine
  • Testimise lõpetamine
  •  Millal lõpetada testimist?  
  •  Mida teha, kui testida ei saa?  
  •  Kas igaüks võib olla testija?  
  •  Testijale abiks omadused ja oskused.  
  •  Valik jaotusi testimisele.  
  • Arendus testimine
  • vastuvõtutestimine 
  • Dünaamiline
  • staatiline testimine 
  • Checkimine 
  • testimine 
  • re­testimine 
  • Funktsionaalne
  • mittefunktsionaalne testimine 
  • Manuaalne 
  • automatiseeritud testimine 
  •  Testijaks olemise võlud.  
  •  Mis on tarkvara arhitektuur?  
  • ! Arhitektuur on vundament millele, tarkvara ehitatakse
  •  Erinevused funktsionaalsest disainist.  
  • Arhitektuurne disain
  • Funktsionaaldisain
  •  Mis on arhitektuuri erosioon.  
  •  Klient­server arhitektuur.  
  • probleeme. Järgnevalt mõned mustrid. 
  •  Komponentidel põhinev arhitektuur. 
  •  Kihiline arhitektuur.  
  •  Message bus.  
  •  N­tier.  
  •  Objekt orienteeritud arhitektuur.  
  •  DDD arhitektuur.  
  •  Teenus orienteeritud arhitektuur.  
  •  Monoliitne arhitektuur.  
  •  Mikroteenused.  
  •  Kuidas valida arhitektuuri? 
  •  Arhitektuuri disain.  
  •  Nimeta ja seleta lahti arhitektuuri disainimise protsessid. ka 
  • Won Kim
  •  Kes on arhitektuuri omanik?  
  •  Kuidas toimub töötamine arhitektuuriga suures meeskonnas?  
  •  Arhitektuuri testimine.  
  •  Agiilne arhitektuur. 
  •  Veebirakenduse arhitektuur.  
  •  Nimeta universaalsed põhimõtted ja seleta need lahti.  
  •  Hea arhitektuuri eelised ja nende seletused.  
  • kerge lugeda
  • kerge kasutada
  • kerge muuta
  • kerge testida 
  •  HTTP protokoll.  
  •  HTTP päring  
  • nimi:väärtus paarid
  •  HTTP vastus  
  •  Nimeta veebirakenduste liike ja seleta need lahti.  
  • Thin­client veebirakendused
  • Fat­client veebirakendused 
  • Veebiteenused 
  •  Veebirakendus JAVAs.  
  •  Servlet API  
  •  Model view controller  
  •  JSP  
  •  JAX­RS  
  •  Starter KITS  
  •  Alternatiivid servletile  
  •  Nimeta tööriistu ja raamistike veebirakenduse jaoks.  
  •  Riskide võrdlus
  •  Nimeta manifesto agiilse tarkvaraarendamiseks ja seleta need lahti.  
  • priority 
  • customer 
  • delivery 
  • software
  • measure of progress
  • changing requirements
  • late in development
  •  Agiilse meetodi printsiibid. Seleta lahti.  
  •  Agiilsete metodoloogiate maastik.  
  •  eXterme Programming.  
  • discipline 
  • organises 
  • higher­quality
  • productively 
  •  XP väärtused.  
  • communication
  • simplicity 
  • feedback
  • courage
  •  Scrum? Kõik, mis oli loengus. Seletada lahti kõik mõisted, tegevused ja osalejad.  
  •  Mis on kasutuslugu?  
  •  Kanban.  
  •  Minimal Marketable Feature (MMF)  
  •  Eesmärgi mudel  
  •  Kanban vs Scrum  
  •  Mis on mudel? Kus kasutatakse? Milleks on mudeleid vaja?  
  •  Tarkvaratehnika vaated.  
  •  Liikumine ühelt vaatelt järgmisele. 
  •  Tarkvaraprotsessi etapid.  
  •  Iteratiivne arendamine: Rational Unified Process (RUP)  
  •  Modelleerimine.  
  •  Mudelite klassifikatsioon.  
  •  Käitumise analüüs.  
  •  Interaktsioonide analüüs.  
  •  Struktuuri analüüs.  
  •  Interaktsioonide disain.  
  •  Struktuuri disain.  
  •  Käitumise disain.  
  •  Kuidas on varem arhitektuurist mõeldud 
  • durability
  • convenience 
  • beauty
  • ajaksaalal 
  •  Moodsa süsteemiarhitektuuri mõtte juured  
  •  Arhitektuuri olemus  
  •  Arhitektuuri roll  
  •  Mis on arhitektuur?  
  •  Mis on keerukus ja miks on see oluline?  
  •  Riigi kui selle arhitektuur 
  • country
  •  Riigi infosüsteemi kui terviku kontekstis ja miks on see oluline?  
  •  Süsteemid ja nende dünaamika  
  •  ICBM ja nende ohutus  
  •  Tänapäevased keerulised süsteemid  
  •  Süsteemi definitsioon ja süsteemimõtlemine  
  •  Arhitektuur süsteemimõtlemise kontekstis  
  •  Vorm, funktsioon ja kontseptsioon
  •  Arhitekti roll  
  •  Miks koodi disain on vajalik?  
  •  Clean Code  
  • inventor of Wiki and Fit 
  • co­inventor of eXtreme Programming
  •  Koodi lihtsa disaini neli elementi ja näited  
  •  Objektorienteeritud disain  
  •  Disaini mustrid  
  •  Finants­ või tehnoloogiaettevõtted?  
  •  «Äri», kelle jaoks IT taust on juba eeldus. 
  •  Lean põhimõtted.  
  •  Arenduse infrastruktuur ja konfiguratsioonihaldus  
  •  Mida endast kujutab arenduse infrastruktuur? 
  •  Milleks hallata nõudeid?  
  •  Milleks planeerida? 
  •  Versioonihaldus.  
  •  Build/Deploy. Toodangusse minek.  
  •  Virtualiseerimine.  

Kommentaarid (0)

Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri


Sarnased materjalid

62
pdf
72
docx
138
docx
24
docx
12
pdf
22
docx
1072
pdf
19
pdf





30 päevane VIP +50% ROHKEM

Telli VIP ja ole 30+14 päeva mureta

5.85€

3.9€

Oled juba kasutaja? Logi sisse

Faili allalaadimiseks, pead sisse logima
Kasutajanimi / Email
Parool

Unustasid parooli?

Pole kasutajat?

Tee tasuta konto