Resultados dos testes de utilizadores

Validac¸ ˜ao

Conte ´udo

5.1 Requisitos cumpridos . . . 47

Neste cap´ıtulo ´e feita a validac¸ ˜ao da plataforma, estando o processo dividido em: n ´umero de requi-sitos concretizados e o resultado dos testes de utilizadores. Apesar da plataforma estar em produc¸ ˜ao, n ˜ao foi poss´ıvel realizar uma an ´alise comparativa do n ´umero de respostas entre o m ´etodo antigo e a plataforma, uma vez que houve uma fraca divulgac¸ ˜ao da mesma pela comunidade estudantil resultando numa an ´alise injusta, face a potencialidade da plataforma como um todo.

5.1 Requisitos cumpridos

Neste processo de validac¸ ˜ao da plataforma pretendia-se confirmar o n ´umero de requisitos cumpridos, justificando a n ˜ao concretizac¸ ˜ao.

Seguindo a ordem presente no cap´ıtulo 2 e os respetivos agrupamentos, obteve-se as Tabelas 5.1, 5.2 - 5.4 e 5.5. A coluna “Estado” tem como poss´ıveis valores: “Implementado” – Quando foi totalmente implementado; “Semi-implementado” – Quando ficou algum aspeto por implementar; “N ˜ao implementado” – Quando nenhum aspeto ficou implementado.

Como vis´ıvel nas Tabelas5.1,5.2-5.4e5.5, o n ´umero de casos de “N ˜ao implementado” e de “Semi-implementado”, s ˜ao m´ınimos quando comparados aos casos de “Implementados”. Deste modo, pode-se considerar um sucesso o processo de validac¸ ˜ao. ´E importante salientar, que alterac¸ ˜oes efetuadas aos requisitos, ou o incumprimento destes, foi devido ou a falta de informac¸ ˜ao publica nos endpoints do F ´enix, ou a falta de informac¸ ˜ao nos endpoints do F ´enix, ou a impossibilidade de juntar a ferramenta ao F ´enix, sendo deste modo motivos n ˜ao relacionados por falta de tempo ou falta de compet ˆencias, mas sim de meios.

Tabela 5.1: Estado dos requisitos do grupo ”Recolha de Informac¸ ˜ao”.

Requisito Estado justificac¸ ˜ao/Observac¸ ˜ao

A plataforma deve recolher a seguinte informac¸ ˜ao acerca dos questionados, quer de forma autom ´atica ou manual:

(a) Tempo investido pelo grupo (ma-nual e obrigat ´orio);

(b) Tempo investido individual (ma-nual e obrigat ´orio);

(c) Curso, unidade curricular e

n ´umero de inscric¸ ˜oes (pre-ferencialmente autom ´atico e obrigat ´orio);

(d) Nota que espera obter no traba-lho realizado face o submetido (manual e obrigat ´orio);

(e) Pontos fortes, pontos a melhorar e coment ´arios/sugest ˜oes (ma-nual e opcional).

Implementado

A linha (c) n ˜ao ficou totalmente auto-matizada, uma vez que a informac¸ ˜ao do n ´umero de inscric¸ ˜oes n ˜ao se encontra acess´ıvel diretamente pelo f ´enix.

A plataforma deve assegurar que os questionados s ˜ao estudantes inscritos na unidade curricular foco do ques-tion ´ario

Implementado

A plataforma deve garantir a anonimi-dade dos questionados:

(a) Na eventualidade de o n ´umero

de respostas permitir a

identificac¸ ˜ao de um inquirido, as respostas devem ser agrupadas.

Implementado

N ˜ao agrupa as respostas, mas im-pede a identificac¸ ˜ao uma vez que n ˜ao ´e guardada qualquer informac¸ ˜ao do aluno

A plataforma deve assinalar quando o n ´umero de respostas n ˜ao garante re-presentatividade (por exemplo, com a f ´ormula da representatividade aplicada pelo conselho pedag ´ogico);

N ˜ao implemen-tado

A f ´ormula da representatividade do conselho pedag ´ogico ´e de um grau de complexidade elevado para o que ´e pretendido para este requisito. No en-tanto, ´e poss´ıvel obter os resultados mesmo quando n ˜ao h ´a representativi-dade.

