GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa
-
Upload
orlando-junior -
Category
Sports
-
view
1.598 -
download
2
description
Transcript of 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
GOG: uma arquitetura computacional para a criação e o uso de jogos de empresa
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.
São Bernardo do Campo
2011
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
Trabalho de Conclusão de Curso – Centro Universitário da FEI
Comissão julgadora
_________________________________________________
Orientador e Presidente
_________________________________________________
Examinador (1)
_________________________________________________
Examinador (2)
São Bernardo do Campo
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
Fonte: adaptado de Weske, 2007, pag. 9
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
Fonte: adaptado de Weske, 2007, pag. 12
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.
Fonte: adaptado de Weske, 2007, pag. 51
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.
Fonte: adaptado de Weske, 2007, pag. 51
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="Marketing"/>
<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="Marketing"/>
<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="Nome"/>
<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="Juros"/>
<xs:element ref="Impostos"/>
<xs:element ref="Marketing"/>
<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="Nome"/>
<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="Tipo"/>
<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="Nome"/>
<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="Tipo"/>
<xs:element ref="Tempo"/>
<xs:element ref="Juros"/>
</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:element ref="Valor"/>
</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="Valor"/>
<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="Nome"/>
<xs:element ref="IdPreCondicao"/>
<xs:element ref="Limite"/>
<xs:element ref="Juros"/>
<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="Limite"/>
<xs:element ref="CustoPorMP"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="CustoPorMP">
<xs:complexType/>
</xs:element>
<xs:element name="ProdutoAcabado">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Custo"/>
<xs:element ref="CustoPorPA"/>
<xs:element ref="Limite"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Juros">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Tipo"/>
<xs:element ref="Valor"/>
</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:complexType mixed="true">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="condicao"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Vendas">
<xs:complexType mixed="true">
<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">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Custo"/>
<xs:element ref="Tipo"/>
69
<xs:element ref="Valor"/>
<xs:element ref="condicao"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="Consultoria" type="xs:string"/>
<xs:element name="Estoque">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<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>
<condicao>2011-11-28 15:37:00</condicao>
</Compras>
<Vendas>
<condicao>2011-11-28 15:42:00</condicao>
</Vendas>
<Vendas>
<condicao>2011-11-28 15:47:00</condicao>
</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%.