وضع مقاييس مؤشر قابلية الصيانة لتطبيقات COBOL

يُعدّ مؤشر قابلية الصيانة (MI) أحد أكثر المقاييس المركبة استخدامًا في قياس جودة البرمجيات. فهو يُلخّص ثلاث خصائص هيكلية للكود، وهي الحجم والتعقيد والحجم الكلي، في قيمة رقمية واحدة تُنبئ بمدى صعوبة تغيير الكود. بالنسبة للغات البرمجة الحديثة، فإنّ الصيغة والحدود والأدوات المستخدمة راسخة. أما بالنسبة للغة كوبول، فالوضع أكثر تعقيدًا، حيث تُطبّق معظم الفرق الصيغة العامة دون تعديل، أو تتخلى تمامًا عن القياس الكمي لأنّ النتائج لا تُعكس ما يواجهه المطورون فعليًا.

كلا النهجين يُنتجان نتائج مُضللة. فتطبيق صيغة MI القياسية على لغة COBOL دون فهم كيفية عمل مكوناتها ضمن سياقها النحوي يُنتج نتائج متحيزة بشكل منهجي، تجعل البرامج عالية الجودة تبدو هامشية، والبرامج منخفضة الجودة تبدو مقبولة. أما التخلي عن القياس تمامًا فيُفقد قرارات التحديث الأساس الكمي اللازم لتبريرها أمام أصحاب المصلحة في الأعمال، ولتحديد أولويات أعمال الإصلاح في مجموعة تضم آلاف البرامج.

المسار الصحيح هو فهم ما تقيسه صيغة مؤشر الإدارة (MI) في لغة كوبول تحديدًا، ومواضع قصورها في تقدير الجودة، والمقاييس التكميلية التي تُصحح نقاط ضعفها الخاصة بلغة كوبول، وكيفية معايرة العتبات بناءً على محفظتك الفعلية بدلًا من المعايير العامة المستمدة من قواعد بيانات لغات البرمجة الحديثة. يغطي هذا الدليل الجوانب الأربعة جميعها، مع شرح تقني كافٍ لتنفيذ برنامج مؤشر إدارة بلغة كوبول، وإرشادات عملية كافية لاستخدامه في قرارات التحديث.

قبل الخوض في التفاصيل التقنية، تجدر الإشارة إلى نقطة أخيرة: يسعى مؤشر قابلية الصيانة إلى تقديم نظرة شاملة على عبء الصيانة النسبي لمختلف أقسام المشروع، وذلك من خلال دمج سلسلة من المقاييس المختلفة. وتكتسب هذه النظرة الشاملة أهمية خاصة لمحفظات مشاريع COBOL، تحديدًا لأن أي مقياس بمفرده لا يُغطي الصورة الكاملة. يُعدّ مؤشر قابلية الصيانة نقطة انطلاق، وليس الصورة الكاملة، ولكنه المكان الأمثل للبدء.

لماذا يُعدّ قياس قابلية الصيانة أكثر أهمية للغة كوبول منه للغات الحديثة؟

يُعدّ قياس قابلية الصيانة في قاعدة بيانات برمجية بلغة جافا أو بايثون عمرها سنتان، ومُختبرة جيدًا، ويتولى صيانتها الفريق الذي كتبها، أمرًا مفيدًا، ولكنه نادرًا ما يكون عاجلًا. فالكود واضحٌ لمطوريه، ومنطقه موثق أو يمكن استنتاجه من الاختبارات، وتكلفة التغيير محدودة بمدى إلمام الفريق به.

تختلف محافظ COBOL في الصناعات الخاضعة للتنظيم بثلاث طرق تجعل قياس قابلية الصيانة الكمية ليس ممارسة جودة بل ضرورة تشغيلية.

فجوة المعرفة. تحتوي معظم برامج كوبول على منطق أعمال لم يُوثّق رسميًا. وتُشفّر وظائف الدفعات المكتوبة منذ عقود قواعد لم يعد أحد يتذكرها. يتقاعد المطورون القادرون على قراءة الشفرة بطلاقة وتقدير تكلفة التغيير بدقة. أما المطورون المتبقون، فمعرفتهم بأجزاء من البرنامج محدودة. وبدون مقاييس كمية، يعتمد تقدير تكلفة التغيير كليًا على المطور الذي تسأله، والتفاوت في هذه التقديرات كبير لدرجة تجعل تخطيط المشاريع غير موثوق.

مشكلة الحجم. تحتوي محفظة برامج COBOL النموذجية على آلاف البرامج، لم يُجرَ تحديث العديد منها منذ سنوات. لا يمكن لأي فريق تقييم آلاف البرامج يدويًا قبل بدء برنامج التحديث. لذا، فإن المقاييس التي يمكن حسابها تلقائيًا عبر المحفظة بأكملها في غضون ساعات تُغني عن أسابيع من المراجعة اليدوية.

متطلب دراسة الجدوى. تتطلب برامج التحديث تبريراً للاستثمار. يرغب المسؤولون التنفيذيون الذين يوافقون على ميزانيات التحديث التي تبلغ ملايين الدولارات في الحصول على أدلة كمية تثبت جدوى الاستثمار. توفر نتائج مؤشر الإدارة، ونسب الديون التقنية المستمدة منه، وتقديرات تكلفة التغيير التي تشير إلى عتبات مؤشر الإدارة، هذه الأدلة بشكل يمكن عرضه على أصحاب المصلحة غير المتخصصين تقنياً.

صيغة MI ومكوناتها الخاصة بلغة COBOL

الصيغة الأكثر شيوعًا لحساب مؤشر قابلية الصيانة هي:

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

تقوم النسخة المحدودة من مايكروسوفت، المستخدمة في معظم الأدوات التجارية، بربط هذا بمقياس من 0 إلى 100:

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

لكل مكون اعتبارات محددة ذات صلة بلغة كوبول.

أسطر من التعليمات البرمجية في لغة كوبول

تحتوي ملفات مصدر COBOL على أربعة أقسام: التعريف، والبيئة، والبيانات، والإجراءات. يُعرّف قسم التعريف البرنامج. ويصف قسم البيئة بيئة تشغيله. ويُعرّف قسم البيانات هياكل بياناته. أما قسم الإجراءات فهو القسم الوحيد الذي يحتوي على التعليمات القابلة للتنفيذ.

سؤال القياس: هل يجب على LOC حساب جميع الأسطر عبر الأقسام الأربعة جميعها، أم فقط عبارات PROCEDURE DIVISION؟

لأغراض إدارة المعلومات، يؤدي حساب جميع الأسطر (بما في ذلك تعريفات البيانات) إلى زيادة كبيرة في عدد الأسطر البرمجية دون زيادة مقابلة في تعقيد التنفيذ. يختلف برنامج COBOL الذي يحتوي على 400 سطر من قسم البيانات (DATA DIVISION) لتحديد تخطيطات السجلات و100 سطر من قسم الإجراءات (PROCEDURE DIVISION) في خصائص قابلية الصيانة عن برنامج يحتوي على 100 سطر من قسم البيانات و400 سطر من قسم الإجراءات، ولكن يتم التعامل معهما بنفس الطريقة باستخدام عدد الأسطر البرمجية الخام.

أفضل الممارسات: لحساب مؤشر تعقيد COBOL، استخدم عدد عبارات PROCEDURE DIVISION (باستثناء الأسطر الفارغة، وأسطر التعليقات، وعناوين الأقسام/الفقرات) بدلاً من إجمالي أسطر المصدر. ينتج عن ذلك قيم LOC تتوافق بشكل أدق مع تعقيد البرنامج القابل للتنفيذ.

مشكلة أعضاء COPY: تتضمن عبارات COPY أعضاءً من مصادر خارجية أثناء الترجمة. عبارة COPY التي تتوسع إلى 200 سطر من تعريفات البيانات تُضيف سطرًا واحدًا إلى ملف المصدر، ولكنها تُضيف 200 سطر إلى البرنامج المُترجم. بعض الأدوات تحسب عدد أسطر الكود المنطقية (بعد التوسع بعد النسخ)؛ بينما تحسب أدوات أخرى أسطر المصدر الفعلية. قد يصل الفرق إلى عشرة أضعاف في البرامج التي تستخدم COPY بكثرة.

انتبه: إذا كانت أداة إدارة المعلومات لديك تحسب أسطر المصدر الفعلية، فستبدو البرامج التي تستخدم النسخ بكثرة أصغر حجمًا وأسهل صيانة مما هي عليه في الواقع. تحقق دائمًا مما إذا كان عدد أسطر الكود في أداتك قبل أو بعد توسيع النسخ.

التعقيد الحلقي في لغة كوبول

التعقيد الحلقي هو مقياس لجودة الكود يقيس مدى سهولة فهم الكود وصيانته من خلال قياس عدد المسارات المستقلة داخله. في لغة كوبول، تتضمن هياكل القرار التي تُنشئ مسارات مستقلة ما يلي:

بناء COBOL	تأثير التعقيد الحلقي
IF ... END-IF	+1 لكل IF
IF ... ELSE ... END-IF	+1 لكل شرط IF (وإلا فلن يضيف مسارًا آخر)
EVALUATE ... WHEN	+1 لكل شرط WHEN
PERFORM UNTIL condition	+1 لكل شرط حتى
PERFORM VARYING ... WITH TEST BEFORE/AFTER	+1 لكل متغير
AT END بند القراءة	+1
ON EXCEPTION / NOT ON EXCEPTION	+1 لكل معالج استثناء
ON OVERFLOW / NOT ON OVERFLOW	+1 لكل معالج تجاوز السعة
ON SIZE ERROR	معالج أخطاء +1 لكل حجم

نقطة الضعف في مستوى 88: تُنشئ أسماء الشروط في لغة كوبول، والمُصنّفة ضمن مستوى 88، شروطًا منطقية تظهر في عبارات IF وEVALUATE، ولكنها مُعرّفة في قسم البيانات (DATA DIVISION). يحتوي برنامجٌ على عشرين شرطًا من مستوى 88، يُشار إلى كلٍّ منها في هياكل قرار متعددة، على تعقيد سلوكي أكبر بكثير مما يُشير إليه عدد عبارات قسم الإجراءات (PROCEDURE DIVISION). يُحصي التعقيد الحلقي نقاط القرار، ولكنه لا يستطيع استيعاب العلاقات الدلالية بين أسماء مستوى 88 والمنطق الذي يختبرها.

الأداء من خلال التعقيد الضمني: PERFORM SECTION-A THRU SECTION-Z ينفذ جميع الفقرات بين القسم أ والقسم ز. يُعد عدد الفقرات، وهياكل القرارات داخلها، جزءًا من التعقيد الفعلي لعبارة PERFORM، ولكن يتم حساب CC على مستوى العبارة. PERFORM THRU كمسار واحد بغض النظر عما يقع بينه.

حجم هالستيد في لغة كوبول

يُعدّ حجم هالستيد مقياسًا لحجم البرنامج وتعقيده بناءً على عدد المعاملات والمُعاملات. في لغة كوبول:

العوامل هي أفعال وكلمات رئيسية في لغة COBOL: MOVE، ADD، SUBTRACT، MULTIPLY، DIVIDE، COMPUTE، IF، PERFORM، READ، WRITE، OPEN، CLOSE، CALL، GO TO، EVALUATE، WHEN، وما إلى ذلك.

المعاملات هي أسماء البيانات والقيم الحرفية والثوابت التصويرية: عناصر البيانات المحددة في قسم البيانات، والقيم الحرفية الرقمية والنصية، والثوابت التصويرية في لغة كوبول (المسافات، والأصفار، والقيم العالية، والقيم المنخفضة).

عامل الإسهاب: تُعد لغة كوبول أكثر إسهاباً بشكل ملحوظ من اللغات الحديثة التي تُقدم منطقاً مكافئاً. مثال على تعبير جافا: total = quantity * unitPrice * (1 - discount) هو سطر واحد يحتوي على أربعة عوامل تشغيل وأربعة معاملات. المكافئ في لغة كوبول:

كوبول

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

هذا مكافئ تقريبًا من حيث المعاملات والمتغيرات، ولكن لنفترض عملية حسابية أكثر تعقيدًا قد تتطلب ثلاثة أسطر في جافا. في كوبول، قد تتطلب خمسة أسطر أو أكثر نظرًا لعدم وجود تسلسل للتعبيرات وضرورة استخدام حقول تخزين وسيطة. وبالتالي، سيكون حجم هالستيد أعلى في كوبول مقارنةً بجافا المكافئة، ببساطة لأن كوبول تعبر عن نفس العملية الحسابية بعدد أكبر من رموز اللغة.

النتيجة العملية: ستكون لبرامج كوبول أحجام هالستيد أعلى من برامج اللغات الحديثة ذات المنطق المكافئ. يؤدي ارتفاع حجم هالستيد إلى تقليل مؤشر المعلومات. وبالتالي، ستحصل برامج كوبول بشكل منهجي على درجات أقل في مؤشر المعلومات من برامج اللغات الحديثة ذات التعقيد المكافئ، ليس لصعوبة صيانتها، بل لأن كوبول أكثر إسهابًا من الناحية التركيبية.

أوجه قصور لغة MI القياسية مقارنةً بلغة COBOL: أربع نقاط ضعف

حتى عند حسابها بشكل صحيح، فإن صيغة MI القياسية تغفل أربعة أبعاد لقابلية صيانة COBOL والتي لها تأثير كبير على تكلفة التغيير في العالم الحقيقي.

1. نسخ اقتران الأعضاء

يُعدّ ملف COBOL المُضمّن في 300 برنامج تبعية صيانة تؤثر على جميع هذه البرامج عند إجراء أي تغيير عليه. لا يظهر هذا الارتباط في أيٍّ من مكونات صيغة MI. البرنامج الذي يتضمن 300 ملفًا يحتوي على 300 تبعية ضمنية، تُعاملها MI على أنها مكافئة لبرنامج لا يحتوي على أي ملفات.

مقياس إضافي: عدد تبعيات أعضاء النسخ، وهو عدد عبارات النسخ الفريدة في قسم البيانات الخاص بالبرنامج. تتطلب البرامج ذات الترابط العالي بين عبارات النسخ تحليلًا للأثر قبل أي تغيير لفهم البرامج الأخرى التي تشترك في نفس تعريفات دفتر النسخ.

2. قرعة المشجعين (يتم الإعلان عنها بالعد)

يُعتبر برنامج فرعي مكتوب بلغة كوبول، يتم استدعاؤه من قِبل 150 برنامجًا آخر، هدفًا عالي المخاطر للتغيير بغض النظر عن درجة مؤشر الصيانة (MI). فبرنامج فرعي سهل الصيانة (MI = 85) يتم استدعاؤه من قِبل 150 برنامجًا، يصعب تغييره بأمان مقارنةً ببرنامج فرعي ضعيف الصيانة (MI = 45) لا يتم استدعاؤه من قِبل أي برنامج. ولا تأخذ صيغة مؤشر الصيانة (MI) في الحسبان مدى انتشار استخدام البرنامج.

مقياس إضافي: عدد البرامج الفرعية التي تستدعي برنامجًا معينًا عبر استدعاء البرنامج (CALL) أو الإرسال الديناميكي. يُعدّ عدد البرامج الفرعية العامل الرئيسي في تحديد مخاطر التغيير للبرامج الفرعية بغض النظر عن تعقيدها الداخلي.

3. عمق تبعية JCL

ينطوي برنامج COBOL الذي يتم استدعاؤه بواسطة مهمة JCL، والتي تعتمد على خمس عشرة مهمة لاحقة (أي مهام تُنفذ بعده وتعتمد على مخرجاته)، على مخاطر تشغيلية تقع خارج نطاق MI تمامًا. فبرنامج ذو MI = 55 يعمل بشكل مستقل يكون تعديله أقل خطورة من تعديل برنامج ذي MI = 80 يقع في مركز سلسلة تبعية معقدة للدفعات.

مقياس إضافي: عمق التبعية في لغة التحكم في الوظائف (JCL)، وهو عمق سلسلة التبعية في شبكة وظائف JCL. تتطلب البرامج ذات عمق التبعية العالي في JCL نطاق اختبار أوسع لأي تغيير، بغض النظر عن درجة MI الداخلية الخاصة بها.

4. تضخم الكود الميت

تؤدي الفقرات والأقسام غير المستخدمة، وهي أكواد COBOL المُعرّفة ولكن لا يتم استدعاؤها في أي مسار تنفيذي، إلى زيادة عدد أسطر التعليمات البرمجية وحجم بيانات Halstead دون المساهمة في عبء صيانة التعليمات البرمجية النشطة. فعلى سبيل المثال، يحتوي برنامج على 600 سطر من التعليمات البرمجية غير المستخدمة و200 سطر من التعليمات البرمجية النشطة على مؤشر أداء يُعاقبه على التعليمات البرمجية غير المستخدمة، على الرغم من أن هذه التعليمات غير ذات صلة بتكلفة التغيير.

مقياس إضافي: نسبة التعليمات البرمجية غير المستخدمة، وهي نسبة عبارات قسم الإجراءات التي لا يمكن الوصول إليها من أي مسار تنفيذ إنتاجي. تشير النسب المرتفعة للتعليمات البرمجية غير المستخدمة إلى أن عدد أسطر التعليمات البرمجية المحسوبة بواسطة MI وحجم Halstead مبالغ فيهما بشكل كبير.

مجموعة كاملة من مقاييس COBOL

لا يوجد مقياس واحد يقيس قابلية صيانة لغة كوبول. توفر المجموعة التالية، عند استخدامها معًا، صورة كاملة:

متري	ما يقيسه	ملاحظة خاصة بلغة كوبول	الاستخدام الأساسي
مؤشر الصيانة	سهولة الصيانة بشكل عام (مركب)	ينطبق على بيانات قسم الإجراءات؛ تحقق من معالجة النسخ	درجة الجودة الأساسية؛ تصنيف المحفظة
التعقيد السيكلوماتيكي	عدد مسارات التنفيذ المستقلة	يتضمن التقييم عند، والتنفيذ حتى، وفي النهاية، وعند الاستثناء	تغيير الجهد المبذول لكل برنامج؛ تقدير عدد حالات الاختبار
مجلد هالستيد	الحمل الحسابي (المعاملات + العمليات الحسابية)	توقع قيمًا أعلى من برامج اللغات الحديثة المماثلة	جزء من MI؛ مقارنة البرامج ضمن مجموعة COBOL
عدد الأعضاء (نسخة)	الترابط التبعي من خلال التعريفات المشتركة	تتطلب البرامج التي تضم أكثر من 15 عضوًا في فريق النسخ إجراء تحليل للأثر قبل أي تغيير.	تغيير تصنيف المخاطر
فان-إن (يُدعى بواسطة)	كم عدد البرامج التي تسمي هذا البرنامج؟	المحرك الرئيسي لمخاطر التغيير في البرامج الفرعية	تسلسل الترحيل؛ تغيير عتبة التفويض
رمز ميت %	نسبة رمز الإجراء غير القابل للوصول	قم بزيادة قيمة LOC/HV إذا لم يتم استبعادها؛ واستبعدها من نطاق التحويل	تقليص نطاق التحديث
عمق تبعية JCL	عمق سلسلة وظائف الدفعة النهائية	لا يمكن حسابها من مصدر COBOL وحده؛ تتطلب تحليل JCL	مخاطر التغيير التشغيلي؛ نطاق الاختبار
عمق الأداء المتداخل	أقصى مستوى تداخل لنداءات PERFORM	يشير التداخل العميق إلى تعقيد هيكلي لا يمكن رصده بواسطة CC	أولوية إعادة الهيكلة

معايرة العتبة لـ COBOL

تُستمد عتبات MI القياسية من قواعد بيانات لغات البرمجة الحديثة، ولا تنطبق مباشرةً على لغة كوبول. يقارن الجدول أدناه العتبات القياسية مع ما يُقابلها في لغة كوبول، ويشرح الأساس المنطقي للتعديل.

نطاق النقاط	التفسير القياسي	تفسير لغة كوبول	المنطق
85-100	سهولة الصيانة العالية	قابل للصيانة بدرجة عالية (متسق)	أفضل برامج COBOL تحقق نتائج ضمن هذا النطاق، وتتميز ببنية نظيفة وحجم مناسب.
65-84	صيانة متوسطة	يمكن صيانتها بشكل معتدل، راجع اقتران النسخ ووحدة التغذية الراجعة	لا يزال المعيار القياسي ساريًا، لكن المقاييس التكميلية أكثر أهمية هنا.
50-64	ضعيف، يحتاج إلى إعادة هيكلة	هامشي، يُقيّم في السياق	تُسجّل العديد من برامج COBOL جيدة البنية درجات عالية هنا بسبب الإسهاب وحده؛ استخدم CC و fan-in للتمييز بين المشاكل الحقيقية وآثار بناء الجملة
25-49	سيئة للغاية	ضعف، وربما ارتفاع في معدل الإصابة بالسرطان و/أو فقدان مفرط للوعي	تشير البرامج في هذا النطاق بشكل موثوق إلى وجود مشاكل هيكلية، وليس مجرد إسهاب في لغة كوبول.
0-24	إعادة هيكلة رئيسية وحاسمة	أمر بالغ الأهمية، وله أولوية قصوى للمعالجة أو الإلغاء	بما يتوافق مع التفسير القياسي

إرشادات المعايرة الأساسية: قم بتشغيل أداة MI على جميع برامج COBOL الخاصة بك قبل تحديد عتبات خاصة بكل برنامج. احسب الوسيط والمدى الربيعي للبرامج. حدد عتبة "الاهتمام المطلوب" عند النسبة المئوية 25 من برامجك، أي البرامج التي تقع في الربع الأدنى من قاعدة التعليمات البرمجية الخاصة بك، وليس البرامج التي تقل نتائجها عن عتبة مستمدة من برامج Java. هذه الطريقة ذاتية المعايرة وتراعي تأثير الإسهاب المنهجي في COBOL.

استخدام المعلومات الإدارية في قرارات التحديث

تكتسب نتائج مؤشر المعلومات المتعددة أهميتها القصوى عندما تُستخدم في اتخاذ قرارات تشغيلية محددة. فيما يلي التطبيقات الرئيسية.

تسلسل مراحل الترحيل. تُعدّ البرامج ذات درجات مؤشر الترحيل العالية (التي تتميز بصيانتها الجيدة وانخفاض تعقيدها) الخيار الأمثل لمراحل الترحيل المبكرة. فهي أسهل في التحقق من صحتها، وأقل عرضةً لاحتواء حالات استثنائية غير موثقة، وأقل عرضةً لظهور سلوك غير متوقع في بيئة الترحيل. أما البرامج ذات درجات مؤشر الترحيل المنخفضة، فينبغي ترحيلها في مراحل لاحقة، بعد أن يكتسب الفريق الخبرة والثقة، وبعد استخلاص منطق العمل بشكل كامل.

تحديد أولويات الصيانة. تمثل البرامج التي يقل مؤشر الصيانة فيها عن النسبة المئوية الخامسة والعشرين، والتي تتميز أيضًا بكثرة استدعائها من قبل العديد من البرامج الأخرى، أو بكثرة اعتمادها على لغة التحكم في الوظائف (JCL)، المجموعة الأكثر خطورة: برامج معقدة هيكليًا تعتمد عليها العديد من البرامج الأخرى. هذه البرامج هي الأكثر عرضة لإنتاج عيوب مرتبطة بالتغييرات، والأكثر تكلفة في معالجتها عند حدوث ذلك. لذا، ينبغي أن تكون هذه البرامج هي الهدف الأول لبرنامج تقليل الديون التقنية.

قرارات التطوير مقابل الشراء. عند تقييم ما إذا كان من الأفضل الاحتفاظ ببرنامج COBOL على المدى الطويل أو استبداله ببرنامج SaaS أو بديل حديث، فإنّ مؤشر MI وسجل تكلفة التغيير يوفران الأساس الكمي لحساب خيار التطوير مقابل الشراء. على سبيل المثال، برنامج بمؤشر MI يساوي 30، تم تعديله خمس عشرة مرة خلال السنوات الثلاث الماضية، واستغرق كل تعديل وقتًا أطول بكثير من المتوقع، لديه تكلفة صيانة موثقة يمكن مقارنتها بتكلفة الاستبدال.

عتبات تفويض التغيير. تستخدم بعض المؤسسات مؤشرات الأداء الرئيسية لتحديد مستوى تفويض التغيير المطلوب. تتطلب البرامج التي تقل عن عتبة معينة من مؤشرات الأداء الرئيسية مراجعة أكثر دقة، واختبارًا مستقلًا، وموافقة إضافية قبل نشرها في بيئة الإنتاج. وهذا يُنشئ عملية تحكم في التغيير تراعي الجودة دون الحاجة إلى تقييم يدوي لكل تغيير.

الشيء الوحيد الذي لا تستطيع مؤشرات الإدارة فعله هو التنبؤ بتأثير التغيير على الأعمال. فبرنامجٌ ذو مؤشر إدارة يساوي 85، يُجري حسابات رأس المال التنظيمي، يحتاج إلى قدرٍ من الاختبار والتحقق لا يقل عن قدر برنامجٍ ذي مؤشر إدارة يساوي 40، يؤدي وظيفة إعداد تقارير ذات أهمية منخفضة. يقيس مؤشر الإدارة جهد التغيير، لا نتائجه. وكلا البُعدين ضروريان لإجراء تقييم شامل للمخاطر.

كيفية SMART TS XL يُنشئ ويتتبع مقاييس قابلية صيانة لغة كوبول

يُعد حساب مؤشر الأداء الرئيسي لبرنامج COBOL واحد أمرًا بسيطًا. أما حسابه بدقة لمجموعة من آلاف البرامج، مع مراعاة توسيع COPY، وتحديد التعليمات البرمجية غير المستخدمة، واستكمال مؤشر الأداء الرئيسي بالمقاييس الإضافية التي يغفلها، فيتطلب تحليلًا آليًا على نطاق واسع.

SMART TS XLالصورة تحليل الكود الثابت يحسب هذا البرنامج مجموعة مقاييس COBOL الكاملة الموضحة في هذا الدليل عبر المحفظة بأكملها في آنٍ واحد. يتم حساب مؤشر MI باستخدام عدد عبارات PROCEDURE DIVISION بدلاً من إجمالي أسطر المصدر، مع إجراء توسيع COPY قبل التحليل لضمان إسناد تعريفات البيانات المشتركة بشكل صحيح. يأخذ التعقيد الحلقي في الاعتبار عبارات EVALUATE WHEN وشروط PERFORM UNTIL وفروع معالجة الاستثناءات، وليس فقط عبارات IF. يتم حساب حجم Halstead من أفعال COBOL ومعاملات البيانات في PROCEDURE DIVISION.

بشكل حاسم ، SMART TS XL يُكمّل مؤشر كتلة الجسم بالمقاييس التي تغفلها الصيغة. رسم خرائط تبعية التطبيق يُنتج هذا التقرير قيم عدد المستفيدين، أي عدد المكالمات الواردة، لكل برنامج في المحفظة، مما يُحدد البرامج عالية المخاطر بغض النظر عن درجة مؤشر الإدارة (MI) الخاصة بها. توسيع JCL توفر هذه الإمكانية عمق تبعية JCL لكل برنامج، مما يربط تحليل MI على مستوى COBOL بسياق المخاطر التشغيلية الذي لا يمكن الكشف عنه إلا من خلال تحليل JCL.

تحديد التعليمات البرمجية الميتة من خلال إمكانية تحليل التأثير يحدد الفقرات والأقسام التي لا تحتوي على مسارات تنفيذ واردة، مما يتيح استبعاد التعليمات البرمجية الميتة من حساب MI ويوفر مقياس النسبة المئوية للتعليمات البرمجية الميتة الذي يحدد ما إذا كانت درجة MI المنخفضة للبرنامج تعكس تعقيدًا حقيقيًا أو تضخمًا في عدد أسطر التعليمات البرمجية.

تتيح إمكانية البحث المؤسسي إمكانية الاستعلام عن مجموعة بيانات المقاييس الكاملة: حيث يمكنك العثور على جميع البرامج التي يقل مؤشر المقاييس فيها عن 40 وعدد عمليات الربط فيها عن 20، مرتبةً حسب عمق تبعية لغة التحكم في الوظائف (JCL)، بالإضافة إلى أهداف المعالجة ذات الأولوية القصوى في المحفظة، وذلك من خلال استعلام واحد عبر ملايين أسطر لغة كوبول. ويُعدّ مخزون المقاييس القابل للاستعلام هذا أساسًا لتطبيقات تحديد أولويات الصيانة، وتسلسل الترحيل، وتفويض التغييرات المذكورة أعلاه.

وأخيرًا، تُظهر المعلومات المتبادلة التي يتم تتبعها بمرور الوقت، والتي يتم إعادة حسابها بعد كل دورة تغيير كبيرة، ما إذا كان البرنامج يتحسن أم يتدهور. SMART TS XLيتم تشغيل تحليل 's على المصدر الحالي بدلاً من اللقطات المخزنة مؤقتًا، مما يضمن أن المقاييس تعكس الحالة الفعلية لقاعدة التعليمات البرمجية في وقت كل تحليل بدلاً من تقييم نقطة زمنية معينة يصبح قديمًا.

مقاييس تتناسب مع اللغة

يُعدّ مؤشر قابلية الصيانة مقياسًا صالحًا وقيمًا لمحفظات برامج COBOL، ولكن فقط عند تطبيقه مع فهم كيفية تفاعل خصائص COBOL النحوية مع مكوناتها. إن تطبيق عتبات عامة على برامج COBOL يُنتج نتائج مُضللة. إن استكمال مؤشر قابلية الصيانة بالمقاييس التي يغفلها، مثل اقتران النسخ، وعدد المداخل، وعمق تبعية JCL، ونسبة التعليمات البرمجية غير المستخدمة، يُعطي صورةً تُطابق ما يُواجهه المطورون فعليًا عند العمل على محفظة برامج COBOL.

المنظمات التي تستخدم هذه المقاييس بفعالية هي تلك التي تتعامل معها كنقطة انطلاق لحوارٍ بنّاء، لا كحكمٍ نهائي على جودة البرنامج. يُعدّ مؤشر الأداء الرئيسي (MI) إشارةً جديرة بالمتابعة، إذ يُشير باستمرار إلى البرامج التي تُكلّف تغييرها مبالغ طائلة، وتُشكّل مخاطرةً عند تعديلها، وتستحقّ المعالجة قبل البدء بالتحديث. ما لا يُمكن لمؤشر الأداء الرئيسي (MI) فعله هو أن يحلّ محلّ حكم المطوّر الذي يقرأ الشفرة، أو أن يحلّ محلّ التحليل الهيكلي الذي يكشف عن التبعيات ومنطق العمل الذي لا يُمكن لأيّ مقياسٍ بمفرده رصده.