MONOGRAFIA: Reengenharia em Software Legado

82
CENTRO UNIVERSITÁRIO DO ESPÍRITO SANTO – UNESC LUCIANA PONCHE DIAS REENGENHARIA EM SOFTWARE LEGADO COLATINA 2013

Transcript of MONOGRAFIA: Reengenharia em Software Legado

Page 1: MONOGRAFIA: Reengenharia em Software Legado

CENTRO UNIVERSITÁRIO DO ESPÍRITO SANTO – UNESC

LUCIANA PONCHE DIAS

REENGENHARIA EM SOFTWARE LEGADO

COLATINA

2013

Page 2: MONOGRAFIA: Reengenharia em Software Legado

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, para obtenção do Título de Bacharel em Sistemas de Informação.

COLATINA

2013

Page 3: MONOGRAFIA: Reengenharia em Software Legado

LUCIANA PONCHE DIAS

REENGENHARIA EM SOFTWARE LEGADO

Trabalho de Conclusão de Curso apresentado ao Centro Universitário do Espírito Santo – UNESC, para obtenção do Título de Bacharel em Sistemas de Informação.

ORIENTADOR

Priscila de Almeida Prata, Professora do UNESC, Mestre em Engenharia urbana.

Nota

AVALIADOR

Professor do UNESC

Nota

Colatina, ______ de __________________ de 2013.

Page 4: MONOGRAFIA: Reengenharia em Software Legado

Dedico este trabalho a Deus por ter me concedido a graça de concluir mais uma etapa de minha caminhada com sucesso. A meus pais, por todo esforço, pelo carinho, amor e educação que muito contribuíram na minha formação. A minha irmã por sempre acreditar em meu potencial e não deixar desistir. A meus amigos e familiares que sempre estiveram ao meu lado para me apoiar.

Page 5: MONOGRAFIA: Reengenharia em Software Legado

Agradeço a minha orientadora, a professora Priscila de Almeida Prata, pela dedicação e doação de conhecimentos dispensados para a elaboração desse trabalho. Ao professor Geraldo Cezar Seidel Dalla Bernardina, pela motivação e entusiasmo. Ao gerente de TI Keiji Sakai, que aceitou ser entrevistado e que muito contribuiu para o “enriquecimento” do trabalho, apesar de todos os imprevistos ao longo da pesquisa.

Page 6: MONOGRAFIA: Reengenharia em Software Legado

Tente uma, duas, três vezes e se possível tente a quarta, a quinta e quantas vezes for necessário. Só não desista nas primeiras tentativas, a persistência é amiga da conquista. Se você quer chegar aonde a maioria não chega, faça o que a maioria não faz.

Bill Gates

Page 7: MONOGRAFIA: Reengenharia em Software Legado

RESUMO

Trata da proposta de aplicação da reengenharia em software legado, bem como as vantagens e desvantagens, tendo como critério os custos, funcionalidades e desempenho. 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, visando uma melhor qualidade do software. 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 da organização. Através da pesquisa qualitativa, foi feito uma entrevista com um gerente de TI, que já passou por diversos processos de reengenharia em software legado. Mediante pesquisa quantitativa, foi feito uma análise de um questionário distribuído para 500 gestores de TI referente à reengenharia em software legado. As mesmas foram de grande relevância para o trabalho, uma vez que todos os tópicos abordados na pesquisa bibliográfica serão “autenticados”. Conclui-se que atualmente a necessidade de aplicar a reengenharia é 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: reengenharia, legado, software, engenharia, manutenção.

Page 8: MONOGRAFIA: Reengenharia em Software Legado

LISTA DE FIGURAS

Figura 1 – Tripé da engenharia de software ......................................................... 17

Figura 2 – Modelo cascata .................................................................................... 22

Figura 3 – Modelo prototipação ............................................................................. 23

Figura 4 – Modelo espiral ...................................................................................... 24

Figura 5 – Modelo em camadas de um software legado ...................................... 29

Figura 6 – Níveis lógicos de sistemas computacionais ......................................... 30

Figura 7 – Qualidade de sistema e valor de negócio ............................................ 32

Figura 8 – Distinção entre o desenvolvimento de um novo software (1) e

reengenharia (2) ....................................................................................................

38

Figura 9 - Relacionamentos no ciclo de desenvolvimento de software ................ 40

Figura 10 – Processo de reengenharia ................................................................. 42

Figura 11 – Processo de engenharia reversa ....................................................... 45

Figura 12 – Visualizações de software no ciclo de desenvolvimento ................... 46

Figura 13 – Processo de reestruturação de programa .......................................... 48

Figura 14 – Custo da reengenharia ....................................................................... 55

Page 9: MONOGRAFIA: Reengenharia em Software Legado

LISTA DE QUADRO

Quadro 1 – Ferramentas de reengenharia ............................................................ 57

Page 10: MONOGRAFIA: Reengenharia em Software Legado

SUMÁRIO

INTRODUÇÃO ...................................................................................................... 12

1 SOFTWARE ....................................................................................................... 13

1.1 EVOLUÇÃO DO SOFTWARE ......................................................................... 13

1.2 CLASSIFICAÇÃO ............................................................................................ 15

1.3 CRISE DO SOFTWARE .................................................................................. 15

2 ENGENHARIA DE SOFTWARE ........................................................................ 17

2.1 PROCESSO/CICLO DE VIDA DO SOFTWARE ............................................. 18

2.2 MODELOS DE CICLO DE VIDA ..................................................................... 20

2.2.1 Ciclo de vida clássico (modelo cascata) ........................................... 21

2.2.2 Prototipação .............................................................................................. 22

2.2.3 Modelo espiral ............................................................................................ 24

3 SOFTWARE LEGADO ...................................................................................... 26

3.1 EVOLUÇÃO PARA O LEGADO ...................................................................... 27

3.2 ARQUITETURA ............................................................................................... 28

3.3 NÍVEL LÓGICO ............................................................................................... 30

3.4 AVALIAÇÃO .................................................................................................... 31

3.5 MANUTENÇÃO ............................................................................................... 33

3.6 PROBLEMAS COM O LEGADO ..................................................................... 35

4 REENGENHARIA DE SOFTWARE ................................................................... 37

4.1 RELACIONAMENTOS NO CICLO DE DESENVOLVIMENTO ....................... 39

4.2 PROCESSO DE REENGENHARIA DE SOFTWARE ..................................... 41

4.2.1 Tradução de código-fonte ......................................................................... 43

4.2.2 Engenharia reversa .................................................................................... 44

4.2.2.1 Visões de software .................................................................................... 46

4.2.3 Melhoria da estrutura do programa .......................................................... 47

4.2.4 Modularização de programa ...................................................................... 48

4.2.5 Reengenharia de dados ............................................................................. 49

4.3 VANTAGENS DA REENGENHARIA .............................................................. 50

4.4 DIFICULDADES NO PROCESSO DE REENGENHARIA .............................. 52

4.5 CUSTO ............................................................................................................ 54

Page 11: MONOGRAFIA: Reengenharia em Software Legado

4.6 FERRAMENTAS DE AUXÍLIO À REENGENHARIA ....................................... 56

4.7 ESTUDO DE CASO (EXEMPLIFICAÇÃO) ..................................................... 57

4.7.1 Sistema LEGADO_TEL .............................................................................. 58

4.7.2 O problema ................................................................................................. 59

4.7.3 Alternativas de soluções ........................................................................... 59

4.7.4 Problemas na substituição ........................................................................ 60

4.7.5 Solução alternativa .................................................................................... 62

4.7.6 Considerações finais ................................................................................. 63

5 METODOLOGIA ................................................................................................ 65

5.1 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 01 .......................... 65

5.2 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 02 .......................... 70

CONCLUSÃO ....................................................................................................... 75

REFERÊNCIAS ..................................................................................................... 76

ANEXO A – INSTRUMENTO DE COLETA DE DADOS ...................................... 79

Page 12: MONOGRAFIA: Reengenharia em Software Legado

12

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.

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.

Page 13: MONOGRAFIA: Reengenharia em Software Legado

13

1 SOFTWARE

Uma descrição de software num livro didático poderia assumir a seguinte

forma: "Software é: (1) instruções (programas de computador) que, quando

executadas, produzem a função e o desempenho desejados; (2) estruturas de dados

que possibilitam que os programas manipulem adequadamente a informação; e (3)

documentos que descrevem a operação e o uso dos programas" (PARREIRA,

2006).

Entende-se que “software” é uma sequência de instruções escritas para serem

interpretadas por um computador com o objetivo de executar tarefas específicas. Em

um computador, o software é classificado como a parte lógica cuja função é fornecer

instruções para o hardware. O termo inglês “soft” é o antônimo de “hard” e significa

“macio”, ou seja, o hardware é difícil de manipular e de alterar, enquanto o software

não (MONTEIRO, 2007).

1.1 EVOLUÇÃO DO SOFTWARE

Os softwares evoluem em resposta às exigências de mudanças como, por

exemplo, correção de erros, melhorias no desempenho, migrações para novas

plataformas ou outras características (PRESSMAN, 2006).

Com o surgimento dos primeiros softwares, não se imaginava que o mesmo se

tornaria um elemento importante para o mundo e que teria capacidade de manipular

a informação. Com a ascensão computacional e as mudanças vindas dele, veio a

vontade de criar sistemas cada vez mais perfeitos, livres de erros e com prazos e

datas estipuladas (PRESSMAN, 2006).

O contexto em que o software foi desenvolvido está estreitamente ligado a

quase cinco décadas de evolução dos sistemas computadorizados. O melhor

desempenho de hardware, o menor tamanho e o custo mais baixo, precipitaram o

aparecimento de sistemas baseados em computadores mais sofisticados. Nas

ultimas décadas o software evolui de uma ferramenta de análise de informações e

de resolução de problemas especializados para uma indústria da programação

(SOMMERVILLE, 1992).

Em meados da década de 40, o desenvolvimento do software era feito

virtualmente, sem administração até que os prazos começassem a se esgotar e os

Page 14: MONOGRAFIA: Reengenharia em Software Legado

14

custos a subir. Durante este período, era usada orientação batch (em lote) para a

maioria dos sistemas. Na maior parte, o hardware dedicava-se à execução de um

único programa que, por sua vez, dedicava-se a uma única aplicação específica. O

software era projetado sob medida para cada aplicação e tinha uma distribuição

relativamente limitada. Por causa desse ambiente de software personalizado o

projeto era um processo implícito realizado no cérebro de alguém e sem nenhuma

documentação (PRESSMAN, 1995).

Em meados de 1960 até o final de 1975 a multiprogramação e os sistemas

multiusuários introduziram novos conceitos de interação homem-máquina. As

técnicas interativas abriram um novo mundo de aplicações e novos níveis de

sofisticação de software e hardware. Sistemas de tempo real podiam analisar,

coletar e transformar dados de múltiplas fontes. Os avanços da armazenagem on-

line levaram à primeira geração de sistemas de gerenciamento de banco de dados

(PRESSMAN, 1995).

À medida que o número de sistemas crescia, era crescente o número de falhas

que constantemente precisava ser corrigidas por exigência dos usuários, essas

atividades foram chamadas de "manutenção de software". Esta constante

manutenção acarretou diversos problemas no desenvolvimento e avanços dos

softwares, pois ao mesmo tempo em que concertava um problema, surgia outro

(PRESSMAN, 1995).

Durante os anos de 1975 a 1985 as redes globais, as comunicações digitais de

largura de banda e a crescente demanda de acesso "instantâneo" a dados exigiram

muito dos desenvolvedores de software. Também foi caracterizada pelo advento e o

generalizado uso de microprocessadores, computadores pessoais e poderosas

estações de trabalho "Workstations" de mesa (PRESSMAN, 1995).

Atualmente as tecnologias orientadas a objetos estão ocupando o lugar das

abordagens mais convencionais para o desenvolvimento de software em muitas

áreas de aplicação. Os sistemas especialistas e o software de inteligência artificial

saíram do laboratório para a aplicação prática em problemas de amplo espectro do

mundo real. O software de rede neural artificial abriu excitantes possibilidades para o

reconhecimento de padrões e para capacidades de processamento de informações

semelhantes às humanas (PRESSMAN, 1995).

Page 15: MONOGRAFIA: Reengenharia em Software Legado

15

1.2 CLASSIFICAÇÃO

O software passa por constates classificações e cada autor o classifica de

formas diferentes, seguindo critérios pré-estabelecidos. Seguindo como princípio a

classificação de Verzello, o software se classifica em três tipos: Software de

Sistema, Software de Programação e Software de Aplicação (VERZELLO, 1984).

O Software de Sistema ou Sistema Operacional é o conjunto de informações

processadas pelo sistema interno de um computador que permite a interação entre

usuário e os periféricos do computador através de uma interface gráfica. Engloba o

sistema operativo e os controladores de dispositivos (VERZELLO, 1984).

O Software de Programação ou Software de Infraestrutura é o conjunto de

ferramentas que permitem ao programador desenvolver sistemas informáticos,

geralmente usando linguagens de programação e um ambiente visual de

desenvolvimento integrado. Os Bancos de Dados, Dicionários de Dados e Brokers

também são considerados Software de Infraestrutura, uma vez que permitem que se

escrevam sistemas inteiros utilizando o seu potencial (VERZELLO, 1984).

O Software de Aplicação são programas de computadores que permitem ao

usuário executar uma série de tarefas específicas em diversas áreas de atividade

como arquitetura, contabilidade, educação, medicina e outras áreas comerciais. São

ainda os videojogos, sistemas de celulares, os sistemas de automação industrial,

etc. (VERZELLO, 1984).

1.3 CRISE DO SOFTWARE

Em meados de 1970 o termo “crise do software” foi usado para expressar as

dificuldades do desenvolvimento de software frente ao rápido crescimento da

demanda por software, da complexidade dos problemas a serem resolvidos e da

inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que

funcionassem adequadamente ou pudessem ser validados (PRESSMAN, 2002).

A partir do momento em que o desenvolvimento de software começou a

