Wenn Sie ein System ohne Quellcode und ohne Dokumentation übernehmen — Ein praktisches Playbook, um es am Laufen zu halten

„Das Unternehmen, das es gebaut hat, existiert nicht mehr.“ „Die Person, die es gebaut hat, ist gegangen, und wir erreichen sie nicht.“ „Es gibt eine ausführbare Datei und eine Datenbank auf dem Server, aber nirgendwo Quellcode oder Spezifikationen.“ Das ist eine alles andere als seltene Situation bei Beratungen zu KMU-Geschäftssystemen. Und doch läuft das System noch heute, und das Geschäft hängt weiterhin davon ab.

Der schlechteste Schritt in dieser Situation ist, allein deshalb, weil „es sowieso niemand wirklich versteht“, mit Versuch-und-Irrtum-Korrekturen oder beiläufigen Umgebungsänderungen daran herumzustochern. Ein System ohne Quellcode kommt ohne Garantie, dass Sie es reparieren können, falls es kaputtgeht. Andererseits ist es auch verfrüht, sofort zu „da können wir nichts machen, wir müssen alles neu bauen“ zu springen. Es gibt Wege, eine Spezifikation auch ohne Dokumentation zu rekonstruieren, und es gibt Fälle, in denen sich das Innenleben auch ohne Quellcode noch lesen lässt. Dieser Artikel legt in der Reihenfolge, in der Sie tatsächlich vorgehen würden, die Schritte dar, um von völligem Nichts zu einer funktionierenden Betriebs- und Wartungseinrichtung zu gelangen.

1. Das Ergebnis zuerst

• Das Erste, was zu tun ist, ist nicht Änderung — es ist die Bewahrung des aktuellen Zustands. Die laufende Produktionsumgebung selbst ist Ihr wichtigstes Asset. Erstellen Sie ein Disk-Image-Backup (z. B. durch Umwandlung in eine virtuelle Maschine mit Disk2vhd) und ein Datenbank-Backup, und bestätigen Sie, dass Sie tatsächlich davon wiederherstellen können, bevor Sie weitermachen.¹
• Sie können die Spezifikation auch ohne Dokumentation rekonstruieren. Die Hauptmaterialien sind Interviews mit den Nutzern des Systems, die Bildschirme und Berichte, das Datenbankschema, die Protokolle und die Beobachtung des tatsächlichen Verhaltens mit Process Monitor.²
• Wie gut sich der Quellcode wiederherstellen lässt, hängt stark vom Technologie-Stack ab. Für .NET kommen Decompiler wie ILSpy recht weit; bei nativem Code wie VB6 oder C++ sollten Sie realistischerweise nicht damit rechnen, viel wiederherzustellen.³⁴
• Dekompilieren hat rechtliche Aspekte. Artikel 30-4 des Urheberrechtsgesetzes wird so verstanden, dass er die Nutzung zu Untersuchungs- und Analysezwecken grundsätzlich erlaubt, doch die Prüfung des Vertrags (der Lizenzbedingungen) ist unerlässlich.⁵
• Warten Sie nicht, bis Sie „alles vollständig verstehen“. Priorisieren Sie das Verständnis der Teile, bei denen ein Ausfall das Geschäft stoppen würde, und der Teile, die wahrscheinlich bald geändert werden müssen, und nehmen Sie Änderungen klein, einzeln und umkehrbar vor.
• Ein Geschäftsbesorgungsvertrag ist das Grundmodell für die Wartung. Für die Untersuchung eines Systems mit unbekanntem Innenleben lässt sich keine Erfolgshaftung (ein Werkvertrag) zusagen. Teilen Sie den Vertrag in eine Untersuchungsphase und eine Änderungsphase.

2. Warum entsteht eine „Nichts vorhanden“-Situation?

Bevor Sie über die Reaktion nachdenken, hilft es herauszufinden, in welches Muster Ihre eigene Situation fällt — das gibt Ihnen ein Gefühl dafür, welche Hinweise noch vorhanden sein könnten.

Das letzte Muster wird leicht übersehen, muss aber in der Praxis genauso behandelt werden wie „es gibt keine Quelle“. Ein klassischer Fehlschlag ist, eine alte Kopie der Quelle als maßgeblich zu behandeln und sie zu ändern, nur um festzustellen, dass die Produktions-ausführbare-Datei in Wirklichkeit Jahre an Korrekturen enthielt, die die Quelle nie gesehen hat. Selbst wenn Sie einen Quellbaum finden, trauen Sie ihm nicht, bevor Sie ihn gebaut und das Ergebnis mit der Produktions-ausführbaren-Datei abgeglichen haben.

Unabhängig davon, in welchem Muster Sie sich befinden, lohnt es sich, zuerst nach Vertrag, Lieferschein und Abnahmeprotokoll zu suchen. Ist dort das Eigentum am Urheberrecht oder eine Pflicht zur Quellcode-Lieferung festgelegt, wird das zur Grundlage für jede folgende Verhandlung oder rechtliche Analyse.

3. Was in der ersten Woche zu tun ist — Bewahrung des aktuellen Zustands und Bestandsaufnahme

3.1 Alle Änderungen einfrieren

Bis die Untersuchung abgeschlossen ist, gilt die Regel, die Zielserver und -maschinen unangetastet zu lassen. „Lass uns erstmal nur das OS aktualisieren“ oder „lass uns Dateien aufräumen, die nicht genutzt aussehen“ sind genau die Art von Dingen, die fatal sein können. Ohne Quellcode gibt es keine „einfach reparieren“-Option, falls etwas kaputtgeht. Es lohnt sich auch zu erwägen, das Timing von Updates unter Kontrolle zu bringen, damit automatische Updates (Windows Update, Änderungen im Antivirus-Verhalten) die Umgebung nicht stillschweigend von selbst verändern.

3.2 Backup — die Umgebung selbst als Asset duplizieren

Ein Backup allein auf Dateiebene reicht nicht aus. Bei dieser Art von System können die OS-Einstellungen, die Registrierung, die Runtime und sogar der Bereitstellungsort alle Teil von „warum es funktioniert“ sein, sodass Sie das gesamte Disk-Image bewahren.

In der Praxis ist Sysinternals’ Disk2vhd das dafür am häufigsten genutzte Werkzeug. Es kann ein laufendes System, während es online bleibt, mithilfe eines Volume Shadow Copy (VSS) in eine konsistente VHD/VHDX umwandeln und gibt Ihnen so die Grundlage für eine Verifikationsumgebung, die Sie als Hyper-V-virtuelle-Maschine booten können.¹ Der Vorteil ist, dass Sie damit gleichzeitig das Risiko eines alternden physischen Servers angehen und eine Verifikationsumgebung sichern können (beachten Sie, dass OEM-lizenziertes Windows unter seiner Lizenz möglicherweise nicht in eine virtuelle Umgebung verschoben werden darf, die Prüfung des Lizenztyps ist daher notwendig¹).

Sichern Sie daneben die Datenbank mit der eigenen Standardmethode des DBMS. Und der mit Abstand wichtigste Schritt ist, tatsächlich aus dem Backup wiederherzustellen und zu bestätigen, dass es startet. Ein Backup, das nie einen Wiederherstellungstest durchlaufen hat, ist nur eine Versicherung, von der Sie annehmen, dass Sie sie haben. Da ein wiederhergestelltes Image jedoch weiterhin die Produktionsverbindungseinstellungen und geplanten Aufgaben unverändert enthält, führen Sie den ersten Start immer in einer vom Netzwerk isolierten Umgebung durch (Details in Kapitel 7). Booten Sie es versehentlich noch verbunden, kann das, was als Testumgebung gedacht war, am Ende die Produktionsdatenbank oder deren Integrationspartner aktualisieren.

3.3 Bestandsaufnahme — alles auflisten, was läuft

Zählen Sie als Nächstes die Komponenten des Systems mechanisch auf. Das ist eine Aufgabe für Gründlichkeit, nicht für Intuition.

Können Sie nicht feststellen, wo eine Konfigurationsdatei oder ein Ausgabeziel liegt, ist die Beobachtung des Datei- und Registrierungszugriffs des Prozesses mit Process Monitor der schnellste Weg — die Pfade, die die Anwendung tatsächlich liest und schreibt, erscheinen direkt in der Liste.²

4. Sie können die Spezifikation auch ohne Dokumentation rekonstruieren

Sobald die Bestandsaufnahme Ihnen sagt, „was vorhanden ist“, ist der nächste Schritt, „was es tut“ zu rekonstruieren. Die Materialien dafür sind alle verfügbar.

• Die Nutzer des Systems befragen — Die beste Spezifikation, die Sie finden werden, steckt im Kopf derjenigen, die das System täglich nutzen. Gehen Sie tägliche, monatliche und jährliche Geschäftsprozesse durch und fragen Sie, was auf welchem Bildschirm eingegeben wird und was herauskommt. Insbesondere die jährliche Verarbeitung (Jahresabschluss, Jahresendinventur, Geschäftsjahreswechsel) kann selbst die zuständige Person vergessen haben, und das ist ein häufiger Fehlerpunkt beim ersten Durchlauf nach einer Übergabe.
• Bildschirme und Berichte — Katalogisieren Sie jeden Bildschirm und jeden Bericht mit Screenshots und echten Beispielen. Allein die Entsprechung zwischen Eingabefeldern und Ausgabefeldern offenbart bereits viel vom Skelett der Verarbeitung.
• Datenbankschema und Daten — Tabellendefinitionen, Constraints und die tatsächlichen Daten hinter codierten Werten sind Fossilien von Geschäftsregeln. Eine Beobachtung wie „dieses Flag nimmt nur je drei Werte an“ verrät Ihnen Spezifikationen, die Sie von den Bildschirmen aus nie sehen würden.
• Protokolle und das Ereignisprotokoll — Anwendungsspezifische Protokolle, falls vorhanden, offenbaren den Ablauf der Verarbeitung, und das Windows-Ereignisprotokoll offenbart vergangene Fehlertrends.
• Beobachtung des tatsächlichen Verhaltens — Das Aufzeichnen von Datei-, Registrierungs- und Netzwerkzugriffen mit Process Monitor lässt Sie Ein-/Ausgabe-Beziehungen bestätigen — „dieser Monatsendprozess liest eine CSV aus diesem gemeinsamen Ordner und spricht mit diesem Datenbankserver“ — ganz ohne Quellcode.² Allerdings zeigt Process Monitor nur, wer der Verkehrspartner ist; es zeigt nicht, welche Tabellen wie aktualisiert wurden. Darüber hinaus benötigen Sie die eigenen Tracing-/Auditing-Funktionen des DBMS (etwa SQL Server Extended Events) oder den Vergleich des Datenbankinhalts vor und nach einem Prozesslauf.

Wichtig ist hier, nicht zu versuchen, jede Funktion gleichmäßig zu dokumentieren. Das Ziel ist die Kontinuität des Betriebs, nicht eine Enzyklopädie, priorisieren Sie also „Verarbeitung, die das Geschäft stoppt, wenn sie ausfällt“, „Verarbeitung, die Fehler wirft“ und „Bereiche, die bald geändert werden müssen“, und bauen Sie das Register des Untersuchten von dort aus auf.

5. Was ohne Quellcode technisch möglich ist

Wie weit Sie erwarten können, „das Innenleben zu lesen“, wird größtenteils davon bestimmt, womit das System gebaut wurde. Schätzen Sie den Technologie-Stack anhand der Eigenschaften der ausführbaren Datei und der DLL-Zusammensetzung und richten Sie Ihre Erwartungen entsprechend aus.

Für eine .NET-App, die im regulären IL-Format bereitgestellt wird, ist die Lage recht gut — der aus dem Dekompilieren gewonnene C#-Code ist praktisch genug, um die Verarbeitung zu verstehen. Allerdings gilt, wie die offizielle Dokumentation selbst feststellt: Kommentare, lokale Variablennamen, Leerraum und andere zur Kompilierzeit nicht benötigte Informationen gehen verloren, sodass er als Ressource zum Verständnis des Verhaltens behandelt werden sollte, nicht als Ersatz für den Original-Quellcode.³ Es gibt auch Ausnahmen: Wurde Verschleierung angewendet, steigt die Entschlüsselungsschwierigkeit stark, und ein mit Native AOT veröffentlichtes Binary enthält kein IL, sodass die Annahme „es ist .NET, also lesbar“ nicht zutrifft. Prüfen Sie bei der Einschätzung des Technologie-Stacks auch das Bereitstellungsformat, nicht nur die Entwicklungssprache.

Überlebt eine PDB (Symboldatei) neben der ausführbaren Datei, können Sie möglicherweise Funktionsnamen wiederherstellen, und sogar den Original-Quellcode selbst, falls er eingebettet ist. Was eine PDB kann und nicht kann, behandelt „Was ist eine PDB (Program Database)?“.

Rechtliche Aspekte — vor dem Dekompilieren „zuerst prüfen“

Technisch etwas tun zu können und dazu berechtigt zu sein, sind zwei verschiedene Dinge. Reverse Engineering, einschließlich Dekompilieren, hat urheberrechtliche Aspekte. Gemäß Artikel 30-4 des Urheberrechtsgesetzes (neu eingeführt durch die Novelle von 2018, betreffend „Nutzung, die nicht darauf abzielt, die in einem Werk zum Ausdruck gebrachten Gedanken oder Gefühle zu genießen“) wird Vervielfältigung oder Bearbeitung zum Zweck der Untersuchung und Analyse eines Programms grundsätzlich als erlaubt verstanden, soweit für notwendig befunden. Der Artikel enthält jedoch den Vorbehalt, dass dies „nicht gilt, wo es die Interessen des Urheberrechtsinhabers unangemessen beeinträchtigen würde“, sodass beispielsweise die Nutzung der Analyseergebnisse zum Bau eines Konkurrenzprodukts anders beurteilt werden könnte.⁵

Es gibt auch die separate vertragliche Frage, wie Fälle zu behandeln sind, in denen eine Lizenzvereinbarung für Standardsoftware oder einen Liefergegenstand die Analyse untersagt. Prüfen Sie vor einem solchen Schritt die Lizenzbedingungen der betreffenden Software und den ursprünglichen Entwicklungsvertrag (die Klausel zum Eigentum am Urheberrecht), und ziehen Sie im Zweifel einen Anwalt hinzu. Liegt das Urheberrecht am Liefergegenstand bei Ihrem eigenen Unternehmen, wird diese Frage erheblich einfacher. Wie ein solcher Vertrag zu lesen ist, behandelt auch „Wie sollten Verträge für ausgelagerte Entwicklung und Wartung strukturiert sein?“.

6. Weiterbetrieb, Einkapselung oder Neubau

Sobald Sie das aus der Untersuchung gewonnene Verständnis mit den Realitäten auf der Geschäftsseite kombiniert haben, ist es Zeit, die Richtung festzulegen. Auch hier lautet die Antwort nicht „auf jeden Fall vollständiger Neubau“ oder „auf jeden Fall unverändert lassen“ — klären Sie es mit einer Entscheidungstabelle.

Die entscheidenden Faktoren sind diese vier: verbleibende Nutzungsjahre, Häufigkeit und Konzentration von Änderungswünschen, geschäftliche Auswirkung im Ausfallfall, und der während der Untersuchung gewonnene Verständnisgrad. Ein Wechsel zum vollständigen Neubau mit geringem Verständnisgrad riskiert, die Eigenheiten des alten Systems zu übersehen, „das niemand erklären kann, aber es ist das für das Geschäft korrekte Verhalten“. Auch wenn Sie sich für einen Neubau entscheiden, wird das in Kapitel 4 rekonstruierte Register der Spezifikationen zur Grundlage Ihrer Anforderungsdefinition, sodass die Investition in die Untersuchung nie verschwendet ist. Bei der Migration ist der Standardansatz, das alte und das neue System für einen festgelegten Zeitraum parallel zu betreiben und die Ausgabe (Berichte, Aggregate, Dateien) für dieselbe Eingabe mechanisch abzugleichen.

Für technologiespezifische Entscheidungen zu Weiterbetrieb und Migration behandelt „Weiterbetrieb und Migration von VB6-/Access-Business-Apps“ VB6 und Access im Detail, und „Ein Leitfaden zum Ausstieg aus IE-Modus-abhängigen Systemen“ behandelt interne Websysteme, die vom IE-Modus abhängen.

7. Betrieb und Wartung nach der Übergabe

Lautet die Richtung „vorerst weiterbetreiben“ — was in der Praxis die meisten Fälle beschreibt —, verringert das Festhalten an den folgenden Mustern die Zahl der Zwischenfälle.

• Eine Verifikationsumgebung haben — aber den ersten Start immer vom Netzwerk isolieren — Das Booten des in 3.2 erstellten Disk-Images als virtuelle Maschine gibt Ihnen eine Verifikationsumgebung, die der Konfiguration der Produktion entspricht. Doch dieses Image enthält weiterhin unverändert Produktionsverbindungszeichenfolgen, Anmeldedaten, geplante Aufgaben und Autostart-Dienste. Booten Sie es mit Netzwerkverbindung, riskieren Sie, dass ein nächtlicher Batch zweimal läuft und die Produktionsdatenbank aktualisiert, E-Mails erneut versendet werden oder externe APIs aufgerufen werden. Führen Sie den ersten Start immer mit entfernter virtueller NIC oder in einem isolierten Netzwerk durch, stoppen Sie die geplanten Aufgaben und Autostart-Dienste, schreiben Sie die Verbindungsziele für Tests um, und erlauben Sie erst danach Konnektivität im tatsächlich benötigten Umfang.
• Änderungen einzeln und umkehrbar vornehmen — Ob eine Konfigurationsänderung oder das Anwenden eines Windows-Updates, tun Sie jeweils eine Sache. Bewahren Sie das Image von vor der Änderung, und setzen Sie zurück, falls etwas schiefgeht. Kombinieren Sie das mit einem Protokoll dessen, was geändert wurde (einem Änderungsprotokoll).
• Die Dokumentation als Nebenprodukt der Untersuchung wachsen lassen — Statt ein Projekt zu starten, um die perfekte Spezifikation zu schreiben, fügen Sie dem Register hinzu, was Sie bei jeder Reaktion auf einen Vorfall oder jeder Änderung lernen. Betreiben Sie das ein Jahr lang, und die Dokumentation füllt sich, beginnend mit den für das Geschäft wichtigsten Teilen.
• Überwachung einbauen — Verfügbarkeitsüberwachung, Speicherplatz, Fehlerprotokolle, und das Erkennen, dass „die Datei, die jedes Mal herauskommen sollte, nicht herausgekommen ist“. Auch wenn Sie nicht in die Blackbox hineinsehen können, können Sie ihre Ein- und Ausgaben überwachen.
• Untersuchung und Änderung in separate Verträge aufteilen — Bei der Auslagerung der Wartung können Sie für die Untersuchung eines Systems mit unbekanntem Innenleben keine Erfolgshaftung zusagen, es ist daher gesund, den Vertrag nach Phase aufzuteilen: Untersuchung und Wartung als Geschäftsbesorgung, und einzelne Änderungen, sobald die Spezifikation feststeht, als Werkvertrag (oder eine erfolgsbasierte Geschäftsbesorgung).

8. Zusammenfassung

• Übernehmen Sie ein System ohne Quellcode und ohne Dokumentation, geht die Bewahrung des aktuellen Zustands jeder Änderung voraus. Erstellen Sie ein Disk-Image (z. B. mit Disk2vhd) und ein Datenbank-Backup, und bestätigen Sie, dass Sie tatsächlich davon wiederherstellen können.
• Nehmen Sie eine Bestandsaufnahme der ausführbaren Dateien, Autostart-Einträge, geplanten Aufgaben, Konfiguration, Integrationspartner und Konten vor, um ein vollständiges Bild des Systems zu erhalten.
• Die Spezifikation lässt sich rekonstruieren aus Nutzerinterviews, Bildschirmen, Berichten, dem Datenbankschema, Protokollen und der Beobachtung des tatsächlichen Verhaltens mit Process Monitor. Priorisieren Sie die Teile mit der größten geschäftlichen Auswirkung, nicht jede Funktion.
• Wie gut sich das Innenleben wiederherstellen lässt, hängt vom Technologie-Stack ab. .NET ist über Dekompilieren recht gut lesbar, ist aber kein Ersatz für den Original-Quellcode. Prüfen Sie vor dem Vorgehen den Sinn von Artikel 30-4 des Urheberrechtsgesetzes sowie Lizenzbedingungen und Verträge.
• Entscheiden Sie zwischen Weiterbetrieb, Einkapselung, teilweisem Neubau und vollständigem Neubau anhand verbleibender Nutzungsjahre, Änderungshäufigkeit, geschäftlicher Auswirkung und Verständnisgrad. Für welchen Weg Sie sich auch entscheiden, die während der Untersuchung rekonstruierte Spezifikation wird zu einem Asset.
• In der Betriebsphase ist das Grundmuster eine Verifikationsumgebung, jeweils eine Änderung, ein Änderungsprotokoll, die Überwachung von Ein- und Ausgaben und ein Geschäftsbesorgungsvertrag.

Verwandte Artikel

• Was ist eine PDB (Program Database)? — Debug-Informationen, Symbole und Source Link verstehen
• Ein praktischer Leitfaden zu Process Monitor
• Weiterbetrieb und Migration von VB6-/Access-Business-Apps — Eine Behalten-/Einkapseln-/Ersetzen-Entscheidungstabelle
• Ein Leitfaden zum Ausstieg aus IE-Modus-abhängigen Systemen
• Wie sollten Verträge für ausgelagerte Entwicklung und Wartung strukturiert sein? — Geschäftsbesorgung vs. Werkvertrag, gemäß der IPA-„Muster-Transaktion und -Vertrag“
• Worüber Sie sich vor der Auslagerung der Windows-App-Entwicklung Klarheit verschaffen sollten

Verwandte Beratungsbereiche

Die KomuraSoft LLC (合同会社小村ソフト) übernimmt die Ist-Zustands-Untersuchung von Geschäftssystemen ohne erhaltenen Quellcode oder Dokumentation (Analyse von ausführbaren Dateien, Datenbanken und beobachtetem Verhalten), die Rekonstruktion von Spezifikationen aus Verhalten, die Klärung einer Weiterbetrieb-versus-Migration-Strategie sowie den darauffolgenden Betrieb und die Wartung. Wir begrüßen auch Beratungen, die mit „ich weiß nicht einmal, wo ich anfangen soll“ beginnen.

• Nutzung vorhandener Ressourcen & Migrationsunterstützung
• Änderung & Wartung bestehender Windows-Software
• Fehleranalyse & Ursachenermittlung
• Technische Beratung & Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Kann ich auch bei einem System ohne Quellcode noch Wartung oder Änderungen beauftragen?

Ja, das können Sie. Der Ansatz ändert sich lediglich gegenüber der gewöhnlichen Wartung. Der realistische Weg ist, zunächst die laufende Umgebung zu bewahren und zu sichern, dann eine Untersuchungsphase einzurichten, die die Spezifikation aus Bildschirmen, Berichten, Datenbank, Protokollen und ausführbaren Dateien rekonstruiert, und erst danach innerhalb des in dieser Phase gewonnenen Verständnisses zu Änderungen oder neuer Randentwicklung überzugehen. Da eine Untersuchung ihr Ergebnis nicht im Voraus zusagen kann, wird sie meist als Geschäftsbesorgung statt als Werkvertrag mit Erfolgshaftung abgewickelt.

Ist das Dekompilieren einer ausführbaren Datei (Reverse Engineering) illegal?

Nicht pauschal. Gemäß Artikel 30-4 des japanischen Urheberrechtsgesetzes, neu eingeführt durch die Novelle von 2018, werden Nutzungen, die „nicht darauf abzielen, die in einem Werk zum Ausdruck gebrachten Gedanken oder Gefühle zu genießen“ — wie die Untersuchung und Analyse eines Programms — grundsätzlich als erlaubt verstanden, soweit für notwendig befunden. Der Artikel klammert jedoch Fälle aus, die „die Interessen des Urheberrechtsinhabers unangemessen beeinträchtigen“, und es bleibt die separate Frage, was gilt, wenn eine Lizenzvereinbarung eine Analyse untersagt. Prüfen Sie vor einem solchen Schritt die Lizenzbedingungen und den ursprünglichen Entwicklungsvertrag, und ziehen Sie im Zweifel einen Anwalt oder eine andere Fachperson hinzu.

Das Entwicklungsunternehmen existiert nicht mehr, und wir kommen nicht an den Quellcode. Was sollten wir tun?

Prüfen Sie zunächst frühere Verträge und Liefergegenstände. Legt der Entwicklungsvertrag fest, wem das Urheberrecht gehört und ob eine Quellcode-Lieferung erforderlich war, gibt Ihnen das eine Grundlage, ihn zu erhalten oder zu nutzen. Können Sie jemanden erreichen, der beteiligt war, lohnt es sich zu erkunden, ob diese Person ihn übergibt. In der Praxis ist es aber wichtig, sich nicht in „wir konnten ihn doch nicht bekommen“ festzufahren — gehen Sie davon aus, dass Sie ihn nicht erhalten werden, und beginnen Sie parallel damit, die laufende Umgebung zu bewahren und zu sichern und die Spezifikation aus Verhalten und Datenbank zu rekonstruieren.

Es gibt überhaupt keine Dokumentation. Wo fange ich an?

Bewahren Sie vor jeder Änderung zunächst den aktuellen Zustand. Erstellen Sie ein Disk-Image der laufenden Produktionsumgebung und ein Datenbank-Backup, und bestätigen Sie, dass sich beide tatsächlich wiederherstellen lassen. Nehmen Sie als Nächstes eine Bestandsaufnahme von ausführbaren Dateien, Autostart-Einträgen, geplanten Aufgaben, Konfiguration, externen Integrationen und Konten vor, um ein vollständiges Bild des Systems zu erhalten. Von dort aus ist der Standardansatz, die tatsächlichen Nutzer zu befragen und Bildschirme, Berichte und Datenbankschema zu beobachten, wobei nur die für das Geschäft wichtigsten Teile dokumentiert werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.