Gestão e Evolução de Software: Manutenção e Sistemas Legados

Leis de Evolução de Software de Lehman

Evolução Inevitável: A primeira lei estabelece que a manutenção do sistema é um processo inevitável. À medida que o ambiente do sistema muda, novos requisitos surgem e o sistema deve ser modificado. Quando o sistema modificado é novamente introduzido no ambiente, ocorrem mais mudanças ambientais e, assim, o ciclo de evolução reinicia.

Degradação da Estrutura: A segunda lei estabelece que, quando o sistema é alterado, sua estrutura é degradada. A única maneira de evitar isso é investir em manutenção preventiva, na qual horas são dedicadas ao aprimoramento da estrutura do software sem adicionar novas funcionalidades. Obviamente, isso implica custos adicionais, além dos necessários para implementar as mudanças no sistema.

Dinâmica: A Terceira Lei de Lehman sugere que os sistemas de grande porte têm dinâmica própria definida ainda nos estágios iniciais do processo de desenvolvimento. Isso determina as fortes tendências de manutenção do sistema e limita o número de possíveis mudanças. Lehman e Belady sugerem que essa lei é uma consequência de fatores estruturais que influenciam e restringem as mudanças do sistema, bem como de fatores organizacionais que afetam a evolução do sistema.

Tipos de Manutenção de Software

A manutenção de software pode ser classificada em diferentes tipos, cada um com suas características e objetivos específicos:

• Manutenção Corretiva

  A correção de erros de codificação é normalmente barata; os erros de projeto são mais caros, pois pode ser necessário o reprojeto do sistema existente.

• Manutenção Adaptativa

  Esse tipo de manutenção é necessária quando algum aspecto do ambiente do sistema, como o hardware, plataforma do sistema operacional ou outro software de apoio, muda. O sistema da aplicação deve ser modificado para lidar com essas mudanças de ambiente.

• Manutenção Evolutiva

  Esse tipo de manutenção é necessária quando os requisitos do sistema mudam em resposta às mudanças organizacionais ou de negócios. A escala de mudanças necessárias para o software é muito maior do que em outros tipos de manutenção.

Previsão de Manutenção e Solicitações de Mudança

Os gerentes detestam surpresas, especialmente se elas resultam em altos custos inesperados.

Fatores Relacionados à Previsão

• Se uma mudança de sistema deve ser aceita, isso depende, de certa maneira, da facilidade de manutenção dos componentes do sistema afetados por essa mudança.
• A implementação de mudanças de sistema tende a degradar sua estrutura, reduzindo, assim, sua facilidade de manutenção.
• Os custos de manutenção dependem do número de mudanças e os custos de implementação de mudanças dependem da facilidade de manutenção dos componentes do sistema.

A previsão do número de solicitações de mudança para um sistema requer uma compreensão do relacionamento entre o sistema e seu ambiente externo. Para isso, deve-se avaliar:

• O número e a complexidade das interfaces do sistema. Quanto maior o número de interfaces e quanto mais complexas, mais prováveis serão as demandas por mudanças.
• O número de requisitos do sistema inerentemente voláteis. Os requisitos que refletem políticas e procedimentos organizacionais são provavelmente mais voláteis do que os requisitos baseados em características de domínio estáveis.
• Os processos de negócios nos quais o sistema é usado. À medida que os processos de negócios evoluem, eles geram solicitações de mudanças. Quanto mais os processos de negócio usam o sistema, mais demandas por mudanças ocorrem.

Métricas para Avaliar a Facilidade de Manutenção

Exemplos de métricas de processo que podem ser usadas para avaliar a facilidade de manutenção são:

• Número de solicitações de manutenção corretiva. Um aumento no número de relatórios de falhas pode indicar que mais erros estão sendo introduzidos no programa do que reparados durante o processo de manutenção, o que pode indicar um declínio na facilidade de manutenção.
• Tempo médio necessário para análise de impactos. Isso reflete o número de componentes afetados pela solicitação de mudança. Se esse tempo aumentar, significa que cada vez mais componentes estão sendo afetados, e a facilidade de manutenção está diminuindo.
• Tempo médio para implementar uma solicitação de mudança. Não é igual ao tempo para análise de impactos, embora haja uma correlação. Essa é a quantidade de tempo necessária para realmente modificar o sistema e sua documentação após a avaliação de quais componentes serão afetados. Um aumento no tempo necessário para implementar uma mudança indica um declínio na facilidade de manutenção.
• Número de solicitações pendentes de mudança. Um aumento desse número com o tempo pode indicar declínio na facilidade de manutenção.

