Página 1

No Silver Bullet: Essence and Accidents of

Engenharia de software por Frederick P.
Brooks, Jr.
De todos os monstros que enchem os pesadelos do nosso folclore, nenhum aterroriza
mais do que lobisomens, porque eles se transformam inesperadamente do familiar em
horrores. Para Esses, uns buscam balas de prata que podem magicamente colocá-los
para descansar. O projeto de software familiar, pelo menos visto pelo gerente não
técnico, tem algo deste personagem; geralmente é inocente e direta, mas é capaz de se
tornar um monstro de horários perdidos, orçamentos explodidos e produtos defeituosos.
Assim nós ouvimos gritos desesperados por uma bala de prata - algo para reduzir os
custos de software rapidamente, como os custos de hardware de computador.

Não há desenvolvimento único, tanto na tecnologia como na técnica de gestão, que por
si só promete uma melhoria da produtividade, da confiabilidade, da ordem de
magnitude, em simplicidade. Neste artigo, vamos tentar mostrar por que, examinando
a natureza do problema de software e as propriedades das soluções propostas.

Embora não vejamos avanços surpreendentes - e, de fato, acredito que seja

inconsistente com a natureza do software - muitas as inovações encorajadoras estão
em andamento. Um esforço disciplinado e consistente para se desenvolver, propagar
e explorar essas inovações, de fato, deve render uma ordem de magnitude melhoria.
O primeiro passo para a gestão da doença foi a substituição de teorias demoníacas e
teorizações de humores pela teoria dos germes.
Disse aos trabalhadores que o progresso seria feito passo a passo, com grande esforço,
e que um cuidado persistente e incessante teria que ser pago a uma disciplina de
limpeza. Então é com a engenharia de software hoje.

Página 2
2.Dificuldades Essenciais
Não há apenas balas de prata agora em vista, a própria natureza do software faz com
que improvável que haja alguma - nenhuma invenção que fará para a produtividade do
software, confiabilidade e simplicidade que eletrônicos, transistores e integração em
grande escala para hardware de computador. Não podemos esperar nunca ver dois
ganhos a cada dois anos.
Primeiro, é preciso observar que a anomalia não é que o progresso do software seja tão
lento, mas que o progresso do hardware do computador é tão rápido. Nenhuma outra
tecnologia desde a civilização começou a ter seis ordens de grandeza em ganho de preço
de desempenho em 30 anos. Em não outra tecnologia pode um optar por tomar o ganho
em qualquer um melhor desempenho ou em custos reduzidos. Esses ganhos decorrem
da transformação da fabricação de computadores de um setor de montagem para uma
indústria de processos.
Em segundo lugar, para ver qual a taxa de progresso que se pode esperar na tecnologia
de software, deixe-nos examine as dificuldades dessa tecnologia. Seguindo Aristóteles,
eu os divido em essência , as dificuldades inerentes à natureza do software e os
acidentes , aqueles dificuldades que hoje atendem à sua produção, mas não são
inerentes.
A essência de uma entidade de software é uma construção de conceitos interligados:
conjuntos de dados, relações entre itens de dados, algoritmos e invocações de funções.
Essa essência é abstrata em que tal construção conceitual é a mesma em muitos
diferentes representações. No entanto, é altamente preciso e ricamente detalhado.
Eu acredito que a parte mais difícil da construção do software seja a especificação,
design e teste desta construção conceitual, não o trabalho de representá-lo e testar a
fidelidade da representação. Nós ainda fazemos erros de sintaxe, para ter certeza; mas
eles são comparados com os erros conceituais na maioria dos sistemas.
Se isso for verdade, o software de construção sempre será difícil. Na verdade, não há
prata bala.
Consideremos as propriedades inerentes desta essência irredutível do software
moderno dos sistemas: complexidade, conformidade, variabilidade e
invisibilidade.
Complexidade. As entidades de software são mais complexas para o seu tamanho do
que qualquer outra construção humana porque não há duas partes iguais (pelo menos
acima do nível da indicação). E se eles são, fazemos as duas partes similares em uma
sub-rotina - aberta ou fechada. Nesse respeito, os sistemas de software diferem
profundamente de computadores, edifícios ou automóveis, onde abundam os elementos
repetidos.

Página 3
Os computadores digitais são eles mesmos mais complexos do que a maioria das
pessoas que compõem: eles tem um número muito grande de estados. Isso faz com
que conceba, descreva e teste Eles são difíceis. Os sistemas de software têm ordens de
magnitude mais estados do que computadores Faz.
Da mesma forma, uma ampliação de uma entidade de software não é apenas uma
repetição do mesmo
elementos em tamanhos maiores, é necessariamente um aumento no número de
diferentes
elementos. Na maioria dos casos, os elementos interagem uns com os outros em
alguns não-lineares moda e a complexidade do conjunto aumenta muito mais do
que linearmente. A complexidade do software é uma propriedade essencial, não
acidental. Conseqüentemente,
descrições de uma entidade de software que abstraem sua complexidade, muitas
vezes, abstraem-se é a essência. Durante três séculos, a matemática e as ciências
físicas fizeram grande avançar construindo modelos simplificados de fenômenos
complexos, derivando propriedades
dos modelos e verificando essas propriedades por experiência. Este paradigma
funcionou
porque as complexidades ignoradas nos modelos não eram as propriedades essenciais
da fenômenos. Não funciona quando as complexidades são a essência.
Muitos dos problemas clássicos de desenvolvimento de produtos de software derivam
disso
complexidade essencial e seu aumento não-linear aumenta com o tamanho. Da
complexidade vem
a dificuldade de comunicação entre os membros da equipe, o que leva a falhas do
produto, excessos de custos, atrasos no cronograma. Da complexidade vem a
dificuldade de enumerando, muito menos compreensão, todos os possíveis estados do
programa, e Daí vem a falta de confiabilidade. Da complexidade da função vem a
dificuldade de função de invocação, o que torna os programas difíceis de usar. Da
complexidade da estrutura vem a dificuldade de expandir os programas para novas
funções sem criar lado efeitos. Da complexidade da estrutura vêm os estados não
visuais que constituem armadilhas de segurança.
Não só problemas técnicos, mas problemas de gerenciamento também provêm do
complexidade. Faz uma visão geral difícil, impedindo assim a integridade conceitual.
Isso faz com que
difícil de encontrar e controlar todas as extremidades soltas. Isso cria o tremendo
aprendizado e entendendo o fardo que faz da rotatividade pessoal um desastre.

