__TOC__

[[Category: Võrgurakendused II: hajussüsteemide ehitamine]]
== Meeskond ja rollid ==

*'''Marko Koiduste''' - Projektijuht
*'''Jaanus Türnpuu'''
*'''Sergei Fatejev'''
*'''Kaspar Tilk'''

== Idee ==
Plaan on luua laohaldussüsteem, kus inimesed saaksid esitada tellimusi.

== Kasutatav .NET tehnoloogia ==
C#, Entity Framework, Web-API, AngularJS klientrakenduse loomiseks

== Analüüs ==
On olemas mitmed laod. Inimesed näevad lao hetkeseisu, saavad tellida neile sobivaid tooteid, peale tellimist saavad automaatselt arvet. Meie laos hoitakse erinevaid tooteid, mis on hoitud kategooriate kaupa. Meie kliendid saavad teha meie süsteemis kasutajaid, erinevate rollidega, hallata neid, muuta andmeid. Igal meie töötajal on erinevate õigustega kasutaja, olenevalt tööpositsioonist. Kõikidest tellimustest ja kasutajategevustest on olemas ajalugu (logid), mille alusel saavad kliendid näha kõige populaarsemaid tooteid ning ka töötajad saaksid prognoosida, mis tooteid oleks vaja rohkem tellida ning milliseid vähem.

Rühma projektiks on lüüa laohaldussüsteem, mida on võimalik erinevatele ladudele rakendada st tehakse mitmeid üldistusi. Kliendid saavad näha laoseisu ning peale sobivate toodete tellimist saavad nad automaatselt genereeritud arve. Laos olevad tooted on jaotatud kategooriate kaupa. Rakenduse kasutajatele on võimalik määrata erinevaid rolle, rollid on seotud õigustega - näiteks admin saab hallata kõiki kasutajaid, muuta nende andmeid ning süsteemi uusi kasutajaid lisata. Tava kasutaja saab aga ainult tellimusi vormistada. Olulisel kohal on ka logifailid, proovime logides hoida kõiki kasutajate ja lao haldusega seotud toiminguid - uute kasutajate loomisi, andmete muutmisi jne. Toodete logid on olulised, et saaks prognoosida, millist kaupa tellida .. kõige aktiivsemad/tellitumad kaubad proovime välja tuua, et oleks kohe näha, mille järgi turul suur nõudlus on.

'''TAILOR PLESSS'''

== Rakenduse sisu ==

'''Rakenduses on olemas järgmised võimalused (Must have):'''

*1. Kasutajate registreerimise süsteem
*2. Kasutajate haldussüsteem
*3. Sisse logimine
*4. Laoseisu jälgimine
*5. Kaupade tellimine
*6. Kauba nimekiri erinevates ladudes
*7. Tehtud tellimuste vaatamine

'''Rakenduses võiksid olla lisavõimalused (Could have):'''
*1. Tehtud tellimuste muutmine
*2. Laoseisu analüüs - prognoosid
*3. Populaarseimate toodete list

== Andmebaasiskeem ==
[[File:StoreItAB.png|1200px]]

== XML osa ==
XML-is hoitakse infot arvete kohta. Arvel on muuhulgas arve number, koostaja, tellija, tellitud tooted koos hindadega, arve koostanud ettevõtte juriidiline info, kuupäevad jne.
XSLT-fail loob etteantud XML-failist arved, mida ka inimene suudab lugeda ja mõista.
=== XML Fail ===
<pre>
<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet type="text/xsl" href="Arved.xslt" ?>
<arved>
<arve number="1337420" kuupäev="20.03.2016">
<koostaja eesnimi="Kaspar" perenimi="Tilk">
<kontaktandmed>
<kontakt väärtus="kaspar.tilk" tüüp="Skype"/>
<kontakt väärtus="53542343" tüüp="telefon"/>
</kontaktandmed>
</koostaja>
<tellija eesnimi="Mait" perenimi="Poska"/>
<tarneviis nimetus="kuller">
<tarnija nimi="DPD"/>
</tarneviis>
<tellitudTooted>
<toode nimi="banaan" kogus="2" ühik="kg" kategooria="puuvili" aktiivne="true">
<tavahind väärtus="2" valuuta="€"/>
<soodushind väärtus="1.50" valuuta="€"/>
<kirjeldus><![CDATA[toores banaan]]></kirjeldus>
</toode>
<toode nimi="õun" kogus="3" ühik="kg" kategooria="puuvili" aktiivne="true">
<tavahind väärtus="1" valuuta="€"/>
<soodushind väärtus="0.50" valuuta="€"/>
<kirjeldus><![CDATA[hapu õun]]></kirjeldus>
</toode>
</tellitudTooted>
<käibemaksumäär väärtus="0%"/>
<summad>
<käibemaksuta väärtus="3" valuuta="€"/>
<käibemaksuga väärtus="3" valuuta="€"/>
</summad>
<juriidilineInfo ettevõtteNimi="OÜ Puuvili" registrikood="420666" aadress="Keki tn, Keila">
<pangakontod>
<pangakonto pangaNimi="Swedbank" kontonr="EE12345678"/>
<pangakonto pangaNimi="SEB" kontonr="EE87654321"/>
</pangakontod>
<kontaktandmed>
<kontakt väärtus="puu@vili.ee" tüüp="E-mail"/>
<kontakt väärtus="531337" tüüp="Telefon"/>
</kontaktandmed>
</juriidilineInfo>
<lisainfo><![CDATA[Täname tellimuse eest!]]></lisainfo>
<tähtaeg kuupäev="21.03.2016"/>
</arve>

<arve number="1337420" kuupäev="20.03.2016">
<koostaja eesnimi="Kaspar" perenimi="Tilk">
<kontaktandmed>
<kontakt väärtus="kaspar.tilk" tüüp="Skype"/>
<kontakt väärtus="53542343" tüüp="Telefon"/>
</kontaktandmed>
</koostaja>
<tellija eesnimi="Andres" perenimi="Käver"/>
<tarneviis nimetus="kuller">
<tarnija nimi="DPD"/>
</tarneviis>
<tellitudTooted>
<toode nimi="banaan" kogus="2" ühik="kg" kategooria="puuvili" aktiivne="true">
<tavahind väärtus="2" valuuta="€"/>
<soodushind väärtus="1.50" valuuta="€"/>
<kirjeldus><![CDATA[toores banaan]]></kirjeldus>
</toode>
<toode nimi="õun" kogus="3" ühik="kg" kategooria="puuvili" aktiivne="true">
<tavahind väärtus="1" valuuta="€"/>
<soodushind väärtus="0.50" valuuta="€"/>
<kirjeldus><![CDATA[hapu õun]]></kirjeldus>
</toode>
</tellitudTooted>
<käibemaksumäär väärtus="0%"/>
<summad>
<käibemaksuta väärtus="3" valuuta="€"/>
<käibemaksuga väärtus="3" valuuta="€"/>
</summad>
<juriidilineInfo ettevõtteNimi="OÜ Puuvili" registrikood="420666" aadress="Keki tn, Keila">
<pangakontod>
<pangakonto pangaNimi="Swedbank" kontonr="EE12345678"/>
<pangakonto pangaNimi="SEB" kontonr="EE87654321"/>
</pangakontod>
<kontaktandmed>
<kontakt väärtus="puu@vili.ee" tüüp="E-mail"/>
<kontakt väärtus="531337" tüüp="telefon"/>
</kontaktandmed>
</juriidilineInfo>
<lisainfo><![CDATA[Täname tellimuse eest!]]></lisainfo>
<tähtaeg kuupäev="21.03.2016"/>
</arve>
</arved>
</pre>

