Henrique Prado Sousa. Integrando modelagem intencional à modelagem de processos. Dissertação de Mestrado

Transcrição

1 Henrique Prado Sousa Integrando modelagem intencional à modelagem de processos Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa de Pós- Graduação em Informática do Departamento de Informática da PUC-Rio. Orientador: Prof. Julio Cesar Sampaio do Prado Leite Rio de Janeiro fevereiro de 2012

2 Henrique Prado Sousa Integrando modelagem intencional à modelagem de processos Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa de Pós- Graduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Edward Hermann Haeusler Presidente Departamento de Informática PUC-Rio Prof. Julio Cesar Sampaio do Prado Leite Orientador Departamento de Informática PUC-Rio Prof.ª Cláudia Cappelli Departamento de Informática Unirio Prof. José Eugênio Leal Coordenador Setorial do Centro Técnico Científico PUC-Rio Rio de Janeiro, 17 de fevereiro de 2012

3 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Henrique Prado Sousa Graduou-se em Bacharelado em Sistemas de Informação na Universidade Federal do Estado do Rio de Janeiro (UNIRIO) em Desde 2006 participa do núcleo de pesquisa NP2Tec, da UNIRIO. Desde 2010 participa do grupo de engenharia de requisitos da PUC-Rio, coordenado pelo professor Julio Leite. Ficha Catalográfica Sousa, Henrique Prado Integrando modelagem intencional à modelagem de processos / Henrique Prado Sousa ; orientador: Julio Cesar Sampaio do Prado Leite v., 138 f,; Il. ; 30 cm 1. Dissertação (mestrado) Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Inclui referências bibliográfias 1. Informática Teses. 2. Engenharia de requisitos. 3. Modelagem de processos de negócio. 4. Modelagem de objetos. 5. BPM. 6. BPMN. 7. i*. 8. Integração de processos e objetivos. 9. Alinhamento de processos e objetivos. 10. KPI. 11. Indicadores. I. Leite, Julio Cesar Sampaio do Prado. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título. CDD: 004

4 Agradecimentos Não há como iniciar uma página de agradecimento contida em mais um trabalho de grande valor em minha vida, sem colocar em primeiro lugar Aquele que foi o único a me acompanhar integralmente passo a passo durante todas as minhas vidas. Sim! És tu! Meu Deus! Muito obrigado! Agora, é claro, agradeço aos meus pais todos os esforços empenhados unicamente ao meu crescimento pessoal, muito frequentemente, abdicando a si somente para doar a mim ainda mais carinho e dedicação. Espero estar correspondendo a todas as expectativas, de forma a recompensar justamente tudo o que me foi dado. Eternos agradecimentos! Em sequencia vem uma pessoa muitíssima especial para mim. Aquela que iniciou, propiciou e alavancou juntinho de mim toda essa vida de nerd alucinado que só começou depois de quase 20 anos de pura diversão. Ela que me motivou e ajudou em todos os momentos de puras tribulações durante o caminho de ascensão intelectual nos últimos 8 anos. À minha noiva linda, agradeço de coração! Agora sim, o momento mais esperado da página de agradecimentos! Fico impressionado com as pessoas que nascem com tal dom. Ensinar é uma atividade que até pode ser realizada por qualquer um, mas para executá-la em sua plenitude, é necessário muito mais do que conhecimento sobre uma disciplina, tem que ter o dom que engloba habilidades que vão desde o feeling de identificar apenas através da observação se o aluno está entendendo, passando por paciência, paciência e paciência, até a capacidade de ser carismático! São essas pessoas que me motivam todos os dias em minha vida, e mal sabem que são meus verdadeiros heróis que quero ser quando crescer! Aos meus eternos orientadores Julio Leite, Flávia Santoro e Leonardo Azevedo, MUITO OBRIGADOOO! O que também não poderia de forma alguma estar ausente aqui são os agradecimento aos amigos! Não adianta... Somente aqueles que estão no mesmo barco é que, na hora de fazer funcionar, giram a manivela com você. Seja para melhorar o seu artigo ou para chorar a nota de PAA, eles sempre estarão lá ao seu lado, motivando, agregando e dedicando à construção de um amigo cada vez melhor! Aos amigos André, Eduardo, Herbet, Leandro, Marx, e todo o grupo de Engenharia de Requisitos da PUC-Rio, broadcast de agradecimentos!!!

5 5 Resumo Sousa, Henrique Prado; Leite, Julio Cesar Sampaio do Prado. Integrando modelagem intencional à modelagem de processos. Pontifícia Universidade Católica do Rio de Janeiro, p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. A modelagem de processos de negócio é utilizada por empresas que desejam documentar detalhes do fluxo de execução de seus processos, resultando em um documento rico em detalhes sobre o negócio. Este artefato também é utilizado pela Engenharia de Software para elicitação de requisitos de sistema. A modelagem intencional possui foco na modelagem de objetivos - definidos como metas e metas flexíveis - e registra as estratégias que podem ser seguidas por um ator de forma a melhor atender suas necessidades, mapeando tarefas e recursos necessários, além disso, também aborda as dependências entre atores. É importante que os modelos de processos de negócio estejam alinhados aos objetivos da organização de forma a prover fonte de informações confiável que gere consequentemente requisitos alinhados ao negócio. Diversas ferramentas estão disponíveis no mercado com o objetivo de apoiar a modelagem dos processos de negócio e dos objetivos organizacionais, entretanto, percebe-se que as soluções disponíveis ainda são incompletas quando se fala na integração de modelos de processos com modelo de objetivos, e em formas de verificação do alinhamento entre processos e objetivos organizacionais a partir da modelagem. Apesar dos processos de negócio e objetivos serem intrinsecamente interdependentes na arquitetura organizacional, as linguagens de modelagem atuais não oferecem recursos suficientes para tratar processos e objetivos de forma alinhada, uma vez que existem deficiências na integração entre a camada de modelagem de objetivos e de processos. Assim, o uso do ferramental disponível que se apoia nessas linguagens e métodos dificulta sobremaneira a tarefa de identificar se os processos utilizados para gerar serviços e produtos, verdadeiramente atingem os objetivos da organização, bem como o impacto que as mudanças nos objetivos causariam nos processos de negócio. Neste trabalho integramos uma linguagem de

6 6 modelagem de objetivos a uma linguagem de processos de negócio e provemos os elementos e métodos necessários para ampliar a capacidade de análise do alinhamento dos processos de negócio às estratégias organizacionais. Palavras-chave Engenharia de requisitos, Modelagem de processos de negócio, Modelagem de objetivos, BPM, BPMN, i*, Integração de processos e objetivos, Alinhamento de processos e objetivos, KPI, indicadores.

7 7 Abstract Sousa, Henrique Prado; Leite, Julio Cesar Sampaio do Prado (Advisor). Integrating intentional modeling to business process modeling. Pontifícia Universidade Católica do Rio de Janeiro, p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro. The business processes modeling is used by companies which wish to document details of the execution flow of their processes, resulting in a document rich in details about the business. This artifact is also used by the Software Engineering to elicit system requirements. The intentional modeling is focused on objectives - defined as goals and softgoals - and registers the strategies that may be followed by an actor in order to better meet their needs and mapping tasks and resources, furthermore, it also addresses the dependencies between actors. It is important that business processes models are aligned to the organization s objectives in order to provide reliable information source that consequently generates requirements aligned to business. Several tools are available providing support to business processes and organizational objectives modeling, however, it s possible to realize that the available solutions are still incomplete when it comes to integration of process models and goals models and ways to check the alignment between organizational goals and processes using these models. Despite of business processes and goals are intrinsically interdependent in the organizational architecture, the current modeling languages generally treat process and goals separately, since there are deficiencies in the integration between the modeling layer of objectives and processes. Thus, the use of the available tools that supports these languages and methods greatly complicates the task of identify if the processes used to generate products and services truly achieve the organizational goals, as well as the impact of the changes in the goals would cause in business processes. In this work we integrated a goal modeling language to a business processes modeling language and provided the elements and methods required to expand the capacity of analysis of the alignment between the business processes and the organizational goals.

8 8 Keywords Requirements engineering, Business processes modeling, Objectives modeling, BPM, BPMN, i*, Integration of processes and goals, alignment of processes and goals, KPI, Indicators.

9 9 Sumário 1 Introdução Detalhamento do contexto Abordagem proposta Trabalhos relacionados Organização do documento Marco Teórico Introdução UML Extensões do diagrama de processo Extensões do diagrama de objetivos BPMN Processos privados Processos públicos Processos colaborativos Notação Framework i* Strategic Dependency (Modelo SD) Strategic Rationale (Modelo SR) URN (UCM e GRL) GRL UCM Rastreabilidade entre UCM e GRL Framework ARIS VAC Valued Added Chain EPC Event-driven Process Chain FAD Function Allocation Diagram Diagrama de objetivos... 54

10 Seleção de linguagens Domínio de processos de negócio Domínio de objetivos Arquitetura de Integração Similaridades entre as notações Adaptações necessárias Diagrama Integrado Análise do alinhamento através de KPIs Introdução Uso de indicadores no Diagrama Integrado Uso do Diagrama de Indicadores Implementação da Integração Ferramenta Oryx Estudo da ferramenta Aplicando a Engenharia Reversa Reengenharia de software Testes Exemplo de aplicação Modelo de processo Modelo SR Integração dos modelos Modelagem dos indicadores Análise e desenvolvimento de relatórios Conclusão Resumo Comparação com trabalhos relacionados Contribuições para Transparência do Processo Trabalhos futuros Referências bibliográficas

11 11 Lista de figuras Tabela 1 - Elementos de um diagrama de processo de negócio em UML Tabela 2 Elementos de um diagrama de objetivos em UML Tabela 3 Recursos e regras compõem todos os diagramas Tabela 4 Elementos básicos da BPMN Tabela 5 Elementos de um modelo SD Tabela 6 Elementos do modelo SR Tabela 7 Elementos do modelo GRL Tabela 8 Elementos do modelo UCM Tabela 9 Elementos de um diagrama de objetivos Tabela 10 Conexões permitidas entre os elementos do diagrama de objetivos Tabela 11 Comparação entre as linguagens de modelagem de processos Tabela 12 Comparação entre as linguagens de modelagem de objetivos Tabela 13 Similaridades entre elementos do i* e BPMN Tabela 14 Novos elementos incluídos ao Diagrama Integrado Tabela 15 Elementos do Diagrama de Indicadores Tabela 16 Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 Teste gráfico Tabela 18 Teste de regras do tipo Containment Rules Tabela 19 Teste de regras do tipo Cardinality Rules Tabela 20 - Teste de regras do tipo Connection Rules Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) Tabela 22 Teste gráfico para o elemento meta (Diagrama SD) Tabela 23 Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial108 Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento Dependency (Diagrama SD) Tabela 26 Detalhamento dos indicadores inseridos no Diagrama Integrado Tabela 27 Resumo de associação entre principais elementos Tabela 28 Tabela de descrição de indicadores Tabela 29 Tabela de descrição do recurso crítico Tabela 30 Detalhamento de recursos críticos não identificados no processo Tabela 31 Correlação entre recursos críticos e papéis responsáveis

12 12 Lista de tabelas Tabela 1 - Elementos de um diagrama de processo de negócio em UML Tabela 2 Elementos de um diagrama de objetivos em UML Tabela 3 Recursos e regras compõem todos os diagramas Tabela 4 Elementos básicos da BPMN Tabela 5 Elementos de um modelo SD Tabela 6 Elementos do modelo SR Tabela 7 Elementos do modelo GRL Tabela 8 Elementos do modelo UCM Tabela 9 Elementos de um diagrama de objetivos Tabela 10 Conexões permitidas entre os elementos do diagrama de objetivos Tabela 11 Comparação entre as linguagens de modelagem de processos Tabela 12 Comparação entre as linguagens de modelagem de objetivos Tabela 13 Similaridades entre elementos do i* e BPMN Tabela 14 Novos elementos incluídos ao Diagrama Integrado Tabela 15 Elementos do Diagrama de Indicadores Tabela 16 Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 Teste gráfico Tabela 18 Teste de regras do tipo Containment Rules Tabela 19 Teste de regras do tipo Cardinality Rules Tabela 20 - Teste de regras do tipo Connection Rules Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) Tabela 22 Teste gráfico para o elemento meta (Diagrama SD) Tabela 23 Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial108 Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento Dependency (Diagrama SD) Tabela 26 Detalhamento dos indicadores inseridos no Diagrama Integrado Tabela 27 Resumo de associação entre principais elementos Tabela 28 Tabela de descrição de indicadores Tabela 29 Tabela de descrição do recurso crítico Tabela 30 Detalhamento de recursos críticos não identificados no processo Tabela 31 Correlação entre recursos críticos e papéis responsáveis

13 13 1 Introdução Os modelos de processos de negócio são normalmente desenvolvidos para uso na Reengenharia de Processos de Negócio (RPN) com o objetivo de alcançar melhorias e reduzir custos [Paim02]. Entretanto, a modelagem de processos de negócio também possui importância na Engenharia de Software. Uma vez que os modelos de processos de negócio registram um conjunto de elementos que representam fluxos de consumo e produção de artefatos e informações, atividades, requisitos, regras de negócio, sistemas de apoio e diversos outros elementos pertinentes à execução de seus processos, é possível, por exemplo, realizar análises e criar um mapeamento entre o modelo e uma arquitetura de software [Villarroel06], [Marquioni05], [Soeli95] (Figura 1). Figura 1 Relacionamento de processos de negócio e arquitetura de componentes [Adaptação [Junior03 apud Villarroel06]] Outro exemplo de aplicação de modelos de processos de negócio é na identificação de serviços (considere também serviços como requisitos de software) [Azevedo09] [Sousa10], [Josuttis07] (Figura 2).

14 14 Figura 2 Relacionamento de processos de negócios e funcionalidades de software [Diirr11] Além disso, os modelos de processos de negócio podem servir como insumo para estudo do domínio na fase de elicitação de requisitos, bem como um modelo gráfico que facilita a comunicação com o cliente. A Modelagem de Processos de Negócio auxilia tanto a equipe de desenvolvimento quanto ao cliente a descobrirem o que ele quer e evidenciar o óbvio (minimizam surpresas) [Villarroel06]. Sob a ótica do cliente, a realização deste mapeamento permite que ele visualize melhor a amplitude do seu negócio e consequentemente dimensione com mais precisão quais processos podem ser informatizados (a partir da identificação de gargalos, focos de retrabalho e outras possibilidades de melhoria). Sob a ótica da equipe de desenvolvimento, o mapeamento permite identificar ambiguidades no discurso do usuário durante o elicitação, evidenciar o óbvio, além de permitir relação direta com a lista de requisitos a ser confeccionada [Villarroel06].

15 15 Trata-se então, de uma prática interessante de determinação de prioridades a desenvolver, além de que, em se tratando de representação gráfica, o cliente poderá criticar o que for omitido ainda em tempo de elicitação, e não apenas quando ele tiver à disposição algo mais concreto, como uma tela já funcional. No mínimo isto irá reduzir significativamente o retrabalho da equipe de desenvolvimento em produtos já construídos [Villarroel06]. Os modelos de processos de negócio têm tipicamente um alcance maior em detalhes, sendo mais inclusivos que um sistema de software, possibilitando assim, que o engenheiro de requisitos defina claramente o que está no âmbito do sistema proposto e o que será implementado em outra oportunidade. Também, associado ao custo-benefício, pode prover a justificativa para construir um novo sistema baseado no modelo atual. Qualquer que seja a técnica utilizada para elicitação de requisitos, tão importante quanto a elicitação em si, é realizar a sua formalização. Sistematizações diretamente em linguagem natural (mesmo que em uma lista de requisitos) podem omitir informações importantes que não ficam visíveis em função da ausência de estruturação dos requisitos. Os métodos que sustentam o levantamento de processos (por exemplo, RUP e ICONIX) constituem aliados importantes para a equipe de desenvolvimento, pois geram mais estabilidade e visibilidade dos requisitos a serem implementados [Marquioni05]. Portanto, ao utilizar esse artefato para derivar serviços, é possível alcançar maior alinhamento da TI com o negócio [JOSUTTIS, 2007], uma vez que ele provê fonte de informação consideravelmente mais segura quanto aos problemas tradicionais de comunicação e interpretação entre o engenheiro de requisitos e o cliente. Entretanto, existe outro ponto de vista que deve ser considerado. Os processos de negócio são projetados para atingir os objetivos do negócio, porém, um modelo de processo de negócio, mesmo bem feito, pode gerar um sistema de informação desalinhado caso o processo de negócio esteja desalinhado aos objetivos do negócio [Cardoso11]. O sistema herda de seus requisitos, que são extraídos de um processo de negócio, o desalinhamento existente entre os processos e os objetivos do negócio. Isso indica que é um fator fundamental o desenvolvimento de métodos, linguagens e ferramentas que permitam a análise do alinhamento dos processos de negócio em relação aos seus objetivos. Diversos trabalhos são desenvolvidos nesta linha, no entanto, é um consenso que o tema alinhamento de processos e objetivos não é simples e gera diferentes conceitos e visões acerca de seus elementos [Kefi&Kalika05], [Singh&Woo09], [Cardoso11].

16 16 A complexidade do domínio, bem como a sua importância, justifica a continuidade de estudos na área Detalhamento do contexto No contexto das organizações, a competitividade acirra-se em função de mudanças em políticas, padrões e novas necessidades dos consumidores. Somem-se a isso as recentes crises financeiras que obrigam às organizações responderem rapidamente às dificuldades e oportunidades que surgem nesses momentos. Isso demanda uma evolução dos processos empresariais porque as organizações agregam e/ou alteram seus objetivos estratégicos para corresponder às mudanças. Esse relacionamento direto entre objetivos e processos organizacionais é crítico, uma vez que só a partir disto é possível medir a eficiência e eficácia do negócio. Portanto as informações processo x objetivo são necessárias no ambiente organizacional e devem ser monitoradas frequentemente para que seja possível gerir o nível de atendimento da execução dos processos aos objetivos do negócio. No contexto tecnológico, os sistemas computacionais devem responder em tempo hábil às demandas dos novos requisitos que partem das alterações constantes nos processos organizacionais. Os engenheiros de software devem estar aptos a garantir o alinhamento da TI com o negócio e podem usufruir dos modelos de processos e objetivos como insumo para o entendimento do problema e planejamento correto das soluções. Diversas ferramentas estão disponíveis no mercado com o objetivo de apoiar a modelagem dos processos de negócio e dos objetivos organizacionais, entretanto, percebe-se que as soluções disponíveis ainda são incompletas quando se fala na integração de modelos de processos e modelo de objetivos [Behnam10], [Braubach 10], [Cardoso11], [Singh&Woo09]. Na arquitetura organizacional, processos de negócio e objetivos coexistem e se relacionam, porém, as linguagens de modelagem atuais são insuficientes em apresentar recursos que mantenham rastreabilidade e alinhamento entre os modelos. Por exemplo, alguns autores apontam a existência de ênfase dada à modelagem funcional [Chung&Leite09], isto é, centrada em como fazer/executar os processos (entre exemplos de diagrama com estas características podemos citar o workflow, diagramas de atividade e o diagrama EPC 1 ), sendo pouco frequente que qualidades 1 Neste trabalho a sigla EPC referencia ao diagrama Event-driven Process Chain e não à notação proprietária que utilizada na arquitetura ARIS (Architecture of Integrated Information Systems), conforme citam alguns trabalhos.

17 17 do processo, em função de distintas demandas gerenciais, estejam explicitamente modeladas. De maneira geral, os processos irão possuir atividades que implementam características de qualidade, mas sem explicitá-las. Ocorre que ao centrar na funcionalidade existe a possibilidade de que o modelo de processos deixe de considerar algumas características de qualidade que deveriam estar presentes. Isso, como já apontado na literatura por [Kueng&Kawalek97], [Soffer&Wand05], [Cappelli10], é um problema com graves consequências. Um dos motivos para que isso ocorra, é o maior enfoque no desenvolvimento de soluções que representam o contexto prático dos processos, oferecendo maior detalhamento ao nível de atividades (operacional), o que não ocorre nos modelos de objetivos. De certa forma, os usuários das linguagens de modelagem são induzidos a dar maior importância na modelagem de baixo nível, o que também pode ser interpretado como herança da visão de workflow ou, ainda, de diagramas de atividades da UML [OMG11b]. Assim, o uso do recurso de modelagem nas ferramentas disponíveis dificulta sobremaneira a tarefa de identificar se os processos utilizados para gerar serviços e produtos, verdadeiramente atingem os objetivos da organização, nem o impacto que as mudanças nos objetivos causariam nos processos de negócio [Cardoso11]. Outro efeito colateral possível é a separação da modelagem de processos e da modelagem de objetivos em relação às equipes de levantamento de informações e modelagem. Na atribuição da modelagem dos processos, encontrase uma equipe modelando os processos dos diferentes departamentos, tendo como fontes de informação os funcionários que geralmente possuem uma visão estritamente prática de suas atividades, enquanto na modelagem de objetivos, encontra-se o alto escalão da organização, definindo com a visão gerencial os objetivos organizacionais. Nesta situação o problema ocorre porque o modelo de objetivos e o modelo de processos são feitos separadamente, e as fontes de informação do nível operacional não compartilham a mesma visão das fontes de informação do nível gerencial. Além disso, os processos podem ser modelados por grupos distintos, facilitando a inserção de diferentes detalhes no produto final de modelagem por motivos de ausência de padrão rigoroso Abordagem proposta O objetivo deste trabalho é integrar uma linguagem de modelagem de objetivos a uma linguagem de modelagem de processos de negócio e prover os elementos e métodos necessários para oferecer maior capacidade de representação dos relacionamentos entre processos e seus objetivos, explicitar a rastreabilidade entre os

18 18 elementos envolvidos e contribuir positivamente com a transparência do processo, ampliando assim a capacidade de análise do alinhamento dos processos de negócio às estratégias organizacionais. Nossa proposta não considera o uso de métodos aliados a linguagens que, com apoio de softwares, inserem novas capacidades que compõem um produto ferramental (por exemplo, ferramentas que implementam BSC Balanced Scorecard [BSI12]), mas sim a capacidade das linguagens, notações e respectivos ambientes de modelagem em expressar os elementos do domínio de objetivos, processos e suas correlações. Desta forma, busca-se reduzir o distanciamento encontrado atualmente entre modelos de objetivos e processos. Ainda propomos um método de uso de indicadores relacionados a elementos do processo como forma de medir sua capacidade em alcançar seus objetivos. Nossas propostas visam principalmente contribuir na questão da análise do alinhamento entre processos e seus objetivos, o que engloba a verificação da capacidade dos processos em satisfazer seus objetivos, a facilitação na identificação de impactos resultantes de alterações nos objetivos estratégicos, e a melhoria dos processos de forma a tornarem-se mais eficientes. Neste estudo, foram avaliadas as principais linguagens para modelagem de objetivos e processos de negócio em relação à sua capacidade de integração entre os modelos de objetivos e modelos de processos (apenas nas linguagens que oferecem ambos os recursos), além dos recursos gráficos disponíveis para representação dos elementos do negócio, como forma de identificar a linguagem mais adequada para a modelagem de processos e objetivos. Posteriormente, projetamos a integração destas linguagens também incluindo elementos que facilitassem a análise do alinhamento entre os modelos. As linguagens e os recursos de integração foram implementados a partir do reuso de código e customização da ferramenta Oryx [Daniel07], [Oryx12], [Peters07], [Tscheschner07]. A ferramenta Oryx é um framework acadêmico Open Source para modelagem gráfica de processos de negócio. Sua tecnologia é baseada em web, sendo executado através de browser, o que elimina a necessidade de instalação do software. Esta ferramenta foi desenvolvida originalmente com o objetivo de oferecer elementos BPMN para a modelagem de processos de negócio, no entanto, sua arquitetura foi desenvolvida separando o núcleo da aplicação e a interface, facilitando a programação de novos elementos e linguagens ao requisitar somente a manipulação da camada de interface. Para integrar as linguagens, foram desenvolvidas na ferramenta Oryx novas visões, relacionamentos e elementos para possibilitar a comunicação e alinhamento das notações, possibilitando a união das definições e semântica específica de cada

19 19 linguagem. As alterações necessárias para criar uma interface que permita o contato entre os elementos foram projetadas e implementadas na ferramenta, criando uma terceira linguagem que possibilita ao usuário usufruir da capacidade das linguagens em um único modelo Trabalhos relacionados Com o objetivo de integrar o framework ARIS e a linguagem de modelagem de objetivos Tropos, [Cardoso10] mapeia as relações semânticas entre os elementos similares das linguagens. Neste trabalho os autores apontam o problema de alinhamento interno de cada linguagem, que é o foco principal deste trabalho. Enquanto o ARIS é amplamente utilizado para modelagem de processo de negócios, apresenta uma linguagem pouco expressiva para objetivos. A linguagem Tropos, por sua vez, compreende conceitos e técnicas que permitem a captura e análise de objetivos, mas não aborda modelagem de processo de negócios de forma detalhada. Os autores ainda consideram os diferentes enfoques na arquitetura organizacional, e utilizam uma abordagem ontológica (UFO - Unified Foundational Ontology) para mapear as duas linguagens a partir da interpretação dos seus conceitos. Em [Cardoso11] são propostas taxonomias para modelos de objetivos de negócio com o propósito de harmonizar as diferenças no domínio dos objetivos e dos processos como forma de facilitar o alinhamento posterior dos modelos. Os autores defendem a dificuldade de se alinhar objetivos a processos de negócio e relevam que os objetivos são desenvolvidos em vários níveis de abstração e precisão, podendo referenciar vários aspectos da organização e seus processos. A taxonomia proposta equaliza o domínio de objetivos, os conceitos envolvidos em cada categoria da taxonomia e as implicações na estrutura dos processos de negócio que apoiam esses objetivos. O trabalho [Shamsaei10] destaca a necessidade de garantir o alinhamento dos processos a regras internas e externas que devem ser obrigatoriamente obedecidas e propõe um método que permite avaliar o nível de alinhamento/discordância dos processos de negócio em relação a essas regras. O método utiliza a extensão da notação URN para o uso de KPIs (Key Performance Indicator) com o objetivo de medir o alinhamento, sendo composto por quatro passos que parte da modelagem, passando pela análise e melhoramento dos modelos e finalizando em seu monitoramento, baseado nos KPIs. Os elementos utilizados pelo método são os objetivos organizacionais, processos de negócio e regras, e o seu produto é o nível do alinhamento dos processos e a identificação dos processos que necessitam de

20 20 melhoramento. Links de rastreamento são estabelecidos entre os modelos organizacionais e de regulamentações, incluindo pesos de importância relativa nos relacionamentos entre os elementos Organização do documento No Capítulo 2 são revistas e resumidas as características das linguagens para modelagem de processos e modelagem de objetivos estudadas neste trabalho. Esta revisão visa demonstrar a pontos positivos e negativos de cada linguagem e justificar a escolha das linguagens que foram integradas. No Capítulo 3 é apresentada a arquitetura de integração das linguagens de objetivo e processo, e a proposta de um método para análise do alinhamento entre os modelos de objetivo e processo a partir do uso de indicadores. No Capítulo 4 é detalhado como foi realizada a implementação da proposta de integração na ferramenta Oryx. No Capítulo 5 é apresentado um exemplo da aplicação do alinhamento dos modelos e análise a partir dos indicadores. No Capítulo 6 são feitas comparações com os trabalhos relacionados, contribuições, apresentação das conclusões e trabalhos futuros.

21 21 2 Marco Teórico Este capítulo apresenta análises sobre as principais linguagens de modelagem de processos e objetivos da atualidade e demonstra as comparações e características consideradas na seleção para posterior integração Introdução Diversas linguagens estão disponíveis para a modelagem de processos de negócio e para a modelagem de objetivos, no entanto, a maioria das linguagens é específica dentro de seu contexto de aplicação, não apresentando meios de relacionar seus elementos. [List&Korherr06] lista um conjunto de linguagens de modelagem de processos de negócio e apresenta uma comparação de suas características. Conforme demonstra a Figura 3, nenhuma das linguagens de modelagem de processo abordada apresenta relações com a modelagem de objetivos. Essa característica expõe uma possível tendência do mercado no desenvolvimento de soluções com enfoque na modelagem da visão operacional, sem destaque ao relacionamento dos processos e objetivos organizacionais, em uma visão estratégica. Figura 3 Avaliação da perspectiva no contexto de processos de negócio [List&Korherr06] Ainda em uma tabela semelhante, [Pourshahid09] apresenta uma comparação de um conjunto de notações para modelagem de processos e objetivos (Figura 4 - apresenta três sinais representando três níveis, sendo o sinal de visto representando

22 22 disponível, o sinal x representando indisponível, e o sinal +/- representando um estado intermediário, incompleto ). O trabalho demonstra a ausência de rastreabilidade entre processos e objetivos na grande maioria das linguagens. Esse é um forte indício da ausência do alinhamento entre os modelos nas principais linguagens utilizadas. Além disso, a tabela corrobora com o trabalho de [List&Korherr06] em relação a tendência de desenvolvimento de ferramentas com foco na modelagem da visão operacional. Também expõem, partindo do ponto de vista das linguagens de modelagem de objetivos, que existem deficiências quando analisa a capacidade da linguagem em modelar processos. Figura 4 Comparação de notações e características de modelagem de processos [Pourshahid09] Neste trabalho integramos apenas duas linguagens, sendo uma voltada para a modelagem de processos e outra para a modelagem de objetivos. O principal objetivo é cobrir as lacunas existentes em outras linguagens, mantendo a rastreabilidade entre os elementos nos diversos níveis e possibilitando a análise do processo em relação aos seus objetivos através do uso de indicadores, o que consequentemente permitirá a avaliação do alinhamento entre os modelos. Segundo [Pourshahid09], para apoiar o alinhamento de processos de negócio com objetivos de negócio, a notação de modelagem deve oferecer a modelagem de processo, modelagem de objetivo, rastreabilidade entre os modelos de objetivo e processo, e mecanismos de avaliação do modelo de objetivos. Caso contrário, não seria capaz de demonstrar o impacto dos processos de metas organizacionais. Além disso, papéis coadjuvantes (ou atores / organizações), atividades (ou funções) e eventos irão aumentar a capacidade de modelagem de processos de negócios, e enriquecer o significado das relações entre processos de negócio e objetivos. Em uma análise preliminar, identificamos a partir da tabela de [Pourshahid09] (Figura 4) a ausência da modelagem de objetivos na maioria das linguagens de modelagem de processo apresentadas, sendo ainda possível verificar que o inverso também é verdade, ou seja, as linguagens de modelagem de objetivo não oferecem

23 23 recursos para modelagem de processo ou não oferecem a rastreabilidade entre os modelos (exceto pela linguagem URN, conforme os autores apontam). No entanto, na arquitetura organizacional, processos de negócio e objetivos são intrinsecamente interdependentes, apesar das linguagens de modelagem atuais apresentarem deficiências no alinhamento entre processos e objetivos. Além do problema de alinhamento entre os modelos, observa-se grande ênfase no desenvolvimento de linguagens que ofereçam suporte para a modelagem da visão operacional, uma vez que são poucas as linguagens de modelagem de objetivos em comparação com as linguagens de modelagem de processos. É possível que este fato seja resultado da antiga visão de workflow [WMC95], aplicada de forma tradicional ao longo dos anos, ou ainda, pelo excessivo número de ferramentas que, por muito tempo, ofereceram (e algumas ainda oferecem) somente a modelagem de processos, por exemplo, Arpo BPMN ++, Oryx, Bizagi, Intalio BPMS, Signavio, Microsoft Visio, Visual Architect e ARIS [Arpo12], [Oryx12], [Bizagi12], [Intalio12], [Signavio12], [Visio12], [VisualArchitect12], [ARIS12]. Assim, o uso do ferramental disponível também dificulta sobremaneira a tarefa de identificar se os processos utilizados para gerar serviços e produtos, verdadeiramente atingem os objetivos da organização, bem como o impacto que as mudanças nos objetivos causariam nos processos de negócio [Cardoso10], [Cardoso11]. Para identificar as melhores características das linguagens e aplicar o reuso de seus elementos para o desenvolvimento de uma nova linguagem integrada, as seguintes linguagens foram analisadas: UCM e GRL (que compõem a URN), EPC e a modelagem de objetivos do framework ARIS, UML, BPMN, i* e NFR. As próximas subseções apresentam cada uma das linguagens e ao final a conclusão UML A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de Orientação a Objetos [Guedes07]. É um padrão adotado pela OMG utilizado internacionalmente no contexto da engenharia de software e atualmente encontra-se na versão 2.0 [OMG11a]. Esta versão é composta por 13 tipos de diagramas [Melo04] e tem como objetivo fornecer múltiplas visões do sistema a ser modelado, permitindo a análise e a modelagem considerando diversos aspectos, de forma a atingir a completitude da modelagem e permitindo que cada diagrama complemente os outros. Alguns diagramas abordam o sistema de forma mais geral, apresentando uma visão externa,

24 24 como é o objetivo do Diagrama de Casos de Uso, ao passo que outros oferecem uma visão de uma camada mais profunda do software, apresentando um enfoque mais técnico ou ainda visualizando apenas uma característica específica do sistema ou um determinado processo [Gudes07]. No entanto, o metamodelo da UML não contempla elementos específicos para tratar com diagramas de processos de negócio [Villarroel06], [Mili03]. Os usuários da UML utilizam o diagrama que mais se aproxima a este propósito que é o diagrama de atividades [Pourshahid09]. O Diagrama de Atividade se preocupa em descrever os passos a serem percorridos para a conclusão de uma atividade específica, muitas vezes representada por um método com certo grau de complexidade, podendo, no entanto, modelar um processo completo [Guedes07]. Apesar disso, muitos estudiosos concordam que existe a falta de vocabulários para expressar processos de negócio de uma forma intuitiva e natural na UML [Mili03]. Sabe-se que os diagramas de atividade oferecem a modelagem de fluxo de sequência, papéis, atividades, eventos e hierarquias de processos, mas não oferecem modelagem de objetivos e rastreabilidade entre os modelos de objetivos e modelos de processos [List&Korherr06]. Além disso, certos conceitos frequentemente usados na modelagem de processos não fazem parte do padrão UML [Eriksson&Penker00]. Para atender à demanda de modelagem de processos de negócio com uma solução mais abrangente, os mecanismos de extensão da própria UML definidos pela OMG foram utilizados (também conhecido como built-in extensions) [Villarroel06], [Eriksson&Penker00]. [Eriksson&Penker00] propuseram um conjunto de extensões que, agregados ao padrão UML, permitem a modelagem de processos de negócio. Estas extensões não alteram o padrão UML criando uma nova linguagem, mas ampliam a sua expressividade a partir de mecanismos naturais previstos na UML. Entre os diversos diagramas e elementos propostos por [Eriksson&Penker00] (Vision Statement diagram, Conceptual model, Goal model, Process diagram, Assembly Line diagram, Use-Case diagram, Resource model, Organization model, Information model, Statechart diagram, Interaction diagrams e System Topology diagram), neste trabalho apenas apresentaremos os diagramas de processos (Process diagram) e de objetivos (Goal model), e os mecanismos de interação entre eles. Esses diagramas são apresentados a seguir, incluindo exemplos.

25 Extensões do diagrama de processo O diagrama de processo proposto por [Eriksson&Penker00] é baseado no diagrama de atividades da UML, somado a um conjunto de estereótipos que descrevem a execução das atividades dentro de um processo, como elas interagem, os objetos de entrada e saída, os recursos de suprimento e controle que participam no processo, e o objetivo do processo. O processo é representado por um objeto de atividade com estereótipo de <<process>>, formado pelo ícone tradicional conforme descrito na Tabela 1 (além da regra de negócio, apresentada na Tabela 3, que está disponível em todos os diagramas). Um processo pode conter outros processos (subprocessos). A atividade é representada por um retângulo com os lados arredondados, e também é chamada na linguagem de processo atômico, ou seja, um processo que não pode ser decomposto. Todos os elementos que estão envolvidos com o processo são modelados ao seu redor. O objetivo ou problema alocado ao processo é modelado acima do diagrama de processo, relacionado através do link de dependência que contém o estereótipo <<achieve>>, partindo do processo para o objetivo. Os outros objetos são típicos da modelagem de processos de negócio e encontram-se detalhados na Tabela 1. Tabela 1 - Elementos de um diagrama de processo de negócio em UML Extensões de processo Nome Estereótipo Símbolo Definição/Descrição Processo Atividade (Processo atômico) Atividade Atividade Um processo é uma descrição de um conjunto de atividades relacionadas que, quando executadas corretamente, irão satisfazer um objetivo explícito. Um processo deve ser dividido em mais processos. Se estes processos são atômicos, eles são chamados de atividades. Inicio do processo Inicio Inicia um processo Fim do processo Fim Finaliza um processo Objeto-para- Assembly Line Objeto-vindo de- Assembly Line Objeto Objeto Um objeto entregue por um processo para a Assembly Line. Um objeto que vai da Assembly Line para um processo.

26 26 Fluxo de processo Fluxo de recurso Fluxo de recursos não-causal Controle de processo Conexão de objetivo Processo de suprimento Processo de decisão Processos de união e bifurcação Receber eventos de negócio Enviar eventos de negócio Assembly Line Fluxo de controle Fluxo de objeto Fluxo de objeto Fluxo de objeto Dependência Fluxo de objeto Decisão Um fluxo de controle de processo com uma condição Fluxo de objeto mostra que um objeto é produzido por um processo e consumido por outro. Fluxo de objeto nãocausal mostra que um objeto pode ser produzido por um processo e consumido por outro. Mostra que um processo é controlado por um objeto. Aloca um objetivo a um processo. Mostra que um processo é suprido por um objeto. Ponto de decisão entre dois ou mais processos. Bifurcação e União Bifurcação e união de processos. Recepção de sinal Mostra um recebimento de evento de negócio. Emissão de sinal Mostra um envio de evento de negócio. Pacote As Assembly Lines sincronizam e suprem os processos em termos de objetos. Objetivo quantitativo Objetivo qualitativo Objetivo Objetivo Um objetivo pode ser descrito com um valor alvo em uma unidade especifica de medida (a quantidade). Um objetivo normalmente descreve em linguagem natural. Um objetivo qualitativo envolve julgamento humano, no processo de determinar se ele foi cumprido. Instância de um objetivo qualitativo Objetivo qualitativo Ambos os objetivos qualitativos e quantitativos podem ser instanciados. Recurso Classe Recursos podem ser produzidos, consumidos, usados ou refinados por processos. Os recursos são também informação ou coisas que podem ser abstratas ou físicas.

27 27 Recurso abstrato Pessoa Classe Classe Um recurso abstrato é algo intangível, por exemplo, conceitos matemáticos. Um recurso físico que específica um ser humano. Recurso físico Evento de negócio Classe Sinal Um recurso físico que especifica documentos, máquinas (não humano). Uma ocorrência significante no tempo ou espaço. Um evento de negócio causa algum impacto ao negócio. A Figura 5 apresenta um exemplo de modelo de processo de negócio dividido em raias (swimlanes), que é um elemento padrão do diagrama de atividades. Cada raia demonstra as atividades executadas pelos respectivos responsáveis descrito no topo. As trocas de recursos (entradas e saídas) são explicitadas entre os processos. Figura 5 - Diagrama de processo de negócio em UML [Eriksson&Penker00] A Figura 6 apresenta um exemplo de modelo de processo de negócio mais simples, porém demonstra o relacionamento de um objetivo com o elemento processo.

28 28 Figura 6 Exemplo de objetivo relacionado ao processo [Eriksson&Penker00] Extensões do diagrama de objetivos O diagrama de objetivos proposto por [Eriksson&Penker00] reutiliza o diagrama de objetos da UML. Os objetivos podem ser representados em diferentes níveis, sendo cada nível, um diagrama de objetos. Os objetivos são descritos como classes de objetos com o estereótipo de <<goal>>. Os elementos que compõem o diagrama são: objetivos, relacionamento de dependência, associação entre objetivos e um elemento que representa os problemas os quais atuam negativamente sobre o objetivo (Tabela 2, além dos elementos da Tabela 3 que estão disponíveis para todos os diagramas). Tabela 2 Elementos de um diagrama de objetivos em UML Extensões de objetivo Nome Estereótipo Símbolo Definição/Descrição Objetivo Problema Classe Nota Denota os estados de desejo, o que significa que os objetivos motivam ações para alterar estados na direção desejada. Algo que impede o alcance do objetivo. Cauda, medida e prérequisito são outros estereótipos que são uteis quando se modela problemas. Uma causa leva aos problemas. Um problema pode ser resolvido se uma causa é removida.

29 29 Dependência de objetivo Objetivo contraditório Decomposição de objetivo incompleta Decomposição de objetivo completa Dependência Associação Dependência Dependência A causa pode ser removida se uma medida é alcançada e certos prérequisitos são validos. Objetivos são organizados em hierarquias de dependência nas quais um ou alguns objetivos são dependentes de subobjetivos. Objetivos podem ser contraditórios, mas devem ser cumpridas. Objetivos são organizados em hierarquias de dependência que algumas vezes são incompletas. Objetivos são organizados em hierarquias de dependência que algumas vezes são completas. Objetivo quantitativo Objetivo Um objetivo pode ser descrito com um valor alvo em uma unidade especifica de medida (a quantidade). Objetivo qualitativo Objetivo Um objetivo normalmente descreve em linguagem natural. Um objetivo qualitativo envolve julgamento humano, no processo de determinar se ele foi cumprido. Instância de um objetivo qualitativo Objetivo qualitativo Ambos os objetivos qualitativos e quantitativos podem ser instanciados. Existem duas classes de objetivos predefinidas no diagrama de objetivos: objetivo quantitativo e objetivo qualitativo. Um objetivo quantitativo pode ser medido através de valores específicos que são atingidos, um objetivo qualitativo depende do julgamento de quem avalia, tornando subjetiva a sua medição. O objetivo quantitativo é composto pelos seguintes atributos: descrição (goal description), valor esperado (goal value), valor atual (current value) e unidade de medida (unit of measurement). O objetivo qualitativo também possui o atributo descrição, porém seus outros atributos valor esperado, valor atual e unidade de medida devem ser interpretados pelo avaliador. Os autores definem esses atributos como instância de um objeto qualitativo. O relacionamento de dependência entre objetivos denota que um objetivo é subobjetivo de outro, ou que um depende do outro. O relacionamento de associação denota links entre objetivos, tais como contradições [Eriksson&Penker00].

30 30 Outro conceito apresentado é o de problema, que representa um obstáculo para a satisfação do objetivo. Identificar problemas pode levar ao descobrimento de novos objetivos que são satisfeitos com a eliminação desses problemas. A modelagem de problemas pode ser hierárquica, com a subdivisão em subproblemas. Os problemas são relacionados com os seus respectivos objetivos, mas podem ser eliminados pela inclusão de ações de solução. Um plano de ação pode ser projetado no modelo de objetivos como uma forma de resolver os problemas. Os objetivos, por sua vez, são relacionados aos processos de negócio. Os processos projetados no plano de ação devem ser posteriormente formalizados como processos e relacionados aos seus objetivos. A Figura 7 apresenta um exemplo de modelo de objetivo. O objetivo geral é ter muitos consumidores, e o valor desejado é de Este objetivo foi dividido em três subobjetivos que também descrevem as categorias dos consumidores (visitantes da internet desconhecidos, consumidores registrados e consumidores inscritos). Três problemas estão relacionados a cada um dos subobjetivos. Por exemplo, o problema relacionado ao objetivo de atrair mais visitantes na internet é que os usuários podem desconhecer o site. Para solucionar este problema, são gerados novos subobjetivos que almejam a publicação do site para o conhecimento dos usuários, por exemplo, Garantir que o site esteja visível nas máquinas de busca mais comuns. Figura 7 Diagrama de objetivos em UML [Eriksson&Penker00]

31 31 A Tabela 3 apresenta o elemento regra de negócio que se apresenta em todos os modelos. As regras são elementos especiais que definem restrições/condições ao negócio, e por serem importantes devem sempre ser ligadas aos elementos que são relacionados e/ou sofrem tais regras, por exemplo, objetivos e processos. Tabela 3 Recursos e regras compõem todos os diagramas Extensões de regras Nome Estereótipo Símbolo Definição/Descrição Regra de negócio Nota Regras restringem, derivam e estabelecem condições de existência. As regras de negócio são usadas para especificar estados de desejo, incluindo os estados alvos permitidos ao negócio. Esta seção apresentou a modelagem de processos de negócio e objetivos utilizando um built-in para a linguagem UML proposta por [Eriksson&Penker00]. A extensão apresentada utiliza modelos UML e objetos com novos estereótipos para representação de novos conceitos, o que permite a inclusão de novos elementos com menor esforço, a partir do reuso dos objetos e diagramas UML. Na próxima seção é apresentada a notação BPMN BPMN A BPMN (Business Process Model and Notation), versão 2.0, é um padrão desenvolvido pela OMG (Object Management Group) com o principal objetivo de oferecer uma notação que fosse legível e compreensível para os usuários do negócio [OMG11a]. A notação foi desenvolvida a partir do conhecimento e experiências dos membros da OMG que procuraram consolidar as melhores ideias para alcançar uma única notação padrão. Muitas metodologias e notações foram revistas durante o desenvolvimento da BPMN (por exemplo, UML Activity Diagram, UML EDOC Business Process, IDEF, ebcml BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM e Event-Process Chains (EPCs)) para que fosse desenvolvida uma especificação que representasse a combinação das melhores práticas da comunidade de modelagem de processos [OMG11a]. A intenção da BPMN é padronizar o modelo de processo de negócio e sua notação em face das diversas notações de modelagem e pontos de vista distintos. Outro fator padronizado no contexto da BPMN é a padronização de arquivos de

32 32 processo BPMN (extensão.bpmn), que permite a exportação e importação dos modelos para ferramentas de diferentes fabricantes. A BPMN suporta somente conceitos de modelagem que são aplicáveis a processos de negócio. Isso significa que outros tipos de modelagem realizados por organizações, mesmo com propósitos do negócio, estão fora de se escopo, por exemplo, modelagem organizacional, modelagem de dados, modelagem de objetivos/estratégia e modelagem de regras de negócio. A notação oferece uma variedade de recursos para o desenvolvimento de um modelo de processo de negócio e classifica os diagramas BPMN em três tipos básicos baseado na perspectiva na qual o processo é modelado: Processo de negócio privado não executável, Processo de negócio privado executável e Processo público. Ainda existem os diagramas de Colaboração, Coreografia e Conversação, sendo que esses dois últimos não são detalhados neste trabalho por não possuírem as características desejadas no detalhamento dos fluxos de execução de processos Processos privados Os Processos de negócio privados são processos internos a uma organização, antigamente chamados de workflow ou processos BPM. Existem dois tipos de processos privados: executável e não executável. Um processo executável é um processo que foi modelado com propósito de ser executado, utilizando em sua semântica processos, atividades, eventos, operadores lógicos, fluxos, loops e manipulação de dados. Um processo não executável é um processo que foi modelado com o propósito de documentar o comportamento do processo em um nível de detalhe de modelagem definido. Desta forma, a informação necessária para execução, tal como a condição formal das expressões são tipicamente excluídas em um processo não executável. A Figura 8 mostra um exemplo de um modelo de processo de negócio privado. Figura 8 Exemplo de modelo de processo de negócio privado [OMG11a].

33 Processos públicos Um processo de negócio público representa as interações entre um processo de negócio privado com outro processo ou participante (Figura 9). Somente o processo público torna-se visível, enquanto o processo privado é representado por uma raia vazia. Assim, o processo público mostra o lado de fora do mundo em que o fluxo de mensagens e o comando destas mensagens de fluxo são necessários para interagir com o processo. Figura 9 Exemplo de processo de negócio público [OMG11a] Processos colaborativos Uma colaboração ilustra as interações entre duas ou mais entidades do negócio. Uma colaboração normalmente contém duas ou mais pools, representando os participantes que interagem. A troca de mensagem é representada pelo fluxo que conecta as pools (ou os objetos dentro das pools ). As mensagens associadas ao fluxo de mensagens estão descritas no corpo das setas de fluxo de mensagem. A colaboração pode ser descrita como dois ou mais processos públicos se comunicando (Figura 10). Com um processo público, as atividades de colaboração dos participantes podem ser consideradas o ponto de toque entre os participantes. O correspondente interno no processo (executável) é suscetível a ter muito mais atividades e detalhes do que é mostrado nos processos públicos. Coreografias podem ser apresentadas "entre" as pools como se dividissem o fluxo de mensagem entre elas. Todas as combinações de pools, processos, e coreografia são permitidas em uma colaboração.

34 34 Figura 10 Exemplo de processo colaborativo Notação Os elementos gráficos utilizados nos diagramas BPMN foram desenvolvidos intencionalmente para facilitar o entendimento dos modelos e ao mesmo tempo ampliar a expressividade de complexidades inerentes aos processos de negócio. A abordagem adotada para lidar com esses dois requisitos conflitantes foi organizar aspectos gráficos da notação em categorias especificas, de forma que o usuário possa facilmente reconhecer os tipos básicos de elementos e compreender o diagrama. Dentro das categorias básicas dos elementos, podem ser adicionadas variações e informações para suportar novas necessidades, porém sem mudar dramaticamente o visual básico e percepção do diagrama. As cinco categorias básicas de elementos são: Fluxo de objetos; Dados, Objetos de conexão, Swimlanes e Artefatos. Os elementos básicos que se encaixam nesses grupos são descritos na Tabela 4. Ainda são oferecidos outros elementos (que são variações dos elementos básicos) para expressar casos específicos com maior nível de detalhe (não demonstrados aqui). Tabela 4 Elementos básicos da BPMN Nome Símbolo Definição/Descrição Evento Eventos são fatos que ocorrem durante a execução do processo. Pode ser classificado em evento inicial, intermediário e final. Atividade Operador lógico Fluxo de sequencia Uma atividade pode ser atômica ou não atômica (composta). Um operador lógico é usado para controlar divergência e convergência nos fluxos sequenciais de um processo. Um fluxo de sequencia é usado para mostrar a ordem das atividades que serão

35 35 Fluxo de mensagem Associação Pool executadas no processo. Um fluxo de mensagem é usado para mostrar a passagem de mensagens entre os participantes. Uma associação é usada para ligar informação e artefatos de forma gráfica. Representação gráfica de um participante em um modelo. Lane Objeto de dados Mensagem Subpartição dentro de um processo ou Pool que estende toda a extensão do processo. Objetos de dados que proveem informação sobre o que as atividades necessitam para serem executadas ou o que elas produzem. Representa uma mensagem com conteúdo de comunicação entre dois participantes. Grupo Agrupa elementos gráficos de uma mesma categoria. A Figura 11 apresenta um exemplo de modelo de processo de negócio em um diagrama BPMN. O processo é composto por quatro raias que representam os papéis executores das atividades, alocadas nas respectivas raias. O modelo utiliza apenas elementos simples, tais como eventos, atividades, operadores lógicos e artefatos.

36 36 Figura 11 Exemplo de modelo de processo de negócio em um diagrama BPMN Esta seção apresentou a notação BPMN. Atualmente em sua versão 2.0, é um padrão publicado pela OMG, que foi definido a partir do esforço de diversos pesquisadores da área para desenvolver uma notação específica para a modelagem de processos de negócio. Portanto, a BPMN não aborda outros conceitos, como por exemplo, a modelagem de objetivos. Na próxima seção será apresentado o framework i*, específico para a modelagem de metas intencionais Framework i* O framework de Modelagem i* (i-estrela) [Yu95] modela contextos organizacionais com base nos relacionamentos de dependência entre os atores participantes [Napolitano09]. A ideia central do i* é representar através de modelos os atores e as dependências que eles têm uns com os outros para que metas próprias sejam atingidas [Oliveira08c].

37 37 O conceito mais relevante no i* é o conceito de objetivo: Um objetivo é uma condição ou estado de interesse no mundo que um ator gostaria de alcançar [Tradução livre, [Yu95] e [13] apud [Oliveira08c]]. Dessa forma, atores dependem uns dos outros para que seus objetivos sejam alcançados, recursos sejam fornecidos, tarefas sejam realizadas e metas-flexíveis sejam razoavelmente satisfeitas [Oliveira08c]. A proposta de modelagem do framework i* consiste em dois componentes de modelagem chamados Strategic Dependency (SD) e Strategic Rationale (SR). O modelo SD descreve um processo em termos dos relacionamentos de dependência intencional entre os agentes. Os agentes dependem um do outro para que os objetivos sejam alcançados, tarefas sejam executadas e recursos compartilhados. O modelo SR prove uma descrição intencional do processo em termos de seus elementos e das suas razões estratégicas internas dos atores [Yu95]. As subseções seguintes detalham os modelo SD e SR Strategic Dependency (Modelo SD) No modelo SD, os atores possuem dependência entre si para alcançar objetivos, executar tarefas e fornecer recursos. Ao depender de outro ator, o ator dependente obtém vantagens das oportunidades que são disponibilizadas através dos atores que prestam o suporte [Yu09]. Ao mesmo tempo em que o dependente é beneficiado, ele torna-se vulnerável caso não sejam atendidas as suas expectativas. Essas dependências são consideradas estratégicas para os atores interessados, já que eles podem ser beneficiados ou prejudicados em seu bem-estar. Atores poderiam escolher que dependências ter, de acordo com seu julgamento em relação a potenciais ganhos e perdas [Yu09]. O modelo SD é um grafo onde os nós representam atores (agentes, posições, papéis), e cada dependência representa um relacionamento de cooperação entre dois atores, sendo que o ator chamado de depender depende de outro chamado de dependee. O elo da dependência, chamado de dependum, é o objeto da dependência que pode ser: um objetivo, uma meta-flexível, uma tarefa ou um recurso, definido sempre como uma entidade física ou informacional. Conforme mencionado anteriormente, as relações de dependência mostram as vulnerabilidades do depender, pois o dependee pode falhar no cumprimento do acordo e, por isso, cada dependência tem um grau de importância ( critical, committed ou open, em ordem decrescente de importância) para refletir sua relevância [Oliveira08c].

38 38 Dentro do diagrama SD, é possível expressar quatro tipos de dependências: dependência de meta, dependência de tarefa, dependência de recurso e dependência de meta-flexível. A Figura 12, Figura 13, Figura 14 e Figura 15 ilustram os quatro tipos de relacionamento (nestes casos, o dependee encontra-se sempre à esquerda e o depender sempre à direita): Figura 12 Exemplo de relacionamento de dependência de meta Figura 13 - Exemplo de relacionamento de dependência de meta-flexível Figura 14 - Exemplo de relacionamento de dependência de tarefa Figura 15 - Exemplo de relacionamento de dependência de recurso Os exemplos ilustram o significado de uma dependência entre dois atores: um ator quer alguma coisa que outro ator pode suprir. A Figura 12 apresenta uma dependência de objetivo, em que o cliente depende do caixa do banco para realizar o saque do dinheiro. A Figura 13 apresenta uma dependência de meta-flexível, em que o cliente depende do caixa do banco para ser atendido com rapidez ao realizar o saque. A Figura 14 apresenta uma dependência de tarefa, em que o cliente depende que o caixa do banco execute a tarefa de emitir o comprovante de pagamento. A

39 39 Figura 15 apresenta uma dependência de recurso, em que o cliente depende do caixa do banco para obter o seu comprovante de pagamento. Os tipos das dependências refletem o grau de liberdade existente no relacionamento. Na dependência por objetivo, cabe ao dependee toda e qualquer decisão para o cumprimento do objetivo. Na dependência por tarefa, o dependee executa a tarefa da maneira como o depender deseja, portanto, é de responsabilidade do depender decidir como a tarefa deve ser executada. Na dependência por recurso, o grau de liberdade é nulo, ou seja, o dependee deve fornecer o recurso exatamente como o depender deseja. Na dependência por meta-flexível, o depender tem a decisão final de aceitar ou não a meta alcançada, porém ele usa o beneficio do know-how (habilidades e conhecimentos) do dependee [Oliveira08c]. Dede que um autor seja autônomo, ele pode optar por não se tornar dependente de outro. Ao analisar a rede de dependências, é possível concluir que algumas dependências parecem ser mais viáveis do que outras e que uma falha dentro de uma dependência pode propagar para uma grande cadeia de dependências [Yu09]. A Tabela 5 apresenta os elementos de um modelo SD. Tabela 5 Elementos de um modelo SD Nome Símbolo Definição/Descrição Ator/Agente Representa um ator interessado em alcançar seus objetivos. Meta Meta-flexível Tarefa Recurso Dependência Marcação de crítico Marcação de aberto Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito. Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador. Representa uma unidade de trabalho a ser executada. Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos. Representa um relacionamento de dependência. Marca o elemento como crítico. Significa que o ator/agente acredita que não existe outra forma para suceder se a dependência não for satisfeita. Marca o elemento como não comprometido/independente. Significa que a rotina pode ser afetada, mas não necessariamente falhar caso a dependência não seja satisfeita.

40 40 A Figura 16 apresenta um exemplo de um modelo SD. Figura 16 Exemplo de diagrama SD [Adaptação de [Susi05]] Strategic Rationale (Modelo SR) O modelo SR oferece uma descrição intencional dos processos em termos de seus elementos e o raciocínio aplicado em sua execução. Enquanto o modelo SD mantém um nível de abstração por modelar somente os relacionamentos externos entre atores, o modelo SR apresenta uma visão em baixo nível que permite maior entendimento sobre os raciocínios estratégicos dos atores em relação aos processos. O modelo SR descreve os relacionamentos intencionais que são internos aos atores, tais como relacionamentos meios-fim que relacionam os elementos dos processos provendo representações explícitas do porque, como e possíveis alternativas. Os raciocínios encontram-se no nível estratégico, logo as alternativas do processo que está sendo fundamentado também são relacionamentos estratégicos [Yu95]. Os elementos do processo usados para representar os relacionamentos intencionais internos aos atores são: relacionamentos meios fim, que possuem o papel de explicitar as decisões que foram tomadas para que as metas do ator fossem alcançadas; decomposição de tarefas, que detalha a elaboração e realização das tarefas, além de mostrar como os recursos são disponibilizados e utilizados; e os

41 41 relacionamentos de contribuição, que exibem o tipo de contribuição (positiva ou negativa) entre metas flexíveis [Napolitano09]. [Oliveira10] definem um metamodelo [Figura 17] contendo os elementos e relacionamentos possíveis no i*. Cada um destes tipos de relacionamentos são detalhados a seguir em termos de sua características de aplicação e elementos gráficos. Figura 17 Metamodelo i* [Oliveira10] No relacionamento de decomposição de tarefa é possível relacionar uma tarefa a subelementos que devem estar disponíveis para a execução da tarefa decomposta. Por exemplo, a decomposição de uma tarefa em uma meta implica que essa meta deve ser satisfeita primeiramente para que a tarefa possa ser executada. Se fosse uma decomposição de recurso, ele deveria estar disponível primeiramente para consumo da tarefa. A Figura 18 apresenta de forma gráfica as possibilidades de aplicação do relacionamento de decomposição.

42 42 Figura 18 Ligações para o relacionamento de Decomposição O relacionamento means-end (meios-fim) registra como e o que foi executado (means) para que um dado fim (end) pudesse ser realizado. Por exemplo, para um recurso ser produzido, alguma atividade foi realizada. Neste caso a atividade tem o papel de means e o recurso, o papel de end. Somente tarefas possuem o papel de means, porém os elementos recurso, tarefa e meta podem ter o papel de end. Ainda existe o caso específico de relacionamento means-end para metasflexíveis que é explicado a seguir. A Figura 19 apresenta de forma gráfica as possibilidades de aplicação do relacionamento means-end. Figura 19 - Ligações para os relacionamentos de meios-fim O relacionamento do tipo Contribuição é um sub-relacionamento do tipo Meansend e herda as suas características [Oliveira10], entretanto, por relacionar especificamente os elementos tarefa e meta-flexível a outro elemento do tipo metaflexível, recebe labels que expressam o significado de contribuição. A Figura 20 apresenta esses relacionamentos.

43 43 Figura 20 Ligações para os relacionamentos de contribuição positiva e negativa A Tabela 6 apresenta os elementos de um modelo SR e suas respectivas descrições. Tabela 6 Elementos do modelo SR Nome Símbolo Definição/Descrição Ator/Agente Representa um ator interessado em alcançar seus objetivos. Meta Meta-flexível Tarefa Recurso Dependência Marcação de crítico Marcação de aberto Decomposição de tarefa Meios-fim Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito. Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador. Representa uma unidade de trabalho a ser executada. Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos. Representa um relacionamento de dependência. Marca o elemento como crítico. Significa que o ator/agente acredita que não existe outra forma para suceder se a dependência não for satisfeita. Marca o elemento como não comprometido/independente. Significa que a rotina pode ser afetada, mas não necessariamente falhar caso a dependência não seja satisfeita. Representa um relacionamento que expressa a decomposição de uma tarefa em outros elementos. Representa um relacionamento que expressa a ligação entre um fim e um meio

44 44 Contribuição positiva Contribuição negativa de alcançá-lo. Representa um relacionamento que expressa contribuição positiva para um meta-flexível. Representa um relacionamento que expressa contribuição negativa para um meta-flexível. Pool do ator/agente Representa um ator/agente em forma de pool. A Figura 21 exemplifica um modelo misto (SD + SR). O conteúdo do modelo SR encontra-se na pool do ator central, onde é modelado o seu rationale, ou seja, a estratégia utilizada para que ele alcance suas metas. Ao redor, apresentam-se as modelagens das dependências de recursos, tarefas e meta com outros atores. Figura 21 Exemplo de modelo SR (adaptação de [Yu95]) Esta seção apresentou o framework i* que oferece uma linguagem para a modelagem de dependências de recursos e metas entre atores, bem como a

45 45 modelagem das estratégias de cada ator para alcançar suas metas. Observa-se que a modelagem de objetivos do i* ocorre em um plano de visão distinto das modelagens tradicionais de objetivos organizacionais que são definidos em alto nível, trazendo uma nova noção que permite análises mais apuradas dos riscos e estratégias envolvidas na execução dos processos organizacionais. A próxima seção apresenta a URN que é uma notação composta por uma linguagem de modelagem de processos (UCM) e uma linguagem de modelagem de objetivos (GRL) URN (UCM e GRL) A URN (User Requirement Notation) é uma notação composta por duas sublinguagens, uma específica para modelagem de processos e outra para modelagem de objetivos. Essa notação é um padrão nomeado como Z.151 e recomendado pela ITU-T (International Telecommunication Union) no contexto das Técnicas de Descrições Formais (FDT) [ITU08]. A URN foi projetada para oferecer recursos para elicitação, análise, especificação e validação de requisitos. Entre os objetivos do desenvolvimento do padrão URN, temos: capturar os requisitos do usuário quando apenas poucos detalhes de projeto estão disponíveis; focalizar os estágios iniciais de projeto; avaliação antecipada de desempenho e detecção antecipada de interações indesejadas [Amyot&Mussbacher02]. A URN é composta por duas notações que representam conceitos de modelagem e notações para objetivos (com foco em requisitos não funcionais e atributos de qualidade) e cenários (com foco nos requisitos operacionais, requisitos funcionais, desempenho e raciocínio (reasoning) arquitetural) [Sikandar03]. A notação com foco em objetivo é chamada de GRL (Goal-oriented Requirements Language) e a notação de cenários é chamada de UCM (Use Case Map). A partir dessa combinação, a UCM permite a captura de objetivos e raciocínios de decisão (utilizando GRL) e a capacidade de modelar sistemas dinâmicos que possuem comportamento variável em tempo de execução (utilizando UCM) [Sikandar03]. As próximas subseções detalham a GRL e a UCM.

46 GRL A GRL é uma extensão da linguagem i* [Yu95] que foi desenvolvida para apoiar a modelagem orientada a metas e a representação do raciocínio (reasoning) de atores, especialmente para tratar requisitos não funcionais. Ela fornece elementos para expressar vários tipos de conceitos que aparecem durante o processo de requisitos. Existem três categorias principais de conceitos: elementos intencionais, links, e atores. Os elementos intencionais na GRL são: tarefa, objetivo, meta-flexível e recurso. Eles são intencionais porque são usados por modelos que permitem identificar o motivo de determinados comportamentos, o motivo de aspectos estruturais e informacionais serem escolhidos para inclusão nos requisitos do sistema, quais alternativas foram consideradas, quais critérios foram usados para deliberar entre as alternativas, e quais as razões para a escolha de uma alternativa e não outra [GRL12]. A GRL suporta o raciocínio sobre cenários, estabelecendo correspondências entre elementos GRL intencionais e não intencionais em modelos de cenários da URN. Modelar ambos os objetivos e cenários é complementar e pode ajudar na identificação de objetivos e cenários adicionais importantes para os interessados, contribuindo assim para a integralidade e exatidão dos requisitos. Alguns dos elementos intencionais da GRL são reutilizados do i*, tais como, ator/agente, task (tarefa), softgoal (meta-flexível) e goal (meta). Entre os relacionamentos reutilizados encontram-se a contribuição, dependência e decomposição. Entretanto, novos elementos são adicionados, tais como, belief (crença), link de correlação, níveis de satisfação e tipos de contribuição. A Figura 22 apresenta os níveis de satisfação e tipos de contribuição (também presentes no i*, provêm do NFR framework [Chung00]). A Tabela 7 apresenta os outros elementos do modelo GRL. Figura 22 Níveis de satisfação (à esquerda) e tipos de contribuição (à direita) da GRL

47 47 Tabela 7 Elementos do modelo GRL Nome Símbolo Definição/Descrição Ator/Agente Representa um ator interessado em alcançar seus objetivos. Meta Meta-flexível Tarefa Recurso Crença Dependência Decomposição Contribuição Correlação Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito. Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador. Representa uma unidade de trabalho a ser executada. Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos. Raciocínio ou argumentação associada a uma contribuição ou uma relação. Representa um relacionamento de dependência. Define o que é necessário para uma tarefa ser executada. Descreve como metas-flexíveis, tarefas, crenças, e relações contribuem entre si. Cada contribuição pode ser qualificada por um nível: equal, break, hurt, some-, some+, undetermined, help ou make (Figura 22). Contribuição que indica efeitos colaterais em outro elemento intencional. A Figura 23 apresenta um exemplo de modelo em GRL utilizando grande parte dos elementos da linguagem. Figura 23 Exemplo de modelo GRL [Amyot02]

48 UCM A modelagem de requisitos funcionais de sistemas complexos, muitas vezes implica em uma ênfase inicial nos aspectos comportamentais, tais como interações entre o sistema e o seu ambiente (e usuários), de forma a definir os relacionamentos entre suas interações e sobre as atividades intermediárias realizadas pelo sistema. Cenários representam de maneira excelente e útil de descrever esses aspectos. [Amyot&Mussbacher02]. Os modelos UCM são usados como uma notação visual para a descrição de relações causais entre responsabilidades em um ou mais cenários. São mais úteis nas fases iniciais de desenvolvimento de software e são aplicáveis para captura e elicitação e validação de cenários, bem como design arquitetônico de alto nível e geração de casos de teste. Também fornecem um framework comportamental para avaliação e tomada de decisões arquiteturais em um alto nível, opcionalmente, com base em análise de desempenho dos modelos. Além disso, fornecem aos seus usuários a capacidade dinâmica (em tempo de execução) do refinamento de variações de cenários e de estrutura como forma de permitir o desenvolvimento incremental e integração de cenários complexos [Amyot&Mussbacher02]. As principais vantagens da UCM são sua capacidade de modelar refinamentos dinâmicos para diversos comportamentos e estruturas, além de integrar componentes estruturais e comportamentais em uma única visão, realizando assim, a ponte entre requisitos e projeto [Amyot&Mussbacher01]. Os elementos principais da linguagem UCM são descritos a seguir (Tabela 8): Tabela 8 Elementos do modelo UCM Nome Símbolo Definição/Descrição Ator/Time Representa o responsável ou grupo de responsáveis no processo. Ponto inicial Captura precondições e eventos de disparo. Ponto final Representa eventos resultantes e pós-condições. Responsabilidades Caminhos Stub estático Stub dinâmico Locais onde, por exemplo, procedimentos, atividades e funções são necessários. Conecta pontos iniciais a pontos finais e pode ligar responsabilidades em um caminho causal. Representa relacionamento estático com outro diagrama. Representa relacionamento dinâmico com outros diagramas.

49 49 Cenários grandes e complexos podem ser decompostos e estruturados através de submapas chamados plugins, usado (e reutilizados) em recipientes de mapas chamados stubs e exibidos em formato de diamantes (Tabela 8). A Figura 24 apresenta um exemplo de diagrama UCM. Este diagrama retrata um cenário de alto nível (comumente chamado de Root Map), enquanto os dois outros modelos UCM da Figura 25 e Figura 26, são plugins para o stub Authenticate. Neste exemplo do diagrama principal, um contribuinte quer acessar o contador eletrônico através do sistema de segurança. Após a identificação de contribuinte (CheckId), o sistema necessita autenticar o solicitante, que pode ser aceito ou rejeitado. Para realizar a autenticação, pode ser utilizado o plugin biométrico ou senha. Uma vez autenticado, o contador eletrônico cria uma nova sessão, e em seguida o sistema torna-se pronto para processar as transações. Figura 24 Exemplo de diagrama UCM (diagrama principal) [Amyot&Mussbacher02] Figura 25 Plug-in Biométrico [Amyot&Mussbacher02]

50 50 Figura 26 Plugin Senha [Amyot&Mussbacher02] Os candidatos a alternativas para a autenticação (biometria ou senha), se incluidos no modelo GRL, podem ser operacionalizados baseado no reasoning, desta forma é possível ter maior controle estratégico, além de possibilitar análises mais detalhadas do contexto nos modelos Rastreabilidade entre UCM e GRL A ferramenta jucmnav é o principal recurso computacional para a criação de modelos UCM e GRL. Esta ferramenta foi desenvolvida como um plugin do Eclipse e encontra-se em constante evolução. A integração dos modelos UCM e GRL e métodos de alinhamento ocorrem de várias formas, por exemplo, através de relacionamentos específicos, tais como links de realização [Behnam10] (Figura 27), responsabilidade, rastreabilidade e complacência [Ghanavati09]. Figura 27 Exemplo de relacionamento do tipo realização entre modelos GRL e UCM [Behnam10]

51 51 Diversos trabalhos são desenvolvidos para ampliar a capacidade de alinhamento e análise dos modelos UCM e GRL, por exemplo, com o uso de indicadores [Shamsaei10], frameworks de alinhamento [Ghanavati09] e uso de templates [Behnam10]. Esta seção apresentou o padrão Z.151, conhecido como URN, proposto pela ITU-T (International Telecommunication Union). Este padrão oferece a modelagem de objetivos em alto nível utilizando a linguagem GRL, e a modelagem de cenários, utilizando o padrão UCM. Um dos pontos positivos desse padrão é a existência de rastreabilidade entre o modelo de objetivos e o modelo de execução. Além disso, diversos estudos expandem a linguagem incluindo novos elementos e relacionamentos como forma de ampliar a capacidade da linguagem no sentido de garantir que os objetivos sejam cumpridos. Na próxima seção será apresentado o framework ARIS, considerado um dos mais importantes no contexto da modelagem de processos de negócio. 2.6.Framework ARIS A Arquitetura de Sistemas de Informação Integrado (ARIS Architecture of Integraterd Information Systems) é um conceito (e não simplesmente uma ferramenta) desenvolvido pelo professor August-Wilhelm Scheer, na Alemanha. Seu objetivo é prover um framework que ofereça meios de expressar os conceitos do negócio de forma precisa e, assim, permitir análises detalhadas e prover um ponto inicial não ambíguo para o desenvolvimento de sistemas de informação computacionais [Davis07]. A partir da definição do framework ARIS, foi desenvolvida a ferramenta ARIS Toolset, lançada em 1992, sendo utilizada em larga escala para a modelagem de processo de negócio por empresas de diversos tamanhos, sendo uma ferramenta líder no ramo [Davis02]. No contexto da modelagem de processos de negócio, a ferramenta oferece três níveis de abstração que são aplicados em diagramas distintos, com objetos específicos. O primeiro nível é formado pelos processos que estão diretamente envolvidos na criação de valores para a companhia, eles são modelados no diagrama de Cadeia de Valor Agregado (VAC Value-added chain) [Scheer&AG05]. O segundo nível é basicamente formado pelo fluxo de atividades, recursos, eventos e regras, que formam o diagrama de Cadeia de Processos e Eventos (EPC Event-Driven Process), considerado o diagrama central de toda a modelagem de negócio no ARIS [Davis07]. Por último, no nível mais baixo, estão modelados os elementos que representam a

52 52 execução das atividades, com o objetivo de oferecer informações adicionais do nível operacional, em particular, sobre a transformação dos dados de entrada e saída [Davis07]. Esses elementos são modelados no Diagrama de Alocação de Função (FAD Function Allocation Diagram). Além desses modelos que são específicos para modelar os processos de negócio em diferentes níveis de abstração, o ARIS também possui um modelo designado apenas para a modelagem de objetivos, capaz de possibilitar a definição e relacionamento dos objetivos de forma hierárquica juntamente com os processos e Fatores Críticos de Sucesso [Seildlmeier&Storr04]. Esses diagramas são detalhados nas subseções seguintes VAC Valued Added Chain O diagrama VAC especifica os processos em uma organização as quais influenciam diretamente o seu real valor agregado. Estes processos podem ser ligados a outros sequencialmente e então formar a cadeia de valor agregado [ARIS06]. Além disso, é possível relacioná-los aos seus respectivos objetivos e indicadores. Um modelo VAC pode ser detalhado em outros macroprocessos do mesmo tipo (VAC). Em um diagrama VAC, os processos podem ser dispostos em uma hierarquia ou similar a uma árvore. A orientação do processo subordinado ou superior é sempre ilustrada, além disso, um diagrama de cadeia de valor representa os relacionamentos entre os processos e as unidades organizacionais e também os objetos informativos [ARIS06]. A Figura 28 exemplifica um modelo VAC. Este modelo possui o macroprocesso Realizar empréstimos para pessoa física, composto por outros três macroprocessos que estão ligados aos seus respectivos objetivos e indicadores (KPI). Realizar empréstimos para pessoa física Porcentagem de trabalhadores da classe C Quantidade de contratos fechados Porcentagem de perda em sinistros Gerir solicitações de pedido de crédito Analisar pedido de crédito Gerenciar contratos de crédito em vigor Garantir acesso às solicitações de crédito para pessoa física Garantir margem de risco controlado nos créditos concedidos Garantir que créditos concedidos retornarão lucro mínimo Garantir o pagamento dos clientes Minimizar perdas em sinistros Figura 28 Exemplo de modelo VAC [Sousa10]

53 Carries out & Supports Carries out & Supports Carries out & Supports 53 A visão de macroprocesso é conhecida como uma visão gerencial devido a sua abstração. Essa visão é moldada durante a primeira fase do ciclo de vida da modelagem de processos de negócio com o propósito de adquirir conhecimento necessário para calcular tempo e custo de um projeto de modelagem de processos do negócio [Sousa10] EPC Event-driven Process Chain O diagrama EPC é o modelo central para toda a modelagem de negócio. É um modelo dinâmico que traz consigo os recursos estáticos do negócio (por exemplo, sistemas, organizações e dados) e os organiza para conceber uma sequência de tarefas ou atividades ( o processo ) que agrega valor ao negócio [Davis02]. Este modelo possui similaridades em relação ao modelo desenvolvido a partir do uso da notação BPMN, já que ambos detalham os processos de negócio no nível de atividades utilizando elementos semelhantes. O fluxo de trabalho detalhado em um modelo EPC engloba informações como papéis executores e suas unidades organizacionais, raias que organizam as atividades de acordo com seus papéis executores, elementos de interface com outros processos, eventos que demarcam o início e o fim do processo, eventos intermediários que sinalizam circunstâncias importantes para a continuidade do processo (principalmente nos fluxos de decisão), operadores lógicos para inserir regras no fluxo e as próprias atividades que serão executadas ao longo do processo [Sousa10]. A Figura 29 ilustra um exemplo de EPC. Este modelo possui atividades executadas pela área de Crédito e taxas contratuais e pelo sistema Crédito direto. As atividades de responsabilidade de cada papel estão respectivamente em suas raias. As linhas que cruzam a linha das raias representam handoffs entre os papéis executores do processo. Organizational el... Receber proposta de crédito Proposta de crédito alterada Alterar proposta de crédito Montar contrato Crédito e taxas contratuais Proposta de crédito recebida Comunicar limite não aprovado Limite não aprovado comunicado Analisar contrato Aprovar contrato Contrato efetivado Verificar situação cadastral do cliente Cancelar proposta SYS Proposta cancelada Necessidade de ajuste do contrato identificada SYS Crédito Direto Limite não aprovado Necessidade de ajuste do contrato não identificada Para cada tipo de imposto Verificar limite de crédito do cliente SYS Limite aprovado Calcular alíquota de imposto SYS Determinar taxa de juros a ser cobrada do cliente SYS Contrato de risco identificado Cancelar contrato de risco SYS Contrato de risco cancelado Figura 29 Exemplo de modelo EPC [Sousa10]

54 FAD Function Allocation Diagram O diagrama FAD é um modelo que possui informações sobre uma atividade do ponto de vista operacional. É utilizado para apresentar uma visão mais detalhada dos recursos disponíveis e necessários, que são relevantes para as atividades. O FAD também é utilizado para reduzir a complexidade visual do diagrama de processo de negócio (neste caso, considere o modelo EPC), representando elementos como, por exemplo, funções, áreas, sistemas de apoio, entradas e saídas de dados, documentos e riscos envolvidos nas atividades [Sousa10]. Observe que a notação BPMN não possui modelos FAD, e que o fluxo de informações é modelado no próprio diagrama principal. A Figura 30 exemplifica um modelo FAD. Esta atividade é executada pelo sistema Crédito Direto, caracterizando uma atividade automatizada. As informações que a atividade consome são Proposta de crédito, Créditos concedidos e Cadastro de cliente, sendo esta última extraída da base de dados BDCliente. O resultado da atividade é a informação Proposta de crédito atualizada com um status de aprovação que depende da regra de negócio Verificação de limite de crédito e que é implementado de acordo com o requisito de negócio Verificar limite de crédito do cliente. Proposta de crédito Crédito Direto BDCliente Cadastro do cliente Verificar limite de crédito do cliente Proposta de crédito Créditos concedidos Verificação de limite de crédito Verificar limite de crédito de cliente Figura 30 Exemplo de modelo FAD [Sousa10] Diagrama de objetivos Além da possibilidade de relacionar o objetivo ao processo na cadeia de valor, ainda é possível detalhar os objetivos do negócio em um diagrama específico. O diagrama de objetivos trata os objetivos como elementos centrais e permite o relacionamento com processos, produtos/serviços, fatores críticos de sucesso (FCS) e o relacionamento entre objetivos de forma hierárquica. A Tabela 9 e

55 55 Tabela 10 apresentam respectivamente os elementos do diagrama de objetivos e os tipos de relacionamentos disponíveis entre os elementos. Observe que os relacionamentos são limitados e não podem ser customizados (apenas é possível substituir o nome de representação, mas não o tipo). Tabela 9 Elementos de um diagrama de objetivos Nome Símbolo Definição/Descrição Objetivo Objective O objetivo pode ser decomposto em subobjetivos e deve estar relacionado direta ou indiretamente a um processo. Processo Fator crítico de sucesso (FCS) Produto/Serviço Process Critical factor Product/Service Um processo deve ter um ou mais objetivos relacionados. O fator crítico de sucesso é relacionado ao objetivo e representa algo que deve ser tratado para que o objetivo seja alcançado. Um Produto/Serviço é consumido ou produzido por um processo. Tabela 10 Conexões permitidas entre os elementos do diagrama de objetivos Conexão x Objeto Objetivo Processo Fator crítico Produto/ Serviço Objetivo Belongs to Supports N/A N/A Processo Supports N/A N/A Has output of Fator crítico Is critical fator for N/A N/A N/A Produto/ Serviço Supports is input for N/A N/A A Figura 31 apresenta um exemplo de modelo de objetivos. O objetivo Aumentar eficiência é composto pelos objetivos Reduzir custos e Aumentar lucro. Este último encontra-se relacionado ao fator crítico de sucesso Lucro. Os processos Executar campanha publicitária e Verificar estratégias de preço, estão relacionados ao objetivo Aumentar Market Share.

56 56 Figura 31 Modelo de objetivos Esta subseção apresentou a modelagem de processos de negócio e objetivos utilizando a ferramenta ARIS, que implementa o framework ARIS. A ferramenta oferece três níveis de modelagem de processos de negócio (VAC, EPC e FAD) além de um diagrama específico para a modelagem de objetivos. Por ser uma ferramenta comercial, a customização de elementos no ARIS é bastante limitada, de forma a garantir sempre as regras de seu framework original. Portanto, existem dificuldades para representar modelos mais detalhados no contexto da semântica dos relacionamentos entre os elementos, por exemplo, relacionamentos de medidas qualitativas/quantitativas, que não existem na linguagem. Essas limitações na definição de novos elementos dificultam a configuração de alterações que ampliam a expressividade dos diagramas auxiliando as análises de alinhamento entre os processos e objetivos. Por exemplo, não é possível identificar as atividades chave de um processo sem a rastreabilidade entre as necessidades de um objetivo e as atividades executadas. Também não é possível utilizando-se apenas a notação disponível, verificar através dos modelos se o processo é capaz de satisfazer um objetivo, ou ainda, medir de forma quantitativa o seu impacto na camada estratégica do negócio. Particularmente, cabe observar que apesar da plataforma ARIS possibilitar uma hierarquização dos objetivos por intermédio do diagrama de objetivos, o consequente alinhamento a diferentes processos é de difícil execução principalmente pela ausência de relacionamentos que possuam semântica para criar a rastreabilidade entre os objetivos e atividades que visam satisfazê-los.

57 57 A próxima seção apresenta uma rápida análise das linguagens vistas e justificativas para a seleção das linguagens utilizadas na integração Seleção de linguagens O objetivo desta seção é ponderar sobre cada linguagem analisada nas subseções anteriores para realizar uma breve análise sobre seus pontos positivos e negativos e então justificar a escolha das linguagens para o trabalho de integração. O que se busca neste momento é uma linguagem de modelagem de objetivos e outra de modelagem de processos de negócio para, posteriormente, inserirmos a rastreabilidade entre as linguagens, adicionando os elementos necessários, além de propor um método de verificação do alinhamento no nível de modelagem. Um dos objetivos da seleção das linguagens é o reuso de seus elementos e definições de interface, uma vez que seria um retrabalho projetar novos elementos representativos, considerando que muitas das definições utilizadas atualmente nos modelos já possuem certa padronização em seus elementos gráficos, mesmo entre diferentes ferramentas e notações. Por outro lado, não vamos nos ater às regras de cada linguagem, mas realizar as adaptações que forem necessárias para alinhar melhor os modelos. O conjunto de alterações expressivas na união das linguagens resultará em uma nova solução, porém derivada das linguagens escolhidas. Nesta avaliação, não somente a capacidade da linguagem será importante, mas todo o contexto de aceitabilidade do mercado e a importância da linguagem dentro de seu domínio. Iniciaremos as análises no domínio dos processos de negócio e posteriormente, no domínio dos objetivos Domínio de processos de negócio Seguindo de acordo com a sequência de apresentações das linguagens de modelagem de processos de negócio neste capítulo, temos a seguinte lista: UML, BPMN, UCM e EPC. A modelagem de processos de negócio na UML inicialmente era desenvolvida utilizando o diagrama de atividades padrão que não possui recursos suficientes para modelar a complexidade de um processo de negócio. No entanto, com a proposta de extensão de [Eriksson&Penker00], foram incluídos novos conceitos, aumentando a capacidade de representação da linguagem. A UML é uma linguagem fortemente consolidada no contexto do desenvolvimento de software e seu diagrama de atividades já é utilizado há anos pelos

58 58 profissionais da áera, entretanto, o fato da extensão de processos de negócio não ser um elemento nativo da UML é um ponto negativo. O diagrama de atividades em si permite apenas o desenho simples do fluxo de atividades, não permitindo, por exemplo, o registro de insumos e produtos das atividades, tais como informações e artefatos. Outro fator agravante é que, apesar desta proposta surgir em 2000, a OMG lançou em 2001 a BPMN, alcançando rapidamente um grande número de usuários. A BPMN é um padrão atualmente desenvolvido pela OMG, que é um consórcio aberto, de nível internacional, que foi fundado em 1989 com o objetivo de criar padrões através do apoio dos diversos membros participantes ao redor do mundo [OMG12]. Entre as grandes empresas que participaram do desenvolvimento da BPMN 2.0, podemos citar: Oracle, SAP AG, Unisys, Accenture, IDS Scheer, Red Hat, TIBCO e Hewlett-Packard. Com o auxilio de diversos usuários, é possível desenvolver os padrões unindo a experiência de vários grupos, além de facilitar a aceitabilidade e uso dos conteúdos gerados. Com isso, a BPMN é atualmente a notação mais utilizada para a modelagem de processos de negócio [OMG11a]. Isso também se justifica pelo grande número de ferramentas comerciais e principalmente gratuitas (incluindo ferramentas de código aberto) disponíveis no mercado. Como exemplo de ferramentas gratuitas (algumas livres) que oferecem a BPMN podemos citar ARIS Express, Barium Live, BizAgi Process Modeler, BonitaSoft, Eclipse BPMN Modeler, Intalio BPMS, Interfacing Free Vision BPMN Modeler, ITP Commerce BPMN Visio plug-in, Oryx, Processmaker Open Source BPM and Workflow, Questetra BPM Suite, TIBCO Business Studio, Visio BPMN Modeler e ainda um vasto número de ferramentas que podem ser encontradas em [Louw12]. Isso demonstra a grande aceitação da notação e a maturidade de difusão, já que temos ferramentas desenvolvidas por empresas de diversos países. Na capacidade da notação em representar elementos de processos de negócio, é a linguagem que mais oferece recursos gráficos. Identifica-se grande número de componentes, muitas vezes de um mesmo tipo, mas com elemento gráfico levemente distinto para representar situações específicas. Um exemplo são os eventos, que podem ocorrer temporalmente em diversas circunstâncias, entretanto, dentro de um processo de negócio, é comum certos eventos possuírem maior número de ocorrências, por exemplo, a emissão de uma mensagem. Esses elementos são chamados de triggers (Figura 32).

59 59 Figura 32 Tipos de eventos da BPMN A BPMN não oferece recursos para a modelagem de objetivos, no entanto, isso não é considerado um problema neste trabalho. Porém, isso talvez justifique a ausência de regras de negócio na notação, que é um conceito importante já que podem atuar diretamente no contexto dos objetivos da organização. Outro ponto importante é que a BPMN, em relação à extensão da UML para processos de negócio, é de autoria da OMG, o que garante maior possibilidade de evolução contínua da notação de acordo com as necessidades reais do mercado e maior garantia de longevidade. No contexto da extensibilidade, ambos permitem a inserção de novas definições. Outra linguagem analisada foi a UCM, que integra a URN, juntamente com a GRL. A UCM é uma linguagem para modelagem de cenários que são usados para descrever processos de negócios ou fluxos de trabalho. Apesar da sua importância dentro da URN ao representar os processos (descritos como cenários) relacionados aos objetivos, no contexto específico da modelagem de processos de negócio ela torna-se menos adequada, seja pela ausência de representação de elementos do negócio como pelo seu padrão gráfico de modelagem.

60 60 Portanto entende-se que a UCM é importante no contexto da URN quando trata de rastreabilidade e alinhamento entre objetivos e processos, mas para representar modelos de negócio de forma abrangente, ela não é a melhor opção. Outros autores corroboram com esse pensamento como [Pourshahid09] e [Sikandar03]. Como última linguagem analisada, temos o EPC que foi desenvolvido em 1992 pelo grupo do professor Scheer, na Universidade de Saarland. Assim como a BPMN, o EPC possui vasta capacidade de representação de elementos de processos de negócio e considerável aceitação do mercado. Um exemplo de importância da linguagem é que os sistemas ERP da SAP utilizam os diagramas EPC para documentar os processos do sistema SAP R/3. O EPC é integrante de um dos frameworks mais avançados no contexto da modelagem de processo: o framework ARIS. Esse framework inspirou o desenvolvimento da ferramenta conhecida como ARIS (Architecture of Integrated Information Systems), da empresa Software AG. Obviamente a ferramenta ARIS também oferece o modelo EPC, porém muitas outras soluções foram desenvolvidas contendo o diagrama, por exemplo, ARIS Express, ADONIS, Mavim Rules, Business Process Visual ARCHITECT, Microsoft Visio, Semtalk, Bonapart e Oryx. Apesar de ser uma linguagem sólida e reconhecida, não se tornou um padrão internacional como a BPMN, principalmente por ter sido desenvolvido em um contexto proprietário e ser o principal modelo de uma das soluções mais complexas e de alto custo do mercado, não atingindo as empresas de pequeno porte e usuários simples. Baseado nestas considerações, escolhemos a BPMN como notação para a modelagem de processos de negócio, uma vez que consideramos sua capacidade de modelagem de processos de negócio satisfatória e com elementos gráficos amigáveis, além de ser um padrão reconhecido e adotado por um grupo internacional com constantes atualizações e estar consolidado entre os usuários e desenvolvedores de ferramentas Domínio de objetivos No domínio de objetivos, de acordo com a sequência de linguagens apresentadas neste capítulo, iniciaremos a análise com a extensão da linguagem UML, prosseguindo com o framework i*, a GRL e o modelo de objetivos do framework ARIS. Assim como os elementos de modelagem de processos de negócio são propostos através da extensão da UML por [Eriksson&Penker00], o mesmo trabalho inclui a extensão de elementos para a modelagem de objetivos. Essa linguagem

61 61 oferece uma abordagem parecida com a do framework ARIS que permite o relacionamento dos objetivos com os processos e a decomposição de objetivos em um diagrama específico, entretanto, é a única linguagem (entre as analisadas) que oferece o conceito de problema. O framework i* é o precursor da modelagem intencional distribuída e no registro do raciocínio (reasoning) para o alcance dos objetivos. A modelagem intencional é voltada para objetivos, definidos como metas e metas-flexíveis. A modelagem tradicional de processos utiliza objetivos, mas de uma maneira pouco profunda o que acarreta uma série de problemas. O i* permite uma análise aprofundada sobre os objetivos organizacionais e como os objetivos provocam impactos uns nos outros e nas tarefas executadas pela organização, uma vez que o i* lida com a intencionalidade de forma mais completa, através da dependência estratégica entre os atores [Oliveira08c], evidenciando maior nível de informações e detalhamento, o que contribui positivamente para a transparência do negócio. Além disso, é um dos frameworks mais referenciados e discutidos da atualidade, servindo de inspiração para novos métodos, tais como GRL (Goal-Oriented Requirements Engineering) e TROPOS [Bresciani04], [Castro02], ERi*c [Oliveira08c], e extensões, tais como, Diagrama de IP [Oliveira08a], SD Situation [Oliveira08a], SR Construct [Oliveira08b] e Diagnósticos i* [Oliveira08b]. Isso demonstra a importância acadêmica do i*, principalmente como precursor da abordagem intencional. Conforme visto, a GRL compõe a URN, que é um padrão internacional aprovado pela União Internacional de Telecomunicação (ITU) e é composta pelos elementos disponíveis no i*, incluindo extensões que ampliam a capacidade da linguagem tanto para a modelagem de agentes (em sistemas multiagentes) como maior capacidade semântica de relacionamentos, já que a GRL aborda especialmente requisitos não funcionais. Apresentando uma visão distinta da modelagem de objetivos baseada em i*, encontra-se o modelo de objetivos do framework ARIS. Consideramos este modelo como o mais simples, principalmente no que tange a capacidade semântica dos relacionamentos. Além de não diferenciar meta de meta-flexível e de não possuir relacionamentos de contribuição, oferece apenas um tipo de relacionamento entre objetivos (belongs to) e outro entre objetivos e processos (supports). Além disso, não permite a extensão da linguagem (ou seja, do framework ARIS) para inclusão de novos elementos. Entretanto, é a única linguagem a explorar o conceito de FCS (Fator Crítico de Sucesso) [Rockart78], [Grunert&Ellegard92].

62 62 Duas linguagens se destacam entre as linguagens analisadas pela capacidade representativa dos elementos e semântica dos relacionamentos: i* e GRL. Na escolha entre as duas linguagens, optamos pelo i*, uma vez que a capacidade da GRL é justificada pelo uso do i* e, além disso, acreditamos que o i* possui maior enfoque acadêmico. Sabemos que existem muitas outras linguagens além das analisadas neste trabalho, por exemplo, somente entre as linguagens discutidas por trabalhos que utilizamos como referências [Pourshahid09], [List&Korherr06], temos: IDEF, Petri Nets, YAWL e EEML, entretanto, descartamos estas linguagens porque entendemos serem menos expressivas no contexto da modelagem de processos do que as outras. Além disso, os trabalhos de [List&Korherr06] e [Pourshahid09] já demonstram que estas linguagens não oferecem mais benefícios do que as linguagens abordadas. Esta subseção apresentou uma avaliação das linguagens de modelagem de processos e objetivos abordados neste capítulo e justificou a escolha da BPMN e do framework i* para o trabalho de integração das linguagens. Cabe salientar que ao reutilizar os conceitos dessas linguagens, a capacidade e restrições referentes à modelagem de processos de negócio e objetivos são basicamente as mesmas das linguagens BPMN e i*, e apenas mudanças convenientes à integração foram aplicadas. Neste trabalho não atentamos a possíveis imperfeições das linguagens, mas apenas focamos na comparação de suas qualidades nos quesitos que consideramos importantes. A Tabela 11 e Tabela 12 sintetizam de forma comparativa, com notas de 0 a 4, sendo o menor valor representando ausência da capacidade descrita, e o maior valor representando a máxima pontuação de satisfação. Os valores foram definidos baseados na experiência prévia e conhecimento adquirido durante o estudo. O quesito Interface refere-se à capacidade representativa dos elementos gráficos; Representação refere-se à capacidade de englobar as diversas definições dos elementos envolvidos no respectivo domínio; Popularidade refere-se às frentes de pesquisa existentes, artigos, citações, porém, principalmente à percepção de volume de usuários utilizando a linguagem; Integração refere-se à presença de elementos que relacionam objetivos e processos de negócio; Padronização refere-se à forma como a linguagem foi projetada, propósito, autores e uso como linguagem padrão dentro de seu domínio; Ferramentas referem-se ao número de softwares disponíveis que oferecem a modelagem da respectiva linguagem; Evolução refere-se à projeção de atualização e continuidade da linguagem.

63 63 Tabela 11 Comparação entre as linguagens de modelagem de processos Diagrama de processos (UML) BPMN UCM (URN) EPC (ARIS) Interface Representação Popularidade Integração Padronização Ferramentas Evolução Tabela 12 Comparação entre as linguagens de modelagem de objetivos Diagrama de Diagrama de I* GRL (URN) objetivos (UML) objetivos (ARIS) NFR Interface Representação Popularidade Integração Padronização Ferramentas Evolução O próximo capítulo apresenta a integração das duas linguagens, os novos elementos, relacionamentos e visões propostas.

64 64 3 Arquitetura de Integração O objetivo da integração é permitir a modelagem de objetivos e a modelagem de processos em um mesmo diagrama de forma a explicitar o porque e o como ao mesmo tempo, evidenciando o alinhamento ou desalinhamento entre processos e objetivos e aumentando a transparência dos modelos. As duas notações (i* e BPMN) possuem elementos e regras próprias que não necessariamente serão reutilizadas aqui. O framework i* oferece a modelagem de objetivos a partir do ponto de vista dos atores, entretanto, em nossa proposta seus elementos são reutilizados na modelagem de objetivos de processos de negócio e, consequentemente, sofre alterações para se adequar à integração. A BPMN serve de base para a modelagem de processos de negócio sendo que este já é o seu papel principal - mas também é adequada para a integração. O resultado do trabalho é uma nova forma de representação e uso de elementos do i* e da BPMN, o que consideramos uma nova linguagem que reutiliza elementos de interesse para a integração. Essa nova linguagem oferece notação mais completa, principalmente no que tange os relacionamentos entre objetivos de negócio, objetivos dos atores (objetivos de mais baixo nível) e suas atividades, que visam satisfazer os respectivos objetivos. Outras contribuições são discutidas posteriormente. 3.1.Similaridades entre as notações [Cardoso10] apresenta um estudo que propõem a integração semântica entre os elementos do framework ARIS e a linguagem TROPOS, correlacionando seus elementos similares. Nesta seção apresentaremos as similaridades que identificamos entre a BPMN e o framework i*. A Tabela 13 apresenta os elementos que possuem a mesma semântica nas duas linguagens. A pool do agente tem o mesmo objetivo que a pool do papel executor que é a imposição de limites no modelo para a inserção dos elementos que são de responsabilidade do ator/agente. Ator e agente também possuem a mesma semântica.

65 65 Tabela 13 Similaridades entre elementos do i* e BPMN Framework i* BPMN Nome Símbolo Nome Símbolo Pool do ator + agente Pool Tarefa Atividade Recurso Objeto de dados A tarefa é similar a atividade representando ações que são executadas pelos atores/agentes. Entretanto, a tarefa também pode representar um processo mais abstrato, que em BPMN é representado por um elemento igual a atividade, mas com uma marcação de subprocesso (Figura 37). Os relacionamentos de decomposição e meios-fim (means-end) podem ser interpretados em relação aos relacionamentos da BPMN, entretanto esses são mais complexos, já que dependem dos elementos que se relacionam. No caso do relacionamento entre tarefa e meta através da decomposição, não é especificado como o objetivo deve ser atingido porque isso não é interesse do ator [istarwiki12], portanto podem existir alternativas a serem executadas, entretanto, isso é de interesse do alinhamento entre processos e objetivos, e deve ser expressado claramente. Esse objetivo será alcançado por uma ou mais tarefas interligadas pelo relacionamento meios-fim, que insere a ideia de XOR (ou exclusivo). Para estas tarefas, o objetivo é algo a ser alcançado. Traduzindo para BPMN, temos um macroprocesso que pode ser executado por um dos dois processos/tarefas que visam alcançar o objetivo (Figura 33). Em outras palavras, no i* as tarefas marcadas com o sinal? implementam o objetivo que decompõem a tarefa mais abstrata. Em BPMN essas tarefas correspondem a atividades que almejam alcançar o objetivo. A tarefa mais abstrata corresponde a um processo macro.

66 66 Figura 33 Relacionamento Decomposição entre tarefa e objetivo no contexto BPMN No relacionamento entre tarefas através do link de Decomposição, a tarefa macro é restringida à execução das subtarefas [istarwiki12]. Todas as tarefas que decompõem devem ser executadas em prol da tarefa macro, porém sem restrição de ordem de execução, portanto, em BPMN esse é um relacionamento de inclusão (AND) (Figura 34). Figura 34 Relacionamento de Decomposição entre tarefas no contexto da BPMN No relacionamento entre tarefa e recurso através do link de Decomposição, o recurso deve estar disponível, sendo que o ator da tarefa não é o responsável pelo recurso [istarwiki12]. Portanto, na BPMN esse recurso é repassado por terceiros para o responsável da tarefa que a utiliza como insumo. Pode também ser um produto de um processo que serve de insumo para outro. No relacionamento entre tarefa e meta-flexível através do link de Decomposição, a meta-flexível representa um atributo de qualidade que deve ser seguido na execução da tarefa e guiará na escolha de alternativas entre as demais decomposições que estão abaixo dela [istarwiki12]. Em BPMN, a meta-flexível poderá representar uma regra de negócio ou novas atividades de decisão que seguem em um dado fluxo a partir de algum parâmetro.

67 67 O relacionamento de meios-fim apresenta uma tarefa meio que representa a ação ou conjunto de ações realizadas que levaram ao produto fim. O produto fim pode ser um recurso, outra tarefa ou um meta/meta-flexível. No caso do fim como um recurso, podemos representar em BPMN o produto de uma atividade ou processo. Caso o fim seja uma tarefa, representa um processo decomposto em outra tarefa, no entanto, para mais de uma tarefa, há uma relação de XOR (ou exclusivo), já que a execução de uma das tarefas é suficiente (Figura 35). Figura 35 Relacionamento de meios-fim entre tarefas no contexto BPMN No caso dos relacionamentos de dependência, eles tornam-se implícitos na troca de recursos entre raias e processos na BPMN Adaptações necessárias O i* é uma linguagem para a modelagem de objetivos (meta e meta-flexível) e de estratégias que visam satisfazer os objetivos de forma intencional, considerando o ponto de vista de um agente. Ela parte da modelagem do alto nível com os objetivos e pode descer até a representação de atividades e recursos de tarefas. Nosso ponto de interesse no reuso do i* segue até o nível em que as tasks (tarefas) iniciam a representação de elementos dos processos de negócio ou mesmo o próprio processo. É neste momento em que fica a cargo do reuso de recursos da BPMN a introdução de maiores detalhes de como as atividades/processos são executadas. Portanto é possível perceber que o reasoning típico dos atores/agentes será compartilhado com a BPMN que também possui elementos para representá-lo, tais como operadores lógicos e eventos. O i* será responsável primordialmente pelas representações de alto nível, contendo objetivos e processos abstratos, e a BPMN, pelos elementos de baixo nível, representando o fluxo de recursos e as tarefas. A Figura 36 demonstra basicamente os limites das linguagens e seus pontos de encontro.

68 68 Figura 36 Integração BPMN e i* Um ponto importante a salientar é que apesar de propormos o diagrama que integra as linguagens e a sua semântica de uso, não limitamos o uso dos recursos das duas linguagens caso o usuário deseje inserir mais elementos representativos. Por

69 69 exemplo, a BPMN já representa a dependência de recursos entre os handoffs (passagem de fluxo de um ator para outro) naturalmente no diagrama, porém se o usuário desejar também representar isso no alto nível, utilizando i*, não haverá restrições. No diagrama da Figura 36 é possível identificar duas adaptações importantes na integração. Uma é referente ao elemento gráfico que representa tarefas. Como no i* não existe uma diferenciação gráfica entre tarefas que representam atividades simples e tarefas que representam um conjunto de atividades (na linguagem i* considera-se as tarefas folhas como tarefas atômicas), acrescentamos ao elemento representativo o mesmo sinal que a BPMN utiliza para representar o processo que possui subprocessos (Figura 37 e Figura 38). O sinal de + representa uma atribuição (assignment), ou seja, um relacionamento com o modelo de subprocesso. Essa atribuição é necessária para a integração das linguagens, uma vez que não será possível representar todos os processos em BPMN em um mesmo modelo caso o nível de objetivos (pertinente aos elementos do i*) possua muitas tarefas deste tipo. Figura 37 Processo que contém subprocesso Figura 38 Tarefa que contém subprocesso Outra adaptação foi a ampliação dos elementos nos quais o relacionamento de meios-fim e decomposição de tarefa podem conectar. Os processos em BPMN sempre serão relacionados com os outros elementos a partir destes conectores mantendo a mesma semântica. O elemento Regra de negócio (Figura 39) também foi incluído entre os elementos da BPMN. Figura 39 Elemento Regra de Negócio

70 70 Alguns objetivos podem ser expressos como regras de negócio, portanto esse elemento foi incluído. Nestes casos consideramos que é melhor expressar os objetivos como regras locais dentro de um processo do que como objetivos do processo, uma vez que são mais difíceis de serem medidos porque não necessariamente essas regras irão gerar produtos, mas apenas controlar a forma como os processos devem ser executados. Entretanto as regras de negócio tornam claras as respectivas decisões no fluxo dos processos e as formas de proceder em atividades, o que a classifica como uma informação importante. As próximas subseções descrevem os diagramas (visões) principais da nova linguagem. As definições de outros elementos que serão incluídos na linguagem aparecerão conforme a apresentação dos modelos Diagrama Integrado O objetivo do Diagrama Integrado é permitir, em um único modelo, a visualização dos elementos do escopo da modelagem de objetivos e da modelagem de processos, ou seja, ele inter-relaciona elementos de processos da BPMN e elementos de objetivos do i*, formando uma única visão. Conforme dito na subseção anterior, o encontro entre BPMN e i* situa-se no nível de processo, conforme apresenta a Figura 36. Uma vez que toda a parte macro foi modelada partindo do nível mais abstrato, o detalhamento de seus elementos resulta na descrição de um segundo nível, onde se encontram os processos. No primeiro nível de detalhamento, é possível fazer a ligação com modelos BPMN diretamente a partir do relacionamento de Atribuição (Figura 40), ou a partir de um relacionamento meios-fim (Figura 41). No relacionamento de atribuição o processo BPMN fica relacionado através de um link + que consta no elemento gráfico. Figura 40 Relacionamento de Atribuição levando ao modelo de processos

71 71 Também é possível explicitar o modelo de processo através do relacionamento meios-fim, conforme mostra a Figura 41. Figura 41 Relacionamento meios-fim Cada processo é executado por um conjunto de atores, esses atores executam atividades do processo de acordo com o seu reasoning (ou seja, os caminhos de atividades percorridos estrategicamente baseado nos diferentes estados possíveis), bem como o que aqui definimos como objetivos locais, que são os objetivos que partem do ponto de vista do ator, ou seja, objetivos de baixo nível que representam a intencionalidade do ator em contemplar suas responsabilidades dentro do processo. Ao detalhar um processo pelo ponto de vista intencional dos atores, estaremos implementando o segundo nível de detalhamento do Diagrama Integrado. A Figura 42 apresenta o detalhamento de objetivos do Papel 1 e Papel 2, relacionando com suas raias no processo, demonstrando as atividades executadas para atingir seu objetivo (considere neste processo a possibilidade de representar os elementos da BPMN e no modelo de objetivos, o uso de outros elementos, por exemplo, a representação de dependência entre os papéis). A Figura 43 detalha ainda mais os relacionamentos entre objetivos e suas atividades. Seus objetivos no processo são relacionados ao trecho de atividades que são específicas para satisfazer os objetivos locais. Este modelo permite a rastreabilidade entre o porque e o como na camada mais próxima ao nível operacional. As atividades são agrupadas através do elemento agrupamento da BPMN e relacionadas aos respectivos objetivos através do relacionamento de meiosfim.

72 72 Cabe salientar que os objetivos locais são detalhamento dos objetivos de processo, ou seja, são subobjetivos, porém expressados no nível de abstração dos atores. Essa relação possibilita a rastreabilidade entre os objetivos de alto nível, os atores responsáveis e suas atividades, o que torna mais fácil e preciso, por exemplo, a identificação de responsabilidades e propagação de impactos causados por problemas ou mudanças, apenas percorrendo o modelo. Figura 42 Detalhamento no diagrama integrado ao nível de papéis executores

73 73 Figura 43 Relacionamento de objetivos locais dos papéis e rastreabilidade no processo Essencialmente, fazem parte do Diagrama Integrado todos os elementos do i* e da BPMN selecionados para uso neste trabalho. Além dos elementos demonstrados até o momento, também inserimos o conceito de indicadores e propusemos uma forma de utilizá-lo dentro da nova linguagem. Um indicador, mais precisamente um Key Performance Indicator (KPI) ou Indicador Chave de Performance (ICP), é um termo da indústria para medição ou métrica que avalia a performance relativa a algum objetivo. Indicadores são usados rotineiramente por organizações para medir tanto sucesso quando qualidade na satisfação de objetivos estratégicos, aprovando processos ou entregando serviços/produtos. Por exemplo, o indicador Aumento da porcentagem da base de clientes pode ser apropriado para o objetivo Aumentar Market share, enquanto Duração média pode servir como um indicador para a atividade Pedido de empréstimo [Daniele11]. Indicadores constituem um elemento importante da modelagem de negócio já que oferecem critérios para determinar se uma organização está alcançando seus objetivos, sejam eles objetivos estratégicos, requisitos de qualidade, ou objetivos de

74 74 produção [Daniele11]. Na Engenharia de Requisitos, indicadores estão sendo usados para avaliar o nível de satisfação de objetivos [Lamsweerde09 apud Daniele11]. A próxima seção apresenta como utilizar os KPIs como auxílio na análise de alinhamento dos processos e seus objetivos Análise do alinhamento através de KPIs Este subseção apresenta uma proposta que consiste em uma abordagem baseada em indicadores com o objetivo de verificar a possibilidade de um processo alcançar seus objetivos Introdução Durante a modelagem dos processos de negócio, diversas informações são levantadas e mapeadas em diferentes modelos, em seus respectivos níveis de abstração. No nível mais abstrato, são representados os processos de negócio que representam a cadeia de valor da organização, formada por processos de alto nível que podem ser decompostos por outros processos em níveis inferiores, mas ainda assim abstratos o suficiente para serem denominados processos. Cada processo existe e se justifica quando ele é projetado de forma a atingir algum objetivo dentro da organização. Da mesma forma que uma organização possui um objetivo geral que justifica a sua existência (por exemplo, produzir um produto), cada processo e subprocesso desta organização também possui seus objetivos (de nível mais baixo) que ao serem satisfeitos, contribuem com os macros objetivos organizacionais. Entretanto, cada processo poderá levar a diferentes níveis de satisfação de seus objetivos: por exemplo, um processo, quando realizado a contento, pode satisfazer por completo um objetivo; ou essa satisfação pode ser parcial (alguns chamam esta última de contribuição). Nesse último caso, o objetivo então será cumprido caso mais de um processo seja realizado com sucesso. Também é relevante mencionar que alguns objetivos são cumpridos a cada execução de um processo enquanto outros dependem de várias execuções de um mesmo processo para serem atingidos. De uma forma geral, serão necessários diversos processos ocorrendo em paralelo para que a organização obtenha sucesso em seu nicho de atuação. Cada objetivo existente em uma organização (independente do nível de abstração) impõe que um conjunto de condições seja satisfeito para que o objetivo possa ser considerado alcançado. O termo condições refere-se, por exemplo, ao desenvolvimento de um produto, um estado do processo, a produção de alguma

75 75 informação, o disparo de um evento específico ou qualquer coisa que possa ser alcançada a partir da execução de um processo. Essas condições (ou conjunto de condições) esperadas em um objetivo são definidas por elementos nomeados como Indicadores. Os indicadores, quando interligados a objetivos, representam as condições que devem ser alcançadas para que o objetivo possa ser satisfeito. Quando interligados a processos, representam condições que são esperadas que sejam produzidas ao instanciar o processo. Abaixo do nível de modelagem dos processos de negócio, está mapeado o conjunto de atividades que devem ser executadas para que o processo seja considerado finalizado. A finalização do processo está inteiramente relacionada à produção das condições necessárias para satisfação de seus objetivos. Ou seja, o processo é responsável por produzir todas as condições esperadas a fim de alcançar os objetivos relacionados ao dado processo. A produção dessas condições está intimamente ligada aos diferentes estados e transformações dos produtos e informações que são processados durante a execução das atividades. As informações são manipuladas através das atividades, gerando diferentes produtos e disparando diferentes eventos. Como a execução natural do processo gera as diferentes condições necessárias para alcançar os objetivos do processo, entende-se que os indicadores devem ser definidos em função da produção destes elementos durante sua execução. Os elementos produzidos pelo processo são vestígios que indicam se o processo de fato produziu o esperado, que é definido através dos indicadores. Portanto os indicadores podem ser definidos através dos elementos que são desenvolvidos ao longo da execução do processo. Supondo-se que o processo produz as informações necessárias para que os indicadores sejam calculados, podemos inferir que: 1. Os indicadores podem ser calculados. 2. Se os indicadores forem satisfatórios (alcançarem suas metas), podemos supor que o processo é eficaz. Entenda como satisfatório o desempenho do processo necessário de forma que os valores resultantes dos indicadores estejam dentro dos limites dos valores esperados pela organização (metas). Caso o processo não produza as informações necessárias, inferimos que:

76 76 1. Os indicadores não podem ser calculados. 2. Não é possível saber se o objetivo está sendo alcançado nos casos em que são necessários insumos para gerar cálculos. 3. O objetivo (meta) não será alcançado caso dependa de produtos do processo. 4. A meta-flexível pode não ter contribuições suficientes para se tornar satisfatória. 5. Os processos encontram-se desalinhados com seus objetivos. A diferença entre o item 2 e 3 é que existem objetivos que dependem apenas de cálculos para serem verificados. Por exemplo, para a meta O número de carros produzidos mensalmente seja maior do que o número de carros vendidos no mês, seu indicador depende apenas de informações sobre números que o processo em algum momento deve produzir para que o objetivo seja medido. No entanto, para a meta Um carro seja produzido por hora, dado que em algum momento do processo de fabricação de componentes houver falha na produção de um item e ele deixar de ser produzido (por exemplo, um parafuso), então entende-se que na ausência do produto, a meta fatalmente não será alcançada. O fluxo de produtos que percorrem um processo pode estar modelado em um diagrama de nível mais baixo, onde as atividades são detalhadas com informações operacionais (como no framework ARIS), mas na BPMN, encontram-se registrados no mesmo nível das atividades, no modelo de processo de negócio. A modelagem do nível operacional consiste em registrar os elementos que participam da execução de uma atividade, por exemplo, dados de entrada e saída, sistemas de apoio, ferramentas utilizadas, regras de negócio e requisitos de negócio. A BPMN somente oferece um nível de modelagem, que é o nível de processo, logo esses elementos devem estar relacionados neste nível (conforme dito anteriormente, a BPMN não oferece modelagem de regras de negócio, e também não possui os elementos que representem requisitos de negócio. Porém cabe salientar que a BPMN deixa em aberto a possibilidade de inclusão de novas definições de negócio no modelo [OMG12], bem como oferece elementos de anotações que podem conter as informações textuais. Neste trabalho incluímos o elemento Regras de Negócio devido a sua importância para o mapeamento de objetivos e processos, entretanto, não abordamos os impactos de sua aplicação). Os elementos que são necessários para calcular um indicador são produzidos pelas atividades e naturalmente modelados ao registrar os elementos de saída das atividades. Nem todos os elementos produzidos pelas atividades são produtos chave para um indicador, podendo tratar-se apenas de informações que perpassam os processos como elementos intermediários que podem, em sequência, se transformar ou não em novos produtos de maior valor para o negócio.

77 77 Portanto, uma das primeiras ações que realizamos foi de desenvolver um novo elemento representativo, levemente distinto, de forma a proporcionar a identificação simples dos elementos que são utilizados como insumos para os indicadores (os quais chamamos de críticos ) em relação aos elementos que participam apenas do fluxo do processo. A Figura 44 e Figura 45 apresentam a diferença entre esses elementos. A única diferença foi a cor do elemento que tornou-se vermelha como forma de chamar mais atenção ao elemento crítico que o processo deve produzir. Figura 44 Cluster representando informações/artefatos que fluem através do processo Figura 45 Cluster representando informações/artefatos necessárias ao indicador Uso de indicadores no Diagrama Integrado O Diagrama Integrado é composto por elementos do i*, da BPMN, além de elementos que auxiliam na integração. Para aplicarmos a abordagem da análise de alinhamento utilizando indicadores, foram incluídos ao diagrama novos elementos para apoiar a representação dos recursos críticos (apresentado na subseção anterior), indicadores e novos relacionamentos. A Tabela 14 apresenta o conjunto de elementos que foram adicionados ao Diagrama Integrado. Dois relacionamentos foram incluídos para ligar o recurso crítico ao indicador (com a semântica de Recurso crítico é insumo para o Indicador ), e para ligar o indicador à meta/meta-flexível (com a semântica de Indicador mede o objetivo ).

78 78 Tabela 14 Novos elementos incluídos ao Diagrama Integrado Nome Símbolo Definição/Descrição Recurso crítico (Informação/Artefato) Representa um artefato/informação que é utilizado como insumo para cálculo dos indicadores. Indicador Representa o elemento indicador. Associação (Insumo) Associação (Medição) Relaciona um Recurso Crítico como insumo de um Indicador. Relaciona um KPI como um elemento que mede satisfação de uma meta/meta-flexível. Para exemplificar a aplicação do uso dos indicadores, foi desenvolvida a Figura 46. O Diagrama Integrado apresenta a modelagem de um processo que visa atender um cliente. Na parte que define os objetivos, temos que o Atendente geral possui dois objetivos, A meta-flexível Clientes sejam atendimentos rapidamente e a meta Clientes sejam atendidos de forma satisfatória. Para verificar o atendimento satisfatório da meta-flexível, foi criado o indicador Tempo médio de atendimento que calcula a média de tempo dos atendimentos. Caso a média seja menor ou igual ao tempo estabelecido pelo gestor como rápido, o objetivo será considerado satisfatório. Esse objetivo caracteriza-se como meta-flexível porque tempo rápido é discutível e pode mudar seus critérios de satisfação baseado em pontos de vista distintos. Entretanto o indicador existe e calcula a média do tempo, ficando a cargo de um possível gestor definir o que é tempo rápido baseado em métricas que ele utilizar como apoio [Kaiya02], [Cysneiros&Leite]. Para que o indicador possa ser calculado, ele necessita de um insumo, que é o tempo dos atendimentos. Neste caso, a solução foi fazer a média a partir do tempo de gravação dos atendimentos. Portanto, para que o indicador seja calculado, é necessário este recurso crítico. Para verificar a satisfação da meta Atendimento mal sucedido seja menor que 10% foi criado o indicador Porcentagem de atendimentos mal sucedidos. O objetivo consiste em verificar se o número de atendimentos que não foram solucionados é menor ou igual a 10% de todos os atendimentos. O indicador então calcula a porcentagem baseando-se no número de todos os atendimentos e o número de atendimentos mal sucedidos. O número de todos os atendimentos é calculado com o

79 79 somatório de gravações de atendimentos. O número de atendimentos mal sucedidos é obtido a partir do registro de atendimentos que tenham sido mal sucedidos. Para atender a esses objetivos, a Atendente geral deve realizar a tarefa Atender cliente. Essa tarefa pode ser executada de duas maneiras: ao executar o processo Realizar atendimento presencial para clientes externos ou Realizar atendimento telefônico para clientes externos. Observe que neste caso o cliente em foco é um cliente externo, entretanto, nada impede que esses objetivos sejam usados no contexto dos clientes internos. Na integração dos modelos, ficou expressado o processo Realizar atendimento telefônico para clientes externos. Observa-se sem dificuldades que este processo produz o recurso crítico Gravação do atendimento, necessário para calcular o Indicador tempo médio de atendimento e também parte dos insumos necessários para o cálculo do indicador Porcentagem de atendimentos mal sucedidos. Entretanto, não é possível identificar o recurso crítico Atendimento mal sucedido. Com isso, é possível concluir que o processo não é capaz de oferecer recursos para saber se o objetivo Atendimentos mal sucedidos seja menor do que 10% está sendo alcançado ou não, o que demonstra o desalinhamento entre os modelos, o processo e seu objetivo. É claro que o objetivo pode estar sendo alcançado, uma vez que, como dito anteriormente, este é um objetivo que depende de cálculo e não de produto. Porém, no nível de modelagem identifica-se o problema e para solucioná-lo, ou elimina-se o objetivo ou o processo deve ser alterado de forma a permitir que a medição do objetivo seja possível.

80 80 Figura 46 Uso dos indicadores no Diagrama Integrado Uma visão mais simplificada pode ser expressa como na Figura 47, onde o detalhamento do processo é escondido em um relacionamento de Atribuição e a produção do recurso crítico é explicita através de relacionamento. Figura 47 - Uso dos indicadores de forma simplificada no Diagrama Integrado

81 81 Nos exemplos citados, o indicador mais complexo é que necessita de dois elementos como insumo para realizar o cálculo. Entretanto podem existir muitos objetivos relacionados a muitos indicadores que, por sua vez, necessitam de muitos recursos para o seu cálculo. Isso pode tornar o Diagrama Integrado inviável em número de elementos presentes, uma vez que ele já possui naturalmente a modelagem de processos e objetivos no mesmo modelo. Para solucionar este problema, desenvolvemos o Diagrama de Indicadores que modulariza o relacionamento entre objetivos, indicadores e recursos críticos permitindo a extração desses elementos do Diagrama Integrado e garantindo a possibilidade de análise dos indicadores Uso do Diagrama de Indicadores Esta seção apresenta a aplicação do Diagrama de Indicadores que tem como objetivo permitir o relacionamento dos indicadores com os objetivos e dos indicadores com os elementos necessários para medi-los que, neste caso, são as informações e/ou artefatos críticos. Com este diagrama, viabiliza-se a proposta apresentada na seção anterior sem a necessidade de representar no Diagrama Integrado todos os elementos críticos, reduzindo assim a complexidade do modelo, principalmente em casos em que diversos elementos devem ser modelados. A Tabela 15 apresenta os elementos que compõem o Diagrama de Indicadores: Tabela 15 Elementos do Diagrama de Indicadores Nome Símbolo Definição/Descrição Meta Meta-flexível Recurso crítico (Informação/Artefato) Indicador Processo Representa um objetivo que somente pode ser completamente satisfeito ou não satisfeito. Representa um objetivo que pode ser satisfeito de acordo com pontos de vista, ou então parcialmente satisfeito. Representa um recurso considerado crítico em um processo, uma vez que ele é usado na medição dos objetivos do processo. Representa um indicador que pode medir um objetivo. Representa um processo relacionado através de atribuição.

82 82 Associação (Insumo) Associação (Medição) Associação (Produto) Associação (Dever) Relaciona um Recurso Crítico como insumo de um Indicador. Relaciona um KPI como um elemento que mede satisfação de um meta/meta-flexível. Relaciona um Recurso Crítico que é produzido por um Processo. Relaciona um Processo a uma meta/meta-flexível que deve ser satisfeito. No Diagrama de Indicadores, o principal objetivo é relacionar o indicador aos elementos críticos necessários para que ele seja calculado e relacionar o indicador ao objetivo o qual ele mede. Esses relacionamentos são necessários porque ao retornar no Diagrama Integrado, o Diagrama de Indicadores fará a ponte para a verificação dos elementos críticos presentes nos processos com os elementos críticos presentes no(s) indicador(es), além do relacionamento entre o objetivo e o indicador demonstrar se aquele modelo se refere ao objetivo do processo avaliado. Opcionalmente, é possível relacionar o elemento processo tanto ao objetivo através do relacionamento de Associação de Satisfação (que tem a semântica que implica que o processo deve satisfazer aos seus objetivos) quanto ao Recurso Crítico, com o relacionamento de Associação de Produto (que tem a semântica que implica que o processo produz o recurso crítico). A inclusão desses elementos adiciona ao modelo a informação de qual processo que gera o recurso critico bem como o processo responsável por atingir o objetivo. A inclusão desses elementos é opcional, entretanto, torna mais transparente o contexto em que se encontram os relacionamentos dos recursos críticos x indicadores x objetivos. A Figura 48 apresenta um exemplo de um modelo no Diagrama de Indicadores: Figura 48 Exemplo de modelo no Diagrama de Indicadores

83 83 Este diagrama demonstra os relacionamentos básicos entre os elementos metaflexível, indicador e recurso crítico. A meta-flexível Cliente seja atendido rapidamente implica no cálculo do tempo médio dos atendimentos aos clientes que é medido pelo indicador Tempo médio de atendimento. Para realizar esse cálculo, o indicador utiliza como insumo o recurso crítico Gravações dos atendimentos, extraindo a informação de tempo e realizando a média. O objetivo será satisfeito se o valor do tempo médio das gravações estiver dentro de um intervalo definido como rápido pelos gestores do negócio (essas informações extras relacionadas aos elementos ficam registradas nos campos propriedades dos elementos, oferecidos pela ferramenta). No contexto da análise aqui proposta, para que a meta-flexível seja medida é necessário que o processo relacionado a este objetivo obrigatoriamente produza o recurso crítico Gravações dos atendimentos. Uma vez produzido, a satisfação da meta-flexível (que é o valor do tempo médio) dependerá exclusivamente da instância do processo (e para o caso de metas-flexíveis, também dependerá da interpretação do possível avaliador ou ainda do valor resultante das diferentes contribuições que a meta-flexível recebe. Em [Chung00] encontra-se mais explicações sobre a diferença entre os conceitos de satisfação de metas e metas-flexíveis). Portanto, conforme dito anteriormente, uma verificação de alinhamento possível de aplicar no nível de modelagem é a identificação da produção dos recursos necessários para o cálculo dos indicadores. Esta seção apresentou a aplicação da proposta utilizando os elementos de indicadores como um meio para relacionar objetivos, processos e informações/artefatos. Com essa proposta é possível avaliar se o processo produz as informações necessárias para que os indicadores ligados aos objetivos sejam calculados. O simples cálculo dos indicadores não é suficiente para que se afirme algo em relação aos objetivos do processo, ainda é necessário que a instância do processo seja capaz de gerar informações que produzam indicadores satisfatórios. Desta forma, se todos os indicadores relacionados a um objetivo estiverem satisfatórios, sugere-se que o objetivo foi alcançado, entretanto, é possível identificar se o processo, conforme está, possui capacidade de alcançar seus objetivos se for executado de forma a produzir os resultados satisfatórios. O próximo capítulo apresenta como foi realizada a implementação de todos os elementos e modelos que foram desenvolvidos para possibilitar a integração das linguagens.

84 84 4 Implementação da Integração Este capítulo descreve como foram implementadas as linguagens e os elementos de integração na ferramenta-protótipo que reutilizou o núcleo e estrutura da ferramenta de código aberto Oryx Ferramenta Oryx A ferramenta Oryx é um framework acadêmico de código aberto inicialmente desenvolvido para oferecer a modelagem gráfica de processos de negócio (BPMo). Sua tecnologia é baseada em web, sendo executado através de browser, o que elimina a necessidade de instalação do software. Atualmente a ferramenta oferece várias linguagens para modelagem, tais como BPMN (Business Process Model and Notation) e EPC (Event-driven Process Chain), além disso, é extensível a novas funções através da adição de plugins [Oryx12]. Sua arquitetura é bem definida e já foi reutilizada para o desenvolvimento de soluções comerciais como, por exemplo, a ferramenta Signavio [Kunze&Weske10]. Além disso, a ferramenta Oryx encontra-se em uso por grandes empresas, por exemplo, a organização Serpro [Serpro11], que realiza customizações para adequá-la às suas necessidades. A Figura 49 apresenta alguns diagramas disponíveis para uso através da ferramenta Oryx. Atualmente a ferramenta encontra-se na versão Beta e pode ser acessada pelo site oficial do Oryx:

85 85 Figura 49 - Painel com diversos exemplos de tipos de modelos que podem ser modelados na ferramenta 4.2. Estudo da ferramenta Apesar de possuir o código aberto, pouca documentação existe sobre a infraestrutura da ferramenta, além disso, a documentação disponível encontra-se em línguas estrangeiras como o inglês e alemão. Portanto, para adquirir o conhecimento necessário para customizar a ferramenta de acordo com as nossas necessidades, foram demandados esforços de pesquisa nas bibliografias existentes e principalmente no código fonte, utilizando o método de tentativa e erro. Como forma de projetar um caminho estratégico para alcançar o conhecimento necessário sobre a ferramenta e posteriormente customizá-la, definiu-se o uso das seguintes técnicas da engenharia de software: engenharia reversa e reengenharia de software. A engenharia de software utiliza-se dos princípios da engenharia reversa como uma coleção de teorias, metodologias e técnicas capazes de suportar a extração e abstração de informações de um software existente, produzindo documentos consistentes, quer seja a partir do código fonte, ou através da adição de conhecimento

86 86 e experiência, que não poderiam ser automaticamente reconstruídos a partir do código [Benedusi92]. A engenharia reversa atua no caminho contrário da engenharia progressiva, que se define como àquela que segue a sequencia de desenvolvimento estabelecida por uma metodologia, visando à obtenção do sistema implementado. Na engenharia reversa o sistema geralmente é o ponto inicial do processo [Chikofsky&Cross90]. Portanto utiliza-se a técnica de engenharia reversa, quando o produto existe juntamente com a necessidade realizar alterações de qualquer natureza, porém, não existem insumos suficientes que documentem a sua infraestrutura de forma a possibilitar o entendimento necessário para realizar as alterações. Duas categorias dentro da engenharia reversa são apontadas por [Chikofsky&Cross90]: redocumentação e recuperação do projeto. A redocumentação visa criar diferentes visões do sistema, em diferentes níveis de abstração através da análise do código fonte, para possibilitar maior compreensão do sistema. O desenvolvimento dessas visões pode gerar nova documentação (diferente da documentação preexistente), agregando mais conhecimento sobre o sistema. A recuperação do projeto visa obter as informações necessárias para melhorar o entendimento sobre os objetivos do sistema, quais suas atividades e como ele as executa. Por sua vez, a reengenharia de software também chamada de recuperação ou renovação, recupera informações de projeto de um software existente e usa essas informações para alterar ou reconstituir o sistema, preservando as funções existentes, ao mesmo tempo em que adiciona novas funções ao software, num esforço para melhorar sua qualidade global [Piekarski&Quinaia95]. Essa definição demonstra uma ligação direta entre a reengenharia de software e a engenharia reversa, uma vez que a reengenharia utiliza o conhecimento gerado a partir da aplicação da engenharia reversa para possibilitar as alterações no software durante a execução da reengenharia. Portanto existe distinção clara entre as duas técnicas, conforme destaca [Piekarski&Quinaia95]: O objetivo da reengenharia é produzir um sistema novo com maior facilidade de manutenção e a engenharia reversa é usada como parte do processo de reengenharia, pois fornece o entendimento do sistema a ser reconstruído. Durante o trabalho no Oryx, foi recuperado o desenho da ferramenta a partir das descobertas possibilitadas pela engenharia reversa e concluída a reengenharia ao implementar um conjunto de plugins que possuem os elementos propostos neste trabalho. As próximas subseções detalham as atividades realizadas.

