Manutenção de software - Software maintenance
Desenvolvimento de software |
---|
A manutenção de software na engenharia de software é a modificação de um produto de software após a entrega para corrigir falhas, melhorar o desempenho ou outros atributos.
Uma percepção comum de manutenção é que envolve apenas a correção de defeitos . No entanto, um estudo indicou que mais de 80% do esforço de manutenção é usado para ações não corretivas. Essa percepção é perpetuada pelos usuários que enviam relatórios de problemas que, na realidade, são aprimoramentos de funcionalidade do sistema. Estudos mais recentes colocam a proporção de correção de bugs perto de 21%.
História
A manutenção de software e a evolução de sistemas foram abordadas pela primeira vez por Meir M. Lehman em 1969. Durante um período de vinte anos, sua pesquisa levou à formulação das Leis de Lehman (Lehman 1997). As principais descobertas de sua pesquisa concluem que a manutenção é realmente um desenvolvimento evolutivo e que as decisões de manutenção são auxiliadas pela compreensão do que acontece aos sistemas (e software) ao longo do tempo. Lehman demonstrou que os sistemas continuam a evoluir com o tempo. Conforme eles evoluem, eles se tornam mais complexos, a menos que alguma ação, como refatoração de código, seja realizada para reduzir a complexidade. No final dos anos 1970, um estudo de pesquisa famoso e amplamente citado por Lientz e Swanson, expôs a fração muito alta dos custos do ciclo de vida que estavam sendo gastos na manutenção.
A pesquisa mostrou que cerca de 75% do esforço de manutenção foi nos dois primeiros tipos, e a correção de erros consumiu cerca de 21%. Muitos estudos subsequentes sugerem uma magnitude de problema semelhante. Estudos mostram que a contribuição dos usuários finais é crucial durante a nova coleta e análise de dados de requisitos. Esta é a principal causa de qualquer problema durante a evolução e manutenção do software. A manutenção de software é importante porque consome uma grande parte dos custos gerais do ciclo de vida e também a incapacidade de alterar o software de forma rápida e confiável significa que oportunidades de negócios são perdidas.
Importância da manutenção de software
Os principais problemas de manutenção de software são gerenciais e técnicos. Os principais problemas de gerenciamento são: alinhamento com as prioridades do cliente, pessoal, que organização faz a manutenção, estimativa de custos. Os principais problemas técnicos são: compreensão limitada, análise de impacto , testes, medição de capacidade de manutenção.
A manutenção de software é uma atividade muito ampla que inclui correção de erros, aprimoramentos de recursos, exclusão de recursos obsoletos e otimização. Como a mudança é inevitável, mecanismos devem ser desenvolvidos para avaliar, controlar e fazer modificações.
Portanto, qualquer trabalho feito para alterar o software após ele estar em operação é considerado trabalho de manutenção. O objetivo é preservar o valor do software ao longo do tempo. O valor pode ser aumentado com a expansão da base de clientes, atendendo a requisitos adicionais, tornando-se mais fácil de usar, mais eficiente e empregando tecnologia mais recente. A manutenção pode durar 20 anos, enquanto o desenvolvimento pode durar 1–2 anos.
Planejamento de manutenção de software
Uma parte integrante do software é a manutenção, que requer um plano de manutenção preciso a ser construído durante o desenvolvimento do software. Deve especificar como os usuários solicitarão modificações ou relatarão problemas. O orçamento deve incluir estimativas de recursos e custos, e uma nova decisão deve ser tomada para o desenvolvimento de cada novo recurso do sistema e seus objetivos de qualidade. A manutenção de software, que pode durar mais de 5 anos (ou mesmo décadas) após o processo de desenvolvimento, exige um plano eficaz que pode abordar o escopo da manutenção de software, a adaptação do processo de pós-entrega / implantação, a designação de quem irá fornecer manutenção e uma estimativa dos custos do ciclo de vida.
Processos de manutenção de software
Esta seção descreve os seis processos de manutenção de software como:
- O processo de implementação contém atividades de preparação e transição de software, como a concepção e criação do plano de manutenção; a preparação para lidar com os problemas identificados durante o desenvolvimento; e o acompanhamento da gestão da configuração do produto.
- O processo de análise de problemas e modificações, que se executa assim que a aplicação passa a ser da responsabilidade do grupo de manutenção. O programador de manutenção deve analisar cada solicitação, confirmá-la (reproduzindo a situação) e verificar sua validade, investigá-la e propor uma solução, documentar a solicitação e a proposta de solução e, por fim, obter todas as autorizações necessárias para aplicar as modificações.
- O processo considerando a implementação da própria modificação.
- O processo de aceitação da modificação, por meio da confirmação do trabalho modificado com a pessoa que enviou a solicitação, a fim de garantir que a modificação forneceu uma solução.
- O processo de migração ( migração de plataforma , por exemplo) é excepcional e não faz parte das tarefas diárias de manutenção. Se o software precisar ser transferido para outra plataforma sem qualquer alteração na funcionalidade, esse processo será usado e uma equipe de projeto de manutenção provavelmente será designada para essa tarefa.
- Por fim, o último processo de manutenção, também um evento que não ocorre no dia a dia, é a retirada de um software.
Existem vários processos, atividades e práticas que são exclusivas para os mantenedores, por exemplo:
- Transição: uma sequência controlada e coordenada de atividades durante a qual um sistema é transferido progressivamente do desenvolvedor para o mantenedor
- Acordos de nível de serviço (SLAs) e contratos de manutenção especializados (específicos de domínio) negociados pelos mantenedores
- Help Desk de solicitação de modificação e relatório de problema: um processo de tratamento de problemas usado pelos mantenedores para priorizar, documentar e encaminhar as solicitações que recebem
Categorias de manutenção de software
EB Swanson identificou inicialmente três categorias de manutenção: corretiva, adaptativa e perfectiva. O padrão IEEE 1219 foi substituído em junho de 2010 pelo P14764 . Desde então, eles foram atualizados e a ISO / IEC 14764 apresenta:
- Manutenção corretiva : modificação reativa de um produto de software realizada após a entrega para corrigir problemas descobertos. A manutenção corretiva pode ser automatizada com correção automática de bugs .
- Manutenção adaptativa: modificação de um produto de software realizada após a entrega para manter um produto de software utilizável em um ambiente alterado ou em mudança.
- Manutenção perfeita: modificação de um produto de software após a entrega para melhorar o desempenho ou a facilidade de manutenção .
- Manutenção preventiva : modificação de um produto de software após a entrega para detectar e corrigir falhas latentes no produto de software antes que se tornem falhas efetivas.
Também existe uma noção de manutenção pré-entrega / pré-lançamento, que são todas as coisas boas que você faz para reduzir o custo total de propriedade do software. Coisas como conformidade com padrões de codificação que incluem metas de manutenção de software. A gestão de acoplamento e coesão do software. O cumprimento das metas de suportabilidade do software (SAE JA1004, JA1005 e JA1006 por exemplo). Algumas instituições acadêmicas estão realizando pesquisas para quantificar o custo da manutenção contínua de software devido à falta de recursos, como documentos de design e treinamento e recursos de compreensão de sistema / software (multiplique os custos por aproximadamente 1,5-2,0 onde não há dados de design disponíveis) .
Fatores de manutenção
Impacto dos principais fatores de ajuste na manutenção (classificados em ordem de impacto positivo máximo)
Fatores de Manutenção | Alcance Plus |
---|---|
Especialistas em manutenção | 35% |
Alta experiência da equipe | 34% |
Variáveis e dados baseados em tabela | 33% |
Baixa complexidade do código base | 32% |
Y2K e motores de busca especiais | 30% |
Ferramentas de reestruturação de código | 29% |
Ferramentas de reengenharia | 27% |
Linguagens de programação de alto nível | 25% |
Ferramentas de engenharia reversa | 23% |
Ferramentas de análise de complexidade | 20% |
Ferramentas de rastreamento de defeitos | 20% |
Especialistas em “atualização em massa” do ano 2000 | 20% |
Ferramentas automatizadas de controle de mudança | 18% |
Horas extras não pagas | 18% |
Medidas de qualidade | 16% |
Inspeções formais de código de base | 15% |
Bibliotecas de teste de regressão | 15% |
Excelente tempo de resposta | 12% |
Treinamento anual de> 10 dias | 12% |
Experiência de alta gestão | 12% |
Automação de AJUDA | 12% |
Sem módulos sujeitos a erros | 10% |
Relatórios de defeitos online | 10% |
Medidas de produtividade | 8% |
Excelente facilidade de uso | 7% |
Medidas de satisfação do usuário | 5% |
Alto moral da equipe | 5% |
Soma | 503% |
Os módulos sujeitos a erros não são apenas problemáticos, mas muitos outros fatores também podem degradar o desempenho. Por exemplo, um código espaguete muito complexo é muito difícil de manter com segurança. Uma situação muito comum que freqüentemente degrada o desempenho é a falta de ferramentas de manutenção adequadas, como software de rastreamento de defeitos, software de gerenciamento de mudanças e software de biblioteca de teste. A seguir, descreva alguns dos fatores e a faixa de impacto na manutenção do software.
Impacto dos principais fatores de ajuste na manutenção (classificados em ordem de impacto negativo máximo)
Fatores de Manutenção | Alcance Minus |
---|---|
Módulos sujeitos a erros | -50% |
Variáveis e dados incorporados | -45% |
Inexperiência da equipe | -40% |
Alta complexidade de código | -30% |
Sem Y2K de mecanismos de pesquisa especiais | -28% |
Métodos de controle de mudança manual | -27% |
Linguagens de programação de baixo nível | -25% |
Sem ferramentas de rastreamento de defeitos | -24% |
Nenhum especialista de “atualização em massa” do ano 2000 | -22% |
Fraca facilidade de uso | -18% |
Sem medidas de qualidade | -18% |
Sem especialistas em manutenção | -18% |
Tempo de resposta ruim | -16% |
Sem inspeções de código | -15% |
Sem bibliotecas de teste de regressão | -15% |
Sem automação de help desk | -15% |
Sem relatórios de defeitos online | -12% |
Inexperiência de gestão | -15% |
Sem ferramentas de reestruturação de código | -10% |
Sem treinamento anual | -10% |
Sem ferramentas de reengenharia | -10% |
Sem ferramentas de engenharia reversa | -10% |
Sem ferramentas de análise de complexidade | -10% |
Sem medidas de produtividade | -7% |
Moral da equipe pobre | -6% |
Sem medidas de satisfação do usuário | -4% |
Sem horas extras não pagas | 0% |
Soma | -500% |
Dívida de manutenção
Em um artigo para a 27ª Conferência Internacional sobre Gerenciamento de Qualidade de Software em 2019, John Estdale introduziu o termo “dívida de manutenção” para necessidades de manutenção geradas pela dependência de uma implementação de fatores externos de TI, como bibliotecas, plataformas e ferramentas, que se tornaram obsoletas. O aplicativo continua em execução e o departamento de TI esquece essa responsabilidade teórica, concentrando-se em requisitos mais urgentes e problemas em outros lugares. Essa dívida se acumula com o tempo, corroendo silenciosamente o valor do ativo de software. Eventualmente, acontece algo que torna a mudança do sistema inevitável.
O proprietário pode então descobrir que o sistema não pode mais ser modificado - ele é literalmente insustentável. De forma menos dramática, pode demorar muito ou custar muito para que a manutenção resolva o problema de negócios e uma solução alternativa deve ser encontrada. O software caiu repentinamente para o valor de £ 0.
Estdale define "Dívida de Manutenção" como: a lacuna entre o estado de implementação atual de um aplicativo e o ideal, usando apenas a funcionalidade de componentes externos que é totalmente mantida e suportada. Essa dívida costuma estar oculta ou não é reconhecida. A manutenção geral de um aplicativo depende da obtenção contínua de componentes de todos os tipos de outros fornecedores, incluindo:
- Ferramentas de desenvolvimento: edição de código-fonte, gerenciamento de configuração, compilação e construção
- Ferramentas de teste: seleção de teste, execução / verificação / relatório
- Plataformas para executar o acima: hardware, sistema operacional e outros serviços
- Ambiente de produção e quaisquer instalações de espera / recuperação de desastres, incluindo o ambiente de suporte em tempo de execução da linguagem de código-fonte e o ecossistema mais amplo de agendamento de tarefas, transferência de arquivos, armazenamento replicado, backup e arquivamento, logon único, etc. etc.
- Pacotes adquiridos separadamente, por exemplo, DBMS, gráficos, comunicações, middleware
- Comprado em código-fonte, bibliotecas de código de objeto e outros serviços invocáveis
- Quaisquer requisitos decorrentes de outros aplicativos que compartilham o ambiente de produção ou que interagem com o aplicativo em questão
e claro
- A disponibilidade de habilidades relevantes, internamente ou no mercado.
O desaparecimento completo de um componente pode tornar o aplicativo impossível de reconstruir ou iminentemente impossível de manter.
Veja também
- Aposentadoria do aplicativo
- Jornal de manutenção e evolução de software: pesquisa e prática
- Suporte de longo termo
- Engenharia de Software Baseada em Busca
- Arqueologia de software
- Mantenedor de software
- Desenvolvimento de software
Referências
Leitura adicional
- ISO / IEC 14764 IEEE Std 14764-2006 Engenharia de software - Processos do ciclo de vida do software - Manutenção . 2006. doi : 10.1109 / IEEESTD.2006.235774 . ISBN 0-7381-4960-8.
- Pigoski, Thomas M. (1996). Manutenção prática de software . Nova York: John Wiley & Sons. ISBN 978-0-471-17001-3.
- Pigoski, Thomas M. Descrição para evolução e manutenção de software (versão 0.5) . Área de Conhecimento do SWEBOK.
- April, Alain; Abran, Alain (2008). Gerenciamento de manutenção de software . Nova York: Wiley-IEEE. ISBN 978-0-470-14707-8.
- Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Manutenção de software: práticas eficazes para ambientes distribuídos geograficamente . Nova Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
- Grubb, Penny; Takang, Armstrong (2003). Manutenção de software . New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
- Lehman, MM; Belady, LA (1985). Evolução do programa: processos de mudança de software . Londres: Academic Press Inc. ISBN 0-12-442441-4.
- Page-Jones, Meilir (1980). O guia prático para projeto de sistemas estruturados . Nova York: Yourdon Press. ISBN 0-917072-17-0.