MONOGRAFIA: Reengenharia em Software Legado

CENTRO UNIVERSITRIO DO ESPRITO SANTO UNESC
LUCIANA PONCHE DIAS

REENGENHARIA EM SOFTWARE LEGADO

COLATINA
2013

LUCIANA PONCHE DIAS


Trabalho de Concluso de Curso
apresentado ao Centro Universitrio do
Esprito Santo UNESC, sob orientao
da professora Priscila de Almeida Prata,
para obteno do Ttulo de Bacharel em
Sistemas de nformao.

COLATINA
2013

LUCIANA PONCHE DIAS


Trabalho de Concluso de Curso
apresentado ao Centro Universitrio do
Esprito Santo UNESC, para obteno
do Ttulo de Bacharel em Sistemas de
nformao.

ORIENTADOR

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

AVALIADOR

Professor do UNESC

Nota

Colat!a" ###### $% ################## $% 2013&

Dedico este trabalho a Deus por ter me
concedido a graa de concluir mais uma
etapa de minha caminhada com sucesso.
A meus pais, por todo esforo, pelo
carinho, amor e educao !ue muito
contribu"ram na minha formao. A minha
irm por sempre acreditar em meu
potencial e no dei#ar desistir. A meus
amigos e familiares !ue sempre esti$eram
ao meu lado para me apoiar.

Agradeo a minha orientadora, a
professora Priscila de Almeida Prata, pela
dedicao e doao de conhecimentos
dispensados para a elaborao desse
trabalho. Ao professor %eraldo Ce&ar
Seidel Dalla 'ernardina, pela moti$ao e
entusiasmo.
Ao gerente de () *ei+i Sa,ai, !ue aceitou
ser entre$istado e !ue muito contribuiu
para o -enri!uecimento. do trabalho,
apesar de todos os impre$istos ao longo
da pes!uisa.

