Artigo Engenharia de Software 11 - Introdução à Manutenção de Software

Manutenção

Introdução à Manutenção de Software

O desenvolvimento de qualquer software, exceto programas muito simples, é uma tarefa bastante complexa. Esse fato se tornou evidente com a “crise de software”, o que originou o conceito de engenharia de software como uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, manutenção e descarte de software.

  A engenharia de software surgiu inicialmente mais como uma promessa do que uma realidade. De fato, muitos dos problemas ligados ao desenvolvimento e manutenção de software continuam sem solução, apesar de muitos conceitos terem evoluído.

  Entender o que significa manutenção de software, e principalmente a abrangência do significado do termo, constitui passo fundamental para o estudo e aprofundamento de soluções para os problemas atrelados a essa tarefa.

  Faz-se importante destacar nesse ponto que o autor deste trabalho vem trabalhando diretamente com manutenção de software no meio organizacional há alguns anos. Esta experiência acaba por influenciar a percepção dos fatores mais importantes envolvidos na prática com a manutenção de software, contribuindo para a concretização deste artigo.

Atividade de Manutenção de Software

Este tópico tem por objetivo destacar as características, tipos e desafios para a manutenção de software. Trata-se de um tópico importante para esclarecer alguns pontos pertinentes ao assunto que serão considerados ao longo deste artigo.

Definições

A atividade de manutenção de software é caracterizada pela modificação de um produto de software já entregue ao cliente, para a correção de eventuais erros, melhora em seu desempenho, ou qualquer outro atributo, ou ainda para adaptação desse produto a um ambiente modificado (IEEE, 1998).

  Embora a definição trate genericamente qualquer produto de software, existem diferenças entre a manutenção de softwares com propósitos distintos. Essa distinção é explicada por Pfleeger (2001), que estabelece três categorias de sistemas.

  Uma primeira classificação representa aqueles softwares construídos com base em uma especificação rígida e bem definida, cujos resultados esperados são bem conhecidos. Por exemplo, um software construído para realizar operações com matrizes (adição, multiplicação e inversão). Nesse tipo de software, uma vez que tenha sido construído considerando a correta implementação do método, dificilmente haverá a necessidade de manutenções.

  Já em uma segunda classificação, são agrupados os softwares que constituem implementações de soluções aproximadas para problemas do mundo real, uma vez que soluções completas somente são conseguidas na teoria nesses casos. Como exemplo, pode-se citar um jogo de xadrez. Embora suas regras sejam bem definidas, não é possível construir um software que calcule a cada passo todos os possíveis movimentos de peças do tabuleiro, de forma a determinar o melhor movimento. Isso porque o número de movimentos possíveis é muito grande para ser calculado em um intervalo de tempo relativamente curto. A técnica utilizada para desenvolver esse tipo de solução baseia-se em descrever o problema de forma abstrata e então definir os requisitos de software a partir dessa abstração.

  Percebe-se que esse tipo de sistema já abre espaço para diferentes interpretações por parte do desenvolvedor, o que tende a produzir software com maior necessidade de manutenção do que quando comparado aos da classificação anterior. Por considerar uma abstração para especificação de requisitos, a necessidade de mudança pode aparecer caso a abstração mude, na medida em que um maior entendimento do problema seja alcançado.

  Finalmente, uma terceira e última classe de softwares considera mudanças no ambiente onde o software vai ser utilizado, característica não existente nas duas classificações anteriores.

  Um software integrante da terceira classificação corresponde àquele criado com base em um modelo dos processos abstratos envolvidos no sistema, e precisará mudar sempre que ocorrer mudanças nesses modelos, sendo, portanto, parte do ambiente que ele modela. Um exemplo desse tipo de software seria aquele que apresenta informações da economia de um país. À medida que a economia passa a ser mais bem compreendida, o modelo muda e com ele a abstração do problema, causando uma necessidade inevitável de manutenção no software. Esse tipo de software, comumente encontrado no dia-a-dia das organizações, tem interesse particular neste trabalho.

  Além de considerar tipos diferentes de software, o processo de manutenção não corresponde a uma atividade isolada. Durante a sua execução, diferentes partes precisam interagir de forma que os objetivos da manutenção sejam entendidos e os resultados esperados alcançados. Essas partes são apresentadas em Polo et al. (1999), que as define como:

§Organização Cliente: essa organização corresponde ao adquirente do software, conforme definido pela norma ISO/IEC 12207. Isso significa a organização que possui o software e requisita o serviço de manutenção.

§Mantenedor: trata-se da organização que oferece o serviço de manutenção.

§Usuário: representa a organização ou pessoa que utiliza o software em questão, valendo-se de suas funcionalidades para automatizar e facilitar tarefas.

  Ainda segundo esse autor, existe um relacionamento entre essas partes e a constituição de um fluxo para os pedidos de manutenção, conforme é esquematizado na Figura 1.

Figura 1. Fluxo envolvido na manutenção de software (adaptação Polo et al. 1999)

  A organização solicitante deve possuir algum responsável pela solicitação de manutenção, que será encarregado de verificar os requisitos e informar o mantenedor. Esse responsável deverá considerar os erros e dificuldades apontadas pelo help-desk, que corresponde ao departamento diretamente encarregado do diálogo com os usuários.

  Do lado do mantenedor, a organização que presta o serviço deve possuir alguém responsável por avaliar as requisições, julgando-as apropriadas ou não para os objetivos do software e da organização solicitante. Uma vez que os pedidos de manutenção são aceitos, deve existir alguém responsável por estabelecer um cronograma de entrega, que deverá considerar as prioridades e interesses de ambas as partes. Esse cronograma deverá ser seguido pela equipe de manutenção, que compreende o pessoal envolvido diretamente em atender às solicitações.

  Finalmente, o papel do usuário consiste em utilizar o software reportando problemas para o help-desk, que por sua vez informará o responsável pelas solicitações de manutenção, fechando o ciclo." [...] continue lendo...