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.
Ärge unustage, et bakalaureusetöö ja magistritöö tuleb semestri algul deklareerida nagu oleks tegemist õppeainega. Rohkem infot on SIIN.
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.
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.
Kui töö põhifookus on infosüsteemi või tarkvara või nende osa projekteerimisel ja/või realiseerimise, siis pole töös eraldi alajaotust "uurimisküsimused" vaja. Vastasel juhul peaks selline alajaotus kindlasti olema. Töö esimeses pooles sõnastate küsimused. Töö lõpuosas annate kõikidele eespool kirja pandud küsimustele ilmutatult vastuse.
Bloomi taksonoomia on õppe-kasvatustöö eesmärkide liigitus. Lõputööks sobiva töö minimaalseim tase on saadud teadmiste rakendamine.
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. Ma olen väga nõus ühe kaitsmiskomisjoni liikme ütlusega: "Lõputöö võib olla töö juurest pärit (tarkvaraarenduse) projekt, kuid mitte iga (tarkvaraarenduse) projekt ei ole lõputöö." Kui töölt on saadud ülesanne ja selgepiirilised juhised kuidas see ülesanne täita, siis nende juhiste täitmisest ja tulemuse kirjeldamisest lõputööks ei piisa. Ülesande täitmisel peab täitjal olema vabadusi teha põhjendatud valikuid või siis tuleb leida veel midagi, mida töösse lisada.
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).
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:
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.
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).
Ärge kasutage mina või meie vormi.
Halb:
Parem:
Ü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.
Maailma kirjeldus (sisuliselt referaat) on lõputööks sobimatu. Tagasihoidlik lõputöö piirdub elus kogutud teadmiste ja oskuste rakendamisega mingi ülesande täitmiseks. 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.
1 Sissejuhatus
1.1 Taust ja probleem
1.2 Ülesandepüstitus
1.3 Töö struktuur
2 Metoodika
2.1 Töö protsess
2.2 Kasutatud tööriistad
2.3 Autori roll arendusmeeskonnas (kui olite osa suuremast rühmast)
3 Teoreetiline taust
4 Sarnaste tarkvarade analüüs (kui selliseid leidub; kui ei leidu, siis tuleks siinkohal kirjutada, kuidas neid otsisite ja millele Teie väide tugineb)
5 Arendusele eelnenud olukorra analüüs (kui tarkvara asendas juba olemasolnud tarkvara)
6 Tulemused
7 Tulemuste analüüs
7.1 Võrdlus olemasoleva tarkvaraga
7.2 Kasutajate tagasiside
7.2.1 Küsimustik
7.2.2 Küsitlemise protsess
7.2.3 Tulemused
7.2.4 Tagasiside alusel tehtud täiendused
7.3 Osapooled, kellele on tehtud tööst kasu
8 Tööprotsessi reflektsioon
8.1 Töö tegemisel hästi läinud asjad
8.2 Töö tegemisel halvasti läinud asjad
8.3 Asjad, mida töö uuesti tegemisel tuleks muuta
9 Arendusvaade
10 Kokkuvõte
Kasutatud kirjandus
Tallinna Tehnikaülikooli IT-teaduskonna allikate kasutamise juhendit on uuendatud. Muuhulgas on sinna lisandunud on peatükk generatiivse tehisintellekti kasutamise kohta kirjalikes töödes. Leiate uuendatud juhendi siit: https://taltech.ee/infotehnoloogia-teaduskond/oppekorraldus Dokument 08.
Lisaksin omaltpoolt, et kui generatiivset tehisintellekti kasutati puhtalt sõnastuse parandamiseks, siis minu arvates võiks seda töö tegemisel kasutatud tööriistade jaotises ikkagi mainida koos viidetega konkreetsetele kasutatud vahenditele.
Töö sissejuhatuse osas tuleb kirjeldada ja analüüsida töö tegemise metoodikat. Analüüsimine tähendab antud juhul valikute põhjendamist. Mida sinna kirjutada?
Metoodika komponente kirjeldavad allikad tuleb panna kasutatud materjalide alla ning neile nii ülesandepüstituse kui töö tekstis korrektselt viidata.
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.
Kolb, D. A. (1984). Experiential learning: Experience as the source of learning and development. Englewood Cliffs, NJ: Prentice-Hall.
stiilis, et "lõputöö reflekteerimisel lähtutakse D. Kolbi kogemuslikust õppimisteooriast mille kohaselt konkreetsele kogemusele (töö tegemisele) järgneb reflektsioon, saadud kogemustest õppimine ning tulemuse testimine uutes tingimustes. Käesolevas töös uutes tingimustes testimist ei toimu, kuid tuuakse välja, mida võiksid sarnase töö tegijad sellest tööst õppida.". Töö analüüsi osas peaksid sellest tulenevalt olema jaotised:
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.
Töö üheks osaks on ilmselt millegi (arendusmetoodika, arendusvahendi, andmebaasisüsteemi, kasutatava lahenduse 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 tasuta tarkvara. Tarkvara valimisel vaadake, et seal oleks ka tundlikkuse analüüsi võimalus.
Tarkvara kasutaja arvutis
Veebipõhine tarkvara
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.
Siin on näiteid lõputöödest, kus on saadud tulemusi mustri formaadis kirja pandud.
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.
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.
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.
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.
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.
Lõputöö tulemuseks oleva tehise (eeskätt tarkvara või metoodika) tehnoloogia valmidusastme (technology readiness level) hindamine pakub võimaluse standardiseeritud hinnangu andmiseks ülesandepüstituses planeeritavale tööle ja lõputöös selle tulemusena tehtud tööle. Standardiseeritud skaalal antav hinnang võimaldab kõigil osapooltel võimalikult ühtemoodi aru saada, mis on plaanis või mis on tehtud. Uurimistöö suunaga tööl jääb tase tavaliselt vahemikku 2-5 ja tarkvaraarenduse töös 6-9.
Teadusartiklite lõpus on enamasti alajaotus tehtud töö nõrkuste/puuduste kohta (pealkirjad nagu "Limitations", "Threats to Validity" vms). Hea ja õige oleks selline alajaotus ka oma töösse kirja panna. Seal tuleks välja tuua kõikvõimalikud "kahtlased kohad", mis ei lase töö tulemusena esitatud väiteid tõepähe võtta. Ka kaitsmise mõttes on parem need ise välja tuua, mitte lasta retsensendil/komisjonil neid ise avastada ja siis küsitlusel üllatada/rünnata.
Toon näiteid.
Kõikidel õppekavadel on eelistatud avalik kaitsmine. Erinevatel õppekavadel on kinnise kaitsmisega seoses erinevad poliitikad ja praktikad - seega kui näete ohtu, et kaitsmine kujuneb kinniseks, siis hakake selle kohta varakult uurima. Võimalik, et ettevõte võib juhedajalt / kaitsmiskomisjonilt / retsensendilt nõuda konfidentsiaalsuskokkuleppe sõlmimist - tehke see varakult selgeks ja veenduge, et need inimesed on valmis seda tegema. Kui hakata nende küsimustega tegelema alles siis, kui töö on juba peaaegu valmis, võib tulemuseks olla palju asjatut segadust, muret, tüli ja meelepaha.
Kinnise kaitsmise korral tekib ka küsimus, kas see oli ikka päriselt vajalik või üritatakse selle abil ebakvaliteetset tööd avalikkuse eest peita.
Minu arvates ei peaks olema ükski kaitsmine kinnine, sest tööd peaks alati saama kirjutada sellise nurga alt, et see on üldisem kui ainult ühe ettevõtte vajaduste rahuldamine ning siis pole ka põhjust ettevõtet ja selle saladusi töös mainida. Mulle meeldis ühe kaitsmiskomisjoni juhi kommentaar kinniste kaitsmiste kohta: "kõiki töid peaks saama nii formuleerida, et saladusi sinna kirja ei lähe ja kui tõesti on nii ülisalajane asi, et sellest poole sõnagagi rääkides on maailmalõpp terendamas, siis see ei ole hea lõputöö teema ja selle eest peaks tudeng saama tööl palka ja peaks lõputöö tegema mingil muul teemal."