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

Retsenseeris projekti "Rahaplaneerija" meeskond:

• Maila Keerus
• Evelin Jõgi