Não há balas de prata: a essência e os acidentes da engenharia de software

Entre todos os monstros que residem em nossos pesadelos, nenhum é mais aterrorizante do que o lobisomem, pois se transforma de uma forma familiar em algo horroroso. E para matá-lo, segundo o folclore, precisamos utilizar uma bala de prata.

Em projetos de software, as coisas acontecem de uma forma bem parecida. Os projetos começam bem, cumprindo o orçamento, prazo e satisfazendo o cliente, até que em determinado momento a situação sai de controle e as pessoas ficam desesperadas a procura de uma “bala de prata” para resolver todos os problemas do projeto, ou seja, matar o lobisomem.
Vamos agora apresentar as dificuldades da Engenharia de Software que estão a espera de uma “bala de prata”. Essas dificuldades podem ser divididas em 2 grupos, dificuldades de “essência” e “acidentes”.

As dificuldades de “essência” são caracterizadas pelas seguintes propriedades:

  • Complexidade: conforme o software cresce, a complexidade inerente a ele também cresce. Porém, o crescimento da complexidade não é linear em relação ao crescimento do software.
  • Conformidade: o software deve adaptar-se a outras interfaces, muitas vezes definidas arbitrariamente por instituições ou por outros sistemas. Adaptar-se a uma interface externa traz consigo complexidade.
  • Mutabilidade: diferentemente de carros, softwares não são modificados apenas na fase de design, sofrem constantes mudanças durante todo o seu processo de desenvolvimento.
  • Invisibilidade: software é invisível, o que torna a constituição de modelos muito importante a fim de visualizarmos dependências, sequenciamento, fluxo de controle etc.

Os “acidentes” são os percalços que afetam a produção de software mas que, por natureza, não são inerentes ao desenvolvimento de software. Grande parte destas dificuldades foram resolvidas no passado com linguagens de alto nível, time-sharing e ambientes de desenvolvimento unificados.

Esperanças pela bala de prata

Vamos considerar alguns avanços técnicos como potenciais balas de prata, tais como: avanços da Ada e de outras linguagens de alto nível, programação orientada a objetos, inteligência artificial, sistemas especialistas, programação “automática”, programação visual, verificação de programa, ambientes e ferramentas e estações de trabalho.

Que problemas esses avanços resolvem? Dificuldades de “essência” ou “acidentais”? Eles oferecem avanços revolucionários ou incrementam algum avanço?

 

Ataques promissores contra as dificuldades de essência

  • Comprar versus construir: softwares adquiridos podem ser mais baratos, são mais documentados e possuem suporte. Por outro lado, softwares construídos em casa são mais adaptados a realidade da organização.
  • Refinamento de requisitos e rápida prototipação: a parte mais difícil do desenvolvimento de um software é definir o que deve ser feito. Para tal é imprensidivel que os requisitos sejam levantados de forma mais espeficica, ou seja, mais refinada. Algumas técnicas podem ser utilizadas para tornar o software mais aderente as necessidades do cliente, como o desenvolvimento incremental e a prototipação das principais interfaces do sistema, possibilitando ao cliente aferir sobre a consistência e usabilidade do sistema.
  • Grandes projetistas: são deles as estruturas de software mais rápidas, enxutas, simples, limpas e produzidas com menos esforço. Esses profissionais são muito raros no mercado.

Este é um resumo do artigo “No Silver Bullet”.