Vous êtes sur la page 1sur 92
Evolução de Software Tópicos em Desenvolvimento de Sistemas Prof. Júlio Peixoto

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;

Odesempenho 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

reservados.

slide4

Um modelo espiral de desenvolvimento e evolução

Um modelo espiral de desenvolvimento e evolução © 2011 Pearson Prentice Hall. Todos os direitos reservados.

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 5

Evolução e em serviço

Evolução e em serviço © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 6

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 6

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

Osoftware ainda pode ser usado, mas nenhuma outra alteração é realizada nele.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide7

Processos de evolução

Processos de evolução do software dependem de:

Otipo de software que está sendo mantida;

Odesenvolvimento 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.

Aevolução e a identificação de mudanças continuam durante toda a vida do

sistema.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide8

Processos de identificação de mudanças e de evolução

Processos de identificação de mudanças e de evolução © 2011 Pearson Prentice Hall. Todos os direitos

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 9

O processo de evolução desoftware

O processo de evolução desoftware © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 10

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 10

Implementação de mudança

Implementação de mudança © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 11

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 11

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

reservados.

slide 12

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 def ei t o grave do sist ema p r eci sa ser r eparado para per mitir a

continuidade da operação normal;

Se as mudanças ao ambiente do sistema (por exemplo, uma atualização do sistema operacional) tem efeitos inesperados;

Se houver mudanças de negócios que exigem uma resposta muito rápida (por exemplo, o surgimento de um produto concorrente).

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 13

O processo de correção de emergência

O processo de correção de emergência © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 14

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.

 

Test es de regressão automatizados são particularment e valiosos quando feitas mudanças em um sistema.

são

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

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 15

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.

Aequipe 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

reservados.

slide 16

Dinâmica da evolução de programas

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

reservados.

slide 17

A mudança éinevitável

Os requisitos do sistema são suscetíveis de mudar enquanto o sistema está 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 um ambiente.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 18

Leis de Lehman

Leis de Lehman © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 19

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 19

Leis de Lehman

Leis de Lehman © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 20

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 20

Aplicabilidade das leis de Lehman

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

reservados.

slide 21

Leis de LEHMAN

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 LEHMAN

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 LEHMAN

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 LEHMAN

Quarta 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 LEHMAN

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 LEHMAN

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 LEHMAN

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 LEHMAN

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

muito dinheiro em

sistemas, para se obter um maior retorno o software deve ser utilizado por vários anos;

empresas

gastam

Muitas empresas dependem de sistemas de mais de 20 anos de existência;

sistema dessas

características poderia causar prejuízos se deixasse de funcionar por algum período.

A

interrupção

de

um

Sistemas Legados

São sistemas antigos que possuem uma função crítica em relação ao processo

organização que

modificações de

funcional

de

uma

sofreram diversas

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).

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

ser

implementado em uma linguagem obsoleta. Pode

ser difícil encontrar pessoal que tenha

conhecimento dessa linguagem.

parte

todo

sistema

pode

ou

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

tornando-o cada vez mais difícil de ser compreendido.

do

sistema,

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

Software de Aplicação

Software de Apoio

Hardware

Hardware de Sistema:

em muitos

casos, os

sistemas

legados

foram

escritos

para hardware de

que

mainframe,

não

está

mais

disponível,

tem

uma

dispendiosa

e

pode

manutenção

ser

não

compatível com as atuais políticas de

compras na área deTI.

Estrutura dos Sistemas Legados

Processos de Negócio

Software de Aplicação

Software de Apoio

Hardware

Software de apoio: O Sistema Legado pode depender de diferentes produtos de software de apoio, desde o sistema operacional e utilitários oferecidos pelo fabricante de hardware até os compiladores

utilizados para o desenvolvimento

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 Apoio

Hardware

Software de Aplicação:

fornece os serviços ao

negócio. É composto por vários programas separados,

desenvolvidos em épocas

diferentes

Estrutura dos Sistemas Legados

Processos de Negócio

Software de Aplicação

Software de Apoio

Hardware

Processos de negócios: são

os processos utilizados nas

empresas a fim de atingir algum objetivo de negócio.

Envolve regras e políticas de

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

hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.
hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.
hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.
hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.

hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.

hardware, especialmente se for proposta mudança radical para um novo tipo de hardware.

de

uma

Estrutura dos Sistemas

Legados

Exemplo:

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

melhorar

usa

facilidade de manutenção: acontece quando um sistema sofre várias modificações que são realmente necessárias.

o

sistema

para

Avaliar um Sistema

Legado

Avaliar um Sistema Legado 1 - Baixa qualidade, alto valor de negócio: esses sistemas estão prestando

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 candidatoo a

transformação ou substituição, se aplicável.

Avaliar um Sistema

Legado

Avaliar um Sistema Legado 2 - Baixa qualidade, baixo valor de negócio: manter esse sistema em

2 - Baixa 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
Avaliar um Sistema Legado

Avaliar um Sistema Legado

Avaliar um Sistema Legado 4 - Alta qualidade, Alto valor de negócio: esses sistemas devem ser

4 - Alta qualidade, Alto valor

de negócio: esses sistemas devem

ser mantidos em operação e sua alta qualidade significa que não é

investir na sua ou substituição.

