Wissen / Vorhandene Software weiterentwickeln

Bestehende Software erweitern: Bestand und Änderbarkeit prüfen

Kurz gesagt: Vorhandene Software lässt sich sinnvoll erweitern, wenn ihr tatsächlicher Stand nachvollziehbar und die Anwendung kontrolliert veränderbar ist. Prüfen Sie Quellcode, Installation, Abhängigkeiten, Datenmodell und wichtige Arbeitsabläufe. Eine kleine, fachlich definierte Änderung mit Vergleichsfällen zeigt, welche Grundlagen tragen und welche zuerst repariert werden müssen. Das Alter der Software allein entscheidet darüber nicht.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / 10 Minuten Lesezeit

01 / BESTAND UND ZIEL

Eine funktionierende Anwendung ist eine Grundlage, kein vollständiger Nachweis.

Bestand und gewünschte Änderung müssen zusammen betrachtet werden.

Ein internes Werkzeug kann seit Jahren zuverlässig Aufträge verwalten und trotzdem schwer zu verändern sein. Umgekehrt ist ältere Technik nicht automatisch ungeeignet. Für die Weiterentwicklung zählt, ob der konkrete Softwarestand zugänglich, startbar und verständlich ist und ob wichtige Funktionen nach einer Änderung kontrolliert geprüft werden können. Eine moderne Oberfläche allein beantwortet diese Fragen nicht.

Beginnen Sie mit einer einzelnen gewünschten Erweiterung: etwa einem zusätzlichen Status, einer neuen Auswertung oder einer Verbindung zu einem anderen System. Beschreiben Sie, was der Betrieb heute manuell erledigt und welches Ergebnis die Anwendung künftig liefern soll. Die fachliche Aufgabe bleibt der Maßstab für die technische Bestandsaufnahme. Eine allgemeine Bewertung jedes beliebigen Codeteils wäre dafür weder eindeutig begrenzt noch automatisch hilfreich.

Dieser Beitrag behandelt vorhandene Individualsoftware und ihren kontrollierten nächsten Änderungsschritt. Die grundsätzliche Entscheidung über Struktur und Inhalte eines öffentlichen Webauftritts behandelt Website-Relaunch oder gezielte Weiterentwicklung. Beim internen Werkzeug können dagegen gespeicherte Vorgänge, Sonderregeln und laufende Arbeitsprozesse den Aufwand bestimmen. Diese Unterschiede sollten im Auftrag sichtbar sein, damit die Bestandsaufnahme die tatsächlichen Abhängigkeiten untersucht.

02 / TATSÄCHLICHEN STAND BESTIMMEN

Welche Fassung läuft, und welcher Quellcode gehört dazu?

Eine Projektdatei mit „final“ im Namen ist keine Versionszuordnung.

Sammeln Sie die vorhandenen Quellen, die bekannte Veröffentlichung und die Information, wie Änderungen bisher ausgeliefert wurden. Lassen Sie die Betreuung abgleichen, ob der verfügbare Code zur laufenden Fassung gehört. Zusätzliche Änderungen direkt auf dem Server, lokal erzeugte Dateien oder ungesicherte Einzelkorrekturen können dafür relevant sein. Solche Unterschiede werden zunächst dokumentiert, nicht für eine vermeintlich saubere Ausgangslage gelöscht.

Die Git-Dokumentation zu Revisionen erklärt, wie sich gespeicherte Stände eindeutig bezeichnen lassen. Ein Commit kann eine belastbare Referenz für den versionierten Quellcode sein. Er beweist jedoch für sich allein nicht, dass genau dieser Stand veröffentlicht wurde oder dass außerhalb der Versionsverwaltung keine Änderungen existieren. Die Zuordnung zwischen Quelle, erzeugten Ausgabedateien und laufender Anwendung muss separat feststehen.

Halten Sie das Ergebnis in einer kurzen Ausgangsnotiz fest: Quellstand, festgestellte Abweichungen, zugehörige Konfiguration und bekannte Veröffentlichung. Bei Anwendungen mit einem Buildschritt gehört auch das Verfahren dazu, das aus den Quellen die ausgelieferten Dateien erzeugt. Bei direkt ausgelieferten Quellen kann dieser Schritt entfallen. Eine Dokumentation sollte den tatsächlichen Ablauf beschreiben, statt einen Build allein deshalb vorauszusetzen, weil er in anderen Projekten üblich ist.

03 / KONTROLLIERT STARTEN

Die Anwendung muss außerhalb des bisherigen Einzelrechners laufen können.

Eine überprüfte Startanleitung macht fehlende Voraussetzungen sichtbar.

