REENGENHARIA EM SOFTWARE LEGADO

Luciana Ponche Dias1

RESUMO

Este artigo trata da proposta de aplicação da reengenharia em software legado, bem como vantagens e desvantagens da mesma, tendo como critério os custos, funcionalidades e desempenho, partindo do princípio de que um projeto de reengenharia em software legado tem por si a qualidade do software e melhor desempenho e produtividade nos processos gerenciais. Um software legado que passa pelo processo de reengenharia e consequentemente por engenharia reversa não perde suas funcionalidades, ao contrário, ele passa por um novo processo de codificação, estruturação, documentação, e esses processos são “chaves” para atingir a qualidade do mesmo. Através de pesquisa bibliográfica são exemplificadas as diretrizes que levam à necessidade de aplicar a reengenharia em software legado, bem como a importância da mesma dentro de uma organização. Através de pesquisa qualitativa, foi feito uma entrevista com um gerente de TI (tecnologia da informação), que já participou de diversos projetos de reengenharia em software legado. A mesma foi de grande relevância, uma vez foi possível alinhar a aplicabilidade de “qualidade de um software” correlacionado com um projeto bem sucedido ou não. Conclui-se que atualmente a necessidade de aplicar a reengenharia em software legado é cada vez maior e que a mesma contribui de maneira imprescindível nos processos organizacionais, porém por ser de tamanha complexidade, é preciso fazer um estudo detalhado de custos e necessidades. Palavras-Chave: legado, processos, qualidade, reengenharia, software.

INTRODUÇÃO

A variedade de problemas que envolvem manutenção de software cresce

constantemente, sendo que as soluções não acompanham esta evolução. A

reengenharia de software é uma das estratégias da evolução de software. Ocupa-se

de reimplementar sistemas legados, para que sua manutenção seja mais simples.

O grande dilema da reengenharia em software legado é que junto ao software

legado existem informações dos negócios e procedimentos que podem não estar

documentados. O risco de remover e reescrever tais programas são grandes, pois

muitas informações teriam que ser descobertas por tentativa e erro.

1 Graduada em Sistemas de Informação - UNESC

Esta obra tem por objetivo, apresentar a importância da reengenharia em

software legado, além disso, deixar explícito os conceitos relevantes do processo,

vantagens, desvantagens e custo, visando pela qualidade do software.

Para desenvolvimento desta pesquisa, foram utilizadas referências

bibliográficas disponíveis em livros, revistas, artigos, etc. Foi realizada uma pesquisa

de campo qualitativa através de uma entrevista com um gerente de TI. Também foi

feito uma análise de um questionário distribuído para 500 gestores de TI referente à

reengenharia em software legado, de caráter quantitativo.

Dar início à pesquisa de reengenharia em software legado é relevante, pois

muitas empresas ainda mantêm o software legado e a manutenção de sistemas

legados é cada vez mais dispendiosa, e a reengenharia prolonga o tempo de vida

útil do software. A reengenharia é eficaz em termos de custo quando ele tem alto

valor de negócios, melhora a estrutura do sistema, cria uma nova documentação

relacionada e faz com que ela seja de mais fácil compreensão.

1 SOFTWARE LEGADO

Um software é um artefato evolutivo e, com o passar do tempo, seu projeto e

implementação originais são modificados para atender a novos requisitos e/ou

melhorar o seu desempenho. Fatores internos e externos, como o estado da

economia, as modificações nos mercados, as alterações nas leis, as mudanças de

gestão e organização estrutural, contribuem para que as empresas sofram

mudanças contínuas (SOMMERVILLE, 2003).

Essas mudanças geram requisitos de software novos ou modificados; assim,

todos os softwares úteis inevitavelmente são modificados quando as empresas

passam por mudanças. Portanto, esses sistemas incorporam um grande número de

alterações que foram feitas durante muitos anos, além de incorporarem importantes

regras de negócio no seu contexto, são os chamados softwares legados, a palavra

“legado” traz um sentido pejorativo, similar ao adjetivo obsoleto. O nome “software

legado” é dado a sistemas antigos, em uso há determinado período e desenvolvidos

com tecnologia ultrapassada (SOMMERVILLE, 2003).

Existem muitas empresas que estão repletas de software legado em uso,

principalmente as empresas cujos processos são os mesmos por anos.

Normalmente as empresas gastam muito dinheiro na implantação do sistema e

esperam não ter o mesmo gasto novamente. Muitos desses antigos sistemas ainda

são fundamentais para as empresas, isto é, as empresas dependem dos serviços

fornecidos pelo software, e qualquer falha desses serviços teria um sério efeito em

seu dia a dia. Normalmente são aplicações complexas, de difícil manutenção e que

pelo grau de criticidade e custo para modernização, continuam ativas (BRAGA,

2004).

A preocupação com os “legados” está na baixa qualidade do mesmo. Muitas

vezes não existem documentações e se existem são pobres de detalhes, os casos

de testes são fracos e não há um controle de mudanças. Muitas vezes o engenheiro

de software não mexe no software legado quando o mesmo atende as necessidades

do cliente (BROOKS, 1995).

Algumas das principais características na identificação de um software legado

são: sistemas em produção há mais de cinco anos; hardware e software obsoletos;

sistemas com mais de 10 mil linhas de códigos; interface com o usuário baseada em

caractere; código-fonte amplamente modificado por diversas equipes ao longo dos

anos, com alterações não documentadas; documentação antiga e desatualizada,

não condizentes com as funcionalidades e processos atuais do sistema; utilização

de um sistema de arquivos ou gerenciador de banco de dados obsoletos; sistema

não conhecido em sua totalidade pelos profissionais responsáveis por sua

manutenção; usuários do sistema incapazes de explicar com detalhes suas funções

junto ao sistema e todos os processos que o mesmo executa; regras de negócio

inseridas apenas no código-fonte do sistema (BRAGA, 2004).

1.1 AVALIAÇÃO DO LEGADO

Segundo Warren ao avaliar um sistema legado, deve considerá-lo sob duas

perspectivas diferentes. A primeira seria sob a perspectiva de negócios (valor do

sistema para a empresa) e a segunda seria uma perspectiva de sistema (avaliação

da qualidade do software de aplicação e do software e hardware de apoio do

sistema). A junção dessas duas perspectivas é decisiva na hora de decidir o que

fazer com o sistema legado (WARREN, 1998).

A qualidade e o valor de negócios de cada um desses sistemas são avaliados e

comparados com outros sistemas, mediante um gráfico, que mostra o valor de

negócios relativo e a qualidade do sistema. Na figura (1), é possível verificar que

existem quatro grupos de sistemas e que se subdividem em: baixa qualidade, baixo

valor de negócios; baixa qualidade, alto valor de negócios; alta qualidade, baixo

valor de negócios e alta qualidade, alto valor de negócios (SOMMERVILLE, 2003).

Figura 1 – Qualidade de sistema e valor de negócio Fonte: SOMMERVILLE, 2003.

• Baixa qualidade, baixo valor de negócios: significa que manter esses sistemas

em operação será dispendioso e a taxa de retorno de investimento para os negócios

será pequena. Esses sistemas são candidatos a serem descartados (BRAGA, 2004).

• Baixa qualidade, alto valor de negócios: significa que esses sistemas estão

prestando uma importante contribuição à empresa, assim, não podem ser

descartados. Porém, sua baixa qualidade significa que os custos operacionais são

altos, de modo que são candidatos à transformação ou à substituição do sistema

(BRAGA, 2004).

• Alta qualidade, baixo valor de negócios: significa que são sistemas que não

contribuem muito para os negócios, mas cuja manutenção pode não ser

dispendiosa. Não vale o risco substituir esses sistemas, de modo que a manutenção

normal pode ser continuada ou eles podem ser descartados (WARREN, 1998).

• Alta qualidade, alto valor de negócios: significa que esses sistemas devem ser

mantidos em operação, mas sua alta qualidade significa que não é necessário

investir na sua transformação ou substituição. Deve-se continuar com a manutenção

normal do sistema (WARREN, 1998).

1.2 PROBLEMAS COM O LEGADO

Os sistemas legados constituem a parte mais importante do fluxo de

informações dentro das organizações e são os principais veículos para a

consolidação das informações sobre o negócio. O conhecimento agregado nestes

sistemas constitui um patrimônio corporativo significativo. Por tratar de sistemas

críticos apresentam numerosos problemas para as empresas (BISBAL, 1999).

A maioria dos sistemas legados passou por mudanças contínuas durante

muitos anos de manutenção. De acordo com a segunda lei de evolução de

programas de Lehman (1985), quando um programa em evolução é continuamente

modificado, sua estrutura se deteriora, consequentemente a complexidade aumenta.

Esse aumento de complexidade ocorre porque há uma precipitação ao elaborar as

correções dos problemas e não há tempo para manter o refinamento de um projeto

ou a consistência da abordagem em todo o código (LEHMAN, 1985).

A pressa em disponibilizar um produto pode levar mantenedores a implementar

uma modificação rápida, ineficiente e sem ter sido adequadamente testada, em vez

de utilizar o tempo necessário para seguir as boas práticas de engenharia de

software. O resultado é um produto com vários "remendos" e difícil de ser entendido

e mantido (LEHMAN, 1985).

Atualmente as organizações estão enfrentando uma grande pressão para

modernizar seus sistemas, a fim de que possam responder melhor às necessidades

de mercado e de pessoas e às rápidas mudanças de tecnologia (LEHMAN, 1985).

2 REENGENHARIA DE SOFTWARE

O software é o conjunto de vários artefatos e não apenas o código fonte. O

software não é um produto acabado, está sempre em mutação, condição esta

originária de mudanças nas regras de negócio, necessidade de melhoria do

processo produtivo ou da adequação do produto ou serviço (ZANLORENCI, 2009).

Muitas organizações têm enfrentado problemas com o uso e a manutenção de

software construído para ser executado em uma variedade de tipo de hardware e

programado em linguagem obsoletas. 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. Sendo assim, as organizações têm três alternativas: manter os

softwares legados, comprar um novo software 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 (SOMMERVILLE, 2003).

Quando o sistema não é fácil de ser mantido sendo, porém, de grande utilidade, ele deve ser reconstruído. Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software. Esse processo é denominado reengenharia de software (PIEKARSKI, 2000).

O termo reengenharia pode referir-se tanto à reengenharia do processo de

negócios quanto à reengenharia de sistemas. Trata-se de abordagens diferentes,

embora muitos autores afirmem que deveria haver uma maior sinergia entre estes

dois processos dentro de uma empresa (SILVA, 2005).

A reengenharia de software também chamada renovação ou recuperação de

software é definida como a recuperação rigorosa do conhecimento embutido em

sistemas existentes a fim de alavancar os esforços em seu aprimoramento,

procurando melhorar sua qualidade global e reduzir custos com manutenção, isto é,

reestruturar ou reescrever todo ou parte de um sistema legado sem alterar suas

funcionalidades (SILVA, 2005).

Um processo de reengenharia geralmente inclui tradução do código-fonte,

melhoria na estrutura do programa, modularização, alguma forma de engenharia

reversa seguida por uma forma de engenharia progressiva ou reestruturação e

reengenharia de dados (SILVA, 2005).

É importante ressaltar que existe clara distinção entre o desenvolvimento de um

novo software e reengenharia, a distinção está relacionada ao ponto de partida de

cada um dos processos. O desenvolvimento de um novo software (engenharia

progressiva) inicia-se com uma especificação escrita do software que será

construído, enquanto que a reengenharia inicia-se tomando como base um sistema

já desenvolvido. Como mostra a figura (2) abaixo (SOMMERVILLE, 2003).

O objetivo da engenharia reversa é derivar o projeto ou especificação de um

sistema, partindo-se de seu código fonte. O objetivo da reengenharia é produzir um

sistema novo com maior facilidade de manutenção. A engenharia reversa é usada

como parte do processo de reengenharia, pois fornece o entendimento do sistema a

ser reconstruído (SOMMERVILLE, 2003).

Figura 2 - Distinção entre o desenvolvimento de um novo software (1) e reengenharia (2) Fonte: SOMMERVILLE, 2003.

2.1 RELACIONAMENTOS NO CICLO DE DESENVOLVIMENTO

Para uma melhor compreensão das técnicas de manutenção de software, é

preciso considerar três conceitos dependentes: a existência de um processo de

desenvolvimento de software, a presença de um sistema a ser analisado e a

identificação de níveis de abstração (OSBORNE e CHIKOFSKY, 1990).

Independente do que seja o processo de desenvolvimento de software, espera-

se que haja interação entre seus estágios e, quiçá, recursão. No processo de

desenvolvimento, os estágios iniciais envolvem conceitos independentes de

implementação, enquanto os estágios finais enfatizam os detalhes de

implementação (OSBORNE e CHIKOFSKY, 1990).

O aumento de detalhes durante o processo de desenvolvimento conceitua os níveis de abstração. Estágios iniciais do sistema planejam e definem requisitos de alto nível quando comparados com a própria implementação (PIEKARSKI, 2000).

Esta comparação deixa claro que nível de abstração e grau de abstração são

grandezas distintas. Enquanto o nível de abstração é um conceito que diferencia os

estágios conceituais do projeto, o grau de abstração é intrínseco a cada estágio

(PIEKARSKI, 2000).

Para que as técnicas de manutenção de software (especificamente engenharia

reversa e reengenharia) sejam descritas de forma simplificada, serão tomadas como

base três fases do processo de desenvolvimento de software, com níveis de

abstração diferenciados, conforme figura 3 (OSBORNE e CHIKOFSKY, 1990):

• Requisitos: especificação do problema a ser resolvido, incluindo objetivos,

restrições e regras de negociação;

• Projeto: especificação da solução;

• Implementação: codificação, teste e adaptação ao sistema operacional;

Figura 3 - Relacionamentos no ciclo de desenvolvimento de software Fonte: CHIKOFSKY e CROSS, 1990.

2.2 PROCESSO DE REENGENHARIA DE SOFTWARE

O processo de reengenharia é um dos desafios mais significativos para

engenheiros de software e é sob um processo bem definido que a estabilidade no

desenvolvimento do software pode ser instituída. O problema é comum, afetando

todos os tipos de organização, pois uma falha na reengenharia pode dificultar os

esforços da organização para manter-se competitiva (BORGES, 2007).

A capacitação em desenvolvimento de software pressupõe a existência de um

processo de software definido no qual é aplicado um modelo de melhoria de

processos. O processo definido tem documentação que detalha o que é feito,

quando, por quem, o que é utilizado e o que é produzido. A maturidade do processo

indica até que ponto um processo é definido e implementado, utilizando para isso

aspetos como métricas para verificação do controle e da eficácia (BORGES, 2007).

Assim, a capacitação em desenvolvimento de software reflete o grau de

institucionalização de uma infraestrutura e cultura relacionada aos métodos, práticas

e procedimentos do desenvolvimento de software. Reflete, também, a qualidade do

processo, pois a qualidade dos produtos de software depende diretamente da

qualidade do processo de desenvolvimento a eles associados (BORGES, 2007).

Um processo de reengenharia tem como entrada um programa legado e a

saída é uma versão estruturada e modularizada do mesmo programa. Ao mesmo

tempo em que ocorre a reengenharia do programa, os dados do sistema também

podem passar por reengenharia (BORGES, 2007).

A reengenharia de dados é o processo de analisar e reorganizar estruturas de dados e, eventualmente, os valores dos dados de um programa, com o objetivo de torná-lo mais compreensível. Em princípio, a reengenharia de dados não deverá ser necessária, se a funcionalidade do sistema permanecer inalterada. Na prática, há uma série de razões pelas quais é preciso modificar os dados, como também os programas, em um sistema legado (SOMMERVILLE, 2003).

Efetuar o processo de reengenharia em uma aplicação implica em examinar e

alterar um sistema com o propósito de reconstituí-lo em um novo modelo e uma

implementação de nova forma. A figura 4 exibe as principais etapas no processo de

reengenharia de software (PIEKARSKI, 2000).

Figura 4 – Processo de reengenharia Fonte: SOMMERVILLE, 2003

3 METODOLOGIA

Até este ponto da obra, foi apresentada a pesquisa bibliográfica, que remete a

uma série de conceitos e perspectivas sobre a reengenharia em software legado.

Foi realizada uma pesquisa de campo de cunho qualitativo, com um gerente de

TI que se submeteu a uma entrevista (por troca de e-mails) com perguntas

relacionadas ao processo de reengenharia em software legado em que ele teve

participações. Através da entrevista é perceptível a concepção de vários tópicos

citados no referencial bibliográfico.

3.1 ENTREVISTA COM GERENTE DE TI

Em entrevista com Keiji Sakai, bacharel em ciência da computação, MBA e

certificado em diversas áreas de gerência, que ocupa há dois anos e meio o cargo

de diretor de TI da BM&FBOVESPA, e que já passou por diversas instituições

financeiras, entre elas: ESM Consultoria e Projetos em TI LTDA; JPMorgan Chase;

HSBC Bank Brasil; Deutsche Bank S/A - Banco Alemão; UNIBANCO; Banco Matrix

S/A; Banco de Investimentos Garantia e Banco Norchem, exprime de forma sucinta

suas diversas experiências em projetos de reengenharia em software legado.

Você já teve oportunidade de participar do processo de reengenharia de

software? Se sim, discorra sobre os principais pontos. Levando em

consideração adaptação dos usuários, melhorias, custos, vantagens e

desvantagens.

SAKAI: Sim, em diversas instituições financeiras. Em primeiro lugar, é importante

explicar o que considero reengenharia de software – na minha visão, reengenharia

de software é reconstruir uma aplicação ou parte dela, corrigindo defeitos existentes

ou saneando códigos antigos, ou ainda renovando componentes para a plena

utilização dos melhores recursos de software e hardware existentes.

Neste sentido, em reengenharias de software onde não ocorreram grandes

mudanças de interação aos usuários, mas trouxeram claramente vantagens, seja na

correção ou na melhoria de performance, a recepção dos mesmos foi sempre muito

positiva. Naquelas onde a interação dos usuários com a aplicação teve alteração,

principalmente devido a grandes rupturas tecnológicas (mainframe para micro

informática, plataforma DOS para Windows, desktops para tablets), as primeiras

movimentação provocaram resistência dos usuários principalmente devido à

mudança da rotina operacional dos mesmos. Com relação a custos, vantagens e

desvantagens, existe uma falsa percepção que a reengenharia seria “mais barata”

do que um novo desenvolvimento – em algumas situações isto não foi verdade, pois

o nível de integração dos legados aliado a complexidade de novas tecnologias

encareceu alguns dos projetos. Em algumas situações, o custo de uma

manutenção corretiva do sistema legado seria muito mais vantajoso que uma ação

de reengenharia de software.

O que levou/leva a empresa a passar pelo processo de reengenharia no

software?

SAKAI: Alguns dos grandes motivadores: estratégia de downsizing da instituição,

custo de manutenção de legados, nível de instabilidade de legados em decorrência

de manutenções e customizações “complementares” e por fim, estratégia de

negócios para lançamento de novas interações entre as aplicações das instituições

e os clientes finais.

Quais são os principais aspectos que um gestor de TI precisa avaliar se

tratando do “software”?

SAKAI: A criticidade da aplicação que precisa ser reescrita precisa ser avaliada –

numa instituição financeira onde algumas aplicações precisam funcionar em regime

24 x 07, o risco de instabilidade pode provocar perdas milionárias e fuga de clientes.

Além disto, em ambientes extremamente regulados a consistência das informações

(incluindo eventuais cálculos) são de extrema criticidade. Neste sentido, planos

para garantir a qualidade do sistema devem ser colocados em prática, como por

exemplo, testes regressivos, certificações com o mercado, produção paralela e

simulações dos requisitos não funcionais devem estar no radar do gestor de TI.

Quais são os principais motivos que levam ao “abandono” do software

legado?

SAKAI: Obsolescência aliada a instabilidade e ao alto custo de manutenção. No

caso da obsolescência, o risco operacional em decorrência de descontinuidade de

software, hardware e tecnologia pode obrigar as instituições a partir para uma

estratégia de reengenharia.

No processo de reengenharia o risco de perder funcionalidades do software

legado ainda existe, quais são as medidas para tal acontecimento?

SAKAI: Para evitar este tipo de situação, o mapeamento das funcionalidades é

fundamental. Na inexistência de documentação atualizada, os trabalhos tradicionais

de Analise de Sistemas e Analise de Processos deve fazer parte do projeto.

Você utiliza algum modelo para desenvolvimento do projeto de reengenharia

ou adapta algum modelo?

SAKAI: Sobre metodologia ou modelos, em cada instituição utilizávamos

metodologias e modelos diferentes. O importante tanto na definição dos artefatos

como na metodologia é a de não burocratizar o processo, com controles e

documentações não necessárias.

Qual é o momento de aplicar a reengenharia no software. Quais aspectos

contribuem para isso?

SAKAI: A reengenharia deve ser aplicada nos momentos em que os software

legados não estão mais aptos a atender as necessidades. Por exemplo, volume

transacional, performance, tecnologia, alterações regulatórias e estratégias de

negócio.

O processo de reengenharia de software pode ser a “solução” dos problemas

dos softwares legados?

SAKAI: Neste ponto é importante ressaltar que durante muitos anos o mercado de TI

do Brasil estava fechado para provedores estrangeiros (reserva de mercado) e com

isto, o desenvolvimento de soluções domésticas foi amplamente aplicado. Com o

fim da reserva de mercado e a vinda de vários provedores com soluções globais, a

dependência de legados internos diminui. Por exemplo, para uma empresa que na

década de 80 decidiu desenvolver um sistema de BackOffice para controlar todo o

seu processo produtivo, eu não partiria para a reengenharia da solução e sim,

buscaria um ERP de mercado.

Para soluções específicas que não são atendidas pelo mercado e que são criticas

para as organizações, a reengenharia é a solução.

Qual o papel do gerente de TI, na gestão e qualidade do software?

SAKAI: Em algumas organizações, a qualidade do software é de responsabilidade

do gestor de TI junto com um gestor de Qualidade. Mas com relação aos aspectos

técnicos com os requisitos não funcionais, de arquitetura, segurança da informação

e tecnologia adotada, a responsabilidade é principalmente do gestor de TI.

Qual é a visão pós-reengenharia?

SAKAI: Tive boas e más experiências – mas não em decorrência da reengenharia

em si. Os maus resultados foram em decorrência de falhas, seja na especificação

dos requisitos funcionais, seja na construção das soluções.

Considerações finais (nesta parte fica livre do entrevistado, ressaltar algum

ponto que não foi citado, contar experiência de vida profissional, dicas, ou

seja, tudo que venha acrescentar ao trabalho).

SAKAI: Um projeto de reengenharia de software não é facilmente aprovado. O

argumento de necessidade para melhoria de ambientes ou mitigação de riscos

operacionais sem a quantificação dos benefícios financeiros não são fortes o

suficiente para que um CIO tome a decisão de aprovar um projeto. Mesmo os

CIOs que patrocinam projetos de reengenharia por conta própria, assumem riscos

que, caso os projetos não sejam extremamente bem sucedidos, colocam sua

credibilidade na instituição em risco. Considerando a “comoditização” cada vez

maior de software, em minha opinião são poucas as reais necessidades de

reengenharia de software nos dias atuais.

3.2 ANÁLISE E DISCUSSÃO DOS RESULTADOS

Mediante entrevista, é possível perceber que há casos em que a única opção é

a reengenharia, pois a descontinuidade do software e limitações do hardware faz

com que o processo organizacional também não evolua. Contudo, a reengenharia

deve ser aplicada apenas para sistemas críticos que não podem ser substituídos por

soluções de mercado.

Sobre os “custos” é interessante a forma como é colocado, uma vez que os

custos, só serão altos ou baixos dependendo da situação a qual o software se

encontra, porém é bom lembrar que um software que passa por reengenharia, tem

sua performance e funcionalidades melhoradas, com isso, pedidos de manutenção,

serão cada vez menores, e o gasto com o mesmo diminuirá.

Outro ponto interessante, foi a forma como o software é “inserido” na

organização, sendo instrumento de negócio e de lucro, porém o mau funcionamento

do mesmo irá acarretar problemas em toda a hierarquia da organização. A partir do

momento em que o software legado não atende mais as necessidades é hora de

agir, seja passar por um processo de reengenharia ou buscar algo novo no mercado.

É visível o quanto é difícil e complexo implantar e ter o projeto de reengenharia

aceito, uma vez que ainda existe insegurança nos processos, pois como foi dito, os

processos de reengenharia precisam ser bem feito para dar certo. Existem hoje

diversas ferramentas CASE que agilizam os processos, porém elas não são os

únicos fatores determinantes, uma boa gestão é crucial.

CONCLUSÃO

Mediante estudo, conclui-se que realizar a reengenharia em software legado,

depende de muitos fatores, tanto gerenciais quanto a preocupação de se fazer algo

com qualidade.

A importância da reengenharia está em possibilitar que todo conhecimento

agregado (funções e procedimentos específicos de caráter particular e único) ao

software legado não seja perdido. Porém se existir um software no mercado que

supra as funções do “legado”, a melhor opção seria sim, implantar este software.

Finalizando, é conclusivo que o software quando chega ao seu estado crítico,

precisa de medidas para que o mesmo continue em uso, o papel de um gestor de TI

é buscar pela melhor solução.

REFERÊNCIAS

BISBAL, Jesus. Uma visão geral da migração do sistema legado, 1999. BORGES, Rosemary. Sistemas legados, 2007. BRAGA, Jose Luiz; PINTO, Hebert Laroca Mendes. Sistemas legados e novas tecnologias: técnicas de integração e estudo de caso, 2004. BROOKS, F. P. Ensaios sobre Engenharia de Software. 1. ed. MA: Addison-Wesley, 1995. CHIKOFSKY, E. J.; CROSS, J. H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, 1990. LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution, 1985. OSBORNE, W. M.; CHIKOFSKY, E. J. Manutenção de software, 1990.

PIEKARSKI, Ana; Reengenharia de software: o que, por que e como. Disponível em: <revistas.unicentro.br/index.php/RECEN/article/download/528/697>. Acesso em: 19 Mai. 2013. SILVA, Roberto Andrade de. Migração e Integração de Sistemas Legados, 2005. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Addison-Wesley, 2003. WARREN, Ian. Um método para avaliar Sistemas Legados para a Evolução, 1998. ZANLORENCI, Edna; Abordagem da Engenharia de Requisitos para Software Legado. Disponível em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>. Acesso em: 27 Ago. 2013.