Upload
luciana-ponche-dias
View
186
Download
0
Embed Size (px)
Citation preview
CENTRO UNIVERSITÁRIO DO ESPÍRITO SANTO – UNESC
LUCIANA PONCHE DIAS
REENGENHARIA EM SOFTWARE LEGADO
COLATINA
2013
LUCIANA PONCHE DIAS
REENGENHARIA EM SOFTWARE LEGADO
Trabalho de Conclusão de Curso apresentado ao Centro Universitário do Espírito Santo – UNESC, sob orientação da professora Priscila de Almeida Prata, para obtenção do Título de Bacharel em Sistemas de Informação.
COLATINA
2013
LUCIANA PONCHE DIAS
REENGENHARIA EM SOFTWARE LEGADO
Trabalho de Conclusão de Curso apresentado ao Centro Universitário do Espírito Santo – UNESC, para obtenção do Título de Bacharel em Sistemas de Informação.
ORIENTADOR
Priscila de Almeida Prata, Professora do UNESC, Mestre em Engenharia urbana.
Nota
AVALIADOR
Professor do UNESC
Nota
Colatina, ______ de __________________ de 2013.
Dedico este trabalho a Deus por ter me concedido a graça de concluir mais uma etapa de minha caminhada com sucesso. A meus pais, por todo esforço, pelo carinho, amor e educação que muito contribuíram na minha formação. A minha irmã por sempre acreditar em meu potencial e não deixar desistir. A meus amigos e familiares que sempre estiveram ao meu lado para me apoiar.
Agradeço a minha orientadora, a professora Priscila de Almeida Prata, pela dedicação e doação de conhecimentos dispensados para a elaboração desse trabalho. Ao professor Geraldo Cezar Seidel Dalla Bernardina, pela motivação e entusiasmo. Ao gerente de TI Keiji Sakai, que aceitou ser entrevistado e que muito contribuiu para o “enriquecimento” do trabalho, apesar de todos os imprevistos ao longo da pesquisa.
Tente uma, duas, três vezes e se possível tente a quarta, a quinta e quantas vezes for necessário. Só não desista nas primeiras tentativas, a persistência é amiga da conquista. Se você quer chegar aonde a maioria não chega, faça o que a maioria não faz.
Bill Gates
RESUMO
Trata da proposta de aplicação da reengenharia em software legado, bem como as vantagens e desvantagens, tendo como critério os custos, funcionalidades e desempenho. Um software legado que passa pelo processo de reengenharia e consequentemente por engenharia reversa não perde suas funcionalidades, ao contrário, ele passa por um novo processo de codificação, estruturação, documentação, visando uma melhor qualidade do software. Através de pesquisa bibliográfica são exemplificadas as diretrizes que levam à necessidade de aplicar a reengenharia em software legado, bem como a importância da mesma dentro da organização. Através da pesquisa qualitativa, foi feito uma entrevista com um gerente de TI, que já passou por diversos processos de reengenharia em software legado. Mediante pesquisa quantitativa, foi feito uma análise de um questionário distribuído para 500 gestores de TI referente à reengenharia em software legado. As mesmas foram de grande relevância para o trabalho, uma vez que todos os tópicos abordados na pesquisa bibliográfica serão “autenticados”. Conclui-se que atualmente a necessidade de aplicar a reengenharia é cada vez maior e que a mesma contribui de maneira imprescindível nos processos organizacionais, porém por ser de tamanha complexidade, é preciso fazer um estudo detalhado de custos e necessidades.
Palavras-chave: reengenharia, legado, software, engenharia, manutenção.
LISTA DE FIGURAS
Figura 1 – Tripé da engenharia de software ......................................................... 17
Figura 2 – Modelo cascata .................................................................................... 22
Figura 3 – Modelo prototipação ............................................................................. 23
Figura 4 – Modelo espiral ...................................................................................... 24
Figura 5 – Modelo em camadas de um software legado ...................................... 29
Figura 6 – Níveis lógicos de sistemas computacionais ......................................... 30
Figura 7 – Qualidade de sistema e valor de negócio ............................................ 32
Figura 8 – Distinção entre o desenvolvimento de um novo software (1) e
reengenharia (2) ....................................................................................................
38
Figura 9 - Relacionamentos no ciclo de desenvolvimento de software ................ 40
Figura 10 – Processo de reengenharia ................................................................. 42
Figura 11 – Processo de engenharia reversa ....................................................... 45
Figura 12 – Visualizações de software no ciclo de desenvolvimento ................... 46
Figura 13 – Processo de reestruturação de programa .......................................... 48
Figura 14 – Custo da reengenharia ....................................................................... 55
LISTA DE QUADRO
Quadro 1 – Ferramentas de reengenharia ............................................................ 57
SUMÁRIO
INTRODUÇÃO ...................................................................................................... 12
1 SOFTWARE ....................................................................................................... 13
1.1 EVOLUÇÃO DO SOFTWARE ......................................................................... 13
1.2 CLASSIFICAÇÃO ............................................................................................ 15
1.3 CRISE DO SOFTWARE .................................................................................. 15
2 ENGENHARIA DE SOFTWARE ........................................................................ 17
2.1 PROCESSO/CICLO DE VIDA DO SOFTWARE ............................................. 18
2.2 MODELOS DE CICLO DE VIDA ..................................................................... 20
2.2.1 Ciclo de vida clássico (modelo cascata) ........................................... 21
2.2.2 Prototipação .............................................................................................. 22
2.2.3 Modelo espiral ............................................................................................ 24
3 SOFTWARE LEGADO ...................................................................................... 26
3.1 EVOLUÇÃO PARA O LEGADO ...................................................................... 27
3.2 ARQUITETURA ............................................................................................... 28
3.3 NÍVEL LÓGICO ............................................................................................... 30
3.4 AVALIAÇÃO .................................................................................................... 31
3.5 MANUTENÇÃO ............................................................................................... 33
3.6 PROBLEMAS COM O LEGADO ..................................................................... 35
4 REENGENHARIA DE SOFTWARE ................................................................... 37
4.1 RELACIONAMENTOS NO CICLO DE DESENVOLVIMENTO ....................... 39
4.2 PROCESSO DE REENGENHARIA DE SOFTWARE ..................................... 41
4.2.1 Tradução de código-fonte ......................................................................... 43
4.2.2 Engenharia reversa .................................................................................... 44
4.2.2.1 Visões de software .................................................................................... 46
4.2.3 Melhoria da estrutura do programa .......................................................... 47
4.2.4 Modularização de programa ...................................................................... 48
4.2.5 Reengenharia de dados ............................................................................. 49
4.3 VANTAGENS DA REENGENHARIA .............................................................. 50
4.4 DIFICULDADES NO PROCESSO DE REENGENHARIA .............................. 52
4.5 CUSTO ............................................................................................................ 54
4.6 FERRAMENTAS DE AUXÍLIO À REENGENHARIA ....................................... 56
4.7 ESTUDO DE CASO (EXEMPLIFICAÇÃO) ..................................................... 57
4.7.1 Sistema LEGADO_TEL .............................................................................. 58
4.7.2 O problema ................................................................................................. 59
4.7.3 Alternativas de soluções ........................................................................... 59
4.7.4 Problemas na substituição ........................................................................ 60
4.7.5 Solução alternativa .................................................................................... 62
4.7.6 Considerações finais ................................................................................. 63
5 METODOLOGIA ................................................................................................ 65
5.1 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 01 .......................... 65
5.2 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 02 .......................... 70
CONCLUSÃO ....................................................................................................... 75
REFERÊNCIAS ..................................................................................................... 76
ANEXO A – INSTRUMENTO DE COLETA DE DADOS ...................................... 79
12
INTRODUÇÃO
A variedade de problemas que envolvem manutenção de software cresce
constantemente, sendo que as soluções não acompanham esta evolução. A
reengenharia de software é uma das estratégias da evolução de software. Ocupa-se
de reimplementar sistemas legados, para que sua manutenção seja mais simples.
O grande dilema da reengenharia em software legado é que junto ao software
legado existem informações dos negócios e procedimentos que podem não estar
documentados. O risco de remover e reescrever tais programas são grandes, pois
muitas informações teriam que ser descobertas por tentativa e erro.
Esta obra tem por objetivo, apresentar a importância da reengenharia em
software legado, além disso, deixar explícito os conceitos relevantes do processo,
vantagens, desvantagens e custo, visando pela qualidade do software.
Para desenvolvimento desta pesquisa, foram utilizadas referências
bibliográficas disponíveis em livros, revistas, artigos, etc. Foi realizada uma pesquisa
de campo qualitativa através de uma entrevista com um gerente de TI. Também foi
feito uma análise de um questionário distribuído para 500 gestores de TI referente à
reengenharia em software legado, de caráter quantitativo.
Dar início à pesquisa de reengenharia em software legado é relevante, pois
muitas empresas ainda mantêm o software legado e a manutenção de sistemas
legados é cada vez mais dispendiosa, e a reengenharia prolonga o tempo de vida
útil do software. A reengenharia é eficaz em termos de custo quando ele tem alto
valor de negócios, melhora a estrutura do sistema, cria uma nova documentação
relacionada e faz com que ela seja de mais fácil compreensão.
13
1 SOFTWARE
Uma descrição de software num livro didático poderia assumir a seguinte
forma: "Software é: (1) instruções (programas de computador) que, quando
executadas, produzem a função e o desempenho desejados; (2) estruturas de dados
que possibilitam que os programas manipulem adequadamente a informação; e (3)
documentos que descrevem a operação e o uso dos programas" (PARREIRA,
2006).
Entende-se que “software” é uma sequência de instruções escritas para serem
interpretadas por um computador com o objetivo de executar tarefas específicas. Em
um computador, o software é classificado como a parte lógica cuja função é fornecer
instruções para o hardware. O termo inglês “soft” é o antônimo de “hard” e significa
“macio”, ou seja, o hardware é difícil de manipular e de alterar, enquanto o software
não (MONTEIRO, 2007).
1.1 EVOLUÇÃO DO SOFTWARE
Os softwares evoluem em resposta às exigências de mudanças como, por
exemplo, correção de erros, melhorias no desempenho, migrações para novas
plataformas ou outras características (PRESSMAN, 2006).
Com o surgimento dos primeiros softwares, não se imaginava que o mesmo se
tornaria um elemento importante para o mundo e que teria capacidade de manipular
a informação. Com a ascensão computacional e as mudanças vindas dele, veio a
vontade de criar sistemas cada vez mais perfeitos, livres de erros e com prazos e
datas estipuladas (PRESSMAN, 2006).
O contexto em que o software foi desenvolvido está estreitamente ligado a
quase cinco décadas de evolução dos sistemas computadorizados. O melhor
desempenho de hardware, o menor tamanho e o custo mais baixo, precipitaram o
aparecimento de sistemas baseados em computadores mais sofisticados. Nas
ultimas décadas o software evolui de uma ferramenta de análise de informações e
de resolução de problemas especializados para uma indústria da programação
(SOMMERVILLE, 1992).
Em meados da década de 40, o desenvolvimento do software era feito
virtualmente, sem administração até que os prazos começassem a se esgotar e os
14
custos a subir. Durante este período, era usada orientação batch (em lote) para a
maioria dos sistemas. Na maior parte, o hardware dedicava-se à execução de um
único programa que, por sua vez, dedicava-se a uma única aplicação específica. O
software era projetado sob medida para cada aplicação e tinha uma distribuição
relativamente limitada. Por causa desse ambiente de software personalizado o
projeto era um processo implícito realizado no cérebro de alguém e sem nenhuma
documentação (PRESSMAN, 1995).
Em meados de 1960 até o final de 1975 a multiprogramação e os sistemas
multiusuários introduziram novos conceitos de interação homem-máquina. As
técnicas interativas abriram um novo mundo de aplicações e novos níveis de
sofisticação de software e hardware. Sistemas de tempo real podiam analisar,
coletar e transformar dados de múltiplas fontes. Os avanços da armazenagem on-
line levaram à primeira geração de sistemas de gerenciamento de banco de dados
(PRESSMAN, 1995).
À medida que o número de sistemas crescia, era crescente o número de falhas
que constantemente precisava ser corrigidas por exigência dos usuários, essas
atividades foram chamadas de "manutenção de software". Esta constante
manutenção acarretou diversos problemas no desenvolvimento e avanços dos
softwares, pois ao mesmo tempo em que concertava um problema, surgia outro
(PRESSMAN, 1995).
Durante os anos de 1975 a 1985 as redes globais, as comunicações digitais de
largura de banda e a crescente demanda de acesso "instantâneo" a dados exigiram
muito dos desenvolvedores de software. Também foi caracterizada pelo advento e o
generalizado uso de microprocessadores, computadores pessoais e poderosas
estações de trabalho "Workstations" de mesa (PRESSMAN, 1995).
Atualmente as tecnologias orientadas a objetos estão ocupando o lugar das
abordagens mais convencionais para o desenvolvimento de software em muitas
áreas de aplicação. Os sistemas especialistas e o software de inteligência artificial
saíram do laboratório para a aplicação prática em problemas de amplo espectro do
mundo real. O software de rede neural artificial abriu excitantes possibilidades para o
reconhecimento de padrões e para capacidades de processamento de informações
semelhantes às humanas (PRESSMAN, 1995).
15
1.2 CLASSIFICAÇÃO
O software passa por constates classificações e cada autor o classifica de
formas diferentes, seguindo critérios pré-estabelecidos. Seguindo como princípio a
classificação de Verzello, o software se classifica em três tipos: Software de
Sistema, Software de Programação e Software de Aplicação (VERZELLO, 1984).
O Software de Sistema ou Sistema Operacional é o conjunto de informações
processadas pelo sistema interno de um computador que permite a interação entre
usuário e os periféricos do computador através de uma interface gráfica. Engloba o
sistema operativo e os controladores de dispositivos (VERZELLO, 1984).
O Software de Programação ou Software de Infraestrutura é o conjunto de
ferramentas que permitem ao programador desenvolver sistemas informáticos,
geralmente usando linguagens de programação e um ambiente visual de
desenvolvimento integrado. Os Bancos de Dados, Dicionários de Dados e Brokers
também são considerados Software de Infraestrutura, uma vez que permitem que se
escrevam sistemas inteiros utilizando o seu potencial (VERZELLO, 1984).
O Software de Aplicação são programas de computadores que permitem ao
usuário executar uma série de tarefas específicas em diversas áreas de atividade
como arquitetura, contabilidade, educação, medicina e outras áreas comerciais. São
ainda os videojogos, sistemas de celulares, os sistemas de automação industrial,
etc. (VERZELLO, 1984).
1.3 CRISE DO SOFTWARE
Em meados de 1970 o termo “crise do software” foi usado para expressar as
dificuldades do desenvolvimento de software frente ao rápido crescimento da
demanda por software, da complexidade dos problemas a serem resolvidos e da
inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que
funcionassem adequadamente ou pudessem ser validados (PRESSMAN, 2002).
A partir do momento em que o desenvolvimento de software começou a
caminhar com o advento das linguagens estruturadas e modulares, tornou-se claro
que a indústria de software estava falhando repetidamente na entrega de resultados
dentro dos prazos, quase sempre estourando os orçamentos e apresentando um
grau de qualidade duvidoso ou insatisfatório (DALMASO, 2013).
16
Um relatório em 1967 apresentou que, de 50% a 80% dos projetos não haviam
sido concluídos e outros fracassados por não terem atingindo os objetivos
esperados, e dos que foram concluídos, foram entregues acima do prazo estipulado
e o orçamento acima daquilo que foi predeterminado (DALMASO, 2013).
Mediante aos fatos, em 1968 aconteceu a “NATO Software Engineering
Conference”, um evento criado com o objetivo de discutir alternativas para contornar
a crise do software. Essa conferência marcou assim o início dessa nova área na
computação. Esta reunião teve como principal objetivo estabelecer práticas mais
maduras para o processo de desenvolvimento, por esta razão o encontro é
considerado hoje como o nascimento da disciplina de “Engenharia de Software”
(DALMASO, 2013).
Os problemas que originaram esta crise tinham relacionamento direto com a forma de trabalho das equipes. Eram problemas que não se limitavam a "sistemas que não funcionam corretamente", mas envolviam também dúvidas sobre como desenvolver e manter um volume crescente de software e ainda estar preparado para as futuras demandas. Essencialmente, eram sintomas provenientes do pouco entendimento dos requisitos por parte dos desenvolvedores, somados às técnicas e medidas pobres aplicadas sobre o processo e o produto, além dos poucos critérios de qualidade estabelecidos até então (PRESSMAN, 2002).
Todos esses fatores exigiram respostas e métodos que foram sendo
aprimorados e documentados, dando início à área de Engenharia de Software. A
busca por eficiência e competência revelou oportunidades, desafios e perigos que
guiaram as tecnologias e apontaram novos rumos para as pesquisas (DALMASO,
2013).
Embora ainda existam problemas durante o desenvolvimento e entrega do
software, os processos, métodos e ferramentas auxiliam muito em seu progresso,
uma vez aplicados por pessoas com conhecimentos adequados é evidente que
resultará em um bom projeto. Antigamente se produzia software de maneira muito
desordenada sem preocupação com o que realmente o software deveria fazer ou se
era possível executar “tal” tarefa, a engenharia de software surgiu da necessidade
de se construir software com mais qualidade em menor tempo (SANTOS, 2005).
17
2 ENGENHARIA DE SOFTWARE
Uma primeira definição de engenharia de software foi proposta por Fritz Bauer
na primeira grande conferencia dedicada ao assunto: "O estabelecimento e uso de
sólidos princípios de engenharia para que se possa obter economicamente um
software que funcione eficientemente com máquinas reais" (PARREIRA, 2006).
A engenharia de software é uma derivação da engenharia de sistemas e de
hardware. Ela abrange um conjunto de três elementos fundamentais - métodos,
ferramentas e procedimentos que possibilita ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construção
de software de alta qualidade produtivamente (PARREIRA, 2006).
A Engenharia de Software busca prover a tecnologia necessária para produzir um software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial, por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados (SANTOS, 2005).
Um grande problema no desenvolvimento de software é justamente o fato de
boa parte das organizações não encararem o desenvolvimento de software como um
projeto de verdade, assim, não aplicando procedimentos, métodos e ferramentas
necessárias. Por conta disso, boa parte dos projetos fracassa (SANTOS, 2005).
Figura 1 – Tripé da engenharia de software
Fonte: MARTINS, 2006.
A engenharia de software é baseada no tripé: processos, pessoas e tecnologia
(figura 1). Não adianta ter os melhores profissionais se não possuir boas tecnologias
para uso ou se não possuir um processo que guie o desenvolvimento de software.
18
Da mesma forma, não adianta possuir as tecnologias mais avançadas se as pessoas
não conseguem utilizá-las. Além disso, mesmo que pareça inconcebível para alguns,
de nada adianta ter a melhor tecnologia e as melhores pessoas se não existe um
processo que guie as atividades dessas pessoas utilizando tais tecnologias. Existem
grande chances de ter problemas relacionados à falta de controle ou
desorganização, caso não tenha um processo que discipline as tarefas das pessoas
(PARREIRA, 2006).
2.1 PROCESSO/CICLO DE VIDA DO SOFTWARE
Como todo produto, o software possui um ciclo de vida, que pode ser definido
como o conjunto de todas as etapas relacionadas à sua existência, desde a sua
concepção, até o seu desaparecimento. Isso inclui uma série de etapas, dentre elas:
a concepção, onde o produto é idealizado, a partir da percepção de uma
necessidade; o desenvolvimento, a partir da identificação dos requisitos e sua
transformação em itens a serem entregues ao cliente; a operação, quando o produto
é instalado para ser utilizado em algum processo de negócio, sujeita a manutenção,
sempre que necessário; e a retirada, quando o produto tem sua vida útil finalizada.
(MEDEIROS, 2006).
No ciclo de vida de um software, a codificação, que representa a escrita do
programa utilizando alguma linguagem de programação, é apenas uma parte do
ciclo de vida, embora muitos profissionais de informática acreditem que essa seja a
única tarefa relacionada ao desenvolvimento de software (MEDEIROS, 2006).
O processo de software é um guia de como um produto de software deve ser
construído, do início ao fim. A ligação está no fato que esse guia depende do modelo
de ciclo de vida utilizado. Existem vários modelos e dependendo dele, as atividades
a serem executadas podem variar. Um processo é um conjunto de passos
parcialmente ordenados, constituídos por atividades, métodos, práticas e
transformações, utilizados para atingir uma meta. Uma meta está associada a
resultados, que são os produtos resultantes da execução do processo (MEDEIROS,
2006).
Um processo deve ter uma documentação que o descreve, apresentando detalhes sobre o que é feito (produto), quando (passos), por quem (agentes), o que usa como entrada (insumo) e o que é produzido (resultado) (MEDEIROS, 2006).
19
A engenharia de software compreende um conjunto de etapas que engloba os
métodos, ferramentas e procedimentos. Essas etapas frequentemente são citadas
como paradigmas da engenharia de software. Um paradigma de engenharia de
software é escolhido tendo-se como base a natureza do projeto e da aplicação, os
métodos e as ferramentas a serem usados, os controles e os produtos que precisam
ser entregues (PARREIRA, 2006).
O processo de software é um guia de como um produto de software deve ser construído, do início ao fim. Este guia depende do modelo de ciclo de vida utilizado. Um processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, utilizados para se atingir uma meta. Uma meta está associada a resultados, que são os produtos resultantes da execução do processo (PARREIRA, 2006).
Os “métodos” proporcionam os detalhes de "como fazer" para construir o
software, envolvem um amplo conjunto de tarefas que inclui: planejamento com
estimativa de projeto, análise de requisitos de software e de sistemas, projeto da
estrutura de dados, arquitetura de programa e algoritmo de processamento,
codificação, teste e manutenção. Os métodos da engenharia de software na maioria
das vezes introduzem uma notação gráfica ou orientada a linguagem especial e
introduzem um conjunto de critérios para a qualidade do software (PARREIRA,
2006).
As “ferramentas” de engenharia de software proporcionam apoio automatizado
ou semiautomatizado aos métodos. Existem ferramentas para sustentar cada um
dos métodos citados anteriormente. Quando as ferramentas são integradas de forma
que a informação criada por uma ferramenta possa ser usada por outra, é
estabelecido um sistema de suporte ao desenvolvimento de software chamado de
CASE (PARREIRA, 2006).
O CASE (Computer Aided Software Engineering) combina software, hardware e um banco de dados de engenharia de software (uma estrutura de dados contendo importantes informações sobre analise, projeto, codificação e teste) para criar um ambiente de engenharia de software que seja análogo ao projeto auxiliado por computador/engenharia auxiliada por computador para o hardware (PARREIRA, 2006).
Os “procedimentos” da engenharia de software constituem o elo para manter
junto os métodos e as ferramentas, alavancando possibilidades para o
desenvolvimento racional e oportuno do software. A sequência em que os métodos
serão aplicados, os produtos que são exigidos com prazo para entrega
(documentos, relatórios, formulários etc.), o marco de referência que possibilitam aos
20
gerentes de software avaliar o progresso, os controles que ajudam a assegurar a
qualidade e a coordenar as mudanças é definido pelos procedimentos (PARREIRA,
2006).
Para seleção de um processo, e posterior iniciação de um projeto, é necessário
entender qual modelo de ciclo de vida ele utiliza. Um modelo de ciclo de vida pode
ser apropriado para um projeto, mas não ser apropriado para outro. É necessário
entender bem os conceitos relacionados para que as escolhas feitas sejam
baseadas em conhecimento e não no acaso (CORDEIRO, 2012).
2.2 MODELOS DE CICLO DE VIDA
O termo modelo de ciclo de vida é utilizado para descrever um grupo de
atividades relacionado ao desenvolvimento de software e a forma como elas se
relacionam. Para cada modelo de ciclo de vida existe um relacionamento diferente
entre as atividades, determinando formas diferentes de se conduzir o processo de
construção do produto (SANTOS, 2005).
Segundo SANTOS (2005) para detalhamento dos modelos de ciclo de vida, é
necessário entender os subprocessos (fluxos ou disciplinas) ligados às tarefas de
desenvolvimento. Os principais subprocessos são:
• Requisitos: obtenção do enunciado, completo, claro e preciso dos desejos,
necessidades, expectativas e restrições dos clientes em relação ao produto a ser
desenvolvido.
• Análise: modelagem dos conceitos relevantes do domínio do problema, com
o intuito de verificar a qualidade dos requisitos obtidos e detalhar tais requisitos em
um nível adequado aos desenvolvedores.
• Desenho (ou projeto): definição de uma estrutura implementável para um
produto, que atenda aos requisitos especificados.
• Implementação: codificação das partes que compõe o software, definidas no
desenho, utilizando as tecnologias selecionadas.
• Teste: verificação dinâmica das partes que constituem o software, utilizando
um conjunto finito de casos de teste, selecionados dentro de um domínio
potencialmente infinito, contra seu comportamento esperado.
A literatura cita vários tipos de modelos de ciclo de vida de software. Dentre os
diversos modelos de ciclos de vida de software, pode-se citar: cascata, espiral,
21
prototipação, refinamento iterativo, ciclo de vida progressivo, desenvolvimento
incremental, entre outros (CORDEIRO, 2012).
2.2.1 Ciclo de vida clássico (modelo cascata)
O modelo clássico ou cascata foi derivado de modelos de atividade de
engenharia com o fim de estabelecer ordem no desenvolvimento de grandes
produtos de software. Em vista dos outros modelos, este é o mais rígido, menos
administrativo e o modelo mais antigo, porém o mais amplamente usado e
importante da engenharia de software. O modelo em cascata é referência para
muitos outros modelos, servindo de base para muitos projetos modernos
(PRESSMAN, 2006).
O sucesso do modelo cascata está no fato de o mesmo ser orientado para
documentação. Neste caso a documentação abrange mais do que arquivo de texto,
abrange representações gráficas ou simulações (PRESSMAN, 2006).
O ciclo de vida clássico requer uma abordagem sistemática, uma abordagem
incorporando processos, métodos e ferramentas, sequencial ao desenvolvimento de
software, que se inicia no nível do sistema e avança ao longo da análise, projeto,
codificação, teste e manutenção. Tendem a colocar ordem numa atividade
inerentemente caótica (PRESSMAN, 2006).
O modelo cascata é um modelo de engenharia projetado para ser aplicado no
desenvolvimento do software. A ideia principal que o dirige é que as diferentes
etapas de desenvolvimento seguem uma sequência. A saída da primeira etapa “fluí”
para a segunda etapa e a saída da segunda etapa “fluí” para a terceira e assim por
diante. As atividades a executar são agrupadas em tarefas, executadas
sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior
tiver terminado (MELO, 2007).
A vantagem do modelo é que o mesmo só avança para a próxima tarefa, a
partir da aceitação e validação do cliente. O modelo pressupõe que o cliente
participa ativamente no projeto. Este modelo minimiza o impacto da compreensão
adquirida no curso do projeto (MELLO, 2007).
O andamento do processo flui de cima para baixo, como uma cascata (daí o
nome “modelo cascata”). O modelo envolve as seguintes atividades:
planejamento/engenharia de sistemas; análise de requisitos; projeto;
22
construção/codificação; teste e integração; operação e manutenção. Como mostra a
figura (2) abaixo (MELO, 2007).
Figura 2 – Modelo cascata Fonte: SOMMERVILLE, 2003.
2.2.2 Prototipação
Um protótipo é uma versão inicial de um sistema de software, que é utilizada
para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer
mais sobre os problemas e suas possíveis soluções. O desenvolvimento rápido de
um protótipo é essencial para que os custos sejam controlados e os usuários
possam fazer experiências com o protótipo no início do processo de software
(PRESSMAN, 2006).
A prototipação possibilita ao desenvolvedor criar um modelo de software que
será implementado. O seu principal objetivo é antecipar ao usuário final um modelo
de sistema para que o mesmo possa avaliar suas reais finalidades, identificar erros e
omissões, com isso o desenvolvedor pode efetuar de forma imediata as correções e
ajustes no software (PRESSMAN, 2006).
Como todas as abordagens ao desenvolvimento de software, a prototipação
inicia-se com a coleta de requisitos (Figura 3). Faz-se então um projeto rápido
contendo os aspectos que serão visíveis ao cliente. O projeto rápido leva à
23
construção de um protótipo, que, será avaliado pelo cliente/usuário. Esta avaliação
será usada para refinar requisitos para o software desenvolvido. Idealmente, o
protótipo serve como um mecanismo para identificar os requisitos de software.
Muitas vezes, é preciso descartar um protótipo e, partir do início para evitar perda de
tempo com correções (PRESSMAN, 2006).
Figura 3 – Modelo prototipação
Fonte: PRESSMAN, 2006.
A filosofia de protótipos possui algumas vantagens, que são: garantia de
sucesso técnico e psicológico; redução no fator tempo; ideal para sistemas
gerenciais e de apoio à decisão; sistema atual melhora a percepção do usuário em
relação software; o desenvolvedor constrói algo imediatamente; entre outros
(PRESSMAN, 2006).
As principais desvantagens deste modelo é que na maioria das vezes o cliente
quer resultados, e, muitas vezes não saberá, ou não entenderá que um protótipo
pode estar longe do software ideal. Mesmo assim, a gerência de desenvolvimento
cede às reclamações e tenta encurtar o prazo de entrega, o qual já estava
prolongado. O desenvolvedor, na pressa de colocar um protótipo em funcionamento,
é levado a usar uma linguagem de programação imprópria por simplesmente estar à
disposição ou estar mais familiarizado. Essa atitude poderá levar a um algoritmo
ineficiente. Outras desvantagens é que pode haver muitos ajustes no protótipo final,
a fim de melhorar a qualidade; o desenvolvedor pode esquecer estruturas
24
inapropriadas no protótipo; exige elevada capacitação gerencial por parte da equipe
do projeto; entre outros (PRESSMAN, 2006).
O protótipo é baseado no “feedback” dos usuários, por causa disso as
mudanças são feitas no protótipo. Dependendo do comentário dos usuários, estas
mudanças podem ser menores, de modo que alterem formatos, ou podem ser
maiores, de modo que são requeridas mudanças estruturais no protótipo. Ainda que
possam ocorrer problemas, o uso da prototipação é um paradigma eficiente na
Engenharia de Software. O grande segredo é o entendimento entre o desenvolvedor
e o cliente (PRESSMAN, 2006).
2.2.3 Modelo espiral
O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar
os diversos modelos existentes à época, eliminando suas dificuldades e explorando
seus pontos fortes. Foi desenvolvido para abranger as melhores características do
ciclo de vida clássico e da prototipação, porém com a adição de um novo elemento,
que foi a “análise de risco”. Este modelo de ciclo de vida se utiliza de protótipos por
se adequar muito bem com esta filosofia de desenvolvimento. Cada passo (Figura 4)
através do ciclo inclui: planejamento, análise e projeto, prototipação e avaliação. Os
passos se repetem até que um produto seja obtido (PRESSMAN, 2006).
Figura 4 – Modelo espiral Fonte: PRESSMAN, 2006.
25
Um ciclo se inicia com a determinação de objetivos, alternativas e restrições
(primeira tarefa) na qual ocorre o comprometimento dos envolvidos e o
estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa,
avaliação de alternativas, identificação e solução de riscos, executa-se uma análise
de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for
considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o
desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata.
Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo
(PRESSMAN, 2006).
Os riscos são circunstâncias adversas que podem atrapalhar o processo de
desenvolvimento e a qualidade do produto a ser desenvolvido, com isso é possível
prever e eliminar os problemas de alto risco através de um planejamento e projetos
cuidadosos. Este é um modelo que atende aos seguintes casos: o problema a ser
resolvido não está totalmente entendido; a realidade pode mudar enquanto o
sistema está sendo desenvolvido; a própria solução adotada pode ter algum efeito
colateral desconhecido e a preocupação está centrada mais na qualidade e
funcionalidade do que se produz (PRESSMAN, 2006).
Com base na experiência adquirida com a primeira versão, estabelecem-se
novos requisitos para o sistema, e uma nova versão é concebida e implementada. O
modelo espiral tende à uma trajetória para o modelo mais completo do sistema,
baseado principalmente em decisões de prosseguir ou não, de acordo com a
avaliação, seja do cliente ou do desenvolvedor (PRESSMAN, 2006).
O paradigma de modelo espiral é a abordagem mais realista para o desenvolvimento de softwares e sistemas em grande escala. Ele usa uma abordagem "evolucionária", capacitando o desenvolvedor e o cliente a entender e reagir aos riscos, em cada etapa evolutiva da espiral. Usa a prototipação como um mecanismo de redução de riscos e a mesma pode ser aplicada em qualquer ponto evolutivo. Porém, pode ser difícil convencer grandes clientes de que a abordagem evolutiva é controlável. Se um grande risco não for descoberto, com certeza ocorrerão problemas (PRESSMAN, 2006).
Esse paradigma é relativamente novo, e não tem sido amplamente usado como
outros modelos anteriormente explicados, o motivo está por exigir considerável
experiência na determinação de riscos e depende dessa experiência para ter
sucesso. O modelo espiral é mais adequado para sistemas complexos e que exijam
um alto nível de interações com os usuários, a fim de possibilitar a abordagem de
todos os problemas desse sistema (PRESSMAN, 2006).
26
3 SOFTWARE LEGADO
Um sistema de software é um artefato evolutivo e, com o passar do tempo, seu
projeto e implementação originais são modificados para atender a novos requisitos
e/ou melhorar o seu desempenho. Fatores internos e externos, como o estado da
economia, as modificações nos mercados, as alterações nas leis, as mudanças de
gestão e organização estrutural, contribuem para que as empresas sofram
mudanças contínuas (SOMMERVILLE, 2003).
Essas mudanças geram requisitos de software novos ou modificados; assim,
todos os sistemas de software úteis inevitavelmente são modificados quando as
empresas passam por mudanças. Portanto, esses sistemas incorporam um grande
número de alterações que foi feitas durante muitos anos, além de incorporarem
importantes regras de negócio no seu contexto. São os chamados sistemas legados
(SOMMERVILLE, 2003).
Existem muitas empresas que estão repletas de software legado em uso,
principalmente as empresas cujos processos são os mesmos por anos.
Normalmente as empresas gastam muito dinheiro na implantação do sistema e
esperam não ter o mesmo gasto novamente (JALOTE, 2005).
A durabilidade de sistema de software é muito variável, muitos sistemas de
grande porte permanecem em uso por mais de dez anos. Muitos desses antigos
sistemas ainda são fundamentais para as empresas, isto é, as empresas dependem
dos serviços fornecidos pelo software, e qualquer falha desses serviços teria um
sério efeito em seu dia a dia. Normalmente são aplicações complexas, de difícil
manutenção e que pelo grau de criticidade e custo para modernização, continuam
ativas (BRAGA, 2004).
A palavra “legado” traz um sentido pejorativo, similar ao adjetivo obsoleto. O
nome “software legado” é dado a sistemas antigos, em uso há determinado período
e desenvolvidos com tecnologia ultrapassada. Possuem uma função crítica em
relação ao processo funcional de uma organização que passou por diversas
modificações de requisitos durante seu tempo de vida (BRAGA, 2004).
A preocupação do engenheiro de software com os “legados” está na baixa
qualidade do mesmo. Muitas vezes não existem documentações e se existem são
pobres de detalhes, os casos de testes são fracos e não há um controle de
27
mudanças. Muitas vezes o engenheiro de software não mexe no software legado
quando o mesmo atende as necessidades do cliente (BROOKS, 1995).
Com o constante avanço da tecnologia, esses sistemas costumam ser
implantados nas organizações já desatualizados tecnologicamente (BROOKS,
1995).
Um sistema legado contém software, hardware, profissionais, processos, regras de negócio e informações geradas e manipuladas por todo sistema. Existem profissionais ligados diretamente ao mesmo, como analistas, desenvolvedores e administradores de dados; e existem profissionais que utilizam o sistema, como diretores, gerentes e usuários de um modo geral (BRAGA, 2004).
É necessário também focar o lado humano de uma possível mudança
tecnológica com a modernização ou mesmo substituição do sistema legado. Esse
acompanhamento estratégico se chama “Gestão de Mudanças” (Change
management) que são ferramentas e técnicas utilizadas para atenuar o impacto da
mudança tecnológica causado nos indivíduos diretamente ligados à tecnologia
(SOMMERVILLE, 2003).
Algumas das principais características na identificação de um software legado
são: sistemas em produção há mais de cinco anos; hardware e software obsoletos;
sistemas com mais de 10 mil linhas de códigos; interface com o usuário baseada em
caractere; código-fonte amplamente modificado por diversas equipes ao longo dos
anos, com alterações não documentadas; documentação antiga e desatualizada,
não condizentes com as funcionalidades e processos atuais do sistema; utilização
de um sistema de arquivos ou gerenciador de banco de dados obsoletos; sistema
não conhecido em sua totalidade pelos profissionais responsáveis por sua
manutenção; usuários do sistema incapazes de explicar com detalhes suas funções
junto ao sistema e todos os processos que o mesmo executa; regras de negócio
inseridas apenas no código-fonte do sistema (BRAGA, 2004).
3.1 EVOLUÇÃO PARA O LEGADO
A evolução de um sistema é um termo amplo que cobre todo o tempo entre
uma simples adição de um campo a um banco de dados até a completa
reimplementação de um sistema. Essas atividades de evolução podem ser divididas
em três categorias: manutenção, modernização e substituição (PEGO, 2010).
28
A manutenção é um processo incremental e iterativo em que pequenas
modificações são efetuadas no sistema. Essas modificações podem indicar
correções de erros ou pequenas melhorias no sistema, e nunca devem indicar
grandes mudanças estruturais (PEGO, 2010).
A substituição é indicada para sistemas que não conseguem se adaptar às
necessidades do negócio e para os quais a modernização não é mais possível ou
viável (PEGO, 2010).
A modernização envolve mudanças maiores que a manutenção, mas conserva
uma porção significativa do sistema. Essas mudanças incluem a reestruturação do
sistema, melhorias funcionais importantes, ou novos atributos de software. A
modernização é utilizada quando um sistema legado requer mudanças significativas
que as possíveis com manutenção (PEGO, 2010).
O tipo de modernização de um sistema legado pode ser definido pelo nível de
entendimento do sistema requerido para suportar os esforços de modernização.
Conhecimento interno da lógica do sistema é chamada “modernização white-box”, e
a que requer somente o conhecimento das interfaces externas do sistema é
chamada “modernização black-box” (PEGO, 2010).
3.2 ARQUITETURA
A arquitetura de qualquer software, seja ele legado ou não, representa um
artefato de projeto complexo, havendo uma variedade de formas de "olhar" e
compreendê-la (VASCONCELOS, 2007).
Uma arquitetura descreve diferentes propriedades do software, como a sua
divisão em elementos arquiteturais, protocolos de comunicação e controle,
sincronização, distribuição física, acesso a dados, etc. Uma arquitetura de software
deve ser vista e descrita mediante diferentes perspectivas e deve identificar seus
componentes, relacionamentos estáticos, interações dinâmicas, propriedades,
características e restrições (VASCONCELOS, 2007).
Quando se trata da arquitetura de um sistema legado, normalmente
apresentam algumas particularidades. No contexto organizacional possui vários
componentes, figura (5), são eles: hardware do sistema; software de apoio; software
de aplicação e processos de negócios (VASCONCELOS, 2007).
29
Figura 5 – Modelo em camadas de um software legado Fonte: SOMMERVILLE, 2003.
Quando se trata de “hardware do sistema” na maioria dos sistemas obsoletos o
hardware é antigo, não existem mais fornecedores e a manutenção é dispendiosa.
Em muitos casos, os sistemas legados foram escritos para hardware de mainframe e
pode não ser compatível com as atuais políticas de compras na área de tecnologia
da informação (BRAGA, 2004).
O “software de apoio” como o sistema operacional, compiladores, ferramentas,
etc. também pode estar desatualizado. O sistema pode ter sido compilado utilizando-
se uma versão de um compilador hoje descontinuada, e a mesma deve ser mantida
(BRAGA, 2004).
No caso do “software de aplicação”, não é um único programa de aplicação,
mas incluiu vários programas. O sistema pode ter iniciado com um único programa
processando um ou dois arquivos de dados, mas ao longo do tempo, podem ter sido
implantadas alterações como a adição de novos programas, que compartilham os
dados e se comunicam com outros programas do sistema. Esses diferentes
programas, geralmente são escritos e desenvolvidos por pessoas e linguagens
diferentes, em épocas distintas (SOMMERVILLE, 2003).
Como o software de aplicação, temos também os “dados de aplicação” que são aplicados no mesmo contexto. Em sistemas legados um imenso volume de dados se acumulou durante o tempo de existência do sistema. Esses dados podem estar inconsistentes, duplicados em diferentes arquivos. Assim como acontece com o software de aplicação, os arquivos de dados iniciais sofrem alterações à medida que novas informações são exigidas (BRAGA, 2004).
30
A camada de “processos de negócios” são informações sobre os processos
internos da organização, codificadas em uma linguagem de programação e
espalhadas pelos programas que fazem parte do sistema. Em boa parte dos
sistemas essas regras não estão bem documentadas, sendo do conhecimento tático
de gerentes, analistas e usuários do sistema (BRAGA, 2004).
3.3 NÍVEL LÓGICO
Modificar uma camada do sistema pode introduzir novos recursos, e as
camadas superiores do sistema são beneficiadas desses recursos. A modificação do
software no sistema pode torná-lo mais lento, de modo que um novo hardware é
necessário. Em grande parte das vezes é impossível manter interfaces de hardware,
especialmente se for proposta uma mudança radical para um novo tipo de hardware
(MECELLA, 1999).
A separação do sistema legado em níveis lógicos é uma “ponte” para um
posterior tratamento, manutenção ou integração. Os níveis lógicos se dividem em
quatro partes, como mostra a figura 6 (MECELLA, 1999).
Figura 6 - Níveis lógicos de sistemas computacionais Fonte: MECELLA, 1999.
A primeira representação é o “altamente Decomponível (amigável)” este
sistema é dividido em três níveis lógicos bem distintos e estruturado. A alteração de
31
um nível não afetará significativamente o outro nível. Todos os níveis são
prontamente acessíveis (MECELLA, 1999).
A segunda representação é o “decomponível nos dados (pouco amigável)” este
sistema é dividido em dois níveis lógicos: o nível de interface em conjunto com o
nível de processamento lógico e o nível de dados. O acesso aos dados nesse tipo
de sistema é imediato, ao contrário do acesso à interface ou o processamento
lógico. Sua integração a outros sistemas é conseguida com programação e
utilização de tecnologias (MECELLA, 1999).
A terceira representação é o “decomponível no programa (pouco amigável)”
este sistema é dividido em dois níveis lógicos: o nível de interface, separado e o
nível de programas e dados, em conjunto. Os dados somente são acessíveis a partir
de funções do sistema. Nesta categoria se encontram a maioria dos sistemas
legados. Sua integração a outros sistemas é conseguida com programação e
utilização de tecnologias (MECELLA, 1999).
A quarta e ultima representação é o “monolítico (hostil)” este sistema é
composto de um único bloco lógico. São aplicações bem antigas, e o acesso às suas
informações é bastante difícil. Sua integração a outros sistemas é bastante
complexa (MECELLA, 1999).
3.4 AVALIAÇÃO
Segundo Warren ao avaliar um sistema legado, deve-se considerá-lo sob duas
perspectivas diferentes. A primeira seria sob a perspectiva de negócios (valor do
sistema para a empresa) e a segunda seria uma perspectiva de sistema (avaliação
da qualidade do software de aplicação e do software e hardware de apoio do
sistema). A junção dessas duas perspectivas é decisiva na hora de decidir o que
fazer com o sistema legado (WARREN, 1998).
Essas avaliações são meramente subjetivas e sua quantificação deve ser efetuada utilizando-se uma abordagem de questionamentos aos vários indivíduos envolvidos no processo, colhendo assim vários pontos de vista. Dados quantitativos coletados também poderão auxiliar na avaliação do sistema, como: o número de pedidos de modificações no sistema; o volume de dados utilizados pelo sistema, etc. A formulação das questões a serem efetuadas deve ser inerente às duas perspectivas adotadas para a avaliação do sistema legado (SOMMERVILLE, 2003).
O ideal é que seja utilizada a avaliação objetiva para informar as decisões
sobre o que fazer com o sistema legado. Contudo, em muitos casos, essas decisões
32
não são realmente objetivas, mas se baseiam em considerações organizacionais ou
políticas. É imprescindível para uma organização efetuar uma correta avaliação de
seus sistemas legados. Caso essa avaliação seja efetuada sem critério, as decisões
tomadas poderão representar perdas significativas de dinheiro e recursos (BRAGA,
2004).
Supondo que uma organização possua dez sistemas legados, a qualidade e o
valor de negócios de cada um desses sistemas são avaliados e comparados com
outros sistemas, mediante um gráfico, que mostra o valor de negócios relativo e a
qualidade do sistema. Na figura (7), é possível verificar que existem quatro grupos
de sistemas e que se subdividem em: baixa qualidade, baixo valor de negócios;
baixa qualidade, alto valor de negócios; alta qualidade, baixo valor de negócios e
alta qualidade, alto valor de negócios (SOMMERVILLE, 2003).
Figura 7 – Qualidade de sistema e valor de negócio
Fonte: SOMMERVILLE, 2003.
Quando o sistema se encaixa no nível de “Baixa qualidade, baixo valor de
negócios” significa que manter esses sistemas em operação será dispendioso e a
taxa de retorno de investimento para os negócios será pequena. Esses sistemas são
candidatos a serem descartados (BRAGA, 2004).
Agora se o sistema se enquadra no nível de “Baixa qualidade, alto valor de
negócios” significa que esses sistemas estão prestando uma importante contribuição
à empresa, assim, não podem ser descartados. Porém, sua baixa qualidade significa
33
que os custos operacionais são altos, de modo que são candidatos à transformação
ou à substituição do sistema (BRAGA, 2004).
No nível de “Alta qualidade, baixo valor de negócios” significa que são sistemas que não contribuem muito para os negócios, mas cuja manutenção pode não ser muito dispendiosa. Não vale o risco substituir esses sistemas, de modo que a manutenção normal pode ser continuada ou eles podem ser descartados (WARREN, 1998).
Quando o sistema se enquadra no nível de “Alta qualidade, alto valor de
negócios” significa que esses sistemas devem ser mantidos em operação, mas sua
alta qualidade significa que não é necessário investir na sua transformação ou
substituição. Deve-se continuar com a manutenção normal do sistema (WARREN,
1998).
3.5 MANUTENÇÃO
A manutenção é definida como a totalidade de atividades requeridas para
prover suporte de custo efetivo para um sistema de software. As atividades são
realizadas tanto durante o estágio de pré-entrega quanto no estágio de pós-entrega.
A manutenção é uma atividade inevitável e pode vir a ser a mais longa fase no ciclo
de vida do sistema, isso se justifica através das leis de evolução do software
(RAMOS, 2008).
Essas leis de evolução do software são: “mudança contínua” no qual os
sistemas devem ser continuamente adaptados senão se tornará progressivamente
insatisfatório. O “aumento da complexidade” no qual o sistema aumenta sua
complexidade conforme evolui, a não ser que algo seja feito para controlar tal
complexidade. O “crescimento contínuo” no qual o conteúdo funcional de um sistema
deve crescer continuamente para manter a satisfação do usuário durante a sua vida
útil (RAMOS, 2008).
Os principais fatores que dificultam e encarecem a manutenção no software
legado é que muitas vezes é excepcionalmente difícil entender o programa “de outra
pessoa”, isso porque foram implementadas por diferentes equipes. Não há um estilo
de programação consistente em todo sistema e os algoritmos são mal escritos. Uma
parte ou todo sistema pode ter sido desenvolvido em uma linguagem obsoleta, e
encontrar um profissional que tenha conhecimento dessa linguagem acaba sendo
34
difícil e caro, uma vez que um profissional deste nível é raro no mercado e o seu
salário maior (RAMOS, 2008).
Muitas vezes foi usado um sistema de administração de bases de dados que
pode estar obsoleto, ou depende de arquivos armazenados separadamente. No
caso de arquivos separados, cada um tem seu próprio formato e, frequentemente, as
mesmas informações são duplicadas e representadas em diferentes formas e em
diferentes arquivos. Essa duplicação usualmente acontece porque as informações
são fortemente integradas com as estruturas de dados dos programas (DINIZ, 2010).
Outro problema do software legado está em sua documentação, muitas vezes
não existe documentação e quando existe, ela não é compreensível e consistente
com o código fonte, neste caso ela não tem valor. Em alguns casos, a única
documentação é o código-fonte do sistema (RAMOS, 2008).
Esses softwares por não serem projetados não são apitos e nem estão preparados para mudanças, às chances de perda de desempenho devido a modificações não adequadas na sua estrutura interna e o número crescente de novos erros devidos a alterações indevidas no código é um risco que se corre (PINTO, 2004).
Os sistemas são feitos para refletir comportamentos do mundo real, logo é
necessário que o software acompanhe as mudanças impostas pelo ambiente na
qual está inserido. Uma falha em acompanhar essas mudanças pode implicar em
perda de qualidade por parte do software ou até mesmo no fim da sua vida útil, os
muitos anos de manutenção podem corromper a estrutura do sistema, tornando-o
cada vez mais difícil de ser compreendido. O envelhecimento de um software é um
processo inevitável (PINTO, 2004).
Existem dois tipos de envelhecimento de software: o primeiro ocorre quando os responsáveis por um software falham em adaptá-lo para os novos requisitos, um exemplo seria um software que no passado funcionava perfeitamente, mas devido ao fato de seu sistema operacional ter caído em desuso e não existir uma nova versão do software para um sistema operacional mais recente foi esquecido por seus usuários (PINTO, 2004).
O segundo ocorre quando mudanças no software são feitas por
desenvolvedores que não entendem a estrutura original deste, o que fatalmente
implicará em algum dano para esta estrutura, que mesmo pequeno irá aumentando
conforme novas atualizações forem sendo feitas, e com o passar do tempo cada
nova mudança se tornará mais difícil e consequentemente cara. Caso não seja feita
uma reestruturação do software, este chegará a um ponto onde novas atualizações
ficarão inviáveis (PINTO, 2004).
35
A partir do momento em que um sistema começa a ser utilizado, ele entra em
um estado contínuo de mudança. Mesmo que tenha sido construído aplicando as
melhores técnicas de projeto e codificação, os sistemas vão se tornando obsoletos
em vista das novas tecnologias que são disponibilizadas (PIEKARSKI, 2000).
As leis da evolução de software são estudadas há 30 anos, e sua contribuição para a melhor compreensão da evolução de software e a engenharia de software como um todo são ainda inestimáveis (VASCONCELOS, 2007).
Com o objetivo de minimizar os problemas gerados por manutenções difíceis e,
algumas vezes, degenerativas da estrutura do sistema, muitas organizações estão
optando por refazer seus sistemas. A ideia básica dessa reconstrução ou
reengenharia é que as informações de projeto e especificação sejam extraídas do
código fonte, reformuladas e reconstruídas, resultando um software mais fácil de ser
mantido (BENNETT, 1991).
Aplicando-se a reengenharia de software, o sistema pode ser redocumentado
e/ou reestruturado, podem ser traduzidos para uma linguagem de programação mais
moderna e implementados em uma plataforma distribuída, bem como seus dados
podem ser migrados para uma base de dados diferente. A reengenharia de software
tem como objetivo fazer sistemas flexíveis, fáceis de modificar, frente às constantes
mudanças das necessidades dos usuários (BENNETT, 1995).
O campo da reengenharia está crescendo em resposta à necessidade crítica
que existe na indústria de software por tecnologia que suporte a manutenção de
sistemas legados e o desenvolvimento evolutivo de novos sistemas. Existe uma
firme e crescente demanda para migrar programas legados de mainframes
monoprocessados, para estações multiprocessadas, distribuídas e ligadas em rede,
visando acompanhar os avanços das técnicas de programação tais como: interfaces
gráficas para o usuário, comunicação interprogramas, desenvolvimento orientado a
objetos, reusabilidade, etc. (COLEMAN, 1994).
3.6 PROBLEMAS COM O LEGADO
Os sistemas legados constituem a parte mais importante do fluxo de
informações dentro das organizações e são os principais veículos para a
consolidação das informações sobre o negócio. O conhecimento agregado nestes
sistemas constitui um patrimônio corporativo significativo. Por tratar de sistemas
36
críticos apresentam numerosos e importantes problemas para as empresas
(BISBAL, 1999).
Entre os mais significativos destacam-se: apresentam plataformas de hardware
com altos custos de manutenção que poderá se tornar numa das maiores despesas
na área de TI; desenvolvidos em plataformas proprietárias; não passíveis de
publicação na internet; apresentam limitações de integração com outros sistemas; e
restritos com relação ao desenvolvimento de novas funcionalidades (STEVENS,
1998).
Os negócios de hoje só podem sobreviver se eles puderem adaptar
rapidamente para um ambiente variável e tirar vantagens das novas oportunidades
de negócio. A partir do momento que os sistemas de TI se tornam vitais a quase
todos os negócios, é necessário que estes sistemas possam ser modificados
rapidamente e com baixo custo (STEVENS, 1998).
A maioria dos sistemas legados passou por mudanças contínuas durante
muitos anos de manutenção. De acordo com a segunda lei de evolução de
programas de Lehman (1985), quando um programa em evolução é continuamente
modificado, sua estrutura se deteriora, consequentemente a complexidade aumenta.
Esse aumento de complexidade ocorre porque há uma precipitação ao elaborar as
correções dos problemas e não há tempo para manter o refinamento de um projeto
ou a consistência da abordagem em todo o código (LEHMAN, 1985).
A pressa em disponibilizar um produto pode levar mantenedores a implementar
uma modificação rápida, ineficiente e sem ter sido adequadamente testada, em vez
de utilizar o tempo necessário para seguir as boas práticas de engenharia de
software. O resultado é um produto com vários "remendos" e difícil de ser entendido
e mantido (LEHMAN, 1985).
Atualmente as organizações estão enfrentando uma grande pressão para
modernizar seus sistemas, a fim de que possam responder melhor às necessidades
da área de mercado e de pessoas e às rápidas mudanças de tecnologia (LEHMAN,
1985).
37
4 REENGENHARIA DE SOFTWARE
O software é o conjunto de vários artefatos e não apenas o código fonte. O
software não é um produto acabado, está sempre em mutação, condição esta
originária de mudanças nas regras de negócio das organizações, da necessidade de
melhoria do processo produtivo ou da adequação do produto ou do serviço que
utiliza tecnologia da informação e está disponibilizado para uso (ZANLORENCI,
2009).
Muitas organizações têm enfrentado problemas com o uso e a manutenção de
software construído para ser executado em uma variedade de tipo de hardware e
programado em linguagem obsoletas. A tarefa de realizar a manutenção torna-se
mais complexa e mais cara e, ainda, esses sistemas tornam-se cada vez mais
desorganizados devido às inúmeras tentativas de adaptações e inclusões de novas
funcionalidades. Sendo assim, as organizações têm três alternativas: manter os
softwares legados, comprar um novo software ou realizar a reengenharia tanto para
aumentar sua manutenibilidade quanto para implementá-los em um paradigma mais
atual com ou sem mudança de linguagem (SOMMERVILLE, 2003).
Quando o sistema não é fácil de ser mantido sendo, porém, de grande utilidade, ele deve ser reconstruído. Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software. Esse processo é denominado reengenharia de software (PIEKARSKI, 2000).
O termo reengenharia pode referir-se tanto à reengenharia do processo de
negócios (Business Process Reengineering – BPR) quanto à reengenharia de
sistemas (Systems Reengineering – SR). Trata-se de abordagens diferentes,
embora muitos autores afirmem que deveria haver uma maior sinergia entre estes
dois processos dentro de uma empresa. De fato, pode-se comprovar que a
reengenharia do processo de negócios pode ser alavancada com o auxílio
computacional da reengenharia de sistemas, ao passo que a reengenharia de
sistemas pode beneficiar-se com a aplicação dos conceitos da reengenharia do
processo de negócios (SILVA, 2005).
A reengenharia de software também chamada renovação ou recuperação de
software é definida como a recuperação rigorosa do conhecimento embutido em
sistemas existentes a fim de alavancar os esforços em seu aprimoramento,
procurando melhorar sua qualidade global e reduzir custos com manutenção, isto é,
38
reestruturar ou reescrever todo ou parte de um sistema legado sem alterar suas
funcionalidades (SILVA, 2005).
Um processo de reengenharia geralmente inclui tradução do código-fonte,
melhoria na estrutura do programa, modularização, alguma forma de engenharia
reversa seguida por uma forma de engenharia progressiva ou reestruturação e
reengenharia de dados (SILVA, 2005).
Existem diferentes tipos de reengenharia: com a troca parcial ou completa da
implementação sem a troca da funcionalidade, em que há mudança do paradigma
de desenvolvimento e/ou da linguagem de implementação, preservando o
funcionamento do sistema; e com troca da funcionalidade, em que se aplica o
processo tradicional de desenvolvimento de software, modificando o funcionamento
do sistema no modelo de análise e implementando-o novamente (PIEKARSKI,
2000).
É importante ressaltar que existe uma clara distinção entre o desenvolvimento
de um novo software e a reengenharia, a distinção está relacionada ao ponto de
partida de cada um dos processos. O desenvolvimento de um novo software
(engenharia progressiva) inicia-se com uma especificação escrita do software que
será construído, enquanto que a reengenharia inicia-se tomando como base um
sistema já desenvolvido. Como mostra a figura (8) abaixo (SOMMERVILLE, 2003).
Figura 8 - Distinção entre o desenvolvimento de um novo software (1) e reengenharia (2)
Fonte: SOMMERVILLE, 2003.
O objetivo da engenharia reversa é derivar o projeto ou especificação de um
sistema, partindo-se de seu código fonte. O objetivo da reengenharia é produzir um
sistema novo com maior facilidade de manutenção. A engenharia reversa é usada
39
como parte do processo de reengenharia, pois fornece o entendimento do sistema a
ser reconstruído (SOMMERVILLE, 2003).
Para melhorias relacionadas à reengenharia, podem-se estabelecer três
categorias, que são: reengenharia de processos administrativos (direcionada para
alterações potenciais em todos os negócios ou processos organizacionais);
reengenharia de processos produtivos (consiste em modificar qualquer ciclo de
processos padrão, que esteja em uso em uma dada organização, a fim de melhora);
reengenharia de software ou produtos (captura e modificação de mecanismos
internos ou funcionalidade de um sistema existente ou produto, visando reconstituí-
lo em uma nova forma e com novas características, frequentemente para tomar
vantagem das novas e emergentes tecnologias, mas sem grandes alterações na
funcionalidade e propósito inerentes ao sistema) (SOMMERVILLE, 2003).
4.1 RELACIONAMENTOS NO CICLO DE DESENVOLVIMENTO
Para uma melhor compreensão das técnicas de manutenção de software, é
preciso considerar três conceitos dependentes: a existência de um processo de
desenvolvimento de software, a presença de um sistema a ser analisado e a
identificação de níveis de abstração (independência dos dados e dos programas)
(OSBORNE e CHIKOFSKY, 1990).
Independente do que seja o processo de desenvolvimento de software, espera-
se que haja interação entre seus estágios e, quiçá, recursão. No processo de
desenvolvimento de software, os estágios iniciais envolvem conceitos mais gerais,
independentes de implementação, enquanto os estágios finais enfatizam os detalhes
de implementação (OSBORNE e CHIKOFSKY, 1990).
O aumento de detalhes durante o processo de desenvolvimento conceitua os níveis de abstração. Estágios iniciais do sistema planejam e definem requisitos de alto nível quando comparados com a própria implementação (PIEKARSKI, 2000).
Esta comparação deixa claro que nível de abstração e grau de abstração são
grandezas distintas. Enquanto o nível de abstração é um conceito que diferencia os
estágios conceituais do projeto, o grau de abstração é intrínseco a cada estágio
(PIEKARSKI, 2000).
A evolução através das fases do processo de desenvolvimento de software
envolve transições dos níveis mais altos de abstração nos estágios iniciais, para
40
níveis mais baixos nos estágios posteriores. As informações podem ser
representadas em qualquer estágio do desenvolvimento, seja de forma detalhada
(baixo grau de abstração), seja de forma mais sucinta ou global (alto grau de
abstração). Abstração é definida como a habilidade de se ignorar os aspectos de
assuntos não relevantes para o propósito em questão, tornando possível uma
concentração maior nos assuntos principais (PIEKARSKI, 2000).
Para que as técnicas de manutenção de software (especificamente engenharia
reversa e reengenharia) sejam descritas de forma simplificada, serão tomadas como
base três fases do processo de desenvolvimento de software, com níveis de
abstração diferenciados, conforme figura 9 (OSBORNE e CHIKOFSKY, 1990):
• Requisitos: especificação do problema a ser resolvido, incluindo objetivos,
restrições e regras de negociação;
• Projeto: especificação da solução;
• Implementação: codificação, teste e adaptação ao sistema operacional;
A técnica tradicional, que avança progressivamente pelas fases do processo de desenvolvimento de software, é denominada engenharia progressiva. A execução dessa técnica consiste em partir de projetos independentes da implementação, que possuem altos níveis de abstração, indo em direção à implementação física do sistema (OSBORNE e CHIKOFSKY, 1990).
Figura 9 - Relacionamentos no ciclo de desenvolvimento de software Fonte: CHIKOFSKY e CROSS, 1990.
41
Na Figura 9, com exceção da engenharia progressiva, as demais transições
entre as fases de desenvolvimento são tecnologias utilizadas na manutenção de
software, sendo assim definidas por PIEKARSKI (2000):
• Redocumentação: como uma subárea da engenharia reversa, é a criação ou
revisão de uma representação semanticamente equivalente, dentro do mesmo nível
relativo de abstração, sendo que as formas resultantes de representação são
consideradas como visões alternativas, utilizadas para uma melhor compreensão
humana do sistema analisado;
• Recuperação de projeto: é uma subárea da engenharia reversa em que o
conhecimento do domínio da aplicação, informações externas e dedução são
adicionados nas observações referentes ao programa, com fim de extrair abstrações
significativas de mais alto nível, além das obtidas por meio da observação direta do
sistema;
• Reestruturação: é a modificação de uma forma de representação, para outra
no mesmo nível de abstração relativo, preservando o comportamento externo do
sistema (funcionalidade e semântica). Frequentemente usada como uma forma de
manutenção preventiva, a reestruturação é aplicada em sistemas que tenham sido
desenvolvidos de forma desestruturada, resultando uma representação que preserva
as características do sistema, mas de forma melhor estruturada;
• Engenharia reversa: é o processo de analisar um sistema a fim de criar sua
representação de uma forma diferente ou em um nível mais alto de abstração do que
o código fonte;
• Reengenharia: é a reconstrução de algo do mundo real, tendo como propósito
a tentativa por melhorias que permitam produzir algo de melhor qualidade ou
comparável ao produto inicial.
4.2 PROCESSO DE REENGENHARIA DE SOFTWARE
O processo de reengenharia é amplamente reconhecido como um dos desafios
mais significativos para engenheiros de software e é sob um processo bem definido
que a estabilidade no desenvolvimento do software pode ser instituída. O problema
é comum, afetando todos os tipos de organização, pois uma falha na reengenharia
pode dificultar os esforços da organização para manter-se competitiva (BORGES,
2007).
42
A capacitação em desenvolvimento de software pressupõe a existência de um
processo de software definido no qual é aplicado um modelo de melhoria de
processos. O processo definido tem documentação que detalha o que é feito,
quando, por quem, o que é utilizado e o que é produzido. A maturidade do processo
indica até que ponto um processo é definido e implementado, utilizando para isso
aspetos como métricas para verificação do controle e da eficácia (BORGES, 2007).
Assim, a capacitação em desenvolvimento de software reflete o grau de
institucionalização de uma infraestrutura e cultura relacionada aos métodos, práticas
e procedimentos do desenvolvimento de software. Reflete, também, a qualidade do
processo, pois a qualidade dos produtos de software depende diretamente da
qualidade do processo de desenvolvimento a eles associados (BORGES, 2007).
Um processo de reengenharia tem como entrada um programa legado e a
saída é uma versão estruturada e modularizada do mesmo programa. Ao mesmo
tempo em que ocorre a reengenharia do programa, os dados do sistema também
podem passar por reengenharia (BORGES, 2007).
A reengenharia de dados é o processo de analisar e reorganizar estruturas de dados e, eventualmente, os valores dos dados de um programa, com o objetivo de torná-lo mais compreensível. Em princípio, a reengenharia de dados não deverá ser necessária, se a funcionalidade do sistema permanecer inalterada. Na prática, há uma série de razões pelas quais é preciso modificar os dados, como também os programas, em um sistema legado (SOMMERVILLE, 2003).
Efetuar o processo de reengenharia em uma aplicação implica em examinar e
alterar um sistema com o propósito de reconstituí-lo em um novo modelo e uma
implementação de nova forma. A figura 10 exibe as principais etapas no processo de
reengenharia de software (PIEKARSKI, 2000).
Figura 10 – Processo de reengenharia Fonte: SOMMERVILLE, 2003
43
4.2.1 Tradução de código-fonte
Quando um programa se encontra escrito em uma linguagem de programação
e precisa, por algum motivo como, por exemplo, falta de suporte ao compilador atual,
ser migrado para outra linguagem, a tradução do código-fonte se faz necessária
(MAZZANTI, 2008).
A tradução do código-fonte mantém a estrutura e a organização do programa
em si inalterada. A linguagem para a qual o programa será transcrito pode ser uma
versão atualizada da linguagem original, como, por exemplo, de PHP 4 para PHP 5,
ou pode ser uma linguagem diferente, como, por exemplo, de C++ para Java
(MAZZANTI, 2008).
A tradução de código-fonte só será economicamente viável se existir alguma
ferramenta para realizar a maior parte da tradução de forma automatizada. Na
maioria dos casos, é impossível realizar a tradução de forma completamente
automática. As instruções da linguagem original podem não ter nenhuma instrução
equivalente na nova linguagem. Embora, esse tipo de ferramenta tem evoluído, não
são raros os casos em que os desenvolvedores devem intervir e corrigir possíveis
erros manualmente (SOMMERVILLE, 2003).
Existem algumas ferramentas no mercado que se propõem a fazer essa tarefa, tais como: CodePorting C#2Java - esta ferramenta converte projetos C# para Java e promete usabilidade, produtividade, simplicidade, confiabilidade, administração facilitada e poderosas customizações; Composer CipherSoft – converte aplicações Oracle Forms e PL/SQL para Java; Telescope for Jaguar – converte Oracle Forms para Java, trata-se de uma solução semi-automatizada, pois precisa de análise da empresa desenvolvedora antes da migração. Existem ainda ferramentas que se destinam a facilitar a atualização de uma tecnologia para outra: a Oracle Forms Migration Assistant é uma ferramenta que atualiza as aplicações Oracle Forms 6i para Oracle Forms 11g (LOVATTO, 2012).
Conversões de linguagens são bem mais difíceis do que se costuma imaginar,
principalmente por problemas de automação. A maioria das ferramentas de
conversão aplica a tecnologia da conversão sintática, mesmo com esta abordagem
aparentemente simples e de baixo nível, muitas dificuldades ocorrem, e o tamanho
das complexidades ainda não é muito bem definido (MAZZANTI, 2008).
É preciso deixar claro que diferente da tradução do código-fonte, a
“segmentação” é o processo de reengenharia com mudança da orientação de
procedimental para orientação a objetos, preservando-se as funcionalidades do
software e a linguagem de programação. Portanto, é realizada a adaptação do
44
código-fonte, de acordo com os recursos disponíveis na linguagem, de forma a
implementá-lo com características orientadas a objetos (LOVATTO, 2012).
4.2.2 Engenharia reversa
O termo engenharia reversa tem suas origens na análise do hardware, onde a
prática de “decifrar” projetos de produtos era mais comum (PRESSMAN, 1995).
A engenharia reversa é definida como o processo de se tomar um objeto para
verificar como ele funciona, a fim de copiá-lo ou de aprimorá-lo. É uma prática
herdada das antigas indústrias e que, atualmente, é usada em software e hardware.
Na indústria automobilística, por exemplo, um fabricante pode comprar um veículo
de um concorrente, desmontá-lo e examinar as soldas, lacres e outros componentes
do veículo, com o propósito de aprimorar seus próprios veículos, com componentes
similares (PRESSMAN, 1995).
Segundo Chikofsky e Cross, pode-se definir engenharia reversa como uma
coleção de teorias, metodologias, e técnicas capazes de suportar a extração e
abstração de informações de um software existente, produzindo documentos
consistentes, quer seja a partir somente do código fonte, ou através da adição de
conhecimento e experiência que não podem ser automaticamente reconstruídos a
partir do código (CHIKOFSKY e CROSS, 1990).
Quando se trata de software, o programa que passará pelo processo de
engenharia reversa não é o do concorrente, e sim o sistema da própria organização.
Este processo fornece informações da especificação e do projeto de um sistema de
software, a partir de seu código-fonte. Depois, essas informações são armazenadas
de forma que seja possível manipulá-las. Portanto, a engenharia reversa para o
software consiste na análise de um programa, com o objetivo de criar uma
representação do programa em um nível de abstração maior que o código-fonte
(PFLEEGER, 2004).
O processo de engenharia reversa (figura 11) começa com uma fase de análise
utilizando-se ferramentas automatizadas, a fim de descobrir a estrutura do sistema,
estudar como o programa efetua certas operações, melhorar o desempenho do
programa, corrigir uma falha, identificar vírus, ou para adaptar um programa para
que possa ser executado em uma plataforma diferente. Estas informações são
45
mantidas em dicionários de dados que mantém as informações do sistema,
vinculados ao código-fonte do programa (SOMMERVILLE, 2003).
Figura 11 – Processo de engenharia reversa
Fonte: SOMMERVILLE, 2003.
A recuperação de projeto é uma subárea da engenharia reversa na qual o
conhecimento do domínio da aplicação, informações externas e dedução são
adicionados às observações referentes ao programa, para extrair abstrações
significativas de mais alto nível, além daquelas obtidas através da observação direta
do sistema (SOMMERVILLE, 2003).
Documentos de vários tipos como diagramas de programa e de estrutura de dados e matrizes de rastreamento (que mostram onde as entidades são definidas e referenciadas no sistema), podem ser gerados através das informações armazenadas (SOMMERVILLE, 2003).
Como uma subárea da engenharia reversa, a documentação é a criação ou
revisão de uma representação semanticamente equivalente, dentro do mesmo nível,
relativo de abstração, sendo que as formas resultantes de representação são
consideradas como visões alternativas, utilizadas para uma melhor compreensão
humana do sistema analisado (SOMMERVILLE, 2003).
Depois de gerada a documentação do sistema, outras informações podem ser
adicionadas aos dicionários de dados a fim de ajudar a recriar a especificação do
sistema. Isto, em geral, envolve mais anotações manuais da estrutura do sistema. A
especificação não pode ser inferida automaticamente a partir do modelo do sistema.
(SOMMERVILLE, 2003).
Atualmente, existem várias ferramentas automatizadas e semi-automatizadas
para auxiliar no processo de engenharia reversa. Entretanto, em qualquer processo
46
de engenharia reversa de sistemas, o envolvimento de especialistas no domínio e na
aplicação é fundamental (SOMMERVILLE, 2003).
4.2.2.1 Visões de software
A partir da engenharia reversa e com base nos níveis e graus de abstração, o
software pode ser visualizado de diferentes maneiras, conforme conceitos de
HARANDI (1990):
• Visão em nível implementacional: abstrai características da linguagem de
programação e características específicas da implementação.
• Visão em nível estrutural: abstrai detalhes da linguagem de programação
para revelar sua estrutura a partir de diferentes perspectivas. O resultado é uma
representação explícita das dependências entre os componentes do sistema.
• Visão em nível funcional: abstrai a função de um componente, isto é, o que o
componente faz. Essa visão relaciona partes do programa a suas funções,
procurando revelar as relações lógicas entre elas.
• Visão em nível de domínio: abstrai o contexto em que o sistema está
operando, ou seja, o porquê do sistema a ser desenvolvido.
Conforme figura 12 é perceptível a correspondência entre as categorias de
visualização do software e as diferentes atividades do ciclo de desenvolvimento de
software (HARANDI, 1990).
Figura 12 - Visualizações de software no ciclo de desenvolvimento
Fonte: HARANDI, 1990.
47
É relevante ressaltar que uma forma de representação extraída do código pode diferir de uma representação similar que foi desenvolvida no processo de engenharia progressiva. A forma extraída irá refletir a idiossincrasia da representação do código muito mais do que a representação original, que reflete a compreensão do problema pelo analista ou projetista (HARANDI, 1990).
Muitas vezes é necessário acrescentar às informações contidas no código,
outras informações de conhecimentos e experiências humanas, para obter visões
diferenciadas do software. Conforme o escopo das informações usadas, que
resultarão em um nível de entendimento obtido do sistema pode-se formular uma
categorização dos métodos de engenharia reversa (HARANDI, 1990).
4.2.3 Melhoria da estrutura do programa
A reestruturação do programa é feita com o objetivo de tornar o software mais
fácil de ser entendido e modificado. Em sua maioria os programas desenvolvem uma
complexa estrutura lógica devido a diversas modificações sofridas durante a
manutenção. A adição de novos comandos sem modificar a estrutura de controle
existente, é um exemplo (MAZZANTI, 2008).
No curto prazo, essa é uma solução com menor risco e mais rápida, uma vez que reduz as chances de um defeito ser introduzido no sistema. No longo prazo, entretanto, isso pode resultar em um código incompreensível. Estruturas complexas de código podem também ser utilizadas quando os programadores procuram evitar duplicação de código, como em sistemas que são restringidos por uma memória limitada, por exemplo (MAZZANTI, 2008).
A figura (13) abaixo representa as três principais atividades envolvidas na
reestruturação do programa: inicialmente é feito uma analise estática a fim de obter
informações que servem para representar o código como uma rede semântica ou um
grafo direcionado. Esta representação não é necessariamente fácil de ser
compreendida pelas pessoas, normalmente, ela é utilizada apenas por uma
ferramenta automatizada. Após isso, a representação é refinada por meio de
sucessivas simplificações com base em técnicas de transformação. Por fim, uma vez
completada as simplificações, um novo programa é gerado (MAZZANTI, 2008).
Ou seja, a reestruturação é a transformação de uma forma de representação,
para outra no mesmo nível de abstração relativo, preservando o comportamento
externo do sistema (funcionalidade e semântica). Geralmente usada como uma
forma de manutenção preventiva, a reestruturação é aplicada em sistemas que
48
tenham sido desenvolvidos de forma desestruturada, resultando uma representação
que preserva as características do sistema, porém de forma estruturada
(SOMMERVILLE, 2003).
Figura 13 – Processo de reestruturação de programa Fonte: SOMMERVILLE, 2003.
4.2.4 Modularização de programa
Segundo LOVATTO (2012) modularização é um conceito onde o software é
divido em partes distintas, compõe o ferramental necessário para um programa mais
legível com uma melhor manutenção e melhor desempenho por meio da
programação estruturada.
É caracterizado como um elemento separadamente endereçável do sistema,
menor parte do sistema que realiza uma função completa independente de outras
funções, conjunto de instruções de um programa que pode ser chamado por um
nome, sendo ideal que para os outros módulos seja uma caixa preta (LOVATTO,
2012).
A modularização do programa consiste na reorganização do mesmo, de modo
que as partes relacionadas sejam reunidas em um único módulo. Assim, fica mais
fácil remover redundâncias nesses componentes relacionados, aperfeiçoar suas
interações e simplificar suas interfaces com o restante do programa (MAZZANTI,
2008).
Segundo Mazzanti (2008) diversos tipos de módulos podem ser criados
durante o processo de modularização do programa. São elas:
49
• Abstrações de dados: agrupam os dados e o processamento associado,
como funções de construção e de acesso, e são flexíveis em relação às mudanças.
Desde que a interface seja mantida, as modificações em dados abstratos não devem
afetar outras partes do programa.
• Módulos de Hardware: esses módulos agrupam todas as funções
relacionadas ao controle de um determinado dispositivo de hardware e estão
estreitamente relacionados com as abstrações de dados.
• Módulos funcionais: esses módulos agrupam funções que realizam tarefas
semelhantes, estreitamente relacionadas. Todas as funções ocupadas com dados
de entrada e a validação destes dados, por exemplo, podem ser agrupadas em um
único módulo.
• Módulos de apoio ao processo: todas as funções e todos os itens específicos
de dados que apoiam um processo de negócio específico são agrupados nesses
módulos.
A modularização de programas juntamente com outras técnicas de
programação integram o ferramental para a elaboração de programas visando,
principalmente, os aspectos de confiabilidade, legibilidade, manutenção e
flexibilidade (LOVATTO, 2012).
4.2.5 Reengenharia de dados
A reengenharia de dados é o processo de analisar e reorganizar estruturas de
dados e, eventualmente, os valores dos dados de um programa, com o objetivo de
torná-lo mais compreensível (SOMMERVILLE, 2003).
Muitas aplicações contêm dezenas de programas acima dos 20 anos de idade.
Esses programas possuem milhares de elementos de dados, alguns redundantes,
inconsistentes, ou incompreensíveis, e milhares de linhas de código, alguma
obsoletas, outras incorretas. Utilizando ferramentas CASE pode-se evitar alguns
problemas de dados nos novos sistemas, mas a maioria dos aplicativos não possui
força para detectar ou corrigir problemas de dados em sistemas existentes
(SOMMERVILLE, 2003).
De acordo com Sommerville (2003) a princípio, se a funcionalidade do
programa permanecer inalterada a reengenharia de dados não será necessária.
50
Porém, na prática, existem alguns fatores pelos quais os dados precisam ser
modificados, como:
• Degradação dos dados: existência de dados duplicados ou redundantes,
armazenados em diferentes partes do programa com diferentes formatos. Ainda, os
dados podem não refletir alterações no ambiente externo.
• Limites impostos aos programas: quando o sistema precisa tratar de um
volume maior de dados do que foi previsto pelos projetistas.
• Evolução da arquitetura: na migração de arquitetura centralizada para
distribuída, o acesso aos dados pode ser feito remotamente, por vários usuários e ao
mesmo tempo.
4.3 VANTAGENS DA REENGENHARIA
A reengenharia é a forma que muitas organizações estão buscando para
manter seus softwares, livrando-se das manutenções difíceis e da degeneração de
suas estruturas. Por este motivo, é importante que o resultado desse processo seja
confiável. Desta forma, a garantia da qualidade é o estopim para as vantagens da
mesma (LEMOS, 2003).
Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais (PRESSMAN, 2006).
Realizar a reengenharia é resultante de fatores como a necessidade de
melhoria da qualidade dos serviços e produtos oferecidos, a compressão das
margens de lucro, a redução do ciclo de vida dos produtos, a diminuição da
interferência dos governos e dos subsídios, a explosão tecnológica, o rápido
crescimento do conhecimento humano, a maturidade dos mercados de consumo e a
globalização da economia (HAMMER, 1994).
Outros fatores são relacionados com a complexidade das atividades
empresariais, tais como a busca por produtividade; a flexibilidade frente às
constantes mudanças; a concentração no ramo de negócio; os relacionamentos com
clientes, com o meio ambiente e com os governos; o apoio de consultores; a
parceirização; a gestão e a remuneração dos recursos humanos por resultados.
51
Todos esses pontos influenciam diretamente na reengenharia dos softwares
existentes em empresas (HAMMER, 1994).
A reengenharia melhora a estrutura do sistema, cria uma nova documentação
relacionada e faz com que ela seja de mais fácil compreensão. E como resultados
disso, as possíveis manutenções no software vão ser menos requisitados e quando
a mesma for, será de fácil resolução, uma vez que o programa estará mais bem
estruturado e documentado (SOMMERVILLE, 2003).
Quanto ao melhoramento da performance dos processos, em particular os que
envolvem forte componente humana, deve em primeiro lugar conhecer-se os fatores
a que o cliente atribui maior valor nos serviços que a organização lhe presta (ou
pode vir a prestar) para, a partir daí, identificar as atividades críticas desse ponto de
vista, as quais devem começar por ser submetidas a uma avaliação do seu atual
desempenho (MARI, 2008).
Esta medição da avaliação do desempenho é feita através de benchmarking,
isto é, de uma sistemática comparação de indicadores-chave da performance de
processos (key process performance indicators) entre a organização em causa e os
seus concorrentes melhor cotados no mercado, frequentemente essa comparação,
envolve organizações de outros setores de atividade mas com processos
semelhantes (MARI, 2008).
Centrando a atenção nesses processos e atividades críticas (sobretudo nos que acrescentam maior valor e estão com desempenho inferior ao "melhor da classe"), há que proceder ao seu redesenho, se necessário a partir do zero (isto é, de uma folha de papel em branco) (MARI, 2008).
Com alguma frequência, nesse redesenho é possível incluir aquilo que
poderemos designar por "pontos de ruptura" (breakthrougs), entendidos como sendo
algo que permite alcançar uma vantagem competitiva significativa e percepcionada
pelo mercado, como tendo introduzido neste um elemento diferenciador, que
normalmente resulta um acréscimo sustentado da quota de mercado (MARI, 2008).
As tecnologias de informação têm proporcionado muitos dos "pontos de
ruptura" que chegam ao nosso conhecimento como elementos fulcrais de casos bem
sucedidos de reengenharia, mas não é a sua única fonte. Portanto outros elementos
também contribuem para o sucesso da reengenharia, como por exemplo, a adoção
de novos métodos de trabalho, novas tecnologias de produção, novo desenho de
produtos e, inevitavelmente, novas formas de participação dos recursos humanos
(MARI, 2008).
52
Outra vantagem são os riscos reduzidos, pois existe um alto risco em
desenvolver um software novo que seja essencial. Podem ser cometidos erros na
especificação do sistema e ocorrer problemas de desenvolvimento, a importância da
reengenharia está em possibilitar que todas as funcionalidades do software legado
não sejam perdidas, o que aconteceria se fosse optado pelo desenvolvimento de um
novo software (MARI, 2008).
Uma das maiores vantagens da reengenharia é que ela preserva a solução
existente do negócio em uma nova arquitetura técnica e é uma solução que deve ser
considerada pelas empresas, pois os custos de desenvolvimento e implantação de
um novo sistema podem ser muito altos. Estudos têm mostrados que reengenharia,
quando aplicada apropriadamente, geralmente promove custo efetivo e menos riscos
do que o desenvolvimento de um novo sistema (CAGNIN, 2005).
Conclui-se que a reengenharia é de grande vantagem quando se trata de
sistemas legados, podendo envolver, documentar, organizar e reescrever o sistema
para uma linguagem de programação mais moderna. As vantagens da reengenharia
se destacam muito quando se trata de custo para as empresas e assim como de
tempo para a introdução do novo sistema na rotina da empresa (LEMOS, 2003).
4.4 DIFICULDADES NO PROCESSO DE REENGENHARIA
Atualmente, a qualidade dos softwares está cada vez melhor, a tecnologia e a
mobilidade está ao alcance de todos, porém ao mesmo tempo em que a tecnologia
evolui, muitas pessoas e gestores de organizações não conseguem se “vê” livres
dos softwares legados, mesmo que seja para usar como fonte de pesquisa em
dados antigos. Esses softwares legados, em sua grande maioria, são mantidos
ativos para qualquer que seja a eventualidade e sua perda é um risco que a
organização prefere correr (SILVA, 2005).
A quantidade de código em sistemas legados é imensa. Em 1990, estimava-se
que existiam 120 bilhões de linhas de código fonte de sistemas legados, a maioria
em COBOL ou FORTRAN (são linguagens de programação com facilidades
limitadas de estruturação de programas e dados). A migração ou alteração desses
softwares gera grandes desafios técnicos, uma vez que a perda de funções e custo
são as principais delas (BENNETT, 1995).
53
Ao mesmo tempo em que o software legado traz incorporado a ele o acúmulo de anos de experiência e refinamento, traz também todos os vícios e defeitos vigentes na época de seu desenvolvimento. Porém o que hoje é chamado de vício e defeito, naquela época era a melhor indicação para a resolução do problema (BENNETT, 1995).
Existem fatores que estão diretamente relacionados com a dificuldade e
entendimento do software legado, por exemplo, antigamente, ter um hardware com
um bom desempenho, era um custo muito alto para as organizações, então as
mesmas optavam por hardwares mais baratos e mais limitados, logo, o tamanho de
armazenamento do software tinha que ser reduzido. Hoje com hardware mais
baratos, isso não é mais um empecilho no desenvolvimento. Contudo, no
desenvolvimento do software sempre se prezou pela eficiência em detrimento da
clareza e estruturação do programa, o que leva a sucessivas manutenções e
consequentes degenerações no software (BENNETT, 1995).
Muitos softwares legados são críticos para os negócios das organizações que
os possuem, pois com eles têm embutidas informações dos negócios e
procedimentos, que na maioria das vezes não estão documentados. O risco de
remover e reescrever tais programas são grandes, pois muita informação teria que
ser redescoberta por tentativa e erro. Consequentemente, as organizações de um
modo geral, preferem não “aposentar” seus softwares legados e mantê-los em uso,
com adaptações às novas necessidades (BENNETT, 1995).
Muitos gerentes de tecnologia de informação têm medo de migrar para novas
tecnologias ou por que não confiam na tecnologia ou por que não confiam no seu
corpo técnico de pessoal. As dificuldades devem ser enfrentadas, pois qualquer
software que não evoluir continuamente, torna-se menos útil no mundo real (DINIZ,
2010).
Segundo Bennett (1991), os motivos de maior relevância para manter o
software legado são:
• Desestruturação e dificuldade de entendimento do código, pois o software foi
desenvolvido antes da introdução dos métodos de programação estruturada;
• Programadores que não participaram do desenvolvimento de software
sentem dificuldade em entender e mapear a funcionalidade para o código fonte;
• Documentação desatualizada, não auxiliando em nada a equipe de
manutenção;
• Dificuldade de predizer as consequências de efeitos colaterais;
54
• Dificuldade de administrar múltiplas alterações concorrentes.
Várias empresas se esquecem de considerar o risco de perda de capital
humano e o risco da solução parar de funcionar de uma hora para outra. Outro erro
comum é esquecer-se de considerar a oportunidade de investir em novas
tecnologias que oferecem um custo de manutenção menor e têm o potencial de
agregar mais valor em todo sistema, em especial no aspecto de usabilidade (DINIZ,
2010).
O número de sistemas que precisa ser modificado está aumentando
gradualmente, existe fila de espera para pedidos de manutenção. Assim fica claro
que às vezes é impossível para as organizações investirem em novos sistemas para
melhorar a eficiência organizacional (DINIZ, 2010).
O problema de manutenção de software legado é complexo, pois esses
sistemas não são simples programas, desenvolvidos e mantidos, a maioria é
composta de outros diferentes programas que, de alguma forma compartilham dados
(DINIZ, 2010).
Empresas com o problema de software legado devem capacitar seus gerentes
em reengenharia de software. Isso vai garantir não só que os gerentes tomem uma
atitude em relação ao software legado como também vai contribuir para uma
execução eficaz e eficiente do processo de migração. Para resolver esses
problemas é importante partir da etapa de conhecer as novas tecnologias, estudar
sobre novas linguagens, novos servidores de aplicação e novas arquiteturas e
investir em treinamento do corpo técnico (DINIZ, 2010).
4.5 CUSTO
A complexidade e tamanho dos programas legados têm influência direta no
custo de manutenção. O cálculo do custo de manutenção do software legado em
geral é equivocado, pois não “levam” em conta os riscos envolvidos na sua
permanência (YOURDON, 1990).
Pesquisas revelam que mais de 50% do custo de um produto de software está
relacionado com as atividades de manutenção, havendo casos de este percentual
chegar até a 85%. Em alguns negócios, estima-se que 80% de todos os gastos com
software são consumidos pelas manutenções e evoluções dos sistemas
(YOURDON, 1990).
55
Os custos da reengenharia dependem da extensão do trabalho que é realizado
(figura 14), a partir da complexidade de cada processo, consequentemente o custo
aumenta. O processo de reengenharia nem sempre sai mais barato que a
implantação de um novo sistema, contudo a reengenharia é a medida mais cabível
(MARI, 2008).
Figura 14 - Custo da reengenharia Fonte: BORGES, 2007
O custo envolve a qualidade do software que vai sofrer reengenharia; as
ferramentas disponíveis para fazer o processo de reengenharia; a quantidade de
dados que deverão passar por reengenharia de dados e também a disponibilidade
de pessoal habilitado (MARI, 2008).
O objetivo é aumentar os lucros, elevando a produtividade e diminuindo os
custos de produção, para tentar aumentar o mercado consumidor, que exige
qualidade e preços acessíveis (MARI, 2008).
A reengenharia reduz todos os tipos de desperdícios, reestruturando o
processo. Por exemplo: você corta uma folha de alumínio em tiras e, no final, sobra
uma tira que é menor que a largura necessária. Essa tira é jogada fora. Para encarar
novos desafios postos pela sociedade e pelo mercado, uma empresa precisa
repensar seus procedimentos operacionais. A meta é a de tornar as pessoas e as
máquinas mais eficientes. Assim será possível reduzir custos sem prejudicar
produtos e serviços (MARI, 2008).
A redução de custo é obtida através da eliminação de atividades que não
agregam valor ao produto e são dispensáveis no sistema (MARI, 2008).
É claro perceber que existe um mito se tratando do custo da reengenharia, pois
se tratando de nível à curto prazo, o custo será elevado pois acontecerá uma
reestruturação do sistema, mudanças geram gastos. Contudo, a nível de longo prazo
56
trará muitas vantagens, uma vez que o gasto com manutenção e mão de obra
específica não será um gasto decorrente nos próximos anos, a solicitação de
manutenção será menor (YOURDON, 1990).
4.6 FERRAMENTAS DE AUXÍLIO À REENGENHARIA
Existem ferramentas com a finalidade de auxiliar a execução da reengenharia.
A maioria das ferramentas é utilizada na etapa de engenharia reversa do sistema a
ser reconstruído (PRESSMAN, 2006).
As ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma
classificação que abrange todas as ferramentas baseada em computadores que
auxiliam atividades de engenharia de software, desde análise de requisitos e
modelagem até programação e testes. Podem ser consideradas como ferramentas
automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma
ou várias etapas do ciclo de desenvolvimento de software (JANONES, 2010).
O objetivo das ferramentas CASE, é a melhoria da qualidade de software, aumento da produtividade no processo de software, agilizar o tempo para tomada de decisão, menor quantidade de códigos de programação, melhoria e redução de custos na manutenção, agilidade no retrabalho do software, entre outras (JANONES, 2010).
As ferramentas baseadas em engenharia reversa estão ainda “engatinhando”,
ficando claro que as pesquisas na área de entendimento de código são muito
importantes e muitas outras pesquisas ainda acontecerão (PRESSMAN, 2006).
As ferramentas devem ser adequadas aos processos de reengenharia, e não
os processos adequados às ferramentas. As ferramentas de suporte disponíveis
para auxiliar a reengenharia têm influência sobre os custos de reengenharia
(PRESSMAN, 2006).
Existem muitas ferramentas de reengenharia com aplicabilidade em sistemas
de software. O quadro 1 apresenta várias dessas ferramentas, mostrando de onde
provêm as informações de entrada e o que cada uma delas produz como resultado
(PRESSMAN, 2006).
O escopo das informações que cada ferramenta utiliza é proveniente do código
fonte do software (cada ferramenta trabalha com código em determinada linguagem
pré-definida) e da base de conhecimento do sistema (constituída por documentação
57
existente, informações de usuários ou projetistas do software e bibliotecas de
componentes, entre outras) (PRESSMAN, 2006).
Em relação aos resultados produzidos, quando apenas o código fonte é
utilizado como entrada, as visões fornecidas são em nível implementacional e
estrutural. Para obtenção de visões mais abstratas (funcional e de domínio), bem
como outras saídas, é necessário utilizar como entrada, além do código fonte, bases
de conhecimento sobre o sistema (PRESSMAN, 2006).
Quadro 1 - Ferramentas de reengenharia
Fonte: PIEKARSKI, 2000.
4.7 ESTUDO DE CASO (EXEMPLIFICAÇÃO)
Estudo de caso retirado da revista “Interdisciplinar Aplicada”, ano 2004, cujos
autores são: Eliana Domingues da Cruz Milev e Francisco de Assis Zampirolli.
Segue a baixo o estudo de caso.
58
Esta seção apresenta o estudo de caso da substituição de um módulo de um
sistema de software denominado “Classificados”, utilizado em uma empresa
jornalística brasileira, que para fins desse trabalho será chamada J. Papel. Para que
esse sistema atenda os objetivos da empresa, vários módulos relacionados entre si
trabalham juntos. Esses módulos são fortemente interligados, o bom funcionamento
de um módulo muitas vezes depende do funcionamento dos demais módulos do
sistema.
Esse estudo se aplica à substituição do componente ou de “Classificados”, que
é responsável pela captação de anúncios da empresa. O J. Papel tem grande parte
de seu lucro oriundo de venda de espaço para publicação de anúncios solicitados no
caderno de classificados do jornal. Nesse caderno são publicados anúncios pagos
pelos clientes com a finalidade de divulgar um produto ou serviço. Para a captação
de anúncios a empresa trabalha com duas soluções com tecnologias diferentes:
Telefones e balcões (LEGADO_TEL); e Agências de Publicidade (LEGADO_AGE).
4.7.1 Sistema LEGADO_TEL
Das duas soluções existentes, essa (LEGADO_TEL) é a mais antiga e
apresenta diversos problemas, como segue:
• Sistema pouco flexível, não parametrizado, qualquer alteração implica em
manutenção no código;
• Código escrito com linguagem obsoleta;
• Dificuldades em encontrar profissionais que dominem a linguagem;
• Não usa uma base de dados padrão e isso dificulta o desenvolvimento e
integração com outros sistemas e/ou módulos;
• Espaço de armazenamento de dados reduzido e a tecnologia empregada não
permitem ampliações;
• Hardware obsoleto e sem suporte pelo fabricante, portanto com custo elevado
para qualquer necessidade de troca;
• Restrições para aumento da capacidade de processamento sem a troca total
do sistema (limitado em memória e em processador);
• O sistema não tem recursos de visualização de anúncios em sua forma final,
característica importantíssima em sistemas de jornal;
59
• Inviável o desenvolvimento de interface online para captação de anúncios
utilizando navegadores da Internet.
4.7.2 O problema
A empresa J. Papel tem que acompanhar a evolução para se manter no
mercado e ainda ampliar seus negócios oferecendo facilidades e melhores serviços
aos seus anunciantes e leitores.
O alvo de modernização é o caderno de “Classificados”, ele é uma das
principais fontes de lucro para a empresa e deve ser modernizado graficamente com
uma melhor distribuição de segmento de mercado permitindo anúncios com cor, foto
e destaque de logomarca com melhores resultados para o anunciante. O sistema
LEGADO_TEL por se tratar de um sistema legado, não suporta essa modernização
gráfica e se torna um obstáculo para o crescimento da empresa.
No ano de 2003, a empresa entende que esse sistema é crítico para a
organização e que sua substituição é vital. Diante disso o J. Papel decide investir em
software.
4.7.3 Alternativas de soluções
A empresa possui duas alternativas: substituição do sistema por uma solução
completamente nova ou reengenharia do sistema legado com a substituição do
módulo de “Classificados”.
Desenvolver um software crítico para a empresa é uma decisão arriscada, pois
pode demorar meses e até anos para sua finalização. A empresa não tem esse
tempo, a concorrência de mercado ajuda a decidir pela segunda e mais confiável
alternativa: substituir o módulo integrando-o aos demais módulos do sistema de
“Classificados”.
Várias empresas trouxeram soluções, a escolhida foi uma empresa americana
que propôs uma solução utilizando ferramentas de desenvolvimento de acordo com
a adotada pelo J. Papel. A solução escolhida, no entanto, deve manter as
funcionalidades do sistema atual e ainda proporcionar todas as novas funções
oferecidas pelo novo produto. Para que esse resultado fosse possível, as
especificações do sistema atual devem ser elaboradas pela equipe do J. Papel
60
seguindo um cronograma construído baseado em funcionalidades de superfície sem
um aprofundamento detalhado nos processos envolvidos.
O sistema LEGADO_TEL e suas interfaces com outros módulos possuem uma
documentação desatualizada, e nessas condições para elaborar especificações
quando a documentação do sistema não existe ou não está atualizada, a
Engenharia Reversa do sistema em produção é uma das formas para documentar o
que está em funcionamento e a Reengenharia proporá o processo alternativo. Outra
forma é escrever as especificações com base no conhecimento da equipe envolvida.
Porém, face ao pouco tempo designado para essa atividade, a forma escolhida foi a
segunda, as especificações foram baseadas no conhecimento da equipe, o que
resultou em especificações pouco detalhadas que dificultaram o entendimento para
a empresa que oferecia a nova solução e esquecimento de especificações de
algumas interfaces interligadas ao módulo a ser substituído.
4.7.4 Problemas na substituição
A tentativa de integração da solução adotada ocorreu durante o ano de 2004,
porém os problemas encontrados foram muitos:
• Definição do cronograma imposto fora da realidade;
• Prazo de entrega da solução subdimensionado;
• Fase de levantamento extremamente curta não permitindo ao fornecedor da
solução o tempo suficiente para entender todos os processos e necessidades da
empresa;
• O levantamento pouco detalhado resultou em conhecimento insuficiente do
processo atual de produção;
• Novas funcionalidades foram solicitadas pela empresa que não existiam no
sistema antigo e também não constavam em especificações;
• A empresa precisa se adaptar ao novo sistema já que nem todas as
funcionalidades e regras estavam sendo atendidas;
• O novo módulo oferecia muitas funcionalidades que nem mesmo a equipe
contratada para a implantação sabia como utilizar ou adaptar para as necessidades
da empresa;
61
• A solução adotada foi construída baseada em parametrizações. Porém muitas
regras específicas de negócio da empresa não eram atendidas através de
parâmetros e exigia modificação no código do sistema;
• Preocupação tardia com as principais interfaces (entradas e saídas);
• A solução não estava sendo utilizada em nenhum outro jornal o que
impossibilitava ver o resultado do produto em uso em outras empresas;
• Localização/customização do sistema por ser um sistema desenvolvido em
outro país o tratamento dado ao código de endereçamento postal (CEP) precisou ser
modificado, pois o cadastro do CEP no Brasil difere do americano.
• Vendas realizadas com cartão de crédito, o sistema americano vende com
cartão de crédito apenas com pagamento a vista, o sistema original não previa
parcelamentos;
• Problemas de comunicação, o sistema foi escrito em inglês e os primeiros
testes com a área usuária foram complicados por não terem sido traduzidos na
língua portuguesa. Além disso, as telas e mensagens de erros e alertas foram sendo
traduzido na fase de testes, o que gerou traduções mal feitas e incompletas e
descontentamento dos usuários;
• Integração não estava totalmente pronta e com tantas modificações feitas na
última hora gerou instabilidade (travamento do sistema);
• Paralelo à substituição do sistema, uma grande mudança ocorria ao mesmo
tempo, a terceirização do serviço de suporte;
• Trabalhar com dois novos fornecedores, ao mesmo tempo foi extremamente
complicado. Em alguns problemas de ambiente, como instabilidade ou travamento
do sistema, o fornecedor do suporte alegava que o problema estava no software e a
empresa fornecedora da nova solução acreditava que o problema era de suporte, e
dessa forma o problema não era atendido com rapidez necessária;
• Mudanças de regras ditadas por usuários eram constantes durante a fase de
testes de sistema;
• Com tantas mudanças a apresentação de bugs era frequente;
• A existência de todos esses problemas gerou um clima de instabilidade e
conflitos na equipe e culminou na saída dos dois principais gestores do projeto, um
de cada empresa, o que prejudicou ainda mais o desempenho da equipe envolvida;
• Com a saída dos dois principais gestores, a responsabilidade passou a
gestores com alto conhecimento técnico, porém com pouco conhecimento dos
62
processos do sistema “Classificados” e com nenhum tempo para aquisição do
conhecimento.
Apesar de tantas dificuldades, ainda acreditava-se que a empresa poderia
corrigir e adaptar o sistema, pois até então apresentava problemas de código e
estrutura que poderiam ser corrigidos. Com tantos contratempos, a empresa
fornecedora da solução somente conseguiu imprimir um teste do caderno de
classificados as vésperas da finalização do prazo de entrega do produto, prazo que
já havia sido prorrogado três vezes. O produto gerado durante os testes de
aceitação apresentou uma série de problemas. A empresa contratante decidiu por
rescindir o contrato.
4.7.5 Solução alternativa
A substituição do sistema fracassou, mas a necessidade da empresa de
modernizar seu caderno de Classificados era ainda prioritária. Pressionados pela
área comercial que tinha um produto novo a lançar, a modernização de seu caderno
de Classificados, a gerência de informática decide adotar um plano B.
O plano B era muito mais simples e econômico para a empresa. A empresa
brasileira responsável pela solução do sistema LEGADO_AGE, que atende as
agências de publicidade, oferecia uma substituição do software com as mesmas
funcionalidades do software da primeira solução escolhida e ainda uma opção para
o lançamento do novo produto.
No entanto, o plano B somente foi aprovado pela diretoria e áreas usuárias
porque a equipe que representava a fornecedora brasileira possuía profundo
conhecimento do sistema legado que seria adaptado para o lançamento do novo
produto e futuramente substituído. Além do conhecimento, a fornecedora brasileira
tranquilizou os representantes do J. Papel com um protótipo do caderno de
Classificados modernizado antes mesmo da aprovação do projeto.
Enfim, a solução oferecida tornou possível o lançamento do novo produto e o
lançamento do novo caderno de Classificados foi um sucesso e citam-se os
principais motivos que levaram a isso:
• O J. Papel decide pela adoção do Plano B, tendo em mãos um protótipo do
resultado final, ou seja, um teste com o caderno de Classificados modernizado de
acordo com as especificações da área comercial;
63
• O J. Papel designa um novo gestor com profundo conhecimento do sistema
de Classificados e das regras de negócio da empresa para gerenciar o plano B;
• A empresa contratada também tem conhecimento do sistema existente e das
regras de negócio específicas do J. Papel e efetua um levantamento preciso de
todos os processos afetados com a modificação;
• O cronograma imposto é rejeitado e após o planejamento é apresentado um
cronograma dentro da realidade;
• Prazo de entrega proposto é aceito pelas áreas Comercial e Tecnologia da
Informação;
• Todas as interfaces (entradas e saídas) são cuidadosamente analisadas e
suas modificações planejadas com antecedência;
• Todas as adaptações necessárias para a modificação dos processos são
efetuadas;
• Por ser um produto nacional, os problemas decorrentes de localização e
customização do sistema não ocorreram;
• Toda e qualquer mudança de regra foi cuidadosamente analisada antes de
ser aceita, recusada ou adiada;
• Comunicação facilitada, utilizando o idioma nativo.
4.6.6 Considerações finais
O estudo de caso relata dois experimentos de manutenção de software na qual
a empresa (denominada neste artigo por “J. Papel”) possuía duas alternativas:
substituição do sistema por uma solução completamente nova ou reengenharia do
sistema legado com a substituição do módulo de “Classificados”. A opção escolhida
foi a segunda.
A primeira tentativa de reengenharia fracassou, e os motivos do fracasso, são
explicáveis, uma vez que os processos não foram bem aplicados. No momento em
que deveria aplicar a “engenharia reversa” foi optado pelo caminho de
parametrização, e este fez perder regras específicas de negócio. Não houve um
melhor detalhamento dos processos anteriores no qual resultou na perca de
processos de produção importantes. A definição de prazos não foi estruturada e
ocasionou desorganização em todos os setores.
64
Entre outros problemas que aconteceram e que é detalhado no estudo de caso,
é imprescindível dizer, que quando os processos de reengenharia não são bem
feitos o resultado é o fracasso. Muitos gestores de TI temem a reengenharia por
medo de um dos processos falharem e acabar prejudicando todo o resto.
A segunda tentativa obteve sucesso principalmente porque foi executado por
uma empresa que conhece o ramo jornalístico e possui em sua equipe pessoas
treinadas para trabalhar no sistema LEGADO_TEL, pois já oferecia suporte para
outro componente de software da empresa J. Papel. Outros fatores que
influenciaram no sucesso deste segundo experimento foram usar técnicas de
reengenharia para obter a documentação do sistema existente, bem como seguir um
modelo de padronização de manutenção.
Mediante estudo de caso é comprovado que a reengenharia aplicada de forma
correta, seguindo todos os processos de forma coerente, as chances de dar certo é
quase 100%. Porém se a mesma for feita “pelas metades” o seu fracasso é imediato,
resultando em um custo ainda maior.
Vale lembrar que quando o software legado possuiu regras específicas de
negócios, que nenhum outro software possui, o melhor caminho é optar pela
reengenharia do mesmo. Porém se existir um software no mercado que supra todos
os requisitos e funcionalidades, implantar um novo software pode ser a melhor
solução viável.
65
5 METODOLOGIA
Até este ponto da obra, foi apresentada a pesquisa bibliográfica, que remete a
uma série de conceitos e perspectivas sobre a reengenharia em software legado.
Deixando bem claro seus processos, vantagens, desvantagens, custos, usabilidade
e definições. O estudo de caso foi muito importante para “ilustrar” tudo dito
anteriormente.
Foi realizada uma pesquisa de campo de cunho qualitativo, com um gerente de
TI que se submeteu a uma entrevista (por troca de e-mails) com perguntas
relacionadas ao processo de reengenharia em software legado em que ele teve
participações. Através da entrevista é perceptível a concepção de vários tópicos
citados no referencial bibliográfico.
A segunda parte da pesquisa de campo foi de cunho quantitativo, a mesma é
um questionário realizado pela empresa de consultoria Deloitte & Touche, voltado
para as 500 maiores empresas portuguesas (segundo a revista Exame), em que visa
mostrar a visão do gerente de TI dentro do diversos “tópicos” da reengenharia em
uma organização.
Ter como parâmetro uma pesquisa qualitativa e outra quantitativa faz enfatizar
o objetivo inicial do trabalho e dar sustância à ideia de que é preciso pensar no
software como um otimizador de processos.
5.1 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 01
Em entrevista com Keiji Sakai, bacharel em ciência da computação, MBA e
certificado em diversas áreas de gerência, que ocupa há dois anos e meio o cargo
de diretor de TI da BM&FBOVESPA, e que já passou por diversas instituições
financeiras, entre elas: ESM Consultoria e Projetos em TI LTDA; JPMorgan Chase;
HSBC Bank Brasil; Deutsche Bank S/A - Banco Alemão; UNIBANCO; Banco Matrix
S/A; Banco de Investimentos Garantia e Banco Norchem, exprime de forma sucinta
suas diversas experiências em projetos de reengenharia em software legado.
Você já teve oportunidade de participar do processo de reengenharia de
software?
SAKAI: Sim, em diversas instituições financeiras.
66
Se sim, discorra sobre os principais pontos. Levando em consideração
adaptação dos usuários, melhorias, custos, vantagens e desvantagens.
SAKAI: Em primeiro lugar, é importante explicar o que considero reengenharia de
software – na minha visão, reengenharia de software é reconstruir uma aplicação ou
parte dela, corrigindo defeitos existentes ou saneando códigos antigos, ou ainda
renovando componentes para a plena utilização dos melhores recursos de software
e hardware existentes.
Neste sentido, em reengenharias de software onde não ocorreram grandes
mudanças de interação aos usuários, mas trouxeram claramente vantagens, seja na
correção ou na melhoria de performance, a recepção dos mesmos foi sempre muito
positiva. Naquelas onde a interação dos usuários com a aplicação teve alteração,
principalmente devido a grandes rupturas tecnológicas (mainframe para micro
informática, plataforma DOS para Windows, desktops para tablets), as primeiras
movimentação provocaram resistência dos usuários principalmente devido à
mudança da rotina operacional dos mesmos. Com relação a custos, vantagens e
desvantagens, existe uma falsa percepção que a reengenharia seria “mais barata”
do que um novo desenvolvimento – em algumas situações isto não foi verdade, pois
o nível de integração dos legados aliado a complexidade de novas tecnologias
encareceu alguns dos projetos. Em algumas situações, o custo de uma
manutenção corretiva do sistema legado seria muito mais vantajoso que uma ação
de reengenharia de software.
O que levou/leva a empresa a passar pelo processo de reengenharia no
software?
SAKAI: Alguns dos grandes motivadores: estratégia de downsizing da instituição,
custo de manutenção de legados, nível de instabilidade de legados em decorrência
de manutenções e customizações “complementares” e por fim, estratégia de
negócios para lançamento de novas interações entre as aplicações das instituições
e os clientes finais.
Quais são os principais aspectos que um gestor de TI precisa avaliar se
tratando do “software”?
SAKAI: A criticidade da aplicação que precisa ser reescrita precisa ser avaliada –
numa instituição financeira onde algumas aplicações precisam funcionar em regime
67
24 x 07, o risco de instabilidade pode provocar perdas milionárias e fuga de clientes.
Além disto, em ambientes extremamente regulados a consistência das informações
(incluindo eventuais cálculos) são de extrema criticidade. Neste sentido, planos
para garantir a qualidade do sistema devem ser colocados em prática, como por
exemplo, testes regressivos, certificações com o mercado, produção paralela e
simulações dos requisitos não funcionais devem estar no radar do gestor de TI.
Quais são os principais motivos que levam ao “abandono” do software
legado?
SAKAI: Obsolescência aliada a instabilidade e ao alto custo de manutenção. No
caso da obsolescência, o risco operacional em decorrência de descontinuidade de
software, hardware e tecnologia pode obrigar as instituições a partir para uma
estratégia de reengenharia.
No processo de reengenharia o risco de perder funcionalidades do software
legado ainda existe, quais são as medidas para tal acontecimento?
SAKAI: Para evitar este tipo de situação, o mapeamento das funcionalidades é
fundamental. Na inexistência de documentação atualizada, os trabalhos tradicionais
de Analise de Sistemas e Analise de Processos deve fazer parte do projeto.
Você utiliza algum modelo para desenvolvimento do projeto de reengenharia
ou adapta algum modelo?
SAKAI: Sobre metodologia ou modelos, em cada instituição utilizávamos
metodologias e modelos diferentes. O importante tanto na definição dos artefatos
como na metodologia é a de não burocratizar o processo, com controles e
documentações não necessárias.
O processo de reengenharia de software pode ser a “solução” dos problemas
dos softwares legados?
SAKAI: Neste ponto é importante ressaltar que durante muitos anos o mercado de TI
do Brasil estava fechado para provedores estrangeiros (reserva de mercado) e com
isto, o desenvolvimento de soluções domésticas foi amplamente aplicado. Com o
fim da reserva de mercado e a vinda de vários provedores com soluções globais, a
dependência de legados internos diminui. Por exemplo, para uma empresa que na
68
década de 80 decidiu desenvolver um sistema de BackOffice para controlar todo o
seu processo produtivo, eu não partiria para a reengenharia da solução e sim,
buscaria um ERP de mercado.
Para soluções específicas que não são atendidas pelo mercado e que são criticas
para as organizações, a reengenharia é a solução.
Atualmente, reengenharia é a melhor solução para software legado?
SAKAI: A mesma resposta da questão anterior se aplica aqui. Reengenharia
apenas para sistemas críticos que não podem ser substituídos por soluções de
mercado.
Qual é o momento de aplicar a reengenharia no software. Quais aspectos
contribuem para isso?
SAKAI: A reengenharia deve ser aplicada nos momentos em que os software
legados não estão mais aptos a atender as necessidades. Por exemplo, volume
transacional, performance, tecnologia, alterações regulatórias e estratégias de
negócio.
Qual o papel do gerente de TI, na gestão e qualidade do software?
SAKAI: Em algumas organizações, a qualidade do software é de responsabilidade
do gestor de TI junto com um gestor de Qualidade. Mas com relação aos aspectos
técnicos com os requisitos não funcionais, de arquitetura, segurança da informação
e tecnologia adotada, a responsabilidade é principalmente do gestor de TI.
Qual é a visão pós-reengenharia?
SAKAI: Tive boas e más experiências – mas não em decorrência da reengenharia
em si. Os maus resultados foram em decorrência de falhas, seja na especificação
dos requisitos funcionais, seja na construção das soluções.
Os gerentes de TI estão preparados para aceitar o processo de reengenharia?
SAKAI: Um gerente de TI da área de Desenvolvimento tende a adorar um projeto de
reengenharia – gerentes de infraestrutura podem gostar (em situações onde a
reengenharia permitiria uma revisão dos ambientes tecnológicos) ou não (em
69
situações onde a reengenharia altera os procedimentos operacionais e de
produção).
Considerações finais (nesta parte fica livre do entrevistado, ressaltar algum
ponto que não foi citado, contar experiência de vida profissional, dicas, ou
seja, tudo que venha acrescentar ao trabalho).
SAKAI: Um projeto de reengenharia de software não é facilmente aprovado. O
argumento de necessidade para melhoria de ambientes ou mitigação de riscos
operacionais sem a quantificação dos benefícios financeiros não são fortes o
suficiente para que um CIO tome a decisão de aprovar um projeto. Mesmo os
CIOs que patrocinam projetos de reengenharia por conta própria, assumem riscos
que, caso os projetos não sejam extremamente bem sucedidos, colocam sua
credibilidade na instituição em risco. Considerando a “comoditização” cada vez
maior de software, em minha opinião são poucas as reais necessidades de
reengenharia de software nos dias atuais.
A seguir estão os principais pontos que devem ser discutido mediante
entrevista:
Mediante entrevista, é possível perceber que ás vezes a única opção é a
reengenharia, pois a descontinuidade do software e limitações do hardware faz com
que o processo organizacional também não evolua. Contudo, a reengenharia deve
ser aplicada apenas para sistemas críticos que não podem ser substituídos por
soluções de mercado.
Sobre os “custos” é interessante a forma como é colocado, uma vez que os
custos, só serão altos ou baixos dependendo da situação a qual o software se
encontra, porém é bom lembrar que um software que passa por reengenharia, tem
sua performance e funcionalidades melhoradas, com isso, pedidos de manutenção,
serão cada vez menores, e o gasto com o mesmo diminuirá.
Outro ponto interessante da entrevista foi a forma como o software é “inserido”
na organização, sendo instrumento de negócio e de lucro, porém o mau
funcionamento do mesmo irá acarretar problemas em toda a hierarquia da
organização. A partir do momento em que o software legado não atende mais as
necessidades é hora de pensar no que fazer, seja passar por um processo de
reengenharia ou buscar algo novo no mercado.
70
É visível o quanto é difícil e complexo implantar e ter o projeto de reengenharia
aceito, uma vez que ainda existe insegurança nos processos, pois como foi dito, os
processos de reengenharia precisam ser bem feito para dar certo. Existem hoje
diversas ferramentas CASE que agilizam os processos, porém elas não são os
únicos fatores determinantes, uma boa gestão é crucial.
Foram usados dois termos na entrevista que merecem uma definição, para
melhor entendimento da resposta, são eles:
• Downsizing: em português significa “achatamento”, é uma técnica conhecida
em todo o mundo e que visa a eliminação de processos desnecessários que
engessam a empresa e atrapalham a tomada de decisão, com o objetivo de criar
uma organização mais eficiente e enxuta possível.
• Regime 24x07: é uma abreviação que significa "24 horas por dia, 07 dias por
semana", geralmente se referindo a um negócio ou serviço disponível o tempo todo,
sem interrupção.
5.2 COLETA E DISCUSSÃO DOS RESULTADOS - PARTE 02
Apesar de ser um conceito relativamente recente, a reengenharia parece já ter
chegado até nós, ao ponto de já estar a produzir resultados. Assim, e de acordo com
um estudo realizado pela empresa de consultoria Deloitte & Touche (2000), com as
500 maiores empresas Portuguesas (segundo a revista Exame) estas pareciam já
estar a par deste conceito. O questionário está disponível no ANEXO A desta obra.
De acordo com pesquisa 84% dos gerentes de TI sabem ou já ouviram falar
sobre reengenharia, contra 16% que não tinham conhecimento. Como mostra o
gráfico um (1) abaixo:
Gráfico 1 – O que é reengenharia Fonte: Deloitte & Touche
71
Dessas empresas, 43% já tinham implementado projetos de reengenharia e
55% estavam em fase de implementação. Apenas 2% ainda não tinham implantado.
Conforme o gráfico dois (2):
Gráfico 2 – Implementação de projeto Fonte: Deloitte & Touche
Muitos dos programas ditos de reengenharia não são de fato. Este é, aliás, um
dos motivos de insucesso de alguns programas de pseudo reengenharia. Em
relação ao futuro, as perspectivas indicam que 62% das empresas inquiridas
pretendem avançar com novos projetos, contra 38%. Representado no gráfico três
(3) a seguir:
Gráfico 3 – Avanço com novos projetos Fonte: Deloitte & Touche
E destes, que tencionam avançar com novos projetos de reengenharia, a
grande maioria, 88% espera implementá-los no próximo ano. Gráfico quatro (4),
abaixo:
Gráfico 4 - Planejamento de um novo projeto de reengenharia Fonte: Deloitte & Touche
72
Em relação aos motivos que levaram a aplicar a reengenharia, chama atenção
o fato de 35% dos gerentes de TI alegarem “os custos demasiado elevados”, ponto
este tratado na pesquisa bibliográfica, uma vez que manter o software legado é
muito custoso para uma organização. Com 16% segue a “perda de competitividade”
onde um software melhor estruturado, têm uma performance elevada em relação ao
legado. É de suma relevância destacar os 10% na “diminuição de lucros”, na qual
comprova o quanto o legado é importante no que diz respeito a negócios e que o
mesmo acarreta perda de lucro. De acordo com gráfico cinco (5) abaixo:
Gráfico 5 – Motivos da aplicação da reengenharia Fonte: Deloitte & Touche
O nível de satisfação em relação ao pós-reengenharia atinge 68%, não
havendo nenhum registro de caso de grande insatisfação. Conforme gráfico seis (6):
Gráfico 6 – Grau de satisfação Fonte: Deloitte & Touche
De acordo com o gráfico sete (7), 42% dos processos que foram objetos de
reengenharia foram os processos operacionais, seguidos 38% por processos infra
estruturais e 20% toda a organização, o que eleva a preocupação com o legado em
um todo.
73
Gráfico 7 – Processos objetos de reengenharia Fonte: Deloitte & Touche
No gráfico oito (8) foi possível perceber que 36% das empresas implementaram
programas de reengenharia recorrendo apenas a recursos internos. Para além de
que 8% conseguiram o mesmo recorrendo apenas a consultores externos.
Gráfico 8 - A quem foi recorrido para o processo de reengenharia Fonte: Deloitte & Touche
Assim, de acordo com as respostas recebidas nenhuma empresa tenciona usar
apenas os consultores externos em próximos projetos, os seja, pretendem buscar
equipes mistas (88%). Conforme gráfico nove (9):
Gráfico 9 – Planos para recorrer no futuro Fonte: Deloitte & Touche
Relativamente às maiores dificuldades na implementação da reengenharia,
numa escala de 1 a 5, os empresários que participaram do estudo, referiram mais
frequentemente a "resistência à mudança", as "perspectivas irrealistas" e as
"limitações dos sistemas informáticos existentes". A resistência à mudança é um
74
ponto muito questionado, pois o usuário tem muita dificuldade de aceitar o novo,
mesmo este trazendo diversas vantagens perspectiveis ou não para o mesmo.
Gráfico 10 – Dificuldades na implementação da reengenharia Fonte: Deloitte & Touche
É possível concluir, que os gestores portugueses são grandes entusiastas da
reengenharia e que os graus de conhecimento e satisfação são esmagadoramente
positivos.
Não há duvida que seja necessário repensar a forma de funcionamento das
organizações. As constantes mutações a que assistimos obrigam a um novo tipo de
organizações, mais flexíveis, mais ágeis, que respondam de forma mais adequada
às solicitações do mercado.
O processo de reengenharia pode contribuir para isso, contudo é necessário
estarmos conscientes que a reengenharia não resolve todos os problemas, ainda
menos quando é mal interpretada e aplicada.
Muitas empresas prosseguiram o mito da reengenharia através da mera
simplificação de processos ou, na maioria dos casos, de uma automatização dos
processos existentes. Este equívoco provocou, em alguns casos, uma diminuição da
competitividade, uma vez que à maioria destes projetos estiveram associados
grandes investimentos que, ou diminuíram a capacidade financeira das empresas ou
provocaram um acentuado endividamento.
Desta forma, é cada vez mais importante que as empresas concentrem os seus
esforços em processos de mudança que sejam realmente capazes de alcançar o
aumento de produtividade necessário para assegurar a sua sobrevivência.
75
CONCLUSÃO
Mediante estudo é possível concluir que a forma de realizar a reengenharia em
software legado, depende de muitos fatores, relacionados, por exemplo, com a
forma de trabalho da empresa, a origem do software em questão e o
desenvolvimento de tecnologias.
A importância da reengenharia está em possibilitar que todo conhecimento
agregado (funções e procedimentos específicos de caráter particular e único) ao
software legado não seja perdido. Porém se existir algum software no mercado que
faz todas as funções do software legado e com um custo reduzido, a melhor opção
seria sim, implantar este novo software.
Finalizando, é conclusivo que o software quando chega ao seu estado crítico,
precisa de medidas para que o mesmo continue em uso, o papel de um gestor de TI
é buscar pela melhor solução.
76
REFERÊNCIAS
BENNETT, K. H; WARD, M. P. Suporte Automatizado de Manutenção de Software, 1991. ______. Métodos Formais para sistemas legados, 1995. BISBAL, Jesus. Uma visão geral da migração do sistema legado, 1999. BORGES, Rosemary. Sistemas legados, 2007. BRAGA, Jose Luiz; PINTO, Hebert Laroca Mendes. Sistemas legados e novas tecnologias: técnicas de integração e estudo de caso, 2004. BROOKS, F. P. Ensaios sobre Engenharia de Software. 1. ed. MA: Addison-Wesley, 1995. CAGNIN, Maria Istela. Parfaite, uma contribuição para a reengenharia de software baseada em linguagens de padrões e frameworks, 2005. CHIKOFSKY, E. J.; CROSS, J. H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, 1990. COLEMAN, D.; ARNOLD, P. Desenvolvimento Orientado a Objetos: O método de fusão, 1994. CORDEIRO, Edson dos Santos. Introdução a Ciclo de Vida do Software, 2012. DALMASO, Alanderson. Crise do software, 2013. DINIZ, Samuel. O problema do software legado. Disponível em: <http://blogdosamueldiniz.blogspot.com.br/2010/02/o-problema-do-softwarelegado.html>. Acesso em: 19 Fev. 2013. HAMMER, M.; CHAMPY, J. Reengenharia: revolucionando a empresa em função dos clientes, da concorrência e das grandes mudanças da gerencia. Rio de Janeiro: Campus, 1994. HARANDI, M.; NING, J. Q. Knowledge-Based Program Analysis: IEEE Software, 1990. JALOTE, P. Uma abordagem integrada para Engenharia de Software. 3. ed. New York: Springer, 2005. JANONES, Ramos de Sousa. Qualidade de Software: Uma questão de eficiência, 2010. LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution, 1985.
77
LEMOS, Gizelle Sandrini. Padrões de reengenharia auxiliados por diretrizes de qualidade de software, 2003. LOVATTO, Robinson. Estudo de viabilidade sobre a migração de um sistema Oracle forms 6i para um ambiente web, 2012. MARI, Charles Roberto Boeing. Reengenharia de Software: Estudo de Caso em um Sistema de Automação, 2008. MARTINS, Márcia M. G. Gerenciamento de Serviços de TI – Uma Proposta de Integração de Processos de Melhoria e Gestão de Serviços, 2006. MAZZANTI, Eduardo Spolaor. Técnicas de reengenharia de software aplicadas em uma ferramenta de representação 3D da distribuição de cores de imagens digitais, 2008. MECELLA, Massimo. Integração de sistemas de informação legados altamente fragmentados através de modelagem de objetos e em camadas, 1999. MEDEIROS, Teresa Maria Maciel de. Introdução à engenharia de software e à qualidade de software, 2006. MELO, Tiago Eugênio de. Engenharia de Software: conceitos e aplicações, 2007. MILEV, Eliana Domingues da Cruz; ZAMPIROLLI, Francisco de. Revista Interdisciplinar Aplicada: Estudo de Caso em Manutenção de Software, 2004. MONTEIRO, Mario A. Introdução a organização de computadores, 2007. OSBORNE, W. M.; CHIKOFSKY, E. J. Manutenção de software, 1990. PARREIRA, Walteno Martins. Apostila engenharia de software, 2006. PEGO, Paulo Cesar Batista. Critério de Avaliação de sistemas Legados, 2010. PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004. PIEKARSKI, Ana; Reengenharia de software: o que, por que e como. Disponível em: <revistas.unicentro.br/index.php/RECEN/article/download/528/697>. Acesso em: 19 Mai. 2013. PINTO, Herbert Laroca Mendes. Sistemas legados e as novas tecnologias: técnicas de integração e estudo de caso, 2004. PRESSMAN, Roger S. Engenharia de Software. 1. ed. São Paulo: Makron, 1995. ______. ______. 5. ed. Rio de Janeiro: Mc GrawHill, 2002. ______. ______. 6. ed. Rio de Janeiro: McGraw-Hill, 2006.
78
RAMOS, Cristiane Soares; OLIVEIRA, Kathia Marçal de. Conhecendo Sistemas Legados através de Métricas de Software, 2008. SANTOS, Pedro de Alcântara dos. Introdução à engenharia de software, 2005. SILVA, Roberto Andrade de. Migração e Integração de Sistemas Legados, 2005. SOMMERVILLE, Ian. Engenharia de Software. 4. ed. São Paulo: Addison-Wesley, 1992. ______. ______. 6. ed. São Paulo: Addison Wesley, 2003. STEVENS, P.; POOLEY, R. Sistemas de Padrões de Reengenharia, 1998. VASCONCELOS, Aline Pires Vieira de. Uma abordagem de apoio à criação de arquiteturas de referência de domínio baseada na análise de sistemas legados. Rio de Janeiro: UFRJ, 2007. VERZELLO, Robert J. Processamento de dados. São Paulo: McGraw-Hill, 1984. WARREN, Ian. Um método para avaliar Sistemas Legados para a Evolução, 1998. YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Editora Campus, 1990. ZANLORENCI, Edna; Abordagem da Engenharia de Requisitos para Software Legado. Disponível em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>. Acesso em: 27 Ago. 2013.
79
ANEXO A – INSTRUMENTO DE COLETA DE DADOS
80
ANEXO A – INSTRUMENTO DE COLETA DE DADOS
Entrevista elaborada com a finalidade de captar uma visão mais ampla do
processo de reengenharia em software legado, no ponto de vista de um gerente de
TI (tecnologia da informação).
1- Você já teve oportunidade de participar do processo de reengenharia de software? 2- Se sim, discorra sobre os principais pontos. Levando em consideração adaptação dos usuários, melhorias, custos, vantagens e desvantagens. 3- O que levou/leva a empresa a passar pelo processo de reengenharia no software? 4- Quais são os principais aspectos que um gestor de TI precisa avaliar se tratando do “software”? 5- Quais são os principais motivos que levam ao “abandono” do software legado? 6- No processo de reengenharia o risco de perder funcionalidades do software legado ainda existe, quais são as medidas para tal acontecimento? 7- Você utiliza algum modelo para desenvolvimento do projeto de reengenharia ou adapta algum modelo? 8- O processo de reengenharia de software pode ser a “solução” dos problemas dos softwares legados? 9- Atualmente, reengenharia é a melhor solução para software legado? 10- Qual é o momento de aplicar a reengenharia no software. Quais aspectos contribuem para isso? 11- Qual o papel do gerente de TI, na gestão e qualidade do software? 12- Qual é a visão pós-reengenharia? 13- Os gerentes de TI estão preparados para aceitar o processo de reengenharia? 14- Considerações finais (nesta parte fica livre do entrevistado, ressaltar algum ponto que não foi citado, contar experiência de vida profissional, dicas, ou seja, tudo que venha acrescentar ao trabalho).
81
Questionário elaborado pela empresa de consultoria Deloitte & Touche,
direcionado para às 500 maiores empresas Portuguesas (segundo a revista Exame)
com a finalidade de captar dados junto aos gestores de TI sobre as diversas faces
da Reengenharia.
1- Você sabe o que é reengenharia? ( ) Sim ( ) Não 2- Já implementou algum projeto de reengenharia? ( ) Em implementação ( ) Implementados ( ) Não 3- Pretende avançar com novos projetos? ( ) Sim ( ) Não 4- Para quando planeja começar o projeto de reengenharia? ( ) Nos próximos 6 meses ( ) Entre 6 meses a 1 ano ( ) Entre 1 ano a 2 anos 5- O que levou a aplicar a reengenharia? ( ) Redução de quota de mercado ( ) Não cumprimento dos prazos de entrega ( ) Custos demasiado elevados ( ) Fraca qualidade dos produtos/serviços ( ) Fraco serviço aos clientes ( ) Diminuição de lucros ( ) Perda de competitividade ( ) Outras 6- Qual foi o grau de satisfação obtido? ( ) Muito satisfeito ( ) Satisfeito ( ) Insatisfeito ( ) Muito insatisfeito ( ) Ainda a decorrer 7- Quais os processos que foram objeto de reengenharia? ( ) Toda a organização ( ) Processos operacionais ( ) Processos infra estruturais 8- A quem foi recorrido para o processo de reengenharia? ( ) Consultores externos ( ) Recursos internos
82
( ) Equipes mistas 9- A quem tenciona recorrer no futuro? ( ) Equipes mistas ( ) Recursos internos 10- Quais foram as principais barreiras? ( ) Limitação dos sistemas informáticos ( ) Resistência à mudança ( ) Inexistência de equipes de projeto multifuncionais ( ) Inexistência de um líder de projeto ( ) Envolvimento demasiado tardio do pessoal de SI ( ) Qualificações inadequadas da equipe de projeto ( ) Expectativas irrealistas