User:Tsildebe: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Tsildebe (talk | contribs)
Tsildebe (talk | contribs)
 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
Esitamise kuupäev: 13. november 2011
Esitamise kuupäev: 13. november 2011


==Essee==
= Essee =
Siia tuleb essee tekst. Minu IT alase uudise põhjal tehtud essee räägib ...
Kui hakkasin essee jaoks teemat valima, ei hakanud silma ühtegi sellist nädala tähtsamat uudist, millest oleks soovinud midagi kirjutada. Kuna ka suurem osa projekte on töö juures sellised, millest kahjuks kirjutada ei saa, otsutasin kirjutada tarkvaraarenduse metoodikatest.
 
Kujutame ette olukorda, kus uksest astub sisse klient, kes soovib saada veebilehte, millel on kontaktvorm lehe külastajate jaoks. Programmeerija ütleb, et see pole üldse keeruline ning et järgmisel nädalal on veebileht valmis. Läheb nädal mööda, kuid ei lehte ega ka töötavat kontaktvormi. Läheb mööda teinegi nädal, kuid ikka veel ei ole kliendil soovitud asja. Põhjustena tuuakse välja erinevad asju - arendaja arvuti oli katki, hiired viisid interneti ära ja seda, mida klient soovis, ei ole üldse võimalik teha. Võib tunududa imelikuna, kuid selline on reaalne elu - õnneks siiski mitte alati, aga kahjuks väga tihti.
 
Vältimaks taolisi olukordi, on tarkade inimeste poolt välja mõeldud ja välja töötatud erinevad metoodikad. Definitsiooni kohaselt on metoodika süstemaatiline viis millegi tegemiseks, antud juhul on tegemist tarkvaraarenduse metoodikatega. Metoodikate puhul on eriti tähtsad omadused detailsus, skoop ja elemendid. Detailsus näitab seda, kui rangelt ja täpselt mingit tegvust kirjeldatakse. Skoop näitab ära, kui suurt ulatust kogu protsessist ja tegevustest antud metoodika katab. Elemendid näitavad kõike seda, mida kirjeldatakse, näiteks rollid ja protsessid.
 
Üldiselt on metoodikaid väga erinevaid ning nad on arenenud täpselt samamoodi nagu on arenenud kogu infotehnoloogia. Kõige tähtsam, mida meeles pidada, on see, et mitte ükski metoodika ei ole sobilik kõikide projektide jaoks ning kõikidel metoodikatel on oma nõrgad ja tugevad küljed. Järgnevalt toon välja kaks väga erinevat metoodikat, mis näitavad selgelt, kui suurel määral võivad metoodikad omavahel erineda - nendeks näitemetoodikateks on välearendus (''agile)'' ja veekose meetod (''waterfall)''.
 
Välearenduse puhul on olulised isikud ja suhtlus tellija ning arendaja vahel, töötav tarkvara, reageerimine muudatusetele. Arenduse puhul ei ole prioriteetne põhjalik dokumentatsioon, mis kirjeldaks ära kõikide kasutajaliideses olevate nuppude asukohad, vaid lihtsalt nõudmine, et kasutajaliideses oleks nupp, millele saaks vajutada. Kuna välearenduse puhul on tähtis olla tellijaga pidevas suhtlemises, siis saab alati üle täpsustada, kuhu mingi nupp täpselt lõpuks paigutada tuleb. Kuna välearenduseses keskendutakse esmajärjekorras töötavale rakendusele ning võimalikult kiirele tarkvara erinevate etappide kliendile toimetamisele, ei ole kliendile antav tarkvara vaheetappidel kindlasti lõplik, vaid seal võib alati ette tulla muudatusi ning üldiselt neid ka ette tuleb. See omakorda toob välja ühe välearendusele omase omaduse, et koodibaasi'' refactoring'' (uuesti kodeerimine) on kiire, lihtne ja odav, kuna tegemist ei ole tarkvaraarenduse lõppversiooniga ning uuesti kodeerimisel ei ole seega vaja teha muudatusi kogu projekti ulatuses.
 
