Manuel Menezes de Sequeira
DCTI, ISCTE-IUL
Manuel.Sequeira@iscte.pt, D6.02
As apresentações desta série baseiam-se nas apr...
Na aula anterior


Desenho arquitectónico
 Decisões no desenho arquitectónico
 Organização de sistemas
 Estilos de dec...
2009/2010

Engenharia do Software I

3
Sumário


Desenho de interfaces com o utilizador
 Problemas de desenho
 Heurísticas de Nielsen para interfaces com


...
Objectivos


Sugerir princípios gerais do desenho de
interfaces



Explicar
 Diferentes estilos de interacção e sua uti...
A interface com o utilizador


Deve ajustar-se a competências, experiência
e expectativas de prospectivos utilizadores

...
Factores humanos no desenho
de interfaces
Memória de curta duração
limitada

Humanos recordam instantaneamente
cerca de se...
Princípios do desenho de
interfaces com o utilizador


Desenho considera
necessidades, experiência e capacidades
de utili...
Princípios do desenho de
interfaces com o utilizador
Familiaridade

Usar termos e conceitos recolhidos da experiência
das ...
Familiaridade


Termos e conceitos recolhidos da
experiência das pessoas que mais usarão
sistema



Termos e conceitos o...
Consistência


Sempre que possível, operações
comparáveis activadas da mesma forma



Exemplos
 Comandos e menus com o ...
Mínima surpresa


Utilizadores nunca são surpreendidos
pelo comportamento do sistema



Se utilizador conhece efeito de ...
Recuperabilidade


Incluir mecanismos para utilizadores
recuperarem de erros



Resiliência face a erros do utilizador
...
Orientação


Disponibilizar informação quando erros
ocorrem e mecanismos de ajuda
sensíveis ao contexto



Disponibiliza...
Diversidade


Proporcionar mecanismos de interacção
para diferentes tipos de utilizadores do
sistema



Alguns utilizado...
Heurísticas de Nielsen
Visibilidade do
estado do sistema

Manter utilizadores informados acerca do que
está a acontecer at...
Heurísticas de Nielsen
Prevenção de erros Mostrar boas mensagens de erro e sobretudo
desenhar de forma a evitar ocorrência...
Heurísticas de Nielsen
Desenho estético e
minimalista

Desenhar diálogos sem informação irrelevante
ou raramente necessári...
Dois problemas de desenho


Como disponibilizar ao sistema informação
vinda do utilizador?



Como disponibilizar ao uti...
Estilos de interacção
Manipulação directa
 Selecção em menus
 Preenchimento de formulários
 Comandos
 Linguagem natura...
Estilos de interacção
Estilo

Vantagens

Desvantagens

Manipulação
directa

Interacção rápida e
intuitiva; fácil aprender....
Múltiplas interfaces
Interface gráfica de
utilização (Gnome/KDE)

Interface de linha de
comandos (bash/ksh)

Gestor da int...
Interacção LIBSYS
Pesquisa de documentos Utilizadores usam os mecanismos de
pesquisa para procurar os documentos de
que pr...
Interfaces baseadas na
Web


Muitos sistemas baseados na Web têm
interfaces baseadas em formulários cujos
campos podem se...
Formulário de pesquisa do
LIBSYS
LIBSYS: Pesquisa

Escolher colecção

Todas

Palavra ou frase
Procurar usando

Título

Pal...
Apresentação da
informação


Apresentação ao utilizador de informação
do sistema



Informação pode ser apresentada
 Di...
Apresentação da
informação

Informação
a mostrar

Software de
apresentação

Ecrã

2009/2010

Engenharia do Software I

27
Modelo-vista-controlador
Entradas do
utilizador

Controlador

estado
métodos

Edições do
modelo

2009/2010

Mensagens de
m...
Apresentação da
informação


Informação estática
 Inicializada no início de uma sessão
 Não muda durante uma sessão
 P...
Factores da apresentação da
informação


Utilizador interessa-se por informação precisa ou
relações entre dados?



Quão...
Apresentações alternativas da
informação
Jan. Fev. Mar. Abr. Mai. Jun.
2842 2851 3164 2789 1273 2835

4000
3000
2000
1000
...
Apresentação analógica ou
digital?


Apresentação digital
 Compacta – Ocupa pouco espaço no ecrã
 Permite comunica valo...
Métodos de apresentação

1
4

2
0

3

Mostrador e
agulha

2009/2010

Gráfico em
queijo

Termómetro

Engenharia do Software...
Mostrando valores relativos

Pressão
0

2009/2010

100

200

Temperatura
300

400

0

Engenharia do Software I

25

50

75...
Visualização de dados


Grandes quantidades de informação



Revela tendências e relações entre entidades



Possíveis ...
Ecrãs coloridos


Cor adiciona dimensão extra à interface



Ajuda a compreender estruturas
complexas de informação



...
Erros comuns


Usar a cor para comunicar significado



Superabundância de cor no ecrã

2009/2010

