Aktualisierungen mit Rückweg planen

Erfassen Sie Anwendung, Modell, Werkzeugverträge, Regeln und Datenstruktur des heutigen Stands. Ein einzelner Softwarestand reicht nicht, wenn die Arbeit von mehreren unabhängig geänderten Teilen abhängt. Benennen Sie die Änderung und den fachlichen Grund. Markieren Sie, welche Aufträge oder Quellen betroffen sein könnten. Eine Aktualisierung der Dokumentation ist von einer Aktualisierung eines laufenden Systems zu unterscheiden. Die Versionsseite dieser Bibliothek listet nur belegte Repository-Änderungen.

Planen Sie dieselben fachlichen Fälle wie vor der Änderung und ergänzen Sie gezielte Gegenfälle für die neue Funktion. Prüfen Sie Leserechte, Freigaben, Werkzeugwirkung und Protokollierung gemeinsam. Ein erfolgreicher Programmstart beweist keine unveränderte fachliche Bedeutung. Geänderte Datenfelder können beispielsweise einen bisherigen Filter entwerten. Halten Sie erwartete Ergebnisse vor dem Vergleich fest und beschreiben Sie jede beobachtete Abweichung als Befund.

1. Bestimmen Sie den letzten nachweislich brauchbaren Stand.
2. Prüfen Sie, welche Datenänderungen sich damit noch lesen lassen.
3. Legen Sie Abbruchkriterien und die zuständige Entscheidungsperson fest.
4. Beschreiben Sie, wie offene Aufträge während des Wechsels angehalten und später geprüft werden sollen.

Eine Rückkehr des Programmcodes macht bereits ausgeführte Außenwirkungen nicht rückgängig. Solche Wirkungen brauchen eine eigene fachliche Behandlung.

Nach der geplanten Übernahme müssen Quellenstand, laufende Aufträge und tatsächliche Zielwirkungen kontrolliert werden. Dokumentieren Sie Version, Zeitpunkt und begrenzten Prüfumfang. Wenn ein Abbruchkriterium eintritt, sollen neue Wirkungen zuerst angehalten werden. Bewahren Sie den fehlerhaften Zustand für die Ursachenanalyse, soweit die vereinbarten Datenregeln das erlauben. Ein Versionswechsel endet erst mit einem nachvollziehbaren Betriebsbefund oder einer dokumentierten Rückkehr, nicht mit dem Kopieren einer Datei.