Mõned mõtted ja soovitused lõputööde teemavaliku ja teemakäsitluse kohta

Lõputöö all pean silmas bakalaureuse, magistri või diplomitööd - kui ei ole öeldud teisiti.

Need soovitused on universaalsed ja kehtivad bakalaureusetööst doktoritööni ja sealt edasi igasuguse teadustöö korral.

1 Esitus

Suurepärases lõputöös (nii informaatika kui ka äriinfotehnoloogia lõputöö):

Mary Shaw 2003. aastal kirjutatud artiklis Writing Good Software Engineering Research Papers antud soovitused edukate tarkvaraarenduse teadusartiklite kirjutamiseks kehtivad täiel määral ka lõputööde kirjutamisel. Kes soovib kandideerida hindele 5 peab tingimata kõiki neid soovitusi järgima, sest retsensendid ja kaitsmiskomisjon pööravad tähelepanu samadele küsimustele. Hindele 5 kandideeriva töö üks mõtteline kriteerium ongi, et sellest saaks kirjutada avaldamist vääriva teadusartikli kõrgetasemelisele konverentsile või ajakirja. Kõrgetasemelisel konverentsil võetakse vastu alla 25% esitatud töödest. Kaitsmisel saab hinde 5 tüüpiliselt alla 25% töödest. Saada lõputöö eest hinne 5 on nagu kõrgetasemelisele konverentsile sisse saamine - raske, aga seda rahuldust pakkuvam. Kindlasti lugege see artikkel läbi - seal on ka hulgaliselt näiteid, kuid toon siinkohal välja küsimused, millele suurepärane teadusartikkel/lõputöö peab vastama.

  1. Mis on täpselt töö tulemus?
    • Millisele uurimisküsimusele andis töö vastuse?
    • Miks peaks lugejat see tulemus huvitama?
    • Millisele suuremale küsimusele aitab see tulemus vastust leida?
  2. Milles seisneb töö uudsus? *
    • Millised on need uued teadmised, mida lugeja võib kuskil mujal rakendada?
    • Milliste varasemate tööde (enda või teiste oma) õlgadele selle töö tulemused toetuvad? Millele pakutakse paremat alternatiivi?
    • Mille poolest on saadud tulemused erinevad ja paremad võrreldes varasemate tööde tulemustega?
    • Mis on detailselt selle töö uued tulemused?
  3. Miks peaksid lugejad neid tulemusi uskuma?
    • Milliseid standardeid/meetodeid kasutades on tulemusi valideeritud?
    • Millised konkreetsed tõendid näitavad, et tulemused vastavad nende kohta esitatud väidetele?

Sellest tulenevalt tuleb töö esimeses pooles püstitada uurimisküsimus ning uurida põhjalikult antud valdkonnas juba tehtud töid. Töö teises pooles tuleb saadud tulemusi põhjalikult ja usutavalt valideerida. Kokkuvõte/annotatsioonid peaksid iga küsimuse kohta vähemalt ühe lause esitama.

* Tüüpilise bakalaureusetöö kontekstis tähendab uudsus, et projekteeritakse ja/või realiseeritakse mingi infosüsteem või tarkvara või nende osa, mida polnud sellisel kujul olemas, kuid mida kellelgi läheb vaja. Tänapäeval on IT-süsteemide arendamisel juba nii pikk ajalugu, et täiesti tühjale kohale uue tarkvara tegemist tuleb harva ette. Seega leidub suure tõenäosusega turul juba mingit sarnast tarkvara ja lugeja töö tulemuste headuses veenmiseks tuleb töös uut tarkvara kindlasti olemasolevaga võrrelda. Tegelikult tuleb sellised võrreldavad tarkvarad juba enne oma tarkvara loomist üles leida,

Uudsuse taseme täiendavaks tõstmiseks võib näiteks töö ühe osana viia läbi katsetustel põhineva uuringu selle kohta, milline tehniline lahendus oleks uue süsteemi loomiseks kõige parem. Jällegi tuleb eelnevalt otsida erialakirjandust (sh teaduskirjandust) selles mõttes, et kas sellist uuringut on varem tehtud. Otsingu tulemused tuleb töös välja tuua. Kui sarnaseid uuringuid on tehtud, siis tuleb esile tõsta uue uuringu erinevused.

Hea lõputöö peaks demonstreerima, et autor oskab õpitut loovalt kasutada, arvestades konkreetse kasutamise olukorra eripäradega - võimaluste ja piirangutega. See näitab, et asjast on tegelikult aru saadud. See nõuab oluliselt sügavamaid teadmisi ja oskusi kui mõistete teaduslike definitsioonide taasesitamine ning tüüpülesannete lahendamine.

