Talk:Meeskond:LifePlanner: Difference between revisions
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…" |
|||
Line 1: | Line 1: | ||
=Retsensioon: Andres Mets= | =Retsensioon: Andres Mets= | ||
Analüüs on tehtud liiga üldine, tuleb märkida, et siinkohal ootaks | 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. |
Revision as of 19:29, 7 November 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.