Prof. Hélio Monteiro

Mudança de Software Mudança de software é inevitável

Novos requisitos emergem quando o SW é usado; O ambiente do negócio muda; Erros devem ser reparados; Incorporação de novo Hardware ; Melhoria no desempenho e/ou confiabilidade.

Um problema chave para as organizações é implementar e gerir mudança para os seus sistemas legados

Estratégias de mudança de software Manutenção de software

Mudanças são feitas em resposta à modificação de requisitos, mas a estrutura fundamental do SW permanece estável.

Transformação arquitetural A arquitetura do sistema é modificada, geralmente de uma

centralizada para uma distribuída. Reengenharia de software

Nenhuma funcionalidade é adicionada ao sistema, mas ele é reestruturado e reorganizado para facilitar mudanças futuras.

Estas estratégias podem ser aplicadas em conjunto ou separadamente.

Dinâmica de evolução dos sistemasA dinâmica de evolução de sistemas é o estudo dos

processos de mudança do sistemaEstudo empírico (Estudo baseado na experiência),

realizado por Lehman e Belady propõe que existem leis que são aplicadas a todos os sistemas enquanto eles evoluem;

O estudo foi baseado em sistemas de grande porte desenvolvidos por grandes organizações.

Leis de Lehman Mudança contínua – Um sistema, num ambiente real,

necessariamente muda ou torna-se progressivamente menos útil;

Aumento da complexidade – Com a evolução do sistema, sua estrutura tende a ficar mais complexa;

Evolução de sistemas de grande porte – A evolução de um sistema é um processo auto-regulável;

Estabilidade organizacional – mudanças de staff / recursos tem poucos efeitos na evolução do sistema;

Conservação da familiaridade - a mudança incremental é constante.

Aplicabilidade das leis de Lehman São aplicadas a sistemas de grande porte desenvolvidos

por grandes organizações. Entretanto, as leis podem ser aplicadas a sistemas menores que existem em empresas de menor porte.

Manutenção de software É modificar um sistema depois que ele foi implantado ou se

encontra operacional; A manutenção pode envolver grandes mudanças, até mesmo na

arquitetura do sistema; As mudanças são implementadas modificando os componentes

existentes e/ou adicionando novos componentes ao sistema; Os requisitos do sistema mudam porque o ambiente muda;Se os sistemas estão fortemente acoplados com seu ambiente,

quando um sistema novo ou uma nova funcionalidade é instalada, ele pode mudar o ambiente e, portanto, mudar os requisitos dos demais sistemas;

Os sistemas devem ser modificados para que eles permaneçam úteis no ambiente.

Tipos de manutenção Manutenção Corretiva

◦ Este tipo de manutenção é utilizado para a correção de erros que podem surgir em: Regras de negócio (Erro ou ausência); Código; Performance (Desempenho);

Manutenção Evolutiva◦ Este tipo de manutenção visa:

Implementar novas regras de negócio; Adaptar o sistema a novas solicitações do ambiente; Inclusão de novas funcionalidades.

Manutenção Adaptativa◦ Este tipo de manutenção diz respeito à adaptabilidade do sistema a novos

elementos, sejam de software ou hardware. Manutenção Preventiva

◦ Caracteriza-se pela necessidade de evitar a ocorrência de uma possível condição que provocará erro, inexatidão ou defasagem do sistema.◦ Um exemplo de manutenção preventiva foi o Bug do ano 2000.

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

Modelo espiral p/ manutenção

Custos de manutenção Usualmente maiores do que os custos de desenvolvimento (de duas a

cem vezes, dependendo da aplicação) Afetados por fatores técnicos e não técnicos Aumenta enquanto o SW é mantido. A manutenção corrompe a

estrutura do SW, tornando-a mais difícil. SW antigos podem ter custos de manutenção altos

0 50 100 150 200 250 300 350 400 450 500

System 1

System 2

Development costs Maintenance costs

$

ManutençãoFatores de custos

Estabilidade da equipe - Custos de manutenção são menores se o mesmo staff está envolvido com o sistema

Habilidades do staff - O staff de manutenção é inexperiente e tem conhecimento limitado do domínio

Idade e estrutura do sistema - Enquanto o programa envelhece, sua estrutura se degrada tornando-o mais difícil de compreender e mudar

Software evolutivoEm vez de ter fases separadas p/ manutenção e desenvolvimento, é

preferível que o SW seja desenhado permitindo sua evolução contínua no seu ciclo de vida

O processo de manutenção

Pedidos de mudançaSão feitos pelos utilizadores, clientes ou gestão; Em princípio devem ser analisados cuidadosamente

como parte do processo de manutenção, e então, implementados ;

Na prática, alguns pedidos devem ser implementados urgentementeReparar falhas ;Mudanças no ambiente; Mudanças urgentes do negócio.

