Kodekvalitet og teknisk gæld som mangel: sådan kan det måles i en tvist

Forside · Gennemgået oktober 2026 · Af John Nielsen

Kunden har fået software, der virker, men som en ny leverandør kalder uvedligeholdelig. Eller softwaren virker ikke, og leverandøren mener, at fejlene er småting, mens kunden mener, at fundamentet er forkert. I begge tilfælde bliver kodekvaliteten et spørgsmål i tvisten. Den kan måles, men et tal for kvalitet er kun nyttigt, når det holdes op mod en målestok: det aftalte, det sædvanlige for den type løsning, eller de konkrete konsekvenser for drift og videreudvikling.

Om kvaliteten udgør en mangel, er en juridisk vurdering. Den sagkyndiges opgave er at gøre de tekniske forhold målbare, forklarlige og efterprøvelige. Hvordan skønstemaet formuleres i IT-projekter, er beskrevet på digital-bevissikring.dk.

Hvad teknisk gæld betyder

Teknisk gæld er en metafor for de omkostninger, der opstår senere, fordi en løsning er lavet hurtigere eller enklere end den burde. Gælden viser sig som kode, der er svær at ændre uden at noget andet går i stykker, manglende test, forældede afhængigheder, duplikeret logik og dokumentation, der ikke passer.

I en tvist er metaforen nyttig, men upræcis. Al software har en vis teknisk gæld, og noget af den er bevidst valgt. Spørgsmålet er derfor ikke, om der er gæld, men hvor meget, hvor den sidder, om den var aftalt eller forudsigelig, og hvad den betyder for kunden.

Målestokken først

Før der måles, skal det være klart, hvad der måles imod:

Det aftalte. Kravspecifikationen, kontraktbilag, kodestandarder, krav om testdækning, dokumentation, sikkerhedskrav eller platform.
Det sædvanlige. God praksis for den type løsning, sprog og framework på leveringstidspunktet. Det skal begrundes og helst henføres til anerkendte standarder eller udbredt praksis, ikke til den sagkyndiges smag.
Konsekvensen. Konkrete følger: hvor lang tid en typisk ændring tager, hvor mange fejl rettelser medfører, eller om løsningen kan overdrages til en anden leverandør.

ISO/IEC 25010 beskriver en produktkvalitetsmodel med ni karakteristika, blandt andet vedligeholdbarhed, pålidelighed, sikkerhed og ydeevne, hver opdelt i underkarakteristika. Den giver et fælles sprog for, hvad kvalitet omfatter. ISO/IEC 5055 går et skridt længere og definerer automatiserede mål på kildekodeniveau for fire af karakteristikaene, bygget på optællinger af kendte svagheder fra CWE-kataloget. Ingen af standarderne fastsætter grænseværdier for, hvornår kode er god nok. Det afhænger af aftalen og sammenhængen.

Hvad der kan måles

Målbare forhold, der typisk indgår:

Kompleksitet · Cyklomatisk kompleksitet pr. funktion, lange funktioner og filer, dyb indlejring
Duplikering · Andel af kode i ens eller næsten ens blokke
Test · Antal og typer af automatiske test, dækningsgrad, om testene faktisk kører og består
Afhængigheder · Forældede eller ikke længere vedligeholdte komponenter, kendte sårbarheder
Struktur · Cirkulære afhængigheder mellem moduler, lag der springes over
Byggeproces · Kan løsningen bygges fra kildekoden alene, advarsler fra compileren
Dokumentation · Om installations-, drifts- og arkitekturdokumentation findes og passer

Statiske analyseværktøjer kan beregne mange af målene automatisk. Kategorien omfatter både generelle kvalitetsplatforme og sprogspecifikke linters. Værktøjet og dets version skal dokumenteres, og det samme gælder regelsættet. Standardindstillinger er sjældent neutrale: et værktøj kan markere tusindvis af “problemer”, hvoraf de fleste er stilspørgsmål uden betydning.

Fra tal til betydning

Tal alene overbeviser sjældent, og de kan vildlede. Et par principper:

