GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa

CENTRO UNIVERSITÁRIO DA FEI

GIAN MARCO FERRARI

GUSTAVO MARTELLA ACHKAR

ORLANDO DA SILVA JUNIOR

GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa

São Bernardo do Campo

2011

GIAN MARCO FERRARI

GUSTAVO MARTELLA ACHKAR

ORLANDO DA SILVA JUNIOR


Trabalho de Conclusão de Curso apresentado ao

Centro Universitário da FEI como parte dos

requisitos necessários para obtenção do título de

Bacharel em Ciência da Computação, orientado

pelo Prof. Dr. Rodrigo Filev Maia.


2011

Gian Marco Ferrari

Gustavo Martella Achkar

Orlando da Silva Junior


Trabalho de Conclusão de Curso – Centro Universitário da FEI

Comissão julgadora

_________________________________________________

Orientador e Presidente

_________________________________________________

Examinador (1)

_________________________________________________

Examinador (2)


2011

RESUMO

Jogos de Empresas constituem hoje uma importante ferramenta no auxílio ao aprendizado em

certos cursos, sendo adotados por diversas instituições. Porém, apresentam os seguintes

problemas: são caros, poucos, não satisfatoriamente específicos e de difícil utilização e

adaptação. Neste trabalho é proposta uma arquitetura capaz de permitir que não somente a

aplicação, mas também a concepção de jogos de empresas fique a cargo do professor que os

utiliza, pois, embora essa abordagem exija um maior interesse e esforço por parte do mesmo,

dessa forma é possível a personalização do jogo de empresas, adequando-o as necessidades do

professor e dos demais envolvidos. Como resultado espera-se que um professor leigo, através

da definição de um fluxo de jogo próprio e configuração dos módulos de jogo pré-

programados, encontre na arquitetura proposta a flexibilidade necessária para criar seus

próprios jogos e consequentemente supra suas necessidades.

Palavras-chave: jogo de empresas – workflow – arquitetura computacional

ABSTRACT

Business Games are today an important tool to support learning in some courses, being

adopted by several institutions. However, they present the following problems: they are

expensive, few, not satisfactorily specific and difficult to use and adapt. This work proposes

an architecture capable of allowing not only the application, but also the design of business

games, to be in charge of the teacher who uses them, because, although this approach requires

a greater interest and effort on the part of the same, this way business games customization is

made possible, adapting it to the needs of the teacher and others involved. As a result it is

expected that a lay teacher, through the definition of a game workflow of his own and the

configuration of pre-programmed modules, find in the proposed architecture the flexibility to

create his own games and therefore meet his needs.

Key words: business game – workflow – computational architecture

5

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................. 7

1.1 Contexto ............................................................................................................................. 8

1.2 Justificativa ........................................................................................................................ 8

1.3 Objetivo .............................................................................................................................. 8

2 TRABALHOS RELACIONADOS .............................................................................................. 9

3 FUNDAMENTAÇÃO TEÓRICA ............................................................................................. 11

3.1 Sobre Jogos de Empresas ............................................................................................... 11

3.1.1 O Professor e o Jogo de Empresas ................................................................................ 13

3.1.2 Aspectos de Aprendizagem ........................................................................................... 15

3.1.3 Aplicação do Jogo sob a Perspectiva do Professor ....................................................... 17

3.2 Do Processo de Negócio ao Jogo de Empresas .............................................................. 19

3.2.1 Processo de Negócio ..................................................................................................... 20

3.2.2 Classificação do BP quanto ao nível operacional.......................................................... 22

3.2.3 Gestão de Processo de Negócio..................................................................................... 24

3.2.4 Ciclo de Vida do Processo de Negócio ......................................................................... 26

3.2.5 Gestão de Workflow ...................................................................................................... 29

3.2.6 Distinção entre BPM e Gestão de Workflow ................................................................ 33

3.2.7 Implicações na arquitetura proposta .............................................................................. 34

3.3 Teoria dos Jogos .............................................................................................................. 37

3.3.1 Histórico ........................................................................................................................ 38

3.3.2 Definição de jogos ......................................................................................................... 38

3.3.3 Tipos de jogos ............................................................................................................... 39

4 ARQUITETURA COMPUTACIONAL DE JOGOS DE EMPRESA ................................... 42

4.1 Definições de Arquitetura ............................................................................................... 42

4.2 Elementos Estruturais do Design de Jogos de Empresa .............................................. 43

4.3 Abordagens ao Design de Jogos de Empresa ................................................................ 45

4.4 GOG: Uma Arquitetura Computacional para Jogos de Empresa ............................. 48

5 ENGENHARIA DE SOFTWARE ............................................................................................. 51

5.1 Especificação e Requisitos do Projeto ........................................................................... 51

6

5.2 Atores................................................................................................................................ 52

5.3 Casos de Uso .................................................................................................................... 53

5.4 Arquitetura GOG ............................................................................................................ 54

5.5 Especificação dos Módulos do Workflow...................................................................... 56

5.6 Especificação da Estrutura Básica do Jogo .................................................................. 57

5.7 Especificação e Requisitos da Definição de Jogo .......................................................... 59

5.8 Linguagem de Definição de Jogo ................................................................................... 63

5.9 Implementação ................................................................................................................ 71

5.10 Testes ................................................................................................................................ 73

6 CONCLUSÕES ............................................................................................................... 76

6.1 Trabalhos Futuros ........................................................................................................... 76

REFERÊNCIAS .................................................................................................................................. 78

ANEXO A – UM JOGO DE EMPRESAS DO MUNDO REAL ..................................................... 82

7

1 INTRODUÇÃO

Com o avanço de recursos tecnológicos e as mudanças do mercado, cresceu a

necessidade de que a forma de ensino também mudasse, pois ficou evidente um

distanciamento entre a formação e a expectativa do mercado (ORTI; RODRIGUES;

ALBINO, 2008; LACRUZ, 2004). O modelo tradicional já não atende mais às necessidades

do mercado sendo a falta de prática provida na formação considerada um dos principais

problemas (LACRUZ, 2004), segundo Santos e Lovato (2007): “[...] muitos cursos de

administração enfatizam exageradamente o que deve ser em detrimento do que é, divorciando,

consequentemente, a teoria da prática, tendem a recomendar o ideal e ignorar as restrições,

pressões e limitações das situações reais (RAMOS, 1991)”. Assim, surgiram estudos que

propõe formas de melhorar o ensino, sendo os métodos vivenciais muito valorizados, para

Orti, Rodrigues e Albino (2008): “[...] jogos de empresa vêm obtendo maior destaque como

uma dessas metodologias e deve preparar os ‘jogadores’ para tornar suas empresas

competitivas em relação ao mercado, oferecendo situações similares às da realidade para o

treino da tomada de decisão e também deve ser pedagogicamente adequado, provendo o

interesse e o aprendizado”.

Entre os benefícios de um Jogo de Empresas podemos destacar: a aproximação entre

teoria e prática, a ampla aceitação e motivação dos alunos, o desenvolvimento de

competências e a melhora do aprendizado em geral, contudo, tal recurso tem se mostrado

caro, de difícil utilização pelos alunos e professores, havendo pouca variedade, inclusive de

cenários e situações onde características específicas de cada empresa e país acabam ignoradas.

Os professores têm dificuldade em adaptar jogos de empresas à grade curricular devido ao

tempo requerido e o escopo abordado (não é possível adaptá-los de modo a balancear

complexidade e tempo) (LACRUZ, 2004).

Neste trabalho é proposta uma arquitetura que permite a construção de diferentes jogos

através da concepção de um workflow e o uso de módulos configuráveis previamente

desenvolvidos, permitindo a criação de cenários e situações particulares, suficientemente

específicas e adaptadas à realidade que se quer retratar bem como a disponibilidade da grade

curricular. Cada módulo é desenvolvido através de uma linguagem de programação

específica, com interfaces segundo a definição da arquitetura proposta de modo a ser possível

a interoperabilidade entre módulos através do mecanismo de workflow.

8

1.1 Contexto

Jogos de Empresa ganharam espaço nas instituições de ensino superior graças aos

benefícios a eles associados como a aproximação entre teoria e prática, a ampla aceitação e

motivação dos alunos, o desenvolvimento de competências e a melhora do aprendizado em

geral. Contudo, atualmente, faltam Jogos de Empresa no mercado, sendo que estes têm um

alto custo de aquisição; são pouco específicos, ignorando características específicas de cada

empresa e país; e de difícil utilização pelos alunos e professores. Estes últimos, ainda, têm

dificuldade em adaptá-los à grade curricular devido ao tempo requerido e o escopo abordado.

1.2 Justificativa

Professores interessados em ter um maior controle sobre o jogo, ainda que ao custo de

um maior esforço pessoal, poderiam, se munidos de uma ferramenta que lhes permitisse tal

flexibilidade, configurar seus próprios jogos de modo que melhor se adaptem às suas

necessidades.

1.3 Objetivo

Propor uma arquitetura que confira flexibilidade a jogos de empresa, permitindo sua

maior adaptação e personalização por parte do professor através da definição de um fluxo de

jogo próprio e configuração dos módulos de jogo.

9

2 TRABALHOS RELACIONADOS

No intuito de encontrar uma solução que atenda às necessidades de todos os

envolvidos no desenvolvimento de um jogo empresarial, este projeto apresenta, a seguir, uma

relação de semelhantes trabalhos e pesquisas, tal como suas soluções obtidas.

Thavikulwat (2004) propõe uma arquitetura de simulações de jogos de negócios

computadorizados. De fato, esse trabalho não está relacionado diretamente à engenharia, mas

sua abordagem e a exposição da arquitetura apresentada permitem que este projeto analise,

avalie e desenvolva uma ferramenta que seja capaz de simular jogos de empresa. A proposta

de Thavikulwat (2004) considera a representação, a cronometragem, o hosting e a pontuação

dos simuladores de jogos de negócio. Deste modo, o tratamento que o trabalho dá à

arquitetura resulta em um modelo que é compreendido tanto por um especialista em negócios

quanto por um engenheiro de software.

O trabalho de Westphal e Lopes (2007) apresenta e analisa três abordagens ao design

de simuladores de jogos e destaca os quatro elementos principais de um simulador. O

procedimento metodológico da pesquisa de Westphal e Lopes (2007) consistiu no

levantamento das publicações já existentes sobre metodologias e abordagens ao design de

simuladores. Suas principais fontes foram os periódicos da ABSEL – Association for Business

Simulation and Experiental Learning e da Simulation & Gaming. Sendo possível abordar os

aspectos sociais, as interações existentes entre os envolvidos do jogo e as questões relativas ao

aprendizado, o estudo foi delimitado por apresentar os aspectos de desenvolvimento de

simuladores. Como resultado, os autores apresentam o conjunto de estudos, analisado e

sistematizado, dos principais aspectos para a construção de simuladores, que serve de

referência para os desenvolvedores e os estudiosos da área. O trabalho de Westphal e Lopes

(2007) colabora com a análise e a modelagem da solução deste projeto, uma vez que os

elementos estruturais de um simulador e os mais conhecidos métodos de identifica-los e trata-

los.

Pelaes (2009) desenvolve uma dissertação de mestrado focada no processo de

construção da estratégia de operações, centralizando os resultados na simulação de jogos

empresariais. Para alcançar esse objetivo, o trabalho realiza um levantamento bibliográfico

dos pontos-chave sobre o ensino da estratégia de operações e modela e avalia seu processo de

construção. Na fase de construção, Pelaes (2009) modela os processos por BPMN,

justificando essa escolha por sua interoperabilidade com outros sistemas, sobretudo baseados

em web, e desenvolve um aplicativo. Os resultados do trabalho expressam sua utilidade neste

10

projeto: três funcionários de distintas empresas avaliaram o aplicativo e o classificaram

positivamente em fatores de factibilidade, usabilidade e utilidade. Este último é composto,

sobretudo, pela avaliação da solução quanto à sua colaboração para o aprendizado de

estratégias de operações. Para este projeto, isto denota a vantagem da modelagem de

processos para a construção de jogos de aprendizado de negócios.

Por fim, Borrajo et. al (2010) apresentam o simulador SIMBA, uma ferramenta web

voltada à educação e à pesquisa em negócios. O trabalho descreve o simulador e seu modelo

lógico, arquitetura de software e principais funcionalidades. Embora focados na exposição das

características funcionais e pedagógicas do simulador, enfatizando a melhoria da função do

ensino por infraestruturas de Tecnologia da Informação (TI), Borrajo et. al (2010) apresentam

o simulador para três distintas finalidades: administração de negócios, educação de negócios e

pesquisa em inteligência artificial. Assim, esse trabalho provê um estudo inter-relacional

integrado de áreas que permitem que este projeto desenvolva uma solução para especialistas

em negócio e cientistas da computação.

Por apresentarem de modo geral as fases existentes na engenharia de jogos de

empresa, as pesquisas acima relacionadas envolvem-se diretamente com este projeto e

colaboram para a construção de uma solução computacional aceitável por professores, alunos

e engenheiros de software.

11

3 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os conceitos que fundamentam o presente trabalho,

permitindo a sua compreensão.

3.1 Sobre Jogos de Empresas

Trata-se de um método que pode ser denominado ainda como: jogos de negócios,

jogos gerenciais, simulação empresarial, simulação de gestão, gestão simulada e simulação

gerencial (BERNARD, 2006 apud SANTOS; LOVATO, 2007).

Para Orti, Rodrigues e Albino (2008) os jogos de empresas constituem de sistemas de

simulação empresarial informatizada, com a finalidade pedagógica do ensino e aprendizagem

sendo assim a confluência de áreas de conhecimento, tais como os conceitos e práticas de

gestão, os princípios pedagógicos de ensino e aprendizagem e a tecnologia da informação.

Lacruz (2004) em seu trabalho apresenta uma evolução da definição de jogos de

empresas citando diversos autores que, segundo ele “[...] coincidem no argumento de que

jogos de empresas são modelos dinâmicos de simulação que salientam as situações da área

empresarial, bem como o aspecto sequencial. [...] todas as definições apresentaram os jogos

de empresas como uma atividade fortemente vinculada à tomada de decisão”.

Lacruz (2004) afirma então que “[...] jogos de empresas representam uma técnica

educacional dinâmica desenvolvida para propiciar aos “jogadores” uma experiência de

aprendizado marcante e lúdica; servem, assim, como uma ponte entre a academia, a vivência

passada e o ambiente empresarial, a partir de uma representação da realidade (situações

específicas da área empresarial) por meio de abstrações matemáticas; utilizam-se de técnicas

de simulação (retratando condições de laboratório de uma determinada realidade, não sendo

somente uma simulação da empresa, mas do mercado) e possuem componentes dos jogos

(trazendo a interatividade e o exercício em equipe)”.

Apesar do recorrente entendimento de que Jogos de Empresas envolvem uma

simulação destacado tanto por Lacruz (2004) como por Orti, Rodrigues e Albino (2008)

anteriormente citados, existe um debate entre diferentes autores acerca da diferenciação do

conceito daquilo que seria uma simulação e daquilo que seria um jogo.

Para Ramos (1991) apud Santos e Lovato (2007): “A simulação é uma seletiva

representação da realidade, abrangendo apenas aqueles elementos da situação real que o autor

considera relevante para seu propósito. E, um modelo simulado reduz o tamanho da realidade

12

sendo representada, além de simplificá-la”. Seguindo a mesma linha de raciocínio, Santos e

Lovato (2007) diz que a simulação faz uso de modelos construídos que visam reproduzir

processos em ação, sendo que, a escolha dos aspectos da realidade a ser modelada depende

dos objetivos da simulação, cujo comportamento deve responder de modo semelhante àquele

do sistema real.

Jogo é um termo normalmente usado para simulação com a participação de pessoas

que tomam decisões sendo utilizado em situações nas quais há competição (GUETZKOW,

1962 apud SANTOS; LOVATO, 2007). Huizinga (1993) apud Orti, Rodrigues e Albino

(2008) vai além ao propor que no jogo cria-se uma realidade imaginária sob regras absolutas

que determinam aquilo que vale no mundo do jogo. De forma semelhante Gramigna (1993)

apud Orti, Rodrigues e Albino (2008) sugere que quando se entra num jogo aceitam-se as

regras e nos afastamos do mundo real exterior vivendo os aspectos lúdicos do jogo.

Para Gramigna (1993) apud Orti, Rodrigues e Albino (2008) se juntarmos os dois

conceitos, teremos então o jogo simulado onde os participantes enfrentam desafios de

tomadas de decisão que reproduzem situações reais.

Para Ramos (1991, p. 12, grifo do autor) apud Santos e Lovato (2007), “em essência, a

simulação [jogos de empresas] é uma estratégia de aprender a aprender, pois estimula o

aluno a desenvolver determinadas capacidades, capacidades estas que aumentarão sua

potencialidade de obter novos conhecimentos e adquirir novas habilidades”. Santos e Lovato

(2007) afirmam ainda que “esta técnica explora a faceta competitiva da personalidade do ser

humano, pela qual ele se sente estimulado a disputar com outras pessoas, e se utiliza de todas

as ferramentas possíveis para vencer o confronto”.

O Jogo de Empresas é, portanto, antes de qualquer coisa uma ferramenta de auxilio ao

aprendizado, que deve se aproximar tanto quanto possível da realidade (SANTOS; LOVATO,

2007), contudo, como percebido por Lacruz (2004): “As simulações do meio ambiente são

sempre mais simples que o mundo real, porque, além de o conhecimento sobre a realidade não

ser completo, é necessário manter o jogo relativamente fácil de ser processado e, também,

permitir que os participantes identifiquem as relações de causa e efeito que presidem o

modelo e vinculam os resultados às ações”. Portanto a aproximação da realidade de um Jogo

de Empresa esta limitada pelo seu objetivo: auxiliar no aprendizado, que necessita do

interesse ganho, por vezes, através de aspectos lúdicos de jogo como citado por Gramigna

(1993). Há um limite a partir do qual mais complexidade não traz benefícios, sendo

importante permitir aos participantes levantar perguntas e desenvolver insights (VICENTE,

2001 apud LACRUZ, 2004).

13

Segundo Tanabe (1977) apud Lacruz (2004) e Orti, Rodrigues e Albino (2008), os

jogos de empresas têm três objetivos básicos: Treinamento (desenvolver a habilidade de

tomada de decisão, através do exercício e experiências), Didático (transmitir conhecimentos e

técnicas específicos de um modo prático e experimental) e Pesquisa (encontrar soluções para

problemas empresariais valendo-se do realismo da simulação).

