Software Evolution
2
Objetivos
• Explicar porque a evolução é inevitável.
• Discutir a manutenção de software e custos associados.
• Descrever os processos envolvidos.
• Discutir uma estratégia de atualização de sistemas legados.
Evolução
• Alterações no software são inevitáveis:
– Novos requisitos surgem durante sua utilização;
– O ambiente (entorno) se altera (mercado / negócios);
– Erros devem ser corrigidos;
– Novos equipamentos são adicionados ao sistema;
– Performance e / ou confiabilidade podem necessitar melhora.
• Problema: implementação e gerência de alterações (Change Management).
4
Evolução: Importância
• Sistemas (SW) são ativos importantes: alto investimento.
• Para manter seu valor, devem ser atualizados, alterados e corrigidos.
• A maior parte do orçamento das empresas está alocada para a evolução dos sistemas e não para a criação de novos.
5
Modelo Espiral
6
Dinâmica da Evolução
• Estudo dos processos que regem as mudanças de sistemas.
• Lehman e Belady propuseram uma série de “leis” aplicáveis à sistemas em evolução (análise empírica).
• Mais observações do que “leis”, melhor aplicadas quanto maior a organização e maior o sistema em análise.
7
Leis de Lehman
Lei Descrição
Mudança contínua
Sistemas utilizados em operação (produção) obrigatoriamente sofrem alterações ou, progressivamente, tornam-se obsoletos.
Complexidade crescente
Com as alterações, a estrutura do sistema torna- se mais complexa. Recursos extras devem ser alocados em preservar e simplificar sua estrutura.
Versões
A evolução de um sistema é um processo auto regulado. Atributos como tamanho, tempo entre versões e número de erros reportados são aproximadamente invariantes para cada nova versão liberada.
Estabilidade organizacional
Durante o ciclo de vida de um sistema, sua taxa de evolução é aproximadamente constante e independente dos recursos alocados ao seu desenvolvimento.
8
Leis de Lehman (cont.)
Lei Descrição
Familiaridade
Durante o ciclo de vida de um sistema, as alterações incrementais em cada versão são aproximadamente constantes.
Crescimento contínuo
As funcionalidades de um sistema devem crescer continuamente para manter a satisfação do usuário.
Queda de qualidade
A qualidade de um sistema aparenta declínio a menos que este seja adaptado às alterações do seu ambiente operacional.
Feedback
Processos evolucionários devem incorporar sistemas de feedback automatizados a fim de obter melhorias significativas do sistema.
Leis de Lehman
• Aplicáveis (genericamente) a sistemas grandes e customizados - grandes organizações.
• Indeterminado como adotá-las para:
– produtos modulares; add-in’s;
– sistemas que incorporam um número
significativo de CotS (Components off the Shelf);
– pequenas organizações;
– sistemas pequenos / médios.
10
Manutenção
• Alteração de um programa / sistema após sua entrada em produção.
• Normalmente não envolve mudanças radicais à arquitetura do sistema.
• Implementação:
– correção de erros (corretiva);
– ajuste de componentes (adaptativa);
– adição de novos componentes (evolutiva).
11
Manutenção: Inevitável
• Requerimentos de sistema são propensos a alterações devido a mudanças do
ambiente. Um sistema em desenvolvimento pode não atender aos seus requisitos no momento da entrega.
• Sistemas devem sofrer manutenção a fim de manterem-se úteis.
• Sistemas são fortemente acoplados ao ambiente. Sua instalação altera o entorno, impactando seus requerimentos.
12
Manutenção: Tipos
• Reparação de falhas (corretiva):
– correção de deficiências visando atender requisitos.
• Adaptação ao ambiente (adaptativa):
– alteração para que o sistema opere em um ambiente diferente do proposto inicialmente (S.O., computador, etc.).
• Modificação ou adição de funcionalidade (evolutiva):
– satisfazer novos requisitos.
13
Manutenção: Esforço
14
Manutenção: Custos
• Usualmente maiores que o de
desenvolvimento (2x até 100x, variável segundo a aplicação).
• Dependentes de fatores diversos (técnicos e não técnicos).
• Aumentam com a manutenção:
– manutenção corrompe a estrutura, dificultando trabalhos posteriores
• Software “legado” pode ter custos de suporte elevado (ex.: linguagens “antigas”, compiladores, etc.).
Manutenção: Fatores de Custo
• Estabilidade:
– custos reduzidos com manutenção do grupo.
• Responsabilidade:
– sem responsabilidade pela manutenção, não há incentivo em criar visando mudanças futuras.
• Habilidade:
– grupo de manutenção é, em geral, inexperiente, e com conhecimento limitado do domínio.
• Idade e estrutura:
– com o envelhecimento do sistema, sua estrutura se degrada e torna-se difícil de entender e alterar.
16
Manutenção: Planejamento
• Preocupação com a análise de que partes do sistema podem causar problemas e quais tem alto custo de manutenção.
– a aprovação da alteração depende da possibilidade de mudança dos componentes afetados;
– implementar alterações degrada o sistema e reduz sua capacidade de manutenção;
– custos de manutenção dependem do número de alterações e o custo de alterações depende da capacidade de manutenção do sistema.
17
Manutenção: Planejamento
18
Alterações: Planejamento
• Predizer a quantidade de alterações demanda entendimento das relações entre sistema e ambiente.
• Sistemas fortemente acoplados necessitam alterações sempre que o ambiente mudar.
• Fatores de influência:
– quantidade e complexidade das interfaces;
– quantidade alterações “herdadas” por / de sub- sistemas.
– processos de negócio onde o sistema é utilizado.
19
Métricas de Complexidade
• Planejamento pode ser feito estudando a complexidade dos componentes.
• Estatística: maior parte do esforço sobre um número pequeno de componentes.
• Dependência:
– complexidade da estrutura de controle;
– complexidade da estrutura de dados;
– objetos, métodos (procedimentos) e modularidade.
20
Métricas de Processo
• Medidas de processos podem ser utilizadas na analise de manutenção
– quantidade de manutenções corretivas;
– tempo médio de análise de impacto;
– tempo médio de implementação;
– Número de solicitações pendentes.
• Se qualquer desses parâmetros aumentar, isso pode indicar um declínio da
possibilidade de manutenção.
Processo Evolutivo
• Dependente de:
– Tipo de software em manutenção;
– Processo evolutivo utilizado
– Habilidade, conhecimento e experiência das pessoas envolvidas.
• Evolução de sistemas depende de propostas de alteração.
22
Processo Evolutivo
23
Solicitações Emergenciais
• Alterações urgentes significam uma implementação sem seguir todos os passos do processo.
– correção de falha grave;
– alterações no ambiente ocasionado efeitos inesperados;
– alterações de negócio necessitam uma resposta rápida.
24
Reengenharia
• Reestruturar ou reescrever parte ou a totalidade de um sistema sem alterar sua funcionalidade.
• Aplicável quando pouco (não todos) os sub- sistemas requerem manutenção freqüente.
• Esforço em tornar a manutenção mais fácil.
Pode ser necessário reestruturar / documentar o (novo) sistema.
25
Reengenharia: Vantagens
• Risco reduzido:
– alto risco no desenvolvimento de novos sistemas como problemas de codificação, pessoal, especificação, etc.
• Custo reduzido:
– custo de reengenharia é normalmente muito menor que o custo de desenvolvimento.
26
Reengenharia: Processo
Reengenharia: Processo
• Análise do Código Fonte:
– conversão para uma nova linguagem / reestruturação do código.
• Engenharia Reversa:
– análise da codificação e entendimento da lógica do programa.
• Melhoria da estrutura:
– reestruturação para compreensão (lógica e código).
28
Reengenharia: Processo (cont.)
• Modularização:
– reorganização da estrutura do programa.
• Reengenharia de dados:
– limpeza e reestruturação dos dados.
29
Reengenharia: Fatores de Custo
• Qualidade do software sob revisão.
• Suporte das ferramentas de reengenharia.
• Extensão da conversão de dados necessária.
• Disponibilidade de especialistas para a reengenharia.
– potencial problema para sistemas antigos.
30
Sistemas Legados: Evolução
• Organizações baseadas em sistemas legados devem definir uma estratégia de evolução:
– desabilitar o sistema e redesenhar processos de forma a que não seja mais necessário;
– continuar com a manutenção do sistema;
– reengenharia do sistema;
– substituição.
• A estratégia depende da qualidade do sistema e sua criticidade.
31
Sistemas Legados: Categorias
• Baixa qualidade, baixo valor de negócio:
– sistemas devem ser substituídos.
• Baixa qualidade, alto valor negócio:
– reengenharia ou substituição.
32
Sistemas Legados: Categorias (cont.)
• Alta qualidade, baixo valor de negócio:
– CotS, eliminação ou manutenção.
• Alta qualidade, alto valor de negócio:
– continuar operação.
Análise: Valor p/ Negócio
• Fundamental analisar de diferentes pontos de vista:
– usuário final;
– clientes;
– gerentes da linha;
– gerentes de TI;
– Gerentes seniores.
• Entreviste diferentes stakeholders e analise os resultados.
34
Análise: Qualidade do Sistema
• Processos de negócio:
– Quão bem os processos suportam as metas?
• Ambiente:
– Quão efetivo / eficiente é o ambiente e qual o custo de mantê-lo?
• Aplicação
– Qual a qualidade da aplicação?
35
Análise: Processos de Negócio
• Analise os processos como um stakeholder:
– existe um modelo de processo e ele é seguido?
– diferentes setores da organização usam diferentes processos para o mesmo fim?
– como o processo foi adaptado?
– como é a relação com outros processos e são realmente necessários?
– O processo é suportado pela aplicação legada?
36
Análise: Ambiente
Fator Questionamentos
Provedor
Ainda existe? Financeiramente estável e duradouro? Se não existe, algum outro mantem o sistema?
Taxa de Falhas O HW possui histórico de alta taxa de falhas? O SW falha e força reinicialização do sistema?
Idade
Quão velho é o HW e o SW? Quanto mais velhos, mais obsoletos. Podem funcionar corretamente, mas devem existir grandes vantagens (financeira e de negócio) em um upgrade.
Performance A performance é adequada? Problemas de performance tem impacto significativo?
37
Análise: Ambiente (cont.)
Fator Questionamentos
Requisitos de Suporte
Que tipo de suporte local é necessário (HW e SW)? Se os custos são altos, substituição é a opção.
Custos de Manutenção
Qual o custo de manutenção de HW e licensiamento de SW? HW antigo e a renovação anual de SW podem ter um custo alto.
Inter- operabilidade
Os problemas propagam para outros sistemas?
SW de suporte (ex.: compiladores) são compatíveis com o S.O.? Emulação é necessária?
38
Análise: Aplicação
Fator Questionamentos
Compreensão
Quão dificil é compreender a lógica e estrutura (código fonte) do sistema? Quão complexa é a estrutura de controle? Váriáveis tem nomes mneumonicos associados à sua função?
Documentação Qual a documentação disponível? É completa, consistente e atualizada?
Dados
Existe uma modelagem de dados para o sistema? Qual a extensão de dados duplicados?
Dados são consistentes e atualizados?
Performance Performance é adequada? Problemas de performance tem efeito significativo?
Análise: Aplicação (cont.)
Fator Questionamentos
Linguagem de Programação
Existe disponibilidade de compiladores modernos / atualizados? A linguagem ainda é utilizada?
Gerência de configuração
Todas as versões de todos os componentes são gerenciados por um sistema de gerência de configuração? Existe descritivo dos componentes em uso?
Dados de Teste
Existem dados de teste? Existem registros dos testes de regressão executados na adição de funcionalidades ao sistema?
Habilidades Técnicas
Existe pessoal treinado na manutenção do sistema? Esse número é limitado?
40
Sistema: Medidas
• Colete métricas (quantitativas) que indiquem a qualidade do sistema:
– Quantidade de solicitações de alteração;
– Quantidade de diferentes interfaces do sistema;
– Volume de dados utilizado pelo sistema.
41
• O desenvolvimento e a evolução de sistemas devem ser um único processo interativo.
• As “leis” de Lehman servem de guias na análise do processo evolutivo.
• Manutenção:
– corretiva – adaptativa – evolutiva
• Para sistemas customizáveis, o custo da manutenção excede o de desenvolvimento.
Pontos Chave
42
• O processo evolutivo é direcionado pelas requisições de alteração (stakeholders).
• Reengenharia de SW foca em reestruturar e documentar de maneira a facilitar a manutenção do sistema.
• O valor p/ o negócio e a qualidade de um sistema legado são os fatores de orientação da estratégia evolutiva de um sistema legado.
