Introdução a Engenharia de Software - garcia.pro.br SW I - parte 7... · •A reengenharia de...

65
Engenharia de Software

Transcript of Introdução a Engenharia de Software - garcia.pro.br SW I - parte 7... · •A reengenharia de...

Engenharia de

Software

Prof.Luís Fernando GARCIA

[email protected]

www.Garcia.pro.br

2

Parte 7

Evolução e Legados

Fontes4

Enfoque Tópicos abordados ...

Assuntos abordados

▸Evolução

▸Manutenção

▸ Legados

6

7

Mudanças Mudanças em Software

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

▸ Ciclo das mudanças / Evolução

13

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

Evolução

▸ Depende de:

▸ Tipo de software

▸ Processos de negócio

▸ Pessoas

▸ Criticidade do software

▸ Ambiente operacional

16

Processo de Evolução - Identificação17

Processo de Evolução - Processo 18

Processo de Evolução - Mudanças19

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 URGENTES21

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

Métodos Ágeis E Evolução de Software

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

Dinâmica da

EvoluçãoLeis de Lehman

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

Leis de Lehman #128

Leis de Lehman #229

ManutençãoDe Software

31

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

TIPOS de Manutenção de Software34

TIPOS de Manutenção de Software35

Ciclos de Manutenção de Software36

Custos Da Manutenção

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

ProblemasNa Manutenção de Software

Problemas41

Problemas42

PrevisãoDa manutenção

44

Reengenharia

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

Reengenharia48

Reengenharia49

Refatoração

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

Legados

53

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

55

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

58

59

Resumindo ...

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

Leitura Sugerida

63

Próxima

Disciplina

65

Engenharia

de

Software II