Intrinsic Software Value: ein Messmodell für die Abrechnung von Softwareentwicklung

Die Abrechnung von Softwareentwicklung über geleistete Arbeitsstunden stößt durch den Einsatz von Coding-Agents an ihre Grenzen. Übernehmen Sprachmodelle weite Teile der Implementierung, entkoppelt sich der zeitliche Aufwand vom gelieferten Ergebnis. Das von Jan-Henrik Hempel entwickelte Konzept des Intrinsic Software Value (ISV) definiert hierfür ein alternatives Maß: Es bestimmt den strukturellen Umfang einer Code-Änderung über eine deterministische Formel und automatisierte Code-Analysen.

Die Entkopplung von Zeit und Software-Erstellung

Die klassische Abrechnung nach Aufwand (Time and Material) setzt eine proportionale Beziehung zwischen Arbeitszeit und Entwicklungsumfang voraus. Coding-Agents hebeln diesen Zusammenhang aus. Entwickler spezifizieren Anforderungen, prüfen Ergebnisse und integrieren Module, während Sprachmodelle die Generierung des Quellcodes weitgehend automatisieren. Auf Dienstleisterseite verschiebt sich die Kostenstruktur: Die abrechenbare Entwicklerstunde verliert an Gewicht, während Inferenzkosten, Werkzeuglizenzen und die Bereitstellung spezialisierter Entwicklungsumgebungen steigen.

Wird weiterhin nach Stunden abgerechnet, sinkt der Umsatz des Anbieters mit jedem Produktivitätsgewinn. Auftraggeber wiederum können aus den erfassten Arbeitszeiten nicht mehr ableiten, wie umfangreich die gelieferte Leistung tatsächlich ist.

Der Wechsel zu Festpreisen löst dieses Problem kaum. Festpreise verlagern Schätzrisiken vollständig auf den Dienstleister. Zudem setzen sie stabile Anforderungen voraus, die in Entwicklungsprojekten selten existieren. Intern stützen sich Festpreisangebote meist weiterhin auf verdeckte Stundenschätzungen.

Das Prinzip des Intrinsic Software Value

Der ISV misst den reinen strukturellen Umfang einer Änderung an einem Softwaresystem als dimensionslose Punktzahl. Das Modell bewertet keinen ökonomischen Nutzen einer Funktion für Auftraggeber. Es erfasst ausschließlich das technische Delta zwischen der bestehenden Codebasis und den Anforderungen eines Tickets.

Die Höhe dieses Deltas hängt vom aktuellen Zustand der Software ab. Die Integration einer Authentifizierung über einen Identity Provider erfordert in einem System mit vorbereiteten Schnittstellen einen geringen Eingriff. Fehlt eine Benutzerverwaltung in der Codebasis vollständig, fällt der Eingriff erheblich größer aus. Das ISV-Modell erfasst diese Differenz als strukturelle Lücke, statt sich auf subjektive Zeitschätzungen von Entwicklern zu stützen. Die Berechnung erfolgt nach der Formelversion 3.4.

Die dreistufige Bewertungs-Pipeline

Die Ermittlung des ISV erfolgt automatisiert in drei aufeinanderfolgenden Phasen innerhalb der Continuous-Integration-Pipeline, sobald ein Ticket einen definierten Status erreicht.

Fact Finder

Der Fact Finder erstellt eine maschinenlesbare Bestandsaufnahme des Ist-Zustands. Er teilt sich in zwei Komponenten:

• Status Quo Miner: Erfasst deterministische Code-Metriken über etablierte Werkzeuge. Dazu zählen der Codeumfang mit scc, Code-Duplikate über jscpd, die Testabdeckung über Jest oder Vitest sowie die Anzahl von God Classes mit mehr als 1000 Zeilen Code. Zusätzlich ermittelt das Werkzeug den Code-Churn der vorangegangenen zwölf Monate.

• Architecture Scanner: Analysiert die Systemarchitektur über ein Sprachmodell mit niedriger Temperatur zwischen 0 und 0,1. Die Analyse dokumentiert Frameworks, Tech-Stacks, bestehende Schnittstellen und Architekturmuster.

Da das System für die Analyse beliebige Git-Commits auschecken kann, lässt sich der Zustand der Codebasis auch rückwirkend für bereits abgeschlossene Aufgaben rekonstruieren.

