Especificação de software de realidade aumentada voltado para o ensino tecnológico

ARTIGO ​​ ORIGINAL

Especificação de software de realidade aumentada voltado para o ensino tecnológico

Gislane Martins S. de Abreu ¹; Lucas R. Madeira ²;Carlos de S. Soares Neto ³

..

1. Introdução

No tempo atual, uma difusão de novas tecnologias vem destacando-se para propiciar a educação e a absorção das informações “[...] fundamentais para a tomada de decisões e resolução de problemas.” (Hessel et al, 2024)8. Uma dessas tecnologias inovadoras que está sendo bastante aplicada para a educação conhecida como Realidade Aumentada (RA), que pode ser conceituada como a “[...] justaposição de objetos virtuais tridimensionais, gerados por computador, em um ambiente real, por meio de algum dispositivo tecnológico”. (Lin et al, 2019).10

Conforme destaca Tori et al, (2006)13 “A Realidade Aumentada enriquece o ambiente físico com objetos virtuais, ampliando o entendimento do ambiente real”. Nesse contexto, “[...] Essa inovação contribui com mudanças na maneira como as pessoas se comunicam, trabalham e se relacionam na era digital”. (Gatti et al, 2024)6.

Apesar do avanço no uso de soluções de Realidade Aumentada, sua utilização ainda apresenta pouca utilização, especialmente quando aplicado ao ensino e aprendizado, uma vez que projetistas de Realidade Aumentada, até o momento, tem poucos parâmetros específicos para definir “um conjunto de diretrizes ou heurísticas para ajudar na implementação”. (Hamilton, 2011)7. Liao (2019)11 assevera em sua pesquisa que “[...] a usabilidade não tem recebido um foco adequado, não se preocupando com as diferentes capacidades e usuários na utilização das tecnologias.” (Liao, 2019)11.

Dessa forma foi observado que uma metodologia se faz necessária para colaborar com o projeto de tecnologias inovadoras, tal como Realidade Aumentada, no processo de criação e avaliação dos projetos. Tal metodologia visa oferecer benefícios a fim melhorar a compreensão de parâmetros específicos que podem ser empregados. Uma vez que “[...] aplicativos implementados utilizando a engenharia de requisitos tradicional podem não favorecer a melhoria da usabilidade do sistema.” (Hamilton, 2011).

Esse trabalho apresenta a utilização de uma metodologia de análise de requisitos voltada especificamente para o desenvolvimento de objetos educacionais com realidade aumentada, a fim de promover a implementação de realidade aumentada como apoio ao ensino tecnológico. Um dos pré-requisitos fundamentais é entender o ponto de vista dos usuários e stakeholders, buscando fazer uso da análise do domínio para obter maiores ganhos por meio de um projeto centrado no usuário.

O objetivo é ajudar os desenvolvedores a determinar como realizar a seleção de recursos como interface, requisitos funcionais e não-funcionais, além dos objetos de aprendizado a serem utilizados.

.

2. Referencial teórico

A Realidade Aumentada está definida como uma categoria integrante das tecnologias de realidades mistas. (Endsley et al, 2017)3. Cuja principal característica é “associar objetos virtuais com o mundo real, por meio da interação de objetos reais no meio virtual, conhecido como virtualidade aumentada.” (Tori et al, 2006)13. Podemos destacar a RA como um sistema cuja vantagem é “[...] aumentar o conjunto de dados disponibilizados no cenário, em que as informações oferecidas pelos objetos virtuais servem de apoio ao usuário na execução de atividades do mundo real." (Holme et al, 2005)9.

Diversos especialistas elaboram objetos de aprendizagem com pouca preocupação sobre a adequação de tal recurso para o tipo de usuários que irão utilizá-lo. Do mesmo modo, há pouca preocupação em utilizar pesquisas, tal como análises de requisitos de maneira prévia ao desenvolvimento do software de RA. Por diversas vezes, a avaliação é postergada para as fases finais do processo de implementação do software, dessa forma o processo se torna mais oneroso e complexo. Costabile et al (1) atesta que “[...] objetos de aprendizagem, assim como, aplicativos utilizados na educação, precisam ser de fácil utilização[...]” (Costabile et al) (1). Caso contrário, a fluidez de uso do usuário será prejudicada com o aplicativo, ao invés de promover o aprendizado. Uma vez que a simplicidade de uso se relaciona diretamente à usabilidade do software.

A usabilidade pode ser definida desde o início do projeto, no entanto, ocorre uma certa “[...] carência de recursos adequados, princípios e fundamentos apropriados na identificação dos requisitos necessários de usabilidade do público-alvo.” (Gale et al., 2015)4. No entanto, essa análise deve ser considerada “[...] uma parte essencial no projeto de implementação do software e necessita de estudos com maior intensidade, além da dedicação dos desenvolvedores desses ambientes de aprendizagem [...]” (Nakamoto, 2011)12.

As diversas estratégias de engenharia de usabilidade, quando examinadas de maneira mais aprofundada, em sua maioria, demonstram que as atividades de projeto são definidas e organizadas conforme padrões e modelos bastante utilizados no cotidiano. No entanto, Lin et al (2019)10 observa que em algumas situações “[...] a tecnologia dispõe de paradigmas mais modernos para interatividade dos alunos, ou ainda interferem de maneira substancial na percepção dos usuários” (Lin et al, 2019)10. O que pode dificultar o entendimento de como cada usuário irá se adaptar aos desafios do ambiente apresentado pelo sistema (por exemplo: a manipulação de objetos tridimensionais, a interação com o cenário real, a utilização de recursos, tais como marcadores, tablets, dentre outros equipamentos).

Vale destacar que em nosso projeto, será utilizado o princípio BYOD, ou seja, Bring your Own Device, que significa de maneira genérica: traga seu próprio dispositivo. Ele propõe que os alunos utilizem seus dispositivos, uma vez que a maioria dos smartphones e tablets atuais são compatíveis com a tecnologia de realidade aumentada. Pois dessa forma busca-se evitar novas despesas com laboratórios e equipamentos e tecnologias específicas de alto custo. Além disso, a instituição de ensino dispõe de tablets para uso educacional, os quais serão considerados na avaliação de requisitos e posteriormente na avaliação de usabilidade.

Outro ponto que incentiva para a escolha do princípio BYOD considera que nos aplicativos onde se emprega capacetes e mecanismos de visão ótica direta, nem todos os usuários se adequam a tecnologia, pois o uso de lentes e capacetes por tempo prolongado ocasiona uma sintomática característica de exaustão, vertigem, fadiga ou supressão de profundidade. (Hessel et al., 2024)8. Considerando tais características, o objetivo é realizar uma análise de requisitos aprofundada, para a escolha mais adequada dos atributos para o desenvolvimento do aplicativo de Realidade Aumentada a ser utilizado.

.

3. Metodologia

Os principais fluxos da engenharia de software voltados para o desenvolvimento de aplicativos de realidade aumentada foram adaptados com base na metodologia proposta por Pádua (2008), em que descreve o processo, conhecido como Praxis, um acrônimo para PRocesso para Aplicativos eXtensíveis e InterativoS. Tal metodologia é definida como “[...] um processo de software fundamentado no modelo de entrega evolutiva.” (Pádua, 2008). Ela estabelece um processo de desenvolvimento de software voltado para projetos de curta e média duração, produzidos de forma individual ou por equipes pequenas. É indicada para o desenvolvimento de aplicativos gráficos interativos, baseados em orientação a objetos.

O objetivo é apoiar os desenvolvedores na análise de requisitos, conforme a metodologia apresentada. Ela apresenta uma abordagem de engenharia de usabilidade modificada, que estende o processo apresentado em Gabbard (2008)5. Vale lembrar que as atividades de análise de requisitos não estão restritas somente a essas atividades. Essas possuem como objetivo apenas complementar e introduzir os projetistas na análise de requisitos.

Acompanhando a arquitetura estabelecida no Processo Unificado, o PRAXIS apresenta um ciclo de vida formado por fases, decomposta em uma ou mais iterações e fluxos. Na Tabela 1 são apresentadas as atividades principais a serem realizadas em cada um dos módulos da análise.

Tabela 1: Fases e Iterações do Processo PRAXIS. 

Fonte: Pádua, (2008).

O processo de especificação de software é formado por diversas etapas que são: Estudo de viabilidade do software, Verificação da exigência, Especificação dos requisitos de software, Validação dos requisitos de software. Em nosso estudo, vamos realizar tal análise por meio da: Análise do perfil do usuário, para cada tipo de usuário previsto. 

Os projetistas buscam conhecer os atributos pessoais dos usuários (motivação e limitações), suas habilidades e competências (na tarefa, na organização, no uso de dispositivos móveis, na utilização de ambientes 3D e em sistemas informatizados). ​​ Em seguida, é realizada a Análise do contexto da tarefa, pois para cada tarefa a ser apoiada pelo sistema, os projetistas procuram conhecer os objetivos e resultados, a estrutura, a duração, as dependências, os custos, a carga mental, as interrupções, os incidentes, dentre outros detalhes. para definir o levantamento das funções, requisitos funcionais e não-funcionais e posteriormente a modelagem conceitual dos elementos.

Dessa forma, é possível auxiliar projetistas e usuários na identificação de uma solução, pela associação do problema identificado às possíveis características (a partir das necessidades), estando elas associadas a padrões.

.

.Tabela 2: Atividades da Especificação de Requisitos. Fonte: Pádua, (2008).

Com o objetivo de guiar e auxiliar os projetistas na análise de requisitos, seguindo a metodologia proposta, na Tabela 2 são apresentadas as atividades principais a serem realizadas em cada um dos módulos da análise.

Vale lembrar que as atividades de análise de requisitos não estão restritas somente a essa abordagem, uma vez que tal arcabouço possui como objetivo apenas complementar a introdução dos projetistas na análise de requisitos.

Com as informações da tabela 2, foi desenvolvido o projeto de interface do usuário. Esse projeto é avaliado tanto por especialistas quanto por usuários do sistema. A cada iteração, o projeto é refinado após avaliação. Este processo de refinamento ocorre de maneira iterativa, até que o projeto esteja adequado.

.

4. Desenvolvimento e discussão

Seguindo a metodologia indicada, ainda na fase de levantamento de requisitos, foi efetuado o estudo sobre o levantamento das funções, interfaces, requisitos funcionais e não-funcionais esperados para o produto, conforme tabela 3. 

Tabela 3: Requisitos funcionais do software.

Fonte: autor, 2024.

.

Na etapa seguinte de análise de requisitos, foi organizada a elaboração dos protótipos de baixa fidelidade, em que consta o detalhamento dos casos de uso. Tais protótipos visam representar como serão as características da interface e seu funcionamento. As vantagens de tal modelo estão relacionadas à facilidade na organização das ideias, elementos e fluxos de atividades. Conforme demostrado na tabela 4

Tabela 4: protótipo de baixa fidelidade da tela de auto cadastro, novas turmas e disciplinas. Fonte: autor, 2024.