A manutenção de software é a modificação de um software após a sua entrega. A manutenção de software é frequentemente considerada menos qualificada e menos gratificante do que o desenvolvimento novo. Como tal, é um alvo comum para terceirização ou offshoring. Normalmente, a equipe que desenvolve o software é diferente daquela que irá mantê-lo. Os desenvolvedores não têm um incentivo para escrever o código de forma que seja facilmente mantido. O software é frequentemente entregue incompleto e quase sempre contém alguns bugs que a equipe de manutenção deve corrigir. A manutenção de software muitas vezes inclui inicialmente o desenvolvimento de novas funcionalidades, mas à medida que o produto se aproxima do fim de sua vida útil, a manutenção é reduzida ao mínimo essencial e depois interrompida completamente antes que o produto seja descontinuado.
Cada ciclo de manutenção começa com uma solicitação de alteração, tipicamente originada de um usuário final. Essa solicitação é avaliada e, se for decidido implementá-la, o programador estuda o código existente para entender como ele funciona antes de implementar a alteração. Os testes para garantir que a funcionalidade existente seja mantida e que a nova funcionalidade desejada seja adicionada frequentemente compreendem a maior parte do custo de manutenção.
A manutenção de software não é tão bem estudada quanto outras fases do ciclo de vida do software, apesar de representar a maior parte do custo. O entendimento não mudou significativamente desde a década de 1980. A manutenção de software pode ser categorizada em vários tipos, dependendo de ser preventiva ou reativa e de buscar adicionar funcionalidade ou preservar a funcionalidade existente, esta última tipicamente em face de um ambiente alterado.
Histórico No início da década de 1970, as empresas começaram a separar a manutenção de software com sua própria equipe de engenheiros para liberar as equipes de desenvolvimento de software de tarefas de suporte. Em 1972, R. G. Canning publicou "The Maintenance 'Iceberg, no qual sustentou que a manutenção de software era uma extensão do desenvolvimento de software com uma entrada adicional: o sistema existente. A disciplina de manutenção de software mudou pouco desde então. Uma inovação do século XXI foi a liberação deliberada de software incompleto por empresas, planejando terminá-lo pós-lançamento. Este tipo de alteração, e outras que expandem a funcionalidade, são frequentemente chamadas de evolução de software em vez de manutenção.
Ciclo de vida do software miniatura|centro|Diagrama de um ciclo de vida de desenvolvimento de software tradicional de 1988|644x644px Apesar dos testes e da garantia de qualidade, virtualmente todo software contém bugs onde o sistema não funciona conforme o planejado. A manutenção pós-lançamento é necessária para remediar esses bugs quando são encontrados. A maior parte do software é uma combinação de componentes pré-existentes de software comercial de prateleira (COTS) e software livre e de código aberto com código personalizado. O software COTS e de código aberto é tipicamente atualizado ao longo do tempo, o que pode reduzir o ônus da manutenção, mas as modificações nesses componentes de software precisarão ser ajustadas no produto final. Diferente do desenvolvimento de software, que é focado em atender requisitos especificados, a manutenção de software é impulsionada por eventos — como solicitações de usuários ou detecção de um bug. Seu principal propósito é preservar a utilidade do software, geralmente face a requisitos em mudança.
Se concebida como parte do ciclo de vida de desenvolvimento de software, a manutenção é a última e tipicamente a fase mais longa do ciclo, compreendendo 80 a 90 por cento do custo do ciclo de vida. Outros modelos consideram a manutenção separada do desenvolvimento de software, em vez disso, como parte do ciclo de vida de manutenção de software (SMLC). Os modelos SMLC normalmente incluem entender o código, modificá-lo e revalidá-lo.
Transição do lançamento para a manutenção até o fim da vida útil miniatura|upright=1.5|Diagrama mostrando os passos para a aposentadoria de software Frequentemente, o software é entregue em um estado incompleto. Os desenvolvedores testam um produto até ficarem sem tempo ou financiamento, porque enfrentam menos consequências por um produto imperfeito do que por ultrapassar o tempo ou o orçamento. A transição da equipe de desenvolvimento para a equipe de manutenção é frequentemente ineficiente, sem listas de problemas conhecidos ou testes de validação, que a equipe de manutenção provavelmente recriará. Após o lançamento, é provável que os membros da equipe de desenvolvimento sejam redistribuídos ou de outra forma fiquem indisponíveis. A equipe de manutenção exigirá recursos adicionais no primeiro ano após o lançamento, tanto para o suporte técnico quanto para a correção de defeitos deixados pela desenvolvimento.
Inicialmente, o software pode passar por um período de aprimoramentos após o lançamento. Novas funcionalidades são adicionadas de acordo com o feedback do usuário. Em algum momento, a empresa pode decidir que não é mais rentável fazer melhorias funcionais e restringir o suporte à correção de bugs e atualizações de emergência. As alterações tornam-se cada vez mais difíceis e caras devido à falta de expertise ou à arquitetura decadente devido ao envelhecimento de software. Depois que um produto não é mais mantido e não recebe nem mesmo esse nível limitado de atualização, alguns fornecedores buscarão extrair receita do software enquanto for possível, mesmo que o produto provavelmente seja cada vez mais evitado. Eventualmente, o software será retirado do mercado, embora possa permanecer em uso. Durante esse processo, o software se torna um sistema legado.
Ciclo de alteração O primeiro passo no ciclo de alteração é receber uma solicitação de alteração de um cliente e analisá-la para confirmar o problema e decidir se implementa a alteração. Isso pode exigir contribuições de vários departamentos; por exemplo, a equipe de marketing pode ajudar a avaliar se a alteração é esperada para trazer mais negócios. A estimação de esforço de desenvolvimento de software é um problema difícil, inclusive para solicitações de alteração de manutenção, mas a solicitação provavelmente será recusada se for muito cara ou inviável. Se for decidido implementar a solicitação, ela pode ser atribuída a uma versão agendada e implementada. Embora a metodologia ágil não tenha uma fase de manutenção, o ciclo de alteração pode ser promulgado como uma sprint de scrum.
Entender o código existente é um passo essencial antes de modificá-lo. A taxa de compreensão depende tanto da base de código quanto da habilidade do programador. Seguir convenções de codificação, como usar nomes claros de funções e variáveis que correspondam ao seu propósito, facilita o entendimento. O uso de instruções de loop condicional somente se o código puder ser executado mais de uma vez e a eliminação de código que nunca será executado também podem aumentar a compreensibilidade. Programadores experientes têm mais facilidade para entender o que o código faz em um nível alto. A visualização de software é às vezes usada para acelerar esse processo.
A modificação do código pode ocorrer de qualquer maneira. Por um lado, é comum aplicar uma correção rápida e desorganizada sem que seja concedido tempo suficiente para atualizar a documentação do código. Por outro lado, o aprimoramento iterativo estruturado pode começar alterando o documento de requisitos de alto nível e propagando a alteração para níveis mais baixos do sistema. A modificação frequentemente inclui refatoração de código (melhorar a estrutura sem alterar a funcionalidade) e reestruturação (melhorar a estrutura e a funcionalidade ao mesmo tempo). Diferente do software comercial, os ciclos de alteração do software livre e de código aberto são largamente restritos à codificação e teste, com documentação mínima. Os projetos de software de código aberto, em vez disso, dependem de listas de discussão e um grande número de contribuidores para entender a base de código e corrigir bugs com eficiência.
Um problema adicional com a manutenção é que quase toda alteração no código introduzirá novos bugs ou efeitos cascata inesperados, que exigem outra rodada de correções. Os testes podem consumir a maior parte dos recursos de manutenção para código de segurança crítica, devido à necessidade de revalidar todo o software se alguma alteração for feita. A revalidação pode incluir revisão de código, teste de regressão com um subconjunto de testes de unidade, testes de integração e testes de sistema. O objetivo dos testes é verificar se a funcionalidade anterior foi mantida e se a nova funcionalidade foi adicionada.
Categorias de manutenção de software O propósito principal da manutenção de software é garantir que o produto continue a atender aos requisitos de usabilidade. Às vezes, isso pode significar estender as capacidades do produto além do inicialmente imaginado.
De acordo com a especificação ISO/IEC 14764, a manutenção de software pode ser classificada em quatro tipos: Manutenção corretiva: modificação do software para corrigir um bug ou outra falha em atender aos requisitos, tipicamente relatada por um usuário final. Manutenção preventiva: modificação proativa do software após a entrega para garantir que continue a atender aos requisitos ou corrigir problemas que ainda não se manifestaram. Este tipo de manutenção é realizado especialmente em sistemas que precisam ser altamente seguros ou disponíveis. A rejuvenescimento de software é uma forma de manutenção preventiva para limpar o estado e prevenir problemas futuros. Manutenção adaptativa: modificação do software realizada após a entrega para garantir sua usabilidade contínua em um ambiente alterado ou em mudança. Manutenção perfeitiva: aprimoramento do software após a entrega para melhorar qualidades como experiência do usuário, eficiência de processamento e mantibilidade. A manutenção perfeitiva é necessária se outros tipos de manutenção forem realizados, porque a modificação de uma base de código existente, caso contrário, aumentará a complexidade e causará a deterioração da estrutura existente. A manutenção perfeitiva pode incluir reescrever documentação, refatorar código e ajuste de desempenho. De acordo com algumas estimativas, o aprimoramento (as duas últimas categorias) compreende cerca de 80 por cento da manutenção de software.
Facilidade de manutenção A facilidade de manutenção (mantibilidade) é a qualidade do software que permite que ele seja facilmente modificado sem quebrar a funcionalidade existente. De acordo com a especificação ISO/IEC 14764, a atividade para garantir a mantibilidade do software antes do lançamento conta como parte da manutenção de software. Muitas organizações de desenvolvimento de software negligenciam a mantibilidade, mesmo que isso aumente os custos de longo prazo. A dívida técnica é incorrida quando os programadores, muitas vezes por preguiça ou urgência em cumprir um prazo, escolhem soluções rápidas e sujas em vez de construir a mantibilidade em seu código. Uma causa comum são as subestimativas na estimação de esforço de desenvolvimento de software, levando a recursos insuficientes alocados para o desenvolvimento. Um aspecto importante é ter uma grande quantidade de testes de software automatizados que possam detectar se a funcionalidade existente é comprometida por uma alteração.
Um índice de mantibilidade pode ser calculado com certas fórmulas a partir de medidas de linhas de código, medidas de McCabe e medidas de complexidade de Halstead.
A medição e o acompanhamento da mantibilidade visam ajudar a reduzir ou reverter a tendência de um sistema em direção à "entropia do código" ou integridade degradada e indicar quando se torna mais barato e/ou menos arriscado reescrever o código do que alterá-lo.