Sauaia (1989) apud Lacruz (2004) também ressalta três objetivos dos jogos de

empresas, porém tem seu foco nos benefícios trazidos aos jogadores, são eles: Aumento do

conhecimento (pela incorporação de novas informações trazidas ao contexto do jogo; pela

integração de conhecimentos que passam a fazer sentido; e por meio do resgate de

conhecimentos anteriormente adquiridos, cuja vivência facilita o acesso), Desenvolvimento de

habilidades (por meio da prática gerencial repetida) e Fixação de atitudes (através da

transposição da aprendizagem propiciada pelos acontecimentos fictícios, inseridos em um

cenário simulado, para o ambiente real).

Independente das diferenças nos parâmetros tomados para a classificação fica claro

que os jogos de empresas visam à melhora do aprendizado trazendo benefícios distintos aos

participantes graças ao seu caráter vivencial. Ainda acerca dos benefícios Vicente (2001) apud

Santos e Lovato (2007) diz que “[...] estas categorias de jogos [jogos de empresas em

específico] associam o prazer lúdico não só à capacidade de raciocínio analítico, mas também

à habilidade de tomada de decisão. Pessoas que têm por hábito jogar este tipo de jogo têm

menos dificuldade em fazer análises racionais e em tomar decisões. Em nossa sociedade estas

duas habilidades estão profundamente relacionadas”.

Para Harrel et al. (2002) apud Santos e Lovato (2007) “a habilidade de definir uma

idéia com um modelo, permite testar o impacto das sugestões e, então, o uso do modelo para

se vender a idéia aos tomadores de decisão pode incentivar a atitude do tipo: vamos

experimentar para ver”.

A necessidade do desenvolvimento dessas habilidades decorre da necessidade do

mercado, segundo Vicente (2001) apud Santos e Lovato (2007) “[...] as empresas precisam

muito mais de pessoas capacitadas a tomar decisões e a serem empreendedoras do que meros

operários incapazes de criar ou decidir por si mesmos”.

3.1.1 O Professor e o Jogo de Empresas

Segundo Sauaia (1995): “Pode-se observar que as escolas têm enfrentado dificuldades

em preparar administrador para a profissão, em estabelecer um nível de educação formal que

14

se possa considerar plenamente satisfatório, tanto do ponto de vista do recém-formado quanto

do ponto de vista das empresas que o acolhem”.

Para Santos e Lovato (2007), técnicas alternativas, como estudos de caso para ensino,

seminários, jogos de empresas etc, são exemplos de como complementar o ensino. Sauaia

(1995) apud Santos e Lovato (2007) afirma ainda que o jogo de empresas constitui um

método “muito bem aceito pelos educandos por combinar satisfação e aprendizagem,

representa um recurso valioso que, se bem explorado, pode contribuir grandemente para o

avanço da educação gerencial”.

Para Vicente (2001) apud Santos e Lovato (2007), “os jogos de empresas não são um

modismo, mas sim uma tendência secular que vem ganhando ímpeto em nossos dias pelo

maturamento de várias tecnologias”. No Brasil o Ministério da Educação (MEC), editou a

resolução de número CNE/CES nº. 1/2004 em 04/03/2004 que determina que o projeto

pedagógico deva fazer uma integração entre a teoria e a prática. Sendo assim o uso de jogos

de empresas atende a uma exigência do curso de administração (SANTOS; LOVATO, 2007).

Ainda assim há aqueles que resistem ao uso de Jogos de Empresas. Para Sauaia

(1995), os professores se classificam em dois grupos: “[...] em “vigorosos oponentes” ou em

“grandes partidários” das simulações, no que diz respeito à abordagem ao processo de

aprendizagem. Os oponentes não crêem que conceitos possam ser aprendidos em uma

simulação, pois, segundo eles, prevalecem os aspectos lúdicos relativos ao jogo. Já os

partidários estão convencidos de que as simulações criam um valioso ambiente no qual se

processa uma aprendizagem dinâmica e plena, com aplicação de conceitos e de técnicas”.

Gramigna (1993) apud Orti, Rodrigues e Albino (2008) identifica 10 mitos e

classifica-os como forças restritivas, que precisam ser desmistificadas:

1) "Se brinco não aprendo”;

2) "Jogos demandam muito tempo de planejamento";

3) "Tenho medo de os treinando não entrarem no jogo”;

4) "Não gosto de incentivar a competição, ela já é muito forte nas empresas";

5) "O jogo torna as pessoas agressivas";

6) "Com uma boa teoria, as pessoas aprendem mais”;

7) "No jogo, não tenho controle da aprendizagem";

8) “Fico inseguro por não possuir referencial teórico sobre jogos";

9) "Não tenho habilidade criativa, logo não posso usar jogos”;

10) "Adulto não gosta de atividades lúdicas".

15

Na visão de Sauaia (2006) apud Santos e Lovato (2007), os cursos de Ciências Sociais

(Administração de Empresas, Ciências Contábeis e Economia) incorporarão esta técnica já

conhecida e diante as suas vantagens aqueles professores que enxergam mais fatores que

dificultam o uso de jogos de empresas do que os motivam, provavelmente mudarão de idéia

no curto ou médio prazo. Santos e Lovato (2007) diz ainda que “Percebe-se uma tendência de

aumento no uso dos jogos de empresas em sala de aula, haja vista a familiaridade dos alunos e

professores com as tecnologias computacionais, cada vez mais modernas e de fácil

utilização”.

3.1.2 Aspectos de Aprendizagem

Já foi dito anteriormente que os Jogos de Empresas têm caráter vivencial, público alvo

adulto, entre outras características, para melhor compreender as implicações dessas

características Lacruz (2004) discute brevemente sobre a aprendizagem em si, segundo ele:

“[...] o tema foi discutido segundo diferentes abordagens e enfoques por diversos estudiosos, à

luz das análises de SANTOS (2003) e SAUAIA (1995) a aprendizagem será vista no contexto

da Andragogia, sob o enfoque da Abordagem Humanista, através de uma perspectiva da

Teoria da Gestalt, cujos princípios mais se aproximam dos presentes em jogos de empresas

[grifo nosso]”.

A Andragogia aborda a aprendizagem de adultos, como é o caso nos cursos de ensino

superior, na visão de KRISCHKE (2000) apud MARQUES FILHO (2001: 57) apud Lacruz

(2004): “A andragogia tem como características básicas: ser um processo de aprendizagem

de ação e participação, dando ênfase tanto no processo como no conteúdo; mais centrada na

aprendizagem do que no ensino; no treinando do que no facilitador; na atividade do que na

passividade; no clima de interesse e necessidade do treinando mais do que em provar o

conhecimento do formador; no contrato de aprendizagem; na apropriação do saber do que no

conhecer; na avaliação mais do que um instrumento de controle como um autodiagnóstico dos

hiatos das competências que se pretende alcançar [grifos do original]”.

Segundo Lacruz (2004) a Abordagem Humanista pode ser resumida partindo-se de

dois parâmetros: o aluno e o professor. O aluno é o foco do processo de ensino e

aprendizagem, visto como um ser ativo, criativo, participativo e que “aprendeu a aprender”. O

professor é o facilitador da aprendizagem, devendo fornecer condições para que os alunos

aprendam. Trata-se de uma abordagem que se contrapõe à idéia tradicional de ensino que têm

no professor o seu elemento fundamental (agente que transmite o conhecimento de forma

16

estruturada aos alunos passivos). Nos jogos de empresas o foco é transferido do professor para

os alunos.

A Teoria da Gestalt interpreta “[...] o pensamento como um processo reflexivo, dentro

do qual as pessoas desenvolvem insights novos ou os modificam através de uma nova

compreensão. O pensamento reflexivo combina tanto processos indutivos como dedutivos”

(SAUAIA, 1995). De acordo com BIGGE (1977), parafraseado por SAUAIA (1995), os

principais aspectos do pensamento reflexivo associados à teoria da gestalt são:

1. Reconhecimento e definição de um problema, ao tomarmos ciência de objetivos

conflitantes ou da presença de obstáculos ante os objetivos;

2. Formulação de hipóteses, ou seja, criação de asserções sob a forma de

generalizações, para que sejam verificadas pela experiência humana;

3. Elaboração das implicações lógicas das hipóteses, na forma de dedução das

implicações ou conseqüências de observações já feitas e de outras ainda por fazer;

4. Teste das hipóteses, envolvendo tentativas de verificar as implicações ou

conseqüências deduzidas;

5. Tirando conclusões, isto é, aceitando, modificando ou rejeitando as hipóteses,

admitindo-se a inexistência de evidências que garantam uma tomada de posição definitiva

[grifos do autor].

Lacruz (2004) conclui então que as “características encontradas na andragogia se

relacionam com a abordagem humanista, quando da adoção pelo professor de uma postura de

facilitador da aprendizagem, centrada no aluno, e com a teoria da gestalt, quando da

autogestão da aprendizagem pelo aluno, características idênticas às encontradas em jogos de

empresas”.

Sendo assim os jogos de empresas são uma abordagem de ensino que difere do modelo

tradicional na forma como se da o aprendizado. As características do modelo tradicional

sugerem uma concordância com teorias do condicionamento estímulo-resposta que

consideram a aprendizagem como um processo de mudança no comportamento, ocorrendo

através de estímulos e respostas que se relacionam e obedecem a princípios mecanicistas,

estando então em contraponto à teoria de campo-gestalt (ORTI; RODRIGUES; ALBINO,

2008). O modelo tradicional parece ainda concordar com a corrente comportamentalista

behaviorista, que vê o homem como um ser passivo cujo comportamento seria governado por

estímulos externos, em contraponto a abordagem humanista (LACRUZ, 2004).

Segundo Santos e Lovato (2007) “acredita-se que os jogos de empresas não devem

tomar o lugar de outros métodos educacionais, mas somar esforços e complementá-los para

17

suprirem as deficiências na educação tradicional”. A Tabela 1, que segue, destaca diferenças

entre o ensino tradicional e vivencial.

PARÂMETROS

EDUCACIONAIS

ENSINO

TRADICIONAL APRENDIZAGEM VIVENCIAL

Orientação didática Ensino Aprendizagem

Personagem central Educador Educando

Conteúdos trabalhados Do educador Do educando

Envolvimento do educador Alto Baixo

Envolvimento do educando Baixo Alto

Atitude que orienta Quero ensinar Quero aprender

Técnica usual Expositiva Atividade em grupo

Tipo de aprendizagem Cognitiva Cognitiva, afetiva, atitudinal e

comportamental

Áreas trabalhadas Cérebro Todo o indivíduo

Aplicação de conceitos Teórica Prática

Objetivos educacionais Gerais e coletivos Específicos e individualizados

Avaliados da aprendizagem Educador Educando

Andamento da aula Estímulo do educador Motivos do educando

Ambiente criado Competitivo Competitivo e cooperativo

Tabela 3.1 – Comparativo e parâmetros dos métodos educacionais: ensino tradicional x aprendizagem vivencial

Fonte: adaptado de Sauaia, 1995

3.1.3 Aplicação do Jogo sob a Perspectiva do Professor

Masetto (1992), citado por Orti, Rodrigues e Albino (2008), defende a existência de

nove princípios que explicitam o processo de aprendizagem do adulto, capazes de oferecer

condições facilitadoras de aprendizagem:

1. Promoção da participação num processo efetivo de interação, eliminando-se a

situação dicotômica onde o professor é o “dono” da verdade e ao aluno compete absorver o

que é transmitido, cada um sendo responsável por parte do processo, e a situação de conflito,

onde o professor é visto (se coloca) como um “obstáculo” a ser vencido, inexistindo, portanto,

o comportamento cooperativo;

18

2. Valorização da experiência e contribuição dos alunos, potencializando o

desenvolvimento da autoconfiança do aprendiz;

3. Explicitação do significado dos temas envolvidos, possibilitando que o aprendiz os

relacione com seu “universo”;

4. Definição clara e explícita de objetivos e metas a serem alcançados e organização

de um plano eficiente para consegui-lo, a partir do envolvimento e participação dos

aprendizes, de forma a relacioná-los da melhor maneira às necessidades e expectativas destes;

5. Estabelecimento de recursos eficientes, avaliáveis e adequados aos objetivos, os

quais se sujeitarão à avaliação realizada conjuntamente por alunos e professor, a fim de

verificar sua eficiência e possíveis alterações;

6. Criação de um sistema de feedback contínuo entre alunos e professor, que forneça

condições de corrigir ou redirecionar a rota no sentido dos objetivos propostos;

7. Desenvolvimento de uma reflexão crítica, apresentando interpretações alternativas

de valores, crenças, comportamento e ideologia culturalmente transmitidos, bem como do

trabalho, relações pessoais e perspectivas do mundo social e político;

8. Estabelecimento de diálogos permanentes entre professor e alunos, engajamento

mútuo e ação cooperativa (contrato psicológico), tendo em vista “equilibrar as necessidades

do aprendiz e as propostas do professor”;

9. Adaptação do comportamento do professor ao processo de aprendizagem próprio de

adultos: ao professor caberá, em resumo, preocupar-se com os interesses dos alunos,

admitindo seus autoconceitos e experiências passadas como material educacional, mostrando-

se confiante e aberto a diferentes pontos de vista e relacionando a teoria com a prática.

Estes princípios refletem o que seria uma postura de facilitador por parte do professor,

sendo esta a postura esperada na aplicação de Jogos de Empresas (ORTI; RODRIGUES;

ALBINO, 2008).

Lacruz (2004) com base em diversos autores, diz que a operacionalidade de um jogo

de empresas pode ser sintetizada em sete fases:

(1) Apresentação do cenário simulado: circunstância em que o animador esclarece os

jogadores sobre o ambiente em que o jogo está contextualizado;

(2) Esclarecimento das regras: refere-se à apresentação do que é permitido/proibido e

do ciclo do jogo; enfim, a todas as regras e a sistemática do jogo de empresas;

(3) Planejamento das equipes para as decisões a serem tomadas: nesta fase, as equipes

se reúnem por um período predeterminado para tomar as decisões concernentes ao jogo, com

19

base em suas vivências passadas, conhecimentos técnicos e relatórios gerados pelo próprio

jogo;

(4) Revelação das decisões tomadas pelas equipes ao animador: nesta ocasião, as

decisões tomadas por cada equipe de jogadores são reveladas exclusivamente ao animador;

(5) Processamento das decisões tomadas: as decisões são processadas por meio de

modelagens que reproduzam uma realidade possível do ambiente em que as empresas

dirigidas pelas equipes estão inseridas, e seu cálculo pode ser realizado pelo computador ou

pelo professor. Após o processamento das decisões, são gerados relatórios, que servem de

feedback sobre o mercado para as empresas e de parâmetro para as próximas decisões,

apontando em que condição cada empresa se encontra;

(*) Repetição das fases de (3) a (5) nas demais etapas definidas na fase (2);

(6) Definição da equipe vencedora: pelos critérios estabelecidos na fase (2) é

apresentada a equipe vencedora;

(7) Debriefing ou aftermath: momento de troca de experiências – em que jogadores e

animador reúnem-se para discutir suas impressões sobre o jogo de empresas, por que tomaram

esta ou aquela decisão – e de correção de distorções no entendimento surgidas por qualquer

razão.

Lacruz (2004) diz ainda que estas fases não são fechadas, sem pontos de interligação,

ou inflexíveis e lembra que Jogos de empresas não são fins em si mesmos.

Segundo Kallás (2004) apud Orti, Rodrigues e Albino (2008) “O administrador do

jogo procura através do diálogo e da análise, orientar as equipes no sentido de fazê-las

reconhecerem os instrumentos e técnicas da administração que as ajudariam em cada uma das

situações”.

Orti, Rodrigues e Albino (2008) reforçam a

“ênfase que inúmeros autores dão para que os jogos de empresa sejam feitos

de modo coletivo, ou seja, em equipe, pois além do enriquecimento na troca

de experiências é algo mais parecido com a realidade, onde as decisões são

normalmente interdepartamentais e interdependentes” (ORTI; RODRIGUES,

ALBINO, 2008).

3.2 Do Processo de Negócio ao Jogo de Empresas

A gestão de processos de negócio é uma disciplina que compreende uma série de

conceitos, métodos, técnicas, linguagens e notações. Sistemas de gestão de processos de

20

negócio são diferentes de jogos de empresa, porém ambos têm afinidade uma vez que

compartilham conceitos e exigem alguns conhecimentos similares para serem concebidos e

utilizados. Neste capítulo serão apresentados definições e conceitos da gestão de processos de

negócio pertinentes à compreensão e contextualização de parte daquilo que esta por trás dos

jogos de empresa, de sua concepção e da arquitetura proposta neste trabalho. Como o título do

capitulo sugere é adotada uma abordagem “da base ao topo”, começando com a introdução de

conceitos básicos necessários ao entendimento das conclusões que decorrem.

Ko (2009), referenciando diversos autores, destaca um problema que atinge

diretamente o propósito deste capítulo: a ausência de terminologias universais como um

problema comum a gestão de processos de negócio. Isso dificulta classificações, comparações

e o entendimento da relação dos conceitos apresentados com jogos de empresas, sendo,

portanto, também objetivo deste capítulo a clarificação de conceitos e adoção de uma

terminologia básica do campo de estudo para que fique mais clara à fronteira daquilo que se

aplica a este trabalho. Em geral serão adotadas, neste trabalho, as definições do livro de

Weske (2007), em cujo prólogo, o Prof dr.ir. Wil van der Aalst, reconhecido por Ko (2009)

como proeminente pesquisador da área, prove uma excelente introdução a gestão do processo

de negócio.

3.2.1 Processo de Negócio

Processo de negócio é a tradução feita neste trabalho para o termo inglês Business

Process e comumente abreviado como BP, também adotada nesse trabalho.

Em seu trabalho Ko (2009) explora diversas definições e suas facetas para o processo

de negócio e acaba por adotar a definição de Ould (1995), por ele citado, na qual os processos

de negócio são vistos como séries ou redes de atividades com valor agregado, realizadas pelas

funções ou colaboradores relevantes, para propositadamente atingir metas de negócio comuns.

Trata-se de uma definição próxima a de Weske (2007), adotada neste trabalho, para o qual um

processo de negócio consiste em um conjunto de atividades que são realizadas de forma

coordena em um ambiente técnico-organizacional atendendo a um objetivo do negócio.

Weske (2007) diz ainda que cada processo de negócio é promulgado por uma única

organização, sendo próprio a cada organização.

Segundo Ko (2009), processos de negócio são comumente encontrados dentro de