Engenharia do Softwar...
Mau exemplo

2009/2010

Engenharia do Software I

38
Orientações para uso de cores
Limitar o número de cores
 Ser conservador
 Mostrar alterações de estado
 Suportar tarefa...
Bom exemplo

2009/2010

Engenharia do Software I

40
Mensagens de erro


Bom desenho é crítico: más mensagens de
erro podem levar à rejeição do sistema



Devem ser




...
Factores na redacção de
mensagens de erro
Contexto

Reflectir contexto corrente do utilizador. Deve-se estar
ciente das su...
Erro do utilizador
Nome do paciente
Introduza o nome do
paciente:

Ximenes, Xisto

Assuma que um(a)
enfermeira(o) se
engan...
Mau desenho: mensagem de
erro orientada para o sistema
Erro!

!

Erro 27
ID de paciente inválido!

OK

2009/2010

Engenhar...
Bom desenho: mensagem de
erro orientada para o utilizador
Paciente “Xisto Ximenes” desconhecido
“Xisto Ximenes” não está r...
Processo de desenho de
interfaces com o utilizador


É processo iterativo



Relações estreitas entre utilizadores e
des...
Actividades centrais do
processo
Análise de utilizadores

Compreender o que os utilizadores irão
fazer com o sistema.

Pro...
Processo de desenho
Analisar e
compreender
actividades dos
utilizadores

Produzir
primeiro
protótipo
em papel

Avaliar
des...
Análise de utilizadores


Sem perceber o que utilizadores
pretendem fazer não é possível desenhar
interface eficaz



An...
Cenário de interacção com o
utilizador
A Joana é aluna de Estudos Religiosos. Está a trabalhar num
ensaio sobre arquitectu...
Requisitos do cenário


Utilizadores podem não estar cientes de
termos de pesquisa mais apropriados



Precisam de ajuda...
Técnicas de análise
Análise de tarefas

Modelar os passos que completar uma
tarefa envolve.

Entrevistas e questionários

...
Análise hierárquica de
tarefas
Obter imagens a
partir de bibliotecas
remotas

Fazer 1, 2 e 3 até imagens encontradas, 4
1
...
Entrevistas


Conceber entrevistas semi-estruturadas
baseadas em perguntas abertas



Utilizadores fornecem informação q...
Etnografia


Observador externo observa utilizadores
trabalhando e questiona-os sobre o seu
trabalho



Valor decorre de...
Registos etnográficos
O controlo do tráfego aéreo usa um determinado número de
„pacotes‟ em que os pacotes de controlo de ...
Resultados da análise
etnográfica


Controladores têm de ver todos os voos
num sector: deve evitar-se visualizações
em qu...
Prototipagem da interface com
o utilizador


Dar aos utilizadores experiência directa
com interface



Sem ela é impossí...
Prototipagem em papel


Estudar cenários usando esboços da
interface



Usar guião para apresentar série de
interacções ...
Técnicas de prototipagem
Com guião

Programação visual
Baseada na Web

2009/2010

Desenvolver conjunto de guiões e ecrãs u...
Avaliação de interfaces com o
utilizador


Necessária para aferir se desenho é
adequado



Avaliação completa muito cara...
Atributos de usabilidade
Apreensibilidade

Quanto demora um utilizador a se tornar produtivo
com o sistema?

Velocidade de...
Técnicas de avaliação simples


Questionários ao utilizador



Gravação vídeo de utilização do sistema e
posterior avali...
A reter


Princípios do desenho guiam desenho
de interfaces com utilizador



Estilos de interacção incluem
 Manipulaçã...
A reter


Apresentações gráficas mostram tendências e
valores aproximados



Apresentações digitais mostram valores
prec...
A reter


Análise de utilizadores sensibiliza
designers para forma de trabalho efectiva
de utilizadores



Prototipagem ...
A ler


Ian Sommerville, Software Engineering,
8.ª edição, Addison-Wesley, 2006
 Capítulo 16

2009/2010

Engenharia do S...
A ver


useit.com: Jakob Nielsen's Website

2009/2010

Engenharia do Software I

68
Upcoming SlideShare
Loading in …5
×

Usabilidade de aplicações

226 views
153 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
226
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Usabilidade de aplicações

  1. 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. 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. 3. 2009/2010 Engenharia do Software I 3
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. Apresentação da informação Informação a mostrar Software de apresentação Ecrã 2009/2010 Engenharia do Software I 27
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Erros comuns  Usar a cor para comunicar significado  Superabundância de cor no ecrã 2009/2010 Engenharia do Software I 37
  38. 38. Mau exemplo 2009/2010 Engenharia do Software I 38
  39. 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. 40. Bom exemplo 2009/2010 Engenharia do Software I 40
  41. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 67. A ler  Ian Sommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006  Capítulo 16 2009/2010 Engenharia do Software I 67
  68. 68. A ver  useit.com: Jakob Nielsen's Website 2009/2010 Engenharia do Software I 68

×