7. MANUTENÇÃO DE -Prof.

Peter Jandl Jr

SOFTWARE -Engenharia de Software II

-ADS | UNIP
Engenharia de Software

(C) PJandl, 2023. 03/22/2024 2

Incorporados na
ISO9126

(C) PJandl, 2023. 03/22/2024 3

 Conceitos Fundamentais

Categorias de Manutenção

Leis de Lehman
(C) PJandl, 2023. 03/22/2024 4
Manutenção de Software

- Disciplina responsável por lidar com as mudanças relacionados ao software

depois da sua entrega.
Software = código + documentação
- Documentação inclui, minimamente, requisitos, análise, projeto, manuais e outros.
- Segundo o IEEE:
“Manutenção é o ato de manter uma entidade em bom estado de reparo, eficiência
ou validade; para evitar falhas ou declínio”.

(C) PJandl, 2023. 03/22/2024 5

Manutenção::objetivos

O objetivo dos processos de manutenção de sistemas e

software é modificar o produto, depois de liberado, para
corrigir falhas, melhorar desempenho ou outros atributos,
ou ainda adaptar às mudanças do ambiente.

(C) PJandl, 2023. 03/22/2024 6

 Manutenção::objetivos
Por meio da manutenção de software, os produtos de software e sistema
existentes são modificados ou descontinuados (retirados), preservando a
integridade das operações da organização.

(C) PJandl, 2023. 03/22/2024 7

(C) PJandl, 2023. 03/22/2024 8
(C) PJandl, 2023. 03/22/2024 9
Manutenção de Software

- Fase mais problemática do ciclo de vida de um software.

- Pode despender mais de 70% de todo esforço de uma organização.
- Justifica-se devido a necessidade desses sistemas continuar
rodando para operação da organização, de maneira que as
alterações se tornam inevitáveis.

(C) PJandl, 2023. 03/22/2024 10

MANUTENÇÃO
::CUSTOS

Representa de 50% até

90% dos custos de
desenvolvimento.

(C) PJandl, 2023. 03/22/2024 11

Manutenção
::justificativa para demanda de esforço
- Idade média dos sistemas corporativos:
entre 10 e 15 anos
-  Principais interesses:
- desempenho requerido,
- novas necessidades,
- espaço de armazenamento e
- migração para novas plataformas
-  Principais dificuldades
(C) PJandl, 2023. 03/22/2024 12
Manutenção
::justificativa para demanda de esforço
- Idade média dos sistemas corporativos:
entre 10 e 15 anos
-  Principais interesses:
-  Principais dificuldades:
- sistemas mal estruturados, nenhuma preocupação com arquitetura global
- tamanho do programa/código
- código e documentação ruins.
(C) PJandl, 2023. 03/22/2024 13
Manutenção
::componentes de custo
- Tentar entender o que o software faz;
- Interpretar as estruturas de dados, as características de interface e
limites de desempenho;
- Analisar, avaliar, projetar, codificar e testar as modificações.

(C) PJandl, 2023. 03/22/2024 14

Manutenção
::custos não monetários
- Redução da qualidade global do software
- Insatisfação do cliente
- Insatisfação do pessoal de manutenção
- Adiamento de oportunidades de desenvolvimento

(C) PJandl, 2023. 03/22/2024 15

Manutenção::questões clássicas

- É difícil ou impossível traçar a evolução do software em suas

várias versões.
- As alterações não são adequadamente documentadas.
- É difícil ou impossível recuperar o processo de criação do
software.

(C) PJandl, 2023. 03/22/2024 16

Manutenção::questões clássicas

- É muito difícil entender programas de "outras pessoas".

- As “outras pessoas" frequentemente não estão presentes para
explicar.
- A maioria dos softwares não foram projetados para suportar
alterações.
- Manutenção não tem glamour!
(C) PJandl, 2023. 03/22/2024 17
Manutenção::questão chave

A maioria dos problemas com a manutenção do software é,

de fato, causada por deficiências na maneira como o
software foi planejado, projetado e desenvolvido.

De volta ao ponto de
partida!!!

(C) PJandl, 2023. 03/22/2024 18

Manutenibilidade::definição

A manutenibilidade pode ser definida qualitativamente

como a facilidade com que um software pode ser
entendido, corrigido, adaptado e ou melhorado.

(C) PJandl, 2023. 03/22/2024 19

Manutenibilidade

- Dado que a manutenabilidade é uma qualidade relacionada à facilidade

