1. Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
Manuel.Sequeira@iscte.pt, D6.02
As apresentações desta série baseiam-se nas apresentações disponibilizadas por Ian
Sommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e
finalmente por Manuel Menezes de Sequeira.

2. Na aula anterior

Desenho arquitectónico
 Decisões no desenho arquitectónico
 Organização de sistemas
 Estilos de decomposição
 Estilos de controlo
 Arquitecturas de referência
2009/2010
Engenharia do Software I
2

3. 2009/2010
Engenharia do Software I
3

4. Sumário

Desenho de interfaces com o utilizador
 Problemas de desenho
 Heurísticas de Nielsen para interfaces com





2009/2010
o utilizador
Estilos de interacção
Processo de desenho de interfaces com o
utilizador
Análise dos utilizadores
Prototipagem de interfaces com o utilizador
Avaliação de interfaces
Engenharia do Software I
4

5. Objectivos

Sugerir princípios gerais do desenho de
interfaces

Explicar
 Diferentes estilos de interacção e sua utilização
 Quando usar apresentações gráficas e textuais
de informação
 Principais actividades do processo de desenho
de interfaces

Apresentar atributos de usabilidade e
abordagens à avaliação de sistemas
2009/2010
Engenharia do Software I
5

6. A interface com o utilizador

Deve ajustar-se a competências, experiência
e expectativas de prospectivos utilizadores

Utilizadores muitas vezes julgam sistema pela
interface e não pela funcionalidade

Interface mal desenhada pode induzir
utilizador a erros catastróficos

Mau desenho leva muitos sistemas não serem
usados
2009/2010
Engenharia do Software I
6

7. Factores humanos no desenho
de interfaces
Memória de curta duração
limitada
Humanos recordam instantaneamente
cerca de sete itens de informação. Mais
informação, mais probabilidade de erro.
Humanos erram
Quando humanos erram e sistemas
falham, alertas e mensagens
inapropriados aumentam stress e, por
isso, probabilidade de novos erros.
Humanos são diferentes
Humanos têm grande gama de
capacidades físicas. Designers não
devem desenhar para si mesmos.
Humanos têm diferentes
Alguns preferem imagens, outros
preferências de interacção preferem texto.
2009/2010
Engenharia do Software I
7

8. Princípios do desenho de
interfaces com o utilizador

Desenho considera
necessidades, experiência e capacidades
de utilizadores

Designers cientes de limitações físicas e
mentais de humanos (e.g., memória de
curta duração limitada) e reconhecem que
humanos erram

Princípios subjazem a desenho de
interfaces, nem todos os princípios
aplicáveis a todos os desenhos
2009/2010
Engenharia do Software I
8

9. Princípios do desenho de
interfaces com o utilizador
Familiaridade
Usar termos e conceitos recolhidos da experiência
das pessoas que mais usarão sistema.
Consistência
Sempre que possível, operações comparáveis
activadas da mesma forma.
Mínima surpresa
Utilizadores nunca são surpreendidos pelo
comportamento do sistema.
Recuperabilidade Incluir mecanismos para utilizadores recuperarem
de erros.
Orientação
Disponibilizar informação quando erros ocorrem e
mecanismos de ajuda sensíveis ao contexto.
Diversidade
Proporcionar mecanismos de interacção para
diferentes tipos de utilizadores do sistema.
2009/2010
Engenharia do Software I
9

10. Familiaridade

Termos e conceitos recolhidos da
experiência das pessoas que mais usarão
sistema

Termos e conceitos orientados para
utilizador e não computacionais

Por exemplo, sistema administrativo deve
usar cartas, documentos e pastas e não
ficheiros, identificadores ou directórios
2009/2010
Engenharia do Software I
10

11. Consistência

Sempre que possível, operações
comparáveis activadas da mesma forma

Exemplos
 Comandos e menus com o mesmo formato
 Pontuação de comandos semelhante
 Utilização consistente de maiúsculas e
minúsculas
2009/2010
Engenharia do Software I
11

12. Mínima surpresa

Utilizadores nunca são surpreendidos
pelo comportamento do sistema

Se utilizador conhece efeito de um
comando, deve conseguir prever efeitos
de comandos comparáveis
2009/2010
Engenharia do Software I
12

13. Recuperabilidade

Incluir mecanismos para utilizadores
recuperarem de erros

Resiliência face a erros do utilizador
 Anular ou desfazer comandos
 Confirmação de acções destrutivas
 Remoções com possibilidade de
recuperação
2009/2010
Engenharia do Software I
13

14. Orientação

Disponibilizar informação quando erros
ocorrem e mecanismos de ajuda
sensíveis ao contexto

Disponibilização de orientação
 Sistemas de ajuda
 Manuais em linha
2009/2010
Engenharia do Software I
14

15. Diversidade

Proporcionar mecanismos de interacção
para diferentes tipos de utilizadores do
sistema

Alguns utilizadores têm dificuldades de
visão: disponibilizar texto com maiores
caracteres
2009/2010
Engenharia do Software I
15

16. Heurísticas de Nielsen
Visibilidade do
estado do sistema
Manter utilizadores informados acerca do que
está a acontecer através da disponibilização
atempada de informação.
Correspondência
entre sistema e
mundo real
Falar a língua do utilizador, usando palavras,
frases e conceitos familiares e não termos
orientados para o sistema. Seguir convenções
do mundo real, fazendo informação surgir de
forma natural e por uma ordem lógica.
Controlo e
liberdade do
utilizador
Dar aos utilizadores uma “saída de emergência”
para abandonarem estado do sistema no qual
entraram por engano. Não forçar o utilizador a
diálogo extenso para sair desses estados.
Suportar mecanismos para desfazer e refazer.
Consistência e
padrões
Não forçar utilizadores a pensar se diferentes
palavras, situações ou acções têm o mesmo
significado. Seguir convenções.
2009/2010
Engenharia do Software I
16

17. Heurísticas de Nielsen
Prevenção de erros Mostrar boas mensagens de erro e sobretudo
desenhar de forma a evitar ocorrência de
problemas. Eliminar condições propensas a
erros ou verificá-las e dar possibilidade de
confirmar antes de realizar acções.
Reconhecer em vez Minimizar recurso a memória do utilizador
de recordar
tornando visíveis objectos, acções e opções.
Não obrigar utilizador a recordar dados de uma
parte para outra de diálogo. Tornar instruções de
utilização visíveis ou fáceis de obter.
Flexibilidade e
eficiência de
utilização
2009/2010
Criar atalhos – invisíveis para utilizador iniciado
– que acelerem interacção de utilizador
experiente. Adequar sistema simultaneamente a
utilizadores iniciados e experientes. Permitir
configuração de acções frequentes.
Engenharia do Software I
17

18. Heurísticas de Nielsen
Desenho estético e
minimalista
Desenhar diálogos sem informação irrelevante
ou raramente necessária. Itens adicionais de
informação num diálogo competem com
unidades de informação relevantes e diminuem
a sua visibilidade relativa.
Ajudar a
reconhecer,
diagnosticar e
recuperar de erros
Exprimir mensagens de erro em linguagem
simples (sem códigos) precisando qual o
problema e sugerindo construtivamente uma
solução.
Ajuda e
documentação
Pode ser necessário disponibilizar ajuda e
documentação, apesar de ser preferível que o
sistema possa ser usado sem documentação.
Informação de ajuda e documentação deve ser
fácil de pesquisar, estar focada na tarefa do
utilizador e listar passos concretos a dar. Não
deve ser demasiado grande.
2009/2010
Engenharia do Software I
18

19. Dois problemas de desenho

Como disponibilizar ao sistema informação
vinda do utilizador?

Como disponibilizar ao utilizador
informação vinda do sistema?

Interacção com utilizador e apresentação
de informação podem ser integradas em
estrutura coerente (e.g., metáfora de
interface com o utilizador)
2009/2010
Engenharia do Software I
19

20. Estilos de interacção
Manipulação directa
 Selecção em menus
 Preenchimento de formulários
 Comandos
 Linguagem natural

2009/2010
Engenharia do Software I
20

21. Estilos de interacção
Estilo
Vantagens
Desvantagens
Manipulação
directa
Interacção rápida e
intuitiva; fácil aprender.
Difícil implementar; aplicável só se
tarefas e objectos têm metáfora
visual.
Selecção em Evita erros do utilizador;
Lento para utilizadores experientes;
• Controlo decom muitas opções é complexo.
Sistemas operativos.
stocks.
menus
pouca digitação. Jogos.dos sistemas de
Sistemas
Maioria de recuperação
•
• Gestão pessoal de
Sistemas de comando
de informação.
utilização geral.
• Sistemas CAD.
Formulários Introdução simplescontrolo. Ocupa muito ecrã; opções do
e de
empréstimos.
dados; fácil aprender;
utilizador podem não corresponder
verificável.
a campos.
Comandos
Poderoso e flexível.
Difícil aprender; gestão fraca de
erros.
Linguagem
natural
Acessível a utilizadores
ocasionais; fácil estender.
Muita digitação; pouca fiabilidade.
2009/2010
Engenharia do Software I
21

22. Múltiplas interfaces
Interface gráfica de
utilização (Gnome/KDE)
Interface de linha de
comandos (bash/ksh)
Gestor da interface
gráfica de utilização
do X Window System
Interpretador de
comandos
Sistema operativo Linux
2009/2010
Engenharia do Software I
22

23. Interacção LIBSYS
Pesquisa de documentos Utilizadores usam os mecanismos de
pesquisa para procurar os documentos de
que precisam.
Pedido de documentos
2009/2010
Utilizadores pedem a entrega de um
documento na sua máquina ou num
servidor para impressão.
Engenharia do Software I
23

24. Interfaces baseadas na
Web

Muitos sistemas baseados na Web têm
interfaces baseadas em formulários cujos
campos podem ser





Menus
Caixa de texto livre
Botões de rádio
Etc.
LIBSYS: Menu para escolher onde
pesquisar e caixa de texto para frase a
procurar
2009/2010
Engenharia do Software I
24

25. Formulário de pesquisa do
LIBSYS
LIBSYS: Pesquisa
Escolher colecção
Todas
Palavra ou frase
Procurar usando
Título
Palavras adjacentes
Pesquisar
2009/2010
Sim
Limpar
Engenharia do Software I
Não
Cancelar
25

26. Apresentação da
informação

Apresentação ao utilizador de informação
do sistema

Informação pode ser apresentada
 Directamente – Texto num processador de texto
 Transformada – Formato gráfico
Padrão de desenho.

Abordagem Modelo-Vista-Controlador
suporta múltiplas vistas dos mesmos
dados
2009/2010
Engenharia do Software I
26

27. Apresentação da
informação
Informação
a mostrar
Software de
apresentação
Ecrã
2009/2010
Engenharia do Software I
27

28. Modelo-vista-controlador
Entradas do
utilizador
Controlador
estado
métodos
Edições do
modelo
2009/2010
Mensagens de
modificação
da vista
Modelo
estado
métodos
Engenharia do Software I
Vista
estado
métodos
Interrogações e
actualizações
do modelo
28

29. Apresentação da
informação

Informação estática
 Inicializada no início de uma sessão
 Não muda durante uma sessão
 Pode ser numérica ou textual

Informação dinâmica
 Muda durante a sessão
 Mudanças têm de ser comunicadas ao
utilizador
 Pode ser numérica ou textual
2009/2010
Engenharia do Software I
29

30. Factores da apresentação da
informação

Utilizador interessa-se por informação precisa ou
relações entre dados?

Quão depressa mudam os valores da informação?
Alterações devem ser indicadas imediatamente?

Utilizador deve responder a alterações?

Há interface de manipulação directa?

Informação textual ou numérica? Valores relativos
importantes?
2009/2010
Engenharia do Software I
30

31. Apresentações alternativas da
informação
Jan. Fev. Mar. Abr. Mai. Jun.
2842 2851 3164 2789 1273 2835
4000
3000
2000
1000
0
2009/2010
Jan.
Fev.
Mar.
Abr.
Engenharia do Software I
Mai. Jun.
31

32. Apresentação analógica ou
digital?

Apresentação digital
 Compacta – Ocupa pouco espaço no ecrã
 Permite comunica valores precisos

Apresentação analógica
 Fácil ter ideia dos valores num relance
 Possível mostrar valores relativos
 Fácil ver valores excepcionais dos dados
2009/2010
Engenharia do Software I
32

33. Métodos de apresentação
1
4
2
0
3
Mostrador e
agulha
2009/2010
Gráfico em
queijo
Termómetro
Engenharia do Software I
10
20
Barra
horizontal
33

34. Mostrando valores relativos
Pressão
0
2009/2010
100
200
Temperatura
300
400
0
Engenharia do Software I
25
50
75
100
34

35. Visualização de dados

Grandes quantidades de informação

Revela tendências e relações entre entidades

Possíveis visualizações
 Informação meteorológica recolhida em vários locais
 Estado de rede como conjunto de nós ligados
 Fábrica como conjunto de tanques e tubos
mostrando pressões e temperaturas
 Modelo 3D de molécula
 Páginas Web como árvore hiperbólica
2009/2010
Engenharia do Software I
35

36. Ecrãs coloridos

Cor adiciona dimensão extra à interface

Ajuda a compreender estruturas
complexas de informação

Usada para destacar eventos
excepcionais
2009/2010
Engenharia do Software I
36

37. Erros comuns

Usar a cor para comunicar significado

Superabundância de cor no ecrã
2009/2010
Engenharia do Software I
37

38. Mau exemplo
2009/2010
Engenharia do Software I
38

39. Orientações para uso de cores
Limitar o número de cores
 Ser conservador
 Mostrar alterações de estado
 Suportar tarefas do utilizador com
código de cores
 Usar de forma pensada e consistente
 Cautela com emparelhamentos

2009/2010
Engenharia do Software I
39

40. Bom exemplo
2009/2010
Engenharia do Software I
40

41. Mensagens de erro

Bom desenho é crítico: más mensagens de
erro podem levar à rejeição do sistema

Devem ser





Educadas
Concisas
Consistentes
Construtivas
Formação e experiência dos utilizadores é
factor determinante no desenho
2009/2010
Engenharia do Software I
41

42. Factores na redacção de
mensagens de erro
Contexto
Reflectir contexto corrente do utilizador. Deve-se estar
ciente das suas acções e gerar mensagens relevantes.
Experiência
Mensagens longas e “cheias de significado” irritam
utilizadores experientes. Mensagens concisas não são
percebidas por utilizadores iniciados. Disponibilizar
ambas: utilizador controla grau de concisão.
Nível de
Adequar mensagens a competências e experiência do
competência utilizador. Conceber mensagens diferentes para tipos
de utilizador diferentes usando diferentes terminologias.
Estilo
Redigir mensagens de forma positiva. Usar a voz activa
e não a voz passiva. Não insultar nem tentar ter piada.
Cultura
Estudar culturas locais dos utilizadores. Há diferenças
culturais assinaláveis entre Europa, Ásia e os EUA:
mensagens adequadas numa cultura podem não o ser
noutra.
2009/2010
Engenharia do Software I
42

43. Erro do utilizador
Nome do paciente
Introduza o nome do
paciente:
Ximenes, Xisto
Assuma que um(a)
enfermeira(o) se
engana no nome do
paciente de cujo
registo necessita.
2009/2010
OK
Engenharia do Software I
Cancelar
43

44. Mau desenho: mensagem de
erro orientada para o sistema
Erro!
!
Erro 27
ID de paciente inválido!
OK
2009/2010
Engenharia do Software I
Cancelar
44

45. Bom desenho: mensagem de
erro orientada para o utilizador
Paciente “Xisto Ximenes” desconhecido
“Xisto Ximenes” não está registado como paciente.
Carregue em “Pacientes” para ver uma lista de pacientes.
Carregue em “De novo” para introduzir o nome de novo.
Carregue em “Ajuda” para obter mais ajuda.
Pacientes
2009/2010
Ajuda
De novo
Engenharia do Software I
Cancelar
45

46. Processo de desenho de
interfaces com o utilizador

É processo iterativo

Relações estreitas entre utilizadores e
designers

Três actividades centrais
 Análise do utilizador
 Prototipagem do sistema
 Avaliação da interface
2009/2010
Engenharia do Software I
46

47. Actividades centrais do
processo
Análise de utilizadores
Compreender o que os utilizadores irão
fazer com o sistema.
Prototipagem do sistema
Desenvolver uma série de protótipos para
realizar experiências.
Avaliação da interface
Fazer experiências com os protótipos
envolvendo os utilizadores.
2009/2010
Engenharia do Software I
47

48. Processo de desenho
Analisar e
compreender
actividades dos
utilizadores
Produzir
primeiro
protótipo
em papel
Avaliar
desenho com
utilizadores
finais
2009/2010
Avaliar
desenho com
utilizadores
finais
Protótipo
executável
Protótipo de
desenho
Produzir
protótipo
dinâmico
Implementar
interface com
o utilizador
final
Engenharia do Software I
48

49. Análise de utilizadores

Sem perceber o que utilizadores
pretendem fazer não é possível desenhar
interface eficaz

Análises descritas em termos que
utilizadores e designers possam entender

Cenários descrevendo casos de uso
típicos são forma de descrever análises
2009/2010
Engenharia do Software I
49

50. Cenário de interacção com o
utilizador
A Joana é aluna de Estudos Religiosos. Está a trabalhar num
ensaio sobre arquitectura indiana e sobre a forma como foi
influenciada pela prática religiosa. Para melhor compreender
o assunto, gostaria de aceder a fotografias de pormenores de
edifícios importantes. No entanto, não conseguiu encontrar
nada de relevante na sua biblioteca local.
Aborda o bibliotecário para discutir as suas necessidades.
Este sugere-lhe alguns termos de pesquisa. Também lhe
sugere algumas bibliotecas em Nova Deli e Londres que
talvez tenham o material desejado. Entram nos catálogos da
biblioteca e fazem pesquisas com esses termos. Encontram
algum material e fazem um pedido para serem enviadas
directamente à Joana fotocópias das fotografias com
pormenores arquitectónicos que encontraram.
2009/2010
Engenharia do Software I
50

51. Requisitos do cenário

Utilizadores podem não estar cientes de
termos de pesquisa mais apropriados

Precisam de ajuda na escolha dos termos

Têm de poder escolher colecções a
pesquisar

Têm de poder pesquisar e pedir cópias do
material relevante encontrado
2009/2010
Engenharia do Software I
51

52. Técnicas de análise
Análise de tarefas
Modelar os passos que completar uma
tarefa envolve.
Entrevistas e questionários
Perguntar aos utilizadores acerca do
trabalho que realizam.
Etnografia
Observar os utilizadores enquanto
trabalham.
2009/2010
Engenharia do Software I
52

53. Análise hierárquica de
tarefas
Obter imagens a
partir de bibliotecas
remotas
Fazer 1, 2 e 3 até imagens encontradas, 4
1
2
Descobrir
possíveis
fontes
Estabelecer
termos de
pesquisa
3
4
Pesquisar
imagens
Pedir fotocópias
dos itens
encontrados
Fazer 3.1, 3.2 e 3.3 até imagens encontradas, 3.4 se necessário, 3.5
3.1
Seleccionar
biblioteca
3.2
3.3
Autenticar
no catálogo
Pesquisar
imagens
3.4
Modificar
termos de
pesquisa
3.5
Registar
itens
relevantes
3.3.1, 3.3.2 e 3.3.3
3.3.1
2009/2010
Introduzir
termos de
pesquisa
3.3.2
Iniciar
pesquisa
Engenharia do Software I
3.3.3
Analisar
resultados
53

54. Entrevistas

Conceber entrevistas semi-estruturadas
baseadas em perguntas abertas

Utilizadores fornecem informação que
julgam essencial, e não apenas informação
que se previu recolher

Entrevistas de grupo e grupos foco
permitem a utilizadores discutirem entre si
o que fazem
2009/2010
Engenharia do Software I
54

55. Etnografia

Observador externo observa utilizadores
trabalhando e questiona-os sobre o seu
trabalho

Valor decorre de muitas tarefas serem
intuitivas e difíceis de descrever e explicar
pelos utilizadores

Ajuda a compreender papel de influências
sociais e organizacionais no trabalho
2009/2010
Engenharia do Software I
55

56. Registos etnográficos
O controlo do tráfego aéreo usa um determinado número de
„pacotes‟ em que os pacotes de controlo de sectores adjacentes do
espaço aéreo são fisicamente colocados lado a lado. Os voos num
sector são representados por tiras de papel enfiadas nas ranhuras
de um suporte de madeira por uma ordem que reflecte a sua
posição no sector. Se não houver suficientes ranhuras num suporte
(e.g., o espaço aéreo está muito intenso), os controladores
espalham as tiras na secretária em frente do suporte.
Enquanto observávamos os controladores, notámos que os
controladores olhavam regularmente para os suportes de tiras no
sector adjacente. Chamámos a atenção para este facto e
perguntámos-lhes porque o faziam. Responderam que, quando um
controlador adjacente tem tiras na sua secretária, há muitos voos
que se preparam para entrar no seu sector. Quando isso acontece,
eles tentam acelerar a velocidade das aeronaves no seu sector
para „fazer espaço‟ para os voos que para ele se dirigem.
2009/2010
Engenharia do Software I
56

