Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Modelagem de Negócio A importância de entender o negócio antes de começar o desenvolvimento de projetos de software De que se trata o artigo? Nadja Rodrigues [email protected] Mestre em Administração de Empresas (UFPB). Especialista em Sistemas de Informação e Redes de Computadores (UFPB). Graduada em Ciência da Computação (UFPB). Trabalhou por 12 anos na indústria de TI, fazendo parte de empresas públicas como SERPRO e DATAPREV, Universidade (UFPB NTI), além de ter atuado em várias empresas da iniciativa privada, dentre elas, a Confederação das Unimeds do Norte-Nordeste. Na área acadêmica, lecionou em faculdades nos estados da Paraíba e Pernambuco, e na UFPB. Atualmente, é professora e pesquisadora no IFPB, desenvolvendo pesquisas na área de Engenharia de Software e coordenando atividades de Análise e Desenvolvimento de Software. Jorge Dias Jr. [email protected] www.jorgediasjr.com Doutorando em Ciência da Computação (UFPE). Mestre em Ciência da Computação (UFPE). Graduado em Ciência da Computação (UFPB). Desenvolve pesquisas na área de SOA desde 2005. Possui vários artigos publicados em conferências nacionais e internacionais. Tem experiência como analista de TI na indústria, onde desenvolveu sistemas no âmbito do governo federal, além de ter atuado em vários projetos da iniciativa privada. Atualmente, é professor em Engenharia de Software e coordenador do curso de Sistemas de Informação no Departamento de Ciências Exatas da UFPB. N os dias atuais, as Tecnologias de Informação e Comunicação vêm sendo utilizadas não apenas como ferramentas para automatização organizacional, através de sistemas de informação tradicionais. Com o surgimento de novos paradigmas e recursos, houve uma transferência de valores entre os instrumentos organizacionais, e a tecnologia passou a ser vista como elemento imprescindível para elaboração de estratégias e formação de inteligência de negócios. O resultado da percepção dessa constante evolução das tecnologias e do aumento de poder proporcionado por elas pode ser associado ao aumento no nível de exigência dos “clientes de tecnologia”, que cada vez mais esperam colher os frutos dos seus investimentos a partir do alinhamento entre tecnologia e planejamento estratégico. A capacidade de uma organização coletar dados, interpretá-los e agir com base neles, rapidamente, pode diferenciar vencedores de perdedores, em um mercado altamente competitivo. Antes de pensarmos no software que será desenvolvido, precisamos entender o domínio do negócio de que este software fará parte. Neste sentido, este artigo trata da importância de entender a estrutura e a dinâmica do negócio antes de começar o desenvolvimento de algum projeto de software, e discutirá algumas notações para se modelar os processos de negócio. Para que serVe? Mostrar a importância de entender o negócio da organização, suas necessidades e principais problemas atuais; buscar alternativas para minimizar ou resolver esses problemas e, de forma geral, otimizar os processos de negócio; documentar os processos de negócio para a elicitação de bons requisitos de software, atendendo ou superando as expectativas de seus stakeholders. Em que situação o tema é útil? Para pessoas da área de tecnologia da informação que trabalham no desenvolvimento de soluções de software para organizações, com o objetivo de atender as suas necessidades reais de negócio, potencializando o alinhamento entre a TI e os objetivos deste negócio. Edição 31 - Engenharia de Software Magazine 7 Com o intuito de tentar garantir o alinhamento entre tecnologia e estratégias organizacionais, os projetos de software devem conhecer o cenário organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou mesmo reengenharia nos processos de negócio, e entender que o sistema a ser implantado será apenas um dos recursos avaliados nesta análise de negócio, e não o único. Este artigo tem o objetivo de apresentar a importância da Modelagem de Negócio e alguns aspectos técnicos relacionados ao desenvolvimento das suas atividades. Além disso, motivar o seu uso em projetos de construção de software, buscando aproximar os seus resultados e as expectativas dos seus stakeholders. A importância da modelagem de negócios Há alguns anos, já se dizia que o mundo estava sendo construído a partir da combinação dos computadores e das telecomunicações, e que essa realidade deveria ser encarada como uma das maiores revoluções vividas pela humanidade. “A realidade está em constante evolução e o que ontem era ficção hoje é prática comum entre aqueles que buscam oferecer e utilizar serviços diferenciados e de valor agregado” [5]. A autora ainda diz que, nessa nova realidade, há uma transformação contínua nas instituições e no estilo de vida das pessoas. Ao longo da história da humanidade, grandes mudanças em padrões de comportamento, de processos, na forma de ver e de reconstruir o mundo, sempre foram vistas como revoluções, como redefinições da nossa própria existência. Faz-se importante entender os fenômenos, os eventos, que ocasionam essas transformações. O que motivou as empresas a verem nas Tecnologias de Informação e Comunicação (TIC) novas oportunidades de negócio? Desde quando os computadores e as redes deixaram de ser vistos como instrumentos de automatização, para se transformarem em elementos imprescindíveis nas estratégias para construção de inteligência de negócio? Pode-se dizer que houve uma mudança de paradigma com relação à percepção da aplicação das TIC no mundo dos negócios. A evolução da tecnologia, da rede mundial, do poder de armazenamento e processamento de dados, com consequentes melhorias significativas na geração de informações e na construção de conhecimento, são alguns dos fatores responsáveis pelas constantes redefinições nas vidas das pessoas e das organizações, e no mundo dos negócios. “O cenário competitivo obriga as empresas a pensarem em novas maneiras de gerenciamento, diante de um novo mundo, novas políticas, novas formas de relacionamento, novas organizações, nova Economia, globalizada” [5]. A autora explica que o apoio da TI e, mais especificamente, dos processos digitais e da inteligência em rede, são fundamentais para o sucesso dessas organizações. Você pode estar se perguntando: eu estou lendo um artigo sobre Modelagem de Negócios ou sobre Administração de Empresas? O fato é que os pesquisadores ou profissionais da Ciência da Computação precisam entender que esta área, de forma 8 Engenharia de Software Magazine - Modelagem de Negócio geral, não é vista como “área fim”, e sim como “área meio”, por construir produtos e oferecer serviços que serão utilizados, na sua grande maioria, por outras ciências e áreas. O fato é que os “clientes de tecnologia” não mais esperam simplesmente adquirir TIC com o objetivo de automatizar as suas rotinas organizacionais. Esses clientes, cada vez mais exigentes, acreditam que vão investir os seus recursos em ativos que agregarão valor ao seu negócio, alinhando tecnologia a estratégias organizacionais. Façamos agora uma reflexão: os clientes conhecem o negócio; os profissionais de TIC dominam os recursos tecnológicos; mas quem é o responsável por garantir a aplicação eficiente e eficaz dos recursos tecnológicos no negócio? Nesse contexto, espera-se que essa atividade seja desempenhada por alguém que conheça ambos os aspectos, que exerça o papel de Analista de Negócio. Você conhece seu projeto? Trabalhar na área de Análise e Desenvolvimento de Sistemas não é sinônimo de atividade fácil. Esse fato por vezes se deve ao desconhecimento da natureza da própria área, não só por parte dos leigos, mas muitas vezes, dos próprios profissionais que nela atuam. Todo analista/desenvolvedor de sistemas já foi, pelo menos uma vez na vida, confundido com profissionais que fazem montagem e manutenção de micros, consertam impressoras, trocam peças de hardware, instalam aplicativos, configuram sistemas operacionais e finalmente, removem indesejados hóspedes de computadores, como os vírus. E se um dia esse analista/desenvolvedor disse que não sabia fazer alguma dessas atividades na frente de um leigo, ele provavelmente ouviu a “célebre” frase: “Que absurdo! Você estudou para fazer o quê, então?”. Agora, vamos inverter os papéis, e trazer para os analistas/ desenvolvedores de sistemas o desafio de conhecer as demais áreas: • Odontologia: você saberia dizer agora o que é um Odontograma? • Direito: você saberia dizer que seções constam em uma Petição? • Engenharia: você saberia dizer que variáveis influenciam o projeto de uma Ponte? Acreditamos que não saber responder perguntas de uma área específica é um cenário natural, para as pessoas que não conhecem a área. Isso se deve ao fato de que só podemos dominar o conhecimento gerado a partir dos dados e das informações que recebemos, armazenamos, processamos e, consequentemente, podemos utilizar. A ideia das perguntas é chegar à simples conclusão de que só conhecemos o que investigamos. Uma vez que, em geral, construímos produtos para outras áreas, e oferecemos serviços para clientes que não são analistas de sistemas, devemos entender que temos que ter a preocupação de trabalhar, em vários momentos, investigando cenários desconhecidos, e utilizando REQUISITOS uma lupa para enxergar detalhes que possam contribuir com o nosso trabalho. Embora essas atividades sejam inerentes ao dia-a-dia dos detetives, elas também são executadas como parte da análise e do desenvolvimento de sistemas. Ao longo da existência dos profissionais que trabalham na construção de sistemas, os seus desafios sempre foram encontrar problemas que pudessem ser amenizados ou resolvidos com o uso de aplicações específicas para suas áreas, ou cenários que pudessem ser otimizados e melhor monitorados, de forma análoga, através do uso desse tipo de aplicação. O fato é que, no cenário atual, conforme explicado anteriormente, a satisfação do cliente não reside mais na informatização dos seus escritórios, lojas, ou demais tipos de estabelecimentos comerciais. Este cliente espera que o investimento dos seus recursos seja feito de forma alinhada às suas estratégias de negócio. Traduzindo o que foi colocado, para que essas expectativas sejam atendidas, é imprescindível que o Analista de Negócio mergulhe no dia-a-dia do cliente, com o propósito de conhecer o cenário de negócio em um nível suficiente, a ponto de avaliar e, se preciso for, sugerir melhorias, ou mesmo reengenharia nos processos organizacionais. Neste cenário, o sistema a ser implantado será um dos recursos avaliados nesta Análise de Negócio, mas, certamente, não será o único. Na Análise de Negócio, ter um checklist com perguntas pode servir como elemento norteador e medir o nível de conhecimento sobre o projeto a ser desenvolvido, além de que poderá ajudar bastante na execução das atividades, especialmente para iniciantes. Assim sendo, seguem algumas sugestões de perguntas que o Analista de Negócio deverá responder, para medir o conhecimento adquirido sobre o projeto: • O que é o seu projeto? • A que área de negócio ele se refere? • Como essa área “funciona”? Quais são as suas características? • Quais são os processos de negócio da área? Que atividades compõem esses processos? Como as atividades são executadas? Quem executa as atividades? Quando as atividades são executadas? • Quais são os pontos fortes dos processos? Quais são os pontos fracos? • Que mudanças beneficiariam os processos? • Já existe alguma aplicação semelhante ao projeto no cliente? • Caso exista, quais são os seus pontos fortes? Quais são os seus pontos fracos? • O que o cliente espera do sistema que será resultado do projeto? • Existem aplicações legadas que devam ser integradas a esse sistema? • Quem serão os “usuários” desse sistema? • Que características esse sistema terá? às expectativas dos clientes, ou seja, sobre a necessidade de alinhar TIC às estratégias de negócio. Neste cenário, façamos o seguinte questionamento: como poderemos gerar produtos e serviços para clientes, se não conhecemos o seu negócio, o seu dia-a-dia, as suas rotinas, as suas necessidades? A resposta é simples e objetiva: se não conhecemos o negócio do nosso cliente, poderemos até aplicar tecnologia e construir aplicações para sua organização, mas correremos o risco de não atendermos às suas expectativas, de não agregarmos valor nenhum ao seu negócio. Antes de começarmos projetos, devemos lembrar que os Sistemas de Informação (SI) gerados a partir desses projetos serão utilizados por diversos tipos de pessoas, em diversos tipos de cenários. Cabe aos analistas/desenvolvedores, o desafio de construir sistemas que se encaixem de forma intuitiva e natural, nos cenários em que vierem a ser usados, além de agregarem valor ao dia-a-dia dos seus usuários. Neste contexto, antes de pensarmos no software que será desenvolvido, precisamos entender o domínio do negócio de que este software fará parte e, o mais importante, construir uma visão crítica sobre o mesmo. Através dessa visão crítica, poderemos encontrar a melhor maneira de aplicar a tecnologia, de acordo com as necessidades impostas pelo domínio e expectativas do cliente. Conforme mostra a Figura 1, várias alternativas de projetos podem ser consideradas, em cada caso. A Engenharia de Software, área da engenharia que estuda os métodos, ferramentas e procedimentos utilizados na produção de software, sugere a sistematização das atividades ligadas ao entendimento e avaliação dos domínios das aplicações de software, através das definições da área de Modelagem de Negócio. Os métodos trazem os detalhes de como fazer para construir o software, incluindo atividades como planejamento, estimativas de projeto, além das atividades de análise e desenvolvimento; as ferramentas, por sua vez, dão apoio aos métodos, automatizando as atividades; os procedimentos, por último, representam o elo entre os métodos e as ferramentas, definindo, por exemplo, a sequência em que os métodos serão aplicados e os produtos que serão entregues. A Modelagem de Negócio pode ser vista como uma disciplina que envolve um conjunto de conceitos, modelos e técnicas com o objetivo de desenvolver o modelo de negócio de uma organização. Para isso, a Modelagem de Negócios vai se basear nos processos de negócio da organização. Sommerville (2007) define esses processos como sendo processos usados O que é modelagem de negócio Ao longo de todo o texto, vimos falando sobre a importância de aplicar tecnologia e construir aplicações voltadas Figura 1. Alternativas de alinhamento entre Tecnologia e Estratégias Organizacionais Edição 31 - Engenharia de Software Magazine 9 para atingir algum objetivo de negócio. Podemos tornar essa definição mais clara se definirmos esses processos como sendo aqueles ligados à área fim da organização. O autor cita ainda alguns exemplos de processos de negócio, para alguns domínios específicos: • Domínio: Empresa de Seguros Processo de Negócio: Emissão de Apólice de Seguro; • Domínio: Empresa de Manufatura Processos de Negócio: Recebimento de Pedido de Produto; Manufatura do Produto. O resultado da modelagem de negócio são os modelos de negócio. Esses modelos refletem a representação de um conjunto de atividades – tanto internas (como planejamento), quanto externas (como tomada de ação) – que são executadas para transformar entradas em saídas, produzindo trabalho (produto/serviço) nas organizações, conforme exemplo da Figura 2. Avaliando a importância dos SI para as suas organizações, percebemos a sua relevância como requisito de competitividade, como elemento de diferenciação com relação a concorrentes. Um exemplo facilmente citado são os diferentes sistemas de venda na Internet. Cada um apresenta características próprias, embora o objetivo principal seja atrair clientes, realizar vendas, gerenciar as informações resultantes desses processos e fidelizar esses clientes, fazendo com que essas atividades se tornem cíclicas e constantes. Essa diferenciação deve espelhar de forma direta a forma como o processo será realizado na organização. Para que isso aconteça, devem ser envolvidos, nas atividades de modelagem de negócio, não só os especialistas nos processos de negócio, geralmente pessoas ligadas ao nível operacional da organização, mas também gerentes táticos (dos diversos setores, departamentos da organização) e a alta administração da organização. A importância do envolvimento de cada um desses atores na modelagem de negócio é justificada pelos seguintes argumentos: o nível operacional conhece profundamente os detalhes dos modelos de negócio da empresa, no escopo das atividades que desempenha rotineiramente; o nível tático Figura 2. Exemplo de Processo de Negócio - Vender Produtos 10 Engenharia de Software Magazine - Modelagem de Negócio conhece os elementos de gerência de uma área específica, e as suas interfaces com as demais áreas da organização; o nível estratégico (alta administração) tem a visão macro da organização, de todos os seus processos e o poder de tomar decisões sobre os aspectos relacionados e esses elementos. As atividades envolvidas na modelagem de negócios representam muito mais de que entender necessidades técnicas e automatizar os processos de negócio existentes, através de SI. A modelagem de negócio resulta em análises e reflexões sobre a natureza do negócio e a forma como ele é executado, ou seja, sobre as características do negócio e as rotinas organizacionais. Já entendemos que modelar o negócio de uma organização é uma atividade necessária para alinhar tecnologia e estratégias organizacionais. O que ainda precisa ser explicado é o fato de que essas atividades, para realmente surtirem o efeito desejado pela organização, não são realizadas de forma trivial (e justamente por isso devem ser executadas sob as sugestões de alguma metodologia específica para este fim) e requerem esforços consideráveis da equipe de projeto e das pessoas que fazem parte da organização. Essa colocação não tem por objetivo voltar atrás quanto ao que foi colocado anteriormente ou questionar a relevância dessas atividades para a construção de um produto de software, mas sim, introduzir algumas reflexões sobre os cenários ideais para seu uso. Kruchten (2003) diz claramente que não recomenda a modelagem de negócios para todos os esforços de engenharia de software. O autor sugere que os modelos de negócios parecem agregar mais valor quando há várias pessoas diretamente envolvidas na utilização do sistema e o volume de informações manipuladas pelo sistema é significativo. Sobre os cenários ideais para desenvolvimento das atividades de modelagem de negócios, este mesmo autor explica que se o projeto estivesse simplesmente adicionando um recurso ao software de um comutador de telecomunicação existente, a equipe não precisaria considerar a modelagem de negócios, porque não haveria a pretensão de mudar radicalmente o propósito do software. De forma resumida, pode-se dizer que, neste caso, não precisariam ser rediscutidos ou reavaliados os aspectos gerais de negócio. Pontualmente, seriam adicionadas funcionalidades a um software. O autor prossegue, justificando que, por outro lado, se o projeto estivesse relacionado à construção de um sistema de gestão de marcas novas, a fim de apoiar as vendas de soluções de rede de telecomunicações (uma aplicação para e-business), a modelagem de negócios seria muito valiosa para compreender como este novo sistema iria afetar a forma como o negócio seria conduzido. O autor considera que, no segundo cenário, os processos do domínio são complexos, porque o projeto que está sendo construído é uma solução sob medida, e não um produto de prateleira. REQUISITOS Deixamos a recomendação de que, de acordo com o tipo de projeto, seja feita uma análise da necessidade de modelagem de negócios, dos fatores favoráveis e desfavoráveis à sua aplicação e, principalmente, da real contribuição dos seus resultados para o desenvolvimento do projeto. Objetivos da modelagem de negócio A adoção das atividades de Modelagem Figura 3. Diagrama de Atividades de Negócio como parte dos processos de construção de software traz inúmeros benefícios às organina construção de um cenário organizacional mais eficiente zações. Além de sugerir a otimização das rotinas organizae eficaz. Em outras palavras, através dos resultados da Mocionais, a Modelagem de Negócio apóia a especificação do delagem de Negócio, esta equipe de projetos pode derivar os software que será produto do projeto, através da análise e requisitos de sistema essenciais para apoiar a organização. do entendimento do negócio. Podemos citar, como sendo os principais objetivos da MoNotações para modelar processos de negócio delagem de Negócio: Notação para modelagem de processos de negócio é uma linguagem gráfica ou textual para representar um conheci Entender o Negócio: Através das atividades de Modelagem mento ou domínio. Alguns requisitos para uma boa notação de Negócio, a equipe de projeto observa e analisa o dia-a-dia e os processos de negócio do cliente, entendendo a estrutura são a expressividade, a legibilidade, a precisão e ferramentas e a dinâmica da organização na qual um sistema deve ser para dar suporte a esta notação. Atualmente duas notações implantado; estão sendo bastante adotadas: UML e BPMN. Iremos discutir as duas nas próximas seções deste artigo. Entender os problemas atuais e identificar as possibilidades de melhoria: Através da imersão no dia-a-dia do cliente, e das UML investigações sobre os diversos aspectos relacionados às UML (Unified Modeling Language) é uma linguagem padrão atividades desempenhadas nos processos de negócio, é possível que a equipe de projeto entenda os problemas atuais para documentar projetos de software. Esta linguagem provê da organização. Observando as boas práticas relacionadas a um conjunto de diagramas para representar diferentes viprocessos da mesma natureza, conversando com especialistas sões do sistema a ser especificado. Alguns exemplos desses na área, ou mesmo com o próprio cliente (que supostamente diagramas são: diagrama de classes, diagrama de objetos, conhece o seu negócio), a equipe de projeto pode identifidiagrama de casos de uso, diagrama de interação, diagrama car as possibilidades de melhoria e sugerir que elas sejam de componentes e diagrama de atividades. executadas; Para modelar processos de negócio na UML, podemos utilizar o diagrama de atividades. Este diagrama tem o objetivo Assegurar o entendimento comum sobre a organização e o seu de destacar a lógica de realização de uma tarefa, mostrando negócio: Através do desenvolvimento do trabalho da Modeo fluxo entre atividades e a sequência dessas com suporte lagem de Negócio, que é realizado pela equipe de projeto, para comportamento condicional e paralelo. juntamente com as pessoas que pertencem à organização, é possível assegurar que os clientes, usuários e desenvolvedores Os elementos do diagrama de atividades são: tenham um entendimento comum da organização e dos seus • Atividades: representam tarefas ou sub-atividades de um processos de negócio; processo; • Transições: quando o fluxo de controle passa para outra Documentar os processos de negócio e capturar a relação entre atividade; os seus conceitos: Através da geração de artefatos técnicos da • Decisões: são caminhos alternativos no fluxo de controle Modelagem de Negócio, a equipe de projeto pode mapear, das atividades. Podem ser uma condição, uma bifurcação validar e documentar os processos de negócio. A construção (fork) ou uma união (join); desses artefatos leva ainda a equipe de projeto a capturar a relação entre os seus conceitos, gerando conhecimento para si • Barras de sincronização: utilizadas para sincronizar atividades de um processo; e, muitas vezes, para o próprio cliente, que passa a ter a visão detalhada de cada processo organizacional; • Raias: utilizadas para mostrar responsabilidades. Derivar os requisitos de sistema necessários para sustentar a orgaA Figura 3 mostra um exemplo de um diagrama de ativinização: Através do entendimento do negócio da organização e dades. Cada caixa do diagrama representa uma atividade, de aspectos referentes a esta como problemas, oportunidades as bolinhas representam início ou fim do processo, as linhas de negócio, possibilidades de diferenciação, requisitos para verticais representam o início de fluxos que serão executacompetitividade, a equipe de projeto pode entender como um sistema de informação pode influenciar positivamente dos em paralelo ou a junção destes fluxos, enquanto que o Edição 31 - Engenharia de Software Magazine 11 losango indica um desvio condicional na execução. Todos estes elementos podem ser opcionalmente agrupados em “raias”, que podem representar um departamento ou alguma outra entidade. Podemos perceber que a notação do diagrama de atividades é bastante simples. Neste sentido, fica a seguinte pergunta: será que esta notação é capaz de representar um processo de negócio complexo? Por exemplo, regras de negócio de um processo. Como representar isso em um diagrama de atividades? Devido à falta de elementos representativos, surgiram outras notações com a finalidade de modelar processos de negócio. Um exemplo é a notação BPMN (Business Process Modeling Notation) que vamos ver na seção a seguir. BPMN A notação BPMN foi idealizada em 2001 quando foi criado um grupo de trabalho com a finalidade de se criar uma notação capaz de representar de maneira expressiva os processos de negócio das organizações. Em maio de 2004, a versão 1.0 do BPMN foi lançada ao público. Figura 4. %VENTOS EM "0-. Figura 5. %XEMPLOS DE EVENTOS EM "0-. Figura 6. %XEMPLO DE UM PROCESSO MODELADO EM "0-. 12 Engenharia de Software Magazine - Modelagem de Negócio A especificação da notação da BPMN provê uma notação gráfica para expressar os processos de negócio em forma de diagrama de processo de negócio (BPD). O objetivo do BPMN é dar suporte ao gerenciamento de processo de negócio, tanto para os usuários técnicos quanto para os usuários de negócio, fornecendo uma notação intuitiva para os usuários, tornando-os capazes de representarem semânticas de processos complexos. A notação definida está agrupada nos seguintes grupos: • Objetos de fluxo: são os principais elementos gráficos para definir o comportamento do processo de negócio. Existem três tipos de objetos de fluxos: atividades, eventos e decisões; • Objetos de conexão: conectam objetos de fluxo. Podem ser: fluxo de sequencia, fluxo de mensagem e associação; • Swimlanes: servem para agrupar elementos do processo, normalmente associados a unidades organizacionais, departamentos ou grupos; • Artefatos: são usados para fornecer informações adicionais sobre o processo. Existem quatro artefatos padronizados, mas os fabricantes de software de modelagem estão livres para adicionar outros artefatos. Alguns exemplos são: objetos de dados, grupos e anotações. A Figura 4 mostra os elementos que representam eventos no BPMN. Perceba a quantidade de elementos para representar diferentes tipos de eventos, tais como: mensagem, cronômetro, exceção, compensação, regra, atalho, etc. Além disso, os eventos podem representar estados de início, intermediário ou final. A Figura 5 mostra dois exemplos de processos simples modelados utilizando BPMN. No primeiro exemplo, o processo se inicia quando um evento de mensagem é recebido, representando um recebimento de pedido de suporte. Então a atividade “Trata pedido de suporte” é executada. O processo fica aguardando até que outro evento de mensagem seja recebido (Aguarda uma resposta técnica interna). A partir deste evento, o registro de resposta é criado e um evento de mensagem (Envia solução) é enviado. Perceba como os três tipos de eventos do tipo mensagem foram utilizados no processo. O exemplo 2 segue a mesma ideia, porém é utilizado o evento do tipo cronômetro, no qual o processo se inicia todas as segundas-feiras às 10hs. O processo da Figura 6 inicia com um evento genérico, chamado evento inicial. Após o processamento do pedido, uma decisão sobre a forma de pagamento deve ser feita. Se a forma é cartão de crédito, a transação deve ser confirmada por outro participante: o banco. O banco é uma piscina (Pool) do tipo caixa preta; seus processos internos são desconhecidos. Após a forma de pagamento ter sido processada, o produto é despachado. O processo termina com um evento final. REQUISITOS Ferramentas Como foi dito anteriormente, um aspecto muito importante que deve ser considerado na escolha da notação é o suporte ferramental que esta possui. No caso das duas notações apresentadas, existem algumas ferramentas que as suportam. É natural que existam mais opções de ferramentas para criar diagrama de atividades, pois qualquer ferramenta para UML, naturalmente, possui a opção para criação de diagrama de atividades. Alguns bons exemplos de ferramentas gratuitas que suportam UML são a astah community e a StarUML. No caso de ferramentas para BPMN também temos opções. Alguns exemplos são: iLog, IntalioBPMS, BizAgi e BillFish. Conclusão Este artigo apresentou a importância de entender a estrutura organizacional e seus processos como fator crucial para se construir soluções de TI que estejam alinhadas às necessidades, aos objetivos e processos da organização. Além disso, foram apresentadas também duas notações para modelagem de processos de negócio, que é uma importante atividade para o entendimento do contexto do negócio. Em artigos futuros, iremos abordar de maneira mais técnica e prática como modelar o negócio e seus processos de maneira sistemática. Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.deVmedia.com.br/esmag/feedback Referências [InfoQ, 2009] Artigo da InfoQ. Como Alinhar Processos de TI e Governança SOA para suportar RODRIGUES, Nadja da N. Virtualização bancária: a experiência em João Pessoa – PB. 2002. 157 f. Iniciativas BPM? (2009) Disponível em http://www.infoq.com/br/news/2009/02/process-it-soa- Dissertação (Mestrado em Administração de Empresas) – Universidade Federal da Paraíba, João governance. Pessoa, 2002. KRUCHTEN, P. Introdução ao RUP: Rational Unified Process. Ciência Moderna, 2003. LAUDON, SOMMERVILLE, Ian.Engenharia de Software.Tradução de Selma Shin Shimizu Melnikoff, Reginaldo Kenneth C.; Sistemas de Informação Gerenciais. Tradução da 5. ed. São Paulo: Makron Books Arakaki, Edílson de Andrade Barbosa. Revisão técnica de Kechi Hirama. 8. ed. São Paulo: Pearson Editora,2003. Addison-Wesley, 2007. OMG Business Process Modeling Notation Specifications. Disponível em: http://www.bpmn.org/. STAIR, R. M.; REYNOLDS, G. W. Princípios de Sistemas de Informação. Tradução da 6.ed. São Paulo: Acessado em 05/11/2010. Thompson, 2006. PRESSMAM, Roger S. Engenharia de Software. Tradução de Rosangela Dellosso Penteado. Revisão técnica de Fernão Stella R. Germano, José Carlos Maldonado, Paulo Cesar Masiero. 6.ed. São Paulo: McGraw-Hill, 2006. Edição 31 - Engenharia de Software Magazine 13
