Festlegung von Wartbarkeitsindex-Metriken für COBOL-Anwendungen

Der Wartbarkeitsindex (MI) ist eine der am weitesten verbreiteten Metriken zur Messung der Softwarequalität. Er fasst drei strukturelle Eigenschaften von Code – Größe, Komplexität und Umfang – in einem einzigen numerischen Wert zusammen, der vorhersagt, wie aufwendig Codeänderungen sein werden. Für moderne Programmiersprachen sind Formel, Schwellenwerte und Werkzeuge etabliert. Bei COBOL gestaltet sich die Situation komplexer, und die meisten Teams wenden entweder die generische Formel unverändert an oder verzichten gänzlich auf quantitative Messungen, da die Ergebnisse nicht den tatsächlichen Erfahrungen der Entwickler zu entsprechen scheinen.

Beide Ansätze führen zu irreführenden Ergebnissen. Die Anwendung der Standard-MI-Formel auf COBOL ohne Berücksichtigung des Verhaltens seiner Komponenten im syntaktischen Kontext von COBOL erzeugt systematisch verzerrte Ergebnisse, die hochwertige Programme als grenzwertig und minderwertige Programme als akzeptabel erscheinen lassen. Der vollständige Verzicht auf Messungen entzieht Modernisierungsentscheidungen die quantitative Grundlage, die sie benötigen, um gegenüber den Stakeholdern des Unternehmens nachvollziehbar zu sein und die Behebung von Mängeln in einem Portfolio von Tausenden von Programmen zu priorisieren.

Der richtige Weg besteht darin, zu verstehen, was die MI-Formel in COBOL konkret misst, wo sie die Qualität unter- bzw. überschätzt, welche ergänzenden Metriken ihre COBOL-spezifischen Schwächen ausgleichen und wie Schwellenwerte anhand Ihres tatsächlichen Portfolios kalibriert werden, anstatt anhand generischer Benchmarks, die von modernen Sprachcodebasen abgeleitet wurden. Dieser Leitfaden behandelt alle vier Aspekte und bietet sowohl genügend technisches Know-how für die Implementierung eines COBOL-MI-Programms als auch genügend praktische Anleitung für Modernisierungsentscheidungen.

Ein letzter Punkt vor den Details: Der Wartungsindex versucht, durch die Kombination verschiedener Kennzahlen einen umfassenden Überblick über den relativen Wartungsaufwand für unterschiedliche Projektabschnitte zu geben. Dieser ganzheitliche Blick ist gerade für COBOL-Portfolios wertvoll, da keine einzelne Kennzahl das Gesamtbild vollständig erfassen kann. Der Wartungsindex ist der Ausgangspunkt, nicht die ganze Wahrheit, aber der richtige Ort, um zu beginnen.

Warum die Messung der Wartbarkeit für COBOL wichtiger ist als für moderne Programmiersprachen

Die Messung der Wartbarkeit einer zwei Jahre alten, gut getesteten und vom Entwicklerteam gepflegten Java- oder Python-Codebasis liefert zwar nützliche Informationen, ist aber selten dringlich. Der Code ist für die Autoren verständlich. Die Logik ist dokumentiert oder aus Tests ableitbar. Die Kosten für Änderungen sind durch die Vertrautheit des Teams mit dem Code begrenzt.

COBOL-Portfolios in regulierten Branchen unterscheiden sich in dreierlei Hinsicht, was die quantitative Wartbarkeitsmessung nicht zu einer Qualitätsmaßnahme, sondern zu einer betrieblichen Notwendigkeit macht.

Die Wissenslücke. Der Großteil des COBOL-Codes enthält Geschäftslogik, die nie formal dokumentiert wurde. Batch-Jobs, die vor Jahrzehnten geschrieben wurden, kodieren Regeln, an die sich niemand mehr erinnert. Die Entwickler, die den Code fließend lesen und Änderungskosten präzise abschätzen können, gehen in Rente. Die verbleibenden Entwickler kennen nur Teile des Portfolios. Ohne quantitative Kennzahlen hängt die Schätzung der Änderungskosten vollständig davon ab, welchen Entwickler man befragt, und die Streuung dieser Schätzungen ist so groß, dass die Projektplanung unzuverlässig wird.

Das Problem des Umfangs. Ein typisches COBOL-Portfolio umfasst Tausende von Programmen, von denen viele jahrelang unverändert geblieben sind. Kein Team kann Tausende von Programmen manuell prüfen, bevor ein Modernisierungsprogramm beginnt. Kennzahlen, die innerhalb weniger Stunden automatisch für das gesamte Portfolio berechnet werden können, ersetzen wochenlange manuelle Überprüfungen.

Die Notwendigkeit eines Business Case. Modernisierungsprogramme erfordern eine Investitionsbegründung. Führungskräfte, die Modernisierungsbudgets in Millionenhöhe genehmigen, benötigen quantitative Nachweise für die Rechtmäßigkeit der Investition. MI-Scores, daraus abgeleitete Kennzahlen zur technischen Verschuldung und Kostenschätzungen für Veränderungen, die sich auf MI-Schwellenwerte beziehen, liefern diese Nachweise in einer Form, die auch Nicht-Technikern präsentiert werden kann.

Die MI-Formel und ihre COBOL-spezifischen Komponenten

Die am häufigsten verwendete Formel zur Berechnung des Wartbarkeitsindex lautet:

MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)

Die von Microsoft verwendete, begrenzte Variante, die von den meisten kommerziellen Tools genutzt wird, ordnet dies einer Skala von 0 bis 100 zu:

MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)

Jede Komponente erfordert spezifische COBOL-relevante Überlegungen.

Codezeilen in COBOL

COBOL-Quelldateien enthalten vier Abschnitte: IDENTIFICATION, ENVIRONMENT, DATA und PROCEDURE. Der Abschnitt IDENTIFICATION identifiziert das Programm. Der Abschnitt ENVIRONMENT beschreibt die Laufzeitumgebung. Der Abschnitt DATA definiert die Datenstrukturen. Nur der Abschnitt PROCEDURE enthält ausführbare Anweisungen.

Die Messfrage: Soll LOC alle Zeilen über alle vier Abteilungen hinweg zählen oder nur Anweisungen der PROCEDURE DIVISION?

Für Managementinformationssysteme (MI) führt das Zählen aller Zeilen (einschließlich Datendeklarationen) zu einer deutlichen Erhöhung der Codezeilen (LOC), ohne dass die Ausführungskomplexität entsprechend zunimmt. Ein COBOL-Programm mit 400 DATA DIVISION-Zeilen zur Definition von Datensatzlayouts und einer 100-zeiligen PROCEDURE DIVISION weist andere Wartbarkeitseigenschaften auf als ein Programm mit 100 DATA DIVISION-Zeilen und einer 400-zeiligen PROCEDURE DIVISION, wird aber von der reinen Codezeilenzählung identisch behandelt.

Bewährte Vorgehensweise: Verwenden Sie für die Berechnung der COBOL-MI die Anzahl der PROCEDURE DIVISION-Anweisungen (ohne Leerzeilen, Kommentarzeilen und Überschriften von Abschnitten/Paragraphen/Absätzen) anstelle der Gesamtzahl der Quellcodezeilen. Dadurch erhalten Sie LOC-Werte, die der Komplexität des ausführbaren Codes genauer entsprechen.

Das Problem mit COPY-Elementen: COPY-Anweisungen binden externe Quellcode-Elemente zur Kompilierzeit ein. Eine COPY-Anweisung, die zu 200 Zeilen Datendefinitionen expandiert, fügt der Quelldatei zwar eine Zeile hinzu, dem kompilierten Programm jedoch 200 Zeilen. Manche Tools zählen die logischen Zeilen (nach der Expansion), andere die physischen Quellcodezeilen. Bei Programmen mit häufigem COPY-Verbrauch kann der Unterschied um eine Größenordnung variieren.

Achtung: Wenn Ihr MI-Tool physische Quellcodezeilen zählt, erscheinen Programme mit umfangreicher COPY-Nutzung kleiner und wartungsfreundlicher als sie tatsächlich sind. Prüfen Sie daher immer, ob die Zeilenanzahl in Ihrem Tool vor oder nach der Kopiererweiterung berechnet wird.

Zyklomatische Komplexität in COBOL

Die zyklomatische Komplexität ist ein Qualitätsmerkmal für Code, das die Verständlichkeit und Wartbarkeit von Code misst, indem es die Anzahl unabhängiger Pfade durch diesen Code ermittelt. In COBOL umfassen die Entscheidungsstrukturen, die unabhängige Pfade erzeugen, Folgendes:

COBOL-Konstrukt	Auswirkungen der zyklomatischen Komplexität
IF ... END-IF	+1 pro IF
IF ... ELSE ... END-IF	+1 pro IF (ELSE fügt keinen weiteren Pfad hinzu)
EVALUATE ... WHEN	+1 pro WHEN-Klausel
PERFORM UNTIL condition	+1 pro UNTIL-Bedingung
PERFORM VARYING ... WITH TEST BEFORE/AFTER	+1 pro VARIIEREND
AT END Klausel zum LESEN	+1
ON EXCEPTION / NOT ON EXCEPTION	+1 pro Ausnahmebehandlung
ON OVERFLOW / NOT ON OVERFLOW	+1 pro Überlaufbehandlung
ON SIZE ERROR	+1 pro Größenfehlerbehandlung

Der blinde Fleck der 88er-Ebene: Die 88er-Bedingungsnamen in COBOL erzeugen logische Bedingungen, die zwar in IF- und EVALUATE-Anweisungen vorkommen, aber in der DATA DIVISION definiert sind. Ein Programm mit zwanzig 88er-Bedingungen, die jeweils in mehreren Entscheidungsstrukturen referenziert werden, weist eine deutlich höhere Verhaltenskomplexität auf, als die Anzahl der Anweisungen in der PROCEDURE DIVISION vermuten lässt. Die zyklomatische Komplexität zählt zwar die Entscheidungspunkte, kann aber die semantischen Beziehungen zwischen den 88er-Bedingungen und der Logik, die sie prüft, nicht erfassen.

LEISTUNG DURCH implizite Komplexität: PERFORM SECTION-A THRU SECTION-Z Führt alle Absätze zwischen ABSCHNITT A und ABSCHNITT Z aus. Die Anzahl der Absätze und die darin enthaltenen Entscheidungsstrukturen sind Teil der effektiven Komplexität der PERFORM-Anweisung, aber die auf Anweisungsebene berechnete Komplexität (CC) behandelt PERFORM THRU als ein einziger Weg, ungeachtet dessen, was dazwischen liegt.

Halstead-Volumen in COBOL

Das Halstead-Volumen ist ein Maß für die Größe und Komplexität eines Programms, basierend auf der Anzahl der Operatoren und Operanden. In COBOL:

Operatoren sind COBOL-Verben und Schlüsselwörter: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN usw.

Operanden sind Datennamen, Literale und figurative Konstanten: Datenelemente, die in der DATA DIVISION definiert sind, numerische und Zeichenkettenliterale sowie COBOL-figurative Konstanten (SPACES, ZEROS, HIGH-VALUES, LOW-VALUES).

Der Faktor der Ausführlichkeit: COBOL ist für äquivalente Logik deutlich umständlicher als moderne Sprachen. Ein Java-Ausdruck total = quantity * unitPrice * (1 - discount) ist eine Zeile mit vier Operatoren und vier Operanden. Das COBOL-Äquivalent:

Cobol

       COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
                        * (1 - WS-DISCOUNT)

Dies entspricht in etwa der Anzahl an Operatoren und Operanden. Betrachten wir jedoch eine komplexere Berechnung, die in Java etwa drei Zeilen benötigt, so sind in COBOL aufgrund der fehlenden Möglichkeit zur Verkettung von Ausdrücken und der Notwendigkeit, Zwischenspeicherfelder zu verwenden, unter Umständen fünf oder mehr Zeilen erforderlich. Das Halstead-Volumen ist daher für COBOL entsprechend höher als für die äquivalente Java-Berechnung, da COBOL dieselbe Berechnung mit mehr Sprachbausteinen ausdrückt.

Die praktische Konsequenz: COBOL-Programme weisen höhere Halstead-Volumina auf als Programme moderner Programmiersprachen mit vergleichbarer Logik. Ein höheres Halstead-Volumen reduziert den MI-Wert. COBOL-Programme erzielen daher systematisch niedrigere MI-Werte als Programme moderner Programmiersprachen mit vergleichbarer Komplexität, nicht weil sie schwieriger zu warten sind, sondern weil COBOL syntaktisch ausführlicher ist.

Wo Standard MI bei COBOL an seine Grenzen stößt: Vier blinde Flecken

Selbst bei korrekter Berechnung vernachlässigt die Standard-MI-Formel vier Dimensionen der COBOL-Wartbarkeit, die einen erheblichen Einfluss auf die tatsächlichen Änderungskosten haben.

1. KOPIE Mitgliedskopplung

Ein von 300 Programmen eingebundenes COBOL-Copybook stellt eine Wartungsabhängigkeit dar, die sich bei jeder Änderung daran auf alle 300 Programme auswirkt. Diese Kopplung erscheint in keiner Komponente der MI-Formel. Ein Programm mit zwanzig Copybooks weist 300 implizite Abhängigkeiten auf, die MI als äquivalent zu einem Programm ohne Copybooks behandelt.

Zusätzliche Kennzahl: Anzahl der Abhängigkeiten zwischen Kopierelementen, d. h. die Anzahl eindeutiger COPY-Anweisungen in der DATA DIVISION eines Programms. Programme mit hoher COPY-Kopplung erfordern vor jeder Änderung eine Folgenabschätzung, um zu ermitteln, welche anderen Programme dieselben Copybook-Definitionen verwenden.

2. Fan-In (Anzahl der Zuschauer)

Ein COBOL-Subprogramm, das von 150 anderen Programmen aufgerufen wird, stellt unabhängig von seinem MI-Wert ein hohes Änderungsrisiko dar. Ein gut wartungsfreundliches Subprogramm (MI = 85), das von 150 Programmen aufgerufen wird, lässt sich schwieriger sicher ändern als ein schlecht wartungsfreundliches Hilfsprogramm (MI = 45), das von niemandem aufgerufen wird. Die MI-Formel berücksichtigt nicht die Verbreitung eines Programms.

Ergänzende Kennzahl: Fan-In, die Anzahl der verschiedenen Programme, die ein bestimmtes Programm über CALL oder dynamische Dispatch aufrufen. Fan-In ist der Hauptfaktor für das Änderungsrisiko von Unterprogrammen, unabhängig von deren interner Komplexität.

3. JCL-Abhängigkeitstiefe

Ein COBOL-Programm, das von einem JCL-Job mit fünfzehn abhängigen Folgejobs aufgerufen wird – Jobs, die nach dem Programm ausgeführt werden und von dessen Ausgabe abhängen –, birgt ein Betriebsrisiko, das vollständig außerhalb des MI-Bereichs liegt. Ein eigenständig laufendes Programm mit MI = 55 ist weniger riskant zu modifizieren als ein Programm mit MI = 80, das im Zentrum einer komplexen Batch-Abhängigkeitskette steht.

Zusätzliche Metrik: JCL-Abhängigkeitstiefe, die Tiefe der nachgelagerten Abhängigkeitskette im JCL-Jobnetzwerk. Programme mit hoher JCL-Abhängigkeitstiefe erfordern unabhängig von ihrem internen MI-Wert einen umfassenderen Testumfang für jede Änderung.

4. Inflation von totem Code

Tote Abschnitte und Paragraphen, also COBOL-Code, der zwar definiert, aber nie aufgerufen wird, erhöhen die Codezeilenanzahl (LOC) und das Halstead-Volumen, ohne den Wartungsaufwand für den aktiven Code zu erhöhen. Ein Programm mit 600 Zeilen totem und 200 Zeilen aktivem Code hat einen Managementindex (MI), der den toten Code negativ bewertet, obwohl dieser für die Änderungskosten irrelevant ist.

Zusätzliche Metrik: Anteil ungenutzten Codes, der Anteil der PROCEDURE DIVISION-Anweisungen, die von keinem Produktionsausführungspfad aus erreichbar sind. Hohe Anteile ungenutzten Codes deuten darauf hin, dass die mit MI berechneten Zeilenanzahlen (LOC) und das Halstead-Volumen deutlich überhöht sind.

Eine vollständige COBOL-Metriksuite

Die Wartbarkeit von COBOL lässt sich nicht durch eine einzelne Kennzahl erfassen. Die folgende Gruppe von Kennzahlen liefert in Kombination ein vollständiges Bild:

Metrisch	Was es misst	COBOL-spezifischer Hinweis	Hauptnutzen
Wartbarkeitsindex	Gesamter Wartungsaufwand (Verbundwerkstoff)	Gilt für die Abschlüsse der Verfahrensabteilung; Kopierhandhabung prüfen	Basisqualitätswert; Portfolio-Ranking
Zyklomatische Komplexität	Anzahl unabhängiger Ausführungspfade	Berücksichtigen Sie EVALUATE WHEN, PERFORM UNTIL, AT END, ON EXCEPTION	Änderungsaufwand pro Programm; Schätzung der Testfallanzahl
Halstead-Volumen	Rechenaufwand (Operatoren + Operanden)	Erwarten Sie höhere Werte als bei vergleichbaren modernen Sprachprogrammen	Teil von MI; programmübergreifender Vergleich innerhalb des COBOL-Portfolios
KOPIE Mitgliederzahl	Abhängigkeitskopplung durch gemeinsame Definitionen	Programme mit mehr als 15 COPY-Mitgliedern erfordern vor jeder Änderung eine Folgenabschätzung.	Änderungsrisikoklassifizierung
Fan-In (Aufgerufen von)	Wie viele Programme nennen das?	Haupttreiber des Veränderungsrisikos für Teilprogramme	Migrationssequenzierung; Änderungsberechtigungsschwelle
Toter Code %	Prozentsatz des nicht erreichbaren Prozedurencodes	LOC/HV aufblasen, falls nicht ausgeschlossen; vom Umrechnungsumfang ausschließen.	Umfangsreduzierung für die Modernisierung
JCL-Abhängigkeitstiefe	Tiefe der nachgelagerten Batch-Job-Kette	Aus dem COBOL-Quellcode allein nicht berechenbar; erfordert JCL-Analyse	Risiko von Betriebsänderungen; Testumfang
Verschachtelte PERFORM-Tiefe	Maximale Verschachtelungsebene von PERFORM-Aufrufen	Tiefe Verschachtelung deutet auf strukturelle Komplexität hin, die von CC nicht erfasst wird.	Refactoring-Priorität

Schwellenwertkalibrierung für COBOL

Standardmäßige MI-Schwellenwerte basieren auf modernen Programmiersprachen und sind nicht direkt auf COBOL anwendbar. Die folgende Tabelle vergleicht Standard-Schwellenwerte mit entsprechenden COBOL-Werten und erläutert die Gründe für die Anpassung.

Ergebnisbereich	Standardinterpretation	COBOL-Interpretation	Begründung
85-100	Sehr wartungsfreundlich	Sehr gut wartungsfreundlich (beständig)	Die besten COBOL-Programme erreichen diese Werte: saubere Struktur, angemessene Größe
65-84	Mäßig wartungsfähig	Mäßig wartungsfreundlich, COPY-Kopplung und Fan-In überprüfen.	Der Standardschwellenwert bleibt bestehen, aber ergänzende Kennzahlen sind hier wichtiger.
50-64	Mangelhaft, Überarbeitung erforderlich	Randbedeutend, im Kontext beurteilen	Viele gut strukturierte COBOL-Programme erzielen hier allein aufgrund ihrer Ausführlichkeit hohe Werte; verwenden Sie CC und Fan-In, um echte Probleme von Syntaxartefakten zu unterscheiden.
25-49	Sehr schlecht	Schlechte Qualität, wahrscheinlich hohe CC und/oder übermäßige LOC	Programme in diesem Bereich weisen zuverlässig auf strukturelle Probleme hin, nicht nur auf die Ausführlichkeit von COBOL.
0-24	Kritische, grundlegende Refaktorisierung	Kritisch, höchste Priorität für Sanierung oder Stilllegung	Im Einklang mit der Standardinterpretation

Wichtige Kalibrierungshinweise: Führen Sie MI für Ihr gesamtes COBOL-Portfolio durch, bevor Sie programmspezifische Schwellenwerte festlegen. Berechnen Sie den Median und den Interquartilsabstand des Portfolios. Setzen Sie den Schwellenwert für „Aufmerksamkeit erforderlich“ auf das 25. Perzentil Ihres eigenen Portfolios, also auf Programme im untersten Quartil Ihrer spezifischen Codebasis, nicht auf Programme, deren Wert unter einem aus Java-Programmen abgeleiteten Schwellenwert liegt. Dieser Ansatz ist selbstkalibrierend und berücksichtigt den systematischen COBOL-Ausführlichkeitseffekt.

MI für Modernisierungsentscheidungen nutzen

MI-Scores sind besonders wertvoll, wenn sie als Grundlage für konkrete operative Entscheidungen dienen. Hier sind die wichtigsten Anwendungsbereiche.

Reihenfolge der Migrationswellen. Programme mit hohen MI-Werten (gut gewartet, geringe Komplexität) eignen sich am besten für frühe Migrationswellen. Sie sind leichter zu validieren, enthalten seltener undokumentierte Randfälle und bergen ein geringeres Risiko für unerwartetes Verhalten in der migrierten Umgebung. Programme mit niedrigen MI-Werten sollten in späteren Wellen migriert werden, nachdem das Team Erfahrung und Sicherheit gesammelt und die Geschäftslogik gründlich extrahiert hat.

Priorisierung der Wartung. Programme mit einem MI-Wert unterhalb des 25. Perzentils, die zudem eine hohe Fan-In-Rate (Aufruf durch viele Programme) oder eine hohe JCL-Abhängigkeitstiefe aufweisen, stellen die risikoreichste Kombination dar: strukturell komplexe Programme, von denen viele andere Programme abhängen. Diese Programme erzeugen am ehesten änderungsbedingte Fehler und sind im Fehlerfall am teuersten zu beheben. Sie sollten daher vorrangig im Rahmen eines Programms zur Reduzierung technischer Schulden behandelt werden.

Eigenentwicklung oder Kaufentscheidung. Bei der Bewertung, ob ein COBOL-Programm langfristig beibehalten oder durch eine SaaS-Lösung oder eine moderne Alternative ersetzt werden soll, liefern der MI-Wert und die Kostenhistorie für Änderungen die quantitative Grundlage für die Eigenentwicklungs- oder Kaufentscheidung. Ein Programm mit einem MI-Wert von 30, das in den letzten drei Jahren fünfzehn Mal modifiziert wurde, wobei jede Modifikation deutlich länger dauerte als geplant, weist dokumentierte Wartungskosten auf, die mit den Kosten einer Neulösung verglichen werden können.

Änderungsfreigabeschwellen. Einige Organisationen verwenden MI-Scores, um den erforderlichen Freigabegrad für Änderungen zu bestimmen. Programme unterhalb eines bestimmten MI-Schwellenwerts erfordern eine strengere Prüfung, unabhängige Tests und eine zusätzliche Freigabe vor der Produktionsfreigabe. Dadurch wird ein qualitätsorientierter Änderungskontrollprozess geschaffen, ohne dass jede Änderung manuell bewertet werden muss.

Eines kann MI nicht leisten: die geschäftlichen Auswirkungen einer Änderung vorhersagen. Ein Programm mit MI = 85, das regulatorische Kapitalberechnungen durchführt, erfordert mindestens genauso viel Test und Validierung wie ein Programm mit MI = 40, das eine Berichtsfunktion mit geringem Risiko erfüllt. MI misst den Veränderungsaufwand, nicht die Veränderungsfolgen. Beide Dimensionen sind für eine vollständige Risikobewertung erforderlich.

Wie SMART TS XL Erstellt und verfolgt COBOL-Wartbarkeitsmetriken

Die Berechnung der Managementinformation (MI) für ein einzelnes COBOL-Programm ist unkompliziert. Die genaue Berechnung für ein Portfolio von Tausenden von Programmen unter Berücksichtigung der COPY-Erweiterung, der Identifizierung von totem Code und der Ergänzung der MI um die fehlenden zusätzlichen Metriken erfordert eine automatisierte Analyse im großen Maßstab.

SMART TS XL statische Code-Analyse Berechnet die vollständige, in diesem Leitfaden beschriebene COBOL-Metriksuite simultan für das gesamte Portfolio. Der MI-Wert wird anhand der Anzahl der PROCEDURE DIVISION-Anweisungen anstelle der gesamten Quellcodezeilen berechnet. Vor der Analyse wird eine COPY-Erweiterung durchgeführt, um sicherzustellen, dass gemeinsam genutzte Datendefinitionen korrekt zugeordnet werden. Die zyklomatische Komplexität berücksichtigt EVALUATE WHEN-Klauseln, PERFORM UNTIL-Bedingungen und Ausnahmebehandlungszweige, nicht nur IF-Anweisungen. Das Halstead-Volumen wird aus den COBOL-Verben und Datenoperanden in der PROCEDURE DIVISION berechnet.

Entscheidend ist, SMART TS XL Ergänzt MI um die Kennzahlen, die die Formel nicht liefert. Zuordnung von Anwendungsabhängigkeiten Ermittelt die Fan-in-Werte, also die Aufrufzahlen, für jedes Programm im Portfolio und identifiziert risikoreiche Programme unabhängig von ihrem MI-Score. JCL-Erweiterung Die Funktion bietet die JCL-Abhängigkeitstiefe für jedes Programm und verbindet die MI-Analyse auf COBOL-Ebene mit dem operationellen Risikokontext, den nur die JCL-Analyse aufdecken kann.

Die Funktion zur Auswirkungsanalyse identifiziert toten Code, indem sie Absätze und Abschnitte ohne eingehende Ausführungspfade kennzeichnet. Dadurch kann toter Code von der MI-Berechnung ausgeschlossen werden, und es wird die Metrik des toten Codeanteils bereitgestellt, die bestimmt, ob der niedrige MI-Wert eines Programms auf echte Komplexität oder auf überhöhte Codezeilen zurückzuführen ist.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage des gesamten Metrikdatensatzes: Alle Programme mit einem MI-Wert unter 40 und einem Fan-In-Wert über 20, sortiert nach JCL-Abhängigkeitstiefe, sowie die wichtigsten Behebungsziele im Portfolio lassen sich mit einer einzigen Abfrage über Millionen von COBOL-Zeilen hinweg finden. Dieses abfragbare Metrikinventar bildet die Grundlage für die oben beschriebenen Anwendungen zur Priorisierung von Wartungsarbeiten, Migrationsreihenfolgeplanung und Änderungsfreigabe.

Schließlich zeigt der über die Zeit verfolgte MI, der nach jedem wesentlichen Änderungszyklus neu berechnet wird, ob sich das Programm verbessert oder verschlechtert. SMART TS XLDie Analyse wird auf Basis des aktuellen Quellcodes und nicht auf Basis zwischengespeicherter Momentaufnahmen durchgeführt. Dadurch wird sichergestellt, dass die Metriken den tatsächlichen Zustand der Codebasis zum Zeitpunkt jeder Analyse widerspiegeln und nicht eine Momentaufnahme, die mit der Zeit veraltet.

Metriken, die zur Sprache passen

Der Wartbarkeitsindex (MI) ist eine valide und wertvolle Kennzahl für COBOL-Portfolios, jedoch nur, wenn er unter Berücksichtigung der Wechselwirkungen zwischen den syntaktischen Eigenschaften von COBOL und seinen Komponenten angewendet wird. Die Anwendung generischer Schwellenwerte auf COBOL-Programme führt zu irreführenden Ergebnissen. Die Ergänzung des MI um die nicht berücksichtigten Kennzahlen – wie COPY-Kopplung, Fan-In, JCL-Abhängigkeitstiefe und Anteil toten Codes – ergibt ein Bild, das den tatsächlichen Erfahrungen von Entwicklern in einem COBOL-Portfolio entspricht.

Organisationen, die diese Kennzahlen effektiv nutzen, betrachten sie als Ausgangspunkt für fundierte Gespräche und nicht als endgültiges Urteil über die Programmqualität. Ein MI-Wert ist ein Signal. Dieses Signal ist beachtenswert, da es konsequent auf Programme hinweist, deren Änderung kostspielig und deren Modifizierung riskant ist und die vor Beginn einer Modernisierung angegangen werden sollten. MI kann jedoch weder das Urteilsvermögen eines Entwicklers, der den Code liest, ersetzen, noch die Strukturanalyse, die Abhängigkeiten und Geschäftslogik aufdeckt, die keine einzelne Kennzahl erfassen kann.