Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware?

Software & Quellcode

Bei Streit über eine individuell entwickelte Software reicht die installierte Anwendung allein häufig nicht aus, um technische Ursachen, Entwicklungsstand und Abweichungen nachvollziehbar zu untersuchen. Entscheidend ist, welche Anforderungen vereinbart oder dokumentiert wurden, welcher konkrete Softwarestand untersucht werden soll und welche technischen Nachweise zu diesem Stand vorliegen.

Untersuchungsgrundlage

Von der technischen Frage zur geeigneten Unterlagenbasis

1 Frage Konkrete technische Streitfrage eingrenzen.

2 Soll & Stand Anforderungen und relevanten Softwarestand bestimmen.

3 Nachweise Tests, Tickets, Historie und Betriebsumgebung zuordnen.

4 Grenzen Fehlende oder widersprüchliche Unterlagen transparent ausweisen.

Nicht jede Untersuchung benötigt jede Unterlage. Entscheidend ist, welche Informationsquelle die konkrete technische Frage trägt.

1. Technische Fragestellung und Unterlagenbedarf bestimmen

Die Unterlagen werden nicht abstrakt gesammelt. Sie müssen zur technischen Frage passen. Soll beispielsweise untersucht werden, ob eine bestimmte Funktion im abgenommenen Softwarestand vorhanden war, sind andere Nachweise erforderlich als bei der Frage nach Codequalität, Performance oder einer später eingetretenen Regression.

Eine erste Sichtung sollte deshalb klären, welcher technische Zustand untersucht werden soll, für welchen Zeitpunkt die Aussage gelten soll und welche konkrete Eigenschaft Gegenstand der Prüfung ist.

2. Anforderungen und dokumentierten Soll-Zustand sichern

Für einen technischen Soll-Ist-Vergleich muss nachvollziehbar sein, welche technischen Funktionen oder Eigenschaften als Untersuchungsmaßstab herangezogen werden sollen. Dafür können insbesondere folgende Unterlagen relevant sein:

• Lastenheft und Pflichtenheft,
• technische Leistungsbeschreibungen,
• User Stories und Akzeptanzkriterien,
• Änderungsanforderungen und Change Requests,
• Abnahme- und Testkriterien,
• technische Anlagen zu Angeboten oder Verträgen,
• Protokolle, in denen technische Anforderungen konkretisiert oder geändert wurden.

3. Software- und Quellcodestand eindeutig identifizieren

Eine technische Prüfung benötigt einen reproduzierbar bestimmbaren Untersuchungsgegenstand. Bei versionsverwalteter Software sollte daher möglichst nicht nur ein Ordner mit Quellcodedateien übergeben werden.

Hilfreich sind insbesondere:

• Repository oder dokumentierter Repository-Export,
• konkrete Commit- oder Revisionskennung,
• relevante Branch- und Tag-Bezeichnungen,
• Release-Bezeichnung und Build-Artefakt,
• Build-Anleitung und verwendete Tool-Versionen,
• Abhängigkeitsdateien und Lock-Dateien,
• Konfigurationsdateien, soweit sie den untersuchten Zustand beeinflussen.

Der Versionsbezug ist entscheidend, weil unterschiedliche Commits oder Releases unterschiedliche technische Eigenschaften besitzen können. Die offizielle Git-Dokumentation beschreibt Revisionen als Bezeichner für konkrete Commit-Objekte beziehungsweise für Mengen erreichbarer Commits.

4. Fehler-, Test- und Reproduktionsnachweise einordnen

Wird ein konkreter Fehler behauptet, muss nachvollzogen werden können, unter welchen Bedingungen er aufgetreten ist. Besonders nützlich sind:

• Ticket oder Fehlerbericht mit Zeitpunkt,
• genaue Reproduktionsschritte,
• erwartetes und beobachtetes Verhalten,
• automatisierte oder manuelle Testfälle,
• Testberichte und CI-Ergebnisse,
• Screenshots oder Bildschirmaufzeichnungen mit nachvollziehbarem Kontext,
• Logdateien und Fehlermeldungen,
• Information darüber, in welcher Softwareversion der Fehler beobachtet wurde.

