Evolução de Software

Tópicos em Desenvolvimento de Sistemas

Prof. Júlio Peixoto
Tópicos abordados
• Processos de evolução
✓ Processos de mudança de sistemas de software

• Dinâmica da evolução de programas

✓ Compreensão da evolução de softwares

• Manutenção de software
✓ Mudanças nos sistemas de software em operação.

• Gerenciamento de sistemas legados

✓ Tomadas de decisão sobre mudanças no software
Mudanças
no software
• Mudanças no software sãoinevitáveis

✓ Novos requisitos emergem quando o software éusado;

✓ Mudanças no ambiente de negócios;
✓ Erros devem ser reparados;
✓ Computadores e equipamentos novos são adicionados ao sistema;
✓ O desempenho ou a confiabilidade do sistema pode demandarmelhorias.

• Um problema-chave de todas as organizações está em implementar e gerenciar

as mudanças em seus sistemas de software já existentes.
Importância
da evolução
• As organizações fazem grandes investimentos em seus sistemas de software –
esses são ativos críticos de negócios.

• Para manter o valor desses ativos para o negócio, esses devem ser alterados e
atualizados.

• A maior parte do orçamento de softwares em grandes empresas é dedicado à

mudança e evolução de softwares existentes e não no desenvolvimento de
softwares novos.

© 2011 Pearson Prentice Hall. Todos os direitos

slide4
reservados.
Um modelo espiral dedesenvolvimento
e evolução

© 2011 Pearson Prentice Hall. Todos os direitos slide 5

reservados.
Evolução e em serviço

© 2011 Pearson Prentice Hall. Todos os direitos slide 6

reservados.
Evolução e em serviço
• Evolução
✓ Fase do ciclo de vida de um sistema de software em que esse está em uso
operacional e está evoluindo na medida em que novos requisitos são
propostos e implementados no sistema.

• Em serviço
✓ Nesta fase, o software continua a ser útil, mas as únicas mudanças feitas
são aquelas necessárias para mantê-lo operacional, isso é, correções de
bugs e mudanças para refletir as mudanças no ambiente do software.
Nenhuma funcionalidade nova é adicionada.

• Interrupção gradual
✓ O software ainda pode ser usado, mas nenhuma outra alteração é realizada
nele.
© 2011 Pearson Prentice Hall. Todos os direitos
slide7
reservados.
Processos de evolução
• Processos de evolução do software dependem de:

✓ O tipo de software que está sendo mantida;

✓ O desenvolvimento dos processosusados;
✓ As habilidades e a experiência das pessoas envolvidas.

• Propostas de mudança são os acionadores para a evolução do sistema.

✓ Devem estar ligados com componentes que são afetados pela mudança,
permitindo assim que sejam estimados os custos e o impacto da mudança.

• A evolução e a identificação de mudanças continuam durante toda a vida do

sistema.
© 2011 Pearson Prentice Hall. Todos os direitos
slide8
reservados.
Processos de identificação demudanças
e de evolução

© 2011 Pearson Prentice Hall. Todos os direitos slide 9

reservados.
O processo de evolução desoftware

© 2011 Pearson Prentice Hall. Todos os direitos slide 10

reservados.
Implementação de mudança

© 2011 Pearson Prentice Hall. Todos os direitos slide 11

reservados.
Implementação de mudança
• Iteração do processo de desenvolvimento, no qual as revisões do sistema são
projetadas, implementadas e testadas.

• Uma diferença fundamental é que a primeira fase de implementação da

mudança pode envolver a compreensão do programa, especialmente se os
desenvolvedores do sistema original não são responsáveis pela implementação
da mudança.

• Durante a fase de compreensão do programa, você precisa entender como o

programa está estruturado, como ele implementa a funcionalidade e como a
mudança proposta pode afetar o programa.

© 2011 Pearson Prentice Hall. Todos os direitos

slide12
reservados.
Solicitações de mudança
• Mudanças urgentes podem precisar ser implementadas sem passar por todas as
fases do processo de engenharia de software.

✓ Se um defeito grave do sistema precisa ser reparado para permitir a

continuidade da operação normal;

✓ Seas mudanças ao ambiente do sistema (por exemplo, uma atualização do

sistema operacional) tem efeitos inesperados;

✓ Sehouver mudanças de negócios que exigem uma resposta muito rápida

(por exemplo, o surgimento de um produtoconcorrente).

© 2011 Pearson Prentice Hall. Todos os direitos

slide13
reservados.
O processo de correção deemergência

© 2011 Pearson Prentice Hall. Todos os direitos slide 14

