Wat zijn de juridische problemen rond server- en infrastructuur van systeemontwikkeling?

IT-systemen die in bedrijven worden gebruikt, worden in zekere zin gecreëerd door het opstellen van specificaties en ontwerpen, en door het schrijven van broncode die overeenkomt met deze inhoud. Maar een systeem functioneert pas echt als er naast deze zachte aspecten ook fysieke computers, oftewel infrastructuur, aanwezig zijn. In dit artikel zullen we juridische kwesties bespreken die nauw verband houden met het gebied van infrastructuur in systeemontwikkelingsprojecten.

Wat is infrastructuur in IT-systemen?

Technici die systeemontwikkeling uitvoeren, worden systeemingenieurs (SE) genoemd. En ontwikkelingsprojecten beginnen met de bovenstroomse processen, zoals het maken van specificaties en ontwerpen, en gaan dan verder met de implementatie van het programma en het uitvoeren van tests. Dit is de algemene stroom. In de ruimste zin van het woord kan een systeemingenieur (SE) worden omschreven als een technicus die alle taken uitvoert die hiervoor nodig zijn. Echter, afhankelijk van het bedrijf of de werkplek, kunnen de taken en gebieden die men verantwoordelijk is verder worden onderscheiden door meer specifieke namen. De term infrastructuur ingenieur verwijst naar technici die verantwoordelijk zijn voor het inrichten van de fysieke computeromgeving, een taak die met name relevant is in het kader van IT-systeemontwikkeling en -operaties. IT-systemen die worden gebruikt in bedrijven en werkplekken zijn in zekere zin abstracte constructies die bestaan uit combinaties van broncode. Echter, om ervoor te zorgen dat deze systemen hun beoogde rol naar behoren kunnen vervullen, is het essentieel om de infrastructuur, inclusief servers en netwerken, op te zetten. De praktijk van systeemontwikkeling gaat vooruit op twee wielen: de implementatie van programma’s en broncode, en de inrichting van de infrastructuur die deze operationele omgeving ondersteunt. Dit perspectief wordt ook als belangrijk beschouwd om onvoorziene problemen te voorkomen.

Specifieke situaties waarin infrastructuurproblemen een project in vlammen doen opgaan

In systeemontwikkelingsprojecten kan het gebeuren dat men zich te veel richt op abstracte programma’s en broncodeontwerp, en het perspectief van infrastructuuronderhoud verliest. Echter, als beide niet synchroon lopen, kan dit soms leiden tot een risico van een project dat in vlammen opgaat.

Hoe een fout in server sizing kan leiden tot een conflict

Bijvoorbeeld, na de implementatie en het testen van het programma, kan het blijken dat de servercapaciteit uiteindelijk niet voldoende is en het systeem niet praktisch bruikbaar is. Het voorspellen van de belasting die het systeem in de operationele fase kan hebben en het onderhoud van de infrastructuur aanpassen aan de schaal van het systeem wordt ‘sizing’ genoemd. Er zijn gevallen waarin een fout in server sizing heeft geleid tot problemen. (Hoewel deze uiteindelijk zijn opgelost door een schikking, kan dit geval als een bekend voorbeeld worden genomen.) Voor meer informatie over het oplossen van conflicten tussen beide partijen door middel van een ‘schikking’, zie het volgende artikel.

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

Het feit dat het conflict is opgelost door een schikking betekent eenvoudigweg dat het conflict is opgelost door ‘onderhandelingen’ tussen beide partijen. Daarom, in tegenstelling tot wanneer een vonnis wordt uitgesproken door een rechtbank, wordt de inhoud van de schikking niet opgeslagen als jurisprudentie en is het meestal zeer specifiek.

De essentie van het geval is de reikwijdte van de verplichting van de leverancier om te reageren op onduidelijke specificaties

Echter, de essentie van dergelijke conflicten kan worden gezien als ‘hoe ver de leverancier verantwoordelijk moet zijn voor zaken die niet expliciet zijn gespecificeerd’. Met dit in gedachten, kunt u veel tips krijgen uit de inhoud van het volgende artikel.

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

