Tarkvaratehnika konspekt eksamiks (0)

Tarkvaratehnika  konspekt. 
Tarkvaratehnika 
Tarkvaratehnika e. tarkvara inseneeria on professionaalsele tarkvaraarendusele suunatud distsipli n, mis
tegeleb sel ega, kuidas organiseerida tarkvaraarendust, arvestades organisatsiooniliste ja rahaliste
piirangutega. Tarkvaratooted koosnevad valjatöötatud programmidest ja nende dokumentatsioonist.
Tarkvaratehnika eesmärgiks on kuluefekti vne tarkvaraarendus kogu tarkvara elukaare ulatuses.
Tarkvaratehnika on süstemaatilise, distsiplineeritud ja mõõdetava lähehemisvi si rakendamine tarkvara
arendamisele, käitamisele ja hooldamisele, see tähendab, inseneriteaduste rakendamine tarkvarale .
Tarkvaratehnika „point“: Tarkvaratehnika on suunatud professionaalsele tarkvaraarendusele.
Tarkvaratehnika ei tegele tarkvaraarenduse endaga vaid sel ega, kuidas organiseerida tarkvaraarendust.
Tarkvaratehnika vajadus - kõrgenenud nõudmised: suuremad süsteemid, keerulisemad süsteemid,
kiiremini arendatavad süsteemid. Insener suudab valmis programmeerida lihtsa kontrol eri. Kas seesama
insener saab hakkama ka lennuliikluse kontrollsüsteemi programmeerimisega?
Tarkvaratööstuse kriisi põhjus - puudus süstemaatiline lähenemine tarkvaraarenduse organiseerimisele.
Kvaliteetse tarkvara atribuudid:
•  omab nõutud funktsionaalsust,
•  hooldatav (tarkvara peab arenema, et vastata muutuvatele vajadustele),
•  usaldusväärne (tarkvara peab olema töökindel),
•  efekti vne (tarkvara ei tohi raisata süsteemi ressursse),
•  vastuvõetav (tarkvara peab olema aktsepteeritud kasutajate poolt, kel e jaoks ta on loodud –
tarkvara peab olema arusaadav, kasutatav ja ühilduv teiste süsteemidega).
Tarkvaratehnika vaated:
•  Omaniku vaade (Motivation layer ),
•  Kavandaja vaade (System design layer),
•  Ehitaja vaade ( Deployment layer).
Tarkvaraprotsessi etapid:
1.  Nõuete esiletoomine ja analüüs,
2.  Kavandamine e. disain (Arhitektuuriline kavandamine, Detailne kavandamine),
3.   Realiseerimine ,
4.   Testimine ,
5.  Hooldus ja evolutsioon .
Tarkvaraprojekti jaoks vajalikud osad: inimesed, nõuded, vahendid, testid-mockid.
Süsteem 
Tarkvaratehnika ei ole isoleeritud distsipli n vaid osa laiemast süsteemitehnikast. Tarkvarasüsteemid ei
ole isoleeritud süsteemid vaid sotsiaalsete süsteemide osad – sotsiotehniline süsteem.
Süsteem on üksteisega ühendatud olemite või komponentide hulk, mis moodustavad keerulise terviku
või täidavad koos keerulist funktsiooni. Süsteem võib sisaldada tarkvara, mehhaanilist, elektrilist ja
elektroonilist ri stvara ja ol a opereeritud inimeste poolt. Süsteemi komponentide omadused ja
käitumine sõltuvad teistest süsteemi komponentidest.
Tehnilised süsteemid - süsteemid, mis sisaldavad ri st- ja tarkvara ning kus kasutajaid ja
kasutusprotsesse ei käsitleta süsteemi osadena. Tehniline süsteem ei ole iseendast teadlik.
Sotsio -tehnilised süsteemid - Süsteemid, mis sisaldavad ni  tehnilisi süsteeme kui ka inimesi, kes
kasutavad tehnilisi süsteeme ja suhtlevad nendega ning kasutusprotsesse. 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 ning ri stvara, tarkvara ja andmete muudatustest).
Süsteemitehnika on sotsio-tehniliste süsteemide spetsifitseerimise, kavandamise, realiseerimise,
valideerimise, instal eerimise ja hooldamise protsess.
Protsess 
Protsess on sammude jada, mis hõlmab tegevusi, piiranguid ja ressursse mingit li ki tulemi loomiseks.
Tarkvaraprotsess ehk tarkvara arendusprotsess on sammude jada, mille eesmärgiks on tarkvara loomine
ja haldamine .
Üldistatud tegevused tarkvaraprotsessides:
•  Spetsifitseerimine – mida süsteem peab tegema ja mis on pi rangud tema arendamisel?
•  Arendamine – tarkvarasüsteemi tootmine.
•   Valideerimine – kas toodetud tarkvarasüsteem on see, mida kasutaja soovis?
•  Evolutsioon – tarkvarasüsteemi muutmine vastavalt kasutajate muutuvatele nõudmistele.
Tarkvaraprotsessi mudelid 
Tarkvaraprotsessi mudel - tarkvaraprotsessi lihtsustatud esitus teatud vaatepunktist. Näited
vaatepunktidest:
•  Tegevusekeskne (activity-centric) vaatepunkt (tegevuste jada),
•  Andmekeskne (data-centric) vaatepunkt (andmevood),
•  Rollikeskne ( role -centric või agent-centric) vaatepunkt (kes mida teeb),
•  Tulemikeskne (product-centric) vaatepunkt (mis on iga tegevuse tulem).
Plaanipõhine tarkvaraprotsess: kõik tegevused on ette planeeritud ja edu kriteeriumiks on plaani
järgmine.
Koskmudel on tarkvaraarenduse metoodika, mil es arendamise etappe kujutatakse nii, et iga etapp on
eelmisest allpool ning töö käigus li gutakse kose kombel järjest al apoole. Koskmudelis on järgmised
etapid:
•  nõuete analüüs,
•  disain,
•  programmeerimine,
•  testimine ja hooldamine.
Puudused:
•  Saab kasutada ainult si s, kui nõuded on fikseeritud;
•  Iga tarkvaraprotsessi etapp peab olema lõpetatud enne kui alustatakse järgmist etappi .
Eelised:
•  Plaanipärane arendus aitab koordineerida arendustööd suurte süsteemide loomisel, kui
süsteemi arendatakse erinevates kohtades.
Modifitseeritud kose mudel: igast etappist saab minna ühele eelmistest etappidest ja sealt juba alla
poole li kuda.
Agiilne tarkvaraprotsess: planeerimine toimub sammude kaupa töö käigus.
Iteratiivse mudeli kohaselt koosneb kogu protsess mitmest järjestikusest tsüklist (iteratsioonist), mis
kõik sisaldavad
•  analüüsi,
•  disaini,
•  programmeerimist,
•  testimist
kuid erinevates tsüklites on rõhk erinevatel sammudel.
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 suureneb), mil e pärast on vajadus
kasutada koodi refaktoreerimist.
Komponendipõhine tarkvaraarendus - Tegevus pole ülesannetele ja protsessile orienteeritud, vaid
töötava tarkvara loomisele. Süsteemi ehitatakse väikeste tükkide (komponentide) kaupa, mis pärast
pannakse kokku.
•  Nõuete analüüs,
•  komponentide analüüs (mis komponendid on vaja ehitada, kuidas komponentidest kõige
effekti vsem süsteem kokku panna),
•  nõuete muutmine (et läheks vastavusse komponentidega mis saame kasutada),
•  süsteemi kaevandamine (komponentide koorduvkasutamisega),
•  arendamine ja integratsioon,
•  süsteemi valideerimine ja testimine.
Seda protsessi võib teha ni  kosemudeli moodi kui ka iterati vselt.
Eelised:
•  Väiksemad riskid;
•  Spetsialistide parem kasutamine;
•  Parem vastavus standarditele;
•  Kiirem arendusprotsess.
Puudused:
•  Suuremad hoolduskulud;
•  Komponentide teegi ülalpidamine;
•  Korduvkasutatavate komponentide leidmine, neist arusaamine ja nende kohandamine .
Tarkvara arenduskulud – Arenduskulud ja Evolutsiooni-hoolduse kulud. Kulud sõltuvad arendatava
süsteemi tüübist ja süsteemile esitatud nõudmistest nagu näiteks jõudlus ja töökindlus . Arenduskulud
on umbes 1/4 kuludest ja evolutsioon on 3/4.
Tarkvara arenduskulude jaotus sõltub arendatava süsteemi tüübist ja kasutatavast tarkvaraprotsessi
mudelist.
•  Mittekri tilised süsteemid 40-20-40,
•  kri tilised 60-20-20 (nõuete analüüs, kaevandamine – kodeerimine – testimine).
Tarkvarainsenerid peavad käituma ausal ja eetiliselt vastutustundlikul viisil, kui soovivad ol a
respekteeritud professionaalidena. Eetiline käitumine on rohkem kui lihtsalt seaduste järgimine .
Professionaalse vastutuse aspektid:
1)   Konfidentsiaalsus . Tarkvarainsener peab respekteerima oma tööandja ja klientide
konfidentsiaalsust, sõltumata sel est, kas formaalne leping konfidentsiaalsuse kohta on al a
kirjutatud.
2)   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 .
3)  Intellektuaalne omand. Tarkvarainsener peab olema teadlik kohalikest seadustest ja määrustest,
mis sätestavad intel ektuaalse omandi kasutamise näiteks patentide ja kopeerimisõiguse näol.
Ta peab olema ettevaatlik, et tööandjate ja klientide intellektuaalne omand oleks kaitstud.
4)  Arvuti väärkasutus. Tarkvarainsener ei tohi kasutada oma tehnilisi oskusi teiste inimeste arvutite
väärkasutamiseks. Väärkasutus katab vahemiku suhteliselt triviaalsest (näiteks mängude
mängimine tööandja arvutil) kuni äärmiselt tõsiseni (vi ruste levitamine ja teiste arvutite
ründamine).
Nõuete analüüs 
Nõudeid on vaja püstitada rangel kujul, mõõdetaval kujul. Probleemil on 2 küljet – reaalne maailma
probleem ja infotehnoloogiline probleem, meid huvitab nende ühisosa. Nõuete analüüsimisel esimene
küsimus: Mis on probleem te püüte lahendada (Miks?) ning probleemi kontekst. Analüüsida süsteemi
nagu praegu on, panna mõisteid kirja ja si s juba nõudeid. Nõuete analüüs on eesmärgid, võimalused ja
piirangud mida me esitame oma tarkvara intensi vsele süsteemile. Eesmärk on teada saada, mil ist
süsteemi tahame – sel e võimalused, funktsioonid ta täidab, kuidas ta neid täidab. As-is süsteem -> To-
be süsteem.
Nõuete vahel tuleb teha kompromissi , mis ongi üks põhjustest miks nõuete analüüs on ni  oluline.
Nõuded on vaja kirjeldada ka agi lse arenduse käigus. Head nõuded on eelduseks edukale projektile.
WHY – tuleb küsida miks klient tahab midagi teha, mida ta tahab saavutada, mida tahab parandada
(eesmärgid).  Eesmärk muutub nõudeks.
WHAT – mida süsteem peab konkreetselt tegema ( funktsionaalsed teenused).
WHO – kes vastutab, kel e huvisid täidab see süsteem (vastutajate kohustused).
WHY – eesmärgid. WHAT – funktsionaalsed teenused. WHO – kohustuste jagamine vastutajate vahel.
Descriptive statements (deskriptiivsed väited ) state system properties holding regardless of how the
system should behave. Prescriptive statements (eesmärgilised väided) state desirable properties
holding or not depending on how the system behaves.
Funktsionaalsed nõuded – mil istel tingimustel mil iseid funktsioone peab süsteem täitma. Vastab
küsimusele: „Mida peab tarkvara tegema?“ (ärinõudmised, ärireeglid, standardid , funktsionaalsus). (nt.
Süsteem peab võimaldama kauba tellimist). Nt. Pangasüsteem: põhifunktsioonid on kontode avamine,
transaktsioonid, laenu andmine jne. Need funktsioonid on kaetud funktsionaalsete nõuetega. Ükskõik
mis süsteemi puhul, me peame defineerima nõudeid, mida süsteem peaks täitma. Tuleb välja töödelda
test caseid, ja sel ega saab kontrol ida, kas süsteem töötab ni , nagu peaks või mitte.
Mittefunktsionaalsed nõuded – mis pi rangutega peavad mil ised funktsioonid täidetud olema.
Jagunevad väga paljudeks nõueteks. Vastab küsimusele: „Kuidas tarkvara peab vajalikke funktsioone
täitma?“ (süsteemsed nõudmised ja pi rangud, tõhusus, täpsus, turvalisus,  inimturvalisus, andmekaitse
turvalilsus, ajaline ja ruumiline kiirus, töökindlus, kasutajali des, välja töötamise aeg, hind,
maintainability(süsteem peab olema sel ine, et seda on kerge ümber häälestada. Kui süsteem on tehtud
nii, et muudatusi on raske el u vi a, si s see sattub süsteemi saatuslikuks , instal imine jne). (nt. Peab
teenindama 1000 üheaegset kasutajat, Peab olema kättesaadav välisvõrgus, Peab saama kasutada õues
päikese käes). Süsteem võib tätma funktsioone, aga võib olla kasutamatu.
Väljatöötlemise nõuded – nt hind. Kui meil on lõpmatult raha, si s me võime ülihea süsteemi teha. Aga
see on ni  kal is, et keegi ei tel i seda hinna pärast. Kõik on hea, kvaliteedi ja funktsionaalsed nõuded on
täidetud, aga tegelikult seda keegi ei osta.
Erinevatel osapooltel on erinevad nõuded. Nõuete kaevandamise protsess: Miks -> Mida -> Kel ele.
Mil ist probleemi me sel e projektiga lahendame? Kas „MIDA“ on defineeritud? Kas „Kel ele“ on tegelik
nõude omanik? Mine nii sügavale kui vaja, et leida juurpõhjus/nõue.
Nõuete püstitamisel on oluline, et nad oleksid reaalsed ja testitavad.
Hea nõue on:
•  Üheselt mõistetav;
•  Selge ja lühike;
•  Täpne, arusaadav;
•  Realiseeritav ja testitav ;
•  Sõltumatu;
•  Vajalik ja aktuaalne ;
•  Täielik, kõik info ühe nõue juures.
Nõuetest arusaamine on eduka projekti alus.
Eesmärk on see, mida me veel ei oma.  Meil on erinevated ütlused maailma kohta: kirjeldavad ja
tuleviku vaatavad (eesmärgi pärased).  Need on seisundid , kuhu me tahame jõuda või mida me tahame
hoida.  
Pehmed ja tugevad nõuded.
Pehmed on sel ised, et tahame midagi paremat, nt. et ettevõte kasum kasvaks, tarkvara oleks ki re. Need
ei ole mõõdetavad ega testitavad. Need on pehmed, sest nt ki rus on väga subjekti vne asi.
Tugevad  nõuded on sel ised, kui me näiteks ütleks, et tarkvaraki rus peaks olema 2 sek. Nõuded on
tugevad, kui eksisteerib mingi standard. Nt. Turvanõuded on määratud standardiga.
Süsteemi nõuded on üldisemad nõuded. Tarkvara nõuded on spetsi filisemad, kui süsteemi nõuded.
Need nõuded jagunevad ka edasi nõueteks.
Nõuete välja selgitamiseks:
1.   Süsteemist /valdkonnast arusaamine – uurima organisatsiooni struktuuri, dokumentatsiooni.
Dokumentatsioonist saab teada valdkonna mudelit, äriprotsesse, mõisteid.Kui on lihtne
süsteem, siis vb ei võta palju aega. Kui valdkonda ei tunne, si s peab sellest valdkonnast
aru saada.
2.  Küsitlema, selgeks tegema Why, What(nõuded), Who(kes teeb). Mõistete tagasisidemana
küsimine. Esialgne mõistete kirja panemine .
Tuleb erinevad osapooled, kes ja mil e eest vastutab sel es ettevõttes kirja panna. Ja si s
hakata uurima neid.
3.  Spetsifitseerimine ja dokumenteerimine
Nõuete kirja panemine. Funktsionaalsed nõuded pannakse F1, F2, F3, jne .. Ja si s peab
olema use- case või test case nõue kontrol imiseks. Iga nõue on eraldi kirja panema , see
võib ol a ka tabeli kujul.
4.  Nõuete valideerimine ja verifitseerimine.
Nõuete kvaliteet:
•  Nõued peavad tulema välja sel ised, et kõik osapooled on nendega rahul. Nt. tarkvara arendusel
3 osapoolt: Süsteemi omanik, Süsteemi töötajad, Arendajad .
•  Nõued ei saa olema vastuolus .
•  Ei tohi olla üleliigseid nõudeid.
•  Nõuded peavad olema mõõdetavad.
•  Nõuetega seotud vead on kõige levinumad, most persistent (leitud tihti pärast tarkvara
väljalaset), kõige kal imad.
•  Nõuded peavad olema adekvaatsed, s.t. neid peab olema võimalik täitma.
•  Nõuded peavad olema hästi struktureeritud.
•  Nõuded peavad olema pi savad.
Testitav/Mittetestitav nõue - Nõuete püstitamisel on oluline, et nad oleksid testitavad.  Otstarbekas on
püstitada testitavad nõuded, muidu ei saa nende täidetust hinnata.
Reaalne/ Ebareaalne nõue – Nõue võib ol a testitav, kuid ebareaalne, ebamõistlik, ebapi savalt
spetsifitseeritud jne.
Disaini faasis on vigade parandamine on 5 korda kal im, kui nõuete faasis.
Realiseerimise faasis on vigade parandamine 10 korda kallim, kui nõuete faasis.
Testimise faasis on vigade parandamine 20 korda kallim, kui nõuete faasis.
Toodangus on vigade parandamine 200 korda kallim, kui nõuete faasis.
Teine võimalus nõuete analüüsi kaardistamiseks (Eesti energia näitel):
Protsessi analüüs
•  As-IS kaardistus ja TO-BE kirjeldamine
Ä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 – see ei puutu ärist.
•  Mil ised tehniloogiaid kasutatakse
•  Kuidas toimub logimine
•  Kuidas süsteemi konfigureeritakse

Tarkvara kvaliteet 
Väga lühidalt on kvaliteet toote vastavus nõuetele. Keerukate toodete puhul tuleb vastavuse hindamisel
arvesse võtta ka toote loomise protsessi. Tarkvara kvaliteet seob toote, nõuded tootele ja tootmise
protsessi. Kvaliteeti ei saa sisse testida. Halvasti arendatud süsteemi pole võimalik kontrolli abil heaks
muuta.
Lõpptulemus sõltub kogu arendusprotsessist:
•  vajadustele vastavast ri stvarast,
•   tarkvara arenduse meetoditest ja vahenditest,
•  projekti- ja kvaliteedihaldusest,
•  organisatsioonist,
•   standarditest.
Tarkvara kvaliteet = toode + nõuded + protsessid
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”) – sel ine
teadmine võib anda kasulikku infot hankimisel.
Kvaliteet kui suhe toote, nõuete, protsesside vahel(“hinnataset arvestades oli hotelli kvaliteet väga hea”)
– sel ine suhe on alati olemas ja abiks hinnaefekti vsel tegutsemisel kõigis rol ides.
Kvaliteet kui mõõt – mõõt on alati olemas(ka näiteks si s, kui “sel e süsteemi kvaliteet on madal”).
Tarkvaratoode 
Millest koosneb?
•  Arenduse käigus hangitud infotehnoloogiavahendid: riistvara , standardtarkvara, sideandmed.
•  Arenduse käigus tehtud töö: täitja arendatud tarkvara (sealhulgas lähtekood, objektkood,
täitmiskood jm); instal atsioonid, kohandamised, muudatused, andmehõive.
•  Muudatused tel ija organisatsioonis, protsessides, töökorralduses
•  Metoodika: tulemuste kasutamine, tulemuste edasiarendamine, uute arenduste tegemine
•  Projektdokumentatsioon kasutamise kohta(kasutajajuhendid), objektsüsteemi(nt organisatsioon ,
mil e jaoks tarkvara arendatakse) kohta, loodavate objektide kohta (programmi/testimise
dokumentatsioon ), instal eerimise ja seadistamise kohta, arenduse (sh testimise) kohta
•  Teadmised projekti tulemuste kasutamisest, objektsüsteemist(süsteemianalüüs või vajalikud
muudatused seadusandluses), projektist, arendusest
•  Õigused tööks, arendamiseks , levitamiseks
•  Vahendid hoolduseks, muudatuseks, arenduseks.
Nõuded
Mida klient tahtis -> Mida sai aru projektijuht -> Mida analüütik pani kirja -> Mida programmeerija tegi -
> jne ...
Erinevad inimesed näevad nõudeid erinevalt. Erinevatel osapooltel on erinevad nõuded:
•  Omanik võib nõuda, et süsteem oleks kuluefekti vne
•  Kasutaja võib soovida loetavat kirja ekraanil
•  Hooldaja näeks heameelega arusaadavat koodi
Tarkvaraprotsessid 
Tarkvara model eerib tegelikkus ja võib ol a väga keerukas, samuti võib ol a väge keerukas sel e arendus.
Et sel e keerukusega hakkama saada, on tarkvaraga seonduvaid tegevusi, tulemeid, dokumentatsiooni
mõistlik kuidagi struktureerida. Seda saab teha protsesside ja elutsükli mudelite abil.
Tuleks eristada tarkvara elutsükli mudeleid ja protsessiraamistikke.  Teenuste protsessiraamistikud:
ISO/IEC 12207, CMMI, COBIT, ITIL. Nad hõlmavad väga mitmesuguseid protsesse, mitte ainult tarkvara
arendust. Näiteid protsessidest: hankimine , tarnimine, ekspluatatsioon, hooldus, konfiguratsiooni
haldus, muudatuste haldus jne.
Tarkvara elutsükli mudelid
•   Code -and-fix mudel
•  V-mudel
•  Koskmudel e lineaarne mudel
•  Evolutsiooniline mudel
•  Formaalne süsteemi mudel
•  Korduvkasutusele tuginev mudel
•  Prototüüpimine
•  RUP-mudel
•  RAD-mudel
•  Komponenttehnoloogiale tuginev mudel
•  Agi lne mudel
Testimine 
Kitsamas mõttes on testimine tarkvara täitmine / käivitamine kontrol imaks, kas ta vastab ettenähtud
nõuetele ning leidmaks vigu. Laiemas mõttes on testimine tarkvara analüüsi protsess eesmärgiga leida
erinevusi olemasolevate ja nõutud tingimuste vahel ning hinnata tarkvara omadusi.
Testimist võib laias mõttes määratleda ka kui kõikidest elutsükli tegevustest (ni  staatilistest kui ka
dünaamilistest) koosnevad protsessi, mis puudutab tarkvara ja sel ega seotud toodete planeerimist,
ettevalmistust ja hindamist ning mil e eesmärk on kindlaks teha toodete vastavus spetsifitseeritud
nõuetele, näidata et nad vastavad eesmärgile ning leida defekte.
Efekti vseks testimiseks ei pi sa vaid süsteemist. On vaja teada nõudeid ja protsesse, mis omakorda
tulenevad:
•  ülesande püstitusest,
•  organisatsioonist,
•  seadusandlusest,
•  standarditest,
•  riskianalüüsist,
•  headest tavadest,
•  kasutajatest,
•  kasutusviisist jne.
Staatiline testimine (static testing) – süsteemi või komponendi (koodi või dokumendi) testimine ilma
testitavat tulemit käivitamata (läbivaatus, staatiline analüüs).
Dünaamiline testimine – testimine, mil e käigus testitavat tarkvara käivitatakse.  Klassikaline testimine.
Tarkvara inspektsioon võimaldab leida 70-80% vigadest enne funktsionaalset testimist.
Tunni jooksul leitav vigade keskmine arv:
•  Funktsionaalne valge kasti testimine – 0.282
•  Funktsionaalne musta kasti testimine – 0.322
•  Läbivaatlused – 1.056(nt Standupid)
Reeve’i ruusikareegel – iga inspektsiooni käigus leitud viga säästab 9.3 töötundi.
Kastide testimine (valge/musta/hal i kasti meetodid).
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:
•  Rakendusliideste testimine – rakendust testitakse avalike ja privaatsete
rakendusli deste kaudu
•  Koodi ulatus – luuakse teste , mis testivad koodi ulatust. Näiteks testi disainer võib luua
testi, mil e käigus kõiki avaldisi(lauseid/käske) programmis käivitatakse vähemalt ühe
korra
•  Vigade süstimine – koodi ulatuse parandamine kontrol ides, kas tarkvara töötab vigade
liamisel
•  Staatiline testimine – valge kasti testimine hõlmab kogu staatilist testimist
Musta kasti testimine: Testimine kohtleb tarkvara kui "musta kasti", teadmata midagi sel e
sisemisest teostusest. Musta kasti testimismeetodite hulka kuuluvad:
•  Spetsifikatsiooni põhine testimine
•  Juhuslikud sisendid ja lisatud vead
•  Uurimuslik testimine
•  Piirväärtuste analüüs
•  Suitsu testimine
•  Kasutusmugavuste testimine
Halli kasti testimine: Testimisel on olemas juurdepääs sisemistele andmestruktuuridele ja
algoritmidele testjuhtumite koostamisel, kuid testimine vi akse läbi kasutaja või musta kasti
tasemel. Hal i kasti testimise al a kuulub andmebaasi muutmine, sest tavaliselt ei saa kasutaja
väljaspool testitavad süsteemi andmeid muuta. Hal i kasti testimine võib hõlmata ka
pöördprojekteerimist leidmaks näiteks piirväärtusi või tõrketeateid.
Testimise tasandid :
1.   Unit test (individual components),
2.  Integration test (component group),
3.  System test (system as a whole ),
4.  Acceptance test (system as a whole – customer requirements).
Ühiktestimisel (Unit testing) vastab üks test konkreetsele koodi osale, tavaliselt funktsioonile.
Objektorienteeritud keskkonnas testitakse klasside tasemel ja minimaalsesse testi kaasatakse ka
konstruktorid ja destruktorid. Ühikteste kirjutavad arendajad tavaliselt valge kasti sti lis, et kontrol ida,
kas mingi funktsioon töötab, nagu ette nähtud. Ühe funktsiooni kohta võib ol a mitu testi, et kontrol ida
funktsiooni töötamist pi rväärtustel või erinevaid koodi harusid. Ühiktestimisega ei saa tagada terve
tarkvaratoote õigsust. Pigem kontrol itakse sel ega, kas erinevad tarkvara osad töötavad üksteisest
eraldi.
Lõimumise testimine (Integration testing) - kontrol itakse, kas komponentide vahelised li desed
vastavad tarkvara disainile. Tarkvara komponente võib integreerida järk-järgult või ühekorraga.
Tavaliselt eelistatakse vi mast, sest ni  saab ki remini leida ja parandada vigu li destes. Selline testimine
paljastab defektid li destes ja vastastikustes toimetes integreeritud komponentide (moodulite) vahel.
Integreeritakse ja testitakse järjest suuremaid tarkvara komponentide gruppe, mis vastavad
arhitektuurilise disaini elementidele, kuni kogu tarkvara töötab ühtse süsteemina.
Süsteemi testimine - testitakse täielikult integreeritud süsteemi, et kinnitada süsteemi nõuetele
vastavust. Musta kasti testimine.
Süsteemi integratsiooni testimine - kinnitatakse, et süsteem on integreeritud mistahes välise või
kolmanda osapoole süsteemiga, mis on määratletud süsteemi nõuetes.
Regressioonitestimine - eesmärgiks on otsida vigu pärast koodi olulist muutmist. Tavaline
regressioonitestimise meetod on läbi vi a varem kasutatud teste, et kontrol ida, kas eelnevalt kindlaks
tehtud rikked on taas esile kerkinud. Regressioonitestimise ulatus sõltub arendustegevuse etapist ja
lisatud funktsionaalsuse kaalukusest. 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.
Vastuvõtu testimine võib tähendada kahte asja:
1.  Viiakse läbi proovitest, et kontrol ida, kas uus tarkvara komponent on vastuvõetav peamisse
testimise protsessi, näiteks enne lõimumis - või regressioonitestimist.
2.  Kliendi tehtud testimist, tihti tema enda arenduskeskkonnas ja ri stvaral, nimetatakse
kasutaja vastuvõtu testimiseks.
Funktsionaalne testimine –
•  Riskipõhine - idee on testida esmalt tootega seotud kriitilisi riske,
•  Uuriv testimine (exploratory testing) -  mitteformaalne tarkvara testimise tehnika, mil e puhul
testija hindab testide kavandamist nende täitmise käigus ja kasutab saadud informatsiooni uute
ja paremate testide projekteerimiseks,
•  Suitsu testimine (smoke testing) - täidetakse alamhulk kõigist testidest selgitamaks, kas
põhilised funktsioonid töötavad. Nimetus tuleneb elektroonikatööstusest - seadme esmane
sisselülitamine), Ekspertteadmiste põhine (kogenud arendaja või testija oskab tõenäolisi vea
kohti ette aimata). Kontrol , kas kõik töötab v mitte. Kas saab testijale üle anda või mitte. See on
nn ki r ülevaade.
Ekspertteadmiste põhine testimine – Kasutatakse nt si s, kui tehakse kasutusmugavustega seotuid
teste. Kogenud arendaja või testija oskab tõenäolisi vea kohti ette aimata. Tõenäoliste vigade leidmine
võib sõltuda mitut sorti eelteadmistest, mil eks on:
•  Üldised teadmised
•  Teadmised konkreetsete rakendusvaldkonna (nt konkreetse programmeerimisekeel) kohta
•  Teadmised mingi vigade tüübi kohta (nt tüüpilised infoturbega seotud kodeerimise vead)
•  Teadmised arendusmetoodika kohta
•  Teadmised konkreetse arendaja või tel ija kohta
Mittefunktsionaalne testimine
•  Jõudlustest kontrol ib, kui kiiresti tarkvara töötab kindla koguse andmete või kasutajatega.
•  Koormustestimisega kontrollitakse, kas tarkvara suudab püsivalt töötada kindlal koormusel. Kui
koormustestimist tehakse mittefunktsionaalselt, si s nimetatakse seda tihti vastupidavuse
testimiseks.
•  Stabi lsuse testimine kontrol ib, kas tarkvara on võimeline pidevalt töötama kindla ajaperioodi
jooksul. Seda nimetatakse mõnikord vastupidavuse testimiseks.
•  Kasutatavuse testimine kontrol ib, kas kasutajali dest on lihtne kasutada ja mõista, Tehakse
eyetrackingut, mil ega analüüsitakse, kuhu vaatab tavaline kasutaja ja kus oleks kõige sobivam
paigutus nt nupu jaoks
•  Turvalisuse testimine on oluline tarkvara puhul, mis töötleb konfidentsiaalseid andmeid, et
vältida süsteemi häkkimist või ründamist,
•  Destrukti vne testimine üritatakse tekitada tõrkeid tarkvaraprogrammis või käivituskeskkonnas,
et testida selle robustsust. Üritame seda katki teha erinevate vi sidega.
Testimise tsükkel –
•  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,
•  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, mil iseid vigu tuleks parandada, mil ised tagasi lükata (st leiti, et tarkvara töötab
korralikult) ja mil iseid vigu parandada mil algi tulevikus,
•  Vigade uuesti testimine - Kui arendusmeeskond on üritanud viga parandada, si s testitakse seda
uuesti,
•  Regressioonitestimine - tagada, et vi mased muudatused midagi ei lõhkunud ja et tarkvaratoode
tervikuna töötab endiselt õigesti ,
•  Testimise lõpetamine - Kui katse vastab lõpetamise kriteeriumitele, si s tegevused nagu väljundi
püüdmine, õppetunnid, tulemused, logid ja projektiga seotud dokumendid arhiveeritakse ja neid
kasutatakse viitena tulevastes projektides.
Testimise resultati vsust pole kerge hinnata. Seepärast pole ka testimise mahu üle otsustamine kerge.
Testimise lõpetamine: Ideaalselt peaks testimise maht sõltuma tarkvarale esitatud nõuetest - testitakse
seni, kuni need on rahuldatud. Praktiliselt tehakse ni  vaid tõesti kri tiliste rakenduste korral. Põhjusi on
palju, näiteks:
•  Nõudeid ja nende rahuldatust on rakse hinnata
•  Töö tuleb ki resti üle anda
•  On olemas eelnev kogemus ja see määrab testimise mahu
•   Rakendus ei ole kri tiline (kui midagi juhtub, si s keegi eriliselt ei kannata)
Testimise maht ja lõpetamine. Kriteeriumid:
•  Esimesed testid jooksid läbi
•  Kasutaja ei oska rohkem tahta
•  Testimise(või halvemal juhul süsteemiarenduse) aeg või raha on läbi
•   Eelmine kord testisime samapalju ja oli hea kül 
•  Süsteemi üleandmise tähtaeg on käes
•  Paistab, et edasine testimine ei anna uusi vigu
•  Pole enam huvitav, tahaks midagi muud teha
•  Kõik ekvivalentsiklassid peavad olema testitud
•  Testimine peab vastaba 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%
Neid kriteeriume võiks panda lepingusse, kus on kokku lepitud, mil al testimine lõpeb ja mil al võiksid
vastuvõtutestid alustatud.
Testimisele annab kaasa, kui testija oskab:
•  Üldistada
•  Osata näha suuri pilti
•  Ja julgeb küsida küsimusi
•  Uudishimu
•  Suhelda
•  Lugeda
•  Kirjutada
Arhitektuur  
Arhitektuur on süsteemi osade ja nende omavaheliste seoste abstraktne kirjeldus. Süsteemi
illustratsioon, mis aitab arusaada süsteemi käitumisest. Vorm on see, mis süsteem on. Funktsioon on
see, mida süsteem teeb. Kontseptsioon on see, kuidas neist mõelda. Arhitekti töö seisneb töös vormi,
funktsiooni ja kontseptsiooni kui tervikuga . Vormist ( arhitektuurist ) tulevad kulud, funktsioonid tulud.
Nende vahe ongi profit .
Süsteemi arhitektuur on struktuuride kogum, mis aitavad mõista süsteemi, hõlmates tarkvara elemente,
seoseid nende vahel ja elementide ning seoste omadusi.
Arhitektuur on vundament mil ele, tarkvara ehitatakse. Arhitektuuri juhivad mittefunktsionaalsed
nõuded, funktsionaaldisaini juhivad funktsionaalsed nõuded. UML komponendi-, paigaldus- ja
paketidiagrammid on enamasti arhitektuuri dokumentatsioonis.
Arhitektuurne disain - protsess, mil e käigus defineeritakse ri stvara ja tarkvara komponendid ja nende
liidesed , kujundamaks välja raamistikku tarkvara arendamiseks.
Eeldisain - protsess, mil e käigus analüüsitakse arhitektuuri alternati ve ja defineeritakse arhitektuur,
komponendid, li desed igale tarkvara komponendile.
Detaildisain - eeldisaini tulemi laiendamine/täpsustamine saavutamaks vajalikku täpsust arendamise
alustamiseks.
Funktsionaaldisain - protsess, mil e käigus defineeritakse seosed süsteemi komponentide vahel.
Arhitektuur on disain aga mitte kõik disainid ei ole arhitektuur. Arhitektuuri juhivad
mittefunktsionaalsed nõuded, funktsionaaldisaini juhivad funktsionaalsed nõuded. Pseudokood kuulub
detaildisaini dokumentatsiooni.
UML komponendi-, paigaldus- ja paketidiagrammid on enamasti arhitektuuri dokumentatsioonis.
UML klassi-, objekti-, käitumisdiagrammid kuuluvad funktsionaaldisaini dokumentatsiooni.
Arhitektuuri erosioon – kui mingi hetk üks arendaja rikkub arhitektuuri visiooni (nt. ühendab kihid mis
omavahel ei tohi suhelda) ning see järel tekkib „broken window effect“(seisab üks mahajäetud maja.
Kõik on majaga korras. Maja seisab aastaid. Piisab , kui üks inimene või aeg lõhub ära ühe klaasi. Siis
õigepea katkeneb teine klaas, kolmas jne ja si s tekib vajadus maja lammutada). – teised arendajad
peatuvad jälgima seda reeglit ka. Arhitektuuri erosioon – arhitektuuri mitteteadlik muutmine,
lõhkumine.
Arhitektuur on oluline sel epärast, et sel est sõltub kuivõrd kal is on süsteemi edasi arendada või
muutma . Kui arhitektuur ei ola paigas, si s iga muudatus muutub aina kallimaks.
Arhitektuuri  mustrid  
Arhitektuuri mustrid – mil el põhinevad enamus arhitektuuridest.  Enamasti kasutatakse tarkvara
vundamendi ehitamises erinevate arhitektuuri mustrite kombinatsiooni . Iga muster on millegi jaoks
head. Aga igas mustris on ka omad mi nused. Mustrid ei asenda teine teist.
Enamkasutatavad mustrid:
•  Klient- Server – kuskil on server, tema ümber on kliendid mis suhtlevad ainult serveriga või läbi
serverit üks teisega . (P2P, Skype ) Kasu:
o  Andmed on tsentraliseeritud
o  Kõrge turvalisus
o  Lihtne hal ata
•  Komponentidel põhinev süsteem on jaotatud komponentideks, igal komponendil on oma
ülesanne. Kasu:
o  Kerge paigaldada
o  Kerge ehitada
o  Odav hind
o   Taaskasutatav
o  Lahendab tehnilist keerukust
o  Asendatavad komponendid,
o  Laiendatav,
o  Kapseldatud komponendid (Komponent on kasulik ainult si s, kui ta on ära kapseldatud)
o  Sõltumatus.
o  Süsteem on si s kerge paigaldada, kerge ehitada, odav hind, taaskasutatav, lahendab
tehnilist keerukust. Komponent peaks lahendama mingit konkreetset ülesannet.
•  Kihiline arhitektuur – arhitektuur on jagatud kihtideks, iga kiht suhtleb ainult oma naabridega.
Igal kihil on oma üks ülesanne. Läbi kõike kihtide jooksevad domeeni objektid ja globaalsed
kihid nt. turvalisuskiht ja logimiskiht. Ükski komponent või kiht ei peaks tegelema rohkem, kui
ühe ülesandega. On ärilises tarkvaras kõige enamasti kasutatav lahendus. Omadused:
o  Abstraktne,
o  Manageeritav
o  Kapseldatud,
o  Selgelt defineeritud kihid  - Igal kihil on oma spetsiifiline ülesanne.
o  Taaskasutatav,
o  Nõrgalt seotud – kihtide vahel on seotud ainult ülemise ja alumise kihiga.
o  Isoleeritud,
o  Hea jõudlus – kui probleemid andmebaasiga suhtlemisega, si s pole mõtet UI poolel
muudatusi tegema, vaid peaks parandama andmebaasi kiht.
o  Testitav.
•  Message Bus (Enterprise Service Bus) – üks kiht, mil e läbi kõik suhtlus käib. Ükski rakendus ei
tohi teisega suhelda ilma et ta ei käiks läbi service bus-i. Sa ei pea igat rakendust ümber tegema,
et ta saaks teiste rakendustega suhelda. Tuleks  ainult defineerida ühendust, et rakendus saaks
service bus’ga suhelda. Näide: X-Tee. Kasud :
o  Laiendatavus,
o  Nõrgalt seotud,
o  Skaleeritavus – kui kõik käib läbi ühte konkreetse koha läbi, si s see muutub lõpuks
pudelikaelaks. Service bus on mitteskaleeriv.
o  Aplikatsioonide lihtsus.
•  N-tier – nagu mitmekihiline arhitektuur, aga kihid ei ole tarkvara sees, vaid on ri stvaralised. Nt.
brauserkiht, serverkiht, rakendus ise, andmebaas – riistvaraline jaotus, kihid asuvad füüsiliselt
erinevates masinates. Kasud:
o  Hal atavus,
o  Skaleeritavus – laiendamine, ehk kui jõudlusest jääb puudu, siis paneme ühe purgi
juurde. Tihtipeale ei saa rakendust paralleelselt mitmest arvutist tööle panna.
Skaleeritavus aga lubab seda.
o  Paindlikus,
o  Kättesaadavus.
•  Objekt-orienteeritud – arhitektuur objekt-orienteeritud põhimõttega. Igal objektil on oma
ülesanne, objekte saab laiendada, omavahel siduda jne. Omadused:
o  abstraktsioon,
o  kompositsioon,
o  pärilus,
o  kapseldamine – et objekt võiks samuti omada mingit põhifunktsionaalsust,
o  polümorfism,
o  eraldatus.
Kasu:
o  Arusaadavus,
o  Taaskasutatavus – kui oleme loonud klassi, si s on võimalik sel est klassist alamklassi
luua või seda klassi laiendada ja kasutada seda natuke muus vormis,
o  Testitavus – kui rakendus on loodud objektina või komponendina, si s on sel ist
rakendust kergem testida. Sel eks, et testida komponenti – ei ole vaja tervet süsteemi
testida,
o  Laiendatavus,
o  Kõrge kohesi vsus - seotud funktsionaalsus on ühendatud samasse klassi.
•  DDD – objekt-orienteeritud arhitektuuri laiendus, kus lähtutakse ärilisest domeenist. Domain
Driven Design. Aga räägime domeen keeles, äri keeles. Kasu:
o  Äriline mõistmine – arendaja ja äri nimene kasutab samu mõisteid, mida pärast
programmeeritakse.
o  OO kasud.
•  Teenus orienteeritud arhitektuur (SOA) – rakendused suhtlevad omavahel kokku leppitud
protokoliga. Nt. SOAP protokoll (WSDL). Aga suurtes süsteemides on raske. Sellepärast jäeti
varuvariandiks, ja reeglina proovitakse ilma hakkama saada. Oli POP umbes 7 a tagasi.
Omadused:
o  Autonoomne – iga teenus on iseseisev.
o  Jagatav - Seda saab ka iseseisvalt testida.
o  Nõrgalt seotud,
o  Jagatakse lepingut ja skeemi, mitte sisemisi klasse – ehk saab seespoolt rakenduse
ümber ehitada ilma et muuta lepingut. Kasu:
o  Abstraktsus,
o  Leitavus – iga süsteem vastutab oma spetsiifilise osa eest üldises aplikatsioonis ja see
osa on tavaliselt teada, kus mis asub.
o  Erinevad platvormid  - ei pea valima tervele süsteemile ühe ja sama arenduskeele või
ülesehituse. Iga rakendus on iseseisev ni kaua kuni ta järgib kokkulepitud lepingut.
o   Ratsionaalsus .
•  Monoli tne arhitektuur – kõige lihtsam arhitektuur, funktsionaalselt eristatavad osad ei ole
lahutatud komponendid, ega eraldi kihtina. Lihtsalt võetakse ülesanne ja lahendatakse ära.
Enamus rakendusi töötavad ni .
•  Mikroteenuste arhitektuur - sarnane teenus orienteeritud arhitektuurile. Keeruline ohjas hoida,
kipub käest ära minema. Teenused on väiksemad. Teenused komponentide vahel ,mitte
erinevate rakenduste vahel. Tuli koos pilvede teenustega . Pilvedes tarkvara on iseseisev ja
reeglina tehtud ni , et ta oleks skaleeritav. Kasud:
o  Sama mis teenusorienteeritud arhitektuuril,
o  Lihtsalt skaleeritav,
o  Tehnoloogiste valikute muutmise osas vabam.
Arhitektuuri kavandamine 
Kuidas valida arhitektuuri? Mõelda,
•  kuidas kasutajad kasutavad süsteemi (nt. online või offline, nendel on erinevad nõuded),
•  kuidas süsteemi paigaldada (automated deployement. Automatiseerimine: tasub alati korduvad
tegevused anda masina kätte),
•  mil ised on mittefunktsionaalsed nõuded (turvalisus, jõudlus, paral eelsus, multikeelsus,
konfiguratsioon),
•  kuidas saavutada paindlikus ja hal atavus läbi aja,
•  mil ised on arhitektuuri trendid mis võivad mõjutada süsteemi praegu või tulevikus.
Võtme jõud, mis mõjutavad arhitektuuri:
•  Kasutaja volitused - kasutaja kogemus: ära dikteeri. Kasutajad muutuvad ebaõnnelikuks, kui
peaks tegema midagi nende loogikaga vastuolas.  
•  Turu küpsus - kasuta valmis komponente, ära leiuta jalgratast. Alati tasub otsida, äkki on keegi
midagi sarnast teinud.
•  Paidlik disain - taaskasutatavus, hal atavus, skaleeritavus(pole odav). Tuleviku trendid mõjutavad
alati arhitektuuri.
Mõned tarkused:
Ära üle inseneeri . Ära tee eeldusi , mida ei saa kontrollida. Tee täpselt seda, mida peab tegema. Kunagi ei
tuleks eelduda, vaid tuleks kohe fakte kontrol ida.  Mõelda võiks:
•  Mis on fundamentaalsed osad arhitektuurist, mil e valesti tegemine on väga suure riskiga
süsteemi toimimisele. Alati on olemas mingi rakenduse osa, mil e ümbertegemine on väga kal is.
Tuleks olema valmis sel eks, kui mingi häda tuleb.
•  Mil ine osa süsteemist on suurima muutumise tõenäosusega. Kui oskame sel ele vastata, si s
oskame ka arhitektuuri valida. Osa, mis suure tõenäosusega muutub, tuleks planeerida nii, et
seda oleks kerge muuta.
•  Mil iste osade disainimist võib edasi lükata ilma märkimisväärsete mõjudeta. Samuti tuleks
mõelda, kas mingi osa süsteemist saab disainida hiljem? Sest tulevikus võib ol a parem ülevaade
probleemist. Mida rohkem on mul infot, seda lihtsam on otsust teha. Ma ootan lahendusega,
kuni mul on õige info käes.
•  Mil ised on võtme eeldused ja kuidas ma suudan neid kontrollida. Ära tee eeldusi , mida sa ei
suuda kontrol ida. Siuke eeldus on tühi õhk. Iga eelduse põhjal tuleks mõelda, kuidas seda üldse
kontrol ida.
•  Mis võib põhjustada süsteemi ümber disainimise. Panna enda jaoks kõik riskid, mil e puhul peab
terve süsteemi ümber tegema.
Tarkvaraarhitektuuri disainimeks ei ole universaalset, aksepteeritud protsessi. Iga juhtum on erinev,
iga süsteem ja klient on erinevad. Iga protsess tuleb valida või kohandata vastavalt parasjagu
valitsevatele olukordadele.  
Mõned protsessid:
•  ADD – Attribute Driven Design - rekursi vne protsess. Töötati välja Carnegie Mel on Ülikooli
pool. Koosneb kahest osast. Neid kahte osasid rekursiivselt kogu aeg ketratakse.
o  1. osa – taktika .
§  Kontrol i, et nõuded oleks pi savad.
§  Vali süsteemi osa, mida komponentideks lahutada.
§  Identifitseeri arhitektuuri juhtivad nõuded.
§  Vali kontseptsioon, mis täidab juhtivad nõuded.
o  2. osa – dokumenteerimine.
§  Algväärtusta arhitektuuri elemendid ja jaota vastutused.
§   Defineeri elementide li desed.
§  Verifitseeri ja vi mistle nõudeid ning määra nende pealt pi rangud elementidele.
§  Korda samme kõikide süsteemi osade kohta.
o  ADD kasu:
§  Nõuete vahelised kompromissid tulevad varajases staadiumis välja, mis
omakorda aitab valida parima arhitektuuri nõuete katmiseks. Kui sa alustad
väiksematest jupikestest ja suurendad järjest, si s on sul võimalik varakult
probleemi märgata.
•  Won Kim pakutud protsess – Won Kim is Senior Advisor at Samsung Electronics.
Rekursi vne/iterati vne protsess, mis koosneb kaheksast sammust. Alustame väiksest osast
süsteemist ja iterati vselt hakkab uusi ja uusi tükke tulema.
1.   Koosta esialgne paigaldusplaan(deployment plan). See annab ülevaate sel est, kuidas
soovitakse rakendust paigaldada.
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 . Moodul koosneb
komponentidest. Sisuliselt tee sama asja komponentidest.
5.  Vali üks kuni mitu mustrit komponentide vaatele ja defineeri kaetud nõuded. Sama asja
vaadel.
6.  Vali üks kuni mitu mustrit paigutusvaatele ja defineeri kaetud nõuded
7.  Teosta järelkontrol  arhitektuurile
8.  itereeri punkte 1-7.
•  Agiilne arhitektuur – pole jäik protsess, vaid üldine guideline või mõtteviis. Peaks mõtlema, et
arhitektuur ei ole midagi erilist, vaid on mingi osa.  Selle järgi arhitektuur ei ole mitte midagi
erilist, seda võib muuta. Igal süsteemil on arhitektuur. Agiilse arhitektuuri järgi öeldakse, et
arhitektuur skaleerub ja arhitektuur evoleerub. Erosioon on arhitektuuri mitteteadlik muutmine
ehk lõhkumine. Lepime sel ega, et arhitektuur peaks olema võimeline ajaga muutma.
Probleemid: Kes vastutab arhitektuuri eest? Kõik on vastutavad. Aga vahel inimesed ei ole
üksteisega nõus. Skaleeruvus suurtes ti mides : kuidas tiim kokku panna, eriti kui nad
geolokaalselt erinevates kohtades. Lahenduseks valitakse üht arhitektuuri vastutajat. See ei
tähenda, et arhitektuur on ühe inimese oma, vaid aitab alamtiime arhitektuurist aru saada.
o  Arhitektuur suures meeskonnas
§  Arhitektuuri juhitud lähenemine
§  Featuuri juhitud lähenemine
§  Avatud lähtekoodi lähenemine
§  Kombinatsioon eelnevatest
o  Arhitektuur ei ole ühe inimese teema. Arhitekt peaks kaasama kõiki töösse, isegi
tel i jat.
o  Arhitektuuri testimine. Küsi endalt:
§  Mil istele eeldustele tugineb arhitektuur
§  Mil iseid nõudeid arhitektuur katab
§  Mis on sel e arhitektuuri võtme riskid – mida rohkem me suudame riske ette
mõelda, seda kergem on neid riske lahendada.
§  Mil iste meetmetega leevendada riske
§  Mil moel on see arhitektuur edasiminek vi mase kandidaadi/baas arhitektuuri
suhtes.
o  Ära kirjuta arhitektuuri paberile, vaid proovi ja ehita. Ära unusta alternatiive(proovi
kohe mõelda, kas alternatiivne lahendus lahendaks probleemi).  Arvesta äri
kitsendustega.  Parim tõestus on kood. Kommunikeeri. Mõtle tulevikule aga ära
pinguta üle. Kõike probleeme pole mõtet ette mõelda. Lenda valguskiirusel :
§  Ole ni  väle kui võimalik – proovi kõike saavutada võimalikult ki resti. Proovige
jõuda võimalikult ruttu millegagi kliendiini.
§  Ä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 AINT GONNA READ IT -  mistahes dokumentatsioon seal on, aga
kui raha on mängus see kipub olema aja raiskamine. Teised ei viitsi seda lugeda.
Mida lühemalt annad infot edasi, seda parem.
Tavaline praktika
Agiilne praktika
Arhitektid tõstetakse või hullem tõstavad end ise
Arhitektidel on alandlikkust tunnistada, et nad ei
kõrgemale pjedestaali astmele
oska vee peal käia
Arhitektid on li ga hõivatud, et “määrida” oma käsi
Arhitektid osalevad akti vselt arendustegevuses.
koodi kirjutamisega
Nad on meeskonna konsutandid.
Arhitektuuri mudelid on piisavalt robustsed, et
Arhitektidel on alandlikkust tunnistada, et nad ei
lahendada ka tulevikus tekkivaid probleeme
oska tulevikku ennustada. Küll aga on nad
enesekindlad selles, et homseid probleeme saab
lahendada homme .
Eesmärk on luua lõplik arhitektuur võimalikult vara
Arhitektuur tekib iterati vselt koos arendusega
Häsit dokumenteeritud mudelid
Valguski rus. Dokumenteeri ni  palju kui on vaja
kommunikatsiooniks
Arhitektuuri mudeleid presenteeritakse vaid
Mudeleid kommunikeeritakse avalikult kõigile
“sobilikele kuulajatele”
osapooltele, ka poolikuid, et saada tagasisidet
Arhitektuurile tehakse enne järelkontroll ja
Arhitektuuri kontrollitakse eksperimentidiga
seejärel läheb arhitektuur arendamisele

