COBOL Uygulamaları için Bakım Kolaylığı Endeksi Ölçütlerinin Oluşturulması

Bakım Kolaylığı Endeksi (MI), yazılım kalitesi ölçümünde en yaygın kullanılan bileşik metriklerden biridir. Kodun üç yapısal özelliğini (boyut, karmaşıklık ve hacim) tek bir sayısal puana dönüştürerek kodun değiştirilmesinin ne kadar zor olacağını tahmin eder. Modern diller için formül, eşikler ve araçlar iyi bir şekilde belirlenmiştir. COBOL için durum daha karmaşıktır ve çoğu ekip ya genel formülü ayarlama yapmadan uygular ya da puanlar geliştiricilerin gerçekte deneyimledikleriyle örtüşmediği için nicel ölçümü tamamen terk eder.

Her iki yaklaşım da yanıltıcı sonuçlar doğurur. COBOL'un sözdizimsel bağlamında bileşenlerinin nasıl davrandığını anlamadan standart MI formülünü COBOL'a uygulamak, yüksek kaliteli programların marjinal, düşük kaliteli programların ise kabul edilebilir görünmesine neden olan sistematik olarak yanlı puanlar üretir. Ölçümü tamamen terk etmek, modernizasyon kararlarını, iş paydaşlarına karşı savunulabilir olmaları ve binlerce programdan oluşan bir portföyde iyileştirme çalışmalarını önceliklendirmeleri için gereken nicel temelden yoksun bırakır.

Doğru yol, MI formülünün COBOL'da özellikle neyi ölçtüğünü, kaliteyi nerede hafife aldığını ve nerede abarttığını, COBOL'a özgü kör noktalarını düzelten ek ölçütlerin neler olduğunu ve eşik değerlerini modern dil kod tabanlarından türetilen genel kıyaslama ölçütlerine göre değil, gerçek portföyünüze göre nasıl kalibre edeceğinizi anlamaktır. Bu kılavuz, bir COBOL MI programı uygulamak için yeterli teknik derinlik ve modernizasyon kararları için kullanmak üzere yeterli pratik rehberlik ile bu dört konuyu da kapsamaktadır.

Mekanik detaylara geçmeden önce son bir nokta: Bakım Kolaylığı Endeksi, bir dizi farklı ölçütü bir araya getirerek bir projenin farklı bölümlerinin göreceli bakım yüküne ilişkin bütünsel bir bakış açısı sunmaya çalışır. Bu bütünsel bakış açısı, COBOL portföyleri için değerlidir çünkü hiçbir tek ölçüt resmin tamamını yansıtmaz. Bakım Kolaylığı Endeksi başlangıç ​​noktasıdır, hikayenin tamamı değil, ancak başlamak için doğru yerdir.

Bakım Kolaylığı Ölçümünün COBOL İçin Modern Dillerden Daha Önemli Olmasının Sebebi

İki yıllık, iyi test edilmiş ve kodu yazan ekip tarafından sürdürülen bir Java veya Python kod tabanında sürdürülebilirliği ölçmek faydalı bilgiler sağlar ancak nadiren acil bir durumdur. Kod, yazarları için okunabilirdir. Mantık belgelenmiştir veya testlerden türetilebilir. Değişiklik maliyeti, ekibin aşinalığıyla sınırlıdır.

Düzenlemeye tabi sektörlerdeki COBOL portföyleri, nicel sürdürülebilirlik ölçümünü bir kalite uygulaması değil, operasyonel bir zorunluluk haline getiren üç açıdan farklılık gösterir.

Bilgi açığı. COBOL kodlarının çoğu, resmi olarak belgelenmemiş iş mantığı içeriyor. On yıllar önce yazılmış toplu işler, kimsenin hatırlamadığı kuralları kodluyor. Kodu akıcı bir şekilde okuyabilen ve değişiklik maliyetini doğru bir şekilde tahmin edebilen geliştiriciler emekli oluyor. Kalan geliştiriciler ise portföyün bazı bölümlerine kısmen aşina. Nicel ölçütler olmadan, değişiklik maliyeti tahmini tamamen hangi geliştiriciye sorduğunuza bağlıdır ve bu tahminlerdeki değişkenlik, proje planlamasını güvenilmez hale getirecek kadar yüksektir.

Ölçek sorunu. Tipik bir COBOL portföyü, çoğu yıllardır dokunulmamış binlerce program içerir. Hiçbir ekip, modernizasyon programı başlamadan önce binlerce programı manuel olarak değerlendiremez. Haftalarca süren manuel incelemenin yerini, tüm portföy genelinde saatler içinde otomatik olarak hesaplanabilen ölçümler alır.

İş gerekçesi gerekliliği. Modernizasyon programları yatırım gerekçelendirmesi gerektirir. Milyonlarca dolarlık modernizasyon bütçelerini onaylayan yöneticiler, yatırımın haklı olduğuna dair nicel kanıt isterler. MI puanları, MI'dan türetilen teknik borç oranları ve MI eşiklerine atıfta bulunan değişim maliyeti tahminleri, bu kanıtı teknik olmayan paydaşlara sunulabilecek bir biçimde sağlar.

MI Formülü ve COBOL'a Özgü Bileşenleri

Bakım kolaylığı endeksini hesaplamak için en yaygın kullanılan formül şöyledir:

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

Çoğu ticari araç tarafından kullanılan Microsoft'un sınırlı varyantı, bunu 0-100 ölçeğine eşler:

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

Her bir bileşenin COBOL ile ilgili özel hususları vardır.

COBOL'da Kod Satırları

COBOL kaynak dosyaları dört bölümden oluşur: TANIMLAMA, ORTAM, VERİ ve PROSEDÜR. TANIMLAMA BÖLÜMÜ programı tanımlar. ORTAM BÖLÜMÜ çalışma ortamını açıklar. VERİ BÖLÜMÜ veri yapılarını tanımlar. Yalnızca PROSEDÜR BÖLÜMÜ yürütülebilir ifadeler içerir.

Ölçüm sorusu: LOC, dört bölümün tamamındaki tüm satırları mı saymalı, yoksa yalnızca PROSEDÜR BÖLÜMÜ ifadelerini mi?

MI amaçları için, tüm satırları (veri bildirimleri dahil) saymak, yürütme karmaşıklığında karşılık gelen bir artış olmaksızın satır sayısını önemli ölçüde artırır. Kayıt düzenlerini tanımlayan 400 DATA DIVISION satırı ve 100 satırlık bir PROCEDURE DIVISION içeren bir COBOL programının, 100 DATA DIVISION satırı ve 400 satırlık bir PROCEDURE DIVISION içeren bir programdan farklı bakım kolaylığı özellikleri vardır, ancak ham satır sayısı bunları aynı şekilde ele alır.

En iyi uygulama: COBOL MI hesaplaması için, toplam kaynak satır sayısı yerine PROCEDURE DIVISION ifadesinin sayısını (boş satırlar, yorum satırları ve bölüm/kesit/paragraf başlıkları hariç) kullanın. Bu, yürütülebilir karmaşıklığa daha yakın LOC değerleri üretir.

COPY üye problemi: COPY ifadeleri, derleme zamanında harici kaynak üyelerini içerir. 200 satırlık veri tanımlarına genişleyen bir COPY ifadesi, kaynak dosyasına bir satır, derlenmiş programa ise 200 satır katkıda bulunur. Bazı araçlar mantıksal satır sayısını (kopyalama sonrası genişleme) sayarken, diğerleri fiziksel kaynak satırlarını sayar. Yoğun COPY kullanımı olan programlar için bu fark bir büyüklük mertebesinde olabilir.

Dikkat: Eğer MI aracınız fiziksel kaynak satırlarını sayıyorsa, yoğun COPY kullanımı olan programlar gerçekte olduklarından daha küçük ve bakımı daha kolay görünecektir. Aracınızdaki LOC'nin COPY genişletmesinden önce mi yoksa sonra mı hesaplandığını her zaman doğrulayın.

COBOL'da Döngüsel Karmaşıklık

Döngüsel Karmaşıklık, bir kodda yer alan bağımsız yolların sayısını ölçerek kodun anlaşılabilirliğini ve sürdürülebilirliğini ölçen bir kod kalitesi ölçütüdür. COBOL'da bağımsız yollar oluşturan karar yapıları şunlardır:

COBOL Construct	Döngüsel Karmaşıklık Etkisi
IF ... END-IF	+1 her IF için
IF ... ELSE ... END-IF	+1 her IF için (ELSE başka bir yol eklemez)
EVALUATE ... WHEN	+1, her WHEN maddesi için
PERFORM UNTIL condition	+1, "UNTIL" koşulu başına
PERFORM VARYING ... WITH TEST BEFORE/AFTER	+1 değişken başına
AT END OKUMA maddesi	+1
ON EXCEPTION / NOT ON EXCEPTION	+1 istisna işleyici başına
ON OVERFLOW / NOT ON OVERFLOW	taşma işleyici başına +1
ON SIZE ERROR	+1 boyut başına hata işleyici

88 seviyeli kör nokta: COBOL'un 88 seviyeli koşul adları, IF ve EVALUATE ifadelerinde görünen ancak DATA DIVISION'da tanımlanan mantıksal koşullar oluşturur. Her biri birden fazla karar yapısında referans alınan yirmi adet 88 seviyeli koşula sahip bir program, PROCEDURE DIVISION'ın ifade sayısının gösterdiğinden önemli ölçüde daha fazla davranışsal karmaşıklığa sahiptir. Döngüsel Karmaşıklık, karar noktalarını sayar ancak 88 seviyeli adlar ile bunları test eden mantık arasındaki anlamsal ilişkileri yakalayamaz.

Örtük karmaşıklık yoluyla performans sergilemek: PERFORM SECTION-A THRU SECTION-Z SECTION-A ve SECTION-Z arasındaki tüm paragrafları yürütür. Paragraf sayısı ve içlerindeki karar yapıları, PERFORM ifadesinin etkin karmaşıklığının bir parçasıdır, ancak ifade düzeyinde hesaplanan CC, PERFORM THRU Arada ne olursa olsun, tek bir yol olarak.

COBOL'da Halstead Hacmi

Halstead Hacmi, programın operatör ve işlenen sayısına bağlı olarak boyutunu ve karmaşıklığını ölçen bir birimdir. COBOL'da:

Operatörler , COBOL fiilleri ve anahtar kelimeleridir: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN ve benzerleri.

İşlenenler veri adları, değişmez değerler ve mecazi sabitlerdir: DATA DIVISION'da tanımlanan veri öğeleri, sayısal ve dize değişmez değerleri ve COBOL mecazi sabitleri (BOŞLUKLAR, SIFIRLAR, YÜKSEK DEĞERLER, DÜŞÜK DEĞERLER).

Sözcük zenginliği faktörü: COBOL, eşdeğer mantık için modern dillere göre önemli ölçüde daha ayrıntılıdır. Bir Java ifadesi total = quantity * unitPrice * (1 - discount) Dört operatör ve dört işlenen içeren tek bir satırdır. COBOL karşılığı:

COBOL

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

Bu, operatörler ve işlenenler açısından kabaca eşdeğerdir, ancak Java'da üç satırda halledilebilecek daha karmaşık bir hesaplamayı düşünün. COBOL'da, ifade zincirleme eksikliği ve ara çalışma alanı alanlarının kullanılması gerekliliği nedeniyle beş veya daha fazla satır gerekebilir. COBOL'un aynı hesaplamayı daha fazla dil belirteciyle ifade etmesi nedeniyle, Halstead Hacmi, eşdeğer Java'ya göre COBOL için buna bağlı olarak daha yüksek olacaktır.

Pratik sonuç şu: COBOL programları, eşdeğer mantığa sahip modern dil programlarından daha yüksek Halstead Hacmine sahip olacaktır. Daha yüksek Halstead Hacmi, MI'yı azaltır. Bu nedenle COBOL programları, bakımı daha zor olduğu için değil, COBOL'un sözdizimsel olarak daha ayrıntılı olduğu için, eşdeğer karmaşıklığa sahip modern dil programlarından sistematik olarak daha düşük MI puanı alacaktır.

COBOL İçin Standart MI'ın Yetersiz Kaldığı Noktalar: Dört Kör Nokta

Doğru hesaplansa bile, standart MI formülü, gerçek dünyadaki değişiklik maliyetini önemli ölçüde etkileyen COBOL'un sürdürülebilirliğinin dört boyutunu gözden kaçırmaktadır.

1. KOPYA Üye Bağlantısı

300 program tarafından dahil edilen bir COBOL copybook'u, üzerinde herhangi bir değişiklik yapıldığında tüm 300 programı etkileyen bir bakım bağımlılığıdır. Bu bağlantı, MI formülünün hiçbir bileşeninde görünmez. Yirmi copybook içeren bir programın, MI'ın copybook içermeyen bir programa eşdeğer olarak ele aldığı 300 örtük bağımlılığı vardır.

Ek ölçüt: Kopyalama Üyesi Bağımlılık Sayısı, bir programın DATA DIVISION'ındaki benzersiz COPY ifadelerinin sayısı. Yüksek COPY bağımlılığına sahip programlar, aynı copybook tanımlarını hangi diğer programların paylaştığını anlamak için herhangi bir değişiklikten önce etki analizi gerektirir.

2. Taraftar Katılımı (Sayı Tarafından Çağrılan)

150 farklı program tarafından çağrılan bir COBOL alt programı, MI puanından bağımsız olarak yüksek riskli bir değişiklik hedefidir. 150 program tarafından çağrılan, yüksek bakım kolaylığına sahip (MI = 85) bir alt programı, hiç kimse tarafından çağrılmayan, düşük bakım kolaylığına sahip (MI = 45) bir yardımcı programdan daha güvenli bir şekilde değiştirmek zordur. MI formülü, bir programın ne kadar yaygın kullanıldığını dikkate almaz.

Ek ölçüt: Fan-In, belirli bir programı CALL veya dinamik dağıtım yoluyla çağıran farklı programların sayısı. Fan-in, alt programların içsel karmaşıklığından bağımsız olarak, değişiklik riskinin birincil belirleyicisidir.

3. JCL Bağımlılık Derinliği

On beş adet bağımlı alt işe sahip, yani kendisinden sonra çalışan ve çıktısına bağlı olan bir JCL işi tarafından çağrılan bir COBOL programı, MI'nin kapsamı dışında kalan operasyonel riskler taşır. Bağımsız olarak çalışan MI = 55 değerine sahip bir programı değiştirmek, karmaşık bir toplu işlem bağımlılık zincirinin merkezinde yer alan MI = 80 değerine sahip bir programı değiştirmekten daha az risklidir.

Ek ölçüt: JCL Bağımlılık Derinliği, JCL iş ağındaki aşağı yönlü bağımlılık zincirinin derinliği. Yüksek JCL bağımlılık derinliğine sahip programlar, dahili MI puanlarından bağımsız olarak, herhangi bir değişiklik için daha geniş bir test kapsamı gerektirir.

4. Ölü Kod Enflasyonu

Ölü paragraflar ve bölümler, tanımlanmış ancak hiçbir yürütme yolu tarafından çağrılmayan COBOL kodları, canlı kodun bakım yüküne katkıda bulunmadan satır sayısını ve Halstead hacmini şişirir. 600 satır ölü kod ve 200 satır canlı kod içeren bir program, ölü kodun değişiklik maliyetiyle ilgisi olmamasına rağmen, ölü kod nedeniyle cezalandıran bir MI'ya sahiptir.

Ek ölçüt: Ölü Kod Yüzdesi, herhangi bir üretim yürütme yolundan erişilemeyen PROCEDURE DIVISION ifadelerinin oranı. Yüksek ölü kod yüzdeleri, MI tarafından hesaplanan LOC ve Halstead Hacminin önemli ölçüde şişirilmiş olduğunu gösterir.

Eksiksiz bir COBOL Metrik Paketi

COBOL'un bakım kolaylığını tek bir ölçütle ifade etmek mümkün değildir. Aşağıdaki ölçütler birlikte kullanıldığında eksiksiz bir tablo sunar:

metrik	Ne Ölçer?	COBOL'a Özgü Not	Birincil kullanım
Sürdürülebilirlik Endeksi	Genel bakım kolaylığı (kompozit)	PROSEDÜR BÖLÜMÜ bildirimlerine uygulayın; KOPYA işleminin doğruluğunu teyit edin.	Temel kalite puanı; portföy sıralaması
Siklomatik Karmaşıklık	Bağımsız yürütme yollarının sayısı	"DEĞERLENDİRME NE ZAMAN, PERFORMANS ŞEKLİNE KADAR, SONUNDA, İSTİSNAİ DURUMLARDA" ifadelerini ekleyin.	Program başına değişim çabası; test senaryosu sayısı tahmini
Halstead Cilt	Hesaplama yükü (operatörler + işlenenler)	Eşdeğer modern dil programlarına kıyasla daha yüksek değerler bekleyin.	MI'ın bir parçası; COBOL portföyü içindeki programlar arası karşılaştırma.
Üye Sayısı KOPYALA	Paylaşılan tanımlar aracılığıyla bağımlılık bağlantısı	15'ten fazla COPY üyesi olan programlarda, herhangi bir değişiklik yapılmadan önce etki analizi yapılması gerekmektedir.	Risk sınıflandırmasında değişiklik
Hayran Tarafından Çağrılan	Bu programa kaç tane bu isim veriliyor?	Alt programlar için değişim riskinin temel etkeni	Göç sıralaması; yetkilendirme eşiğinin değiştirilmesi
Ölü Kod %	Ulaşılamayan işlem kodu yüzdesi	Hariç tutulmamışsa LOC/HV'yi şişirin; dönüştürme kapsamından hariç tutun.	Modernizasyon için kapsam daraltma
JCL Bağımlılık Derinliği	Aşağı akış toplu iş zinciri derinliği	Yalnızca COBOL kaynak kodundan hesaplanamaz; JCL analizi gerektirir.	Operasyonel değişiklik riski; test kapsamı
İç içe PERFORM Derinliği	PERFORM çağrılarının maksimum iç içe geçme seviyesi	Derin iç içe geçme, CC tarafından yakalanamayan yapısal karmaşıklığı gösterir.	Yeniden düzenleme önceliği

COBOL için Eşik Kalibrasyonu

Standart MI eşikleri, modern dil kod tabanlarından türetilmiştir ve doğrudan COBOL'a uygulanmaz. Aşağıdaki tablo, standart eşikleri COBOL'a uygun eşdeğerleriyle karşılaştırır ve ayarlama gerekçesini açıklar.

Skor Aralığı	Standart Yorumlama	COBOL Yorumu	gerekçe
85-100	Bakımı son derece kolay	Son derece sürdürülebilir (tutarlı)	En iyi COBOL programları bu aralıkta puan alır: temiz yapı, uygun boyut.
65-84	Orta derecede bakımı kolay	Orta derecede sürdürülebilir, COPY bağlantısını ve fan-in'i gözden geçirin.	Standart eşik değeri geçerli, ancak burada ek ölçütler daha önemli.
50-64	Kötü, yeniden yapılandırma gerekiyor.	Sınırda, bağlam içinde değerlendirin	İyi yapılandırılmış birçok COBOL programı, yalnızca ayrıntılı anlatımları sayesinde burada yüksek puan alır; gerçek sorunları sözdizimi hatalarından ayırt etmek için CC ve fan-in kullanın.
25-49	Çok kötü	Zayıf, muhtemelen yüksek CC ve/veya aşırı LOC	Bu aralıktaki programlar, yalnızca COBOL'un aşırı sözcük kullanımından değil, yapısal sorunlardan da güvenilir bir şekilde bahseder.
0-24	Kritik, büyük çaplı yeniden yapılandırma	Kritik, iyileştirme veya devre dışı bırakma için en yüksek öncelik	Standart yorumla tutarlı

Temel kalibrasyon kılavuzu: Program özel eşiklerini belirlemeden önce tüm COBOL portföyünüzde MI'yı çalıştırın. Portföy medyanını ve çeyrekler arası aralığını hesaplayın. "Dikkat gerektiren" eşiğinizi, kendi portföyünüzün 25. yüzdelik diliminde, yani belirli kod tabanınızın en alt çeyreğinde yer alan programlarda belirleyin; Java programlarından türetilen bir eşiğin altında puan alan programları değil. Bu yaklaşım kendi kendini kalibre eder ve sistematik COBOL sözcük bolluğu etkisini hesaba katar.

Modernizasyon Kararlarında Yönetim Bilgilerinin Kullanımı

MI puanları, belirli operasyonel kararları bilgilendirdikleri zaman en değerli hale gelir. İşte başlıca uygulama alanları.

Geçiş dalgası sıralaması. Yüksek MI puanına sahip programlar (iyi bakımlı, düşük karmaşıklık) erken geçiş dalgaları için en iyi adaylardır. Doğrulama işlemleri daha kolaydır, belgelenmemiş uç durumlar içerme olasılıkları daha düşüktür ve geçiş yapılan ortamda beklenmedik davranışlar üretme riski daha azdır. Düşük MI puanına sahip programlar, ekip deneyim ve güven kazandıktan ve kapsamlı iş mantığı çıkarımından sonra, daha sonraki dalgalarda geçiş yapmalıdır.

Bakım önceliklendirmesi. MI değeri 25. yüzdelik dilimin altında olan ve aynı zamanda yüksek fan-in (birçok program tarafından bu şekilde adlandırılır) veya yüksek JCL bağımlılık derinliğine sahip programlar, en yüksek risk kombinasyonunu temsil eder: birçok başka programın bağlı olduğu yapısal olarak karmaşık programlar. Bunlar, değişiklik kaynaklı hatalar üretme olasılığı en yüksek ve ürettiklerinde düzeltilmesi en pahalı olan programlardır. Teknik borç azaltma programının ilk hedefleri bunlar olmalıdır.

Geliştirme mi, satın alma mı kararları. Bir COBOL programını uzun vadede sürdürmenin mi yoksa SaaS veya modern bir alternatifle değiştirmenin mi daha mantıklı olduğuna karar verirken, MI puanı ve değişiklik maliyeti geçmişi, geliştirme mi, satın alma mı hesaplaması için nicel bir temel sağlar. MI = 30 olan, son üç yılda on beş kez değiştirilen ve her değişikliğin tahmin edilenden önemli ölçüde daha uzun sürdüğü bir programın, değiştirme maliyetiyle karşılaştırılabilen belgelenmiş bir bakım maliyeti vardır.

Değişiklik yetkilendirme eşikleri. Bazı kuruluşlar, gerekli değişiklik yetkilendirme düzeyini belirlemek için MI puanlarını kullanır. Belirli bir MI eşiğinin altındaki programlar, üretim ortamına dağıtımdan önce daha titiz bir inceleme, bağımsız test ve ek onay gerektirir. Bu, her değişikliğin manuel olarak değerlendirilmesini gerektirmeden, kalite odaklı bir değişiklik kontrol süreci oluşturur.

MI'ın yapamayacağı tek şey: bir değişikliğin işletme üzerindeki etkisini tahmin etmek. Düzenleyici sermaye hesaplamaları yapan MI = 85'lik bir program, düşük riskli bir raporlama işlevi gerçekleştiren MI = 40'lık bir program kadar test ve doğrulama gerektirir. MI, değişimin sonucunu değil, değişim çabasını ölçer. Tam bir risk değerlendirmesi için her iki boyut da gereklidir.

Ne kadar SMART TS XL COBOL Bakım Kolaylığı Ölçütlerini Oluşturur ve Takip Eder

Tek bir COBOL programı için MI hesaplamak basittir. Ancak, COPY genişlemesini hesaba katarak, ölü kodu belirleyerek ve MI'yı eksik olan ek metriklerle tamamlayarak, binlerce programdan oluşan bir portföy için doğru bir şekilde hesaplamak, büyük ölçekli otomatik analiz gerektirir.

SMART TS XL'S statik kod analizi Bu kılavuzda açıklanan tüm COBOL metrik paketini, tüm portföy genelinde eş zamanlı olarak hesaplar. MI, toplam kaynak satırları yerine PROCEDURE DIVISION ifade sayımları kullanılarak hesaplanır ve paylaşılan veri tanımlarının doğru şekilde atfedilmesini sağlamak için analizden önce COPY genişletmesi gerçekleştirilir. Döngüsel Karmaşıklık, yalnızca IF ifadelerini değil, EVALUATE WHEN yan tümcelerini, PERFORM UNTIL koşullarını ve istisna işleyici dallarını da hesaba katar. Halstead Hacmi, PROCEDURE DIVISION'daki COBOL fiillerinden ve veri işlenenlerinden hesaplanır.

En önemlisi, SMART TS XL MI, formülün eksik bıraktığı ölçütlerle tamamlayıcı niteliktedir. uygulama bağımlılık eşlemesi Portföydeki her program için katılım değerlerini ve arama sayılarını üretir ve MI puanlarından bağımsız olarak yüksek riskli programları belirler. JCL genişlemesi Bu özellik, her program için JCL bağımlılık derinliğini sağlar ve COBOL düzeyindeki MI analizini, yalnızca JCL analizinin ortaya çıkarabileceği operasyonel risk bağlamına bağlar.

Etki analizi özelliğinden gelen ölü kod tanımlaması, gelen yürütme yolu olmayan paragrafları ve bölümleri işaretleyerek, ölü kodun MI hesaplamasından hariç tutulmasını sağlar ve bir programın düşük MI puanının gerçek karmaşıklığı mı yoksa şişirilmiş satır sayısını mı yansıttığını belirleyen ölü kod yüzdesi ölçütünü sunar.

Kurumsal arama özelliği, tüm metrik veri setini sorgulanabilir hale getirir: milyonlarca satır COBOL kodu arasında tek bir sorguyla, JCL bağımlılık derinliğine göre sıralanmış, portföydeki en yüksek öncelikli düzeltme hedeflerini içeren, MI değeri 40'ın altında ve fan-in değeri 20'nin üzerinde olan tüm programları bulun. Bu sorgulanabilir metrik envanteri, yukarıda açıklanan bakım önceliklendirme, geçiş sıralaması ve değişiklik yetkilendirme uygulamalarının temelini oluşturur.

Son olarak, zaman içinde izlenen ve her önemli değişim döngüsünden sonra yeniden hesaplanan MI, programın iyileşip iyileşmediğini veya kötüleşip kötüleşmediğini gösterir. SMART TS XLAnaliz, önbelleğe alınmış anlık görüntüler yerine mevcut kaynak kod üzerinde çalıştırılır; bu da ölçümlerin, zaman içinde güncelliğini yitiren anlık bir değerlendirme yerine, her analiz anındaki kod tabanının gerçek durumunu yansıtmasını sağlar.

Dile Uygun Ölçütler

Bakım Kolaylığı Endeksi, COBOL portföyleri için geçerli ve değerli bir ölçüttür, ancak yalnızca COBOL'un sözdizimsel özelliklerinin bileşenleriyle nasıl etkileşim kurduğunun anlaşılmasıyla uygulandığında işe yarar. COBOL programlarına genel eşikler uygulamak yanıltıcı sonuçlar doğurur. Bakım Kolaylığı Endeksini eksik bıraktığı ölçütlerle (COPY bağımlılığı, fan-in, JCL bağımlılık derinliği, ölü kod yüzdesi) desteklemek, geliştiricilerin bir COBOL portföyünde çalışırken gerçekte deneyimledikleriyle örtüşen bir tablo ortaya çıkarır.

Bu ölçütleri etkili bir şekilde kullanan kuruluşlar, bunları program kalitesi hakkında nihai bir karar olarak değil, bilinçli bir konuşmanın başlangıç ​​noktası olarak ele alanlardır. MI puanı bir sinyaldir. Bu sinyal takip edilmeye değerdir; sürekli olarak değiştirilmesi pahalı, modifiye edilmesi riskli ve modernizasyon başlamadan önce ele alınması gereken programlara işaret eder. MI'ın yapamayacağı şey ise, kodu okuyan bir geliştiricinin yargısının yerini almak veya tek bir ölçütle yakalanamayan bağımlılıkları ve iş mantığını ortaya koyan yapısal analizin yerini almaktır.