Arquitetura de Software

O caso das fábricas de softwareJack Greenfield - Microsoft CorporationJulho de 2004

Resumo: apresenta brevemente a motivação das fábricas de software, uma metodologia de

desenvolvimento da Microsoft. Uma fábrica de software é um ambiente de desenvolvimento

configurado para oferecer suporte ao desenvolvimento rápido de um tipo específico de aplicativo.

As fábricas de software são apenas um passo à frente, lógico na contínua evolução dos métodos e

práticas de desenvolvimento de software. Contudo, elas prometem alterar o caráter da indústria

de software pela introdução de padrões de industrialização. (10 páginas impressas)

Nesta página

Aumentando a escala do desenvolvimento de software

Enfrentando as mudanças futuras, outra vez

As curvas de inovação e as mudanças de paradigma

Elevando o nível de abstração

Industrializando o desenvolvimento de software

O software pode ser industrializado?

Economias de escala e escopo

Com o que se parecerá a industrialização?

Conclusão

Aumentando a escala do desenvolvimento de softwareO desenvolvimento de software, como praticado atualmente, é lento, dispendioso e propenso a

erros, gerando muitas vezes produtos com grande número de defeitos e causando sérios

problemas de usabilidade, confiabilidade, desempenho, segurança e de outras características do

serviço.

Segundo o Standish Group [Sta94], as empresas nos Estados Unidos gastam aproximadamente $

250 bilhões em desenvolvimento de software a cada ano, em cerca de 175.000 projetos. Apenas

16 por cento desses projetos são concluídos dentro do cronograma e do orçamento. Outros 31 por

cento são cancelados, principalmente em função de problemas de qualidade, com perdas em torno

de $ 81 bilhões. Outros 53 por cento excedem seus orçamentos em uma média de 189 por cento,

com perdas de cerca de $ 59 bilhões. Os projetos que são concluídos têm em média apenas 42 por

cento das funcionalidades originalmente planejadas.

Esses números confirmam objetivamente o que já sabemos por experiência, ou seja, que o

desenvolvimento de software faz uso intensivo de mão-de-obra, consumindo mais capital humano

por valor produzido do que o que se deve esperar de uma indústria moderna.

É claro que, a despeito dessas deficiências, os produtos do desenvolvimento de software

fornecem, obviamente, um valor significativo aos clientes, como demonstrado pela tendência, de

longo prazo, de aumento da demanda. Isso não 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 dispõem a sofrer grandes perdas e a

correr riscos para colher os benefícios que o software oferece. Embora essas circunstâncias

evidentemente não sejam as ideais, como demonstrado pela crescente popularidade da

terceirização, elas não parecem forçar mudanças significativas nos métodos e práticas do

desenvolvimento de software como um todo.

Foram obtidos apenas ganhos modestos em produtividade na última década, e talvez os mais

importantes tenham sido as linguagens em códigos de bytes, os padrões e os métodos ágeis. Além

desses avanços, ainda desenvolvemos software da forma como fazíamos há dez anos. Na verdade,

nossos métodos e práticas não mudaram muito, o mesmo acontecendo com os riscos e custos

associados.

A situação, no entanto, está para mudar. A demanda global e total de software está projetada para

sofrer um aumento de ordem de magnitude na próxima década, acionada por novas forças da

economia global, como a emergência da China e o aumento do papel do software na infra-

estrutura social, por novos tipos de aplicativos, como integração de empresas e informática

médica, e pelas tecnologias de novas plataformas como serviços de Web, dispositivos móveis e

aparelhos inteligentes.

Sem aumentos comparáveis de capacidade, parece inevitável que a capacidade de

desenvolvimento total de software está destinada a ficar muito abaixo da demanda total ao final

da década. É lógico que, se as forças do mercado puderem atuar livremente, isso não acontecerá

de fato, uma vez que o interesse dos fornecedores de software garantirá a capacidade necessária

à satisfação da demanda.

Início da página

Enfrentando as mudanças futuras, outra vezO que vai mudar, então, para que a capacidade adicional seja fornecida? Não é preciso muita

