EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1
Mudança de Software 2
Manutenção de software Mudança de software é inevitável Novos requisitos surgem quando o software é usado; O ambiente de negócio muda; Erros devem ser reparados; Novos computadores e equipamentos são adicionados ao sistema; O desempenho ou a confiabilidade do sistema deve ser melhorada. 3
Estratégias de mudança de software Manutenção de software Mudanças são feitas em resposta a requisitos modificados, mas a estrutura fundamental do SW permanece estável. Transformação de arquitetura A arquitetura do sistema é modificada geralmente de uma centralizada p/ uma distribuída Reengenharia de software Nenhuma funcionalidade é adicionada ao sistema, mas ele é re-estruturado e re-organizado p/ facilitar mudanças futuras 4
O processo de manutenção Pedidos de alterações Análise de impacto Planejamento de release Implementação de mudança Liberação do sistema Reparo de defeitos Adaptação da plataforma Incremento de sistema 5
Pedidos de mudança Implementação de mudança Mudanças propostas Análise de requisitos Validação de requisitos Desenvolvimento do Software 6
Pedidos de mudança Reparação de emergência Pedido de alteração Analisar o códigofonte Modificar o códigofonte Liberar o sistema modificado 7
Dinâmica de evolução de programas Leis de Lehman As leis de Lehman são aplicadas a todos os sistemas enquanto eles evoluem. As leis são derivadas das observações aplicadas a sistemas de larga escala desenvolvidos por grandes organizações. 8
5 Leis de Lehman Mudança contínua. Aumento da complexidade. Evolução de programas de larga escala. Estabilidade organizacional. Conservação da familiaridade. 9
Tipos de Manutenção de Software Manutenção Corretiva - Identificar e corrigir erros. Manutenção Adaptativa - Adaptar o software ao ambiente. Manutenção Perfectiva - Atender pedidos do usuário para modificar funções existentes ou incluir novas funções. Manutenção Preventiva - Melhorar a manutenibilidade ou confiabilidade futuras. 10
Distribuição do esforço de manutenção Reparação de Falhas (17%) Adaptação de SW (18%) Adição ou modificação de funcionalidade (65%) 11
Custos de manutenção Sistema1 Sistema2 0 5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0 4 5 0 5 0 0 $ Custos de desenvolvimento Custos de manutenção 12
Manutenção - Fatores de custos Estabilidade da equipe Responsabilidade contratual Habilidades da equipe Idade e estrutura do programa 13
Pedidos de mudança São feitos pelos utilizadores, clientes ou gerentes. Na prática, alguns pedidos devem ser implementados urgentemente: Reparar falhas Mudanças no ambiente Mudanças urgentes do negócio 14
Previsão de mudança A previsão de mudança preocupa-se em avaliar as partes do sistema que podem causar problemas e ter custos de manutenção altos. A aceitação da mudança depende da facilidade de manutenção dos componentes afetados pela mudança. 15
Previsão de mudança Quais partes do sistema serão mais caras para serem mantidas? Previsão de mudança de sistema Previsão de facilidade de manutenção Previsão de custo de manutenção Quais partes serão afetadas pelos pedidos de mudança? Quantos pedidos de mudança podem ser esperados? Qual será o custo manutenção durante o tempo de vida útil desse sistema? Quais os custos de manutenção desse sistema no próximo ano? 16
Sistemas Legados Antigos sistemas que ainda são essenciais para a empresa. Todos os sistemas de software úteis inevitavelmente são modificados quando as empresas passam por mudanças. 17
Há uma necessidade de converter muitos sistemas legados de uma arquitetura centralizada p/ uma cliente-servidor Razões Sistemas Legados Custos de HW. Expectativas quanto à interface com o usuário Acesso distribuído aos sistemas 18
Risco de substituir um Sistemas Legados Sistemas de legado, raramente, têm uma especificação completa. Os processos corporativos e o modo como os sistemas legados operam estão sempre entrelaçados. 19
Risco de substituir um Sistemas Legados O sistema pode embutir regras corporativas que não estão documentadas formalmente em outro lugar. Desenvolvimento de software novo é arriscado e pode não ter êxito. 20
Risco de substituir um Sistemas Legados Partes diferentes implementadas por diferentes equipes. Linguagem de programação obsoleta. A documentação de sistema está desatualizada. 21
Risco de substituir um Sistemas Legados A estrutura de sistema corrompida por muitos anos de manutenção (utilização de técnicas para economizar espaço ou aumentar a velocidade). Estruturas de arquivo usadas podem ser incompatíveis. 22
Valor de negócios Avaliação dos Sistemas Legados 9 10 6 7 8 1 2 3 4 5 Qualidade de sistema 23
Avaliação dos Sistemas Legados Descartar completamente o sistema. escolhida quando o sistema não estiver prestando uma contribuição efetiva aos processos. Continuar a manter o sistema. sistema é necessário e sem grande número de modificações. Transformar o sistema de alguma maneira para melhorar sua facilidade de manutenção. qualidade do sistema foi degradada por modificações regulares. 24
Valor de negócios Avaliação dos Sistemas Legados 9 reengenharia 10 6 investir 7 8 2 descartar 1 3 5 Manutenção 4 normal Qualidade de sistema 25
Sistemas Legados de Aplicação 26
Sistemas Centrados em Bancos de Dados Programa 1 Programa 2 Programa 3 Programa 4 Sistema de Gerenciamento de banco de dados descreve Modelos de dados lógicos e físicos 27
Estrutura de Sistemas Legados Interface com o usuário serviços Interface com o usuário serviços Banco de dados Banco de dados Modelo ideal Sistema legados reais 28
Distribuição da interface com o usuário A distribuição da interface com o usuário tira vantagem da capacidade de processamento local dos PCs p/ implementar interfaces gráficas Onde há uma separação clara entre a interface e a aplicação então o sistema legado pode ser modificado para distribuir a interface Caso contrário um middleware p/ gerenciamento de tela pode traduzir interfaces textuais p/ gráficas 29
Distribuição de Sistemas Legados Aplicação em operação em clientes PC Serviço de aplicação BD IU Sistema legado middleware Sistema legado Terminais a caractere 30
Modelo de Distribuição em Camadas Apresentação Validação de dados Organização de tela p/ usuário final Verificar entrada/saída de dados Controle de interação Serviços da aplicação Base de dados Gerencia sequência de operação /telas Fornece cálculos básicos Fornece gerenciamento e Armazenamento de dados 31
Opções de Distribuição O modelo de distribuição mais simples é a distribuição da interface do utilizador onde somente a interface é implementada no servidor. A opção mais complexa é onde o servidor provê gestão dos dados e os serviços são implementados no cliente. 32
Spectrum de opções de distribuição Servidor: 1- Controle de interação Validação de dados Serviços Banco de dados 2- Serviços Banco de dados 3- Banco de dados Cliente: 1- Apresentação 2- Apresentação Controle de interação Validação de dados 3- Apresentação Controle de interação Validação de dados Serviços Custo e esforço crescente 33
Manutenção de Código Alienígena Programas com muitos fluxos de controle. Módulos muito grandes. Poucos linhas de comentários significativos. Não existe nenhum outro elemento da configuração de software, além do código. 34
Manutenção de Código Alienígena Nenhum membro do pessoal atual de manutenção trabalhou no desenvolvimento do programa. Nenhuma metodologia de desenvolvimento foi aplicada. 35
Manutenção de Código Alienígena Solução Engenharia Reversa e Reengenharia 36
Engenharia Reversa e Reengenharia ENGENHARIA REVERSA processo de análise de um software, partindo-se inicialmente da implementação para um nível mais alto de abstração REENGENHARIA implica no exame e na alteração do software para reconstruí-lo em uma nova forma. 37
Engenharia Reversa Analisar o software com o objetivo de recuperar o seu projeto e a sua especificação a partir de seu código-fonte. 38
Engenharia Reversa e Reengenharia requisito projeto implementação Eng. progressiva Eng. progressiva Eng. reversa Eng. reversa 39
O processo da Engenharia Reversa Análise automatizada Diagrama de estrutura de programa Sistema a ser reengenheirado Repositório de Informações do Sistema Geração de documentos Diagrama de estrutura de dados Anotação manual Matrizes de rastreamento 40
Reengenharia Reestruturar ou reescrever parte ou todo o sistema legado, sem alterar a sua funcionalidade. Aplicável quando alguns subsistemas de um sistema de grande porte requerem uma manutenção frequente. A reengenharia envolve a adição de esforço de modo a tornar esses sistemas mais fáceis de manter. Os sistemas poderão ser reestruturados e redocumentados. 41
Reengenharia requisito projeto implementação Eng. progressiva Eng. reversa Eng. progressiva Eng. reversa Reengenharia Reengenharia 42
Vantagens da Reengenharia Risco reduzido: Redesenvolvimento de software essencial constitui um risco elevado, devido ao papel crítico do software na organização. Custo reduzido: Algumas estimativas sugerem que o custo de reengenharia é significativamente inferior ao custo de redesenvolvimento do sistema, provavelmente 4 vezes inferior. 43
Distinção entre Reengenharia e o Novo Desenvolvimento de Software Novo sistema Especificação do sistema Projeto e implementação Novo sistema Reengenharia de software Sistema de Soft existente Compreensão e transformação Sistema Alterado (reengenheirado) 44
Processo de Reengenharia Programa original Document. de programa Programa modularizado Dados originais Tradução de Código-fonte Engenharia reversa Modularização de programa Reengenharia de dados Melhoria de estrutura do prog Programa estruturado Dados reengenheirados 45
Reengenharia de Dados Envolve a análise e a reorganização das estruturas de dados (e, por vezes, dos valores dos dados) num programa. Razões para usar a reengenharia de dados: Limpeza de dados; Extensão de dados; Migração de dados. 46
Fatores de Custo de Reengenharia A qualidade do software que deve passar pelo processo de reengenharia Ferramentas disponíveis ao processo de reengenharia A extensão de conversão de dados requerida A disponibilidade de pessoal habilitado. 47
Problemas com a Reestruturação Perda de comentários / Perda de documentação. A reestruturação não ajuda na presença de uma modularização pobre, onde componentes relacionados estão dispersos pelo código A compreensão de programas orientados a dados poderá não ser melhorada através da reestruturação 48