Engenharia de Software - Aula 17 - Manutenção e Reengenharia

Prévia do material em texto

Aula de Hoje
• Manutenção e Reengenharia
• Manutenção de software
• Suportabilidade do software
• Reengenharia de software• Reengenharia de software
Exemplo de um processo 
GENÉRICO de Software
Engenharia Engenharia 
de de 
RequisitosRequisitos
Projeto Projeto 
de de 
SoftwareSoftware
Construção Construção 
e e 
TesteTeste
ImplantaçãoImplantação
Depois do software implantado (fase de Implantação)...
O desafio é: 
“Como manter o software em utilização e como fazer as atualizações que vão
surgindo?”
Motivação
Imagine um produto que usou muito
Hardware: livre-se, doe-o, reinvente-o!
Hardware: compre outro!
• Tende a obsolescência
• Problemas com frequência
• Mais tempo para reparar do que o aceitável
•Ação paliativa•Ação paliativa
• Consertá-lo
• Remendá-lo
• Ampliar sua funcionalidade
•Manutenção torna-se cada vez mais difícil
MAS, e se for Software?!?!
Mudanças e Software
• Software deve evoluir com o tempo não importando o 
domínio de aplicação, tamanho ou complexidade desse 
software
• Mudanças direcionam esse processo de evolução (ou • Mudanças direcionam esse processo de evolução (ou 
manutenção)
• Alterações em virtude da correção de erros
• Adaptações a uma nova tecnologia
• Solicitações de novas funções por usuários
• Quando a aplicação é reconstruída para prover benefícios em um 
contexto mais moderno
Manutenção de Software
• Inicia-se quase que imediatamente à entrega do software no 
cliente ☺
• Usuários finais relatam os bugs encontrados
• Alterações, adaptações e novas funções• Alterações, adaptações e novas funções
•Desafio da manutenção de software
• Executar melhorias de maneira planejada, programada e controlada
• Se fila de melhorias cresce, consome mais e mais recursos 
(pessoas, tempo e dinheiro)
Manter X Criar
• Espera-se que o que é visível seja tudo o que há para evoluir 
no software
• No entanto, há uma enorme massa de problemas e custo 
que fica “sob a superfície”que fica “sob a superfície”
• Mudanças são responsáveis por mais de 60% de todo 
esforço gasto numa organização de desenvolvimento de 
software (e a tendência é aumentar) � só 40% para produtos 
novos
• Desses 60% � 20% são para correção de erros e 80% gastos com 
adaptações a mudanças em requisitos, melhorias vindas de 
usuários e prevenções para uso futuro (reengenharia)
Por que tanto esforço?
• Muitos softwares atuais foram feitos há décadas sob uma 
determinada plataforma
• Muitos NÃO usaram as melhores técnicas de projeto e codificação 
conhecidas na época
• Principais preocupações eram o tamanho do programa e o espaço
de armazenamento
• Depois esses softwares foram migrados para novas plataformas de 
hardware e de sistemas operacionais
• Ex: mainframes para PCs em instituições bancárias
Por que tanto esforço?
• Muitos softwares atuais foram feitos há décadas sob uma 
determinada plataforma (continuação...)
• Foram também melhorados para atender as novas necessidades do 
usuário (que pode ter mudado)
• Tudo sem se preocupar com a arquitetura global
• Estruturas mal projetadas e codificadas, de lógica pobre e mal 
documentadas
• Para piorar: mobilidade do pessoal de software
• Pode ser pior: outros terem modificado o software original, sem 
documentar nada e não estarem mais na equipe também (argh!)
Manutenibilidade
• Mudanças em software são inevitáveis
• Mecanismos de avaliação, controle e execução
• Análise e projeto, juntos, conduzem a uma característica importante • Análise e projeto, juntos, conduzem a uma característica importante 
da maioria dos softwares
•Manutenibilidade
• Indicação qualitativa da facilidade de correção, adaptação ou 
melhoria de um software
O que é reengenharia (de software)?
• Reconstruir o software ...
• ... criando um produto com mais (ou as mesmas) funções, melhor 
desempenho e confiabilidade
• ... melhorando a sua capacidade de manutenção
•Quem faz?
• No nível da organização, são especialistas de negócio, em geral, 
empresas de consultoria
• No nível de software, são os engenheiros de software
Por que é importante?
• Vive-se num mundo que muda rapidamente
• Mudam-se as demandas nas regras de negócios e na tecnologia da 
informação
• O software é a realização das regras de negócio e, se essas regras 
mudam, o software deve ser também modificado
• Para maior competitividade e 
eficiência, gerentes trabalham 
para modificar as regras de 
negócio, então o software 
deve acompanhar o ritmo
Reengenharia: visão macro sistêmica
ProcessosProcessos
de de NegócioNegócio
SistemasSistemas
de TIde TI AplicaçõesAplicaçõesReengenhariaReengenharia
Reengenharia de Software
• Cenário nada incomum
• Uma aplicação serviu às necessidades do negócio de uma empresa por 10 
ou 15 anos. Durante esse tempo foi corrigida, adaptada e aperfeiçoada 
muitas vezes. No entanto, boas práticas de engenharia de software foram muitas vezes. No entanto, boas práticas de engenharia de software foram 
negligenciadas em função de diversos fatores. 
• Agora a aplicação está instável. Funciona, mas sempre que uma 
modificação é tentada, efeitos colaterais inesperados e sérios ocorrem. 
Mas, a aplicação precisa continuar a evoluir. O que se deve fazer?
• Software difícil de manter não é um problema novo. A ênfase cada vez 
maior na reengenharia de software tem sido motivada por problemas de 
manutenção de software nos últimos 40 anos ...
Reengenharia de Software
• Leva tempo (anos), tem custo significativo $$$ e absorve 
recursos que poderiam ser utilizados em necessidades mais 
imediatasimediatas
•Conclusão
• Toda organização precisa de uma estratégia para a reengenharia de 
software
•Sugestão
• Um modelo de processo de reengenharia
Modelo de Processo de 
Reengenharia de Software
Engenharia 
avante
Análise do 
inventário
16
Reestruturação
dos dados
Reestruturação
do código
Engenharia 
reversa
Reestruturação
de documentos 2
34
5
1. Análise de Inventário
• Fazer planilha com informações detalhadas e atuais de 
todas as aplicações da organização
• nome da aplicação e ano em que foi originalmente criada
• número de mudanças significativas sofridas e o esforço total para • número de mudanças significativas sofridas e o esforço total para 
realizar essas mudanças
• data da última mudança significativa e o esforço para realizar essa 
última mudança
• sistema(s) onde reside e aplicações com quem têm interface
• Analisar e priorizar para escolher aplicações candidatas à 
reengenharia
• Tamanho, idade, criticalidade para o negócio, etc.
2. Reestruturação de Documentos
• Pouca documentação é marca registrada de muitos
sistemas legados. Mas, há opções sobre o que fazer?
1. Criar documentação consome muito tempo. Se funciona bem, e 
é provável que não passe mais por mudanças, deixe o sistema
como está. Em geral, esta é a abordagem corretacomo está. Em geral, esta é a abordagem correta
2. Documentação deve ser atualizada, mas temos recursos
limitados. Pode não ser necessário redocumentar toda a 
aplicação, mas apenas as partes que estão mudando
3. O sistema é crítico para o negócio e tem que ser totalmente
redocumentado. Mesmo assim, deve-se limitar a documentação
ao mínimo essencial
• Ou seja, crie apenas documentação necessária para
melhorar o entendimento do software, nada mais
3. Engenharia Reversa
• Hardware: desmonte e descubra!
• Software: Processo de análise de programa para representá-
lo em uma abstração mais alta que seu código-fonte
• Processo de recuperação de projeto de dados, arquitetural e • Processo de recuperação de projeto de dados, arquitetural e 
procedimental a partir de código-fonte
• Entender softwares antigos cujos desenvolvedores não mais 
trabalhamna organização: jogos antigos de Atari, SNES, etc.
• Averiguar se o código-fonte de um software não sofreu modificações 
por vírus ou outro tipo de código maléfico
• Pode infringir direitos autorais e de propriedade intelectual de 
fabricantes de software se for para obter acesso a recursos de 
software não oferecidos gratuitamente
• Código-fonte “sujo” pode ser reestruturado para 
que contenha só construções de programação 
estruturada (for, if-then-else, etc.)
• Com código mais fácil de “ler”, pode-se extrair
3. Engenharia Reversa
código “sujo”
reestruturar
código
código limpo Processamento• Com código mais fácil de “ler”, pode-se extrair
informações sobre dados (BD, arquivos), de 
interface com usuário (ações e respostas) e de 
processamento (métodos, parâmetros)
• Refinamento e simplificação são feitos pelo 
engenheiro de software � produzir documentação 
de projeto
extrair
abstrações
refinar
&
simplificar
código limpo
especificação inicial
Processamento
Interface
Banco de
dados
especificação final
4. Reestruturação de Código
• A partir da documentação de projeto oriunda da engenharia reversa, 
deve-se reprojetar e executar um novo projeto que produz a mesma função 
que o programa original, mas com mais qualidade
• Trechos de código de projeto pobre (“emaranhados” de código) são • Trechos de código de projeto pobre (“emaranhados” de código) são 
reprojetadas
• Violações de construções de programação estruturada são registradas e 
o código é então reestruturado (pode ser feito automaticamente)
• Código resultante é revisado e testado para garantir que nenhuma 
anomalia foi introduzida
• Documentação interna do código é atualizada
5. Reestruturação de Dados
• Avaliam-se todas as declarações em linguagem de 
programação que contêm definições de dados, descrições de 
arquivos, entradas e saídas e descrições de interfaces 
(análise de código-fonte)
1. Obter informações sobre fluxos de dados
2. Padronização de registro de dados, como nomes de itens de 
dados, formatos de arquivo, etc.
3. Quando a estrutura de dados é fraca (ex: uso de arquivos em
vez de um banco de dados relacional), os dados passam por
reengenharia
• Modificações nos dados resultarão invariavelmente em
modificações arquiteturais e de código
6. Engenharia Avante
• Também chamada de renovação ou recomposição
• Usa informação de projeto de software existente para alterar, 
reconstituir ou recriar esse sistema em um esforço para 
aperfeiçoar sua qualidade como um todoaperfeiçoar sua qualidade como um todo
• Na maioria dos casos, o software trabalhado por 
reengenharia reimplementa a função do sistema existente e 
também adiciona novas funções e/ou melhora o desempenho
• Arquiteturas cliente-servidor, em camadas e orientadas a objetos
• Remodelagem, aperfeiçoamentos e construção de IGU
(Re)Engenharia de Software
AVISOS
• Próxima aula – dia 27/11/14 � aula sobre Qualidade
• Próxima terça-feira – dia 02/12/14 � 3ª Prova – peso 3
Leitura Recomendada
• Capítulo 29 do livro texto: Pressman,
Roger. Engenharia de Software, 7ed.
McGrawHill, Porto Alegre, RS, 2011.
• Capítulo 9 do livro texto: Sommerville, Ian.
Engenharia de Software, 9ed. Prentice Hall,
São Paulo, SP, 2011.