Tipos de sistemas de Lehman Sistemas S: formalmente definidos e derivados de uma especificação Sistemas P: requisitos baseados em uma solução aproximada que seja prática de construir e utilizar Sistemas E: embutido no mundo real e se modifica à medida que o mundo muda Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Evolução versus declínio do sistema O custo de manutenção é muito alto? A confiabilidade do sistema é inaceitável? O sistema não pode mais se adaptar a mudanças adicionais dentro de um período de tempo razoável? O desempenho do sistema ainda está fora das restrições prescritas? As funções do sistema têm utilidade limitada? Outros sistemas fazem o mesmo trabalho melhor, mais rápido ou gerando menos custos? O custo de manutenção do hardware é muito alto, a ponto de justificar sua substituição por um hardware mais novo e mais barato? Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Leis da evolução do software Mudança contínua: conduz a menos utilidade Aumento da complexidade: estrutura se deteriora Lei fundamental de evolução do programa: programa obedece estatisticamente a tendências e invariâncias determináveis Conservação da estabilidade organizacional: taxa de atividade global é estatisticamente invariante Conservação da familiaridade: conteúdo publicado é estatisticamente invariante Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Tipos de manutenção Corretiva: mantém o controle sobre as funções do dia-a-dia do sistema Adaptativa: mantém o controle sobre as modificações do sistema Perfectiva: aperfeiçoa as funções aceitáveis já existentes Preventiva: toma medidas preventivas para que o desempenho do sistema não diminua para níveis inaceitáveis Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Responsabilidades da equipe de manutenção Entender o sistema Localizar informações na documentação do sistema Manter a documentação sistema atualizada Ampliar as funções existentes, a fim de incluir novos requisitos ou requisitos modificados Adicionar novas funções ao sistema Descobrir a fonte das falhas ou problemas do sistema Localizar e corrigir defeitos Responder a questões sobre como o sistema funciona Reestruturar o projeto e os componentes do código Reescrever o projeto e os componentes do código Excluir o projeto e os componentes do código que não são mais úteis Gerenciar as mudanças que são feitas no sistema Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Problemas de manutenção Problemas com o pessoal Entendimento limitado Prioridades de gerenciamento Ânimo Problemas técnicos Recursos e paradigmas Dificuldade para a realização de testes Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Fatores que afetam o esforço da manutenção Tipo de aplicação Novidade do sistema Rotatividade e disponibilidade do pessoal de manutenção Duração da vida útil do sistema Dependência de um ambiente que se modifica Característica de hardware Qualidade do projeto Qualidade do código Qualidade da documentação Qualidade dos testes Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Medindo as características da manutenção Registros desejáveis: razão do tempo total de implementação da mudança pelo número total de mudanças implementadas número de problemas não resolvidos tempo gasto em problemas não resolvidos porcentagem de mudanças que introduzem novos defeitos número de componentes modificados para implementar uma mudança Registros necessários: momento em que o problema é relatado qualquer perda de tempo devido à demora por parte do setor administrativo tempo exigido para analisar o problema tempo requerido para especificar quais mudanças devem ser feitas tempo necessário para fazer as mudanças tempo necessário para testar as mudanças tempo necessário para documentar as mudanças Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Exemplo para calcular um número ciclomático Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Índice de nebulosidade Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Grupo de controle de configuração Um problema é identificado por um usuário, cliente ou desenvolvedor, que registra os ‘sintomas’ em um formulário formal de controle de alteração A mudança proposta é relatada ao grupo de controle de configuração O grupo se reúne para discutir o problema: determina a natureza da mudança, quem pagará pelos recursos necessários O grupo discute a provável fonte do problema, o escopo das alterações, o tempo exigido; atribui um nível de prioridade/gravidade, e um analisa é encarregado de fazer as alterações Com uma cópia de teste, o analista faz implementa e realiza os testes para garantir que as alterações funcionam O analista trabalha com o responsável pela biblioteca de programas para controlar a instalação das mudanças no sistema em operação O analista arquiva um relatório das alterações Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Controle de alterações Sincronização: Quando a alteração foi feita? Identificação: Quem fez a alteração? Nomeação: Quais componentes do sistema foram alterados? Autenticação: A alteração foi feita corretamente? Autorização: Quem autorizou que a alteração fosse feita? Acompanhamento: Quem foi notificado sobre a alteração? Cancelamento: Quem pode cancelar o pedido de alteração? Delegação: Quem é responsável pela alteração? Avaliação: Qual é a prioridade da alteração? Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Análise de impacto Produto de trabalho: qualquer artefato do desenvolvimento cuja alteração é significativa Rastreabilidade horizontal: relação dos componentes entre conjuntos de produtos de trabalho Rastreabilidade vertical: relação entre as partes do produto de trabalho Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Ferramentas automatizadas para manutenção Editores de texto Comparadores de arquivos Compiladores e linkers Ferramentas de depuração Geradores de referência cruzada Analisadores estáticos de código Repositórios de gerência de configuração Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Rejuvenescimento de software Redocumentação: análise estática do código-fonte, produzindo informações adicionais Reestruturação: modifica o código, transformando-o de mal estruturado em bem estruturado Engenharia reversa: recria as informações sobre o projeto e a especificação, a partir do código Reengenharia: aplicação da engenharia reversa em um sistema já existente e depois aplica-se a ‘engenharia direta’ para fazer as mudanças na especificação e no projeto que completam o modelo lógico Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11

Redocumentação A saída pode incluir: relações das chamadas dos componentes hierarquias de classe tabelas de interfaces de dados informações dos dicionários de dados tabelas ou diagramas de fluxo de dados tabelas ou diagramas de fluxo de controle pseudocódigo caminhos de testes referências cruzadas dos componentes e das variáveis Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger Capítulo 11