Object1

Pgina 1 No Silver Bullet -Essncia e Acidentes em Engenharia de Software Frederick P. Brooks, Jr. University of North Carolina em Chapel Hill No h desenvolvimento nico, em qualquer tecnologia ou gesto tcnica, que por si s promete ainda uma ordem de grandeza melhoria dentro de uma dcada na produtividade, na confiabilidade, na simplicidade. Abstrato 1 Toda a construo de software envolve tarefas essenciais, a confeco do complexo estruturas conceituais que compem a entidade de software, resumo e tarefas acidentais, o representao dessas entidades abstratas em linguagens de programao e do mapeamento de os em linguagens de mquina dentro de limites de espao e velocidade. A maior parte do passado grande ganhos de produtividade de software vm de remoo de barreiras artificiais que tm fez as tarefas acidentais excessivamente duras, tais como restries de hardware graves, inbeis linguagens de programao, falta de tempo de mquina. Como muito do que software engenheiros agora no ainda dedicada ao acidental, em oposio ao essencial? A menos que mais do que 9/10 de todo o esforo, a reduo de todas as actividades acidentais para zero o tempo no 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 rpida como parte de uma iterao planejada no estabelecimento software exigncias. Crescer organicamente software, adicionando funo cada vez mais para sistemas como elas so executar, usado e testado. Identificar e desenvolver os grandes estilistas conceituais da nova gerao. Introduo 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 edio de Man-Month aniversrio, Mythical com 4 novos captulos, Addison-Wesley (1995), se reproduzido a partir dos Anais do Mundo Dcima IFIP Computing Conference, H.-J. Kugler, ed., Elsevier Science BV, Amsterdam, NL (1986) pp 10691076. Pgina 2 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 2 O projeto de software familiar tem algo desse personagem (pelo menos como visto pela no-gerente tcnico), geralmente inocentes e simples, mas capaz de se tornar um monstro de horrios no cumpridos, oramentos queimados, e os produtos defeituosos. Ento

ouvimos desesperados gritos de uma bala de prata, algo para tornar os custos de software cair to rapidamente quanto computador custos de hardware fazer. Mas, quando olhamos para o horizonte de uma dcada, portanto, ns no vemos nenhuma bala de prata. No h desenvolvimento nico, em qualquer tcnica ou tecnologia de gesto, que por si s promete ainda uma ordem de magnitude na produtividade, em termos de confiabilidade, em simplicidade. Neste captulo vamos tentar ver o porqu, mas examinando tanto a natureza do problema de software e as propriedades dos marcadores propostos. Ceticismo no pessimismo, no entanto. Embora no vemos avanos surpreendentes, e, na verdade, acreditar que tal incompatvel com a natureza do software, muitos inovaes encorajadores esto em andamento. Um esforo disciplinado e consistente para desenvolver, propagar, e explor-los de fato deve render uma melhora da ordem de grandeza. No h estrada real, mas h uma estrada. O primeiro passo para o tratamento da doena foi a troca de teorias demnio e teorias humores pela teoria dos germes. Essa etapa muito, o comeo da esperana, em si mesmo tracejada todas as esperanas de solues mgicas. Ele disse aos trabalhadores o progresso seria feito passo a passo, com grande esforo, 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 No s h nenhuma bala de prata agora em vista, a prpria natureza do software torna improvvel que haja quaisquer de nenhuma inveno que ir fazer para a produtividade de software, confiabilidade e simplicidade que a integrao eletrnica, transistores, e em larga escala fez por hardware do computador. No podemos esperar que nunca para ver os ganhos de duplas a cada dois anos. Primeiro, devemos observar que a anomalia no que o progresso software to lento, mas que o progresso hardware do computador to rpido. Nenhuma outra tecnologia desde a civilizao comeou viu seis ordens de magnitude ganho de preo-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 transformao de fabricao de um computador indstria de montagem em uma indstria 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 Aristteles, eu dividi-los em sua essncia as dificuldades de inerente natureza do software e acidentes-essas dificuldades que hoje frequentam a sua produo, mas que no so inerentes. Os acidentes de discutir na prxima seo. Primeiro vamos considerar a essncia. A essncia de uma entidade de software uma construo de conceitos interligados: conjuntos de dados, relaes entre itens de dados, algoritmos e invocaes de funes. Esta essncia abstrata, em que a construo conceitual o mesmo sob os mais representaes. No entanto, altamente precisa e rica em detalhes. Eu acredito que a parte mais difcil da construo de software para a especificao, projeto, teste e desta construo conceitual, e no o trabalho de represent-lo e testar a fidelidade do representao. Ns ainda cometemos erros de sintaxe, para ter certeza, mas eles so fuzz em comparao com o erros conceituais na maioria dos sistemas.

