IT-Projektverlauf rekonstruieren: Tickets, Git-Historie, E-Mails und Protokolle

IT-Projekte & technische Due Diligence

Ein IT-Projektverlauf lässt sich häufig nicht aus einem einzigen Dokument ablesen. Ticketsysteme, Repository-Historien, E-Mails, Besprechungsprotokolle, CI/CD-Daten und weitere Projektartefakte dokumentieren jeweils nur bestimmte Ausschnitte. Eine belastbare Rekonstruktion entsteht deshalb erst durch die quellenbezogene Einordnung, zeitliche Normalisierung und den Vergleich mehrerer voneinander unterscheidbarer Nachweise.

1. Zuerst muss die Rekonstruktionsfrage feststehen

Eine vollständige Projektgeschichte lässt sich in umfangreichen IT-Projekten regelmäßig nicht sinnvoll aus sämtlichen verfügbaren Daten rekonstruieren. Ausgangspunkt sollte deshalb eine konkrete technische Fragestellung sein.

Beispielsweise kann zu klären sein:

• wann eine bestimmte technische Anforderung erstmals dokumentiert wurde,
• wann eine Änderung im Repository technisch sichtbar wird,
• ob ein Fehler vor oder nach einem bestimmten Release dokumentiert wurde,
• welche technischen Ereignisse einem Abnahmezeitpunkt vorausgingen,
• welche Teile eines behaupteten Projektverlaufs durch vorhandene Artefakte gestützt werden.

Erst aus dieser Frage ergibt sich, welche Quellen und Zeiträume tatsächlich untersucht werden müssen.

2. Eine Chronologie benötigt eine Quellenmatrix

Unterschiedliche Systeme verwenden unterschiedliche Ereignis- und Zeitmodelle. Deshalb ist es sinnvoll, die vorhandenen Informationen zunächst in einer strukturierten Quellenmatrix zu erfassen.

Eine solche Matrix kann beispielsweise enthalten:

• Quellentyp und Quellsystem,
• eindeutigen technischen Identifikator,
• dokumentiertes Ereignis,
• ursprünglichen Zeitwert,
• Zeitzone oder UTC-Offset,
• normalisierten Vergleichszeitpunkt,
• dokumentierten Akteur oder Account,
• Beziehung zu anderen Artefakten,
• Unsicherheit oder Aussagegrenze.

Diese Struktur ist eine sachverständige Untersuchungsmethodik. Sie ersetzt nicht die Prüfung, was die jeweilige Quelle technisch tatsächlich aussagt.

3. Ticketdaten dokumentieren unterschiedliche Ereignisse

Ein Ticket kann mehrere zeitlich verschiedene Informationen enthalten: Erstellung, Bearbeitung, Statuswechsel, Kommentare, Zuordnungen oder spätere Änderungen.

Ein Feld updated bedeutet deshalb nicht automatisch, dass die im Ticket beschriebene technische Änderung genau zu diesem Zeitpunkt implementiert wurde. Ebenso kann ein Erstellungszeitpunkt nur dokumentieren, wann ein Vorgang im Ticketsystem angelegt wurde.

Für eine Rekonstruktion sollte daher möglichst zwischen aktuellem Ticketzustand und vorhandener Änderungshistorie oder Audit-Historie unterschieden werden.

4. Git-Historie dokumentiert versionierte Repository-Ereignisse

Die Git-Historie kann versionierte Änderungen und deren Beziehungen technisch nachvollziehbar machen. Mit git log können Commit-Historien dargestellt werden.

Wichtig ist jedoch, dass ein Git-Commit unterschiedliche Zeitinformationen enthalten kann. Die offiziellen Pretty-Formats unterscheiden unter anderem zwischen Author Date und Committer Date.

Für eine Projektchronologie sollte deshalb dokumentiert werden, welche dieser Zeitinformationen verwendet wird. Eine einzelne Git-Datumsangabe sollte nicht ohne diese Einordnung als allgemeiner Zeitpunkt der fachlichen Entstehung einer Änderung behandelt werden.

5. Author Date und Committer Date sind nicht dasselbe

Git kann den Zeitpunkt, der dem Autor einer Änderung zugeordnet ist, getrennt von dem Zeitpunkt speichern, zu dem der Commit durch den Committer in seiner konkreten Form erstellt wurde.

