Engenharia de Software - Semana 4

Prévia do material em texto

ENGENHARIA 
DE SOFTWARE
SEMANA 4
SOMMERVILLE – CAPÍTULO 9 – EVOLUÇÃO DE SOFTWARE
O desenvolvimento de software não é interrompido quando o sistema é 
entregue, mas continua por toda a vida útil do sistema justamente para 
que este permaneça útil. 
Mudanças e modificações ocorrem para correção de problemas, 
melhoria do desempenho e para o atendimento de expectativas dos 
usuários. 
Softwares são verdadeiros ativos das empresas, representam altos 
investimentos e a manutenção pode chegar a 2/3 dos custos. Ou seja, 
organizações gastam mais com evolução do que com desenvolvimento. 
EVOLUÇÃO DE SOFTWARE
Desenvolvimento de software brownfield: termo que descreve situações 
nas quais os sistemas de software precisam ser desenvolvidos e 
gerenciados em um ambiente em que dependem de vários outros 
sistemas de software.
Evolução de software raramente acontece de forma isolada.
O alto custo de desenvolvimento resulta em sistemas com vida útil muito 
longa. É comum sistemas militares e de estruturas de grande porte 
serem usados por cerca de 30 anos ou até terem retorno do 
investimento.
EVOLUÇÃO DE SOFTWARE
MODELO EM ESPIRAL
Teste de 
defeito
O modelo ilustra toda a vida 
útil do sistema, em que 
cada etapa da engenharia 
de software é realizada 
após cada release.
Esse modelo implica que 
uma única organização é 
responsável tanto pelo 
desenvolvimento inicial 
como pela evolução.
VIDA ÚTIL DE SOFTWARE
• MANUTENÇÃO - envolve atividades adicionais de processo, como o 
entendimento de programa, além das atividades normais de 
desenvolvimento de software.
• EVOLUÇÃO - fase em que mudanças significativas na arquitetura e 
funcionalidade do software podem ser feitas. O software é usado com 
sucesso até sua estrutura ser degradada e demandar mudanças 
ambientais, como de hardware e sistemas operacionais.
• SERVIÇO - as únicas mudanças feitas são relativamente pequenas e 
essenciais. Durante essa fase, o software ainda é útil, mas é 
considerado como substituível e não recebe novas mudanças.
PROCESSOS DE EVOLUÇÃO
A evolução pode ser informal com conversas entre usuários de 
desenvolvedores ou formal com documentação estruturada produzida 
em cada estágio do processo.
Propostas de mudança no sistema são os acionadores para a evolução.
As propostas de mudança podem vir de 
requisitos já existentes que não tenham sido 
implementados no release de sistema, 
solicitações de novos requisitos, relatórios de 
bugs do sistema apontados pelos stakeholders 
e novas ideias para melhoria do software 
vindas da equipe de desenvolvimento.
PROCESSOS DE EVOLUÇÃO
Etapas da evolução:
1. Solicitação de mudança.
2. Análise do impacto.
3. Planejamento da release.
4. Implementação de mudança.
5. Liberação do sistema
Você pode pensar em implementação de mudanças como uma iteração 
do desenvolvimento, em que as revisões do sistema são projetadas, 
implementadas e testadas.
PROCESSOS DE EVOLUÇÃO
Mudanças urgentes podem surgir por três motivos:
• Defeito grave no sistema que precisa ser corrigido para permitir a 
continuidade do funcionamento normal.
• Alterações no ambiente operacional com efeitos inesperados que 
interrompam o funcionamento normal.
• Mudanças inesperadas no funcionamento do negócio que executa o 
sistema, como o surgimento de novos concorrentes ou a introdução 
de nova legislação que afete o sistema. 
DINÂMICA DA EVOLUÇÃO
O processo de evolução de sistema envolve a compreensão do programa que 
tem de ser mudado e, em seguida, a implementação dessas mudanças
A dinâmica da evolução de programas é o estudo da mudança de sistema.
Estudos realizados sobre a mudança de sistema com intenção de compreender mais 
sobre as características de evolução de software nas décadas de 1970, 1980 e 
1990 por Lehman e Belady resultaram em oito proposições denominadas Leis de 
Lehman.
LEIS DE LEHMAN
1. Mudança contínua - a manutenção de sistema é um processo inevitável.
2. Aumento da complexidade - quando um sistema é alterado, sua estrutura se degrada. A única maneira de 
evitar que isso aconteça é investir em manutenção preventiva.
3. Evolução de programa de grande porte - sistemas de grande porte têm uma dinâmica própria, 
estabelecida em um estágio inicial do processo de desenvolvimento
4. Estabilidade organizacional - a maioria dos grandes projetos de programação trabalha em um estado 
saturado. Ou seja, uma mudança de recursos ou de pessoal tem efeitos imperceptíveis sobre a evolução 
do sistema a longo prazo. 
5. Conservação da familiaridade - preocupação com o aumento das mudanças em cada release de sistema.
6. Crescimento contínuo - A funcionalidade oferecida pelos sistemas tem de aumentar continuamente para 
manter a satisfação do usuário.
7. Declínio de qualidade - A qualidade dos sistemas cairá, a menos que eles sejam modificados para refletir 
mudanças em seu ambiente operacional. 
8. Sistema de feedback - Os processos de evolução incorporam sistemas de feedback multiagentes, 
multiloop, e você deve tratá-los como sistemas de feedback para alcançar significativa melhoria do 
produto.
MANUTENÇÃO DE SOFTWARE
A manutenção de software é o processo geral de mudança em um sistema depois 
que ele é liberado para uso e entregue.
O termo geralmente se aplica ao software customizado em que grupos de 
desenvolvimento separados estão envolvidos antes e depois da liberação.
As alterações feitas no software podem ser simples mudanças para correção de 
erros de codificação, até mudanças mais extensas para correção de erros de 
projeto, ou melhorias significativas para corrigir erros de especificação ou acomodar 
novos requisitos.
Manutenção é uma atividade contínua.
MANUTENÇÃO DE SOFTWARE
Existem três diferentes tipos de manutenção de software:
 1. Correção de defeitos ou corretiva: mudanças para reparo de defeitos do 
software.
 2. Adaptação ambiental ou adaptativa: mudanças para adaptar o software a 
outro ambiente
3. Adição de funcionalidade ou evolutiva: mudanças para adicionar 
funcionalidade ao sistema.
MANUTENÇÃO DE SOFTWARE
A figura ilustra a distribuição dos custos de manutenção. 
Evoluir o sistema para lidar com novos ambientes e novos 
ou alterados requisitos consome mais esforço de 
manutenção e mais custos. 
Geralmente, é mais caro adicionar funcionalidade depois 
que um sistema está em operação do que implementar a 
mesma funcionalidade durante o desenvolvimento 
CUSTO DA MANUTENÇÃO
A manutenção costuma custar 3 vezes mais do que o 
desenvolvimento.
Como alternativa, é válido investir mais em desenvolvimento 
nas etapas iniciais para reduzir custos futuros de manutenção.
MANUTENÇÃO DE SOFTWARE
Prever o número de solicitações de 
mudança para um sistema requer 
uma compreensão do 
relacionamento entre o sistema e 
seu ambiente externo.
 Para avaliar os relacionamentos 
você deve considerar:
• O número e a complexidade das 
interfaces de sistema.
• O número de requisitos 
inerentemente voláteis de 
sistema. 
• Os processos de negócio em que 
o sistema é usado
SOFTWARES LEGADOS
Muitos sistemas legados mais velhos são difíceis de serem compreendidos e mudados.
Os programas podem ter sido otimizados para o desempenho ou uso de espaço à custa de inteligibilidade, ou, 
ao longo do tempo, a estrutura inicial do programa pode ter sido danificada por uma série de mudanças. 
Para fazer com que os sistemas legados de software sejam mais fáceis de serem mantidos, é preciso aplicar 
reengenharia nesses sistemas visando a melhoria de sua estrutura e inteligibilidade.
A reengenharia pode envolver:
• A redocumentação de sistema.
• A refatoração da arquitetura de sistema.
• A mudança de linguagem de programação para uma linguagem moderna.
• E modificações e atualizações da estrutura e dos dados de sistema.
PROCESSO DE REENGENHARIA
As etapas da reengenharia são:
• Tradução de código-fonte.
• Engenharia reversa.
• Melhoria de estrutura de programa.
• Modularização de programa.• Reengenharia de dados.
Os custos aumentam de cima para baixo, de 
modo que a tradução de código-fonte é a opção 
mais barata. A reengenharia como parte da 
migração da arquitetura é a mais cara.
O problema com a reengenharia de software é 
que existem limites práticos para o quanto você 
pode melhorar um sistema por meio da 
reengenharia
MANUTENÇÃO PREVENTIVA
A refatoração é o processo de fazer melhorias em um programa para diminuir 
a degradação gradual resultante das mudanças.
Isso significa modificar um programa para melhorar sua estrutura, para 
reduzir sua complexidade ou para torná-lo mais compreensível. 
Quando você refatorar um programa, não deve adicionar funcionalidade, mas 
concentrar-se na melhoria dele. Portanto, você pode pensar em refatoração 
como uma “manutenção preventiva”, que reduz os problemas de mudança no 
futuro.
MANUTENÇÃO PREVENTIVA
REENGENHARIA REFATORAÇÃO
Ocorre depois que um sistema foi 
mantido por algum tempo e com 
o aumento dos custos de 
manutenção.
Reestruturação e 
redocumentação do software para 
torná-lo mais fácil de se entender 
e mudar
É o processo contínuo de melhoria 
ao longo do processo de 
desenvolvimento e evolução para 
evitar a degradação do código.
Preserva sua funcionalidade, pode 
ser pensada como manutenção 
preventiva
SOFTWARES LEGADOS
Mais e mais empresas estão começando a entender que o processo de 
desenvolvimento de um sistema é um processo integral de ciclo de vida e que 
uma separação artificial entre desenvolvimento de software e manutenção de 
software é inútil.
De uma perspectiva de negócio, você precisa decidir se o negócio 
realmente necessita do sistema. 
De uma perspectiva técnica, você precisa avaliar a qualidade do 
software de aplicação e o apoio de software e hardware do sistema.
SOFTWARES LEGADOS
Manter esses sistemas 
em funcionamento se 
tornará caro com baixo 
retorno. Esses sistemas 
devem ser descartados.
Esses sistemas são 
importantes para o 
negócio, portanto, eles 
não podem ser 
descartados. 
Esses sistemas não 
contribuem muito para o 
negócio, mas seus custos 
de manutenção podem não 
ser altos.
Esses sistemas precisam 
ser mantidos em operação
SOFTWARES LEGADOS
Para avaliar um sistema de software a partir de uma perspectiva técnica, é 
preciso considerar tanto o sistema de aplicação em si, quanto o ambiente 
no qual ele opera.
O ambiente inclui o hardware e todos os softwares de apoio associados 
(compiladores, ambientes de desenvolvimento etc.) necessários para 
manter o sistema.
O ambiente é importante porque muitas mudanças de sistema resultam de 
mudanças no ambiente, como atualizações no hardware ou sistema 
operacional.
	Slide 1: Engenharia de Software
	Slide 2: evolução DE SOFTWARE
	Slide 3: evolução DE SOFTWARE
	Slide 4: MODELO em espiral
	Slide 5: Vida útil de software
	Slide 6: Processos de evolução
	Slide 7: PROCESSOS de evolução
	Slide 8: PROCESSOs de evolução
	Slide 9: Dinâmica da evolução
	Slide 10: Leis de Lehman
	Slide 11: Manutenção de software
	Slide 12: Manutenção de software
	Slide 13: Manutenção de software
	Slide 14: Custo da Manutenção
	Slide 15: Manutenção de software
	Slide 16: softwares legados
	Slide 17: Processo de reengenharia
	Slide 18: Manutenção preventiva
	Slide 19: Manutenção preventiva
	Slide 20: Softwares legados
	Slide 21: Softwares legados
	Slide 22: Softwares legados