reservados.
Métodos ágeis eevolução
• Métodos ágeis são baseados no desenvolvimento incremental, assim, a
transição do desenvolvimento para a evolução é imperceptível.

✓A evolução é simplesmente uma continuação do processo de

desenvolvimento baseada em versões frequentes do sistema.

• Testes de regressão automatizados são particularmente valiosos quando são

feitas mudanças em um sistema.

• Mudanças podem ser expressas como estórias adicionais de usuários.

© 2011 Pearson Prentice Hall. Todos os direitos

slide15
reservados.
Problemas de transferência
• No qual a equipe de desenvolvimento usa uma abordagem ágil, mas a equipe de
evolução não está familiarizado com os métodos ágeis e preferem uma
abordagem baseada em planos.

✓ A equipe de evolução pode esperar uma documentação detalhada para

apoiar a evolução, e essa não é produzida em processos ágeis.

• Em que uma abordagem baseada em planos tem sido usada para o

desenvolvimento, mas a equipe de evolução prefere usar métodos ágeis.

✓ A equipe de evolução pode ter de começar do zero, desenvolvendo testes

automatizados e os códigos no sistema podem não ter sido refatorados e
simplificados como é esperado em desenvolvimento ágil.

© 2011 Pearson Prentice Hall. Todos os direitos

slide16
reservados.
Dinâmica da evolução deprogramas
• Dinâmica da evolução de programas é o estudo dos processos de mudanças de
sistema.

• Depois de vários importantes estudos empíricos, Lehman e Belady propuseram

que houvesse uma série de "leis" que se aplicassem a todos os sistemas, na
medida em que eles evoluíssem.

• Existem observações ao invés de leis. Elas são aplicáveis a sistemas de grande

porte desenvolvidos por grandesorganizações.

✓ Não está claro se essas são aplicáveis a outros tipos de sistemas de

software.

© 2011 Pearson Prentice Hall. Todos os direitos

slide17
reservados.
A mudança éinevitável
• Os requisitos do sistema são suscetíveis de mudar enquanto o sistemaestá
sendo desenvolvido, pois o ambiente estámudando.

• Portanto, um sistema entregue não atenderá a seus requisitos!

• Sistemas são fortemente acoplados com seu ambiente.

• Quando um sistema é instalado em um ambiente, ele muda esse ambiente e,

portanto, altera os requisitos do sistema.

• Os sistemas devem mudar, caso queiram permanecer úteis em umambiente.

© 2011 Pearson Prentice Hall. Todos os direitos

slide18
reservados.
Leis de Lehman

© 2011 Pearson Prentice Hall. Todos os direitos slide 19

reservados.
Leis de Lehman

© 2011 Pearson Prentice Hall. Todos os direitos slide 20

reservados.
Aplicabilidade das leis deLehman
• Geralmente, as leis de Lehman parecem ser aplicáveis a sistemas customizados,
grandes, desenvolvidos por grandes organizações.

✓ Confirmado no início de 2000 pelo trabalho de Lehman sobre o projeto

FEAST.

• Não está claro como devem ser modificadas para:

✓ Produtos de software devidamente embalados (rever tradução???);

✓ Sistemas que incorporam um número significativo de componentes COTS;
✓ Pequenas organizações;
✓ Sistemas de médio porte.

© 2011 Pearson Prentice Hall. Todos os direitos

slide21
reservados.
Leis de L E H M A N
Primeira Lei - Mudança Contínua

• A manutenção de um sistema é um processo

inevitável.
• O ambiente muda, novos requisitos surgem e o
sistema deve ser modificado
• Após o sistema modificado ser reimplantado, ele
muda o ambiente

“Um sistema em um ambiente do mundo real

necessariamente tem de ser modificado ou se tornará uma
maneira progressiva menos útil para esse ambiente”.
Leis de L E H M A N
Segunda Lei - Complexidade Crescente

• A medida que o sistema é modificado sua estrutura é

degradada.

• A medida que um sistema evolui, sua complexidade

aumenta, a menos que seja realizado esforço para mantê-la
ou diminuí-la.

• Manutenções preventivas são necessárias e tem custos

adicionais, além daqueles para implementar as mudanças
necessárias.

“A medida que um programa em evolução se modifica,

sua estrutura tende a se tornar mais complexa.
Recursos extras precisam ser dedicados a preservar e
simplificar a estrutura”.
Leis de L E H M A N
Terceira Lei – Auto Regulação

• Sistemas de grande porte têm uma dinâmica própria que é