Deve-se continuar a manutenção

transformação

necessário

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

reservados.

slide 61

Tipos de manutenção

Manutenção para corrigir defeitos de software

Mudar um sistema para corrigir deficiências que não correspondem aos seus requisitos.

Manutenção para adaptar o software a um ambiente operacional diferente.

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 do sistema

Modificando o sistema para satisfazer novos requisitos.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 62

Distribuição do esforço de manutenção

Distribuição do esforço de manutenção © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 63

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 63

Os custos de manutenção

Geralment e, 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 futuras manutenções.

Softwares envelhecidos podem t er al tos cust os de supor te (por exemplo, linguagens, compiladores antigos etc.)

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 64

Custos de desenvolvimento e manutenção

Custos de desenvolvimento e manutenção © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 65

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 65

Fatores de custos de manutenção

Estabilidade da equipe

Custos de manutenção são reduzidos se a mesma equipe estiver envolvida

com eles por algum tempo.

Responsabilidade contratual

Os desenvol vedores de um sist ema 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

reservados.

slide 66

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

reservados.

slide 67

Previsão de manutenção

Previsão de manutenção © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 68

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 68

Previsão de mudanças

Prever o número de mudanças

um sistema e seu ambiente.

exige a compreensão do relacionamento entre

Sist emas

f or t ement e

alterações no sistema.

acoplados

exigem

Sãofatores que influenciam essarelação:

mudanças sempre

que

ocor rem

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

reservados.

slide 69

Métricas de complexidade

As previsões de manutenção podem ser f eit as 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 do sistema.

Acomplexidade depende de:

Complexidade das estruturas de controle;

Complexidade das estruturas de dados;

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

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 70

Métricas de processo

Métricas de processo podem ser usadas para avaliar a

manutenção

capacidade de

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.

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

manutenibilidade.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 71

Reengenharia de software

Areestruturaçã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.

Osistema pode ser reestruturado eredocumentado.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 72

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

reservados.

slide 73

O processo de reengenharia

O processo de reengenharia © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 74

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 74

Atividades do processo

de reengenharia

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 de dados de sistema.

©

2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 75

Abordagens de reengenharia

Abordagens de reengenharia © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 76

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 76

Fatores de custo de reengenharia

Aqualidade do software a ser reestruturado.

Aferramenta de apoio disponível para a reengenharia.

Aextensão da conversão de dados necessária.

Adisponibilidade 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

reservados.

slide 77

Manutenção preventiva por refatoração

A refatoração é o processo de fazer melhorias em um programa para diminuir a degradação por meio da mudança.

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

os problemas de mudanças futuras.

Arefatoração envolve a modificação de um programa para melhoria da sua estrutura, redução da sua complexidade ou facilitar o entendimento.

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

reservados.

slide 78

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

necessárias

ferramentas

automatizadas

para

processar

e

fazer a

reengenharia de um sistema legado para criar um sistema novo, mais

manutenível.

Arefatoraçã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

reservados.

slide 79

“Maus cheiros” no código de programa

Código duplicado

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

Se um 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

reservados.

slide 80

“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 os dados.

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

reservados.

slide 81

Gerenciamento de sistemas legados

Organizações que dependem

de sistemas

estratégia para a evolução desses sistemas

legados devem escolher

uma

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

para que essenã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.

Aestratégia escolhida deve depender da qualidade do sistema e do seu valor de negócio.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 82

Um exemplo de uma avaliação desistema legado

Um exemplo de uma avaliação desistema legado © 2011 Pearson Prentice Hall. Todos os direitos reservados.

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 83

Categorias de sistemas legados

Baixa qualidade, baixo valor de negócio

Essessistemas 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 de negócio

Continuar em operação com a manutenção normal do sistema.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 84

Avaliação do valor de negócio

Aavaliaçã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

reservados.

slide 85

Pro

emas na

avaliação do valor de

negócio

Ouso do sistema

Se os 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ão apoiados

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

Se um sistema não é confiável e seus problemas afetam diretamente clientes, o sistema tem um baixo valor de negócio.

seus

As saídas do sistema

Se o 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

reservados.

slide 86

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 empresa?

Avaliação ambiental

as metas atuais da

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

reservados.

slide 87

Avaliação do processo de negó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 relacionament os com outros processos de negócios, esses são

necessários?

Oprocesso 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 em Web.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 88

Fatores usados na avaliação de ambientes

Fatores usados na avaliação de ambientes © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 89

Fatores usados na avaliação de aplicações

Fatores usados na avaliação de aplicações © 2011 Pearson Prentice Hall. Todos os direitos reservados. slide

© 2011 Pearson Prentice Hall. Todos os direitos reservados.

slide 90

Medições do sistema

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

Onúmero de solicitações de mudança nosistema;

Onúmero de diferentes interfaces de usuário usadas pelo sistema;

Ovolume de dados usados pelo sistema.

© 2011 Pearson Prentice Hall. Todos os direitos

reservados.

slide 91

Pontos Importantes

Existem três tipos de manutenção de software, correção de bugs,modificação

do software para

requisitos novos ou alterados.

funcionar em um novo ambiente, e implementação de

A reengenharia de software est á preocupada com a reestrutu raçã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

reservados.

slide 92