Talk:Meeskond: KTM Development

Retsensioon meeskond KTM Development projekti analüüsile

Koostanud: Sporto

ÜLDINE ARUSAADAVUS

Projekti grupitöö haldus programm teema on arusaadav, kuid edasine analüüs tekitab mitmeid küsimusi. Eesmärk on teha rakendus vähendamaks tööd segavaid faktoreid ning tõsta selle efektiivsust, aga põhjendamata jääb, mis on täpsemalt need faktorid ning kuidas nende programm grupitöö efektiivsust tõstab.

Funktsioonid ja protsessid on kirjeldatud arusaamatult - keelekasutus tekitab küsitavusi terminites ja rakenduse töö jääb segaseks. Lisaks mõned protsessid ei täida eesmärki. Näiteks grupi tavaliige, kellele on pandud “To-Do task”, ei saa ise seda muuta, vaid peab kirjutama “adminile” ja alles tema saab “To Do listi” seisundit muuta. See on pigem grupitöö efektiivsuse pidurdamine. Vestluse haldamine ja puhtana hoidmine on läbi mõtlemata - liikmed saavad ikka teemavälist juttu ajada, eesmärk oli aga see likvideerida. Küsimusi tekitab viie sekundi järel ootamine - kiires arutelus takistab protsessi.

Tuleks veel täpsemalt läbi mõelda, kellele rakendus on mõeldud. On selgitamata millist kasu saavad erinevad nimetatud sihtgrupid antud rakendusest. Näiteks, millist kasu saab õpetaja sellest rakendusest, kui õpetajal on ainult kolm gruppi, aga klasse on tavaliselt rohkem kui kolm ja mis oleks tema eesmärk seda rakendust kasutada?

Lisaks iga funktsioon ja protsess peaks kõrvutama eesmärgiga ning kontrollima kas ja kuidas ta aitab selle saavutamisele kaasa. Teisisõnu liigsed funktsioonid pikendavad protsessi ja pole vastavuses esialgse eesmärgiga kergendada ning lihtsustada grupitööde tegemist.

Selgitamata on, mis on dashboard?

KEELEKASUTUS

Keelekasutuse koha pealt ei tundu olevat analüüsi dokumendiga, kuna pole ametlik. Ei soovita kasutada sina-vormi, selle asemel oleks hea ja viisakas tava umbkaudne kõneviis (kasutaja siseneb, kasutaja teeb jne). Miinuseks on kõnekeele või slängi kasutus lõigus üldine: “Nagu öeldakse, et "don't put all your eggs in one basket, siis meie eesmärgiks on luua eraldi keskkond”. Taoline keelekasutus ei sobi tarkvara analüüsi dokumenti. Oluline on ka kasutada sünonüüme vältimaks korduseid. Tooks välja läbiva korduva sõna “väga”, mida esines mõnel juhul ühes lauses mitmeid kordi ning ka järjestikustes lausetes silmatorkavalt palju.

Üldiselt pole liigselt kirjavigu, kuid mõned tooks välja: effektiivne (õige efektiivne), tavakasutajasõbralik (kasutajasõbralik - eelnevalt juba välja toodud, et mõeldud mitte tehnikateadlikele).

KASUTAJALIIDES

Töölaua vaade tundub olevat liiga tihe hetkel.

• Terve vasak pool võiks olla peidetav/tabitav. Tegu on suhteliselt staatiliste väljadega, millele ei ole vaja jooksvat ligipääsu igal ajahetkel.
• Chatbox võiks olla pigem vertikaalsem, kui horisontaalne. Üldiselt suurem.

Raske öelda, mis peaks olema kõigile ühiselt nähtavad ja mis on sisselogitud kasutajatele erinev:

• Mida saab ainult Admin muuta ja mis on muudetavad tavakasutaja poolt?
• Lingid ja failid on kõigile ühised? Kas kasutaja saab enda task-i spetsiifilisi linke panna?
• ‘Ülesande täielik detailne püstitus’ on mõeldud hetkel sisselogitud kasutaja Task-i kohta?

TEHNOLOOGIA KASUTUS

Kohati jäi mulje, et segamini on aetud versioonihaldustarkvara ja meeskonnatöö organiseerimistarkvara. Tõsi, mõlema puhul on kasutajaid rohkem kui üks ja nendevaheline töö peab olema organiseeritud. See tähendab, et tarkvara peab olema kas veebirakendus või võrgurakendus. Igal juhul tuleks realiseerida mitmekihiline arhitektuur (multi-tier architecture).

