introdução a engenharia de software - garcia.pro.br sw i - parte 7... · •a reengenharia de...
TRANSCRIPT
Mudanças em Software
▸ Mudanças são Inevitáveis
▸ Novos requisitos
▸ Mudanças no ambiente negócios
▸ Erros
▸ Nova infra-estrutura
▸ Problemas de desempenho e confiabilidade
9
Mudanças em Software
▸ Mudanças são Inevitáveis
▸ Chave do sucesso:
▸ Implementar e gerenciar as mudanças em softwares existentes ...
▸ Não postergar ...
▸ Não ignorar ...
10
Mudanças em Software
▸ Importância das mudanças
▸ Ativos Críticos de negócio
▸ Alto valor
▸ Maior parte do orçamento de software é (ou deve ser) para manutenção e não para desenvolvimento
11
Problemas com Mudanças em Software
▸ Raramente existe Documentação Completa▹ Se existe está desatualizada
▸ Processos corporativos e sistemas ENTRELAÇADOS▹ Processos criados A PARTIR do sistema▹ Regras e restrições corporativas somente no sistema
▸ Riscos inerentes ao desenvolvimento de sw
12
Mudanças em Software
Evolução – Em uso operacional e incluindo novos requisitos
Em serviço – Em uso operacional e mudanças são apenas correções de erros e adequação a novos ambientes
Interrupção gradual – Ainda em uso mas sem mudanças ...
14
Evolução
▸ Depende de:
▸ Tipo de software
▸ Processos de negócio
▸ Pessoas
▸ Criticidade do software
▸ Ambiente operacional
16
Processo de Evolução - Mudanças
• Uma diferença fundamental é que a primeira fase deimplementação da mudança pode envolver a compreensão doprograma, especialmente se os desenvolvedores do sistemaoriginal não são responsáveis pela implementação da mudança.
• Durante a fase de compreensão do programa, você precisaentender como o programa está estruturado, como eleimplementa a funcionalidade e como a mudança proposta podeafetar o programa.
20
Mudanças URGENTES
• Mudanças urgentes podem precisar ser implementadas sempassar por todas as fases do processo de engenharia de software.
Se um defeito grave do sistema precisa ser reparado parapermitir a continuidade da operação normal;
Se as mudanças ao ambiente do sistema (por exemplo, umaatualização do sistema operacional) tem efeitos inesperados;
Se houver mudanças de negócios que exigem uma respostamuito rápida (por exemplo, o surgimento de um produtoconcorrente).
22
Mudanças em Métodos Ágeis
• Métodos ágeis são baseados no desenvolvimento incremental,assim, a transição do desenvolvimento para a evolução éimperceptível.
A evolução é simplesmente uma continuação do processo dedesenvolvimento baseada em versões frequentes do sistema.
• Mudanças podem ser expressas como estórias adicionais deusuários.
24
Mudanças são inevitáveis
• Os requisitos do sistema são suscetíveis de mudar enquanto o sistema está sendodesenvolvido, pois o ambiente está mudando.
• Portanto, um sistema entregue não atenderá a seus requisitos!
• Sistemas são fortemente acoplados com seu ambiente.
• Quando um sistema é instalado em um ambiente, ele muda esse ambiente e,portanto, altera os requisitos do sistema.
• Os sistemas devem mudar, caso queiram permanecer úteis em um ambiente.
26
Leis de Lehman
▸ Aplicabilidade comprovada:
▸ Grandes sistemas customizados
▸ Pequenos sistemas ??
▸ Médios sistemas ??
▸ Módulos ??
27
Manutenção de Software
• Modificar um programa depois desse ter sido liberado para uso.
• O termo é usado principalmente para mudar softwarecustomizado.
• Geralmente, a manutenção não envolve mudanças importantespara a arquitetura do sistema.
• As mudanças são implementadas por meio da modificação doscomponentes existentes e pela adição de novos componentes aosistema.
32
TIPOS de Manutenção de Software
• Manutenção para corrigir defeitos de software
Mudar um sistema para corrigir deficiências que nãocorrespondem aos seus requisitos.
• Manutenção para adaptar o software a um ambiente operacionaldiferente.
Mudar um sistema para que ele opere em um ambientediferente (computador, OS, etc.) da sua implementação inicial.
• Manutenção para adicionar ou modificar a funcionalidade dosistema
Modificando o sistema para satisfazer novos requisitos.
33
Custos
• Geralmente, maior do que os custos de desenvolvimento (2 * a100 *, dependendo da aplicação).
• Afetados por fatores técnicos e não técnicos.
• Aumentam na medida em que o software é mantido. Amanutenção corrompe a estrutura do software, dificultandofuturas manutenções.
• Softwares envelhecidos podem ter altos custos de suporte (porexemplo, linguagens, compiladores antigos etc.)
38
Custos – Fatores importantes
• Estabilidade da equipe
Custos de manutenção são reduzidos se a mesma equipe estiver envolvida comeles por algum tempo.
• Responsabilidade contratual
Os desenvolvedores de um sistema podem não ter responsabilidade contratualpara a manutenção, assim não há incentivo para projetar mudanças futuras.
• Qualificações de pessoal
Muitas vezes a equipe de manutenção é inexperiente e tem conhecimentos dodomínio limitados.
• Idade e estrutura do programa
Na medida em que os programas envelhecem, sua estrutura se degrada e tornam-se mais difíceis de entender e mudar.
39
Reengenharia
• A reestruturação ou reescrita de parte ou da totalidade de umsistema legado, sem alterar sua funcionalidade.
• Aplicável em casos em que alguns, mas não todos os subsistemasde um sistema maior exigem manutenção frequente.
• A reengenharia envolve esforços adicionais para torná-los maisfáceis de se manter.
• O sistema pode ser reestruturado e redocumentado.
46
Reengenharia
• Risco reduzido
Existe um alto risco no desenvolvimento de software novo.Pode haver problemas de desenvolvimento, problemas com aequipe e problemas de especificação.
• Custo reduzido
Muitas vezes, o custo da reengenharia é significativamentemenor do que os custos de desenvolvimento de software novo.
47
Refatoração
• A refatoração é o processo de fazer melhorias em um programa paradiminuir a degradação por meio da mudança.
• Você pode pensar na refatoração como "manutenção preventiva", o quereduz os problemas de mudanças futuras.
• A refatoração envolve a modificação de um programa para melhoria dasua estrutura, redução da sua complexidade ou facilitar o entendimento.
• Ao refatorar um programa, você não deve adicionar funcionalidade, massim concentrar-se na melhoria do programa.
51
Estratégias para Legados
• Organizações que dependem de sistemas legados devem escolher umaestratégia para a evolução desses sistemas
Fazer o descarte completo do sistema e modificar os processos denegócio para que esse não seja mais necessário;
Continuar dando suporte para o sistema;
Reestruturar o sistema por meio da reengenharia para melhoria desua manutenabilidade;
Substituir o sistema com um novo sistema.
• A estratégia escolhida deve depender da qualidade do sistema e do seuvalor de negócio.
54
Possíveis sugestões
• Baixa qualidade, baixo valor de negócio
Esses sistemas devem ser descartados.
• Baixa qualidade, alto valor de negócio
Esses fazem uma importante contribuição para os negócios, mas suamanutenção é cara. Deve passar por uma reengenharia ou sersubstituído caso um sistema adequado esteja disponível.
• Alta qualidade, baixo valor de negócio
Substituir com COTS, descartar completamente ou manter.
• Alta qualidade, alto valor de negócio
Continuar em operação com a manutenção normal do sistema.
56
Avaliação de Legados
• A avaliação deve levar em conta diferentes pontos de vista:
Usuários finais do sistema;
Clientes empresariais;
Gerentes de linha;
Gerentes de TI;
Gerentes seniores.
• Entrevistar diferentes stakeholders e coletar os resultadosobtidos.
57
Resumindo ...
• Existem três tipos de manutenção de software, correção de bugs,modificação do software para funcionar em um novo ambiente, eimplementação de requisitos novos ou alterados.
• A reengenharia de software está preocupada com a reestruturação e aredocumentação do software para torná-lo mais fácil de entender emudar.
• Refatoração, fazer pequenas alterações no programa, as quais devempreservar a funcionalidade, é uma forma de manutenção preventiva.
• O valor de negócio de um sistema legado e a qualidade do software deaplicação devem ser avaliadas para ajudar a decidir se o sistema deve sersubstituído, transformado ou mantido.
61