O objectivo do projecto Central Participativa da Marca UA é, em termos gerais, criar um site/portal onde seja possível aprender sobre as normas de bem representar a marca. O conceito de experimentação é essencial para que os membros da Universidade de Aveiro possam aprender a relacionar-se com esta, de forma correcta e criativa. Os utilizadores registados (toda a comunidade da UA) podem partilhar os ficheiros criados, comentar, votar, sugerir actividades, criando assim toda uma comunidade em torno da marca.
Requisitos funcionais:
Para a elaboração dos requisitos funcionais, optou-se por construir uma tabela resumo para que, deste modo, haja uma percepção mais fácil dos mesmos.
Ao realizar a tabela, organizou-se a mesma tendo em conta:
· Áreas de conteúdos;
· Prioridades;
· Tipos de utilizador.
A distinção entre as diversas áreas é muito ténue (especialmente entre as áreas de criação e de avaliação) mas, por razões de estruturação da tabela, optou-se por realizar esta divisão.
Ao nível do tipo de utilizadores, irão existir quatro tipos:
· Utilizador não registado – tem apenas acesso à página inicial uma vez que a aplicação a desenvolver é apenas para membros da Universidade de Aveiro e apenas estes podem aceder à mesma;
· Utilizador registado – mais comum, qualquer membro da comunidade da UA;
· Utilizador validador – conhecedor das normas da marca da UA tem permissão para fazer validação de artefactos cuja validação não seja possível automaticamente;
· Utilizador administrador - detentor da capacidade técnica para editar qualquer área do site, quando autorizado a tal.
Tabela_Requisitos_funcionais.pdf
Optou-se por realizar uma lista um pouco mais extensa desses mesmos requisitos que decidimos colocar também aqui.
Vai existir uma página inicial à qual os quatro tipos de utilizadores têm acesso:
Sistema de login (username; password);
Download das normas da marca UA;
Download de ficheiros oficiais (galeria);
Merchandising;
Descrição da plataforma.
Após efectuar o login o utilizador registado e o utilizador administrador têm acesso à página principal onde haverá uma espécie de “hall de entrada” onde o utilizador tem quatro áreas à escolha:
Mesmo que o utilizador entre numa delas, estas vão estar sempre presentes no menu a qualquer altura.
Na área de orientação e informação o utilizador tem acesso:
Relativamente à area de criação, a aplicação tem:
Na área de avaliação iremos ter:
Estará sempre presente a possibilidade de logout para que os utilizadores possam sair da aplicação quando desejarem.
Requisitos não funcionais:
Segurança:
· O acesso é restrito apenas a membros da Universidade de Aveiro;
· Utilizaremos um API no login para a ligação á base de dados da UA, uma vez que esta deve ser protegida;
· Após X tempo sem interacção o sistema fazer o log out;
· Privacidade (http://www.w3.org/standards/webdesign/pr
Desempenho:
· Os ficheiros terão um limites de tamanho imposto pela aplicação para a optimização do sistema.
Usabilidade:
· Definir a língua original do site (português) e, se existirem, evidenciar claramente todas as ocorrências em outra língua;
· Usar tabelas que se adaptam e transformam graciosamente consoante o browser utilizado, garantindo o bom funcionamento independentemente do browser;
· Garantir que a página pode na mesma ser aberta e funcionar mesmo em browsers antigos ou com as funcionalidades desligadas, para isso criar uma versão em HTML que substitua, se necessário, as CSSs;
· Grandes blocos de informação serão divididos em partes mais pequenas para facilitar a leitura, uma vez que esses grandes blocos causam fadiga e promovem o desinteresse. Assim, este principio de usabilidade será utilizado para tornar mais acessível a leitura das normas de utilização da Marca UA ou, eventualmente, na Ajuda à ferramenta de desenho;
· Serão implementados mecanismos claros e concisos de navegação, tais como mapa do site, barra de navegação sempre visível e indicação da localização dentro do site.
Acessibilidade:
(http://www.w3.org/TR/1999/WAI-WEBCONTENT-1
· Providenciar alternativas em texto a imagens e sons ou, em contrapartida, providenciar imagens ou som a textos;
· Ter a certeza de que a cor de fundo e a cor de conteúdos são suficientemente diferentes de forma a que não sejam confundidas e possam ser tb percebidas por pessoas com dificuldades de visão, daltonismo, etc;
· Toda a informação disponível através da cor (ex: links acedidos e não acedidos, etc) deverá estar tb disponível sem cor, através do contexto ou de anotações;
·Assegurar que conteúdo que se move, pisca, faz scroll ou se actualiza automaticamente pode ser parado pelo utilizador, uma vez que pode ser distractivo ou mesmo impeditivo para certos utilizadores.
Confiabilidade:
· Privacidade (http://www.w3.org/standards/webdesign/pr
Hardware e Software:
· Computadores de trabalho com os softwares de escolha instalados.
Viabilidade técnica:
Após a realização da lista de requisitos funcionais e não funcionais é importante estudar quais as tecnologias necessárias para a implementação dos mesmo. Em anexo, encontra-se a tabela respectiva.
De seguida, efectuou-se uma análise de quais as tecnologias mais adequadas para os fins pretendidos.
A tabela segue em anexo.
Conclusões finais:
Após concluir este segundo módulo foi possível esclarecer algumas das dúvidas que o grupo tinha. Ficou mais clarificada a estrutura que se pretende para o site da Central Participativa da Marca UA, tal como os requisitos necessários para o seu funcionamento.
É importante focar o facto de ainda não ter sido decidido qual a plataforma ou programa mais adequado àquilo a que o projecto final se destina. A maior dúvida situa-se entre o Joomla e o Drupal, uma vez que o Wordpress só recentemente é que teve um grande desenvolvimento em termos tanto de programação como design, e por isso não há tanta informação disponível de forma a que esteja ao nível das anteriores. Após análise, foi possível concluir que ambas as plataformas têm características muito semelhantes e possuem muito módulos acessórios que podem ser utilizados para a maior parte do que o grupo pretende. A decisão final será tomada face à realização do próximo módulo, onde se terá que desenvolver uma demo. Nesta fase, ir-se-ão testar ambas as plataformas e ver qual se adequa melhor às necessidades do projecto e tirar-se-ão também as dúvidas referentes ao sistema de validação que é um ponto de grande importância na decisão final.
. Desenvolvimento do projec...
. Avanços
. Aula 01/06/11 - desenvolv...
. Versão beta - mapa de nav...