Teoreetilise tausta seletamisel kasutab hea lõputöö oma sõnu, mitte suuremahulisi tsitaate. Selgitused võiksid olla nii läbitöötatud (arusaadavad; piisavalt lihtsad, kuid mitte triviaalsed), et ka valdkonda mitte tundja saab võimaluse tööst aru saada. Selliseid selgitusi oskab anda vaid keegi, kes saab ise asjadest aru. Seega annab teoreetilise tausta lugemine võimaluse ka hinnata, kuidas autor on töö teemast aru saanud. Üheks nõksuks teema enda jaoks paremaks lahtimõtestamiseks on proovida oma töö teemat ja teoreetilist tausta selgitada oma tuttavatele/sõpradele ning teha seda korduvalt.

Siin on infosüsteemi analüüsi ja kavandamise õppekava magistritööde seminari lindistus. Need põhimõtted kehtivad ka äriinfotehnoloogia ja informaatika õppekava magistritööde puhul.

Kui esitate tulemusena mingi tehise, kuid ei valideeri seda või ei tee seda piisavalt, siis ei maksa paremat hinnet kui 3 oodata. Hea valideerimine ei ole sobivuse deklaratsioon, vaid sisaldab tegevusi valminud tulemi tegelikus headuses veendumiseks. Nende tegevuste tulemused võimaldavad valideerimise tulemusi põhjendada. Valideerimise alla kuulub näiteks tehtud töö ja saadud tulemuste võrdlemine teiste sarnaste töödega ja saadud tulemustega (eelistatult on võrdluses ka võimalikult palju teadusartikleid).

Tagasi algusesse

2 Teemavalik

Hea lõputöö jaoks on vaja pingutust väärivat teemat, sobivat struktuuri ja head meetodit töös soovitud tulemusteni jõudmiseks. Seega on teemavalik äärmiselt oluline. Hea teema on:

Minu praeguse hetke arusaamise kohaselt oodatakse healt informaatika bakalaureusetöölt keeruka tarkvara projekteerimist ja kõrgetasemelist realiseerimist. Sobib ka algoritmide täiustamine, täiustatud algoritmide realiseerimine ning tulemuse võrdlemine teiste samasisuliste algoritmidega. Tõstan näidetena esile selle, selle ja selle bakalaureusetöö täiesti uue tarkvara loomise kohta ja selle bakalaureusetöö olemasoleva tarkvara täiendamise kohta. Lisaks tarkvara realiseerimisele on realiseeritud tehniline lahendus ja töö käigus tehtud valikud lõputöö dokumenti hästi ning põhjalikult kirja pandud. Siin on peatükis 5 ja siin on peatükis 2 hästi kirjeldatud rakenduse disaini. Nendest esitusest võib eeskuju võtta.

Äriinfotehnoloogia bakalaureuseõppes võib seda asendada keeruka infosüsteemi projekteerimine koos prototüüpimisega. Parimale hindele (5) kandideerimiseks peab üliõpilasel olema olnud loominguline vabadus nõuete püstitamisel või tehnilise lahenduse leidmisel, mitte ei ole see kõik talle ülesande püstitaja poolt ettekirjutatud. Tõstan esile selle lõputöö kui suurepärase näite infosüsteemi analüüsi ja esmase realiseerimise kohta tehtud bakalaureusetööst. See on väga hästi ja loetavalt kirjutatud ning annab vastused eelpool väljatoodud küsimustele.

Hea magistritöö võiks välja pakkuda mingi IT tehise e artefakti (nt tarkvara, metoodika), mis on selles valdkonnas juba loodud samasisulistest tehistest mingis aspektis parem ja oleks kasulik laiemalt kui ainult üks arendusprojekt. Selle tehise loomise vajadus peab olema teaduskirjanduse alusel põhjendatud ning olemasolevate tehiste puudujäägid, mida uus tehis üritab korvata, peavad olema selgelt välja toodud. Uue tehise headuse hindamiseks tuleks seda praktikas kasutada ning tulemustest raporteerida. Samuti tuleb seda võrrelda olemasolevate samasisuliste tehistega. Siin on sellise töö näide.

Äriinfotehnoloogia lõputööks sobiks ka mingist teemast teaduskirjanduse põhjal süsteemse ülevaate tegemine (literature review). Sellises bakalaureusetöös peaks olema vähemalt 10 teadusartiklit ning need võib valida koostöös juhendajaga. Magistritöös peaks vaadeldavaid teadusartikleid olema vähemalt 30 ning kogu sellise töö tegemiseks, alates kirjanduse leidmisest, tuleb järgida detailset protokolli.

