UNIVERSIDADE DO SUL DE SANTA CATARINA JHONATAS VICENTE DE JESUS VANUSA LUEDKE

DESENVOLVIMENTO DE UM SISTEMA DE GERENCIAMENTO DE PROCESSOS VISANDO APLICAR ESTRATGIAS DE NEGCIO

Palhoa 2011

JHONATAS VICENTE DE JESUS VANUSA LUEDKE

DESENVOLVIMENTO DE UM SISTEMA DE GERENCIAMENTO DE PROCESSOS VISANDO APLICAR ESTRATGIAS DE NEGCIO

Trabalho de Concluso de Curso apresentado ao Curso de Graduao em Sistema de Informao da Universidade do Sul de Santa Catarina, como requisito parcial obteno do ttulo de Bacharel em Sistemas de Informao.

Orientador: Prof. Dr. Ricardo Villarroel Dvalos.

Palhoa 2011

JHONATAS VICENTE DE JESUS VANUSA LUEDKE

DESENVOLVIMENTO DE UM SISTEMA DE GERENCIAMENTO DE PROCESSOS VISANDO APLICAR ESTRATGIAS DE NEGCIO

Este Trabalho de Concluso de Curso foi julgado adequado obteno do ttulo de Bacharel em Sistema de Informao e aprovado em sua forma final pelo Curso de Graduao em Sistema de Informao da Universidade do Sul de Santa Catarina.

Palhoa, 3 de Novembro de 2011.

______________________________________________________ Professor e orientador Ricardo Villarroel Dvalos, Dr. Universidade do Sul de Santa Catarina ______________________________________________________ Prof. Flavio Ceci, M.Eng. Universidade do Sul de Santa Catarina ______________________________________________________ Mrcio Welter, PMP Assembleia Legislativa de Santa Catarina

Agradeo a Deus por ter me dado foras at aqui. Aos meus pais e meu irmo que sempre me apoiaram e incentivaram nos meus estudos e a minha esposa que nos momentos difceis esteve comigo me motivando a continuar. Agradeo tambm aos meus amigos, que tiveram que suportar esse perodo final de concluso do curso. Jhonatas Vicente de Jesus

Aos meus pais e irmos que sempre me motivaram e incentivaram nos meus estudos e que tiveram o tempo todo do meu lado. Ao meu namorado por estar presente nas horas boas e ruins e me dando apoio para no desanimar. E aos meus amigos que me incentivaram e me deram muita fora pra continuar e concluir este curso. Vanusa Luedke

AGRADECIMENTO

Primeiramente agradecemos a DEUS por ter nos concebido a oportunidade do nosso crescimento profissional e pessoal. Agradecemos tambm a todos os professores do curso de Bacharelado em Sistemas de Informao da Universidade do Sul de Santa Catarina na ajuda prestada ao longo do curso, em especial ao Prof Dr. Eng. Ricardo Villarroel Dvalos por ter nos orientado neste trabalho. Agradecemos em especial a nossos familiares e a todos os nossos amigos que nos apoiaram e estiveram do lado durante os momentos mais importantes de nossas vidas. Fazendo assim com que consegussemos concluir esta faculdade e na realizao deste trabalho.

"Aprendi atravs da experincia amarga a suprema lio: nossa ira controlada pode ser convertida em uma fora capaz de mover o mundo." (Mahatma Gandhi)

RESUMO

As organizaes necessitam cada vez mais de uma viso integrada de seus processos, pessoas e tecnologias, bem como maior confiabilidade, agilidade e eficincia na prestao de seus servios. Para nortear o cumprimento desses objetivos a proposta do presente projeto consiste em desenvolver um sistema para gerenciamento de processos de negcio (BPMS - Business Process Management Systems) visando agregar valor aos processos por meio de motores de regras de negcio. O sistema de gerenciamento de processos de negcio uma ferramenta para automatizao com enfoque na execuo, controle e monitoramento de processos de negcio das organizaes. O sistema desenvolvido tem como principal caracterstica ser totalmente Web , contemplando o ciclo que vai desde o desenho do processo, criao de formulrios, definio de regras de negcio at a execuo dos mesmos pelos usurios finais. O projeto se iniciou por meio da pesquisa de alguns softwares BPMS de mercado, identificando nestes os pontos fracos e oportunidades de melhoria, focando principalmente na forma como aqueles tratavam a definio e execuo de processos, bem como regras de negcio eram geridas pelos mesmos. Depois de estudos nesta rea e percebendo alguns pontos de melhorias, foram levantados os requisitos necessrios e efetuada anlise de ferramentas tecnolgicas para o desenvolvimento do sistema. Para o projeto foi utilizada a linguagem Java juntamente com os frameworks jBPM como motor de processos, Drools como motor de regras de negcio e Flex para interface. Por meio do projeto em questo, pde-se constatar a facilidade de criao e melhoria de um processo, no qual rapidamente um processo pode ser criado expressando formulrios, caminhos, regras, participantes e responsabilidades com rapidez. O presente projeto contribui tambm para que as organizaes consigam ter maior facilidade de responder s mudanas, ganhem em velocidade, agilidade e qualidade possibilitando uma melhora significativa no rendimento do negcio.

Palavras-chave: Automao de Processos, Regras de Negcio, Gerenciamento de Processos de Negcio.

LISTA DE ILUSTRAES

Figura 1 Os dois grupos de conhecimentos que sustentam o conceito BPM. ...................... 24 Figura 2 Ciclo de vida BPM. ............................................................................................. 25 Figura 3 Diagrama de Coreografia. ................................................................................... 31 Figura 4 Diagrama de Comunicao.................................................................................. 32 Figura 5 Arquitetura BPMS............................................................................................... 37 Figura 6 Framework dos componentes da soluo tecnolgica BPMS............................... 38 Figura 7 Distribuio das Informaes em SOA. ............................................................... 51 Figura 8 Arquitetura jBPM................................................................................................ 55 Figura 9 Etapas metodolgicas. ......................................................................................... 61 Figura 10 Mdulos do sistema BPMS. ............................................................................. 62 Figura 11 Proposta Ambiente administrativo Elaborao de processos. ...................... 63 Figura 12 Proposta Portal do usurio. ............................................................................ 64 Figura 13 Arquitetura Tecnolgica. .................................................................................. 65 Figura 14 Modelagem do Processo de Negcio do Administrador. ................................... 68 Figura 15 Modelagem do Processo de Negcio do Usurio .............................................. 68 Figura 16 Diagrama de Caso de Uso Mdulo Administrador. ......................................... 74 Figura 17 Diagrama de Caso de Uso Mdulo Usurio. ................................................... 75 Figura 18 Diagrama de Atividade do Caso de Uso CSU05 Administrador. ..................... 83 Figura 19 Diagrama de Atividade do Caso de Uso CSU09 Administrador. ..................... 84 Figura 20 Diagrama de Atividade do Caso de Uso CSU03 - Administrador....................... 85 Figura 21 Diagrama de Atividade do Caso de Uso CSU08 Administrador. ..................... 86 Figura 22 Diagrama de Atividade do Caso de Uso CSU01 Usurio. ............................... 87 Figura 23 Diagrama de Atividade do Caso de Uso CSU05 Usurio. ............................... 88 Figura 24 Diagrama de Atividade do Caso de Uso CSU04 Usurio. ............................... 89 Figura 25 Diagrama de Atividade do Caso de Uso CS004 Usurio. ................................ 90 Figura 26 Exemplo de modelo de dados utilizado no sistema. ........................................... 91 Figura 27 Ferramentas utilizadas. ...................................................................................... 92 Figura 28 Arquitetura JBoss Application Server. ............................................................... 97 Figura 29 Processo do desenvolvimento.......................................................................... 101 Figura 30 Modelo no suportado pelo motor de processos............................................... 104 Figura 31 Soluo para o problema da deciso 1. ............................................................ 105 Figura 32 Soluo para o problema da deciso 2. ............................................................ 105 Figura 33 Modelo BPMN em formato XML gerado pelo motor de processos. ................. 106 Figura 34 Modelo no suportado pelo motor de processos............................................... 106 Figura 35 Soluo para o problema do evento de fim. ..................................................... 107 Figura 36 Exemplo de expresso utilizada com o Drools................................................. 107 Figura 37 Parte do cdigo utilizado no projeto para definio de regras........................... 108 Figura 38 Login sistema. ................................................................................................. 115 Figura 39 Funcionalidades do sistema Perfil administrador. ......................................... 115 Figura 40 Consulta de processos. .................................................................................... 116 Figura 41 Cadastro do processo....................................................................................... 117 Figura 42 Processo atual.................................................................................................. 117 Figura 43 Modelagem do processo. ................................................................................. 118 Figura 44 Elementos do desenho do processo.................................................................. 118 Figura 45 Desenho do processo. ...................................................................................... 119 Figura 46 Aba Formulrio e Dados. ............................................................................. 119

Figura 47 Seleo de tarefa. ............................................................................................ 120 Figura 48 Cadastro de dados. .......................................................................................... 120 Figura 49 Apresentao dos dados do processo. .............................................................. 121 Figura 50 Nome do formulrio. ....................................................................................... 121 Figura 51 Definio do formulrio. ................................................................................. 121 Figura 52 Definio das regras de navegao. ................................................................. 122 Figura 53 Regras de navegao. ...................................................................................... 122 Figura 54 Edio das regras de navegao....................................................................... 123 Figura 55 Definio das regras de negcio. ..................................................................... 124 Figura 56 Regras de negcio. .......................................................................................... 124 Figura 57 Edio das regras de negcio........................................................................... 125 Figura 58 Apresentao do local que esta sendo inserido a regras de negcio. ................. 125 Figura 59 Apresentao das regras inseridas.................................................................... 126 Figura 60 Associar participante a tarefa do processo........................................................ 127 Figura 61 Participantes do processo................................................................................. 127 Figura 62 Usurios cadastrados para associar a tarefa...................................................... 128 Figura 63 Usurios participantes da tarefa do processo.................................................... 128 Figura 64 Administrao de usurios............................................................................... 129 Figura 65 Apresentao dos usurios cadastrados............................................................ 129 Figura 66 Adicionar novo usurio. .................................................................................. 130 Figura 67 Processo de ativar e inativar usurios............................................................... 131 Figura 68 Opo para execuo das tarefas associadas. Opo Processo.......................... 132 Figura 69 Apresentao da tela onde sero gerenciadas suas tarefas. ............................... 132 Figura 70 Processos cadastrados no nome de determinado usurio. ................................. 133 Figura 71 Tarefas cadastradas de determinado processo. ................................................. 133 Figura 72 Edio de determinada tarefa........................................................................... 134 Figura 73 Histrico da tarefa selecionada. ....................................................................... 134 Figura 74 Tela inicial, exibindo inicialmente todos os processos cadastrados. ................. 138 Figura 75 Informaes bsicas do processo Gerenciamento de Incidentes. ................... 139 Figura 76 Processo corrente. ........................................................................................... 139 Figura 77 Modelagem do processo. ................................................................................. 140 Figura 78 Tela em que sero apresentados os dados, e local onde se cadastram. .............. 140 Figura 79 Tela do cadastro de dados................................................................................ 141 Figura 80 Apresentao dos dados. ................................................................................. 141 Figura 81 Preenchimento do formulrio. ......................................................................... 142 Figura 82 Seleo de tarefa associada.............................................................................. 142 Figura 83 Apresentao das regras de navegao............................................................. 143 Figura 84 Cadastro das regras de navegao.................................................................... 144 Figura 85 Apresentao das regras de negcio................................................................. 145 Figura 86 Cadastro das regras de negcio........................................................................ 146 Figura 87 Apresentao das regras cadastradas................................................................ 146 Figura 88 Associar participante a tarefa do processo........................................................ 147 Figura 89 Tela de gerenciamento do usurio.................................................................... 148 Figura 90 Cadastro de usurio. ........................................................................................ 149 Figura 91 Gerenciamento dos usurios. ........................................................................... 149

LISTA DE TABELAS

Quadro 1 Lista de elementos bsicos da notao BPMN.................................................... 34 Quadro 2 Requisitos Funcionais rea administrador. ..................................................... 71 Quadro 3 Requisitos Funcionais rea usurio. ............................................................... 71 Quadro 4 Requisitos no Funcionais. ................................................................................ 72 Quadro 5 Atores................................................................................................................ 73 Quadro 6 Detalhamento do Caso de Uso CSU05 Administrador..................................... 76 Quadro 7 Detalhamento do Caso de Uso CSU03 Administrador..................................... 77 Quadro 8 Detalhamento do Caso de Uso CSU08 Administrador..................................... 78 Quadro 9 Detalhamento do Caso de Uso CSU09 Administrador..................................... 79 Quadro 10 Detalhamento do Caso de Uso CSU01 Usurio. ............................................ 80 Quadro 11 Detalhamento do Caso de Uso CSU05 Usurio. ............................................ 80 Quadro 12 Detalhamento do Caso de Uso CSU04 Usurio. ............................................ 81 Quadro 13 Detalhamento do Caso de Uso CSU03 Usurio. ............................................ 82 Quadro 14 Avaliao da ferramenta BizAgi. ................................................................... 112 Quadro 15 Avaliao da ferramenta Orquestra. ............................................................... 113 Quadro 16 Avaliao da ferramenta Bonita. .................................................................... 114 Quadro 17 Validao dos requisitos. ............................................................................... 137

LISTA DE SIGLAS

API - Application Programming Interface ASI - Application Service Interface BAM - Business Activity Monitoring BI - Business Intelligence BLiP - Business Logic integration Platform BPD - Business Process Diagram BPEL - Business Process Execution Language BPM - Business Process Management BPMI - Business Process Management Initiative BPML - Business Process Modeling Language BPMN - Business Process Modeling Notation BPMN-WG - Business Process Modeling Notation Working Group BPMS - Business Process Management System BR - Business Rules BRE - Business Rules Engine BRMS - Business Rules Management System BSI - Business Service Interface CDC - Connected Device Configuration CEP - Complex Event Processing CLDC - Connected Limited Device Configuration CRM - Customer Relationship Management DCOM - Distributed Component Object Model DPN - Diagrama de Processos de Negcio DRL - DocObject Resource Locator EAI - Enterprise Application Integration EJB - Enterprise Java Beans ERP - Enterprise Resource Planning J2EE - Java 2 Enterprise Edition J2ME - Java 2 Mobile Edition J2SE - Java 2 Standard Edition JDK - Java Development Kit

JIT - Just-in-time jPDL - Process Definition Language JRE - Java Runtime Edition JVM - Maquina Virtual Java KPI - Key Performance Indicators MPN - Modelagem do Processo de Negcio OASIS - Organization for the Advancement of Structured Information Standards OMG - Object Management Group OMG - Object Management Group ORB - Object Request Broker PVM - Parallel Virtual Machine REST - Representational State Transfer ROI - Return on Investment SGBD - Sistemas de gerncia de banco de dados SOA - Service Oriented Architecture SOAP - Simple Object Access Protocol TI - Tecnologia da Informao UDDI - Universal Description and Integration WFMC - Workflow Management Coalition WS-BPEL - Web Service Business Processing Execution Languages WSDL - Web Service Description Language WS-HT - Web Service Human Task XMI - XML Metadata Interchange XML - Extensible Markup Language XSD - XML Schema Definition XSLT - Extensible Stylesheet Language Transformations W3C - World Wide Web Consortium

SUMRIO

1 INTRODUO ........................................................................................................................17 1.1 PROBLEMTICA ..................................................................................................................18 1.2 OBJETIVOS............................................................................................................................19 1.2.1 Objetivo geral......................................................................................................................19 1.2.2 Objetivos especficos ...........................................................................................................20 1.3 JUSTIFICATIVA ....................................................................................................................20 1.4 ESTRUTURA DO TRABALHO .............................................................................................22 2 PESQUISA BIBLIOGRFICA ...............................................................................................23 2.1 GERENCIAMENTO DE PROCESSO DE NEGCIO (BPM) .................................................23 2.1.1 Viso horizontal e vertical das organizaes ......................................................................26 2.1.2 Benefcios para empresas incorporando BPM ...................................................................28 2.2 A NOTAO BPMN..............................................................................................................29 2.2.1 Mudanas das verses BPMN 1.2 BPMN 2.0 ..................................................................30 2.2.2 A Notao BPMN 2.0 ..........................................................................................................32 2.2.3 Coreografia e orquestrao ................................................................................................35 2.3 BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM) .......................................................36 2.3.1 Ferramentas BPMS.............................................................................................................41 2.3.2 Workflow ..............................................................................................................................42 2.4 BR (BUSINESS RULES) ..........................................................................................................43 2.4.1 BRE (Business Rules Engine)..............................................................................................43 2.4.1.1 Utilizao de BRE ...............................................................................................................44 2.4.1.2 Vantagens na sua aplicao ................................................................................................45 2.4.2 BRMS (Business Rule Management System).......................................................................45 2.5 BPEL (BUSINESS PROCESS EXECUTION LANGUAGE) ......................................................46 2.6 BAM (BUSINESS ACTIVITY MONITORING) .........................................................................47 2.6.1 KPI (Key Performance Indicator)........................................................................................49 2.7 SOA (SERVICE ORIENTED ARCHITECTURE)......................................................................50 2.7.1 Cuidados com o SOA ..........................................................................................................51 2.7.2 Benefcios.............................................................................................................................52 2.8 WEB SERVICE ........................................................................................................................52 2.9 FRAMEWORKS PARA DESENVOLVER SISTEMAS BPMS ................................................53 2.9.1 JBoss Drools ........................................................................................................................53 2.9.2 JBoss jBPM 5.......................................................................................................................54 2.9.3 Activiti ..................................................................................................................................56 2.9.4 Signavio ...............................................................................................................................56 2.10 CONCLUSES FINAIS DO CAPTULO................................................................................57 3 MTODO..................................................................................................................................59 3.1 CARACTERIZAO DO TIPO DE PESQUISA ....................................................................59 3.2 ETAPAS..................................................................................................................................60 3.3 PROPOSTA.............................................................................................................................62 3.4 DELIMITAES ....................................................................................................................65 4 MODELAGEM DO SISTEMA PROPOSTO..........................................................................67 4.1 MODELAGEM DOS PROCESSOS DE NEGCIO ................................................................67 4.2 ANLISE DE REQUISITOS...................................................................................................69 4.2.1 Requisitos Funcionais .........................................................................................................69

4.2.1.1 rea Administrativa ...........................................................................................................69 4.2.1.2 rea do Usurio .................................................................................................................71 4.2.2 Requisitos no Funcionais...................................................................................................72 4.3 ATORES .................................................................................................................................72 4.4 MODELAGEM DOS CASOS DE USO...................................................................................73 4.4.1 Diagrama de Casos de Uso..................................................................................................74 4.4.2 Descries dos casos de uso.................................................................................................75 4.4.2.1 Documentao dos casos de uso do ator: Administrador .....................................................75 4.4.2.2 Documentao dos casos de uso do ator: Usurio ...............................................................79 4.5 MODELAGEM DAS ATIVIDADES.......................................................................................82 4.5.1 Diagrama de atividade Administrador............................................................................83 4.5.2 Diagrama de atividade Usurio .......................................................................................86 4.6 MODELAGEM DE DADOS ...................................................................................................90 4.7 CONSIDERAES FINAIS DO CAPTULO .........................................................................91 5 DESENVOLVIMENTO ...........................................................................................................92 5.1 TENOLOGIAS UTILIZADAS ................................................................................................92 5.1.1 Java ......................................................................................................................................93 5.1.2 JBoss Drools ........................................................................................................................94 5.1.3 JBoss jBPM 5.......................................................................................................................94 5.1.4 BlazeDS ...............................................................................................................................95 5.1.5 Flex 4 ...................................................................................................................................96 5.1.6 Mysql 5.................................................................................................................................96 5.1.7 JBoss Application Server......................................................................................................97 5.1.8 Eclipse ..................................................................................................................................98 5.1.9 Flash Builder 4 ....................................................................................................................98 5.1.10 Java Persistence API ...........................................................................................................99 5.1.11 Hibernate .............................................................................................................................99 5.2 PROCESSO DE DESENVOLVIMENTO ..............................................................................100 5.2.1 Detalhamento do processo de desenvolvimento ...............................................................103 5.3 PESQUISA E VERIFICAO DE FERRAMENTAS BPMS................................................108 5.3.1 Avaliao de Ferramentas ................................................................................................108 5.3.2 Definio de requisitos de seleo da ferramenta.............................................................109 5.3.2.1 Exemplos de Requisitos de Modelagem............................................................................110 5.3.2.2 Exemplos de Requisitos de Desenvolvimento ...................................................................110 5.3.2.3 Exemplos de Requisitos de Ambiente de Usurio .............................................................110 5.3.2.4 Exemplos de Requisitos de Integrao ..............................................................................110 5.3.2.5 Exemplos de Requisitos de Gesto ...................................................................................111 5.3.2.6 Exemplos de Requisitos de Infra-estrutura e Administrao..............................................111 5.3.2.7 Exemplos de Requisitos de Licenciamento da Soluo .....................................................111 5.3.3 Critrios para Avaliao das Ferramentas ......................................................................112 5.3.3.1 Ferramenta BizAgi BPM Sute .........................................................................................112 5.3.3.1.1 Concluso da Anlise ....................................................................................................112 5.3.3.2 Ferramenta Orquestra .......................................................................................................113 5.3.3.2.1 Concluso da Anlise ....................................................................................................113 5.3.3.3 Ferramenta Bonita............................................................................................................114 5.3.3.3.1 Concluso da Anlise ....................................................................................................114 5.4 APRESENTAO DO SISTEMA ........................................................................................114 5.4.1 Gerenciamento dos processos ...........................................................................................115 5.4.2 Participantes do processo..................................................................................................126 5.4.3 Administrao de usurios................................................................................................129 5.4.4 Execuo das tarefas do processo .....................................................................................131 5.5 VALIDAO .......................................................................................................................135

5.5.1 Validao dos requisitos funcionais..................................................................................135 5.5.2 Estudo de Caso ..................................................................................................................137 5.5.2.1 Concluso do Estudo de Caso...........................................................................................150 5.6 CONSIDERAES FINAIS DO CAPTULO .......................................................................150 6 CONCLUSO E TRABALHOS FUTUROS.........................................................................151 6.1 CONCLUSO.......................................................................................................................151 6.2 TRABALHOS FUTUROS.....................................................................................................153 REFERNCIAS............................................................................................................................154

17 1 INTRODUO

A partir dos anos 90, com a evoluo intensa da informtica, maiores estudos e compreenso de processos tornaram-se necessrios. Assim, Davenport (1994, p. 47) observou que:
Pelas mesmas linhas telefnicas, que antes levavam apenas vozes e estticas, passam hoje ordens de compra, grandes somas de dinheiro, plantas de projetos de produtos, [...] e o computador, que a princpio automatizava os clculos, hoje aconselha aos responsveis pelas decises, e at mesmo toma essas decises.

Dessa forma, num mercado altamente competitivo e dinmico, onde as organizaes precisam responder rpida e eficientemente aos estmulos do mercado, estruturas organizacionais flexveis, bem como tecnologias integradoras se tornaram iniciativas constantes nas empresas. O Gerenciamento de Processos de Negcio (Business Process Management BPM) uma iniciativa que pode apoiar essas respostas e esse considera as etapas de modelagem, anlise, automatizao, monitoramento e orientao estratgica. Para apoiar uma iniciativa de BPM, uma nova categoria de software aparece, os chamados Sistemas de Gerenciamento de Processos de Negcio (Business Process Management Systems BPMS), que so conjuntos de ferramentas que auxiliam a documentao, desenho, redesenho, modelagem e automao de processos. (VALLE e OLIVEIRA, 2010). Os sistemas BPMS possibilitam que processos de negcio integrem, lgica e cronologicamente, clientes, fornecedores, parceiros, influenciadores, funcionrios e todo e qualquer elemento que possa se integrar, dando organizao viso completa e essencialmente integrada do ambiente interno e externo das suas operaes e das atuaes de cada participante em todos os processos. (CRUZ, 2010). Nos ltimos anos, tem-se notado a gradual introduo de tecnologias sofisticadas de motores de regras de negcios (Business Rules Engine - BRE) nas organizaes e essas regras adicionam valor aos negcios por meio da capacidade de aplicar estratgias de negcio que suportam sofisticadas decises analticas nas mos dos usurios de negcios. (WORTHINGTON, 2008). A proposta desta monografia tem como finalidade desenvolver um sistema BPMS totalmente Web visando a agregar valor aos processos de negcio por meio de BREs e, desta

