EDET

5W2H

What

• 1. Qual o nome do seu projeto?
  • Eye Do Easy Translog (EDET).

• 2. Qual o objetivo deste projeto?
  • Desenvolver uma ferramenta de pesquisa, com interface amigável, que efetua o registro e a análise de dados do processo de leitura, produção textual e/ou tradução (e.g., fixações, pausas, movimentos recursivos, digitações), dados esses coletados por meio de rastreamento ocular, registro de acionamentos do teclado e insumos de reconhecimento de voz. Em outras palavras, trata-se de uma aplicação que permite compreender, do ponto de vista cognitivo, como o usuário lê, digita, dita e traduz.

• 3. Quais os maiores desafios, na sua opinião, para se realizar este trabalho?
  • Os maiores desafios estão relacionados com a integração dos dados gerados por diferentes fontes de insumo e o planejamento de uma interface amigável que permita ao pesquisador obter resultados para diferentes parâmetros, diferentes tipos de atividade (e.g., escrita, leitura, tradução) e diferentes áreas de interesse (e.g., um única palavra, uma sentença, duas linhas de texto).

• 4. Quais os conhecimentos básicos (teorias) que devemos ter para se implementar este projeto?
  • Em se tratando das áreas de aplicação da ferramenta, serão necessários conhecimentos da teoria da relação olho-mente (JUST; CARPENTER, 1980), dos estudos processuais da tradução (cf. ALVES, 2003) e dos estudos sobre expertise e desempenho experto (cf. ERICSSON et al. 2006). Em se tratando do desenvolvimento da ferramenta, serão necessários conhecimentos sobre os princípios de eye tracking (e.g., o que é uma fixação e o que é uma sacada), de key logging (e.g., o timestamp associado a cada tecla ou clique de mouse) e de reconhecimento de voz (e.g., como converter sons em texto escrito).
  • ALVES, F. Tradução, cognição e contextualização: triangulando a interface processo-produto no desempenho de tradutores novatos. DELTA, São Paulo, v.19, p. 71- 108, 2003.
  • ERICSSON, K. A.; CHARNESS, N.; FELTOVICH, P. J.; HOFFMAN, R. R. (Ed). The Cambridge Handbook of Expertise and Expert Performance. Cambridge: Cambridge University Press, 2006.
  • JUST, M.; CARPENTER, P. A theory of reading: From eye fixations to comprehension. Psychological Review, v. 87, p. 329-354, 1980.

