Mida k6ps esimesel semestril koolis õppis

Nii, esimene semester koolis läbi, aeg teha väike kokkuvõte.

Üldiselt on ikka väga raske koolis käia pere ja töö kõrvalt ja k6psul on tükk tegemist, et enamik võetud koolikohustusi täita ning mitte saada eksmatrikuleeritud akadeemilise edasijõudmatuse tõttu. Samuti tuli hoida ranget reziimi selles osas, et lastele ja abikaasale peab alati aega olema, see on tähtsam kui kool. Seega -- kooliajal ei mingit diivanil lesimist, teleka vaatamist (seda k6ps nagunii ei tee), teatris ja tantsimas käimst, ega sporditegemist (sellest on küll üsna raske loobuda ja Tartu Rattamaratoni tegi k6ps siiski läbi. Regulaarsed treeningud on aga semestri ja sessi ajal tühistatud).

Aga k6ps võttis niisiis esimesel semestril järgmisi aineid, ning õppis neis järgmist uut ja huvitavat:

• Software Economics (Tarkvaraökonoomika)
  
  
  
  • Tarkvara enda "mõõtmise" temaatikaga oli k6ps varem üldiselt kursis. Täiendavat infot sai k6ps küll Function Point Analysis-e teemal, millest tal varem ainult üsna ähmane ettekujutus oli.
  
  
  • Tarkvara-arendusprojekti "mõõtmise" metoodika oli k6psu jaoks rohkem uus. Eriti jäi meelde COCOMO-nimeline meetod, mis püüab tarkvara kirjutamiseks kuluvat aega ja resurssi heuristika baasil ennustada, kui on teada loodava süsteemi Function Point analüüsi tulemus või eeldatav koodiridade arv ning mitmed muud asjaolud. See tundus andvat küllaltki realistlikke tulemusi. Kui ta ainult töötaks ka tänapäeva suurte infosüsteemide areduses, kus rakendus tuleb luua läbi mitmete kooseksisteerivate arhitektuuride, standardite, raamistike ja liideste, ning koodi kirjutamine ei ole üldse põhiline tegevus..
  
  
  
  



• Systems Modeling (Süsteemide modeleerimine)
  
  
  
  • See oli k6psu lemmikaine esimesel semestril :)
  
  
  • Traditsioonilise UML-iga modeleerimise osas ei avastanud k6ps midagi uut.
  
  
  • Suhteliselt huvitav lähenemine oli Story-Driven Modeling (kasutuslugudel põhinev modeleerimine). See käib selliselt, et nõuded pannakse kirja mitte üldistatud ja selgelt piiritletud kasutusjuhtudega (Use Case) vaid spetsiifilisemate ja mitte nii piiritletud kasutuslugudena (User Story). Edasi ei modeleerita nende põhjal mitte kohe abstraktseid kontseptsioone (Concept) ega klasse, vaid konkreetseid objekte ja nende vahelisi seoseid. Selliselt tekib terve hulk objektidiagramme -- iga kasutusloo iga sammu kohta üks -- mis näitavad objekte ja nende vahelisi seoseid igal sammul ning erinevad teineteisest ainult suhteliselt väikeste muudatuste poolest. Nüüd alles hakatakase klasse modeleerima (neid saaks ka juba automaatselt tuletada, kui on piisavalt hea objektimudel). Selline lähenemine tundus k6psu traditsioonilise objektorienteeritud metoodikaga treenitud mõistusele algul harjumatu, aga tegelikult päris huvitav ja arvatavasti teatud laadi süsteemide puhul paremaid tulemusi andev. Kui ainult seda lähenemist toetavaid tööriistu ka oleks..
  
  
  • Petri Net-id (sh. Colored Petri Net-id, millesse k6ps eriti süvenes) -- täiesti uus kontseptsioon k6psu jaoks. Aga teatud liiki süsteemide puhul hea ja mugav modeleerimisvahend. Mis peamine - võimaldab simuleerida küllaltki keerulisi protsesse.
  
  
  • Process Mining oli ka k6psu jaoks uus teema.
  
  
  • Selle aine sooritas k6ps uhkelt hindele "B", ehk "väga hea" :)
  
  
  
  



• Software Quality and Standards (Tarkvara kvaliteet ja standardid)
  
  
  
  • Seda ainet võttis k6ps Tallinna Tehnikaülikoolis.
  
  
  • Siin ei olnud k6psule eriti midagi uut. Küll aga said olemasolevad teadmised põhjalikult korrastatud, meelde tuletatud ning määratletud kindlate standardite ja muude klassifikaatorite alla.
  
  
  • Aine jäi sooritamata, kuna ei k6ps ei suutnud kohustusi tähtaegadeks täita. K6ps loodab järgnevatel semestritel siiski soorituse kirja saada.
  
  
  
  



• Requirements Engineering (Nõuetehaldus)
  
  
  
  • Seda ainet võttis k6ps samuti Tallinna Tehnikaülikoolis.
  
  
  • Siin ei olnud samuti k6psule eriti midagi uut ja olemasolevad teadmised said põhjalikult korratud ja korrastatud.
  
  
  • Aine jäi esialgu napilt sooritamata, kuna k6ps esitas eksamitöö absoluutselt viimasel hetkel või veel mõni hetk peale seda. K6ps loodab aga järgnevatel semestritel selleski aines soorituse kirja saada.
  
  
  
  

Aga miks siis k6ps teeb endale elu nii raskeks ja üritab töö ja pere kõrvalt koolis ka käia? Mitmel põhjusel:

• Esiteks, k6ps on teatud mõttes rahutu hing. Ta ei saa eriti pikalt paigal olla (kuigi mingites asjades on k6ps jälle hämmastavalt järjekindel). Ta uurib ning katsetab igasuguseid uusi ja huvitavaid asju, topib oma nina mitmele poole, teda on lihtne saada millestki erilisest vaimustuma ning midagi erilist ette võtma.


• Teiseks, k6psule tundub, et see tarkvara-arenduse maailm (kus k6ps igapäevaselt toimetab), kisub kohati arenema umbes sinnakanti, kuhu ehituski on arenenud: tehakse võimalikult hea ja põhjalik disain, allhangitakse teostus võimalikult odavalt, rakendatakse standardeid ning järelevalvet. Pole enam eriti nii, et antakse suhteliselt üldiselt määratletud ülesanne meistri kätte, kes sellele käsitsi ilusa ja hea lahenduse valmis nokitseb. Seega ei tee paha õppida "kõrgemaid" distsipliine, mis sisaldavad endas rohkem "inimlikke" oskusi (suhtlemine, abstraktne tunnetus, stiilitaju, empaatia) -- saada ehitajast disaineriks, ärianalüütikuks, konsultandiks või õpetajaks. Või vähemalt järelvalvajaks :) Lõppudelõpuks teeb edusamme ka mudelipõhine arendus (Model-Based Development), kus ideaalis pole üldse "ehitajaid" vaja -- "valmis" süsteem genereeritakse piisavalt heast disainist automaatselt. Ehitajad kipuvad elama hästi ainult buumi ajal.


• Kolmandaks, ega tööd saa õppimise ajal katki jätta -- pere tahab ülalpidamist ja eluasemelaen maksmist.

K6ps on erakordselt tänulik oma pere ning lähedaste inimeste toetusele, mis ainsana teeb sellise koolis käimise võimalikuks.