estabelecida no estágio inicial do processo de
desenvolvimento.
• A evolução de software é um processo auto-regulável.
Atributos do sistema como tamanho, tempo entre versões e
número de erros reportados é quase invariável em cada
versão do sistema.
• Consequência de fatores estruturais e organizacionais

“A evolução do programa grande é um processo auto-regulado. Os

atributos do sistema, como tamanho, tempo entre releases e número
de erros relatados são aproximadamente invariáveis para cada
release do sistema”.
Leis de L E H M A N

Quar ta Lei – Estabilidade Organizacional

• A maioria dos projetos de programação trabalha no “Estado

saturado”, isto é, uma mudança nos recursos ou no pessoal tem
efeitos imperceptíveis na evolução de longo prazo do sistema.

• Durante o ciclo de vida de um programa, sua taxa de desenvolvimento

é quase constante

• Independe de recursos dedicados ao desenvolvimento do sistema

• Alocação de grandes equipes é improdutivo, pois o overhead de

comunicação predomina

“Durante o tempo de duração de um programa, sua taxa de

desenvolvimento é aproximadamente constante e independente dos
recursos dedicados ao desenvolvimento do sistema”.
Leis de L E H M A N
Quinta Lei - Conservação de Familiaridade
• Acrescentar nova funcionalidade em um sistema inevitavelmente
introduz novos defeitos. Quanto mais funcionalidades forem
acrescentadas em cada release maior o número de defeitos.
• Durante o ciclo de vida de um sistema, mudanças incrementais
em cada versão são quase constantes.
• Um grande incremento em uma release leva a muitos
defeitos novos.A release posterior será dedicada quase
exclusivamente para corrigir os defeitos
• Ao orçar grandes incrementos, deve-se considerar as
correções de defeitos

“Durante o tempo de duração de um sistema, as mudanças

incrementais em cada release são aproximadamente constantes”.
 Leis de L E H M A N

Sexta Lei – Crescimento Contínuo

• O conteúdo funcional de sistemas

devem ser continuamente aumentado
para manter a satisfação do usuário.
Leis de L E H M A N

Sétima Lei – Qualidade Declinante

• A qualidade de sistemas parecerá

estar declinando a menos que eles
sejam mantidos e adaptados às
modificações do ambiente
 Leis de L E H M A N

Oitava Lei – Sistema de Feedback

• Os processos de evolução incorporam

sistemas de
feedback com vários agentes e loops

• Estes sistemas devem ser considerados

para conseguir aprimoramentos
significativos de produto
MANUTENÇÃO DE SISTEMAS

Software precisa de mudanças para corrigir erros,

melhorar seu desempenho ou outras características não
funcionais ou incluir, alterar e excluir requisitos funcionais.
MANUTENÇÃO DE SISTEMAS

• Manutenção corretiva:
• Mudanças para reparo de defeitos de software

• Manutenção adaptativa:
• Mudanças para adaptar o software a outro
ambiente

• Manutenção evolutiva:
• Mudanças para adicionar funcionalidade ao
sistema
MANUTENÇÃO DE SISTEMAS
Estratégias para mudanças de software:

• Manutenção de software: Mudanças realizadas em respostas a

requisitos (Mantendo estável a estrutura fundamental).

• Transformação de Arquitetura: Envolve transformações de arquitetura

de software.
Ex. Sistema centralizado transformado em um sistema com
arquitetura cliente-servidor.

• Reengenharia de software: Nenhuma nova funcionalidade é adicionada

ao sistema. O sistema é alterado afim de tornar mais fácil sua
compreensão e alteração, mas sem envolver grandes mudanças em sua
arquitetura.

Nota:As estratégias não são mutuamente exclusivas.

MANUTENÇÃO DE SISTEMAS

Manutenção de Software:
É o processo geral de modificação de um sistema após ser
colocado em uso.

Tipos de manutenção:

• Manutenção para reparar os defeitos de software.

• Manutenção para adaptar o software a um

ambiente operacional diferente.

• Manutenção para fazer acréscimo à funcionalidade

do sistema ou modificá-los.
MANUTENÇÃO DE SISTEMAS

Custeio do Ciclo de Vida do Produto

• Analisar o custo de todo ciclo de vida do

produto e não apenas o custo do projeto.
 MANUTENÇÃO DE SISTEMAS

Os custos de manutenção variam de acordo com a natureza da

aplicação, mas como geralmente são bem superiores ao custo de
desenvolvimento. Os principais fatores que elevam os custos de
manutenção são:

• Ao término do desenvolvimento do projeto geralmente a equipe de

desenvolvimento é desfeita e no caso de manutenção dificilmente
será a mesma equipe que desenvolveu.

• Geralmente o processo de manutenção é tratado como mais

