Hva er juridiske problemer knyttet til server- og infrastruktur i systemutvikling?

IT-systemer som brukes i bedrifter er på en måte laget ved å lage spesifikasjoner og design dokumenter, og skrive kildekoden som svarer til dette innholdet. Men et system fungerer faktisk bare når det ikke bare er denne myke siden, men også den fysiske datamaskinen, det vil si infrastrukturen. I denne artikkelen vil vi diskutere juridiske problemer som er dypt relatert til infrastrukturområdet i systemutviklingsprosjekter.

Hva er infrastruktur i IT-systemer?

Teknikere som utfører systemutvikling kalles systemingeniører (SE). Utviklingsprosjekter starter med oppstrømsprosesser som å lage spesifikasjoner og design dokumenter, og fortsetter med implementering av programvare og utførelse av tester. I en bred forstand kan en systemingeniør (SE) beskrives som en tekniker som håndterer alle disse nødvendige oppgavene. Imidlertid kan det være at bedrifter og arbeidsplasser skiller mer spesifikt mellom navnene basert på arbeidsinnhold og område. Begrepet infrastruktur ingeniør refererer til teknikere som spesielt håndterer fysisk forberedelse av datamaskinens driftsmiljø i forbindelse med utvikling og drift av IT-systemer. IT-systemer som brukes i bedrifter og på arbeidsplasser er på en måte abstrakte konstruksjoner laget av kombinasjoner av kildekode. Men for at disse systemene skal kunne utføre sin forventede rolle, er det nødvendig med infrastrukturbygging, inkludert servere og nettverk. Praktisk systemutvikling går fremover med to hjul: implementering av programvare og kildekode, og forberedelse av infrastrukturen som støtter driftsmiljøet. Dette perspektivet anses å være viktig for å forhindre uforutsette problemer.

Hvordan infrastrukturproblemer kan sette prosjekter i brann

I systemutviklingsprosjekter kan det skje at man fokuserer for mye på abstrakte programmer og kildekodedesign, og overser perspektivet med infrastrukturforberedelse. Men, en situasjon der begge deler ikke er på linje kan noen ganger bli en risiko for prosjektbrann.

Hvordan feil serverstørrelse kan føre til konflikt

For eksempel, etter at all programimplementering og testing er fullført, kan det vise seg at serverens prosesseringskapasitet til slutt ikke er tilstrekkelig, og systemet kan ikke tåle praktisk bruk. For å forutsi hvor mye belastning systemet kan håndtere i driftsfasen og forberede infrastrukturen i henhold til systemets størrelse, kalles dette “sizing”. Det har faktisk vært tilfeller der feil serverstørrelse har ført til problemer. (Selv om det til slutt ble løst gjennom forlik, kan du referere til denne saken som et kjent eksempel.) For mer informasjon om hvordan konflikter mellom begge parter kan løses gjennom “forlik”, se følgende artikkel.

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

At en konflikt ble løst gjennom forlik betyr enkelt sagt at konflikten ble løst gjennom “diskusjon” mellom begge parter. Derfor, i motsetning til når en dom er utstedt av en domstol, blir innholdet i forliket vanligvis ikke akkumulert som en rettspraksis, og det har en sterk individualitet.

Kjernen i saken er omfanget av leverandørens forpliktelser til uklare spesifikasjoner

Imidlertid kan kjernen i slike konflikter også betraktes som “hvor mye ansvar skal leverandøren ta for saker som ikke er spesifikt angitt i spesifikasjonene”. Med dette i betraktning, kan du få mange tips fra innholdet i følgende artikkel.

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