Välearenduse puhul tuleb välja tuua ka see, et kehtivad mõned eelduslikud põhimõtted: arendajad peavad olema kiired, paindlikud, taibukad ja tegema tihedat koostööd tellijatega. Tellijad peavad sellise arendusmeetodi puhul olema pühendunud, taibukad ja valmis väga tihedaks koostööks arendajatega. Väga tähtsaks omaduseks välearenduse puhul on ka see, et kuna välearenduse puhul valmib esmane etapp töötavast rakendusest võimalikult kiiresti, saab ka testimisega alustada suhteliselt arenduse alguses. Miinuseks on välearenduse puhul see, et testimise aluseks olev dokumentatsioon ei ole sageli väga põhjalik ning dokumentatsioon on pidevas muutumises. Antud meetodi plussiks on ka siinkohal see, et vea parandamine on resursilisest seisukohast odav.
 
Veekose meetodi puhul on olulised protsess ja vahendid, põhjalik ning kõikehõlmav dokumentatsioon, plaani järgimine, lepingukohased läbirääkimised. Sellise arenduse puhul on prioriteetne stabiilsus ja kindlus. Kõige tähtsam selle meetodi puhul on väga põhjalik ning kõikehõlmav dokumentatsioon, mis sisaldab endas kõike, mis puudutab arendatavat tarkvara, alates nõudmistest, pikslitega paika pandud nuppude asukohtadest ning mõnikord isegi koodiridade arvust. Veekose meetodi kõige suuremaks plussiks on see, et nõudmised on põhjalikud läbi mõeldud ja paika pandud ning ei muutu. Suurimaks miinuseks on selle meetodi puhul aga see, et igasuguste ettenägematute muudatuste sisseviimine on äärmiselt aja- ja ressursimahukas ning kallis. Veekose meetodi testimise puhul on plussiks asjaolu, et kogu testimist puudutav info on kirja pandud põhjalikku dokumentatsiooni, mille alusel on testplaani ja testjuhtude koostamine väga lihtne. Samas, igasuguse vea parandamine on väga ressursimahukas, kuna testimist ei alustata enne, kui kogu tarkvara on valmis ja see võib omakorda kaasa tuua suuremahulisi muudatusi.
 
Need kaks metoodikat ei ole ainsad, kuid kõiki erinevad metoodikaid kirja pannes saab kokku ikka väga-väga pika nimekirja. Nagu eelnevalt mainitud, siis antud näitemetoodikad on äärmiselt erinevad ja on seetõttu sobilikud ka väga erinevatele arendusprojektidele. Aga kuidas siis valida seda õiget metoodikat? Kahjuks sellele küsimusele ei ole ühest vastust. Väga palju sõltub metoodika valikul sellest, milline on tellija soov või nõudmine ning milline on meeskond, kes hakkab arendusega tegelema. Seetõttu tehakse tihti seda, et kombineeritakse erinevate metoodikate tugevamad küljed ning luuakse konkreetsele projektile või meeskonnale sobilik meetod.
 
Olen ise tegelenud tarkvaraarendusega mõlema metoodika järgi ning olen seega näinud mõlema metoodika plusse ja miinuseid. Kokkuvõttes taandub minu arvates kõik sellele, kuidas kindlustada, et arendusprojekt lõpeks nii tellija kui arendaja jaoks positiivselt. Mina ise eelistan väiksema või väga muutuva skoobiga projektide puhul välearendust, kuna see tagab suurema vabaduse. Suuremate projektide puhul eelistan välearendust segada mõnigade elementidega veekose metoodikast ja mõnigate elementidega ka teistest metoodikatest.


==Õpingukorralduse küsimused==
==Õpingukorralduse küsimused==

Latest revision as of 22:56, 13 November 2011

Erialatutvustuse aine arvestustöö

Autor: Taavi Sildeberg
Esitamise kuupäev: 13. november 2011

Essee

Kui hakkasin essee jaoks teemat valima, ei hakanud silma ühtegi sellist nädala tähtsamat uudist, millest oleks soovinud midagi kirjutada. Kuna ka suurem osa projekte on töö juures sellised, millest kahjuks kirjutada ei saa, otsutasin kirjutada tarkvaraarenduse metoodikatest.

Kujutame ette olukorda, kus uksest astub sisse klient, kes soovib saada veebilehte, millel on kontaktvorm lehe külastajate jaoks. Programmeerija ütleb, et see pole üldse keeruline ning et järgmisel nädalal on veebileht valmis. Läheb nädal mööda, kuid ei lehte ega ka töötavat kontaktvormi. Läheb mööda teinegi nädal, kuid ikka veel ei ole kliendil soovitud asja. Põhjustena tuuakse välja erinevad asju - arendaja arvuti oli katki, hiired viisid interneti ära ja seda, mida klient soovis, ei ole üldse võimalik teha. Võib tunududa imelikuna, kuid selline on reaalne elu - õnneks siiski mitte alati, aga kahjuks väga tihti.