análise para ver que os métodos e práticas de desenvolvimento de software terão que mudar

radicalmente.

Como a capacidade da indústria depende do tamanho do pool de desenvolvedores competentes e

da produtividade dos seus membros, aumentar a capacidade do setor requer mais

desenvolvedores utilizando os métodos e as práticas atuais ou um número semelhante de

desenvolvedores utilizando métodos e práticas diferentes.

Embora a cultura do aprendizado cultivada nos últimos dez anos pareça ter aumentado com êxito

o número de desenvolvedores competentes e a competência média do desenvolvedor, o

aprendizado provavelmente não equipará a indústria para satisfazer o nível esperado de demanda,

pelo menos por dois motivos:

• Sabemos por experiência que nunca haverá mais do que uns poucos programadores

excepcionais. Os melhores desenvolvedores são até mil vezes mais produtivos do que os piores,

mas o número de maus desenvolvedores supera o de bons na mesma proporção [Boe81].

• Como observado por Brooks [Bro95], adicionar pessoas a um projeto pode, eventualmente,

gerar margens de retorno menores. A quantidade de capacidade adquirida através do

recrutamento e treinamento de desenvolvedores sofre queda assintótica.

A solução, portanto, deve envolver a modificação dos nossos métodos e práticas. Devemos

encontrar formas de tornar os desenvolvedores muito mais produtivos.

Início da página

As curvas de inovação e as mudanças de paradigmaColetivamente, como indústria, já estivemos aqui antes. A história do desenvolvimento de software

é uma luta contra a complexidade e a mudança, com os ganhos sendo contrabalançados pelas

perdas à medida que o progresso gera uma demanda crescente. Embora um grande progresso

tenha sido feito em meio século, não foi um progresso uniforme. Ao contrário, seguiu os

conhecidos padrões das curvas de inovação, como ilustrado na figura 1 [Chr97].

Figura 1. Curvas de inovação

Normalmente, uma inovação descontínua estabelece as bases para uma nova geração de

tecnologias. O progresso na nova base é inicialmente rápido, mas depois decresce

vagarosamente, à medida que essa base se estabiliza e amadurece. Finalmente, a base perde sua

capacidade de sustentar a inovação e é atingido um patamar. Nesse ponto, outra inovação

descontínua cria uma nova base para uma outra geração de novas tecnologias, e o padrão se

repete. Kuhn chama essas bases de paradigmas, e as transições entre elas de mudanças de

paradigma [Kuh70]. As mudanças de paradigma ocorrem em pontos de junção onde a mudança

existente é necessária para sustentar o momentum de avanço. Nós estamos agora em um ponto

de junção.

Início da página

Elevando o nível de abstraçãoHistoricamente, as mudanças de paradigma aumentaram o nível de abstração para os

desenvolvedores, fornecendo conceitos mais eficazes para captura e reutilização do conhecimento

em plataformas e linguagens. No âmbito da plataforma, por exemplo, evoluímos do

processamento em lotes, passando pelas plataformas terminal/host, cliente/servidor, computador

pessoal, sistemas de vários níveis e integração de aplicativos corporativos até os serviços

assíncronos e fracamente acoplados. No âmbito da linguagem, evoluímos da codificação numérica,

passando pelas linguagens assembly, estruturadas e orientadas a objeto, até chegarmos a

linguagens e padrões codificados em bytes que podem ser vistos como abstrações baseadas em

linguagem. Smith e Stotts sintetizam essa progressão de forma eloqüente [SS02]:

A história da programação é um exercício de abstração hierárquica. A cada geração, os designers

de linguagens geram construções das lições aprendidas na geração passada, que os arquitetos

usam em seguida para criar abstrações ainda mais complexas e de grande eficácia.

Eles destacam também que as novas abstrações tendem a surgir primeiramente nas plataformas,

para depois migrar para as linguagens. Estamos em um momento dessa progressão em que as

abstrações baseadas em linguagens estão atrasadas em relação às abstrações baseadas em

plataforma há muito tempo. Ou, para dizer de outra maneira, estamos em um ponto em que as

ferramentas encontram-se atrás das plataformas há muito tempo. Usando a última geração da

tecnologia de plataforma, por exemplo, podemos agora automatizar processos abrangendo várias

empresas localizadas em qualquer lugar do planeta, usando serviços compostos por orquestração,

mas ainda costuramos à mão cada um desses aplicativos, como se fosse o primeiro da sua

espécie. Criamos grandes conceitos abstratos, como pedidos de indenização de seguro e acordos

de segurança, a partir de conceitos pequenos e concretos, como loops, seqüência de caracteres e

números inteiros. Nós organizamos cuidadosa e arduamente milhões de minúsculas peças inter-

relacionadas de código-fonte e recursos, para formar estruturas muitíssimo complexas. Se a

indústria de semicondutores usasse uma abordagem semelhante, construiria os processadores

imensamente complexos que processam esses aplicativos com transistores soldados à mão. Em

vez disso, essa indústria monta componentes predefinidos denominados ASICs (Application

Specific Integrated Circuits), usando ferramentas como as da figura 2, e depois gera as

implementações.

Figura 2. Ferramentas de design baseadas em ASIC7

Não 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 benefícios como independência e

integração de dados, o que torna os aplicativos voltados a dados mais fáceis 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 criação e manutenção de interfaces gráficas de

usuário, oferecendo benefícios como independência de dispositivos e montagem visual.

Observando atentamente a maneira como isso foi feito, podemos ver um padrão recorrente.

• Depois de desenvolver uma série de sistemas em um determinado domínio de problema,

identificamos um conjunto de abstrações reutilizáveis nesse domínio, e então documentamos

um conjunto de padrões de uso dessas abstrações.

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

abstrações e padrões. Isso nos leva a criar sistemas no domínio, por meio de instanciação,

adaptação, configuração e montagem de componentes definidos pelo runtime.

• Nós então 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 rápida às necessidades de mudanças,

uma vez que parte da implementação é gerada e pode ser modificada com facilidade.

Trata-se do conhecido padrão 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 difícil. A estrutura define um produto arquetípico, como um

aplicativo ou subsistema, que pode ser finalizado ou especializado de diversas maneiras para

atender a variações de necessidades. Mapear as necessidades de cada variante de produto em

uma estrutura não é um problema simples e requer geralmente a habilidade de um arquiteto ou

desenvolvedor sênior. As ferramentas baseadas em linguagem podem automatizar essa etapa

pela captura de variedades de requisitos usando expressões de linguagens e gerando código de

conclusão da estrutura.

Início da página

Industrializando o desenvolvimento de softwareOutras indústrias aumentaram sua capacidade passando do artesanato, onde produtos inteiros são

criados desde o início por indivíduos ou pequenas equipes, para a fabricação, onde uma larga

gama de produtos é montada rapidamente com componentes reutilizáveis, criados por diversos

fornecedores e onde as máquinas automatizam as repetições ou as tarefas subalternas. Elas

padronizaram processos, projetos e embalagem, usando de linhas de produtos que facilitam a

reutilização sistemática e cadeias logísticas que distribuem o custo e o risco. Algumas são, hoje,

capazes de uma personalização em massa, onde as variantes do produto são criadas de forma

rápida e não dispendiosa, de acordo com o pedido, para atender às necessidades específicas de

clientes individuais.

Início da página

O software pode ser industrializado?As analogias entre o software e os produtos físicos já foram ardentemente discutidas. Esses

padrões de industrialização podem ser aplicados à indústria do software? Seríamos nós de alguma

forma especiais ou diferentes dos outros setores em função da natureza do nosso produto? Peter

Wegner sintetiza semelhanças e dessemelhanças da seguinte forma [Weg78]:

Os produtos de software são, em alguns aspectos, como os produtos tangíveis das disciplinas

convencionais da engenharia, como pontes, prédios e computadores. Mas existem também

algumas diferenças importantes que dão ao desenvolvimento de software um sabor único. Como o

software é lógico e não físico, seus custos estão concentrados no desenvolvimento e não na

produção e como o software não se desgasta, sua confiabilidade depende das qualidades lógicas,