de manutenção de um sistema, é difícil de quantificar, pois
- Apenas alguns aspectos do sistema podem ser medidos, como
complexidade ou portabilidade.
- Não existe fórmula mágica
- Apesar disso, reconhecer as características de um sistema fácil de manter
é importante.
(C) PJandl, 2023. 03/22/2024 20
Manutenabilidade::fatores

- Cuidado inadequado com o projeto, codificação e teste;

- Configuração de software ruim;
- Disponibilidade de pessoal qualificado de software;
- Facilidade de manusear o sistema;
- Uso de linguagens de programação padronizadas;
- Uso de sistemas operacionais padronizados;
(C) PJandl, 2023. 03/22/2024 21
Manutenabilidade::fatores

- Estruturas padronizadas de documentação;

- Disponibilidade de um computador próprio para aas atividades de
manutenção;
- Disponibilidade da pessoa ou grupo que desenvolveu o software; e
- Planejamento para manutenibilidade.
(Fator mais importante que afeta a manutenibilidade!)
(C) PJandl, 2023. 03/22/2024 22
Manutenibilidade::métricas CK
Chidamber-Kemerer específicas para sistemas orientado a
objetos
- Métricas de :
- Profundidade da Herança (DIT: Deep of InheritanceTree)
- Número de Filhos (NOC: Number Of Child)
- Acoplamento entre Objetos (CBO: Coupling Between Objects)
- Falta de Coesão em Métodos (LCOM: Lack Cohesion in Methods)
- Métodos Ponderados por Classes (WMC: Weighted Methods in Classes)
- Resposta para Classe (RFC: Response for a Class)
(C) PJandl, 2023. 03/22/2024 23
Manutenibilidade::métricas Gilb

- Métricas de Tempo de:

- Reconhecimento do problema;
- Demora administrativa;
- Coleta de ferramentas de manutenção;
- Análise do problema;
- Especificação da alteração;
- Correção ou modificação;
- Teste local e global; e
- Revisão da manutenção.
(C) PJandl, 2023. 03/22/2024 24
Manutenção::outros indicadores
TEMPO MÉDIO ENTRE FALHAS (MTBF
– MEDIUM TIME BETWEEN FAILURES)
- Refere-se ao tempo médio entre paradas. Esta
métrica é utilizada para analisar a concepção do
sistema e a segurança de ativos complexos. Baseia-
se na relação entre as horas de funcionamento e o
número de falhas.
- As organizações podem otimizar os seus horários de
Manutenção Preventiva (PM), seguindo
cuidadosamente este indicador-chave (KPI) e as
métricas de desempenho associadas, como o tempo
de funcionamento e o tempo de paradas.
(C) PJandl, 2023.
TEMPO MÉDIO PARA REPARO (MTTR
– MEDIUM TIME THROUGH REPAIR)
- Saber o tempo médio necessário para
diagnosticar e reparar falhas em sistemas é vital
quando se lida com manutenção não planejada.
Esta métrica é responsável pelo tempo
necessário para retomar a operação/produção.
- O MTTR pode ter um impacto significativo nos
resultados operacionais de uma organização e
pode resultar em encomendas ou objetivos
comerciais não cumpridos.
03/22/2024 25
Manutenção::outros indicadores
MANUTENÇÃO PLANEJADA VS.
NÃO PLANEJADA
- A manutenção planejada refere-se a qualquer
atividade de manutenção programada destinada
a reduzir o tempo de parada. A manutenção não
planejada é qualquer tarefa de manutenção
inesperada, frequentemente o resultado de falha
do sistema.
- O acompanhamento da manutenção planejada
vs. não planejada ajuda a medir o sucesso do
sistema e das tarefas de manutenção.
(C) PJandl, 2023.
PORCENTAGEM DE
MANUTENÇÃO PLANEJADA
- Saber que fração de todas as tarefas de
manutenção estão planejadas ajuda a identificar
processos ineficientes. Esta métrica de
manutenção é expressa como a porcentagem do
número total de horas gastas em tarefas planeadas
num período especificado.
- Um valor superior a 90% é considerado
"manutenção de classe mundial", enquanto que
um valor superior a 70% é considerado aceitável.
03/22/2024 26
Desenvolvimento versus Manutenção

- Adicionar uma nova funcionalidade durante o desenvolvimento é

mais fácil que durante a manutenção.
- Manutenção de software deve respeitar certos parâmetros e
restrições existentes.

