Dimensionamento de sistemas legados além das linhas de código

Uma contagem de linhas mostra quanto texto-fonte existe. Ela não mostra quanto comportamento um substituto precisa preservar, quantos caminhos esse comportamento pode seguir ou quanto do código-fonte ainda é executado. Tratar essas grandezas como equivalentes explica por que estimativas de modernização aparentemente precisas erram por um fator inteiro.

Já vi um pequeno conjunto de processos em lote levar mais tempo para ser entendido do que uma aplicação muito maior, porque cada job tocava o mesmo registro mutável de cliente e toda exceção aparecia em um relatório de controle impresso. Também vi diretórios intimidadores encolherem depois que uma análise de alcançabilidade mostrou que anos de variantes desativadas ainda eram distribuídos na árvore de código. A contagem estava certa nos dois casos. A conclusão tirada dela estava errada.

A unidade útil não é uma linha. É um comportamento que precisa ser descoberto, separado de suas dependências, implementado e comprovado como equivalente. Cinco medidas expõem esse trabalho: profundidade das decisões, fan-in sobre dados persistentes, proporção de código morto, superfície de integração e proporção do comportamento documentado apenas pela saída de produção. Nenhuma delas fornece sozinha um preço mágico. Juntas, elas dão à equipe um retrato defensável do sistema.

A contagem de linhas mede inventário, não reescrita

Linhas de código respondem a uma pergunta estreita: quanto texto uma regra específica de contagem classificou como fonte? O relatório de Robert Park para o Software Engineering Institute, Software Size Measurement: A Framework for Counting Source Statements, dedica bastante esforço a definir com precisão linhas físicas e instruções lógicas. Esse é o primeiro alerta. Duas ferramentas podem discordar antes que alguém tenha discutido comentários, copybooks gerados, macros expandidas, SQL embutido ou vários membros contendo a mesma rotina.

Mesmo uma contagem perfeitamente normalizada mede inventário. Ela pode ajudar na ingestão do repositório, no armazenamento, na vazão do analisador ou em uma primeira comparação aproximada entre versões escritas na mesma linguagem e sob as mesmas convenções. Não diz se 40 linhas implementam um mapeamento direto ou uma regra com estado e 16 caminhos. Não diz se 4.000 linhas copiadas estão ativas. Não mostra que uma única atribuição a uma coluna de status altera oito jobs posteriores.

A linguagem também distorce o denominador. Declarações de dados COBOL podem fazer layouts de registros parecerem visualmente grandes. APL ou SQL podem expressar bastante comportamento em poucas instruções. Java gerado pode acrescentar milhares de métodos de acesso repetitivos. Uma proporção baseada em linhas trata tudo isso silenciosamente como unidades equivalentes de pensamento. Não são.

Não tente corrigir isso com uma tabela de conversão de linguagens, na qual uma linha COBOL equivaleria a certo número de linhas Go. Essa recomendação continua popular porque produz rapidamente uma planilha e se parece com o planejamento histórico de produtividade. Ela falha em modernizações porque a arquitetura de destino não deve preservar a forma textual da origem. Um copybook compartilhado pode virar um esquema e clientes gerados. Vinte programas em lote quase idênticos podem virar um serviço com configuração. Um cálculo denso pode continuar denso em Rust porque a matemática, e não a sintaxe de origem, determina o trabalho.

Mantenha a contagem de linhas na avaliação, mas dê a ela um rótulo honesto. Registre separadamente linhas físicas, instruções lógicas, linhas geradas, comentários e linhas duplicadas. Use esses números para descrever o acervo. Nunca deixe que a soma represente esforço de entrega ou risco comportamental.

A profundidade ciclomática mostra decisões caras

A complexidade ciclomática conta caminhos independentes em um grafo de fluxo de controle. Thomas McCabe apresentou a medida em seu artigo de 1976, A Complexity Measure, com a expressão da teoria dos grafos geralmente escrita como V(G) = E - N + 2P. Ela é útil porque as obrigações de teste crescem em torno das decisões, não da formatação. A descrição tecnológica posterior do Software Engineering Institute também traz uma ressalva importante: um valor alto, sozinho, não prova que um módulo representa risco nem que ele deve ser redesenhado.

Na avaliação de sistemas legados, a distribuição importa mais do que a média do repositório. Uma média de seis pode descrever uma base uniforme ou uma base em que a maioria das rotinas é trivial e alguns módulos de liquidação contêm centenas de caminhos. Esses acervos precisam de planos diferentes. Informe pelo menos a mediana, o percentil 90, o máximo e a proporção de rotinas alcançáveis acima do limite que sua equipe examinará manualmente. Deixe rotinas geradas e mortas fora da distribuição principal, mas informe-as ao lado.

Complexidade ciclomática e profundidade ciclomática estão relacionadas, mas não são idênticas. A complexidade conta caminhos independentes. A profundidade registra até onde as decisões ficam aninhadas antes de o controle voltar a um nível mais simples. Uma tabela plana de despacho com 30 casos pode ter alta complexidade e ainda ser fácil de dividir. Cinco condições aninhadas que dependem de alterações anteriores podem ter menos caminhos, mas ser mais difíceis de explicar, testar e mover. As equipes muitas vezes confundem as duas medidas e depois não entendem por que um módulo com pontuação aceitável consome o orçamento de revisão.

Meça ambas em cada rotina alcançável. Para a profundidade, conte estruturas condicionais, loops, exceções e desvios específicos da linguagem que estejam aninhados, depois de expandir qualquer pré-processamento que altere o fluxo de controle. Em seguida, examine as rotinas com valor alto em qualquer um dos eixos. O exame deve responder a quatro perguntas: a ramificação depende de estado persistente? Ela altera dados usados depois na mesma transação? A condição está duplicada em outro lugar? As entradas registradas conseguem exercitar os dois resultados?

Não some todas as pontuações de complexidade em um número gigantesco. Uma soma recompensa a divisão de uma rotina sem reduzir as decisões reais do sistema e esconde a concentração. Use um mapa de calor ou uma tabela ordenada que preserve a identidade do módulo, o contexto da chamada e os dados tocados. Uma estimativa de reescrita precisa saber onde as decisões estão acopladas, não apenas quantos elementos de decisão um analisador encontrou.

A complexidade também determina o trabalho de comprovação. Uma rotina com um caminho direto pode precisar apenas de casos de fronteira representativos. Uma rotina profundamente aninhada que seleciona preços, impostos ou resultados de elegibilidade precisa de uma matriz de casos observados e construídos. Isso não significa que todo caminho matemático mereça um teste próprio. Existem caminhos inviáveis, e algumas combinações são excluídas pela validação anterior. Significa que a estimativa deve financiar o trabalho de provar quais caminhos importam, em vez de presumir que a contagem de linhas já os capturou.

O fan-in de dados revela o impacto real

Fan-in mede quantos chamadores ou fluxos convergem para um componente. Em sistemas legados, o fan-in no nível do código é útil, mas o fan-in da camada de dados costuma ser uma medida mais reveladora. Conte os programas implantados separadamente, jobs, telas, relatórios, procedimentos armazenados, transferências de arquivos e utilitários operacionais que leem ou gravam cada registro persistente, tabela, arquivo, fila ou área de dados compartilhada.

A distinção entre fan-in de leitura e de gravação importa. Cinquenta relatórios lendo um livro-razão que só recebe acréscimos geram trabalho de migração e compatibilidade, mas um único job de conciliação que grava linhas históricas pode criar uma restrição de transição muito mais difícil. A responsabilidade mista é pior: uma transação online atualiza um registro mestre, um lote noturno o corrige e um utilitário operacional pode sobrescrever um campo durante uma exceção. Um diagrama de esquema mostra o objeto compartilhado. Não mostra a ordem, a autoridade ou a razão operacional dessas gravações.

Comece com referências estáticas e depois confronte-as com evidências de execução. A análise estática consegue resolver SQL direto, nomes conhecidos de arquivos, uso de copybooks e chamadas literais. Ela não encontra SQL dinâmico, nomes montados em variáveis, substituições do agendador, aliases, exits e acessos feitos por ferramentas fora do repositório. Registros de auditoria do banco de dados, logs de jobs, metadados de mensagens e histórico do catálogo de arquivos revelam parte desse fan-in ausente. Entrevistas podem acrescentar utilitários operacionais, mas trate a lembrança como uma pista até que uma evidência a confirme.

Classifique os ativos de dados por mais do que o número bruto de referências. Separe leitores de gravadores, acesso online de processamento em lote e atualizações síncronas de atualizações adiadas. Registre se uma fronteira de transação abrange vários ativos. Marque campos cujo significado muda conforme o programa, como um status vazio interpretado como “pendente” por um job e “não se aplica” por outro. Esses conflitos semânticos geram mais trabalho de reescrita do que uma tabela limpa com muitos leitores comuns.

Um registro prático de fan-in pode ser compacto:

asset,readers,writers,execution_modes,transaction_peer,observed
CUSTOMER-MASTER,14,4,online|batch,ADDRESS-HISTORY,yes
RATE-CONTROL,6,1,batch,none,no
CLAIM-QUEUE,3,3,online|operator,PAYMENT-FILE,partial

A última coluna é intencional. Uma referência estática e um acesso observado são afirmações diferentes. Preserve ambos. Quando uma estimativa os mistura, uma referência nunca executada pode inflar o escopo enquanto um acesso dinâmico não visto desaparece.

Fan-in alto não significa automaticamente “reescrever primeiro”. Muitas vezes significa o contrário. Um ativo de dados muito compartilhado pode exigir uma fronteira explícita de compatibilidade, uma transferência gradual de responsabilidade ou um período em que componentes antigos e novos coexistam. A medida altera a sequência porque mostra onde uma mudança correta localmente ainda pode quebrar o acervo.

O código morto muda o denominador

A proporção de código morto é a parte do acervo que não pode ser executada na configuração de produção definida. Ela deve reduzir o escopo de implementação, mas somente depois que a equipe provar por que o código está morto. Apagar um diretório porque ninguém se lembra dele não é análise.

Use três rótulos. Código inalcançável não tem caminho a partir de um ponto de entrada configurado. Código não observado tem um caminho possível, mas não foi executado durante a janela de observação. Comportamento desativado tem uma decisão respaldada por um responsável de que o substituto não o preservará. Esses rótulos não substituem uns aos outros. A documentação da IBM para identificar código COBOL inalcançável afirma explicitamente que o resultado vem de análise estática e não reflete o caminho real de execução. Essa limitação explica por que evidências estáticas e dinâmicas precisam ficar separadas.

A configuração define a alcançabilidade. Um módulo não usado na programação dos dias úteis pode executar no fechamento trimestral. Uma transação CICS pode estar desabilitada em uma região e ativa em outra. Membros JCL podem ser selecionados por variáveis do agendador. Um executável de desktop pode carregar um plugin indicado em um arquivo de configuração local que nunca chegou ao controle de versão. Monte o conjunto de pontos de entrada a partir de agendas de produção, definições de transações, manifestos de implantação, procedimentos de comando, jobs registrados e manuais dos operadores, não apenas de um grafo de chamadas enraizado no programa principal mais óbvio.

Depois, calcule várias proporções: instruções estaticamente inalcançáveis, instruções alcançáveis mas não observadas, instruções alcançáveis duplicadas e comportamento aprovado para desativação. Dê a cada uma um nível de confiança e uma referência de evidência. A estimativa deve excluir apenas a parte desativada. Código inalcançável com configuração incerta pertence a uma fila de resolução, enquanto código não observado ainda precisa de testes direcionados ou de uma decisão de negócio.

Código morto ainda pode conter pistas úteis. Uma ramificação antiga pode explicar a codificação de um campo ou o layout de um relatório que sobrevive em outro lugar. Preserve o código-fonte e o registro da análise mesmo quando o novo sistema omitir o comportamento. O erro é pagar para traduzir rotinas mortas como se fossem requisitos. O erro oposto é apagá-las antes que a equipe entenda os contratos ativos que cresceram ao redor delas.

A superfície de integração é contada em contratos

Uma integração não é uma única caixa em um diagrama de arquitetura. É um contrato com transporte, formato de dados, regra de horário, comportamento de erro, fronteira de responsabilidade, mecanismo de segurança e procedimento de recuperação. Conte esses contratos e depois meça quanto eles diferem.

Um arquivo noturno de largura fixa pode custar mais para ser reproduzido do que dez endpoints HTTP comuns. O arquivo pode exigir um nome exato, página de código, tamanho de registro, ordem de classificação, total de conferência, janela de chegada, convenção de reexecução e confirmação manual. Um receptor pode interpretar bytes de preenchimento não documentados. Nada disso aparece em uma contagem de linhas. Boa parte pode nem aparecer no programa emissor porque o agendador, o produto de transferência e o procedimento do operador carregam partes do comportamento.

Inventarie toda borda externa e toda borda interna que cruze uma fronteira de responsabilidade ou implantação. Inclua bancos de dados controlados por outra equipe, arquivos de entrada e saída, filas, chamadas de procedimento remoto, protocolos de terminal, e-mail, saída de impressora, provedores de identidade, interfaces de hardware, planilhas usadas como modelos de importação e transferências manuais acionadas por um relatório. Não agrupe cinco arquivos como “feed do parceiro” se eles tiverem agendas ou tratamento de falhas diferentes.

Para cada contrato, registre direção, protocolo, localização do esquema, frequência, padrão de pico, ordenação, idempotência, regra de nova tentativa, tempo limite, autenticação, criptografia, produtor, consumidor, ambiente de testes e uma amostra capturada em produção. Desconhecido é um valor legítimo. Também é trabalho. Uma célula vazia nunca deve virar silenciosamente a suposição de que o padrão da plataforma de destino será compatível.

A superfície de integração tem duas pontuações úteis. A contagem de contratos mede a amplitude. A novidade dos contratos mede quantos mecanismos diferentes a equipe precisa reproduzir ou substituir. Vinte arquivos que compartilham um gerador e um protocolo de confirmação podem formar uma família de implementação. Quatro interfaces que usam uma fila de mainframe, um fluxo de controle de impressora, uma integração proprietária de automação no desktop e um compartilhamento montado manualmente criam quatro problemas de descoberta e teste.

Preste atenção especial ao comportamento negativo. Consumidores podem depender de um arquivo vazio, um código de retorno específico, uma nova tentativa atrasada, entrega duplicada ou ausência de uma linha. Amostras do caminho de sucesso raramente capturam esses contratos. Reúna logs de falha e registros de reexecução. Pergunte aos operadores o que fazem quando o artefato esperado não chega. A ação deles muitas vezes faz parte do sistema, embora nenhum compilador consiga vê-la.

A saída de produção pode ser a única especificação

Alguns comportamentos legados existem apenas no que a produção emite. O código os calcula, usuários e sistemas posteriores dependem deles, mas nenhum requisito atual os explica. Essa lacuna merece uma medida própria porque altera o trabalho de descoberta e verificação.

Primeiro, conte as superfícies de comportamento: respostas de API, alterações no banco de dados, arquivos, mensagens, campos de tela, relatórios impressos, registros de auditoria, códigos de retorno, eventos de tempo e avisos ao operador. Para cada superfície, classifique a fonte da especificação como documentação atual, testes executáveis, inferência do código, confirmação de um especialista ou observação da produção. Várias fontes podem se aplicar. A categoria perigosa é “somente produção”: nenhum documento ou teste confiável define o resultado, e as pessoas julgam a correção comparando o que o sistema antigo produz.

“Somente produção” não precisa continuar misterioso. Capture pares representativos de entrada e saída, normalize campos voláteis, como carimbos de data e hora ou identificadores gerados, e reproduza as entradas no sistema antigo em condições controladas quando possível. Preserve ordenação, arredondamento, codificação, tratamento de espaços em branco e saída de erros antes que alguém os “limpe”. Um espaço no final pode ser irrelevante em um relatório e marcar a fronteira de um campo em outro.

Meça isso como proporção ponderada, não como contagem bruta de saídas. Dê mais peso às saídas que movimentam dinheiro, fecham livros, controlam trabalho físico, atendem a uma revisão de auditoria ou alimentam outro sistema. Registre também a cobertura: quanta variedade de entrada, de calendário e de comportamento de falha o tráfego capturado contém. Trinta dias de solicitações online podem cobrir caminhos comuns e ainda perder o processamento de fim de ano. Um milhão de verificações repetidas de integridade quase não acrescenta conhecimento do comportamento.

É aqui que estimativa e verificação se encontram. Se o comportamento está documentado e testado, a equipe de substituição pode implementar contra um contrato explícito. Se ele vive apenas na saída, a equipe precisa descobrir o contrato, construir um comparador, classificar diferenças e obter uma decisão quando o comportamento antigo for inconsistente. Esse trabalho existe mesmo que a rotina responsável tenha apenas 80 linhas.

Tráfego registrado é evidência, não um oráculo. Ele pode conter resultados errados, defeitos mascarados, dados sensíveis e dependências acidentais. Aplique controles de acesso e minimização, identifique campos que não podem sair do perímetro do cliente e peça a um responsável designado que decida se uma diferença mostra uma regressão ou um defeito antigo que deve ser desativado. Paridade automatizada sem esse processo de decisão pode preservar erros com uma precisão impressionante.

Um perfil de tamanho mantém riscos diferentes separados

Combine as medidas em um perfil, não em uma pontuação ponderada universal. Um único número parece conveniente, mas destrói as informações necessárias para escolher a arquitetura, sequenciar o trabalho e definir a profundidade da verificação. Dois sistemas podem receber a mesma pontuação enquanto um tem lógica de decisão concentrada e o outro tem código simples atrás de dezenas de interfaces frágeis.

O perfil deve conter vários registros vinculados para a configuração de produção avaliada. O registro do acervo contém instruções lógicas e proporções por linguagem, geração, duplicação e comentários. O registro de decisões contém complexidade e aninhamento máximo, com mediana, percentil 90, máximo e pontos críticos alcançáveis. O registro de concentração de dados contém leitores e gravadores por ativo, pares de transação, modos de execução e acessos observados.

O registro de alcançabilidade contém proporções desativadas e não resolvidas ao lado de raízes estáticas, janela de execução e decisões dos responsáveis. O registro de contratos contém interfaces distintas, famílias de mecanismos, amostras de falha e acesso de teste. O registro de evidência comportamental contém superfícies ponderadas conhecidas apenas em produção, variedade de entradas capturadas, lacunas de calendário e o responsável por decisões sobre divergências. Mantenha identificadores estáveis entre esses registros para que um revisor passe de um ponto crítico à sua evidência sem comparar descrições manualmente.

Versione o perfil com os pontos de entrada, o conjunto de configurações, o período de observação, as versões das ferramentas e as exclusões. Caso contrário, uma análise posterior pode parecer contradizer a avaliação quando apenas usou raízes diferentes do agendador ou expandiu os copybooks de outra forma.

Use faixas em vez de falsa precisão. Para profundidade das decisões, uma faixa pode distinguir rotinas comuns, pontos críticos de revisão e candidatas a decomposição. Para fan-in de dados, pode separar ativos isolados, modelos de leitura compartilhados e responsabilidade de gravação disputada. Defina cada faixa em termos de ação. Uma célula vermelha deve significar “exige uma fronteira de compatibilidade e revisão do responsável”, não “parece assustadora”.

O perfil também expõe a incerteza. Marque se cada valor vem de análise estática, observação em execução, registros de configuração ou decisão de um responsável. Anexe uma referência de evidência e o nível de confiança. Uma regra desconhecida de nova tentativa de integração e uma contagem exata de 200.000 linhas não devem virar uma média tranquilizadora. A incerteza pode dominar o risco de transição.

Armazene observações brutas ao lado dos valores derivados. Se um analisador informar 26 chamadores e os registros de execução mostrarem 19, preserve os dois números e o status da conciliação. Um trabalho posterior pode provar que cinco chamadores pertencem a agendas desativadas e duas chamadas são aliases dinâmicos. Substituir o número anterior destrói a trilha de auditoria e faz a estimativa parecer mais certa do que a avaliação jamais foi. A mesma regra vale para normalização de complexidade, detecção de duplicatas e cobertura do tráfego.

Para estimar, converta itens do perfil em pacotes de trabalho com condições observáveis de conclusão. Um ponto crítico de decisão fica pronto quando sua tabela de comportamento, implementação e casos de paridade são aceitos. Um ativo de dados fica pronto quando responsabilidade, comportamento transacional, regra de migração e consumidores são considerados. Uma integração fica pronta quando caminhos de sucesso, falhas, novas tentativas e passagem para a operação funcionam no ambiente de destino. Uma superfície conhecida apenas em produção fica pronta quando os casos capturados coincidem ou um responsável aprova cada diferença intencional.

Isso mantém os multiplicadores locais. Uma rotina de alta complexidade afeta o pacote de trabalho ao qual pertence. Ela não torna arbitrariamente toda transferência de arquivo e toda tela duas vezes mais caras. Um relatório mal especificado acrescenta descoberta e comparação àquela superfície de saída. Não infla o código morto. Fatores locais são mais fáceis de questionar, revisar e verificar.

Estime unidades de evidência, não linhas de substituição

Quando o perfil existir, estime unidades de comportamento preservado e comprovação. Comece pelas capacidades alcançáveis e divida-as onde a responsabilidade pelos dados, os contratos de integração ou os métodos de verificação forem diferentes. A contagem de linhas do destino é desconhecida e quase irrelevante. O trabalho de arquitetura pode remover repetição, combinar programas ou substituir lógica procedural de apoio por recursos da plataforma.

Para cada unidade, estime quatro atividades: descoberta, projeto e implementação do destino, construção de evidências e aceitação. A descoberta inclui resolver chamadas dinâmicas, layouts ausentes, responsáveis e regras conhecidas apenas em produção. A construção de evidências inclui captura de tráfego, dados de teste, comparadores e casos de falha esperados. A aceitação inclui a revisão das diferenças por alguém autorizado a decidir se o comportamento antigo continua obrigatório.

Não esconda a incerteza dentro de um número maior de esforço. Mantenha um registro de premissas com um teste e um responsável. “RATE-CONTROL não tem gravadores interativos” pode ser testado com registros de acesso e revisão dos operadores. “Todos os jobs de fechamento trimestral aparecem na exportação do agendador” pode ser testado contra o histórico de execução. Resolva cedo as premissas de alto impacto porque elas podem alterar fronteiras, não apenas horas.

Uma comparação prática deixa a ideia clara. O sistema A tem 700.000 instruções lógicas, 45 por cento de comportamento desativado com aprovação, profundidade moderada de decisão, dois centros de dados com muita gravação e seis famílias de integração com casos de falha capturados. O sistema B tem 180.000 instruções, quase nenhum comportamento desativado, várias rotinas de liquidação profundamente aninhadas, nove ativos de dados com responsabilidade disputada e saídas cujas regras existem apenas em relatórios de fechamento mensal. Uma estimativa por linhas torna A quase quatro vezes maior. Um perfil comportamental pode mostrar com justificativa que B carrega mais trabalho de descoberta e aceitação. O perfil não prova o preço. Mostra por que o preço deve seguir a evidência, e não o volume de texto.

Esse método também torna comparáveis as estimativas dos fornecedores. Peça a cada participante seus pontos de entrada contados, classificação de alcançabilidade, distribuição de complexidade, ativos de alto fan-in, inventário de contratos, superfícies conhecidas apenas em produção e premissas não resolvidas. Se um fornecedor apresenta um multiplicador de linhas e outro identifica os nove ativos com gravadores concorrentes, fica claro quem examinou o sistema e quem precificou uma história.

CodeHero lê toda a árvore de código em paralelo e depois verifica o comportamento modernizado contra o tráfego de produção registrado por meio de um sistema de paridade. Essa combinação trata escala do acervo e comprovação do comportamento como problemas separados. A distinção importa mais do que qualquer afirmação sobre quantas linhas uma ferramenta consegue ingerir.

A aprovação deve seguir a trilha das medidas

Uma estimativa confiável de um sistema legado permite que outro engenheiro rastreie o escopo até as evidências. Deve ser possível selecionar qualquer pacote de trabalho importante e encontrar os pontos de entrada que o alcançam, as decisões que contém, os dados que lê ou grava, os contratos que atravessa e os exemplos de produção que definem a aceitação.

Antes de aprovar um plano, pergunte o que o avaliador excluiu e sob a autoridade de quem. Pergunte quais períodos de execução a observação cobriu, incluindo caminhos de fechamento trimestral ou anual. Peça os maiores pontos críticos de complexidade, em vez de uma média. Pergunte quais ativos de dados têm vários gravadores. Pergunte quais interfaces não têm amostras de falha. Pergunte quais saídas não possuem especificação além da produção. Respostas diretas podem incluir incerteza. Confiança vaga deve interromper a aprovação.

A contagem de linhas ainda cabe na primeira página porque descreve o material analisado. Ela deve ficar ao lado das proporções de código morto e gerado, não acima das medidas que descrevem o comportamento. A estimativa deve mudar quando aparece um gravador oculto, quando um job supostamente morto se mostra ativo ou quando uma saída não tem exemplos suficientes. Se ela muda apenas quando alguém encontra outro diretório de arquivos-fonte, o modelo está medindo inventário e chamando isso de engenharia.

O primeiro resultado pelo qual vale pagar é o perfil de tamanho versionado e seu registro de evidências. Ele cria uma base concreta para decisões de arquitetura e comerciais e dá à equipe de substituição uma definição de pronto que resiste ao contato com a produção.