Resumo

No artigo “No Silver Bullet”, Brooks aborda sobre problemas que se podem encontrar nos
processos de Engenharia de Software.
Na introdução Brooks faz uma comparação entre o Software e o Lobisomem, onde segundo o
autor, de todos monstros que preenchem os pesadêlos nosso folclore nenhum deles nos aterrorisa
mais que os lobisomens, porque inesperadamente eles transformam-se do familiar ao horrível,
onde para acalmá-los procuram-se balas de prata que o fazem magicamente.
O Software, portanto,similarmente ao lobisomem, ele é normalmente inocente e honesto, mas
capaz de se tornar um monstro de prazos deficientes, orçamentos estourados e produtos falhados.
Surgem então súplicas desesperadas por uma bala de prata, ou seja, algo que faça os custos de
software cair tão rapidamente quanto os custos de hardware de computador.
Brooks defende que não há balas de prata em vista e que primeiro, devemos observar que a
anomalia não é que o progresso do software seja muito lento mas que o progresso do hardware de
computador seja muito rápido; Segundo, para ver que taxa de progresso podemos esperar na
tecnologia de software, devemos examinar as suas dificuldades. Citando Aristóteles, Brooks divide
essas dificuldades em essenciais(dificuldades inerentes à natureza do software) e acidentais
(dificuldades que afetam a produção do software mas não inerentes à sua natureza).
Brooks acredita que a parte mais difícil na construção do software é a especificação, o projeto e o
teste desta construção conceitual, e não o trabalho de representá-lo e testar a fidelidade da
representação; e que a construção de um software será sempre difícil, não havendo nenhuma bala
de prata inerente.
As principais dificuldades essenciais são:
- Complexidade: As entidades de software talvez sejam mais complexas pelo seu tamanho que
qualquer outra construção humana porque não têm duas partes similares. Neste aspecto, sistemas
de software diferem profundamente de computadores, prédios ou automóveis, onde elementos
repetidos abundam. A complexidade do software é uma propriedade essencial, não acidental. Por
isso, as descrições de uma entidade de software que abstraem sua complexidade sempre abstraem
sua essência. Muitos problemas na sua construção derivam desta complexidade e do seu
crescimento não linear.Da complexidade surge dificuldade de comunicação entre os membros da
equipe, o que leva a falhas no produto, custos exacerbados e atrasos nos prazos estabelecidos. Da
complexidade surge dificuldade de enumerar, muito menos entender todos os estados do programa
e a origem da deficiência. Da complexidade da função vem dificuldade de chamar a função, o que
torna os programas difíceis de usar. Da complexidade de estrutura surge dificuldade de estender
os programas com novas funções sem criar efeitos colaterais. Da complexidade de estrutura
surgem estados invisíveis que constituem furos de segurança. Não somente problemas técnicos,
mas também de gerência surgem da complexidade. Isto dificulta a visão global, além de impedir a
integridade conceitual. Torna difícil encontrar e controlar todos os pontos deficientes. Cria uma
carga tremenda de aprendizagem e entendimento, o que torna a rotatividade de pessoal um
desastre.
- Conformidade: Em muitos casos, o software deve se adaptar porque é novo e entrou em cena
recentemente. Em outros, porque é percebido como o mais adaptável. Mas, em todos os casos,
grande parte da complexidade surge da conformidade com outras interfaces; esta complexidade
não pode ser simplificada por qualquer re-projeto isolado do software.
- Alterabilidade/Mutabilidade: A entidade do software está constantemente sujeita às pressões
por mudanças. O produto de software é incorporado a uma matriz cultural de aplicações, usuários,
leis e veículos de máquina, que estão em constante mudança e suas mudanças, inexoravelmente,
forçam mudanças no produto de software.
- Invisibilidade: O software é invisível e invisualizável; ele não pode ser representado por uma
abstração geométrica, e para constituir uma representação são necessários vários diagramas que
devem representar fluxo de controle, fluxo de dados, padrões de dependência, sequência temporal,
entre outros.
Face a estes problemas, Brooks apresenta alguns progressos do passado que vieram à resover as
dificuldades acidentais, mas não as essenciais, dos quais destaca:
-Linguagens de alto nível: que livram um programa de muitas das suas complexidades acidentais;
-Time-sharing: que trouxe melhorias principalmente na produtividade dos programadores e na
qualidade de seu produto resolvendo o problema de compartilhamento de recursos existentes que
causavam interrupção no tempo de desenvolvimento;
- Ambientes de programação unificados: que melhoraram a produtividade atacando as
dificuldades acidentais que resultavam do uso de programas individuais em conjunto, através do
fornecimento de bibliotecas integradas, formatos de arquivo unificados, filtros, entre outros. Como
resultado, estruturas conceituais que poderiam ser sempre invocadas e reutilizadas facilmente.
A seguir, Brooks apresenta os desenvolvimentos técnicos que seriam potenciais balas de prata,
onde destaca:
- Ada e o avanço de outas linguagens de alto nível;
- Programação orientada à objetos;
- Inteligência artificial;
- Sistemas especialistas;
-Programação Automátical;
-Programação Gráfica
-Verificação de Programas;
-Ambientes e ferramentas;
-Workstations.
A seguir, Brooks apresenta alguns “ataques Promissores na Essência Conceitual”, onde
segundo, embora nenhum progresso tecnológico prometa trazer resultados mágicos como na área
de hardware, há a abundância de bons trabalhos e a promessa de um progresso, se não espetacular,
estável. Todos os ataques tecnológicos sobre os acidentes do processo de software são
fundamentalmente limitados pela equação de produtividade:
tempo_de_tarefa = ∑ (frequência) x (tempo)
Brooks defende que devemos considerar aqueles ataques que indicam a essência do problema de
software.Alguns desses ataques muito promissores são:
- Comprar versus Construir: onde defende que a solução mais radical possível para a construção
do software é não construí-lo completamente;
-Refinamento de requisitos e prototipagem rápida: que é a etapa mais importante do processo
de desenvolvimento pois auxilia muito na grande dificuldade que os desenvolvedores encontram
em saber exatamente o que deve ser construído;
-Contratação de bons projectistas: o que é fundamental para resolução dos problemas essenciais
pois projetos excelentes veem de bons projetistas que constroem estruturas mais rápidas, menores,
simples, claras e produzem com menos esforço.