Mikä on lainsäädännöllinen ongelma liittyen palvelin- ja infrastruktuuriin järjestelmäkehityksessä?

Yrityksissä käytettävät IT-järjestelmät luodaan tietyssä mielessä laatimalla määrittely- ja suunnitteluasiakirjoja ja kirjoittamalla niitä vastaavaa lähdekoodia. Kuitenkin, ei riitä, että otetaan huomioon vain nämä pehmeät näkökohdat, vaan järjestelmä toimii todellisuudessa vasta, kun on olemassa fyysinen tietokone, toisin sanoen infrastruktuuri. Tässä artikkelissa käsitellään infrastruktuurin alueeseen liittyviä oikeudellisia kysymyksiä, jotka ovat merkittäviä IT-järjestelmän kehitysprojekteissa.

Mitä infrastruktuuri tarkoittaa IT-järjestelmissä

Järjestelmänkehittäjät tunnetaan nimellä järjestelmäinsinöörit (SE). Kehitysprojektit alkavat yleensä ylävirran prosesseista, kuten määrittely- ja suunnitteluasiakirjojen luomisesta, ja jatkuvat ohjelmiston toteutuksella ja sen testauksella. Yleisesti ottaen voidaan sanoa, että laajemmin määriteltynä järjestelmäinsinööri (SE) on teknikko, joka hoitaa kaikki nämä tarvittavat tehtävät. Kuitenkin yrityksissä ja työpaikoilla tehtävänkuvat ja vastuualueet voivat vaihdella, ja niitä voidaan eritellä tarkemmin eri nimikkeillä. Infrastruktuuri-insinööri on termi, joka viittaa teknikkoon, jonka tehtävänä on erityisesti fyysisen tietokoneen toimintaympäristön ylläpito IT-järjestelmän kehitys- ja käyttöprosessissa. Yrityksissä ja työpaikoilla käytettävät IT-järjestelmät ovat eräänlaisia abstrakteja rakennelmia, jotka koostuvat lähdekoodin yhdistelmistä. Jotta nämä järjestelmät voivat kuitenkin toimia odotetulla tavalla, on välttämätöntä rakentaa infrastruktuuri, joka sisältää palvelimet ja verkon. Järjestelmänkehitys etenee ohjelmiston lähdekoodin toteutuksen ja sen toimintaympäristöä tukevan infrastruktuurin ylläpidon rinnakkain. Tämä näkökulma on tärkeä myös odottamattomien ongelmien ehkäisemiseksi.

Mitä konkreettisia tilanteita projektin epäonnistumiseen johtavat infrastruktuuriongelmat?

Järjestelmäkehitysprojekteissa voi todellisuudessa tapahtua, että keskitytään liikaa abstraktiin ohjelmointiin ja lähdekoodin suunnitteluun, ja infrastruktuurin kehittäminen jää huomiotta. Kuitenkin, jos nämä kaksi eivät kulje käsi kädessä, se voi johtaa projektin epäonnistumiseen.

Miten palvelimen koon virheellinen määrittäminen voi johtaa riitoihin?

Esimerkiksi, kun ohjelman toteutus ja testaus on saatu päätökseen, saattaa paljastua, että palvelimen suorituskyky ei riitä ja järjestelmä ei kestä käytännön käyttöä. Tämä ongelma voidaan ennakoida arvioimalla, kuinka paljon kuormitusta järjestelmä voi kestää käyttövaiheessa, ja kehittämällä infrastruktuuri järjestelmän kokoa vastaavaksi. Tätä kutsutaan “sizingiksi”. On ollut tapauksia, joissa palvelimen koon virheellinen määrittäminen on johtanut ongelmiin. (Vaikka tämä ongelma on ratkaistu sovinnolla, voit tutustua tähän tunnettuun tapaukseen.) Lisätietoja sovinnon kautta ratkaistavista riidoista löydät seuraavasta artikkelista.

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

Riidan ratkaiseminen sovinnolla tarkoittaa yksinkertaisesti sitä, että molemmat osapuolet ovat päässeet sopimukseen keskustelujen kautta. Toisin kuin tuomioistuimen antamassa tuomiossa, sovintoratkaisu ei ole ennakkotapaus, vaan se on yksilöllinen ratkaisu.

Tapauksen ydin on toimittajan vastuun laajuus epäselvien vaatimusten suhteen

Kuitenkin, näiden riitojen ydin on usein se, kuinka pitkälle toimittajan tulisi kantaa vastuu asioista, joita ei ole määritelty vaatimuksissa. Tämän huomioon ottaen, voit saada paljon vinkkejä seuraavasta artikkelista.

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