Tabela 5.2: Estado dos requisitos do grupo ”Gestor de Question ´arios”(Parte 1 de 3).

Requisito Estado justificac¸ ˜ao/Observac¸ ˜ao

Um question ´ario pode estar em um dos tr ˆes estados:

(a) Criado - Estado apresentado ap ´os a criac¸ ˜ao, onde ´e poss´ıvel alterar a data de lanc¸amento; (b) Aberto – Estado que permite que

os utilizadores respondam;

i Este estado fica ativo

quando:

1 No dia da entrega da entrega;

2 Na semana da entrega; 3 Um dia estipulado pelo

delegado; 4 Manualmente.

(c) Fechado – Os utilizadores ficam impossibilitados de responder.

i Este estado fica ativo

quando:

1 Duas semanas ap ´os a abertura;

2 Um dia estipulado pelo delegado;

3 Manualmente.

Implementado

Para al ´em dos estados enumerados, foi adicionado o estado ”Finalizado”, que surge ap ´os o estado ”Fechado”. Este tem significa que o question ´ario est ´a conclu´ıdo e n ˜ao pode ser rea-berto. O per´ıodo de duas semanas pa-receu demasiado e foi reduzido para 7 dias. Alterac¸ ˜ao manual do estado foi removida, sendo apenas poss´ıvel al-terar a data e hora, ficando o sistema respons ´avel de cumprir a l ´ogica e atri-buir automaticamente o estado.

Tabela 5.3: Estado dos requisitos do grupo ”Gestor de Question ´arios”(Parte 2 de 3).

Requisito Estado justificac¸ ˜ao/Observac¸ ˜ao

A plataforma deve conter informac¸ ˜ao acerca da data de encerramento de projetos ou laborat ´orios, preferencial-mente de forma autom ´atica, mas deve permitir que o delegado possa in-serir esta informac¸ ˜ao caso seja ne-cess ´ario. Tamb ´em deve permitir que este introduza informac¸ ˜ao sobre ou-tros poss´ıveis elementos de avaliac¸ ˜ao que devam ser alvo de question ´arios:

(a) No caso de projeto, a data de en-cerramento corresponde `a data de entrega;

(b) No caso de laborat ´orios, a data de fim corresponde ao fim da se-mana onde decorreu a avaliac¸ ˜ao; (c) No caso de outros elementos, a data de fim deve ser uma das poss´ıveis hip ´oteses acima men-cionadas.

Implementado

N ˜ao foi poss´ıvel obter as datas de forma automatizada, uma vez que nem sempre todos os elementos de avaliac¸ ˜ao constam no F ´enix, ficando por esta raz ˜ao manual. Esta alterac¸ ˜ao acaba por ser ben ´efica, uma vez que faz com que o delegado tenha de ve-rificar e inserir as datas discutidas nas reuni ˜oes.

A plataforma deve notificar os alunos alvo do question ´ario sobre a exist ˆencia do mesmo quando no estado aberto por preencher:

(a) Envio de um e-mail a informar que o question ´ario de uma dada UC j ´a se encontra acess´ıvel. Este e-mail pode ser modificado pelo delegado, mas deve garantir que o link para o preenchimento est ´a presente;

(b) Se poss´ıvel, quando iniciada a sess ˜ao no F ´enix, apresentac¸ ˜ao de uma mensagem sobre to-dos os question ´arios que este utilizador ainda n ˜ao preencheu.

Quando n ˜ao houver

ques-tion ´arios para preencher, esta mensagem n ˜ao ser ´a apresen-tada.

Semi-implementado

A linha (b) n ˜ao est ´a implementada por impossibilidade de junc¸ ˜ao com o F ´enix, no entanto, quando aluno acede `a plataforma, ´e listado na p ´agina prin-cipal, os question ´arios por preencher que est ˜ao abertos, assim como os que j ´a respondeu e est ˜ao finalizados. A plataforma notifica os alunos quando o estado do question ´ario ´e aberto, no entanto, o e-mail n ˜ao pode ser edi-tado, sendo um template fixo com o link sempre presente.

Tabela 5.4: Estado dos requisitos do grupo ”Gestor de Question ´arios”(Parte 3 de 3).

Requisito Estado justificac¸ ˜ao/Observac¸ ˜ao

