Dimensionierung von Legacy-Systemen jenseits der Zeilenzahl

Eine Zeilenzahl sagt, wie viel Quelltext vorhanden ist. Sie sagt nicht, wie viel Verhalten ein Ersatz bewahren muss, auf wie viele Arten dieses Verhalten verzweigen kann oder wie viel vom Quelltext noch ausgeführt wird. Wer diese Größen gleichsetzt, erhält scheinbar genaue Modernisierungsschätzungen, die um ein Vielfaches danebenliegen.

Ich habe erlebt, dass die Analyse einer kleinen Batch-Landschaft länger dauerte als die einer viel größeren Anwendung, weil jeder Job denselben veränderlichen Kundendatensatz berührte und jede Ausnahme in einem gedruckten Kontrollbericht erschien. Ich habe auch gesehen, wie einschüchternde Verzeichnisse nach einer Erreichbarkeitsanalyse zusammenschrumpften, weil dort noch jahrelang ausgemusterte Varianten mit dem Quellbaum ausgeliefert wurden. In beiden Fällen stimmte die Zählung. Die daraus gezogene Schlussfolgerung war falsch.

Die brauchbare Einheit ist keine Codezeile. Es ist ein Stück Verhalten, das gefunden, von seinen Abhängigkeiten getrennt, implementiert und als gleichwertig nachgewiesen werden muss. Fünf Messgrößen machen diese Arbeit sichtbar: Entscheidungstiefe, Fan-in bei persistenten Daten, Anteil toten Codes, Integrationsfläche und der Anteil des Verhaltens, der nur durch Produktionsausgaben bekannt ist. Keine davon liefert allein einen magischen Preis. Zusammen ergeben sie eine belastbare Form des Systems.

Zeilenzahl misst Bestand, nicht Aufwand der Neuentwicklung

Codezeilen beantworten eine enge Frage: Wie viel Text hat eine bestimmte Zählregel als Quelltext eingestuft? Robert Parks Bericht des Software Engineering Institute, Software Size Measurement: A Framework for Counting Source Statements, verwendet viel Aufwand darauf, physische Zeilen und logische Anweisungen genau zu definieren. Das ist die erste Warnung. Zwei Werkzeuge können sich bereits uneinig sein, bevor jemand Kommentare, generierte Copybooks, expandierte Makros, eingebettetes SQL oder mehrere Member mit derselben Routine besprochen hat.

Selbst eine vollständig normalisierte Zählung misst nur den Bestand. Sie kann bei der Aufnahme eines Repositorys, beim Speicherbedarf, beim Parser-Durchsatz oder bei einem ersten groben Vergleich von Versionen helfen, die in derselben Sprache und nach denselben Konventionen geschrieben wurden. Sie verrät nicht, ob 40 Zeilen eine geradlinige Zuordnung oder eine zustandsbehaftete Regel mit 16 Pfaden implementieren. Sie verrät nicht, ob 4.000 kopierte Zeilen aktiv sind. Und sie zeigt nicht, dass eine einzige Zuweisung an eine Statusspalte acht nachgelagerte Jobs verändert.

Auch die Sprache verzerrt den Nenner. COBOL-Datendeklarationen können Datensatzlayouts optisch groß machen. APL oder SQL können erhebliches Verhalten in wenigen Anweisungen ausdrücken. Generiertes Java kann Tausende wiederholter Zugriffsmethoden hinzufügen. Ein zeilenbasierter Quotient behandelt all das stillschweigend als gleichwertige Denkeinheiten. Das sind sie nicht.

Versuchen Sie nicht, das mit einer Umrechnungstabelle für Sprachen zu reparieren, etwa indem eine COBOL-Zeile einer bestimmten Zahl von Go-Zeilen entspricht. Diese Empfehlung bleibt beliebt, weil sie schnell eine Tabelle erzeugt und nach historischer Produktivitätsplanung aussieht. Bei einer Modernisierung scheitert sie, weil die Zielarchitektur die Textform der Quelle nicht bewahren sollte. Ein gemeinsam genutztes Copybook kann zu einem Schema und generierten Clients werden. Zwanzig fast gleiche Batch-Programme können zu einem Dienst plus Konfiguration werden. Eine dichte Berechnung kann in Rust dicht bleiben, weil die Mathematik und nicht die Quellsyntax den Aufwand bestimmt.

Behalten Sie die Zeilenzahl in der Analyse, aber beschriften Sie sie ehrlich. Erfassen Sie physische Zeilen, logische Anweisungen, generierte Zeilen, Kommentare und duplizierte Zeilen getrennt. Beschreiben Sie damit den Bestand. Lassen Sie ihre Summe niemals für Lieferaufwand oder Verhaltensrisiko stehen.

Zyklomatische Tiefe zeigt teure Entscheidungen

Zyklomatische Komplexität zählt unabhängige Pfade durch einen Kontrollflussgraphen. Thomas McCabe führte die Messgröße 1976 in seinem Aufsatz A Complexity Measure ein, mit dem graphentheoretischen Ausdruck, der üblicherweise als V(G) = E - N + 2P geschrieben wird. Sie ist nützlich, weil Testpflichten rund um Entscheidungen wachsen und nicht rund um Formatierung. Die spätere Technologiebeschreibung des Software Engineering Institute enthält auch eine wichtige Einschränkung: Ein hoher Wert allein beweist weder, dass ein Modul riskant ist, noch dass es neu gestaltet werden sollte.

Für die Analyse eines Legacy-Systems ist die Verteilung wichtiger als der Durchschnitt des Repositorys. Ein Mittelwert von sechs kann einen gleichmäßigen Codebestand beschreiben. Er kann aber auch bedeuten, dass die meisten Routinen trivial sind und einige wenige Abrechnungsmodule Hunderte Pfade enthalten. Diese Bestände brauchen unterschiedliche Pläne. Berichten Sie mindestens Median, 90. Perzentil, Maximum und den Anteil erreichbarer Routinen oberhalb des Schwellenwerts, den Ihr Team manuell prüft. Halten Sie generierte und tote Routinen aus der primären Verteilung heraus, weisen Sie sie aber daneben aus.

Zyklomatische Komplexität und zyklomatische Tiefe hängen zusammen, sind jedoch nicht dasselbe. Komplexität zählt unabhängige Pfade. Tiefe hält fest, wie weit Entscheidungen verschachtelt sind, bevor der Kontrollfluss auf eine einfachere Ebene zurückkehrt. Eine flache Dispatch-Tabelle mit 30 Fällen kann eine hohe Komplexität haben und trotzdem leicht zerlegbar sein. Fünf verschachtelte Bedingungen, die von vorherigen Änderungen abhängen, können weniger Pfade haben und dennoch schwerer zu erklären, zu testen und zu verlagern sein. Teams vermischen beides oft und wundern sich dann, warum ein Modul mit akzeptablem Wert das Prüfbudget aufbraucht.

Messen Sie beides je erreichbarer Routine. Zählen Sie für die Tiefe verschachtelte Bedingungen, Schleifen, Ausnahmen und sprachspezifische Verzweigungen, nachdem Sie Vorverarbeitung expandiert haben, die den Kontrollfluss verändert. Prüfen Sie dann Routinen, die auf einer der beiden Achsen hohe Werte haben. Die Prüfung soll vier Fragen beantworten: Hängt die Verzweigung von persistentem Zustand ab? Ändert sie Daten, die später in derselben Transaktion verwendet werden? Wird die Bedingung an anderer Stelle dupliziert? Können aufgezeichnete Eingaben beide Ergebnisse auslösen?

Addieren Sie nicht alle Komplexitätswerte zu einer riesigen Zahl. Eine Summe belohnt das Aufteilen einer Routine, auch wenn die tatsächlichen Entscheidungen des Systems unverändert bleiben, und sie verbirgt Konzentration. Nutzen Sie eine Heatmap oder eine sortierte Tabelle, die Modulidentität, Aufrufkontext und berührte Daten bewahrt. Eine Schätzung für eine Neuentwicklung muss wissen, wo Entscheidungen gekoppelt sind, nicht nur, wie viele Entscheidungselemente ein Parser gefunden hat.

Komplexität bestimmt auch den Aufwand für Nachweise. Eine geradlinige Routine braucht vielleicht repräsentative Grenzfälle. Eine tief verschachtelte Routine, die Preise, Steuern oder Berechtigungsergebnisse auswählt, braucht eine Matrix aus beobachteten und konstruierten Fällen. Das bedeutet nicht, dass jeder mathematische Pfad einen eigenen Test verdient. Nicht ausführbare Pfade gibt es, und manche Kombinationen schließt eine vorgelagerte Validierung aus. Es bedeutet, dass eine Schätzung die Arbeit finanzieren muss, mit der das Team die relevanten Pfade nachweist, statt anzunehmen, die Zeilenzahl habe sie bereits erfasst.

Daten-Fan-in legt den tatsächlichen Wirkungsradius offen

Fan-in misst, wie viele Aufrufer oder Abläufe auf eine Komponente zulaufen. Bei Legacy-Systemen ist Fan-in auf Codeebene hilfreich, aber Fan-in in der Datenschicht ist oft die schärfere Messgröße. Zählen Sie die unabhängig bereitgestellten Programme, Jobs, Masken, Berichte, Stored Procedures, Dateiübertragungen und Bedienerwerkzeuge, die jeden persistenten Datensatz, jede Tabelle, Datei, Queue oder jeden gemeinsam genutzten Datenbereich lesen oder schreiben.

Die Trennung von Lese-Fan-in und Schreib-Fan-in ist wichtig. Fünfzig Berichte, die ein nur ergänzbares Journal lesen, erzeugen Migrations- und Kompatibilitätsarbeit. Ein einziger Abstimmungsjob, der historische Zeilen schreibt, kann jedoch eine viel härtere Randbedingung für die Umstellung schaffen. Gemischte Verantwortung ist schlimmer: Eine Online-Transaktion aktualisiert einen Stammdatensatz, ein nächtlicher Batch korrigiert ihn und ein Bedienerwerkzeug kann bei einer Ausnahme ein Feld überschreiben. Ein Schemadiagramm zeigt das gemeinsam genutzte Objekt. Es zeigt weder Reihenfolge noch Befugnis oder betrieblichen Grund dieser Schreibzugriffe.

Beginnen Sie mit statischen Referenzen und gleichen Sie sie dann mit Laufzeitnachweisen ab. Statische Analyse kann direktes SQL, bekannte Dateinamen, die Nutzung von Copybooks und literale Aufrufe auflösen. Sie verfehlt dynamisches SQL, in Variablen zusammengesetzte Namen, Ersetzungen des Schedulers, Aliasse, Exits und Zugriffe durch Werkzeuge außerhalb des Repositorys. Laufzeitprotokolle für Datenbankzugriffe, Job-Logs, Nachrichtenmetadaten und die Historie von Dateikatalogen machen einen Teil dieses fehlenden Fan-in sichtbar. Gesprächsnotizen können Bedienerwerkzeuge ergänzen, doch behandeln Sie Erinnerungen als Hinweis, bis ein Nachweis sie bestätigt.

Ordnen Sie Datenbestände nach mehr als der bloßen Zahl der Referenzen. Trennen Sie Leser von Schreibern, Online- von Batch-Zugriffen und synchrone von verzögerten Aktualisierungen. Halten Sie fest, ob eine Transaktionsgrenze mehrere Bestände umfasst. Markieren Sie Felder, deren Bedeutung je Programm wechselt, etwa einen leeren Status, den ein Job als „ausstehend“ und ein anderer als „nicht anwendbar“ deutet. Solche semantischen Konflikte verursachen mehr Aufwand als eine saubere Tabelle mit vielen gewöhnlichen Lesern.

Ein brauchbarer Fan-in-Datensatz kann knapp bleiben:

asset,readers,writers,execution_modes,transaction_peer,observed
CUSTOMER-MASTER,14,4,online|batch,ADDRESS-HISTORY,yes
RATE-CONTROL,6,1,batch,none,no
CLAIM-QUEUE,3,3,online|operator,PAYMENT-FILE,partial

Die letzte Spalte ist beabsichtigt. Eine statische Referenz und ein beobachteter Zugriff sind unterschiedliche Aussagen. Bewahren Sie beide. Wenn eine Schätzung sie zusammenwirft, kann eine nie ausgeführte Referenz den Umfang aufblähen, während ein ungesehener dynamischer Zugriff verschwindet.

Ein hohes Fan-in bedeutet nicht automatisch „zuerst neu schreiben“. Oft bedeutet es das Gegenteil. Ein stark gemeinsam genutzter Datenbestand kann eine ausdrückliche Kompatibilitätsgrenze, eine stufenweise Übertragung der Verantwortung oder eine Phase erfordern, in der alte und neue Komponenten nebeneinander laufen. Die Messgröße ändert die Reihenfolge, weil sie zeigt, wo eine lokal korrekte Änderung dennoch den Bestand beschädigen kann.