(C) PJandl, 2023. 03/22/2024 27

Desenvolvimento versus Manutenção

- Exemplo: ao projetar uma nova funcionalidade, o mantenedor

deve investigar o sistema atual para abstrair sua arquitetura e
detalhes de baixo-nível:
- Realizar como a mudança será acomodada;
- Prever o impacto da mudança (efeito cascata);
- Determinar as características necessárias para o trabalho.
(C) PJandl, 2023. 03/22/2024 28
 - Arquitetos e construtores devem tomar cuidado para
não enfraquecer a estrutura existente de uma casa
Desenvolvimento quando adições são realizadas.
- Apesar do custo de um novo cômodo ser mais barato
versus que o custo de uma construção completa, o custo por

Manutenção metro quadrado é muito mais alto.

- Isso ocorre pois é necessário: remoção de paredes,
alteração do encanamento/fiação, cuidados.

(C) PJandl, 2023. 03/22/2024 29

Manutenabilidade::revisões

- A manutenibilidade deve ser considerada em cada nível do

processo de revisão da engenharia de software, ou seja, nas etapas:
- Revisão de Requisitos
- Revisão de Projetos
- Revisão de Código
- Revisão de Teste
(C) PJandl, 2023. 03/22/2024 30
Manutenabilidade
::revisão de requisitos
- Deve observar:
- Áreas de melhoramentos futuros;
- Aspectos de portabilidade do software;
- Interfaces que poderiam impactar a manutenção.

(C) PJandl, 2023. 03/22/2024 31

Manutenabilidade
::revisão de projeto
- Deve avaliar:
- projeto arquitetural;
- projeto procedimental;
- projeto de interfaces e
- projeto de dados
- ...quanto à facilidade de manutenção e à qualidade global.
(C) PJandl, 2023. 03/22/2024 32
Manutenabilidade
::revisão de código
- Deve enfatizar:
- Estilo consistente de codificação
(desejável um manual de estilo de codificação); e
- Documentação interna.

(C) PJandl, 2023. 03/22/2024 33

Manutenabilidade
::revisão de teste
- Deve investigar:
- Cada passo do teste, que pode fornecer indícios sobre as partes
do software que poderiam exigir manutenção preventiva.

(C) PJandl, 2023. 03/22/2024 34

MANUTENÇÃO DE
SOFTWARE::RAZÕES

Quais razões/fatores que levam a

modificação de um software
existente?

(C) PJandl, 2023. 03/22/2024 35

Manutenção de Software::razões
Adicionar
Corrigir defeitos Melhorar design
funcionalidades
Se um sistema é
utilizado, ele nunca Migrar de SO, Adaptar a
Comunicar com
estará finalizado, pois BD, bibliotecas, diferentes
outros sistemas
etc hardware
precisa sempre evoluir
para: Adaptar a leis,
regras de negócio, Refatorar código
etc

(C) PJandl, 2023. 03/22/2024 36

 Conceitos Fundamentais

Categorias de Manutenção

Leis de Lehman
(C) PJandl, 2023. 03/22/2024 37
 Manutenção Manutenção
corretiva preventiva
Manutenção
::categorias

São as razões para as alterações Manutenção

que determinam a categoria de Manutenção
evolutiva ou
manutenção. adaptativa
perfectiva

https://www.computer.org/education/bodies-of-knowledge/software-engineering
(C) PJandl, 2023. 03/22/2024 38
Manutenção::categorias

(C) PJandl, 2023. 03/22/2024 39

Manutenção Corretiva

- Modificações no software para corrigir defeitos existentes nos

requisitos, projeto, código, configurações, etc.
- Devido a sua natureza “ad hoc”, pode gerar outros problemas
como aumento de complexidade e outros efeitos em cascata.

(C) PJandl, 2023. 03/22/2024 40

Manutenção Preventiva
- Modificações no software para prevenir potenciais problemas no futuro.
- Lida com o deterioramento de estruturas, previne falhas e melhora a
manutenabilidade.
- Torna os programas mais fáceis de entender e facilita trabalhos de
manutenção futuros.
- Exemplos: reestruturação, refatoração ou otimização de código;
atualização de documentação; inclusão de alertas de manutenção etc.
(C) PJandl, 2023. 03/22/2024 41
Manutenção Adaptativa
- Adaptações para manter o software usável devido às alterações no ambiente externo.
- É necessária porque o ambiente (plataforma, mercado, competição, legislação) está
em constante evolução, mesmo quando não existem defeitos identificados.
- Exemplos:
- Alteração ou atualização do SO, BD, servidor, compilador, bibliotecas,
frameworks, hardware podem servir para acomodar mudanças no software (embora
requeiram nova homologação).
- Mudanças na legislação (tributos, isenções, incentivos) exigem modificações e
novos testes.