Pgina 3 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 3 Se isso for verdade, a construo de software ser sempre difcil. H inerentemente no prata bala. Vamos considerar as propriedades inerentes a esta essncia irredutvel de software moderna sistemas: a complexidade, conformidade, mutabilidade, invisibilidade e. Entidades de software de complexidade. So mais complexas para o seu tamanho do que talvez qualquer outro humano construir, porque no h duas peas iguais (pelo menos acima do nvel de instruo). Se eles so, fazemos as duas partes semelhantes em um, um sub-rotina, aberta ou fechada. Neste sistemas de software respeito diferem profundamente a partir de computadores, edifcios ou automveis, onde os elementos repetidos abundam. Os computadores digitais so-se mais complexa do que a maioria das coisas que as pessoas construir, eles tem um grande nmero de estados. Isso faz com que conceber, descrever, e test-las rgido. Os sistemas de software tm ordens de magnitude mais estados do que os computadores fazem. Da mesma forma, uma ampliao de uma entidade de software no apenas uma repetio do mesmo elementos em tamanho maior, que necessariamente um aumento no nmero de elementos diferentes. Na maioria dos casos, os elementos interagem uns com os outros, de alguma forma no-linear, ea complexidade do conjunto aumenta muito mais do que linearmente. A complexidade do software de propriedade essencial, no acidental. Por isso descries de uma entidade de software que abstrair a sua complexidade, muitas vezes abstrair sua essncia. Matemtica e as cincias fsico feito grandes progressos durante trs sculos por construo de modelos simplificados de fenmenos complexos, derivando propriedades do modelos e verificando as propriedades experimentalmente. Isso funcionou porque o complexidades ignorados nos modelos no foram as propriedades essenciais dos fenmenos. Ele no funciona quando as complexidades so a essncia. Muitos dos problemas clssicos de produtos de software de desenvolvimento derivado deste complexidade essencial e no-linear da sua aumentou com o tamanho. A partir da complexidade vem a dificuldade de comunicao entre os membros da equipe, o que leva a falhas de produtos, o custo derrapagens, atrasos na programao. A partir da complexidade vem a dificuldade de enumerar, compreenso muito menos, todos os estados possveis do programa, e de que trata o falta de confiabilidade. A partir da complexidade das funes vem a dificuldade de invocar os funes, o que torna os programas difceis de usar. De complexidade da estrutura vem do dificuldade de estender programas a novas funes, sem criar efeitos colaterais. A partir do complexidade da estrutura vem do estado unvisualized que que constituem a segurana alapes. No s problemas tcnicos, mas problemas de gesto, bem vir da complexidade. Esta complexidade torna difcil viso, impedindo assim a integridade conceitual. Isso torna mais difcil encontrar e controlar todas as pontas soltas. Ele cria o grande aprendizado e carga entendimento pessoal que faz volume de negcios um desastre. Software pessoas da conformidade. No est sozinho para enfrentar a complexidade. Lida com fsica objetos muito complexos, mesmo a nvel partcula "fundamental". Os trabalhos fsico em diante, no entanto, em uma f firme que existem princpios unificadores a ser encontrados, quer no

quarks ou em teorias do campo unificado. Einstein argumentou repetidamente que deve haver simplificado explicaes da natureza, porque Deus no caprichoso ou arbitrrio. Sem essa f conforta o engenheiro de software. Muito da complexidade, ele deve mestre a complexidade arbitrria, forada sem rima ou razo pela humano muitos Pgina 4 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 4 instituies e sistemas para que suas interfaces devem confirmar. Estes diferem da interface a interface, e de vez em quando, no por causa da necessidade, mas apenas porque eram desenhado por pessoas diferentes, e no 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 adaptvel. Mas, na todos os casos, a complexidade muito vem de conformao para outras interfaces, o que no pode ser simplificado por qualquer redesenho do software sozinho. Mutabilidade. A entidade software est constantemente sujeito a presses por mudana. De Naturalmente, assim que so prdios, carros e computadores. Mas as coisas raramente so manufaturados mudou aps o fabrico, eles so substitudos por modelos mais recentes, ou mudanas essenciais so incorporada em posteriores nmero serial cpias do mesmo projeto bsico. Callbacks de automveis so realmente muito raras, alteraes no campo de computadores um pouco menos. Ambos so muito menos freqentes do que modificaes de software em campo. Em parte, isso ocorre porque o software em um sistema incorpora a sua funo, ea funo a parte que mais sente as presses da mudana. Em parte porque o software pode ser mudado mais facilmente ele puro pensamento coisas, infinitamente malevel. Edifcios de fato se mudado, mas os altos custos da mudana, entendidas por todos, servem para amortecer o capricho dos trocadores. Todo o software de sucesso alterado. Dois processos esto no trabalho. Como um software produto encontrado para ser til, as pessoas experiment-lo em novos casos na borda de, ou alm, o domnio original. As presses para a funo estendida vm principalmente de usurios que gostem a funo bsica e inventar novos usos para ele. Segundo, o software bem-sucedido tambm sobrevive alm da vida normal da mquina veculo para o qual primeiro escrita. Se no computadores novos, ento, pelo menos, novos discos, de novo monitores, impressoras novas vm junto, e o software deve ser conformado com a sua nova veculos de oportunidade. Em suma, o software est embutido em uma matriz cultural de aplicaes, usurios, leis, e os veculos de mquinas. Estes mudam tudo continuamente, e suas alteraes inexoravelmente forar a mudana sobre o produto de software. Invisibilidade. Software invisvel e montante invisualizvel. Abstraes geomtricas so ferramentas poderosas. A planta de um edifcio de ajuda tanto o arquiteto e cliente avaliar espaos, fluxos de trfego e pontos de vista. Contradies tornam-se evidentes, as omisses podem ser pego. Desenhos escala de peas mecnicas e vara-figura modelos de molculas, apesar de abstraes, servem ao mesmo propsito. Uma realidade geomtrica capturado em um abstrao geomtrica. A realidade do software no inerentemente incorporada no espao. Por isso, no tem nenhuma