organizações empresariais e entre organizações existindo muitos tipos de processo de

21

negócio. Como exemplos de processo de negócio, ele destaca: ordens de compra, as

negociações de preço, gerenciamento de transporte, fusão e aquisição, entre outras.

Segundo Ballard et al. (2006), são elementos de um processo de negócio:

a) Entrada: representa o material e informações necessários para completar as

atividades do processo produzindo um resultado final específico;

b) Saída: representa os dados, informações e ativos físicos que o processo gera e,

portanto, valor para a organização contribuindo para a realização das medições de negócios e

objetivos. Pode representar também eventos, ações ou os resultados dessas ações;

c) Eventos: estes são notificações acerca de alguma ocorrência. Podem ocorrer antes,

durante ou depois da execução de um processo. Normalmente indicam o início, status

intermediário ou final de uma atividade do processo. Um evento pode ser uma ação resultante

da conclusão de outro processo (ou atividade do processo), da ocorrência de certa condição,

ou da chegada a um determinado ponto no tempo;

d) Subprocesso: trata-se de um processo ou etapa de processo, dentro de outro

processo. Um subprocesso é definido quando não é possível representar o escopo do trabalho

com apenas um conjunto de atividades. Um subprocesso tem os mesmos elementos de um

processo, trata-se de uma caracterização recursiva;

e) Atividade: é o mais baixo nível de trabalho em um processo;

f) Recurso: representa uma pessoa, organização, equipamento ou sistema utilizado

pelo trabalho no processo;

g) Métricas de desempenho: são atributos que servem para ajudar e orientar os

responsáveis pelo processo a fazer o controle e avaliação de eficiência e eficácia do mesmo.

Figura 3.1 – Elementos de um processo

Fonte: adaptado de Ballard et al., 2006, pag. 60

22

3.2.2 Classificação do BP quanto ao nível operacional

Quanto às possíveis classificações dos processos de negócio uma é particularmente

relevante a este trabalho: a classificação em níveis de operacionalidade (vai desde estratégias

comerciais de alto nível até o processo de negócio implementado).

Weske (2007) descreve os primeiros e mais elevados níveis, aos quais se refere como

organizacionais, da seguinte forma:

1. No mais alto nível, a estratégia da empresa é especificada, descrevendo seus

conceitos de longo prazo para desenvolver uma vantagem competitiva sustentável no

mercado.

2. No segundo nível, a estratégia de negócio é dividida em metas operacionais. Esses

objetivos podem ser organizados, de modo que cada meta pode ser dividida em um conjunto

de submetas.

3. No terceiro nível, se encontram os processos de negócio organizacionais. Processos

de negócio organizacionais são processos de alto nível que normalmente são especificados de

forma textual por suas entradas, saídas, os resultados esperados, e suas dependências em

outros processos de negócio organizacionais. Estes processos de negócio podem atuar como

processos fornecedores ou consumidores.

Segundo Weske (2007), técnicas informais e semiformais são usadas nestes níveis

elevados. A estratégia de uma empresa, seus objetivos, e seus processos de negócio

organizacionais podem ser descritos em textos enriquecidos com diagramas expressos em

uma notação adhoc (superficial) ou semiformal.

Weske (2007) explica então a relação entre processos organizacionais e operacionais

(terceiro e quarto níveis respectivamente), enquanto os processos de negócio organizacionais

caracterizam de grosso modo as funcionalidades do negócio, normalmente há vários

processos de negócio operacionais contribuindo com um processo de negócio organizacional.

Nos processos de negócio operacionais as atividades e seus relacionamentos são especificados

(através de modelos de processo de negócio), mas aspectos de implementação do processo de

negócio são desconsiderados.

Weske (2007) conclui sua caracterização dos níveis dizendo que os processos de

negócio operacionais são a base para o desenvolvimento de processos de negócio

implementados (ultimo nível). Processos de negócio implementados contêm informações

sobre a execução das atividades do processo e o ambiente técnico e organizacional em que

23

eles serão executados. Há várias maneiras de implementar processos de negócio, o ultimo

nível se refere a uma especificação que permite a promulgação do processo em uma

determinada plataforma, seja ela organizacional ou técnica.

Figura 3.2 – Níveis dos processos de negocio.

Fonte: adaptado de Weske, 2007, pag. 18

A Figura 3 adiante, no subcapitulo intitulado “Gestão de Processo de Negócio”, é

apresentado um exemplo onde os BPs são definidos em nível operacional. Weske (2007)

apresenta exemplos para os níveis organizacionais dentro de um mesmo contexto, através

deles podemos entender melhor as 3 primeiras fases:

24

1. Estratégia de negócio: Um exemplo seria buscar a liderança de custo para os

produtos em um determinado domínio. Segundo Stahl e Grigsby (1997) isso significa buscar

o menor custo de operação num domínio da indústria, o que não significa necessariamente

oferecer produtos ou serviços a um menor preço.

2. Meta: Reduzir os gastos com materiais fornecidos é um exemplo de meta que leva a

liderança de custo.

3. Processo de negócio organizacional: um processo de negócio para gerenciar entrada

de matérias-primas fornecidas por um conjunto de fornecedores seria um exemplo de

iniciativa para reduzir os gastos com materiais fornecidos.

3.2.3 Gestão de Processo de Negócio

Gestão de Processo de Negócio é a tradução feita nesse trabalho para o termo em

inglês Business Process Management, comumente abreviado como BPM, abreviação esta

adotada nesse trabalho.

Segundo Ko (2009) a tecnologia da informação foi aproveitada para gerenciar

processos de negócio, formulários anteriormente preenchidos manualmente foram

crescentemente substituídos por suas contrapartes eletrônicas, o que resultou na origem da

Gestão de Processos de Negócio.

Segundo Weske (2007) a gestão de processos de negócio inclui conceitos, métodos e

técnicas para apoiar a concepção, administração, configuração, promulgação e análise de

processos de negócio. Para Weske (2007) a base da gestão de processos de negócio é a

representação explícita dos processos de negócio com suas atividades e as restrições de

execução entre elas.

Algumas definições adaptadas de Weske (2007) necessárias a compreensão prática da

gestão do processo de negócio:

a) Sistema de gestão de processos de negócio (do inglês Business Process

Management System, abreviado BPMS): é um sistema de software genérico impulsionado

pela representação explícita dos processos com objetivo de coordenar a promulgação dos

processos de negócio.

b) Modelo de processo de negócio: consiste em um conjunto de modelos de atividade

e as restrições de execução entre eles. Cada modelo de processo de negócios funciona como

um blueprint (um detalhado plano de ação) para um conjunto de instâncias de processos de

negócio.

25

c) Instância do processo de negócio: representa um caso concreto no negócio

operacional de uma empresa, composto de instâncias de atividade. Cada modelo de atividade

funciona como um blueprint para um conjunto de instâncias de atividade.

d) Orquestração de processo: refere-se ao controle centralizado dos processos de

negócio de uma empresa por um sistema de gestão de processos de negócio de modo análogo

a um maestro que centralmente controla os músicos de uma orquestra. Isso é possível uma vez

que os processos de negócio são realizados em uma única organização, sendo próprios desta

conforme definido anteriormente.

e) Coreografia de processos: compreende a especificação das interações de um

conjunto de processos de negócio. O termo coreografia indica a ausência de um agente central

que controla as atividades nos processos de negócio envolvidos. A interação só é alcançada

através do envio e recebimento de mensagens. A fim de realizar interações de forma correta,

os processos de negócio que interagem precisam concordar sobre uma coreografia comum

antes de começar a interagir.

Na figura 3.3 estão representados dois processos de negócio (Comprador e

Revendedor), o fluxo de ação por eles compreendido e a troca de mensagens feita entre os

dois de modo a formar uma coreografia. Neste exemplo foi usada a notação BPMN que será

discutida mais a frente.

Figura 3.3 – Processos de negócio interagindo e formando uma coreografia de processos


26

3.2.4 Ciclo de Vida do Processo de Negócio

O ciclo de vida do BP, segundo Weske (2007), consiste, resumidamente, em:

1. Design e Análise: nesta etapa, processos de negócio são identificados, analisados,

validados e representados por modelos de processo de negócio.

2. Configuração: nesta etapa o processo de negócio deve ser implementado. Em geral

o sistema de gestão de processos de negócio precisa ser configurado de acordo com o

ambiente organizacional da empresa e os processos de negócio, cuja promulgação ele deve

controlar. Esta configuração inclui as interações dos funcionários com o sistema, bem como a

integração dos sistemas de software existente com o sistema de gestão de processo de

negócio.

3. Promulgação: nesta etapa instâncias de processos de negócio são promulgadas.

Esta etapa engloba a execução em tempo real do processo de negócio. O BPMS controla

ativamente a execução de instâncias de processos de negócio, tal como definido no modelo de

processo de negócio. A promulgação do processo precisa atender a uma correta orquestração

dos processos, garantindo que as atividades do processo são realizadas de acordo com as

restrições de execução especificadas no modelo de processo.

4. Diagnóstico: a fase de avaliação utiliza as informações disponíveis para avaliar e

melhorar os modelos de processos de negócio e suas implementações. Logs de execução são

avaliados por meio do monitoramento de atividades de negócio e técnicas de mineração de

processo. Estas técnicas visam identificar a qualidade dos modelos de processo de negócio e a

adequação do ambiente de execução.

5. Administração e Envolvidos: O domínio de processos de negócio é caracterizado

por ter vários tipos de profissionais envolvidos, com diferentes saberes, conhecimentos e

experiência. Estes diferentes tipos de profissionais devem cooperar estreitamente na

elaboração de processos de negócio e no desenvolvimento de soluções adequadas para

promulgá-los.

27

Figura 3.4 – Ciclo de vida do processo de negócio


Ko (2009) propõe em seu trabalho um processo de seis passos intitulado como

processo de modelagem de processos de negocio, que segundo ele próprio tem estreita relação

com o ciclo de vida do processo de negocio. Os seis passos por ele propostos:

Passo 1 — Necessidades do Negócio: Envolve a identificação de uma necessidade e

definição de uma meta de negócio em alto nível (equivalente ao segundo nível operacional da

Figura 2).

Passo 2 — Definições de Meta de Negócio: Envolve o levantamento de requisitos e

concepção de uma visão de alto nível das etapas do processo em questão (equivalente ao

terceiro nível operacional da Figura 2).

Passo 3 — Detalhes dos Diagramas de Processo de Negócio: Envolve a modelagem de

processos de negócio em um padrão gráfica facilmente interpretável e formal (e.g., BPMN).

Passo 4 — Traduzir Diagramas para Código Executável: Usa-se uma ferramenta que

suporta padrões de intercâmbio (e.g., XPDL) para traduzir automaticamente o modelo gráfico

de processo de negócio no código executável (e.g., BPEL).

28

Passo 5 — Código de Execução: o código será verificado e os ajustes necessários

serão feitos. Após testes e aprovação, o processo de negocio será publicado no BPMS.

Passo 6 — Processos de Negócio Executáveis: O BPMS contém um componente

chamado de motor, trata-se de um software que gerencia o encaminhamento e execução

adequados de todas as instâncias de BP para as fases e pessoas corretas. O BP esta enfim em

vigor.

É importante notar que Ko (2009) enxerga o ciclo de vida do BP de forma menos

abrangente do que Weske (2007), sendo os passos 1 e 2 do processo em questão

compreendidos na etapa de Design e Análise do ciclo de Weske (2007). O nome processo de

modelagem de processos de negocio é infeliz, não apenas pela desagradável repetição da

palavra processo, mas também por haver muito mais do que modelagem envolvido neste

processo, parece que Ko (2009) pensa num caso particular do ciclo de vida no qual haveria

apenas a implementação desprovida de um esforço de melhoramento continuo dos processos,

quebrando a idéia de ciclo. A despeito daquilo que Ko (2009) pudesse ter em mente ao definir

o tal processo de modelagem de processos de negocio, este não apenas ajuda a entender

melhor o ciclo de vida do BP, mas serve também para junto a este pensar no processo de

desenvolvimento de um jogo de empresas dada a arquitetura proposta, o que será feito

adiante.

Ko (2009) observa que há lacunas entre a teoria, os padrões e os sistemas BPM. A

figura abaixo indica que a definição de padrões e normas se baseia na teoria da gestão de

processos de negócio sendo por sua vez adotadas em sistemas e software. Ko (2009) diz ainda

que a heterogeneidade de técnicas de modelagem de processos de negócio constitui um

problema notório para a área da gestão de processos de negócio sendo estas técnicas distintas

quanto às áreas de aplicabilidade (sugere BPM, SOA e B2B), uso e reconhecimento (de jure e

de facto), por exemplo.

29

Figura 3.5 – A relação entre teoria, padrões e sistemas BPM.

Fonte: adaptado de Ko, 2009, p. 16

3.2.5 Gestão de Workflow

Workflow é um termo inglês que pode ser traduzido como fluxo de trabalho. Segundo

Weske (2007), uma conquista importante da gestão de workflow é a representação explícita

de estruturas de processo em modelos de processo bem como a promulgação controlada de

processos de negócio de acordo com estes modelos. Diz ainda que esta abordagem, dirigida a

modelos, possibilita um alto grau de flexibilidade, porque os modelos de processo podem ser

adaptados para cumprir novas exigências e ser imediatamente usados para promulgar

processos de negócio.

O Workflow Management Coalition define workflow e sistemas de gestão de

workflow da seguinte forma:

1. Workflow é a automação de um processo de negócio, no todo ou em parte, durante

o qual documentos, informações ou tarefas são passadas de um participante ao outro para

tomada de ação, de acordo com um conjunto de regras processuais.

2. Um sistema de gerenciamento de workflow é um sistema de software que define,

cria e gerencia a execução de workflows através do uso de software, rodando em um ou mais

motores de workflow, que são capazes de interpretar a definição do processo, interagir com os

30

participantes do workflow e, quando necessário, invocar o uso de ferramentas de TI e

aplicações.

Quanto a sua aplicação Weske (2007) diz que a tecnologia de workflow é capaz de

suportar processos de negócio dentro de um dado sistema de aplicativo ou entre um conjunto

de sistemas aplicativos, de forma a integrar eficazmente estes sistemas. Mas a tecnologia de

workflow também pode ser utilizada para promulgar processos de negócio em que humanos

estão ativamente envolvidos, melhorando assim a colaboração entre os trabalhadores.

Segundo Weske (2007) tradicionalmente a lógica do processo é definida no código da

aplicação, o que dificulta alterações na nesta, porém a tecnologia de gestão de workflow pode

ser usada para facilitar a modificação da lógica do processo realizado por aplicativos. As

funções de um sistema de aplicação são as etapas do workflow, e um componente de

workflow utiliza um modelo de workflow para promulgar as funções. Pela modificação da

lógica de processo especificada em modelos de workflow, o comportamento do sistema de

aplicação pode ser modificado sem codificação.

Segundo Weske (2007), a maioria dos sistemas de aplicação empresariais, tais como

sistemas de planejamento de recursos empresariais (ERP – Enterprise Resource Planning),

hospedam um componente de workflow que facilita a personalização flexível de processos de

negócio dentro destes sistemas. Observe que, em vez do termo sistema de gerenciamento de

workflow, o termo componente de workflow é usado, porque um componente de workflow

não é um sistema de software stand-alone, mas sim, incorporado na aplicação.

Na definição de Weske (2007) um workflow de única aplicação consiste em atividades

e sua ordenação causal e temporal que são realizadas por um sistema de aplicação comum.

Workflows de múltiplas aplicações contêm atividades que são realizadas por múltiplos

sistemas de aplicação, proporcionando uma integração destes sistemas.

31

Figura 3.6 – Arquitetura de sistemas de workflow de única aplicação.


Weske (2007) explica que na arquitetura de um sistema de workflow de um único

aplicativo, mostrada na Figura 6, há um componente de workflow dedicado que é alimentado

com modelos de workflow que captam a lógica do processo, bem como informação sobre a

execução técnica. O componente de workflow usa funções realizadas pelo aplicativo e fornece

processos para o nível superior, a interface gráfica do usuário. Já no caso de um workflow de

múltiplas aplicações, um sistema de gestão de workflow dedicado garante que os sistemas de

aplicação sejam invocados conforme especificado no modelo de processo. Além disso, a

transferência de dados entre os sistemas de aplicação também é cuidado pelo sistema de

gestão de workflow.

32

Figura 3.7 – Arquitetura de sistemas de workflow de múltiplas aplicações.


Weske (2007) distingue workflows em duas outras categorias: os de sistema e os de

interação humana.

Segundo Weske (2007) em workflows de sistema, as atividades de workflow são

executadas automaticamente por sistemas de software, não havendo, portanto, interação entre

trabalhadores e a aplicação. Em sua definição um workflow de sistema consiste em atividades

que são executadas por sistemas de software, sem qualquer envolvimento do usuário.

Segundo Weske (2007), workflows de interação humana tipicamente compreendem

partes de um processo de negócio maior, que tem partes automatizadas e não automatizadas.

O objetivo dos workflows de interação humana é apoiar eficazmente as partes automatizadas

dos processos de negócio controlando ativamente as atividades realizadas de acordo com

modelos de processo. Ele define os workflows interação humana como workflows nos quais

os humanos estão ativamente envolvidos e interagem com os sistemas de informação.

Ainda acerca dos workflows de interação humana, Weske (2007) diz que estes

requerem conceitos de interface gráfica particulares. O principal conceito é a lista de itens de

trabalho. Trabalhadores interagem com o sistema usando listas de itens de trabalho, sempre

que um trabalhador puder realizar uma atividade do processo, ele ou ela é informado por um

item na sua lista de itens de trabalho. Quando o item é selecionado, o respectivo aplicativo é

iniciado, e os dados de entrada são fornecidos. Quando a atividade for concluída, o

33

trabalhador informa a aplicação de workflow. O sistema de gestão de workflow em seguida,

computa o estado atual e determina as próximas atividades.

3.2.6 Distinção entre BPM e Gestão de Workflow

Em seu trabalho, Ko (2009) aponta que há dois pontos de vista pelo qual é possível

fazer a distinção entre BPM e a Gestão de Workflow. Um ponto de vista é do Gartner

Research, segundo o qual Business Process Management (BPM) é uma disciplina de gestão

orientada a processos e não é uma tecnologia, e workflow é uma tecnologia de gerenciamento

de fluxo encontrada em sistemas de gestão de processos de negócio (BPMS) e outras

categorias de produtos. A tabela abaixo mostra outro ponto de vista, por van der Aalst et al.

