CostmarkCostmark

Insights

Softwareprojekte kalkulieren: warum die Menge der Einflussgrößen das eigentliche Problem ist

Lennart Stabenow

Nicht die Rechnung ist das Schwierige an der Kalkulation eines Softwareprojekts, sondern die Zahl der Größen, die gleichzeitig zusammenwirken — Anforderungen, Konfigurationen, Regelwerke. Was sich dazu nachzählen lässt und was daraus für die Aufwandsschätzung folgt.

Warum lässt sich ein Softwareprojekt so schwer kalkulieren?

Weil der Gegenstand der Kalkulation eine Eigenschaft hat, die andere Gewerke in diesem Maß nicht haben: Er besteht fast nur aus Unterschieden.

Frederick Brooks hat das 1986 beschrieben. Software sei „more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level)“. Ein größeres Projekt enthält deshalb nicht mehr vom Gleichen, sondern mehr Verschiedenes — und daraus folgt der Satz, um den es hier geht: „In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly“ (TR86-020, University of North Carolina). Übersetzt: Die Teile wirken aufeinander, und die Komplexität wächst schneller als der Umfang.

Wer eine Baugruppe kalkuliert, arbeitet mit Größen, die sich addieren: Stückliste, Fertigungszeiten, Materialpreise. Wer ein Softwareprojekt kalkuliert, arbeitet mit einer Menge von Entscheidungen, die einander bedingen. Wie groß diese Menge in einem ausgewachsenen System wird, lässt sich nachzählen: Der Linux-Kernel wird über mehr als 15.000 voneinander abhängige Konfigurationsoptionen eingestellt (Borges, Pereira, Khelladi, Acher, EASE 2025).

Das gilt auf beiden Seiten des Tisches. Wer anbietet, muss diese Menge kalkulieren, um einen Preis nennen zu können. Wer vergibt, muss sie nachvollziehen, um den Preis einordnen zu können — mit weniger Einblick und meist mit weniger Zeit. Die Aufgabe ist dieselbe, nur die Unterlagen sind unterschiedlich vollständig.

Wie schnell wächst die Zahl der Möglichkeiten?

Schneller, als die Anschauung mitkommt. Das US-Normungsinstitut NIST rechnet ein Beispiel vor, das jeder nachprüfen kann. Die Ressourcen-Konfigurationsdatei einer Android-App kennt 35 Einstellungen. Für den Test werden sie zu neun Parametern mit je drei bis fünf möglichen Werten zusammengefasst. Das ergibt 3 × 3 × 4 × 3 × 5 × 4 × 4 × 5 × 4 = 172.800 Konfigurationen (NIST SP 800-142, S. 16).

Balkendiagramm mit neun Zeilen auf logarithmischer Skala. Es zeigt, wie viele Konfigurationen entstehen, wenn zu einer Optionsgruppe schrittweise die nächste hinzukommt: 3, 9, 36, 108, 540, 2.160, 8.640, 43.200 und schließlich 172.800 Konfigurationen bei neun Gruppen.

Rechenbeispiel nach NIST SP 800-142, Tabelle 4 — jede weitere Optionsgruppe multipliziert, sie addiert nicht. Keine Messung an einem Projekt.

NIST rechnet weiter, was das praktisch bedeutet: Braucht ein Testsatz 15 Minuten, wären das „roughly 24 staff-years“ — rund 24 Personenjahre, bei den dort angesetzten Personalkosten mehr als drei Millionen Dollar. Für neun Angaben aus einer Datei.

Der Ausweg ist nicht, mehr zu prüfen, sondern gezielter. NIST hat ab 1999 untersucht, wie viele Größen an realen Ausfällen beteiligt sind. In der untersuchten NASA-Anwendung gingen 67 Prozent der Fehler auf einen einzelnen Parameterwert zurück, 93 Prozent auf Zweier- und 98 Prozent auf Dreierkombinationen; über die untersuchten Anwendungen hinweg wurden alle Fehler von Wechselwirkungen aus höchstens vier bis sechs Größen ausgelöst. Ein Testsatz, der jede Viererkombination mindestens einmal enthält, kommt im Beispiel oben mit 625 statt 172.800 Konfigurationen aus — 0,4 Prozent.

Zwei Dinge zählen daran für die Kalkulation. Die Auffächerung ist real und multiplikativ. Und sie ist beherrschbar — aber nur mit einer Systematik, die die Kombinationen erzeugt, statt sie im Kopf zu halten. Der zweite Punkt ist eine Übertragung, kein Beleg: Testabdeckung ist nicht Kalkulation.

