O Índice de Manutenibilidade (IM) é uma das métricas compostas mais utilizadas na medição da qualidade de software. Ele condensa três propriedades estruturais do código — tamanho, complexidade e volume — em uma única pontuação numérica que prevê a dificuldade de modificar o código. Para linguagens modernas, a fórmula, os limites e as ferramentas são bem estabelecidos. Para COBOL, a situação é mais complexa, e a maioria das equipes aplica a fórmula genérica sem ajustes ou abandona completamente a medição quantitativa, pois as pontuações não parecem corresponder à experiência real dos desenvolvedores.
Ambas as abordagens produzem resultados enganosos. Aplicar a fórmula padrão de MI (Métodos de Mensuração) ao COBOL sem entender como seus componentes se comportam no contexto sintático do COBOL produz pontuações sistematicamente enviesadas, fazendo com que programas de alta qualidade pareçam marginais e programas de baixa qualidade pareçam aceitáveis. Abandonar completamente a mensuração deixa as decisões de modernização sem a base quantitativa necessária para serem defensáveis perante as partes interessadas do negócio e para priorizar o trabalho de remediação em um portfólio de milhares de programas.
Obtenha uma visão completa das métricas COBOL.
SMART TS XL Classifica todos os programas COBOL simultaneamente por complexidade, fan-in e profundidade de dependência do JCL.
Mais informaçõesO caminho correto é entender o que a fórmula de MI mede especificamente em COBOL, onde ela subestima e superestima a qualidade, quais métricas suplementares corrigem suas limitações específicas do COBOL e como calibrar os limites com base no seu portfólio real, em vez de usar benchmarks genéricos derivados de bases de código de linguagens modernas. Este guia aborda todos esses quatro aspectos, com profundidade técnica suficiente para implementar um programa de MI em COBOL e orientação prática suficiente para usá-lo em decisões de modernização.
Um último ponto antes de abordarmos os detalhes técnicos: o Índice de Manutenibilidade (MI) busca fornecer uma visão holística da carga de manutenção relativa para diferentes seções de um projeto, combinando uma série de métricas distintas. Essa visão holística é valiosa para portfólios COBOL justamente porque nenhuma métrica isolada captura o quadro completo. O MI é o ponto de partida, não a história completa, mas o lugar certo para começar.
Por que a medição da manutenibilidade é mais importante para COBOL do que para linguagens modernas?
Medir a manutenibilidade de um código-fonte Java ou Python com dois anos de existência, bem testado e mantido pela equipe que o escreveu, fornece informações úteis, mas raramente é urgente. O código é legível para seus autores. A lógica está documentada ou pode ser derivada de testes. O custo de alteração é limitado pela familiaridade da equipe com o código.
Os portfólios COBOL em setores regulamentados diferem em três aspectos que fazem com que a medição quantitativa da manutenibilidade não seja uma prática de qualidade, mas sim uma necessidade operacional.
A lacuna de conhecimento. A maior parte do código COBOL contém lógica de negócios que nunca foi formalmente documentada. Tarefas em lote escritas décadas atrás codificam regras que ninguém se lembra. Os desenvolvedores que conseguem ler o código fluentemente e estimar o custo de alterações com precisão estão se aposentando. Os desenvolvedores que permanecem têm familiaridade parcial com partes do portfólio. Sem métricas quantitativas, a estimativa de custo de alterações depende inteiramente de qual desenvolvedor você pergunta, e a variabilidade nessas estimativas é alta o suficiente para tornar o planejamento de projetos pouco confiável.
O problema da escala. Um portfólio típico de COBOL contém milhares de programas, muitos dos quais não foram atualizados há anos. Nenhuma equipe consegue avaliar manualmente milhares de programas antes do início de um programa de modernização. Métricas que podem ser calculadas automaticamente em todo o portfólio em questão de horas substituem semanas de revisão manual.
A necessidade de justificativa de negócios. Os programas de modernização exigem justificativa de investimento. Executivos que aprovam orçamentos de modernização multimilionários desejam evidências quantitativas de que o investimento é justificado. Pontuações de MI (Importation Management), índices de dívida técnica derivados de MI e estimativas de custo de mudança que referenciam limites de MI fornecem essas evidências de forma que possam ser apresentadas a partes interessadas não técnicas.
A fórmula MI e seus componentes específicos em COBOL
A fórmula mais comumente usada para calcular o Índice de Manutenibilidade é:
MI = 171 - 5.2 × ln(Halstead Volume) - 0.23 × (Cyclomatic Complexity) - 16.2 × ln(Lines of Code)A variante limitada da Microsoft, usada pela maioria das ferramentas comerciais, mapeia isso para uma escala de 0 a 100:
MI (bounded) = max(0, (171 - 5.2 × ln(HV) - 0.23 × CC - 16.2 × ln(LOC)) × 100 / 171)Cada componente possui considerações específicas relevantes para o COBOL.
Linhas de código em COBOL
Os arquivos fonte COBOL contêm quatro divisões: IDENTIFICATION, ENVIRONMENT, DATA e PROCEDURE. A divisão IDENTIFICATION identifica o programa. A divisão ENVIRONMENT descreve seu ambiente de execução. A divisão DATA define suas estruturas de dados. Somente a divisão PROCEDURE contém instruções executáveis.
A questão da medição: o LOC deve contar todas as linhas em todas as quatro divisões, ou apenas as instruções PROCEDURE DIVISION?
Para fins de MI (Manutenção Individual), contar todas as linhas (incluindo declarações de dados) aumenta significativamente o LOC (Número de Linhas de Código) sem um aumento correspondente na complexidade de execução. Um programa COBOL com 400 linhas de DATA DIVISION definindo layouts de registro e uma PROCEDURE DIVISION de 100 linhas possui características de manutenibilidade diferentes de um programa com 100 linhas de DATA DIVISION e uma PROCEDURE DIVISION de 400 linhas, mas o LOC bruto os trata de forma idêntica.
Boa prática: Para o cálculo de MI em COBOL, utilize a contagem de instruções PROCEDURE DIVISION (excluindo linhas em branco, linhas de comentário e cabeçalhos de divisão/seção/parágrafo) em vez do total de linhas de código-fonte. Isso produz valores de LOC que correspondem mais precisamente à complexidade do executável.
O problema do membro COPY: as instruções COPY incluem membros de código-fonte externos em tempo de compilação. Uma instrução COPY que se expande para 200 linhas de definições de dados contribui com uma linha para o arquivo de origem, mas com 200 linhas para o programa compilado. Algumas ferramentas contabilizam as linhas de código lógicas (expansão pós-cópia); outras contabilizam as linhas de código-fonte físicas. A diferença pode ser de uma ordem de magnitude para programas com uso intensivo de COPY.
Atenção: Se a sua ferramenta de MI contabiliza linhas de código-fonte físicas, programas com uso extensivo de COPY parecerão menores e mais fáceis de manter do que realmente são. Sempre verifique se o LOC (linhas de código) na sua ferramenta se refere à expansão pré ou pós-cópia.
Complexidade ciclomática em COBOL
A Complexidade Ciclomática é uma métrica de qualidade de código que mede a compreensibilidade e a manutenibilidade do código, contabilizando o número de caminhos independentes que ele possui. Em COBOL, as estruturas de decisão que criam caminhos independentes incluem:
| Construção COBOL | Impacto da Complexidade Ciclomática |
|---|---|
IF ... END-IF | +1 por IF |
IF ... ELSE ... END-IF | +1 por IF (ELSE não adiciona outro caminho) |
EVALUATE ... WHEN | +1 por cláusula WHEN |
PERFORM UNTIL condition | +1 por condição ATÉ |
PERFORM VARYING ... WITH TEST BEFORE/AFTER | +1 por VARIÁVEL |
AT END cláusula sobre LEIA | +1 |
ON EXCEPTION / NOT ON EXCEPTION | +1 por manipulador de exceção |
ON OVERFLOW / NOT ON OVERFLOW | +1 por manipulador de estouro |
ON SIZE ERROR | +1 por manipulador de erros de tamanho |
O ponto cego do nível 88: os nomes de condição de nível 88 do COBOL criam condições lógicas que aparecem em instruções IF e EVALUATE, mas são definidas na DATA DIVISION. Um programa com vinte condições de nível 88, cada uma referenciada em múltiplas estruturas de decisão, tem uma complexidade comportamental significativamente maior do que a contagem de instruções da PROCEDURE DIVISION sugere. A Complexidade Ciclomática contabiliza os pontos de decisão, mas não consegue capturar as relações semânticas entre os nomes de nível 88 e a lógica que os testa.
DESEMPENHO ATRAVÉS DA complexidade implícita: PERFORM SECTION-A THRU SECTION-Z Executa todos os parágrafos entre SECTION-A e SECTION-Z. O número de parágrafos e as estruturas de decisão dentro deles fazem parte da complexidade efetiva da instrução PERFORM, mas o CC calculado no nível da instrução trata PERFORM THRU como um único caminho, independentemente do que houver entre eles.
Volume Halstead em COBOL
O Volume de Halstead é uma medida do tamanho e da complexidade de um programa, baseada no número de operadores e operandos. Em COBOL:
Os operadores são verbos e palavras-chave do COBOL: MOVE, ADD, SUBTRACT, MULTIPLY, DIVIDE, COMPUTE, IF, PERFORM, READ, WRITE, OPEN, CLOSE, CALL, GO TO, EVALUATE, WHEN, e assim por diante.
Os operandos são nomes de dados, literais e constantes figurativas: itens de dados definidos na DATA DIVISION, literais numéricos e de string e constantes figurativas COBOL (ESPAÇOS, ZEROS, VALORES ALTOS, VALORES BAIXOS).
O fator verbosidade: COBOL é significativamente mais verboso do que linguagens modernas para lógica equivalente. Uma expressão Java. total = quantity * unitPrice * (1 - discount) é uma linha com quatro operadores e quatro operandos. O equivalente em COBOL:
cobol
COMPUTE WS-TOTAL = WS-QUANTITY * WS-UNIT-PRICE
* (1 - WS-DISCOUNT)Isso é aproximadamente equivalente em termos de operadores e operandos, mas considere um cálculo mais complexo que em Java poderia usar três linhas. Em COBOL, ele pode exigir cinco ou mais linhas devido à falta de encadeamento de expressões e à necessidade de usar campos de armazenamento intermediários. O Volume de Halstead será correspondentemente maior para COBOL do que para Java equivalente, simplesmente porque o COBOL expressa a mesma computação com mais tokens de linguagem.
A consequência prática: os programas COBOL terão volumes de Halstead mais altos do que os programas em linguagens modernas com lógica equivalente. Um volume de Halstead mais alto reduz a informação de manutenção (MI). Portanto, os programas COBOL terão sistematicamente pontuações mais baixas em MI do que os programas em linguagens modernas com complexidade equivalente, não porque sejam mais difíceis de manter, mas porque o COBOL é sintaticamente mais verboso.
Onde o Standard MI deixa a desejar para COBOL: Quatro pontos cegos
Mesmo calculada corretamente, a fórmula padrão de MI (Manutenibilidade Integrada) deixa de fora quatro dimensões da manutenibilidade do COBOL que têm um impacto significativo no custo real das alterações.
1. Acoplamento de membro COPY
Um copybook COBOL incluído por 300 programas é uma dependência de manutenção que afeta todos os 300 programas quando qualquer alteração é feita nele. Esse acoplamento não aparece em nenhum componente da fórmula MI. Um programa que inclui vinte copybooks tem 300 dependências implícitas que o MI trata como equivalentes a um programa sem copybooks.
Métrica suplementar: Contagem de Dependências de Membros de Cópia, o número de instruções COPY exclusivas na DATA DIVISION de um programa. Programas com alto acoplamento de COPY exigem análise de impacto antes de qualquer alteração para entender quais outros programas compartilham as mesmas definições de copybook.
2. Fan-In (Contagem por Chamada)
Um subprograma COBOL chamado por outros 150 programas é um alvo de alto risco para alterações, independentemente de sua pontuação MI. Um subprograma de fácil manutenção (MI = 85) que é chamado por 150 programas é mais difícil de ser alterado com segurança do que um utilitário de difícil manutenção (MI = 45) que não é chamado por ninguém. A fórmula do MI não leva em consideração a frequência com que um programa é utilizado.
Métrica suplementar: Fan-In, o número de programas distintos que chamam um determinado programa por meio de CALL ou despacho dinâmico. O Fan-In é o principal fator de risco de mudança para subprogramas, independentemente de sua complexidade interna.
3. Profundidade de Dependência do JCL
Um programa COBOL invocado por um job JCL que possui quinze jobs dependentes subsequentes, ou seja, jobs que são executados após ele e dependem de sua saída, apresenta um risco operacional que está completamente fora do escopo do MI. Um programa com MI = 55 que é executado de forma independente é menos arriscado de modificar do que um programa com MI = 80 que está no centro de uma cadeia complexa de dependência de lotes.
Métrica suplementar: Profundidade de Dependência JCL, a profundidade da cadeia de dependências a jusante na rede de tarefas JCL. Programas com alta profundidade de dependência JCL exigem um escopo de teste mais amplo para qualquer alteração, independentemente de sua pontuação interna de MI (Métrica Integrada).
4. Inflação de Código Morto
Parágrafos e seções mortas, código COBOL definido, mas nunca executado por nenhum caminho de execução, aumentam o LOC (linhas de código) e o Volume de Halstead sem contribuir para a carga de manutenção do código em execução. Um programa com 600 linhas de código morto e 200 linhas de código em execução possui uma MI (Método de Execução) que o penaliza pelo código morto, mesmo que este seja irrelevante para o custo de alteração.
Métrica suplementar: Percentagem de código morto, a proporção de instruções PROCEDURE DIVISION que são inacessíveis a partir de qualquer caminho de execução de produção. Percentagens elevadas de código morto indicam que o LOC calculado pelo MI e o Volume de Halstead estão significativamente inflacionados.
Um conjunto completo de métricas COBOL
Nenhuma métrica isolada captura a manutenibilidade do COBOL. O conjunto a seguir, usado em conjunto, fornece uma visão completa:
| métrico | O que ele mede | Nota específica para COBOL | Uso primário |
|---|---|---|---|
| Índice de Manutenção | Facilidade geral de manutenção (compósito) | Aplicar às declarações da DIVISÃO DE PROCEDIMENTOS; verificar o manuseio de CÓPIAS | Pontuação de qualidade básica; classificação do portfólio |
| Complexidade ciclomática | Número de caminhos de execução independentes | Incluir AVALIAR QUANDO, EXECUTAR ATÉ, AO FIM, EM CASO DE EXCEÇÃO | Esforço de mudança por programa; estimativa de número de casos de teste |
| Volume de Halstead | Carga computacional (operadores + operandos) | Espere valores mais altos do que os de programas equivalentes de idiomas modernos. | Parte do MI; comparação entre programas dentro do portfólio COBOL |
| CÓPIA Contagem de membros | Acoplamento de dependências por meio de definições compartilhadas | Programas com mais de 15 membros do COPY exigem análise de impacto antes de qualquer alteração. | Alterar classificação de risco |
| Fan-In (Chamado por) | Quantos programas chamam isso de | Principal fator de risco de mudança para subprogramas | Sequenciamento de migração; alteração do limite de autorização |
| Código morto % | Percentagem de código de procedimento inacessível | Inflar LOC/HV se não estiver excluído; excluir do escopo de conversão | Redução do escopo para modernização |
| Profundidade de dependência do JCL | profundidade da cadeia de tarefas em lote a jusante | Não é possível calcular apenas com base no código-fonte COBOL; requer análise JCL. | Risco de mudança operacional; escopo de testes |
| Profundidade PERFORM Aninhada | Nível máximo de aninhamento de chamadas PERFORM | Aninhamento profundo indica complexidade estrutural não capturada pelo CC | Prioridade de refatoração |
Calibração de Limiar para COBOL
Os limites padrão de MI (Instrumentos Múltiplos) são derivados de bases de código de linguagens modernas e não se aplicam diretamente ao COBOL. A tabela abaixo compara os limites padrão com equivalentes apropriados para COBOL e explica a justificativa do ajuste.
| Faixa de Pontuação | Interpretação padrão | Interpretação de COBOL | análise racional |
|---|---|---|---|
| 85-100 | Altamente sustentável | Altamente sustentável (consistente) | Os melhores programas COBOL obtêm pontuação nesta faixa, com estrutura limpa e tamanho adequado. |
| 65-84 | De manutenção moderada | Moderadamente fácil de manter, revise o acoplamento COPY e o fan-in. | O limite padrão se mantém, mas as métricas suplementares são mais importantes neste caso. |
| 50-64 | Ruim, precisa de refatoração. | Marginal, avaliar no contexto | Muitos programas COBOL bem estruturados se destacam aqui apenas pela verbosidade; use CC e fan-in para distinguir problemas reais de artefatos de sintaxe. |
| 25-49 | Muito pobre | Péssimo, provavelmente com CC elevado e/ou LOC excessivo. | Programas nessa faixa indicam, de forma confiável, problemas estruturais, e não apenas verbosidade do COBOL. |
| 0-24 | Refatoração crítica e abrangente | Crítico, prioridade máxima para remediação ou desativação. | De acordo com a interpretação padrão. |
Diretrizes essenciais para calibração: Execute a Análise de Infraestrutura (MI) em todo o seu portfólio COBOL antes de definir limites específicos para cada programa. Calcule a mediana e o intervalo interquartil do portfólio. Defina seu limite de "atenção necessária" no 25º percentil do seu portfólio, ou seja, nos programas que se encontram no quartil inferior da sua base de código específica, e não em programas com pontuação abaixo de um limite derivado de programas Java. Essa abordagem é autocalibrável e leva em consideração o efeito sistemático da verbosidade do COBOL.
Utilizando Inteligência Artificial para Decisões de Modernização
Os indicadores de inteligência de mercado tornam-se mais valiosos quando servem de base para decisões operacionais específicas. Aqui estão as principais aplicações.
Sequenciamento das ondas de migração. Programas com altas pontuações de MI (bem mantidos, baixa complexidade) são os melhores candidatos para as primeiras ondas de migração. Eles são mais fáceis de validar, têm menor probabilidade de conter casos extremos não documentados e apresentam menor risco de produzir comportamentos inesperados no ambiente migrado. Programas com baixas pontuações de MI devem ser migrados em ondas posteriores, após a equipe adquirir experiência e confiança, e após uma extração completa da lógica de negócios.
Priorização da manutenção. Programas com MI abaixo do 25º percentil que também apresentam alto fan-in (chamado de "muitos programas") ou alta profundidade de dependência de JCL representam a combinação de maior risco: programas estruturalmente complexos dos quais muitos outros programas dependem. Esses são os programas com maior probabilidade de gerar defeitos relacionados a mudanças e os mais caros de remediar quando isso ocorre. Devem ser os primeiros alvos de um programa de redução de dívida técnica.
Decisões de construir versus comprar. Ao avaliar se deve manter um programa COBOL a longo prazo ou substituí-lo por uma alternativa SaaS ou moderna, a pontuação MI e o histórico de custos de alteração fornecem a base quantitativa para o cálculo de construir versus comprar. Um programa com MI = 30, modificado quinze vezes nos últimos três anos, com cada modificação levando significativamente mais tempo do que o estimado, possui um custo de manutenção documentado que pode ser comparado ao custo de substituição.
Limiares de autorização de mudanças. Algumas organizações usam pontuações de MI (Índice de Modificação) para determinar o nível de autorização de mudanças necessário. Programas abaixo de um determinado limiar de MI exigem uma revisão mais rigorosa, testes independentes e aprovação adicional antes da implementação em produção. Isso cria um processo de controle de mudanças focado na qualidade, sem exigir a avaliação manual de cada mudança.
A única coisa que o MI não consegue fazer é prever o impacto de uma mudança nos negócios. Um programa com MI = 85 que realiza cálculos de capital regulatório requer pelo menos tanto teste e validação quanto um programa com MI = 40 que executa uma função de relatório de baixo risco. O MI mede o esforço de mudança, não a consequência da mudança. Ambas as dimensões são necessárias para uma avaliação de risco completa.
Como SMART TS XL Estabelece e monitora métricas de manutenibilidade de COBOL.
Calcular as métricas de informação (MI) para um único programa COBOL é simples. No entanto, calculá-las com precisão para um conjunto de milhares de programas, levando em conta a expansão do comando COPY, a identificação de código morto e a complementação das MI com as métricas adicionais que elas não contemplam, exige análise automatizada em larga escala.
SMART TS XL'S análise de código estático Calcula simultaneamente o conjunto completo de métricas COBOL descritas neste guia para todo o portfólio. O MI é calculado usando a contagem de instruções PROCEDURE DIVISION em vez do total de linhas de código-fonte, com a expansão COPY realizada antes da análise para garantir que as definições de dados compartilhadas sejam atribuídas corretamente. A Complexidade Ciclomática considera as cláusulas EVALUATE WHEN, as condições PERFORM UNTIL e os desvios do manipulador de exceções, não apenas as instruções IF. O Volume de Halstead é calculado a partir dos verbos COBOL e dos operandos de dados na PROCEDURE DIVISION.
Crucialmente, SMART TS XL Complementa o MI com as métricas que a fórmula não inclui. mapeamento de dependências de aplicativos Produz os valores de fan-in, ou seja, as contagens de chamadas, para cada programa no portfólio, identificando programas de alto risco independentemente de sua pontuação MI. Expansão JCL Essa funcionalidade fornece a profundidade de dependência do JCL para cada programa, conectando a análise de MI em nível COBOL ao contexto de risco operacional que somente a análise de JCL pode revelar.
A identificação de código morto a partir da funcionalidade de análise de impacto sinaliza parágrafos e seções sem caminhos de execução de entrada, permitindo a exclusão de código morto do cálculo de MI (Impacto de Execução) e fornecendo a métrica de porcentagem de código morto que determina se a baixa pontuação de MI de um programa reflete complexidade genuína ou linhas de código infladas.
A funcionalidade de busca corporativa torna todo o conjunto de dados de métricas consultável: encontre todos os programas com MI abaixo de 40 e fan-in acima de 20, classificados por profundidade de dependência JCL, os alvos de remediação de maior prioridade no portfólio, em uma única consulta em milhões de linhas de COBOL. Esse inventário de métricas consultável é a base para a priorização de manutenção, o sequenciamento de migração e os aplicativos de autorização de alterações descritos acima.
Por fim, o MI (Índice de Mudança) acompanhado ao longo do tempo e recalculado após cada ciclo de mudança significativa mostra se o programa está melhorando ou piorando. SMART TS XLA análise do [nome da ferramenta/sistema] é executada no código-fonte atual, em vez de snapshots em cache, garantindo que as métricas reflitam o estado real da base de código no momento de cada análise, e não uma avaliação pontual que se torna obsoleta.
Métricas que correspondem à linguagem
O Índice de Manutenibilidade (MI) é uma métrica válida e valiosa para portfólios COBOL, mas somente quando aplicado com uma compreensão de como as características sintáticas do COBOL interagem com seus componentes. Aplicar limites genéricos a programas COBOL produz resultados enganosos. Complementar o MI com as métricas que ele não abrange — acoplamento COPY, fan-in, profundidade de dependência JCL e porcentagem de código morto — produz um panorama que corresponde à experiência real dos desenvolvedores ao trabalharem em um portfólio COBOL.
As organizações que utilizam essas métricas de forma eficaz são aquelas que as tratam como ponto de partida para uma conversa informada, e não como um veredito final sobre a qualidade do programa. Uma pontuação de MI é um sinal. Vale a pena acompanhar esse sinal, pois ele aponta consistentemente para os programas que são caros de alterar, arriscados de modificar e que merecem atenção antes do início da modernização. O que a MI não pode fazer é substituir o julgamento de um desenvolvedor que lê o código, ou substituir a análise estrutural que revela as dependências e a lógica de negócios que nenhuma métrica isolada consegue capturar.
