Visão geral de manutenção de software

A manutenção de software é amplamente aceita como parte do SDLC hoje em dia. Significa todas as modificações e atualizações feitas após a entrega do produto de software. Existem várias razões pelas quais as modificações são necessárias, algumas delas são brevemente mencionadas abaixo:

  • Market Conditions - As políticas, que mudam com o tempo, como tributação e restrições recentemente introduzidas, como manter a contabilidade, podem gerar a necessidade de modificação.

  • Client Requirements - Com o tempo, o cliente pode solicitar novos recursos ou funções no software.

  • Host Modifications - Se algum hardware e / ou plataforma (como sistema operacional) do host de destino for alterado, alterações de software serão necessárias para manter a adaptabilidade.

  • Organization Changes - Se houver alguma mudança no nível de negócios na extremidade do cliente, como redução da força da organização, aquisição de outra empresa, organização se aventurando em novos negócios, pode haver necessidade de modificação no software original.

Tipos de manutenção

Durante a vida útil do software, o tipo de manutenção pode variar de acordo com sua natureza. Pode ser apenas uma tarefa de manutenção de rotina como algum bug descoberto por algum usuário ou pode ser um grande evento em si mesmo com base no tamanho ou natureza da manutenção. A seguir estão alguns tipos de manutenção com base em suas características:

  • Corrective Maintenance - Inclui modificações e atualizações feitas para corrigir ou corrigir problemas, que são descobertos pelo usuário ou concluídos por relatórios de erros do usuário.

  • Adaptive Maintenance - Isso inclui modificações e atualizações aplicadas para manter o produto de software atualizado e ajustado para o mundo em constante mudança da tecnologia e do ambiente de negócios.

  • Perfective Maintenance- Isso inclui modificações e atualizações feitas para manter o software utilizável por um longo período de tempo. Inclui novos recursos, novos requisitos do usuário para refinar o software e melhorar sua confiabilidade e desempenho.

  • Preventive Maintenance- Isso inclui modificações e atualizações para evitar problemas futuros do software. Tem como objetivo atender problemas, que não são significativos neste momento, mas podem causar sérios problemas no futuro.

Custo de Manutenção

Os relatórios sugerem que o custo de manutenção é alto. Um estudo sobre a estimativa de manutenção de software descobriu que o custo de manutenção chega a 67% do custo de todo o ciclo do processo de software.

Em média, o custo de manutenção do software é superior a 50% de todas as fases do SDLC. Existem vários fatores que fazem com que o custo de manutenção seja alto, como:

Fatores do mundo real que afetam o custo de manutenção

  • A idade padrão de qualquer software é considerada de 10 a 15 anos.
  • Os softwares mais antigos, que deveriam funcionar em máquinas lentas com menos memória e capacidade de armazenamento, não podem ser um desafio contra os novos softwares aprimorados em hardware moderno.
  • Conforme a tecnologia avança, torna-se caro manter o software antigo.
  • A maioria dos engenheiros de manutenção são novatos e usam o método de tentativa e erro para corrigir o problema.
  • Freqüentemente, as alterações feitas podem facilmente prejudicar a estrutura original do software, dificultando quaisquer alterações subsequentes.
  • As alterações geralmente não são documentadas, o que pode causar mais conflitos no futuro.

Fatores finais do software que afetam o custo de manutenção

  • Estrutura do Programa de Software
  • Linguagem de programação
  • Dependência do ambiente externo
  • Confiabilidade e disponibilidade da equipe

Atividades de manutenção

O IEEE fornece uma estrutura para atividades de processo de manutenção sequencial. Ele pode ser usado de maneira iterativa e pode ser estendido para que itens e processos personalizados possam ser incluídos.

Essas atividades vão de mãos dadas com cada uma das seguintes fases:

  • Identification & Tracing- Envolve atividades relativas à identificação de requisitos de modificação ou manutenção. É gerado pelo usuário ou o próprio sistema pode reportar via logs ou mensagens de erro. Aqui, o tipo de manutenção também é classificado.

  • Analysis- A modificação é analisada por seu impacto no sistema, incluindo implicações de segurança e proteção. Se o impacto provável for severo, procura-se uma solução alternativa. Um conjunto de modificações necessárias é então materializado em especificações de requisitos. O custo de modificação / manutenção é analisado e a estimativa é concluída.

  • Design- Novos módulos, que precisam ser substituídos ou modificados, são projetados de acordo com as especificações de requisitos definidas no estágio anterior. Os casos de teste são criados para validação e verificação.

  • Implementation - Os novos módulos são codificados com a ajuda de design estruturado criado na etapa de design. Espera-se que cada programador faça testes de unidade em paralelo.

  • System Testing- O teste de integração é feito entre os módulos recém-criados. O teste de integração também é realizado entre os novos módulos e o sistema. Por fim, o sistema é testado como um todo, seguindo procedimentos de teste regressivos.

  • Acceptance Testing- Depois de testar o sistema internamente, ele é testado para aceitação com a ajuda dos usuários. Se estiver nesse estado, o usuário reclamará de alguns problemas que serão tratados ou anotados para tratar na próxima iteração.

  • Delivery- Após o teste de aceitação, o sistema é implantado em toda a organização por um pequeno pacote de atualização ou nova instalação do sistema. O teste final ocorre no cliente após a entrega do software.

    Instalações de treinamento são fornecidas, se necessário, além da cópia impressa do manual do usuário.

  • Maintenance management- O gerenciamento da configuração é uma parte essencial da manutenção do sistema. É auxiliado por ferramentas de controle de versão para controlar versões, semi-versão ou gerenciamento de patch.

Reengenharia de software

Quando precisamos atualizar o software para mantê-lo no mercado atual, sem afetar sua funcionalidade, isso é chamado de reengenharia de software. É um processo completo em que o design do software é alterado e os programas reescritos.

O software legado não consegue ficar em sintonia com a tecnologia mais recente disponível no mercado. À medida que o hardware se torna obsoleto, a atualização do software se torna uma dor de cabeça. Mesmo que o software envelheça com o tempo, sua funcionalidade não envelhece.

Por exemplo, inicialmente o Unix foi desenvolvido em linguagem assembly. Quando a linguagem C surgiu, o Unix foi reprojetado em C, porque trabalhar em linguagem assembly era difícil.

Fora isso, às vezes os programadores percebem que poucas partes do software precisam de mais manutenção do que outras e também precisam de reengenharia.

Processo de Reengenharia

  • Decideo que reengenharia. É um software completo ou parte dele?
  • Perform Engenharia reversa, a fim de obter especificações de softwares existentes.
  • Restructure Programse necessário. Por exemplo, transformar programas orientados a funções em programas orientados a objetos.
  • Re-structure data como requerido.
  • Apply Forward engineering conceitos para obter software reprojetado.

Existem alguns termos importantes usados ​​na reengenharia de software

Engenharia reversa

É um processo para atingir a especificação do sistema por meio de uma análise completa e da compreensão do sistema existente. Este processo pode ser visto como um modelo SDLC reverso, ou seja, tentamos obter um nível de abstração mais alto analisando os níveis de abstração mais baixos.

Um sistema existente é projeto previamente implementado, sobre o qual nada sabemos. Os designers então fazem engenharia reversa olhando para o código e tentam obter o design. Com o design em mãos, procuram concluir as especificações. Portanto, indo ao contrário do código para a especificação do sistema.

Reestruturação do Programa

É um processo para reestruturar e reconstruir o software existente. É tudo sobre como reorganizar o código-fonte, seja na mesma linguagem de programação ou de uma linguagem de programação para outra diferente. A reestruturação pode ter a reestruturação do código-fonte e a reestruturação dos dados, ou ambas.

A reestruturação não afeta a funcionalidade do software, mas aumenta a confiabilidade e a facilidade de manutenção. Os componentes do programa, que causam erros com muita frequência, podem ser alterados ou atualizados com reestruturação.

A confiabilidade do software em uma plataforma de hardware obsoleta pode ser removida por meio da reestruturação.

Engenharia Avançada

A engenharia avançada é um processo de obtenção do software desejado a partir das especificações em mãos, que foram derrubadas por meio da engenharia reversa. Ele assume que já havia alguma engenharia de software feita no passado.

A engenharia direta é igual ao processo de engenharia de software, com apenas uma diferença - ela é realizada sempre após a engenharia reversa.

Reutilização de componentes

Um componente é uma parte do código do programa de software, que executa uma tarefa independente no sistema. Pode ser um pequeno módulo ou o próprio subsistema.

Exemplo

Os procedimentos de login usados ​​na web podem ser considerados como componentes, o sistema de impressão no software pode ser visto como um componente do software.

Os componentes possuem alta coesão de funcionalidade e menor taxa de acoplamento, ou seja, funcionam de forma independente e podem realizar tarefas sem depender de outros módulos.

Na OOP, os objetos projetados são muito específicos para sua preocupação e têm menos chances de serem usados ​​em algum outro software.

Na programação modular, os módulos são codificados para realizar tarefas específicas que podem ser usadas em vários outros programas de software.

Há toda uma nova vertical, que é baseada na reutilização de componentes de software, e é conhecida como Component Based Software Engineering (CBSE).

A reutilização pode ser feita em vários níveis

  • Application level - Onde um aplicativo inteiro é usado como subsistema de um novo software.

  • Component level - Onde o subsistema de um aplicativo é usado.

  • Modules level - Onde os módulos funcionais são reutilizados.

    Os componentes de software fornecem interfaces que podem ser usadas para estabelecer comunicação entre diferentes componentes.

Processo de Reutilização

Dois tipos de método podem ser adotados: mantendo os mesmos requisitos e ajustando os componentes, ou mantendo os mesmos componentes e modificando os requisitos.

  • Requirement Specification - Os requisitos funcionais e não funcionais são especificados, aos quais um produto de software deve cumprir, com a ajuda do sistema existente, entrada do usuário ou ambos.

  • Design- Esta também é uma etapa do processo SDLC padrão, onde os requisitos são definidos em termos de linguagem de software. A arquitetura básica do sistema como um todo e seus subsistemas são criados.

  • Specify Components - Ao estudar o projeto do software, os projetistas separam todo o sistema em componentes ou subsistemas menores. Um projeto de software completo se transforma em uma coleção de um enorme conjunto de componentes trabalhando juntos.

  • Search Suitable Components - O repositório de componentes de software é indicado pelos designers para pesquisar o componente correspondente, com base na funcionalidade e nos requisitos de software pretendidos.

  • Incorporate Components - Todos os componentes combinados são embalados juntos para moldá-los como um software completo.