Sammenlign. Et mål for kompleksitet eller duplikering bliver først meningsfuldt, når det holdes op mod noget: en sammenlignelig løsning, projektets egne tidligere versioner eller værktøjets dokumenterede tærskler.
Find koncentrationerne. Kvalitetsproblemer er sjældent jævnt fordelt. Ofte sidder de i få centrale moduler. Det er mere sigende at vise, at de fem mest ændrede filer også er de mest komplekse, end at angive et gennemsnit for hele kodebasen.
Kobl til fejl. Forbind målene med fejllister og ændringshistorik: hvor er fejlene opstået, og hvor lang tid har rettelserne taget? Se fejllister og fejlklassifikation i en projekttvist.
Vis eksempler. Udvalgte kodeuddrag, der viser problemet konkret, gør målene forståelige for ikke-teknikere.

Historikken i versionsstyringen kan vise, hvordan kvaliteten har udviklet sig: om problemerne var der fra start, eller om de er opstået under et bestemt forløb, fx efter et skift af udviklere, under tidspres eller efter kundens ændringsønsker. Se kildekode og Git som bevis.

Typiske faldgruber

Genereret og tredjepartskode i målingen. Den trækker tallene i begge retninger og hører ikke til leverandørens egen kode. Filtrér den fra, og dokumentér det.
Den nye leverandørs vurdering. En leverandør, der skal overtage eller genopbygge en løsning, har en interesse i konklusionen. Dens vurdering kan være faglig korrekt, men er ikke uvildig.
Bagklogskab. Det sædvanlige skal vurderes efter forholdene på leveringstidspunktet, ikke efter i dag. Et framework, der nu er forældet, kan have været et rimeligt valg dengang.
Kundens egne bidrag. Har kunden eller en tredjepart ændret i koden efter leveringen, skal den leverede version bruges som grundlag.
Testdækning som kvalitetsmål. Høj dækning siger ikke, at testene tester noget væsentligt. Lav dækning er et fund, høj dækning er ikke et bevis.
Kosmetik som mangel. Afvigelser fra en kodestil uden betydning for drift eller vedligehold bør ikke fylde i rapporten.

Sikring af grundlaget

Målingen skal kunne gentages af en modparts sagkyndige. Sikr derfor:

den leverede version af kildekoden med fuld historik, med commit-id og hashværdi
byggeskripter, låsefiler og konfiguration, så løsningen kan bygges som leveret
kontraktbilag, kodestandarder og kravspecifikation i den gældende version
fejllister, ændringslog og testresultater fra projektets værktøjer
værktøjernes konfiguration, version og rå output, gemt med hashværdi

Se leverancens tilstand på overdragelsestidspunktet for sikring af kode, miljøer og builds, og bevaringsplan for et IT-projekt i krise for, hvad der bør bevares tidligt.

Rapporten

En brugbar rapport om kodekvalitet beskriver målestokken, de anvendte værktøjer og indstillinger, resultaterne med sammenligningsgrundlag, de vigtigste koncentrationer med eksempler og en vurdering af konsekvenserne for drift og videreudvikling. Den skelner klart mellem målinger, faglige vurderinger og forhold, der ikke kunne afklares. Hvor det er muligt, angives et skøn over, hvad det vil kræve at bringe koden op på det aftalte niveau, med de forudsætninger skønnet bygger på.

Hvad målingen kan og ikke kan bevise

Målinger af kodekvalitet kan vise, hvor koden afviger fra et aftalt eller sædvanligt niveau, hvor problemerne er koncentreret, og hvordan de hænger sammen med fejl og ændringsomkostninger. De kan ikke alene vise, at løsningen er mangelfuld i juridisk forstand, og de kan ikke afgøre, om parterne havde aftalt et bestemt kvalitetsniveau. Det kræver, at de tekniske fund ses i lyset af aftalegrundlaget.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Open source-licenser og SBOM som bevis i licens- og ophavsretstvister · Sikkerhedsfejl i leveret software: vurdering som mangel

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik