Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que trata o artigo

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


Para que serve

Ampliar o conhecimento sobre reengenharia de software, saber identificar e aplicar os Padrões para a Reengenharia e, auxiliar os gerentes de projeto em TI e Analistas de Sistemas na adoção de reengenharia de sistemas legados procedimentais para o paradigma orientado a objetos


Em que situação o tema é útil

Na avaliação de um re-projeto de um sistema legado procedimental, apoiar a melhoraria da qualidade dos processos de software e do planejamento de questões administrativas em projetos de TI e, garantir a qualidade do processo de 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.

Nas últimas décadas, o fator qualidade com relação ao processo de desenvolvimento de software foi bastante estudado tendo sido elaborados vários modelos de melhoria e amadurecimento do mesmo, o que elevou sua capacitação para a geração de software.

Assim, no processo de reengenharia, a garantia da qualidade também foi encarada como mais uma etapa do processo. A definição de um processo completo de software deve incluir atividades de controle de projeto, garantia da qualidade, gerenciamento de configuração, além de ferramentas e métodos de engenharia de software.

A definição de padrões de reengenharia tem sido abordada por diversos autores atualmente, pela necessidade da existência de diretrizes mais consistentes para guiar a realização do processo.

Este artigo foi baseado no trabalho escrito por LEMOS (2002), o qual propõe que a qualidade de processo de desenvolvimento de software é desafio também no processo de reengenharia. Dessa forma, no trabalho supracitado, a aplicação de modelos de melhoria da qualidade, originalmente utilizados no processo de desenvolvimento de software, em apoio ao processo de reengenharia é também utilizada, com o objetivo de tornar o processo de reengenharia orientada a objetos mais eficiente e maduro.

LEMOS (2002) optou por descrever esse processo utilizando-se padrões, pelo fato de tornarem o aprendizado, pelos engenheiros de software, mais fácil dado seu formato padronizado. Dessa forma, foi proposto um Processo de Reengenharia Orientada a Objetos, denominado PRE/OO esperando auxiliar engenheiros de software a realizar a reengenharia de sistemas legados, obtendo sua completa re-estruturação, de forma facilitada.

Conhecendo a Engenharia Reversa

O termo “engenharia reversa” teve sua origem na análise do hardware, em que a prática de extração de projetos de produtos concluídos é comum, sendo aplicada para a melhoria desses produtos e análise de produtos de competidores.

Nesse contexto, a engenharia reversa pode ser definida como o processo de desenvolvimento de um conjunto de especificações para um sistema de hardware complexo através do exame ordenado dos componentes do sistema. Enquanto que para o hardware o objetivo tradicional da engenharia reversa é duplicar o sistema, para o software esse processo é mais frequentemente utilizado para se obter um suficiente entendimento do mesmo no nível de desenvolvimento. Portanto, define-se engenharia reversa para um software como o processo de análise para identificar seus componentes e inter-relacionamentos e criar representações do mesmo em outra forma ou num nível mais alto de abstração.

...
Quer ler esse conteúdo completo? Tenha acesso completo