Ein gerichtlich zertifizierter Sachverständiger für Software prüft, ob Software dem Stand der Technik entspricht und welche Qualitätsmängel vorliegen. Stand der Technik ist dabei kein technischer, sondern ein juristischer Begriff: Eine Lösung muss nicht nur funktionieren, sondern bewährt, zielgerichtet und für das konkrete Anwendungsgebiet geeignet sein.
Das Wichtigste in Kürze
- Liegt die Fehlerdichte einer Software über zwei Bugs pro 1.000 Lines of Code, gilt sie als unreif und ist noch nicht für den produktiven Einsatz geeignet.
- “Stand der Technik” ist kein technischer, sondern ein juristischer Begriff: Eine Technologie muss nicht nur neu und verbreitet sein, sondern auch in genau dem jeweiligen Anwendungsgebiet bewährt sein.
- Mehr Unit-Tests zu schreiben, um eine niedrige Code-Coverage zu heben, verschlimmert die Lage häufig, weil dabei bestehendes Fehlverhalten einzementiert wird, auf das sich der Code bereits verlässt.
- Agilität erhöht Geschwindigkeit und Produktivität, führt aber nach Sebastian Dietrichs Beobachtung nicht zu höherer Softwarequalität als frühere, aufwändigere Entwicklungsansätze.
- Gerichtsprozesse um Softwaremängel enden selten wirklich vor Gericht, weil öffentliche Verfahren Auftraggeber gegenüber ihren Kunden blößstellen und beide Parteien daher außergerichtliche Einigungen bevorzugen.
Was ein Gerichtssachverständiger für Software prüft
Ein gerichtlich zertifizierter Sachverständiger für Software bewertet, ob eine Software dem Stand der Technik entspricht und welche Qualität sie tatsächlich hat. Der vollständige Titel lautet “allgemein beeideter und gerichtlich zertifizierter Sachverständiger”. Beeidet bedeutet, dass der Sachverständige einmal vor Gericht einen Eid abgelegt hat und nicht bei jedem Verfahren neu vereidigt werden muss. Zertifiziert bedeutet, dass er eine Prüfung vor einer Richterin und zwei Fachprüfern zu seinem Fachgebiet abgelegt hat.
Die Idee dahinter ist einfach. Wenn zwei Parteien in einem Zivilprozess beide auf ihrem Recht beharren und der Richter sich technisch nicht auskennt, schlägt er einen Sachverständigen aus einer Liste vor. Einigen sich beide Seiten auf diese Person, glauben sie der fachlichen Einschätzung. Der Sachverständige schafft Klarheit dort, wo das Gericht selbst nicht urteilen kann.
Warum Software-Streitfälle selten vor Gericht landen
Die meisten Software-Streitigkeiten werden außergerichtlich beigelegt, nicht im Gerichtssaal. Der Grund ist Diskretion. Ein Unternehmen, das mit einer eingekauften Software unzufrieden ist, will nicht, dass seine Kunden von dem Problem erfahren. Gerichtsprozesse sind öffentlich, also bevorzugen die Parteien die stille Einigung.
Eine Ausnahme bilden staatsnahe Unternehmen. Hier könnte der Rechnungshof eine außergerichtliche Einigung kritisch hinterfragen und unzulässige Geldflüsse vermuten. Diese Firmen suchen deshalb bewusst die gerichtliche Einigung, obwohl der eigentliche Streit oft längst beigelegt ist. Beim Zivilprozess fragt der Richter zuerst, ob eine außergerichtliche Einigung möglich wäre. Die Antwort lautet dann nein, aber die Dokumente seien bereits vorbereitet und brauchten nur noch eine Unterschrift.
Stand der Technik ist ein juristischer Begriff, kein technischer
Stand der Technik bedeutet nicht das Neueste und Coolste, sondern das Bewährte. Das ist die wichtigste Korrektur für jeden Entwickler, der reflexartig zur aktuellsten Technologie greift. Der Begriff stammt aus dem Recht und taucht in vielen Gesetzen auf. Entspricht eine Software nicht dem Stand der Technik, hat das Folgen für Gewährleistung und Schadenersatz.
Vier Kriterien machen den Stand der Technik aus. Eine Technologie muss aktuell sein, sie muss fortschrittlich sein, sie muss bewährt sein, und zwar genau im jeweiligen Anwendungsgebiet, und sie muss die Aufgabe effektiv und effizient lösen. Neu und auf Konferenzen gefeiert reicht nicht. Erst die Bewährung im konkreten Einsatz zählt.
Ein Beispiel sind viele JavaScript-Webtechnologien. Für eine Software, die zehn oder zwanzig Jahre laufen soll, eignen sie sich oft nicht, weil sie sich zu schnell ändern und keinen verlässlichen Long-Term-Support bieten. Eine neue Version kommt, ein halbes Jahr später wird die alte nicht mehr gewartet. Im kurzlebigen Webkontext ist das tolerierbar. Bei langer Laufzeit blockiert es irgendwann sogar sicherheitskritische Updates.
Stand der Technik ist gar kein technischer Begriff, sondern ein juristischer. Es reicht nicht, dass ich die Aufgabe lösen kann. Ich muss sie effizient und effektiv lösen, und das heißt, ich muss die nächsten Jahre mitbedenken. — Sebastian Dietrich
Wie sich Fehlerdichte als Reifekriterium nutzen lässt
Die Fehlerdichte gibt an, wie viele Fehler in einer Software noch unentdeckt stecken, gemessen pro 1000 Zeilen Code. Liegt die Defect Density über zwei Fehler pro 1000 Lines of Code, gilt die Software als unreif und nicht für den produktiven Einsatz geeignet. Wo Menschenleben am Spiel stehen, sinkt die Schwelle auf 0,5 Fehler pro 1000 Zeilen.
Die Zahl der ursprünglich enthaltenen Fehler lässt sich mit Formeln grob schätzen. Sie hängt von der Größe der Software ab, von ihrer Komplexität und auch von den automatisierten Tests. Laufende automatisierte Tests finden im Vorfeld bereits Fehler, die nie in einem Bugtracker landen, sondern direkt gefixt werden.
Von der geschätzten Gesamtzahl zieht der Sachverständige ab, was Tester, Probebetrieb oder Echtbetrieb bereits gefunden haben. Was übrig bleibt, ist die Zahl der noch unentdeckten Bugs. In der Praxis liegen diese Werte selbst bei sicherheitskritischer Software manchmal erstaunlich hoch, etwa zwischen 5000 und 12.000 Bugs in einem größeren System.
Tools liefern den Überblick, nicht das Urteil
Bei Software mit Millionen Codezeilen prüft niemand jede Zeile von Hand, sondern lässt sich von Werkzeugen einen Überblick verschaffen. Das bekannteste Werkzeug ist SonarQube. Sein Vorteil liegt darin, dass es programmiersprachenübergreifend arbeitet und Größe, Komplexität und technische Qualität sichtbar macht.
SonarQube bleibt allerdings low-level. Es zeigt Code Smells, aber keine Architektur- oder Designfehler. Ein Code Stench geht weiter als ein Smell: Er führt mit hoher Wahrscheinlichkeit zu einem Bug. Ein typisches Beispiel in Java ist der Vergleich mit einfachem statt doppeltem Gleichheitszeichen in einer if-Bedingung. Solcher Code läuft, ist aber fast sicher nicht bewusst so geschrieben.
Vorsicht beim blinden Korrigieren. Smells quer durchs Beet auszubessern kann neue Bugs erzeugen, weil sich Teile des Systems womöglich auf das bisherige Fehlverhalten verlassen haben. Und kein Tool kann beurteilen, ob ein Framework geeignet ist, eine Software die nächsten zehn bis fünfzehn Jahre zu tragen. Dafür braucht es den Blick auf die Historie des Frameworks, auf die Zahl der Committer und auf den realen Support. Das ist eine Frage für Menschen, nicht für ein Werkzeug.
Fachliche und technische Qualität sind zwei Paar Schuhe
Softwarequalität zerfällt in eine fachliche und eine technische Dimension, die getrennt geprüft werden. Fachliche Qualität fragt, ob die Software das tut, was gefordert wurde: ob alle Stories umgesetzt sind, ob Last- und Pflichtenheft erfüllt sind. Das ist das Feld des Tests.
Hier hilft die Sicht von hinten. Es gibt viele Testarten, die alle als Stand der Technik gelten, und jede einzelne reicht für sich allein nicht aus. Entscheidend ist die Frage, wie viele Fehler die jeweilige Testart gefunden hat. Findet eine Testart nichts mehr, heißt das nicht, dass die Software fehlerfrei ist. Dann ist eine andere Testart dran.
Zur fachlichen Qualität gehören auch die nicht-funktionalen Anforderungen, und die sind oft schwammig formuliert. Zu Usability steht selten etwas Konkretes, zu Performance heißt es bloß, die Anwendung müsse sich performant verhalten. Was performant bedeutet, bleibt offen. Zwei Sekunden Reaktionszeit sind ein Maßstab, aber ein Jahresabschluss darf länger rechnen, ohne unperformant zu sein. Die nüchterne Prüffrage lautet hier oft schlicht: Habt ihr Usability oder Performance überhaupt jemals getestet?
Technische Qualität dreht sich um den Stand der Technik und kennt hunderte Kriterien. Die Spanne reicht von Naming- und Coding-Conventions über Code Smells bis zu Abhängigkeitszyklen, Dead-Code-Analyse, doppeltem Code und der Frage, ob die definierte Architektur überhaupt eingehalten wurde. Das eine ist, ob das Auto innen und außen schön ist und einen sicher von A nach B bringt. Das andere ist, die Motorhaube zu öffnen und nachzusehen, ob da eine metrische Schraube sitzt oder eine Holzschraube.
Mehr Unit-Tests sind nie die richtige Empfehlung
Wenn die Testabdeckung zu niedrig ist, lautet die Empfehlung niemals, einfach mehr Unit-Tests nachzuschreiben. Das führt zu Verschlimmbesserung, weil es einen schlechten Zustand zementiert. Code-Coverage sagt ohnehin nichts über die Intelligenz eines Tests aus.
Der bessere Weg setzt am Änderungsprozess an. Bei jeder Änderung am Code wird vorher ein Test geschrieben, der genau diese Änderung prüft, und zwar ein intelligenter Test. So wächst die Qualität dort, wo das System sich verändert, statt blind Abdeckung zu produzieren.
Diese Logik trägt das ganze Vorgehen über sogenannte Quality Gates. Das Prinzip ist immer dasselbe: Es darf nicht schlechter werden, es muss sukzessive besser werden. Liegt die Coverage bei 13 Prozent, obwohl 70 Prozent zugesagt waren, muss sie mit jedem Release steigen. Bei neuem oder geändertem Code müssen die Regeln gelten, bei Metriken wie Coverage oder doppeltem Code darf der Wert nie sinken.
Vom Mount Everest zur Zugspitze
Ein erster Qualitätsbefund ist meist ein riesiger Haufen, und die richtige Reaktion ist nicht Schockstarre, sondern der erste Schritt. Das Bild dazu: Du stehst vor dem Mount Everest. Auf einen Berg kommst du, indem du gehst und darauf achtest, nicht abzustürzen. Einzelne Maßnahmen, immer weiter, nicht zurückfallen.
Das Ziel muss nicht der Gipfel sein. Irgendwann steht das Team auf der Zugspitze und stellt fest, dass die Qualität jetzt reicht, auch wenn das System weiter schwerfällig ist. Wer eine bedingte Abnahme verhandelt, bekommt genau dafür Zeit: Die Software darf in den Einsatz, definierte Punkte müssen innerhalb eines Jahres behoben werden, ein großer Teil der Zahlung folgt erst danach.
Wer ernsthaft technische Schulden abbaut und parallel weiterentwickelt, sollte mit drei bis vier Jahren rechnen, bis eine Software den Stand erreicht, den man sich zur Abnahme gewünscht hätte. Genau hier hilft SonarQube wieder, weil es die Quality-Gate-Logik des “besser als zuvor” abbilden kann. Der Schalter, der alle Regeln auf einmal scharf stellt und einen alles zerreißenden Report produziert, ist der falsche Weg.
Agilität hat das Tempo erhöht, nicht die Qualität
Agile Entwicklung hat Geschwindigkeit und Produktivität gesteigert, aber nicht die Qualität. Das ist die unbequeme Beobachtung aus vielen Prüfungen quer durch Branchen. Früher floss enorm viel Zeit in tonnenweise Papier und brachte am Ende dieselbe fachliche und technische Qualität, die heute mit weniger Aufwand erreicht wird.
Das Mindset ist agiler geworden, oft mehr als nur auf dem Papier. Menschen denken agiler und füllen nicht mehr stur Testreports aus, sondern gehen intelligenter an die Sache. Der Output selbst ist dadurch günstiger geworden, aber nicht besser.
Das gilt auch in stark regulierten Feldern wie der Flugindustrie oder im Gesundheitsbereich. Dort wird mehr dokumentiert, vieles läuft weniger agil, alles ist teurer. Am Ergebnis ändert das wenig. Auch diese Branchen kochen nur mit Wasser.
Schau dir an, was nach Jahren von deiner Software übrig ist
Der ehrlichste Qualitätstest kommt erst Jahre nach dem Go-live. Geh fünf, sechs, sieben Jahre nach Projektabschluss dorthin, wo deine Software eingesetzt wird, und sieh nach, was damit passiert. Erst dann zeigt sich, ob ein cooles Projekt auch echten Wert geliefert hat.
Zwei Ergebnisse sind möglich. Entweder läuft die Software noch und bringt etwas, dann war es ein gutes Projekt. Oder sie ist längst weggeworfen, weil niemand damit arbeiten konnte. Anwenderzufriedenheit allein ist kein Beweis für Business Value. Den Wert misst man erst, wenn das System im Echtbetrieb steht.
