PROCESSO DE DESENVOLVIMENTO DA SOLUÇÃO SOA Esta seção detalha o processo de desenvolvimento do produto

SOA, apresentado de forma “macro” na seção 5.4.7.

Este processo é de certa forma especial pelo fato deste modelo de processos de inovação ser voltado para SOA. Ele acontece em ciclos de análise, codificação e testes até atender aos requisitos levantados em processos anteriores.

A figura 25 ilustra o macro ciclo de desenvolvimento SOA. As etapas são apresentadas em uma sequência tradicional, iniciando na especificação da solução e terminando na certificação da solução, já pronta para a entrega, que acontece em outro processo e espaço do modelo. Conforme os objetivos ou resultados efetivos do dado projeto de inovação, o output desse processo pode ser somente entre outros elementos, um protótipo ou mesmo testes de tecnologias.

Figura 25 - Ciclo de desenvolvimento SOA

Fonte: autor (2015). Especificação -SOA(global) -Serviços(individuais) Definição da arquitetura da Solução Especificação formal dos serviços Testes Certificação Protótipo

Da mesma maneira que os processos apresentados na seção anterior, as etapas deste processo são também uma referência para orientar a OV no processo de desenvolvimento da solução SOA. Portanto, o caminho a ser seguido pode ser bastante variável de projeto para projeto (conforme seus objetivos, escopo, dimensão, nível de reuso de serviços, complexidade de integrações e testes, etc.), com idas e voltas, ciclos, paralelismos. Ainda, nem todas as etapas devem necessariamente ser seguidas, como num projeto SOA tradicional.

Na figura 26, os processos em destaque (cinza) ilustram um loop, o que significa que cada conjunto de serviços é desenvolvido gerando um protótipo. Em seguida ele é testado e o projeto avança para outro conjunto de serviços, com o processo se repetindo até que a solução inteira esteja funcionando. A certificação pode acontecer ao final ou para cada conjunto de serviços desenvolvidos, dependendo do projeto e de como a OV preferir proceder.

Como o desenvolvimento de software SOA tem inúmeras particularidades quando comparado, por exemplo, ao de software tradicional, o subprocesso de desenvolvimento de serviço de software conta com mais etapas/subprocessos.

Figura 26 - Subprocesso de Desenvolvimento de Software

Fonte: autor (2015). Descoberta de serviços Codificação de serviços Composição de serviços Integração de serviços Orquestração de serviços Especificação -SOA(global) -Serviços(individuais) Definição da arquitetura da Solução Especificação formal dos serviços Testes Certificação Protótipo

Inovações em uma única empresa geralmente seguem um processo de desenvolvimento de software já estabelecido e conhecido por todos os funcionários da empresa. Na inovação colaborativa, dependendo da forma de organização das equipes de desenvolvimento, diferentes metodologias de desenvolvimento de software podem ser utilizadas em um mesmo projeto de inovação. Isso tem relação à autonomia dada às equipes de desenvolvimento pelo gerente do projeto de inovação.

Dentre as decisões que precisam ser tomadas pela OV podem-se destacar:

 Decidir quais subprocessos do ciclo de desenvolvimento SOA serão utilizados;

 Decidir quais metodologias de desenvolvimento e gerência do projeto serão utilizadas no ciclo de desenvolvimento SOA (usando a DFM de processo de melhoria de software e Gestão de projeto), e por quais equipes;

 Selecionar ferramentas adequadas de groupware25_;

 Montar um plano de comunicação das equipes entre si e a gerência de projeto;

 Decidir como as equipes de desenvolvimento vão trabalhar; Formação das equipes:

 Equipe única de desenvolvimento (formada por membros de mais de uma empresa);

 Equipes em silos (cada empresa com uma equipe);

 Equipes mistas (equipes formadas por membros oriundos de mais de uma empresa).

Organização das tarefas:

 Equipes divididas em funções (analistas, desenvolvedores, testadores);

 Equipes divididas em serviços e funcionalidades (cada equipe desenvolve um determinado conjunto de funcionalidades e serviços).

