Manutenibilidade de Software
Autor: Marco Aurélio Cordeiro - GPS
Manutenção de software é definida como o processo de modificação de um produto de software, componente ou sistema após a sua instalação, de forma a corrigi-lo, melhorá-lo ou adaptá-lo para uma mudança no ambiente operacional. Manutenibilidade de software é o atributo que caracteriza a facilidade de modificação ou adaptação de um software[1]. É muitas vezes quantificada em termos do tempo médio requerido para efetivar a revisão do software para eliminar um erro. Esse atributo é muito significativo para um software, na medida que a etapa de manutenção pode consumir até 65% do custo total de um produto[2].
Freqüentemente, a primeira vez em que aparecem questões de falhas de software é durante a fase de teste. Detecção de falhas, depuração, correção e teste de regressão são as atividades executadas durante a fase de teste e integração. Nesta fase, muitos dos problemas do software vêm a tona e são corrigidos, porém, fatalmente, outros somente aparecerão após a sua implantação, quando em operação pelos usuários.
Após a implantação do sistema em produção, a fase do ciclo de vida que inicia é a de manutenção. Nesta fase, a correção de um erro ou o melhoramento funcional obriga que a modificação seja analisada, implementada, testada, documentada e integrada. Por este motivo, cada manutenção acaba sendo sempre um processo trabalhoso e delicado, buscando que o novo código não introduza novos erros e que a documentação seja atualizada para refletir as modificações.
Alguns problemas que podem dificultar a atividade de manutenção, principalmente para aqueles software que atravessam muitos anos em atividade, são:
A indústria de software não tem costume de desativar sistemas pelo fato de apresentarem algumas destas características e, por este motivo, devemos procurar alcançar as seguintes metas durante o desenvolvimento:
O Processo de Manutenção
A meta primordial deste processo é facilitar a acomodação de mudanças, que são inevitáveis em produtos de software, reduzindo a
quantidade de esforço na fase de manutenção. Este processo deve ser amplo o bastante para suportar manutenção para a correção de um erro, dito corretiva, para a modificação de uma funcionalidade existente, adaptativa ou a inclusão de funcionalidade, perfectiva. Pedidos de mudança podem originar, por necessidade do usuário, alterações legais ou por diversos outros motivos. O que importa é que haja um processo formal e documentado para que a mudança seja efetivada ou rejeitada, registrando as informações independente do veredicto da mudança. Deve-se registrar mesmo a informação de rejeição, pelo fato dela ser solicitada novamente por outra fonte. Muitas vezes, diversas ações de mudança são empacotadas juntas em um único bloco, para facilitar a implementação e o controle.
O procedimento para conduzir a ação da manutenção deve incluir os seguintes passos:
Conclusão
Curioso que a fase do ciclo de vida do software que, geralmente, consome a maior parte dos recursos, financeiros e humanos, das organizações de desenvolvimento de software em nível mundial, é a que menos atenção recebe quando estamos planejando o desenvolvimento de um software. Há muito pouco tempo, começamos a ouvir falar em manutenibilidade, palavra técnica que provavelmente nem conste no nosso dicionário, mas que vem ganhando destaque em nosso meio, justamente pelo motivo que move as organizações: Custo. Pensar em manutenibilidade durante o desenvolvimento de um software, é pensar em atributos que irão facilitar a implementação de modificações e, provavelmente, permitirão minimizar um panorama constante da nossa profissão. Pessoas que desenvolvem um único projeto e ficam permanentemente na fase de manutenção deste produto, estão impossibilitadas de atuar em novos projetos, porque não conseguiram produzir documentação que facilite a inserção de outros técnicos para ajudar neste trabalho, liberando, desta fase, os técnicos que participaram do projeto desde o início. Além da documentação, outro fator que enterra técnicos em um único projeto, são projetos desenvolvidos com processos pobres do ponto de vista de engenharia de software, o que dificulta as modificações e que só o chamado analista responsável, muitas vezes o único que sobrou do time de desenvolvimento, é capaz de implementar sem introduzir mais erros do que aqueles que está corrigindo.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] BEHFOROOZ, Ali; HUDSON, Frederick. Software engineering fundamentals. New York: Oxford University Press, 1996.
[2] SCHACH, S. R. Practical software engineering. Irving-Aksen: Homewood, 1992.
Manutenção de software é definida como o processo de modificação de um produto de software, componente ou sistema após a sua instalação, de forma a corrigi-lo, melhorá-lo ou adaptá-lo para uma mudança no ambiente operacional. Manutenibilidade de software é o atributo que caracteriza a facilidade de modificação ou adaptação de um software[1]. É muitas vezes quantificada em termos do tempo médio requerido para efetivar a revisão do software para eliminar um erro. Esse atributo é muito significativo para um software, na medida que a etapa de manutenção pode consumir até 65% do custo total de um produto[2].
Freqüentemente, a primeira vez em que aparecem questões de falhas de software é durante a fase de teste. Detecção de falhas, depuração, correção e teste de regressão são as atividades executadas durante a fase de teste e integração. Nesta fase, muitos dos problemas do software vêm a tona e são corrigidos, porém, fatalmente, outros somente aparecerão após a sua implantação, quando em operação pelos usuários.
Após a implantação do sistema em produção, a fase do ciclo de vida que inicia é a de manutenção. Nesta fase, a correção de um erro ou o melhoramento funcional obriga que a modificação seja analisada, implementada, testada, documentada e integrada. Por este motivo, cada manutenção acaba sendo sempre um processo trabalhoso e delicado, buscando que o novo código não introduza novos erros e que a documentação seja atualizada para refletir as modificações.
Alguns problemas que podem dificultar a atividade de manutenção, principalmente para aqueles software que atravessam muitos anos em atividade, são:
- A documentação do software se deteriorou através dos anos, e já não reflete a funcionalidade atual;
- Nenhum dos desenvolvedores do software está disponível para esclarecer as dúvidas;
- Forte integração do módulo que sofrerá manutenção com outros módulos;
- Alta complexidade algorítmica do módulo a ser modificado;
- Inexistência de controle de configuração do software;
- Inexistência de um ambiente para teste da manutenção;
- Alterações freqüentes no software motivadas, por exemplo, por necessidades legais.
A indústria de software não tem costume de desativar sistemas pelo fato de apresentarem algumas destas características e, por este motivo, devemos procurar alcançar as seguintes metas durante o desenvolvimento:
- Usuários e desenvolvedores devem estar bem informados da importância da manutenção, e requisitos de manutenibilidade devem ser detalhados e documentados, principalmente quando o software tem perspectiva de modificações constantes, como é o caso de sistemas que se baseiam em legislação que muda com freqüência;
- Estabelecimento de um conteúdo mínimo de documentação requerida que auxilie efetivamente o processo de manutenção;
- Determinar os atributos de design necessários para a manutenibilidade requerida e inclusão destes no plano de garantia de qualidade de software;
- Estabelecer um processo de manutenção efetivo, se possível, suportado por ferramenta automatizada.
O Processo de Manutenção
A meta primordial deste processo é facilitar a acomodação de mudanças, que são inevitáveis em produtos de software, reduzindo a
quantidade de esforço na fase de manutenção. Este processo deve ser amplo o bastante para suportar manutenção para a correção de um erro, dito corretiva, para a modificação de uma funcionalidade existente, adaptativa ou a inclusão de funcionalidade, perfectiva. Pedidos de mudança podem originar, por necessidade do usuário, alterações legais ou por diversos outros motivos. O que importa é que haja um processo formal e documentado para que a mudança seja efetivada ou rejeitada, registrando as informações independente do veredicto da mudança. Deve-se registrar mesmo a informação de rejeição, pelo fato dela ser solicitada novamente por outra fonte. Muitas vezes, diversas ações de mudança são empacotadas juntas em um único bloco, para facilitar a implementação e o controle.
O procedimento para conduzir a ação da manutenção deve incluir os seguintes passos:
- Avaliar a requisição da mudança, avaliando sua real necessidade;
- Avaliar o impacto da mudança dentro do sistema ou em sistemas ao qual está integrado;
- Estimar custo e tempo para implementação;
- Implementar as modificações;
- Testar os módulos modificados;
- Testar a integração do sistema;
- Atualizar a documentação;
- Integrar.
Conclusão
Curioso que a fase do ciclo de vida do software que, geralmente, consome a maior parte dos recursos, financeiros e humanos, das organizações de desenvolvimento de software em nível mundial, é a que menos atenção recebe quando estamos planejando o desenvolvimento de um software. Há muito pouco tempo, começamos a ouvir falar em manutenibilidade, palavra técnica que provavelmente nem conste no nosso dicionário, mas que vem ganhando destaque em nosso meio, justamente pelo motivo que move as organizações: Custo. Pensar em manutenibilidade durante o desenvolvimento de um software, é pensar em atributos que irão facilitar a implementação de modificações e, provavelmente, permitirão minimizar um panorama constante da nossa profissão. Pessoas que desenvolvem um único projeto e ficam permanentemente na fase de manutenção deste produto, estão impossibilitadas de atuar em novos projetos, porque não conseguiram produzir documentação que facilite a inserção de outros técnicos para ajudar neste trabalho, liberando, desta fase, os técnicos que participaram do projeto desde o início. Além da documentação, outro fator que enterra técnicos em um único projeto, são projetos desenvolvidos com processos pobres do ponto de vista de engenharia de software, o que dificulta as modificações e que só o chamado analista responsável, muitas vezes o único que sobrou do time de desenvolvimento, é capaz de implementar sem introduzir mais erros do que aqueles que está corrigindo.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] BEHFOROOZ, Ali; HUDSON, Frederick. Software engineering fundamentals. New York: Oxford University Press, 1996.
[2] SCHACH, S. R. Practical software engineering. Irving-Aksen: Homewood, 1992.