Hindajate silmis võistlevad tööd omavahel. Hinde 5 saavad tööd, mis on teistest üle. Seega sõltub Teie tulemus mingil määral ka teiste samal ajal kaitsjate töö tasemest. Õige on eeldada, et iga aastaga tase tõuseb. Töö, millele pole midagi otseselt ette heita, kuid mis ei tekita hindajates keerukuse, põhjalikkuse, vahendite valiku vms tõttu eriliselt positiivseid emotsioone (vau hüüatust), saab hindeks 4. Hinne 5 on reserveeritud parimatele töödele ja neid hindeid antakse välja pigem vähem kui rohkem - selle saab 0-20% kaitsjatest. Seega parima hinde saamiseks tuleb võtta väljakutset pakkuv ülesanne ja siis sinna igaks juhuks sellele veel tööd juurde panna. Kahjuks pole ka siis parim hinne kindlustatud. Eriti bakalaureusetööde korral, mida ei retsenseerita, sõltub väga palju heast muljest, mida suudate oma töö kohta kaitsmisel jätta. Lahja töö pealt head muljet ei jäta. Kahjuks ei piisa hindeks 5 sellest, et tehtud on hea töö. Kaitsmise tulemuse peab vähemalt osadel komisjoni liikmetel tekkima soov anda just sellele tööle oma maksimaalne õnnistus.

Minu kogemuse kohaselt saab informaatika bakalaureusetööde kaitsmisel aknapõhise andmebaasirakenduse loomise või andmebaaside disainilahenduste võrdlemise eest parimal juhul hinde 4 (väga hea). Andmebaasirakenduste puhul on ilmselt põhjuseks, et nendes on palju korduvat koodi ning lihtsamaid aknapõhiseid rakendusi saab tänapäeval luua ka pool- või isegi täisautomaatselt. Seega andmebaasirakenduste puhul tasuks mõelda, kuidas suurendada nende keerukust. Näited võimalustest:

Animatsioonid lõputöödeks tänapäeval enam ei sobi. Koos animatsioonidega soovitakse näha ka õpetamise metoodikat. Neile, kes pole ise reaalset õppetööd läbi viinud, on selle koostamine liiga keeruline ettevõtmine.

Tallinna Tehnikaülikoolis kehtib reegel, et 1 EAP = 26 tundi tööd. Lõputöö kontekstis on see oluline, sest kaitsmiskomisjon paneb kohe tähele, kui lõputöös on tehtud vähem tööd kui see valem ette näeb ning hindab seetõttu tööd allapoole. Rohkem pole mingi probleem - nagu elus ikka, kes rohkem teeb see rohkem saab. Arvan, et suurepärasele hindele kandideerija peab tegema sellest mahust rohkem tööd.

Siin kirjeldan ma erinevaid andmebaaside valdkonnas lahendamist ootavaid teadus- ja arendusprobleeme. Kindlasti on seal kirjas palju võimalikke probleeme, mille lahendamisse saaksid ka üliõpilased oma lõputöödega oma väikese, kuid väärika, panuse anda.

Tagasi algusesse

3 Ülesandepüstitus

Mõtlen, et ülesandepüstituse/töö sisu läbimõtlemisel oleks kasu üksikult üldisele lähenemisest (induktiivne arutlemine).

See tähendab, et kõigepealt mõtlete kirjutate/probleemidest, mis esinesid mingis konkreetses Teile eelnevalt tuttavas olukorras (konkreetne teenus/komponent/tarkvara/projekt/mudel/metoodika...). Mõtlete/kirjutate sellest, kuidas selles olukorras oleks võinud neid probleeme lahendada. Edasi arutlete, et sarnased probleemid võivad esineda ka teistes olukordades ning seega võiks pakutav lahendus olla üldisem, st kasutatav erinevates olukordades. Näiteks konkreetses ettevõttes oleks mingi teenuse testimiseks vaja suurt hulka erinevate riikide isikunimesid. Selle jaoks ei leidu ühtegi sobivat valmistarkvara, mis täidaks neid ja neid ja neid funktsionaalseid nõuded. Seega tuleks see tarkvara ise luua. Kuna aga isikunimede genereerimise vajadus võib tekkida ka teistes ettevõtetes/projektides, siis võiks ka loodav tarkvara olla üldine, et seda saaks erinevates kohtades kasutada.

Kui liigute arutlusega üldiselt üksikule (deduktiivne arutlemine), siis võib tulemuseks olla, et kirjutate liiga pikalt- ja üldiselt sellest, kuidas mingit probleemide klassi võiks lahendada, kuid milline on täpselt see probleem, mida lõputöös lahendate ja milline on pakutav lahendus jääb lugejale ebaselgeks. Näiteks kirjutate pikalt sellest, kuidas rakenduse andmetega juhitavaks muutmine aitab lihtsustada selle käitumises muudatuste tegemist. Samas sellest, mida ja kuidas soovite konkreetselt andmetega juhitavaks muuta, kirjutate vähe või üldse mitte.

Nii ülesandepüstituse kui lõputöö enda puhul võib tõmmata paralleele relatsioonilisest andmemudelist tuntud "Informatsiooni ühtse esitamise printsiibiga", mis ütleb et "kogu andmebaasis hoitav informatsioon esitatakse vaid ühel viisil – relatsiooni atribuutide väärtustena (mitte peidetud objekti identifikaatoritena vms)".

Samamoodi koostatakse ülesandepüstitus (ja hiljem lõputöö) nii, et kõik selle mõistmiseks vajalik on tekstis ilmutatult kirjas (mitte kommentaarides, autori peas või autori saadetud meilides).

Tagasi algusesse

4 Dokumendi kirjutamisest

Ülesandepüstitus ei lähe lõpliku kirjatöö mõttes raisku. Ülesandepüstituse saate kasutada sissejuhatuse ja kokkuvõtte kirjutamiseks. Ülesandepüstituses kirja pandud kasutatavad materjalid lähevad suure tõenäosusega lõputöös kasutatud materjalideks. Vormistage seetõttu juba ülesandepüstituses kasutatud materjalid korrektsel viisil.

Esimese asjana soovitan kirja panna sisukorra. Kooskõlastage sisukord juhendajaga. Kui sisukord on paigas, siis saab hakata erinevate pealkirjade alla midagi lisama.

Ärge jätke dokumendi kirjutamist viimasele hetkele - proovige iga nädal kirjatööga tegeleda.

Kasutage pidevalt õigekirja kontrolle ja proovige kohe lauseid hästi ja selgelt sõnastada. Kasutage väga pikkade lausete asemel pigem lühemaid lauseid. Kui juhendaja vaatab üle Teie vahetulemusi, siis halb esitus varjutab alati sisu. On kirjutaja valik, kas juhendaja peab keskenduma puuduvatele komadele ja kirjavigadele viitamisele või saab ta oma energia suunata sisuliste soovituste andmisele.

Internetist saab täiesti tasuta eesti keele spelleri ja poolitaja LibreOffice ja OpenOffice.org tarkvarale. Kui kasutate LaTeXit Overleafis, siis seal saab samuti valida õigekirjakontrolli keelt ja valikus on ka eesti keel.

Kirjavead ja väga halb vormistus poolikus dokumendis on nagu tehniline võlg. See segab sisust arusaamist, kuhjub ning selle võla tagasimaksmise (vigade parandamise) viimasele hetkele jätmine võib tähendada, et probleemid jäävad lõpuks ajapuudusel lahendamata.

Kui kirjutate lõputööd Wordis, siis võiks dokumendi panna pilve ja anda juhendajale samuti dokumendi lugemise ja muutmise õigus. "Track changes" funktsionaalsus võimaldab näha õppejõu tehtud parandusi.

Tagasihoidlik lõputöö kirjeldab maailma (sisuliselt on referaat). Parem lõputöö analüüsib saadud tulemusi ja järeldab/soovitab/otsustab selle põhjal midagi. Veel parem lõputöö sünteesib erinevatest allikatest saadud teavet ja enda tulemusi, et luua midagi uut ja võimalik, et maailma muutvat - see on juba doktoritööst oodatav tase. Ärge piirduge töös "kirjeldamisega" ja üritage töö tekstis ka seda sõna vältida.

Tagasi algusesse

5 Metoodika

Selles jaotises kirjutatakse, mida ja kuidas võiks töö tegemise käigus teha.

5.1 Erinevad uurimistöö liigid

Töö sissejuhatuse osas tuleb kirjeldada töö tegemise metoodikat. Kasutatud meetodid valikute tegemiseks ja mõõtmiseks on selle üks osa. Kui töö sisuks on praktiline arendusprojekt, siis tuleb nimetada kasutatavat arendusmetoodikat ning kas sissejuhatuses või töö põhiosas põhjendada selle valikut. Oleks hea, kui ka selline töö üritaks lõpuks saadud õppetunde ja tulemusi üldistada, st kasutada induktsiooni.