Implementação da mudança

Reparação de emergência

Previsão de mudançaA previsão de mudança preocupa-se em avaliar as partes

do sistema que podem causar problemas e ter custos de manutenção altos A aceitação da mudança depende da manutenibilidade dos

componentes afectados pela mudança; Implementar mudanças degrada o sistema e reduz sua

manutenibilidade ; Custos de manutenção dependem do número de

mudanças e os custos de mudança dependem da manutenibilidade.

Previsões em relação às mudanças

Previsão da mudança Prever o número de mudanças requer a compreensão

das relações entre um sistema e seu ambiente; Sistemas fortemente acoplados c/ o ambiente requerem

mudanças quando quer que o ambiente mude; Fatores que influenciam:

Número e complexidade das interfaces do sistema; Número de requisitos inerentemente voláteis; Os processos do negócio onde o sistema é utilizado.

Grupo de Controle de MudançaAvalia:

o impacto na funcionalidade do produto.validade técnica da mudança

consistência, uniformidadeAprova, rejeita, ou põe em espera;Segue um Cronograma.

Componentes de um pedido de mudançaDescrição da mudança solicitada;

O solicitante deve, através de um canal próprio, descrever o que deseja alterar em relação ao software.

Alternativas existentes em relação à mudança; A equipe de desenvolvimento/manutenção deve verificar se existem

alternativas viáveis com vistas aos aspectos: prático, técnico e econômico.Complexidade;

Verificação da complexidade, em relação ao sistema, da alteração solicitada.

Impacto;Analisar o impacto das mudanças no sistema e nos demais

sistemas com os quais há interação;

Componentes de um pedido de mudançaCusto;

Viabilidade econômica do projeto de mudanças;Relação com outras mudanças;

Analisar se existem outras mudanças que impactem ou contemplem as mudanças solicitadas.

Cronograma;Após as etapas anteriormente descritas, elaborar cronograma com os

principais marcos do projeto.Testes

Realização dos testes, principalmente regressão, para as alterações solicitadas.

Métricas de complexidade Previsões de manutenção podem ser feitas através da

avaliação da complexidade dos componentes do sistema; Estudos mostram que a maior parte dos esforços de

manutenção são gastos em um número relativamente pequeno de componentes de um sistema;

A complexidade depende das estruturas de controle, das estruturas de dados e do tamanho dos módulos e procedimentos.

Métricas do processo Medidas de processo podem ser usadas p/ medir a

manutenibilidade : Número de pedidos p/ a manutenção corretiva; Tempo médio requerido p/ a análise de impacto; Tempo médio p/ implementar um pedido de mudança; Número de pedidos de mudanças importantes.

Se qualquer destes valores apresentar curva ascendente, pode indicar um declínio na manutenibilidade.

Evolução da arquitetura Necessidade de converter sistemas legados (arquitetura

centralizada) para arquitetura distribuída (cliente-servidor) Razões

Custos de HW. Servidores são mais baratos que mainframes;Utilizadores querem acessar o sistema a partir de computadores

diferentes e localizados em pontos geograficamente distantes.Fatores de distribuição

A importância do negócio;A idade do sistema (quanto mais velho mais difícil);Estrutura do sistema (quanto mais modularizado, mais fácil);Política de procura do HW (substituição dos mainframes por

servidores).

Estrutura de sistemas legadosNa prática, as três camadas de um sistema

(Apresentação, Regras de negócio e Acesso a dados) estes estão inseridas em uma camada única, nos sistemas legados mais antigos; De acordo com as mais recentes metodologias de

desenvolvimento de sistemas, o ideal é a distribuição clara entre a interface do usuário (Apresentação), os serviços do sistema (Regras de negócio) e a gestão de dados do sistema (Acesso a dados).

Bibliografia SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson Education,

2007. 592 p. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e projeto

orientados a objetos e ao desenvolvimento iterativo. Porto Alegre: Bookman, 2007. 695 p.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Elsevier, 2006. 474 p.

ERIKSSON, Hans-Erik. UML toolkit. New York, NY: J. Wiley, 1998. 397 p. FOWLER, Martin. UML Essencial: um breve guia para a linguagem-padrão de

modelagem de objetos. 2. ed. Porto Alegre: Bookman, 2000. 169 p. QUATRANI, Terry. Visual modeling with Rational Rose 2000 and UML. Reading, MA:

Addison-Wesley, 2001. 256 p. ; il. JACOBSON, Ivar; BOOCH, Grady & RUMBAUGH, James. The unified software

development process. Reading, MA: Addison-Wesley, 1999. 463p. RUMBAUGH, James; et al. Modelagem e projetos baseados em objetos. 8. ed. Rio

de Janeiro: Campus, 1994. 652 p.