=== XML Skeemifail ===
<pre>
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="arved">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="128" name="arve">
<xs:complexType>
<xs:sequence>
<xs:element name="koostaja">
<xs:complexType>
<xs:sequence>
<xs:element name="kontaktandmed">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="16" name="kontakt">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:string" use="required" />
<xs:attribute name="tüüp" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="eesnimi" type="xs:string" use="required" />
<xs:attribute name="perenimi" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="tellija">
<xs:complexType>
<xs:attribute name="eesnimi" type="xs:string" use="required" />
<xs:attribute name="perenimi" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="tarneviis">
<xs:complexType>
<xs:sequence>
<xs:element name="tarnija">
<xs:complexType>
<xs:attribute name="nimi" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="nimetus" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="tellitudTooted">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="128" name="toode">
<xs:complexType>
<xs:sequence>
<xs:element name="tavahind">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:decimal" use="required" />
<xs:attribute name="valuuta" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="soodushind">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:decimal" />
<xs:attribute name="valuuta" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="kirjeldus" type="xs:string" />
</xs:sequence>
<xs:attribute name="nimi" type="xs:string" use="required" />
<xs:attribute name="kogus" type="xs:unsignedByte" use="required" />
<xs:attribute name="ühik" type="xs:string" use="required" />
<xs:attribute name="kategooria" type="xs:string" />
<xs:attribute name="aktiivne" type="xs:boolean" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="käibemaksumäär">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="summad">
<xs:complexType>
<xs:sequence>
<xs:element name="käibemaksuta">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:decimal" use="required" />
<xs:attribute name="valuuta" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="käibemaksuga">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:decimal" use="required" />
<xs:attribute name="valuuta" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="juriidilineInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="pangakontod">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="32" name="pangakonto">
<xs:complexType>
<xs:attribute name="pangaNimi" type="xs:string" use="required" />
<xs:attribute name="kontonr" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="kontaktandmed">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="32" name="kontakt">
<xs:complexType>
<xs:attribute name="väärtus" type="xs:string" use="required" />
<xs:attribute name="tüüp" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="ettevõtteNimi" type="xs:string" use="required" />
<xs:attribute name="registrikood" type="xs:unsignedInt" use="required" />
<xs:attribute name="aadress" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="lisainfo" type="xs:string" />
<xs:element name="tähtaeg">
<xs:complexType>
<xs:attribute name="kuupäev" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="number" type="xs:unsignedInt" use="required" />
<xs:attribute name="kuupäev" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</pre>

=== XSLT ===
<pre>
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
<xsl:output method="html" indent="yes"/>

<xsl:template match="/">
<html>
<head>
<title>Arved</title>
</head>
<body>
<xsl:for-each select="/arved/arve">
<div>

Arve nr <xsl:value-of select="@number"/> Koostatud <xsl:value-of select="@kuupäev"/>


Koostaja: <xsl:value-of select="koostaja/@eesnimi"/><xsl:value-of select="koostaja/@perenimi"/>
<ul>
<xsl:for-each select="./koostaja/kontaktandmed/kontakt">
<li>
<xsl:value-of select="@tüüp"/>: <xsl:value-of select="@väärtus"/>
</li>
</xsl:for-each>
</ul>


Tellija: <xsl:value-of select="./tellija/@eesnimi"/> <xsl:value-of select="./tellija/@perenimi"/>

<table border="1" cellpadding="4" cellspacing="0">
<tr>
<th>Toote nimetus</th>
<th>Kogus</th>
<th>Ühik</th>
<th>Hind</th>
</tr>
<xsl:for-each select="./tellitudTooted/toode">
<tr align="center">
<td>
<xsl:value-of select="@nimi"/>
</td>
<td>
<xsl:value-of select="@kogus"/>
</td>
<td>
<xsl:value-of select="@ühik"/>
</td>
<td>
<xsl:value-of select="./tavahind/@väärtus"/><xsl:value-of select="./tavahind/@valuuta"/>
</td>
</tr>
</xsl:for-each>
<tr>
<td colspan="3" align="right">
Summa käibemaksuta:
</td>
<td colspan="1" align="center">
<xsl:value-of select="./summad/käibemaksuta/@väärtus"/><xsl:value-of select="./summad/käibemaksuta/@valuuta"/>
</td>
</tr>
<tr>
<td colspan="3" align="right">
Käibemaksumäär:
</td>
<td colspan="1" align="center">
<xsl:value-of select="./käibemaksumäär/@väärtus"/>
</td>
</tr>
<tr>
<td colspan="3" align="right">
Summa käibemaksuga:
</td>
<td colspan="1" align="center">
<xsl:value-of select="./summad/käibemaksuga/@väärtus"/><xsl:value-of select="./summad/käibemaksuga/@valuuta"/>
</td>
</tr>
</table>

Juriidiline info
<xsl:variable name="info" select="./juriidilineInfo"/>
 
Ettevõte: <xsl:value-of select="$info/@ettevõtteNimi"/>
 
Aadress: <xsl:value-of select="$info/@aadress"/>
 
Registrikood: <xsl:value-of select="$info/@registrikood"/>
 
<xsl:for-each select="$info/pangakontod/pangakonto">
<xsl:value-of select="@pangaNimi"/>: <xsl:value-of select="@kontonr"/>
 
</xsl:for-each>
<xsl:for-each select="$info/kontaktandmed/kontakt">
<xsl:value-of select="@tüüp"/>: <xsl:value-of select="@väärtus"/>
 
</xsl:for-each>


Maksetähtaeg: 
<xsl:value-of select="./tähtaeg/@kuupäev"/>

 
<xsl:value-of select="./lisainfo"/>

</div>
</xsl:for-each>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
</pre>
[[File:XsltPilt.png]]

== Logi ==
*20.03 - Lehe loomine ja XML osa esitamine

2016-01-28T17:07:07Z

Ktilk: /* Lõpptoote retsensioon */

Meeskond BIT teeb rakendust, millega lihtsustada ärianalüüsi nõuete haldust. Esimesena jääb silma, et visuaalne pool on eraldi välja toodud - see on väga positiivne, kuna lihtsustab rakenduse töö ettekujutamist. Visuaalse poole kirjeldus näitab ka seda, et rakenduse funktsioone on rohkem süviti arutatud, et oskaks erinevaid vaateid välja tuua.

Kahjuks muutub edasine pilt segasemaks. Esimesena tekib küsimus selles osas, kellele on antud rakendus mõeldud. Sellest, kes on rakenduse kasutaja, sõltub kõik edasine. Kui kasutajaks on ka äriosapool, muutub programmi eesmärk ja kasutamine tugevalt, kuna ei saa eeldada, et äriklient tajub kasutajalugude tausta ja oskab neid õigesti kirja panna või vastavalt vajadusele kommenteerida. See töö peaks siiski jääma pigem analüütikule. Ehk oleks mõttekam programmi nõnda teha, et põhikasutaja on analüütik, kes saab äriosapooltega kokku, kaardistab olukorra ja lisab kasutajalood. Edasi saab teha koostööd programmeerijatega, et olla kindel, et kõik kasutajalugudest samamoodi aru saavad.

Äridomeeni mudel tekitab samuti küsimusi. Kasutuslugu ja kasutuslugu_sisu on mõlemad seotud olekuga - see tundub üleliigne, kuna ilmselt ei saa nõnda olla, et sisu olek on "valmis" ja kasutusloo olek seda pole. Lisaks peaks nende tabelite puhul ilmselt tegu olema sama asjaga, kuna kasutuslool on sisu juba olemas - jääb segaseks, milleks on seda vaja eraldi tabelina välja tuua.

Lisaks pole kindel, kas meeskond on täpselt aru saanud user story ja user case'i sisust - tasub lugeda lisa näiteks Business Analysti artiklist www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html.

Rakenduse idee on hea, aga realisatsioon jääb praegusel hetkel veel segaseks. Aitaks see, kui kasutaja täpsemalt defineerida ja kindlaks teha, et rakenduse võimalused vastavad selle kasutaja võimalustele ja oskustele (pole mõtet klienti programmeerimise taustinfoga segadusse ajada, neilt peab info kätte saama vastavate oskustega isik).

