Fragilidade do software - Software brittleness

Na programação de computadores e na engenharia de software , a fragilidade do software é o aumento da dificuldade em consertar softwares mais antigos que podem parecer confiáveis, mas falham seriamente quando apresentados a dados incomuns ou alterados de forma aparentemente secundária. A frase é derivada de analogias à fragilidade na usinagem .

Causas

Quando o software é novo, é muito maleável; ele pode ser formado para ser o que for desejado pelos implementadores. Mas, à medida que o software em um determinado projeto cresce cada vez mais e desenvolve uma base maior de usuários com longa experiência com o software, ele se torna cada vez menos maleável. Como um metal que foi endurecido pelo trabalho, o software se torna um sistema legado , quebradiço e incapaz de ser facilmente mantido sem quebrar todo o sistema.

Fragilidade no software pode ser causada por algoritmos que não funcionam bem para toda a gama de dados de entrada. Um bom exemplo é um algoritmo que permite a ocorrência de uma divisão por zero ou uma equação de ajuste de curva usada para extrapolar além dos dados aos quais foi ajustada. Outra causa da fragilidade é o uso de estruturas de dados que restringem valores. Isso foi comumente visto no final da década de 1990, quando as pessoas perceberam que seu software só tinha espaço para uma entrada de ano de 2 dígitos ; isso levou à atualização repentina de enormes quantidades de software frágil antes do ano 2000. Outra forma mais comum de fragilidade é nas interfaces gráficas do usuário que fazem suposições inválidas. Por exemplo, um usuário pode estar executando em uma tela de baixa resolução e o software abrirá uma janela muito grande para caber na tela . Outro problema comum é expresso quando um usuário usa um esquema de cores diferente do padrão , fazendo com que o texto seja renderizado na mesma cor do fundo, ou um usuário usa uma fonte diferente da padrão, que não caberá no espaço permitido e corta instruções e rótulos.

Muitas vezes, uma base de código antiga é simplesmente abandonada e um sistema totalmente novo (que se destina a ser livre de muitas das cargas do sistema legado) criado do zero, mas isso pode ser um processo caro e demorado.

Alguns exemplos e razões por trás da fragilidade do software:

  • Os usuários esperam uma interface de usuário relativamente constante ; uma vez que um recurso foi implementado e exposto aos usuários, é muito difícil convencê-los a aceitar mudanças importantes nesse recurso, mesmo que o recurso não tenha sido bem projetado ou a existência do recurso bloqueie o progresso posterior.
  • Uma grande quantidade de documentação pode descrever o comportamento atual e seria caro para alterar. Além disso, é essencialmente impossível recuperar todas as cópias da documentação existente, então os usuários provavelmente continuarão a consultar manuais obsoletos.
  • Os implementadores originais (que sabiam como as coisas realmente funcionavam) seguiram em frente e deixaram documentação insuficiente sobre o funcionamento interno do software. Muitos pequenos detalhes de implementação só foram compreendidos por meio das tradições orais da equipe de design, e muitos desses detalhes eventualmente são irremediavelmente perdidos, embora alguns possam ser redescobertos por meio da aplicação diligente (e cara) da arqueologia de software .
  • Provavelmente, patches foram lançados ao longo dos anos, mudando sutilmente o comportamento do software. Em muitos casos, esses patches, enquanto corrigem a falha evidente para a qual foram emitidos, introduzem outras falhas mais sutis no sistema. Se não forem detectadas pelo teste de regressão , essas falhas sutis tornam as alterações subsequentes no sistema mais difíceis.
  • Formas mais sutis de fragilidade comumente ocorrem em sistemas de inteligência artificial . Esses sistemas geralmente dependem de suposições significativas sobre os dados de entrada. Quando essas premissas não são atendidas - e, como não podem ser declaradas, esse pode ser facilmente o caso - o sistema responderá de maneiras totalmente imprevisíveis.
  • Os sistemas também podem ser frágeis se as dependências dos componentes forem muito rígidas . Um exemplo disso é visto nas dificuldades de transição para novas versões de dependências . Quando um componente espera que outro produza apenas um determinado intervalo de valores e esse intervalo muda, ele pode causar erros no sistema, durante a construção ou no tempo de execução .
  • Quando um sistema está em fase de manutenção, há menos recursos técnicos disponíveis para suportar as mudanças do que para um sistema que está em uma fase de desenvolvimento ou implementação do Ciclo de Vida de Desenvolvimento de Sistemas (SDLC).

Veja também

Referências

  • Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Gerenciamento de dependência orientado a aspectos . Addison Wesley Professional. ISBN 0-321-21976-7.
  • Anastasios Manessis, Adrian Hilton, Phil McLauchlan e Phil Palmer (2000). "Uma Estrutura Geométrica Estatística para Reconstrução de Modelos de Cenas" (PDF) . Conferência Britânica de Visão de Máquina .CS1 maint: vários nomes: lista de autores ( link )
  • Virginia Postrel (1999). "Fantasias de poder: o estranho apelo do bug do ano 2000 - problema de transição do ano 2000" . Razão . Arquivado do original em 10/09/2005 . Página visitada em 2008-07-25 .