Subprocessos do ciclo de desenvolvimento SOA

a) Especificação

Após uma análise mais orientada para o negócio e a decisão por uma abordagem baseada em SOA, necessidades do mercado alvo e clientes, é necessário especificar os requisitos gerais, os requisitos funcionais e não-funcionais, dos pontos de vista técnico (para cada

serviço de software individual e aos níveis de integração de software SOA), de negócio (ou seja, vendo o software SOA como um produto), estratégico (parcerias estratégicas específicas necessárias aos serviços) e financeiro (tributações e frameworks jurídicos). Muito disso já pode ter sido feito em processos anteriores (como por exemplo no processo de Refinamento do conceito da solução SOA), mas aqui essas informações são colocadas em um formato mais técnico para serem utilizadas como artefatos para a desenvolvimento dos serviços de software (em nível de programação).

b) Definição da arquitetura da solução

Projeto da solução global, levando em conta questões como o modelo de integração (por exemplo, através de um ESB26_{), modelo}

de pagamento (por exemplo, taxa fixa por mês), arquitetura de negócio (baseado em SaaS por exemplo), modelo de implantação (por exemplo, nuvem privada) e modelo de acesso (por exemplo, sob demanda). Ainda, indicação de eventuais plataformas comuns de desenvolvimento e comunicação / colaboração entre os membros.

c) Especificação Formal

Especificação to-be detalhada de cada serviço de software envolvido, basicamente em termos de requisitos funcionais e não- funcionais. Isso revela uma abordagem top-down, tendo em mente que o novo software SOA previsto deve lidar com diversos serviços de software diferentes para sua composição independentemente da disponibilidade dos serviços previstos. Abordagens bottom-up costumam ser usadas de forma complementar quando da necessidade de se contemplar sistemas legados e componentes de software proprietários.

d) Desenvolvimento dos serviços de software

Para o desenvolvimento de produtos SOA, a codificação dos serviços é um subprocesso complexo e compreende outros subprocessos: a) Descoberta de Serviços; b) Codificação; c) Composição; d) Orquestração; e) Integração.

26 _{ESB – Enterprise Service Bus, se refere à arquitetura de construção de software} tipicamente implementado em tecnologias encontradas na categoria de produtos de infraestrutura, fornecem uma base de serviços para arquiteturas mais complexas via um driver de evento e padrões baseados em mensagens (BUS).

1. Descoberta de serviços

Envolve a busca e seleção de serviços de acordo com a especificação definida, e a posterior vinculação (binding) dos serviços selecionados para compor o produto SOA.

Mecanismos especiais de busca são necessários. Eles devem ser capazes de passar por repositórios de serviços bem diferentes e heterogêneos, lidar com diferentes semânticas, diferentes contextos de negócios, bem como funcionalidades equivalentes que devem ser harmonizadas frente aos requisitos funcionais desejados e ao QoS (Quality of service) mínimo esperado. Como o resultado da pesquisa, os serviços existentes podem ser encontrados ou não. Se não, o serviço desejado (s) deve ser desenvolvido “do zero”, ou seja, tem de ser tratado no subprocesso de codificação (ver a seguir).

Para o caso de serviços existentes, os mecanismos de seleção especiais também são necessários. A seleção deve ser capaz de lidar com ponderação e multicritérios de tomada de decisão, e a escolha (ou recomendação) do serviço (s) mais adequado(s). Isso, por sua vez, pode necessitar de intervenção humana (no caso de uma abordagem não totalmente automatizado). Esses critérios também podem envolver fundamentos como propriedade de acesso, os custos dos serviços, confiabilidade dos serviços, reputação dos fornecedores, complexidade para interoperar, entre outros.

Os serviços podem: a) estar prontos para reutilização; b) exigir um encapsulamento para estarem pronto para ser utilizado; c) exibir funcionalidade mais “pobre” que a procurada ou precisar de reengenharia na sua interface, criando assim uma nova versão do serviço; e d) exigir uma completa re-implementação com respeito a TICs utilizadas, abordagem de integração, add-ons27 planejados para o serviço, entre outros; Aspectos que devem ser tratados no subprocesso de codificação.

