The role of `value quality´

Segundo Grubb e Takang (2003, p.55) manutenções corretivas e preventivas acontecem periodicamente, a um custo relativamente baixo, porém incremental. Com poucas exceções, requisições de manutenções adaptativas e perfectivas também ocorrem intermitentemente, ao custo de uma fração do desenvolvimento de um novo sistema. No longo prazo, o custo total dessas manutenções representa um valor considerável ao longo do ciclo de vida do sistema. No curto prazo, entretanto, a organização pode preferir gastar com as pequenas manutenções de custo comparativamente baixo enquanto realiza outros projetos mais ambiciosos e que demandem mais recursos financeiros.

Estudos mostram uma evolução histórica dos custos da manutenção. Segundo Pigoski (1996) e Pfleeger (2001) 80% dos custos de um software referem-se à manutenção. A Figura 3 mostra a evolução histórica desses custos, indo de 40% na década de 70 e chegando a 90%, no início dos anos 90, indicando um aumento progressivo da atividade de manutenção. Os problemas e dificuldades enfrentados durante a manutenção, alguns deles identificados anteriormente, contribuem significativamente para o aumento dos custos da manutenção dos sistemas.

A evolução do sistema, assim como a evolução do software é inerentemente onerosa por várias razões (Sommerville, 2007, p.23):

ƒ As mudanças propostas precisam ser analisadas com muito cuidado, tanto da perspectiva de negócios como do ponto de vista técnico. Essas mudanças precisam contribuir com os objetivos do sistema e não devem simplesmente ocorrer por motivos técnicos. Elas também devem ser aprovadas por uma série de pessoas antes de serem efetivadas (Sommerville, 2007, p.30).

ƒ Como os subsistemas nunca são totalmente independentes, as mudanças em um subsistema podem afetar desfavoravelmente o desempenho e o comportamento de outros subsistemas. Portanto, mudanças posteriores nesses subsistemas podem ser necessárias.

ƒ Os motivos das decisões do projeto original geralmente não são registrados. Os responsáveis pela evolução do sistema precisam imaginar por que determinadas decisões de projeto foram tomadas.

ƒ À medida que os sistemas “envelhecem”, sua estrutura é corrompida por mudanças e, dessa forma, o custo de novas mudanças aumenta.

Uma razão importante pela qual os custos de manutenção são altos é que é mais dispendioso acrescentar uma funcionalidade depois que o sistema estiver em operação do que implementar a mesma funcionalidade durante o seu desenvolvimento. Os principais fatores que distinguem o desenvolvimento e a manutenção e que levam a custos de manutenção mais altos são (Sommerville, 2003, p.520):

ƒ Estabilidade da equipe – Depois de um sistema ter sido entregue, é normal a equipe de desenvolvimento se dispersar para trabalhar em novos projetos. A nova equipe ou os indivíduos responsáveis pela manutenção do sistema não compreendem o sistema ou o background das decisões de projeto do sistema. É necessário bastante esforço durante o processo de manutenção, a fim de compreender o sistema existente, antes de implementar mudanças nele.

ƒ Responsabilidade contratual – O contrato para fazer a manutenção de um sistema, geralmente, é separado do contrato de desenvolvimento do sistema. O contrato de

estabilidade da equipe, significa que não há nenhum incentivo para uma equipe de desenvolvimento escrever o software de maneira que seja fácil de ser modificado. Se uma equipe de desenvolvimento puder optar pela simplificação, a fim de economizar esforço durante o desenvolvimento, vale a pena que proceda dessa maneira, mesmo que isso signifique aumento dos custos de manutenção.

ƒ Habilidade da equipe – O pessoal de manutenção, freqüentemente, tem pouca experiência e não está familiarizado com o domínio da aplicação. A manutenção tem uma imagem ruim entre os engenheiros de software. Ela é vista como um processo que requer menos habilidade do que o desenvolvimento do sistema e geralmente é designada para o pessoal mais novo. Além disso, os sistemas podem ter sido escritos em linguagens de programação obsoletas. O pessoal da manutenção pode não ter muita experiência do desenvolvimento com base nessas linguagens e precisa aprendê-las para fazer a manutenção do sistema.

ƒ Idade e estrutura do programa – À medida que os programas envelhecem, suas estruturas tendem a se tornar mais difíceis de ser entendidas e modificadas. Além disso, muitos sistemas legados foram desenvolvidos sem as modernas técnicas de engenharia de software. Elas nunca foram bem estruturadas e eram freqüentemente otimizadas com vistas à eficiência, e não à facilidade de compreensão. A documentação dos sistemas antigos pode não ter passado pelo gerenciamento de configuração; assim, perde-se tempo procurando as versões certas dos componentes de sistema que devem ser modificados.

Os primeiros três problemas surgem do fato de que muitas organizações ainda fazem distinção entre o desenvolvimento e a manutenção de sistemas. A manutenção é vista como uma atividade de segunda classe e não há nenhum incentivo em gastar dinheiro durante o desenvolvimento para reduzir os custos de modificação no sistema. A única solução no longo prazo para esse problema é aceitar que os sistemas raramente têm um tempo de vida útil definido, mas continuam em uso, de alguma maneira, por um período indefinido (Sommerville, 2003, p.521).

Segundo Sommerville (2003, pp.498-499), manter sistemas em uso evita os riscos de substituição por novos sistemas, no entanto alterar um software existente torna-se mais dispendioso à medida que o sistema se torna mais velho. Os sistemas legados são particularmente dispendiosos no que se refere a fazer alterações, por diversas razões:

ƒ Diferentes partes do sistema foram implementadas por diferentes equipes. Portanto, não há um estilo de programação consistente em todo o sistema.

ƒ Parte do sistema ou todo o sistema pode ser implementado com a utilização de uma linguagem de programação obsoleta. Pode ser difícil encontrar pessoal que tenha conhecimento dessa linguagem. Além disso, pode ser necessário um gasto dispendioso com a manutenção do sistema.

ƒ Freqüentemente a documentação do sistema é inadequada e desatualizada. Em alguns casos, a única documentação é o código-fonte do sistema. Algumas vezes, o código-fonte foi perdido e somente a versão executável do sistema está disponível. ƒ Em geral, muitos anos de manutenção podem ter corrompido a estrutura do sistema,

tornando-o cada vez mais difícil de ser compreendido. É possível que novos programas tenham sido acrescentados e que tenham sido criadas interfaces destes com outras partes do sistema, de acordo com a necessidade.

ƒ O sistema pode ter sido otimizado para melhorar o uso de espaço ou a velocidade de execução em vez de ter sido escrito para facilitar a compreensão. Isso acarreta dificuldades específicas para os programadores que aprenderam modernas técnicas de engenharia de software e que não foram expostos a truques de programação. ƒ Os dados processados pelo sistema podem estar armazenados em diferentes

arquivos, que podem ter estruturas incompatíveis. É possível que alguns dados tenham sido duplicados ou estejam desatualizados, inexatos ou incompletos.

Polo, Piatini e Ruiz (2003, p.vi) afirmam que a manutenção é o estágio mais oneroso do ciclo de vida do software, uma vez que novos ambientes e tecnologias requerem grandes esforços de manutenção para manter os sistemas em operação e, segundo esses autores, não há motivos para pensar que esta situação irá se modificar.

A observação de Sommerville (2003) remete à motivação desta pesquisa. Manter um sistema não é uma decisão trivial e puramente técnica. Os gestores devem ser capazes de justificar os investimentos em manutenção de sistemas legados através de métodos de avaliação de investimento, para então decidir se vale à pena investir esforços e recursos para manter um sistema atualizado em vez de desenvolver um novo que o substitua.