A plataforma deve permitir ao dele-gado o reenvio peri ´odico de um e-mail como est´ımulo ao preenchimento do question ´ario:

(a) Este reenvio deve-se restringir apenas `as pessoas que ainda n ˜ao o preencheram;

(b) O e-mail pode ser livre ou base-ado num formato, mas deve sem-pre conter o question ´ario.

Implementado

Permite o envio manual como reforc¸o, baseado num template n ˜ao edit ´avel. No entanto, o envio autom ´atico foi

desativado por ser incomodativo,

uma vez que caso um aluno tenha v ´arios por responder, recebe m ´ultiplos emails.

A plataforma, quando o estado dos question ´arios ´e aberto, deve mostrar aos utilizadores (delegados, alunos ou docentes) apenas o n ´umero de res-postas, a data de fecho e quanto tempo resta at ´e `a data de fecho.

Tabela 5.5: Estado dos requisitos do grupo ”Processamento de Informac¸ ˜ao”.

Requisito Estado justificac¸ ˜ao/Observac¸ ˜ao

A plataforma, quando o estado do question ´ario ´e fechado, deve realizar um sum ´ario dos dados, mostrando:

(a) N ´umero de respostas face

ao n ´umero de questionados,

m´ınimos, m ´aximos, desvio

padr ˜ao, m ´edia (total e sem 5% dos extremos).

Implementado ^{Faz a an ´alise total e com e sem} extre-mos.

A plataforma deve permitir a extrac¸ ˜ao de toda a informac¸ ˜ao recolhida quando o estado do question ´ario ´e fechado, em formato Excel (.xls)

Implementado ^{Formato final csv, dando mais}

liber-dade para an ´alise.

A plataforma deve notificar todas as partes e permitir a visualizac¸ ˜ao das respostas quando o estado do ques-tion ´ario ´e fechado:

(a) O coordenador deve ter acesso ao resultado de todos os ques-tion ´arios realizados no curso que coordena, organizado por ano e semestre;

(b) O regente e os docentes de-vem ter acesso ao resultado dos question ´arios realizados `as uni-dades curriculares que lecionam; (c) O delegado deve ter acesso ao resultado dos question ´arios do ano que ´e respons ´avel. O dele-gado de ciclo deve ter acesso a todos os resultados no curso, or-ganizado por ano e semestre; (d) O estudante deve ter acesso ao

resultado dos question ´arios que respondeu.

Implementado

Por poder ser necess ´ario visualizar em qualquer instante, ´e poss´ıvel extrair as respostas em qualquer momento, mantendo a anonimidade. O papel de regente foi algo imposs´ıvel de imple-mentar por n ˜ao haver essa informac¸ ˜ao no F ´enix, de modo a automatizar.

5.2 Resultados dos testes de utilizadores

Com intuito de verificar se os requisitos da ferramenta s ˜ao de r ´apida execuc¸ ˜ao grac¸as `a interface, foram feitos testes com utilizadores, sendo cronometrado cada utilizador, assim como contabilizado o n ´umero de cliques que este necessitou para realizar com sucesso cada uma das tarefas.

Como utilizadores foram selecionados alunos do 1º e 2º ciclo, havendo uma distribuic¸ ˜ao aleat ´oria pelo n ´umero de matr´ıculas dos mesmos e o requisito obrigat ´orio que tivessem inscrito a pelo menos uma UC, que n ˜ao fosse a de dissertac¸ ˜ao ou projeto de tese. Os utilizadores n ˜ao tiveram qualquer introduc¸ ˜ao `a ferramenta e n ˜ao podiam colocar perguntas, sendo assim um teste `as cegas, onde os utilizadores t ˆem de explorar at ´e concretizar a tarefa.

As tarefas para os testes de utilizadores foram:

1. No papel de aluno, aceder `as subscric¸ ˜oes e remover a notificac¸ ˜ao da 1ª UC que ´e mostrada na lista.

2. No papel de delegado, criar um elemento de avaliac¸ ˜ao do tipo “projeto” para uma UC em que esteja inscrito, cujo a entrega seja `as 23:59, uma semana antes ao dia do teste com o utilizador. 3. No papel de delegado, enviar um email de reforc¸o para o question ´ario criado anteriormente. 4. No papel de aluno, responder ao question ´ario que foi criado.

