Talk:Meeskond:LifePlanner - Revision history

Hantsov at 00:53, 30 January 2015

2015-01-30T00:53:19Z

← Older revision		Revision as of 03:53, 30 January 2015
Line 28:		Line 28:

	Kokkuvõttes on veakontrollide puudujäägid mõistetavad arvestades, et tegemist on prototüübiga. Kui rakendust disainida väljanägemiselt kuidagi „väiksemaks” ning arvestada tehtud soovitusi kasutajasõbralikkuse kohta, siis võiks siit välja areneda reaalselt kasutatav abivahend.		Kokkuvõttes on veakontrollide puudujäägid mõistetavad arvestades, et tegemist on prototüübiga. Kui rakendust disainida väljanägemiselt kuidagi „väiksemaks” ning arvestada tehtud soovitusi kasutajasõbralikkuse kohta, siis võiks siit välja areneda reaalselt kasutatav abivahend.

			''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''


			=Lõpptoote retsensioon=

			Meeskond on kodulehel väga hästi välja toonud kogu rakenduse funktsionaalsuse ja juhendi selle kasutamiseks. Esimese asjana hakkab kohe silma, et rakenduse välimus on läbinud uuenduskuuri. Disainiga on nähtud vaeva. Prototüüpi retsenseerides silma jäänud „TODO listi” ja „Rahaplaneerija” ebamugavused kasutamisel on nüüd kadunud.

			Prototüübis märgatud peamine puudujääk veakontrollide näol on samuti saanud tugeva uuenduskuuri. Enamus kasutaja valetegevustele on selgete juhistega veateated. Siiski üks suurem viga on veel alles – kui lisada sündmus kalendrisse vigaste kuupäevadega, jookseb rakendus kokku. Koodis muudetakse textboxi sisu DateTime.Parse abil aja formaati, mis pakub aga hea võimaluse vigadega tekkeks, kui seda ei kontrollita - võinuks kasutada nt try/catch plokki. Üks pisem puudujääk veel sündmuste lisamise juures on, et lõppaegu saab panna varasemaks algusajast. Koodi koha pealt on rakendus mõistlikult MVVM arendusmustrit järgides üles ehitatud. Kood on ilusti kommenteeritud.

			Kokkuvõttes tundub, et meeskond saavutas analüüsis püstitatud ''must-have'' funktsionaalsused ning jõuti ka teostada ''nice to have'' funktsionaalsusest ilus disain. Paar veakontrolli/veahaldust on jäänud teostamata.

	''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''		''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''

Hantsov at 15:49, 21 January 2015

2015-01-21T15:49:46Z

← Older revision		Revision as of 18:49, 21 January 2015
Line 22:		Line 22:
	=Prototüübi retsensioon nr. 2=		=Prototüübi retsensioon nr. 2=

	Rakenduse kõige suurem puudujääk on hetkel erinevad veakontrollid. Kalendrisse lisamisel, kui teha viga aegade sistestamisel, siis jookseb programm kokku. Lisaks paremal asuv nimekiri sündmustest lisab korduvalt sündmusi, kui navigeerida kalendris. Lisaks võiks olla sündmustel kontroll, et neid ei saaks kaugele minevikku paigutada ning lõppkuupäeva paigutada varasemaks algusest.		Rakenduse kõige suurem puudujääk on hetkel erinevad veakontrollid. Kalendrisse lisamisel, kui teha viga aegade sistestamisel, siis jookseb programm kokku. Lisaks paremal asuv nimekiri sündmustest lisab korduvalt sündmusi, kui navigeerida kalendris. Lisaks võiks olla sündmustel kontroll, et neid ei saaks kaugele minevikku paigutada ning lõppkuupäeva paigutada varasemaks algusest. TODO lehel, kui vajutada pärast lisamist ilma uuendamata "Tehtud", siis jookseb programm kokku.

	Rahaplaneerijas on veakontroll olemas ning kõik toimib ootuspäraselt. Rahaplaneerijas lihtsalt kasutaja seisukohalt häirib, et pärast igat tegevust peab tagasi liikuma ning akna uuesti laadima.		Rahaplaneerijas on veakontroll olemas ning kõik toimib ootuspäraselt. Rahaplaneerijas lihtsalt kasutaja seisukohalt häirib, et pärast igat tegevust peab tagasi liikuma ning akna uuesti laadima.
	Samuti TODO listiga oleks ehk kasutajasõbralikkuse koha pealt parem, kui see uuendaks ennast automaatselt, kui „Tehtud” vajutada.		Samuti TODO listiga (kalendri lehel olev) oleks ehk kasutajasõbralikkuse koha pealt parem, kui see uuendaks ennast automaatselt, kui „Tehtud” vajutada.

	Kokkuvõttes on veakontrollide puudujäägid mõistetavad arvestades, et tegemist on prototüübiga. Kui rakendust disainida väljanägemiselt kuidagi „väiksemaks” ning arvestada tehtud soovitusi kasutajasõbralikkuse kohta, siis võiks siit välja areneda reaalselt kasutatav abivahend.		Kokkuvõttes on veakontrollide puudujäägid mõistetavad arvestades, et tegemist on prototüübiga. Kui rakendust disainida väljanägemiselt kuidagi „väiksemaks” ning arvestada tehtud soovitusi kasutajasõbralikkuse kohta, siis võiks siit välja areneda reaalselt kasutatav abivahend.

	''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''		''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''

