Conclus ˜ oes
6.2 Trabalho futuro
Conclus ˜oes
Conte ´udo
6.1 Resumo . . . 59
Neste cap´ıtulo ´e feita uma s´ıntese dos cap´ıtulos abordados, culminando num conjunto de observac¸ ˜oes sobre a execuc¸ ˜ao desta tese e o que pode ser feito em trabalhos futuros.
6.1 Resumo
Como referido no cap´ıtulo1, dada a organizac¸ ˜ao doIST, a ambiguidade na comunidade acad ´emica sobre a equival ˆencia de 1ECTSem horas, a necessidade de recolher informac¸ ˜ao relativa ao n ´umero de horas investidas pelos alunos nos elementos de avaliac¸ ˜ao e os problemas associados `a forma como ´e recolhida atualmente, confirma a necessidade de existir uma ferramenta como a que foi desenvolvida nesta tese, cumprindo com os requisitos que surgem no cap´ıtulo2.
Com base nos requisitos presentes no cap´ıtulo2, concebeu-se uma an ´alise presente no cap´ıtulo 3, sobre as poss´ıveis tecnologias atuais, que permitem realizar o pretendido, com os seus pr ´os e contras (Tabela3.1com a comparac¸ ˜ao das ferramentas). Dada a peculiaridade da ferramenta devido aos requisitos, confirmou-se que esta ferramenta teria de ser concebida de raiz, por n ˜ao haver uma ferramenta que fizesse tudo que se pretendia no cap´ıtulo2.
O Cap´ıtulo4 descreve a implementac¸ ˜ao da ferramenta, recorrendo a Django com a FenixAPI em python, para o backend, e, para o frontend, Jinja com bootstrap. Neste cap´ıtulo n ˜ao s ´o ´e feita uma descric¸ ˜ao do dom´ınio do problema, recorrendo a diagramas UML, que demonstram como est ˜ao relacio-nados os objetos, como tamb ´em, ´e explicada a arquitetura desenvolvida do problema. Focando apenas na arquitetura geral da ferramenta, comec¸ando pela camada mais abaixo, todo o servic¸o de login e gest ˜ao de autenticac¸ ˜ao ´e feita pelos sistemas CAS do IST, sendo feita apenas a chamada do mesmo, n ˜ao ficando qualquer informac¸ ˜ao de utilizadores e passwords no sistema. O acesso `a informac¸ ˜ao ne-cess ´aria para o sistema (cursos, disciplinas, informac¸ ˜ao dos utilizadores), ´e feita atrav ´es da FenixAPI em python, que acede aos endpoints, recebendo um dicion ´ario com a informac¸ ˜ao que ´e depois tratada para construir os objetos necess ´arios. Esta informac¸ ˜ao ´e inserida no sistema desenvolvido em Django, encarregue da persist ˆencia do sistema e gerida pelos m ´odulos presentes na ferramenta. Esta modu-laridade da implementac¸ ˜ao em conjunto com a documentac¸ ˜ao feita nesta tese, no c ´odigo e do pr ´oprio django, fazem a aplicac¸ ˜ao expans´ıvel, com um grau de dificuldade reduzido. Existe ainda no dom´ınio do django, um escalonador ass´ıncrono, respons ´avel pelo agendamento das mensagens, assim como pela alterac¸ ˜ao dos estados dos question ´arios. ´E importante referir que existiram erros na API do F ´enix em python, que tiveram de ser corrigidos por mim. Foi ainda poss´ıvel durante experi ˆencias, reparar que houve anos em que a API devolvia cursos em duplicado. Dada este cen ´ario, a plataforma foi cons-tru´ıda para que caso se repita, existam dois cursos duplicados, tornando o identificador ´unico o URL do endpoint, e n ˜ao o nome do curso.
ainda s ˜ao feitos coment ´arios face ao sucesso da aplicac¸ ˜ao, dada as m ´etricas definidas no projeto. Em suma a aplicac¸ ˜ao pode considerar-se como um sucesso, pois cumpriu com a grande maioria dos requisitos que eram impostos, sendo que aqueles que n ˜ao foram cumpridos foi devido `a impossibilidade de aceder `a informac¸ ˜ao necess ´aria para realizar o requisito. Os dados e os requisitos que foram ou n ˜ao cumpridos (juntamente com os motivos), podem ser vistos nas Figuras5.1e5.2e nas Tabelas5.1,5.2 -5.4,5.5e5.6. No que diz respeito `a experi ˆencia com utilizadores, conclui-se que ´e necess ´aria uma breve explicac¸ ˜ao, pois nem sempre ´e intuitiva para todos os utilizadores, mas concretamente com os delegados, que t ˆem mais funcionalidades, do que os alunos normais.
Em suma, o desenvolvimento desta aplicac¸ ˜ao foi um sucesso, sendo poss´ıvel confirm ´a-lo atrav ´es do n ´umero de requisitos cumpridos e dos resultados da interac¸ ˜ao dos utilizadores. Embora algumas adversidades surgidas durante a implementac¸ ˜ao, foi poss´ıvel terminar a tese com um produto, que se encontra alojado nos servidores da RNL, estando operacional at ´e ao momento. Foi inclusive, testado num cen ´ario real, no 1º Semestre do ano letivo 19/20, tendo a plataforma um comportamento conforme o esperado, com excec¸ ˜ao de problemas surgidos nos servidores, que n ˜ao dizem respeito `a tese/produto.
´
E importante salientar que o produto final, tornou-se mais relevante para os alunos, n ˜ao sendo apenas uma ferramenta para apoio aos delegados com question ´arios, mas sim, uma central para os outros servic¸os presentes no IST, sendo poss´ıvel aceder `a plataforma do Shuttle, aos email do IST e ainda contem um gerador de hor ´arios, tornado a plataforma, mais relevante.
6.2 Trabalho futuro
Uma vez que o produto se encontra em produc¸ ˜ao, ´e necess ´ario manter a ferramenta atualizada, n ˜ao s ´o no que diz respeito ao conte ´udo, como a poss´ıveis melhorias da interface ou a introduc¸ ˜ao de novos m ´odulos.
Um dos focos principais para trabalho futuro, ´e a conclus ˜ao da interface gr ´afica, no que diz respeito a outros acessos poss´ıveis atrav ´es da ferramenta. De momento encontra-se, tr ˆes espac¸os vazio, prepa-rado para ter 3 novos servic¸os que poderiam ser implementados, sendo eles “Reposit ´orios”, “Opini ˜oes” e “Procura shuttle”. No servic¸o “Reposit ´orios” seria o aglomerado dos v ´arios reposit ´orios que existem na comunidade do IST, que nem sempre s ˜ao do conhecimento de todos os alnos. Estes estariam orga-nizados pelos cursos, tornado a aplicac¸ ˜ao um foco para quem procura reposit ´orios de informac¸ ˜ao. No servic¸o “Opini ˜oes”, seria criar um modulo novo, semelhante a um trivago, onde era dado o feedback de todas UCs do ist, sendo poss´ıvel registar o ano do coment ´ario e o regente respons ´avel da altura. Desta forma os alunos conseguiam obter as opini ˜oes de algumas UCs, antes de as selecionar. Por ´ultimo, “Procura shuttle” seria um modulo novo, que saberia as pessoas que andam de shuttle e era capaz de interagir com estas, de modo a recolher informac¸ ˜ao sobre a posic¸ ˜ao atual do shuttle e partilh ´a-la
com a restante comunidade. Esta recolha de informac¸ ˜ao, podia ser feita pelo GPS do telem ´ovel, ou manualmente, de forma simples.
A ´ultima sugest ˜ao como trabalho futuro, envolve a criac¸ ˜ao de espac¸os publicit ´arios na aplicac¸ ˜ao, permitindo a criac¸ ˜ao de um fundo monet ´ario, com base nas pessoas que entram na aplicac¸ ˜ao e veem a publicidade e/ou clicam na mesma, sendo um comportamento semelhante em outras p ´aginas online com publicidade. Em termos legais, n ˜ao me pareceu ser incompat´ıvel com as regras do IST ou da RNL, nem ´e um uso ilegal das outras hiperligac¸ ˜oes presentes, uma vez que a aplicac¸ ˜ao redireciona para os criadores e em nenhum instante refere propriedade intelectual sobre esses, sendo apenas uma p ´agina de redireccionamento. Este fundo poderia ser usado para obras que fossem do interesse dos alunos e do departamento, ou para compra de material para os laborat ´orios, ou parte do fundo ser usado como pr ´emio para incentivar o uso da ferramenta no preenchimento de question ´arios.
Bibliografia
[1] M. Denscombe, The Good Research Guide: For Small-Scale Social Research Projects, 5th ed. Open University Press, 2014.
[2] J. S. M. C. de Arag ˜ao Goulart, “Sistema de gest ˜ao de informac¸ ˜ao do ipfn - gest ˜ao de recursos humanos e suporte inform ´atico,” Master’s thesis, Instituto Superior T ´ecnico, 4 2018.