Talk:EasyDesk

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.

Andmebaasiskeem 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. Tabelis Staff võiks olla perenime kohta ka info, juhuks kui on kaks töötajat ühe eesnimega. Meile tundub, et oleks 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. Jääb natuke arusaamatuks kas on mõeldud, et ühel ettevõttel on mitu kasutajat või ühel kasutajal mitu ettevõtet. Andmebaasiskeemi järgi tundub, et on mõeldud, et ühel kasutajal on mitu ettevõtet, aga pigem võiks olla ühel ettevõttel mitu kasutajat. Hetkel ei ole kirjeldatud ka võimalust, et ühe kasutaja alla oleks võimalik lisada mitu ettevõtet või ühe ettevõtte alla oleks võimalik lisada mitu kasutajat, sest registreerimisel peab nii kasutaja kui ettevõte olema unikaalsed väärtused ja mõlemad sisestatud, vastasel juhul kuvatakse veateade ja ka hiljem ei ole funktsionaalsust, mis lubaks veel ühe ettevõtte/kasutaja lisada.

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.

Ü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