''Retsenseeris PenguinHorde.''

== Lõpptoote retsensioon meeskonnalt Incman ==

Meeskonnal BIT on valminud kena programm erinevate projektide haldamiseks. Meeskonnaliikmed on suutnud kõik endale püstitatud ''must have'' eesmärgid edukalt täitnud. ''Nice to have'' funktsionaalsused said ilmselt natuke liiga optimistlikud.

Mis oli hästi:
*Rakendus avaneb .exe failist ning puudub vajadus eraldi andmebaasi loomiseks.
*Visuaalselt on rakendus ilus ja puhas, info on konkreetselt kuvatud.
*PDFi tegemine on väga lahe funktsionaalsus.
*Rakenduse kood on ilusti kihtideks jaotatud.
*Kenasti on jälgitud MVVM arendusmustrit.
*Kood on puhas ja jälgitav ning meetodid on dokumenteeritud.

Märkused:
*Veidi tüütud on aknad, mis peale uue projekti lisamist ja muutmist ette hüppavad. Kasutaja tagasiside võiks toimuda näiteks vaate sees.
*Projekti teemade ja eesmärkide muutmise vaatest ei saa tagasi projektivaatesse -> võiks olla nupp "Tagasi" nagu projekti lisamise vaatel.
*Pealehele minek on millegipärast väga aeglane(ilmselt andmepäringute tõttu?).
*Kasutajaloo lisamisel rakendus sulgub, kui proovida ilma teemata lisada. Võiks anda tagasisidet.

Valminud on minimalistlik ja visuaalselt kena rakendus, milles on kõik planeeritud funktsionaalsused olemas. Programmikood on väga hästi loetav ja arusaadav(enamjaolt ka dokumenteeritud). Täiendada saaks veel ''quality of life'' uuendustega ning rakenduse kiiremaks tegemisega.

Talk:BIT

2016-01-28T16:29:39Z

Ktilk: /* Lõpptoote retsensioon */ new section

Incman

2016-01-28T08:19:26Z

Ktilk: /* Viited programmile */

[[Category:Programmeerimine CSharp keeles]]

'''Meeskonna nimi: IncMan'''
=Projekt=

Tööjuhtumite (intsidentide) haldus- ja teavitussüsteem.

=Meeskonna koosseis=

*Sergei Fatejev
*Marko Koiduste
*Kaspar Tilk
*Jaanus Türnpuu

Projektijuht: Marko Koiduste

=Projektist=

==Ülevaade==
Rakendus on loodud intsidentide haldamiseks. Rakenduse peaeesmärk on lihtsustada ja kiirendada intsidendihaldust ning tulevikus võimaldada ülevaadet intsidentidest, probleemidest ning nendega seotud statistikast. Intsidendihaldus on oluline osa tagamaks ja säilitamaks teenuste kvaliteeti.

Rakenduse põhiobjektideks on '''kasutaja''' ja '''intsident'''. Rakenduse kasutajaliidesel on mitu vaadet, mis sõltub vastava kasutaja vastavatest õigustest. Rakendus vajab andmebaasi olemasolu. Rakendus jaotub nelja kihti: ''Data Access Layer, Business Logic Layer, Service Layer, Presentation Layer''.

== Kasutatav .NET tehnoloogia ==

Kasutatav raamistik: .NET Framework 4.5

Kasutatav tehnoloogia: C#, Windows Presentation Foundation, Entity Framework, LINQ

==Täpsemalt rakenduse tööst==

'''Kasutaja''' 
Kasutajaid saab luua admin ja juht tüüpi kasutaja. Teisi kasutajaid saavad hallata vaid admin ning juht. Iga kasutaja saab muuta enda andmeid ning parooli. Kasutaja õigused seome kasutajaga kasutaja-tüüp olemi kaudu. Igal isikul on maksimaalselt üks kasutaja, seega iga kasutajaga on seotud ühed andmed. Kasutaja näeb pooleliolevaid intsidente, saab neid muuta ning enda loodud intsidente sulgeda. Lisaks on kasutajal võimalus sorteerida käimasolevaid intsidente näiteks tähtsuse, kuupäeva, omaniku, intsidenditüübi jne järgi. Tavakasutaja saab muuta teiste kasutajate poolt loodud intsidente, kuid sulgemisõigus on ainult intsidendi loojal ehk omanikul ning tema ülemusel ehk juhil.

'''Intsident''' 
Intsidente saavad luue kõik kasutajad. Intsidenti saavad hallata kõik kasutajad. Intsidendi omanikuks määratakse kasutaja, kes selle lõi. Intsidenti saab sulgeda ning arhiveerida omanik ning tema juht(admin saab seda kõike teha).

'''Kasutajaliides''' 
Kasutajaliidese loomine on rakenduse loomise viimane samm enne lõplikku testimist. Kasutajaliidese loome WPF raamistikus. Kasutajaliides peab olema tagasihoidlik ja viisakas. Kasutajaliides võiks olla kasutajasõbralik, näidata kasutajale ette formaati, õpetada ning suunata. (Näiteks viies hiire mõne nupu kohale selgitab, mida nupp teeb).
Kasutajaliides kuvab statistikat, logisid, haldamata/hallatud intsidente.
Andmebaas
Andmebaasis hoiame esialgu kasutajaid, intsidente, logisid ja arhiivi. Tulevikus peaks arhiivi jaoks olema eraldi andmebaas, kuid meie projekti loomise ning testimise perioodil pole see oluline.

'''Data Access Layer''' 
Rakenduse kiht, kus luuakse ühendus andmebaasiga.

'''Business Logic Layer''' 
Äriloogika kiht. Siin defineerime objektid.

'''Service Layer''' 
Rakenduse kiht.

'''Presentation Layer''' 
Kasutajaliidese kiht.

==Planeeritavad funktsionaalsused==
; Kasutajate haldus

* Kasutaja loomine

Kasutaja loomise juures luuakse ka isik. Kuhu lisanduvad antud kasutajaga seotud isiku andmed. Neid võib minna vaja teavituste juures ja kontakti saamiseks.

* Kasutaja muutmine

Kasutajat saab muuta tema peremeeskasutaja(ehk juht) või tema ise. Kasutaja andmete muutmise kohta on logi, kus näeb, millal mida muudeti. Kõik muudatused säilitakse kujul “väli”:“enne” => “pärast” | “aeg”. Välja arvatud parool.

* Kasutaja arhiveermine

Kui kasutaja on märgitud ebaaktiivset kasutajat on võimalik arhiveerida. Arhiveerida saab kasutajat vaid tema peremeeskasutaja. Selline asi on välistatud, et kasutaja arhiveerib end ise.

; Intsidentide haldus(peamine funktsionaalsus)

* Intsidendi loomine

Intsidendi loomisel määratakse omanikuks intsidenti loov kasutaja. Omanik ning omaniku juht(ja admin) on ainsad, kes saavad intsidenti lõppenuks kuulutada(sulgeda).

* Intsidendi muutmine

Kõik intsidentidega seonduvad tegevused peavad kajastuma logides. Ka Intsidendi loomine kajastub muutmisena. Muutmine peab olema säilitatud kujul “väli”: “enne” => “pärast” | “aeg”, sarnaselt kasutaja muutmisele.

* Intsidendi arhiveerimine

; Monitooring

* Käimasolevad intsidendid

Monitooringu eesmärk on kajastada käimasolevaid intsidente. Et saaks neid jälgida, kiirelt nende juurde pääseda ning anda võimalus kasutajale neid muuta.

; Logid

* Kasutajalogid

Logid kasutaja tegevuse kohta seoses enda või oma alamkasutajatega. Kasutaja peaks nägema logisid enda tegevusest ning endale alluvate kasutaja tegevusest.

* Intsidendilogid

