Introdução à Manutenção de Software
De que se trata o artigo:
O artigo trata do assunto manutenção de software, englobando suas definições, evolução e desafios. É apresentado também, de maneira breve, a norma ISO/IEC 12207 e sua estrutura para o processo de software.
Para que serve:
Este texto é indicado para aqueles profissionais que atuam com manutenção de software no seu dia-a-dia e que desejam entender melhor a evolução histórica e os atuais desafios em torno desse tema.
Em que situação o tema é útil:
A manutenção de software é hoje um assunto presente em organizações que desenvolvem e mantém software. Isso se deve à necessidade de sempre ajustar e melhorar o produto de software de acordo com as mais diversas necessidades. Diante desse fato, entender o significado e abrangência do termo manutenção de software pode auxiliar organizações e profissionais interessados no tema a melhor conduzir seus esforços quando precisam manter seus produtos.
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.
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.
Uma observação faz-se necessária com relação ao termo falha e defeito de software. Conforme explica Pressman (2005), a IEEE define para o contexto de hardware a explicação de que um defeito constitui uma anomalia do produto. Já uma falha pode significar um defeito em um dispositivo ou componente, ou uma definição incorreta de passo, processo ou de dados em um programa de computador.
No contexto de manutenção de software, os termos falha e defeito são sinônimos, e ambos se referem a algum problema de qualidade, identificado após o software ter sido entregue ao usuário.
As mudanças que ocorrerão em um software para deixá-lo mais completo, livre de erros, ou adaptado ao seu ambiente, podem ser definidas como atividades de evolução de software, conforme explica Sommerville (2003).
A decisão de investir na evolução de um software, ou abandoná-lo para iniciar um projeto novo, construído com base nos requisitos atuais, não é uma tarefa trivial (Pfleeger, 2001). Essa decisão deve considerar fatores como o custo envolvido, a confiabilidade do software após a manutenção, a capacidade que possuirá de se adaptar a mudanças futuras, seu desempenho, limitações de suas atuais funções, e ainda as opções existentes no mercado que atendam o mesmo problema de maneira mais completa, rápida e barata.
...