como precisão e solidez, em lugar de qualidades físicas como dureza e maleabilidade.

Algumas discussões envolveram uma comparação do tipo "laranjas e maçãs" entre a produção de

bens físicos, de um lado, e o desenvolvimento de software do outro. A chave para esclarecer a

confusão é compreender as diferenças entre a produção e o desenvolvimento e entre economias

de escala e escopo.

Para fornecer retorno de investimento, os componentes reutilizáveis devem ser reutilizados o

bastante para mais do que recuperar o custo de seu desenvolvimento, tanto diretamente, através

da redução de custo, quanto indiretamente, através da redução dos riscos, da diminuição do

tempo para colocação no mercado ou do aprimoramento da qualidade. Os componentes

reutilizáveis são ativos financeiros do ponto de vista do investimento. Como os custos da criação

de um componente reutilizável são geralmente bastante altos, é improvável que os níveis de

lucratividade da reutilização sejam alcançados por acaso. Uma abordagem sistemática de

reutilização torna-se então necessária. Isso geralmente envolve a identificação de um domínio no

qual diversos sistemas serão desenvolvidos, a identificação de problemas recorrentes nesse

domínio, o desenvolvimento de conjuntos de bens de produção integrados que resolvam esses

problemas e, em seguida, sua aplicação à medida que sistemas forem desenvolvidos no domínio.

Início da página

Economias de escala e escopo

A reutilização sistemática pode gerar economias de escala e escopo. Esses dois efeitos são

bastante conhecidos em outras indústrias. Embora ambos reduzam tempo e custo, e aprimorem a

qualidade do produto pela produção coletiva e não individual de diversos produtos, diferem na

forma como produzem esses benefícios.

As economias de escala surgem quando várias instâncias idênticas de um único projeto são

produzidas coletivamente, e não individualmente, como ilustrado na figura 3. Essas economias

surgem da produção de itens como parafusos, quando os bens de produção, como as máquinas,

são usados para produzir várias instâncias idênticas do produto. Um projeto é criado, juntamente

com as instâncias iniciais, chamadas protótipos, por um processo de uso intensivo de recursos,

chamado desenvolvimento, que é realizado por engenheiros. Diversas instâncias adicionais,

chamadas cópias, são então produzidas por um outro processo, chamado produção, realizado por

máquinas e/ou por mão-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 protótipos semelhantes, porém

distintos, são produzidos coletivamente, em vez de individualmente, como ilustrado na figura 4. Na

fabricação de automóveis, por exemplo, diversos projetos semelhantes, mas distintos, de

automóveis são freqüentemente desenvolvidos pela composição de projetos existentes de

subcomponentes, como chassi, corpo, interior e sistema de direção, e as variações e modelos são

muitas vezes criados pela diversificação de características, como motor e nível de acabamento,

em projetos já existentes. Em outras palavras, as mesmas práticas, processos, ferramentas e

materiais são usados para criar diversos projetos e protótipos de produtos semelhantes, porém

distintos. O mesmo acontece na construção civil, onde várias pontes e arranha-céus raramente

partilham um projeto comum. No entanto, um ponto interessante da construção civil é que, em

geral, apenas uma ou duas instâncias de um projeto bem-sucedido são produzidas, então as

economias de escala são raras ou não existem. Na fabricação de automóveis, onde diversas

instâncias idênticas de projetos bem-sucedidos são normalmente produzidas, as economias de

escopo são complementadas pelas economias de escala, como ilustrado pelas cópias de cada

protótipo mostrado na figura 4.

Figura 4. Economias de escopo

É lógico que existem diferenças significativas entre a criação de software, a indústria

automobilística e a construção civil, mas a criação de software se parece algumas vezes com uma

e com outra.

• Em mercados como o consumidor de desktop, onde as cópias de produtos como sistemas

operacionais e aplicativos de produtividade são produzidas em massa, o software apresenta

economias de escala como na indústria automobiística.

• Em mercados como o corporativo, onde os aplicativos comerciais desenvolvidos para se obter

uma vantagem competitiva são raramente produzidos em massa, se é que isso ocorre, o