(C) PJandl, 2023. 03/22/2024 42

Manutenção Perfectiva/Evolutiva

- Modificações para fornecer melhorias aos usuários e outros

stakeholders (partes interessadas).
- Expande os requisitos do sistema.
- É frequente quando o software se torna útil efetivamente e os
usuários solicitam melhorias além do escopo inicial que acabam
por constituir novas funcionalidades.
(C) PJandl, 2023. 03/22/2024 43
Manutenção::esforço
Modificação de funcionalidade
Dentre os tipos de
Adaptação ao ambiente
manutenção de externo
software existentes,
temos que aquele que Adaptação de
interfaces
gera o maior esforço
para seu reparo: Correção de
defeitos

(C) PJandl, 2023. 03/22/2024 44

Manutenção::relacionamento
- Em princípio, as atividades de manutenção podem ser categorizadas
individualmente.
- Na prática, as atividades estão interligadas, pois:
- Ao modificar o código devido a uma nova biblioteca (adaptativa), defeitos
podem ser introduzidos. Logo, esses defeitos devem ser corrigidos
(corretiva).
- A introdução de uma nova funcionalidade (evolutiva) pode requerer que
código seja refatorado antes para facilitar sua implementação (preventiva).

(C) PJandl, 2023. 03/22/2024 45

Manutenção::relacionamento

(C) PJandl, 2023. 03/22/2024 46

Manutenção::relacionamento

- Manutenção corretiva e evolutiva são mais visíveis e trazem

valor direto para o usuário, pois corrigem defeitos ou incorporam
melhorias.
- Manutenção preventiva e adaptativa trazem valor indireto para o
usuário, pois são, muitas vezes, invisíveis, dado que usualmente
não modificam as funcionalidades existentes.

(C) PJandl, 2023. 03/22/2024 47

Manutenção
::proporções

(C) PJandl, 2023. 03/22/2024 48

Manutenção::proporções

- Manutenção preventiva usualmente não tem a atenção necessária.

- Investe-se mais em corrigir problemas do que em sua prevenção.
- Sistemas bem projetados acabam por demandar manutenção
evolutiva mais do que aqueles deficientes.

(C) PJandl, 2023. 03/22/2024 49

Manutenção::tarefas

1. Estabelecer uma organização (tarefas e responsáveis) para a manutenção (“de

fato" ou formal).
2. Descrever procedimentos de avaliação e de comunicação.
3. Definir sequências padronizadas de eventos (para os pedidos de manutenção).
4. Estabelecer procedimentos para registrar a história das atividades de
manutenção.
5. Definir critérios de revisão e avaliação.
(C) PJandl, 2023. 03/22/2024 50
Manutenção::tarefas
1. Estabelecer uma organização

(C) PJandl, 2023. 03/22/2024 51

Manutenção
::tarefas
2. Descrever
procedimentos
3. Definir sequências
padronizadas

(C) PJandl, 2023. 03/22/2024 52

Manutenção::tarefas
4.Estabelecer procedimentos para registro das informações
- identificação do programa - nível e identificação da alteração no programa

- número de comandos fonte - número de comandos fonte adicionados por

- linguagem de programação usada alteração no programa

- número de pessoas-horas despendidos na

- data da instalação do programa
manutenção
- número de execuções do programa desde a
- identificação do pedido de manutenção
instalação
- tipo de manutenção
- número de falhas de processamento associadas
ao item anterior - datas de início e fim da manutenção

(C) PJandl, 2023. 03/22/2024 53

Manutenção::tarefas
5. Definir critérios de revisão e avaliação

- Número médio de falhas de processamento por execução do programa

- Pessoas-horas despendido em cada categoria de manutenção
- Número médio de pessoas-horas despendido por comando fonte
adicionado ou deletado devido a manutenção
- Tempo médio de processamento para um pedido de manutenção
- Porcentagem de pedidos de manutenção por tipo
(C) PJandl, 2023. 03/22/2024 54
 Conceitos Fundamentais

Categorias de Manutenção

Leis de Lehman
(C) PJandl, 2023. 03/22/2024 55
 Fonte: M. M. Lehman. Rules and Tools for Software Evolution Planning and
Leis de Lehman

Management. Annals of Software Engineering, 2001.

- O termo manutenção de software data dos anos 1960/1970.
- Durante um período de 20 anos de pesquisas, Lehman propôs um conjunto de Leis
de Evolução, posteriormente conhecido como Leis Lehman.
- As leis de Lehman indicam que todo o software, para se manter relevante, deve
passar por adaptações. Entretanto, com o tempo, essas adaptações tornam o
software mais complexo, tornando a manutenção mais cara e ampliando os lead
times.
- São oito as leis de evolução de Lehman.
(C) PJandl, 2023. 03/22/2024 56
Leis de Lehman
1. Mudança contínua
• Um software deve ser continuamente adaptado, senão torna-se, pouco a pouco, menos satisfatório. A cada
alteração no ambiente em que ele roda, que nele exija melhorias não realizadas, o tornarão
progressivamente menos satisfatório quanto aos seus propósitos.

2. Complexidade crescente
• Se não forem tomadas medidas para reduzir ou manter a complexidade de um software, conforme é
alterado sua complexidade aumenta progressivamente. Deve, então, haver um esforço para reduzir a
complexidade final de um sistema enquanto este recebe alterações.

3. Auto regulação
• A curva pertinente ao processo de evolução de um software, em relação a seus atributos e processos, são
auto reguláveis e próximos a uma curva normal, subindo até um teto, quando começa a diminuir.

(C) PJandl, 2023. 03/22/2024 57

Leis de Lehman
4. Conservação da estabilidade organizacional
• A velocidade de atividade global efetiva de um software em evolução deverá se manter invariável durante
todo o ciclo de vida deste produto. O mix que é levado em consideração para as tomadas de decisão que
levam a evolução de um software tendem a ser constantes.

5. Conservação de familiaridade
• Durante a vida útil de um software em evolução, a taxa de mudanças tende a ser proporcional ao domínio
que a equipe detém. A taxa de evolução de um software está intimamente ligado ao grau de familiaridade
dentre os profissionais que o mantém.

6. Crescimento Contínuo
• Todo software deve ter o conteúdo funcional continuamente ampliado durante seu ciclo de vida
para manter a satisfação dos seus usuários. O projeto inicial não consegue incluir absolutamente todo o
necessário e progressivamente precisará ser aumentado.

(C) PJandl, 2023. 03/22/2024 58

Leis de Lehman
7. Declínio da qualidade
• Os softwares desenvolvidos para resolver problemas do mundo real se
depreciam progressivamente se não receberem as mudanças necessárias para
sua adaptação ao acontecimentos em seu ambiente operacional durante todo o
tempo de seu ciclo de vida útil.

8. Sistema de feedback
• Os processos de manutenção e evolução de um software refletem sistemas de
feedback em múltiplos níveis, retornos e agentes e devem ser assim tratados
para manter-se significativos.

(C) PJandl, 2023. 03/22/2024 59

CONCLUSÕES

(C) PJandl, 2023. 03/22/2024 60

Conclusões
- O desenvolvimento de software requer considerar a manutenção
como atividade essencial.
- A implementação de um processo de manutenção de
sistema/software é considerada com sucesso se:
1. Foi desenvolvida uma estratégia de manutenção para gerenciar
modificações, migração e aposentadoria dos produtos.
2. São identificados os impactos das alterações no sistema existente.

(C) PJandl, 2023. 03/22/2024 61

Conclusões
3. Documentação afetada é atualizada.
4. Os produtos modificados são desenvolvidos com testes que
demonstram que os requisitos não estão comprometidos.
5. Os upgrades dos produtos são migrados para o ambiente do cliente.
6. Os produtos são retirados de uso de maneira controlada, de modo a
minimizar o distúrbio para o cliente.
7. As modificações são comunicadas a todas as partes afetadas.

(C) PJandl, 2023. 03/22/2024 62

PARA SABER MAIS
(C) PJandl, 2023. 03/22/2024 63
Para saber mais

- Guide do the Software Engineering Book of

Knowledge (SWEBOK). V3.0.
< https://www.computer.org/education/bodies-of-knowledge/software-engineering >
- Tipos de manutenção de Software
< https://leandromtr.com/tipos-de-manutencao-de-software/ >
- SOMMERVILLE, I. Engenharia de Software. 8ª Ed. Pearson: 2007.

(C) PJandl, 2023. 03/22/2024 64