Õigusprobleemid, mis kaasnevad IT-süsteemi andmebaasiga

IT-süsteemidega seotud õiguslike küsimuste mõistmisel on vaja süsteemset õigusalast teadmist, kuid samal ajal on oluline ka IT-süsteemi komponentide tundmine. Selles artiklis selgitame, millistest osadest IT-süsteem koosneb ja kuidas need osad omavahel seotud on ning kuidas nad funktsioneerivad. Samuti käsitleme õigusprobleeme, mis on eriti seotud andmebaasidega, mida kasutajatele ei pruugi silma paista.

IT-süsteem koosneb “ekraanist” ja “loogikast”

Mis on IT-süsteemi “ekraan”

Kui soovite mõista IT-süsteemi struktuuri, on kõige silmatorkavam ekraani välimus. Tõepoolest, tavalises süsteemiarenduse protsessis järgneb funktsioonide väljaselgitamisele ja muule “nõuete määratlemisele” tavaliselt “ekraani kujundus” ja “ekraani liikumise” korraldamine. Selline ekraani välimus on süsteemiarenduse tellijale ehk kasutajale loomulikult silmatorkav valdkond ja ka valdkond, kus kasutaja ja tarnija vaheline suhtlus on kõige aktiivsem. Allpool olevas artiklis selgitatakse kasutaja “koostöökohustust” kogu süsteemiarenduse protsessis projekti saavutamiseks tarnijaga.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Selles artiklis selgitatakse peamiselt, et kasutajal on süsteemiarenduse suhtes koostöökohustus, sealhulgas põhikujunduse (st ekraani) ja muude etappide osas, kus on vaja tarnijaga koostööd teha.

IT-süsteemi “ekraan” kirjeldatakse tavaliselt arvutikeelte, nagu HTML ja CSS, reeglite järgi. IT-süsteemi “ekraani” teemal on erinevaid nimetusi, nagu “frontend”, “UI (kasutajaliides)”, kuid peamised arutelupunktid on “kasutajasõbralikkus”, “loetavus” jne.

Mis on IT-süsteemi “loogika”

Kuid kui IT-süsteem on “ekraanipõhine”, siis see on lihtsalt “ekraan”, millel pole mingit “liikumist” ega “muutust”. Kasutaja sisendi vastuvõtmine ja väljundi kuvamine “ekraanil” nõuab “arvutusprotsessi”.

Sellised kasutaja silmade eest varjatud, justkui “süsteemi tagakülje” komponendid teostavad keerulisi arvutusi ja kontrolli. Andmete otsimine ekraanilt, andmete ümberkirjutamine, lisamine, kustutamine jne on võimalikud ainult eelnevalt loodud andmebaasi olemasolu korral. Andmebaasi teabe erinevad töötlused tehakse tavaliselt arvutikeeles, mida nimetatakse SQL-iks.

Nuppude ja muude ekraanil paiknevate lülitite kasutamine SQL-lause vajaliku käivitamiseni viiva tee loomiseks viib süsteemi kogupildi valmimiseni, mis sisaldab liikumist ja muutusi.

Muuseas, “ekraanilt” nähtamatute erinevate loogikate kokkupanekuga seotud teemasid nimetatakse mõnikord “backendiks”.

Süsteemide arutelus võib riskiks saada, kui keskendutakse ainult “välimusele” ekraanil

Siiamaani toodud selgitused moodustavad (veebis toimiva) IT-süsteemi struktuuri aluse. Selline mõistmine on oluline ka seadusandluse arutelude, projektide vaidluste ennetamise, kriisijuhtimise jms seisukohast. Konkreetselt võib tekkida kommunikatsiooni segadus kasutajate, kes keskenduvad ainult ekraanil nähtavale “välimusele”, ja tarnijate vahel, kes peavad silmas ka nähtamatut “loogikat”, mis kannab endas palju olulisi ülesandeid.

Kasutajate ja tarnijate erinevad mured võivad olla riskiks

Näiteks kasutajad, kes keskenduvad peamiselt IT-süsteemide “ekraanidele”, võivad sageli olla ükskõiksed süsteemi sisemise keerukuse suhtes. Just seetõttu ei pruugi nad mõista, kui palju mõjutab “väike funktsiooni lisamine” või “väike spetsifikatsiooni muutmine” paljusid protsesse. Järgnevas artiklis selgitame õigusprobleeme, mis sageli tekivad seoses olemasoleva süsteemi kaotamisega uue süsteemi arendamise projekti käigus.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Siin selgitame, et uue süsteemi andmete ülekandmisel vanast süsteemist võib sageli tekkida probleeme. Teisisõnu, sisemise arvutus- ja juhtimissüsteemi keerukus, mida ei pruugi välimuse põhjal ette kujutada, võib kasutajatele põhjustada ootamatuid probleeme. Lisaks võib asjaolu, et kasutajad ei mõista “süsteemi looja tarnija tundeid”, põhjustada olukorra, kus muudatused tehakse järk-järgult pärast projekti lõppu.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Arvestades olukordi, kus nõutakse spetsifikatsioonide muutmist või funktsioonide lisamist pärast projekti lõppu, võib tasu suurendamise võimalus muutuda mõnikord tõsiseks probleemiks.

https://monolith.law/corporate/increase-of-estimate[ja]

Kasutajate ükskõiksus “loogika” suhtes tagaküljel võib olla risk

Lisaks võib juhtuda, et just need osad, mida kasutajad ei saa jälgida, muutuvad suureks intsidentiks, kui probleemid ilmnevad. Allpool on mõned sellised näited.

Oht, et tekivad probleemid hoolduse ja turvalisuse osas

Selle alla kuuluvad olukorrad, kus lisafunktsioone ei saa rakendada, süsteem muutub aeglasemaks ja lõpuks ei tööta üldse.

Lisaks on olemas turvarünnakud, mis kasutavad ära ekraanil oleva koodi puudusi, et varastada isiklikku ja konfidentsiaalset teavet, mida ei tohiks ekraanil kuvada. Sellise turvarünnaku tüüp on tuntud kui “SQL-injection”. Sellest võib saada tõsise vaidluse algus. Allpool olevas artiklis käsitleme üksikasjalikult juhtumeid, kus see on juhtunud.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

Kuigi selle artikli peateema on raamistike ja teekide kasutamisega kaasnevad riskid, on esitatud kohtuasjad seotud SQL-injection rünnakutega.

Oht, et haldajate töö ei ole piisavalt reguleeritud

IT-süsteemi kasutajate ükskõiksus taga oleva “loogika” suhtes võib viia selleni, et IT-süsteemi haldajate töö ei ole piisavalt reguleeritud. Allpool olevas artiklis käsitleme seda teemat seoses “andmekao riski ja meetmetega”.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Oht, et isegi kui süsteem töötab pealiskaudselt korrektselt, võib loogika olla vale

Asjaolu, et süsteemist rääkides ei piirdu me ainult “ekraaniga”, tähendab, et isegi kui süsteem töötab pealiskaudselt korrektselt, võib selle taga olev “loogika” olla vale. See võib ilmneda ootamatult, isegi kui see ei ole igapäevaste põhitegevuste käigus ilmnenud, näiteks “kord poolaastas” või “kord aastas” toimuvate erakorraliste tegevuste käigus.

Sellisel juhul käsitletakse seda juriidiliselt mitte kui lepingurikkumist, vaid kui “garantiikohustuse rikkumist”.

https://monolith.law/corporate/defect-warranty-liability[ja]

Kui pärast vastuvõtmist ilmneb viga, on allpool olevas artiklis üksikasjalikult kirjeldatud, kuidas olukorraga toime tulla.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Kokkuvõte

Süsteemiarenduse ja õigusasjade süstemaatiline mõistmine

Süsteemiarendusega seotud õigusprobleemide puhul on oluline mõista, millise komponendi probleem on tekkinud, enne kui jõutakse õiguslike küsimuste tuvastamiseni. Nii õiguslike probleemide kui ka IT-süsteemi probleemide puhul on süsteemiarenduse projektides tekkivate vaidluste korral eriti oluline mitte kaotada silmist tervikpilti ja püüelda erinevate sektorite vahelise koostöö nimel.