Ein Fehlerbericht ohne Versions- und Umgebungsbezug kann die technische Einordnung erheblich einschränken.

5. Projekt-, Änderungshistorie und Systemumgebung erfassen

Bei der Rekonstruktion eines Entwicklungsverlaufs können technische Änderungen und ihre zeitliche Reihenfolge von Bedeutung sein.

Je nach Fragestellung können deshalb zusätzlich folgende Artefakte relevant sein:

• Commit-Historie,
• Pull- oder Merge-Requests,
• Issue- und Ticketsystem,
• Review-Kommentare,
• Release Notes,
• CI/CD-Protokolle,
• technische Besprechungs- und Entscheidungsprotokolle.

Diese Unterlagen können helfen, eine technische Änderung mit einem bestimmten Entwicklungsstand und einem dokumentierten Ereignis in Beziehung zu setzen.

System- und Betriebsumgebung gehören zur Untersuchungsgrundlage

Das Verhalten einer Anwendung kann von ihrer Umgebung abhängen. Eine reproduzierbare Prüfung benötigt deshalb gegebenenfalls auch Angaben zur tatsächlichen Betriebs- oder Testumgebung.

• Betriebssystem und Laufzeitumgebung,
• Datenbank- und Middleware-Versionen,
• relevante Infrastrukturkomponenten,
• Container- oder Deployment-Konfiguration,
• Schnittstellen und angebundene Fremdsysteme,
• Datenbank- oder Schemazustand,
• Konfigurationsparameter, soweit sie das untersuchte Verhalten beeinflussen.

6. Übergabe und Belastbarkeit der Unterlagen dokumentieren

Für die technische Nachvollziehbarkeit sollte dokumentiert werden, welche Dateien und Daten tatsächlich untersucht wurden. Bei digitalen Artefakten können Dateilisten, Zeitpunkte und kryptografische Hashwerte eingesetzt werden, um den übernommenen Datenstand eindeutig zu dokumentieren.

Dadurch wird später nachvollziehbar, ob sich die untersuchte Datei oder der untersuchte Datenbestand von einer anderen Fassung unterscheidet.

Der Vergleich kryptografischer Hashwerte kann die Integritätsprüfung zweier Datenstände stützen. Ein Hashwert belegt für sich allein weder den Zeitpunkt der Entstehung noch die Person, die einen Inhalt erstellt hat. Repository-Metadaten und Übergabeprotokolle sind deshalb getrennt zu prüfen.

Was leisten Hashwerte bei der Dokumentation einer Übergabe?

Kryptografische Hashwerte können dabei helfen, einen übernommenen Datei- oder Datenstand eindeutig wiederzuerkennen und spätere Integritätsvergleiche zu unterstützen.

Ein Hashwert belegt für sich allein jedoch weder den Entstehungszeitpunkt noch die Person, die einen Inhalt erstellt hat. Versionshistorie, Repository-Metadaten und Übergabedokumentation sind davon getrennt zu betrachten.

Unterlagenmatrix für die Erstprüfung

Die Unterlagen sollten der jeweiligen Prüffrage zugeordnet werden. Eine kurze Matrix kann je Artefakt die Bezeichnung, Herkunft, Version, Zeitraum, Integritätsangabe, konkrete Beweisfunktion und bekannte Lücken enthalten. So bleibt erkennbar, welche Aussage ein Dokument tragen kann und welche zusätzliche Untersuchung nötig ist.

• Exportfunktion vorhanden? Anforderungsfassung, betroffener Release, Build-Artefakt und reproduzierbarer Funktionstest.
• Fehler seit einem Update? zwei identifizierte Stände, Changelog, Testdaten, Konfiguration und Fehlerprotokoll.
• Herkunft einer Implementierung? vollständige erreichbare Repository-Historie, externe Vergleichsbasis und dokumentierte Gegenhypothesen.

