Wskaźnik Utrzymywalności (MI) to jeden z najczęściej stosowanych wskaźników złożonych w pomiarze jakości oprogramowania. Łączy on trzy strukturalne właściwości kodu: rozmiar, złożoność i objętość, w jeden wynik liczbowy, który przewiduje, jak trudno będzie zmienić kod. W przypadku języków współczesnych formuła, progi i narzędzia są dobrze znane. W przypadku języka COBOL sytuacja jest bardziej skomplikowana i większość zespołów albo stosuje ogólny wzór bez żadnych korekt, albo całkowicie rezygnuje z pomiaru ilościowego, ponieważ wyniki wydają się nie odpowiadać rzeczywistym doświadczeniom programistów.
Oba podejścia dają mylące rezultaty. Zastosowanie standardowej formuły MI do języka COBOL bez zrozumienia, jak jego komponenty zachowują się w kontekście składniowym COBOL-a, prowadzi do wyników systematycznie obciążonych, przez co programy wysokiej jakości wydają się marginalne, a programy niskiej jakości – akceptowalne. Całkowite porzucenie pomiarów pozbawia decyzje modernizacyjne ilościowych podstaw, niezbędnych do ich obrony przed interesariuszami biznesowymi i nadania priorytetu działaniom naprawczym w odniesieniu do portfela tysięcy programów.
Uzyskaj pełny obraz metryk COBOL
SMART TS XL jednocześnie klasyfikuje wszystkie programy COBOL według złożoności, stopnia zaawansowania i głębokości zależności od JCL.
Więcej informacjiPrawidłowym sposobem jest zrozumienie, co formuła MI mierzy konkretnie w COBOL-u, gdzie zaniża i zawyża jakość, jakie dodatkowe wskaźniki korygują specyficzne dla COBOL-a słabe punkty oraz jak kalibrować progi względem rzeczywistego portfolio, a nie ogólnych benchmarków pochodzących z baz kodu współczesnych języków. Niniejszy przewodnik obejmuje wszystkie cztery, zapewniając wystarczającą głębię techniczną, aby wdrożyć program MI w COBOL-u, oraz wystarczającą ilość praktycznych wskazówek, aby wykorzystać go do podejmowania decyzji modernizacyjnych.
Ostatnia uwaga przed omówieniem mechaniki: Wskaźnik Utrzymywalności (MI) stara się zapewnić holistyczny obraz względnego obciążenia konserwacyjnego dla różnych sekcji projektu poprzez połączenie szeregu różnych wskaźników. Ten holistyczny obraz jest cenny dla portfeli COBOL właśnie dlatego, że żaden pojedynczy wskaźnik nie oddaje pełnego obrazu. Wskaźnik Utrzymywalności (MI) to punkt wyjścia, a nie cała historia, ale właściwy punkt wyjścia.
Dlaczego pomiar utrzymywalności jest ważniejszy w przypadku języka COBOL niż języków współczesnych
Pomiar utrzymywalności kodu w Javie lub Pythonie, który ma dwa lata, jest dobrze przetestowany i utrzymywany przez zespół, który go stworzył, dostarcza użytecznych informacji, ale rzadko jest pilny. Kod jest czytelny dla jego autorów. Logika jest udokumentowana lub można ją wyprowadzić z testów. Koszt zmian jest ograniczony znajomością kodu przez zespół.
Portfele COBOL w regulowanych branżach różnią się w trzech aspektach, które sprawiają, że ilościowy pomiar utrzymywalności nie jest praktyką jakościową, lecz operacyjną koniecznością.
Luka w wiedzy. Większość kodu COBOL zawiera logikę biznesową, która nigdy nie została formalnie udokumentowana. Zadania wsadowe napisane dekady temu kodują reguły, których nikt nie pamięta. Programiści, którzy potrafią płynnie czytać kod i dokładnie szacować koszty zmian, odchodzą na emeryturę. Ci, którzy pozostali, mają jedynie częściową znajomość części portfolio. Bez metryk ilościowych szacowanie kosztów zmian zależy wyłącznie od tego, którego programistę zapytamy, a zmienność tych szacunków jest na tyle duża, że planowanie projektu staje się mało wiarygodne.
Problem skali. Typowe portfolio COBOL zawiera tysiące programów, z których wiele nie było zmienianych od lat. Żaden zespół nie jest w stanie ręcznie ocenić tysięcy programów przed rozpoczęciem programu modernizacji. Metryki, które można obliczyć automatycznie dla całego portfolio w ciągu kilku godzin, zastępują tygodnie ręcznego przeglądu.
Wymóg uzasadnienia biznesowego. Programy modernizacyjne wymagają uzasadnienia inwestycji. Kadra kierownicza zatwierdzająca wielomilionowe budżety na modernizację chce ilościowych dowodów na to, że inwestycja jest uzasadniona. Wyniki MI, wskaźniki zadłużenia technicznego wyprowadzone z MI oraz szacunki kosztów zmian, które odnoszą się do progów MI, dostarczają tych dowodów w formie, która może być przedstawiona interesariuszom nietechnicznym.
Formuła MI i jej komponenty specyficzne dla języka COBOL
Najczęściej stosowanym wzorem do obliczania wskaźnika utrzymywalności jest:
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)Ograniczona wersja Microsoftu, używana przez większość narzędzi komercyjnych, odwzorowuje to na skalę 0–100:
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Każdy komponent ma specyficzne dla COBOL-a zagadnienia.
Linie kodu w COBOL-u
Pliki źródłowe języka COBOL zawierają cztery sekcje: IDENTYFIKACJA, ŚRODOWISKO, DANE i PROCEDURA. Sekcja IDENTYFIKACJA identyfikuje program. Sekcja ŚRODOWISKO opisuje jego środowisko wykonawcze. Sekcja DANYCH definiuje jego struktury danych. Tylko sekcja PROCEDURA zawiera instrukcje wykonywalne.
Pytanie dotyczące pomiaru: czy LOC powinien uwzględniać wszystkie linie we wszystkich czterech działach, czy tylko instrukcje PROCEDURE DEVISION?
Dla celów MI, zliczanie wszystkich wierszy (w tym deklaracji danych) znacząco zwiększa LOC bez jednoczesnego wzrostu złożoności wykonania. Program w COBOL-u z 400 wierszami DATA DIVISION definiującymi układy rekordów i 100-wierszowym PROCEDURE DIVISION ma inne cechy utrzymywalności niż program ze 100 wierszami DATA DIVISION i 400-wierszowym PROCEDURE DIVISION, ale surowy LOC traktuje je identycznie.
Najlepsza praktyka: Do obliczeń MI w języku COBOL należy używać liczby instrukcji PROCEDURE DIVISION (z wyłączeniem pustych wierszy, wierszy komentarzy oraz nagłówków podziałów/sekcji/akapitów) zamiast całkowitej liczby wierszy źródłowych. Dzięki temu wartości LOC będą bardziej zbliżone do złożoności pliku wykonywalnego.
Problem z elementami składowymi COPY: instrukcje COPY uwzględniają zewnętrzne elementy źródłowe w czasie kompilacji. Instrukcja COPY, która rozszerza się do 200 wierszy definicji danych, dodaje jeden wiersz do pliku źródłowego, ale 200 wierszy do skompilowanego programu. Niektóre narzędzia zliczają logiczne LOC (rozszerzenie po kopiowaniu); inne zliczają fizyczne wiersze źródłowe. Różnica może sięgać rzędu wielkości w przypadku programów intensywnie korzystających z COPY.
Uwaga: Jeśli Twoje narzędzie MI liczy fizyczne linie źródłowe, programy z intensywnym wykorzystaniem COPY będą wydawać się mniejsze i łatwiejsze w utrzymaniu niż w rzeczywistości. Zawsze sprawdzaj, czy LOC w Twoim narzędziu jest przed, czy po rozszerzeniu kopii.
Złożoność cyklomatyczna w COBOL-u
Złożoność cyklomatyczna to metryka jakości kodu, która mierzy zrozumiałość i łatwość utrzymania kodu poprzez pomiar liczby niezależnych ścieżek w tym kodzie. W języku COBOL struktury decyzyjne tworzące niezależne ścieżki obejmują:
| COBOL Construct | Wpływ złożoności cyklomatycznej |
|---|---|
IF ... END-IF | +1 za IF |
IF ... ELSE ... END-IF | +1 za każde JEŻELI (W PRZECIWNYM WYPADKU nie dodaje innej ścieżki) |
EVALUATE ... WHEN | +1 na klauzulę WHEN |
PERFORM UNTIL condition | +1 za każdy warunek UNTIL |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 za ZMIENNE |
AT END klauzula READ | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 za każdy program obsługi wyjątków |
ON OVERFLOW / NOT ON OVERFLOW | +1 za obsługę przepełnienia |
ON SIZE ERROR | +1 na obsługę błędów rozmiaru |
88-poziomowa martwa strefa: 88-poziomowe nazwy warunków w COBOL-u tworzą warunki logiczne, które pojawiają się w instrukcjach IF i EVALUATE, ale są definiowane w DATA DIVISION. Program z dwudziestoma 88-poziomowymi warunkami, z których każdy jest przywoływany w wielu strukturach decyzyjnych, ma znacznie większą złożoność behawioralną, niż sugeruje liczba instrukcji w PROCEDURE DIVISION. Złożoność cyklomatyczna zlicza punkty decyzyjne, ale nie jest w stanie uchwycić relacji semantycznych między nazwami 88-poziomowymi a logiką, która je testuje.
WYKONAJ PRZEZ ukrytą złożoność: PERFORM SECTION-A THRU SECTION-Z Wykonuje wszystkie akapity między SEKCJĄ A a SEKCJĄ Z. Liczba akapitów i struktury decyzyjne w nich zawarte są częścią efektywnej złożoności polecenia PERFORM, ale CC obliczone na poziomie polecenia traktuje PERFORM THRU jako pojedyncza ścieżka, bez względu na to, co leży pomiędzy.
Objętość Halsteada w COBOL-u
Objętość Halsteada to miara rozmiaru i złożoności programu oparta na liczbie operatorów i operandów. W języku COBOL:
Operatorami są czasowniki i słowa kluczowe języka COBOL: PRZENIEŚ, DODAJ, ODEJMUJ, MNOŻ, DZIEL, OBLICZ, JEŻELI, PERFORM, ODCZYTAJ, ZAPIS, OTWÓRZ, ZAMKNIJ, WYWOŁAJ, PRZEJDŹ DO, OCEŃ, KIEDY itd.
Operandami są nazwy danych, literały i stałe symboliczne: elementy danych zdefiniowane w DATA DIVISION, literały numeryczne i łańcuchowe oraz stałe symboliczne języka COBOL (SPACJA, ZERA, WARTOŚCI WYSOKIE, WARTOŚCI NISKIE).
Czynnik rozwlekłości: COBOL jest znacznie bardziej rozwlekły niż współczesne języki w przypadku równoważnej logiki. Wyrażenie Java total = quantity * unitPrice * (1 - discount) to jeden wiersz z czterema operatorami i czterema operandami. Odpowiednik w COBOL-u:
kobol
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)Jest to mniej więcej równoważne w przypadku operatorów i operandów, ale rozważmy bardziej złożone obliczenie, które w Javie może wymagać trzech wierszy. W COBOL-u może to wymagać pięciu lub więcej wierszy ze względu na brak łańcuchowania wyrażeń i konieczność użycia pośrednich pól pamięci roboczej. Objętość Halsteada będzie odpowiednio wyższa w COBOL-u niż w równoważnej Javie, po prostu dlatego, że COBOL wyraża to samo obliczenie za pomocą większej liczby tokenów językowych.
Konsekwencja praktyczna: programy w COBOL-u będą miały wyższe wolumeny Halsteada niż programy w językach współczesnych o równoważnej logice. Wyższy wolumen Halsteada zmniejsza MI. Programy w COBOL-u będą zatem systematycznie uzyskiwać niższe wyniki w zakresie MI niż programy w językach współczesnych o równoważnej złożoności, nie dlatego, że są trudniejsze w utrzymaniu, ale dlatego, że COBOL jest bardziej rozbudowany składniowo.
Gdzie Standard MI zawodzi w przypadku COBOL-a: cztery ślepe punkty
Nawet poprawnie obliczona, standardowa formuła MI pomija cztery wymiary łatwości utrzymania języka COBOL, które mają istotny wpływ na rzeczywiste koszty zmian.
1. COPY Element łączący
Kopibook COBOL-a zawarty w 300 programach to zależność konserwacyjna, która wpływa na wszystkie 300 programów po wprowadzeniu w nich jakichkolwiek zmian. To sprzężenie nie pojawia się w żadnym komponencie formuły MI. Program zawierający dwadzieścia kopii ma 300 niejawnych zależności, które MI traktuje jako równoważne programowi bez kopii.
Metryka uzupełniająca: Liczba zależności elementów kopii, czyli liczba unikalnych instrukcji COPY w podziale danych programu. Programy z wysokim sprzężeniem COPY wymagają analizy wpływu przed wprowadzeniem jakichkolwiek zmian, aby zrozumieć, które inne programy korzystają z tych samych definicji copybook.
2. Fan-In (liczba wywołań)
Podprogram COBOL wywoływany przez 150 innych programów jest celem zmian wysokiego ryzyka, niezależnie od jego wartości MI. Podprogram o wysokiej łatwości utrzymania (MI = 85), wywoływany przez 150 programów, jest trudniejszy do bezpiecznej zmiany niż narzędzie o niskiej łatwości utrzymania (MI = 45), którego nikt nie wywołuje. Wzór na MI nie uwzględnia stopnia wykorzystania programu.
Metryka uzupełniająca: Fan-In, liczba odrębnych programów wywołujących dany program za pomocą CALL lub dynamicznego przydzielania. Fan-in jest głównym czynnikiem ryzyka zmian dla podprogramów, niezależnie od ich wewnętrznej złożoności.
3. Głębokość zależności JCL
Program COBOL wywoływany przez zadanie JCL, które ma piętnaście zadań zależnych, uruchamianych po nim i zależnych od jego wyników, niesie ze sobą ryzyko operacyjne całkowicie wykraczające poza zakres MI. Program o MI = 55, który działa samodzielnie, jest mniej ryzykowny w modyfikacji niż program o MI = 80, który znajduje się w centrum złożonego łańcucha zależności wsadowych.
Metryka uzupełniająca: Głębokość zależności JCL, czyli głębokość łańcucha zależności w dół łańcucha w sieci zadań JCL. Programy o dużej głębokości zależności JCL wymagają szerszego zakresu testowania dla każdej zmiany, niezależnie od ich wewnętrznego wyniku MI.
4. Inflacja martwego kodu
Martwe akapity i sekcje, czyli kod COBOL, który jest zdefiniowany, ale nigdy nie jest wywoływany przez żadną ścieżkę wykonania, zawyżają LOC i Halstead Volume, nie przyczyniając się do obciążenia konserwacyjnego kodu działającego. Program z 600 liniami martwego kodu i 200 liniami kodu działającego ma MI, który karze go za martwy kod, mimo że martwy kod nie ma znaczenia dla kosztu zmiany.
Metryka uzupełniająca: Procent martwego kodu, czyli odsetek instrukcji PROCEDURE DIVISION, które są niedostępne z żadnej ścieżki wykonania produkcyjnego. Wysokie procenty martwego kodu wskazują, że obliczone przez MI wartości LOC i Halstead Volume są znacznie zawyżone.
Kompletny zestaw metryk COBOL
Żadna pojedyncza metryka nie odzwierciedla w pełni łatwości utrzymania języka COBOL. Poniższy zestaw, stosowany łącznie, daje pełny obraz:
| metryczny | Co mierzy | Notatka specyficzna dla języka COBOL | Pierwsze użycie |
|---|---|---|---|
| Indeks łatwości utrzymania | Ogólna łatwość konserwacji (kompozyt) | Zastosuj do oświadczeń DZIAŁU PROCEDUR; zweryfikuj obsługę KOPII | Wynik jakości bazowej; ranking portfela |
| Złożoność cyklomatyczna | Liczba niezależnych ścieżek wykonania | Zawiera OCEŃ, GDY, WYKONAJ DO, NA KONIEC, WYJĄTEK | Zmiana wysiłku na program; oszacowanie liczby przypadków testowych |
| Objętość Halsteada | Obciążenie obliczeniowe (operatory + operandy) | Spodziewaj się wyższych wartości niż w przypadku równoważnych programów nauczania języków nowożytnych | Część MI; porównanie międzyprogramowe w ramach portfolio COBOL |
| KOPIA Liczba członków | Sprzęganie zależności poprzez wspólne definicje | Programy z liczbą członków COPY >15 wymagają analizy wpływu przed wprowadzeniem jakichkolwiek zmian | Klasyfikacja ryzyka zmiany |
| Fan-In (wywoływany) | Ile programów to nazywa? | Główny czynnik ryzyka zmian dla podprogramów | Sekwencjonowanie migracji; próg autoryzacji zmian |
| % martwego kodu | Procent kodu procedury nieosiągalnej | Zawyżaj LOC/HV, jeśli nie wyłączono; wyłącz z zakresu konwersji | Zmniejszenie zakresu modernizacji |
| Głębokość zależności JCL | Głębokość łańcucha zadań wsadowych w dół rzeki | Nie da się obliczyć wyłącznie na podstawie źródła COBOL; wymagana jest analiza JCL | Ryzyko zmiany operacyjnej; zakres testowania |
| Zagnieżdżona głębokość PERFORM | Maksymalny poziom zagnieżdżenia wywołań PERFORM | Głębokie zagnieżdżenie wskazuje na złożoność strukturalną nieobjętą przez CC | Priorytet refaktoryzacji |
Kalibracja progów dla COBOL-a
Standardowe progi MI pochodzą z baz kodowych języków współczesnych i nie mają bezpośredniego zastosowania w COBOL-u. Poniższa tabela porównuje standardowe progi z odpowiednikami odpowiednimi dla COBOL-a i wyjaśnia uzasadnienie dostosowania.
| Zakres oceny | Standardowa interpretacja | Interpretacja COBOL-a | racjonalne uzasadnienie |
|---|---|---|---|
| 85-100 | Bardzo łatwy w utrzymaniu | Wysoce łatwy w utrzymaniu (spójny) | Najlepsze programy COBOL mieszczą się w tym przedziale, mają czystą strukturę i odpowiedni rozmiar |
| 65-84 | Umiarkowanie łatwe w utrzymaniu | Umiarkowanie łatwe w utrzymaniu, przejrzyj sprzężenie COPY i fan-in | Standardowy próg obowiązuje, ale tutaj ważniejsze są dodatkowe wskaźniki |
| 50-64 | Słabo, konieczne refaktoryzowanie | Marginalny, oceniać w kontekście | Wiele dobrze ustrukturyzowanych programów COBOL otrzymuje tutaj punkty wyłącznie ze względu na rozwlekłość; użyj CC i fan-in, aby odróżnić rzeczywiste problemy od artefaktów składniowych |
| 25-49 | Bardzo słaba | Słaby, prawdopodobnie wysoki CC i/lub nadmierny LOC | Programy z tego zakresu niezawodnie wskazują na problemy strukturalne, a nie tylko na rozwlekłość języka COBOL |
| 0-24 | Krytyczna, główna refaktoryzacja | Krytyczne, najwyższy priorytet w zakresie naprawy lub wycofania z eksploatacji | Zgodne ze standardową interpretacją |
Kluczowe wskazówki dotyczące kalibracji: Przeprowadź analizę MI w całym portfolio COBOL przed ustawieniem progów dla poszczególnych programów. Oblicz medianę i rozstęp międzykwartylowy portfela. Ustaw próg „wymaganej uwagi” na 25. percentylu swojego portfolio, czyli programy w dolnym kwartylu konkretnej bazy kodu, a nie programy, których wyniki są niższe od progu uzyskanego z programów Java. To podejście kalibruje się samoczynnie i uwzględnia systematyczny efekt rozwlekłości w COBOL.
Wykorzystanie MI do podejmowania decyzji modernizacyjnych
Wyniki MI stają się najbardziej wartościowe, gdy wpływają na konkretne decyzje operacyjne. Oto główne zastosowania.
Sekwencjonowanie fal migracji. Programy z wysokimi wynikami MI (dobrze utrzymane, o niskiej złożoności) są najlepszymi kandydatami do wczesnych fal migracji. Są łatwiejsze do walidacji, rzadziej zawierają nieudokumentowane przypadki brzegowe i niosą ze sobą mniejsze ryzyko wystąpienia nieoczekiwanego zachowania w migrowanym środowisku. Programy z niskimi wynikami MI powinny być migrowane w późniejszych falach, po zdobyciu doświadczenia i pewności siebie przez zespół oraz po dokładnej ekstrakcji logiki biznesowej.
Priorytetyzacja konserwacji. Programy z MI poniżej 25. percentyla, które charakteryzują się również wysokim wskaźnikiem fan-in (określanym przez wiele programów) lub dużą głębokością zależności JCL, stanowią kombinację najwyższego ryzyka: strukturalnie złożone programy, od których zależy wiele innych programów. Są to programy, które najprawdopodobniej generują defekty związane ze zmianami i są najdroższe w naprawie, jeśli wystąpią. Powinny być one pierwszymi celami programu redukcji długu technicznego.
Decyzje „zbuduj czy kup”. Oceniając, czy utrzymać program COBOL długoterminowo, czy zastąpić go SaaS lub nowoczesną alternatywą, wynik MI i historia kosztów zmian stanowią ilościową podstawę do kalkulacji „zbuduj czy kup”. Program o wskaźniku MI = 30, modyfikowany piętnaście razy w ciągu ostatnich trzech lat, przy czym każda modyfikacja trwała znacznie dłużej niż szacowano, ma udokumentowane koszty utrzymania, które można porównać z kosztami wymiany.
Progi autoryzacji zmian. Niektóre organizacje wykorzystują wskaźniki MI do określania wymaganego poziomu autoryzacji zmian. Programy poniżej pewnego progu MI wymagają bardziej rygorystycznej weryfikacji, niezależnego testowania i dodatkowego zatwierdzenia przed wdrożeniem produkcyjnym. Dzięki temu powstaje proces kontroli zmian uwzględniający jakość, bez konieczności ręcznej oceny każdej zmiany.
Jednego nie potrafi MI: przewidzieć wpływu zmiany na biznes. Program z MI = 85, który wykonuje obliczenia kapitału regulacyjnego, wymaga co najmniej tyle samo testów i walidacji, co program z MI = 40, który realizuje funkcję raportowania o niskim ryzyku. MI mierzy wysiłek związany ze zmianą, a nie jej konsekwencje. Oba wymiary są niezbędne do pełnej oceny ryzyka.
W jaki sposób SMART TS XL Ustanawia i śledzi metryki utrzymywalności COBOL
Obliczenie MI dla pojedynczego programu COBOL jest proste. Dokładne obliczenie MI dla portfela tysięcy programów, uwzględnienie rozszerzenia COPY, identyfikacja martwego kodu i uzupełnienie MI o dodatkowe, pomijane metryki, wymaga zautomatyzowanej analizy na dużą skalę.
SMART TS XL'S statyczna analiza kodu oblicza pełny zestaw metryk COBOL opisany w tym przewodniku dla całego portfolio jednocześnie. Wskaźnik MI jest obliczany na podstawie liczby instrukcji PROCEDURE DIVISION, a nie całkowitej liczby wierszy źródłowych, z rozwinięciem COPY wykonywanym przed analizą, aby zapewnić prawidłowe przypisanie współdzielonych definicji danych. Złożoność cyklomatyczna uwzględnia klauzule EVALUATE WHEN, warunki PERFORM UNTIL i rozgałęzienia obsługi wyjątków, a nie tylko instrukcje IF. Objętość Halstead jest obliczana na podstawie czasowników COBOL i operandów danych w PROCEDURE DIVISION.
Co najważniejsze, SMART TS XL uzupełnia MI o metryki, których brakuje w formule. mapowanie zależności aplikacji generuje wartości fan-in, czyli tzw. „call-by counts”, dla każdego programu w portfelu, identyfikując programy wysokiego ryzyka, niezależnie od ich wyniku MI. Ekspansja JCL Funkcja ta zapewnia głębokość zależności JCL dla każdego programu, łącząc analizę MI na poziomie COBOL z kontekstem ryzyka operacyjnego, który może ujawnić tylko analiza JCL.
Funkcja identyfikacji martwego kodu w analizie wpływu oznacza akapity i sekcje, które nie zawierają ścieżek wykonywania przychodzącego, umożliwiając wykluczenie martwego kodu z obliczeń MI i dostarczając metrykę procentową martwego kodu, która określa, czy niski wynik MI programu odzwierciedla rzeczywistą złożoność czy zawyżony LOC.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w całym zbiorze danych metryk: znajdź wszystkie programy z MI poniżej 40 i fan-in powyżej 20, posortowane według głębokości zależności JCL, celów naprawczych o najwyższym priorytecie w portfolio, w jednym zapytaniu obejmującym miliony wierszy kodu COBOL. Ten możliwy do wyszukiwania inwentarz metryk stanowi podstawę dla opisanych powyżej aplikacji do priorytetyzacji konserwacji, sekwencjonowania migracji i autoryzacji zmian.
Wreszcie, wskaźnik MI śledzony w czasie i przeliczany po każdym cyklu istotnych zmian, pokazuje, czy program ulega poprawie czy pogorszeniu. SMART TS XLAnaliza jest przeprowadzana na podstawie bieżącego źródła, a nie migawek z pamięci podręcznej. Dzięki temu metryki odzwierciedlają rzeczywisty stan bazy kodu w momencie każdej analizy, a nie ocenę w danym momencie, która szybko staje się nieaktualna.
Metryki dopasowane do języka
Wskaźnik Utrzymywalności (Manuability Index) jest miarodajnym i wartościowym wskaźnikiem dla portfeli COBOL, ale tylko wtedy, gdy jest stosowany ze zrozumieniem, jak składnia COBOL-a oddziałuje na jego komponenty. Stosowanie ogólnych progów do programów COBOL daje mylące rezultaty. Uzupełnienie wskaźnika MI o pomijane metryki, takie jak sprzężenie COPY, fan-in, głębokość zależności JCL i odsetek martwego kodu, daje obraz odpowiadający rzeczywistym doświadczeniom programistów pracujących z portfelem COBOL.
Organizacje, które skutecznie wykorzystują te wskaźniki, traktują je jako punkt wyjścia do świadomej dyskusji, a nie jako ostateczny werdykt dotyczący jakości programu. Wskaźnik MI to sygnał. Warto się nim kierować, ponieważ konsekwentnie wskazuje programy, których zmiana jest kosztowna, modyfikacja ryzykowna i które warto omówić przed rozpoczęciem modernizacji. Wskaźnik MI nie może zastąpić osądu programisty czytającego kod ani analizy strukturalnej, która ujawnia zależności i logikę biznesową, których nie jest w stanie uchwycić żaden pojedynczy wskaźnik.