pronto representao geomtrica da forma que a terra tem os mapas, os chips de silcio tm diagramas, computadores tm esquemas de conectividade. Assim que tentamos software diagrama estrutura, descobrimos que a constituem no apenas uma, mas vrias, gerais grafos dirigidos, sobrepostos uns sobre os outros. Os grficos vrios pode representar o fluxo de controlo, o fluxo de dados, padres de dependncia, seqncia de tempo, o nome de espao-relacionamentos. Estes no so geralmente planar mesmo, e muito menos hierrquica. De fato, uma das formas de Pgina 5 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 5 estabelecer o controle conceitual sobre tal estrutura aplicar o corte ligao at que um ou mais dos grficos torna-se hierrquica. 2 Apesar dos progressos em restringir e simplificar as estruturas de software, eles permanecem inerentemente montante invisualizvel, privando assim a mente de alguns de seus mais poderosos ferramentas conceituais. Esta falta no s impede o processo de projeto dentro de uma mente, dificulta severamente a comunicao entre mentes. Avanos ltimos Resolvido dificuldades acidentais Se examinarmos os trs passos na tecnologia de software que tm sido mais frutfera no passado, descobrimos que cada atacaram uma dificuldade diferente importante na construo de software, mas eles tm sido as dificuldades acidentais, no essencial,. Ns tambm podemos ver o natural limites para a extrapolao de cada tal ataque. Linguagens de alto nvel. Certamente o curso mais poderosa para a produtividade de software, confiabilidade e simplicidade tem sido a utilizao progressiva de linguagens de alto nvel para programao. A maioria dos observadores de crdito 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 nvel realizar? Ele libera um programa de grande parte da sua complexidade acidental. Um programa abstrato consiste de construes conceituais: operaes, tipos de dados, seqncias e de comunicao. O programa da mquina de concreto preocupado com pedaos, registos, condies, galhos, canais, discos e tal. Para o medida em que a linguagem de alto nvel incorpora as construes queria em abstrato programa e evita todos os entes inferiores, que elimina todo um nvel de complexidade que era nunca inerente ao programa de todo. O mximo que uma linguagem de alto nvel pode fazer fornecer todas as construes do programador imagina no programa abstrato. Para ter certeza, o nvel de nossa sofisticao no pensamento sobre estruturas de dados, tipos de dados e operaes de crescimento constante, mas a um cada vez diminuio da taxa. E desenvolvimento da linguagem se aproxima mais e mais perto do sofisticao dos usurios. Alm disso, em algum momento a elaborao de uma linguagem de alto nvel se torna um fardo que os aumentos, no reduz, a tarefa intelectual do usurio que raramente usa o esotrico construes. Compartilhamento de tempo. A maioria dos observadores de crdito de compartilhamento de tempo com uma grande melhoria na produtividade dos programadores e na qualidade dos seus produtos, embora no to grande como que trouxe por linguagens de alto nvel.

Time-sharing ataca uma dificuldade bem diferente. Compartilhamento de tempo preserva imediatismo e, portanto, nos permite manter uma viso geral da complexidade. A lenta turnaround da programao lote significa que, inevitavelmente, esquecer as mincias, se no o muito impulso, do que estvamos pensando quando ns paramos de programao e chamado para compilao e execuo. Esta interrupo de conscincia caro no tempo, para ns deve atualizar. O efeito mais grave pode muito bem ser a decadncia da compreenso de tudo o que est acontecendo em em um sistema complexo. 2 Parnas, DL, "Projetando software para facilitar a extenso e contrao," IEEE Trans. em SE, 5, 2 (Maro, 1979), pp 12-138. Pgina 6 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 6 Lento turn-around, como linguagem de mquina complexidades, uma vez acidental de uma dificuldade essencial do processo de software. Os limites da contribuio de time-sharing derivam diretamente. O efeito princpio 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. Alm disso h benefcios so esperados. Unificadas ambientes de programao. Unix e Interlisp, o primeiro integrado ambientes de programao para entrar em uso generalizado, so 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 princpio, pode sempre chamar, alimentar, e usar um outro fato pode facilmente faz-lo na prtica. 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 padro. Devido a esses sucessos, os ambientes so objecto de grande parte dos softwares de hoje de pesquisa de engenharia. Vamos olhar para a sua promessa e limitaes na prxima seo. Esperanas para o Prata Agora vamos nos considerar os desenvolvimentos tcnicos que so mais frequentemente apresentados como potenciais balas de prata. Quais os problemas que eles tratam? So eles os problemas de essncia, ou so restos de nossas dificuldades acidentais? Ser que eles oferecem avanos revolucionrios, ou aqueles incrementais? Ada e outros avanos linguagem de alto nvel. Um dos mais elogiado recente desenvolvimentos a linguagem de programao Ada, um general-purpose, linguagem de alto nvel da dcada de 1980. Ada de fato no s reflete as melhorias evolutivas na linguagem conceitos, mas incorpora recursos para incentivar o design moderno e modularizao conceitos. Talvez a filosofia Ada mais um avano do que a linguagem Ada, para a filosofia de modularizao, de tipos de dados abstratos, de estruturao hierrquica. Ada , talvez, mais rica, o produto natural do processo pelo qual os requisitos foram estabelecidas em seu design. Isso no fatal, por vocabulrios subconjunto de trabalho pode resolver o problema de aprendizagem, e os avanos de hardware nos dar as MIPS baratos para pagar o compilao custos. Avanando a estruturao de sistemas de software de fato um bem muito