Eine Übernahme braucht einen nachvollziehbaren Weg vom vorhandenen Quellstand zur lauffähigen Testfassung. Dazu gehören verwendete Laufzeiten, benötigte Dienste, Installationsschritte und die nötigen Konfigurationsnamen. Private Werte werden über einen vereinbarten sicheren Weg bereitgestellt; eine Anleitung sollte keine Passwörter oder produktiven Schlüssel enthalten. Für die erste Anfrage genügt eine Beschreibung, welche Systeme vorhanden sind.

Dokumentieren Sie auch Aufgaben außerhalb der Browseroberfläche: Hintergrundprozesse, zeitgesteuerte Scripts, Warteschlangen oder Dateiverzeichnisse. Eine sichtbare Anmeldung kann funktionieren, während die nächtliche Verarbeitung gar nicht läuft. Der Startnachweis sollte deshalb die für die geplante Erweiterung relevanten Komponenten umfassen. Unbekannte Dienste bleiben offene Voraussetzungen und dürfen nicht als erfolgreich übernommen gelten.

Die praktische Probe erfolgt in einer kontrollierten Umgebung mit passenden Testdaten. Ausgehende E-Mails, Zahlungsaktionen oder Veränderungen fremder Systeme dürfen dort nicht versehentlich produktiv ausgelöst werden. Ein ausdrücklich ersetzter Testdienst oder eine vereinbarte Simulation macht die Grenze nachvollziehbar. Wenn eine solche Umgebung fehlt, ist ihr Aufbau ein eigener Teil des Auftrags. Eine bloße Kopie der Produktionsdateien garantiert noch keine sichere oder vollständige Arbeitsumgebung.

04 / ABHÄNGIGKEITEN FESTHALTEN

Zuerst den bekannten Bestand installieren, dann Updates planen.

Eine funktionierende Lockdatei schützt die Vergleichbarkeit der Ausgangsprobe.

Abhängigkeiten sind zusätzlich verwendete Pakete, Laufzeiten und Dienste. Für die Bestandsaufnahme ist entscheidend, welche Fassung tatsächlich benötigt wird und wie sie bezogen werden kann. Eine allgemeine Versionsspanne kann bei einer späteren Installation einen anderen Paketstand ergeben. Deshalb sollten deklarierte Anforderungen, festgelegte Paketversionen und die bisher verwendete Umgebung gemeinsam betrachtet werden.

Als konkretes Beispiel beschreibt npm ci eine Installation anhand einer vorhandenen Lockdatei. Stimmen Paketdefinition und Lockdatei nicht überein, bricht der Befehl ab, statt die Lockdatei anzupassen. Bei PHP-Anwendungen erklärt die Composer-Dokumentation, dass install mit vorhandener composer.lock die darin festgelegten Versionen verwendet. Das sind Beispiele für passende Werkzeuge, keine pauschalen Befehle für jedes Softwareprojekt.

Solche Mechanismen erleichtern einen reproduzierbaren Paketbestand, beweisen aber nicht die vollständige Betriebsfähigkeit oder Sicherheit. Laufzeit, Plattform, Konfiguration, weitere Dienste und Installationsschritte bleiben relevant. Ein sofortiges großes Paketupdate würde zudem den Ausgangsvergleich verändern. Trennen Sie deshalb das Wiederherstellen eines bekannten Zustands von notwendigen Updates und der fachlichen Erweiterung. Für die allgemeine Einordnung der Abhängigkeiten ergänzt Drittanbieter-Code und Software-Lieferkette diesen Schritt.

05 / DATENMODELL VERSTEHEN

Eine zusätzliche Spalte kann bestehende Vorgänge verändern.

Gespeicherte Daten und ihre Bedeutung gehören zur Änderungsplanung.

Fragen Sie, welche Daten die Anwendung speichert und welche fachlichen Regeln damit verbunden sind. Ein scheinbar einfaches Feld kann in Suche, Export, Berichten, Schnittstellen und Hintergrundverarbeitung verwendet werden. Welche Werte sind erlaubt? Was bedeutet eine leere Angabe? Gibt es ältere Datensätze, die nicht den heutigen Regeln entsprechen? Diese Fragen sollten anhand geeigneter Daten geprüft werden, ohne unkontrolliert reale personenbezogene Daten zu verteilen.

Die PostgreSQL-18-Dokumentation zu Tabellenänderungen zeigt konkrete Auswirkungen: Das Entfernen einer Spalte entfernt auch ihre enthaltenen Daten; ein neuer Standardwert gilt für zukünftige Einfügungen und ändert vorhandene Zeilen nicht automatisch. Solche Unterschiede machen deutlich, warum eine geänderte Felddefinition und die Bearbeitung bereits gespeicherter Daten getrennte Aufgaben sein können.

