A Metodologia Maiêutica (M²) é uma metodologia para desenvolvimento de Softwares 3D Interativos (S3DI) com foco na educação (ROSSITO et al., 2012) e inspirada em um método proposto pelo filósofo grego Sócrates, chamado Maiêutica. Este método consiste na constante elaboração de perguntas (e suas respectivas respostas) como forma de fazer um interlocutor criar uma conceituação geral de um objeto (HOUNSELL; ANZOLLIN; KEMCZINSKI, 2005). Com a utilização da Maiêutica na M², tem-se uma metodologia que aplica uma série de perguntas para um analista de projeto, referentes aos diversos aspectos do sistema proposto: como ele deve se comportar, suas limitações, suas interfaces e etc. Estas perguntas podem ter caráter objetivo ou descritivo. Através destas perguntas, a M² busca permitir que o analista reflita e refine sua definição do S3DI a ser desenvolvido.
Em sua proposta original, a M² suportava apenas o desenvolvimento de aplicação de Realidade Virtual (RV). Seu escopo porém foi aumentando conforme os anos, passando a suportar também Realidade Aumentada (RA) e Jogos Sérios 3D (JS3D), caracterizando então este conjunto de aplicações como S3DI (ROSSITO et al., 2012).
A M² é fundamentalmente dividida em quatro projetos distintos: Projeto Conceitual, Projeto de Comunicação, Projeto de Estrutura e Projeto de Desenvolvimento, organizados conforme Figura 12.
Figura 12 – Diagrama de atividades dos projetos da M²
Fonte: adaptado de Hounsell, Anzollin e Kemczinski, 2005.
O Projeto Conceitual é onde estão localizados os principais esforços da metodologia. Neste projeto, que pode ser observado em detalhes na Figura 13, definem-se o tipo e o objetivo da aplicação, sendo aplicados os princípios da maiêutica através de perguntas de diferentes escopos.
O diagrama de atividades da Figura 13 é focado na ordem em que os questionários (blocos com cor rosa) com perguntas maiêuticas devem ser respondidos. O primeiro questionário no fluxo de atividades contém as Perguntas Objetivas Básicas (POB), que servem para delinear o DNA da aplicação (referente ao seu tipo), e inclui questões referentes a tópicos como a veracidade do ambiente virtual, a área de conhecimento em que se aplica o software desenvolvido, tipo de imersão, e etc. Ao total, as POB consistem em 23 perguntas objetivas, disponibilizadas no Anexo A.
Após o preenchimento das POB, é necessário responder outros três questionários. Estes questionários são: Descrição Conceitual (DC); Perguntas Objetivas Avançadas (POA) e; Perguntas Objetivas Educacionais (POE).
As perguntas da DC (ver Anexo B) estabelecem uma documentação formal dos requisitos do software. Estas 16 perguntas, de caráter descritivo, abrangem temas como escopo, metas, métricas, público alvo, e definição de requisitos técnicos e funcionais.
Figura 13 – Diagrama de atividades do projeto conceitual da M²
Fonte: adaptado de Rossito, 2012.
As Perguntas Objetivas Avançadas (POA), com o total de 18 perguntas listadas no Anexo C, lidam com os aspectos de interação e usabilidade do software, ou seja, como o UFA interage com o mundo virtual, como seleciona objetos, navega por ambientes, como o software gera feedback, etc.
Por fim, as Perguntas Objetivas Educacionais (POE) auxiliam o projetista a verificar se sua aplicação tem mais caráter educacional ou de treinamento através de perguntas referentes ao tipo de aprendizado que se espera que os UFA obtenham, as formas de avaliação dos resultados, os procedimentos pedagógicos adotados para o uso do software, entre outros. Ao total, são 16 POE conforme listado no Anexo D.
Após responder as perguntas do Projeto Conceitual, o projetista deve validar os requisitos levantados, podendo contar ou não com a ajuda de um UFE que esteja envolvido no projeto. Conforme o diagrama de atividades, caso os requisitos sejam reprovados, os questionários devem ser revisados em uma nova iteração, até que a aprovação dos requisitos ocorra.
Com os requisitos aprovados, iniciam-se paralelamente o Projeto de Comunicação e o Projeto de Estrutura. O Projeto de Comunicação possui um único questionário chamado Perguntas Descritivas de Comunicação (PDC), que contém 38 perguntas disponibilizadas no Anexo E. Este projeto visa transformar em elementos de interface as funcionalidades descritas nos requisitos. Aqui os elementos de usabilidade e semiótica tem grande impacto nas perguntas descritivas da metodologia.
O Projeto de Estrutura, por sua vez, busca definir a arquitetura do sistema a ser desenvolvido e conta com um questionário chamado Perguntas Descritivas de Estrutura (PDE), que contém 12 perguntas conforme Anexo F. Nesta etapa, são definidos padrões, métricas e estilos, podendo se utilizar de ferramentas comuns da Engenharia de Software, como Modelo Entidade-Relacionamento, Diagrama de Fluxo de Dados, UML (Unified Modeling Language, ou Linguagem de Modelagem Unificada) entre outros.
Ao finalizar os projetos de Comunicação e Estrutura, inicia-se o Projeto de Desenvolvimento e aloca-se os recursos da equipe técnica, define cronogramas, sequenciamento de desenvolvimento e culmina na codificação e validação do software em si. Para apoiar o projetista nesta etapa, existem 9 questões nas Perguntas Descritivas de Desenvolvimento (PDD), que estão disponibilizadas no Anexo G.
3.3.6 Considerações Finais
Nas metodologias apresentadas nesta seção, a participação de UFA proposta sempre tem caráter obrigatório. Isto limita o uso destas metodologias em situações onde não é viável o envolvimento dos UFA. Além disso, é possível analisar outras comparações entre as metodologias, conforme Tabela 6, onde cada linha representa uma das metodologias apresentadas, e as colunas trazem informações a respeito das metodologias correspondentes: qual tipo de jogo é focado, se ocorre participação em etapas conceituais e técnicas, se existe suporte para requisitos tripartite.
Quanto aos tipos de aplicações que as metodologias relacionadas focam em desenvolver, tanto a metodologia baseada na teoria da atividade quanto a Game2Learn são voltadas à jogos educacionais (JE). Este é um tipo de jogo que é considerado como subgênero de JS (MICHAEL; CHEN, 2005). A M² é a única metodologia que aplica-se a um escopo mais abrangente, pois também pode ser utilizada para desenvolver aplicações S3DI, ou seja, RV, RA e JS.
Tabela 6 – Comparativo entre metodologias participativas Metodologia Foco Participação de UFA Requisitos Tripartite Conceitual Técnica
Criação Validação Criação Validação
Game2Learn JE Sim Não Não Sim Sim
Metodologia para JS3D de Treinamento JS3D Não Não Não Sim Não
Metodologia baseada em Teoria da Atividade
JE Sim Sim Não Sim Sim
Processo de Desenvolvimento do LIAG JS Não Sim Sim Sim Não
Metodologia Maiêutica S3DI Não Não Não Sim Não
Fonte: produção do próprio autor, 2015.
Com relação a participação conceitual, ou seja, participação em etapas onde o JS é especificado, apenas a metodologia baseada na teoria da atividade contempla a participação dos UFA tanto criando especificações quando validando-as.
Já na participação técnica, ou seja, onde conteúdo do JS é desenvolvido, nenhuma metodologia contempla a participação dos UFA criando conteúdo, exceto o processo de desenvolvimento do LIAG. Em compensação, todas as metodologias contemplam a participação avaliando o conteúdo.
Em se tratando de requisitos tripartite, ou seja, requisitos que conciliam as perspectivas dos UFE, UFA e da ETD, apenas a metodologia baseada na teoria da atividade e a Game2Learn oferecem recursos para a criação deste tipo de especificação.