Object 1

Página 1 No Silver Bullet -Essência e Acidentes em Engenharia de Software Frederick P. Brooks, Jr. University of North Carolina em Chapel Hill Não há desenvolvimento único, em qualquer tecnologia ou gestão técnica, que por si só promete ainda uma ordem de grandeza melhoria dentro de uma década na produtividade, na confiabilidade, na simplicidade. Abstrato 1 Toda a construção de software envolve tarefas essenciais, a confecção do complexo estruturas conceituais que compõem a entidade de software, resumo e tarefas acidentais, o representação dessas entidades abstratas em linguagens de programação e do mapeamento de os em linguagens de máquina dentro de limites de espaço e velocidade. A maior parte do passado grande ganhos de produtividade de software vêm de remoção de barreiras artificiais que têm fez as tarefas acidentais excessivamente duras, tais como restrições de hardware graves, inábeis linguagens de programação, falta de tempo de máquina. Como muito do que software engenheiros agora não é ainda dedicada ao acidental, em oposição ao essencial? A menos que é mais do que 9/10 de todo o esforço, a redução de todas as actividades acidentais para zero o tempo não dar uma ordem de magnitude. Portanto, parece que o tempo veio para tratar as partes essenciais do tarefa software, aqueles preocupados com abstratos formar estruturas conceituais de grande complexidade. Eu sugiro: • • • • Explorando o mercado de massa para evitar a construir o que pode ser comprado. Usando prototipagem rápida como parte de uma iteração planejada no estabelecimento software exigências. Crescer organicamente software, adicionando função cada vez mais para sistemas como elas são executar, usado e testado. Identificar e desenvolver os grandes estilistas conceituais da nova geração. Introdução De todos os monstros que enchem os pesadelos de nosso folclore, nada aterroriza mais do que lobisomens, pois eles transformam inesperadamente do familiar em horrores. Para Destes, buscamos balas de prata que pode colocá-los magicamente para descansar. 1 Reproduzido de: Frederick P. Brooks, A edição de Man-Month aniversário, Mythical com 4 novos capítulos, Addison-Wesley (1995), se reproduzido a partir dos Anais do Mundo Décima IFIP Computing Conference, H.-J. Kugler, ed., Elsevier Science BV, Amsterdam, NL (1986) pp 1069-1076.

Página 2 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 2 O projeto de software familiar tem algo desse personagem (pelo menos como visto pela não-gerente técnico), geralmente inocentes e simples, mas capaz de se tornar um monstro de horários não cumpridos, orçamentos queimados, e os produtos defeituosos. Então

ouvimos desesperados gritos de uma bala de prata, algo para tornar os custos de software cair tão rapidamente quanto computador custos de hardware fazer. Mas, quando olhamos para o horizonte de uma década, portanto, nós não vemos nenhuma bala de prata. Não há desenvolvimento único, em qualquer técnica ou tecnologia de gestão, que por si só promete ainda uma ordem de magnitude na produtividade, em termos de confiabilidade, em simplicidade. Neste capítulo vamos tentar ver o porquê, mas examinando tanto a natureza do problema de software e as propriedades dos marcadores propostos. Ceticismo não é pessimismo, no entanto. Embora não vemos avanços surpreendentes, e, na verdade, acreditar que tal é incompatível com a natureza do software, muitos inovações encorajadores estão em andamento. Um esforço disciplinado e consistente para desenvolver, propagar, e explorá-los de fato deve render uma melhora da ordem de grandeza. Não há estrada real, mas há uma estrada. O primeiro passo para o tratamento da doença foi a troca de teorias demônio e teorias humores pela teoria dos germes. Essa etapa muito, o começo da esperança, em si mesmo tracejada todas as esperanças de soluções mágicas. Ele disse aos trabalhadores o progresso seria feito passo a passo, com grande esforço, e que um cuidado, persistente incessante teria que ser pago a um disciplina de limpeza. Assim é com a engenharia de software hoje. Será que ela tem que ser duro? - Dificuldades Essenciais Não só há nenhuma bala de prata agora em vista, a própria natureza do software torna improvável que haja quaisquer de nenhuma invenção que irá fazer para a produtividade de software, confiabilidade e simplicidade que a integração eletrônica, transistores, e em larga escala fez por hardware do computador. Não podemos esperar que nunca para ver os ganhos de duplas a cada dois anos. Primeiro, devemos observar que a anomalia não é que o progresso software é tão lento, mas que o progresso hardware do computador é tão rápido. Nenhuma outra tecnologia desde a civilização começou viu seis ordens de magnitude ganho de preço-desempenho em 30 anos. Em nenhum outro tecnologia pode-se escolher para levar o ganho em qualquer um melhor desempenho ou reduzida custos. Estes ganhos de fluxo a partir da transformação de fabricação de um computador indústria de montagem em uma indústria de processo. Em segundo lugar, para ver qual a taxa de progresso que podemos esperar em tecnologia de software, vamos examinar as suas dificuldades. Seguindo Aristóteles, eu dividi-los em sua essência as dificuldades de inerente à natureza do software e acidentes-essas dificuldades que hoje frequentam a sua produção, mas que não são inerentes. Os acidentes de discutir na próxima seção. Primeiro vamos considerar a essência. 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. Esta essência é abstrata, em que a construção conceitual é o mesmo sob os mais representações. No entanto, é altamente precisa e rica em detalhes. Eu acredito que a parte mais difícil da construção de software para a especificação, projeto, teste e desta construção conceitual, e não o trabalho de representá-lo e testar a fidelidade do representação. Nós ainda cometemos erros de sintaxe, para ter certeza, mas eles são fuzz em comparação com o erros conceituais na maioria dos sistemas.