Página 4
Conformidade. As pessoas de software não estão sozinhas em enfrentar a
complexidade. A física trata com
objetos terrivelmente complexos, mesmo no nível de partículas "fundamental". O
físico trabalha no entanto, em uma fé firme de que existem princípios unificadores,
seja em quarks ou em teorias de campo unificado. Einstein argumentou que deve
haver uma simplificação explicações da natureza, porque Deus não é caprichoso ou
arbitrário.
Nenhuma dessas fé conforta o engenheiro de software. Grande parte da complexidade
que ele deve
O mestre é uma complexidade arbitrária, forçado sem rima ou motivo por muitos
humanos
instituições e sistemas aos quais suas interfaces devem estar em conformidade. Estes
diferem de
interface para interface e, de tempos em tempos, não por necessidade, mas apenas
porque
Eles foram projetados por pessoas diferentes, e não por Deus.
Em muitos casos, o software deve ser conforme porque é a chegada mais recente ao
cena. Em outros, deve ser conforme porque é percebido como o mais conforme. Mas
em todos os casos, muita complexidade vem da conformação a outras interfaces; esta
A complexidade não pode ser simplificada por qualquer redesenho do software sozinho.
Variabilidade. A entidade do software está constantemente sujeita a pressões de
mudança. Do
claro, assim como edifícios, carros, computadores. Mas as coisas fabricadas são
raramente
mudou após o fabrico; Eles são substituídos por modelos posteriores, ou mudanças
essenciais
são incorporados em cópias de número de série posterior do mesmo design básico.
Call-backs
de automóveis são realmente bastante infreqüentes; Mudanças de campo de
computadores um pouco menos assim. Ambos são muito menos freqüentes do
que modificações no software de campo.
Em parte, isso é assim porque o software de um sistema incorpora sua função e a
A função é a parte que mais sente as pressões da mudança. Em parte, é porque O
software pode ser alterado com mais facilidade - é puro pensamento, infinitamente
maleável.
Os edifícios, de fato, mudam, mas os altos custos de mudança, entendidos por todos,
servem para amortecer os caprichos dos cambistas.
Todo o software bem-sucedido é alterado. Dois processos estão no trabalho. Primeiro,
como um software
O produto é considerado útil, as pessoas experimentam em novos casos na borda ou
além do
domínio original. As pressões para a função alargada vêm principalmente de usuários
que como a função básica e inventar novos usos para isso.
Em segundo lugar, o software bem sucedido sobrevive além da vida normal do veículo
da máquina
para o qual é escrito pela primeira vez. Se não forem novos computadores, pelo menos
novos discos, novos
exibe novas impressoras; e o software deve ser conforme ao seu novo veículos
de oportunidade.

Página 5
Em suma, o produto de software está incorporado em uma matriz cultural de
aplicativos, usuários, leis e veículos de máquinas. Todos mudam
continuamente e suas mudanças inexoravelmente força a mudança no produto
do software.
Invisibilidade. O software é invisível e não visível. As abstrações geométricas são
ferramentas poderosas. O plano de um prédio ajuda tanto arquiteto quanto cliente a
avaliar
espaços, fluxos de tráfego, visualizações. As contradições e omissões tornam-se óbvias.
Escala
desenhos de peças mecânicas e modelos de moléculas de bastão, embora abstrações,
servem o mesmo propósito. Uma realidade geométrica é capturada em uma
geometria abstração.
A realidade do software não está inerentemente incorporada no espaço. Por isso, não
está pronto
Representação geométrica na forma como a terra possui mapas, chips de silício têm
diagramas,
Os computadores possuem esquemas de conectividade. Assim que tentamos diagramar
o software
estrutura, consideramos que não constituem um, mas vários, gráficos direcionados em
geral
sobreposto um sobre o outro. Os vários gráficos podem representar o fluxo de
controle, o fluxo de dados, os padrões de dependência, a seqüência de tempo,
os relacionamentos nome-espaço.
Esses gráficos geralmente não são planos, muito menos hierárquicos. Na verdade, um
dos
formas de estabelecer o controle conceitual sobre essa estrutura é reforçar o corte de
link até um ou mais dos gráficos se tornarem hierárquicos.
Apesar dos progressos na restrição e simplificação das estruturas de software, eles
permanecem intrinsecamente invisíveis e, portanto, não permitem que a mente use
alguns de seus
ferramentas conceituais mais poderosas. Esta falta não apenas impede o processo de
design dentro de uma mente, dificulta severamente a comunicação entre as mentes.
Desvios anteriores solucionaram dificuldades acidentais
Se examinarmos as três etapas no desenvolvimento de tecnologia de software que foram
mais frutíferas no passado, descobrimos que cada uma atacou uma grande dificuldade
em
software de construção, mas que essas dificuldades foram acidentais, não essenciais,
dificuldades. Podemos também ver os limites naturais para a extrapolação de cada
ataque.
Idiomas de alto nível. Certamente, o golpe mais poderoso para a produtividade do
software,
confiabilidade e simplicidade tem sido o uso progressivo de linguagens de alto nível
para
programação. A maioria dos observadores acredita que o desenvolvimento com pelo
menos um fator de cinco em produtividade e com ganhos concomitantes de
confiabilidade, simplicidade e compreensibilidade.