Was Regeln und Vorschriften zusätzlich auffächern

Zur inhaltlichen Menge kommt eine zweite, die in älteren Erfahrungswerten kaum vorkommt. Für ein und dieselbe Steuerungssoftware können in den nächsten Jahren mehrere Regelwerke gleichzeitig greifen:

  • Die Maschinenverordnung (EU) 2023/1230 gilt ab dem 20. Januar 2027 und bezieht Software ausdrücklich ein.
  • Der Cyber Resilience Act (EU) 2024/2847 verpflichtet Hersteller von Produkten mit digitalen Elementen ab dem 11. September 2026 zu Meldepflichten und ab dem 11. Dezember 2027 vollständig.
  • Die KI-Verordnung (EU) 2024/1689 greift für KI-Systeme, die Sicherheitsbauteil eines nach Sektorrecht geprüften Produkts sind, ab dem 2. August 2027.

Welchen Umfang allein einer dieser Rechtsakte hat, zeigt eine Randnotiz: Für den Cyber Resilience Act hat die Europäische Kommission mit dem Normungsauftrag M/606 einen Satz von 41 Normen in Auftrag gegeben (Europäische Kommission, CRA — Standardisation).

Jede dieser Anforderungen wird im Projekt zu Arbeit: Nachweisdokumentation, Schwachstellenbehandlung über die Produktlebensdauer, Konformitätsbewertung, geänderte Freigabeprozesse. Dieser Aufwand steckt in den Erfahrungswerten abgeschlossener Projekte nicht — die Vorhaben, aus denen die Erfahrung stammt, unterlagen diesen Pflichten noch nicht. Damit verliert der Analogieschluss „das letzte Projekt war ungefähr so groß“ genau dort seine Grundlage, wo er am häufigsten benutzt wird. Welche Pflicht im Einzelfall greift, ist eine Rechtsfrage. Hier zählt nur die Menge.

Warum reicht Erfahrung dafür nicht mehr aus?

Zwei Befunde, die man nebeneinanderlegen muss.

Der erste: Aufwandsschätzung ist in der Praxis ein Urteilsverfahren, und das aus gutem Grund. Magne Jørgensen und Barry Boehm haben die Frage 2009 in IEEE Software gegeneinander diskutiert. Jørgensen hält fest, dass in 10 von 16 verglichenen Studien „typically simple and unstructured“ urteilsbasierte Verfahren zu genaueren Schätzungen führten als aufwendige formale Modelle — obwohl es solche Modelle seit über 40 Jahren gibt (IEEE Software 2009). Die verbreitete Methode ist also die menschliche Einschätzung, und sie ist, gemessen an den Alternativen, nicht die schlechtere.

Der zweite: Das menschliche Arbeitsgedächtnis hat eine Kapazitätsgrenze. Nelson Cowan hat die Evidenz dazu zusammengetragen und kommt auf eine zentrale Kapazitätsgrenze von im Mittel etwa vier Einheiten — drei bis fünf, sobald Zusammenfassen und inneres Wiederholen ausgeschlossen sind. Im Original: „a single, central capacity limit averaging about four chunks“ (Behavioral and Brain Sciences 2001).

Diese Zahl bedeutet nicht, dass eine erfahrene Fachkraft nur vier Dinge bedenken kann. Fachleute umgehen die Grenze ständig — über Struktur, Notation, Checklisten, Langzeitgedächtnis. Sie bedeutet etwas anderes: Das gleichzeitige Gegeneinanderabwägen vieler wechselwirkender Größen findet außerhalb des Kopfes statt, oder es findet nicht statt. Solange die Zahl der Größen klein blieb, fiel das nicht auf. Bei 172.800 Möglichkeiten aus neun Angaben und drei parallel laufenden Regelwerken fällt es auf.

Das ist kein Vorwurf an die Erfahrung. Es ist eine Aussage über Mengen.

Was leistet ein Rechenmodell — und was nicht?

Die bequeme Schlussfolgerung wäre, dass ein Modell das Problem löst. So einfach ist es nicht, aber der Befund von 2009 ist auch keine Absage. Es lohnt sich, ihn genauer zu lesen.

Jørgensens Einwände richten sich gegen den Aufwand und die Reichweite damaliger Modelle, nicht gegen deren Mathematik. Erstens braucht jedes Modell für seine Eingaben wiederum ein Urteil: „All meaningful estimation models require judgment to produce the input to the models.“ Zweitens lässt sich hochspezifisches Wissen — wer im Team arbeitet, wie reif eine Schnittstelle wirklich ist — mechanisch nicht einbauen. Boehm hält in derselben Debatte dagegen: Gerade unter hoher Unsicherheit brauche man Sensitivitäts-, Risiko- und Abwägungsrechnungen in einer Zahl, die „goes well beyond the available time of experts to perform“, während ein Modell sie schnell durchrechnet.