(2003), segundo o qual as funcionalidades da gestão de workflow são um subconjunto

daquelas do BPM sendo a fase de diagnóstico do ciclo de vida do BPM a principal diferença.

Figura 3.8 – Utilização do ciclo de vida do BPM para comparar a gestão de workflow com a gestão de

processos de negócios por Van der Aalst et al. (2003).

Fonte: adaptado de Ko, 2009, pag. 15

ESTÁGIO DO CICLO

DE VIDA BPM

GESTÃO DE

WORKFLOW

GESTÃO DE

PROCESSO DE

NEGÓCIO

Design Sim Sim

Configuração Sim Sim

Promulgação Sim Sim

Diagnostico Fraco Sim

Tabela 3.2: Gestão de Workflow e BPM comparados.

Fonte: adaptado de Ko, 2009, pag. 15

34

Os pontos de vista não se anulam e nenhum deles destoa daquilo que é apresentado

por Weske (2007) em seu livro. A única ressalva é de que um workflow não necessariamente

é uma tecnologia como apresentado pela Gartner. Vale lembrar também que os ciclos de vida

levam em conta a implementação da teoria, sendo ambos, workflow e BPM, implementáveis.

Na figura abaixo Weske (2007) representa através de UML as relações entre conceitos

de modelagem de processo de negócio citados nesse trabalho. É interessante destacar que para

Weske (2007) o workflow não é uma subclasse do BP uma vez que concretiza uma parte do

BP, sendo assim, o workflow não possui uma relação “é-um” com o BP, mas sim uma

associação.

Figura 3.9 – Processo de Negócio: modelo conceitual.

Fonte: adaptado de Weske, 2007.

3.2.7 Implicações na arquitetura proposta

No trabalho de Roudaky e Doroodchi (2009), cujo objetivo é tornar o processo por trás

dos jogos de computador visível e simples de compreender, é proposto o uso do workflow

para mapear a interação entre o usuário e o jogo, no caso uma interação analógica com o

controle (usuário pressiona botões para manifestar suas escolhas) resulta numa resposta

pseudo-analógica equivalente no mundo virtual do jogo. É possível abstrair esse uso do

workflow para a interação em jogos de empresas, que se da pelo passar das rodadas de jogo

35

em resposta ao envio das escolhas feitas pelos alunos.

Segundo Roudaky e Doroodchi (2009) jogos de computador também podem ser

considerados como processos e, conseqüentemente, podem ser modelados usando workflow.

Shubik (2002) diz que um jogo é definido por suas regras formais e informais. As regras

formais são explicitadas, enquanto as informais estão contidas no contexto dos arredores e

situações nas quais o jogo é jogado. Para Shubik (2002), juntas, as regras provêm os

portadores do processo. Jogos de empresas, assim como qualquer jogo, também seguem

regras e podem ser considerados como processos, portanto, também podem ser modelados

através de um workflow.

A sequência de passos de desenvolvimento para jogos de computador proposto por

Roudaky e Doroodchi (2009):

1. Definir os objetivos do jogo, principais objetos e cenários;

2. Realizar a análise de workflow sobre os cenários, e criar o diagrama de workflow

do jogo;

3. Criar os objetos na cena;

4. Desenvolver o código usando o diagrama de workflow;

5. Testar o software.

Neste trabalho, assim como no trabalho de Roudaky e Doroodchi (2009), não é o

objetivo discutir aspectos dos jogos de computador como objetos e cenários, bastando à

compreensão dos passos de desenvolvimento de um modo geral. Abaixo estão os passos para

se fazer a análise de workflow segundo o próprio Roudaky e Doroodchi (2009), esclarecendo

o passo 2 do desenvolvimento que pode ser aplicado pelo professor ao conceber o jogo de

empresas (que seguirá um workflow por ele definido):

a) Primeiro pensamos no jogo como um grande processo com uma atividade, sendo

depois dividido em mais atividades.

b) Para expandir uma atividade, partimos dos pontos de entrada. Um ponto de entrada é o

evento que ativa ou desencadeia um processo. Na maioria dos casos, os pontos de

entrada são os resultados de interações do usuário com o jogo.

c) Depois de identificados os pontos de entrada, todas as atividades que vão ser

executadas devem ser listadas e esboçadas em um diagrama de workflow.

d) Para cada cenário, o modelo de workflow é formado.

e) Mais tarde, esses workflows individuais são combinados com base em suas interações

e mecanismos de sincronização. Em outras palavras, o workflow do jogo global será

formado por esses workflows individuais.

36

Como dito anteriormente, um BPM pretende apoiar a concepção, administração,

configuração, promulgação e análise dos processos de negócio, sendo este abrangente

objetivo alcançado através das etapas compreendidas no ciclo de vida do processo de negócio.

A arquitetura proposta neste trabalho para a criação de jogos de empresa personalizados

sugere um processo de desenvolvimento próximo a esse, uma vez que tem um objetivo

similar, conforme definição no capítulo 1.3.

Considerando o ciclo de vida do processo de negocio de Weske (2007), o processo de

modelagem de processos de negocio de Ko (2009) e os passos de desenvolvimento de jogos

de Roudaky e Doroodchi (2009), é proposto aqui o seguinte processo para o desenvolvimento

de jogos de empresas:

1. Design: nesta etapa o professor deve definir como será o jogo de empresas, qual

será o fluxo do jogo e como serão as fases do mesmo. Essa etapa pode ser feita em papel, ela

envolve a criação do jogo em si. O professor tem diversos aspectos a levar em conta nesta

etapa, mas vale lembrar que decisões de nível organizacional (estratégia, metas e processos

organizacionais), devem ser pensadas e cobradas dos jogadores nas rodadas de jogo. Portanto

a relação entre BPM e nossa arquitetura se da também quanto ao conteúdo do jogo. Contudo,

os níveis abaixo dos organizacionais fogem ao propósito didático dos cursos de administração

e nossa arquitetura não permite o trabalho sobre tais processos. Sendo assim, a avaliação das

empresas dos alunos no jogo não contempla a gestão dos processos de negócio, apesar deste

ser um fator competitivo importante.

2. Configuração: nossa arquitetura propõe a existência de uma interface que permita a

modelagem de um diagrama que define o workflow de jogo, bem como a configuração dos

módulos pré-programados. Nesta etapa, o professor deve, então, transcrever aquilo que tem

em mente para o software de apoio ao desenvolvimento de jogos personalizados. É possível

que a arquitetura não atenda as necessidades do professor em situações onde este quer algo

mais sofisticado ou personalizado, nesse caso ele pode contratar profissionais de computação

para mexer no código.

3. Promulgação: Com o código automaticamente gerado, e possivelmente

personalizado, em mãos, o professor precisa aplicá-lo aos seus alunos. Nossa arquitetura

propõe que haja uma interface de administração através da qual o professor pode controlar a

aplicação do jogo, tanto quanto a sua disponibilidade como quanto a outros aspectos de jogo

(ex: alterações no cenário do mercado do jogo em uma dada fase). Os alunos têm acesso ao

jogo via web.

37

4. Análise: O processo pode se tornar cíclico se for adicionada esta etapa ao processo,

pois essa etapa remete a etapa de design ao fornecer feedback que pode ser refletido em

alterações do jogo. Contudo essa etapa não será explorada nesse trabalho, ficando a ideia

disponível para trabalhos futuros. Vale lembrar que ao final do jogo é feita uma avaliação dos

alunos, trata-se de mais uma fase do jogo, nada tem haver com essa etapa onde são

apresentados parâmetros quanto ao desenrolar do jogo em geral.

Sendo assim a arquitetura proposta permite ao professor a concepção,

desenvolvimento e aplicação de seus próprios jogos de empresas, fornecendo a ele um recurso

que permite uma fácil tradução da ideia em código, bem como a utilização do código em

forma de jogo.

A gestão de workflow tem papel fundamental na arquitetura proposta neste trabalho,

pela mesma razão que ela tem no BPM: possibilita um alto grau de flexibilidade uma vez que

o comportamento da aplicação pode ser modificado sem codificação por parte do professor.

Na arquitetura proposta deve haver um componente de workflow de única aplicação,

gerado a partir dos dados fornecidos pelo professor na etapa de configuração, trata-se de um

objeto Java que determina qual módulo estará ativo, ele o faz chamando outros componentes

Java. O workflow proposto é de interação humana e, portanto, conceitos de interface gráfica

particulares, como a lista de itens se aplicam, contudo neste trabalho será abordada apenas a

lista de itens na forma de cobranças feitas pelo professor a cada rodada.

Na arquitetura proposta os conceitos de orquestração e coreografia não se aplicam, o

primeiro porque não há vários processos a serem coordenados, trata-se de um único grande

processo, o segundo porque não há interação desse processo com outros processos.

3.3 Teoria dos Jogos

A teoria dos jogos é uma teoria matemática que modela fenômenos que podem ser

observados quando dois ou mais agentes de decisão interagem entre si (SARTINI, 2004).

Embora sua consolidação só se tenha dado no século XX, existem registros históricos

da utilização dessa ferramenta pelo menos dois séculos antes. Nos últimos 100 anos, os

principais pesquisadores e estudiosos fundamentaram sua estrutura e confirmaram

matematicamente as proposições teóricas (SARTINI et. al, 2004).

Atualmente esta teoria é utilizada por outras áreas de estudo, como política, biologia e

economia. Esta, sobretudo, tem utilizado a teoria dos jogos em fenômenos que envolvem

38

decisões como é o caso dos leilões, das eleições e das barganhas (SARTINI et. al, 2004;

COSTA, 2004).

Este capítulo permite uma melhor compreensão da constituição dos jogos de empresas

ao fundamentar a teoria dos jogos nele empregada.

3.3.1 Histórico

A primeira demonstração formal que deu origem à teoria dos jogos apareceu em 1913

com a publicação do modelo matemático do alemão Ernst Zermelo. Nele, o matemático

alemão provava que o jogo de xadrez era estritamente determinado, ou seja, em cada jogada,

o jogador possui uma estratégia para vencer ou empatar com o adversário (SARTINI et. al,

2004).

Em 1928, o matemático John Von Neumann demonstrou que todo jogo finito de soma

zero com duas pessoas possui uma solução em estratégias mistas. Em 1937, fez a mesma

demonstração, mas utilizando-se do teorema do ponto fixo de Brouwer, e em conjunto com o

economista Oskar Morgenstein (SARTINI et. al., 2004). Em 1944, publicam em parceria The

Theory of Games and Economic Behaviour, obra acerca dos fundamentos da Teoria dos

Jogos, enfocando os jogos de estratégia, que não dependem apenas da sorte, mas

principalmente das escolhas feitas pelos jogadores (COSTA, 2004).

Logo após a Segunda Guerra Mundial, em 1950, o matemático americano John Forbes

Nash Jr. publicou quatro artigos essenciais para a teoria dos jogos. Neles, descrevia suas

teorias sobre jogos cooperativos e não-cooperativos e barganha (SARTINI et. al, 2004). Em

1994, Nash foi laureado com o prêmio Nobel de Economia por suas contribuições à teoria dos

jogos cultivada às ciências econômicas.

Já consolidada na matemática aplicada, a teoria dos jogos expandiu-se para outras

áreas, como a política e a biologia, a partir dos anos 70. As ciências que a utilizavam viam-na

como um promissor método de analisar situações estratégicas. Uma década antes, ainda,

Thomas Schelling se destaca por romper o isolamento da teoria dos jogos à matemática,

aplicando-a nas ciências sociais (CARMICHAEL, 2005).

3.3.2 Definição de jogos

Sartini et. al. (2004) definem formalmente a teoria dos jogos como “a teoria dos

modelos matemáticos que estuda a escolha de decisões ótimas sob condições de conflito”.

39

Segundo o Dicionário Aurélio (2006), o jogo é “uma atividade física ou mental

fundamentada em sistema de regras que definem a perda ou o ganho”. Com esta definição,

Costa (2004) vê em Von Neumann a utilização desse sentido sob a ótica da economia.

Segundo a autora, jogos são situações de interesse competitivo onde cada jogador visa

maximizar seus ganhos.

Basicamente, um jogo é composto por dois ou mais jogadores (COSTA, 2004), que

são os participantes do jogo (CARMICHAEL, 2005). Cada um deles possui um conjunto de

estratégias e cada estratégia escolhida pelo jogador é definida como uma situação no espaço

de todas as situações possíveis (SARTINI et. al, 2004).

Um jogo pode ser definido como um conjunto finito de jogadores ,

sendo que cada possui um conjunto finito de estratégias .

Sendo , para cada estratégia escolhida do jogador tem-se um vetor

denominado situação, que indica qual é o perfil de estratégia pura

elegido. Ainda, cada jogador possui uma função utilidade que associa o ganho, ou

payoff, a cada situação , onde é espaço de situações, formado pelo produto

cartesiano de todas elas (OLIVEIRA; ARAÚJO; CÂMARA, 2010; SARTINI et. al., 2004):

3.3.3 Tipos de jogos

As referências (CARMICHAEL, 2005; SARTINI et. al., 2004; GIBBONS, 1992;

COSTA, 2004) sobre teoria dos jogos mostram que os diversos jogos existentes podem ser

classificados de várias formas. Sobre essas classificações, este trabalho apresentará apenas

algumas, a fim de que os principais conceitos sobre a teoria possam ser compreendidos

objetivando a leitura e os resultados da presente pesquisa.

Carmichael (2005) diz que os jogos são, muitas vezes, classificados pela forma como

os jogadores se movem. Como por esta razão a autora escolheu classificar os jogos de

estratégia conforme a movimentação, é possível qualificar o jogo como sendo de

movimentação simultânea ou movimentação sequencial. Embora com nomes distintos, outros

autores como Felegyhazi e Hubaux (2006) e Gibbons (1992) também realizam a distinção

entre jogos de acordo com este critério.

40

Jogos de movimento simultâneo são aqueles em que os jogadores movem-se ao

mesmo tempo ou em que seus movimentos não são vistos pelos demais jogadores. Neste caso,

os jogadores estabelecem suas estratégias com base no que pensam que os outros jogadores

poderão fazer (CARMICHAEL, 2005). Comumente esse tipo de jogo é analisado através da

matriz de payoff’s (Figura 1). Nela, é apresentada a avaliação dos resultados obtidos (payoff)

dos jogadores para cada possível situação de ganho e de perda, respectivamente.

Figura 3.10 – Matriz de payoff’s representando o clássico dilema do prisioneiro.

Fonte: Autores “adaptado de” Sartini et. al., 2004, p. 7

Sartini et. al. (2004) exemplifica o dilema do prisioneiro, expresso na matriz de

payoff’s da Figura 3.10, da seguinte forma: “dois ladrões, Al e Bob, são capturados e

acusados de um mesmo crime. Presos em selas separadas e sem poderem se comunicar entre

si, o delegado de plantão faz seguinte proposta: cada um pode escolher entre confessar ou

negar o crime. Se nenhum deles confessar, ambos serão submetidos a uma pena de 1 ano. Se

os dois confessarem, então ambos terão pena de 5 anos. Mas se um confessar e o outro negar,

então o que confessou será libertado e o outro será condenado a 10 anos de prisão”. Esse jogo

esclarece as implicações de um jogo de movimento simultâneo, a estratégia que melhor

defende os interesses próprios de cada prisioneiro é confessar, contudo uma vez que ambos

confessem defendendo seus interesses próprios, ambos enfrentarão uma pena maior do que se

ambos tivessem negado, trata-se de uma situação paradoxal gerada pela desconfiança no

próximo, que, a princípio, pensa apenas em si próprio e não hesitaria em confessar se

soubesse que o outro vai negar ainda que seja esta postura o que impossibilita ambos os

prisioneiros de pegar uma pena menor, que é o objetivo de ambos.

Já jogos de movimento sequencial caracterizam-se por seu conjunto de movimentos

estar previamente ordenado para cada jogada. Carmichael (2005) explica que, neste caso, um

jogador realiza o primeiro movimento e outro jogador, ou jogadores, realiza o próximo

movimento, conhecendo o movimento do primeiro jogador. Diferentemente dos jogos de

41

movimento simultâneo, os jogadores dos jogos de movimento sequencial fundamentam suas

decisões a partir dos movimentos do adversário.

Outra classificação bastante importante descrita por Carmichael (2005) – e também

por Nash (1951) e Nisan et. al. (2007) – é a da cooperação dos jogadores no jogo. Os autores

consideram o jogo em cooperativo ou não-cooperativo.

Carmichael (2005) descreve que jogos cooperativos são aqueles em que aos jogadores

é permitida a comunicação e a realização de quaisquer acordos sobre como jogar.

Drew (1986) descreve que “a teoria dos jogos não-cooperativos é o modo de modelar e

analisar situações em que cada decisão ótima do jogador depende de suas crenças ou

expectativas sobre o jogo de seus oponentes“. Nisan et. al. (2007) complementam essa

definição dizendo que os agentes dos jogos não-cooperativos atuam individual e

egoisticamente, fugindo da solução proposta e buscando os próprios interesses.

A arquitetura proposta neste trabalho pressupõe a concepção de jogos não-

cooperativos, embora em salas de aula talvez os alunos possam eventualmente se comunicar e

seja possível a concepção de jogos cooperativos nesse contexto, ainda assim a arquitetura

proposta não prevê qualquer meio de comunicação para facilitar a aplicação de jogos

cooperativos.

Quanto movimento a arquitetura proposta permite a concepção de jogos simultâneos,

sequenciais ou até mesmo híbridos, nos quais a informação a principio não esta disponível,

mas pode ser obtida pelos jogadores através do dispêndio de recursos disponíveis.

A teoria dos jogos se mostra relevante por possibilitar a modelagem de problemas que

serão enfrentados pelos jogadores nas tomadas de decisão impostas pelo jogo de empresas,

que simula situações reais nas quais a teoria do jogo é aplicada na busca de soluções.

Problemas conhecidos como o dilema do prisioneiro exemplificam situações que serão

enfrentadas pelos jogadores sendo o conhecimento desses problemas importante para a

concepção do jogo em si por parte do professor bem como para a formação dos alunos.

42

4 ARQUITETURA COMPUTACIONAL DE JOGOS DE EMPRESA

A proposição de uma arquitetura computacional para a construção de jogos de

empresa é o objetivo deste trabalho. Na finalidade de melhor compreensão do que seja uma

arquitetura, este capítulo distingue e define o que é uma arquitetura sob as óticas geral,

computacional e de jogos de empresa.

No âmbito geral, é apresentada uma definição utilizada também em outras áreas de

