Os sistemas legados respondem pela maior parte do processamento de dados mundial, ou, dependendo de entendimentos, por todo. Isto porque, para SEACORD (2003) qualquer sistema em produção pode ser considerado como legado. Entre 60% e 70% dos sistemas estão em COBOL, estima-se em 200 milhões de linhas (SEACORD et al, 2003 e ULRICH, 2002).

A participação do custo de manutenção no custo total de um sistema tem crescido de 40%, nos anos 70, até 90%, atualmente (PIGOSKI, 1996). Destes custos, cerca de 20% são consumidos com correções e 80% com melhorias diversas (Martin apud ULRICH, 2002).

Segundo a ISO/IEC 14764 (1999), podemos distinguir quatro modalidades de manutenção de software: CORRETIVA, para corrigir problemas depois que aconteceram; ADAPTATIVA, para adequá-los a novos ambientes e mantê-los úteis nestes; PERFECTIVA, melhorias no desempenho e manutenibilidade; PREVENTIVA, corrigir falhas antes que aconteçam. Para Pressman (1995, p. 878), a manutenção perfectiva é que consome mais recursos e é resultante do software estar em uso e ser “bem-sucedido”. Este tipo de manutenção é responsável pela agregação de novas capacidades, alterações em funções existentes e ampliações gerais solicitadas pelos usuários.

Sistemas de informação “legados” devem ter equipes permanentes para manutenções corretivas, adaptativas e preventivas. Ou seja, alguns analistas, dependendo do tamanho do sistema, devem conhecê-lo profundamente, estarem preparados e em permanente trabalho de alteração (manutenção) do mesmo. Quando a área de TI vive em sobressaltos devido a erros nos seus SIs, ou vive “apagando incêndios”, é de se concluir que a organização tem um “gerenciamento” nulo, falho, imprudente ou inábil em algumas destas três categorias de manutenção.

A manutenção perfectiva pode ser mais flexível quanto à alocação de pessoal pois o atendimento às necessidades dos clientes, usuários e controladores pode ser “negociado”. Porém, o adiamento repetitivo neste atendimento e, juntando-se a falta de pessoal qualificado para as outras manutenções, certamente causará a “morte” do sistema. Ou, na melhor das hipóteses, um “pico” de esforço/custo em um determinado momento de “crise”. Estes “picos” podem consumir muito mais recursos do que o de uma equipe permanente e reduzida. Além de, na maioria das vezes, já terem causado “estresse” ou estragos na imagem e credibilidade da área de informática, e da empresa, junto a seus stakeholders e opinião pública.

Algumas organizações estão pouco preparadas para entender a importância da manutenção. Isso se constata pela falta de processos específicos para tratar do assunto ou, colocam analistas e programadores inexperientes e sem supervisão para fazerem as manutenções corretivas e acabam transformando o sistema em “uma colcha de retalhos” ou “macarrônico”. Em alguns casos tratam o processo de manutenção perfectiva como projetos de sistemas novos sem distinguirem a enorme diferença entre ambos. Outras vezes, fazem esforços monumentais, alocando grande soma de recursos para a condução de novos projetos que duram de um a dois anos e esquecem que, ao final, existirá um produto que precisará de manutenção, às vezes, por mais de 20 anos.

Enfim, a disciplina de manutenção de software precisa ser melhor desenvolvida, entendida e valorizada pelas organizações. Até que isso aconteça, a TI continuará a ser um “buraco sem fundo” de recursos e “mil novas idéias” de se atacarem as conseqüências continuarão surgindo.

(ISO/IEC 14764, 1999) ISO/IEC 14764. “Information technology – Software Maintenance”,1999.

(PIGOSKI,1996) Thomas.M., “Practical Software Maintenance”, John Wiley & Sons, Inc., 1996.

(PRESSMAN, 1995) ROGER, Pressman, “Engenharia de software”, Makron Books, 1995.|

(SEACORD et al, 2003) Seacord, Robert C., Plakosh, Daniel, Lewis, Grace A.|

“Modernizing Legacy Systems: Software Technologies, Engineering Processes, and|

Business Practices”, Addison-Wesley, 2003.

(ULRICH, 2002) Ulrich, William M., “Legacy Systems: Transformation Strategies”, 2002 Prentice-Hall PTR, 2002.