caminhar com o advento das linguagens estruturadas e modulares, tornou-se claro

que a indústria de software estava falhando repetidamente na entrega de resultados

dentro dos prazos, quase sempre estourando os orçamentos e apresentando um

grau de qualidade duvidoso ou insatisfatório (DALMASO, 2013).

Page 16: MONOGRAFIA: Reengenharia em Software Legado

16

Um relatório em 1967 apresentou que, de 50% a 80% dos projetos não haviam

sido concluídos e outros fracassados por não terem atingindo os objetivos

esperados, e dos que foram concluídos, foram entregues acima do prazo estipulado

e o orçamento acima daquilo que foi predeterminado (DALMASO, 2013).

Mediante aos fatos, em 1968 aconteceu a “NATO Software Engineering

Conference”, um evento criado com o objetivo de discutir alternativas para contornar

a crise do software. Essa conferência marcou assim o início dessa nova área na

computação. Esta reunião teve como principal objetivo estabelecer práticas mais

maduras para o processo de desenvolvimento, por esta razão o encontro é

considerado hoje como o nascimento da disciplina de “Engenharia de Software”

(DALMASO, 2013).

Os problemas que originaram esta crise tinham relacionamento direto com a forma de trabalho das equipes. Eram problemas que não se limitavam a "sistemas que não funcionam corretamente", mas envolviam também dúvidas sobre como desenvolver e manter um volume crescente de software e ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do pouco entendimento dos requisitos por parte dos desenvolvedores, somados às técnicas e medidas pobres aplicadas sobre o processo e o produto, além dos poucos critérios de qualidade estabelecidos até então (PRESSMAN, 2002).

Todos esses fatores exigiram respostas e métodos que foram sendo

aprimorados e documentados, dando início à área de Engenharia de Software. A

busca por eficiência e competência revelou oportunidades, desafios e perigos que

guiaram as tecnologias e apontaram novos rumos para as pesquisas (DALMASO,

2013).

Embora ainda existam problemas durante o desenvolvimento e entrega do

software, os processos, métodos e ferramentas auxiliam muito em seu progresso,

uma vez aplicados por pessoas com conhecimentos adequados é evidente que

resultará em um bom projeto. Antigamente se produzia software de maneira muito

desordenada sem preocupação com o que realmente o software deveria fazer ou se

era possível executar “tal” tarefa, a engenharia de software surgiu da necessidade

de se construir software com mais qualidade em menor tempo (SANTOS, 2005).

Page 17: MONOGRAFIA: Reengenharia em Software Legado

17

2 ENGENHARIA DE SOFTWARE

Uma primeira definição de engenharia de software foi proposta por Fritz Bauer

na primeira grande conferencia dedicada ao assunto: "O estabelecimento e uso de

sólidos princípios de engenharia para que se possa obter economicamente um

software que funcione eficientemente com máquinas reais" (PARREIRA, 2006).

A engenharia de software é uma derivação da engenharia de sistemas e de

hardware. Ela abrange um conjunto de três elementos fundamentais - métodos,

ferramentas e procedimentos que possibilita ao gerente o controle do processo de

desenvolvimento do software e oferece ao profissional uma base para a construção

de software de alta qualidade produtivamente (PARREIRA, 2006).

A Engenharia de Software busca prover a tecnologia necessária para produzir um software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial, por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados (SANTOS, 2005).

Um grande problema no desenvolvimento de software é justamente o fato de

boa parte das organizações não encararem o desenvolvimento de software como um

projeto de verdade, assim, não aplicando procedimentos, métodos e ferramentas

necessárias. Por conta disso, boa parte dos projetos fracassa (SANTOS, 2005).

Figura 1 – Tripé da engenharia de software

Fonte: MARTINS, 2006.

A engenharia de software é baseada no tripé: processos, pessoas e tecnologia

(figura 1). Não adianta ter os melhores profissionais se não possuir boas tecnologias

para uso ou se não possuir um processo que guie o desenvolvimento de software.

Page 18: MONOGRAFIA: Reengenharia em Software Legado

18

Da mesma forma, não adianta possuir as tecnologias mais avançadas se as pessoas

não conseguem utilizá-las. Além disso, mesmo que pareça inconcebível para alguns,

de nada adianta ter a melhor tecnologia e as melhores pessoas se não existe um

processo que guie as atividades dessas pessoas utilizando tais tecnologias. Existem

grande chances de ter problemas relacionados à falta de controle ou

desorganização, caso não tenha um processo que discipline as tarefas das pessoas

(PARREIRA, 2006).

2.1 PROCESSO/CICLO DE VIDA DO SOFTWARE

Como todo produto, o software possui um ciclo de vida, que pode ser definido

como o conjunto de todas as etapas relacionadas à sua existência, desde a sua

concepção, até o seu desaparecimento. Isso inclui uma série de etapas, dentre elas:

a concepção, onde o produto é idealizado, a partir da percepção de uma

necessidade; o desenvolvimento, a partir da identificação dos requisitos e sua

transformação em itens a serem entregues ao cliente; a operação, quando o produto

é instalado para ser utilizado em algum processo de negócio, sujeita a manutenção,

sempre que necessário; e a retirada, quando o produto tem sua vida útil finalizada.

(MEDEIROS, 2006).

No ciclo de vida de um software, a codificação, que representa a escrita do

programa utilizando alguma linguagem de programação, é apenas uma parte do

ciclo de vida, embora muitos profissionais de informática acreditem que essa seja a

única tarefa relacionada ao desenvolvimento de software (MEDEIROS, 2006).

O processo de software é um guia de como um produto de software deve ser

construído, do início ao fim. A ligação está no fato que esse guia depende do modelo

de ciclo de vida utilizado. Existem vários modelos e dependendo dele, as atividades

a serem executadas podem variar. Um processo é um conjunto de passos

parcialmente ordenados, constituídos por atividades, métodos, práticas e

transformações, utilizados para atingir uma meta. Uma meta está associada a

resultados, que são os produtos resultantes da execução do processo (MEDEIROS,

2006).

Um processo deve ter uma documentação que o descreve, apresentando detalhes sobre o que é feito (produto), quando (passos), por quem (agentes), o que usa como entrada (insumo) e o que é produzido (resultado) (MEDEIROS, 2006).

Page 19: MONOGRAFIA: Reengenharia em Software Legado

19

A engenharia de software compreende um conjunto de etapas que engloba os

métodos, ferramentas e procedimentos. Essas etapas frequentemente são citadas

como paradigmas da engenharia de software. Um paradigma de engenharia de

software é escolhido tendo-se como base a natureza do projeto e da aplicação, os

métodos e as ferramentas a serem usados, os controles e os produtos que precisam

ser entregues (PARREIRA, 2006).

O processo de software é um guia de como um produto de software deve ser construído, do início ao fim. Este guia depende do modelo de ciclo de vida utilizado. Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, utilizados para se atingir uma meta. Uma meta está associada a resultados, que são os produtos resultantes da execução do processo (PARREIRA, 2006).

Os “métodos” proporcionam os detalhes de "como fazer" para construir o

software, envolvem um amplo conjunto de tarefas que inclui: planejamento com

estimativa de projeto, análise de requisitos de software e de sistemas, projeto da

estrutura de dados, arquitetura de programa e algoritmo de processamento,

codificação, teste e manutenção. Os métodos da engenharia de software na maioria

das vezes introduzem uma notação gráfica ou orientada a linguagem especial e

introduzem um conjunto de critérios para a qualidade do software (PARREIRA,

2006).

As “ferramentas” de engenharia de software proporcionam apoio automatizado

ou semiautomatizado aos métodos. Existem ferramentas para sustentar cada um

dos métodos citados anteriormente. Quando as ferramentas são integradas de forma

que a informação criada por uma ferramenta possa ser usada por outra, é

estabelecido um sistema de suporte ao desenvolvimento de software chamado de

CASE (PARREIRA, 2006).

O CASE (Computer Aided Software Engineering) combina software, hardware e um banco de dados de engenharia de software (uma estrutura de dados contendo importantes informações sobre analise, projeto, codificação e teste) para criar um ambiente de engenharia de software que seja análogo ao projeto auxiliado por computador/engenharia auxiliada por computador para o hardware (PARREIRA, 2006).

Os “procedimentos” da engenharia de software constituem o elo para manter

junto os métodos e as ferramentas, alavancando possibilidades para o

desenvolvimento racional e oportuno do software. A sequência em que os métodos

serão aplicados, os produtos que são exigidos com prazo para entrega

(documentos, relatórios, formulários etc.), o marco de referência que possibilitam aos

Page 20: MONOGRAFIA: Reengenharia em Software Legado

20

gerentes de software avaliar o progresso, os controles que ajudam a assegurar a

qualidade e a coordenar as mudanças é definido pelos procedimentos (PARREIRA,

2006).

Para seleção de um processo, e posterior iniciação de um projeto, é necessário

entender qual modelo de ciclo de vida ele utiliza. Um modelo de ciclo de vida pode

ser apropriado para um projeto, mas não ser apropriado para outro. É necessário

entender bem os conceitos relacionados para que as escolhas feitas sejam

baseadas em conhecimento e não no acaso (CORDEIRO, 2012).

2.2 MODELOS DE CICLO DE VIDA

O termo modelo de ciclo de vida é utilizado para descrever um grupo de

atividades relacionado ao desenvolvimento de software e a forma como elas se

relacionam. Para cada modelo de ciclo de vida existe um relacionamento diferente

entre as atividades, determinando formas diferentes de se conduzir o processo de

construção do produto (SANTOS, 2005).

Segundo SANTOS (2005) para detalhamento dos modelos de ciclo de vida, é

necessário entender os subprocessos (fluxos ou disciplinas) ligados às tarefas de

desenvolvimento. Os principais subprocessos são:

• Requisitos: obtenção do enunciado, completo, claro e preciso dos desejos,

necessidades, expectativas e restrições dos clientes em relação ao produto a ser

desenvolvido.

• Análise: modelagem dos conceitos relevantes do domínio do problema, com

o intuito de verificar a qualidade dos requisitos obtidos e detalhar tais requisitos em

um nível adequado aos desenvolvedores.

• Desenho (ou projeto): definição de uma estrutura implementável para um

produto, que atenda aos requisitos especificados.

• Implementação: codificação das partes que compõe o software, definidas no

desenho, utilizando as tecnologias selecionadas.

• Teste: verificação dinâmica das partes que constituem o software, utilizando

um conjunto finito de casos de teste, selecionados dentro de um domínio

potencialmente infinito, contra seu comportamento esperado.

A literatura cita vários tipos de modelos de ciclo de vida de software. Dentre os

diversos modelos de ciclos de vida de software, pode-se citar: cascata, espiral,

Page 21: MONOGRAFIA: Reengenharia em Software Legado

21

prototipação, refinamento iterativo, ciclo de vida progressivo, desenvolvimento

incremental, entre outros (CORDEIRO, 2012).

2.2.1 Ciclo de vida clássico (modelo cascata)

O modelo clássico ou cascata foi derivado de modelos de atividade de

engenharia com o fim de estabelecer ordem no desenvolvimento de grandes

produtos de software. Em vista dos outros modelos, este é o mais rígido, menos

administrativo e o modelo mais antigo, porém o mais amplamente usado e

importante da engenharia de software. O modelo em cascata é referência para

muitos outros modelos, servindo de base para muitos projetos modernos

(PRESSMAN, 2006).

O sucesso do modelo cascata está no fato de o mesmo ser orientado para

documentação. Neste caso a documentação abrange mais do que arquivo de texto,

abrange representações gráficas ou simulações (PRESSMAN, 2006).

O ciclo de vida clássico requer uma abordagem sistemática, uma abordagem

incorporando processos, métodos e ferramentas, sequencial ao desenvolvimento de

software, que se inicia no nível do sistema e avança ao longo da análise, projeto,

codificação, teste e manutenção. Tendem a colocar ordem numa atividade

inerentemente caótica (PRESSMAN, 2006).

O modelo cascata é um modelo de engenharia projetado para ser aplicado no

desenvolvimento do software. A ideia principal que o dirige é que as diferentes

etapas de desenvolvimento seguem uma sequência. A saída da primeira etapa “fluí”

para a segunda etapa e a saída da segunda etapa “fluí” para a terceira e assim por

diante. As atividades a executar são agrupadas em tarefas, executadas

sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior

tiver terminado (MELO, 2007).

A vantagem do modelo é que o mesmo só avança para a próxima tarefa, a

partir da aceitação e validação do cliente. O modelo pressupõe que o cliente

participa ativamente no projeto. Este modelo minimiza o impacto da compreensão

adquirida no curso do projeto (MELLO, 2007).

O andamento do processo flui de cima para baixo, como uma cascata (daí o

nome “modelo cascata”). O modelo envolve as seguintes atividades:

planejamento/engenharia de sistemas; análise de requisitos; projeto;

Page 22: MONOGRAFIA: Reengenharia em Software Legado

22

construção/codificação; teste e integração; operação e manutenção. Como mostra a

figura (2) abaixo (MELO, 2007).

Figura 2 – Modelo cascata Fonte: SOMMERVILLE, 2003.

2.2.2 Prototipação

Um protótipo é uma versão inicial de um sistema de software, que é utilizada

para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer

mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de

um protótipo é essencial para que os custos sejam controlados e os usuários

possam fazer experiências com o protótipo no início do processo de software

(PRESSMAN, 2006).

A prototipação possibilita ao desenvolvedor criar um modelo de software que

será implementado. O seu principal objetivo é antecipar ao usuário final um modelo

de sistema para que o mesmo possa avaliar suas reais finalidades, identificar erros e

omissões, com isso o desenvolvedor pode efetuar de forma imediata as correções e

ajustes no software (PRESSMAN, 2006).

Como todas as abordagens ao desenvolvimento de software, a prototipação

inicia-se com a coleta de requisitos (Figura 3). Faz-se então um projeto rápido

contendo os aspectos que serão visíveis ao cliente. O projeto rápido leva à

Page 23: MONOGRAFIA: Reengenharia em Software Legado

