Arquitetura de Software

O caso das fbricas de software

Jack Greenfield - Microsoft Corporation
Julho de 2004
Resumo: apresenta brevemente a motivao das fbricas de software, uma metodologia de
desenvolvimento da Microsoft. Uma fbrica de software um ambiente de desenvolvimento
configurado para oferecer suporte ao desenvolvimento rpido de um tipo especfico de aplicativo.
As fbricas de software so apenas um passo frente, lgico na contnua evoluo dos mtodos e
prticas de desenvolvimento de software. Contudo, elas prometem alterar o carter da indstria
de software pela introduo de padres de industrializao. (10 pginas impressas)
Nesta pgina
Aumentando a escala do desenvolvimento de software

Enfrentando as mudanas futuras, outra vez

As curvas de inovao e as mudanas de paradigma

Elevando o nvel de abstrao

Industrializando o desenvolvimento de software

O software pode ser industrializado?

Economias de escala e escopo

Com o que se parecer a industrializao?

Concluso

Aumentando a escala do desenvolvimento de software

O desenvolvimento de software, como praticado atualmente, lento, dispendioso e propenso a
erros, gerando muitas vezes produtos com grande nmero de defeitos e causando srios
problemas de usabilidade, confiabilidade, desempenho, segurana e de outras caractersticas do
servio.
Segundo o Standish Group [Sta94], as empresas nos Estados Unidos gastam aproximadamente $
250 bilhes em desenvolvimento de software a cada ano, em cerca de 175.000 projetos. Apenas
16 por cento desses projetos so concludos dentro do cronograma e do oramento. Outros 31 por
cento so cancelados, principalmente em funo de problemas de qualidade, com perdas em torno
de $ 81 bilhes. Outros 53 por cento excedem seus oramentos em uma mdia de 189 por cento,
com perdas de cerca de $ 59 bilhes. Os projetos que so concludos tm em mdia apenas 42
por cento das funcionalidades originalmente planejadas.
Esses nmeros confirmam objetivamente o que j sabemos por experincia, ou seja, que o
desenvolvimento de software faz uso intensivo de mo-de-obra, consumindo mais capital humano
por valor produzido do que o que se deve esperar de uma indstria moderna.

 claro que, a despeito dessas deficincias, os produtos do desenvolvimento de software

fornecem, obviamente, um valor significativo aos clientes, como demonstrado pela tendncia, de
longo prazo, de aumento da demanda. Isso no quer dizer que os consumidores estejam
plenamente satisfeitos, seja com o software fornecido ou com a forma como o fornecemos. Isso
significa apenas que eles valorizam o software, tanto que se dispem a sofrer grandes perdas e a
correr riscos para colher os benefcios que o software oferece. Embora essas circunstncias
evidentemente no sejam as ideais, como demonstrado pela crescente popularidade da
terceirizao, elas no parecem forar mudanas significativas nos mtodos e prticas do
desenvolvimento de software como um todo.
Foram obtidos apenas ganhos modestos em produtividade na ltima dcada, e talvez os mais
importantes tenham sido as linguagens em cdigos de bytes, os padres e os mtodos geis. Alm
desses avanos, ainda desenvolvemos software da forma como fazamos h dez anos. Na verdade,
nossos mtodos e prticas no mudaram muito, o mesmo acontecendo com os riscos e custos
associados.
A situao, no entanto, est para mudar. A demanda global e total de software est projetada para
sofrer um aumento de ordem de magnitude na prxima dcada, acionada por novas foras da
economia global, como a emergncia da China e o aumento do papel do software na infraestrutura social, por novos tipos de aplicativos, como integrao de empresas e informtica
mdica, e pelas tecnologias de novas plataformas como servios de Web, dispositivos mveis e
aparelhos inteligentes.
Sem aumentos comparveis de capacidade, parece inevitvel que a capacidade de
desenvolvimento total de software est destinada a ficar muito abaixo da demanda total ao final
da dcada. lgico que, se as foras do mercado puderem atuar livremente, isso no acontecer
de fato, uma vez que o interesse dos fornecedores de software garantir a capacidade necessria
satisfao da demanda.
Incio da pgina