Toter Code verändert den Nenner

Der Anteil toten Codes ist der Teil des Bestands, der in der festgelegten Produktionskonfiguration nicht ausgeführt werden kann. Er sollte den Implementierungsumfang senken, aber erst nachdem das Team nachgewiesen hat, warum der Code tot ist. Ein Verzeichnis zu löschen, weil sich niemand daran erinnert, ist keine Analyse.

Verwenden Sie drei Bezeichnungen. Nicht erreichbarer Code hat keinen Pfad von einem konfigurierten Einstiegspunkt. Nicht beobachteter Code besitzt einen möglichen Pfad, wurde im Beobachtungsfenster aber nicht ausgeführt. Ausgemustertes Verhalten hat eine vom Verantwortlichen bestätigte Entscheidung, dass der Ersatz es nicht bewahren wird. Diese Bezeichnungen können einander nicht ersetzen. IBMs Dokumentation zur Erkennung nicht erreichbaren COBOL-Codes sagt ausdrücklich, dass ihr Ergebnis aus statischer Analyse stammt und nicht den tatsächlichen Ausführungspfad widerspiegelt. Genau wegen dieser Einschränkung müssen statische und dynamische Nachweise getrennt bleiben.

Die Konfiguration definiert Erreichbarkeit. Ein Modul, das im Werktagsplan ungenutzt bleibt, kann zum Quartalsabschluss laufen. Eine CICS-Transaktion kann in einer Region deaktiviert und in einer anderen aktiv sein. JCL-Member können über Scheduler-Variablen ausgewählt werden. Eine Desktop-Anwendung kann ein Plugin laden, das in einer lokalen Konfigurationsdatei benannt ist, die nie in die Versionsverwaltung gelangte. Bilden Sie die Menge der Einstiegspunkte aus Produktionsplänen, Transaktionsdefinitionen, Deployment-Manifesten, Befehlsprozeduren, registrierten Jobs und Bedienerhandbüchern, nicht nur aus einem Aufrufgraphen mit dem offensichtlichen Hauptprogramm als Wurzel.

Berechnen Sie anschließend mehrere Anteile: statisch nicht erreichbare Anweisungen, erreichbare, aber nicht beobachtete Anweisungen, duplizierte erreichbare Anweisungen und zur Ausmusterung freigegebenes Verhalten. Geben Sie für jeden Anteil einen Vertrauenswert und einen Nachweis an. Die Schätzung sollte nur den ausgemusterten Anteil ausschließen. Nicht erreichbarer Code mit unsicherer Konfiguration gehört in eine Klärungsliste, während nicht beobachteter Code weiterhin gezielte Tests oder eine fachliche Entscheidung braucht.

Toter Code kann trotzdem nützliche Hinweise enthalten. Ein alter Zweig kann eine Feldkodierung oder ein Berichtslayout erklären, das an anderer Stelle weiterlebt. Bewahren Sie Quelle und Analysedatensatz auf, auch wenn das neue System das Verhalten auslässt. Der Fehler besteht darin, für die Übersetzung toter Routinen zu bezahlen, als wären sie Anforderungen. Der entgegengesetzte Fehler besteht darin, sie zu löschen, bevor das Team die aktiven Verträge um sie herum verstanden hat.

Integrationsfläche wird in Verträgen gezählt

Eine Integration ist kein einzelner Kasten in einem Architekturdiagramm. Sie ist ein Vertrag mit Transport, Datenform, Zeitregel, Fehlerverhalten, Verantwortungsgrenze, Sicherheitsmechanismus und Wiederanlaufverfahren. Zählen Sie diese Verträge und messen Sie dann, wie stark sie sich unterscheiden.

Eine nächtliche Datei mit fester Satzlänge kann mehr Reproduktionsaufwand verursachen als zehn gewöhnliche HTTP-Endpunkte. Die Datei kann einen exakten Namen, Zeichensatz, eine Satzlänge, Sortierreihenfolge, Kontrollsumme, ein Ankunftsfenster, eine Wiederholungsregel und eine manuelle Bestätigung verlangen. Ein Empfänger kann undokumentierte Füllbytes auswerten. Nichts davon erscheint in einer Zeilenzahl. Vieles steht nicht einmal im sendenden Programm, weil Scheduler, Übertragungsprodukt und Bedienerablauf Teile des Verhaltens tragen.

Erfassen Sie jede externe Kante und jede interne Kante, die eine Verantwortungs- oder Deployment-Grenze überschreitet. Dazu gehören Datenbanken anderer Teams, ein- und ausgehende Dateien, Queues, entfernte Prozeduraufrufe, Terminalprotokolle, E-Mail, Druckerausgabe, Identitätsdienste, Hardwareschnittstellen, als Importvorlage verwendete Tabellen und manuelle Übergaben, die ein Bericht auslöst. Fassen Sie fünf Dateien nicht als „Partner-Feed“ zusammen, wenn sie unterschiedliche Zeitpläne oder Fehlerbehandlungen haben.

Halten Sie für jeden Vertrag Richtung, Protokoll, Schemaquelle, Häufigkeit, Lastspitzen, Reihenfolge, Idempotenz, Wiederholungsregel, Zeitlimit, Authentifizierung, Verschlüsselung, Produzenten, Konsumenten, Testumgebung und ein Produktionsbeispiel fest. Unbekannt ist ein legitimer Wert. Es ist auch Arbeit. Eine leere Zelle darf nicht stillschweigend zur Annahme werden, dass die Voreinstellung der Zielplattform übereinstimmt.

Die Integrationsfläche hat zwei nützliche Werte. Die Vertragszahl misst die Breite. Die Vertragsneuheit misst, wie viele verschiedene Mechanismen das Team nachbilden oder ersetzen muss. Zwanzig Dateien mit demselben Generator und Bestätigungsprotokoll können eine Implementierungsfamilie bilden. Vier Schnittstellen über eine Mainframe-Queue, einen Druckersteuerstrom, eine proprietäre Desktop-Automatisierung und eine manuell eingehängte Freigabe schaffen vier Entdeckungs- und Testprobleme.

Achten Sie besonders auf negatives Verhalten. Konsumenten können von einer leeren Datei, einem bestimmten Rückgabecode, einer verzögerten Wiederholung, doppelter Zustellung oder dem Fehlen einer Zeile abhängen. Beispiele für den Erfolgsfall erfassen diese Verträge selten. Sammeln Sie Fehlerprotokolle und Wiederanlaufaufzeichnungen. Fragen Sie die Bediener, was sie tun, wenn das erwartete Artefakt nicht eintrifft. Ihre Handlung ist oft Teil des Systems, obwohl kein Compiler sie sehen kann.

Produktionsausgabe kann die einzige Spezifikation sein

Manches Legacy-Verhalten existiert nur in dem, was die Produktion ausgibt. Der Code berechnet es, Benutzer und nachgelagerte Systeme verlassen sich darauf, aber keine aktuelle Anforderung erklärt es. Diese Lücke verdient eine eigene Messgröße, weil sie Entdeckungs- und Prüfaufwand verändert.

Zählen Sie zuerst die Verhaltensoberflächen: API-Antworten, Datenbankänderungen, Dateien, Nachrichten, Bildschirmfelder, gedruckte Berichte, Audit-Datensätze, Rückgabecodes, Zeitereignisse und Bedienerabfragen. Klassifizieren Sie für jede Oberfläche die Quelle der Spezifikation als aktuelle Dokumentation, ausführbare Tests, Schlussfolgerung aus dem Code, Bestätigung durch Fachleute oder Produktionsbeobachtung. Mehrere Quellen können gelten. Gefährlich ist die Kategorie „nur Produktion“: Kein vertrauenswürdiges Dokument und kein Test definiert das Ergebnis, und Menschen beurteilen die Richtigkeit, indem sie die Ausgabe des alten Systems vergleichen.

„Nur Produktion“ muss nicht für immer rätselhaft bleiben. Erfassen Sie repräsentative Paare aus Eingabe und Ausgabe, normalisieren Sie veränderliche Felder wie Zeitstempel oder generierte Kennungen und spielen Sie die Eingaben nach Möglichkeit unter kontrollierten Bedingungen im alten System ab. Bewahren Sie Reihenfolge, Rundung, Kodierung, Behandlung leerer Werte und Fehlerausgabe, bevor jemand sie „bereinigt“. Ein abschließendes Leerzeichen kann in einem Bericht unwichtig und in einem anderen eine Feldgrenze sein.

Messen Sie das als gewichteten Anteil und nicht als bloße Zahl von Ausgaben. Gewichten Sie Ausgaben stärker, die Geld bewegen, Bücher abschließen, physische Arbeit steuern, Audit-Prüfungen erfüllen oder ein anderes System speisen. Erfassen Sie außerdem die Abdeckung: wie viel Eingabevielfalt, Kalendervielfalt und Fehlerverhalten der aufgezeichnete Verkehr enthält. Dreißig Tage Online-Anfragen können gewöhnliche Pfade abdecken und trotzdem den Jahresabschluss verpassen. Eine Million wiederholte Zustandsprüfungen liefert fast kein zusätzliches Wissen über das Verhalten.

Hier treffen Schätzung und Verifikation zusammen. Wenn Verhalten dokumentiert und getestet ist, kann das Ersatzteam gegen einen ausdrücklichen Vertrag implementieren. Wenn Verhalten nur in Ausgaben lebt, muss das Team den Vertrag entdecken, einen Vergleicher bauen, Unterschiede klassifizieren und eine Entscheidung einholen, wenn das alte Verhalten inkonsistent ist. Diese Arbeit existiert selbst dann, wenn die verantwortliche Routine nur 80 Zeilen umfasst.

Aufgezeichneter Verkehr ist ein Nachweis und keine unfehlbare Instanz. Er kann falsche Ergebnisse, verdeckte Fehler, sensible Daten und zufällige Abhängigkeiten enthalten. Setzen Sie Zugriffskontrollen und Datenminimierung ein, bestimmen Sie Felder, die die Kundengrenze nicht verlassen dürfen, und lassen Sie einen verantwortlichen Eigentümer entscheiden, ob eine Abweichung eine Regression oder einen alten Fehler zeigt, der ausgemustert werden soll. Automatisierte Parität ohne diesen Entscheidungsprozess kann Fehler mit beeindruckender Genauigkeit bewahren.

Ein Größenprofil hält verschiedene Risiken getrennt

Fassen Sie die Messgrößen in einem Profil zusammen und nicht in einer universellen gewichteten Punktzahl. Eine einzelne Zahl wirkt bequem, zerstört aber die Angaben, die für Architektur, Reihenfolge und Prüftiefe nötig sind. Zwei Systeme können denselben Wert erhalten, obwohl eines konzentrierte Entscheidungslogik und das andere einfachen Code hinter Dutzenden brüchiger Schnittstellen besitzt.

Das Profil sollte mehrere verbundene Datensätze für die untersuchte Produktionskonfiguration enthalten. Der Bestandsdatensatz hält logische Anweisungen sowie Anteile nach Sprache, Generierung, Duplikaten und Kommentaren fest. Der Entscheidungsdatensatz enthält Komplexität und maximale Verschachtelung mit Median, 90. Perzentil, Maximum und erreichbaren Hotspots. Der Datensatz zur Datenkonzentration enthält Leser und Schreiber je Bestand, Transaktionspartner, Ausführungsarten und beobachtete Zugriffe.

Der Erreichbarkeitsdatensatz enthält ausgemusterte und ungeklärte Anteile neben statischen Wurzeln, Laufzeitfenster und Eigentümerentscheidungen. Der Vertragsdatensatz enthält einzelne Schnittstellen, Mechanismusfamilien, Fehlerbeispiele und Testzugang. Der Nachweisdatensatz zum Verhalten enthält gewichtete Oberflächen, die nur durch Produktion bekannt sind, die Vielfalt aufgezeichneter Eingaben, Kalenderlücken und die verantwortliche Person für Abweichungsentscheidungen. Verwenden Sie über diese Datensätze hinweg stabile Kennungen, damit ein Prüfer vom Hotspot zum Nachweis wechseln kann, ohne Beschreibungen von Hand abzugleichen.

Versionieren Sie das Profil zusammen mit Einstiegspunkten, Konfigurationssatz, Beobachtungszeitraum, Werkzeugversionen und Ausschlüssen. Sonst kann ein späterer Scan der Analyse scheinbar widersprechen, obwohl er lediglich andere Scheduler-Wurzeln verwendet oder Copybooks anders expandiert hat.