Intsidendiga seotud logid. Peab olema näha, kes lõi intsidendi, ehk kes on omanik. Peab nägema kõiki muudatusi. Logid säilitatakse koos intsidendiga.

'''''Nice to have'' ehk kui aega üle'''
* Arenduslogid (Uuendused, parandused)
Logid admini tegevuse kohta seoses programmi uuendamise, parandamise kohta. Niiütelda “uudis” formaadis, et kasutajad teaksid, mis on muudetud ja kuidas mingi uus funktsioon töötab.
* Andmebaasiserveri monitooring
Luua lihtne monitooring andmebaasile, et jälgida tema mahte, töökoormust. Andmebaasi monitooring peaks andma alerti, kui andmebaas on täis saamas või on üle koormatud(mingil x põhjusel)

=Meeskonna LetsDoIt analüüsi retsensioon=
Meeskonna LetsDoIt analüüs on lihtsasti mõistetav ning ülevaatlik sellest kuidas nende poolt arendatav rakendus toimima hakkab. On välja toodud must-have võimalused, kuid ka nice-to-have võimalused, mis rakendust veelgi paremaks teeksid. Positiivse poole pealt saab veel lisada, et meeskond on juba mõelnud, kuidas rakenduse andmebaas reaalselt välja nägema hakkab ning on teinud ka vastava joonise.

Uurides antud ERD andmebaasimudelit, leidsime sealt mitmed puudused, mis süsteemi realiseerimisel võivad probleeme tekitada. Mitmes kohas võiks üks - üks, mitmele seose asemel olla üks - null, üks või mitmele seos. Näiteks kontakti ja kontakti liigi, veretüübi ja kasutaja vahel. Süsteemis ei ole kindlasti kohe algusest peale olemas kasutajaid iga eksisteeriva veretüübiga. Kasutaja rolli seoses võiks olla märgitud ka seose alguse ja lõpu kuupäevad, et saaks ülevaate ajaloost. Skeemi puuduseks on veel asjaolu, et näiteks medõde või arst ei saa ise doonoriks olla. Samuti võiks mudelis olla kirjas inimene, kes verd võttis.

Esialgsest tekstist jääb segaseks ka asjaolu, kes seda süsteemi haldama hakkab ning kuidas kasutajad sisse hakkavad logima. Kuna käsitletakse delikaatseid inimeste andmeid (terviseinfo), siis võiks mõelda ka andmebaasi turvalisusele ehk kasutada andmebaasis mingit sorti krüpteerimist. Lisaks eelnevale võiks 0-tüüpi vere annetamise järel automaatselt saata haiglatele kirja, et selline veri on lattu tekkinud, kuna teadupärast 0-tüüpi veri sobib kõigile ja on väga nõutud, eriti kriisiolukordades. Disainimisel ja parema üldpildi saamiseks, võiks meeskond uurida ka Eestis reaalselt toimivat samalaadset lahendust - www.verekeskus.ee ja www.kliinikum.ee/verekeskus/. Üldjoontes võib öelda, et tegu on asjakohase rakendusega, mis võib ka reaalses elus kasutust leida. Lõpetuseks soovime edu meeskonnale oma ideede realiseerimisel.

=Viited programmile=
Prototüüp -> http://www.upload.ee/files/5400645/Incmanwpf.rar.html
 
Lõpptoode -> https://drive.google.com/file/d/0B7qVxpU1IkLTUnpXaS1OX29qMzQ/view?usp=sharing
[[Category:Programmeerimine CSharp keeles]]

Incman

2016-01-28T08:18:15Z

Ktilk: /* Viited programmile */

[[Category:Programmeerimine CSharp keeles]]

'''Meeskonna nimi: IncMan'''
=Projekt=

Tööjuhtumite (intsidentide) haldus- ja teavitussüsteem.

=Meeskonna koosseis=

*Sergei Fatejev
*Marko Koiduste
*Kaspar Tilk
*Jaanus Türnpuu

Projektijuht: Marko Koiduste

=Projektist=

==Ülevaade==
Rakendus on loodud intsidentide haldamiseks. Rakenduse peaeesmärk on lihtsustada ja kiirendada intsidendihaldust ning tulevikus võimaldada ülevaadet intsidentidest, probleemidest ning nendega seotud statistikast. Intsidendihaldus on oluline osa tagamaks ja säilitamaks teenuste kvaliteeti.

Rakenduse põhiobjektideks on '''kasutaja''' ja '''intsident'''. Rakenduse kasutajaliidesel on mitu vaadet, mis sõltub vastava kasutaja vastavatest õigustest. Rakendus vajab andmebaasi olemasolu. Rakendus jaotub nelja kihti: ''Data Access Layer, Business Logic Layer, Service Layer, Presentation Layer''.

== Kasutatav .NET tehnoloogia ==

Kasutatav raamistik: .NET Framework 4.5

Kasutatav tehnoloogia: C#, Windows Presentation Foundation, Entity Framework, LINQ

==Täpsemalt rakenduse tööst==

'''Kasutaja''' 
Kasutajaid saab luua admin ja juht tüüpi kasutaja. Teisi kasutajaid saavad hallata vaid admin ning juht. Iga kasutaja saab muuta enda andmeid ning parooli. Kasutaja õigused seome kasutajaga kasutaja-tüüp olemi kaudu. Igal isikul on maksimaalselt üks kasutaja, seega iga kasutajaga on seotud ühed andmed. Kasutaja näeb pooleliolevaid intsidente, saab neid muuta ning enda loodud intsidente sulgeda. Lisaks on kasutajal võimalus sorteerida käimasolevaid intsidente näiteks tähtsuse, kuupäeva, omaniku, intsidenditüübi jne järgi. Tavakasutaja saab muuta teiste kasutajate poolt loodud intsidente, kuid sulgemisõigus on ainult intsidendi loojal ehk omanikul ning tema ülemusel ehk juhil.

'''Intsident''' 
Intsidente saavad luue kõik kasutajad. Intsidenti saavad hallata kõik kasutajad. Intsidendi omanikuks määratakse kasutaja, kes selle lõi. Intsidenti saab sulgeda ning arhiveerida omanik ning tema juht(admin saab seda kõike teha).

'''Kasutajaliides''' 
Kasutajaliidese loomine on rakenduse loomise viimane samm enne lõplikku testimist. Kasutajaliidese loome WPF raamistikus. Kasutajaliides peab olema tagasihoidlik ja viisakas. Kasutajaliides võiks olla kasutajasõbralik, näidata kasutajale ette formaati, õpetada ning suunata. (Näiteks viies hiire mõne nupu kohale selgitab, mida nupp teeb).
Kasutajaliides kuvab statistikat, logisid, haldamata/hallatud intsidente.
Andmebaas
Andmebaasis hoiame esialgu kasutajaid, intsidente, logisid ja arhiivi. Tulevikus peaks arhiivi jaoks olema eraldi andmebaas, kuid meie projekti loomise ning testimise perioodil pole see oluline.

'''Data Access Layer''' 
Rakenduse kiht, kus luuakse ühendus andmebaasiga.

'''Business Logic Layer''' 
Äriloogika kiht. Siin defineerime objektid.

'''Service Layer''' 
Rakenduse kiht.

'''Presentation Layer''' 
Kasutajaliidese kiht.

==Planeeritavad funktsionaalsused==
; Kasutajate haldus

* Kasutaja loomine

Kasutaja loomise juures luuakse ka isik. Kuhu lisanduvad antud kasutajaga seotud isiku andmed. Neid võib minna vaja teavituste juures ja kontakti saamiseks.

* Kasutaja muutmine

Kasutajat saab muuta tema peremeeskasutaja(ehk juht) või tema ise. Kasutaja andmete muutmise kohta on logi, kus näeb, millal mida muudeti. Kõik muudatused säilitakse kujul “väli”:“enne” => “pärast” | “aeg”. Välja arvatud parool.