Página 3 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 3 Se isso for verdade, a construção de software será sempre difícil. Há é inerentemente não prata bala. Vamos considerar as propriedades inerentes a esta essência irredutível de software moderna sistemas: a complexidade, conformidade, mutabilidade, invisibilidade e. Entidades de software de complexidade. São mais complexas para o seu tamanho do que talvez qualquer outro humano construir, porque não há duas peças iguais (pelo menos acima do nível de instrução). Se eles são, fazemos as duas partes semelhantes em um, um sub-rotina, aberta ou fechada. Neste sistemas de software respeito diferem profundamente a partir de computadores, edifícios ou automóveis, onde os elementos repetidos abundam. Os computadores digitais são-se mais complexa do que a maioria das coisas que as pessoas construir, eles tem um grande número de estados. Isso faz com que conceber, descrever, e testá-las rígido. Os sistemas de software têm ordens de magnitude mais estados do que os computadores fazem. Da mesma forma, uma ampliação de uma entidade de software não é apenas uma repetição do mesmo elementos em tamanho maior, que é necessariamente um aumento no número de elementos diferentes. Na maioria dos casos, os elementos interagem uns com os outros, de alguma forma não-linear, ea complexidade do conjunto aumenta muito mais do que linearmente. A complexidade do software é de propriedade essencial, não acidental. Por isso descrições de uma entidade de software que abstrair a sua complexidade, muitas vezes abstrair sua essência. Matemática e as ciências físico feito grandes progressos durante três séculos por construção de modelos simplificados de fenômenos complexos, derivando propriedades do modelos e verificando as propriedades experimentalmente. Isso funcionou porque o complexidades ignorados nos modelos não foram as propriedades essenciais dos fenômenos. Ele não funciona quando as complexidades são a essência. Muitos dos problemas clássicos de produtos de software de desenvolvimento derivado deste complexidade essencial e não-linear da sua aumentou com o tamanho. A partir da complexidade vem a dificuldade de comunicação entre os membros da equipe, o que leva a falhas de produtos, o custo derrapagens, atrasos na programação. A partir da complexidade vem a dificuldade de enumerar, compreensão muito menos, todos os estados possíveis do programa, e de que trata o falta de confiabilidade. A partir da complexidade das funções vem a dificuldade de invocar os funções, o que torna os programas difíceis de usar. De complexidade da estrutura vem do dificuldade de estender programas a novas funções, sem criar efeitos colaterais. A partir do complexidade da estrutura vem do estado unvisualized que que constituem a segurança alçapões. Não só problemas técnicos, mas problemas de gestão, bem vir da complexidade. Esta complexidade torna difícil visão, impedindo assim a integridade conceitual. Isso torna mais difícil encontrar e controlar todas as pontas soltas. Ele cria o grande aprendizado e carga entendimento pessoal que faz volume de negócios um desastre. Software pessoas da conformidade. Não está sozinho para enfrentar a complexidade. Lida com física objetos muito complexos, mesmo a nível partícula "fundamental". Os trabalhos físico em diante, no entanto, em uma fé firme que existem princípios unificadores a ser encontrados, quer no

quarks ou em teorias do campo unificado. Einstein argumentou repetidamente que deve haver simplificado explicações da natureza, porque Deus não é caprichoso ou arbitrário. Sem essa fé conforta o engenheiro de software. Muito da complexidade, ele deve mestre é a complexidade arbitrária, forçada sem rima ou razão pela humano muitos

Página 4 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 4 instituições e sistemas para que suas interfaces devem confirmar. Estes diferem da interface a interface, e de vez em quando, não por causa da necessidade, mas apenas porque eram desenhado por pessoas diferentes, e não por Deus. Em muitos casos o software tem de confirmar porque tem mais recentemente para o cena. Em outros, devem estar de acordo porque é percebido como o mais adaptável. Mas, na todos os casos, a complexidade muito vem de conformação para outras interfaces, o que não pode ser simplificado por qualquer redesenho do software sozinho. Mutabilidade. A entidade software está constantemente sujeito a pressões por mudança. De Naturalmente, assim que são prédios, carros e computadores. Mas as coisas raramente são manufaturados mudou após o fabrico, eles são substituídos por modelos mais recentes, ou mudanças essenciais são incorporada em posteriores número serial cópias do mesmo projeto básico. Callbacks de automóveis são realmente muito raras, alterações no campo de computadores um pouco menos. Ambos são muito menos freqüentes do que modificações de software em campo. Em parte, isso ocorre porque o software em um sistema incorpora a sua função, ea função é a parte que mais sente as pressões da mudança. Em parte é porque o software pode ser mudado mais facilmente ele é puro pensamento coisas, infinitamente maleável. Edifícios de fato se mudado, mas os altos custos da mudança, entendidas por todos, servem para amortecer o capricho dos trocadores. Todo o software de sucesso é alterado. Dois processos estão no trabalho. Como um software produto é encontrado para ser útil, as pessoas experimentá-lo em novos casos na borda de, ou além, o domínio original. As pressões para a função estendida vêm principalmente de usuários que gostem a função básica e inventar novos usos para ele. Segundo, o software bem-sucedido também sobrevive além da vida normal da máquina veículo para o qual é primeiro escrita. Se não computadores novos, então, pelo menos, novos discos, de novo monitores, impressoras novas vêm junto, e o software deve ser conformado com a sua nova veículos de oportunidade. Em suma, o software está embutido em uma matriz cultural de aplicações, usuários, leis, e os veículos de máquinas. Estes mudam tudo continuamente, e suas alterações inexoravelmente forçar a mudança sobre o produto de software. Invisibilidade. Software é invisível e montante invisualizável. Abstrações geométricas são ferramentas poderosas. A planta de um edifício de ajuda tanto o arquiteto e cliente avaliar espaços, fluxos de tráfego e pontos de vista. Contradições tornam-se evidentes, as omissões podem ser pego. Desenhos à escala de peças mecânicas e vara-figura modelos de moléculas, apesar de abstrações, servem ao mesmo propósito. Uma realidade geométrica é capturado em um abstração geométrica. A realidade do software não é inerentemente incorporada no espaço. Por isso, não tem nenhuma

pronto representação geométrica da forma que a terra tem os mapas, os chips de silício têm diagramas, computadores têm esquemas de conectividade. Assim que tentamos software diagrama estrutura, descobrimos que a constituem não apenas uma, mas várias, gerais grafos dirigidos, sobrepostos uns sobre os outros. Os gráficos vários pode representar o fluxo de controlo, o fluxo de dados, padrões de dependência, seqüência de tempo, o nome de espaço-relacionamentos. Estes não são geralmente planar mesmo, e muito menos hierárquica. De fato, uma das formas de

