Juridische kwesties gerelateerd aan databases van IT-systemen

Wanneer u zich verdiept in juridische kwesties rond IT-systemen, is het noodzakelijk om een systematische kennis van de wet te hebben. Tegelijkertijd is het ook belangrijk om te begrijpen wat de componenten van een IT-systeem zijn. In dit artikel zullen we uitleggen hoe een IT-systeem is opgebouwd uit verschillende onderdelen en hoe deze onderdelen met elkaar samenwerken om te functioneren. Daarnaast zullen we ook ingaan op juridische kwesties die nauw verbonden zijn met databases, een aspect dat vaak over het hoofd wordt gezien door gebruikers.

IT-systemen bestaan uit ‘schermen’ en ‘logica’

Wat is het ‘scherm’ van een IT-systeem?

Wanneer we proberen de structuur van een IT-systeem te begrijpen, is het meest opvallende aspect vaak het uiterlijk van het scherm. Inderdaad, in de algemene stappen van systeemontwikkeling, volgt na het definiëren van de vereisten, zoals het identificeren van functies, meestal het ontwerpen van het scherm en het organiseren van de schermovergangen. Dit uiterlijk van het scherm is een gebied dat vanzelfsprekend opvalt voor de gebruiker die de systeemontwikkeling bestelt, en het is ook een gebied waar communicatie tussen de gebruiker en de leverancier het meest waarschijnlijk plaatsvindt. In het volgende artikel wordt de ‘samenwerkingsplicht’ uitgelegd die de gebruiker aan de leverancier heeft in alle stadia van systeemontwikkeling.

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

In dit artikel wordt voornamelijk uitgelegd dat de gebruiker, als onderdeel van zijn samenwerkingsplicht in systeemontwikkeling, moet samenwerken met de leverancier in fasen zoals basisontwerp (oftewel het scherm).

In IT-systemen wordt het ‘scherm’ meestal beschreven volgens de regels van computertalen zoals HTML en CSS. Het gesprek over het ‘scherm’ van een IT-systeem wordt aangeduid met verschillende namen, zoals ‘frontend’, ‘UI (User Interface)’, enz., maar de belangrijkste discussiepunten zijn ‘gebruiksgemak’ en ‘leesbaarheid’ vanuit het perspectief van de gebruiker.

Wat is de ‘logica’ van een IT-systeem?

Echter, als een IT-systeem alleen uit een ‘scherm’ bestaat, dan is het niets meer dan een ‘scherm’ dat geen ‘beweging’ of ‘verandering’ kan hebben. Zelfs als de ontvangst van invoer van de gebruiker en de weergave van uitvoer op het ‘scherm’ worden uitgevoerd, is er een ‘berekeningsproces’ in dit proces.

Deze complexe berekeningen en controles worden uitgevoerd door componenten die niet zichtbaar zijn voor de gebruiker, oftewel de ‘achterkant’ van het systeem. Processen zoals het zoeken naar gegevens vanaf het scherm, het wijzigen van gegevens, het toevoegen of verwijderen ervan, zijn alleen mogelijk dankzij een vooraf gebouwde database op de achtergrond. Verschillende bewerkingen op de informatie in de database worden meestal uitgevoerd in een computertaal die SQL wordt genoemd.

Het creëren van een pad van de trigger, zoals een knop op het scherm, naar de uitvoering van de benodigde SQL-instructie, voltooit het totaalbeeld van een systeem met beweging en verandering.

Overigens, gesprekken over het samenstellen van verschillende logica die niet zichtbaar is vanaf het ‘scherm’ worden soms aangeduid als ‘backend’.

Het risico van het enkel bespreken van het ‘uiterlijk’ van een systeem vanuit het scherm

De uitleg tot nu toe vormt de basis van de structuur van IT-systemen (met de veronderstelling dat ze op het web werken). Het begrijpen van deze zaken heeft grote betekenis op het gebied van juridische discussies, preventie van projectgeschillen, crisisbeheer, enzovoort. Concreet kan er een miscommunicatie ontstaan tussen gebruikers die alleen aandacht besteden aan het ‘uiterlijk’ op het scherm, en leveranciers die veel belangrijke taken hebben aan de ‘logica’-kant die niet zichtbaar is.

Het verschil in aandachtspunten tussen gebruikers en leveranciers kan een risico vormen