simples pela alta direção designando profissionais menos
experientes. Isto é um erro!!!

• Linguagem ultrapassada, técnicas obsoletas, documentação

incompleta ou inexistente e código com alta complexidade (devido
a manutenções anteriores).

• Contratos de desenvolvimento, geralmente não preveem

manutenção, o que e mais um problema no processo.
Sistemas Legados
 Razão
● As empresas gastam muito dinheiro em
sistemas, para se obter um maior retorno o
software deve ser utilizado por vários anos;

● Muitas empresas dependem de sistemas de

mais de 20 anos de existência;

● A interrupção de um sistema dessas

características poderia causar prejuízos se
deixasse de funcionar por algum período.
Sistemas Legados
● São sistemas antigos que possuem uma
função crítica em relação ao processo
funcional de uma organização que
sofreram diversas modificações de
requisitos durante seu tempo de vida;

● Também operam em um hardware antigo

e específico, com diversas limitações.
 Sistemas
●
Legados
Os sistemas legados respondem pela maior parte do
processamento de dados mundial, ou, dependendo de
entendimentos, por todo. Isto porque, para SEACORD (2003)
qualquer sistema em produção pode ser considerado como
legado. Entre 60% e 70% dos sistemas estão em COBOL,
estima-se em 200 milhões de linhas (SEACORD et al, 2003 e
ULRICH,2002).

● A participação do custo de manutenção no custo total de um

sistema tem crescido de 40%, nos anos 70, até 90%, atualmente
(PIGOSKI, 1996). Destes custos, cerca de 20% são consumidos
com correções e 80% com melhorias diversas (Martin apud
ULRICH,2002).

Fonte:http://imasters.com.br/artigo/5919/desenvolvimento/reflexoes_sobre_manutencao_de_sistemas_l
egados/
Riscos de Substituição de Sistemas
Legados

● Raramente existe uma especificação

completa do sistema legado. E se existir, é
muito improvável que ela abranja todas as
modificações feitas no sistema.

● Os processos corporativos e o modo

como os sistemas legados operam estão
sempre intrinsecamente ligados. Esses
processos foram projetados para tirar
vantagens dos serviços de software e para
evitar seus pontos negativos.
Riscos de Substituição de Sistemas
Legados
● Importantes regras corporativas podem
estar inseridas no software e pode não
estar documentadas em nenhum outro
lugar. Simplesmente substituir o software
pode ter consequências imprevisíveis;

●O simples desenvolvimento de um sistema

para tomar essa função pode trazer risco
em si para a organização (atrasos, custos
altos...).
 Manutenção de Sistemas
Legados
● Manter sistemas legados envolve um grande
dispêndio de dinheiro e tempo porque:

◦ Diferentes partes do sistema foram implementadas

por diferentes equipes. Não há um estilo de
programação consistente em todo sistema.

◦ Uma parte ou todo sistema pode ser

implementado em uma linguagem obsoleta. Pode
ser difícil encontrar pessoal que tenha
conhecimento dessa linguagem.
Manutenção de Sistemas
Legados
◦ Frequentemente documentação é
inadequada e desatualizada. Em alguns casos,
a única documentação é o código-fonte do
sistema. Outras, só existe a versão
executável do sistema;

◦ Os muitos anos de manutenção podem ter

corrompido a estrutura do sistema,
tornando-o cada vez mais difícil de ser
compreendido.
Manutenção de Sistemas
Legados
◦ O sistema pode ter sido otimizado para
melhorar a utilização de espaço ou velocidade
de execução, em vez de ter sido escrito para
facilitar a compreensão;

◦ Os dados processados pelo sistema podem

estar armazenados em diferentes arquivos, que
podem ter estruturas incompatíveis. É possível
que alguns dados tenha sido duplicados, ou
estejam desatualizados, eeinexatos ou
incompletos.
Estrutura dos Sistemas Legados

Processos de Negócio Hardware de Sistema: em muitos

casos, os sistemas legados foram
Software de Aplicação escritos para hardware de que
mainframe, não está mais
Software de Apoio disponível, tem uma manutenção
dispendiosa e pode não ser
Hardware compatível com as atuais políticas de
compras na área deTI.
Estrutura dos Sistemas Legados
Software de apoio: O Sistema
Legado pode depender de
Processos de Negócio diferentes produtos de software
de apoio, desde o sistema
Software de Aplicação operacional e utilitários
oferecidos pelo fabricante de
Software de Apoio hardware até os compiladores
utilizados para o desenvolvimento
Hardware do sistema. Novamente, esses
produtos de software podem
estar obsoletos e não ter mais a
assistência técnica de seus
fornecedores originais.
Estrutura dos Sistemas Legados

Processos de Negócio
Software de Aplicação:
Software de Aplicação
fornece os serviços ao
negócio. É composto por
Software de Apoio vários programas separados,
desenvolvidos em épocas
Hardware
diferentes
Estrutura dos Sistemas Legados

Processos de Negócio Processos de negócios: são

os processos utilizados nas
Software de Aplicação empresas a fim de atingir
algum objetivo de negócio.
Software de Apoio
Envolve regras e políticas de
Hardware negócio, que especificam
como as transações devem
ser feitas.
Estruturas dos Sistemas
Legados
● A modificação de uma camada do sistema pode
introduzir novos recursos, e as camadas superiores
do sistema podem ser modificadas para se
beneficiarem desse recurso;

● A modificação do software no sistema pode torná-lo

mais lento, de modo que um novo hardware é
necessário;

● Muitas vezes é impossível manter interfaces de

hardware, especialmente se for proposta uma
mudança radical para um novo tipo de hardware.
Estrutura dos Sistemas
Legados
● Exemplo:
 Avaliar um Sistema
Legado
● Descartar completamente o sistema: essa opção
deve ser escolhida quando o sistema não tiver
prestando uma contribuição efetiva aos processos
de negócio. Isso ocorre quando os processos
corporativos foram modificados, desde que o
sistema foi instalado, e não mais dependem do
sistema;
● Substituir um sistema por um novo: pode ser
conseqüência de uma mudança de hardware que
inviabiliza o sistema antigo, mas ainda mantendo
utilidade.
 Avaliar um Sistema
Legado
● Continuar a manter o sistema: esta opção deve
ser escolhida quando o sistema ainda é
necessário, ele for bastante estável e os usuários
não pedirem grandes modificações no sistema;

● Transformar o sistema para melhorar usa

facilidade de manutenção: acontece quando um
sistema sofre várias modificações que são
realmente necessárias.
Avaliar um Sistema
Legado
1 - Baixa qualidade, alto valor
de negócio: esses sistemas estão
prestando uma importante
contribuição à empresa e não
podem ser descartados. No
entanto, sua baixa qualidade
transforma num candidato
o a
transformação ou substituição, se
aplicável.
Avaliar um Sistema
Legado
2 - B aixa qualidade,
baixo valor de negócio:
manter esse sistema em
operação será dispendioso
e a taxa de retorno de
investimento será bastante
pequena. São candidatos a
serem descartados.
Avaliar um Sistema Legado
Avaliar um Sistema Legado
4 - Alta qualidade, Alto valor
de negócio: esses sistemas devem
ser mantidos em operação e sua
alta qualidade significa que não é
necessário investir na sua
transformação ou substituição.
Deve-se continuar a manutenção
normal do sistema.
Avaliar um Sistema Legado
● Avaliação do Valor de negócio:

◦ Usuários finais do sistema: Qual é a eficácia dos

sistemas que apoia seus processos de negócios?
Quanto da funcionalidade do sistema é utilizada?

◦ Clientes: O uso do sistema é transparente para os

clientes ou suas interações são limitadas pelo
sistema? Eles têm que esperar por causa do
sistema? Os erros do sistema têm impacto direto
sobre os clientes?
Avaliar um Sistema Legado
● Avaliação do Valor de negócio:

◦ Gerentes de linha: os gerentes pensam que o

sistema é eficaz para o sucesso de uma unidade? Os
custos de manutenção do sistema são justificáveis?
Os dados manipulados pelo sistema são
importantes para o funcionamento da unidade do
gerente?

◦ Gerentes de TI: existem dificuldades em encontrar

pessoas para trabalhar no sistema? O sistema
consome recursos que poderiam ser usados mais
efetivamente em outros sistemas?
 Avaliar um Sistema Legado
● Avaliação do Valor de negócio:

◦ Gerentes sênior: o sistema e o processo de

negócio associado prestam uma contribuição
eficaz aos objetivos da empresa?
Pontos importantes
• O desenvolvimento e a evolução de software podem ser pensados como
processo iterativo e integrado, que pode ser representado usando um modelo
em espiral.

• Para sistemas customizados, os custos de manutenção de software geralmente

excedem os custos de desenvolvimento de software.

• O processo de evolução do software é impulsionado pelas solicitações de

mudança e inclui a análise do impacto da mudança, planejamento de release e
implementação da mudança.

• As leis de Lehman, assim como a noção de que a mudança é contínua, descreve