Enfrentando as mudanas futuras, outra vez

O que vai mudar, ento, para que a capacidade adicional seja fornecida? No preciso muita
anlise para ver que os mtodos e prticas de desenvolvimento de software tero que mudar
radicalmente.
Como a capacidade da indstria depende do tamanho do pool de desenvolvedores competentes e
da produtividade dos seus membros, aumentar a capacidade do setor requer mais
desenvolvedores utilizando os mtodos e as prticas atuais ou um nmero semelhante de
desenvolvedores utilizando mtodos e prticas diferentes.
Embora a cultura do aprendizado cultivada nos ltimos dez anos parea ter aumentado com xito
o nmero de desenvolvedores competentes e a competncia mdia do desenvolvedor, o
aprendizado provavelmente no equipar a indstria para satisfazer o nvel esperado de demanda,
pelo menos por dois motivos:

Sabemos por experincia que nunca haver mais do que uns poucos programadores
excepcionais. Os melhores desenvolvedores so at mil vezes mais produtivos do que os piores,
mas o nmero de maus desenvolvedores supera o de bons na mesma proporo [Boe81].
Como observado por Brooks [Bro95], adicionar pessoas a um projeto pode, eventualmente,
gerar margens de retorno menores. A quantidade de capacidade adquirida atravs do

recrutamento e treinamento de desenvolvedores sofre queda assinttica.

A soluo, portanto, deve envolver a modificao dos nossos mtodos e prticas. Devemos
encontrar formas de tornar os desenvolvedores muito mais produtivos.
Incio da pgina

As curvas de inovao e as mudanas de paradigma

Coletivamente, como indstria, j estivemos aqui antes. A histria do desenvolvimento de

software uma luta contra a complexidade e a mudana, com os ganhos sendo contrabalanados
pelas perdas medida que o progresso gera uma demanda crescente. Embora um grande
progresso tenha sido feito em meio sculo, no foi um progresso uniforme. Ao contrrio, seguiu os
conhecidos padres das curvas de inovao, como ilustrado na figura 1 [Chr97].

Figura 1. Curvas de inovao

Normalmente, uma inovao descontnua estabelece as bases para uma nova gerao de
tecnologias. O progresso na nova base inicialmente rpido, mas depois decresce vagarosamente,
medida que essa base se estabiliza e amadurece. Finalmente, a base perde sua capacidade de
sustentar a inovao e atingido um patamar. Nesse ponto, outra inovao descontnua cria uma
nova base para uma outra gerao de novas tecnologias, e o padro se repete. Kuhn chama essas
bases de paradigmas, e as transies entre elas de mudanas de paradigma [Kuh70]. As
mudanas de paradigma ocorrem em pontos de juno onde a mudana existente necessria
para sustentar o momentum de avano. Ns estamos agora em um ponto de juno.
Incio da pgina

Elevando o nvel de abstrao

Historicamente, as mudanas de paradigma aumentaram o nvel de abstrao para os
desenvolvedores, fornecendo conceitos mais eficazes para captura e reutilizao do conhecimento
em plataformas e linguagens. No mbito da plataforma, por exemplo, evolumos do
processamento em lotes, passando pelas plataformas terminal/host, cliente/servidor, computador
pessoal, sistemas de vrios nveis e integrao de aplicativos corporativos at os servios
assncronos e fracamente acoplados. No mbito da linguagem, evolumos da codificao numrica,
passando pelas linguagens assembly, estruturadas e orientadas a objeto, at chegarmos a
linguagens e padres codificados em bytes que podem ser vistos como abstraes baseadas em
linguagem. Smith e Stotts sintetizam essa progresso de forma eloqente [SS02]:

A histria da programao um exerccio de abstrao hierrquica. A cada gerao, os designers

de linguagens geram construes das lies aprendidas na gerao passada, que os arquitetos
usam em seguida para criar abstraes ainda mais complexas e de grande eficcia.
Eles destacam tambm que as novas abstraes tendem a surgir primeiramente nas plataformas,
para depois migrar para as linguagens. Estamos em um momento dessa progresso em que as
abstraes baseadas em linguagens esto atrasadas em relao s abstraes baseadas em
plataforma h muito tempo. Ou, para dizer de outra maneira, estamos em um ponto em que as
ferramentas encontram-se atrs das plataformas h muito tempo. Usando a ltima gerao da
tecnologia de plataforma, por exemplo, podemos agora automatizar processos abrangendo vrias
empresas localizadas em qualquer lugar do planeta, usando servios compostos por orquestrao,
mas ainda costuramos mo cada um desses aplicativos, como se fosse o primeiro da sua
espcie. Criamos grandes conceitos abstratos, como pedidos de indenizao de seguro e acordos
de segurana, a partir de conceitos pequenos e concretos, como loops, seqncia de caracteres e
nmeros inteiros. Ns organizamos cuidadosa e arduamente milhes de minsculas peas interrelacionadas de cdigo-fonte e recursos, para formar estruturas muitssimo complexas. Se a
indstria de semicondutores usasse uma abordagem semelhante, construiria os processadores
imensamente complexos que processam esses aplicativos com transistores soldados mo. Em
vez disso, essa indstria monta componentes predefinidos denominados ASICs (Application
Specific Integrated Circuits), usando ferramentas como as da figura 2, e depois gera as
implementaes.

Figura 2. Ferramentas de design baseadas em ASIC 7

No podemos automatizar o desenvolvimento de software de forma semelhante? claro que sim,
e na verdade j fizemos isso. Os sistemas de gerenciamento de bancos de dados, por exemplo,
automatizam o acesso aos dados usando o SQL, fornecendo benefcios como independncia e
integrao de dados, o que torna os aplicativos voltados a dados mais fceis de criar e manter. Da
mesma forma, os editores WYSIWYG (What You See Is What You Get , O formato exibido o
resultado final) e de metaestruturas facilitam a criao e manuteno de interfaces grficas de
usurio, oferecendo benefcios como independncia de dispositivos e montagem visual.
Observando atentamente a maneira como isso foi feito, podemos ver um padro recorrente.

Depois de desenvolver uma srie de sistemas em um determinado domnio de problema,

identificamos um conjunto de abstraes reutilizveis nesse domnio, e ento documentamos
um conjunto de padres de uso dessas abstraes.

Em seguida, desenvolvemos um runtime, como uma estrutura ou servidor, para codificar as

abstraes e padres. Isso nos leva a criar sistemas no domnio, por meio de instanciao,
adaptao, configurao e montagem de componentes definidos pelo runtime.
Ns ento definimos a linguagem e criamos ferramentas para oferecer suporte a essa
linguagem, tais como editores, compiladores e depuradores, para automatizar o processo de
montagem. Isso nos ajuda a responder de forma mais rpida s necessidades de mudanas,

uma vez que parte da implementao gerada e pode ser modificada com facilidade.
Trata-se do conhecido padro de estrutura de linguagem descrito por Roberts e Johnson [RJ96].
Uma estrutura pode reduzir o custo de desenvolvimento de um aplicativo em uma ordem de
grandeza, mas utiliz-la pode ser difcil. A estrutura define um produto arquetpico, como um
aplicativo ou subsistema, que pode ser finalizado ou especializado de diversas maneiras para
atender a variaes de necessidades. Mapear as necessidades de cada variante de produto em
uma estrutura no um problema simples e requer geralmente a habilidade de um arquiteto ou
desenvolvedor snior. As ferramentas baseadas em linguagem podem automatizar essa etapa pela
captura de variedades de requisitos usando expresses de linguagens e gerando cdigo de
concluso da estrutura.
Incio da pgina

Industrializando o desenvolvimento de software

Outras indstrias aumentaram sua capacidade passando do artesanato, onde produtos inteiros so
criados desde o incio por indivduos ou pequenas equipes, para a fabricao, onde uma larga
gama de produtos montada rapidamente com componentes reutilizveis, criados por diversos
fornecedores e onde as mquinas automatizam as repeties ou as tarefas subalternas. Elas
padronizaram processos, projetos e embalagem, usando de linhas de produtos que facilitam a
reutilizao sistemtica e cadeias logsticas que distribuem o custo e o risco. Algumas so, hoje,
capazes de uma personalizao em massa, onde as variantes do produto so criadas de forma
rpida e no dispendiosa, de acordo com o pedido, para atender s necessidades especficas de
clientes individuais.
Incio da pgina

O software pode ser industrializado?

As analogias entre o software e os produtos fsicos j foram ardentemente discutidas. Esses
padres de industrializao podem ser aplicados indstria do software? Seramos ns de alguma
forma especiais ou diferentes dos outros setores em funo da natureza do nosso produto? Peter
Wegner sintetiza semelhanas e dessemelhanas da seguinte forma [Weg78]:
Os produtos de software so, em alguns aspectos, como os produtos tangveis das disciplinas
convencionais da engenharia, como pontes, prdios e computadores. Mas existem tambm
algumas diferenas importantes que do ao desenvolvimento de software um sabor nico. Como o
software lgico e no fsico, seus custos esto concentrados no desenvolvimento e no na
produo e como o software no se desgasta, sua confiabilidade depende das qualidades lgicas,
como preciso e solidez, em lugar de qualidades fsicas como dureza e maleabilidade.
Algumas discusses envolveram uma comparao do tipo "laranjas e mas" entre a produo de
bens fsicos, de um lado, e o desenvolvimento de software do outro. A chave para esclarecer a
confuso compreender as diferenas entre a produo e o desenvolvimento e entre economias
de escala e escopo.
Para fornecer retorno de investimento, os componentes reutilizveis devem ser reutilizados o
bastante para mais do que recuperar o custo de seu desenvolvimento, tanto diretamente, atravs
da reduo de custo, quanto indiretamente, atravs da reduo dos riscos, da diminuio do
tempo para colocao no mercado ou do aprimoramento da qualidade. Os componentes
reutilizveis so ativos financeiros do ponto de vista do investimento. Como os custos da criao
de um componente reutilizvel so geralmente bastante altos, improvvel que os nveis de

lucratividade da reutilizao sejam alcanados por acaso. Uma abordagem sistemtica de

reutilizao torna-se ento necessria. Isso geralmente envolve a identificao de um domnio no
qual diversos sistemas sero desenvolvidos, a identificao de problemas recorrentes nesse
domnio, o desenvolvimento de conjuntos de bens de produo integrados que resolvam esses
problemas e, em seguida, sua aplicao medida que sistemas forem desenvolvidos no domnio.
Incio da pgina

Economias de escala e escopo

A reutilizao sistemtica pode gerar economias de escala e escopo. Esses dois efeitos so
bastante conhecidos em outras indstrias. Embora ambos reduzam tempo e custo, e aprimorem a
qualidade do produto pela produo coletiva e no individual de diversos produtos, diferem na
forma como produzem esses benefcios.
As economias de escala surgem quando vrias instncias idnticas de um nico projeto so
produzidas coletivamente, e no individualmente, como ilustrado na figura 3. Essas economias
surgem da produo de itens como parafusos, quando os bens de produo, como as mquinas,
so usados para produzir vrias instncias idnticas do produto. Um projeto criado, juntamente
com as instncias iniciais, chamadas prottipos, por um processo de uso intensivo de recursos,
chamado desenvolvimento, que realizado por engenheiros. Diversas instncias adicionais,
chamadas cpias, so ento produzidas por um outro processo, chamado produo, realizado por
mquinas e/ou por mo-de-obra de baixo custo, para atender a uma demanda de mercado.

Figura 3. Economias de escala

