L'indice di manutenibilità (MI) è una delle metriche composite più utilizzate nella misurazione della qualità del software. Riassume tre proprietà strutturali del codice – dimensione, complessità e volume – in un unico punteggio numerico che prevede la difficoltà di modifica del codice. Per i linguaggi moderni, la formula, le soglie e gli strumenti sono ben consolidati. Per il COBOL, la situazione è più complessa e la maggior parte dei team applica la formula generica senza modifiche oppure abbandona completamente la misurazione quantitativa perché i punteggi non sembrano corrispondere all'esperienza reale degli sviluppatori.
Entrambi gli approcci producono risultati fuorvianti. Applicare la formula standard di misurazione dell'efficienza (MI) al COBOL senza comprenderne il comportamento dei componenti nel contesto sintattico del COBOL genera punteggi sistematicamente distorti, che fanno apparire marginali i programmi di alta qualità e accettabili quelli di bassa qualità. Abbandonare completamente la misurazione priva le decisioni di modernizzazione del fondamento quantitativo necessario per essere giustificabili agli stakeholder aziendali e per dare priorità agli interventi di correzione in un portfolio di migliaia di programmi.
Ottieni un quadro completo delle metriche COBOL
SMART TS XL Classifica simultaneamente ogni programma COBOL in base a complessità, fan-in e profondità delle dipendenze JCL.
Maggiori InformazioniLa strada corretta consiste nel comprendere cosa misura la formula MI nello specifico in COBOL, dove sottostima e sovrastima la qualità, quali metriche supplementari correggono i suoi punti deboli specifici per COBOL e come calibrare le soglie in base al proprio portfolio effettivo anziché a benchmark generici derivati da codebase di linguaggi moderni. Questa guida copre tutti e quattro questi aspetti, con un livello di approfondimento tecnico sufficiente per implementare un programma MI per COBOL e con sufficienti indicazioni pratiche per utilizzarlo nelle decisioni di modernizzazione.
Un'ultima considerazione prima di passare agli aspetti tecnici: l'Indice di Manutenibilità (Maintenability Index, MI) cerca di fornire una visione olistica del carico di manutenzione relativo per le diverse sezioni di un progetto, combinando una serie di metriche differenti. Questa visione olistica è preziosa per i portfolio COBOL proprio perché nessuna singola metrica è in grado di fornire un quadro completo. Il MI è il punto di partenza, non la storia completa, ma il punto di partenza ideale.
Perché la misurazione della manutenibilità è più importante per COBOL che per i linguaggi moderni
Misurare la manutenibilità di una codebase Java o Python vecchia di due anni, ben testata e gestita dal team che l'ha scritta, fornisce informazioni utili ma raramente è urgente. Il codice è leggibile per i suoi autori. La logica è documentata o derivabile dai test. Il costo delle modifiche è limitato dalla familiarità del team con il codice.
I portfolio COBOL nei settori regolamentati si distinguono per tre aspetti che rendono la misurazione quantitativa della manutenibilità non una pratica di qualità, bensì una necessità operativa.
La lacuna di conoscenze. Gran parte del codice COBOL contiene logica di business mai formalmente documentata. I processi batch scritti decenni fa codificano regole che nessuno ricorda più. Gli sviluppatori in grado di leggere il codice fluentemente e stimare con precisione i costi delle modifiche stanno andando in pensione. Gli sviluppatori che rimangono hanno una conoscenza parziale di alcune parti del portfolio. Senza metriche quantitative, la stima dei costi delle modifiche dipende interamente dallo sviluppatore a cui ci si rivolge, e la variabilità di queste stime è talmente elevata da rendere inaffidabile la pianificazione del progetto.
Il problema della scalabilità. Un portfolio COBOL tipico contiene migliaia di programmi, molti dei quali non sono stati modificati per anni. Nessun team può valutare manualmente migliaia di programmi prima dell'inizio di un programma di modernizzazione. Le metriche che possono essere calcolate automaticamente sull'intero portfolio in poche ore sostituiscono settimane di revisione manuale.
Il requisito del business case. I programmi di modernizzazione richiedono una giustificazione dell'investimento. I dirigenti che approvano budget di modernizzazione multimilionari desiderano prove quantitative che dimostrino la giustificazione dell'investimento. I punteggi MI, i rapporti di debito tecnico derivati da MI e le stime dei costi di modifica che fanno riferimento alle soglie MI forniscono tali prove in una forma che può essere presentata anche a interlocutori non tecnici.
La formula MI e i suoi componenti specifici per COBOL
La formula più comunemente utilizzata per calcolare l'indice di manutenibilità è:
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)La variante delimitata di Microsoft, utilizzata dalla maggior parte degli strumenti commerciali, mappa questo valore su una scala da 0 a 100:
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Ogni componente presenta specifiche considerazioni rilevanti per il linguaggio COBOL.
Righe di codice in COBOL
I file sorgente COBOL contengono quattro sezioni: IDENTIFICAZIONE, AMBIENTE, DATI e PROCEDURA. La SEZIONE IDENTIFICAZIONE identifica il programma. La SEZIONE AMBIENTE descrive il suo ambiente di esecuzione. La SEZIONE DATI definisce le sue strutture dati. Solo la SEZIONE PROCEDURA contiene le istruzioni eseguibili.
La questione della misurazione: LOC deve contare tutte le righe di tutte e quattro le divisioni, o solo le dichiarazioni della DIVISIONE PROCEDURE?
Ai fini dell'analisi dei dati, il conteggio di tutte le righe (incluse le dichiarazioni di dati) aumenta significativamente il numero di righe senza un corrispondente aumento della complessità di esecuzione. Un programma COBOL con 400 righe nella DATA DIVISION che definiscono la struttura dei record e una PROCEDURE DIVISION di 100 righe presenta caratteristiche di manutenibilità diverse da un programma con 100 righe nella DATA DIVISION e una PROCEDURE DIVISION di 400 righe, ma il conteggio grezzo delle righe li tratta in modo identico.
Buona prassi: per il calcolo del MI COBOL, utilizzare il conteggio delle istruzioni PROCEDURE DIVISION (escludendo righe vuote, righe di commento e intestazioni di divisione/sezione/paragrafo) anziché il numero totale di righe del codice sorgente. Questo produce valori LOC che corrispondono più fedelmente alla complessità eseguibile.
Il problema del membro COPY: le istruzioni COPY includono membri sorgente esterni in fase di compilazione. Un'istruzione COPY che si espande fino a 200 righe di definizioni di dati contribuisce con una sola riga al file sorgente, ma con 200 righe al programma compilato. Alcuni strumenti contano le righe logiche (espansione post-copia); altri contano le righe fisiche del codice sorgente. La differenza può essere di un ordine di grandezza per i programmi che fanno un uso intensivo di COPY.
Attenzione: se il tuo strumento MI conta le righe di codice sorgente fisiche, i programmi con un uso estensivo di COPY appariranno più piccoli e più facili da gestire di quanto non siano in realtà. Verifica sempre se LOC nel tuo strumento si riferisce all'espansione pre o post-copia.
Complessità ciclomica in COBOL
La complessità ciclomica è una metrica di qualità del codice che misura la comprensibilità e la manutenibilità del codice misurando il numero di percorsi indipendenti al suo interno. In COBOL, le strutture decisionali che creano percorsi indipendenti includono:
| Costrutto COBOL | Impatto della complessità ciclomica |
|---|---|
IF ... END-IF | +1 per IF |
IF ... ELSE ... END-IF | +1 per ogni IF (ELSE non aggiunge un altro percorso) |
EVALUATE ... WHEN | +1 per clausola WHEN |
PERFORM UNTIL condition | +1 per condizione UNTIL |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 per VARIABILE |
AT END clausola su READ | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 per ogni gestore di eccezioni |
ON OVERFLOW / NOT ON OVERFLOW | +1 per ogni gestore di overflow |
ON SIZE ERROR | +1 per gestore degli errori di dimensione |
Il punto cieco del livello 88: i nomi delle condizioni a 88 livelli del COBOL creano condizioni logiche che compaiono nelle istruzioni IF e EVALUATE, ma sono definite nella DIVISIONE DATI. Un programma con venti condizioni a 88 livelli, ciascuna referenziata in più strutture decisionali, presenta una complessità comportamentale significativamente maggiore di quanto suggerisca il conteggio delle istruzioni nella DIVISIONE PROCEDURE. La complessità ciclomica conta i punti decisionali, ma non è in grado di cogliere le relazioni semantiche tra i nomi a 88 livelli e la logica che li verifica.
ESEGUIRE ATTRAVERSO la complessità implicita: PERFORM SECTION-A THRU SECTION-Z esegue tutti i paragrafi tra la SEZIONE-A e la SEZIONE-Z. Il numero di paragrafi e le strutture decisionali al loro interno fanno tutti parte della complessità effettiva dell'istruzione PERFORM, ma CC calcolato a livello di istruzione tratta PERFORM THRU come un unico percorso, a prescindere da ciò che si trova nel mezzo.
Volume di Halstead in COBOL
Il volume di Halstead è una misura delle dimensioni e della complessità di un programma basata sul numero di operatori e operandi. In COBOL:
Gli operatori sono verbi e parole chiave COBOL: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN e così via.
Gli operandi sono nomi di dati, letterali e costanti figurative: elementi di dati definiti nella DATA DIVISION, letterali numerici e stringa e costanti figurative COBOL (SPAZI, ZERI, VALORI ALTI, VALORI BASSI).
Il fattore verbosità: COBOL è significativamente più prolisso dei linguaggi moderni per una logica equivalente. Un'espressione Java total = quantity * unitPrice * (1 - discount) è una riga con quattro operatori e quattro operandi. L'equivalente in COBOL:
cobolo
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)Questo è approssimativamente equivalente in termini di operatori e operandi, ma si consideri un calcolo più complesso che in Java potrebbe utilizzare tre righe. In COBOL potrebbe richiederne cinque o più a causa della mancanza di concatenamento delle espressioni e della necessità di utilizzare campi di memoria di lavoro intermedi. Il volume di Halstead sarà corrispondentemente maggiore per COBOL rispetto all'equivalente Java semplicemente perché COBOL esprime lo stesso calcolo con più token di linguaggio.
La conseguenza pratica: i programmi COBOL avranno volumi di Halstead più elevati rispetto ai programmi in linguaggio moderno con logica equivalente. Un volume di Halstead più elevato riduce l'MI. I programmi COBOL, pertanto, otterranno sistematicamente punteggi inferiori in termini di MI rispetto ai programmi in linguaggio moderno di complessità equivalente, non perché siano più difficili da mantenere, ma perché il COBOL è sintatticamente più prolisso.
Dove Standard MI non è all'altezza di COBOL: quattro punti ciechi
Anche se calcolata correttamente, la formula standard MI non tiene conto di quattro dimensioni della manutenibilità del COBOL che hanno un impatto significativo sui costi di modifica reali.
1. Accoppiamento membro COPIA
Un copybook COBOL incluso da 300 programmi rappresenta una dipendenza di manutenzione che influenza tutti e 300 i programmi ogni volta che viene apportata una modifica. Questo accoppiamento non compare in alcun componente della formula MI. Un programma che include venti copybook ha 300 dipendenze implicite che MI considera equivalenti a un programma senza copybook.
Metrica supplementare: Conteggio delle dipendenze dei membri di copia, ovvero il numero di istruzioni COPY univoche nella DATA DIVISION di un programma. I programmi con un elevato accoppiamento COPY richiedono un'analisi d'impatto prima di qualsiasi modifica per comprendere quali altri programmi condividono le stesse definizioni del copybook.
2. Ingresso dei tifosi (conteggio chiamato)
Un sottoprogramma COBOL chiamato da altri 150 programmi rappresenta un obiettivo di modifica ad alto rischio, indipendentemente dal suo punteggio MI. Un sottoprogramma facilmente manutenibile (MI = 85) chiamato da 150 programmi è più difficile da modificare in sicurezza rispetto a un'utility scarsamente manutenibile (MI = 45) che non viene chiamata da nessuno. La formula MI non tiene conto di quanto un programma sia diffuso.
Metrica supplementare: Fan-In, il numero di programmi distinti che richiamano un determinato programma tramite CALL o dispatch dinamico. Il Fan-in è il principale fattore determinante del rischio di modifiche per i sottoprogrammi, indipendentemente dalla loro complessità interna.
3. Profondità delle dipendenze JCL
Un programma COBOL richiamato da un job JCL che ha quindici job dipendenti a valle, ovvero job che vengono eseguiti successivamente e dipendono dal suo output, comporta un rischio operativo che esula completamente dall'ambito di MI. Un programma con MI = 55 che viene eseguito in modo autonomo è meno rischioso da modificare rispetto a un programma con MI = 80 che si trova al centro di una complessa catena di dipendenze batch.
Metrica supplementare: Profondità di dipendenza JCL, ovvero la profondità della catena di dipendenze a valle nella rete di job JCL. I programmi con un'elevata profondità di dipendenza JCL richiedono un ambito di test più ampio per qualsiasi modifica, indipendentemente dal loro punteggio MI interno.
4. Inflazione del codice morto
Paragrafi e sezioni inattivi, codice COBOL definito ma mai richiamato da alcun percorso di esecuzione, aumentano il numero di righe di codice (LOC) e il volume di Halstead senza contribuire al carico di manutenzione del codice attivo. Un programma con 600 righe di codice inattivo e 200 righe di codice attivo ha un indice di modifica (MI) che lo penalizza per il codice inattivo, anche se quest'ultimo è irrilevante ai fini del costo di modifica.
Metrica supplementare: Percentuale di codice morto, ovvero la proporzione di istruzioni PROCEDURE DIVISION irraggiungibili da qualsiasi percorso di esecuzione in produzione. Percentuali elevate di codice morto indicano che il numero di righe di codice (LOC) e il volume di Halstead calcolati da MI sono significativamente sovrastimati.
Una suite completa di metriche COBOL
Nessun singolo parametro è sufficiente a descrivere la manutenibilità del COBOL. Il seguente insieme di parametri, utilizzati congiuntamente, fornisce un quadro completo:
| Metrico | Cosa misura | Nota specifica per COBOL | Uso primario |
|---|---|---|---|
| Indice di manutenibilità | Facilità di manutenzione complessiva (composito) | Applicare le dichiarazioni della DIVISIONE PROCEDURE; verificare la gestione delle COPIE | Punteggio di qualità di base; classificazione del portfolio |
| Complessità ciclomatica | Numero di percorsi di esecuzione indipendenti | Includi VALUTA QUANDO, ESEGUI FINO A, ALLA FINE, IN CASO DI ECCEZIONE | Modificare lo sforzo per programma; stima del numero di casi di test |
| Volume di Halstead | Carico computazionale (operatori + operandi) | Aspettatevi valori più elevati rispetto a programmi di lingua moderna equivalenti. | Parte di MI; confronto tra programmi all'interno del portfolio COBOL |
| COPIA Numero di membri | Accoppiamento delle dipendenze tramite definizioni condivise | I programmi con più di 15 membri COPY richiedono un'analisi d'impatto prima di qualsiasi modifica | Modificare la classificazione del rischio |
| Fan-In (chiamato da) | Quanti programmi chiamano questo? | Principale fattore di rischio di cambiamento per i sottoprogrammi | Sequenziamento della migrazione; soglia di autorizzazione alla modifica |
| Codice morto % | Percentuale di codice procedura irraggiungibile | Gonfiare LOC/HV se non escluso; escludere dall'ambito di conversione | Riduzione dell'ambito di applicazione della modernizzazione |
| Profondità delle dipendenze JCL | profondità della catena di processi batch a valle | Non calcolabile solo dal codice sorgente COBOL; richiede l'analisi JCL. | Rischio di modifica operativa; ambito dei test |
| Profondità di esecuzione annidata | Livello massimo di annidamento delle chiamate PERFORM | L'annidamento profondo indica una complessità strutturale non catturata da CC | Priorità di refactoring |
Calibrazione della soglia per COBOL
Le soglie MI standard derivano da codebase di linguaggi moderni e non si applicano direttamente al COBOL. La tabella seguente confronta le soglie standard con i valori equivalenti appropriati per il COBOL e spiega la logica di adeguamento.
| Punteggio | Interpretazione standard | Interpretazione COBOL | Fondamento logico |
|---|---|---|---|
| 85-100 | Altamente manutenibile | Altamente manutenibile (coerente) | I migliori programmi COBOL rientrano in questa fascia di punteggio: struttura pulita, dimensioni appropriate. |
| 65-84 | Moderatamente manutenibile | Moderatamente manutenibile, rivedere l'accoppiamento COPY e il fan-in | La soglia standard rimane valida, ma in questo caso le metriche supplementari assumono maggiore importanza. |
| 50-64 | Scarso, necessita di ristrutturazione | Marginale, valutare nel contesto | Molti programmi COBOL ben strutturati ottengono un buon punteggio in questa sezione solo grazie alla loro verbosità; utilizzare CC e fan-in per distinguere i problemi reali dagli artefatti di sintassi. |
| 25-49 | Molto scarsa | Scarsa, probabile elevata CC e/o LOC eccessiva | I programmi in questa fascia indicano in modo affidabile problemi strutturali, non solo la verbosità del COBOL. |
| 0-24 | Ristrutturazione critica e importante | Critico, massima priorità per la bonifica o la dismissione | Coerente con l'interpretazione standard |
Indicazioni chiave per la calibrazione: Eseguite MI sull'intero portfolio COBOL prima di impostare le soglie specifiche per ciascun programma. Calcolate la mediana e l'intervallo interquartile del portfolio. Impostate la soglia di "attenzione richiesta" al 25° percentile del vostro portfolio, ovvero i programmi che si trovano nel quartile inferiore della vostra specifica codebase, non i programmi che ottengono un punteggio inferiore a una soglia derivata dai programmi Java. Questo approccio è autocalibrante e tiene conto dell'effetto sistematico della verbosità del COBOL.
Utilizzo dell'intelligence gestionale (IM) per le decisioni di modernizzazione.
I punteggi MI diventano più utili quando forniscono informazioni utili per prendere decisioni operative specifiche. Ecco le principali applicazioni.
Sequenziamento delle ondate di migrazione. I programmi con punteggi MI elevati (ben mantenuti, bassa complessità) sono i candidati migliori per le prime ondate di migrazione. Sono più facili da validare, hanno meno probabilità di contenere casi limite non documentati e presentano un rischio inferiore di produrre comportamenti imprevisti nell'ambiente migrato. I programmi con punteggi MI bassi dovrebbero essere migrati nelle ondate successive, dopo che il team ha acquisito esperienza e fiducia e dopo un'accurata estrazione della logica di business.
Prioritizzazione della manutenzione. I programmi con MI inferiore al 25° percentile che presentano anche un elevato fan-in (chiamato da molti programmi) o un'elevata profondità di dipendenza JCL rappresentano la combinazione a più alto rischio: programmi strutturalmente complessi da cui dipendono molti altri programmi. Questi sono i programmi che hanno maggiori probabilità di produrre difetti legati alle modifiche e i più costosi da correggere quando ciò accade. Dovrebbero essere i primi obiettivi di un programma di riduzione del debito tecnico.
Decisioni di sviluppo interno o acquisto. Quando si valuta se mantenere un programma COBOL a lungo termine o sostituirlo con un'alternativa SaaS o moderna, il punteggio MI e la cronologia dei costi di modifica forniscono la base quantitativa per il calcolo di convenienza tra sviluppo interno e acquisto. Un programma con MI = 30, modificato quindici volte negli ultimi tre anni, con ogni modifica che ha richiesto un tempo significativamente maggiore rispetto a quello stimato, ha un costo di manutenzione documentato che può essere confrontato con il costo di sostituzione.
Soglie di autorizzazione alle modifiche. Alcune organizzazioni utilizzano i punteggi MI per determinare il livello di autorizzazione alle modifiche richiesto. I programmi al di sotto di una determinata soglia MI richiedono una revisione più rigorosa, test indipendenti e un'approvazione aggiuntiva prima della distribuzione in produzione. Ciò crea un processo di controllo delle modifiche orientato alla qualità senza richiedere la valutazione manuale di ogni singola modifica.
L'unica cosa che l'MI non può fare è prevedere l'impatto di un cambiamento sul business. Un programma con MI = 85 che esegue calcoli sul capitale regolamentare richiede almeno la stessa quantità di test e validazione di un programma con MI = 40 che svolge una funzione di reporting a basso rischio. L'MI misura lo sforzo richiesto per il cambiamento, non le sue conseguenze. Entrambe le dimensioni sono necessarie per una valutazione completa del rischio.
Come SMART TS XL Definisce e monitora le metriche di manutenibilità del COBOL
Calcolare l'indice MI per un singolo programma COBOL è semplice. Calcolarlo con precisione per un portfolio di migliaia di programmi, tenendo conto dell'espansione di COPY, identificando il codice morto e integrando l'indice MI con le metriche aggiuntive che esso non considera, richiede un'analisi automatizzata su larga scala.
SMART TS XL'S analisi statica del codice Calcola simultaneamente l'intera suite di metriche COBOL descritta in questa guida sull'intero portfolio. MI viene calcolato utilizzando il conteggio delle istruzioni PROCEDURE DIVISION anziché il numero totale di righe del codice sorgente, con l'espansione di COPY eseguita prima dell'analisi per garantire che le definizioni dei dati condivisi siano attribuite correttamente. La complessità ciclomica tiene conto delle clausole EVALUATE WHEN, delle condizioni PERFORM UNTIL e dei rami di gestione delle eccezioni, non solo delle istruzioni IF. Il volume di Halstead viene calcolato a partire dai verbi COBOL e dagli operandi dati nella PROCEDURE DIVISION.
In modo cruciale, SMART TS XL integra l'MI con le metriche che la formula non include. mappatura delle dipendenze delle applicazioni produce i valori fan-in, conteggi call-by, per ogni programma nel portafoglio, identificando i programmi ad alto rischio indipendentemente dal loro punteggio MI. Espansione JCL Questa funzionalità fornisce la profondità delle dipendenze JCL per ogni programma, collegando l'analisi MI a livello COBOL al contesto di rischio operativo che solo l'analisi JCL può rivelare.
L'identificazione del codice morto tramite la funzionalità di analisi dell'impatto segnala paragrafi e sezioni privi di percorsi di esecuzione in entrata, consentendo l'esclusione del codice morto dal calcolo dell'indice MI e fornendo la metrica percentuale di codice morto che determina se un basso punteggio MI di un programma riflette una reale complessità o un numero di righe di codice gonfiato.
La funzionalità di ricerca aziendale rende interrogabile l'intero set di dati delle metriche: è possibile trovare tutti i programmi con MI inferiore a 40 e fan-in superiore a 20, ordinati in base alla profondità di dipendenza JCL, e gli obiettivi di correzione con la massima priorità nel portfolio, con una singola query su milioni di righe di COBOL. Questo inventario di metriche interrogabile costituisce la base per le applicazioni di prioritizzazione della manutenzione, sequenziamento della migrazione e autorizzazione delle modifiche descritte in precedenza.
Infine, l'indice MI, monitorato nel tempo e ricalcolato dopo ogni ciclo di cambiamento significativo, mostra se il programma sta migliorando o peggiorando. SMART TS XLL'analisi viene eseguita sul codice sorgente corrente anziché su snapshot memorizzati nella cache, garantendo che le metriche riflettano lo stato effettivo del codice sorgente al momento di ciascuna analisi, anziché una valutazione puntuale che tende a diventare obsoleta.
Metriche che corrispondono al linguaggio
L'indice di manutenibilità (Maintenability Index, MI) è una metrica valida e preziosa per i portfolio COBOL, ma solo se applicato con una comprensione di come le caratteristiche sintattiche del COBOL interagiscono con i suoi componenti. L'applicazione di soglie generiche ai programmi COBOL produce risultati fuorvianti. Integrare il MI con le metriche che esso non considera, come l'accoppiamento COPY, il fan-in, la profondità delle dipendenze JCL e la percentuale di codice morto, fornisce un quadro che corrisponde a ciò che gli sviluppatori effettivamente sperimentano quando lavorano su un portfolio COBOL.
Le organizzazioni che utilizzano efficacemente queste metriche sono quelle che le considerano un punto di partenza per una discussione informata, non un verdetto definitivo sulla qualità di un programma. Un punteggio MI è un segnale. Vale la pena seguirlo, perché indica costantemente i programmi che sono costosi da modificare, rischiosi da modificare e che meritano di essere affrontati prima dell'inizio della modernizzazione. Ciò che MI non può fare è sostituire il giudizio di uno sviluppatore che legge il codice, né rimpiazzare l'analisi strutturale che rivela le dipendenze e la logica aziendale che nessuna singola metrica è in grado di cogliere.