23

construção de um protótipo, que, será avaliado pelo cliente/usuário. Esta avaliação

será usada para refinar requisitos para o software desenvolvido. Idealmente, o

protótipo serve como um mecanismo para identificar os requisitos de software.

Muitas vezes, é preciso descartar um protótipo e, partir do início para evitar perda de

tempo com correções (PRESSMAN, 2006).

Figura 3 – Modelo prototipação

Fonte: PRESSMAN, 2006.

A filosofia de protótipos possui algumas vantagens, que são: garantia de

sucesso técnico e psicológico; redução no fator tempo; ideal para sistemas

gerenciais e de apoio à decisão; sistema atual melhora a percepção do usuário em

relação software; o desenvolvedor constrói algo imediatamente; entre outros

(PRESSMAN, 2006).

As principais desvantagens deste modelo é que na maioria das vezes o cliente

quer resultados, e, muitas vezes não saberá, ou não entenderá que um protótipo

pode estar longe do software ideal. Mesmo assim, a gerência de desenvolvimento

cede às reclamações e tenta encurtar o prazo de entrega, o qual já estava

prolongado. O desenvolvedor, na pressa de colocar um protótipo em funcionamento,

é levado a usar uma linguagem de programação imprópria por simplesmente estar à

disposição ou estar mais familiarizado. Essa atitude poderá levar a um algoritmo

ineficiente. Outras desvantagens é que pode haver muitos ajustes no protótipo final,

a fim de melhorar a qualidade; o desenvolvedor pode esquecer estruturas

Page 24: MONOGRAFIA: Reengenharia em Software Legado

24

inapropriadas no protótipo; exige elevada capacitação gerencial por parte da equipe

do projeto; entre outros (PRESSMAN, 2006).

O protótipo é baseado no “feedback” dos usuários, por causa disso as

mudanças são feitas no protótipo. Dependendo do comentário dos usuários, estas

mudanças podem ser menores, de modo que alterem formatos, ou podem ser

maiores, de modo que são requeridas mudanças estruturais no protótipo. Ainda que

possam ocorrer problemas, o uso da prototipação é um paradigma eficiente na

Engenharia de Software. O grande segredo é o entendimento entre o desenvolvedor

e o cliente (PRESSMAN, 2006).

2.2.3 Modelo espiral

O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar

os diversos modelos existentes à época, eliminando suas dificuldades e explorando

seus pontos fortes. Foi desenvolvido para abranger as melhores características do

ciclo de vida clássico e da prototipação, porém com a adição de um novo elemento,

que foi a “análise de risco”. Este modelo de ciclo de vida se utiliza de protótipos por

se adequar muito bem com esta filosofia de desenvolvimento. Cada passo (Figura 4)

através do ciclo inclui: planejamento, análise e projeto, prototipação e avaliação. Os

passos se repetem até que um produto seja obtido (PRESSMAN, 2006).

Figura 4 – Modelo espiral Fonte: PRESSMAN, 2006.

Page 25: MONOGRAFIA: Reengenharia em Software Legado

25

Um ciclo se inicia com a determinação de objetivos, alternativas e restrições

(primeira tarefa) na qual ocorre o comprometimento dos envolvidos e o

estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa,

avaliação de alternativas, identificação e solução de riscos, executa-se uma análise

de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for

considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o

desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata.

Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo

(PRESSMAN, 2006).

Os riscos são circunstâncias adversas que podem atrapalhar o processo de

desenvolvimento e a qualidade do produto a ser desenvolvido, com isso é possível

prever e eliminar os problemas de alto risco através de um planejamento e projetos

cuidadosos. Este é um modelo que atende aos seguintes casos: o problema a ser

resolvido não está totalmente entendido; a realidade pode mudar enquanto o

sistema está sendo desenvolvido; a própria solução adotada pode ter algum efeito

colateral desconhecido e a preocupação está centrada mais na qualidade e

funcionalidade do que se produz (PRESSMAN, 2006).

Com base na experiência adquirida com a primeira versão, estabelecem-se

novos requisitos para o sistema, e uma nova versão é concebida e implementada. O

modelo espiral tende à uma trajetória para o modelo mais completo do sistema,

baseado principalmente em decisões de prosseguir ou não, de acordo com a

avaliação, seja do cliente ou do desenvolvedor (PRESSMAN, 2006).

O paradigma de modelo espiral é a abordagem mais realista para o desenvolvimento de softwares e sistemas em grande escala. Ele usa uma abordagem "evolucionária", capacitando o desenvolvedor e o cliente a entender e reagir aos riscos, em cada etapa evolutiva da espiral. Usa a prototipação como um mecanismo de redução de riscos e a mesma pode ser aplicada em qualquer ponto evolutivo. Porém, pode ser difícil convencer grandes clientes de que a abordagem evolutiva é controlável. Se um grande risco não for descoberto, com certeza ocorrerão problemas (PRESSMAN, 2006).

Esse paradigma é relativamente novo, e não tem sido amplamente usado como

outros modelos anteriormente explicados, o motivo está por exigir considerável

experiência na determinação de riscos e depende dessa experiência para ter

sucesso. O modelo espiral é mais adequado para sistemas complexos e que exijam

um alto nível de interações com os usuários, a fim de possibilitar a abordagem de

todos os problemas desse sistema (PRESSMAN, 2006).

Page 26: MONOGRAFIA: Reengenharia em Software Legado

26

3 SOFTWARE LEGADO

Um sistema de 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 sistemas de software úteis inevitavelmente são modificados quando as

empresas passam por mudanças. Portanto, esses sistemas incorporam um grande

número de alterações que foi feitas durante muitos anos, além de incorporarem

importantes regras de negócio no seu contexto. São os chamados sistemas legados

(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 (JALOTE, 2005).

A durabilidade de sistema de software é muito variável, muitos sistemas de

grande porte permanecem em uso por mais de dez anos. 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 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. Possuem uma função crítica em

relação ao processo funcional de uma organização que passou por diversas

modificações de requisitos durante seu tempo de vida (BRAGA, 2004).

A preocupação do engenheiro de software 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

Page 27: MONOGRAFIA: Reengenharia em Software Legado

27

mudanças. Muitas vezes o engenheiro de software não mexe no software legado

quando o mesmo atende as necessidades do cliente (BROOKS, 1995).

Com o constante avanço da tecnologia, esses sistemas costumam ser

implantados nas organizações já desatualizados tecnologicamente (BROOKS,

1995).

Um sistema legado contém software, hardware, profissionais, processos, regras de negócio e informações geradas e manipuladas por todo sistema. Existem profissionais ligados diretamente ao mesmo, como analistas, desenvolvedores e administradores de dados; e existem profissionais que utilizam o sistema, como diretores, gerentes e usuários de um modo geral (BRAGA, 2004).

É necessário também focar o lado humano de uma possível mudança

tecnológica com a modernização ou mesmo substituição do sistema legado. Esse

acompanhamento estratégico se chama “Gestão de Mudanças” (Change

management) que são ferramentas e técnicas utilizadas para atenuar o impacto da

mudança tecnológica causado nos indivíduos diretamente ligados à tecnologia

(SOMMERVILLE, 2003).

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

3.1 EVOLUÇÃO PARA O LEGADO

A evolução de um sistema é um termo amplo que cobre todo o tempo entre

uma simples adição de um campo a um banco de dados até a completa

reimplementação de um sistema. Essas atividades de evolução podem ser divididas

em três categorias: manutenção, modernização e substituição (PEGO, 2010).

Page 28: MONOGRAFIA: Reengenharia em Software Legado

28

A manutenção é um processo incremental e iterativo em que pequenas

modificações são efetuadas no sistema. Essas modificações podem indicar

correções de erros ou pequenas melhorias no sistema, e nunca devem indicar

grandes mudanças estruturais (PEGO, 2010).

A substituição é indicada para sistemas que não conseguem se adaptar às

necessidades do negócio e para os quais a modernização não é mais possível ou

viável (PEGO, 2010).

A modernização envolve mudanças maiores que a manutenção, mas conserva

uma porção significativa do sistema. Essas mudanças incluem a reestruturação do

sistema, melhorias funcionais importantes, ou novos atributos de software. A

modernização é utilizada quando um sistema legado requer mudanças significativas

que as possíveis com manutenção (PEGO, 2010).

O tipo de modernização de um sistema legado pode ser definido pelo nível de

entendimento do sistema requerido para suportar os esforços de modernização.

Conhecimento interno da lógica do sistema é chamada “modernização white-box”, e

a que requer somente o conhecimento das interfaces externas do sistema é

chamada “modernização black-box” (PEGO, 2010).

3.2 ARQUITETURA

A arquitetura de qualquer software, seja ele legado ou não, representa um

artefato de projeto complexo, havendo uma variedade de formas de "olhar" e

compreendê-la (VASCONCELOS, 2007).

Uma arquitetura descreve diferentes propriedades do software, como a sua

divisão em elementos arquiteturais, protocolos de comunicação e controle,

sincronização, distribuição física, acesso a dados, etc. Uma arquitetura de software

deve ser vista e descrita mediante diferentes perspectivas e deve identificar seus

componentes, relacionamentos estáticos, interações dinâmicas, propriedades,

características e restrições (VASCONCELOS, 2007).

Quando se trata da arquitetura de um sistema legado, normalmente

apresentam algumas particularidades. No contexto organizacional possui vários

componentes, figura (5), são eles: hardware do sistema; software de apoio; software

de aplicação e processos de negócios (VASCONCELOS, 2007).

Page 29: MONOGRAFIA: Reengenharia em Software Legado

29

Figura 5 – Modelo em camadas de um software legado Fonte: SOMMERVILLE, 2003.

Quando se trata de “hardware do sistema” na maioria dos sistemas obsoletos o

hardware é antigo, não existem mais fornecedores e a manutenção é dispendiosa.

Em muitos casos, os sistemas legados foram escritos para hardware de mainframe e

pode não ser compatível com as atuais políticas de compras na área de tecnologia

da informação (BRAGA, 2004).

O “software de apoio” como o sistema operacional, compiladores, ferramentas,

etc. também pode estar desatualizado. O sistema pode ter sido compilado utilizando-

se uma versão de um compilador hoje descontinuada, e a mesma deve ser mantida

(BRAGA, 2004).

No caso do “software de aplicação”, não é um único programa de aplicação,

mas incluiu vários programas. O sistema pode ter iniciado com um único programa

processando um ou dois arquivos de dados, mas ao longo do tempo, podem ter sido

implantadas alterações como a adição de novos programas, que compartilham os

dados e se comunicam com outros programas do sistema. Esses diferentes

programas, geralmente são escritos e desenvolvidos por pessoas e linguagens

diferentes, em épocas distintas (SOMMERVILLE, 2003).

Como o software de aplicação, temos também os “dados de aplicação” que são aplicados no mesmo contexto. Em sistemas legados um imenso volume de dados se acumulou durante o tempo de existência do sistema. Esses dados podem estar inconsistentes, duplicados em diferentes arquivos. Assim como acontece com o software de aplicação, os arquivos de dados iniciais sofrem alterações à medida que novas informações são exigidas (BRAGA, 2004).

Page 30: MONOGRAFIA: Reengenharia em Software Legado

30

A camada de “processos de negócios” são informações sobre os processos

internos da organização, codificadas em uma linguagem de programação e

espalhadas pelos programas que fazem parte do sistema. Em boa parte dos

sistemas essas regras não estão bem documentadas, sendo do conhecimento tático

de gerentes, analistas e usuários do sistema (BRAGA, 2004).

3.3 NÍVEL LÓGICO

Modificar uma camada do sistema pode introduzir novos recursos, e as

camadas superiores do sistema são beneficiadas desses recursos. A modificação do

software no sistema pode torná-lo mais lento, de modo que um novo hardware é

necessário. Em grande parte das vezes é impossível manter interfaces de hardware,

especialmente se for proposta uma mudança radical para um novo tipo de hardware

(MECELLA, 1999).

A separação do sistema legado em níveis lógicos é uma “ponte” para um

posterior tratamento, manutenção ou integração. Os níveis lógicos se dividem em

quatro partes, como mostra a figura 6 (MECELLA, 1999).

Figura 6 - Níveis lógicos de sistemas computacionais Fonte: MECELLA, 1999.

A primeira representação é o “altamente Decomponível (amigável)” este

sistema é dividido em três níveis lógicos bem distintos e estruturado. A alteração de

Page 31: MONOGRAFIA: Reengenharia em Software Legado

31

um nível não afetará significativamente o outro nível. Todos os níveis são

prontamente acessíveis (MECELLA, 1999).

A segunda representação é o “decomponível nos dados (pouco amigável)” este

sistema é dividido em dois níveis lógicos: o nível de interface em conjunto com o

nível de processamento lógico e o nível de dados. O acesso aos dados nesse tipo

de sistema é imediato, ao contrário do acesso à interface ou o processamento

lógico. Sua integração a outros sistemas é conseguida com programação e

utilização de tecnologias (MECELLA, 1999).

A terceira representação é o “decomponível no programa (pouco amigável)”

este sistema é dividido em dois níveis lógicos: o nível de interface, separado e o

nível de programas e dados, em conjunto. Os dados somente são acessíveis a partir

de funções do sistema. Nesta categoria se encontram a maioria dos sistemas

legados. Sua integração a outros sistemas é conseguida com programação e

utilização de tecnologias (MECELLA, 1999).

A quarta e ultima representação é o “monolítico (hostil)” este sistema é

composto de um único bloco lógico. São aplicações bem antigas, e o acesso às suas

informações é bastante difícil. Sua integração a outros sistemas é bastante

complexa (MECELLA, 1999).

3.4 AVALIAÇÃO

Segundo Warren ao avaliar um sistema legado, deve-se 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).

Essas avaliações são meramente subjetivas e sua quantificação deve ser efetuada utilizando-se uma abordagem de questionamentos aos vários indivíduos envolvidos no processo, colhendo assim vários pontos de vista. Dados quantitativos coletados também poderão auxiliar na avaliação do sistema, como: o número de pedidos de modificações no sistema; o volume de dados utilizados pelo sistema, etc. A formulação das questões a serem efetuadas deve ser inerente às duas perspectivas adotadas para a avaliação do sistema legado (SOMMERVILLE, 2003).

O ideal é que seja utilizada a avaliação objetiva para informar as decisões

sobre o que fazer com o sistema legado. Contudo, em muitos casos, essas decisões

Page 32: MONOGRAFIA: Reengenharia em Software Legado

32

não são realmente objetivas, mas se baseiam em considerações organizacionais ou

políticas. É imprescindível para uma organização efetuar uma correta avaliação de

seus sistemas legados. Caso essa avaliação seja efetuada sem critério, as decisões

tomadas poderão representar perdas significativas de dinheiro e recursos (BRAGA,

2004).

Supondo que uma organização possua dez sistemas legados, 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 (7), é 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 7 – Qualidade de sistema e valor de negócio

Fonte: SOMMERVILLE, 2003.

Quando o sistema se encaixa no nível de “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).

Agora se o sistema se enquadra no nível de “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

Page 33: MONOGRAFIA: Reengenharia em Software Legado

33

que os custos operacionais são altos, de modo que são candidatos à transformação

ou à substituição do sistema (BRAGA, 2004).

No nível de “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 muito 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).

Quando o sistema se enquadra no nível de “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).

3.5 MANUTENÇÃO

A manutenção é definida como a totalidade de atividades requeridas para

prover suporte de custo efetivo para um sistema de software. As atividades são

realizadas tanto durante o estágio de pré-entrega quanto no estágio de pós-entrega.

A manutenção é uma atividade inevitável e pode vir a ser a mais longa fase no ciclo

de vida do sistema, isso se justifica através das leis de evolução do software

(RAMOS, 2008).

Essas leis de evolução do software são: “mudança contínua” no qual os

sistemas devem ser continuamente adaptados senão se tornará progressivamente

insatisfatório. O “aumento da complexidade” no qual o sistema aumenta sua

complexidade conforme evolui, a não ser que algo seja feito para controlar tal

complexidade. O “crescimento contínuo” no qual o conteúdo funcional de um sistema

deve crescer continuamente para manter a satisfação do usuário durante a sua vida

útil (RAMOS, 2008).

Os principais fatores que dificultam e encarecem a manutenção no software

legado é que muitas vezes é excepcionalmente difícil entender o programa “de outra

pessoa”, isso porque foram implementadas por diferentes equipes. Não há um estilo

de programação consistente em todo sistema e os algoritmos são mal escritos. Uma

parte ou todo sistema pode ter sido desenvolvido em uma linguagem obsoleta, e

encontrar um profissional que tenha conhecimento dessa linguagem acaba sendo

Page 34: MONOGRAFIA: Reengenharia em Software Legado

34

difícil e caro, uma vez que um profissional deste nível é raro no mercado e o seu

salário maior (RAMOS, 2008).

Muitas vezes foi usado um sistema de administração de bases de dados que

pode estar obsoleto, ou depende de arquivos armazenados separadamente. No

caso de arquivos separados, cada um tem seu próprio formato e, frequentemente, as

mesmas informações são duplicadas e representadas em diferentes formas e em

diferentes arquivos. Essa duplicação usualmente acontece porque as informações

são fortemente integradas com as estruturas de dados dos programas (DINIZ, 2010).

Outro problema do software legado está em sua documentação, muitas vezes

não existe documentação e quando existe, ela não é compreensível e consistente

com o código fonte, neste caso ela não tem valor. Em alguns casos, a única

documentação é o código-fonte do sistema (RAMOS, 2008).

Esses softwares por não serem projetados não são apitos e nem estão preparados para mudanças, às chances de perda de desempenho devido a modificações não adequadas na sua estrutura interna e o número crescente de novos erros devidos a alterações indevidas no código é um risco que se corre (PINTO, 2004).

Os sistemas são feitos para refletir comportamentos do mundo real, logo é

necessário que o software acompanhe as mudanças impostas pelo ambiente na

qual está inserido. Uma falha em acompanhar essas mudanças pode implicar em

perda de qualidade por parte do software ou até mesmo no fim da sua vida útil, os

muitos anos de manutenção podem corromper a estrutura do sistema, tornando-o

cada vez mais difícil de ser compreendido. O envelhecimento de um software é um

processo inevitável (PINTO, 2004).

Existem dois tipos de envelhecimento de software: o primeiro ocorre quando os responsáveis por um software falham em adaptá-lo para os novos requisitos, um exemplo seria um software que no passado funcionava perfeitamente, mas devido ao fato de seu sistema operacional ter caído em desuso e não existir uma nova versão do software para um sistema operacional mais recente foi esquecido por seus usuários (PINTO, 2004).

O segundo ocorre quando mudanças no software são feitas por

desenvolvedores que não entendem a estrutura original deste, o que fatalmente

implicará em algum dano para esta estrutura, que mesmo pequeno irá aumentando

conforme novas atualizações forem sendo feitas, e com o passar do tempo cada

nova mudança se tornará mais difícil e consequentemente cara. Caso não seja feita

uma reestruturação do software, este chegará a um ponto onde novas atualizações

ficarão inviáveis (PINTO, 2004).

Page 35: MONOGRAFIA: Reengenharia em Software Legado

35

A partir do momento em que um sistema 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, os sistemas vão se tornando obsoletos

em vista das novas tecnologias que são disponibilizadas (PIEKARSKI, 2000).

As leis da evolução de software são estudadas há 30 anos, e sua contribuição para a melhor compreensão da evolução de software e a engenharia de software como um todo são ainda inestimáveis (VASCONCELOS, 2007).

Com o objetivo de minimizar os problemas gerados por manutenções difíceis e,

algumas vezes, degenerativas da estrutura do sistema, muitas organizações estão

optando por refazer seus sistemas. A ideia básica dessa reconstrução ou

reengenharia é que as informações de projeto e especificação sejam extraídas do

código fonte, reformuladas e reconstruídas, resultando um software mais fácil de ser

mantido (BENNETT, 1991).

Aplicando-se a reengenharia de software, o sistema pode ser redocumentado

e/ou reestruturado, podem ser traduzidos para uma linguagem de programação mais

moderna e implementados em uma plataforma distribuída, bem como seus dados

podem ser migrados para uma base de dados diferente. A reengenharia de software

tem como objetivo fazer sistemas flexíveis, fáceis de modificar, frente às constantes

mudanças das necessidades dos usuários (BENNETT, 1995).

O campo da reengenharia está crescendo em resposta à necessidade crítica

que existe na indústria de software por tecnologia que suporte a manutenção de

sistemas legados e o desenvolvimento evolutivo de novos sistemas. Existe uma

firme e crescente demanda para migrar programas legados de mainframes

monoprocessados, para estações multiprocessadas, distribuídas e ligadas em rede,

visando acompanhar os avanços das técnicas de programação tais como: interfaces

gráficas para o usuário, comunicação interprogramas, desenvolvimento orientado a

objetos, reusabilidade, etc. (COLEMAN, 1994).

3.6 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

Page 36: MONOGRAFIA: Reengenharia em Software Legado

36

críticos apresentam numerosos e importantes problemas para as empresas

(BISBAL, 1999).

Entre os mais significativos destacam-se: apresentam plataformas de hardware

com altos custos de manutenção que poderá se tornar numa das maiores despesas

na área de TI; desenvolvidos em plataformas proprietárias; não passíveis de

publicação na internet; apresentam limitações de integração com outros sistemas; e

restritos com relação ao desenvolvimento de novas funcionalidades (STEVENS,

1998).

Os negócios de hoje só podem sobreviver se eles puderem adaptar

rapidamente para um ambiente variável e tirar vantagens das novas oportunidades

de negócio. A partir do momento que os sistemas de TI se tornam vitais a quase

todos os negócios, é necessário que estes sistemas possam ser modificados

rapidamente e com baixo custo (STEVENS, 1998).

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

da área de mercado e de pessoas e às rápidas mudanças de tecnologia (LEHMAN,

1985).

Page 37: MONOGRAFIA: Reengenharia em Software Legado

37

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

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 (Business Process Reengineering – BPR) quanto à reengenharia de

sistemas (Systems Reengineering – SR). Trata-se de abordagens diferentes,

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

dois processos dentro de uma empresa. De fato, pode-se comprovar que a

reengenharia do processo de negócios pode ser alavancada com o auxílio

computacional da reengenharia de sistemas, ao passo que a reengenharia de

sistemas pode beneficiar-se com a aplicação dos conceitos da reengenharia do

processo de negócios (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 é,

Page 38: MONOGRAFIA: Reengenharia em Software Legado

38

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

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,

2000).

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

de um novo software e a 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 (8) abaixo (SOMMERVILLE, 2003).

Figura 8 - Distinção entre o desenvolvimento de um novo software (1) e reengenharia (2)

Fonte: 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

Page 39: MONOGRAFIA: Reengenharia em Software Legado

39

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, a fim 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).

4.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 (independência dos dados e dos programas)