87 Aplicando a Engenharia Reversa Como início da execução da engenharia reversa, foi definido um plano composto por três fases que, por sua vez, são compostas por um conjunto de atividades conforme descrito na Tabela 16: Tabela 16 Projeção de macroatividades da engenharia reversa da ferramenta Oryx Fase 1 Fase 2 Fase 3 Identificar como obter o código fonte Identificar os procedimentos para a instalação da base de codificação Configurar o ambiente de desenvolvimento Identificar documentação da ferramenta Estudar a arquitetura da ferramenta Identificar os procedimentos para desenvolvimento de plugins Estudar o código fonte Identificar os conceitos arquiteturais na codificação Avaliar outras necessidades Execução da Fase 1 A primeira fase do processo de engenharia reversa foi iniciada com uma pesquisa na internet para obter informações gerais sobre como proceder com a instalação do ambiente de desenvolvimento Oryx. Durante as buscas foram identificados muitos sites com o assunto Oryx, porém o site oficial do projeto Oryx ( publicado no Google Codes ofereceu o conjunto de informações necessárias para realizar as atividades da primeira fase. Os procedimentos de instalação da ferramenta, acesso à codificação e configuração do ambiente de desenvolvimento são descritos em [Sousa&Leite12]. Após as execuções destas atividades, a Fase 1 da engenharia reversa do software Oryx foi finalizada. A próxima subseção descreve a execução da segunda fase. Execução da Fase 2 A segunda fase da engenharia reversa foi iniciada com a busca de documentos que descrevessem a arquitetura da ferramenta Oryx. Alguns documentos [Daniel07], [Peters07], [Tscheschner07], foram encontrados no site oficial Oryx-editor, no Google Codes. Estes documentos são monografias desenvolvidas por alunos que estão envolvidos no grupo de pesquisa da ferramenta Oryx. Os trabalhos possuem um conteúdo extenso sobre a infraestrutura da ferramenta e o desenvolvimento de plugins, no entanto, todas as documentações estão em língua estrangeira como o inglês e o alemão.

88 88 Para solucionar parcialmente a dificuldade de leitura em alemão, os arquivos em PDF deveriam ser traduzidos. Então foi feita uma pesquisa para identificar ferramentas que realizassem esse trabalho. A maioria das ferramentas encontradas não traduziam arquivos com extensão PDF, e as que traduziam eram caras, além disso, as traduções em softwares gratuitos e demonstrativos eram limitadas em poucas linhas. Outra busca foi realizada para verificar softwares de tradução de arquivos do tipo DOC, e diversos aplicativos foram encontrados. A partir disso foi iniciada outra busca por programas capazes de transformar arquivos PDF para arquivos DOC. Vários aplicativos foram encontrados e a conversão foi feita, no entanto, o produto desta conversão não foi satisfatório, já que foram inseridos no documento muitos caracteres aleatórios, deformando sua formatação e afetando sua estrutura, o que impossibilitou uma tradução minimamente satisfatória. Novamente iniciou-se a busca por tradutores de PDF, e desta vez foi identificada uma ferramenta de tradução online baseada no tradutor do Google (Google Translate - disponível em Este ferramenta traduziu o documento integralmente, mas também inseriu muitos erros, no entanto, foi a única solução descoberta que produziu uma tradução aceitável. Com a leitura destes documentos traduzidos foi possível obter o conjunto de informações necessárias sobre a arquitetura da ferramenta (Figura 50), compreender no nível teórico como é a organização de arquivos do Oryx e identificar os arquivos chaves para a construção de plugins. Essas informações descobertas a partir do estudo dos documentos identificados na pesquisa serão descritas a seguir, de forma resumida.

89 89 Figura 50 Arquitetura da ferramenta Oryx [Daniel07] A ferramenta tem um projeto típico Cliente-Servidor onde mantém a codificação principal sendo processada no lado do servidor, enquanto parte da codificação permanece no lado cliente. A codificação desenvolvida para o lado servidor não foi estudada neste trabalho, já que não é necessária para o desenvolvimento de plugins. A estrutura da ferramenta foi desenvolvida para ser capaz de interpretar arquivos que são compostos pela definição de elementos de modelagem e suas regras de interação. O desenvolvimento destes arquivos independe da complexidade do núcleo da ferramenta Oryx, o que demonstra a modularidade dos componentes núcleo de sistema e plugin. O foco do trabalho será na parte do cliente, mais especificamente no desenvolvimento dos Stencils. Um stencil é a descrição de um objeto gráfico e suas regras, que definem como esse objeto irá se relacionar com os outros no diagrama. Um conjunto de stencils pode ser carregado no editor Oryx para construir modelos [Peters07]. No entanto os stencils não serão carregados em separado, eles serão agrupados em um mesmo arquivo formando um stencil set. Uma importante característica do stencil é que ele não define a representação gráfica dos elementos, mas somente as propriedades referentes ao comportamento do objeto no diagrama. O desenvolvimento da parte gráfica dos componentes será abordado mais a frente.

90 90 Os stencils set são armazenados em arquivos do tipo JSON (JavaScript Object Notation - O arquivo JSON que define um plugin para o Oryx é composto por um cabeçalho, conjunto de stencils e conjunto de regras. A Figura 51 exemplifica o código de um stencil set. Esse fragmento é composto por um título, que nomeia o stencil set, um namespace que é um identificador único, uma descrição, e o conjunto de stencils e regras. Figura 51 Fragmento de um stencil set No interior da tag de stencils são inseridas as definições dos elementos de modelagem. Não há restrição de numero de stencils a serem inseridos no conjunto. A Figura 52 exemplifica o código de um stencil, presente dentro da tag Stencils : [ ], ele inicia e termina entre as chaves ({ }). O stencil é formado pelos atributos: type, que define qual é o tipo de elemento do stencil, por exemplo, um nó ou relacionamento; id, que é um identificador único para o elemento; title, que nomeia o objeto no diagrama; description, que define uma descrição do elemento que será mostrada no gráfico; view, que é o path para o arquivo gráfico que será desenhado no diagrama; icon, que é o path para o arquivo gráfico que possuirá o pequeno ícone que representará o elemento; roles, que especificam regras definidas que podem ser aplicadas a elementos específicos; properties, que oferecem ao usuário informações e campos para serem preenchidos referentes a propriedades do elemento. Não existe restrição ao numero de propriedades inseridas no stencil.

91 91 Figura 52 Fragmento de um stencil As propriedades de um stencil podem conter diversos parâmetros. Cada propriedade descrita irá gerar um campo no gráfico seja para permitir a inserção de texto, seleção de opção ou conteúdo pré-definido. A Figura 53 exemplifica o código das properties contendo apenas uma propriedade e seus parâmetros, limitados pelos { }. Figura 53 Fragmento das propriedades de um stencil Por fim, as rules definem um conjunto de regras referente a relacionamentos entre os elementos no diagrama. A Figura 54 mostra um fragmento de código contendo três tipos de regras: connectionrules, cardinalityrules e containmentrules. Ainda existem outros tipos de regras, porém somente essas três serão detalhadas já que os stencils set produzidos neste trabalho as utilizam predominantemente.

92 92 Figura 54 Fragmento de código das regras de um stencil set O tipo de regra connectionrules consiste em definir quais elementos podem ser interligados a partir de um relacionamento, ou seja, mais especificamente é a configuração de um determinado objeto do tipo relacionamento, onde define-se os elementos em que ele pode interligar. A Figura 55 apresenta um fragmento de código que define regras para relacionamento entre elementos. Neste exemplo, o elemento de relacionamento controlflow está configurado com duas regras de conexão. A primeira define que pode existir uma conexão saindo do elemento activitysource em direção ao elemento conditiontarget. A segunda regra define a conexão saindo do elemento conditionsource para o elemento activitytarget. Figura 55 Fragmento de código das regras de conexão O tipo de regra cardinalityrules define o número de conexões de entrada/saída que um elemento pode possuir. A Figura 56 exemplifica um fragmento contendo duas regras de cardinalidade. Essa regra não está definida para um elemento específico como descrito nas regras de conexão, exemplificada anteriormente, mas define um papel (role) que deve ser configurado no stencil para adquirir a regra. No exemplo, dois papéis são definidos: inputcondition e outputcondition. O papel inputcondition define que o objeto o qual está configurado para obedecer esta regra deverá obrigatoriamente ter um elemento de relacionamento entrando. O papel outputcondition também especifica que é obrigatório um relacionamento de saída do elemento.

93 93 Figura 56 Fragmento de código de regras de cardinalidade O tipo de regra containmentrules define quais elementos podem estar contidos dentro do elemento configurado. Esta regra é mais adequada às raias (pools) onde os elementos são inseridos. A Figura 57 exemplifica um fragmento de código contendo regras de conteúdo. Esta regra cria uma role diagram que contém os elementos que possuem o id activity, condition e as regras definidas de conexão definidas anteriormente inputcondition e outputcondition. Figura 57 Fragmento de código de regras de conteúdo Uma vez definido o stencil set, todas as informações e regras sobre os elementos estarão disponíveis para interpretação do Oryx. O próximo passo é definir os elementos gráficos que representarão os stencils definidos no stencil set. Dois elementos gráficos são necessários para representação no modelo: o ícone e o objeto gráfico. O ícone é uma versão reduzida do objeto gráfico que a ferramenta disponibiliza em um painel na interface da ferramenta, para que o usuário selecione entre as opções, e o respectivo elemento seja incluído no diagrama. Os ícones devem estar no formato de arquivo PNG com dimensões de 16 x 16 pixels. Essas figuras podem ser facilmente desenvolvidas utilizando o MsPaint, no Windows. O elemento gráfico que representa o objeto que será desenhado no diagrama é definido a partir do formato SVG (Scalable Vetor Graphics).

94 94 Neste formato os desenhos são criados a partir de códigos do padrão SVG. Existem vários comandos que podem ser utilizados para gerar diversos tipos de grafos. Esses comandos podem ser estudados no site do W3C ( Alguns tipos de arquivo SVG são oferecidos, por exemplo, é possível criar um arquivo SVG relacionado a figuras existentes, como se fosse uma ancora para o outro arquivo gráfico, no entanto, este tipo de arquivo SVG não funciona corretamente no Oryx, sendo recomendado apenas o uso dos arquivos SVG descritivos, em que as imagens são geradas a partir da especificação de código na linguagem oferecida pelo padrão. Além da codificação do padrão SVG, devem ser inseridos no arquivo outras tags que serão interpretadas especificamente pelo Oryx. Por exemplo, devem ser definidos no arquivo SVG a localização do campo de texto, cor, tamanho da fonte, entre outros elementos, como os Oryx Magnets, que definem pontos no desenho onde os relacionamentos podem se ligar ao objeto. A Figura 58 demonstra um exemplo de codificação de arquivo SVG contendo tags do Oryx. Neste exemplo, nota-se que o cabeçalho possui a definição do namespace do Oryx, necessário para reconhecer as tags: xmlns:oryx=" A tag <Oryx:magnets> demarca o inicio da configuração dos pontos que estarão disponíveis no objeto para a ligação de relacionamentos. Cada ponto é definido pela sua coordenada x e y. Entre as tags <g> </g> estão configurados os elementos que definirão o visual gráfico do elemento. A tag <radialgradient> </radialgradient> define um fundo para ser utilizado no objeto. Esta imagem é composta por uma reta <rect> que está ancorada ao elemento (Oryx:anchors) pelo topo, esquerda e direita, o que significa que ao ampliar o objeto no diagrama, a reta crescerá para estas direções, exceto para baixo. O mesmo ocorre para o círculo <circle> que também compõem a imagem. Na tag <text> é definido o campo para inserção de texto no elemento, incluindo o tamanho da fonte, sua coordenada x, y e seu alinhamento (align) em relação ao objeto. O texto é encaixado na reta que é desenhada no gráfico (fittoelem).

95 95 Figura 58 Exemplo de código de imagem SVG Em suma, para desenvolver o plugin desejado, é necessário definir o stencil set contendo todos os elementos que se deseja modelar, suas regras, seus ícones e arquivos SVG referentes a cada um dos elementos. Esse conhecimento é suficiente para finalizar a Fase 2 (Tabela 16) do processo de engenharia reversa. Na próxima subseção, são descritos os procedimentos realizados na terceira fase do processo de engenharia reversa onde foram estudados os conceitos descobertos na segunda fase diretamente na codificação da ferramenta. Execução da Fase 3 Na terceira fase do processo de engenharia reversa, o alvo de estudo é a codificação e o ambiente de programação do Oryx. Grande parte do código já foi estudada nos documentos, na segunda fase, porém neste momento todos os conceitos serão revistos de forma prática nos arquivos do projeto do Oryx.

96 96 Entre o conjunto de pastas e arquivos do projeto do Oryx, estão codificações referentes ao lado servidor e cliente da aplicação. Como dito antes, o estudo realizado tem foco no lado do cliente. Os arquivos dos stencils, os quais serão de fato editados, estão presentes no seguinte path: Oryx/editor/data/stencilsets (Figura 59). Figura 59 Infraestrutura de pastas do ambiente de desenvolvimento do Oryx Abrindo a pasta stencilset (Figura 60) é possível encontrar um grande conjunto de stencils presentes nas subpastas e também o arquivo stencilsets.json. Neste arquivo são registrados todos os stencils sets presentes na pasta stencilsets. Portanto é necessário registrar o novo stencil neste arquivo. A Figura 61 exemplifica o registro de um stencil set no arquivo stencilsets.json. As informações que compõem o registro são título do stencil (title), namespace, descrição (description), path onde está o arquivo JSON do stencilset que se deseja registrar (uri), path do ícone para representar o stencil set (icon_url) e a opção que torna o stencil set visível na ferramenta ou não (visible).

97 97 Figura 60 Detalhamento da pasta stencilsets Figura 61 Exemplo de registro de stencil set Ao entrar em uma pasta de um stencil set, identifica-se uma estrutura comum a todos as pastas dos stencils set que é composta por uma subpasta dedicada aos ícones dos elementos (icons), uma subpasta dedicada aos arquivos SVG que representam os elementos no modelo (view) (Figura 62), o arquivo JSON que contem todas as configurações dos stencils, suas regras, e opcionalmente um arquivo do tipo PNG contendo o ícone que representa o stencil set.

98 98 Figura 62 Estrutura de pastas do stencil set petrinets É justamente essa estrutura que foi implementada neste projeto a criação dos novos stencils set. Todo o conhecimento sobre a infraestrutura da ferramenta Oryx necessário para a continuação do projeto foi identificado, finalizando a atividade de engenharia reversa. A partir do conhecimento extraído com a aplicação da engenharia reversa, foi possível modelar um diagrama conceitual, representado na Figura 63. Neste diagrama estão contidos os elementos básicos de um stencil set, conforme apresentado nos capítulos anteriores. O stencil set pode conter zero ou mais stencils e rules. Um stencil contém zero ou mais properties e roles. Uma rule pode ser de três tipos: ConnectionRules, CardinalityRules e ContainmentRules. Cada rule define uma role que pode ser referenciada pelo stencil que passa a respeitar a regra. Figura 63 Diagrama conceitual contendo elementos básicos de um stencil set Com esse conhecimento adquirido, é possível descrever uma lista de requisitos mais detalhada, por exemplo, para poder implementar na ferramenta a linguagem do framework i*, o check list de requisitos poderia ser:

99 99 Criar plugin contendo i* o Criar elementos SVG com formato gráfico compatível ao i* o o Criar ícones para cada elemento SVG Implementar o arquivo stencil set Criar stencil para cada elemento do i* Criar regras de acordo com as regras do i* Aplicar as regras aos elementos de acordo com as regras do i* Utilizando os novos conhecimentos que possibilitaram visualizar as atividades necessárias para implementar as novas demandas na ferramenta Oryx (i* alinhado à BPMN), é possível aplicar a reengenharia reversa para customizar a ferramenta, inserindo novo código, alterando e reutilizando a codificação existente. A próxima seção descreve como foram implementados os novos requisitos e quais as novas alterações incluídas após gerar a versão 1.0 da ferramenta Reengenharia de software Esta seção apresenta como foi executado o processo de reengenharia da ferramenta Oryx. A estrutura de pastas da ferramenta é detalhada, mostrando onde se encontram as codificações no ambiente de desenvolvimento, além disso, são apresentados diagramas que demonstram as diferentes definições do Oryx e como os seus arquivos se relacionam. Este capítulo possui um enfoque na apresentação dos conceitos e infraestrutura do ambiente e seus arquivos. Na fase de reengenharia, o objetivo era desenvolver os plugins do i* e da BPMN de forma a permitir a modelagem conjunta de seus elementos. No entanto, o código do Oryx disponibilizado para download já possui uma implementação do BPMN 2.0, permitindo o seu reuso. Retornando ao assunto da codificação, conforme dito nos estudos anteriores é possível definir as atividades necessárias para alcançar os objetivos desta fase. O reuso do stencil set BPMN foi muito útil, eliminando completamente o trabalho de definição dos elementos dessa notação. Então foi apenas necessário incluir os novos stencils do i* e suas regras, além de definir os elementos gráficos e realizar as alterações necessárias para adaptar o i* ao stencil set do BPMN. O stencil set BPMN + i* foi projetado conforme o esquema apresentado na Figura 64. A maior dificuldade encontrada na implementação foi a ausência de ferramenta de debug, já que não há como acompanhar a execução do código de um

100 100 stencil set, e um pequeno erro de uma virgula ausente já faz com que a ferramenta não funcione corretamente. Stencil set +titulo +namespace +description Stencils i* +properties +roles Stencils BPMN +properties +roles Regras BPMN +connectionrules +cardinalityrules +containmentrules Regras i* +connectionrules +cardinalityrules +containmentrules Figura 64 Esquema de formação do Stencil set BPMN + i* Diversas vezes foi necessário apagar grande parte da codificação desenvolvida e reinserir novamente por partes e realizando testes de execução em paralelo para garantir que nada estivesse faltando. Neste tipo de programação, onde se trabalha com um arquivo simples de tags e sem um sistema de debug, não é seguro aplicar um grande número de modificações e posteriormente realizar testes, já que um erro inserido em algum ponto do código (mesmo que sem querer) demandará esforços maiores para ser rastreado e identificado. Os sintomas que ocorrem por problemas de codificação são os mesmos para qualquer problema inserido no stencil set. O sistema não apresenta os elementos do stencil set no ambiente Oryx ou a ferramenta simplesmente não carrega integralmente, independente de carregar os elementos do stencil set. Após a finalização do código, os stencils sofreram novas alterações para oferecer ao usuário a possibilidade de trabalhar com as notações separadamente, por exemplo, modelar um diagrama SD, SR ou utilizar unicamente a BPMN, ou ainda, na parte de integração das linguagens, incluir as visões geradas a partir da união da BPMN com SD ou da BPMN com SR. Para implementar esses alterações, foram extraídos todos os elementos do stencil set implementado até o momento. Cada diagrama (i* SD, i* SR e BPMN) foi

101 101 transformado em um único stencil set e foram criadas perspectivas na ferramenta para que o usuário possa selecionar e facilmente trocar entre os diferentes plugins. A separação dos novos stencil sets não trazem nenhuma novidade ao trabalho, a não ser pela mudança do esquema de implementação (Figura 64), no entanto, a criação de perspectivas demandou alterações em um arquivo que define as perspectivas na ferramenta e na estrutura de pastas. O Oryx possui um arquivo chamado extension.json (Figura 65), onde são configurados stencil sets que estendem a capacidade de outros stencil set considerados como principais. Estas extensões são aplicadas ao modelo quando o usuário solicita a inclusão do plugin manualmente ou quando seleciona a perspectiva predefinida que contém plugins de extensão. Figura 65 Pasta extensions contendo o arquivo extensions.json Esta estrutura de extensões foi utilizada como estratégia para a implementação das visões. Um stencil set genérico foi desenvolvido contendo o stencil básico do diagrama e o conjunto de regras genéricas que são usadas pelos stencils set que irão estendê-lo. Esse stencil set principal é iniciado na ferramenta, e as perspectivas definem os elementos que vão ser apresentados neste stencil set principal. Portanto cada stencil set implementado a partir da separação mencionada anteriormente (i* SD, i* SR e BPMN) foi configurado como uma extensão. A Figura 66 ilustra o esquema de formação do stencil set principal i*bpmn e seu relacionamento com suas extensões.

102 102 Stencil set i*bpmn +title +namespace +description +connectionrules +cardinalityrules +containmentrules i* SR Stencil set i* SD Stencil set +title +namespace +description extends extends +title +namespace +description extends i* SR Rules +connectionrules +cardinalityrules +containmentrules i* SR Stencils +properties +rules BPMN Stencil set +title +namespace +description i* SD Rules +connectionrules +cardinalityrules +containmentrules i* SD Stencils +properties +rules BPMN Rules +connectionrules +cardinalityrules +containmentrules BPMN Stencils +properties +rules Figura 66 Esquema de formação do stencil set i*bpmn a partir de extensões O arquivo extension.json é formado pelo registro do conjunto de stencils set que são utilizados como extensão e o registro das perspectivas. O registro de um stencil set é formado por titulo, namespace, descrição, definição (path para o stencil set da extensão) e o campo de extensão, onde se define o path em que se encontra o stencil set a ser estendido. O registro de uma perspectiva é composto por titulo, namespace, descrição, stencil set que vai ser estendido, o campo onde se registra quais stencils set serão incluídos na perspectiva e outro campo onde se registra quais stencils set serão removidos da perspectiva (Figura 67).

103 103 Figura 67 Exemplo do arquivo extension.json Com essas alterações também se finaliza a fase de implementação dos plugins realizada através da reengenharia de software. Uma vez que a codificação foi desenvolvida, é natural que a próxima etapa seja referente aos testes e correções. A próxima seção apresenta como foram feitos os testes partindo de um roteiro predefinido e apresenta alguns exemplos do que foi realizado. 4.3.Testes A codificação desenvolvida neste trabalho é um conjunto de especificações que são interpretadas pelo núcleo da ferramenta Oryx e geram um resultado gráfico em seu ambiente de modelagem. Para testar a codificação desenvolvida, foi escolhido o método de testes assistido, baseado em um roteiro onde são pré-registrados os resultados esperados por cada funcionalidade a ser testada. Uma vez que os resultados esperados são atingidos através do uso da funcionalidade, a função é considerada satisfatória. Caso contrário, é identificado o defeito que deve ser consertado e novamente testado ou simplesmente registrada a existência do problema, caso seja avaliado e justificado que o código não deve ser alterado neste caso. Os testes foram projetados a partir de roteiros onde se definem especificações que devem ser integralmente cumpridas ao utilizar a função na ferramenta. Os elementos alvo dos testes foram cada objeto e cada regra (de objetos) que compõem a notação definida neste trabalho (exceto os elementos BPMN reutilizados). Aqui

104 104 descreveremos apenas o roteiro de testes aplicados e alguns exemplos de testes, os resultados mais detalhados encontram-se em [Sousa&Leite12]. Como um plugin é formado por stencils e regras, basicamente foram estes os elementos testados. A especificação dos elementos é repassada para a codificação e o resultado esperado é o elemento gráfico e regras de acordo com o esperado. Para cada stencil foram testados: No caso de ser um nó, o elemento gráfico esperado, localização do texto no objeto, efeito de ampliação do objeto, regras específicas. No caso de ser um relacionamento, o elemento gráfico esperado, localização do texto no objeto, efeito de ampliação do objeto, regras específicas e regras de conexão. Nem todos os testes são aplicáveis a todos os stencils e regras, sendo neste caso, marcado como não aplicável. A sintaxe geral do programa é automaticamente verificada pelo Oryx, que somente abre o stencil set para modelagem se todas as regras de sintaxe estiverem corretas. Os testes foram divididos em dois tipos, chamados de Teste gráfico e Teste de regras, sendo que este último ainda possui variações, já que as regras foram testadas separadamente para cada situação esperada por um objeto em relação aos outros elementos que fazem parte do domínio da regra. O objetivo do teste gráfico (Tabela 17) é verificar se o elemento está de acordo com as especificações esperadas. A verificação de aceite do teste é visual e comparativa. A especificação padrão dos elementos é composta dos seguintes campos: Elemento nome do elemento na ferramenta; Formato formato gráfico do elemento; Cor cor do corpo do elemento; Texto Configuração do texto em relação ao objeto; O campo Resultado, mostra a figura que é resultante do código que foi implementado. Esta figura deverá ser comparada com a especificação para verificar se o objeto obedece a todas as especificações, o que caracteriza um teste com sucesso. Uma vez que o elemento passou no teste, o campo Teste é preenchido com OK.

105 105 Tabela 17 Teste gráfico Teste gráfico Especificação Resultado Elemento: Formato: Cor: Texto: Teste: O teste de regras do tipo Containment Rules (Tabela 18) possuem os seguintes parâmetros: elemento nome do elemento o qual a regra está atribuída; conteúdo os elementos que podem encontrar-se modelados no corpo do elemento que deve obedecer a regra. Tabela 18 Teste de regras do tipo Containment Rules Teste de regras (Containment Rules) Especificação Resultado Elemento: Conteúdo: Teste: O Teste de regras do tipo Cardinality Rules (Tabela 19) possuem os seguintes parâmetros: elemento nome do elemento o qual a regra está atribuída; elemento de entrada nome do relacionamento que chega ao elemento; Card. Entrada Cardinalidade do elemento de entrada; Elemento de saída nome do relacionamento que sai do elemento; Card. Saída Cardinalidade do elemento de saída. Tabela 19 Teste de regras do tipo Cardinality Rules Teste de regras (Cardinality Rules) Especificação Resultado Elemento: Elemento de entrada Card. Entrada: Elemento de saída: Card. Saída: Teste:

106 106 O teste de regras do tipo Connection Rules (Tabela 20) possui os seguintes parâmetros: Elemento nome do relacionamento que será avaliado; Elem. Inicial nome do elemento que deve estar na ponta inicial do relacionamento; Elem. Final nome do elemento que deve estar na ponta final do relacionamento. Tabela 20 - Teste de regras do tipo Connection Rules Teste de regras (Connection Rules) Especificação Resultado Elemento: Elem. Inicial: Elem. Final: Teste: Testes de negação das regras não serão aplicados já que o Oryx automaticamente impede a execução de regras que não estão explicitas. Por exemplo, se definir somente uma regra que relaciona o objeto A ao objeto B nesta direção, a partir do relacionamento X, não é necessário testar a conexão para a direção inversa porque ela não acontecerá, já que não está definida. A Tabela 21 e Tabela 22 apresentam dois exemplos de teste gráfico, neste caso, para elementos do i*. A tabela é dividida em duas partes, na esquerda, encontram-se as especificações do elemento, do lado direito, o elemento modelado. O teste consiste em uma avaliação visual do elemento que, uma vez modelado, apenas deve corresponder às especificações. Caso corresponda, o teste é concluído de forma positiva. Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) Teste gráfico Especificação Resultado Elemento: Agent Formato: circular Cor: cinza Texto: centralizado Teste: OK

107 107 Tabela 22 Teste gráfico para o elemento meta (Diagrama SD) Teste gráfico Especificação Resultado Elemento: Meta Formato: oval Cor: verde Texto: centralizado Teste: OK A Tabela 23 apresenta o teste para a regra Containment Rule. A configuração desta regra permite que elementos sejam modelados dentro de outros elementos, o qual se torna seu limite de mobilidade. Por exemplo, podemos citar o próprio diagrama principal que recebe os elementos de modelagem. O diagrama deve estar configurado nesta regra para todos os elementos de linguagem. No teste apresentado, foi testado o elemento AgentLane, que é uma Lane que representa um papel/agente. De acordo com a especificação da tabela, os elementos que devem ser modelados dentro da lane estão descritos no campo Conteúdo. Os elementos são: Agent, Meta, Metaflexível, Task, Resource, Critical Mark, Open Mark, Dependency. O teste consiste em inserir estes elementos na lane. Uma vez que a ferramenta permite o desenho dos elementos esperados, o teste foi realizado com sucesso. Observando o resultado do teste, verifica-se que todos os elementos esperados foram modelados corretamente no interior da lane, validando o resultado. Tabela 23 Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) Teste de regras (Containment Rules) Especificação Resultado Elemento: AgentLane Conteúdo: Agent, Meta, Meta-flexível, Task, Resource, Critical Mark, Open Mark, Dependency. Teste: OK

108 108 A Tabela 24 apresenta o teste para a regra Cardinality Rule. Esta regra define quantos relacionamentos de um dado tipo um elemento pode ter como entrada/saída. No exemplo, o relacionamento de fluxo de sequência foi testado para os eventos do tipo inicial. A cardinalidade de um evento inicial é zero, uma vez que só o processo inicia-se com ele. Portanto, para este teste, tenta-se ligar um relacionamento em direção ao evento inicial, e espera-se que a ferramenta recuse a ligação, conforme mostra o resultado do teste. A ferramenta apresenta sinais em vermelho demonstrando que a ligação não é permitida. Isso demonstra que a restrição da regra está funcionando conforme o esperado. Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial Teste de regras (Cardinality Rules) Especificação Resultado Elemento: Regra genérica (Eventos iniciais) Elemento de entrada: SequenceFlow Card. Entrada: 0 Elemento de saída: N/A Card. Saída: N/A Teste: OK A Tabela 25 apresenta o teste para a regra Connection Rule. Esta regra define quais objetos podem se relacionar. No exemplo, o teste é para o relacionamento de dependência em um diagrama SD. A especificação apresenta o elemento inicial e o elemento final, ou seja, também define a direção do relacionamento. O resultado deve apresentar os elementos relacionados, seguindo a direção correta no relacionamento.

109 109 Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento Dependency (Diagrama SD) Teste de regras (Connection Rules) Especificação Resultado Elemento: Dependecy Elem. Inicial: Agent Elem. Final: Meta Elem. Inicial: Agent Elem. Final: Meta-flexível Elem. Inicial: Agent Elem. Final: Task Elem. Inicial: Agent Elem. Final: Resource Elem. Inicial: Meta Elem. Final: Agent Elem. Inicial: Meta-flexível Elem. Final: Agent Elem. Inicial: Task Elem. Final: Agent Elem. Inicial: Resource Elem. Final: Agent Teste: OK Esta seção apresentou o roteiro de testes que foram aplicados na ferramenta e exemplificou cada tipo de teste aplicado para as diferentes regras que os elementos podem receber. Os testes completos, incluindo a listagem de erros presentes na ferramenta (e não nos plugins desenvolvidos), as dificuldades encontradas e o manual da ferramenta podem ser vistos em [Sousa&Leite12]. Os resultados dos testes foram satisfatórios resultando na possibilidade de uso integral das linguagens como extensão da ferramenta Oryx. A próxima seção apresenta o estudo de caso aplicado à proposta deste trabalho.

110 110 5 Exemplo de aplicação Este capítulo apresenta um exemplo de uso da linguagem proposta como forma de validação. Através da implementação da linguagem utilizando o potencial de extensão da ferramenta Oryx é possível demonstrar o desenvolvimento dos modelos e a integração das linguagens. Para realizar este teste, utilizamos um modelo de processo de negócio em BPMN e um modelo SR, ambos desenvolvidos por terceiros. Apesar da notação proposta neste trabalho não reutilizar integralmente todos os recursos do i* e da BPMN, principalmente no que tange a regras e relacionamentos, queremos demonstrar que partindo desses modelos, podemos introduzir as alterações/adaptações necessárias para construir um terceiro modelo que integra os dois primeiros, introduzindo relacionamentos que permitem a rastreabilidade com semântica de causa (why) e efeito (how) referenciando respectivamente a modelagem de objetivos e processes. O modelo de processo utilizado foi extraído de [Diirr10] e encontra-se modelado utilizando a notação do framework ARIS, portanto, foi necessário o trabalho de tradução do modelo de processos para a notação BPMN. Com o processo modelado em BPMN, solicitamos a um aluno de doutorado da PUC-Rio que projetasse o modelo SR do processo, tendo como fonte de informação o modelo em BPMN e uma descrição do processo. Uma vez que o modelo foi finalizado, apresentamos a linguagem de integração e solicitamos que a utilizasse, criando um Diagrama Integrado. Ao concluir o Diagrama Integrado, apresentamos nosso método de uso de indicadores e solicitamos que também fossem projetados indicadores para os objetivos que haviam sido incluídos no modelo SR, o que possibilita a verificação de alinhamento entre os modelos. Posteriormente realizamos análises no Diagrama Integrado e extraímos informações de interesse. Durante a validação, nosso papel foi apenas de instruir no uso da linguagem, da ferramenta e em dúvidas pontuais nas atividades solicitadas. As subseções seguintes detalham cada procedimento realizado nesta validação.

111 Modelo de processo O modelo de processo extraído de [Diirr10] foi modelado utilizando diagramas EPC e FAD. Primeiramente desenvolvemos em BPMN o fluxo de atividades, eventos e operadores lógicos contidos no diagrama EPC e, posteriormente, completamos o modelo com os elementos de detalhamento do fluxo de informações presentes nos modelos FAD. A descrição de alto nível do processo também foi extraída de [Diirr10], conforme transcrito a seguir: Neste processo são analisadas propostas de crédito, as quais podem ser aprovadas ou rejeitadas. Quando uma proposta de crédito é recebida, o cadastro do cliente é checado e o sistema verifica se o limite de crédito do cliente é suficiente para a concessão do crédito proposto. Se o limite for aprovado, então o sistema calcula as taxas do contrato para gerar uma proposta de contrato. Esta proposta de contrato é encaminhada a um analista de crédito que identifica necessidades de ajustes e o nível do risco inerente ao empréstimo. Se o contrato for aceitável, o cliente é contatado para avaliar o contrato. Uma vez que o contrato é aprovado, ele será ratificado. Se o contrato não for aprovado, ele será cancelado. O modelo resultante da tradução para a notação BPMN pode ser visto na Figura 68.

112 Figura 68 Processo Analisar Pedido de Crédito [adaptação de [Diirr10]] 112

113 Modelo SR O modelo SR foi desenvolvido por um aluno de doutorado da PUC-Rio a partir da leitura do modelo BPMN e sua descrição (considere uma abordagem botton-up). Nenhuma informação sobre a integração posterior dos modelos foi repassada na atividade da construção do modelo SR, logo, ficou sob a responsabilidade do aluno toda a interpretação do modelo de processo de negócio e o desenvolvimento do modelo SR. O modelo resultante é apresentado na Figura 69. Observe que existe a naturalidade de interpretar durante a tradução do modelo BPMN para o modelo SR, os papéis executores como atores, raias como pools de agentes e a dependência de artefatos/informações que são repassadas (handoff) de uma raia para outra no modelo BPMN. Figura 69 Modelo SR desenvolvido a partir do processo Analisar Pedido de Crédito

114 114 Cabe salientar que não temos o objetivo de criticar o modelo SR em relação à sua completude porque não necessitamos de um modelo plenamente detalhado. Nossos objetivos se restringem a integrar os modelos e identificar os fluxos/atividades na camada de processos que correspondem às tarefas/objetivos da camada de objetivos, visando tornar explícita a rastreabilidade entre os modelos. 5.3.Integração dos modelos Neste momento apresentamos noções gerais referentes à integração das linguagens, o método e a notação de modelagem do Diagrama Integrado. Solicitamos ao aluno que modelasse o Diagrama Integrado partindo do modelo BPMN e de seu modelo i*. Como uma forma de minimizar o esforço do aluno, solicitamos que desconsiderasse o fluxo de informações/artefatos do modelo BPMN para simplificar o modelo e facilitar a visualização e modelagem dos agrupamentos de atividades porventura necessários. Os eventos também não foram descritos, para reduzir o tamanho do modelo. A Figura 70 apresenta o Diagrama Integrado com o desenho modificado para raias horizontais descritas à esquerda, e os elementos de modelagem de objetivos à direita. Figura 70 Resultado da integração Ao integrar os modelos alguns elementos que faziam parte do modelo i* foram eliminados. Estes elementos não deixaram de ser representados, na verdade eles foram ainda mais detalhados no modelo BPMN. Um dos elementos que foram excluídos são as decomposições das tarefas. No alto nível, estes elementos poderiam

115 115 representar processos complexos, mas partindo do ponto de vista dos papéis e suas responsabilidades, os elementos folha que decompõem uma tarefa tendem a serem atividades atômicas e possuirão elementos correspondentes no diagrama BPMN. Algumas tarefas poderão ser mais abstratas, sendo detalhadas por um pequeno fluxo dentro do processo (agrupamento). Um dos maiores ganhos nesta representação é a definição da temporalidade na execução das tarefas decompostas. Além disso, outros detalhamentos serão possíveis, tais como a representação de insumos necessários para a execução das atividades e os seus produtos, descrições textuais mais elaboradas, representação de outros conceitos do negócio e regras de execução dos processos, definidas por operadores lógicos e eventos. Alguns relacionamentos meios-fim de objetivos (meta e meta-flexível) com tarefas também foram eliminados, e substituídos por relacionamentos meios-fim com agrupamentos de atividades que são executados para satisfazê-los. O agrupamento demonstra o esforço realizado no processo para satisfazer os objetivos locais. Outro elemento que pode ser eliminado são os recursos, automaticamente representados na troca de informações/artefatos entre os atores e na entrada e saída de atividades. Partindo do ponto de vista do ator Atendente, seus objetivos são Resultado da proposta seja comunicado e Condições do contrato sejam satisfeitas. Para satisfazer o objetivo Resultado da proposta seja comunicado é necessário que a tarefa Enviar resultado da proposta seja satisfeita. O processo já possui atividade semelhante com o nome de Comunicar proposta não aprovada que substituiu a tarefa sendo relacionada diretamente com o objetivo (observe que a possível tarefa de Comunicar proposta aprovada não faz parte do escopo deste processo). O objetivo Condições do contrato sejam satisfeitas é satisfeito através da tarefa Verificar aceitação do contrato, que corresponde no processo a um agrupamento que promove a atividade de avaliar com o cliente o contrato, podendo resultar na provação ou reprovação. Para atingir esse objetivo o Atendente depende do Cliente. O Cliente, por sua vez, depende do Atendente para receber a comunicação de não aprovação de sua proposta. Observe que o relacionamento de dependência pode ser aplicado tanto no modelo de objetivos como no modelo de processo. Partindo do ponto de vista do ator Crédito Direto (trata-se de um sistema), o seu objetivo principal Proposta de contrato seja gerada é satisfeito através da tarefa Gerar proposta de contrato que, por sua vez, é decomposta no objetivo Dados do cliente sejam mantidos e tarefas Comprometer limite de crédito, Calcular taxas do contrato e Gerar proposta. O objetivo Dados do cliente sejam mantidos pode ser

116 116 alcançado ao executar a tarefa Atualizar dados do cliente ou Cadastrar dados do cliente. As tarefas que decompõem a tarefa Gerar proposta de contrato encontramse em mais detalhes no modelo de processos que possui um fluxo específico agrupado que gera a proposta de contrato. O mesmo ocorre com as tarefas meio do objetivo Dados do cliente sejam mantidos. A execução de uma ou outra atividade respectiva às tarefas no modelo i* fica definida através do operador lógico e eventos no modelo de processos, demonstrando o ganho de detalhamento a partir da modelagem do fluxo. A ordem de satisfação dos objetivos (primeiro Dados do cliente sejam mantidos e depois Proposta de contrato seja gerada ) imposta no modelo i* através do relacionamento de decomposição da tarefa Gerar proposta de contrato também é expressa no processo conforme demonstra a ligação entre os agrupamentos. Partindo do ponto de vista do ator Analista de crédito, a tarefa Analisar contrato, ao ser executada de forma satisfatória, atinge o objetivo Contrato seja analisado. Essa tarefa é decomposta pelas tarefas Verificar se contrato é de risco, Verificar necessidade de ajuste do contrato e Notificar resultado da análise. A tarefa Verificar se contrato é de risco contribui positivamente para o objetivo Menor risco de crédito. Ao alinhar os modelos ambos os objetivos observou-se que o agrupamento de atividades de sua raia correspondia a ambos os objetivos do ator. Após essas alterações foi finalizada a integração, sendo posteriormente aplicada a proposta do uso de indicadores. 5.4.Modelagem dos indicadores Neste momento apresentamos nossa proposta de uso de indicadores como um recurso que permite verificar a capacidade dos modelos em atingir os seus objetivos. Como primeiro passo, solicitamos ao aluno que projetasse indicadores para os objetivos que ele definiu anteriormente. Essa atividade de projetar uma forma de medir os objetivos (que inclui a definição dos elementos que são necessários para aplicar possíveis cálculos ou gerar indícios suficientes para comprovar que o esperado pelo objetivo pode ser produzido pelo processo) auxiliou o aluno a conhecer mais detalhadamente os objetivos que ele estabeleceu. Após a definição dos indicadores, atualizamos o Diagrama Integrado (Figura 71). Os indicadores, seus respectivos objetivos e descrição encontram-se na Tabela 26.

117 117 Tabela 26 Detalhamento dos indicadores inseridos no Diagrama Integrado Objetivo Indicador Descrição Condições do contrato sejam verificadas Resultado da proposta seja comunicado Proposta de contrato seja gerada Dados do cliente sejam mantidos Menor risco de crédito Contrato seja analisado Produção de documento de verificação do contrato Emissão de comunicação de resultado das propostas Produção de propostas de contratos Razão de acessos a cadastros do cliente Coeficiente de risco de crédito Percentual de contratos analisados Mede o percentual de documentos de verificação de contrato produzidos em relação ao numero de contratos analisados sem restrição. O valor esperado é de 100%. O calculo é: numero de documentos de verificação do contrato/numero de contratos analisados sem restrição. Mede o percentual de comunicados emitidos em relação ao numero de propostas canceladas. O valor esperado é de 100%. O calculo é: numero de comunicações emitidas / numero de cancelamentos de proposta. Verifica se foi gerada a proposta de contrato respectivo ao cliente que teve o crédito comprometido, de forma a evidenciar que a proposta de contrato foi produzida para o cliente que possui crédito. Verifica se houve o acesso ao cadastro do cliente para cada proposta recebida de forma a evidenciar que o cadastro foi analisado. Deve haver um acesso registrado no log do sistema respectivo a cada proposta recebida. Calcula o coeficiente de risco de crédito baseado em heurísticas que utiliza o checklist como insumo. Mede o percentual de contratos analisados em relação ao número de propostas de contrato geradas. O valor esperado é de 100%. O calculo é: numero de contratos analisados / número de propostas geradas. Figura 71 Inclusão de indicadores no diagrama integrado

118 118 Após a atualização do modelo com os indicadores, foi solicitado ao aluno que identificasse no processo onde ocorre a produção dos elementos necessários para medir os indicadores, e então atualizasse novamente o Diagrama Integrado inserindo os respectivos recursos críticos (Figura 72). Figura 72 Diagrama Integrado contemplando indicadores e recursos críticos Após modificar o diagrama inserindo os recursos críticos, consideramos o teste de integração finalizado. A próxima subseção apresenta como extrair informações importantes através da análise do Diagrama Integrado Análise e desenvolvimento de relatórios Uma vez que os modelos encontram-se prontos, torna-se possível a análise e a extração de informações sobre os elementos envolvidos. Inicialmente temos o relacionamento explicito entre os objetivos e seus processos, dos indicadores e seus elementos necessários, e das atividades com os recursos críticos. A partir disso é possível identificar, por exemplo, quais objetivos podem ser medidos pelo processo e quais não podem; os papéis e atividades envolvidos na produção dos recursos críticos; correlação entre papéis e recursos críticos; e verificação dos processos que produzem os recursos críticos desejados. As tabelas Tabela 27, Tabela 28, Tabela 29, Tabela 30 e Tabela 31 consolidam informações contidas no diagrama. A Tabela 27 contém o resumo dos principais elementos que se relacionam no processo que são: o próprio processo, seus objetivos, as atividades que são executadas como esforço para atingir os objetivos, os indicadores associados aos objetivos e os recursos críticos necessários para gerar os indicadores.