Die am häufigsten vergessene Klausel im Softwareprojekt: Abnahmekriterien

Als Softwarefirma ist das eines der ersten Themen, die wir in jedem Projekt besprechen. Ein Projekt, das ohne schriftliche Abnahmekriterien beginnt, ist ein Projekt, in dem bis zum Tag der Übergabe jeder etwas anderes erwartet.

Wird ein Softwarestreitfall eröffnet, diskutieren die Parteien meist Folgendes. Funktioniert die Software oder nicht.

Der Grund, warum sich dieser Streit nicht klären lässt, ist kein technischer. Im Vertrag steht nicht, was "funktioniert" bedeutet. Fehlt ein Abnahmekriterium, sagt der Entwickler, er habe geliefert, der Kunde sagt, er habe nichts erhalten, und beide haben nach ihrem eigenen Maßstab recht.

Dieses eine Fehlen ist der gemeinsame Nenner der Softwarestreitigkeiten, die ich gesehen habe.

Wie das Abnahmekriterium formuliert werden sollte

Die Abnahme ist der Zeitpunkt, der die rechtliche Folge der Lieferung auslöst. Auch die Frist der Mängelhaftung beginnt von dort an zu laufen. Das heißt, ist dieses Datum unbestimmt, ist auch unbestimmt, wann die Haftung endet.

Eine funktionierende Abnahmeklausel enthält Folgendes. Die Liste der Abnahmetests, die Umgebung, in der der Test durchgeführt wird, wer ihn durchführt, die Einspruchsfrist und die Regel, dass die Abnahme als erfolgt gilt, wenn innerhalb der Frist kein Einspruch eingeht.

Der am häufigsten übersehene Punkt ist die Testumgebung. Eine Software, die auf dem Rechner des Entwicklers funktioniert, funktioniert in der Umgebung des Kunden möglicherweise nicht, und an diesem Punkt wird gestritten, wer dafür verantwortlich ist. Ist die Umgebung im Vertrag definiert, entsteht dieser Streit nicht.

Das Abnahmekriterium an subjektives Gefallen zu knüpfen, ist dagegen die schlechteste Wahl. Eine an "die Zufriedenheit des Kunden" geknüpfte Abnahme schafft eine zeitlich unbegrenzte Verpflichtung, und die Arbeit des Entwicklers endet nie.

Geistige Eigentumsrechte gehen nicht automatisch über

Der zweithäufigste Fehler ist die Eigentumsvermutung. Der Kunde glaubt, mit der gezahlten Vergütung Eigentümer des Codes zu sein. Rechtlich ist das nicht so.

Computerprogramme sind nach dem Gesetz Nr. 5846 als Werk geschützt, und sofern nichts anderes vereinbart ist, verbleiben die Verwertungsrechte beim Urheber. Die Übertragung muss ausdrücklich geregelt, schriftlich vorgenommen werden, und die übertragenen Rechte müssen einzeln aufgeführt werden. Eine allgemeine Formulierung wie "sämtliche Rechte werden übertragen" bleibt angreifbar.

Daneben müssen drei Kategorien unterschieden werden. Speziell für den Kunden geschriebener Code wird in der Regel übertragen. Bereits vorher bestehende Komponenten des Entwicklers werden nicht übertragen, sondern lizenziert, und Umfang sowie Dauer der Lizenz werden gesondert festgelegt. Open-Source-Komponenten unterliegen ihren eigenen Lizenzen, und die Liste der verwendeten Komponenten muss dem Vertrag als Anlage beigefügt werden.

Werden diese drei nicht unterschieden, ergibt sich Folgendes. Der Kunde glaubt, Eigentümer des gesamten Codes zu sein, der Entwickler nutzt seine eigene Bibliothek weiterhin in einem anderen Projekt, und das Problem fällt erst bei einem Streitfall auf.

Ein Vertrag ohne Änderungsmanagement funktioniert nicht

Wie gut der Leistungsumfang auch formuliert ist, während des Projekts kommen Änderungswünsche auf. Steht im Vertrag nicht, wie mit einem solchen Wunsch umgegangen wird, wird jeder Wunsch zu einer Verhandlung.

Eine funktionierende Regelung beantwortet folgende Fragen. An wen und in welcher Form wird der Wunsch übermittelt. Von wem und innerhalb wie vieler Tage wird die Auswirkungsanalyse erstellt. Wie werden Auswirkungen auf Preis und Zeitplan berechnet. Mit wessen Unterschrift wird die Genehmigung erteilt. Was geschieht mit einem nicht genehmigten Wunsch.

Sind diese fünf Fragen beantwortet, wird aus der Änderung kein Krisenfall mehr, sondern ein Prozess.

Die Stellung als Auftragsverarbeiter entsteht unbemerkt

Greift der Entwickler auf personenbezogene Daten des Kunden zu, wird er zum Auftragsverarbeiter im Sinne des Gesetzes Nr. 6698. Diese Stellung wird oft erlangt, ohne dass es bemerkt wird.

Am häufigsten geschieht dies durch die Verwendung echter Daten in der Testumgebung. Eine Kopie der Produktionsdatenbank wird in die Testumgebung übernommen, die Entwickler arbeiten damit, und ab diesem Moment entsteht eine Datenverarbeitungsbeziehung. Enthält der Vertrag hierzu keine Regelung, läuft die Beziehung ohne rechtliche Grundlage.

Die sauberste Lösung besteht darin, diese Situation gar nicht erst entstehen zu lassen. Mit maskierten oder synthetischen Daten zu testen, ist technisch nicht schwierig und beseitigt das Risiko weitgehend. Ist der Zugriff auf echte Daten wirklich unumgänglich, müssen Gegenstand, Dauer und Zweck der Verarbeitung, die Weisungsgebundenheit des Entwicklers, der Einsatz von Unterauftragsverarbeitern, Sicherheitsmaßnahmen sowie die Rückgabe oder Vernichtung der Daten bei Vertragsende schriftlich geregelt werden.

Wartung ist ein eigener Vertrag

Zum Schluss Wartung und Support. Dies ist eine von der Entwicklung getrennte Leistung und muss gesondert geregelt werden.

Was festgelegt werden muss, ist nicht die Reaktionszeit, sondern die Störungsklassifizierung. Wird nicht definiert, welche Störung in welche Klasse fällt, wird jede Störung mit höchster Priorität angefordert. Nach Festlegung der Klassen werden Reaktions- und Lösungszeit für jede Klasse getrennt festgeschrieben.

Hinzu kommt die Frage der Messung. Eine Dienstleistungsniveau-Zusage, die nicht messbar ist, bleibt bei Verstoß ohne Sanktion. Wie gemessen wird und nach wessen Aufzeichnung, muss im Vertrag stehen.

Wer den Vertrag verfassen sollte

Alle diese Klauseln erfordern, dass Recht und Ingenieurwesen gemeinsam entscheiden. Der Anwalt kann das Abnahmekriterium nicht allein formulieren, weil er nicht weiß, was testbar ist. Der Ingenieur kann die Übertragung geistiger Eigentumsrechte nicht allein formulieren.

Die Partei, die ohne technisches Team in die Vertragsverhandlung geht, akzeptiert am Ende Klauseln, die sich später nicht umsetzen lassen. Eine nicht umsetzbare Klausel verhält sich im Streitfall so, als hätte es sie nie gegeben.