* Kasutaja arhiveermine

Kui kasutaja on märgitud ebaaktiivset kasutajat on võimalik arhiveerida. Arhiveerida saab kasutajat vaid tema peremeeskasutaja. Selline asi on välistatud, et kasutaja arhiveerib end ise.

; Intsidentide haldus(peamine funktsionaalsus)

* Intsidendi loomine

Intsidendi loomisel määratakse omanikuks intsidenti loov kasutaja. Omanik ning omaniku juht(ja admin) on ainsad, kes saavad intsidenti lõppenuks kuulutada(sulgeda).

* Intsidendi muutmine

Kõik intsidentidega seonduvad tegevused peavad kajastuma logides. Ka Intsidendi loomine kajastub muutmisena. Muutmine peab olema säilitatud kujul “väli”: “enne” => “pärast” | “aeg”, sarnaselt kasutaja muutmisele.

* Intsidendi arhiveerimine

; Monitooring

* Käimasolevad intsidendid

Monitooringu eesmärk on kajastada käimasolevaid intsidente. Et saaks neid jälgida, kiirelt nende juurde pääseda ning anda võimalus kasutajale neid muuta.

; Logid

* Kasutajalogid

Logid kasutaja tegevuse kohta seoses enda või oma alamkasutajatega. Kasutaja peaks nägema logisid enda tegevusest ning endale alluvate kasutaja tegevusest.

* Intsidendilogid

Intsidendiga seotud logid. Peab olema näha, kes lõi intsidendi, ehk kes on omanik. Peab nägema kõiki muudatusi. Logid säilitatakse koos intsidendiga.

'''''Nice to have'' ehk kui aega üle'''
* Arenduslogid (Uuendused, parandused)
Logid admini tegevuse kohta seoses programmi uuendamise, parandamise kohta. Niiütelda “uudis” formaadis, et kasutajad teaksid, mis on muudetud ja kuidas mingi uus funktsioon töötab.
* Andmebaasiserveri monitooring
Luua lihtne monitooring andmebaasile, et jälgida tema mahte, töökoormust. Andmebaasi monitooring peaks andma alerti, kui andmebaas on täis saamas või on üle koormatud(mingil x põhjusel)

=Meeskonna LetsDoIt analüüsi retsensioon=
Meeskonna LetsDoIt analüüs on lihtsasti mõistetav ning ülevaatlik sellest kuidas nende poolt arendatav rakendus toimima hakkab. On välja toodud must-have võimalused, kuid ka nice-to-have võimalused, mis rakendust veelgi paremaks teeksid. Positiivse poole pealt saab veel lisada, et meeskond on juba mõelnud, kuidas rakenduse andmebaas reaalselt välja nägema hakkab ning on teinud ka vastava joonise.

Uurides antud ERD andmebaasimudelit, leidsime sealt mitmed puudused, mis süsteemi realiseerimisel võivad probleeme tekitada. Mitmes kohas võiks üks - üks, mitmele seose asemel olla üks - null, üks või mitmele seos. Näiteks kontakti ja kontakti liigi, veretüübi ja kasutaja vahel. Süsteemis ei ole kindlasti kohe algusest peale olemas kasutajaid iga eksisteeriva veretüübiga. Kasutaja rolli seoses võiks olla märgitud ka seose alguse ja lõpu kuupäevad, et saaks ülevaate ajaloost. Skeemi puuduseks on veel asjaolu, et näiteks medõde või arst ei saa ise doonoriks olla. Samuti võiks mudelis olla kirjas inimene, kes verd võttis.

Esialgsest tekstist jääb segaseks ka asjaolu, kes seda süsteemi haldama hakkab ning kuidas kasutajad sisse hakkavad logima. Kuna käsitletakse delikaatseid inimeste andmeid (terviseinfo), siis võiks mõelda ka andmebaasi turvalisusele ehk kasutada andmebaasis mingit sorti krüpteerimist. Lisaks eelnevale võiks 0-tüüpi vere annetamise järel automaatselt saata haiglatele kirja, et selline veri on lattu tekkinud, kuna teadupärast 0-tüüpi veri sobib kõigile ja on väga nõutud, eriti kriisiolukordades. Disainimisel ja parema üldpildi saamiseks, võiks meeskond uurida ka Eestis reaalselt toimivat samalaadset lahendust - www.verekeskus.ee ja www.kliinikum.ee/verekeskus/. Üldjoontes võib öelda, et tegu on asjakohase rakendusega, mis võib ka reaalses elus kasutust leida. Lõpetuseks soovime edu meeskonnale oma ideede realiseerimisel.

=Viited programmile=
Prototüüp -> http://www.upload.ee/files/5400645/Incmanwpf.rar.html

Lõpptoode -> https://drive.google.com/file/d/0B7qVxpU1IkLTUnpXaS1OX29qMzQ/view?usp=sharing
[[Category:Programmeerimine CSharp keeles]]

Incman

2016-01-28T08:17:55Z

Ktilk: /* Prototüübi allalaadimise link */

[[Category:Programmeerimine CSharp keeles]]

'''Meeskonna nimi: IncMan'''
=Projekt=

Tööjuhtumite (intsidentide) haldus- ja teavitussüsteem.

=Meeskonna koosseis=

*Sergei Fatejev
*Marko Koiduste
*Kaspar Tilk
*Jaanus Türnpuu

Projektijuht: Marko Koiduste

=Projektist=

==Ülevaade==
Rakendus on loodud intsidentide haldamiseks. Rakenduse peaeesmärk on lihtsustada ja kiirendada intsidendihaldust ning tulevikus võimaldada ülevaadet intsidentidest, probleemidest ning nendega seotud statistikast. Intsidendihaldus on oluline osa tagamaks ja säilitamaks teenuste kvaliteeti.

Rakenduse põhiobjektideks on '''kasutaja''' ja '''intsident'''. Rakenduse kasutajaliidesel on mitu vaadet, mis sõltub vastava kasutaja vastavatest õigustest. Rakendus vajab andmebaasi olemasolu. Rakendus jaotub nelja kihti: ''Data Access Layer, Business Logic Layer, Service Layer, Presentation Layer''.

== Kasutatav .NET tehnoloogia ==

Kasutatav raamistik: .NET Framework 4.5

Kasutatav tehnoloogia: C#, Windows Presentation Foundation, Entity Framework, LINQ

==Täpsemalt rakenduse tööst==

'''Kasutaja''' 
Kasutajaid saab luua admin ja juht tüüpi kasutaja. Teisi kasutajaid saavad hallata vaid admin ning juht. Iga kasutaja saab muuta enda andmeid ning parooli. Kasutaja õigused seome kasutajaga kasutaja-tüüp olemi kaudu. Igal isikul on maksimaalselt üks kasutaja, seega iga kasutajaga on seotud ühed andmed. Kasutaja näeb pooleliolevaid intsidente, saab neid muuta ning enda loodud intsidente sulgeda. Lisaks on kasutajal võimalus sorteerida käimasolevaid intsidente näiteks tähtsuse, kuupäeva, omaniku, intsidenditüübi jne järgi. Tavakasutaja saab muuta teiste kasutajate poolt loodud intsidente, kuid sulgemisõigus on ainult intsidendi loojal ehk omanikul ning tema ülemusel ehk juhil.

'''Intsident''' 
Intsidente saavad luue kõik kasutajad. Intsidenti saavad hallata kõik kasutajad. Intsidendi omanikuks määratakse kasutaja, kes selle lõi. Intsidenti saab sulgeda ning arhiveerida omanik ning tema juht(admin saab seda kõike teha).