Kui töö on osaliselt uurimistöö ning uurimistulemusi rakendatakse uute tehiste loomiseks või protsesside parandamiseks, siis tuleks proovida see töö liigitada ühte järgnevatest klassidest.

Meie kunagise õppejõu Alex Norta ingliskeelne loenguseeria "How to conduct research?" (Kuidas uurida?), kus neid klasse tutvustatakse, on Youtube keskkonnas kolmes osas kättesaadav.

Metoodika alajaotuses võib ka kirjutada sellest, milliseid enda õppekava läbimisel saadud teadmisi Te töö käigus (milliste töö osade juures) rakendate.

Lõputöö tegemisel ja tulemuse vormistamisel peab järgima eetilise teadustöö põhimõtteid. Ka selle tegemist/mitte-tegemist peaks lõputöö metoodika alajaotuses deklareerima.

Äriinfotehnoloogia lõputöö (nii bakalaureusetöö kui magistritöö) puhul tuleb osata selgitada, kuidas antud töö tulemus võimaldaks saada ärilist (käegakatsutavat, rahas mõõdetavat) kasu ning kellele on see töö mõeldud. See ei välista sugugi uurimuslikku lõputööd. Samas just sellist tüüpi lõputöö puhul tuleb sellele küsimusele mõelda. Kui lõputöö teema on konkreetse süsteemi kavandamine või realiseerimine, organisatsioonis X kasutatava metoodika parandamine või selle seal juurutamine, siis on vastus kohe selge, kuid uurimisliku lõputöö puhul vajab see eraldi selgitust. Sellistele küsimustele tuleks vastata juba lõputöö tekstis ning tuleks osata vastata ka kaitsmisel.

5.2 Nõuded

Taani tarkvarateadlase Dines Bjørneri sõnastatud tarkvara triptühhoonia mudel ütleb, et tarkvara kirjutamiseks on vaja nõudeid ning selleks, et esitada nõudeid tuleb nõuete esitajal tunda valdkonda (domeeni), kus tarkvara hakatakse kasutama. Vaid nii on lootust jõuda õige tarkvarani, mis teeb asju õigesti. Tarkvaraarenduse suunitlusega lõputöö dokumendis peavad kõik need kolm aspekti (valdkond, nõuded, tarkvara) olema kajastatud ning tasakaalus selles mõttes, et lugejale jääb loetust terviklik mulje. Näiteks tarkvaraarenduse töö, mis kirjutab ainult koodi ülesehitusest, testimisest ja töökiirusest, pole piisavalt hea. Töös tuleb esitada ka funktsionaalsed- ja mittefunktsionaalsed nõuded tarkvarale ja kirjutada üldisest kontekstist, kus seda tarkvara kasutama hakatakse. See peab olema töö tekstis kirjas enne lähtekoodi puudutavat osa ja selle peale tuleb töö tegemisel mõelda enne, kui hakkate koodi kirjutama. Arendajale võivad nõuded olla ette antud, kuid ta peab ikkagi oskama nendest nõuetest aru saada ja omalt poolt täiendatud nõudeid teistele arusaadavaks teha. Seega pole ka nõuete haldus arendaja jaoks "võõras mure". Mitte kunagi ei jookse mööda külge alla teadmised valdkonna (pangandus, kaubandus, õppetöö, ilmaennustamine, liiklus, ...) kohta, milles tarkvara kasutama hakatakse. Kui tahate teha paremat lõputööd ja olla parem arendaja, siis lugege selle valdkonna kohta iseseisvalt juurde.

Funktsionaalsete nõuete juures on valida, kas esitada need kasutusmalli mudelina (kasutusmallide skeemid + kasutusmallide tekstikirjeldused) või kasutuslugudena. Mittefunktsionaalsed nõuded võib esitada tabelina. Funktsionaalsed nõuded on aluseks väljalaske plaani koostamisele. Siin, siin ja siin on näited lõputöödest, kus sõnastati kõigepealt funktsionaalsed nõuded kasutuslugudena ja selle alusel pandi paika väljalaske plaan, mis töö tulemusena lõpuks täideti.