Solicitações de mudanças muitas vezes estão relacionadas a problemas do sistema que precisam ser resolvidas urgentemente. Essas mudanças urgentes podem surgir por três razões:

• Ocorreu um defeito grave no sistema que deve ser reparado para permitir a continuidade da operação normal.
• Efeitos inesperados de mudanças no ambiente do sistema operacional que interrompem a operação normal, ou mudanças imprevistas na empresa que utiliza o sistema, como uma emergência provocada por novos concorrentes ou a introdução de uma nova legislação.

Reengenharia de Software: Riscos, Custos e Processos

A realização de reengenharia de um sistema de software tem duas vantagens fundamentais sobre as abordagens mais radicais da evolução de sistema:

Vantagens da Reengenharia

• Risco Reduzido

  Existe alto risco no redesenvolvimento de um software crítico para negócios. Podem ser cometidos erros nas especificações do sistema ou podem surgir problemas de desenvolvimento. Atrasos na introdução do novo software podem significar a perda de negócios e acarretar custos extras.

• Custo Reduzido

  O custo da reengenharia é significativamente menor do que o custo de desenvolvimento de um novo software.

Atividades do Processo de Reengenharia

As atividades nesse processo de reengenharia são:

• Conversão de Código-Fonte. O programa é convertido de uma linguagem de programação antiga para uma versão mais moderna da mesma linguagem ou para uma linguagem diferente.
• Engenharia Reversa. O programa é analisado e são extraídas informações dele. Isso ajuda a documentar sua organização e funcionalidade.
• Aprimoramento da Estrutura do Programa. A estrutura de controle do programa é analisada e modificada para facilitar a leitura e a compreensão.
• Modularização do Programa. As partes relacionadas do programa são agrupadas e, quando apropriado, as redundâncias são removidas. Em alguns casos, esse estágio pode envolver transformações de arquitetura, em que um sistema centralizado, planejado para um único computador, é modificado para operar em uma plataforma distribuída.
• Reengenharia de Dados. Os dados processados são alterados para refletir as mudanças do programa.

Fatores que Afetam os Custos da Reengenharia

Independentemente da extensão da reengenharia, os principais fatores que afetam os custos dela são:

• A qualidade do software que deve passar pela reengenharia. Quanto menor a qualidade do software e de sua documentação associada (se existir), maiores serão os custos de reengenharia.
• O apoio de ferramentas disponíveis para reengenharia. Normalmente, não é adequado em termos de custo fazer a reengenharia de um sistema de software, a menos que se usem ferramentas CASE para automatizar a maioria das mudanças.
• Extensão da Conversão de Dados. Se a reengenharia exigir que grandes volumes de dados sejam convertidos, o custo do processo aumentará significativamente.
• A disponibilidade de pessoal especializado. Se o pessoal responsável pela manutenção do sistema puder ser envolvido no processo de reengenharia, os custos aumentarão, pois os engenheiros de sistema responsáveis pela reengenharia terão de dedicar muito tempo à compreensão do sistema.

A principal desvantagem da reengenharia de software é que existem limitações práticas referentes a quanto um sistema pode ser aprimorado.

Sistemas Legados: Estratégias de Gestão e Avaliação

As organizações com um orçamento limitado para manter e atualizar seus sistemas legados precisam decidir como obter o melhor retorno sobre seu investimento. Existem quatro opções de estratégia:

• Descartar o Sistema Completamente

  Essa opção deve ser escolhida quando o sistema não está mais contribuindo eficientemente para os processos de negócio.

• Manter o Sistema sem Alterações

  Essa opção deve ser escolhida quando o sistema ainda é necessário, mas bastante estável, e os usuários do sistema têm relativamente poucas solicitações de mudança.

• Reengenharia do Sistema

  Essa opção deve ser a escolhida quando a qualidade do sistema foi degradada por mudanças regulares e quando essas mudanças ainda são necessárias.

• Substituir o Sistema

  Essa opção deve ser escolhida quando outros fatores, como um novo hardware, impossibilitam que o sistema antigo continue em operação, ou quando sistemas comerciais permitem que um novo sistema seja desenvolvido a um custo razoável.

