REENGENHARIA EM SOFTWARE LEGADO Luciana Ponche Dias1 RESUMO Este artigo trata da proposta de aplicao da reengenharia em software legado,

bem como vantagens e desvantagens da mesma, tendo como critrio os custos, funcionalidades e desempenho, partindo do princpio 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 no perde suas funcionalidades, ao contrrio, ele passa por um novo processo de codificao, estruturao, documentao, e esses processos so chaves para atingir a qualidade do mesmo. Atravs de pesquisa bibliogrfica so exemplificadas as diretrizes que levam necessidade de aplicar a reengenharia em software legado, bem como a importncia da mesma dentro de uma organizao. Atravs de pesquisa qualitativa, foi feito uma entrevista com um gerente de TI (tecnologia da informao), que j participou de diversos projetos de reengenharia em software legado. A mesma foi de grande relevncia, uma vez foi possvel alinhar a aplicabilidade de qualidade de um software correlacionado com um projeto bem sucedido ou no. Conclui-se que atualmente a necessidade de aplicar a reengenharia em software legado cada vez maior e que a mesma contribui de maneira imprescindvel nos processos organizacionais, porm por ser de tamanha complexidade, preciso fazer um estudo detalhado de custos e necessidades. Palavras-Chave: legado, processos, qualidade, reengenharia, software.

INTRODUO A variedade de problemas que envolvem manuteno de software cresce constantemente, sendo que as solues no acompanham esta evoluo. A reengenharia de software uma das estratgias da evoluo de software. Ocupa-se de reimplementar sistemas legados, para que sua manuteno seja mais simples. O grande dilema da reengenharia em software legado que junto ao software legado existem informaes dos negcios e procedimentos que podem no estar documentados. O risco de remover e reescrever tais programas so grandes, pois muitas informaes teriam que ser descobertas por tentativa e erro.

Graduada em Sistemas de Informao - UNESC

Esta obra tem por objetivo, apresentar a importncia da reengenharia em software legado, alm disso, deixar explcito os conceitos relevantes do processo, vantagens, desvantagens e custo, visando pela qualidade do software. Para desenvolvimento desta pesquisa, foram utilizadas referncias bibliogrficas disponveis em livros, revistas, artigos, etc. Foi realizada uma pesquisa de campo qualitativa atravs de uma entrevista com um gerente de TI. Tambm foi feito uma anlise de um questionrio distribudo para 500 gestores de TI referente reengenharia em software legado, de carter quantitativo. Dar incio pesquisa de reengenharia em software legado relevante, pois muitas empresas ainda mantm o software legado e a manuteno 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 negcios, melhora a estrutura do sistema, cria uma nova documentao relacionada e faz com que ela seja de mais fcil compreenso. 1 SOFTWARE LEGADO Um software um artefato evolutivo e, com o passar do tempo, seu projeto e implementao originais so modificados para atender a novos requisitos e/ou melhorar o seu desempenho. Fatores internos e externos, como o estado da economia, as modificaes nos mercados, as alteraes nas leis, as mudanas de gesto e organizao estrutural, contribuem para que as empresas sofram mudanas contnuas (SOMMERVILLE, 2003). Essas mudanas geram requisitos de software novos ou modificados; assim, todos os softwares teis inevitavelmente so modificados quando as empresas passam por mudanas. Portanto, esses sistemas incorporam um grande nmero de alteraes que foram feitas durante muitos anos, alm de incorporarem importantes regras de negcio no seu contexto, so 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 perodo e desenvolvidos com tecnologia ultrapassada (SOMMERVILLE, 2003). Existem muitas empresas que esto repletas de software legado em uso, principalmente as empresas cujos processos so os mesmos por anos. Normalmente as empresas gastam muito dinheiro na implantao do sistema e

esperam no ter o mesmo gasto novamente. Muitos desses antigos sistemas ainda so fundamentais para as empresas, isto , as empresas dependem dos servios fornecidos pelo software, e qualquer falha desses servios teria um srio efeito em seu dia a dia. Normalmente so aplicaes complexas, de difcil manuteno e que pelo grau de criticidade e custo para modernizao, continuam ativas (BRAGA, 2004). A preocupao com os legados est na baixa qualidade do mesmo. Muitas vezes no existem documentaes e se existem so pobres de detalhes, os casos de testes so fracos e no h um controle de mudanas. Muitas vezes o engenheiro de software no mexe no software legado quando o mesmo atende as necessidades do cliente (BROOKS, 1995). Algumas das principais caractersticas na identificao de um software legado so: sistemas em produo h mais de cinco anos; hardware e software obsoletos; sistemas com mais de 10 mil linhas de cdigos; interface com o usurio baseada em caractere; cdigo-fonte amplamente modificado por diversas equipes ao longo dos anos, com alteraes no documentadas; documentao antiga e desatualizada, no condizentes com as funcionalidades e processos atuais do sistema; utilizao de um sistema de arquivos ou gerenciador de banco de dados obsoletos; sistema no conhecido em sua totalidade pelos profissionais responsveis por sua manuteno; usurios do sistema incapazes de explicar com detalhes suas funes junto ao sistema e todos os processos que o mesmo executa; regras de negcio inseridas apenas no cdigo-fonte do sistema (BRAGA, 2004). 1.1 AVALIAO DO LEGADO Segundo Warren ao avaliar um sistema legado, deve consider-lo sob duas perspectivas diferentes. A primeira seria sob a perspectiva de negcios (valor do sistema para a empresa) e a segunda seria uma perspectiva de sistema (avaliao da qualidade do software de aplicao e do software e hardware de apoio do sistema). A juno dessas duas perspectivas decisiva na hora de decidir o que fazer com o sistema legado (WARREN, 1998). A qualidade e o valor de negcios de cada um desses sistemas so avaliados e comparados com outros sistemas, mediante um grfico, que mostra o valor de negcios relativo e a qualidade do sistema. Na figura (1), possvel verificar que

existem quatro grupos de sistemas e que se subdividem em: baixa qualidade, baixo valor de negcios; baixa qualidade, alto valor de negcios; alta qualidade, baixo valor de negcios e alta qualidade, alto valor de negcios (SOMMERVILLE, 2003).

Figura 1 Qualidade de sistema e valor de negcio Fonte: SOMMERVILLE, 2003.

Baixa qualidade, baixo valor de negcios: significa que manter esses sistemas em operao ser dispendioso e a taxa de retorno de investimento para os negcios ser pequena. Esses sistemas so candidatos a serem descartados (BRAGA, 2004). Baixa qualidade, alto valor de negcios: significa que esses sistemas esto prestando uma importante contribuio empresa, assim, no podem ser descartados. Porm, sua baixa qualidade significa que os custos operacionais so altos, de modo que so candidatos transformao ou substituio do sistema (BRAGA, 2004). Alta qualidade, baixo valor de negcios: significa que so sistemas que no contribuem muito para os negcios, mas cuja manuteno pode no ser dispendiosa. No vale o risco substituir esses sistemas, de modo que a manuteno normal pode ser continuada ou eles podem ser descartados (WARREN, 1998). Alta qualidade, alto valor de negcios: significa que esses sistemas devem ser mantidos em operao, mas sua alta qualidade significa que no necessrio investir na sua transformao ou substituio. Deve-se continuar com a manuteno normal do sistema (WARREN, 1998).

1.2 PROBLEMAS COM O LEGADO Os sistemas legados constituem a parte mais importante do fluxo de informaes dentro das organizaes e so os principais veculos para a consolidao das informaes sobre o negcio. O conhecimento agregado nestes sistemas constitui um patrimnio corporativo significativo. Por tratar de sistemas crticos apresentam numerosos problemas para as empresas (BISBAL, 1999). A maioria dos sistemas legados passou por mudanas contnuas durante muitos anos de manuteno. De acordo com a segunda lei de evoluo de programas de Lehman (1985), quando um programa em evoluo continuamente modificado, sua estrutura se deteriora, consequentemente a complexidade aumenta. Esse aumento de complexidade ocorre porque h uma precipitao ao elaborar as correes dos problemas e no h tempo para manter o refinamento de um projeto ou a consistncia da abordagem em todo o cdigo (LEHMAN, 1985). A pressa em disponibilizar um produto pode levar mantenedores a implementar uma modificao rpida, ineficiente e sem ter sido adequadamente testada, em vez de utilizar o tempo necessrio para seguir as boas prticas de engenharia de software. O resultado um produto com vrios "remendos" e difcil de ser entendido e mantido (LEHMAN, 1985). Atualmente as organizaes esto enfrentando uma grande presso para modernizar seus sistemas, a fim de que possam responder melhor s necessidades de mercado e de pessoas e s rpidas mudanas de tecnologia (LEHMAN, 1985). 2 REENGENHARIA DE SOFTWARE O software o conjunto de vrios artefatos e no apenas o cdigo fonte. O software no um produto acabado, est sempre em mutao, condio esta originria de mudanas nas regras de negcio, necessidade de melhoria do processo produtivo ou da adequao do produto ou servio (ZANLORENCI, 2009). Muitas organizaes tm enfrentado problemas com o uso e a manuteno de software construdo para ser executado em uma variedade de tipo de hardware e programado em linguagem obsoletas. A tarefa de realizar a manuteno torna-se mais complexa e mais cara e, ainda, esses sistemas tornam-se cada vez mais desorganizados devido s inmeras tentativas de adaptaes e incluses de novas

funcionalidades. Sendo assim, as organizaes tm trs 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 mudana de linguagem (SOMMERVILLE, 2003).
Quando o sistema no fcil de ser mantido sendo, porm, de grande utilidade, ele deve ser reconstrudo. Partindo-se do sistema existente (via cdigo-fonte, interface ou ambiente), so abstradas as suas funcionalidades e so construdos o modelo de anlise e o projeto do software. Esse processo denominado reengenharia de software (PIEKARSKI, 2000).

O termo reengenharia pode referir-se tanto reengenharia do processo de negcios 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 tambm chamada renovao ou recuperao de software definida como a recuperao rigorosa do conhecimento embutido em sistemas existentes a fim de alavancar os esforos em seu aprimoramento, procurando melhorar sua qualidade global e reduzir custos com manuteno, isto , reestruturar ou reescrever todo ou parte de um sistema legado sem alterar suas funcionalidades (SILVA, 2005). Um processo de reengenharia geralmente inclui traduo do cdigo-fonte, melhoria na estrutura do programa, modularizao, alguma forma de engenharia reversa seguida por uma forma de engenharia progressiva ou reestruturao e reengenharia de dados (SILVA, 2005). importante ressaltar que existe clara distino entre o desenvolvimento de um novo software e reengenharia, a distino est relacionada ao ponto de partida de cada um dos processos. O desenvolvimento de um novo software (engenharia progressiva) inicia-se com uma especificao escrita do software que ser construdo, 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 especificao de um sistema, partindo-se de seu cdigo fonte. O objetivo da reengenharia produzir um sistema novo com maior facilidade de manuteno. A engenharia reversa usada como parte do processo de reengenharia, pois fornece o entendimento do sistema a ser reconstrudo (SOMMERVILLE, 2003).

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

2.1 RELACIONAMENTOS NO CICLO DE DESENVOLVIMENTO Para uma melhor compreenso das tcnicas de manuteno de software, preciso considerar trs conceitos dependentes: a existncia de um processo de desenvolvimento de software, a presena de um sistema a ser analisado e a identificao de nveis de abstrao (OSBORNE e CHIKOFSKY, 1990). Independente do que seja o processo de desenvolvimento de software, esperase que haja interao entre seus estgios e, qui, recurso. No processo de desenvolvimento, os estgios iniciais envolvem conceitos independentes de implementao, enquanto os estgios finais enfatizam os detalhes de implementao (OSBORNE e CHIKOFSKY, 1990).
O aumento de detalhes durante o processo de desenvolvimento conceitua os nveis de abstrao. Estgios iniciais do sistema planejam e definem requisitos de alto nvel quando comparados com a prpria implementao (PIEKARSKI, 2000).

Esta comparao deixa claro que nvel de abstrao e grau de abstrao so grandezas distintas. Enquanto o nvel de abstrao um conceito que diferencia os estgios conceituais do projeto, o grau de abstrao intrnseco a cada estgio (PIEKARSKI, 2000). Para que as tcnicas de manuteno de software (especificamente engenharia reversa e reengenharia) sejam descritas de forma simplificada, sero tomadas como base trs fases do processo de desenvolvimento de software, com nveis de abstrao diferenciados, conforme figura 3 (OSBORNE e CHIKOFSKY, 1990): Requisitos: especificao do problema a ser resolvido, incluindo objetivos, restries e regras de negociao; Projeto: especificao da soluo;

 Implementao: codificao, teste e adaptao 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 instituda. O problema comum, afetando todos os tipos de organizao, pois uma falha na reengenharia pode dificultar os esforos da organizao para manter-se competitiva (BORGES, 2007). A capacitao em desenvolvimento de software pressupe a existncia de um processo de software definido no qual aplicado um modelo de melhoria de processos. O processo definido tem documentao 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 mtricas para verificao do controle e da eficcia (BORGES, 2007). Assim, a capacitao em desenvolvimento de software reflete o grau de institucionalizao de uma infraestrutura e cultura relacionada aos mtodos, prticas e procedimentos do desenvolvimento de software. Reflete, tambm, 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 sada uma verso estruturada e modularizada do mesmo programa. Ao mesmo tempo em que ocorre a reengenharia do programa, os dados do sistema tambm 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 compreensvel. Em princpio, a reengenharia de dados no dever ser necessria, se a funcionalidade do sistema permanecer inalterada. Na prtica, h uma srie de razes pelas quais preciso modificar os dados, como tambm os programas, em um sistema legado (SOMMERVILLE, 2003).

Efetuar o processo de reengenharia em uma aplicao implica em examinar e alterar um sistema com o propsito de reconstitu-lo em um novo modelo e uma implementao 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 bibliogrfica, que remete a uma srie 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 participaes. Atravs da entrevista perceptvel a concepo de vrios tpicos citados no referencial bibliogrfico.

3.1 ENTREVISTA COM GERENTE DE TI Em entrevista com Keiji Sakai, bacharel em cincia da computao, MBA e certificado em diversas reas de gerncia, que ocupa h dois anos e meio o cargo de diretor de TI da BM&FBOVESPA, e que j passou por diversas instituies financeiras, entre elas: ESM Consultoria e Projetos em TI LTDA; JPMorgan Chase; HSBC Bank Brasil; Deutsche Bank S/A - Banco Alemo; UNIBANCO; Banco Matrix S/A; Banco de Investimentos Garantia e Banco Norchem, exprime de forma sucinta suas diversas experincias 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 considerao adaptao dos usurios, melhorias, custos, vantagens e desvantagens. SAKAI: Sim, em diversas instituies financeiras. Em primeiro lugar, importante explicar o que considero reengenharia de software na minha viso, reengenharia de software reconstruir uma aplicao ou parte dela, corrigindo defeitos existentes ou saneando cdigos antigos, ou ainda renovando componentes para a plena utilizao dos melhores recursos de software e hardware existentes. Neste sentido, em reengenharias de software onde no ocorreram grandes mudanas de interao aos usurios, mas trouxeram claramente vantagens, seja na correo ou na melhoria de performance, a recepo dos mesmos foi sempre muito positiva. Naquelas onde a interao dos usurios com a aplicao teve alterao, principalmente devido a grandes rupturas tecnolgicas (mainframe para micro informtica, plataforma DOS para Windows, desktops para tablets), as primeiras movimentao provocaram resistncia dos usurios principalmente devido mudana da rotina operacional dos mesmos. Com relao a custos, vantagens e desvantagens, existe uma falsa percepo que a reengenharia seria mais barata do que um novo desenvolvimento em algumas situaes isto no foi verdade, pois o nvel de integrao dos legados aliado a complexidade de novas tecnologias encareceu alguns dos projetos. de reengenharia de software. Em algumas situaes, o custo de uma manuteno corretiva do sistema legado seria muito mais vantajoso que uma ao

O que levou/leva a empresa a passar pelo processo de reengenharia no software? SAKAI: Alguns dos grandes motivadores: estratgia de downsizing da instituio, custo de manuteno de legados, nvel de instabilidade de legados em decorrncia de manutenes e customizaes complementares e por fim, estratgia de negcios para lanamento de novas interaes entre as aplicaes das instituies e os clientes finais. Quais so os principais aspectos que um gestor de TI precisa avaliar se tratando do software? SAKAI: A criticidade da aplicao que precisa ser reescrita precisa ser avaliada numa instituio financeira onde algumas aplicaes precisam funcionar em regime 24 x 07, o risco de instabilidade pode provocar perdas milionrias e fuga de clientes. Alm disto, em ambientes extremamente regulados a consistncia das informaes (incluindo eventuais clculos) so de extrema criticidade. Neste sentido, planos para garantir a qualidade do sistema devem ser colocados em prtica, como por exemplo, testes regressivos, certificaes com o mercado, produo paralela e simulaes dos requisitos no funcionais devem estar no radar do gestor de TI. Quais so os principais motivos que levam ao abandono do software legado? SAKAI: Obsolescncia aliada a instabilidade e ao alto custo de manuteno. No caso da obsolescncia, o risco operacional em decorrncia de descontinuidade de software, hardware e tecnologia pode obrigar as instituies a partir para uma estratgia de reengenharia. No processo de reengenharia o risco de perder funcionalidades do software legado ainda existe, quais so as medidas para tal acontecimento? SAKAI: Para evitar este tipo de situao, o mapeamento das funcionalidades fundamental. Na inexistncia de documentao 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 instituio utilizvamos metodologias e modelos diferentes. documentaes no necessrias. 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 no esto mais aptos a atender as necessidades. Por exemplo, volume transacional, performance, tecnologia, alteraes regulatrias e estratgias de negcio. O processo de reengenharia de software pode ser a soluo 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 solues domsticas foi amplamente aplicado. Com o fim da reserva de mercado e a vinda de vrios provedores com solues globais, a dependncia de legados internos diminui. Por exemplo, para uma empresa que na dcada de 80 decidiu desenvolver um sistema de BackOffice para controlar todo o seu processo produtivo, eu no partiria para a reengenharia da soluo e sim, buscaria um ERP de mercado. Para solues especficas que no so atendidas pelo mercado e que so criticas para as organizaes, a reengenharia a soluo. Qual o papel do gerente de TI, na gesto e qualidade do software? SAKAI: Em algumas organizaes, a qualidade do software de responsabilidade do gestor de TI junto com um gestor de Qualidade. Mas com relao aos aspectos tcnicos com os requisitos no funcionais, de arquitetura, segurana da informao e tecnologia adotada, a responsabilidade principalmente do gestor de TI. Qual a viso ps-reengenharia? O importante tanto na definio dos artefatos como na metodologia a de no burocratizar o processo, com controles e

SAKAI: Tive boas e ms experincias mas no em decorrncia da reengenharia em si. Os maus resultados foram em decorrncia de falhas, seja na especificao dos requisitos funcionais, seja na construo das solues. Consideraes finais (nesta parte fica livre do entrevistado, ressaltar algum ponto que no foi citado, contar experincia de vida profissional, dicas, ou seja, tudo que venha acrescentar ao trabalho). SAKAI: Um projeto de reengenharia de software no facilmente aprovado. O argumento de necessidade para melhoria de ambientes ou mitigao de riscos operacionais sem a quantificao dos benefcios financeiros no so fortes o suficiente para que um CIO tome a deciso de aprovar um projeto. Mesmo os CIOs que patrocinam projetos de reengenharia por conta prpria, assumem riscos que, caso os projetos no sejam extremamente bem sucedidos, colocam sua credibilidade na instituio em risco. reengenharia de software nos dias atuais. 3.2 ANLISE E DISCUSSO DOS RESULTADOS Mediante entrevista, possvel perceber que h casos em que a nica opo a reengenharia, pois a descontinuidade do software e limitaes do hardware faz com que o processo organizacional tambm no evolua. Contudo, a reengenharia deve ser aplicada apenas para sistemas crticos que no podem ser substitudos por solues de mercado. Sobre os custos interessante a forma como colocado, uma vez que os custos, s sero altos ou baixos dependendo da situao a qual o software se encontra, porm bom lembrar que um software que passa por reengenharia, tem sua performance e funcionalidades melhoradas, com isso, pedidos de manuteno, sero cada vez menores, e o gasto com o mesmo diminuir. Outro ponto interessante, foi a forma como o software inserido na organizao, sendo instrumento de negcio e de lucro, porm o mau funcionamento do mesmo ir acarretar problemas em toda a hierarquia da organizao. A partir do momento em que o software legado no atende mais as necessidades hora de agir, seja passar por um processo de reengenharia ou buscar algo novo no mercado. Considerando a comoditizao cada vez maior de software, em minha opinio so poucas as reais necessidades de

 visvel o quanto difcil e complexo implantar e ter o projeto de reengenharia aceito, uma vez que ainda existe insegurana 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, porm elas no so os nicos fatores determinantes, uma boa gesto crucial. CONCLUSO Mediante estudo, conclui-se que realizar a reengenharia em software legado, depende de muitos fatores, tanto gerenciais quanto a preocupao de se fazer algo com qualidade. A importncia da reengenharia est em possibilitar que todo conhecimento agregado (funes e procedimentos especficos de carter particular e nico) ao software legado no seja perdido. Porm se existir um software no mercado que supra as funes do legado, a melhor opo seria sim, implantar este software. Finalizando, conclusivo que o software quando chega ao seu estado crtico, precisa de medidas para que o mesmo continue em uso, o papel de um gestor de TI buscar pela melhor soluo. REFERNCIAS BISBAL, Jesus. Uma viso geral da migrao do sistema legado, 1999. BORGES, Rosemary. Sistemas legados, 2007. BRAGA, Jose Luiz; PINTO, Hebert Laroca Mendes. Sistemas legados e novas tecnologias: tcnicas de integrao e estudo de caso, 2004. BROOKS, F. P. Ensaios sobre Engenharia de Software. 1. ed. MA: AddisonWesley, 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. Manuteno de software, 1990.

PIEKARSKI, Ana; Reengenharia de software: o que, por que e como. Disponvel em: <revistas.unicentro.br/index.php/RECEN/article/download/528/697>. Acesso em: 19 Mai. 2013. SILVA, Roberto Andrade de. Migrao e Integrao de Sistemas Legados, 2005. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. So Paulo: Addison-Wesley, 2003. WARREN, Ian. Um mtodo para avaliar Sistemas Legados para a Evoluo, 1998. ZANLORENCI, Edna; Abordagem da Engenharia de Requisitos para Software Legado. Disponvel em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>. Acesso em: 27 Ago. 2013.