Desenvolvimento

Ξ 7 comentários

Aplicações antigas: reescrever ou manter?

publicado por Eduardo Virgílio

Provavelmente um dos dilemas que essas organizações – seja da iniciativa privada ou de um órgão do governo – se deparam hoje em dia ou vão enfrentá-lo nos próximos anos relaciona-se com a seguinte questão: devo continuar a manter as nossas aplicações antigas ou chegou a hora de reescrevê-las? Explico-me melhor. Uma aplicação ou um software de computador geralmente é criado para atender as necessidades das pessoas (ou usuários). Acontece que, com o passar do tempo, esses usuários exigem mudanças, o que é perfeitamente normal levando-se em conta que ocorre um aprimoramento dos seus processos de trabalho. Assim, pode-se afirmar que as aplicações nascem e em seguida passam a sofrer acréscimos com as melhorias sugeridas, algumas delas, inclusive, de ordem legal.

Na medida em que as melhorias são incorporadas na aplicação, o seu código (linhas escritas numa linguagem de programação) cresce e se modifica de forma ininterrupta. Por esse motivo diz-se que uma aplicação tem vida: ela nasce, cresce e um dia morre. A sua morte significa que ela é substituída por outra. Supõe-se que a substituta vá oferecer mais vantagens aos seus usuários, tais como novas funcionalidades, facilidades de uso, maior segurança, confiabilidade e um novo ciclo de vida. Mas, quando é que tiramos uma aplicação do ar? Quando sabemos que chegou a hora de aposentar a mesma?

Aplicações que foram escritas há mais de dez anos e continuam em produção, certamente são mantidas por profissionais da área tais como os analistas, projetistas e programadores que se encarregam de incorporar as melhorias que os seus usuários solicitam. Portanto existe em cada organização um time de profissionais envolvidos com o processo de manutenção.

Bom, depois de um dado tempo a aplicação começa a sofrer um processo irreversível de deterioração do seu código. A partir desse momento, a sua vida útil está quase no fim, então ela praticamente impede que sejam incorporadas novas mudanças na sua estrutura. Em alguns casos pode-se tentar a refatoração, ou seja, executar melhorias progressivas para manter a qualidade do código. No entanto, eu vejo que esse processo nem sempre consegue acomodar as novas exigências de mercado. Aí é que entra a dúvida: vamos reescrever essa aplicação ou persistir na sua manutenção?

O tempo de atendimento é um bom critério, mas não é o único empregado para definir se a aplicação deve ser reescrita ou não. A meu ver existem outros que devem ser avaliados. No entanto, eu diria que todos eles estão intimamente relacionados com a satisfação (produtividade) dos usuários.

Então, para aumentar a eficiência do seu trabalho, os usuários requerem que a sua aplicação sofra alterações de tal sorte que ele consiga usá-la na web, empregue dispositivos móveis (celular, Ipad), lance mão de redes sociais (facebook, twitter), passe a trabalhar com maior segurança (lei Sarbanes Oxley), use uma interface rica (Silverlight), que essa seja intuitiva (orientada a processos), seja multi língua, que a aplicação possa ser instalada nas Nuvens (Cloud Computing) ou que ela seja ofertada como serviço (Software as a Service). Enfim, se nossos usuários nos solicitam o atendimento a algumas dessas necessidades, chega-se rapidamente à conclusão que fica mais em conta desenvolver novamente a aplicação do que procurar inserir tais melhorias no seu código.

Provavelmente a seguinte analogia vai permitir expor com mais propriedade esse cenário. Imagine que o proprietário de um carro da década de oitenta ou noventa chega numa oficina e diz para o mecânico: “Olhe, quero que você faça poucas mudanças no meu veículo. Instale freios ABS, um GPS, meia dúzia de Air Bags, um câmbio Tip Trônic e uma direção hidráulica”. Provavelmente o mecânico vai lhe dizer que fica mais em conta comprar um carro com esses acessórios a promover a manutenção pedida.

Eu sei bem que nós, profissionais de TI, preferimos desenvolver aplicações a manter software legado. Ao nos depararmos com novidades, os desafios atiçam a nossa curiosidade e satisfazem o nosso potencial intelectual. Entretanto deve-se deixar claro que partir para o projeto de reescrita, empregando novas tecnologias, não é uma decisão simples. Ela passa, antes de mais nada, por uma exigência de mercado. Ou seja, não devemos inovar por inovar, mas sim devemos inovar para trazer resultados, para que a organização consiga fazer mais e melhor, para que ocorra um aumento na eficiência dos processos que geram produtos e serviços que ela se propõe a realizar.

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Eduardo Virgílio tem quase trinta e cinco anos dedicados ao desenvolvimento de software. Nesses últimos vinte e cinco ele tem trabalhado como CIO da LG Sistemas. Seu foco de atuação recai sobre a Engenharia de Software, área na qual ele ministrou disciplinas ao longo de vinte anos na Universidade Federal de Goiás. Formou-se em física pela UNB e em seguida obteve o título de mestre pela Universidade Federal do Rio Grande do Sul. Atualmente ele trabalha no projeto de reescrita da suíte composta pelos módulos de RH da sua empresa.

Eduardo Virgílio

Comentários

7 Comments

  • Sei que o Sr tem mais experiência do que eu, porém essa questão precisa ser muito bem analisada pela Empresa.
    Re-escrever envolve não apenas o desafio dos Engenheiros de software e suas equipes, mas também remapeamento de processos, workflow, reuniões, gerência de recursos, cronograma de prazos, previsão do esforço,Mais reuniões, Gestão de todo o Projeto, UMLs, Especificações funcionais, técnicas,mais reuniões, overheads e etc e mais reuniões.
    Como pode ver o custo é alto e o ROI do projeto tem que ser bem atraente para isso.
    Em algumas situações é melhor desenvolver ferramentas agregadas a base de dados do sistema original, com tecnologias mais modernas.

  • Mais uma vez o processo empírico de desenvolvimento de software sendo comparado ao processo prescritivo de construção/manuntenção de veículo.

    Penso que um software bem projetado, arquitetado e desenvolvido pode passar por quantas mudanças forem necessárias, o problema é que difilmente nos deparamos com software desenvolvidos com estes características, ainda mais quando falamos de softwares desenvolvidos a mais de 10 anos.

  • É Romulo, o que se aprende na universidade não é o que se encontra por ai.
    Nos meus mais de 15 anos de trabalho já vi coisas que até Bill Gates duvidaria. (eu nem vou citar que DEUS duvida, por que esse cara é muito bom. É o melhor Analista de Sistemas. Resolveu tudo em 7 dias.)
    Se me contassem eu tambem não acreditaria.
    Lógicas, ilógicas. Processos loucos. Em fim…
    Eu também gostaria de replanejar um sistema.
    Mas num ambiente Corporativo nem sempre isso é possível.
    Tem sempre um que diz: Quem paga por isso? Que Centro de custo irá arcar com isso?.
    Como afirmei acima, o Retorno Sobre Investimento (ROI) tem que ser muito bom para a diretoria tomar uma atitude dessa.
    O nosso amigo, Eduardo Virgilio, é um homem de sorte!
    Um forte abraço

  • Uma visão interessante mas temos que pensar que mesmo reescrevendo uma aplicação a mesma em 10 ou menos anos terá que ser reescrita. O interessante é investir tempo de projeto estruturando uma aplicação expansível e que possa com o futuro ser adaptada facilmente com baixo custo. Não devemos pensar que software é uma carro que fisicamente é complicado mudar, mas sim, algo da produção intelectual dos profissionais de TI.

  • Eduardo, seja bem vindo ao TI Especialistas. Seu artigo expressa muito bem uma realidade e dificuldade que algumas empresas enfrentam. Por vezes software complexo e obsoleto fica mais caro de manter do que o desenvolvimento de novo software, dotado de tecnologias e linguagens de programação mais atuais.

    É um processo complexo, pois além do software é necessário também atualizar os analistas e desenvolvedores na nova linguagem.

    Dependendo da dimensão da empresa isso pode representar milhares de reais de investimento, pelo que deve ser muito bem avaliado. Ainda assim, manter o software antigo pode representar um custo ainda maior.

  • Colega Eduardo, Acredito que o foco deve ser atender à demanda do cliente, ou seja, em meus pensamentos, creio que o certo para esta questão específica é reescrever a rotina, o aplicativo, de forma a atender às novas especificações de hardsoftware, desde que o resultado seja o mesmo que o anterior ou que o cliente deseja! Vejo uma série infinita de aplicativos, cheia de impedimentos por este ou por aquele motivo, e que de forma indistinta, são causados por manutenção de fontes, há muito incompatível com a ferramenta de desenvolvimento escolhida! Sempre que analiso um aplicativo ERP tupiniquim encontro aquela rotina matreira que o CEO, à época programador jr, desenvolveu em like xBase ou no velho e ótimo COBOL, mantida e chamada de função legada! Isto é um bom exemplo de que muitos aplicativos ainda mantém certa antiguidade, e que muitos ainda mantém o fonte, resistindo à mudança, seja para que o desenvolvedor originário possa manter estabilidade, seja porque não ha recursos para desenvolver, reescrevendo o aplicativo com novas funcionalidades da ferramenta escolhida. Enfim, a meu sentir, o mais correto é reescrever, mas vai embutir isso na cabeça dos CEO´s aqui do Brasil! Tarefa inglória, nobre colega! Abraços, Marcelo.

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.