Página 1

Não 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.
Mas, enquanto olhamos para o horizonte de uma década, não vemos nenhuma bala de
prata. 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, vou tentar mostrar por que, examinando a natureza do
problema de software e as propriedades das balas propostas.
O cepticismo não é pessimismo, no entanto. Embora não vejamos avanços
surpreendentes -
e, de fato, acredito que seja inconsistente com a natureza do software - muitos
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. Não existe uma estrada real, mas há uma estrada.
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. Esse passo, o início da esperança,
em
Ele mesmo precipitou todas as esperanças de soluções mágicas. 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
Tem que ser difícil? 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
é abstrato 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 do software de construção seja a especificação,
design e teste
desta construção conceitual, não o trabalho de representá-lo e testar a fidelidade de
a 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 irredutivível do software
moderno
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. Nisso
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-the-
shelf 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.