Engenharia de Software - Evolução de Software

Prévia do material em texto

Evolução de Software
Idarlan Machado
Prof. Vander Alves
Supervisor
 
Introdução
● Alterações nos sistemas são inevitáveis:
● Alterações de leis (influência externa)
● Processo de negócio do cliente muda (interna)
● Erros tem que ser corrigidos
● Novos equipamentos/software são inseridos na 
infraestrutura do sistema
● Desempenho ou confiabilidade do sistema tem que ser 
melhorada
● Os softwares são ativos/bens da organização – precisam estar 
atualizado
● A maior parte do orçamento de software das grandes 
organizacionais são dedicados para evolução sistemas 
existentes do que construção de novos
Modelo espiral de desenvolvimento e evolução
 
Dinâmica de evolução de 
programas
● Estudos realizados por Lehman e Belady 
(1985), propuserma um conjunto de leis 
(hipóteses, na verdade) relacionais à mudança 
de sistemas.
● Escopo do estudo: grandes sistemas.
● Esse estudo ajuda a evidenciar as 
responsabilidades do engenheiro de software 
seja quando irá construir ou evoluir um 
software
 
"Leis"/Hipóteses de Lehman – Para grandes sistemas
Lei Descrição
Mudança contínua Um programa usado em um ambiente real deve mudar 
necessariamente ou torna-se progressivamente menos útil.
Complexidade crescente À medida que um programa muda, sua estrutura tende a se 
tornar mais complexa. Recursos extras devem ser dedicados 
para preservar e simplificar a estrutura.
Evolução de programa de 
grande porte
A evolução de programa é processo auto-regulável. Atributos de 
sistema como tamanho, tempo entre versões e número de erros 
reportados é quase invariável em cada versão de sistema.
Estabilidade 
organizacional
Durante o ciclo de vida de um programa, sua taxa de 
desenvolvimento é quase que constante e independente de 
recursos dedicados ao desenvolvimento do sistema.
Conservação de 
familiaridade
Durante o ciclo de vida de um sistema, mudanças incrementais 
em cada versão são quase constantes
Crescimento contínuo A qualidade dos sistemas entrará em declínio a menos que eles 
sejam adaptados a mudanças em seus ambientes operacionais.
Qualidade em declínio A qualidade dos sistema entrará em declínio a menos que eles 
sejam adaptados a mudanças em seus ambientes operacionais.
Sistema de feedback Os processos de evolução incorporam sistemas de feedback 
com vários agentes e loops e você deve tratá-los como 
sistemas de feedback para conseguir aprimoramentos 
significativos de produto.
 
Manutenção de software
● É a atividade de alterar o sistema após ter sido 
disponibilizado para uso
● Tipos de manutenção de software:
1) Para reparo de defeitos (corretiva)
2) Para adaptar o software a um ambiente 
operacional diferente (adaptativa)
3) Para adicionar funcionalidades ou modificá-la 
(evolutiva)
Distribuição de esforços de manutenção
Custos de desenvolvimento e de manutenção
 
Fatores que influenciam o maior 
gasto em manutenção do software
● Estabilidade da equipe
● Nova equipe assume após software construído
● Responsabilidade contratual
● Empresa 1 – contratada para desenvolver (não fará 
esforços para manutenibilidade)
● Empresa 2 – para manutenção
● Habilidade do pessoal
● Geralmente, profissionais menos experientes são alocados 
para manutenção
● Idade e estrutura do programa
● Degradação devido às manutenções = aumento da 
complexidade
 
Previsão de Manutenção
● Ter mapeado/documentado o que é hard 
(frozen spots) e soft (hot spots) de ser 
modificado
● Prever quais os custos disso durante o ciclo de 
vida do software
Previsão de manutenção
 
Processo de Evolução
● Depende do processo de engenharia de 
software adotado em cada organização
● Grandes empresas = processos mais rigorosos 
(maior número de artefatos de requisitos, de 
arquiterura, etc)
● Pequenas e médias empresas = processos menos 
rigosos
● Mais em geral segue o ciclo ilustrado a seguir
Processo de identificação de mudança e evolução
Processo de evolução de software
Implementação de mudança
 
Reengenharia de Sistemas
● Está relacionada a reimplementação de 
sistemas legados para torná-los mais fáceis de 
manter. Pode envolver:
● Nova documentação
● Organização e reestruturação do sistema
● Conversão do sistema em linguagem mais 
moderna
● Modificação da estrutura de dados e seus valores
Processo de Reparo de emergência
Processo de reengenharia
Abordagens de reengenharia
 
Evolução de Sistemas Legados
Como os sistemas legados são ativos da organização 
e são complexos, definir a estratégia mais apropriada 
para a organização quanto às fases de 
desenvolvimento e evolução é fundamental. Quatro 
opções de estratégia:
1) Descartar o sistema completamente
2) Deixar o sistema sem alterações e continuar 
com a manutenção regular
3) Reengenharia do sistema para aprimorar sua 
facilidade de manutenção
4) Substituir todo ou parte do sistema por um novo 
sistema
Avaliação de sistemas legados
Fatores usados na avaliação de ambientes/mercado
Fatores Questões
Estabilidade do 
fornecedor
O fornecedor ainda existe? O fornecedor é financeiramente estável e é 
provável que continue a existir? Se o fornecedor não estiver mais atuando no 
mercado, alguém mais mantém os sistemas?
Taxa de falhas O hardware tem alta taxa de falhas relatadas? O software de apoio “trava” ou 
força o reinício do sistema?
Idade Qual é idade do hardware e do software? Quanto mais antigo o hardware e 
software de apoio, mais obsoletos eles serão. Eles podem ainda funcionar 
corretamente, mas pode haver benefícios econômicos e de mercado em 
migrar para sistemas mais modernos.
Desempenho O desempenho do sistema é adequado? Os problemas de desempenho têm 
efeito significativo sobre os usuários do sistema?
Requisitos de apoio Qual apoio local é exigido pelo hardware e pelo software? Se houver altos 
custos associados a esse apoio, pode valer a pena considerar a substituição 
do sistema.
Custos de 
manutenção
Quais são os custos de manutenção de hardware e de licenças de software de 
apoio? Hardwares mais antigos podem ter custos de manutenção maiores do 
que de sistemas modernos. O software de apoio pode ter altos custos anuais 
de licença.
Interoperabilidade Existem problemas de interface do sistema com outros sistemas? Os 
compiladores podem, por exemplo, ser usados com versões atuais do sistema 
operacional? É necessária a emulação de hardware?
Fatores usados na avaliação de aplicações – AVALIAR QUALIDADE TÉCNICA
Fatores Questões
Facilidade de 
compreensão
Qual é a dificuldade para compreender o código-fonte do sistema atual? 
Qual é complexidade das estruturas de controle usadas? As variáveis tem 
nomes significativos que refletem suas funções?
Documentação Qual documentação de sistema está disponível? A documentação é 
completa, consistente e atualizada?
Dados Existe um modelo de dados explícito para o sistema? Até que ponto os 
dados são duplicados nos arquivos? Os dados usados pelo sistema estão 
atualizados e consistentes?
Desempenho O desempenho do sistema é adequado? Os problemas de desempenho 
têm efeito significativo sobre os usuários do sistema?
Linguagem de 
programação
Os compiladores modernos estão disponíveis para a linguagem de 
programação usada para desenvolver o sistema? A linguagem de 
programação ainda é usada no desenvolvimento do sistema?
Gerenciamento de 
configuração
Todas as versões de todas as partes do sistema são gerenciadas por um 
sistema de gerenciamento de configurações? Existe um descrição 
explícita das versões de componentes usadas no sistema atual?
Dados de teste Existem dados de teste para o sistema? Existe um registro de teste de 
regressão realizados quando novas características forem acrescentadasao sistema?
Habilidades pessoais Existem pessoas disponíveis que tenham as habilidades para manter a 
aplicação? Existe somente um número limitado de pessoas que 
compreendem o sistema?
	Slide 1
	Slide 2
	Figure 9.1 A spiral model of development and evolution
	Slide 4
	Slide 5
	Slide 6
	Figure 9.8 Maintenance effort distribution
	Figure 9.9 Development and maintenance costs
	Slide 9
	Slide 10
	Figure 9.10 Maintenance prediction
	Slide 12
	Figure 9.3 Change identification and evolution processes
	Figure 9.4 The software evolution process
	Figure 9.5 Change implementation
	Slide 16
	Figure 9.6 The emergency repair process
	Figure 9.11 The reengineering process
	Figure 9.12 Reengineering approaches
	Slide 20
	Figure 9.13 An example of a legacy system assessment
	Figure 9.14 Factors used in environment assessment
	Figure 9.15 Factors used in application assessment