Hvad er de juridiske problemer forbundet med server- og infrastruktur i systemudvikling?

IT-systemer, der anvendes i virksomheder, er på en måde skabt ved at lave specifikations- og design-dokumenter og skrive kildekode, der svarer til indholdet. Men et system fungerer faktisk kun med den fysiske computer, det vil sige infrastrukturen, ikke kun denne bløde side. I denne artikel vil vi diskutere juridiske spørgsmål, der er dybt relateret til infrastrukturområdet i systemudviklingsprojekter.

Hvad er infrastrukturen i et IT-system?

Teknikere, der udfører systemudvikling, kaldes systemingeniører (SE). Udviklingsprojekter starter med opstrømsprocesser som oprettelse af specifikationer og design dokumenter, og fortsætter med implementering af programmer og udførelse af tests. I en bredere forstand kan en systemingeniør (SE) beskrives som en tekniker, der håndterer alle de opgaver, der er nødvendige for disse processer. Afhængigt af virksomheden eller arbejdspladsen kan der dog være yderligere specifikke betegnelser baseret på de opgaver og områder, de er ansvarlige for. Betegnelsen infrastruktur ingeniør refererer til teknikere, der specifikt håndterer opgaver relateret til udvikling og drift af IT-systemer, især ved at forberede det fysiske computerdriftsmiljø. IT-systemer, der bruges i virksomheder og på arbejdspladser, er på en måde abstrakte konstruktioner, der består af kombinationer af kildekode. Men for at disse systemer kan udføre deres forventede roller, er det afgørende at opbygge infrastrukturen omkring servere og netværk. Praktisk systemudvikling skrider frem på to hjul: implementering af programkildekode og forberedelse af infrastrukturen, der understøtter dens driftsmiljø. Dette perspektiv anses for at være vigtigt for at forhindre uforudsete problemer.

Hvad er de konkrete situationer, hvor infrastrukturproblemer kan sætte et projekt i brand?

I systemudviklingsprojekter kan det ske, at man fokuserer for meget på abstrakte programmer og kildekode design, og overser vedligeholdelsen af infrastrukturen. Men hvis disse to aspekter ikke er i sync, kan det potentielt føre til en risiko for internetflammer for projektet.

Hvad er de sager, hvor fejl i serverstørrelse kan forårsage konflikter?

For eksempel, efter at alle programmerings- og testopgaver er afsluttet, kan det vise sig, at serverens ydeevne ikke er tilstrækkelig, og systemet kan ikke håndtere den praktiske anvendelse. Dette kaldes “sizing”, hvor man forudser, hvor meget belastning systemet vil være under i driftsfasen, og tilpasser infrastrukturen til systemets størrelse. Der har været tilfælde, hvor fejl i serverstørrelsen har ført til problemer. (Selvom det blev løst gennem forlig, kan du referere til denne sag som et kendt eksempel.) For mere information om løsning af konflikter mellem parterne gennem “forlig”, se nedenstående artikel.

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

At en konflikt er blevet løst gennem forlig betyder simpelthen, at konflikten er blevet løst gennem “diskussion” mellem parterne. Derfor, i modsætning til når en dom er afsagt af en domstol, bliver indholdet af forliget normalt ikke akkumuleret som en præcedens, men er mere individuelt.

Essensen af sagen er omfanget af leverandørens forpligtelser over for uklare specifikationer

Imidlertid kan essensen af sådanne konflikter også ses som “hvor meget ansvar skal leverandøren bære for ting, der ikke er specificeret i specifikationerne”. Med dette i tankerne, kan du få mange tips fra indholdet af nedenstående artikel.

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

I ovenstående artikel forklarer vi, hvor meget skøn leverandøren skal udøve og påtage sig implementeringsforpligtelsen for ting, der ikke er angivet i specifikationerne. Her forklarer vi, at historien er meget forskellig mellem “skærm-siden” emner, der let kan visualiseres i kravspecifikationer og grundlæggende design dokumenter (det såkaldte “frontend” område), og “logik-siden” som data migration (det såkaldte “backend”, “database” område). Det vil sige, jo mere “skærm-siden” området, hvor specifikationsproblemer let kan bekræftes af ordregiveren/brugeren (som normalt ikke har specialiseret viden om systemudviklingsprojekter), jo mere tilbøjelig er ordregiveren/brugeren til at blive holdt ansvarlig. På den anden side, “logik-siden” problemer er mere tilbøjelige til at blive holdt ansvarlig af leverandøren. Med dette i tankerne, kan serverstørrelsesproblemer, som er svære at genkende, medmindre man er en teknisk ekspert, betragtes som et område, hvor leverandøren er mere tilbøjelig til at blive holdt ansvarlig. Derfor, hvis dette punkt skulle blive seriøst bestridt i retten, kan det forventes, at dommen ofte vil være ugunstig for leverandøren, medmindre der er overbevisende omstændigheder for at fritage leverandøren for ansvar.

Foranstaltninger til at forhindre problemer forårsaget af fejl i serverstørrelsesbestemmelse

For at forhindre de tidligere nævnte problemer er det vigtigt at koordinere arbejdet med implementering af programmer, skrivning af kildekode og infrastrukturel forberedelse. Konkrete foranstaltninger kan omfatte følgende:

Klarlæg ansvar for serverstørrelsesbestemmelse i kontrakten

Ikke kun i disse tilfælde, men mange konflikter omkring systemudviklingsprojekter opstår ofte, når rollefordelingen mellem systemudviklingseksperter og brugere, der er bekendt med interne forhold, er uklar. Selvom det er selvfølgeligt, at tæt samarbejde mellem begge parter er nødvendigt for en gnidningsløs projektudvikling, er det ønskeligt at gøre rollefordelingen og ansvarsområdet så klart som muligt i kontrakten på forhånd.

Specificer udviklingskravene fuldt ud og håndter ændringer effektivt

Desuden, hvis de funktionelle krav, der skal realiseres, er vage, øges risikoen for konflikter. Dette involverer både klarlæggelse af specifikationer i den oprindelige kravdefineringsfase og ændringsstyring i løbet af projektet. Hvordan man skal håndtere specifikationsændringer i løbet af projektet er detaljeret forklaret i følgende artikel.

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

Vælg en udviklingsmodel, der passer til projektets karakter

Desuden, og dette er dybt forbundet med de to ovenstående foranstaltninger, er det vigtigt at vælge en passende udviklingsmodel for systemudviklingsprojekter baseret på deres karakter og skala. Generelt, hvis det er udviklingen af et system af en vis størrelse, hvor serverstørrelsesbestemmelse kan blive vigtig, kan det være fordelagtigt at anvende vandfaldsmodellen, der er velegnet til at klarlægge specifikationer og ansvarsområder. For en detaljeret forklaring på valg af en passende udviklingsmodel baseret på projektets karakter, se følgende artikel.

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

Opsummering

Problemer, der opstår fra infrastrukturens miljøforberedelse, kan let blive overset i bestræbelserne på at sikre en gnidningsløs fremdrift af systemudviklingsprojekter. Det kan være en betydelig byrde for ikke-tekniske eksperter at skulle være opmærksomme på problemer omkring infrastrukturen. Dog kan forebyggende foranstaltninger mod sådanne problemer ses som en forlængelse af grundlæggende tiltag som ‘klar specifikation / grundig ændringsstyring’, ‘klar rolle / ansvarsområde’ og ‘valg af udviklingsmodel tilpasset projektets størrelse og budget’. Det første, som folk involveret i virksomhedens juridiske anliggender bør forstå, er, at grundlaget for forebyggende jura kan være fuldt ud anvendeligt på infrastrukturproblemer. Desuden, for IT-teknikere, er det vigtigt at forstå, at infrastrukturproblemer kan blive en alvorlig risiko for projektets nedbrænding, og at det er vigtigt at styre arbejdet effektivt.