Gap Analyzer

Im zweiten Schritt vergleicht ein Sprachmodell die Anforderungen und Akzeptanzkriterien des Tickets mit dem ermittelten Ist-Zustand. Der Gap Analyzer arbeitet ebenfalls mit einer Temperatur zwischen 0 und 0,1 und untersucht vier technische Dimensionen:

• Änderungen am Datenmodell und notwendige Schemaerweiterungen

• Umfang und Zustand der Benutzeroberfläche

• Komplexität neuer Geschäftslogik

• Erforderliche Adapter und Schnittstellen zu Fremdsystemen

Das Sprachmodell gibt die Ergebnisse als typisiertes JSON-Objekt aus. Dieses enthält für jeden Formelfaktor einen Wert samt schriftlicher Begründung, eine Aufstellung der nötigen Architekturänderungen und einen Konfidenzwert für die Gesamtanalyse.

Erweist sich die Beschreibung eines Tickets als unzureichend, bricht die Pipeline ab und weist die Aufgabe zur Überarbeitung zurück. Liegt der Konfidenzwert unter 0,7, berechnet das System den ISV zwar, markiert das Ticket jedoch zur manuellen Überprüfung im Refinement.

Valuation Engine

Die Valuation Engine berechnet den endgültigen Punktwert. Dieser Schritt erfolgt rein deterministisch anhand fixer mathematischer Regeln, vollständig ohne Beteiligung von Sprachmodellen. Das System dokumentiert die ermittelte Punktzahl zusammen mit den Faktoren und Begründungen direkt im Ticket.

Die Formel zur Wertberechnung

Die Berechnung des ISV nach Version 3.4 lautet:

ISV = ((A1 × A2) + B1) × (C1 × C2) × D3

Die Faktoren sind ganzzahlig und folgen festen Stufen, die an die Fibonacci-Reihe angelehnt sind. Zwischenwerte sind ausgeschlossen, um Scheingenauigkeiten zu vermeiden.

Funktionaler Umfang

Der funktionale Umfang kombiniert Datenmodell, Benutzeroberfläche und Logik:

• A1 (Datenschicht): Reicht von der reinen Anzeige vorhandener Entitäten (Wert 1) über das Bearbeiten einzelner Datensätze (Wert 2) und modulübergreifende Änderungen (Wert 3) bis hin zu tiefgreifenden Schemamigrationen mit Rollback-Strategie (Wert 5).

• A2 (UI-Tiefe): Dient als Multiplikator für die Benutzeroberfläche. Reines Backend ohne Oberfläche erhält den Wert 1, standardisierte Eingabemasken den Wert 2 und zustandsbehaftete, komplexe Client-Interfaces den Wert 3.

• B1 (Logik): Bildet die Verarbeitungsschritte ab. Reines Durchreichen von Daten erhält den Wert 0, Validierungen und Bedingungen den Wert 2, komplexe Algorithmen den Wert 5 und rechenintensive Verfahren oder KI-Einbindungen den Wert 8.

Datenstruktur (A1) und Benutzeroberfläche (A2) werden multipliziert, da Oberflächenänderungen über komplexen Modellen überproportional viel Integrationsarbeit erfordern. Die Geschäftslogik (B1) wird addiert, da Entwickler sie unabhängig von der Präsentationsebene implementieren können.

Architekturfaktor

Der Architekturfaktor erfasst Risiken und die bestehende Qualität der betroffenen Codebasis:

• C1 (Eingriffstiefe): Lokale Änderungen innerhalb bestehender Module erhalten den Wert 1. Änderungen an Schnittstellen, Umbauten am Kernsystem oder die Anbindung neuer externer Systeme steigen über die Werte 2 und 3 bis auf den Maximalwert 5.

• C2 (Technische Schuld): Dieser Faktor wird über Health-Metriken abgeleitet. Ausgeprägte Duplizierung, fehlende Tests, hohe zyklomatische Komplexität und God Classes führen zu Strafpunkten. Bis zu einem Strafpunkt gilt die Codebasis als sauber (C2 = 1), bis vier Strafpunkte als moderat verschuldet (C2 = 2) und ab fünf Strafpunkten als Toxic Legacy (C2 = 3). Modifizieren Entwickler mehrere Repositories, bestimmt das System mit dem schlechtesten Zustand den Wert.

Qualitätsanspruch