'''Kasutajaliides''' 
Kasutajaliidese loomine on rakenduse loomise viimane samm enne lõplikku testimist. Kasutajaliidese loome WPF raamistikus. Kasutajaliides peab olema tagasihoidlik ja viisakas. Kasutajaliides võiks olla kasutajasõbralik, näidata kasutajale ette formaati, õpetada ning suunata. (Näiteks viies hiire mõne nupu kohale selgitab, mida nupp teeb).
Kasutajaliides kuvab statistikat, logisid, haldamata/hallatud intsidente.
Andmebaas
Andmebaasis hoiame esialgu kasutajaid, intsidente, logisid ja arhiivi. Tulevikus peaks arhiivi jaoks olema eraldi andmebaas, kuid meie projekti loomise ning testimise perioodil pole see oluline.

'''Data Access Layer''' 
Rakenduse kiht, kus luuakse ühendus andmebaasiga.

'''Business Logic Layer''' 
Äriloogika kiht. Siin defineerime objektid.

'''Service Layer''' 
Rakenduse kiht.

'''Presentation Layer''' 
Kasutajaliidese kiht.

==Planeeritavad funktsionaalsused==
; Kasutajate haldus

* Kasutaja loomine

Kasutaja loomise juures luuakse ka isik. Kuhu lisanduvad antud kasutajaga seotud isiku andmed. Neid võib minna vaja teavituste juures ja kontakti saamiseks.

* Kasutaja muutmine

Kasutajat saab muuta tema peremeeskasutaja(ehk juht) või tema ise. Kasutaja andmete muutmise kohta on logi, kus näeb, millal mida muudeti. Kõik muudatused säilitakse kujul “väli”:“enne” => “pärast” | “aeg”. Välja arvatud parool.

* Kasutaja arhiveermine

Kui kasutaja on märgitud ebaaktiivset kasutajat on võimalik arhiveerida. Arhiveerida saab kasutajat vaid tema peremeeskasutaja. Selline asi on välistatud, et kasutaja arhiveerib end ise.

; Intsidentide haldus(peamine funktsionaalsus)

* Intsidendi loomine

Intsidendi loomisel määratakse omanikuks intsidenti loov kasutaja. Omanik ning omaniku juht(ja admin) on ainsad, kes saavad intsidenti lõppenuks kuulutada(sulgeda).

* Intsidendi muutmine

Kõik intsidentidega seonduvad tegevused peavad kajastuma logides. Ka Intsidendi loomine kajastub muutmisena. Muutmine peab olema säilitatud kujul “väli”: “enne” => “pärast” | “aeg”, sarnaselt kasutaja muutmisele.

* Intsidendi arhiveerimine

; Monitooring

* Käimasolevad intsidendid

Monitooringu eesmärk on kajastada käimasolevaid intsidente. Et saaks neid jälgida, kiirelt nende juurde pääseda ning anda võimalus kasutajale neid muuta.

; Logid

* Kasutajalogid

Logid kasutaja tegevuse kohta seoses enda või oma alamkasutajatega. Kasutaja peaks nägema logisid enda tegevusest ning endale alluvate kasutaja tegevusest.

* Intsidendilogid

Intsidendiga seotud logid. Peab olema näha, kes lõi intsidendi, ehk kes on omanik. Peab nägema kõiki muudatusi. Logid säilitatakse koos intsidendiga.

'''''Nice to have'' ehk kui aega üle'''
* Arenduslogid (Uuendused, parandused)
Logid admini tegevuse kohta seoses programmi uuendamise, parandamise kohta. Niiütelda “uudis” formaadis, et kasutajad teaksid, mis on muudetud ja kuidas mingi uus funktsioon töötab.
* Andmebaasiserveri monitooring
Luua lihtne monitooring andmebaasile, et jälgida tema mahte, töökoormust. Andmebaasi monitooring peaks andma alerti, kui andmebaas on täis saamas või on üle koormatud(mingil x põhjusel)

=Meeskonna LetsDoIt analüüsi retsensioon=
Meeskonna LetsDoIt analüüs on lihtsasti mõistetav ning ülevaatlik sellest kuidas nende poolt arendatav rakendus toimima hakkab. On välja toodud must-have võimalused, kuid ka nice-to-have võimalused, mis rakendust veelgi paremaks teeksid. Positiivse poole pealt saab veel lisada, et meeskond on juba mõelnud, kuidas rakenduse andmebaas reaalselt välja nägema hakkab ning on teinud ka vastava joonise.

Uurides antud ERD andmebaasimudelit, leidsime sealt mitmed puudused, mis süsteemi realiseerimisel võivad probleeme tekitada. Mitmes kohas võiks üks - üks, mitmele seose asemel olla üks - null, üks või mitmele seos. Näiteks kontakti ja kontakti liigi, veretüübi ja kasutaja vahel. Süsteemis ei ole kindlasti kohe algusest peale olemas kasutajaid iga eksisteeriva veretüübiga. Kasutaja rolli seoses võiks olla märgitud ka seose alguse ja lõpu kuupäevad, et saaks ülevaate ajaloost. Skeemi puuduseks on veel asjaolu, et näiteks medõde või arst ei saa ise doonoriks olla. Samuti võiks mudelis olla kirjas inimene, kes verd võttis.

Esialgsest tekstist jääb segaseks ka asjaolu, kes seda süsteemi haldama hakkab ning kuidas kasutajad sisse hakkavad logima. Kuna käsitletakse delikaatseid inimeste andmeid (terviseinfo), siis võiks mõelda ka andmebaasi turvalisusele ehk kasutada andmebaasis mingit sorti krüpteerimist. Lisaks eelnevale võiks 0-tüüpi vere annetamise järel automaatselt saata haiglatele kirja, et selline veri on lattu tekkinud, kuna teadupärast 0-tüüpi veri sobib kõigile ja on väga nõutud, eriti kriisiolukordades. Disainimisel ja parema üldpildi saamiseks, võiks meeskond uurida ka Eestis reaalselt toimivat samalaadset lahendust - www.verekeskus.ee ja www.kliinikum.ee/verekeskus/. Üldjoontes võib öelda, et tegu on asjakohase rakendusega, mis võib ka reaalses elus kasutust leida. Lõpetuseks soovime edu meeskonnale oma ideede realiseerimisel.

=Viited programmile=
Prototüüp -> http://www.upload.ee/files/5400645/Incmanwpf.rar.html
Lõpptoode -> https://drive.google.com/file/d/0B7qVxpU1IkLTUnpXaS1OX29qMzQ/view?usp=sharing
[[Category:Programmeerimine CSharp keeles]]

Janesekama

2015-11-02T12:46:16Z

Ktilk: Blanked the page

Incman

2015-11-01T21:42:59Z

Ktilk: /* Planeeritavad funktsionaalsused */

[[Category:Programmeerimine CSharp keeles]]

'''Meeskonna nimi: IncMan'''
=Projekt=

Tööjuhtumite (intsidentide) haldus- ja teavitussüsteem.

=Meeskonna koosseis=

*Sergei Fatejev
*Nele Sergejeva
*Marko Koiduste
*Kaspar Tilk
*Jaanus Türnpuu

Projektijuht: Marko Koiduste

=Projektist=

==Ülevaade==
Rakendus on loodud intsidentide haldamiseks. Rakenduse peaeesmärk on lihtsustada ja kiirendada intsidendihaldust ning tulevikus võimaldada ülevaadet intsidentidest, probleemidest ning nendega seotud statistikast. Intsidendihaldus on oluline osa tagamaks ja säilitamaks teenuste kvaliteeti.

Rakenduse põhiobjektideks on '''kasutaja''' ja '''intsident'''. Rakenduse kasutajaliidesel on mitu vaadet, mis sõltub vastava kasutaja vastavatest õigustest. Rakendus vajab andmebaasi olemasolu. Rakendus jaotub nelja kihti: ''Data Access Layer, Business Logic Layer, Service Layer, Presentation Layer''.

== Kasutatav .NET tehnoloogia ==

Kasutatav raamistik: .NET Framework 4.5

Kasutatav tehnoloogia: C#, Windows Presentation Foundation, Entity Framework, LINQ