57. Resultados da análise
etnográfica

Controladores têm de ver todos os voos
num sector: deve evitar-se visualizações
em que voos deslizem para fora do ecrã
(quer pelo topo, quer pela base)

Interface deve mostrar quantos voos
estão em sectores adjacentes de modo
a que controlador possa planear como
lidar com pico de esforço que se
aproxima
2009/2010
Engenharia do Software I
57

58. Prototipagem da interface com
o utilizador

Dar aos utilizadores experiência directa
com interface

Sem ela é impossível aferir usabilidade da
interface

Pode ser processo com duas etapas
 Inicialmente protótipos em papel
 Depois desenho é refinado e desenvolvem-se
protótipos automatizados com sofisticação
crescente
2009/2010
Engenharia do Software I
58

59. Prototipagem em papel

Estudar cenários usando esboços da
interface

Usar guião para apresentar série de
interacções com sistema

Eficaz para obter reacções dos
utilizadores a uma proposta de desenho
2009/2010
Engenharia do Software I
59

60. Técnicas de prototipagem
Com guião
Programação visual
Baseada na Web
2009/2010
Desenvolver conjunto de guiões e ecrãs usando
ferramenta como Macromedia Director. Quando
utilizador interage com ecrã, salta para próximo
ecrã.
Capítulo 17
Usar linguagem concebida para
desenvolvimento rápido como o Visual Basic.
Usar navegador Web e linguagens associadas
Engenharia do Software I
60

61. Avaliação de interfaces com o
utilizador

Necessária para aferir se desenho é
adequado

Avaliação completa muito cara e
impraticável para maioria dos sistemas

Idealmente interfaces avaliadas face a
especificação de usabilidade; mas é
raro serem produzidas especificações
2009/2010
Engenharia do Software I
61

62. Atributos de usabilidade
Apreensibilidade
Quanto demora um utilizador a se tornar produtivo
com o sistema?
Velocidade de
operação
Quão próxima está a resposta do sistema da
prática do utilizador?
Robustez
Quão tolerante é o sistema face a erros do
utilizador?
Recuperabilidade Quão bem recupera o sistema de erros do
utilizador?
Adaptabilidade
2009/2010
Quão preso está o sistema a um único modelo de
trabalho?
Engenharia do Software I
62

63. Técnicas de avaliação simples

Questionários ao utilizador

Gravação vídeo de utilização do sistema e
posterior avaliação

Instrumentação de código para recolher
informação acerca da utilização de
funcionalidades e da ocorrência de erros do
utilizador

Disponibilização de código para recolha em
linha de opiniões do utilizador
2009/2010
Engenharia do Software I
63

64. A reter

Princípios do desenho guiam desenho
de interfaces com utilizador

Estilos de interacção incluem
 Manipulação directa
 Sistemas de menu
 Preenchimento de formulários
 Linguagens de comandos
 Língua natural
2009/2010
Engenharia do Software I
64

65. A reter

Apresentações gráficas mostram tendências e
valores aproximados

Apresentações digitais mostram valores
precisos

Cor usada com parcimónia e consistência

Processo de desenho inclui
 Análise de utilizadores
 Prototipagem do sistema
 Avaliação da interface
2009/2010
Engenharia do Software I
65

66. A reter

Análise de utilizadores sensibiliza
designers para forma de trabalho efectiva
de utilizadores

Prototipagem é processo em etapas;
protótipos iniciais em papel base para
protótipos automáticos

Avaliação da interface informa como
melhorar desenho e afere cumprimento de
requisitos de usabilidade
2009/2010
Engenharia do Software I
66

67. A ler

Ian Sommerville, Software Engineering,
8.ª edição, Addison-Wesley, 2006
 Capítulo 16
2009/2010
Engenharia do Software I
67

68. A ver

useit.com: Jakob Nielsen's Website
2009/2010
Engenharia do Software I
68