I artikkelen ovenfor forklarer vi hvor mye skjønn leverandøren skal utøve og ta ansvar for implementeringen av ting som ikke er oppført i spesifikasjonene. Her forklarer vi at historien er veldig forskjellig mellom “skjermsiden” av saker som lett kan visualiseres i kravspesifikasjoner og grunnleggende design dokumenter (det såkalte “frontend” -området) og “logikksiden” som databasemigrasjon (det såkalte “backend”, “database” -området). Med andre ord, det er mer sannsynlig at bestilleren/brukeren vil bli holdt ansvarlig for “skjermsiden” av området der spesifikasjonsproblemer lett kan bekreftes av bestilleren/brukeren (som vanligvis ikke har spesialisert kunnskap om systemutviklingsprosjekter). På den annen side, det er mer sannsynlig at “logikksiden” av problemet vil bli holdt ansvarlig for leverandøren. Med dette i betraktning, siden serverstørrelsesproblemet er et område der det er vanskelig å gjenkjenne problemet med mindre du er en teknisk ekspert, er det mer sannsynlig at det vil bli holdt ansvarlig for leverandøren. Derfor, hvis du virkelig skal kjempe om dette i retten, med mindre det er noen positive omstendigheter for å frita leverandøren for ansvar, kan det forventes at dommen ofte vil være ugunstig for leverandøren.

Tiltak for å forhindre problemer forårsaket av feil serverstørrelse

For å forhindre slike problemer, er det viktig å koordinere arbeidet med implementering av programvare og skriving av kildekode med infrastrukturforberedelser. Konkrete tiltak kan inkludere følgende:

Klarhet i kontrakten om hvem som er ansvarlig for serverstørrelse

Ikke bare i slike tilfeller, men mange konflikter relatert til systemutviklingsprosjekter oppstår ofte fordi det er uklart hvem som har hvilken rolle mellom systemutviklingseksperter og brukere som er kjent med interne forhold. Selv om det er selvsagt at tett samarbeid mellom begge parter er nødvendig for en jevn prosjektprogresjon, er det ønskelig å klargjøre rollefordeling og ansvarsområde så mye som mulig i kontrakter på forhånd.

Fullstendig spesifisering og endringskontroll av utviklingskrav

I tillegg, hvis funksjonskravene som skal realiseres i utgangspunktet er vage, øker risikoen for slike konflikter. Dette har både aspekter av å klargjøre spesifikasjoner i den opprinnelige kravdefinisjonsfasen og endringskontroll i løpet av prosjektet. Hvordan man skal håndtere spesifikasjonsendringer i løpet av prosjektet er forklart i detalj i følgende artikkel.

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

Velg en utviklingsmodell som passer til prosjektets natur

I tillegg, og dette er dypt relatert til de to foregående tiltakene, er det viktig å velge en passende utviklingsmodell for systemutviklingsprosjektet basert på dets natur og skala. Generelt, hvis utviklingen av et system av en viss størrelse der serverstørrelse kan bli viktig, øker fordelene ved å adoptere en vannfallsmodell som er egnet for å klargjøre spesifikasjoner og ansvarsområder. For mer informasjon om valg av en passende utviklingsmodell basert på prosjektets natur, se følgende artikkel.

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

Oppsummering

Problemer som oppstår fra infrastrukturforberedelser kan lett bli oversett, men er avgjørende for en jevn fremdrift av systemutviklingsprosjekter. Det kan være en betydelig belastning for de som ikke er tekniske eksperter å være oppmerksomme på problemer rundt infrastrukturen. Imidlertid kan forebyggende tiltak for slike problemer sies å være en forlengelse av grunnleggende tiltak som “klargjøring av spesifikasjoner/endringskontroll”, “klargjøring av roller/ansvarsområder”, og “valg av utviklingsmodell som passer til prosjektets størrelse og budsjett”. Det første punktet som de som jobber med bedriftsjuridiske saker bør forstå, er at grunnleggende forebyggende juridiske tiltak kan være fullt ut anvendelige selv for infrastrukturproblemer. Videre, for IT-teknikere, er det viktig å forstå at infrastrukturproblemer kan bli en alvorlig risiko for prosjektbrann, og det er viktig å kunne håndtere arbeidet jevnt.