Yllä olevassa artikkelissa selitetään, kuinka pitkälle toimittajan tulisi ottaa vastuuta asioista, joita ei ole määritelty vaatimuksissa. Tässä yhteydessä selitetään, että “näytön” puolella (eli “frontend” -alueella), joka voidaan helposti visualisoida vaatimusmäärittelyissä ja perussuunnitteludokumenteissa, ja “logiikan” puolella (eli “backend” tai “tietokanta” -alueella), kuten datan siirrossa, on suuria eroja. Toisin sanoen, tilaajat/käyttäjät, jotka eivät yleensä ole erikoistuneet järjestelmäkehitysprojekteihin, ovat todennäköisemmin vastuussa “näytön” puolen ongelmista, koska ne ovat helpommin havaittavissa. Toisaalta, “logiikan” puolen ongelmat ovat todennäköisemmin toimittajan vastuulla. Ottaen huomioon nämä seikat, palvelimen koon määrittämiseen liittyvät ongelmat ovat todennäköisesti toimittajan vastuulla, koska ne ovat vaikeasti havaittavissa ilman teknistä asiantuntemusta. Siksi, jos tästä asiasta joudutaan käymään oikeutta, toimittajan puolella on todennäköisesti haittaa, ellei ole aktiivisia syitä vapauttaa toimittaja vastuusta.

Toimenpiteet virheellisen palvelinkoon määrittämisen aiheuttamien ongelmien estämiseksi

Jotta voimme estää aiemmin mainitut ongelmat, on tärkeää, että ohjelmiston toteutus, lähdekoodin kirjoittaminen ja infrastruktuurin ympäristön valmistelu kulkevat käsi kädessä. Konkreettisia toimenpiteitä voivat olla esimerkiksi seuraavat:

Palvelinkoon määrittämisen vastuun selkeyttäminen sopimuksessa

Ei ainoastaan näissä tapauksissa, vaan useimmissa järjestelmänkehitysprojekteihin liittyvissä kiistoissa, ongelmat johtuvat usein siitä, että järjestelmänkehityksen asiantuntijan eli toimittajan ja yrityksen sisäisiä olosuhteita tuntevan käyttäjän roolien jakaminen on epäselvää. Vaikka molempien osapuolten tiivis yhteistyö on välttämätöntä projektin sujuvalle etenemiselle, on tärkeää, että roolien jakaminen ja vastuualueet määritellään mahdollisimman selkeästi sopimuksessa etukäteen.

Kehitysvaatimusten konkretisointi ja muutoshallinnan täydellinen toteuttaminen

Lisäksi, jos alun perin toteutettavien toiminnallisten vaatimusten määrittely on epäselvää, kiistojen riski kasvaa. Tämä liittyy sekä alkuperäisten vaatimusten määrittelyvaiheen eritelmien selkeyttämiseen että projektin aikana tapahtuvan muutoshallinnan molempiin näkökulmiin. Kuinka projektin aikana tapahtuviin eritelmien muutoksiin tulisi reagoida, selitetään yksityiskohtaisesti seuraavassa artikkelissa.

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

Projektin luonteeseen sopivan kehitysmallin valinta

Lisäksi, ja tämä liittyy syvästi kahteen edellä mainittuun toimenpiteeseen, on tärkeää valita järjestelmänkehitysprojektin luonteen ja laajuuden mukaan sopiva kehitysmalli. Yleisesti ottaen, jos kyseessä on tietyn kokoluokan järjestelmän kehitys, jossa palvelinkoon määrittäminen on tärkeää, vesiputousmallin käyttöönoton edut, joka soveltuu eritelmien ja vastuualueiden selkeyttämiseen, kasvavat. Projektin luonteen huomioon ottavan sopivan kehitysmallin valinnasta kerrotaan yksityiskohtaisemmin seuraavassa artikkelissa.

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

Yhteenveto

Järjestelmäkehitysprojektien sujuvan etenemisen kannalta, infrastruktuurin ympärillä tapahtuvat ongelmat, jotka alkavat ympäristön järjestelyistä, ovat helposti sivuutettavia kohtia. Teknologian asiantuntijoiden ulkopuolella infrastruktuuriongelmien huomioiminen ei ole vähäinen taakka. Kuitenkin, näiden ongelmien ennaltaehkäisy liittyy suoraan perusasioihin, kuten “vaatimusten selkeyttäminen / muutosten hallinnan tiukentaminen”, “roolien / vastuualueiden selkeyttäminen” ja “projektin kokoon ja budjettiin sopivan kehitysmallin valinta”. Yritysjuridiikan parissa työskentelevien tulisi ensisijaisesti ymmärtää, että infrastruktuuriongelmiin voidaan soveltaa ennaltaehkäisevää oikeudellista perustaa. Lisäksi, jos olet IT-alan asiantuntija, on tärkeää ymmärtää, että infrastruktuuriongelmat voivat aiheuttaa vakavia riskejä projektille, ja hallita työskentelyä sujuvasti.