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

Esitus

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:

Teemavalik

Minu praeguse hetke arusaamise kohaselt oodatakse healt informaatika bakalaureusetöölt keeruka tarkvara projekteerimist ja kõrgel tasemel realiseerimist. Sobib ka algoritmide täiustamine, täiustatud algoritmide realiseerimine ning tulemuse võrdlemine teiste samasisuliste algoritmidega. Ä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.

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.

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

Ü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 tarkvara - näiteks tasuta veebipõhine tarkvara http://hipre.aalto.fi/ ja veel üks tasuta tarkvara: https://sourceforge.net/projects/priority/. 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 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