O ciclo de vida do software e a ISO/IEC/IEEE 12207
Quando uma funcionalidade entra em produção, é comum surgir a sensação de que o trabalho terminou. O código foi desenvolvido, os testes passaram e o deploy foi realizado.
Na prática, a entrada em produção não representa o fim do software. Ela marca a passagem para uma nova fase, na qual usuários reais, mudanças no ambiente, novos requisitos e limitações técnicas continuarão exigindo decisões.
Essa é a ideia central do ciclo de vida do software: um produto de software nasce, evolui, é operado, recebe manutenção e, em algum momento, pode ser substituído ou desativado.
Da concepção à criação
Antes de existir código, existe uma necessidade.
Na concepção, a organização procura compreender:
Depois vem a criação, que envolve requisitos, arquitetura, projeto, implementação, integração, verificação e validação.
Essas atividades nem sempre acontecem em uma sequência rígida. Em métodos iterativos e ágeis, elas podem se repetir em ciclos curtos. Uma parte do produto é planejada, construída, avaliada e ajustada enquanto novas informações aparecem.
O ciclo de vida descreve o conjunto de preocupações. Ele não obriga a equipe a utilizar o modelo em cascata.
Operação também faz parte da engenharia
Ao entrar em operação, o software começa a interagir com condições que o ambiente de desenvolvimento dificilmente reproduz por completo:
É nessa fase que monitoramento, suporte, gestão de incidentes, documentação e coleta de feedback se tornam fontes importantes de informação.
O atendimento ao usuário, por exemplo, não está isolado da qualidade. Registros de incidentes e dúvidas recorrentes ajudam a revelar problemas de usabilidade, requisitos incompletos, erros de documentação e oportunidades de melhoria.
Os tipos de manutenção
Manutenção não significa apenas corrigir bugs. Ela pode assumir finalidades diferentes.
Manutenção corretiva
Corrige um defeito que já se manifestou.
Exemplo: um botão deveria inserir um texto no campo ativo, mas não realiza a ação.
Manutenção preventiva
Atua sobre um problema latente antes que ele provoque uma falha perceptível.
Exemplo: atualizar uma dependência vulnerável ou substituir um componente que está próximo de deixar de receber suporte.
Manutenção adaptativa
Adapta o software a uma mudança externa.
Exemplo: alterar uma extensão porque o sistema ao qual ela se integra mudou a estrutura da página.
Manutenção evolutiva
Acrescenta ou aprimora funcionalidades para atender novas necessidades.
Exemplo: criar uma área para gerenciar atendimentos salvos e ainda não registrados.
Refatoração
Melhora a estrutura interna do código sem mudar intencionalmente o comportamento observável.
Exemplo: separar um arquivo JavaScript muito grande em módulos menores para facilitar testes e manutenção.
Essas categorias ajudam a entender por que produtos em uso continuam consumindo trabalho de engenharia.
Quando o software entra em decadência
Um sistema pode continuar funcionando e, ainda assim, entrar em decadência.
Isso ocorre quando mudanças sucessivas tornam a solução difícil de entender, testar e modificar. Também pode acontecer quando a tecnologia fica obsoleta, a documentação deixa de acompanhar o produto ou o sistema já não atende ao modo como a organização trabalha.
Alguns sinais são:
A decadência não é necessariamente culpa de uma única decisão. Muitas vezes é o efeito acumulado de anos de mudanças sem investimento proporcional em arquitetura, documentação e redução da dívida técnica.
O papel da ISO/IEC/IEEE 12207
A ISO/IEC/IEEE 12207 organiza processos, atividades e tarefas relacionados ao ciclo de vida do software. Seu objetivo não é ensinar uma linguagem de programação nem impor uma metodologia específica. Ela oferece um vocabulário comum para que adquirentes, fornecedores, gestores, desenvolvedores, profissionais de qualidade, operação e manutenção entendam as responsabilidades envolvidas.
A norma trata de preocupações como:
As edições da norma reorganizam processos e atualizam a forma de apresentá-los, mas a ideia fundamental permanece: qualidade depende de atividades coordenadas ao longo de todo o ciclo.
Em abril de 2026, foi publicada a ISO/IEC/IEEE 12207:2026, substituindo a edição de 2017. A edição atual reforça que os processos podem ser aplicados de forma concorrente, iterativa, recursiva e incremental, inclusive em abordagens ágeis.
A norma não é um processo pronto
Um cuidado importante: adotar a ISO 12207 não significa executar todos os processos da mesma forma em qualquer projeto.
Uma organização pequena, uma equipe de produto, um fornecedor governamental e uma empresa que desenvolve software crítico possuem riscos e necessidades diferentes. É necessário selecionar, adaptar e detalhar as práticas conforme o contexto.
A norma funciona como um mapa. O caminho concreto depende do produto, das partes interessadas, dos riscos e dos objetivos do negócio.
Conclusão
O software não termina quando é publicado. Ele entra em operação, recebe manutenção, adapta-se ao ambiente e, eventualmente, precisa ser retirado de uso.
Pensar em ciclo de vida amplia a qualidade porque obriga a equipe a olhar além da entrega imediata. Um bom produto não é apenas aquele que funciona hoje, mas aquele que pode ser operado, compreendido, protegido, modificado e, quando necessário, desativado de maneira responsável.
Este artigo organiza reflexões dos meus estudos na pós-graduação em Engenharia da Qualidade e Teste de Software. O objetivo é relacionar os conceitos estudados à prática e às referências normativas atuais.