Please enable JavaScript.
Coggle requires JavaScript to display documents.
Evolução de Software
(Cap. 9, Sommerville), Implementação - Coggle Diagram
Evolução de Software
(Cap. 9, Sommerville)
:beginner: SW é caro :arrow_right: será usado enquanto for útil e obter valor do seu uso.
- Para se manter útil, deve sofrer mudanças ao longo de sua vida útil (evolui e adapta-se)
-
erros, novos requisitos, melhor desempenho (outros RNF), nova infraestrutura, novas leis, ambiente de negócios, ... (são pontos de mudança).
- 60%-90% dos custos de SW são em evolução
- Evolução é particularmente importante em contextos de "sistemas de sistemas"
- Modelo espiral (๑) de desenvolvimento e evolução
- Funciona bem para produtos de SW
- Mas não é o modelo usual, podendo ocorrer descontinuidades, onde surge a manutenção de SW
- Modelo Evolução e 'Em Serviço'
-
-
-
Processos de Evolução
- Movido por propostas (solicitações) de mudança.
- Processo envolve avaliaçào do custo e do impacto da mudança
- Quando há diferentes times para desenvolvimento e evolução, o primeiro estágio da evolução requer uma compreensão do programa.
- Problemas:
- equipe que desenvolveu usou abordagem ágil e o time de evolução prefere uma abordagem dirigida a planos - equipe espera documentação?
- vice-versa - equipe inicia evolução definindo "teste automatizado", refatorando código, ...
-
-
Sistemas Legados
- Sistemas antigos que ainda estão em uso e que desepenham papel importante nos processos de negócio
- Linguagens e tecnologias antigas
- Estrutura degradada (por anos de manutenção)
- Podem ser sistemas sociotécnicos amplos envolvendo hardware, software, bibliotecas, SW de apoio e processos de negócio.
elementos de um sistema legado
(não somente um sistema de SW, mas sim um sistema sociotécnico)
-
camadas de um sistema legado
- Idealmente, camadas com encapsulamento*
e interfaces bem definidas, mas, na prática, isso nem sempre acontece*.
- novos recursos podem gerar alterações em camadas mais altas
- Alterações: HW :recycle: SW
- Manter interfaces em HW (e.g., sistemas embarcados) pode ser difícil
-
Substituir sistemas legados pode ser CARO e ARRISCADO
- Raramente tem-se uma especificação completa e atualizada
- Processos de negócio e operação dos sistemas legados fortemente entrelaçadas
- Regras de negócio podem estar incorporadas no SW
- Desenvolver um novo SW é arriscado
Mas manter sistemas legados pode ser oneroso:
- Estilo do programa e convenções de uso incoerentes devido às mudanças realizadas por diferentes pessoas
- Linguagem obsoleta
- Documentação inadequada e obsoleta
- Sistema degrada pelo longo tempo de manutenções
- Otimizações específicas para HW mais antigo
- Dados mantidos em arquivos com estruturas incompatíveis, com duplicação de dados, ou mesmo obsoletos, imprecisos e incompletos.
Gerenciamento de Sistemas Legados
(Necessita de uma avaliação realista do sistema e definição da estratégia mais adequada.)
-
Manutenção de software
É o processo geral de modificar um sistema após a sua entrega, normalmente aplicado ao SW personalizado.
Tipos:
- Reparo de defeitos para corrigir bugs e vulnerabilidades (corretiva)
- + caro: requisitos ... projeto ... codificação - + barato
- Adaptação ao ambiente para adaptar o software a novas plataformas e ambientes (adaptativa)
- mudança no ambiente (HW, SO, SW Apoio)
- Acréscimo de funcionalidade para adicionar novas características e apoiar novos requisitos (perfectiva)
- respostas à mudanças organizacional ou de negócios
Distribuição do esforço de manutenção
- ▄▄▄▄▄▄ 24% - Reparo defeitos
- ▄▄▄▄▄ 19% - Adaptação ambiente
- ▄▄▄▄▄▄▄▄▄▄▄▄▄▄ 58% - Adição/modificação req.
-
Mais caro adicionar características na manutenção do que no desenvolvimento, pois:
1) Um novo time precisa entender o programa que está sendo mantido;
2) Com a separação desenvolvimento-manutenção, não há incentivo para escrever SW de fácil manutenção
3) Manutenção não é uma atividade popular
4) Com o tempo, a estrutura do SW se degrada e fica mais difícil de manter
- 1 a 3 - separação desenvolvimento|manutenção
- 4 - reengenharia, transformações de arquitetura (adaptação ao HW) e refatoração podem ser aplicadas
Previsão de manutenção - dados de processo podem ajudar a prever a manutenibilidade, como as métricas:
- nº de solicitações de manutenção corretiva
- tempo médio para a análise de impacto de um mudança
- tempo médio para implementar uma mudança
- nº de solicitações pendentes
Reengenharia de software
- Sistemas legados difíceis de manter podem sofrer reengenharia com a finalidade de melhorar sua estrutura e sua compreensibibilidade (facilitar a manutenção)
- Pode envolver: (re)documentação do SW, refatoração da arquitetura, tradução para linguagens modernas, modificação/atualização das estruturas e dos valores dos dados
- Reengenharia tem vantagens sobre a substituição (novo desenvolvimento):
- Custos de reengenharia podem variar dependendo do nível de automatização possível durante o processo
- Acontece após algum tempo de manutenção, que fica mais difícil
-
Refatoração
- Melhorias para desacelerar a degradação
- melhorar estrutura, reduzir complexidade, facilitar compreensão
- Não acrescenta/modifica funcionalidades, concentrando-se nas melhorias
- Pode ser encarada como um manutenção preventiva
- Testes de regressão ajudam a reduzir o risco de introduzir erros por causa da refatoração
- Processo contínuo de melhoria durante desenvolvimento e evolução
Maus cheiros (bad smells) em código são oportunidades de refatoração:
- Código duplicado: "mesmo" código em vários lugares
- Métodos longos: melhora como uma série de métodos menores
- Comandos switch (case): implicam em duplicação. Em OO pode-se usar polimorfismo
- Generalidade especulativa: inclusão de generalidades para o caso de serem necessárias no futuro (muitas vezes podem ser removidas)
-