==Täpsemalt rakenduse tööst==

'''Kasutaja''' 
Kasutajaid saab luua admin ja juht tüüpi kasutaja. Teisi kasutajaid saavad hallata vaid admin ning juht. Iga kasutaja saab muuta enda andmeid ning parooli. Kasutaja õigused seome kasutajaga kasutaja-tüüp olemi kaudu. Igal isikul on maksimaalselt üks kasutaja, seega iga kasutajaga on seotud ühed andmed. Kasutaja näeb pooleliolevaid intsidente, saab neid muuta ning enda loodud intsidente sulgeda. Lisaks on kasutajal võimalus sorteerida käimasolevaid intsidente näiteks tähtsuse, kuupäeva, omaniku, intsidenditüübi jne järgi. Tavakasutaja saab muuta teiste kasutajate poolt loodud intsidente, kuid sulgemisõigus on ainult intsidendi loojal ehk omanikul ning tema ülemusel ehk juhil.

'''Intsident''' 
Intsidente saavad luue kõik kasutajad. Intsidenti saavad hallata kõik kasutajad. Intsidendi omanikuks määratakse kasutaja, kes selle lõi. Intsidenti saab sulgeda ning arhiveerida omanik ning tema juht(admin saab seda kõike teha).

'''Kasutajaliides''' 
Kasutajaliidese loomine on rakenduse loomise viimane samm enne lõplikku testimist. Kasutajaliidese loome WPF raamistikus. Kasutajaliides peab olema tagasihoidlik ja viisakas. Kasutajaliides võiks olla kasutajasõbralik, näidata kasutajale ette formaati, õpetada ning suunata. (Näiteks viies hiire mõne nupu kohale selgitab, mida nupp teeb).
Kasutajaliides kuvab statistikat, logisid, haldamata/hallatud intsidente.
Andmebaas
Andmebaasis hoiame esialgu kasutajaid, intsidente, logisid ja arhiivi. Tulevikus peaks arhiivi jaoks olema eraldi andmebaas, kuid meie projekti loomise ning testimise perioodil pole see oluline.

'''Data Access Layer''' 
Rakenduse kiht, kus luuakse ühendus andmebaasiga.

'''Business Logic Layer''' 
Äriloogika kiht. Siin defineerime objektid.

'''Service Layer''' 
Rakenduse kiht.

'''Presentation Layer''' 
Kasutajaliidese kiht.

==Planeeritavad funktsionaalsused==
; Kasutajate haldus

* Kasutaja loomine

Kasutaja loomise juures luuakse ka isik. Kuhu lisanduvad antud kasutajaga seotud isiku andmed. Neid võib minna vaja teavituste juures ja kontakti saamiseks.

* Kasutaja muutmine

Kasutajat saab muuta tema peremeeskasutaja(ehk juht) või tema ise. Kasutaja andmete muutmise kohta on logi, kus näeb, millal mida muudeti. Kõik muudatused säilitakse kujul “väli”:“enne” => “pärast” | “aeg”. Välja arvatud parool.

* Kasutaja arhiveermine

Kui kasutaja on märgitud ebaaktiivset kasutajat on võimalik arhiveerida. Arhiveerida saab kasutajat vaid tema peremeeskasutaja. Selline asi on välistatud, et kasutaja arhiveerib end ise.

; Intsidentide haldus(peamine funktsionaalsus)

* Intsidendi loomine

Intsidendi loomisel määratakse omanikuks intsidenti loov kasutaja. Omanik ning omaniku juht(ja admin) on ainsad, kes saavad intsidenti lõppenuks kuulutada(sulgeda).

* Intsidendi muutmine

Kõik intsidentidega seonduvad tegevused peavad kajastuma logides. Ka Intsidendi loomine kajastub muutmisena. Muutmine peab olema säilitatud kujul “väli”: “enne” => “pärast” | “aeg”, sarnaselt kasutaja muutmisele.

* Intsidendi arhiveerimine

; Monitooring

* Käimasolevad intsidendid

Monitooringu eesmärk on kajastada käimasolevaid intsidente. Et saaks neid jälgida, kiirelt nende juurde pääseda ning anda võimalus kasutajale neid muuta.

; Logid

* Kasutajalogid

Logid kasutaja tegevuse kohta seoses enda või oma alamkasutajatega. Kasutaja peaks nägema logisid enda tegevusest ning endale alluvate kasutaja tegevusest.

* Intsidendilogid

Intsidendiga seotud logid. Peab olema näha, kes lõi intsidendi, ehk kes on omanik. Peab nägema kõiki muudatusi. Logid säilitatakse koos intsidendiga.

'''''Nice to have'' ehk kui aega üle'''
* Arenduslogid (Uuendused, parandused)
Logid admini tegevuse kohta seoses programmi uuendamise, parandamise kohta. Niiütelda “uudis” formaadis, et kasutajad teaksid, mis on muudetud ja kuidas mingi uus funktsioon töötab.
* Andmebaasiserveri monitooring
Luua lihtne monitooring andmebaasile, et jälgida tema mahte, töökoormust. Andmebaasi monitooring peaks andma alerti, kui andmebaas on täis saamas või on üle koormatud(mingil x põhjusel)

[[Category:Programmeerimine CSharp keeles]]

Incman

2015-11-01T21:38:48Z

2014-10-20T13:43:14Z

Ktilk: /* Essee */

[[Category:Erialatutvustus 2014 (Päevaõpe)]]
=Erialatutvustuse aine arvestustöö=
Autor: Kaspar Tilk

Rühm: 13

Esitamise kuupäev:

==Essee==
Sissejuhatus

Loeng 1

27. augustil toimus meie esimene loeng, mille teemaks oli "Õppekorraldus ja sisekord<ref>[https://echo360.e-ope.ee/ess/echo/presentation/552b549b-da8b-48c4-9047-cf34af6e6188 Loeng: Õppekorraldus ja sisekord]</ref>" ning läbiviijateks Inga Vau, Margus Ernits ja Merle Varendi. See loeng oli väga tähtis, sest meile tutvustati koolikorda ja kooli ennast. Paljudele oli see esimene päev IT Kolledžis, kuid mõned tudengid olid juba suve lõpus matemaatika tasanduskursuse jooksul natuke kooliga tutvuda saanud. Vaatamata sellele, et ma tasanduskursuse läbisin, sain ikkagi palju uut kooli kohta teada. Samuti räägiti, mis me lähipäevil tegema peame hakkama, näiteks "punase joone päevaga" seoses, ning tutvustati infoallikaid, kust üliõpilased ise saavad õppekorralduse kohta uurida. Minu jaoks oli esimene loeng väga motiveeriv, sest mitu korda mainiti, et oleme IT Kolledžisse astudes teinud õige valiku. Merle Varendi ütles, et tasub arendada ka mitte-erialaseid oskusi, sest need võivad olla tulevikus mu konkurentsieeliseks. See oli julgustav, kuna ma olen varem just sellistes ettevõtetes töötanud, mis pole IT-valdkonnaga seotud.

Loeng 2

