Gerenciar os processos de mudanças em sistemas de software

(1)

Mudanças em Software

Slide 1

Prof. Giuliano Prado

Mudança em Software

l

Gerenciar os processos de mudanças em sistemas de software

software

(2)

Objetivos

l

Explicar as diferentes estratégias para modificações em sistemas de software:

• Manutenção de Software

• Transformação de Arquitetura (Evolução Arquitetural)

• Reengenharia de Software

Slide 3

• Reengenharia de Software

l

Explicar os princípios da manutenção de software

l

Descrever a transformação de sistemas legados arquiteturas centralizadas para arquiteturas

distribuídas

Tópicos

l

Dinâmica da Evolução de Programas

l

Manutenção de Software

l

Evolução da Arquitetura

(3)

Mudança de Software

l

Mudança de Software é inevitável

• Novos requisitos surgem quando o software é utilizado

• O ambiente de negócios se modifica

• Erros devem ser reparados

• Novos equipamentos devem ser “acomodados”

Slide 5

• Novos equipamentos devem ser “acomodados”

• O desempenho ou confiança devem ser melhorados

l

O problema chave para as organizações é implementar e gerenciar mudanças para seus sistemas legados

Estratégias de Mudança em Software

l

Manutenção de Software

• Mudanças são realizadas em resposta a mudanças de requisitos mas a estrutura de software fundamental se mantém

l

Transformação Arquitetural

• A arquitetura do sistema é modificada geralmente de uma arquitetura

• A arquitetura do sistema é modificada geralmente de uma arquitetura centralizada para uma distribuída

l

Reengenharia de Software

• Nenhuma funcionalidade nova é adicionada ao sistema, mas este é reestruturado e reorganizado para facilitar futuras modificações

l

Estas estratégias podem ser aplicadas em separado ou

juntas

(4)

l

Dinâmica da Evolução de Programas é o estudo dos processos de mudanças em sistemas de software

l

Após estudos empíricos, Lehman e Belady propuseram um conjunto de leis referentes as mudanças nos

sistemas

Dinâmica da Evolução de Programas

Slide 7

sistemas

l

Talvez sejam hipóteses (observações), aos invés de leis.

São aplicáveis para grandes sistemas desenvolvidos por grandes organizações. Talvez menos aplicáveis em

outros casos.

Aplicabilidade das leis de Lehman

l

Ainda não foram estabelecidas

l

Elas geralmente são aplicáveis para grandes sistemas desenvolvidos por grandes organizações

l

Ainda não está claro como as mesmas deveriam ser modificadas para

modificadas para

• Pacotes de Produtos de Software

• Sistemas que incorporam um significativo número de componentes COTS (Commercial off-the-shelf - Sistemas Comerciais de Prateleira)

• Pequenas Organizações

• Sistemas de Médio Porte

(5)

l

Modificação de um programa após este ter sido colocado em uso

l

Manutenção normalmente não envolve maiores modificações na arquitetura do sistema

Manutenção de Software

Slide 9

modificações na arquitetura do sistema

l

Modificações são implementadas pela

modificação de componentes existentes e adição de novos componentes para o sistema

l

Os requisitos de sistema normalmente são modificados enquanto o sistema está sendo desenvolvido porque o ambiente esta mudando. Então um sistema entrege não irá contemplar seus requisitos.

l

Sistemas são altamente acoplados com seu ambiente.

Manutenção é inevitável

l

Sistemas são altamente acoplados com seu ambiente.

Quando um sistema é instalado em um ambiente, este modifica o ambiente e então modifica os requisitos do sistema.

l

Sistemas DEVEM ser mantidos para continuarem úteis

em um ambiente

(6)

l

Manutenção para reparos de falhas de software (Corretiva)

• Modificar o sistema para corrigir deficiências no intuito de contemplar requisitos

l

Manutenção para adaptar o software a um ambiente operacional diferente (Adaptativa)

Tipos de manutenção

Slide 11

operacional diferente (Adaptativa)

• Modificar o sistema para que este opere em um ambiente diferente (computador, sistema operacional, etc.) da sua implementação inicial

l

Manutenção para adicionar ou modificar funcionalidades do sistema (Perfectiva)

• Modificar o sistema para satisfazer novos requisitos

l

Ainda existiria a manutenção para prevenir possíveis erros que ainda não aconteceram (Preventiva)

Distribuição de esforço de

manutenção

(7)

Modelo Espiral de Manutenção

Slide 13

l

Normalmente maior do que os custos de

desenvolvimento (2 a 100 vezes, dependendo da aplicação)

l

Afetada por fatores técnicos e não-técnicos Aumenta a medida que o software entra em

Custos de Manutenção

l

Aumenta a medida que o software entra em

manutenção. Manutenção corrompe a estrutura do

software, tornando mais difícil manutenções posteriores.

l

Software antigo pode ter altos custos de suporte

(por exemplo: linguagens e compiladores antigos.)

(8)

Custos de Desenvolvimento e Manutenção

Slide 15

Quanto maior o esforço empregado para tornar o software “manutenível” , menor o custo da

manutenção.

l

Estabilidade da Equipe

• Custos de manutenção são reduzidos se a mesma equipe de desenvolvimento está envolvida com a manutenção

l

Responsabilidade Contratual

