Vertraglicher Umgang mit Fehlern

Software hat üblicherweise Fehler - auch produktionsreife Software am Stand der Technik muss nicht völlig fehlerfrei sein. Fehler sind Mängel und gehören daher allesamt im Rahmen der Gewährleistung oder Wartung behoben. Doch welche zuerst? Was, wenn ein Fehler sich nicht beheben lässt. Und wie Fehler von Verbesserungswünschen abgrenzen? Das (und viel mehr) fehlt üblicherweise in Wartungsverträgen.

Kritische Fehler müssen immer zeitnah gelöst werden. Tatsächlich? Gemäß IEEE¹ ist die Kritikalität (impact bzw. severity) eines Fehlers: "Die aus Sicht des Software-Engineerings stärkste Auswirkung, die der Fehler hat bzw. haben könnte". Auch die ISTQB berücksichtigt die Kritikalität für Anwender nicht.² → Möchte man sicherstellen, dass für die Anwender kritische Fehler zeitnah gelöst werden, so muss man das vertraglich festhalten. Dabei kann man sich einer Kategorisierung der Fehler nach Fehlerfolgen angelehnt an DIN 55350-31 bzw DIN 40080 bedienen und diesbezügliche Service-Level Agreements pönalisiert vereinbaren:³

Kritische Fehler (critical) - das System oder relevante Teile davon sind nicht nutzbar, verstoßen gegen gesetzliche Bestimmungen oder stellen eine Gefahr für Umwelt, Gesundheit oder Leben dar
Hauptfehler A (major) - nicht-kritische Fehler, die wesentliche Funktionen und die Brauchbarkeit der Software stark vermindern
Hauptfehler B (minor) - nicht-kritische Fehler, die die Funktionalität und Brauchbarkeit der Software teilweise beeinträchtigen
Nebenfehler (low) - unbedeutende Fehler ohne wesentliche Folgen, die die Funktionalität und Brauchbarkeit nur gering beeinflussen
Belanglose Fehler (trivial) - Fehler, die die Funktionalität und Brauchbarkeit nicht beeinträchtigen

Üblicherweise kommt es dabei aber zu unangenehmen Nebenerscheinungen: Einerseits werden technische Fehler (z.B. Sicherheitsfehler, technische Schulden) meist als unkritisch bewertet, da die Erfahrung fehlt, welche finanziellen oder auch rechtlichen Folgen derartige Fehler haben. Andererseits kommt es hier oft zu Streit, da es unterschiedliche Sichten bezüglich der Fehlerfolgen gibt und was überhaupt als Fehler zu bewerten ist (siehe letzter Absatz). → Alternativ dazu wird empfohlen alle Fehler gleich zu behandeln: Es wird vereinbart, dass alle Fehler zeitnah behoben werden, welche davon auch sofort als Hotfix in Produktion genommen werden entscheidet der Auftraggeber. Das ist für alle Beteiligten vorteilhafter, da nicht nur Streit und fehlerhafte Einschätzungen vermieden werden, sondern eine rasche Fehlerbehebung den Aufwand für Lokalisation, Behebung und Test deutlich reduziert, den Schaden minimiert und die Zufriedenheit aller verbessert.

Was aber tun, wenn sich ein Fehler nicht oder nicht schnell genug beheben lässt? Das ist selten aber doch der Fall, beispielsweise wenn ein Fehler nicht nachvollziehbar ist, nur sporadisch auftritt oder außerhalb des Einflusses aller Beteiligten liegt. Je nach Fehler könnte das Zuziehen externer Experten, die Beauftragung der Fehlerbehebungen im betroffenen externen System oder der Einsatz eines passenden Workarounds hilfreich sein. → Wie hier eine für beide Seiten geeignete Lösung gefunden und bezahlt werden muss, sollte vertraglich vereinbart werden.

Was, wenn der Fehler in Wahrheit ein Verbesserungswunsch ist? Ein Fehler ist gemäß ISO 9000 eine "Nichterfüllung einer Anforderung", Anforderungen sind "Erfordernisse oder Erwartungen, die festgelegt, üblicherweise vorausgesetzt oder verpflichtend sind".⁴ Das beinhaltet selbstverständlich keine fachlichen Verbesserungswünsche. Aber "üblicherweise vorausgesetzt" werden auch zumeist ungenau definierte Eigenschaften wie Bedienbarkeit oder Performance. Fällt der Fehler/Verbesserungswunsch in so eine ungenau definierte Eigenschaft, sind unterschiedliche Sichtweisen vorprogrammiert. Oft auch bei unabstreitbaren Erwartungen, wie Einhaltung des Standes der Technik oder gesetzlicher Vorgaben.⁵ → Um Streit bei der Einordnung Fehler vs. Verbesserungswunsch zu vermeiden, tut man gut daran, allgemeine Eigenschaften der Software nachprüfbar zu formulieren.

Fazit: Der Umgang mit Fehlern muss vertraglich festgelegt werden, ansonsten kommt es potentiell zu Streit, unbrauchbarer Software oder unerwarteten Kosten.

Weitere typische Mängel von Wartungsverträgen siehe Was fehlt den meisten Wartungsverträgen?

___

1. IEEE 1044-2009 Stanadard Classification for Software Anomalies: "Severity = The highest failure impact that the defect could (or did) cause, as determined by (from the perspective of) the organization responsible for software engineering; Priority = Ranking for processing assigned by the organization responsible for the evaluation, resolution, and closure of the defect relative to other reported defects. ↩

2. International Software Testing Qualifications Board: "Severity = The degree of impact that a defect has on the development or operation of a component or system. ↩

3. siehe DIN 55350-31 bzw. DIN 40080, wobei diese gemäß Fehlerfolgen 3 Fehlerklassen mit 2 Subklassen kennen: Kritische Fehler, Hauptfehler (A und B), Nebenfehler (A und B). Besser geeignet ist hier u.U. die IEEE 1044: "blocking, critical, major, minor, inconsequential" ↩

4. siehe DIN ISO 9000 "Qualitätsmanagementsysteme 3.6.9 (Nichtkonformität = Fehler) bzw. 3.6.4 (Anforderung). ↩

5. Ich hatte sogar einmal ein Streitgespräch mit einem Sachverständigen, der allen Ernstes behauptete, dass eine (Standard)Software nur dann den gesetzlichen Vorgaben der DSGVO entsprechen müsse, wenn diese im Rahmen von Anforderungen (in der Ausschreibung) formuliert wären. ↩