Hantsov at 15:10, 21 January 2015

2015-01-21T15:10:02Z

← Older revision		Revision as of 18:10, 21 January 2015
Line 18:		Line 18:

	Kasutajaliides mulle meeldis, ei pidanud kaua mõtlema, mis nupp mida teeb, kõik oli lihtne ja loogiline. Väike norimine sellel teemal, et UI komponendid ei liigu akna suuruse muutmise peale kaasa. Oleks võimalik määrata min suurus aknale, kus kõik komponendid ära mahuks ning siis ei pea selle pärast muretsema. Kuna tegu prototüübiga, siis see täiesti normaalne.		Kasutajaliides mulle meeldis, ei pidanud kaua mõtlema, mis nupp mida teeb, kõik oli lihtne ja loogiline. Väike norimine sellel teemal, et UI komponendid ei liigu akna suuruse muutmise peale kaasa. Oleks võimalik määrata min suurus aknale, kus kõik komponendid ära mahuks ning siis ei pea selle pärast muretsema. Kuna tegu prototüübiga, siis see täiesti normaalne.


			=Prototüübi retsensioon nr. 2=

			Rakenduse kõige suurem puudujääk on hetkel erinevad veakontrollid. Kalendrisse lisamisel, kui teha viga aegade sistestamisel, siis jookseb programm kokku. Lisaks paremal asuv nimekiri sündmustest lisab korduvalt sündmusi, kui navigeerida kalendris. Lisaks võiks olla sündmustel kontroll, et neid ei saaks kaugele minevikku paigutada ning lõppkuupäeva paigutada varasemaks algusest.

			Rahaplaneerijas on veakontroll olemas ning kõik toimib ootuspäraselt. Rahaplaneerijas lihtsalt kasutaja seisukohalt häirib, et pärast igat tegevust peab tagasi liikuma ning akna uuesti laadima.
			Samuti TODO listiga oleks ehk kasutajasõbralikkuse koha pealt parem, kui see uuendaks ennast automaatselt, kui „Tehtud” vajutada.

			Kokkuvõttes on veakontrollide puudujäägid mõistetavad arvestades, et tegemist on prototüübiga. Kui rakendust disainida väljanägemiselt kuidagi „väiksemaks” ning arvestada tehtud soovitusi kasutajasõbralikkuse kohta, siis võiks siit välja areneda reaalselt kasutatav abivahend.

			''Retsenseeris meeskond [https://wiki.itcollege.ee/index.php/Meeskond:EasyRent EasyRent]''

Rokullam: /* Retsensioon: Andres Mets */

2014-12-20T21:32:20Z

Retsensioon: Andres Mets

← Older revision		Revision as of 00:32, 21 December 2014
Line 3:		Line 3:
	Sellise üldise analüüsi baasilt on väga raske määratleda süsteemi mahtu ning loodava funktsionaaluse hulka- analüüsi lugedes tekib küll arusaam süsteemile kehtestatud nõuetest, kuid nagu ülesande kitsaskohtade kirjelduses välja toodud puudub ülevaade süsteemi mahust ning loodava funktsionaalsuse ulatusest. Seega selle analüüsi põhjalt on raske siseneda disaini/implemtatsiooni faasi, programmi loomise käigus kerkivad esile fundametaalset laadi küsiused, millele vastused võivad suurel määral mõjutada süsteemi arendust ning funktsionaalsust tervikuna.		Sellise üldise analüüsi baasilt on väga raske määratleda süsteemi mahtu ning loodava funktsionaaluse hulka- analüüsi lugedes tekib küll arusaam süsteemile kehtestatud nõuetest, kuid nagu ülesande kitsaskohtade kirjelduses välja toodud puudub ülevaade süsteemi mahust ning loodava funktsionaalsuse ulatusest. Seega selle analüüsi põhjalt on raske siseneda disaini/implemtatsiooni faasi, programmi loomise käigus kerkivad esile fundametaalset laadi küsiused, millele vastused võivad suurel määral mõjutada süsteemi arendust ning funktsionaalsust tervikuna.
	Positiivse poole pealt tooksin välja, et soov, mida püütakse saavutada on siiski lahti kirjutatud ning mingi loogiline süstemi jaotus on tehtud ning programmeerijal on võimalus projekt luua ning funktsionaalsuse osad moodulitesse jagada. Kuigi taas tahan rõhutada, et asja muudaks oluliselt lihtsamaks ekraanivormide loetelu ning seal teostatavate teguvuste nimekiri(ekraanivormide hulk ja seal teostatavad tegevused on alati hea lähtepositsioon hinnangute andmisel), parimal juhul ka oodatav süsteemi käitumine kasutaja tegeuvsele.		Positiivse poole pealt tooksin välja, et soov, mida püütakse saavutada on siiski lahti kirjutatud ning mingi loogiline süstemi jaotus on tehtud ning programmeerijal on võimalus projekt luua ning funktsionaalsuse osad moodulitesse jagada. Kuigi taas tahan rõhutada, et asja muudaks oluliselt lihtsamaks ekraanivormide loetelu ning seal teostatavate teguvuste nimekiri(ekraanivormide hulk ja seal teostatavad tegevused on alati hea lähtepositsioon hinnangute andmisel), parimal juhul ka oodatav süsteemi käitumine kasutaja tegeuvsele.


			=Prototüübi retsensioon =
			Retsenseerija: Meeskond CRM/WPF tehnoloogial.


			Korralik projekt, rakenduse tööle saamine oli hea ja lihtne. Laadisin koodi alla, pakkisin lahti, avasin VisualStudios ning käivitasin. Kõik töötas kohe esimese katsega. Dokumentatsiooniga on palju vaeva nähtud. Meeskonna lehel on ilusasti välja toodud, mis funktsionaalsus prototüübis valmis on ning mis veel tulemas. Kaasas oli readme, kus oli vajalik, et rakendus tööle saada ja testida + SQL andmebaasi jaoks.

			Koodi kohta tooks välja, et ToDo tabelis staatus väli oli integer väli ning seal esinesid väärtused 1 või 0. Soovitaks, kui mitte baasi teha klassifikaatorid, mis oleks inimloetavad, siis võiks koodis kuskil enumid defineerida, millel oleks inimloetavad nimed ning neid kasutada.

			RahaTabel view-s sorteerimise loogika oli kõik pressitud ühte suurde sortBut_Click meetodisse ning leidus copy-paste koodi (iga välja järgi sorteerimine oli 3 rida sama koodi, ainus erinevus oli ascending/descending ning välja nimi). Kui seda sortimis loogikat ei ole võimalik tükeldada, siis dataGridi clear ja uue collectioni ette andmise oleks võinud if-idest välja tõsta ning panna see kohe pärast if-ide lõppu. Oleks 10 rea asemel 2st piisanud. Lisaks samal vaatel nuppude IsEnabled properti määramine võiks eraldi private meetodisse tõsta, seda leidub ka mitmes kohas.

			Muidu arhitektuuri poolelt oli loogiliselt üles ehitatud, View-d ViewModelid, BusinessObjectid ning service-d. Kuigi eriti ei meeldinud sellised nimed, mis koosnesid kahest keelest nt. RahaService -> RahaTeenus või siis teha kogu kood inglise keeles.

			Kasutajaliides mulle meeldis, ei pidanud kaua mõtlema, mis nupp mida teeb, kõik oli lihtne ja loogiline. Väike norimine sellel teemal, et UI komponendid ei liigu akna suuruse muutmise peale kaasa. Oleks võimalik määrata min suurus aknale, kus kõik komponendid ära mahuks ning siis ei pea selle pärast muretsema. Kuna tegu prototüübiga, siis see täiesti normaalne.

Amets: /* Retsensioon: Andres Mets */

2014-11-07T17:29:10Z

Retsensioon: Andres Mets

← Older revision		Revision as of 20:29, 7 November 2014
Line 1:		Line 1:
	=Retsensioon: Andres Mets=		=Retsensioon: Andres Mets=
	Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks ~~analüüis~~, mis oleks sisendiks disaini etapile- st. kirjeldaks süsteemi kasutajad ning nende konkreetsed tegevused ehk puuudvad kasutuslood nätieks on mainitud sisselogimise funktsionaalsus, mis näeb ette et logidest saab vaadata, kes millal on süsteemi kasutanud, kas logidest saavad kõik vaadata või süsteemis on realsieeritud mingi administraatori roll(see lihtsalt näide küsimusest, mis kindlasti tekib realsiatsiooni käigus), kui on realiseeritud süsteemis admisitraatori roll, siis kuidas saab süsteemis administraatoriks. Mis väärtus on üldse logidest süsteemi kasutust vaadata, kas sellest võiks olla huivtatud hoopis tarkvara pakkuja- eeldaks liidest tarkvara pakkuja ~~infosüsteemi~~ jne.		Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks analüüsi, mis oleks sisendiks disaini etapile- st. kirjeldaks süsteemi kasutajad ning nende konkreetsed tegevused ehk puuudvad kasutuslood nätieks on mainitud sisselogimise funktsionaalsus, mis näeb ette et logidest saab vaadata, kes millal on süsteemi kasutanud, kas logidest saavad kõik vaadata või süsteemis on realsieeritud mingi administraatori roll(see lihtsalt näide küsimusest, mis kindlasti tekib realsiatsiooni käigus), kui on realiseeritud süsteemis admisitraatori roll, siis kuidas saab süsteemis administraatoriks. Mis väärtus on üldse logidest süsteemi kasutust vaadata, kas sellest võiks olla huivtatud hoopis tarkvara pakkuja- eeldaks liidest tarkvara pakkuja infosüsteemiga jne.
	Sellise üldise analüüsi baasilt on väga raske määratleda süsteemi mahtu ning loodava funktsionaaluse hulka- analüüsi lugedes tekib küll arusaam süsteemile kehtestatud nõuetest, kuid nagu ülesande kitsaskohtade kirjelduses välja toodud puudub ülevaade süsteemi mahust ning loodava funktsionaalsuse ulatusest. Seega selle analüüsi põhjalt on raske siseneda disaini/implemtatsiooni faasi, programmi loomise käigus kerkivad esile fundametaalset laadi küsiused, millele vastused võivad suurel määral mõjutada süsteemi arendust ning funktsionaalsust tervikuna.		Sellise üldise analüüsi baasilt on väga raske määratleda süsteemi mahtu ning loodava funktsionaaluse hulka- analüüsi lugedes tekib küll arusaam süsteemile kehtestatud nõuetest, kuid nagu ülesande kitsaskohtade kirjelduses välja toodud puudub ülevaade süsteemi mahust ning loodava funktsionaalsuse ulatusest. Seega selle analüüsi põhjalt on raske siseneda disaini/implemtatsiooni faasi, programmi loomise käigus kerkivad esile fundametaalset laadi küsiused, millele vastused võivad suurel määral mõjutada süsteemi arendust ning funktsionaalsust tervikuna.
	Positiivse poole pealt tooksin välja, et soov, mida püütakse saavutada on siiski lahti kirjutatud ning mingi loogiline süstemi jaotus on tehtud ning programmeerijal on võimalus projekt luua ning funktsionaalsuse osad moodulitesse jagada. Kuigi taas tahan rõhutada, et asja muudaks oluliselt lihtsamaks ekraanivormide loetelu ning seal teostatavate teguvuste nimekiri(ekraanivormide hulk ja seal teostatavad tegevused on alati hea lähtepositsioon hinnangute andmisel), parimal juhul ka oodatav süsteemi käitumine kasutaja tegeuvsele.		Positiivse poole pealt tooksin välja, et soov, mida püütakse saavutada on siiski lahti kirjutatud ning mingi loogiline süstemi jaotus on tehtud ning programmeerijal on võimalus projekt luua ning funktsionaalsuse osad moodulitesse jagada. Kuigi taas tahan rõhutada, et asja muudaks oluliselt lihtsamaks ekraanivormide loetelu ning seal teostatavate teguvuste nimekiri(ekraanivormide hulk ja seal teostatavad tegevused on alati hea lähtepositsioon hinnangute andmisel), parimal juhul ka oodatav süsteemi käitumine kasutaja tegeuvsele.

Amets: Created page with "=Retsensioon: Andres Mets= Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks analüüis, mis oleks sisendiks disaini etapile- st. kirjeldaks süsteemi kasuta…"

2014-11-07T17:28:10Z

Created page with "=Retsensioon: Andres Mets= Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks analüüis, mis oleks sisendiks disaini etapile- st. kirjeldaks süsteemi kasuta…"

New page

=Retsensioon: Andres Mets=
Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks analüüis, mis oleks sisendiks disaini etapile- st. kirjeldaks süsteemi kasutajad ning nende konkreetsed tegevused ehk puuudvad kasutuslood nätieks on mainitud sisselogimise funktsionaalsus, mis näeb ette et logidest saab vaadata, kes millal on süsteemi kasutanud, kas logidest saavad kõik vaadata või süsteemis on realsieeritud mingi administraatori roll(see lihtsalt näide küsimusest, mis kindlasti tekib realsiatsiooni käigus), kui on realiseeritud süsteemis admisitraatori roll, siis kuidas saab süsteemis administraatoriks. Mis väärtus on üldse logidest süsteemi kasutust vaadata, kas sellest võiks olla huivtatud hoopis tarkvara pakkuja- eeldaks liidest tarkvara pakkuja infosüsteemi jne.
Sellise üldise analüüsi baasilt on väga raske määratleda süsteemi mahtu ning loodava funktsionaaluse hulka- analüüsi lugedes tekib küll arusaam süsteemile kehtestatud nõuetest, kuid nagu ülesande kitsaskohtade kirjelduses välja toodud puudub ülevaade süsteemi mahust ning loodava funktsionaalsuse ulatusest. Seega selle analüüsi põhjalt on raske siseneda disaini/implemtatsiooni faasi, programmi loomise käigus kerkivad esile fundametaalset laadi küsiused, millele vastused võivad suurel määral mõjutada süsteemi arendust ning funktsionaalsust tervikuna.
Positiivse poole pealt tooksin välja, et soov, mida püütakse saavutada on siiski lahti kirjutatud ning mingi loogiline süstemi jaotus on tehtud ning programmeerijal on võimalus projekt luua ning funktsionaalsuse osad moodulitesse jagada. Kuigi taas tahan rõhutada, et asja muudaks oluliselt lihtsamaks ekraanivormide loetelu ning seal teostatavate teguvuste nimekiri(ekraanivormide hulk ja seal teostatavad tegevused on alati hea lähtepositsioon hinnangute andmisel), parimal juhul ka oodatav süsteemi käitumine kasutaja tegeuvsele.