Om juridiske problemer knyttet til databaser i IT-systemer

Når man skal forstå juridiske problemer knyttet til IT-systemer, kreves det ikke bare en systematisk forståelse av loven, men også kunnskap om komponentene i et IT-system. I denne artikkelen vil vi forklare hvordan et IT-system er sammensatt av forskjellige deler, og hvordan disse delene fungerer sammen. Vi vil også diskutere juridiske problemer som er spesielt relevante for databaser, som kan være vanskelige å se fra brukerens perspektiv.

IT-systemer består av “skjermbilder” og “logikk”

Hva er “skjermbilder” i et IT-system?

Når man prøver å forstå strukturen til et IT-system, er det mest iøynefallende ofte skjermens utseende. I en typisk systemutviklingsprosess, etter “kravspesifikasjonen” hvor funksjonene blir identifisert, kommer vanligvis “skjermdesign” og organisering av “skjermoverganger”. Dette visuelle aspektet ved skjermen er naturligvis et område som er lett synlig for brukeren som bestiller systemutviklingen, og det er også et område hvor kommunikasjon mellom brukeren og leverandøren ofte forekommer. I artikkelen nedenfor forklarer vi “samarbeidsplikten” som brukeren har overfor leverandøren i hele systemutviklingsprosessen for å oppnå prosjektmålene.

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

I denne artikkelen forklarer vi hovedsakelig at brukeren har en plikt til å samarbeide med leverandøren, spesielt i faser som grunnleggende design (dvs. skjermbilder).

“Skjermbilder” i et IT-system er vanligvis skrevet i henhold til reglene for datamaskinspråk som HTML og CSS. Når vi snakker om “skjermbilder” i et IT-system, er det forskjellige betegnelser som “frontend”, “UI (User Interface)”, osv., men hovedfokuset er på “brukervennlighet” og “lesbarhet” fra brukerens perspektiv.

Hva er “logikk” i et IT-system?

Men hvis et IT-system bare består av “skjermbilder”, vil det bare være en “skjerm” uten noen “bevegelse” eller “endring”. Selv om inndata fra brukeren mottas og utdata vises på “skjermen”, er det en “beregning” i denne prosessen.

Disse komponentene, som ikke er synlige for brukeren og kan sies å være “baksiden av systemet”, utfører komplekse beregninger og kontroller. Prosesser som å søke etter data fra skjermen, endre data, legge til eller slette, er bare mulige fordi det er en forhåndsbygd database i bakgrunnen. Behandling av forskjellige typer informasjon i databasen gjøres vanligvis med et datamaskinspråk kalt SQL.

Å lage en vei fra en knapp plassert på skjermen til utførelsen av nødvendig SQL-setning, det er slik at et komplett system med bevegelse og endring blir fullført.

For øvrig, diskusjoner om å sette sammen forskjellige logikker som ikke er synlige fra “skjermen” blir ofte referert til som “backend”.

Risikoen ved å bare diskutere systemer ut fra deres “utseende” på skjermen

Forklaringen så langt danner grunnlaget for strukturen til IT-systemer (antatt å fungere på nettet). Forståelse av slike saker har stor betydning også når det gjelder juridiske diskusjoner, forebygging av prosjektkonflikter og krisehåndtering. Spesifikt kan det oppstå misforståelser i kommunikasjonen mellom brukere som bare er opptatt av “utseendet” på skjermen, og leverandører som håndterer mange viktige oppgaver på den usynlige “logikksiden”.

Risikoet ved at brukere og leverandører har helt forskjellige bekymringspunkter

For eksempel, brukere som fokuserer på “skjermbildet” når de snakker om IT-systemer, har en tendens til å være likegyldige til kompleksiteten i den interne strukturen. Derfor kan de ofte ikke forstå hvor mye en tilsynelatende “liten funksjonstillegg” eller “mindre spesifikasjonsendring” kan påvirke mange prosesser. For eksempel forklarer følgende artikkel de juridiske problemene som ofte oppstår når man avvikler et eksisterende system som for tiden er i drift, i forbindelse med et prosjekt for utvikling av et nytt system.

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

Her forklarer vi at det ofte oppstår problemer med dataoverføring til det nye systemet når det gamle systemet avvikles. Med andre ord, kompleksiteten i de interne beregningene og kontrollmekanismene, som er vanskelig å forestille seg ut fra utseendet, kan potensielt føre til uventede problemer for brukerne. I tillegg, fordi brukerne ikke forstår “hvordan systemleverandørene føler”, kan det oppstå situasjoner der endringer blir gjort i ettertid.

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

I slike tilfeller hvor spesifikasjonsendringer eller funksjonstillegg blir pålagt i ettertid, kan det også være et presserende problem om det er mulig å øke belønningen i ettertid.

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

Risiko ved brukerens likegyldighet til “logikk” på baksiden

I tillegg kan det være tilfeller der deler som ikke kan observeres av brukeren, blir en stor hendelse når problemer oppdages. Her er noen eksempler på dette.

Risiko for problemer med vedlikehold og sikkerhet

Dette inkluderer situasjoner der du ikke kan implementere tilleggsfunksjoner, og systemet blir gradvis tregere og slutter å fungere mens du bruker det.

Det er også en metode kalt “SQL-injeksjon” som en sikkerhetsangrep som utnytter mangler i koden implementert på skjermens side, og trekker ut personlig informasjon og konfidensiell informasjon som ikke skal vises på skjermen. Vi behandler detaljene om tilfeller som har blitt alvorlige konflikter som et resultat av dette i følgende artikkel.

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

Hovedtemaet for denne artikkelen er risikoen forbundet med bruk av rammeverk og biblioteker, men rettssakene som er publisert er saker der angrep på sårbarheter ved hjelp av SQL-injeksjon har blitt utført.

Risiko for at styringen ikke strekker seg til operatørens jobb

Det faktum at IT-systembrukere er likegyldige til “logikken” bak, er også knyttet til problemet med at styringen blir vanskelig å strekke seg til jobben til IT-systemoperatøren. I følgende artikkel relatert til dette innholdet forklarer vi viktigheten av databehandlingsarbeid med temaet “tap av data på grunn av operatørens uaktsomhet”.

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

Risiko for at logikken er feil selv om den fungerer riktig på overflaten

Det faktum at systemdiskusjonen ikke er begrenset til “skjermen” betyr at selv om systemet fungerer riktig på overflaten, kan “logikken” være feil. Dette kan plutselig bli avslørt i uregelmessige operasjoner som “en gang hver sjette måned” eller “en gang i året”, selv om det ikke ble klart i det daglige grunnleggende arbeidet.

I slike tilfeller blir det et juridisk problem med (ikke mislighold av forpliktelser, men) mangelfull garanti ansvar som “en sak der mangler ble oppdaget etter levering av systemet”.

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

Som en mottiltak i tilfelle en feil blir oppdaget etter inspeksjon, forklarer vi flyten i detalj i følgende artikkel.

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

Oppsummering

Systematisk forståelse av systemutvikling og juridiske spørsmål

Det er viktig å forstå hvilken komponent i IT-systemet som er involvert i juridiske problemer knyttet til systemutvikling, før man identifiserer de juridiske problemstillingene. Både fra et juridisk og et IT-systemperspektiv, er det viktig i konflikter som oppstår i systemutviklingsprosjekter å ikke miste oversikten over det store bildet, og å legge spesiell vekt på samarbeid mellom forskjellige bransjer.