BPM vs. SOA
Upcoming SlideShare
Loading in...5
×
 

BPM vs. SOA

on

  • 1,295 views

Uma abordagem sobre a ideia de integração de BPM com SOA.

Uma abordagem sobre a ideia de integração de BPM com SOA.

Statistics

Views

Total Views
1,295
Views on SlideShare
1,295
Embed Views
0

Actions

Likes
2
Downloads
84
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

BPM vs. SOA BPM vs. SOA Document Transcript

  • BPM X SOA (BUSINESS PROCESS MANAGEMENT X SERVICE ORIENTED ARCHITECTURE – GERENCIAMENTO DO PROCESSO DE NEGÓCIO X ARQUITETURA ORIENTADA A SERVIÇO) Grupo: GADSR (GRUPO DE ANÁLISE E DESENVOLVIMENTO DE SOFTWARE REUTILIZÁVEL) DÁVISSON HÚDSON CHAVES BERNADETE (6º - SI) JOÃO LUIZ MARQUES GUIMARÃES (5º - SI) THAÍS COSTA DE MESQUITA (5º - SI) PROJETO SEMESTRAL SUBMETIDO AO CORPO DOCENTE DA FACULDADE PROFESSOR MIGUEL ÂNGELO DA SILVA SANTOS (FeMASS) COMO PARTE DA SISTEMÁTICA DE AVALIAÇÃO POR PROJETOS (SAP). Banca Examinadora: _______________________________________________ _______________________________________________ MACAÉ, RJ – BRASIL. JUNHO DE 2010
  • RESUMO Muito tem se discutido sobre os processos nas empresas atualmente. Os processos de negócio de uma empresa hoje devem integrar pessoas, tecnologias e processos. A gerência deve estar alinhada com o pessoal de TI, para assim conseguir que todas as expectativas de um sistema atendam ao processo de negócio. Por isso é apresentado aqui o conceito de BPM (Business Process Management) com o intuito de ajudar a área de negócios principalmente na modelagem e criação de processos para que realmente se adequem à realidade do negócio. E ainda apresenta-se a Arquitetura Orientada a Serviços (SOA) para o oferecimento de serviços providos pelos processos de negócio, tornando mais claro o relacionamento entre as camadas de negócio de uma empresa. Para melhor interligação SOA deve utilizar-se ainda de Web Services e barramentos corporativos de serviço (ESB) propiciando ganho na união de BPM com SOA. Palavras-Chaves: BPM.SOA, Processos de Negócio, Serviços, Web Service.
  • LISTA DE FIGURAS Figura 1. Ciclo de Vida do Serviço (SANTOS, 2007). .............................................................12 Figura 2. Funcionamento básico de um Web Service (fonte: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices) ................13 Figura 3. Arquitetura de um Web Service (retirado de: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices ) ...............14 Figura 4. Representação das tecnologias utilizadas em um Web Service (retirado de : http://pt.wikipedia.org/wiki/Web_service)................................................................................14 Figura 5. Exemplo de funcionamento de um Web Service (CAPELARI, 2004).......................15 Figura 6 Exemplo de SOAP (FARO & FERRAZ, 2004). .........................................................17 Figura 7. Estrutura de uma mensagem SOAP (CUNHA, 2002)..............................................18 Figura 8. Exemplo de WDSL (FARO & FERRAZ, 2004) ........................................................18 Figura 9. Exemplo de funcionamento de um UDDI (in FARO & FERRAZ, 2004) .................20 Figura 10. Fluxo de dados da modelagem de negócios (RSC, 2001) ......................................21 Figura 11. Processo de Negócio (WIKIPEDIA, 2009) ............................................................23 Figura 12. Ciclo de vida BPM (N&S, 2010)............................................................................26 Figura 13. Exemplos de tipos de negócio (adaptado de SANTOS, 2007)................................28 Figura 14. Representação de subprocessos fechado e aberto (SANTOS, 2009) .....................29 Figura 15. Exemplo de Lane (SANTOS, 2009) ........................................................................31 Figura 16. Segmento de processo com artefatos (SANTOS, 2009)..........................................32 Figura 17. Alguns Tipos de BPMS (retirado de PAIM, 2007).................................................34 Figura 18. Elementos de um BPEL (NADER, 2007)................................................................36 Figura 19. Exemplo agência de viagens (NADER, 2007)........................................................37 Figura 20. Exemplo de Processo BPEL (NADER, 2007).........................................................37 Figura 21. Componentes da SOA (SANTOS, 2007).................................................................41 Figura 22. Processo de desenvolvimento de software atual (Digital Assets - 2007)...............42 Figura 23. O Paradigma Find-Bing-Execute (ROCHA, 2006)................................................43 Figura 24. Dinâmica de funcionamento SOA (Digital Assets - 2007).....................................45 Figura 25. Fases de adoção SOA (Adaptado de DIGITAL ASSETS, 2007) ............................46 Figura 26. Representação de um ESB (DIGITAL ASSETS, 2007)...........................................47 Figura 27. Representação de seleção dinâmica ESB (DIGITAL ASSETS, 2007)....................48 Figura 28. Relação BPM x SOA (ROSEN, 2006).....................................................................50
  • LISTA DE TABELAS Tabela 1 - Objetos de Fluxo – Simbologia base.......................................................................29 Tabela 2 - Objetos de Conexão – Simbologia base..................................................................30 Tabela 3 - Swimlanes – Simbologia. ........................................................................................30 Tabela 4 - Artefatos Simbologia...............................................................................................31 Tabela 5 – Comparação entre orientação a serviços e orientação a objetos..........................40
  • LISTA DE SIGLAS AD Análise de Domínio API Application Programming Interface BI Business Intelligence BP Business Process BAM Business Activity Monitoring BPD Business Process Diagram BPEL Business Process Execution Language BPM Business Process Management BPMI Business Process Management Institute BPML Business Process Management Language BPMN Business Process Modeling Notation BPMS Business Process Management System CEO Chief Executive Officer CIO Chief Information Officer EAI Enterprise Application Integration ED Engenharia de Domínio ERP Enterprise Resource Planning ESB Enterprise Service Bus HTML Hyper Text Markup Language OMG Object Management Group OOP Oriented Object Programming PDCA Plan, Do, Check and Action PMC Process Management Center RPC Remote Procedure Calls SI Sistemas de Informação SOA Service Oriented Architecture SOAP Simple Object Access Protocol TI Tecnologia da Informação UDDI Universal Discovery Description Language UML Unified Modeling Language W3C World Wide Web Consortium WS Web Service WSDL Web Service Definition Language WWW World Wide Web XML Extensible Markup Language
  • SUMÁRIO LISTA DE FIGURAS ........................................................................................................................................ III LISTA DE TABELAS.........................................................................................................................................IV LISTA DE SIGLAS.............................................................................................................................................. V 1. INTRODUÇÃO ........................................................................................................................................7 1.1. OBJETIVOS .............................................................................................................................................8 1.1.1. OBJETIVOS GERAIS..............................................................................................................................8 1.1.2. OBJETIVOS ESPECÍFICOS....................................................................................................................8 1.2. JUSTIFICATIVA......................................................................................................................................9 1.3. METODOLOGIA .....................................................................................................................................9 1.4. REFERENCIAL TEÓRICO ...................................................................................................................10 1.4.1. SERVIÇO ...............................................................................................................................................10 1.4.2. WEB SERVICES....................................................................................................................................12 1.4.2.1. XML - EXTENSIBLE MARKUP LANGUAGE.......................................................................................16 1.4.2.2. SOAP - SIMPLE OBJECT ACCESS PROTOCOL .................................................................................16 1.4.2.3. WSDL - WEB SERVICES DEFINITION LANGUAGE ..........................................................................18 1.4.2.4. UDDI - UNIVERSAL DISCOVERY DESCRIPTION INTEGRATION....................................................19 1.4.3. MODELAGEM DE NEGÓCIO..............................................................................................................20 2. BPM (BUSINESS PROCESS MANAGEMENT – GERENCIAMENTO DO PROCESSO DE NEGÓCIO)............................................................................................................................................................23 2.1. BP (BUSINESS PROCESS – PROCESSO DE NEGÓCIO)..................................................................23 2.2. BPM (BUSINESS PROCESS MANAGEMENT)..................................................................................24 2.3. BPMN (BUSINESS PROCESS MODELING NOTATION – NOTAÇÃO DE MODELAGEM DO PROCESSO DE NEGÓCIO) ................................................................................................................................27 2.4. BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM – SISTEMA DE GESTÃO DE PROCESSOS DE NEGÓCIO)..............................................................................................................................32 2.5. BPEL (BUSINESS PROCESS EXECUTION LANGUAGE – LINGUAGEM DE EXECUÇÃO DE PROCESSOS DE NEGÓCIO)..............................................................................................................................34 3. SOA (SERVICE ORIENTED ARCHITECTURE – ARQUITETURA ORIENTADA A SERVIÇOS) 38 3.1. ENTIDADES DA SOA...........................................................................................................................43 3.2. INFRAESTRUTURA E FASES DE ADOÇÃO.....................................................................................45 3.2.1. FASES DE ADOÇÃO ............................................................................................................................45 3.2.2. ESB (ENTERPRISE SERVICE BUS – BARRAMENTO CORPORATIVO DE SERVIÇOS) ............46 4. BPM X SOA ...........................................................................................................................................49 5. CONSIDERAÇÕES FINAIS..................................................................................................................51 5.1. CONCLUSÕES GERAIS .......................................................................................................................51 5.2. PROPOSTAS DE TRABALHOS FUTUROS........................................................................................51 6. REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................................52 7. GLOSSÁRIO ..........................................................................................................................................56 8. CD-ROM CONTENDO PROJETOS ANTERIORES....................................................................... 57
  • 1. INTRODUÇÃO Este trabalho aborda os contextos de Gerenciamento do Processo de Negócio (BPM) e de Arquitetura Orientada a Serviços (SOA) como formas de integração entre pessoas, processos, serviços e informações tecnológicas buscando benefícios do processo de negócio aliados a essas tecnologias. O surgimento de aplicações distribuídas, cada vez mais aumenta a necessidade de compartilhamento de informações, assim tem-se aumentado a necessidade de interoperabilidade entre sistemas. É abordado nesse projeto o conceito de SOA e de BPM, e ainda conceitos afins, com o intuito de demonstrar a aplicabilidade de sua utilização e a sua ligação com a reutilização de software, principal foco de todo esse trabalho deste os primeiros projetos. O BPM trata da questão agilidade e flexibilidade para a gestão dos processos de negócio das empresas expressos por um conjunto de serviços que são unidos, ao passo que em SOA defini-se como uma abordagem arquitetural corporativa permite a criação de serviços de negócios interoperáveis, podendo ser facilmente reutilizados e compartilhados entre aplicações e empresas. Ainda são expressos assuntos relativos à BPM e SOA como linguagens de modelagem de processos, e sistemas que apliquem essa modelagem para interação com serviços e processos de negócios, com o intuito final de integração com a Arquitetura Orientada a Serviços. Tem-se como referencial teórico as abordagens de serviço, Web Services, e modelagem de negócio, assim definiu-se conceitos chave para iniciar os assuntos principais. Em seguida são abordados os temas principais começando por BPM, depois SOA e por fim a relação entre eles. Este trabalho segue princípios abordados em projetos anteriores por isso foi disponibilizado um CD-ROM com projetos anteriores ao final para comparações quando necessárias.
  • 8 1.1. OBJETIVOS 1.1.1. Objetivos Gerais Explorar ao longo dos semestres o desenvolvimento de software voltado à reutilização, considerando as áreas de Engenharia de Software (ES) aplicáveis neste contexto, e possivelmente usar como estudo de caso um domínio a ser selecionado para aplicar as áreas de conhecimento adquiridas. Visa-se principalmente aplicar um ambiente de modelagem baseado em reutilização, estruturado através de princípios da Engenharia de Domínio (ED) e Análise de Domínio (AD), mas usufruindo-se da criação de modelos de negócio baseados nos conhecimentos do Gerenciamento do Processo de Negócio (BPM) e da Arquitetura Orientada a Serviços (SOA), além de outros conceitos que surgirem ao logo do aprendizado, e assim modelar e construir um framework para uma parte do estudo de casos proposto. Vale ressaltar que esta é uma pretensão futura e como o princípio é a modelagem de dados, o projeto pode ser implementado em qualquer linguagem de programação que atenda às necessidades de reutilização e análise. 1.1.2. Objetivos Específicos Apresentar conceitos de BPM e SOA, abordando conceitos relacionados, como ESB, WebService, BPML, BPMN, BAM, BPEL, Assets, entre outros. Descrever assuntos intrínsecos aos conceitos de BPM e SOA que fazem relação com o negócio e tecnologias envolvidas, como middlewares, Business Process, serviços entre outros.
  • 9 1.2. JUSTIFICATIVA A utilização conjunta de SOA com BPM trás ganhos para o negócio da empresa, pois enquanto o BPM provê a abstração de alto nível para definir processos de negócio entre outras capacidades importantes de monitorar e administrar esses processos, o SOA provê as capacidades para que os serviços sejam combinados para apoiar e criar um empreendimento flexível. Em resumo, um bom projeto de BPM e SOA tem a capacidade de aprender a identificar os serviços e suas granularidades, além de prover uma boa interação entre a camada de serviços e a camada de negócios. Nota-se que o BPM se utiliza de conceitos anteriormente popularizados na administração, como reengenharia e qualidade total e de tecnologias como ERP (Sistemas Integrados de gestão), além de novos conceitos para se integrar à estrutura de TI existente na empresa. 1.3. METODOLOGIA Este trabalho baseia-se principalmente em artigos técnicos e trabalhos de graduação, além de fontes baseadas em Web. É fundamentado em princípios de reutilização de software e práticas de modelagem de negócio e visão de negócios aliados à tecnologia que implemente esses conceitos. Os meios de pesquisa mais utilizados são a Internet e documentos acadêmicos impressos ou digitais, apesar de também serem utilizados alguns livros.
  • 10 1.4. REFERENCIAL TEÓRICO 1.4.1. Serviço O que é um serviço? Segundo Koch (2006) um serviço é uma porção ou componente de software construído de forma que possa ser facilmente vinculado a outros componentes. Ele ainda afirma que a idéia por trás destes serviços é a tecnologia expressa de forma que o pessoal de negócio possa entender, e não como um aplicativo enigmático. Segundo o Oasis (2006): “Um serviço é um mecanismo para habilitar o acesso a um conjunto de uma ou mais competências, onde o acesso é provido usando uma interface que descrita é consistentemente exercitada com restrições e políticas como especificados pela descrição de serviço. Um serviço é oferecido por uma entidade – o provedor de serviço – para uso pelos outros, mas os consumidores eventuais do serviço podem não saber do provedor de serviço e podem demonstrar o uso do serviço além do escopo original concebido pelo provedor.” Serviços podem ser caracterizados como funções de negócio bem definidas e auto- contidas que recebem requisições de clientes (consumidores) (FARO & FERRAZ, 2004). Serviço é um componente que atende a uma função de negócio, o qual recebe e responde requisições ocultando os detalhes de sua implementação (SANTOS, 2007). A definição do Gartner Group diz que um serviço é um pedaço de software que oferece uma interface bem definida podendo ser acessada por plataformas independentes e outros pedaços de software. Este acesso pode ser conseguido através de um processo Runtime Discovery, isto é, algo como uma descoberta em tempo real onde o usuário do serviço não necessita ter um conhecimento prévio do serviço ou sua definição da interface antes de requisitar o acesso ao serviço. Um serviço é a lógica do negócio (servidor), capaz de ser acessado por outro processo (cliente) (PIJANOWSKI, 2007). Há três conceitos fundamentais importantes para o entendimento do que está envolvido na interação com serviços: a visibilidade entre provedores de serviços e consumidores, e a interação entre eles, e os efeitos no mundo real da interação com um serviço (OASIS, 2006).
  • 11 Um serviço deve representar o processo de negócio da empresa decomposto, ou seja, um serviço representa uma parte de um todo do negócio da empresa. Eles podem ser reutilizados, modificados e aplicados em diferentes áreas de uma empresa, dentro ou fora dela na verdade, sem a necessidade de ajuste ou troca de tecnologia. Apesar de um serviço ser projetado para ser autônomo, nenhum serviço está isolado, eles devem interagir uns com os outros provendo serviços entre si. Um serviço deve possuir granularidade grossa, ou seja, o nível de detalhes deve ser o menor possível para que o reuso seja favorecido em uma arquitetura SOA (Arquitetura Orientada a Serviço) por exemplo. Para se descobrir os processos candidatos a serviços são utilizadas algumas metodologias: Decomposição de processos (Análise Top Down), decomposição de domínio, análise Bottom-Up, Traccking (rastreamento) de eventos de negócio, gerenciamento do portifólio e meet in the middle (SANTOS, 2007). A análise Top Down (ou decomposição de serviços) divide um processo em partes ou tarefas, tornando mais fácil a identificação de candidatos a serviços. Em uma análise Bottom-Up ao se verificar as interfaces do Backend (sistemas legados) é possível identificar os serviços que podem encapsular essas interfaces. O rastreamento de eventos de negócio por sua vez considera que os eventos são o que estimulam os processos de negócio, por isso monitora os eventos que disparam funcionalidade de negócio. Gerenciamento de portfólio ajuda na modelagem e na identificação dos candidatos a serviços quando existe um portfólio de serviços. Meet in the middle é uma mistura entre Análise Top-Down e Bottom-Up, onde primeiro a análise Top-Down e depois a Bottom-Up são utilizadas para sustentar a integração entre a TI e o negócio que é o objetivo primário da SOA (SANTOS, 2007). A figura 1 apresenta o ciclo de vida de um serviço, nela é possível observar que no status construção é feito a identificação e descoberta de um serviço, a modelagem e implementação e a distribuição de um serviço como entradas. No status de ativo existe um catálogo de serviços e há o gerenciamento da entrega e suporte, deve-se gerenciar através do ciclo de operação, monitoração e avaliação, e usar do PDCA para melhoria contínua desse gerenciamento, lembrando que todas as etapas devem ter qualidade do serviço seguindo regras definidas. Ainda nesse status estão envolvidos as políticas e procedimentos e o portfólio de serviço. Quando um serviço se torna obsoleto é feito a sua retirada, e quando fica inativo é feito o seu arquivamento, esses status caracterizam a saída de um serviço.
  • 12 Figura 1. Ciclo de Vida do Serviço (SANTOS, 2007). 1.4.2. Web Services Web Services servem para integrar componentes ou serviços de software. Eles são um conjunto de mecanismos-padrão de comunicação criados sobre a World Wide Web, como uma metodologia para conectar e comunicar, principalmente entre sistemas distribuídos. Em um Web Service a comunicação entre os serviços é padronizada, o que torna possível a independência de plataforma e de linguagem de programação (RECKZIEGEL, 2006). De acordo com Menéndez (2002) o Web Service é uma aplicação que aceita solicitações de outros sistemas através da Internet, possuindo interfaces acessíveis de rede para a funcionalidade da aplicação. Um serviço promovido por um Web Service facilita o processamento distribuído em sistemas heterogêneos. Estes serviços são baseados em um conjunto de padrões da Internet definidos pelo W3C. O W3C é um consórcio, destinado a desenvolver tecnologias
  • 13 interoperantes, de domínio público, para a World Wide Web (RECKZIEGEL, 2006). O W3C (World Wide Web Consortium) serve como um padrão de desenvolvimento web, de forma que um sistema desenvolvido funcione em navegadores e tecnologias diferentes. Os Web Services são utilizados para disponibilizar serviços interativos na Web, podendo ser acessados por outras aplicações usando, por exemplo, o protocolo SOAP (Simple Object Access Protocol – Protocolo de Acesso a Objeto Simples), que é explicado mais a frente. O intuito principal é facilitar a comunicação de um EAI (Enterprise Application Integration), isto é, a integração das aplicações de uma empresa, assim há uma interoperabilidade entre a informação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio eletrônico com os seus clientes e seus fornecedores (WIKIPEDIA, 2009). Um exemplo que demonstra melhor o conceito de um Web Service seria um sistema desenvolvido em Java e rodando em um servidor Linux, podendo acessar, com transparência, um serviço feito em .Net rodando em um servidor Microsoft. A figura 2 apresenta um exemplo de um Web Service, onde é possível observar o que foi dito no exemplo anterior. Figura 2. Funcionamento básico de um Web Service (fonte: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices) É importante observar que o reuso dos componentes é proveniente de sistemas integrados, podendo cada um deles representar um serviço distinto, e ainda sendo capaz de participar de múltiplos sistemas provendo maiores benefícios imediatos e aumento da agilidade do negócio (RECKZIEGEL, 2006). Segundo Kreger (2001) a arquitetura dos Web Services é baseada na interação entre Provedor de Serviços, Consumidor de Serviços e Registro dos Serviços, envolvendo as operações de publicação, pesquisa e ligação. O provedor de serviços deve definir a descrição do serviço para o Web Service e publicar esta para o consumidor de serviços no registro de serviços, então o consumidor de
  • 14 serviços utiliza a descrição do serviço publicada para se ligar ao provedor de serviços e invocar ou interagir com a implementação do Web Service, conforme observado na figura 3. Figura 3. Arquitetura de um Web Service (retirado de: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices ) Toda e qualquer comunicação entre sistemas é dinâmica e principalmente segura, e sem intervenção humana. Os Web Services permitem enviar e receber dados em formato XML (Extensible Markup Language). Uma aplicação pode ter sua própria linguagem, pois será traduzida para o formato XML tornando possível a comunicação entre aplicações diferentes. Os Web Services deixam os recursos disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos. Os Web Services se utilizam de quatro camadas para fazer a comunicação entre suas aplicações, que empacotam a requisição e a resposta entre o servidor e o cliente. As quatro camadas básicas são: XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Definition Language) e UDDI (Universal Discovery Description Integration). As definições são apresentadas nas subseções. A seguir é apresentada a relação entre esses padrões. Figura 4. Representação das tecnologias utilizadas em um Web Service (retirado de : http://pt.wikipedia.org/wiki/Web_service)
  • 15 A figura 4 apresenta a representação de como as tecnologias se relacionam em um WS, que pode ser explicado da seguinte forma: A estruturação dos dados nas mensagens recebidas e enviadas é feito através de XML, enquanto que as chamadas às operações são codificadas no protocolo SOAP, incluindo parâmetros de entrada/saída. O serviços, como operações e mensagens, por exemplo, são descritos utilizando linguagem WSDL e o processo de publicação fica por conta do protocolo UDDI. Exemplo prático de funcionamento de um WS pode ser visto na figura 5, retirado de Reckziegel (2006). Figura 5. Exemplo de funcionamento de um Web Service (CAPELARI, 2004) A figura 5 é um exemplo de portal Internet de turismo expressado por Capelari (2004), onde a entrada é um destino turístico. Com a informação, o sistema procura serviços oferecidos para determinada localidade destino, com passagens, hospedagens, aluguel de veículos, entre outros, assim comparando preços, horários, descrevendo os serviços oferecidos de modo geral. Contudo, é necessário que as empresas relacionadas criem seus WSs que devem ser acessados pelo portal, podendo as consultas ser feitas de forma concorrente. Essa implementação gera um controle descentralizado, assim uma companhia área, por exemplo, pode alterar seus horários de embarque, sem a necessidade de informar a um sistema de controle central sobre a alteração. Um WS só é realmente útil se os clientes puderem descobrir que serviços estão disponíveis, onde encontrá-los e como eles podem ser chamados (TURTSCHI et. al., 2002).
  • 16 1.4.2.1. XML - Extensible Markup Language Uma explicação bastante simplificada do que é XML é que ele consiste em texto estruturado. Sua simplicidade é o termo relevante, e o texto é suportado em todas as plataformas. A representação de dados em formato texto facilita a leitura por outras plataformas, podendo ler os dados sem a necessidade de conversões especializadas de um formato para outro (TURTSCHI et. al., 2002). Os dados são descritos por elementos e atributos. Os elementos possuem tags, assim como no HTML (Hyper Text Markup Language). Traduzindo fielmente o significado de XML afirma-se que ele é uma linguagem de marcação de dados com formato para descrever dados estruturados. O XML permite a definição de um número infinito de tags. Enquanto no HTML, se as tags podem ser usadas para definir a formatação de caracteres e parágrafos, o XML provê um sistema para criar tags para dados estruturados (GTA/UFRJ). Ou seja, no XML há a possibilidade de extensão, podendo-se criar uma tag de acordo com a necessidade. 1.4.2.2. SOAP - Simple Object Access Protocol O SOAP é um padrão de Internet aberto baseado em XML, que permite que dois sistemas troquem dados. O SOAP é o padrão utilizado pelos WS para trocar dados pela Internet, sendo considerado como um protocolo de interligação. Esse padrão é independente de plataforma podendo ser implementado em mais de 60 linguagens e 20 plataformas (FARO & FERRAZ, 2004). As mensagens são modeladas como um envelope SOAP. A especificação do SOAP define um framework ao qual se constrói mensagens que trafegam através de diversos protocolos, ele é especificado de forma a ser independente de qualquer implementação específica, sendo, portanto uma plataforma descentralizada e distribuída.
  • 17 Figura 6 Exemplo de SOAP (FARO & FERRAZ, 2004). A figura 6 apresenta uma forma de funcionamento do SOAP onde uma aplicação cliente requisita uma mensagem SOAP para um servidor Web com um SOAP request, este se comunica com o servidor SOAP que pode fazer uma requisição RPC (Remote Procedure Calls – Chamadas Remotas de Procedimento) caso necessário, o servidor SOAP se comunica com o servidor Web de forma paralela, assim o Servidor SOAP envia uma mensagem SOAP através de um SOAP response para a aplicação cliente com o que ele requisitou. Segundo Cunha (2002), uma mensagem SOAP consiste basicamente dos elementos envelope, header e body, conforme apresentado na figura 7. O envelope é o elemento raiz do documento XML, contendo as declarações de nomes e atributos adicionais; o header é um cabeçalho opcional e quando utilizado deve ser o primeiro elemento do envelope; um body é obrigatório e contém a informação a ser transportada para o destino, podendo conter um elemento opcional chamado fault para carregar mensagens de status e erros retornados ao se processar a mensagem.
  • 18 Figura 7. Estrutura de uma mensagem SOAP (CUNHA, 2002) 1.4.2.3. WSDL - Web Services Definition Language Em um WS o papel de uma biblioteca de tipo é desempenhado pela descrição WSDL de um Web Service. O WSDL é uma linguagem XML que não necessita ser compilada, trazendo algumas vantagens, porém é um padrão complexo que ainda sofre mudanças (TURTSCHI et. al., 2002). É usado para descobrir a localização dos serviços, suas chamadas de funções e como acessá-los. Ele define interfaces (operações, tipos de dados, etc), protocolos de acesso (SOAP sobre HTTP) e localização dos serviços (URL do Web Service) (FARO & FERRAZ, 2004). Figura 8. Exemplo de WDSL (FARO & FERRAZ, 2004)
  • 19 O que é apresentado na figura 8 é explicado basicamente da seguinte forma: com um registro de um Web Service um cliente faz uma busca através de SOAP do serviço UDDI publicado, o parceiro de negócio invoca o WS através da tecnologia disponível no provedor WS (exemplo Servlets JSPs) e recupera a definição do documento WSDL, a partir daí um serviço chamado JAXR registra o WS durante o desenvolvimento. Quando o cliente envia uma mensagem para um determinado WS, ele obtém a descrição do serviço (utilizando a localização do documento WSDL), assim em seguida constrói a mensagem com os tipos de dados corretos de acordo com a definição encontrada. Essa mensagem é enviada para o endereço onde o serviço está localizado, sendo processado. O WS por sua vez, recebe a mensagem e valida-a de acordo com as informações contidas no WSDL. O serviço remoto trata a mensagem e processá-a, após isso mostra a resposta ao cliente (CUNHA, 2002). 1.4.2.4. UDDI - Universal Discovery Description Integration O UDDI é uma maneira mais completa de localizar WS, ele é, em si mesmo, um Web Service e permite que empresas e indivíduos publiquem informações sobre si e sobre os WS que estão oferecendo, sendo considerado um diretório de domínio global, totalmente aberto, de simples uso e completo (TURTSCHI et. al., 2002). Faz especificação com definição dos mecanismos para publicação e busca de WS em repositórios de serviços. Um UDDI é baseado em XML e SOAP, no qual em XML utiliza as estruturas de dados que definem os WS em um registro UDDI, enquanto em relação ao SOAP, é utilizada a API para comunicação com um registro UDDI (FARO & FERRAZ, 2004). O UDDI ainda não foi submetido ao W3C. A organização dos registros UDDI (UDDI Registry) acontece da seguinte forma: páginas brancas para informações de contato (nome, endereço, URL, etc.); páginas amarelas para categorização dos serviços baseado em taxonomias padrões, e registra informações de códigos de indústrias, produtos, etc.; páginas verdes apresentam informações técnicas sobre o serviço publicado, como especificações do WS e localização (FARO & FERRAZ, 2004).
  • 20 Figura 9. Exemplo de funcionamento de um UDDI (in FARO & FERRAZ, 2004) A figura 9 apresenta o funcionamento do UDDI onde o um provedor WS publica informações de serviços Web no registro UDDI usando Web Service Description Language (WSDL), assim é verificado o registro UDDI (Público ou Privado) de acordo com a cor do registro (leia-se página), o solicitante do serviço Web procura o registro UDDI e encontra uma descrição do serviço desejado, então o registro UDDI envia a descrição do serviço Web solicitado. Assim o solicitante do serviço Web se conecta ao provedor WS através do protocolo SOAP para obter o Web Service, logo após o serviço Web é entregue via SOAP à aplicação/cliente solicitante. 1.4.3. Modelagem de Negócio A modelagem de negócios se baseia em entender a estrutura e a dinâmica da organização na qual um sistema deve ser implantado, assim como os problemas atuais da organização-alvo, e identificar as possibilidades de melhoria. É importante que seja assegurado que os clientes, usuários e desenvolvedores tenham um entendimento comum da organização-alvo e derivar os requisitos de sistema necessários para sustentá-la (RSC, 2001).
  • 21 Para que essas metas expressadas sejam atingidas, a modelagem de negócios descreve como desenvolver uma visão da nova organização-alvo, definindo-se assim os processos, papéis e responsabilidades dessa organização em modelos de casos de uso de negócios e modelos de objetos de negócios. A modelagem de negócio explicita a estrutura e dinâmica da organização gerando assim uma visão comum da organização por clientes, usuários e desenvolvedores (TESSARI, 2003). Para Stutz (2006) a modelagem de negócio pode agregar valor ao processo modelado, e assim ao software, na medida em que há a possibilidade de que sejam identificadas as atividades, oportunidades de melhoria dos processos e relações de negócios. Figura 10. Fluxo de dados da modelagem de negócios (RSC, 2001) Dependendo da finalidade no esforço da modelagem, vários caminhos podem ser percorridos, assim como a etapa disposta no ciclo de vida de desenvolvimento. A seguir tem- se uma explicação de cada fase do fluxo apresentado na figura 10 com base nos conceitos da Rational Software Corporation (2001). No fluxo avaliar status do negócio é avaliado o status da organização na qual o sistema resultante deve ser implantado. Nesse momento é entendido como o projeto deve ser classificado e identificado o que é mais adequado para a modelagem de negócios. O principal
  • 22 objetivo de reunir informações é promover entendimento claro dos problemas e potenciais do negócio e sua forma de trabalho. Deve-se ter em mente que a continuidade do trabalho na iteração é tomada nesse momento, assim como a definição de como será o trabalho nas próximas iterações com os artefatos produzidos. É preciso entender as metas e os objetivos e a visão do negócio da organização-alvo que podem ser aprovados pelos envolvidos e responsáveis. No fluxo identificar processos de negócio, as fronteiras da organização são definidas, além de ser feita uma análise determinando-se quais processos serão descritos em mais detalhes, tornando-os prioritários de acordo com a necessidade. Em descrever o negócio atual, é necessidade entender os processos e a estrutura da organização. Nesse fluxo são refinadas as metas do esforço para modelagem de negócio. Detalha-se aqui o necessário para priorizar as partes que devem ser enfatizadas no restante do projeto, além de descrever os detalhes da organização. No fluxo refinar definições do processo de trabalho cada caso de uso de negócios é detalhado e revisado, não somente por membros da equipe, mas por representantes envolvidos também. Aqui é verificado se o caso de uso do negócio reflete corretamente a maneira como os negócios são feitos. Cabe ao fluxo projetar realizações do processo de negócio descrever como as realizações de casos de uso de negócios serão executadas pelos envolvidos no processo. Além disso, também é de sua responsabilidade identificar os papéis, produtos liberados e eventos de negócio. No ponto refinar papéis e responsabilidades uma entidade de negócios é definida e detalhada, como também as responsabilidades de um colaborador de negócio. Neste fluxo é relevante verificar formalmente se os resultados da modelagem de objetos de negócio são compatíveis com a visão que os envolvidos têm do negócio. O fluxo explorar a automação do processo explora as partes dos processos de negócios que deverão ser automatizadas, sendo que é necessário entender como os sistemas existentes (sistemas legados) se encaixam na organização, assim os requisitos de sistema devem ser derivados nesse fluxo de dados. Em desenvolver um modelo de domínio desenvolve-se um modelo de objeto de negócio não muito complexo, pois se preocupa apenas com os produtos liberados e eventos para o domínio do negócio, constituindo-se o modelo de domínio.
  • 23 2. BPM (BUSINESS PROCESS MANAGEMENT – GERENCIAMENTO DO PROCESSO DE NEGÓCIO) 2.1. BP (BUSINESS PROCESS – PROCESSO DE NEGÓCIO) Um processo consiste de atividades inter-relacionadas para se chegar a um determinado resultado esperado, consistindo de etapas bem definidas. Os processos ocorrem em diferentes níveis de uma organização desde operacionais até estratégicos ou gerenciais. Compreender como os processos de um negócio ocorrem nas organizações e buscar potencializar os benefícios de sua adoção colabora para elevação do nível da organização (NETO & JUNIOR, 2008). Processos de negócios resultam em produtos ou serviços entregues pelas empresas, mostrando-se importantes por integrarem diferentes atividades em áreas funcionais distintas e englobam funcionários, clientes, parceiros e todos os envolvidos com objetivo comum (NETO & JUNIOR, 2008). O nível de complexidade de um processo define a sua dinamicidade, pois facilitam alterações, adaptações e composição mesmo em longo prazo, ao passo que processos mais simples possuem características estáticas dificultando alterações. A palavra processo leva a pensar em “como fazer”, entretanto não se pode esquecer do “quê” deve ser realizado (MENDES, 2010). Mendes afirma que o ideal é entender a capacidade do negócio como o que precede um processo de negócio. Um BP deve espalhar a visão para toda empresa dada pela modelagem de negócio. A capacidade de aprendizado da organização também é um dos elementos a ser considerado por um BP. Figura 11. Processo de Negócio (WIKIPEDIA, 2009)
  • 24 A figura 11 indica que os BPs podem ser entendidos como atividades desenvolvidas a partir de um objetivo pré-estabelecido tornando-se um resultado específico, mas que também envolve pessoas, equipamentos e informação no decorrer, os quais devem estar alinhados. Também são verificados os procedimentos, prioridades e tarefas específicas até alcançar o resultado. Processos de negócio devem ser estruturados com a cooperação, integração e alinhamento entre todas as áreas da organização para que obtenha sucesso. Nota-se ainda que os processos estão cada vez mais automatizados, utilizando-se para tanto softwares, passando a ter uma natureza tecnológica e de negócios. As regras de negócio estão embutidas nas tecnologias portanto (NETO & JUNIOR, 2008). É válido ressaltar que processos operacionais referenciam processos de rotina, ou seja, processos repetitivos e processos estratégicos são os desempenhados pela alta direção. 2.2. BPM (BUSINESS PROCESS MANAGEMENT) Segundo a IT7 (2010), BPM é um conceito que une gestão de negócio e tecnologia da informação buscando a melhoria dos processos de negócio das organizações, e utilizando para isso métodos, técnicas e ferramentas no intuito de modelar, publicar, controlar e analisar processos operacionais. Deve envolver pessoas, aplicações, documentos e outros fatores relacionados. BPM deve prover melhoria, gerenciamento e controle dos processos essenciais da empresa. Segundo Moura (2010), BPM depende de nove passos: Identificar os principais stakeholders; Identificar os requisitos de cada stakeholder; Definir importância e prioridade dos stakeholders para atender requisitos; Identificar os gaps de desempenho (externos), verificando como a empresa está se saindo na prestação de serviços e as prioridades para atendimento; Definir prioridades para melhorias; Ligar seleção AIBD (Alta Importância + Baixo Desempenho) aos BPs internos; Definir prioridades para melhoria dos BPs; Definição de métricas e metas; ciclo PDCA (Planejar, Fazer, Checar e Agir) para tratar 80% das causas dos problemas. BPM faz com que os processos modelados sejam facilmente transformados em softwares além de possibilitar a integração dos aplicativos, e ainda elimina o processamento redundante, pois com a integração dos processos consegue-se uma melhor visão do negócio. Ele busca de forma geral a gestão da performance de seu escopo.
  • 25 De acordo com a Procnet (2010) os principais objetivos do BPM são: obter a automação do fluxo de trabalho, integrando seus passos aos aplicativos existentes; converter processos manuais em processos eficientes informatizados; incorporar características de controle para assegurar a integridade do fluxo de trabalho; prover feedback em tempo real através de monitoramento; buscar melhoramentos contínuos, medir o tempo e custo dos processos; orquestrar os BPs, melhorando a cooperação inter-departamental e inter- empresarial; entender as fronteiras da organização a partir da integração de seus processos aos processos de outras entidades externas (clientes, fornecedores, etc). A WorkingMinds (2008) ainda acrescenta: BPM melhora a visão dos processos de negócio; traz maior agilidade, flexibilidade de tempo de resposta nos serviços de TI; alavanca o aproveitamento de sistemas legados; padroniza a execução de processos e integração com os clientes, parceiros e fornecedores; reduz os custos de manutenção; otimiza os processos. BPM se apóia no profundo conhecimento do negócio para garantir o sucesso da automação das atividades (GRIMAS, 2008). BPM acompanha sistematicamente como os recursos de uma organização são alocados e convertidos em ações operacionais, definindo-se prioridades e metas organizacionais. Basicamente, BPM promove o alinhamento dos processos de negócio com a estratégia, os objetivos e a cadeia de valor das organizações. Segundo a Next Generation Center – NGC - (2010) a meta do BPM é padronizar processos corporativos e ganhar pontos em produtividade e eficiência, assim as ferramentas de BPM servem como aplicações com o propósito de medir, analisar e otimizar a gestão de negócio e os processos da empresa. Para que o BPM seja realmente efetivo as organizações devem deixar de focar unicamente em dados e informações, e passar a gerir a melhoria de seus processos. O ponto básico do BPM é a automação de processos na empresa, ou melhor, por toda a empresa, mas com a consciência de que não existe uma combinação única e exata de processos e metodologias. Estando os processos modelados pode-se controlar sua execução, analisar seu desempenho e identificar pontos de melhoria, proporcionando-se assim uma grande flexibilidade e agilidade na otimização dos processos (WORKINGMINDS, 2008). BPM deve atuar de forma que se repense as tarefas do dia-a-dia, e que se trabalhe lado-a-lado com o pessoal de informática ao menos na fase de implementação, com o intuito de automatizar fluxos de forma rápida e simples (NGC, 2010). Ainda de acordo com a NGC (2010) as ferramentas de BPM utilizam a linguagem dos executivos de negócios e as peças fundamentais são as pessoas, o que faz com que a visão vertical e departamental seja
  • 26 substituída pela visão horizontal, automatizando, integrando e otimizando processos do negócio com clientes, parceiros e colaboradores. O ideal é formar uma equipe de executivos aliada a profissionais de tecnologia, como um tipo de centro de gerenciamento de processos (PMC – Process Management Center), onde todos se voltassem para o desenho e redesenho de processos, assim cuidando dos riscos, indicadores e métricas de desempenho (NGC, 2010). Soluções BPM disponibilizam acesso simplificado a consultas, análises e relatórios corporativos, pois integra bases de dados diferentes unificando as informações em uma interface comum. Nas soluções BPM deve-se usar um diretório de usuários para definir o perfil e nível de acesso (autoridade) para cada usuário envolvido. Para se implementar BPM, segundo a Procnet (2010) o primeiro passo é desenhar a situação atual, sendo necessário a integração das áreas de negócio com a TI, aqui deve-se priorizar os processos que serão implementados a partir de visões específicas, logo após deve- se fazer um medição das tarefas do processo desenhado considerando tempo, custo, probabilidades e freqüência dos fluxos. O terceiro passo é a análise e simulação, que consiste em analisar os modelos gerados com a medição, assim avaliando-se a performance e identificando os gargalos e meios de otimizar os processos. A seguir tem-se o processo de melhoramento onde o processo é redesenhado, eliminando-se processos desnecessários e simplificando a automação de tarefas, onde é feito uma comparação entre o modelo atual e os modelos do novo desenho. Em quinto tem-se a automação com uma solução BPM escolhida, aqui deve estar bem identificados os pontos de contato do processo com os sistemas existentes ou externos e especificados os serviços complementares conforme necessidade. O ideal é inter-relacionar BPM com SOA nesse ponto. A figura 12 apresenta o ciclo de vida do BPM expressado pela N&S (2010), onde se percebe as fases de operação, controle e construção de acordo com as regras acima. Figura 12. Ciclo de vida BPM (N&S, 2010).
  • 27 2.3. BPMN (BUSINESS PROCESS MODELING NOTATION – NOTAÇÃO DE MODELAGEM DO PROCESSO DE NEGÓCIO) Para Bitencourt (2007), BPMN está se consolidando como o mais importante padrão de notação gráfica aberta para desenhar e modelar processos de negócios e, esta notação deve permitir diminuir as distâncias entre o mapeamento dos processos nas áreas de negócio e a adaptação técnica destes processos na TI, se tornando assim um padrão comum de entendimento dos requisitos alinhados com os objetivos do negócio. O BPMN é um padrão que foi criado pelo BPMI (Business Process Management Initiative), uma organização independente que propicia o desenvolvimento de especificações abertas para o gerenciamento de processos empresariais. A BPMI se uniu a OMG (Object Management Group) em 2005, ficando conhecido como Business Modeling & Integration Domain Task Force (BMI DTF), e além do BPMN para modelar processos de negócios, criou ainda o BPML (Business Process Modeling Language) como linguagem padrão de desenvolvimento e o BPQL (Business Process Query Language) como interface de manutenção para a distribuição e execução de processos e-business, com o intuito de facilitar o BPM (GRIMAS, 2008). Para se expressar os processos de negócio o BPMN fornece uma notação em um diagrama de processo de negócio (BPD – Business Process Diagram), que deve ser entendido por todos os utilizadores, analistas e envolvidos, utilizando-se para tal, uma notação comum. Os processos podem ser formados por sub-processos dentro do processo de negócio. Com base em Santos (2009) afirma-se que com o BPMN pode-se modelar os tipos de processo interno, abstrato e de colaboração. Processo interno é o tipo mais comum, contendo uma série de atividades realizadas dentro da empresa. Os processos abstratos algumas vezes incluem processos realizados fora da empresa sem que a empresa tenha gerencia sobre as atividades realizadas, assim deve-se usar um modelo abstrato para representar uma organização independente, ou seja, não se pode modelar por não conhecer o processo, ou não importa modelar, por isso representa-se em branco. Processos de colaboração descrevem processos B2B (Business to Business) e as interações entre duas ou mais entidades de negócio, apresentando diagramas de ponto de vista global. A figura 13 representa os tipos de processo pela notação.
  • 28 Figura 13. Exemplos de tipos de negócio (adaptado de SANTOS, 2007). Para Bitencourt (2007) é possível capturar e modelar os BPs capturando e documentando modelos atuais (AS-IS) em diagramas de fácil entendimento, projetar e descrever modelos ideais (TO-BE), estender detalhes técnicos, monitorar e mensurar o negócio com indicadores de desempenho baseados nas atividades dos fluxos de processos automatizados. A especificação BPMN é dividida em três áreas: Core Elements, Full Elements e Atributes. Onde os core elements representam um conjunto de elementos comuns e simplificados, capazes de modelar a maior parte dos processos do negócio. Os full elements é formado pelo conjunto de todos os elementos da especificação, incluindo os core elements, modelando qualquer processo do negócio. Os atributes são o conjunto de propriedades e informações de cada elemento (SANTOS, 2009). Segundo Grimas (2008) e Santos (2009) existe quatro categorias básicas de elementos a serem simbolizados em BPMN, que são objetos de fluxo, objetos de conexão, swimlanes e artefatos. A tabela 1 apresenta a simbologia para os objetos de fluxo.
  • 29 Tabela 1 - Objetos de Fluxo – Simbologia base. Objeto Descrição Figura Evento É algo que acontece durante um processo do negócio. Estes eventos afetam o fluxo do processo e têm geralmente uma causa (trigger) ou um impacto (result). Há três tipos de eventos, baseados sobre quando afetam o fluxo: Start, Intermediate, e End. Atividade É um termo genérico para um trabalho executado. Os tipos de atividades são: Tarefas e sub-processos. O sub-processo é distinguido por uma pequena cruz no centro inferior da figura. Gateway É usado para controlar a divergência e a convergência da seqüência de um fluxo. Assim, determinará decisões tradicionais, como juntar ou dividir trajetos. Fonte: (SANTOS, 2009) Uma tarefa é a menor unidade de um processo e geralmente não pode ser subdividida. Um sub-processo em um BPD é uma atividade composta por uma série de outras atividades que formam um novo fluxo, e que segundo Santos (2009) pode ser dividida em aberta ou fechada. Um subprocesso aberto é representado com um novo subprocesso interno enquanto um subprocesso fechado pode estar ou não dentro do mesmo pool. Veja a figura 14: Figura 14. Representação de subprocessos fechado e aberto (SANTOS, 2009)
  • 30 A seguir a tabela que demonstra a simbologia dos objetos de conexão. Tabela 2 - Objetos de Conexão – Simbologia base. Objeto Descrição Figura Fluxo de seqüência É usado para mostrar a ordem (seqüência) com que as atividades serão executadas em um processo. Fluxo de mensagem É usado mostrar o fluxo das mensagens entre dois participantes diferentes que os emitem e recebem. Associação É usada para associar dados, texto, e outros artefatos com os objetos de fluxo. As associações são usadas para mostrar as entradas e as saídas das atividades. Fonte: (GRIMAS, 2008) Swimlanes funcionam como um mecanismo de organização das atividades em categorias visuais separadas. Vide tabela a seguir. Tabela 3 - Swimlanes – Simbologia. Objeto Descrição Figura Pool Um pool representa um participante em um processo. Ele atua como um container gráfico para dividir um conjunto de atividades de outros pools, geralmente no contexto de situações de B2B. Lane Uma lane é uma subdivisão dentro de um pool usado para organizar e categorizar as atividades. Fonte: (GRIMAS, 2008)
  • 31 Um pool é utilizado quando o diagrama envolve duas entidades de negócio ou participantes que estão separados fisicamente no diagrama, especificando o que faz o que colocando os eventos e os processos em áreas protegidas (pool) (SANTOS, 2009). Lane separa as atividades associadas para uma função ou papel específico, representa normalmente um departamento dentro de um pool. Figura 15. Exemplo de Lane (SANTOS, 2009) Os artefatos representam as entradas e saídas das atividades de um processo. Tabela 4 - Artefatos Simbologia. Objeto Descrição Figura Objetos de dados O objeto de dado é um mecanismo para mostrar como os dados são requeridos ou produzidos por atividades. São conectados às atividades com as associações. Grupo Um grupo é representado por um retângulo e pode ser usado para finalidades de documentação ou de análise.
  • 32 Anotações As anotações são mecanismos para fornecer informações adicionais para o leitor de um diagrama BPMN. Fonte: (GRIMAS, 2008) Exemplo de uso de artefato. Figura 16. Segmento de processo com artefatos (SANTOS, 2009) Essas foram as simbologias base, porém existem outras mais específicas não citadas nesse projeto. 2.4. BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM – SISTEMA DE GESTÃO DE PROCESSOS DE NEGÓCIO) Um BPMS é um sistema que automatiza a gestão de processos de negócio com execução, controle e monitoração. Deve incluir o mapeamento de BPs, desenho dos fluxos e formulários, regras de negócio, integradores, monitoração em tempo real das atividades e alertas. Isso permitirá a execução efetiva dos processos exclusivamente como modelados.
  • 33 BPMS nada mais é do que a representação dada para softwares que colaboram com a gestão por processos aumentando a capacidade dos gestores e envolvidos na troca de idéias e conhecimento. Esses sistemas devem propiciar um ambiente de integração de sistemas definindo o fluxo de integração, regras, eventos e especificações inerentes ao BPM, além de ser totalmente flexível. Business Process Management System ou Business Process Management Suite é uma categoria de software empresarial que capacita as empresas a modelar, automatizar e gerenciar uma série de atividades inter-relacionadas, tanto departamentais como toda a empresa, e ainda se estendem à participação de clientes, fornecedores e outros envolvidos (AURAPORTAL, 2010). Os BPMS possibilitam que as organizações modelem, disponibilizem e gerenciem processos críticos, podendo ser distribuídos entre múltiplos aplicativos da empresa, departamentos e parceiros de negócio (SMITH & FINGAR, 2003). Esses sistemas devem complementar as estruturas tradicionais de SI (Sistemas de Informação), buscando a satisfação dos envolvidos no processo. Para Paim et. al. (2007) incorporar e implantar BPMS requer metodologia para prover os conceitos, técnicas e ferramentas adequadas para suportar as várias tarefas de modelagem, análise, desenho, simulação, avaliação e redesenho das aplicações, e ainda afirma que ele contribui para a gestão organizacional facilitando a comunicação e integração das pessoas em todos os setores da organização. Existem muitos tipos de sistemas BPMS, este trabalho não apresentará os tipos por considerar desnecessário visto que depende do que cada organização realmente requer de um sistema desse tipo, mas uma ilustração pode ser vista na figura 17. Entretanto algumas características importantes que devem estar presentes em um BPMS instalado são, segundo Oliveira (2007): Capturar e identificar os processos críticos e necessários à gestão do negócio; Entender, aceitar e operar o esquema de identificação, o seqüenciamento e a interação desses processos; Tornar possível a integração do sistema de gestão de processos com o ambiente de TI; Aceitar o conjunto de critérios e métodos (metodologia) adotados pela organização, visando assegurar a efetiva operação e o monitoramento desses processos; Fornecer e colocar disponível, a tempo e na hora certa, informações sobre esses processos; Possibilitar o monitoramento de atividades do negócio (BAM – Business Activity Monitoring), monitorando o funcionamento e desempenho dos processos; Fornecer ferramentas para análise da estrutura atual, simulação e otimização de processos; Fornecer recursos e facilidades para a
  • implementação de ações, visando á obtenção de resultados planejados e à melhoria contínua desses processos. Figura 17 Segundo Ghalimi (2006) um BPMS principais dentre ou em adição as apresentadas por Oliveira (2007) que são: suporte a regras de negócio complexas, monitoramento das atividades de negócio (BAM) e uma maneira de controlar versões de documentos ane oferecidas de forma nativa ou por serviços, ou componentes externos. Ele afirma ainda que se quiser ir mais a fundo ainda pode Service Bus – Barramento de Serviços Corporativos), um repositório de metadados e um conjunto para BI (Business Inte que saem da infra-estrutura de BAM. 2.5. BPEL (BUSINESS PROCESS EXECUÇÃO DE PROCESSOS DE NEG implementação de ações, visando á obtenção de resultados planejados e à melhoria contínua 17. Alguns Tipos de BPMS (retirado de PAIM, 2007) Segundo Ghalimi (2006) um BPMS completo deve possuir três potencialidades principais dentre ou em adição as apresentadas por Oliveira (2007) que são: suporte a regras de negócio complexas, monitoramento das atividades de negócio (BAM) e uma maneira de de documentos anexados às instâncias dos processos, podendo ser oferecidas de forma nativa ou por serviços, ou componentes externos. Ele afirma ainda que se quiser ir mais a fundo ainda pode-se utilizar mais três coisas em adição: Um ESB ( o de Serviços Corporativos), um repositório de metadados e um Business Intelligence – Inteligência do Negócio) que ajude a filtrar os dados estrutura de BAM. Um exemplo de BPMS é o Intalium. L (BUSINESS PROCESS EXECUTION LANGUAGE DE PROCESSOS DE NEGÓCIO) 34 implementação de ações, visando á obtenção de resultados planejados e à melhoria contínua . Alguns Tipos de BPMS (retirado de PAIM, 2007) completo deve possuir três potencialidades principais dentre ou em adição as apresentadas por Oliveira (2007) que são: suporte a regras de negócio complexas, monitoramento das atividades de negócio (BAM) e uma maneira de ncias dos processos, podendo ser oferecidas de forma nativa ou por serviços, ou componentes externos. Ele afirma ainda que se se utilizar mais três coisas em adição: Um ESB (Enterprise o de Serviços Corporativos), um repositório de metadados e um Inteligência do Negócio) que ajude a filtrar os dados Um exemplo de BPMS é o Intalium. – LINGUAGEM DE
  • 35 A BPEL, também conhecida como WS-BPEL, foi construída em substituição à BPML que foi uma linguagem criada para modelar processos de negócio, desenvolvida pelo BPMI. A BPML não superou as expectativas, pois trazia consigo a idéia de orquestração de processos em nível muito genérico (LAWISCH, 2008). Segundo Lawisch os detalhes de cada tarefa do processo simplesmente não interessavam para a especificação, assim apenas fazia chamadas, envio e resposta de mensagens entre web services. Também houve a questão política para a troca de linguagem. BPEL foi originalmente construído pela Microsoft e pela IBM, com o apoio das empresas SAP e Siebel, mas esse consórcio passou o controle para a empresa OASIS (BORTOLINI, 2007). BPEL é um padrão técnico em formato XML, onde seu principal objetivo é descrever um BP que interaja com WSs, internos ou externos à organização. BPEL é uma linguagem baseada em WS específica para executar BPs que envolvam integração de sistemas. Se usada a ferramenta certa, uma analista de negócio implementará poucas linhas de código, pois a ferramenta gerará o restante necessário. Em uma comparação unicamente para entendimento pode-se dizer que BPEL é como o SQL (Structured Query Language – Linguagem de Consulta Estruturada), ou seja, as bases de dados trabalham graças ao SQL, e BPEL segue a mesma linha. Os analistas de negócio não terão que escrever uma única linha de BPEL, pois em vez disso devem utilizar uma ferramenta de modelagem de processos que gere o código para eles (GHALIMI, 2006). Não é preciso se importar em como o código é gerado segundo Ghalimi por três razões: Em primeiro lugar usar um motor que suporte BPEL de forma nativa assegura que os processos que são distribuídos nele poderão ser distribuídos em outro motor de processos também. BPEL suporta definição proprietária de extensão. Em segundo, é certo que os processos que vão ser distribuídos visando um servidor executável de BPEL terão as interfaces WS que interagirão em qualquer momento com os processos em sua execução, e os dados para auditoria terão certo formato. Em terceiro lugar, quando a maioria dos fornecedores de TI, como IBM, Microsoft, Oracle e SAP, concordam com o padrão fornecido, não há muito espaço para outro. BPMN pode gerar código BPEL, porém ainda não é perfeito. Existe a notação Aris, porém é uma notação muito proprietária, que não permite ser suportada por nenhuma ferramenta senão uma específica denominada IDS Scheer Aris. Portando o BPMN é a melhor opção atualmente. Os digramas UML também não são utilizados para modelar processos, pois são limitados, não acomodando exigências de uma arquitetura orientada a serviços (SOA). BPMN gera BPEL, porém ainda não há como fazer o caminho inverso (GHALIMI, 2006).
  • 36 Segundo Ghalimi, BPMN e BPEL fazem uma combinação extremamente poderosa porque apresentam um caminho do diagrama ao código sem ter que realmente escrever o código. Códigos BPEL antes utilizavam um gerador de código Java, mas isso se tornou muito complexo, então atualmente com o BPM versão 2.0 o código é interpretado de forma nativa de BPEL 2.0. Um processo BPEL se estrutura em passos, chamados de atividade. Ele suporta atividades como: chamar outro WS com <invoke>; manipular dados das variáveis usando <assing>; terminar o processo com <terminate>; criar estruturas de repetição com <while>; aguardar um tempo usando <wait>, entre outras. A figura 18 apresenta um exemplo de elementos de um BPEL, apenas para ilustrar o funcionamento. Figura 18. Elementos de um BPEL (NADER, 2007) As figuras 19 e 20 apresentam exemplos de uma agência de viagem e de um processo BPEL para esse exemplo respectivamente. No processo da agência de viagens são oferecidos os pacotes de viagens para o Canadá, Estados Unidos e outro lugar com uma previsão. Caso a reserva seja feita para o Canadá (reserva AC) ou para os Estados Unidos (reserva AA) será feito o aluguel de um carro para a designação um, e após deve-se ir para a designação dois, mas também se tem a opção de ir direto para a designação dois, os outros lugares (reserva BA) deverão ir obrigatoriamente para dois, obtém-se a resposta e finaliza-se.
  • 37 Figura 19. Exemplo agência de viagens (NADER, 2007). Figura 20. Exemplo de Processo BPEL (NADER, 2007)
  • 38 3. SOA (SERVICE ORIENTED ARCHITECTURE – ARQUITETURA ORIENTADA A SERVIÇOS) De forma geral a Arquitetura Orientada a Serviços (SOA) descreve duas coisas um tanto quanto diferentes. Uma está relacionada a metodologias para desenvolvimento de software e outro descreve um panorama de todos os ativos de software de uma empresa, assim como uma planta arquitetônica é uma representação de todas as peças que, junto, formam uma construção (KOCH, 2006). SOA utiliza, portanto, metodologia de programação orientada a serviços para criação dos softwares relacionados aos serviços de uma empresa. Uma arquitetura de software é um conceito abstrato, mas sua melhor definição neste paradigma trata basicamente como os componentes fundamentais de um sistema se relacionam através de serviços, intrínseca e extrinsecamente, ou seja, componente principal é o serviço. Idéias expressadas em um fórum da IBM (SOA – Infraestrutura para Inovação - 2006), afirmam que para o desenvolvedor, SOA é um framework baseado em web services que permite invocar objetos remotamente utilizando protocolo SOAP, baseado em XML. E na visão gerencial seria uma tecnologia que cria um ambiente de negócio rápido e atinge vantagem competitiva ou maior valor. Em uma arquitetura orientada a serviço a tecnologia da informação (TI) deve alinhar- se às necessidades do negócio. As atividades de negócio são realizadas através de serviços com formas variadas de requisitar e enviar informações. Destaca-se que um serviço deve ser seguro e confiável, além de rápido. SOA deve garantir a segurança, sigilo e integridade do modelo de negócio. Soluções devem adaptar-se a novos contextos de utilização para acompanhar a evolução do negócio, isso provém da flexibilidade empregada pela tecnologia e que é discutida na implantação do SOA. A Arquitetura Orientada a Serviços é basicamente instituída pela troca de mensagens SOAP entre serviços e também pela utilização dos protocolos XML, WSDL, UDDI, etc. Muitos conceitos de SOA foram baseados em modelos já existentes como processamento distribuído e orientação a objetos (DCOM, CORBA, etc. – vide projeto semestral anterior Desenvolvimento Baseado em Componentes) além de outros (ROCHA, 2006). Além disso, SOA utiliza-se de aliados como XML digital signature e XML encryption para garantir a segurança da mensagem.
  • 39 Segundo a Digital Assets (2007) SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas. Web Services (WS) são uma boa maneira de implementar SOA, mas WS não é SOA. Segundo Koch (2006) SOA é uma arquitetura ou estratégia de TI que cria padrões dentro de uma empresa, utilizando-se uma metodologia específica de desenvolvimento de software, ou seja, através de programação orientada a serviço, enquanto WSs são um conjunto de mecanismos-padrão de comunicação criados sob a World Wide Web (www), ou seja, servem para conectar e comunicar. Segundo Rocha (2006) alguns tendem a definir SOA como um conjunto de Web Services, o que não deve ser feito, pois apesar desta afirmação não ser totalmente errada, deve-se ter em mente que SOA independe de ambiente WS para existir, pois é entendido como um modelo conceitual de arquitetura, sendo baseado em protocolos, conceitos, regras, padrões e acordos contratuais para troca de informações entre serviços. Contudo WS está se tornando a plataforma preferida para implantação de SOA. Para a IBM (2010), dentro de uma arquitetura SOA, aplicativos, informações e recursos de TI são serviços ou blocos de construção, os quais podem ser misturados e combinados para criar novos e flexíveis processos de negócios, assim como devem atender aos requisitos prioritários de mudança, por isso destacando-se o seu nível de reuso. Utilizar orientação a objeto e uma arquitetura de componentes é um facilitador para adoção de SOA, mas não é um pré-requisito. Porém a utilização de UML (Unified Modeling Language) permite projetar a arquitetura em questão, assim é possível modelar um serviço utilizando-se os diagramas conhecidos da UML. De acordo com Neto (2006) os padrões adotados nessa arquitetura garantem interfaces bem definidas, sem a interferência de padrões proprietários limitando a utilização, afirmando ainda que antes os canais de comunicação e o vocabulário não se encaixavam. O foco dos serviços está nas atividades no nível de negócio e suas interações e são ligados dinamicamente e de maneira flexível. A reusabilidade é um fator importante, pois podem ser bastante reutilizados os serviços, porém segundo dados da IBM a falta de confiança e de incentivos desestimula o reuso desses serviços, ressalta-se ainda a visibilidade limitada sobre informações de negócio. A Governança de TI é um fator a ser considerado, pois para que os serviços sejam reutilizados, tem que haver uma metodologia de desenvolvimento centralizada e única. O ideal seria um repositório centralizado de serviços, bem documentados, assim fica fácil a
  • 40 procura por um serviço e integração dos mesmos com outros necessários. Dessa forma, para Koch (2006) SOA envolve um portfólio de serviços criados pelos CIOs (Chief Information Officer) para uma arquitetura corporativa, uma metodologia de desenvolvimento centralizada e uma equipe centralizada de gerentes de projetos, arquitetos e desenvolvedores, e ainda requer um CEO (Chief Executive Officer) e uma equipe executiva dispostos, que preparem o necessário para que a equipe de TI possa analisar processos mais pesados da empresa. Entender estes processos e conquistar adesão para o compartilhamento corporativo são significantes em uma transformação do negócio baseada em SOA. Um CIO é algo como uma direção de informática ao passo que um CEO é uma gerência executiva. É necessário que o CIO e o CEO tenham uma relação de proximidade para que tudo dê certo, como apresentado na seção BPM x SOA. SOA representa um paradigma para a organização e utilização de competências distribuídas que estão sob o controle de diferentes domínios proprietários (OASIS, 2006). Diferente da orientação a objeto, onde o foco é o empacotamento de dados com operações, SOA foca na tarefa ou função de negócio. Ainda segundo o Oasis (2006) SOA oferece uma base mais viável para sistemas de grande escala porque ele se enquadra melhor na forma como as atividades humanas são gerenciadas, ou seja, por delegação, senão não haveria diferença entre serviços e objetos. A tabela 5 apresenta uma comparação de Orientação a Serviços com a Orientação a Objetos de forma geral. Nota-se que a principal diferença é que SOA foca na função do negócio e OOP foca no empacotamento de dados com operações. Tabela 5 – Comparação entre orientação a serviços e orientação a objetos. Fonte: (adaptado de SANTOS, 2007)
  • 41 Destaca-se que os conceitos-chave relacionados com o SOA são: baixo acoplamento, abstração, assets. Baixo acoplamento refere-se à capacidade dos ativos de TI trabalharem integrados embora existam independentemente; a abstração leva em consideração a interação com sistemas complexos de forma simples, pelo menos na maneira de uso; assets são elementos de software que encapsulam o conhecimento, podendo ser reutilizados. Em SOA visa-se obter o máximo de desacoplamento entre os serviços, porém deve haver a flexibilidade de inter-relacionamento entre os serviços, pois os serviços atuam como serviços consumidores e/ou serviços provedores (servidores), dependendo de quem consome ou provê o serviço numa composição de serviços. Mas quais benefícios esperar de SOA na prática? De acordo com a Digital Assets (2007): Redução de custo em novos projetos; Time-to_market/ Agilidade; facilidade/ flexibilidade de manutenção; melhoria da qualidade de serviço; otimização dos processos; transformação dos negócios / oportunidades de receita. Principais Desafios estão relacionados com três principais fatores: Organização e pessoas, processos e políticas, tecnologia e ferramentas. De forma resumida, pessoas são eficientes através da iteração e colaboração, processos SOA fornecem serviços para tornar os BPs eficientes e eficazes, e a tecnologia viabiliza a realização dos processos, conforme figura 21. Figura 21. Componentes da SOA (SANTOS, 2007) Organização e pessoas requerem mudança de mentalidade, apoio executivo, incentivos. Um componente ou serviço, flexível, bem documentado e que resolve um
  • problema recorrente será um bom componente se for possível encontrá lo e reusá-lo. A administração de componentes deve ter um perfil semelhante à administração de dados, além de amplo conhecimento d Processos e políticas devem torna dificuldade de identificar como como em um processo RUP Figura 22. Processo de desenvolvimento de software atual (Digital Assets A tecnologia deve expressar volatilidade, com arquitetura padronizada, massa de serviços e middleware para invocação dos serviços. Não é aconselhável a utilização de SOA nos casos em que a empresa não oferece serviços para parceiros, clientes ou fornecedores, e também como SOA está relacionado ao baixo acoplamento, para os casos de utilização Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC CD 0210486/CA). De forma geral os serviços são executados em máquinas distintas, mesmo que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de prot padronizado bem definido. Dentro do que foi visto, conclui ligação entre a tecnologia da informação e os BPs, ajudando a aumentar a flexibilidade de negócios e a capacidade de uma empresa cumprir meta pode ser considerado uma evolução do Desenvolvimento Baseado em Componentes (DBC). O impacto de SOA nos negócios, fora da indústria de TI, reside no aumento de produtividade relativa às mudanças de processos de negócio recorrente será um bom componente se for possível encontrá- lo. A administração de componentes deve ter um perfil semelhante à administração de dados, além de amplo conhecimento do negócio. Processos e políticas devem tornar SOA uma prática sistemática, dificuldade de identificar como os serviços encaixam-se no modelo de desenvolvimento atual RUP (Rational Unified Process), por exemplo, mostrado na figura 22 Processo de desenvolvimento de software atual (Digital Assets A tecnologia deve expressar volatilidade, com arquitetura padronizada, massa de para invocação dos serviços. Não é aconselhável a utilização de SOA nos casos em que a empresa não oferece serviços para parceiros, clientes ou fornecedores, e também como SOA está relacionado ao baixo acoplamento, para os casos de utilização real-time, essa pode não ser uma boa escol Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC CD 0210486/CA). De forma geral os serviços são executados em máquinas distintas, mesmo que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de prot Dentro do que foi visto, conclui-se que o principal objetivo do SOA é fornecer uma ligação entre a tecnologia da informação e os BPs, ajudando a aumentar a flexibilidade de negócios e a capacidade de uma empresa cumprir metas de negócio. Em aspectos gerais SOA pode ser considerado uma evolução do Desenvolvimento Baseado em Componentes (DBC). O impacto de SOA nos negócios, fora da indústria de TI, reside no aumento de produtividade relativa às mudanças de processos de negócio (GARTNER 42 -lo, entendê-lo, avaliá- lo. A administração de componentes deve ter um perfil semelhante à administração r SOA uma prática sistemática, mas ainda se tem se no modelo de desenvolvimento atual, mostrado na figura 22. Processo de desenvolvimento de software atual (Digital Assets - 2007) A tecnologia deve expressar volatilidade, com arquitetura padronizada, massa de Não é aconselhável a utilização de SOA nos casos em que a empresa não oferece serviços para parceiros, clientes ou fornecedores, e também como SOA está relacionado ao , essa pode não ser uma boa escolha. Sistemas baseados em SOA geralmente são sistemas distribuídos abertos (PUC-RIO, CD 0210486/CA). De forma geral os serviços são executados em máquinas distintas, mesmo que sejam máquinas virtuais, e necessitam se comunicar, o que é feito através de protocolo se que o principal objetivo do SOA é fornecer uma ligação entre a tecnologia da informação e os BPs, ajudando a aumentar a flexibilidade de Em aspectos gerais SOA pode ser considerado uma evolução do Desenvolvimento Baseado em Componentes (DBC). O impacto de SOA nos negócios, fora da indústria de TI, reside no aumento de (GARTNER in ROCHA, 2007).
  • 43 3.1. ENTIDADES DA SOA SOA é composto praticamente por várias funcionalidades conceituais e fundamentais, e quando implementadas juntas proporcionam embasamento para o paradigma do find, bind e execute (ROCHA, 2006). A figura 23 apresenta o paradigma find-bind-execute (Encontrar-Vincular-Executar). Figura 23. O Paradigma Find-Bing-Execute (ROCHA, 2006) A figura acima apresenta a SOA com as entidades básicas e conceituais, todavia, nem sempre essas entidades conceituais estão presentes ao mesmo tempo na arquitetura (ROCHA, 2006). Um exemplo é a entidade Registry onde a localização dos serviços e os contratos são armazenados, na maioria das vezes pode não ser utilizada na arquitetura. As entidades têm funcionalidade específica e as interações entre elas ocorrem de forma a proporcionar o máximo de desacoplamento (ROCHA, 2006). Um acoplamento fraco é uma característica de sistema que reduz a interdependência e riscos de conflitos entre as entidades, propiciando flexibilidade de inclusão, alteração e modificação sem causar danos. A seguir uma breve explicação dessas entidades (consumidor de serviço, provedor de serviço, registro de serviço, contrato de serviço, proxy de serviço).
  • 44 Consumidor de Serviço (Service Consumer) - proporcionado por qualquer módulo de software que requer serviços (STEVENS, 2005). Um service consumer efetua a busca no registro de serviços (registry) para localizar um dado serviço, assim, ao encontrar o serviço essa entidade dispara uma requisição de abertura de conexão contra a interface de serviço procurado conforme formato e regras de contratos exigidos pelo serviço provedor (ROCHA, 2006). Na falta do registry, outra forma de descobrir como chegar ao serviço esperado deverá ser utilizada. Provedor de Serviço (Service Provider) - disponibilizado por qualquer módulo de software ou sistema que executa requisições de serviços provenientes de consumidores de serviços. Esta entidade é um serviço endereçável que aceita e executa requisições enviadas por consumidores de serviços contanto que as requisições sigam regras de contrato e descrições do serviço contidas no arquivo WSDL (ROCHA, 2006). Segundo Stevens (2005) os detalhes dos serviços são publicados em um registry juntamente com a localização do contrato os quais contém as regras e requisitos de segurança para acesso aos serviços providos. É responsável pela implementação do serviço. Registro de Serviço (Registry) – serve como um diretório para localizar páginas HTML, Web Services entre outros. Um registry contém a localização dos serviços disponíveis, ou seja, aponta a localização do WSDL do serviço, e ainda provê a localização dos contratos e requisitos de segurança. Nele além de ser armazenada a configuração do serviço, tem-se também a rastreabilidade de suas dependências. De acordo com Faro & Ferraz (2004) esta entidade é responsável pelo registro e consultas a serviços publicados, funcionando como um diretório ou página amarela. Segundo Rocha (2006) uma das características básicas do registro de serviço é determinar o tipo de segurança e protocolo suportado pelos serviços requisitados, e prover a localização dos WSDLs e políticas de acessos dos mesmos para consumidores e serviços que os requisitam. Contrato de Serviço (Service Contract) – um contrato fornece ao service consumer detalhes para estrutura de requisição do serviço e detalhes da estrutura de resposta que o service provider proporcionará (ROCHA, 2006). Um contrato de serviço oferece listas de prováveis condições excepcionais, requerimentos de segurança, incluindo criptografia e assinatura digital, informação de qualidade de serviço (QoS) que descreve métricas, entre outros. Proxy de Serviço (Service Proxy) – um Proxy de serviços não é requisito em SOA, porém a sua presença implica em ganho de performance e ambiente mais seguro. O Proxy de
  • 45 serviço funciona como em um Proxy de internet, com a diferença que para a arquitetura SOA ele atende aplicações XML. Um exemplo apresentado por Stevens (2005) mostra uma idéia melhor a respeito do assunto: um processo de negócio baseado na arquitetura orientada a serviço, que não requer dados atualizados em tempo real, pode simplesmente se beneficiar do armazenamento local de um serviço no Proxy de serviço, proporcionando assim um ganho no tempo de resposta do serviço solicitado. A figura 24 apresenta um exemplo mais prático do funcionamento do SOA. Figura 24. Dinâmica de funcionamento SOA (Digital Assets - 2007) Um provedor de serviços registra um serviço no diretório de serviços, no exemplo os Correios registram o código de rastreamento de um produto, o consumidor do serviço (Loja Virtual Submarino) solicita o serviço desejado no diretório de serviços (um código de rastreamento para um produto), que retorna o contrato de serviço e endereço para o Submarino, aqui o consumidor de serviço vincula o serviço com o provedor de serviço (Correios) que retorna uma resposta do serviço de rastreamento para o consumidor. 3.2. INFRAESTRUTURA E FASES DE ADOÇÃO 3.2.1. Fases de Adoção A implantação estruturada de SOA é feita de maneira corporativa, através de fases de adoção conforme figura 25. Na seqüência é apresentado um resumo dos processos pertencentes a cada fase.
  • 46 Figura 25. Fases de adoção SOA (Adaptado de DIGITAL ASSETS, 2007) Na fase de iniciação ocorrem os processos de entendimento e conceituação, capacitação, análise de Gap, Business Case e venda interna. Em planejamento e design apresenta-se o estabelecimento do processo de governança, definição da arquitetura tecnológica, definição da infra-estrutura SOA e seleção de projeto-piloto. Na fase de implementação faz-se a identificação dos serviços já existentes, implantação da infra-estrutura e realização dos serviços do projeto-piloto. Na monitoração e tendência tem-se a coleta de indicadores, e análise crítica e propostas de melhoria. É importante observar que para se adotar SOA é recomendado se utilizar da Governança como forma de garantir a implantação adequada de SOA, esse deve ser um dos primeiros passos segundo Barbosa (2009), pois as empresas cada vez mais estão se interligando através de uniões e aquisições, e cada uma dessas relações possuem sistemas heterogêneos, tornando a Governança um fator a ser considerado. Ao se implantar SOA o pessoal de negócio pode visualizar como a empresa é em termos de tecnologia, assim quando projetos de TI são apresentados em relação às atividades e processos de negócio e não na forma de aplicativos (KOCH, 2006). De acordo com a Sun (2010) os dados para as atividades do processo de negócios são oferecidos como um serviço integrado. 3.2.2. ESB (Enterprise Service Bus – Barramento Corporativo de Serviços) O ESB se refere a uma arquitetura de construção de software implementado em tecnologias encontradas em infra-estrutura de middleware. Ele se baseia em reconhecimento de padrões, os quais fornecem base de serviços para arquiteturas mais complexas via driver de evento e padrões baseados em mensagens (BUS). A base de um ESB é construída da quebra de funções de funções básicas em partes, distribuídas onde for necessário. Em termos, ESB não implementa SOA, entretanto fornece as características para que isso ocorra, e não necessariamente precisa ser implementado com WS (WIKIPEDIA, 2009).
  • 47 Um ESB é na verdade um mediador, podendo fazer conversões de formatos para comunicação de diferentes plataformas. O sistema de origem não precisa conhecer o sistema destino, além disso ele provê controles de acesso de sistemas externos e permite configurar a segurança das mensagens. Assim se existisse um sistema X em um empresa que adquiriu uma outra empresa que utiliza um sistema Y implementado com tecnologia diferente, e a empresa X necessita obter dados de ambos os sistemas de forma integrada, ela se utilizaria de um ESB para conectar os sistemas, pois o ESB seria um negociador ou interface ao qual seria solicitada a execução dos processos ou consultas, sem que as tecnologias tomassem conhecimento umas das outras. ESB pode ser considerado o coração do SOA (Forum GUJ, 2007). Segundo Cruz (2006), ESB serve como ligação entre SOA e BPM, pois não é possível realizar um BPMS sem haver um ESB. Para ele enquanto se tem poucos serviços, não há problemas em não se utilizar ESB, mas quando esse número aumenta exponencialmente cada um deles vai ter necessidade de autenticação e autorização dos seus clientes, registro de pedidos e respostas efetuadas, proteção de pedidos mal-formados, cache para aumentar a disponibilidade e escalabilidade, entre outros, necessitando-se assim do ESB. Ao invés de haverem clientes solicitando serviços diretamente, existe uma espécie de hub para enviar e receber mensagens dos serviços, centralizando todas as funcionalidades que eram da responsabilidade de cada serviço, assim tornando possível a redução de tempo e complexidade do desenvolvimento cada vez que seja necessário um novo serviço (CRUZ, 2006), como pode ser visto na figura 26. Um ESB gera interações entre os serviços, assim constitui uma ferramenta poderosa para basear um negócio de uma organização. Figura 26. Representação de um ESB (DIGITAL ASSETS, 2007)
  • 48 O funcionamento de um ESB é ilustrado na figura a seguir. Figura 27. Representação de seleção dinâmica ESB (DIGITAL ASSETS, 2007) De acordo com a figura 27, o funcionamento de um ESB basicamente consiste nas seguintes etapas: O provedor registra o serviço no Registry e no ESB, onde regras e políticas podem ser incluídas. O Cliente invoca o serviço solicitando a infra-estrutura de ESB, que solicita informações sobre o serviço a ser executado no diretório de serviços (Registry). O registro responde então com as informações básicas e os metadados (como port type, endpoint, policies, etc), então o ESB executa algo chamado match client-provider aplicando as transformações, políticas, para troca de informações. A mensagem é transformada e roteada para o provedor correto. O ESB pode ser dividido em dois tipos: Orientado a Protocolo e Orientado a API. Um ESB orientado a protocolo define um protocolo que os fornecedores e clientes devem satisfazer, mas cabe aos fornecedores e clientes fazê-lo. Os sistemas conectados são desacoplados de forma que não compartilham nenhum código, assim não é necessário fazer a distribuição de bibliotecas para as aplicações ou sistemas. Entretanto a desvantagem é que qualquer mudança de protocolo exige que os fornecedores e consumidores a atualizem (SANTOS, 2007). Um ESB orientado a API fornece uma API para fornecedores e clientes usarem na implementação ou em uma chamada de serviços, permitindo que os detalhes do protocolo sejam transparentes, porém requer uma forma para que o ESB faça a distribuição do código gerado ou das bibliotecas para todos os fornecedores e clientes (SANTOS, 2007).
  • 49 4. BPM X SOA Segundo Evangelista (IGP Informática - 2010) deve-se ter em mente que a adoção de SOA requer mudança cultural da organização, da forma como as pessoas trabalham juntas e da forma como pensam em arquitetura e principalmente da forma como elas fornecem funcionalidades ao negócio. A área de TI deve ser vista como uma expressão concreta dos processos de negócio. Para entender a relação entre esses paradigmas é necessário perceber onde um termina e o outro começa, ou a sobreposição entre eles. BPM permite que um analista de negócios alinhe sistemas de TI com os objetivos estratégicos através da criação de processos bem definidos, monitorando sua performance e otimizando eficiências operacionais. Cada BP é modelado como um conjunto de tarefas individuais, e essas tarefas são normalmente implementadas como serviços da empresa (ROSEN, 2006). Segundo Rosen (2006) SOA oferece a plataforma de aplicativos que atuam como pontes entre os processos de negócio e os recursos operacionais. Como apresentado na figura 28. No nível de processos de negócio fornecem-se interfaces que suportam diretamente a execução das tarefas do processo, porém a definição dessas interfaces no contexto empresarial deve suportar consistência e reuso. No nível operacional, SOA expõe as capacidades como serviços integrados, mas isto não é feito por mapeamento direto de aplicações existentes como serviços, pois na verdade, ele provê novas interfaces de serviços baseado na semântica e requerimentos funcionais da empresa, onde os mapeia para sistemas existentes. Por fim, as camadas superior e inferior são unidas através da composição de serviços para criar a camada da plataforma de aplicação. Juntas BPM e SOA provêem uma grandiosa combinação para a informatização dos negócios de uma empresa, onde o uso de BPM fornece uma abstração de alto nível para a definição dos BPs, além da capacidade de monitoramento dos processos. Os serviços suportam os processos, ou seja, fornece as funções necessárias para apoiá-los. SOA fornece a capacidade para que esses serviços sejam combinados e apóia a criação flexível da empresa. BPM e SOA são distintos, um não depende do outro, mas atuam melhor se usados em conjunto. Segundo Evangelista (IGP Informática - 2010) BPM sem SOA serve para construir aplicações, porém com dificuldades de estender todo o processo organizacional, e SOA sem BPM cria serviços reutilizáveis e consistentes, porém perde-se a flexibilidade do negócio e a competitividade.
  • 50 Figura 28. Relação BPM x SOA (ROSEN, 2006) Um projeto de BPM deve considerar a utilização futura de um ESB entre a camada de negócios e serviços, criação de lugar para registrar e descobrir serviços, além de identificar os serviços e a granularidade deles. Ward-Dutton (2009) afirma que a combinação do BPM e SOA é vista como complementar tecnicamente, ele sustenta que há sinergia suficiente entre eles para aumentar o valor empresarial. Ainda segundo ele em SOA a abordagem é de baixo para cima, que é basicamente impulsionado pela TI, e BPM possui abordagem de cima para baixo impulsionado pelo negócio, mas muitas vezes há interesses divergentes entre os impulsionadores dessas iniciativas o que dificulta a integração. Para Ward-Dutton (2009) deve-se entender em alto nível os compromissos de serviços de negócio que uma organização faz, onde os modelos de serviços atuam em diferentes níveis de granularidade e abstração, aqui se decompõe os serviços de alto nível de serviços de negócio e informam-se os requerimentos para os acordos de serviço nos diferentes níveis entre a organização e seus sistemas.
  • 51 5. CONSIDERAÇÕES FINAIS 5.1. CONCLUSÕES GERAIS Este projeto apresenta as características do Gerenciamento do Processo de Negócio e da Arquitetura Orientada a Serviço no contexto da interação do negócio com a tecnologia e utilização de possível reutilização de software. O tema reutilização de serviços é bastante discutido atualmente, mas é necessário técnicas que possam facilitar ou aprimorar o desenvolvimento. O que é apresentado aqui é uma maneira de se projetar software seguindo padrões do negócio propriamente dito, através de BPM e dos serviços oferecidos pelo SOA. Apresentam-se ainda algumas notações do BPMN para utilização com a linguagem BPEL, e o conceito de Sistemas de Gestão de Processos de Negócio, além do embasamento em Web Services. É importante um escopo bem definido, para que ocorra a modelagem voltada para reutilização do serviço. O que foi apresentado serve de base para as pretensões futuras do projeto como um todo, mesmo ainda não estando o estudo de caso definido. 5.2. PROPOSTAS DE TRABALHOS FUTUROS Nos próximos semestres, almeja-se especificar um estudo de caso e aplicar os conceitos de Engenharia de Domínio, BPM e SOA e alguma ferramenta para auxiliar na modelagem do domínio (provavelmente Odyssey) alinhado a outra para modelagem de negócio, chegando-se assim aos serviços a serem implementados. Intensiona-se modelar esse estudo de caso como um framework para o domínio a ser analisado, visando a modelagem de serviços reutilizáveis e demonstração das práticas de ED e SOA no BPM. Como geralmente esses estudos são realizados em domínios muito abrangentes, o estudo de caso deve utilizar apenas uma parte do domínio ou um domínio menor apenas para demonstração, já que essas técnicas em sua maior parte são recomendadas para sistemas de maior porte.
  • 52 6. REFERÊNCIAS BIBLIOGRÁFICAS AURAPORTAL. "O que é BPMS?". 2010. Disponível em: http://www.auraportal.com/PT/PT0-What-is-BPMS.aspx. Última consulta em 26/05/2010. BARBOSA, Ricardo de Castro. Entrevista ao site Meta Análise: “SOA: Erros, Acertos e Desafios em sua Adoção”. Publicado em vídeo em 30/11/2009 no site: http://www.metaanalise.com.br/inteligenciademercado/palavra-aberta/entrevista/soa-erros- acertos-e-desafios-em-sua-adoc-o.html#top.Último acesso em 21/05/2010. BITENCOURT, Maurício. "Modelagem de Processos com BPMN". 2007. Disponível em: http://www.baguete.com.br/artigos/270/mauricio-bitencourt/19/07/2007/modelagem-de- processos-com-bpmn. Úlrima consulta em 25/05/2010. BORTOLINI, Rafael. "O Mundo das Siglas e Padrões: Parte III - BPEL". 2007. Disponível em: http://blog.cryo.com.br/2007/08/27/o-mundo-das-siglas-e-padroes-parte-iii- bpel/. Última consulta em 21/05/2010. CAPELARI, João Cláudio Junior; FORNARI, Miguel Rodrigues. “WebClipping utilizando WebServices”. ULBRA-Canoas 2004. In Reckziegel, 2006. CIVA, Gláucia. “CEO x CIO: As Armas para Vencer a Guerra”. Disponível em: http://www.baguete.com.br/noticias/negocios-e-gestao/08/08/2008/ceo-x-cio-as-armas-para- vencer-a-guerra. 08/08/2008. Última consulta em 25/05/2010. CRUZ, Antônio. “SOA, ESB e BPM”. Disponível em: http://www.arquitecturadesoftware.org/blogs/antoniocruz/archive/2006/07/21/405.aspx. Publicado em 21/06/2006. Última consulta em 23/05/2010. CUNHA, Davi., “Web Services, SOAP e Aplicações Web”. Artigo publicado em http://devedge-temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br.html. Data de publicação 10/12/2002. Última consulta em 18/05/2010. Digital Assets. WorkShop SOA (Service Oriented Architecture). 2007. Disponível em: www.digitalassets.com.br. EVANGELISTA, Carlos. "Usar BPM ou SOA ou BPM e SOA?”. Disponível em: http://www.igpinformatica.com.br/docs/BPMSOA.pdf. Última consulta em 20/04/2010. FARO, Marcelo; FERRAZ, Carlos., “Service Oriented Architectures (SOA)”. Sistemas Distribuídos - CIn/UFPE (Centro de Informática/ Universidade Federal de Pernambuco). Material de aula, Pernambuco, 2004. GHALIMI, Ismael Chang. "BPM 2.0". Disponível em: http://www.projeler.com.br/download/pdf/bpm20_ptbr.pdf. Última consulta em 26/05/2010. Tradução IT/Redux. 2006.
  • 53 GRIMAS, Washington. "Business Process Modeling Notation (BPMN)". 2008. Disponível em: http://www.ebah.com.br/introducao-ao-estudo-de-bpmn-ppt-a8800.html. Último acesso em 25/05/2010. GTA/UFRJ, Grupo de Teleinformática e Automação / Universidade Federal do Rio de Janeiro. XML – Extensible Markup Language. Disponível em: http://www.gta.ufrj.br/grad/00_1/miguel/. Última consulta em 12/05/2010. GUJ (Grupo de Usuários Java). “Arquitetura Orientada a Serviço (SOA)”. Disponível em: http://www.guj.com.br/posts/downloadAttach/1458.java. Última consulta em 13/05/2010. GUJ (Grupo de Usuários Java). Resposta ao fórum “O que é ESB?”. Disponível em: http://www.guj.com.br/posts/list/77933.java.2007. Última consulta em 23/05/2010. IBM (2010) –IBM Software sobre tecnologia – Arquitetura Orientada a Serviços, disponível em http://www-01.ibm.com/software/br/info/topic/openenvironment/soa/. Último acesso em 02/05/2010. IT7 (2010). "BPM - Gerenciamento de Processos de Negócios". Disponível em: http://www.it7.com.br/bpm-gerenciamento-de-processos-de-negocios.php. Última consulta em 26/05/2010. KREGER, H.. “Web Services Conceptual Architecture (WSCA 1.0)”, IBM Software Group, 2001. LAWISCH, Eduardo André. "BPEL: Uma Padronização para Especificação Técnica de Processos". Trabalho de Conclusão de Curso. Universidade de Santa Cruz do Sul, Santa Cruz do Sul, RS, Brasil, 2008. MENÉNDEZ, Andrés Ignácio Martínez. “Uma ferramenta de apoio ao desenvolvimento de Web Services”. Dissertação de Mestrado, Universidade Federal de Campina Grande, curso de Pós-Graduação em Informática, 2002. MENDES, Marco A. S. “Além do BPM – Menos Foco em Processos e mais Foco em Capacidades”. Artigo de blog. Data de publicação: 06/02/2010. Disponível em: http://blog.marcomendes.com/2010/02/06/alem-do-bpm-menos-foco-em-processos-e-mais- foco-em-capacidades/. Última consulta em 25/05/2010. MOURA, J. A. B. “Business Process Management (BPM) – Valorando a TI pelos BPs”. Apresentação de projeto a UFCG/CCT/DSC. Disponível em: http://www.dsc.ufcg.edu.br/~antao/disciplinas/eti/slides/ETI- 7BusinessProcessManagement(BPM).ppt. Última consulta em 20/04/2010. NETO, Manoel V. S.; JUNIOR, Josué V. M. “Afinal, o que é Business Process Management (BPM)? Um Novo Conceito para um Novo Contexto”. Artigo de pós- graduação publicado em 8/11/2008 na Revista Eletrônica de Sistemas de Informação. UFRN (Universidade Federal do Rio Grande do Norte), RN, Brasil. NETO, Rodolpho U. Forum “Arquitetura Orientada a Serviços – SOA Infraestrutura para a Inovação (IBM)”. 2006. Disponível em:
  • 54 http://www.pr.senai.br/posgraduacao/uploadAddress/Introducao%20ao%20SOA%5B31574% 5D%5B4843%5D.pdf. Última consulta em 002/05/2010. N&S Negócios e Serviços Ltda. 2010. "Business Process Management (BPM)". Disponível em: http://www.ns.srv.br/artigos/FolhetoFull.pdf. Última consulta em 31/05/2010. NGC (NEXT GENERATION CENTER). 2010. "BPM". Apostila de curso. Disponível em: http://www.livrosfaculdade.com/2010/05/curso-completo-bpm-next-generation.html. Última consulta em 27/05/2010. OLIVEIRA, Saulo Barbara (Org.). “Gestão por Processos - Fundamentos, Técnicas e Modelos de Implementação”. 1ª ed. Rio de janeiro: Quaitymark, 2006. v. 01. 310 p, 2007. In: PAIM et. al., 2007. PAIM, Rafael; PINHO, Bruno; SANTOS, Daniel; e CAMEIRA, Renato. "O que são BPMS: Sistemas de Suporte às Tarefas para Gestão de Processos". Artigo publicado em http://www.cescage.edu.br/site/pagina/arquivos/revista/innovare/artigos/0f20O_QUE_SAO_ BPMS_SISTEMAS_DE_SUPORTE_AS_TAREFAS_PARA_GESTAO_DE_PROCESSOS. pdf. 2007. Última consulta em 26/05/2010. PIJANOWSKI, Keith. “Construindo Aplicativos Distribuídos”. Artigo publicado em: http://msdn.microsoft.com/pt-br/library/bb507204.aspx em 10/09/2007. Última consulta em 21/05/2010. PROCNET Informática (2010). “BPM”. Disponível em: http://www.procnet.com.br/website/index.asp?novoserver1&start=1&endereco_site=www.pr ocnet.com.br&par=&email=. Última consulta em 10/05/2010. PROCNET Informática. 2010. “Projeto BPM”. Disponível em: http://www.procnet.com.br/website/conteudo.asp?id_website_categoria_conteudo=1768&cod =725&idi=1. Última consulta em 30/05/2010. PUC-Rio (Pontífica Universiadade Católica – Rio de Janeiro). “Arquitetura Orientada a Serviços”. Certificação digital número 0210486/Ca. 2004. Rio de Janeiro, RJ. RECKZIEGEL, Mauricio. “Entendendo os WebServices”. Artigo disponível em: http://imasters.uol.com.br/artigo/4245/webservices/entendendo_os_webservices. Data de publicação: 23/06/2006. Última consulta em 17/04/2010. ROCHA, Cláudio A., “Um Estudo Sobre os Desafios de Segurança na Adoção da Arquitetura Orientada a Serviços (SOA)”. Trabalho Final de M.Sc., UNICAMP, Campinas, SP, Brasil 2006. ROSEN, Mike. "BPM and SOA - Where Does One End and the Other Begin?”. Publicado em www.bptrends.com. Publicado em Janeiro de 2006. EUA. RSC (RATIONAL SOFTWARE CORPORATION). 2001. http://www- 01.ibm.com/software/rational/.
  • 55 SANTOS, Rildo F. "Mapeamento e Modelagem de Processos de Negócios com BPMN". 2009. Disponível em: http://www.slideshare.net/Ridlo/mapeamento-e-modelagem-de- processos-de-negcio-com-bpmn. Última consulta em 26/05/2010. SANTOS (2007) – SANTOS, Rildo F. “SOA Fundamentos – Arquitetura Orientada a Serviços, Fundamentos, Princípios de Design, Melhores Práticas e Governança”. Workshop: SOA Fundamentos, 2007. Disponível em: http://www.slideshare.net/Ridlo/soa- fundamentos. Última consulta em 11/05/2010. SMITH, H. & FINGAR, P. “Business Process Management – The Third Wave”. Tampa: Meghan Kiffer, 2003. In: PAIM et. al., 2007. STEVENS, M. “Understanding Service-Oriented Achitecture”. 2005. In: CUNHA, Davi., “Web Services, SOAP e Aplicações Web”. Artigo publicado em http://devedge- temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br.html. Data de publicação 10/12/2002. Última consulta em 18/05/2010. SUN Microsystems. “Arquitetura Orientada a Serviços (SOA)”. Disponível em: http://br.sun.com/practice/software/soa. Última consulta em 21/05/2010. TESSARI, Rogério. “Processos para desenvolvimento de software orientado a objetos”. Projeto, CARVI/ UCS (Campus Universitário da Região dos Vinhedos Bento Gonçalves / Universidade de Caxias do Sul), Rio Grande do Sul, 2003. TURTSCHI, A.; WERRY, J.; HACK, G., ALBAHARI, J., NANDU, S.; LEE, W., “C# .NET - Guia do Desenvolvedor Web”. Rio de Janeiro, Alta Books, 2002. WARD-DUTTON, Neil. “Bringing BPM and SOA Together for Maximum Business Value”. Artigo publicado no site SOAInstitute.org em 10/06/2009. Disponível em http://www.soainstitute.org/articles/article/article/bringing-bpm-and-soa-together-for- maximum-business-value.html. Comentários traduzidos disponível em: http://www.infoq.com/br/news/2009/07/bpm-soa-business-value. Última consulta em 24/05/2010. WIKIPEDIA. “Enterprise Service Bus”. Disponível em: http://pt.wikipedia.org/wiki/Enterprise_Service_Bus. 2009. Última consulta em 21/05/2010. WIKIPEDIA. “Web Service”. Disponível em: http://pt.wikipedia.org/wiki/Web_service. 2009. Última consulta em 12/04/2010. WORKINGMINDS. 2008. "SOA e BPM". Disponível em: http://www.workingminds.com.br/data/pages/FF8080811C2C224E011C2C23E46F0187.htm. Última consulta em 30/05/2010.
  • 56 7. GLOSSÁRIO Artefato: Termo usado para qualquer produto do trabalho de desenvolvimento de software. Chief Executive Officer - Para quem não gosta de traduzir termos, CEO é um termo elegante. Significa, na prática (e em português) diretor-executivo. Chief Information Officer - Comandante Chefe de Informação. Algo como Diretor ou Vice- Presidente de Informática. É a função de mais alto nível, na área de informática, de uma organização. Responsável pela infraestrutura e manutenção da rede. Estereótipo: Permite classificar elementos "com algo em comum" através de símbolos ou nomenclaturas especiais. Um estereótipo é representado por um nome entre << >>. Framework: (ou arcabouço) é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. Ao contrário das bibliotecas, é o framework quem dita o fluxo de controle da aplicação, chamado de Inversão de Controle. Implementação: (Neologismo) é a fase do Ciclo de Vida de um software (programa computacional, documentação e dados), no contexto de um Sistema de Informação, que corresponde à elaboração e preparação dos módulos necessários à sua execução. Metadados: grande quantidade de dados. Middleware: representa uma camada intermediária entre o sistema operacional e as aplicações distribuídas, objetivando abstrair a heterogeneidade na comunicação. RUP: Abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade. Software: Inclui não só o programa de computador propriamente dito, mas também manuais e especificações. Stakholders: todos os envolvidos em um processo. Representa todos que são atingidos ou atingem de forma positiva ou negativa um processo ou negócio. www - abreviação em inglês de World Wide Web, uma espécie de superteia de alcance mundial, também denominada de Web.