Página 5 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 5 estabelecer o controle conceitual sobre tal estrutura é aplicar o corte ligação até que um ou mais dos gráficos torna-se hierárquica. 2 Apesar dos progressos em restringir e simplificar as estruturas de software, eles permanecem inerentemente montante invisualizável, privando assim a mente de alguns de seus mais poderosos ferramentas conceituais. Esta falta não só impede o processo de projeto dentro de uma mente, dificulta severamente a comunicação entre mentes. Avanços últimos Resolvido dificuldades acidentais Se examinarmos os três passos na tecnologia de software que têm sido mais frutífera no passado, descobrimos que cada atacaram uma dificuldade diferente importante na construção de software, mas eles têm sido as dificuldades acidentais, não essencial,. Nós também podemos ver o natural limites para a extrapolação de cada tal ataque. Linguagens de alto nível. Certamente o curso mais poderosa para a produtividade de software, confiabilidade e simplicidade tem sido a utilização progressiva de linguagens de alto nível para programação. A maioria dos observadores de crédito de desenvolvimento que com pelo menos um fator de cinco em produtividade, e com ganhos concomitantes em confiabilidade, inteligibilidade, simplicidade e. O que faz uma linguagem de alto nível realizar? Ele libera um programa de grande parte da sua complexidade acidental. Um programa abstrato consiste de construções conceituais: operações, tipos de dados, seqüências e de comunicação. O programa da máquina de concreto é preocupado com pedaços, registos, condições, galhos, canais, discos e tal. Para o medida em que a linguagem de alto nível incorpora as construções queria em abstrato programa e evita todos os entes inferiores, que elimina todo um nível de complexidade que era nunca inerente ao programa de todo. O máximo que uma linguagem de alto nível pode fazer é fornecer todas as construções do programador imagina no programa abstrato. Para ter certeza, o nível de nossa sofisticação no pensamento sobre estruturas de dados, tipos de dados e operações de crescimento constante, mas a um cada vez diminuição da taxa. E desenvolvimento da linguagem se aproxima mais e mais perto do sofisticação dos usuários. Além disso, em algum momento a elaboração de uma linguagem de alto nível se torna um fardo que os aumentos, não reduz, a tarefa intelectual do usuário que raramente usa o esotérico construções. Compartilhamento de tempo. A maioria dos observadores de crédito de compartilhamento de tempo com uma grande melhoria na produtividade dos programadores e na qualidade dos seus produtos, embora não tão grande como que trouxe por linguagens de alto nível.

Time-sharing ataca uma dificuldade bem diferente. Compartilhamento de tempo preserva imediatismo e, portanto, nos permite manter uma visão geral da complexidade. A lenta turnaround da programação lote significa que, inevitavelmente, esquecer as minúcias, se não o muito impulso, do que estávamos pensando quando nós paramos de programação e chamado para compilação e execução. Esta interrupção de consciência é caro no tempo, para nós deve atualizar. O efeito mais grave pode muito bem ser a decadência da compreensão de tudo o que está acontecendo em em um sistema complexo. 2 Parnas, DL, "Projetando software para facilitar a extensão e contração," IEEE Trans. em SE, 5, 2 (Março, 1979), pp 12-138.

Página 6 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 6 Lento turn-around, como linguagem de máquina complexidades, é uma vez acidental de uma dificuldade essencial do processo de software. Os limites da contribuição de time-sharing derivam diretamente. O efeito princípio é para encurtar o tempo de resposta do sistema. Como se vai para zero, em algum ponto, passa o limiar humano de noticeability, cerca de 100 milisegundos. Além disso há benefícios são esperados. Unificadas ambientes de programação. Unix e Interlisp, o primeiro integrado ambientes de programação para entrar em uso generalizado, são percebidas ter melhorado produtividade por fatores integrais. Por quê? Eles atacam as dificuldades acidentais de uso de programas em conjunto, fornecendo bibliotecas integradas, formatos de arquivos unificados e pilhas e filtros. Como resultado, conceptual estruturas que, em princípio, pode sempre chamar, alimentar, e usar um outro fato pode facilmente fazê-lo na prática. Esta descoberta, por sua vez estimulou o desenvolvimento de toolbenches inteiros, desde cada nova ferramenta pode ser aplicada a todos os programas usando os formatos padrão. Devido a esses sucessos, os ambientes são objecto de grande parte dos softwares de hoje de pesquisa de engenharia. Vamos olhar para a sua promessa e limitações na próxima seção. Esperanças para o Prata Agora vamos nos considerar os desenvolvimentos técnicos que são mais frequentemente apresentados como potenciais balas de prata. Quais os problemas que eles tratam? São eles os problemas de essência, ou são restos de nossas dificuldades acidentais? Será que eles oferecem avanços revolucionários, ou aqueles incrementais? Ada e outros avanços linguagem de alto nível. Um dos mais elogiado recente desenvolvimentos é a linguagem de programação Ada, um general-purpose, linguagem de alto nível da década de 1980. Ada de fato não só reflete as melhorias evolutivas na linguagem conceitos, mas incorpora recursos para incentivar o design moderno e modularização conceitos. Talvez a filosofia Ada é mais um avanço do que a linguagem Ada, para é a filosofia de modularização, de tipos de dados abstratos, de estruturação hierárquica. Ada é, talvez, mais rica, o produto natural do processo pelo qual os requisitos foram estabelecidas em seu design. Isso não é fatal, por vocabulários subconjunto de trabalho pode resolver o problema de aprendizagem, e os avanços de hardware nos dará as MIPS baratos para pagar o compilação custos. Avançando a estruturação de sistemas de software é de fato um bem muito

usar para os MIPS maiores nossos dólares vai comprar. Os sistemas operacionais, alto condenada nos 1960 para a sua memória e os custos de ciclo, provaram ser uma forma excelente para usar alguns dos MIPS e bytes de memória baratos do aumento hardware passado. No entanto, Ada não irá provar ser a bala de prata que mata o software monstro produtividade. É, afinal, outra linguagem de alto nível, ea maior pagamento de tais línguas veio a primeira transição, a partir do acidental complexidades da máquina para a declaração mais abstrato do passo-a-passo soluções. Uma vez que os acidentes tenham sido removidos, os demais são menores, e os lucros de sua remoção será certamente menor. Eu prevejo que daqui a uma década, quando a eficácia da Ada é avaliado, será visto ter feito uma diferença substancial, mas não por causa de uma língua, recurso, nem, aliás, porque de todos eles juntos. Nem a Ada de novo

