Incman

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)

Teise rühma 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.