Categorias de Sistemas Legados por Qualidade e Valor

Os sistemas legados podem ser categorizados com base em sua qualidade técnica e valor de mercado:

• Baixa Qualidade, Baixo Valor de Mercado

  A manutenção desses sistemas em operação será dispendiosa, e a taxa de retorno para o negócio será bastante pequena. Esses sistemas devem ser descartados.

• Baixa Qualidade, Alto Valor de Mercado

  Esses sistemas contribuem de maneira importante para a empresa e não podem ser descartados. Contudo, sua baixa qualidade significa que é dispendioso mantê-los. Esses sistemas devem sofrer reengenharia para aprimorar sua qualidade ou serem substituídos caso um sistema comercial adequado esteja disponível.

• Alta Qualidade, Baixo Valor de Mercado

  Esses sistemas são os que não contribuem mais para a empresa, mas sua manutenção não é dispendiosa. Não vale a pena substituí-los, de modo que as manutenções normais podem prosseguir, desde que nenhuma mudança dispendiosa seja necessária e o hardware do sistema esteja operacional. Se mudanças dispendiosas forem necessárias, os sistemas deverão ser descartados.

• Alta Qualidade, Alto Valor de Mercado

  Esses sistemas devem ser mantidos em operação, mas sua qualidade significa que não se deve investir em transformação ou substituição. A manutenção normal deve prosseguir.

Avaliação do Valor de Mercado de um Sistema

Para avaliar o valor de mercado de um sistema, deve-se identificar os stakeholders do sistema, como os usuários finais e seus gerentes, e formular uma série de questões sobre o sistema. Existem quatro questões básicas que devem ser discutidas:

• Uso do Sistema. Se os sistemas são usados ocasionalmente ou por um pequeno número de pessoas, podem ter um baixo valor de mercado. Um sistema legado pode ter sido desenvolvido para atender a uma necessidade da empresa que mudou ou que agora pode ser atendida mais eficientemente de outras maneiras.
• Processos de Negócio Apoiados. Quando um sistema é introduzido, podem ser projetados processos de negócio para explorar esse sistema. Contudo, as mudanças nesses processos podem ser impossíveis, pois o sistema legado não pode ser adaptado. Portanto, um sistema pode ter baixo valor de mercado porque impede a introdução de novos processos.
• A Confiabilidade do Sistema. A confiabilidade do sistema não é apenas um problema técnico, mas também um problema de negócios. Se um sistema não for confiável e os problemas afetarem diretamente os clientes ou exigirem que pessoas sejam desviadas de suas tarefas para resolver esses problemas, o sistema tem baixo valor de mercado.
• As Saídas do Sistema. A questão fundamental aqui é a importância das saídas do sistema para o funcionamento bem-sucedido da empresa. Se a empresa depende dessas saídas, o sistema tem um alto valor de mercado. Por outro lado, se essas saídas puderem ser facilmente geradas de alguma outra maneira ou se o sistema produzir saídas raramente usadas, seu valor de mercado pode ser baixo.

Avaliação da Qualidade Técnica de um Sistema

Para avaliar a qualidade técnica de um sistema de aplicação, deve-se avaliar vários fatores relacionados principalmente à confiabilidade do sistema, às dificuldades de manutenção do sistema e à documentação do sistema. Pode-se também coletar dados quantitativos que ajudarão a julgar a qualidade do sistema. Exemplos de dados quantitativos que podem ser coletados são:

• O número de solicitações de mudança no sistema. As mudanças tendem a corromper a estrutura do sistema e tornam as mudanças futuras mais difíceis. Quanto mais alto for esse valor, mais baixa será a qualidade do sistema.
• O número de interfaces com o usuário. Este é um fator importante em sistemas baseados em formulários, em que cada formulário pode ser considerado uma interface separada com o usuário. Quanto mais interfaces, maior é a probabilidade de inconsistências e redundâncias.
• O volume de dados usados pelo sistema. Quanto maior o volume de dados (número de arquivos, tamanho do banco de dados, etc.), mais complexo será o sistema.

Embora esses dados sejam muitas vezes úteis, coletá-los pode ser muito dispendioso e, portanto, impraticável. Além disso, não existem valores absolutos a serem usados. A idade e o tamanho do sistema devem ser levados em conta nos julgamentos de qualidade baseados nessas medições.