Talk:Meeskond: KTM Development: Difference between revisions

From ICO wiki
Jump to navigationJump to search
Aameerik (talk | contribs)
Created page with "=Retsensioon meeskond KTM Developmentile= Koostanud: Sporto ==ÜLDINE ARUSAADAVUS== Projekti grupitöö haldus programm teema on arusaadav, kuid edasine analüüs tekitab m..."
 
Aameerik (talk | contribs)
Line 1: Line 1:
=Retsensioon meeskond KTM Developmentile=
=Retsensioon meeskond KTM Development projekti analüüsile=


Koostanud: Sporto
Koostanud: Sporto

Revision as of 13:53, 8 November 2015

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.