Verwenden Sie Bänder statt falscher Genauigkeit. Bei der Entscheidungstiefe kann ein Band gewöhnliche Routinen, Prüfhotspots und Kandidaten zur Zerlegung unterscheiden. Beim Daten-Fan-in kann es isolierte Bestände, gemeinsam gelesene Modelle und umstrittene Schreibverantwortung trennen. Definieren Sie jedes Band über eine Handlung. Eine rote Zelle sollte „braucht eine Kompatibilitätsgrenze und eine Prüfung durch den Verantwortlichen“ bedeuten und nicht „sieht beängstigend aus“.

Das Profil macht auch Unsicherheit sichtbar. Markieren Sie, ob jeder Wert aus statischer Analyse, Laufzeitbeobachtung, Konfigurationsunterlagen oder einer Eigentümerentscheidung stammt. Fügen Sie Nachweis und Vertrauen hinzu. Eine unbekannte Wiederholungsregel einer Integration und eine exakte Zahl von 200.000 Zeilen dürfen nicht zu einem beruhigenden Wert gemittelt werden. Das Unbekannte kann das Umstellungsrisiko bestimmen.

Speichern Sie Rohbeobachtungen neben abgeleiteten Werten. Wenn ein Scanner 26 Aufrufer meldet und Laufzeitdaten 19 zeigen, bewahren Sie beide Zahlen samt Klärungsstatus. Spätere Arbeit kann belegen, dass fünf Aufrufer zu ausgemusterten Zeitplänen gehören und zwei Aufrufe dynamische Aliasse sind. Wer die frühere Zahl ersetzt, zerstört die Prüfungsspur und lässt die Schätzung sicherer erscheinen, als die Analyse je war. Dasselbe gilt für die Normalisierung von Komplexität, die Erkennung von Duplikaten und die Abdeckung des Verkehrs.

Wandeln Sie für die Schätzung Profileinträge in Arbeitspakete mit beobachtbaren Abschlussbedingungen um. Ein Entscheidungshotspot ist abgeschlossen, wenn Verhaltenstabelle, Implementierung und Paritätsfälle akzeptiert sind. Ein Datenbestand ist abgeschlossen, wenn Verantwortung, Transaktionsverhalten, Migrationsregel und Konsumenten berücksichtigt sind. Eine Integration ist abgeschlossen, wenn Erfolgsfälle, Fehler, Wiederholungen und betriebliche Übergabe in der Zielumgebung funktionieren. Eine nur durch Produktion bekannte Oberfläche ist abgeschlossen, wenn aufgezeichnete Fälle ohne Abweichung verglichen werden oder ein Eigentümer jede beabsichtigte Abweichung genehmigt.

So bleiben Multiplikatoren lokal. Eine Routine mit hoher Komplexität beeinflusst das Arbeitspaket, dem sie gehört. Sie macht nicht willkürlich jede Dateiübertragung und jede Maske doppelt so teuer. Ein schlecht spezifizierter Bericht ergänzt Entdeckungs- und Vergleichsarbeit für diese Ausgabe. Er bläht toten Code nicht auf. Lokale Faktoren lassen sich leichter hinterfragen, ändern und verifizieren.

Schätzen Sie Nachweise statt neuer Zeilen

Sobald das Profil steht, schätzen Sie Einheiten des zu bewahrenden Verhaltens und des Nachweises. Beginnen Sie mit erreichbaren Fähigkeiten und teilen Sie sie dort, wo sich Datenverantwortung, Integrationsverträge oder Prüfmethoden unterscheiden. Die Zeilenzahl des Ziels ist unbekannt und weitgehend bedeutungslos. Architekturarbeit kann Wiederholung entfernen, Programme zusammenführen oder prozedurale Hilfslogik durch Plattformfunktionen ersetzen.

Schätzen Sie für jede Einheit vier Tätigkeiten: Entdeckung, Zieldesign und Implementierung, Aufbau der Nachweise und Abnahme. Zur Entdeckung gehören die Klärung dynamischer Aufrufe, fehlender Layouts, Verantwortung und Regeln, die nur in Produktion bekannt sind. Zum Nachweisaufbau gehören Verkehrsaufzeichnung, Testdaten, Vergleicher und erwartete Fehlerfälle. Zur Abnahme gehört die Prüfung von Abweichungen durch jemanden, der entscheiden darf, ob altes Verhalten weiterhin verlangt wird.

Verstecken Sie Unsicherheit nicht in einer größeren Aufwandszahl. Führen Sie ein Annahmenregister mit Test und Eigentümer. „RATE-CONTROL hat keine interaktiven Schreiber“ lässt sich anhand von Zugriffsprotokollen und Bedienerprüfung testen. „Alle Jobs für den Quartalsabschluss stehen im Scheduler-Export“ lässt sich gegen die Ausführungshistorie prüfen. Klären Sie Annahmen mit hoher Wirkung früh, weil sie Grenzen und nicht nur Stunden verändern können.

Ein durchgerechneter Vergleich zeigt den Punkt. System A hat 700.000 logische Anweisungen, 45 Prozent genehmigtes ausgemustertes Verhalten, mittlere Entscheidungstiefe, zwei schreibintensive Datenzentren und sechs Integrationsfamilien mit erfassten Fehlerfällen. System B hat 180.000 Anweisungen, fast kein ausgemustertes Verhalten, mehrere tief verschachtelte Abrechnungsroutinen, neun umstrittene Datenbestände und Ausgaben, deren Regeln nur in Monatsabschlussberichten stehen. Eine Schätzung nach Zeilenzahl macht A fast viermal größer. Ein Verhaltensprofil kann nachvollziehbar zeigen, dass B mehr Entdeckungs- und Abnahmearbeit enthält. Das Profil beweist den Preis nicht. Es zeigt, warum der Preis den Nachweisen statt dem Textvolumen folgen muss.

Die Methode macht auch Angebote vergleichbar. Bitten Sie jeden Anbieter um seine gezählten Einstiegspunkte, Erreichbarkeitsklassifikation, Komplexitätsverteilung, Datenbestände mit hohem Fan-in, Vertragsinventar, nur durch Produktion bekannte Oberflächen und ungeklärte Annahmen. Wenn ein Anbieter einen Zeilenmultiplikator nennt und ein anderer die neun Bestände mit konkurrierenden Schreibern identifiziert, sehen Sie, wer das System untersucht und wer eine Geschichte bepreist hat.

CodeHero liest den gesamten Quellbaum parallel und prüft das modernisierte Verhalten anschließend mit einer Paritätsumgebung gegen aufgezeichneten Produktionsverkehr. Diese Kombination behandelt Bestandsgröße und Verhaltensnachweis als getrennte Probleme. Der Unterschied ist wichtiger als jede Aussage darüber, wie viele Zeilen ein Werkzeug aufnehmen kann.

Freigabe sollte der Messspur folgen

Eine glaubwürdige Schätzung für ein Legacy-System lässt andere Ingenieure den Umfang bis zu den Nachweisen zurückverfolgen. Für jedes große Arbeitspaket sollten Sie die Einstiegspunkte, die es erreichen, seine Entscheidungen, gelesene oder geschriebene Daten, überschrittene Verträge und Produktionsbeispiele für die Abnahme finden können.

Fragen Sie vor der Freigabe eines Plans, was der Prüfer ausgeschlossen hat und wer das genehmigte. Fragen Sie, welche Laufzeitperioden die Beobachtung abdeckte, einschließlich Quartals- oder Jahresabschluss. Verlangen Sie die größten Komplexitätshotspots statt eines Durchschnitts. Fragen Sie, welche Datenbestände mehrere Schreiber haben. Fragen Sie, für welche Schnittstellen Fehlerbeispiele fehlen. Fragen Sie, welche Ausgaben keine andere Spezifikation als die Produktion haben. Direkte Antworten dürfen Unsicherheit enthalten. Vages Vertrauen sollte die Freigabe stoppen.

Die Zeilenzahl gehört weiter auf die erste Seite, weil sie das analysierte Material beschreibt. Sie sollte neben dem Anteil toten und generierten Codes stehen und nicht über den Messgrößen, die Verhalten beschreiben. Die Schätzung muss sich ändern, wenn ein verborgener Schreiber auftaucht, wenn ein angeblich toter Job aktiv ist oder wenn für eine Ausgabe nicht genug Beispiele vorliegen. Ändert sie sich nur, wenn jemand ein weiteres Quellverzeichnis findet, misst das Modell Bestand und nennt ihn Ingenieurarbeit.

Das erste bezahlenswerte Ergebnis ist das versionierte Größenprofil samt Nachweisregister. Es schafft eine konkrete Grundlage für Architektur- und Geschäftsentscheidungen und gibt dem Ersatzteam eine Definition von fertig, die auch in der Produktion Bestand hat.