usar para os MIPS maiores nossos dlares vai comprar. Os sistemas operacionais, alto condenada nos 1960 para a sua memria e os custos de ciclo, provaram ser uma forma excelente para usar alguns dos MIPS e bytes de memria baratos do aumento hardware passado. No entanto, Ada no ir provar ser a bala de prata que mata o software monstro produtividade. , afinal, outra linguagem de alto nvel, ea maior pagamento de tais lnguas veio a primeira transio, a partir do acidental complexidades da mquina para a declarao mais abstrato do passo-a-passo solues. Uma vez que os acidentes tenham sido removidos, os demais so menores, e os lucros de sua remoo ser certamente menor. Eu prevejo que daqui a uma dcada, quando a eficcia da Ada avaliado, ser visto ter feito uma diferena substancial, mas no por causa de uma lngua, recurso, nem, alis, porque de todos eles juntos. Nem a Ada de novo Pgina 7 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 7 ambiente provar ser a causa de as melhorias. A maior contribuio de Ada vontade ser que a mudana para que os programadores de formao ocasionadas em design de software moderna tcnicas. Programao orientada a objetos. Muitos estudantes da arte aguentar mais esperana para a objeto programao orientada do que para qualquer um dos outros fads tcnicas do dia. 3 Eu estou no meio eles. Mark Sherman de notas Dartmouth que devemos ter o cuidado de distinguir duas idias distintas que vo com esse nome: tipos de dados abstratos e tipos hierrquicos, tambm 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 operaes apropriadas, em vez da sua estrutura de armazenamento, o que deve ser escondido. Exemplos disso so os pacotes Ada (com particular tipos) ou mdulos de Modula. Tipos hierrquicos, como Simula-67 de classes, permitir que a definio de geral interfaces que podem ser aperfeioadas, fornecendo tipos subordinados. Os dois conceitos so ortogonais, pode haver hierarquias sem esconder e esconder, sem hierarquias. Ambos os conceitos representam avanos reais na arte de construo de software. Cada remove uma maior dificuldade acidental do processo, permitindo que o desenhador para expressar a essncia de seu projeto sem a necessidade de expressar grandes quantidades de sinttica material que no acrescentam contedo de informao nova. Para ambos os tipos abstratas e hierrquicas tipos, o resultado para remover uma espcie de ordem superior de dificuldade acidental e permitir que um de ordem mais elevada expresso de design. No entanto, tais avanos no pode fazer mais do que remover todo o acidental dificuldades da expresso do desenho. A complexidade do desenho em si essenciais, ataques e tal no fazem qualquer mudana nisso. Um ganho de ordem de grandeza pode ser feita por programao orientada por objectos apenas se o mato desnecessria de tipo especificao permanecendo hoje em nossa linguagem de programao ele prprio responsvel

por novedcimos do trabalho envolvido na concepo de um produto de programa. Duvido. A inteligncia artificial. Muitas pessoas esperam que os avanos na inteligncia artificial para fornecer o avano revolucionrio que vai dar ordem de grandeza ganhos em software produtividade e qualidade. 4 Eu no. Para ver o porqu, devemos dissecar o que se entende por "Inteligncia artificial" e depois ver como ela se aplica. Parnas esclareceu o caos terminolgico: Duas definies muito diferentes de AI esto em uso comum hoje em dia. AI-1: A utilizao de computadores para resolver problemas que antes s poderiam ser resolvidos pela aplicao humana inteligncia. AI-2: A utilizao de um conjunto especfico de tcnicas de programao sabe como heurstica ou regra baseada em programao. Nesta abordagem peritos humanos so estudos para determinar o que heursticas 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, Califrnia: Benjamin Cummings, 1983. 4 Mostow, J., ed., Edio Especial de Inteligncia Artificial e Engenharia de Software, IEEE Trans. em SE, 11, 11 (Nov. 1985). Pgina 8 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 8 A primeira definio tem um significado de deslizamento. . . . Algo pode caber a definio de AI-1 mas hoje, uma vez vemos como funciona o programa e entender o problema, vamos no pense nisso como AI mais. . . . Infelizmente eu no posso identificar um corpo de tecnologia que exclusivo para este campo. . . . A maior parte do trabalho problema especfico, e alguns abstrao nem criatividade exigir para ver como transferi-lo. 5 Concordo completamente com essa crtica. As tcnicas utilizadas para o reconhecimento de voz parecem ter pouco em comum com os utilizados para reconhecimento de imagem, e ambos so diferentes daqueles usados em sistemas de peritos. Eu tenho dificuldade em ver como a imagem reconhecimento, por exemplo, vai fazer nenhuma diferena significativa na prtica de programao. O mesmo tentar de reconhecimento de fala. A coisa dura sobre a construo de software decidir o que dizer, no dizendo isso. No facilitao da expresso pode dar mais do que marginal ganhos. Especialista sistemas de tecnologia, AI-2, merece uma seo prpria. Os sistemas especialistas. A parte mais avanada da arte da inteligncia artificial, ea maioria dos amplamente aplicvel, a tecnologia para a construo de sistemas especialistas. Muitos cientistas de software esto trabalhando duro para aplicar esta tecnologia para o ambiente de software edifcio. 6 O que o conceito, e quais so as perspectivas?