As economias de escopo surgem quando diversos projetos e prottipos semelhantes, porm
distintos, so produzidos coletivamente, em vez de individualmente, como ilustrado na figura 4.
Na fabricao de automveis, por exemplo, diversos projetos semelhantes, mas distintos, de
automveis so freqentemente desenvolvidos pela composio de projetos existentes de
subcomponentes, como chassi, corpo, interior e sistema de direo, e as variaes e modelos so
muitas vezes criados pela diversificao de caractersticas, como motor e nvel de acabamento, em
projetos j existentes. Em outras palavras, as mesmas prticas, processos, ferramentas e
materiais so usados para criar diversos projetos e prottipos de produtos semelhantes, porm
distintos. O mesmo acontece na construo civil, onde vrias pontes e arranha-cus raramente
partilham um projeto comum. No entanto, um ponto interessante da construo civil que, em
geral, apenas uma ou duas instncias de um projeto bem-sucedido so produzidas, ento as

economias de escala so raras ou no existem. Na fabricao de automveis, onde diversas

instncias idnticas de projetos bem-sucedidos so normalmente produzidas, as economias de
escopo so complementadas pelas economias de escala, como ilustrado pelas cpias de cada
prottipo mostrado na figura 4.

Figura 4. Economias de escopo

lgico que existem diferenas significativas entre a criao de software, a indstria
automobilstica e a construo civil, mas a criao de software se parece algumas vezes com uma
e com outra.

Em mercados como o consumidor de desktop, onde as cpias de produtos como sistemas

operacionais e aplicativos de produtividade so produzidas em massa, o software apresenta
economias de escala como na indstria automobistica.
Em mercados como o corporativo, onde os aplicativos comerciais desenvolvidos para se obter
uma vantagem competitiva so raramente produzidos em massa, se que isso ocorre, o

software apresenta apenas economias de escopo como acontece na construo civil.

Podemos ento ver onde mas esto sendo comparadas com laranjas. A produo nas indstrias
fsicas foi ingenuamente comparada ao desenvolvimento de software. No faz sentido procurar
economias de escala no desenvolvimento de nenhuma espcie, seja de software, seja de bens
fsicos. Ns podemos, por outro lado, esperar que a industrializao do desenvolvimento de
software explore economias de escopo.
Incio da pgina

Com o que se parecer a industrializao?

Presumindo-se que a industrializao possa ocorrer na indstria de software, com o que ela se
parecer? No podemos saber com certeza at que isso ocorra, claro. Podemos, no entanto,
fazer suposies embasadas, levando em conta a indstria do software tomou e na forma como a
industrializao ocorreu em outros setores. claro que o desenvolvimento de software nunca ser
reduzido a um processo puramente mecnico atendido por operrios. Ao contrrio, a chave para
atender demanda global parar de gastar o tempo de desenvolvedores preparados com tarefas
repetitivas e subalternas. preciso encontrar maneiras de fazer um uso mais adequado dos
recursos preciosos do que gast-los na criao manual de produtos finais que necessitaro de
manuteno ou mesmo de substituio em apenas uns poucos meses ou anos, quando ocorrer o

lanamento da prxima plataforma principal, ou quando alteraes nas condies do mercado

gerarem mudanas das necessidades comerciais, o que ocorrer primeiro.
Uma forma de fazer isso proporcionar aos desenvolvedores formas de encapsular o seu
conhecimento como bens reutilizveis que outros possam usar. Seria isso muito ambicioso? Os
padres j demonstram uma reutilizao de conhecimento limitado mas efetivo. A prxima etapa
passar da documentao para a automao, usando linguagens, estruturas e ferramentas para
automatizar a aplicao do padro.
O desenvolvimento do semicondutor oferece uma anteviso de como ser o desenvolvimento de
software quando ocorrer a industrializao. Isso no equivale a dizer que os componentes de
software sero em breve to fceis de montar como os ASICs. Os ASICs so produtos altamente
evoludos de duas dcadas de inovao e padronizao da tecnologia da interface e
empacotamento. Por outro lado, isso pode levar menos de 20 anos. Temos a vantagem de lidar
apenas com bits, enquanto a indstria dos semicondutores sofreu a carga adicional de realizar a
engenharia dos materiais fsicos utilizados na implementao de componentes. Ao mesmo tempo,
a natureza efmera dos bits cria desafios como a proteo dos direitos da propriedade digital,
como nas indstrias da msica e do cinema.
Incio da pgina

