Sistema de Apoio aos Delegados

(1)

Sistema de Apoio aos Delegados

Plataforma de Question ários sobre Duraç ão dos Elementos de Avaliaç ão

Filipe Rafael Soares

Dissertaç ão para obtenç ão do Grau de Mestre em

Engenharia Inform ´atica e de Computadores

Orientadores: Prof. Jo ˜ao Carlos Serrenho Dias Pereira

Prof. Nuno Jo ˜ao Neves Mamede

J ´

uri

Presidente: Prof. Rui Filipe Fernandes Prada

Orientador: Prof. Jo ˜ao Carlos Serrenho Dias Pereira

Vogal: Prof. Lu´ıs Jorge Br ´as Monteiro Guerra e Silva

(2)

(3)

Agradecimentos

Nesta seç ão quero agradecer às pessoas que, n ão s ó me apoiaram na conceç ão desta tese, como tamb ém tornaram poss´ıvel toda a minha experi ência acad émica e me apoiaram ao longo destes anos, ajudando-me a ser a pessoa que sou hoje e a atingir v ários marcos importantes na minha vida.

Ao professor Nuno Mamede e ao professor Jo ão Pereira, por terem acreditado na import ância desta tese e pela sua disponibilidade e paci ência ao longo da realizaç ão da mesma, como tamb ém pelo seu apoio ao longo da fase de projeto.

Ao meu colega Jorge Sim ão Goulart, pela sua disponibilidade para me esclarecer e explicar aspetos t écnicos relacionados com a framework inicial, mas acima de tudo, explicar-me como uma plataforma é concebida. Ao meu amigo R úben Filipe Martins Marques, pelo incentivo pela mudança de ferramenta, apoio e motivaç ão para o t érmino desta tese.

`

A Direç ão-Geral do Ensino Superior (DGES), por ao longo destes anos ter-me apoiado economi-camente, permitindo-me n ão s ó concluir os meus estudos, como tamb ém a suportar o meu agregado familiar. Gostava ainda de salientar o grande apoio prestado pela Dr.ª Cec´ılia Almeida, que sempre que surgiram problemas, foi bastante paciente e atenciosa, acreditando na minha pessoa e valorizando o meu esforço dada as circunst âncias.

`

A minha fam´ılia materna, que ao longo da minha vida apoiou-me e guiou-me pelas mais diversas adversidades, incentivando-me a ir mais longe todos dias e ser sempre melhor pessoa. Um obrigado mais especial à minha m ãe pela sua dedicaç ão para garantir que um dia eu fosse algu ém, mas que acima de tudo fosse um homem com bons princ´ıpios e educado, pelo seu esforço para garantir que tivesse as melhores condiç ões para estudar dentro dos seus poss´ıveis. Por último um obrigado especial ao meu tio Francisco Soares, pelo seu apoio e sugest ões.

Aos meus colegas do IST, que ao longo da minha vida acad émica, apoiaram-me e acreditaram em mim para os representar como Delegado e como membro do Conselho Pedag ógico, mas tamb ém confiaram em mim para os apoiar academicamente e pessoalmente, fazendo-me ser uma pessoa mais respons ável, observadora, atenta e sens´ıvel para diversos aspetos acad émicos e da vida.

Ao IST por ter uma organizaç ão que permite a alunos envolverem-se em decis ões da instituiç ão, oferecendo aos alunos a oportunidade de expandir o conhecimento noutras áreas e criarem h ábitos e cuidados profissionais.

(4)

(5)

Abstract

Fenix is the information management system - at Instituto Superior Tecnico (IST) - that process the infor-mation regarding the University degrees. It collects inforinfor-mation about courses being studied , students and the teachers. Within this system, the element ‘course’ is represented by the object curricular unit that is subsequently compose by three domains: evaluation, students and teachers. The organisation of the academic year requires that the number of hours associated with the evaluation of the different curricular units does not to exceed a certain limit. The Fenix does not have any tools to question about the number of hours used by the different elements. This requires the use of external mechanisms like google forms that allow to question and therefore get student feedback about overload, positive aspects or anything that needs to be improved regarding evaluation element’s and or course. The identification of this gap about data collection with a specific criterion led to the development of this dissertation. Its goal is the development of a platform able to question students about the duration of the courses eva-luation elements. In order to make easy to expand, the platform was build on a modular fashion, using the Django e FenixEdu Application Program Interface (API) for the backend; bootstrap e jinja for the frontend. The platform was subsequently put to user tests which lead to the conclusion that it was fit for purpose and is overall user friendly apart of certain aspects at its onset. This platform is operational and running since November 2019

Keywords

Questionnaire; Evaluation Elements; Curricular Unit; European Credit Transfer System (ECTS); Soft-ware Engineering; Full stack development

(6)

(7)

Resumo

O sistema de informaç ão do Instituto Superior Tecnico (IST) – Fenix – é respons ável pela gest ão dos dados relativos aos cursos, disciplinas, docentes e alunos. Neste, a entidade disciplina é representada pelo objeto Unidade Curricular (UC), sendo este composto por tr ês objetos: elementos de avaliaç ão, alunos e docentes. Um elemento de avaliaç ão tem um tipo associado, podendo este ser: testes, exa-mes, projetos, laborat órios e exerc´ıcios. Dada a organizaç ão de um ano letivo, é importante garantir que a carga total associada aos v ários elementos de avaliaç ão das UCs n ão ultrapassem um certo limite. O Fenix, n ão possui funcionalidades que permitam questionar acerca do tempo dispensado para cada elemento, sendo necess ário recorrer a mecanismos externos como google forms, de modo a conce-ber question ários para avaliar se houve sobrecarga e que UCs est ão a sobrecarregar mais os alunos.

´

E ainda poss´ıvel recolher informaç ões sobre aspetos positivos e a melhorar relativos ao elemento de avaliaç ão e/ouUC. Dada a necessidade de recolher a informaç ão mencionada, com um conjunto es-pec´ıfico de requisitos, surge esta tese, cujo objetivo é o desenvolvimento de uma plataforma capaz de questionar os alunos sobre a duraç ão dos elementos de avaliaç ão. Esta plataforma foi desenvolvida de forma modular para f ácil expans ão, recorrendo a Django e FenixEdu Application Program Interface (API) para o backend; bootstrap e jinja para frontend. A plataforma foi colocada à prova atrav és de testes com utilizadores, onde se conclui que esta respondia às necessidades e que no geral é intuitiva, havendo alguns aspetos que n ão s ão intuitivos ao in´ıcio. A plataforma encontra-se operacional desde novembro de 2019.

Palavras Chave

Question ários; Elementos de avaliaç ão; Unidade Curricular (UC); European Credit Transfer System (ECTS); Engenharia de software; Full stack development

(8)

(9)

Conte ´

udo

1 Introduc¸ ˜ao 1

1.1 Motivac¸ ˜ao . . . 3

1.2 Problema e soluc¸ ˜ao atual . . . 6

1.3 Organizac¸ ˜ao do documento . . . 7

2 Levantamento de Requisitos 9 2.1 Requisitos a cumprir . . . 11

2.1.1 Recolha de Informac¸ ˜ao . . . 11

2.1.2 Gestor de Question ´arios. . . 12

2.1.3 Processamento de Informac¸ ˜ao . . . 15

2.2 Principais desafios . . . 16

2.3 Identificaç ão de Utilizadores e suas funç ões. . . 17

2.3.1 Gest ˜ao de Utilizadores e Conte ´udo . . . 18

2.3.2 Gest ˜ao de Respostas e Question ´arios . . . 19

3 Trabalho relacionado 23 3.1 Google Forms . . . 25 3.2 Moodle . . . 27 3.3 F énix . . . 28 3.4 Resumo . . . 29 4 Implementaç ão 31 4.1 Arquitetura do sistema . . . 33

4.1.1 Gest ˜ao de Utilizadores e Conte ´udo . . . 36

4.1.2 Gest ˜ao de Respostas e Question ´arios . . . 37

4.2 Registo WebAPP/CAS . . . 38

4.3 Observac¸ ˜oes . . . 40

5 Validac¸ ˜ao 45 5.1 Requisitos cumpridos . . . 47

(10)

6 Conclus ˜oes 57

6.1 Resumo . . . 59 6.2 Trabalho futuro . . . 60

A Como criar um novo question ´ario? 65

(11)

Lista de Figuras

1.1 Curr´ıculo do 2º ano, 1º semestre da LEIC-T com informac¸ ˜ao da carga de trabalho. . . 4

1.2 Somat ório das horas de esforço de todas às UCs do 3º ano 1º semestre do ano letivo 2017/2018, ao longo do semestre. . . 5

