Jõudsin IT süsteemide arenduse stuudiumiga lõpuni ja kirjutan allpool kõigest lähemalt. Siin on senised postitused õppimise teekonnast, mis järgivad elukestva õppe erinevaid etappe ja väljakutseid: 1. semester, 2. semester, 3. semester, 4. semester, puhkuse periood, 5. semester ja 6. semester).
TalTechi õppurid teavad hästi õppeinfosüsteemi õppetulemuste lehekülge. Seal paikneb õppemooduleid kirjeldav akordion, mis näitab õpingute progressi. Kui mõnest moodulist on punkte puudu, siis on seal kurb punane miinuses arv, mis tähistab puuduvaid ainepunktide. Täitudes muutub ta uhkeks roheliseks linnuks. Iga tudengi unistus on saada kõik linnud kätte.
Käes! Õpingud sooritatud. Järjekordne bakalaureus. Vaataks tagasi – kuidas see IT süsteemide arenduse õppekava läbimine allakirjutanu poolt välja nägi.
- Sooritatud 212 EAP / 180 EAP-st. Tavapärasele õppekavale lisandunud 32 ainepunkti olid peaasjalikult infosüsteemide analüüsi, arhitektuuri ja tootejuhtimisega seotud ained erinevatest magistriõppe õppekavadest.
- Õpitud semestrite arv: 11. Panin kahe aastaga nominaalist üle kasutades lahket võimalust akadeemilisele puhkusele. Kui ühele õppeaastale sattus koroona-periood ja koolitus- ning konsultatsiooniturg oli madalseisus, siis pakkus see võimalust suurema koormusega õppida. Mitu semestrit läks kas patareide laadimiseks või raha teenimiseks. Kui nominaalajaga lõpetamiseks oleks pidanud igal semestril saavutama 30 EAP raames tulemusi, siis minu tegelik EAP-de progress oli semestrite kaupa: 32-24-18-18-3-12-18-0-18-36-15.
- Kaalutud keskmine hinne: 3.59. Enda jaoks olulisemates ainetes süvenesin ja pingutasin kõvasti. Samas oli teisi, milles tegin täiesti teadlikult miinimumi, et lihtsalt baasteadmisi omandada ja tulemus kätte saada.
- Korduseksameid: 4. Kaks korda käisin sooritamas “programmeerimise algkursust” ja “Javat”. Kolmanda korraga sain läbi “Veebirakendused Java baasil”. Enda vintskust pani see õppekava küll harjutama. Tõdemus, et päriselt tuleb veel pingutada, et mingist teemast lõpuni aru saada.
- Sooritamata aineid: 4. Ilmselt FOMO ja enda võimete ülehindamise kombo. Semestri alguses tundsin sageli põnevust ja motivatsiooni aineid võtta. Kui paari kuu pärast kett maha käis, siis päris mitmel puhul kukkusin ainest poole pealt välja. Olulisem hulk teadmisi sai juba kätte ja otsustasin lõpuks, et puhtalt soorituse pärast pole mõtet asja lõpuni teha.
Kas arendajaid vaibkoodimise ajastul vaja on?
Tarkvara arendaja kraad käes? Loovkoodimise / viipkoodimise / vaibkoodimise (vibe coding) ajastu tõustes on tarkvara arendajate roll üldse huvitav. Kui mitte täiesti küsimärgi all, siis vähemalt väga põhjalikult muutumas.
Austraalia arendaja Geoffrey Huntley otsustas ühel hetkel selle alamtüübile Simpsonite multifilmist inspiratsioonina nimeks panna Ralf Wiggumi-nimeline programmeerimistehnika. Kirjutad ette markdown spetsifikatsiooni ja seejärel käivitad bash käsurealt while-tsükli: käivita claude code, täida üks ülesanne, kirjuta selle kohta raport, lülita claude code välja ja alusta otsast peale. Ralf Wiggum on Simpsonitest tuntuks saanud kui heatahtlik ja pisut lihtsameelne tegelane, kes oma asjadega kuigi hästi hakkama ei saa.
Võib-olla olemegi tarkvara arenduses jõudnud etappi, kus võib anda mõne valmis tarkvara näidise koos lähtepromptidega ette kätte, minna oma lastega basseini lõbutsema ja paari tunni pärast tagasi jõudes vaadata üle, kuidas agendid on sellest koopia valmis meisterdanud – justkui Huntley on oma blogipostituses kirjutanud.
LLM abil koodi kirjutamisega on hakatud eksperimenteerima. Tänaseks on Mischa van den Burgi kalkulatsioonide kohaselt toonud see koodi kirjutamise tunnihinna $10.24 peale. Teisisõnu: pelgalt koodi kirjutamine on võrreldaval tasemel McDonaldsi töötaja brutopalgaga.
See ei võta veel arvesse eksperimente, kus tarkvara agendid pannakse mitmetasandiliselt paralleelselt iteratsioone kirjutama ja testima – nagu näiteks see Gemini CLI peal jooksutatav Gas Town multiagentide orkestreerimise süsteem või Claude Code’i peale ehitatud koodikirjutamise agent Auto-Claude, mis võtab ette konkreetsed ülesanded kanban seina pealt, koostab ise ülesannetele konteksti ja klõbistab koodi valmis.
Milleks siis üldse IT süsteemide arendamist õppida?
Robert on sõber, kes alustas IT süsteemide arenduse õpingutega aasta varem ja jõudis üksjagu varem finišisse. Ta muigas peale lõputöö kaitsmist: “Nüüd saab abi küsida kui printer ei tööta.” 🙂 Seda kindlasti ka. Üldjoontes vastaksin – see õppekava õpetab ennekõike arendajana mõtlema.
3 months of developing saved us from 3 hours of thinking
– Andres Käver
Õppejõud Andres Käver ütles oma C# ja hajussüsteemide kursuste alguses, et esimestel nädalatel me veel koodi ei kirjuta, vaid ennekõike mõtleme, et mida me ehitama hakkame. Ta kasutas umbes sellist kelmikat fraasi: “3 months of developing saved us from 3 hours of thinking,” illustreerimaks olukorda, kus arendajate tavapärane reaktsioon on mingid asjad kohe valmis ehitada ja alles mitu kuud hiljem jõuda järeldusele, et seda lahendust just sellisel polnudki vaja. Käver õpetas oma kursustel just tarkvara arhitekti rolli – kuidas esitada endale küsimusi tarkvara funktsionaalsuse ja nõuete kohta enne lahenduse koostama hakkamist.
Samasugune mõttetreener oli Märt Kalmo, kelle 3 kursuse raames nügis ta tudengeid aru saama, et mis programmeerimiskeelte kõhus sünnib. Selle asemel, et lihtsalt erinevaid teeke (library) kasutada oma elu lihtsustamiseks – kas suudame aru saada, et mida mingi komponent rakenduses päriselt teeb.
Didaktiliselt kogu stuudiumi kõige sümpaatsem õppejõud Ago Luberg. Müts maha! Selle mehe võime programmeerimise alused täiesti tumbadele algajatele selgeks teha on ikka imetlusväärne. See viis kuidas ta suudab igal aastal koguda motiveeritud noorte abiõppejõudude kamba ja nende toel mitmesaja tudengi õppimise tempot ja motivatsiooni üleval hoida on medalit ja preemiat väärt. Kui keegi ei saa mitte millestki aru, siis teeb ta teemasse sisenemise turvaliseks. Kui keegi oskab juba väga hästi, siis suudab ta talle lisaülesannetena esitada veel kõvemaid väljakutseid, mis nügib neid ennast veelgi arendama.
Mõtlemisega seotud ainetest tahan tagantjärgi kiita veel “Algoritmid ja andmestruktuurid” ja “Diskreetne matemaatika” aineid. Kuigi oma laadilt olid nad pigem teoreetilised kursused, siis mõlemad neist panid keerulisemate probleemide lahendamisel otsima samm-sammulisi meetodeid tulemusteni jõudmiseks. Aeg-ajalt leian, et mingi teema käsitlemisel võtan mõttes ette tõeväärtustabeli.
Kõige kasulikumad igapäevatöös on omandatud oskused andmebaasidega töötamiseks ja andmete analüüsimiseks. Andmebaaside alused, SQL erikursus ja Python edasijõudnutele andsid väga vajalikud teadmised, et mil viisil andmebaaside päringuid koostada ja optimeerida või kuidas raskekaalu andmeanalüüsi tööd iseenda jaoks lihtsustada. Nende kursuste oskuseid on läinud Helge.app andmete töötlemisel või analüüsimide koostamisel pidevalt tarvis. Samuti – Einari Kivisalu Pythoni kursuste õppejõuna oli soe ja sõbralik.
Jah – need õpingud andsid muidugi ka väga põhjaliku ekskursi programmeerimiskeeltesse. Tunnen ennast täiesti vabalt kui vaja Pythonis, Javascriptis, Typescriptis, PhPs, C#-s või Javas koodi kirjutada. Piisav põhi tekkis ka operatsioonisüsteemide, võrkude ja IT infra teemades. Nende põhjal on lihtsam teha veahaldust kui mingil põhjusel “printer ei prindi” või “veebileht ei kuva”.
Pisut vähem kasu oli mõnest üldainest, näiteks “füüsika mittefüüsikutele” või “kõrgem matemaatika”. Seal oli pisut kordamist võrreldes varaseamaga. Samas – silmaringi laiendamiseks või ajugümnastikaks olid ka need täiesti omal kohal.
Kui veel tagasi vaadata ja peaks iseendalt uuesti küsima – kui peaks uuesti minema ja seda teekonda otsast peale alustama teades seda milleks peab valmis olema, siis kas teeksin seda uuesti. Vastus oleks: “Jah”.
IADB -viimase õppeaasta kokkuvõte
Aga kui keegi soovib lugeda, siis kirjutan pisut pikemalt, et kuidas viimane õppeaasta läks. Peale kohustuslike ainete sooritamist otsustasin viimasel aastal lõputöö kirjutamisega kahasse teha mõned vabaained teistelt õppekavadelt. Sedapuhku infosüsteemide analüüsi ja kavandamise magistrantuurist, niisiis:
- 6EAP Äriinfo modelleerimine (ICM0006) – Alar Krist – kevadsemester
- 6EAP IT arhitektuur (ICM0011) – Alar Krist – kevadsemester
- 9EAP Ettevõtte arhitektuuri eriseminar (ICM0019) – Alar Krist – sügissemester
- 6EAP Lõputöö (IC40LT) – juhendaja: Birgy Lorenz – sügissemester
ICM0006 Äriinfo modelleerimine
Äriinfo modelleerimise õppeaines osalevad infosüsteemide analüüsi ja arendamise magistriprogrammi osalejad 6-7 liikmelistes gruppides. Esimese asjana tuli selgeks õppida erinevad UML tööriistad, et nende abil visualiseerida äriinfo töövahendeid. Et meie grupil oli võimalik teistele teha ka ettekanne olulisematest UMLi koostamisel kasutatavateks vahenditest, siis panen ettekande slaidid ka siia alla.
Kuigi neid tööriistu on palju, siis minu enda lemmikuks on jätkuvalt lihtsalt endise nimega Draw.io, nüüdne https://app.diagrams.net/, mis on lihtsalt kõige väiksema sisenemisbarjääriga tasuta töövahend, millega tiimitöö tegemine on teistest üksjagu hõlpsam.
Teiseks sümpaatseks avastuseks oli Mermaid süntaks, mida olen üha enam hakanud kasutama asjade kirjeldamisel versioonihalduse dokumentatsioonis või Wikides.
Aga õppeaine sisust ka. Semestri vältel valisid kõik grupid ühe temaatilise projekti, millele nad koostavad grupitöö formaadis mitmed äriinfo modelleerimise artefaktid, kasutades selleks erinevaid modelleerimise tööriistu. Alltoodud vahendid pidid kõigepealt valmima grupitöö raames. Niisiis valmis meie ühistööna:
- Ärikirjeldus, mis selgitab kas kogu organisatsiooni või arendatava toote ärilist tegevusvalkonda, eesmärke, ulatust ja olulisemaid funktsioone. Selles kirjeldatakse valdkonna või toote olulisemad subjektid, sündmused ja objektid ja tähistatakse need vastavalt punase, sinise ja rohelise märgisega.
- Ärisõnastik, mis on keskne “tõlkeraamat”, mis defineerib organisatsioonis või tootes kasutatavad terminid, et vältida vääriti mõistmist (nt mida täpselt tähendab “klient” või “aktiivne leping”).
- Ärireeglid, mis kirjeldavad võimalikult konkreetsete ja üheselt mõistetavate lausete või lausenditega, et mida infosüsteem täpselt teeb. Ärireeglitest selgub võimalikult konkreetselt iga infosüsteemi subjekti, sündmuse ja objekti vahelised seosed võimalikult ammendaval kujul. Antud ülesandest oli minu jaoks tagantjärgi väga palju kasu. Kipun arendajatele ülesandeid andes ise olema ebamäärane. Ärireeglite süntaks eeldab, et igast lausest on täiesti üheselt võimalik aru saada, et kes, mida ja mille abil infosüsteemis saavutab.
- Äriinfo mudel kasutab UML visualiseerimiskeelt ja kirjeldab kõik eespool nimetatud ärireeglid visuaalsel moel, et tekiks selge arusaam subjektide, sündmuste ja objektide vaheliste seoste vahel.
- Ontoloogia mudel, mis võtab äri modelleerimiseks aluseks ainult kaks dimensiooni: fakt ja suhe. Selle tulemusena muutub küll UML joonis kordades kirjumaks võrreldes tavapärase äriinfo mudeliga, sest joonisel on suur hulk kaste ja nendevahelisi jooni, mis on tähistatud tegusõnadega (nt. omab, teeb, väljastab, tagastab, jagab, rendib, grupeerib, jne). Ühest küljest muutub mingi süsteemi mudel seeläbi mõistetavamaks tavakasutajale, sest ta ei nõua objektide ja atribuutide peale mõtlemist. Samas – IT analüütiku või tootejuhi sunnib selle mudeli koostamine tegema täiendavat vahesammu kasutaja vajaduste tõlkimiseks tehnoloogiakeelde.
- Relatsiooniline andmemudel (ERD), mis on kõige klassikalisem viis andmebaasi kujutamiseks: millised on andmebaasi olemid, millised on nende olemite atribuudid ja olemite vahelised seosed.
- Dimensionaalne andmemudel, mille abil on võimalik valida infosüsteemi mingi keskne sündmus ja kirjeldada seda ümbritsevad subjektid ja objektid.
- Dokumentmudel, mis kirjeldab infosüsteemi päringute dokumenteerimist tabeli ja JSON formaadi abil.
Oma õppetöö rühmaga ei saanud me kordagi füüsiliselt kokku. Tuleb tõde tunnistada – kuna Teamsi kõnedes polnud kõikidel video sisse lülitatud, siis kui mõni neist mulle tänaval vastu tuleks, siis äkki ei tunneks teda äragi, kuigi kohtumisi toimus meil igal nädalal . 🙂 Aga samas sai töö kenasti tehtud ja jõudsime asjadega kenasti lõpuni.
Selle õppeaine kõige olulisem õppetund oli oma mõttes selguse saamine. Kui iga kord tuli ülejäänud rühmadele teha kokkuvõte oma eelneva nädala töö tulemustest ja vastata nende küsimustele, siis viitas see üsna hästi kätte kohad, kus mingi äriprotsessi või süsteemi kompoonendi kirjeldus oli läinud ülejala, kus terminoloogia ei olnud piisavalt konkreetne või kus enda mõtlemises olid valged laigud.
Teine kasutegur oli visualiseerimisvahendite kasutamise harjutamine virtuaalses koostöös. Lõpuks tuli eksamil demonstreerida, et oskad nii ärikirjeldust kriitiliselt hinnata ja nende põhjal UML jooniseid koostada ka õppejõu poolt ette antud uuele arendusele.
ICM0011 IT arhitektuur
IT arhitektuuri õppeaine lõpuks õnnestus õppejõud Alari Kristilt saada kompliment: “Nii head eksamitööd ei ole ma kunagi näinud”.
Iseenesest on kiitust alati rõõm kuulda. Aga kokkuvõtlik tõdemus – see oli minu jaoks küllaltki lihtne aine. Sain selle raames teha lihtsalt struktureeritud moel paljusid neid asju, mida ma ärikonsultandina nii ehk teisiti pidevalt teen. Üritan mõista mis on äri eesmärk, millistest protsessidest on äri üles ehitatud ja kuidas neid protsesse taas nutikamal moel nii kokku panna, et edaspidi asjad valutumalt käiksid. Lihtsalt lisandväärtuseks oli tehnoloogia dimensioon – mil viisil IT saaks neid ärilisi eesmärke, protsesse ja tegevusi paremini toetada.
Õppeaine märksõnadeks olid: arhitektuuri olemus ja erinevad aspektid, süsteemide integreerimise mustrid, hajutatud süsteemid, komponentarhitektuur, teenustele orienteeritud arhitektuur (SOA), veebiteenused, mikroteenused ja konteiner arhitektuur, pilvarhitektuur.
Selles õppeaines tegime me samamoodi tööd ühistes gruppides nagu ka äriinfo modelleerimise aines ning eksamitöö raames tuli taas õppejõu poolt valitud ette antud juhtumile teha IT arhitektuuri komponentidest kokkuvõte. Jällegi lühiülevaade nendest vahenditest, mis said õppeaine raames läbi käidud:
- UML kasutusmallid – kirjeldamaks, mida erinevad infosüsteemi kasutajad infosüsteemi erinevate osadega teevad.
- Komponentdiagramm, mis visualiseerib infosüsteemi erinevad osad ja nende osade vahelise suhtluse protokollid ja standardid. Evitusdiagrammi eesmärgiks on kirjeldada komponentide paikenemist erinevates füüsilistes ja virtuaalsetes masinates (node). Lisaks füüsilistele serveritele ning tarkvarakomponentidele kujutatakse evitusdiagrammil ka vahevara (middleware).
- Järgnevusdiagramm ja kommunikatsioonidiagramm visualiseerivad kasutaja ja infosüsteemide komponentide omavahelist interaktsiooni. Näiteks, juhul kui kasutaja sisestab midagi veebivormis, siis kuidas eesrakendus suhtleb kontrolleriga, see omakorda tagarakenduse liidesega, see jällegi andmebaasiga ning mil viisil päring teostatakse ja selle tulemus läbi kõikide eeltoodud kihtide taas kasutajale tagastatakse. Kui järgnevusdiagramm visualiseerib seda suhtlust etapiviisiliselt, siis kommunikatsioonidiagrammi puhul antakse ette suhtluse “toru”, ning seejärel illustreeritakse erinevate suhtluskäskude progressi selles kanalis.
Õppeaine formaat taas samasugune. Rühmatööd, enda tulemuste teistele tutvustamine ja teistele kaasa mõtlemine ning lõpus individuaalne eksam, kus pidid oskusi demonstreerima. Kokkuvõttes – õppeaine kõige olulisem väärtus oli harjutada IT süsteemide konsultandi töö visualiseerimise ja mõtestamise poolt.
ICM0019 Ettevõtte arhitektuuri eriseminar
Sügissemestril osalesin ettevõtte arhitektuuri eriseminaris. Koos kahe eelnevaga moodustavad nad Alar Kristi poolt õpetatava ainete “kolmainsuse”, mis on infosüsteemide analüüsi ja kavandamise magistrantide tulevaste oskuste vundamendiks.
Selles õppeaines käisime sissejuhatavalt läbi erinevad ettevõtte arhitektuuri raamistikud. Nendeks olid väiksemate organisatsioonide jaoks mõeldud The Open Group Application Framework (TOGAF 10 EAF), suuremate poolt kasutatav Zachman Framework for Enteprise Architecture ja agiilseid toote- ja arendustiime toetav Scaled Agile Framework (SAFe 6). Meie fookus oli paremini mõista – mil viisil neist organisatsioonide tegevuse süstematiseerimisel võiks olla abi kui üritada neile võimalikult sobivamaid tehnoloogiat valida ja rakenduste arhitektuuri koostada.
Selles aines oli soovitus tööriistana ette võtta Archimate Modeler tarkvara ja selle abil kirjeldada ettevõtte infoarhitektuuri kõige olulisemad elemendid. Seejuures õppisime Archimate modelleerimiskeelt, mis on enda välimuselt küll UML-i sarnane, aga kirjeldab tarkvara arenduse visualiseerimise asemel pigem äri arhitektuuri, rakenduste arhitektuuri ja tehnoloogia arhitektuuri omavaheilisi seoseid.
Mul endal oli Archimate’i kasutamisega raskusi. Tarkvara oli kohmakas ega tundunud piisavalt intuitiivne, mistõttu lõpuks joonistasin kõik aines õpitud asjad taas harjumuspärasel moel https://app.diagrams.net/ abil. Saan aru, et enda valikute tulemusel tuli mul teha küll kolleegidega võrreldes rohkem käsitööd, sest Archimate’i lubadus oli, et kord loodud seosed arhitektuuri komponentide vahel olid taaskasutatavad ja lihtsustasid skeemide täiendamist või uuendamist.
Kuna aga õppeaine sisu oli senistest kõige lähedasem minu senistele ärikonsultandi töö kogemustele, siis erinevate kontseptsioonide läbi jalutamine tuli mul aines lihtsalt. Õppeaines harjutasime läbi:
- Motivatsiooni- ja strateegiamudel, milles tuli visuaalselt vastata küsimusele – kellele, milleks, mida, kuidas, milliste võimekuste ja ressursside abil organisatsioonis tehakse. Sisuliselt on see väga sarnane tasakaalus tulemuskaardi koostamisel joonistatavale strateegia kaardile, kus strateegia omavahelised seosed põhjus-tagajärg struktuuri abil ühendatakse, et mõista – millistest sisenditest on võimalik strateegia võtmes jõuda mingite väljundite ja mõjuni.
- Võimekuste kaart, mis jagas organisatsioonis olulised teadmised ja oskused strateegilisteks, põhitegevuse ja tugitegevuste võimekusteks.
- Äriprotsessi mudel, mis kirjeldab organisatsiooni kõige olulisemad protsessid infosüsteemi vaates erinevate ujumisradade (swimlane) vahel.
- Väärtusvoo diagramm, mille abil võis lahti mõtestada, et millistest komponentidest koosneb organisatsiooni kliendi või infosüsteemi kasutaja jaoks väärtuse loomine. Äri- ja rakenduskihi mudel, mis lisab eeltoodud väärtusvoo diagrammile IT arhitektuuri õppeainest tuttavad kasutuslood, et näidata kuidas infosüsteem ja kasutaja vajadused käsikäes liiguvad.
Õppeaine korraldus ja struktuur taas sarnane kahele eelnevale. Esimeses etapis toimus tegevus rühmatöödes oma töö tulemuste kirjeldamine ja teistele esitlemine. Lõpus järgnes individuaalne eksam.
IC40LT – Lõputöö
IT süsteemide arenduse lõputöös tuleb klassikaliselt näidata, et sa oskad valgelt lehelt alustades arendada toimiva veebirakenduse, mis on vähemalt enda kontekstis unikaalne. Ehk tarvis pole ilmtingimata kasutada mingeid uuenduslikke tehnoloogiaid ega looma uusi teooriaid. Pigem tuleb näidata, et võttes ette mingi konkreetse ülesande, siis oskad selle tehnoloogiliste abivahendite toel lahendada.
Koostasin oma lõputöö teemal: “Veebirakenduse disain ja testimine noorte ja lastevanemate vahelise mõistmise parandamiseks ” ja selle juhendajaks nõustus olema Birgy Lorenz. Aitäh Birgyle, tänu kelle asjalikele ja kiiretele kommentaaridele ning sõbralikule nügimisele jõudsin lõpuni.
Lõputöös otsustasin taas keskenduda teemale, millest oleks vahetut praktilist kasu Helge.app järgmiste arendusplaanide juures. Juba Helgega alustades tegime eksperimente, kus noorte kohta teste täitsid nii noored ise kui ka nende lapsevanemad ning võrdlesime – millised olid lapsevanete ja murdeealiste vahelised tajuerinevused.
Niisiis disainisin ja arendasin rakenduse, kus sai algatada hindamisi murdeealiste ja nende lapsevanemate tajuerinevuste mõõtmiseks. Kaasasin selle rakenduse testimisse grupi kasutajaid ja nende poolt antud tagasiside põhjal koostasin raporti, mille vormistasin lõputööks, mille lühikokkuvõte on all.
Bakalaureusetöö eesmärk on leevendada murdeealiste ja nende vanemate vahelisi kommunikatsiooniprobleeme, arendades koolide tugispetsialistide jaoks välja veebirakenduse “Helge Poll”. Rakendus võimaldab murdeealisel ja lapsevanemal hinnata noore heaolu ning visualiseerib vastuste erisused, aidates kaardistada peresiseseid tajuerinevusi.
Murdeealiste vaimse tervise probleemid on Eestis süvenev väljakutse, milles mängib olulist rolli puudulik omavaheline suhtlus. Olemasolevad digilahendused keskenduvad valdavalt individuaalsele heaolule ega paku tööriistu osapoolte vaatenurkade võrdlemiseks.
Töö raames loodi ja valideeriti disainiteaduse (Design Science Research) metoodikat kasutades veebirakenduse prototüüp, mis võimaldab tugispetsialistil algatada hindamisprotsessi. Rakendus visualiseerib vastuste erisused, luues neutraalse pinnase konstruktiivseks dialoogiks tugispetsialisti vahendusel. Prototüüp on ehitatud kolmekihilise arhitektuuri põhjal ning teostatud kasutades LAMP-pinu (Linux, Apache, MySQL, PHP) ja JavaScripti.
Töö tulemusena valmis funktsionaalne prototüüp, mille testimine kinnitas, et lahendus toetab osapoolte paremat mõistmist ja vähendab tugispetsialistide töömahtu hinnanguliselt 2-4 tundi ühe pere juhtumi kohta. Süsteemi kasutatavust hindasid spetsialistid SUS-skaalal (System Usability Scale) tulemusega 88,325 (“suurepärane”).
Lõputöö rakenduslik väärtus seisneb potentsiaalis muuta perenõustamine struktureeritumaks ning toetada noorte vaimset tervist läbi parema peresisese mõistmise.
Viidatud Allikas: A. Bangor, P. T. Kortum ja J. T. Miller, „An Empirical Evaluation of the System,“ International Journal of Human-Computer Interaction, kd. 24, nr 6, lk. 574-594, 2008.
Lõppsõna
Keda tänan? Pereliikmeid, kellega oldud aeg jäi nädalavahetustel ja õhtuti lühemaks. Kaastudengeid, kellega stuudiumi vältel ühiselt rühmata ja väljakutseid ületada sai. Eriti neid, kes kogunevad krüptilise SSSG (“super secret study group”) täheühendi taha. Sümpaatseid õppejõude.
Olen kuulnud, et aastate vältel on erinevad praegused ja tulevased IADB õppekava tudengid minu lehekülgedele sattunud ja IT süsteemide arenduse õppimise kohta lugenud. Luban, et see siin on IT süsteemide arenduse õppekaval õppimise kohta viimane postitus. Lubasin ühtlasi õppekava juhile Meelis Antoile, et neid postitusi vähemalt esialgu maha ei võta. 🙂
Kui sattusid siia leheküljele ja soovid teada saada, et mis värk on – kuidas IT süsteemide arenduse õppimise stuudiumi kogemus oli, siis lisan ka siia alla uuesti viited varasematele semestritele: 1. semester, 2. semester, 3. semester, 4. semester, akadeemilise puhkuse periood, 5. semester ja 6. semester.
Päisesse genereeritud OpenAI pildi viip: “Kasuta lisatud fotot, et genereerida foto keskealisest mehest, kes kirjutab arvuti taga istudes koodi – ekraanil võiks olla nähtaval veebirakenduse loomine. Ühel pool ekraanil IDE ja teisel pool ekraani tänapäevane dashboard, mis localhost leheküljel on testimiseks avatud.“