• Nenhum resultado encontrado

MODELO DE PROCESSO DE ENGENHARIA DE SOFTWARE

No documento UNIVERSIDADE FEDERAL DO PARANÁ (páginas 67-73)

Este modelo, proposto por Rodrigues (2010) é constituído de um conjunto de disciplinas que proporcionam diretrizes para definir as tarefas e atribuir responsabilidades em um projeto. Neste processo são definidas quatro fases, sendo elas, concepção, pré-produção, produção e pós-produção, sendo que um projeto utilizando este processo quando tiver passado pelas quatro fases, terá produzido uma geração do jogo, esta passagem é conhecida como ciclo de desenvolvimento ou marco.

Além das fases de desenvolvimento também existem sete processos de criação e três de apoio, que são tratados cada um como uma disciplina. Sendo que a ênfase em cada uma destas disciplinas varia conforme o andamento do projeto. A seguir estão descritos os processos de criação.

• Análise de mercado: esta disciplina tem o objetivo de compor o conjunto de atividades relacionadas ao conceito do jogo, levando em consideração seus aspectos educacional e de entretenimento (RODRIGUES et al., 2010).

• Projeto pedagógico-educacional: esta disciplina demanda um maior esforço nas duas primeiras fases do modelo. Ela é responsável por descrever e fundamentar o jogo educacional, tendo em vista suas necessidades didáticas (RODRIGUES et al., 2010).

Game Design: é responsável por se preocupar com a questão de pré-produção. Nele serão definidos e especificados todos os elementos de implementação do jogo, de tal forma que permita seu desenvolvimento (RODRIGUES et al., 2010).

• Implementação: esta visa na definição da organização do código-fonte, na implementação de classes, objetos e componentes, na execução de testes nestes componentes e na integração dos elementos produzidos em arquivos executáveis. Durante este processo são construídas diversas versões operacionais do sistema (builds) ou de parte dele.

• Teste: como o próprio nome já diz, nesta etapa serão testados os componentes desenvolvidos anteriormente. Sendo esta uma parte de fundamental importância no desenvolvimento do projeto, já que “a correção de problemas é de 100 a 1000 vezes mais cara de realizar após a implantação do sistema do que no início do projeto” (MARTINS, 2007, p. 228).

• Distribuição: este processo tem por objetivo disponibilizar o sistema ao usuário, incluindo testes em ambiente de produção, empacotamento, distribuição e instalação do jogo.

Além dos processos de criação, ainda existem os de suporte, que visam facilitar o gerenciamento do projeto por parte da equipe de desenvolvedores. Sendo tais processos definidos a seguir.

• Gerenciamento do projeto: este estabelece uma conduta para a coordenação, informado a todos o que fazer e quando fazer, permitindo um maior controle do andamento por parte do gerente de projeto.

Sendo um grande exemplo de documentação deste processo o Plano de Gerenciamento do Projeto (PGP), o qual constitui-se de um conjunto de documentos, como planos de gerenciamento de atividades, custos, comunicações, riscos, etc.

• Gerenciamento de configuração e mudanças: visa registrar e manter um caminho das mudanças e da evolução do sistema. Em um processo iterativo os artefatos evoluem constantemente, tornando imprescindível que hajam condições de localizar as várias versões desenvolvidas.

Sendo neste processo definidas regras e responsabilidades, além da ferramenta utilizada, no controle de mudanças.

• Gerenciamento de ambiente: nesta disciplina todas as atividades referentes ao suporte de processos e ferramentas necessárias para o ciclo de produção do jogo serão englobadas.

Sabendo disso, o gráfico de baleias (Figura 33) explicita o comportamento das disciplinas em relação a cada uma das fases do processo, demonstrando assim o nível de esforço em cada uma delas.

FIGURA 33 – ESTRUTURA DO MODELO DE PROCESSO PARA O DESENVOLVIMENTO DE SERIOUS GAMES

FONTE: Rodrigues et al. (2017?, p. 5).

Assim, apesar de o RUP original sugerir que sua utilização se encaixa com a modelagem orientada a objetos, as tecnologias utilizadas para o desenvolvimento deste projeto o tornam orientado a eventos, além do fato de ser um jogo e não um sistema de informação tradicional. Portanto, para melhor compreensão de todas as partes do jogo, decidiu-se utilizar a Análise Essencial em conjunto com o Game Design Document (GDD) e os documentos que o ajudam a compor. Assim, o GDD surge para abranger toda parte artística e de entretenimento do jogo, os quais não são possíveis alcançar com as modelagens convencionais de sistemas. Os documentos modelados estão listados a seguir.

• Requisitos Funcionais e Não Funcionais (Seção 3.1.1)

• Análise Essencial

o Lista de Eventos (Apêndice B)

o Diagrama de Fluxo de Telas (Apêndice C)

o Diagrama de Contexto (Apêndice D) o Diagrama de Fluxo de Dados (Apêndice E) o Dicionário de Dados (Apêndice F)

o Diagrama de Transição de Estados (Apêndice G)

• Modelagem de Jogos

o Página-única (Apêndice H) o Dez-páginas (Apêndice I) o Gráfico de Ritmo (Apêndice J)

o Game Design Document (Apêndice K)