Página 6
O que um idioma de alto nível cumpre? Libera um programa de muitos dos seus
complexidade acidental. Um programa abstrato consiste em construções conceituais:
operações, tipos de dados, seqüências e comunicação. O programa de máquinas de
concreto está preocupado com bits, registros, condições, ramos, canais, discos e tal.
Para na medida em que a linguagem de alto nível incorpora as construções que se quer
na programa abstrato e evita todos os mais baixos, elimina todo um nível de
complexidade
Isso nunca foi inerente ao programa.
A linguagem de mais alto nível pode fazer é fornecer todas as construções que o O
programador imagina no programa abstrato. Com certeza, o nível de nosso
pensamento
sobre estruturas de dados, tipos de dados e operações está aumentando
constantemente, mas sempre taxa decrescente. E o desenvolvimento do idioma
se aproxima cada vez mais sofisticação dos usuários.
Além disso, em algum momento, a elaboração de uma linguagem de alto nível cria uma
ferramenta
carga de domínio que aumenta, não reduz, a tarefa intelectual do usuário que
raramente usa as construções esotéricas.
Tempo de compartilhamento . A partilha de tempo trouxe uma grande melhoria na
produtividade de
programadores e na qualidade de seu produto, embora não tão grande quanto isso
trouxe por linguagens de alto nível.
O compartilhamento de tempo compartilha uma dificuldade bastante diferente. A
partilha de tempo preserva o imediatismo,
e, portanto, permite que alguém mantenha uma visão geral da complexidade. A
reviravolta lenta de
A programação em lote significa que inevitavelmente esquece as minúcias, senão a
própria impulso, do que estava pensando quando ele parou de programar e exigiu
compilação e execução. Essa interrupção é dispendiosa no tempo, pois é preciso
atualizar
a memória de alguém. O efeito mais grave pode ser a decadência da compreensão de
tudo o que é acontecendo em um sistema complexo.
A reviravolta mais lenta, como complexidades de linguagem de máquina, é um
acidente, em vez de um dificuldade essencial do processo de software. Os limites da
contribuição potencial de O compartilhamento de tempo deriva diretamente. O
principal efeito do timesharing é encurtar o sistema
tempo de resposta. Como este tempo de resposta passa para zero, em algum momento
passa o humano
Limiar de visibilidade, cerca de 100 milissegundos. Além desse limiar, nenhum
benefício são de se esperar.
Ambientes de programação unificados. Unix e Interlisp, o primeiro integrado
ambientes de programação para uso generalizado, parecem ter melhorado produtividade
por fatores integrais. Por quê?

Página 7
Eles atacam as dificuldades acidentais resultantes da utilização de programas
individuais. juntos, fornecendo bibliotecas integradas, formatos de arquivos
unificados, e tubos e filtros.
Como resultado, estruturas conceituais que, em princípio, sempre podem chamar,
alimentar e usar um outro pode realmente facilmente fazê-lo na prática.
Esse avanço, por sua vez, estimulou o desenvolvimento de bancos de ferramentas
inteiras, uma vez que
Cada nova ferramenta poderia ser aplicada a qualquer programa que usasse os formatos
padrão.
Devido a esses sucessos, os ambientes são objeto de grande parte do software de hoje
-
pesquisa de engenharia. Observamos suas promessas e limitações na próxima seção.
Esperanças para a prata
Agora, vamos considerar os desenvolvimentos técnicos que são mais frequentemente
avançados como
potenciais balas de prata. Que problemas abordam - os problemas de essência, ou as
dificuldades acidentais restantes? Eles oferecem avanços revolucionários, ou
incremental?
Ada e outros avanços de linguagem de alto nível. Um dos mais divulgados recentes
A evolução é Ada, uma linguagem de alto nível de propósito geral da década de 1980.
Ada não
apenas reflete melhorias evolutivas nos conceitos de linguagem, mas, de fato, encarna
recursos para incentivar o design moderno e modularização. Talvez a filosofia de Ada
é mais um avanço do que a linguagem Ada, pois é a filosofia de
modularização, de tipos de dados abstratos, de estruturação hierárquica. Ada é muito
rico, um
resultado natural do processo pelo qual os requisitos foram estabelecidos no seu projeto.
Aquilo não é
fatal, para os vocabulários de trabalho subsetados podem resolver o problema de
aprendizagem e
O avanço de hardware nos dará os MIPS baratos para pagar os custos de compilação.
O avanço da estruturação de sistemas de software é de fato um ótimo uso para a
MIPS aumentados nossos dólares comprarão. Sistemas operacionais, criticados em
voz alta na década de 1960 por sua memória e custos de ciclo, provaram ser uma
excelente forma de usar alguns dos MIPS e bytes de memória baratos do passado
avançado de hardware. No entanto, Ada não será a bala de prata que mata o software
monstro de produtividade. É, afinal, apenas uma outra linguagem de alto nível, e a maior
O retorno de tais idiomas veio da primeira transição - a transição para cima do
complexidades acidentais da máquina na declaração mais abstrata do passo-a-
soluções passo a passo. Uma vez que esses acidentes foram removidos, os restantes
serão menor, e a recompensa por sua remoção certamente será menor.
Eu prevejo que, uma década a partir de agora, quando a eficácia de Ada for avaliada,
será visto ter feito uma diferença substancial, mas não por qualquer linguagem
particular
característica, nem mesmo por causa de todos eles combinados. Nem o novo Ada

Página 8
Os ambientes provam ser a causa das melhorias. A maior contribuição de Ada será
que mudar para ele ocasionou o treinamento de programadores em software
moderno - técnicas de design.
Programação orientada a objetos. Muitos estudantes da arte aguardam mais
esperança para
programação orientada a objetos do que para qualquer outra modificação técnica do
dia. eu sou entre eles. Mark Sherman, de Dartmouth, anota no CSnet News, que é
preciso ser Cuidado para distinguir duas idéias separadas que estão sob esse nome:
dados abstratos
tipos e tipos hierárquicos . O conceito do tipo de dados abstratos é que o objeto de um
objeto é
tipo deve ser definido por um nome, um conjunto de valores adequados e um conjunto
de
operações em vez de sua estrutura de armazenamento, que deve ser escondida.
Exemplos são
Pacotes Ada (com tipos particulares) e módulos da Modula.
Os tipos hierárquicos, como as classes de Simula-67, permitem definir interfaces
gerais que pode ser melhorada ao fornecer tipos subordinados. Os dois conceitos são
orthogonal_one pode ter hierarquias sem se esconder e se esconder sem hierarquias.
Ambos os conceitos representam avanços reais na arte do software de construção.
Cada um remove ainda outra dificuldade acidental do processo, permitindo que o
designer para expressar a essência do projeto sem ter que expressar grandes
quantidades de material sintático que não adiciona conteúdo de informações. Para
tipos abstratos e tipos hierárquicos, o resultado é remover um tipo de dificuldade
acidental de ordem superior e permitir uma expressão de design de ordem superior.
No entanto, tais avanços não podem fazer mais do que remover todos os acidentais.
dificuldades com a expressão do design. A complexidade do projeto em si é essenciais,
e tais ataques não fazem qualquer alteração nisso. Uma ordem de magnitude
O ganho pode ser feito por programação orientada a objetos somente se o tipo
desnecessário -
O underbrush de especificação ainda na nossa linguagem de programação é ele próprio
nove décimos do
Trabalho envolvido na concepção de um produto de programa. Eu duvido.
Inteligência artificial. Muitas pessoas esperam avanços na inteligência artificial para
Fornecer o avanço revolucionário que dará ganhos de ordem de magnitude em
produtividade e qualidade do software. Eu não posso. Para ver por que, devemos
dissecar o que significa por "inteligência artificial".
DL Parnas esclareceu o caos terminológico:
Duas definições bem diferentes de AI são de uso comum hoje. AI-1: o uso de
computadores para resolver problemas que anteriormente só poderiam ser resolvidos
aplicando humanos
inteligência. Al-2: o uso de um conjunto específico de técnicas de programação
conhecidas como
programação heurística ou baseada em regras. Nesta abordagem, os especialistas
humanos são estudados para

