• Nenhum resultado encontrado

Capítulo 3 – Engenharia de Software Baseada em Valor e Ecossistemas de Software

3.5 Perspectiva Futura: Ecossistemas de Software

Em uma década em que esforços são despendidos em direção ao entendimento do valor na Engenharia de Software, a também presente e real interferência de questões ou aspectos não-técnicos como um fator-chave para o sucesso de projetos, processos e

produtos de software abre novas perspectivas para a visão do software como um dos diversos elementos de um sistema (CUKIERMAN et al., 2007, FRANÇA & SILVA, 2009, JANSEN et al., 2009b, MEIRA & SILVA, 2009, SILVA & CÉSAR, 2009). Neste contexto, SCSs tais como fornecedores de software não trabalham mais como “unidades independentes” que podem entregar produtos bem delimitados, mas tornam- se dependentes de outros fornecedores, devido a infra-estruturas de software e a componentes vitais (e.g., sistemas operacionais, bibliotecas, repositórios de componentes e plataformas). Pela constante evolução tecnológica, esses fornecedores recorrem à cooperação virtual com produtores (desenvolvedores) e integradores (consumidores) de artefatos (e.g., componentes) a fim de construir alianças que estabelecem redes de influência e interoperabilidade (JANSEN et al., 2009a). Estas redes são denominadas Ecossistemas de Software ou ECOS (do inglês, Software

Ecosystems ou SECO) e consistem em um conceito que tem se tornado importante para

explicar a existência (surgimento e/ou desaparecimento) de fornecedores de software. A noção de ecossistemas tem origem na Ecologia, e foi estendida, ao longo do tempo, para contemplar ecossistemas humanos: comerciais e sociais (BOSCH, 2009). Um ecossistema humano consiste em um conjunto de atores e suas conexões e atividades, bem como as transações entre estas conexões, levando em conta fatores físicos e não-físicos. No tocante a um ecossistema comercial, os atores correspondem a negócios, produtores e consumidores, os fatores são os bens e serviços, e as transações incluem transações financeiras, além de compartilhamento de informação e de conhecimento, investigações e contatos pré e pós-vendas. Por sua vez, um ecossistema

social reúne os usuários e suas conexões, e as trocas de diversos tipos de informação

(e.g., conhecimento, soluções, idéias, referências, feedback etc.).

A partir dessas definições, BOSCH (2009) define um ECOS como um conjunto

de soluções de software que habilitam, apóiam e automatizam as atividades e transações realizadas por atores em um ecossistema social ou de negócios, e por

organizações que provêem estas soluções. Ou seja, um ECOS é um ecossistema

(especialmente um ecossistema comercial) cujos bens e serviços compreendem as soluções e os serviços de software que habilitam, dão suporte ou automatizam atividades e transações. Dessa forma, os ECOSs introduzem muitos tópicos de pesquisa nos níveis técnico e econômico uma vez que, ao deixar um mercado tradicionalmente fechado, os fornecedores de software enfrentam o desafio de tornarem abertas as interfaces de seus produtos, as suas bases de conhecimento e, em alguns casos, até

mesmo o seu produto de software. Isso se deve ao fato de que o software deixa de ser um produto meramente “código” e passa a ser tratado com um sistema, que compõe um ecossistema. Por exemplo, um cliente pode contratar desenvolvedores externos (terceiros) para realizar customizações em um sistema adquirido de um fornecedor que, por sua vez, pode tê-lo desenvolvido com base em componentes adquiridos de

produtores e/ou construídos por consumidores (integradores) de componentes.

Adicionalmente, os modelos de ECOS podem possuir três níveis de escopo que consideram as suas diferentes entidades e perspectivas, conforme apresentado na Figura 3.5 (JANSEN et al., 2009a):

• Nível do escopo do fornecedor de software (software vendor level): os objetos de estudo correspondem aos atores e aos seus relacionamentos, considerando uma

perspectiva centrada na organização (Figura 3.5.a). Os fornecedores estabelecem

os efeitos do ECOS sobre os seus portfólios de produtos e serviços, e sobre o gerenciamento de conhecimento e dos relacionamentos. Como exemplos, (i) diretrizes devem ser desenvolvidas para considerar decisões sobre “fazer ou comprar” (reutilizar), (ii) os fornecedores devem decidir como explorar ao máximo (com cautela) o portfólio completo de produtos e serviços, e (iii) os fornecedores devem determinar como utilizar o conhecimento do ECOS internamente;

• Nível do escopo da rede de produção de software (software supply network level ou SSN): os objetos de estudo representam as redes que integram um ECOS, incluindo os diferentes relacionamentos entre elas, considerando uma perspectiva interna do

ECOS (Figura 3.5.b). Os fornecedores determinam as estratégias para lidar com seus produtores e consumidores de componentes, e com seus clientes (usuários finais). Por exemplo, um fornecedor pode (i) organizar reuniões periódicas com desenvolvedores de plug-ins (produtores) para seus produtos, (ii) desenvolver portais para relacionamento com intermediários (revendedores) e clientes etc.; • Nível do escopo do ECOS (software ecosystem level): os objetos de estudo são os

ECOSs per si, bem como as relações entre eles, considerando uma perspectiva

externa do ECOS (Figura 3.5.c). Escolhas estratégicas devem ser definidas com

relação à maneira de um fornecedor se comportar em um ECOS para maximizar o valor agregado a produtos e serviços. Por exemplo, um ator pode ser um

orquestrador, que tem controle sobre o ECOS e que desenvolve estratégias para

Figura 3.5 – Níveis de escopo dos ECOSs (BOUCHARAS et al., 2009)10

Para ilustrar as perspectivas do ECOS, JANSEN et al. (2009b) discutem um exemplo (Figura 3.6). A organização fornecedora de software (ISV) é provida com componentes de um fornecedor cujo desenvolvimento é baseado em código aberto (Outsourcer) e de um outro fornecedor qualquer. A partir destes insumos, a organização entrega um produto (P.1) e um serviço (S.1) para os seus clientes (Customers). Normalmente, existe uma competição de mercado, que ocorre por meio da participação de outras organizações que entregam produtos e serviços para outros clientes, e que são providas por outros fornecedores. Dessa forma, (i) o nível do fornecedor de software envolve todos os produtos e serviços relacionados à organização fornecedora, bem como ela mesma, (ii) o nível da rede de produção de software considera todos os clientes e produtores/consumidores que têm contato direto com o fornecedor, e (iii) o

nível do ECOS reúne todas as organizações de software relacionadas.

Figura 3.6 – Perspectivas de ECOSs (JANSEN et al., 2009b)

10 Nesta figura, foi utilizada uma notação de modelagem desenvolvida por BOUCHARAS et al. (2009)

para formalizar uma abordagem de configuração padrão para redes de produção de software e de produtos relacionados. Sup1, Sup2 e Sup3 representam um conjunto de intermediários, i.e., um tipo de ator em um ECOS que engloba revendedores, distribuidores etc. que, neste caso, interagem com outro intermediário, o ISV (independent solution providers ou fornecedores de solução independente), que atende aos clientes (atores que adquirem ou fazem uso de um produto de interesse, direta ou indiretamente, como usuários finais) Cust1 e Cust2. Um produto de interesse ou product of interest (PoI) consiste em uma solução ou serviço de software na forma de um sistema principal que agrega valor ao modelo de negócio do cliente.

Por fim, diante das características apresentadas, desafios e fatores de sucesso foram apontados por BOSCH (2009) e JANSEN et al. (2009b), como: (i) caracterizar e modelar ECOSs, considerando diferentes perspectivas (e.g., no Brasil, a organização e evolução destes ecossistemas podem depender diretamente da atuação do estado, ou seja, de questões políticas); (ii) estabelecer os relacionamentos entre as redes de produção de software; (iii) gerenciar a qualidade em ECOSs; (iv) planejar portfólios e linhas de produtos em ECOSs; (v) prover métodos, técnicas e ferramentas para desenvolver arquiteturas de sistemas que atendam à extensibilidade, à portabilidade e à variabilidade; e (vi) tratar implicações gerais em Engenharia de Software, incluindo mecanismos de comunicação, agilidade na concepção e desenvolvimento de soluções e composição de produtos e serviços. Para isso, BOSCH (2009) desenvolve uma taxonomia que considera múltiplas vertentes através da divisão de um ECOS em duas dimensões (Figura 3.7). A primeira dimensão representa o nível de abstração em que o ECOS existe e se divide em três níveis: operating system, application e end-user

programming. A segunda dimensão analisa a evolução da indústria de software (e da

Computação) em termos de plataformas de computação dominantes: desktop, web e

mobile. No decorrer deste trabalho de pesquisa, alguns dos conceitos relacionadas a

ECOS são resgatados, visando delinear a abordagem proposta por esta dissertação.

Figura 3.7 – Taxonomia para ECOSs (BOSCH, 2009)

3.6 Considerações Finais

Neste capítulo, foi apresentada uma evolução histórica da Engenharia de Software tradicional, focada em questões técnicas, para a ESBV, que busca explorar o valor na indústria de software em suas diferentes perspectivas ao tratar também

questões não-técnicas como fatores econômicos e sociais, incluindo uma visão geral destes aspectos na Reutilização de Software. Assim, delineou-se o conceito de valor, que será utilizado por este trabalho de pesquisa no contexto da ESBC, e definiu-se um conjunto de termos importantes como facetas de valor, cadeia de valor e SCSs. Além disso, realizou-se uma discussão sobre a teoria inicial e sobre os elementos-chave da ESBV, o que viabilizou a exposição da agenda de pesquisa desta área, proposta por BOEHM (2003). Por fim, as novas perspectivas para a indústria de software baseada em valor foram apontadas a partir da visão de que o software é apenas um elemento de um sistema maior que, por sua vez, pertence a um ecossistema de software.

Diante da cronologia apresentada, ao se traçar um paralelo com a ESBC, percebe-se que os seus problemas (i.e., inibidores e riscos) discutidos no Capítulo 2 são reforçados pelos desafios apontados para a ESBV e para os ECOSs, uma vez que, diferentemente de outras engenharias, a Engenharia de Software apresenta um forte viés dos recursos humanos envolvidos durante a execução de seus processos e projetos. Isso demanda um olhar que analise e que transcenda a uma perspectiva única da estrutura “exata” e tradicional da concepção e da construção de sistemas (CUKIERMAN et al., 2007). Torna-se importante, assim, a discussão dessa linha de pensamento durante a formação dos futuros profissionais para a Engenharia de Software (SHAW et al., 2003).

Adicionalmente, mapeamentos entre habilidades e comportamentos de recursos humanos, e atividades técnicas devem representar, por exemplo, estratégias para maximizar a percepção de valor e alinhá-la à sua proposição internalizada pelos SCSs (SILVA & CÉSAR, 2009). Isso impacta a motivação e, conseqüentemente, a produtividade e o time-to-market, dentre outros benefícios preconizados pela Reutilização de Software, além de interferir diretamente na modelagem, estrutura e funcionamento de suas abordagens (como a ESBC) e de ECOS subjacentes que podem vir a se desenvolver (como o mercado). Assim, a partir da fundamentação teórica discutida nos Capítulos 2 e 3, o próximo capítulo apresenta a abordagem de pesquisa proposta, que visa apoiar um mercado de componentes baseado em valor.