• 5. Quais soluções similares existem no mercado?
  • Existem no mercado soluções que isoladamente capturam um ou dois dos insumos/estímulos, mas que são bastante limitadas quanto à forma de exploração dos dados. Por exemplo, há soluções desenvolvidas pelos próprios fabricantes de eye trackers, como a Tobii (https://www.tobiipro.com) e a Eyelink (https://www.sr-research.com/solutions/), as quais apenas analisam dados de movimentos oculares. Há também soluções desenvolvidas apenas para key logging, como o Translog 2006 (http://www.translog.dk) e o Inputlog (http://www.inputlog.net). Há ainda uma solução que minimamente integra dados de eye tracking e keylogging, o Translog-II (https://sites.google.com/site/centretranslationinnovation/translog-ii). Igualmente, há soluções de reconhecimento de voz, como Cloud Speech-to-Text (https://cloud.google.com/speech-to-text/) e Watson Speech to Text (https://www.ibm.com/watson/services/speech-to-text/). Por fim, há soluções de interpretação automática, ou seja, "tradução oral" de uma língua para a outra, como o Lexifone (https://www.crunchbase.com/organization/lexifone). Não obstante, como já apontado, não há integração entre esses módulos.

Why

• 1. Porque é interessante desenvolver este projeto?
  • É relevante desenvolver este projeto porque ele visa atender a uma demanda atual de pesquisadores que lidam com a indústria da língua, uma indústria que busca cada vez mais fornecer, em curto prazo de tempo, serviços com baixo custo e alta qualidade. No entanto, como a indústria vem se desenvolvendo de forma mais rápida que as habilidades dos pesquisadores de áreas como psicolinguística e processo tradutório em usar a tecnologia para a análise das novas formas de se ler, escrever, traduzir e interpretar, é fundamental uma maior integração entre esses pesquisadores e desenvolvedores de sistemas. Ademais, o desenvolvimento de uma ferramenta com interface amigável e integração de diferentes insumos/estímulos e tecnologias retira do pesquisador a necessidade de se especializar na área-meio (e.g., aprender programação), podendo, então, dedicar-se à sua área-fim (e.g., investigar, analisar).

• 2. No seu projeto, precisará optar por algumas tecnologias, usar alguns hardwares e conversar com outros sistemas, atuais ou não?
  • Será, sim, preciso optar por algumas tecnologias, hardwares e sistemas. Existe, no mercado, um número considerável de opções de eye trackers (hardwares com suas respectivas APIs) e softwares de reconhecimento de voz (geralmente integrados como API). Para reduzir custo, inicialmente a proposta inicial é de usar um eye tracker da marca Tobii (TX 60), já disponível no Instituto de Letras e Linguística da Universidade Federal de Uberlândia; a empresa disponibiliza uma API para integração do hardware a novos sistemas. Além disso, optou-se, para reconhecimento de voz, por usar o Cloud Speech-to-Text, da Google. Também será necessária a integração a outros sistemas, como um protocolo para ativação online da aplicação e e-mail para envio de relatórios de erros.

• 3. Com relação às tecnologias, cite no mínimo 3 e explique a função de cada uma no seu projeto.
  • Haverá utilização de tecnologia de reconhecimento de voz a fim de viabilizar a investigação de processos subjacentes ao ato de ditar texto, em vez de digitá-los manualmente.
  • Haverá utilização de tecnologia de captura dos movimentos oculares (eye tracking) a fim de viabilizar a investigação de como um participante processa um texto ou imagem em sua leitura. Nessa captura, o principal foco é entender a fixação do participante, considerando que mais fixações, fixações mais longas ou movimentos recursivos no olhar implicam dificuldade de processamento de uma informação.
  • Haverá utilização de tecnologia de captura de acionamentos de teclado e mouse (key logging) a fim de viabilizar a investigação de como um participante produz um texto, traduz um texto ou pós-edita um texto. Nessa captura, serão consideradas as teclas de produção e de eliminação de textos, em conjunto com os seus respectivos tempos de execução e pausas entre o acionamento de uma e outra.

• 4. Com relação ao hardware, cite no mínimo 3 e explique a função de cada um no seu projeto.
  • Eye tracker da marca Tobii: utilizado para captura os movimentos oculares do usuário por meio de infravermelho e mapeamento das coordenadas do olhar na tela do computador. Para o projeto, esse eye tracker será fundamental para gerar dados sobre fixação, ou seja, quantas vezes e por quanto tempo uma pessoa concentra o olhar em um ponto, assumindo-se que, quanto mais tempo e/ou quanto mais vezes olha para o mesmo ponto, maior é sua dificuldade de processamento de alguma informação.
  • Teclado: utilizado para a entrada de dados digitados pelos usuários do sistema.
  • Mouse: utilizado para a entrada de dados pelos usuários do sistema.
  • Tela: utilizado para a transmissão das informações referentes ao teste. Trata-se de um mecanismo de saída de dados, ao mesmo tempo que, para a tecnologia de eye tracking, contribui como entrada de dados para o mapeamento da coordenada do ponto em que o usuário está fixando em determinado momento.
  • Sensor de voz: utilizado para captura de voz do colaborador, dispositivo de entrada de dados.
  • Placa de vídeo dedicada: utilizada para o processamento rápido dos dados de rastreamento ocular. Depende da tela para a captura correta dos dados de rastreamento ocular.
  • Disco rígido: utilizado para armazenamento dos arquivos temporários e do arquivo final. Importante que seja SSD para agilizar o processamento.

• 5. Com relação aos sistemas, cite no mínimo 3 e explique a função de cada um no seu projeto.
  • API do Google para reconhecimento de voz (i.e., Cloud Speech-to-Text): para viabilizar a realização de tarefas em que o participante apenas dita o texto desejado, em vez de digitá-lo manualmente. Trata-se de uma inovação em relação às aplicações já existentes no mercado para fins de pesquisas psicolinguísticas e processuais.
  • Email: comunicação por meio de protocolo para envio de relatórios de erros do sistema para os desenvolvedores, a fim de se compreender os pontos de melhoria e correção de bugs.
  • Tobii API: para viabilizar a captura de dados do olhar a partir do eye tracker da marca Tobii, selecionado para o desenvolvimento inicial deste projeto.
  • Protocolo de ativação online: para viabilizar a ativação do produto pelo usuário
  • Sistema operacional Windows: será necessário acionar as configurações do Windows pela própria aplicação a fim de configurar o reconhecimento de voz (e.g., ruídos do microfone, impedância) e o vídeo (e.g., brilho e Herz, que influenciam na captura do eye tracker).

Who

• 1. Quem pode se beneficiar deste projeto?
  • Os beneficiários diretos deste projeto são pesquisadores/professores, desenvolvedores de aplicações/sites e publicitários. A ideia é entender como o indivíduo processa informações, o que é relevante para pesquisadores/professores, do ponto de vista acadêmico; para desenvolvedores de aplicações e sites, do ponto de vista da usabilidade; para desenvolvedores de sites e publicitários, do ponto de vista do marketing (e.g., o indivíduo olha para uma propaganda se posicionada no lugar x?).

• 2. Quem poderá operar o sistema?
  • Os beneficiários diretos do projeto (e.g., pesquisadores/professores, desenvolvedores e publicitários) poderão operar o sistema como Administradores, enquanto os indivíduos participantes de sua pesquisa operarão o sistema de forma restrita, como Usuários.

• 3. Quem deverá participar do desenvolvimento do sistema?
  • Os principais participantes do desenvolvimento do sistema serão os desenvolvedores e os beneficiários diretos do projeto, a fim de entender as reais necessidades da aplicação e conferir se a forma de processamento dos dados e suas respectivas saídas de resultado estão corretas do ponto de vista teórico. Esses mesmos participantes também poderão atuar como Usuários quando necessário testar alguma parte do sistema ou mesmo refletir sobre a concepção de alguma funcionalidade. Os desenvolvedores terão os seguintes perfis: programador, gerente de projeto, webdesigner, analista de negócio, analista de infraestrutura e coordenador de segurança e redes,

Where

• 1. Por onde (hardware ou sistemas), os dados serão inseridos?
  • Serão utilizados os seguintes periféricos/hardwares para entrada de dados: teclado, mouse, microfone e eye tracker.
  • Serão utilizados os seguintes sistemas para entrada de dados: Tobii API (captura de dados de movimento ocular); Google Cloud to Speech (captura de dados de reconhecimento de voz); e protocolo de ativação de licença.

• 2. Onde (hardware ou sistemas), os dados serão externalizados?
  • Os dados serão externalizados por meio dos seguintes periféricos: HD interno e HD externo, que gravarão os projetos, os testes, os vídeos, as imagens, os gráficos, os relatórios, os estímulos, os vídeos e os dados processados. Como as coletas costumam resultar em dados muito grandes, não haverá opção por clouding.
  • Alguns dados serão externalizados por meio dos seguintes sistemas: protocolo de email; e protocolo de ativação de licença.

• 3. Onde (em que dispositivos ou ambientes) esta aplicação poderá ser usada?
  • A aplicação poderá ser usada em computadores pessoais e com as configurações mínimas determinadas pelos equipamentos de rastreamento ocular e reconhecimento de voz (Intel Quad Core i5 3.0 GHz, 16 GB RAM, dedicated Nvidia card, 1920 x 1080 screen resolution, Windows 10). O desenvolvimento será exclusivo para Windows.

• 4. Onde os dados serão armazenados?
  • Os dados serão armazenados na própria máquina do pesquisador ou em um HD externo, uma vez que são muito grandes. Foram concebidos, inicialmente, os seguintes depósitos: Projeto, Estímulo, Teste, Dados Brutos, Recursos & Configurações, Dados Pré-Processados, Dados Processados, Imagens, Gráficos, Vídeos, Leitura, Escrita, Tradução, Interface, Participante, Licença, Manual, Erro.

• 5. Onde o software deverá ser hospedado?
  • O software será um executável e disponibilizado em uma página da internet, de preferência em uma página da própria Universidade Federal de Uberlândia.

When

• 1. Em quanto tempo (em semanas) pretende desenvolver o sistema?
  • O software será desenvolvido no período da disciplina, no primeiro semestre de 2019, o correspondente a cerca de 18 semanas (4,5 meses).

• 2. Quais serão as fases e em quanto tempo cada uma?
  • Fase 1 - Identificação da Demanda: trabalho para identificação precisa das reais necessidades dos potenciais usuários. Tempo estimado de 1 semana.
  • Fase 2 - Brainstorming: reunião da equipe para levantar ideias acerca da melhor forma e sequência de execução do projeto, incluindo requisitos funcionais e não funcionais. Tempo estimado de 1 semana.
  • Fase 3 - Planejamento: verificação da viabilidade de seu desenvolvimento, considerando o prazo disponível; (re)definição do escopo do projeto e definição da sequência das atividades a serem realizadas, considerando as tecnologias levantadas nos requisitos do brainstorming; definição do cronograma e do orçamento do projeto; definição dos papéis/funções dos envolvidos no processo, juntamente com métricas de desempenho. Tempo estimado de 2 semanas.
  • Fase 4a - Execução: levantamento/reunião dos recursos e das pessoas necessárias; codificação do software seguindo a sequência, os requisitos funcionais e os requisitos não funcionais definidos no planejamento. Tempo estimado de 10 semanas.
  • Fase 5a - Teste: após finalização da primeira versão completa do sistema, todas as suas funcionalidades serão testadas. Caso haja algum erro, o sistema volta à fase de execução para correções; caso esteja tudo funcionando devidamente, o projeto passa para a fase de encerramento. Tempo estimado de 2 semanas.
  • Fase 4b/5b - Monitoramento e Controle: concomitantemente com a execução, adoção de procedimentos e mecanismos para monitorar e controlar os trabalhos a fim de que seja conduzidos conforme o planejamento; atuação corretiva em relação a eventuais problemas durante o desenvolvimento; medição do desempenho seguindo métricas previamente definidas. Tempo estimado de 12 semanas, podendo se estender caso haja a necessidade de correção de algum erro na fase de teste.
  • Fase 6 - Encerramento: após realização de todos os testes e confirmação de que o sistema está operante, é feita sua entrega ao cliente. Tempo estimado de 1 semana.
  • Fase 7 - Implementação: oferecimento de um treinamento aos primeiros clientes (Administradores) do sistema. Tempo estimado de 1 semana, podendo se estender caso esses clientes necessitem de um treinamento mais abrangente.

• 3. Qual o tempo de resposta do dispositivo ou do sistema, ou seja, quanto tempo acha razoável esperar por uma informação?
  • A aplicação deverá processar os testes enquanto o participante realiza o experimento; no entanto, como o tempo de gravação pode ser muito grande e os arquivos costumam ser pesados, espera-se um tempo de 5 a 10 minutos para que os dados de todo um projeto (i.e., conjunto de testes) sejam devidamente concluídos e gravados no disco rígido selecionado pelo usuário. Esse tempo, contudo, pode sofrer variações dependendo do disco rígido (e.g., SSD x HD), do processador, do tempo de execução do experimento e dos insumos/estímulos associados a cada teste.

• 4. Se tiver investimento, quanto tempo acha razoável para pagar o financiamento?
  • O investimento será captado por meio de editais de agências de fomento, que não necessariamente exigem um retorno financeiro da aplicação. No entanto, em se verificando o seu potencial, a aplicação poderá ser vendida para uma empresa que busque capitalizar sobre as suas potencialidades.

How

• 01. Como será dividido o desenvolvimento do sistema?
  • Haverá quatro grandes etapas.
  • A primeira etapa corresponderá ao desenvolvimento da interface (aqui não necessariamente entendida como a parte gráfica, mas sim como a parte referente aos requisitos funcionais) para o pesquisador/administrador (sobretudo no que tange à escolha de tarefas e de recursos a serem utilizados para a captura das tarefas).
  • A segunda etapa corresponderá ao desenvolvimento da interface (i.e., requisitos funcionais) para o participante da pesquisa/usuário (principalmente no que tange à forma como ele poderá acessar os testes).
  • A terceira etapa corresponderá ao desenvolvimento dos algoritmos para a captura de dados (e.g., o que constitui uma fixação, quais as coordenadas da tela em que há movimento ocular).
  • A quarta etapa corresponderá ao desenvolvimento dos algoritmos para a geração de resultados (especialmente no que diz respeito à integração entre os dados e à forma como esses dados serão apresentados).
  • A ideia é que, ao cabo dessas quatro etapas, esteja finalizada uma aplicação para ser baixada e instalada pelo pesquisador.

• 02. Como será feita a entrada de dados?
  • A entrada de dados ocorrerá através de teclado e mouse (para key logging), eye tracker (para rastreamento ocular) e microfone (para reconhecimento de voz).

• 03. Como será feita a saída de dados?
  • Num momento, os dados poderão ser visualizados na tela caso seja desejo do usuário acompanhar um replay em áudio e vídeo da tarefa gravada, juntamente com informações sobre o rastreamento ocular (e.g., fixações, dilatação de pupila), o keylogging e o reconhecimento de voz (transformados em texto).
  • Noutro momento, os dados de eye tracking e key logging poderão ser exportados como planilha .csv para fins de processamento em outros softwares (e.g., R, SPSS).
  • Noutro momento, os dados poderão ser visualizados como heatmap e gazeplot. O heatmap é uma representação do tipo ondas de calor, de forma que as zonas mais vermelhas são as mais visualizadas, enquanto as zonas mais verdes são as menos visualizadas. O gazeplot é uma representação, em imagem, da sequência de fixações de indivíduo.
  • Noutro momento, os dados poderão ser visualizados como uma representação linear da produção textual. Dessa forma, os dados capturados do teclado, do mouse e do reconhecimento de voz serão processados, juntamente com seus respectivos timestamps, para representar a geração, alteração ou eliminação de textos durante a execução de uma tarefa.
  • Noutro momento, os dados estatísticos poderão ser visualizados como gráficos na própria aplicação.
  • Noutro momento, o administrador poderá selecionar funcionalidades que permitem a análise dos dados de acordo com o tipo de tarefa: leitura, escrita ou tradução.
  • Além disso, haverá saída de dados de erro por email e de dados de ativação da licença de forma online.

• 04. RF01: Selecionar interface.
  • Seleção entre duas opções de interface: Administrador/pesquisador ou Usuário/participante da pesquisa. A interface do Administrador é aquela que permitirá a elaboração e edição de projetos e testes, bem como a obtenção de relatórios de resultados. A interface do Usuário é aquela que permitirá a realização do teste, tendo como únicas configurações possíveis aquelas referentes aos padrões do teclado, à calibragem do olhar e à calibragem da voz. O processo lerá o depósito "Interface".

• 05. RF02: Criar projeto.
  • Utilizado no caso de projeto novo. O administrador poderá descrever o projeto e determinar os tipos e a ordem dos testes, os insumos/estímulos a serem utilizados (e.g., um texto, uma imagem, uma página da internet), os recursos de captura de dados a serem utilizados, os tipos de relatório a serem produzidos, onde os resultados serão salvos e de que forma deverão ser salvos (por tipo de projeto, por tipo de usuário, por tipo de recursos utilizados). O processo escreverá no depósito "Projeto" e lerá do depósito "Teste". Vale sublinhar que um projeto contém necessariamente pelo menos um teste. Além disso, nesse momento, o teste em si não é configurado; apenas suas configurações gerais (ordem de apresentação e tipo).

• 06. RF03: Abrir projeto.
  • No caso de projeto criado anteriormente. O administrador poderá abrir para visualizar as configurações dos testes e dos recursos. O processo lerá dos depósitos "Projeto" e "Teste"

• 07. RF04: Editar projeto.
  • No caso de projeto criado anteriormente. O administrador poderá editar as configurações gerais dos tipos e ordens dos testes e dos recursos, podendo fazer tudo que faria quando da criação de um projeto novo (e.g., determinar estímulos e recursos utilizados, configurar local de salvamento dos dados). Essa abertura disponibilizará as informações e configurações do projeto atual, bem como os recursos necessários para fazer alterações/edições. Essa abertura também permitirá que se altere a ordem em que os projetos serão apresentados ao participante, havendo inclusive a possibilidade de apresentação aleatória. O processo lerá e escreverá nos depósitos "Projeto" e "Teste". Vale sublinhar que, nesse momento, o teste em si não é configurado; apenas suas configurações gerais (ordem de apresentação e tipo). Ademais, o projeto só poderá ser alterado se não houver sido realizada coleta antes; nesse caso, o sistema emitirá um alerta e o pesquisador deverá confirmar se realmente deseja alterá-lo, perdendo todos os dados coletados.

• 08. RF05: Excluir projeto.
  • O administrador poderá excluir projetos, quando achar necessário. Nesse caso, o processo lerá e escreverá nos depósitos "Projeto" e "Teste", o que acarretará a eliminação de dados correspondentes nesses depósitos e em outros (e.g., "Dados Brutos"). Todavia, o projeto só poderá ser alterado se não houver sido realizada coleta antes; nesse caso, o sistema emitirá um alerta e o pesquisador deverá confirmar se realmente deseja alterá-lo, perdendo todos os dados coletados.

• 09. RF06: Exportar projeto.
  • O administrador poderá exportar projetos para outros dispositivos de gravação, como HD externo ou até mesmo nuvem e pendrive (caso seja um projeto pequeno e sem dados coletados). Para exportar, poderá selecionar todo o conteúdo do projeto (incluindo os dados brutos), apenas os dados relativos a alguns participantes ou apenas um ou outro teste. Nesse caso, haverá leitura pelo menos dos depósitos "Projeto", "Teste", "Participantes" e "Dados Brutos".

• 10. RF07: Importar projeto.
  • O administrador poderá importar projetos salvos anteriormente em outra máquina e exportados. Para tal, será preciso acessar um arquivo .ye. Nesse caso, haverá escrita pelo menos nos depósitos "Projeto", "Teste" e "Dados Brutos".

• 11. RF08: Salvar projeto.
  • O administrador poderá salvar, em um arquivo de extensão .ye, seu projeto após configurá-lo, configurar algum teste ou realizar um experimento. Nesse caso, haverá escrita pelo menos em um desses depósitos: "Projeto", "Teste" e "Dados Brutos".

• 12. RF09: Criar teste.
  • O administrador poderá, dentro de um projeto, criar um ou mais testes, considerando os estímulos/insumos desejados, inclusive no que diz respeito à forma como aparecerão na tela e o tempo demandado até que surjam para o participante. Nesse caso, haverá escrita pelo menos nos depósitos "Projeto" e "Teste".

• 13. RF10: Abrir teste.
  • O administrador poderá abrir e visualizar um teste já criado por ele próprio ou importado. Nesse caso, haverá leitura do depósito "Teste".

• 14. RF11: Excluir teste.
  • O administrador poderá excluir teste criado ou importado para sua máquina. Todavia, o teste só poderá ser excluído se não houver sido realizada coleta antes; em caso de dados já coletados, o sistema emitirá um alerta e o pesquisador deverá confirmar se realmente deseja alterá-lo, perdendo todos os dados coletados. Nesse caso, o processo lerá e escreverá nos depósitos "Projeto" e "Teste", o que acarretará a eliminação de dados correspondentes nesses depósitos e em outros (e.g., "Dados Brutos").

• 15. RF12: Selecionar tipo de teste.
  • O administrador, quando da criação ou edição de um teste, poderá selecionar, dentre uma lista, o tipo de teste que deseja incluir no projeto. Por exemplo, haverá teste de escrita, teste de leitura e teste de tradução. Em se tratando do teste de tradução, o tipo de deste já predetermina que a tela será dividida em duas partes (superior/inferior ou direita/esquerda), de modo que numa parte fica o texto-fonte e na outra seja inserido o texto-alvo. Nesse caso, o processo lerá e escreverá pelo menos nos depósitos "Projeto" e "Teste".

• 16. RF13: Editar teste.
  • O administrador poderá fazer alterações em um teste já criado ou importado para um projeto. Essa edição envolverá mudanças nos recursos e insumos/estímulos. Nesse caso, o processo lerá e escreverá pelo menos nos depósitos "Projeto" e "Teste". Todavia, o teste só poderá ser alterado se não houver sido realizada coleta antes; nesse caso, o sistema emitirá um alerta e o pesquisador deverá confirmar se realmente deseja alterá-lo, perdendo todos os dados coletados.

• 17. RF14: Importar estímulo.
  • O administrador poderá importar estímulos/insumos (e.g., um vídeo, uma imagem, um texto) para utilizar em um teste ou projeto. Nesse caso, o processo escreverá pelo menos nos depósitos "Estímulo", "Projeto" e "Teste". Os insumos, antes de importados, deverão estar em um disco local, externo ou nuvem.

• 18. RF15: Exportar teste.
  • O administrador poderá Exportar teste para dispositivos de gravação portáteis como HDs externos e pendrives, além de acessar a nuvem, caso o teste seja de tamanho pequeno. Para a exportação, será possível selecionar que dados do teste serão exportados e, inclusive, se algum dado já coletado será exportado. Nesse caso, o processo lerá pelo menos os depósitos "Estímulo" e "Teste".

• 19. RF16: Importar teste.
  • O administrador poderá importar testes criados em outras máquinas a fim de utilizá-los dentro de um projeto. Também será possível importar o teste de um projeto para outro dentro da própria máquina. O pesquisador deverá selecionar que dados do teste serão importados e, inclusive, definir se algum dado já coletado será importado. Nesse caso, o processo escreverá pelo menos no depósito "Teste" e "Projeto".

• 20. RF17: Ordenar teste.
  • Caso se tenha aberto um projeto ou esteja criando um novo projeto com múltiplos testes, o administrador poderá definir a ordem em que os testes serão apresentados ao participante, podendo, inclusive, estabelecer que será de forma aleatória. Nesse caso, o processo lerá do depósito Teste e escreverá no depósito "Projeto".

• 21. RF18: Simular teste.
  • O administrador poderá simular os testes para verificar seu funcionamento antes da sua aplicação real em um experimento. Nesse caso, só haverá leitura do repositório "Teste".

• 22. RF19: Realizar experimento.
  • O administrador dará início à coleta de dados, seguindo a sequência previamente selecionada (ou de forma aleatória se selecionada) quando da sua criação ou, do contrário, mediante seleção de testes específicos dentro do projeto.

• 23. RF20: Iniciar teste.
  • Após a configuração dos testes do projeto, ficará disponível um botão de iniciar para ser utilizado na interface do administrador e acionar a interface do usuário. Esse processo lerá do depósito "Teste" e escreverá no depósito "Dados Brutos".

• 24. RF21: Executar teste.
  • Após o início de um teste pelo administrador, o teste será executado pelo usuário. Esse processo lerá do depósito "Teste" e escreverá no depósito "Dados Brutos".

• 25. RF22: Concluir teste.
  • Após o usuário terminar o teste, um botão de finalização se apresentará, dando conclusão ao teste realizado. A finalização poderá ser executada mediante clique nesse botão ou ativação de alguma tecla ou combinação de teclas predefinida pelo pesquisador. Por padrão, o acionamento da tecla "F10" executará essa ação. A conclusão do teste poderá implicar fim de todo o experimento ou início do próximo teste. Esse processo lerá do depósito "Teste" e escreverá no depósito "Dados Brutos". Também será lido e escrito o depósito "Projeto".

• 26. RF23: Salvar teste.
  • Por default, o sistema armazena temporariamente os dados de um teste em uma pasta temporária. No entanto, o pesquisador deverá ativar a função "Salvar" para explicitar que de fato concluiu o teste, não desejando reaplicá-lo, e especificar onde e como gostaria de salvar os dados. Esse processo lerá do depósito "Teste" e escreverá no depósito "Dados Brutos". Também será lido e escrito o depósito "Projeto".

• 27. RF24: Ativar recursos.
  • O administrador poderá ativar os recursos de hardware a serem utilizados no teste: teclado e/ou microfone para reconhecimento de voz e/ou rastreador ocular. Nesse caso, haverá leitura e escrita no depósito "Recursos e Configurações".

• 28. RF25: Calibrar eyetracker.
  • Caso tenha ativado esse recurso, o administrador ou o usuário poderá calibrar o sensor óptico. Na ocasião, será chamada a API do rastreador. Em um primeiro momento, será implementada apenas para rastreadores Tobii (https://developer.tobii.com/eyex-engine-api-glance/). Nesse caso, haverá leitura e escrita no depósito "Recursos e Configurações".

• 29. RF26: Configurar teclado.
  • Caso tenha ativado esse recurso, o administrador poderá calibrar o teclado com a participação do colaborador que realizará o teste. Por padrão, o teclado utilizado será internacional, mas será possível selecionar outros, como ABNT e ABNT2. Nesse caso, haverá leitura e escrita no depósito "Recursos e Configurações".

• 30. RF27: Configurar reconhecimento de voz.
  • Caso tenha ativado esse recurso, administrador poderá calibrar o sensor de voz com a participação do colaborador que realizará o teste. Na ocasião, será selecionada a fonte de áudio e será chamado um módulo ou API de reconhecimento de voz. Será implementado a API do Google Cloud Speech-to-Text.(https://cloud.google.com/speech-to-text/). Nesse caso, haverá leitura e escrita no depósito "Recursos e Configurações".

• 31. RF28: Capturar dados de eye tracker.
  • Caso tenha sido ativado esse recurso, o teste rodará e, simultaneamente, serão capturados dados de movimento ocular. Na sua forma bruta, esses dados basicamente envolverão, a cada 60 ms, medidas da dilatação da pupila e mapeamento das coordenadas da tela em que o participante fixa o olha, juntamente com os respectivos tempos em que se dá essa fixação. Nesse caso, haverá leitura do depósito "Teste" e escrita no depósito "Dados Brutos".

• 32. RF29: Capturar dados de teclado.
  • Caso tenha sido ativado esse recurso, o teste rodará e, simultaneamente, serão capturados dados do teclado. Na sua forma bruta, esses dados basicamente envolverão as teclas acionadas, juntamente com seus respectivos timestamps e coordenadas na tela. Nesse caso, haverá leitura do depósito "Teste" e escrita no depósito "Dados Brutos".

• 33. RF30: Capturar dados de voz.
  • Caso tenha sido ativado esse recurso, o teste rodará e, simultaneamente, serão capturados dados de voz. Na sua forma bruta, esses dados basicamente envolverão o áudio da fala do participante e a sua respectiva transformação em texto juntamente com o respectivo timestamp e coordenadas na tela. Nesse caso, haverá leitura do depósito "Teste" e escrita no depósito "Dados Brutos".

• 34. RF31: Capturar dados de mouse.
  • Caso tenha sido ativado esse recurso, o teste rodará e, simultaneamente, serão capturados dados de mouse. Na sua forma bruta, esses dados basicamente envolverão as coordenadas de onde o mouse é ativado em conjunto com o seus respectivos timestamps. Nesse caso, haverá leitura do depósito "Teste" e escrita no depósito "Dados Brutos".

• 35. RF32: Capturar timestamps.
  • Para todos os demais processos de captura, o timestamp será gravado a fim de correlação com os eventos ocorridos e geração de redundância. Nesse caso, haverá escrita no depósito "Dados Brutos".

• 36. RF33: Configurar áreas de interesse.
  • O administrador, mediante uso de ferramentas de círculo, retângulo ou livre, poderá selecionar a área específica da tela que será analisada para determinado teste ou insumo. Por padrão, estará definida toda a tela. Também estará disponível a opção de usar a janela de um software como área de interesse. Nesse caso, haverá leitura do depósito "Dados Brutos" e escrita no depósito "Dados Pré-Processados".

• 37. RF34: Definir filtro de fixação.
  • O administrador deverá selecionar o filtro que determinará que dados de fato correspondem a uma fixação -- como o olho nunca é estático, uma fixação é constituída por microfixações que desviam uma medida x em relação a dado ponto central dentro de um período y de tempo. Existem diversas formas de se calcular fixações, o que interfere nos resultados. Nesse caso, haverá leitura do depósito "Dados Brutos" e escrita no depósito "Dados Pré-Processados".

• 38. RF35: Selecionar dados para análise.
  • O administrador poderá selecionar que dados deseja analisar: um único teste ou x testes dentro de um projeto, um único participante ou x participantes, determinado intervalo de tempo dentro de cada teste. Em alguns casos, os dados iniciais e finais costumam ser descartados pois os primeiros refletem acomodação à tarefa e os últimos podem refletir fadiga. Nesse caso, haverá leitura do depósito "Dados Brutos" e escrita no depósito "Dados Pré-Processados".

• 39. RF36: Pré-processar dados.
  • Considerando a definição de filtro de fixação, a seleção dos dados para análise e as configurações das áreas de interesse, os dados brutos serão pré-processados, para que se faça as devidas correspondências desejadas pelo pesquisador. Nesse caso, haverá leitura do depósito "Dados Brutos" e escrita no depósito "Dados Pré-Processados".

• 40. RF37: Gerar relatório em planilha.
  • Após a conclusão do teste, o administrador poderá gerar um relatório sobre o teste a partir dos dados pré-processados. Esse relatório será gerado em formado .csv. Para a geração do relatório, o administrador selecionará as variáveis que deseja incluir (e.g., sexo, faixa etária), o teste ou os testes desejados, os tipos de output (e.g., raw, média, mediana, moda, somatório, min-máx), bem como as áreas de interesse. Também poderá selecionar como serão tratados os dados com "zero". Caso o recurso de eye tracking esteja ativado, os dados "raw" serão acompanhados das respectivas coordenadas na tela. Nesse caso, haverá leitura do depósito "Dados Pré-Processados" e escrita do depósito "Dados Processados".

• 41. RF38: Exportar planilha.
  • Após a geração do relatório em planilha, o administrador poderá exportar planilhas do projeto em formato .csv para uso em outras aplicações (e.g., R, SPSS). Os dados contidos serão os mesmos visualizados na tela, podendo também haver adição de informações sobre o nome do teste de origem. Nesse caso, haverá leitura do depósito "Dados Processados".

• 42. RF39: Gerar heatmap.
  • Caso seja utilizado o recurso de eye tracking, será possível gerar um heatmap, que consiste em uma representação gráfica das áreas que receberam mais ou menos fixações. Considerando a duração das fixações ou o número de fixações, o heatmap representará: em tonalidades mais vermelhas, as áreas que receberam mais fixações; em tonalidades amarelas/alaranjadas, as áreas que receberam fixações intermediárias; em tonalidades verdes, as áreas que receberam menos fixações; em transparente, as áreas que receberam poucas ou quase nenhuma fixação. Também será possível escolher que essa representação se dê como um "raio-x", com as áreas mais pretas recebendo nenhuma fixação e as áreas do cinza para o transparente recebendo cada vez mais fixações. O heatmap poderá sinalizar o desempenho de um único participante ou de vários, mas nunca poderá ser uma conjugação de testes diferentes. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Imagens".

• 43. RF40: Exportar heatmap.
  • Após a geração do heatmap, o administrador poderá exportá-lo em formato de imagem (.jpg, .png, .tiff) ou mesmo em formato .pdf. Os dados contidos serão os mesmos visualizados na tela, podendo também haver adição de informações sobre o nome do teste de origem e a identificação do participante. Nesse caso, haverá leitura do depósito "Dados Processados".

• 44. RF41: Gerar gazeplot.
  • Caso seja utilizado o recurso de eye tracking, será possível gerar um gazeplot, que consiste em uma representação gráfica da sequência de fixações do participante. As fixações serão representadas por círculos numerados de acordo com suas respectivas sequências, sendo que os círculos maiores representam maior tempo de fixação ou maior número de fixações. O heatmap poderá sinalizar o desempenho de um único participante ou de vários, mas nunca poderá ser uma conjugação de testes diferentes. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Imagens".

• 45. RF42: Exportar gazeplot.
  • Após a geração do gazeplot, o administrador poderá exportá-lo em formato de imagem (.jpg, .png, .tiff) ou mesmo em formato .pdf. Os dados contidos serão os mesmos visualizados na tela, podendo também haver adição de informações sobre o nome do teste de origem e a identificação do participante. Nesse caso, haverá leitura do depósito "Dados Processados".

• 46. RF43: Gerar gráficos.
  • A partir dos dados processados para o relatório em planilha, será possível conversão das estatísticas em gráficos. Assim como feito para os relatórios, o administrador selecionará as variáveis que deseja incluir (e.g., participantes, sexo, faixa etária), o teste ou os testes desejados, os tipos de output (e.g., raw, média, mediana, moda, somatório, min-máx), bem como as áreas de interesse. Também poderá selecionar como serão tratados os dados com "zero". Nesse caso, haverá leitura do depósito "Dados Processados".

• 46. RF44: Exportar gráficos.
  • A partir dos dados processados para o relatório em planilha, será possível conversão das estatísticas em gráficos. Assim como feito para os relatórios, o administrador selecionará as variáveis que deseja incluir (e.g., participantes, sexo, faixa etária), o teste ou os testes desejados, os tipos de output (e.g., raw, média, mediana, moda, somatório, min-máx), bem como as áreas de interesse. Também poderá selecionar como serão tratados os dados com "zero". Nesse caso, haverá leitura do depósito "Dados Processados".

• 48. RF45: Gerar vídeo.
  • O administrador poderá gerar um vídeo de reprodução do teste para fins de visualização, no próprio sistema, de como se deu todo o experimento ou teste de um participante. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Vídeo", em formato raw.

• 49. RF46: Segmentar vídeo.
  • O administrador terá a opção de segmentar os videos dos testes e projetos para capturar apenas as partes de seu interesse (e.g., eliminando os minutos iniciais e os minutos finais de um experimento). Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Vídeo".

• 50. RF47: Exportar vídeo.
  • O administrador poderá exportar os videos inteiros ou segmentos para dispositivos como HDs e pendrives; para tal, poderá selecionar como o vídeo será renderizado e em que formato será gravado (e.g., .mov, .mp4). Nesse caso, haverá leitura dos depósitos "Dados Processados" e "Vídeo".

• 51. RF48: Analisar dados de leitura.
  • O administrador poderá analisar especificamente o que ocorreu em termos de leitura, fazendo associações dos dados processados com categorias de leitura, como skimming, scanning, deep reading. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Análise de leitura".

• 52. RF49: Analisar dados de escrita.
  • O administrador poderá analisar especificamente o que ocorreu em termos de escrita, fazendo associações dos dados processados com categorias de escrita, como escrita de transferência de conhecimento e escrita de transformação do conhecimento. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Análise de escrita".

• 53. RF50: Analisar dados de tradução.
  • O administrador poderá analisar especificamente o que ocorreu em termos de tradução, fazendo associações dos dados processados com categorias de tradução, como processamento em paralelo, processamento sequencial, tradução do zero e pós-edição bilíngue ou monolíngue. Nesse caso, haverá leitura do depósito "Dados Processados" e escrita no depósito "Análise de tradução".

• 54. RF51: Exportar dados de leitura.
  • O administrador poderá exportar, para dispositivos como HDs e pendrives, as análises obtidas especificamente para leitura. Em princípio, essas análises se encontrarão em formato de planilha .csv e imagens de processamento (e.g., .tiff, .png, .jpg, .pdf). Nesse caso, haverá leitura do depósito "Análise de leitura".

• 55. RF52: Exportar dados de escrita.
  • O administrador poderá exportar, para dispositivos como HDs e pendrives, as análises obtidas especificamente para escrita. Em princípio, essas análises se encontrarão em formato de planilha .csv e imagens de processamento (e.g., .tiff, .png, .jpg, .pdf). Nesse caso, haverá leitura do depósito "Análise de leitura".

• 56. RF53: Exportar dados de tradução.
  • O administrador poderá exportar, para dispositivos como HDs e pendrives, as análises obtidas especificamente para escrita. Em princípio, essas análises se encontrarão em formato de planilha .csv e imagens de processamento (e.g., .tiff, .png, .jpg, .pdf). Nesse caso, haverá leitura do depósito "Análise de leitura".

• 57. RF54: Editar informações do participante.
  • O administrador poderá editar as informações dos participantes que já realizaram os testes a fim de corrigir eventuais erros ou adicionar informações importantes observadas ao longo de um experimento. Nesse caso, haverá leitura e escrita do depósito "Participante".

• 58. RF55: Visualizar informações do participante.
  • O administrador poderá visualizar as informações dos participantes que já realizaram os testes. Nesse caso, haverá leitura do depósito "Participante".

• 59. RF56: Coletar informações do participante.
  • Logo após o início do experimento e imediatamente antes da execução do primeiro teste, o usuário deverá entrar com seus dados pessoais (e.g., idade, sexo, uso de óculos, uso de lentes). Esses dados também poderão ser inseridos pelo próprio administrador e serão utilizados mais tarde no relatório e nos demais dados processados, permitindo associar dados entre pessoas de mesma faixa etária, mesmo sexo e que usam ou não óculos/lentes. Nesse caso, haverá leitura e escrita do depósito "Participante", bem como escrita do depósito "Dados Brutos".

• 60. RF57: Salvar informações do participante.
  • O administrador ou o usuário terá de salvar as informações inseridas para confirmar que o preenchimento do cadastro foi finalizado. Nesse caso, haverá leitura e escrita do depósito "Participante", bem como escrita do depósito "Dados Brutos".

• 61. RF58: Gerenciar participantes.
  • O administrador poderá gerenciar (adicionando ou excluindo) os participantes, bem como associar-lhes códigos ou nomes fictícios. Nesse caso, haverá leitura e escrita do depósito "Participante", bem como escrita do depósito "Dados Brutos".

• 62. RF59: Ativar licença.
  • O sistema inicialmente será instalado em versão demo. Mediante um cadastro pelo próprio sistema e processamento online por um protocolo de ativação, será enviada uma licença automática autorizando o uso da versão completa. Nesse caso, haverá leitura e escrita do depósito "Licença".

• 63. RF60: Visualizar manual.
  • O administrador, em caso de dúvidas, poderá recorrer a manual completo sobre as configurações e formas de utilização do sistema. Nesse caso, haverá leitura do depósito "Manual".

• 64. RF61: Gerar relatório de erro.
  • O sistema identificará eventuais erros dentro dos testes, projetos, capturas e experimentos, e o pesquisador poderá gerar um relatório para consultas futuras. Nesse caso, haverá leitura do depósito "Relatório de Erro".

• 65. RF62: Salvar relatório de erro.
  • O usuário poderá salvar o relatório de erros em uma pasta de seu interesse para fins de consulta posterior. Nesse caso, haverá leitura e escrita do depósito "Relatório de Erro".

• 66. RF63: Enviar relatório de erro.
  • Mediante autorização do administrador, o sistema enviará o relatório de erros para a equipe de desenvolvimento por meio de mensagens informativas no software e por e-mail. Nesse caso, haverá leitura do depósito "Relatório de Erro" e utilização da entidade externa "E-mail.

How much

• 1. Quanto custa cada parte do sistema?
  • Folha de pagamento: estimada em R$ 366.525,00 (vide item 4). Prevê-se que 15% será para a parte do Usuário, 10% para a parte de Ativação e Relatório de Erro, 50% para a parte do Administrador e o restante (25%) para interface e web.
  • Taxas: DARE (Documento de Arrecadação de Receitas Estaduais), DARF (Documento de Arrecadação de Receitas Federais), Junta Comercial, Certificado Digital (se necessário), outras taxas por tipo de empresa. Estimadas em R$ 50.000.00, excluindo-se os encargos trabalhistas (já previstos na folha de pagamento como 80% do salário).
  • Contabilidade: um salário-mínimo por mês: estimada em R$ 5.000,00.
  • Equipamentos, aquisição de tecnologia -- e.g., hardwares (e.g., eye tracker), softwares e sistemas (e.g., speech to text) --, locação de espaço físico, hospedagem do site, insumos para o trabalho do dia a dia, dentre outros. Estimados em R$ 50.000,00.
  • Caixa reserva para despesas eventuais estimada em R$ 200.000.00.

• 2. Quanto deverá custar todo o sistema?
  • Para o desenvolvimento do projeto EDET, estima-se o valor R$ 471.525,00, excluindo o caixa reserva, no valor de R$ 200.000,00.

• 3. Quantas pessoas deverão ser usadas (Equipe)?
  • Para o desenvolvimento do projeto EDET, contaremos com 10 programadores e 1 webdesigner, 1 gerente de projeto, 1 analista de negócio, 1 analista de infraestrutura e 1 coordenador de segurança e redes, totalizando 15 profissionais.

• 4. Quanto custa cada profissional?
  • Programador e webdesigner júnior: R$ 2.250,00 x 1,8 x 4,5 x 11 = R$ 200.475,00
  • Gerente de Projeto: R$ 7.000,00 x 1,8 x 4,5 = R$ 56.700,00
  • Analista de Negócio: R$ 4.500,00 x 1,8, 4,5 = R$ 36.450,00
  • Analista de Infraestrutura: R$ 4.000,00 x 1,8 x 4,5 = R$ 32.400,00
  • Coordenador de Segurança/Redes: R$ 5.000,00 x 1,8 x 4,5 = R$ 40.500,00
  • Total: R$ 366.525

• 5. Qual deverá ser o preço de aquisição do seu software para o usuário final (valor de mercado)?
  • Inicialmente, o software terá distribuição gratuita, embora seja necessária a ativação de uma licença, obtida por meio de contato com os desenvolvedores pelo site de hospedagem do aplicativo. Observe-se que essa opção por distribuição gratuita está relacionada com a origem do investimento, editais de agência de fomento. Cabe destacar que se buscará fazer um consórcio de pesquisadores a fim de se chegar a essa quantia, dificilmente contemplada em um único edital ou a um único pesquisador. Caso se opte pela venda da aplicação a uma empresa que poderá capitalizar sobre ela, buscar-se-á atingir cerca de 20% sobre o ponto de equilíbrio: aproximadamente R$ 565.830,00.

DFD

DFD do projeto Eye Do Easy Translog (EDET)

[Clique aqui para acessar o DFD do projeto EDET em formato PDF.]

Canvas

Canvas do projeto Eye Do Easy Translog (EDET)

Pitch

• Clique abaixo para escrever sugestões, críticas ou colaborações para este projeto:
  • http://www.sourceinnovation.com.br/w/index.php?title=Discuss%C3%A3o:EDET&action=edit

DER

[Clique aqui para acessar o DER do projeto EDET em formato PDF.]

Protótipo

• Clique abaixo para acessar o Mock-up do projeto EDET:
  • https://xd.adobe.com/view/3f76ee74-9fec-4533-5a7d-1fbbdea3e3eb-4947/?fullscreen

• Clique aqui para acessar o arquivo disponível para download no Dropbox:
  • https://www.dropbox.com/s/9u4q9828tpx3zls/Mock-up%20Final%20EDET.xd?dl=0