Kui nõuded on väga täpselt/jäigalt lõputöö tegijale ette antud, siis sõltuvalt õppekavast ei loeta sellist tööd üldse lõputööks sobivaks (informaatika bakalaureuseõpe) või siis tõmbab see hindajate silmis kindlasti töö väärtust kõvasti alla. Parem on sellist tööd üldse mitte välja pakkuma hakata. Kui sellise töö peale siiski minna, siis eelneva kompenseerimiseks peab valdkonna uurimine, tarkvara realisatsioon ja tulemuse valideerimine olema võimalikult täiuslik ja ka arendatav süsteem ise võimalikult suur ja keeruline. Teiste sõnadega, kui ühest aspektis (valdkond, nõuded, tarkvara) on töös vähem kirjutada, siis seda rohkem tuleb kirjutada teistest aspektidest. Kui töö on selline, et nõuded anti kliendi poolt ette ja lõputöö tegija asus nende alusel koodi kirjutama, siis tuleb nõuded töös ikkagi esitada, kuid see olukord tuleb töö tekstis selgelt välja tuua. Kui klient andis ette nõuete täpse teksti, siis tuleks need panna lisadesse. Kui töö tegija pidi nõuete kogumisel ja sõnastamisel ise tööd tegema, siis on need kindlasti väärt, et panna nõuded kirja töö põhiosasse. Töö põhiosas on autori enda tulemused.

5.3 Analüütiliste hierarhiate meetod e Saaty meetod

Töö üheks osaks on ilmselt millegi (arendusmetoodika, arendusvahendi, andmebaasisüsteemi jne) väljavalimine mitme kandidaadi seast, et seda siis oma töö ülesande lahendamiseks tarvitada. Valiku tegemiseks tasuks kaaluda analüütiliste hierarhiate meetodi e Saaty meetodi kasutamist. See võimaldab subjektiivse hinnangu "mulle tundub/minu kõhutunne ütleb, et kandidaat X on kõige parem" asemel saada objektiivsema, arvulise hinnangu selle kohta, milline on kaalutud kandidaatide suhteline headus valitud kriteeriumeid silmas pidades. Tegemist on tuntud meetodiga, mille kohta leidub ka eestikeelne loengukonspekt. Meetod eeldab otsustusmudeli koostamist (moodustada eesmärkide, kriteeriumite ja kandidaatide hierarhia) ning konkreetsete kriteeriumite ja kandidaatide paariviisilist võrdlemist. Meetodi kasutamiseks leidub hulgaliselt tasuta tarkvara nagu näiteks:

Seda meetodit õpetatakse magistrikursuses "Täppismeetodid otsuste vastuvõtmisel", aga paljud seda ainet mitte õppinud üliõpilased (sh bakalaureuseõppest) on selle endale iseseisvalt selgeks teinud ja seda oma töös kasutanud. Koos otsustusmudeli koostamisega ja selle täitmisega tuleb teha ka täidetud mudeli tundlikkuse analüüs - ei tohiks olla nii, et mudelis sisalduvate hinnangute väikene muudatus tingib suure muudatuse tulemuses (mudel soovitab eelistada hoopist teist kandidaati kui enne). Siin on näiteid lõputöödest, kus on kasutatud analüütiliste hierarhiate meetodit.

Kui töö oodatavaks tulemuseks on tarkvara, siis juba enne ülesandepüstituse koostamist on vaja teha taustauuring, kas sellist tarkvara on turul olemas või mitte. Kui on, siis mis on olemasolevate programmide puudujäägid, st mille poolest saaks uus tarkvara olla parem. Selle analüüsi tulemus aitab kindlaks teha nõudmised uuele tarkvarale. Peale tarkvara realiseerimist on vaja seda kindlasti olemasoleva tarkvaraga võrrelda.

Olemasoleva tarkvara ja uue tarkvara võimalikult objektiivseks võrdlemiseks sobib samuti väga hästi Saaty meetod (vt näidet). Eesmärgiks on võrrelda erinevaid tarkvarasid. Kriteeriumid on tarkvaralt oodatavad omadused (nii funktsionaalsused kui ka mittefunktsionaalsed omadused). Üks alternatiiv on autori loodud uus tarkvara ja ülejäänud on turul olemasolevad konkureerivad tarkvarad.

Ei tohi olla nii, et väikene muudatus kaaludes tingib hoopis teistsuguse valiku. Veendumaks, et hinnangud on stabiilsed, tuleb viia läbi tundlikkuse analüüs, mida on hästi põhjalikult tehtud näiteks siin.

5.4 Mustrid

Hea lõputöö vaatab kaugemale konkreetse ülesande lahendamisest ja proovib saadud tulemusi üldistada, et neid saaks kasutada ka teistes olukordades, mis on sarnased (aga mitte täpselt samad), kui olukord mille jaoks ülesanne lahendati. Võiks kaaluda seda, et panna töö käigus kindlaks tehtud probleemide head lahendused mustrite formaadis kirja. Kui töö käigus kasutati mingit lahendust, mis algul tundus hea, kuid hiljem tekitas probleeme, siis selle saab panna kirja antimustrina. Igal mustril on nimi ja need nimed moodustavad sõnavara, mida kasutades saab erinevatele lahendustele viidata. Muster on struktuurse kirjutamise vorm, mis võimaldab probleeme ja nende lahendusi struktureeritult ja võrreldaval viisil kirja panna.