uma série de considerações derivadas de estudos de longo prazo, de evolução
de sistema.
© 2011 Pearson Prentice Hall. Todos os direitos
slide61
reservados.
Tipos de
manutenção
• Manutenção para corrigir defeitos desoftware

✓ Mudar um sistema para corrigir deficiências que não correspondem aos

seus requisitos.

• Manutenção para adaptar o software a um ambiente operacionaldiferente.

✓ Mudar um sistema para que ele opere em um ambiente diferente

(computador, OS, etc.) da sua implementaçãoinicial.

• Manutenção para adicionar ou modificar a funcionalidade dosistema

✓ Modificando o sistema para satisfazer novos requisitos.

© 2011 Pearson Prentice Hall. Todos os direitos
slide62
reservados.
Distribuição do esforço demanutenção

© 2011 Pearson Prentice Hall. Todos os direitos slide 63

reservados.
Os custos de
manutenção
• Geralmente, maior do que os custos de desenvolvimento (2 * a 100 *,
dependendo da aplicação).

• Afetados por fatores técnicos e não técnicos.

• Aumentam na medida em que o software é mantido. A manutenção corrompe a

estrutura do software, dificultando futurasmanutenções.

• Softwares envelhecidos podem ter altos custos de suporte (por exemplo,

linguagens, compiladores antigos etc.)

© 2011 Pearson Prentice Hall. Todos os direitos

slide64
reservados.
Custos de desenvolvimento emanutenção

© 2011 Pearson Prentice Hall. Todos os direitos slide 65

reservados.
Fatores de custos de
manutenção
• Estabilidade da equipe

✓ Custos de manutenção são reduzidos se a mesma equipe estiverenvolvida

com eles por algum tempo.

• Responsabilidade contratual

✓ Os desenvolvedores de um sistema podem não ter responsabilidade

contratual para a manutenção, assim não há incentivo para projetar
mudanças futuras.

© 2011 Pearson Prentice Hall. Todos os direitos

slide66
reservados.
Fatores de custos de
manutenção
• Qualificações de pessoal

✓ Muitas vezes a equipe de manutenção é inexperiente e tem conhecimentos

do domínio limitados.

• Idade e estrutura do programa

✓ Na medida em que os programas envelhecem, sua estrutura se degrada e

tornam-se mais difíceis de entender e mudar.

© 2011 Pearson Prentice Hall. Todos os direitos

slide67
reservados.
Previsão de manutenção

© 2011 Pearson Prentice Hall. Todos os direitos slide 68

reservados.
Previsão de
mudanças
• Prever o número de mudanças exige a compreensão do relacionamento entre
um sistema e seu ambiente.

• Sistemas fortemente acoplados exigem mudanças sempre que ocorrem

alterações no sistema.

• São fatores que influenciam essarelação:

✓ Número e complexidade das interfaces de sistema;

✓ Número de requisitos de sistema inerentemente voláteis;

✓ Os processos de negócio nos quais o sistema éusado.

© 2011 Pearson Prentice Hall. Todos os direitos
slide69
reservados.
Métricas de
complexidade
• As previsões de manutenção podem ser feitas por meio da avaliação da
complexidade dos componentes do sistema.

• Estudos têm demonstrado que a maioria dos esforços de manutenção são gastos
em um número relativamente pequeno de componentes dosistema.

• A complexidade depende de:

✓ Complexidade das estruturas de controle;

✓ Complexidade das estruturas de dados;

✓ Método (procedimento) de objetos e tamanho demódulo.

© 2011 Pearson Prentice Hall. Todos os direitos
slide70
reservados.
Métricas de
processo
• Métricas de processo podem ser usadas para avaliar a capacidade de
manutenção

✓ Número de solicitações de manutenção corretiva;

✓ Tempo médio necessário para a análise de impacto;

✓ Tempo médio necessário para implementar uma solicitação de mudança;

✓ Número de solicitações de mudança pendentes.

• Sealgum ou todos esses estão aumentando, isso pode indicar um declínio na

manutenibilidade.
© 2011 Pearson Prentice Hall. Todos os direitos
slide71
reservados.
Reengenharia
de software
• A reestruturação ou reescrita de parte ou da totalidade de um sistema legado,
sem alterar sua funcionalidade.

• Aplicável em casos em que alguns, mas não todos os subsistemas de um sistema

maior exigem manutenção frequente.

• A reengenharia envolve esforços adicionais para torná-los mais fáceis de se

manter.

• O sistema pode ser reestruturado eredocumentado.

© 2011 Pearson Prentice Hall. Todos os direitos

slide72
reservados.
Vantagens da
reengenharia
• Risco reduzido

✓ Existe um alto risco no desenvolvimento de software novo. Pode haver