Página 7 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 7 ambiente provar ser a causa de as melhorias. A maior contribuição de Ada vontade ser que a mudança para que os programadores de formação ocasionadas em design de software moderna técnicas. Programação orientada a objetos. Muitos estudantes da arte aguentar mais esperança para a objeto programação orientada do que para qualquer um dos outros fads técnicas do dia. 3 Eu estou no meio eles. Mark Sherman de notas Dartmouth que devemos ter o cuidado de distinguir duas idéias distintas que vão com esse nome: tipos de dados abstratos e tipos hierárquicos, também chamados de classes. O conceito de tipo abstrato de dados é que um tipo de objeto deve ser definido por um nome, um conjunto de valores apropriados, e um conjunto de operações apropriadas, em vez da sua estrutura de armazenamento, o que deve ser escondido. Exemplos disso são os pacotes Ada (com particular tipos) ou módulos de Modula. Tipos hierárquicos, como Simula-67 de classes, permitir que a definição de geral interfaces que podem ser aperfeiçoadas, fornecendo tipos subordinados. Os dois conceitos são ortogonais, pode haver hierarquias sem esconder e esconder, sem hierarquias. Ambos os conceitos representam avanços reais na arte de construção de software. Cada remove uma maior dificuldade acidental do processo, permitindo que o desenhador para expressar a essência de seu projeto sem a necessidade de expressar grandes quantidades de sintática material que não acrescentam conteúdo de informação nova. Para ambos os tipos abstratas e hierárquicas tipos, o resultado é para remover uma espécie de ordem superior de dificuldade acidental e permitir que um de ordem mais elevada expressão de design. No entanto, tais avanços não pode fazer mais do que remover todo o acidental dificuldades da expressão do desenho. A complexidade do desenho em si é essenciais, ataques e tal não fazem qualquer mudança nisso. Um ganho de ordem de grandeza pode ser feita por programação orientada por objectos apenas se o mato desnecessária de tipo especificação permanecendo hoje em nossa linguagem de programação é ele próprio responsável

por nove- décimos do trabalho envolvido na concepção de um produto de programa. Duvido. A inteligência artificial. Muitas pessoas esperam que os avanços na inteligência artificial para fornecer o avanço revolucionário que vai dar ordem de grandeza ganhos em software produtividade e qualidade. 4 Eu não. Para ver o porquê, devemos dissecar o que se entende por "Inteligência artificial" e depois ver como ela se aplica. Parnas esclareceu o caos terminológico: Duas definições muito diferentes de AI estão em uso comum hoje em dia. AI-1: A utilização de computadores para resolver problemas que antes só poderiam ser resolvidos pela aplicação humana inteligência. AI-2: A utilização de um conjunto específico de técnicas de programação sabe como heurística ou regra baseada em programação. Nesta abordagem peritos humanos são estudos para determinar o que heurísticas ou regras de ouro que eles usam para resolver problemas. . . . O programa é projetado para resolver um problema da maneira que os seres humanos parecem resolvê-lo. 3 Booch, G., "design orientado a objetos", em Engenharia de Software com Ada. Menlo Park, Califórnia: Benjamin Cummings, 1983. 4 Mostow, J., ed., Edição Especial de Inteligência Artificial e Engenharia de Software, IEEE Trans. em SE, 11, 11 (Nov. 1985).

Página 8 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 8 A primeira definição tem um significado de deslizamento. . . . Algo pode caber a definição de AI-1 mas hoje, uma vez vemos como funciona o programa e entender o problema, vamos não pense nisso como AI mais. . . . Infelizmente eu não posso identificar um corpo de tecnologia que é exclusivo para este campo. . . . A maior parte do trabalho é problema específico, e alguns abstração nem criatividade é exigir para ver como transferi-lo. 5 Concordo completamente com essa crítica. As técnicas utilizadas para o reconhecimento de voz parecem ter pouco em comum com os utilizados para reconhecimento de imagem, e ambos são diferentes daqueles usados em sistemas de peritos. Eu tenho dificuldade em ver como a imagem reconhecimento, por exemplo, vai fazer nenhuma diferença significativa na prática de programação. O mesmo é tentar de reconhecimento de fala. A coisa dura sobre a construção de software é decidir o que dizer, não dizendo isso. Não facilitação da expressão pode dar mais do que marginal ganhos. Especialista sistemas de tecnologia, AI-2, merece uma seção própria. Os sistemas especialistas. A parte mais avançada da arte da inteligência artificial, ea maioria dos amplamente aplicável, é a tecnologia para a construção de sistemas especialistas. Muitos cientistas de software estão trabalhando duro para aplicar esta tecnologia para o ambiente de software edifício. 6 O que é o conceito, e quais são as perspectivas?

Um sistema especialista é um programa que contém um motor de inferência generalizada e uma regra base, projetado para tirar os dados e hipóteses e explorar as conseqüências lógicas através das inferências deriváveis da base de regra, conclusões produzindo e conselhos, e oferecendo-se para explicar os seus resultados por refazer seu raciocínio para o usuário. A inferência motores normalmente pode lidar com dados nebulosos ou probabilística e regras, além de puramente lógica determinista. Esses sistemas oferecem algumas vantagens claras sobre algoritmos programados para chegar nas mesmas soluções para os mesmos problemas: • • Tecnologia de motor de inferência é desenvolvido de forma independente de aplicação, e depois aplicado a muitas utilizações. Pode-se justificar um esforço muito maior nos motores de inferência. Na verdade, que a tecnologia está bastante avançada. As partes mutáveis das matérias-aplicação peculiares são codificados na base de regras de uma forma uniforme, e as ferramentas são fornecidas para o desenvolvimento, mudando, testando, e documentando a base de regras. Este regulariza muito da complexidade da aplicação si. Edward Feigenbaum diz que o poder de tais sistemas não vem de sempre mecanismos mais sofisticados de inferência, mas sim de bases de conhecimento cada vez mais ricas, que refletem o mundo real com mais precisão. Creio que o mais importante avanço oferecido pelo tecnologia é a separação da complexidade da aplicação do próprio programa. Como isto pode ser aplicado para a tarefa de software? De muitas maneiras: interface sugerindo regras, aconselhando sobre estratégias de ensaio, mas lembrando-se do tipo freqüências, oferecendo dicas de otimização, etc 5 Parnas, DL, "Aspectos de software de sistemas estratégicos de defesa", Communications of the ACM, 28, 12 (dezembro, 1985), pp 1326-1335. Também em American Scientist, 73, 5 (setembro-outubro de 1985), pp 432-440. 6 Balzer, R., "Uma perspectiva de 15 anos em programação automática," em Mostow, op. cit.