Siin on näiteid lõputöödest, kus on saadud tulemusi mustri formaadis kirja pandud.

5.5 Mõõtmised

Kvantitatiivse uurimistöö korral leiate Te vastuse uurimisküsimustele tehes erinevaid mõõtmiseid, mille tulemuseks on arvud, mille alusel saab midagi otsustada ja järeldada. Mõõtmiste tegemisel tuleb arvestada järgmisega.

5.6 Parem kui varem

Töö alguses tuleb kindlaks teha algolukord. Ühtlasi aitab see vältida jalgratta leiutamist.

Peale tulemuseni jõudmist peate näitama, et Teie töö tulemus on parem kui varem tehtud parim töö (näiteks uus funktsionaalsus, töötab kiiremini, vajab vähem ressursse, parem kasutatavus, kasutatav suurema probleemide hulga puhul).

Kui arendate tarkvara, siis võiks selleks mõõta midagi nii olemasoleva lahenduse puhul kui ka uue lahenduse puhul (A/B testimine). Mõõta võib näiteks tulemuste korrektsust, kasutajate rahulolu või tarkvara abil protsessi täitmise aega. Sobivaima mõõdetava suuruse valimisel tuleb lähtuda probleemidest, mida kasutati uue tarkvara loomise vajaduse põhjendusena.

Kui arendate mingit algoritmi või meetodit, kuid mõõtmised näitavad, et tulemus pole parem kui senine parim lahendus, siis ka see on lõputöö jaoks sobiv tulemus - eeldusel, et kõik eelnev (kirjanduse uuring, lahenduse väljatöötamine, tulemuste mõõtmine) on metoodiliselt korrektselt tehtud. Sellise töö kasutegur on, et tulevikus sama probleemi lahendajad teavad, et see lahendus ei ole parem kui olemasolev parim lahendus ja saavad keskenduda teistsuguse lahenduse otsimisele.

5.6.1 Uus tarkvara

Oletame, et töö sisuks oli uue tarkvara loomine. Loodud tarkvara tuleb nii verifitseerida kui valideerida. Need on kaks ise asja. Verifitseerimine peab näitama, et tegemist on kvaliteetse ja tehniliselt õigesti tehtud tarkvaraga. Verifitseerimise hulka kuuluvad näiteks ühiktestimine (tuleks välja tuua, kui suur osa koodist on ühiktestidega kaetud), loodud andmebaasi skeemist disainivigade otsimine, koodi inspekteerimine, mustrite kasutuse analüüs andmebaasi/rakenduse/kasutajaliidese puhul. Verifitseerimine peab looma kindluse, et tarkvara ja andmebaasi tehakse õigesti ning tehniliselt kõrgel tasemel.

Valideerimine vastab küsimustele, kas loodud on õige e nõuetele vastav tarkvara. Selleks tuleb analüüsida tarkvara vastavust nii funktsionaalsetele kui mittefunktsionaalsetele nõuetele (mis muidugi peavad olema töös eelnevalt välja toodud). Valideerimine peaks näitama, et uus olukord koos uue tarkvara kasutamisega saab olema parem kui eelnev olukord (vana tarkvaraga või ilma tarkvarata). Selleks võib kasutada nii kvalitatiivseid kui ka kvantitatiivseid meetodeid.

Kvalitatiivsete meetodite näited.

Kvantitatiivsete meetodite näited.

5.7 Teaduskirjanduse otsing

Soovitan kasutada Google Scholarit. Huvipakkuva artikli juures saab vaadata selle versioone. Mõne versiooni täistekst võib olla avalikus võrgus, mõne versiooni täistekst võib olla piiratud juurdepääsuga teaduskirjanduse andmebaasis. Ülikooli raamatukogu kaudu on enamikele nendes andmebaasides olevatele täistekstidele juurdepääs. Selleks, et juurdepääs oleks väljaspool ülikooli, tuleb luua eduVPN ühendus.

Teaduskirjanduse otsimisel tasub esmalt otsida kirjanduse ülevaateid huvipakkuval teemal. Kõikides Google otsinguteenustes sh Google Scholar saab kasutada otsinguoperaatoreid, mida nimetatakse siin jaotuses "Web Search".

Järgnev otsing otsib ülevaateartikleid SQLi õpetamise kohta. Otsing vaatab sõnu artikli pealkirjas.