(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 de software, os estágios iniciais envolvem conceitos mais gerais,

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

A evolução através das fases do processo de desenvolvimento de software

envolve transições dos níveis mais altos de abstração nos estágios iniciais, para

Page 40: MONOGRAFIA: Reengenharia em Software Legado

40

níveis mais baixos nos estágios posteriores. As informações podem ser

representadas em qualquer estágio do desenvolvimento, seja de forma detalhada

(baixo grau de abstração), seja de forma mais sucinta ou global (alto grau de

abstração). Abstração é definida como a habilidade de se ignorar os aspectos de

assuntos não relevantes para o propósito em questão, tornando possível uma

concentração maior nos assuntos principais (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 9 (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;

A técnica tradicional, que avança progressivamente pelas fases do processo de desenvolvimento de software, é denominada engenharia progressiva. A execução dessa técnica consiste em partir de projetos independentes da implementação, que possuem altos níveis de abstração, indo em direção à implementação física do sistema (OSBORNE e CHIKOFSKY, 1990).

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

Page 41: MONOGRAFIA: Reengenharia em Software Legado

41

Na Figura 9, com exceção da engenharia progressiva, as demais transições

entre as fases de desenvolvimento são tecnologias utilizadas na manutenção de

software, sendo assim definidas por PIEKARSKI (2000):

• Redocumentação: como uma subárea da engenharia reversa, é a criação ou

revisão de uma representação semanticamente equivalente, dentro do mesmo nível

relativo de abstração, sendo que as formas resultantes de representação são

consideradas como visões alternativas, utilizadas para uma melhor compreensão

humana do sistema analisado;

• Recuperação de projeto: é uma subárea da engenharia reversa em que o

conhecimento do domínio da aplicação, informações externas e dedução são

adicionados nas observações referentes ao programa, com fim de extrair abstrações

significativas de mais alto nível, além das obtidas por meio da observação direta do

sistema;

• Reestruturação: é a modificação de uma forma de representação, para outra

no mesmo nível de abstração relativo, preservando o comportamento externo do

sistema (funcionalidade e semântica). Frequentemente usada como uma forma de

manutenção preventiva, a reestruturação é aplicada em sistemas que tenham sido

desenvolvidos de forma desestruturada, resultando uma representação que preserva

as características do sistema, mas de forma melhor estruturada;

• Engenharia reversa: é o processo de analisar um sistema a fim de criar sua

representação de uma forma diferente ou em um nível mais alto de abstração do que

o código fonte;

• Reengenharia: é a reconstrução de algo do mundo real, tendo como propósito

a tentativa por melhorias que permitam produzir algo de melhor qualidade ou

comparável ao produto inicial.

4.2 PROCESSO DE REENGENHARIA DE SOFTWARE

O processo de reengenharia é amplamente reconhecido como 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).

Page 42: MONOGRAFIA: Reengenharia em Software Legado

42

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 10 exibe as principais etapas no processo de

reengenharia de software (PIEKARSKI, 2000).

Figura 10 – Processo de reengenharia Fonte: SOMMERVILLE, 2003

Page 43: MONOGRAFIA: Reengenharia em Software Legado

43

4.2.1 Tradução de código-fonte

Quando um programa se encontra escrito em uma linguagem de programação

e precisa, por algum motivo como, por exemplo, falta de suporte ao compilador atual,

ser migrado para outra linguagem, a tradução do código-fonte se faz necessária

(MAZZANTI, 2008).

A tradução do código-fonte mantém a estrutura e a organização do programa

em si inalterada. A linguagem para a qual o programa será transcrito pode ser uma

versão atualizada da linguagem original, como, por exemplo, de PHP 4 para PHP 5,

ou pode ser uma linguagem diferente, como, por exemplo, de C++ para Java

(MAZZANTI, 2008).

A tradução de código-fonte só será economicamente viável se existir alguma

ferramenta para realizar a maior parte da tradução de forma automatizada. Na

maioria dos casos, é impossível realizar a tradução de forma completamente

automática. As instruções da linguagem original podem não ter nenhuma instrução

equivalente na nova linguagem. Embora, esse tipo de ferramenta tem evoluído, não

são raros os casos em que os desenvolvedores devem intervir e corrigir possíveis

erros manualmente (SOMMERVILLE, 2003).

Existem algumas ferramentas no mercado que se propõem a fazer essa tarefa, tais como: CodePorting C#2Java - esta ferramenta converte projetos C# para Java e promete usabilidade, produtividade, simplicidade, confiabilidade, administração facilitada e poderosas customizações; Composer CipherSoft – converte aplicações Oracle Forms e PL/SQL para Java; Telescope for Jaguar – converte Oracle Forms para Java, trata-se de uma solução semi-automatizada, pois precisa de análise da empresa desenvolvedora antes da migração. Existem ainda ferramentas que se destinam a facilitar a atualização de uma tecnologia para outra: a Oracle Forms Migration Assistant é uma ferramenta que atualiza as aplicações Oracle Forms 6i para Oracle Forms 11g (LOVATTO, 2012).

Conversões de linguagens são bem mais difíceis do que se costuma imaginar,

principalmente por problemas de automação. A maioria das ferramentas de

conversão aplica a tecnologia da conversão sintática, mesmo com esta abordagem

aparentemente simples e de baixo nível, muitas dificuldades ocorrem, e o tamanho

das complexidades ainda não é muito bem definido (MAZZANTI, 2008).

É preciso deixar claro que diferente da tradução do código-fonte, a

“segmentação” é o processo de reengenharia com mudança da orientação de

procedimental para orientação a objetos, preservando-se as funcionalidades do

software e a linguagem de programação. Portanto, é realizada a adaptação do

Page 44: MONOGRAFIA: Reengenharia em Software Legado

44

código-fonte, de acordo com os recursos disponíveis na linguagem, de forma a

implementá-lo com características orientadas a objetos (LOVATTO, 2012).

4.2.2 Engenharia reversa

O termo engenharia reversa tem suas origens na análise do hardware, onde a

prática de “decifrar” projetos de produtos era mais comum (PRESSMAN, 1995).

A engenharia reversa é definida como o processo de se tomar um objeto para

verificar como ele funciona, a fim de copiá-lo ou de aprimorá-lo. É uma prática

herdada das antigas indústrias e que, atualmente, é usada em software e hardware.

Na indústria automobilística, por exemplo, um fabricante pode comprar um veículo

de um concorrente, desmontá-lo e examinar as soldas, lacres e outros componentes

do veículo, com o propósito de aprimorar seus próprios veículos, com componentes

similares (PRESSMAN, 1995).

Segundo Chikofsky e Cross, pode-se definir engenharia reversa como uma

coleção de teorias, metodologias, e técnicas capazes de suportar a extração e

abstração de informações de um software existente, produzindo documentos

consistentes, quer seja a partir somente do código fonte, ou através da adição de

conhecimento e experiência que não podem ser automaticamente reconstruídos a

partir do código (CHIKOFSKY e CROSS, 1990).

Quando se trata de software, o programa que passará pelo processo de

engenharia reversa não é o do concorrente, e sim o sistema da própria organização.

Este processo fornece informações da especificação e do projeto de um sistema de

software, a partir de seu código-fonte. Depois, essas informações são armazenadas

de forma que seja possível manipulá-las. Portanto, a engenharia reversa para o

software consiste na análise de um programa, com o objetivo de criar uma

representação do programa em um nível de abstração maior que o código-fonte

(PFLEEGER, 2004).

O processo de engenharia reversa (figura 11) começa com uma fase de análise

utilizando-se ferramentas automatizadas, a fim de descobrir a estrutura do sistema,

estudar como o programa efetua certas operações, melhorar o desempenho do

programa, corrigir uma falha, identificar vírus, ou para adaptar um programa para

que possa ser executado em uma plataforma diferente. Estas informações são

Page 45: MONOGRAFIA: Reengenharia em Software Legado

45

mantidas em dicionários de dados que mantém as informações do sistema,

vinculados ao código-fonte do programa (SOMMERVILLE, 2003).

Figura 11 – Processo de engenharia reversa

Fonte: SOMMERVILLE, 2003.

A recuperação de projeto é uma subárea da engenharia reversa na qual o

conhecimento do domínio da aplicação, informações externas e dedução são

adicionados às observações referentes ao programa, para extrair abstrações

significativas de mais alto nível, além daquelas obtidas através da observação direta

do sistema (SOMMERVILLE, 2003).

Documentos de vários tipos como diagramas de programa e de estrutura de dados e matrizes de rastreamento (que mostram onde as entidades são definidas e referenciadas no sistema), podem ser gerados através das informações armazenadas (SOMMERVILLE, 2003).

Como uma subárea da engenharia reversa, a documentação é a criação ou

revisão de uma representação semanticamente equivalente, dentro do mesmo nível,

relativo de abstração, sendo que as formas resultantes de representação são

consideradas como visões alternativas, utilizadas para uma melhor compreensão

humana do sistema analisado (SOMMERVILLE, 2003).

Depois de gerada a documentação do sistema, outras informações podem ser

adicionadas aos dicionários de dados a fim de ajudar a recriar a especificação do

sistema. Isto, em geral, envolve mais anotações manuais da estrutura do sistema. A

especificação não pode ser inferida automaticamente a partir do modelo do sistema.

(SOMMERVILLE, 2003).

Atualmente, existem várias ferramentas automatizadas e semi-automatizadas

para auxiliar no processo de engenharia reversa. Entretanto, em qualquer processo

Page 46: MONOGRAFIA: Reengenharia em Software Legado

46

de engenharia reversa de sistemas, o envolvimento de especialistas no domínio e na

aplicação é fundamental (SOMMERVILLE, 2003).

4.2.2.1 Visões de software

A partir da engenharia reversa e com base nos níveis e graus de abstração, o

software pode ser visualizado de diferentes maneiras, conforme conceitos de

HARANDI (1990):

• Visão em nível implementacional: abstrai características da linguagem de

programação e características específicas da implementação.

• Visão em nível estrutural: abstrai detalhes da linguagem de programação

para revelar sua estrutura a partir de diferentes perspectivas. O resultado é uma

representação explícita das dependências entre os componentes do sistema.

• Visão em nível funcional: abstrai a função de um componente, isto é, o que o

componente faz. Essa visão relaciona partes do programa a suas funções,

procurando revelar as relações lógicas entre elas.

• Visão em nível de domínio: abstrai o contexto em que o sistema está

operando, ou seja, o porquê do sistema a ser desenvolvido.

Conforme figura 12 é perceptível a correspondência entre as categorias de

visualização do software e as diferentes atividades do ciclo de desenvolvimento de

software (HARANDI, 1990).

Figura 12 - Visualizações de software no ciclo de desenvolvimento

Fonte: HARANDI, 1990.

Page 47: MONOGRAFIA: Reengenharia em Software Legado

47

É relevante ressaltar que uma forma de representação extraída do código pode diferir de uma representação similar que foi desenvolvida no processo de engenharia progressiva. A forma extraída irá refletir a idiossincrasia da representação do código muito mais do que a representação original, que reflete a compreensão do problema pelo analista ou projetista (HARANDI, 1990).

Muitas vezes é necessário acrescentar às informações contidas no código,

outras informações de conhecimentos e experiências humanas, para obter visões

diferenciadas do software. Conforme o escopo das informações usadas, que

resultarão em um nível de entendimento obtido do sistema pode-se formular uma

categorização dos métodos de engenharia reversa (HARANDI, 1990).

4.2.3 Melhoria da estrutura do programa

A reestruturação do programa é feita com o objetivo de tornar o software mais

fácil de ser entendido e modificado. Em sua maioria os programas desenvolvem uma

complexa estrutura lógica devido a diversas modificações sofridas durante a

manutenção. A adição de novos comandos sem modificar a estrutura de controle

existente, é um exemplo (MAZZANTI, 2008).

No curto prazo, essa é uma solução com menor risco e mais rápida, uma vez que reduz as chances de um defeito ser introduzido no sistema. No longo prazo, entretanto, isso pode resultar em um código incompreensível. Estruturas complexas de código podem também ser utilizadas quando os programadores procuram evitar duplicação de código, como em sistemas que são restringidos por uma memória limitada, por exemplo (MAZZANTI, 2008).

A figura (13) abaixo representa as três principais atividades envolvidas na

reestruturação do programa: inicialmente é feito uma analise estática a fim de obter

informações que servem para representar o código como uma rede semântica ou um

grafo direcionado. Esta representação não é necessariamente fácil de ser

compreendida pelas pessoas, normalmente, ela é utilizada apenas por uma

ferramenta automatizada. Após isso, a representação é refinada por meio de

sucessivas simplificações com base em técnicas de transformação. Por fim, uma vez

completada as simplificações, um novo programa é gerado (MAZZANTI, 2008).

Ou seja, a reestruturação é a transformação de uma forma de representação,

para outra no mesmo nível de abstração relativo, preservando o comportamento

externo do sistema (funcionalidade e semântica). Geralmente usada como uma

forma de manutenção preventiva, a reestruturação é aplicada em sistemas que

Page 48: MONOGRAFIA: Reengenharia em Software Legado

48

tenham sido desenvolvidos de forma desestruturada, resultando uma representação

que preserva as características do sistema, porém de forma estruturada

(SOMMERVILLE, 2003).

Figura 13 – Processo de reestruturação de programa Fonte: SOMMERVILLE, 2003.

4.2.4 Modularização de programa

Segundo LOVATTO (2012) modularização é um conceito onde o software é

divido em partes distintas, compõe o ferramental necessário para um programa mais

legível com uma melhor manutenção e melhor desempenho por meio da

programação estruturada.

É caracterizado como um elemento separadamente endereçável do sistema,

menor parte do sistema que realiza uma função completa independente de outras

funções, conjunto de instruções de um programa que pode ser chamado por um

nome, sendo ideal que para os outros módulos seja uma caixa preta (LOVATTO,

2012).

A modularização do programa consiste na reorganização do mesmo, de modo

que as partes relacionadas sejam reunidas em um único módulo. Assim, fica mais

fácil remover redundâncias nesses componentes relacionados, aperfeiçoar suas

interações e simplificar suas interfaces com o restante do programa (MAZZANTI,

2008).

Segundo Mazzanti (2008) diversos tipos de módulos podem ser criados

durante o processo de modularização do programa. São elas:

Page 49: MONOGRAFIA: Reengenharia em Software Legado

49

• Abstrações de dados: agrupam os dados e o processamento associado,

como funções de construção e de acesso, e são flexíveis em relação às mudanças.

Desde que a interface seja mantida, as modificações em dados abstratos não devem

afetar outras partes do programa.

• Módulos de Hardware: esses módulos agrupam todas as funções

relacionadas ao controle de um determinado dispositivo de hardware e estão

estreitamente relacionados com as abstrações de dados.

• Módulos funcionais: esses módulos agrupam funções que realizam tarefas

semelhantes, estreitamente relacionadas. Todas as funções ocupadas com dados

de entrada e a validação destes dados, por exemplo, podem ser agrupadas em um

único módulo.

• Módulos de apoio ao processo: todas as funções e todos os itens específicos

de dados que apoiam um processo de negócio específico são agrupados nesses

módulos.

A modularização de programas juntamente com outras técnicas de

programação integram o ferramental para a elaboração de programas visando,

principalmente, os aspectos de confiabilidade, legibilidade, manutenção e

flexibilidade (LOVATTO, 2012).

4.2.5 Reengenharia de dados

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 (SOMMERVILLE, 2003).

Muitas aplicações contêm dezenas de programas acima dos 20 anos de idade.

Esses programas possuem milhares de elementos de dados, alguns redundantes,

inconsistentes, ou incompreensíveis, e milhares de linhas de código, alguma

obsoletas, outras incorretas. Utilizando ferramentas CASE pode-se evitar alguns

problemas de dados nos novos sistemas, mas a maioria dos aplicativos não possui

força para detectar ou corrigir problemas de dados em sistemas existentes

(SOMMERVILLE, 2003).

De acordo com Sommerville (2003) a princípio, se a funcionalidade do

programa permanecer inalterada a reengenharia de dados não será necessária.

Page 50: MONOGRAFIA: Reengenharia em Software Legado

50

Porém, na prática, existem alguns fatores pelos quais os dados precisam ser

modificados, como:

• Degradação dos dados: existência de dados duplicados ou redundantes,

armazenados em diferentes partes do programa com diferentes formatos. Ainda, os

dados podem não refletir alterações no ambiente externo.

• Limites impostos aos programas: quando o sistema precisa tratar de um

volume maior de dados do que foi previsto pelos projetistas.

• Evolução da arquitetura: na migração de arquitetura centralizada para

distribuída, o acesso aos dados pode ser feito remotamente, por vários usuários e ao

mesmo tempo.

4.3 VANTAGENS DA REENGENHARIA

A reengenharia é a forma que muitas organizações estão buscando para

manter seus softwares, livrando-se das manutenções difíceis e da degeneração de

suas estruturas. Por este motivo, é importante que o resultado desse processo seja

confiável. Desta forma, a garantia da qualidade é o estopim para as vantagens da

mesma (LEMOS, 2003).

Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais (PRESSMAN, 2006).

Realizar a reengenharia é resultante de fatores 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 (HAMMER, 1994).

Outros fatores são relacionados com a complexidade das atividades

empresariais, tais como a busca por produtividade; a flexibilidade frente às

constantes mudanças; a concentração no ramo de negócio; os relacionamentos com

clientes, com o meio ambiente e com os governos; o apoio de consultores; a

parceirização; a gestão e a remuneração dos recursos humanos por resultados.

Page 51: MONOGRAFIA: Reengenharia em Software Legado

51

Todos esses pontos influenciam diretamente na reengenharia dos softwares

existentes em empresas (HAMMER, 1994).

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. E como resultados

disso, as possíveis manutenções no software vão ser menos requisitados e quando

a mesma for, será de fácil resolução, uma vez que o programa estará mais bem

estruturado e documentado (SOMMERVILLE, 2003).

Quanto ao melhoramento da performance dos processos, em particular os que

envolvem forte componente humana, deve em primeiro lugar conhecer-se os fatores

a que o cliente atribui maior valor nos serviços que a organização lhe presta (ou

pode vir a prestar) para, a partir daí, identificar as atividades críticas desse ponto de

vista, as quais devem começar por ser submetidas a uma avaliação do seu atual

desempenho (MARI, 2008).

Esta medição da avaliação do desempenho é feita através de benchmarking,

isto é, de uma sistemática comparação de indicadores-chave da performance de

processos (key process performance indicators) entre a organização em causa e os

seus concorrentes melhor cotados no mercado, frequentemente essa comparação,

envolve organizações de outros setores de atividade mas com processos

semelhantes (MARI, 2008).

Centrando a atenção nesses processos e atividades críticas (sobretudo nos que acrescentam maior valor e estão com desempenho inferior ao "melhor da classe"), há que proceder ao seu redesenho, se necessário a partir do zero (isto é, de uma folha de papel em branco) (MARI, 2008).

Com alguma frequência, nesse redesenho é possível incluir aquilo que

poderemos designar por "pontos de ruptura" (breakthrougs), entendidos como sendo

algo que permite alcançar uma vantagem competitiva significativa e percepcionada

pelo mercado, como tendo introduzido neste um elemento diferenciador, que

normalmente resulta um acréscimo sustentado da quota de mercado (MARI, 2008).

As tecnologias de informação têm proporcionado muitos dos "pontos de

ruptura" que chegam ao nosso conhecimento como elementos fulcrais de casos bem

sucedidos de reengenharia, mas não é a sua única fonte. Portanto outros elementos

também contribuem para o sucesso da reengenharia, como por exemplo, a adoção

de novos métodos de trabalho, novas tecnologias de produção, novo desenho de

produtos e, inevitavelmente, novas formas de participação dos recursos humanos

(MARI, 2008).

Page 52: MONOGRAFIA: Reengenharia em Software Legado

52

Outra vantagem são os riscos reduzidos, pois existe um alto risco em

desenvolver um software novo que seja essencial. Podem ser cometidos erros na

especificação do sistema e ocorrer problemas de desenvolvimento, a importância da

reengenharia está em possibilitar que todas as funcionalidades do software legado

não sejam perdidas, o que aconteceria se fosse optado pelo desenvolvimento de um

novo software (MARI, 2008).

Uma das maiores vantagens da reengenharia é que ela preserva a solução

existente do negócio em uma nova arquitetura técnica e é uma solução que deve ser

considerada pelas empresas, pois os custos de desenvolvimento e implantação de

um novo sistema podem ser muito altos. Estudos têm mostrados que reengenharia,

quando aplicada apropriadamente, geralmente promove custo efetivo e menos riscos

do que o desenvolvimento de um novo sistema (CAGNIN, 2005).

Conclui-se que a reengenharia é de grande vantagem quando se trata de

sistemas legados, podendo envolver, documentar, organizar e reescrever o sistema

para uma linguagem de programação mais moderna. As vantagens da reengenharia

se destacam muito quando se trata de custo para as empresas e assim como de

tempo para a introdução do novo sistema na rotina da empresa (LEMOS, 2003).

4.4 DIFICULDADES NO PROCESSO DE REENGENHARIA

Atualmente, a qualidade dos softwares está cada vez melhor, a tecnologia e a

mobilidade está ao alcance de todos, porém ao mesmo tempo em que a tecnologia

evolui, muitas pessoas e gestores de organizações não conseguem se “vê” livres

dos softwares legados, mesmo que seja para usar como fonte de pesquisa em

dados antigos. Esses softwares legados, em sua grande maioria, são mantidos

ativos para qualquer que seja a eventualidade e sua perda é um risco que a

organização prefere correr (SILVA, 2005).

A quantidade de código em sistemas legados é imensa. Em 1990, estimava-se

que existiam 120 bilhões de linhas de código fonte de sistemas legados, a maioria

em COBOL ou FORTRAN (são linguagens de programação com facilidades

limitadas de estruturação de programas e dados). A migração ou alteração desses

softwares gera grandes desafios técnicos, uma vez que a perda de funções e custo

são as principais delas (BENNETT, 1995).

Page 53: MONOGRAFIA: Reengenharia em Software Legado

53

Ao mesmo tempo em que o software legado traz incorporado a ele 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. Porém o que hoje é chamado de vício e defeito, naquela época era a melhor indicação para a resolução do problema (BENNETT, 1995).

Existem fatores que estão diretamente relacionados com a dificuldade e

entendimento do software legado, por exemplo, antigamente, ter um hardware com

um bom desempenho, era um custo muito alto para as organizações, então as

mesmas optavam por hardwares mais baratos e mais limitados, logo, o tamanho de

armazenamento do software tinha que ser reduzido. Hoje com hardware mais

baratos, isso não é mais um empecilho no desenvolvimento. Contudo, no

desenvolvimento do software sempre se prezou pela eficiência em detrimento da

clareza e estruturação do programa, o que leva a sucessivas manutenções e

consequentes degenerações no software (BENNETT, 1995).

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

os possuem, pois com eles têm embutidas informações dos negócios e

procedimentos, que na maioria das vezes não estão 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 de um

modo geral, preferem não “aposentar” seus softwares legados e mantê-los em uso,

com adaptações às novas necessidades (BENNETT, 1995).

Muitos gerentes de tecnologia de informação têm medo de migrar para novas

tecnologias ou por que não confiam na tecnologia ou por que não confiam no seu

corpo técnico de pessoal. As dificuldades devem ser enfrentadas, pois qualquer

software que não evoluir continuamente, torna-se menos útil no mundo real (DINIZ,

2010).

Segundo Bennett (1991), os motivos de maior relevância para manter o

software legado são:

• Desestruturação e dificuldade de entendimento do código, pois o software foi

desenvolvido antes da introdução dos métodos de programação estruturada;

• Programadores que não participaram do desenvolvimento de software

sentem dificuldade em entender e mapear a funcionalidade para o código fonte;

• Documentação desatualizada, não auxiliando em nada a equipe de

manutenção;

• Dificuldade de predizer as consequências de efeitos colaterais;

Page 54: MONOGRAFIA: Reengenharia em Software Legado

54

• Dificuldade de administrar múltiplas alterações concorrentes.

Várias empresas se esquecem de considerar o risco de perda de capital

humano e o risco da solução parar de funcionar de uma hora para outra. Outro erro

comum é esquecer-se de considerar a oportunidade de investir em novas

tecnologias que oferecem um custo de manutenção menor e têm o potencial de

agregar mais valor em todo sistema, em especial no aspecto de usabilidade (DINIZ,

2010).

O número de sistemas que precisa ser modificado está aumentando

gradualmente, existe fila de espera para pedidos de manutenção. Assim fica claro

que às vezes é impossível para as organizações investirem em novos sistemas para

melhorar a eficiência organizacional (DINIZ, 2010).

O problema de manutenção de software legado é complexo, pois esses

sistemas não são simples programas, desenvolvidos e mantidos, a maioria é

composta de outros diferentes programas que, de alguma forma compartilham dados

(DINIZ, 2010).

Empresas com o problema de software legado devem capacitar seus gerentes

em reengenharia de software. Isso vai garantir não só que os gerentes tomem uma

atitude em relação ao software legado como também vai contribuir para uma

execução eficaz e eficiente do processo de migração. Para resolver esses

problemas é importante partir da etapa de conhecer as novas tecnologias, estudar

sobre novas linguagens, novos servidores de aplicação e novas arquiteturas e

investir em treinamento do corpo técnico (DINIZ, 2010).

4.5 CUSTO

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

custo de manutenção. O cálculo do custo de manutenção do software legado em

geral é equivocado, pois não “levam” em conta os riscos envolvidos na sua

permanência (YOURDON, 1990).

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

(YOURDON, 1990).

Page 55: MONOGRAFIA: Reengenharia em Software Legado

55

Os custos da reengenharia dependem da extensão do trabalho que é realizado

(figura 14), a partir da complexidade de cada processo, consequentemente o custo

aumenta. O processo de reengenharia nem sempre sai mais barato que a

implantação de um novo sistema, contudo a reengenharia é a medida mais cabível

(MARI, 2008).

Figura 14 - Custo da reengenharia Fonte: BORGES, 2007

O custo envolve a qualidade do software que vai sofrer reengenharia; as

ferramentas disponíveis para fazer o processo de reengenharia; a quantidade de

dados que deverão passar por reengenharia de dados e também a disponibilidade

de pessoal habilitado (MARI, 2008).

O objetivo é aumentar os lucros, elevando a produtividade e diminuindo os

custos de produção, para tentar aumentar o mercado consumidor, que exige

qualidade e preços acessíveis (MARI, 2008).

A reengenharia reduz todos os tipos de desperdícios, reestruturando o

processo. Por exemplo: você corta uma folha de alumínio em tiras e, no final, sobra

uma tira que é menor que a largura necessária. Essa tira é jogada fora. Para encarar

novos desafios postos pela sociedade e pelo mercado, uma empresa precisa

repensar seus procedimentos operacionais. A meta é a de tornar as pessoas e as

máquinas mais eficientes. Assim será possível reduzir custos sem prejudicar

produtos e serviços (MARI, 2008).

A redução de custo é obtida através da eliminação de atividades que não

agregam valor ao produto e são dispensáveis no sistema (MARI, 2008).

É claro perceber que existe um mito se tratando do custo da reengenharia, pois

se tratando de nível à curto prazo, o custo será elevado pois acontecerá uma

reestruturação do sistema, mudanças geram gastos. Contudo, a nível de longo prazo

Page 56: MONOGRAFIA: Reengenharia em Software Legado

56

trará muitas vantagens, uma vez que o gasto com manutenção e mão de obra

específica não será um gasto decorrente nos próximos anos, a solicitação de

manutenção será menor (YOURDON, 1990).

4.6 FERRAMENTAS DE AUXÍLIO À REENGENHARIA

Existem ferramentas com a finalidade de auxiliar a execução da reengenharia.

A maioria das ferramentas é utilizada na etapa de engenharia reversa do sistema a

ser reconstruído (PRESSMAN, 2006).

As ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma

classificação que abrange todas as ferramentas baseada em computadores que

auxiliam atividades de engenharia de software, desde análise de requisitos e

modelagem até programação e testes. Podem ser consideradas como ferramentas

automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma

ou várias etapas do ciclo de desenvolvimento de software (JANONES, 2010).

O objetivo das ferramentas CASE, é a melhoria da qualidade de software, aumento da produtividade no processo de software, agilizar o tempo para tomada de decisão, menor quantidade de códigos de programação, melhoria e redução de custos na manutenção, agilidade no retrabalho do software, entre outras (JANONES, 2010).

As ferramentas baseadas em engenharia reversa estão ainda “engatinhando”,

ficando claro que as pesquisas na área de entendimento de código são muito

importantes e muitas outras pesquisas ainda acontecerão (PRESSMAN, 2006).

As ferramentas devem ser adequadas aos processos de reengenharia, e não

os processos adequados às ferramentas. As ferramentas de suporte disponíveis

para auxiliar a reengenharia têm influência sobre os custos de reengenharia

(PRESSMAN, 2006).

Existem muitas ferramentas de reengenharia com aplicabilidade em sistemas

de software. O quadro 1 apresenta várias dessas ferramentas, mostrando de onde

provêm as informações de entrada e o que cada uma delas produz como resultado

(PRESSMAN, 2006).

O escopo das informações que cada ferramenta utiliza é proveniente do código

fonte do software (cada ferramenta trabalha com código em determinada linguagem

pré-definida) e da base de conhecimento do sistema (constituída por documentação

Page 57: MONOGRAFIA: Reengenharia em Software Legado

57

existente, informações de usuários ou projetistas do software e bibliotecas de

componentes, entre outras) (PRESSMAN, 2006).

Em relação aos resultados produzidos, quando apenas o código fonte é

utilizado como entrada, as visões fornecidas são em nível implementacional e

estrutural. Para obtenção de visões mais abstratas (funcional e de domínio), bem

como outras saídas, é necessário utilizar como entrada, além do código fonte, bases

de conhecimento sobre o sistema (PRESSMAN, 2006).

Quadro 1 - Ferramentas de reengenharia

Fonte: PIEKARSKI, 2000.

4.7 ESTUDO DE CASO (EXEMPLIFICAÇÃO)

Estudo de caso retirado da revista “Interdisciplinar Aplicada”, ano 2004, cujos

autores são: Eliana Domingues da Cruz Milev e Francisco de Assis Zampirolli.

Segue a baixo o estudo de caso.

Page 58: MONOGRAFIA: Reengenharia em Software Legado

58

Esta seção apresenta o estudo de caso da substituição de um módulo de um

sistema de software denominado “Classificados”, utilizado em uma empresa

jornalística brasileira, que para fins desse trabalho será chamada J. Papel. Para que

esse sistema atenda os objetivos da empresa, vários módulos relacionados entre si

trabalham juntos. Esses módulos são fortemente interligados, o bom funcionamento

de um módulo muitas vezes depende do funcionamento dos demais módulos do

sistema.

Esse estudo se aplica à substituição do componente ou de “Classificados”, que

é responsável pela captação de anúncios da empresa. O J. Papel tem grande parte

de seu lucro oriundo de venda de espaço para publicação de anúncios solicitados no

caderno de classificados do jornal. Nesse caderno são publicados anúncios pagos

pelos clientes com a finalidade de divulgar um produto ou serviço. Para a captação

de anúncios a empresa trabalha com duas soluções com tecnologias diferentes:

Telefones e balcões (LEGADO_TEL); e Agências de Publicidade (LEGADO_AGE).

4.7.1 Sistema LEGADO_TEL

Das duas soluções existentes, essa (LEGADO_TEL) é a mais antiga e

apresenta diversos problemas, como segue:

• Sistema pouco flexível, não parametrizado, qualquer alteração implica em

manutenção no código;

• Código escrito com linguagem obsoleta;

• Dificuldades em encontrar profissionais que dominem a linguagem;

• Não usa uma base de dados padrão e isso dificulta o desenvolvimento e

integração com outros sistemas e/ou módulos;

• Espaço de armazenamento de dados reduzido e a tecnologia empregada não

permitem ampliações;

• Hardware obsoleto e sem suporte pelo fabricante, portanto com custo elevado

para qualquer necessidade de troca;

• Restrições para aumento da capacidade de processamento sem a troca total

do sistema (limitado em memória e em processador);

• O sistema não tem recursos de visualização de anúncios em sua forma final,

característica importantíssima em sistemas de jornal;

Page 59: MONOGRAFIA: Reengenharia em Software Legado

59

• Inviável o desenvolvimento de interface online para captação de anúncios

utilizando navegadores da Internet.

4.7.2 O problema

A empresa J. Papel tem que acompanhar a evolução para se manter no

mercado e ainda ampliar seus negócios oferecendo facilidades e melhores serviços

aos seus anunciantes e leitores.

O alvo de modernização é o caderno de “Classificados”, ele é uma das

principais fontes de lucro para a empresa e deve ser modernizado graficamente com

uma melhor distribuição de segmento de mercado permitindo anúncios com cor, foto

e destaque de logomarca com melhores resultados para o anunciante. O sistema

LEGADO_TEL por se tratar de um sistema legado, não suporta essa modernização

gráfica e se torna um obstáculo para o crescimento da empresa.

No ano de 2003, a empresa entende que esse sistema é crítico para a

organização e que sua substituição é vital. Diante disso o J. Papel decide investir em

software.

4.7.3 Alternativas de soluções

A empresa possui duas alternativas: substituição do sistema por uma solução

completamente nova ou reengenharia do sistema legado com a substituição do

módulo de “Classificados”.

Desenvolver um software crítico para a empresa é uma decisão arriscada, pois

pode demorar meses e até anos para sua finalização. A empresa não tem esse

tempo, a concorrência de mercado ajuda a decidir pela segunda e mais confiável

alternativa: substituir o módulo integrando-o aos demais módulos do sistema de

“Classificados”.

Várias empresas trouxeram soluções, a escolhida foi uma empresa americana

que propôs uma solução utilizando ferramentas de desenvolvimento de acordo com

a adotada pelo J. Papel. A solução escolhida, no entanto, deve manter as

funcionalidades do sistema atual e ainda proporcionar todas as novas funções

oferecidas pelo novo produto. Para que esse resultado fosse possível, as

especificações do sistema atual devem ser elaboradas pela equipe do J. Papel

Page 60: MONOGRAFIA: Reengenharia em Software Legado

60

seguindo um cronograma construído baseado em funcionalidades de superfície sem

um aprofundamento detalhado nos processos envolvidos.

O sistema LEGADO_TEL e suas interfaces com outros módulos possuem uma

documentação desatualizada, e nessas condições para elaborar especificações

quando a documentação do sistema não existe ou não está atualizada, a

Engenharia Reversa do sistema em produção é uma das formas para documentar o

que está em funcionamento e a Reengenharia proporá o processo alternativo. Outra

forma é escrever as especificações com base no conhecimento da equipe envolvida.

Porém, face ao pouco tempo designado para essa atividade, a forma escolhida foi a

segunda, as especificações foram baseadas no conhecimento da equipe, o que

resultou em especificações pouco detalhadas que dificultaram o entendimento para

a empresa que oferecia a nova solução e esquecimento de especificações de

algumas interfaces interligadas ao módulo a ser substituído.

4.7.4 Problemas na substituição

A tentativa de integração da solução adotada ocorreu durante o ano de 2004,

porém os problemas encontrados foram muitos:

• Definição do cronograma imposto fora da realidade;

• Prazo de entrega da solução subdimensionado;

• Fase de levantamento extremamente curta não permitindo ao fornecedor da

solução o tempo suficiente para entender todos os processos e necessidades da

empresa;

• O levantamento pouco detalhado resultou em conhecimento insuficiente do

processo atual de produção;

• Novas funcionalidades foram solicitadas pela empresa que não existiam no

sistema antigo e também não constavam em especificações;

• A empresa precisa se adaptar ao novo sistema já que nem todas as

funcionalidades e regras estavam sendo atendidas;

• O novo módulo oferecia muitas funcionalidades que nem mesmo a equipe

contratada para a implantação sabia como utilizar ou adaptar para as necessidades

da empresa;

Page 61: MONOGRAFIA: Reengenharia em Software Legado

61

• A solução adotada foi construída baseada em parametrizações. Porém muitas

regras específicas de negócio da empresa não eram atendidas através de

parâmetros e exigia modificação no código do sistema;

• Preocupação tardia com as principais interfaces (entradas e saídas);

• A solução não estava sendo utilizada em nenhum outro jornal o que

impossibilitava ver o resultado do produto em uso em outras empresas;

• Localização/customização do sistema por ser um sistema desenvolvido em

outro país o tratamento dado ao código de endereçamento postal (CEP) precisou ser

modificado, pois o cadastro do CEP no Brasil difere do americano.

• Vendas realizadas com cartão de crédito, o sistema americano vende com

cartão de crédito apenas com pagamento a vista, o sistema original não previa

parcelamentos;

• Problemas de comunicação, o sistema foi escrito em inglês e os primeiros

testes com a área usuária foram complicados por não terem sido traduzidos na

língua portuguesa. Além disso, as telas e mensagens de erros e alertas foram sendo

traduzido na fase de testes, o que gerou traduções mal feitas e incompletas e

descontentamento dos usuários;

• Integração não estava totalmente pronta e com tantas modificações feitas na

última hora gerou instabilidade (travamento do sistema);

• Paralelo à substituição do sistema, uma grande mudança ocorria ao mesmo

tempo, a terceirização do serviço de suporte;

• Trabalhar com dois novos fornecedores, ao mesmo tempo foi extremamente

complicado. Em alguns problemas de ambiente, como instabilidade ou travamento

do sistema, o fornecedor do suporte alegava que o problema estava no software e a

empresa fornecedora da nova solução acreditava que o problema era de suporte, e

dessa forma o problema não era atendido com rapidez necessária;

• Mudanças de regras ditadas por usuários eram constantes durante a fase de

testes de sistema;

• Com tantas mudanças a apresentação de bugs era frequente;

• A existência de todos esses problemas gerou um clima de instabilidade e

conflitos na equipe e culminou na saída dos dois principais gestores do projeto, um

de cada empresa, o que prejudicou ainda mais o desempenho da equipe envolvida;

• Com a saída dos dois principais gestores, a responsabilidade passou a

gestores com alto conhecimento técnico, porém com pouco conhecimento dos

Page 62: MONOGRAFIA: Reengenharia em Software Legado

62

processos do sistema “Classificados” e com nenhum tempo para aquisição do

conhecimento.

Apesar de tantas dificuldades, ainda acreditava-se que a empresa poderia

corrigir e adaptar o sistema, pois até então apresentava problemas de código e

estrutura que poderiam ser corrigidos. Com tantos contratempos, a empresa

fornecedora da solução somente conseguiu imprimir um teste do caderno de

classificados as vésperas da finalização do prazo de entrega do produto, prazo que

já havia sido prorrogado três vezes. O produto gerado durante os testes de

aceitação apresentou uma série de problemas. A empresa contratante decidiu por

rescindir o contrato.

4.7.5 Solução alternativa

A substituição do sistema fracassou, mas a necessidade da empresa de

modernizar seu caderno de Classificados era ainda prioritária. Pressionados pela

área comercial que tinha um produto novo a lançar, a modernização de seu caderno

de Classificados, a gerência de informática decide adotar um plano B.

O plano B era muito mais simples e econômico para a empresa. A empresa

brasileira responsável pela solução do sistema LEGADO_AGE, que atende as

agências de publicidade, oferecia uma substituição do software com as mesmas

funcionalidades do software da primeira solução escolhida e ainda uma opção para

o lançamento do novo produto.

No entanto, o plano B somente foi aprovado pela diretoria e áreas usuárias

porque a equipe que representava a fornecedora brasileira possuía profundo

conhecimento do sistema legado que seria adaptado para o lançamento do novo

produto e futuramente substituído. Além do conhecimento, a fornecedora brasileira

tranquilizou os representantes do J. Papel com um protótipo do caderno de

Classificados modernizado antes mesmo da aprovação do projeto.

Enfim, a solução oferecida tornou possível o lançamento do novo produto e o

lançamento do novo caderno de Classificados foi um sucesso e citam-se os

principais motivos que levaram a isso:

• O J. Papel decide pela adoção do Plano B, tendo em mãos um protótipo do

resultado final, ou seja, um teste com o caderno de Classificados modernizado de

acordo com as especificações da área comercial;

Page 63: MONOGRAFIA: Reengenharia em Software Legado

63

• O J. Papel designa um novo gestor com profundo conhecimento do sistema

de Classificados e das regras de negócio da empresa para gerenciar o plano B;

• A empresa contratada também tem conhecimento do sistema existente e das

regras de negócio específicas do J. Papel e efetua um levantamento preciso de

todos os processos afetados com a modificação;

• O cronograma imposto é rejeitado e após o planejamento é apresentado um

cronograma dentro da realidade;

• Prazo de entrega proposto é aceito pelas áreas Comercial e Tecnologia da

Informação;

• Todas as interfaces (entradas e saídas) são cuidadosamente analisadas e

suas modificações planejadas com antecedência;

• Todas as adaptações necessárias para a modificação dos processos são

efetuadas;

• Por ser um produto nacional, os problemas decorrentes de localização e

customização do sistema não ocorreram;

• Toda e qualquer mudança de regra foi cuidadosamente analisada antes de

ser aceita, recusada ou adiada;

• Comunicação facilitada, utilizando o idioma nativo.

4.6.6 Considerações finais

O estudo de caso relata dois experimentos de manutenção de software na qual

a empresa (denominada neste artigo por “J. Papel”) possuía duas alternativas:

substituição do sistema por uma solução completamente nova ou reengenharia do

sistema legado com a substituição do módulo de “Classificados”. A opção escolhida

foi a segunda.

A primeira tentativa de reengenharia fracassou, e os motivos do fracasso, são

explicáveis, uma vez que os processos não foram bem aplicados. No momento em

que deveria aplicar a “engenharia reversa” foi optado pelo caminho de

parametrização, e este fez perder regras específicas de negócio. Não houve um

melhor detalhamento dos processos anteriores no qual resultou na perca de

processos de produção importantes. A definição de prazos não foi estruturada e

ocasionou desorganização em todos os setores.

Page 64: MONOGRAFIA: Reengenharia em Software Legado

64

Entre outros problemas que aconteceram e que é detalhado no estudo de caso,

é imprescindível dizer, que quando os processos de reengenharia não são bem

feitos o resultado é o fracasso. Muitos gestores de TI temem a reengenharia por

medo de um dos processos falharem e acabar prejudicando todo o resto.

A segunda tentativa obteve sucesso principalmente porque foi executado por

uma empresa que conhece o ramo jornalístico e possui em sua equipe pessoas

treinadas para trabalhar no sistema LEGADO_TEL, pois já oferecia suporte para

outro componente de software da empresa J. Papel. Outros fatores que

influenciaram no sucesso deste segundo experimento foram usar técnicas de

reengenharia para obter a documentação do sistema existente, bem como seguir um

modelo de padronização de manutenção.

Mediante estudo de caso é comprovado que a reengenharia aplicada de forma

correta, seguindo todos os processos de forma coerente, as chances de dar certo é

quase 100%. Porém se a mesma for feita “pelas metades” o seu fracasso é imediato,

resultando em um custo ainda maior.

Vale lembrar que quando o software legado possuiu regras específicas de

negócios, que nenhum outro software possui, o melhor caminho é optar pela

reengenharia do mesmo. Porém se existir um software no mercado que supra todos

os requisitos e funcionalidades, implantar um novo software pode ser a melhor

solução viável.

Page 65: MONOGRAFIA: Reengenharia em Software Legado

65

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

Deixando bem claro seus processos, vantagens, desvantagens, custos, usabilidade

e definições. O estudo de caso foi muito importante para “ilustrar” tudo dito

anteriormente.

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.

A segunda parte da pesquisa de campo foi de cunho quantitativo, a mesma é

um questionário realizado pela empresa de consultoria Deloitte & Touche, voltado

para as 500 maiores empresas portuguesas (segundo a revista Exame), em que visa

mostrar a visão do gerente de TI dentro do diversos “tópicos” da reengenharia em

uma organização.

Ter como parâmetro uma pesquisa qualitativa e outra quantitativa faz enfatizar

o objetivo inicial do trabalho e dar sustância à ideia de que é preciso pensar no

software como um otimizador de processos.

5.1 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 01

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?

SAKAI: Sim, em diversas instituições financeiras.

Page 66: MONOGRAFIA: Reengenharia em Software Legado

66

Se sim, discorra sobre os principais pontos. Levando em consideração

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

SAKAI: 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

Page 67: MONOGRAFIA: Reengenharia em Software Legado

67

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.

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

Page 68: MONOGRAFIA: Reengenharia em Software Legado

68

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.

Atualmente, reengenharia é a melhor solução para software legado?

SAKAI: A mesma resposta da questão anterior se aplica aqui. Reengenharia

apenas para sistemas críticos que não podem ser substituídos por soluções de

mercado.

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.

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.

Os gerentes de TI estão preparados para aceitar o processo de reengenharia?

SAKAI: Um gerente de TI da área de Desenvolvimento tende a adorar um projeto de

reengenharia – gerentes de infraestrutura podem gostar (em situações onde a

reengenharia permitiria uma revisão dos ambientes tecnológicos) ou não (em

Page 69: MONOGRAFIA: Reengenharia em Software Legado

69

situações onde a reengenharia altera os procedimentos operacionais e de

produção).

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.

A seguir estão os principais pontos que devem ser discutido mediante

entrevista:

Mediante entrevista, é possível perceber que ás vezes 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 da entrevista 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 pensar no que fazer, seja passar por um processo de

reengenharia ou buscar algo novo no mercado.

Page 70: MONOGRAFIA: Reengenharia em Software Legado

70

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

Foram usados dois termos na entrevista que merecem uma definição, para

melhor entendimento da resposta, são eles:

• Downsizing: em português significa “achatamento”, é uma técnica conhecida

em todo o mundo e que visa a eliminação de processos desnecessários que

engessam a empresa e atrapalham a tomada de decisão, com o objetivo de criar

uma organização mais eficiente e enxuta possível.

• Regime 24x07: é uma abreviação que significa "24 horas por dia, 07 dias por

semana", geralmente se referindo a um negócio ou serviço disponível o tempo todo,

sem interrupção.

5.2 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 02

Apesar de ser um conceito relativamente recente, a reengenharia parece já ter

chegado até nós, ao ponto de já estar a produzir resultados. Assim, e de acordo com

um estudo realizado pela empresa de consultoria Deloitte & Touche (2000), com as

500 maiores empresas Portuguesas (segundo a revista Exame) estas pareciam já

estar a par deste conceito. O questionário está disponível no ANEXO A desta obra.

De acordo com pesquisa 84% dos gerentes de TI sabem ou já ouviram falar

sobre reengenharia, contra 16% que não tinham conhecimento. Como mostra o

gráfico um (1) abaixo:

Gráfico 1 – O que é reengenharia Fonte: Deloitte & Touche

Page 71: MONOGRAFIA: Reengenharia em Software Legado

71

Dessas empresas, 43% já tinham implementado projetos de reengenharia e

55% estavam em fase de implementação. Apenas 2% ainda não tinham implantado.

Conforme o gráfico dois (2):

Gráfico 2 – Implementação de projeto Fonte: Deloitte & Touche

Muitos dos programas ditos de reengenharia não são de fato. Este é, aliás, um

dos motivos de insucesso de alguns programas de pseudo reengenharia. Em

relação ao futuro, as perspectivas indicam que 62% das empresas inquiridas

pretendem avançar com novos projetos, contra 38%. Representado no gráfico três

(3) a seguir:

Gráfico 3 – Avanço com novos projetos Fonte: Deloitte & Touche

E destes, que tencionam avançar com novos projetos de reengenharia, a

grande maioria, 88% espera implementá-los no próximo ano. Gráfico quatro (4),

abaixo:

Gráfico 4 - Planejamento de um novo projeto de reengenharia Fonte: Deloitte & Touche

Page 72: MONOGRAFIA: Reengenharia em Software Legado

72

Em relação aos motivos que levaram a aplicar a reengenharia, chama atenção

o fato de 35% dos gerentes de TI alegarem “os custos demasiado elevados”, ponto

este tratado na pesquisa bibliográfica, uma vez que manter o software legado é

muito custoso para uma organização. Com 16% segue a “perda de competitividade”

onde um software melhor estruturado, têm uma performance elevada em relação ao

legado. É de suma relevância destacar os 10% na “diminuição de lucros”, na qual

comprova o quanto o legado é importante no que diz respeito a negócios e que o

mesmo acarreta perda de lucro. De acordo com gráfico cinco (5) abaixo:

Gráfico 5 – Motivos da aplicação da reengenharia Fonte: Deloitte & Touche

O nível de satisfação em relação ao pós-reengenharia atinge 68%, não

havendo nenhum registro de caso de grande insatisfação. Conforme gráfico seis (6):

Gráfico 6 – Grau de satisfação Fonte: Deloitte & Touche

De acordo com o gráfico sete (7), 42% dos processos que foram objetos de

reengenharia foram os processos operacionais, seguidos 38% por processos infra

estruturais e 20% toda a organização, o que eleva a preocupação com o legado em

um todo.

Page 73: MONOGRAFIA: Reengenharia em Software Legado

73

Gráfico 7 – Processos objetos de reengenharia Fonte: Deloitte & Touche

No gráfico oito (8) foi possível perceber que 36% das empresas implementaram

programas de reengenharia recorrendo apenas a recursos internos. Para além de

que 8% conseguiram o mesmo recorrendo apenas a consultores externos.

Gráfico 8 - A quem foi recorrido para o processo de reengenharia Fonte: Deloitte & Touche

Assim, de acordo com as respostas recebidas nenhuma empresa tenciona usar

apenas os consultores externos em próximos projetos, os seja, pretendem buscar

equipes mistas (88%). Conforme gráfico nove (9):

Gráfico 9 – Planos para recorrer no futuro Fonte: Deloitte & Touche

Relativamente às maiores dificuldades na implementação da reengenharia,

numa escala de 1 a 5, os empresários que participaram do estudo, referiram mais

frequentemente a "resistência à mudança", as "perspectivas irrealistas" e as

"limitações dos sistemas informáticos existentes". A resistência à mudança é um

Page 74: MONOGRAFIA: Reengenharia em Software Legado

74

ponto muito questionado, pois o usuário tem muita dificuldade de aceitar o novo,

mesmo este trazendo diversas vantagens perspectiveis ou não para o mesmo.

Gráfico 10 – Dificuldades na implementação da reengenharia Fonte: Deloitte & Touche

É possível concluir, que os gestores portugueses são grandes entusiastas da

reengenharia e que os graus de conhecimento e satisfação são esmagadoramente

positivos.

Não há duvida que seja necessário repensar a forma de funcionamento das

organizações. As constantes mutações a que assistimos obrigam a um novo tipo de

organizações, mais flexíveis, mais ágeis, que respondam de forma mais adequada

às solicitações do mercado.

O processo de reengenharia pode contribuir para isso, contudo é necessário

estarmos conscientes que a reengenharia não resolve todos os problemas, ainda

menos quando é mal interpretada e aplicada.

Muitas empresas prosseguiram o mito da reengenharia através da mera

simplificação de processos ou, na maioria dos casos, de uma automatização dos

processos existentes. Este equívoco provocou, em alguns casos, uma diminuição da

competitividade, uma vez que à maioria destes projetos estiveram associados

grandes investimentos que, ou diminuíram a capacidade financeira das empresas ou

provocaram um acentuado endividamento.

Desta forma, é cada vez mais importante que as empresas concentrem os seus

esforços em processos de mudança que sejam realmente capazes de alcançar o

aumento de produtividade necessário para assegurar a sua sobrevivência.

Page 75: MONOGRAFIA: Reengenharia em Software Legado

75

CONCLUSÃO

Mediante estudo é possível concluir que a forma de realizar a reengenharia em

software legado, depende de muitos fatores, relacionados, por exemplo, com a

forma de trabalho da empresa, a origem do software em questão e o

desenvolvimento de tecnologias.

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 algum software no mercado que

faz todas as funções do software legado e com um custo reduzido, a melhor opção

seria sim, implantar este novo 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.

Page 76: MONOGRAFIA: Reengenharia em Software Legado

76

REFERÊNCIAS

BENNETT, K. H; WARD, M. P. Suporte Automatizado de Manutenção de Software, 1991. ______. Métodos Formais para sistemas legados, 1995. 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. CAGNIN, Maria Istela. Parfaite, uma contribuição para a reengenharia de software baseada em linguagens de padrões e frameworks, 2005. CHIKOFSKY, E. J.; CROSS, J. H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, 1990. COLEMAN, D.; ARNOLD, P. Desenvolvimento Orientado a Objetos: O método de fusão, 1994. CORDEIRO, Edson dos Santos. Introdução a Ciclo de Vida do Software, 2012. DALMASO, Alanderson. Crise do software, 2013. DINIZ, Samuel. O problema do software legado. Disponível em: <http://blogdosamueldiniz.blogspot.com.br/2010/02/o-problema-do-softwarelegado.html>. Acesso em: 19 Fev. 2013. HAMMER, M.; CHAMPY, J. Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e das grandes mudanças da gerencia. Rio de Janeiro: Campus, 1994. HARANDI, M.; NING, J. Q. Knowledge-Based Program Analysis: IEEE Software, 1990. JALOTE, P. Uma abordagem integrada para Engenharia de Software. 3. ed. New York: Springer, 2005. JANONES, Ramos de Sousa. Qualidade de Software: Uma questão de eficiência, 2010. LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution, 1985.

Page 77: MONOGRAFIA: Reengenharia em Software Legado

77

LEMOS, Gizelle Sandrini. Padrões de reengenharia auxiliados por diretrizes de qualidade de software, 2003. LOVATTO, Robinson. Estudo de viabilidade sobre a migração de um sistema Oracle forms 6i para um ambiente web, 2012. MARI, Charles Roberto Boeing. Reengenharia de Software: Estudo de Caso em um Sistema de Automação, 2008. MARTINS, Márcia M. G. Gerenciamento de Serviços de TI – Uma Proposta de Integração de Processos de Melhoria e Gestão de Serviços, 2006. MAZZANTI, Eduardo Spolaor. Técnicas de reengenharia de software aplicadas em uma ferramenta de representação 3D da distribuição de cores de imagens digitais, 2008. MECELLA, Massimo. Integração de sistemas de informação legados altamente fragmentados através de modelagem de objetos e em camadas, 1999. MEDEIROS, Teresa Maria Maciel de. Introdução à engenharia de software e à qualidade de software, 2006. MELO, Tiago Eugênio de. Engenharia de Software: conceitos e aplicações, 2007. MILEV, Eliana Domingues da Cruz; ZAMPIROLLI, Francisco de. Revista Interdisciplinar Aplicada: Estudo de Caso em Manutenção de Software, 2004. MONTEIRO, Mario A. Introdução a organização de computadores, 2007. OSBORNE, W. M.; CHIKOFSKY, E. J. Manutenção de software, 1990. PARREIRA, Walteno Martins. Apostila engenharia de software, 2006. PEGO, Paulo Cesar Batista. Critério de Avaliação de sistemas Legados, 2010. PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004. 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. PINTO, Herbert Laroca Mendes. Sistemas legados e as novas tecnologias: técnicas de integração e estudo de caso, 2004. PRESSMAN, Roger S. Engenharia de Software. 1. ed. São Paulo: Makron, 1995. ______. ______. 5. ed. Rio de Janeiro: Mc GrawHill, 2002. ______. ______. 6. ed. Rio de Janeiro: McGraw-Hill, 2006.

Page 78: MONOGRAFIA: Reengenharia em Software Legado

78

RAMOS, Cristiane Soares; OLIVEIRA, Kathia Marçal de. Conhecendo Sistemas Legados através de Métricas de Software, 2008. SANTOS, Pedro de Alcântara dos. Introdução à engenharia de software, 2005. SILVA, Roberto Andrade de. Migração e Integração de Sistemas Legados, 2005. SOMMERVILLE, Ian. Engenharia de Software. 4. ed. São Paulo: Addison-Wesley, 1992. ______. ______. 6. ed. São Paulo: Addison Wesley, 2003. STEVENS, P.; POOLEY, R. Sistemas de Padrões de Reengenharia, 1998. VASCONCELOS, Aline Pires Vieira de. Uma abordagem de apoio à criação de arquiteturas de referência de domínio baseada na análise de sistemas legados. Rio de Janeiro: UFRJ, 2007. VERZELLO, Robert J. Processamento de dados. São Paulo: McGraw-Hill, 1984. WARREN, Ian. Um método para avaliar Sistemas Legados para a Evolução, 1998. YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Editora Campus, 1990. 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.

Page 79: MONOGRAFIA: Reengenharia em Software Legado

79

ANEXO A – INSTRUMENTO DE COLETA DE DADOS

Page 80: MONOGRAFIA: Reengenharia em Software Legado

80

ANEXO A – INSTRUMENTO DE COLETA DE DADOS

Entrevista elaborada com a finalidade de captar uma visão mais ampla do

processo de reengenharia em software legado, no ponto de vista de um gerente de

TI (tecnologia da informação).

1- Você já teve oportunidade de participar do processo de reengenharia de software? 2- Se sim, discorra sobre os principais pontos. Levando em consideração adaptação dos usuários, melhorias, custos, vantagens e desvantagens. 3- O que levou/leva a empresa a passar pelo processo de reengenharia no software? 4- Quais são os principais aspectos que um gestor de TI precisa avaliar se tratando do “software”? 5- Quais são os principais motivos que levam ao “abandono” do software legado? 6- No processo de reengenharia o risco de perder funcionalidades do software legado ainda existe, quais são as medidas para tal acontecimento? 7- Você utiliza algum modelo para desenvolvimento do projeto de reengenharia ou adapta algum modelo? 8- O processo de reengenharia de software pode ser a “solução” dos problemas dos softwares legados? 9- Atualmente, reengenharia é a melhor solução para software legado? 10- Qual é o momento de aplicar a reengenharia no software. Quais aspectos contribuem para isso? 11- Qual o papel do gerente de TI, na gestão e qualidade do software? 12- Qual é a visão pós-reengenharia? 13- Os gerentes de TI estão preparados para aceitar o processo de reengenharia? 14- 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).

Page 81: MONOGRAFIA: Reengenharia em Software Legado

81

Questionário elaborado pela empresa de consultoria Deloitte & Touche,

direcionado para às 500 maiores empresas Portuguesas (segundo a revista Exame)

com a finalidade de captar dados junto aos gestores de TI sobre as diversas faces

da Reengenharia.

1- Você sabe o que é reengenharia? ( ) Sim ( ) Não 2- Já implementou algum projeto de reengenharia? ( ) Em implementação ( ) Implementados ( ) Não 3- Pretende avançar com novos projetos? ( ) Sim ( ) Não 4- Para quando planeja começar o projeto de reengenharia? ( ) Nos próximos 6 meses ( ) Entre 6 meses a 1 ano ( ) Entre 1 ano a 2 anos 5- O que levou a aplicar a reengenharia? ( ) Redução de quota de mercado ( ) Não cumprimento dos prazos de entrega ( ) Custos demasiado elevados ( ) Fraca qualidade dos produtos/serviços ( ) Fraco serviço aos clientes ( ) Diminuição de lucros ( ) Perda de competitividade ( ) Outras 6- Qual foi o grau de satisfação obtido? ( ) Muito satisfeito ( ) Satisfeito ( ) Insatisfeito ( ) Muito insatisfeito ( ) Ainda a decorrer 7- Quais os processos que foram objeto de reengenharia? ( ) Toda a organização ( ) Processos operacionais ( ) Processos infra estruturais 8- A quem foi recorrido para o processo de reengenharia? ( ) Consultores externos ( ) Recursos internos

Page 82: MONOGRAFIA: Reengenharia em Software Legado

82

( ) Equipes mistas 9- A quem tenciona recorrer no futuro? ( ) Equipes mistas ( ) Recursos internos 10- Quais foram as principais barreiras? ( ) Limitação dos sistemas informáticos ( ) Resistência à mudança ( ) Inexistência de equipes de projeto multifuncionais ( ) Inexistência de um líder de projeto ( ) Envolvimento demasiado tardio do pessoal de SI ( ) Qualificações inadequadas da equipe de projeto ( ) Expectativas irrealistas