Página 9 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 9 Considere um assessor testes imaginário, por exemplo. Na sua forma mais rudimentar, o sistema especialista de diagnóstico é muito parecido com uma lista de verificação piloto, fundamentalmente oferecer sugestões quanto a possíveis causas de dificuldade. Como a base de regras foi desenvolvido, a sugestões tornam-se mais específico, tendo em conta mais sofisticada do problema os sintomas relatados. Pode-se visualizar um assistente de depuração, que oferece muito generalizada sugestões no início, mas como estrutura do sistema cada vez mais está incorporado na base de regras, vem mais e mais em particular no hipóteses é gera e os ensaios, recomenda. Tal sistema especialista pode afastar mais radicalmente do convencional

aqueles em que sua base de regras provavelmente deve ser hierarquicamente modularizado da mesma forma o produto de software correspondente é, de modo que à medida que o produto é modularmente modificada, o base de regras de diagnóstico pode ser modularmente modificado também. O trabalho necessário para gerar as regras de diagnóstico é o trabalho que terá de ser feito de qualquer maneira a gerar o conjunto de casos de teste para os módulos de e para o sistema. Se isso for feito de forma adequada geral, com uma estrutura uniforme de regras e uma boa inferência motor disponível, ele pode realmente reduzir o trabalho total da produção de trazer-se casos de teste, bem como ajudar na manutenção ao longo da vida e teste de modificação. Da mesma forma, nós pode postular outros conselheiros mais provavelmente muitos deles e, provavelmente, simples para o outras partes do tarefa de construção de software. Muitas dificuldades estão no caminho da realização antecipada de consultores especializados úteis para o desenvolvedor do programa. Uma parte crucial do nosso cenário imaginário é o desenvolvimento de fácil maneiras de se obter a partir de especificação da estrutura do programa para o automático ou semi-automático geração de regras de diagnóstico. Ainda mais difícil e importante é a dupla tarefa de aquisição de conhecimento: encontrar articulados, auto-analíticas especialistas que sabem por que eles fazem coisas, e desenvolvimento de técnicas eficientes para extrair o que eles sabem e distilando em bases de regras. O pré-requisito essencial para a construção de um sistema especialista é ter uma especialista. A contribuição mais poderosa de sistemas especialistas será certamente de colocar ao serviço do programador inexperiente a experiência e sabedoria acumulada dos melhores programadores. Isto não é pequena contribuição. A diferença entre o melhor software prática da engenharia e da prática média é muito grande, talvez maior do que em qualquer disciplina engenharia. Uma ferramenta que difunde as boas práticas seria importante. "Automatic" de programação. Por quase 40 anos, as pessoas têm vindo a antecipar e escrevendo sobre "programação automática", a geração de um programa para resolver um problema a partir de uma declaração sobre as especificações do problema. Algumas pessoas hoje escrevem como se eles esperavam que esta tecnologia para fornecer o próximo avanço. 7 Parnas implica que o termo é usado para o glamour e conteúdo não semântica, afirmando, Em suma, a programação automática sempre foi um eufemismo para a programação com uma linguagem de alto nível do que era presentemente disponíveis para o programador. 8 Ele argumenta, em essência, que na maioria dos casos é o método de solução, não do problema, cuja especificação tem que ser dado. 7 Mostow, op. cit. 8 Parnas, 1985, op. cit.

Página 10 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986)

10 Exceções podem ser encontrados. A técnica de construção de geradores é muito poderoso, e é rotineiramente usado para boa vantagem em programas de triagem. Alguns sistemas para equações diferenciais que integram também permitido especificação direta do problema. O sistema de avaliação dos parâmetros, escolheu a partir 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 caracterizada por parâmetros relativamente poucos. Existem muitos métodos conhecidos de solução para fornecer uma biblioteca de alternativas. Extensa análise levou a regras explícitas para a seleção de técnicas de solução, dada parâmetros do problema. É difícil ver como estas técnicas podem ser generalizadas para o resto do mundo do comum sistema de software, onde os casos com as mesmas propriedades limpas são a exceção. É difícil mesmo imaginar como este avanço na generalização poderia concebivelmente ocorrer. Programação gráfica. Um tema favorito para PH.D. dissertações em software engenharia é gráfica, ou visual, a programação, a aplicação da computação gráfica para design de software. 9 Às vezes, a promessa de uma tal abordagem é postulada a partir da analogia com o design de chips VLSI, onde computação gráfica desempenha um papel tão fecunda. Às vezes, a abordagem é justificada por fluxogramas, considerando que o programa ideal médio, design e fornecimento de instalações poderosas para construí-las. Nada mesmo convincente, muito menos emocionante, tenha surgido a partir de tais esforços. Eu estou convencido de que nada vai. Em primeiro lugar, como já argumentei em outros lugares, o fluxograma é uma abstração muito pobre da estrutura de software. 10 Na verdade, ele é melhor visto como Burks, von Neumann e Goldstine tentativa de fornecer uma linguagem de controle precisava desesperadamente de alto nível para a sua proposta computador. No, multipage lamentável, a forma de conexão na caixa para que o fluxo gráfico foi hoje elaborado, que provou ser essencialmente inútil como um desenho da ferramenta- programadores desenhar fluxogramas depois, não antes, escrevendo os programas que eles descrevem. Em segundo lugar, as telas de hoje são muito pequenas, em pixels, para mostrar tanto o âmbito eo resolução de qualquer diagrama de software sério detalhada. A chamada "metáfora do desktop" de estação de trabalho de hoje é, em vez de um "avião-assento" metáfora. Qualquer pessoa que tenha baralhado um lapful de documentos enquanto estiver sentado em um ônibus entre dois passageiros corpulentos irá reconhecer o diferença de um pode ver apenas algumas poucas coisas de uma só vez. O desktop verdade fornece visão geral e de acesso aleatório para uma contagem de páginas. Além disso, quando se encaixa de longo criatividade forte, mais do que um programador ou o escritor tem sido conhecida a abandonar a área de trabalho para

