|
|
|
|
Blog sobre as reflexões dos projectos
[ Dezembro |
Novembro |
Outubro |
Setembro ]
- 2004/12/11 - O Projecto do Editor de Horários
- Volto ao tema porque há pessoas que só pensam nas coisas em cima do teclado. Tempo para os utilizadores e concepção é coisa que não usam! E depois vêm as confusões e perguntas como "Tenho que por todos os horários do 2º ao 4º ano?! Que é que eles pensam que ando a fazer?"
Se se lembrassem da vossa experiência pessoal e falassem com colegas com cadeiras em atraso veriam que existem dois tipos de problemas:
1) Os horários são uma manta de retalhos e pode-se arranjar um horário melhor combinando horas de cadeiras de duas turmas (ex.: manhã de 2a feira livre, nada de aulas à 6a feira). Isto quer dizer: dois horários diferentes do 4º ano para demonstrar o projecto.
2) Incompatibilidades de horários para quem tem cadeiras em atraso do 2º e do 3º (não me digam que não arranjam casos reais de colegas vossos que tiveram que deixar de lado uma cadeira por causa disto). Para o demonstrador, isto quer dizer: dois horários diferentes do 2º ano, mais dois diferentes do 3º ano.
JMBL (regressar ao topo)
- 2004/12/11 - Projectos - Lendas que Correm de Boca em Boca
- Hoje chegaram-me notícias de lendas que andam a correr de boca em boca. Que foram obrigados a isto, que não se deve fazer aquilo, etc.
Pois é, há muita coisa a correr sem o mínimo fundamento.
A regra para ter a certeza é só uma: perguntem-me.
Vem isto a propósito do que alguém me escreveu sobre um dos projectos não poder ser uma aplicação que se instala e corre num PC por devaneio do corpo docente. Mais concretamente, o editor de horários não deve ser uma aplicação autónoma. Porquê? Por duas razões:
1) Porque é um dos requisitos que surge logo que se faça uma análise minimamente cuidada sobre os dados, sua persistência e localização. Os dados não existem do lado do cliente mas sim remotamente num único local e são modificados semestralmente. Há então que tornar transparente ao utilizador a sua transferência.
2) As soluções que irão ser apresentadas pelos vários grupos destinam-se a serem analisadas e comparadas para se fazer um editor de horários para o Fénix. Isto significa que se esperam soluções operando sobre a WWW. Uma solução com outra filosofia não serviria para nada a não ser para deitar fora, o que, convenhamos, seria pouco encorajador para quem a concebesse.
JMBL (regressar ao topo)
- 2004/11/19 - Entrega dos Projectos
- Além da entrega do relatório em papel, a entrega dos projectos compreende a entrega de um CD onde deve estar o projecto pronto a executar e as respectivas fontes.
Idealmente, deverá ser possível executar o projecto a partir do CD sem ter que copiar ficheiros ou instalar qualquer produto.
Para o caso de ser necessário copiar para disco rígido (o projecto escreve ficheiros, p. ex.) ou ter que ser instalado, no CD deve estar um manual de instruções completo.
O manual de instruções de instalação e operação deve admitir que nenhum produto necessário à utilização do projecto se encontra na máquina onde o projecto vai ser executado.
O manual deve dar instruções claras como deve ser utilizado o projecto e ainda as instruções para a sua instalação e de todos os produtos necessários para que o projecto seja executado.
Os instaladores de tais produtos deverão ser fornecidos no CD ou, em alternativa, o manual explicará como podem ser obtidos.
Finalmente, o manual de instruções de instalação e operação será uma das componentes da avaliação do vosso trabalho.
JMBL (regressar ao topo)
- 2004/11/05 - Testes Formais de Usabilidade
- A aula 7 de laboratório parece que não se enquadra na sequência de aulas de laboratório dedicadas ao projecto. Parece, mas não é!
O vosso projecto tem que especificar testes de usabilidade formal derivados dos requisitos e com eles especificados. Os testes têm que ser realizados no final para aquilatar da efectiva realização dos objectivos e contam para a classificação do projecto.
JMBL (regressar ao topo)
- 2004/11/04 - Requisitos...
- Sobre requisitos há muito que se pode dizer. A velha classificação em funcionais e não funcionais é, como digo, velha, e pouco adequada a sistemas interactivos. Nestes há que contar com os dos utilizadores, de dados, de ambiente e funcionais. Esta nova classificação permite isolar e identificar melhor os requisitos e está a ser dada nas aulas teóricas.
Portanto: se alguém aparecer só com funcionais e não funcionais vai suar nas discussões do projecto. É uma promessa.
Alguns de vocês obtiveram resultados interessantes nos inquéritos que fizeram.
Já agora, fizeram também observações e entrevistas? Associaram utilizadores aos vossos projectos? Lembrem-se da promessa acima.
Mas sobre inquéritos, sei que houve respostas interessantes que dão em requisitos para além do que é realizável no espaço de tempo que têm para realizar os projectos. Lembrem-se do Word. Embora a MS tivesse ideia do que haveria a fazer no futuro, não implementou logo tudo e foi evoluindo de versão em versão.
JMBL (regressar ao topo)
- 2004/10/22 - Bases de Dados: só para perder tempo...!
- Há umas pessoas que andam a pensar em usar bases de dados! Porquê complicar? O que nos interessa é demonstrar a facilidade da funcionalidade interactiva.
Um ficheiro de texto é uma base de dados simples que nos permite demonstrar os casos de uso! Isto quer dizer: não esqueçam o UML e que no "ralatório" final eles lá têm que estar com os diagramas de sequência, sem esquecer os testes de usabilidade formal e os respectivos resultados e sua análise.
JMBL (regressar ao topo)
- 2004/10/21 - O blog, projectos, enunciados, etc.
- Vamos começar este blog para ir dando as nossas reflexões sobre os projectos, CCU e tudo o que estiver à volta deles.
A primeira coisa tem a ver com o ar muito vago dos enunciados dos projectos. É de propósito: a especificação concreta de cada projecto tem que depender do que for obtido dos contactos com os utilizadores (observação dos utilizadores ao realizarem as tarefas, entrevistas, inquéritos, registos existentes como relatórios ou diários, etc.)
A segunda reflexão que vos deixo hoje refere-se à construção de diálogos para serem visualizados por um navegador (browser). Para chegar a todos os utilizadores ou clientes de uma empresa, não se pode obrigá-los a empregar um único navegador, pois há muita gente que não emprega o IE mas sim navegadores como o Netscape, Mozilla e Opera.
Isto só quer dizer uma coisa: todo o código empregue (HTML, JavaScript, Flash, etc.) tem que ser absolutamente standard e há que testar em todos aqueles navegadores para ter a certeza de que não há desvios.
JMBL (regressar ao topo)
|
|
| |
|