problemas de desenvolvimento, problemas com a equipe e problemas de
especificação.

• Custo reduzido

✓ Muitas vezes, o custo da reengenharia é significativamente menor do que os

custos de desenvolvimento de software novo.

© 2011 Pearson Prentice Hall. Todos os direitos

slide73
reservados.
O processo dereengenharia

© 2011 Pearson Prentice Hall. Todos os direitos slide 74

reservados.
Atividades do processo
dereengenharia
• Tradução de código-fonte
✓ Conversão do código para uma nova linguagem.

• Engenharia reversa
✓ Análise do programa para compreensão desse;

• Melhoria de estrutura de programa

✓ Reestruturação automática para capacidade de compreensão;

• Modularização de programa
✓ Reorganização da estrutura de programa;

• Reengenharia de dados
✓ Limpeza e reestruturação
© 2011de dados
Pearson Prenticede sistema.
Hall. Todos os direitos
slide75
reservados.
Abordagens de reengenharia

© 2011 Pearson Prentice Hall. Todos os direitos slide 76

reservados.
Fatores de custo de
reengenharia
• A qualidade do software a ser reestruturado.

• A ferramenta de apoio disponível para a reengenharia.

• A extensão da conversão de dados necessária.

• A disponibilidade de pessoal especializado para a reengenharia.

✓ O que pode ser um problema com velhos sistemas baseados em tecnologias

que já não são amplamente usadas.

© 2011 Pearson Prentice Hall. Todos os direitos

slide77
reservados.
Manutenção preventiva
por refatoração
• A refatoração é o processo de fazer melhorias em um programa para diminuir a
degradação por meio damudança.

• Você pode pensar na refatoração como "manutenção preventiva", o que reduz

os problemas de mudanças futuras.

• A refatoração envolve a modificação de um programa para melhoria da sua

estrutura, redução da sua complexidade ou facilitar oentendimento.

• Ao refatorar um programa, você não deve adicionar funcionalidade, mas sim

concentrar-se na melhoria do programa.

© 2011 Pearson Prentice Hall. Todos os direitos

slide78
reservados.
Refatoração e
reengenharia
• A reengenharia ocorre depois que um sistema é mantido por algum tempo e os
custos de manutenção são crescentes.

• São ferramentas automatizadas para processar e fazer a

necessárias
reengenharia de um sistema legado para criar um sistema novo, mais
manutenível.
• A refatoração é um processo contínuo de melhoria por meio do processo de
evolução e desenvolvimento.

• Pretende-se evitar a degradação da estrutura e código que aumenta os custos e

as dificuldades de manutenção de um sistema.

© 2011 Pearson Prentice Hall. Todos os direitos

slide79
reservados.
“Maus cheiros” no
código de
• Código duplicado
programa
✓ O mesmo código ou códigos muito semelhantes podem ser incluídos em
diferentes lugares de um programa. Estes podem ser removidos e
implementados como um único método ou função a qual será chamada
quando necessária.

• Métodos longos
✓ Seum método for muito longo, ele deve ser redefinido como uma série de
métodos mais curtos.

• Declarações switch (case)

✓ Frequentemente envolve a duplicação, na qual o switch depende do tipo de
um valor. As declarações de switch podem ser espalhadas em torno de um
programa. Muitas vezes, em linguagens orientadas a objetos, é possível usar
polimorfismo para conseguir a mesma coisa.
© 2011 Pearson Prentice Hall. Todos os direitos
slide80
reservados.
“Maus cheiros” no
código de programa
• Aglutinação de dados

✓ A aglutinação de dados ocorre quando o mesmo grupo de itens de dados

(campos em classes, parâmetros em métodos) voltam a ocorrer em vários
lugares em um programa. Muitas vezes, esses podem ser substituídos por
um objeto que encapsule todos osdados.

• Generalidade especulativa

✓ Ocorre quando os desenvolvedores incluem generalidades em um programa

no caso dessas serem necessárias no futuro. Muitas vezes podem,
simplesmente, ser removidas.

© 2011 Pearson Prentice Hall. Todos os direitos

slide81
reservados.
Gerenciamento de
sistemas legados
• Organizações que dependem de sistemas legados devem escolher uma
estratégia para a evolução desses sistemas

✓ Fazer o descarte completo do sistema e modificar os processos de negócio

para que esse não seja mais necessário;
✓ Continuar dando suporte para o sistema;
✓ Reestruturar o sistema por meio da reengenharia para melhoria de sua
manutenibilidade;
✓ Substituir o sistema com um novo sistema.

