Talk:Isearve

Retsensioon projekti Isearve analüüsile

Analüüs on põhjalik, ekraanipiltidega ning hästi loetav. Loodav programm tundub käesoleva aine raames mõistliku suurusega ning selle funktsionaalsus on arusaadav ning asjalik. Arvestades, et tegemist on n-ö oma tarbeks tehtud analüüsiga, võib seda pidada igati ontlikuks. On näha, et meeskond on projekti enda jaoks läbi mõelnud ja teab, kuidas sellega pihta hakata ja ka lõpuni jõuda.

Et aga meie lugesime seda analüüsi võõra retsensendi pilguga, siis tooksime siiski välja mõned küsimused, mille üle meeskond võiks mõelda (ja mida nad võivad peale järelemõtlemist soovi korral ignoreerida).

1. Funktsionaalsus

1.1. Tsitaadid analüüsist: “Alustab uue arve loomist nullist või võtab aluseks mõne eelmise arve.” ja "Arve number luuakse programmi poolt, kuid kasutajal on võimalik seda muuta." Näeme, et programmis võib tekkida oht, et kasutaja alustab uue arve tegemist vana arve pealt, kuid ei muuda ära andmeid, mis peaksid iga kord erinevad olema (kuupäev, arve number). Tulemuseks on valede andmetega arve või mitu arvet sama numbriga. Analüüsis võiks olla kirjeldatud, kuidas sellist ohtu vältida: kas täiendavad kontrollid arve numbri osas või teatud andmete vanalt arvelt uuele mittekopeerimine.

1.2. Programmis ei tundu olevat erinevaid arveliike (ettemaksuarve, kreeditarve), mistõttu ei saa programmi võtta aluseks kogu raamatupidamisele. See omakorda tähendab, et firmal ei ole ka mingit põhjust arveid selles programmis tasutuks märkida - reaalne finantsraamatupidamine jääb paratamatult teise programmi ning samu andmeid topelt sisestada pole kellelgi huvi.

1.3. Analüüsis on kirjeldatud arve kustutamise nupp, kuid ei ole lahti seletatud, mida see täpsemalt teeb. Kas arve märgitakse arhiveerituks või kustutatakse see reaalselt ka andmebaasist? Samuti ei selgu, kas arveid saab ka muuta, ja kui saab, siis kuidas ning mis tingimustel.

1.4. Andmebaasi kasutajate haldus on nice-to-have nimekirjas. Andmebaasi user tabelis on väli user_id, mis meie arusaamist mööda peaks siis olema ettevõtte id-number. Segaseks jääb, et kas sama süsteemi saab siis kasutada mitme eri ettevõtte arvete väljastamiseks? Otsest probleemi me selle koha peal ei näe, aga analüüsist oli seda infot esimese korraga üsna raske välja lugeda.