estudo. No âmbito computacional, é apresentada uma exposição do conceito de modo que a

compreensão de parte do objetivo deste trabalho seja alcançada. Na área de jogos de empresa,

a arquitetura é colocada na visão das abordagens de design dos simuladores com foco na

construção computacional. Durante o capítulo também é descrita a utilização e a aplicação do

conceito exposto no projeto.

4.1 Definições de Arquitetura

Segundo o Dicionário Aurélio (2006), a arquitetura é arte de edificar. Utilizando-se

dessa etimologia e estendendo o sentido, o Dicionário Houaiss (2009) define também

arquitetura como:

1. arte e técnica de organizar espaços e criar ambientes para abrigar os diversos tipos

de atividades humanas, visando tb. a determinada intenção plástica; 2.conjunto das

obras arquitetônicas executadas em determinado contexto histórico, social ou

geográfico. [...]. 5. conjunto de princípios e regras que são base de uma instituição; 6.

conjunto de elementos que perfazem um todo; estrutura, natureza, organização. [...]

(DICIONÁRIO HOUAISS, 2009).

As duas últimas definições da citação acima são, talvez, as mais próximas daquela a

qual este trabalho pretende alcançar, apresentando o conceito de arquitetura computacional de

jogos de empresa. Nos capítulos 5.1, 5.6 e 5.7 são descritas as especificações da arquitetura:

seus princípios e regras (limitações) de funcionamento.

Em sistemas computacionais, a arquitetura pode ser vista como uma composição de

três componentes: organização física; controle e fluxo de informações; e representação,

interpretação e transformação da informação (REDDI; FEUSTEL, 1976). Na arquitetura

proposta, os três componentes são apresentados no capítulo 5.

Outra definição na área computacional, já aplicada à área de software, é dada por

Booch, Rumbaugh e Jacobson (1999):

Uma arquitetura é o conjunto de decisões significativas sobre a organização de um

sistema de software, a seleção dos elementos estruturais e as suas interfaces pelo qual

43

o sistema é composto, juntamente com o seu comportamento como especificado nas

colaborações entre esses elementos em subsistemas progressivamente maiores e o

estilo arquitetural que guia essa organização: os elementos, as interfaces, suas

colaborações e sua composição (BOOCH, RUMBAUGH, JACOBSON, 1999 apud

LARMAN, 2001).

No capítulo 5, são descritos em detalhes os elementos da arquitetura proposta e suas

relações entre si, bem como a especificação que guia a construção e a colaboração desses

elementos.

Quando a arquitetura é colocada no âmbito do design de jogos de empresa, outra

definição costuma aparecer. Por referir-se a algo mais específico e que vai além de um

simples jogo ou da própria construção do software enquanto jogo, a arquitetura de jogos de

empresa trata dos elementos estruturais do jogo e das suas abordagens de design. Nos

próximos subcapítulos serão apresentados os principais elementos estruturais de um jogo

empresarial e uma breve descrição das abordagens de design mais conhecidas, bem como suas

aplicações neste trabalho.

4.2 Elementos Estruturais do Design de Jogos de Empresa

Entre as inúmeras abordagens de design de simuladores de jogos de empresa

existentes, é possível conhecer quais os elementos estruturais principais comuns a todas elas.

O trabalho de Westphal e Lopes (2007) identificou quais são esses elementos e como eles são

integrados na abordagem escolhida.

Westphal e Lopes (2007) identificaram quatro elementos estruturais mínimos que

compõem um simulador empresarial: cenários, decisões, modelagem de algoritmos e métodos

de avaliação do desempenho dos participantes. É importante alertar que esses elementos são

considerados pelo desenvolvimento de simuladores, foco da abordagem utilizada neste

trabalho. Sendo assim, outras considerações, como interações entre os jogadores e aspectos

sociais não são discutidas, não são discutidas.

A Figura 4.1 mostra o relacionamento desses elementos no design de simuladores.

44

Figura 4.1 – Matriz de Relacionamento de Elementos Estruturais

Fonte: Autores

Segundo Teach (1990) apud Westphal e Lopes (2007), um cenário é uma descrição da

indústria que está sendo simulada e das empresas. Um cenário contém referências para as

variáveis externas à empresa e referências para as variáveis internas que o afetam. Em suma,

um cenário descreve a economia na qual a empresa é operada e qual é o efeito dessa economia

nos concorrentes da empresa.

Goosen (1981) apud Westphal e Lopes (2007) propõe o desenvolvimento de duas

estruturas como método Westphal e Lopes (2007) de identificação do cenário: verbal e

matemática. Enquanto a primeira trata da linguagem que é utilizada no jogo, a segunda refere-

se à modelagem matemática que é utilizada na construção do jogo pela ferramenta

computacional.

Neste trabalho, o cenário foi identificado segundo o critério de Waggener (1982), cuja

proposta tem como objetivo a expansão da simulação. Nessa proposta, os jogadores aplicam

os conceitos da Administração na simulação a partir de cenários criativos idealizados pelo

professor.

Westphal e Lopes (2007) alertam que um dos maiores problemas na definição do

cenário está na quantidade de informações que são disponibilizadas ao participante. Neste

projeto, a escolha dessa proposta se deu pela flexibilidade que ela tem em permitir que o

próprio professor seja o interpretador do cenário, não cabendo à arquitetura nem a este

trabalho solucionar esse problema. O detalhamento do cenário é descrito nos capítulos 5.6 e

5.7.

O segundo elemento estrutural mais comum no design de jogos empresariais é a

decisão. Segundo Goosen, Jensen e Wells (1999) apud Westphal e Lopes (2007), o conjunto

de decisões estratégias e táticas são relacionadas entre si a partir de algoritmos que modelam

45

as funções matemáticas das áreas de estudo da Administração, como a Contabilidade, as

Finanças, o Marketing, entre outros.

Como a arquitetura proposta neste projeto visa a contemplar a flexibilidade das

operações idealizadas pelo usuário (professor) e limita-se a não interferir em seus processos

de escolha de modelagem de workflows, a variável de decisão é colocada sob a

responsabilidade do professor.

Embora diretamente ligado à computação, o terceiro elemento estrutural também é

colocado sob a responsabilidade do professor. A modelagem de funções e algoritmos faz parte

dos procedimentos de tomada de decisão que o professor escolhe quando opta por qual

estratégia de decisão no design é a mais adequada ao jogo. Segundo Teach (1990) apud

Westphal e Lopes (2007), um algoritmo é um procedimento operacional que envolve

equações que combinam fatos históricos, decisões e condições econômicas para calcular

resultados.

Por fim, tem-se a avaliação de desempenho dos jogadores, que é um parâmetro para

determinar o vencedor do jogo (WESTPHAL; LOPES, 2007). Entre as diversas

possibilidades existentes para determinar um vencedor, este projeto decidiu por escolher o

mais comum nos jogos de empresa. Uma pesquisa feita por Anderson e Lawton (1990)

apontou que 92,5% dos professores avaliam o desempenho dos jogadores sobre outros

jogadores. Este método de avaliação objetiva priorizar o desempenho competitivo e consiste

em:

a) analisar comparativamente o desempenho entre os jogadores e criar um ranking; e

b) fornecer uma análise objetiva com base nos parâmetros do ambiente simulado.

A utilização desses elementos básicos pode ser aplicada em qualquer abordagem de

design de jogos de empresa. O próximo subcapítulo apresenta de modo sucinto as principais

abordagens ao design e, em seguida, descreve como a arquitetura proposta seguiu a

abordagem escolhida.

4.3 Abordagens ao Design de Jogos de Empresa

Segundo Thavikuwat (2004), o design de simuladores de jogos de empresa tem sido

fundamentado na ciência desde 1957. Com o passar dos anos, diferentes abordagens foram

criadas. Mais recentemente, essas abordagens tem realizado seu foco no design pelo

computador.

46

Westphal e Lopes (2007) discutem três diferentes abordagens para o design de

simuladores computacionais de jogos de empresa: as abordagens de Goosen (1981), Teach

(1990) e o Rock Pool Design Method (HALL, 2005), também de propósito geral mas com

enfoque computacional.. A Tabela 4.1 apresenta as similaridades entre essas abordagens.

GOOSEN (1981) TEACH (1990) HALL (2005)

ABORDAGEM

GERAL AO

DESIGN

Passos gerais para o

design de simulações com

foco em algoritmos.

Design de

simulações: seus

componentes,

interações e a

simulação sob

perspectiva dos

jogadores, da

faculdade e do

desenvolvedor.

Proposta de

metodologia de

design de software,

tendo em

perspectiva jogos

de empresa,

provendo estrutura

e liberdade criativa.

PRINCIPAIS

ASPECTOS DO

DESIGN

CONSIDERADOS

Cenários, relatórios,

equações, funções

matemáticas, algoritmos,

decisões, parâmetros e

restrições, software de

computador, manual do

participante.

Cenários, papéis,

sistema contábil,

decisões,

resultados,

algoritmos,

equações, software

de computador,

interações, tradução

do mundo real.

Público alvo e

objetivo, cenário,

decisões,

resultados, modelos

(algoritmos),

rotinas e relatórios,

documentação,

testes, calibragem e

refinamento.

Tabela 4.1 – Abordagens ao design de jogos de empresa

Fonte: WESTPHAL; LOPES, 2007.

É possível notar na Tabela 4.1 que a abordagem de Hall (2005) foca-se na construção

de softwares como jogos de empresa, diferentemente das demais, que centram-se na

arquitetura do jogo empresarial. As abordagens de Goosen (1981) e Teach (1990) utilizam o

computador como ferramenta apenas, e não apresentam nenhum suporte para o

desenvolvimento do software enquanto jogo de empresa.

Por esta razão e também por prover um resultado final mais flexível e uma abordagem

que esteja mais próxima que as outras em relação às metodologias de desenvolvimento de

software iterativas, este projeto utiliza a abordagem de Hall (2005) para alcançar seu objetivo.

Ainda que brevemente, essa abordagem é descrita a seguir com mais detalhes.

4.3.1 The Rock Pool Method

47

O Rock Pool Method é uma metodologia de design de software aplicada no contexto

do design da simulação de negócios (WESTPHAL; LOPES, 2007; HALL, 2005).

A abordagem metodológica do Rock Pool Method provê uma estrutura de design de

software rigorosa, mas que também permita a criação de um modelo de simulação que provê

que o aprendizado seja um processo criativo (HALL, 2005).

Segundo Hall (2005), a expressão “piscina de rochas” é uma metáfora que compara a

metodologia com a exploração de piscinas de rochas na praia após o recuo da maré: cada

piscina de rochas é um estágio no processo; as rochas de cada piscina representam os

elementos de design, que não são processados, mas revistados diversas vezes. Assim como o

movimento entre as piscinas de rochas é sistemático, a ordem em que os elementos são

abordados depende da simulação e do processo criativo utilizado. Westphal e Lopes (2007)

explicam que, nesta abordagem, o design não constitui um processo sequencial. Sendo assim,

não possui um ponto de início definido e pode ser revisitado diversas vezes até que as todas as

tarefas estejam concluídas, a fim de que um novo estágio possa ser iniciado. Analogamente,

essa abordagem aproxima-se dos processos iterativos.

A Tabela 4.2 apresenta os estágios dos Rock Pool Method.

GRANDES FASES DO DESIGN ELEMENTOS DO DESIGN

Definição das necessidades Especificar público-alvo; definir objetivos de

aprendizado; determinar duração; definir modo de uso.

Especificações da simulação

Definir questões a serem abordadas (conceitos / áreas de

negócio); definir tipo da simulação; definir modo de

entrega; definir versão (ões); definir cenário do jogo –

setor.

Design da simulação

Definir decisões; definir resultados; definir modelos

ligando decisões e resultados; criar rotinas e relatórios que

demonstrem o funcionamento dos modelos; criar

documentação preliminar.

Desenvolvimento da simulação

Testar modelos; calibrar modelos; adicionar decisões /

relatórios conforme a simulação progride; criar apoio de

aprendizado e tutorial; aprimorar documentação.

Validação da simulação Aplicação teste do jogo; modificações e refinamento do

jogo; refinar e modificar documentação.

48

Finalização do design

Finalizar documentação - participante e tutor/animador;

finalizar apoio ao tutor/animador; disponibilizar

simulação.

Tabela 4.2 – Estágios do Rock Pool Method

Fonte: WESTPHAL; LOPES, 2007.

4.4 GOG: Uma Arquitetura Computacional para Jogos de Empresa

A Arquitetura GOG (Gian, Orlando e Gustavo – nomes dos autores deste projeto) é

uma arquitetura computacional destinada à construção e o uso de jogos de empresa. Seus

principais utilizadores são os professores que ministram aulas de jogos de empresa ou

conteúdos relacionados, alunos desses professores, faculdades que agregam esses alunos e

professores e desenvolvedores de software capazes de programar este projeto.

Para o desenvolvimento da Arquitetura GOG, este projeto seguiu a abordagem de

design de Hall (2005). A Tabela 4.3 apresenta a definição dos elementos utilizados pela

arquitetura nos estágios do Rock Pool Method.

ESTÁGIO ELEMENTOS, DEFINIÇÕES E REQUISITOS

Definição das

necessidades

Público-alvo: alunos que estudam jogos de empresa;

Aprendizagem: definida pelo professor na concepção da

ideia do jogo (pré-modelagem do workflow);

Duração: tempo definido pelo professor no workflow;

Modo de uso: descrito na Figura 4.2.

Especificações

da simulação

A arquitetura GOG é flexível e dá liberdade criativa ao professor

para definir quais módulos pré-programados podem ser utilizados

na simulação, bem como seus cenários de uso e avaliações de

desempenho.

Design da

simulação

A arquitetura GOG é flexível e dá liberdade criativa ao professor

para especificar o design da simulação: seus objetivos, variáveis e

os resultados.

Desenvolvimento

da simulação

O fluxo de uso da Arquitetura GOG é apresentado na

Figura 4.2;

As ferramentas dispostas pela arquitetura permitem que o

professor crie e manipule um jogo de empresas a partir de

um workflow pré-definido;

Os relatórios fazem parte dos requisitos da arquitetura e são

definidos no capítulo 5.1.

Validação da

simulação A avaliação de desempenho dos alunos é feita pela interpretação

do professor e não é avaliada pela arquitetura, que apenas

49

disponibiliza os resultados de cada participante.

Finalização do

design

A documentação do jogo empresarial criado é de

responsabilidade do professor, que deverá conduzir e

orientar os alunos na simulação;

A documentação da arquitetura é descrita neste projeto e

permite que o professor crie e manipule seu jogo

empresarial a partir deste trabalho. Tabela 4.3 – Definição dos elementos da Arquitetura GOG pelo Rock Pool Method

Fonte: Autores

A Figura 4.2 apresenta a metodologia da Arquitetura GOG, que expressa o processo

de funcionamento proposto para todos os envolvidos – professores, alunos, faculdades e

desenvolvedores de software.

Figura 4.2- Metodologia da Arquitetura GOG

A Figura 4.3 apresenta a Arquitetura GOG, cujos componentes computacionais estão

descritos em detalhes no capítulo 5. A finalidade da Figura 4.3 é apresentar a proposta

50

arquitetural, de modo que todos os envolvidos compreendam o funcionamento da arquitetura

em alto nível.

Figura 4.3- Arquitetura GOG

Os componentes que integram a arquitetura a Arquitetura GOG são:

a) Interface de Definição de Jogo: é uma ferramenta gráfica que permite ao professor

definir e modelar workflows. O professor utiliza essa ferramenta para criar seus jogos.

Arquivo de Definição de Jogo: é um arquivo de formato XML que corresponde ao

jogo modelado pelo professor e atenta às regras de definição de workflow da

Arquitetura GOG (ver capítulo 5.8);

b) Administração do Jogo de Empresas: corresponde à área administrativa da

arquitetura, que é gerenciada e controlada pelo professor;

c) Banco de Dados: é uma base de dados que agrega e fornece os dados que são

manipulados pelos alunos e pelo professor para compor o jogo;

d) Jogo de Empresas: corresponde ao jogo gerado pelo professor e que é utilizado nas

aulas pelos alunos.

51

5 ENGENHARIA DE SOFTWARE

A Engenharia de Software é uma disciplina da Ciência da Computação que trata da

aplicação de uma abordagem sistemática, disciplinada e quantificável em relação ao

desenvolvimento, à operação e à manutenção de softwares (IEEE, 1993 apud PRESSMAN,

2005).

Este capítulo visa apresentar a abordagem de engenharia de software sob a ótica do

desenvolvimento utilizada na construção projeto a fim de detalhar a solução proposta ao

problema.

5.1 Especificação e Requisitos do Projeto

A especificação de software deste projeto tem como finalidade expressar as

necessidades e as restrições do produto para contribuir com a solução do problema de mundo

real apresentado anteriormente (KOTONYA; SOMMERVILLE, 2000 apud SWEBOK,

2004).

A especificação deste projeto apresenta os requisitos do projeto atendido pela

Arquitetura GOG. Esses requisitos são expressos na Tabela 5.1.

RQ-0 Definição do Jogo desejado

O sistema deve permitir que o professor seja capaz de definir o fluxo de jogo (suas etapas

de decisões) assim como os parâmetros desejados que farão parte do jogo. Os parâmetros

são, exclusivamente, os contemplados pela arquitetura GOG (listados e definidos no

capítulo 5.7). A definição do fluxo do jogo segue as regras definidas em RQJ-1. Vale

ressaltar que a arquitetura permitirá a definição e execução de vários jogos ao mesmo

tempo dentro do servidor.

RQ-1 Geração do Jogo

O sistema deve ser capaz de gerar um novo jogo no sistema para uma definição de jogo

fornecida (RQ-0).

RQ-2 Login

O sistema deve habilitar o professor, e apenas o professor, a entrar na parte administrativa

do sistema através de Login. Os jogadores cadastrados devem ser aptos a acessar o jogo

através de Login também.

52

RQ-3 Alterações de Conta

O sistema deve permitir que o professor altere seu login e sua senha para acesso na parte

administrativa, assim como os jogadores cadastrados para acesso ao jogo.

RQ-4 Ativação do Jogo

O sistema deve permitir que o professor ative um jogo ainda não iniciado do sistema.

RQ-5 Requisição de novos Jogadores

O sistema deve permitir que novos jogadores enviem uma requisição de cadastro de novo

jogador ao professor de um jogo ainda não ativado, assim como a aceitação ou negação do

mesmo por parte do professor.

RQ-6 Definição de Parâmetros durante o jogo

