Processamento de Informac¸ ˜ao

Estes requisitos correspondem ao processamento da informac¸ ˜ao que deve ser feita quando conclu´ıda a recolha de respostas, isto ´e, quando o estado do question ´ario passa a fechado. Estes s ˜ao:

1. 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).

Permite uma vis ˜ao r ´apida sobre os aspetos recolhidos.

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

Cont ´em toda a informac¸ ˜ao recolhida e anonimizada, possibilitando outras an ´alises.

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

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

(b) O regente e os docentes devem ter acesso ao resultado dos question ´arios realizados `as unidades curriculares que lecionam;

(c) O delegado deve ter acesso ao resultado dos question ´arios do ano de que ´e respons ´avel. O delegado de ciclo deve ter acesso a todos os resultados no curso, organizado por ano e semestre;

(d) O estudante deve ter acesso ao resultado dos question ´arios a que respondeu.

A notificac¸ ˜ao do fecho de um question ´ario ´e essencial, pois permite ter uma ideia do sucedido na respetiva entrega e permite ao delegado, regente e coordenador intervirem ainda em tempo de aulas, algo que nem sempre ´e poss´ıvel por ocorr ˆencia de atrasos.

2.2 Principais desafios

Durante a concec¸ ˜ao da tese n ˜ao s ´o foram confirmados alguns dos desafios mencionados na fase de projeto, como tamb ´em foram identificados outros novos, sendo de seguida todos mencionados. Quando confirmada a impossibilidade de a plataforma estar inserida no F ´enix, alguns dos requisitos anteriores tornaram-se imposs´ıveis de realizar, como por exemplo o requisito3bna secc¸ ˜ao2.1.2.

Quanto aos endpoints1 - pontos de acesso para obtenc¸ ˜ao de informac¸ ˜ao - quando aprofundado o conhecimento sobre os dados poss´ıveis de se obter, conclui-se que n ˜ao seria poss´ıvel obter-se o n ´umero de inscric¸ ˜oes de forma autom ´atica, tal como desejado na secc¸ ˜ao2.1.1, ponto(c). A informac¸ ˜ao poss´ıvel de obter atrav ´es dos mesmo em relac¸ ˜ao aos elementos de avaliac¸ ˜ao de uma UC, estaria condicionada pela organizac¸ ˜ao dada pelo docente e dependente do elemento de avaliac¸ ˜ao, tornando pouco eficaz a obtenc¸ ˜ao das datas de forma automatizada.

Outro desafio j ´a mencionado durante a fase do projeto, era o de tentar assegurar o n ´umero de respostas ao longo de semestre. Da apresentac¸ ˜ao do projeto, por sugest ˜ao do professor Lu´ıs Guerra e Silva, colocou-se atributos que permitissem atribuir pontuac¸ ˜oes aos alunos de forma a criar uma competic¸ ˜ao pelo n ´umero de inqu ´eritos respondidos. No entanto, esta competic¸ ˜ao teria de ter algum benef´ıcio de forma a atrair os alunos, algo que teria de ser melhor abordado do que foi nesta tese. Relembrando que a proposta anterior era de um pop-up no abrir F ´enix, algo que n ˜ao ´e conceb´ıvel.

Estando a plataforma alojada num site separado do F ´enix, torna o processo de preenchimento dos inqu ´eritos algo menos c ´omodo, como tamb ´em pode amedrontar alguns alunos pelo pop-up de ced ˆencia de informac¸ ˜ao, fazendo com que haja menos respostas/participantes.

Como ser ´a vis´ıvel mais adiante, numa fase inicial da tese, a framework eleita para desenvolver da plataforma seria a BennuFramework. Esta decis ˜ao inicial resultou num desafio de implementac¸ ˜ao elevado, uma vez que existe uma forte falta de documentac¸ ˜ao e suporte. O colega Jorge Goulart, que trabalhou com a ferramenta na sua tese, foi essencial para explicar como ´e que se montava e criava um projeto recorrendo `a framework, no entanto, ´e importante salientar que existiam aspetos na tese do colega que j ´a se encontravam desatualizados e n ˜ao funcionavam, sendo necess ´ario atualiza-los. Se n ˜ao fosse o profundo conhecimento do colega sobre a ferramenta, seria imposs´ıvel trabalhar com esta. Esta framework veio mais tarde a ser substitu´ıda pela Django framework, que envolveu um redesenhar da arquitetura.

Como dito na secc¸ ˜ao anterior, um dos objetivos importantes ´e garantir a autenticidade dos alunos, ou seja, que s ˜ao realmente os alunos inscritos na UC que respondem ao question ´ario. Este aspeto ´e assegurado pelo mecanismo de autenticac¸ ˜ao do IST `as aplicac¸ ˜oes que necessitem de autenticac¸ ˜ao pelo CAS. No entanto n ˜ao existe forma de garantir que apenas alunos que fazem o projeto s ˜ao os que respondem. A colocac¸ ˜ao do campo se est ´a ou n ˜ao a fazer o projeto, pode resultar em alunos que n ˜ao

queiram responder ao inqu ´erito, a preench ˆe-lo erradamente. Este aspeto ´e um desafio que apenas tem como soluc¸ ˜ao o bom senso por parte dos alunos.

Por ´ultimo, continua a existir o problema do suporte e manutenc¸ ˜ao `a plataforma, pois existe a neces-sidade de atualizar os delegados, coordenadores, docentes e importar os cursos todos os anos letivos .

2.3 Identificac¸ ˜ao de Utilizadores e suas func¸ ˜oes

Dado o ˆambito do projeto, os objetivos pretendidos, a tecnologia utilizada e os desafios anteriores, a lista de utilizadores e as suas func¸ ˜oes na plataforma ´e a seguinte:

• Administrador – Entidade que assegura a manutenc¸ ˜ao da plataforma, mantendo a informac¸ ˜ao dos cursos, UCs, Coordenadores, Docentes, Delegados e Alunos atualizada;

• Coordenador – Entidade que consegue visualizar o estado e os resultados dos question ´arios do curso que ´e respons ´avel e ainda extrair a informac¸ ˜ao bruta;

• Docente – Consegue visualizar o estado e os resultados dos question ´arios das UCs que ´e res-pons ´avel e ainda extrair a informac¸ ˜ao bruta;

• Aluno – Entidade que, no caso de haver um question ´ario por preencher, o preenche. Caso contr ´ario pode verificar resultados de question ´arios fechados em que tenha participado;

• Delegado – Entidade que ap ´os verificar os dados dos elementos de avaliac¸ ˜ao, prepara os ques-tion ´arios para serem depois enviados aos Alunos. Na eventual necessidade de reforc¸ar o preen-chimento de um dado question ´ario, pode mudar o estado deste (se necess ´ario) e enviar um email aos alunos. Pode ainda encerrar os question ´arios e obter os resultados num ficheiro. Cont ´em tamb ´em as func¸ ˜oes do Aluno.

Com recurso a Diagramas de Caso de Uso, ´e poss´ıvel transmitir de forma mais visual a func¸ ˜ao de cada utilizador em cada um dos m ´odulos que existem na plataforma. Os m ´odulos nesta plataforma s ˜ao:

• Gest ˜ao de Utilizadores e Conte ´udo; • Gest ˜ao de Respostas e Question ´arios.

De seguida, cada subsecc¸ ˜ao, apresenta de forma mais percet´ıvel as funcionalidades disponibiliza-das aos utilizadores em cada um dos m ´odulos mencionados.