Concluso
Este artigo descreveu a incapacidade da indstria de software atender demanda projetada
usando os mtodos e prticas atuais. Problemas diversos e importantes so brevemente discutidos
aqui, deixando, sem dvida, o leitor desejoso de evidncias e aprofundamento da discusso. Uma
discusso muito mais detalhada fornecida no livro Software Factories: Assembling Applications
with Patterns, Models, Frameworks and Tools, de Jack Greenfield e Keith Short, da John Wiley and
Sons. Mais informaes podem tambm ser encontradas em
http://msdn.microsoft.com/architecture/overview/softwarefactories e
http://www.softwarefactories.com/, incluindo-se artigos que descrevem problemas crnicos que
impedem a transio do artesanato para a fabricao, as inovaes essenciais que vo ajudar a
indstria a ultrapassar esses problemas e a metodologia de fbricas de software, que integra as
principais inovaes.
Declarao de direito autoral
Copyright 2004 de Jack Greenfield. Partes tm copyright 2003 de Jack Greenfield e Keith
Short, e so reproduzidas com a autorizao de Wiley Publishing, Inc. Todos os direitos
reservados.
Referncias
1. [Boe81] B Boehm. Software Engineering Economics. Prentice Hall PTR, 1981
2. [Bro95] F Brooks. The Mythical Man-Month. Addison-Wesley, 1995
3. [Chr97] C Christensen. The Innovator's Dilemma, Harvard Business School Press, 1997
4. [Kuh70] T Kuhn. The Structure Of Scientific Revolutions. The University Of Chicago Press, 1970
5. [RJ96] D Roberts and R. Johnson. Evolving Frameworks: A Pattern Language for Developing
Object-Oriented Frameworks. Proceedings of Pattern Languages of Programs, Allerton Park,
Illinois, September 1996
6. [SS02] J. Smith and D Stotts. Elemental Design Patterns A Link Between Architecture and
Object Semantics. Proceedings of OOPSLA 2002
7. A ilustrao contendo o Virtuoso Chip Editor e o Virtuoso XL Layout Editor foi reproduzida
com a autorizao de Cadence Design Systems, Inc. 2003. Cadence Design Systems, Inc. Todos
os direitos reservados. Cadence e Virtuoso so marcas registradas de Cadence Design Systems,
Inc.
8. [Sta94] The Standish Group. The Chaos

Report.http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf
9. [Weg78] P Wegner. Research Directions In Software Technology. Proceedings Of The 3rd
International Conference On Software Engineering. 1978
Sobre o autor
Jack Greenfield um arquiteto de estruturas comerciais e ferramentas da Microsoft. Ele foi
anteriormente Chief Architect no Practitioner Desktop Group da Rational Software Corporation e
fundador e CTO da InLine Software Corporation. Na NeXT, ele desenvolveu o Enterprise Objects
Framework, hoje denominado Apple Web Objects. Palestrante e escritor muito conhecido,
contribuiu tambm com o UML, J2EE e as especificaes associadas a OMG e JSP. Ele tem um B.S.
em Fsica pela George Mason University. Jack pode ser encontrado em jackgr@microsoft.com.
2004 Microsoft Corporation. Todos os direitos reservados. Termos de uso.
Incio da pgina
Verso para Impresso

Enviar esta Pgina

Adicionar a Favoritos

Fale Conosco |Imprima esta pgina |Adicione aos Favoritos

2005 Microsoft Corporation. Todos os direitos reservados. Nota Legal |Marcas
comerciais |Poltica de Privacidade