Kui palju peaks seaduslikult rakendama süsteemiarenduse spetsifikatsioonides mitte esinevaid funktsioone?

Ettevõtetes kasutatavad IT-süsteemid on põhimõtteliselt loodud vastavalt eelnevalt määratletud spetsifikatsioonidele. Kuid teisest küljest, arvestades, et süsteemiarenduse spetsialistina on tarnijale usaldatud arendustegevus, ei pruugi kasutajate ootused olla madalad, kui lihtsalt mehaaniliselt rakendatakse ainult seda, mis on spetsifikatsioonis kirjas. Selles artiklis selgitame, kui palju peaksime võtma kohustust rakendada programme, mis “ei ole spetsifikatsioonis kirjas, kuid on vajalikud arenduse eesmärgi valguses”.

Seadusega seotud probleemid, mis kaasnevad spetsifikatsioonides mitte esinevate asjade rakendamisega

Vendoreilt nõutakse otsustusvabadust

Süsteemiarendusega seotud projektide lepingute ja nendega kaasnevate erinevate õiguslike probleemide suur eripära on see, et tööd vastu võttev vendoril on suur otsustusvabadus.

Seotud artikkel: Mis on projektijuhtimise kohustused süsteemiarenduses[ja]

Kuid siin mainitud “otsustusvabadus” ei kehti tingimata kõigi süsteemiarenduse etappide kohta. Pärast iga etapi läbivaatamist ja detailsete ülesannete väljaselgitamist võib töö muutuda lihtsaks. Kuid üldiselt, mida rohkem on tegemist ülesvoolu tööga, seda raskem on tööd teha ilma suure otsustusvabaduseta. See on ka põhjus, miks ülesvoolu tööd sobivad sageli paremini pooldelegeerimise lepingumudeliga.

Seotud artikkel: Erinevused süsteemiarenduse alltöövõtu lepingute ja pooldelegeerimise lepingute vahel[ja]

Otsustusvabadus tuleb rakendada ka range arendusprotsessi raames

Kuid isegi kui süsteemiarendaja vendoril on suur otsustusvabadus, ei tohiks ta “järk-järgult” klientide soove vastu võtta, kuna see võib hilisemates etappides põhjustada suuri kahjustusi. Üks IT-süsteem koosneb paljudest väikestest osadest, seega võib isegi väike muudatus välimuses nõuda arendajalt suurt töömahtu. Lisaks on artikleid, mis selgitavad süsteemiarenduse spetsifikatsioonide muutmise küsimust õiguslikust vaatepunktist, sealhulgas kuidas muudatuste haldamist hallata. Järgnev artikkel selgitab muudatuste haldamist, kuid arutleb ka selle üle, kui suurt mõju võib spetsifikatsioonide muutmine tuua kaasa inseneride tööle.

Seotud artikkel: Kuidas hallata muudatusi süsteemiarenduses õiguslikust vaatepunktist[ja]

Mida peaks spetsialist tegema, ilma et ta oleks kinni spetsifikatsioonides?

Süsteemiarenduse projekti sujuvaks läbiviimiseks on oluline eelnevalt määratleda arenduse nõuded ja neid järgides plaanipäraselt edasi liikuda. Teisest küljest, kui te lihtsalt teete seda, mida teile öeldakse, järgides eelnevalt määratletud nõudeid, võib olla olukordi, kus te ei suuda süsteemiarenduse spetsialistina oma rolli täielikult täita. Sellise dilemmaga silmitsi seistes tekib küsimus: “Mida peaks rakendama, isegi kui see pole spetsifikatsioonides näidatud?”

Seaduslikud kohustused määratakse vastavalt spetsifikatsioonide ja lepingute “eesmärgile”

Implementeerimiseks vajaliku sisu määrab, isegi kui seda ei ole lepingutes või spetsifikatsioonides kirjas, ikkagi nende lepingute ja spetsifikatsioonide “eesmärk”, st “millise tähenduse või kavatsusega on selline kokkulepe sõlmitud”. Vaatame allpool mõnda kohtupraktikat.

Kohtupraktika, kus rakendamiskohustus lükati ümber, kuna seda ei olnud märgitud

Allpool tsiteeritud kohtupraktikas arenes vaidlus välja olukorrast, kus süsteemi, mille oli välja töötanud müüja, oli jõudnud ajutise töökorralduseni, kuid lepingu lõpetamist nõuti, kuna vajalikud funktsioonid puudusid. Kasutaja väitis, et puudub “andmete automaatne uuendamise funktsioon”, mis oli väidetavalt süsteemi peamine müügiargument, kuid kohus ei tunnustanud selle rakendamise kohustust.

Nagu eespool märgitud, ei ole lepingus ega põhi- ja detailprojekteerimisdokumentides märget, et funktsioon ③ oleks süsteemi arendamise eesmärk.

Hageja väidab, et funktsioon ③ oli kostja peamine müügiargument hageja suhtes ja rõhutab selle funktsiooni vajalikkust, kuid kui see väide oleks tõene, oleks see olnud märgitud lepingus ja on raske uskuda, et selle funktsiooni arendamiseks oli kokku lepitud, kui seda ei olnud märgitud.

Tokyo District Court, February 18, 2009 (Heisei 21)

Kuigi see otsus võib tõepoolest tunduda lihtne, kui võtta ainult järeldus, et “kui seda ei ole projekteerimisdokumentides märgitud, siis ei pea seda tegema”, on täpsem öelda, et otsus tehti mitte ainult projekteerimisdokumentide olemasolu või puudumise põhjal, vaid arvestades nende dokumentide ja lepingu “eesmärki”. Teisisõnu, “kui mõelda, miks seda ei märgitud projekteerimisdokumentidesse ega lepingusse, on mõistlik arvata, et ka vastav kokkulepe puudus”.

Kohtupraktika, kus rakendamise kohustus on kinnitatud isegi ilma kirjelduseta

Teiselt poolt on kohtupraktikat, mis on tunnustanud kohustust rakendada isegi siis, kui lepingus või spetsifikatsioonides seda ei ole kirjeldatud. Allpool tsiteeritud kohtupraktika käsitleb süsteemi arendamist ravimite tarvitamise ajaloo haldamiseks, kus andmete üleviimine olemasolevast süsteemist uude süsteemi ei õnnestunud, mistõttu kasutajad ei saanud uut süsteemi kasutada ja tühistasid lepingu. Kuid müüja väitis, et andmete üleviimine ei kuulu nende tööülesannete hulka, mis viis vaidluseni.

Uue süsteemi arendamisega kaasneb sageli olemasoleva süsteemi kaotamine ja andmete üleviimine. Nende tööde tähtsusest ja sellega kaasnevatest õiguslikest küsimustest räägime üksikasjalikumalt ka allpool toodud artiklis.

Seotud artikkel: Õiguslikud probleemid, mis kaasnevad süsteemiarenduse käigus vana süsteemi asendamisega[ja]

Olemasolevas süsteemis oli juba salvestatud üle 50 000 patsiendi andmed ja hageja kasutas neid andmeid bürootöö efektiivsuse suurendamiseks. Kui patsiendi andmeid ei saa olemasolevast süsteemist uude süsteemi üle viia, on selge, et see toob kaasa probleeme apteegis retseptide täitmisel ja hageja esindaja oli seda kindlasti teadlik. Ja enne lepingu sõlmimist küsis hageja esindaja kostja esindajalt andmete üleviimise võimaluse kohta, mida kostja esindaja tunnistas (jäetakse välja), hageja esindaja oli teadlik, et on suur tõenäosus, et ta peab käsitsi sisestama üle 50 000 patsiendi andmed, on raske uskuda, et ta otsustas siiski uue süsteemi kasutusele võtta. Lisaks, nagu eespool (1)I-s märgitud, ei suutnud kostja viia olemasoleva süsteemi ravimite ajaloo andmeid uude süsteemi, mistõttu ta printis need andmed paberile ja skaneeris need PDF-faili, kuigi lepingus ei eeldatud andmete üleviimist, on raske uskuda, et kostja pakkus sellist aeganõudvat teenust.