Der Faktor D3 definiert die Definition of Done. Der Standardwert liegt bei 1. Fordern Auftraggeber verpflichtende End-to-End-Tests, Barrierefreiheit nach WCAG AAA oder Sicherheits-Audits, steigt der Faktor auf 2. Regulatorische Auflagen mit Audit-Trails oder externen Zertifizierungen erhöhen den Wert auf 3.

Kalibrierung und Vertragsgestaltung

Der ISV stellt eine Maßeinheit für die Größe einer Änderung dar, liefert jedoch keinen monetären Preis. Um Punkte in Kosten zu übersetzen, kalibriert der Anbieter das Modell anhand historischer Projektdaten.

Abgeschlossene Tickets werden mit den Git-Diffs, dem damaligen Zustand der Codebasis und den tatsächlich gebuchten Arbeitsstunden zusammengeführt. Eine Regressionsanalyse ermittelt daraus die Ship Rate, also den durchschnittlichen Stundenaufwand pro ISV-Punkt, inklusive statistischer Konfidenzintervalle. Multipliziert mit dem Stundensatz des Anbieters ergibt sich der Preis pro Punkt.

In Verträgen vereinbaren Auftraggeber und Dienstleister zwei feste Variablen:

• Die verbindliche Formelversion (beispielsweise Version 3.4).

• Den finanziellen Preis pro ISV-Punkt.

Produktivitätsgewinne durch verbesserte KI-Werkzeuge verbleiben beim Dienstleister: Der Punktwert einer Anforderung bleibt stabil, selbst wenn die Bearbeitungszeit sinkt.

Abgrenzung zu anderen Verfahren

Konzepte zur vermessenden Bewertung von Software existieren seit Jahrzehnten:

• Function Point Analysis (ISO/IEC 20926): 1979 von Allan Albrecht bei IBM entwickelt, bestimmt funktionale Größen über Ein- und Ausgaben sowie Schnittstellen, bleibt dabei jedoch zwingend technologieunabhängig.

• COSMIC (ISO/IEC 19761): Zählt Datenbewegungen zwischen funktionalen Prozessen, ignoriert den internen Zustand des Codes aber ebenfalls.

• Automated Function Points (ISO/IEC 19515): Ermittelt funktionale Größen automatisiert aus dem Quelltext, blendet architektonische Verschuldung jedoch weitgehend aus.

• Story Points: Dienen agilen Teams als relative Schätzgröße, sind jedoch teamabhängig, subjektiv und nicht justiziabel für vertragliche Vereinbarungen.

Der ISV unterscheidet sich von diesen Modellen dadurch, dass er die technische Schuld (C2) und die architektonische Eingriffstiefe (C1) der jeweiligen Codebasis algorithmisch in das Größenmaß einrechnet.

Grenzen und methodische Risiken

Das Modell löst die Entkopplung von Zeit und Leistung, bringt jedoch spezifische Risiken mit sich:

• Fehlender ökonomischer Bezug: Ein hoher ISV steht für einen großen baulichen Eingriff, korreliert jedoch nicht zwingend mit dem geschäftlichen Nutzen für den Kunden.

• Fehlanreize bei technischer Schuld: Der Faktor C2 vergütet Entwicklungsarbeit in schlecht gepflegtem Code höher. Refactorings, die technische Schulden abbauen, senken den ISV künftiger Tickets und damit das künftige Abrechnungsvolumen des Anbieters.

• Normative Metrik-Grenzen: Die Schwellenwerte für Strafpunkte, etwa die Grenze für Testabdeckung bei 70 Prozent, setzt der Modellbauer fest; sie sind nicht universell empirisch validiert.

• Varianz durch Sprachmodelle: Trotz niedriger Temperaturwerte unterliegen Sprachmodelle Restschwankungen. Zudem lässt sich die Punktevergabe durch gezielt formulierte Ticket-Texte beeinflussen, was eine manuelle Plausibilisierung im Entwicklerteam erforderlich macht.

• Kaltstart ohne Projekthistorie: In Neukonstellationen ohne historische Projektdaten fehlt die empirische Grundlage für die initiale Ship Rate, sodass die Vertragsparteien den Punktpreis frei verhandeln müssen.

Die Idee und das Konzept von dem ganzen stammt von Jan-Henrik Hempel. Das Repo mit allen Details ist hier zu finden: