3.7 Manutenção de software

Visão geral e motivação

A maior parte do software passa a esmagadora maioria da vida não sendo construída, mas sendo mantida. No momento em que um sistema entra em produção, ele entra numa fase (muitas vezes de anos ou décadas) de corrigir defeitos, adaptar-se a um ambiente em mudança, melhorar o que já funciona e prevenir problemas futuros. Em grandes empresas, e especialmente no governo, essa fase domina. Motores tributários, sistemas de benefícios, plataformas de defesa e livros-razão financeiros centrais são rotineiramente mantidos por muito mais tempo do que qualquer um que os encomendou esperava. A manutenção de software é a disciplina de manter o software entregue correto, atual e valioso durante toda a sua vida operacional.

A manutenção é cronicamente subestimada e desvalorizada, e esse erro é caro. Estudo após estudo, ao longo de décadas, coloca a manutenção bem acima da metade do custo total do ciclo de vida do software, comumente citada na faixa de 60 a 90 por cento para sistemas de longa vida. Ainda assim as organizações planejam, orçam, dotam de pessoal e celebram a construção inicial como se fosse todo o empreendimento. Depois tratam tudo que vem depois como reflexão tardia, financiado por um bolo cada vez menor e atribuído a quem estiver disponível. O resultado é previsível: sistemas frágeis, mantenedores desmoralizados, custo crescente de mudança e, por fim, uma crise enquadrada como “problema de legado” (capítulo 3.6) quando era, desde sempre, um problema de manutenção sem gestão.

Este capítulo segue a área de conhecimento de Manutenção de Software do SWEBOK (Software Engineering Body of Knowledge) e a ISO/IEC 14764. Ele cobre os fundamentos da manutenção e as quatro categorias reconhecidas, as questões-chave que tornam a manutenção difícil, incluindo custo, pessoal e moral, o processo de manutenção, as técnicas centrais de compreensão de programas, reengenharia e refatoração, como estimar o custo de manutenção e (a ideia de maior alavancagem do capítulo) como projetar para a manutenibilidade desde o início. A convicção central é que a manutenção não é uma atividade menor que vem depois da engenharia. É a maior parte da engenharia de software e precisa ser planejada, financiada e respeitada como tal.

Princípios fundamentais

A manutenção é a maior parte do ciclo de vida, não um epílogo. Planeje e orce para ela desde o primeiro dia. Ela custará mais que a construção.
As quatro categorias são trabalhos diferentes. A manutenção corretiva, adaptativa, perfectiva e preventiva têm direcionadores e cadências diferentes. A maior parte do esforço não é corrigir bugs.
Você não consegue mudar o que não entende. A compreensão de programas é a maior atividade isolada da manutenção. Torne legíveis o código e o seu histórico.
A manutenibilidade é uma propriedade de design. O custo da mudança futura é definido em grande parte por decisões tomadas durante a construção. Projete para ela deliberadamente.
Mudança pequena, segura e contínua vence mudança grande adiada. Refatore e modernize de forma incremental sob uma rede de segurança de testes em vez de acumular uma dívida de mudança.
O software envelhece mesmo parado. O ambiente se move (dependências, plataformas, regulamentações), então um sistema estático apodrece em silêncio. A manutenção preventiva é trabalho de verdade.
Os mantenedores merecem status de primeira classe. A moral, a retenção de conhecimento e o pessoal das equipes de manutenção determinam diretamente o custo e o risco de longo prazo.

Recomendações

Distinga as quatro categorias de manutenção e dote de pessoal todas elas

A ISO/IEC 14764 e o SWEBOK reconhecem quatro categorias, e confundi-las é um erro comum de planejamento. A manutenção corretiva corrige defeitos encontrados em operação. A manutenção adaptativa mantém o software funcionando à medida que o ambiente muda: novos sistemas operacionais, navegadores, dependências, hardware, regulamentações ou sistemas com que ele faz interface. A manutenção perfectiva melhora o software para usuários e mantenedores, por meio de novas funcionalidades, melhor desempenho, usabilidade aprimorada e manutenibilidade aumentada. A manutenção preventiva corrige falhas latentes e reduz o risco futuro antes que se manifeste, por meio de endurecimento, limpeza e modernização de áreas frágeis. Uma divisão adicional útil agrupa a corretiva e a preventiva como correção (lidar com falhas) e a adaptativa e a perfectiva como aprimoramento (lidar com novos requisitos). De forma crucial, os estudos empíricos constatam consistentemente que a maior parte da manutenção não é corretiva: o aprimoramento e a adaptação dominam. Oriente o orçamento e o pessoal de acordo e acompanhe em qual categoria o seu esforço de fato cai para poder geri-lo.

Invista na compreensão de programas

A maior atividade isolada da manutenção é entender o sistema existente o bastante para mudá-lo com segurança. Os mantenedores rotineiramente gastam mais tempo lendo e raciocinando sobre o código do que modificando-o. Torne isso mais barato de propósito. Mantenha a documentação perto do código e atual (capítulo 2.7). Preserve o histórico de decisões por meio de registros de decisão de arquitetura (capítulo 1.6) e de um histórico de commits limpo (capítulo 2.6). Use análise estática, grafos de dependência e ferramentas de navegação de código para mapear território desconhecido. Os testes de caracterização (testes que fixam o comportamento atual, inclusive as esquisitices) transformam o entendimento tácito em conhecimento executável e durável. Quando a compreensão é cara, toda mudança é lenta e arriscada. Quando é barata, a manutenção vira rotina.

Refatore continuamente sob uma rede de segurança de testes

A refatoração é a reestruturação disciplinada do código que melhora sua qualidade interna sem mudar seu comportamento externo. Feita continuamente e em pequenos passos, ela contraria a deriva natural rumo à complexidade e mantém plano, em vez de crescente, o custo da mudança. A pré-condição inegociável é uma suíte confiável de testes automatizados (capítulo 2.4). Sem ela, “refatorar” é só reescrever com risco. Incorpore a refatoração ao trabalho cotidiano: deixe cada módulo um pouco mais limpo do que o encontrou, em vez de guardá-la para limpezas raras, grandes e perigosas. Essa é a manutenção preventiva na prática, e é a manutenção mais barata que existe.

Faça reengenharia quando a mudança incremental já não bastar

Quando um componente se degradou ao ponto de a mudança rotineira ser cara ou arriscada demais, a reengenharia (examinar e alterar um sistema para reconstituí-lo em nova forma) é a ferramenta mais pesada. A reengenharia costuma combinar a engenharia reversa (recuperar design e intenção a partir da implementação) com a reengenharia para a frente (reconstruir numa estrutura melhor preservando o comportamento). Prefira fazer a reengenharia em fatias delimitadas e incrementais, usando padrões como a figueira-estranguladora e a ramificação por abstração (capítulo 3.6), e não como uma reescrita total. A reengenharia fica no continuum da manutenção à modernização: refatoração para o pequeno e local, reengenharia para o estrutural e modernização para o nível da plataforma.

Conduza um processo de manutenção definido

A manutenção se beneficia de um processo explícito e repetível, como descrito na ISO/IEC 14764: implementação do processo (estabelecer planos e procedimentos), análise de problemas e de modificações (triagem, reprodução, avaliação de impacto e de custo), implementação da modificação, revisão e aceitação da manutenção, migração e aposentadoria. Envolva-o numa gestão disciplinada de mudanças: todo pedido de manutenção (seja um relato de defeito ou um aprimoramento) deve ser registrado, classificado por categoria, avaliado quanto ao impacto, priorizado, implementado sob controle de versões com testes, revisado e lançado pelo pipeline normal (capítulo 11.2). A análise de impacto, entender tudo que uma mudança proposta pode tocar, é central e merece esforço real. A aposentadoria também faz parte do processo: desativar um sistema com segurança, migrar seus dados e usuários e preservar os registros é trabalho de manutenção que precisa ser planejado, não improvisado.

Estime o custo de manutenção explicitamente e financie-o

Não trate a manutenção como gratuita nem como ruído no orçamento de construção. Estime-a. As abordagens comuns incluem as razões de esforço de manutenção (a regra prática amplamente usada de que a manutenção anual gira em torno de 15 a 25 por cento do custo original de desenvolvimento, embora sistemas críticos de longa vida acumulem muito mais ao longo da vida), os modelos paramétricos como o COCOMO II (Constructive Cost Model) com suas extensões de manutenção e reutilização e a previsão guiada por métricas a partir dos seus próprios dados históricos de taxas de defeitos, volume de mudanças e custo de mudança. Alimente essas estimativas na análise de custo total de propriedade e na economia discutida no capítulo 10.10. O preço de compra ou o custo de construção de um sistema é uma entrada. A hipoteca é a manutenção, e ela deve aparecer em todo argumento de negócio.

Projete para a manutenibilidade desde o início

A maior alavancagem sobre o custo de manutenção é exercida antes de a manutenção começar. A manutenibilidade (analisabilidade, modificabilidade, testabilidade e modularidade, no vocabulário da ISO/IEC 25010) é uma qualidade de design que precisa ser um requisito explícito, não um feliz acaso. Favoreça designs modulares, fracamente acoplados e de alta coesão (capítulo 2.2), interfaces claras e separação de responsabilidades, fortes testes automatizados, código legível e documentação atual e observabilidade rica para que operadores e mantenedores vejam o que o sistema está fazendo (Parte 9). Cada uma dessas decisões troca um pouco mais de esforço agora por grandes economias cumulativas ao longo das décadas em que um sistema de fato viverá. Construir para a manutenibilidade é o investimento de maior retorno em todo o ciclo de vida.

Compromissos: prós e contras

Abordagem	Prós	Contras
Refatoração contínua / manutenção preventiva	Mantém plano o custo da mudança, reduz o risco, alto ROI	Esforço contínuo sem novas funcionalidades visíveis. Exige testes fortes
Adiar a manutenção (“manter as luzes acesas”)	O mais barato neste trimestre. Libera capacidade para funcionalidades	A dívida de mudança se acumula. Crise eventual e ação forçada e cara
Reengenharia de um componente degradado	Restaura a manutenibilidade e estende a vida útil	Esforço e risco significativos. O comportamento precisa ser preservado com cuidado
Projetar para a manutenibilidade desde o início	Economias cumulativas ao longo da vida. Mais fácil toda mudança futura	Maior custo inicial e disciplina. Os benefícios são diferidos e menos visíveis

A troca recorrente na manutenção é custo presente versus custo futuro, e a tentação sempre corre para o adiamento. Pular a refatoração, deixar as dependências envelhecerem e deixar a equipe de manutenção sem recursos parecem todos gratuitos neste trimestre, porque a conta chega depois: como um sistema mais lento, mais arriscado e mais caro e, por fim, como uma “crise de legado”. A disciplina da boa manutenção é pagar custos pequenos, contínuos e visíveis agora para evitar custos grandes, súbitos e definidores de carreira depois. Como as economias são diferidas e invisíveis, essa troca exige uma liderança que entenda a economia do ciclo de vida, e não apenas datas de lançamento.

Perguntas para discutir com sua equipe