Bijvoorbeeld, gebruikers die voornamelijk over het ‘scherm’ praten als het gaat om IT-systemen, hebben de neiging om onverschillig te zijn over de complexiteit van de interne structuur. Precies om deze reden kunnen ze vaak niet inschatten hoeveel invloed wat op het eerste gezicht lijkt op ‘een kleine toevoeging van functies’ of ‘een kleine wijziging in specificaties’ kan hebben op veel processen. Bijvoorbeeld, in het volgende artikel worden de juridische problemen die vaak voorkomen bij het afschaffen van bestaande systemen die momenteel in gebruik zijn, uitgelegd in het kader van een project voor de ontwikkeling van nieuwe systemen.

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

Hier wordt uitgelegd dat er vaak problemen ontstaan bij de overdracht van gegevens naar het nieuwe systeem als gevolg van de afschaffing van het oude systeem. Met andere woorden, het feit dat de interne berekenings- en besturingsmechanismen vaak veel complexer zijn dan je op het eerste gezicht zou denken, kan een onverwachte bron van problemen zijn voor de gebruikerskant. Bovendien, omdat ze de ‘gevoelens van de leveranciers die het systeem maken’ niet begrijpen, kunnen er situaties ontstaan waarin er na verloop van tijd kleine veranderingen worden aangebracht.

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

In gevallen waarin na verloop van tijd wijzigingen in specificaties of toevoegingen van functies worden opgelegd, kan de mogelijkheid van een latere verhoging van de beloning soms een ernstig probleem worden.

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

Het risico van onverschilligheid van gebruikers ten opzichte van de ‘logica’ aan de achterkant

Daarnaast kan het deel dat niet zichtbaar is voor de gebruiker, in geval van problemen, soms uitgroeien tot een groot incident. Hieronder volgen enkele voorbeelden.

Het risico van problemen op het gebied van onderhoud en beveiliging

Dit omvat situaties waarin het onmogelijk is om extra functies te implementeren, of waarin de werking geleidelijk trager wordt tijdens het gebruik, tot het punt waarop het niet meer werkt.

Er is ook een methode genaamd ‘SQL-injectie’, die wordt gebruikt als een beveiligingsaanval om persoonlijke en vertrouwelijke informatie te extraheren die niet op het scherm mag worden weergegeven, vanwege tekortkomingen in de code die aan de kant van het scherm is geïmplementeerd. We behandelen gedetailleerd gevallen waarin dit de aanleiding was voor ernstige geschillen in het volgende artikel.

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

Het hoofdthema van dit artikel is het risico dat gepaard gaat met het gebruik van frameworks en bibliotheken, maar de rechtszaken die we presenteren betreffen gevallen waarin aanvallen werden uitgevoerd op kwetsbaarheden met behulp van SQL-injectie.

Het risico dat governance niet van toepassing is op het werk van de operationele manager

Het feit dat IT-systeemgebruikers onverschillig zijn voor de ‘logica’ aan de achterkant, leidt tot het probleem dat het moeilijk wordt om governance toe te passen op het werk van de IT-systeem operationele manager. In het volgende artikel behandelen we het belang van het werken met databases, met als thema ‘verlies van gegevens door nalatigheid van de operationele manager’.

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

Het risico dat de logica verkeerd is, zelfs als het systeem correct lijkt te werken

Het feit dat het gesprek over het systeem niet beperkt blijft tot het ‘scherm’, betekent dat zelfs als een systeem op het oppervlak correct lijkt te werken, de daadwerkelijke ‘logica’ verkeerd kan zijn. Dit kan onverwacht aan het licht komen tijdens onregelmatige taken, zoals ‘een keer per half jaar’ of ‘een keer per jaar’, zelfs als het niet duidelijk is in de dagelijkse basiswerkzaamheden.

In dergelijke gevallen wordt het juridisch gezien een kwestie van defectgarantieaansprakelijkheid (niet van contractbreuk), als een ‘geval waarin een tekortkoming achteraf aan het licht kwam in een systeem dat eenmaal was geleverd’.

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

Als er na de acceptatie een defect aan het licht komt, leggen we de stappen in detail uit in het volgende artikel.

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

Samenvatting

Een systematische begrip van systeemontwikkeling en juridische zaken

Het is belangrijk om te begrijpen welk onderdeel van het IT-systeem het probleem veroorzaakt bij juridische kwesties rond systeemontwikkeling, zelfs voordat specifieke juridische punten worden geïdentificeerd. Of het nu een juridisch probleem is of een probleem met het IT-systeem, in geschillen die zich voordoen in systeemontwikkelingsprojecten, is het vooral belangrijk om het overzicht niet te verliezen en inspanningen te leveren voor samenwerking tussen verschillende industrieën.