Süsteemi  keerukus  
Süsteemimõtlemine on üks vi sidest asjadest mõelda, nagu loovmõtlemine või loogiline arutelu.
Sellisena ei ola ta formaalne teadus. Süsteemist võib mõelda kui süsteemidinaamika pehmest
versioonist. Süsteemidinaamika 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 definitsioon on sisse ehitatud
emergents: uute funktsioonide esilekerkimine. Süsteemimõtlemine on just insenerivaldkondades sobiv
viis probleemidest mõelda.
Arhitektuur süsteemimõtlemise kontekstis. Arhitekruur on süsteemi osade ja nende omavahelise
seoste abstraktne kirjeldus. Ni  lihtne ongi: veel üldisemat määratlust on keeruline leida. Samas on ka
kõik ära öeldud. Ni  võib kirjeldada kõike: organisatsiooni, inimest, tarkvara jne. Kuid lihtsus on petlik:
süsteemis osad võivad ol a organisatsioon, inimene, tarkvara jne. Seosed võivad ol a ni  füüsilised kui
mõju avaldavad. Kirjeldada võib neid kõiki väga mitmel vi sil.
Süsteemil on kolm peamist aspekti: Vorm, funktsioon ja kontseptsioon. Süsteemi definitsioonis on
juttu funktsioonist. Arhitektuuri definitsioonis on juttu vormist. Kuidas ühest teiseni jõuda? Kuidas valida
funktsiooni täitmiseks sobiv vorm? Seda tavaliselt peetaksegi arhitekti tööks. Appi tuleb kontseptsioon.-
hulk mõttemal e süsteemi funktsiooni vormiga sidumiseks. Kuidas me süsteemist mõtleme? Põhjus, miks
Brooksi arvates tarkvara on põhimõtteliselt keeruline. Vorm ja funktsioon on süsteemi omadused,
kontseptsioon mõtteline viiis ühest teise jõudmiseks.  Vorm on see, mis süsteem on. Funktsioon on
see, mida süsteem teeb. Kontseptsioon on see, kuidas neist mõelda. Arhitekti töö seisneb töös vormi,
funktsiooni ja kontseptsiooni kui tervikuga. Süsteemi arhitektuur määrab, kui suurt kasu sa saad. Kui
vahe väärtuse ja kasu vahel on suur, si s ka kasu suur.
Süsteemi keerukust arvutatakse sel e elementide, nende li kide, nende omavaheliste seoste ja seoste
liikide arvu kaudu. Levinud, intuiti vne ja paljude variatsioonidega.
•  Keerukus vs keerulisus. Keerukus kasvab eksponendiliselt sõltuvusest elementide hulgast ja
ajast. Keerulisus on süsteemi omadus näida keeruline.
•  Dünaamiline keerukus ilmneb läbi süsteemi osade omavahelise interaktsiooni ajas. Keerukuse
juhtimine on kõige olulisem ja väga keeruline arhitekti roll.
•  Arhitektuur peab vastu seista keerukuse suurendamisele, kuna arhitektuur ajaga kasvab (kui
seda mitte haldada siis kontrol imatult). Keerukus käitub alati ühel vi sil. Keerukus kasvab
eksponendina. Kuskil on alati võimete pi r.
Keerukus tuleb suuremal määral arhitektuurist. Arhitekti üks olulisi rolle on keerukuse juhtimine.
Arhitektuur on vaadeldav rea otsustena. Arhitekt, võttes arvesse kontseptsiooni, sisendprotsesse ja
nende ebamäärasust, projekti kolmnurka (aeg, raha, funktsionaalsus), ja muid teadaolevaid piiranguid
teeb otsusi, mis võimaldavad keerukuse kasvust võimalikult palju kasu saada. Keerukuse juhtimine on
väga oluline arhitekti rol .
Maailma suurim infosüsteem on Brasi lia mingi süsteem.
Universaalsed põhimõtted arhitektuuri juures:
•  High cohesion – kui suur süsteem on jaotatud väikesteks koherentseteks tükkideks. Igal tükkil on
üks konkreetne eesmärk. Üks tükk teeb ühe asja ja teeb seda väga hästi.  
•  Low coupling – moodulitel on vähe sõltuvusi, puuduvad ringsõltuvused. On arusaadav, kes mida
kasutab, kes mida teeb ja kuidas asutsus on jaotatud. Räägib süsteemiomavahelistest
sõltuvustest.
•  Loose coupling – komponendid ei näe palju teiste komponenditesse sisse, oluline on li des, mitte
detailid. Sellised rakendused on kerge lugeda, kasutada, muuta ja testida.
High cohesion, low coupling ja loose coupling on universaalsed põhimõtted, kehtivad ni arhitektuuri kui
ka disaini puhul.
Hea arhitektuuri eelised:
•  Rakendust on kerge
o  Lugeda – igal tükil selge eesmärk. Silme ees ainult oluline. Parem ülevaade struktuurist.
o  Kasutada – Kasutatav komponent võib ol a koodina rakenduse sees / teegina rakenduse
küljes / veebiteenuse taga.
o  Muuta – Kõigepealt tuleb koodist aru saada. Muudatuste pi ratud mõju süsteemile.
o  Testid – Võimalik isoleerida ja mock ’ida. Sõltuvuse asemel dummy’d. Kerge eri
situatsioone läbi mängida. Kergem testida äärmiseid juhtumeid.
Mis on arhitektuur? Palju definitsioone ning kõik on õiged. Arhitektuur vs disain – semiootikute
pärismaa.
Clean  code 
Kui koodi eest ei hoolitseta, si s selle koodi kvaliteet hakkab langema ja langev kvaliteet tõmbab alla
produkti  vsust. Iga järgmine lisatav funktsionaalsus muutub üha keerulisemaks, kuna iga kood, mida me
juurde lisame on üha keerulisem. Tuleb pöörata tähelepanu koodile ja tegeleda sellega, et kood oleks
kergelt loetav.
Clean code – sel e leiutas uncle Bob. “You know you are working on clean code when each routine you
read turns out to be pretty much what you expected.” The boy scout rule - Leave the campground
cleaner than you found it. Kood on puhas si s, kui sa loed ja kõik tundub loogiline ja järjest tuleb see,
mida sa ootanud oled.
Kent Beck on UNIT testimise autor. Ta on defineerinud ära lihtsa disaini 4 põhimõttet: (tähtsuse
järjekorras)
1.  Passes all tests – testide olemasolu ja nende läbitavus
2.  No duplication – loogilist asja ei ole seal topelt . Ei ole duplitseerimist. Ei ole copy past’i.
3.   Expresses intent – väljendab kavatsust, mis funktsionaalsus peaks tegema kõige paremini.
Paistab välja, miks seda koodi on kirjutatud.
4.  Small – kui me mil egagi peale vaatame ja ei saa öelda, et see on väike, si s on tõenäoliselt disain
ei ole lihtne ja vajab parandamist.
Nimede panemine – kui nimede järgi võib ette pakkuda, mida see süsteeb teeb ja mil eks seda vaja on,
siis nimede panemine on õige.  Tundub, et nimede panemine on triviaalne, aga tegelikult see on väga
oluline asi.
Muutuja nimed peaksid olema INGLISE KEELES. Inglise keel on programmeerimise keel. Kui kogu aeg
kasutada ühte keelt ja nimesid panna õigesti, si s teoreetiliselt kood võiks ol a loetav ni , nagu üks lause.
Kui miksida erinevaid keeli (eesti, inglise) siis tuleb segaputru, mis on üsna loetamatu. Väga suur
tõenäosus sattuda programmeerida kel egagi, kel e emakeeleks pole inglise keel, ja si s inglise keel tuleb
teie suhtlemiskeeleks.
Tuleks kasutada terminoloogiat, mida kasutab antud valdkond . Tuleb valdkonna termineid selgeks saada
ja püüda neid kasutada. Kui programmeerija näeb terminoloogiat, mida kasutatakse valdkonnas, si s
seda on lihtne ka edasi arendada. Nimede panekule tuleks ka natuka aega panustada. Kui muutuja on
funktsiooni sees, siis see pole väga kri tiline. Aga funktsiooni või klassi nimetus on juba olulisem. Mida
nähtavam on see struktuur (klass/funktsioon), seda tähtsam on õige nime panemine. Võib arutada ka
kliendiga, kas tema jaoks oleks sel ine nimi arusaadav ja tema arvates õige. Kui on klassid , si s
kasutatakse nimesõnasid. Si s kui on list/col ection, si s nimi on tavaliselt mitmuses. Map ehk seos kahe
asja vahel mõnikord kasutatakse nt customersByRegistrationCode ehk näitab seose. Kui integer, si s
võiks panna muutuja nimele ühik juurde, si s ei teki hiljem kahetimõistmist.
Tuleks alati kasutata ühte terminit ja tuleks kasutada seda igal pool. Tarkvara ehitamisel vältige sõna
“ Client ” sest seda kasutatakse naguni  teistest kontekstides, parem oleks “Customer”.
Mil ine on hea funktsioon? See on lühike funktsioon. Kui palju läheb funktsioon süvitsi? St treppide arv.
Kui on for loop, mil e sees on if jne, kui on mitu taset treppe, si s on see vihje, et funktsioon on li ga pikk.
Hästi oluline on see, et funktsioon tegeleb ainult ühe asjaga. On hea mõte exception handling panna
eraldi meetodisse ni , et try meetod oleks väga lühike.  
Funktsiooni parameetrite arv: mida neid vähem, seda parem. Kui parametreid on palju, si s järelikult
funktsioon tegeleb väga paljude asjadega, ning see pole si s clean code. Boolean parameetrid on mõni
kord OK, kui see lihtsalt ongi mingi setter meetod.
Õigel funktsioonil ei ole kõrvalmõjusid: kui nt funktsioon kontrol lib objekti, si s ta ei peaks objekti olekut
muutma.
Mida vähem me kommentaare kirjutame, seda parem! Kui on clean code, si s on naguni  arusaadav,
mida tehakse, muutujad ja funktsioonid on hästi nimetatud ja kommentaaridel ei olegi mõtet. Tüüpiliselt
saab lihtsalt meetodit ümber nimetada ja kommentaari eemaldada. Kommentaar võib ka paigast ära
minna. Koodi/muutujate ümbertõstmisel jäävad kommentaarid paika ja ei ole enam arusaadav, mil e
kohta see käis. Kommentaarid ei anna midagi juurde. Kui meetodit enam ei ole vaja, si s kustutage ta
ära. Koodi osa välja kommenteerimine on halb! Seda meetodit võib hiljem versiooni haldusest üles
otsida. Tõde on ainult koodis!
On üksikud situatsioonid, kus me ei pääse kommentaarideta. Näiteks mingid litsensi kommentaarid.
Mõnikord on oluline koodiga kaasa öelda, miks see on tehtud. Kui tehakse workaround, mis ei ole
omaette mõistlik, si s tuleks sinna kommentaari juurde panna. Mõnikord on rõhutamine, mis puudutab
mitmes lõimes kasutamist või kui mingi asi on väga resurssi mahukas, si s see on asi, mida tuleks
kommenteerida.  Javadoc ehk avaliku api kirjeldus, mis töötab kõige paremini si s, kui ta on koodi juures:
moodsad arendusvahendid kontrol ivad ise, kas dokumentatsioonis kirjeldatud vi ted on õiged, kas
parameetrid on õiged jne.
The boyscout rule: “Leave the campground cleaner than you found it”.  Seda põhimõtet peaks järgima
koodi kirjutamisel.
Design Patterns: Common solutions to frequent problems arising in object -oriented design. A
systematized catalog of solutions by skil ed and experienced developers. Simplifies communication
between developers – “we are using the Strategy pattern”.
HTTP protokoll on lahe lahendus. Tuleb sisse request, server vastab. Üldlevinud, kerge kasutada, kerge
testida. HTTP on tekstist baseeruv formaat.
Kui tegeleme väljaspoolt java -t andmete lugemisega, siis tuleks kasutada stream -e. Java sees võib
kasutada reader/writer, neid on lihtsam stringideks keerata.
Veebirakenduste liigid 
Veebirakenduste liigid:
•  Thin-client – vana kooli rakendused, kus server koostab päringule vastuse, vastus on terviklik ja
brauser lihtsalt kuvab selle, pi ratud interakti vsus.  Server koostab HTMLi.
•  Fat-client – server edastab koodi ja andmed, ekraanipilt valmib kliendi poolel, interakti vne,
sageli asendab arvutiprogramme.  Nt Gmail. Vinge kasutajali des. “Web 2.0”.  Siin toimub nt rea
lisamine ilma terve komponendi või lehe uuendamata. Staati line html leht + javascript. Ajax
kaudu andmete lugemine ja kirjutamine. Kontrol er vahendab andmeid (sisuliselt REST li des).
•  Veebiteenused (REST või SOAP li desed) – süsteemide ühendamiseks standartse HTTP abil.
Süsteemi suhtlemise vahendused.  
o  SOAP on lõputu peavalu allikas :D Vanakooli standard, eksisteeris enne  resti. Pärast elu
näitas, et saab lihtsamini ja paremini.
o  REST li des – lihtsustatud kontroller. Ainult töötleb andmeid, ei tegele kasutajali desega.
Eeldab HTTP kasutamist. Eelis: Väga hea vastutuste jagamine, Lihtne testida, Parem
interaktiivsus ja kasutajamugavus.
•  Model-View-Controller – hea vi s veebirakenduse koodi organiseerida. Disainimustrina:
rakenduse kood on jaotatud kolme komponendi vahel . On  väga hästi defineeritud, kes millega
suhtleb.
o  model (andmemudel, äriloogika),
o  view (kasutajali dese genereerimine) – ei tegele äriloogikaga,
o   control  er ( vahendaja maailma ja rakenduse vahel, suhtleb äriloogikaga, otsustab mil ist
view’s näidata).
Tegu on standardiga, kus  ühes kohas töötav asi teises kohas ei tööta.
Veebirakendused javas . Java konteinerid(serverid) : tomcat, jetty, tomee, wildfly.  Moodsad
alternati vid: konteiner (server) lisatakse teegina rakenduse sisse. Käivitatakse otse käsurealt.
Pakendatakse standartse java arhi vina(jar).
Agiilne tarkvaratehnika ja  modelleerimine  
Milleks tarkvaratehnika? Tarkvaratööstuse kri s 1965 – 1985. 1/3 kukkus läbi ja üle poole ületasid
eelarvet. Puudus distsipli n ja süstemaatiline lähenemine tarkvaraarenduse organiseerimisele.
Agi  lsed meetodid, mis järgivad agi lset manifesti: XP, Scrum , Kanban , Lean , Lean Startup .
Agiilne  metodoloogia  
Agiilse metodoloogia manifest:
•  Üksikisikud ja interaktsioonid on olulisemad kui protsessid ja tööristad.
•  Töötav tarkvara on olulisem kui ulatuslik dokumentatsioon.
•  Koostöö kliendiga on olulisem kui kliendiga läbirääkimine lepingu osas.
•  Muutustele reageerimine on olulisem kui plaani järgimine.
Agiilsete meetodite põhimõtted:
•  Jaga ja valitse!
•  Kliendi pidev osalemine tarkvara arenduse protsessis,  mitte ainult algul ja lõppus.
•  Inkrementaalne tarkvara väljastamine, inkrementaalselt anname välja terviklikke tükke, mis
iseseisvalt töötavad.
•  Pigem inimesed kui protsess – rõhku pööratakse arendusti mi oskustele ja nende töö
organiseerimisele.
•  Muutuste haldamine – kogu tarkvaraarenduse protsess on ehitatud sel ele et nõuded võivad
muutuda,
•  Säilitada lihtsust – püüda keerukust süsteemist kõrvaldada, nt. seda teevad mudelid (nende
eesmärgiks on vähendada keerukust). Kuidas vähendada keerukust tarkvaras?
Refaktoreerimine.
Iga agiilse meetodi põhimõtte – Jaga ja Valitse. Jagad tükkideks ja arendad tükkide kaupa. Aga need
peavad olema tervikuid ehk töötama ise.
Meetodid 
Kõige paremat tarkvaratehnika meetodit ei eksisteeri, erinevat tüüpi meetodid erinevat li ki
süsteemidele. Kõige levinumad agi lsed metoodikad – Extreme Programming, Scrum, Kanban. Muud
agi lsed metoodikad: Lean Startup – esikohal on „validated learning“. Lean UX – esikohal on „kasutaja
kogemus“.
Agi lse tarkvaratehnika metodoloogiad: probleemvaldkonna esialgne li gendamine on kri tilise
tähtsusega! Ka analüüs peab toimuma iteratiivselt! Organiseeri tarkvaraarendus eesmärgipõhiselt, kus
kasutuslood kirjeldavad ärieesmärkide realiseerimist. Üldiselt hõlmab üks Scrumi Sprint mitut
ärieesmärki. Kastuslood võib omakorda jaotada ülesanneteks – Taskideks. Kanbanis on oluline Pul -
põhimõte. Kanbanis üldiselt Ärieesmärk = MMF (= Potential y Shippable Product Increment Scrumis).
XP meetod 
Agiilse metoodika üks variant.
eXtreme pProgramming iteratiivne tsükkel –
1.  Vali jagatud värgist mingi osa sel e iteratsiooni ( release ) jaoks
2.  Jaga kasutajalood taskideks
3.  Planeeritakse release
4.  Arendatakse, integreeritakse ja testitatakse tarkvara
5.  Release tarkvara (väljalask)
6.  Hinnatakse süsteem – kogu tüki funktsionaalsuse koostestimine.
7.  Korratakse esimesest punktist kuni tarkvara on valmis.
Iteratsiooni pikkus on 1-2 nädalat. Iteratsiooni planeerimise meetingul on kogu programmeerijate ti m,
kes arutlevad kliendiga kasutajalood mis on valitud sel e iteratsiooni implementeerimiseks. Iga
iteratsioonil näidetakse demo kujul mis seisus on tarkvara. Igal päeval on stand -up meeting scrum-
moodi, aga XP-s klient on ka kohal.
XP põhimõtted:
•  Inkrementaalne planeerimine, nõuded salvestatakse kasutajaloo kaardidel ja määratakse nende
arendamise prioriteedid. User stories hiljem jagatakse taskideks.
•  Iga release toob kaasa minimaalne kasulik hulk funktsionaalsust, mis toob mingit äriväärtust.
Releasid on sagedased.
•  Lihtne disain – nii palju et oleks võimalik nõudeid täita antud releasi piires. Aga üldine
arhitektuur ikkagi alguses valitakse.
•  Test- first development
•  Koodi refaktoreerimine
•  Paarisprogrammeerimine – progejad töötavad paarides, üks on piloot teine jälgib, pärast
vahetatakse.  
•  Koodi kol ekti vne omandus – kõik vastutavad kogu koodi eest.
•  Pidev integreerimine, pidev versioonihaldus.
•  Pidev normaalne tempo ilma üleaja töötamiseta, see toob ainult kvaliteedi langu ning
produkti vsuse al a minemise.
•  Klient on kogu aeg saadaval – kas reaalselt või Skype’ teel. Kõige parem on kui klient saab iga
iteratsiooni juures kohal olla.
XP-s on rõhk koodile, progemise organiseerimisele. Scrumis on rohkem rõhku projekti haldusele,
projekti juhtimisele – mõnes mõttes kõrgema abstraktsiooni taseme metoodika.
Scrum 
Kui XP-s oli rohkem rõhku koodile, koodi organiseerimisele, siis Scrumil on rohkem rõhku sel ele, kuidas
seda kogu asja püsti panna. Jaga ja valitse!
Scrum:
1.  Jaga toote tükkideks, mis on mõistlikud self-contained osad mida saab release’da
iseseisvalt, nii et iga tükk omab äriväärtust.
2.  Jaga ajateljel ära aeg, mis on vaja sel e toote valmistamiseks. Selleks pane ajateljele
tükid. Oluline, et igal tükil on mingi äriväärtus olemas.
3.  Jaga ära organisatsioon tiimideks ( cross - functional team – saavad teha kõike, ni 
arendada kui ka nõudeid analüüsida ja testida)
4.  Optimiseeri äriväärtust – optimaalse ki rusega saada lõplik toote, optimaalne ärilises
mõttes toode osade paigaldamine ajateljel.
5.  Optimiseerida protsess – kuidas töö käib.
Toode omanik (Scrumi rol ) on tel ija, mis tahav mingisugust asju saavutada.
Product Backlog – toote on jaotatud user storiedeks, epicutekst, featuriteks – igaühel on arendamise
prioriteet . Arendus on jaotatud sprinditeks. Sprint ei ole midagu muu kui iteratsioon . Iga sprindi algul on
sprindi planeerimise koosolek ( Spring Planning Meeting). Ti m saab kokku, arutab sprindi, planeerib
sel e, jaotab feature või user story taskideks.
Sprint Backlog – sprint on jaotatud väikesteks ülesandeteks, mis ei ole ainult progemise ülesanded.
Spring kestab 1-4 nädalat.
Scrum Master (boss) jälgib protsessi ja iga 24 tundi pärast toimub igapäevane meeting (Daily Scrum
Meeting), kus osaleb toote omanik ja kus reeglina küsitakse igal inimesel 3 küsimust: Mida tegid eile, Kas
on mingid probleemid, Mil ega nüüd tegeled.
Burndown-up Chart – viis mõõta projekti tegevust, teatud meetrika mis näitab meie tegumiste
effekti vsust. Kui sprint on läbi toimub Sprint Review kus toote omanik annab oma tagasiside ja Sprint
Retrospektiiv – arutakse kuidas sprint läks. Siis minnakse järgmisele iteratsioonile. Kui kõik on valmis
(kliendile antakse toote üle), si s toimub kogu projekti retrospektiiv.
Scrum raamistik : Rol id
•  (Toode omanik - 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 , Adjust features and priority every iteration as needed, Accept or reject work results;
•  ScrumMaster - Represents management to the project, Responsible for enacting Scrum values
and practices, Removes impediments, Ensure that the team is ful y functional and productive,
Enable close cooperation across all roles and functions, Shield the team from external
interferences; Team - Typically 5-9 people, Cross-functional (Programmers, testers, user
experience designers, etc.), Members should be ful -time (May be exceptions e.g., database
administrator), Teams are self-organizing, Ideal y, no titles but rarely a possibility, Membership
should change only between sprints), Ceremonies (Sprindi planeerimine, Sprint review, Sprint
retrospektiiv, Daily scrum meeting), Artifacts (Product backlog, Spring backlog, Burndown
charts).
Kasutuslood (Toode väiksemad tükkid, mis pärast jagatakse Sprindi taskideks). Üldkuju: As a user playing
some role, I must be able to perform some activities [in order to achieve some goal ]. Eesmärk (So that I
can) on kõrgema taseme eesmärk.
Product Backlog – kasutajalugude tabel, kus on järgmised veerud: As a, I want to, So that (I can),
Business Value (prioriteet, äriväärtus), Estimate (hinnang kui palju arenduseks aega läheb). Sprint
Backlog – Kasutajalugu, selle taskid, sprindi päevad (si n on kirjutatud kui palju aega läheb selle taski
realiseerimisele sel päeval). Burndown Chart – sprindi päevade graafik , kus on ülevaade kuidas
muutuvad arvud järgmistes kategooriates: sel päeval tehtud taskid, jäänud jõupingutus tundides,
tegemata taskid, ideaalne burndown joon.
Backlogi granulaarsus: prioriteetsemad osad on detailsema kirjeldusega. Epic – suur kasutajalugu.
Feature – seotud kasutajalugude kogum. Scrum lõppeb kui kõik kasutajalood on täidetud, või raha on
otsa saanud, või aeg on läbi.
Kanban 
Kanban - Pul  Value through the Value Stream.
1. Lükkame väärtust edasi väärtuseahelas (nt. To do, Analysis, Dev, Test, Release, Done ).
2. Igas sammus (v.a. Done) on limiteeritud hulk väärtusi.  
3. Kõik oleks nähtav.
Kanbani ideoloogia. “Lean” – keskendu sel ele, mida klient vajab just praegu. Väldi inimeste või
ressursside ülekoormamist. Väldi ebaühtlast töökoormust. Väldi tegevusi, mis ei lisa väärtust.
Minimal Marketable Feature – Potentionally Shippable Product Increment. Mingi funktsionaalsus, mis
realiseerib osa kliendi nõuetest ning mis on suuteline anda kliendile väärtus iseseisva olemina. Kui kõik
kasutuslood jagada eesmärkide kaupda (so that) – saad vastavad MMF.
Kanbani eelised Scrumi ees:
•  Lihtsus,
•  Puudub suurte Backlogide haldamine,
•  Puudub “time boxing” Sprint Backlogide jaoks,
•  Puuudub arendamise edukuse hindamine ja mõõtmine.
Erinevused:
•  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 Scrum focuses on assignments
of each person (yesterday, today , problems).
•  Scrum estimates and measures progress, while this is optional in Kanban.
Rational  Unified  Process  (RUP) 
Rational Unified Process (RUP). RUP-i 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.
Öeldakse et see on äärmiselt mitteagi lne. Aga tegelikult see on kül altki agi lne. Lihtsalt rõhu asetused
on erinevad. Sõltub ajast. Kõigega tegeltakse enam vähem samal ajal. Nt testimine käib lainetena.
Tehakse erinevates iteratsioonides ni , et erinevatel tarkvaraprotsessi etappidel on erinevad
rõhuasetsused.
Tarkvararakenduste liigid 
Tarkvararakenduste liigid:
•  Kohalikud (stand-alone) rakendused, 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;
•  Model eerimis- ja simulatsioonirakendused;
•  Andmekogumisrakendused (data collection systems), nt. keskkonna kohta andmeid koguvad
süsteemid;
•  Süsteemide süsteemid (systems of systems).
Modelleerimine 
Mudel – mingi hüpoteetiline lihtsustatud keerulise olemi või protsessi kirjeldus. Mudel peab olema
täpselt ni  keeruline kui vaja on, aga mitte keerulisem. Küsimus on sel es, et mil ised maailma aspektid
on olulised ja mida võib ignoreerida. Mudeleid on vaja et soodustada diskussiooni olemasoleva või
loodava süsteemi üle ja dokumenteerida olemasolevat süsteemi. Mudel on detailne süsteemi esitus,
mil est saab (osaliselt) genereerida süsteemi realisatsiooni. Mudelid on vahendid, et soodustada
diskussiooni olemasoleva või loodava süsteemi üle. Mudelid on vahendid dokumenteerimaks
olemasolevat süsteemi. Mudel on detailne süsteemi esitus, mil est saab osaliselt genereerida süsteemi
realisatsiooni.
Tarkvaratehnika vaated:
•  Omaniku vaade
•  Kavandaja vaade
•  Ehitaja vaade
Need vaated on erinevatel abstraktsiooni tasemetel.
Tarkvaraprotsessi etapid:
•  Nõuete esiletoomine ja analüüs
•  Kavandamine e. Disain
o  Arhitektuuriline kavandamine
o  Detailne kavandamine
•  Realiseerimine
•  Testimine
•  Hooldus ja evolutsioon
UML – standrad tarkvara arenduses mudelite kirjeldamiseks. Mudelitel on oma klassifikatsioon
horisontaalsete ja vertikaalsete dimensioonide järgi. Mudeleid on vaja sel eks, et saada lihtsustusi.
Selleks, et üldse rakendusi disainida.
Modelleerimine: Igas etapis ja igas faasis on oma „tehised“ (artifacts): graafilised ja tabulaarsed
mudelid, dokumendid, kood jne.
•  Käitumise analüüs:
o  Mis eesmärke süsteem peaks saavutama?
o  Mil ised rol id on nende eesmärkide saavutamiseks vajalikud?
o  Mida süsteem peaks tegema?
•  Interaktsiooni analüüs :
o  Kuidas süsteem peab suhtlema kasutajaga ja teiste süsteemidega?
•  Struktuuri analüüs :
o  Mis osadest süsteem koosneb ja kuidas need on omavahel seotud?
o  Mil ist tüüpi olemite kohta peaks süsteem informatsiooni esitama ja kuidas need
olemid on omavahel seotud?
•   Interaktsioonide disain :
o  Mil iseid teateid süsteemi osad vahetavad omavahel ja kasutajaga?  
•  Struktuuri disain :
o  Mil ist informatsiooni tuleb süsteemis esitada?
•  Käitumise disain :
o  Kuidas süsteemi olemid käituvad? Olekudiagrammid
Horisontaalses – Vaatepunkti aspekt (Interaktsioonid, Struktuur, Käitumine).
Vertikaalses – Abstraktsiooni tase (Analüüs, Disain, Platvormist sõltuv disain). Ridade kaupa:
Kasutusjuhtude diagrammid , klassidiagrammid, tegevusdiagrammid, Jadadiagrammid, Detailsed
klassidiagrammid, Olekudiagrammid, interaktsioonide spefikastsioonid, objektimudelid, Detailsed
olekudiagrammid.
Versioonihaldus 
Draiverid -
Versioonihaldus. Muudab arenduse paindlikumaks. Hajusad vahendid (Git, Mercurial, TeamWare),
Tsentraliseeritud vahendid (SVN, CVS, Perforce, Microsoft TFS). Harud ( branch ) - luuakse repositooriumi
peaharust eraldi haru. Projektid arendatakse harus ja mergetakse peaharru. Harus arendatakse
eksperimentaalset osa. Ainult pikad projektid harus, lühemad peaharus.
A tag represents a version of a particular branch at a moment in time. Tags are symbolic names for a
given revision. They always point to the same object (usual y: to the same revision); they do not change.
A branch represents a separate thread of development that may run concurrently with other
development efforts on the same code base . Changes to a branch may eventual y be merged back into
another branch to unify them. Branches are symbolic names for line of development. New commits are
created on top of branch. The branch pointer naturally advances, pointing to newer and newer commits.
Build -Deploy 
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.
Vahendid: Shell script / Ant script / Jenkins / Atlassion Bamboo jne .
Toodangusse minek.
•  Väldi käsitööd. Sel ega kaasnevad vead.
•  Kasuta seda tulemust, mis sa continuous integration vahenditega juba valmis tegid.
•  Kui ei saa si s tee selgeks, miks ei saa. Elimineeri need põhjused ja kasuta ikka.
•  Kui si s ka ei saa si s kasuta vähemalt samu build skripte. ... muudmoodi li gub asi
kontrol imatuse suunas.
•  Proovi saavutada olukord, kus versioonihaldusest tulev asi on kompileeruv ja vajadusel
pakenduv kohe, ilma lisakonfigureerimisteta.
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.
Proovi saavutada olukord, kus versioonihaldusest tulev asi on kompileeruv ja vajadusel pakenduv kohe,
ilma lisakonfigureerimiseta.
Virtualiseerimine.
•  Arendus mitmele operatsioonisüsteemile:
o  Arendus,
o  Testimine,
•  Erinevatele operatsioonisüsteemidele kompileerimine (continuous integration).
Töölaua/serveripargi virtualiseerimise vahendid: parallels desktop, VM Ware Workstation, Virtualbox.
Muu 
Cross-functional tiim - Kõik vajalikud rol id on kaetud, Teistest sõltumatu, Fookus koostööl ja tulemusel.
Ideaalne tiimi suurus 5-7 inimest, sh 4 arendajat, 2 kvaliteedispetsialisti, analüütik. Self-organizing tiim -
Meeskond on isemajandav, Ühised eesmärgid, vastutus, otsused.
Lean põhimõtted - Ehita õiget asja, Ehita asi õigesti, Pidev areng.