ICO wiki - User contributions [en]

Nipitiri

2015-06-13T07:11:00Z

Hsirkel:

=Nipitiri=

==Meeskonna liikmed==

*Kristjan Pihus
*Hanno Sirkel
*Rait Ots
*Ago Kütt
*Merje Kungla

==Projekti esimene osa: XML==

== Idee ==
Luua 4-tasemeline XML definitsioon, näidis sellele ning transleerimised HTML ja XML formaati.

== XML ==

=== XML fail ===

<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<tns:autod xmlns:tns="http://www.example.org/autod" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.example.org/autod autod.xsd ">
<tns:auto id="0" mark="Ford" mudel="Sierra">
<tns:mootor>
<tns:kytus>bensiin</tns:kytus>
<tns:kubatuur yhik="ccm">2000</tns:kubatuur>
</tns:mootor>
<tns:kere v2rv="punane"/>
</tns:auto>

<tns:auto id="1" mark="ZAZ" mudel="969">
<tns:mootor>
<tns:kytus>diisel</tns:kytus>
<tns:kubatuur yhik="ccm">2500</tns:kubatuur>
</tns:mootor>
<tns:kere v2rv="roheline"/>
</tns:auto>

<tns:auto id="2" mark="Saab" mudel="9-5">
<tns:mootor>
<tns:kytus>bensiin</tns:kytus>
<tns:kubatuur yhik="ccm">1500</tns:kubatuur>
</tns:mootor>
<tns:kere v2rv="sinine"/>
</tns:auto>

<tns:auto id="3" mark="Volvo" mudel="960">
<tns:mootor>
<tns:kytus>elekter</tns:kytus>
</tns:mootor>
<tns:kere v2rv="sinine"/>
</tns:auto>

<tns:auto id="4" mark="Volvo" mudel="V40">
<tns:mootor>
<tns:kytus>diisel</tns:kytus>
<tns:kubatuur yhik="ccm">2400</tns:kubatuur>
</tns:mootor>
<tns:kere v2rv="must"/>
</tns:auto>

<tns:auto id="5" mark="Volvo" mudel="V70">
<tns:mootor>
<tns:kytus>gaas</tns:kytus>
<tns:kubatuur yhik="ccm">2000</tns:kubatuur>
</tns:mootor>
<tns:kere v2rv="valge"/>
</tns:auto>

</tns:autod>

</source>

=== XSD fail ===

<source lang="xml">

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.org/autod"
xmlns:tns="http://www.example.org/autod"
elementFormDefault="qualified">

<simpleType name="kytusSimpleType">
<restriction base="string">
<enumeration value="bensiin"></enumeration>
<enumeration value="diisel"></enumeration>
<enumeration value="elekter"></enumeration>
</restriction>
</simpleType>

<complexType name="mootorComplexType">
<sequence>
<element name="kytus" type="tns:kytusSimpleType"
maxOccurs="1" minOccurs="0">
</element>
<element name="kubatuur" maxOccurs="1" minOccurs="0">
<complexType>
<simpleContent>
<extension base="int">
<attribute name="yhik" use="required">
<simpleType>
<restriction base="string">
<enumeration value="ccm"/>
<enumeration value="l"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>

<complexType name="autoComplexType">
<sequence>
<element name="mootor" type="tns:mootorComplexType"></element>
<element name="kere" type="tns:kereComplexType"
maxOccurs="1" minOccurs="1">
</element>
</sequence>
<attribute name="id" type="int"></attribute>
<attribute name="mark" type="string"></attribute>
<attribute name="mudel" type="string"></attribute>
</complexType>

<simpleType name="v2rvSimpleType">
<restriction base="string">
<enumeration value="punane"></enumeration>
<enumeration value="roheline"></enumeration>
<enumeration value="sinine"></enumeration>
</restriction>
</simpleType>

<complexType name="kereComplexType">
<attribute name="v2rv" type="tns:v2rvSimpleType"></attribute>
</complexType>

<element name="autod" type="tns:AutodListComplexType"></element>

<complexType name="AutodListComplexType">
<sequence>
<element name="auto" type="tns:autoComplexType" maxOccurs="unbounded" minOccurs="0"></element>
</sequence>
</complexType>
</schema>

</source>

=== XSLT failid ===
==== XML -> HTML ====
<source lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tns="http://www.example.org/autod">

<xsl:output encoding="UTF-8" method="html" />

<xsl:template match="/">
<html>
<body>

<h2>Autode nimekiri</h2>

<table border="1">
<tr><td>Mark</td><td>Mudel</td><td>Värv</td><td>Mootor</td></tr>
<xsl:for-each select="tns:autod/tns:auto">
<tr>
<td><xsl:value-of select="@mark"/></td>
<td><xsl:value-of select="@mudel"/></td>
<td><xsl:value-of select="tns:kere/@v2rv"/></td>
<td><xsl:value-of select="tns:mootor/tns:kytus"/> <xsl:text> </xsl:text> <xsl:value-of select="tns:mootor/tns:kubatuur"/><xsl:value-of select="tns:mootor/tns:kubatuur/@yhik"/></td>
</tr>
<p> </p>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>

</source>

==== XML -> XML ====
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tns="http://www.example.org/autod">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/">
<tns:autod>

<xsl:for-each select="tns:autod/tns:auto">
<xsl:if test="@mark='Volvo'">
<auto>
<mark>
<xsl:value-of select="@mark"/>
</mark>
<mudel>
<xsl:value-of select="@mudel"/>
</mudel>
</auto>
</xsl:if>
</xsl:for-each>
</tns:autod>
</xsl:template>
</xsl:stylesheet>
</source>

==Projekti teine osa: veebiteenus ja klientrakendus==
=Analüüs=

Projekti tulemina luuakse keeleõppe keskkond milles õppijal on võimalik testida ning selle käigus laiendada oma sõnavara õpitavas võõrkeeles.
Veebirakendus realiseeritakse JavaScripti abil (AngularJS raamistikku kasutades) ning veebiteenus MVC Web API tehnoloogial.

Andmemudel koosneb kolmest olemist (sõnad, õppetükkid, skoor), lisaks hoitakse andmebaasis logi kasutaja tehtud tegevuste kohta ning kasutajate autentimisega seotud olemid (Web API Security). Igal olemil on olemas primaarvõti ID näol. Andmemudel on graafiliselt kujutatud joonisel.

Olemite kirjeldused:
Lesson - siia salvestatakse õppetüki nimi
Word - Sõnad ning nende vasted siht- ja lähtekeeles, seotud Lesson olemiga
Score - Rakenduse kasutaja poolt sõna arvamise tulemus, seotud Word olemiga

Andmemudel:

[[File:2015-06-07_18.48.53.jpg]]

Esialgne API kirjeldus:

[https://docs.google.com/document/d/1zXhUYNPzShb_W9bp3sLxvqbRiLp21K0mGMoCGmfep-o/edit Esialgne API kirjeldus]

Kasutaja vaate kirjeldus:

Rakenduse kasutajale kuvatakse sisselogimisvaade.
Peale sisselogimist saab kasutaja valida õppetüki, mille järel rakendus pakub arvamiseks sõna sellest peatükist veel mittäraarvatud sõnade hulgast.
API kontrollib vastuse ning salvestab tulemuse skooritabelisse.
API's on ka päringud kasutaja õppetükkide hetkeseisu kohta. API tagastab õppetüki kohta äraarvatud sõnade arvu ning sõnade koguarvu. Kui see on võrdne, kuvatakse vastavat õppetükki kasutaja vaates rohelisena ning vastava õppetüki valik mitteaktiivsena.

=Klientrakendus=

Klientrakendus on realiseeritud JavaScriptis, lähtekood asub siin:
[https://bitbucket.org/kpihus/werbum]

=Veebiteenus=

Veebiteenus on realiseeritud ASP.NET MVC Web API vahenditega.
Lähtekood asub siin:
[https://loosers.visualstudio.com/]

File:2015-06-07 18.48.53.jpg

2015-06-13T06:54:54Z

Hsirkel: Andmemudel

Andmemudel

2013-01-07T21:57:38Z

Hsirkel:

Talk:CSharp Meeskond Risk2012

2012-12-31T19:39:14Z

Hsirkel: /* Prototüübi retsensioon */

=Prototüübi retsensioon=

Idee lauamängu realiseerimiseks on väga hea - tegu on populaarse mänguga ning sobiva vormistuse korral võiks loota suurt kasutajaskonda. Prototüübi staadiumis mäng toimib, kasutatavuses on samas olulisi puudujääke.

Mängu lõpuni jõudmine kahe mängija puhul ei õnnestunudki, armee suuremaks kasvamine (kümnete) tuhandete ühikuteni oli probleemiks. Viga sai raporteeritud, loodetavasti õnnestub lõppversiooniks parandused sisse viia.

Lauamängu puhul on oluline osa mängust reaalne ründe- ja kaitsetegevus, mis seisneb täringute veeretamises. Risk2012 puhul piirdub see osa lühida kokkuvõttega arvuti poolt loositud tulemustest. Ilmselt võiks siin rakendada mõnda visuaalset effekti vms parema tulemuse saavutamiseks. Kokkuvõte käigust popup'i näol on kohati raskesti loetav ning ehk siingi võiks visualiseerimist rakendada näiteks graafikutena vms.

Ülevaade mängija resurssidest ei ole piisav. Soovitaks lisada kaardile info selle kohta, kui suur armee mingil konkreetsel territooriumil asub. See info on küll kättesaadav ka hetkel, kuid suure kaardi puhul ei ole hästi hoomatav. Samuti ei ole üheselt selge, millised territooriumid piirnevad üksteisega ehk kuhu on võimalik rünnakut suunata. Võiks välja tuua näiteks erineva värvitooniga vastava mängija käigu ajal vms.

Mäng praeguste kaartide korral on liiga pikk. Eriti just testimise eesmärgil on kasulik lisada mõni väiksem kaart, mis võimaldaks mängu dünaamikast aru saamist. Veerandtunnine testimistsükkel on veidi liiga pikk.

Antud mängu näol on tegu eelkõige seltskonnamänguga, ent elektroonilises versioonis peaks kogu mänguseltskond kasutama kordamööda ühte arvutit ning vastasmeeskonna käigu ajal ei ole võimalik oma strateegia planeerimisega tegeleda. Võrgumängu tugi on plaanitud nice-to-have tööde nimekirjas, kuid lähtuvalt antud mängu olemusest soovitaksin pigem sellele kogu mängu üles ehitada. Sobivaks platvormiks desktop-aplikatsiooni asemel oleks pigem mobiilne või sotsiaalmeedia lisa (facebook app).

Kokkuvõttes on prototüüp realiseeritud rahuldaval tasemel, mängu idee on arusaadav ning ülevaade plaanitavast lõppversioonist selge.

*Retsenseeris meeskond Metronaator.

=Analüüsi retsensioon=

==Idee==
Analüüsidokument võiks sisaldada lühikest ülevaadet lauamängust Risk, et seeläbi paremini aru saada ka loodava mängu sisust. Piisaks ka kui oleks ära toodud viide mõnele seda mängu kirjeldavale veebilehele, näiteks [http://en.wikipedia.org/wiki/Risk_(game) http://en.wikipedia.org/wiki/Risk_(game)].

==Funktsionaalsus==
Idee osas kirjeldatu jätab mulje terviklikust mängust, samas ''must have'' funktsionaalsuse realiseerimisel ei saa veel piisavalt ettekujutust, kas valmiva puhul on tegemist reaalselt mängitava mänguga või alles prototüübiga, mis lõplikult realiseeritakse kunagi hiljem.

Selgusetuks jääb ka, kas mäng realiseeritakse ühes arvutis kordamööda mängimiseks või saab olema võimalus mängida mängu üle võrgu mitme vastasega. See viimane versioon on ''nice to have'' osas ehk siis mängu valmiv versioon ei pruugi sisaldada elementi, mis muudaks selle mängu kasutajatele atraktiivseks.

Analüüsidokumendis võiks ära kirjeldada peamised kasutuslood, mis moodi mängu kasutaja suhtleb mänguga - kasutuslood puuduvad. Milliseid operatsioone ta saab teha ja kuidas ta saab aru, et tema kord on parajasti midagi teha. Suhteliselt põhjalikult on kirjeldatud lahingu pidamise reegleid, kuid on ebaselge, kuidas mängija saab tagasiside lahingu ja vägede liikumise toimumise kohta. Lisaks kasutuslugudele peaks analüüsidokumendis olema eraldi välja toodud ka kasutajate rollid.

Analüüs on kohati väga üldsõnaline, samas teises kohas isegi liigagi detailidesse laskuv - funktsionaalne kirjeldus on liiga tehniline ja ei too välja üldist loogikat. Puudub süsteemsus, mis tingib ka selle, et võhikul on väga raske korralikku ülevaadet asjast saada.

==Vormistus==
Vormistus võiks korrektsem olla. Dokumendis esineb rohkelt näpuvigu, mis viitab viimistluse puudumisele. Samuti raskendavad lugemist õigekirja vead. Puuduvad nummerdatud pealkirjad ja leheküljenumbrid. Analüüsis kasutatud mõisted on defineerimata.

Dokumendil on ebaloogiline ülesehitus (nt ''nice to have'' lahendused võiks olla dokumendi lõpus ära kirjeldatud).

==Kokkuvõte==
Idee on hea ja ambitsioonikas, aga dokumendist ei saa päris täit ja selget ülevaadet, kuidas mäng funktsioneerib.

==Küsimused==
#Funktsionaalsuse alt tuleb hetkel välja, et mängija saab ainult kaarti ja akna suurust valida, aga muud tegevused?
#Mängu tegevuste täitmise järjekord ja lahingute pidamise motoorika, millisesse faasi need tegevused kuuluvad? Kes täidab, tegutseb?
#Rohkem kui 2 osapoolt lahingus ründemehhaanika (A -> B, B -> A, C -> B, D -> A). Miks kõigepealt toimub lahing C->B,D->A vahel?

Retsenseeris [[Meeskond Naaskel]]

Talk:CSharp Meeskond Risk2012

2012-12-31T19:30:12Z

Hsirkel: /* Prototüübi retsensioon */

=Prototüübi retsensioon=

Idee lauamängu realiseerimiseks on väga hea - tegu on populaarse mänguga ning sobiva vormistuse korral võiks loota suurt kasutajaskonda. Prototüübi staadiumis mäng toimib, kasutatavuses on samas olulisi puudujääke.

Mängu lõpuni jõudmine kahe mängija puhul ei õnnestunudki, armee suuremaks kasvamine (kümnete) tuhandete ühikuteni oli probleemiks. Viga sai raporteeritud, loodetavasti õnnestub lõppversiooniks parandused sisse viia.

Lauamängu puhul on oluline osa mängust reaalne ründe- ja kaitsetegevus, mis seisneb täringute veeretamises. Risk2012 puhul piirdub see osa lühida kokkuvõttega arvuti poolt loositud tulemustest. Ilmselt võiks siin rakendada mõnda visuaalset effekti vms parema tulemuse saavutamiseks. Kokkuvõte käigust popup'i näol on kohati raskesti loetav ning ehk siingi võiks visualiseerimist rakendada näiteks graafikutena vms.

Ülevaade mängija resurssidest ei ole piisav. Soovitaks lisada kaardile info selle kohta, kui suur armee mingil konkreetsel territooriumil asub. See info on küll kättesaadav ka hetkel, kuid suure kaardi puhul ei ole hästi hoomatav. Samuti ei ole üheselt selge, millised territooriumid piirnevad üksteisega ehk kuhu on võimalik rünnakut suunata. Võiks välja tuua näiteks erineva värvitooniga vastava mängija käigu ajal vms.

Mäng praeguste kaartide korral on liiga pikk. Eriti just testimise eesmärgil on kasulik lisada mõni väiksem kaart, mis võimaldaks mängu dünaamikast aru saamist. Veerandtunnine testimistsükkel on veidi liiga pikk.

Antud mängu näol on tegu eelkõige seltskonnamänguga, ent elektroonilises versioonis peaks kogu mänguseltskond kasutama kordamööda ühte arvutit ning vastasmeeskonna käigu ajal ei ole võimalik oma strateegia planeerimisega tegeleda. Võrgumängu tugi on plaanitud nice-to-have tööde nimekirjas, kuid lähtuvalt antud mängu olemusest soovitaksin pigem sellele kogu mängu üles ehitada. Sobivaks platvormiks desktop-aplikatsiooni asemel oleks pigem mobiilne või sotsiaalmeedia lisa (facebook app).

Kokkuvõttes on prototüüp realiseeritud rahuldaval tasemel, mängu idee on arusaadav ning ülevaade plaanitavast lõppversioonist selge.

*Retsenseeris meeskond Metronaator.*

=Analüüsi retsensioon=

==Idee==
Analüüsidokument võiks sisaldada lühikest ülevaadet lauamängust Risk, et seeläbi paremini aru saada ka loodava mängu sisust. Piisaks ka kui oleks ära toodud viide mõnele seda mängu kirjeldavale veebilehele, näiteks [http://en.wikipedia.org/wiki/Risk_(game) http://en.wikipedia.org/wiki/Risk_(game)].

==Funktsionaalsus==
Idee osas kirjeldatu jätab mulje terviklikust mängust, samas ''must have'' funktsionaalsuse realiseerimisel ei saa veel piisavalt ettekujutust, kas valmiva puhul on tegemist reaalselt mängitava mänguga või alles prototüübiga, mis lõplikult realiseeritakse kunagi hiljem.

Selgusetuks jääb ka, kas mäng realiseeritakse ühes arvutis kordamööda mängimiseks või saab olema võimalus mängida mängu üle võrgu mitme vastasega. See viimane versioon on ''nice to have'' osas ehk siis mängu valmiv versioon ei pruugi sisaldada elementi, mis muudaks selle mängu kasutajatele atraktiivseks.

Analüüsidokumendis võiks ära kirjeldada peamised kasutuslood, mis moodi mängu kasutaja suhtleb mänguga - kasutuslood puuduvad. Milliseid operatsioone ta saab teha ja kuidas ta saab aru, et tema kord on parajasti midagi teha. Suhteliselt põhjalikult on kirjeldatud lahingu pidamise reegleid, kuid on ebaselge, kuidas mängija saab tagasiside lahingu ja vägede liikumise toimumise kohta. Lisaks kasutuslugudele peaks analüüsidokumendis olema eraldi välja toodud ka kasutajate rollid.

Analüüs on kohati väga üldsõnaline, samas teises kohas isegi liigagi detailidesse laskuv - funktsionaalne kirjeldus on liiga tehniline ja ei too välja üldist loogikat. Puudub süsteemsus, mis tingib ka selle, et võhikul on väga raske korralikku ülevaadet asjast saada.

==Vormistus==
Vormistus võiks korrektsem olla. Dokumendis esineb rohkelt näpuvigu, mis viitab viimistluse puudumisele. Samuti raskendavad lugemist õigekirja vead. Puuduvad nummerdatud pealkirjad ja leheküljenumbrid. Analüüsis kasutatud mõisted on defineerimata.

Dokumendil on ebaloogiline ülesehitus (nt ''nice to have'' lahendused võiks olla dokumendi lõpus ära kirjeldatud).

==Kokkuvõte==
Idee on hea ja ambitsioonikas, aga dokumendist ei saa päris täit ja selget ülevaadet, kuidas mäng funktsioneerib.

==Küsimused==
#Funktsionaalsuse alt tuleb hetkel välja, et mängija saab ainult kaarti ja akna suurust valida, aga muud tegevused?
#Mängu tegevuste täitmise järjekord ja lahingute pidamise motoorika, millisesse faasi need tegevused kuuluvad? Kes täidab, tegutseb?
#Rohkem kui 2 osapoolt lahingus ründemehhaanika (A -> B, B -> A, C -> B, D -> A). Miks kõigepealt toimub lahing C->B,D->A vahel?

Retsenseeris [[Meeskond Naaskel]]

Talk:CSharp Meeskond Risk2012

2012-12-31T19:29:37Z

Hsirkel: /* Prototüübi retsensioon */

=Prototüübi retsensioon=

Idee lauamängu realiseerimiseks on väga hea - tegu on populaarse mänguga ning sobiva vormistuse korral võiks loota suurt kasutajaskonda. Prototüübi staadiumis mäng toimib, kasutatavuses on samas olulisi puudujääke.

Mängu lõpuni jõudmine kahe mängija puhul ei õnnestunudki, armee suuremaks kasvamine (kümnete) tuhandete ühikuteni oli probleemiks. Viga sai raporteeritud, loodetavasti õnnestub lõppversiooniks parandused sisse viia.

Lauamängu puhul on oluline osa mängust reaalne ründe- ja kaitsetegevus, mis seisneb täringute veeretamises. Risk2012 puhul piirdub see osa lühida kokkuvõttega arvuti poolt loositud tulemustest. Ilmselt võiks siin rakendada mõnda visuaalset effekti vms parema tulemuse saavutamiseks. Kokkuvõte käigust popup'i näol on kohati raskesti loetav ning ehk siingi võiks visualiseerimist rakendada näiteks graafikutena vms.

Ülevaade mängija resurssidest ei ole piisav. Soovitaks lisada kaardile info selle kohta, kui suur armee mingil konkreetsel territooriumil asub. See info on küll kättesaadav ka hetkel, kuid suure kaardi puhul ei ole hästi hoomatav. Samuti ei ole üheselt selge, millised territooriumid piirnevad üksteisega ehk kuhu on võimalik rünnakut suunata. Võiks välja tuua näiteks erineva värvitooniga vastava mängija käigu ajal vms.

Mäng praeguste kaartide korral on liiga pikk. Eriti just testimise eesmärgil on kasulik lisada mõni väiksem kaart, mis võimaldaks mängu dünaamikast aru saamist. Veerandtunnine testimistsükkel on veidi liiga pikk.

Antud mängu näol on tegu eelkõige seltskonnamänguga, ent elektroonilises versioonis peaks kogu mänguseltskond kasutama kordamööda ühte arvutit ning vastasmeeskonna käigu ajal ei ole võimalik oma strateegia planeerimisega tegeleda. Võrgumängu tugi on plaanitud nice-to-have tööde nimekirjas, kuid lähtuvalt antud mängu olemusest soovitaksin pigem sellele kogu mängu üles ehitada. Sobivaks platvormiks desktop-aplikatsiooni asemel oleks pigem mobiilne või sotsiaalmeedia lisa (facebook app).

Kokkuvõttes on prototüüp realiseeritud rahuldaval tasemel, mängu idee on arusaadav ning ülevaade plaanitavast lõppversioonist selge.

Retsenseeris meeskond Metronaator.

=Analüüsi retsensioon=

==Idee==
Analüüsidokument võiks sisaldada lühikest ülevaadet lauamängust Risk, et seeläbi paremini aru saada ka loodava mängu sisust. Piisaks ka kui oleks ära toodud viide mõnele seda mängu kirjeldavale veebilehele, näiteks [http://en.wikipedia.org/wiki/Risk_(game) http://en.wikipedia.org/wiki/Risk_(game)].

==Funktsionaalsus==
Idee osas kirjeldatu jätab mulje terviklikust mängust, samas ''must have'' funktsionaalsuse realiseerimisel ei saa veel piisavalt ettekujutust, kas valmiva puhul on tegemist reaalselt mängitava mänguga või alles prototüübiga, mis lõplikult realiseeritakse kunagi hiljem.

Selgusetuks jääb ka, kas mäng realiseeritakse ühes arvutis kordamööda mängimiseks või saab olema võimalus mängida mängu üle võrgu mitme vastasega. See viimane versioon on ''nice to have'' osas ehk siis mängu valmiv versioon ei pruugi sisaldada elementi, mis muudaks selle mängu kasutajatele atraktiivseks.

Analüüsidokumendis võiks ära kirjeldada peamised kasutuslood, mis moodi mängu kasutaja suhtleb mänguga - kasutuslood puuduvad. Milliseid operatsioone ta saab teha ja kuidas ta saab aru, et tema kord on parajasti midagi teha. Suhteliselt põhjalikult on kirjeldatud lahingu pidamise reegleid, kuid on ebaselge, kuidas mängija saab tagasiside lahingu ja vägede liikumise toimumise kohta. Lisaks kasutuslugudele peaks analüüsidokumendis olema eraldi välja toodud ka kasutajate rollid.

Analüüs on kohati väga üldsõnaline, samas teises kohas isegi liigagi detailidesse laskuv - funktsionaalne kirjeldus on liiga tehniline ja ei too välja üldist loogikat. Puudub süsteemsus, mis tingib ka selle, et võhikul on väga raske korralikku ülevaadet asjast saada.

==Vormistus==
Vormistus võiks korrektsem olla. Dokumendis esineb rohkelt näpuvigu, mis viitab viimistluse puudumisele. Samuti raskendavad lugemist õigekirja vead. Puuduvad nummerdatud pealkirjad ja leheküljenumbrid. Analüüsis kasutatud mõisted on defineerimata.

Dokumendil on ebaloogiline ülesehitus (nt ''nice to have'' lahendused võiks olla dokumendi lõpus ära kirjeldatud).

==Kokkuvõte==
Idee on hea ja ambitsioonikas, aga dokumendist ei saa päris täit ja selget ülevaadet, kuidas mäng funktsioneerib.

==Küsimused==
#Funktsionaalsuse alt tuleb hetkel välja, et mängija saab ainult kaarti ja akna suurust valida, aga muud tegevused?
#Mängu tegevuste täitmise järjekord ja lahingute pidamise motoorika, millisesse faasi need tegevused kuuluvad? Kes täidab, tegutseb?
#Rohkem kui 2 osapoolt lahingus ründemehhaanika (A -> B, B -> A, C -> B, D -> A). Miks kõigepealt toimub lahing C->B,D->A vahel?

Retsenseeris [[Meeskond Naaskel]]

2012-12-17T21:08:18Z

Hsirkel: /* Prototüüp */

Meeskond Metronaator

2012-12-17T21:07:53Z

Hsirkel: /* Prototüüp */

[[Category: Programmeerimine CSharp keeles]]
=Kirjeldus=
Metro Invaders Projekti sisuks on vertical-scrolling shooter-tüüpi mäng Windows 8 Metro platvormile.
=Tööjaotus=
*Tõnis Markus (arhitekt)
*Hanno Sirkel (projektijuht)
*Kristo Danilson
*Jaagup Rooso

=Lingid=
* Analüüsidokument [https://docs.google.com/document/d/1aKNQXLdw8TjqA84e1UHhMNTRYikoBGngnaZd9UDZxzM/edit Google docs] [https://docs.google.com/file/d/0B115ocT1N6XANzlobVVLNUNNREk/edit PDF]
* Kood Github'is [https://github.com/hannosirkel/ITK-CSharp Github]
* Objektide dokument [https://docs.google.com/document/d/16IkYTqFscU56_tQi3Wcdws1ppiqTkDauDQpEvIzoCk4/edit Google docs]
* Retsensioon meeskonna "Ratsa Rikkaks" projekti analüüsile [https://wiki.itcollege.ee/index.php/Talk:Ratsa_Rikkaks#Anal.C3.BC.C3.BCsi_retsensioon]

=Prototüüp=
Prototüübis on realiseeritud mängija liikumine ekraanil, vastase tekitamine, liikumine ja vastase hävitamine mängija poolt.

Kuna tegu on Windows 8 Metro app'iga, on prototüübi jooksutamine võimalik vaid Windows 8 opsüsteemiga arvutis, millel on aktiivne developer litsents.
Mugavaim viis prototüüp käima panna on tõmmata kood github'ist, pakkida lahti ning avada .sln fail Visual Studio 2012'ga. Selleks otstarbeks on loodud repositooriumisse eraldi branch "prototype", kuhu peale ülesande esitamise tähtaega (17.12) enam muudatusi ei lisata.
* Prototüübi pakk github'ist: [https://github.com/hannosirkel/ITK-CSharp/archive/prototype.zip]

Alternatiivse võimalusena saab kasutada AppPackaget. Jällegi kehtib win8 + dev litsentsi reegel. Installeerimise protseduur on veidi tülikas, sestap parem võimalus on kasutada koodi .zip'i.
* AppPackage: [http://hsirkel.net/MetroInvaders_prototype_AppPackage.zip]
* Instruktsioon AppPackage installeerimiseks: [http://msdn.microsoft.com/en-us/library/windows/apps/hh975356.aspx]

Meeskond Metronaator

2012-12-17T21:07:42Z

Hsirkel:

[[Category: Programmeerimine CSharp keeles]]
=Kirjeldus=
Metro Invaders Projekti sisuks on vertical-scrolling shooter-tüüpi mäng Windows 8 Metro platvormile.
=Tööjaotus=
*Tõnis Markus (arhitekt)
*Hanno Sirkel (projektijuht)
*Kristo Danilson
*Jaagup Rooso

=Lingid=
* Analüüsidokument [https://docs.google.com/document/d/1aKNQXLdw8TjqA84e1UHhMNTRYikoBGngnaZd9UDZxzM/edit Google docs] [https://docs.google.com/file/d/0B115ocT1N6XANzlobVVLNUNNREk/edit PDF]
* Kood Github'is [https://github.com/hannosirkel/ITK-CSharp Github]
* Objektide dokument [https://docs.google.com/document/d/16IkYTqFscU56_tQi3Wcdws1ppiqTkDauDQpEvIzoCk4/edit Google docs]
* Retsensioon meeskonna "Ratsa Rikkaks" projekti analüüsile [https://wiki.itcollege.ee/index.php/Talk:Ratsa_Rikkaks#Anal.C3.BC.C3.BCsi_retsensioon]

=Prototüüp=
Prototüübis on realiseeritud mängija liikumine ekraanil, vastase tekitamine, liikumine ja vastase hävitamine mängija poolt.
Kuna tegu on Windows 8 Metro app'iga, on prototüübi jooksutamine võimalik vaid Windows 8 opsüsteemiga arvutis, millel on aktiivne developer litsents.
Mugavaim viis prototüüp käima panna on tõmmata kood github'ist, pakkida lahti ning avada .sln fail Visual Studio 2012'ga. Selleks otstarbeks on loodud repositooriumisse eraldi branch "prototype", kuhu peale ülesande esitamise tähtaega (17.12) enam muudatusi ei lisata.
* Prototüübi pakk github'ist: [https://github.com/hannosirkel/ITK-CSharp/archive/prototype.zip]

Alternatiivse võimalusena saab kasutada AppPackaget. Jällegi kehtib win8 + dev litsentsi reegel. Installeerimise protseduur on veidi tülikas, sestap parem võimalus on kasutada koodi .zip'i.
* AppPackage: [http://hsirkel.net/MetroInvaders_prototype_AppPackage.zip]
* Instruktsioon AppPackage installeerimiseks: [http://msdn.microsoft.com/en-us/library/windows/apps/hh975356.aspx]

Meeskond Metronaator

2012-12-17T21:05:53Z

Hsirkel:

[[Category: Programmeerimine CSharp keeles]]
=Kirjeldus=
Metro Invaders Projekti sisuks on vertical-scrolling shooter-tüüpi mäng Windows 8 Metro platvormile.
=Tööjaotus=
*Tõnis Markus (arhitekt)
*Hanno Sirkel (projektijuht)
*Kristo Danilson
*Jaagup Rooso

=Lingid=
* Analüüsidokument [https://docs.google.com/document/d/1aKNQXLdw8TjqA84e1UHhMNTRYikoBGngnaZd9UDZxzM/edit Google docs] [https://docs.google.com/file/d/0B115ocT1N6XANzlobVVLNUNNREk/edit PDF]
* Kood Github'is [https://github.com/hannosirkel/ITK-CSharp Github]
* Objektide dokument [https://docs.google.com/document/d/16IkYTqFscU56_tQi3Wcdws1ppiqTkDauDQpEvIzoCk4/edit Google docs]
* Retsensioon meeskonna "Ratsa Rikkaks" projekti analüüsile [https://wiki.itcollege.ee/index.php/Talk:Ratsa_Rikkaks#Anal.C3.BC.C3.BCsi_retsensioon]

=Prototüüp=
Kuna tegu on Windows 8 Metro app'iga, on prototüübi jooksutamine võimalik vaid Windows 8 opsüsteemiga arvutis, millel on aktiivne developer litsents.
Mugavaim viis prototüüp käima panna on tõmmata kood github'ist, pakkida lahti ning avada .sln fail Visual Studio 2012'ga. Selleks otstarbeks on loodud repositooriumisse eraldi branch "prototype", kuhu peale ülesande esitamise tähtaega (17.12) enam muudatusi ei lisata.
* Prototüübi pakk github'ist: [https://github.com/hannosirkel/ITK-CSharp/archive/prototype.zip]

Alternatiivse võimalusena saab kasutada AppPackaget. Jällegi kehtib win8 + dev litsentsi reegel. Installeerimise protseduur on veidi tülikas, sestap parem võimalus on kasutada koodi .zip'i.
* AppPackage: [http://hsirkel.net/MetroInvaders_prototype_AppPackage.zip]
* Instruktsioon AppPackage installeerimiseks: [http://msdn.microsoft.com/en-us/library/windows/apps/hh975356.aspx]

Talk:Ratsa Rikkaks

2012-11-25T19:47:21Z

Hsirkel:

=Analüüsi retsensioon=

Meeskond on valinud projektiks videolaenutuse infosüsteemi. Analüüsist saab piisava ülevaate loodava infosüsteemi oodatavast funktsionaalsusest. Tegevused kasutaja seisukohast lähtuvalt on hästi lahti kirjutatud.

Kuivõrd eesmärgiks on reliseerida infosüsteem arendamaks meeskonnatöö ja programmeerimise alaseid oskuseid, siis on niisugune valik sobiv. Reaalset ärilist rakendust võiks sarnasest valdkonnast leida näiteks tööriistalaenutuse vms infosüsteemile.

Analüüsist ei nähtu, kas rakendus realiseeritakse modulaarsena, mis võimaldaks hiljem lisada erinevaid teenuseid (mingi teise kauba laenutamine) või tegevusvaldkondi (kasutades olemasolevat kliendihalduse moodulit).

Tootekataloogi ("Filmide arvestus") osas jääb selgusetuks, kas ja kuidas õnnestub vaadata laoseisu (ehk millised filmid on laenutuseks saadaval, millised välja laenatud). Kuidas leida, kas kliendi poolt soovitud film on soovitavaks ajaperioodiks saadaval? Kuidas välditakse ühe filmi topelt laenutamist samaks ajaperioodiks? Kuidas käsitletakse mitme samasisulise toote (2tk sama filmi) olekut kataloogis, kas lisatakse eraldi kirjena? Kui ei lisata eraldi kirjena, siis ilmselt tekib probleem tuvastamisega, milline kasutaja mis ajahetkel laenutas millist konkreetset toodet (et selgitada näiteks välja, kes plaadi ära kriipis). Samas kui lisatakse eraldi kirjetena, siis kuidas realiseeritakse ülevaatlik päring saadaolevate ja välja laenutatud toodete kohta ning kas uue laenutuse loomisel peab siis otsima välja konkreetse toote või võetakse automaatselt esimene saadaolev. Samas puudub tootel väljapakutud struktuuris unikaalne identifikaator. On olemas küll automaatselt genereeritud UID, kuid selle sidumine füüsilise tootega võib osutuda probleemseks (aga samas võib ka toimida, kui näiteks rakendus prindib, või tehakse seda käsitsi, toote lisamisel sildiprinterist vastava UID'ga kleepeka, mille saab siis karbile kleepida).

Kokkuvõttes valitud töö on piisava mahuga ja selle realiseerimine antud meeskonna suurusega õppeaine raames on realistlik. Analüüs annab piisava detailsusega ülevaate loodavast rakendusest. Teema ei ole kuigi aktuaalne, puudub äriline väljund.

Koostas: [[Meeskond_Metronaator]]

Meeskond Metronaator

2012-11-25T19:46:30Z

Hsirkel: /* Lingid */

Talk:Ratsa Rikkaks

2012-11-25T19:45:33Z

Hsirkel: /* Analüüsi retsensioon */

Talk:Ratsa Rikkaks

2012-11-25T19:45:22Z

Hsirkel: Created page with '=Analüüsi retsensioon= Meeskond on valinud projektiks videolaenutuse infosüsteemi. Analüüsist saab piisava ülevaate loodava infosüsteemi oodatavast funktsionaalsusest. Te…'

Talk:Meeskond Metronaator

2012-11-25T12:28:06Z

Hsirkel: Created page with '=Analüüsi retsensioon= Tekst siia Koostas: Meeskond'

=Analüüsi retsensioon=
Tekst siia

Koostas: Meeskond

Meeskond Metronaator

2012-11-20T08:03:46Z

Hsirkel: /* Lingid */

Meeskond Metronaator

2012-11-03T13:53:55Z

Hsirkel: /* Tööjaotus */

Juhend: Kodutöö aines "Programmeerimine CSharp keeles" (Kaugõpe2012)

2012-11-01T10:21:47Z

Hsirkel: /* Meeskond Metronaator */

=Kodutöö aines "Programmeerimine C# keeles"=

==Eesmärk==
Saada praktiline arenduskogemus .NET keskkonnas ning arendada meeskonnatöö kogemust ja analüüsivõimet.

==Reeglid==
Ühte projektimeeskonda kuulub 3-5 tudengit. Ühel teemal võib teostada projekti üks või mitu meeskonda.Töö käiku kajastatakse https://wiki.itcollege.ee keskkonnas või soovi korral võib seda teha ka ajaveebis(blogis).
Ajaveebi pidamise eesmärke on kaks: nii on võimalik kirja panna kõik mõtted ja ideed (ning nendest jääb jälg ja dokumentatsioon) ning õppejõul on hiljem võimalik saada ülevaade iga projektimeeskonna liikme panusest. Ajaveebi loob ja ajaveebi haldab projektimeeskond vabalt valitud (avalikus) keskkonnas.

==Tähtaegadest kinnipidamine==
Projekt jaguneb alamosadeks, millele on määratud tähtajad. Maksimumpunktide saavutamiseks tuleb tähtajaks esitada töö, mis vastab püstitatud nõuetele. Kui töö esitatakse tähtajast hiljem ,kaotatakse iga hilinenud päeva kohta 10% punktidest. Maksimaalselt kaotatakse 50%.

Näide:
Töö esitamise tähtaeg on 4.09.2012 kell 23:59 ja selle osa eest on võimalik teenida 8p. Meeskond1 esitab töö, mis vastab nõuetele, tähtajaks. Tulemus:8p
Meeskond2 esitab töö, mis vastab nõuetele 05.09.2011 02:00 (ehk tähtajast paar tundi hiljem). Tulemus: 7,1 punkti.
Meeskond3 esitab töö, mis vastab nõuetele 06.09.2011 12:00 (ehk tähtajast paar päeva hiljem). Tulemus: 6,4 punkti.

==Hindamine==
Teostatuks loetakse projekt juhul, kui lähteülesanne on realiseeritud, lahendus on töötav, kuid esineb suuremaid vigu ning piirsituatsioonidega ei ole arvestatud.
Maksimumtulemuse saavutamiseks peab projekt olema teostatud tehniliselt veatult ning varustatud dokumentatsiooniga, milles sisaldub arendusprotsessi kirjeldus (peab selguma ka iga rühmaliikme panus projekti teostamisel), kasutajajuhend ning lahenduse kirjeldus. Tehnilisi ja vormistuslike puudujääke on võimalik korvata lisavõimaluste realiseerimisega.Üldjuhul tuleb loodud lahendust ka praktikumides või loengutes teistele tudengitele tutvustada (ca 10 min).
Nagu eelpool mainitud, koosneb projekt erinevatest osadest. Punktide arvu määramisel arvestatakse ka tähtajast kinni pidamist, mille toimimisloogika on kirjeldatud eespool.

===Meeskonna kokkupanek ja idee===
'''05.11.2012''' (2p)

Tekitatakse meeskonna wiki lehekülg. Meeskonnal peab olema nimi ning see koosneb kolmest kuni viiest liikmest. Määratakse projektijuht. Juhul kui hakatakse blogi pidama kuskil mujal keskkonnas ilmub selle kohta link. Paari sõnaga peaks kirjeldama idee olemust nii, et selle üldine suund oleks arusaadav.

===Analüüs===
'''19.11.2012''' (6p)
Analüütilise osa eesmärgiks on arendada tudengite analüüsioskust, mida on vaja ka päris tarkvaraarenduse protsessi juures.'''NB! Miinimum sõnade arv 700''' Selle osa käigus peab valmima loodava rakenduse analüüs, mis sisaldab muu hulgas ka:
*Analüüs rakendusele. (Mida see endas sisaldab? Mis on selle eesmärk? Mida tavakasutaja sellega teha saaks? Milliste osade realiseerimine võib osutuda problemaatiliseks?) Kui on tööjaotus paigas, siis tuua ka see välja.
*Tuua välja nimekiri funktsionaalsusest, mida plaanitakse kindlasti teostada(''Must have'')
*Nimekiri funktsionaalsustest, mis võiks olla, aga mida ei pruugita ajapuuduse tõttu realiseerida.(''Nice to have'')

'''Retsensioon''' 25.11.2012 (3p)

===Prototüüp===
'''10.12.2012'''(10p)

Valmib projekti esmane realisatsioon. Laias laastus on peafunktsionaalsused realiseeritud(Nimekiri funktsionaalsusest, mida plaanitakse teostada). Programmis võib esineda üksikuid, kuid mitte väga suuri vigu.

'''Retsensioon''' 17.12.2012(5p)

===Lõpptoode===
'''07.01.2013'''(20p)
Selleks faasiks peab projekt maksimumpuntkide saavutamiseks olema teostatud tehniliselt veatult ning varustatud dokumentatsiooniga, milles sisaldub arendusprotsessi kirjeldus (peab selguma ka iga rühmaliikme panus projekti teostamisel), kasutajajuhend ning lahenduse kirjeldus.

'''Retsensioon''' 14.01.2013(5p)

===Esitlus/Kaitsmine===

'''Toimub loengutes/praktikumides''' ''(4p) ''
Esitlusel kaitstakse projekti. Tutvustatakse tehnoloogiat, mida kasutati rakenduse realiseerimiseks. Lühidalt räägitakse tööjaotusest ning probleemidest, mis tekkisid projekti realiseerimisel. Näidatakse lähtekoodi ja demonstreeritakse oma rakendust teistele tudengitele, kes võivad selle kohta küsimusi küsida. Kestvus ~20min.

====Kaitsmise ajad====
Siia ilmuvad detsembri alguses projekti kaitsmise ajad.

==Konsultatsioon==
Igal projektimeeskonnal on piiramatu õigus saada õppejõu käest konsultatsiooni ja juhendamist oma
töö tegemiseks, kas harjutuste ajal või pärast harjutusi ja loenguid. Eriaegade suhtes saab sõlmida
õppejõuga kokkuleppeid kontaktidel +372 53 469 734 või mait.poska [ät] itcollege.ee
(teksti originaalautor Priit Raspel)

=Teemad 2012 sügis=
Kodutööna tuleb luua:

==Kodune raamatukogu==
Kodudes on tihti erinevaid raamatuid (filme, muud nänni) ja sõbrad tahavad neid vahel laenutada.
Loo rakendus, mis
* Võimaldaks sisestada kodused raamatud
* Võimaldaks luua laenutajate profiile
* Raamatuid välja laenutada (tähtajaliselt)
* Laseks koostada erinevaid aruandeid (kodusolevad raamatud, väljalaenutatud raamatud, tähtaja ületanud laenutused jne)

Lisavõimalused
* Kui laenutaja profiilis on e-mail, siis saada automaatselt e-kiri „kallis sõber see ja see, Sinu käes on minu raamat, kas tood tagasi ka?”
* Kuva hoiatused, kui laenutaja laenutuste ajalugu on vilets või kui mõni raamat on tagastamata.
* Lase lisada raamatutele pilt
* Loo lihtne veebiliides (et sõbrad saaksid veebist vaadata, mis raamatud kasutajal kodus veel alles on)
Või

==CRM==
Oma klientidest peab olema ülevaade.
Loo rakendus, mis võimaldab:
* Kliente ning nende kontaktisikuid sisestada, muuta ning kustutada
* Võimalda sisestada kliendikontakte
* Koostada hinnapakkumisi klientidele, kusjuures hinnapakkumine lisatakse süsteemi ka kui kliendikontakt ning saadetakse samast süsteemist kliendile.
* Kliendi andmete vaatamisel kuvatakse ka kliendikontaktid

Lisavõimalused
* Loo võimalus, kus kontaktisiku sünnipäeva saabumisel saadetakse automaatselt inimesele meil õnnesoovidega
* Õnnitlusmeilide template’sid võiks olla mitu
* Loo võimalus kliendi huvide (huvialade) kajastamiseks süsteemis

==Tetris(XNA)==
==XoniX(XNA)==

==Nõuded rakendusele==
Loodav rakendus peab:
* Peab kasutama andmebaasi (erikokkuleppel ka XML formaadis andmeallikat)
* Peab võimaldama tegevuste kohta registri pidamist (logi)
* Kasutama kasutajaliidesena ühte järgmistest: WPF, Windows Phone 7/8, Windows 8 rakendus või ASP.Net

'''Loodav rakendus peab olema loodud objektorienteeritud lähenemist kasutades!''' Klassid, klassid, klassid

Lisapunkte annab:
* Silmailu
* Kood on kirjutatud häid praktikaid järgides ja on veatu(testimine, testimine, testimine)
* Orginaalsed ideed ja hea äriidee
* Rakendus leiab kasutust pärismaailmas

==Nõuded XNA projektile==
Loodav mäng peab sisaldama:
* Erinevaid tasemeid
* Punktiarvestust
* XBox puldi tuge
* Klaviatuurilt juhtimise tuge

'''Loodav mäng peab olema loodud objektorienteeritud lähenemist kasutades!''' Klassid, klassid, klassid

Lisapunkte annab:
* Silmailu
* Kood on kirjutatud häid praktikaid järgides ja on veatu(testimine, testimine, testimine)
* Orginaalsed ideed ja hea ''story''

=Meeskonnad 2012=

==Meeskond Test==
Meeskonna wiki leht: [[Meeskond Test]]
Meeskonna liikmed:
*Peeter Pakiraam
*Agu Sihvka

Analüüsi retsenioon [https://wiki.itcollege.ee/index.php?title=Juhend:_Kodut%C3%B6%C3%B6_aines_%22Programmeerimine_CSharp_keeles%22_(2012)&action=edit&section=21 siin on midagi]

==Meeskond Naaskel==
Meeskonna wiki leht: [[Meeskond Naaskel]]

Meeskonna liikmed:
*Helge Saks
*Merje Kungla
*Heiki Linnamägi
*Kristjan Pihus
*Ülari Ainjärv

==Meeskond <nimi>==
Meeskonna wiki leht: [https://wiki.itcollege.ee/ selgub kui meeskonnal on nimi]

Meeskonna liikmed:
*Marek Öövel
*Artur Hokkonen
*<vaba>
*<vaba>
*<vaba>

Teema: ei ole veel valitud, arutame uute liikmetega koos

''Artur'':
;huvi pakkuvad teemad (jalgratta leiutamine)
: ladu
: kliendihaldus (CRM)
: arved
;mida tahaksin teha
: wpf (GUI)
: baas (ddl)
: rakenduskiht (class library'd + xml üle võrgu - System.Web.Services.WebService?)

==Meeskond Metronaator==
Meeskonna wiki leht: [https://wiki.itcollege.ee/index.php/Metronaator]

Meeskonna liikmed:
*Tõnis Markus
*Hanno Sirkel
*Jaagup Rooso
*Kristo Danilson

Projekt: Metro Invaders
Projekti sisuks on ''vertical-scrolling'' shooter-tüüpi mäng Windows 8 Metro platvormile.

Link analüüsidokumendile: [https://docs.google.com/document/d/1aKNQXLdw8TjqA84e1UHhMNTRYikoBGngnaZd9UDZxzM]
Link koodile Github'is: [https://github.com/hannosirkel/ITK-CSharp]
Link blogile, kust võib leida veidi infot projekti kulgemise kohta: []

Juhend: Kodutöö aines "Programmeerimine CSharp keeles" (Kaugõpe2012)

2012-11-01T10:19:50Z

Hsirkel: /* Meeskonnad 2012 */

=Kodutöö aines "Programmeerimine C# keeles"=

==Eesmärk==
Saada praktiline arenduskogemus .NET keskkonnas ning arendada meeskonnatöö kogemust ja analüüsivõimet.

==Reeglid==
Ühte projektimeeskonda kuulub 3-5 tudengit. Ühel teemal võib teostada projekti üks või mitu meeskonda.Töö käiku kajastatakse https://wiki.itcollege.ee keskkonnas või soovi korral võib seda teha ka ajaveebis(blogis).
Ajaveebi pidamise eesmärke on kaks: nii on võimalik kirja panna kõik mõtted ja ideed (ning nendest jääb jälg ja dokumentatsioon) ning õppejõul on hiljem võimalik saada ülevaade iga projektimeeskonna liikme panusest. Ajaveebi loob ja ajaveebi haldab projektimeeskond vabalt valitud (avalikus) keskkonnas.

==Tähtaegadest kinnipidamine==
Projekt jaguneb alamosadeks, millele on määratud tähtajad. Maksimumpunktide saavutamiseks tuleb tähtajaks esitada töö, mis vastab püstitatud nõuetele. Kui töö esitatakse tähtajast hiljem ,kaotatakse iga hilinenud päeva kohta 10% punktidest. Maksimaalselt kaotatakse 50%.

Näide:
Töö esitamise tähtaeg on 4.09.2012 kell 23:59 ja selle osa eest on võimalik teenida 8p. Meeskond1 esitab töö, mis vastab nõuetele, tähtajaks. Tulemus:8p
Meeskond2 esitab töö, mis vastab nõuetele 05.09.2011 02:00 (ehk tähtajast paar tundi hiljem). Tulemus: 7,1 punkti.
Meeskond3 esitab töö, mis vastab nõuetele 06.09.2011 12:00 (ehk tähtajast paar päeva hiljem). Tulemus: 6,4 punkti.

==Hindamine==
Teostatuks loetakse projekt juhul, kui lähteülesanne on realiseeritud, lahendus on töötav, kuid esineb suuremaid vigu ning piirsituatsioonidega ei ole arvestatud.
Maksimumtulemuse saavutamiseks peab projekt olema teostatud tehniliselt veatult ning varustatud dokumentatsiooniga, milles sisaldub arendusprotsessi kirjeldus (peab selguma ka iga rühmaliikme panus projekti teostamisel), kasutajajuhend ning lahenduse kirjeldus. Tehnilisi ja vormistuslike puudujääke on võimalik korvata lisavõimaluste realiseerimisega.Üldjuhul tuleb loodud lahendust ka praktikumides või loengutes teistele tudengitele tutvustada (ca 10 min).
Nagu eelpool mainitud, koosneb projekt erinevatest osadest. Punktide arvu määramisel arvestatakse ka tähtajast kinni pidamist, mille toimimisloogika on kirjeldatud eespool.

===Meeskonna kokkupanek ja idee===
'''05.11.2012''' (2p)

Tekitatakse meeskonna wiki lehekülg. Meeskonnal peab olema nimi ning see koosneb kolmest kuni viiest liikmest. Määratakse projektijuht. Juhul kui hakatakse blogi pidama kuskil mujal keskkonnas ilmub selle kohta link. Paari sõnaga peaks kirjeldama idee olemust nii, et selle üldine suund oleks arusaadav.

===Analüüs===
'''19.11.2012''' (6p)
Analüütilise osa eesmärgiks on arendada tudengite analüüsioskust, mida on vaja ka päris tarkvaraarenduse protsessi juures.'''NB! Miinimum sõnade arv 700''' Selle osa käigus peab valmima loodava rakenduse analüüs, mis sisaldab muu hulgas ka:
*Analüüs rakendusele. (Mida see endas sisaldab? Mis on selle eesmärk? Mida tavakasutaja sellega teha saaks? Milliste osade realiseerimine võib osutuda problemaatiliseks?) Kui on tööjaotus paigas, siis tuua ka see välja.
*Tuua välja nimekiri funktsionaalsusest, mida plaanitakse kindlasti teostada(''Must have'')
*Nimekiri funktsionaalsustest, mis võiks olla, aga mida ei pruugita ajapuuduse tõttu realiseerida.(''Nice to have'')

'''Retsensioon''' 25.11.2012 (3p)

===Prototüüp===
'''10.12.2012'''(10p)

Valmib projekti esmane realisatsioon. Laias laastus on peafunktsionaalsused realiseeritud(Nimekiri funktsionaalsusest, mida plaanitakse teostada). Programmis võib esineda üksikuid, kuid mitte väga suuri vigu.

'''Retsensioon''' 17.12.2012(5p)

===Lõpptoode===
'''07.01.2013'''(20p)
Selleks faasiks peab projekt maksimumpuntkide saavutamiseks olema teostatud tehniliselt veatult ning varustatud dokumentatsiooniga, milles sisaldub arendusprotsessi kirjeldus (peab selguma ka iga rühmaliikme panus projekti teostamisel), kasutajajuhend ning lahenduse kirjeldus.

'''Retsensioon''' 14.01.2013(5p)

===Esitlus/Kaitsmine===

'''Toimub loengutes/praktikumides''' ''(4p) ''
Esitlusel kaitstakse projekti. Tutvustatakse tehnoloogiat, mida kasutati rakenduse realiseerimiseks. Lühidalt räägitakse tööjaotusest ning probleemidest, mis tekkisid projekti realiseerimisel. Näidatakse lähtekoodi ja demonstreeritakse oma rakendust teistele tudengitele, kes võivad selle kohta küsimusi küsida. Kestvus ~20min.

====Kaitsmise ajad====
Siia ilmuvad detsembri alguses projekti kaitsmise ajad.

==Konsultatsioon==
Igal projektimeeskonnal on piiramatu õigus saada õppejõu käest konsultatsiooni ja juhendamist oma
töö tegemiseks, kas harjutuste ajal või pärast harjutusi ja loenguid. Eriaegade suhtes saab sõlmida
õppejõuga kokkuleppeid kontaktidel +372 53 469 734 või mait.poska [ät] itcollege.ee
(teksti originaalautor Priit Raspel)

=Teemad 2012 sügis=
Kodutööna tuleb luua:

==Kodune raamatukogu==
Kodudes on tihti erinevaid raamatuid (filme, muud nänni) ja sõbrad tahavad neid vahel laenutada.
Loo rakendus, mis
* Võimaldaks sisestada kodused raamatud
* Võimaldaks luua laenutajate profiile
* Raamatuid välja laenutada (tähtajaliselt)
* Laseks koostada erinevaid aruandeid (kodusolevad raamatud, väljalaenutatud raamatud, tähtaja ületanud laenutused jne)

Lisavõimalused
* Kui laenutaja profiilis on e-mail, siis saada automaatselt e-kiri „kallis sõber see ja see, Sinu käes on minu raamat, kas tood tagasi ka?”
* Kuva hoiatused, kui laenutaja laenutuste ajalugu on vilets või kui mõni raamat on tagastamata.
* Lase lisada raamatutele pilt
* Loo lihtne veebiliides (et sõbrad saaksid veebist vaadata, mis raamatud kasutajal kodus veel alles on)
Või

==CRM==
Oma klientidest peab olema ülevaade.
Loo rakendus, mis võimaldab:
* Kliente ning nende kontaktisikuid sisestada, muuta ning kustutada
* Võimalda sisestada kliendikontakte
* Koostada hinnapakkumisi klientidele, kusjuures hinnapakkumine lisatakse süsteemi ka kui kliendikontakt ning saadetakse samast süsteemist kliendile.
* Kliendi andmete vaatamisel kuvatakse ka kliendikontaktid

Lisavõimalused
* Loo võimalus, kus kontaktisiku sünnipäeva saabumisel saadetakse automaatselt inimesele meil õnnesoovidega
* Õnnitlusmeilide template’sid võiks olla mitu
* Loo võimalus kliendi huvide (huvialade) kajastamiseks süsteemis

==Tetris(XNA)==
==XoniX(XNA)==

==Nõuded rakendusele==
Loodav rakendus peab:
* Peab kasutama andmebaasi (erikokkuleppel ka XML formaadis andmeallikat)
* Peab võimaldama tegevuste kohta registri pidamist (logi)
* Kasutama kasutajaliidesena ühte järgmistest: WPF, Windows Phone 7/8, Windows 8 rakendus või ASP.Net

'''Loodav rakendus peab olema loodud objektorienteeritud lähenemist kasutades!''' Klassid, klassid, klassid

Lisapunkte annab:
* Silmailu
* Kood on kirjutatud häid praktikaid järgides ja on veatu(testimine, testimine, testimine)
* Orginaalsed ideed ja hea äriidee
* Rakendus leiab kasutust pärismaailmas

==Nõuded XNA projektile==
Loodav mäng peab sisaldama:
* Erinevaid tasemeid
* Punktiarvestust
* XBox puldi tuge
* Klaviatuurilt juhtimise tuge

'''Loodav mäng peab olema loodud objektorienteeritud lähenemist kasutades!''' Klassid, klassid, klassid

Lisapunkte annab:
* Silmailu
* Kood on kirjutatud häid praktikaid järgides ja on veatu(testimine, testimine, testimine)
* Orginaalsed ideed ja hea ''story''

=Meeskonnad 2012=

==Meeskond Test==
Meeskonna wiki leht: [[Meeskond Test]]
Meeskonna liikmed:
*Peeter Pakiraam
*Agu Sihvka

Analüüsi retsenioon [https://wiki.itcollege.ee/index.php?title=Juhend:_Kodut%C3%B6%C3%B6_aines_%22Programmeerimine_CSharp_keeles%22_(2012)&action=edit&section=21 siin on midagi]

==Meeskond Naaskel==
Meeskonna wiki leht: [[Meeskond Naaskel]]

Meeskonna liikmed:
*Helge Saks
*Merje Kungla
*Heiki Linnamägi
*Kristjan Pihus
*Ülari Ainjärv

==Meeskond <nimi>==
Meeskonna wiki leht: [https://wiki.itcollege.ee/ selgub kui meeskonnal on nimi]

Meeskonna liikmed:
*Marek Öövel
*Artur Hokkonen
*<vaba>
*<vaba>
*<vaba>

Teema: ei ole veel valitud, arutame uute liikmetega koos

''Artur'':
;huvi pakkuvad teemad (jalgratta leiutamine)
: ladu
: kliendihaldus (CRM)
: arved
;mida tahaksin teha
: wpf (GUI)
: baas (ddl)
: rakenduskiht (class library'd + xml üle võrgu - System.Web.Services.WebService?)

==Meeskond Metronaator==
Meeskonna wiki leht: [https://wiki.itcollege.ee/Metronaator]

Meeskonna liikmed:
*Tõnis Markus
*Hanno Sirkel
*Jaagup Rooso
*Kristo Danilson

Projekt: Metro Invaders
Projekti sisuks on ''vertical-scrolling'' shooter-tüüpi mäng Windows 8 Metro platvormile.

Link analüüsidokumendile: [https://docs.google.com/document/d/1aKNQXLdw8TjqA84e1UHhMNTRYikoBGngnaZd9UDZxzM]
Link koodile Github'is: [https://github.com/hannosirkel/ITK-CSharp]
Link blogile, kust võib leida veidi infot projekti kulgemise kohta: []

User:Hsirkel

2011-11-14T15:13:01Z

Hsirkel: /* Erialatutvustuse aine arvestustöö */

=Erialatutvustuse aine arvestustöö=
Autor: Hanno Sirkel<br>
01. november 2011

==Essee==
'''Innovatsioon läbi turunõudluse või siiski mitte...'''

Hiljutises Digitunnis diskuteeriti Apple'i tootearenduse strateegia üle. Ettevõtte lähtekoht uute toodete arendamisel on pakkuda tarbijatele mitte seda, mida tarbija soovib vaid seda, mida tarbija hakkab soovima peale toote turuletulekut. Kõlab agressiivse ja kohati üleoleva suhtumisena, ent lähemalt vaadeldes leiame, et niisugune strateegia on toiminud aegade algusest innovaatiliste toodete turustamisel. Esimeses etapis võib tunduda, et uut toodet pole kellegile tarvis ning tegu on läbikukkumisega. Näiteid võib tuua ajaloost mitmeid, alates sõiduautost, ühekordsetest raseerimisvahenditest, lõpetades erinevate pilveteenustega.
Hea äripraktika näeb ette tarbijakesksust. Ent tõeliseks innovatsiooniks ei piisa turuosaliste soovide kuulamisest ja neile vastutulekust. Tarbijakeskne lähenemine toob kaasa lineaarse arengu ja kohati isegi pärsib arengut. x86 protsessorite tagasiühilduvus esimeste 8086 protsessoritega on hea näide selle kohta. Turg nõuab protsessoreid, mis on 100% ühilduvad esimeste 8086 protsessoritega, ent see ei tule kuidagi kasuks innovatsioonile. 2000 aastate algusest pärit näide Intel Itanium vs. AMD ilmestab seda hästi. Tehniliselt paljulubav arhitektuur, samas turuvõitluses jäädi alla AMD'le, kes lubas täielikku ühilduvust 8086 protsessoriga.

Tarbijakäitumises võib leida ka positiivseid näiteid. Tänaseks on suur osa sisutootjaid (muusika, filmid jmt.) loobunud koopiakaitsete rakendamisest ning müügiks pakutav sisu valdavalt piiranguteta formaadis. Suurtest teenusepakkujatest on sisu osas koopiakaitse piirangud eemaldanud Apple/iTunes, e-raamatute osas seni esirinnas püsiv Amazon seda veel teinud ei ole. Turu esmavallutajana on Amazoni edu märkimisväärne, ent konkurentide organiseerumisel võib see muutuda.

Tarbijakesksest ärimudelist väljumine peaks ideaalis koos käima kõrgete ärieetiliste standarditega. Tänapäeval on uute turusegmentide loomise taga peamiselt soov suurendada kasumit ning tagada ettevõttele rahavoog kaitstes väljatöötatud toodet või tehnoloogiat võimalikult laiaulatuslikult piirates sel viisil konkurentsi teket. Siin oleks tarvis suuremat sekkumist seadusandluse poolt koos avalikkuse kaasamisega. Kui loov meedia on juba valdavalt vabas formaadis kättesaadav, miks ei võiks tulevikus sama mudel levida teistesse valdkondadesse. Üksikisiku tasemel erineb tarkvara tootmine vähe näiteks muusika tootmisest. Valmis toote vormistamise seisukohast on erinevus siiski oluline. Helikonservi loomiseks piisab vähesest hulgast muusikutest, suure tarkvarapaketi tarvis läheb vaja märksa suuremat hulka autoreid. Kuigi tarkvara tootmises on hetkel valdav korporatiivne ärimudel, leidub ka teistsuguseid näiteid. Mõjukamatest projektidest kindlasti Linuxi tuuma arendamine vabatahtlike poolt, kelle töö on tasustatud suures osas antud tootele lisaväärtust pakkuvate ettevõtete poolt. Samas eksisteerib veel hulk väiksemaid, ent samuti äriliselt edukaid vabavara projekte (nt. Puppet Labs, Zenoss). Leian, et antud mudelil võiks lähitulevikus olla rohkem potentsiaali. Kapitali ja tööjõu jätkuv kontsentreerumine ei ole tänapäeval enam edasiviivaks jõuks. Dünaamilised väikeettevõtted, omavahel integreeruvad tooted, virtuaalne, mitteformaalsetes gruppides iseorganiseeruv tööjõud võiksid olla tuleviku märksõnad.

==Õ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===
Vastuse annab õppekorralduse eeskiri punktis 5.2 Eksamite ja Arvestuste Korraldus. Eksamid ja arvestused peavad olema sooritatud eksamisessiooni lõpukuupäevaks (leiab akadeemilisest kalendrist). Põhieksami lisaks on võimalik sooritada korduseksam, kuhu on tarvis registreeruda õppeosakonnas. Õppurist mitteoleneval põhjusel (haigused, surm ja muud tõsisemad ikaldused) on õppeprorektoril õigus pikendada tähtaega sügissemestril kuni kevadsemestri esimese poolsemestri eksamisessiooni lõpuni ja kevadsemestril sügissemestri alguspäevani. Kordussooritus on tasuta RE-õppekohal ning tasuline REV-õppekohal (tasu kehtestatakse rektori käskkirjaga, hetkel 13€).

===Küsimus 1===
Teisel või kolmandal õppeaastal avastad, et teine õppekava sobib paremini ja sa otsustad õppekava vahetada. Millised on tegevused ja mis ajaks need teha tuleb, et vahetada õppekava?

===Vastus===
Vastuse annab õppekorralduse eeskiri punktis 7. Akadeemiline Liikumine.
Vabade õppekohtade olemasolul on võimalik akadeemiline liikumine IT Kolledži siseselt. Akadeemiline liikumine peab olema lõpetatud semestri punase joone päevaks (kaugõppes 2011. õppeaastal 7. oktoobriks).

[[Category:Erialatutvustus 2011 kaugõpe]]

User:Hsirkel

2011-11-14T15:08:52Z

Hsirkel: /* Erialatutvustuse aine arvestustöö */

User:Hsirkel

2011-11-14T15:01:52Z

Hsirkel: /* Erialatutvustuse aine arvestustöö */

=Erialatutvustuse aine arvestustöö=
Autor: Hanno Sirkel<br>
Esitamise kuupäev: 30. september 2011

==Essee==
Innovatsioon läbi turunõudluse või siiski mitte...

Hiljutises Digitunnis diskuteeriti Apple'i tootearenduse strateegia üle. Ettevõtte lähtekoht uute toodete arendamisel on pakkuda tarbijatele mitte seda, mida tarbija soovib vaid seda, mida tarbija hakkab soovima peale toote turuletulekut. Kõlab agressiivse ja kohati üleoleva suhtumisena, ent lähemalt vaadeldes leiame, et niisugune strateegia on toiminud aegade algusest innovaatiliste toodete turustamisel. Esimeses etapis võib tunduda, et uut toodet pole kellegile tarvis ning tegu on läbikukkumisega. Näiteid võib tuua ajaloost mitmeid, alates sõiduautost, ühekordsetest raseerimisvahenditest, lõpetades erinevate pilveteenustega.
Hea äripraktika näeb ette tarbijakesksust. Ent tõeliseks innovatsiooniks ei piisa turuosaliste soovide kuulamisest ja neile vastutulekust. Tarbijakeskne lähenemine toob kaasa lineaarse arengu ja kohati isegi pärsib arengut. x86 protsessorite tagasiühilduvus esimeste 8086 protsessoritega on hea näide selle kohta. Turg nõuab protsessoreid, mis on 100% ühilduvad esimeste 8086 protsessoritega, ent see ei tule kuidagi kasuks innovatsioonile. 2000 aastate algusest pärit näide Intel Itanium vs. AMD ilmestab seda hästi. Tehniliselt paljulubav arhitektuur, samas turuvõitluses jäädi alla AMD'le, kes lubas täielikku ühilduvust 8086 protsessoriga.

Tarbijakäitumises võib leida ka positiivseid näiteid. Tänaseks on suur osa sisutootjaid (muusika, filmid jmt.) loobunud koopiakaitsete rakendamisest ning müügiks pakutav sisu valdavalt piiranguteta formaadis. Suurtest teenusepakkujatest on sisu osas koopiakaitse piirangud eemaldanud Apple/iTunes, e-raamatute osas seni esirinnas püsiv Amazon seda veel teinud ei ole. Turu esmavallutajana on Amazoni edu märkimisväärne, ent konkurentide organiseerumisel võib see muutuda.

Tarbijakesksest ärimudelist väljumine peaks ideaalis koos käima kõrgete ärieetiliste standarditega. Tänapäeval on uute turusegmentide loomise taga peamiselt soov suurendada kasumit ning tagada ettevõttele rahavoog kaitstes väljatöötatud toodet või tehnoloogiat võimalikult laiaulatuslikult piirates sel viisil konkurentsi teket. Siin oleks tarvis suuremat sekkumist seadusandluse poolt koos avalikkuse kaasamisega. Kui loov meedia on juba valdavalt vabas formaadis kättesaadav, miks ei võiks tulevikus sama mudel levida teistesse valdkondadesse. Üksikisiku tasemel erineb tarkvara tootmine vähe näiteks muusika tootmisest. Valmis toote vormistamise seisukohast on erinevus siiski oluline. Helikonservi loomiseks piisab vähesest hulgast muusikutest, suure tarkvarapaketi tarvis läheb vaja märksa suuremat hulka autoreid. Kuigi tarkvara tootmises on hetkel valdav korporatiivne ärimudel, leidub ka teistsuguseid näiteid. Mõjukamatest projektidest kindlasti Linuxi tuuma arendamine vabatahtlike poolt, kelle töö on tasustatud suures osas antud tootele lisaväärtust pakkuvate ettevõtete poolt. Samas eksisteerib veel hulk väiksemaid, ent samuti äriliselt edukaid vabavara projekte (nt. Puppet Labs, Zenoss). Leian, et antud mudelil võiks lähitulevikus olla rohkem potentsiaali.

==Õ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===
Vastuse annab õppekorralduse eeskiri punktis 5.2 Eksamite ja Arvestuste Korraldus. Eksamid ja arvestused peavad olema sooritatud eksamisessiooni lõpukuupäevaks (leiab akadeemilisest kalendrist). Põhieksami lisaks on võimalik sooritada korduseksam, kuhu on tarvis registreeruda õppeosakonnas. Õppurist mitteoleneval põhjusel (haigused, surm ja muud tõsisemad ikaldused) on õppeprorektoril õigus pikendada tähtaega sügissemestril kuni kevadsemestri esimese poolsemestri eksamisessiooni lõpuni ja kevadsemestril sügissemestri alguspäevani. Kordussooritus on tasuta RE-õppekohal ning tasuline REV-õppekohal (tasu kehtestatakse rektori käskkirjaga, hetkel 13€).

===Küsimus 1===
Teisel või kolmandal õppeaastal avastad, et teine õppekava sobib paremini ja sa otsustad õppekava vahetada. Millised on tegevused ja mis ajaks need teha tuleb, et vahetada õppekava?

===Vastus===
Vastuse annab õppekorralduse eeskiri punktis 7. Akadeemiline Liikumine.
Vabade õppekohtade olemasolul on võimalik akadeemiline liikumine IT Kolledži siseselt. Akadeemiline liikumine peab olema lõpetatud semestri punase joone päevaks (kaugõppes 2011. õppeaastal 7. oktoobriks).

--Category:Erialatutvustus 2011--

User:Hsirkel

2011-09-30T11:23:08Z

Hsirkel: Created page with '=Erialatutvustuse aine arvestustöö= Autor: Hanno Sirkel<br> Esitamise kuupäev: 30. september 2011 ==Essee== ==Õpingukorralduse küsimused== ===Küsimus A=== Kukkusid eksa…'

=Erialatutvustuse aine arvestustöö=
Autor: Hanno Sirkel<br>
Esitamise kuupäev: 30. september 2011

==Essee==

==Õ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===
Vastuse annab õppekorralduse eeskiri punktis 5.2 Eksamite ja Arvestuste Korraldus. Eksamid ja arvestused peavad olema sooritatud eksamisessiooni lõpukuupäevaks (leiab akadeemilisest kalendrist). Põhieksami lisaks on võimalik sooritada korduseksam, kuhu on tarvis registreeruda õppeosakonnas. Õppurist mitteoleneval põhjusel (haigused, surm ja muud tõsisemad ikaldused) on õppeprorektoril õigus pikendada tähtaega sügissemestril kuni kevadsemestri esimese poolsemestri eksamisessiooni lõpuni ja kevadsemestril sügissemestri alguspäevani. Kordussooritus on tasuta RE-õppekohal ning tasuline REV-õppekohal (tasu kehtestatakse rektori käskkirjaga, hetkel 13€).

===Küsimus 1===
Teisel või kolmandal õppeaastal avastad, et teine õppekava sobib paremini ja sa otsustad õppekava vahetada. Millised on tegevused ja mis ajaks need teha tuleb, et vahetada õppekava?

===Vastus===
Vastuse annab õppekorralduse eeskiri punktis 7. Akadeemiline Liikumine.
Vabade õppekohtade olemasolul on võimalik akadeemiline liikumine IT Kolledži siseselt. Akadeemiline liikumine peab olema lõpetatud semestri punase joone päevaks (kaugõppes 2011. õppeaastal 7. oktoobriks).

--Category:Erialatutvustus 2011--