Página 9
determine o que as heurísticas ou as regras de uso que utilizam para resolver problemas.
O programa é projetado para resolver um problema da maneira como os humanos
parecem resolvê-lo.
A primeira definição tem um significado deslizante .... Algo pode caber na definição de
Al-1
hoje, mas, uma vez que vemos como o programa funciona e compreende o problema,
vamos
não pense nisso como Al. Infelizmente não consigo identificar um corpo de tecnologia
Isso é exclusivo desse campo .... A maioria do trabalho é específica do problema e
alguns
É necessária uma abstração ou criatividade para ver como transferi-lo. Concordo
completamente com essa crítica. As técnicas utilizadas para o reconhecimento de
fala parecem
ter pouco em comum com aqueles usados para reconhecimento de imagem, e ambos
são diferentes
daqueles usados em sistemas especializados. Eu tenho dificuldade em ver como o
reconhecimento da imagem,
por exemplo, irá fazer qualquer diferença apreciável na prática de programação. O
mesmo
O problema é verdadeiro no reconhecimento de fala. O mais difícil de construir
software é decidir o que quer dizer, não dizer isso. Nenhuma facilitação de expressão
pode dar mais do que ganhos marginais.
Sistemas especializados. A parte mais avançada da arte da inteligência artificial, e a
maioria
amplamente aplicado, é a tecnologia para a construção de sistemas especializados.
Muitos softwares
Os cientistas estão trabalhando no trabalho aplicando esta tecnologia ao software de
construção meio Ambiente. Qual é o conceito e quais são as perspectivas?
Um sistema especializado é um programa que contém um mecanismo de inferência
generalizado e uma regra
base, toma dados de entrada e suposições, explora as inferências deriváveis da regra
base, produz conclusões e conselhos, e oferece para explicar seus resultados
retraçando sua raciocínio para o usuário. Os motores de inferência normalmente
podem lidar com dados probabilísticos e regras, além da lógica puramente
determinista.
Esses sistemas oferecem algumas vantagens claras em relação aos algoritmos
programados projetados para chegando às mesmas soluções para os mesmos
problemas:
• A tecnologia do mecanismo de inferência é desenvolvida de forma
independente de aplicação, e depois aplicado a vários usos. Pode-se justificar
muito esforço na inferência motores. Na verdade, essa tecnologia está bem
avançada.
• As partes variáveis dos materiais peculiares do aplicativo são codificadas
no base de regras de forma uniforme, e ferramentas são fornecidas para o
desenvolvimento, mudança, testando e documentando a base de regras. Isso
regulariza grande parte do complexidade do próprio aplicativo.

Página 10
O poder de tais sistemas não vem de mecanismos de inferência cada vez maiores mas
sim de bases de conhecimento cada vez mais ricas que refletem o mundo real mais com
precisão. Eu acredito que o avanço mais importante oferecido pela tecnologia é o
separação da complexidade da aplicação do próprio programa.
Como esta tecnologia pode ser aplicada na tarefa de engenharia de software? De várias
maneiras:
Tais sistemas podem sugerir regras de interface, aconselhar sobre estratégias de teste,
lembrar bug- frequências de tipos e sugestões de otimização de oferta.
Considere um consultor de testes imaginários, por exemplo. Na sua forma mais
rudimentar, o
O sistema de especialistas em diagnóstico é muito parecido com uma lista de verificação
de um piloto, apenas enumerando sugestões
quanto a possíveis causas de dificuldade. À medida que mais e mais estrutura do sistema
é incorporada em a base da regra, e como a base da regra tem uma conta mais sofisticada
do problema Os sintomas relatados, o consultor de teste torna-se cada vez mais
particular no as hipóteses que gera e os testes que recomenda. Tal sistema especializado
pode Partida mais radicalmente dos convencionais em que sua base de regra
provavelmente deveria
ser hierarquicamente modularizado da mesma forma que o produto de software
correspondente é,
de modo que, à medida que o produto é modularmente modificado, a base de regras
de diagnóstico pode ser modificado de forma modificada também.
O trabalho necessário para gerar as regras de diagnóstico é o trabalho que teria que ser
feito
de qualquer forma na geração do conjunto de casos de teste para os módulos e para o
sistema. Se for
feito de forma adequada, com uma estrutura uniforme para regras e um bom motor de
inferência disponível, pode realmente reduzir o trabalho total de geração de até casos
de teste e ajuda também com testes de manutenção e modificação ao longo da vida.
Dentro
da mesma forma, pode-se postular outros conselheiros, provavelmente muitos e
provavelmente simples, para as outras partes da tarefa de construção de software.
Muitas dificuldades impedem a realização precoce de um útil sistema especialista
assessores do desenvolvedor do programa. Uma parte crucial do nosso cenário
imaginário é a
desenvolvimento de maneiras fáceis de obter a partir da especificação da estrutura do
programa para o geração automática ou semiautomática de regras de diagnóstico. Ainda
mais difícil e importante é a dupla tarefa de aquisição de conhecimento: encontrar
articulação, auto- especialistas analíticos que sabem por que fazem coisas e
desenvolvem técnicas eficientes por extrair o que eles conhecem e destilá-lo em bases
de regras. O essencial O pré-requisito para construir um sistema especializado é ter um
especialista.

Página 11
A contribuição mais poderosa dos sistemas especializados certamente será colocar no
serviço do inexperiente programador, a experiência e a sabedoria acumulada dos
melhores programadores. Esta não é uma pequena contribuição. O fosso entre o melhor
software
prática de engenharia e a prática média é muito ampla, talvez maior do que em
qualquer outra disciplina de engenharia. Uma ferramenta que dissemina boas
práticas seria importante.
Programação "automática". Por quase 40 anos, as pessoas estão antecipando e
escrevendo sobre "programação automática", ou a geração de um programa para
resolver um
problema de uma declaração das especificações do problema. Alguns hoje escrevem
como se eles
Espera que esta tecnologia ofereça o próximo avanço.
Parnas implica que o termo é usado para glamour, não para conteúdo semântico,
afirmando,
Em suma, a programação automática sempre foi um eufemismo para programação
com uma linguagem de nível superior à que estava atualmente disponível para o
programador.
Ele argumenta, em essência, que na maioria dos casos é o método de solução, não o
problema, cuja especificação deve ser dada.
Pode-se encontrar exceções. A técnica de construção de geradores é muito poderosa e
é rotineiramente usado para uma boa vantagem em programas para classificação.
Alguns sistemas para as equações diferenciais integradoras também permitiram a
especificação direta da problema, e os sistemas avaliaram os parâmetros, escolhidos de
uma biblioteca de métodos de solução e gerou os programas.
Essas aplicações têm propriedades muito favoráveis:
• Os problemas são prontamente caracterizados por relativamente poucos
parâmetros. • Existem muitos métodos conhecidos de solução para fornecer uma
biblioteca de alternativas.
• Uma extensa análise levou a regras explícitas para a seleção de técnicas de
solução, parâmetros de problemas fornecidos.
É difícil ver como tais técnicas se generalizam para o mundo mais amplo do comum
sistema de software, onde os casos com propriedades tão boas são a exceção. É difícil
até mesmo para imaginar como esse avanço na generalização poderia ocorrer.

Página 12
Programação gráfica. Um assunto favorito para dissertações de doutorado em
software engenharia é a programação gráfica ou visual, a aplicação do computador
gráficos para design de software. Às vezes, a promessa feita por tal abordagem é
postulado por analogia com o design de chips VLSI, em que a computação gráfica
joga tão
Um papel frutuoso. Às vezes, o teórico justifica a abordagem considerando
fluxogramas como o meio ideal de design de programas e fornecendo instalações
poderosas para construindo-os.
Nada mesmo convincente, muito menos emocionante, já emergiu de tais esforços. eu
sou convencido de que nada será.
Em primeiro lugar, como eu argumentei em outro lugar, o fluxograma é uma abstração
muito fraca
da estrutura de software. Na verdade, é melhor visto como Burks, von Neumann e
A tentativa de Goldstine de fornecer uma linguagem de controle de alto nível
desesperadamente necessária para o computador proposto. Na forma pitiful,
multipágina, caixa de conexão ao qual o fluxograma foi elaborado hoje, provou ser
inútil como uma ferramenta de design - Os programadores desenham fluxogramas
depois, não antes, escrevendo os programas que descrevem.
Em segundo lugar, as telas de hoje são muito pequenas, em pixels, para mostrar tanto o
escopo como o
resolução de qualquer diagrama de software seriamente detalhado. O chamado
"desktop metáfora "da estação de trabalho de hoje é, em vez disso, uma metáfora do"
assento do avião ".
Arrasou uma volta cheia de papéis, sentada entre dois passageiros portentos reconhecer
a diferença - pode-se ver apenas algumas coisas ao mesmo tempo. A área de trabalho
verdadeira
fornece uma visão geral e acesso aleatório a uma série de páginas. Além disso, quando
os ataques de a criatividade é forte, mais de um programador ou escritor é conhecido
por abandonar a área de trabalho para o piso mais espaçoso. A tecnologia de hardware
terá que avançar substancialmente antes do alcance dos nossos escopos ser suficiente
para tarefa de design de software.
Mais fundamentalmente, como argumentei acima, o software é muito difícil de
visualizar.
Se um diagrama controla o fluxo, o ninho de escopo variável, as referências cruzadas
variáveis,
fluxo de dados, estruturas de dados hierárquicas ou o que quer que seja, só se considera
uma dimensão de
o software intrincado interligado elefante de software. Se alguém sobrepõe todos os
diagramas gerado pelas muitas visualizações relevantes, é difícil extrair qualquer
visão geral global.
A analogia da VLSI é fundamentalmente enganadora - um design de chip é uma camada
de dois-
descrição dimensional cuja geometria reflete sua realização em 3 espaços. Um
software O sistema não é.

Página 13
Verificação do programa. Grande parte do esforço na programação moderna passa em
testes
e o reparo de erros. Existe talvez uma bala prateada, eliminando a
erros na origem, na fase de design do sistema? Tanto a produtividade como o produto a
confiabilidade seja radicalmente aprimorada seguindo a estratégia profundamente
diferente de
provando desenhos corretos antes que o imenso esforço seja investido na
implementação e testando-os?
Não acredito que possamos encontrar magia de produtividade aqui. A verificação do
programa é uma conceito poderoso, e será muito importante para coisas como operações
seguras, kernels do sistema. A tecnologia não promete, no entanto, poupar mão-de-obra.
As verificações são tanto trabalho que apenas alguns programas substanciais já foram
verificado.
A verificação do programa não significa programas à prova de erros. Não há mágica
aqui,
ou. As provas matemáticas também podem ser defeituosas. Então, enquanto a
verificação pode reduzir a carga de teste do programa, não pode eliminá-lo.
Mais a sério, mesmo a verificação perfeita do programa só pode estabelecer que um
programa
atende às suas especificações. A parte mais difícil da tarefa de software está chegando
a uma completa
e especificações consistentes, e grande parte da essência da construção de um
programa é de fato a depuração da especificação.
Ambientes e ferramentas. Quanto mais ganho pode ser esperado da explosão pesquisa
em melhores ambientes de programação? A reação instintiva de alguém é essa
os grandes problemas de pagamento - sistemas de arquivos hierárquicos, formatos de
arquivo uniformes para fazer
possíveis interfaces de programas uniformes e ferramentas generalizadas - foram os
primeiros atacados,
e foram resolvidos. Editores inteligentes específicos da linguagem são
desenvolvimentos ainda não
amplamente utilizado na prática, mas o máximo que prometem é a ausência de erros
sintáticos e erros semânticos simples.
Talvez o maior ganho ainda não seja realizado a partir de ambientes de programação é
o uso
de sistemas de banco de dados integrados para acompanhar a infinidade de detalhes que
devem ser lembrados
com precisão pelo programador individual e mantidos atualizados para um grupo de
colaboradores em um único sistema.
Certamente, este trabalho vale a pena, e certamente ganhará frutos na produtividade e
confiabilidade. Mas, por sua própria natureza, o retorno a partir de agora deve ser
marginal.