O sistema deve permitir que o professor defina valores dos parâmetros variáveis durante

o jogo (ver AS-11) entre etapas do jogo de um jogo já ativado do sistema. Vale ressaltar

que os parâmetros contemplados serão únicos e exclusivamente os definidos em AS-11 e

que estes valores só podem ser alterados após o fim de uma etapa do jogo e antes do

começo da etapa seguinte (ou seja, entre etapas). A sequência das etapas (ou rodadas) do

jogo já foi definida no workflow nesta altura.

RQ-7 Troca de Etapa

O sistema deve permitir que o professor encerre a rodada atual do jogo (mesmo que antes

de seu horário de encerramento definido no workflow), ativando a etapa seguinte (mesmo

que antes de seu horário de ativação).

RQ-8 Jogar

O sistema deve permitir que um jogador cadastrado tenha acesso a um jogo ativo,

tomando as decisões da etapa ativa atualmente.

Tabela 5.1 – Tabela de requisitos do projeto

5.2 Atores

Os atores do sistema são as diferentes pessoas ou dispositivos que utilizam o sistema

dentro do contexto de função e comportamento (PRESSMAN, 2005) descritos nos casos de

uso apresentados no próximo subcapítulo.

53

Ator Descrição

Professor Representa o docente que ministra os conceitos que envolvem os

processos de decisão do jogo e que ministrará o jogo.

Aluno Representa o estudante que é aprendiz do ator Professor. Ele jogará o

jogo ministrado pelo ator Professor.

Tabela 5.2 – Descrição dos atores envolvidos no sistema

5.3 Casos de Uso

Segundo Rumbaugh, Jacobson, Booch (1999), um caso de uso especifica o

comportamento do sistema ou parte dele. Neste projeto, a modelagem dos casos de uso foi

realizada a partir dos requisitos presentes no capítulo 5.1. Os diagramas dessa modelagem

estão expressos na Figura 5.1 e na Figura 5.2.

Figura 5.1 – Diagrama de caso de uso para o ator Professor

54

Figura 5.2 – Diagrama de caso de uso para o ator Aluno

A Tabela 5.3 especifica os elementos do diagrama para os casos de uso.

CASO DE USO DESCRIÇÃO

Definir Jogo Engloba o requisito RQ-0, ou seja, toda a parte de definição do workflow

e dos parâmetros do jogo por parte do professor.

Administrar Jogo Engloba os requisitos RQ1, RQ-4, RQ-5, RQ-6 e RQ-7, ou seja, toda a

parte de geração, ativação e gerenciamento do jogo em execução.

Alterar Conta Engloba o requisito RQ-3, no qual o usuário pode alterar suas

informações de conta (como login e senha).

Login Engloba o requisito RQ-2, no qual o aluno ou professor obtém acesso ao

sistema através de seu login e senha.

Jogar Engloba o requisito RQ-8, no qual o aluno joga efetivamente o jogo

empresarial gerado.

Requisitar

cadastro

Engloba o RQ-5 por parte do aluno, no qual o aluno pode requisitar ao

professor um cadastro como novo jogador.

Tabela 5.3 – Descrição dos casos de uso

5.4 Arquitetura GOG

A Arquitetura GOG é a arquitetura utilizada neste projeto para responder ao problema

definido no capítulo 1.1. A Figura 5.3 representa essa arquitetura.

55

Figura 5.3 – Arquitetura GOG

Como é possível notar na Figura 5.3, a arquitetura é composta por um conjunto de

componentes que se inter-relacionam. As relações entre os componentes definem o controle

de fluxo e o fluxo de dados das informações que são transmitidas pela arquitetura, começando

pelo professor e finalizando no aluno.

Os componentes que definem a Arquitetura GOG são:

a) Ator Professor: ver definição no capítulo 5.2;

b) Interface de Definição de Jogo: ferramenta gráfica para definição do jogo,

atendendo à especificação da Arquitetura GOG presentes nos capítulos 4.4 e 5.

Isso inclui o workflow e todos os parâmetros do jogo. A ferramenta gera como

resultado o Arquivo de Definição de Jogo.

c) Arquivo de Definição de Jogo: é o arquivo XML com todos os dados de

definição de jogo definidos pelo professor na ferramenta gráfica. A estrutura deste

arquivo é exposta no capítulo 5.8

d) Servidor: representa o servidor de hospedagem do jogo de empresas. É composto

pela aplicação servidora do jogo empresarial e o banco de dados.

e) Administrativo de Jogos de Empresa: é a área administrativa do ator Professor;

gerencia os jogos publicados.

56

a. Ativação: interface de usuário utilizada pelo ator Professor para importar a

definição de jogo, gerar e ativar os jogos que desejar.

b. Controle: responsável pelas interações do ator Professor com a camada de

apresentação, pela importação, validação e leitura dos arquivos de

Definição de Jogo e pela ativação do componente Controlador.

f) Controlador: executa as transições necessárias das etapas do workflow de um

jogo de empresas, assim como verifica qual é a etapa do jogo atual. As transições

podem ser forçadas pelo professor (ver RQ-7), ou então feitas automaticamente se

a condição de transição definida pelo professor na etapa de definição de jogo for

satisfeita. Deste modo, assim que um jogador acessar o jogo, o controlador será

chamado para verificar qual a etapa atual do jogo.

g) Banco de dados: é a base de dados da arquitetura. Nele estão contidos todos os

dados criados pelo sistema para o jogo de empresas importado e que sustentam a

arquitetura de um jogo de empresas (conforme capítulos 4.4, 5.5, 5.6 e 5.7);

a. Tabelas de Referência: São as tabelas que conterão os dados de definição

de jogo de todos os jogos gerados pela arquitetura GOG. Aqui abrigam os

dados que dão flexibilidade a arquitetura.

b. Tabelas de Aplicação: Tabelas comuns dos jogos que conterão dados da

aplicação;

h) Jogo de Empresas: camada de apresentação e acesso aos jogos de empresas

gerados pela arquitetura GOG. Vale lembrar que os arquivos aqui têm código fixo

e não gerado. Esta camada olha as tabelas de referência e decide o que deve ser

feito, que é onde abriga a flexibilidade da definição de jogos.

i) Ator Aluno: ver definição no capítulo 5.2;

5.5 Especificação dos Módulos do Workflow

Como já dito anteriormente, o professor será capaz de definir o workflow de seu jogo através

de módulos. Os módulos disponíveis pela Arquitetura GOG são detalhados a seguir:

NOME

DO

MÓDULO

DESCRIÇÃO DECISÃO QUE O

JOGADOR TOMARÁ

57

Compras Permite ao usuário compra de matéria

prima e máquinas

Se quer comprar matéria prima

e/ou máquinas e quanto.

Marketing Permite o usuário decidir se vai investir

no marketing Se quer investir em marketing.

Produtos

Permite o usuário definir como vai ser

seu produto final vendido quanto a

quantidade do produto por embalagem

vendida. (exemplo: se a embalagem será

de 100 gramas ou 200 gramas)

O quanto de produto tem por

embalagem

Estoque Permite ao usuário alugar locais para

estoque.

Se quer alugar locais de estoque

e quantos

Vendas

Permite ao usuário distribuir seus

produtos acabados dentre os locais de

venda

O quanto cada região de venda

deve receber de produtos

acabados e qual o preço de

venda de cada produto acabado

em cada região

Tabela 5.4 – Descrição dos módulos

5.6 Especificação da Estrutura Básica do Jogo

A estrutura básica do jogo é a estrutura que conterá todo o jogo empresarial gerado

pela Arquitetura GOG. Levando em consideração o que foi visto sobre jogos de empresas nos

capítulos 5.1 e 5.5 e o levantamento de informações sobre o jogo de empresas do Anexo A,

foram levantadas algumas asserções para descrever a estrutura básica do jogo de empresas

suportado pela Arquitetura GOG. Essas asserções estão descritas na Tabela 5.4.

AS-0 Mundo Empresarial

O jogo consiste num mundo empresarial fictício, onde cada jogador representa uma

empresa. O jogador deverá fazer uma série de decisões pré-determinadas que irão

influenciar nos resultados de sua própria empresa e mercado dando rumo ao jogo.

AS-1 Concorrentes

Cada participante do jogo representa uma empresa. Os participantes são concorrentes

entre si, portanto, no mundo fictício representarão empresas concorrentes entre si.

58

AS-2 Informações aos jogadores

Os jogadores terão informações à disposição para ajudá-los na tomada de decisão, através

de relatórios, consultorias e jornal.

AS-3 Critério para vencedor

Será declarado o vencedor do jogo o jogador que obtiver maior lucro após o término do

workflow.

AS-4 Workflow

Cada etapa do workflow definido pelo professor representará uma rodada do jogo

empresarial.

AS-5 Estrutura empresarial

As empresas consistem de compra de matéria-prima, usada na produção de produtos

acabados. A produção é executada por, no mínimo, 1 máquina.

AS-6 Produção

Cada unidade de matéria prima gerará uma e apenas uma unidade de produto acabado.

AS-7 Compra de Matéria Prima

Compra de matéria prima são sempre pagas à vista.

AS-8 Vendas de Produto Acabado

Venda de produtos acabados são sempre recebidas à vista.

AS-9 Juros

Quaisquer juros a serem pagos durante o jogo são pagos ao final de cada rodada.

AS-10 Consultoria

O serviço de consultoria disponibiliza as seguintes informações:

1. Quem comprou matéria prima e quanto;

59

2. O quanto cada empresa vendeu produto acabado e onde;

3. Capacidade produtiva e preços de Produto acabado de concorrentes.

AS-11 Parâmetros Variáveis durante o jogo

O professor poderá alterar o valor das seguintes variáveis entre as etapas do jogo (durante

sua execução): taxa de juros, impostos, custos de marketing, valores máximo e mínimo

para o preço de produto acabado, custo da consultoria.

AS-12 Jornal

O jornal informará os valores dos parâmetros variáveis durante o jogo (AS-11).

Adicionalmente, dará dicas de possíveis catástrofes e/ oportunidades. Detalhamento em

RQJ-3.

AS-13 Depreciação de Máquinas

Se o professor quiser que haja depreciação de máquinas na etapa de definição de jogo,

uma máquina sai imediatamente de operação assim que ela é totalmente desvalorizada.

AS-14 Classes econômicas

Existirão no jogo três classes econômicas para a compra de produtos acabados. São elas:

1. Classe A: pessoas com preferência de produtos de qualidade alta;

2. Classe B: pessoas que dão prioridade igual para qualidade e preço;

3. Classe C: pessoas que dão preferência a produtos mais baratos.

AS-15 Relatórios

Serão entregues aos jogadores no começo de cada rodada, sem custo, contendo as

seguintes informações:

1. Compromissos dos próximos períodos;

2. Desempenho da empresa: caixa e despesas futuras;

Tabela 5.4 – Descrição das Especificações da Estrutura Básica do Jogo

5.7 Especificação e Requisitos da Definição de Jogo

60

A definição do jogo pelo professor é uma parte essencial deste trabalho. É de extrema

importância definir o que o professor poderá incluir em seu jogo (parte da arquitetura GOG

que dá flexibilidade). Levando em consideração o que foi visto sobre jogos de empresas nos

capítulos anteriores somado às informações sobre o jogo de empresas do Anexo A, foram

levantados os requisitos para a definição de jogo, descritos na Tabela 5.5.

RQJ-1 Workflow

O sistema deve deixar o professor apto a definir as etapas de seu jogo através do

workflow usando os módulos definidos no capítulo 5.5. A condição para transição entre

etapas é feita pelo tempo e este é também definido pelo professor.

RQJ-2 Opções Gerais da Rodada

O sistema deve deixar o professor apto a definir uma ou mais opções que o jogador terá

em todas as rodadas do jogo. As opções devem estar dentro do universo:

1. Se o jogador vai querer pagar por Serviços de consultoria;

2. Se o jogador vai querer pagar pelo Jornal;

3. Se o jogador vai fazer investimentos em marketing (Módulo Marketing);

4. Se o jogador vai comprar novo local de Estoque (Módulo Estoque);

5. Se o jogador comprará Matéria Prima e/ou máquinas (Módulo Compras);

6. Se o jogador distribuirá seus produtos acabados produzidos nos locais de venda

(Módulo Vendas);

Vale ressaltar que se forem definidos financiamentos (ver RQJ-16), em todas as rodadas

os jogadores terão a opção disponível na tela para obterem os financiamentos que tenham

suas pré-condições satisfeitas.

RQJ-3 Catástrofes e Oportunidades

O sistema deve deixar o professor apto a definir possíveis catástrofes e oportunidades

inesperadas durante o jogo e suas respectivas probabilidades de acontecimento (fácil

médio ou difícil). Um evento destes impacta nos Parâmetros Variáveis durante o jogo

(ver AS11 de 0.6), o professor deve ser capaz de definir o valor destes parâmetros para

quando ocorrer um evento inesperado durante o jogo, ele fará isso para cada evento.

Também o professor deve definir a notícia que aparecerá no jornal para dar dicas aos

jogadores antes que o evento ocorra e também a notícia que aparecerá no jornal quando o

evento ocorrer.

61

RQJ-4 Locais de venda

O professor deve ser apto a definir no sistema os locais de venda, com suas respectivas

variedades de classes econômicas e se são no mercado interno ou externo.

RQJ-5 Limite máximo de compra de matéria prima

O professor pode definir o valor máximo de matéria prima que o jogador pode comprar

numa rodada. Pode ser um número fixo ou então em relação ao quanto o jogador pode

produzir naquela rodada, ou seja, a capacidade produtiva vezes algum valor desejado.

RQJ-6 Máquinas

O professor deve ser apto a definir quais são os tipos de máquinas que existirão no jogo,

assim como seus custos fixos por rodada, suas produtividades, seu custo inicial, seu custo

por Produto acabado produzido, a qualidade dos produtos produzidos por ela, sua

depreciação e se são pagas à vista ou a prazo.

RQJ-7 Estoque

O jogador tem a opção de alugar locais novos de estoque para aumentar seu limite de

estoque. Cada local de estoque pode ser de matéria-prima ou de produto acabado. O

professor deve ser apto a definir no sistema qual o valor fixo para se alugar um local de

estoque (pago por rodada), assim como os custos de estocagem de cada unidade de

Produto acabado e de Matéria prima.

RQJ-8 Custos de Matéria prima

O professor deve ser apto a definir no sistema qual o custo por matéria prima.

RQJ-9 Limite máximo e mínimo de preço de Produto acabado

O professor deve ser apto a definir no sistema quais os preços máximos e mínimos que

um jogador pode vender um produto acabado. Existe o limite para o mercado interno e

para o externo (podem existir locais de venda no exterior e no interior).

RQJ-10 Política de Produtos Acabados não vendidos

O professor deve ser apto a definir no sistema uma política que descreve o que o sistema

deve fazer com produtos acabados que acabaram por não serem vendidos no final da

rodada devido à rejeição dos públicos de compra. Essa política deve ser uma das abaixo,

lembrando que sempre todos os produtos acabados que foram distribuídos nas regiões

62

acabarão vendidos:

1. Vender a um cliente especial a preço de custo. Este cliente comprará todos os produtos

acabados restantes.

2. Vender a um cliente especial pelo valor mais baixo vendido no mercado diminuído de

um determinado valor, definido pelo professor. Este cliente comprará todos os produtos

acabados restantes.

Nota: é possível definir políticas diferentes para o mercado interno e externo.

RQJ-11 Contexto

O professor deve ser apto a definir no sistema o contexto econômico e empresarial de terá

seu jogo. Este contexto será definido através de um texto que é apresentado aos jogadores

em seu primeiro acesso ao jogo.

RQJ-12 Definição de Matéria-Prima e Produto Acabado

O professor deve ser apto a definir no sistema quais é a matéria-prima utilizada no jogo e

qual o produto acabado gerado por essa matéria-prima. Vale lembrar que no jogo haverá

exatamente um tipo de matéria-prima e exatamente um tipo de produto acabado.

RQJ-13 Despesas com funcionários

O valor de despesas com funcionários que será gasto pelos jogadores a cada rodada deve

ser definido pelo professor, assim como se haverá dissídio desse valor (X% a cada N

rodadas)

RQJ-14 Marketing

O valor de ganho obtido pelos jogadores que decidirem investir em marketing deve ser

definido pelo professor. O ganho de quem investe em marketing pode ser um valor fixo

ou uma determinada porcentagem em cima do valor ganho das vendas.

RQJ-15 Bônus a vendedores

O valor que deve ser pago a vendedores deve ser definido. Este valor deve uma

porcentagem sobre a receita de vendas (excluindo bônus de marketing).

RQJ-16 Financiamento

Os tipos de financiamentos que forem existir no jogo devem ser definidos. Devem ser

definidas as características para cada tipo de financiamento:

63

1. Pré-Condição: se existe uma pré-condição para poder fazê-lo. As pré-condições válidas

são: se o caixa estourou, se o limite de outros financiamentos estourou.

2. Limite: o limite máximo de financiamentos deste tipo que podem ser feitos durante o

jogo.

3. Juros: se corresponde aos juros do jornal ou juros pré-definido específico para este tipo

de financiamento.

4. Tempo de pagamento: em quanto tempo o financiamento deve ser quitado em número

de rodadas.

RQJ-17 Bônus a vendedores

O valor que deve ser pago a vendedores deve ser definido. Este valor deve uma

porcentagem sobre a receita de vendas (excluindo bônus de marketing).

RQJ-17 Juros

O valor inicial de Juros no sistema deve ser definido. Vale lembrar que este valor pode

ser alterado pelo professor durante o jogo (ver AS-11).

RQJ-18 Nome do jogo

O professor deve ser capaz de definir no sistema o nome do jogos gerados.

RQJ-19 Recurso inicial

O valor de caixa inicial deve ser definido pelo professor.

Tabela 5.5 – Descrição das Especificações e Requisitos da Definição de Jogo

5.8 Linguagem de Definição de Jogo

A Linguagem de Definição de Jogo é uma linguagem baseada no formato XML (XML

Schema) para definir as regras de criação e validação de um jogo de empresa convalidado na

Arquitetura GOG. A Tabela 5.6 apresenta o formato dessa linguagem.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<xs:element name="DefinicaoJogo">

<xs:complexType>

<xs:sequence>

<xs:element ref="NomeJogo"/>

<xs:element ref="Contexto"/>

64

<xs:element ref="MateriaPrima"/>

<xs:element ref="ProdutoAcabado"/>

<xs:element ref="CustoMP"/>

<xs:element ref="BonusVendedores"/>

<xs:element ref="CustoJornal"/>

<xs:element ref="CustoConsultoria"/>

<xs:element ref="Juros"/>

<xs:element ref="CaixaInicial"/>

<xs:element ref="Impostos"/>

<xs:element ref="UnidadePA"/>

<xs:element ref="Modulos"/>

<xs:element ref="Opcoes"/>

<xs:element ref="LimitePrecoPA"/>

<xs:element ref="Eventos"/>

<xs:element ref="Locais"/>

<xs:element ref="LimiteMaximoMP"/>

<xs:element ref="Maquinas"/>

<xs:element ref="Estoque"/>

<xs:element ref="PANaoVendidos"/>

<xs:element ref="DespesasFuncionarios"/>

<xs:element ref="Marketing"/>

<xs:element ref="Financiamentos"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="NomeJogo" type="xs:string"/>

<xs:element name="Contexto" type="xs:string"/>

<xs:element name="CustoMP" type="xs:decimal"/>

<xs:element name="BonusVendedores" type="xs:decimal"/>

<xs:element name="CustoJornal" type="xs:decimal"/>

<xs:element name="CustoConsultoria" type="xs:decimal"/>

<xs:element name="CaixaInicial" type="xs:integer"/>

<xs:element name="UnidadePA">

<xs:complexType>

<xs:sequence>

<xs:element ref="Nome"/>

<xs:element ref="QtdInicial"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="QtdInicial" type="xs:integer"/>

<xs:element name="Modulos">

<xs:complexType>

<xs:choice maxOccurs="unbounded">

<xs:element ref="Compras"/>


<xs:element ref="Vendas"/>

<xs:element ref="Produtos"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="Produtos">

<xs:complexType>

<xs:sequence>

<xs:element ref="condicao"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Opcoes">

<xs:complexType>

<xs:sequence>

65

<xs:element ref="Consultoria"/>

<xs:element ref="Jornal"/>


<xs:element ref="Estoque"/>

<xs:element ref="Compras"/>

<xs:element ref="Vendas"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Jornal" type="xs:integer"/>

<xs:element name="LimitePrecoPA">

<xs:complexType>

<xs:sequence>

<xs:element ref="Minimo"/>

<xs:element ref="Maximo"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Minimo">

<xs:complexType>

<xs:sequence>

<xs:element ref="MercadoInterno"/>

<xs:element ref="MercadoExterno"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Maximo">

<xs:complexType>

<xs:sequence>

<xs:element ref="MercadoInterno"/>

<xs:element ref="MercadoExterno"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Eventos">

<xs:complexType>

<xs:sequence>

<xs:element ref="Evento"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Evento">

<xs:complexType>

<xs:sequence>


<xs:element ref="Probabilidade"/>

<xs:element ref="Tipo"/>

<xs:element ref="Noticia"/>

<xs:element ref="TituloNoticia"/>

<xs:element ref="NoticiaDica"/>

<xs:element ref="TituloNoticiaDica"/>

<xs:element ref="Parametros"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Probabilidade" type="xs:NCName"/>

<xs:element name="Noticia" type="xs:string"/>

<xs:element name="TituloNoticia" type="xs:string"/>

<xs:element name="NoticiaDica">

<xs:complexType/>

</xs:element>

66

<xs:element name="TituloNoticiaDica">

<xs:complexType/>

</xs:element>

<xs:element name="Parametros">

<xs:complexType>

<xs:sequence>


<xs:element ref="Impostos"/>


<xs:element ref="MaximoPrecoPA"/>

<xs:element ref="MinimoPrecoPA"/>

<xs:element ref="Consultoria"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="MaximoPrecoPA">

<xs:complexType/>

</xs:element>

<xs:element name="MinimoPrecoPA">

<xs:complexType/>

</xs:element>

<xs:element name="Locais">

<xs:complexType>

<xs:sequence>

<xs:element maxOccurs="unbounded" ref="Local"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Local">

<xs:complexType>

<xs:sequence>


<xs:element ref="ClasseA"/>

<xs:element ref="ClasseB"/>

<xs:element ref="ClasseC"/>

<xs:element ref="Mercado"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="ClasseA" type="xs:decimal"/>

<xs:element name="ClasseB" type="xs:decimal"/>

<xs:element name="ClasseC" type="xs:decimal"/>

<xs:element name="Mercado" type="xs:NCName"/>

<xs:element name="LimiteMaximoMP">

<xs:complexType>

<xs:sequence>


<xs:element ref="Valor"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Maquinas">

<xs:complexType>

<xs:sequence>

<xs:element maxOccurs="unbounded" ref="Maquina"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Maquina">

<xs:complexType>

<xs:sequence>

67


<xs:element ref="CustoFixo"/>

<xs:element ref="Produtividade"/>

<xs:element ref="CustoPorPA"/>

<xs:element ref="CustoInicial"/>

<xs:element ref="QualidadePA"/>

<xs:element ref="Depreciao"/>

<xs:element ref="MetodoPagamento"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Produtividade" type="xs:integer"/>

<xs:element name="CustoInicial" type="xs:decimal"/>

<xs:element name="QualidadePA" type="xs:integer"/>

<xs:element name="Depreciao" type="xs:integer"/>

<xs:element name="MetodoPagamento">

<xs:complexType>

<xs:sequence>


<xs:element ref="Tempo"/>


</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Tempo" type="xs:string"/>

<xs:element name="PANaoVendidos">

<xs:complexType>

<xs:sequence>

<xs:element ref="IdPolitica"/>


</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="IdPolitica" type="xs:integer"/>

<xs:element name="DespesasFuncionarios">

<xs:complexType>

<xs:sequence>

<xs:element ref="CustoFixo"/>

<xs:element ref="Dissidio"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Dissidio">

<xs:complexType>

<xs:sequence>


<xs:element ref="Frequencia"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Frequencia" type="xs:integer"/>

<xs:element name="Financiamentos">

<xs:complexType>

<xs:sequence>

<xs:element ref="Financiamento"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Financiamento">

<xs:complexType>

<xs:sequence>

68


<xs:element ref="IdPreCondicao"/>

<xs:element ref="Limite"/>


<xs:element ref="TempoPagamento"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="IdPreCondicao" type="xs:integer"/>

<xs:element name="TempoPagamento" type="xs:integer"/>

<xs:element name="MateriaPrima">

<xs:complexType mixed="true">

<xs:choice minOccurs="0" maxOccurs="unbounded">

<xs:element ref="Custo"/>


<xs:element ref="CustoPorMP"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="CustoPorMP">

<xs:complexType/>

</xs:element>

<xs:element name="ProdutoAcabado">




<xs:element ref="CustoPorPA"/>


</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="Juros">





</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="Impostos" type="xs:decimal"/>

<xs:element name="Nome" type="xs:string"/>

<xs:element name="Compras">


<xs:sequence>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="condicao"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Vendas">


<xs:sequence>

<xs:element minOccurs="0" maxOccurs="unbounded" ref="condicao"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="condicao" type="xs:NMTOKEN"/>

<xs:element name="Marketing">





69


<xs:element ref="condicao"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="Consultoria" type="xs:string"/>

<xs:element name="Estoque">



<xs:element ref="MateriaPrima"/>

<xs:element ref="ProdutoAcabado"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="MercadoInterno" type="xs:decimal"/>

<xs:element name="MercadoExterno" type="xs:decimal"/>

<xs:element name="Tipo" type="xs:string"/>

<xs:element name="Valor" type="xs:string"/>

<xs:element name="CustoFixo" type="xs:decimal"/>

<xs:element name="CustoPorPA" type="xs:string"/>

<xs:element name="Limite" type="xs:string"/>

<xs:element name="Custo" type="xs:string"/>

</xs:schema>

Tabela 5.6 – Linguagem de Definição de Jogo em formato XML Schema

Cada elemento da linguagem possui uma função única na linguagem que define o

jogo. Cada elemento e sua respectiva função são apresentados na Tabela 5.7.

Nº ELEMENTO (TAG) DESCRIÇÃO

1 DefinicaoJogo Tag principal que contém todos os outros elementos

abaixo dela

2 Módulos

Tag que terá o workflow definido pelo professor

abaixo, que serão as tags dos módulos na ordem

definida. Cada módulo tem sua tag e debaixo de

cada módulo há a tag “condição” que terá a

data/horário para transição para o módulo. Atende ao

RQJ-1.

3 Opções

Conterá todas as opções que terão em todas as

rodadas do jogo definidas (atende ao RQJ-2).

Necessariamente, terá as tags Consultoria, Jornal,

Estoque, Compras e Vendas abaixo. Nestas tags

conterão se o professor quer ou não esta opção.

4 Contexto Cenário de jogo. Atende ao RQJ-11.

5 MateriaPrima Nome da matéria prima utilizada (atende parte do

RQJ-12)

6 ProdutoAcabado Nome do produto acabado utilizada (atende parte do

RQJ.12)

7 CustoMP Custo de cada unidade de matéria-prima (atende ao

RQJ-8)

8 LimitePrecoPA Contém os valores máximos e mínimos de preço de

Produto acabado que os jogadores podem dar aos

70

seus produtos. Atende ao RQJ-9.

9 Eventos

Possui as catástrofes e oportunidades inesperadas.

Cada evento terá sua tag Evento embaixo desta tag e

terá as informações abaixo dela: Nome,

Probabilidade de ocorrência (fácil, médio ou difícil),

Tipo (“Boa” para oportunidades e “Ruim” para

catástrofes), Notícia para ser exibida no jornal

quando ocorrer o evento (tag “Noticia”), Título desta

notícia, Notícia que aparecerá no jornal antes dela

acontecer, dando dicas aos jogadores (tag

“NoticiaDica”), Titulo desta notícia de dica e quais

os valores que os parâmetros variáveis durante o

jogo assumirão (debaixo da tag “Parâmetros”). Caso

algum parâmetro não seja alterado pelo evento, a tag

existirá abaixo da tag de parâmetros, porém com

valor vazio. Atende ao RQJ-3

10 Locais

Terá todos os locais de venda abaixo, cada local de

venda terá sua tag abaixo desta, chamada “Local”,

com as informações: Nome, distribuição de cada

classe econômica e se está no mercado interno ou

externo. Atende ao RQJ-4.

11 LimiteMaximoMP

Possui as informações sobre o limite máximo para

compra de matéria prima. A tag “Tipo” pode ter os

valores “Fixo” ou “CapProdutiva”, onde se for fixo

indica um determinado valor máximo que estará na

tag “Valor”, caso seja “CapProdutiva” o valor

máximo depende da capacidade produtiva do

jogador e em “Valor” haverá o valor que

multiplicado pela capacidade

12 Maquinas

Possui as informações das máquinas. Cada máquina

terá sua tag “Maquina” abaixo desta tag, com as

informações: Nome, Custo fixo por rodada,

produtividade, custo por produto acabado gerado,

custo inicial na compra, qualidade do produto

gerado, quanto períodos demora para depreciá-la

totalmente e o método de pagamento. O método de

pagamento contém: tipo (“prazo” ou “vista”) e se for

a prazo, quanto períodos para recebê-la e os juros (se

é um valor específico ou o do jornal, caso seja do

jornal a tag “Valor” fica vazia). Atende ao RQJ-6.

13 Estoque

Contem as informações do aluguel de locais de

estoque para matéria-prima e produto-acabado;

Atende ao RQJ-7.

14 PANaoVendidos

Contem as informações do aluguel de locais de

estoque para matéria-prima e produto-acabado;

Atende ao RQJ-7.

15 DespesasFuncionarios

Informações com despesas com funcionários, custo

fixo por rodada e se há dissídio (a tag “Valor”

contém a porcentagem do dissídio e “Freqüência”

tem o número de rodadas em q o dissídio ocorre).

71

Atende ao RQJ-13.

16 Marketing

Informações do custo para pbter os serviços de

marketing e se o ganho de quem investe em

marketing é do tipo “fixo”(no caso a tag “Valor” terá

o valor do bônus) ou “porcentagem”(no caso a tag

“Valor” terá a porcentagem ganha em cima das

vendas). Atende ao RQJ-14.

17 BônusVendedores

Contém a porcentagem ganha por vendedores.

Atende ao RQJ-15.

18 Financiamentos

Contém todos os financiamentos definidos pelo

professor. Atende ao RQJ.16. Possui uma tag

“Financiamento abaixo para cada financiamento

definido. Cada financiamento tem as informações:

Nome, a Pré-condição para que ele possa ser feito (0

para sem pré-condição, 1 – limite de outros

financiamentos estourado, 2 – caixa estourado),

Limite, Juros (pode ser do jornal ou específico) e o

Tempo máximo de pagamento em número de

rodadas.

19 CustoJornal Custo para obter o serviço de jornal

20 CustoConsultoria Custo para obter o serviço de consultoria

21 NomeJogo Contém o nome do jogo (atende ao RQJ.18)

22 CaixaInicial Contém o valor de caixa inicialmente dado aos

jogadores no começo do jogo (atende ao RQJ.19).

23 Juros Valor do juros do jornal inicial. Atende ao RQJ.17. Tabela 5.6 – Descrição dos elementos da linguagem

5.9 Implementação

A etapa de implementação visou à construção da arquitetura com base nos requisitos

levantados. Foram consideradas três partes para a implementação total da arquitetura GOG,

embora pedaços de cada dessas partes fossem suficientes para a validação e a verificação da

arquitetura.

A primeira parte dedicou-se à construção da linguagem de definição de jogo (capítulo

5.8) e da ferramenta gráfica de modelagem. A linguagem XML foi escolhida para ser a

linguagem de definição de jogo em virtude da sua portabilidade e interoperabilidade com

diversas plataformas (MCLAUGHLIN, 2001, p.8-9). Para que essa linguagem fosse

facilmente manipulável, uma linguagem de programação mais atual foi escolhida para a

construção da ferramenta gráfica. A ferramenta gráfica de modelagem foi desenvolvida na

plataforma Microsoft .NET com a linguagem C# 4.0, utilizando o ambiente de

desenvolvimento Visual Studio 2010. Essa plataforma foi escolhida para a ferramenta gráfica

em razão da experiência dos integrantes da equipe com ela e da sua fácil manipulação de

72

objetos visuais e integração com outras ferramentas de desenvolvimento. A Figura 5.4

apresenta o resultado dessa primeira parte.

Figura 5.5 – Interface de usuário da ferramenta gráfica de modelagem

A segunda parte da implementação teve como foco o desenvolvimento da base que

constituiria a arquitetura GOG. Nesta parte foram utilizados:

a) Servidor: Apache Tomcat 6.0.33;

b) Sistema Gerenciador de Banco de dados: Oracle 11g XE;

c) Ambiente de Desenvolvimento: Eclipse Indigo 3.7;

d) Linguagens de programação: Java Server Pages (JSP) e Java.

Por fim, a última parte contemplou a interfaces de comunicação entre os componentes

da arquitetura e as interfaces de usuário, utilizadas pelo professor e pelo aluno. Essas

interfaces são apresentadas na Figura 5.6 e Figura 5.7.

73

Figura 5.6 – Interface de usuário da área administrativa do jogo de empresas (área do professor)

Figura 5.7 – Interface de usuário do jogo de empresas (área do aluno)

Deve-se ressaltar que os requisitos para workflow estão contemplados no sistema, de

modo que, assim que o jogador acessa o jogo, e a etapa do jogo foi alterada pelo professor, ou

o tempo de início de uma nova etapa foi ultrapassado (ver RQ-7 e RQJ-1), o sistema identifica

a nova etapa e age de acordo. Na área administrativa, o professor pode gerar, ativar e trocar as

etapas de jogos em andamento, definindo valores de parâmetros para a nova etapa também, se

desejar.

5.10 Testes

A etapa de testes teve como objetivo verificar e validar a implementação conforme os

requisitos. Também coube à etapa de testes a criação de um jogo de empresas segundo a

metodologia exposta no capítulo 4.4.

Baseado na linguagem de definição de jogo apresentada no capítulo 5.8, a Tabela 5.7

apresenta o XML utilizado na etapa de testes para a construção do jogo de empresas na

arquitetura GOG. Basicamente, esse XML apresenta:

a) compra de matéria-prima pela empresa;

74

b) definição dos produtos;

c) decisão sobre investimentos (compra e vendas);

<?xml version="1.0"?>

<DefinicaoJogo>

<NomeJogo> Virtual Milk Game </NomeJogo>

<Contexto>Voce tem uma fabrica de queijo. Aumente seus lucros!

</Contexto>

<MateriaPrima>Leite</MateriaPrima>

<ProdutoAcabado>Queijo</ProdutoAcabado>

<CustoMP>100.0</CustoMP>

<BonusVendedores> </BonusVendedores>

<CustoJornal> </CustoJornal>

<CustoConsultoria>500.0</CustoConsultoria>

<Juros>0.10</Juros>

<CaixaInicial> 10000.0 </CaixaInicial>

<Impostos> 200.0 </Impostos>

<UnidadePA>

<Nome> </Nome>

<QtdInicial> </QtdInicial>

</UnidadePA>

<Modulos>

<Compras>

<condicao></condicao>

</Compras>

<Vendas>

<condicao>2011-11-28 15:32:00</condicao>

</Vendas>

<Compras>


</Compras>

<Vendas>


</Vendas>

<Vendas>


</Vendas>

</Modulos>

<Opcoes>

<Consultoria>0</Consultoria>

<Jornal>0</Jornal>

<Marketing>0</Marketing>

<Estoque>0</Estoque>

<Compras>0</Compras>

<Vendas>0</Vendas>

</Opcoes>

<LimitePrecoPA>

<Minimo>

<MercadoInterno></MercadoInterno>

<MercadoExterno></MercadoExterno>

</Minimo>

<Maximo>

<MercadoInterno></MercadoInterno>

<MercadoExterno></MercadoExterno>

</Maximo>

</LimitePrecoPA>

<Eventos>

</Eventos>

<Locais>

</Locais>

<LimiteMaximoMP>

75

<Tipo></Tipo>

<Valor></Valor>

</LimiteMaximoMP>

<Maquinas>

</Maquinas>

<Estoque>

<MateriaPrima>

<Limite></Limite>

<Custo></Custo>

<CustoPorMP></CustoPorMP>

</MateriaPrima>

<ProdutoAcabado>

<Limite></Limite>

<Custo></Custo>

<CustoPorPA></CustoPorPA>

</ProdutoAcabado>

</Estoque>

<PANaoVendidos>

<IdPolitica></IdPolitica>

<Valor></Valor>

</PANaoVendidos>

<DespesasFuncionarios>

<CustoFixo></CustoFixo>

<Dissidio>

<Valor></Valor>

<Frequencia></Frequencia>

</Dissidio>

</DespesasFuncionarios>

<Marketing>

<Custo>500.0</Custo>

<Tipo>porcentagem</Tipo>

<Valor>0.20</Valor>

</Marketing>

<Financiamentos>

</Financiamentos>

</DefinicaoJogo>

Tabela 5.7 – XML da fase de testes para a construção do jogo de empresas

Após a confecção do documento XML, o arquivo foi importado no sistema através da

área administrativa do professor. Em seguida, ocorreu a ativação do jogo de empresas

importado, resultando na sua liberação de acesso aos alunos.

Após liberação do jogo de empresas pelo professor e login no sistema com o perfil do

ator Aluno, foi possível interagir no sistema, simulando um jogo de empresas

computadorizado.

Com este teste, a arquitetura mostrou-se válida para a criação e o uso de jogos de

empresa computadorizados.

76

6 CONCLUSÕES

O objetivo deste trabalho era propor uma arquitetura que conferisse flexibilidade a

jogos de empresa criados por professores que lecionam disciplinas relacionadas a esse tema.

Através da pesquisa em teoria dos jogos, jogos de empresa no contexto educativo e gestão e

modelagem de processos de negócio, foram estudados os fundamentos técnicos que criaram a

base para a validação da hipótese, apresentada no capítulo 4.4 e capítulo 5.

A metodologia utilizada para o levantamento dos requisitos de um jogo empresarial e

da arquitetura de jogos de empresa que deu sustentação à arquitetura computacional proposta

também colaborou com os propósitos do objetivo: o professor é guiado pela arquitetura para

construir seu próprio jogo e utilizá-lo com seus alunos. Em outras palavras, a metodologia

forneceu:

a) o método para a coleta dos requisitos para a modelagem da arquitetura;

b) o processo para a construção de um jogo de empresas; e

c) o formato de execução da arquitetura GOG: os processos que levam da construção

do jogo de empresas pelo professor à utilização pelo aluno.

Porém, embora a metodologia e os meios utilizados para a construção deste projeto

fossem suficientes para a sua conclusão, alguns pontos do projeto ficaram por concluir, em

razão do tempo que este trabalho seria entregue.

Os componentes da área administrativa, o formato do arquivo de definição de jogo e

as interfaces de comunicação com o professor e o aluno – requisitos principais e essenciais

para a validação da arquitetura – foram concluídas e validadas na fase de testes.

Por outro lado, o que não era essencial para o funcionamento da arquitetura, embora

também não fosse deixado de lado por este motivo, encontra-se ainda por concluir. Neste

ponto, são consideradas, sobretudo, as interfaces de usuário com o professor e o aluno: a

interface para a modelagem do workflow e criação do jogo e a melhora dos aspectos visuais

das interfaces de ativação do jogo para o professor e do jogo em si pelo aluno.

Embora não existam arquiteturas semelhantes à apresentada neste projeto na literatura,

se crê que as propostas apresentadas aqui poderão colaborar com o descobrimento de novos

problemas em jogos de empresa computadorizados.

6.1 Trabalhos Futuros

77

Com a conclusão dos aspectos principais do projeto, é possível sugerir alguns

trabalhos que colaborarão com a sua melhora no campo científico e irão além da sua

conclusão total. É, listado, portanto:

a) a adaptação da arquitetura a áreas específicas do conhecimento da Administração,

como Marketing, Vendas, etc.;

b) a melhora da utilização da arquitetura pelo professor, deixando mais transparente a

interação entre a geração do jogo pela modelagem e a importação do jogo criado

no sistema web;

c) a adaptação do formato do arquivo de definição de jogo a áreas mais específicas do

conhecimento da Administração;

d) a criação de uma linguagem de modelagem de workflows específica para jogos de

empresa.

78

REFERÊNCIAS

ANDERSON, P. H.; LAWTON, L. Methods for evaluating performance on business

simulations: a survey. Developments Business Simulation & Experiential Exercises.

ABSEL, Oklahoma, v. 17, p. 177, 1990.

BALLARD, Chuck et. al. Improving Business Perform Insight... with Business

Intelligence and Business Process Management. Redbooks, 2006.

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language User

Guide. Reading, MA.: Addison-Wesley, 1999.

BORRAJO, F. et al. SIMBA: A simulator for business education and research. Decision

Support Systems, 2010.

CARMICHAEL, Fiona. A Guide to Game Theory. Edinburgo: Prentice Hall, 2005.

COSTA, Cristiene dos Santos. Teoria dos Jogos e a Relação entre o "Teorema Minimax"

de John Von Neumann e o "Equilíbrio de Nash" de John Nash. 2004.

DICIONÁRIO AURÉLIO. Ferreira, Aurélio B. Miniaurélio: o dicionário da língua

portuguesa. 6. ed. rev. atual. Curitiba: Positivo, 2006.

DICIONÁRIO HOUAISS. Dicionário Houaiss da Língua Portuguesa. 2009. Disponível

em: <http://houaiss.uol.com.br>.

DREW, Fudenberg. Noncooperative Game Theory for Industrial Organization: An

Introduction and Overview. 1986.

FELEGYHAZI, Mark; HUBAUX, Jean-Pierre. Game Theory in Wireless Networks: A

Tutorial.

GRAMIGNA, M. R. M. Jogos de empresa. São Paulo: Makron Books, 1993.

GIBBONS, Robert. Game Theory for Applied Economists. Princeton University Press:

New Jersey, 1992.

79

GOOSEN, K. R. A generalized algorithm for designing and developing business simulations.

Developments Business Simulation & Experiential Exercises. ABSEL, Illinois, v. 8, p. 41-

47, 1981.

GOOSEN, K. R.; JENSEN, R.; WELLS, R. Purpose and learning benefits of business

simulations: a design and development perspective. Developments Business Simulation &

Experiential Exercises. ABSEL, v. 26, pp. 133-142, 1999.

HALL, J. J. S. B. Computer business simulation design: the Rock Pool method.

Developments Business Simulation & Experiential Exercises. ABSEL, Orlando, v. 32, pp.

144-154, 2005.

IEEE. IEEE Standards Collection: Software Engineering. IEEE Standard 610.12-1990,

IEEE, 1993.

JACOBSON, I. Object-Oriented Software Engineering. Addison-Wesley, 1992.

KO, Ryan K. L. A Computer Scientist's Introductory Guide to Business Process

Management (BPM). Crossroads Magazine, v. 15, n. 4, jun. 2009.

KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering: Processes and

Techniques, John Wiley & Sons, 2000.

LACRUZ, A. J. Jogos de Empresas: Considerações Teóricas. Caderno de Pesquisa em

Administração, São Paulo, v. 11, n. 4, p. 93-109, out. 2004.

LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis

and Design and the Unified Process. Prentice Hall, 2001. 2. ed.

MCLAUGHLIN, Brett. Java & XML. Sebastopol: O'Reilly, 2001. 2. ed.

NASH, John. Non-cooperative games. Annals of Mathematics. 1951.

NISAN, Noam et. al. Algorithmic Game Theory. Cambridge University Press: New York,

2007.

80

OLIVEIRA, F.; ARAÚJO, M. A.; CÂMARA, M. A. O Teorema Minimax de von

Neumann. In.: CONGRESSO NACIONAL DE MATEMÁTICA APLICADA E

COMPUTACIONAL, 2010, Águas de Lindóia. Anais do CNMAC. 2010. p. 1063.

ORTI, P. S.; RODRIGUES, J. S.; ALBINO, J. P. Fatores Críticos de Sucesso em Jogos de

Empresa. Simpósio de Engenharia de Produção, Brasil, v. XV, n. 1617, nov. 2008.

PELAES, T. S. Modelagem em BPMN de um sistema de Gestão Estratégica de

Operações visando sua simulação em jogo empresarial. 2009. Dissertação (Mestrado em

Engenharia de Produção e Sistema) - Pontifícia Universidade Católica do Paraná, Curitiba.

PRESSMAN, Roger S. Software Engineering: A Practitioner's Approach. 6. ed. McGraw-

Hill, 2005.

REDDI, S. S.; FEUSTEL, E. A. A Conceptual Framework for Computer Architecture.

Computing Surveys, 1976.

ROUDAKY, A.; DOROODCHI M.; Developing Games in Alice using Workflow. Alice

Symposium’09, jun. 2009.

SANTOS, M. R. G. F.; LOVATO, S. Os jogos de empresas como recurso didático na

formação de administradores. CINTED-UFRGS. v. 5, n. 2, dez. 2007.

SWEBOK. Guide to the Software Engineering Body of Knowledge. IEEE Computer

Society, 2004.

SARTINI et al. Uma Introdução a Teoria dos Jogos. 2004.

SHUBIK, M. The uses of teaching games in game theory classes and some experimental

games. Simulation & Gaming, 33, 139-156, 2002.

SAUAIA, A. C. A. Satisfação e aprendizagem em jogos de empresas: contribuições para

educação gerencial. Tese (Doutorado). Faculdade de Economia, Administração e

Contabilidade, Universidade de São Paulo, São Paulo: USP, 1995.

STAHL, M. J.; GRIGSBY, D. W. Strategic Management. Blackwell Publishing, 1997.

81

THAVIKULWAT, P. The Architecture of Computerized Business Gaming Simulations.

Simulation Gaming, v. 35, nº. 2, pp. 242-269, 2004.

TEACH, R. D. Profits: The false prophet in business games. Simulation & Gaming, 21, 12-

26. 1990.

VAN DER AALST, W. M. P., TER HOFSTEDE, A. H. M. e WESKE, M.. Business process

management: A survey. 2003.

VICENTE, Paulo. Jogos de Empresas: a fronteira do conhecimento em administração de

negócios. São Paulo: Makron, 2001.

WESKE, Mathias. Business Process Management: Concepts, Languages, Architectures.

Berlin: Springer, 2007.

WESTPHAL, F. K.; LOPES, P. C. Desenvolvimento de simuladores para jogos de empresa:

abordagens ao design. GEPROS - Gestão da Produção, Operações e Sistemas, Londrina,

PR, v. 5, p. 143-154, out-dez 2007.

82

ANEXO A – UM JOGO DE EMPRESAS DO MUNDO REAL

83

Jogo de Empresas fornecido pelo

Prof. Msc. Marco Aurélio Vallim Reis da Silva

Do Departamento de Administração do

Centro Universitário da FEI

CUSTOS TOTAIS DE PRODUÇÃO

Todas as unidades de Matéria Prima são idênticas entre si. Cada unidade de matéria

prima será transformada em apenas uma unidade de Produto Acabado (P.A). A quantidade de

matéria prima a ser comprada por uma empresa esta limitada a 1,5 vezes sua capacidade

produtiva do respectivo período, arredondada para cima. As compras de matéria prima serão

pagas à vista, ou seja, no mesmo período em que forem realizadas.

Os outros custos variáveis, sendo o principal deles a mão-de-obra, serão

contabilizados por unidade de produto acabado.

A máquina manual produz uma única unidade de produto acabado, com um custo

variável de R$ 20.000 por unidade de produto acabado.

A máquina automática pode produzir uma ou duas unidades de P.A., a critério da

empresa em sua programação da produção. Se a máquina automática produzir apenas uma

unidade de P.A., o custo será de R$ 20.000 por unidade. Se a maquina automática produzir

duas unidades de P.A., o custo cai para R$ 15.000 por unidade de P.A.

Os custos de engenharia, supervisão, taxas de funcionamento, etc., estão custeados por

máquina que estiver disponível no início do período. A depreciação não está incluída nesse

valor.

Mesmo que a maquina não seja utilizada na produção, em certo período, deverá pagar

os custos fixos, cujos valores são:

a) R$ 10000,00 cada máquina manual existente no início do período;

b) R$ 15000,00 cada máquina automática existente no início do período;

Os custos de estocagem, tais como, armazenagem, seguro, movimentação, etc., estão

custeados por unidade de matéria prima ou de produto acabado que estiver estocada no início

do período, e cujos valores são:

a) R$ 4000,00 cada unidade de matéria prima;

b) R$ 8000,00 cada unidade de produto acabado.

84

VENDA DE PRODUTOS ACABADOS

Todas as unidades de produtos acabados são idênticas entre si. As vendas de produto

acabado serão recebidas à vista, ou seja, no mesmo período em que forem realizadas. A

empresa poderá vender os seus produtos tanto no mercado interno como no externo.

O preço máximo de cada unidade de Produto Acabado (P.A) no mercado interno

poderá variar de período para período, entre R$ 50.000 e R$ 120.000. No mercado externo, o

preço poderá variar entre US$ 22.000 (vinte e dois mil d6lares) e US$ 50.000,00 (cinquenta

mil dólares). A venda de P.A obedece a um modelo de distribuição que beneficia a empresa

que oferecer o menor preço tanto no mercado interno quanto no externo.

Se em determinado período a empresa não conseguiu vender no mercado geral toda

a quantidade ofertada, ira vender para urna cliente especial até a totalidade da quantidade

proposta, cancelando o preço inicialmente proposto e recebendo unicamente 0 menor preço

ofertado pelas empresas, diminuído de R$ 4.000 (não haverá dois preços de produto acabado

para uma certa empresa) no mercado interno e de U$ 2.000,00 no mercado externo. O mesmo

procedimento será adotado quando a empresa passar o preço errado ou fora do parâmetro.

DESPESAS ADMINISTRATIVAS

As despesas com os salários do pessoal administrativo são fixas e correspondem a R$

120000,00.

Caso a empresa queira obter informações sobre o mercado (compra de M.P e venda de

P.A) e da concorrência (capacidade produtiva, preço, quantidade vendida, etc.), poderá

contatar o serviço de uma consultoria (coordenador do jogo) em qualquer instante do período

que precisar das informações. Em cada rodada será fornecido o valor dessa consultoria.

DESPESAS DE VENDAS

A empresa poderá investir em marketing com o objetivo de melhorar suas vendas. Em

cada rodada será fornecido o investimento em marketing. As empresas que realizarem esse

investimento terão um bônus em percentual (%) sobre a receita de vendas. Estas informações

constarão no formulário de decisões.

Os vendedores recebem urna comissão de 10% sobre as vendas (antes do bônus caso

tenha efetuado a despesa em marketing).

85

COMPRA DE MÁQUINAS NOVAS

Em qualquer período, a empresa pode comprar máquinas novas.

Qualquer máquina, seja manual seja automática, é depreciada em quatro períodos.

A primeira prestação (50 %) é paga no período da encomenda. A segunda prestação

(também 50 %) é paga sem juros no período em que a maquina é recebida e já começa a

operar e a ser depreciada. A depreciação é totalmente alocada no custo dos produtos vendidos

da empresa.

O preço da máquina manual é R$ 50.000. Portanto, cada prestação é igual a R$

25000,00. Sendo encomendada no período N, é recebida no período N+l. A sua depreciação é

igual a $ 12.500 por período.

O preço da máquina automática é R$ 100000,00. Portanto, cada prestação é igual a $

50000,00. Sendo encomendada no período N, é recebida no período N+2. A sua depreciação é

igual a $ 25000,00 por período.

ATIVO IMOBILIZADO

Seu valor é a soma de todos os valores residuais das máquinas, considerados no fim do

período. Inclui todas as máquinas da empresa, seja em operação seja encomendadas

(compradas).

As máquinas encomendadas figurarão pelo seu valor total, sem depreciação; a

compensação da segunda prestação não paga será feita com a sua inclusão no “Passivo” do

balanço, na conta “investimentos a pagar”.

No período em que for recebida, a máquina comprada já entra em operação e sofre

depreciação, mesmo que não venha a ser utilizada.

A máquina será desativada após decorrida a sua vida útil fiscal, ou seja, após os 4

períodos nos quais ela pôde ser utilizada. Ela não mais produzirá, sendo automaticamente

excluída do Ativo Imobilizado.

FINANCIAMENTO

86

O valor solicitado é recebido no mesmo período em que é feito o pedido, e os juros são

pagos no final do período.

Financiamento normal: se a empresa não dispuser de saldo de caixa suficiente para

pagar as prestações da compra de máquinas, financiamentos anteriores, Imposto de Renda ou

dividendos, ou quiser aumentar o saldo de caixa final tendo em vista o período seguinte,

recorrerá ao financiamento normal. Este financiamento cobra juros de acordo com a taxa

fornecida pelo jornal informativo de cada período. Sendo pedido no período N, terá que ser

pago no período N+2 no valor solicitado. O valor limite do financiamento normal é 50% do

ativo não circulante.

Financiamento de emergência: será concedido obrigatoriamente quando houver

estouro de caixa. Este ficará negativo quando o caixa inicial do período mais as receitas

financeiras forem menores que os pagamentos dos custos e despesas de produção (pagamento

de matéria-prima; despesas de produção; custos fixos; despesas de vendas e despesas

administrativas) e ou facultativamente quando a empresa ainda precisar de dinheiro e tiver

ultrapassado o limite do financiamento normal. Vale ressaltar que a receita de vendas do

período e as demais entradas e saídas de caixa somente ocorrerão depois dos pagamentos dos

custos e despesas de produção. Este financiamento cobra juros maior que o financiamento

normal e a taxa será fornecida pelo formulário. Sendo pedido no período N, terá que ser pago

no período N+1 no valor solicitado. Não há limite para o financiamento de emergência.

CAIXA

O “saldo inicial” de um período é o “saldo final” do período anterior.

O saldo final não pode ser negativo. Se isto acontecer, a empresa deve fazer um

financiamento de emergência no período, suficiente ao menos para o saldo ficar nulo.

Caso o saldo fique negativo, a empresa recebe obrigatoriamente um financiamento de

emergência para o referido saldo parcial ficar nulo. Este valor obrigatório é também um valor

mínimo do financiamento de emergência, podendo a empresa solicitar um valor maior. Por

uma questão de simplificação, a receita financeira será calculada com base na raiz quadrada

da taxa SELIC do período em cima do caixa inicial.

PAGAMENTOS DE DIVIDENDOS

87

As empresas devem distribuir obrigatoriamente um dividendo mínimo de 30% do

lucro liquido. Para simplificar, nesta simulação, o dividendo será calculado em relação ao

lucro líquido do exercício anterior. O dividendo não deverá ser pago caso a empresa apure

prejuízo.

IMPOSTO DE RENDA

A alíquota de imposto de renda e contribuição social é de 34%.

GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa

Sports

Transcript of GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa