קביעת מדדי אינדקס תחזוקה עבור יישומי COBOL

מדד התחזוקה (MI) הוא אחד המדדים המורכבים הנפוצים ביותר במדידת איכות תוכנה. הוא מרכז שלוש תכונות מבניות של קוד, גודל, מורכבות ונפח, לציון מספרי יחיד שחוזה כמה קשה יהיה לשנות את הקוד. עבור שפות מודרניות, הנוסחה, הספים והכלים מבוססים היטב. עבור COBOL, המצב מסובך יותר, ורוב הצוותים מיישמים את הנוסחה הגנרית ללא התאמות או נוטשים לחלוטין את המדידה הכמותית מכיוון שהציונים אינם נראים תואמים את מה שמפתחים חווים בפועל.

שתי הגישות מניבות תוצאות מטעות. יישום נוסחת MI הסטנדרטית על COBOL מבלי להבין כיצד רכיביה מתנהגים בהקשר התחבירי של COBOL מייצר ציונים המוטים באופן שיטתי באופן שגורם לתוכניות באיכות גבוהה להיראות שוליות ולתוכניות באיכות נמוכה להיראות מקובלות. נטישת המדידה מותירה לחלוטין החלטות מודרניזציה ללא הבסיס הכמותי הדרוש להן כדי להיות ניתנות להגנה בפני בעלי עניין עסקיים ולתעדף עבודות תיקון מול תיק עבודות של אלפי תוכניות.

הדרך הנכונה היא להבין מה נוסחת ה-MI מודדת ב-COBOL באופן ספציפי, היכן היא ממעיטה ומגזימה באיכות, אילו מדדים משלימים מתקנים את הנקודות העיוורות הספציפיות ל-COBOL, וכיצד לכייל ספים מול תיק העבודות בפועל ולא מול מדדים גנריים הנגזרים מבסיסי קוד בשפות מודרניות. מדריך זה מכסה את כל הארבעה, עם עומק טכני מספיק כדי ליישם תוכנית COBOL MI והדרכה מעשית מספקת כדי להשתמש בה לקבלת החלטות מודרניזציה.

נקודה אחרונה לפני המכניקה: מדד התחזוקה מנסה לתת תמונה הוליסטית של נטל התחזוקה היחסי עבור חלקים שונים של הפרויקט על ידי מיזוג סדרה של מדדים שונים. תמונה הוליסטית זו חשובה עבור תיקי COBOL דווקא משום שאף מדד יחיד אינו לוכד את התמונה המלאה. מדד התחזוקה הוא נקודת ההתחלה, לא הסיפור המלא, אלא המקום הנכון להתחיל בו.

מדוע מדידת תחזוקה חשובה יותר עבור COBOL מאשר עבור שפות מודרניות

מדידת תחזוקה בבסיס קוד של ג'אווה או פייתון בן שנתיים, שנבדק היטב ומתוחזק על ידי הצוות שכתב אותו מספקת מידע שימושי אך לעיתים רחוקות דחוף. הקוד קריא למחבריו. הלוגיקה מתועדת או ניתנת לגזירה מבדיקות. עלות השינוי מוגבלת בהיכרות של הצוות.

תיקי COBOL בתעשיות מפוקחות שונים זה מזה בשלוש דרכים שהופכות את מדידת התחזוקה הכמותית לא לנוהג איכותי אלא לצורך תפעולי.

פער הידע. רוב תוכניות ה-COBOL מכילות לוגיקה עסקית שמעולם לא תועדה רשמית. משימות אצווה שנכתבו לפני עשרות שנים מקודדות כללים שאף אחד לא זוכר. המפתחים שיכולים לקרוא את הקוד בצורה שוטפת ולהעריך את עלות השינוי במדויק פורשים. למפתחים שנותרו יש היכרות חלקית עם חלקים מהפורטפוליו. ללא מדדים כמותיים, הערכת עלות שינוי תלויה לחלוטין באיזה מפתח שואלים, והשונות בהערכות אלו גבוהה מספיק כדי להפוך את תכנון הפרויקט ללא אמין.

בעיית קנה המידה. תיק עבודות COBOL טיפוסי מכיל אלפי תוכניות, שרבות מהן לא טופלו במשך שנים. אף צוות לא יכול להעריך ידנית אלפי תוכניות לפני תחילת תוכנית מודרניזציה. מדדים שניתן לחשב באופן אוטומטי על פני כל תיק העבודות תוך שעות מחליפים שבועות של סקירה ידנית.

דרישת מקרה עסקי. תוכניות מודרניזציה דורשות הצדקת השקעה. מנהלים המאשרים תקציבי מודרניזציה של מיליוני דולרים רוצים ראיות כמותיות לכך שההשקעה מוצדקת. ציוני MI, יחסי חוב טכני הנגזרים מ-MI, והערכות עלויות שינוי המתייחסות לספי MI מספקים ראיות אלו בצורה שניתן להציג לבעלי עניין שאינם טכניים.

נוסחת 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.

שורות קוד ב-COBOL

קבצי המקור של COBOL מכילים ארבע חטיבות: זיהוי (IDENTIFICATION), סביבה (ENVIRONMENT), נתונים (DATA) ופרוצדורה (PROCEDURE). חטיבת הזיהוי (IDENTIFICATION DIVISION) מזהה את התוכנית. חטיבת הסביבה (ENVIRONMENT DIVISION) מתארת ​​את סביבת זמן הריצה שלה. חטיבת הנתונים (DATA DIVISION) מגדירה את מבני הנתונים שלה. רק חטיבת הפרוצדורות (PROCEDURE DIVISION) מכילה פקודות הפעלה (executable).

שאלת המדידה: האם LOC צריך לספור את כל השורות על פני כל ארבע החלוקות, או רק משפטי PROCEDURE DIVISION?

למטרות MI, ספירת כל השורות (כולל הצהרות נתונים) מנפחת את LOC באופן משמעותי ללא עלייה מקבילה במורכבות הביצוע. תוכנית COBOL עם 400 שורות DATA DIVISION המגדירות פריסות רשומות ו- PROCEDURE DIVISION בת 100 שורות בעלת מאפייני תחזוקה שונים מתוכנית עם 100 שורות DATA DIVISION ו- PROCEDURE DIVISION בת 400 שורות, אך LOC גולמי מתייחס אליהן באופן זהה.

שיטת עבודה מומלצת: עבור חישוב COBOL MI, השתמש במספר משפטי PROCEDURE DIVISION (לא כולל שורות ריקות, שורות הערות וכותרות חלוקה/סעיף/פסקה) במקום סך שורות המקור. פעולה זו מייצרת ערכי LOC התואמים יותר למורכבות ההפעלה.

בעיית איבר COPY: משפטי COPY כוללים איברי מקור חיצוניים בזמן הקומפילציה. משפט COPY שמתרחב ל-200 שורות של הגדרות נתונים תורם שורה אחת לקובץ המקור אך 200 שורות לתוכנית שעברה הקומפילציה. חלק מהכלים סופרים LOC לוגי (הרחבה לאחר העתקה); אחרים סופרים שורות מקור פיזיות. ההבדל יכול להיות בסדר גודל עבור תוכניות עם שימוש רב ב-COPY.

שימו לב: אם כלי ה-MI שלכם סופר קווי מקור פיזיים, תוכניות עם שימוש נרחב ב-COPY ייראו קטנות יותר וקלות יותר לתחזוקה ממה שהן באמת. ודאו תמיד האם LOC בכלי שלכם הוא הרחבה לפני או אחרי העתקה.

מורכבות ציקלומטית ב-COBOL

מורכבות ציקלומטיקה היא מדד לאיכות קוד המודד את יכולת ההבנה והתחזוקה של קוד על ידי מדידת מספר הנתיבים העצמאיים דרך קוד זה. ב-COBOL, מבני ההחלטות היוצרים נתיבים עצמאיים כוללים:

בניית COBOL	השפעה על מורכבות ציקלומטית
IF ... END-IF	+1 לכל IF
IF ... ELSE ... END-IF	+1 לכל IF (אחרת לא מוסיפה נתיב נוסף)
EVALUATE ... WHEN	+1 לכל פסוקית WHEN
PERFORM UNTIL condition	+1 לכל תנאי UNTIL
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 של COBOL יוצרים תנאים לוגיים המופיעים במשפטי IF ו- EVALUATE אך מוגדרים ב- DATA DIVISION. תוכנית עם עשרים תנאים ברמה 88, שכל אחד מהם מופנה במבני החלטה מרובים, בעלת מורכבות התנהגותית גבוהה משמעותית ממה שמציע ספירת המשפטים של PROCEDURE DIVISION. מורכבות ציקלומטיקה סופרת את נקודות ההחלטה אך אינה יכולה ללכוד את הקשרים הסמנטיים בין שמות ברמה 88 לבין הלוגיקה שבודקת אותם.

מורכבות מרומזת של PERFORM THRU: PERFORM SECTION-A THRU SECTION-Z מבצע את כל הפסקאות בין SECTION-A ל-SECTION-Z. מספר הפסקאות ומבני ההחלטות בתוכן הן חלק מהמורכבות האפקטיבית של משפט PERFORM, אך CC המחושב ברמת המשפט מטפל ב- PERFORM THRU כדרך אחת ללא קשר למה שביניהם.

נפח הלסטד ב-COBOL

Halstead Volume הוא מדד לגודל ולמורכבות של תוכנית בהתבסס על מספר האופרטורים והאופרנדים. ב-COBOL:

אופרטורים הם פעלים ומילות מפתח ב-COBOL: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN וכן הלאה.

אופרנדים הם שמות נתונים, ליטרלים וקבועים פיגורטיביים: פריטי נתונים המוגדרים ב-DATA DIVISION, ליטרלים מספריים וליטרליים מחרוזות, וקבועי COBOL פיגורטיביים (רווחים, אפסים, ערכים גבוהים, ערכים נמוכים).

גורם המלליות: COBOL מפורט באופן משמעותי יותר משפות מודרניות עבור לוגיקה מקבילה. ביטוי ג'אווה total = quantity * unitPrice * (1 - discount) היא שורה אחת עם ארבעה אופרטורים וארבעה אופרנדים. המקבילה ב-COBOL:

קובול

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

זה שווה ערך בערך באופרטורים ובאופרנדים, אבל חשבו על חישוב מורכב יותר שב-Java עשוי להשתמש בשלוש שורות. ב-COBOL ייתכן שיידרשו חמש שורות או יותר עקב היעדר שרשור ביטויים והדרישה להשתמש בשדות אחסון ביניים. נפח ה-Halstead יהיה גבוה יותר בהתאמה עבור COBOL מאשר עבור Java מקבילה פשוט משום ש-COBOL מבטא את אותו חישוב עם יותר טוקנים של שפה.

התוצאה המעשית: לתוכניות COBOL יהיו נפחי Halstead גבוהים יותר מאשר לתוכניות שפה מודרנית בעלות לוגיקה מקבילה. נפח Halstead גבוה יותר מפחית את ה-MI. לכן, לתוכניות COBOL יהיו ציון נמוך יותר באופן שיטתי ב-MI מאשר לתוכניות שפה מודרנית בעלות מורכבות מקבילה, לא משום שקשה יותר לתחזק אותן, אלא משום ש-COBOL מפורט יותר מבחינה תחבירית.

היכן ש-Standard MI נופל בקצרה לעומת COBOL: ארבע נקודות עיוורות

אפילו אם מחושב נכון, נוסחת ה-MI הסטנדרטית מפספסת ארבעה ממדים של תחזוקת COBOL שיש להם השפעה משמעותית על עלות השינוי בעולם האמיתי.

1. צימוד חבר COPY

ספר עותקים של COBOL הכלול ב-300 תוכניות הוא תלות תחזוקה המשפיעה על כל 300 התוכניות כאשר מתבצע בה שינוי כלשהו. צימוד זה אינו מופיע באף רכיב של נוסחת MI. תוכנית הכוללת עשרים ספרי עותקים מכילה 300 תלויות מרומזות ש-MI מתייחס אליהן כשוות ערך לתוכנית ללא ספרי עותקים.

מדד משלים: Copy Member Dependency Count, מספר משפטי COPY הייחודיים ב-DATA DIVISION של תוכנית. תוכניות עם צימוד COPY גבוה דורשות ניתוח השפעה לפני כל שינוי כדי להבין אילו תוכניות אחרות חולקות את אותן הגדרות ספר עותקים.

2. פאן-אין (ספירת קריאה)

תת-תוכנית COBOL שנקראת על ידי 150 תוכניות אחרות היא יעד שינוי בסיכון גבוה ללא קשר לציון ה-MI שלה. תת-תוכנית בעלת תחזוקה גבוהה (MI = 85) שנקראת על ידי 150 תוכניות קשה יותר לשינוי בטוח מאשר כלי עזר בעל תחזוקה גרועה (MI = 45) שאינו נקרא על ידי אף אחד. נוסחת ה-MI אינה מתחשבת בהיקף השימוש הנרחב בתוכנית.

מדד משלים: Fan-In, מספר התוכניות הייחודיות שקוראות לתוכנית נתונה באמצעות CALL או שיגור דינמי. Fan-in הוא המניע העיקרי לסיכון שינוי עבור תת-תוכניות ללא קשר למורכבות הפנימית שלהן.

3. עומק תלות JCL

תוכנית COBOL המופעלת על ידי משימת JCL שיש לה חמש עשרה משימות תלויות במורד הזרם, משימות הפועלות אחריה ותלויות בפלט שלה, נושאת סיכון תפעולי שאינו תחום כלל של MI. תוכנית עם MI = 55 שפועלת באופן עצמאי פחות מסוכנת לשינוי מאשר תוכנית עם MI = 80 שנמצאת במרכז שרשרת תלות מורכבת של אצווה.

מדד משלים: עומק תלות JCL, עומק שרשרת התלות במורד הזרם ברשת עבודות JCL. תוכניות עם עומק תלות JCL גבוה דורשות טווח בדיקה רחב יותר עבור כל שינוי, ללא קשר לציון ה-MI הפנימי שלהן.

4. אינפלציה של קוד מת

פסקאות וקטעים מתים, קוד COBOL שמוגדר אך מעולם לא נקרא על ידי נתיב ביצוע כלשהו, ​​מנפחים את LOC ואת נפח ה-Halstead מבלי לתרום לעומס התחזוקה של הקוד החי. לתוכנית עם 600 שורות קוד מת ו-200 שורות קוד חי יש MI שמעניש אותה על הקוד המת, למרות שהקוד המת אינו רלוונטי לעלות השינוי.

מדד משלים: אחוז קוד מת, שיעור משפטי PROCEDURE DIVISION שאינם נגישים מכל נתיב ביצוע ייצור. אחוזי קוד מת גבוהים מצביעים על כך ש-LOC ונפח האלסטד המחושבים על ידי MI מנופחים באופן משמעותי.

חבילת מדדי COBOL מלאה

אין מדד יחיד המאפשר תחזוקה של COBOL. החבילה הבאה, בשימוש משותף, מספקת תמונה מלאה:

מטרי	מה זה מודד	הערה ספציפית ל-COBOL	שימוש ראשוני
מדד תחזוקה	קלות תחזוקה כללית (קומפוזיט)	החל על משפטי PROCEDURE DIVISION; אימות טיפול ב-COPY	ציון איכות בסיסי; דירוג תיק עבודות
מורכבות סיקלומטית	מספר נתיבי ביצוע עצמאיים	כלול הערכה מתי, ביצוע עד, בסוף, בחריג	מאמץ שינוי לכל תוכנית; אומדן ספירת מקרי בדיקה
הלסטד ווליום	עומס חישובי (אופרטורים + אופרנדים)	צפו לערכים גבוהים יותר מאשר תוכנות שפה מודרניות מקבילות	חלק מ-MI; השוואה בין-תוכניות בתוך תיק העבודות של COBOL
עותק מספר חברים	צימוד תלות באמצעות הגדרות משותפות	תוכניות עם מעל 15 חברי COPY דורשות ניתוח השפעה לפני כל שינוי	שינוי סיווג סיכון
מאוורר-אין (נקרא על ידי)	כמה תוכניות קוראות לזה	הגורם העיקרי לסיכון שינוי עבור תת-תוכניות	רצף הגירה; שינוי סף הרשאה
אחוז קוד מת	אחוז קוד פרוצדורה בלתי מושג	ניפוח LOC/HV אם לא נכלל; אל תכלול את טווח ההמרה	צמצום היקף למודרניזציה
עומק תלות JCL	עומק שרשרת משימת אצווה במורד הזרם	לא ניתן לחישוב ממקור COBOL בלבד; דורש ניתוח JCL	סיכון שינוי תפעולי; היקף הבדיקה
עומק PERFORM מקונן	רמת קינון מקסימלית של קריאות PERFORM	קינון עמוק מצביע על מורכבות מבנית שלא נקלטה על ידי CC	עדיפות עיבוד מחדש

כיול סף עבור COBOL

ספי MI סטנדרטיים נגזרים מבסיסי קוד של שפות מודרניות ואינם חלים ישירות על COBOL. הטבלה שלהלן משווה ספי סטנדרטיים עם מקבילות המתאימים ל-COBOL ומסבירה את הרציונל של ההתאמה.

טווח ציונים	פרשנות סטנדרטית	פרשנות COBOL	רציונל
85-100	תחזוקה גבוהה	תחזוקה גבוהה (עקבי)	תוכניות COBOL הטובות ביותר מקבלות ציון בטווח הזה, מבנה נקי, גודל מתאים
65-84	ניתן לתחזוקה בינונית	תחזוקה בינונית, סקירת צימוד COPY ו-fan-in	סף סטנדרטי נשמר, אך מדדים משלימים חשובים יותר כאן
50-64	גרוע, נדרש שינוי פקטורינג	שולי, להעריך בהקשר	תוכניות COBOL רבות המובנות היטב מקבלות ציון כאן בזכות רמת הפירוט שלהן בלבד; השתמשו ב-CC וב-fan-in כדי להבחין בבעיות אמיתיות לבין ארטיפקטים של תחביר.
25-49	גרוע מאוד	CC נמוך, כנראה גבוה ו/או LOC מוגזם	תוכניות בטווח זה מצביעות באופן אמין על בעיות מבניות, לא רק על רמת פירוט ב-COBOL.
0-24	שינויים קריטיים ועיקריים	קריטי, עדיפות עליונה לתיקון או להשבתה	עולה בקנה אחד עם הפרשנות הסטנדרטית

הנחיות כיול מרכזיות: הפעילו את MI על פני כל תיק העבודות שלכם ב-COBOL לפני קביעת ספים ספציפיים לתוכנית. חשבו את החציון ואת הטווח הבין-רבעוני של תיק העבודות. קבעו את סף "נדרשת תשומת לב" באחוזון ה-25 של תיק העבודות שלכם, תוכניות ברבעון התחתון של בסיס הקוד הספציפי שלכם, לא תוכניות שמקבלות ציון נמוך מסף שנגזר מתוכניות Java. גישה זו מכוילת את עצמה ומתחשבת באפקט המלל השיטתי של COBOL.

שימוש ב-MI לקבלת החלטות מודרניזציה

ציוני MI הופכים בעלי ערך רב ביותר כאשר הם משפיעים על קבלת החלטות תפעוליות ספציפיות. להלן היישומים העיקריים.

ריצוף גלי מעבר. תוכניות עם ציוני MI גבוהים (מתוחזקים היטב, מורכבות נמוכה) הן המועמדות הטובות ביותר לגלי מעבר מוקדמים. הן קלות יותר לאימות, פחות סבירות להכיל מקרי קצה לא מתועדים, ונושאות סיכון נמוך יותר לייצר התנהגות בלתי צפויה בסביבה שעברה מעבר. תוכניות עם ציוני MI נמוכים צריכות לעבור מעבר בגלים מאוחרים יותר, לאחר שהצוות בנה ניסיון וביטחון, ולאחר חילוץ יסודי של לוגיקה עסקית.

קביעת סדרי עדיפויות לתחזוקה. תוכניות עם MI מתחת לאחוזון ה-25, שהן גם בעלות תלות גבוהה ב-fan-in (הנקראת על ידי תוכניות רבות) או עומק תלות גבוה ב-JCL, מייצגות את השילוב בעל הסיכון הגבוה ביותר: תוכניות מורכבות מבחינה מבנית שתוכניות רבות אחרות תלויות בהן. אלו הן התוכניות בעלות הסבירות הגבוהה ביותר לייצר פגמים הקשורים לשינוי והיקרות ביותר לתיקון כאשר הן כאלה. הן צריכות להיות המטרות הראשונות של תוכנית להפחתת חוב טכני.

החלטות של בנייה לעומת קנייה. כאשר מעריכים האם לתחזק תוכנית COBOL לטווח ארוך או להחליפה ב-SaaS או בחלופה מודרנית, ציון ה-MI והיסטוריית עלויות השינויים מספקים את הבסיס הכמותי לחישוב הבנייה לעומת הקנייה. תוכנית עם MI = 30, ששונתה חמש עשרה פעמים בשלוש השנים האחרונות, כאשר כל שינוי אורך זמן רב משמעותית מהמשוער, בעלת עלות תחזוקה מתועדת שניתן להשוות אותה לעלות ההחלפה.

ספי הרשאת שינויים. ארגונים מסוימים משתמשים בציוני MI כדי לקבוע את רמת הרשאת השינויים הנדרשת. תוכניות מתחת לסף MI מסוים דורשות סקירה קפדנית יותר, בדיקות עצמאיות ואישור נוסף לפני פריסת הייצור. זה יוצר תהליך בקרת שינויים מודע לאיכות מבלי לדרוש הערכה ידנית של כל שינוי.

הדבר היחיד שהערכה רגולטרית (MI) לא יכולה לעשות: לחזות את ההשפעה העסקית של שינוי. תוכנית עם MI = 85 שמבצעת חישובי הון רגולטורי דורשת לפחות אותה כמות של בדיקות ותיקוף כמו תוכנית עם MI = 40 שמבצעת פונקציית דיווח בעלת סיכון נמוך. MI מודד את מאמץ השינוי, לא את תוצאות השינוי. שני הממדים נדרשים להערכת סיכונים מלאה.

איך SMART TS XL קובע ועוקב אחר מדדי תחזוקה של COBOL

חישוב ערך מדויק (MI) עבור תוכנית COBOL אחת הוא פשוט. חישובו המדויק עבור תיק עבודות של אלפי תוכניות, תוך התחשבות בהרחבת COPY, זיהוי קוד מת והשלמת ערך מדויק עם המדדים הנוספים שהוא מפספס, דורש ניתוח אוטומטי בקנה מידה גדול.

SMART TS XL"S ניתוח קוד סטטי מחשב את חבילת המדדים המלאה של COBOL המתוארת במדריך זה על פני כל תיק העבודות בו זמנית. MI מחושב באמצעות ספירות משפטי PROCEDURE DIVISION ולא באמצעות סך שורות המקור, כאשר הרחבת COPY מבוצעת לפני הניתוח כדי להבטיח שהגדרות נתונים משותפות מיוחסות כהלכה. מורכבות Cyclomatic מתחשבת בפסקאות EVALUATE WHEN, תנאי PERFORM UNTIL וענפי טיפול בחריגים, ולא רק במשפטי IF. נפח Halstead מחושב מפעלי COBOL ואופרנדים של נתונים ב- PROCEDURE DIVISION.

באופן חיוני, SMART TS XL משלים את ה-MI עם המדדים שהנוסחה מפספסת. מיפוי תלות יישומים מייצר את ערכי המאוורר, מונה ספירות, עבור כל תוכנית בתיק, ומזהה תוכניות בסיכון גבוה ללא קשר לציון ה-MI שלהן. הרחבת JCL היכולת מספקת את עומק התלות של JCL עבור כל תוכנית, ומחברת את ניתוח MI ברמת COBOL להקשר של הסיכון התפעולי שרק ניתוח JCL יכול לחשוף.

זיהוי קוד מת מיכולת ניתוח ההשפעה מסמן פסקאות וסעיפים ללא נתיבי ביצוע נכנסים, מה שמאפשר את הכללת קוד מת מחישוב ה-MI ומספק את מדד אחוז הקוד המת שקובע האם ציון ה-MI הנמוך של תוכנית משקף מורכבות אמיתית או LOC מנופח.

יכולת החיפוש הארגוני הופכת את מערך הנתונים המלא של המדדים לניתן לשאילתה: מצא את כל התוכניות עם MI מתחת ל-40 ו-fan-in מעל 20, ממוינות לפי עומק תלות JCL, יעדי התיקון בעלי העדיפות הגבוהה ביותר בתיק, בשאילתה אחת על פני מיליוני שורות של COBOL. מלאי מדדים זה הניתן לשאילתה הוא הבסיס לתעדוף התחזוקה, רצף ההעברה ואישור השינויים שתוארו לעיל.

לבסוף, מדד המיקוד (MI) שמנוקב לאורך זמן, ומחושב מחדש לאחר כל מחזור שינוי משמעותי, מראה האם התוכנית משתפרת או מתדרדרת. SMART TS XLהניתוח של מופעל על המקור הנוכחי ולא על תמונות מצב המאוחסנות במטמון, מה שמבטיח שהמדדים משקפים את המצב בפועל של בסיס הקוד בזמן כל ניתוח ולא הערכה נקודתית בזמן שפוגעת.

מדדים התואמים את השפה

מדד התחזוקה הוא מדד תקף ובעל ערך עבור תיקי COBOL, אך רק כאשר הוא מיושם תוך הבנה של האופן שבו המאפיינים התחביריים של COBOL מקיימים אינטראקציה עם רכיביו. החלת ספים גנריים על תוכניות COBOL מניבה תוצאות מטעות. השלמת מדד התחזוקה עם המדדים שהוא מפספס, כמו צימוד COPY, fan-in, עומק תלויות JCL ואחוז קוד מת, מייצרת תמונה התואמת את מה שמפתחים חווים בפועל בעת עבודה בתיק COBOL.

הארגונים המשתמשים במדדים אלה ביעילות הם אלה שמתייחסים אליהם כנקודת מוצא לשיחה מושכלת, ולא כפסק דין סופי על איכות התוכנית. ציון MI הוא איתות. האות שווה לעקוב אחריו, הוא מצביע בעקביות על התוכניות שיקרות לשינוי, מסוכנות לשינוי, ושווה לטפל בהן לפני תחילת המודרניזציה. מה ש-MI לא יכול לעשות הוא להחליף את שיקול הדעת של מפתח שקורא את הקוד, או להחליף את הניתוח המבני שחושף את התלות וההיגיון העסקי שאף מדד בודד לא יכול ללכוד.