Um sistema especialista um programa que contm um motor de inferncia generalizada e uma regra base, projetado para tirar os dados e hipteses e explorar as conseqncias lgicas atravs das inferncias derivveis da base de regra, concluses produzindo e conselhos, e oferecendo-se para explicar os seus resultados por refazer seu raciocnio para o usurio. A inferncia motores normalmente pode lidar com dados nebulosos ou probabilstica e regras, alm de puramente lgica determinista. Esses sistemas oferecem algumas vantagens claras sobre algoritmos programados para chegar nas mesmas solues para os mesmos problemas: Tecnologia de motor de inferncia desenvolvido de forma independente de aplicao, e depois aplicado a muitas utilizaes. Pode-se justificar um esforo muito maior nos motores de inferncia. Na verdade, que a tecnologia est bastante avanada. As partes mutveis das matrias-aplicao peculiares so codificados na base de regras de uma forma uniforme, e as ferramentas so fornecidas para o desenvolvimento, mudando, testando, e documentando a base de regras. Este regulariza muito da complexidade da aplicao si. Edward Feigenbaum diz que o poder de tais sistemas no vem de sempre mecanismos mais sofisticados de inferncia, mas sim de bases de conhecimento cada vez mais ricas, que refletem o mundo real com mais preciso. Creio que o mais importante avano oferecido pelo tecnologia a separao da complexidade da aplicao do prprio programa. Como isto pode ser aplicado para a tarefa de software? De muitas maneiras: interface sugerindo regras, aconselhando sobre estratgias de ensaio, mas lembrando-se do tipo freqncias, oferecendo dicas de otimizao, etc 5 Parnas, DL, "Aspectos de software de sistemas estratgicos de defesa", Communications of the ACM, 28, 12 (dezembro, 1985), pp 1326-1335. Tambm em American Scientist, 73, 5 (setembro-outubro de 1985), pp 432440. 6 Balzer, R., "Uma perspectiva de 15 anos em programao automtica," em Mostow, op. cit. Pgina 9 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 9 Considere um assessor testes imaginrio, por exemplo. Na sua forma mais rudimentar, o sistema especialista de diagnstico muito parecido com uma lista de verificao piloto, fundamentalmente oferecer sugestes quanto a possveis causas de dificuldade. Como a base de regras foi desenvolvido, a sugestes tornam-se mais especfico, tendo em conta mais sofisticada do problema os sintomas relatados. Pode-se visualizar um assistente de depurao, que oferece muito generalizada sugestes no incio, mas como estrutura do sistema cada vez mais est incorporado na base de regras, vem mais e mais em particular no hipteses 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 diagnstico pode ser modularmente modificado tambm. O trabalho necessrio para gerar as regras de diagnstico o trabalho que ter de ser feito de qualquer maneira a gerar o conjunto de casos de teste para os mdulos de e para o sistema. Se isso for feito de forma adequada geral, com uma estrutura uniforme de regras e uma boa inferncia motor disponvel, ele pode realmente reduzir o trabalho total da produo de trazer-se casos de teste, bem como ajudar na manuteno ao longo da vida e teste de modificao. Da mesma forma, ns pode postular outros conselheiros mais provavelmente muitos deles e, provavelmente, simples para o outras partes do tarefa de construo de software. Muitas dificuldades esto no caminho da realizao antecipada de consultores especializados teis para o desenvolvedor do programa. Uma parte crucial do nosso cenrio imaginrio o desenvolvimento de fcil maneiras de se obter a partir de especificao da estrutura do programa para o automtico ou semiautomtico gerao de regras de diagnstico. Ainda mais difcil e importante a dupla tarefa de aquisio de conhecimento: encontrar articulados, auto-analticas especialistas que sabem por que eles fazem coisas, e desenvolvimento de tcnicas eficientes para extrair o que eles sabem e distilando em bases de regras. O pr-requisito essencial para a construo de um sistema especialista ter uma especialista. A contribuio mais poderosa de sistemas especialistas ser certamente de colocar ao servio do programador inexperiente a experincia e sabedoria acumulada dos melhores programadores. Isto no pequena contribuio. A diferena entre o melhor software prtica da engenharia e da prtica mdia muito grande, talvez maior do que em qualquer disciplina engenharia. Uma ferramenta que difunde as boas prticas seria importante. "Automatic" de programao. Por quase 40 anos, as pessoas tm vindo a antecipar e escrevendo sobre "programao automtica", a gerao de um programa para resolver um problema a partir de uma declarao sobre as especificaes do problema. Algumas pessoas hoje escrevem como se eles esperavam que esta tecnologia para fornecer o prximo avano. 7 Parnas implica que o termo usado para o glamour e contedo no semntica, afirmando, Em suma, a programao automtica sempre foi um eufemismo para a programao com uma linguagem de alto nvel do que era presentemente disponveis para o programador. 8 Ele argumenta, em essncia, que na maioria dos casos o mtodo de soluo, no do problema, cuja especificao tem que ser dado. 7 Mostow, op. cit. 8 Parnas, 1985, op. cit. Pgina 10 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986)

