Talk:EasyDesk: Difference between revisions

From ICO wiki
Jump to navigationJump to search
 
(19 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Projekti "EasyDesk" retsensioon ==
== Projekti "EasyDesk" retsensioon ==


Rakenduse idee on arusaadav ning funktsionaalsused põhjalikult ja loogiliselt kirjeldatud. ''Must have'' ja ''Nice to have'' funktsioonid on antud rakenduse jaoks sobivad ning mõistlikult jaotatud. Funktsioonid, mis on väljatoodud ''Must have'' all, katavad antud sisuga rakenduse peamisi vajadusi. ''Nice to have'' funktsioonide all on olemas rakendusele sobivad funktsioonid, mis ei ole esimeses etapis ettevõttele esmavajalikud, kuid annavad olemasolul lisaväärtust.
'''Rakenduse idee''' on väga hea, see on arusaadav ning funktsionaalsused põhjalikult ja loogiliselt kirjeldatud. Oleks võinud tuua ka näiteid või täpsustada, mis teenuseid pakkuvate ettevõtete jaoks rakendus on mõeldud, sest teenused võivad olla erinevad. Mõnel teenusel on kindel kestus näiteks massaaž (1 tund) ja mõnel teenusel ei ole võimalik nii täpselt kestust määrata, näiteks IT arendustööd vms.


Vaadete puhul oli põhjalikult kirjeldatud, kuidas toimub uue kliendi/teenuse jne. lisamine ning mõne sõnaga oleks võinud kirjeldada ka kustutamist ja muutmist. Näiteks, kuidas peaks rakendus käituma (keelama tegevuse, küsima kinnituse vms), kui soovitakse kustutada aktiivse tellimusega klienti või muuta aktiivse tellimusega teenuse staatust arhiveerituks jne.
'''''Must have'' ja ''Nice to have'' funktsioonid''' on antud rakenduse jaoks sobivad ning mõistlikult jaotatud. Funktsioonid, mis on väljatoodud ''Must have'' all, katavad antud sisuga rakenduse peamisi vajadusi. Registreerimise ja sisselogimise kasutamine on põhjendatud, sest tegemist on andmetega, mille juurde peaks olema piiratud ligipääs. Võiks mõelda, kas registreerimisel kasutada ka ettevõtte registrikoodi, siis on kindel, et sisestatakse unikaalne ettevõte, nime võib natuke erineval kujul kirjutada ja siis ei saada aru, et see ettevõte juba on olemas (näiteks OÜ märgitakse nime ette või taha või jäetakse üldse ära).


Andmebaasiskeem on väljatoodud funktsionaalsuse jaoks piisav ning info on loogiliselt tabelitesse jaotatud.
''Nice to have'' funktsioonide all on olemas rakendusele sobivad funktsioonid, mis ei ole esimeses etapis ettevõttele esmavajalikud, kuid annavad olemasolul lisaväärtust.


'''Vaadete''' puhul oli põhjalikult kirjeldatud, kuidas toimub uue kliendi/teenuse jne. lisamine ning mõne sõnaga oleks võinud kirjeldada ka kustutamist ja muutmist. Näiteks, kuidas peaks rakendus käituma (keelama tegevuse, küsima kinnituse vms), kui soovitakse kustutada aktiivse tellimusega klienti või muuta aktiivse tellimusega teenuse staatust arhiveerituks jne.


Kas rakenduse idee on arusaadav?
'''Andmebaas''' on väljatoodud funktsionaalsuse jaoks piisav ning info on enamjaolt loogiliselt tabelitesse jaotatud.
Andmebaasi puhul oleks võinud eraldi välja tuua, milliste tulpade väärtused on võimalik kirjete lisamisel või muutmisel tühjaks jätta. Antud juhul võib küll eeldada, et tegu on väljadega, mille puhul pole lisamise funktsionaalsuse juures märgitud veateadete kuvamist, kuid üheseltmõistetavuse huvides võiks see olla konkreetsem.


Kas loogiliselt sobituvad väljatoodud nice to have ja must have funktsionaalsused rakenduse juurde?
'''Soovitused/mõtted andmebaasiskeemi osas'''


Kas funktsionaalsused on loogiliselt kirjeldatud?
Tabelis Staff võiks olla perenime kohta ka info, juhuks kui on kaks töötajat ühe eesnimega.


Retsenseeriva meeskonna poolsed mõtted(mida võiks teha paremini või mis võiks olla teistmoodi koos põhjendusega).
Tabelite User ja Company kasutus jääb natuke arusaamatuks. Skeemi kohaselt paistab, et ühel ettevõttel saab olla mitu kasutajat, kuid vastavalt registreerimise selgitusele peavad registreerimisel nii kasutaja kui ettevõte olema unikaalsed väärtused ja mõlemad sisestatud. Vastasel juhul kuvatakse veateade ja ka hiljem ei ole märgitud funktsionaalsust, mis lubaks veel ühe kasutaja lisada. Selliselt puudub eraldi User ja Company tabelitel mõte. Lisaks tundub loogilisem, kui tabelid Clients, Orders, Staff ja Services oleks seotud CompanyID-ga, mitte UserID-ga, sest kliendid, tellimused, töötajad ja teenused on ettevõttel, mitte kasutajal. Viimane kehtib ka juhul, kui funktsionaalsus uue kasutaja lisamiseks tuleb hiljem, kuna uus kasutaja peaks ligi pääsema ettevõtte andmetele.


Kui on andmebaasi skeem, siis võib ka selle kohta märkmeid teha. A'la, et kas toetab/võimdalab funktsionaalsuse saavutamist.
Mõned skeemi seosed paistavad ebaloogilised: skeemi kohaselt saab tellimusel olla mitu klienti ning teenusel mitu kasutajat/ettevõtet, kuid korrektne tundub vastupidi (kliendil mitu tellimust, kasutajal/ettevõttel mitu teenust).
Üldmulje plaanitavast rakendusest. Näiteks, et kas funktsionaalsus on piisav või hoopis hoiatada meeskonda, et must to have funktsionaalsus on liiga pikk ja midagi võiks kärpida, et töö valmis jõuda.


Retsenseeriv meeskond soovitab, et võiks kaaluda seda, et Orders tabelisse lisada väljad tööde alustamise aeg ja valmis saamise aeg, see aitaks hinnata ettevõttel teenuste kestust, juhul kui on ettevõte, kelle teenuse kestus ei ole kindlalt paigas. Varasemate andmete pealt oleks võimalik ettevõttel sama teenuse kestvust prognoosida.


'''Kokkuvõte'''
Üldiselt tundub, et projekt on hästi planeeritud ja kasutaja võiks kõik ''Must have'' funktsionaalsused valmis jõuda. ''Must have'' funktsionaalsused on olulised ja ''Nice to have'' funktsionaalsused annavad rakendusele küll lisandväärtust, aga rakendus toimib ka ilma nendeta.




Line 27: Line 30:
*'''Evelin Jõgi'''
*'''Evelin Jõgi'''
*'''Kersti Miller'''
*'''Kersti Miller'''
== Lõpptoote retsensioon ==
Üheliikmeline meeskond EasyDesk on ära teinud suure töö. Loodud on rakendus mis võimaldab ettevõtetel oma teenuseid, kliente, tellimusi ja töötajate infot hallata. Töö on alanud põhjalikust analüüsist, kus on välja toodud mida rakendusega tahetakse saavutada ja kuidas seda tehniliselt teha. On välja toodud mõistlik kogus funktsionaalsusi mis plaaniti kindlasti valmis saada. Väga põhjalikult on kirjeldatud planeeritud vaated. Algne andmebaasimudel oli läbi mõeldud ja loogiline.
===Eesmärkide täitmine===
Enamjaolt on planeeritud funktsionaalsused realiseeritud. Ei jõutud vamis aruannete koostamise funktsionaalsusega. Lisaks küllaltki mahukale rakendusele on valminud ka väga põhjalik kasutusjuhend, kus on kirjedatud võimalikud tegevused ja piirangud. Ohukohad on ilusti punasega rõhutatud.
===Tehniline pool===
Kasutud on WPF tehnoloogiat ja Model-View-ViewModel (MVVM) arendusmustrit ning lokaalset sql andmebaasi koos Entity Frameworkiga. Kood on üldiselt puhas ja loogiline ning raknduse struktuur mõistlik. Rakendus on jagatud kaheks projektiks. Ühes on vaadete ja vaateemudeliga seonduv ning teises mudelite, andmebaasi ja BO-dega seonduv. Vaated näevad viisakad välja.
===Mõningad tähelepanekud===
Oleks võinud muuta andmebaasi selliselt, et kliendi kustutamisel ei kustuks kõik selle kliendiga seotud tellimused.
Oleks võinud olla rohkem vigadehaldust andmebaasiga suhtlemisel.
Uue konto loomiseks hüppab ekraanil uus aken eelmisest tükk maad eemal lahti.
===Kokkuvõtteks===
Arvestades, et tegemist on üheliikmelise tiimiga on suudetud väga korralik töö ära teha. Analüüs oli põhjalik ja selle tulemusi on näha ka rakenduse ülesehituses.
Retsenseeris projekti "Battle2048" meeskond:
*'''Andrus Seiman'''
*'''Kristjan Peterson'''

Latest revision as of 00:57, 2 February 2017

Projekti "EasyDesk" retsensioon

Rakenduse idee on väga hea, see on arusaadav ning funktsionaalsused põhjalikult ja loogiliselt kirjeldatud. Oleks võinud tuua ka näiteid või täpsustada, mis teenuseid pakkuvate ettevõtete jaoks rakendus on mõeldud, sest teenused võivad olla erinevad. Mõnel teenusel on kindel kestus näiteks massaaž (1 tund) ja mõnel teenusel ei ole võimalik nii täpselt kestust määrata, näiteks IT arendustööd vms.

Must have ja Nice to have funktsioonid on antud rakenduse jaoks sobivad ning mõistlikult jaotatud. Funktsioonid, mis on väljatoodud Must have all, katavad antud sisuga rakenduse peamisi vajadusi. Registreerimise ja sisselogimise kasutamine on põhjendatud, sest tegemist on andmetega, mille juurde peaks olema piiratud ligipääs. Võiks mõelda, kas registreerimisel kasutada ka ettevõtte registrikoodi, siis on kindel, et sisestatakse unikaalne ettevõte, nime võib natuke erineval kujul kirjutada ja siis ei saada aru, et see ettevõte juba on olemas (näiteks OÜ märgitakse nime ette või taha või jäetakse üldse ära).

Nice to have funktsioonide all on olemas rakendusele sobivad funktsioonid, mis ei ole esimeses etapis ettevõttele esmavajalikud, kuid annavad olemasolul lisaväärtust.

Vaadete puhul oli põhjalikult kirjeldatud, kuidas toimub uue kliendi/teenuse jne. lisamine ning mõne sõnaga oleks võinud kirjeldada ka kustutamist ja muutmist. Näiteks, kuidas peaks rakendus käituma (keelama tegevuse, küsima kinnituse vms), kui soovitakse kustutada aktiivse tellimusega klienti või muuta aktiivse tellimusega teenuse staatust arhiveerituks jne.

Andmebaas on väljatoodud funktsionaalsuse jaoks piisav ning info on enamjaolt loogiliselt tabelitesse jaotatud. Andmebaasi puhul oleks võinud eraldi välja tuua, milliste tulpade väärtused on võimalik kirjete lisamisel või muutmisel tühjaks jätta. Antud juhul võib küll eeldada, et tegu on väljadega, mille puhul pole lisamise funktsionaalsuse juures märgitud veateadete kuvamist, kuid üheseltmõistetavuse huvides võiks see olla konkreetsem.

Soovitused/mõtted andmebaasiskeemi osas

Tabelis Staff võiks olla perenime kohta ka info, juhuks kui on kaks töötajat ühe eesnimega.

Tabelite User ja Company kasutus jääb natuke arusaamatuks. Skeemi kohaselt paistab, et ühel ettevõttel saab olla mitu kasutajat, kuid vastavalt registreerimise selgitusele peavad registreerimisel nii kasutaja kui ettevõte olema unikaalsed väärtused ja mõlemad sisestatud. Vastasel juhul kuvatakse veateade ja ka hiljem ei ole märgitud funktsionaalsust, mis lubaks veel ühe kasutaja lisada. Selliselt puudub eraldi User ja Company tabelitel mõte. Lisaks tundub loogilisem, kui tabelid Clients, Orders, Staff ja Services oleks seotud CompanyID-ga, mitte UserID-ga, sest kliendid, tellimused, töötajad ja teenused on ettevõttel, mitte kasutajal. Viimane kehtib ka juhul, kui funktsionaalsus uue kasutaja lisamiseks tuleb hiljem, kuna uus kasutaja peaks ligi pääsema ettevõtte andmetele.

Mõned skeemi seosed paistavad ebaloogilised: skeemi kohaselt saab tellimusel olla mitu klienti ning teenusel mitu kasutajat/ettevõtet, kuid korrektne tundub vastupidi (kliendil mitu tellimust, kasutajal/ettevõttel mitu teenust).

Retsenseeriv meeskond soovitab, et võiks kaaluda seda, et Orders tabelisse lisada väljad tööde alustamise aeg ja valmis saamise aeg, see aitaks hinnata ettevõttel teenuste kestust, juhul kui on ettevõte, kelle teenuse kestus ei ole kindlalt paigas. Varasemate andmete pealt oleks võimalik ettevõttel sama teenuse kestvust prognoosida.

Kokkuvõte Üldiselt tundub, et projekt on hästi planeeritud ja kasutaja võiks kõik Must have funktsionaalsused valmis jõuda. Must have funktsionaalsused on olulised ja Nice to have funktsionaalsused annavad rakendusele küll lisandväärtust, aga rakendus toimib ka ilma nendeta.


Retsenseeris projekti "Rahaplaneerija" meeskond:

  • Maila Keerus
  • Evelin Jõgi
  • Kersti Miller


Lõpptoote retsensioon

Üheliikmeline meeskond EasyDesk on ära teinud suure töö. Loodud on rakendus mis võimaldab ettevõtetel oma teenuseid, kliente, tellimusi ja töötajate infot hallata. Töö on alanud põhjalikust analüüsist, kus on välja toodud mida rakendusega tahetakse saavutada ja kuidas seda tehniliselt teha. On välja toodud mõistlik kogus funktsionaalsusi mis plaaniti kindlasti valmis saada. Väga põhjalikult on kirjeldatud planeeritud vaated. Algne andmebaasimudel oli läbi mõeldud ja loogiline.

Eesmärkide täitmine

Enamjaolt on planeeritud funktsionaalsused realiseeritud. Ei jõutud vamis aruannete koostamise funktsionaalsusega. Lisaks küllaltki mahukale rakendusele on valminud ka väga põhjalik kasutusjuhend, kus on kirjedatud võimalikud tegevused ja piirangud. Ohukohad on ilusti punasega rõhutatud.

Tehniline pool

Kasutud on WPF tehnoloogiat ja Model-View-ViewModel (MVVM) arendusmustrit ning lokaalset sql andmebaasi koos Entity Frameworkiga. Kood on üldiselt puhas ja loogiline ning raknduse struktuur mõistlik. Rakendus on jagatud kaheks projektiks. Ühes on vaadete ja vaateemudeliga seonduv ning teises mudelite, andmebaasi ja BO-dega seonduv. Vaated näevad viisakad välja.

Mõningad tähelepanekud

Oleks võinud muuta andmebaasi selliselt, et kliendi kustutamisel ei kustuks kõik selle kliendiga seotud tellimused. Oleks võinud olla rohkem vigadehaldust andmebaasiga suhtlemisel. Uue konto loomiseks hüppab ekraanil uus aken eelmisest tükk maad eemal lahti.

Kokkuvõtteks

Arvestades, et tegemist on üheliikmelise tiimiga on suudetud väga korralik töö ära teha. Analüüs oli põhjalik ja selle tulemusi on näha ka rakenduse ülesehituses.


Retsenseeris projekti "Battle2048" meeskond:

  • Andrus Seiman
  • Kristjan Peterson