Antud analüüs on kirjutatud meeskonnatöö organiseerimistarkvarast ja ilmselt plaanitakse ka võrgurakenduse arendust. Jääb arusaamatuks, kuidas üks grupitöö rakendus plaanib toimida mitme kasutaja puhul. Kas kõik grupi liikmed kasutavad seda ühes arvutis või on võimalik seda kasutada üle võrgu. Analüüsist jookseb läbi sõna „andmebaas“, aga pole seletatud, kuidas toimub ühendus andmebaasiga (ehk Serveriga) ja mis takistused võivad ilmneda ühenduse loomisel. Analüüsist on välja jäänud see oluline osa, mis kirjeldab, kuidas rakendus töötab mitme kasutaja vahel.

PUUDUSED JA KÜSITAVUSED

• Arusaamatu on gruppide arvu piiramine kuni 3 grupini ja selle ajaline kestus (Kas samal ajal või kokku? Kas vana grupi peab kustutma, et uut saaks alustada? Kas ajalugu säilib? Kui kauaks?).

Kuna tööriist on ka vahendiks õppejõule, siis tekib temal rohkem gruppe. Samuti võib üliõpilastel ühe semestri jooksul rohkem gruppe tekkida. Piirangu vajadust ei ole põhjendatud.

• Milleks on vaja nii täpne registreerimine (vastuolu lihtsusega)?

Klassi või kursuse registreerimise probleem: kas läheb igaaastaselt edasi või peab ise iga aasta kinnitama? Mis juhtub, kui minna gümnaasiumist ülikooli? Kui kasutaja on akadeemilisel puhkusel, või ei õpi üldse? Idee: Nice to Have: Valikus sisselogimine olemasolevate kontodega. (Facebook, Gmail, LinkedIn, kooli email)

• Grupi parooli kasutamine. Kas grupi parool eristab kõiki gruppe? Kas teised, kes parooli ära arvavad tohiks kohe liituda? Kas admin või tavakasutaja kinnitab liitumise?
• Töö kirjelduses on näha algsete mõtete kirja panekut ning hiljem nende täiendamist. Kuid siis on jäetud vanade funktsionaalsuste kirjeldused samaks. Näiteks gruppide muutmise osas on esimesena mainitud kirjelduses, et muudatusi saab teha ainult admin kasutaja, hiljemas kirjelduses tuleb mängu lisa admin.
• Teateid võiks saada lisada kõik kasutajad. Võiks olla valikus, kas teadetetahvel on kasutamiseks kõigile või ainult adminitele.
• To-Do listi saavad lisada ülesandeid ainult adminid. Samamoodi võiks siin olla valik, kes lisada saavad.
• Projekt vajab kasutajaõiguste ja gruppide haldamist, et paremini piirata või anda õiguseid erinevatele süsteemi väljadele.
• Tag-ide süsteem on läbi mõtlemata ja ei sobi antud ülesandega kokku. Tekib oht, kus kiire töö märgitakse erinevate sõnadega, nt: #kiire või #kiire töö. Pigem võiks olla ülesannetes eeldefineeritud prioriteedid ning vajadusel saab neid nende järgi järjestada.
• Rakenduse kasutamisest õppejõu poolt on halvasti kaetud. Selgitamata on funktsionaalsused õppejõu ja traditsioonilise grupitöö vahel. Samuti ei olnud sellest räägitud sissejuhatuses.
• Kasutajaliidese pilt sobib esialgseks variandiks teadmaks, mis väljasid projektis vaja läheb, kuid läbi mõtlemata ja kirjeldamata on erinevad vaated ning kuidas neid parema *kasutajakogemuse saamiseks kuvada.
• Kasutatavate tehnoloogiate nimistu on tegemata. (Rakenduse suhtlus kasutajate vahel)
• Välja toomata on ka potentsiaalsed probleemid ja murekohad.

KOKKUVÕTE

Eesmärk on üldiselt arusaadav, aga selle realiseeritavus on suhteliselt hägune. Jääb segaseks, miks mõned otsused on tehtud ja mõningad punktid räägivad üksteisele vastu. Kas on ikka üle võrgu ning kui jah, siis kuidas?

Idee on prespektiivikas, kuid mitmed aspektid on läbi mõtlemata ja seetõttu ei kutsuks väljatöötatud “Simple Team Manageri” veel kasutama.

KTM prototüübi retsensioon

Koostanud: Sporto

Hea

• Projekt on jaotatud kolme kihi vahel: WPF, DAL ja BLL.
• BLL all on juba loodud ProjektService ja KasutajaService klass, kus on juba mõningad meetodid andmebaasi poole pöördumiseks.
• Andmebaas olemas.
• On ka loodud mõned BO klassid.
• Disain on kena.

Murekohad ja soovitused

• XAML
  • Tõsta vaated eraldi kausta, aitab paremini aru saada.
  • CodeBehind-is olevad päringud üle viia Service-te alla

Näiteks: “bool emailOlemas = db.KASUTAJASet.Any(kasutaja => kasutaja.Email.Equals(txtEmail.Text));” päringu koht oleks samuti KasutajaService klassis ja näiteks “IsUniqueEmail(txtEmail.Text);” meetodi sees.

• • Pole kasutatud dünaamilist disaini ehk kasutamata Grid-i võimalused laiuse ja kõrguse määramiseks joondamisel. Hetkel käe järgi sätitud elemendid.
  • Registreerimise vormil peaks olema “tühista” vasakul ja ”registreeri” paremal, nagu tava ette näeb. Käsu täitmise nupp paremalpool teistest.
• Salasõnasid hoitakse andmebaasis lihttekstina.
• ViewModel-id on tühjad, praegu asub funktsionaalsus vaadete taga.
• Funktsionaalsus:
  • Registreerimisel tuleb kohe emaili kontrollimisel veateade, mis programmi kokku jooksutab.
  • Lisades uut projekti ei uuendata projektide nimekirja automaatselt, vaid selleks peab eraldi nuppu kasutama.
  • Andmebaasi lisades genereeritakse ise ID viimase sisestuse järgi - peaks olemas autogenerated.
• Pikad lohisevad "and-if" kontrollid

Näiteks: “if(!string.IsNullOrEmpty(txtEesnimi.Text) && !string.IsNullOrEmpty(txtPerenimi.Text) && !string.IsNullOrEmpty(txtPwd.Password) && !string.IsNullOrEmpty(txtEmail.Text) && txtPwd.Password == txtPwd2.Password)”

Võiks olla eraldi boolean meetod "AllInputsFilled();" Parandab koodi loetavust

• Ühtlasem keelekasutus
  • Andmebaas ja suur osa funktsioonidest on eesti keeles kirjutatud.
  • ProjectsVM-is leiduvad funktsioonid loadDataFromDB(), laemeilid(), lisaProjektiMeeskonda(string email). Kõigil kolmel on erinev tava.
  • Funktsioonisisesed muutujad on kohati imeliku nimega, arvatavasti on kopeeritud kuskilt mujalt ja jäänud muutmata.

Kokkuvõte

Näha, et hetkel on projekt väga algusjärgus. Põhikihis on loodud neli vaadet ning suurem osa loogikast on CodeBehindis. Disain on kena, kuid tähtsam on saada projekt liikuma, iluga saab lõpus tegeleda. Soovitaks organiseerida vaated, tõsta funktsionaalsused View-de tagant ära.

Prototüübi jaoks natuke vähe tehtud - oleks võinud luua vajalikud vaated, et saada parem ülevaade sellest, kuidas projekti tahetakse realiseerida.

KTM valmistoote retsensioon

Prototüübi plussid säilisid, seega kena disain, andmebaas, projekti jagatus on kõik plussid.

Plussid:

• Õpetus olemas.
• Korralikult kommenteeritud.
• Hästi struktueeritud (kuigi mingipärast pole view-d 'Views' kaustas).
• Registreerimisel kontrollid ja arusaadavad veateated.

Negatiivid:

• Suur osa koodi view taga (Peale 'mainwindow' ja 'Projects', kus loodakse view taga vm ja siis pöördutakse selle poole).
• Korduvat koodi näiteks väljalogimisel, kus oli kaks funktsiooni sama sisuga, kuigi erineva event-i peale. Oleks võinud mõlema korral kolmanda funktsiooni välja kutsuda.
• Peale registreerimise ja sisselogimise ei saanud edasi testida, kuna uue projekti loomisel annab veateate.