• Os desenvolvedores de um sistema podem não ter nenhuma responsabilidade de contrato para a manutenção de um sistema, sendo assim, pode não existir nenhum incentivo de projeto para

Fatores de Custos de Manutenção

sendo assim, pode não existir nenhum incentivo de projeto para mudanças futuras.

l

Habilidade da Equipe

• Equipe de manutenção freqüentemente não possuem experiência e têm limitado conhecimento do domínio

l

Idade e Estrutura do Programa

(9)

Software Evolucionário

l

Ao invés de pensar que desenvolvimento e

manutenção são duas fases separadas, software evolucionário é projetado para que seja

continuamente evoluído em todo o seu tempo de

Slide 17

vida

O Processo de Manutenção

Processo real

(10)

O Processo de Manutenção

Processo ideal

Slide 19

Pedidos de Mudança

l

Pedidos de mudança são mudanças propostas por usuários do sistema, da gerência ou dos clientes

l

Em princípio, todos pedidos de mudança deveriam ser cuidadosamente analisados como parte do processo de manutenção e, então, implementados

manutenção e, então, implementados

l

Na prática, alguns pedidos de mudança devem ser implementados com urgência, pelas seguintes razões:

• Reparo de uma falha

• Mudanças no Ambiente do Sistema

• Mudanças nos negócios que não foram previstas (requisitadas com

(11)

Implementação da Mudança

Slide 21

Reparo de Emergência

(12)

Previsão de Manutenção

l

Previsão de Manutenção está preocupada com estimar quais partes do sistema podem causar problemas que tenham altos custos de

manutenção

Slide 23

• Aceitação de mudança depende da manutenibilidade dos componentes afetados pela mudança

• Implementar as mudanças degrada o sistema e reduz sua manutenibilidade

• Custos de manutenção dependem do número de mudanças e custos das mudanças dependem da facilidade de manutenção

Previsão de Manutenção

(13)

Previsão da Mudança

l

Previsão do número de pedidos de mudanças e o entendimento dos relacionamentos entre um sistema e seu ambiente

l

Sistemas altamente acoplados requerem

mudanças toda vez que o ambiente é modificado

Slide 25

mudanças toda vez que o ambiente é modificado

l

Fatores que influenciam este relacionamento são:

• Número e Complexidade de Interfaces do Sistema

• Número de requisitos de sistema inerentemente voláteis

• Os processos de negócio onde o sistema é usado

Métricas de Complexidade

l

Previsões de manutenibilidade podem ser feitas por

avaliação da complexidade dos componentes do sistema

l

Estudos mostraram que a maior parte dos esforços de manutenção é gasto com um número relativamente pequeno de componentes de sistema

pequeno de componentes de sistema

l

Complexidade depende de:

• Complexidade das estruturas de controle

• Complexidade das estruturas de dados

• Tamanho dos procedimentos e módulos

(14)

Métricas do Processo

l

Medidas de Processo podem ser usadas para avaliar manutenibilidade

• Número de pedidos de manutenção corretiva

• Tempo médio necessário para análise de impacto

• Tempo médio tomado para implementas um pedido de

Slide 27

• Tempo médio tomado para implementas um pedido de mudança

• Número de pedidos de modificação importantes

l

Se qualquer um destes (ou todos) aumentar, isto pode indicar um declínio na manutenibilidade

Evolução da Arquitetura

l

Existe a necessidade de converter muitos

sistemas legados de arquiteturas centralizadas para arquiteturas cliente-servidor (distribuídas)

l

Fatores de Mudança

• Custos de Hardware. Servidores são mais baratos do que

• Custos de Hardware. Servidores são mais baratos do que mainframes

• Expectativas quanto à interface com o usuário. Usuários esperam interfaces gráficas

• Acesso distribuído aos sistemas. Usuários desejam acessar o sistema de diferentes computadores, geograficamente

separados

(15)

Estrutura de Sistemas Legados

l

Idealmente, para distribuição, deveria existir uma clara separação entre a interface com o usuário, os serviços do sistema e a gerência dos dados do sistema

Slide 29

l

Ná prática, estes são usualmente misturados com os sitemas legados antigos

Estrutura de Sistemas Legados

Serviços

Interface com o Usuário Interface com o Usuário

Serviços

Banco de Dados

Modelo ideal para distribuição Sistemas legados reais Banco de Dados

Serviços

(16)

Distribuição do Sistema Legado

Application services Database

Desktop PC clients runnin g application

Middleware layer (wrapper) Legacy system

Slide 31

User interface

Character terminals

Legacy system

Opções de Distribuição

l

Quanto mais distribuído é o servidor para o cliente, mais altos são os custos de evolução da arquitetura

l

O modelo de distribuição mais simplista é a distribuição de Interface com o Usuário (IU) onde somente a

interface com o usuário é implementada no servidor interface com o usuário é implementada no servidor

l

A opção mais complexa é onde o servidor simplesmente

fornece a gerência de dados e os serviços de aplicação

são implementados no cliente

(17)

Distribuição da Interface com o Usuário

l

Distribuição da IU utiliza como vantagem o poder de processamento local dos PCs para

implementar a interface gráfica

l

Onde existe uma clara separação entre a IU e a

Slide 33

l

Onde existe uma clara separação entre a IU e a aplicação, então o sistema legado pode ser

modificado para implementar a distribuição da IU

l