Página 14
Estações de trabalho. Quais ganhos são esperados para a arte do software a partir do
aumento rápido da potência e da capacidade de memória da estação de trabalho
individual? Bem,
Quantos MIPS pode ser usado com sucesso? A composição e edição de programas e Os
documentos são totalmente suportados pelas velocidades atuais. Compilar pode dar um
impulso, mas um
O fator de 10 na velocidade da máquina certamente deixaria o tempo de reflexão a
atividade dominante em
O dia do programador. Na verdade, parece ser assim agora.
Estações de trabalho mais poderosas que certamente receberemos. Melhorias mágicas
deles não podemos esperar.
Ataques promissores na essência conceitual
Mesmo que nenhuma inovação tecnológica prometa dar o tipo de mágico resultados
com os quais estamos tão familiarizados na área de hardware, há uma abundância de
bom trabalho acontecendo agora, e a promessa de um progresso constante, se não
espetacular.
Todos os ataques tecnológicos aos acidentes do processo de software são
fundamentalmente limitado pela equação de produtividade:
Se, como eu acredito, os componentes conceituais da tarefa agora estão levando a
maioria dos
tempo, então nenhuma quantidade de atividade nos componentes da tarefa que são
meramente a
A expressão dos conceitos pode dar grandes ganhos de produtividade.
Portanto, devemos considerar aqueles ataques que abordam a essência do software
problema, a formulação dessas complexas estruturas conceituais. Felizmente, alguns
dos esses ataques são muito promissores.
Comprar versus construir. A solução mais radical possível para a construção de
software não é para construí-lo.
Todos os dias isso se torna mais fácil, à medida que mais e mais fornecedores oferecem
mais e melhor
produtos de software para uma variedade vertiginosa de aplicações. Enquanto nós
engenheiros de software
trabalhou na metodologia de produção, a revolução do computador pessoal não criou
um, mas muitos mercados de massa para software. Todo banca de jornais carrega
revistas mensais, que classificam por tipo de máquina, anunciam e revisam dezenas de
produtos a preços de alguns dólares a algumas centenas de dólares. Mais especializado
As fontes oferecem produtos muito poderosos para a estação de trabalho e outros
mercados do Unix.

Página 15
Mesmo as ferramentas de software e os ambientes podem ser comprados na
prateleira. Eu tenho em outro lugar propôs um mercado para módulos
individuais.
Qualquer produto desse tipo é mais barato de comprar do que construir de novo.
Mesmo com um custo de cem mil dólares, uma peça de software comprada está
custando apenas cerca de um programador. E a entrega é imediata! Imediatamente
pelo menos para produtos que realmente existem produtos cujo desenvolvedor pode
encaminhar produtos para um usuário feliz. Além disso, tais produtos tendem a ser
melhor documentados e um pouco melhor mantidos que o software doméstico.
O desenvolvimento do mercado de massa é, eu acredito, a mais profunda tendência de
longo prazo em
Engenharia de software. O custo do software sempre foi custo de desenvolvimento, não
custo de replicação. Compartilhar esse custo entre até alguns usuários reduz
radicalmente o usuário por usuário
custo. Outra maneira de ver isso é que o uso de n cópias de um sistema de software
efetivamente multiplica a produtividade de seus desenvolvedores por n . Isso é um
aprimoramento da produtividade da disciplina e da nação.
A questão fundamental, é claro, é a aplicabilidade. Posso usar um pacote off-the-shelf
disponível
para executar minha tarefa? Uma coisa surpreendente aconteceu aqui. Durante a década
de 1950 e
Nos anos 60, estudo após estudo mostrou que os usuários não usariam pacotes off-
theshelf para
folha de pagamento, controle de estoque, contas a receber e assim por diante. Os
requisitos também foram
Especializado, a variação caso a caso é muito alta. Durante a década de 1980,
encontramos pacotes em alta demanda e uso generalizado. O que mudou?
Não são os pacotes, na verdade. Eles podem ser um pouco mais generalizados e um
pouco
mais personalizável do que antigamente, mas não muito. Não são também as aplicações.
E se
qualquer coisa, as necessidades comerciais e científicas de hoje são mais diversas e
complicadas do que os de 20 anos atrás.
A grande mudança ocorreu na relação de custo de hardware / software. Em 1960, o
comprador de um máquina de dois milhões de dólares sentiu que poderia pagar US $
250.000 por mais programa de folha de pagamento, um que escorregou facilmente e
sem interrupção no computador hostil
ambiente social. Hoje, o comprador de uma máquina de escritório de $ 50,000 não pode
ser concebível
pagar um programa de folha de pagamento personalizado, então ele adapta o processo
de folha de pagamento ao
pacotes disponíveis. Os computadores agora são tão comuns, se ainda não tão amados,
que
As adaptações são aceitas como uma questão de curso.
 Página 16
Existem exceções dramáticas no meu argumento de que a generalização de software Os
pacotes mudaram pouco ao longo dos anos: planilhas eletrônicas e simples sistemas de
banco de dados. Essas ferramentas poderosas, tão óbvias em retrospectiva e ainda tão
atrasadas em
aparecendo, se prestam a inúmeros usos, alguns bastante pouco ortodoxos. Artigos e até
mesmo
Os livros agora abundam sobre como lidar com tarefas inesperadas com a planilha.
ampla
números de aplicativos que anteriormente seriam escritos como programas
personalizados em
Cobol ou Report Program Generator agora são rotineiramente feitos com essas
ferramentas.
Muitos usuários agora operam seus próprios computadores dia a dia em vários
aplicativos sem escrever um programa. De fato, muitos desses usuários não podem
escrever
novos programas para suas máquinas, mas eles são, no entanto, habilidosos para
resolver novos problemas com eles.
Eu acredito que a estratégia de produtividade de software mais poderosa para muitos as
organizações hoje são equipar os trabalhadores intelectuais ingênuos do computador
que estão no
linha de fogo com computadores pessoais e boa escrita generalizada, desenho, arquivo
e
programas de planilhas e, em seguida, soltá-los. A mesma estratégia, realizada com
pacotes matemáticos e estatísticos generalizados e alguma programação simples
capacidades, também funcionará para centenas de cientistas de laboratório. Requisitos
de requalificação e prototipagem rápida. A única parte mais difícil de Construir um
sistema de software é decidir exatamente o que construir. Nenhuma outra parte do
O trabalho conceitual é tão difícil como estabelecer os requisitos técnicos detalhados,
incluindo todas as interfaces para pessoas, máquinas e outros sistemas de software. Não
Outra parte do trabalho afeta o sistema resultante se for feito de forma
errada. Nenhuma outra parte é mais difícil de corrigir mais tarde.
Portanto, a função mais importante que o construtor de software executa para o
O cliente é a extração iterativa e o refinamento dos requisitos do produto. Para o A
verdade é que o cliente não sabe o que quer. O cliente geralmente não sabe quais
perguntas devem ser respondidas, e ele quase nunca pensou no problema em o
detalhe necessário para a especificação. Mesmo a resposta simples "Faça o novo
O sistema de software funciona como o nosso antigo sistema manual de processamento
de informações "é de fato
tão simples. Nunca queremos exatamente isso. Sistemas de software complexos são,
além disso, coisas que agem, esse movimento, que funcionam. A dinâmica dessa ação
é difícil de imaginar.
Assim, ao planejar qualquer atividade de design de software, é necessário permitir
uma extensa iteração entre o cliente e o designer como parte da definição do sistema.

Página 17
Eu iria um passo adiante e afirmar que é realmente impossível para um cliente, mesmo
trabalhando com um engenheiro de software, para especificar de forma completa,
precisa e correta
requisitos exatos de um produto de software moderno antes de tentar algumas versões
do produtos.
Portanto, um dos mais promissores dos esforços tecnológicos atuais e um que ataca a
essência, não os acidentes, do problema do software, é o desenvolvimento de
abordagens e ferramentas para prototipagem rápida de sistemas, pois a prototipagem
faz parte do especificação iterativa de requisitos.
Um protótipo de sistema de software é aquele que simula as interfaces importantes e
executa as principais funções do sistema pretendido, embora não seja necessariamente
vinculado pela mesma velocidade de hardware, tamanho ou restrições de custo.
Protótipos normalmente
execute as tarefas principais do aplicativo, mas não faça nenhuma tentativa de lidar com
o
tarefas excepcionais, responder corretamente às entradas inválidas ou abortar de forma
limpa. O propósito de
o protótipo é tornar real a estrutura conceitual especificada, de modo que o cliente possa
Teste-o para consistência e usabilidade.
Grande parte do procedimento atual de aquisição de software baseia-se no pressuposto
de que
pode-se especificar antecipadamente um sistema satisfatório, obter lances para a sua
construção, tê-lo
construído e instale-o. Penso que esta suposição é fundamentalmente errada, e que
muitos
Problemas de aquisição de software provêm dessa falácia. Portanto, eles não podem
ser consertados sem revisão fundamental - revisão que prevê o desenvolvimento
iterativo e especificação de protótipos e produtos.
Desenvolvimento incremental - crescer, não construir, software. Ainda me lembro da
sacudida que senti
Em 1958, quando ouvi pela primeira vez um amigo falar sobre a construção de um
programa, em oposição
para escrever um. Em um instante ele ampliou toda a minha visão do processo de
software. o
A mudança de metáfora foi poderosa e precisa. Hoje entendemos como outros
processos de construção, a construção de software é, e usamos livremente outros
elementos de a metáfora, como especificações , montagem de componentes e
andaimes .
A metáfora do edifício ultrapassou sua utilidade. É hora de mudar novamente. Se eu,
como eu
acredite, as estruturas conceituais que construímos hoje são muito complicadas de ser
especificamente com antecedência, e muito complexo para ser construído sem falhas,
então devemos assumir uma abordagem radicalmente diferente.
Deixe-nos transformar a natureza e estudar a complexidade dos seres vivos, em vez de
apenas os trabalhos mortos
do homem. Aqui encontramos construções cujas complexidades nos emocionam com
admiração. O cérebro
sozinho é intrincado além do mapeamento, poderoso além da imitação, rico em
diversidade, auto- proteção e auto-renovação. O segredo é que ele é cultivado,
não construído.

Page 18
Portanto, deve ser com os nossos sistemas de software. Alguns anos atrás, Harlan Mills
propôs que
qualquer sistema de software deve ser cultivado por desenvolvimento incremental. Ou
seja, o
O sistema deve primeiro ser executado, mesmo que não faça nada útil, exceto chamar
o
conjunto adequado de subprogramas falsos. Então, pouco a pouco, deve ser elaborado,
com o
subprogramas, por sua vez, estão sendo desenvolvidos - em ações ou chamadas para
talões vazios no nível abaixo.
Eu vi resultados mais dramáticos desde que comecei a pedir essa técnica no projeto
construtores na minha classe de Laboratório de Engenharia de Software. Nada na última
década tem
Mudou radicalmente a minha própria prática ou a sua eficácia. A abordagem requer
design de cima para baixo, pois é um crescimento descendente do software. Isso
permite fácil backtracking. Ele se presta a protótipos iniciais. Cada função adicionada
e nova a provisão para dados ou circunstâncias mais complexas cresce orgânica do
que é já está lá.
Os efeitos da moral são surpreendentes. Saltos de entusiasmo quando há um sistema de
corrida,
mesmo um simples. Os esforços redobram quando a primeira imagem de um novo
gráfico
O sistema de software aparece na tela, mesmo que seja apenas um retângulo. Um
sempre tem,
em cada etapa do processo, um sistema de trabalho. Acho que as equipes podem
crescer muito mais
entidades complexas em quatro meses do que podem construir .
Os mesmos benefícios podem ser realizados em grandes projetos como em meus
pequenos.
Grandes designers. A questão central de como melhorar os centros de arte de
software, como sempre tem, nas pessoas.
Podemos obter bons projetos seguindo boas práticas em vez de pobres. Boa
As práticas de design podem ser ensinadas. Os programadores estão entre a parte mais
inteligente da
população, para que eles possam aprender boas práticas. Por isso, um grande impulso
nos Estados Unidos é promulgar boas práticas modernas. Novos currículos, nova
literatura, novos organizações como o Instituto de Engenharia de Software, todos
surgiram em para aumentar o nível de nossa prática de pobre a bom. Isso é inteiramente
apropriado. No entanto, não acredito que possamos fazer o próximo passo para cima da
mesma maneira.
Considerando que a diferença entre conceitos conceituais pobres e bons pode estar na
solidez do método de design, a diferença entre bons projetos e grandes certamente não.
Grandes projetos provêm de grandes designers. A construção de software é
um processo criativo . A metodologia sólida pode capacitar e liberar a mente
criativa; isto não pode inflamar ou inspirar o drudge.

Page 19
As diferenças não são menores - são bem como as diferenças entre Salieri e Mozart.
Estudo após estudo mostra que os melhores designers produzem estruturas que
são mais rápidos, menores, mais simples, mais limpos e produzidos com menos
esforço. As diferenças entre o grande e o médio, uma ordem de magnitude.
Uma pequena retrospecção mostra que, embora muitos sistemas de software finos e
úteis tenham
foi projetado por comitês e foi construído como parte de projetos de várias partes, esses
softwares
sistemas que entusiasmaram fãs apaixonados são aqueles que são produtos de um ou de
um
poucas mentes de design, grandes designers. Considere Unix, APL, Pascal, Modula, o
Interface Smalltalk, mesmo Fortran; e contraste com Cobol, PL / I, Algol,
MVS / 370 e MS-DOS. (Ver Tabela 1.)
Por isso, embora eu apoie fortemente a transferência de tecnologia e o currículo esforços
de desenvolvimento em curso, penso que o esforço único mais importante que podemos
fazer mount é desenvolver maneiras de desenvolver grandes designers.
Nenhuma organização de software pode ignorar esse desafio. Gerentes bons, escassos,
no entanto
eles são, não são mais escassos do que bons designers. Grandes designers e grandes
gerentes são
ambos muito raros. A maioria das organizações gasta esforços consideráveis para
encontrar e cultivar
as perspectivas de gestão; Não conheço nenhum que gaste o mesmo esforço em
encontrar e desenvolvendo os grandes designers sobre os quais a excelência técnica
dos produtos em última análise, dependerá.
Tabela 1. Vultros emocionantes. Produtos de software úteis, mas não instáveis.
Emocionante
Produtos sim
Não
Unix
Cobol
APL
PL / I
Pascal
Algol
Modula
MVS / 370
Conversa fiada
MS-DOS
Fortran
Minha primeira proposta é que cada organização de software deve determinar e
proclamar que
Os grandes designers são tão importantes para o sucesso que os grandes gerentes são, e
que eles podem
espera-se que seja igualmente alimentado e recompensado. Não só salário, mas os
benefícios
de reconhecimento - tamanho do escritório, mobiliário, equipamento técnico pessoal,
fundos de viagem, suporte de pessoal - deve ser totalmente equivalente.

Página 20
Como crescer grandes designers? O espaço não permite uma longa discussão, mas
alguns
As etapas são óbvias:
• Identificar de forma sistemática os melhores designers o mais cedo
possível. O melhor muitas vezes não são os mais experientes.
• Atribuir um mentor de carreira para ser responsável pelo desenvolvimento
da perspectiva, e mantenha cuidadosamente um arquivo de carreira.
• Elaborar e manter um plano de desenvolvimento de carreira para cada
perspectiva, incluindo
Aprendizagem cuidadosamente selecionada com designers de topo, episódios de
avançados educação formal e cursos curtos, todos intercalados com solo-design e
atribuições de liderança técnica.
• Fornecer oportunidades para que os designers em crescimento interajam e
estimulem cada um de outros.
Reconhecimentos
Agradeço Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick e, mais
especialmente David Parnas por suas idéias e idéias estimulantes, e Rebekah Bierly para
a produção técnica deste artigo.
REFERÊNCIAS
[1]
DL Parnas, "Projetando Software para Facilidade de Extensão e Contração ", IEEE
Transactions on Software Engineering , Vol. 5, nº 2, março de 1979, pp. 128-38.
[2]
G. Booch, "Object-Oriented Design", Engenharia de Software com Ada , 1983, Menlo
Park, Califórnia: Benjamin / Cummings.
[3]
Transações da IEEE em Engenharia de Software (questão especial sobre inteligência
e engenharia de software), l. Mostow, convidado ed., Vol. 11, nº 11, Novembro de
1985.
[4]

Página 21
DL Parnas, "Aspectos de Software dos Sistemas Estratégicos de Defesa:" American
Cientista , novembro de 1985.
[5]
R. Balzer, "Uma perspectiva de 15 anos na programação automática", IEEE Transações
sobre engenharia de software (questão especial sobre inteligência artificial e
engenharia de software), J. Mostow, guest ed., Vol. 11, nº 11 (novembro 1985), pp.
1257-67. [6]
Computador (edição especial no programa visual), RB Graphton e T. Ichikawa,
eds convidados, Vol. 18, nº 8, agosto de 1985.
[7]
G. Raeder, "Uma pesquisa da programação gráfica atual
Técnicas, " Computador (edição especial sobre programação visual), RB Graphton e
T. Ichikawa, convidados, Vol. 18, nº 8, agosto de 1985, pp. 11-25.
[8]
FP Brooks, The Mythical Man Month , Reading, Mass .: Addison-Wesley, 1975,
Capítulo 14.
[9]
Conselho de Ciência da Defesa, Relatório da Força-Tarefa sobre Software Militar na
imprensa. [10]
HD Mills, "Programação de cima para baixo em grandes sistemas", na depuração
Técnicas em sistemas grandes , R. Ruskin, ed., Englewood Cliffs, NJ: Prentice-
Salão, 1971. [11]
BW Boehm, "Um modelo espiral de desenvolvimento e aprimoramento de software"
1985, TRW Technical Report 21-371-85, TRW, Inc., 1 Space Park, Redondo Beach,
Califórnia 90278.
[12]
H. Sackman, WJ Erikson e EE Grant, "Estudos exploratórios experimentais
Comparando desempenho de programação on-line e off-line, " Comunicações
of the ACM , Vol. 11, No. 1 (January 1968), pp. 3-11.
Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software
Engineering," Computer , Vol. 20, No. 4 (April 1987) pp. 10-19.