Vältimaks taolisi olukordi, on tarkade inimeste poolt välja mõeldud ja välja töötatud erinevad metoodikad. Definitsiooni kohaselt on metoodika süstemaatiline viis millegi tegemiseks, antud juhul on tegemist tarkvaraarenduse metoodikatega. Metoodikate puhul on eriti tähtsad omadused detailsus, skoop ja elemendid. Detailsus näitab seda, kui rangelt ja täpselt mingit tegvust kirjeldatakse. Skoop näitab ära, kui suurt ulatust kogu protsessist ja tegevustest antud metoodika katab. Elemendid näitavad kõike seda, mida kirjeldatakse, näiteks rollid ja protsessid.

Üldiselt on metoodikaid väga erinevaid ning nad on arenenud täpselt samamoodi nagu on arenenud kogu infotehnoloogia. Kõige tähtsam, mida meeles pidada, on see, et mitte ükski metoodika ei ole sobilik kõikide projektide jaoks ning kõikidel metoodikatel on oma nõrgad ja tugevad küljed. Järgnevalt toon välja kaks väga erinevat metoodikat, mis näitavad selgelt, kui suurel määral võivad metoodikad omavahel erineda - nendeks näitemetoodikateks on välearendus (agile) ja veekose meetod (waterfall).

Välearenduse puhul on olulised isikud ja suhtlus tellija ning arendaja vahel, töötav tarkvara, reageerimine muudatusetele. Arenduse puhul ei ole prioriteetne põhjalik dokumentatsioon, mis kirjeldaks ära kõikide kasutajaliideses olevate nuppude asukohad, vaid lihtsalt nõudmine, et kasutajaliideses oleks nupp, millele saaks vajutada. Kuna välearenduse puhul on tähtis olla tellijaga pidevas suhtlemises, siis saab alati üle täpsustada, kuhu mingi nupp täpselt lõpuks paigutada tuleb. Kuna välearenduseses keskendutakse esmajärjekorras töötavale rakendusele ning võimalikult kiirele tarkvara erinevate etappide kliendile toimetamisele, ei ole kliendile antav tarkvara vaheetappidel kindlasti lõplik, vaid seal võib alati ette tulla muudatusi ning üldiselt neid ka ette tuleb. See omakorda toob välja ühe välearendusele omase omaduse, et koodibaasi refactoring (uuesti kodeerimine) on kiire, lihtne ja odav, kuna tegemist ei ole tarkvaraarenduse lõppversiooniga ning uuesti kodeerimisel ei ole seega vaja teha muudatusi kogu projekti ulatuses.

Välearenduse puhul tuleb välja tuua ka see, et kehtivad mõned eelduslikud põhimõtted: arendajad peavad olema kiired, paindlikud, taibukad ja tegema tihedat koostööd tellijatega. Tellijad peavad sellise arendusmeetodi puhul olema pühendunud, taibukad ja valmis väga tihedaks koostööks arendajatega. Väga tähtsaks omaduseks välearenduse puhul on ka see, et kuna välearenduse puhul valmib esmane etapp töötavast rakendusest võimalikult kiiresti, saab ka testimisega alustada suhteliselt arenduse alguses. Miinuseks on välearenduse puhul see, et testimise aluseks olev dokumentatsioon ei ole sageli väga põhjalik ning dokumentatsioon on pidevas muutumises. Antud meetodi plussiks on ka siinkohal see, et vea parandamine on resursilisest seisukohast odav.

Veekose meetodi puhul on olulised protsess ja vahendid, põhjalik ning kõikehõlmav dokumentatsioon, plaani järgimine, lepingukohased läbirääkimised. Sellise arenduse puhul on prioriteetne stabiilsus ja kindlus. Kõige tähtsam selle meetodi puhul on väga põhjalik ning kõikehõlmav dokumentatsioon, mis sisaldab endas kõike, mis puudutab arendatavat tarkvara, alates nõudmistest, pikslitega paika pandud nuppude asukohtadest ning mõnikord isegi koodiridade arvust. Veekose meetodi kõige suuremaks plussiks on see, et nõudmised on põhjalikud läbi mõeldud ja paika pandud ning ei muutu. Suurimaks miinuseks on selle meetodi puhul aga see, et igasuguste ettenägematute muudatuste sisseviimine on äärmiselt aja- ja ressursimahukas ning kallis. Veekose meetodi testimise puhul on plussiks asjaolu, et kogu testimist puudutav info on kirja pandud põhjalikku dokumentatsiooni, mille alusel on testplaani ja testjuhtude koostamine väga lihtne. Samas, igasuguse vea parandamine on väga ressursimahukas, kuna testimist ei alustata enne, kui kogu tarkvara on valmis ja see võib omakorda kaasa tuua suuremahulisi muudatusi.