Teise loengu, teemal "Õppimine ja motivatsioon<ref>[https://echo360.e-ope.ee/ess/echo/presentation/4d88020e-ceeb-46cf-a017-a5497a9644a0 Loeng: Õppimine ja motivatsioon]</ref>", pidas Margus Ernits 4. septembril. Õppejõud andis head nõu õppimise kohta - esialgu, mida ei tohiks teha, et endal ja teistel oleks tulevikus parem. Hea mõttekäik oli teiste eest töö ära tegemise kohta, kui keegi seda viimasel hetkel enne tähtaega peaks paluma. Tudeng, kes ise midagi teha ei viitsi ja mõtleb, et saab tänu teistele kodutööd tehtud, see ei pruugi eksamitest läbi saada ning peab ikka lõpuks kõik järgi õppima. Seejuures raiskab ta aga veel rohkem oma aega. Teiseks tõsiasjaks on spikerdamine - mida lihtsam seda teha on, seda rohkem spikerdatakse, ütles Ernits. Nõustun selle väitega, sest vahel sai keskkoolis isegi nendes ainetes maha kirjutatud, kus teema selgeks õppimine oleks olnud lihtne ja vajalik.
Saime ka mõned soovitused õppimise tõhusamaks muutmise ning innustuse kohta. Uut teemat õppima hakates võib see tunduda raske ning see viib motivatsiooni alla. Tihti on esimene samm kõige raskem ,aga kui juba natuke saab "otsa lahti", siis tavaliselt hakkab huvi teema vastu kasvama. Üks soovitus oli ''Mind map''i kohta - kui õpitav muutub liiga keeruliseks ning seosed ei teki uute ja vanade teadmiste vahele, siis tuleks mõtted kaardistada. Loodan, et saan ilma ''mindmapping''uta hakkama, aga kui ei saa, siis oleks huvitav seda proovida.

Loeng 3

Loeng 4

Loeng 5

Loeng 6

Loeng 7

Loeng 8
"Suhtumine õppetöösse ja veebirakenduste turvalisus<ref>[https://echo360.e-ope.ee/ess/echo/presentation/791a5ecb-f27c-4401-8565-1dbd16894f27?ec=true Loeng: Suhtumine õppetöösse ja veebirakenduste turvalisus]</ref>" oli meie 16. oktoobri ehk viimase loengu teema ning selle viis läbi Elar Lang. Õppetöösse suhtumise teemal olid mulle kõige meeldejäävamateks punktideks tahe ennast arendada ning lai silmaring. Kordusid mõned head mõtted eelmiste loengute soovitustest. Kõige rohkem on jäänud meelde soovitus küsida võimalikult palju - peaasi, et teema selgeks saab. Siiani pole ma aktiivne küsija olnud, kuigi peaksin siiski üritama seda rohkem teha. Samuti kordus mõte õppimist segavate faktorite kohta - loengus peab tegelema ainult õppimisega. Kuna mitmed on soovitanud ennast suhtluskanalitest õppimise ajaks välja logida, siis nüüd teen seda minagi, kuigi see pole mul suureks probleemiks olnud.
Miskipärast meeldis mulle viimane loeng(võibolla seetõttu, et esinejaks oli koolitaja ning oskas hästi publiku ees rääkida)kõige rohkem - eriti teine pool. Elar Lang rääkis lühidalt turvalisusest veebirakendustes ning rõhutas, et ka suurtes ja tuntud ettevõtetes on turvariskid olemas. See pani mind mõtlema, mis infot ma enda kohta internetti panen, sest see võib tulevikus minu vastu pöörduda. Samuti oli huvitav kuulda, kui lihtne on kräkkida kellegi paroole, kui see on liiga tavaline või ära arvatav. Saadud info ajendil üritan oma paroolid võimalikult keeruliseks teha ning kasutada erinevaid salasõnu.
Kokkuvõte

==Notes==

==Õpingukorralduse küsimused ja ülesanne==
===Küsimus A===
Kukkusid eksamil läbi. Kaua on võimalik eksamit järele teha? Kellega kokkuleppida, et järeleksamit teha? Kuidas toimub järeleksamile registreerimine? Mis on tähtajad? Palju maksab, kui oled riigi finantseeritaval (RF) õppekohalkohal? Palju maksab, kui oled tasulisel (OF) õppekohal kohal?

'''Vastus'''

Kui tudeng kukub eksami läbi, siis võib ta sooritada korduseksami kahe semestri jooksul pärast aine õpetamissemestri lõppu.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#eksamid Õppekorralduse eeskiri 5.3.6]</ref> Korduseksamite tähtajad määrab ainet õpetav õppejõud kooskõlas õppeosakonnas koostatud ajakavaga, seega tuleb järeleksam kokkuleppida õppejõuga.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#eksamid Õppekorralduse eeskiri 5.3.6]</ref> Järeleksamile registreerimine toimub ÕISis, kusjuures registreerumise ja soorituse vahele peab jääma vähemalt 2 päeva.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#eksamitekorraldus Õppekorralduse eeskiri 5.2.8]</ref> Korduseksami arve kuvatakse ÕISis ja selle maksumuse kehtestab rektor käskkirjaga.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#eksamitekorraldus Õppekorralduse eeskiri 5.2.7]</ref> Omafinantseeritaval õppekohal tuleb maksta kordussoorituse eest 20€ HITSA kontole. Riigifinantseeritaval kohal on kordussooritusel osalemine tasuta. <ref>[http://www.itcollege.ee/tudengile/kkk/#Kuidas_pääsen_kordussooritusele? Vastused korduma kippuvatele küsimustele(9.)]</ref><ref>[https://www.itcollege.ee/tudengile/finantsinfo/pangarekvisiidid/ Teenuste tasumäärad 2014/2015 õppeaastal]</ref>

===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 tuleb need teha, et vahetada õppekava?
Kas deklareeritud, kuid tegemata jäänud valikaine tuleb kolledži lõpetamiseks tingimata sooritada? Millega pean arvestama, deklareerides valikaineid üle õppekavas ette nähtud mahu (sh. deklareeritud, kuid sooritamata jäänud valikained)?

'''Vastus'''

Õppekava vahetamiseks tuleb esitada hiljemalt 1 tööpäev enne semestri punase joone päeva EIK õppeosakonda rektori nimele vabas vormis kirjalik avaldus ning nimekiri õppesooritustest, mille arvestamist uue õppekava osana taotletakse. <ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#akadeemilineliikumine Õppekorralduse eeskiri 7]</ref>

Tudeng peab oma õpinguaja jooksul sooritama kõik tema poolt täidetavas õppekavas olevad kohustuslikud ained ja õppekavas ettenähtud mahus valikaineid.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#alused Õppekorralduse eeskiri 1.3.6]</ref>

RE õppekohal tuleb tasuda õppekava nominaalmahtu (180 EAP) ületavate õpingute eest. Seega, kui olen deklareerinud ühte õppeainet mitu korda või deklareerinud valikaineid üle õppekavas sätestatud määra, esitatakse mulle õppemaksu arve.<ref>[http://www.itcollege.ee/tudengile/kkk/#Mida_deklareerimisel_arvestada? Vastused korduma kippuvatele küsimustele(2.)]</ref>Kui lõpetan õpingud nominaalajaga, siis on mul õigus avalduse alusel taotleda õppemaksu tagastamist 180 EAP ületavate EAPde eest kuni 2 EAP ulatuses.Avalduse õppemaksu tagastamiseks pea esitama õppeosakonda peale diplomitöö edukat kaitsmist viie tööpäeva jooksul alates kaitsmise tulemuste teatavaks tegemisest.<ref>[http://www.itcollege.ee/tudengile/eeskirjad-ja-juhendid/oppekorraldus-eeskiri/#oppuroigus Õppekorralduse eeskiri 3.1.8]</ref>

===Ülesanne===
Kui mitme EAP ulatuses tuleb õppekulud osaliselt hüvitada aasta lõpuks, kui esimese semestri lõpuks on olemas 26 EAPd ja teise semestri lõpuks 19 EAPd? Kui suur on teile esitatav arve?

'''Vastus'''

Semestris tuleb koguda vähemalt 27 EAP-d(54 õppeaastas), seega aasta lõpuks on puudu 9 ainepunkti. 1 EAP maksab 50€, mistõttu tuleb arve 450€ suurune.<ref>[http://www.itcollege.ee/tudengile/finantsinfo/ IT Kolledži finantsinfo]</ref><ref>[http://www.itcollege.ee/tudengile/kkk/korgharidusreform-kkk/#Teine Kõrgharidusreform]</ref>

===Vastuste allikad===
<references/>

User:Ktilk

2014-10-20T13:09:03Z

Ktilk: /* Essee */