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.

Esitus

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

Seoses lõputööde uute hindamiskriteeriumitega (kehtivad nii magistritöödele kui ka bakalaureusetöödele; nii informaatikutele kui ka äriinfotehnoloogidele) ning palju rangemaks muutunud hindamisega on eriti oluline, et töös:

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 võiks kirjutada teadusartikli. 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.

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.

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. 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 soovitakse panna mitte rohkem kui 25% töödest. 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 üks vähestest enda käsutuses olevatest viitest.

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.

Ü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).

Metoodika

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õrldemist. 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). See ja see ja see ja see ja see (siin on ka hästi põhjalik tundlikkuse analüüs) on näited lõputöödest, kus on analüütiliste hierarhiate meetodit kasutatud.

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.

Kui töö üheks osaks on mõõtmine, siis peab arvestama järgnevaga.

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 õ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.

Back to homepage