Need kaks metoodikat ei ole ainsad, kuid kõiki erinevad metoodikaid kirja pannes saab kokku ikka väga-väga pika nimekirja. Nagu eelnevalt mainitud, siis antud näitemetoodikad on äärmiselt erinevad ja on seetõttu sobilikud ka väga erinevatele arendusprojektidele. Aga kuidas siis valida seda õiget metoodikat? Kahjuks sellele küsimusele ei ole ühest vastust. Väga palju sõltub metoodika valikul sellest, milline on tellija soov või nõudmine ning milline on meeskond, kes hakkab arendusega tegelema. Seetõttu tehakse tihti seda, et kombineeritakse erinevate metoodikate tugevamad küljed ning luuakse konkreetsele projektile või meeskonnale sobilik meetod.

Olen ise tegelenud tarkvaraarendusega mõlema metoodika järgi ning olen seega näinud mõlema metoodika plusse ja miinuseid. Kokkuvõttes taandub minu arvates kõik sellele, kuidas kindlustada, et arendusprojekt lõpeks nii tellija kui arendaja jaoks positiivselt. Mina ise eelistan väiksema või väga muutuva skoobiga projektide puhul välearendust, kuna see tagab suurema vabaduse. Suuremate projektide puhul eelistan välearendust segada mõnigade elementidega veekose metoodikast ja mõnigate elementidega ka teistest metoodikatest.

Õpingukorralduse küsimused

Küsimus A

Kukkusid eksamil läbi. Kuidas edasi? Kaua on võimalik eksamit teha? Kellega kokkuleppida, et eksamit teha? Kuidas toimub järeleksamile registreerimine? Mis on tähtajad? Palju maksab, kui oled riigieelarvelisel (RE) kohal? Palju maksab, kui oled riigieelarvevälisel (REV) kohal?

Vastus

Kukkusid eksamil läbi. Kuidas edasi?
Tuleb sooritada korduseksam, kusjuures õppejõul on õigus anda täiendavaid ülesandeid, mille täitmine on korduseksamile lubamise eelduseks.
Kaua on võimalik eksamit teha?
Korduseksamit on võimalik sooritada kahe semestri jooksul pärast aine õpetamissemestri lõppul.
Kellega kokkuleppida, et eksamit teha?
Ainet õpetav õppejõuga.
Kuidas toimub järeleksamile registreerimine?
Järeleksamile tuleb registreerida õppeosakonnas.
Mis on tähtajad?
Kordusekasmite tähtajad määrab ainet õpetav õppejõud, kooskõlas õppeosakonnas koostatud soovitusliku ajakavaga. Kordussoorituse tasu tuleb tasuda üleeelmise tööpäeva lõpuks, arvestatuna eksami toimumise päevast.
Palju maksab, kui oled riigieelarvelisel (RE) kohal?
Riigieelarvelisel õppekohal õppijal on korduseksam tasuta.
Palju maksab, kui oled riigieelarvevälisel (REV) kohal?
Kordussoorituse tasu (REV tudeng) – 13 €

Küsimus 2

Juhtusid kaotama uksekaardi. Mis on tegevused ja teatamised? Juhtusid kaotama kapi võtme. Mis on tegevused ja teatamised?

Vastus

Juhtusid kaotama uksekaardi. Mis on tegevused ja teatamised?
Tuleb anda kaardi kaotusest õppeosakond ning tellida asendus kaart.Selleks tuleb tudengil siseneda www.minukool.ee keskkonda, “kaardi tellimine” aknasse ja kliki “telli asenduskaart” . Asenduskaardi tellimisel kaotab automaatselt kehtivuse varasemalt väljastatud kehtiv kaart ja tellimisprotsess on sarnane uue kaardi tellimisega. (vali “tavakaart” või “pangakaart” ning tasu asenduskaardi väljastamise eest vastavalt Eesti Üliõpilasliidu kehtestatud hinnakirjale 6,5 € :).
Juhtusid kaotama kapi võtme? Mis on tegevused ja teatamised?
Teatan õppetehnikule antud juhtumist. Arvatavasti kaotan ka tagatisraha