5. No papel de delegado, extrair a informac¸ ˜ao do question ´ario anterior.

As Figuras 5.1 e 5.2 s ˜ao a representac¸ ˜ao visual dos resultados obtidos em cada tarefa, sendo menos informac¸ ˜ao da que consta na Tabela 5.6. Os valores dos tempos foram arredondados para valores exatos, sendo que valores terminados em 0,5 ou mais, perfazia para valores acima.

Tabela 5.6: An ´alise dos resultados obtidos aos testes de utilizadores (n ´umero de cliques esperado diz respeito ao

n ´umero de cliques m´ınimos para completar a tarefa).

Num de cliques Durac¸ ˜ao da tarefa (segundos) Max Min M ´edia Moda Esperado Max Min M ´edia Moda

Tarefa 1 16 5 8,53 8 4 106 30 62,09 70

Tarefa 2 32 14 21,44 15 14 152 67 108,10 83

Tarefa 3 25 8 11,91 12 7 77 10 40,03 45

Tarefa 4 25 12 13,28 12 12 75 25 33,39 26

Tarefa 5 14 5 9,34 6 5 47 12 26,69 30

Com base nos resultados obtidos, observou-se que n ˜ao existe uma relac¸ ˜ao entre o n ´umero de cliques e o tempo de durac¸ ˜ao, uma vez que certos utilizadores eram mais ofensivos na explorac¸ ˜ao e outros mais cautelosos. Observou-se ainda que o n ´umero m ´edio de cliques e a moda, aproximam-se do cen ´ario ideal na maior parte das tarefas. N ˜ao havendo um tempo esperado para a execuc¸ ˜ao de

Figura 5.1: Numero de cliques por tarefa.

Figura 5.2: Durac¸ ˜ao da realizc¸ ˜ao com sucesso por tarefa.

cada tarefa, as observac¸ ˜oes em relac¸ ˜ao aos valores obtidos referentes ao tempo, permite concluir que as tarefas s ˜ao de r ´apida execuc¸ ˜ao. No entanto, ´e poss´ıvel notar-se que o valor m ´edio do tempo tende a diminuir ao longo do teste, pois uma vez o utilizador familiarizado com a interface, este tornou-se mais r ´apido (embora a dificuldade das tarefas seja diferente, a familiarizac¸ ˜ao com a interface ajuda).

Durante a execuc¸ ˜ao dos testes, foi poss´ıvel observar-se que alguns alunos tiveram maior facilidade na navegac¸ ˜ao. Quando questionados sobre a interface, referiam uma semelhanc¸a com outras com as quais possivelmente tenham estado em contacto, havendo apenas um aluno que, tendo trabalhado com Django, estava mais familiarizado com certos detalhes de interac¸ ˜ao, que foram apontados como pouco intuitivos por alguns alunos. Os detalhes apontados como pouco intuitivos foram:

opc¸ ˜ao para gerir as avaliac¸ ˜oes encontra-se no canto inferior direito, sendo para alguns pouco vis´ıvel;

2. No papel de delegado, quando se gere uma avaliac¸ ˜ao tem que se selecionar a UCpara qual se quer criar um elemento de avaliac¸ ˜ao. O selecionar de umaUC´e feito clicando na checkbox visivel na Figura5.3. O facto de a selec¸ ˜ao ser na checkbox foi pouco intuitivo para alguns.

3. A realizac¸ ˜ao de uma ac¸ ˜ao ´e feita ap ´os selecionar uma UC. De seguida, atrav ´es da droplist no campo ”Action” ´e seleciona a ac¸ ˜ao a realizar e pressionado o bot ˜ao ”Go”. Este procedimento para fazer uma ac¸ ˜ao em vez de ser s ´o um clique foi pouco intuitivo par alguns.

Figura 5.3: Ecr ˜a da selec¸ ˜ao daUC, para criar um elemento de avaliac¸ ˜ao.

Em suma, os testes com utilizadores foram um sucesso, demonstrando que na maioria dos detalhes de interac¸ ˜ao, a interface ´e intuitiva. Existe a necessidade, especialmente para um delegado (devido ao facto de ter mais operac¸ ˜oes na interface), de haver uma introduc¸ ˜ao `a ferramenta, de modo a que este n ˜ao se sinta intimidado pelas funcionalidades.

6