Welche Unterlagen reichen für eine erste Prüfung?

Für eine erste fachliche Einschätzung muss nicht zwingend bereits der vollständige Projektbestand übermittelt werden. Ein sinnvolles Startpaket kann beispielsweise enthalten:

• konkrete technische Fragestellung,
• kurze Projekt- und Systembeschreibung,
• relevante Anforderungsunterlagen,
• Beschreibung des beanstandeten technischen Problems,
• Angabe des betroffenen Software- oder Release-Stands,
• Übersicht der vorhandenen Quellcode-, Ticket-, Test- und Protokolldaten.

Auf dieser Grundlage lässt sich regelmäßig zunächst bestimmen, welche weiteren technischen Unterlagen für eine belastbare Untersuchung erforderlich wären.

Eine unvollständige Unterlagenlage begrenzt die Aussage

Fehlende Unterlagen führen nicht automatisch dazu, dass keine technische Aussage möglich ist. Sie können aber die Reichweite der Aussage begrenzen.

Fehlt beispielsweise der ursprünglich ausgelieferte Softwarestand, kann eine spätere Codefassung nicht ohne Weiteres als identischer Untersuchungsgegenstand behandelt werden. Fehlen reproduzierbare Fehlerdaten, kann gegebenenfalls nur die vorhandene Dokumentationslage, nicht aber das behauptete Laufzeitverhalten geprüft werden.

Solche Einschränkungen gehören ausdrücklich in die Dokumentation der Untersuchung.

Befund, Interpretation und rechtliche Würdigung trennen

Ein technischer Befund könnte beispielsweise lauten, dass eine bestimmte Funktion in einem untersuchten Commit nicht vorhanden ist oder dass ein dokumentierter Test unter festgelegten Bedingungen fehlschlägt.

Die fachliche Interpretation kann anschließend einordnen, welche technische Bedeutung dieser Befund für die konkrete Untersuchungsfrage besitzt.

Prüffragen

Reicht die Unterlagenlage für die konkrete Untersuchung?

• Ist die technische Fragestellung klar bestimmt?
• Sind Anforderungen oder andere Soll-Unterlagen verfügbar?
• Ist der relevante Software- und Quellcodestand identifizierbar?
• Liegen geeignete Fehler-, Test- oder Reproduktionsnachweise vor?
• Ist die Projekt- und Änderungshistorie soweit erforderlich nachvollziehbar?
• Ist die tatsächliche System- und Betriebsumgebung ausreichend dokumentiert?
• Ist Herkunft und Übergabe der Unterlagen nachvollziehbar?
• Werden fehlende oder widersprüchliche Unterlagen als Aussagegrenze ausgewiesen?

Wie dokumentierte Anforderungen mit einem konkret bestimmten Softwarestand verglichen werden können, erläutert der Beitrag Softwaremängel technisch untersuchen: Soll-Ist-Vergleich .

Welche konkrete Softwarefassung für eine Untersuchung technisch relevant ist, erläutert der Beitrag Welche Softwareversion muss ein Sachverständiger untersuchen? .

Wie ein übergebener Quellcodebestand technisch als Untersuchungsgegenstand dokumentiert werden kann, erläutert der Beitrag Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build .

Welche Herkunftsaussagen sich aus einer Git-Historie ableiten lassen, erläutert Git-Historie und Software-Provenienz.

Weiterführend: Quellen und Methodik des Wissensbereichs .

Eigene Fachliteratur und Veröffentlichungen

Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.

• Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung

Software- oder Quellcode-Gutachten

Wenn ein konkreter Softwarestand, Quellcode, Anforderungen oder technische Abweichungen untersucht werden sollen, kann zunächst die vorhandene Unterlagenlage fachlich eingeordnet werden.

Software-Gutachten ansehen