Ir para o conteúdo

Manutenção de software

Origem: Wikipédia, a enciclopédia livre.

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

[editar | editar código]

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.[1] 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.[1] A disciplina de manutenção de software mudou pouco desde então.[2] 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.[2]

Ciclo de vida do software

[editar | editar código]
Diagrama de um ciclo de vida de desenvolvimento de software tradicional de 1988

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.[3] 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.[4] 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.[5] Seu principal propósito é preservar a utilidade do software, geralmente face a requisitos em mudança.[6]

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,[7][8] compreendendo 80 a 90 por cento do custo do ciclo de vida.[9] 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).[8] Os modelos SMLC normalmente incluem entender o código, modificá-lo e revalidá-lo.[8]

Transição do lançamento para a manutenção até o fim da vida útil

[editar | editar código]
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.[10] 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á.[11] 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.[10]

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.[12]

Ciclo de alteração

[editar | editar código]

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.[13] 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.[14] A estimação de esforço de desenvolvimento de software é um problema difícil, inclusive para solicitações de alteração de manutenção,[15] mas a solicitação provavelmente será recusada se for muito cara ou inviável.[16] Se for decidido implementar a solicitação, ela pode ser atribuída a uma versão agendada e implementada.[16] Embora a metodologia ágil não tenha uma fase de manutenção,[17] o ciclo de alteração pode ser promulgado como uma sprint de scrum.[18]

Entender o código existente é um passo essencial antes de modificá-lo.[2] A taxa de compreensão depende tanto da base de código quanto da habilidade do programador.[19] 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.[20] 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.[21] Programadores experientes têm mais facilidade para entender o que o código faz em um nível alto.[22] A visualização de software é às vezes usada para acelerar esse processo.[23]

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.[24] 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.[25] 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).[26] 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.[27]

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.[2] 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.[28] 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.[26] O objetivo dos testes é verificar se a funcionalidade anterior foi mantida e se a nova funcionalidade foi adicionada.[29]

Categorias de manutenção de software

[editar | editar código]

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.[30]

De acordo com a especificação ISO/IEC 14764, a manutenção de software pode ser classificada em quatro tipos:[31]

  • 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.[31][32]
  • 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.[33][31] Este tipo de manutenção é realizado especialmente em sistemas que precisam ser altamente seguros ou disponíveis.[33] A rejuvenescimento de software é uma forma de manutenção preventiva para limpar o estado e prevenir problemas futuros.[33]
  • 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.[31][33]
  • 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.[33][34] 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.[34] A manutenção perfeitiva pode incluir reescrever documentação, refatorar código e ajuste de desempenho.[33]

De acordo com algumas estimativas, o aprimoramento (as duas últimas categorias) compreende cerca de 80 por cento da manutenção de software.[35]

Facilidade de manutenção

[editar | editar código]

A facilidade de manutenção (mantibilidade) é a qualidade do software que permite que ele seja facilmente modificado sem quebrar a funcionalidade existente.[31] 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.[5] Muitas organizações de desenvolvimento de software negligenciam a mantibilidade, mesmo que isso aumente os custos de longo prazo.[36] 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.[37] 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.[38] Um aspecto importante é ter uma grande quantidade de testes de software automatizados que possam detectar se a funcionalidade existente é comprometida por uma alteração.[31]

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.

Um desafio com a mantibilidade é que muitos cursos de engenharia de software não a enfatizam e distribuem tarefas únicas que têm especificações claras e imutáveis.[39] Cursos de engenharia de software não cobrem sistemas tão complexos quanto os que ocorrem no mundo real.[40] Engenheiros de desenvolvimento que sabem que não serão responsáveis pela manutenção do software não têm um incentivo para construir a mantibilidade.[2]

Força de trabalho

[editar | editar código]

A manutenção é frequentemente considerada um trabalho não gratificante para engenheiros de software, que, se designados para a manutenção, eram mais propensos a pedir demissão.[41][42] Muitas vezes paga menos do que um trabalho comparável em desenvolvimento de software.[42] A tarefa é frequentemente atribuída a trabalhadores temporários ou equipe menos qualificada,[2][43] embora os engenheiros de manutenção também sejam tipicamente mais velhos do que os desenvolvedores, em parte porque devem estar familiarizados com tecnologias desatualizadas.[43] Em 2008, cerca de 900 000 dos 1,3 milhão de engenheiros de software e programadores trabalhando nos Estados Unidos estavam fazendo manutenção.[44]

As empresas começaram a criar equipes separadas para manutenção, o que levou à terceirização desse trabalho para uma empresa diferente e, na virada do século XXI, às vezes à relocalização global do trabalho (offshoring) para outro país — seja como parte da empresa original ou uma entidade separada.[45][9] As fontes típicas de terceirização são países desenvolvidos, como Estados Unidos, Reino Unido, Japão e Austrália, enquanto os destinos são geralmente países de menor custo, como China, Índia, Rússia e Irlanda.[46] As razões para a relocalização global incluem aproveitar os menores custos trabalhistas, permitir suporte 24 horas por dia, 7 dias por semana, reduzir a pressão de tempo sobre os desenvolvedores e aproximar o suporte do mercado do produto.[47] As desvantagens da relocalização global incluem barreiras de comunicação na forma de fatores como fuso horário e desjunção organizacional e diferenças culturais.[9] Apesar de muitos empregadores considerarem a manutenção um trabalho de menor qualificação e a fase do desenvolvimento de software mais adequada para a relocalização global,[9][48] ela requer comunicação próxima com o cliente e resposta rápida, ambas dificultadas por essas dificuldades de comunicação.[9]

Alternativas à manutenção

[editar | editar código]

Na engenharia de software, o termo sistema legado não tem um significado fixo, mas muitas vezes se refere a sistemas mais antigos que são grandes, difíceis de modificar e também necessários para as necessidades atuais de negócios. Muitas vezes, os sistemas legados são escritos em linguagens de programação obsoletas, carecem de documentação, têm uma estrutura deteriorada após anos de alterações e dependem de especialistas para mantê-los operacionais.[49] Ao lidar com esses sistemas, em algum ponto, tanta dívida técnica se acumula que a manutenção não é prática ou econômica.[12] Outras opções incluem:

  • Congelamento — não fazer mais trabalho no sistema legado.[50] Esta opção pode ser escolhida se o fornecedor quiser continuar a extrair receita enquanto for possível, evitando os custos de manutenção.[12]
  • Terceirizar a funcionalidade do sistema legado para uma empresa diferente, especialmente se não for considerada uma função de negócio principal.[50]
  • Descartar o sistema legado existente e redesenhar um novo aplicativo do zero para cumprir o mesmo propósito do sistema legado.[50] No entanto, essa abordagem é ineficiente devido ao descarte de um sistema funcional, e com essa abordagem há o perigo de o novo sistema não atender aos requisitos de negócios em mudança.[50]
  • Envolver o aplicativo legado em uma camada de abstração para simplificar interfaces desatualizadas.[50] O código-fonte não é modificado, mas a nova interface permite que um componente testado e aprovado seja acessado por aplicativos mais novos. Essa abordagem não corrige nenhum dos problemas de manutenção de um sistema legado.[51] Bancos de dados, funções e aplicativos inteiros podem ser envolvidos dessa maneira.[52]
  • Migrar o sistema legado para uma nova plataforma, o que pode reduzir a despesa do novo desenvolvimento de software reutilizando a implementação, o design, a especificação e os requisitos do sistema legado.[53] A migração pode levar de 5 a 10 anos, mas resulta em maior flexibilidade e economia de longo prazo na manutenção de software.[54] Até 80 por cento da despesa está em testes; isto é, garantir que o novo sistema tenha a mesma saída que o sistema antigo.[55] Após a conclusão do novo sistema, é necessária uma transição do sistema antigo para o novo sistema com o mínimo de interrupção nas funções de negócio.[55]

Pesquisa

[editar | editar código]

Apesar de ocupar a maior parte dos recursos de desenvolvimento de software, a manutenção é a fase menos estudada do desenvolvimento de software.[56][57] Grande parte da literatura focou em como desenvolver código mantível desde o início, com menos foco em motivar os engenheiros a priorizar a mantibilidade.[58] 2020, soluções automatizadas para refatoração de código para reduzir o esforço de manutenção são uma área ativa de pesquisa,[59] assim como a avaliação de mantibilidade aprimorada por aprendizado de máquina.[60]

Referências

[editar | editar código]
  1. ↑ a b Tripathy & Naik 2014, p. 25.
  2. ↑ a b c d e f Offutt, Jeff (janeiro de 2018). «Overview of Software Maintenance and Evolution». Departamento de Ciência da Computação da Universidade George Mason. Consultado em 5 de maio de 2024 
  3. ↑ Tripathy & Naik 2014, p. 4.
  4. ↑ Tripathy & Naik 2014, pp. 5-6.
  5. ↑ a b Tripathy & Naik 2014, p. 26.
  6. ↑ Madhusudhan et al. 2017, p. 761.
  7. ↑ Varga 2018, p. 3.
  8. ↑ a b c Tripathy & Naik 2014, p. 7.
  9. ↑ a b c d e Ulziit et al. 2015, p. 764.
  10. ↑ a b Reifer 2012, p. 22.
  11. ↑ Reifer 2012, p. 21.
  12. ↑ a b c Tripathy & Naik 2014, p. 89.
  13. ↑ Madhusudhan et al. 2017, p. 763.
  14. ↑ Tripathy & Naik 2014, p. 120.
  15. ↑ Madhusudhan et al. 2017, p. 762.
  16. ↑ a b Tripathy & Naik 2014, p. 123.
  17. ↑ Ali et al. 2024, p. 126.
  18. ↑ Ali et al. 2024, p. 130.
  19. ↑ Tripathy & Naik 2014, p. 296.
  20. ↑ Tripathy & Naik 2014, pp. 296-297.
  21. ↑ Tripathy & Naik 2014, p. 309.
  22. ↑ Tripathy & Naik 2014, p. 297.
  23. ↑ Tripathy & Naik 2014, pp. 318-319.
  24. ↑ Tripathy & Naik 2014, pp. 85-86.
  25. ↑ Tripathy & Naik 2014, p. 86.
  26. ↑ a b Tripathy & Naik 2014, p. 94.
  27. ↑ Tripathy & Naik 2014, p. 59.
  28. ↑ Reifer 2012, p. 5.
  29. ↑ Tripathy & Naik 2014, p. 98.
  30. ↑ Varga 2018, p. 4.
  31. ↑ a b c d e f Varga 2018, p. 5.
  32. ↑ Tripathy & Naik 2014, pp. 26-27.
  33. ↑ a b c d e f Tripathy & Naik 2014, p. 27.
  34. ↑ a b Varga 2018, pp. 5-6.
  35. ↑ Varga 2018, p. 5 fn 4.
  36. ↑ Varga 2018, p. 12.
  37. ↑ Varga 2018, pp. 6-7.
  38. ↑ Varga 2018, p. 7.
  39. ↑ Varga 2018, pp. 7-8.
  40. ↑ Varga 2018, p. 9.
  41. ↑ Madhusudhan et al. 2017, p. 764.
  42. ↑ a b Reifer 2012, p. 7.
  43. ↑ a b Reifer 2012, p. 8.
  44. ↑ Reifer 2012, p. 1.
  45. ↑ Rahman et al. 2024, p. 1.
  46. ↑ Rahman et al. 2021, Research Background.
  47. ↑ Ulziit et al. 2015, p. 763.
  48. ↑ Reifer 2012, p. 2.
  49. ↑ Tripathy & Naik 2014, pp. 187-188.
  50. ↑ a b c d e Tripathy & Naik 2014, p. 188.
  51. ↑ Tripathy & Naik 2014, p. 189.
  52. ↑ Tripathy & Naik 2014, p. 191.
  53. ↑ Tripathy & Naik 2014, pp. 188-189.
  54. ↑ Tripathy & Naik 2014, p. 195.
  55. ↑ a b Tripathy & Naik 2014, p. 196.
  56. ↑ Madhusudhan et al. 2017, p. 759.
  57. ↑ Ulziit et al. 2015, p. 766.
  58. ↑ Reifer 2012, pp. 4-5.
  59. ↑ Baqais & Alshayeb 2020, p. 459.
  60. ↑ Alsolai & Roper 2020, p. 106214.

Fontes

[editar | editar código]
  • Ali, Muhammad; Cheema, Sehrish Munawar; Naz, Ammerha; Pires, Ivan Miguel (2024). «SAMSEF: An Agile Software Maintenance Leveraging Scrum Framework for Improved Efficiency and Effectiveness». Good Practices and New Perspectives in Information Systems and Technologies. Col: Lecture Notes in Networks and Systems (em inglês). 989. [S.l.]: Springer Nature Switzerland. pp. 126–136. ISBN 978-3-031-60226-9. doi:10.1007/978-3-031-60227-6_11 
  • Alsolai, Hadeel; Roper, Marc (2020). «A systematic literature review of machine learning techniques for software maintainability prediction» (PDF). Information and Software Technology. 119. doi:10.1016/j.infsof.2019.106214 
  • Baqais, Abdulrahman Ahmed Bobakr; Alshayeb, Mohammad (2020). «Automatic software refactoring: a systematic literature review». Software Quality Journal. 28 (2): 459–502. doi:10.1007/s11219-019-09477-y 
  • Madhusudhan, V.; Suma, V.; Rao, Jawahar J. (2017). Software Maintenance: From the Perspective of Effort and Cost Requirement. Proceedings of the International Conference on Data Engineering and Communication Technology (em inglês). Springer. pp. 759–768. ISBN 978-981-10-1678-3 
  • Rahman, Hanif Ur; da Silva, Alberto Rodrigues; Alzayed, Asaad; Raza, Mushtaq (2024). «A Systematic Literature Review on Software Maintenance Offshoring Decisions». Information and Software Technology. 172. doi:10.1016/j.infsof.2024.107475 
  • Rahman, Hanif Ur; Raza, Mushtaq; Afsar, Palwasha; Khan, Habib Ullah (2021). «Empirical Investigation of Influencing Factors Regarding Offshore Outsourcing Decision of Application Maintenance». IEEE Access. 9: 58589–58608. Bibcode:2021IEEEA...958589R. ISSN 2169-3536. doi:10.1109/ACCESS.2021.3073315. hdl:10576/37687Acessível livremente 
  • Reifer, Donald J. (2012). Software Maintenance Success Recipes (em inglês). [S.l.]: CRC Press. ISBN 978-1-4398-5167-8 
  • Tripathy, Priyadarshi; Naik, Kshirasagar (2014). Software Evolution and Maintenance: A Practitioner's Approach (em inglês). [S.l.]: John Wiley & Sons. ISBN 978-0-470-60341-3 
  • Ulziit, Bayarbuyan; Warraich, Zeeshan Akhtar; Gencel, Cigdem; Petersen, Kai (2015). «A conceptual framework of challenges and solutions for managing global software maintenance». Journal of Software: Evolution and Process. 27 (10): 763–792. doi:10.1002/smr.1720 
  • Varga, Ervin (2018). Unraveling Software Maintenance and Evolution: Thinking Outside the Box (em inglês). [S.l.]: Springer. ISBN 978-3-319-71303-8 

Ligações externas

[editar | editar código]
Obtida de "https://pt.wikipedia.org/w/index.php?title=Manutenção_de_software&oldid=71249200"