Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Engenharia de Software Magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Reengenharia de Software Orientado a Objetos - Engenharia de Software 33
Este artigo apresenta questões envolvendo a manutenção de software evolutiva e adaptativa, conceitos sobre Reengenharia de Software e elucidação dos padrões para reengenharia de software
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Engenharia de Software Magazine 33
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Engenharia de Software Magazine 33
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Engenharia de Software Magazine 33
Reengenharia de Software Orientado a Objetos
Muitas organizações têm enfrentado problemas com o uso e a manutenção de sistemas de software construídos para serem executados em uma variedade de tipos de hardware e programados em linguagens obsoletas. Com o passar do tempo, a tarefa de realizar a manutenção torna-se mais complexa e mais cara e, ainda, esses sistemas tornam-se cada vez mais desorganizados devido às inúmeras tentativas de adaptações e inclusões de novas funcionalidades. Há ainda muitos softwares nessa situação devido à rápida evolução das ferramentas, tecnologias e métodos, conseguida pelas indústrias de computadores e empresas de tecnologia da informação. Sendo assim, as organizações têm três alternativas: manter os softwares legados com a situação já descrita de desorganização e custos cada vez maiores, reconstruir os softwares ou realizar a reengenharia tanto para aumentar sua manutenibilidade quanto para implementá-los em um paradigma mais atual com ou sem mudança de linguagem.
No caso de manter um software legado, apenas efetuando-se as manutenções para que o mesmo continue operando, muitos problemas podem ocorrer, tais como a alocação de pessoal para essa tarefa que pode ter uma porcentagem bastante significativa do esforço de uma organização, além da falta de sua documentação, comum nesses casos e que torna ainda mais crítica a situação.
A opção pela reconstrução de um software legado também tem problemas associados. O fato de que software tem regras de negócios embutidas, que podem não estar documentadas e a possibilidade das pessoas que as dominam não estarem mais na empresa, faz com que a sua completa reconstrução não seja tão confiável. Além disso, outro problema dessa opção é o custo do re-desenvolvimento global do software, geralmente muito alto, consumindo tempo e recursos que, na maioria das vezes, as empresas não dispõem.
A engenharia reversa e/ou reengenharia são as formas que muitas organizações estão buscando para manter/refazer seus softwares, livrando-se das manutenções difíceis e da degeneração de suas estruturas. Por esse motivo, é importante que o resultado desse processo seja confiável.
"
Este é um post disponível para assinantes MVP
Muitas organizações têm enfrentado problemas com o uso e a manutenção de sistemas de software construídos para serem executados em uma variedade de tipos de hardware e programados em linguagens obsoletas. Com o passar do tempo, a tarefa de realizar a manutenção torna-se mais complexa e mais cara e, ainda, esses sistemas tornam-se cada vez mais desorganizados devido às inúmeras tentativas de adaptações e inclusões de novas funcionalidades. Há ainda muitos softwares nessa situação devido à rápida evolução das ferramentas, tecnologias e métodos, conseguida pelas indústrias de computadores e empresas de tecnologia da informação. Sendo assim, as organizações têm três alternativas: manter os softwares legados com a situação já descrita de desorganização e custos cada vez maiores, reconstruir os softwares ou realizar a reengenharia tanto para aumentar sua manutenibilidade quanto para implementá-los em um paradigma mais atual com ou sem mudança de linguagem.
No caso de manter um software legado, apenas efetuando-se as manutenções para que o mesmo continue operando, muitos problemas podem ocorrer, tais como a alocação de pessoal para essa tarefa que pode ter uma porcentagem bastante significativa do esforço de uma organização, além da falta de sua documentação, comum nesses casos e que torna ainda mais crítica a situação.
A opção pela reconstrução de um software legado também tem problemas associados. O fato de que software tem regras de negócios embutidas, que podem não estar documentadas e a possibilidade das pessoas que as dominam não estarem mais na empresa, faz com que a sua completa reconstrução não seja tão confiável. Além disso, outro problema dessa opção é o custo do re-desenvolvimento global do software, geralmente muito alto, consumindo tempo e recursos que, na maioria das vezes, as empresas não dispõem.
A engenharia reversa e/ou reengenharia são as formas que muitas organizações estão buscando para manter/refazer seus softwares, livrando-se das manutenções difíceis e da degeneração de suas estruturas. Por esse motivo, é importante que o resultado desse processo seja confiável.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Engenharia de Software Magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
É desenvolvedor Delphi desde 1997, com ampla experiência em aplicações Win32. Graduado em Informática pela UFJF, com Especialização em Desenvolvimento de Aplicações para Web pelo Centro de Ensino Superior de Juiz de Fora/MG, e Mestrado em Computação pela UFF/Niterói-RJ. Atualmente é professor univer...
O que você achou deste post?
Cursos relacionados
Publicidade
