Millised on seaduslikud probleemid, mis on seotud süsteemiarenduse serveri ja infrastruktuuriga?

Ettevõtetes kasutatavad IT-süsteemid luuakse teatud mõttes spetsifikatsioonide ja disainidokumentide koostamise ning nende sisu kajastava lähtekoodi kirjutamise kaudu. Kuid süsteem ei toimi tegelikult mitte ainult selliste pehmete aspektide, vaid ka füüsilise arvuti, st infrastruktuuri olemasolu korral. Käesolevas artiklis käsitleme süsteemiarendusprojektides infrastruktuuriga tihedalt seotud õigusprobleeme.

Infrastruktuur IT-süsteemides

Süsteemiarendajaid nimetatakse süsteemiinsenerideks (SE). Arendusprojektid algavad üldjuhul ülalt-alla protsessidega, nagu spetsifikatsioonide ja disainidokumentide loomine, ning jätkuvad programmi rakendamise ja selle testimisega. Laiemas mõttes võib öelda, et süsteemiinsener (SE) on tehnik, kes tegeleb kõigi nende vajalike ülesannetega, kuid ettevõtted ja töökohad võivad mõnikord eristada peenemaid nimetusi sõltuvalt vastutusalast ja valdkonnast. Infrastruktuuriinsener on termin, mis viitab tehnikule, kes tegeleb eriti füüsilise arvuti töökeskkonna ettevalmistamisega IT-süsteemide arendamise ja haldamise raames. IT-süsteemid, mida kasutatakse ettevõtetes ja töökohtades, on teatud mõttes abstraktsed struktuurid, mis koosnevad lähtekoodi kombinatsioonidest. Kuid selleks, et süsteem saaks täita oma algselt oodatud rolli, on hädavajalik luua infrastruktuur, sealhulgas serverid ja võrgud. Süsteemiarenduse praktiline töö toimub lähtekoodi rakendamise ja selle töökeskkonda toetava infrastruktuuri ettevalmistamise kaudu. Selline vaatenurk on oluline ka ettenägematute probleemide ennetamiseks.

Konkreetsed olukorrad, kus infrastruktuuri probleemid põhjustavad projekti põlemist

Süsteemiarendusprojektides võib juhtuda, et keskendutakse ainult abstraktsele programmeerimisele ja lähtekoodi disainile, jättes tähelepanuta infrastruktuuri. Kuid kui mõlemad ei liigu samas tempos, võib see põhjustada projekti põlemise riski.

Serveri suuruse viga põhjustab konflikti

Näiteks võib juhtuda, et pärast kõigi programmide rakendamist ja testimist selgub, et serveri töötlusvõime ei ole piisav ja süsteem ei ole praktiliseks kasutamiseks sobiv. Selleks, et hinnata, kui suurt koormust süsteem võib kasutusetapis taluda, ja teha infrastruktuuri ettevalmistusi vastavalt süsteemi suurusele, nimetatakse seda “suuruseks”. On juhtumeid, kus serveri suuruse viga on põhjustanud probleeme. (Kuigi see on lahendatud kompromissiga, võib selle juhtumi näiteks tuua.) Lisateavet kompromissi lahenduse kohta leiate järgmisest artiklist.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Kui konflikt on lahendatud kompromissiga, tähendab see lihtsalt, et mõlemad pooled on “läbirääkimiste” tulemusel konflikti lahendanud. Seega, erinevalt kohtuotsusest, ei kogune kompromissi sisu kohtupraktikana, vaid on tavaliselt väga individuaalne.

Juhtumi olemus on tarnija vastutuse ulatus ebaselgete spetsifikatsioonide suhtes

Kuid selliste konfliktide olemus võib olla ka küsimus, kui palju vastutust peaks tarnija võtma asjade eest, mida spetsifikatsioonides selgelt ei ole määratletud. Sellest lähtuvalt saate järgmisest artiklist palju näpunäiteid.

https://monolith.law/corporate/system-development-specs-function[ja]

Ülaltoodud artiklis selgitatakse, kui palju peaks tarnija oma äranägemise järgi rakendama asju, mida spetsifikatsioonides ei ole määratletud. Siin selgitatakse, et “ekraani” küsimused, mida on lihtne visualiseerida nõuete määratluse või põhikujunduse dokumentides (nn “frontend” valdkond), ja “loogika” küsimused, nagu andmete migratsioon (nn “backend”, “andmebaas” valdkond), on väga erinevad. Teisisõnu, mida rohkem on “ekraani” valdkonnas probleeme, mida tellija/kasutaja (kes tavaliselt ei oma süsteemiarendusprojektidele spetsialiseeritud teadmisi) saab hõlpsasti tuvastada, seda tõenäolisem on, et tellija/kasutaja vastutab. Teisest küljest, “loogika” probleemid on tõenäoliselt tarnija vastutusel. Arvestades seda, on serveri suuruse probleemid valdkond, mida on raske mõista, kui te ei ole tehnikaspetsialist, ja seega on tõenäoline, et need on tarnija vastutusel. Seega, kui see küsimus tõuseb kohtus tõsiselt vaidluseks, on tõenäoline, et tarnijale tehakse ebasoodne otsus, kui pole aktiivseid asjaolusid, mis vabastaksid tarnija vastutusest.

Meetmed serveri suuruse määramise viga tõttu tekkivate probleemide vältimiseks

Et vältida eelnevalt mainitud probleeme, on oluline kooskõlastada programmeerimise ja lähtekoodi kirjutamise tööd infrastruktuuri ümbruse keskkonna ettevalmistamisega. Konkreetselt võib kaaluda järgmisi meetmeid:

Serveri suuruse määramise eest vastutuse selge määratlemine lepingus

Enamik süsteemiarendusprojektidega seotud vaidlusi tuleneb asjaolust, et süsteemiarenduse spetsialistide (ehk müüjate) ja ettevõtte sisemiste asjaoludega kursis olevate kasutajate rollijaotus on ebaselge. Mõistagi on mõlema osapoole tihedat koostööd vaja projekti sujuvaks kulgemiseks, kuid sellegipoolest on soovitatav rollijaotus ja vastutusala võimalikult selgelt lepingus määratleda.

Arendusnõuete konkretiseerimine ja muudatuste haldamine

Lisaks, kui funktsionaalsed nõuded on algusest peale ebaselged, suureneb vaidluste tekkimise oht. See hõlmab nii algsete nõuete määratlemise faasi, kus tuleb selgelt määratleda spetsifikatsioonid, kui ka projekti käigus tehtavate muudatuste haldamist. Kuidas peaksime reageerima projekti käigus tehtavatele spetsifikatsioonimuudatustele, selgitame üksikasjalikult järgmises artiklis.

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

Projekti olemusele vastava arendusmudeli valimine

Lisaks, mis on tihedalt seotud eelneva kahe punktiga, on oluline valida süsteemiarendusprojektidele sobiv arendusmudel, võttes arvesse nende olemust ja suurust. Üldiselt, kui tegemist on teatud suurusega süsteemi arendamisega, kus serveri suuruse määramine võib oluliseks muutuda, võib eeldada, et spetsifikatsioonide ja vastutusalade selgitamiseks sobib paremini vesiputoumudel. Projekti olemusele vastava arendusmudeli valimise kohta selgitame üksikasjalikult järgmises artiklis.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Kokkuvõte

Süsteemiarendusprojektide sujuva kulgemise nimel võivad infrastruktuuriga seotud keskkonna ettevalmistamisest tulenevad probleemid kergesti jääda märkamatuks. Infrastruktuuriprobleemidele tähelepanu pööramine võib olla tehnoloogiaekspertidele mõeldes üsna koormav. Siiski võib öelda, et selliste probleemide ennetamise meetmed, nagu “spetsifikatsioonide selgitamine / muudatuste haldamise põhjalikkus”, “rollide / vastutusalade selgitamine” ja “projekti suurusele ja eelarvele vastava arendusmudeli valimine”, on põhiliste meetmete jätkuks. Ettevõtte õigusnõustajad peaksid esmalt mõistma, et infrastruktuuriprobleemide puhul on ennetava õiguse alused täiesti rakendatavad. Lisaks, kui olete IT-spetsialist, on oluline mõista, et infrastruktuuriprobleemid võivad põhjustada projekti tõsiseid probleeme, ja on oluline sujuvalt tööd juhtida.