18 forma, dar suporte estrutura organizacional, reduzir o impacto com mudanas em seus processos e regras de negcio e integrar e disseminar conhecimento entre as pessoas envolvidas na organizao.

1.1

PROBLEMTICA

Atualmente, em um mercado dinmico e colaborativo, organizaes esto cada vez mais integradas a clientes, fornecedores e, s vezes, acionistas esto comandando as empresas em escritrios espalhados por todo o mundo, necessitando, assim, de informaes atualizadas de toda a organizao. Diante desse cenrio, as organizaes precisam de ferramentas que as apiem a responder s mudanas o mais rpido possvel, com qualidade e eficincia nos servios prestados. A automao e monitoramento de processos de negcio, por meio de sistemas BPMS, possibilitam que diversos aspectos crticos normalmente encontrados nas organizaes sejam solucionados ou minimizados. Diante desse contexto organizacional, alguns pontos de melhoria se tornam evidentes, como: as organizaes tm dificuldade de entendimento dos seus processos operacionais, faltando uma viso ponta a ponta e de como esses se integram com toda a sua estrutura; falta de integrao entre os Sistemas de Informao. Atualmente, as organizaes possuem diversos sistemas espalhados sem integrao e sem uniformizao das informaes; dificuldade para responder s mudanas. No cenrio atual, organizaes mudam constantemente seus Sistemas de Informao para se adequarem a novos requisitos de negcio. Essas mudanas, normalmente trazem consigo gastos exorbitantes e grande demora na modificao ou criao desses sistemas, o que conseqentemente impacta em toda a organizao; distanciamento entre Tecnologia da Informao (TI) e Negcio. A rea de negcio atualmente necessita responder as mudanas de mercado da

19 melhor forma possvel e para isso a TI precisa prover meios para que essas mudanas sejam alcanadas. Com isso, um grande problema surge: Como facilitar o alinhamento entre essas duas reas?; regras de negcio fragmentadas entre os diversos Sistemas de Informao. Um ponto crtico atualmente a falta de centralizao das regras de negcio, em que uma mesma regra codificada (replicada) em diversos sistemas, resultando em redundncia e esforo para desenvolvimento. Ocasionalmente, quando uma regra necessita ser criada ou modificada, refletir essas mudanas em diversos sistemas se torna uma atividade cara e demorada; carncia de sistemas BPMS nacionais e principalmente com ambiente totalmente Web . Diversas ferramentas nacionais e internacionais necessitam a configurao e a criao dos processos em um ambiente Desktop. E, por meio desse, os processos so implantados na Web. Dessa forma so necessrios ambientes distintos para configurao e utilizao desses sistemas.

1.2

OBJETIVOS

A seguir, so apresentados o objetivo geral e os objetivos especficos.

1.2.1

Objetivo geral

O objetivo principal deste trabalho desenvolver um sistema BPMS, visando a agregar valor aos processos por meio de motor de regras de negcios.

20 1.2.2 Objetivos especficos

Os objetivos especficos apresentam-se a seguir: desenvolvimento de um modelador grfico de processos e de um aplicativo interativo para criao de formulrios; integrao da soluo proposta com um motor de regras de negcio para otimizar e flexibilizar a execuo de processos de negcio; desenvolvimento de um portal que possibilite ao usurio final executar, organizar e acompanhar suas tarefas e processos; elaborar e aplicar um procedimento metodolgico para o desenvolvimento do sistema BPMS; validar e testar o sistema por meio de um estudo de caso.

1.3

JUSTIFICATIVA

Atualmente, as organizaes necessitam cada vez mais de uma viso integrada de seus processos, pessoas e tecnologias, bem como uma maior confiabilidade, agilidade e eficincia na prestao de seus servios. Para nortear o cumprimento desses objetivos, o desenvolvimento de uma plataforma BPMS para apoiar uma iniciativa BPM se justifica e traz consigo diversos benefcios que podem ser observados tanto pelos gestores que podero monitorar e acompanhar as atividades em tempo real, obtendo assim informaes teis sobre o negcio, como por meio das pessoas que participaro efetivamente na execuo dos processos operacionais, que se beneficiaro com a facilidade de sua automatizao, interagindo com estes, por meio de formulrios eletrnicos. Segundo Baldam et al. (2010), quase todos os negcios possuem regras usadas em vrias instncias e inscritas em vrios softwares simultaneamente, em que, caso uma regra mude, as alteraes devem ser feitas em cada sistema em uso.

21 Para esse cenrio, a utilizao de um BRE possibilita que usurios de negcios possam modificar as regras de negcio sem a necessidade de interveno da rea de TI, podendo implementar rapidamente grupos de regras que iro tomar e ativar decises e servios sem utilizar programao. (WORTHINGTON, 2008). Com a adoo de um BRE, a utilizao de um repositrio nico de regras e processos de negcio se torna uma ferramenta fundamental e adequada, favorecendo a integrao efetiva entre TI e negcios, em que ambos podero, por meio de um local nico, manipular e agregar valor organizao por meio das regras de negcio. Como resultado, as empresas se tornam mais efetivas e reativas diante desse cenrio que muda constantemente. Um problema verificado em algumas empresas de desenvolvimento de software no Estado de Santa Catarina citado por Coral (2007), que um dos principais desafios a falta de padronizao de seus processos que impedem seu crescimento. Para suprir essa carncia, o sistema BPMS proposto disponibilizar por meio de uma interface intuitiva a Notao Padronizada para Modelar Processos de Negcio (Business Process Modeling Notation BPMN) que apia na modelagem dos processos. importante destacar que essa linguagem trabalha com a Arquitetura orientada a Servios (Service Oriented Architecture - SOA) para proporcionar uma melhor organizao dos processos para os servios e possibilitar uma maior adaptao a mudanas. Tambm, uma das principais vantagens da soluo proposta, em relao a outras do mercado, ser um ambiente totalmente Web, que favorece tanto analistas de negcio, em que estes podero, a partir de qualquer localidade, definir e modificar caractersticas dos processos de negcio, bem como, os usurios que utilizaro a plataforma em suas atividades dirias, que tero a possibilidade de interagir ou acompanhar o status de seus processos. Diante de todo o exposto, as motivaes principais para o desenvolvimento da plataforma BPMS o forte interesse dos autores na rea de BPM e tecnologias aplicadas ao BPM, como a possibilidade de torn-la um produto comercial que possa auxiliar as organizaes de diversos segmentos a gerenciarem seus processos de negcio eficazmente, obtendo, assim, melhores resultados e maior qualidade na gerao de seus produtos e prestao de servios, para clientes e empresas.

22 1.4 ESTRUTURA DO TRABALHO

Este trabalho est dividido nos seguintes captulos: Captulo 1: apresenta uma viso geral do tema, a problemtica, objetivos gerais e especficos, bem como a justificativa. Captulo 2: descreve os conceitos tericos para fundamentar e desenvolver a monografia, que so: Gerenciamento de Processos de Negcio (BPM), BPM , BPMS, BRE, BRMS (Business Rules Management System), BPEL (Business Process Execution Language), BAM (Business Activity Monitoring), SOA, Web Service; e alguns Frameworks. Captulo 3 : descreve a caracterizao do tipo de pesquisa, etapas metodolgicas, proposta da soluo e delimitaes do trabalho. Captulo 4: descreve a modelagem e arquitetura da soluo proposta. Captulo 5: descreve o processo de desenvolvimento, as ferramentas e tecnologias utilizadas, bem como a apresentao das telas do sistema e sua descrio. Tambm comentado sobre a realizao da validao do sistema conforme objetivos definidos. Captulo 6: apresenta as concluses, objetivos alcanados e

recomendaes da monografia.

23 2 PESQUISA BIBLIOGRFICA

Este captulo apresenta os conceitos sobre gerenciamento de processos de negcio e sua utilizao, a definio e principais elementos grficos do BPMN (Business Process Modeling Notation ), a linguagem BPEL (Business Process Execution Language), a utilizao de regras de negcios apoiadas pelos motores de regras, bem como os mdulos que compem os sistemas BPMS (Business Process Management System). Tambm apresentado o BAM (Business Activity Monitoring) para monitorar, em tempo real, os processos de negcio, o uso do SOA (Service Oriented Architecture) e da tecnologia Web Service para integrar sistemas e o uso dos sistemas BPMS com seus principais Frameworks.

2.1

GERENCIAMENTO DE PROCESSO DE NEGCIO (BPM)

Conforme Danverport (1994) o processo simplesmente um conjunto de atividades estruturadas e medidas, destinadas a resultar um produto especificado para um determinado cliente ou mercado. uma ordenao especfica das atividades de trabalho, no tempo e no espao, com um comeo e um fim, e inputs e outputs claramente definidos: uma estrutura para a ao. Segundo Garimella e outros (2008, p. 20, traduo nossa), Business Process Management (BPM) um conjunto de metodologias, ferramentas e tecnologias com enfoque no desenho, representao, anlise e controle dos processos de negcio operacionais. Para Cruz (2006, p. 63), segue a definio de BPM:
Conjunto, formado por metodologias e tecnologias que possibilitam que processos de negcio integrem, lgica e cronologicamente, cliente, fornecedor, parceiros, influenciadores, empregados e todo e qualquer elemento que com eles possam, queiram ou tenham de interagir, dando ao ambiente interno e externo da organizao uma viso completa e essencialmente integrada das suas operaes e atuaes.

Para Cruz (2006, pag. 64), o BPM sustentado por dois conjuntos o organizacional e o ferramental, conforme apresenta a figura a seguir:

24

Figura 1 Os dois grupos de conhecimentos que sustentam o conceito BPM. Fonte: Cruz (2006).

O processo de negcio, apesar de ser uma sequncia estruturada de atividades especficas, no formado por um nico elemento, mas, sim, pela juno de vrios, como pessoas, mquinas e sistemas que trabalham juntas para buscar um objetivo de negcio em comum. (KO, 2009). O BPM possui um ciclo de vida subdividido em diversas etapas, sendo esse iniciado com a definio da metodologia a ser aplicada, em que dvidas devem ser entendidas e equacionadas para um correto alinhamento com as necessidades do cliente. Aps, iniciada a fase de documentao, desenho e anlise do processo atual, em que as deficincias e as qualidades so formalmente documentadas e analisadas, servindo como base para a prxima etapa. Seguindo, tem-se a fase de anlise, redesenho e modelagem do novo processo, em que as oportunidades de melhoria so colocadas em prtica, gerando um novo processo caso seja necessrio. Por ltimo realizada a implementao do novo processo, em que sua execuo monitorada, verificando assim seu correto funcionamento. (CRUZ, 2010 BALDAM et al., 2010).

25 A Figura 2 ilustra o ciclo de vida BPM.

Figura 2 Ciclo de vida BPM. Fonte: Baldam et al., (2010).

As etapas apresentadas, na figura acima, segundo Valle e Oliveira (2010), tendo semelhana com o descrito por Cruz, detalhada da seguinte forma: planejar o BPM: definio das atividades para o alcance das metas organizacionais; modelar e otimizar o processo: gerar informaes do processo atual (AS IS) e proposta de projeto futuro (TO BE); implantar processo: suporte a implantao e a execuo; controle e anlise do processo: nesta fase ocorre o controle dos processos por meio de recursos e indicadores para otimizao e planejamento das atividades. No processo de modelagem, algumas pessoas argumentam que despender muito tempo em desenhar o processo como ele no to importante quanto modelar o processo

26 ideal, e, portanto, o AS IS no deveria receber tanta ateno quanto o TO BE. (BORTOLINI, 2010 ). Segundo Bortolini (2010), "Existem muitas discusses em torno desses dois tipos de modelagem, AS IS e TO BE. AS IS o desenho de como o processo realmente executado, contendo seus erros e acertos, j o mtodo TO BE trata do ideal e no da realidade vivida pela empresa". O AS IS para Baldam et al. (2010, p. 74), faz com a equipe se envolva, em que a "atividade de modelar um processo AS IS induz a fazerem julgamentos e a imaginarem mudanas desejveis" e ainda comenta que "no h um modelo perfeito" de modelagem de processo. J no TO BE, conforme Baldam et al. (2010), pretende-se criar um ambiente de discusso entre as partes envolvidas de forma a melhorar o processo em questo, inov-la ou at mesmo questionar se ele se faz necessrio e se de fato agrega valor necessrio organizao.

2.1.1

Viso horizontal e vertical das organizaes

A tica tradicional (Vertical) nomeada dessa forma por apresentar a estrutura organizacional de forma hierrquica, ou seja, por meio de organogramas funcionais em que as relaes de responsabilidades e de subordinao so visualizadas. Essa uma viso

fragmentada que no contempla a forma de como as organizaes produzem valor. (DVALOS, 2010). A viso fragmentada funcional e departamental torna difcil para os integrantes de uma organizao a compreenso de como as tarefas individuais se combinam para gerar resultado para o cliente. A falta da viso do todo e no s das partes tinha como consequncia servios e produtos movimentando-se por meio das funes empresariais (marketing, produo, vendas, engenharia) de forma descoordenada, lenta e ineficiente. (ANGELONI, 2009, p. 118). Segundo Valle e Oliveira (2010), a viso horizontal (por processos) caracterizada por uma viso dinmica em que uma organizao faz o necessrio para produzir valor para os seus clientes e tambm significa visualizar a organizao a partir da tica de

27 processos, focando mais a ao (atividade de trabalho) do que sua estrutura (funes e departamentos). A viso por processos quebra o paradigma funcional, possibilitando uma viso integrada dos processos ponta a ponta. Os processos nas organizaes horizontais precisam estar em primeiro lugar, devem nortear e influenciar a estrutura, sistemas, comportamentos e pessoas no enfatizando mais a estrutura tradicional hierrquica. (ANGELONI, 2009, p. 118). Para Baldam et al. (2010, p. 25), a viso por processo procura entender o que precisa ser feito e como faz-lo. [...] primeiro tem-se em mente as atividades que agregaro valor para a organizao sem se preocupar inicialmente em saber qual o departamento que o executar. Para Tregear e outros (2011, p. 4), atravs de seus processos de negcios que uma empresa executa sua estratgia. Os processos de negcios devem, portanto, ser geridos e otimizados continuamente isto BPM (Business Process Management). Segundo o autor, necessrio antes da adoo do BPM estabelecer o escritrio de processos que possui as seguintes etapas: preparar e planejar, conscientizao sobre BPM, desenvolver a competncia interna, construir e operar um escritrio, comunicar, gerenciar as mudanas, demonstrar a melhoria de processo e melhorar continuamente. O escritrio de processo tem como objetivo a misso de administrar, suportar e fomentar BPM em toda a organizao. Com sua criao, pode-se consolidar o interesse e a ao em fornecer um mecanismo de controle efetivo e o apoio de muitas iniciativas de processos em andamento. Para o desenvolvimento de um escritrio de processo,

necessrio um modelo de referncia, tambm um programa de desenvolvimento de competncias em BPM e implementao em ondas, no qual se pode desenvolver a maturidade do processo de forma controlada. (TREGEAR, 2011). Conforme Tregear (2011), as responsabilidades de um escritrio de processo so: traduzir a viso estratgia para a operao; promover a melhoria continua dos processos de negcios; fomentar a inovao e criatividade nas aes de processos; coordenar as atividades de melhoria e inovao de processos por meio de uma abordagem de gesto de portiflio; acompanhar os benefcios entregues a partir da melhoria e da gesto do dia a dia dos processos;

28 definir e manter mtodos e ferramentas de apoio para as iniciativas de BPM; dar apoio s atividades de gesto da mudana durante os projetos de melhoria de processos; fornecer recursos internos para o estudo, pesquisa e evoluo de BPM na organizao; apoiar o uso de sistemas e outras tecnologias relacionadas BPM; compartilhar e disseminar conhecimentos relacionados a processos e a resultados bem sucedidos com BPM.

2.1.2

Benefcios para empresas incorporando BPM

Com BPM, as organizaes ganham em velocidade, agilidade e qualidade, possibilitando uma melhora no rendimento do negcio. Diversos aspectos podem ser apontados como ganho significativo da adoo do BPM, assim descreve Garimella e outros (2008, p. 20-21): Diretores de negcio podem de forma mais pr-ativa responder e controlar aspectos operacionais de seus processos. Diretores de Tecnologia podem utilizar suas habilidades em funo dos processos de negcio. A empresa, como um todo, tem um ganho significativo, podendo agir de forma rpida na busca por seus objetivos. Segundo Cruz (2006, p. 21), Todo mundo fala em processos de negcio, mas, ao que parece, poucos sabem o que realmente seja, para que serve e quais as vantagens em ter uma organizao conhecida e operada por meio dos seus processos. Outros benefcios importantes para a organizao o conhecimento e a visibilidade das atividades da empresa, maior capacidade de identificar problemas, otimizaes das tarefas, melhor definio dos direitos e papis na sociedade e serve como uma ferramenta para preveno, auditoria e avaliao do comprimento da regulamentao. (KO, 2009).

29 Baldam et al. (2010 p. 42-44) comentam que as empresas exigem maior transparncia nos negcio e o maior uso das tecnologias que permitam transaes entre empresas, alm disso, utilizam o BPM por estar associado maior rapidez no desenvolvimento do produto, tendo um ciclo de vida menor, resultando na diminuio do tempo para o retorno do investimento (ROI - Return on Investment).

2.2

A NOTAO BPMN

