Talk:Meeskond: QView
Retsensioon XML'ile
Retsenseeris meeskond Falador
Meeskond QView tegi XMLi autode nimekirja kohta. Nimekirjad on kapsuleeritud “cars” alla ja kohe alguses on ehitatud erinevate atribuutide puud kere tüübi, kütuse tüübi, tootja, käigukasti ja vedavate telgede definitsioonid ja siis peale seda autod.
Selline ülesehitus on hea viis olla väga organiseeritud ja ühtlane nii, et andmestikus ei kasutaks mõnele keelele spetsiifilist tekste mis võiks näiteks vene ja inglise andmebaaside andmete grupeerimist ja sorteerimist takistada. See aga teeb XML enda lugemist ilma stiililehe või XSLT-ta natuke raskemaks kuna on vaja mitmeid atribuute id-de järgi ülevalt otsida.
Samuti selle jaoks kasutatakse tugevalt ära ka elementide atribuutide määramist kuid on vajalikud väljad ikka pandud omaette elementide sisse mis ei pruugi sobida atribuudiks panemist nagu näiteks kommentaarid. Küll aga pole kasutatud antud XMLis üldse CDATA väljadel mis võivad tulla mujalt ja võivad näiteks ära lõhkuda XMLi struktuuri.
Lisaks on meie arvateks probleemiks XMLi ülesehitusel atribuutide ühikute puudulikkus, auto võimsusel on küll ühik kaasas aga läbisõidul ja hinnal need puuduvad. Hiljem on raske arvata mis ühikus mõni asi on ning autode võimsuste andmete töötlemisel või võrdlemisel tuleb stringi parsida, et teada saada kui võimas auto tegelikult on.
XMLi skeemifail on loodud hästi. Tüüpideks on õigesti valitud kas asi on unsignedByte või Int vastavalt eeldatavale andmemahule (kuigi meie paneksime ka sellistele väiksematele ID-dele Int tüübid külge igaks juhuks). Küll aga võiks mõnes kohas olla natuke liberaalsem piirangutega ehk nagu näiteks lubada ühe auto alla mitu kütuse tüüpi nagu näiteks bensiin + gaas või elekter + bensiin. Üldiselt on aga hästi ära märgitud mida kindlasti on vaja xmli kaasa anda ja mida mitte.
XSLT faile on loodud kokku kolm, kaks neist on HTMLid ja üks XML. Esimeses XSLT HTMLi omas puudub tingimuste kontrollid küll aga on need olemas teises XSLT HTMLis ning üleüldiselt on need hästi üles ehitatud. XSLT XML failis võiks olla kasutatud ka atribuudid, näiteks hinna ja läbisõidu ühik ja käikude arv, samas aga on kasutatud auto võimsusel arvu ja ühikut koos. See ebakõla võib tekitada hiljem segadust ja hilisema andmetetöötluse raskemaks.
Kokkuvõtteks on kõik töö aspektid tegelikult hästi tehtud ning näitab et meeskond hoomab XML, XSLT ja XSD loomist.
Retsensioon Team Echo poolt
Klient
Klientrakendusega on palju vaeva nähtud. Meeskond on näinud vaeva, et rakendus teha angularis. Meeskond on täitnud oma must have funktsioonid. Veebileht on kiire ja lihtsasti ülesehitatud. Näha on, et meeskond sattus ajahätta, sest mõndades funktsioonides on bug’id. Näiteks ei arvuta kohe välja keskmist aega järgmise piletini. Meeskond mainis ka kaitsmisel, et neil jäi aega natuke väheks. Üldiselt töötab kõik mis vaja, ning rakendust saaks implemeteerida kohe mingi süsteemiga. Kood on tehtud õigesti, ning ka type scripti on kasutatud korrektselt. Tööga on vaeva nähtud. Failide paigutus projektis võiks olla natukene parem, aga seda nad mainisid ka ise kaitsmisel. Üldiselt suuri etteheitmisi ei ole ja meeskond on teinud head tööd. Hindeks paneks neile hoolimata mõnest bug’ist maksimumi, kuna sellega on kõvasti pingutatud soovitud tulemuseni ja enda seatud must have kriteeriumid on täidetud.
Veebiteenus
Koodis on olemas funktsionaalsust isegi rohkem kui seda frondis näidatakse. Vaeva on nähtud palju. Meeskond on isegi teinud endale eraldi WPF rakenduse, mis aitab neil testida. WPF rakendus annab meekonnale võimaluse “dummy Datat” genereerida. Koodi ülesseehitus on arusaadav ja lihtsasti loetav. Kogu projekti ülessehitus vastab meilt nõutud nõuetele. Kasutatud on õigesti serviceid. Kood on hästi vormistatud ja on tehtud mitmesuguseid baasklasse, et teha elu lihtsamaks, ning kasutada objektorienteeritud programmeerimist. Koodis pole üleliigseid mittevajalike asju. Kasutatud on erinevaid andmete valideerimismeetodeid. Annotatsioonid on olemas ja korrektsed. Kasutaja autentimisega on vaeva nähtud. Üldiselt ei ole koodi kohta midagi halba öelda. Hea näide teistele kuidas teha. Hindeks paneks kindlasti 100/100. Väga hea töö.
Retsensioon veebiteenusele
Retsenseeris meeskond Falador
Meeskond QView on valinud esmase pilguga väga kerge süsteemi ja kergele probleemile lahenduse kuid millel võib tegelikult päris elus olla väga kasulik mõju. Kes meist varem poleks jõudnud kõneoperaatori esindusse või postkontorisse just tipptunnil ja lihtsalt passinud tühja oodates millal rivi väga vaikselt kahaneb.
Meeskond QView on oma veebiteenuse analüüsi teinud väga napisõnaliselt, kirjeldus ainult 49 sõna, kasutajate võimalused 60 sõnaga ja must have/nice to have ka 45 sõnaga.
Kirjeldus puudutab paari lausega feature’id mida nad soovivad lisada nagu nimekiri teenindus punktidest, kui kaugel hetkel kassad on ja prognoositav aeg kuni kliendi kord saabub kuid eriti viimasel ei seleta ära mis süsteem on neil plaanis luua, et usaldusväärset aega kliendile pakkuda. Statistikaliselt saab läheneda sellele probleemile kas väga suure kirvega mingi standard aeg panna ehk väga suure veaga või siis minnes äärmiselt täppisteaduseks kasutades eelnevate külastuste aegu antud teenindus puntkis antud teenindajatega ja iga kasutaja oma “kiirust” võrreldes vastavalt keskmise külastus kiirusega.
Mõningad feature’id mis võiksid olla meie arvates: piletite ette broneerimine, oma pileti ära andmine või kellegagi vahetamine ja piletite tühistamine. See kõik käiks aga kokku sellega kui pilet ja klient oleksid seotud. Kõik see lubaks luua statistikat ja reaalsemat ooteaega, kuna kogu ajalugu iga pileti kohta on olemas.
Oleks soovinud näha ka detailsemat nimekirja erinevate kasutajate õiguste ja võimaluste kohta. Kuigi admini juures “Adminil on õigus muuta rakendust ning lisada uuendusi” katab suhteliselt kõik võimalused, oleks võinud laskuda detailidesse mida administraatorid saavad muuta/lisada/kustutada.
Üks pool on hetkel üldse ära jäänud mis on nimelt firma poolne kliendi teeninduse külg kuna kassade taga olevad klienditeenindajad peavad ka kuidagi teenusele ju teadma andma kas nad on lõpetanud kliendiga tegelemise ja võtavad vastu uue. Samuti ei puuduta analüüs midagi selle kohta et ühes teeninduspunktis võib olla mitu liini nagu näiteks ARKis kus paralleelselt vastavalt teemale saavad vaid teatud inimesed teatud probleemidega teenindada.
Nende must have ja nice to have nimekirjas samuti sooviks veidi rohkem detaile. Lemmik teeninduspunktide lisamine kasutajate kohta ei tundu olevat nagu must have feature ja võiks kuuluda pigem nice to have. Selle puudumine ei mõjuta teenuse põhifunktsionaalsust.
Meeldiv, et nad lisasid andmebaasi struktuuri analüüsi, see näitab täitsa kuidas teoorias võiks süsteem ülesse ehitatud olla. Küll aga on näha et ka see on kiiruga ja tsipa mõtlemata tehtud. Antud andmebaasiga on võimalik teha must have funktsionaalsus kuigi struktuuris leiame me palju ebakõlasid ja arusaamatuid kohti. Nagu näiteks mille jaoks on vaja CompanyType? Samuti iga kontor on eraldi seotud Region ja Cityga kuigi meie loogika ütleb et üks võiks teise all olla, kas siis Region on maakond nagu harjumaa, siis City Tallinn läheks selle alla või Region nagu Mustamägi mis läheks City alla. Pole selgitatud mis asi mis on. Andmebaasist loeb välja et piletitel on tüübid olemas ehk mitme liini teema on rahuldatud kuigi tüübid on üldised? Meie loogika ütleks ka seda et pileti tüübid on igal firmal unikaalsed ehk ARK ja EMT ja Eesti Post ei oma samu teemasid. Hetkel pole ka piletid seotud kasutajatega ehk ei ole mingit viisi jälgida mis pileti keegi võttis kasvõi kliendi poolseks järelvaatamiseks. Samuti andmebaasi struktuuris puudub täielikult firma klienditeenindaja poolne osa kuigi kuna seda polnud ka analüüsis mainitud, siis arusaadav miks seda ka andmebaasis ei kajastu.
Kokkuvõtteks on tegu tegelikult hea teemaga millel on potentsiaali aga analüüs on ilmselgelt tehtud liialt kiirustades ja mitte süvenedes mida kõike võiks projektis teha. Eriti kuna meeskond koosneb 5st inimesest, ootaks et analüüs võiks olla vähemalt pool retsensioonist mis meie siia kokku kirjutasime.
