O caso das fábricas de software

Jack Greenfield - Microsoft Corporation

Julho 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 software

O 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.

Enfrentando as mudanças futuras, outra vez

O 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.

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

Coletivamente, 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].

Aa480032.aj3softfac_fig1(pt-br,MSDN.10).gif
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.

Elevando o nível de abstração

Historicamente, 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.

Aa480032.aj3softfac_fig2(pt-br,MSDN.10).gif
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.

Industrializando o desenvolvimento de software

Outras 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.

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.

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.

Aa480032.aj3softfac_fig3(pt-br,MSDN.10).gif
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.

Aa480032.aj3softfac_fig4(pt-br,MSDN.10).gif
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.

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.

Conclusão

Este 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.

© .

Mostrar: