REQUISITOS FUNCIONAIS +
REFLEXÃO VIABILIDADE TÉCNICA ____________________
YMT
DeCA | NTC | ANO3 | PROJECTO NTC SEM2
REQUISITOS FUNCIONAIS
1. Paradigma de interacção
i. Navegação horizontal / vertical entre botões ii. Atalhos cromáticos ou por números
iii. Introdução de pins numéricos
2. Criação do canal YMT (agulhagem do URL para um canal da plataforma IPTV)
3. Criação de uma conta e/ou introdução de login de utilizador i. Introdução do nome (username)
ii. Introdução do pin numérico (optativo)
iii. Selecção do avatar a partir de um banco de dados com imagens prédefinidas (conteúdos enviados para o Sapo Fotos pelos administradores catalogados como avatares)
iv. Introdução do género v. Introdução da idade
4. Selecção de um ambiance dentro de uma lista de ambiances pré-definidos (menu) i. Selecção de um ambience (art, dinner, party, sport...)
5. Personalização de um ambiance com base nos prédefinidos
i. Escolha de “sub-ambiances” (para cada um, escolher ambiances mais específicos: por exemplo, dentro do ambiance party, poder escolher
disco, lounge, etc.)
6. Selecção das definições de visualização dos ambiances
i. Escolha dos media types que se pretendem visualizar (apenas fotos, apenas vídeo, audio, etc.) através de check boxes
ii. Escolha da duração do ambiance
7. Criação de uma galeria personalizada de ambiances
i. Adição a uma galeria pessoal do conteúdo que está a ser visualizado, através de um botão na interface ou no telecomando
ii. Reprodução dos conteúdos adicionados
iii. Eliminar selectivamente os conteúdos adicionados
8. Galerias partilhadas por utilizador
i. Visualizar as galerias partilhadas por outros utilizadores ii. Atribuição de um rating às galerias partilhadas
iii. Registo automático do número de acessos a cada galeria
iv. Ordenar as galerias partilhadas por ordem de rating ou número de visualizações
9. Biblioteca de moods
i. Listagem de todos os ambiances da aplicação (de modo a proporcionar ao utilizador uma visão geral de todos os ambiances disponíveis)
Notas:
No ponto 4, idealizou-se a criação de um menu em forma de cubo, a partir do qual se poderão seleccionar os ambiances pré-definidos gerais, isto é, sem especificar nenhum
sub-ambiance. Esta selecção será feita através das setas direccionais em cada face
visível do cubo, girando o cubo para a face com o ambiance correspondente.
A ideia do cubo surgiu também com o intuito de conferir uma possível identidade visual à aplicação (por exemplo, utilizando um cubo no logótipo ou como logo marca).
No ponto 5, caso o utilizador desejar especificar um dos ambiances gerais, poderá clicar na face correspondente do cubo sendo-lhe apresentado um menu, com os sub-ambiances respectivos (por exemplo, dentro do ambiance party, poderá escolher disco, lounge,
birthday, rave, etc.).
Decidiu-se incluir uma janela de preview, que carrega os conteúdos escolhidos, sendo possível fazer full-screen, se o utilizador assim o desejar.
Um dos objectivos seria adaptar o espaço desta janela, para funcionalidades diferentes, isto é, caso o utilizador pretenda visualizar, por exemplo, a biblioteca de ambiances ou a galeria, esse espaço seria ocupado para esse efeito.
Antes dos conteúdos serem carregados, o utilizador pode alterar as definições de visualização dos ambiances (ponto 6), nomeadamente o tipo de media (vídeo, imagem, som) e duração de cada imagem/vídeo.
Nos pontos 7 e 8, de modo a potencializar a interacção entre utilizadores, optou-se por incluir uma galeria de ambiances, à qual o utilizador pode adicionar cada um dos conteúdos, assim que os vai visualizando. Desta forma, poderá criar playlists personalizadas e partilhá-las com outros utilizadores.
Através da visualização de outras galerias é sempre possível atribuir um rating, que posteriormente permitirá classificá-las e ordená-las.
No ponto 9, no sentido de permitir ao utilizador, uma listagem de todos os ambiances e
sub-ambiances da aplicação, decidiu-se incluir uma biblioteca, onde todos eles estarão
descritos, de modo a proporcionar uma visão geral dos ambiances (à semelhança de sites onde aparecem todas as tags disponíveis).
VIABILIDADE TÉCNICA (ANÁLISE DA TABELA)
Para proceder ao estudo da viabilidade técnica do projecto, foi necessário primeiro olhar para a lista de requisitos funcionais, e perceber de que forma se poderiam agrupar e organizar os diferentes requisitos em função das tecnologias que requerem.
Após esta avaliação prévia e, seguindo as indicações fornecidas, desenvolveu-se este estudo com base numa tabela de viabilidade, onde se destacam dois grandes grupos: » Criação de uma conta; introdução login utilizador; biblioteca de moods
» Selecção e personalização de ambiances; definições de visualização; criação e partilha de galeria
Ainda que estes sejam os dois principais grupos, existe um terceiro, onde se estudaram as tecnologias que são comuns a todos os requisitos funcionais:
» Software » Hardware » IDE’S
Dentro de cada um destes grupos, especificaram-se as tecnologias necessárias para a implementação dos seus requisitos, assim como as diferentes possibilidades que existem para o fazer.
O estudo foi desenvolvido atendendo aos prós e contras de cada possibilidade (excepto quando a implementação está limitada a uma única tecnologia/recurso), que foram cuidadosamente avaliados de forma a ser escolhida a opção mais adequada a cada situação do projecto.
A tabela está organizada utilizando grupos de cores, que dizem respeito a tecnologias da mesma categoria.
Após uma breve contextualização da forma como se processou este estudo, será dado seguimento à justificação das opções que estão devidamente representadas na tabela de viabilidade.
Em primeiro lugar, justificar-se-ão as decisões relativas ao grupo que abrange todos os requisitos funcionais e que, como tal, representa grande parte da base em que se assenta este projecto.
Tanto o hardware como o software foram pontos em que não existiu grande margem de manobra para tomar decisões, na medida em que a proposta de desenvolvimento deste projecto é muito específica nesse aspecto. No que diz respeito a hardware, a aplicação irá assentar sobre uma set-top box da MEO, e é a partir dela que o utilizador irá navegar. A este nível, para o desenvolvimento do projecto, será igualmente necessário o servidor onde estará alojada a aplicação. As opções são Microsoft Server e Linux Server, tendo sido seleccionada a primeira.
Ao nível do software, mais uma vez estaremos restringidos ao software presente na set-top box que irá ser utilizada. A set-set-top box corre sobre o sistema operativo (middleware) Microsoft Mediaroom, e é sobre ele que correm as funcionalidades desta. Outro ponto importante do software, é o browser disponibilizado nestas caixas, que se dá pelo nome de Tasman, e que é algo limitado ao nível de suporte de linguagem de marcação HTML, e também ao nível das tecnologias que suporta. Por fim, é importante referir que como nem sempre será possível o acesso a uma set-top box, a maior parte do trabalho irá ser desenvolvido no simulador do Mediaroom. Para finalizar este tópico é necessário ainda
expor que, ao nível de IDE’s (integrated development environment) a nossa escolha recaiu sobre o Dreamweaver por ser a ferramenta mais familiar aos elementos do grupo e com maiores potencialidades
Olhando agora para o primeiro grupo de requisitos funcionais (criação de uma conta; introdução login utilizador; biblioteca de moods), pode observar-se a sua divisão em três áreas de implementação diferentes: linguagens de programação (client-side, server-side, estruturação/formatação), bases de dados e frameworks.
Começando por abordar as linguagens de programação client-side, neste ponto, apenas se indicaram duas opções: Javascript e Actionscript. Aqui, facilmente se escolheu o Javascript, uma vez que nos oferece todos os recursos necessários e, ao mesmo tempo, é uma linguagem que já é do conhecimento de todos os elementos do grupo. Uma vez que Actionscript, apesar das suas elevadas potencialidades, não é suportado pela set-top box, descartou-se essa possibilidade.
Em relação às linguagens server-side, deparamo-nos com várias possibilidades - PHP, ASP e JSP. Mais uma vez a decisão foi tomada tendo como factor preponderante a experiência dos membros do grupo com as tecnologias em questão. Como tal, optou-se pela primeira destas opções, pela razão já referida, mas também porque é uma tecnologia gratuita e open-source, existindo um maior número de pessoas a utilizá-la como ferramenta de desenvolvimento e, também, mais documentação de apoio. O ASP embora fosse uma forte alternativa, sobretudo pelo facto de ser desenvolvido pela Microsoft, o que no neste caso seria favorável na medida em que todo o trabalho vai ser desenvolvido com base no software Mediaroom, também da Microsoft, perde por ser uma tecnologia paga e não familiar aos elementos da equipa de trabalho.
Passando agora à estruturação/formatação, esta assenta em duas tecnologias que são incontornáveis no desenvolvimento web, o HTML, e o CSS. Em relação as estas tecnologias, é importante salientar mais uma vez, que o facto de estarmos a desenvolver uma aplicação para uma set-top box, é um factor altamente restritivo. A este nivel, o Microsoft Mediaroom apenas suporta X-HTML 1.0 Strict, CSS1.0, e CSS 2.1.
Relativamente à tabela das bases de dados optou-se por incluir três possibilidades diferentes: MySQL, Access e MS SQL.
As duas últimas opções, apesar de serem tecnologias Microsoft, o que seria uma vantagem na realização deste projecto, não são gratuitas nem tão familiares ao grupo. Por outro lado, no MySQL, para além do elevado à vontade com a tecnologia, é open source e gratuito, o que contribuiu fortemente para ter sido escolhido como a opção mais viável.
Quanto às frameworks, apenas dizem respeito a javascript, uma vez que será a única linguagem na qual se irá recorrer às mesmas. Assim sendo, optou-se pela biblioteca jQuery, devido ao elevado número de utilizadores, aplicações que recorrem a esta framework e ainda pelo facto de já ter sido utilizada noutros trabalhos.
No segundo grupo de requisitos funcionais (selecção e personalização de ambiances; definições de visualização; criação e partilha de galeria) existem algumas particularidades no que toca à viabilidade técnica.
Como se pode observar na tabela, introduziram-se duas tecnologias na secção de linguagens: XML e SOAP. Apesar de não serem propriamente linguagens de programação e de não se inserirem no contexto preciso do HTML e CSS (daí a representação numa cor
ligeiramente diferente), serão essenciais ao desenvolvimento da aplicação, principalmente no que toca à inclusão de webservices, que estão relacionados com estas suas tecnologias, por exemplo, no que diz respeito a pedidos e respostas dos mesmos.
Outra alteração neste segundo grupo de requisitos, é a inclusão dos Webservices, que são de extrema importância, pois estarão na base de funcionamento de toda a aplicação. Posto isto, optou-se pela utilização de webservices da Sapo, entre eles, as API’s videos e fotos.
Tendo em conta que um dos objectivos do projecto, já definido anteriormente, será utilizar as plataformas Sapo Videos e Sapo Fotos para ir buscar todo o conteúdo visual da aplicação (fotografias, imagens, vídeos), estas duas API’s reunem tudo o que é necessário para essa função, uma vez que são webservices Sapo.
Apesar das duas outras API’s apresentadas na tabela serem extremamente versáteis e úteis, tanto estão relacionadas com linguagens de programação que não são dominadas pelo grupo (Youtube Data API), como são direccionadas para utilizadores principiantes, apenas permitindo inserir a API no site, não entrando profundamente na programação (Ajax Video). Por isso, não constituem opções viáveis.
