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
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 11
Prentice Hall
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
Prentice Hall
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
Prentice Hall
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
Prentice Hall
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
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
• 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
Capítulo 11
Prentice Hall
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
Prentice Hall
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
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 11
Prentice Hall
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 11
Prentice Hall
Medindo as características da manutenção

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

Registros desejáveis:





Capítulo 11
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
Prentice Hall
Exemplo para calcular um número ciclomático
Scor eboar d: : dr awscor e( i nt n)
{
whi l e( numdi gi t s- - > 0} {
scor e[ numdi gi t s] - >er ase( ) ;
}
/ / bui l d new scor e i n l oop, each t i me updat e posi t i on
numdi gi t s = 0;
/ / i f scor e i s 0, j ust di spl ay “ 0”
i f ( n == 0) {
del et e scor e[ numdi gi t s] ;
scor e[ numdi gi t s] = new Di spl ayabl e( di gi t s[ 0] ) ;
scor e[ numdi gi t s] - >move( Poi nt ( ( 700- numdi gi t s* 18) , 40) ) ;
scor e[ numdi gi t s] - >dr aw( ) ;
numdi gi t s++;
}
whi l e ( n) {
i nt r em = n % 10;
del et e scor e[ numdi gi t s] ;
scor e[ numdi gi t s] = new Di spl ayabl e( di gi t s[ r em] ) ;
scor e[ numdi gi t s] - >move( Poi nt ( 700- numdi gi t s* 18) , 40) ) ;
scor e[ numdi gi t s] - >dr aw( ) ;
n / = 10;
numdi gi t s++;
}
}
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 11
Prentice Hall
Índice de nebulosidade
Engenharia de Software: Teoria e Prática
Shari Lawrence Pfleeger
Capítulo 11
Prentice Hall
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
Prentice Hall
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
Prentice Hall
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
Prentice Hall
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
Prentice Hall
Rejuvenescimento de software




Redocumentação: análise estática do códigofonte, 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
Prentice Hall
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
Prentice Hall