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
138
Embed
Henrique Prado Sousa Integrando modelagem intencional à ...julio/diss-henrique.pdf · modelagem de objetivos a uma linguagem de processos de negócio e provemos os elementos e métodos
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
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 2010. 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. – 2012. v., 138 f,; Il. ; 30 cm
1. Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, 2012.
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
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
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, 2012. 138p. 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
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
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, 2012. 138p. 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
Keywords
Requirements engineering, Business processes modeling, Objectives
modeling, BPM, BPMN, i*, Integration of processes and goals, alignment of
Tabela 1 - Elementos de um diagrama de processo de negócio em UML................... 25 Tabela 2 – Elementos de um diagrama de objetivos em UML .................................... 28 Tabela 3 – Recursos e regras compõem todos os diagramas ..................................... 31 Tabela 4 – Elementos básicos da BPMN .................................................................... 34 Tabela 5 – Elementos de um modelo SD .................................................................... 39 Tabela 6 – Elementos do modelo SR .......................................................................... 43 Tabela 7 – Elementos do modelo GRL ....................................................................... 47 Tabela 8 – Elementos do modelo UCM....................................................................... 48 Tabela 9 – Elementos de um diagrama de objetivos ................................................... 55 Tabela 10 – Conexões permitidas entre os elementos do diagrama de objetivos ....... 55 Tabela 11 – Comparação entre as linguagens de modelagem de processos ............. 63 Tabela 12 – Comparação entre as linguagens de modelagem de objetivos ................ 63 Tabela 13 – Similaridades entre elementos do i* e BPMN .......................................... 65 Tabela 14 – Novos elementos incluídos ao Diagrama Integrado ................................ 78 Tabela 15 – Elementos do Diagrama de Indicadores .................................................. 81 Tabela 16 – Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 – Teste gráfico ......................................................................................... 105 Tabela 18 – Teste de regras do tipo Containment Rules .......................................... 105 Tabela 19 – Teste de regras do tipo Cardinality Rules .............................................. 105 Tabela 20 - Teste de regras do tipo Connection Rules ............................................. 106 Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) ............................. 106 Tabela 22 – Teste gráfico para o elemento meta (Diagrama SD) ............................. 107 Tabela 23 – Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) ........................................................................................................................... 107 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) ............................................................ 109 Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado .......... 117 Tabela 27 – Resumo de associação entre principais elementos ............................... 119 Tabela 28 – Tabela de descrição de indicadores ...................................................... 120 Tabela 29 – Tabela de descrição do recurso crítico .................................................. 120 Tabela 30 – Detalhamento de recursos críticos não identificados no processo......... 121 Tabela 31 – Correlação entre recursos críticos e papéis responsáveis ..................... 121
12
Lista de tabelas
Tabela 1 - Elementos de um diagrama de processo de negócio em UML................... 25 Tabela 2 – Elementos de um diagrama de objetivos em UML .................................... 28 Tabela 3 – Recursos e regras compõem todos os diagramas ..................................... 31 Tabela 4 – Elementos básicos da BPMN .................................................................... 34 Tabela 5 – Elementos de um modelo SD .................................................................... 39 Tabela 6 – Elementos do modelo SR .......................................................................... 43 Tabela 7 – Elementos do modelo GRL ....................................................................... 47 Tabela 8 – Elementos do modelo UCM....................................................................... 48 Tabela 9 – Elementos de um diagrama de objetivos ................................................... 55 Tabela 10 – Conexões permitidas entre os elementos do diagrama de objetivos ....... 55 Tabela 11 – Comparação entre as linguagens de modelagem de processos ............. 63 Tabela 12 – Comparação entre as linguagens de modelagem de objetivos ................ 63 Tabela 13 – Similaridades entre elementos do i* e BPMN .......................................... 65 Tabela 14 – Novos elementos incluídos ao Diagrama Integrado ................................ 78 Tabela 15 – Elementos do Diagrama de Indicadores .................................................. 81 Tabela 16 – Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 – Teste gráfico ......................................................................................... 105 Tabela 18 – Teste de regras do tipo Containment Rules .......................................... 105 Tabela 19 – Teste de regras do tipo Cardinality Rules .............................................. 105 Tabela 20 - Teste de regras do tipo Connection Rules ............................................. 106 Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) ............................. 106 Tabela 22 – Teste gráfico para o elemento meta (Diagrama SD) ............................. 107 Tabela 23 – Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) ........................................................................................................................... 107 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) ............................................................ 109 Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado .......... 117 Tabela 27 – Resumo de associação entre principais elementos ............................... 119 Tabela 28 – Tabela de descrição de indicadores ...................................................... 120 Tabela 29 – Tabela de descrição do recurso crítico .................................................. 120 Tabela 30 – Detalhamento de recursos críticos não identificados no processo......... 121 Tabela 31 – Correlação entre recursos críticos e papéis responsáveis ..................... 121
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
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
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
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
A complexidade do domínio, bem como a sua importância, justifica a
continuidade de estudos na área.
1.1. 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 EPC1), 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
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, encontra-
se 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.
1.2. 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
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
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.
1.3. 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
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.
1.4. 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
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.
2.1. 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
“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
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.
2.2. 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
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
2.2.1.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
Um processo é uma descrição de um conjunto de atividades relacionadas que, quando executadas corretamente, irão satisfazer um objetivo explícito.
Atividade
(Processo atômico) Atividade
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 Um objeto entregue por um processo para a Assembly Line.
Objeto-vindo de-Assembly Line
Objeto Um objeto que vai da Assembly Line para um processo.
26
Fluxo de processo Fluxo de controle
Um fluxo de controle de processo com uma condição
Fluxo de recurso Fluxo de objeto
Fluxo de objeto mostra que um objeto é produzido por um processo e consumido por outro.
Fluxo de recursos não-causal
Fluxo de objeto
Fluxo de objeto não-causal mostra que um objeto pode ser produzido por um processo e consumido por outro.
Controle de processo
Fluxo de objeto Mostra que um processo é controlado por um objeto.
Conexão de objetivo
Dependência
Aloca um objetivo a um processo.
Processo de suprimento
Fluxo de objeto Mostra que um processo é suprido por um objeto.
Processo de decisão
Decisão
Ponto de decisão entre dois ou mais processos.
Processos de união e bifurcação
Bifurcação e União Bifurcação e união de processos.
Receber eventos de negócio
Recepção de sinal
Mostra um recebimento de evento de negócio.
Enviar eventos de negócio
Emissão de sinal
Mostra um envio de evento de negócio.
Assembly Line Pacote
As Assembly Lines sincronizam e suprem os processos em termos de objetos.
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.
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
Recurso abstrato Classe
Um recurso abstrato é algo intangível, por exemplo, conceitos matemáticos.
Pessoa Classe
Um recurso físico que específica um ser humano.
Recurso físico Classe
Um recurso físico que especifica documentos, máquinas (não humano).
Evento de negócio Sinal
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
Figura 6 – Exemplo de objetivo relacionado ao processo [Eriksson&Penker00]
2.2.2.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 Classe
Denota os estados de desejo, o que significa que os objetivos motivam ações para alterar estados na direção desejada.
Problema Nota
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
A causa pode ser removida se uma medida é alcançada e certos pré-requisitos são validos.
Dependência
de objetivo Dependência
Objetivos são organizados em hierarquias de dependência nas quais um ou alguns objetivos são dependentes de subobjetivos.
Objetivo
contraditório Associação
Objetivos podem ser contraditórios, mas devem ser cumpridas.
Decomposição de objetivo incompleta
Dependência Objetivos são organizados em hierarquias de dependência que algumas vezes são incompletas.
Decomposição de objetivo completa
Dependência
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
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 500.000. 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
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.
2.3. 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
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
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.
2.3.1. 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
2.3.2.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].
2.3.3.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
Figura 10 – Exemplo de processo colaborativo
2.3.4. 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
Uma atividade pode ser atômica ou não atômica (composta).
Operador lógico
Um operador lógico é usado para controlar divergência e convergência nos fluxos sequenciais de um processo.
Fluxo de sequencia Um fluxo de sequencia é usado para mostrar a ordem das atividades que serão
35
executadas no processo.
Fluxo de mensagem
Um fluxo de mensagem é usado para mostrar a passagem de mensagens entre os participantes.
Associação
Uma associação é usada para ligar informação e artefatos de forma gráfica.
Pool
Representação gráfica de um participante em um modelo.
Lane
Subpartição dentro de um processo ou Pool que estende toda a extensão do processo.
Objeto de dados
Objetos de dados que proveem informação sobre o que as atividades necessitam para serem executadas ou o que elas produzem.
Mensagem
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
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.
2.4. 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
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.
2.4.1. 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
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
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
Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito.
Meta-flexível
Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador.
Tarefa
Representa uma unidade de trabalho a ser executada.
Recurso
Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos.
Dependência
Representa um relacionamento de dependência.
Marcação de crítico
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 de aberto
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
A Figura 16 apresenta um exemplo de um modelo SD.
Figura 16 – Exemplo de diagrama SD [Adaptação de [Susi05]]
2.4.2. 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
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
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 metas-
flexí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 Means-
end e herda as suas características [Oliveira10], entretanto, por relacionar
especificamente os elementos tarefa e meta-flexível a outro elemento do tipo meta-
flexível, recebe labels que expressam o significado de contribuição. A Figura 20
apresenta esses relacionamentos.
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
Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito.
Meta-flexível
Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador.
Tarefa
Representa uma unidade de trabalho a ser executada.
Recurso
Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos.
Dependência
Representa um relacionamento de dependência.
Marcação de crítico
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 de aberto
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.
Decomposição de tarefa
Representa um relacionamento que expressa a decomposição de uma tarefa em outros elementos.
Meios-fim Representa um relacionamento que expressa a ligação entre um fim e um meio
44
de alcançá-lo.
Contribuição positiva
Representa um relacionamento que expressa contribuição positiva para um meta-flexível.
Contribuição negativa
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
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).
2.5. 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
2.5.1.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
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
Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito.
Meta-flexível
Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador.
Tarefa
Representa uma unidade de trabalho a ser executada.
Recurso
Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos.
Crença
Raciocínio ou argumentação associada a uma contribuição ou uma relação.
Dependência
Representa um relacionamento de dependência.
Decomposição
Define o que é necessário para uma tarefa ser executada.
Contribuição
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).
Correlação
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
2.5.2.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
Locais onde, por exemplo, procedimentos, atividades e funções são necessários.
Caminhos
Conecta pontos iniciais a pontos finais e pode ligar responsabilidades em um caminho causal.
Stub estático
Representa relacionamento estático com outro diagrama.
Stub dinâmico
Representa relacionamento dinâmico com outros diagramas.
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
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.
2.5.3.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
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
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.
2.6.1.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).
Figura 28 – Exemplo de modelo VAC [Sousa10]
Analisar pedido de créditoGerir solicitações de pedido de
crédito
Gerenciar contratos de crédito
em vigor
Realizar empréstimos para
pessoa física
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
Porcentagem de
perda em
sinistros
Quantidade de
contratos
fechados
Porcentagem de
trabalhadores da
classe C
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].
2.6.2.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.
Figura 29 – Exemplo de modelo EPC [Sousa10]
Organizational el... .
Ca
rrie
s o
ut &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sC
arr
ies
ou
t &
Su
pp
ort
sO
the
r
Crédito e taxascontratuais
Receber propostade crédito
Proposta de
crédito recebida
SYS
Verificar situação
cadastral do cliente
SYS
Verificar limite decrédito do cliente
Limite aprovado
Limite não
aprovado
SYS
Cancelar proposta
Comunicar limitenão aprovado
Limite nãoaprovado
comunicado
SYS
Determinar taxa dejuros a ser
cobrada do cliente
Analisar contrato
Necessidade deajuste do
contrato nãoidentificada
Contrato derisco
identificado
Necessidade deajuste docontrato
identificada
SYS
Cancelar contratode risco
Alterar propostade crédito
Proposta decrédito alterada
Contrato derisco cancelado
Aprovar contratoContrato
efetivado
Montar contrato
SYS
Para cada tipo de imposto
Calcular alíquotade imposto
Propostacancelada
Crédito Direto
54
2.6.3.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”.
Figura 30 – Exemplo de modelo FAD [Sousa10]
2.6.4.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
Verificar limite de
crédito do cliente
Crédito DiretoProposta de
crédito
Cadastro do
cliente
Créditosconcedidos
BDClienteProposta de
crédito
Verificação de limite de
crédito
Verificar limite
de crédito decliente
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
O objetivo pode ser decomposto em subobjetivos e deve estar relacionado direta ou indiretamente a um processo.
Processo
Um processo deve ter um ou mais objetivos relacionados.
Fator crítico de sucesso
(FCS)
O fator crítico de sucesso é relacionado ao objetivo e representa algo que deve ser tratado para que o objetivo seja alcançado.
Produto/Serviço
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”.
Objective
Process
Critical factor
Product/Service
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
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.
2.7. 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.
2.7.1.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
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
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
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
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
5.1.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]]
113
5.2.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
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
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
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” encontram-
se 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
Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado
Objetivo Indicador Descrição
Condições do contrato sejam
verificadas
Produção de documento de verificação do
contrato
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.
Resultado da proposta seja comunicado
Emissão de comunicação de
resultado das propostas
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.
Proposta de contrato seja
gerada
Produção de propostas de
contratos
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.
Dados do cliente sejam
mantidos
Razão de acessos a cadastros do
cliente
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.
Menor risco de crédito
Coeficiente de risco de crédito
Calcula o coeficiente de risco de crédito baseado em heurísticas que utiliza o checklist como insumo.
Contrato seja analisado
Percentual de contratos
analisados
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
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.
5.5. 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.
119
Tabela 27 – Resumo de associação entre principais elementos
Elemento Descrição
Processo Analisar pedido de crédito
Objetivo associado Condições do contrato sejam verificadas
Atividades associadas Verificar condições de contrato com o cliente; Aprovar contrato; Cancelar contrato;
Indicadores associados Produção de documento de verificação do contrato;
Recursos críticos associados Documento de verificação do contrato; Proposta de contrato analisada (sem
restrição);
Objetivo associado Resultado da proposta seja comunicado
Atividades associadas Comunicar proposta não aprovada;
Indicadores associados Emissão de comunicação de resultados das propostas
Recursos críticos associados Proposta de crédito (cancelada); Comunicado de proposta não aprovada;
Objetivo associado Proposta de contrato seja gerada
Atividades associadas
Verificar cadastro do cliente; Atualizar cadastro do cliente; Cadastrar cliente;
Verificar limite de crédito do cliente; Cancelar proposta de crédito; Comprometer
limite de crédito; Calcular taxas do contrato; Determinar taxas de juros a ser
cobrada; Gerar proposta de contrato;
Indicadores associados Produção de propostas de contrato;
Recursos críticos associados Proposta de contrato;
Objetivo associado Dados do cliente sejam mantidos
Atividades associadas Verificar cadastro do cliente; Atualizar cadastro do cliente; Cadastrar cliente;
Indicadores associados Percentual de acessos a cadastros de cliente
Recursos críticos associados Logs de acesso ao cadastro do cliente; Proposta de crédito (recebida);
Objetivo associado Menor risco de crédito
Atividades associadas Analisar contrato; Alterar proposta de crédito; Cancelar contrato de risco;
Comunicar não aprovação de contrato de risco;
Indicadores associados Coeficiente de risco de crédito;
Recursos críticos associados Checklist de análise de contrato;
Objetivo associado Contrato seja analisado
Atividades associadas Analisar contrato; Alterar proposta de crédito; Cancelar contrato de risco;
Comunicar não aprovação de contrato de risco;
Indicadores associados Percentual de contratos analisados;
Recursos críticos associados Proposta de contrato; Proposta de contrato (analisada);
A Tabela 28 apresenta como pode ser realizada a descrição detalhada dos
indicadores. Essas informações podem ser preenchidas na própria ferramenta que
oferece os respectivos campos como atributo dos indicadores. A tabela é composta
por nome e descrição do indicador, objetivo associado, o valor alvo que o indicador
deve apresentar que é esperado pelo objetivo, o responsável por gerir o indicador, os
recursos críticos necessários como fonte de informação, as atividades que geram
120
esses recursos, a unidade de medida do valor produzido pelo indicador, a
periodicidade em que ele é calculado e a fórmula de cálculo.
Tabela 28 – Tabela de descrição de indicadores
Indicador Descrição
Nome Produção de documento de verificação do contrato
Descrição Mede o percentual de documentos de verificação de contrato produzidos em
relação ao numero de contratos analisados sem restrição.
Objetivo Condições do contrato sejam verificadas
Valor alvo O valor esperado é de 100%.
Responsável Atendente
Recursos críticos Documento de verificação do contrato; Proposta de contrato analisada (sem
restrição);
Atividades de origem Verificar condições de contrato com o cliente; Analisar contrato;
Unidade de medida %
Peridiocidade A cada instância do processo em que for gerado um contrato sem restrição.
Fórmula de cálculo O calculo é: numero de documentos de verificação do contrato/numero de
contratos analisados sem restrição.
A Tabela 29 apresenta detalhes sobre os recursos críticos. Além do nome e da
descrição, as informações mais importantes são quais processo e atividades geram
esses recursos, uma vez que essas merecem acompanhamento especial porque
possuem relacionamento direto com a satisfação de objetivos.
Tabela 29 – Tabela de descrição do recurso crítico
Recurso crítico Descrição
Nome Proposta de contrato
Descrição
Representa a proposta de contrato, contendo: código da proposta de crédito; nome
do cliente; CPF; endereço do cliente; telefone do cliente; lista de peças; valor a ser
financiado; número de parcelas; taxa de juros; valor das taxas do contrato; para
cada parcela; data a ser realizado o pagamento; valor a ser pago; juros
correspondentes à multa por atraso; situação.
Processos que geram o
recurso crítico Analisar pedido de crédito
Atividades que geram o
recurso crítico Gerar proposta de contrato
A Tabela 30 lista todos os recursos críticos que não foram identificados nos
processos (baseado na necessidade dos indicadores). Os campos “Processo que
geram o recurso crítico” e “Atividades que geram o recurso crítico” evidenciam a
produção desses elementos em locais distintos ao processo avaliado.
121
No caso do processo utilizado nos nossos testes, verifica-se de acordo com a
Tabela 30 a ausência de três recursos críticos (Documento de verificação do contrato,
Logs de acesso ao cadastro do cliente, Checklist de análise de contrato). Como não
estudamos todo o domínio referente ao negócio que o processo “Analisar pedido de
crédito” compõe, não podemos afirmar se existem outros processos e atividades que
possuem esses recursos críticos.
Neste caso, esses recursos críticos podem ser implementados posteriormente
em uma versão “to-be” deste processo. O impacto da ausência desses elementos é
explicado no capítulo 3.4.
Tabela 30 – Detalhamento de recursos críticos não identificados no processo
Recurso crítico não identificado
Descrição
Nome Documento de verificação do contrato
Processos que geram o recurso crítico -
Atividades que geram o recurso crítico -
Nome Logs de acesso ao cadastro do cliente
Processos que geram o recurso crítico -
Atividades que geram o recurso crítico -
Nome Checklist de análise de contrato
Processos que geram o recurso crítico -
Atividades que geram o recurso crítico -
A Tabela 31 evidencia a responsabilidade dos papéis em relação à produção
dos recursos críticos ao correlacioná-los. Os atores envolvidos na produção destes
recursos possuem relação mais forte com os objetivos do processo (até mesmo se
esses recursos críticos forem utilizados em outros processos). Essa tabela também
evidencia os recursos que não são produzidos por nenhum ator listado.
Tabela 31 – Correlação entre recursos críticos e papéis responsáveis
Recurso crítico Ator
Nome Atendente Crédito direto Analista de crédito
Documento de verificação do contrato - - -
Proposta de contrato analisada (sem
restrição) - - x
Proposta de crédito (cancelada) - x -
Comunicado de proposta não aprovada x - -
Proposta de contrato - x -
122
Logs de acesso ao cadastro do cliente - - -
Proposta de crédito (recebida) - x -
Checklist de análise de contrato - - -
Proposta de contrato - x -
Proposta de contrato (analisada) - - x
123
6 Conclusão
Este capítulo apresenta a conclusão do trabalho que é composta por um resumo
geral, comparação com trabalhos relacionados e trabalhos futuros.
6.1.Resumo
A modelagem de processos de negócio é um recurso importante para as
organizações porque registra informações desde a camada estratégica até as tarefas
no nível operacional, facilitando o estudo do negócio e posteriores modificações de
melhoria. Ao mesmo tempo, a engenharia de requisitos pode utilizar este artefato
como insumo para estudo do domínio e elicitação de requisitos.
Entretanto, é possível que exista o desalinhamento entre os processos de
negócio e os objetivos organizacionais, o que poderia conduzir à modelagem de um
artefato correto, porém representando um processo que contém deficiências em sua
projeção operacional, proposta como solução às necessidades da organização. O uso
deste artefato como insumo para elicitação de requisitos provavelmente resultará no
desenvolvimento de software também desalinhado aos objetivos organizacionais.
As ferramentas de suporte, linguagens e notações de modelagem de processos
e objetivos deixam lacunas quanto à necessidade de verificar se os processos
condizem com os objetivos, e a maioria não permite registrar a rastreabilidade entre os
modelos, além de existir maior direcionamento das ferramentas em registrar o fluxo de
atividades da visão operacional em relação ao nível estratégico do negócio.
Baseado nisso, propomos a integração de uma linguagem de modelagem de
processos a uma linguagem de modelagem de objetivos. Para isso avaliamos um
conjunto de linguagens de modelagem de processos e objetivos, sendo o resultado
desta seleção a BPMN e o framework i*.
Através do reuso de seus elementos, projetamos uma arquitetura de negócio
integrando os recursos do framework i* na camada de objetivos e os recursos da
BPMN na camada de processos. A integração gerou uma nova linguagem adicionada
de novos elementos e modelos capazes de representar a rastreabilidade entre
objetivos de diferentes níveis de abstração (elementos i*) com as respectivas
atividades (elementos BPMN) que representam o esforço dentro dos processos para
satisfazer os objetivos.
124
Com a introdução da modelagem da intencionalidade dentro do contexto de
processos de negócio, foi adicionada à linguagem a capacidade de representar metas
e metas-flexíveis no nível operacional, unindo em um mesmo modelo (Diagrama
Integrado) informações sobre as questões “o que?”, representada pelos objetivos, e o
“como?”, representada pelas atividades de processo. O relacionamento direto através
de links meios-fim entre a intencionalidade dos atores dentro do processo e como eles
são executados, permitem verificar não somente o fluxo de atividades de forma
temporal, mas também o raciocínio utilizado pelo ator através dos operadores lógicos,
eventos e regras de negócio, para atingir seus objetivos. Isso só foi possível com a
inclusão do relacionamento entre os modelos, que além de garantir a rastreabilidade,
inclui o potencial da BPMN na modelagem de processos e também os elementos
extras que incluímos nesta nova linguagem.
Outra proposta deste trabalho foi o uso de indicadores como forma de verificar a
capacidade dos modelos em satisfazer seus objetivos. A proposta consiste em
relacionar aos objetivos o conjunto de indicadores necessários para medi-lo e, ao
mesmo tempo, relacionar aos indicadores os elementos de negócio necessários para
que eles possam ser calculados. Esses elementos de negócio (os quais chamamos de
recursos críticos) são rastreados nos processos e, uma vez que não se encontram
disponíveis, consideramos que foi identificado o desalinhamento entre a camada de
objetivos e a camada de processos. Isso ocorre porque na camada de objetivos um
conjunto de recursos críticos são esperados como produtos dos processos que
evidenciam a satisfação de seus objetivos. Entretanto, considerando a ausência desse
elemento na camada de processos, não é possível garantir o cálculo dos indicadores
que medem os objetivos através da modelagem (pode ser que a instância do processo
atinja os objetivos, porém não poderíamos saber sem calcular os indicadores).
A rastreabilidade inserida entre a camada de objetivos organizacionais e a
camada de objetivos de baixo nível referente aos atores, tornou possível identificar
mais facilmente possíveis impactos, desvios e suas motivações, isso porque os
objetivos de baixo nível nada mais são do que a decomposição dos objetivos de alto
nível, porém, esses objetivos são modelados a partir da visão dos atores. Esses
objetivos de baixo nível possuem relações com as atividades do processo que são
executadas para satisfazer os objetivos do ator, o que consequentemente, contribuirá
para os objetivos do negócio.
Um protótipo que permite o uso da linguagem proposta foi desenvolvido a partir
do reuso da codificação (código aberto) da ferramenta Oryx. Este protótipo permitiu a
validação da linguagem de forma gráfica e lógica.
125
6.2.Comparação com trabalhos relacionados
Em [Cardoso10] são mapeadas as relações semânticas dos elementos do
framework ARIS e da linguagem de modelagem de objetivos Tropos como uma
proposta de integração. Eles utilizam a Ontologia de Fundamentação Unificada (UFO)
para se apoiar na interpretação dos conceitos. Nosso trabalho vai além do
mapeamento semântico porque não somente correlacionamos os elementos de
conceitos semelhantes entre as linguagens, mas reutilizamos seus elementos para
gerar uma nova arquitetura e método de modelagem. Além disso, utilizamos outras
linguagens: o framework i* (a qual Tropos também se baseia) e a BPMN (que é um
padrão internacional aberto desenvolvido pela OMG). Não consideramos necessária a
utilização de uma abordagem ontológica porque no nosso caso as semelhanças entre
as definições dos elementos do framework i* e BPMN são diretas. Nosso objetivo
também não era apenas apontar semelhanças entre os conceitos das linguagens, mas
reutilizar, descartar e criar qualquer elemento necessário para representar a nossa
visão de arquitetura.
Em [Cardoso11] são propostas taxonomias para modelos de objetivos de
negócio com o propósito de “harmonizar” as divergências existentes entre o domínio
dos objetivos e o domínio dos processos que determinam o desalinhamento entre
eles. Após a atividade de harmonização, espera-se que seja possível projetar o
alinhamento dos modelos com maior facilidade, uma vez que as
alterações/adaptações necessárias para alinhar ambos os domínios (processos e
objetivos) foram realizadas. A taxonomia qualifica diversos tipos de objetivos e
categorias e suas implicações na estrutura dos processos de negócio que apoiam
esses objetivos.
Nossa proposta difere primeiramente porque consideramos objetivos
qualificados somente como metas e metas-flexíveis uma vez que todos os objetivos
podem ser enquadrados dentro desta perspectiva que é mais simples e tradicional.
Outra diferença é que nossa proposta de alinhamento entre objetivos e
processos não está restrita a qualificação de objetivos porque ela se baseia no
conjunto de relações “indicadores com objetivos” e “recursos críticos com indicadores”,
para representar os elementos que o processo deve produzir, de modo a evidenciar
que o objetivo está sendo alcançado e garantir que os indicadores possam ser
calculados.
Além disso, o relacionamento entre objetivos e atividades no Diagrama Integrado
é possibilitado pelas relações entre os objetivos do negócio e objetivos dos atores. Os
objetivos do negócio estão em nível mais abstrato, e de fato, podem ser decompostos
126
em objetivos mais específicos que direcionam as tarefas dos atores ao longo do
processo. Esses objetivos são identificados mais facilmente ao considerar a visão do
ator/agente, partindo de seu entendimento sobre os papéis e responsabilidades que
desempenha no contexto organizacional. Desvios de entendimento podem ser
identificados ao modelar esses objetivos enquanto são obtidas as informações do
próprio papel executor, durante a modelagem dos processos.
Portanto, o relacionamento entre os elementos citados anteriormente mostra-se
de certa forma com naturalidade - desde que objetivos e processos estejam alinhados
- facilitando análises mais aprofundadas quando se deseja relacionar elementos no
baixo nível (atores, atividades, informações) com elementos do alto nível (objetivos
organizacionais e indicadores). A partir destas relações, não identificamos a
necessidade de uma fase de harmonização entre processos e objetivos como requisito
facilitador para realização de atividades de alinhamento, uma vez que, se os atores
não podem alcançar seus “objetivos locais” (por não poder realizá-lo, e não por
insatisfação de possíveis métricas) e não produzem os elementos previstos nos
indicadores, simplesmente consideramos o processo incapaz de atingir tais objetivos,
tonando-se necessária a sua revisão.
O trabalho de [Shamsaei10] apresenta propostas na linha de indicadores com o
objetivo de garantir o alinhamento dos processos de negócio com regras internas
(definidas pela organização) e externas (por exemplo, normas e leis), além disso,
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. A proposta utiliza a extensão da
notação URN que oferece o recurso de indicadores, os quais possibilitam a medição
do alinhamento. O produto da aplicação do método é o nível do alinhamento entre
processos e regras, bem como a identificação dos processos que necessitam de
melhoramento. Nossa proposta também aplica o uso de indicadores, porém de uma
forma diferente. Nosso objetivo é oferecer um recurso que permita em tempo de
modelagem (ou no nível de modelagem) identificar objetivos que não poderão ser
medidos e/ou satisfeitos pela ausência de componentes “chave” nos processos. Não
nos limitamos a análises de regras, mas de objetivos de qualquer natureza que
possam ser medidos através dos indicadores.
Nosso método também permite identificar onde se encontram os elementos
utilizados como insumo pelos indicadores nas atividades do processo e seus
respectivos responsáveis através do rastreamento pelo uso de objetos especiais
(recursos críticos). Com isso, torna-se mais fácil identificar deficiências, como também
o impacto de possíveis mudanças nos objetivos estratégicos.
127
6.3.Contribuições para Transparência do Processo
[Cappelli08], [Leal10] realizam estudos aplicando o conceito de Transparência
(definido por [GupoERPuc12]), no domínio de processos. Neste trabalho, definimos
uma linguagem de modelagem que favorece a análise do alinhamento dos processos
e seus objetivos, sendo que esta facilitação é possibilitada por efeitos da
Transparência no modelo de processo de negócio. Esta seção apresenta análises
sobre as contribuições deste trabalho para a Transparência do Processo.
Segundo [GupoERPuc12], Transparência pode ser qualificada como uma meta-
flexível que possui relações de contribuição com outras metas-flexíveis. O seguinte
grafo SIG (Softgoal Interdependency Graph) [Chung00] foi definido demonstrando
essas relações (Figura 73):
Figura 73 - Gráfico de interdependência de metas de transparência - Softgoal Interdependency
Graph (SIG) [GupoERPuc12].
O relacionamento entre as metas-flexíveis é de "help" e indica que caso essa
meta-flexível sofra contribuições positivas, todos os níveis superiores que estão
ligados pelo link "help" também serão promovidos positivamente (o contrário também é
verdadeiro). As atividades que ao serem executadas contribuem positivamente para
os determinados atributos são chamadas “Operacionalização”. Estas atividades
implementam o requisito não funcional, ou seja, são o meio operacional de satisfazê-lo
[GupoERPuc12].
Em [Leal10], observa-se ao operacionalizar certas metas-flexíveis em processos
de negócio que, dependendo dos resultados gerados pela solução aplicada, é possível
surgir "efeitos colaterais" capazes de gerar relacionamentos implícitos entre as metas-
flexíveis com contribuições tanto positivas quanto negativas. Em outras palavras, ao
operacionalizar uma meta-flexível, é possível que o resultado produzido contribua
positivamente para a meta-flexível visada inicialmente, porém, essa mesma
operacionalização poderá impactar outras meta-flexíveis, tanto de forma positiva
quanto de forma negativa, o que consequentemente será refletido para a
Transparência. Portanto o Grafo de Transparência apesar de relacionar todos os seus
128
elementos do ponto de vista da contribuição positiva, pode sofrer mutações e gerar
diversos relacionamentos implícitos (desejáveis ou não) baseado nas diferentes
operacionalizações. Neste trabalho analisamos apenas as contribuições positivas
explícitas.
Analisamos as contribuições da linguagem para alguns dos nós da árvore que
consideramos mais pertinentes ao contexto, são eles: Informatividade, Entendimento e
Auditabilidade.
Em “Informatividade”, consideramos que contribuímos positivamente para o
atributo Completeza (definido como “Capacidade de não faltar nada do que pode ou
deve ter”) através do Diagrama Integrado, uma vez que ele permite o registro de todos
os elementos da linguagem, desde os níveis abstratos até o nível operacional,
expondo também os relacionamentos entre a camada de objetivos e a camada e
processos. Neste modelo, preferencialmente todos os elementos envolvidos devem
ser modelados e os objetivos devem ter suas relações registradas com as respectivas
atividades que foram projetadas para satisfazê-los.
Com isso, também contribuímos para “Entendimento” ao afetar seus atributos
”Compositividade” (definido como “Capacidade de construir ou formar a partir de
diferentes partes”) e “Dependência” (definido como “Capacidade de identificar a
relação entre as partes com um todo”). Ao inserir informações particulares e de
composição/decomposição, por exemplo, “relacionamento de objetivos locais com as
respectivas atividades que o satisfazem” e “relacionamento entre objetivos
estratégicos e objetivos locais”, contribuímos com o atributo “Detalhamento”, definido
como “Capacidade de descrever em minúcias”. Os atributos “Concisão” (definido como
“Capacidade de ser resumido”) e “Divisibilidade” (definido como “Capacidade de ser
particionado”) podem ser explorados pelo usuário da ferramenta de acordo com suas
necessidades, por exemplo, ao seccionar a modelagem utilizando o Diagrama de
Indicadores ou somente BPMN e i* como forma de resumir e/ou separar as
informações em modelos diferentes.
No contexto da “Auditabilidade”, o atributo “Validável” (definido como
“Capacidade de ser testado por experimento ou observação para identificar se o que
está sendo feito é correto”) torna-se algo intrínseco ao modelo de processo de
negócio, já que ele pode ser instanciado como teste, e também acompanhado e
avaliado pelos indicadores. O mesmo ocorre para o atributo “Controlabilidade”
(definido como “Capacidade de domínio”) caso os processos sejam geridos a parir dos
modelos. Com a aplicação do Diagrama Integrado, maior nível de informações e
relacionamentos entre os elementos são descritos, ampliando a capacidade de
129
controle, principalmente pela relação entre objetivos e atividades que é mais visível
neste diagrama.
O atributo “Verificabilidade” (definido como “Capacidade de identificar se o que
está sendo feito é o que deve ser feito”) recebe contribuição do uso de indicadores
que, em nossa proposta, consiste em identificar se o processo é capaz de produzir o
que é esperado pelos objetivos. O atributo “Rastreabilidade” (definido como
“Capacidade de seguir o desenvolvimento de um processo ou a construção de uma
informação, suas mudanças e justificativas”) recebe contribuição naturalmente pelo
registro das atividades dos processos e das transformações de produtos/informações
que ocorrem durante sua execução. Porém, através dos relacionamentos entre as
camadas de objetivos e processos, é possível rastrear ao mesmo tempo com maior
amplitude e precisão as justificativas das projeções das atividades e objetivos de
negócio, ou seja, as questões do “por que” e “como” encontram-se relacionadas no
Diagrama Integrado, o que também beneficia o atributo “Explicável” (definido como
“Capacidade de informar razão de algo”).
Conforme visto em nossas ponderações sobre as contribuições dos modelos
propostos neste trabalho no contexto da Transparência, o seu uso amplia o nível de
aderência a alguns (porque não analisamos todos os casos) dos requisitos não
funcionais presentes no gráfico de interdependência de metas de Transparência,
atuando como uma opção de operacionalização para cada um dos atributos
apresentados.
6.4. Trabalhos futuros
Nosso trabalho envolveu a definição de uma linguagem para modelagem e o
desenvolvimento de um protótipo. Os trabalhos futuros envolvem melhorias nestes
dois elementos.
No contexto da ferramenta, um dos trabalhos futuros é a evolução da interface
gráfica como forma de melhorar a representação dos elementos, facilitando a
diferenciação dos tipos de relacionamentos e representação de definições. Também
devemos corrigir defeitos na ferramenta Oryx e transformá-la em uma versão final, se
possível, disponibilizando a funcionalidade de oferecer relatórios automatizados.
No contexto da linguagem, devemos explorar mais o uso do conceito de regras
de negócio e seu relacionamento com os objetivos, além do refinamento no uso de
indicadores.
No contexto geral, esforços devem ser orientados para o uso da proposta em
casos mais complexos, possibilitando a busca por pontos de melhoria tanto na
ferramenta como na linguagem.
130
7 Referências bibliográficas
[Amyot02] Amyot, D.; “Using the User Requirements Notation”, ITU-T Workshop on
the "Use of Description Techniques", novembro de 2002.
[Amyot&Mussbacher01] Amyot, D., Mussbacher, G.; “Bridging the
Requirements/Design Gap in Dynamic Systems with Use Case Maps (UCMs)”. In
Proceeding ICSE '01 Proceedings of the 23rd International Conference on Software
Engineering, IEEE Computer Society Washington,DC,USA, 2001, ISBN:0-7695-1050-7
[Amyot&Mussbacher02] Amyot, D., Mussbacher, G.; “URN: Towards a New
Standard for the Visual Description of Requirements”. In Proceedings of
SAM'2002. pp.21~37.
[ARIS06] ARIS; “Help Documentation”, ARIS Business Architect 7.0 v. 7.0.2.234414,