(ente uma, duas, tr/s $e&es e se poss"$el
tente a !uarta, a !uinta e !uantas $e&es
for necess0rio.
S1 no desista nas primeiras tentati$as, a
persist/ncia 2 amiga da con!uista.
Se $oc/ !uer chegar aonde a maioria no
chega, faa o !ue a maioria no fa&.

Bill Gates
RESUMO

Trata da proposta de aplicao da reengenharia em software legado, bem como as
vantagens e desvantagens, tendo como critrio os custos, funcionalidades e
desempenho. Um software legado que passa pelo processo de reengenharia e
consequentemente por engenharia reversa no perde suas funcionalidades, ao
contrrio, ele passa por um novo processo de codificao, estruturao,
documentao, visando uma melhor qualidade do software. Atravs de pesquisa
bibliogrfica so exemplificadas as diretrizes que levam necessidade de aplicar a
reengenharia em software legado, bem como a importncia da mesma dentro da
organizao. Atravs da pesquisa qualitativa, foi feito uma entrevista com um
gerente de T, que j passou por diversos processos de reengenharia em software
legado. Mediante pesquisa quantitativa, foi feito uma anlise de um questionrio
distribudo para 500 gestores de T referente reengenharia em software legado. As
mesmas foram de grande relevncia para o trabalho, uma vez que todos os tpicos
abordados na pesquisa bibliogrfica sero "autenticados. Conclui-se que
atualmente a necessidade de aplicar a reengenharia cada vez maior e que a
mesma contribui de maneira imprescindvel nos processos organizacionais, porm
por ser de tamanha complexidade, preciso fazer um estudo detalhado de custos e
necessidades.

Pala'(a)*+,a'%- reengenharia, legado, software, engenharia, manuteno.
LISTA DE FIGURAS

Figura 1 Trip da engenharia de software ......................................................... 17
Figura 2 Modelo cascata .................................................................................... 22
Figura 3 Modelo prototipao ............................................................................. 23
Figura 4 Modelo espiral ...................................................................................... 24
Figura 5 Modelo em camadas de um software legado ...................................... 29
Figura 6 Nveis lgicos de sistemas computacionais ......................................... 30
Figura 7 Qualidade de sistema e valor de negcio ............................................ 32
Figura 8 Distino 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 Visualizaes de software no ciclo de desenvolvimento ................... 46
Figura 13 Processo de reestruturao de programa .......................................... 48
Figura 14 Custo da reengenharia ....................................................................... 55

LISTA DE .UADRO

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

SUMRIO

NTRODUO ...................................................................................................... 12
1 SOFTWARE ....................................................................................................... 13
1.1 EVOLUO DO SOFTWARE ......................................................................... 13
1.2 CLASSFCAO ............................................................................................ 15
1.3 CRSE DO SOFTWARE .................................................................................. 15
2 ENGENHARIA DE SOFTWARE ........................................................................ 17
2.1 PROCESSO/CCLO DE VDA DO SOFTWARE ............................................. 18
2.2 MODELOS DE CCLO DE VDA ..................................................................... 20
2&2&1 C+lo $% '$a +l/))+o 01o$%lo +a)+ata2 ........................................... 21
2&2&2 P(otot3a45o .............................................................................................. 22
2&2&3 Mo$%lo %)3(al ............................................................................................ 24
3 SOFTWARE LEGADO ...................................................................................... 26
3.1 EVOLUO PARA O LEGADO ...................................................................... 27
3.2 ARQUTETURA ............................................................................................... 28
3.3 NVEL LGCO ............................................................................................... 30
3.4 AVALAO .................................................................................................... 31
3.5 MANUTENO ............................................................................................... 33
3.6 PROBLEMAS COM O LEGADO ..................................................................... 35
6 REENGENHARIA DE SOFTWARE ................................................................... 37
4.1 RELACONAMENTOS NO CCLO DE DESENVOLVMENTO ....................... 39
4.2 PROCESSO DE REENGENHARA DE SOFTWARE ..................................... 41
6&2&1 T(a$745o $% +8$9o*:o!t% ......................................................................... 43
6&2&2 E!9%!,a(a (%'%()a .................................................................................... 44
4.2.2.1 Vises de software .................................................................................... 46
6&2&3 M%l,o(a $a %)t(7t7(a $o 3(o9(a1a .......................................................... 47
6&2&6 Mo$7la(;a45o $% 3(o9(a1a ...................................................................... 48
6&2&< R%%!9%!,a(a $% $a$o) ............................................................................. 49
4.3 VANTAGENS DA REENGENHARA .............................................................. 50
4.4 DFCULDADES NO PROCESSO DE REENGENHARA .............................. 52
4.5 CUSTO ............................................................................................................ 54

4.6 FERRAMENTAS DE AUXLO REENGENHARA ....................................... 56
4.7 ESTUDO DE CASO (EXEMPLFCAO) ..................................................... 57
6&=&1 S)t%1a LEGADO#TEL .............................................................................. 58
6&=&2 O 3(o>l%1a ................................................................................................. 59
6&=&3 Alt%(!at'a) $% )ol74?%) ........................................................................... 59
6&=&6 P(o>l%1a) !a )7>)tt745o ........................................................................ 60
6&=&< Sol745o alt%(!at'a .................................................................................... 62
6&=&@ Co!)$%(a4?%) :!a) ................................................................................. 63
< METODOLOGIA ................................................................................................ 65
5.1 COLETA E DSCUSSO DOS RESULTADOS - PARTE 01 .......................... 65
5.2 COLETA E DSCUSSO DOS RESULTADOS - PARTE 02 .......................... 70
CONCLUSAO ....................................................................................................... 75
REFERBNCIAS ..................................................................................................... 76
ANECO A INSTRUMENTO DE COLETA DE DADOS ...................................... 79

12

INTRODUDAO

A variedade de problemas que envolvem manuteno de software cresce
constantemente, sendo que as solues no acompanham esta evoluo. A
reengenharia de software uma das estratgias da evoluo de software. Ocupa-se
de reimplementar sistemas legados, para que sua manuteno seja mais simples.
O grande dilema da reengenharia em software legado que junto ao software
legado existem informaes dos negcios e procedimentos que podem no estar
documentados. O risco de remover e reescrever tais programas so grandes, pois
muitas informaes teriam que ser descobertas por tentativa e erro.
Esta obra tem por objetivo, apresentar a importncia da reengenharia em
software legado, alm disso, deixar explcito os conceitos relevantes do processo,
vantagens, desvantagens e custo, visando pela qualidade do software.
Para desenvolvimento desta pesquisa, foram utilizadas referncias
bibliogrficas disponveis em livros, revistas, artigos, etc. Foi realizada uma pesquisa
de campo qualitativa atravs de uma entrevista com um gerente de T. Tambm foi
feito uma anlise de um questionrio distribudo para 500 gestores de T referente
reengenharia em software legado, de carter quantitativo.
Dar incio pesquisa de reengenharia em software legado relevante, pois
muitas empresas ainda mantm o software legado e a manuteno de sistemas
legados cada vez mais dispendiosa, e a reengenharia prolonga o tempo de vida
til do software. A reengenharia eficaz em termos de custo quando ele tem alto
valor de negcios, melhora a estrutura do sistema, cria uma nova documentao
relacionada e faz com que ela seja de mais fcil compreenso.

13

1 SOFTWARE

Uma descrio de software num livro didtico poderia assumir a seguinte
forma: "Software : (1) instrues (programas de computador) que, quando
executadas, produzem a funo e o desempenho desejados; (2) estruturas de dados
que possibilitam que os programas manipulem adequadamente a informao; e (3)
documentos que descrevem a operao e o uso dos programas" (PARRERA,
2006).
Entende-se que "software uma sequncia de instrues escritas para serem
interpretadas por um computador com o objetivo de executar tarefas especficas. Em
um computador, o software classificado como a parte lgica cuja funo fornecer
instrues para o hardware. O termo ingls "soft o antnimo de "hard e significa
"macio, ou seja, o hardware difcil de manipular e de alterar, enquanto o software
no (MONTERO, 2007).

1.1 EVOLUO DO SOFTWARE

Os softwares evoluem em resposta s exigncias de mudanas como, por
exemplo, correo de erros, melhorias no desempenho, migraes para novas
plataformas ou outras caractersticas (PRESSMAN, 2006).
Com o surgimento dos primeiros softwares, no se imaginava que o mesmo se
tornaria um elemento importante para o mundo e que teria capacidade de manipular
a informao. Com a ascenso computacional e as mudanas 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 dcadas de evoluo 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 dcadas o software evolui de uma ferramenta de anlise de informaes e
de resoluo de problemas especializados para uma indstria da programao
(SOMMERVLLE, 1992).
Em meados da dcada de 40, o desenvolvimento do software era feito
virtualmente, sem administrao at que os prazos comeassem a se esgotar e os
14

custos a subir. Durante este perodo, era usada orientao batch (em lote) para a
maioria dos sistemas. Na maior parte, o hardware dedicava-se execuo de um
nico programa que, por sua vez, dedicava-se a uma nica aplicao especfica. O
software era projetado sob medida para cada aplicao e tinha uma distribuio
relativamente limitada. Por causa desse ambiente de software personalizado o
projeto era um processo implcito realizado no crebro de algum e sem nenhuma
documentao (PRESSMAN, 1995).
Em meados de 1960 at o final de 1975 a multiprogramao e os sistemas
multiusurios introduziram novos conceitos de interao homem-mquina. As
tcnicas interativas abriram um novo mundo de aplicaes e novos nveis de
sofisticao de software e hardware. Sistemas de tempo real podiam analisar,
coletar e transformar dados de mltiplas fontes. Os avanos da armazenagem on-
line levaram primeira gerao de sistemas de gerenciamento de banco de dados
(PRESSMAN, 1995).
medida que o nmero de sistemas crescia, era crescente o nmero de falhas
que constantemente precisava ser corrigidas por exigncia dos usurios, essas
atividades foram chamadas de "manuteno de software". Esta constante
manuteno acarretou diversos problemas no desenvolvimento e avanos 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 comunicaes digitais de
largura de banda e a crescente demanda de acesso "instantneo" a dados exigiram
muito dos desenvolvedores de software. Tambm foi caracterizada pelo advento e o
generalizado uso de microprocessadores, computadores pessoais e poderosas
estaes de trabalho "Workstations" de mesa (PRESSMAN, 1995).
Atualmente as tecnologias orientadas a objetos esto ocupando o lugar das
abordagens mais convencionais para o desenvolvimento de software em muitas
reas de aplicao. Os sistemas especialistas e o software de inteligncia artificial
saram do laboratrio para a aplicao prtica em problemas de amplo espectro do
mundo real. O software de rede neural artificial abriu excitantes possibilidades para o
reconhecimento de padres e para capacidades de processamento de informaes
semelhantes s humanas (PRESSMAN, 1995).

15

1.2 CLASSFCAO

O software passa por constates classificaes e cada autor o classifica de
formas diferentes, seguindo critrios pr-estabelecidos. Seguindo como princpio a
classificao de Verzello, o software se classifica em trs tipos: Software de
Sistema, Software de Programao e Software de Aplicao (VERZELLO, 1984).
O Software de Sistema ou Sistema Operacional o conjunto de informaes
processadas pelo sistema interno de um computador que permite a interao entre
usurio e os perifricos do computador atravs de uma interface grfica. Engloba o
sistema operativo e os controladores de dispositivos (VERZELLO, 1984).
O Software de Programao ou Software de nfraestrutura o conjunto de
ferramentas que permitem ao programador desenvolver sistemas informticos,
geralmente usando linguagens de programao e um ambiente visual de
desenvolvimento integrado. Os Bancos de Dados, Dicionrios de Dados e Brokers
tambm so considerados Software de nfraestrutura, uma vez que permitem que se
escrevam sistemas inteiros utilizando o seu potencial (VERZELLO, 1984).
O Software de Aplicao so programas de computadores que permitem ao
usurio executar uma srie de tarefas especficas em diversas reas de atividade
como arquitetura, contabilidade, educao, medicina e outras reas comerciais. So
ainda os videojogos, sistemas de celulares, os sistemas de automao industrial,
etc. (VERZELLO, 1984).

1.3 CRSE DO SOFTWARE

Em meados de 1970 o termo "crise do software foi usado para expressar as
dificuldades do desenvolvimento de software frente ao rpido crescimento da
demanda por software, da complexidade dos problemas a serem resolvidos e da
inexistncia de tcnicas 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 comeou a
caminhar com o advento das linguagens estruturadas e modulares, tornou-se claro
que a indstria de software estava falhando repetidamente na entrega de resultados
dentro dos prazos, quase sempre estourando os oramentos e apresentando um
grau de qualidade duvidoso ou insatisfatrio (DALMASO, 2013).
16

Um relatrio em 1967 apresentou que, de 50% a 80% dos projetos no haviam
sido concludos e outros fracassados por no terem atingindo os objetivos
esperados, e dos que foram concludos, foram entregues acima do prazo estipulado
e o oramento 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 conferncia marcou assim o incio dessa nova rea na
computao. Esta reunio teve como principal objetivo estabelecer prticas mais
maduras para o processo de desenvolvimento, por esta razo 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 no se limitavam a
"sistemas que no funcionam corretamente", mas envolviam tambm
dvidas 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 tcnicas e medidas
pobres aplicadas sobre o processo e o produto, alm dos poucos critrios
de qualidade estabelecidos at ento (PRESSMAN, 2002).

Todos esses fatores exigiram respostas e mtodos que foram sendo
aprimorados e documentados, dando incio rea de Engenharia de Software. A
busca por eficincia e competncia 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, mtodos 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 preocupao com o que realmente o software deveria fazer ou se
era possvel executar "tal tarefa, a engenharia de software surgiu da necessidade
de se construir software com mais qualidade em menor tempo (SANTOS, 2005).

17

2 ENGENHARIA DE SOFTWARE

Uma primeira definio de engenharia de software foi proposta por Fritz Bauer
na primeira grande conferencia dedicada ao assunto: "O estabelecimento e uso de
slidos princpios de engenharia para que se possa obter economicamente um
software que funcione eficientemente com mquinas reais" (PARRERA, 2006).
A engenharia de software uma derivao da engenharia de sistemas e de
hardware. Ela abrange um conjunto de trs elementos fundamentais - mtodos,
ferramentas e procedimentos que possibilita ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construo
de software de alta qualidade produtivamente (PARRERA, 2006).
A Engenharia de Software busca prover a tecnologia necessria para
produzir um software de alta qualidade a um baixo custo. Os dois fatores
motivadores so essencialmente a qualidade e o custo. A qualidade de um
produto de software um parmetro cuja quantificao no 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 organizaes no encararem o desenvolvimento de software como um
projeto de verdade, assim, no aplicando procedimentos, mtodos e ferramentas
necessrias. Por conta disso, boa parte dos projetos fracassa (SANTOS, 2005).

F97(a 1 T(3E $a %!9%!,a(a $% )o:tFa(%
Fo!t%- MARTINS" 200@&

A engenharia de software baseada no trip: processos, pessoas e tecnologia
(figura 1). No adianta ter os melhores profissionais se no possuir boas tecnologias
para uso ou se no possuir um processo que guie o desenvolvimento de software.
18

Da mesma forma, no adianta possuir as tecnologias mais avanadas se as pessoas
no conseguem utiliz-las. Alm disso, mesmo que parea inconcebvel para alguns,
de nada adianta ter a melhor tecnologia e as melhores pessoas se no existe um
processo que guie as atividades dessas pessoas utilizando tais tecnologias. Existem
grande chances de ter problemas relacionados falta de controle ou
desorganizao, caso no tenha um processo que discipline as tarefas das pessoas
(PARRERA, 2006).

2.1 PROCESSO/CCLO DE VDA 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 existncia, desde a sua
concepo, at o seu desaparecimento. sso inclui uma srie de etapas, dentre elas:
a concepo, onde o produto idealizado, a partir da percepo de uma
necessidade; o desenvolvimento, a partir da identificao dos requisitos e sua
transformao em itens a serem entregues ao cliente; a operao, quando o produto
instalado para ser utilizado em algum processo de negcio, sujeita a manuteno,
sempre que necessrio; e a retirada, quando o produto tem sua vida til finalizada.
(MEDEROS, 2006).
No ciclo de vida de um software, a codificao, que representa a escrita do
programa utilizando alguma linguagem de programao, apenas uma parte do
ciclo de vida, embora muitos profissionais de informtica acreditem que essa seja a
nica tarefa relacionada ao desenvolvimento de software (MEDEROS, 2006).
O processo de software um guia de como um produto de software deve ser
construdo, do incio ao fim. A ligao est no fato que esse guia depende do modelo
de ciclo de vida utilizado. Existem vrios modelos e dependendo dele, as atividades
a serem executadas podem variar. Um processo um conjunto de passos
parcialmente ordenados, constitudos por atividades, mtodos, prticas e
transformaes, utilizados para atingir uma meta. Uma meta est associada a
resultados, que so os produtos resultantes da execuo do processo (MEDEROS,
2006).
Um processo deve ter uma documentao 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)
(MEDEROS, 2006).

19

A engenharia de software compreende um conjunto de etapas que engloba os
mtodos, ferramentas e procedimentos. Essas etapas frequentemente so citadas
como paradigmas da engenharia de software. Um paradigma de engenharia de
software escolhido tendo-se como base a natureza do projeto e da aplicao, os
mtodos e as ferramentas a serem usados, os controles e os produtos que precisam
ser entregues (PARRERA, 2006).
O processo de software um guia de como um produto de software deve
ser construdo, do incio ao fim. Este guia depende do modelo de ciclo de
vida utilizado. Um processo um conjunto de passos parcialmente
ordenados, constitudos por atividades, mtodos, prticas e transformaes,
utilizados para se atingir uma meta. Uma meta est associada a resultados,
que so os produtos resultantes da execuo do processo (PARRERA,
2006).

Os "mtodos proporcionam os detalhes de "como fazer" para construir o
software, envolvem um amplo conjunto de tarefas que inclui: planejamento com
estimativa de projeto, anlise de requisitos de software e de sistemas, projeto da
estrutura de dados, arquitetura de programa e algoritmo de processamento,
codificao, teste e manuteno. Os mtodos da engenharia de software na maioria
das vezes introduzem uma notao grfica ou orientada a linguagem especial e
introduzem um conjunto de critrios para a qualidade do software (PARRERA,
2006).
As "ferramentas de engenharia de software proporcionam apoio automatizado
ou semiautomatizado aos mtodos. Existem ferramentas para sustentar cada um
dos mtodos citados anteriormente. Quando as ferramentas so integradas de forma
que a informao criada por uma ferramenta possa ser usada por outra,
estabelecido um sistema de suporte ao desenvolvimento de software chamado de
CASE (PARRERA, 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 informaes sobre analise, projeto,
codificao e teste) para criar um ambiente de engenharia de software que
seja anlogo ao projeto auxiliado por computador/engenharia auxiliada por
computador para o hardware (PARRERA, 2006).

Os "procedimentos da engenharia de software constituem o elo para manter
junto os mtodos e as ferramentas, alavancando possibilidades para o
desenvolvimento racional e oportuno do software. A sequncia em que os mtodos
sero aplicados, os produtos que so exigidos com prazo para entrega
(documentos, relatrios, formulrios etc.), o marco de referncia que possibilitam aos
20

gerentes de software avaliar o progresso, os controles que ajudam a assegurar a
qualidade e a coordenar as mudanas definido pelos procedimentos (PARRERA,
2006).
Para seleo de um processo, e posterior iniciao de um projeto, necessrio
entender qual modelo de ciclo de vida ele utiliza. Um modelo de ciclo de vida pode
ser apropriado para um projeto, mas no ser apropriado para outro. necessrio
entender bem os conceitos relacionados para que as escolhas feitas sejam
baseadas em conhecimento e no no acaso (CORDERO, 2012).

2.2 MODELOS DE CCLO DE VDA

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
construo do produto (SANTOS, 2005).
Segundo SANTOS (2005) para detalhamento dos modelos de ciclo de vida,
necessrio entender os subprocessos (fluxos ou disciplinas) ligados s tarefas de
desenvolvimento. Os principais subprocessos so:
Requisitos: obteno do enunciado, completo, claro e preciso dos desejos,
necessidades, expectativas e restries dos clientes em relao ao produto a ser
desenvolvido.
Anlise: modelagem dos conceitos relevantes do domnio do problema, com
o intuito de verificar a qualidade dos requisitos obtidos e detalhar tais requisitos em
um nvel adequado aos desenvolvedores.
Desenho (ou projeto): definio de uma estrutura implementvel para um
produto, que atenda aos requisitos especificados.
mplementao: codificao das partes que compe o software, definidas no
desenho, utilizando as tecnologias selecionadas.
Teste: verificao dinmica das partes que constituem o software, utilizando
um conjunto finito de casos de teste, selecionados dentro de um domnio
potencialmente infinito, contra seu comportamento esperado.
A literatura cita vrios tipos de modelos de ciclo de vida de software. Dentre os
diversos modelos de ciclos de vida de software, pode-se citar: cascata, espiral,
21

prototipao, refinamento iterativo, ciclo de vida progressivo, desenvolvimento
incremental, entre outros (CORDERO, 2012).

2&2&1 C+lo $% '$a +l/))+o 01o$%lo +a)+ata2

O modelo clssico 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 rgido, menos
administrativo e o modelo mais antigo, porm o mais amplamente usado e
importante da engenharia de software. O modelo em cascata referncia 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
documentao. Neste caso a documentao abrange mais do que arquivo de texto,
abrange representaes grficas ou simulaes (PRESSMAN, 2006).
O ciclo de vida clssico requer uma abordagem sistemtica, uma abordagem
incorporando processos, mtodos e ferramentas, sequencial ao desenvolvimento de
software, que se inicia no nvel do sistema e avana ao longo da anlise, projeto,
codificao, teste e manuteno. Tendem a colocar ordem numa atividade
inerentemente catica (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 sequncia. A sada da primeira etapa "flu
para a segunda etapa e a sada da segunda etapa "flu para a terceira e assim por
diante. As atividades a executar so agrupadas em tarefas, executadas
sequencialmente, de forma que uma tarefa s poder ter incio quando a anterior
tiver terminado (MELO, 2007).
A vantagem do modelo que o mesmo s avana para a prxima tarefa, a
partir da aceitao e validao do cliente. O modelo pressupe que o cliente
participa ativamente no projeto. Este modelo minimiza o impacto da compreenso
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; anlise de requisitos; projeto;
22

construo/codificao; teste e integrao; operao e manuteno. Como mostra a
figura (2) abaixo (MELO, 2007).

F97(a 2 Mo$%lo +a)+ata
Fo!t%- SOMMERVILLE" 2003&

2&2&2 P(otot3a45o

Um prottipo uma verso inicial de um sistema de software, que utilizada
para mostrar conceitos, experimentar opes de projeto e, em geral, para conhecer
mais sobre os problemas e suas possveis solues. O desenvolvimento rpido de
um prottipo essencial para que os custos sejam controlados e os usurios
possam fazer experincias com o prottipo no incio do processo de software
(PRESSMAN, 2006).
A prototipao possibilita ao desenvolvedor criar um modelo de software que
ser implementado. O seu principal objetivo antecipar ao usurio final um modelo
de sistema para que o mesmo possa avaliar suas reais finalidades, identificar erros e
omisses, com isso o desenvolvedor pode efetuar de forma imediata as correes e
ajustes no software (PRESSMAN, 2006).
Como todas as abordagens ao desenvolvimento de software, a prototipao
inicia-se com a coleta de requisitos (Figura 3). Faz-se ento um projeto rpido
contendo os aspectos que sero visveis ao cliente. O projeto rpido leva
23

construo de um prottipo, que, ser avaliado pelo cliente/usurio. Esta avaliao
ser usada para refinar requisitos para o software desenvolvido. dealmente, o
prottipo serve como um mecanismo para identificar os requisitos de software.
Muitas vezes, preciso descartar um prottipo e, partir do incio para evitar perda de
tempo com correes (PRESSMAN, 2006).

F97(a 3 Mo$%lo 3(otot3a45o
Fo!t%- PRESSMAN" 200@&

A filosofia de prottipos possui algumas vantagens, que so: garantia de
sucesso tcnico e psicolgico; reduo no fator tempo; ideal para sistemas
gerenciais e de apoio deciso; sistema atual melhora a percepo do usurio em
relao software; o desenvolvedor constri algo imediatamente; entre outros
(PRESSMAN, 2006).
As principais desvantagens deste modelo que na maioria das vezes o cliente
quer resultados, e, muitas vezes no saber, ou no entender que um prottipo
pode estar longe do software ideal. Mesmo assim, a gerncia de desenvolvimento
cede s reclamaes e tenta encurtar o prazo de entrega, o qual j estava
prolongado. O desenvolvedor, na pressa de colocar um prottipo em funcionamento,
levado a usar uma linguagem de programao imprpria por simplesmente estar
disposio ou estar mais familiarizado. Essa atitude poder levar a um algoritmo
ineficiente. Outras desvantagens que pode haver muitos ajustes no prottipo final,
a fim de melhorar a qualidade; o desenvolvedor pode esquecer estruturas
24

inapropriadas no prottipo; exige elevada capacitao gerencial por parte da equipe
do projeto; entre outros (PRESSMAN, 2006).
O prottipo baseado no "feedback dos usurios, por causa disso as
mudanas so feitas no prottipo. Dependendo do comentrio dos usurios, estas
mudanas podem ser menores, de modo que alterem formatos, ou podem ser
maiores, de modo que so requeridas mudanas estruturais no prottipo. Ainda que
possam ocorrer problemas, o uso da prototipao um paradigma eficiente na
Engenharia de Software. O grande segredo o entendimento entre o desenvolvedor
e o cliente (PRESSMAN, 2006).

2&2&3 Mo$%lo %)3(al

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 caractersticas do
ciclo de vida clssico e da prototipao, porm com a adio de um novo elemento,
que foi a "anlise de risco. Este modelo de ciclo de vida se utiliza de prottipos por
se adequar muito bem com esta filosofia de desenvolvimento. Cada passo (Figura 4)
atravs do ciclo inclui: planejamento, anlise e projeto, prototipao e avaliao. Os
passos se repetem at que um produto seja obtido (PRESSMAN, 2006).
F97(a 6 Mo$%lo %)3(al
Fo!t%- PRESSMAN" 200@&
25

Um ciclo se inicia com a determinao de objetivos, alternativas e restries
(primeira tarefa) na qual ocorre o comprometimento dos envolvidos e o
estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa,
avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise
de risco. Prototipao uma boa ferramenta para tratar riscos. Se o risco for
considerado inaceitvel, 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 so circunstncias adversas que podem atrapalhar o processo de
desenvolvimento e a qualidade do produto a ser desenvolvido, com isso possvel
prever e eliminar os problemas de alto risco atravs de um planejamento e projetos
cuidadosos. Este um modelo que atende aos seguintes casos: o problema a ser
resolvido no est totalmente entendido; a realidade pode mudar enquanto o
sistema est sendo desenvolvido; a prpria soluo adotada pode ter algum efeito
colateral desconhecido e a preocupao est centrada mais na qualidade e
funcionalidade do que se produz (PRESSMAN, 2006).
Com base na experincia adquirida com a primeira verso, estabelecem-se
novos requisitos para o sistema, e uma nova verso concebida e implementada. O
modelo espiral tende uma trajetria para o modelo mais completo do sistema,
baseado principalmente em decises de prosseguir ou no, de acordo com a
avaliao, 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 "evolucionria", capacitando o desenvolvedor e o cliente a
entender e reagir aos riscos, em cada etapa evolutiva da espiral. Usa a
prototipao como um mecanismo de reduo de riscos e a mesma pode
ser aplicada em qualquer ponto evolutivo. Porm, pode ser difcil convencer
grandes clientes de que a abordagem evolutiva controlvel. Se um grande
risco no for descoberto, com certeza ocorrero problemas (PRESSMAN,
2006).

Esse paradigma relativamente novo, e no tem sido amplamente usado como
outros modelos anteriormente explicados, o motivo est por exigir considervel
experincia na determinao de riscos e depende dessa experincia para ter
sucesso. O modelo espiral mais adequado para sistemas complexos e que exijam
um alto nvel de interaes com os usurios, a fim de possibilitar a abordagem de
todos os problemas desse sistema (PRESSMAN, 2006).
26

3 SOFTWARE LEGADO

Um sistema de software um artefato evolutivo e, com o passar do tempo, seu
projeto e implementao originais so modificados para atender a novos requisitos
e/ou melhorar o seu desempenho. Fatores internos e externos, como o estado da
economia, as modificaes nos mercados, as alteraes nas leis, as mudanas de
gesto e organizao estrutural, contribuem para que as empresas sofram
mudanas contnuas (SOMMERVLLE, 2003).
Essas mudanas geram requisitos de software novos ou modificados; assim,
todos os sistemas de software teis inevitavelmente so modificados quando as
empresas passam por mudanas. Portanto, esses sistemas incorporam um grande
nmero de alteraes que foi feitas durante muitos anos, alm de incorporarem
importantes regras de negcio no seu contexto. So os chamados sistemas legados
(SOMMERVLLE, 2003).
Existem muitas empresas que esto repletas de software legado em uso,
principalmente as empresas cujos processos so os mesmos por anos.
Normalmente as empresas gastam muito dinheiro na implantao do sistema e
esperam no ter o mesmo gasto novamente (JALOTE, 2005).
A durabilidade de sistema de software muito varivel, muitos sistemas de
grande porte permanecem em uso por mais de dez anos. Muitos desses antigos
sistemas ainda so fundamentais para as empresas, isto , as empresas dependem
dos servios fornecidos pelo software, e qualquer falha desses servios teria um
srio efeito em seu dia a dia. Normalmente so aplicaes complexas, de difcil
manuteno e que pelo grau de criticidade e custo para modernizao, continuam
ativas (BRAGA, 2004).
A palavra "legado traz um sentido pejorativo, similar ao adjetivo obsoleto. O
nome "software legado dado a sistemas antigos, em uso h determinado perodo
e desenvolvidos com tecnologia ultrapassada. Possuem uma funo crtica em
relao ao processo funcional de uma organizao que passou por diversas
modificaes de requisitos durante seu tempo de vida (BRAGA, 2004).
A preocupao do engenheiro de software com os "legados est na baixa
qualidade do mesmo. Muitas vezes no existem documentaes e se existem so
pobres de detalhes, os casos de testes so fracos e no h um controle de
27

mudanas. Muitas vezes o engenheiro de software no mexe no software legado
quando o mesmo atende as necessidades do cliente (BROOKS, 1995).
Com o constante avano da tecnologia, esses sistemas costumam ser
implantados nas organizaes j desatualizados tecnologicamente (BROOKS,
1995).
Um sistema legado contm software, hardware, profissionais, processos,
regras de negcio e informaes 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 usurios de um modo geral
(BRAGA, 2004).

necessrio tambm focar o lado humano de uma possvel mudana
tecnolgica com a modernizao ou mesmo substituio do sistema legado. Esse
acompanhamento estratgico se chama "Gesto de Mudanas (Change
management) que so ferramentas e tcnicas utilizadas para atenuar o impacto da
mudana tecnolgica causado nos indivduos diretamente ligados tecnologia
(SOMMERVLLE, 2003).
Algumas das principais caractersticas na identificao de um software legado
so: sistemas em produo h mais de cinco anos; hardware e software obsoletos;
sistemas com mais de 10 mil linhas de cdigos; interface com o usurio baseada em
caractere; cdigo-fonte amplamente modificado por diversas equipes ao longo dos
anos, com alteraes no documentadas; documentao antiga e desatualizada,
no condizentes com as funcionalidades e processos atuais do sistema; utilizao
de um sistema de arquivos ou gerenciador de banco de dados obsoletos; sistema
no conhecido em sua totalidade pelos profissionais responsveis por sua
manuteno; usurios do sistema incapazes de explicar com detalhes suas funes
junto ao sistema e todos os processos que o mesmo executa; regras de negcio
inseridas apenas no cdigo-fonte do sistema (BRAGA, 2004).

3.1 EVOLUO PARA O LEGADO

A evoluo de um sistema um termo amplo que cobre todo o tempo entre
uma simples adio de um campo a um banco de dados at a completa
reimplementao de um sistema. Essas atividades de evoluo podem ser divididas
em trs categorias: manuteno, modernizao e substituio (PEGO, 2010).
28

A manuteno um processo incremental e iterativo em que pequenas
modificaes so efetuadas no sistema. Essas modificaes podem indicar
correes de erros ou pequenas melhorias no sistema, e nunca devem indicar
grandes mudanas estruturais (PEGO, 2010).
A substituio indicada para sistemas que no conseguem se adaptar s
necessidades do negcio e para os quais a modernizao no mais possvel ou
vivel (PEGO, 2010).
A modernizao envolve mudanas maiores que a manuteno, mas conserva
uma poro significativa do sistema. Essas mudanas incluem a reestruturao do
sistema, melhorias funcionais importantes, ou novos atributos de software. A
modernizao utilizada quando um sistema legado requer mudanas significativas
que as possveis com manuteno (PEGO, 2010).
O tipo de modernizao de um sistema legado pode ser definido pelo nvel de
entendimento do sistema requerido para suportar os esforos de modernizao.
Conhecimento interno da lgica do sistema chamada "modernizao white-box, e
a que requer somente o conhecimento das interfaces externas do sistema
chamada "modernizao black-box (PEGO, 2010).

3.2 ARQUTETURA

A arquitetura de qualquer software, seja ele legado ou no, 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
diviso em elementos arquiteturais, protocolos de comunicao e controle,
sincronizao, distribuio fsica, acesso a dados, etc. Uma arquitetura de software
deve ser vista e descrita mediante diferentes perspectivas e deve identificar seus
componentes, relacionamentos estticos, interaes dinmicas, propriedades,
caractersticas e restries (VASCONCELOS, 2007).
Quando se trata da arquitetura de um sistema legado, normalmente
apresentam algumas particularidades. No contexto organizacional possui vrios
componentes, figura (5), so eles: hardware do sistema; software de apoio; software
de aplicao e processos de negcios (VASCONCELOS, 2007).

29

F97(a < Mo$%lo %1 +a1a$a) $% 71 )o:tFa(% l%9a$o

Quando se trata de "hardware do sistema na maioria dos sistemas obsoletos o
hardware antigo, no existem mais fornecedores e a manuteno dispendiosa.
Em muitos casos, os sistemas legados foram escritos para hardware de mainframe e
pode no ser compatvel com as atuais polticas de compras na rea de tecnologia
da informao (BRAGA, 2004).
O "software de apoio como o sistema operacional, compiladores, ferramentas,
etc. tambm pode estar desatualizado. O sistema pode ter sido compilado utilizando-
se uma verso de um compilador hoje descontinuada, e a mesma deve ser mantida
(BRAGA, 2004).
No caso do "software de aplicao, no um nico programa de aplicao,
mas incluiu vrios 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 alteraes como a adio de novos programas, que compartilham os
dados e se comunicam com outros programas do sistema. Esses diferentes
programas, geralmente so escritos e desenvolvidos por pessoas e linguagens
diferentes, em pocas distintas (SOMMERVLLE, 2003).
Como o software de aplicao, temos tambm os "dados de aplicao que
so aplicados no mesmo contexto. Em sistemas legados um imenso volume
de dados se acumulou durante o tempo de existncia do sistema. Esses
dados podem estar inconsistentes, duplicados em diferentes arquivos.
Assim como acontece com o software de aplicao, os arquivos de dados
iniciais sofrem alteraes medida que novas informaes so exigidas
(BRAGA, 2004).

30

A camada de "processos de negcios so informaes sobre os processos
internos da organizao, codificadas em uma linguagem de programao e
espalhadas pelos programas que fazem parte do sistema. Em boa parte dos
sistemas essas regras no esto bem documentadas, sendo do conhecimento ttico
de gerentes, analistas e usurios do sistema (BRAGA, 2004).

3.3 NVEL LGCO

Modificar uma camada do sistema pode introduzir novos recursos, e as
camadas superiores do sistema so beneficiadas desses recursos. A modificao do
software no sistema pode torn-lo mais lento, de modo que um novo hardware
necessrio. Em grande parte das vezes impossvel manter interfaces de hardware,
especialmente se for proposta uma mudana radical para um novo tipo de hardware
(MECELLA, 1999).
A separao do sistema legado em nveis lgicos uma "ponte para um
posterior tratamento, manuteno ou integrao. Os nveis lgicos se dividem em
quatro partes, como mostra a figura 6 (MECELLA, 1999).

F97(a @ * NG'%) l89+o) $% ))t%1a) +o137ta+o!a)
Fo!t%- MECELLA" 1HHH&

A primeira representao o "altamente Decomponvel (amigvel) este
sistema dividido em trs nveis lgicos bem distintos e estruturado. A alterao de
31

um nvel no afetar significativamente o outro nvel. Todos os nveis so
prontamente acessveis (MECELLA, 1999).
A segunda representao o "decomponvel nos dados (pouco amigvel) este
sistema dividido em dois nveis lgicos: o nvel de interface em conjunto com o
nvel de processamento lgico e o nvel de dados. O acesso aos dados nesse tipo
de sistema imediato, ao contrrio do acesso interface ou o processamento
lgico. Sua integrao a outros sistemas conseguida com programao e
utilizao de tecnologias (MECELLA, 1999).
A terceira representao o "decomponvel no programa (pouco amigvel)
este sistema dividido em dois nveis lgicos: o nvel de interface, separado e o
nvel de programas e dados, em conjunto. Os dados somente so acessveis a partir
de funes do sistema. Nesta categoria se encontram a maioria dos sistemas
legados. Sua integrao a outros sistemas conseguida com programao e
utilizao de tecnologias (MECELLA, 1999).
A quarta e ultima representao o "monoltico (hostil) este sistema
composto de um nico bloco lgico. So aplicaes bem antigas, e o acesso s suas
informaes bastante difcil. Sua integrao a outros sistemas bastante
complexa (MECELLA, 1999).

3.4 AVALAO

Segundo Warren ao avaliar um sistema legado, deve-se consider-lo sob duas
perspectivas diferentes. A primeira seria sob a perspectiva de negcios (valor do
sistema para a empresa) e a segunda seria uma perspectiva de sistema (avaliao
da qualidade do software de aplicao e do software e hardware de apoio do
sistema). A juno dessas duas perspectivas decisiva na hora de decidir o que
fazer com o sistema legado (WARREN, 1998).
Essas avaliaes so meramente subjetivas e sua quantificao deve ser
efetuada utilizando-se uma abordagem de questionamentos aos vrios
indivduos envolvidos no processo, colhendo assim vrios pontos de vista.
Dados quantitativos coletados tambm podero auxiliar na avaliao do
sistema, como: o nmero de pedidos de modificaes no sistema; o volume
de dados utilizados pelo sistema, etc. A formulao das questes a serem
efetuadas deve ser inerente s duas perspectivas adotadas para a
avaliao do sistema legado (SOMMERVLLE, 2003).

O ideal que seja utilizada a avaliao objetiva para informar as decises
sobre o que fazer com o sistema legado. Contudo, em muitos casos, essas decises
32

no so realmente objetivas, mas se baseiam em consideraes organizacionais ou
polticas. imprescindvel para uma organizao efetuar uma correta avaliao de
seus sistemas legados. Caso essa avaliao seja efetuada sem critrio, as decises
tomadas podero representar perdas significativas de dinheiro e recursos (BRAGA,
2004).
Supondo que uma organizao possua dez sistemas legados, a qualidade e o
valor de negcios de cada um desses sistemas so avaliados e comparados com
outros sistemas, mediante um grfico, que mostra o valor de negcios relativo e a
qualidade do sistema. Na figura (7), possvel verificar que existem quatro grupos
de sistemas e que se subdividem em: baixa qualidade, baixo valor de negcios;
baixa qualidade, alto valor de negcios; alta qualidade, baixo valor de negcios e
alta qualidade, alto valor de negcios (SOMMERVLLE, 2003).

F97(a = .7al$a$% $% ))t%1a % 'alo( $% !%98+o

Quando o sistema se encaixa no nvel de "Baixa qualidade, baixo valor de
negcios significa que manter esses sistemas em operao ser dispendioso e a
taxa de retorno de investimento para os negcios ser pequena. Esses sistemas so
candidatos a serem descartados (BRAGA, 2004).
Agora se o sistema se enquadra no nvel de "Baixa qualidade, alto valor de
negcios significa que esses sistemas esto prestando uma importante contribuio
empresa, assim, no podem ser descartados. Porm, sua baixa qualidade significa
33

que os custos operacionais so altos, de modo que so candidatos transformao
ou substituio do sistema (BRAGA, 2004).
No nvel de "Alta qualidade, baixo valor de negcios significa que so
sistemas que no contribuem muito para os negcios, mas cuja manuteno
pode no ser muito dispendiosa. No vale o risco substituir esses sistemas,
de modo que a manuteno normal pode ser continuada ou eles podem ser
descartados (WARREN, 1998).

Quando o sistema se enquadra no nvel de "Alta qualidade, alto valor de
negcios significa que esses sistemas devem ser mantidos em operao, mas sua
alta qualidade significa que no necessrio investir na sua transformao ou
substituio. Deve-se continuar com a manuteno normal do sistema (WARREN,
1998).

3.5 MANUTENO

A manuteno definida como a totalidade de atividades requeridas para
prover suporte de custo efetivo para um sistema de software. As atividades so
realizadas tanto durante o estgio de pr-entrega quanto no estgio de ps-entrega.
A manuteno uma atividade inevitvel e pode vir a ser a mais longa fase no ciclo
de vida do sistema, isso se justifica atravs das leis de evoluo do software
(RAMOS, 2008).
Essas leis de evoluo do software so: "mudana contnua no qual os
sistemas devem ser continuamente adaptados seno se tornar progressivamente
insatisfatrio. O "aumento da complexidade no qual o sistema aumenta sua
complexidade conforme evolui, a no ser que algo seja feito para controlar tal
complexidade. O "crescimento contnuo no qual o contedo funcional de um sistema
deve crescer continuamente para manter a satisfao do usurio durante a sua vida
til (RAMOS, 2008).
Os principais fatores que dificultam e encarecem a manuteno no software
legado que muitas vezes excepcionalmente difcil entender o programa "de outra
pessoa, isso porque foram implementadas por diferentes equipes. No h um estilo
de programao consistente em todo sistema e os algoritmos so 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
34

difcil e caro, uma vez que um profissional deste nvel raro no mercado e o seu
salrio maior (RAMOS, 2008).
Muitas vezes foi usado um sistema de administrao de bases de dados que
pode estar obsoleto, ou depende de arquivos armazenados separadamente. No
caso de arquivos separados, cada um tem seu prprio formato e, frequentemente, as
mesmas informaes so duplicadas e representadas em diferentes formas e em
diferentes arquivos. Essa duplicao usualmente acontece porque as informaes
so fortemente integradas com as estruturas de dados dos programas (DNZ, 2010).
Outro problema do software legado est em sua documentao, muitas vezes
no existe documentao e quando existe, ela no compreensvel e consistente
com o cdigo fonte, neste caso ela no tem valor. Em alguns casos, a nica
documentao o cdigo-fonte do sistema (RAMOS, 2008).
Esses softwares por no serem projetados no so apitos e nem esto
preparados para mudanas, s chances de perda de desempenho devido a
modificaes no adequadas na sua estrutura interna e o nmero crescente
de novos erros devidos a alteraes indevidas no cdigo um risco que se
corre (PNTO, 2004).

Os sistemas so feitos para refletir comportamentos do mundo real, logo
necessrio que o software acompanhe as mudanas impostas pelo ambiente na
qual est inserido. Uma falha em acompanhar essas mudanas pode implicar em
perda de qualidade por parte do software ou at mesmo no fim da sua vida til, os
muitos anos de manuteno podem corromper a estrutura do sistema, tornando-o
cada vez mais difcil de ser compreendido. O envelhecimento de um software um
processo inevitvel (PNTO, 2004).
Existem dois tipos de envelhecimento de software: o primeiro ocorre quando
os responsveis 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 cado em
desuso e no existir uma nova verso do software para um sistema
operacional mais recente foi esquecido por seus usurios (PNTO, 2004).

O segundo ocorre quando mudanas no software so feitas por
desenvolvedores que no entendem a estrutura original deste, o que fatalmente
implicar em algum dano para esta estrutura, que mesmo pequeno ir aumentando
conforme novas atualizaes forem sendo feitas, e com o passar do tempo cada
nova mudana se tornar mais difcil e consequentemente cara. Caso no seja feita
uma reestruturao do software, este chegar a um ponto onde novas atualizaes
ficaro inviveis (PNTO, 2004).
35

A partir do momento em que um sistema comea a ser utilizado, ele entra em
um estado contnuo de mudana. Mesmo que tenha sido construdo aplicando as
melhores tcnicas de projeto e codificao, os sistemas vo se tornando obsoletos
em vista das novas tecnologias que so disponibilizadas (PEKARSK, 2000).
As leis da evoluo de software so estudadas h 30 anos, e sua
contribuio para a melhor compreenso da evoluo de software e a
engenharia de software como um todo so ainda inestimveis
(VASCONCELOS, 2007).

Com o objetivo de minimizar os problemas gerados por manutenes difceis e,
algumas vezes, degenerativas da estrutura do sistema, muitas organizaes esto
optando por refazer seus sistemas. A ideia bsica dessa reconstruo ou
reengenharia que as informaes de projeto e especificao sejam extradas do
cdigo fonte, reformuladas e reconstrudas, resultando um software mais fcil 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 programao mais
moderna e implementados em uma plataforma distribuda, bem como seus dados
podem ser migrados para uma base de dados diferente. A reengenharia de software
tem como objetivo fazer sistemas flexveis, fceis de modificar, frente s constantes
mudanas das necessidades dos usurios (BENNETT, 1995).
O campo da reengenharia est crescendo em resposta necessidade crtica
que existe na indstria de software por tecnologia que suporte a manuteno de
sistemas legados e o desenvolvimento evolutivo de novos sistemas. Existe uma
firme e crescente demanda para migrar programas legados de mainframes
monoprocessados, para estaes multiprocessadas, distribudas e ligadas em rede,
visando acompanhar os avanos das tcnicas de programao tais como: interfaces
grficas para o usurio, comunicao 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
informaes dentro das organizaes e so os principais veculos para a
consolidao das informaes sobre o negcio. O conhecimento agregado nestes
sistemas constitui um patrimnio corporativo significativo. Por tratar de sistemas
36

crticos apresentam numerosos e importantes problemas para as empresas
(BSBAL, 1999).
Entre os mais significativos destacam-se: apresentam plataformas de hardware
com altos custos de manuteno que poder se tornar numa das maiores despesas
na rea de T; desenvolvidos em plataformas proprietrias; no passveis de
publicao na internet; apresentam limitaes de integrao com outros sistemas; e
restritos com relao ao desenvolvimento de novas funcionalidades (STEVENS,
1998).
Os negcios de hoje s podem sobreviver se eles puderem adaptar
rapidamente para um ambiente varivel e tirar vantagens das novas oportunidades
de negcio. A partir do momento que os sistemas de T se tornam vitais a quase
todos os negcios, necessrio que estes sistemas possam ser modificados
rapidamente e com baixo custo (STEVENS, 1998).
A maioria dos sistemas legados passou por mudanas contnuas durante
muitos anos de manuteno. De acordo com a segunda lei de evoluo de
programas de Lehman (1985), quando um programa em evoluo continuamente
modificado, sua estrutura se deteriora, consequentemente a complexidade aumenta.
Esse aumento de complexidade ocorre porque h uma precipitao ao elaborar as
correes dos problemas e no h tempo para manter o refinamento de um projeto
ou a consistncia da abordagem em todo o cdigo (LEHMAN, 1985).
A pressa em disponibilizar um produto pode levar mantenedores a implementar
uma modificao rpida, ineficiente e sem ter sido adequadamente testada, em vez
de utilizar o tempo necessrio para seguir as boas prticas de engenharia de
software. O resultado um produto com vrios "remendos" e difcil de ser entendido
e mantido (LEHMAN, 1985).
Atualmente as organizaes esto enfrentando uma grande presso para
modernizar seus sistemas, a fim de que possam responder melhor s necessidades
da rea de mercado e de pessoas e s rpidas mudanas de tecnologia (LEHMAN,
1985).

37

6 REENGENHARIA DE SOFTWARE

O software o conjunto de vrios artefatos e no apenas o cdigo fonte. O
software no um produto acabado, est sempre em mutao, condio esta
originria de mudanas nas regras de negcio das organizaes, da necessidade de
melhoria do processo produtivo ou da adequao do produto ou do servio que
utiliza tecnologia da informao e est disponibilizado para uso (ZANLORENC,
2009).
Muitas organizaes tm enfrentado problemas com o uso e a manuteno de
software construdo para ser executado em uma variedade de tipo de hardware e
programado em linguagem obsoletas. A tarefa de realizar a manuteno torna-se
mais complexa e mais cara e, ainda, esses sistemas tornam-se cada vez mais
desorganizados devido s inmeras tentativas de adaptaes e incluses de novas
funcionalidades. Sendo assim, as organizaes tm trs alternativas: manter os
softwares legados, comprar um novo software ou realizar a reengenharia tanto para
aumentar sua manutenibilidade quanto para implement-los em um paradigma mais
atual com ou sem mudana de linguagem (SOMMERVLLE, 2003).
Quando o sistema no fcil de ser mantido sendo, porm, de grande
utilidade, ele deve ser reconstrudo. Partindo-se do sistema existente (via
cdigo-fonte, interface ou ambiente), so abstradas as suas
funcionalidades e so construdos o modelo de anlise e o projeto do
software. Esse processo denominado reengenharia de software
(PEKARSK, 2000).

O termo reengenharia pode referir-se tanto reengenharia do processo de
negcios (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 negcios pode ser alavancada com o auxlio
computacional da reengenharia de sistemas, ao passo que a reengenharia de
sistemas pode beneficiar-se com a aplicao dos conceitos da reengenharia do
processo de negcios (SLVA, 2005).
A reengenharia de software tambm chamada renovao ou recuperao de
software definida como a recuperao rigorosa do conhecimento embutido em
sistemas existentes a fim de alavancar os esforos em seu aprimoramento,
procurando melhorar sua qualidade global e reduzir custos com manuteno, isto ,
38

reestruturar ou reescrever todo ou parte de um sistema legado sem alterar suas
funcionalidades (SLVA, 2005).
Um processo de reengenharia geralmente inclui traduo do cdigo-fonte,
melhoria na estrutura do programa, modularizao, alguma forma de engenharia
reversa seguida por uma forma de engenharia progressiva ou reestruturao e
reengenharia de dados (SLVA, 2005).
Existem diferentes tipos de reengenharia: com a troca parcial ou completa da
implementao sem a troca da funcionalidade, em que h mudana do paradigma
de desenvolvimento e/ou da linguagem de implementao, 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 anlise e implementando-o novamente (PEKARSK,
2000).
importante ressaltar que existe uma clara distino entre o desenvolvimento
de um novo software e a reengenharia, a distino est relacionada ao ponto de
partida de cada um dos processos. O desenvolvimento de um novo software
(engenharia progressiva) inicia-se com uma especificao escrita do software que
ser construdo, enquanto que a reengenharia inicia-se tomando como base um
sistema j desenvolvido. Como mostra a figura (8) abaixo (SOMMERVLLE, 2003).

F97(a I * D)t!45o %!t(% o $%)%!'ol'1%!to $% 71 !o'o )o:tFa(% 012 % (%%!9%!,a(a 022

O objetivo da engenharia reversa derivar o projeto ou especificao de um
sistema, partindo-se de seu cdigo fonte. O objetivo da reengenharia produzir um
sistema novo com maior facilidade de manuteno. A engenharia reversa usada
39

como parte do processo de reengenharia, pois fornece o entendimento do sistema a
ser reconstrudo (SOMMERVLLE, 2003).
Para melhorias relacionadas reengenharia, podem-se estabelecer trs
categorias, que so: reengenharia de processos administrativos (direcionada para
alteraes potenciais em todos os negcios ou processos organizacionais);
reengenharia de processos produtivos (consiste em modificar qualquer ciclo de
processos padro, que esteja em uso em uma dada organizao, a fim de melhora);
reengenharia de software ou produtos (captura e modificao de mecanismos
internos ou funcionalidade de um sistema existente ou produto, visando reconstitu-
lo em uma nova forma e com novas caractersticas, frequentemente para tomar
vantagem das novas e emergentes tecnologias, mas sem grandes alteraes na
funcionalidade e propsito inerentes ao sistema) (SOMMERVLLE, 2003).

4.1 RELACONAMENTOS NO CCLO DE DESENVOLVMENTO

Para uma melhor compreenso das tcnicas de manuteno de software,
preciso considerar trs conceitos dependentes: a existncia de um processo de
desenvolvimento de software, a presena de um sistema a ser analisado e a
identificao de nveis de abstrao (independncia dos dados e dos programas)
(OSBORNE e CHKOFSKY, 1990).
ndependente do que seja o processo de desenvolvimento de software, espera-
se que haja interao entre seus estgios e, qui, recurso. No processo de
desenvolvimento de software, os estgios iniciais envolvem conceitos mais gerais,
independentes de implementao, enquanto os estgios finais enfatizam os detalhes
de implementao (OSBORNE e CHKOFSKY, 1990).
O aumento de detalhes durante o processo de desenvolvimento conceitua
os nveis de abstrao. Estgios iniciais do sistema planejam e definem
requisitos de alto nvel quando comparados com a prpria implementao
(PEKARSK, 2000).

Esta comparao deixa claro que nvel de abstrao e grau de abstrao so
grandezas distintas. Enquanto o nvel de abstrao um conceito que diferencia os
estgios conceituais do projeto, o grau de abstrao intrnseco a cada estgio
(PEKARSK, 2000).
A evoluo atravs das fases do processo de desenvolvimento de software
envolve transies dos nveis mais altos de abstrao nos estgios iniciais, para
40

nveis mais baixos nos estgios posteriores. As informaes podem ser
representadas em qualquer estgio do desenvolvimento, seja de forma detalhada
(baixo grau de abstrao), seja de forma mais sucinta ou global (alto grau de
abstrao). Abstrao definida como a habilidade de se ignorar os aspectos de
assuntos no relevantes para o propsito em questo, tornando possvel uma
concentrao maior nos assuntos principais (PEKARSK, 2000).
Para que as tcnicas de manuteno de software (especificamente engenharia
reversa e reengenharia) sejam descritas de forma simplificada, sero tomadas como
base trs fases do processo de desenvolvimento de software, com nveis de
abstrao diferenciados, conforme figura 9 (OSBORNE e CHKOFSKY, 1990):
Requisitos: especificao do problema a ser resolvido, incluindo objetivos,
restries e regras de negociao;
Projeto: especificao da soluo;
mplementao: codificao, teste e adaptao ao sistema operacional;
A tcnica tradicional, que avana progressivamente pelas fases do processo
de desenvolvimento de software, denominada engenharia progressiva. A
execuo dessa tcnica consiste em partir de projetos independentes da
implementao, que possuem altos nveis de abstrao, indo em direo
implementao fsica do sistema (OSBORNE e CHKOFSKY, 1990).

F97(a H * R%la+o!a1%!to) !o ++lo $% $%)%!'ol'1%!to $% )o:tFa(%
Fo!t%- CHIJOFSJK % CROSS" 1HH0&

41

Na Figura 9, com exceo da engenharia progressiva, as demais transies
entre as fases de desenvolvimento so tecnologias utilizadas na manuteno de
software, sendo assim definidas por PEKARSK (2000):
Redocumentao: como uma subrea da engenharia reversa, a criao ou
reviso de uma representao semanticamente equivalente, dentro do mesmo nvel
relativo de abstrao, sendo que as formas resultantes de representao so
consideradas como vises alternativas, utilizadas para uma melhor compreenso
humana do sistema analisado;
Recuperao de projeto: uma subrea da engenharia reversa em que o
conhecimento do domnio da aplicao, informaes externas e deduo so
adicionados nas observaes referentes ao programa, com fim de extrair abstraes
significativas de mais alto nvel, alm das obtidas por meio da observao direta do
sistema;
Reestruturao: a modificao de uma forma de representao, para outra
no mesmo nvel de abstrao relativo, preservando o comportamento externo do
sistema (funcionalidade e semntica). Frequentemente usada como uma forma de
manuteno preventiva, a reestruturao aplicada em sistemas que tenham sido
desenvolvidos de forma desestruturada, resultando uma representao que preserva
as caractersticas do sistema, mas de forma melhor estruturada;
Engenharia reversa: o processo de analisar um sistema a fim de criar sua
representao de uma forma diferente ou em um nvel mais alto de abstrao do que
o cdigo fonte;
Reengenharia: a reconstruo de algo do mundo real, tendo como propsito
a tentativa por melhorias que permitam produzir algo de melhor qualidade ou
comparvel ao produto inicial.

4.2 PROCESSO DE REENGENHARA 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 instituda. O problema
comum, afetando todos os tipos de organizao, pois uma falha na reengenharia
pode dificultar os esforos da organizao para manter-se competitiva (BORGES,
2007).
42

A capacitao em desenvolvimento de software pressupe a existncia de um
processo de software definido no qual aplicado um modelo de melhoria de
processos. O processo definido tem documentao que detalha o que feito,
quando, por quem, o que utilizado e o que produzido. A maturidade do processo
indica at que ponto um processo definido e implementado, utilizando para isso
aspetos como mtricas para verificao do controle e da eficcia (BORGES, 2007).
Assim, a capacitao em desenvolvimento de software reflete o grau de
institucionalizao de uma infraestrutura e cultura relacionada aos mtodos, prticas
e procedimentos do desenvolvimento de software. Reflete, tambm, a qualidade do
processo, pois a qualidade dos produtos de software depende diretamente da
qualidade do processo de desenvolvimento a eles associados (BORGES, 2007).
Um processo de reengenharia tem como entrada um programa legado e a
sada uma verso estruturada e modularizada do mesmo programa. Ao mesmo
tempo em que ocorre a reengenharia do programa, os dados do sistema tambm
podem passar por reengenharia (BORGES, 2007).
A reengenharia de dados o processo de analisar e reorganizar estruturas
de dados e, eventualmente, os valores dos dados de um programa, com o
objetivo de torn-lo mais compreensvel. Em princpio, a reengenharia de
dados no dever ser necessria, se a funcionalidade do sistema
permanecer inalterada. Na prtica, h uma srie de razes pelas quais
preciso modificar os dados, como tambm os programas, em um sistema
legado (SOMMERVLLE, 2003).

Efetuar o processo de reengenharia em uma aplicao implica em examinar e
alterar um sistema com o propsito de reconstitu-lo em um novo modelo e uma
implementao de nova forma. A figura 10 exibe as principais etapas no processo de
reengenharia de software (PEKARSK, 2000).
F97(a 10 P(o+%))o $% (%%!9%!,a(a
Fo!t%- SOMMERVILLE" 2003
43

6&2&1 T(a$745o $% +8$9o*:o!t%

Quando um programa se encontra escrito em uma linguagem de programao
e precisa, por algum motivo como, por exemplo, falta de suporte ao compilador atual,
ser migrado para outra linguagem, a traduo do cdigo-fonte se faz necessria
(MAZZANT, 2008).
A traduo do cdigo-fonte mantm a estrutura e a organizao do programa
em si inalterada. A linguagem para a qual o programa ser transcrito pode ser uma
verso 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
(MAZZANT, 2008).
A traduo de cdigo-fonte s ser economicamente vivel se existir alguma
ferramenta para realizar a maior parte da traduo de forma automatizada. Na
maioria dos casos, impossvel realizar a traduo de forma completamente
automtica. As instrues da linguagem original podem no ter nenhuma instruo
equivalente na nova linguagem. Embora, esse tipo de ferramenta tem evoludo, no
so raros os casos em que os desenvolvedores devem intervir e corrigir possveis
erros manualmente (SOMMERVLLE, 2003).
Existem algumas ferramentas no mercado que se propem a fazer essa
tarefa, tais como: CodePorting C#2Java - esta ferramenta converte projetos
C# para Java e promete usabilidade, produtividade, simplicidade,
confiabilidade, administrao facilitada e poderosas customizaes;
Composer CipherSoft converte aplicaes Oracle Forms e PL/SQL para
Java; Telescope for Jaguar converte Oracle Forms para Java, trata-se de
uma soluo semi-automatizada, pois precisa de anlise da empresa
desenvolvedora antes da migrao. Existem ainda ferramentas que se
destinam a facilitar a atualizao de uma tecnologia para outra: a Oracle
Forms Migration Assistant uma ferramenta que atualiza as aplicaes
Oracle Forms 6i para Oracle Forms 11g (LOVATTO, 2012).

Converses de linguagens so bem mais difceis do que se costuma imaginar,
principalmente por problemas de automao. A maioria das ferramentas de
converso aplica a tecnologia da converso sinttica, mesmo com esta abordagem
aparentemente simples e de baixo nvel, muitas dificuldades ocorrem, e o tamanho
das complexidades ainda no muito bem definido (MAZZANT, 2008).
preciso deixar claro que diferente da traduo do cdigo-fonte, a
"segmentao o processo de reengenharia com mudana da orientao de
procedimental para orientao a objetos, preservando-se as funcionalidades do
software e a linguagem de programao. Portanto, realizada a adaptao do
44

cdigo-fonte, de acordo com os recursos disponveis na linguagem, de forma a
implement-lo com caractersticas orientadas a objetos (LOVATTO, 2012).

6&2&2 E!9%!,a(a (%'%()a

O termo engenharia reversa tem suas origens na anlise do hardware, onde a
prtica 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 prtica
herdada das antigas indstrias e que, atualmente, usada em software e hardware.
Na indstria automobilstica, por exemplo, um fabricante pode comprar um veculo
de um concorrente, desmont-lo e examinar as soldas, lacres e outros componentes
do veculo, com o propsito de aprimorar seus prprios veculos, com componentes
similares (PRESSMAN, 1995).
Segundo Chikofsky e Cross, pode-se definir engenharia reversa como uma
coleo de teorias, metodologias, e tcnicas capazes de suportar a extrao e
abstrao de informaes de um software existente, produzindo documentos
consistentes, quer seja a partir somente do cdigo fonte, ou atravs da adio de
conhecimento e experincia que no podem ser automaticamente reconstrudos a
partir do cdigo (CHKOFSKY e CROSS, 1990).
Quando se trata de software, o programa que passar pelo processo de
engenharia reversa no o do concorrente, e sim o sistema da prpria organizao.
Este processo fornece informaes da especificao e do projeto de um sistema de
software, a partir de seu cdigo-fonte. Depois, essas informaes so armazenadas
de forma que seja possvel manipul-las. Portanto, a engenharia reversa para o
software consiste na anlise de um programa, com o objetivo de criar uma
representao do programa em um nvel de abstrao maior que o cdigo-fonte
(PFLEEGER, 2004).
O processo de engenharia reversa (figura 11) comea com uma fase de anlise
utilizando-se ferramentas automatizadas, a fim de descobrir a estrutura do sistema,
estudar como o programa efetua certas operaes, melhorar o desempenho do
programa, corrigir uma falha, identificar vrus, ou para adaptar um programa para
que possa ser executado em uma plataforma diferente. Estas informaes so
45

mantidas em dicionrios de dados que mantm as informaes do sistema,
vinculados ao cdigo-fonte do programa (SOMMERVLLE, 2003).

F97(a 11 P(o+%))o $% %!9%!,a(a (%'%()a

A recuperao de projeto uma subrea da engenharia reversa na qual o
conhecimento do domnio da aplicao, informaes externas e deduo so
adicionados s observaes referentes ao programa, para extrair abstraes
significativas de mais alto nvel, alm daquelas obtidas atravs da observao direta
do sistema (SOMMERVLLE, 2003).
Documentos de vrios tipos como diagramas de programa e de estrutura de
dados e matrizes de rastreamento (que mostram onde as entidades so
definidas e referenciadas no sistema), podem ser gerados atravs das
informaes armazenadas (SOMMERVLLE, 2003).

Como uma subrea da engenharia reversa, a documentao a criao ou
reviso de uma representao semanticamente equivalente, dentro do mesmo nvel,
relativo de abstrao, sendo que as formas resultantes de representao so
consideradas como vises alternativas, utilizadas para uma melhor compreenso
humana do sistema analisado (SOMMERVLLE, 2003).
Depois de gerada a documentao do sistema, outras informaes podem ser
adicionadas aos dicionrios de dados a fim de ajudar a recriar a especificao do
sistema. sto, em geral, envolve mais anotaes manuais da estrutura do sistema. A
especificao no pode ser inferida automaticamente a partir do modelo do sistema.
(SOMMERVLLE, 2003).
Atualmente, existem vrias ferramentas automatizadas e semi-automatizadas
para auxiliar no processo de engenharia reversa. Entretanto, em qualquer processo
46

de engenharia reversa de sistemas, o envolvimento de especialistas no domnio e na
aplicao fundamental (SOMMERVLLE, 2003).

4.2.2.1 Vises de software

A partir da engenharia reversa e com base nos nveis e graus de abstrao, o
software pode ser visualizado de diferentes maneiras, conforme conceitos de
HARAND (1990):
Viso em nvel implementacional: abstrai caractersticas da linguagem de
programao e caractersticas especficas da implementao.
Viso em nvel estrutural: abstrai detalhes da linguagem de programao
para revelar sua estrutura a partir de diferentes perspectivas. O resultado uma
representao explcita das dependncias entre os componentes do sistema.
Viso em nvel funcional: abstrai a funo de um componente, isto , o que o
componente faz. Essa viso relaciona partes do programa a suas funes,
procurando revelar as relaes lgicas entre elas.
Viso em nvel de domnio: abstrai o contexto em que o sistema est
operando, ou seja, o porqu do sistema a ser desenvolvido.
Conforme figura 12 perceptvel a correspondncia entre as categorias de
visualizao do software e as diferentes atividades do ciclo de desenvolvimento de
software (HARAND, 1990).

F97(a 12 * V)7al;a4?%) $% )o:tFa(% !o ++lo $% $%)%!'ol'1%!to
Fo!t%- HARANDI" 1HH0&

47

relevante ressaltar que uma forma de representao extrada do cdigo
pode diferir de uma representao similar que foi desenvolvida no processo
de engenharia progressiva. A forma extrada ir refletir a idiossincrasia da
representao do cdigo muito mais do que a representao original, que
reflete a compreenso do problema pelo analista ou projetista (HARAND,
1990).

Muitas vezes necessrio acrescentar s informaes contidas no cdigo,
outras informaes de conhecimentos e experincias humanas, para obter vises
diferenciadas do software. Conforme o escopo das informaes usadas, que
resultaro em um nvel de entendimento obtido do sistema pode-se formular uma
categorizao dos mtodos de engenharia reversa (HARAND, 1990).

6&2&3 M%l,o(a $a %)t(7t7(a $o 3(o9(a1a

A reestruturao do programa feita com o objetivo de tornar o software mais
fcil de ser entendido e modificado. Em sua maioria os programas desenvolvem uma
complexa estrutura lgica devido a diversas modificaes sofridas durante a
manuteno. A adio de novos comandos sem modificar a estrutura de controle
existente, um exemplo (MAZZANT, 2008).
No curto prazo, essa uma soluo com menor risco e mais rpida, uma
vez que reduz as chances de um defeito ser introduzido no sistema. No
longo prazo, entretanto, isso pode resultar em um cdigo incompreensvel.
Estruturas complexas de cdigo podem tambm ser utilizadas quando os
programadores procuram evitar duplicao de cdigo, como em sistemas
que so restringidos por uma memria limitada, por exemplo (MAZZANT,
2008).

A figura (13) abaixo representa as trs principais atividades envolvidas na
reestruturao do programa: inicialmente feito uma analise esttica a fim de obter
informaes que servem para representar o cdigo como uma rede semntica ou um
grafo direcionado. Esta representao no necessariamente fcil de ser
compreendida pelas pessoas, normalmente, ela utilizada apenas por uma
ferramenta automatizada. Aps isso, a representao refinada por meio de
sucessivas simplificaes com base em tcnicas de transformao. Por fim, uma vez
completada as simplificaes, um novo programa gerado (MAZZANT, 2008).
Ou seja, a reestruturao a transformao de uma forma de representao,
para outra no mesmo nvel de abstrao relativo, preservando o comportamento
externo do sistema (funcionalidade e semntica). Geralmente usada como uma
forma de manuteno preventiva, a reestruturao aplicada em sistemas que
48

tenham sido desenvolvidos de forma desestruturada, resultando uma representao
que preserva as caractersticas do sistema, porm de forma estruturada
(SOMMERVLLE, 2003).

F97(a 13 P(o+%))o $% (%%)t(7t7(a45o $% 3(o9(a1a

6&2&6 Mo$7la(;a45o $% 3(o9(a1a

Segundo LOVATTO (2012) modularizao um conceito onde o software
divido em partes distintas, compe o ferramental necessrio para um programa mais
legvel com uma melhor manuteno e melhor desempenho por meio da
programao estruturada.
caracterizado como um elemento separadamente enderevel do sistema,
menor parte do sistema que realiza uma funo completa independente de outras
funes, conjunto de instrues de um programa que pode ser chamado por um
nome, sendo ideal que para os outros mdulos seja uma caixa preta (LOVATTO,
2012).
A modularizao do programa consiste na reorganizao do mesmo, de modo
que as partes relacionadas sejam reunidas em um nico mdulo. Assim, fica mais
fcil remover redundncias nesses componentes relacionados, aperfeioar suas
interaes e simplificar suas interfaces com o restante do programa (MAZZANT,
2008).
Segundo Mazzanti (2008) diversos tipos de mdulos podem ser criados
durante o processo de modularizao do programa. So elas:
49

Abstraes de dados: agrupam os dados e o processamento associado,
como funes de construo e de acesso, e so flexveis em relao s mudanas.
Desde que a interface seja mantida, as modificaes em dados abstratos no devem
afetar outras partes do programa.
Mdulos de Hardware: esses mdulos agrupam todas as funes
relacionadas ao controle de um determinado dispositivo de hardware e esto
estreitamente relacionados com as abstraes de dados.
Mdulos funcionais: esses mdulos agrupam funes que realizam tarefas
semelhantes, estreitamente relacionadas. Todas as funes ocupadas com dados
de entrada e a validao destes dados, por exemplo, podem ser agrupadas em um
nico mdulo.
Mdulos de apoio ao processo: todas as funes e todos os itens especficos
de dados que apoiam um processo de negcio especfico so agrupados nesses
mdulos.
A modularizao de programas juntamente com outras tcnicas de
programao integram o ferramental para a elaborao de programas visando,
principalmente, os aspectos de confiabilidade, legibilidade, manuteno e
flexibilidade (LOVATTO, 2012).

6&2&< R%%!9%!,a(a $% $a$o)

A reengenharia de dados o processo de analisar e reorganizar estruturas de
dados e, eventualmente, os valores dos dados de um programa, com o objetivo de
torn-lo mais compreensvel (SOMMERVLLE, 2003).
Muitas aplicaes contm dezenas de programas acima dos 20 anos de idade.
Esses programas possuem milhares de elementos de dados, alguns redundantes,
inconsistentes, ou incompreensveis, e milhares de linhas de cdigo, alguma
obsoletas, outras incorretas. Utilizando ferramentas CASE pode-se evitar alguns
problemas de dados nos novos sistemas, mas a maioria dos aplicativos no possui
fora para detectar ou corrigir problemas de dados em sistemas existentes
(SOMMERVLLE, 2003).
De acordo com Sommerville (2003) a princpio, se a funcionalidade do
programa permanecer inalterada a reengenharia de dados no ser necessria.
50

Porm, na prtica, existem alguns fatores pelos quais os dados precisam ser
modificados, como:
Degradao dos dados: existncia de dados duplicados ou redundantes,
armazenados em diferentes partes do programa com diferentes formatos. Ainda, os
dados podem no refletir alteraes no ambiente externo.
Limites impostos aos programas: quando o sistema precisa tratar de um
volume maior de dados do que foi previsto pelos projetistas.
Evoluo da arquitetura: na migrao de arquitetura centralizada para
distribuda, o acesso aos dados pode ser feito remotamente, por vrios usurios e ao
mesmo tempo.

4.3 VANTAGENS DA REENGENHARA

A reengenharia a forma que muitas organizaes esto buscando para
manter seus softwares, livrando-se das manutenes difceis e da degenerao de
suas estruturas. Por este motivo, importante que o resultado desse processo seja
confivel. 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 padres de
desenvolvimento claramente documentados, e a caractersticas implcitas
que so esperadas de todo software desenvolvido por profissionais
(PRESSMAN, 2006).

Realizar a reengenharia resultante de fatores como a necessidade de
melhoria da qualidade dos servios e produtos oferecidos, a compresso das
margens de lucro, a reduo do ciclo de vida dos produtos, a diminuio da
interferncia dos governos e dos subsdios, a exploso tecnolgica, o rpido
crescimento do conhecimento humano, a maturidade dos mercados de consumo e a
globalizao da economia (HAMMER, 1994).
Outros fatores so relacionados com a complexidade das atividades
empresariais, tais como a busca por produtividade; a flexibilidade frente s
constantes mudanas; a concentrao no ramo de negcio; os relacionamentos com
clientes, com o meio ambiente e com os governos; o apoio de consultores; a
parceirizao; a gesto e a remunerao dos recursos humanos por resultados.
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 documentao
relacionada e faz com que ela seja de mais fcil compreenso. E como resultados
disso, as possveis manutenes no software vo ser menos requisitados e quando
a mesma for, ser de fcil resoluo, uma vez que o programa estar mais bem
estruturado e documentado (SOMMERVLLE, 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 servios que a organizao lhe presta (ou
pode vir a prestar) para, a partir da, identificar as atividades crticas desse ponto de
vista, as quais devem comear por ser submetidas a uma avaliao do seu atual
desempenho (MAR, 2008).
Esta medio da avaliao do desempenho feita atravs de benchmarking,
isto , de uma sistemtica comparao de indicadores-chave da performance de
processos (key process performance indicators) entre a organizao em causa e os
seus concorrentes melhor cotados no mercado, frequentemente essa comparao,
envolve organizaes de outros setores de atividade mas com processos
semelhantes (MAR, 2008).
Centrando a ateno nesses processos e atividades crticas (sobretudo nos
que acrescentam maior valor e esto com desempenho inferior ao "melhor
da classe"), h que proceder ao seu redesenho, se necessrio a partir do
zero (isto , de uma folha de papel em branco) (MAR, 2008).

Com alguma frequncia, nesse redesenho possvel incluir aquilo que
poderemos designar por "pontos de ruptura" (breakthrougs), entendidos como sendo
algo que permite alcanar uma vantagem competitiva significativa e percepcionada
pelo mercado, como tendo introduzido neste um elemento diferenciador, que
normalmente resulta um acrscimo sustentado da quota de mercado (MAR, 2008).
As tecnologias de informao tm proporcionado muitos dos "pontos de
ruptura" que chegam ao nosso conhecimento como elementos fulcrais de casos bem
sucedidos de reengenharia, mas no a sua nica fonte. Portanto outros elementos
tambm contribuem para o sucesso da reengenharia, como por exemplo, a adoo
de novos mtodos de trabalho, novas tecnologias de produo, novo desenho de
produtos e, inevitavelmente, novas formas de participao dos recursos humanos
(MAR, 2008).
52

Outra vantagem so os riscos reduzidos, pois existe um alto risco em
desenvolver um software novo que seja essencial. Podem ser cometidos erros na
especificao do sistema e ocorrer problemas de desenvolvimento, a importncia da
reengenharia est em possibilitar que todas as funcionalidades do software legado
no sejam perdidas, o que aconteceria se fosse optado pelo desenvolvimento de um
novo software (MAR, 2008).
Uma das maiores vantagens da reengenharia que ela preserva a soluo
existente do negcio em uma nova arquitetura tcnica e uma soluo que deve ser
considerada pelas empresas, pois os custos de desenvolvimento e implantao de
um novo sistema podem ser muito altos. Estudos tm mostrados que reengenharia,
quando aplicada apropriadamente, geralmente promove custo efetivo e menos riscos
do que o desenvolvimento de um novo sistema (CAGNN, 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 programao mais moderna. As vantagens da reengenharia
se destacam muito quando se trata de custo para as empresas e assim como de
tempo para a introduo do novo sistema na rotina da empresa (LEMOS, 2003).

4.4 DFCULDADES NO PROCESSO DE REENGENHARA

Atualmente, a qualidade dos softwares est cada vez melhor, a tecnologia e a
mobilidade est ao alcance de todos, porm ao mesmo tempo em que a tecnologia
evolui, muitas pessoas e gestores de organizaes no 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, so mantidos
ativos para qualquer que seja a eventualidade e sua perda um risco que a
organizao prefere correr (SLVA, 2005).
A quantidade de cdigo em sistemas legados imensa. Em 1990, estimava-se
que existiam 120 bilhes de linhas de cdigo fonte de sistemas legados, a maioria
em COBOL ou FORTRAN (so linguagens de programao com facilidades
limitadas de estruturao de programas e dados). A migrao ou alterao desses
softwares gera grandes desafios tcnicos, uma vez que a perda de funes e custo
so as principais delas (BENNETT, 1995).
53

Ao mesmo tempo em que o software legado traz incorporado a ele o
acmulo de anos de experincia e refinamento, traz tambm todos os vcios
e defeitos vigentes na poca de seu desenvolvimento. Porm o que hoje
chamado de vcio e defeito, naquela poca era a melhor indicao para a
resoluo do problema (BENNETT, 1995).

Existem fatores que esto 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 organizaes, ento 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 no mais um empecilho no desenvolvimento. Contudo, no
desenvolvimento do software sempre se prezou pela eficincia em detrimento da
clareza e estruturao do programa, o que leva a sucessivas manutenes e
consequentes degeneraes no software (BENNETT, 1995).
Muitos softwares legados so crticos para os negcios das organizaes que
os possuem, pois com eles tm embutidas informaes dos negcios e
procedimentos, que na maioria das vezes no esto documentados. O risco de
remover e reescrever tais programas so grandes, pois muita informao teria que
ser redescoberta por tentativa e erro. Consequentemente, as organizaes de um
modo geral, preferem no "aposentar seus softwares legados e mant-los em uso,
com adaptaes s novas necessidades (BENNETT, 1995).
Muitos gerentes de tecnologia de informao tm medo de migrar para novas
tecnologias ou por que no confiam na tecnologia ou por que no confiam no seu
corpo tcnico de pessoal. As dificuldades devem ser enfrentadas, pois qualquer
software que no evoluir continuamente, torna-se menos til no mundo real (DNZ,
2010).
Segundo Bennett (1991), os motivos de maior relevncia para manter o
software legado so:
Desestruturao e dificuldade de entendimento do cdigo, pois o software foi
desenvolvido antes da introduo dos mtodos de programao estruturada;
Programadores que no participaram do desenvolvimento de software
sentem dificuldade em entender e mapear a funcionalidade para o cdigo fonte;
Documentao desatualizada, no auxiliando em nada a equipe de
manuteno;
Dificuldade de predizer as consequncias de efeitos colaterais;
54

Dificuldade de administrar mltiplas alteraes concorrentes.
Vrias empresas se esquecem de considerar o risco de perda de capital
humano e o risco da soluo 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 manuteno menor e tm o potencial de
agregar mais valor em todo sistema, em especial no aspecto de usabilidade (DNZ,
2010).
O nmero de sistemas que precisa ser modificado est aumentando
gradualmente, existe fila de espera para pedidos de manuteno. Assim fica claro
que s vezes impossvel para as organizaes investirem em novos sistemas para
melhorar a eficincia organizacional (DNZ, 2010).
O problema de manuteno de software legado complexo, pois esses
sistemas no so simples programas, desenvolvidos e mantidos, a maioria
composta de outros diferentes programas que, de alguma forma compartilham dados
(DNZ, 2010).
Empresas com o problema de software legado devem capacitar seus gerentes
em reengenharia de software. sso vai garantir no s que os gerentes tomem uma
atitude em relao ao software legado como tambm vai contribuir para uma
execuo eficaz e eficiente do processo de migrao. Para resolver esses
problemas importante partir da etapa de conhecer as novas tecnologias, estudar
sobre novas linguagens, novos servidores de aplicao e novas arquiteturas e
investir em treinamento do corpo tcnico (DNZ, 2010).

4.5 CUSTO

A complexidade e tamanho dos programas legados tm influncia direta no
custo de manuteno. O clculo do custo de manuteno do software legado em
geral equivocado, pois no "levam em conta os riscos envolvidos na sua
permanncia (YOURDON, 1990).
Pesquisas revelam que mais de 50% do custo de um produto de software est
relacionado com as atividades de manuteno, havendo casos de este percentual
chegar at a 85%. Em alguns negcios, estima-se que 80% de todos os gastos com
software so consumidos pelas manutenes e evolues dos sistemas
(YOURDON, 1990).
55

Os custos da reengenharia dependem da extenso 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
implantao de um novo sistema, contudo a reengenharia a medida mais cabvel
(MAR, 2008).

F97(a 16 * C7)to $a (%%!9%!,a(a
Fo!t%- LORGES" 200=

O custo envolve a qualidade do software que vai sofrer reengenharia; as
ferramentas disponveis para fazer o processo de reengenharia; a quantidade de
dados que devero passar por reengenharia de dados e tambm a disponibilidade
de pessoal habilitado (MAR, 2008).
O objetivo aumentar os lucros, elevando a produtividade e diminuindo os
custos de produo, para tentar aumentar o mercado consumidor, que exige
qualidade e preos acessveis (MAR, 2008).
A reengenharia reduz todos os tipos de desperdcios, reestruturando o
processo. Por exemplo: voc corta uma folha de alumnio em tiras e, no final, sobra
uma tira que menor que a largura necessria. 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
mquinas mais eficientes. Assim ser possvel reduzir custos sem prejudicar
produtos e servios (MAR, 2008).
A reduo de custo obtida atravs da eliminao de atividades que no
agregam valor ao produto e so dispensveis no sistema (MAR, 2008).
claro perceber que existe um mito se tratando do custo da reengenharia, pois
se tratando de nvel curto prazo, o custo ser elevado pois acontecer uma
reestruturao do sistema, mudanas geram gastos. Contudo, a nvel de longo prazo
56

trar muitas vantagens, uma vez que o gasto com manuteno e mo de obra
especfica no ser um gasto decorrente nos prximos anos, a solicitao de
manuteno ser menor (YOURDON, 1990).

4.6 FERRAMENTAS DE AUXLO REENGENHARA

Existem ferramentas com a finalidade de auxiliar a execuo da reengenharia.
A maioria das ferramentas utilizada na etapa de engenharia reversa do sistema a
ser reconstrudo (PRESSMAN, 2006).
As ferramentas CASE (do ingls Computer-Aided Software Engineering) uma
classificao que abrange todas as ferramentas baseada em computadores que
auxiliam atividades de engenharia de software, desde anlise de requisitos e
modelagem at programao e testes. Podem ser consideradas como ferramentas
automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma
ou vrias 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 deciso, menor quantidade de cdigos de programao,
melhoria e reduo de custos na manuteno, agilidade no retrabalho do
software, entre outras (JANONES, 2010).

As ferramentas baseadas em engenharia reversa esto ainda "engatinhando,
ficando claro que as pesquisas na rea de entendimento de cdigo so muito
importantes e muitas outras pesquisas ainda acontecero (PRESSMAN, 2006).
As ferramentas devem ser adequadas aos processos de reengenharia, e no
os processos adequados s ferramentas. As ferramentas de suporte disponveis
para auxiliar a reengenharia tm influncia sobre os custos de reengenharia
(PRESSMAN, 2006).
Existem muitas ferramentas de reengenharia com aplicabilidade em sistemas
de software. O quadro 1 apresenta vrias dessas ferramentas, mostrando de onde
provm as informaes de entrada e o que cada uma delas produz como resultado
(PRESSMAN, 2006).
O escopo das informaes que cada ferramenta utiliza proveniente do cdigo
fonte do software (cada ferramenta trabalha com cdigo em determinada linguagem
pr-definida) e da base de conhecimento do sistema (constituda por documentao
57

existente, informaes de usurios ou projetistas do software e bibliotecas de
componentes, entre outras) (PRESSMAN, 2006).
Em relao aos resultados produzidos, quando apenas o cdigo fonte
utilizado como entrada, as vises fornecidas so em nvel implementacional e
estrutural. Para obteno de vises mais abstratas (funcional e de domnio), bem
como outras sadas, necessrio utilizar como entrada, alm do cdigo fonte, bases
de conhecimento sobre o sistema (PRESSMAN, 2006).

Quadro 1 - Ferramentas de reengenharia
Fonte: PEKARSK, 2000.

4.7 ESTUDO DE CASO (EXEMPLFCAO)

Estudo de caso retirado da revista "nterdisciplinar Aplicada, ano 2004, cujos
autores so: Eliana Domingues da Cruz Milev e Francisco de Assis Zampirolli.
Segue a baixo o estudo de caso.
58

Esta seo apresenta o estudo de caso da substituio de um mdulo de um
sistema de software denominado "Classificados, utilizado em uma empresa
jornalstica brasileira, que para fins desse trabalho ser chamada J. Papel. Para que
esse sistema atenda os objetivos da empresa, vrios mdulos relacionados entre si
trabalham juntos. Esses mdulos so fortemente interligados, o bom funcionamento
de um mdulo muitas vezes depende do funcionamento dos demais mdulos do
sistema.
Esse estudo se aplica substituio do componente ou de "Classificados, que
responsvel pela captao de anncios da empresa. O J. Papel tem grande parte
de seu lucro oriundo de venda de espao para publicao de anncios solicitados no
caderno de classificados do jornal. Nesse caderno so publicados anncios pagos
pelos clientes com a finalidade de divulgar um produto ou servio. Para a captao
de anncios a empresa trabalha com duas solues com tecnologias diferentes:
Telefones e balces (LEGADO_TEL); e Agncias de Publicidade (LEGADO_AGE).

6&=&1 S)t%1a LEGADO#TEL

Das duas solues existentes, essa (LEGADO_TEL) a mais antiga e
apresenta diversos problemas, como segue:
Sistema pouco flexvel, no parametrizado, qualquer alterao implica em
manuteno no cdigo;
Cdigo escrito com linguagem obsoleta;
Dificuldades em encontrar profissionais que dominem a linguagem;
No usa uma base de dados padro e isso dificulta o desenvolvimento e
integrao com outros sistemas e/ou mdulos;
Espao de armazenamento de dados reduzido e a tecnologia empregada no
permitem ampliaes;
Hardware obsoleto e sem suporte pelo fabricante, portanto com custo elevado
para qualquer necessidade de troca;
Restries para aumento da capacidade de processamento sem a troca total
do sistema (limitado em memria e em processador);
O sistema no tem recursos de visualizao de anncios em sua forma final,
caracterstica importantssima em sistemas de jornal;
59

nvivel o desenvolvimento de interface online para captao de anncios
utilizando navegadores da nternet.

6&=&2 O 3(o>l%1a

A empresa J. Papel tem que acompanhar a evoluo para se manter no
mercado e ainda ampliar seus negcios oferecendo facilidades e melhores servios
aos seus anunciantes e leitores.
O alvo de modernizao o caderno de "Classificados, ele uma das
principais fontes de lucro para a empresa e deve ser modernizado graficamente com
uma melhor distribuio de segmento de mercado permitindo anncios com cor, foto
e destaque de logomarca com melhores resultados para o anunciante. O sistema
LEGADO_TEL por se tratar de um sistema legado, no suporta essa modernizao
grfica e se torna um obstculo para o crescimento da empresa.
No ano de 2003, a empresa entende que esse sistema crtico para a
organizao e que sua substituio vital. Diante disso o J. Papel decide investir em
software.

6&=&3 Alt%(!at'a) $% )ol74?%)

A empresa possui duas alternativas: substituio do sistema por uma soluo
completamente nova ou reengenharia do sistema legado com a substituio do
mdulo de "Classificados.
Desenvolver um software crtico para a empresa uma deciso arriscada, pois
pode demorar meses e at anos para sua finalizao. A empresa no tem esse
tempo, a concorrncia de mercado ajuda a decidir pela segunda e mais confivel
alternativa: substituir o mdulo integrando-o aos demais mdulos do sistema de
"Classificados.
Vrias empresas trouxeram solues, a escolhida foi uma empresa americana
que props uma soluo utilizando ferramentas de desenvolvimento de acordo com
a adotada pelo J. Papel. A soluo escolhida, no entanto, deve manter as
funcionalidades do sistema atual e ainda proporcionar todas as novas funes
oferecidas pelo novo produto. Para que esse resultado fosse possvel, as
especificaes do sistema atual devem ser elaboradas pela equipe do J. Papel
60

seguindo um cronograma construdo baseado em funcionalidades de superfcie sem
um aprofundamento detalhado nos processos envolvidos.
O sistema LEGADO_TEL e suas interfaces com outros mdulos possuem uma
documentao desatualizada, e nessas condies para elaborar especificaes
quando a documentao do sistema no existe ou no est atualizada, a
Engenharia Reversa do sistema em produo uma das formas para documentar o
que est em funcionamento e a Reengenharia propor o processo alternativo. Outra
forma escrever as especificaes com base no conhecimento da equipe envolvida.
Porm, face ao pouco tempo designado para essa atividade, a forma escolhida foi a
segunda, as especificaes foram baseadas no conhecimento da equipe, o que
resultou em especificaes pouco detalhadas que dificultaram o entendimento para
a empresa que oferecia a nova soluo e esquecimento de especificaes de
algumas interfaces interligadas ao mdulo a ser substitudo.

6&=&6 P(o>l%1a) !a )7>)tt745o

A tentativa de integrao da soluo adotada ocorreu durante o ano de 2004,
porm os problemas encontrados foram muitos:
Definio do cronograma imposto fora da realidade;
Prazo de entrega da soluo subdimensionado;
Fase de levantamento extremamente curta no permitindo ao fornecedor da
soluo o tempo suficiente para entender todos os processos e necessidades da
empresa;
O levantamento pouco detalhado resultou em conhecimento insuficiente do
processo atual de produo;
Novas funcionalidades foram solicitadas pela empresa que no existiam no
sistema antigo e tambm no constavam em especificaes;
A empresa precisa se adaptar ao novo sistema j que nem todas as
funcionalidades e regras estavam sendo atendidas;
O novo mdulo oferecia muitas funcionalidades que nem mesmo a equipe
contratada para a implantao sabia como utilizar ou adaptar para as necessidades
da empresa;
61

A soluo adotada foi construda baseada em parametrizaes. Porm muitas
regras especficas de negcio da empresa no eram atendidas atravs de
parmetros e exigia modificao no cdigo do sistema;
Preocupao tardia com as principais interfaces (entradas e sadas);
A soluo no estava sendo utilizada em nenhum outro jornal o que
impossibilitava ver o resultado do produto em uso em outras empresas;
Localizao/customizao do sistema por ser um sistema desenvolvido em
outro pas o tratamento dado ao cdigo de endereamento postal (CEP) precisou ser
modificado, pois o cadastro do CEP no Brasil difere do americano.
Vendas realizadas com carto de crdito, o sistema americano vende com
carto de crdito apenas com pagamento a vista, o sistema original no previa
parcelamentos;
Problemas de comunicao, o sistema foi escrito em ingls e os primeiros
testes com a rea usuria foram complicados por no terem sido traduzidos na
lngua portuguesa. Alm disso, as telas e mensagens de erros e alertas foram sendo
traduzido na fase de testes, o que gerou tradues mal feitas e incompletas e
descontentamento dos usurios;
ntegrao no estava totalmente pronta e com tantas modificaes feitas na
ltima hora gerou instabilidade (travamento do sistema);
Paralelo substituio do sistema, uma grande mudana ocorria ao mesmo
tempo, a terceirizao do servio 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 soluo acreditava que o problema era de suporte, e
dessa forma o problema no era atendido com rapidez necessria;
Mudanas de regras ditadas por usurios eram constantes durante a fase de
testes de sistema;
Com tantas mudanas a apresentao de bugs era frequente;
A existncia de todos esses problemas gerou um clima de instabilidade e
conflitos na equipe e culminou na sada dos dois principais gestores do projeto, um
de cada empresa, o que prejudicou ainda mais o desempenho da equipe envolvida;
Com a sada dos dois principais gestores, a responsabilidade passou a
gestores com alto conhecimento tcnico, porm com pouco conhecimento dos
62

processos do sistema "Classificados e com nenhum tempo para aquisio do
conhecimento.
Apesar de tantas dificuldades, ainda acreditava-se que a empresa poderia
corrigir e adaptar o sistema, pois at ento apresentava problemas de cdigo e
estrutura que poderiam ser corrigidos. Com tantos contratempos, a empresa
fornecedora da soluo somente conseguiu imprimir um teste do caderno de
classificados as vsperas da finalizao do prazo de entrega do produto, prazo que
j havia sido prorrogado trs vezes. O produto gerado durante os testes de
aceitao apresentou uma srie de problemas. A empresa contratante decidiu por
rescindir o contrato.

6&=&< Sol745o alt%(!at'a

A substituio do sistema fracassou, mas a necessidade da empresa de
modernizar seu caderno de Classificados era ainda prioritria. Pressionados pela
rea comercial que tinha um produto novo a lanar, a modernizao de seu caderno
de Classificados, a gerncia de informtica decide adotar um plano B.
O plano B era muito mais simples e econmico para a empresa. A empresa
brasileira responsvel pela soluo do sistema LEGADO_AGE, que atende as
agncias de publicidade, oferecia uma substituio do software com as mesmas
funcionalidades do software da primeira soluo escolhida e ainda uma opo para
o lanamento do novo produto.
No entanto, o plano B somente foi aprovado pela diretoria e reas usurias
porque a equipe que representava a fornecedora brasileira possua profundo
conhecimento do sistema legado que seria adaptado para o lanamento do novo
produto e futuramente substitudo. Alm do conhecimento, a fornecedora brasileira
tranquilizou os representantes do J. Papel com um prottipo do caderno de
Classificados modernizado antes mesmo da aprovao do projeto.
Enfim, a soluo oferecida tornou possvel o lanamento do novo produto e o
lanamento do novo caderno de Classificados foi um sucesso e citam-se os
principais motivos que levaram a isso:
O J. Papel decide pela adoo do Plano B, tendo em mos um prottipo do
resultado final, ou seja, um teste com o caderno de Classificados modernizado de
acordo com as especificaes da rea comercial;
63

O J. Papel designa um novo gestor com profundo conhecimento do sistema
de Classificados e das regras de negcio da empresa para gerenciar o plano B;
A empresa contratada tambm tem conhecimento do sistema existente e das
regras de negcio especficas do J. Papel e efetua um levantamento preciso de
todos os processos afetados com a modificao;
O cronograma imposto rejeitado e aps o planejamento apresentado um
cronograma dentro da realidade;
Prazo de entrega proposto aceito pelas reas Comercial e Tecnologia da
nformao;
Todas as interfaces (entradas e sadas) so cuidadosamente analisadas e
suas modificaes planejadas com antecedncia;
Todas as adaptaes necessrias para a modificao dos processos so
efetuadas;
Por ser um produto nacional, os problemas decorrentes de localizao e
customizao do sistema no ocorreram;
Toda e qualquer mudana de regra foi cuidadosamente analisada antes de
ser aceita, recusada ou adiada;
Comunicao facilitada, utilizando o idioma nativo.

6&@&@ Co!)$%(a4?%) :!a)

O estudo de caso relata dois experimentos de manuteno de software na qual
a empresa (denominada neste artigo por "J. Papel) possua duas alternativas:
substituio do sistema por uma soluo completamente nova ou reengenharia do
sistema legado com a substituio do mdulo de "Classificados. A opo escolhida
foi a segunda.
A primeira tentativa de reengenharia fracassou, e os motivos do fracasso, so
explicveis, uma vez que os processos no foram bem aplicados. No momento em
que deveria aplicar a "engenharia reversa foi optado pelo caminho de
parametrizao, e este fez perder regras especficas de negcio. No houve um
melhor detalhamento dos processos anteriores no qual resultou na perca de
processos de produo importantes. A definio de prazos no foi estruturada e
ocasionou desorganizao em todos os setores.
64

Entre outros problemas que aconteceram e que detalhado no estudo de caso,
imprescindvel dizer, que quando os processos de reengenharia no so bem
feitos o resultado o fracasso. Muitos gestores de T 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 jornalstico 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 tcnicas de
reengenharia para obter a documentao do sistema existente, bem como seguir um
modelo de padronizao de manuteno.
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%. Porm 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 especficas de
negcios, que nenhum outro software possui, o melhor caminho optar pela
reengenharia do mesmo. Porm se existir um software no mercado que supra todos
os requisitos e funcionalidades, implantar um novo software pode ser a melhor
soluo vivel.

65

< METODOLOGIA

At este ponto da obra, foi apresentada a pesquisa bibliogrfica, que remete a
uma srie de conceitos e perspectivas sobre a reengenharia em software legado.
Deixando bem claro seus processos, vantagens, desvantagens, custos, usabilidade
e definies. 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
T que se submeteu a uma entrevista (por troca de e-mails) com perguntas
relacionadas ao processo de reengenharia em software legado em que ele teve
participaes. Atravs da entrevista perceptvel a concepo de vrios tpicos
citados no referencial bibliogrfico.
A segunda parte da pesquisa de campo foi de cunho quantitativo, a mesma
um questionrio realizado pela empresa de consultoria Deloitte & Touche, voltado
para as 500 maiores empresas portuguesas (segundo a revista Exame), em que visa
mostrar a viso do gerente de T dentro do diversos "tpicos da reengenharia em
uma organizao.
Ter como parmetro uma pesquisa qualitativa e outra quantitativa faz enfatizar
o objetivo inicial do trabalho e dar sustncia ideia de que preciso pensar no
software como um otimizador de processos.

5.1 COLETA E DSCUSSO DOS RESULTADOS - PARTE 01

Em entrevista com Keiji Sakai, bacharel em cincia da computao, MBA e
certificado em diversas reas de gerncia, que ocupa h dois anos e meio o cargo
de diretor de T da BM&FBOVESPA, e que j passou por diversas instituies
financeiras, entre elas: ESM Consultoria e Projetos em T LTDA; JPMorgan Chase;
HSBC Bank Brasil; Deutsche Bank S/A - Banco Alemo; UNBANCO; Banco Matrix
S/A; Banco de nvestimentos Garantia e Banco Norchem, exprime de forma sucinta
suas diversas experincias em projetos de reengenharia em software legado.

Vo+M N/ t%'% o3o(t7!$a$% $% 3a(t+3a( $o 3(o+%))o $% (%%!9%!,a(a $%
)o:tFa(%O
SAKA: Sim, em diversas instituies financeiras.
66

S% )1" $)+o((a )o>(% o) 3(!+3a) 3o!to)& L%'a!$o %1 +o!)$%(a45o
a$a3ta45o $o) 7)7/(o)" 1%l,o(a)" +7)to)" 'a!ta9%!) % $%)'a!ta9%!)&
SAKA: Em primeiro lugar, importante explicar o que considero reengenharia de
software na minha viso, reengenharia de software reconstruir uma aplicao ou
parte dela, corrigindo defeitos existentes ou saneando cdigos antigos, ou ainda
renovando componentes para a plena utilizao dos melhores recursos de software
e hardware existentes.
Neste sentido, em reengenharias de software onde no ocorreram grandes
mudanas de interao aos usurios, mas trouxeram claramente vantagens, seja na
correo ou na melhoria de performance, a recepo dos mesmos foi sempre muito
positiva. Naquelas onde a interao dos usurios com a aplicao teve alterao,
principalmente devido a grandes rupturas tecnolgicas (mainframe para micro
informtica, plataforma DOS para Windows, desktops para tablets), as primeiras
movimentao provocaram resistncia dos usurios principalmente devido
mudana da rotina operacional dos mesmos. Com relao a custos, vantagens e
desvantagens, existe uma falsa percepo que a reengenharia seria "mais barata
do que um novo desenvolvimento em algumas situaes isto no foi verdade, pois
o nvel de integrao dos legados aliado a complexidade de novas tecnologias
encareceu alguns dos projetos. Em algumas situaes, o custo de uma
manuteno corretiva do sistema legado seria muito mais vantajoso que uma ao
de reengenharia de software.

O P7% l%'o7Ql%'a a %13(%)a a 3a))a( 3%lo 3(o+%))o $% (%%!9%!,a(a !o
)o:tFa(%O
SAKA: Alguns dos grandes motivadores: estratgia de downsizing da instituio,
custo de manuteno de legados, nvel de instabilidade de legados em decorrncia
de manutenes e customizaes "complementares e por fim, estratgia de
negcios para lanamento de novas interaes entre as aplicaes das instituies
e os clientes finais.

.7a) )5o o) 3(!+3a) a)3%+to) P7% 71 9%)to( $% TI 3(%+)a a'ala( )%
t(ata!$o $o R)o:tFa(%SO
SAKA: A criticidade da aplicao que precisa ser reescrita precisa ser avaliada
numa instituio financeira onde algumas aplicaes precisam funcionar em regime
67

24 x 07, o risco de instabilidade pode provocar perdas milionrias e fuga de clientes.
Alm disto, em ambientes extremamente regulados a consistncia das informaes
(incluindo eventuais clculos) so de extrema criticidade. Neste sentido, planos
para garantir a qualidade do sistema devem ser colocados em prtica, como por
exemplo, testes regressivos, certificaes com o mercado, produo paralela e
simulaes dos requisitos no funcionais devem estar no radar do gestor de T.

.7a) )5o o) 3(!+3a) 1ot'o) P7% l%'a1 ao Ra>a!$o!oS $o )o:tFa(%
l%9a$oO
SAKA: Obsolescncia aliada a instabilidade e ao alto custo de manuteno. No
caso da obsolescncia, o risco operacional em decorrncia de descontinuidade de
software, hardware e tecnologia pode obrigar as instituies a partir para uma
estratgia de reengenharia.

No 3(o+%))o $% (%%!9%!,a(a o ()+o $% 3%($%( :7!+o!al$a$%) $o )o:tFa(%
l%9a$o a!$a %T)t%" P7a) )5o a) 1%$$a) 3a(a tal a+o!t%+1%!toO
SAKA: Para evitar este tipo de situao, o mapeamento das funcionalidades
fundamental. Na inexistncia de documentao atualizada, os trabalhos tradicionais
de Analise de Sistemas e Analise de Processos deve fazer parte do projeto.

Vo+M 7tl;a al971 1o$%lo 3a(a $%)%!'ol'1%!to $o 3(oN%to $% (%%!9%!,a(a
o7 a$a3ta al971 1o$%loO
SAKA: Sobre metodologia ou modelos, em cada instituio utilizvamos
metodologias e modelos diferentes. O importante tanto na definio dos artefatos
como na metodologia a de no burocratizar o processo, com controles e
documentaes no necessrias.

O 3(o+%))o $% (%%!9%!,a(a $% )o:tFa(% 3o$% )%( a R)ol745oS $o) 3(o>l%1a)
$o) )o:tFa(%) l%9a$o)O
SAKA: Neste ponto importante ressaltar que durante muitos anos o mercado de T
do Brasil estava fechado para provedores estrangeiros (reserva de mercado) e com
isto, o desenvolvimento de solues domsticas foi amplamente aplicado. Com o
fim da reserva de mercado e a vinda de vrios provedores com solues globais, a
dependncia de legados internos diminui. Por exemplo, para uma empresa que na
68

dcada de 80 decidiu desenvolver um sistema de BackOffice para controlar todo o
seu processo produtivo, eu no partiria para a reengenharia da soluo e sim,
buscaria um ERP de mercado.
Para solues especficas que no so atendidas pelo mercado e que so criticas
para as organizaes, a reengenharia a soluo.

At7al1%!t%" (%%!9%!,a(a E a 1%l,o( )ol745o 3a(a )o:tFa(% l%9a$oO
SAKA: A mesma resposta da questo anterior se aplica aqui. Reengenharia
apenas para sistemas crticos que no podem ser substitudos por solues de
mercado.

.7al E o 1o1%!to $% a3l+a( a (%%!9%!,a(a !o )o:tFa(%& .7a) a)3%+to)
+o!t(>7%1 3a(a ))oO
SAKA: A reengenharia deve ser aplicada nos momentos em que os software
legados no esto mais aptos a atender as necessidades. Por exemplo, volume
transacional, performance, tecnologia, alteraes regulatrias e estratgias de
negcio.

.7al o 3a3%l $o 9%(%!t% $% TI" !a 9%)t5o % P7al$a$% $o )o:tFa(%O
SAKA: Em algumas organizaes, a qualidade do software de responsabilidade
do gestor de T junto com um gestor de Qualidade. Mas com relao aos aspectos
tcnicos com os requisitos no funcionais, de arquitetura, segurana da informao
e tecnologia adotada, a responsabilidade principalmente do gestor de T.

.7al E a ')5o 38)*(%%!9%!,a(aO
SAKA: Tive boas e ms experincias mas no em decorrncia da reengenharia
em si. Os maus resultados foram em decorrncia de falhas, seja na especificao
dos requisitos funcionais, seja na construo das solues.

O) 9%(%!t%) $% TI %)t5o 3(%3a(a$o) 3a(a a+%ta( o 3(o+%))o $% (%%!9%!,a(aO
SAKA: Um gerente de T da rea de Desenvolvimento tende a adorar um projeto de
reengenharia gerentes de infraestrutura podem gostar (em situaes onde a
reengenharia permitiria uma reviso dos ambientes tecnolgicos) ou no (em
69

situaes onde a reengenharia altera os procedimentos operacionais e de
produo).

Co!)$%(a4?%) :!a) 0!%)ta 3a(t% :+a l'(% $o %!t(%')ta$o" (%))alta( al971
3o!to P7% !5o :o +ta$o" +o!ta( %T3%(M!+a $% '$a 3(o:))o!al" $+a)" o7
)%Na" t7$o P7% '%!,a a+(%)+%!ta( ao t(a>al,o2&
SAKA: Um projeto de reengenharia de software no facilmente aprovado. O
argumento de necessidade para melhoria de ambientes ou mitigao de riscos
operacionais sem a quantificao dos benefcios financeiros no so fortes o
suficiente para que um CO tome a deciso de aprovar um projeto. Mesmo os
COs que patrocinam projetos de reengenharia por conta prpria, assumem riscos
que, caso os projetos no sejam extremamente bem sucedidos, colocam sua
credibilidade na instituio em risco. Considerando a "comoditizao cada vez
maior de software, em minha opinio so poucas as reais necessidades de
reengenharia de software nos dias atuais.

A seguir esto os principais pontos que devem ser discutido mediante
entrevista:
Mediante entrevista, possvel perceber que s vezes a nica opo a
reengenharia, pois a descontinuidade do software e limitaes do hardware faz com
que o processo organizacional tambm no evolua. Contudo, a reengenharia deve
ser aplicada apenas para sistemas crticos que no podem ser substitudos por
solues de mercado.
Sobre os "custos interessante a forma como colocado, uma vez que os
custos, s sero altos ou baixos dependendo da situao a qual o software se
encontra, porm bom lembrar que um software que passa por reengenharia, tem
sua performance e funcionalidades melhoradas, com isso, pedidos de manuteno,
sero cada vez menores, e o gasto com o mesmo diminuir.
Outro ponto interessante da entrevista foi a forma como o software "inserido
na organizao, sendo instrumento de negcio e de lucro, porm o mau
funcionamento do mesmo ir acarretar problemas em toda a hierarquia da
organizao. A partir do momento em que o software legado no atende mais as
necessidades hora de pensar no que fazer, seja passar por um processo de
reengenharia ou buscar algo novo no mercado.
70

visvel o quanto difcil e complexo implantar e ter o projeto de reengenharia
aceito, uma vez que ainda existe insegurana nos processos, pois como foi dito, os
processos de reengenharia precisam ser bem feito para dar certo. Existem hoje
diversas ferramentas CASE que agilizam os processos, porm elas no so os
nicos fatores determinantes, uma boa gesto crucial.
Foram usados dois termos na entrevista que merecem uma definio, para
melhor entendimento da resposta, so eles:
Downsizing: em portugus significa "achatamento, uma tcnica conhecida
em todo o mundo e que visa a eliminao de processos desnecessrios que
engessam a empresa e atrapalham a tomada de deciso, com o objetivo de criar
uma organizao mais eficiente e enxuta possvel.
Regime 24x07: uma abreviao que significa "24 horas por dia, 07 dias por
semana", geralmente se referindo a um negcio ou servio disponvel o tempo todo,
sem interrupo.

5.2 COLETA E DSCUSSO DOS RESULTADOS - PARTE 02

Apesar de ser um conceito relativamente recente, a reengenharia parece j ter
chegado at ns, 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 questionrio est disponvel no ANEXO A desta obra.
De acordo com pesquisa 84% dos gerentes de T sabem ou j ouviram falar
sobre reengenharia, contra 16% que no tinham conhecimento. Como mostra o
grfico um (1) abaixo:

G(/:+o 1 O P7% E (%%!9%!,a(a
Fo!t%- Deloitte & Touche
71

Dessas empresas, 43% j tinham implementado projetos de reengenharia e
55% estavam em fase de implementao. Apenas 2% ainda no tinham implantado.
Conforme o grfico dois (2):

G(/:+o 2 I13l%1%!ta45o $% 3(oN%to

Muitos dos programas ditos de reengenharia no so de fato. Este , alis, um
dos motivos de insucesso de alguns programas de pseudo reengenharia. Em
relao ao futuro, as perspectivas indicam que 62% das empresas inquiridas
pretendem avanar com novos projetos, contra 38%. Representado no grfico trs
(3) a seguir:

G(/:+o 3 A'a!4o +o1 !o'o) 3(oN%to)

E destes, que tencionam avanar com novos projetos de reengenharia, a
grande maioria, 88% espera implement-los no prximo ano. Grfico quatro (4),
abaixo:

G(/:+o 6 * Pla!%Na1%!to $% 71 !o'o 3(oN%to $% (%%!9%!,a(a
72

Em relao aos motivos que levaram a aplicar a reengenharia, chama ateno
o fato de 35% dos gerentes de T alegarem "os custos demasiado elevados, ponto
este tratado na pesquisa bibliogrfica, uma vez que manter o software legado
muito custoso para uma organizao. Com 16% segue a "perda de competitividade
onde um software melhor estruturado, tm uma performance elevada em relao ao
legado. de suma relevncia destacar os 10% na "diminuio de lucros, na qual
comprova o quanto o legado importante no que diz respeito a negcios e que o
mesmo acarreta perda de lucro. De acordo com grfico cinco (5) abaixo:

G(/:+o < Mot'o) $a a3l+a45o $a (%%!9%!,a(a

O nvel de satisfao em relao ao ps-reengenharia atinge 68%, no
havendo nenhum registro de caso de grande insatisfao. Conforme grfico seis (6):

G(/:+o @ G(a7 $% )at):a45o

De acordo com o grfico sete (7), 42% dos processos que foram objetos de
reengenharia foram os processos operacionais, seguidos 38% por processos infra
estruturais e 20% toda a organizao, o que eleva a preocupao com o legado em
um todo.
73

G(/:+o = P(o+%))o) o>N%to) $% (%%!9%!,a(a

No grfico oito (8) foi possvel perceber que 36% das empresas implementaram
programas de reengenharia recorrendo apenas a recursos internos. Para alm de
que 8% conseguiram o mesmo recorrendo apenas a consultores externos.

G(/:+o I * A P7%1 :o (%+o(($o 3a(a o 3(o+%))o $% (%%!9%!,a(a

Assim, de acordo com as respostas recebidas nenhuma empresa tenciona usar
apenas os consultores externos em prximos projetos, os seja, pretendem buscar
equipes mistas (88%). Conforme grfico nove (9):

G(/:+o H Pla!o) 3a(a (%+o((%( !o :7t7(o

Relativamente s maiores dificuldades na implementao da reengenharia,
numa escala de 1 a 5, os empresrios que participaram do estudo, referiram mais
frequentemente a "resistncia mudana", as "perspectivas irrealistas" e as
"limitaes dos sistemas informticos existentes". A resistncia mudana um
74

ponto muito questionado, pois o usurio tem muita dificuldade de aceitar o novo,
mesmo este trazendo diversas vantagens perspectiveis ou no para o mesmo.

G(/:+o 10 D:+7l$a$%) !a 13l%1%!ta45o $a (%%!9%!,a(a

possvel concluir, que os gestores portugueses so grandes entusiastas da
reengenharia e que os graus de conhecimento e satisfao so esmagadoramente
positivos.
No h duvida que seja necessrio repensar a forma de funcionamento das
organizaes. As constantes mutaes a que assistimos obrigam a um novo tipo de
organizaes, mais flexveis, mais geis, que respondam de forma mais adequada
s solicitaes do mercado.
O processo de reengenharia pode contribuir para isso, contudo necessrio
estarmos conscientes que a reengenharia no resolve todos os problemas, ainda
menos quando mal interpretada e aplicada.
Muitas empresas prosseguiram o mito da reengenharia atravs da mera
simplificao de processos ou, na maioria dos casos, de uma automatizao dos
processos existentes. Este equvoco provocou, em alguns casos, uma diminuio da
competitividade, uma vez que maioria destes projetos estiveram associados
grandes investimentos que, ou diminuram a capacidade financeira das empresas ou
provocaram um acentuado endividamento.
Desta forma, cada vez mais importante que as empresas concentrem os seus
esforos em processos de mudana que sejam realmente capazes de alcanar o
aumento de produtividade necessrio para assegurar a sua sobrevivncia.
75

CONCLUSAO

Mediante estudo possvel 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 questo e o
desenvolvimento de tecnologias.
A importncia da reengenharia est em possibilitar que todo conhecimento
agregado (funes e procedimentos especficos de carter particular e nico) ao
software legado no seja perdido. Porm se existir algum software no mercado que
faz todas as funes do software legado e com um custo reduzido, a melhor opo
seria sim, implantar este novo software.
Finalizando, conclusivo que o software quando chega ao seu estado crtico,
precisa de medidas para que o mesmo continue em uso, o papel de um gestor de T
buscar pela melhor soluo.

76

REFERBNCIAS

BENNETT, K. H; WARD, M. P. S73o(t% A7to1at;a$o $% Ma!7t%!45o $%
So:tFa(%, 1991.
______. MEto$o) Fo(1a) 3a(a ))t%1a) l%9a$o), 1995.

BSBAL, Jesus. U1a ')5o 9%(al $a 19(a45o $o ))t%1a l%9a$o, 1999.

BORGES, Rosemary. S)t%1a) l%9a$o), 2007.

BRAGA, Jose Luiz; PNTO, Hebert Laroca Mendes. S)t%1a) l%9a$o) % !o'a)
t%+!olo9a)- tcnicas de integrao e estudo de caso, 2004.

BROOKS, F. P. E!)ao) )o>(% E!9%!,a(a $% So:tFa(%. 1. ed. MA: Addison-
Wesley, 1995.

CAGNN, Maria stela. Pa(:at%" 71a +o!t(>745o 3a(a a (%%!9%!,a(a $%
)o:tFa(% >a)%a$a %1 l!97a9%!) $% 3a$(?%) % :(a1%Fo(U), 2005.

CHKOFSKY, E. J.; CROSS, J. H. R%'%()% E!9!%%(!9 a!$ D%)9! R%+o'%(V- A
Taxonomy. EEE Software, 1990.

COLEMAN, D.; ARNOLD, P. D%)%!'ol'1%!to O(%!ta$o a O>N%to)- O mtodo de
fuso, 1994.

CORDERO, Edson dos Santos. I!t(o$745o a C+lo $% V$a $o So:tFa(%, 2012.

DALMASO, Alanderson. C()% $o )o:tFa(%, 2013.

DNZ, Samuel. 3 problema do soft4are legado. Disponvel em:
<http://blogdosamueldiniz.blogspot.com.br/2010/02/o-problema-do-
softwarelegado.html>. Acesso em: 19 Fev. 2013.

HAMMER, M.; CHAMPY, J. R%%!9%!,a(a- (%'ol7+o!a!$o a %13(%)a %1 :7!45o
$o) +l%!t%)" $a +o!+o((M!+a % $a) 9(a!$%) 17$a!4a) $a 9%(%!+a. Rio de
Janeiro: Campus, 1994.

HARAND, M.; NNG, J. Q. J!oFl%$9%*La)%$ P(o9(a1 A!alV))- EEE Software,
1990.

JALOTE, P. U1a a>o($a9%1 !t%9(a$a 3a(a E!9%!,a(a $% So:tFa(%. 3. ed. New
York: Springer, 2005.

JANONES, Ramos de Sousa. .7al$a$% $% So:tFa(%- Uma questo de eficincia,
2010.

LEHMAN, M. M. P(o9(a1)" L:%*CV+l%)" a!$ t,% LaF) o: 3(o9(a1 E'ol7to!,
1985.

77

LEMOS, Gizelle Sandrini. Pa$(?%) $% (%%!9%!,a(a a7Tla$o) 3o( $(%t(;%) $%
P7al$a$% $% )o:tFa(%, 2003.

LOVATTO, Robinson. E)t7$o $% 'a>l$a$% )o>(% a 19(a45o $% 71 ))t%1a
O(a+l% :o(1) @ 3a(a 71 a1>%!t% F%>, 2012.

MAR, Charles Roberto Boeing. R%%!9%!,a(a $% So:tFa(%- Estudo de Caso em
um Sistema de Automao, 2008.

MARTNS, Mrcia M. G. G%(%!+a1%!to $% S%('4o) $% TI U1a P(o3o)ta $%
I!t%9(a45o $% P(o+%))o) $% M%l,o(a % G%)t5o $% S%('4o), 2006.

MAZZANT, Eduardo Spolaor. TE+!+a) $% (%%!9%!,a(a $% )o:tFa(% a3l+a$a)
%1 71a :%((a1%!ta $% (%3(%)%!ta45o 3D $a $)t(>745o $% +o(%) $% 1a9%!)
$9ta), 2008.

MECELLA, Massimo. I!t%9(a45o $% ))t%1a) $% !:o(1a45o l%9a$o) alta1%!t%
:(a91%!ta$o) at(a'E) $% 1o$%la9%1 $% o>N%to) % %1 +a1a$a), 1999.

MEDEROS, Teresa Maria Maciel de. I!t(o$745o W %!9%!,a(a $% )o:tFa(% % W
P7al$a$% $% )o:tFa(%, 2006.

MELO, Tiago Eugnio de. E!9%!,a(a $% So:tFa(%- +o!+%to) % a3l+a4?%), 2007.

MLEV, Eliana Domingues da Cruz; ZAMPROLL, Francisco de. R%')ta
I!t%($)+3l!a( A3l+a$a- Estudo de Caso em Manuteno de Software, 2004.

MONTERO, Mario A. I!t(o$745o a o(9a!;a45o $% +o137ta$o(%), 2007.

OSBORNE, W. M.; CHKOFSKY, E. J. Ma!7t%!45o $% )o:tFa(%, 1990.

PARRERA, Walteno Martins. A3o)tla %!9%!,a(a $% )o:tFa(%, 2006.

PEGO, Paulo Cesar Batista. C(tE(o $% A'ala45o $% ))t%1a) L%9a$o), 2010.

PFLEEGER, S. L. E!9%!,a(a $% So:tFa(%- t%o(a % 3(/t+a. 2. ed. So Paulo:
Prentice Hall, 2004.

PEKARSK, Ana; 5eengenharia de soft4are6 o !ue, por !ue e como. Disponvel em:
<revistas.unicentro.br/index.php/RECEN/article/download/528/697>. Acesso em: 19
Mai. 2013.

PNTO, Herbert Laroca Mendes. S)t%1a) l%9a$o) % a) !o'a) t%+!olo9a)-
tcnicas de integrao e estudo de caso, 2004.

PRESSMAN, Roger S. E!9%!,a(a $% So:tFa(%. 1. ed. So Paulo: Makron, 1995.
______. ______. 5. ed. Rio de Janeiro: Mc GrawHill, 2002.
______. ______. 6. ed. Rio de Janeiro: McGraw-Hill, 2006.

78

RAMOS, Cristiane Soares; OLVERA, Kathia Maral de. Co!,%+%!$o S)t%1a)
L%9a$o) at(a'E) $% MEt(+a) $% So:tFa(%, 2008.

SANTOS, Pedro de Alcntara dos. I!t(o$745o W %!9%!,a(a $% )o:tFa(%, 2005.

SLVA, Roberto Andrade de. M9(a45o % I!t%9(a45o $% S)t%1a) L%9a$o), 2005.

SOMMERVLLE, an. E!9%!,a(a $% So:tFa(%. 4. ed. So Paulo: Addison-Wesley,
1992.
______. ______. 6. ed. So Paulo: Addison Wesley, 2003.

STEVENS, P.; POOLEY, R. S)t%1a) $% Pa$(?%) $% R%%!9%!,a(a, 1998.

VASCONCELOS, Aline Pires Vieira de. U1a a>o($a9%1 $% a3oo W +(a45o $%
a(P7t%t7(a) $% (%:%(M!+a $% $o1G!o >a)%a$a !a a!/l)% $% ))t%1a) l%9a$o).
Rio de Janeiro: UFRJ, 2007.

VERZELLO, Robert J. P(o+%))a1%!to $% $a$o). So Paulo: McGraw-Hill, 1984.

WARREN, an. U1 1Eto$o 3a(a a'ala( S)t%1a) L%9a$o) 3a(a a E'ol745o,
1998.

YOURDON, E. A!/l)% E)t(7t7(a$a Mo$%(!a. Rio de Janeiro: Editora Campus,
1990.

ZANLORENC, Edna; Abordagem da Engenharia de 5e!uisitos para Soft4are
7egado. Disponvel em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>.
Acesso em: 27 Ago. 2013.

79

ANECO A INSTRUMENTO DE COLETA DE DADOS

80

ANECO A INSTRUMENTO DE COLETA DE DADOS

Entrevista elaborada com a finalidade de captar uma viso mais ampla do
processo de reengenharia em software legado, no ponto de vista de um gerente de
T (tecnologia da informao).

1* Vo+M N/ t%'% o3o(t7!$a$% $% 3a(t+3a( $o 3(o+%))o $% (%%!9%!,a(a $%
)o:tFa(%O

2* S% )1" $)+o((a )o>(% o) 3(!+3a) 3o!to)& L%'a!$o %1 +o!)$%(a45o
a$a3ta45o $o) 7)7/(o)" 1%l,o(a)" +7)to)" 'a!ta9%!) % $%)'a!ta9%!)&

3* O P7% l%'o7Ql%'a a %13(%)a a 3a))a( 3%lo 3(o+%))o $% (%%!9%!,a(a !o
)o:tFa(%O

6* .7a) )5o o) 3(!+3a) a)3%+to) P7% 71 9%)to( $% TI 3(%+)a a'ala( )%
t(ata!$o $o R)o:tFa(%SO

<* .7a) )5o o) 3(!+3a) 1ot'o) P7% l%'a1 ao Ra>a!$o!oS $o )o:tFa(%
l%9a$oO

@* No 3(o+%))o $% (%%!9%!,a(a o ()+o $% 3%($%( :7!+o!al$a$%) $o )o:tFa(%
l%9a$o a!$a %T)t%" P7a) )5o a) 1%$$a) 3a(a tal a+o!t%+1%!toO

=* Vo+M 7tl;a al971 1o$%lo 3a(a $%)%!'ol'1%!to $o 3(oN%to $% (%%!9%!,a(a
o7 a$a3ta al971 1o$%loO

I* O 3(o+%))o $% (%%!9%!,a(a $% )o:tFa(% 3o$% )%( a R)ol745oS $o)
3(o>l%1a) $o) )o:tFa(%) l%9a$o)O

H* At7al1%!t%" (%%!9%!,a(a E a 1%l,o( )ol745o 3a(a )o:tFa(% l%9a$oO

10* .7al E o 1o1%!to $% a3l+a( a (%%!9%!,a(a !o )o:tFa(%& .7a) a)3%+to)
+o!t(>7%1 3a(a ))oO

11* .7al o 3a3%l $o 9%(%!t% $% TI" !a 9%)t5o % P7al$a$% $o )o:tFa(%O

12* .7al E a ')5o 38)*(%%!9%!,a(aO

13* O) 9%(%!t%) $% TI %)t5o 3(%3a(a$o) 3a(a a+%ta( o 3(o+%))o $%
(%%!9%!,a(aO

16* Co!)$%(a4?%) :!a) 0!%)ta 3a(t% :+a l'(% $o %!t(%')ta$o" (%))alta( al971
3o!to P7% !5o :o +ta$o" +o!ta( %T3%(M!+a $% '$a 3(o:))o!al" $+a)" o7
)%Na" t7$o P7% '%!,a a+(%)+%!ta( ao t(a>al,o2&

81

Questionrio 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 T sobre as diversas faces
da Reengenharia.

1* Vo+M )a>% o P7% E (%%!9%!,a(aO
( ) Sim
( ) No

2* X/ 13l%1%!to7 al971 3(oN%to $% (%%!9%!,a(aO
( ) Em implementao
( ) mplementados
( ) No

3* P(%t%!$% a'a!4a( +o1 !o'o) 3(oN%to)O
( ) Sim
( ) No

6* Pa(a P7a!$o 3la!%Na +o1%4a( o 3(oN%to $% (%%!9%!,a(aO
( ) Nos prximos 6 meses
( ) Entre 6 meses a 1 ano
( ) Entre 1 ano a 2 anos

<* O P7% l%'o7 a a3l+a( a (%%!9%!,a(aO
( ) Reduo de quota de mercado
( ) No cumprimento dos prazos de entrega
( ) Custos demasiado elevados
( ) Fraca qualidade dos produtos/servios
( ) Fraco servio aos clientes
( ) Diminuio de lucros
( ) Perda de competitividade
( ) Outras

@* .7al :o o 9(a7 $% )at):a45o o>t$oO
( ) Muito satisfeito
( ) Satisfeito
( ) nsatisfeito
( ) Muito insatisfeito
( ) Ainda a decorrer

=* .7a) o) 3(o+%))o) P7% :o(a1 o>N%to $% (%%!9%!,a(aO
( ) Toda a organizao
( ) Processos operacionais
( ) Processos infra estruturais

I* A P7%1 :o (%+o(($o 3a(a o 3(o+%))o $% (%%!9%!,a(aO
( ) Consultores externos
( ) Recursos internos
82

( ) Equipes mistas

H* A P7%1 t%!+o!a (%+o((%( !o :7t7(oO
( ) Equipes mistas
( ) Recursos internos

10* .7a) :o(a1 a) 3(!+3a) >a((%(a)O
( ) Limitao dos sistemas informticos
( ) Resistncia mudana
( ) nexistncia de equipes de projeto multifuncionais
( ) nexistncia de um lder de projeto
( ) Envolvimento demasiado tardio do pessoal de S
( ) Qualificaes inadequadas da equipe de projeto
( ) Expectativas irrealistas

Idioma

MONOGRAFIA: Reengenharia em Software Legado

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

MONOGRAFIA: Reengenharia em Software Legado

Enviado por

Direitos autorais:

Formatos disponíveis

CENTRO UNIVERSITRIO DO ESPRITO SANTO UNESC

LUCIANA PONCHE DIAS

Interesses relacionados

Você também pode gostar