3.1.1 Requisitos Funcionais e Não Funcionais

O procedimento de obtenção de requisitos possui diversos objetivos, dentre eles, a manutenção de um acordo com o cliente e as partes interessadas, quanto ao desempenho do sistema, o esboço das interfaces, a transmissão clara dos requisitos para a equipe de desenvolvedores, além de providenciar informações valiosas para o planejamento do projeto, como o conteúdo técnico realizado nas iterações e contribuição para a estimativa de prazos e riscos (MARTINS, 2007).

Sendo que os requisitos são definidos como funcionais e não funcionais, os quais representam o comportamento do sistema e as características não relacionadas ao comportamento, respectivamente (MARTINS, 2007).

Os requisitos levantados estão dispostos nas tabelas a seguir, onde são apresentados os requisitos funcionais (F) e os não funcionais (NF) com suas respectivas descrições (WAZLAWICK, 2008 apud QUEIROGA, 2013). Requisitos que abordam o acesso ao jogo, a jogabilidade em si, configurações, a saída e conteúdos extras.

TABELA 14 – ACESSO DO USUÁRIO AO JOGO F1 - Acesso do usuário ao

jogo

Descrição: O jogador deverá selecionar, ou criar, um perfil para que o jogo acesse e carregue as informações.

Requisitos Não Funcionais

Nome Restrição

NF 1.1 - Controle de acesso O jogador só terá acesso aos "mundos" se for selecionado um perfil existente ou criado um novo e selecionado posteriormente.

NF 1.2 - Apresentação dos

"mundos"

Somente após a entrada em um perfil, a interface de seleção de

"mundos" aparecerá.

NF 1.3 - Seleção de "mundo" O jogador terá que selecionar um "mundo" desbloqueado.

NF 1.4 - Apresentação das fases

Após a escolha de um "mundo" a lista de fases disponíveis irá ser apresentada.

NF 1.5 - Seleção de fase O jogador deve escolher uma fase entre as desbloqueadas.

NF 1.6 - Acesso ao jogo A interface da fase só aparecerá após todas as funções acima

Uma mensagem contendo o objetivo aparecerá no início da fase, além de ser possível clicar em 'objetivo' para vê-lo novamente.

NF 2.2 - Visualização de ajuda O jogador pode acessar a ajuda através do NPC no canto inferior esquerdo.

NF 2.3 - Seleção de comandos O jogador poderá fazer a ação de "arrastar e soltar" os comandos disponíveis.

NF 2.4 - Auto ajuste da lista de comandos selecionados

A lista de comandos deve se auto ajustar quando o jogador colocar um comando antecedendo outros. execução da lista de comandos

Animações em pixel art devem ocorrer no momento que o jogador selecionar a opção 'PLAY'.

FONTE: Os autores (2017).

TABELA 16 – PAUSAR

F3 – Pausar

Descrição: Caso o jogador aperte o botão de 'Pause' ou a tecla ESC, um pop-up com configurações irá aparecer.

Requisitos Não Funcionais

Nome Restrição

NF 3.1 – Retomar O jogador poderá retomar a fase, clicando em 'retomar'.

NF 3.2 - Retornar para a

NF 3.4 - Opções de áudio O jogador poderá habilitar ou desabilitar tanto a música quanto os efeitos sonoros do jogo.

FONTE: Os autores (2017).

TABELA 17 – SAIR

F4 – Sair

Descrição: Caso o jogador escolha esta opção, ele terá que confirmar se realmente deseja sair, assim fechando o jogo.

Requisitos Não Funcionais

Nome Restrição

NF 4.1 – Confirmar O jogador só poderá sair se confirmar que realmente deseja.

NF 4.2 – Sair Quando o jogador confirmar a saída, o jogo se fechará.

FONTE: Os autores (2017).

TABELA 18 – EXTRAS F5 – Extras

Descrição: HQs em formato de vídeo serão transmitidas ao jogador com a narrativa da estória.

Requisitos Não Funcionais

Nome Restrição

NF 5.1 - Introdução Sempre que o jogo iniciar um vídeo contendo a narrativa do Capítulo "O fim de alguns é a origem de outros..." irá ser exibido.

NF 5.2 - Mundo 1 Somente na primeira vez que o jogador iniciar o "mundo 1" um vídeo contendo a narrativa do Capítulo “De Estudante a Comandante em 1 dia” irá ser exibido.

NF 5.3 - Mundo 2 Somente na primeira vez que o jogador iniciar o "mundo 2" um vídeo contendo a narrativa do Capítulo "Empilhando Problemas" irá ser exibido.

NF 5.4 - Mundo 3 Somente na primeira vez que o jogador iniciar o "mundo 3" um vídeo contendo a narrativa do Capítulo "Operação Floresta de Mechas" irá ser exibido.

NF 5.5 – Final Somente após o jogo ser concluído um vídeo contendo a narrativa do Capítulo

"Unindo Velho e Novo" irá ser exibido.

NF 5.6 – Pular Será possível 'pular' os vídeos durante sua exibição ao clicar em qualquer tecla.

FONTE: Os autores (2017).

No documento UNIVERSIDADE FEDERAL DO PARANÁ (páginas 67-73)