Beschreiben Sie deshalb einen Migrationsweg: Ausgangszustand, neue Struktur, Behandlung vorhandener Werte, Vergleich nach der Umstellung und Umgang mit einem Abbruch. Die Django-5.2-Dokumentation zu Migrationen behandelt die versionierte Entwicklung von Datenbankschemata und zeigt auch Grenzen der Umkehrbarkeit. Ein zurückgesetzter Programmstand stellt daher nicht automatisch verlorene Daten wieder her. Welche Wiederherstellung praktisch möglich ist, muss zum verwendeten System und zur konkreten Änderung geprüft werden.

06 / BESTEHENDES VERHALTEN PRÜFEN

Halten Sie wichtige Vergleichsfälle vor der Änderung fest.

Die Testbasis trennt vorhandene Fehler von neuen Auswirkungen.

Welche Tätigkeiten dürfen durch die Erweiterung nicht schlechter funktionieren? Wählen Sie die wichtigsten Abläufe aus, die den betroffenen Bereich berühren. Bei einem Auftragswerkzeug könnten das Anlegen, Bearbeiten, Suchen und Exportieren eines Vorgangs sein. Verwenden Sie für jeden Ablauf konkrete Testdaten und ein fachlich bestätigtes Ergebnis. Damit ist später erkennbar, ob eine Änderung an anderer Stelle unbeabsichtigt wirkt.

Wenn vorhandene automatische Tests existieren, prüfen Sie zuerst, ob sie in der eingerichteten Umgebung tatsächlich laufen und welche Funktionen sie abdecken. Ein alter grüner Bericht oder eine Testdatei ohne ausgeführte Prüfung ist dafür kein Ersatz. Ohne geeignete Tests können zunächst gezielte Vergleichsfälle aufgebaut werden. Sie sollen beobachtbares Verhalten belegen und müssen nicht jeden internen Umsetzungsschritt nachzeichnen.

Notieren Sie bereits vorhandene Abweichungen mit klarer Trennung: bestätigt, noch ungeklärt oder außerhalb der aktuellen Aufgabe. Ein bestehender Fehler darf nicht stillschweigend zum gewünschten Verhalten erklärt werden. Umgekehrt sollte eine neue Erweiterung nicht die Verantwortung für jeden historischen Befund übernehmen, ohne dass Umfang und Priorität besprochen wurden. Diese Ausgangsbasis ermöglicht eine faire Abnahme: Die neue Funktion wird nach ihren Regeln geprüft, wichtige bestehende Abläufe nach ihren eigenen Vergleichsfällen.

07 / KLEINE ÄNDERUNGSPROBE

Ein begrenzter Schritt zeigt die tatsächliche Änderbarkeit.

Unser fiktives Beispiel ergänzt einen Termin im Auftragswerkzeug.

Die folgende Änderungsprobe ist ausdrücklich fiktiv und selbst entwickelt. Ein vorhandenes Werkzeug verwaltet Serviceaufträge. Ergänzt werden soll ein freiwilliger geplanter Einsatztermin. Alte Aufträge dürfen ohne Termin bestehen bleiben; neue Aufträge können einen Termin bekommen. Der Wert soll in der Liste erscheinen und im vorgesehenen Export enthalten sein. Eine Erinnerungsfunktion gehört ausdrücklich nicht zu dieser ersten Probe.

Fiktive Erweiterung mit Ergebnis und Vergleich
PrüfbereichVereinbarte ErwartungNachweis
Bestehender AuftragKein Termin wird erfunden; Auftrag bleibt les- und bearbeitbarVergleichsfall mit älterem synthetischem Datensatz
Neuer Auftrag mit TerminEingegebenes Datum wird nach der festgelegten Regel gespeichertAnlegen, erneut öffnen und gespeicherten Wert vergleichen
Termin ändernListe und Detail zeigen anschließend denselben aktuellen WertGezielte Änderung mit erneutem Abruf
Unzulässiger WertKeine ungültige Speicherung oder halbfertige ÄnderungFehlerfall mit überprüftem Ausgangsdatensatz
ExportNeues Feld und bisherige Felder folgen der vereinbarten AusgabestrukturVergleich mit festgelegtem Muster
RückwegProgramm- und Datenzustand können nach dem geplanten Verfahren wiederhergestellt werdenNachweis in der Testumgebung vor produktiver Umstellung

Aus dieser Probe entstehen greifbare Erkenntnisse: Welche Dateien und Datenstrukturen sind beteiligt? Welche Tests funktionieren? Ist eine Freigabe ohne Überraschungen möglich? Offene Probleme bleiben benannt. Für die genauere Formulierung ergänzt Abnahmekriterien für Software-Funktionen den technischen Nachweis. Ein kleiner erfolgreich geprüfter Schritt verspricht noch nicht, dass jede spätere Erweiterung ebenso einfach ist.

08 / BESTANDSPROTOKOLL

Die Bestandsaufnahme endet mit einer begründeten nächsten Aufgabe.

Ein lesbares Protokoll macht Voraussetzungen und Grenzen überprüfbar.

Unsere eigene Protokollvorlage lässt sich in sechs Punkte gliedern: zugeordneter Quellstand, nachgewiesene Installation, relevante Abhängigkeiten, verstandenes Datenmodell, ausgeführte Vergleichsfälle und Ergebnis der Änderungsprobe. Jeder Punkt bekommt einen kurzen Nachweis und offene Fragen. „Dokumentation vorhanden“ ist weniger aussagekräftig als „Die Startanleitung wurde mit der benannten Fassung erfolgreich ausgeführt; der externe Exportdienst wurde dabei ersetzt“.

Der NIST Secure Software Development Framework 1.1 bietet Empfehlungen für die Einbindung sicherer Entwicklungspraktiken in den Softwarelebenszyklus und eine gemeinsame Sprache zwischen Auftraggebern und Anbietern. Wir verwenden es hier als fachlichen Orientierungsrahmen, nicht als Zertifizierung oder als Behauptung einer vollständig nach NIST geprüften Anwendung. Das konkrete Bestandsprotokoll bleibt unsere eigene, projektbezogene Arbeitshilfe.

Trennen Sie daraus drei Entscheidungen: Was kann auf der nachgewiesenen Grundlage umgesetzt werden? Welche Voraussetzung muss zuerst hergestellt werden? Welche Bereiche benötigen eine eigene Untersuchung? Ein fehlender Installationsnachweis kann zum Beispiel zunächst die Wiederherstellung der Entwicklungsumgebung auslösen. Ein ungeklärtes Datenmodell kann vor einer neuen Funktion weitere Analyse verlangen. Diese nachvollziehbare Reihenfolge ist hilfreicher als eine pauschale Aussage, der gesamte Code sei gut oder schlecht.

09 / UMFANG UND WEITERENTWICKLUNG

Beauftragen Sie einen geklärten Schritt und seine Voraussetzungen.

Bestandsaufnahme und Erweiterung können getrennte Ergebnisse haben.

Ein Entwicklungsauftrag sollte sagen, welche Quellen und Nachweise bereits verfügbar sind und welche erst hergestellt werden müssen. Eine erste technische Einordnung kann den Umfang der nächsten Funktion begrenzen. Wenn die Bestandsaufnahme neue Abhängigkeiten zeigt, lassen sich Aufwand und Reihenfolge danach konkreter besprechen. Eine feste Zusage für unbekannte Software ohne diese Grundlage wäre fachlich schlecht überprüfbar.

Planen Sie die Auslieferung gemeinsam mit der bestehenden Betreuung. Zuständigkeit, Veröffentlichungsweg, Prüfung des laufenden Zustands und Wiederherstellung gehören zur konkreten Änderung. Die Entwicklungsumgebung und die Produktion müssen nicht identisch sein; relevante Unterschiede müssen aber bekannt sein. Ein erfolgreicher lokaler Test belegt beispielsweise nicht, dass ein externer Dienst in der produktiven Konfiguration richtig angebunden ist.

Auf der Leistungsseite Entwicklung beschreibt Ruhrstack auch Erweiterungen vorhandener Lösungen. Ein sinnvoller Einstieg sind die Beschreibung des bisherigen Ablaufs, die gewünschte neue Funktion und der bekannte technische Stand. Danach wird geklärt, welche Bestandsaufnahme nötig ist und welches Ergebnis der erste Auftrag liefern soll. Passwörter und reale Kundendaten gehören nicht in eine allgemeine Anfrage. Der sichere Zugang wird erst für die konkret vereinbarte Arbeit abgestimmt.

10 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 8. Oktober 2026 geprüft. Bestandsprotokoll und Änderungsprobe sind eigene redaktionelle Arbeitshilfen für ein ausdrücklich fiktives Werkzeug. Die Dokumentationen zu Django 5.2 und PostgreSQL 18 dienen als konkrete Beispiele; sie schreiben keinen Technikwechsel vor.

  1. Git: git-rev-parse und Bezeichnung von Revisionen, abgerufen am 8. Oktober 2026.
  2. npm: npm ci, Installation aus einer vorhandenen Lockdatei, abgerufen am 8. Oktober 2026.
  3. Composer: Basic usage, Installation und Lockdatei, abgerufen am 8. Oktober 2026.
  4. PostgreSQL 18: Modifying Tables, abgerufen am 8. Oktober 2026.
  5. Django 5.2: Migrations, abgerufen am 8. Oktober 2026.
  6. NIST: SP 800-218, Secure Software Development Framework 1.1, abgerufen am 8. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Welche Funktion fehlt Ihrer vorhandenen Software?

Beschreiben Sie den heutigen Ablauf und die gewünschte Erweiterung. Wir klären, welche Informationen für die technische Bestandsaufnahme nötig sind und welcher erste Änderungsschritt sinnvoll wäre.

Software-Erweiterung besprechen