Capítulo 14 — Engenharia de software
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Design centrado no usuário"]
N1["14.2 Testes de usabilidade"]
N2["14.3 Acompanhar defeitos de usabilidade"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Design centrado no usuário"]
N1["14.2 Testes de usabilidade"]
N2["14.3 Acompanhar defeitos de usabilidade"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX040"]
[14.1 Design centrado no usuário]
|
v
[14.2 Testes de usabilidade]
|
v
[14.3 Acompanhar defeitos de usabilidade]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem
Você vai (1) aplicar o design centrado no usuário a um recurso de segurança; (2) conduzir testes de usabilidade; (3) acompanhar defeitos de usabilidade como quaisquer outros defeitos.
14.1 Design centrado no usuário
A Greyford quer um novo botão de reporte em seu sistema de e-mail. Aiko segue um processo centrado no usuário: entrevistar usuários, esboçar opções, testar protótipos e refinar. As entrevistas mostram que os engenheiros de campo leem e-mails sobretudo no celular, muitas vezes de luvas ou sob luz forte. Um ícone pequeno escondido em um menu não funcionaria para eles. O desenho dela coloca um botão de reporte grande no topo de cada mensagem, tanto no computador quanto no celular. As práticas de engenharia de software se aplicam aos recursos de segurança exatamente como a qualquer outro recurso.
14.2 Testes de usabilidade
Aiko testa o protótipo com oito funcionários de funções diferentes. Cada um é convidado a reportar um e-mail suspeito enquanto ela observa sem ajudar. Ela registra o tempo gasto e os erros. Os usuários de computador reportam em menos de cinco segundos; dois usuários de celular têm dificuldade porque o botão sai da tela ao rolar. Ela corrige o botão para que ele permaneça visível. Testes pequenos com usuários reais encontram problemas que os projetistas não conseguem ver, porque já sabem como o recurso funciona. Ela repete o teste no celular depois da correção, e os oito participantes têm sucesso rapidamente.
14.3 Acompanhar defeitos de usabilidade
Aiko registra os problemas de usabilidade no mesmo rastreador de defeitos usado para bugs funcionais, com severidade definida por quantos usuários falham e pela importância da tarefa. O botão que some ao rolar é um defeito de alta severidade, porque reportar é a finalidade principal do recurso. Tratar problemas de usabilidade como defeitos garante que sejam corrigidos antes do lançamento, em vez de ficarem como questões de gosto. Sasse, Brostoff e Weirich (2001) argumentaram que uma segurança que as pessoas não conseguem usar de forma eficaz não é uma segurança eficaz. O defeito é corrigido antes do lançamento.
Exemplo resolvido
Aiko desenha um botão de reporte com entrevistas e protótipos, testa-o com oito usuários, corrige um defeito no celular e acompanha a usabilidade como defeitos.
Caso sintético. Os testes são sintéticos; Sasse et al. (2001) é real.
Erros e limites
Oito testadores deixam passar problemas raros. Testes em laboratório diferem das condições reais de campo.
Exercícios
- EX040 — Condições de campo. Que condições afetam o uso de e-mail pelos engenheiros de campo? Rubrica: 3 = celular, luvas e luz forte;; 2 = condições;; 1 = vago;; 0 = nenhuma.
- EX041 — Defeito no celular. Que defeito de usabilidade o teste encontrou? Rubrica: 3 = o botão de reporte no celular saía da tela ao rolar;; 2 = rolagem;; 1 = vago;; 0 = nenhuma.
- EX042 — Severidade do defeito. Por que o problema de rolagem era de alta severidade? Rubrica: 3 = reportar é a finalidade principal do recurso;; 2 = tarefa central;; 1 = cosmético;; 0 = nenhuma.
Síntese
As funcionalidades de segurança precisam de desenho centrado no usuário, testes de usabilidade e acompanhamento de defeitos, como qualquer outro software.
Continue estudando — aula 14 (capítulo 14 de 50)
← Capítulo 13 · Índice das aulas · Capítulo 15 →
Continue para a próxima aula já escrita.