Talk:Meeskond:LifePlanner: Difference between revisions

From ICO wiki
Jump to navigationJump to search
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.

Revision as of 23:32, 20 December 2014

Retsensioon: Andres Mets

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. 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.