Die Git-Dokumentation stellt hierfür unter anderem die Formatangaben %aI für ein Author-Datum und %cI für ein Committer-Datum im strikten ISO-8601-Format bereit.

Für die fachliche Interpretation ist daher relevant, ob beispielsweise ein ursprünglicher Änderungszeitpunkt, ein späteres Rebasing, eine Übernahme oder ein anderer Repository-Vorgang betrachtet wird.

6. Commit-Inhalte und Unterschiede müssen getrennt von Zeitdaten geprüft werden

Ein Zeitstempel allein beschreibt nicht, welche technische Änderung vorgenommen wurde. Für die inhaltliche Untersuchung können deshalb beispielsweise git show und git diff relevant sein.

Dadurch lässt sich die zeitliche Zuordnung mit der tatsächlich versionierten Änderung verbinden. Zusätzlich können vollständige Commit- beziehungsweise Objekt-IDs dokumentiert werden, damit der untersuchte Repository-Zustand eindeutig referenziert ist.

Die Aussage bleibt dabei auf den versionierten Repository-Inhalt begrenzt. Ein Commit beweist für sich genommen weder die tatsächliche Auslieferung noch den Zeitpunkt eines produktiven Deployments.

7. E-Mail-Header enthalten mehrere Arten von Zeit- und Identifikationsdaten

Bei E-Mails ist zunächst zu unterscheiden, welche Information aus welchem Header-Feld stammt. RFC 5322 beschreibt unter anderem das Date:-Feld sowie das Message-ID:-Feld.

Das Date:-Feld beschreibt den im Nachrichtenkopf angegebenen Ursprungszeitpunkt der Nachricht. Es ist nicht automatisch mit dem Empfangszeitpunkt beim Empfänger gleichzusetzen.

Eine Message-ID kann als technischer Nachrichtenidentifikator für die Zuordnung von Nachrichten und Antworten nützlich sein. Sie ist für sich genommen jedoch kein Nachweis der Echtheit oder des tatsächlichen Empfangs einer Nachricht.

8. Received-Felder können Transportstationen dokumentieren

Beim SMTP-Transport können Received:-Trace-Felder entstehen. RFC 5321 beschreibt diese Felder im Zusammenhang mit der Weiterleitung einer Nachricht zwischen SMTP-Systemen.

Solche Header können zusätzliche technische Hinweise auf Transportstationen und Zeitangaben liefern. Ihre Aussagekraft hängt jedoch vom erhaltenen vollständigen Header, den beteiligten Systemen und der konkreten Überlieferung ab.

Ein einfacher Ausdruck oder ein Screenshot einer E-Mail kann deshalb eine geringere technische Rekonstruktionsgrundlage bieten als eine Nachricht mit erhaltenen Original-Headern.

9. Zeitzonen müssen vor einem Zeitvergleich berücksichtigt werden

Zeitangaben aus unterschiedlichen Quellen können in verschiedenen Zeitzonen, mit unterschiedlichen UTC-Offsets oder in UTC gespeichert sein. RFC 3339 beschreibt ein standardisiertes Datums- und Zeitformat einschließlich Zeitzonenbezug.

Für eine Vergleichschronologie ist es sinnvoll, den ursprünglichen Zeitwert unverändert zu dokumentieren und zusätzlich einen normalisierten Vergleichswert zu verwenden.

Die Normalisierung verändert dabei nicht die ursprüngliche Quelle. Sie dient ausschließlich dazu, Zeitangaben aus verschiedenen Systemen konsistent gegenüberzustellen.

10. Besprechungsprotokolle dokumentieren einen anderen Quellentyp

Ein Besprechungs- oder Entscheidungsprotokoll unterscheidet sich technisch von einem automatisiert erzeugten Repository- oder Systemereignis. Es dokumentiert menschlich festgehaltene Aussagen, Beschlüsse oder Beobachtungen.

Dabei sollte unterschieden werden zwischen:

• Datum der beschriebenen Besprechung,
• Erstellungszeitpunkt des Dokuments,
• späteren Bearbeitungen,
• freigegebener und nicht freigegebener Fassung,
• dokumentierter Aussage und technisch nachweisbarem Systemereignis.