1.3 LEIC-T 1º semestre 2017/2018, tempo previsto pelos docentes face o mencionado pelos alunos e mais informac¸ ˜ao.. . . 6

2.1 Diagrama de casos de Uso referente ao m ódulo Gest ão de Utilizadores e Conte údo. . . . 19

2.2 Diagrama de casos de Uso referente ao m ódulo Gest ão de Respostas e Question ários. . 21

3.1 Resumo visual de respostas no Google forms. . . 26

3.2 Documentaç ão/Tutorial de como criar um question ário no Moodle. . . 28

4.1 Arquitetura em camadas da plataforma desenvolvida. . . 33

4.2 Vis ˜ao simplificada do UML do problema. . . 41

4.3 Pop up de registo da WebApp. . . 42

4.4 M ´aquina de estados finitos, do objeto ”Quiz”. . . 43

5.1 Numero de cliques por tarefa. . . 54

5.2 Duraç ão da realizç ão com sucesso por tarefa. . . 54

5.3 Ecr ã da seleç ão da UC, para criar um elemento de avaliaç ão. . . 55

A.1 Nova classe para a base de dados.. . . 67

A.2 Alteraç ão à classe ”Answer”. . . 67

A.3 Novo formul ´ario para recolha de respostas. . . 68

A.4 Alteraç ão à classe ”ManageQuiz”, ao m étodo ”build information” . . . 68

(12)

B.1 Google Form primeira p ´agina do inqu ´erito atual. . . 72

B.2 Google Form segunda p ´agina do inqu ´erito atual (caso postivo). . . 73

B.3 Google Form primeira p ´agina do inqu ´erito atual (caso negativo). . . 74

B.4 Google Form terceira p ´agina do inqu ´erito atual. . . 75

B.5 Google Form quarta p ´agina do inqu ´erito atual. . . 76

(13)

Lista de Tabelas

3.1 Resumo das opç ões fase alguns requisitos mais relevantes. 0 – N ão garante; 1 – Garante

mal; 2 – Garante bem; 3 – Garante muito bem . . . 29

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

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

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

5.6 An álise dos resultados obtidos aos testes de utilizadores (n úmero de cliques esperado diz respeito ao n úmero de cliques m´ınimos para completar a tarefa). . . 53

(14)

(15)

Listagens

(16)

(17)

Acr ´

onimos

UC Unidade Curricular

ECTS European Credit Transfer System

LEIC-T Licenciatura em Engenharia Inform ´atica e de Computadores - Taguspark

DGES Direc¸ ˜ao-Geral do Ensino Superior

UML Unified Modeling Language

API Application Program Interface

(18)

(19)

1

Introduc¸ ˜ao

Conte ´

udo

1.1 Motivac¸ ˜ao. . . . 3

1.2 Problema e soluc¸ ˜ao atual. . . . 6

(20)

(21)

Qual a diferença entre question ário1e inqu érito2? Do ponto vista lingu´ıstico, um question ário consiste numa s érie de perguntas acerca de um tema, que permite questionar um grupo de indiv´ıduos e entender a opini ão destes com base nas respostas dadas. Das respostas obtidas, é poss´ıvel ter um parecer por cada pergunta, que em suma contribuem para um parecer geral acerca do foco do question ário. Enquanto que um inqu érito é por norma associado à investigaç ão cujo objetivo consiste em averiguar determinados factos. Martyn Denscombe refere no seu livro [1, p. 166], que existem diversos tipos de question ários, no entanto, um question ário de âmbito de pesquisa, deve seguir os seguintes tr ês crit érios:

1. Deve ser concebido de modo a recolher informaç ão que pode ser usada para uma an álise; 2. Deve consistir numa lista de perguntas escritas, sendo ocasional a utilizaç ão de figuras; 3. Deve recolher informaç ão perguntando diretamente sobe os aspetos alvo.

Do que depende o sucesso de um question ário? De acordo com Martyn Denscombe [1, p. 167], o sucesso de um question ário est á dependente de tr ês aspetos, sendo o assegurar destes, essencial para que os resultados do question ário sejam completos e v álidos. Os aspetos s ão:

1. R ´acio de respostas - quantas repostas foram obtidas;

2. R ácio de respostas completas - quantas perguntas foram respondidas face o total; 3. Validade das respostas - Qu ão honestas ou precisas s ão as respostas.

1.1 Motivac¸ ˜ao

O Instituto Superior Tecnico (IST) tem como miss ão contribuir para o desenvolvimento da sociedade, tra-balhando para atingir essa miss ão atrav és de diversas áreas acad émicas, como por exemplo investigaç ão, p ós-graduaç ão, desenvolvimento e inovaç ão. Contribui ainda promovendo um ensino superior ao n´ıvel dos mais elevados padr ões internacionais.

NoIST, o ensino prestado diz respeito às áreas da Arquitetura, Engenharia e Ci ências e Tecnologia, estando diversos Cursos assegurados nas respetivas áreas cient´ıficas. Cada Curso é composto por um conjunto de Unidades Curriculares (UCs), respons áveis por lecionar um determinado conte údo e assegurar que os alunos inscritos na mesma, adquiriram um determinado n´ıvel de conhecimento, atrav és de elementos de avaliaç ão que podem ser de caracter pr ático, como laborat órios e projetos, e/ou te órico, atrav és de exames ou testes.

