Talk:Ajamasin

Ajamasinat retsenseeris meeskond Isearve, Siim Kallari ja Priit Tiganik

Arhitektuur

Loodetavsti saame õ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. Kui nii, siis kahe programmiloomine ja haldamine võib mõnes mõttes olla lihtsam (funktsionaalust saab eraldiseisvalt täiendada, ühe programmi muudatused ei tohiks teist segada jne), kuid võib pikemas perspektiivis tekitada ka probleeme (alguses kohati sarnane kood võib kahe programmi lõikes kiiresit muutuma hakata ning mingi aja pärast võib olla vaja hallata kahte täiesti erinevat programmi).

Põhimõtteliselt võib kodutöö koosneda ka ainult ühest programmist, aga selle sees on siis kuidagi (nt sakkidega) eristatud pakkumise loomine ja kandideerimine. Kuna asi töötab ühe ettevõtte sees, siis ilmselt on täiesti võimalik olukord, kus üks isik on nii pakkumiste looja kui ka kandideerija. Kuna selliseid rolle kuigipalju siiski olla ei saa, siis saab pakkumiste loomist kasutajaõigustega piirata.

Tundub, et ideaalsel juhul peaks praeguse rakenduse puhul tegemist olema klient-server rakendusega, kus kogu loogika on serveri poole peal. Antud programmi kirjeldus viitab aga sellele, et kogu loogika asub siiski kasutaja arvutis asuvas programmis. Ilmselt saab kodutöö eesmärgid ka nii täidetud, kuid kui soovida sama süsteem reaalselt mitmete kasutajatega tööle panna, siis võib tekkida mitmeid probleeme nagu näiteks sama ürituse samaaegne muutmine mitme isiku poolt vms.

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.