Talk:Kalimali budget: Difference between revisions
No edit summary |
|||
Line 6: | Line 6: | ||
= | =Lõpptoote retsensioon= | ||
===Ülesehitus:=== | ===Ülesehitus:=== |
Revision as of 18:03, 24 January 2018
Analüüsi retsensioon
Analüüs on hästi ülesehitatud, funktsionaalus on arusaadavalt kirjeldatud.. Mõned probleemid, mida ma nägin.. Mingi funktsionaalsus on segane.. Kas ma ise kasutaks lahendust?.. Mida teeksin teistmoodi? Mida meeskond arvab andmemudelist.. Kuidas skoop tundub? Kas on teostatav või peaks meeskond näiteks midagi vähem. Mingi funktsionaalsus Nice to have alt must have alla tõsta.. Tekstist arusaadavus ja ülesehitus..
Retsenseeris meeskond Demo 12.11.2017
Lõpptoote retsensioon
Ülesehitus:
Analüüs on hästi ja loogiliselt ülesehitatud, hea jälgida ja aru saada.
Funktsionaalsuse kirjeldus
Hea, et funktsionaalsus on puntkidena kirjeldatud. Halb see, et välja toodud punktid on veidi pealiskaudsed. Võiks olla veidi detailsemalt kirjeldatud. Puudu jääb ehk ka selgitavatest joonistest, mis aitaksid paremini mõista, mida rakendus täpselt tegema peab.
Probleemid:
- Vaated 1: “(pole veel otsustatud, kas saab olema parooliga või ilma)”
Kindlasti peab olema parool!
- Vaated 1: miks on külaline?
- Vaated 4: Kas kasutaja poolt lisatavad kulu- või tulutüübid on näha hiljem kõikidele kasutajatele või on need kasutajapõhised? Andmemudelist võib eeldada, et need on kõigile nähtavad.
- Vaated üldiselt: selle asemel, et tekstiliselt lahti kirjutada vaated (kus, mis asub jms) võiks teha lihtsustava prototüübi joonise, mis lihtsustab nii projektiliikmete arusaama võimalikust lõpptulemusest kui ka retsenseerijate oma:)
Kas me ise kasutaks lahendust?
Ei, kuna pole otsest vajadust hetkel (pole pereinimesed). Individuaalsel tasemel on nt. Swedbanki internetipangas sarnane funktsionaalsus rahaplaneerija näol. Soovitaks sellest eeskuju võtta.
Mida teeksime teistmoodi?
Kasutaks SQLite andmebaasi MySQL asemel, kuna tegemist lokaalse desktop rakendusega. MySQL ja networkiga sidumine võib teha nice-to-have funktsionaalsusena.
Andmemudel:
Kulu ja tulu tabelid peaksid olema samuti Foreign Key’de abil kasutajaga seotud. Praeguses andmemudelis ei ole ühtegi viidet sellele, mis kulud/tulud milliste kasutajatega seotud on. Muus osas on hea, et on näitetabelitena välja toodud, milleks mingeid tabeleid vaja läheb.
Skoop:
Nagu ka analüüsikirjutajad ise mainisid, siis nõustume, et algajatele arendajatele on see suhteliselt suur väljakutse. Projekt hõlmab mitmeid komponente, sh kasutajapõhine lähenemine, seos andmebaasiga jms. Kuna tegemist on projekti liikmetele uue arenduskeelega, siis võib vastamisi sattuda erinevate väiksemate muredega, mis pikendavad projekti realiseeritavust. Kokkuvõtvalt on tegu väga suure väljakutsega, kuid samas piisav, et saada C# keele ja framework’idega “sina” peale.
Teostatavus:
Idee on teostatav ja ka jõukohane, samas võiks tõsta mitmed must-have punktid nice-to-have alla. Näiteks:
- erinevate tulu ja kululiikide (kategooriate) määramise võimalus
- kasutajanimede, kululiikide ning muude kirjete muutmine/kustutamine
- võimalus teha päringuid erinevate kasutajate, kululiikide kaupa
- tehingute grupeerimise võimalus
- järjestada tulusid-kulusid erinevate parameetrite kaupa (summa, kululiigi, kuupäeva järgi nt. nn. TOP kulud
Must-have võiks olla tõesti core funktsionaalsus.
Arusaadavus:
Tekst on arusaadavalt ja hästi lahti kirjutatud. Analüüsi idee osas kirjutatakse selgelt lahti, mida antud rakendusega teha saab. Teksti üles ehitus on loogiline, algul kirjeldatakse idee lahti ning siis tuuakse välja rakenduse erienvad vaated, kirjeldatakse ära funktsionaalsus ja tuuakse välja andmemudel. Rakendusest arusaamist lihtsustab ka näide andmebaasi tabelitest.
Tublid ja jõudu tööle!
Retsenseeris meeskond CSharpResto 12.11.2017
Prototüübi retsensioon
Funktsionaalsus
Kasutajaliides ja -disain
Realisatsioon, kood
Retsenseeris meeskond PennyFriends 24.01.2018