• A estratégia escolhida deve depender da qualidade do sistema e do seu valor de

negócio.

© 2011 Pearson Prentice Hall. Todos os direitos

slide82
reservados.
Um exemplo de uma avaliação desistema
legado

© 2011 Pearson Prentice Hall. Todos os direitos slide 83

reservados.
Categorias de
sistemas legados
• Baixa qualidade, baixo valor de negócio
✓ Esses sistemas devem ser descartados.

• Baixa qualidade, alto valor de negócio

✓ Esses fazem uma importante contribuição para os negócios, mas sua
manutenção é cara. Deve passar por uma reengenharia ou ser substituído
caso um sistema adequado esteja disponível.

• Alta qualidade, baixo valor de negócio

✓ Substituir com COTS,descartar completamente ou manter.

• Alta qualidade, alto valor denegócio

✓ Continuar em operação com a manutenção normal do sistema.
© 2011 Pearson Prentice Hall. Todos os direitos
slide84
reservados.
Avaliação do
valor denegócio
• A avaliação deve levar em conta diferentes pontos de vista:

✓ Usuários finais do sistema;

✓ Clientes empresariais;

✓ Gerentes de linha;

✓ Gerentes de TI;

✓ Gerentes seniores.

• Entrevistar diferentes stakeholders e coletar os resultados obtidos.

© 2011 Pearson Prentice Hall. Todos os direitos
slide85
reservados.
Problemas na
avaliação do valorde
•negócio
O uso dosistema
✓ Seos sistemas são usados apenas ocasionalmente ou por um pequeno
número de pessoas, eles podem ter um valor de negócio debaixo.

• Os processos de negócio que sãoapoiados

✓ Um sistema pode ter um baixo valor de negócio se força o uso de processos
de negócios ineficientes.

• Confiança do sistema
✓ Seum sistema não é confiável e seus problemas afetam diretamente seus
clientes, o sistema tem um baixo valor denegócio.

• As saídas do sistema
✓ Seo negócio depende das saídas do sistema, então o sistema tem um alto
valor de negócio. © 2011 Pearson Prentice Hall. Todos os direitos
slide86
reservados.
Avaliação da
qualidade do
sistema
• Avaliação dos processos de negócio

✓ O quão bem o processo de negócios dá suporte para as metas atuaisda

empresa?

• Avaliação ambiental

✓ Quão eficaz é o ambiente do sistema e quão caro é mantê-lo?

• Aplicação da avaliação

✓ Qual é a qualidade do sistema de aplicação de software ?

© 2011 Pearson Prentice Hall. Todos os direitos

slide87
reservados.
Avaliação do processo denegócio
• Use uma abordagem orientada a pontos de vista e procure respostas dos
stakeholders do sistema.

✓ Existe um modelo de processo definido, esse é seguido?

✓ Diferentes partes da organização usam processos diferentes para a mesma
função?
✓ Como o processo foi adaptado?
✓ Quais são os relacionamentos com outros processos de negócios, esses são
necessários?
✓ O processo efetivamente recebe suporte do software de aplicação legada?

• Exemplo - um sistema de aquisição de viagens pode ter um baixo valor de

negócio, em virtude do uso generalizado de aquisições baseadas emWeb.

© 2011 Pearson Prentice Hall. Todos os direitos

slide88
reservados.
Fatores usados na avaliação deambientes

© 2011 Pearson Prentice Hall. Todos os direitos slide 89

reservados.
Fatores usados na avaliação deaplicações

© 2011 Pearson Prentice Hall. Todos os direitos slide 90

reservados.
Medições do sistema

• Você pode coletar dados quantitativos para fazer uma avaliação da qualidade do
sistema de aplicação.

✓ O número de solicitações de mudança nosistema;

✓ O número de diferentes interfaces de usuário usadas pelosistema;

✓ O volume de dados usados pelosistema.

© 2011 Pearson Prentice Hall. Todos os direitos

slide91
reservados.
Pontos Importantes
• Existem três tipos de manutenção de software, correção de bugs,modificação
do software para funcionar em um novo ambiente, e implementação de
requisitos novos ou alterados.

• A reengenharia de software está preocupada com a reestruturação e a

redocumentação do software para torná-lo mais fácil de entender emudar.

• Refatoração, fazer pequenas alterações no programa, as quais devem preservar

a funcionalidade, é uma forma de manutenção preventiva.

• O valor de negócio de um sistema legado e a qualidade do software de aplicação

devem ser avaliadas para ajudar a decidir se o sistema deve ser substituído,
transformado ou mantido.
© 2011 Pearson Prentice Hall. Todos os direitos
slide92
reservados.