Der erste Einwand gilt unverändert. Der zweite hing nie an der Rechnung, sondern am Modellbau: hunderte Positionen beschreiben, konsistent halten, jeder eine Verteilung und ihre Abhängigkeiten zuordnen, das Ganze bei jeder Änderung nachziehen. Dieser Aufwand hat den Nutzen in aller Regel überstiegen. Also wurde aggregiert — und das Urteil blieb die praktikablere Methode.

Genau diese Rechnung hat sich verschoben. Der Detailgrad, der lange nicht wirtschaftlich darstellbar war, ist es heute — durch verfügbare Rechenleistung und maschinelle Verfahren im Modellaufbau. Damit rückt in Reichweite, was Boehm beschreibt: durchgerechnete Sensitivitäten, die zeigen, welche Größen das Ergebnis überhaupt treiben.

Was dabei nicht passiert: Die Maschine erzeugt keine Kalkulation. Sie nimmt einen Teil der Fleißarbeit ab; tragfähig wird das Modell erst durch kalkulatorisches Handwerk, Domänenwissen, Statistik und die Modellierung selbst. Die Aufgabe bleibt anspruchsvoll. Sie ist nur nicht mehr unwirtschaftlich.

Was an einer Kalkulation dadurch besser wird, hat mit Nachkommastellen nichts zu tun. Es ist die Auflösung: Der Aufwand wird feiner zerlegt, statt auf wenige Sammelpositionen verdichtet zu werden, deren Verhältnis zum Ergebnis niemand prüfen kann. Das ist zugleich die Antwort auf Jørgensens dritten Einwand — dass das Verhältnis von Aufwand und Umfang über Datensätze und über die Zeit hinweg nicht stabil ist. Was fein aufgelöst ist, lässt sich nachkalibrieren; ein globaler Faktor lässt sich nur ersetzen. Und die Zerlegung trägt schon für sich etwas bei, unabhängig von der Rechnung dahinter: Sie hebt die Schätzung an und verringert die Verzerrung, umso stärker, je vielteiliger die Aufgabe ist (Kruger, Evans, Journal of Experimental Social Psychology 2004). Der Weg zur Zahl trägt hier mehr bei als die Zahl.

Was in diesem Beitrag nicht steht, ist eine gemessene Genauigkeitsaussage. Die gibt es erst, wenn genügend abgeschlossene Projekte gegen ihre eigene Prognose gestellt sind — und sie wird dann als Bandbreite berichtet, nicht als Prozentpunkt. Auch Brooks' Befund hat sich nicht erledigt: Ein Wundermittel, das die wesensmäßige Komplexität entfernt, gibt es nicht. Was bleibt, ist eine klarere Arbeitsteilung. Wie unsicher eine Dauer ist, wie reif eine Schnittstelle wirklich ist, welche Anforderung noch kippen kann — das ist eine Fachfrage. Was daraus in der Summe folgt, ist eine Rechenfrage. Die Trennlinie verläuft nicht zwischen Mensch und Maschine, sondern zwischen Urteilen und Buchführen.

Was daraus folgt

Die Reihenfolge ist umgekehrt zu der, die man erwartet: Die Rechnung steht am Ende, nicht am Anfang. Zuerst wird das Projekt so zerlegt, dass die Menge überhaupt sichtbar wird — Liefergegenstände, Arbeitspakete, Ressourcen, Dauern, Abhängigkeiten. Die Pflichten aus den Regelwerken gehören dabei als eigene Arbeitspakete hinein, nicht als pauschaler Zuschlag am Schluss. Erst danach ist die Frage nach Aufwand und Bandbreite sinnvoll; die Methode beschreibt, wie das technisch abläuft.

Für ein Vorhaben, das Sie selbst durchführen, heißt das: Aus den vorhandenen Unterlagen entsteht zuerst ein vollständiges Projektbild, und daraus folgt die Projektkalkulation mit einer Bandbreite über den Verlauf. Sie ist vollständig, nicht vorsichtig — wo Sie innerhalb davon planen, ist Ihre Entscheidung.

Was dabei nicht passiert: Die Komplexität wird nicht kleiner. Sie wird darstellbar — und erst das macht sie entscheidbar.

Quellen