Post on 04-Aug-2015
description
CENTRO UNIVERSITÁRIO DO ESPÍRITO SANTO – UNESC
LUCIANA PONCHE DIAS
REENGENHARIA EM SOFTWARE LEGADO
COLATINA
2012
LUCIANA PONCHE DIAS
REENGENHARIA EM SOFTWARE LEGADO
Trabalho de Conclusão de Curso apresentado ao Centro Universitário do Espírito Santo – UNESC, sob orientação da Professora Priscila de Almeida Prata, como requisito para a obtenção do Título de Bacharel em Sistema de Informação.
COLATINA
2012
SUMÁRIO
INTRODUÇÃO .................................................................................................... 04
1 PROBLEMA DE PESQUISA E HIPÓTESES .................................................. 05
2 JUSTIFICATIVA ............................................................................................... 06
3 OBJETIVOS ..................................................................................................... 07
3.1 OBJETIVO GERAL ........................................................................................ 07
3.2 OBJETIVOS ESPECÍFICOS .......................................................................... 07
4 REFERENCIAL TEÓRICO ................................................................................ 08
5 PROCEDIMENTOS METODOLÓGICOS ......................................................... 14
6 CRONOGRAMA 777...................................................................................... 15
REFERÊNCIAS .................................................................................................... 16
ANEXO A – INSTRUMENTO DE COLETA DE DADOS 77777777........ 17
INTRODUÇÃO
A variedade de problemas que envolvem manutenção de software cresce
constantemente, sendo que as soluções não acompanham esta evolução. A
reengenharia de software é uma das estratégias de evolução de software. Ocupa-se
de reimplementar sistemas legados, para que sua manutenção seja fácil.
O grande dilema de implantar a reengenharia em software legado é que eles
têm embutidas informações dos negócios e procedimentos, que podem não estar
documentados. O risco de remover e reescrever tais programas são grandes, pois
muitas informações teriam que ser redescobertas por tentativa e erro.
A manutenção de sistemas legados é cada vez mais dispendiosa, e a
reengenharia prolonga o tempo de vida útil do software. A reengenharia é eficaz em
termos de custo quando ele tem alto valor de negócios, mas é dispendioso manter.
A reengenharia melhora a estrutura do sistema, cria uma nova documentação
relacionada e faz com que ela seja de mais fácil compreensão.
Será realizada uma pesquisa bibliográfica baseada em publicações recentes
disponíveis em livros, revistas, etc. Também será realizada uma pesquisa de campo
qualitativa através de entrevista com um gerente de TI explanando as mudanças
após a implementação da reengenharia em software legado.
Dar inicio à pesquisa de reengenharia em software legado é relevante, pois
atualmente muitas empresas ainda mantêm software legado. Colocar em pratica a
reengenharia em um sistema implica examinar e alterar um sistema de software de
forma a reconstituir e reimplementa-lo sob um novo formato.
1 PROBLEMA DE PESQUISA E HIPÓTESES
Porque efetuar a reengenharia em software legado implica tantas barreiras
dentro da empresa e qual a importância da mesma?
• Porque existe o medo tanto do usuário do sistema quanto do gerente de TI
de que com a reengenharia o software não faça as mesmas funções do
antigo.
• Porque os gerentes de TI não têm as competências gerenciais necessárias
para avaliar o custo de manutenção do legado nem para conduzirem um
processo de migração. Empresas com o problema do legado devem
capacitar seus gerentes em reengenharia de software.
• Porque não há conhecimento das novas tecnologias. Estudar sobre novas
linguagens, novos servidores de aplicação e novas arquiteturas é vital para
tomar uma atitude de acabar com o legado. Investir em treinamento do seu
corpo técnico também é importante.
2 JUSTIFICATIVA
Pesquisar sobre reengenharia em software legado é relevante, pois hoje
existem muitas empresas que ainda mantém software legado. Colocar em pratica a
reengenharia em um sistema implica examinar e alterar um sistema de software de
forma a reconstituir e reimplementa-lo sob um novo formato. Significa aprimorar a
documentação, projetar e reestruturar um sistema existente de forma a obter uma
forma mais aceitável do mesmo.
Na área computacional, é de grande importância que o profissional de TI saiba
fazer da reengenharia uma aliada dentro da empresa. Com ela haverá aumento na
manutenibilidade de software, identificação dos candidatos ao reuso, valorização do
sistema que sofre o processo de reengenharia e aprimoramento da gestão de riscos
do projeto.
Reengenharia de software ainda apresenta grandes dificuldades de
implantação, porém o uso dela em software legado trás grandes benefícios para a
empresa, gerentes de TI e para os que manuseiam o software. Um sistema que
tenha sofrido o processo de reengenharia fornece os recursos solicitados pelos
participantes no projeto, ao mesmo tempo em que conserva uma pequena parte da
construção conceitual do sistema legado.
3 OBJETIVO
3.1 OBJETIVO GERAL
Apresentar a importância e eficácia da reengenharia em software legado.
3.2 OBJETIVO ESPECÍFICO
• Conceituar software legado;
• Conceituar reengenharia de software;
• Exemplificar todos os processos;
• Comparar custos, vantagens e desvantagens;
• Distinguir o que é problema e o que é solução;
• Deixar explicito os conceitos e usabilidades.
4 REFERENCIAL TEÓRICO
Ao passar do tempo, não se imaginava que o software se tornaria um elemento
importante para o mundo e teria a capacidade de manipular a informação. Com este
crescimento computacional, dá inicio a criação de sistemas perfeitos e problemas
para quem desenvolve softwares complexos (SOMMERVILLE, 2003).
O software é o conjunto de vários artefatos e não apenas o código fonte. O
software não é um produto acabado, está sempre em mutação, condição esta
originária de mudanças nas regras de negócio das organizações, da necessidade de
melhoria do processo produtivo ou da adequação do produto ou do serviço que
utiliza tecnologia da informação e está disponibilizado para uso (ZANLORENCI,
2009).
A partir do momento em que um software começa a ser utilizado, ele entra em
um estado contínuo de mudança. Mesmo que tenha sido construído aplicando as
melhores técnicas de projeto e codificação existentes, os sistemas vão se tornando
obsoletos em vista das novas tecnologias que são disponibilizadas. Além das
correções de erros, as mudanças mais comuns que os sistemas sofrem são
migrações para novas plataformas, ajustes para mudanças de tecnologia de
hardware ou sistema operacional e extensões em sua funcionalidade para atender
os usuários. Essas mudanças são realizadas sem que haja preocupação com a
arquitetura geral do sistema, produzindo estruturas mal projetadas, documentação
desatualizada, lógica e codificações ruins, sendo esses os dificultadores da
manutenção em um sistema (OSBORNE e CHIKOFSKY, 1990).
Quando o sistema não é fácil de ser mantido sendo, porém, de grande utilidade, ele deve ser reconstruído. Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software. Esse processo é denominado reengenharia de software (PIEKARSKI, 2012).
Reengenharia de software, também chamada renovação ou recuperação de
software, não apenas recupera informações do projeto de um sistema existente,
como também usa estas informações para reconstruir o sistema, procurando
melhorar sua qualidade global e reduzir custos com manutenção (PRADO, 2012).
A reengenharia tem como principal objetivo melhorar um sistema de alguma
maneira, através de alterações significantes que proporcionem melhoria, porém,
sem alterar suas funções. A extração automática da descrição de uma aplicação e
sua implementação em outra linguagem não é considerada, e sim tradução de
código. O processo de reengenharia inclui tradução de código-fonte, engenharia
reversa, melhoria de estrutura de programa, modularização de programa e
reengenharia de dados (NOGUEIRA, 2000).
Existem diferentes tipos de reengenharia: com a troca parcial ou completa da
implementação sem a troca da funcionalidade, em que há mudança do paradigma
de desenvolvimento e/ou da linguagem de implementação, preservando o
funcionamento do sistema; e com troca da funcionalidade, em que se aplica o
processo tradicional de desenvolvimento de software, modificando o funcionamento
do sistema no modelo de análise e implementando-o novamente (PIEKARSKI,
2012).
A reengenharia pode ser dividida em duas fases principais: a engenharia
reversa e a engenharia progressiva, cada uma destas fases pode ser dividida em
uma série de atividades. Percebe-se que existe clara distinção entre o
desenvolvimento de um novo software e reengenharia de software. A distinção está
relacionada ao ponto de partida de cada um dos processos. O desenvolvimento de
um novo software (definido como engenharia progressiva) inicia-se com uma
especificação escrita do software que será construído, enquanto que a reengenharia
inicia-se tomando como base um sistema já desenvolvido. Nota-se, que existe
distinção entre os objetivos da reengenharia e os da engenharia reversa. O objetivo
da engenharia reversa é derivar o projeto ou especificação de um sistema, partindo-
se de seu código fonte. O objetivo da reengenharia é produzir um sistema novo com
maior facilidade de manutenção. A engenharia reversa é usada como parte do
processo de reengenharia, pois fornece o entendimento do sistema a ser
reconstruído (SOMMERVILLE, 2003).
Para melhorias relacionadas à reengenharia, podem-se estabelecer três
categorias, que são: reengenharia de processos administrativos (direcionada para
alterações potenciais em todos os negócios ou processos organizacionais);
reengenharia de processos produtivos (consiste em modificar qualquer ciclo de
processos padrão, que esteja em uso em uma dada organização, afim de melhora);
reengenharia de software ou produtos (captura e modificação de mecanismos
internos ou funcionalidade de um sistema existente ou produto, visando reconstituí-
lo em uma nova forma e com novas características, frequentemente para tomar
vantagem das novas e emergentes tecnologias, mas sem grandes alterações na
funcionalidade e propósito inerentes ao sistema (SOMMERVILLE, 2003).
Um processo de reengenharia tem como entrada um programa legado e a
saída é uma versão estruturada e modularizada do mesmo programa. Ao mesmo
tempo em que ocorre a reengenharia do programa, os dados do sistema também
podem passar por reengenharia (ZANLORENCI, 2009).
A reengenharia de dados é o processo de analisar e reorganizar estruturas de
dados e, eventualmente, os valores dos dados de um programa, com o objetivo de
torná-lo mais compreensível. Em princípio, a reengenharia de dados não deverá ser
necessária, se a funcionalidade do sistema permanecer inalterada. Na prática, há
uma série de razões pelas quais é preciso modificar os dados, como também os
programas, em um sistema legado (SOMMERVILLE, 2003).
A reengenharia ocupa-se de reimplementar sistemas legados, para que sua
manutenção seja fácil. Software legado pode ser definido como aquele que executa
tarefas úteis para a organização, mas que foi desenvolvido utilizando-se técnicas
atualmente consideradas obsoletas. Logo, nem todo software antigo é legado. A
palavra legado, neste caso, traz um sentido pejorativo, similar ao adjetivo obsoleto.
Em outras palavras, software legado é um software antigo que, apesar de ainda ser
utilizado, foi desenvolvido sem preocupação com as boas práticas de
desenvolvimento vigentes e, às vezes, utilizando uma plataforma já descontinuada
(WARD e BENNETT, 1995).
Os três grandes problemas do software legado são: Primeiramente a sua
incompatibilidade com plataformas operacionais mais recentes, mesmo que exista a
virtualização a demanda de tempo é maior para executar uma dada tarefa. O
segundo problema é o no seu desenvolvimento uma vez que o legado na maioria
das vezes não possui documentação, sua arquitetura não é modularizada e
linguagem de programação ultrapassada. O terceiro problema está na usabilidade
do software, em geral o legado foi desenvolvido em uma plataforma que impede ou
inviabiliza a utilização de interfaces mais evoluídas (DINIZ, 2012).
Existe um grande dilema na decisão sobre o futuro de software legado. Ao mesmo tempo em que ele traz incorporado o acúmulo de anos de experiência e refinamento, traz também todos os vícios e defeitos vigentes na época de seu desenvolvimento (BENNETT, 1995).
Há um risco significativo de negócio em simplesmente descartar sistemas
legados e substituí-los por um sistema que foi desenvolvido utilizando uma
tecnologia moderna, pois raramente existe uma especificação completa do sistema
legado. Se existir uma especificação, é pouco provável que ela incorpore todas as
mudanças que foram feitas no sistema. Os processos corporativos e o modo como
os sistemas legados operam estão sempre intrinsecamente entrelaçados.
Importantes regras corporativas podem estar inseridas no software e podem não
estar documentadas em nenhum outro lugar. O desenvolvimento de um software
novo é arriscado, uma vez que podem ocorrer problemas inesperados com um novo
sistema (SOMMERVILLE, 2003).
O sistema deve mudar para permanecer útil, no entanto, alterar um sistema
legado é muitas vezes dispendioso. Pois, diferentes partes do sistema foram
implementadas por diferentes equipes, portanto, não há um estilo de programação
consistente. O sistema pode utilizar uma linguagem de programação obsoleta.
Frequentemente, a documentação do sistema é inadequada e desatualizada. Em
geral, muitos anos de manutenção podem ter corrompido a estrutura do sistema. O
sistema pode ter sido otimizado para melhorar a utilização de espaço ou a
velocidade de execução, em vez de ter sido escrito para facilitar a compreensão. Os
dados processados pelo sistema podem estar armazenados em diferentes arquivos,
que podem ter estruturas incompatíveis (SOMMERVILLE, 2003).
Muitos programas legados são críticos para os negócios das organizações que
os possuem. Eles têm embutidas informações dos negócios e procedimentos, que
podem não estar documentados. O risco de remover e reescrever tais programas
são grandes, pois muita informação teria que ser redescoberta por tentativa e erro.
Consequentemente, as organizações, não ”aposentam” seus sistemas legados,
preferindo mantê-los em operação, com adaptações às novas necessidades.
(LEHMAN, 1980).
Praticamente todos os sistemas legados utilizados foram projetados antes do
desenvolvimento orientado a objetos ser utilizado. Em vez de serem organizados
com um conjunto de objetos interativos, esses sistemas são projetados utilizando
uma estratégia de projeto orientado a funções. Centenas de programas de
aplicações foram desenvolvidos utilizando-se esses métodos e as ferramentas
CASE associadas (SOMMERVILLE, 2003).
Como a reconstrução manual de sistemas legados é um processo lento e
trabalhoso, pesquisas estão sendo direcionadas para a utilização de tecnologias de
sistemas transformacionais na área de reengenharia de software. Um sistema
transformacional que vem sendo utilizado nesta área é o Draco-PUC. O Draco-PUC
implementa as ideias de transformação orientada a domínios (PRADO, 2012).
Outra técnica usada na estratégia de reengenharia é a abordagem Fusion/RE
que faz a recuperação do projeto atual do sistema legado. A abordagem Fusion/RE
apresenta técnicas para recuperar sistemas legados utilizando o paradigma da
orientação a objetos, sem que os mesmos tenham sidos desenvolvidos com essa
tecnologia. Esta abordagem tem como objetivo recuperar informações e gerar os
mesmos modelos propostos para facilitar a compreensão do sistema que está sendo
analisado. Após a geração dos modelos, estes são utilizados para orientar o
engenheiro de software no processo de organização do código, dando a ele
características de orientação a objetos. O processo de organização de código é
denominado segmentação e o seu resultado, o sistema já organizado, é denominado
sistema segmentado (PRADO, 2012).
A tendência de reengenharia dos processos das empresas são influenciados
por fatores tais como a necessidade de melhoria da qualidade dos serviços e
produtos oferecidos, a compressão das margens de lucro, a redução do ciclo de vida
dos produtos, a diminuição da interferência dos governos e dos subsídios, a
explosão tecnológica, o rápido crescimento do conhecimento humano, a maturidade
dos mercados de consumo e a globalização da economia (NOGUEIRA, 2000).
A complexidade e tamanho dos programas legados têm influência direta no
custo de manutenção dos mesmos. Pesquisas revelam que mais de 50% do custo
de um produto de software está relacionado com as atividades de manutenção,
havendo casos de este percentual chegar até a 85% (YOURDON, 1990).
Em alguns negócios, estima-se que 80% de todos os gastos com software são
consumidos pelas manutenções e evoluções dos sistemas. O número de sistemas
que precisa ser modificado está aumentando gradualmente. Existe fila de espera
para pedidos de manutenção. Isto significa que, algumas vezes, é impossível para
as organizações investirem em novos sistemas para melhorar a eficiência
organizacional (YOURDON, 1990).
A estrutura de controle dos sistemas legados é complexa, com muitas
ramificações incondicionais e a lógica de controle não é intuitiva. Essa estrutura
pode ser afetada por manutenções regulares, tornando alguns códigos inatingíveis.
O programa pode ser reestruturado automaticamente para eliminar declarações
incondicionais. Condições complexas podem ser simplificadas, como parte do
processo de reestruturação de programa (NOGUEIRA, 2000).
A questão é que se continuarem utilizando os sistemas legados e fazendo
alterações, seus custos aumentarão. Se decidirem substituir seus sistemas legados
por novos sistemas, isso será dispendioso. Muitas empresas estão examinando
técnicas de engenharia de software que ampliem o tempo de duração dos sistemas
legados e que reduzam os custos de manter esses sistemas em uso, como a
evolução de produtos de software e a reengenharia de software (SOMMERVILLE,
2003).
5 PROCEDIMENTOS METODOLÓGICOS
Será realizada uma pesquisa bibliográfica baseada em publicações recentes
disponíveis em livros, revistas e em sites confiáveis, buscando informações que
darão sustentação ao trabalho.
Também será realizada uma pesquisa de campo qualitativa através de
entrevista com um gerente de TI explicitando as mudanças drásticas na empresa
depois de executado a reengenharia em software legado. A entrevista servirá como
ponto crucial do trabalho, uma vez que estará mostrando que é possível fazer a
reengenharia em um sistema em uso, a melhoria da mesma tanto para os negócios
como para quem utiliza a ferramenta e os custos.
6 CRONOGRAMA
No quadro abaixo está representada a escala de tempo que será utilizada para
elaboração do projeto de pesquisa e de todas as fases que serão realizadas até a
entrega da Monografia.
2012 2013
FASES A S O N D J F M A M J J A S O
Escolha e delimitação do tema
Revisão da literatura para o projeto
Elaboração do projeto de pesquisa
Entrega do projeto de pesquisa
Estruturação da Monografia
Elaboração dos elementos textuais
Coleta e Análise de Dados
Discussão dos Resultados
Conclusão e Introdução
Resumo
Ajustes finais de Formatação
Entrega da Monograifa
REFERÊNCIAS
DINIZ, Samuel; O problema do software legado. Disponível em: <http://blogdosamueldiniz.blogspot.com.br/2010/02/o-problema-do-software-legado.html>. Acesso em: 19 Out. 2012. LEHMAN, M. M. Programs, Life-Cycles, and the Laws of program Evolution, 1980, 1060-1076 p. NOGUEIRA, Marcelo; Reengenharia de Software. Disponível em: <http://www.noginfo.com.br/arquivos/CC_ESOF_II_10.pdf>. Acesso em: 23 Out. 2012. OSBORNE,W.M.; CHIKOFSKY, E.J. Fitting Pieces to the Maintenance Puzzle. IEEE Software, 1990, 11 p. PIEKARSKI, Ana; Reengenharia de software: o que, por que e como. Disponível em: < revistas.unicentro.br/index.php/RECEN/article/download/528/697>. Acesso em: 19 Out. 2012. PRADO, Antônio. Reengenharia de software para plataformas distribuídas orientadas a objeto. Disponível em: <http://www.inf.ufsc.br/sbes99/anais/SBES-Completo/26.pdf>. Acesso em: 25 Out. 2012. SOMMERVILLE, I. Engenharia de software. 6. ed., São Paulo: Addison Wesley, 2003, 592p. ZANLORENCI, Edna; Abordagem da Engenharia de Requisitos para Software Legado. Disponível em: <wer.inf.pucrio.br/WERpapers/artigos/.../Ednazanloren.pdf>. Acesso em: 27 Out. 2012. WARD, M. P.; BENNETT, K. H. Formal Methods for Legacy Systems. Journal of Software Maintenance: Research and Practice, 1995, 203 – 219 p. YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Editora Campus, 1990.
ANEXO A – INSTRUMENTO DE COLETA DE DADOS
Questionário elaborado com a finalidade de captar uma visão mais ampla das
funcionalidades da reengenharia em software legado.
01 - O que levou a empresa executar a reengenharia no software?
02- Quais as principais preocupações imediatas?
03- Alguma funcionalidade do legado foi perdida? Discorra sobre o assunto.
04- O que mudou após a reengenharia?
05- Houve aversão de funcionários/usuários?
06- Em relação ao custo, diminuiu? Discorra sobre o assunto.
07- Que papel o gerente de TI tem nessas mudanças?
08- Em sua opinião, até onde o software legado pode ser utilizado?
09- Reengenharia é a melhor opção?
10- Considerações finais.