software apresenta apenas economias de escopo como acontece na construção civil.

Podemos então ver onde maçãs estão sendo comparadas com laranjas. A produção nas indústrias

físicas foi ingenuamente comparada ao desenvolvimento de software. Não faz sentido procurar

economias de escala no desenvolvimento de nenhuma espécie, seja de software, seja de bens

físicos. Nós podemos, por outro lado, esperar que a industrialização do desenvolvimento de

software explore economias de escopo.

Início da página

Com o que se parecerá a industrialização?Presumindo-se que a industrialização possa ocorrer na indústria de software, com o que ela se

parecerá? Não podemos saber com certeza até que isso ocorra, é claro. Podemos, no entanto,

fazer suposições embasadas, levando em conta a indústria do software tomou e na forma como a

industrialização ocorreu em outros setores. É claro que o desenvolvimento de software nunca será

reduzido a um processo puramente mecânico atendido por operários. Ao contrário, 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 criação manual de produtos finais que necessitarão de

manutenção ou mesmo de substituição em apenas uns poucos meses ou anos, quando ocorrer o

lançamento da próxima plataforma principal, ou quando alterações nas condições do mercado

gerarem mudanças das necessidades comerciais, o que ocorrer primeiro.

Uma forma de fazer isso é proporcionar aos desenvolvedores formas de encapsular o seu

conhecimento como bens reutilizáveis que outros possam usar. Seria isso muito ambicioso? Os

padrões já demonstram uma reutilização de conhecimento limitado mas efetivo. A próxima etapa

é passar da documentação para a automação, usando linguagens, estruturas e ferramentas para

automatizar a aplicação do padrão.

O desenvolvimento do semicondutor oferece uma antevisão de como será o desenvolvimento de

software quando ocorrer a industrialização. Isso não equivale a dizer que os componentes de

software serão em breve tão fáceis de montar como os ASICs. Os ASICs são produtos altamente

evoluídos de duas décadas de inovação e padronização 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 indústria dos semicondutores sofreu a carga adicional de realizar a

engenharia dos materiais físicos utilizados na implementação de componentes. Ao mesmo tempo,

a natureza efêmera dos bits cria desafios como a proteção dos direitos da propriedade digital,

como nas indústrias da música e do cinema.

Início da página

ConclusãoEste artigo descreveu a incapacidade da indústria de software atender à demanda projetada

usando os métodos e práticas atuais. Problemas diversos e importantes são brevemente discutidos

aqui, deixando, sem dúvida, o leitor desejoso de evidências e aprofundamento da discussão. Uma

discussão 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 informações podem também ser encontradas em

http://msdn.microsoft.com/architecture/overview/softwarefactories e

http://www.softwarefactories.com/, incluindo-se artigos que descrevem problemas crônicos que

impedem a transição do artesanato para a fabricação, as inovações essenciais que vão ajudar a

indústria a ultrapassar esses problemas e a metodologia de fábricas de software, que integra as

principais inovações.

Declaração de direito autoral

Copyright © 2004 de Jack Greenfield. Partes têm copyright © 2003 de Jack Greenfield e Keith

Short, e são reproduzidas com a autorização de Wiley Publishing, Inc. Todos os direitos reservados.

Referências

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 ilustração contendo o Virtuoso® Chip Editor e o Virtuoso® XL Layout Editor foi reproduzida

com a autorização de Cadence Design Systems, Inc. © 2003. Cadence Design Systems, Inc. Todos

os direitos reservados. Cadence e Virtuoso são 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 também com o UML, J2EE e as especificações associadas a OMG e JSP. Ele tem um B.S.

em Física pela George Mason University. Jack pode ser encontrado em jackgr@microsoft.com.

© 2004 Microsoft Corporation. Todos os direitos reservados. Termos de uso.

Início da página

  Versão para Impressão   Enviar esta Página  Adicionar a Favoritos

Fale Conosco |Imprima esta página |Adicione aos Favoritos©2005 Microsoft Corporation. Todos os direitos reservados. Nota Legal |Marcas comerciais |Política de Privacidade