Segundo a OMG (Object Management Group, 2011), o Business Process Modeling Notation (BPMN) um padro que disponibiliza para as organizaes a capacidade de compreenso dos seus negcios definidas em uma notao grfica, possibilitando a comunicao desses procedimentos de forma padronizada. Alm disso, a notao grfica facilitar o entendimento das colaboraes para que as empresas compreendam a si mesmas, dos participantes em seus negcios e permitir que organizaes se adaptem s novas circunstancias de negcios internos e externos (B2B - Business to Bussines) rapidamente. Segundo Valle e Oliveira (2010, p. 78), por meio da notao BPMN, diversos tipos de processos, desde os mais globais aos mais especficos, podem ser modelados, como processos administrativos (vendas, compras, controle de materiais), financeiro (emprstimos, controle de capital), desenvolvimento de software, entre outros. Um dos pontos fortes do BPMN so a possibilidade de conectar o desenho dos processos de negcio (DPN) e a automao e execuo desses processos em um ambiente operacional, criando um elo de comunicao padronizado entre ambos. (VALLE; OLIVEIRA, 2010, p. 78). O BPMN teve origem em um acordo entre vrias empresas que possuam sua prpria notao. O incio se deu com a criao do Business Process Management Initiative (BPMI, http://www.bpmi.org), uma organizao sem fins lucrativos que recebeu forte apoio de grandes corporaes, como IBM, Fujitsu, BEA e SAP. Em 2001, foi criado o Business Process Modeling Notation Working Group. (BPMN-WG) que junto a diversas empresas deu incio ao BPMN. (BITENCOURT, 2007).

30 2.2.1 Mudanas das verses BPMN 1.2 BPMN 2.0

A verso da BPMN 1.2 sofreu diversas modificaes e uma, que chamou a ateno, a alterao do nome da especificao BPMN, que de Business Process Modelling Notation passa a se chamar Business Process Model and Notation. Isso ocorreu porque a especificao da verso 2.0, alm de descrever a notao de desenho do processo, tambm define um modelo de classe para apoiar a implementao das notaes pelas ferramentas. (SGANDERIA, 2010). Outras mudanas que ocorreram, segundo a equipe da Cryo Technologies (2010) foram relacionadas : criao de diagrama de coreografia: comunicao entre participantes demonstrando cada empresa envolvida em um processo colaborativo, em que o foco est na forma de interao entre os participantes; criao de diagrama de converso: que contempla a troca de mensagem entre os participantes; eventos no interruptivos de um processo: inicia-se nova atividade sem ter interrupo da anterior; eventos sub-processos: acionam sub-processos dependendo da informao que recebem; transferncia de processo: com XML o modelo de processo pode ser transferido de uma ferramenta outra. Conforme escrito no artigo do Ghalimi (2006), [...] A BPMN suporta a orquestrao de servios Web Services e a execuo de tarefas humanas do Workflow, ao permitir coreografia de mltiplos processos de negcio atravs da metfora das raias de uma piscina. [...]. Conforme a OMG (2011, Object Management Group), ocorreram algumas modificaes na notao e tcnica para a especificao BPMN. As principais mudanas referentes s tcnicas so: formatos de intercmbio para troca de sintaxe abstrata se tratando dos modelos XMI e XSD; formatos de intercmbio para a troca de esquema pra XMI e XSD ; transformaes XSLT entre o XMI e formatos XSD ;

31 tarefas de referncia so removidas, reutilizados dentro de um nico diagrama, com o objetivo de simplificar a linguagem e implementaes. Assim, por exemplo, a figura 3 apresenta algumas incorporaes da verso BPMN 2.0. A coreografia, no qual representa a comunicao entre os participantes separados por piscinas, estas representam o fluxo da empresa, formalizando como os participantes se comunicam. (BOER, 2010).

Figura 3 Diagrama de Coreografia. Fonte: OMG (2011).

Tambm, a figura 4 ilustra um diagrama de conversao que define uma troca de mensagens entre os participantes, representando a troca de informao e no necessariamente o fluxo dela. (BOER, 2010).

32

Figura 4 Diagrama de Comunicao. Fonte: OMG (2011).

2.2.2

A Notao BPMN 2.0

Conforme Valle e Oliveira (2010), um Diagrama de Processos de Negcio (DPN), tambm conhecido como Business Process Diagram (BPD) composto por diversos elementos, sendo os mais importantes: atividade, evento, gateway (smbolos de deciso) e conectores. Com eles, pode-se desenvolver um modelo de diagrama. Para executar esses processos, utilizada uma linguagem denominada BPEL (Business Process Execution Language). No DPN existem os seguintes tipos de diagrama: Privado ou Interno: realizado dentro da organizao, so as atividades internas e como elas se interagem; Abstrato ou Publico: a ligao dos processos internos com organizaes externas. Devem aparecer somente atividades que se comunicam com estas organizaes; Colaborao ou Global: modelam-se as interaes, em que a comunicao por meio de troca de mensagens, com um ou mais processos de negcio. Segundo a especificao da OMG (2011), em relao ao BPMN 2.0, existem cinco categorias bsicas de elementos, definidas como: Fluxo de Objetos, Dados, Conexo de Objetos, Raias e Artefatos.

33 O fluxo de objeto define o comportamento de um processo e est dividido em: Evento, Atividade e Gateway. Os dados esto divididos em: dados do objeto, entrada de dados, sada de dados e armazenamento de dados. A conexo dos objetos pode ocorrer nas seguintes formas: associao de dados, associaes, mensagem de fluxo e sequncia de fluxo. Os elementos so agrupados por meio de piscinas e raias, que podem representar organizaes, papis, unidades organizacionais, entre outros conceitos. Os artefatos so utilizados para fornecer informaes adicionais sobre os processos. O atual conjunto de artefatos inclui: grupo e anotao de texto.

Elemento Evento

Descrio Um Evento algo que acontece durante um processo do negcio ou uma coreografia. Possui no fluxo do modelo ao de causa ou impacto. H trs tipos de Eventos: Incio (Start), Intermedirio (Intermediate) e Fim (End). A atividade, em termos genricos, trabalho que a empresa executa de um processo. Ela pode ser composta ou no, e as atividades podem ser em forma de tarefa ou sub-processo. So utilizadas para padronizao e coreografia. A Deciso usada para controlar a divergncia e a convergncia do fluxo dentro de um processo ou uma coreografia. Assim, determinar ramificao, bifurcao, fuso e unio de caminhos. Os marcadores internos indicaro o tipo de controle de comportamento.

Notao

Atividade

Deciso

Fluxo de Um Fluxo de Sequncia usado para mostrar a ordem Sequncia (a sequncia) com que as atividades sero executadas em um processo. Fluxo da Um Fluxo da Mensagem usado para mostrar o fluxo Mensagem das mensagens entre dois participantes. Associao Uma Associao usada para interligar ou associar dados, texto, e outros artefatos com os objetos do fluxo. A ponta da seta indica a direo do fluxo.

34

Piscina

Pools ou Piscinas so utilizados quando o diagrama envolve duas entidades de negcio ou participantes que esto separados fisicamente no diagrama. Um pool representa uma organizao e uma lane representa tipicamente um departamento dentro dessa organizao. Os objetos do tipo Lanes ou Raia so utilizados para separar as atividades associadas para uma funo ou papel especfico.

Raia

Objetos de Os Objetos de dados so mecanismos para mostrar dados como os dados so executados ou produzidos nas atividades. Os dados de entrada e sada fornecem a mesma informao para os processos. Mensagem A mensagem ser utilizada para troca de informaes entre os participantes. Grupo O grupo o agrupamento de elementos grficos que esto dentro de uma categoria no afetando a sequencia de fluxo entre eles. As categorias podem ser utilizadas para anlise ou documentao. O grupo uma maneira em que a categoria tem de ser visualmente exibida no diagrama. As anotaes so mecanismos para que um modelador fornea a informao do texto adicional para o leitor de um diagrama de BPMN.

Anotao

Quadro 1 Lista de elementos bsicos da notao BPMN. Fonte: OMG, 2011.

Existem vrios outros exemplos dos elementos de BPMN. Mais detalhes podem ser encontrados no site da OMG (www.omg.org). medida que so coletados os dados sobre o processo a ser modelado, pode-se utilizar diversas variaes destes elementos, cada uma com uma semntica precisa (por exemplo, eventos baseados em tempo). Pode-se, tambm, adicionar novos elementos que enriquecem a semntica do processo. (GSIG, 2011). Segundo iProcess (2011), um modelo BPMN nos permite representar os seguintes conceitos: processos, sub-processos e atividades; loops, instanciao mltipla de atividades e transaes de compensao; eventos de incio, de fim e intermedirios no processo (ex: um processo pode iniciar a partir do evento Email vindo do cliente);

35 decises, paralelismo e sincronizao de processos; organizaes, departamentos e papis que participam do processo; trocas de mensagens entre organizaes participantes do processo (essencial para representar cenrios B2B); objetos de dados que tramitam ao longo do processo.

Com estes recursos, o BPMN permite a criao de modelos excepcionalmente sofisticados com a vantagem adicional de poderem ser facilmente compreendidos.

2.2.3

Coreografia e orquestrao

Para que o BPM (Business Process Management) trabalhe corretamente, so necessrios que sejam efetuadas a integrao de servios e a execuo dos processos a partir orquestrao e a coreografia dos processos. A Orquestrao ocorre quando um elemento controla todos os aspectos do processo e na coreografia cada elemento autnomo e controla a si mesmo. Com a orquestrao que acaba sendo definida a sequncia de passos do processo, aqui que se inclui as excees. Dentro do SOA (Service Oriented Architecture) isso ocorre por meio de servio. Neste trabalho, o BPMN (Business Process Modeling Notation) que efetua a representao visual de sequncia e o BPEL (Business Process Execution Language) que executa a sequncia. J na coreografia, as regras so criadas no qual determinado para cada elemento do processo, este abordado baseado em mensagem que est sendo utilizado em aplicaes B2B (Business to Bussines) e interessante por verificar a troca de mensagem semntica e comportamento, ou utilizado tambm nos componentes em que verificado o comportamento de cada elemento para analisar a sua evoluo. da coreografia que utilizado a Web Service (WS-CDL Web Service Coreografia Definition Language). (ROSEN, 2008).

36 2.3 BPMS (BUSINESS PROCESS MANAGEMENT SYSTEM)

Para Valle e Oliveira (2010), BPMS so conjuntos de ferramentas que servem para executar (automatizar) processos de negcio, e relatam que este software serve para automatizar processos primrios quanto secundrios de qualquer natureza salvo de excees como de indstria qumica, petroqumica e petrolfera que possuem um Workflow integrado na estrutura das plantas industriais. De acordo com Cruz (2010, p. 118), o surgimento do BPMS ocorreu devido baixa venda de Workflow quando os fabricantes decidiram incrementar e gerar um novo software para aumentar as vendas. A arquitetura BPMS foi criada com tecnologias emprestadas de outros ambientes, e nenhuma tecnologia utilizada foi criada para o BPMS. Para Cruz (2010, p. 68), o surgimento do BPMS ocorreu a partir do Workflow. O BPMS foi criado para [...] automatizar e controlar processos por meio da execuo de regras de negcio, visando retirar do trabalhador a responsabilidade por tarefas repetitivas, desmotivantes e estressantes, transferindo-as para vrias Tecnologias da Informao. (CRUZ, 2010, p. 85). A definio, para Cruz (2010, p. 90), sobre BPMS :
Conjunto de software, aplicaes e ferramentas de tecnologias da informao cujo objetivo o de possibilitar a implantao de modus operandi Business Process Management, integrando em tempo real clientes, fornecedores, parceiros, influenciadores, empregados e todo e qualquer elementos que com eles possam, queiram ou tenham que interagir por meio da automatizao dos processos de negcio.

Segundo ULTIMUS (2011), com o uso do BPMS, aproveita-se conceito fundamental de modelagem para permitir que processos sejam testados em um ambiente virtual, em que problemas e gargalos podem ser verificados antes mesmo de sua implantao, tambm, por meio da otimizao, que, aps a identificao e resoluo da situao inicial, realizada na modelagem, pode-se prosseguir com o projeto, contribuindo, assim, para seu sucesso. O BPMS apresenta um painel de interface, oferecendo maior visibilidade e controle dos processos, podendo monitorar, avaliar e manter os processos em tempo real. Quanto s regras o BPMS da oportunidade ao gerente do processo configurar vrios parmetros para gerir incidentes e alertas, podem ser ativados para informar o vencimento de prazo para os usurios.

37 J, para o CEO Ghalimi (2006), um BPMS:

[...] deve suportar o desenho e a execuo do processo, consequentemente uma ferramenta de modelagem de processo simples com potencialidades de simulao do processo [...]. Tambm, um BPMS deve suportar orquestrao dos servios e interaes humanas no fluxo de trabalho. [...] um BPMS completo tem trs componentes principais: uma ferramenta de desenho de processos, um motor de execuo de processos e uma interface de usurios para os fluxos de trabalho.

Para Dubray (2011), o BPMS possui quatro tecnologias chave, sendo elas: XML (Extensible Markup Language): que traz a interao com a fonte de dados; Midleware B2B: trazendo uma conexo segura para a comunicao externa de processo de negcio; Enterprise Application Integration: permite ao BPMS interagir com os sistemas corporativos e legados; Web Service: padronizar as interaes dos sistemas.

Figura 5 Arquitetura BPMS. Fonte: Dubray, (2011).

Para o autor, o BPMS trabalha com trs interfaces: Application Service Interface (ASI) que envolve aplicativo de negcio e Web Service, tambm a Business Service Interface (BSI), que se refere ao gerenciamento de interaes entre o processo de negcio e seus

38 parceiros e, por ltimo, a interface que Browser-based document exchange, ou seja, troca de documentos baseados em navegadores para usurios finais. O BPMS segue um padro, o BPMI (Business Process Management Initiative), segundo Sordi et al. (2007):
O BPMI.org constitudo por empresas da rea de tecnologia da informao e de institutos de pesquisa que esto interessados no desenvolvimento da tecnologia BPMS. A misso do BPMI.org promover, desenvolver e disseminar o BPMS, estabelecendo padres, desenvolvendo especificaes abertas e dando assistncia s empresas desenvolvedoras de ferramentas, tcnicas e metodologias.

Figura 6 Framework dos componentes da soluo tecnolgica BPMS. Fonte: Sordi et al., (2007).

Sordi et al. (2007) comentam que o sistema BPMS desempenha o papel de organizador e controlador, fazendo com que o trabalho seja desempenhado como um maestro em uma orquestra. Analisando os componentes do BPMS, segundo a figura acima (SORDI et al., 2007), existem as regras que comandam o sistema BPMS, essas so lanadas para cada uma das informaes que esto armazenadas no "repositrio de definio de processo" do BPMS,

39 nele que esto descritas as atividades, as sequncias de trabalhos possveis de ocorrerem, as regras para identificao de incio e trmino de cada atividade, entre outras informaes importantes orquestrao do processo. Aps, ocorre manipulao e armazenamento desses dados em que so desenvolvidas as especificaes do processo, esse passo ocorre com as ferramentas de desenho. Depois de efetuado o desenho e inseridas todas as instrues de controle do processo, gerado o cdigo executvel (software), em que esse cdigo fonte segue os padres BPML (Business Process Modeling Language) que ser interpretado e executado pelo "motor de processo", que auxiliar o sistema BPMS no acompanhamento do processo. O armazenamento dessas informaes ocorre no "Repositrio de instncias do processo", em cima deste e no "Repositrio de definio de processo" que o motor de processo executa seu trabalho. No "Repositrio de definio de processo", os dados podem ser inseridos, alterados ou excludos, isso com o auxlio do componente de instalao e configurao que tm a definio das configuraes (ou parametrizaes) do sistema BPMS. Como citado anteriormente, o BPMS possui um painel de controle de processo em que se podem observar os status das atividades. Esse acompanhamento se d por meio do componente de "monitoramento e gerenciamento". O "Framework de conectores" e o "middleware" so importantes para que ocorra a integrao e a transparncia no sistema BPMS, pois as atividades desenvolvidas podem no estar no mesmo ambiente de execuo. Na situao em que esses componentes so utilizados demasiadamente, o prprio BPMS deve controlar o status do processo em que utilizado o "gerenciador de transao". Para Cruz (2010), o BPMS possui um ciclo de vida que est dividido nas seguintes etapas: programar ou diagramar o BPMS: colocar em prtica a anlise, desenho, redesenho da modelagem e a organizao dos processos de negcio mapeados no BPM. Cada atividade pode possuir eventos, podendo ser no momento da entrada na atividade, no processamento ou em sua sada; testar e simular o BPMS: uma preocupao pela quantidade de componentes e por envolver grande nmero de hardware diferentes, nesse caso, teste significa verificar se os componentes esto definidos corretamente e se o hardware est configurado conforme esperado, aps isso a preocupao est na simulao com a equipe e o usurio final;

40 treinar os usurios: necessrio que ocorra antes da implantao, para cada envolvido entender suas responsabilidades; implantar o BPMS: para implantar necessrio analisar o tipo, a natureza e o local em que o processo ser executado. Existem quatro tipos de execuo: o com descontinuidade total do processo em operao no qual dois processo no podem existir ao mesmo tempo; o com descontinuidade parcial do processo, podendo ser

desmembrado em sub-processos; o com sobreposio do processo em operao que praticada para poder obter melhoria com os programas de qualidade; o em paralelo com o processo em operao que gera dupla carga de trabalho por atuar em dois processos ao mesmo tempo. Valle e Oliveira (2010, p. 150) apresentam as tecnologias que so integradas ao BPMS e comentam que essas foram emprestadas de outros ambientes para uso do BPMS e que nenhuma linguagem foi inventada para o software. Seguem as tecnologias: Ferramentas para Modelagem de Organizaes; Ferramentas para Modelagem de Processo; Ferramentas para Estatstica; Ferramentas para Simulao; Ferramentas para Gerenciamento de Regras de Negcio; Aplicaes de BPM; Ferramentas para Monitorao de processos; Ferramentas para Desenvolvimento de Software; Ferramentas EAI (Enterprise Application Integration ) ; Ferramentas para SOA (Service Oriented Architecture); Ferramentas para Gerenciamento do Ambiente Workflow ; Servidor de Aplicaes; Linguagem BP (Assembly); ERP, CRM e outros softwares e aplicaes; BI (Business Intelligence) e Data Warehouse .

41 2.3.1 Ferramentas BPMS

Segue a lista de Business Process Management Sutes (IPBPM, 2011): Adobe - LiveCycle ES2; Appian - Appian 6 BPM Sute; AuraPortal - Auraportal 4.0; BizAgi BizAgi; Cordys - Cordys BPMS; Exact - Exact e-synergy; EMC - Documentum Process Suite; FlowCentric - FlowCentric Suite BPM; Fujitsu - Fujitsu Interstage Suite; HandySoft - BizFlow BPM; IBM - IBM BPM Suite; Lombardi - Lombardi TeamWorks 7; Openwork Openwork; Oracle - Oracle BPM Suite; PegaSystems - Smart BPM Suite; Savvion - Savvion BPM Suite; Singularity - Singularity Process Platform; Software AG - WebMethods BPMS; SoftExpert - SoftExpert BPM Suite; Tibco - iProcess Sute; Ultimus - Ultimus Adaptive BPM Sute; Vitria - M30 BPMS; InfoSistema iFlow.

Ferramentas BPMS livres, segundo Dvalos (2011): BONITA SOFT; INTALIO; ORQUESTRA BPM;

42 TIBCO; jBPM; Oryx Editor BPM; SIGNAVIO; SAVVION BPM; Jira e Confluence.

2.3.2

Workflow

O modelo Workflow est sob a responsabilidade de uma organizao chamada de Workflow Management Coalition (WFMC) que gera as especificaes do Workflow. (CRUZ, 2006). Uma das limitaes do uso do Workflow, apresentada por Cruz (2006, p. 51), o nmero de transaes que o Workflow pode processar por dia. Segundo Cruz (2010, p. 131), [...] o modelo conceitual foi construdo em cima de 3Rs: Roles (papeis), Rules (regras) e Routes (rotas) . Para Cruz, o Workflow foi o responsvel pela criao do elemento regra de negcio. Segundo Gartner (2008, apud Ko, 2009), BPM no a tecnologia, mas sim a disciplina orientada para a gesto de processo, enquanto o Workflow a tecnologia encontrada no processo de gesto de negcios. As limitaes do Workflow esto na integrao de sistemas com o fluxo de trabalho da empresa, em que nem servios ou mesmo tecnologias baseadas em SOA so utilizadas. Outra questo levantada pelo autor a falta de informaes inerente e ferramentas de diagnstico que facilitam a identificao de erros e falhas em tempo real. (KO, 2009). Conforme ULTIMUS (2011), a diferena que existe do Workflow para o BPM que o fluxo de processo fixo, sem possibilidade de prever vrios caminhos, em que a anlise e informaes do contedo so muito bsicas, existindo limitaes na integrao de sistemas, permitindo apenas dados, recuperao de documentos e sequenciamento de tarefas estabelecidas como regras pr-definidas.

43 2.4 BR (BUSINESS RULES )

Hay & Heaky (2006, p. 107, apud Baldam et al., 2010) afirmaram que as regras de negcio (Business Rules, ou BR) podem ser entendidas como uma descrio que define ou restringe certos aspectos do negcio. Baldam et al. (2010) comentam que necessrio identificar as regras do processo e deposit-las em repositrio (banco de dados, por exemplo), de modo que todos possam consultar em um nico ponto. A regra de negcio toda norma ou tudo aquilo que a lei ou o uso comum determina a respeito de qualquer transao que envolve uma determinada organizao (ALVARENGA, 2007). As regras so utilizadas em: softwares, hardware, banco de dados, pessoas, documentao e procedimento. Para que seja efetuada qualquer ao existe uma regra de negcio associada e necessrio que essas sejam bem definidas para que funcionem como um facilitador na fase de manuteno do ciclo de vida de um software. A autora comenta que as regras devem ser modeladas de forma precisa e consistente, necessrio ainda que as regras sejam formalizadas, tendo um estudo aprofundado de cada regra para que seja descrito de forma compreensiva e o conhecimento sobre as mesmas fique preservado. (ALVARENGA, 2007).

2.4.1

BRE (Business Rules Engine)

Mecanismo de regras de negcio conceituado por Chisholm (2004, p. 3, traduo nossa) como [...] aplicaes de software que contm definies de regras de negcio.. E complementa que essas regras so trabalhadas a partir de motores. Chisholm (2004, p. 1-2) comenta que as regras de negcios podem ter diferentes significados para diferentes pessoas e, de acordo com GUIDE, um grupo industrial, que utiliza o sistema, BRE uma afirmao que define ou restringe aspectos dos negcios Cruz (2010, p. 132) comenta que no possui software que tem o mesmo poder de criar definies de regras do que o Workflow ou BPMS. E complementa:

44
Regras de negcio possibilitam a execuo correta das tarefas que, por qualquer motivo, sejam criticas em um procedimento. necessrio analisar cada tarefa e descobrir os detalhes que possam fazer a criao de regras de negcio imprescindvel para a correta execuo da tarefa. So as regras de negcio que dizem quando e como fazer uma tarefa.[...]

Para Worthington (2008), os motores de regras separam as regras de negcio do cdigo do programa, podendo ser frequentemente alteradas sem interveno. Tratam-se da definio e execuo da regra. O autor conceitua o BRE:
Um Motor de Regras de Negcio uma parte sofisticada do software que permite aos usurios de negcio definir, simular e aplicar scores, regra de negcio, estratgias e decises por meio de uma vasta gama de rea de atuao de clientes, de tipos de produtos e de plataformas de gerenciamento de clientes.

J, Ghalimi (2006) afirma que para um BPMS funcionar necessrio um motor de regras de negcio, sendo que no h nenhuma maneira padro para realizar essa integrao. Caso houvesse, as regras de negcio seriam definidas como ocorrem na modelagem de processos de negcio, usando BPMN (Business Process Modeling Notation ) e cdigo de BPEL (Business Process Execution Language). Para verificar as vantagens, necessrio alinhar o ciclo de vida da regra de negcio com o dos processos de negcio. E para o autor umas das funes do BPMS :
[...] examinar as vantagens e potencialidades oferecidas pelo motor das regras de negcio no apenas para regras de negcio, mas tambm em que ligar as regras para selecionar que execuo de um servio dever ser usada, como uma interface de usurio deve ser costurada aos usurios finais especficos, e quando escalar um alerta ao gerente de TI quando algumas excees de nvel de sistema so geradas [..]

2.4.1.1 Utilizao de BRE

Essas aplicaes computadorizadas so utilizadas basicamente pelas empresas para gerenciar informaes. Conforme Chisholm (2004), no mercado, esto disponveis dois grupos principais de softwares: 1 - Motores de inferncia que lem informao de um banco de dados e operam regras para encontrar respostas a questes do usurio;

45 2 - Motores de verificao de compatibilidade e armazenamento em banco de dados depois de calculados os resultados.

2.4.1.2 Vantagens na sua aplicao

O autor Chisholm (2004, p. XX-XXI) cita algumas vantagens para aplicao dos motores de regras dos negcios: maior velocidade de implementao; gerenciamento de diversidades; auditorias; compatibilidade de engenharia.

Para Chisholm (2004), oportuno evidenciar que o preo para se criar um BRE altssimo, e que um BRE (Business Rules Engine) deve ser aplicado em empresas e negcios de grande complexidade e responsabilidades. Para tanto, as organizaes podem optar por ferramentas BRE de pacotes fechados.

2.4.2

BRMS (Business Rule Management System)

De acordo com Ross (2009), o Sistema de Gerenciamento de Regras de Negcios (BRMS) coloca disposio das pessoas que comandam as empresas, elementos precisos e confiveis para uma tomada de deciso no dia a dia da operao dos seus negcios, por meio de tcnicas e processos que oferecem anlise, rastreabilidade e filtragem, necessrios a uma deciso lgica. Ross (2009), ainda complementa que convm salientar que o foco do BRMS est em gerenciar a deciso como um problema do negcio e no como um problema tcnico. Segundo Worthington (2008), BRMS [...] conjunto completo de softwares que podem incluir um BRE, um repositrio de regras e de ferramentas de teste de desenho de

46 regras. Complementa, ainda, que as aplicaes de Motor de Regras de Negcio melhoram o tempo de resposta de uma alterao de estratgia de decises em curto prazo. Para Deitert e McCoy( 2007, apud Azevedo et al., 2009), o BRMS complementa as funcionalidades do BRE (Business Rules Engine). No inicio a ferramenta era chamado de BRE e, para suprir as necessidades advindas da evoluo e complexidade das regras, surgiu o BRMS. As ferramentas BRMS facilitam a criao, classificao, verificao,

desenvolvimento e execuo de regras, e composta pelos componentes: motor de execuo, repositrio, ambiente de desenvolvimento integrado, modelo de simulao de regras, monitoramento, anlise, template de regras, gesto e administrao. Ghalimi (2006) coloca, no seu artigo, que O BPM (Business Process Management) 2.0 faz do Sistema de Gerenciamento de Regras de Negcio (BRMS) parte do BPMS, de modo que somente uma plataforma tenha que ser controlada, e o ciclo de vida de processos dirigido a regras aerodinmico. Conforme Ross (2009), o BRMS tem por meta assegurar que o conhecimento bsico dos negcios esteja sempre acessvel s pessoas autorizadas e que as polticas dos negcios, regulamentos e obrigaes contratuais sejam interpretadas de forma confivel, sem redundncia, e de forma transparente.

2.5

BPEL (BUSINESS PROCESS EXECUTION LANGUAGE)

Segundo Silva (2009), a linguagem BPEL um padro criado pela OASIS (Organization for the Advancement of Structured Information Standards) para a execuo de processos de negcios, descrevendo como ocorre o relacionamento entre os diversos Servios Web participantes de uma composio. Complementa que a estrutura de programao dessa linguagem muito parecida com as demais linguagens possibilitando ao Processo de Negcio ser visto como algoritmo. Ainda comentado em seu artigo que o BPM 2.0 trabalha graas ao BPEL, no havendo necessidade de escrever linha de cdigo do BPEL, sendo, para isso, utilizada uma ferramenta que gere o cdigo necessrio. Seguem outros comentrios do autor:
[...] usar um motor de processos que suporte BPEL de forma nativa assegura que os processos que so distribudos nele podero ser distribudos em outro motor de

47
processos tambm. Tanto quanto eu posso dizer, esta a melhor poltica de segurana que todo o cliente poderia ter.

Um processo BPEL pode ser sncrono ou assncrono. Um processo BPEL sncrono bloqueia o cliente (aquele que est usando o processo) at que o processo termine e retorne um resultado para o cliente. Um processo assncrono no bloqueia o cliente [...]. Geralmente, os processos assncronos so usados para processos de longa durao, e os sncronos so usados para processos que retornam um resultado em um tempo relativamente curto. Se um processo BPEL usa servios Web assncrono, o prprio processo geralmente tambm assncrono.

Para Hurwitz et al. (2009, p.102), com a evoluo do padro Web Service foi criada a linguagem WS-BPEL (Web Sevices Business Processing Execution Languagem linguagem de Execuo de Processamento de Negcio Web Service). A linguagem descreve os processos com mensagens que so transmitidas aos Web Services. O processo de negcio possui vrios elementos que precisam ser orquestrados para que a empresa consiga conduzir bem o negcio. Fazendo de forma correta esta orquestrao, a empresa ser capaz de monitorar o desempenho do processo e dar seu devido suporte. (HURWITZ et al., 2009). Ghalimi (2006) coloca, no seu artigo, que BPMN e BPEL fazem uma combinao extremamente poderosa, porque apresentam um caminho do diagrama ao cdigo sem ter que realmente escrever o cdigo.

2.6

BAM (BUSINESS ACTIVITY MONITORING)

Com a evoluo do BPM, houve a necessidade de mtricas sobre os processos, segundo o autor Ghalimi (2006) com BPM 2.0, o BAM - Business Activity Monitoring ou Monitoramento das Atividades de Negcio, parte da soluo total. Em vez de ser um componente opcional, tambm, descrito que no h uma maneira padro de integrar um BPMS com uma plataforma BAM. Para o autor, o BAM deve ser sincronizado com o ciclo de vida de processos de negcio, ele uma ferramenta que ajuda na depurao, na eliminao de erros e simulaes durante a modelagem.

48 Conforme detalhado por Cruz (2010, p. 201), BAM foi criado como metodologia para permitir um controle mais preciso de tudo que feito dentro da organizao e em tempo real, [...]ao em tempo real. Segundo Baldam et al. (2010, p. 119), o monitoramento das atividades de negcio (BAM) iniciou por volta de 2002/2003, estimulado pelo interesse em BPM, que facilitou a compreenso entre as atividades operacionais em tempo real de TI e empresariais. O BAM focado nas transaes e eventos dividido em quatro atributos-chave conforme (BALDAM et al., 2010, p. 120-122): volume: por meio da execuo dos processos de negcio, um dos objetivos do BAM rastrear os volumes gerados pelas transaes realizadas durante a execuo do processo. Essas transaes so resultados dos eventos de negcio. A seguir, alguns exemplos de volumes: Nmero de transaes de negcio, Nmero de mudanas em um registro, Nmero de itens consumidos, Nmero de chamadas, Nmero de erros, entre outros. Por meio desses itens de medio, empresas podem, por meio de ferramentas BAM, gerarem alertas ou tomarem alguma ao quando algum evento acontecer. Normalmente, as informaes de monitoramento so exibidas em painis de controle, chamados de dashboard, o que disponibiliza aos gestores a observao, desempenho e reao aos eventos de negcios; velocidade: a velocidade tambm outro fator relacionado s transaes de negcio e pode ser definido como o tempo relacionado s operaes de negcio. Por meio do atributo velocidade, tais caractersticas podem ser monitoradas e exibidas para que eventos possam ser habilitados, possibilitando a melhoria relacionada ao fator tempo dos processos. A seguir, alguns exemplos de velocidade: tempo de espera entre eventos; tempo restante para concluso do evento; rendimento do processo, entre outros. Por meio dessas medidas so disponibilizadas as informaes necessrias e o entendimento de como o negcio est caminhando, o que permite analisar o desempenho organizacional e a realizao de predies por parte dos executivos sobre o que vai acontecer em relao aos processos de negcio; erros: o atributo erro um fator importante e que deve ser levado em considerao pelos gestores. Atualmente, mesmo sistemas fortemente testados e utilizados no mercado, erros podem ocorrer, seja por causa de

49 hardware, software, erro humano ou falhas nos processos. Por meio de ferramentas BAM, os erros podem ser localizados de forma eficaz, podendo ser realizadas anlises sobre sua frequncia, motivadores do erro, permitindo a soluo pontual dessas ocorrncias; condies especiais: so definidas pelos executivos e representam eventos pertinentes ao negcio, aspectos especficos sob a tica dos executivos. Assim, como as medidas, Volume, Velocidade e Erro, ferramentas BAM localizaro essas condies especiais, disponibilizando informaes estatsticas, alertas ou executando eventos quando elas forem encontradas. Por exemplo, uma organizao gostaria de ser alertada quando uma compra acima de um determinado valor fosse realizada ou alguma anormalidade em relao ao negcio fosse encontrada. As condies especiais so base dos KPIs (Indicadores chave de desempenho), permitindo a combinao de volume, velocidade, erro, com conhecimento especfico do negcio. Um dado importante que, por meio da utilizao do BAM, o uso de medio e condies especiais produziu melhorias de produtividade da ordem de 40% ou mais.

2.6.1

KPI (Key Performance Indicator)

Segundo Kerzner (2004, p. 297), os KPIs so tpicos internamente compartilhados que permitem maximizar o que se faz bem e corrigir o que se faz mal. Os KPIs so as melhores prticas internas que possibilitam atingir os fatores crticos de sucesso (CSFs) e complementa que servem para apoio do gerenciamento das reas, apoio a alta administrao, podendo ser utilizada como uma metodologia. Para Schlter (2009), o KPI um "excelente mtodo para provocar a sinergia de aes de toda empresa, orientando-os aos objetivos sistmicos do seu negcio", orientando na convergncia entre as aes internas e externas da empresa por meio de mtricas quantificveis. Caractersticas para construo de KPIs (SCHLTER, 2009) so:

50 o valor do KPI deve ser estratgico: indicadores pontuais devem fazer parte do planejamento estratgico; o KPI deve ser sistmico: deve ser integrado a outras reas da empresa; os valores de desempenho devem ser desdobrados: as metas devem ser repartidas a cada processo; deve ter um modelo robusto: deve ser robusto para mostrar resultado coerente e verdadeiro; o modelo deve ser de fcil assimilao e obteno: ser simples de ser compreendido e obteno de forma fcil; o KPI pressupe responsabilidade, mas tambm autoridade: autoridades para o gerenciamento das melhorias. Marr (2009) identifica que um problema do KPI ele ser utilizado em demasia, muitas vezes, descrevendo qualquer tipo de dados de medio e as mtricas de desempenho de negcio, ao invs de identificar e projetar cuidadosamente os indicadores para avaliar o desempenho.

2.7

SOA (SERVICE ORIENTED ARCHITECTURE)

A definio de SOA para Cruz (2010, p. 141) Ferramentas, baseadas em padres abertos (no-proprietrios), que permitem integrar, de forma rpida e dinmica, softwares, sistemas e aplicaes rodando em plataformas iguais e/ou diferentes, e esses aos processos de negcios da organizao. Permitiu, tambm, a introduo do conceito de centralizao dos servios a partir de Web Service, facilitando integrao para sistemas de plataformas heterogneas. Cruz ainda comenta que SOA surgiu em funo da necessidade existente de integrao entre diferentes plataformas de hardware e software [...]. Baldam et al. (2010, p. 104) comentam que SOA apresenta-se como uma interessante alternativa. Segue o conceito de SOA para o autor:
[...] O conceito expressa a inteno de disponibilizar aplicativos ou rotinas independentes como servios, em rede de computadores (Internet e Intranet), comunicando-se por padres abertos. A maior parte do padro SOA se utiliza de Web Services (RPD, DCOM, ORB, SOAP, REST e WSDL), entretanto pode-se utilizar qualquer tecnologia padronizada, baseada em Web.

51 Os processos em SOA (servios de Web vinculados) apiam e auxiliam os sistemas de processo de negcio, no devendo estes ser confundidos com o prprio processo de negcio (KO, 2009). As diferentes plataformas de vrios sistemas, antes de existir a concepo de SOA, eram integradas por meio de interfaces rgidas e proprietrias, alm de apresentarem altos custos para integrao. No ano de 2000, o World Wide Web Consortium, W3C, padronizou Web Service emergentes e determinou especificaes para o uso do XML (eXtended Markup Language) e protocolos de comunicao a fim de possibilitar a interoperabilidade das plataformas heterogneas. SOAP (Simple Object Access Protocol) o nome dado ao protocolo que faz a distribuio das informaes, como se fosse um envelope, em que o cdigo XML o contedo da transao conforme figura 7. (CRUZ, 2010).

Figura 7 Distribuio das Informaes em SOA. Fonte: Cruz, (2010).

2.7.1

Cuidados com o SOA

Para Cruz (2010, p. 146), os cuidados que se deve ter com a adoo do SOA so: segurana: por ser ambiente aberto, so necessrios investimentos para manter a segurana; lentido: tambm, por ser aberto, pode ocorrer lentido, prejudicando empresas que necessitam de rapidez nos servios; desorganizao informal: pode ocorrer desorganizao devido grande criao de servios Web ;

52 anlise, desenho, redesenho, modelagem, organizao, implantao, gerenciamento e melhoria de processo de negcio: ter sistemas que no esto ligados organizao.

2.7.2

Benefcios

Segundo Cruz (2010, p. 144), a adoo de SOA proporciona alguns benefcios, como: identificao da interao entre usurios, negcios e dados; criao em camadas, possibilitando a integrao entre mltiplos sistemas, sempre que a soluo no puder ser desenvolvida num nico modelo; composio de padres que representam as combinaes de mltiplos sistemas diferentes; modelagem da soluo, que prov um layout conceitual, descrevendo como os componentes das aplicaes e dos dados interagem com os negcios.

2.8

WEB SERVICE

Segundo Hurwitz e outros (2009), o Web Service surgiu devido necessidade de prestao de servios e disponibilizao informaes na Web de forma organizada e padronizada. Os padres Web Services so o XML (Extensible Markup Language) em que os programadores definem dados que outro programador consegue entender, padronizando comandos, WSDL (Web Service Description Language) linguagem especial que descreve todos os comandos que um componente de software aceita de outro, e o SOAP (Simple Object Access Protocol) protocolo que permite a comunicao dos componentes do software. (HURWITZ et al., p. 62).

53 Conforme Nextgeneration (2011), "o BPM pode tambm ser visto como base para o Web Service ou o redesenho da arquitetura de processos por meio da distribuio de componentes em redes remotas colaborativas e para a metodologia de gesto de projetos e recurso de TI". O Web Service no BPM o responsvel pela estrutura bsica para a gerao de mensagem. Para o autor, o uso do Web Service "facilita a proliferao em larga escala de processos comerciais automatizados e distribudos. Para o futuro, o autor comenta que os Web Services podem ser usados para extrair mtricas dos processos de negcios, e o BPM pode usar Web Service como um agente de automatizao, envolvendo, em alguns casos, uma aplicao terceira em qualquer passo do processo de negcios.

2.9

FRAMEWORKS PARA DESENVOLVER SISTEMAS BPMS

Este item descreve o funcionamento de alguns Frameworks utilizados para o desenvolvimento de sistemas BPMS.

2.9.1

JBoss Drools

Segundo Lui (2011), o JBoss Drools utilizado no desenvolvimento de sistemas baseados em regras complexas que de outro jeito seriam desenvolvidas programaticamente em Java, assim como no desenvolvimento de sistemas para mercados muito dinmicos, em que regras mudam com frequncia. Ele possibilita a criao de aplicaes dinmicas e possui a definio de regras de negcio de forma natural e declarativa. Para a sua utilizao, necessrio conhecer sua API (Application Programming Interface) que utiliza arquivos, seguindo a extenso DRL. A plataforma JBoss Drools possui uma implementao de regras de negcio, lanada em 2011, hoje abrange outros conceitos, como Processamento de Eventos Complexos (Complex Event Processing ou CEP) e Workflows. O autor ainda comenta que com o Drools possvel programar regras de negcio declarativamente, separar e centralizar

54 as regras de negcio de um sistema e gerenciar regras, alterando-as e versionando-as dinamicamente (LUI,2011). A atualizao do Drools vem com o lanamento do Business Logic integration Platform (BLiP) e est dividida em (LUI, 2011): Drools Guvnor: sistema de gerenciamento de regras (Business Rule Management System ou BRMS) que permite a organizao,

versionamento, verificao e edio de regras; Drools Expert: motor de regras da plataforma que executa regras de negcio dado um conjunto de fatos; Drools Flow: motor de processos da plataforma que possui uma forma de integrao com as regras de negcio; Drools Fusion : motor de processamento de eventos complexos (Complex Event Processing ou CEP), que uma forma de regra de negcio que leva em conta aspectos temporal e streaming de eventos; Drools Planner: para a resoluo de problemas usando heursticas que retornam a resultados considerados o melhor possvel para problemas que no possuem uma soluo algortmica definitiva.

2.9.2

JBoss jBPM 5

JBoss jBPM um Framework que permite a gesto de processos de negcio e a orquestrao de um processo de forma flexvel e escalvel. Essa ferramenta permite que as empresas criem e automatizem os processos de negcio de uma forma que coordenem pessoas, aplicaes e servios. O objetivo principal o de reduzir o tempo de desenvolvimento e integrar os servios implementados em SOA. (JBOSS, 2011). Sua arquitetura suporta os componentes Java e vrias linguagens de processo, tornando esse um diferencial importante em relao a outros Frameworks. Suporta a jPDL (Process Definition Language), uma linguagem orientada a processos e declarativa, utilizada para gerenciamento de fluxo de trabalho, o JBoss jBPM tambm suporta o gerenciamento de tarefas humanas e a linguagem BPEL para orquestrao de Web Service e para construo de

55 fluxo de pgina. Em seu ambiente possvel a visualizao grfica e do cdigo XML do fluxo de trabalho que est sendo desenvolvido (JBOSS, 2011).

Figura 8 Arquitetura jBPM. Fonte: Orana (2011).

Segundo Orana (2011), o jBPM fornece uma base slida para as aplicaes, possuindo o mdulo BAM para monitoramento de processos de negcio. Segundo a Mastertheboss (2011), as principais caractersticas do jBPM 5 so: execuo BPMN2 nativa; altamente configurvel, incorporando um motor de processo, em que utiliza um mecanismo de processo genrico denominado (PVM); processos de domnio especfico e integrao de eventos por meio do motor de regra Drools e fluxo de trabalho; independe do servio de tarefas humanas (usando WS-HT); ferramentas Web para tarefas como criao de processos BPMN2, implantao, gesto, comunicao, entre outras tarefas; capacidades de migrao do jBPM 3 e 4 (jPDL 3, 4 a BPMN2).

Segundo a comunidade, o jBPM um flexvel sistema BPMS com foco principalmente em pessoas tcnicas. jBPM5 a verso mais recente do projeto jBPM e foi criado baseado na especificao BPMN (Business Process Modeling Notation) 2.0, suportando o ciclo de vida de processo de negcio. O mesmo est baseado no projeto Drools, que unifica diversos projetos, combinando processos, regras e eventos.

56 2.9.3 Activiti

Este framework trabalha com um fluxo de trabalho leve, com a plataforma destinada a pessoas de negcios, administradores e desenvolvedores. um software livre distribudo pelo Apache. Ele funciona com qualquer aplicativo Java e trabalha com um ou mais computadores em conjunto. Sistema leve e que baseado em conceitos simples, ele foi construdo em cima da verso BPMN (Business Process Modeling Notation ) 2.0 (ACTIVITI, 2011). Segundo Activiti (2011), os componentes que o compem so: Activiti Engine: conhecido como o corao do projeto, rodando dois processos BPMN simultaneamente; Activiti Explore: aplicao Web que permite que todos os usurios do sistema tenham acesso ao motor de execuo, como: gerenciamento de tarefas, visualizao de relatrios e verificao de instancias de processos; Activiti Probe: aplicao que fornece recurso de administrao e de infraestrutura para que seja verificado se o sistema est operando e funcionando corretamente; Activiti Modeler: um aplicativo Web de edio grfica de processo, sendo armazenado por um servidor em um sistema de arquivo central; Activiti Ciclo: uma aplicao Web no qual facilita a colaborao de pessoas de negcio, desenvolvedor e pessoal operacional.

2.9.4

Signavio

A Signavio uma empresa alem que oferece framework para modelagem e anlise de processo. Seu objetivo de envolver toda a organizao no processo de negcio, tornando mais fcil a viso dos processos como um todo, para que sejam estipuladas melhorias, bem como uma melhora no auxlio colaborao e a contribuio. (SIGNAVIO, 2011).

57 O produto oferecido pela empresa um Editor de Processo Signavio (Signavio Process Editor) no qual possui um inovador processo de gerenciamento Web , permitindo incorporar mais pessoas no desenho do processo. No necessrio efetuar muito investimento, e o sistema pode ser hospedado no prprio servidor da Signavio , neste caso, estipulada a quantia de pessoas que estaro acessando ao repositrio de processo, ou o sistema poder ser instalado no prprio servidor da empresa que poder ser acessado pela prpria intranet. (SIGNAVIO, 2011). Conforme Signavio (2011), seguem alguns recursos do sistema: comparao de diagrama: o modelo mostra realce no que foi alterado em um diagrama; formatao de diagrama: podem-se formatar os elementos no diagrama; criar um sub-processo baseado em um pedao do processo: nesse recurso, podem-se selecionar alguns elementos e transform-los em um subprocesso; ganho de espao: nesse recurso, possvel solicitar mais espaos nos processos criados; ponto de vista simplificado no diagrama: opo de selecionar uma parte do processo para mostrar para outras pessoas, podendo esconder outras piscinas. Existem vrias organizaes utilizando dos servios da Signavio. Das citadas neste trabalho tem-se a Activiti e jBPM.

2.10 CONCLUSES FINAIS DO CAPTULO

O Gerenciamento de Processos de Negcio tem se consolidado atualmente como um grande aliado das organizaes, podendo ser utilizado em pequenas, mdias e grandes empresas, fortalecendo a comunicao e oferecendo meios para que seus processos sejam moldados conforme sua dinmica organizacional. Por meio da utilizao dos sistemas BPMS, alm do ganho com a automao, a plataforma age como articuladora por onde todos os processos so iniciados e gerenciados, o que, para os usurios finais torna-se um facilitador, agregando maior dinamismo e velocidade

58 ao negcio. Aliando-se plataforma um motor de regras de negcio, TI e rea de negcios se tornam parceiras desempenhando papel fundamental para concretizao dos objetivos estratgicos definidos pela organizao. Concluindo, uma plataforma BPMS no deve ser considerada a soluo para todos os problemas, mas, sim, uma abordagem que, se utilizada corretamente, aproveitando todos os recursos disponveis e, principalmente, apoiada pelos usurios, pode se tornar uma grande habilitadora para o gerenciamento efetivo de seus processos de negcio.

59 3 MTODO

Este captulo apresenta a caracterizao do tipo de pesquisa, etapas, proposta da soluo, demonstrando cada mdulo e suas ligaes, as delimitaes, bem como o cronograma para o projeto.

3.1

CARACTERIZAO DO TIPO DE PESQUISA

Segundo Andrade (2001), a "pesquisa cientfica um conjunto de procedimentos sistemticos, baseados no raciocnio lgico, que tem por objetivo encontrar solues para os problemas propostos mediante o emprego de mtodos cientficos. Para este projeto, a classificao ser subdividida seguindo algumas perspectivas, que so: quanto natureza, considerada uma pesquisa aplicada, pois o objetivo deste projeto utilizar o conhecimento adquirido para a aplicao prtica, ou seja, o desenvolvimento de um sistema a partir de novas tecnologias e recursos que facilitem o uso dos usurios. quanto forma de abordagem, classificada em qualitativa, pois ser realizada uma validao do sistema junto a um usurio pr-definido a partir de entrevistas e observaes conduzidas pelos Elaborao dos autores, 2011. em relao aos objetivos, exploratria, em que, segundo Silva e Menezes (2005), enquadram-se como pesquisa bibliogrfica e estudos de caso. Esta proposta se fundamenta a partir das pesquisas realizadas nas principais fontes bibliogrficas estudadas e, tambm, ser aplicada a um sistema proposto para uma empresa fictcia.

60 3.2 ETAPAS

As etapas para elaborao deste projeto seguem a seguinte estrutura: pesquisa sobre ferramentas de motores de processos e de regras de negcio; modelagem; desenvolvimento; testes; implantao e a definio de um estudo de caso para a validao de todos os mdulos do sistema. A Figura 9 ilustra essas etapas.

61

Figura 9 Etapas metodolgicas. Fonte: Elaborao dos autores, 2011.

62 3.3 PROPOSTA

A proposta desta monografia consiste em desenvolver um sistema BPMS para que processos possam ser definidos e executados por meio de um ambiente Web. A Figura 10 ilustra os mdulos que trabalharo de forma integrada para proporcionar a definio e automatizao de processos. O Motor de Processos e Motor de Regras de Negcio so as peas principais do sistema BPMS, que so responsveis principalmente pela execuo de processos e regras de negcio.

Figura 10 Mdulos do sistema BPMS. Fonte: Elaborao dos autores, 2011.

A Figura 11 ilustra o ambiente administrativo, que todas as etapas de elaborao de processos sero definidas. O usurio administrador, ao se autenticar no sistema, iniciar pela modelagem do processo, desenhando graficamente o fluxo de atividades; aps essa etapa, ser necessria a definio dos dados, em que esses podero ser, por exemplo, para um processo de compras o valor da cotao ou nome de cada empresa. Seguindo, tem-se a etapa de criao de formulrios, em que para cada atividade poder ser definido um formulrio para preenchimento. Aps, segue-se a criao de regras de negcio. Essa uma etapa muito importante e a que deve ser dada muita ateno. Toda organizao possui diversos processos, para cada um diversas regras esto associadas. Cada

63 regra reflete algum aspecto da empresa, e essas devem ser bem analisadas para que fatores importantes no sejam deixados de lado. Aps a concluso das etapas anteriores, o processo pode ser implantado para utilizao na organizao.

Figura 11 Proposta Ambiente administrativo Elaborao de processos. Fonte: Elaborao dos autores, 2011.

A Figura 12 ilustra o portal de processos que ser acessado pelos usurios da organizao. por meio dele que processos so executados e cada participante interagir com esses por meio de formulrios previamente definidos pelo administrador.

64

Figura 12 Proposta Portal do usurio. Fonte: Elaborao dos autores, 2011.

A partir da autenticao, o usurio est apto a interagir com os processos aos quais est associado. Para isso, ele pode iniciar um processo ou, por meio de sua caixa de entrada, visualizar ou dar continuidade em processos em andamento. importante salientar que o usurio poder a qualquer instante verificar o status dos processos de que ele participa. A Figura 13 ilustra a estrutura tecnolgica, bem como tecnologias envolvidas para elaborao do projeto. Por ser um sistema Web, o mesmo poder ser acessado por meio de qualquer computador com acesso internet.

65

Figura 13 Arquitetura Tecnolgica. Fonte: Elaborao dos autores, 2011.

3.4

DELIMITAES

Uma plataforma BPMS tem por objetivo principal a automatizao de processos de negcio, disponibilizando para isso diversas ferramentas. Dessa forma, por existir diversos mdulos agregados ao BPMS e cada um com relativa complexidade de desenvolvimento, o projeto possui as seguintes limitaes: Ser desenvolvido um sistema BPMS, subdividido nos seguintes mdulos: ferramenta para desenho de processos Os processos sero desenhados, seguindo a notao BPMN, sendo que, apenas os elementos bsicos da notao sero contemplados; ferramenta para definio de dados Dados sero definidos para a utilizao nos processos, sendo que, apenas os tipos bsicos, como numricos, textuais e booleanos faro parte do escopo do projeto;

66 ferramenta para desenho de formulrios Formulrios sero definidos para interao com os usurios dos processos, para isso, caractersticas visuais, como layout, disposio de campos, cores e formulrios complexos no faro parte do escopo do projeto, abrangendo apenas caractersticas bsicas; ferramenta para definio de regras de negcio Regras de negcio so diferentes para cada organizao, podendo assumir grande

complexidade, assim, apenas regras simples, como condicionais, validaes e clculos simples sero contemplados; portal de processos O portal de processos a interface principal com o usurio final, em que esses interagiro com os processos aos quais esto associados. Dessa forma, sero disponibilizadas apenas operaes bsicas para manipulao dos processos, como consultas de tarefas, preenchimento dos formulrios e acompanhamento de suas atividades.

No far parte do escopo desse projeto o desenvolvimento de funcionalidades como: integrao com outras fontes de dados e/ou sistemas por meio de Web Services; mdulo BAM para monitoramento de processos de negcio; mdulo para simulao de processos; linguagem BPEL para orquestrao dos processos de negcio.

Tambm, por este projeto tratar do desenvolvimento de diversos mdulos em que alguns possuem certa complexidade, demandando, assim, tempo para pesquisa e desenvolvimento, a modelagem ser sucinta. Para isso, a modelagem, em sua maior parte, englobar aspectos mais superficiais, no se atendo a detalhes, em que no sero incorporados todos os artefatos normalmente definidos para o desenvolvimento de software.

67 4 MODELAGEM DO SISTEMA PROPOSTO

Neste capitulo, descreve-se a modelagem do sistema proposto a ser desenvolvido. Esta modelagem ser realizada de forma sucinta e considera: a Modelagem dos Processos de Negcio, a Modelagem e Descrio dos Casos de Uso e o Diagrama de Atividade dos Casos de Uso mais prximos ao usurio.

4.1

MODELAGEM DOS PROCESSOS DE NEGCIO

Conforme Dvalos (2010), a modelagem de processo auxilia um projeto de software, na medida em que facilita a abstrao dos procedimentos que definem o negcio.. Este modelo permite que o usurio navegue entre as aes, permitindo que analistas possam absorver todos os dados necessrios para o desenvolvimento do projeto. A modelagem utilizada, neste projeto, de Eriksson e Penker:
Os pesquisadores Eriksson e Penker (2000) criaram um conjunto de esteretipos capazes de contemplar a viso de um Processo de Negcio. Esses modelos refletem o ambiente e a estrutura organizacional com a qual o sistema proposto ir contribuir. Estes modelos representam uma viso inicial das atividades do negcio, sendo possvel capturar de forma significativa eventos, entradas, recursos e sadas associados ao processo de negcio. (DVALOS, 2010, p. 137).

As ligaes que esto apresentadas como entrada (input) significa que essas informaes sero utilizadas e tratadas ou somente servir como catalisador. J a sada (output) indica que o processo produziu algum objeto de valor para a organizao. E, por fim, a meta (goal) que descreve o objetivo do processo. (DVALOS, 2010). A seguir, esto sendo apresentadas as imagens da MPN, sendo a imagem 15 do usurio no qual sua ligao ao sistema para executar uma tarefa do processo, ele inicia com o login ao sistema e efetua consultas e verificaes das tarefas destinadas ao seu nome. J do administrador, imagem 14, a ao que ele executa de iniciar um projeto, ele acessa o sistema para criar os processos, efetuar o desenho, definio dos dados, definio das regras e desenho do formulrio para o usurio poder efetuar suas tarefas e, alm de tudo, ele quem controla os usurios.

68

Figura 14 Modelagem do Processo de Negcio do Administrador. Fonte: Elaborao dos autores, 2011.

Figura 15 Modelagem do Processo de Negcio do Usurio Fonte: Elaborao dos autores, 2011.

69 4.2 ANLISE DE REQUISITOS

A atividade de anlise de requisitos procura descobrir o que o cliente e o usurio querem que o sistema faa e de como ele ir se comportar perante a arquitetura que lhe concedida, abordando uma elaborao de toda a comunicao entre o sistema e o usurio e a estrutura imposta ao mesmo. (FOWLER, 2004).

4.2.1

Requisitos Funcionais

Os requisitos funcionais so levantados a partir do comportamento do sistema, que ir determinar as funcionalidades que o mesmo dever possuir. Partindo desses requisitos, os casos de uso, que ser explicado na sequncia, tero um melhor detalhamento. (LARMAN, 2005).

4.2.1.1 rea Administrativa

A rea administrativa o ncleo principal do sistema, em que todos os mdulos, como cadastros, consultas, visualizao de histrico, desenho de processos, delegao de atividades para os usurios, associao de usurios a processos e gerenciamento geral dos processos so realizados. Seguem, no quadro 2, detalhes dos requisitos citados: ID RF01 Nome Cadastrar processo Descrio O sistema dever prover funcionalidade que permita ao usurio administrador manipular o Cadastro de processo, definindo inicialmente as informaes bsicas. As operaes permitidas so: Incluso, Alterao ou Excluso de Processo.

70

RF02

Consultar processo

O sistema dever prover funcionalidade que permita ao usurio administrador Consultar processo por: Nome, Descrio, Categoria e Nmero da identificao. O sistema dever prover funcionalidade que permita ao usurio administrador Desenhar o processo seguindo a notao BPMN. As operaes permitidas so: Incluso, Alterao ou Excluso de elementos do Desenho do Processo. O sistema dever prover funcionalidade que permita ao usurio administrador manipular os dados do processo. As operaes permitidas so: Incluso, Alterao ou Excluso de Dados do Processo. O sistema dever prover funcionalidade que permita ao usurio administrador manipular os Formulrios do Processo. As operaes permitidas so: Incluso, Alterao ou Excluso de dados nos Formulrios do Processo. O sistema dever prover funcionalidade que permita ao usurio administrador manipular o Cadastro de regras de negcio. As operaes permitidas so: Incluso, Alterao ou Excluso de Regras de Negcio. O sistema dever prover funcionalidade que permita ao usurio administrador manipular o Cadastro de regras de navegao. As operaes permitidas so: Incluso ou Alterao. O sistema dever prover funcionalidade que permita ao usurio administrador manipular o Cadastro de usurios. As operaes permitidas so: Incluso, Alterao ou Ativar/Inativar Usurios. O sistema dever prover funcionalidade que permita ao usurio administrador Consultar os Usurios por: Nome, Login, Status. O sistema dever prover funcionalidade que permita ao usurio administrador Inativar ou Ativar usurios dos processos. O sistema dever prover funcionalidade que permita ao usurio administrador associar processos aos usurios.

RF03

Desenhar processo Extenso

RF04

Cadastrar dados do processo

RF05

Desenhar formulrio do processo

RF06

Cadastrar regras de negcio

RF07

Cadastrar regra de navegao

RF08

Cadastrar usurios

RF09

Consultar usurios

RF10

Inativar/Ativar usurios

RF11

Associar usurios a processos

71

RF12

Nomear formulrio

O sistema dever prover funcionalidade que permita ao usurio cadastrar/editar o nome de um formulrio. O sistema dever prover funcionalidade que permita ao usurio administrador selecionar um processo para automatizao. O sistema dever prover funcionalidade que permita ao usurio se autenticar no sistema.

RF13

Selecionar processo

RF14

Controle de acesso

Quadro 2 Requisitos Funcionais rea administrador. Fonte: Elaborao dos autores, 2011.

4.2.1.2 rea do Usurio

A rea do usurio a rea de trabalho em que o mesmo pode efetuar consultas, visualizar histrico e trabalhar com as instncias dos processos dos quais participa. O quadro 3 descreve os requisitos funcionais da rea usurio. ID RF15 RF16 Nome Consultar processos associados Cadastrar informaes nas tarefas do processo Descrio O sistema dever prover funcionalidade que permita ao usurio Consultar Processo pelo seu Nome. O sistema dever prover funcionalidade que permita ao usurio manipular as informaes das tarefas dos processos. As operaes permitidas so: Incluso e Concluso da Tarefa do Processo. O sistema dever prover funcionalidade que permita ao usurio verificar os processos que esto cadastrados em seu nome. O sistema dever prover funcionalidade que permita ao usurio acompanhar todas as etapas (histrico) realizadas em uma tarefa do processo. O sistema devera oferecer uma opo de visualizao das tarefas pendentes que esto associadas ao nome do usurio, para poder efetuar as devidas alteraes necessrias.

RF17

Visualizar processos associados Visualizar histrico da tarefa do processo Visualizar tarefas pendentes

RF18

RF19

Quadro 3 Requisitos Funcionais rea usurio. Fonte: Elaborao dos autores, 2011.

72 4.2.2 Requisitos no Funcionais

Nos requisitos no funcionais, efetuada uma anlise arquitetural (LARMAN, 2005), verificando toda a parte de hardware e de como o sistema vai se comportar perante a estrutura proposta, envolvendo a adaptabilidade e a confiabilidade da arquitetura oferecida ao sistema. No quadro 4, so descritos os requisitos no funcionais levantados: ID RNF01 NOME Controle de acesso DESCRIO Todo usurio deve ter uma conta e esta estar associada a um perfil que determinar o acesso a determinadas funcionalidades do sistema. O sistema deve ter portabilidade e ser flexvel entre os sistemas operacionais e os navegadores. A interface deve ser simples e intuitiva para facilitar o uso do sistema. O sistema deve ter um tempo de resposta de 7 segundos no mximo. necessrio capacitar os usurios para a correta utilizao do sistema. A documentao deve ser completa e bem definida para facilitar o uso do sistema.

RNF02 RNF03 RNF04 RNF05 RNF06

Portabilidade e flexibilidade Usabilidade Tempo de resposta Treinamento Documentao

Quadro 4 Requisitos no Funcionais. Fonte: Elaborao dos autores, 2011.

4.3

ATORES

O usurio do sistema conhecido como ator. O papel dele a comunicao em relao ao sistema e este se relaciona com os casos de uso. O ator pode se comunicar com vrios casos de uso e inversamente. Os atores podem ser cliente, representante de servio ao cliente, gerente de vendas. analista de produto, entre outros. (FOWLER, 2004). No sistema proposto, existe a comunicao de 2 (dois) atores, veja no quadro 5:

73

ATOR

DESCRIO

Administrador Responsvel por todas as funcionalidades do sistema. ele quem vai gerenciar todos os usurios e a execuo das atividades de todos os usurios. ele quem vai gerir o processo desde sua inicializao. Usurio o participante do processo. Ele que o responsvel pelo desenvolvimento e execuo das tarefas dos processos. Este ter o perfil conforme determinado pelo administrador. Ele somente ir usufruir do sistema.

Quadro 5 Atores. Fonte: Elaborao dos autores, 2011.

4.4

MODELAGEM DOS CASOS DE USO

A modelagem dos casos de uso serve para descrever o uso de um sistema detalhando como ser utilizado por seus clientes e scios. Os casos de uso podem ser narrativas em texto de algum autor, usando o sistema para atingir os objetivos, bem como em diagrama. Os casos de uso so essenciais para descrever a utilizao do sistema, que auxilia o usurio no cumprimento de sua meta. (LARMAN, 2005). Cada caso de uso tem um ator principal, que pede ao sistema que execute um servio. (FOWLER, 2004, p. 105). Esses passos que o ator percorre com a inteno de executar um servio devem ser detalhados nos casos de uso. Esse detalhamento deve ser desenvolvido a partir da interface com o usurio, iniciando no momento em que o usurio efetua a primeira iterao com o sistema, indicando todos os caminhos possveis, ate o momento em que o ator finaliza o programa. (FOWLER, 2004) Dos relacionamentos utilizados nos casos de uso, tem-se conforme (FOWLER, 2004): incluso (<<include>>) significa que o caminho do caso de uso est includo um outro caso de uso, ou seja, compartilham passos em comum; extenso (<<extend>>) significa dependncia. O caso de uso estendido pode alterar o comportamento somente nesse ponto da extenso.

74 4.4.1 Diagrama de Casos de Uso

Neste tpico, apresentam-se os diagramas de casos de uso que sero utilizados neste trabalho. A Figura 16 ilustra o diagrama dos casos de uso do mdulo administrador.

Figura 16 Diagrama de Caso de Uso Mdulo Administrador. Fonte: Elaborao dos autores, 2011.

75 A figura 17 ilustra o diagrama dos casos de uso do mdulo usurio.

Figura 17 Diagrama de Caso de Uso Mdulo Usurio. Fonte: Elaborao dos autores, 2011.

4.4.2

Descries dos casos de uso

Neste item, foram selecionados alguns casos de uso para ser efetuada a documentao. Nela constar a sua identificao, descrio, pr e ps-condio, os fluxos e ator envolvido. Seguindo a organizao dos itens anteriores, as partes do usurio e do administrador so descritas separadamente.

4.4.2.1 Documentao dos casos de uso do ator: Administrador

No quadro 6, apresenta a descrio do caso de uso Desenhar formulrio do processo no mdulo administrador. Seguem os detalhes deste caso de uso.

76

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Desenhar formulrio do processo. CSU05. Administrador desenha formulrio desenvolvimento do processo. Administrador. Ter selecionado uma tarefa do processo, o desenho do processo bem definido e os dados do processo devidamente cadastrados. 1. Ator seleciona o processo que deseja desenhar o formulrio; 2. Ator seleciona opo Formulrio e Dados; 3. Aps seleciona, na combo-box que se encontra no canto superior direito da pgina, a tarefa do processo que deseja efetuar o desenho do formulrio; 4. Sistema apresenta campo para efetuar a criao do formulrio no centro e do lado esquerdo apresenta paleta com os dados a serem inseridos; 5. Ator verifica formulrio: a. Se formulrio est correto executa FP 7; b. Se deseja alterar formulrio executa FA 1; c. Se formulrio esta em branco FP 6; 6. Ator arrasta os dados da paleta da esquerda para o campo de criao do formulrio e efetua sua organizao; 7. Ator salva formulrio. 1. Ator altera o desenho do formulrio e as informaes necessrias; 2. Executa FP 7. a ser aplicado no

Fluxo Alternativo Ps-condio

Formulrio pronto para a aplicao.

Quadro 6 Detalhamento do Caso de Uso CSU05 Administrador. Fonte: Elaborao dos autores, 2011.

No quadro 7, ser apresentado o caso de uso Selecionar processo, etapa essa de fundamental importncia. Na sequencia seguem as descries deste caso de uso.

77

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Selecionar processo. CSU03. Seleo de processo para efetuar a automatizao. Administrador. Possuir o cadastro do processo. 1. Ator seleciona processo atravs da combo-box Processo Atual que se encontra no canto direito superior da tela; 2. Sistema carrega informaes do processo; 3. Ator efetua alteraes cabveis.

Fluxo Alternativo Ps-condio Executada a automatizao do processo selecionado.

Quadro 7 Detalhamento do Caso de Uso CSU03 Administrador. Fonte: Elaborao dos autores, 2011.

No quadro 8, apresentado a descrio do caso de uso Cadastrar dados do processo. Segue detalhamento do mesmo.

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Cadastrar dados do processo. CSU08. Cadastrar os dados do processo para ser usado no formulrio. Administrador. J possuir o desenho do processo definido e selecionado tarefa do processo para edio. 1. Ator seleciona a aba Formulrio e Dados; 2. Sistema apresenta tela para edio; 3. O sistema apresenta do lado esquerdo uma paleta para cadastro dos dados: a. Se dados j foram definidos, o sistema apresenta todos os dados cadastrados; b. Se no foi efetuada a insero de dados, o sistema apresenta a paleta vazia;

78

4. Ator acessa a opo de cadastro de dados, que se encontra na parte superior da paleta em forma de cone; 5. Ator acessa o sistema para edio dos dados: a. Se deseja inserir dados executa FP 6; b. Se deseja excluir executa FA 1; c. Se deseja alterar dados executa FA 3; 6. Seleciona cone para adicionar dados; 7. Efetua o cadastro de dados; 8. Ator salva informaes. Fluxo Alternativo 1. Seleciona o cone de excluir; 2. Confirma excluso do dado; 3. Executa FP 8. 4. Seleciona o dado que deseja alterar; 5. Efetua alteraes do dado; 6. Executa FP 8. Ps-condio Dados disponveis para manipulao e aplicao no formulrio.

Quadro 8 Detalhamento do Caso de Uso CSU08 Administrador. Fonte: Elaborao dos autores, 2011.

No quadro 9, apresentado o detalhamento do caso de uso Cadastrar regras de negcio. As regras de negcio so associadas s tarefas. Segue o detalhamento.

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Cadastrar regras de negcio. CSU09. Cadastrar as regras de negcio para as atividades do processo. Administrador. J possuir o desenho do processo e os dados do processo. 1. Ator seleciona a tarefa do processo que deseja cadastrar a regra; 2. Sistema exibe paleta no lado direito com opo de adicionar regra tanto na entrada do processo como na sada: a. Se sistema j possuir regras ser apresentado relao das mesmas: i. Se desejar editar ou visualizar a regra registrada, seleciona o cone da seta para

79 efetuar a alterao ou visualizao; ii. Se desejar excluir somente clicar no cone ao lado do nome da regra; b. Se sistema no possuir regras cadastradas; 3. Seleciona cone da seta para onde deseja efetuar a insero; 4. Sistema apresentara tela para cadastro da regra: a. Se desejar cadastrar informaes, executa FP 7; b. Seno executa FA 1; 5. Efetua a insero das regras; 6. Ator salva informaes. Fluxo Alternativo Ps-condio 1. Seleciona o boto Cancelar. Regras disponveis para manipulao e aplicao.

Quadro 9 Detalhamento do Caso de Uso CSU09 Administrador. Fonte: Elaborao dos autores, 2011.

4.4.2.2 Documentao dos casos de uso do ator: Usurio

Neste item, ser apresentada a documentao dos casos de uso do mdulo usurio. No quadro 10, tem-se o detalhamento do caso de uso Consultar processos associados ao nome do usurio. , neste caso de uso, que o usurio pode verificar as tarefas de um processo que esto associadas ao seu nome.

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Consultar processos associados. CSU01. realizada uma pesquisa para verificar se existem processos cadastrados no nome do usurio. Usurio. necessrio ter acessado ao sistema. 1. Sistema apresenta tela com opo de pesquisa; 2. Ator preenche o campo de pesquisa com o nome ou parte do

80 nome do processo; 3. So apresentados os processos conforme dados da pesquisa: a. Se desejar efetuar alterao, executa FA 1; b. Seno, visualiza os processos cadastrados. Fluxo Alternativo Ps-condio 1. Executado CS04. Realizao de pesquisa; Verificao dos processos desejados.

Quadro 10 Detalhamento do Caso de Uso CSU01 Usurio. Fonte: Elaborao dos autores, 2011.

No quadro 11, apresentado o caso de uso Visualizar tarefa do processo, sendo essa o ambiente principal com o qual o usurio ir interagir. Segue o detalhamento deste caso de uso.

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Visualizar tarefas pendentes. CSU05. Lista de todos os processos que o usurio possui associado e que esto pendentes. Usurio. necessrio ter acessado ao sistema. 1. Usurio efetuou login no sistema 2. Sistema apresenta, na tela central, as tarefas associadas ao mesmo; a. Se usurio deseja executar a tarefa, executa CSU04; b. Se usurio deseja saber histrico, executa CSU03;

Fluxo Alternativo Ps-condio Anlise dos processos; Efetivao de tarefas do processo.

Quadro 11 Detalhamento do Caso de Uso CSU05 Usurio. Fonte: Elaborao dos autores, 2011.

O quadro 12 detalha o caso de uso onde o usurio cadastra informaes das tarefas do processo. O caso de uso Cadastrar informaes de tarefa no processo ocorre quando o usurio utiliza o formulrio que o administrar criou. Segue detalhamento do mesmo.

81

Nome Identificador Descrio Ator Primrio Pr-condio Fluxo Principal

Cadastrar informaes nas tarefas do processo. CSU04. efetuado cadastro de informaes nas tarefas executadas do processo. Usurio. Necessrio que j tenha sido executado CSU05 ou CSU02. 1. Ator seleciona determinada tarefa ou processo; 2. Sistema apresenta confirmao da execuo da tarefa: a. Se clicar no boto sim, executa FP3; b. Se clicar no boto no, executa FP5; 3. Sistema apresenta opes de edio: a. Se usurio executou tarefa incorreta, executa FA 1; b. Se inserir dados, executa FP 4; 4. Usurio clica no boto Enviar; 5. Volta ao CSU05.

Fluxo Alternativo Ps-condio

1. Usurio pressiona boto Cancelar; 2. Executa FP 5. Tarefas inseridas no processo; Informaes adicionadas ao processo.

Quadro 12 Detalhamento do Caso de Uso CSU04 Usurio. Fonte: Elaborao dos autores, 2011.

O quadro 13 apresenta detalhamento do caso de uso onde exibido o histrico do processo. Atravs do histrico todas as etapas cadastradas, quem as efetuou, entre outros detalhes so descritos. Segue o detalhamento.

Nome Identificador Descrio

Visualizar histrico da tarefa do processo. CSU03. efetuada anlise de todas as informaes de determinado processo atravs de uma tarefa.

82

Ator Primrio Pr-condio Fluxo Principal

Usurio. Necessrio que j tenha sido executado CSU05. 1. Ator verifica tarefas; 2. Seleciona tarefa, clicando no cone; 3. Sistema apresenta tela com os dados de execuo de tarefas do processo: 4. Analisa o histrico das informaes das tarefas do processo; 5. Usurio pressiona o boto Sair; 6. Executa CSU02.

Fluxo Alternativo Ps-condio Analisadas as aes que foram efetuadas em determinada tarefa do processo.

Quadro 13 Detalhamento do Caso de Uso CSU03 Usurio. Fonte: Elaborao dos autores, 2011.

4.5

MODELAGEM DAS ATIVIDADES

A estrutura de um diagrama de atividade comea com um n inicial, em que, na sequncia, uma ao executada, que pode ocorrer paralelamente, aps ter a opo de seguir o fluxo chegando esse a um nico ponto de sada. (FOWLER, 2004). Os diagramas de atividades dizem o que acontece, mas no dizem quem faz o qu (FOWLER, 2004, p. 120). Para definir quem realiza o qu necessrio dividir o diagrama de atividade em classes e unidades, sendo essa caracterstica no contemplada no trabalho. A seguir, descrevem-se os diagramas de atividades dos casos de uso detalhados na seo anterior.

83 4.5.1 Diagrama de atividade Administrador

A figura 18 apresenta o fluxo de atividades para a criao de um formulrio, que o usurio ir utilizar para execuo de suas tarefas. Para essa atividade ser executada, necessrio que os dados sejam devidamente definidos. Nesse fluxo, o administrador verifica o processo, seleciona uma tarefa do processo para que seja criado o formulrio e modela os dados que devem constar no formulrio.

Figura 18 Diagrama de Atividade do Caso de Uso CSU05 Administrador. Fonte: Elaborao dos autores, 2011.

84 Na figura 19, o usurio define as regras do processo. O fluxo inicia-se com a visualizao do processo, aps selecionada a tarefa do processo para inserir a regra. A insero efetuada na entrada da tarefa e ou na sada, o sistema apresenta uma tela com a opo para cadastro dos dados, em que tambm sero listadas as regras que j foram cadastradas, podendo, se necessria, manipul-las.

Figura 19 Diagrama de Atividade do Caso de Uso CSU09 Administrador. Fonte: Elaborao dos autores, 2011.

85 Na figura 20, apresentado o fluxo para seleo do processo que ser automatizado. Para que seja efetuada qualquer alterao no processo deve-se selecionar primeiramente o processo.

Figura 20 Diagrama de Atividade do Caso de Uso CSU03 - Administrador. Fonte: Elaborao dos autores, 2011.

A figura 21 apresenta o fluxo para cadastro dos dados. Esses dados so utilizados para a criao do formulrio e para regras de negcio. Para que o formulrio seja devidamente cadastrado, esses dados devem estar bem definidos. Nesse fluxo, necessrio que o desenho do processo tambm j esteja bem definido para que o administrador possa cadastrar os dados a partir do desenho do processo. Na tela apresentada para edio dos dados, o usurio poder excluir, alterar ou adicionar os dados do processo.

86

Figura 21 Diagrama de Atividade do Caso de Uso CSU08 Administrador. Fonte: Elaborao dos autores, 2011.

4.5.2

Diagrama de atividade Usurio

A figura 22 apresenta o fluxo de atividades que o usurio ir executar para que sejam consultadas as tarefas do processo associadas ao mesmo. O sistema apresenta opo de consulta permitindo que o usurio possa efetu-las digitando o nome do processo.

87

Figura 22 Diagrama de Atividade do Caso de Uso CSU01 Usurio. Fonte: Elaborao dos autores, 2011.

A figura 23 apresenta a visualizao das tarefas do processo associadas a um usurio. Para cada tarefa exibindo informaes de data, status, nome e descrio. Se o usurio no possuir nenhuma tarefa em seu nome, o sistema apresenta uma mensagem com essa informao.

88

Figura 23 Diagrama de Atividade do Caso de Uso CSU05 Usurio. Fonte: Elaborao dos autores, 2011.

Na figura 24, apresentada tela onde o usurio ir interagir com o formulrio para edio dos dados.

89

Figura 24 Diagrama de Atividade do Caso de Uso CSU04 Usurio. Fonte: Elaborao dos autores, 2011.

Na figura 25, apresentado o histrico de aes de um processo atravs de uma tarefa. So apresentados todos os passos j executados para um processo. Este passo ocorre aps a visualizao das tarefas cadastradas para o usurio.

90

Figura 25 Diagrama de Atividade do Caso de Uso CS004 Usurio. Fonte: Elaborao dos autores, 2011.

4.6

MODELAGEM DE DADOS

Um modelo de dados descreve as informaes armazenadas em um banco, essas informaes so sobre o sistema. Para que seja efetuada essa modelagem, necessria uma linguagem. A linguagem do modelo de dados pode ser apresentada como texto ou como linguagens grficas. O modelo de dados est baseado nos nveis de abstrao que est dividida em (HEUSER, 1998): modelo conceitual que trata da descrio do banco de dados independendo de um SGBD (Sistemas de gerncia de banco de dados) e modelo lgico que dependente do SGBD. A figura 26 apresenta um exemplo do modelo de dados que ser utilizado no desenvolvimento do sistema.

91

Figura 26 Exemplo de modelo de dados utilizado no sistema. Fonte: Elaborao dos autores, 2011.

4.7

CONSIDERAES FINAIS DO CAPTULO

Neste item, foi realizada a modelagem do sistema BPMS proposto, sendo que a descrio de seu desenvolvimento ser detalhada no prximo captulo. Por ser um sistema com certa complexidade, envolvendo conceitos relativamente novos, os artefatos da modelagem foram definidos de forma sucinta, sendo escolhidos alguns para serem mais detalhados, demonstrando nesses itens uma viso mais abrangente sobre a proposta. A simplificao da modelagem pode tambm ser justificada pelo uso de frameworks para apoiar a execuo dos processos de negcio e das regras de negcio. Para o desenvolvimento, ser utilizado como referncia o modelo de processo de negcio, juntamente com os requisitos funcionais e no funcionais, diagramas de casos de uso e seu detalhamento, modelo de dados e diagramas de atividades.

92 5 DESENVOLVIMENTO

Neste

capitulo,

sero

descritos

os

procedimentos

utilizados

para

desenvolvimento do sistema proposto, as tecnologias que foram utilizadas para apoiar o desenvolvimento e uma descrio do sistema. Para isso, sero apresentadas as imagens das telas bem como uma explicao da funo de cada tela.

5.1

TENOLOGIAS UTILIZADAS

Para o desenvolvimento do sistema, buscou-se utilizar ferramentas livres e que fossem compatveis e flexveis com o projeto. O sistema proposto utiliza uma plataforma web para proporcionar aos administradores e aos usurios maior facilidade para modelar processos e transmitir a informao relativa a estes. A figura 27 ilustra as vrias tecnologias que foram utilizadas para o desenvolvimento do sistema.

Figura 27 Ferramentas utilizadas. Fonte: Elaborao dos autores, 2011.

93 5.1.1 Java

Java uma linguagem orientada a objeto que foi desenvolvida e mantida pela Sun Microsystems que, posteriormente em 2009, a empresa Sun foi comprada pela Oracle. Esta linguagem foi criada com o objetivo de ser utilizada por pequenos dispositivos, sendo que a linguagem teve seu lanamento no uso de clientes web para rodar pequenas aplicaes no qual se destacou no lado do servidor que teve um grande avano e, no momento, a linguagem dominante. O foco da plataforma Java para aplicaes de mdio e grande porte. (CAELUM, 2011). Java uma tecnologia de cdigo aberto independente de plataforma. Essa tecnologia d a possibilidade de desenvolver programas de mais alta qualidade, como jogos aplicativos entre outros. Quando se desenvolve em Java, utiliza-se sua linguagem de programao que ser executada em um ambiente de distribuio Java chamado Maquina Virtual . Como ela multiplataforma, para um programa desenvolvido em Java ser executado ele necessita ser traduzido e, para isso, utilizada a Mquina Virtual Java (JVM) no qual gerado um cdigo intermedirio chamado de bytecode, que interpretado pela JVM, que por sua vez cria um ambiente virtual sob o sistema operacional. Para que o sistema seja executado de forma rpida, Java criou o compilador Just-in-time (JIT), que analisa e retira cdigos desnecessrios, aumentando a velocidade da execuo. Java divido em: Java 2 Standard Edition (J2SE) que utilizada em computadores pessoais que possui APIs. Estas APIs so divididas em: Java Development Kit (JDK) utilizado para desenvolvimento; Java Runtime Edition (JRE): utilizada para preparar o ambiente de execuo.

Java 2 Mobile Edition (J2ME): utilizado pra dispositivo mveis no qual dividido em: Connected Limited Device Configuration (CLDC) e Connected Device Configuration (CDC)

Java 2 Enterprise Edition (J2EE): utilizado para aplicaes desktop ou web, possuindo uma vasta biblioteca ideal para construo de servidores de aplicao. Para este projeto, optou-se por desenvolver o aplicativo com esta linguagem

utilizando como Ambiente Integrado para Desenvolvimento (Integrated Development

94 Environment IDE), o Eclipse que na sequencia ser melhor detalhado. Como a linguagem Java orientada a objeto, fcil e rpido efetuar alteraes no aplicativo, sendo ela uma linguagem segura e confivel, porttil, independendo de plataformas e compatvel com as demais tecnologias que sero utilizadas no projeto. (ORACLE, 2011)

5.1.2

JBoss Drools

A ferramenta JBoss Drools, como descrito anteriormente, oferece uma plataforma lgica de negcio que unificada e integrada com regras, fluxo de trabalho e processamento de evento. Este sistema facilita a programao das regras de negcio em que se tem maior facilidade de gerenci-las. Foi criada pensando na performance e escalabilidade e integrado plataforma Java. (JBOSS , 2011)

5.1.3

JBoss jBPM 5

Hoje em dia, as aplicaes esto sendo desenvolvidas orientadas ao negcio, deixando evidente o produto final e no tendo muito foco na linguagem que ser utilizada ou frameworks entre outros. O jBPM uma ferramenta que auxilia no desenvolvimento de processos de negcio. Trata-se de uma linguagem ligada linguagem Java e no depende de servidor para ser executada. Pode ser executada em plataforma Java e est ligada arquitetura SOA, tendo alguns recursos, como a ligao com EJB (Enterprise Java Beans) e ligao com o BPEL. O jBPM auxilia na interface de comunicao preenchendo a lacuna entre gerentes e colaboradores, fazendo que os gerentes de projetos de software tenham mais controle sobre os seus esforos de desenvolvimento. O jBPM possui uma linguagem prpria que facilita o desenvolvimento das tarefas, rotinas de envio de email, entre outras.

95 O jBPM uma estrutura que oferece fluxo de trabalho, gerenciamento de processos de negcio e orquestrao de processos em um produto escalvel e flexvel, permitindo que a empresa crie e automatize os seus processos. Foi escolhida essa ferramenta por permitir maior agilidade no desenvolvimento do projeto, disponibilizando para isso diversos recursos como: Utilizao de mecanismos como Web Service, workflow, onde as etapas do processo so gerenciadas por ele. Framework configurvel e integrado ao motor de regras de negcio. Possui tambm um editor baseado no Eclipse, IDE utilizado no projeto, possuindo um conjunto de plug-ins da JBoss. (JBOSS, 2011).

5.1.4

BlazeDS

BlazeDS um servidor baseado em Java que pode ser caracterizado como uma tecnologia Web remota de mensagem que permite aos desenvolvedores conectar facilmente os dados do servidor distribudo e envi-los em tempo real para o Flex. Por ser remoto, facilita o empacotamento das chamadas entre o Flex e os mtodos Java no servidor, tendo um bom desempenho por sua transferncia ser no formato binrio, permitindo que os aplicativos carreguem mais rapidamente. Esse framework foi escolhido por necessidade de comunicao de aplicaes Java com Flex, ou seja, a aplicao Java publica a mensagem para o Flex e o cdigo Java pode responder as mensagens enviadas pelo Flex. Alm disso, essa tecnologia foi escolhida por possuir servio de Proxy, permitir controle de desempenho, informaes e configurao do servidor. O fato de ser livre e de cdigo aberto tambm contribuiu para a escolha dessa ferramenta. (ADOBE, 2011)

96 5.1.5 Flex 4

O Flex um framework de cdigo aberto para a construo e manuteno de aplicativos web . A verso mais recente o Flex 4.5.1. Ele possui uma linguagem moderna podendo ser utilizado para aplicaes interativas e expressivas. A verso utilizada do Adobe na verso gratuito Adobe Flex SDK, que possui ferramentas teis para melhorar a experincia de desenvolvimento de aplicaes com o Adobe Flash Player. O Flex possibilita a criao de aplicaes grandes, permitindo, tambm, aos desenvolvedores criarem aplicaes no somente desktop e web , mas tambm em dispositivos mveis usando uma estrutura unificada. O Flex possibilita o desenvolvimento com melhor designer, devido sua estrutura, fornecendo uma linguagem e ferramentas que auxiliam na construo rica de aplicativos. Possui opo de um aplicativo ser construdo ou ter mantido por um ou vrios membros da equipe. (ADOBE, 2011).

5.1.6

Mysql 5

O Mysql um sistema de gerenciamento de banco de dados desenvolvido, distribudo e apoiado pela Oracle. Um banco de dados uma coleo de dados estruturados. O Mysql um software de cdigo aberto ( possvel qualquer um usar e modificar o programa) e um software livre. Ele foi desenvolvido principalmente para ser usado por manipular muitas informaes, ou seja, um banco de dados grande, executando as tarefas dede forma rpida. O Mysql foi escolhido por ser um banco de dados rpido, confivel, fcil de usar, sendo muito flexvel e compatvel com vrias plataformas. Tambm por possuir alto desempenho, facilidade de gerenciamento e no possui custo financeiro para aquisio. (ORACLE, 2011).

97 5.1.7 JBoss Application Server

JBoss Application Server um servidor de aplicao multiplataforma de cdigo aberto baseado em Java . Sua arquitetura fcil de usar possuindo alta flexibilidade. O JBoss AS 5 disponibiliza recursos necessrios para a execuo de aplicaes JAVA EE, de fcil e rpida instalao, auxiliando os desenvolvedores no total controle e customizao na infraestrutura, na customizao e demais necessidades. O servidor JBoss possui vrios subsistemas integrados, sendo um deles o Apache Tomcat. O Tomcat executa sob o JBoss arquivos JSP e Servlets, j, o JBoss tem a capacidade de executar aplicaes distribudas quando utilizado EJB. O Tomcat por si s no possui recursos para rodar aplicaes distribudas. O JBoss AS oferece opes para construir, implantar e gerenciar aplicativos Java EE. Sua operao utiliza pouca memria, podendo ser utilizado em um ou vrios servidores e JVM. (JBOSS, 2011).

Figura 28 Arquitetura JBoss Application Server. Fonte: JBoss, 2011.

98 5.1.8 Eclipse

O Eclipse foi criado pela IBM, logo aps se tornou independente e, agora, mantido por uma comunidade de cdigo aberto que no possui fins lucrativos. Seu projeto esta focado na construo de plataformas para o desenvolvimento e composta por extenses e frameworks. Sua maior vantagem a juno dos plug-ins que gerenciado por um ncleo. O Eclipse um IDE (Ambiente de desenvolvimento integrado - Integrated Development Environment) que possui embutido um conjunto de funcionalidades, facilitando a construo de softwares. Esse software foi escolhido por ser gratuito e por possuir diversos plug-ins, facilitando o desenvolvimento do projeto. Tambm pelo timo desempenho, por ser cdigo aberto, flexvel e por possuir ambiente grfico amigvel e leve. (ECLIPSE, 2011)

5.1.9

Flash Builder 4

O Adobe Flash Builder um plug-in do Eclipse que serve como ferramenta de desenvolvimento integrado e executado em multiplataforma. Ele utilizado para desenvolvimento de aplicaes para a internet, desktop e dispositivos mveis que usam o framework Flex e Action Script. Alm disso, inclui tambm ferramentas que auxiliam na produtividade e eficcia da aplicao. O Adobe Flash Builder pode acelerar o desenvolvimento por meio de recursos, como edio de cdigo inteligente, depurao interativa por etapas, geradores de perfis de memria e desempenho e design visual. Adobe Flash Builder inclui um interativo depurador, permitindo que os desenvolvedores possam percorrer a execuo de cdigo, inspecionar as variveis e assistir expresses. O Flex Builder tem suporte para anlise de desempenho. O ponto de vista de perfil exibe informaes estatsticas sobre o uso de memria, alm de funo de chamadas em tempo de execuo. (ADOBE, 2011).

99 5.1.10 Java Persistence API

Java Persistence API (JPA) um framework utilizado na camada de persistncia, que prov desenvolvedora maior produtividade para construo de sistemas em Java. A JPA a especificao para o gerenciamento de persistncia e mapeamento objeto relacional (ORM), tendo como principal conceito as entidades. Entidades correspondem a objetos que podem ser gravados na base de dados por meio da persistncia. Cada entidade deve possuir uma chave primria na base de dados, que ser seu identificador. Essa entidade denominada tambm como POJO (Plain Old Java Object), que so criadas por meio de classes Java, definindo a forma de mapeamento. A JPA faz parte da plataforma Java EE e est contida no documento JSR 220 do EJB (Enterprise Java Beans) 3.0. Para seu desenvolvimento, necessrio que se mapeiem classes de negcio em entidades, bem como a definio de unidades de persistncia e conexo com o banco de dados. Por meio da JPA tambm se pode efetuar consultas estticas e dinmicas, sendo essas muito parecidas com as consultas SQL. (ORACLE, 2011). Para que seja utilizada necessrio um provedor JPA especfico, pois JPA uma especificao para frameworks de persistncia, dentre os existentes, neste projeto, foi escolhido Hibernate, que ser detalhado no prximo item.

5.1.11 Hibernate

O Hibernate faz parte da comunidade JBoss, sendo uma ferramenta de mapeamento objeto/relacional para aplicaes Java. Por meio do Hibernate o armazenamento e recuperao de objetos de domnio Java so facilitados, sendo usado por esse uma linguagem prpria denominada HQL (Hibernate Query Language) e orientada a objeto. Uma caracterstica que esse framework no indicado quando se necessita de funes especficas de um determinado banco de dados, sendo mais bem aplicado para sistemas em que a maior parte da lgica do negcio esta na prpria aplicao. Em resumo, ele serve como uma interface, recebendo chamadas de mtodo dos objetos, convertendo esses em comandos de leitura e gravao, que sero executados pelo banco de dados. (JBOSS, 2011).

100 5.2 PROCESSO DE DESENVOLVIMENTO

O procedimento utilizado para o desenvolvimento desta proposta considerou as seguintes etapas, ilustradas na figura 29.

101

Figura 29 Processo do desenvolvimento. Fonte: Elaborao dos autores, 2011.

102 O processo de desenvolvimento iniciou-se com a pesquisa de alguns softwares BPMS do mercado, identificando nesses os pontos fracos e oportunidades de melhoria. O foco principal foi na identificao da forma de como esses tratavam a definio e execuo de processos e, principalmente, como regras de negcio eram geridas pelos mesmos. A partir da pesquisa, partiu-se para a definio de um motor de processos e de regras de negcio que pudesse suprir as necessidades de desenvolvimento. Com base na pesquisa iniciou-se a modelagem do sistema, na qual foram levantadas informaes, regras e requisitos necessrios para que o software fosse desenvolvido. Na modelagem, foram identificados os principais processos de negcio, bem como os requisitos necessrios para um sistema BPMS. Tambm, foram identificados casos de uso e atividades, demonstrando, assim, a interao entre os atores e o sistema e, por fim, foi realizada a modelagem de dados, em que toda a estrutura necessria de dados foi organizada, utilizando o modelo de Entidade Relacionamento, permitindo, assim a correta manipulao dos dados pelo sistema. A etapa de desenvolvimento foi realizada com certa dificuldade por se tratar de um sistema que engloba funcionalidades inslitas. Foram utilizadas vrias tecnologias relativamente novas e de forma integrada para que o desenvolvimento pudesse ser concludo e os objetivos alcanados. Para a camada de persistncia, foi utilizada a especificao JPA e sua implementao, o Hibernate. Em se tratando de interface, foi escolhido o Adobe Flex, proporcionando, assim, maiores recursos visuais, sendo esses essenciais para o projeto. O banco de dados escolhido foi o MySQL e, por ser uma aplicao Web, foi utilizado o servidor de aplicao JBoss Server. Aps a etapa de desenvolvimento, que engloba tambm a aplicao dos motores de processo e de regras de negcio, foi realizada a implantao do sistema em um ambiente de homologao, na qual, foram realizados testes gerais. Aps, foi efetuada a validao do sistema. Essa validao foi realizada por meio de um check-list, demonstrando, assim, cada etapa concluda, parcialmente ou no concluda. Tambm, por meio de um estudo de caso, que demonstrou uma situao hipottica, validando o mdulo administrativo do sistema.

103 5.2.1 Detalhamento do processo de desenvolvimento

O desenvolvimento do sistema iniciou-se pelo mdulo de modelagem de processos de negcio, em que foi utilizada a linguagem de programao Java e o framework Flex, esse, especificamente, para as interfaces grficas. Esse mdulo de todo o sistema pode ser considerado o mais complexo. Complexidade essa que se deve aos recursos visuais necessrios para que o usurio final pudesse de maneira rpida e simples desenhar, conectar, remover e nomear elementos do processo de negcio, utilizando a notao BPMN de forma totalmente Web . Todos os elementos grficos e controles foram desenvolvidos sem o auxlio de qualquer componente externo, gerando, assim, tempo considervel em pesquisa sobre recursos mais avanados do framework Flex. Como exemplo, podem-se citar as setas de conexes entre os elementos e a paleta de componentes que exibida ao clicar em um elemento, habilitando, assim, diversas opes de forma rpida. Diante de todo o exposto, foi encontrado certo grau de dificuldade para resolver diversas situaes de desenvolvimento, o que acabou gerando tempo considervel para pesquisa e concretizao do modelador de processos. Outra dificuldade encontrada no processo de desenvolvimento foi no aprendizado das tecnologias para execuo de processos (Motor de Processos) e execuo de regras de negcio (Motor de Regras de Negcio). Essas tecnologias, por serem novas, esto em constante evoluo, o que acaba gerando, de certa forma, alguns problemas que foram observados somente na etapa de desenvolvimento. So elas: Documentao: Inicialmente a documentao das tecnologias parecia suprir as necessidades para o desenvolvimento, mas, com o decorrer do mesmo, verificou-se que certas caractersticas no eram contempladas satisfatoriamente, ocasionando tempo em fruns de discusses, pesquisas em diversas fontes e testes em busca de solues etc; Evoluo da Tecnologia: Como dito anteriormente, os motores de processo e de regras de negcio so relativamente novos e, por essa razo, esto em constante evoluo. Para o desenvolvimento do mdulo de execuo de processos, necessrio utilizar caractersticas mais avanadas da ferramenta. Alguma dessas caractersticas, aps incansvel pesquisa em fruns, chegou-se concluso de que a ferramenta no contempla ou que a mesma se encontra em desenvolvimento.

104

Os problemas identificados e descritos acima impactaram diretamente no mdulo de execuo de processos (Portal do Usurio), dessa forma, na figura 30 sero listadas as solues encontradas para realizar o desenvolvimento desse mdulo. Elementos BPMN e suporte do motor de processos: Alguns elementos da especificao BPMN geraram problemas para realizar a correta aplicao do motor. De forma geral as dificuldades encontradas foi na correta converso do modelo salvo atravs do ambiente administrativo (Configurao da Automatizao pelo administrador) para o modelo que o motor de processos consiga realizar a interpretao. Sendo assim, segue, na figura 30 algumas situaes encontradas. o Deciso (Gateway): Na figura 30 demonstrada a situao que no contemplada pelo motor de processos. Ao converter o modelo citado para o motor de processos do JBPM, um erro exibido informando que a tarefa trs tarefa 3 no pode ter dois fluxos de sequncia convergindo para ela.

Figura 30 Modelo no suportado pelo motor de processos. Fonte: Elaborao dos autores, 2011.

Solues encontradas:

1 - A figura 31 demonstra como o modelo acima pode ser contornado. Quando uma deciso pode convergir para diversos caminhos e aps haja a necessidade de convergir para um nico caminho, deve ser usada uma deciso denominada divergente e uma denominada convergente. Atravs dessa soluo o fluxo converge para um caminho nico, no qual, pode-se dar prosseguimento ao processo.

105

Figura 31 Soluo para o problema da deciso 1. Fonte: Elaborao dos autores, 2011.

2 - Outra soluo para o problema descrito acima o exibido na figura 32. Se o desenho do processo permitir, os possveis caminhos provenientes da deciso podem seguir cada um, um caminho especfico. Dessa forma, tm-se no processo dois os mais caminhos sendo percorridos atravs da execuo do processo.

Figura 32 Soluo para o problema da deciso 2. Fonte: Elaborao dos autores, 2011.

Piscina (Pool): Ao realizar pesquisas para converter uma piscina para a sua respectiva no formato do motor de processos e aps diversos testes realizados, chegou-se a concluso de que o mesmo no possui um correspondente, ou seja, uma piscina normalmente usada para designar uma organizao e a Raia (Lane) utilizada para representar um participante do processo. Dessa forma, para um modelo executvel no JBPM, no existe uma correspondncia para uma Piscina, somente para Raias. Na figura 33 demonstrado parte do modelo gerado para representar as Raias no motor de processos.

106

Figura 33 Modelo BPMN em formato XML gerado pelo motor de processos. Fonte: Elaborao dos autores, 2011.

Eventos de Fim (End): Outra situao encontrada na etapa de desenvolvimento est relacionada com os eventos de fim. Depois de tempo considervel em pesquisas e principalmente com testes, chegou-se a seguinte concluso.

Semelhante ao erro encontrando com o problema da deciso, ao converter o modelo citado na figura 34 para o motor de processos do JBPM, um erro exibido informando que o evento de fim no pode ter dois fluxos de sequncia convergindo para ele.

Figura 34 Modelo no suportado pelo motor de processos. Fonte: Elaborao dos autores, 2011.

o Soluo encontrada: A figura 35 demonstra como o problema descrito pode ser contornado. Nesse caso cada tarefa deve ter seu prprio evento de fim, no podendo mais de uma tarefa convergir para o mesmo evento de fim.

107

Figura 35 Soluo para o problema do evento de fim. Fonte: Elaborao dos autores, 2011.

Regras de negcio e motor de regras: Algumas questes relacionadas aplicao do motor de regras de negcio e sua integrao com o motor de processos so descritos a seguir. o Linguagem interna para regras de negcio: As regras de negcio utilizando o motor de regras podem ser expressas atravs da prpria linguagem Java ou por uma denominada MVEL, essa ltima semelhante ao Java. No projeto desenvolvido no foi utilizado todo o poder do motor de regras de negcio onde diversas funcionalidades so disponibilizadas. Por questo de tempo, foi utilizada uma parte do motor do Drools que j integrado ao motor de processos do JBPM. A linguagem utilizada para expressar as regras foi o prprio Java, onde por familiaridade dos autores, facilitou a organizao dos algoritmos. Na figura 36 segue um pequeno exemplo no qual uma varivel totalCompra calculado um desconto sobre ela.

Figura 36 Exemplo de expresso utilizada com o Drools. Fonte: Elaborao dos autores, 2011.

o Eventos de Entrada e Sada: O mdulo de regras de negcio desenvolvido no projeto utiliza uma caracterstica que so os eventos de entrada ou sada associados s tarefas. Atravs dessa caracterstica, uma atividade pode possuir regras que sero executadas antes que a mesma seja executada, e/ou aps a execuo da atividade. A sintaxe para expressar as regras a descrita acima e, na figura 37 ser demonstrado um pequeno exemplo utilizado no projeto.

108

Figura 37 Parte do cdigo utilizado no projeto para definio de regras. Fonte: Elaborao dos autores, 2011.

Como puderam ser observadas, algumas dificuldades foram encontradas, mas solucionadas ou contornadas. Como resultado, obteve-se aprendizado por parte dos autores acerca da aplicao de motores de regras de negcio e de processos e, tambm, reduo considervel para desenvolvimento do projeto.

5.3

PESQUISA E VERIFICAO DE FERRAMENTAS BPMS

Neste capitulo sero abordadas as ferramentas BPMS que foram avaliadas neste trabalho.

5.3.1

Avaliao de Ferramentas

Seguindo as sugestes e critrios de avaliao de ferramentas da empresa IProcess, empresa renomada no mercado nacional tendo ganho diversos prmios

109 internacionais atravs de vrios cases de sucesso, seguiu-se o modelo de avaliao definido por ela para avaliao das ferramentas selecionadas nessa pesquisa. Algumas variveis para a escolha de uma plataforma BPM A escolha de uma plataforma de BPM uma das escolhas mais difceis por parte das organizaes e, isso se d por alguns motivos: Mercado de BPM ainda com relativa inexperincia. Elevados valores financeiros envolvidos Dificuldade em se avaliar as caractersticas como usabilidade e produtividade das ferramentas BPM Grande nmero de alternativas no mercado entre outras caractersticas

No existe uma ferramenta que possa ser definida como a melhor, tudo depende das caractersticas e necessidades da organizao que est adquirindo o produto.

5.3.2

Definio de requisitos de seleo da ferramenta

A avaliao deve ser realizada por cada organizao de modo a encontrar os requisitos que atendam sua realidade, podendo essas, ser agrupadas por categorias, como demonstrado a seguir. Requisitos de modelagem Requisitos de desenvolvimento Requisitos de ambiente de usurio final Requisitos de integrao Requisitos de gesto Requisitos de infra-estrutura e administrao Requisitos de Licenciamento

110 5.3.2.1 Exemplos de Requisitos de Modelagem

Suporte a notao BPMN Modelagem e representao dos indicadores de desempenho

5.3.2.2 Exemplos de Requisitos de Desenvolvimento

Possuir um nico ambiente para o desenvolvimento de todos os componentes da soluo

Permitir a construo de formulrios e aplicaes Documentao de API para o desenvolvimento de novas funcionalidades

5.3.2.3 Exemplos de Requisitos de Ambiente de Usurio

Ambiente 100% Web Permitir anexar e consultar documentos do processo Permitir delegar atividades para outros usurios

5.3.2.4 Exemplos de Requisitos de Integrao

Permitir conectividade com web services Permitir conectividade com bases de dados nativas da organizao

111 5.3.2.5 Exemplos de Requisitos de Gesto

Apresentar histrico dos processos com viso grfica e textual Permitir a construo de grficos e relatrios para indicadores por gestor de processo

5.3.2.6 Exemplos de Requisitos de Infra-estrutura e Administrao

Infra-estrutura de Hardware e Software necessrio para o funcionamento da soluo

Funcionalidades para a administrao da soluo Estrutura de Suporte a Atendimento do Fabricante da Soluo

5.3.2.7 Exemplos de Requisitos de Licenciamento da Soluo

Sem custo de licena Por usurio final Por processo Avaliar custo de suporte da ferramenta

112 5.3.3 Critrios para Avaliao das Ferramentas

Para a avaliao das ferramentas ser definido dentre os principais requisitos apresentados, os que mais se destacam apontando para cada um se o mesmo Atende, Atende parcialmente ou No atende. (IPROCESS-BPM, 2010). Legenda: A Atende; AP Atende parcialmente; NA No atende.

5.3.3.1 Ferramenta BizAgi BPM Sute

Critrios de Avaliao Suporte a Notao BPMN Modelagem dos Indicadores do Processo Publicao da Documentao em Ambiente Web Ferramentas para a Construo de Formulrios e Aplicaes com Wizard Ambiente Integrado de Modelagem de Desenvolvimento do Processo Permite Anexar e Consultar Documentos do Processo Delegar Atividades para Outros Usurios Permite Evocao de Web Services Consulta ao Histrico de Processos em formato textual e grfico Possui indicadores prontos para uso pelo gestor de negcio
Quadro 14 Avaliao da ferramenta BizAgi. Fonte: Elaborao dos autores, 2011.

A NA A A AP A A A A A

5.3.3.1.1 Concluso da Anlise

113 Dentre as ferramentas analisadas foi a mais intuitiva e de rpido aprendizado. Possui wizards que auxiliam na utilizao da ferramenta. tima documentao com dezenas de exemplos e comunidade ativa.

5.3.3.2 Ferramenta Orquestra

Critrios de Avaliao Suporte a Notao BPMN Modelagem dos Indicadores do Processo Publicao da Documentao em Ambiente Web Ferramentas para a Construo de Formulrios e Aplicaes com Wizard Ambiente Integrado de Modelagem de Desenvolvimento do Processo Permite Anexar e Consultar Documentos do Processo Delegar Atividades para Outros Usurios Permite Evocao de Web Services Consulta ao Histrico de Processos em formato textual e grfico Possui indicadores prontos para uso pelo gestor de negcio
Quadro 15 Avaliao da ferramenta Orquestra. Fonte: Elaborao dos autores, 2011.

AP NA A A A A A A A A

5.3.3.2.1 Concluso da Anlise

Ferramenta 100% Web. A verso para avaliao disponibilizada possua diversos mdulos bloqueados, sendo necessria a compra da licena para liberao. Dessa forma no teve como realizar uma avaliao mais aprofundada. Apesar disso, se mostrou uma ferramenta interessante. Um dos pontos fracos foi a construo de formulrios, que, necessita de diversos passos apenas para criar um simples campo. Dessa forma o processo de criao leva um tempo considervel.

114 5.3.3.3 Ferramenta Bonita

Critrios de Avaliao Suporte a Notao BPMN Modelagem dos Indicadores do Processo Publicao da Documentao em Ambiente Web Ferramentas para a Construo de Formulrios e Aplicaes com Wizard Ambiente Integrado de Modelagem de Desenvolvimento do Processo Permite Anexar e Consultar Documentos do Processo Delegar Atividades para Outros Usurios Permite Evocao de Web Services Consulta ao Histrico de Processos em formato textual e grfico Possui indicadores prontos para uso pelo gestor de negcio
Quadro 16 Avaliao da ferramenta Bonita. Fonte: Elaborao dos autores, 2011.

A NA NA AP AP AP A A A AP

5.3.3.3.1 Concluso da Anlise

A ferramenta Bonita foi uma das que mais se destacou. Ela Open Source, o que facilitaria, por exemplo, na alterao de algum mdulo do software por um programador. Possuem um repositrio onde exemplos de processos e conectores podem ser baixados para aprimorar a ferramenta. tima documentao e software de fcil manuseio. Tambm bem simples para instalar e rodar os processos automatizados com ela.

5.4

APRESENTAO DO SISTEMA

Nesta etapa, sero apresentadas as principais funcionalidades do sistema, a partir de imagens e breve comentrio de sua utilizao.

115 Para efetuar o acesso ao sistema, necessrio efetuar o login. Um usurio ter associado ao seu login um perfil, que pode ser usurio ou administrador. Esse perfil definir os privilgios que o mesmo ter dentro do sistema.

Figura 38 Login sistema. Fonte: Elaborao dos autores, 2011.

5.4.1

Gerenciamento dos processos

Aps o login, sero apresentadas todas as funcionalidades do sistema definidas de acordo com seu perfil, neste caso apresentado o perfil administrador.

Figura 39 Funcionalidades do sistema Perfil administrador. Fonte: Elaborao dos autores, 2011.

Selecionando-se a aba Processo, sendo essa a primeira tela apresentada ao entrar no sistema com o perfil administrador, possvel efetuar consulta dos processos existentes e fazer alterao de suas informaes. tambm nessa etapa que um novo processo

116 criado para ser automatizado. Uma observao importante a caracterstica seqencial das etapas. Por exemplo, para criao da modelagem do processo, obrigatria a definio das informaes bsicas do processo e, para criao dos formulrios, deve-se ter realizada a modelagem e assim por diante.

Figura 40 Consulta de processos. Fonte: Elaborao dos autores, 2011.

Na imagem seguinte, segue tela de cadastro de um novo processo.

117

Figura 41 Cadastro do processo. Fonte: Elaborao dos autores, 2011.

Aps a definio das informaes bsicas do processo, no menu do canto superior direito, tem-se a combo-box Processo Atual, onde a partir de sua seleo pode-se realizar o desenho do processo, bem como a definio dos dados, formulrios e regras de negcio.

Figura 42 Processo atual. Fonte: Elaborao dos autores, 2011.

Aps a definio e seleo do processo a ser automatizado, na aba Modelagem, pode ser realizado o desenho do processo, podendo, tambm, a partir dela, editar ou excluir qualquer informao contida nesta etapa.

118

Figura 43 Modelagem do processo. Fonte: Elaborao dos autores, 2011.

No desenho do processo, podem-se arrastar os elementos da paleta, ou mesmo, aps o primeiro elemento inserido, inserir outros elementos a partir dele. Na figura a seguir demonstrado um exemplo em que no lado inferior direito exibido um cone, que ao ser clicado, habilita a opo de redimensionamento da piscina.

Figura 44 Elementos do desenho do processo. Fonte: Elaborao dos autores, 2011.

119 Na figura a seguir um exemplo do desenho do processo. No exemplo, tem-se a opo de nomeao da piscina que, selecionando a aba do desenho do processo, habilitada sua edio.

Figura 45 Desenho do processo. Fonte: Elaborao dos autores, 2011.

Aps a definio do desenho do processo, pode-se partir para criao de dados e formulrios por meio da aba Formulrio e Dados. Esse um mdulo muito importante, pois , por meio dele, que o usurio final poder interagir com o processo atravs do preenchimento de formulrios.

Figura 46 Aba Formulrio e Dados. Fonte: Elaborao dos autores, 2011.

Ao desenhar um formulrio, o mesmo deve ser associado a uma tarefa do processo. Dessa forma, est sendo indicado que, quando o processo chegar determinada

120 atividade, o formulrio em questo ser exibido para preenchimento ou apenas para visualizao, dependendo do que foi configurado. Sempre um formulrio, para ser criado, deve ser associado a uma tarefa e, seus dados, definidos previamente. No caso da figura 47, tem-se a tarefa que ser associada para efetuar o desenho do formulrio, que se encontra no canto superior direito na aba formulrio.

Figura 47 Seleo de tarefa. Fonte: Elaborao dos autores, 2011.

Como dito anteriormente, para o desenho dos formulrios, necessrio que os dados tenham sido previamente cadastrados. Os dados possuem um papel fundamental, pois eles representam as informaes de que um processo necessita para ser executado corretamente e por meio dele que regras e condies so definidas.

Figura 48 Cadastro de dados. Fonte: Elaborao dos autores, 2011.

Na figura que segue, so exibidos os dados aps seu cadastramento. por meio desses dados que os formulrios so criados, bastando para isso arrastar os dados para rea do formulrio, criando, assim, um campo de formulrio.

121

Figura 49 Apresentao dos dados do processo. Fonte: Elaborao dos autores, 2011.

A parte inferior da tela de formulrio permite a definio de seu ttulo.

Figura 50 Nome do formulrio. Fonte: Elaborao dos autores, 2011.

Na figura 51, um exemplo de desenho de formulrio para a tarefa Requisita frias.

Figura 51 Definio do formulrio. Fonte: Elaborao dos autores, 2011.

122

Retornando aba Modelagem, podem ser definidas as regras de navegao. Para efetuar esta ao, seleciona-se a opo do elemento deciso. Ao lado direito da tela so exibidos os caminhos possveis, bastando para isso, selecionar um dos caminhos ou fluxo de deciso que se deseja definir uma regra de navegao.

Figura 52 Definio das regras de navegao. Fonte: Elaborao dos autores, 2011.

Na imagem 53 exibido como ser a apresentao da tela para deciso da navegao, como exemplo a deciso denominada Aprovado?, nesse so apresentados as opes ou caminhos possveis que o fluxo pode seguir. Esse fluxo e regras so avaliados a partir do momento em que um processo se encontra em execuo.

Figura 53 Regras de navegao. Fonte: Elaborao dos autores, 2011.

Ao selecionar um fluxo de sequncia ou caminho, exibida a tela de definio de regras. Nessa tela so definidas as informaes bsicas da regra e as condies para que a mesma seja executada. No exemplo 54, o caminho selecionado define que se a regra foi satisfeita, o fluxo do processo seguir para a atividade Encaminha. Para que a regra seja satisfeita, a varivel Aprovado deve ser igual a true (verdadeiro) e o solicitante deve ser

123 um Funcionrio. Percebe-se que, a partir dessa tela, possvel criar condies diversas, podendo representar situaes com certo grau de complexidade.

Figura 54 Edio das regras de navegao. Fonte: Elaborao dos autores, 2011.

Tambm, atravs da aba Modelagem, ao clicar sobre uma tarefa do processo, exibida a aba com a opo de incluir regras de negcio.

124

Figura 55 Definio das regras de negcio. Fonte: Elaborao dos autores, 2011.

As regras podem ser inseridas tanto na entrada como na sada de uma tarefa, bastando para isso clicar nas referidas setas. Uma observao importante que ao executar uma tarefa no portal do usurio, a posio das regras, ou seja, entrada (ANTES) ou sada (DEPOIS), definem a ordem de execuo das mesmas. Se forem definidas regras na entrada, essas sero executadas antes que a tarefa em si seja apresentada ao usurio e, caso tenham sido definidas regras de sada, essas sero executadas aps a execuo da tarefa em questo. Segue imagem:

Figura 56 Regras de negcio. Fonte: Elaborao dos autores, 2011.

Na figura a seguir apresentado o cadastro das regras de negcio.

125

Figura 57 Edio das regras de negcio. Fonte: Elaborao dos autores, 2011.

Como se pode verificar, no topo da tela de cadastro apresentada a ordem em que a regra ser inserida.

Figura 58 Apresentao do local que esta sendo inserido a regras de negcio. Fonte: Elaborao dos autores, 2011.

Aps salvar, a regra fica visvel indicando a ordem em que foi criada, podendo ser editada clicando-se sobre a respectiva seta, no qual apresentada a tela para edio, conforme figura 59.

126

Figura 59 Apresentao das regras inseridas. Fonte: Elaborao dos autores, 2011.

Essas so as etapas desenvolvidas pelo administrador para gerenciar os processos.

5.4.2

Participantes do processo

Os participantes ou atores representam as pessoas que efetivamente participaro da execuo dos processos. So eles que interagiro com os formulrios associados s tarefas. Para associar um participante, semelhante navegao da definio de regras de negcio. O usurio dever selecionar uma atividade e ao lado ser exibida tela de configuraes, no qual se tem a opo de adicionar um participante. Uma observao que, nessa verso do projeto, permitido selecionar um participante por vez, caso queira associar mais de um participante, a etapa de cadastramento deve ser repetida.

127

Figura 60 Associar participante a tarefa do processo. Fonte: Elaborao dos autores, 2011.

Na tela para associao de tarefas, apresentado campo para adicionar os usurios.

Figura 61 Participantes do processo. Fonte: Elaborao dos autores, 2011.

Ao clicar em adicionar participantes, exibida uma tela, contendo todos os usurios cadastrados. Para associar um participante, basta clicar no link no nome do usurio.

128

Figura 62 Usurios cadastrados para associar a tarefa. Fonte: Elaborao dos autores, 2011.

Aps a concluso da associao, o usurio exibido na tela de participantes do processo.

Figura 63 Usurios participantes da tarefa do processo. Fonte: Elaborao dos autores, 2011.

129 5.4.3 Administrao de usurios

A tela de administrao de usurios responsvel por todo gerenciamento dos usurios do sistema. A partir dessa tela, pode-se consultar, criar, editar, ativar e inativar um usurio. Para acessar a administrao de usurios, deve-se ir ao menu Administrao -> Usurios.

Figura 64 Administrao de usurios. Fonte: Elaborao dos autores, 2011.

Ao clicar no menu, exibida a consulta dos usurios atuais do sistema.

Figura 65 Apresentao dos usurios cadastrados. Fonte: Elaborao dos autores, 2011.

130

Se o administrador deseja adicionar um novo usurio, basta clicar no boto Adicionar Novo Usurio.

Figura 66 Adicionar novo usurio. Fonte: Elaborao dos autores, 2011.

A partir da tela de consulta, tambm, possvel inativar ou ativar um usurio. Ao inativar um usurio, ele ficar impossibilitado de participar de novas tarefas, porm no perder o vnculo das tarefas que j faz parte.

131

Figura 67 Processo de ativar e inativar usurios. Fonte: Elaborao dos autores, 2011.

Essas so as etapas em que o administrador associa usurios a determinadas tarefas do processo.

5.4.4

Execuo das tarefas do processo

O portal de processos, ou o que foi denominado como Portal do Usurio, onde todas as configuraes definidas pelo administrador so convertidas para um modelo executvel, permitindo que usurios habilitados possam efetivamente interagir com suas atividades dirias. Uma caracterstica interessante que o usurio direcionado ao que fazer, onde atravs de seu ambiente de trabalho tarefas so exibidas para que sejam cumpridas por ele. Dessa forma, ele tem plena conscincia de suas responsabilidades e impacto sobre o restante do processo.

132 Para que sejam executadas as tarefas do processo, o administrador poder ter acesso atravs da opo Processo. Segue figura.

Figura 68 Opo para execuo das tarefas associadas. Opo Processo. Fonte: Elaborao dos autores, 2011.

Na figura que segue, apresentada a tela onde sero gerenciadas as tarefas.

Figura 69 Apresentao da tela onde sero gerenciadas suas tarefas. Fonte: Elaborao dos autores, 2011.

Para o usurio que no se encaixa como administrador, ao se logar no sistema, ser exibida a mesma tela, somente o menu ser diferenciado, no qual no constar a opo de Automatizao. Atravs do ambiente de trabalho do usurio, so exibidos os processos que o mesmo est habilitado a iniciar, sendo possvel, a qualquer momento, selecionar um processo da listagem ou consultar um especfico para iniciar sua execuo. Essa opo disponibilizada ao lado esquerdo da tela de tarefas.

133

Figura 70 Processos cadastrados no nome de determinado usurio. Fonte: Elaborao dos autores, 2011.

Na tela a seguir, possvel visualizar todas as tarefas pendentes do usurio. As informaes disponveis so: processo, tarefa, status e data.

Figura 71 Tarefas cadastradas de determinado processo. Fonte: Elaborao dos autores, 2011.

Para iniciar a execuo de uma tarefa, basta clicar sobre seu nome. Ao clicar, ser apresentada tela para preenchimento da tarefa, sendo essa o formulrio definido pelo administrador na automao. Atravs dela, pode-se efetuar a sua concluso clicando em Enviar, onde uma tela de confirmao ser exibida.

134

Figura 72 Edio de determinada tarefa. Fonte: Elaborao dos autores, 2011.

Na imagem anterior, tem-se a opo Histrico, que ao ser clicada, exibe todas as aes realizadas no processo at o momento.

Figura 73 Histrico da tarefa selecionada. Fonte: Elaborao dos autores, 2011.

135 5.5 VALIDAO

A validao foi efetuada em duas etapas. Atravs de um estudo de caso, realizando testes com o sistema e atravs de um quadro comparativo, verificando o cumprimento dos requisitos estabelecidos.

5.5.1

Validao dos requisitos funcionais

Conforme modelagem dos requisitos funcionais apresentados, segue no quadro 17, os requisitos junto com a validao da implementao. Requisitos Cadastrar processo Requisitos atendidos? Sim Parcial No X Observaes O cadastro/edio de processo ocorre no perfil de administrador. a primeira etapa do sistema. Ser efetuado na mesma tela do cadastrar processo. S ser efetuada de forma diferenciada. o segundo processo do sistema. Por meio dele que o processo desenhado. Pode ser considerado um dos mdulos mais importantes do sistema. Todas as funcionalidades do sistema giram em torno desse. Esse requisito pode ser subdividido em outros, pois o mdulo se mostrou bem extenso. Nessa etapa, a interface apresenta formulrio de cadastro de cada campo de um processo especfico. Se o mesmo j possuir dados, apresentado, podendo ser editado ou excludo. Nessa opo, necessrio que os dados j tenham sido cadastrados,

Consultar processo

Desenhar processo

Cadastrar dados do processo

Desenhar formulrio do processo

136 pois por meio desses que cada campo do formulrio criado. Cadastrar regras de negcio X Nessa etapa, as regras de negcio referentes a um processo so cadastradas. por meio dela que um fluxo de deciso avaliado. Como exemplo: Se uma compra for maior que R$ 20.000, o processo vai para o gerente de compras valid-lo. Esse requisito visvel apenas quando selecionado um fluxo de seqncia em uma deciso, em que as regras e condies da mesma so exibidas. Essa opo apresenta tela em que se podem incluir usurios do sistema. Atravs dessa opo possvel visualizar usurios cadastrados no sistema. Os usurios do sistema nunca so excludos, mas somente desativados. Dessa forma, tem-se maior controle, onde um usurio desativado deixa de executar tarefas perdendo acesso ao seu portal. Essa opo possibilita que usurios sejam associados processos, habilitando-os para sua execuo. Esse requisito habilita a edio do nome de um formulrio. Essa opo essencial para todos os outros mdulos do sistema. Atravs da seleo de um processo, pode-se efetuar o desenho, inserir regras, dados e formulrios. Essa opo onde uma determinada tarefa do processo selecionada, para que seja includo o formulrio. Atravs dessa opo efetuado acesso ao sistema, constando os

Consultar regras de navegao

Cadastrar usurios Consultar usurios

X X

Inativar/Ativar usurios

Associar usurios a processos Nomear formulrio Selecionar processo

X X

Selecionar tarefa para criar formulrio Controlar acesso (login)

137 campos de login e senha. Consultar processos associados Cadastrar informaes nas tarefas do processo Visualizar processos X Nessa opo, pode-se efetuar consulta referentes aos processos cadastrados. Essa opo permite ao usurio informar os dados do formulrio de uma tarefa. Essa opo exibe ao usurio todos os processos que o mesmo est habilitado a iniciar. Nesse item, possvel verificar todas as aes que foram efetuadas para determinado processo. Essa opo a tela de entrada, no qual os usurios podem verificar as tarefas do processo e efetuar suas alteraes.

Visualizar histrico da tarefa no processo Visualizar tarefas pendentes

Quadro 17 Validao dos requisitos. Fonte: Elaborao dos autores, 2011.

5.5.2

Estudo de Caso

Conforme Ponte (2009), um estudo de caso "visa conhecer em profundidade o seu como e os seus porqus, evidenciando a sua unidade e a sua identidade prprias". Trata-se de uma pesquisa no qual seu objetivo principal descrever, para que o investigador consiga compreender como, no caso, o sistema, se porta. Auxilia, tambm, na descoberta de novas opes ou at mesmo melhorias. O estudo de caso deve ser todo documental, podendo ser escrito ou em forma de vdeo e deve ser apresentado em forma de historia. Para validao do projeto, foi realizado um estudo de caso, em que foi criado um cenrio, descrevendo todas as etapas de construo do mesmo. Para o estudo de caso, foi modelado e automatizado o processo Gerenciamento de Incidentes, que consiste na resoluo, o mais rpido possvel, de um problema, restabelecendo o servio brevemente, reduzindo, assim, o impacto negativo no negcio. Um incidente pode ser descrito como

138 qualquer evento que no faa parte da operao padro e que possa causar uma interrupo de um servio. (DEVMEDIA, 2011). Seguindo algumas etapas do ciclo BPM descritas na pesquisa bibliogrfica, temse a fase Planejar o BPM, Modelar e Otimizar o Processo, Desenvolvimento, Controle e Anlise do Processo. Para o projeto e estudo de caso, supe-se que a etapa Planejar o BPM j tenha sido realizada. Ento, o escopo do projeto ficar entre a Modelagem e Desenvolvimento do processo Gerenciamento de Incidentes. A primeira etapa, para iniciar a modelagem e automao de processos, consiste em definir um nome e algumas informaes bsicas para o mesmo.

Figura 74 Tela inicial, exibindo inicialmente todos os processos cadastrados. Fonte: Elaborao dos autores, 2011.

Na figura seguir, so apresentadas as informaes do processo, no qual exibida atravs da tela de cadastro de um novo processo.

139

Figura 75 Informaes bsicas do processo Gerenciamento de Incidentes. Fonte: Elaborao dos autores, 2011.

Aps definir as caractersticas bsicas de um processo, a combo-box Processo Atual, exibe todos os processos cadastrados. Nesse item, definido qual processo ser configurado ou trabalhado no momento. A partir dessa seleo, todas as operaes posteriores sero associadas a esse processo.

Figura 76 Processo corrente. Fonte: Elaborao dos autores, 2011.

Uma etapa importantssima a modelagem do processo. Nela, so definidas todas as atividades, fluxos e descries bsicas do modelo. Por meio da definio da modelagem, possvel visualizar, de forma clara e de fcil entendimento tanto pelo pessoal tcnico como de negcios, todos os participantes do processo, responsabilidades e, principalmente, conhecer de ponta a ponta como um processo caminha dentro de uma organizao e de como o mesmo gera resultado para o cliente.

140

Figura 77 Modelagem do processo. Fonte: Elaborao dos autores, 2011.

Aps a definio da modelagem do processo, tem-se a etapa para criao de dados e formulrios do processo. Os dados tm um papel fundamental, pois eles representam as informaes necessrias para que um processo funcione corretamente. Por meio dos dados, so criados os formulrios, e esses so associados a atividades do processo.

Figura 78 Tela em que sero apresentados os dados, e local onde se cadastram. Fonte: Elaborao dos autores, 2011.

Os dados ou variveis do processo so criadas de forma rpida e intuitiva, podendo ser editadas a qualquer momento.

141

Figura 79 Tela do cadastro de dados. Fonte: Elaborao dos autores, 2011.

Aps o cadastramento dos dados, os mesmos so exibidos na paleta ao lado esquerdo da rea, para criao de formulrios.

Figura 80 Apresentao dos dados. Fonte: Elaborao dos autores, 2011.

142

A criao de formulrios extremamente simples e rpida de ser realizada. Basta apenas arrastar os dados da esquerda para a tela de formulrios direita. Por meio dessa tela, pode-se remover um campo ou alterar o nome do campo do formulrio a qualquer momento. No exemplo da figura 81 foi criado o formulrio para a tarefa Registrar Incidente, na qual, as informaes iniciais sobre o incidente so registradas.

Figura 81 Preenchimento do formulrio. Fonte: Elaborao dos autores, 2011.

Normalmente, cada tarefa definida na modelagem e que precise de alguma interao humana, deve possuir um formulrio associado. Dessa forma, cada formulrio, ao ser criado, deve ser associado a uma tarefa por meio da combo-box Tarefa associada.

Figura 82 Seleo de tarefa associada. Fonte: Elaborao dos autores, 2011.

Uma parte fundamental que vai definir como um processo se comportar quando o mesmo for executado, a definio de regras de negcio. Nesse caso especfico, as regras so de navegao. por meio da navegao que o sistema saber, a partir do preenchimento de um formulrio, qual ser a prxima atividade a ser executada. Essa deciso de qual tarefa executar expressa por meio de condies, e essas podem ser combinadas para gerar regras bem complexas. Ao selecionar uma deciso, o sistema exibir todos os caminhos possveis para a mesma, bastando apenas clicar em que caminho se deseja incluir uma regra. Uma observao

143 importante que pelo menos uma das condies deve retornar verdadeiro, pois, sem isso, o processo, ao ser executado, fica parado, pois nenhuma das condies foi satisfeita.

Figura 83 Apresentao das regras de navegao. Fonte: Elaborao dos autores, 2011.

A tela de definio de regras bem intuitiva e se baseia em operaes lgicas sobre as variveis cadastradas para o processo. Na figura a seguir, tem-se a regra que definir quando o fluxo de execuo seguir para a atividade Investigar/Diagnosticar Incidente. Caso forem necessrias regras mais complexas, basta ir adicionando outras condies. Dessa forma, podem-se criar regras como: Se a rea responsvel for igual a Desenvolvimento e o problema informado for relacionado a software, ento siga para a atividade

Investigar/Diagnosticar Incidente.

144

Figura 84 Cadastro das regras de navegao. Fonte: Elaborao dos autores, 2011.

Outra caracterstica interessante do mdulo de regras de negcio a possibilidade de se definir regras associadas s tarefas. Essas regras podem ser criadas para dois estgios distintos. Os estgios possveis so entrada (ANTES) e sada (DEPOIS). Dessa forma, uma tarefa pode ter condies que sero processadas antes da execuo de uma tarefa e/ou depois de sua execuo. Essas regras possibilitam ao sistema a capacidade de expressar restries, polticas e particularidades inerentes ao negcio de uma organizao.

145

Figura 85 Apresentao das regras de negcio. Fonte: Elaborao dos autores, 2011.

A imagem a seguir demonstra o cadastro de uma regra para uma determinada tarefa. No exemplo, a atividade Classificar/Priorizar Incidente, antes de sua execuo, ser definida a regra que verifica se a rea responsvel pela soluo do problema a equipe de desenvolvimento. Nesse caso, a prioridade ser definida como ALTA e exibida na prxima tarefa.

146

Figura 86 Cadastro das regras de negcio. Fonte: Elaborao dos autores, 2011.

A qualquer momento pode-se manipular as regras definidas, bastando selecionar a tarefa e a respectiva regra, para efetuar sua edio ou excluso. Segue figura.

Figura 87 Apresentao das regras cadastradas. Fonte: Elaborao dos autores, 2011.

147 Para que o usurio consiga executar esta tarefa do processo, necessrio que o mesmo esteja associado tarefa. Para efetuar esta associao utiliza-se a mesma tela. Para associar o usurio, basta selecionar o cone, na figura 88 da opo Participante do Processo, conforme figura a seguir.

Figura 88 Associar participante a tarefa do processo. Fonte: Elaborao dos autores, 2011.

Aps clicar sobre o cone, so apresentados todos os usurios, no qual possvel localizar o usurio que ser associado tarefa. Para associ-lo, basta clicar sobre o nome do mesmo. Tambm, atravs dessa tela possvel editar ou ativar/inativar atravs da coluna Status.

148

Figura 89 Tela de gerenciamento do usurio. Fonte: Elaborao dos autores, 2011.

Se o usurio no est cadastrado, pode-se inclu-lo de forma simples, clicando sobre a opo Adicionar Novo Usurio, no qual abrir a tela Novo Usurio.

149

Figura 90 Cadastro de usurio. Fonte: Elaborao dos autores, 2011.

Se o administrador somente deseja cadastrar ou gerir os usurios, tem-se a opo Administrao > Usurios, que ir apresentar a mesma tela.

Figura 91 Gerenciamento dos usurios. Fonte: Elaborao dos autores, 2011.

150 5.5.2.1 Concluso do Estudo de Caso

Por meio do projeto em questo, pode-se constatar a facilidade de criao e evoluo de um processo. Rapidamente, um processo pode ser criado, expressando formulrios, caminhos, regras, participantes e responsabilidades. Dessa forma, uma organizao no sofre com a demora no desenvolvimento tradicional ou alterao de um sistema, que acaba retardando a evoluo da mesma. As organizaes esto em constante evoluo e, o projeto em questo, contribui para que as mesmas evoluam na velocidade ideal, facilitando mudanas e fortalecendo a comunicao entre a rea de negcios e TI. O estudo de caso demonstrou a criao de todas as etapas necessrias para criao de um processo de negcio. As etapas descritas so seqenciais, isso significa que esto integradas e dependentes entre si.

5.6

CONSIDERAES FINAIS DO CAPTULO

Neste captulo, foi apresentado o desenvolvimento do projeto, bem como as ferramentas, tecnologias e frameworks utilizados. Tambm foi descrito o procedimento de desenvolvimento, as dificuldades encontradas, bem como as solues para os problemas. Apresentaram-se as telas do sistema e suas funcionalidades. Ao final, efetuou-se a validao do sistema comparando com os requisitos citados, alm de um estudo de caso, demonstrando as etapas e funcionamento do processo, assim como descrio de cada uma.

151 6 CONCLUSO E TRABALHOS FUTUROS

Neste capitulo ser descrito as consideraes finais deste projeto, apresentando uma anlise dos resultados alcanados comparando com a proposta inicial, bem como indicaes para trabalhos futuros.

6.1

CONCLUSO

Este trabalho apresentou o desenvolvimento de um sistema para gerenciamento de processos de negcio visando apoiar as organizaes na execuo e controle de suas atividades. A seguir, so apresentadas as principais concluses. O processo de desenvolvimento se iniciou com a anlise de alguns softwares BPMS do mercado, que por sua vez resultou no levantamento dos principais requisitos e regras de negcio inerentes a esse tipo de ferramenta. Em seguida foi realizada a modelagem e estudos para aplicao dos motores de processos e de regras de negcio, bem como a realizao de um estudo de caso. Atravs das etapas descritas na modelagem e da aplicao dos motores, o material aqui exposto pode contribuir para o desenvolvimento de novos sistemas com o foco no gerenciamento de processos de negcio. A aplicao de motores de processos e de regras de negcio na etapa de desenvolvimento apresentou algumas dificuldades, sendo essas visveis principalmente na correta aplicao e integrao entre essas tecnologias. Como conseqncia, levou-se tempo considervel para obteno de resultados palpveis. Em contrapartida, possibilitou que no fosse reinventada a roda reduzindo drasticamente o tempo de desenvolvimento, na qual, diversas funcionalidades teriam der ser desenvolvidas para obteno do mesmo resultado. A utilizao de motores estimulada, mas indica-se que as principais caractersticas dessas sejam bem avaliadas antes de sua aplicao em ambiente de desenvolvimento. Atravs da aplicao do estudo de caso pde ser observada a velocidade de evoluo de um processo e a capacidade de se inserir novas melhorias, onde, com o desenvolvimento tradicional seria praticamente impossvel.

152 A automatizao do processo considerado no estudo de caso foi implementado em minutos, onde as alteraes eram refletidas praticamente em tempo real no processo em execuo, sendo essa, uma caracterstica essencial para as organizaes atuais, onde mudanas, novos requisitos de negcio e novas polticas devem ser geridos em tempo hbil e com eficincia. Atravs do desenvolvimento e aplicao do sistema em questo, alguns resultados gerais foram alcanados, como: Padronizao: atravs do modelador grfico desenvolvido utilizando a notao BPMN, processos foram desenhados seguindo padres reconhecidos internacionalmente, o que favorece a comunicao entre os diversos atores do processo. Alm disso, atravs do mdulo de regras de negcio, regras foram criadas facilmente, de forma estruturada e armazenadas em um repositrio nico, disponibilizando um ponto central de acesso. Essa centralizao importante gerando um repositrio de conhecimento da organizao. Visibilidade: processos se tornam visveis integralmente por todos os participantes, bem como seus papis e responsabilidades. Produtividade: atravs do portal do usurio, tarefas so exibidas em sua rea de trabalho, indicando ao usurio o que fazer, tornando assim, o trabalho menos burocrtico. Mudanas: novos processos so criados e alterados rapidamente, permitindo que a organizao utilize suas foras para entregar valor ao cliente. Histrico de Processos: atravs do armazenamento de todas as informaes dos processos e de suas tarefas, possvel realizar auditoria de todas as atividades obtendo-se informaes valiosas como responsveis ou quando tarefas foram executadas. Tambm, a anlise desses dados possibilita que gestores possam encontrar possveis gargalos nos processos. O armazenamento do histrico tambm favorece as empresas que desejam obter algum tipo de ISO. Por ser esse um tema relativamente novo, o sistema desenvolvido, pode servir como referncia para que organizaes possam visualizar os resultados obtidos aqui e, avaliarem a aplicao de um sistema BPMS em sua estrutura organizacional para gerir seus processos de negcio.

153

6.2

TRABALHOS FUTUROS

Atravs de estudos realizados no desenvolvimento deste projeto, verificou-se que algumas ferramentas so importantes para possibilitar maior gesto e controle de todo o ciclo de desenvolvimento de processos, sendo elas: BAM: Para um maior controle e monitoramento em tempo real dos processos de negcio, gestores podem se beneficiar das informaes geradas por essa ferramenta, podendo utiliz-las para tomada de deciso. Integrao com bases externas: As organizaes atualmente possuem diversos sistemas de informao espalhados entre as diversas reas. Dessa forma importante que as ferramentas BPMS possam se integrar s bases desses sistemas extraindo informaes para alimentar os processos de negcio. Integrao com servios: Atravs da arquitetura SOA e sua caracterstica onde componentes de software so desenvolvidas em forma de servios interessante que o sistema BPMS possa integr-los a qualquer momento. Simulao de Processos: De todos os mdulos citados anteriormente esse o menos visto em sistemas BPMS e, isso se justifica pela complexidade inerente a ele. Atravs da simulao de processos, gestores ao invs de implantarem os processos e avaliarem sua execuo j em ambiente de produo, podem, antes mesmo de public-lo, avaliar e encontrar possveis gargalos atravs de relatrios que so gerados por esse tipo de ferramenta. O benefcio gerado inestimvel podendo esse, evitar que uma organizao perca dinheiro por um processo mal planejado e implementado.

154 REFERNCIAS

ACTIVITI. Disponvel em: < http://www.activiti.org/ >. Acesso em: 29/05/2011 ADOBE. Disponvel em: <www.adobe.com/br/>. Acesso em: 24/09/2011 ALVARENGA, Geoflvia Guilarducci. Uma Abordagem para Tratamento de Regras de Negcio em Sistemas de Informao . 2007. 149f. Curso de PsGraduao do Instituto de Informtica da Universidade Federal de Gois. Gois, 2007. ANDRADE, Maria Margarida de. 5 ed. Introduo metodologia do trabalho cientfico: elaborao de trabalhos na graduao. So Paulo: Atlas, 2001. ANGELONI, Maria Terezinha. Organizaes do Conhecimento : Infra-estrutura, Pessoas e Tecnologias. Editora Saraiva. So Paulo. 2009. AZEVEDO, Leonardo, et al. Conceituao de BRMS. 2009. Disponvel em: < http://www.seer.unirio.br/index.php/monografiaspp. i/article/viewFile/404/351 >. Acesso em: 24/04/2011. BALDAM, Roquemar, et al.. Gerenciamento de Processos de Negcio : BPM - Business Process Management. Editora rica Ltda, So Paulo, 2010. BITENCOURT, Maurcio. Modelagem de Processos com BPMN. 2007. Disponvel em: < http://www.baguete.com.br/artigos/270/mauricio-bitencourt/19/07/2007/modelagem-deprocessos-com-bpmn >. Acesso em: 24/04/2011. BLAZEDS. Disponvel em: < http://opensource.adobe.com/wiki/display/blazeds/BlazeDS >. Acesso em: 22/09/2011 BOER, Fernanda. BPMN 2.0 . 2010. Disponvel em: < http://blog.orquestrabpm.com.br/2010/06/bpmn-20.html >. Acesso em: 05/05/2011. BORTOLINI, Rafael. AS IS X TO BE. 2010. Disponvel em: < http://blog.orquestrabpm.com.br/2010/02/as-is-x-to-be.html >. Acesso em: 30/04/2011. CAELUM. Disponvel em: < www.caelum.com.br>. Acesso em: 26/09/2011 CHISHOLM, Malcom. How to Build a Business Rules Engine: Extending Application Functionality Through Metadata Engineering, 2004, Elsevier Science (USA). CORAL, Eliza et al.. PLATIC | Arranjo Produtivo Catarinense: Tecnologia de informao e comunicao. 2007. Disponvel em: < http://www2.ielsc.org.br/capitulo1_platic.pdf >. Acesso em: 31/03/2011. CRYO Technologies. BPMN 2.0 . 2010. Disponvel em: < http://blog.orquestrabpm.com.br/2010/06/bpmn-20.html >. Acesso em: 28/04/2010. CRUZ, Tadeu. BPM & BPMS: Business Process Management & Business Management Systems. Rio de Janeiro: Brasport, 2010.

155 CRUZ, Tadeu. Uso e Desuso de Sistemas de Workflow : Porque as organizaes no conseguem obter retorno com investimentos em projetos de Workflow , E-Papers Servios Editoriais, Rio de Janeiro, 2006. DAVENPORT, T. H. Reengenharia de processos. Rio de Janeiro: Campus, 1994. DVALOS, Dr. Ricardo Villarroel. Modelagem de Negcios. 2011. Disponvel em: < http://inf.unisul.br/~davalos/davalosmoneg.htm > Acesso em: 28/04/2011. DVALOS, Dr. Ricardo Villarroel. Modelagem de Processos. Palhoa: UnisulVirtual, 2010. DAVENPORT, Thomas. H. Reengenharia de Processos: como inovar na empresa atravs da tecnologia da informao. Rio de Janeiro, Campus, 1994. DEITERT, E., MCCOY, D., The Anatomy of a Business Rule Management System, Gartener Research, 2007. IN: AZEVEDO, Leonardo, et al. Conceituao de BRMS. 2009. Disponvel em: < http://www.seer.unirio.br/index.php/monografiaspp. i/article/viewFile/404/351 >. Acesso em: 24/04/2011. DUBRAY, Jean-Jacques. Architecture. Disponvel em: < http://www.ebpml.org/architecture.htm >. Acesso em: 02/05/2011. ECLIPSE. Disponvel em: < http://www.eclipse.org/ >. Acesso em: 26/09/2011 FLEX . Disponvel em: < http://opensource.adobe.com/wiki/display/flexsdk/flex+4 >. Acesso em: 22/09/2011 FLASH BUILDER. Disponvel em: < http://www.adobe.com/products/flash-builder.html>. Acesso em: 24/09/2011 FOWLER, Martin. UML Essencial: Um breve guia para a linguagem-padro de modelagem de objetos. 2004, Porto Alegre, ARTMED Editora S.A.. GARIMELLA, Kiran et al. Introcuccin a BPM para Dummies. Indianpolis, Indiana: Wiley Publishing, 2008. GARTNER Research. Disponvel em: <http://www.gartner.com/technology/home.jsp>, Acesso em: 2008. IN: KO, Ryan K. L. A Computer Scientist`s Introductory Guide to Business Process Management (BPM). 2009. Disponvel em: <http://xrds.acm.org/article.cfm?aid=1558901>. Acesso em: 19/04/2011. GHALIMI, Ismael Chang. BPM 2.0. 2006. Disponvel em: < http://www.projeler.com.br/download/pdf/bpm20_ptbr.pdf >. Acesso em: 29/04/2011. GSIG, Grupo de Sistemas Integrados de Gesto. Paradigmas para a automao de processos. Disponvel em: < http://inf.unisul.br/~gsig/modelagem-de-processos-deneg%C3%B3cio/paradigmas-para-automa%C3%A7%C3%A3o-de-processos>. Acesso em: 24/04/2011. HEUSER, Carlos Alberto. Projeto de Banco de Dados. Rio Grande do Sul, Editora Sagra, 1998. Disponvel em: <http://groups.google.com/group/Viciados_em_Livros/>. Acesso em: 30/08/2011

156 HURWITZ, Judith et al. Arquitetura Orientada a Servios SOA: para leigos, Rio de Janeiro, Altabooks, 2009. IPBPM, Instituto Portugus de Business Process Management: Process Community. Ferramentas BPM. Disponvel em: < http://www.ipbpm.pt/pt/ferramentas_bpms >. Acesso em: 22/04/2011. IPROCESS. BPM. Disponvel em: <http://www.iprocess.com.br>. Acesso em: 01/12/2010. IPROCESS. BPM. Disponvel em: < http://www.youtube.com/user/iprocessbpm>. Acesso em: 01/12/2010. IPROCESS. BPMN. O modelo E-R dos Processos. Disponvel em: < http://www.iprocess.com.br/artigos/bpmn.asp >. Acesso em: 24/04/2011. JBOSS Community. Disponvel em: < http://www.jboss.org/ >. Acesso em: 01/05/2011. KERZNER, Harold. Gesto de Projetos: as Melhores Prticas, So Paulo, Artmed Editora S.A, 2004. KO, Ryan K. L. A Computer Scientist`s Introductory Guide to Business Process Management (BPM). 2009. Disponvel em: <http://xrds.acm.org/article.cfm?aid=1558901>. Acesso em: 19/04/2011. LARMAN, Craig. UTILIZANDO UML E PADRES: Uma introduo anlise e ao projeto orientado a objetos e ao desenvolvimento iterativo. 2005, Porto Alegre, ARTMED Editora S.A.. LUI, Rafael. JBoss Drools 5 - Implementando regras de negcio com o Drools. 2011. Disponvel em: < http://www.devmedia.com.br/articles/viewcomp.asp?comp=19270# >. Acesso em: 01/05/2011. MARR, Bernard. How to Design key Performance Indicators, API, 2009. Disponvel em: < http://www.apinstitute.com/downloads/100608%20How%20to%20design%20Key%20Performance%20Ind icators.pdf >. Acesso em: 25/04/2011. MASTERTHEBOSS . JBoss Drools tutorial. Disponvel em: < http://www.mastertheboss.com/jbpm/45-JBoss-drools-1.html >. Acesso em: 01/05/2011. NEXTGENERATION. BPM . Disponvel em: < http://pt.scribd.com/doc/3807598/Gerenciamento-BPM >. Acesso em: 7/05/2011. OMG. Business Process Model and Notation (BPMN). 2011. Disponvel em: < http://www.omg.org/spec/BPMN/2.0/PDF>. Acesso em: 20/04/2011. ORACLE. Disponvel em: < www.oracle.com/br/index.html >. Acesso em: 27/09/2011. ORANA, Arthur Cesar. Integrao de BPM em aplicaes corporativas JEE. Disponvel em: < http://www.slideshare.net/aoreana/integrao-de-bpm-em-aplicaes-corporativas-jee >. Acesso em: 6/05/2011.

157 PONTE, Joo Pedro de. O estudo de caso na investigao em educao matemtica. Disponvel em: < http://www.educ.fc.ul.pt/docentes/jponte/docs-pt/94-Ponte%28QuadranteEstudo%20caso%29.pdf>. Acesso em: 29/10/2011. ROSEN, Mike. Orchestration or Choreography? 2008. Disponvel em : < http://www.bptrends.com/publicationfiles/04-08-COL-BPMandSOAOrchestrationorChoreography-%200804-Rosen%20v01%20_MR_final.doc.pdf >. Acesso em: 29/05/2011. ROSS, G. Ronald. Business Rules Journal, What You Need to Know About Rulebook Management. 2009. Disponvel em: < http://www.brcommunity.com/b500.php?zoom_highlight=What+you+need+to+know+about+ rulebook+management>. Acesso em: 21/04/2011. SILVA, E.L DA e MENEZES, E.M. Metodologia da Pesquisa e elaborao de Dissertao . 4 Ed. UFSC, Florianpolis, 2005. SILVA, R. Fabrcio. BPEL Business Process Execution language: Tutorial: Implementando um processo de negcio com BPEL, 2009, So Paulo. Disponvel em: < http://www.wsbpel.hd1.com.br >. Acesso em: 25/04/2011. SCHLTER, R Mauro. Indicadores Chaves de Performance. 2009. Disponvel em: < http://www.educacaonanet.com.br/ipelog/artigos/indicadores_chave_de_performance_kpi_par te1.pdf >. Acesso em: 22/04/2011. SIGNAVIO. Disponvel em: < http://signavio.com/en.html >. Acesso em: 29/05/2011 SGANDERIA, Kelly. O que h de novo em BPMN 2.0 . iPelog. 2010. Disponvel em: < http://www.youtube.com/iprocessbpm#p/c/0/nPrh0HWVEyQ >. Acesso em: 6/05/2011. SORDI, Jos Osvaldo de; SPELTA, Andrea Giovanni. Anlise de componentes da tecnologia de Business Process Management System (BPMS) sob a perspectiva de um caso prtico. 2007. Disponvel em: < http://www.revistasusp.sibi.usp.br/scielo.php?pid=S180717752007000100005&script=sci_arttext >. Acesso em: 3/5/2011. TREGEAR, Roger et al. Estabelecendo o escritrio de processos. Elo Group. Rio de Janeiro. Disponvel em: < http://www.elo Group.com.br/download/Estabelecendo%20o%20Escrit%C3%B3rio%20de%2 0Processos.pdf >. Acesso em: 29/04/2011. ULTIMUS. BPM vs Workflow . Disponvel em: <http://www.bpmvsworkflow .com/>. Acesso em: 20/04/2011. VALLE, Rogerio; OLIVEIRA, Saulo Barbar. Anlise de Modelagem de Processos de Negcio Foco na notao BPMN. So Paulo: Atlas, 2010. VERNAY, Diogo. Gerenciamento de Incidentes ITIL. Disponvel em: < http://www.devmedia.com.br/post-7174-Gerenciamento-de-Incidentes-ITIL.html> Acesso em: 11/10/2011

158 WORTHINGTON, John. Gerando Lucros em Servios Financeiros por Meio de Motores de Regras de Negcios. 2008. Disponvel em: < http://www.serasaexperian.com.br/cursosinteresses/palestras/ftp/ftp_0100.pdf>. Acesso em: 02/04/2011.