Quem é dono do número de manutenção no seu orçamento, e ele é uma linha de primeira classe ou um resíduo raspado do que a construção não gastou? A manutenção é a maior parte do custo do ciclo de vida, comumente de 60 a 90 por cento para sistemas de longa vida, e ainda assim é rotineiramente financiada como reflexão tardia e dotada de pessoal por quem estiver livre. Quando o orçamento é residual, o trabalho preventivo é o primeiro a ser cortado, a dívida de mudança se acumula e segue-se um deslize previsível para uma “crise de legado”. Levem uma estimativa de verdade (uma razão de esforço de manutenção, um modelo paramétrico ou os seus próprios dados históricos de custo de mudança) e nomeiem a pessoa responsável por financiá-la ao longo da vida do sistema. A correção é orçar a manutenção explicitamente em todo argumento de negócio, do jeito que uma hipoteca fica ao lado de um preço de compra. Uma liderança que só celebra lançamentos continuará subfinanciando a fase em que de fato moram a maior parte do dinheiro e do risco.
Vocês reservam capacidade para a manutenção preventiva, ou ela sempre perde para a próxima funcionalidade? O trabalho preventivo (refatorar sob uma rede de testes, manter as dependências atuais, endurecer áreas frágeis) é a manutenção mais barata que existe, porque mantém plana a curva do custo de mudança em vez de deixá-la subir. É também o mais fácil de adiar, já que pulá-lo parece gratuito neste trimestre e a conta chega depois como um sistema mais lento e mais arriscado. Um mecanismo concreto ajuda: uma alocação permanente, e muitas equipes fortes protegem cerca de um quinto da capacidade, que é guardada em vez de negociada a cada sprint. Levem a tendência do seu custo de mudança como evidência. Se ela está subindo, vocês já estão investindo de menos. A disciplina é pagar custos pequenos e visíveis agora para evitar custos grandes, súbitos e definidores de carreira depois, e isso exige uma liderança que leia a economia do ciclo de vida e não as datas de lançamento.
Qual é o plano de vocês para aposentar um sistema, e quando foi a última vez que realmente desativaram um? A aposentadoria é uma parte explícita do processo de manutenção (migração de dados, virada de usuários, preservação de registros, desligamento seguro), e ainda assim as organizações carregam sistemas mortos e redundantes por anos porque a desativação é pouco glamorosa e sem orçamento. Todo sistema zumbi ainda consome licenças, correções de segurança, superfície de integração e a atenção de pessoas que poderiam estar em outro lugar. Levem um inventário e sinalizem os sistemas sem usuários ativos ou com uma substituição completa já em operação, depois planejem o desligamento deles como qualquer outro trabalho: migrem os dados, preservem o que a lei exige e confirmem que nada mais depende deles. No governo especialmente, a lei de retenção de registros molda como vocês aposentam, então envolvam a conformidade cedo. Um sinal de maturidade que vale acompanhar: quando foi a última vez que a sua organização desligou algo deliberadamente?
Quanto de cada mudança é gasto entendendo o sistema antes de tocá-lo, e qual é o seu fator ônibus nos sistemas que mais importam? A compreensão de programas é a maior atividade isolada da manutenção, e seu custo é definido por quão legíveis vocês mantiveram o código, seu histórico e seu comportamento. Quando o entendimento vive apenas em poucas cabeças de longa permanência, cada saída ou aposentadoria eleva o preço de toda mudança futura, e uma única ausência pode travar uma correção crítica. Levem evidências: a razão entre o tempo de leitura e raciocínio e o tempo de edição nas mudanças recentes, o número de pessoas que conseguem modificar com segurança cada módulo central e se as regras de negócio e as decisões são documentadas junto ao código ou reconstruídas de memória a cada vez. A consideração concorrente é que a documentação e os testes de caracterização custam esforço agora por economias que só aparecem depois, então são fáceis de pular. Em contextos corporativos e governamentais, onde os sistemas sobrevivem aos autores originais por décadas e regras estatutárias estão enterradas num motor de cálculo de que ninguém se lembra por inteiro, tratem a compreensão capturada (registros de decisão de arquitetura, testes de caracterização, documentação atual) como um ativo que vocês financiam deliberadamente, e não uma cortesia que acontece quando alguém tem tempo sobrando.
Quem de fato dota de pessoal o seu trabalho de manutenção, e o status e a moral dele correspondem à sua importância? A manutenção é a maior parte do custo do ciclo de vida e a engenharia mais difícil que existe, mudar com segurança sistemas que você não construiu e talvez não entenda por completo, e ainda assim é rotineiramente entregue às pessoas menos experientes e enquadrada como um “manter as luzes acesas” de baixo status. Esse sinal é corrosivo: seus melhores engenheiros evitam o trabalho, o conhecimento se concentra e depois sai pela porta, e o custo da mudança sobe enquanto ninguém está olhando. Levem o perfil de senioridade de quem mantém seus sistemas mais longevos, seus dados de rotatividade e de retenção de conhecimento e uma leitura honesta de se a manutenção é um beco sem saída ou uma especialização respeitada na sua organização. A tensão é real, já que engenheiros ambiciosos querem construir coisas novas e os líderes querem celebrar lançamentos, então respeitar a manutenção exige estrutura deliberada. Para uma grande empresa ou órgão público que opera sistemas que carregam risco regulatório e financeiro por décadas, dotar a manutenção de engenheiros seniores respeitados é uma decisão de gerenciamento de riscos, e deixar a manutenção virar um posto de punição é como se fabrica a próxima crise de legado.
Vocês acompanham em qual das quatro categorias o seu esforço de fato cai, e estão medindo o custo de mudança como um indicador antecedente? As equipes rotineiramente planejam a manutenção como se fosse em sua maioria correção de bugs, quando os estudos empíricos mostram que o aprimoramento e a adaptação dominam, então um portfólio financiado apenas para trabalho corretivo está mal dimensionado desde o início. Sem o acompanhamento por categoria vocês não conseguem ver que um sistema está sendo remodelado por um fluxo constante de adaptações regulatórias, e sem uma métrica de custo de mudança (prazo de mudança, taxa de falha de mudanças, tendências de complexidade) vocês não conseguem dizer se a curva está plana ou subindo em silêncio rumo a uma crise. Levem a sua divisão real por categoria no último ano, a sua tendência de custo de mudança se tiverem uma e uma nota honesta de se a análise de impacto é uma etapa real ou uma formalidade pulada sob pressão de prazo. A atração concorrente é que a própria medição dá esforço e pode parecer custo operacional quando o sistema ainda funciona. Em portfólios corporativos e governamentais, onde muitas equipes mantêm muitos sistemas e uma curva de custo crescente em qualquer um deles é um alerta precoce que vale a pena agir, o acompanhamento compartilhado por categoria e os indicadores de custo de mudança são o que permite à liderança fazer a reengenharia de um módulo antes que ele se degrade e não depois que falhar em público.

Perspectiva por setor

Startup. Com um punhado de engenheiros e pouca pista, você não pode bancar um processo pesado de manutenção, mas também não pode bancar uma base de código que ninguém vai tocar. Reserve uma pequena fatia permanente de cada ciclo (cerca de um dia em cinco) para o trabalho preventivo: atualize dependências, limpe pequenos defeitos antes que se acumulem e refatore os cantos que você já teme sob os testes que tiver. O objetivo é manter o código barato de mudar enquanto você muda de rumo, para nunca acordar com vinte engenheiros confundindo manutenção adiada com um “problema de legado”.

Pequena empresa. Sem especialista dedicado em manutenção e com orçamento apertado, incline-se para comprar e hospedar em vez de construir, de modo que a manutenção adaptativa (correções de segurança, atualizações de plataformas e de dependências) seja em grande parte tarefa de outra pessoa. Onde você for dono de código, mantenha-o pequeno, chato e bem documentado e garanta que pelo menos duas pessoas entendam tudo de que o negócio depende. Acompanhe o punhado de sistemas que vocês não podem se dar ao luxo de perder e orce uma linha modesta e explícita para mantê-los atuais em vez de fingir que a manutenção é gratuita.

Grande empresa. Em escala vocês mantêm muitos sistemas de longa vida em muitas equipes, então a prioridade é um processo definido e repetível: um pipeline registrado e triado de pedidos, a classificação nas quatro categorias, uma análise de impacto rotineira e uma alocação preventiva permanente guardada em vez de negociada. Financiem a manutenção como um programa de primeira classe, meçam indicadores de custo de mudança em todo o portfólio e usem uma curva crescente como gatilho para fazer a reengenharia de um módulo antes que ele vire um passivo. As expectativas de governança e de auditoria significam que o acompanhamento por categoria e os registros de mudanças não são custo operacional: são a evidência de que o parque está sob controle.

Governo. As regras de contratação, a transparência e a responsabilização pública moldam a manutenção tanto quanto a engenharia. A manutenção adaptativa guiada por lei chega com prazos anuais rígidos que não podem escorregar, então orcem a manutenção como um custo operacional indefinido e dotem de pessoal uma equipe estável de especialistas para reter o conhecimento de regras cujos autores se aposentaram há muito. A aposentadoria é limitada pela lei de retenção de registros, então planejem a desativação com a conformidade desde o início e favoreçam contratos e arquiteturas que mantenham o sistema mantível e portável em vez de prendê-los a um único fornecedor por décadas.

Exemplos

Startup. Uma startup que acabou de entregar o MVP é tentada a despejar todas as horas em novas funcionalidades, mas seu engenheiro fundador reserva uma fatia permanente de cada sprint (cerca de um dia em cinco) para manutenção desde o primeiro mês. Esse orçamento mantém as dependências corrigidas, limpa pequenos defeitos antes que se acumulem e refatora os cantos que a equipe já teme, de modo que a base de código continua barata de mudar enquanto o produto muda de rumo. As startups que pulam isso chegam a vinte engenheiros com uma base de código que ninguém quer tocar e a confundem com um “problema de legado” quando era manutenção adiada desde sempre.

Grande empresa. Um banco global opera uma plataforma de pagamentos que está em produção há quinze anos. Ele financia a manutenção como um programa permanente de primeira classe e não como uma linha de orçamento residual. O trabalho é triado nas quatro categorias: um fluxo constante de mudanças adaptativas acompanha as novas regulamentações e as atualizações de interface dos bancos parceiros, o trabalho perfectivo acrescenta funcionalidades e melhora a vazão, o trabalho corretivo limpa defeitos contra acordos rigorosos de nível de serviço (SLAs) e uma alocação preventiva permanente (cerca de um quinto da capacidade da equipe) quita complexidade por refatoração contínua sob uma suíte completa de testes. A equipe mede o prazo de mudança e a taxa de falha de mudanças e trata um custo de mudança crescente como alerta precoce para fazer a reengenharia de um módulo antes que ele vire um passivo. Os mantenedores são engenheiros seniores e bem-conceituados, não pessoal júnior estacionado em “manter as luzes acesas”.

Governo. Uma autoridade tributária nacional mantém um sistema que funciona há mais de trinta anos e é emendado todo ano conforme a lei tributária muda. A categoria dominante aqui é a manutenção adaptativa guiada por lei, com prazos anuais rígidos que não podem escorregar. A autoridade investe pesado na compreensão de programas: as regras de negócio são documentadas ao lado do código, os testes de caracterização fixam o comportamento de regras cujos autores originais se aposentaram há muito e a análise de impacto é uma etapa formal antes de qualquer mudança no motor de cálculo. Como o ambiente (a lei) muda continuamente, o sistema nunca pode ser “terminado”, então a autoridade orça a manutenção como um custo operacional indefinido, dota de pessoal uma equipe estável de especialistas para reter o conhecimento e moderniza as práticas de entrega ao redor, como controle de código-fonte, integração contínua (CI) e testes automatizados, mesmo com o núcleo permanecendo.

Justificativa de negócio: motivações, ROI e TCO

O fato de negócio central do software é que a manutenção, e não a construção, é para onde vai o dinheiro. Em toda a indústria e ao longo de décadas de estudo, a manutenção responde pela clara maioria do custo do ciclo de vida, frequentemente citada em 60 a 90 por cento para sistemas que vivem muito, que em empresas e governo são a maioria deles. Qualquer análise de custo total de propriedade que pare na entrada em produção está errada por um fator de vários. O principal argumento de negócio para levar a manutenção a sério é simplesmente a precisão: orce para a vida inteira do sistema ou seja repetidamente surpreendido pela conta.

O retorno do investimento vem de dobrar a curva de custo. Num sistema negligenciado, o custo de cada mudança sobe com o tempo à medida que a complexidade se acumula e a compreensão decai, até a mudança se tornar proibitivamente lenta e arriscada. Num sistema bem mantido, o trabalho preventivo contínuo (refatoração, atualidade das dependências, cobertura de testes, documentação) mantém plana essa curva, de modo que a milésima mudança custa mais ou menos o que a décima custou. Investir em manutenibilidade e em manutenção preventiva portanto não é uma despesa a minimizar. É a alavanca que determina se um sistema continua acessível de mudar ou deriva para o custo e o risco crescentes de um parque legado (capítulo 3.6) e para os desafios de sustentação do capítulo 10.4. Financiem a manutenção deliberadamente, meçam o custo de mudança como indicador antecedente e tratem uma curva crescente como um sinal para agir e não como um fato da natureza. A economia é tratada mais a fundo no capítulo 10.10.

Antipadrões e armadilhas

Tratar a manutenção como reflexão tardia. Orçar e celebrar apenas a construção e depois deixar sem recursos a fase de manutenção, muito maior e mais longa.
Dotar a manutenção de pessoal com as pessoas menos experientes. Atribuir o trabalho mais difícil (mudar com segurança sistemas que você não entende por completo) a quem está menos equipado e sinalizar que a manutenção é de baixo status.
Confundir manutenção com correção de bugs. Planejar apenas para o trabalho corretivo quando a adaptação e o aprimoramento é que de fato dominam o esforço.
Adiar indefinidamente a manutenção preventiva. Nunca refatorar, nunca atualizar dependências, até a dívida de mudança forçar uma crise cara.
Mudar código sem análise de impacto. Fazer uma “pequena correção” que reverbera em falhas imprevistas em outro lugar.
Refatorar sem rede de segurança de testes. Reestruturar código sem jeito de provar que o comportamento foi preservado: isso é só reescrever com risco.
Deixar o conhecimento sair pela porta. Deixar de documentar regras de negócio e decisões, de modo que cada aposentadoria ou saída eleva o custo de toda mudança futura.
Nunca aposentar nada. Carregar sistemas mortos e redundantes para sempre porque a desativação é pouco glamorosa e não planejada.

Modelo de maturidade

Nível 1: Iniciar. A manutenção é não planejada e sem financiamento, tratada de forma reativa por quem estiver livre. É vista como correção de bugs e como trabalho de baixo status. Não há acompanhamento por categoria, nem estimativa de custo, e o conhecimento vive em poucas cabeças. O custo de mudança sobe sem ser notado até uma correção travar ou uma crise forçar a atenção.
Nível 2: Desenvolver. Algumas equipes começaram a registrar e a triar pedidos de manutenção e a carregar uma linha de orçamento, mas a prática é inconsistente na organização e o orçamento costuma ser um resíduo. O trabalho corretivo é acompanhado enquanto o esforço adaptativo e o perfectivo não são claramente distinguidos. Alguns testes e documentação existem em bolsões, então a mudança é em parte controlada mas a compreensão continua cara e desigual de equipe para equipe.
Nível 3: Padronizar. Um processo definido de manutenção (segundo a ISO/IEC 14764) é documentado e imposto em toda a organização: o trabalho é classificado nas quatro categorias, a análise de impacto e a gestão de mudanças são rotina, e a manutenção é estimada e financiada explicitamente em todo argumento de negócio. A manutenção preventiva e a refatoração são prática padrão sob uma suíte sólida de testes, e a manutenibilidade (analisabilidade, modificabilidade, testabilidade, modularidade) é um requisito explícito de design e não um hábito local.
Nível 4: Gerenciar. A manutenção é medida e controlada com dados em relação a linhas de base. Os indicadores de custo de mudança (prazo de mudança, taxa de falha de mudanças, tendências de complexidade e de defeitos) são acompanhados por sistema, a mistura de esforço nas quatro categorias é quantificada em relação às expectativas, e as razões de esforço de manutenção e as estimativas paramétricas são conferidas contra o custo real histórico de mudança. Uma curva de custo crescente é detectada como indicador antecedente e dispara ação, e a alocação preventiva é dimensionada a partir de evidências e não chutada. As decisões de refatorar, fazer a reengenharia ou aposentar são tomadas sobre limiares medidos, não por intuição.
Nível 5: Orquestrar. A manutenção é continuamente melhorada e integrada em toda a organização e à sua economia de ciclo de vida. O TCO do ciclo de vida conduz o investimento do portfólio, a reengenharia é aplicada deliberadamente antes de os componentes se degradarem, o conhecimento é ativamente retido e a aposentadoria é planejada e rotineiramente executada. A organização reequilibra o esforço de manutenção à medida que o ambiente muda (regulamentações, plataformas, dependências), os mantenedores são engenheiros seniores respeitados e todo o parque se adapta de modo que o custo de mudança continue plano em sistemas que vivem por décadas.

Ideias para discussão

Que fração do esforço de engenharia de vocês vai de fato para a manutenção, e o orçamento e o pessoal refletem essa realidade?
Vocês conseguem decompor o seu trabalho de manutenção nas quatro categorias, e a mistura corresponde às suas suposições?
Quanto de uma mudança típica é gasto entendendo o sistema versus modificando-o, e o que tornaria mais barata a compreensão?
O seu custo de mudança está subindo, plano ou caindo ao longo do tempo, e vocês o estão medindo?
Suas equipes têm uma rede de segurança confiável de testes que torna segura a refatoração contínua, ou reestruturar é arriscado demais para tentar?
Quem mantém os seus sistemas mais longevos, como o conhecimento deles é capturado e qual é o status e a moral desse trabalho?

Principais conclusões

A manutenção é a maior parte do custo do ciclo de vida do software (comumente de 60 a 90 por cento para sistemas de longa vida) e precisa ser planejada, orçada e dotada de pessoal como uma atividade de primeira classe.
As quatro categorias (corretiva, adaptativa, perfectiva, preventiva) são trabalhos distintos, e o aprimoramento e a adaptação, não a correção de bugs, costumam dominar.
A compreensão de programas é a maior atividade isolada da manutenção. Torne legíveis o código, o histórico e o comportamento para manter barata toda mudança.
Refatore continuamente sob uma rede de segurança de testes e faça a reengenharia incremental de componentes degradados para manter plano o custo da mudança.
Estime explicitamente o custo de manutenção e alimente-o no custo total de propriedade e nas decisões econômicas.
Projete para a manutenibilidade desde o início (é o investimento de maior retorno em todo o ciclo de vida) e trate os mantenedores como os profissionais seniores que precisam ser.

Referências e leitura complementar

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Software Maintenance knowledge area
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): maintainability quality characteristics
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb and Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (maintenance and reuse models)
Meir M. Lehman, “Laws of Software Evolution” (on why software must continually change or become less useful)
Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis, Modernising Legacy Systems