In het bovenstaande artikel wordt uitgelegd hoe ver de leverancier discretionaire bevoegdheid kan uitoefenen en verantwoordelijk is voor de implementatie van zaken die niet in de specificaties zijn vermeld. Hier wordt uitgelegd dat er een groot verschil is tussen zaken die gemakkelijk kunnen worden gevisualiseerd in functionele specificaties en basisontwerpen, zoals ‘schermzijde’ zaken (het zogenaamde ‘front-end’ gebied), en ‘logica-zijde’ zaken zoals datamigratie (het zogenaamde ‘back-end’, ‘database’ gebied). Met andere woorden, het is waarschijnlijk dat de opdrachtgever/gebruiker gemakkelijker verantwoordelijk kan worden gehouden voor problemen met de specificaties die gemakkelijk kunnen worden gecontroleerd in het ‘schermzijde’ gebied. Aan de andere kant, problemen aan de ‘logica-zijde’ worden waarschijnlijk toegeschreven aan de leverancier. Met dit in gedachten, aangezien server sizing problemen moeilijk te herkennen zijn tenzij men een technisch expert is, is het waarschijnlijk dat ze worden toegeschreven aan de leverancier. Daarom, tenzij er actieve omstandigheden zijn om de verantwoordelijkheid van de leverancier te ontslaan, als dit punt serieus wordt betwist in de rechtbank, is het waarschijnlijk dat de leverancier nadelig zal worden beoordeeld.

Maatregelen om problemen door server sizing fouten te voorkomen

Om dergelijke problemen te voorkomen, is het belangrijk om de implementatie van het programma, de beschrijving van de broncode en de voorbereiding van de infrastructuur op elkaar af te stemmen. De volgende maatregelen kunnen concreet worden overwogen:

De verantwoordelijkheid voor server sizing duidelijk vastleggen in het contract

Niet alleen in deze gevallen, maar veel geschillen met betrekking tot systeemontwikkelingsprojecten ontstaan vaak doordat de rolverdeling tussen de systeemontwikkelingsexpert, de leverancier, en de gebruiker die bekend is met de interne omstandigheden, onduidelijk is. Hoewel het vanzelfsprekend is dat nauwe samenwerking tussen beide partijen noodzakelijk is voor een soepele voortgang van het project, is het wenselijk om de rolverdeling en verantwoordelijkheidsgebieden zo duidelijk mogelijk vast te leggen in een contract of iets dergelijks.

Concretisering van ontwikkelingseisen, volledig beheer van wijzigingen

Daarnaast, als de functionele eisen die in de eerste plaats moeten worden gerealiseerd vaag zijn, neemt het risico op conflicten toe. Dit heeft zowel te maken met de verduidelijking van de specificaties in de initiële eisenfase als met het beheer van wijzigingen tijdens het project. Hoe om te gaan met specificatiewijzigingen tijdens het project wordt in detail uitgelegd in het volgende artikel.

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

Kies een ontwikkelingsmodel dat past bij de aard van het project

Daarnaast, en dit is nauw verbonden met de bovenstaande twee maatregelen, is het belangrijk om een geschikt ontwikkelingsmodel te kiezen voor systeemontwikkelingsprojecten, afhankelijk van hun aard en omvang. Over het algemeen, als het gaat om de ontwikkeling van systemen van een bepaalde omvang waarbij server sizing belangrijk kan zijn, wordt het voordelig om het watervalmodel te gebruiken, dat geschikt is voor het verduidelijken van specificaties en verantwoordelijkheidsgebieden. Over het kiezen van een geschikt ontwikkelingsmodel op basis van de aard van het project wordt in detail uitgelegd in het volgende artikel.

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

Samenvatting

Problemen die ontstaan bij het opzetten van de infrastructuur voor systeemontwikkelingsprojecten kunnen gemakkelijk over het hoofd worden gezien. Het is begrijpelijk dat het voor niet-technische experts een aanzienlijke last kan zijn om aandacht te besteden aan infrastructuurproblemen. Echter, preventieve maatregelen voor dergelijke problemen kunnen worden gezien als een uitbreiding van basisstrategieën zoals ‘het verduidelijken van specificaties / grondig verandermanagement’, ‘het verduidelijken van rollen / verantwoordelijkheidsgebieden’, en ‘het kiezen van een ontwikkelingsmodel dat past bij de schaal en het budget van het project’. Het is belangrijk voor mensen die betrokken zijn bij bedrijfsjuridische zaken om te begrijpen dat de basisprincipes van preventief juridisch werk ook van toepassing kunnen zijn op infrastructuurproblemen. Bovendien, voor IT-technici, is het belangrijk om te begrijpen dat infrastructuurproblemen een ernstig risico kunnen vormen voor het project en dat het belangrijk is om de werkzaamheden soepel te coördineren.