(intitle:teaching OR intitle:pedagogy OR intitle:education OR intitle:classroom OR intitle:"e-learning") AND (intitle:SQL) AND ((intitle:systematic OR intitle:literature) AND (intitle:review OR intitle:overview OR intitle:study))

6 Saadud tulemused

Tehtud kirjatöö jääb aastakümneteks digikokku kõigile lugemiseks. Kõigil Teie tulevastel tööandjatel on võimalik seda eelnevalt lugeda. Täiesti kindlasti ei taha Te teha tööd, mille lugemine aastate pärast piinlikust valmistab. Piinlikel asjaolude on lisaks kalduvus kõige ebasobivamatel hetkedel esile kerkida. Palju ägedam on, kui noor kolleeg näiteks aastate pärast ütleb, et luges ülikoolis õppides Teie kunagist tööd ja see oli väga huvitav ning hästi kirjutatud töö, mis on ka aastaid hiljem õpetlik ja kasulik lugemismaterjal.

Seetõttu pöörake tähelepanu nii töö sisule kui ka vormile. Kirjavead, puudulik viitamine ja kehva vormistus on halvad asjad. Tehke maksimaalne pingutus, et neid vältida. Ja kui tunnete, et ei jaksa/ei viitsi, siis mõelge, kas pärast häbi tunda ja punastada on parem. Kontrollige mitu korda kõiki oma esitatud väiteid. Kui võimalik, siis kasutage automaatseid õigekirja kontrolle. Laske oma tööd töökaaslasel/sugulasel/sõbral lugeda ja arvustada. Arvestage, et juhendaja ei ole Teie töö kaasautor ja Te ei saa eeldada, et tema Teie eest need vead ära parandab.

Hea teadustöö selgitab, kuidas jõuti tulemusteni, et tehtut saaks kontrollida (uuesti läbi teha) ja edasistes teadustöödes kasutada. Kõik vajalikud andmed peaksid olema huvilistele kättesaadavad. Kui Teie töö tulemuseks on lähtekood, aga ka andmebaasi kood, mudelid, kasutajaliidese prototüüp vms ja see pole ettevõtte tellimusel loodud erilahendus, siis võiks need olla avaldatud avalikul GitHubi lehel, millele töös viidatakse. Nii saavad tulevikus näiteks järgmised üliõpilased Teie tehtut edasi arendada. Võrreldes ülikooli pakutavate salvedega on eelis selles, et tulemused jäävad garanteeritult avalikuks ka peale Teie ülikooliõpingute lõppu. Viide lõputööle ja loodud tulemite salvedele on ka midagi, mida saate edaspidi kasutada oma CV-s ja tehtud tööde portfoolios. Siin on viited minu juhendatud lõputööde avalikele tulemustele. Oli veel üks töö (CASE vahendi Enterprise Architect parandatud mudeliteisendus), mis andis väga hea ja kasuliku tulemuse, kuid selle töö tulemust GitHubi ei pandud ja nüüd on keeruline seda tarkvara jagada ja edasi arendada.

Kui töö tulemuseks on töötav tarkvara, siis selle kasutusjuhendi võiks panna lõputöö dokumendi lisadesse ning kindlasti tuleks see panna ka GitHubi lehele. Mis oleks veel parem tunnustus Teie tehtud tööle kui see, et inimesed tehtud tööd tõepoolest kasutama hakkavad ja võibolla tahavad ka edasi arendada. Kui kirjutate töö põhiosas loodud tarkvarast, siis seal tuleks kirjutada tarkvara nõuetest, ülesehituse ja toimimise põhimõtetest (koos diagrammide e skeemide ja lähtekoodi näidetega) ning kasutajaliidese põhimõtetest (koos ekraanipiltide näidetega). Tuleks kirjutada ja põhjendada töö käigus tehtud disainivalikutest. Kui selle asemel esitada loodud tarkvara kasutusjuhend, siis see on ebapiisav ja jätab tööst halva mulje.

Lähtekood peaks olem GitHubis ja mujal, kus kaitsmiskomisjon soovib seda näha. Dokumendi lisadesse panemiseks on rakenduse lähtekoodi liiga palju. Lisades võiks dubleerida andmebaasiobjektide loomise lähtekoodi ja juhul kui loote töö käigus mingeid abiskripte/pisiutiliite, siis ka nende lähtekoodi. Töö dokumendi põhiosas tuleks esitada huvitavamaid/keerukamaid lähtekoodi fragmente ja neid analüüsida/selgitada.

Tagasi algusesse

Back to homepage