10 Excees podem ser encontrados. A tcnica de construo de geradores muito poderoso, e rotineiramente usado para boa vantagem em programas de triagem. Alguns sistemas para equaes diferenciais que integram tambm permitido especificao direta do problema. O sistema de avaliao dos parmetros, escolheu a partir de uma biblioteca de mtodos de soluo, e gerou os programas. Essas aplicaes tm propriedades muito favorveis: Os problemas so prontamente caracterizada por parmetros relativamente poucos. Existem muitos mtodos conhecidos de soluo para fornecer uma biblioteca de alternativas. Extensa anlise levou a regras explcitas para a seleo de tcnicas de soluo, dada parmetros do problema. difcil ver como estas tcnicas podem ser generalizadas para o resto do mundo do comum sistema de software, onde os casos com as mesmas propriedades limpas so a exceo. difcil mesmo imaginar como este avano na generalizao poderia concebivelmente ocorrer. Programao grfica. Um tema favorito para PH.D. dissertaes em software engenharia grfica, ou visual, a programao, a aplicao da computao grfica 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 computao grfica desempenha um papel to fecunda. s vezes, a abordagem justificada por fluxogramas, considerando que o programa ideal mdio, design e fornecimento de instalaes poderosas para constru-las. Nada mesmo convincente, muito menos emocionante, tenha surgido a partir de tais esforos. Eu estou convencido de que nada vai. Em primeiro lugar, como j argumentei em outros lugares, o fluxograma uma abstrao 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 nvel para a sua proposta computador. No, multipage lamentvel, a forma de conexo na caixa para que o fluxo grfico foi hoje elaborado, que provou ser essencialmente intil como um desenho da ferramentaprogramadores desenhar fluxogramas depois, no antes, escrevendo os programas que eles descrevem. Em segundo lugar, as telas de hoje so muito pequenas, em pixels, para mostrar tanto o mbito eo resoluo de qualquer diagrama de software srio detalhada. A chamada "metfora do desktop" de estao de trabalho de hoje , em vez de um "avio-assento" metfora. Qualquer pessoa que tenha baralhado um lapful de documentos enquanto estiver sentado em um nibus entre dois passageiros corpulentos ir reconhecer o diferena de um pode ver apenas algumas poucas coisas de uma s vez. O desktop verdade fornece viso geral e de acesso aleatrio para uma contagem de pginas. Alm 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 espaoso. A tecnologia de hardware tero que avanar bastante substancialmente antes do alcance de nossos espaos suficiente para a tarefa de design de software. Mais fundamentalmente, como j afirmei acima, o software muito difcil de visualizar. Quer que o fluxo de controle diagrama, escopo de variveis de nidificao, varivel referncias cruzadas, dados golpe, estruturas hierrquicas de dados, ou qualquer outra coisa, sentimo-nos apenas uma dimenso do intrinsecamente interligados elefante software. Se sobrepor todos os diagramas gerados pelos muitos pontos de vista relevantes, difcil extrair qualquer viso global. A VLSI 9 Raeder, G., "Um levantamento das atuais tcnicas de programao grfica," em RB Grafton e Ichikawa T., eds., Edio Especial sobre Programao Visual, Computao, 18, 8 (agosto, 1985), pp 11-25 10 Brooks 1995, op. cit., captulo 15. Pgina 11 F. Brooks: No Silver Bullet Essncia 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 essncia. Um sistema de software no . Verificao do programa. Muito do esforo em programao moderna vai para o teste e reparao 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 estratgia profundamente diferente de provar projetos corrigir antes do imenso esforo vertida para a implementao e test-las? Eu no acredito que vamos encontrar a magia aqui. Verificao do programa um poderoso conceito, e ele ser muito importante para coisas como kernels de sistemas operacionais seguras. A tecnologia no promete, no entanto, para salvar o trabalho. As verificaes so muito trabalhar que apenas alguns programas substanciais j foram verificados. Verificao do programa no significa prova de erros de programas. No h mgica aqui, quer. Provas matemticas tambm pode estar com defeito. Assim que a verificao pode reduzir o programa de testes de carga, no se pode elimin-la. Mais a srio, at mesmo verificao programa perfeito que s pode estabelecer um programa cumpre a sua especificao. A parte mais difcil da tarefa software chegar a uma completa e especificao consistente, e grande parte da essncia da construo de um programa de fato a depurao da especificao. Ambientes e ferramentas. Quanto mais ganho pode ser esperados a partir da exploso pesquisas em melhores ambientes de programao? Uma da reaco instintiva que o grande recompensa problemas foram os primeiros atacados, e foram resolvidos: arquivo hierrquico sistemas, formatos de ficheiros uniformes de modo a ter interfaces de programao uniformes, e generalizada ferramentas. Especficos do idioma editores inteligentes so desenvolvimentos ainda no amplamente utilizados na prtica, mas a maioria o que eles prometem a liberdade de erros sintticos e simples erros de semntica. Talvez o maior ganho ainda a ser realizado no ambiente de programao o uso de sistemas de banco de dados integrados para manter o controle das mirades de detalhes que devem ser recordar com preciso 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 prpria natureza, o retorno a partir de agora deve ser marginal. As estaes de trabalho. Que ganhos so de esperar para a arte do software certo e rpido aumento da capacidade de energia e memria da estao de trabalho individual? Bem, quantos MIPS pode usar um fruto? A composio e edio de programas e documentos totalmente suportado por velocidades de hoje. Compilando pode resistir a um impulso, mas um fator de 10 em velocidade da mquina, certamente, deixar pensar tempo da atividade dominante no dia do programador. Na verdade, parece ser assim agora. Estaes de trabalho mais poderosas que certamente bem-vindos. Melhorias mgicas deles no podemos esperar. Pgina 12 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 12 Ataques promissores na essncia conceitual Mesmo que nenhum avano tecnolgico promete dar o mole de mgica resultados que nos so to familiares na rea de hardware, no tanto uma abundncia de bom funcionamento acontecendo agora, ea promessa de constante progresso espetacular, se. Todos os ataques tecnolgicos sobre os acidentes do processo de software so fundamentalmente limitada pela equao produtividade: Hora da task = (Frequency) Eu x (Time) Eu Se, como acredito, os componentes conceituais da tarefa esto agora a tomar a maior parte do tempo, ento no h quantidade de atividade sobre os componentes de tarefas que so meramente a expresso de os conceitos podem dar grandes ganhos de produtividade. Por isso, devemos considerar esses ataques que se dirigem a essncia do software problema, a formulao dessas estruturas complexas conceptuais. Felizmente, alguns dos estes so muito promissores. Compre contra construir. A soluo mais radical possvel para a construo de software no constru-la de todo. Todo dia isso se torna mais fcil, pois mais e mais vendedores oferecem mais e melhor produtos de software para uma variedade estonteante de aplicaes. Enquanto ns, engenheiros de software trabalharam na metodologia de produo, a revoluo do computador pessoal foi criado no um, mas m qualquer, mercados de massa para software. Cada banca realizada mensalmente revistas que, classificadas por tipo de mquina, propaganda e rever dezenas de produtos no preos de alguns dlares para algumas centenas de dlares. Fontes mais especializadas oferecem muito poderosos produtos para a estao de trabalho Unix e outros mercados. Mesmo portagens de software e ambientes podem ser comprados off-the-shelf. Eu tenho outro lugar props um mercado local para Os mdulos individuais. Qualquer desses produtos mais barato comprar do que construir de novo. Mesmo a um custo de US $ 100.000,

