Resumo: Não há Bala de Prata
"No Silver Bullet: essence and accidents of software
engineering"
Frederick P. Brooks
Christian Reis
<kiko@async.com.br>
Resumo:
Este artigo (
Brooks, 1986) defende a inexistência de um avanço
tecnológico que gere uma melhora de ordem de magnitude na produtividade,
simplicidade e confiabilidade da construção de software. O autor ainda
aponta alguns caminhos promissores ainda em desenvolvimento.
Há, hoje, grande discussão em torno de promover grande melhora na
produtividade da construção de sistemas complexos. Existem duas partes
bastante separadas que constituem as atividades relacionadas ao
desenvolvimento do software: atividades essenciais, que envolvem a
criação de um modelo conceitual para o sistema, e atividades acidentais,
que envolvem a própria implementação do sistema em um programa. O objeto
deste artigo é defender que avanços significativos conquistados até hoje
foram promovidos em cima das questões acidentais do software, e que
ganhos da mesma proporção no desenvolvimento das atividades essenciais
são muito mais difíceis de serem alcançados.
A própria natureza do software torna improvável que exista uma solução
mágica para o problema da construção de sistemas, como a integração
eletrônica representaram para o problema de construção de hardware
complexo. Não é que o software evolui muito lentamente; na realidade, o
hardware é que evolui muito rapidamente; não existem paralelos
tecnológicos no mundo com a velocidade da inovação em hardware.
Analisando os problemas inerentes à essência do problema do
desenvolvimento de software, existem os seguintes pontos particulares:
- Complexidade: Há poucos elementos repetitivos e
idênticos, e fazer crescer o software envolve muito trabalho além de
agregar ou repetir componentes menores. Não há crescimento linear para o
software.
- Conformidade: Não há conforto em um princípio unificado.
O software, por ser uma criação muito recente, precisa ser adaptado a
todo tipo de instituição e sistema já existente.
- Alterabilidade: Por poder ser alterado muito facilmente,
o software sofre pressão por mudança e alteração constante.
- Invisibilidade: O software não é espacialmente
representável: não existe um diagrama ou esquema lógico que o descreva.
São necessárias muitas representações para conseguir um entendimento
visual do sistema.
Passando pelas conquistas do passado que promoveram melhoras de
produtividade na criação do software, temos:
- Linguagem de Alto Nível: Embora realmente muito
importante na melhora de produtividade, este avanço só tem impacto sobre
a complexidade acidental, e não no problema em si.
- Time-sharing: Sistemas modernos resolveram o problema de
turnaround que realmente existia com os sistemas de processamento Batch.
No entanto, este problema não faz parte do problema essencial ao
desenvolvimento de software.
- Ambientes Unificados: Bibliotecas integradas e formatos
de arquivos unificados fazem, na prática, ser possível integrar
estruturas conceituais cujo projeto já previa esta integração, de forma
que não resolveram nenhum problema essencial ao trabalho de construir um
sistema de software.
- Ada e outras linguagens de alto nível: Não atacam a
essência do problema, embora realmente ajudem o desenvolvedor a
desenvolver técnicas novas de projetar o sistema.
- Orientação a Objetos: Resolvem questões acidentais
provendo tipos abstratos de dados e uma hierarquia de tipos. No entanto,
não resolvem questões relacionadas à análise ou projeto de software.
- Inteligência Artificial: segundo Parnas,
(Parnas, 1985) O uso de IA não é uma bala de prata, pelo simples
fato de resolver problemas muito específicos, e requerer trabalho e criatividade
para permitir aplicar uma solução a novas questões.
- Programação Automática: Até hoje não se viu algo que
passe uma especificação diretamente para código; em geral, se existem,
tem aplicação muito específica.
- Programação Gráfica: Embora muito de faça analogia com
procedimentos gráficos para desenvolver hardware, resta a dificuldade
sempre de se visualizar a estrutura conceitual que representa o
software. O uso de muitos diagramas é necessário, e isto reduz a
eficiência e compreensão da visualização.
- Verificação de Programas: Embora realmente tenha impacto
sobre teste e validação do software criado, tem alto custo de aplicação,
e não resolve o problema da especificação incorreta ou imprecisa.
- Ambientes e Ferramentas: O retorno destes avanços será
sempre marginal, porque apóiam o acidental através de mecanismos de
validação de sintaxe e semântica, e apoio à memória do desenvolvedor.
- Workstations: Edição e composição já são adequadamente
suportadas pelas velocidades atuais de computadores. A compilação já não
é um gargalo significativo ao processo de desenvolvimento.
A tarefa à mão, melhorar o desenvolvimento de software, deve atacar os
aspectos essenciais do software.
Uma solução boa para a construção é justamente não construí-lo; há já
disponíveis grandes quantidades de componentes prontos, tornando muito
mais rápido e barato desenvolver. Custos baixos de hardware e a
aplicação geral da computação têm levado os usuários a requererem menos
solução customizadas para seus problemas, de forma que software
padronizado passa a ser uma alternativa.
A tarefa mais difícil é sempre decidir o que construir. Uma
técnica excelente para resolver o problema é extrair e refinar
iterativamente a funcionalidade do sistema; permite que os requisitos
evoluam, o que é muito mais natural do que forçar os clientes a
especificarem 100
A forma mais natural de se desenvolver é justamente criar um esqueleto
inicialmente desprovido de funcionalidade, e adicionar esta
funcionalidade incrementalmente. Esta técnica se aplica bem tanto a
projetos pequenos quanto a projetos grandes.
A grande questão de melhorar o processo de desenvolvimento envolve
melhorar a qualidade do pessoal atribuído às atividades de
desenvolvimento. Bons desenvolvedores e gerentes são raros, mas são o
ponto único de maior impacto na produtividade de uma equipe de
desenvolvimento.
-
Brooks, F. P. (1986),
- No silver bullet: essence and accidents of software
engineering, in H. Kugler, ed., `Information Processing 86', Elsevier
Science (North Holland), pp. 1069-1076.
-
Parnas, D. (1985),
- `Software aspects of strategic defense systems', Communications of the ACM 28(12), 1326-1335.
Christian Reis
2000-09-14