CENTRO UNIVERSITÁRIO DO ESPÍRITO SANTO – UNESC

LUCIANA PONCHE DIAS

REENGENHARIA EM SOFTWARE LEGADO

COLATINA

2012

LUCIANA PONCHE DIAS

REENGENHARIA EM SOFTWARE LEGADO

Trabalho de Conclusão de Curso apresentado ao Centro Universitário do Espírito Santo – UNESC, sob orientação da Professora Priscila de Almeida Prata, como requisito para a obtenção do Título de Bacharel em Sistema de Informação.

COLATINA

2012

SUMÁRIO

INTRODUÇÃO .................................................................................................... 04

1 PROBLEMA DE PESQUISA E HIPÓTESES .................................................. 05

2 JUSTIFICATIVA ............................................................................................... 06

3 OBJETIVOS ..................................................................................................... 07

3.1 OBJETIVO GERAL ........................................................................................ 07

3.2 OBJETIVOS ESPECÍFICOS .......................................................................... 07

4 REFERENCIAL TEÓRICO ................................................................................ 08

5 PROCEDIMENTOS METODOLÓGICOS ......................................................... 14

6 CRONOGRAMA 777...................................................................................... 15

REFERÊNCIAS .................................................................................................... 16

ANEXO A – INSTRUMENTO DE COLETA DE DADOS 77777777........ 17

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 de evolução de software. Ocupa-se

de reimplementar sistemas legados, para que sua manutenção seja fácil.

O grande dilema de implantar a reengenharia em software legado é que eles

têm embutidas 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 redescobertas por tentativa e erro.

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, mas é dispendioso manter.

A reengenharia melhora a estrutura do sistema, cria uma nova documentação

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

Será realizada uma pesquisa bibliográfica baseada em publicações recentes

disponíveis em livros, revistas, etc. Também será realizada uma pesquisa de campo

qualitativa através de entrevista com um gerente de TI explanando as mudanças

após a implementação da reengenharia em software legado.

Dar inicio à pesquisa de reengenharia em software legado é relevante, pois

atualmente muitas empresas ainda mantêm software legado. Colocar em pratica a

reengenharia em um sistema implica examinar e alterar um sistema de software de

forma a reconstituir e reimplementa-lo sob um novo formato.

1 PROBLEMA DE PESQUISA E HIPÓTESES

Porque efetuar a reengenharia em software legado implica tantas barreiras

dentro da empresa e qual a importância da mesma?

• Porque existe o medo tanto do usuário do sistema quanto do gerente de TI

de que com a reengenharia o software não faça as mesmas funções do

antigo.

• Porque os gerentes de TI não têm as competências gerenciais necessárias

para avaliar o custo de manutenção do legado nem para conduzirem um

processo de migração. Empresas com o problema do legado devem

capacitar seus gerentes em reengenharia de software.

• Porque não há conhecimento das novas tecnologias. Estudar sobre novas

linguagens, novos servidores de aplicação e novas arquiteturas é vital para

tomar uma atitude de acabar com o legado. Investir em treinamento do seu

corpo técnico também é importante.

2 JUSTIFICATIVA

Pesquisar sobre reengenharia em software legado é relevante, pois hoje

existem muitas empresas que ainda mantém software legado. Colocar em pratica a

reengenharia em um sistema implica examinar e alterar um sistema de software de

forma a reconstituir e reimplementa-lo sob um novo formato. Significa aprimorar a

documentação, projetar e reestruturar um sistema existente de forma a obter uma

forma mais aceitável do mesmo.

Na área computacional, é de grande importância que o profissional de TI saiba

fazer da reengenharia uma aliada dentro da empresa. Com ela haverá aumento na

manutenibilidade de software, identificação dos candidatos ao reuso, valorização do

sistema que sofre o processo de reengenharia e aprimoramento da gestão de riscos

do projeto.

Reengenharia de software ainda apresenta grandes dificuldades de

implantação, porém o uso dela em software legado trás grandes benefícios para a

empresa, gerentes de TI e para os que manuseiam o software. Um sistema que

tenha sofrido o processo de reengenharia fornece os recursos solicitados pelos

participantes no projeto, ao mesmo tempo em que conserva uma pequena parte da

construção conceitual do sistema legado.

3 OBJETIVO

3.1 OBJETIVO GERAL

Apresentar a importância e eficácia da reengenharia em software legado.

3.2 OBJETIVO ESPECÍFICO

• Conceituar software legado;

• Conceituar reengenharia de software;

• Exemplificar todos os processos;

• Comparar custos, vantagens e desvantagens;

• Distinguir o que é problema e o que é solução;

• Deixar explicito os conceitos e usabilidades.

4 REFERENCIAL TEÓRICO

Ao passar do tempo, não se imaginava que o software se tornaria um elemento

importante para o mundo e teria a capacidade de manipular a informação. Com este

crescimento computacional, dá inicio a criação de sistemas perfeitos e problemas

para quem desenvolve softwares complexos (SOMMERVILLE, 2003).

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 das organizações, da necessidade de

melhoria do processo produtivo ou da adequação do produto ou do serviço que

utiliza tecnologia da informação e está disponibilizado para uso (ZANLORENCI,

2009).

A partir do momento em que um software começa a ser utilizado, ele entra em

um estado contínuo de mudança. Mesmo que tenha sido construído aplicando as

melhores técnicas de projeto e codificação existentes, os sistemas vão se tornando

obsoletos em vista das novas tecnologias que são disponibilizadas. Além das

correções de erros, as mudanças mais comuns que os sistemas sofrem são

migrações para novas plataformas, ajustes para mudanças de tecnologia de

hardware ou sistema operacional e extensões em sua funcionalidade para atender

os usuários. Essas mudanças são realizadas sem que haja preocupação com a

arquitetura geral do sistema, produzindo estruturas mal projetadas, documentação

desatualizada, lógica e codificações ruins, sendo esses os dificultadores da

manutenção em um sistema (OSBORNE e CHIKOFSKY, 1990).

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, 2012).

Reengenharia de software, também chamada renovação ou recuperação de

software, não apenas recupera informações do projeto de um sistema existente,

como também usa estas informações para reconstruir o sistema, procurando

melhorar sua qualidade global e reduzir custos com manutenção (PRADO, 2012).

A reengenharia tem como principal objetivo melhorar um sistema de alguma

maneira, através de alterações significantes que proporcionem melhoria, porém,

sem alterar suas funções. A extração automática da descrição de uma aplicação e

sua implementação em outra linguagem não é considerada, e sim tradução de

código. O processo de reengenharia inclui tradução de código-fonte, engenharia

reversa, melhoria de estrutura de programa, modularização de programa e

reengenharia de dados (NOGUEIRA, 2000).

Existem diferentes tipos de reengenharia: com a troca parcial ou completa da

implementação sem a troca da funcionalidade, em que há mudança do paradigma

de desenvolvimento e/ou da linguagem de implementação, preservando o

funcionamento do sistema; e com troca da funcionalidade, em que se aplica o

processo tradicional de desenvolvimento de software, modificando o funcionamento

do sistema no modelo de análise e implementando-o novamente (PIEKARSKI,

2012).

A reengenharia pode ser dividida em duas fases principais: a engenharia

reversa e a engenharia progressiva, cada uma destas fases pode ser dividida em

uma série de atividades. Percebe-se que existe clara distinção entre o

desenvolvimento de um novo software e reengenharia de software. A distinção está

relacionada ao ponto de partida de cada um dos processos. O desenvolvimento de

um novo software (definido como 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. Nota-se, que existe

distinção entre os objetivos da reengenharia e os da engenharia reversa. 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).

Para melhorias relacionadas à reengenharia, podem-se estabelecer três

categorias, que são: reengenharia de processos administrativos (direcionada para

alterações potenciais em todos os negócios ou processos organizacionais);

reengenharia de processos produtivos (consiste em modificar qualquer ciclo de

processos padrão, que esteja em uso em uma dada organização, afim de melhora);

reengenharia de software ou produtos (captura e modificação de mecanismos

internos ou funcionalidade de um sistema existente ou produto, visando reconstituí-

lo em uma nova forma e com novas características, frequentemente para tomar

vantagem das novas e emergentes tecnologias, mas sem grandes alterações na

funcionalidade e propósito inerentes ao sistema (SOMMERVILLE, 2003).

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 (ZANLORENCI, 2009).

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).

A reengenharia ocupa-se de reimplementar sistemas legados, para que sua

manutenção seja fácil. Software legado pode ser definido como aquele que executa

tarefas úteis para a organização, mas que foi desenvolvido utilizando-se técnicas

atualmente consideradas obsoletas. Logo, nem todo software antigo é legado. A

palavra legado, neste caso, traz um sentido pejorativo, similar ao adjetivo obsoleto.

Em outras palavras, software legado é um software antigo que, apesar de ainda ser

utilizado, foi desenvolvido sem preocupação com as boas práticas de

desenvolvimento vigentes e, às vezes, utilizando uma plataforma já descontinuada

(WARD e BENNETT, 1995).

Os três grandes problemas do software legado são: Primeiramente a sua

incompatibilidade com plataformas operacionais mais recentes, mesmo que exista a

virtualização a demanda de tempo é maior para executar uma dada tarefa. O

segundo problema é o no seu desenvolvimento uma vez que o legado na maioria

das vezes não possui documentação, sua arquitetura não é modularizada e

linguagem de programação ultrapassada. O terceiro problema está na usabilidade

do software, em geral o legado foi desenvolvido em uma plataforma que impede ou

inviabiliza a utilização de interfaces mais evoluídas (DINIZ, 2012).

Existe um grande dilema na decisão sobre o futuro de software legado. Ao mesmo tempo em que ele traz incorporado o acúmulo de anos de experiência e refinamento, traz também todos os vícios e defeitos vigentes na época de seu desenvolvimento (BENNETT, 1995).

Há um risco significativo de negócio em simplesmente descartar sistemas

legados e substituí-los por um sistema que foi desenvolvido utilizando uma

tecnologia moderna, pois raramente existe uma especificação completa do sistema

legado. Se existir uma especificação, é pouco provável que ela incorpore todas as

mudanças que foram feitas no sistema. Os processos corporativos e o modo como

os sistemas legados operam estão sempre intrinsecamente entrelaçados.

Importantes regras corporativas podem estar inseridas no software e podem não

estar documentadas em nenhum outro lugar. O desenvolvimento de um software

novo é arriscado, uma vez que podem ocorrer problemas inesperados com um novo

sistema (SOMMERVILLE, 2003).

O sistema deve mudar para permanecer útil, no entanto, alterar um sistema

legado é muitas vezes dispendioso. Pois, diferentes partes do sistema foram

implementadas por diferentes equipes, portanto, não há um estilo de programação

consistente. O sistema pode utilizar uma linguagem de programação obsoleta.

Frequentemente, a documentação do sistema é inadequada e desatualizada. Em

geral, muitos anos de manutenção podem ter corrompido a estrutura do sistema. O

sistema pode ter sido otimizado para melhorar a utilização de espaço ou a

velocidade de execução, em vez de ter sido escrito para facilitar a compreensão. Os

dados processados pelo sistema podem estar armazenados em diferentes arquivos,

que podem ter estruturas incompatíveis (SOMMERVILLE, 2003).

Muitos programas legados são críticos para os negócios das organizações que

os possuem. Eles têm embutidas 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 muita informação teria que ser redescoberta por tentativa e erro.

Consequentemente, as organizações, não ”aposentam” seus sistemas legados,

preferindo mantê-los em operação, com adaptações às novas necessidades.

(LEHMAN, 1980).

Praticamente todos os sistemas legados utilizados foram projetados antes do

desenvolvimento orientado a objetos ser utilizado. Em vez de serem organizados

com um conjunto de objetos interativos, esses sistemas são projetados utilizando

uma estratégia de projeto orientado a funções. Centenas de programas de

aplicações foram desenvolvidos utilizando-se esses métodos e as ferramentas

CASE associadas (SOMMERVILLE, 2003).

Como a reconstrução manual de sistemas legados é um processo lento e

trabalhoso, pesquisas estão sendo direcionadas para a utilização de tecnologias de

sistemas transformacionais na área de reengenharia de software. Um sistema

transformacional que vem sendo utilizado nesta área é o Draco-PUC. O Draco-PUC

implementa as ideias de transformação orientada a domínios (PRADO, 2012).

Outra técnica usada na estratégia de reengenharia é a abordagem Fusion/RE

que faz a recuperação do projeto atual do sistema legado. A abordagem Fusion/RE

apresenta técnicas para recuperar sistemas legados utilizando o paradigma da

orientação a objetos, sem que os mesmos tenham sidos desenvolvidos com essa

tecnologia. Esta abordagem tem como objetivo recuperar informações e gerar os

mesmos modelos propostos para facilitar a compreensão do sistema que está sendo

analisado. Após a geração dos modelos, estes são utilizados para orientar o

engenheiro de software no processo de organização do código, dando a ele

características de orientação a objetos. O processo de organização de código é

denominado segmentação e o seu resultado, o sistema já organizado, é denominado

sistema segmentado (PRADO, 2012).

A tendência de reengenharia dos processos das empresas são influenciados

por fatores tais como a necessidade de melhoria da qualidade dos serviços e

produtos oferecidos, a compressão das margens de lucro, a redução do ciclo de vida

dos produtos, a diminuição da interferência dos governos e dos subsídios, a

explosão tecnológica, o rápido crescimento do conhecimento humano, a maturidade

dos mercados de consumo e a globalização da economia (NOGUEIRA, 2000).

A complexidade e tamanho dos programas legados têm influência direta no

custo de manutenção dos mesmos. Pesquisas revelam que mais de 50% do custo

de um produto de software está relacionado com as atividades de manutenção,

havendo casos de este percentual chegar até a 85% (YOURDON, 1990).

Em alguns negócios, estima-se que 80% de todos os gastos com software são

consumidos pelas manutenções e evoluções dos sistemas. O número de sistemas

que precisa ser modificado está aumentando gradualmente. Existe fila de espera

para pedidos de manutenção. Isto significa que, algumas vezes, é impossível para

as organizações investirem em novos sistemas para melhorar a eficiência

organizacional (YOURDON, 1990).

A estrutura de controle dos sistemas legados é complexa, com muitas

ramificações incondicionais e a lógica de controle não é intuitiva. Essa estrutura

pode ser afetada por manutenções regulares, tornando alguns códigos inatingíveis.

O programa pode ser reestruturado automaticamente para eliminar declarações

incondicionais. Condições complexas podem ser simplificadas, como parte do

processo de reestruturação de programa (NOGUEIRA, 2000).

A questão é que se continuarem utilizando os sistemas legados e fazendo

alterações, seus custos aumentarão. Se decidirem substituir seus sistemas legados

por novos sistemas, isso será dispendioso. Muitas empresas estão examinando

técnicas de engenharia de software que ampliem o tempo de duração dos sistemas

legados e que reduzam os custos de manter esses sistemas em uso, como a

evolução de produtos de software e a reengenharia de software (SOMMERVILLE,

2003).

5 PROCEDIMENTOS METODOLÓGICOS

Será realizada uma pesquisa bibliográfica baseada em publicações recentes

disponíveis em livros, revistas e em sites confiáveis, buscando informações que

darão sustentação ao trabalho.

Também será realizada uma pesquisa de campo qualitativa através de

entrevista com um gerente de TI explicitando as mudanças drásticas na empresa

depois de executado a reengenharia em software legado. A entrevista servirá como

ponto crucial do trabalho, uma vez que estará mostrando que é possível fazer a

reengenharia em um sistema em uso, a melhoria da mesma tanto para os negócios

como para quem utiliza a ferramenta e os custos.

6 CRONOGRAMA

No quadro abaixo está representada a escala de tempo que será utilizada para

elaboração do projeto de pesquisa e de todas as fases que serão realizadas até a

entrega da Monografia.

2012 2013

FASES A S O N D J F M A M J J A S O

Escolha e delimitação do tema

Revisão da literatura para o projeto

Elaboração do projeto de pesquisa

Entrega do projeto de pesquisa

Estruturação da Monografia

Elaboração dos elementos textuais

Coleta e Análise de Dados

Discussão dos Resultados

Conclusão e Introdução

Resumo

Ajustes finais de Formatação

Entrega da Monograifa

REFERÊNCIAS

DINIZ, Samuel; O problema do software legado. Disponível em: <http://blogdosamueldiniz.blogspot.com.br/2010/02/o-problema-do-software-legado.html>. Acesso em: 19 Out. 2012. LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution, 1980, 1060-1076 p. NOGUEIRA, Marcelo; Reengenharia de Software. Disponível em: <http://www.noginfo.com.br/arquivos/CC_ESOF_II_10.pdf>. Acesso em: 23 Out. 2012. OSBORNE,W.M.; CHIKOFSKY, E.J. Fitting Pieces to the Maintenance Puzzle. IEEE Software, 1990, 11 p. 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 Out. 2012. PRADO, Antônio. Reengenharia de software para plataformas distribuídas orientadas a objeto. Disponível em: <http://www.inf.ufsc.br/sbes99/anais/SBES-Completo/26.pdf>. Acesso em: 25 Out. 2012. SOMMERVILLE, I. Engenharia de software. 6. ed., São Paulo: Addison Wesley, 2003, 592p. ZANLORENCI, Edna; Abordagem da Engenharia de Requisitos para Software Legado. Disponível em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>. Acesso em: 27 Out. 2012. WARD, M. P.; BENNETT, K. H. Formal Methods for Legacy Systems. Journal of Software Maintenance: Research and Practice, 1995, 203 – 219 p. YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Editora Campus, 1990.

ANEXO A – INSTRUMENTO DE COLETA DE DADOS

Questionário elaborado com a finalidade de captar uma visão mais ampla das

funcionalidades da reengenharia em software legado.

01 - O que levou a empresa executar a reengenharia no software?

02- Quais as principais preocupações imediatas?

03- Alguma funcionalidade do legado foi perdida? Discorra sobre o assunto.

04- O que mudou após a reengenharia?

05- Houve aversão de funcionários/usuários?

06- Em relação ao custo, diminuiu? Discorra sobre o assunto.

07- Que papel o gerente de TI tem nessas mudanças?

08- Em sua opinião, até onde o software legado pode ser utilizado?

09- Reengenharia é a melhor opção?

10- Considerações finais.