Mudança de software 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 sistemas A dinâmica de evolução de sistemas é o estudo dos processos de mudança do sistema Estudo 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 Manutenção Evolutiva 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

Manutenção Fatores de custos Software evolutivo 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 evolutivo Em 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ça Sã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 urgentemente Reparar 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ça A 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ça Avalia: o impacto na funcionalidade do produto. validade técnica da mudança consistência, uniformidade Aprova, rejeita, ou põe em espera; Segue um Cronograma.

Componentes de um pedido de mudança Descriçã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ça Custo; 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 legados Na 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.