1.5. Nice-to-have nimekirjast valiksime tegemiseks esmalt e-postiga arve saatmise võimaluse, see suurendaks oluliselt kasutajamugavust. Kui andmebaasis ei kasutata standardset e-arvesüsteemi xml-formaati (mis on päris kohutav, vt http://www.pangaliit.ee/images/files/E-arve/Eesti_e-arve_kirjeldus_ver1.2_est.pdf ), siis võib pigem loobuda xml-formaadis arve koostamisest, mis on kirjeldatud must-have funktsionaalsuse all. Hetkel ei saanud analüüsist päris täpselt aru, kellele ja mis otstarbel kasutamiseks selline redutseeritud xml-arve on mõeldud.

2. Andmed ja andmebaas

2.1. Andmebaasis on tänav, maja, korter eraldi väljadena, kuid sisestamisvormil on see üks väli. Kuigi tehniliselt on võimalik neid ühest väljast ka lahti harutada ja eraldi salvestada, on see oluliselt keerulisem ja veaohtlikum kui kolme sisestusvälja kasutamine. Kui tegemist on Eesti kasutajale suunatud programmiga, siis soovitaksime kaaluda ADS-formaadis aadressi sisestust.

2.2. Tsitaat analüüsist: “Andmebaas peab koosnema vähemalt neljast tabelist”. Mainime lihtsalt meeldetuletuseks, et kodutöö juhendis oli soovituslik tabelite arv vähemalt kuus. Andmebaasi mudeli juures oleksime hea meelega näinud, mis tüüpi salvestatavad andmed on.

2.3. Andmebaasis on pangakontod piiratud nelja pangaga. Võib-olla tasuks pangakontod eraldi tabelisse paigutada, nii et kasutaja saaks neid ise lisada ja muuta.

2.4. Customer tabelis on väli reg_code, kuhu võib salvestada nii registrikoodi kui ka isikukoodi. Esiteks tekkis küsimus, mis puhul isikukoodi programmis kasutama hakatakse. Eraisiku puhul arvele reeglina isikukoodi ei kirjutada ning FIE-de puhul kasutatakse nende registrikoodi. Kui aga isikukood on andmebaasis vajalik, siis võib olla mõistlik isikukood ja registrikood andmebaasis eraldi hoida.

2.5. Analüüsist selgub, et programm võimaldab pidada lepingupartnerite üle arvestust - neid lisada ja muuta ning arvele valida. Samas tundub, et teenuste või toodete puhul sellist võimalust ei ole. Ehk oleks otstarbekas lisada ka teenuste/toodete standardnimetuste nimekiri ühe tabelina. Kasutajale võiks jääda samas võimalus ise otsustada, kas ta tahab kasutada loendist võetud nimetust või sisestada/täiendada käsitsi.

2.6. Analüüsist ei leidnud kirjeldust, mis juhtub varem väljastatud arvete infoga, kui arvel märgitud partner andmebaasist kustutatakse. Kas temaga seotud andmebaasi kirjed säilivad esialgsel kujul või poolikult?

2.7. Partneri andmete hulka soovitame lisada e-posti aadressi. Kuigi meiliga saatmine on nice-to-have nimekirjas, oleks kasutajale arve väljasaatmine siiski lihtsam, kui e-posti aadress oleks arve peal näha. Samuti võiks arvel olla koht muude märkuste jaoks.

Kuigi küsimusi sai retsensiooni palju, siis (nagu sissejuhatuses öeldud) oli tegelikult üldmulje siiski väga hea ning mitmed meie tõstatatud küsimused on projekti meeskond enda jaoks tõenäoliselt juba läbi mõelnud ja oma peas lahendanud. Igal juhul soovime teile jaksu ja jääme tulemust ootama!

Retsenseeris meeskond Paabel (Liina Abner, Rutt Lindström, Esta Prangel, Krista Rüütel)

Retsensioon lõpptootele

Rakenduse idee on väga hea. Tegemist on töölauarakendusega, milles on võimalik koostada arveid ning hoiustada oma partnereid ja neile koostatud arveid.

Funktsionaalsus on antud rakenduse jaoks sobiv. Loodud funktsionaalsus töötab. Toome välja mõned tähelepanekud, mis testimisel tekkisid. Välja toodud tähelepanekud ei ole kindlasti vead, need on välja toodud ideede andmiseks ja ei ole kahtlust, et meeskond isearve nende realiseerimisega hätta jääks.

Partnerite sisestamine:

• Partnerite sisestamisel võiks olla kontroll, et sama registrikoodiga partnerit ei ole võimalik teist korda sisestada. Kui on rohkem partnereid, siis võib seda olla keeruline jälgida, et neid topelt ei sisestataks.

Arve sisestamine:

• Kuna arve number on identifitseerimistunnus, siis võiks lisada kontrolli, et teist korda ei saa sama arve numbriga arvet koostada.
• Arve koostamisel võiks olla võimalus valida erinevat käibemaksumäära, sest päriselt on kehtestatud erinevad käibemaksumäärad.
• Andmete turvalisuse huvides võiks kaaluda ka sisselogimise võimaluse tekitamist.
• Kuigi miinusmärgiga on võimalik arvet sisestada, siis kreeditarve esitamisel peaks olema nimetus kreeditarve.
• Väga hea lahendus on see, et kui koostada uus arve ja seda partnerit andmebaasis ei ole, siis salvestatakse ühtlasi ka uus partner.

Arve kuvamine:

• Arve ja makse kuupäev võiks olla kuupäeva vormingus, kellaaja täpsus on üleliigne.

Lisaks võiks saada ettevõtte enda andmeid ka muuta, kui näiteks aadress muutub ja tihti on ettevõtetel mitu pangakontot, aga hetkel on võimalik kasutada ainult ühte. Selleks, et rakendust päriselt kasutada, võiks funktsionaalsuse poole pealt olla võimalik ka filtreerida ja kuvada näiteks kindla partneri kõik arved/tasumata arved vms, sest kui arvete maht kasvab, siis on raske neid hallata. Placeholderite kasutamine on hetkel natuke ebamugav, sest see ei kao ära, kui väljale vajutad ja testmise käigus juhtus mitmel korral nii, et kirjutasid placeholderi sisse oma teksti.

Üks tähelepanek on seoses andmebaasiga ja ressursside efektiivse kasutamisega, iga kord, kui salvestatakse arve, siis salvestatakse tabelisse "contacts" uus rida ehk kontaktandmed, mis ei tundu vajalik tegevus.

Rakenduse kood on üldiselt arusaadav, kommenteeritud, loetavalt vormindatud ja jagatud loogiliselt kihtidesse: BO, service, viewmodels, views. Meis tekitab segadust SaleBO sees loodud klass "INotify", mis on sisult sama kui ViewModels kaustas klass "INotifyVM", mida tundub, et tegelikult ei kasutatagi. Meie arvates peaks INotify olema siiski ViewModeli tasandil, sest on vaatega seotud. Lisaks on SaleBO sees loodud klass "INotify" InvoiceBO baasklassiks, aga baasklassid võiksid olla paremini nähtavad projektis, kui mõne teise klassi sees peidus. InvoiceBO-s olevad getterid paistavad kohati sisaldavat osi, mis kuuluvad pigem äriloogika alla. InvoiceBO sees ridadel 82-106 property sees on tehtud andmbaasist päring, kuid meie arvates peaks jääma andmebaasist päringud service'isse. Positiivse poole pealt tooks välja, et võimalikud andmebaasi exceptionid paistavad ilusti Service'i poolel try/catchidega kontrolli all olevat.

Kokkuvõtteks on suur osa 'must-have' funktsionaalsusest loodud ja tundub, et ka selle aine raames vajalikud oskused omandatud.

Retsenseeris projekti "Rahaplaneerija" meeskond:

• Maila Keerus
• Evelin Jõgi