o piso mais espaçoso. A tecnologia de hardware terão que avançar bastante substancialmente antes do alcance de nossos espaços é suficiente para a tarefa de design de software. Mais fundamentalmente, como já afirmei acima, o software é muito difícil de visualizar. Quer que o fluxo de controle diagrama, escopo de variáveis de nidificação, variável referências cruzadas, dados golpe, estruturas hierárquicas de dados, ou qualquer outra coisa, sentimo-nos apenas uma dimensão do intrinsecamente interligados elefante software. Se sobrepor todos os diagramas gerados pelos muitos pontos de vista relevantes, é difícil extrair qualquer visão global. A VLSI 9 Raeder, G., "Um levantamento das atuais técnicas de programação gráfica," em RB Grafton e Ichikawa T., eds., Edição Especial sobre Programação Visual, Computação, 18, 8 (agosto, 1985), pp 11-25 10 Brooks 1995, op. cit., capítulo 15.

Página 11 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 11 analogia é fundamentalmente enganosa-a de design de chips é um objeto bidimensional em camadas cuja geometria reflecte a sua essência. Um sistema de software não é. Verificação do programa. Muito do esforço em programação moderna vai para o teste e reparação de bugs. Existe talvez uma bala de prata para ser encontrado, eliminando os erros em a fonte, na fase de projeto do sistema? Pode tanto a produtividade e confiabilidade do produto ser radicalmente melhorar seguindo a estratégia é profundamente diferente de provar projetos corrigir antes do imenso esforço é vertida para a implementação e testá-las? Eu não acredito que vamos encontrar a magia aqui. Verificação do programa é um poderoso conceito, e ele será muito importante para coisas como kernels de sistemas operacionais seguras. A tecnologia não promete, no entanto, para salvar o trabalho. As verificações são muito trabalhar que apenas alguns programas substanciais já foram verificados. Verificação do programa não significa à prova de erros de programas. Não há mágica aqui, quer. Provas matemáticas também pode estar com defeito. Assim que a verificação pode reduzir o programa de testes de carga, não se pode eliminá-la. Mais a sério, até mesmo verificação programa perfeito que só pode estabelecer um programa cumpre a sua especificação. A parte mais difícil da tarefa software é chegar a uma completa e especificação consistente, 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 esperados a partir da explosão pesquisas em melhores ambientes de programação? Uma da reacção instintiva é que o grande recompensa problemas foram os primeiros atacados, e foram resolvidos: arquivo hierárquico sistemas, formatos de ficheiros uniformes de modo a ter interfaces de programação uniformes, e generalizada ferramentas. Específicos do idioma editores inteligentes são desenvolvimentos ainda não amplamente utilizados na prática, mas a maioria o que eles prometem é a liberdade de erros sintáticos e simples erros de semântica. Talvez o maior ganho ainda a ser realizado no ambiente de programação é o uso de sistemas de banco de dados integrados para manter o controle das miríades de detalhes que devem ser recordar com precisão pelo programador individual e mantidos corrente em um grupo de

colaboradores em um único sistema. Certamente este trabalho vale a pena, e certamente ele vai dar alguns frutos, tanto a produtividade e confiabilidade. Mas por sua própria natureza, o retorno a partir de agora deve ser marginal. As estações de trabalho. Que ganhos são de esperar para a arte do software certo e rápido aumento da capacidade de energia e memória da estação de trabalho individual? Bem, quantos MIPS pode usar um fruto? A composição e edição de programas e documentos é totalmente suportado por velocidades de hoje. Compilando pode resistir a um impulso, mas um fator de 10 em velocidade da máquina, certamente, deixar pensar tempo da atividade dominante no dia do programador. Na verdade, parece ser assim agora. Estações de trabalho mais poderosas que certamente bem-vindos. Melhorias mágicas deles não podemos esperar.

Página 12 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 12 Ataques promissores na essência conceitual Mesmo que nenhum avanço tecnológico promete dar o mole de mágica resultados que nos são tão familiares na área de hardware, não é tanto uma abundância de bom funcionamento acontecendo agora, ea promessa de constante progresso espetacular, se. Todos os ataques tecnológicos sobre os acidentes do processo de software são fundamentalmente limitada pela equação produtividade: Hora da task = Σ (Frequency) Eu x (Time) Eu Se, como acredito, os componentes conceituais da tarefa estão agora a tomar a maior parte do tempo, então não há quantidade de atividade sobre os componentes de tarefas que são meramente a expressão de os conceitos podem dar grandes ganhos de produtividade. Por isso, devemos considerar esses ataques que se dirigem a essência do software problema, a formulação dessas estruturas complexas conceptuais. Felizmente, alguns dos estes são muito promissores. Compre contra construir. A solução mais radical possível para a construção de software não é construí-la de todo. Todo dia isso se torna mais fácil, pois mais e mais vendedores oferecem mais e melhor produtos de software para uma variedade estonteante de aplicações. Enquanto nós, engenheiros de software trabalharam na metodologia de produção, a revolução do computador pessoal foi criado não um, mas m qualquer, mercados de massa para software. Cada banca realizada mensalmente revistas que, classificadas por tipo de máquina, propaganda e rever dezenas de produtos no preços de alguns dólares para algumas centenas de dólares. Fontes mais especializadas oferecem muito poderosos produtos para a estação de trabalho Unix e outros mercados. Mesmo portagens de software e ambientes podem ser comprados off-the-shelf. Eu tenho outro lugar propôs um mercado local para Os módulos individuais. Qualquer desses produtos é mais barato comprar do que construir de novo. Mesmo a um custo de US $ 100.000,

comprou um pedaço de software está custando apenas tanto quanto um programador ano. E a entrega é imediata! Imediata, pelo menos, para os produtos que realmente existem, produtos cujo desenvolvedor pode referir-se a perspectiva de um usuário feliz. Além disso, tais produtos tendem para ser muito melhor documentado e um pouco melhor do que manter software homegrown. O desenvolvimento do mercado de massa é, creio eu, a mais profunda tendência de longo prazo em engenharia de software. O custo do software tem sido sempre o custo de desenvolvimento, não custo de replicação. Compartilhando esse custo até mesmo entre alguns usuários radicalmente corta o por usuário custo. Outra maneira de olhar para ele é que o uso de n cópias de um sistema de software efetivamente multiplica a produtividade de seus desenvolvedores, n. Isso é um aprimoramento da a produtividade da disciplina e da nação. O aspecto fundamental, é claro, é aplicabilidade. Posso usar um pacote off-the-shelf disponíveis para fazer a minha tarefa? Uma coisa surpreendente aconteceu aqui. Durante os anos 1950 e 1960, estudar após estudo mostrou que os usuários não usaria off-the-shelf pacotes para folha de pagamento, estoque controle, contas a receber, etc As exigências eram muito especializado, caso a caso variação muito alta. Durante a década de 1980, encontramos tais pacotes em alta demanda e uso generalizado. O que mudou? Na verdade não os pacotes. Eles podem ser de alguma forma mais generalizada e um tanto mais personalizável do que antigamente, mas não muito. Na verdade não as aplicações, também. Se

Página 13 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 13 nada, as necessidades empresariais e científicos de hoje estão mais diversificadas, mais complicado do que as de 20 anos atrás. A grande mudança foi na relação custo de hardware / software. O comprador de US $ 2 - milhões de máquinas em 1960, senti que ele podia pagar 250.000 dólares a mais por um folha de pagamento personalizado programa, que escorregou com facilidade e sem interrupção para o social-computador hostil ambiente. Os compradores de máquinas de escritório R $ 50.000, hoje, não pode concebivelmente pagar programas personalizados de folha de pagamento, de modo que eles se adaptam seus processos de folha de pagamento para os pacotes disponível. Computadores são agora tão comum, ainda que não tão amado, que as adaptações são aceitos como uma questão de disciplina. Há exceções dramáticas para o meu argumento de que a generalização do software pacotes mudou pouco ao longo dos anos: planilhas eletrônicas e banco de dados simples sistemas. Essas ferramentas poderosas, tão óbvios em retrospecto, e ainda tão tarde aparecendo, emprestar -se a uma miríade de usos, alguns bastante heterodoxo. Livros de artigos e até agora abundam sobre como lidar com tarefas inesperadas com a planilha. Um grande número de aplicações que anteriormente foram escritos como programas personalizados no Programa Cobol ou Report Gerador são agora rotineiramente feito com essas ferramentas. Muitos usuários já operam seus próprios computadores dia a dia sobre variados aplicações sem ter que escrever um programa. Na verdade, muitos desses usuários não podem escrever novos programas para suas máquinas, mas eles são, no entanto, perito em resolver novo problemas com eles.

Eu acredito que a estratégia de produtividade mais poderoso software para o homem organizações a dia é equipar os trabalhadores computador virgens intelectual na linha de fogo com computadores pessoais e generalizada boa escrita, desenho de arquivo e planilha programas, e transformá-los soltos. A mesma estratégia, com programação simples capacidades, também irá trabalhar para centenas de cientistas de laboratório. Requisitos requinte e prototipagem rápida. A parte mais difícil de construir um único sistema de software é decidir precisamente o que construir. Nenhuma outra parte do trabalho conceptual é difícil como estabelecer os requisitos técnicos detalhados, incluindo todos os interfaces para pessoas, para máquinas, e outros sistemas de software. Nenhuma outra parte do trabalhar para aleija o sistema resultante se feito errado. Nenhuma outra parte é ir mais difícil rectificar mais tarde. Portanto, a função mais importante que os construtores de software fazem para os seus clientes é o iterativo de extração e refinamento dos requisitos do produto. Pois a verdade é, o os clientes não sabem o que querem. Eles geralmente não sabem que perguntas devem ser respondeu, e quase nunca ter pensado o problema no detalhe que deve ser especificada. Mesmo a simples resposta "Faça o trabalho novo sistema de software como o nosso velho sistema de processamento de informações manual "é na verdade muito simples. Os clientes nunca quer exatamente isso. Sistemas de software complexos são, além disso, as coisas que funcionam, que se movem, que trabalhar. A dinâmica da ação que são difíceis de imaginar. Assim, no planejamento de qualquer software actividade, é necessário para permitir uma iteração extensa entre o cliente eo designer como parte da definição do sistema. Eu iria um passo além e afirmar que é realmente impossível para os clientes, mesmo aqueles trabalhando com os engenheiros de software, para especificar completamente, precisamente, e corretamente a exata requisitos de um produto de software moderno antes de ter construído e tentei algumas versões do o produto que está especificando.

Página 14 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 14 Por isso, um dos mais promissores dos esforços tecnológicos atuais, e um que ataca a essência, não os acidentes, do problema de software, é o desenvolvimento de abordagens e ferramentas para prototipagem rápida de sistemas como parte da iterativa especificação de requisitos. Um sistema de software protótipo é um que simula as interfaces importantes e executa as principais funções do sistema que se destina, embora não sendo necessariamente vinculados por a velocidade do mesmo hardware, tamanho ou restrições de custo. Protótipos normalmente executam a tarefas da linha principal da aplicação, mas não fazem qualquer tentativa para manipular as exceções, responder corretamente para entradas inválidas, abortar de forma limpa, etc O objetivo do protótipo é para fazer estrutura do real conceptual especificado, de modo que o cliente pode testá-lo para a consistência e usabilidade Muito dos atuais procedimentos de aquisição de software se baseia na suposição de que

pode-se especificar um sistema satisfatório de antecedência, obter lances para a sua construção, tê-lo construído, e instalá-lo. Eu acho que essa suposição é fundamentalmente errado, e que muitos software de aquisição de primavera problemas daquela falácia. Por isso, eles não podem ser fixadas sem revisão fundamental, aquela que proporciona o desenvolvimento iterativo e especificação de protótipos e produtos. Desenvolvimento incremental - crescer, não construir, o software ainda me lembro o choque que senti na. 1958, quando ouvi pela primeira vez uma palestra amigo sobre a construção de um programa, em vez de escrever um. Em um flash ser ampliou minha visão de conjunto do processo de software. A mudança foi metáfora potente e preciso. Hoje entendemos como outro edifício como processa a construção de software é, e nós livremente utilizar outros elementos da metáfora, como especificações, montagem de componentes, e os andaimes. A metáfora do edifício sobreviveu à sua utilidade. É hora de mudar novamente. Se, como acreditar, as estruturas conceituais que construímos hoje são muito complicados para ser precisamente especificadas com antecedência, e demasiado complexo para ser construído perfeitamente, então temos de tomar uma abordagem radicalmente diferente. Voltemo-nos para a natureza e complexidade estudo em seres vivos, em vez de apenas os mortos obras do homem. Aqui encontramos construções cujas complexidades emocionar-nos com admiração. O cérebro sozinho é complicado além de mapeamento, além da imitação poderoso, rico em diversidade, auto- proteger e auto-renovação. O segredo é que ela é cultivada, não construídos. Assim deve ser com os nossos sistemas de software. Alguns anos atrás, Harlan Mills propôs que qualquer sistema de software devem ser cultivadas pelo desenvolvimento incremental. 11 Isto é, o sistema primeiro deve ser feito para correr, mesmo que ele não faz nada útil, exceto chamar o conjunto apropriado de subprogramas fictícios. Então, pouco a pouco ela é desenvolvida, com os subprogramas, por sua vez sendo desenvolvido em ações ou chamadas para stubs vazios no nível abaixo. Eu tenho visto os resultados mais dramáticos desde que começou a incitar esta técnica na construtores do projeto em minha aula de laboratório de engenharia de software. Nada na última década foi tão radicalmente mudou a minha própria prática, ou a sua eficácia. A abordagem necessita projeto top-down, pois é um crescente de cima para baixo do software. Ele permite fácil backtracking. Ele se presta para os primeiros protótipos. Cada função adicional e nova disposição de dados mais complexos ou circunstâncias cultivados organicamente do que já está lá. 11 Mills, HD, "programação top-down em sistemas de grande porte," Depurando Techniques em grandes sistemas, R. Rustin, ed., Englewood Cliffs, NJ, Prentice-Hall, 1971.

Página 15 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 15 Os efeitos de moral são surpreendentes. Saltos entusiasmo quando há um sistema em execução, mesmo que simples. Esforços redobrar quando a primeira imagem de um software gráfico novo

sistema aparece no ecrã, mesmo se for apenas um rectângulo. A gente sempre tem, em cada fase do processo, um sistema de trabalho. Acho que as equipes podem crescer muito mais complexo entidades em quatro meses do que pode construir. Os mesmos benefícios podem ser realizados em grandes projetos como os meus pequenos. 12 Grandes designers. A questão central de como melhorar os centros de arte de software, como ele sempre, sobre as pessoas. Podemos obter bons projetos, seguindo as boas práticas em vez de os pobres. Bom práticas de projeto pode ser ensinado. Os programadores estão entre a parte mais inteligente do população, para que eles possam aprender boas práticas. Assim, um impulso principal nos Estados Unidos é promulgar boa prática moderna. Novos currículos, literatura nova, novas organizações, tais como o Instituto de Engenharia de Software, todos vieram a existir, a fim de elevar o nível da nossa prática de ruim a boa. Isto é inteiramente adequada. No entanto, eu não acredito que nós podemos dar o próximo passo para cima da mesma forma. Considerando que a diferença entre pobres projetos conceituais e os bons pode estar na solidez do método de projeto, a diferença entre projetos bons e grandes certamente não o faz. Grandes projetos vêm de grandes estilistas. Construção de software é um criativo processo. Metodologia de som pode fortalecer e libertar a mente criativa, não pode inflamar ou inspirar o Drudge. As diferenças não são menores, é um pouco como Salieri e Mozart. Estudo após estudo mostra que os melhores designers de muito produzir estruturas que são mais rápidos, menores, mais simples, mais limpo, e produzido com menos esforço. As diferenças entre a grande ea média aproximar uma ordem de magnitude. Uma retrospectiva pouco mostra que, embora muitos finos, sistemas de software úteis que foi concebido por comitês e construído por projetos de várias vias, os sistemas de software que ter animado os fãs apaixonados são aqueles que são os produtos de uma ou um projetando poucos mentes, grandes designers. Considere Unix, APL, Pascal, Modula, a interface do Smalltalk, mesmo Fortran e contraste com Cobol, PL / I, Algol, MVS/370, e MS-DOS (fig. 1) Sim Não Unix Cobol APL PL / 1 Pascal Algol Modula MVS/370 Smalltalk MS-DOS Fortran Fig. 1 produtos excitantes Assim, embora eu apoio fortemente a transferência de tecnologia e currículo esforços de desenvolvimento em andamento, acho que o esforço mais importante que podemos montagem é desenvolver formas para crescer grandes designers. 12 Boehm, BW, "um modelo espiral de desenvolvimento de software e melhoria", Computador, 20, 5 (maio, 1985), pp 43-57.

Página 16 F. Brooks: No Silver Bullet Essência e acidente em engenharia de software (1986) 16 Nenhuma organização software pode ignorar este desafio. Bom gestores, escassos embora sejam, não são mais escassos do que bons designers. Grandes designers e gestores de grandes são ambos muito raro. A maioria das organizações gastam um esforço considerável em encontrar e cultivar a perspectivas de gestão, eu sei de nenhum que gasta igual esforço em encontrar e desenvolver os grandes estilistas a quem a excelência técnica dos produtos será em última instância dependem. Minha primeira proposta é que cada organização deve determinar software e proclamar que grandes estilistas são tão importantes para seu sucesso como grandes administradores são, e que eles podem ser deverá ser igualmente nutridos e recompensado. Não só o salário, mas os privilégios de reconhecimento escritório de tamanho, mobiliário, equipamento técnico pessoal, verbas para viagens, os funcionários suporte deve ser totalmente equivalente. Como crescer grandes estilistas? O espaço não permite uma longa discussão, mas alguns passos são óbvias: • • • • Sistematicamente identifique os melhores projetistas o mais cedo possível. O melhor muitas vezes não são o mais experientes. Atribua um orientador de carreira responsável pelo desenvolvimento da perspectiva, e manter um plano de carreira cuidado. Elaborar e manter um plano de desenvolvimento de carreira para cada perspectiva, incluindo cuidadosamente aprendizagem selecionados com estilistas, episódios de educação formal avançada, e cursos de curta duração, todos intercalados com projeto solo e liderança técnica atribuições. Oferecer oportunidades para designers de crescimento para interagir e estimular uns aos outros. ■