Importante mencionar que estas situações podem acontecer com cada serviço único, dessa forma esta análise deve ser feita pelo membro da OV que possui o respectivo serviço. Portanto, uma análise deve ser feita posteriormente pela OV para selecionar quais serviços já existentes devem ser aproveitados, e/ou decidir sobre quais serviços (e, portanto, a partir do quais parceiros) já existentes precisam ser adaptados e quais precisam ser criados do “zero”.

27 _{Em computação o termo Add-ons refere-se a módulos de hardware ou software} que suplementam ou estendem a capacidades de ferramentas computacionais.

2. Codificação de serviços

A codificação de serviços se refere à implementação propriamente dita de cada serviço de software de acordo com as decisões e especificações prévias. A codificação de cada serviço pode ser conduzida por um membro ou vários da OV, os quais podem implementar o serviço em conjunto devido à expertise necessária (presentes nos parceiros).

A codificação de serviços também envolve discussões e decisões sobre metodologias comum (ou não) de desenvolvimento de software (s) para cada um ou todos os serviços, modelos de maturidade de software (SOA-MM), modelagem de software (por exemplo, via UML), mockups, protótipos intermediários e incrementais, modelos 3 camadas ou MVC, aspectos de controle de versão e multi-tenancy28_{, etc.}

3. Composição de serviços

Compreende ações destinadas a interligar os serviços selecionados/desenvolvidos em um “pacote” SOA coerente, aderente ao novo produto SOA idealizado. Isto pode ser feito “manualmente” ou ajudado por ambientes e linguagens de computação de alto nível, como o BPM / BPMN29_.

4. Orquestração de serviços

Envolve tarefas para “transformar” a composição de software SOA em um programa executável. Isto pode ser feito “manualmente” ou ajudado por ambientes e linguagens de computação adequados, como o BPEL30_.

5. Integração de serviços

Envolve ações relacionadas com a integração de todos os serviços desenvolvidos, com componentes locais e infraestruturas gerais (persistência de dados, comunicação, execução e hospedagem), e

28 _{Software multi-tenancy refere-se à uma arquitetura de software em que uma} única instância de um software executado em um servidor serve vários clientes diferentes sob diferentes modelos de acesso.

29 _{BPM – Business Process Modeling, Modelagem de processos de negócio –} BPMN - Business Process Modeling Notation, Notação de modelagem de processos de negócio.

30 _{BPEL - Business Process Execution Language (BPEL), abreviação de Web} Services Business Process Execution Language (WS-BPEL). Linguagem padrão OASIS[1] executável para especificar ações de processos de negócio com web services.

interoperação (especialmente quando os serviços - existentes ou novos - foram desenvolvidos em tecnologias de serviços diferentes e se comunicam em protocolos diferentes). Este subprocesso pode ser realizado “em paralelo” com os outros dependendo da abordagem de integração e método de desenvolvimento de software escolhidos.

e) Testes

Consiste na verificação rigorosa de cada serviço e o funcionamento do produto SOA como um todo - como um protótipo - usando técnicas tradicionais de engenharia de software, combinado com questões relacionadas com sistemas distribuídos, comunicação e integração entre os serviços. Requisitos funcionais e não-funcionais (principalmente QoS) são avaliadas. Dependendo da metodologia de desenvolvimento de software comum acordada ou das diversas metodologias de software adotadas pelas diferentes equipes de desenvolvimento, os clientes podem ser chamados a participar, desde os testes nos primeiros protótipos até as fases do ciclo de desenvolvimento SOA instanciado. Ciclos de refinamentos podem ser feitos passando por etapas anteriores até que as métricas de qualidade sejam atingidas.

f) Certificação

Certificação oficial e final da qualidade dos serviços e do software SOA como um todo.

O resultado final de todo o ciclo de desenvolvimento é o produto SOA, idealizada no projeto de inovação e desenvolvida de forma colaborativa.