1.
Einleitung ^
[1]
Die Entwicklung von Software ist eine sehr komplexe Angelegenheit: nicht nur dass es eine Vielfalt von möglichen Fehlern, die der Entwickler machen kann, gibt, sondern auch die Definition dessen, was zu tun ist, also die Erstellung der Spezifikation, ist problematisch. Oftmals wird nicht das definiert, was der Kunde eigentlich möchte, auch weil der Kunde dies nicht entsprechend artikulieren konnte. Es ist also offensichtlich, dass Software-Mängel leicht passieren können und auch, dass es oft gar nicht so eindeutig ist, ob ein gewisser vom Kunden unerwünschter Zustand, ein Mangel ist oder nicht. Zwar wird eine Abweichung zur Spezifikation als Mangel zu werten sein, nur ist diese selten so eindeutig um sich darauf berufen zu können.
[2]
So schnell wie Fehler bei der Entwicklung von Software passieren können, so schnell können sie oft auch behoben werden, da Änderungen rasch möglich sind. Teilweise ist oft nur ein Vorzeichen im Quellcode zu korrigieren und das Problem ist beseitigt. Damit dies aber möglich ist, müssen die Mängel gut dokumentiert sein. Es muss für den Entwickler klar sein, wie die Software reagiert und wie sie eigentlich reagieren sollte.
[3]
Aber auch wenn die Mängel trotz Mängelrüge nicht behoben werden können und es in Folge eventuell zu einer (gerichtlichen) Auseinandersetzung zwischen Kunde und Lieferant kommt, ist es wichtig, dass die Mängel genau dokumentiert sind, um diese dann auch beweisen zu können. Dass dies zeitnahe passiert, ist gerade bei Software-Mängeln sehr wichtig.
[4]
Aus Erfahrung des Autors finden Befundaufnahmen im Zuge eines Zivilprozesses oft erst Jahre später statt und die Software ist dann in dem ursprünglichen Zustand eventuell gar nicht mehr verfügbar, weil vielleicht schon neue Versionen eingespielt worden sind oder diese auf der aktuellen Hardware gar nicht mehr lauffähig ist. Auch sind Mitarbeiter, die mit den Problemen vertraut waren, eventuell nicht mehr greifbar.
[5]
Sinnvoll ist daher unbedingt eine zeitnahe, verständliche und vollständige Dokumentation der Mängel, die dem Lieferanten die Problematik klar macht. Häufig wird dieser dann die Verantwortung erkennen und den Mangel rasch erledigen oder aber die Situation klären (etwa weil das Verhalten tatsächlich so beabsichtigt war).
[6]
Angemerkt sei, dass für den Fall, dass eine gerichtliche Auseinandersetzung zu erwarten ist, auch die Dokumentation der Software-Mängel gleich in Form einer gerichtlichen Beweissicherung über Antrag beim Bezirksgericht vorgenommen werden kann, bzw. vielleicht sogar soll.
2.
Rahmenbedingungen ^
[7]
Idealerweise kann der Anwender selbst die Mängel genau dokumentieren, oft scheitert dies aber am nötigen Fachwissen. In diesem Falle ist es sinnvoll einen sachverständigen Dritten hinzuzuziehen. Bei einem derartigen Termin wird es sinnvoll sein, wenn der Lieferant auch anwesend ist, damit etwaige Missverständnisse rasch geklärt werden können. Ohnehin muss dem Lieferanten zugestanden werden, dass er sich vor Beginn der Mängelbehebung vor Ort ein Bild über die vorhandenen Mängel machen kann1.
[8]
In so einem Fall ist ein Termin zu suchen, zu dem die Beteiligten Zeit haben, d.h. es ist zwar wichtig, dass die Anlage im Betrieb ist, es sollte aber in Randstunden geschehen. Idealerweise kann der Betrieb auch noch im Rahmen einer Echtsituation beobachtet werden.
[9]
In einem ersten Schritt sind dabei einmal die wichtigsten Eckpunkte zu klären, etwa ob eine Dokumentation vorhanden ist, welche Hardware eingesetzt wird (auch im Vergleich zu den Hardware-Empfehlungen des Lieferanten) und welche Version eingespielt ist. Auch sind etwaige externe Störungen, wie etwa Viren, auszuschließen. Wesentlich ist aber auch zu klären, was eigentlich hätte geliefert werden sollen.
[10]
Folgende Punkte sind dabei besonders zu beachten:
- Softwaredokumentation begutachten: in welcher Form und in welchem Umfang ist sie vorhanden? Welche Themen werden durch sie abgedeckt? Falls nicht alle Leistungsmerkmale der Software durch die Dokumentation abgedeckt sind, so ist festzuhalten, ob es sich dabei eventuell sogar um elementare oder zumindest wesentliche Leistungsmerkmale handelt2.
- Sind aktuelle Programmänderungen auch in die Dokumentation eingearbeitet?
- Welche Hardware wird eingesetzt, diese vergleichen mit den Hardware-Empfehlungen des Lieferanten.
- Welche Version der Software wird eingesetzt, ist dies das aktuellste Update?
- Mit welcher Kontinuität sind Updates der Software erschienen und wurden diese eingespielt?
- Liegt der Quellcode der Software vor?
- Hat der Anwender selbst Eingriffe vorgenommen, etwa durch Eingriffe in den Binärcode oder aber schreibende Zugriffe direkt auf die Datenbank (an der Software vorbei)?
- Welche Parameter der Software sind gesetzt und wurden hier etwa Auslieferungsstandards durch den Anwender umgesetzt?
- Ist aktueller Virenschutz vorhanden?
- Was wurde vereinbart? Liegt eine Spezifikation, bzw. ein detaillierter Projekt- und Zeitplan vor?
- Decken sich Spezifikation und Umsetzung?
3.
Mängel ^
[11]
Der wesentlichste Aspekt ist die Dokumentation etwaiger Mängel. Es muss dabei vor allem auf die Hinweise des Anwenders eingegangen werden, der die ihm aufgefallenen Probleme nennen muss. Diese müssen genau dokumentiert werden, am besten mit Hilfe von Screenshots und Ausdrucken, wobei das tatsächliche Verhalten dem erwarteten Verhalten (Sollbeschaffenheit) gegenüber gestellt werden sollte.
[12]
Wesentlich ist dabei die Reproduzierbarkeit, das heißt es sollte genau dokumentiert werden, wann dieses Verhalten auftritt. Wichtig ist dabei etwa festzuhalten, ob das Verhalten immer nachvollziehbar ist, oder aber nur bei gewissen Eingabedaten oder Datenzuständen. Ist das Verhalten nicht beliebig reproduzierbar, so muss untersucht werden, wie es reproduzierbar gemacht werden kann. Gelingt dies nicht, so ist auch dies zu dokumentieren.
[13]
Festzuhalten ist, dass meist der Anwender nicht in der Lage ist, alle Probleme aufzuzählen, weil häufig nur Aussagen der Art «nichts geht» oder «es gibt nur Probleme» getroffen werden, nicht aber detailliert die Punkte aufgezählt werden. Dabei ist es am besten mögliche Defizite an Hand eines Kataloges zu erarbeiten. Etwa haben Rechtsprechung und Literatur vor allem folgende Defizite und Unzulänglichkeiten als Beeinträchtigung des gewöhnlichen Gebrauchs eingestuft: Dokumentationsdefizite (auf die bereits im vorhergehenden Abschnitt eingegangen wurden), Funktionsdefizite, Eigenschaftsdefizite, Kapazitätsdefizite, Verwendungsbeschränkungen und Funktionsmängel3.
- Funktions- und Eigenschaftsdefizite liegen vor, wenn ein (nach dem Verwendungszweck) für erforderlich zu erachtendes Ausstattungsmerkmal (Funktionen oder Eigenschaften) nicht in angemessenem bzw. ausreichendem Umfang vorhanden ist oder völlig fehlt.
- Kapazitätsdefizite liegen vor, wenn die Bedienerführung und der Bedienerkomfort unzumutbar erscheinen und eine angemessene Dimensionierung und Auswahl von Systembestandteilen die Einschränkung verhindert hätten.
- Verwendungsbeschränkungen liegen vor, wenn durch eingebaute Softwaresperren die Verwendung der Software verhindert oder eingeschränkt werden sollte.
- Funktionsmängel liegen vor, wenn Systemfunktionen unkorrekt ausgeführt werden, bzw. teilweise oder vollständig ausfallen. Im Gegensatz zu den Funktionsdefiziten besteht hier prinzipiell Einigkeit zwischen den Parteien, dass die betroffenen Funktionalitäten vorhanden zu sein haben, problematisch ist allerdings ihre einwandfreie Ausführung.
[14]
Bei diesen Mängeln kann dabei unterschieden werden, zwischen:
- Systemwidriger Programmabbruch
- Systemträgheit: etwa inakzeptable Reaktionszeiten
- Ausgabefehler, etwa Kalkulations- bzw. Darstellungsfehler
[15]
Eine nützliche Schablone zur Erfassung von Indikatoren für die Fehlerbewertung wird dabei etwa von Lenzer4 angeboten. Beispiele dafür sind die Auftrittshäufigkeit und Belastwirkung der Fehlreaktion, der Anteil der funktionalen Systembeeinträchtigung oder die Zumutbarkeit, die betreffenden Fehlreaktionen zu umgehen.
4.
Weitere Aspekte ^
[16]
Neben der Aufnahme der etwaigen Mängel ist es auch wichtig weitere Aspekte zu beachten. Etwa könnten vorhandene Probleme, wie Programmfehler, dazu geführt haben, dass Dateninkonsistenzen aufgetreten sind. Es ist daher sinnvoll Prüfprogramme auf Datenkonsistenz auszuführen um dies zu untersuchen. Falls derartige Prüfprogramme nicht von der Software angeboten werden, müssen geeignete Prüfroutinen, idealerweise unter Beiziehung des Lieferanten, überlegt werden.
[17]
Insbesondere im Falle von Dateninkonsistenzen muss überlegt werden, wie und mit welchem Aufwand diese repariert werden können. Aber auch sonst muss bei Vorliegen von Mängeln geprüft werden, ob Schäden entstanden sind. Etwa kann es sein, dass Stilstandzeiten aufgetreten sind. Diese sollten möglichst genau dokumentiert werden.
[18]
Software ist sehr schnelllebig, meist sind innerhalb von Tagen neue Versionen verfügbar, bei denen die Mängel behoben sind. Das ist zwar prinzipiell positiv, dennoch kann es Situationen geben in denen es wichtig ist zu untersuchen, ob einmal ein Mangel vorgelegen ist, etwa um die Ursache für Dateninkonsistenzen zu klären. Alleine aus diesem Grund ist eine Sicherung wesentlich, aber mit ihr können auch etwaige andere Störquellen nachträglich untersucht werden, etwa weil in einem Verfahren argumentiert wird, dass Fehler im Betriebssystem vorlagen, die in Folge zu den Problemen geführt haben. Auch lässt sich eventuell durch die Sicherung der Zeitpunkt bestimmter Veränderungs- und Zugriffsvorgänge ermitteln, der für die zu ermittelte Höhe eines etwaigen Schadenersatzes relevant sein könnte.
[19]
Zusammenfassend sind daher folgende Aspekte zu beachten:
- Durchführen einer Datenkonsistenzprüfung mit Dokumentation eventueller Inkonsistenzen.
- Dokumentation eventueller Schäden, wie z.B. Stillstandzeiten, möglichst mit Belegen dazu.
- Dokumentation von zusätzlich installierter Software, da eventuelle Wechselwirkungen denkbar wären.
- Durchführen einer Sicherung, die Programm- und Datenbestand umfasst. Dies sollte in Form einer 1:1-Abbildung-Sicherung («image-Sicherung») geschehen, um auch Auswirkungen etwa des Betriebssystems in weiterer Folge analysieren zu können.
5.
Weitere Vorgangsweise ^
[20]
Wesentlich ist, dass nach erfolgter Dokumentation auch die weitere Vorgangsweise abgestimmt wird. Es sollten die Verantwortlichkeiten festgelegt werden, damit geklärt ist, was zu tun ist. Insbesondere sollte entschieden werden, ob mit dem derzeitigen Stand eine Weiterarbeit möglich ist.
[21]
Sollten sich Dateninkonsistenzen oder Mängel herausgestellt haben, so muss geklärt werden, wer diese zu verantworten hat und ob diese behoben werden können. Es sollte klar dokumentiert werden, wie eine Lösung dafür aussieht und bis wann diese zu erfolgen hat.
- 1 Z.B. OGH 22. November 2011, 4Ob159/11b.
- 2 Schedel, Beweisführung in EDV-Sachen, Erich Schmidt Verlag, Berlin, S. 250 (2009)
- 3 Schedel, Beweisführung in EDV-Sachen, Erich Schmidt Verlag, Berlin, S. 134 ff. (2009)
- 4 Lenzer, Begutachtung und rechtliche Bewertung von EDV-Mängeln, Wißner-Verlag, Augsburg, S. 138 f. (2003)
