UNIVERSIDADE DO SUL DE SANTA CATARINA DANTES GUILHERME FIGUEIREDO FERNANDES UM ESTUDO PARA AUTOMATIZAR COM A LINGUAGEM BPEL O PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES DE UMA EMPRESA DESENVOLVEDORA DE SOFTWARE Palhoça 2010 DANTES GUILHERME FIGUEIREDO FERNANDES UM ESTUDO PARA AUTOMATIZAR COM A LINGUAGEM BPEL O PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES DE UMA EMPRESA DESENVOLVEDORA DE SOFTWARE Projeto de Trabalho de Conclusão de Curso apresentado ao Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação. Orientador: Professor Ricardo Villarroel Dávalos, Dr. Palhoça 2010 DANTES GUILHERME FIGUEIREDO FERNANDES UM ESTUDO PARA AUTOMATIZAR COM A LINGUAGEM BPEL O PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES DE UMA EMPRESA DESENVOLVEDORA DE SOFTWARE Esta Monografia foi julgada adequada à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina. Palhoça, 17 de junho de 2010. ______________________________________________________ Professor e orientador Ricardo Villarroel Dávalos, Dr. Universidade do Sul de Santa Catarina ______________________________________________________ Prof.ª Maria Inés Castiñeira, Dr.ª Universidade do Sul de Santa Catarina ______________________________________________________ Professor Marcos Tellini Universidade do Sul de Santa Catarina Aos nossos pais que acreditaram que seriamos capazes de concretizar esse objetivo. AGRADECIMENTOS Em primeiro lugar, a minha família que teve a paciência de me compreender nesse momento tão tumultuado de finalização de curso. Aos meus pais pelo apoio oferecido em todos os aspectos. Ao orientador Ricardo Villarroel Dávalos por auxiliar a confeccionar este trabalho e mostrar o caminho que deveria seguir. Ao CIGA – Consórcio de Informática na Gestão Pública Municipal, empresa que apoiou e compreendeu a finalização da monografia. Aos nossos amigos e a todos que nos apoiaram no decorrer do caminho. “Quando você quer alguma coisa, todo o universo conspira para que você realize o seu desejo.” (PAULO COELHO). RESUMO Há muito tempo que micro e pequenas empresas não podiam concorrer com as de grande porte devido ao alto custo das ferramentas tecnológicas necessárias para dar apoio às organizações. Hoje, o mercado está mudando. Soluções que antes só estariam disponíveis por alguns milhares de reais, hoje pode-se conseguir através, por exemplo, de Software Livre e de Código Aberto (SL/CA). Isso está levando estas empresas a superarem esta fase de atraso em Tecnologia da Informação (TI). Neste trabalho é realizado um estudo para automatizar com a linguagem BPEL (Business Process Execution Language) o processo de levantamento de informações de uma empresa desenvolvedora de software, visando difundir ferramentas BPMS (Business Process Management System) na região, colaborando para fomentar o mercado de TI e ajudar as empresas que não possuem capital para investir em tecnologia da informação. A principal contribuição desta monografia está associada a um procedimento de uso e aplicações que poderiam ser realizadas em empresas de outros setores. Palavras-Chave: Sistema de Informação. Software Livre e de Código Aberto. BPMS. BPEL BPMN. Gerenciamento de Processos de Negócio. ABSTRACT For a long time micro and small enterprises could not compete with large companies, due to the high cost of technological tools necessary to support organizations. Today, the market is changing. Solutions that were previously only available for a few thousand dollars, can now be achieved through, for example, Free Software and Open Source which is leading companies to overcome this late stage in IT. This work is a study to automate the BPEL (Business Process Execution Language) process of gathering information from a software development company, aiming to disseminate tools like BPMS (Business Process Management System) in the region, helping to foster the IT market and help enterprises that lack capital to invest in information technology. The main contribution of this monograph is associated with a procedure for use and applications that could be made in companies in other sectors. Keywords: Information System. Free Software and Open Source. BPMS. BPEL. BPMN. Business Process Management. LISTA DE ILUSTRAÇÕES Figura 1: Árvore de problemas ................................................................................................. 21  Figura 2: Exemplo dos três níveis da perspectiva de nível ...................................................... 25  Figura 3: Ciclo de Vida BPMN ................................................................................................ 27  Figura 4: Processo de Negócio Privado .................................................................................... 29  Figura 5: Exemplo de processo abstrato. .................................................................................. 30  Figura 6: Exemplo de um processo colaborativo. .................................................................... 31  Figura 7: Exemplo de eventos. ................................................................................................. 33  Figura 8: Exemplo de atividade geral. ...................................................................................... 33  Figura 9: Exemplo de atividade não-atômica contraído e expandido. ..................................... 34  Figura 10: Exemplo de gateway. .............................................................................................. 34  Figura 11: Exemplo de Fluxo de Sequência. ............................................................................ 35  Figura 12: Exemplo de Fluxo de Mensagem. ........................................................................... 35  Figura 13: Exemplo de Associação. ......................................................................................... 36  Figura 14: Exemplo de Pool. .................................................................................................... 37  Figura 15: Exemplo de Lane. ................................................................................................... 37  Figura 16: Exemplo de Objeto de Dados. ................................................................................ 38  Figura 17: Exemplo de Grupo. ................................................................................................. 38  Figura 18: Exemplo de Anotação. ............................................................................................ 39  Figura 19: Camada BPEL. ........................................................................................................ 41  Figura 20: BPEL. ...................................................................................................................... 42  Figura 21: BPMS. ..................................................................................................................... 46  Figura 22: Plataforma Intalio BPMS ........................................................................................ 50  Figura 23: Etapas metodológicas .............................................................................................. 53  Figura 24: Proposta ................................................................................................................... 54  Figura 25: Estrutura tecnológica .............................................................................................. 55  Figura 26: Macro processo da empresa desenvolvedora de software ...................................... 58  Figura 27: O processo de análise .............................................................................................. 59  Figura 28: O processo de levantamento de informações. ......................................................... 60  Figura 29: Plataforma Intalio Community ............................................................................... 63  Figura 30: Novo AJAX Form ................................................................................................... 65  Figura 31: Modelo de formulário. ............................................................................................ 66  Figura 32: Formulário WorkFlow. ........................................................................................... 67  Figura 33: Variáveis. ................................................................................................................ 68  Figura 34: Parte do processo de levantamento de informações................................................ 69  Figura 35: Mapeamento do formulário para as variáveis. ........................................................ 70  Figura 36: Tela de login do Intalio. .......................................................................................... 71  Figura 37: Tela de processos. ................................................................................................... 72  LISTA DE TABELAS Quadro 1: Síntese dos elementos gráficos BPMN.................................................................... 40  Quadro 2: BPMS Brasileiros .................................................................................................... 48  Quadro 3: BPMS Internacionais Presentes no Brasil ............................................................... 49  LISTA DE SIGLAS AJAX – Asynchronous Javascript e XML BAM – Business Activity Monitoring BPD – Business Process Diagram BPEL – Business Process Execution Language BPM – Business Process Management BPMI – Business Process Management Initiative BPMN – Business Process Modeling Notation BPMS – Business Process Management System BRM – Business Rules Management JCP – Java Community Process JSR – Java Specification Requests MPN – Modelagem de Processos de Negócio OASIS – Organization for the Advanced of Structured Information Standards OMG – Object Management Group TI – Tecnologia da Informação SL/CA – Software Livre e de Código Aberto SOA – Service Oriented Architecture SOAP – Simple Object Access Protocol UDDI – Universal Description and Integration XML – Extensible Markup Language WSDL – Webservice Description Language W3C – World Wide Web Consortium SUMÁRIO 1  INTRODUÇÃO ................................................................................................................. 15  1.1  PROBLEMA .................................................................................................................... 16  1.2  OBJETIVO ...................................................................................................................... 17  1.2.1  Objetivos Específicos .................................................................................................. 17  1.3  JUSTIFICATIVA ............................................................................................................ 18  1.4  ESTRUTURA DA MONOGRAFIA ............................................................................... 19  2  PESQUISA BIBLIOGRÁFICA ...................................................................................... 20  2.1  PANORAMA DAS EMPRESAS DE TECNOLOGIA EM SANTA CATARINA ........ 20  2.2  GERENCIAMENTO DE PROCESSOS DE NEGÓCIO ................................................ 21  2.2.1  Definição de Processos de Negócio ............................................................................. 23  2.2.1.1  Tipos de Processo de Negócio .................................................................................... 24  2.2.1.1.1  Perspectiva de Nível (Level Perspective) ................................................................ 24  2.2.1.1.2  Competência de Núcleo (core competency perspective) ......................................... 25  2.2.1.2  Benefícios de se Adotar o Gerenciamento de Processos de Negócio ........................ 26  2.2.1.3  O Ciclo de Vida BPM ................................................................................................. 27  2.3  NOTAÇÃO DE MODELAGEM DE PROCESSOS DE NEGÓCIO (BPMN) ............... 28  2.3.1  Usos do BPMN ............................................................................................................. 28  2.3.1.1  Processos de Negócios Privado .................................................................................. 29  2.3.1.2  Processos Abstratos .................................................................................................... 30  2.3.1.3  Processos Colaborativos ............................................................................................. 30  2.3.2  Tipos de Diagramas BPMN ........................................................................................ 31  2.3.3  Elementos Gráficos ..................................................................................................... 32  2.3.3.1  Objetos de Fluxo (Flow Objects) ............................................................................... 32  2.3.3.1.1  Eventos ..................................................................................................................... 32  2.3.3.1.2  Atividades ................................................................................................................ 33  2.3.3.1.3  Gateway ................................................................................................................... 34  2.3.3.2  Objetos de Conexão (Connecting Objects) ................................................................ 34  2.3.3.2.1  Fluxo de Sequência (Sequence Flow) ...................................................................... 35  2.3.3.2.2  Fluxo de Mensagem (Message Flow) ...................................................................... 35  2.3.3.2.3  Associação (Association) ......................................................................................... 35  2.3.3.3  Divisores (Swimlanes) ................................................................................................ 36  2.3.3.3.1  Pools ........................................................................................................................ 36  2.3.3.3.2  Lanes ........................................................................................................................ 37  2.3.3.4  Artefatos (Artifacts) .................................................................................................... 37  2.3.3.4.1  Objeto de Dados (Data Object) ............................................................................... 37  2.3.3.4.2  Grupo (Goup) .......................................................................................................... 38  2.3.3.4.3  Anotação (Annotation) ............................................................................................. 38  2.3.4  Síntese dos Elementos Gráficos .................................................................................. 39  2.4  LINGUAGEM BPEL ....................................................................................................... 40  2.4.1  História do BPEL ........................................................................................................ 41  2.4.2  A Relação do BPEL com outros padrões webservices .............................................. 42  2.4.3  Componentes BPEL: Arquitetura ............................................................................. 42  2.4.3.1  BPEL Designer ........................................................................................................... 43  2.4.3.2  Process Flow Template .............................................................................................. 43  2.4.3.3  BPEL Engine .............................................................................................................. 43  2.5  ARQUITETURA SOA .................................................................................................... 43  2.5.1  SOA e webservices ....................................................................................................... 44  2.6  SOLUÇÕES BPMS ......................................................................................................... 45  2.6.1  Lista de Soluções BPMS ............................................................................................. 47  2.6.1.1  BPMS Brasileiros ....................................................................................................... 48  2.6.1.2  BPMS Internacionais Presentes no Brasil .................................................................. 48  2.6.2  Análise da solução BPMS Intalio Community ........................................................... 49  2.6.2.1  JSR 168 ....................................................................................................................... 51  3  MÉTODO .......................................................................................................................... 52  3.1  CARACTERIZAÇÃO DO TIPO DE PESQUISA .......................................................... 52  3.2  ETAPAS .......................................................................................................................... 53  3.3  PROPOSTA ..................................................................................................................... 54  3.4  DELIMITAÇÕES ............................................................................................................ 55  4  MODELAGEM DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES ... 57  4.1  INTRODUÇÃO ............................................................................................................... 57  4.2  MODELAGEM COM BPMN DO MACRO PROCESSO ............................................. 57  4.3  O PROCESSO ANÁLISE ............................................................................................... 58  4.4  O PROCESSO LEVANTAMENTO DE INFORMAÇÕES ........................................... 60  4.5  CONSIDERAÇÕES FINAIS ........................................................................................... 61  5  AUTOMATIZAÇÃO DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES COM A LINGUAGEM BPEL ............................................................... 62  5.1  INTRODUÇÃO ............................................................................................................... 62  5.2  FERRAMENTAS UTILIZADAS ................................................................................... 62  5.3  PROCEDIMENTO PARA AUTOMATIZAR PROCESSOS COM A LINGUAGEM BPEL ........................................................................................................................................ 63  5.4  AUTOMATIZAÇÃO DO PROCESSO PROPOSTO ..................................................... 64  5.4.1  Formulários ................................................................................................................. 65  5.4.2  Esquema XML ............................................................................................................. 67  5.4.3  Diagrama do processo de negócio .............................................................................. 69  5.5  EXECUÇÃO DOS PROCESSOS ................................................................................... 70  5.6  DIFICULDADES ENCONTRADAS .............................................................................. 72  5.7  CONCLUSÕES DO CAPÍTULO .................................................................................... 73  6  CONCLUSÕES E RECOMENDAÇÕES ....................................................................... 74  6.1  CONCLUSÕES ............................................................................................................... 74  6.2  RECOMENDAÇÕES ...................................................................................................... 75  REFERÊNCIAS ..................................................................................................................... 76  APÊNDICE A – AUTOMATIZAÇÃO DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES COM A LINGUAGEM BPEL ............................................................... 78  ANEXO A – DIAGRAMA DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ......................................................................................................................... 104  15 1 INTRODUÇÃO Atualmente pode-se observar um grande relacionamento entre negócios e Tecnologia de Informação (TI), pois as organizações cada vez mais devem fornecer respostas rápidas que permitam a adaptação a cenários dinâmicos. Para isto é preciso estabelecer novos paradigmas, nos quais a disponibilização de informações confiáveis e consistentes deve justificar investimentos. (WHITE, 2009). Para apoiar estes esforços, a partir do ano 2000, a organização BPMI (Business Process Management Initiative) iniciou estudos para apoiar o Gerenciamento de Processos de Negócio e mais tarde veio juntar-se a OMG (Object Management Group). Ambas procuram estabelecer padrões, normas e especificações para uma ampla gama de tecnologias e indústrias. (OMG, 2009). Existem muitas definições relacionadas com o Gerenciamento de Processos de Negócio e para a finalidade deste trabalho considerou-se aquela que se centra em melhorar, redesenhar e automatizar processos. A BPMI lançou em 2004 a primeira versão da Notação Padronizada para Modelar Processos de Negócio (Business Process Modeling Notation – BPMN) e sua finalidade focava-se em ser facilmente entendida por todas as pessoas do negócio, desde analistas do negócio até os técnicos responsáveis pela sua automatização. Com a parceria entre a BPMI e a OMG foi lançada recentemente a segunda versão, a qual vem sendo aplicada por muitas empresas. Também a BPMN encontra-se embutida na maioria das ferramentas que apóiam o desenvolvimento de software. (WHITE, 2009). Após realizada a Modelagem de Processos de Negócio (MPN) existe a necessidade de controlar ou gerenciar estes processos. A partir da linguagem BPEL (Bussines Process Execution Language), pode-se automatizar os processos e publicar as atividades em um webservice, fornecendo desta forma um ambiente para poder monitorar os processos implementados (RAISCH, 2007). A linguagem BPEL trabalha com a Arquitetura Orientada a Serviços (SOA ou Service Oriented Arquiteture) e esta fornece apoio para a automação dos processos de negócio e possibilita que estes se adaptem mais rapidamente a mudanças de condições e de requerimentos. (IBM, 2009). Abrangendo todas estas tecnologias, temos uma solução BPMS (Business Process Management System), ou Sistema de Gerenciamento de Processo de Negócio que permite o 16 acompanhamento em tempo real, orquestrando o fluxo de processos em um ambiente completamente controlado e monitorado. Para proporcionar uma efetiva gestão de uma empresa desenvolvedora de software, este trabalho pretende a partir da implementação de um sistema BPMS, automatizar o processo de levantamento de informações, buscando a qualidade do serviço prestado, visando um melhor relacionamento com os clientes. 1.1 PROBLEMA Para proporcionar uma efetiva gestão de uma empresa desenvolvedora de software, visando proporcionar uma boa qualidade do serviço prestado e realizar um melhor relacionamento com os clientes, a proposta deste trabalho é automatizar o processo de levantamento de informações desta empresa a partir de um sistema BPMS. Na maioria das empresas desenvolvedoras de software não é raro que muitos funcionários estejam simultaneamente envolvidos em múltiplos projetos. Há funcionários que desenvolvem dois softwares e ao mesmo tempo estão corrigindo bugs (defeitos) de outros dois. Além disso, a empresa não possui seus processos bem definidos, dificultando ainda mais o controle das atividades que fazem parte do seu trabalho. Uma das maneiras de tornar toda a empresa mais organizada e ágil, seria através da modelagem de seus processos, definindo seu workflow (fluxo de trabalho), facilitando a correção e otimização de problemas na “linha de produção”. A complexidade existente no desenvolvimento de software, a quantidade de alterações, o prazo e o atendimento de vários clientes com situações específicas, são algumas das situações que podem tornar inviáveis algumas tarefas para liberar estes produtos para o mercado. Mas, mesmo uma empresa de desenvolvimento de software, onde muitos imprevistos e mudanças acontecem freqüentemente, a padronização de seus procedimentos é possível, melhorando seus prazos e custos de maneira significativa. A longo prazo, o desenvolvimento de um novo software pode acabar acontecendo como em uma linha de produção. Adotando-se SOA, por exemplo, a reutilização de código acabaria acelerando todo o processo de desenvolvimento, diminuindo custos e facilitando a manutenção do mesmo. A divisão do código em partes significativas o suficiente para que sejam 17 compartilhadas e reutilizadas em diversas áreas da empresa, agiliza o desenvolvimento. Isso facilitaria muitas tarefas, pois não seria necessário reescrever o código. Um outro problema desse retrabalho pode ser o fato de cada área escrever o código do seu jeito, nem sempre sendo a maneira mais eficiente. A divisão do código e compartilhamento do mesmo, padroniza as formas de acesso aos bancos de dados e o retorno das informações, oferecendo soluções menos acopladas, mais ágeis e gerenciáveis que a abordagem tradicional. A automatização e monitoramento dos processos de negócio relativos ao desenvolvimento de software para estas empresas representam um desafio. Através de webservices é possível obter um retorno sobre o investimento a médio e longo prazo, e ainda agilizar todo o processo de desenvolvimento, além de diminuir custos em geral. Portanto, além de todos os benefícios citados, o SOA define cada componente como um serviço gerenciável, trazendo aspectos funcionais e de qualidade mensuráveis, agregando valor a gestão dos processos e do desenvolvimento como um todo. 1.2 OBJETIVO O objetivo principal deste trabalho é automatizar com a linguagem BPEL o processo de levantamento de informações de uma empresa desenvolvedora de software visando um melhor relacionamento com os clientes. 1.2.1 Objetivos Específicos Os objetivos específicos apresentam-se a seguir: 1) Realizar uma pesquisa bibliográfica da notação BPMN, SOA e BPEL; 2) Efetuar uma pesquisa bibliográfica sobre as principais ferramentas BPMS; 3) Descrever um procedimento que defina detalhadamente a automatização dos processos de negócio. 18 4) Disponibilizar um manual e um vídeo que descreva os principais procedimentos utilizados para a automatização de processos. 1.3 JUSTIFICATIVA Para proporcionar uma efetiva aproximação e um melhor relacionamento com os clientes de uma empresa desenvolvedora de software, este trabalho pretende a partir da aplicação de um sistema BPMS automatizar o processo relativo ao levantamento de informações desta empresa. Parte dos benefícios trazidos por esta automatização, está na melhor gestão dos processos executados pela empresa, do tempo de execução de cada tarefa, bem como a busca pelo aperfeiçoamento do processo como um todo, otimizando-o e diminuindo gargalos. O reflexo desta mudança aparece principalmente, na qualidade do serviço prestado, agregando valor ao negócio, através de um melhor relacionamento com o cliente. Conforme ADVISOR(2009), ao se automatizar os processos de negócio, os modelos serão mais facilmente compreendidos, possibilitando sua otimização e amadurecimento em todos os aspectos. A automatização e monitoramento dos processos de negócio relativos ao desenvolvimento de software podem auxiliar, em muito, a empresa na qual está sendo aplicada e, a partir de um gerenciamento eficiente destes processos pode-se melhorar alguns problemas, como atraso nos prazos, duração das principais atividades, falta de controle, dentre outros. Ainda aliado a tudo isso, a arquitetura SOA vem oferecer soluções mais ágeis, menos acopladas e gerenciáveis, o que agrega valor ao negócio e traz um diferencial muito grande, tanto no serviço prestado ao cliente, como nos processos internos, pois como muitas métricas podem ser inseridas e analisadas em tempo real num ambiente SOA, as respostas a qualquer problema ou gargalo podem ser quase que imediatas. Além disso, por se tratar de um assunto novo, este trabalho pode oferecer uma boa pesquisa bibliográfica e uma solução, já adotada por empresas internacionalmente reconhecidas e planejada por tantas outras. Também a partir desta monografia o assunto poderá ser difundido, apoiando empresas da região com os estudos aqui abordados, assim como o manual criado para automatizar os processos de negócio. 19 Pretende-se também utilizar uma ferramenta do tipo Software Livre e de Código Aberto (SL/CA) para automatizar processos de negócio, pois muitas soluções encontradas hoje possuem um custo elevado não fazendo parte das limitações econômicas das pequenas empresas. 1.4 ESTRUTURA DA MONOGRAFIA Esta monografia esta dividida nos seguintes capítulos: Capítulo 1: apresenta uma introdução geral do tema, o problema, os objetivos, a justificativa e os procedimentos metodológicos. Capítulo 2: descreve os principais conceitos necessários ao desenvolvimento desta monografia. São eles: Panorama das empresas de tecnologia em Santa Catarina, Gerenciamento de Processos de Negócio; Qualidade no desenvolvimento de projetos de software: BPMN, webservices, SOA, BPEL, ferramentas BPMS (Intalio Community Server e Intalio Community Designer). Capítulo 3: apresenta a aplicação de um estudo de caso nas ferramentas Intalio Community Server e Intalio Community Designer. Todo o desenvolvimento é representado de maneira detalhada. Capítulo 4: define a modelagem do processo da empresa de maneira detalhada. Capítulo 5: descreve o procedimento para automatizar processos com a linguagem BPEL e como acontece a execução do processo na ferramenta BPMS. Capítulo 6: aborda as conclusões e recomendações da monografia. Apêndice A: é descrito o procedimento detalhado da automatização com a linguagem BPEL do processo de levantamento de informações da empresa desenvolvedora de software. Anexo A: define os diagramas do processo de desenvolvimento de software. 20 2 PESQUISA BIBLIOGRÁFICA Este capítulo apresenta as definições de gerenciamento de processos de negócio, da BPMN, da linguagem BPEL, do SOA e sistemas BPMS. Trata dos benefícios de se adotar o gerenciamento de processos de negócio e seu ciclo de vida. Traz os usos do BPMN, seus tipos e elementos gráficos. Aborda também a história do BPEL e seus componentes, além da relação entre SOA e webservices e ainda algumas soluções disponíveis no mercado, com uma análise da ferramenta Intalio Community, utilizada neste trabalho. 2.1 PANORAMA DAS EMPRESAS DE TECNOLOGIA EM SANTA CATARINA Segundo CORAL (2007), um levantamento realizado pelo Projeto Gargalos, identificou em 2001, alguns dos obstáculos que estavam dificultando o crescimento e reduzindo a competitividade das empresas do setor de tecnologia. Através das informações obtidas do projeto, a equipe do IEL/SC criou a árvore de problemas do setor. Conforme mostra a Figura 1, são muitos os problemas, mas que convergem para a Gestão ineficiente do negócio de software. 21 Figura 1: Árvore de problemas Fonte: CORAL(2007) Uma das causas para este problema é a insuficiência de padronização dos processos, o que acaba gerando, junto com vários outros fatores, problemas maiores e nas mais variadas áreas da empresa. Através deste levantamento, pode-se constatar que uma gestão ineficiente do negócio, pode afetar todas as áreas da empresa, aumentando custos, diminuindo a qualidade dos serviços prestados, acarretando em insatisfação por parte de clientes e colaboradores. 2.2 GERENCIAMENTO DE PROCESSOS DE NEGÓCIO Segundo KO (2009), toda atividade humana, desde o planejamento de férias até o gerenciamento de processos complexos de fabricação, é regida por processos. Estes podem ser otimizados por qualquer experiência (por exemplo, planejamento de férias) ou por prudentes investigações científicas (por exemplo, processos de fabricação). 22 Da mesma forma, existem processos de negócios nas empresas. Os processos de negócios (por exemplo, ordens de compra, as negociações de preços, solicitação de orçamentos, processos de fusão e aquisição, etc) são comumente encontrados em organizações empresariais e entre organizações. Existem muitos tipos de processos de negócio. Fundamentalmente, os processos de negócio, podem ser privados ou públicos. Processos de negócios privados são aqueles internos à empresa e podem estar localizados no nível estratégico, de gerenciamento ou no nível operacional. Processos de negócios públicos envolvem organizações externas, como por exemplo entrega de mercadorias, encomenda de materiais, etc. Processos de negócios públicos também são comumente conhecidos como processos de negócios colaborativos (Collaborative Business Process - CBP). Com a intensificação da globalização, os processos de negócios colaborativos estão se tornando mais importantes por causa de alguns fatores: 1. O aumento da freqüência das mercadorias encomendadas. 2. A necessidade de transferência rápida de informação. 3. A tomada de decisão rápida. 4. A necessidade de se adaptar às mudanças. 5. Um maior número de concorrentes internacionais. 6. Menor tempo de ciclo. Segundo KO (2009), em uma tentativa de lidar com esses desafios, a Tecnologia da Informação (TI) foi aproveitada para gerenciar processos de negócios. Formulários previamente elaborados cheios de instruções estão cada vez mais sendo substituídos por conteúdos eletrônicos. Isto acabou por dar origem ao Business Process Management (BPM). Segundo Van der Aalst, pesquisador de BPM, o Gerenciamento de Processos de Negócio tem como objetivo "apoiar processos de negócios utilizando métodos, técnicas e softwares para projetar, aprovar, controlar e analisar processos operacionais envolvendo humanos, organizações, aplicações, documentos e outras fontes de informação." Ferramentas de software que apóiam à gestão destes processos operacionais, ficaram conhecidas como BPMS. 23 2.2.1 Definição de Processos de Negócio A fim de evitar confusões quanto ao uso da sigla BPM, iniciaremos por definir exatamente o que esta quer dizer, seguindo a definição de Amaral (2006):  “Business Process Modeling”, ou seja, “modelagem de processos de negócio”, o que é apenas 1(um) dos recursos de um BPMS  “Business Performance Management”, ou seja, “Gerenciamento de desempenho empresarial”, é uma outra categoria de software, mas que, como tem a mesma sigla, é confundida com freqüência com Business Process Management(Gerenciamento de Processos de Negócio).  “Business Process Management” na acepção de gestão, não de tecnologia. Em português a tradução mais adequada seria “Gestão de Processos” ou “Gestão por Processos”. Em inglês, no entanto, não há diferença. Assim pode-se dizer: “Implantamos BPM na nossa empresa”, no sentido de que foi implantada a filosofia de gestão de processos, sem ter, necessariamente, nenhuma relação com sistemas de TI.  “Business Process Management”, ou Gerenciamento de Processos de Negócio, na acepção de tecnologia. É com esse sentido que sempre estaremos empregando a sigla BPM neste trabalho. O autor Ryan K. L. (2009) traz de algumas referencias a definição de processos de negócio como sendo: um conjunto de atividades que toma um ou mais tipos de entrada e cria uma saída que é de valor para o cliente. Um processo de negócio tem um objetivo e é afetado por eventos que ocorrem no mundo externo ou em outros processos, e ainda, um estruturado, medido conjunto de atividades destinadas a produzir uma saída especificada para um determinado cliente ou mercado. Ela implica uma forte ênfase em como o trabalho é feito dentro de uma organização, em contraste com ênfase um foco sobre o produto. Um processo é, portanto, uma específica ordenação de atividades de trabalho através do tempo e lugar, com um começo, um fim, e inputs e outputs claramente identificados: uma estrutura para a ação. (KO, 2009) Por fim, ele ainda evidencia alguns elementos, como: conter atividade intencional; é realizada colaborativamente por um grupo (de pessoas e/ou máquinas); muitas vezes atravessam as fronteiras funcionais; invariavelmente, impulsionado pelo mundo de fora. (KO, 2009). 24 2.2.1.1 Tipos de Processo de Negócio Segundo KO (2009) existem duas principais perspectivas de processos de negócio: a perspectiva de nível (level perspective) e a perspectiva de competência de núcleo (core competency perspective). 2.2.1.1.1 Perspectiva de Nível (Level Perspective) A perspectiva de nível basicamente classifica os processos de negócios em níveis como os de organogramas tradicionais. Esta perspectiva é influenciada principalmente por Robert N. Anthony, que define três níveis de atividades de gestão: 1. Controle Operacional, que é "o processo de assegurar que tarefas específicas sejam realizadas de forma eficaz e eficiente" 2. Gestão de controle, que é "o processo pelo qual os gestores asseguram que os recursos são obtidos e utilizados de forma eficaz e eficiente na realização dos objetivos da organização". 3. Planejamento estratégico, que é "o processo de decidir sobre os objetivos da organização, sobre as mudanças nesses objetivos, sobre os recursos utilizados para atingir estes objetivos, e sobre as políticas que estão a governar a aquisição, utilização e disposição desses recursos". Estes 3 níveis, respectivamente, formam o que hoje é conhecida como Operação Nível Processos de Negócios (Operation-Level Business Processes), Gestão de Processos de Negócio- Level (Management-Level Business Processes) e Alto-nível / Nível Estratégico de Processos de Negócios (High-Level/ Strategic Level Business Processes), conforme mostrado (em um modelo de alto nível) na Figura 2. (KO, 2009). 25 Figura 2: Exemplo dos três níveis da perspectiva de nível Fonte: KO (2009) 2.2.1.1.2 Competência de Núcleo (core competency perspective) 26 KO (2009), afirma que enquanto a perspectiva de nível foca na repartição de responsabilidades, a perspectiva da competência de núcleo de processos de negócios, agrupa os processos de negócios pela sua função, ou mais especificamente, suas competências essenciais. Existem essencialmente três grupos: 1. Núcleo de Processos de Negócio. Estes são os processos geradores de receitas. Por exemplo: Departamento de Desenvolvimento de Software da IBM e da Microsoft. 2. Gestão de Processos de Negócios. Estes incluem os processos que garantem a eficiência, a conformidade e governança corporativa. Por exemplo: Solicitações, notificações, etc. 3. Apoiar os processos de negócios. Estes são componentes que não geram receitas mas sim custos, no entanto, são crucial para o cumprimento dos objetivos de negócio. Por exemplo: O processo, transporte, de negócio de uma indústria. 2.2.1.2 Benefícios de se Adotar o Gerenciamento de Processos de Negócio KO (2009) afirma que a modelagem dos processos atuais em um negócio ou mesmo entre as empresas pode trazer a identificação do problema imediato além de ser uma importante ferramenta para a simulação de ganhos de eficiência de alguns processos. Alguns dos benefícios importantes de analisar e modelar processos de negócios são os seguintes: 1. Maior visibilidade e conhecimento das atividades da empresa; 2. Maior capacidade para identificar gargalos; 3. Aumento da identificação de áreas potenciais para otimização; 4. Tempos de execução reduzidos; 5. Melhor definição das funções e papéis na empresa; 6. Boa ferramenta para a prevenção de fraudes, auditoria e avaliação do cumprimento da regulamentação; 27 2.2.1.3 O Ciclo de Vida BPM Segundo KO (2009), o BPM é composto do seguinte ciclo de vida: Figura 3: Ciclo de Vida BPMN Fonte: KO (2009) 1. Desenho do Processo - Nesta fase, é desenhado como estão os processos de negócio e são eletronicamente modeladas em sistemas de BPM (BPMS). 2. Configuração do Sistema - Esta etapa configura o BPMS e as infra-estruturas do sistema subjacente (por exemplo, a sincronização dos papéis e organogramas). 3. Processo de Adoção - Eletronicamente modelado, os processos de negócios são implantados em sistemas BPM (BPMS). 4. Diagnóstico - Dada a análise adequada e ferramentas de monitoramento, o analista de BPM pode identificar e melhorar os gargalos e potenciais brechas de fraude nos processos de negócio. 28 2.3 NOTAÇÃO DE MODELAGEM DE PROCESSOS DE NEGÓCIO (BPMN) O BPMN são especificações que definem as notações e semânticas de um BPD (Business Process Diagram), ou seja, um diagrama de processos de negócio, o objetivo de todo BPMN. O BPMN, desenvolvido pela BPMI tem como principal objetivo padronizar a notação de modelagem dos processos de negócio. Seu foco está em fornecer uma notação que seja entendida por todos os envolvidos no negócio, desde o analista de negócio, até o técnico responsável pela implementação. Uma segunda meta, mas não menos importante é assegurar que as linguagens XML (eXtensible Markup Language) desenvolvidas para executar os processos de negócio, como o BPEL (Business Process Execution Language), possa ser visualizado com uma notação de negócios orientada, ou seja, ele se preocupada que o que é expressado através da notação, também seja possível transcreve-la para a linguagem de programação. (BPMN, 2009). O que acontece na prática é que buscando-se desenvolver o diagrama dos processos de negócio, utiliza-se o BPMN para padronizar as informações apresentadas no diagrama de modo que depois, através de linguagens de execução como o BPEL consiga-se extrair todo um sistema pronto para implementar, monitorar e de fácil adaptação a novas regras de negócio. Apesar de hoje isto ainda ser uma utopia, pois na prática muito dos processos precisam ser reescritos ou melhorados para corrigirem a falta ou á regras específicas que não podem ser representadas na sua totalidade, a tecnologia vem caminhando para atender a todas estas necessidades. (BPMN,2009). 2.3.1 Usos do BPMN Como apresentado anteriormente, o BPMN é utilizado para comunicar uma ampla variedade de informações para uma ampla variedade de usuários. Os elementos estruturados do BPMN permitirão ao usuário ser capaz de facilmente diferenciar entre as seções de um diagrama BPMN. (BPMN, 2009). 29 Existem três tipos básicos de sub-modelos dentro de um modelo BPMN fim a fim: Processos de Negócios Privado (Interno); Processos Abstratos (Público); Processos Colaborativos (Global). Estes termos ainda não foram padronizados, mas já existe um esforço dentro do W3C (World Wide Web Consortium) e do OASIS (Organization for the Advancement of Structured Information Standards) a fim de consolidar estes termos. (BPMN, 2009). 2.3.1.1 Processos de Negócios Privado Segundo a BPMN (2009), um processo de negócio privado geralmente focalizará no ponto de vista de apenas uma organização. Apesar de processos internos muitas vezes mostrarem interações com participantes externos, eles definem as atividades que geralmente não são visíveis ao público e são, portanto, atividades privadas. A figura a seguir caracteriza um processo de negócio privado. Figura 4: Processo de Negócio Privado Fonte: Adaptado de BMPN (2005) Se forem utilizados Swimlanes então um processo de negócio privado será contido dentro de uma única Pool. O fluxo de sequência do processo ficará restrito a esta Pool e não poderá atravessar seus limites. O fluxo de mensagens pode atravessar seus limites da Pool para demonstrar as interações que existem entre os processos internos de negócio distintos. Assim, um único diagrama de processo de negócio pode exibir múltiplos processos de negócio privado. 30 2.3.1.2 Processos Abstratos Um processo abstrato descreve a interação entre duas entidades, um processo de negócio privado e um outro processo ou participante. Neste processo, as informações apresentadas são para demonstrar a interação que ocorre entre processos de negócio. Como mostra a figura a seguir o processo abstrato apresenta apenas as informações necessárias para se comunicar, mais o objeto de fluxo apropriado. Todas as outras atividades “internas” não são mostradas no processo abstrato. (BPMN, 2009). Figura 5: Exemplo de processo abstrato. Fonte: Adaptado de BMPN (2005) 2.3.1.3 Processos Colaborativos Um processo colaborativo descreve a interação entre duas ou mais entidades de negócio, além de apresentarem uma visão mais global do processo, ou seja, não assume um ponto de vista de uma entidade em particular, apenas mostram as interações entre os participantes. Estas interações entre os participantes, quando apresentadas no diagrama, são chamadas de “pontos de contato”, portanto, este processo define as interações que são publicamente visíveis para cada participante. (ORATECH, 2009). 31 Figura 6: Exemplo de um processo colaborativo. Fonte: Adaptado de BMPN (2005) 2.3.2 Tipos de Diagramas BPMN Através destes e entre estes três sub-modelos BPMN, muitos tipos de diagramas podem ser criados. Segue alguns tipos que podem ser modelados com o BPMN:  Atividades de processos privados de alto nível  Processos de negócios privados detalhados  Processos de negócios privados detalhados com interações a uma ou mais entidades externas  Dois ou mais processos de negócios privados interagindo  Processos de negócios privados detalhado relacionando com processo abstrato  Processos de negócios privados detalhado relacionando com processo colaborativo  Dois ou mais processos abstratos  Processo abstrato relacionando com processo colaborativo  Processo colaborativo somente  Dois ou mais processos de negócios privado detalhado interagindo através de processo abstrato 32  Dois ou mais processos de negócios privado detalhado interagindo através de um processo colaborativo  Dois ou mais processos de negócios privado detalhado interagindo através de um processo abstrato e um processo colaborativo O BPMN foi criado para permitir todos os tipos de diagramas acima. Entretanto, se muitos sub-modelos forem combinados, o diagrama pode ficar muito complexo e difícil de todos entenderem. Deste modo, é recomendado que o diagrama seja focado, como num processo privado ou um processo colaborativo. (BPMN, 2009). 2.3.3 Elementos Gráficos Um dos objetivos do BPMN é ser um mecanismo simples para criar um modelo de processo de negócio, ao mesmo tempo que ser capaz de abordar toda a complexidade de um processo de negócio. Para isso, existem quatro categorias básicas de elementos, que são: Objetos de Fluxo (Flow Objects), Objetos de Conexão (Connecting Objects), Divisores (Swimlanes) e Artefatos (Artifacts). (BPMN, 2009). 2.3.3.1 Objetos de Fluxo (Flow Objects) Objetos de Fluxo são os principais elementos gráficos para definir o comportamento de um processo de negócio e são divididos em três categorias: Eventos (Events), Atividades (Activities) e Gateway. 2.3.3.1.1 Eventos 33 Um evento é representado por um círculo e são caracterizados por se tratarem de um acontecimento durante um processo de negócio. Eles afetam o fluxo do processo e podem representar tanto uma causa (disparador) como um impacto (resultado). Há três tipos de eventos, baseados em como eles afetam o fluxo: Início (Start), Intermediário (Intermediate) e Fim (End), apresentados respectivamente na figura abaixo. (ORATECH, 2009. BPMN, 2009). Figura 7: Exemplo de eventos. Fonte: Adaptado de BMPN (2005) 2.3.3.1.2 Atividades Uma atividade é representada por um retângulo arredondado nas bordas e é caracterizado por se tratarem de um “trabalho” executado. Uma atividade pode ser atômica ou não atômica, ou seja, composta. (ORATECH. 2009). Os tipos de atividades que são parte de um modelo de processo são: Processo (Process), Sub-Processo (Sub-Process), e Tarefa (Task). Tarefa é uma atividade atômica e é incluída dentro de um processo. Uma tarefa é utilizada, apenas, quando a tarefa não pode ser “quebrada” em sub-processos. Figura 8: Exemplo de atividade geral. Fonte: Adaptado de BMPN (2005) Processo e sub-processo não atômico é uma atividade composta que é incluída dentro de um processo. Eles são compostos, ou seja, podem ser “quebrado”, detalhando em níveis menores através de subprocessos. Eles podem ser representado através um sinal de mais no centro inferior de quadrado indicando que ele pode ser detalhado ou pode ser representado através de todo o sub-processo apresentado dentro do respectivo quadrado indicando fazer parte de apenas um trabalho. Eles são apresentados a seguir, respectivamente. 34 Figura 9: Exemplo de atividade não-atômica contraído e expandido. Fonte: Adaptado de BMPN (2005) 2.3.3.1.3 Gateway Um Gateway é representado por um losango e é caracterizado por controlar a divergência e convergência do Fluxo de Sequência. Portanto, ele determina as decisões tradicionais, assim como divisões, fusões e junções dos caminhos. Legendas internas indicam o tipo de controle de comportamento. (ORATECH, 2009). Figura 10: Exemplo de gateway. Fonte: Adaptado de BMPN (2005) 2.3.3.2 Objetos de Conexão (Connecting Objects) Os objetos de conexão são utilizados num diagrama para criar o esqueleto básico de um processo de negócio. Existem três objetos conectores básicos diferentes: Fluxo de Sequência 35 (Sequence Flow), Fluxo de Mensagem (Message Flow) e Associação (Association). (ORATECH, 2009). 2.3.3.2.1 Fluxo de Sequência (Sequence Flow) Um fluxo de sequência é utilizado para mostrar a ordem em que as atividades acontecerão num processo e é representada por uma seta de linha sólida como na figura a seguir. (BPMN, 2009). Figura 11: Exemplo de Fluxo de Sequência. Fonte: Adaptado de BMPN (2005) 2.3.3.2.2 Fluxo de Mensagem (Message Flow) Um fluxo de mensagem é utilizado para mostrar o fluxo de mensagens entre dois participantes que estão preparados para enviá-los e recebe-los. No BPMN, dois Polls num diagrama representam dois participantes. Ele é representado por uma seta com um círculo no inicio da mesma, além de ser tracejada, como apresentado na figura a seguir. (BPMN, 2009). Figura 12: Exemplo de Fluxo de Mensagem. Fonte: Adaptado de BMPN (2005) 2.3.3.2.3 Associação (Association) 36 Associação é utilizada para associar informações com os objetos de fluxo. Texto e gráficos de objetos que não sejam de fluxo, podem ser associados por meio dela. Ela é representada por uma linha pontilhada, porém, uma seta poderá ser utilizada na ponta quando for apropriado. A figura a seguir representa as duas situações. Figura 13: Exemplo de Associação. Fonte: Adaptado de BMPN (2005) 2.3.3.3 Divisores (Swimlanes) O BPMN utiliza-se de divisores (Swimlanes) para particionar e/ou organizar as atividades. É possível que um diagrama BPMN possa representar mais de um processo privado, bem como os processos que mostram a colaboração entre o processo privado ou participante, então cada processo de negócio privado, será considerado como se tivesse sido realizado por diferentes participantes. Graficamente, cada participante irá ser particionado, ou seja, será colocado dentro de um caixa retangular denominada Pool. (BPMN, 2009). Pools podem ter sub divisões, e estas sub-divisões são chamadas apenas de Lanes. 2.3.3.3.1 Pools Um Pool representa um participante de um processo e também atua como um divisor e um container gráfico para particionar uma quantidade de atividades de outros Pools, geralmente em situações B2B (Business to Business). Ele é representado por um retângulo abrangendo todas as atividades como na figura a seguir. (BPMN, 2009). 37 Figura 14: Exemplo de Pool. Fonte: Adaptado de BMPN (2005) 2.3.3.3.2 Lanes Uma Lane é um sub divisão dentro de um Pool que irá se estender por todo o mesmo, independente de se vertical ou horizontal. Lanes são utilizadas para categorizar e organizar atividades. A figura a seguir ilustra uma Lane. Figura 15: Exemplo de Lane. Fonte: Adaptado de BMPN (2005) 2.3.3.4 Artefatos (Artifacts) Artefatos são utilizados para fornecer informações adicionais sobre o processo. Existem três tipos padronizados de artefatos, mas modeladores ou ferramentas de modelagem podem adicionar livremente quantos artefatos forem necessários. Os artefatos padrões atualmente incluem: Objeto de Dados (Data Object), Grupo (Goup) e Anotação (Annotation). (BPMN, 2009). 2.3.3.4.1 Objeto de Dados (Data Object) 38 Objetos de dados são um mecanismo para mostrar como os dados são solicitados ou produzidos por atividades. Eles se conectam às atividades através de associações. (ORATECH, 2009). Figura 16: Exemplo de Objeto de Dados. Fonte: Adaptado de BMPN (2005) 2.3.3.4.2 Grupo (Goup) O grupo pode ser usado para fins de documentação ou de análise, mas não afetam o fluxo de seqüência. Um grupo é representado por um retângulo de cantos arredondados desenhado com linha tracejada como apresentado na figura a seguir. (ORATECH, 2009). Figura 17: Exemplo de Grupo. Fonte: Adaptado de BMPN (2005) 2.3.3.4.3 Anotação (Annotation) Anotações são um mecanismo usado pelo modelador para fornecer informação textual adicional ao leitor de um diagrama BPMN. A figura a seguir demonstra como deve ser representada uma anotação num diagrama BPMN. (ORATECH, 2009). 39 Figura 18: Exemplo de Anotação. Fonte: Adaptado de BMPN (2005) 2.3.4 Síntese dos Elementos Gráficos Apresenta-se a seguir a notação BPMN básica para Modelar Processos de Negócio (WHITE, 2009). Elemento Descrição Notação Evento Um “Evento” é representado por um círculo e é algo que acontece durante um processo do negócio. Há três tipos de Eventos: Início (Start), Intermediário (Intermediate), e Fim (End), ilustrados a direita, respectivamente. Atividade Uma “Atividade” é representada por um retângulo de canto arredondado. Um Sub-Processo é distinguido por uma pequena cruz no centro inferior da figura. Decisão A “Decisão” é representada pela forma de losango e usada para controlar a divergência e a convergência do fluxo. Assim, determinará decisões tradicionais, como juntar ou dividir trajetos. Os marcadores internos indicarão o tipo de controle de comportamento. Fluxo de Um “Fluxo de Seqüência” é representado por uma Seqüência seta com uma linha contínua e é usado para mostrar a ordem (a seqüência) com que as atividades serão executadas em um processo. Fluxo da Um “Fluxo da Mensagem” é representado por uma Mensagem linha tracejada e usado para mostrar o fluxo das mensagens entre dois participantes. Associação Uma “Associação” é representada por uma linha pontilhada é usada para associar dados, texto, e outros artefatos com os objetos do fluxo. Pool O “Pool” representa um participante em um processo. Ele representa também um recipiente que separa um conjunto de atividades de outros “Pools”. Subdivisão Representa uma “Subdivisão” dentro de um “Pool” e se estenderá no comprimento inteiro do “Pool”, verticalmente ou horizontalmente. São usadas para 40 organizar e categorizar as atividades. Objetos de Os “Objetos de dados” são mecanismos para mostrar dados 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 de canto arredondado extraído com uma linha tracejada. Agrupar pode ser usado para finalidades da documentação ou da análise, mas não afeta o Fluxo de Seqüência. Anotação As anotações são mecanismos para que um modelador forneça a informação do texto adicional para o leitor de um diagrama de BPMN. Quadro 1: Síntese dos elementos gráficos BPMN. Fonte: Adaptado BPMN (2005). Para esta tabela, foi sintetizado o básico, mas existem outras formas de elementos gráficos que não foram citados. Aqueles citados são apenas os de maior relevância para o trabalho. 2.4 LINGUAGEM BPEL Business Process Execution Language, ou apenas BPEL segundo Moorthy (2009), é uma linguagem baseada em XML usada para definir processos de negócio da empresa em webservices. O principal objetivo do BPEL é definir o padrão do formato dos fluxos dos processos de negócio para que as empresas possam trabalhar juntas sem problemas, através de webservices. O BPEL amplia o modelo de interação dos webservices e habilita o suporte a transações de negócios. Ele é baseado em webservices no sentido de que cada processo de negócio envolvido é assumido como sendo implementado como um webservice. Processos escritos em BPEL podem orquestrar interações entre webservices utilizando documentos XML de forma padronizada. Esses processos podem ser executados em qualquer plataforma ou produto que esteja em conformidade com a especificação BPEL. 41 Figura 19: Camada BPEL. Fonte: BEXEE (2004). BPEL suporta dois diferentes tipos de processos de negócio: Processos Executáveis: Modelos do comportamento real de uma participante em uma interação de negócios. Eles seguem o paradigma de orquestração que pode ser executado por um motor de orquestração. Processos Abstratos: Usa descrições de processos que especificam o comportamento de troca mutuamente visíveis da mensagem de cada uma das partes envolvidas no protocolo, sem revelar o seu comportamento interno. 2.4.1 História do BPEL Segundo Macedo, em Agosto de 2002, as gigantes IBM, Microsoft e BEA criaram a BPEL, com base nas características do webservice Flow Language da IBM e do XLANG da Microsoft. Em 2003, submeteram-se ao OASIS (Organisation for the Advancement of Structured Information Standards) para defini-lo como um padrão aberto para a orquestração de serviços em webservices. 42 2.4.2 A Relação do BPEL com outros padrões webservices Moorthy afirma que BPEL é baseado em webservices e, portanto, está relacionado com padrões como WSDL (Web Services Description Language), XML (Extensible Markup Language), SOAP (Simple Object Access Protocol) e UDDI (Universal Description, Discovery, and Integration).  WSDL: Define os detalhes da interface do Web service.  UDDI: Define um padrão para a publicação e descoberta de Web service.  SOAP: Define o formato de nível de mensagem para acessar o Web service. É um padrão de mensagens XML fornecido pela W3C. (ERL, 2007). Figura 20: BPEL. Fonte: BEXEE (2004). 2.4.3 Componentes BPEL: Arquitetura O BPEL divide-se em três componentes maiores: BPEL Designer, Process Flow Template e BPEL Engine. Falaremos de cada um separadamente. 43 2.4.3.1 BPEL Designer Esta é a interface gráfica com o usuário e é usado para definir o processo de negócio, pois ele é intuitivo para os especialistas de negócios sem ser excessivamente técnica em profundidade. Ele gera a visualização da lógica do Process Flow Template. 2.4.3.2 Process Flow Template Ele capta a lógica do fluxo de negócio gerada a partir do BPEL Designer em modo de design e prepara para ser executada pelo BPEL Engine em modo de execução. Basicamente ele é responsável por criar o XML que será usado pelo BPEL Engine para saber o que fazer, através do BPEL Designer previamente desenhado pelo analista de negócio. 2.4.3.3 BPEL Engine Executa qualquer Process Flow Template compatível com o padrão BPEL. Seria o responsável pela orquestração dos pedidos de serviços. 2.5 ARQUITETURA SOA O SOA é uma arquitetura na qual podem ser publicados serviços em um ambiente de fácil localização, compartilhamento, e ainda podem ser descritos independentemente de programação e/ou linguagens. (REIS, 2007). 44 Erl (2007) explica que SOA não depende da tecnologia a ser utilizada, que SOA representa um modelo de arquitetura distinto de distribuição de serviços, associado a um paradigma de desenvolvimento centrado na disponibilização de serviços. “O SOA propõe que modelemos um processo, não mais como um monobloco, mas sim por um conjunto ordenado de unidades bem-definidas, cada qual com sua funcionalidade convenientemente descrita, de modo que, ao final da execução de todas as unidades, teremos o resultado esperado.” (YUNG, 2007). Yung (2007) afirma que o SOA define cada componente como um serviço gerenciável, além de ter aspectos funcionais e de qualidade mensuráveis. Portanto o SOA vem oferecer soluções menos acopladas, mais ágeis e gerenciáveis que a abordagem tradicional. Koch (2006) traduz SOA como sendo uma estratégia que proclama a criação de todos os ativos de software de uma empresa via metodologia de programação orientada a serviços, ou seja, porções, ou componentes, de software construídas de tal modo que possam ser facilmente vinculadas a outros componentes de software. A idéia é dividir em partes significativas o suficiente o código, para serem compartilhadas e reutilizadas em diversas áreas da empresa, automatizando assim muitas tarefas que antes precisava-se por exemplo, enviar diversas querys (solicitação ao banco de dados) para servidores diferentes, afim de se obter o cruzamento de dados desejado. Através do SOA, isto pode ser feito através de apenas uma chamada, abstraindo todo o código necessário para o cruzamento dos dados, e facilitando a reutilização do mesmo futuramente. 2.5.1 SOA e webservices Segundo Crescenzo (2010), os webservices são grandes aliados do SOA, mas são apenas uma das maneiras que permitem que o conceito de SOA seja aplicado. SOA pode ser aplicada através de várias tecnologias, segue alguns exemplos:  Programa de linha de comando: Esta pode vir a ser a melhor opção para sistemas que estão alocados em uma mesma máquina ou rede. 45  Via Protocolo HTTP (webservices): Ótima opção para integrar sistemas, geralmente a mais usada por se tratar de uma tecnologia bem difundida e por muitas tecnologias serem compatíveis.  Via TCP/IP (Sockets): Esta é uma solução de alta performance para integração entre sistemas. Cada tecnologia tem uma forma de se desenvolver com este tipo de protocolo.  Com envio de mensagens: Geralmente são feitos com sistemas de terceiros como o MSMQ (Microsoft) ou o MQSeries (IBM), os quais procuram garantir que a integração tenha consistência.  Via arquivos (Text/XML): Solução para sistemas onde a integração não precisa ser imediata, pois esta é o serviço mais demorado e menos performático. Crescenzo (2010) afirma que SOA não é apenas uma tendência e nem uma nova tendência, pois ele foi desenvolvido a alguns anos atrás, mas hoje existe a necessidade de se utilizar o seu conceito, muito mais do que antigamente, o que está levando a sua expansão. 2.6 SOLUÇÕES BPMS BPMS (Business Process Management System), ou Sistema de Gerenciamento de Processo de Negócio é uma solução que vem ganhando espaço no mercado por se tratar de uma solução que permite a operacionalização de fluxos de processos em um ambiente controlado e monitorável. “Uma solução BPMS é constituída de 5 principais itens: o desenho do projeto elaborado por BPMN; a sua orquestração realizada via BPEL; a implementação de agentes ou componentização realizada por SOA; deve possuir ferramentas que monitorem seu funcionamento e deve ser flexível o suficiente para suportar um realinhamento do fluxo do processo ou mudanças em seus agentes.” (SILVA, 2008). Assim como Silva, Amaral(2006) também define solução BPMS como: “Uma categoria de softwares que visa atender o ciclo completo de Gestão de Processos, composta por: modelagem, redesenho, implementação, monitoramento e otimização de processos.” 46 Figura 21: BPMS. Fonte: REIS (2007) Entre alguns dos requisitos de um BPMS, enumerados por Amaral (2006), baseando-se em estudos tais como de Gartner, IDC, Forrester e BPMG, destacam-se: 1. Seja aderente aos padrões da área (BPMN, BPEL e/ou BPML) 2. Permita modelar processos de negócio, podendo também simulá-los e documentá-los extensivamente 3. Tenha componentes prontos para integração com sistemas heterogêneos. Integrações via Web Services, JMS e JCA são básicas, sendo esperados mecanismos prontos para conectar com ERPs (SAP, Peoplesoft, Oracle E- Business Suite etc.) 4. Possua componente de BAM (Business Activity Monitoring) ou integre-se nativamente a um produto deste tipo. Uma solução de BAM monitora em tempo real os indicadores dos processos, e permite que os gestores tomem ações corretivas imediatamente 5. Possua componente BRM (Business Rules Management) ou integre-se nativamente a um produto deste tipo. Um BRM permite separar as regras dos processos do código da aplicação, permitindo que usuários de negócios configurem estas regras de forma ágil e transparente Outro ponto importante quanto a soluções BPMS é quanto a flexibilidade para refletir a estrutura organizacional de um empresa. Bender (2006) defende que todo BPMS deve ser capaz de reconhecer a estrutura organizacional de uma empresa ou empresas (pessoas, áreas, grupos, papéis, relacionamentos diversos, etc.), definir os participantes dos processos e gerenciar o relacionamento 47 entre a estrutura organizacional e esses participantes, tudo isso de maneira que elas possam interagir com as atividades dos processos de maneira adequada e no momento correto. Como a maioria esmagadora das empresas não é orientada a processos, temos que encarar essa realidade e lidar com ela da melhor forma possível, levando isto em conta Bender (2006) relaciona a estrutura organizacional sob diversas perspectivas: 1. Estrutura organizacional da empresa. O BPMS deve ser capaz de refletir a complexidade de uma estrutura organizacional de uma empresa, onde muitas vezes, por exemplo, um mesmo profissional desempenha vários papéis em diferentes grupos organizacionais. 2. Participantes do processo. O BPMS deve ser capaz de definir todos os participantes do processo, independente dos participantes serem humanos, sistemas, etc. 3. Relacionamento entre participantes do processo e estrutura organizacional da empresa. Neste ponto, você deve ser capaz de definir, tanto de maneira estática, quanto de maneira dinâmica (em tempo de execução) qual o relacionamento do participante com a estrutura organizacional, ou seja, como diversos participantes estão mapeados na estrutura organizacional da empresa. 2.6.1 Lista de Soluções BPMS Hoje em dia existem muitas soluções BPMS que podem ser divididas em proprietários e livres. Isto quer dizer que, quando proprietários, existe a necessidade da compra do software, ou como geralmente acontece, a compra de sua licença. Listaremos apenas alguns exemplos de vários que podem ser encontrados, tanto proprietários quanto livres baseado na lista de EXPERIENCE(2006). 48 2.6.1.1 BPMS Brasileiros No quadro a seguir são listadas as principais soluções BPMS brasileiras. Nome Link Ágiles, da Image Technology http://www.imagetec.com.br/ ATOS Workflow, da Lecom http://www.lecom.com.br/ Cadmus Workflow, da Cadmus http://www.cadmus.com.br/ Control Tower, da CPA Consulting http://www.cpaconsulting.com.br/ Fusion Workflow/BPM, da Neomind http://www.neomind.com.br/ GAIA BPM, da GAIA Technologies http://www.gaiatech.com.br/ IntraFlow BPMS, da IntraFlow http://www.intraflow.com.br/ Orquestra BPM, da Cryo Technologies http://www.cryo.com.br/ PME, da Tornatti Systems http://www.tornatti.com.br/ SoftExpert BPM Suite, da SoftExpert http://www.softexpert.com.br/ Webdesk, da Datasul http://www.datasul.com.br/ Quadro 2: BPMS Brasileiros Fonte: EXPERIENCE(2006) 2.6.1.2 BPMS Internacionais Presentes no Brasil No Quadro 3 são listadas as principais soluções BPMS Internacionais presentes no mercado brasileiro. Nome Link Adobe LiveCycle Workflow, da Adobe http://www.adobe.com/ BizAgi BPM Suite, da BizAgi http://www.bizagi.com/ EMC Documentum Process Suite, da EMC http://software.emc.com/bpm/ FileNet Business Process Manager, da FileNet http://www.filenet.com/ (adquirida pela IBM) IBM WebSphere BPM Suite, da IBM http://www.ibm.com.br/ 49 iBOLT Business Integration Suite, da Magic http://www.magicsoftwarebrasil.com.br/ Software Intalio|BPMS, da Intalio http://www.intalio.com/ Java Composite Application Platform Suite, da http://www.sun.com.br/ Sun Microsystems Metastorm BPM Suite, da Metastorm http://www.metastorm.com/ Open Text Workflow Server, da Open Text http://faxsolutions.opentext.com/ Oracle BPM Suite, da Oracle http://www.oracle.com.br/ Q-flow, da Urudata http://www.urudata.com/ TIBCO iProcess Suite, da TIBCO http://www.tibco.com/ Ultimus BPM Suite, da Ultimus http://www.ultimus.com/ W4 BPM Suite, da W4 http://www.w4.eu/ Quadro 3: BPMS Internacionais Presentes no Brasil Fonte: EXPERIENCE(2006) 2.6.2 Análise da solução BPMS Intalio Community Uma análise realizada pela OMG (2009), ela descreve de maneira sucinta a Companhia por trás da ferramenta, e logo em seguida trás informações muito úteis quanto ao produto oferecido pela mesma. Segundo OMG (2009) Intalio é o principal fornecedor BPMS Open Source e ajuda as organizações de todos os tamanhos a obter o máximo retorno sobre o investimento no SOA, através do desenvolvimento e implantação de novos processos de negócio sem ter que escrever um único código. Empresas importantes e reconhecidas internacionalmente fazem uso desta solução, fazendo com que a escolha pela mesma para o trabalho desta monografia se de pela ampla utilização entre empresas fortes. No Brasil temos o próprio governo utilizando a ferramenta, dentre outras empresas não menos importantes. Já sobre seu produto, ela descreve afirmando que o Intalio fornece os principais componentes de um BPMS, que suporta os mais recentes padrões da indústria de BPM (BPEL 2.0, BPMN, BPEL4People). 50 Estes componentes principais são: * Intalio|Designer: um ambiente de desenvolvimento integrado ao Eclipse para BPMN que oferece um ambiente visual, sem a necessidade de se programar uma linha de código. * Intalio|Server: Um servidor de processos nativos ao BPEL 2.0 baseado no J2EE que pode ser implantado em qualquer servidor de aplicação. * Intalio|Workflow: Um conjunto integrado de fluxo de trabalho humano com base na extensão BPEL4People e compatível com qualquer portal JSR 168 (Java Specification Requests). O conceito de portal JSR 168 será descrito na próxima seção. O Intalio|BPMS é um pacote com três diferentes edições: * Intalio| BPMS Enterprise Edition: licenciado de maneira tradicional através um uma licença perpétua e suporte e contratos de manutenção anual. Pode ser implantado em qualquer servidor de aplicações J2EE e qualquer base de dados JDBC. * Intalio|BPMS Community Edition: Esta opção tem o melhor da Enterprise Edition e é disponibilizado sem custo de licença, desde que seja implantado no servidor de aplicações Apache Geronimo J2EE e com o Derby ou MySQL como banco de dados. Opcionalmente, Intalio oferece suporte e manutenção para a Community Edition. * Intalio|BPMS Edition Open Source: É um projeto em constante desenvolvimento cujo objetivo é fornecer um BPMS totalmente funcional sob uma licença Open Source. A figura a seguir, exibe as diferenças entre a versão empresarial e a comunitária. Em destaque, os principais componentes da versão comunitária, utilizada neste trabalho. Figura 22: Plataforma Intalio BPMS Fonte: PROJELER(2010) 51 2.6.2.1 JSR 168 Como o objetivo deste trabalho não contempla o assunto daremos apenas uma breve introdução sobre o mesmo. Foi comentado anteriormente sobre a capacidade do Intalio ser compatível com qualquer portal JSR 168, isso significa dizer que ele foi padronizado segundo as especificações desenvolvidas pela JCP (Java Community Process)e formada por empresas de porte e detentoras de produtos do tipo portal. Segundo Oliveira (2004) o objetivo da padronização era acima de tudo, buscar a interoperabilidade entre portais e portlets. A JSR 168, define um conjunto de APIs para Portlets e um contrato entre o Portal Container e o ciclo de vida de um portlet. A JSR 168 teve o inicio de seus trabalhos em fevereiro de 2002 e foi aprovada em outubro de 2003. Liderada pela SUN e IBM, tinha no expert group, representantes da Apache, BEA, Borland, Oracle, SAP, Vignette, entre outras. 52 3 MÉTODO Este capítulo apresenta a caracterização do tipo de pesquisa, trazendo sua classificação de diversos pontos de vista. As etapas para a elaboração do trabalho são descritas seguidas da proposta e dos recursos para o desenvolvimento deste trabalho, e suas delimitações. 3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA Este trabalho pode ser classificado de diversas maneiras, segundo a caracterização do tipo de pesquisa. Será classificado do ponto de vista de sua natureza, da forma de abordagem do problema, de seu objetivo e do ponto de vista dos procedimentos técnicos. Quanto a sua natureza, é uma pesquisa aplicada, pois como é definido por Silva e Menezes (2005) a pesquisa aplicada objetiva gerar conhecimentos para aplicação prática. Considerando que o objetivo deste é realizar uma automatização dos processos, e isto representa a utilização do conhecimento gerado por esta pesquisa, ou seja, a aplicação prática do conhecimento. Partindo do ponto de vista da forma de abordagem do problema, a pesquisa é classificada como qualitativa. Apesar de ser possível utilizar ferramentas que permitirão realizar monitoramentos, ou seja, traduzir em números informações para analisá-las, este não é o foco deste trabalho e por não ter sido aplicada nenhuma função que realizasse tal monitoramente, este trabalho não é quantitativo. Com relação ao ponto de vista de seu objetivo, esta pesquisa é exploratória, como afirma Silva e Menezes (2005) quando diz que em geral esse tipo de pesquisa assume as formas de pesquisas bibliográficas e estudos de casos, como a ser realizada com uma empresa desenvolvedora de software. Finalmente, quanto aos procedimentos técnicos, esta pesquisa preenche os requisitos de pelo menos duas características, pesquisa bibliográfica, por ser elaborada a partir de material já publicado e estudo de caso, pois envolve o estudo profundo e exaustivo de um ou mais objetos, de maneira que permita o seu amplo e detalhado conhecimento. 53 3.2 ETAPAS As etapas para elaboração deste trabalho encontram-se constituídas da seguinte forma: pesquisa bibliográfica, levantamento e escolha dos processos de negócio de uma empresa desenvolvedora de software, modelagem do processo de negócio selecionado, com a notação BPMN, automatização, monitoramento dos processos a partir da ferramenta BPMS e, testes e validação. A Figura 23 apresenta uma ilustração das etapas metodológicas utilizadas aqui. Figura 23: Etapas metodológicas 54 3.3 PROPOSTA A proposta desta monografia consiste em modelar com a notação BPMN o processo de levantamento das informações relativo ao desenvolvimento de software de uma empresa desenvolvedora, buscando a automação de todo o processo através da ferramenta BPMS Intalio Community. A automação deste processo será realizada a partir da linguagem BPEL e este processo estará orientado para uma arquitetura SOA. A Figura 24 ilustra esta proposta. Figura 24: Proposta É importante destacar que na figura anterior observa-se o gerenciamento dos processos de negócio a partir de uma ferramenta BPMS. A estrutura tecnológica que irá suportar esta proposta encontra-se definida na figura a seguir. 55 Figura 25: Estrutura tecnológica 3.4 DELIMITAÇÕES Este trabalho limita-se a desenvolver apenas uma aplicação de teste para apresentar a tecnologia, não sendo destinada a aplicações comerciais e afins. Portanto, não existe a preocupação direta com validações ou regras de negócios específicas, pois estas regras variam de negócio para negócio, e devem ser tratadas especificamente em cada um destes. Esta monografia não trata da melhor disposição do layout dos formulários e não é voltada a questões de acessibilidade, limitando-se apenas em demonstrar como desenhar o layout básico, e utilizar este na ferramenta aplicada. Não será abordada a criação de um webservice, nem mesmo o acesso ao banco de dados; serão levantadas apenas referências teóricas de sua possibilidade e vantagens. Como a proposta desenvolvida aqui pode ser aplicada a diversas empresas de diferentes setores, podendo também atender a maioria das metodologias ligadas ao desenvolvimento de 56 software, não serão abordadas questões relacionadas a metodologias e nem como aplicar a proposta em outras empresas. Portanto, questões relacionadas a negócios não são o foco desta monografia, sendo necessário realizar um levantamento para cada situação, e conforme comentado anteriormente foge do escopo deste trabalho. 57 4 MODELAGEM DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES Nesta parte da monografia, será abordada a modelagem dos processos da empresa desenvolvedora de software e seu detalhamento, no que diz respeito ao foco da implementação deste trabalho. 4.1 INTRODUÇÃO Segundo Oliveira(2010) oferecer meios para auxiliar a organização a obter uma maior eficiência nas diversas atividades de trabalho nas empresas é fundamental. "O valor que a TI pode oferecer para promover melhorias na competitividade das empresas está diretamente ligado a qualidade do serviço prestado nas diversas atividades de trabalho que compõem os objetivos estratégicos de negócios das organizações." OLIVEIRA(2010) Segundo a TOTVS(2010) a TI vem sendo aplicada na otimização de processos empresariais, beneficiando empresas dos mais variados setores, reduzindo a ineficiência e aumentando a produtividade. O benefício trazido pela automação de processos independe de setor, e numa empresa desenvolvedora de software, não é diferente. 4.2 MODELAGEM COM BPMN DO MACRO PROCESSO A figura a seguir ilustra o Modelo de Processo de Negócio (MPN) de uma empresa desenvolvedora de software. Esse modelo, encontrado na internet é descrito no anexo A. Este MPN será estudado para atingir a proposta desta monografia e também será utilizado como base para o detalhamento dos demais processos, buscando a implementação do processo de levantamento de dados. 58 Figura 26: Macro processo da empresa desenvolvedora de software O processo referente à análise preocupa-se em reunir o maior número de informações possíveis quanto ao projeto, para que assim seja possível solucionar uma necessidade levantada anteriormente. A parte de codificação diz respeito ao desenvolvimento em si do projeto, ou seja, onde será preparado o ambiente de desenvolvimento e escrito todo o código até que esteja satisfatoriamente terminado. Finalizado o código fonte ou processo de codificação, será iniciado o processo de testes, onde será colocado a prova este código previamente desenvolvido. Ocorrendo tudo como planejado, será iniciada a parte de implantação, onde basicamente será implementado o sistema na empresa, será dado o treinamento para os usuários do mesmo, e por fim realizada a migração dos dados. Por último, o processo de produção, onde começa a parte de análise de performance da aplicação, suporte aos usuários, e ainda, apontar para a equipe de desenvolvimento problemas de performance na aplicação. 4.3 O PROCESSO ANÁLISE Apesar de o processo de análise ter o início e o fim teoricamente bem determinados, detalha-se cada vez mais o sistema a cada novo passo terminado no processo, descobrindo-se novas funcionalidades que acabam aprimorando o que foi levantado no início. Por isso, nessa etapa, 59 recolhe-se o necessário para dar um início, meio e fim para o projeto, sendo “maleável”, mas tendo sempre em vista que mudanças poderão ocorrer. E é desta forma que este processo desenvolve-se, conforme a figura abaixo, em levantamento de informações, desenho do processo, modelagem de dados, modelagem do sistema, prototipação e definições finais. Figura 27: O processo de análise No “levantamento de informações” é a etapa na qual serão levantadas as necessidades da empresa através de entrevistas com os usuários e responsáveis. Com as informações levantadas junto aos usuários, será feito o desenho do funcionamento do negócio, realizado no “desenho do processo”. Depois disso, será feita a “modelagem de dados”, na qual utilizando-se das informações levantadas anteriormente pelo analista, será finalizado o modelo de dados, podendo ou não, ser apresentado para o usuário final, deixando esta decisão para o analista, levando em conta que um usuário leigo não tirará proveito nenhum deste modelo. Assim que aprovado o modelo de dados pela equipe de administradores de dados, será feita a “modelagem do sistema” que irá manipular estes dados. Terminada a modelagem, o processo de “prototipação” procura apresentar para o usuário um protótipo de telas, da navegabilidade do sistema e de como suas funcionalidades serão exibidas. Com a aprovação do usuário, inicia-se o processo de “definições finais”. Neste serão definidas as próximas fases, e será apresentado um cronograma de execução, quantidade de desenvolvedores e etc, identificando assim sua viabilidade. 60 4.4 O PROCESSO LEVANTAMENTO DE INFORMAÇÕES O processo de levantamento de informações ocorre primeiramente através de entrevistas feitas com usuários, tentando reunir o maior número de dados possíveis. Não se deve levar em conta a parte técnica neste momento, dando importância apenas para as informações. A Figura 28 ilustra o processo de levantamento de informações. Figura 28: O processo de levantamento de informações. Com as informações reunidas, o analista tem o trabalho de formatar estas informações, cuidando para que nenhum detalhe passe por despercebido, pois eles podem fazer a diferença mais tarde. Depois das informações formatadas, elas serão apresentadas para o gerente de projetos, que aprovará ou não. Em caso de não serem aprovadas, o analista deverá buscar novas informações com o usuário. Caso aprovadas, o analista ainda deverá entrevistar os dirigentes, pois nem sempre os usuários possuem todas as informações. Com as novas informações, será feita a consolidação das mesmas e novamente submetida para aprovação do gerente de processos. Em caso de não serem aprovadas, o gerente definirá a necessidade ou não de um novo contato com o usuário. Caso contrário esta etapa encontra-se finalizada. 61 4.5 CONSIDERAÇÕES FINAIS Neste capítulo foram levantadas algumas informações sobre as empresas desenvolvedoras de software, além disso, foi mostrado o macro processo do desenvolvimento e ainda, detalhado este mesmo processo até o levantamento das informações, a fim de utilizarmos este no próximo capítulo, dando continuidade a implementação com a linguagem BPEL do mesmo. 62 5 AUTOMATIZAÇÃO DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES COM A LINGUAGEM BPEL Neste capítulo serão descritos quais os procedimentos para automatização com a linguagem BPEL e comentados as principais dificuldades relativas ao uso da ferramenta Intalio Community. 5.1 INTRODUÇÃO Para iniciar a automatização do processo, é realizada a modelagem com a notação BPMN deste processo a partir do Intalio Community, e então é preparado o ambiente para sua aplicação ou orquestramento. Existem algumas tarefas que precisam ser feitas antes de iniciar a automatização, por exemplo, com a instalação do Java JDK, define-se a variável de ambiente do sistema operacional, além de instalar a ferramenta Intalio Community e configurar alguns detalhes que serão explicados minuciosamente no Apêndice A. 5.2 FERRAMENTAS UTILIZADAS Conforme comentado, a ferramenta utilizada para a automatização proposta nesta monografia foi o Intalio Community e nada além desta foi necessário, pois este sistema encontra-se constituído por outras ferramentas que estão integradas ao mesmo, fazendo dele uma solução completa. A figura 29 ilustra as várias tecnologias que são incorporadas nesta ferramenta (JDBC, Apache, MySQL, etc.), para propiciar a orquestração. Apesar de estas serem utilizadas de maneira transparente até mesmo para o analista de processos, estão presentes e se fazem necessárias para o funcionamento do todo. A figura a seguir, ilustra melhor a plataforma Intalio Community. 63 Figura 29: Plataforma Intalio Community 5.3 PROCEDIMENTO PARA AUTOMATIZAR PROCESSOS COM A LINGUAGEM BPEL O processo de automação para qualquer processo de maneira geral segue alguns passos que serão detalhados a seguir, porém deve ficar claro que processos específicos, requerem passos específicos. A automação de maneira generalizada acontece da seguinte maneira: 1. Definição do processo: Nesta etapa, é definido o processo, de que maneira ele acontece, como ele “flui”, quando ele é executado, qual o resultado esperado e suas possíveis exceções. Isto tudo é definido independentemente do sistema BPMS que será utilizado. 2. Selecionar um sistema BPMS: Na seleção do sistema BPMS, deve-se estudar as ferramentas disponíveis no mercado, avaliar custos e benefícios, procurar aquela que melhor atende as expectativas da empresa. 3. Criar formulários: As etapas números três e quatro, podem variar de acordo com o que foi selecionado na etapa anterior, mas basicamente, você deverá desenhar todos os formulários em que haverá a interação dos usuários, seja para preencher dados, ou para notificar. 64 4. Criar esquema XML: Aqui será definido como os dados serão tratados pelo sistema. 5. Desenho do processo de negócio: Será necessário desenhar o processo de negócio, definindo onde cada item se encaixa e de que maneira a informação “caminha” por ele. 6. Integração: Deve-se então definir a integração com outros sistemas ou banco de dados. Com o processo modelado, será possível desenhar algumas “saídas” para outros sistemas ou bancos de dados. 7. Monitoramento: Com a etapa número 5 (cinco) concluída, pode-se definir métricas e monitorar o modelo, buscando uma gestão eficiente e possíveis gargalos no processo. Podem-se inserir etapas, como também, não utilizar algumas destas anteriormente detalhadas, mas baseado no que foi estudado, estas são as etapas geralmente utilizadas para automatizar um processo. Dependendo da seleção feita na etapa número dois, a ordem não necessariamente deve ser esta, podendo até mesmo, as etapas serem feitas em paralelo ou em ordem diferente da apresentada. 5.4 AUTOMATIZAÇÃO DO PROCESSO PROPOSTO O primeiro passo para a automatização de um processo é a definição do mesmo, o qual já aconteceu, conforme ilustra a Figura 28. A partir desta definição, é elaborada uma pesquisa para selecionar um sistema BPMS que atenda as necessidades. Nosso objetivo no momento é a utilização de SL/CA sem custos. Como apresentado na seção 2.6.2, a solução Intalio Community atende ao objetivo proposto desta monografia. Depois de um período de familiarização e testes com a ferramenta, inicia-se o desenvolvimento da solução para a automatização do processo proposto. Para isso é necessário iniciar um novo projeto e começar a desenhar os formulários. 65 Para a criação de todas as telas, foi usado o seguinte procedimento: Clicando com o botão direito em cima do projeto criado, seleciona-se o caminho: Nova; Outros; Esta opção abrirá o seguinte ambiente de opções, conforme a figura a seguir. Figura 30: Novo AJAX Form 5.4.1 Formulários Os formulários com interações, ou seja, aqueles que necessitam de uma resposta, serão criados em AJAX (Asynchronus Javascript e XML) e este, considera o uso de tecnologias 66 Javascript e XML, providas de navegadores para tornar as páginas Web mais interativas com o usuário. Os formulários que não necessitam de interação, no caso, de notificação será utiliza a opção de formulário Workflow, para que seja possível mostrar as opções de criação da ferramenta. Criando-se um formulário AJAX Form, é possível customizá-lo da maneira que for mais conveniente para o analista, e ainda é possível definir regras de validação de formulários, tornando mais amigável a interação do cliente com a ferramenta. Para se desenhar um modelo de formulário utiliza-se a paleta IntalioWidgets, que já traz muitos recursos prontos, como o seletor de datas, tabelas, textareas, e outros, agilizando o processo de desenho do formulário. A Figura 31, ilustra um modelo de formulário que foi elaborado. Figura 31: Modelo de formulário. Utilizando a aba de propriedades é possível customizar regras, para que não seja possível deixar o campo em branco, ou para que o campo não seja editável, dentre outras. Ainda questões relacionadas ao design, como tamanho, cor e até mesmo opções mais avançadas estão disponíveis. Outro tipo de formulário também está disponível, o Workflow. Para mostrar as possibilidades da ferramenta, será detalhado como pode-se utilizar este outro modelo. Sua principal diferença está em que, neste modelo de formulário, não é possível fazer a validação do lado do 67 cliente, ou seja, a validação ocorre apenas depois do envio da requisição ao servidor. A Figura 32 ilustra um modelo deste tipo de formulário. Figura 32: Formulário WorkFlow. Estas são algumas das funcionalidades para a criação do formulário, mostrando-se uma ferramenta muito poderosa, flexível e relativamente fácil de se usar par desenhar um formulário almejado pelas necessidades do negócio. 5.4.2 Esquema XML Para a automatização do processo proposto, optou-se trabalhar com o Esquema XML, pois desta maneira seria possível utilizar variáveis durante o processo. A figura a seguir ilustra um modelo de Esquema XML utilizando a ferramenta. 68 Figura 33: Variáveis. Neste modelo todas as variáveis foram definidas como string, mas é possível trabalhar com variáveis complexas com a mesma facilidade que existe nas simples. Elas podem ser utilizadas durante o processo para que a informação trafegue de um formulário a outro baseado em algumas regras, dentre outras utilidades. 69 5.4.3 Diagrama do processo de negócio O diagrama do processo de negócio será o “desenho” responsável pelas informações de como o processo deverá seguir, e como deverá responder a cada situação ou exceção. A seguir é ilustrado na Figura 34, parte de um diagrama de negócio em caráter ilustrativo. Figura 34: Parte do processo de levantamento de informações Na Figura 34, nota-se a existência de quatro piscinas (Polls), cada piscina é um participante que de alguma forma interage com o processo como um todo. Além disso, é possível notar muitas outras notações, como o sub-processo e uma piscina diferente das outras. Estas informações são detalhadas no Apêndice A. Com o diagrama desenhado, precisa-se aprofundar um pouco mais para que seja possível utilizá-lo corretamente, fazendo o mapeamento das informações, ou seja, como a informação trafegará no mesmo. Para isso, existe a aba “mapeamento” responsável por esta tarefa e ilustrada pela Figura 35. 70 Figura 35: Mapeamento do formulário para as variáveis. O mapeamento ocorre da seguinte forma: deve-se definir de onde as informações vêm, para onde elas irão, e de que forma isto se dará, sendo possível definir condições se necessário. Com as informações reunidas até aqui, será possível terminar de desenhar o processo, no qual várias informações, apesar de não estarem visíveis na modelagem, estão detalhadas e por isso a orquestração e automação do processo são possíveis. 5.5 EXECUÇÃO DOS PROCESSOS A execução do processo acontece por meio da url: http://ip-servidor:8080/ui-fw por padrão, onde o login e senha são setados num arquivo XML no servidor. O Apêndice A detalha como pode ser definido os usuário para acesso ao sistema. A figura a seguir ilustra como é a tela padrão de login apresentada pelo Intalio Community. 71 Figura 36: Tela de login do Intalio. O Intalio Community trabalha apenas com três abas. A aba de tarefas exibe tarefas de processos que exigem uma interação para que o mesmo prossiga. A aba de notificações exibe aquelas que não necessitam de uma interação, são apenas de caráter informativo. E por último a de processos, onde são listados todos os processos em que o seu usuário pode iniciar. A figura a seguir ilustra melhor estas abas. 72 Figura 37: Tela de processos. Com isso, basicamente todo o processo pode ser utilizado sem problemas. A partir daqui, o processo poderá ser mais facilmente visualizado pela empresa, identificando gargalos e otimizando sem a necessidade de se escrever nem uma linha de código, apenas modificando o processo já desenhado, agilizando o processo de alinhamento com os objetivos do negócio. 5.6 DIFICULDADES ENCONTRADAS Como dificuldades encontradas, pode-se citar as poucas referencias bibliográficas encontradas para apoiar a automatização dos processos no sistema Intalio Community. Por conta disso algumas outras dificuldades apareceram, como: dificuldade na elaboração da modelagem no sistema para que funcionasse de acordo com a decisão do analista. Dificuldade esta que foi resolvida apenas através do método de tentativa e erro com vários elementos do BPMN. 73 5.7 CONCLUSÕES DO CAPÍTULO Neste capítulo foi descrito como acontece o processo de automatização e suas várias etapas num contexto geral. Foram exibidas as principais partes da automatização e qual sua relação com a orquestração, pois cada detalhe representa uma nova forma do sistema interagir com o usuário, fazendo com que cada informação acrescentada ou esquecida faça uma grande diferença. Ainda neste capítulo foi abordado o processo em execução, o que facilita o entendimento e a relação com as partes durante o desenvolvimento. Foram exibidas telas em caráter informativo e definidas regras do comportamento do processo. Alguns problemas foram verificados durante o desenvolvimento deste projeto, todos estes sanados a partir de consultas e domínio da ferramenta, mostrando-se uma ferramenta muito flexível e madura. 74 6 CONCLUSÕES E RECOMENDAÇÕES Neste capítulo serão abordadas algumas conclusões obtidas com este trabalho que foram verificadas no decorrer da automatização realizada, e levantadas algumas recomendações que merecem destaque, mesmo que não abordadas diretamente nesta monografia. 6.1 CONCLUSÕES A experiência e o conhecimento obtido no desenvolvimento deste processo leva a crer que uma empresa que adote este tipo de abordagem tende a ganhar muito em agilidade no realinhamento e otimização dos processos, além de conseguir identificar mais facilmente gargalos, trazendo benefícios tanto para a empresa que o utiliza quanto para o cliente em qualidade de serviço. A utilização desta abordagem requer talvez, uma completa mudança de paradigmas relacionada à gestão da empresa, pois a mesma traz uma nova forma de se pensar sobre os serviços oferecidos pela empresa e sua maneira de monitoramento. Uma abordagem como esta se mostrou muito eficiente enquanto em estudo nesta monografia, pois para uma troca completa do processo em produção durante os testes, foi muito mais ágil do que se fosse necessário fazer um realinhamento do processo numa abordagem tradicional. Esta é uma tecnologia que merece reconhecimento, pois os ganhos que a mesma agrega a empresa é motivo suficiente para pelo menos colocá-la a prova. Definir detalhadamente os processos de negócio de qualquer empresa ajuda a amadurecê-la e fortalecer seu modelo de gestão, oferecendo novas alternativas e ferramentas, como o Intalio Community, no controle das empresas agregando valor aos serviços oferecidos, conseqüentemente, satisfazendo aos clientes. Com a utilização desta ferramenta para apoio ao gerenciamento dos processos de negócio podem ser avaliadas ações estratégicas a partir de regras de negócio e criar um ambiente de colaboração efetiva e múltiplas funções, para analisar coletivamente as informações e preparar usuários para atuarem em diversos setores. Também, permite fácil atualização e incorporação de 75 outras atividades a partir do modelo criado e cria-se um material adequado as necessidades da empresa. Através do estudo levantado e do manual disponibilizado, facilita-se a difusão deste modelo de gerenciamento, vindo a balancear a concorrência do mercado, aproximando grandes e pequenas empresas, sem acarretar num custo elevado e longe do alcance das pequenas. 6.2 RECOMENDAÇÕES Durante os estudos realizados no desenvolvimento deste trabalho, verificou-se que ferramentas como o BAM merecem um destaque e devem ser estudas e incorporadas ao processo para monitoramento mais eficiente do mesmo, além da possibilidade de integrar banco de dados externos, podendo estabelecer relações que afetem o processo como um todo, trazendo benefícios e uma melhor integração do mesmo com os sistemas e a empresa. Muitas outras tecnologias, apoiadas pelo SOA, que agregam valor ao sistema BPMS estão disponíveis, além da possibilidade de desenvolvimento paralelo de uma solução própria para integração ao sistema, trazendo uma flexibilidade muito grande para sua adoção em qualquer tipo de empresa e dos mais variados setores. 76 REFERÊNCIAS ADVISOR, BPM. Automação de Processos. 2008. Disponível em: . Acesso em: 13/04/2010 AMARAL, Vinícius. BPM – Afinal, o que é (e o que não é) isso?. Disponível em: . Acesso em: 19/02/2010. BENDER, Luis. BPMS e Estrutura Organizacional. 2006 Disponível em: . Acesso em: 23/02/2010. BEXEE. BEXEE – BPEL Execution Engine. Disponível em: . Acesso em: 16/10/2009. BPMN. Business Process Modeling Notation Specification. V1.2. 2009 Disponível em: . Acesso em: 29 stembro 2009. CORAL, Eliza et al. PLATIC: Arranjo Produtivo Catarinense. 2007. Disponível em: < http://www2.ielsc.org.br/capitulo1_platic.pdf>. Acesso em: 05/05/2010. CRESCENZO, Luis Henrique Caruso. SOA não é Webservice. Disponível em: . Acesso em: 21/04/2010. ERL, Thomas. Entrevista com Thomas Erl. Revista PortalBPM. São Paulo, ed. 01, 2007, p. 30- 33. EXPERIENCE, The BPM. BPMS Directory. 2006 Disponível em: . Acesso em: 22/02/2010 IBM. New to SOA and Web services. Disponível em: . Acesso em: 31 ago. 2009. KO, Ryan K. L. A Computer Scientist`s Introductory Guide to Business Process Management (BPM). Disponível em: < http://www.acm.org/crossroads/xrds15-4/bpm.html>. Acesso em: 16/10/2009. KOCH, Christopher.ABC da SOA. 17 jul 2006. Disponível em: Acesso em: 08/03/2010. MACEDO, Sifredo. Introdução ao BPEL e à Orquestração de Serviços. Revista PortalBPM. São Paulo, ed. 02, 2007, p. 36-39. MOORTHY, Raj Kumar. An Introduction to BPEL. Disponível em: . Acesso em: 01/09/2009. OLIVEIRA, Eric C. M.Tecnologia de Portais Java e a JSR 168. 2004. Disponível em: . Acesso em: 01/03/2009. 77 OLIVEIRA, Leonardo Rocha de, ET AL. Aspectos críticos de gestão em empresas desenvolvedoras de software. Disponível em: Acesso em: 15/04/2010. OMG. About The Object Management Group (OMG). Disponível em: . Acesso em: 31 ago. 2009. OMG. Business Process Management Initiative. Disponível em: . Acesso em: 31 ago. 2009. ORATECH Consultoria e Serviços LTDA. Introdução à BPMN. Disponível em: . Acesso em: 10/10/2009. RAISCH, D. S. Os 10 passos para implementação do SOA em Mainframe. Revista PortalBPM. São Paulo, ed. 01, 2007, p. 33-41. REIS, Glauco. Introdução ao BPM, BPMS e SOA. Revista ProtalBPM. São Paulo, ed. 01, 2007, p. 22-29. SILVA, E.L DA e MENEZES, E.M. Metodologia da Pesquisa e elaboração de Dissertação. 4a Ed. UFSC, Florianópolis, 2005. SILVA, Jociane Valdiva da. Uma Abordagem da Implementação de Processos de Negócio Utilizando a Linguagem BPEL. Monografia apresentada ao Curso de especialização em Engenharia de Software na UNISUL, Santa Catarina, 2008. SOFTEX, Sociedade. MPS.BR – Melhoria de Software Brasileiro. Guia Geral. Disponível em: < http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf>. Acesso em: 13/10/2009. TOTVS. Prospecto Definitivo de Distribuição Pública Primária e Secundária de Ações Ordinárias de Emissão da Totvs. Disponível em: Acesso em: 15/04/2010. UGOLINI NETO, Rodolpho. Arquitetura Orientada a Serviços – SOA. Infraestrutura para a Inovação. 2006. Disponível em: Acesso em: 08/03/2010. WHITE, Stephen A. Introduction to BPMN. Disponível em: . Acesso em: 31 ago. 2009. YUNG, Leandro. BPM e Arquitetura Orientada a Serviços. Revista PortalBPM. São Paulo, ed. 01, 2007, p. 43-45. 78 APÊNDICE A – AUTOMATIZAÇÃO DO PROCESSO DE LEVANTAMENTO DE INFORMAÇÕES COM A LINGUAGEM BPEL Neste apêndice será descrito todo o procedimento de automatização com a linguagem BPEL do processo de levantamento de informações da empresa desenvolvedora de software descrita no capítulo anterior. Também serão comentados os principais procedimentos relacionados com a automatização e as dificuldades relativas ao uso da ferramenta Intalio Community. AUTOMATIZAÇÃO DO PROCESSO PROPOSTO O processo de automação inicia com o processo do negócio bem definido, utilizada de base para a automação, será iniciada a ferramenta Intalio Community Designer para dar início a modelagem do processo de levantamento de informações na ferramenta. Com o processo claramente definido, pode-se iniciar a automação deste, e para isto deve-se iniciar um novo projeto através do menu: Arquivo; Novo; Projeto do Processo de Negócio Intalio|BPMS. A Figura a seguir ilustra este procedimento. 79 Figura 2: Novo Projeto Com as configurações padrões, definimos um nome: Modelo. Depois de concluída esta etapa, serão criados os formulários que poderão ser utilizados durante o processo. Estes formulários têm o nome de: início; resposta; e validação. Formulários Os formulários são criado em AJAX (Asynchronus Javascript e XML) e este considera o uso de tecnologias Javascript e XML, providas de navegadores para tornar as páginas Web mais interativas com o usuário. 80 A Figura 3 ilustra como o analista pode dar o primeiro passo para elaborar um questionário e logo o cliente poder responder. Clicando com o botão direito em cima do projeto criado, seleciona-se a opção para a criação de todas as telas, para efeito deste trabalho, o caminho: Nova; Outros; conforme a figura a seguir. Figura 3: Novo Projeto. Esta opção abrirá um ambiente com todas as opções disponíveis para criação. Neste momento inicia-se a criação da tela para o analista poder enviar o questionário ao cliente. Portanto, dentro de Intalio Community Designer tem o AJAX Form, o qual é ilustrado na figura a seguir. 81 Figura 4: Novo AJAX Form Depois de selecionada a opção AJAX Form, é criado o formulário conforme as necessidades. Define-se um nome para ele, onde, neste exemplo, será denominado de iniciar, pois ele será o responsável por dar início ao modelo. Desenha-se um modelo de formulário utilizando-se da paleta IntalioWidgets. A Figura 5, mostra um modelo de formulário que foi elaborado. 82 Figura 5: Modelo do formulário iniciar. Depois deste formulário, montado e organizado, devemos criar o formulário de resposta do cliente para o analista, o que significa que deverá ser criado um novo formulário AJAX, conforme descrito anteriormente. A figura a seguir, mostra um modelo do formulário de resposta. Figura 6: Modelo do formulário responder. 83 Neste formulário também serão definidas algumas regras, como por exemplo, que o cliente não pode alterar o campo: perguntas; pois este é apenas para visualização, porque nele exibido o questionário do analista. Existe ainda a necessidade de se criar mais um formulário, o de validação das informações, onde o analista verificará se as informações são suficientes para finalizar a etapa ou não. A figura a seguir exibe um modelo deste formulário, denominado validar. Figura 7: Modelo do formulário validar. Depois de criarmos estes três formulários em AJAX, será criado outro formulário de formato diferente, a fim de mostrar as possibilidades de utilização da ferramenta. Agora será necessário o formulário para notificar o gerente do processo sobre a finalização de parte ou do processo como um todo. Para isso será utilizado o formulário do Workflow, localizado no mesmo local do formulário AJAX. Sua principal diferença está em que, neste modo de formulário, não é possível fazer a validação do lado do cliente. A Figura 8 ilustra um modelo da tela de notificação. 84 Figura 8: Formulário WorkFlow. Nesta tela não será requisitada, nenhuma informação ao gerente, portanto, será uma tela simples de notificação sobre a finalização do processo. Com os quatro formulários finalizados, continua-se agora o diagrama do processo de negócio, localizado na mesma tela de criação. Esquema XML Será necessário também, criar um esquema XML, responsável por armazenar as variáveis que serão utilizadas durante o processo. Para isso, conforme a Figura 9, é selecionada dentro da caixa de criação, o esquema XML. 85 Figura 9: Criar Esquema XML. Depois de definido um nome e finalizado, serão criadas as variáveis. Neste exemplo consideram-se as variáveis: aprovado; pergunta; e resposta. A Figura 10 ilustra como deverá ser realizada esta denominação de variáveis. 86 Figura 10: Variáveis. Todas as variáveis foram definidas como string e serão trabalhadas da mesma forma durante a execução do processo. Com isto pronto, será desenhado o diagrama do processo de negócio. Diagrama do processo de negócio Depois de tudo criado, será modelado o processo como um todo. Porém para que seja possível analisar melhor, o processo será dividido em duas partes num primeiro momento. A Figura 11 ilustra o modelo do primeiro contato do cliente com o analista. 87 Figura 11: Parte do processo de levantamento de informações Na Figura 11, define-se o processo, desde o analista iniciando o questionário, depois entrando num sub-processo, sendo respondido pelo usuário, e avaliado pelo analista até que seja aprovado pelo mesmo para que saia do sub-processo e notifique o gerente da finalização da primeira etapa. Para que seja possível a criação deste formulário, serão criadas quatro piscinas (Polls), uma para cada participante do processo, no caso, o gerente, o analista, o cliente e o processo em si. Com exceção do processo, os outros três deverão ser “setados” como não executáveis, clicando com o botão direito na piscina, como mostra a figura a seguir. 88 Figura 12: Setar Pool como não executável Com as três piscinas setadas como não executável, elas deverão ficar mais escuras. Pode-se então arrastar o formulário “iniciar” da barra para a piscina do analista e escolher a opção initProcess conforme ilustrado na Figura 41. Nesta monografia serão utilizadas as três primeiras opções: “iniProcess”; “create and complete”; “notify”. A opção “iniProcess”, é utilizada para iniciar um processo. A opção “create and complete”, é utilizada quando existe a necessidade de se obter um retorno do participante através de interação, o processo é parado até que este retorno seja obtido. O “notify”, é utilizado quando não há a necessidade de se obter um retorno do participante, apenas notificá-lo e dar continuidade ao processo. 89 Figura 13: Opções de formulário Para o formulário iniciar, utiliza-se a opção “initProcess”, o formulário responder e validar, será utilizado o “create and complete”, pois será necessário parar o processo até que alguém responda ao formulário. E quanto ao último processo, o de notificação, utiliza-se o notify. A Figura 14 ilustra a opção “initProcess”. Figura 14: Formulário iniciar. A seguir é mostrado como deverão ficar os processos “create and complete” e o “notity”, conforme Figuras 15 e 16 respectivamente. 90 Figura 15: Formulário Responder. 91 Figura 16: Formulário de notificação Para criar uma variável no processo, deve-se arrastar a variável do esquema XML para o diagrama e escolher a opção “Criar uma variável no escopo levantamento”, conforme a figura a seguir. 92 Figura 17: Criar variáveis As variáveis do projeto deverão ficar conforme mostrado a seguir, para que se possa utilizá-las corretamente no decorrer do processo. Figura 18: Ilustração das variáveis Depois de criar todo o processo através do Intalio Community Designer, ele deverá parecer como a Figura 19. Figura 19: Processo de levantamento de informações no Intalio Community Degisn As informações da primeira parte; quando o analista mantém contato com o cliente, finalizada e descrita detalhadamente neste capítulo, serão suficientes para desenhar a segunda, ou seja, o contato com os dirigentes, não sendo necessários maiores detalhes. Com o projeto completamente desenhado, ainda é necessário aprofundar um pouco mais, fazendo o mapeamento das informações, ou seja, como a informação trafegará no mesmo. 93 Para isso, será selecionada a tarefa denominada “setar” e na escolhida a aba “mapeamento”, ilustrado pela Figura 20. Figura 20: Mapeamento do formulário para as variáveis. O mapeamento ocorre da seguinte forma: deve-se definir da onde a informação vem e para onde elas irão, e ainda, de que forma.Sendo possível definir condições se necessário. Trataremos agora da primeira forma do fluxo das informações: do formulário para as variáveis. Na figura anterior, “setamos” as variáveis, de acordo com as necessidades. Por exemplo, a variável pergunta, será setada conforme o que vier do formulário inicial no campo perguntas. As variáveis aprovação, e resposta; foram setadas manualmente, como vazio e não, respectivamente. Desta maneira define-se as variáveis durante o processo. Agora para transmitir esses valores para um formulário, por exemplo, que precisará resgatar estas informações, deve-se mapear conforme a Figura 21. 94 Figura 21: Mapeamento das variáveis para os formulários. Na tarefa criar, na aba mapeamento, será definido que na passagem de parâmetro para o formulário do qual ele faz parte, deverá receber os valores contidos nas variáveis guardadas. Neste caso definimos que o campo pergunta, e o campo resposta, do formulário deverá buscar das variáveis pergunta e resposta respectivamente os valores que serão setados em seus campos no momento da criação do formulário. Entendido como é feita a transmissão de informações dos formulários para as variáveis e das variáveis para o formulário, já é possível modelar todo o processo, precisando apenas detalhar como tratamos o final do sub-processo em loop. Para ficar clara esta parte, a Figura 22 ilustra como deverá ficar um exemplo de condição while do sub-processo. 95 Figura 22: Definindo condições while Com o sub-processo selecionado, e na aba mapeamento, pode-se definir condições para o fim do loop. Neste caso, trata-se de um while (Enquanto condição for verdadeira), então enquanto a variável aprovada estiver setada como “não” o sub-processo deverá permanecer em loop e só sairá, assim que o analista tiver aprovado. Com as informações reunidas até aqui, será possível terminar de desenhar o processo, onde várias informações, apesar de não estarem visíveis na modelagem, estão detalhadas e por isso a orquestração e automação do processo são possíveis. Na próxima seção será ilustrado o processo funcionando através da visão do cliente, analista e do gerente. EXECUÇÃO DOS PROCESSOS Será exibido agora o processo em execução. Para que se possa iniciar, cria-se os usuários, no arquivo “security.xml” dentro da pasta do servidor, em var;config. Segue um exemplo de como foi feito para a execução deste projeto. 96 Figura 23: Configuração do arquivo security.xml Desta maneira foi setado três usuários, o analista, o cliente, e o gerente. Depois disto definido, o acesso ao servidor será através da url: http://ip-servidor:8080/ui-fw com isso, a figura seguinte ilustra como seria a tela apresentada pelo Intalio Community. 97 Figura 24: Tela de login do Intalio Depois de acessado, neste exemplo com o manager (definido como analista neste projeto) será exibida a visão do analista, ilustrada na Figura 25. 98 Figura 25: Tela de processos O Intalio Community trabalha apenas com três abas. A aba de tarefas exibe tarefas de processos, que exigem uma interação para que o processo continue. A de notificações exibe aquelas que não necessitam de uma interação, são apenas de caráter informativo. E por fim, a aba de processos, onde são listados todos os processos em que o seu usuário pode iniciar. Neste modelo, foi definido o título do processo nas suas propriedades, que ele seria apresentado ao usuário como: “Iniciar Questionário”. Selecionando este processo, será possível iniciar aquele que foi modelado e verificar seu funcionamento. A figura a seguir exibe o que acontecerá assim que for selecionado o processo “Iniciar Questionário”. 99 Figura 26: Tela de início do processo O analista preencherá o questionário de acordo com suas necessidades para o levantamento das informações. Assim que ele estiver terminado, iniciará o processo clicando no botão “Start” localizado na parte inferior da janela. Assim que for iniciado o processo, a próxima interação que ocorrerá, será do cliente. Acessa-se a página do ponto de vista do cliente para que seja possível dar continuidade, pois como ele foi definido na sua modelagem como “create and complete”, ele aguarda a interação do cliente para que possa continuar. A figura a seguir mostra como é a visão do cliente, que apesar de ser aparentemente igual ao do analista, é exibida apenas informações referentes ao cliente.Como por exemplo, para o cliente não é possível iniciar esse mesmo processo, pois assim foi definido na modelagem. 100 Figura 27: Tela de tarefas Para o cliente, a aba Tarefas virá preenchida com a requisição do analista. Abrindo a requisição, o cliente se depara com o formulário criado anteriormente e preenchido a parte das perguntas pelo analista. A próxima figura mostra como o cliente pode responder, e clicando em complete, terminar sua interação, possibilitando ao sistema dar continuidade ao processo baseado nas informações obtidas pelo formulário. 101 Figura 28: Tela de resposta Depois desta interação, o processo leva estas informações para o analista, que responderá se finalizará ou não o processo, escrevendo novas perguntas para o cliente ou indo para o próximo passo no processo. A Figura 29 ilustra o processo de decisão do analista. 102 Figura 29: Tela de validação Tendo o analista escolhido o processo como aprovado para a próxima etapa, o gerente é imediatamente notificado, e um sub-processo semelhante ao detalhado neste trabalho é iniciado. Uma ilustração da tela de notificação criada pelo sistema automaticamente e enviada para o gerente é exibida na figura a seguir. 103 Figura 30: Tela de notificação Assim que notificado, o gerente pode escolher excluir esta notificação de seu painel de notificações clicando no botão “Dismiss”. Com isso, basicamente todo o processo foi explicado em telas detalhadas. A partir de então, o processo poderá ser mais facilmente visualizado pelos responsáveis, e otimizado sem a necessidade de se escrever nem uma linha de código. Agilizando o processo de alinhamento com os objetivos do negócio. 104 ANEXO A – DIAGRAMA DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Diagrama do processo de desenvolvimento de Software BizAgi Process Modeler 105 Índice 1  DIAGRAMA 1 ................................................................................................................. 109  1.1  PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ........................................ 109  1.1.1  Elementos do processo .............................................................................................. 110  1.1.1.1 Análise ...................................................................................................................... 110 1.1.1.2 Codificação ............................................................................................................... 110 1.1.1.3 Implantação .............................................................................................................. 110 1.1.1.4 Produção ................................................................................................................... 111 1.1.1.5 Testes 110 1.2  ANÁLISE ...................................................................................................................... 111  1.2.1  Elementos do processo .............................................................................................. 111  1.2.1.1 Levantamento de informações .................................................................................. 111 1.2.1.2 Desenho do processo ................................................................................................ 111 1.2.1.3 Modelagem de dados ................................................................................................ 112 1.2.1.4 Modelagem do sistema ............................................................................................. 112 1.2.1.5 Prototipação .............................................................................................................. 112 1.2.1.6 Definições finais ....................................................................................................... 112 1.3  LEVANTAMENTO DE INFORMAÇÕES .................................................................. 113  1.3.1  Elementos do processo .............................................................................................. 113 1.3.1.1 Entrevista com usuários ............................................................................................ 113 1.3.1.2 Formatação de informações ...................................................................................... 113 1.3.1.3 Apresentação das Informações ................................................................................ 114 1.3.1.4 Entrevista com Dirigentes ....................................................................................... 114 1.3.1.5 Apresentação das informações ................................................................................. 114 1.3.1.6 Consolidação das informações ................................................................................. 114 1.4  DESENHO DO PROCESSO ......................................................................................... 114  1.4.1  Elementos do processo .............................................................................................. 115  1.4.1.2 Diagramação do processo de Negócio BPMN ......................................................... 115 1.4.1.1 Apresentação do diagrama aos usuários ................................................................... 115 1.5  MODELAGEM DE DADOS ........................................................................................ 115  1.5.1  Elementos do processo .............................................................................................. 116  1.5.1.1 Criação/manu-tenção do modelo físico .................................................................... 116 1.5.1.2 Criação/manu-tenção do modelo lógico ................................................................... 116 106 1.5.1.3 Apresentação dos modelos ao DBA ......................................................................... 116 1.5.1.4 Geração do script do Banco de Dados ...................................................................... 116 1.6  MODELAGEM DO SISTEMA ..................................................................................... 116  1.6.1  Elementos do processo .............................................................................................. 117 1.6.1.1 Criação dos DFD's .................................................................................................... 117 1.6.1.2 Descrição gráfica dos formulários e funções ............................................................ 117 1.6.1.3 Criação dos DCS ..................................................................................................... 117 1.6.1.4 Descrição gráfica das classes e componentes ........................................................... 117 1.6.1.5 Apresentação aos usuários ........................................................................................ 117 1.6.1.6 Geração do script do Banco de Dados ...................................................................... 117 1.7  DEFINIÇÕES FINAIS .................................................................................................. 119  1.7.1  Elementos do processo .............................................................................................. 119  1.7.1.1 Apresentação de relatórios a Diretoria ..................................................................... 120 1.7.1.2 Definição de equipe e recursos ................................................................................. 120 1.7.1.3 Desenvolver cronograma de execução ..................................................................... 120 1.7.1.4 Desenvolver planilha de custo .................................................................................. 120 1.7.1.5 Revisão do relatório .................................................................................................. 120 1.8  PROTOTIPAÇÃO ......................................................................................................... 118  1.8.1  Elementos do processo .............................................................................................. 118  1.8.1.1 Apresentação aos usuários ........................................................................................ 118 1.8.1.2 Criação/manu-tenção dos modelos de telas/relatórios ............................................ 118 1.9  CODIFICAÇÃO ............................................................................................................ 120  1.9.1  Elementos do processo .............................................................................................. 121  1.9.1.1 Preparar ambiente ..................................................................................................... 122 1.9.1.2 Escrever código ........................................................................................................ 122 1.10  ESCREVER CÓDIGO ................................................................................................... 123  1.10.1  Elementos do processo .............................................................................................. 123  1.10.1.1 Escrever código ........................................................................................................ 123 1.11  PREPARAR AMBIENTE ............................................................................................. 122  1.11.1  Elementos do processo .............................................................................................. 122  1.11.1.1 Instalação de hardware ............................................................................................. 122 1.11.1.2 Instalação de software .............................................................................................. 122 1.11.1.3 Testes de ambiente ................................................................................................... 122 107 1.12  TESTES ......................................................................................................................... 123  1.12.1  Elementos do processo .............................................................................................. 124  1.12.1.1 Teste de bancada ....................................................................................................... 124 1.12.1.2 Teste de qualidade .................................................................................................... 124 1.12.1.3 Teste de stress ........................................................................................................... 124 1.12.1.4 Teste de segurança .................................................................................................... 124 1.12.1.5 Homologação ............................................................................................................ 124 1.13  TESTE DE QUALIDADE ............................................................................................. 125  1.13.1  Elementos do processo .............................................................................................. 126  1.13.1.1 Instalação de hardware ............................................................................................. 126 1.13.1.2 Instalação de software .............................................................................................. 126 1.13.1.3 Testes de ambiente ................................................................................................... 126 1.13.1.4 Efetuar monkey test .................................................................................................. 126 1.14  TESTE DE SEGURANÇA ............................................................................................ 128  1.14.1  Elementos do processo .............................................................................................. 128  1.14.1.1 Efetuar teste de segurança ........................................................................................ 128 1.15  TESTE DE BANCADA ................................................................................................ 124  1.15.1  Elementos do processo .............................................................................................. 125  1.15.1.1 efetuar teste de bancada ............................................................................................ 125 1.16  HOMOLOGAÇÃO ........................................................................................................ 129  1.16.1  Elementos do processo .............................................................................................. 129  1.16.1.1 Efetuar homologação ................................................................................................ 129 1.17  TESTE DE STRESS ...................................................................................................... 127  1.17.1  Elementos do processo .............................................................................................. 127  1.17.1.1 Avaliação de resposta do hardware e software ......................................................... 127 1.17.1.2 Preparação da simulação de teste ............................................................................. 127 1.17.1.3 Teste maciço da aplicação ........................................................................................ 127 1.17.1.4 Análise da avaliação ................................................................................................. 127 1.18  IMPLANTAÇÃO .......................................................................................................... 130  1.18.1  Elementos do processo .............................................................................................. 130  1.18.1.1 Migração de Dados ................................................................................................... 130 1.18.1.2 Trabalho em paralelo ................................................................................................ 130 1.18.1.3 Treinamento para usuários ....................................................................................... 130 108 1.19  TREINAMENTO PARA USUÁRIOS .......................................................................... 131  1.19.1  Elementos do processo .............................................................................................. 131  1.19.1.1 Curso prático de administração ................................................................................ 131 1.19.1.2 Curso prático de operação ........................................................................................ 131 1.20  MIGRAÇÃO DE DADOS ............................................................................................. 132  1.20.1  Elementos do processo .............................................................................................. 132  1.20.1.1 Migrar dados ............................................................................................................. 132 1.21  TRABALHO EM PARALELO ..................................................................................... 133  1.21.1  Elementos do processo .............................................................................................. 133  1.21.1.3 Operar o sistema ....................................................................................................... 133 1.21.1.1 Analisar resultados ................................................................................................... 133 1.21.1.2 Homologação final do sistema ................................................................................. 133 1.22  PRODUÇÃO .................................................................................................................. 134  1.22.1  Elementos do processo .............................................................................................. 134  1.22.1.1 Estabelecer rotina de produção ................................................................................. 135 1.22.1.2 Analisar LOG's de produção .................................................................................... 135 1.22.1.3 Elaborar relatório de análise de performance ........................................................... 135 109 1 DIAGRAMA 1 Versão: 1.0 Autor: Paulo Oliver 1 . 1 P R O C E S S O D E D E S E N V O L V I M E N T O D E S O F T W A R E Saindo do caos Não é raro em ambientes de desenvolvimento que muitos desenvolvedores sejam envolvidos em múltiplos projetos simultaneamente. Assim sendo ao mesmo tempo em que um desenvolvedor desenvolve dois softwares, está também corrigindo bugs de outros dois, dificultando desta forma o trabalho do desenvolvedor. As tarefas de desenvolvimento, quer sejam elas de criação de novos softwares ou de manutenção dos softwares existentes, devem ser divididas em projetos e cada projeto deve seguir uma seqüência de execução que garanta a qualidade do software que está sendo gerado. Equipes Envolvidas As seguintes equipes devem ser delineadas e envolvidas no processo de desenvolvimento : Desenvolvimento Testers Homologação Banco de Dados Suporte Produção Divisões do Processo de Desenvolvimento Análise Codificação Testes Implantação Produção 110 1.1.1 ELEMENTOS DO PROCESSO 1.1.1.1 Análise A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade. Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa freqüentemente falhas na definição do software, ou seja, descobre- se após o desenvolvimento que o que foi feito não atende a necessidade existente. 1.1.1.2 Codificação A etapa de codificação envolve o desenvolvimento em si do projeto Testes Os testes se dividem em 5 tipos : Teste de bancada Teste de qualidade Teste de Stress Teste de Segurança Homologação Destes 3 tipos apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade. 1.1.1.3 Implantação Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas: Treinamento para os usuários. Trabalho em paralelo com aplicações existentes quando necessário. Migração de dados de bancos de dados existentes quando necessário. Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho nesta etapa torna-se bem planejado e organizado, menos sujeito a falhas. 111 1.1.1.4 Produção A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um sub-conjunto da equipe de suporte. Eis algumas tarefas da equipe de produção : Fornecer suporte ao uso da aplicação Inspecionar logs de eventos gerados pela aplicação identificando possíveis problemas em produção Montar uma linha base de performance para a aplicação Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa. Apontar para a equipe de desenvolvimento problemas de performance na aplicação 1 . 2 A N Á L I S E 1.2.1 ELEMENTOS DO PROCESSO 1.2.1.1 Levantamento de informações 1.2.1.2 Desenho do processo 112 1.2.1.3 Modelagem de dados 1.2.1.4 Modelagem do sistema 1.2.1.5 Prototipação 1.2.1.6 Definições finais Curiosidades sobre a etapa de análise A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer, se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema. O analista é em geral um ex-desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma língua destes, podendo desta forma extrair informações durante o levantamento. Como ex-desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto 113 1 . 3 L E V A N T A M E N T O D E I N F O R M A Ç Õ E S Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes. O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando. O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc.). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa. Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação. 1.3.1 ELEMENTOS DO PROCESSO 1.3.1.1 Entrevista com usuários 1.3.1.2 Formatação de informações 114 1.3.1.3 Apresentação das Informações 1.3.1.4 Entrevista com Dirigentes 1.3.1.5 Consolidação das informações 1.3.1.6 Apresentação das informações 1 . 4 D E S E N H O D O P R O C E S S O O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acertá-los e assim consecutivamente até que o usuário aprove o desenho de processo 115 1.4.1 ELEMENTOS DO PROCESSO 1.4.1.1 Diagramação do processo de Negócio BPMN 1.4.1.2 Apresentação do diagrama aos usuários 1 . 5 M O D E L A G E M D E D A D O S Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento. O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresentá-lo ou não ao usuário pode ser uma decisão do analista. O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados. O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados. Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco 116 Toda futura alteração do modelo de dados deve ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma seqüência histórica de mudanças realizadas no banco de dados. 1.5.1 ELEMENTOS DO PROCESSO 1.5.1.1 Criação/manutenção do modelo lógico 1.5.1.2 Criação/manutenção do modelo físico 1.5.1.3 Apresentação dos modelos ao DBA 1.5.1.4 Geração do script do Banco de Dados 1 . 6 M O D E L A G E M D O S I S T E M A Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequence, típicos da análise orientada a objetos. 117 Obtem-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto. Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento. É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 1.6.1 ELEMENTOS DO PROCESSO 1.6.1.1 Criação dos DFD's 1.6.1.2 Descrição gráfica dos formulários e funções 1.6.1.3 Criação dos DCS 1.6.1.4 Descrição gráfica das classes e componentes 1.6.1.5 Apresentação aos usuários 1.6.1.6 Geração do script do Banco de Dados 118 1 . 7 P R O T O T I P A Ç Ã O Feita a modelagem do sistema parte-se então para a construção do protótipo. O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas. 1.7.1 ELEMENTOS DO PROCESSO 1.7.1.1 Criação/manutenção dos modelos de telas/relatórios 1.7.1.2 Apresentação aos usuários 119 1 . 8 D E F I N I Ç Õ E S F I N A I S Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluída em sua etapa mais formal. Da fase de análise obtem-se definições sobre como serão as fases seguintes : A partir das definições de análise é possível desenvolver um cronograma de execução A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores) A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade. 1.8.1 ELEMENTOS DO PROCESSO 120 1.8.1.1 Desenvolver cronograma de execução 1.8.1.2 Definição de equipe e recursos 1.8.1.3 Desenvolver planilha de custo 1.8.1.4 Apresentação de relatórios a Diretoria 1.8.1.5 Revisão do relatório 1 . 9 C O D I F I C A Ç Ã O A etapa de codificação envolve o desenvolvimento em si do projeto Ambiente de codificação Os desenvolvedores devem possuir um ambiente apartado no qual tenham total controle de forma a poderem rapidamente resolver problemas nas máquinas. A equipe de suporte deve dar total apoio aos desenvolvedores, tal como em termos de instalação das máquinas, backup e solução rápida de problemas que sejam exclusivamente de infraestrutura. Deve também procurar, junto com o analista, as melhores técnicas de otimização do ambiente de codificação. Deve estar em uso um sistema de controle de versões no ambiente de desenvolvimento, tal como o Microsoft Visual Source Safe Ocorrências comuns no ambiente de codificação Alterações no modelo de dados Devem ser aprovadas pela equipe de banco de dados e deve ser gerado um script evolutivo que será armazenado juntamente com script 0 do banco de dados Alterações no protótipo Devem ser aprovadas pelo usuário Alterações na modelagem do sistema Alterações no desenho do processo 121 Essas duas últimas podem ter impacto médio a grande no desenvolvimento do sistema. É importante verificar se é realmente absolutamente necessário que essas modificações sejam feitas ou se seria possível que essas modificações fossem implementadas apenas em uma versão 2 do sistema. Caso seja absolutamente necessária a realização destas modificações o cronograma do sistema deve ser corrigido com base no impacto destas mudanças. Normalmente mudanças deste porte causam as outras 2, alteração de protótipo e de modelo de dados O trabalho do analista O analista aproveita o período de desenvolvimento, no qual seu trabalho fica mais direcionado à gerencia de projeto, para realizar as seguintes tarefas : Criar um plano de testes para a aplicação Realizar o “teste de bancada”, teste inicial ainda em ambiente de desenvolvimento, conforme os desenvolvedores terminam cada trecho da aplicação Planejar o teste de stress em conjunto com a equipe de suporte Planejar o processo de implantação da aplicação em conjunto com a equipe de suporte e banco de dados Cronograma e desempenho Uma técnica muito útil para a análise de tempo gasto em desenvolvimento é a análise de pontos de função. Esta análise intenciona quantificar o software que está sendo desenvolvido em pontos de função e identificar a produtividade dos desenvolvedores também em pontos de função/dia. Com isso consegue-se : Identificar os desenvolvedores muito e pouco produtivos Montar cronogramas mais precisos com base na produtividade real dos desenvolvedores Identificar a necessidade de mais desenvolvedores para cumprir um determinado prazo Identificar mais precisamente os custos do projeto A análise de ponto de função é muito detalhista e normalmente demanda tempo na etapa de análise, por isso é muito comum as empresas criarem pequenas adaptações desta análise conforme a arquitetura utilizada. 1.9.1 ELEMENTOS DO PROCESSO 122 1.9.1.1 Preparar ambiente 1.9.1.2 Escrever código 1 . 1 0 P R E P A R A R A M B I E N T E 1.10.1 ELEMENTOS DO PROCESSO 1.10.1.1 Instalação de hardware 1.10.1.2 Instalação de software 1.10.1.3 Testes de ambiente 123 1 . 1 1 E S C R E V E R C Ó D I G O 1.11.1 ELEMENTOS DO PROCESSO 1.11.1.1 Escrever código 1 . 1 2 T E S T E S Os testes se dividem em 5 tipos : Teste de bancada Teste de qualidade Teste de Stress Teste de Segurança Homologação 124 1.12.1 ELEMENTOS DO PROCESSO 1.12.1.1 Teste de bancada 1.12.1.2 Teste de qualidade 1.12.1.3 Teste de stress 1.12.1.4 Teste de segurança 1.12.1.5 Homologação 1 . 1 3 T E S T E D E B A N C A D A Destes 5 tipos apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade. 125 1.13.1 ELEMENTOS DO PROCESSO 1.13.1.1 Efetuar teste de bancada 1 . 1 4 T E S T E D E Q U A L I D A D E Ambiente de Qualidade O ambiente de qualidade é um ambiente o mais similar possível ao ambiente de produção da empresa. Este ambiente é utilizado para a realização de testes de qualidade na aplicação Raramente, porém, é possível ter um ambiente de qualidade realmente idêntico ao de produção. Cabe à equipe de suporte juntamente com o analista/arquiteto do sistema realizar um relatório de riscos relativo a passagem da aplicação para produção, ou seja, o risco de mesmo depois dos testes em qualidade a passagem para produção não funcionar devido a diferença entre qualidade e produção Montagem do ambiente de qualidade A montagem do ambiente de qualidade é, de fato, um teste : Testa-se o passo- a-passo de instalação do sistema, garantindo que o processo de instalação funcionará quando for executado em ambiente de produção Teste de Qualidade O teste de qualidade é, de todos, o teste mais detalhado do sistema. É realizado por testers, profissionais especializados na realização de testes da aplicação. Os testers podem fazer uso do plano de testes criado pelo analista, mas não se prendem a ele. O objetivo principal dos testers é fazer o que é chamado de monkey test : Fazer exatamente o contrário do que a aplicação pede em cada tela e verificar 126 como a aplicação reage. Desta forma obtem-se a garantia de que a aplicação funcionará mesmo perante os piores tipos de usuário existentes. Os testers em geral são desenvolvedores, mas não precisam ser tão especializados como os próprios desenvolvedores do projeto. Em alguns casos podem ser outra equipe de desenvolvimento da própria empresa, mas não devem ser os mesmos desenvolvedores do projeto, pois por mais que tentem os desenvolvedores do projeto sempre fazem testes para fazer a aplicação funcionar, ao contrário de testers que devem fazer a aplicação dar erro Há um trabalho circular entre os testers e o processo de codificação. Os testers devem gerar um relatório de volta para o processo de codificação, gerando uma re- implantação da aplicação em qualidade e novo teste até o momento em que os testers não identifiquem nenhum erro 1.14.1 ELEMENTOS DO PROCESSO 1.14.1.1 Instalação de hardware 1.14.1.2 Instalação de software 1.14.1.3 Testes de ambiente 1.14.1.4 Efetuar monkey test 127 1 . 1 5 T E S T E D E S T R E S S Teste de Stress O teste de stress tem por objetivo testar a aplicação em condições de uso muito maciço, verificando como o hardware e o software respondem em ambiente simulado. O teste envolve tanto o analista/arquiteto, responsável por especificar a simulação de teste, como a equipe de banco, responsável pela análise da resposta do servidor de banco ao teste como a equipe de suporte, responsável pela análise da resposta do hardware e do sistema operacional. 1.15.1 ELEMENTOS DO PROCESSO 1.15.1.1 Preparação da simulação de teste 1.15.1.2 Teste maciço da aplicação 1.15.1.3 Avaliação de resposta do hardware e software 1.15.1.4 Análise da avaliação 128 1 . 1 6 T E S T E D E S E G U R A N Ç A Teste de Segurança Em geral é realizado por uma equipe externa de hackers contratados especialmente para testar a segurança do sistema, este teste tem se tornado comum nas atuais arquiteturas de desenvolvimento para web. 1.16.1 ELEMENTOS DO PROCESSO 1.16.1.1 Efetuar teste de segurança 129 1 . 1 7 H O M O L O G A Ç Ã O Homologação É o teste realizado pelos usuários finais, que podem ou não seguir o plano de testes preparado pelo analista O processo de homologação pode gerar um trabalho circular com a etapa de codificação, assim como ocorreu com o teste de qualidade, mas é mais improvável que o processo de homologação encontre muitas falhas no sistema O usuário vai, como sempre, pedir modificações no sistema. Porém o analista deve ser cuidadoso de direcionar as modificações solicitadas pelo usuário para a próxima versão do sistema. Ao final da homologação o usuário dá sua aprovação final para o sistema 1.17.1 ELEMENTOS DO PROCESSO 1.17.1.1 Efetuar homologação 130 1 . 1 8 I M P L A N T A Ç Ã O Implantação Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas : Treinamento para os usuários Trabalho em paralelo com aplicações existentes quando necessário Migração de dados de bancos de dados existentes quando necessário Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho nesta etapa torna-se bem planejado e organizado, menos sujeito a falhas 1.18.1 ELEMENTOS DO PROCESSO 1.18.1.1 Treinamento para usuários 1.18.1.2 Trabalho em paralelo 1.18.1.3 Migração de Dados 131 1 . 1 9 T R E I N A M E N T O P A R A U S U Á R I O S 1.19.1 ELEMENTOS DO PROCESSO 1.19.1.1 Curso prático de administração 1.19.1.2 Curso prático de operação 132 1 . 2 0 M I G R A Ç Ã O D E D A D O S 1.20.1 ELEMENTOS DO PROCESSO 1.20.1.1 Migrar dados 133 1 . 2 1 T R A B A L H O E M P A R A L E L O 1.21.1 ELEMENTOS DO PROCESSO 1.21.1.1 Operar o sistema 1.21.1.2 Analisar resultados 1.21.1.3 Homologação final do sistema 134 1 . 2 2 P R O D U Ç Ã O Produção A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um sub-conjunto da equipe de suporte. Eis algumas tarefas da equipe de produção : Fornecer suporte ao uso da aplicação Inspecionar logs de eventos gerados pela aplicação identificando possíveis problemas em produção Montar uma linha base de performance para a aplicação Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa. Apontar para a equipe de desenvolvimento problemas de performance na aplicação 1.22.1 ELEMENTOS DO PROCESSO 135 1.22.1.1 Estabelecer rotina de produção 1.22.1.2 Elaborar relatório de análise de performance 1.22.1.3 Analisar LOG's de produção Possíveis rupturas no processo Mesmo muito bem organizado da forma como aqui foi descrita, podem ocorrer rupturas nesse processo de desenvolvimento que causarão problemas de custo e cronograma : Excesso de alterações na especificação durante a etapa de codificação Excesso de erros em homologação ou produção Dificuldade na comunicação entre o analista e os desenvolvedores Cronogramas imprecisos Excesso de alterações na especificação durante a codificação Isso pode ser causado por uma inicial inexperiência de um analista. Deve-se registrar este fato como um índice qualitativo do processo de desenvolvimento e o analista deve utilizar cada ocorrência para aperfeiçoar-se, reduzindo este valor a cada projeto realizado Excesso de erros em homologação ou produção Isso ocorre por inexperiência dos testers, responsáveis por identificar os erros da aplicação. Da mesma forma que o item anterior, isso deve ser registrado como um fator qualitativo do processo e os testers devem utilizar cada ocorrência para aperfeiçoar-se e reduzir este valor Dificuldade na comunicação entre o analista e os desenvolvedores Uma das rupturas mais críticas, quando o analista, por estar muito envolvido com o negócio, passa a ter dificuldade de se comunicar com o desenvolvedor e suas especificações se tornam mais distantes do ambiente físico da codificação. Neste caso torna-se necessária a utilização de um arquiteto de sistemas como intermediário entre o analista e o desenvolvedor. Deve-se tomar muito cuidado na escolha de quem irá realizar esse papel, pois a pessoa deve ser capaz de utilizar a linguagem de negócio e traduzi-la para os desenvolvedores, tendo liberdade de requisitar alterações nas especificações quando estas estiverem por demais distantes do ambiente físico. Essa pessoa deve estar altamente atualizada para definir as melhores tecnologias para cada projeto. Cronogramas imprecisos 136 Isso normalmente reflete uma inexperiência do analista na especificação do tempo para desenvolvimento. Neste ponto duas coisas devem ocorrer : O analista deve usar as falhas de cronograma para aperfeiçoar-se em termos de calculo de duração de um projeto Deve-se aperfeiçoar a aplicação da técnica de análise de pontos de função de forma a depender o mínimo possível do instinto do analista