Talk:Ajamasin: Difference between revisions
Line 11: | Line 11: | ||
=== Funktsionaalsus === | === Funktsionaalsus === | ||
Väga mahukas ettevõtmine! | Väga mahukas ettevõtmine ning väga täpselt on kirja pandud kasutaja käitumine! | ||
Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides | |||
Soovitaks korraks hinnata töö tegijatel, kaua võib nende erinevate osade programmeerimine aega võtta ning hinnata, kas saadakse valmis õigeks ajaks ja võib-olla kaaluda funktsionaalsuse vähendamist. (N: alustada prototüüpimist ainult tööpakkumise sisestamisest/kustutamisest, vaatamisest ning vastuvõtmisest) | |||
Hetkel jääb selgusetuks, kuidas erinevaid kasutajaid eristatakse, kas olemas on sisselogimise funktsioon või saab iga kasutaja anonüümselt valida, kes ta on ning kui tuleb sisselogimise funktsioon, siis kes tegeleb kasutaja registreerimisega, kasutaja ise või organisatsiooni HR? | |||
Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides. | |||
Töö algus ja lõpu aega soovitaks märkida kellaaegadega, kuna isegi organisatsiooni siseselt võivad töö algus / lõpu kellaajad olla erinevad (võimalikud ka öövahetused). | |||
Sellest lähtuvalt, kas kuhugi läheb hiljem kirja ka palju tööd tehti või on arvestus selle järgi, et inimesed käivad tööl lepingu alusel 8-17.00 (16.00) ja siis valivad selle järgi, organisatsiooni siseselt, kus nad töötada tahavad? | |||
"Organisatsioonisiseste tööpakkumiste sirvimise moodul töötajale" - mitte kuskilt ei tule välja, kus kohas peaks olema töötajale see nupp, millega ta saab ennast mingile tööpakkumisele registreerida (küll on jutt sellest, kuidas ta saab ennast maha registreerida) | |||
"vastuvõetud – kui tööpakkumise juurde märgitakse selle töö vastu võtnud isiku andmed, muudetakse pakkumise staatus „vastuvõetud“" - segane lause, kas tööpakkumise juurde märgitakse isiku andmed süsteemi poolt automaatselt kui ta registreerib või kes märgib? | |||
=== Andmebaas === | === Andmebaas === |
Revision as of 22:34, 13 November 2016
Ajamasinat retsenseeris meeskond Isearve, Siim Kallari ja Priit Tiganik
RETSENSIOON ON VEEL KIRJUTAMISEL
Arhitektuur
Loodetavsti saan õigesti aru, et rakendus koosneb praeguse visiooni kohaselt kahest peamisest nö eraldi programmist või vaatest, mille aluskood on ilmselt üpris sarnane, kuid tegu on siiski täiesti eraldiseisvate programmidega, mis on ühendatud vaid andmebaasi kaudu.
Funktsionaalsus
Väga mahukas ettevõtmine ning väga täpselt on kirja pandud kasutaja käitumine!
Soovitaks korraks hinnata töö tegijatel, kaua võib nende erinevate osade programmeerimine aega võtta ning hinnata, kas saadakse valmis õigeks ajaks ja võib-olla kaaluda funktsionaalsuse vähendamist. (N: alustada prototüüpimist ainult tööpakkumise sisestamisest/kustutamisest, vaatamisest ning vastuvõtmisest)
Hetkel jääb selgusetuks, kuidas erinevaid kasutajaid eristatakse, kas olemas on sisselogimise funktsioon või saab iga kasutaja anonüümselt valida, kes ta on ning kui tuleb sisselogimise funktsioon, siis kes tegeleb kasutaja registreerimisega, kasutaja ise või organisatsiooni HR?
Kas töö mahu arvutamine ja hind on täispäevade kaupa? Hetkel see paistab nii oelvat, kuigi päriselus käib arveldamine tavaliselt töötundides. Töö algus ja lõpu aega soovitaks märkida kellaaegadega, kuna isegi organisatsiooni siseselt võivad töö algus / lõpu kellaajad olla erinevad (võimalikud ka öövahetused). Sellest lähtuvalt, kas kuhugi läheb hiljem kirja ka palju tööd tehti või on arvestus selle järgi, et inimesed käivad tööl lepingu alusel 8-17.00 (16.00) ja siis valivad selle järgi, organisatsiooni siseselt, kus nad töötada tahavad?
"Organisatsioonisiseste tööpakkumiste sirvimise moodul töötajale" - mitte kuskilt ei tule välja, kus kohas peaks olema töötajale see nupp, millega ta saab ennast mingile tööpakkumisele registreerida (küll on jutt sellest, kuidas ta saab ennast maha registreerida)
"vastuvõetud – kui tööpakkumise juurde märgitakse selle töö vastu võtnud isiku andmed, muudetakse pakkumise staatus „vastuvõetud“" - segane lause, kas tööpakkumise juurde märgitakse isiku andmed süsteemi poolt automaatselt kui ta registreerib või kes märgib?
Andmebaas
Andmebaasi tabelite arv tundub antud töö jaoks olema täiesti piisav ning nende sisu asjakohane. Paar mõtet andmebaasi ülevaadet lugedes siiski tekkis.
- Esiteks ei saa selle praegusest kirjakujust liiga hästi aru, kuidas üks tabel teisega seotud võib olla. Siin võib abiks olla, kui kasutada üle kogu andmebaasi unikaalseid väljade nimetusi. Näiteks Pakkumise id oleks nimetusega pakkumine_id ja Asukoha id oleks asukoht_id.
- Kasutades eelnevat loogikat peaks olema näha, et antud hetkel on andmebaasi skeemis osad id-d kirjas ainult ühe korra, mis omakorda tähendab seda, et selliste id-dega tabelid pole skeemi järgi ühegi teise tabeliga seotud. Tabelid Asukoht ja Staatus paistavad olevat sellised tabelid, mille sisu ei saa hetkel kuskil mujal kasutada, kuna nende id-sid muudes tabelites ei leidu. Kuna mõlemad on loogiliselt kõige rohkem seotud pakkumisega, peaks Pakkumiste tabelit täiendama kahe väljaga: asukoht_id ja staatus_id. Väli "staatus" on küll pakkumiste tabelis olemas, kuid hetkel jääb arusaamatuks selle funktsioon, kui on olemas eraldi tabel Staatus.
- Väga hea, et analüüsi käigus on selgunud vajadus pakkumist ja isikut siduvale tabelile, kuna ühel pakkumisel võib olla mitu tööotsijat ja üks tööotsija võib kandideerida ka mitmele erinevale pakkumisele.
- Ehk soovite pakkumisele lisada ka pakkumise tegija? Näiteks teavad tööotsijad siis kellegi käest lisainfot küsida. Selle tarvis võib pakkumise tabelisse siiski ühe isik_id välja lisada, aga see oleks siis pakkumise looja või kontaktisiku id. Lisainfo (nt nime) saaks siiski tuua juurde tabelist Isik.
- Pakkumiseisik ja Logi tabelis on puudu unikaalne id. See pole absoluutselt vajalik, kuid kunagi kahjuks ka ei tule.
- Analüüsi funktsionaalsust kirjeldavas osas on algust tehtud juba ka andmete tüüpide kirjeldamisega, mis on väga hea. Pigem võiks seda teemat ilmselt just andmebaasi skeemi osas puudutada, sest siis ei peaks seda iga funktsionaalsuse juures eraldi tegema ning väheneb tõenäosus näpukatele. Näiteks paistab üks selline olevat ürituse ja positsiooni tekstiväljade pikkuse muutus vastavalt funktsionaalsuse kirjeldusele. Igaks juhuks mainime ära, et andmebaasi enda eelistatud kuupäeva formaat on YYYY-MM-DD.