comprou um pedao 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 usurio feliz. Alm 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 tendncia de longo prazo em engenharia de software. O custo do software tem sido sempre o custo de desenvolvimento, no custo de replicao. Compartilhando esse custo at mesmo entre alguns usurios radicalmente corta o por usurio custo. Outra maneira de olhar para ele que o uso de n cpias de um sistema de software efetivamente multiplica a produtividade de seus desenvolvedores, n. Isso um aprimoramento da a produtividade da disciplina e da nao. O aspecto fundamental, claro, aplicabilidade. Posso usar um pacote off-the-shelf disponveis para fazer a minha tarefa? Uma coisa surpreendente aconteceu aqui. Durante os anos 1950 e 1960, estudar aps estudo mostrou que os usurios no usaria off-the-shelf pacotes para folha de pagamento, estoque controle, contas a receber, etc As exigncias eram muito especializado, caso a caso variao muito alta. Durante a dcada de 1980, encontramos tais pacotes em alta demanda e uso generalizado. O que mudou? Na verdade no os pacotes. Eles podem ser de alguma forma mais generalizada e um tanto mais personalizvel do que antigamente, mas no muito. Na verdade no as aplicaes, tambm. Se Pgina 13 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 13 nada, as necessidades empresariais e cientficos de hoje esto mais diversificadas, mais complicado do que as de 20 anos atrs. A grande mudana foi na relao custo de hardware / software. O comprador de US $ 2 milhes de mquinas em 1960, senti que ele podia pagar 250.000 dlares a mais por um folha de pagamento personalizado programa, que escorregou com facilidade e sem interrupo para o social-computador hostil ambiente. Os compradores de mquinas de escritrio R $ 50.000, hoje, no pode concebivelmente pagar programas personalizados de folha de pagamento, de modo que eles se adaptam seus processos de folha de pagamento para os pacotes disponvel. Computadores so agora to comum, ainda que no to amado, que as adaptaes so aceitos como uma questo de disciplina. H excees dramticas para o meu argumento de que a generalizao do software pacotes mudou pouco ao longo dos anos: planilhas eletrnicas e banco de dados simples sistemas. Essas ferramentas poderosas, to bvios em retrospecto, e ainda to tarde aparecendo, emprestar -se a uma mirade de usos, alguns bastante heterodoxo. Livros de artigos e at agora abundam sobre como lidar com tarefas inesperadas com a planilha. Um grande nmero de aplicaes que anteriormente foram escritos como programas personalizados no Programa Cobol ou Report Gerador so agora rotineiramente feito com essas ferramentas. Muitos usurios j operam seus prprios computadores dia a dia sobre variados aplicaes sem ter que escrever um programa. Na verdade, muitos desses usurios no podem escrever novos programas para suas mquinas, mas eles so, no entanto, perito em resolver novo problemas com eles.

Eu acredito que a estratgia de produtividade mais poderoso software para o homem organizaes 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 estratgia, com programao simples capacidades, tambm ir trabalhar para centenas de cientistas de laboratrio. Requisitos requinte e prototipagem rpida. A parte mais difcil de construir um nico sistema de software decidir precisamente o que construir. Nenhuma outra parte do trabalho conceptual difcil como estabelecer os requisitos tcnicos detalhados, incluindo todos os interfaces para pessoas, para mquinas, e outros sistemas de software. Nenhuma outra parte do trabalhar para aleija o sistema resultante se feito errado. Nenhuma outra parte ir mais difcil rectificar mais tarde. Portanto, a funo mais importante que os construtores de software fazem para os seus clientes o iterativo de extrao e refinamento dos requisitos do produto. Pois a verdade , o os clientes no sabem o que querem. Eles geralmente no sabem que perguntas devem ser respondeu, e quase nunca ter pensado o problema no detalhe que deve ser especificada. Mesmo a simples resposta "Faa o trabalho novo sistema de software como o nosso velho sistema de processamento de informaes manual " na verdade muito simples. Os clientes nunca quer exatamente isso. Sistemas de software complexos so, alm disso, as coisas que funcionam, que se movem, que trabalhar. A dinmica da ao que so difceis de imaginar. Assim, no planejamento de qualquer software actividade, necessrio para permitir uma iterao extensa entre o cliente eo designer como parte da definio do sistema. Eu iria um passo alm e afirmar que realmente impossvel 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 construdo e tentei algumas verses do o produto que est especificando. Pgina 14 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 14 Por isso, um dos mais promissores dos esforos tecnolgicos atuais, e um que ataca a essncia, no os acidentes, do problema de software, o desenvolvimento de abordagens e ferramentas para prototipagem rpida de sistemas como parte da iterativa especificao de requisitos. Um sistema de software prottipo um que simula as interfaces importantes e executa as principais funes do sistema que se destina, embora no sendo necessariamente vinculados por a velocidade do mesmo hardware, tamanho ou restries de custo. Prottipos normalmente executam a tarefas da linha principal da aplicao, mas no fazem qualquer tentativa para manipular as excees, responder corretamente para entradas invlidas, abortar de forma limpa, etc O objetivo do prottipo para fazer estrutura do real conceptual especificado, de modo que o cliente pode test-lo para a consistncia e usabilidade Muito dos atuais procedimentos de aquisio de software se baseia na suposio de que

