Tipos de sistemas de Lehman

Apresentação em tema: "Tipos de sistemas de Lehman"— Transcrição da apresentação:

1 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

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

3 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

4 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

5 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

6 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

7 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

8 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

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

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

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

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

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

14 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

15 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

16 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

17 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

18 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

19 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