1_{https://dicionario.priberam.org/questionario} 2_{https://dicionario.priberam.org/inquerito}

(22)

A umaUC é associada uma carga de trabalho, cujo somat ório de todas UCs de um Curso resulta na carga de trabalho esperada no Curso. Atualmente, a carga de trabalho é medida pela European Credit Transfer System (ECTS), sendo esta m étrica complexa e subjetiva na comunidade acad émica. Esta unidade de medida contabiliza a frequ ência da UC, realizaç ão de trabalhos pr áticos, projetos e est ágios, bem como o tempo de estudo e de avaliaç ão.

NoIST, 1ECTS é equivalente a 28 horas de trabalho3_{e, no geral, a duraç ão dos ciclos de estudo é}

definida em torno desta m étrica, sendo por exemplo o 1º ciclo necess ário 180ECTS(28 horas × 180 ECTS= 5040 horas). No entanto, o valor de horas de trabalho pode variar de faculdade para faculdade, havendo opini ões distintas entre docentes, gerando desentendimento e subjetividade na avaliaç ão de sobrecarga de trabalho, pois este valor pode variar entre 25 e 28 horas.

A Figura1.1corresponde ao 2º ano, 1º Semestre da Licenciatura em Engenharia Inform ática e de Computadores - Taguspark (LEIC-T). Tome-se por exemplo, aUCde Programaç ão com Objectos para demonstraç ão do c álculo deECTS.

Figura 1.1: Curr´ıculo do 2º ano, 1º semestre da LEIC-T com informac¸ ˜ao da carga de trabalho.

Como observ ável na Figura 1.1, à UC mencionada espera-se que tenha uma carga de trabalho correspondente a 6.0 cr éditos - outra designaç ão paraECTS- sendo de esperar, com base nos c álculos anteriores, uma carga total (T) de 168 horas. Nesta mesma figura observa-se que existe uma divis ão desta carga total, em carga hor ária de contacto (C) e trabalho aut ónomo (TA). Assim sendo, um aluno tem de dispensar 63 horas para C (correspondendo às aulas te óricas e pr áticas) e 105 horas para TA (tempo dedicado para pesquisa, estudo, elaboraç ão individual ou coletiva de trabalhos, etc.), sendo esta última considerada excessiva, quando o trabalho exigido pelos docentes numaUC, faz com que

(23)

um aluno tenha de dispensar mais que 105 horas.

A carga de trabalho aut ónomo, resulta de uma estimativa dada pelo corpo de docentes (o res-pons ável daUC), com base no que espera lecionar e avaliar no semestre em que se encontra. Esta estimativa pode conter alguma subjetividade, que quando errada por ser em excesso, pode colocar a UCou outras que se encontram em simult âneo, em risco, proporcionando um excesso de trabalho coletivo, devido ao acumular de trabalho distribu´ıdo pelas restantes UCs do semestre. Observe-se a Figura1.2que mostra o esforço previsto de trabalho por semana, dito pelos regentes, para o 3º ano - 1º semestre, onde a linha tracejada vermelha corresponde a 40 horas. Segundo o sistema de educaç ão portugu ês, n ão deveria de haver momentos superiores a este tracejado, algo que na imagem acontece durante v árias semanas.

Figura 1.2: Somat ório das horas de esforço de todas às UCs do 3º ano 1º semestre do ano letivo 2017/2018, ao

longo do semestre.

Que raz ões podem levar a umaUCa acusar excesso de trabalho? Para al ém de um planeamento incorreto daUC, o desleixo/desorganizaç ão dos alunos tem tamb ém um peso neste aspeto. Por vezes estes deixam o estudo para o projeto e o desenvolvimento do mesmo para a última da hora, no qual, em conjunto com as Leis de Murphy, faz com que estes sintam que foi tudo muito em cima ou pouco tempo. No entanto, mesmo com o referido, a maioria dos alunos acaba por referir um tempo perto daquele que os docentes previam (a Figura1.3confirma o mencionado).

Assim sendo, de forma a tentar prevenir problemas de excesso de trabalho, isto é, evitar mais semanas acima das 40 horas, é necess ário criar um mecanismo que permita validar o esforço dos elementos de avaliaç ão. Com esse intuito os delegados daLEIC-T, criaram como soluç ão question ários manualmente geridos.

Como é poss´ıvel concluir, a recolha da informaç ão acerca da perceç ão dos alunos face à complexi-dade dos elementos de avaliaç ão, é um aspeto crucial para garantir que o n úmero deECTSsentidos naUC, semestre e curso, s ão justos e equilibrados e assim assegurar um ano letivo sem sobrecarga de trabalho.

(24)

Figura 1.3: LEIC-T 1º semestre 2017/2018, tempo previsto pelos docentes face o mencionado pelos alunos e mais

informac¸ ˜ao.

1.2 Problema e soluc¸ ˜ao atual

De momento o procedimento para recolha da informaç ão sobre a carga associada a cada projeto é ma-nual, e os question ários s ão concebidos recorrendo ao Google Forms, sendo os resultados registados numa folha de Excel. Estes ficam na Google Drive de um dos delegados (por norma no de ciclo/curso), organizados numa hierarquia de pastas estruturada/dividida pelo ano e semestre4_.

De seguida, o delegado tem a responsabilidade de, no fim de cada entrega, redigir um email sen-sibilizando os colegas para a import ˆancia dos question ´arios, colocando neste email um short link do Google Form a preencher.

Quando o n úmero de respostas se encontra estabilizado, o delegado respons ável pelo question ário extrai o Excel da Google Drive e trabalha-o localmente. Caso este n úmero seja baixo, o delegado volta a enviar para todos os alunos da disciplina um email semelhante ao anterior, de modo a tentar

(25)

incentivar o preenchimento. De seguida, verifica se existem IST-ID inv álidos, duplicados (mantendo o mais recente), se os questionados est ão realmente inscritos e filtram repostas indevidas (como por exemplo com linguagem impr ópria), havendo uma an álise exaustiva de todas respostas. Ap ós esta filtragem procede-se a uma an álise simples, vendo o tempo m áximo, m´ınimo e m édia.

Dada a filtragem e a anonimizaç ão da informaç ão recolhida, os dados s ão enviados para o coorde-nador (e, por vezes, aos regentes), que ir á realizar a sua an álise e, posteriormente, a apresentar á no relat ório de fecho do semestre.

Conclui-se que, ao longo deste processo, existem os seguintes problemas:

• O tempo despendido para a construç ão de question ários para cada elemento de avaliaç ão e o seu envio;

• A gest ão do espaço privado da Google Drive usado para fins institucionais, isto é, quando o delegado respons ável pela pasta abandone o cargo, tem de passar a pasta para outro delegado e este partilha-la com futuros delegados;

• O n úmero de respostas ser baixo - n ão haver mecanismos autom áticos de lembrança para o preenchimento ou de reenvio exclusivo para os que n ão preencheram;

• N ˜ao haver mecanismos de autenticidade, nas respostas dadas.

1.3 Organizac¸ ˜ao do documento

Este documento encontra-se dividido em seis cap´ıtulos, sendo o primeiro relativo à Introduç ão e os restantes cap´ıtulos e respectivos conte údos s ão:

• Capitulo2- Levantamento de requisitos e os desafio que residem em alguns deles;

• Capitulo3- Trabalho relacionado. Uma vis ão do que é feito atualmente com o Google Form, uma explicaç ão do que a plataforma Moodle é capaz e como seria se estivesse inserido no F énix. Reflex ão das tr ês alternativas apresentadas;

• Capitulo4- A arquitetura da soluç ão. Apresentaç ão da soluç ão que melhor responde aos requi-sitos, ap ós uma reflex ão dos aspectos positivos e negativos das soluç ões abordadas na cap´ıtulo 3;

• Capitulo5- Avaliaç ão realizada à plataforma, referindo as m étricas usadas;

• Capitulo 6 - Reflex ão sobre os resultados da avaliaç ão feita e uma analise do processo da conceç ão da plataforma.

(26)

(27)

2

Levantamento de Requisitos

Conte ´

udo

2.1 Requisitos a cumprir . . . 11

2.2 Principais desafios . . . 16

(28)

(29)

Nesta secç ão é exposto o objetivo da plataforma, sendo apresentados os requisitos que a plataforma deve cumprir e o desafio que reside em alguns.

2.1 Requisitos a cumprir

A plataforma implementada tem como objetivo principal questionar os alunos inscritos numaUC, sobre a duraç ão dos elementos de avaliaç ão da mesma, de modo o mais automatizado poss´ıvel e posterior-mente, deve processar as respostas como é adiante explicado. O question ário, no caso de avaliaç ões de projetos, pode ainda questionar sobre o agrado dos alunos sobre a tem ática do mesmo.

Os requisitos levantados para esta plataforma podem ser agrupados em 3 grupos, sendo estes: • Recolha de Informac¸ ˜ao;

• Gestor de Question ários; • Processamento de Informaç ão.

De seguida s ˜ao apresentados os requisitos levantados, separados pelos respetivos grupos.

2.1.1 Recolha de Informac¸ ˜ao

Estes requisitos referem-se à informaç ão que deve ser recolhida quando é preenchido um question ário, à anonimizaç ão e à autenticidade. Os requisitos s ão:

1. A plataforma deve recolher a seguinte informaç ão acerca dos questionados, quer de forma au-tom ática ou manual:

(a) Tempo investido pelo grupo (manual e obrigat ´orio); (b) Tempo investido individual (manual e obrigat ´orio);

(c) Curso, unidade curricular e n úmero de inscriç ões (preferencialmente autom ático e obrigat ório); (d) Nota que espera obter no trabalho realizado face o submetido (manual e obrigat ório);

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

A recolha dos tempos despendidos pelo aluno e pelo grupo s ão o foco deste projeto. O curso, unidade curricular e n úmero de inscriç ões permite caracterizar melhor os questionados, assim como fazer uma an álise mais pormenorizada. A recolha da nota esperada, quando comparada com a nota real, permite perceber a perspetiva dos alunos face ao submetido, sendo poss´ıvel comentar se a unidade curricular tinha os crit érios demasiado rigorosos ou se os inquiridos n ão

(30)

tinham consci ência do submetido. Pontos fortes, pontos a melhorar e coment ários/sugest ões s ão campos que mais tarde auxiliam o delegado a preencher os QUCs e permitem, tamb ém, transmitir uma melhor informaç ão do que se passa/passou.

2. A plataforma deve assegurar que os questionados s ˜ao estudantes inscritos na unidade curricular foco do question ´ario;

´

E importante assegurar que os alunos que respondem aos question ários s ão realmente os alunos que est ão inscritos à unidade curricular, assim como assegurar que estes respondem no m áximo uma vez.

3. A plataforma deve garantir a anonimidade dos questionados:

(a) Na eventualidade de o n úmero de respostas permitir a identificaç ão de um inquirido, as res-postas devem ser agrupadas.

A anonimidade dos quesitonados é um aspeto essencial, para a obtenç ão de coment ários e feed-back honestos.

4. A plataforma deve assinalar quando o n úmero de respostas n ão garante representatividade (por exemplo, com a f órmula da representatividade aplicada pelo Conselho Pedag ógico);

Apesar de n ão ter o n úmero necess ário para representar a unidade curricular, considera-se a informaç ão, ainda que pouca, importante e deve ser apresentada, assinalando apenas que n ão tem representatividade.

2.1.2 Gestor de Question ´arios

Estes requisitos dizem respeito à gest ão dos question ários, como por exemplo a gest ão relativa aos estados de um question ário ou o envio de notificaç ão sobre os mesmos. Os requisitos s ão:

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

(31)

(b) Aberto – Estado que permite que os utilizadores respondam; i. Este estado fica ativo quando:

1 No dia 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.

A passagem de um question ário para o estado Aberto ou Fechado s ão dois aspetos bastante importantes, pois atribuem à plataforma um certo grau de automatizaç ão, sem retirar a liberdade ao delegado de gerir o processo de uma forma mais manual.

2. A plataforma deve conter informaç ão acerca da data de encerramento de projetos ou laborat órios, preferencialmente de forma autom ática, mas deve permitir que o delegado possa inserir esta informaç ão caso seja necess ário. Tamb ém deve permitir que este introduza informaç ão sobre outros poss´ıveis elementos de avaliaç ão que devam ser alvo de question ários:

(a) No caso de projeto, a data de encerramento corresponde `a data de entrega;

(b) No caso de laborat órios, a data de fim corresponde ao fim da semana onde decorreu a avaliaç ão;

(c) No caso de outros elementos, a data de fim deve ser uma das poss´ıveis hip ´oteses acima mencionadas.

A obtenç ão ou a introduç ão das datas dos elementos de avaliaç ão em que se justifique a execuç ão dos question ários, torna o sistema mais automatizado e remove o trabalho que recai sob o dele-gado. A exist ência de uma parte manual neste processo é essencial, pois nem todas as unidades curriculares t êm as datas no F énix (ver secç ão3.3) e nem todos os elementos de avaliaç ão t êm uma data no F énix (laborat órios, por exemplo).

(32)

3. 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 ário de uma dada UC j á se encontra acess´ıvel. Este e-mail pode ser modificado pelo delegado, mas deve garantir que o link para o preen-chimento est á presente;

(b) Se poss´ıvel, quando iniciada a sess ão no F énix, apresentaç ão de uma mensagem sobre todos os question ários que este utilizador ainda n ão preencheu. Quando n ão houver ques-tion ários para preencher, esta mensagem n ão ser á apresentada.

Os mecanismos de divulgaç ão s ão essenciais e um foco do projeto, pois pretende-se com estes reduzir o n úmero de abstenç ões e manter uma taxa de respostas constante e alta ao longo do semestre.

4. A plataforma deve permitir ao delegado o reenvio peri ´odico de um e-mail como est´ımulo ao pre-enchimento 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 baseado num formato, mas deve sempre conter o question ´ario.

Relacionado com o t ópico anterior, pretende-se com o proposto reduzir o n úmero de abstenç ões de respostas. Existem momentos em que os question ários s ão pouco preenchidos, pelo que acredita-se que com algum relembrar do assunto, o n úmero de respostas seja mais constante ao longo do semestre.

5. A plataforma, quando o estado dos question ários é aberto, deve mostrar aos utilizadores (delega-dos, alunos ou docentes) apenas o n úmero de respostas, a data de fecho e quanto tempo resta at é à data de fecho.

Este ponto complementa o anterior, fornecendo ao delegado um dashboard. Deste modo, per-mite aos utilizadores mencionados ter uma noç ão de quantos question ários j á foram preenchidos, podendo o delegado enviar o email a reforçar o preenchimento, ou ao docente durante as aulas reforçar a import ância do preenchimento dos question ários, ou at é mesmo os pr óprios alunos pe-direm aos restantes que preencham.

(33)

2.1.3 Processamento de Informac¸ ˜ao

Estes requisitos correspondem ao processamento da informaç ão que deve ser feita quando conclu´ıda a recolha de respostas, isto é, quando o estado do question ário passa a fechado. Estes s ão:

1. A plataforma, quando o estado do question ário é fechado, deve realizar um sum ário dos dados, mostrando:

(a) N úmero de respostas face ao n úmero de questionados, m´ınimos, m áximos, desvio padr ão, m édia (total e sem 5% dos extremos).

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

2. A plataforma deve permitir a extraç ão de toda a informaç ão recolhida quando o estado do ques-tion ário é fechado, em formato Excel (.xls)

Cont ém toda a informaç ão recolhida e anonimizada, possibilitando outras an álises.

3. A plataforma deve notificar todas as partes e permitir a visualizaç ão das respostas quando o estado do question ário é 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 ários do ano de que é respons ável. 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 notificaç ão do fecho de um question ário é 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 é poss´ıvel por ocorr ência de atrasos.

(34)

2.2 Principais desafios

Durante a conceç ão da tese n ão s ó foram confirmados alguns dos desafios mencionados na fase de projeto, como tamb ém foram identificados outros novos, sendo de seguida todos mencionados. Quando confirmada a impossibilidade de a plataforma estar inserida no F énix, alguns dos requisitos anteriores tornaram-se imposs´ıveis de realizar, como por exemplo o requisito3bna secç ão2.1.2.

Quanto aos endpoints1 _{- pontos de acesso para obtenç ão de informaç ão - quando aprofundado}

o conhecimento sobre os dados poss´ıveis de se obter, conclui-se que n ão seria poss´ıvel obter-se o n úmero de inscriç ões de forma autom ática, tal como desejado na secç ão2.1.1, ponto(c). A informaç ão poss´ıvel de obter atrav és dos mesmo em relaç ão aos elementos de avaliaç ão de uma UC, estaria condicionada pela organizaç ão dada pelo docente e dependente do elemento de avaliaç ão, tornando pouco eficaz a obtenç ão das datas de forma automatizada.

Outro desafio j á mencionado durante a fase do projeto, era o de tentar assegurar o n úmero de respostas ao longo de semestre. Da apresentaç ão do projeto, por sugest ão do professor Lu´ıs Guerra e Silva, colocou-se atributos que permitissem atribuir pontuaç ões aos alunos de forma a criar uma competiç ão pelo n úmero de inqu éritos respondidos. No entanto, esta competiç ão 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 énix, algo que n ão é conceb´ıvel.

Estando a plataforma alojada num site separado do F énix, torna o processo de preenchimento dos inqu éritos algo menos c ómodo, como tamb ém pode amedrontar alguns alunos pelo pop-up de ced ência de informaç ão, fazendo com que haja menos respostas/participantes.

Como ser á vis´ıvel mais adiante, numa fase inicial da tese, a framework eleita para desenvolver da plataforma seria a BennuFramework. Esta decis ão inicial resultou num desafio de implementaç ão elevado, uma vez que existe uma forte falta de documentaç ão e suporte. O colega Jorge Goulart, que trabalhou com a ferramenta na sua tese, foi essencial para explicar como é que se montava e criava um projeto recorrendo à framework, no entanto, é importante salientar que existiam aspetos na tese do colega que j á se encontravam desatualizados e n ão funcionavam, sendo necess ário atualiza-los. Se n ão 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 secç ão anterior, um dos objetivos importantes é garantir a autenticidade dos alunos, ou seja, que s ão realmente os alunos inscritos na UC que respondem ao question ário. Este aspeto é assegurado pelo mecanismo de autenticaç ão do IST às aplicaç ões que necessitem de autenticaç ão pelo CAS. No entanto n ão existe forma de garantir que apenas alunos que fazem o projeto s ão os que respondem. A colocaç ão do campo se est á ou n ão a fazer o projeto, pode resultar em alunos que n ão

(35)

queiram responder ao inqu érito, a preench ê-lo erradamente. Este aspeto é um desafio que apenas tem como soluç ão o bom senso por parte dos alunos.

Por último, continua a existir o problema do suporte e manutenç ão à plataforma, pois existe a neces-sidade de atualizar os delegados, coordenadores, docentes e importar os cursos todos os anos letivos .

2.3 Identificaç ão de Utilizadores e suas funç ˜

oes

Dado o âmbito do projeto, os objetivos pretendidos, a tecnologia utilizada e os desafios anteriores, a lista de utilizadores e as suas funç ões na plataforma é a seguinte:

• Administrador – Entidade que assegura a manutenç ão da plataforma, mantendo a informaç ão dos cursos, UCs, Coordenadores, Docentes, Delegados e Alunos atualizada;

• Coordenador – Entidade que consegue visualizar o estado e os resultados dos question ários do curso que é respons ável e ainda extrair a informaç ão bruta;

• Docente – Consegue visualizar o estado e os resultados dos question ários das UCs que é res-pons ável e ainda extrair a informaç ão bruta;

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

• Delegado – Entidade que ap ós verificar os dados dos elementos de avaliaç ão, prepara os ques-tion ários para serem depois enviados aos Alunos. Na eventual necessidade de reforçar o preen-chimento de um dado question ário, pode mudar o estado deste (se necess ário) e enviar um email aos alunos. Pode ainda encerrar os question ários e obter os resultados num ficheiro. Cont ém tamb ém as funç ões do Aluno.

Com recurso a Diagramas de Caso de Uso, é poss´ıvel transmitir de forma mais visual a funç ão de cada utilizador em cada um dos m ódulos que existem na plataforma. Os m ódulos nesta plataforma s ão:

• Gest ão de Utilizadores e Conte údo; • Gest ão de Respostas e Question ários.

De seguida, cada subsecç ão, apresenta de forma mais percet´ıvel as funcionalidades disponibiliza-das aos utilizadores em cada um dos m ódulos mencionados.

(36)

2.3.1 Gest ˜ao de Utilizadores e Conte ´

udo

Este m ódulo é respons ável pela gest ão/inserç ão da informaç ão relativa aos cursos, UCs, docentes e alunos. É respons ável pela atribuiç ão de um docente a um curso (coordenador de curso), assim como atribuir o cargo de delegado a um aluno (delegado de curso). Como vis´ıvel na Figura2.1, apenas existe um utilizador capaz de manipular esta informaç ão que é o administrador. Todas as funcionalidades de gest ão s ão compostas por duas funcionalidades, sendo elas adicionar ou modificar, onde modificar tanto pode ser editar ou apagar. De seguida é melhor explicado cada um dos casos presente na figura mencionada.

1. Gerir Curso: Introduzindo o ano letivo desejado, acede aos endpoints do F ´enix para carregar

informaç ão relativa a qualquer um dos cursos doISTde forma autom ática.

2. Gerir Coordenador: O administrador deve ser capaz de atribuir um ou mais coordenadores a

um curso. Ap ós a inserç ão dos cursos, este pode selecionar os cursos e importar o respetivo coordenador, que se encontrem dispon´ıveis nos endpoints.

3. Gerir UC: Selecionando um curso, o administrador importa todas as UCs que se encontram

acess´ıveis atrav ´es dos endpoints.

4. Gerir Docente: O administrador ´e capaz de ver todos os docentes que se encontram na

plata-forma, assim como atribuir a responsabilidade de outras UCs que n ˜ao tenham vindo dos end-points, ou atribuir um curso como respons ´avel.

5. Gerir Aluno: Permite ao administrador ter uma vis ão de todos os alunos que j á acederam à

plataforma, podendo nesta área atribuir o cargo de delegado a um aluno, ou corrigir informaç ão que o aluno desejar.

6. Gerir Delegado: O administrador deve ser capaz atribuir e remover o cargo de delegado a um

aluno, sendo esta funcionalidade manual, sem recurso a endpoints, por n ão haver informaç ão dos de delegados atrav és dos endpoints.

(37)

Figura 2.1: Diagrama de casos de Uso referente ao m ódulo Gest ão de Utilizadores e Conte údo.

2.3.2 Gest ˜ao de Respostas e Question ´arios

Este m ódulo assegura que cada um dos utilizadores (com exceç ão do administrador) é capaz de de-sempenhar as funç ões mencionadas anteriormente. Este pode ser considerado como o m ódulo ope-racional de toda plataforma, uma vez que permite a gest ão dos question ários, responder aos mesmos, visualizaç ão das respostas e mais. Como é vis´ıvel na Figura 2.2, neste m ódulo tem como foco os delegados, alunos, coordenadores e docentes. No entanto, o administrador da plataforma consegue re-alizar algumas das operaç ões listadas adiante, como as das operaç ões 1, 2 e 4, pois este tem acesso ao dom´ınio da plataforma.

Passando a explicar cada caso:

1. Gerir question ´ario: Esta funcionalidade ´e de acesso exclusivo ao delegado, dando-lhe a

possi-bilidade de criar, modificar/apagar ou reforçar question ários, atrav és de cada um dos respetivos casos presentes na Figura2.2.

(38)

2. Visualizar resultados dos question ´arios do curso: O delegado consegue ter uma vis ˜ao sobre

todos os question ários que se encontram no seu curso, tendo uma vis ão sum ária, do estado de cada question ário, n úmero de respostas e ainda uma breve estat´ıstica se poss´ıvel. Caso o estado do question ário o permita, este pode ainda extrair os resultados do mesmo.

3. Responder question ´ario: Permite ao aluno responder aos question ´arios que lhe digam respeito,

caso o estado desses o permita.

4. Visualizar resultados dos question ´arios das respectivas UC: Permite ao aluno visualizar os

resultados resumidos caso o estado do question ário o permita e caso o tenha preenchido. 5. Gerir inscriç ão ao question ário: Por norma, todos os alunos quando ligados à plataforma est ão

inscritos/subscritos a todas as notificaç ões das UCs, o que faz com que recebam os emails au-tom áticos. No entanto, caso o aluno n ão pretenda ser incomodado por esses emails, pode remo-ver a sua subscriç ão, podendo mais tarde voltar a subscreremo-ver.

6. Visualizar resultados dos question ´arios das UC respons ´aveis: Esta funcionalidade tem um

comportamento id êntico ao caso 4, mas exclusivamente focada para docentes, uma vez que acrescenta a funcionalidade de extraç ão da informaç ão.

7. Visualizar resultados dos question ários do respectivo curso: Este caso é id êntico ao caso 2,

(39)

(40)

(41)

3

Trabalho relacionado

Conte ´

udo

3.1 Google Forms . . . 25 3.2 Moodle . . . 27 3.3 F ´enix . . . 28 3.4 Resumo . . . 29

(42)

(43)

Com o intuito de analisar caracter´ısticas em sistemas/plataformas de question ários, procedeu-se a uma pesquisa sobre ferramentas deste g énero, tendo-se destacado o Google Forms e o Moodle por poderem ser inseridas num âmbito institucional. Durante a pesquisa foram encontradas outras ferramentas que n ão ser ão aqui mencionadas, uma vez que ou n ão cumpriam os requisitos desejados, ou tinham um limite di ário, havendo custos de utilizaç ão.

Neste cap´ıtulo pretende-se ver em que medida cada uma das ferramentas mencionadas cumpre com os requisitos mencionados, referindo por último uma vis ão da potencialidade de uma ferramenta que produza o desejado, inserida no F énix. Por último, s ão apresentados coment ários e uma vis ão geral sobre o assunto abordado.

3.1 Google Forms

O Google Forms1_{´e uma ferramenta presente na Google Drive, que permite aos utilizadores constru´ırem}

question ários atrav és de uma interface intuitiva. Esta, em conjunto com a funcionalidade do F énix de enviar emails para os alunos de acordo com aUC, é a metodologia atual seguida pelos delegados da LEIC-T, onde estes realizam o processo descrito na subcap´ıtulo1.2.

O Google Forms permite aos utilizadores constru´ırem question ários com um elevado grau de com-plexidade, com um diverso leque de hip óteses para o tipo de quest ões/repostas e ainda possibilita um fluxo condicionado por respostas selecionadas. Os tipos de quest ões/respostas s ão:

• Resposta curta; • Par ágrafo; • Escolha M últipla; • Caixa de verificaç ão; • Pendente;

• Carregar Ficheiro;

• Escala Linear;

• Grelha de escolha m últipla; • Grelha de caixas de verificaç ão; • Data;

• Hora.

Sendo uma ferramenta da Google Drive, esta trabalha em conjunto com outras, nomeadamente a Google Spreadsheets. Esta ferramenta corresponde a uma folha de Excel onde s ão armazenadas as respostas dadas nos question ários. É com base nesta folha que é gerado um breve sum ário do formul ário, como é poss´ıvel ver na Figura3.1.

Outro aspeto da ferramenta aqui descrita ´e o facto de existir uma comunidade ativa a desenvolver plugins para esta, oferecendo a todos os utilizadores um conjunto de funcionalidades sobre os

(44)

tados e sobre os question ários, como por exemplo, envio de documentos, notificaç ão de submiss ão, mails personalizados na submiss ão de question ários, etc., expandido assim o seu potencial.

No que diz respeito a autenticidade, o Google Forms tamb ém possibilita a identificaç ão dos utili-zadores, sendo necess ário que todos os utilizadores possuam uma conta Google. Contudo, para que fosse poss´ıvel a identificaç ão de alunos de uma dada UC, seria necess ário o cruzamento de informaç ão da conta Google com o IST ID do aluno. N ão havendo tal cruzamento, a autenticidade n ão é garantida. Por último, esta ferramenta cria formul ários reativos a qualquer plataforma (PC ou mobile), sendo gratuita, sem qualquer limite para o n úmero de question ários que se possa criar, embora possa haver alguns plugins pagos.

(45)

3.2 Moodle

O Moodle é um software open-source usado no ensino como uma plataforma de gest ão de recursos online, permitindo a transmiss ão e a organizaç ão de conte údos program áticos entre outras funcionalida-des. Neste operam, principalmente, tr ês tipos de utilizadores e que executam as seguintes operaç ões2:

• Administrador

• gerir utilizadores;

• definir modelos de autenticac¸ ˜ao;

• programar c ´opias de seguranc¸a

au-tom ´aticas;

• gerir disciplinas e as suas categorias; • gerir idiomas;

• gerir m ´odulos (atividades e blocos);

• gerir p ágina inicial; • gerir apar ência do site; • aceder a relat órios;

• instalar novos blocos de atividades; • editar apar ˆencia dos temas;

• atualizar a vers ˜ao do Moodle.

• Professor

• configuraç ão da disciplina; • gest ão de alunos;

• gest ˜ao de grupos;

• gest ão de c ópias de segurança; • an álise de relat órios;

• gest ˜ao de escala de notas; • an ´alise de notas dos alunos;

• gest ˜ao de sistema de arquivos/ficheiros; • acesso a f ´orum de professores;

• acesso a tarefas efetuadas pelos alunos.

• Aluno

• recursos; • atividades;

• bloco administrac¸ ˜ao.

O mais semelhante ao que se pretende com este documento é a ferramenta de question ários pre-sente no lado do professor, no entanto, o question ário tem uma gest ão e um comportamento diferente do desejado, sendo que tamb ém a responsabilidade é para ser do lado do delegado e n ão do profes-sor. Esta diferença influencia o fluxo, algo que é importante num question ário e um aspeto positivo no Google Forms.

(46)

No que diz respeito à anonimidade dos alunos face às suas respostas3, existe um campo na criaç ão do question ário que permite ativar ou n ão a identificaç ão dos alunos alvos (Figura3.2). Esta informaç ão tamb ém pode ser recolhida e tem uma funcionalidade que permite obter um breve sum ário.

Figura 3.2: Documentaç ão/Tutorial de como criar um question ário no Moodle.

Sendo um software open-source e havendo uma comunidade forte em volta deste, existe uma boa documentaç ão acerca do mesmo. No entanto, este software como soluç ão ao problema seria algo bastante complexo, pois para al ém de ter bastantes funcionalidades que n ão seriam usadas, envolve uma replicaç ão exaustiva da informaç ão presente no F énix (na p ágina da cadeira). Esta replicaç ão proveniente do F énix teria alguma alteraç ão, pois recordando que a funcionalidade dos question ários é exclusivo dos docentes, os delegados neste software teriam de ter um perfil de professores.

3.3 F ´enix

No que diz respeito ao F énix, este pode ser visto como um Moodle, mas com menos funcionalidades e uma comunidade menos ativa. O F énix apesar de n ão permitir a construç ão de question ários como o Google Forms ou o Moodle, tem uma ferramenta que tem um comportamento semelhante ao desejado – question ários à Qualidade das Unidades Curriculares do IST (QUC).

Os question ários QUC cumprem com parte dos requisitos desejados neste projeto, garantindo por exemplo a autenticaç ão, anonimidade, representatividade e a ades ão. Este é programado para durante um per´ıodo de tempo depois do fim do semestre, estar acess´ıvel aos alunos, sendo que estes s ão “obrigados” a preencher para se poderem inscrever no semestre seguinte. Para al ém desta “obriga-toriedade”, sempre que um aluno acede ao F énix, é relembrado com um pop-up para responder ao question ário, incentivando os alunos ao preenchimento.

Um dos problemas dos question ários QUC, é a flexibilidade de ediç ão, pois relembrando, n ão é um question ário como seria criado no Google Forms ou no Moodle, sendo o c ódigo escrito na plataforma e apresentado a alunos. A mudança no formato ou o editar do question ário seria algo bastante com-plexo. Para al ém disso, sendo uma plataforma que abrange toda a Universidade de Lisboa (UL), existe

(47)

todo um processo burocr ático complexo que complica a ediç ão de funcionalidades na plataforma ou o acrescentar de novas dentro da mesma.

Tal como as outras opç ões, este cumpre com algumas das funcionalidades desejadas, sendo im-portante de salientar que em termos de manutenç ão, mecanismos de lembretes/incentivos ao preen-chimento, a recolha de informaç ão para automatizaç ão é a melhor opç ão.

3.4 Resumo

Em suma, nenhuma das opç ões cumpre na totalidade os requisitos mencionados no cap´ıtulo2e, como tal, surge a necessidade de uma plataforma que v á de encontro ao desejado. Pretende-se, ent ão, recolher as melhores caracter´ısticas de cada opç ão e replic á-las (melhorando-as se poss´ıvel) de modo a cumprir o objetivo do projeto.

A Tabela3.1 é uma avaliaç ão perceptual, que se foca em alguns dos requisitos mais relevantes de modo a torn á-la menos exaustiva. No que diz respeito à automatizaç ão, manutenç ão, autenticaç ão, mecanismo de lembrete e divulgaç ão, o F énix é a melhor opç ão, enquanto que a construç ão de ques-tion ários, extraç ão e an álise das respostas o Google Forms é superior. O Moodle pode ser considerado um meio termo, mas tendo em conta todas as funcionalidades que tem, continua a ser uma soluç ão ”pesada”.

Google Forms Moodle F énix Criaç ão de question ários 3 2 0

Autenticidade 1 2 3

Anonimidade 3 3 3

Facilidade de obtenç ão de informaç ão para automatizaç ão 1 2 3 Divulgaç ão dos question ários 1 2 3

Mecanismo de lembrete 0 2 3

Facilidade de extraç ão de respostas 3 2 0 Sum ário das respostas obtidas 3 2 0

Manutenc¸ ˜ao 1 1 2

Tabela 3.1: Resumo das opç ões fase alguns requisitos mais relevantes. 0 – N ão garante; 1 – Garante mal; 2 –

(48)

(49)

4

Implementac¸ ˜ao

Conte ´

udo

4.1 Arquitetura do sistema . . . 33 4.2 Registo WebAPP/CAS . . . 38 4.3 Observac¸ ˜oes . . . 40

(50)

(51)

Neste cap´ıtulo é descrito o sistema que satisfaz a maioria dos requisitos que constam no cap´ıtulo2, sendo que aqueles que n ão s ão cumpridos, s ão no cap´ıtulo5abordados.

4.1 Arquitetura do sistema

Como referido no cap´ıtulo 2, na secç ão 2.3, esta plataforma ser á composta por 2 m ódulos. Cada m ódulo é composto pelo seu dom´ınio e serviços, que culminam na concretizaç ão dos casos de uso anteriormente ditos. A Figura4.1, mostra a organizaç ão por camadas da plataforma implementada.

Figura 4.1: Arquitetura em camadas da plataforma desenvolvida.

Por ordem ascendente (comec¸ando de baixo para cima), as camadas s ˜ao:

1. Django Framework1_{– Permite o desenvolvimento fullstack de aplicaç ões web, recorrendo à}

lin-guagem de programaç ão python. Este é respons ável pela persist ência da informaç ão na plata-forma, assim como parte da segurança da autenticaç ão (sendo a restante assegurada pelo CAS do IST) e da sanitizaç ão das respostas dadas, salvaguardando o bem-estar da base dados e da ferramenta. Possui ainda mecanismos de envio de emails, formaç ão de grupos com permiss ões de adicionar, ver, modificar e apagar elementos dos diversos dom´ınios e criaç ão de p áginas de apresentaç ão din âmicas (atrav és de Jinja e da p ágina administrativa);

2. Celery2 _{– Escalonador utilizado em projetos concebidos em Django, respons ´avel pelo}

agenda-mento e execuc¸ ˜ao das tarefas ass´ıncronas;

3. Fenix Python SDK3_{– Respons ável por aceder aos endpoints do sistema de informaç ão do IST}

(F ´enix);

1_{Docoumentaç ão: https://docs.djangoproject.com/en/2.2/} 2_{Documentaç ão: https://docs.celeryproject.org/en/stable/} 3_{https://github.com/FenixEdu/fenixedu-python-sdk}

(52)

4. GUC – M ódulo que permite a gest ão de utilizadores e conte údo. Mais detalhes na secç ão2.3.1; 5. GRQ – M ódulo que permite a gest ão de respostas e question ários. Mais detalhes na secç ão

2.3.2;

6. WebApp – Corresponde à camada de apresentaç ão, com a qual o utilizador interage. Esta é a

combinaç ão de p áginas administrativas com p áginas criadas de raiz de modo din âmico, recor-rendo a Jinja4e Bootstrap5.

Como referido no in´ıcio da enumeraç ão anterior, o processo de autenticaç ão da plataforma resulta num dividir de responsabilidades entre o Django e o CAS, sendo que a maior parte da responsabilidade

recai sobre o CAS. Sendo o CAS um mecanismo que permite a qualquer pessoa com um IST-ID6

v álido, usufruir dos serviços do IST (como por exemplo, email e F énix), este ser á respons ável, atrav és da Fenix Python SDK, garantir que se trata de uma pessoa do IST invocando o url de autenticaç ão. Caso o processo de autenticaç ão tenha sucesso, é de seguida criado um objeto User na base de dados, com informaç ão relativa ao utilizador7_{. A informaç ão recolhida neste processo diz respeito ao}

primeiro e ´ultimo nome, o seu IST-ID e o seu papel (aluno ou docente) dentro da faculdade.

Sendo o processo de autenticaç ão assegurado pelo CAS e sendo uma aç ão insegura e incorreta guardar a informaç ão de log in (IST-ID e palavra-chave), é criado no lado da aplicaç ão um ”remote user”8_{, sendo respons ável pela sess ão de utilizador na plataforma, com a informaç ão referida}

anteri-ormente. Consoante o papel do utilizador, é posteriormente criado um docente ou aluno, sendo de seguida acedido/preenchido o resto da informaç ão que é pedida na secç ão 4.2 (como por exemplo, plano curricular e curso).

Dado que um aluno ou um docente podem ter alteraç ões no seu plano curricular em qualquer ins-tante, como por exemplo, ficar a lecionar uma nova UC(docente ou aluno-docente), ou inscrever-se noutra UC (aluno), é necess ário consultar a informaç ão nos respetivos endpoints e atualiz á-la caso haja necessidade. Para que n ão seja atualizada constantemente a informaç ão sempre que um utiliza-dor faça log in, foi programado para que a cada 15 dias ap ós último log in, seja feita uma comparaç ão da informaç ão nos endpoints, com a que consta na base dados e caso seja d´ıspar, atualiz á-la. Esta vari ável encontra-se no ficheiro “choices.py”, com o nome “UPDATE DAYS”.

Relembrando os utilizadores que constam na secç ão2.3, n ão é feita a refer ência nem a funcion ários, nem aos alunos Alumni9. Uma vez que para o endpoint do aluno, ser Alumni é uma propriedade, n ão basta verificar se é aluno e recolher a informaç ão do mesmo. Caso este seja Alumni, é necess ário

4_{Gerador de templates usado no django - https://jinja.palletsprojects.com/en/2.11.x/}

5_{Framework utilizada para desenvolvimento de componentes da interface do frontend - https://getbootstrap.com/} 6_{Identificador ´unico atribu´ıdo a estudantes, professores e funcion ´arios da faculdade}

7_{Atrav ´es do endpoint https://fenix.tecnico.ulisboa.pt/api/fenix/v1/person} 8_{https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/}

(53)

redirecion á-lo e condicionar o seu acesso à plataforma, pois esta é uma plataforma para docentes e alunos que ainda estejam inscritos e frequentem a faculdade com UCs. Caso um funcion ário tente aceder à plataforma, este ser á igualmente redirecionado. Esta detalhe que pode visto como uma falha de segurança é encontrado em outras plataformas desenvolvidas para o IST, que apenas verificam se s ão alunos, como por exemplo a aplicaç ão de reservas do shuttle, possibilitando a Alumni usufruir das reservas.

No que diz respeito ao Fenix Python SDK, este foi pela última vez atualizado em 2015, tendo perma-necido com erros. De modo a que a arquitetura apresentada fosse execut ável, foi necess ário proceder à correç ão local deste SDK, tendo colocado os endpoints a aceder corretamente ao ano acad émico inserido, em vez de aceder sempre ao instante atual. Foi ainda corrigido a chamada a funç ões com os devidos par âmetros. Este problema surgiu duas vezes, uma durante a fase local e outra quando colocada a ferramenta em modo de produç ão. A correç ão ao SDK encontra-se num ficheiro .rar, em conjunto com o c ódigo. Do conjunto de endpoints existentes10_{estes foram os principais utilizados e os}

respetivos campos acedidos:

1. GET /degrees11_{- ’acronym’, ’name’, ’id’, ’academicTerm’, ’teachers’ e ’type’;}

2. GET /degrees/{id}12_{- ’teachers’ (’{id}’ refere-se ao id do curso);}

3. GET /degrees/{id}/courses13_{- ’acronym’, ’name’, ’id’ e ’academicTerm’ (’{id}’ refere-se ao id do}

curso);

4. GET /course/{id}/students14- ’enrolmentCount’, ’attendingCount’ e ’students’ (’{id}’ refere-se ao id da disciplina);

5. GET /person15_{- [PRIVADO] ’username’, ’name’ e ’institutionalEmail’;}

6. GET /person/curriculum16_{- [PRIVADO] ’start’, ’end’, ’degree’ e ’acronym’;}

7. GET /person/courses17_{- [PRIVADO] ’name’ e ’acronym’.}

10_{Lista dos endpoints: https://fenixedu.org/dev/api/} 11_{https://fenixedu.org/dev/api/#get-degrees} 12_{https://fenixedu.org/dev/api/#get-degreesid} 13_{https://fenixedu.org/dev/api/#get-degreesidcourses} 14_{https://fenixedu.org/dev/api/#get-coursesidstudents} 15_{https://fenixedu.org/dev/api/#get-person} 16_{https://fenixedu.org/dev/api/#get-personcurriculum} 17_{https://fenixedu.org/dev/api/#get-personcourses}

(54)

4.1.1 Gest ˜ao de Utilizadores e Conte ´

udo

Como referido previamente na secç ão2.3.1, este m ódulo/camada é respons ável pela gest ão/importaç ão da informaç ão relativa aos cursos, UCs, docentes e alunos. Atrav és dos endpoints enumerados ante-riormente, é poss´ıvel construir o dom´ınio principal da plataforma, obtendo-se o diagrama em Unified Modeling Language (UML) [3] conforme a Figura4.2.

Na Figura 4.2. é poss´ıvel visualizar-se o que foi referido neste cap´ıtulo relativamente ao “remote user”, sendo apresentado na imagem como o objeto “DjangoUser”. Por sua vez este tem uma relaç ão “one-to-one” com o objeto “Person”, garantindo desta forma que uma pessoa (“Person”) aceda à plata-forma, se for um Aluno ou docente da comunidade doIST.

No papel de administrador, este é capaz de importar toda a informaç ão relativa aos cursos (“De-gree”) que existem noIST. Posteriormente, este pode importar todas UCs (“Course”), que s ão perten-centes aos respetivos cursos. É importante destacar que algumas UCs, s ão partilhadas entre cursos, tendo o mesmo nome e URL. Ou seja, a mesmaUC, pode pertencer a um ou mais cursos. Este as-peto faz com que n ão possa haver uma reaç ão de “cascade” quando eliminado um curso, pois aUC tem que se manter caso pertença a outro curso. Por esta raz ão, na Figura4.2 é vista a cardinalidade entre “Degree” e “Course” como zero ou mais, possibilitando deste modo a exist ência independente de ambos os objetos.

O objeto “Person” é respons ável por conter a informaç ão relativa ao primeiro e último nome, assim como o IST-ID. Como é observado na Figura 4.2, existe uma relaç ão de hierarquia, pois tanto um “Teacher”, como um “Student”, s ão “Person”.

Durante a conceç ão da plataforma, observou-se que um docente (“Teacher”), pode coordenar zero ou mais cursos, assim como um Curso (“Degree”), pode ter mais que um coordenador, algo que foi contra a modelaç ão inicial e resultou em problemas na primeira implementaç ão.

Um aluno (“Student”), est á associado a um conjunto de UCs ao qual est á inscrito, sendo vis´ıvel na Figura 4.2, pela ligaç ão representada por “Classes”. No entanto, uma vez que a plataforma ir á enviar emails aos alunos das UCs e estes podem n ão querer ser incomodados pelas notificaç ões da plataforma, estes podem ou n ão estar subscritos às notificaç ões, sendo que inicialmente, todos os alunos est ão subscritos a todas as UCs a que est ão inscritos.

Um aluno pode conter duas responsabilidades adicionais dentro doIST. Este pode ser um delegado (representado por um booleano) ou ser um aluno-docente. Caso este seja um aluno-docente, ter á uma relaç ão semelhante à dos docentes, referente às UCs que é respons ável, denominada “Teaching”.

Cada UC pode conter ou n ão elementos de avaliaç ão (“Evaluation”). Quando esta tem um ele-mento de avaliaç ão, é automaticamente criado um question ário correspondente ao tipo do eleele-mento de avaliaç ão. Na Figura 4.2, é poss´ıvel observar-se dois rect ângulos verdes, que dizem respeito a duas enumeraç ões, uma para o tipo de avaliaç ões que existem (“EvaluationType”) e outra para o estado do

(55)

question ário (“QuizStatus”). Acrescentado o estado de ”Finalizado”ao restantes estados referido na secç ão 2.1.2, no que diz respeito ao c ódigo, estes podem ser visto no ficheiro ”choices.py”, vari ável ”QUIZ STATES”. A restante modelaç ão é melhor explicada na secç ão4.1.2.

4.1.2 Gest ˜ao de Respostas e Question ´arios

Como referido na secç ão2.3.2, este m ódulo permite a gest ão dos v ários elementos de avaliaç ão e consequentemente a gest ão dos diversos question ários. Nesta camada é feita uma relaç ão com os objetos “Evaluation” e “Quiz” presentes no m ódulo QUC, permitindo deste modo a realizaç ão dos casos de uso presentes na Figura2.2.

´

E de salientar que o objeto “Quiz” n ão tem um tipo associado, isto é, por exemplo, n ão é um ques-tion ário do tipo exame ou projeto. Este, est á associado ao objeto “Evaluaques-tion”, que por sua vez tem um tipo associado. O objeto “Quiz” contem informaç ão relativa ao estado do question ário, alunos que devem responder (sendo todos os alunos inscritos à disciplina) e a data de quando alterar o seu estado para “Fechado”. O tipo associado ao elemento de avaliaç ão, influ ência a resposta dada ao question ário, sendo neste caso respons ável pelos objetos “BasicAnswer” e “SpecificAnswer”. O objeto “BasicAnswer” é respons ável por recolher a informaç ão relativa ao curso do aluno, n úmero de inscriç ões, e se partici-pou ou n ão naquele elemento de avaliaç ão. Caso tenha participado no elemento de avaliaç ão, é ent ão apresentado as quest ões relevantes para cada tipo de elemento de avaliaç ão, ficando a cargo do ob-jeto “SpecificAnswer”, recolher essa informaç ão. De momento, os tipos de avaliaç ão e as respetivas perguntas s ão:

1. Teste:

(a) Tempo Suficiente;

(b) Perguntas relacionadas com as pr ´aticas/te ´oricas; (c) Erros no enunciado;

(d) Coment ´arios. 2. Laborat ´orios:

(a) Tempo investido por mim; (b) Tempo investido pelo grupo; (c) Nota esperada;

(d) Tempo de laborat ório suficiente; (e) Tempo de laborat ório útil/produtivo;

(56)

(g) Coment ´arios. 3. Projetos:

(a) Tempo investido por mim; (b) Tempo investido pelo grupo; (c) Nota esperada;

(d) Pontos fortes; (e) Pontos a melhorar;

(f) Coment ´arios.

Os ficheiros respons áveis pela implementaç ão dos respetivos formul ários e os dom´ınios das per-guntas, s ão respetivamente “forms.py” e “choices.py”. A criaç ão de novos tipos de elementos de avaliaç ão e os seus respetivos question ários, é simples, havendo apenas a necessidade de criar a base de dados para o novo tipo e modificar/acrescentar alguns aspetos que se encontram no Anexo Adeste documento. Devido ao facto de o Django ser fullstack, recorrendo ao Jinja e ao bootstrap, a parte de visualizaç ão/apresentaç ão do formul ário n ão requer muita atenç ão. Com tudo, estes detalhes encontram-se no anexo mencionado.

4.2 Registo WebAPP/CAS

Como referido na secç ão4.1, o CAS é respons ável por garantir a autenticidade do utilizador que acede a aplicaç ão. Para que seja poss´ıvel usufruir deste serviço, é necess ário registar a aplicaç ão web no F énix.

Para registar a aplicaç ão no F énix, ap ós realizar log in, deve: 1. Aceder ao separador “Pessoal”18_;

2. Nas opç ões do lado esquerdo (final da p ágina em modo compacto), selecionar “Gerir Aplicaç ões”; 3. De seguida clicar na opç ão “Criar”, surgindo um pop-up como o da Figura4.3. Neste deve indicar o nome da aplicaç ão, uma breve descriç ão da aplicaç ão, o URL para redirecionar (em modo desenvolvimento e caso n ão esteja alojado ser á http://localhost:8000) e por último selecionar a informaç ão que pretende aceder.

Ap ós o registo, é poss´ıvel ver detalhes do registo, onde ser á vis´ıvel informaç ão relativa ao “client id” e “client secret”, que é crucial para que possa ser usado a camada “Fenix Python SDK” e o CAS, uma

(57)

vez que o ficheiro “fenixedu.ini”, deve conter essa informaç ão. No fim o ficheiro “fenixedu.ini” deve ter ser semelhante à Listagem4.1.

O procedimento de registo e utilizaç ão do serviço CAS para autenticidade, s ão aspetos comum às outras teses de desenvolvimento de plataformas que requerem reconhecimento dos utilizador e acesso a Endpoints. Um exemplo do referido at é ao instante é o trabalho de mestrado realizado pelo colega Jorge Sim ão Madeira Cordeiro de Arag ão Goulart [2].

No caso da aplicaç ão desenvolvida, a informaç ão que é poss´ıvel ter acesso é:

(a) Gest ˜ao planos curriculares de alunos (b) Gest ˜ao de Delegados

(c) Pagamentos

(d) Informaç ão (e) Avaliaç ões

(f) Curricular

Dos acessos pedidos, a linha (b), n ão foi poss´ıvel aceder, pois ou n ão se encontra documenta ou n ão é de acesso publico. A informaç ão relativa à linha (c) e linha (e), seriam para tornar o ecr ã principal do aluno mais atrativo e informativo, sendo a informaç ão relativa ao pr óximo teste e a pagamentos em falta. Devido à falta de documentaç ão do que é acess´ıvel em cada “scope” (Figura4.3) n ão é clara a diferença entre linha (a) e a linha (f).

Listagem 4.1: Exemplo do conteudo do ficheiro ”fenixedu.ini”.

1 # O v e r w r i t e y o u r app c r e d e n t i a l s 2 3 [ f e n i x e d u ] 4 c l i e n t _ i d =# # # # # # # # # 5 c l i e n t _ s e c r e t =# # # # # # # # 6 r e d i r e c t _ u r i = h t t p :// l o c a l h o s t :8 0 0 0/ m a i n _ p a g e / 7

8 # C h a n g e t h i s o n l y if you k n o w w h a t you're doing !! 9 [ D E F A U L T ]

10 b a s e _ u r l = h t t p s :// f e n i x . t e c n i c o . u l i s b o a . pt / 11 a p i _ e n d p o i n t = api / f e n i x /

(58)

4.3 Observac¸ ˜

oes

Como referido na secç ão 4.1, o Django possui mecanismos de envio de emails e de formaç ão de grupos com permiss ões de adicionar, ver, modificar e apagar elementos do dom´ınio. Para que fosse poss´ıvel o envio de email, foi necess ário configurar-se o backend de modo a enviar emails recorrendo a SMTP19. Esta configuraç ão fez com que fosse criada uma conta gmail (ist.delegados@gmail.com) para o envio dos emails. No entanto, a forma como é enviado o email, faz com que caso um aluno faça responder, este envie um email para o delegado e n ão para email criado. Os templates de email enviados encontram-se no ficheiro “templates mails.py”.

No que diz respeito à formaç ão dos grupos e as suas permiss ões, é importante que quando insta-lada a ferramenta, sejam criados os seguintes grupos, com as respetivas permiss ões:

1. Delegados

(a) GRQ — Gestor de Avaliaç ão — Can view manage evaluation (b) GRQ — Gestor de Question ário — Can change manage quiz (c) GRQ — Gestor de Question ário — Can delete manage quiz (d) GRQ — Gestor de Question ário — Can view manage quiz (e) GUC — evaluation — Can change evaluation

(f) GUC — quiz — Can change quiz 2. Docentes

(a) GRQ — Gestor de Question ´ario — Can view manage quiz

Como referido na secç ão4.1.1, reforçado na secç ão4.1.2 e vis´ıvel na Figura4.2, o objeto “Quiz” é associado a um conjunto finito de estados (Figura4.4). Consoante o estado em que o question ário se encontra, como referido no cap´ıtulo2, existe um conjunto de operaç ões associado. Este comporta-mento é semelhante ao comportacomporta-mento associado ao padr ão de desenho “State” [3, p. 353], uma vez que objeto tem certos comportamentos diferentes, quando o seu estado interno é alterado.

(59)

(60)

(61)