pode-se especificar um sistema satisfatrio de antecedncia, obter lances para a sua construo, tlo construdo, e instal-lo. Eu acho que essa suposio fundamentalmente errado, e que muitos software de aquisio de primavera problemas daquela falcia. Por isso, eles no podem ser fixadas sem reviso fundamental, aquela que proporciona o desenvolvimento iterativo e especificao de prottipos e produtos. Desenvolvimento incremental - crescer, no construir, o software ainda me lembro o choque que senti na. 1958, quando ouvi pela primeira vez uma palestra amigo sobre a construo de um programa, em vez de escrever um. Em um flash ser ampliou minha viso de conjunto do processo de software. A mudana foi metfora potente e preciso. Hoje entendemos como outro edifcio como processa a construo de software , e ns livremente utilizar outros elementos da metfora, como especificaes, montagem de componentes, e os andaimes. A metfora do edifcio sobreviveu sua utilidade. hora de mudar novamente. Se, como acreditar, as estruturas conceituais que construmos hoje so muito complicados para ser precisamente especificadas com antecedncia, e demasiado complexo para ser construdo perfeitamente, ento 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 construes cujas complexidades emocionar-nos com admirao. O crebro sozinho complicado alm de mapeamento, alm da imitao poderoso, rico em diversidade, autoproteger e auto-renovao. O segredo que ela cultivada, no construdos. Assim deve ser com os nossos sistemas de software. Alguns anos atrs, Harlan Mills props que qualquer sistema de software devem ser cultivadas pelo desenvolvimento incremental. 11 Isto , o sistema primeiro deve ser feito para correr, mesmo que ele no faz nada til, exceto chamar o conjunto apropriado de subprogramas fictcios. Ento, pouco a pouco ela desenvolvida, com os subprogramas, por sua vez sendo desenvolvido em aes ou chamadas para stubs vazios no nvel abaixo. Eu tenho visto os resultados mais dramticos desde que comeou a incitar esta tcnica na construtores do projeto em minha aula de laboratrio de engenharia de software. Nada na ltima dcada foi to radicalmente mudou a minha prpria prtica, ou a sua eficcia. A abordagem necessita projeto top-down, pois um crescente de cima para baixo do software. Ele permite fcil backtracking. Ele se presta para os primeiros prottipos. Cada funo adicional e nova disposio de dados mais complexos ou circunstncias cultivados organicamente do que j est l. 11 Mills, HD, "programao top-down em sistemas de grande porte," Depurando Techniques em grandes sistemas, R. Rustin, ed., Englewood Cliffs, NJ, Prentice-Hall, 1971. Pgina 15 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 15 Os efeitos de moral so surpreendentes. Saltos entusiasmo quando h um sistema em execuo, mesmo que simples. Esforos redobrar quando a primeira imagem de um software grfico novo

sistema aparece no ecr, mesmo se for apenas um rectngulo. 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 benefcios podem ser realizados em grandes projetos como os meus pequenos. 12 Grandes designers. A questo central de como melhorar os centros de arte de software, como ele sempre, sobre as pessoas. Podemos obter bons projetos, seguindo as boas prticas em vez de os pobres. Bom prticas de projeto pode ser ensinado. Os programadores esto entre a parte mais inteligente do populao, para que eles possam aprender boas prticas. Assim, um impulso principal nos Estados Unidos promulgar boa prtica moderna. Novos currculos, literatura nova, novas organizaes, tais como o Instituto de Engenharia de Software, todos vieram a existir, a fim de elevar o nvel da nossa prtica de ruim a boa. Isto inteiramente adequada. No entanto, eu no acredito que ns podemos dar o prximo passo para cima da mesma forma. Considerando que a diferena entre pobres projetos conceituais e os bons pode estar na solidez do mtodo de projeto, a diferena entre projetos bons e grandes certamente no o faz. Grandes projetos vm de grandes estilistas. Construo de software um criativo processo. Metodologia de som pode fortalecer e libertar a mente criativa, no pode inflamar ou inspirar o Drudge. As diferenas no so menores, um pouco como Salieri e Mozart. Estudo aps estudo mostra que os melhores designers de muito produzir estruturas que so mais rpidos, menores, mais simples, mais limpo, e produzido com menos esforo. As diferenas entre a grande ea mdia aproximar uma ordem de magnitude. Uma retrospectiva pouco mostra que, embora muitos finos, sistemas de software teis que foi concebido por comits e construdo por projetos de vrias vias, os sistemas de software que ter animado os fs apaixonados so aqueles que so 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 No Unix Cobol APL PL / 1 Pascal Algol Modula MVS/370 Smalltalk MS-DOS Fortran Fig. 1 produtos excitantes Assim, embora eu apoio fortemente a transferncia de tecnologia e currculo esforos de desenvolvimento em andamento, acho que o esforo 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.

Pgina 16 F. Brooks: No Silver Bullet Essncia e acidente em engenharia de software (1986) 16 Nenhuma organizao software pode ignorar este desafio. Bom gestores, escassos embora sejam, no so mais escassos do que bons designers. Grandes designers e gestores de grandes so ambos muito raro. A maioria das organizaes gastam um esforo considervel em encontrar e cultivar a perspectivas de gesto, eu sei de nenhum que gasta igual esforo em encontrar e desenvolver os grandes estilistas a quem a excelncia tcnica dos produtos ser em ltima instncia dependem. Minha primeira proposta que cada organizao deve determinar software e proclamar que grandes estilistas so to importantes para seu sucesso como grandes administradores so, e que eles podem ser dever ser igualmente nutridos e recompensado. No s o salrio, mas os privilgios de reconhecimento escritrio de tamanho, mobilirio, equipamento tcnico pessoal, verbas para viagens, os funcionrios suporte deve ser totalmente equivalente. Como crescer grandes estilistas? O espao no permite uma longa discusso, mas alguns passos so bvias: Sistematicamente identifique os melhores projetistas o mais cedo possvel. O melhor muitas vezes no so o mais experientes. Atribua um orientador de carreira responsvel 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, episdios de educao formal avanada, e cursos de curta durao, todos intercalados com projeto solo e liderana tcnica atribuies. Oferecer oportunidades para designers de crescimento para interagir e estimular uns aos outros.