Tokyo District Court, November 18, 2010 (Heisei 22)

Ka siin on oluline lepingu eesmärk ja lepingus kirjeldatud punktide “mõte”. Kui mõlemad pooled sõlmisid lepingu teadmisega, et andmete üleviimine ei kuulu tööülesannete hulka, siis kohtu märkus viitab sellele, et mõlemad pooled sõlmisid lepingu ebaloomuliku kavatsusega. See tähendab, et kasutaja oleks pidanud nõustuma tohutu hulga käsitsitööga ja müüja oleks pidanud teadma, et see toob kaasa tõrkeid kasutaja töös, mis on äärmiselt ebaloogiline.

Mida saame mõista mõlemast otsusest

Andmeülekande osas, isegi kui lepingus või spetsifikatsioonides pole seda mainitud, on rakendamise kohustuse heakskiitmise taustal osaliselt seotud asjaoluga, et tegemist oli “andmetega”, mis ei ilmne ekraani välimuses. Eelnev “kohustuslike funktsioonide puudumine” on midagi, mis ilmneb otse süsteemi ekraanil või välimuses. Seetõttu pole isegi süsteemiarenduse algajatel eriti raske leida spetsifikatsioonide puudujääke. Teisest küljest on andmeülekande probleemil omadus, et süsteemiarenduse algajatel on raske mõista selle protsessi olulisust, töö keerukust ja tööaega. Seetõttu võib arvata, et oli ka asjaolusid, mis muutsid selle lihtsaks käsitleda kui küsimust, mida tarnija peaks sujuvalt juhtima oma erialase oskusega.

Nii mõeldes võib öelda, et spetsifikatsioonide või lepingute puudujäägid on tihedalt seotud kasutaja “koostöökohustusega”. Teisisõnu, kas kasutaja on tõesti “koostöökohustuse” täitnud lepingu sõlmimiseks ja spetsifikatsioonide koostamiseks? Süsteemiarendusprojektides on kasutaja täidetavate õiguslike kohustuste üldise selgituse kohta üksikasjalikumalt käsitletud järgmises artiklis.

Seotud artikkel: Mis on süsteemiarenduse tellija, kasutaja poolt kantav koostöökohustus[ja]

Kui vaadata ka ülaltoodud artiklit, siis kasutaja koostöö, nagu ekraani ja kohustuslike funktsioonide väljaselgitamine, ja andmeülekande kaalumise puudumine on suuresti erinevad, kas pole nii?

Kuidas peaksime mõtlema tasule, mis on seotud arendustööga, mida pole spetsifikatsioonides?

Samuti võib see artikkel tekitada huvi seoses küsimusega, kas seaduslikult on lubatud nõuda suuremat tasu, kui on loodud midagi, mida pole spetsifikatsioonides. Tasu suurendamise võimalikkuse ja selle arvutamise meetodi kohta leiate üksikasjalikku teavet järgmisest artiklist.

Seotud artikkel: Kas süsteemiarenduse hinnanguline summa võib pärast suureneda?[ja]

Eelnevas artiklis selgitatakse, et oluline on see, kas oli olemas töö, mis ületas tasu ja vastutasu suhte. Teisisõnu, seoses selle artikliga, kui tarnija on nõus arendama midagi, mida algsetes spetsifikatsioonides ei olnud (selle artikli puhul, eitava näite puhul), siis on võimalik nõuda lisatasu.

Kokkuvõte

Süsteemiarenduses määrab tarnija rolli teatud määral lepingu ja spetsifikatsioonidokumentide sisu. Kuid arvestades, et neid usaldatakse kui eksperte, ei ole nende tegelik roll ainult formaalselt määratletud. Siiski, selle sisu mõistmiseks peaksime mõistma, et seadus mängib suurt rolli.