Ein Protokoll kann daher für die Rekonstruktion sehr relevant sein, besitzt aber eine andere Aussagequalität als beispielsweise ein identifizierter Git-Commit.

11. Quellen sollten miteinander korreliert werden

Besonders belastbar wird eine Rekonstruktion, wenn voneinander unterscheidbare Quellen konsistente Bezüge zeigen.

Beispielsweise kann ein Ticket eine Fehlernummer enthalten, die auch in einer Commit-Nachricht erscheint. Ein Release-Protokoll kann anschließend den entsprechenden Softwarestand nennen, während ein CI/CD-Protokoll einen Build zu diesem Stand dokumentiert.

Eine solche Übereinstimmung erhöht die technische Nachvollziehbarkeit der Zuordnung. Sie darf jedoch nicht dazu führen, unterschiedliche Quellen ungeprüft als voneinander unabhängig zu behandeln, wenn sie tatsächlich nur dieselbe ursprüngliche Information wiederholen.

12. Fehlende und widersprüchliche Quellen gehören in die Rekonstruktion

Projektunterlagen sind häufig unvollständig. Tickets können gelöscht oder exportiert worden sein, Repository-Historien können nur teilweise vorliegen, E-Mail-Header können fehlen und Protokolle können erst später erstellt worden sein.

Ebenso können sich Zeitangaben widersprechen. In solchen Fällen sollte nicht künstlich eine scheinbar eindeutige Chronologie erzeugt werden.

Stattdessen ist zu dokumentieren, welche zeitlichen Zuordnungen gesichert, welche nur plausibel und welche mit dem verfügbaren Material nicht hinreichend auflösbar sind.

13. Chronologische Reihenfolge ist nicht gleich Kausalität

Dass Ereignis A zeitlich vor Ereignis B liegt, beweist nicht, dass A die Ursache von B war.

Für eine technische Ursachenanalyse müssen zusätzlich technische Wirkzusammenhänge, Systemzustände, Änderungen und alternative Erklärungen untersucht werden.

14. Technischer Projektverlauf und Verantwortlichkeit sind zu trennen

Ein technischer Befund kann beispielsweise lauten, dass eine Anforderung am 4. März in einem Ticket dokumentiert, am 8. März in einem Commit technisch umgesetzt und am 10. März in einem Build-Protokoll einem Release zugeordnet wurde.

Ebenso kann festgestellt werden, dass eine behauptete frühere Umsetzung in den untersuchten technischen Quellen nicht nachvollzogen werden konnte.

15. Wie sollte die Rekonstruktion dokumentiert werden?

Eine nachvollziehbare Dokumentation kann für jedes relevante Ereignis beispielsweise folgende Angaben enthalten:

• fortlaufende Ereignisnummer,
• Quellsystem,
• Originalreferenz wie Ticket-ID, Commit-ID oder Message-ID,
• Originalzeitstempel,
• Zeitzone oder UTC-Offset,
• normalisierten Vergleichszeitpunkt,
• kurze Beschreibung des tatsächlich belegten Ereignisses,
• Verknüpfung zu weiteren Quellen,
• technische Aussagegrenze.

Bei exportierten Dateien, Archiven oder anderen übernommenen Artefakten können zusätzlich kryptografische Hashwerte als technische Identifikatoren der konkret untersuchten Dateien dokumentiert werden.

Weiterführende Beiträge

Welche Unterlagen für eine technische Untersuchung eines Softwareprojekts relevant sein können, erläutert Welche Unterlagen benötigt ein IT-Sachverständiger bei Streit über Individualsoftware? .

Wie Repository, Commit und Working Tree als Untersuchungsgegenstand dokumentiert werden, erläutert Quellcode als Untersuchungsgegenstand: Repository, Commit, Branch und Build .

Welche Teile einer Projektfrage technisch beantwortbar sind, erläutert Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

IT-Projektverlauf technisch untersuchen

Wenn ein Projektverlauf aus Tickets, Repository-Historie, E-Mails, Protokollen oder weiteren technischen Artefakten rekonstruiert werden soll, können zunächst Fragestellung, Zeitraum, Quellensysteme und Aussagegrenzen eingegrenzt werden.

IT-Projektgutachten ansehen