t cnicas de usabilidade e testes automatizados em ... · pdf filemonografia submetida ao...
TRANSCRIPT
Universidade de Brasília - UnB
Faculdade UnB Gama - FGA
Engenharia de Software
Técnicas de usabilidade e testes automatizadosem processos de desenvolvimento de software
empírico
Autores: Jônatas Medeiros de Mendonça,Rodrigo Medeiros Soares da Silva
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Brasília, DF
2014
Jônatas Medeiros de Mendonça,Rodrigo Medeiros Soares da Silva
Técnicas de usabilidade e testes automatizados emprocessos de desenvolvimento de software empírico
Monografia submetida ao curso de graduaçãoem Engenharia de Softwareda Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.
Universidade de Brasília - UnB
Faculdade UnB Gama - FGA
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Brasília, DF
2014
Jônatas Medeiros de Mendonça,Rodrigo Medeiros Soares da Silva
Técnicas de usabilidade e testes automatizados em processos de desenvolvi-mento de software empírico / Jônatas Medeiros de Mendonça,Rodrigo Medeiros Soares da Silva. – Brasília, DF, 2014-
110 p. : il. (algumas color.) ; 30 cm.
Orientador: Prof. Dr. Paulo Roberto Miranda Meirelles
Trabalho de Conclusão de Curso – Universidade de Brasília - UnBFaculdade UnB Gama - FGA , 2014.
1. Testes. 2. Software livre. 3. Usabilidade. I. Prof. Dr. Paulo Roberto MirandaMeirelles. II. Universidade de Brasília. III. Faculdade UnB Gama. IV. Técnicas deusabilidade e testes automatizados em processos de desenvolvimento de softwareempírico
CDU 02:141:005.6
Jônatas Medeiros de Mendonça,Rodrigo Medeiros Soares da Silva
Técnicas de usabilidade e testes automatizados emprocessos de desenvolvimento de software empírico
Monografia submetida ao curso de graduaçãoem Engenharia de Softwareda Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.
Trabalho aprovado. Brasília, DF, Dezembro de 2014:
Prof. Dr. Paulo Roberto MirandaMeirellesOrientador
Prof. Hilmer Rodrigues NeriConvidado 1
Prof. Tiago Barros Pontes e SilvaConvidado 2
Brasília, DF2014
Resumo
Este trabalho de conclusão de curso apresenta um estudo sobre usabilidade etestes automatizados de software empírico. Para aplicação deste estudo foi utilizadocomo estudo de caso a plataforma Noosfero, desenvolvida de forma livre a partirdo código aberto. Este estudo apresenta e aplica técnicas de usabilidade, além detécnicas de BDD e TDD em várias aplicações do estudo de caso mencionado, bus-cando assim verificar como estas técnicas de testes podem afetar as avaliações deusabilidade de um software. Além disso o trabalho visa compreender como inseriras práticas de usabilidade estudadas no ciclo de vida de desenvolvimento de umsoftware livre utilizando uma abordagem ágil
Palavras-chaves: software livre. testes automatizados. usabilidade.
Abstract
This course conclusion work presents a study about software usability andautomated tests of empirical software. The Noosfero plataform was used as casestudy for the application of this study, developed as free software from open source.This study presents and applies techniques of usability, in addition to techniquesof BDD and TDD in many applications of the case study mentioned, thus seekingto ascertain how these testing techniques can affect the assessments of usability ofa software. Further work aims to understand how to insert the practical usabilitystudied the life cycle of a free software development using an agile approach.
Key-words: free software. automated tests. usability.
Lista de ilustrações
Figura 1 – Ciclo de atividades TDD (BECK, 2002) . . . . . . . . . . . . . . . . . 29
Figura 2 – Estrutura de Usabilidade Norma ISO 9241-11 . . . . . . . . . . . . . . 34
Figura 3 – Número de avaliadores (NIELSEN, 1994) . . . . . . . . . . . . . . . . . 45
Figura 4 – Ciclo de Vida Estrela . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 5 – Ciclo do Design centrado no humano - Norma ISO 13407 . . . . . . . . 52
Figura 6 – Visão geral do processo de desenvolvimento de software de XPlus . . . 56
Figura 7 – Desenvolvimento noosfero . . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 8 – Descrição de feature - noosfero . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 9 – Descrição de bug - noosfero . . . . . . . . . . . . . . . . . . . . . . . . 60
Figura 10 –Descrição do título (feature) de um teste . . . . . . . . . . . . . . . . . 71
Figura 11 –Descrição de pré condições (background) de um teste . . . . . . . . . . 72
Figura 12 –Descrição do cenário (scenario) de um teste . . . . . . . . . . . . . . . 72
Figura 13 –Descrição do setup de um teste . . . . . . . . . . . . . . . . . . . . . . 73
Figura 14 –Código de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 15 –Cobertura de código do plugin LdapUnb . . . . . . . . . . . . . . . . . 86
Figura 16 –Cobertura de código do plugin para submissão de trabalho . . . . . . . 86
Figura 17 –Cobertura de código do plugin Stoa . . . . . . . . . . . . . . . . . . . . 87
Figura 18 –Cobertura de código do plugin Ldap . . . . . . . . . . . . . . . . . . . 87
Figura 19 –Cobertura de código do plugin Statistics . . . . . . . . . . . . . . . . . 87
Figura 20 –Questionário de perfil do usuário . . . . . . . . . . . . . . . . . . . . . 93
Figura 21 –Questionário de perfil do usuário - Continuação . . . . . . . . . . . . . 94
Figura 22 – Informações sobre o uso dos meios de comunicação . . . . . . . . . . . 95
Figura 23 –Participações sociais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 24 –Portal da Participação Social . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 25 –Ambiente e tempo de acesso no portal . . . . . . . . . . . . . . . . . . 98
Figura 26 –ASQ - The After-Scenario Questionnaire . . . . . . . . . . . . . . . . . 100
Figura 27 –PSSUQ – The Post-Study System Questionnaire . . . . . . . . . . . . . 101
Figura 28 –PSSUQ: The Post-Study System Questionnaire - Questões de 8 à 19 . 102
Lista de tabelas
Tabela 1 – Objetivos do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Tabela 2 – Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Tabela 3 – Técnicas de avaliação para os testes com usuários . . . . . . . . . . . . 66
Tabela 4 – Tabela de variáveis dependentes . . . . . . . . . . . . . . . . . . . . . . 69
Tabela 5 – Validade dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Tabela 6 – Avaliação dos resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Tabela 7 – Comparativo dos questionários . . . . . . . . . . . . . . . . . . . . . . 103
Lista de abreviaturas e siglas
ASQ The After-Scenario Questionnaire
BDD Behavior Driven
DCU Design Centrado no Usuário
DSA Directory System Agent
FGA Faculdade UnB Gama
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
ICC Instituto Central de Ciências
IHC Interação Humano Computador
LAPPIS Laboratório de Produção, Pesquisa e Inovação em Software
LDAP Lightweight Directory Access Protocol
MES Manutenção e Evolução de Software
MVC Model-View-Controller
ProIC Projeto de Iniciação Científica
PSQ The Printer-Scenario Questionnaire
PSSUQ The Post-Study System Questionnaire
PuSH PubSubHubbub
QUIS Questionnaire for User Interaction Satisfaction
Rails Ruby on Rails
SLTI Secretaria de Logística e Tecnologia da Informação
SMT Tecnologias de Mídia Social
SUMI Usability Measurement Inventory
SUS System Usability Scale
SSL Secure Socket Layer
SPB Software Público Brasileiro
TCC Trabalho de Conclusão de Curso
TCP Transmission Control Protocol
TDD Test Driven Develepment
TLS Transport Layer Security
UDP User Datagram Protocol
UPA Usability Professionals’ Association - Associação de Profissionais de
usabilidade
UnB Universidade de Brasília
USP Universidade de São Paulo
UI User Interface
UX User Experience
W3C World Wide Web Consortium
XP Extreme Programming
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.1 Objetivos gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Questões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.1 Classificação da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 As etapas da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 Métodos de Desenvolvimento Empírico . . . . . . . . . . . . . . . . . . . . 23
2.1 Software Livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 GNU e GNU GPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Métodos ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Técnicas de desenvolvimento de testes automatizados . . . . . . . . . . . . 28
3.2.1 TDD - Test Driven Development . . . . . . . . . . . . . . . . . . . 29
3.2.1.1 Benefícios do TDD . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 BDD - Behavior Driven Development . . . . . . . . . . . . . . . . . 30
3.2.2.1 Príncipios do BDD . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Metas de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 As áreas da Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Interação Humano Computador . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Arquitetura da Informação . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Ergonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.4 Design Centrado no usuário . . . . . . . . . . . . . . . . . . . . . . 36
4.2.5 Design de Interaçao . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.6 Engenharia de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.6.1 Ciclo de Engenharia de Usabilidade . . . . . . . . . . . . . 37
4.2.7 Experiência do Usuário - UX . . . . . . . . . . . . . . . . . . . . . 37
4.2.8 Relação de todas essas áreas com a Usabilidade . . . . . . . . . . . 37
4.3 A importância e os benefícios da Usabilidade . . . . . . . . . . . . . . . . . 38
4.4 Avaliação de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Técnicas e Métodos da Engenharia de Usabilidade . . . . . . . . . . . . . . 39
4.5.1 Métodos e técnicas de concepção . . . . . . . . . . . . . . . . . . . 40
4.5.1.1 Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1.2 Storyboard . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1.3 Card Sorting . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1.4 Diagramas de Afinidade . . . . . . . . . . . . . . . . . . . 40
4.5.1.5 Protótipos . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.2 Métodos e técnicas de análise . . . . . . . . . . . . . . . . . . . . . 41
4.5.2.1 Observação . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.2.2 Entrevistas Tradicionais . . . . . . . . . . . . . . . . . . . 41
4.5.2.3 Eyetracking . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.2.4 Questionários de Perfil de Uso . . . . . . . . . . . . . . . . 41
4.5.2.5 Questionários de Satisfação . . . . . . . . . . . . . . . . . 42
4.5.2.6 Grupos de Foco . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.2.7 Diários . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.2.8 Benchmarking de Usabilidade . . . . . . . . . . . . . . . . 43
4.5.2.9 Cenários de uso . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.2.10 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.3 Técnicas e Métodos de avaliação . . . . . . . . . . . . . . . . . . . . 43
4.5.3.1 Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.3.2 Avaliação heurística . . . . . . . . . . . . . . . . . . . . . 44
4.5.3.3 Listas de Verificação . . . . . . . . . . . . . . . . . . . . . 45
4.5.3.4 Percurso Cognitivo . . . . . . . . . . . . . . . . . . . . . . 45
4.5.3.5 Teste de Usabilidade . . . . . . . . . . . . . . . . . . . . . 45
4.6 Usabilidade em Software Livre . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.7 Processos de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.1 Modelo Estrela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.2 O ciclo de vida da Engenharia de Usabilidade - Mayhew . . . . . . 49
4.7.3 Design Centrado no Usuário . . . . . . . . . . . . . . . . . . . . . . 51
4.7.3.1 ISO 13407 e 9241-210 . . . . . . . . . . . . . . . . . . . . 51
4.8 Aplicação de usabilidade em métodos ágeis . . . . . . . . . . . . . . . . . . 52
4.8.1 Estudos correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8.2 DCU Ágil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8.3 DCU e XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Princípios ágeis aplicados ao DCU . . . . . . . . . . . . . . . . . . . . . . . 56
4.10 Teste da Usabilidade vs. Teste de Aceitação do Usuário (UAT) . . . . . . . 58
4.11 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Observações do Estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Estudo de Caso - Noosfero . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Desenvolvimento no processo de colaboração ao noosfero . . . . . . 59
5.1.1.1 Fase de Desenvolvimento . . . . . . . . . . . . . . . . . . . 59
5.1.1.2 Fase de Release 1 . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.1.3 Fase de Release 2 . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.1.4 Release Final . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.2 Aplicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2 Estudo sobre Usabilidade - Portal da Participação Social . . . . . . . . . . 62
5.2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.3 Definição do Estudo Experimental . . . . . . . . . . . . . . . . . . . 63
5.2.3.1 Objetivo Global . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.3.2 Objetivos de Medição . . . . . . . . . . . . . . . . . . . . 63
5.2.3.3 Objetivo do Estudo . . . . . . . . . . . . . . . . . . . . . . 64
5.2.3.4 Questões . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2.4.1 Análise do Perfil dos Usuários . . . . . . . . . . . . . . . . 64
5.2.4.2 Paradigma e Técnica de Avaliação . . . . . . . . . . . . . 65
5.2.4.3 Heurísticas de Usabilidade . . . . . . . . . . . . . . . . . . 66
5.2.4.4 Instrumentos para coletas de dados . . . . . . . . . . . . . 66
5.2.4.5 Cenários para teste de Usabilidade . . . . . . . . . . . . . 67
5.2.5 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.5.1 Definição de Hipóteses . . . . . . . . . . . . . . . . . . . . 68
5.2.5.2 Seleção dos Indivíduos . . . . . . . . . . . . . . . . . . . . 68
5.2.5.3 Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.5.4 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.5.5 Validade dos Resultados . . . . . . . . . . . . . . . . . . . 69
5.2.6 Procedimentos para a execução . . . . . . . . . . . . . . . . . . . . 70
5.2.7 Avaliação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3 Estudo sobre Testes Automatizados - Rede Comunidade UnB . . . . . . . 70
5.3.1 Testes de aceitação - Cucumber . . . . . . . . . . . . . . . . . . . . 71
5.3.2 Testes Funcionais e Unitários . . . . . . . . . . . . . . . . . . . . . 73
5.3.3 Plugin Ldap UnB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3.3.1 Testes com plugin LDAP . . . . . . . . . . . . . . . . . . . 75
5.3.3.2 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . 75
5.3.3.3 Testes unitários . . . . . . . . . . . . . . . . . . . . . . . . 76
5.3.4 Plugin para submissão de trabalho . . . . . . . . . . . . . . . . . . 77
5.3.4.1 Testes Funcionais . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.4.2 Testes Unitários . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.4.3 Testes de Aceitação . . . . . . . . . . . . . . . . . . . . . . 79
5.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1 Resultados Prelimirares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.2 Usabilidade no desenvolvimento de software empírico . . . . . . . . 88
6.1.3 Portal da Participação Social . . . . . . . . . . . . . . . . . . . . . 89
6.2 Próximos Passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.1 Portal do Software Público . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.2 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A Apêndice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.1 Questionário de Perfil do Usuário . . . . . . . . . . . . . . . . . . . . . . . 93
A.2 Questionário de Satisfação . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.2.1 QUIS - Questionnaire for User Interaction Satisfaction . . . . . . . 98
A.2.2 SUS – System Usability Scale . . . . . . . . . . . . . . . . . . . . . 99
A.2.3 SUMI – Usability Measurement Inventory . . . . . . . . . . . . . . 99
A.2.4 ASQ – The After-Scenario Questionnaire . . . . . . . . . . . . . . . 99
A.2.5 PSQ – The Printer-Scenario Questionnaire . . . . . . . . . . . . . . 100
A.2.6 PSSUQ – The Post-Study System Questionnaire . . . . . . . . . . . 100
A.2.7 CSUQ - Computer System Usability Questionnaire . . . . . . . . . 102
A.2.8 Comparativo dos questionários . . . . . . . . . . . . . . . . . . . . . 103
A.3 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
19
1 Introdução
O impacto e utilização do software livre na indústria de software tem aumentando
gradativamente nas últimas décadas e influenciado significativamente a economia global.
O desenvolvimento de software livre baseado em métodos ágeis é uma realidade.
Metodologias ágeis como Scrum e XP recomendam que todas as pessoas envolvidas em
um projeto trabalhem controlando a qualidade do produto todos os dias, pois baseiam-
se na ideia de que prevenir defeitos é mais barato que identificá-los, assim é recomen-
dado testes automatizados para ajudar a garantir a qualidade dos sistemas desenvolvidos
(BERNARDO, 2011).
A área de teste de software também tem evoluido, preocupando-se com as apli-
cações de testes em sistemas cada vez mais dinâmicos e reutilizáveis com propostas para
aumento de qualidade e produtividade de software (VICENTE, 2010).
A áreas relacionadas a usabilidade também vem ganhando importância nessas
últimas décadas. Criar software que seja útil e fácil de usar é fator importante para a
continuidade dos sistemas.
Um dos grandes problemas encontrados em softwares livres é a pouca atenção dada
aos aspectos referentes a usabilidade e acessibilidade das aplicações. Acredita-se que um
dos principais problemas que contribui para a falta de usabilidade de software livre é sua
própria comunidade que apenas enfatiza na criação e, melhoria e teste do código fonte.
Segundo Preece, Rogers e Sharp (2007), uma das causas da baixa adoção de
softwares livres em mercados de larga escala é a baixa qualidade dos estilos de intera-
ção implementados nas interfaces dos produtos. Uma grande maioria não se preocupa
com bons elementos de interface com usuário (UI).
Atualmente, algumas comunidades de software livre vêm se atentando as questões
de usabilidade como forma de se manter no mercado. Um dos casos que conhecemos foi
do Joomla que é um sistema de gerenciamento de conteúdo que nessas últimas versões
investiram em questões de usabilidade, sendo o primeiro CMS a ser 100 por cento res-
ponsivo. Foi criada uma frente de desenvolvimento focado na experência do usuário que
trouxe melhorias significativas a partir da versão 3.0 do CMS. Logo em seguida o Word-
press, outro sistema de gerenciamento de contéudo investiu em melhorias da interface se
atentando aos novos padrões adotados na web.
Entender o perfil do usuário é um dos principais pontos que devem ser levados em
consideração pelos desenvolvedores de software em geral. Cada perfil de usuário tem suas
particularidades e suas expectativas quanto a utilização do sistema. Quando falamos de
20 Capítulo 1. Introdução
usuários com experiência de uso de softwares semelhantes é preciso ter uma maior atenção
na usabilidade para que possa ter uma boa aceitação e menor impacto com as mudanças.
1.1 Problemas
Um dos grandes problemas encontrados nos softwares livres é a baixa usabilidade
de suas interfaces, o que resulta na perda de usuários.
Os desenvolvedores de software livre possuem uma mentalidade mais voltada para
a funcionalidade do que para os usuários do sistema. Possuem código de qualidade, com al-
garismos eficientes e de bom desempenho e são produzidos por desenvolvedores motivados
e voluntários (SANTOS, 2012).
Outro problema do desenvolvimento de software atualmente está em garantir qua-
lidade de software de forma prática e econômica.
1.2 Objetivos
Nesta seção iremos abordar sobre os objetivos deste trabalho de conclusão de
curso, dissertando tanto a respeito dos objetivos gerais do trabalho quanto dos objetivos
específicos.
1.2.1 Objetivos gerais
Este trabalho de conclusão de curso busca analisar técnicas e métodos de usabi-
lidade, assim como técnicas de desenvolvimento e de testes de software em um processo
empírico para verificar a os possiveis efeitos de técnicas como TDD e BDD na usabilidade
de um software, a partir de técnicas como testes de usabilidade, dentre outras.
1.2.2 Objetivos específicos
Para satisfazer os objetivos gerais do trabalho foram definidos objetivos specíficos:
1. Verificar aplicação das práticas do BDD e TDD no processo de desenvolvimento de
software livre;
2. Integração da Engenharia de Usabilidade no ciclo de vida de desenvolvimento de
softwrare livre;
3. Identificar quais as técnicas de design e usabilidade podem ser utilizadas em cada
fase do processo ágil de desenvolvimento de software livre;
1.3. Questões 21
4. Analisar a usabilidade dos portais governamentais utilizando diferentes técnicas de
avaliação, a fim de que a avaliação possa ser feita não somente pelo especialista
de usabilidade, mas também para que os usuários avaliem a qualidade em uso dos
portais;
5. Evoluir o processo de desenvolvimento de software empírico a partir de um estudo
de caso específico;
1.3 Questões
1. Como os testes automatizados são definidos e implementados em um ambiente de
desenvolvimento de software empírico?
2. É possível inserir os princípios de usabilidade dentro do processo ágil de desenvol-
vimento de software?
3. O processo de desenvolvimento utilizando práticas do BDD e TDD apresentam
melhores resultados em testes de usabilidade?
4. Projetos de software centrados no usuário que possuem avaliação de usabilidade
desde o seu início apresentam melhores resultados no teste aceitação?
1.4 Metodologia
1.4.1 Classificação da Pesquisa
Neste trabalho, a coleta e análise dos dados serão realizadas com base em materiais
já publicados, constituído principalmente de livros, artigos de periódicos e materiais dis-
ponibilizados na Internet, caracterizando-se, portanto, como uma pesquisa bibliográfica
do ponto de vista do procedimento técnico empregado (GIL, 1991).
1.4.2 As etapas da Pesquisa
1. Estudo bibliográfico
Levando em consideração os objetivos da pesquisa, o estudo bibliográfico aborda
a usabilidade e a sua relação com as diferentes áreas de conhecimento, tentando
entender como a usabilidade está presente em nosso meio. As áreas pesquisadas são
(Arquitetura da Informação, Design, Ergonomia, Interação Humano Computador,
Engenharia de Usabilidade, Experiência do Usuário, Psicologia, entre outras).
Deve ser feito um estudo sobre o processo de desenvolvimento ágil de software livre.
Além disso é necessário conhecer o ciclo de design centrado no usuário. Encontrar
22 Capítulo 1. Introdução
maneiras de como inserir os métodos de usabilidade utilizando uma abordagem ágil
em um contexto de software livre.
2. Coletas de dados
Os dados serão coletados através de questionários e entrevistas que serão feitas
através de experimentos realizados em um estudo de caso no portal da participação
social.
1.5 Organização do trabalho
Nesta seção está apresentada a organização deste trabalho, e o que se refere cada
capítulo.
O estudo inicia-se no segundo capítulo, em que se aborda o desenvolvimento de
software empírico, onde dissertamos sobre software livre e suas licenças assim como uma
breve base conceitual sobre metodologias ágeis de desenvolvimento.
O terceiro capítulo aborda conceitualmente as técnicas de testes automatizados
que geralmente são utilizadas no processo empírico, além dos tipos de testes que podem
ser aplicados. Nesta seção são destacados o TDD (Test Driven Development) e o BDD
(Behavior Driven Development).
O quarto capítulo aborda os principais conceitos e as áreas referentes a usabilidade
e a as técnicas existentes utilizadas na engenharia de usabilidade e áreas afins, além de a
abordar os processos da engenharia de usabilidade e interação humano computador e as
formas de como poder inserir as técnicas no ciclo de vida de desenvolvimento de software
empírico.
O quinto capítulo aborda as observações feitas no planejamento da aplicação de
técnicas de avaliação da usabilidade para o Portal da Participação Social 1 e também
aborda a plataforma do Noosfero, e as funcionalidades desenvolvidas para a Rede Comu-
nidade UnB2 e o Portal da FGA3, a partir desta plataforma.
O trabalho se encerra com os resultados parciais, assim como as análises obtidas
de todo o processo do trabalho, aĺém de uma discussão para os próximos passos.
1 www.participa.br2 comunidade.unb.br3 www.fga.unb.br
23
2 Métodos de Desenvolvimento Empírico
O Empirismo baseia-se na aquisição de sabedoria através da percepção do mundo
externo, ou então do exame da atividade da nossa mente, que abstrai a realidade que nosé
exterior e as modifica internamente (CHAUí, 2003). Mecanismos do controle de processo
empírico, onde ciclos de feedback constituem o núcleo da técnica de gerenciamento que
são usadas em oposição ao tradicional gerenciamento de comando e controle.É uma forma
de planejar e gerenciar projetos trazendo a autoridade da tomada de decisão a níveis
de propriedade de operação e certeza (SCHWABER, 2004). Neste capítulo será abordado
algumas ideias e práticas de processo de desenvolvimento de software que utilizam métodos
ágeis, processos amplamente utilizados no desenvolvimentode software livre, outro assunto
também abordado no decorrer deste texto.
2.1 Software Livre
Software livre é uma filosofia que trata programas de computadores como fontes
de conhecimento que devem ser compartilhados entre a comunidade, evoluindo assim o
desenvolvimento do pensamento no que se diz respeito a desenvolvimento de software. De
acordo com Stallman (2001), ativista fundador do movimento software livre, um software
deve seguir quatro princípios:
1. Liberdade de execução para qualquer uso;
2. Liberdade de estudar o funcionamento de um software e de adaptá-lo às suas neces-
sidades
3. Liberdade de redistribuir cópias;
4. Liberdade de melhorar o software e de tornar as modificações públicas de modo que
a comunidade se beneficie da melhoria (STALLMAN, 2001).
Um software é considerado software livre se segue estes quatro princípios, portanto o
usuário deve poder utilizar, estudar e modificar o software como ele bem entender, não
significa que o software é necessariamente de graça, mas a partir do momento em que se
obtém posse de um programa um usuário pode modificar e redistribuir o mesmo programa.
Para Stallman (2001), a partir do momento em que os custos de desenvolvimento de um
software são pagos, não há motivos para restrição de acesso, pois a disseminação de
conhecimento é muito mais benéfica do que potenciais lucros para o produtor.
24 Capítulo 2. Métodos de Desenvolvimento Empírico
2.1.1 GNU e GNU GPL
Umas das grandes conquistas de Stallman e da Fre Software Foudation (FSF),
principal organização dedicada a produção e à divulgação do software livre, foram o pro-
jeto GNU1 e a licença de software General Public License (GPL). O projeto GNU consistiu
em desenvolver um sistema operacional baseado no sistema Unix, porém livre de código
proprietário, proporcionando aos usuários do Unix um sistema totalmente compatível com
o Unix, com seu código disponível para todos e a liberdade de buscar suporte e persona-
lizações da forma que quisessem. Com o GNU, também foi desenvolvida a GPL, licença
que dá amparo legal e formaliza a ideologia de software livre, amplamente utilizada pelos
software livres. No final do desenvolvimento do GNU, o finlandês Linus Torvalds iniciou o
desenvolvimento de um núcleo de sistema operacional também baseado no Unix e deu o
nome do núcleo de Linux, disponibilizando-o pela licença GNU GPL. Assim foi promovida
a integração entre GNU e Linux, criando assim o GNU/Linux, amplamente utilizado até
os dias de hoje.
2.2 Métodos ágeis
A utilização de métodos ágeis no desenvolvimento de software tem como caracte-
risticas intrínsecas a flexibilidade e rapidez nas respostas a mudanças. A agilidade, para
uma organização de desenvolvimento de software, é a habilidade deadotar e reagir rapi-
damente e apropriadamente a mudanças no seu ambiente e por exigências impostas pelos
clientes (NERUR; MAHAPATRA; MANGALARAJ, 2005).
Os métodos ágeis compartilham valores como comunicação, feedback constante,
colaboração com o cliente e constante adaptação são baseados no manifesto ágil. Os
quatro princípios básicos do manifesto ágil mostra o que se espera de qualquer método
de desenvolvimento desta categoria:
1. Indivíduos e interações sobre processos e ferramentas;
2. Software funcionando sobre documentação extensiva;
3. Colaboração com o cliente sobre negocioação de contrato;
4. Responder às mudanças sobre seguir um planejamento;
Em projetos ágeis o cliente é mais ativo durante o processo de desenvolvimento, deter-
minandoem conjunto com a equipe de desenvolvimento o que será desenvolvido, além de
participarda validação. Os projetos ágeis também buscam estabelecer um tempo deter-
minado e curto para entregade novas releases do sistema, com o objetivo de trazer mais1 www.gnu.org
2.3. Considerações finais 25
satisfação ao cliente. A partir destes curtos ciclos, que são as interações, a equipe de
desenvolvimento devese preocupar mais com a evolução dos requisitos, que pode gerar
mudanças, porém mantém o projetoatualizados e diminui o riscos de grandes mudanças
a medida que o projeto chega ao final. Da perspectiva do produto, métodos ágeis são
mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora
não exista um consenso completo neste ponto. De uma perspectiva organizacional, a apli-
cabilidade pode ser expressa examinando três dimensões chaves da organização: cultura,
pessoal e comunicação. Em relação a estas áreas, inúmeros fatores chave do sucesso podem
ser identificados (COHEN; LINDVALL; COSTA, 2004).
Um método ágil conhecido como programação extrema, (Extreme Programming
- XP) se tornou-se bastante popular por utilizar práticas focadas em codificação, como
programação pareada, integração contínua e desenvolvimento dirigido por testes. O ob-
jetivo principal do XP é a excelência no desenvolvimento de software, visando um baixo
custo, poucos defeitos, alta produtividade e alto retorno de investimento , de acordo com
Sato (2007). O XP conta com algumas práticas de desenvolvimento para dar suporte à
busca pelos objetivos citados, essas práticas são: refatoração, integração contínua, testes
automatizados, código coletivo e programação em pares.
2.3 Considerações finais
O ambiente de desenvolvimento que este trabalho está inserido é baseado em me-
todologias ágeis como Scrum e XP, buscando seguir os princípios ágeis para o desenvol-
vimento de software livre, que será especificado no capítulo 7.
27
3 Testes
Testar é uma pratica intrínseca ao desenvolvimento e é antiga a necessidade de criar
programas para testar cenários específicos por Everett et al. (2007). Testes de software
serão abordados neste cápítulo, iniciando com uma visão geral de testes automatizados e
conhecendo algumas práticas e padrões utilizados para desenvolver os mesmos.
Para Potel e Cotter (1995) a automação de testes é uma prática ágil, eficaz e de
baixo custo para melhorar a qualidade dos sistemas de software. No entanto utilizar testes
automatizados como uma premissa básica do desenvolvimento é um fenômeno relativa-
mente recente, com início em meados da década de 1990. Além do fato de ser uma técnica
bastante utilizada pelas metodologias ágeis de desenvolvimento.
3.1 Testes Automatizados
Teste automatizado é a prática de tornar os testes de software independentes da
intervenção humana, criando scripts ou programas simples de computador que exercitam
o sistema em teste, capturam os efeitos colaterais e fazem verificações, tudo automatica
e dinamicamente (MESZAROS; WESLEY, 2007).
Os testes automatizados afetam diretamente a qualidade dos sistemas de software,
portanto agregam valor ao produto final, mesmo que os artefatos adicionais produzidos
não sejam visíveis para os usuários finais do sistemas. Estes testes podem ser divididos
em diversos tipos, o que facilita a manutenção dos mesmos.
1. Testes de unidade: testes de correção responsável por testar os menores trechos
de código de um sistema que possui um comportamento definido e nomeado. Nor-
malmente, ele é associado a funções para linguagens procedimentais e métodos em
linguagens orientadas a objetos.
2. Testes funcionais: testes que tem como objetivo verificar a eficiência dos compo-
nentes de um sistema. (MOLINARI, 2003)
3. Testes de integração: denominação ampla que representa a busca de erros de re-
lacionamento entre quaisquer módulos de um software, incluindo desde a integração
de pequenas unidades até a integração de bibliotecas das quais um sistema depende,
servidores e gerenciadores de banco de dados.
4. Testes de interface de usuário testes que verificam a correção por meio da
simulação de eventos de usuário. A partir destes eventos, são feitas verificações na
interface e em outras camadas.
28 Capítulo 3. Testes
5. Testes de leiaute: testes que buscam avaliar a beleza da interface e verificar a
presença de erros após a renderização, dificeis de indentificar com testes comuns de
interface
6. Testes de aceitação: são testes de correção e validação, idealmente especificados
por clientes ou usuários finais do sistema para verificar se um módulo funciona como
foi especificado (MARTIN, 2005).
Testes de aceitação devem utilizar linguagem proxima da natural para evitar proble-
mas de interpretação e de ambiguidades (MUGRIDGE; DCUNNINGHAM, 2005).
7. Testes de desempenho: testes que executam trechos do sistema e armazenam
os tempos de duração obtidos, que ajudam a identificar gargalos que precisam de
otimização para diminuir o tempo de resposta para o usuário (LIU, 2009).
8. Testes de carga: testes que exercitam o sistema sobre condições de uso intenso para
avaliar se a infraestrutura é adequada para a expectativa de uso do sistema (AVRITZE; WEYUKER,
1994).
9. Testes de estresse: teste que visa descobrir os limites do uso da infraestrutura,
isto é , qual a quantidade máxima de usuários e requisições que o sistema consegue
antender corretamente e em um tempo aceitável.
10. Testes de longevidade: testes que tem por objetivo encontrar erros somente vi-
síveis com um longo tempo de execução do sistema, erros que podem ser de cache,
replicação, execução de serviços agendados ou vazamento de memória.
11. Testes de segurança: os testes de segurança servem para verificar se os dados ou
funcionalidades confidenciais de um sistema estão protegidos de fraude ou de usuá-
rios não autorizados. A segurança de um sofware pode envolver aspectos de confi-
denciabilidade, integridade, autenticação, autorização, privacidade (WHITTAKER,
2006).
3.2 Técnicas de desenvolvimento de testes automatizados
Automação de testes é uma técnica voltada principalmente para a melhoria de
qualidade dos sistemas de software. No processo de desenvolvimento de software é funda-
mental controlar o custo do processo de testes, para isso baterias de testes automatizados
devem ser bem definidas e implementadas. Assim é importante conhecer boas práticas e
técnicas de de desenvolvimento de testes automatizados. Existem várias técnicas de desen-
volvimento de software com testes que influenciam diretamente na qualidade do sistema.
Estas técnicas geralmente possuem um processo de atividades pequeno e simples, como
TDD e BDD.
3.2. Técnicas de desenvolvimento de testes automatizados 29
3.2.1 TDD - Test Driven Development
Desenvolvimento dirigido por testes, também conhecido como TDD (Test-Driven
Develepment) é uma técnica de desenvolvimento de software que se dá pela repetição dosci-
plinada de um ciclo curto de passos de implementação de testes e do sistema (KOSKELA,
2007). O ciclo de TDD é definido pelos seguintes passos:
1. Implementar um caso de teste;
2. Implementar um trecho do código suficiente para o novo caso de teste ter sucesso
de tal modo que não quebre os testes previamente escritos;
3. Se necessário, refatorar o código produzido para que ele fique mais organizado;
A técnica de desenvolvimento dirigido por testes foi definida por Kent Beck em seu livro
Test-Driven Development: By Example Beck (2002). Os passos estão representados na
figura abaixo:
Figura 1 – Ciclo de atividades TDD (BECK, 2002)
3.2.1.1 Benefícios do TDD
Uma boa prática do TDD é a bateria de testes, que ajuda o desenvolvedor a evitar
erros de regreção, quando o desenvolvimento de uma nova funcionalidade quebra uma
já existente. TDD também tende a contribuir com uma alta cobertura de código, uma
fez que o desenvolvedor precisa escrever o testes antes da funcionalidade, possibilitando
a criação de um código mais preciso, coeso e menos acoplado. Para Massol e Husted
30 Capítulo 3. Testes
(2003) “o objetivo de TDD é ‘código claro que funciona’. TDD propõe o desenvolvimento
sempre em pequenos passo, deve-se escrever testes sempre para uma menor funcionalidade
possível, escrever o código mais simples que faça o teste passar e fazer sempre apenas
uma refatoração por vez Beck (2002). Assim o desenvolvedor se detém a criar soluções
simples, sempre acompanhado de um constante feedback dos testes. O ciclo curto de
passos definidos por TDD cria uma dependência forte entre codificação e testes, o que
favorece e facilita a criação de sistemas com alta testabilidade Bernardo (2011). Índices
altos de cobertura de código e testabilidade não garantem necessariamente qualidade do
sistema, mas são métricas bem vistas para sistemas bem desenvolvidos Além de uma
técnica de testes automatizados, TDD também é uma prática de desenvolvimento de
software, pois muda a natureza do processo de codificação, auxiliando na produção de um
código funcional e limpo.
3.2.2 BDD - Behavior Driven Development
Desenvolvimento dirido por comportamento (BDD - Behavior Driven Develop-
ment) é uma prática que recomenda o mesmo ciclo de desenvolvimento de TDD, contudo,
induzindo a utilização de uma linguagem ubíqua entre cliente e equipe de desenvolvimento
de acordo com Bernardo (2011), subistituindo termos como assert, assert, test case, test
suite por termos mais comuns ao cliente, como should, context, specification
O BDD é um processo de desenvolvimento de software baseado no TDD. Embora
seja principalmente uma ideia de como um processo de desenvolvimento de software deve
ser gerenciado. a prática do BDD assume a utilização de ferramentas como suporte para
o desenvolvimento de software, por Haring (2011). O BDD utiliza essas ferramentas para
que os testes tenham como ponto de partida o compartemento dos objetos.
O BDD coloca em foco o comportamento em vez da estrutura e faz isso em todos
os níveis de desenvolvimento. Uma vez que nós reconhecemos isso, ele muda a forma como
pensamos sobre desenvolvimento para fora do código e começamos a pensar mais sobre
as intereações sobre pessoas e sistemas, ou entre os objetos, do que sobre a estrutura do
objeto (CHELIMSKKY et al., 2010).
Para que o comportamento seja analisado, é necessário entender o ponto de vista
do cliente, entendendo o comportamento que o sistema deve ter a partir da visão do
cliente.
3.2.2.1 Príncipios do BDD
De acordo com Chelimskky et al. (2010), estes são os três príncipios do BDD:
1. O suficiente é suficiente: parte da ideia de gerenciar o esfoço no planejamento
inicial do sistema, para não fazer menos nem mais do que o necessário para começar,
3.2. Técnicas de desenvolvimento de testes automatizados 31
o que se aplica também ao processo de automação.
2. Agregar valor as partes interessadas: Se você está fazendo algo que não agrega
valor ou que não aumenta a capacidade de agregar valor, pare e faça outra coisa em
seu lugar.
3. Tudo é comportamento: Do código à aplicação, pode-se usar o mesmo pensa-
mento e as mesmas construções linguísticas para descrever o comportamento, em
qualquer nível de granularidade (CHELIMSKKY et al., 2010).
O comportamento do sistema é descrito em histórias de usuário, que são escritas
com a participação tanto de clientes como desemvolvedores do sistema. Assim cada história
de usuário deve seguir, de certa forma, a seguinte estrutura:
Título: do que se trata a história.
Narrativa: deve identificar as partes interessadas para essa história, as funciona-
lidades requeridas, e o benefício deste comportamento. A narrativa de uma história pode
ter vários formatos.
Critério de aceitação: descrição de cada caso específico da narrativa, iniciado
pela especificação da condição inicial do cenário, seguidos pelos estados que ativam este
cenário, finalizado pelos estados esperados ao final do cenário.
3.2.3 Considerações Finais
Testes automatizados devem ser desenvolvidos com prioridade, buscando um rá-
pido feedback, contribuindo assim com a melhoria do sistema. Para isso é necessário que
os cenários de testes estejam bem definidos junto à equipe.
33
4 Usabilidade
Neste capítulo abordaremos os conceitos e as áreas que estão por trás do termo
usabilidade e as relações entre cada uma delas. Entender a importância e os benefícios que
a usabilidade trás para os sistemas de software. Apresentar os modelos de ciclo de vida
utilizados na interação humano computador e mostrar como podemos inserir a usabilidade
no ciclo de desenvolvimento de software empírico.
4.1 Usabilidade
A usabilidade é um termo antigo que começou a ser utilizado pela Ciência Cogni-
tiva e depois pela Psicologia e Ergonomia em substituição ao termo “amigável” (DIAS,
2006).
Segundo Nielsen (1994), usabilidade é um conjunto de propriedades de uma in-
terface que reúne os seguintes componentes: fácil aprendizado, eficiência, capacidade de
memorização, baixo índice de erros e satifação e prazer ao uso.
A usabilidade é um atributo de qualidade relacionado à facilidade de uso de algo.
Refere-se a rapidez com que os usuários podem aprender a usar alguma coisa, a eficiência
deles ao usá-la, o quanto lembram daquilo, seu grau de propensão a erros e o quanto
gostam de utilizá-la (NIELSEN; LORANGER, 2007).
Ainda usabilidade é definida como o fator que assegura que um produto ou serviço é
fácil de usar, eficiente e agradável a partir do ponto de vista do usuário (PREECE; ROGERS; SHARP,
2007).
A Qualidade em uso engloba o contexto do ambiente de trabalho para caracteri-
zar a satisfação de uso, focando não apenas no usuário, mas em seu comportamento ao
interagir com um sistema computacional. O conceito de qualidade em uso mais difundido
é o de usabilidade que engloba a facilidade e a eficiência de aprendizado de uso, bem
como a satifação do usuário. Esse conceito de qualidade em uso é defendido pela norma
ISO/IEC 9126-1 (2003) que define usabilidade como capacidade do produto de software
ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições
específicas.
Já para a norma ISO/IEC 9241-11 (2003), usabilidade é a capacidade de um
produto ser usado por usuários específicos para alcançar objetivos específicos com eficácia,
eficiência e satisfação em um contexto de uso específico. A ISO define alguns termos que
são amplamente utilizados quando se fala em usabilidade.
34 Capítulo 4. Usabilidade
• Eficácia é a capacidade que os sistemas conferem a diferentes tipos de usuários
para alcançar seus objetivos em número e com a qualidade necessária.
• Eficiência é a quantidade de recursos que os sistemas solicitam aos usuários para
a observação de seu objetivos com o sistema.
• Satisfação é a emoção que os sistemas proporciona, aos usuários em face dos re-
sultados obtidos e dos recursos necessários para alcançar tais objetivos.
• Tarefa: Objetivo a ser atingido ou um resultado a obter.
• Usuários: Pessoas que utilizam alguma instãncia do sistema,
• Contexto: Conjunto de elementos, onde se destacam: o ambiente físico, a tecnologia
utilizada e a a motivação.
Figura 2 – Estrutura de Usabilidade Norma ISO 9241-11
4.1.1 Metas de Usabilidade
As metas de usabilidade servem para guiar o desenvolvimento de produtos fáceis
de usar, eficientes e agradáveis (PREECE; ROGERS; SHARP, 2007). São elas:
1. Utilidade
2. Eficácia
3. Eficiência
4. Segurança
5. Facilidade de aprendizado
6. Facilidade de lembrar como se usa
4.2. As áreas da Usabilidade 35
4.2 As áreas da Usabilidade
Para entender o que é usabilidade e como ela está inserida no ciclo de vida do
desenvolvimento de software precisamos compreender as relações que o termo tem com
as diversas áreas que a envolve.
4.2.1 Interação Humano Computador
O Termo Human Computer Interaction (HCI) começou a ser adotado na década
de 1980 para descrever uma nova área de estudo na qual se preocupavam em saber como
o uso dos computadores poderia enriquecer a vida pessoal e profissional dos seus usuários
(MOARES, 2002).
A interação humano computador tem o principal objetivo de melhorar a eficácia e
proporcionar satisfação do usuário.O objetivo do HCI são desenvolver e aprimorar sistemas
computacionais nos quais os usuários possam executar tarefas com segurança, eficiência
e satisfação (PREECE; ROGERS; SHARP, 2007).
4.2.2 Arquitetura da Informação
A informação é algo que está presente no nosso dia-a-dia. Para (WURMAN,
1991)) a informação deve ser aquilo que leva à compreensão. A quantidade de conteúdo
que é produzido na internet extrapola a capacidade humana de retenção da informação.
Para Agner (), esse excesso de informação contribui para o aumento dos problemas de
usabilidade e da necessidade de pesquisa na área de interação humano-computador.
Segundo Garret (2003), a arquitetura da informação são a arte e a ciência de
estruturar e organizar os ambientes informacionais para ajudar as pessoas a encontrarem
e administrarem informações.
O arquiteto de informação deve ser um profissional multidisciplinar com conheci-
mentos em design gráfico, ciência da informação, biblioteconomia, jornalismo, engenharia
de usabilidade, marketing e ciência da computação. Ele deve balancear as necessidades
do usuário com os objetivos do negócio (ROSENFELD; MORVILLE, 1998).
4.2.3 Ergonomia
A ergonomia está na origem da usabilidade, pois visa proporcionar eficácia e efici-
ência, além de bem-estar e saúde do usuário através da adaptação do trabalho ao homem.
O seu objetivo é garantir que sistemas e dispositivos estejam adaptados às maneiras de
pensar, agir e trabalhar do usuário. (CYBIS; BETIOL; FAUST, 2010)
36 Capítulo 4. Usabilidade
4.2.4 Design Centrado no usuário
Design centrado no usuário é um campo de estudo que reúne metodologias de de-
sign nas quais o público álvo de um produto ou serviço influencia as diretrizes e requisitos
do sistema (NORMAN, 2006).
Para Norman (2006), cunhador do termo, o design centrado no usuário é uma
filosofia baseada nas necessidades e interesses dos usuário, com ênfase em fazer produtos
úsaveis e inteligíveis.
Segundo Saffer (2010) as pessoas que utilizarão um produto ou serviço sabem de
suas necessidades, metas e preferências, e é papel do design descobrir isto e projetar para
eles e essa é a filosofia por trás do design centrado no usuário.
4.2.5 Design de Interaçao
Uma grande parte dos produtos que necessitam da interação do usuário são fei-
tos olhando apenas na perspectiva da engenharia e se esquecem de seus reais usuários.
O design de interação surge para redirecionar a preocupação que se tinha apenas em
produzir algo que funcionasse para produzir algo que sejá fácil de utilizar, agrádavel e efi-
caz na perspectiva do usuário, trazendo a usabilidade para dentro do processo de design
(PREECE; ROGERS; SHARP, 2007).
Segundo Moggridge (2006), o termo surgiu com Bill Verplank que resume design
de interação a partir da resposta de três perguntas sobre como você age, como você sente
e como você compreende.
Uma outra definição de design de interação é o design de produtos interativos
que fornecem suporte à atividades cotidianas das pessoas, seja no lar ou no trabalho, ou
seja, criar experiências que melhorem, estendem a maneira como as pessoas trabalham,
se comunicam e interagem (PREECE; ROGERS; SHARP, 2007).
4.2.6 Engenharia de Usabilidade
A engenharia de usabilidade surgiu no final dos anos 80 com o esforço sistemático
das empresas e organizações para desenvolver programas de software interativo com usabi-
lidade. Sua origem parte de iniciativas de cientistas como Card, Moran e Newell (Modelo
do processador Humano de 1983) e Norman (Teoria da Ação de 1989). O objetivo era
produzir conhecimentos que favorecesse a concepção de interfaces humano-computador
mais adaptadas (CYBIS; BETIOL; FAUST, 2010).
Podemos fazer um paralelo da engenharia de usabilidade com a engenharia de
software. A engenharia de software ocupa do desenvolvimento do núcleo funcional de um
sistema interativo formado por estruturas de dados, algoritmos e recursos de processa-
4.2. As áreas da Usabilidade 37
mento de dados. Esse núcleo é construído de forma que o sistema funcione bem, de forma
correta, rápida e sem erros. Já a engenharia de usabilidade ocupa-se da interface com o
usuário que interliga as funções do sistema com os usuários de forma que a interface do
sistema seja agradável, intuitivo, eficiente e fácil de operar (CYBIS; BETIOL; FAUST,
2010).
4.2.6.1 Ciclo de Engenharia de Usabilidade
O ciclo foi definido sendo essencialmente evolutivo, interativo e baseado no en-
volvimento do usuário. A norma ISO 13407 (Projeto centrado no usuário) sugere quatro
principais etapas desse ciclo (analisar e especificar o contexto de operação; especificar
as exigências dos usuários e organizações; produzir soluções de projeto; avaliar o projeto
contra as exigências) (CYBIS; BETIOL; FAUST, 2010).
4.2.7 Experiência do Usuário - UX
Experiência do usuário é toda a interação com um produto, serviço ou marca.
O termo é usado frequentemente para sintetizar toda a experiência com um produto de
software. Não engloba somente as funcionalidades e sim o quanto o aplicativo é agradável
ao usuário (LOWDERMILK, 2013).
O termo User Experience (UX) foi cunhado por Donald Norman na década de 80
para cobrir todos os aspectos da experiência da pessoa com o sistema. Acreditava que
as definições de interface do usuário e usabilidade limitava o entendimento sobre o que o
trabalho dele representava. Ele disse atualmente que não gosta do termo pois está sendo
utilizado para resumir tudo o que ele estava fugindo, que é pensar em UX como apenas
as disciplinas.UX não é uma disciplina é uma cultura. 1
Qualquer pessoa envolvida no projeto precisa atuar na experiência do usuário e
deve ser feito em todo o processo.
4.2.8 Relação de todas essas áreas com a Usabilidade
A usabilidade está relacionada com os fatores humanos e corresponde como o
estudo de como usuários se relacionam com qualquer produto. A interação humano com-
putador está baseada na usabilidade e foca no modo como as pessoas se relacionam com
os produtos ligados à computação.
As áreas que trabalham com usabilidade são disciplinas transversais que agregam
diversas áreas do conhecimento tais como pscicologia, sociologia, ciência da informação e
da computação, fatores humanos, design gráfico e indústrial, ergonomia, comunicação e
etc.1 uxdesign.blog.br
38 Capítulo 4. Usabilidade
4.3 A importância e os benefícios da Usabilidade
No modo geral, os projetistas sabem da importância de desenvolver com enfoque
no usuário e na usabilidade, mas normalmente os projetos são desenvolvidos sem que
tenham sido realizadas pesquisas e aplicados métodos e técnicas de usabilidade.
O tempo e os recursos limitados são as principais razões que impede a implatação
dos testes de usabilidade nas equipes de software. Também há o desconhecimento por
parte da equipe de desenvolvimento das técnicas a serem empregadas.
Segundo Rosa e Moraes (2012), incorporar a usabilidade no seu processo pode
reduzir os custos e tempo de desenvolvimento e melhorar o produto final. É preciso ter
em mente quem é o seu usuário final em todas as etapas de desenvolvimento e proces-
sos de produção, desde análise das necessidades e projeto conceitual até prototipagem e
produção.
O investimento na área de usabilidade agrega valor ao produto e traz benefícios
não somente aos usuários, mas também aos seus produtores.
Para a Associação de Profissionais de usabilidade (UPA), a usabilidade inclui os
seguintes benefícios:
• Aumentar a produtividade
• Diminuir custos de treinamento e suporte
• Aumentar as vendas e as revendas
• Reduzir os custos de desenvolvimento e manutenção.
• Aumentar a satisfação do consumidor.
4.4 Avaliação de Usabilidade
Os métodos de avaliação são utilizados para avaliar a qualidade das interações entre
o usuário e o sistema, e para verificar, inspecionar e diagnosticar os aspectos ergonômicos
das interfaces.
As avaliações de interface podem ser divididas de diversas maneiras como o tipo
de dados, formas e o local da avaliação. Quanto a forma, pode ser definida como:
• Objetiva: São baseadas em técnicas que utilizam medições quantitativas, em vez
de opiniões dos usuários ou especialistas.
• Subjetiva São baseadas em opiniões e relatos de usuários e especialisatas.
4.5. Técnicas e Métodos da Engenharia de Usabilidade 39
Quanto ao tipo de dados, pode ser definida como:
• Quantitativa Envolvem medidas e tendem a ser vistas como objtivas e imparciais.
• Qualitativa Envolvem descrições e relatos e são vistas como subjetivas.
Quanto ao local da avaliação:
• Laboratório Ocorre em ambientes controlados.
• Estudo de Campo ou natural Estão situados no contexto do mundo real no qual
o sistema é utilizado.
Antes de definir as técnicas de avaliação Preece, Rogers e Sharp (2007) identifica
quatro tipos de paradigmas de avaliação: (1) avaliações rápidas e sujas; (2) testes de
usabilidade; (3) estudos de campos e; (4) avaliações preditivas.
Em relação as técnicas de avaliação, Preece, Rogers e Sharp (2007) as divide em
cinco técnicas de avaliação: (1) observação e monitoramento; (2) opinião dos usuários; (3)
opiniões dos especialistas; (4) testes com os usuários e; (5) Predição.
Já Cybis, Betiol e Faust (2010) divide as técnicas de avaliação da usabilidade de
interfaces em três grupos. Técnicas prospectivas; técnicas preditivas/diagnósticas/analíticas/inspecção
e as objetivas/definitivas/empíricas.
De acordo com Preece, Rogers e Sharp (2007) cada método de avaliação possui
características e pode ser aplicado em diferentes situações. Eles diferem entre si em vários
aspectos. É preciso entender as diferentes caracterśiticas de cada método para se definir
qual deles é o mais apropriado para avaliar a interface de um software em um determinado
contexto. Cada método pode se diferenciar pela etapa do ciclo que pode ser aplicado,
a técnica utilizada para coletar dados e os tipos de dados coletados (quantitativa ou
qualitativa).
4.5 Técnicas e Métodos da Engenharia de Usabilidade
Esta seção mostra as técnicas e os métodos que são utilizados pela interação hu-
mano computador para desenvolver um sistema com usabilidade.
De acordo com BERVIAN, Cervo e SILVA (2002) as técnicas são procedimentos
específicos utilizados por uma ciência determinada. O conjunto com várias técnicas cons-
tituem os métodos. Algumas técnicas são utilizadas em várias ciências e os métodos se
adapta às diversas ciências a medida que há imposição de uso de técnicas especializadas.
Cybis, Betiol e Faust (2010) divide as técnicas e os métodos da engenharia de
usabilidade em três tipos: Concepção, Análise e Avaliação.
40 Capítulo 4. Usabilidade
4.5.1 Métodos e técnicas de concepção
Os métodos de concepção são utilizados para implementar as especificações e os
requisitos para a interface a usabilidade de um sistema.
4.5.1.1 Brainstorming
O brainstorming é bastante utilizado em ambientes ágeis para obter ideias, entrar
em consenso sobre problemas ou novas propostas.
4.5.1.2 Storyboard
É uma representação das interações entre os usuários e o sistema em seu ambiente
de trabalho. Corresponde ao detalhamento de um cenário de uso especificado para o
sistema consistindo em uma sequência de desenhos representando não só os esboços de
telas, mas também os elementos do contexto (usuários, equipamentos, móveis, telefones,
colegas).
4.5.1.3 Card Sorting
É uma técnica usada para descobrir como o usuário classifica determinada infor-
mação em sua mente. O usuário recebe uma série de cartões embaralhados descrevendo
conteúdos e agrupam os cartões que tenham alguma relação. Podem ser distribuidos car-
tões com nomes de categorias.
O card sorting pode ser aberto ou fechado podendo ser aplicado tanto de forma
presencial ou remota e aplicados para grupos ou para uma única pessoa. Recomenda-se
no mínimo 15 testes e que cada teste tenha 2 pessoas.
4.5.1.4 Diagramas de Afinidade
Os diagramas de afinidade são utilizados para organizar uma grande quantidade de
itens em grupos lógicos. Diferente do card sorting, nesta técnica os projetistas e usuários
trabalham juntos para obter consenso sobre a organização dos itens. Essa técnica pode
ser usada para analisar os resultados de estudos de campo e analisar as conclusões de uma
avaliação de usabilidade.
4.5.1.5 Protótipos
Os protótipos de papel são úteis para detectar problemas de usabilidade logo no
início do proceso de design. São usados para esclarecer os requisitos específicos para o
projeto da interface do sistema. São rápidos de construir, permitindo rápidas interações de
projeto e necessitam de poucos recursos para serem criados. Existem também os protótipos
4.5. Técnicas e Métodos da Engenharia de Usabilidade 41
de baixa, média e alta que simulam o sistema com mais fidelidade do que os protótipos
em papel.
4.5.2 Métodos e técnicas de análise
Estes métodos são utilizados para buscar informações sobre o contexto de uso
e sobre a usabilidade de um sistema. Podem ser feitas análises do perfil do usuário, o
ambiente de uso, as tarefas, possibilidades e restrições do sistema.
As técnicas mencionadas à baixo visam apoiar os projetistas de interface na busca
de informações sobre o contexto de uso e sobre a usabilidade de um sistema existente.
Essas técnicas são empregadas de forma que se complementem-se umas as outras.
4.5.2.1 Observação
Essa técnica caracteriza-se por um pesquisador observando o usuário e tomando
notas, enquanto este trabalha em seu contexto usual. é uma técnica útil para obter dados
quantitativos (tempo para as tarefas) e qualitativos (práticas e estratégias do usuário)
(CYBIS; BETIOL; FAUST, 2010).
No planejamento é importante definir os objetivos e as maneiras de como será
registrada os acontecimentos. Deve-se levar em consideração o fato que muitos usuários
por estarem sendo observados podem alterar seu comportamento ao utilizar a ferramenta.
É importante que todos estejam cientes dos objetivos do estudo, deixando claro que não
é ele que será avaliado e sim conhecer uma situação de uso.
4.5.2.2 Entrevistas Tradicionais
Através de entrevistas podemos obter as opiniões tanto dos usuários atuais como
dos futuros usuários dos sistemas. Primeiramente é importante identificar as necessidades
das pessoas em acessar uma determinada informação.
4.5.2.3 Eyetracking
Eyetracking é uma técnica que rastrea o movimento dos olhos e da cabeça para
registrar a tomada de informações numa interface.
4.5.2.4 Questionários de Perfil de Uso
É utilizado para obter informações sobre as caracteristicas reais dos usuários de
um sistema e saber como eles realmente utilizam tais ferramentas. É importante que
ao utlizar os questionários de perfil de uso é preciso definir um foco para a sua pesquisa.
Deve-se identificar as principais dúvidas da equipe de projeto em relação ao uso do sistema
(CYBIS; BETIOL; FAUST, 2010).
42 Capítulo 4. Usabilidade
Este tipo de questionário pode ser enviado para os emails dos usuários da fer-
ramenta em análise. É importante definir o tamanho de sua amostra. De acordo com
Cybis, Betiol e Faust (2010), de 20 a 30 por cento é a taxa de retorno dos questionários
enviados. As respostas podem ser analisadas utilizando métodos estatísticos.
4.5.2.5 Questionários de Satisfação
A aplicação de questionários é um dos métodos mais utilizados para avaliação
da satisfação do usuário. Eles resultam da avaliação subjetiva pelo usuário, o qual é
influenciado pelos tipos de questões aplicadas.
Questionários de satifação são utilizados principalmente quando existem usuários
experientes que utilizam o sistema com frequência, podendo ter informações fidedigna
sobre aspectos satisfatórios e insatisfatórios no sistema. Também podem ser aplicados por
usuários de uma nova versão de um sistema imediatamente após um teste de usabilidade.
Essa relação com os testes de usabilidade é interessante por permitir a correlação das
medidas de desempenho (tempo, frequência) com as medidas de satifação do usuário
(CYBIS; BETIOL; FAUST, 2010).
É recomendado que se utilize um questionário padronizado, pois permite a com-
paração de resultados obtidos por diferentes sistemas. Estes questionários apresentam
opções de respostas fechadas, o que permite a produção de dados quantitativos e objeti-
vos (CYBIS; BETIOL; FAUST, 2010).
Um grande número de questionários foram desenvolvidos pela comunidade cientí-
fica para a avaliação da usabilidade. Alguns exemplos de questionários são: QUIS, SUMI,
WAMMI, SUS, ASQ, PSQ,PSSUQ, CSUQ. Os detalhes referentes a cada questionário
estão detalhados no apêndice.
4.5.2.6 Grupos de Foco
Grupo focal é uma reunião informal de usuários que manifestam suas opiniões sobre
o determinado assunto, que pode ser tanto uma oportunidade de novas uncionalidades ou
algum problema específico.
Um moderador deve preparar um roteiro com uma lista de assuntos a serem tra-
tados. É importantes que os participantes sejam de perfis diferentes para que possa
ter uma maior diversidade de informações. Costuma-se ter em média de 6 a 12 usuá-
rios em uma mesa de reuniões. Os registros das informações podem ser através de ví-
deos ou blocos de anotações. O objetivo não é ter a obtenção do consenso em torno
das ideias, mas sim ter uma boa quantidade de opiniões sobre o assunto a ser tratados
(CYBIS; BETIOL; FAUST, 2010).
4.5. Técnicas e Métodos da Engenharia de Usabilidade 43
4.5.2.7 Diários
É uma técnica útil quando a experiência do usuário é ampla e depende da utilização
em multi lugares. Nessa técnica os usários carregam consigo um pequeno diário para nele
anotar as informações do seu dia-a-dia na utilização do sistema (CYBIS; BETIOL; FAUST,
2010).
4.5.2.8 Benchmarking de Usabilidade
Benchmarking é definido como método sistemático e contínuo de avaliação de sis-
temas reconhecidos como representantes das melhores e mais eficazes pŕaticas com a finali-
dade de comparar desempenhos e identificar oportunidades de melhoria. (SPENDOLINI,
1994)
Este método parte da definição dos critérios de avaliação e seleção de representantes
relevantes para criar uma listagem de caracterśisticas desejáveis para o futuro sistema,
como também os aspectos que são desfavoráveis e que devem ser evitados.
4.5.2.9 Cenários de uso
É uma técnica simples e eficaz para analisar e comunicar uma parte das especifica-
ções de requisitos produzidos para a usabilidade e a interface. São utilizados para comuni-
car os cenários atuais de uma tarefa (problema) e o cenário futuro (solução). Os cenários
de solução deve descrever em linguagem natural, como determinados usuários realizarão
tarefas específicas com o sistema em um determinado contexto. É preciso decompor os
objetivos dos usuários segundo as operações necessárias para alcança-los, identificando as
atividades que serão realizadas pelos usuários (CYBIS; BETIOL; FAUST, 2010).
4.5.2.10 Personas
A técnica de persona descreve o perfil de uma pessoa fictícia envolvida com o pro-
duto. Trata-se de inventar um conjunto de pessoas (três ou quatro) que estejam dentro da
população de usuários pretendidos e descrevê-las em detalhes (CYBIS; BETIOL; FAUST,
2010).
As informações devem ser qualitativas e coletadas por meio de entrevistas e ques-
tionários junto à população alvo do sistema. As personas permitem maiior entendimento
dos usuários, colocando-os no centro das decisões do projeto (CYBIS; BETIOL; FAUST,
2010). Essa técnica tem objetivos similares aos de cenários, porém ao invês do foco ser na
tarefa, deve-se ter foco em uma pessoa que faça parte do público alvo do sistema.
44 Capítulo 4. Usabilidade
4.5.3 Técnicas e Métodos de avaliação
4.5.3.1 Checklists
Checklist é uma técnica de inspeção qu oferece uma maneira de abordagem rá-
pida, fácil e de baixo custo para a avaliação de uma interface. Permite com que usuá-
rios que não são especialistas em ergonomia identificarem problemas menores e repetiti-
vos. (CYBIS; BETIOL; FAUST, 2010)
Várias vantagens são encontradas na utilização dessa técnica como: redução de
custos de avaliação por não precisar de especialistas; sistematização das avaliações; reduz
a subjetividade dos processos de avaliação e fornece um conhecimento ergonômico sobre
o que avaliar.
O Ergolist 2 é um aplicativo que pode ser utilizado para realizar uma inspeção da
qualidade ergonômica da interface com o usuário do sistema.
4.5.3.2 Avaliação heurística
Representa um julgamento de valor sobre as qualidades ergonômicas das interfaces
Humano-Computador. Essa avaliação é realizada por especialistas em ergonomia e usabili-
dade. Eles examinam o sistema interativo e diagnosticam os problemas ou as barreiras que
os usuários provavelmente encontrarão durante a interação (CYBIS; BETIOL; FAUST,
2010).
O principal objetivo desse tipo de avaliação é avaliar a interface em fases iniciais
do sistema, sem o envolvimento do usuário. Os graves problemas de interface devem ser
localizados antes que realizem os testes de usabilidade com usuários reais (SANTOS,
2012).
As avaliações mais utilizadas são as 10 heurísticas de Nielsen (1994). São elas:
• Visibilidade de acordo com o sistema
• Mapeamento entre o sistema e o mundo real
• Liberdade e controle ao usuário
• Consistência e Padrões
• Prevenção de Erros
• Reconhecer em vez de relembrar
• Flexibilidade e Eficiência de uso
2 http://www.labiutil.inf.ufsc.br/ergolist/check.htm
4.5. Técnicas e Métodos da Engenharia de Usabilidade 45
• Design estético e minimalista
• Suporte para usuário reconhecer, diagnosticar e recuperar erros
• Ajuda e documentação
Pesquisas realizadas por Jakob Nielsen fornecem indicações sobre a quantidade
de avaliadores que devem ser consultados para que possam indentificar grande parte dos
problemas de ergonomia. Cinco avaliadores com experiência tanto em usabilidade como
no sistema consegue identificar 95 por cento dos problemas de ergonomia enquanto espe-
cialistas que conhece apenas de usabilidade identificam 85 por cento.
Figura 3 – Número de avaliadores (NIELSEN, 1994)
A avaliação heurística requer pouco planejamento e pode fazer parte de um pro-
cesso interativo de um projeto e aplicado em todas as fases de desenvolvimento da inter-
face, mas é preciso que seja avaliado por especialistas de usabilidade com pleno conheci-
mento nas heurśiticas.
4.5.3.3 Listas de Verificação
Permitem que profissionais que não necessariamente sejam especialistas em ergo-
nomia identifiquem problemas menores e repetitivos das interfaces. As normas ISO 9241,
partes 10 a 17, fornecem listas de verificação de ergonomia bem definidas, assim como as
fornecidas pelo site Ergolist (CYBIS; BETIOL; FAUST, 2010).
4.5.3.4 Percurso Cognitivo
Percurso cognitivo é um método de inspeção de usabilidade que tem como objetivo
avaliar a interface considerando a facilidade da interface. A finalidade do percurso cogni-
tivo é fazer com que o design de interação seja fácil de aprender por meio da exploração.
46 Capítulo 4. Usabilidade
Os inspetores aplicam uma lista de verificação orientada à tarefa interativa, abordando
os processos cognitivos que se estabelecem quando o usuário a realiza pela primeira vez
(CYBIS; BETIOL; FAUST, 2010)
4.5.3.5 Teste de Usabilidade
É um dos métodos de teste de experiência do usuário (UX) mais frequentemente
utilizado e conhecido entre aqueles que não são projetistas da UX. Realizar testes com
usuários é o núcleo do Design Centrado no Usuário, pois é através destes que podemos
saber se as reais expectativas dos usuários são atendidas (SANTOS, 2012).
O teste consiste em avaliar o desempenho dos usuários na execução de tarefas
cuidadosamente preparadas, tarefas estas dentro do escopo do sistema. Esse desempenho
pode ser avaliado no quesito, número de erros e tempo de execução da tarefa, questionários
e entrevistas também podem ser utilizados. (PREECE; ROGERS; SHARP, 2007)
Existe alguns passos comuns que devem ser seguidos para a execução dos testes
de usabilidade:
• Escolher abordagem
Existem vários tipos de testes de usabilidade, mas sabe-se que todos eles têm algo
em comum, que é observar as pessoas utilizando algo.As abordagens de pesquisa
podem ser de dois tipos: quantitativa ou qualitativas.
Pesquisas quantitativas são focadas nos dados numéricos e é voltada para fornecer
alta confiança e resultados repetidos dentro de seus grupos de usuários.É preciso ter
o envolvimento de um número maior de participantes para contar as variações que
você encontrará de indivíduo para indíviduo (UNGER; CHANDLER, 2009).
Os testes quantitativos são como experimentos cientificos que precisam ser rigorosos
ou os resultados não serão confiáveis. Deve-se definir um protocolo de teste e segui-lo
consistentemente para todos os participantes (KRUG, 2010).
As pesquisas qualitativas não são focadas em níveis de segurança e da possibilidade
de repetição, mas sim ganhar contexto e percepção considerando o comportamento
do usuário.Ela depende da interpretação do projetista sobre as descobertas, a intui-
ção e o senso comum (UNGER; CHANDLER, 2009).
Nos testes qualitativos você tenta minimizar a quantidade de interação com o par-
ticipante para evitar a influência nos resultados (KRUG, 2010).
Para os testes de usabilidade é possível utilizar qualquer uma das abordagens, mas a
qualitativa é a mais acessível para aqueles que não tiveram um treinamento em méto-
dos científicos mais formais e oferece uma rica fonte de dados (UNGER; CHANDLER,
2009).
4.5. Técnicas e Métodos da Engenharia de Usabilidade 47
• Planejar a pesquisa
Algumas questões devem ser respondidas ao criar o teste de usabilidade: Estas
questões te ajudam a oferecer foco e escopo. Abaixo algumas perguntas que devem
ser respondidas no planejamento de sua pesquisa:
– Defina seu objetivo: Por que você está testando?
– Defina Usuários: Quem você está testando?
– Defina o método para representar sua aplicação: O que você está testando?
– Quais informações você está reunindo?
Nas pesquisas qualitativas geralmente queremos compreender as questões que os
usuários podem encontrar, os níveis de frustações que eles podem experimentar
e a gravidade de um problema em particular. Para os testes qualitativos devem
se pensar em medidas que serão possíveis de ser respondidas com cinco usuários
(UNGER; CHANDLER, 2009).
– Taxa de Sucesso: O grau em que o usuário foi capaz de completar a tarefa?
– Satisfação do usuário
• Usuários
Existem algumas diretrizes que podem ser adotadas para a definição da quantidade
de usuários. Nielsen (1994) definiu algumas dessas diretrizes:
– No teste quantitativo planeje uma quantidade maior de participantes. Em mé-
dia 20 por rodada de pesquisa.
– No teste qualitativo é suficiente ter entre 5 e 8 participantes.
Krug (2010) defende a ideia de que três usuários são ideais para realização de testes
de usabilidade para quem está realizando o teste por conta própria. Ele afirma que
é mais fácil encontrar três participantes do que uma quantidade maior e que é bem
provável que eles já encontrem muitos dos problemas significaticos relacionados as
tarefas que você está testando.
Em equipes ágeis, o teste com o usuário é realizado com o cliente do projeto e
envolve o especialista em usabilidade como mediador do teste (SANTOS, 2012).
• Recutramento e logística
Depois de ter feito o plano de pesquisa e definido os tipos de usuários que podem ser
inseridos na pesquisa é hora de recrutar os participantes. Para o recrutamento de
participantes é interessante gerar uma lista com os potenciais participantes do teste.
48 Capítulo 4. Usabilidade
Essa lista pode vir de usuários registrados do site da empresa relacionada; informa-
ções de contatos do cliente; e-mails para conhecidos que tenha relação com o assunto
do teste; requisições em pequenas pesquisas que pré-qualificam os participantes, e
etc. (UNGER; CHANDLER, 2009).
Você pode realizar uma filtragem com os participantes potenciais antes de seleciona-
los. As perguntas do questionário de filtragem devem ser voltadas para:
– Garantir que o participante seja um usuário das funções em que você está
testando.
– Determinar se ele se encaixa em um dos seus grupos de usuários.
– Ajudar a ter uma boa mistura de participantes.
O questionário de perfil de usuário pode ser utilizado para realizar essa filtragem de
participantes.
• Criação de guias de discussão
Para a execução do teste de usabilidade é preciso que as instruções estejem claras
aos participantes, contendo todas as informações específicas que ele precisará para
completar as tarefas com sucesso.
Os seus materiais de teste deve incluir:
– Formulário de consentimento para gravação de vídeo
– Guia de discussão para o participante, com tarefas detalhadas e perguntas
sobre a satisfação do usuário.
– Questionários
• Facilitação
• Análise e apresentação dos resultados;
• Criação de recomendações.
4.6 Usabilidade em Software Livre
Um dos grandes problemas encontrados em softwares livres é a pouca atenção dada
aos aspectos referentes a usabilidade e acessibilidade das aplicações. Acredita-se que um
dos principais problemas que contribui para a falta de usabilidade de software livre é sua
própria comunidade que apenas enfatiza na criação e, melhoria e teste do código fonte.
4.7. Processos de Usabilidade 49
Segundo Preece, Rogers e Sharp (2007), uma das causas da baixa adoção de
softwares livres em mercados de larga escala é a baixa qualidade dos estilos de intera-
ção implementados nas interfaces dos produtos. Uma grande maioria não se preocupa
com bons elementos de interface com usuário (UI).
Atualmente, algumas comunidades de software livre vêm se atentando as questões
de usabilidade como forma de se manter no mercado. Um dos casos que conhecemos foi
do Joomla que é um sistema de gerenciamento de conteúdo que nessas últimas versões
investiram em questões de usabilidade, sendo o primeiro CMS a ser totalmente responsivo.
Foi criada uma frente de desenvolvimento focado na experência do usuário que trouxe
melhorias significativas a partir da versão 3.0 do CMS. Logo em seguida o Wordpress, outro
sistema de gerenciamento de contéudo investiu em melhorias da interface se atentando
aos novos padrões adotados na web.
Uma grande dificuldade encontrada por parte de usuários com pouca experiência
se encontra na instalação de softwares livres o que acaba por desencorajar esses usuários
na utilização desses softwares.
Entender o perfil do usuário é um dos principais pontos que devem ser levados em
consideração pelos desenvolvedores de software em geral. Cada perfil de usuário tem suas
particularidades e suas expectativas quanto a utilização do sistema. Quando falamos de
usuários com experiência de uso de softwares semelhantes é preciso ter uma maior atenção
na usabilidade para que possa ter uma boa aceitação e menor impacto com as mudanças.
4.7 Processos de Usabilidade
Alguns autores como Mayhew (1999) e Hix e Hartson (1993) proposeram mode-
los de processo baseados em ciclo de vidas bem definidos para as atividades de usabili-
dade.Outro modelo muito utilizado para descrever processos de usabilidade é o proposto
pela norma ISO/IEC-13407 (1999).
O termo modelo de ciclo de vida é utilizado para representar um modelo que capta
um conjunto de atividades e a maneira como elas se relacionam (PREECE; ROGERS; SHARP,
2007).
4.7.1 Modelo Estrela
Proposto em 1989 por HIX; HARTSON, o modelo de ciclo de vida estrela derivou
do trabalho empírico de entender como os designers lidavam com os problemas de design
em IHC. Eles observaram dois diferentes modelos de trabalho: analítico e o sintético. O
primeiro parte-se da visão do sistema para a visão do usuário, já o segundo da visão do
usuário para a do sistema (CYBIS; BETIOL; FAUST, 2010).
50 Capítulo 4. Usabilidade
No modelo estrela não há especificação de ordenamento de atividades. Pode-se
ir de uma atividade à outra há qualquer momento, desde que passe primeiramente pela
avaliação. Sempre que uma atividade for completada deve-se avaliar o seus resultados.
Figura 4 – Ciclo de Vida Estrela
4.7.2 O ciclo de vida da Engenharia de Usabilidade - Mayhew
O ciclo proposto por Mayhew (1999) oferece uma visão holística acerca dessa
engenharia e uma descrição detalhada de como podemos realizar os testes de usabilidade.
A primeira etapa do ciclo é a análise dos requisitos. Mayhew propõe quatro tipos
de atividades de análise de requisitos que são detalhadas abaixo:
• Análise do perfil do usuário: Os projetistas devem conhecer os atributos pessoais
e suas habilidades para cada tipo de usuário identificado.
• Análise do contexto da tarefa: Os projetistas devem conhecer os objetivos e
resultados, a estrutura, duração, custos e etc. de cada tarefa a ser realizada.
• Análise das possibilidades e restrições da plataforma: Verificar quais são as
possibilidades e restrições em termos de equipamentos, sistems operacionais e etc.
• Análise dos princípios gerais para o projeto: Atividade relacionada à pes-
quisa e catalogação dos conhecimentos de ergonomia disponível para a concepção
da interface no tipo de contexto de uso.
Depois da análise dos requisitos é preciso especificar as metas de usabilidade do
futuro sistema. A norma ISO 9241:11 orienta como podemos especificar essas metas.
Na etapa de projetos, testes e implementação, Mayhew propôs que os ciclos devem
se repetir de forma a tratar três nivéis de aspectos de uma interface: No primeiro nível
4.7. Processos de Usabilidade 51
sendo a interface definida conceitualmente; no segundo nível refere-se as definições em
termos de estilo; e no terceiro nível as interações e componentes relacionados com os
contextos das tarefas especiais. A última fase é a de instalação do sistema onde depois
que o usuário já estiver acostumado com o sistema ele pode dar um feedback sobre a
usabilidade do produto de forma mais fidedigna por já ser um "especialista"da ferramenta
como cita a autora.
Uma das técnicas utilizadas para coletar feedback são os testes de usabilidade no
local do trabalho dos usuários ou utilizando métodos de análise como entrevistas, obser-
vações, questionários, grupos de discussões. Esses métodos serão detalhados no pŕoximo
cápitulo.
4.7.3 Design Centrado no Usuário
O DCU surgiu da IHC e consiste em uma metodologia de design de software para
desenvolvedores e designers. Foi definida pela norma ISO 13407 (Human Centered Design
Processes for Interactive Systems) e tem como objetivo definir um processo necessário
ao desenvolvimento de produtos fáceis de utilizar na qual deve envolver os usuários no
processo de desenvolvimento e na avaliação dos produtos.
Sabemos que a ciência experimental que utiliza-se dos métodos empíricos tradi-
cionais para coletar dados e testar hipóteses sobre o comportamento humano aplicam-se
de várias técnicas em nome de pessoas. Essa abordagem é preocupada com os usuários
quando as representa mas ela não leva em conta diversos aspectos do usuário real, por
não envolvê-los no processo. Não basta fazer para o usuário, é preciso fazer com o usuário
(EASON, 2005).
No Design Centrado no usuário (DCU) diferente dos métodos empíricos tradicio-
nais que tem o usuário apenas como referência, no DCU o usuário tem que ser o elemento
central e é necessário envolvê-lo do início ao fim do projeto. Baseia-se nas necessidades,
desejos e limitações das pessoas. Deve-se iniciar com usuários e suas necessidades em vez
de começar com a tecnologia. Lowdermilk (2013) afirma que "para criar produtos que os
usuário amem, é necessário incluir os usuários no processo de criação dos produtos".
Gould e Lewis (1985) estabeleceram alguns princípios para o desenvolvimento
centrado no usuário na decada 70 que são utilizados até hoje que são: Foco desde o inicio
nos usuários e nas tarefas, medidas empiricas e design interativo. O processo do design
centrado no usuário pode ser dividido em 3 fases: análise, desenvolvimento e pós-liberação.
4.7.3.1 ISO 13407 e 9241-210
A ISO 13407 define um processo geral para incluir atividades centradas em humano
através do ciclo de vida de desenvolvimento sem especificar métodos exatos (SANTOS,
52 Capítulo 4. Usabilidade
2012).
A norma é caracterizada por quatro princípios: Ativo envolvimento do usuário;
alocação apropriada de funções entre usuários e tecnologia; Testes de solução de design;
Design multidisciplinar.Em 2010 essa ISO foi revista e renomeada para a ISO 9241-210.
Existem quatro atividades de Design Centrado no Usuário que devem estar pre-
sentes no inicío do projeto:
• Entender e especificar o contexto de uso;
• Especificar os requisitos de usuário;
• Produzir soluções de design;
• Avaliar o design frente aos requisitos;
A ISO 13407 propõe que o envolvimento do usuário seja uma prática frequente em
empresas que desenvolvem sistemas interativos.
Figura 5 – Ciclo do Design centrado no humano - Norma ISO 13407
4.8 Aplicação de usabilidade em métodos ágeis
Os métodos ágeis é uma abordagem de desenvolvimento que têm como princípios
um conjunto de valores com foco no cliente e nas pessoas envolvidas, na entrega constante
de software funcional, no desenvolvimento iterativo baseado em ciclos curtos de entrega
e na aceitação da constante mudança dos requisitos ao longo do desenvolvimento.
Tanto os métodos ágeis e o IHC tem esses mesmos príncipios, o que seria interes-
sante a aplicação das técnicas utilizadas em IHC no contexto de uma abordagem ágil. Essa
semelhança entre os valores proporciona um quadro favorável à integração minimalista de
4.8. Aplicação de usabilidade em métodos ágeis 53
pŕaticas de IHC em ambientes ágeis. Podemos citar alguns desse valores como por exem-
plo: (i) ciclos curtos com entregas contínuas e incrementais, que favorecem a aplicação
de técnicas de prototipagem; (ii) forte envolvimento do usuário que favorece a aplicação
de princípios de projetos participativos e (iii) programação em pares onde em IHC ge-
ralmente a avaliação de usabilidade é feita em pares (BARBOSA; FURTADO; GOMES,
2008).
Segundo Cybis, Betiol e Faust (2010) as características da abordagem ágil facili-
tam na utilização da ergonomia e da usabilidade durante o desenvolvimento de software,
mas afirma que os ergonomistas e engenheiros de usabilidade deverão adaptar suas técni-
cas de análise, modelagem, projeto e teste adotando-se os preceitos do manifesto ágil.
As adaptações são realmente necessárias, principalmente na questão da granula-
ridade da pesquisa, no tempo gasto com ela e na maneira de relatar as descobertas de
usabilidade (SANTOS, 2012).
Segundo Barbosa e SILVA (2010) é preciso ter cuidado em relação à qualidade no
uso, pois raramente a comunidade ágil cita usuários ou a distinção entre usuário e cliente.
Hodgetts (2005) afirma que os métodos ágeis são quase sempre apresentados
sob a visão dos programadores, deixando de lado outras disciplinas como a UED (User
Experience Design). Ele discute em seu artigo as experiências na integração de práticas
do Desig da experiência do usuário em iniciativas de processos ágeis em organizações
que utilizam XP e Scrum. Ele registrou os eforços da equipe com abordagem centrada
apenas em métodos ágeis e depois com a integração das melhores práticas de experiência
do usuário.
4.8.1 Estudos correlatos
Alguns estudos foram feitos tentando fazer essa integração da usabilidade em mé-
todos ágeis.
Constantine e Lockwood (2002) foi um dos primeiros a iniciar a discussão sobre
o tema. Sua proposta é mostrar que UCD está prontamente integrado aos métodos ditos
"leves". Ele afirma que XP e os demais métodos ágeis compartilham das mesmas fraquezas
apresentadas por processos tradicionais como o processo unificado quando se refere à
usabilidade e ao desenho de interface do usuário.
Winter et al. (2011) apresentou um estudo de caso da utilização de um pacote para
teste de usabilidade que foi chamado de UIQ Technology Usability Methods (UTUM). O
objetivo do estudo foi determinar como balancear as demandas de resultados ágeis e
formais na execução de testes de usabilidade para garantia da qualidade.Os dados do
estudo foram obtidos através da observação, entrevistas não estruturada, participações de
reuniões com os stakeholders e documentos do projeto.
54 Capítulo 4. Usabilidade
Memmel, Gundelsweiler e Reiterer (2007) mostra que é possível unir IHC e enge-
nharia de software sob a perspectiva ágil com a utilização de um ciclo de vida de interface
de usuário multidisciplinar e de Engenharia de softwre chamado CRUISER.
Barbosa, Furtado e Gomes (2008) propõem uma estratégia para institucionaliza-
ção da usabilidade com base em conceitos de desenvolvimento e gestão ágil. Ele realizou
um workshop para reflexão sobre a importância em aplicar as novas práticas.
Nielsen e Madsen (2012) relatam um estudo na qual realizaram entrevistas com
12 especialistas em usabilidade de diferentes países no intuito de analisar a influência dos
métodos ágeis nos testes de usabilidade.
Lee, Judge e McCrickard (2011) relata em seus estudos a utilização da abordagem
de usabilidade ágil eXtreme Scenario-based Design (XSBD) na qual concluiram que os
desafios que o time encontrava eram relacionados à comunicação, colaboração e compar-
tilhamento de informação.
Wolkerstorfer et al. (2008) em seu estudo mostra adaptações feitas ao processo
do Extreme Programming (XP). Ele integrou cinco instrumentos de IHC com o processo
do XP. Os instrumentos são: testes de unidade estendidos para avaliação de usabilidade
automatizada; Extreme Personas (variação do método clássico de personas); estudos de
usuários para tomar conhecimento sobre o usuário final; avaliações feitas por especialistas
em usabilidade e testes de usabilidade com usuários.
LEITE (2013), analisou a utilização de métodos de inspeção da usabilidade no
contexto de uma startup. Foi abordado duas modalidades de avaliação heuristica nessa
pequan empresa de desenvolvimento de software que utiliza o método ágil Scrum. Como
conclusão do estudo, relataram que a avaliação tradicional encontrou mais problemas de
usabilidade e maior número de heurísticas violadas.Já na avaliação heurística colaborativa
as médias de severidades atribuidas pelos avaliadores eram maior, no qual encontravam
mais problemas sérios do que na avaliação tradicional, além de o tempo gasto foi menor
do que na tradicional. A avaliação colaborativa apresentou características que permitia a
melhor integração com ambientes ágeis.
Outro estudo encontrado foi a proposta da metodologia AgilUS que é um método
de desenvolvimento ágil que baseia-se no conceito de usabilidade e na necessidade de de-
senvolver software usável. Essa metodologia foi resultado de uma das linhas de investigação
desenvolvida pelo Centro de Engenharia de Software da Universidade Central da Venezu-
ela. O objetivo do método AgilUS é proporcionar um conjunto de atividades organizadas
para construir a usabilidade de design de interface do usuário durante o desenvolvimento
do software ACOSTA.
4.8. Aplicação de usabilidade em métodos ágeis 55
4.8.2 DCU Ágil
Pode ser definido o DCU ágil como a prática de design centrado no usuário quando
conduzida dentro de uma metodologia ou filosofia de desenvovlimento ágil de software
(SANTOS, 2012).
O ciclo de DCU ágil foi proposto por Sy (2007) e integra tantos as atividades
de DCU como as de desenvolvimento em um único ciclo, trabalhando nas mesmas ca-
racterísticas e garantindo que as investigações de usabilidade serão tratadas durante a
interação.
Segundo Najafi e Toyoshiba (2008) o design centrado no usuário pode ser incorpo-
rado no desenvolvimento ágil sem grandes impactos no processo. No método de desenvol-
vimento ágil scrum, uma funcionalidade é desenvolvida, testada e documentada em uma
sprint assim como no design centrado no usuário.
Segundo Santos (2012) o grande desafio do DCU ágil é encontrar a melhor maneira
de realizar as atividades de pesquisa do usuário, design de versões que atendem as necessi-
dades dos usuário, construção de versões interativas e realização de testes de usabilidade,
dentro de um ambiente de desenvolvimento com métodos ágeis, tendo a participação dos
usuários tipicos em todas as atividades.
A modelagem e projeto de interfaces devem ser orientados a padrões de projeto e
as avaliações de ergonomia, testes de usabilidade e especificações de revisões de interface
devem ser realizados rapidamente (CYBIS; BETIOL; FAUST, 2010).
Pesquisas relatam que praticantes de UX que passaram a trabalhar em ambientes
ágeis não querem mais retornar ao método antigo de desenvolvimento baseado no modelo
cascata. Em média, essas equipes levam de 6 a 12 meses para se adptar ao novo ambiente
(SANTOS, 2012).
O termo experiência do usuário é utilizado na comunidade ágil para qualquer
atividade relacionada com a pesquisa do usuário, DCU, usabilidade, design de interfaces.A
utilização do termo não indica que eles realizam todas as atividades de UX (SANTOS,
2012).
Segundo Dickinson e Kunama (2010) a chave para a integração de DCU com
métodos ágeis é assegurar que os resultados da pesquisa de usuário são comunicados e
entendidos de forma eficaz dentro de uma equipe ágil.
4.8.3 DCU e XP
Foram encontrados alguns estudos que descrevem a integração do IHC com as
práticas de Programação Extrema (XP). Segundo McInerney e Maurer (2005) métodos
ágeis e design centrado no usuário possuem uma cultura distinta mas eles mostraram que
56 Capítulo 4. Usabilidade
é possivel unir essas duas abordagens.
O processo de usabilidade ágil é integrar os instrumentos de IHC dentro dos pro-
cessos clássico de XP. Wolkerstorfer et al. (2008) usam o dcu ágil desde 2007 e que até
hoje não houve nenhum problema entre as culturas e que tanto os especialistas de usa-
bilidade quanto os desenvolvedores estão bem integrados.Pode-se encontrar vantagens na
combinação das duas abordagens.
Em 2008 foi proposto uma metodologia revisional institulada XPlus que insere as
técnicas de design e de usabilidade em determinadas fases do ciclo de desenvolvimento
de software.O XPlus agrega algumas práticas de User Experience às práticas tradicionais
de XP. A figura mostra uma visão geral do processo de desenvolvimento de software de
XPlus. (GUIMARAES; CHAVES, )
Figura 6 – Visão geral do processo de desenvolvimento de software de XPlus
Essa metodologia considera a interface um dos aspectos mais importantes de um
software.Ela envolve as novas pŕaticas de UX no processo natural de XP.
O papel de designer de interação não é reconhecido no núcleo eXtreme Program-
ming (XP) da equipe e o XP não tem nenhum processo explícito para lidar com o design
de interação.Em seu estudo Ferreira, Noble e Biddle (2007) relatam como as equipes
combinaram as atividades de design de interação com o XP.
A natureza iterativa de desenvolvimento XP necessário que os designers de intera-
ção tem envolvimento contínuo com o desenvolvimento do produto influenciou a natureza
da relação entre os designers de interação e os desenvolvedores.
Vasconcelos, Garcia e Turnell (2003) descreveram um processo ágil centrado em
usabilidade chamado XPU no qual tinha como objetivo prover à equipe de desenvolvi-
mento um modelo para a construção de sistemas de software centrado no usuário que
valorizasse a usabilidade como característica fundamental da qualidade.
4.9. Princípios ágeis aplicados ao DCU 57
O XPU serve para guiar o time de desenvolvimento, passo a passo em todo o
projeto, seguindo técnicas e artefatos simplificados afim de não se ter apenas sistemas
portáteis reutilizaveis ou acoplados, mas sim com uma interface que refletiam as carac-
terísticas e as necessidades dos usuários. Um problema encontrado é na sustentação do
processo de desenvolvimento baseado em técnicas bem definidas, oq eu contraria o mani-
festo ágil.
4.9 Princípios ágeis aplicados ao DCU
Alguns princípios e boas práticas de métodos ágeis foram levantadas para a apli-
cação no design de sistemas centrado no usuário.
1. Coompreender e identificar as necessidades reais dos usuários
O Objetivo dessa etapa é conhecer o usuário alvo. Deve-se projetar ferramentas que
irão dar suporte aos objetivos e atividades das pessoas.
Algumas técnicas são utilizadas para identificar as necessidades dos usuários como
a observação natural que serve para responder a questão do tipo: o que e como as
pessoas fazem? E as entrevistas que responde o que as pessoas pensam e dizem. Os
resultados da pesquisa devem ser comunicados para a equipe.
2. Focar na essência
O foco na essência ajuda a desenvolver soluções que atendem às reais necessidades
dos usuários diminuindo os riscos de desenvolvimento de funcionalidades com pouco
ou nenhum uso.
A ideia desse príncipio é que deve-se começar a desenvolver apenas pelo que é
essencial, começando pela menor unidade de um sistem sem perder a visão de um
todo.
3. Iterar mais rápido
É importante colocar o produto nas mãos dos usuários para se ter um feedback o
mais cedo possível. Quando a iteração é feita de forma rápida e começando cedo
podemos identificar os problemas com antecedência o que diminui o tempo com
retrabalho e evita que o produto não atenda aos usuários.
4. Criar designs alternativos
Rettig em 1994 disse que "para ter uma boa idéia é preciso que se tenha várias". A
ideia do autor da frase é que devemos pensar e criar várias soluções para um mesmo
problema afim de que possa ter mais possibilidades de escolha.
58 Capítulo 4. Usabilidade
5. Prototipar em baixa resolução
Os protótipos de baixa resolução permite visualizar uma solução de forma mais rá-
pida e concreta economizando tempo de design e desenvolvimento. Esses prótotipos
ajuda a comunicar e entender idéias e serve para validar uma solução. Eles são úteis
pois tendem a ser simples, baratos e de rápida produção.
Um exemplo de prótotipo de baixa fidelidade são os storyboard que serão detalhados
no próximo cápitulo.
A prototipação aumenta a comunicação entre a equipe de desenvolvimento e os usuá-
rios finais, funcionando como uma alternativa “barata"para explorar alternativas de
desenho.
6. Menos documentação, mais comunicação
É essencial que tenha uma boa comunicação em todo o processo entre os desenvol-
vedores, designs e stakeholders envolvidos no projeto.
7. Pesquisa e design em paralelo ao desenvolvimento
8. Testes de usabilidades ágeis
Os testes de usabilidade devem ser feitos em todos os ciclos do projeto. Recomenda-
se que os testes sejam feitos mais vezes e que seja menos formal como são feitos
atualmente. Os resultados encontrados nos testes deve ser comunicado à equipe
para que possa corrigir os erros graves rapidamente.
No próximo capítulo detalharemos como funciona um teste de usabilidade, os tipos
existentes e as práticas identicadas pela comunidade de arquitetura da informação
e áreas correlatas.
9. O fim não é o lançamento
No fim de cada ciclo lança-se o mínimo adequado às necessidades reais dos usuários.
Ao observar o uso real identificamos que existem novas formas para usar a ferramenta
e podemos propor novas melhorias para o sistema.
4.10 Teste da Usabilidade vs. Teste de Aceitação do Usuário (UAT)
Para Preece, Rogers e Sharp (2007) teste de usabilidade e teste de aceitação do
usuário muitas vezes são confundidos. O UAT pode trazer as questões de usabilidade,
mas não é o único método para ser utilizado em um projeto. Por ser feito tardiamente
as mudanças baseadas em UAT são muito mais caras. Já os testes de usabilidade fo-
ram projetados para oferecer informações verdadeiras de desempenho desde o início do
processo.
4.11. Considerações finais 59
O principal objetivo do teste de aceitação do usuário é servir como uma verificação
final de que a aplicação atendeu aos requisitos funcionais estabelecidos pelo cliente.
4.11 Considerações finais
A integração entre os processos de usabilidade e métodos ágeis é esperada e possível
visto que tanto os métodos ágeis como os processo de usabilidade em em comum carac-
terísticas que colocam o foco do desenvolvimento nas necessidade e anseios dos usuários
finais, na interação entre os stakeholders envolvidos e na qualidade final do produto a ser
desenvolvido.
61
5 Observações do Estudo
Durante este capítulo, será apresentada uma introdução sobre o ambiente de tra-
balho e a plataforma de desenvolvimento, chamada Noosfero. A partir desta introdução
apresentaremos os a avaliação de usabildiade, assim como os testes e as funcionalidades
desenvolvidas dentro do processo de colaboração com esta plataforma.
5.1 Estudo de Caso - Noosfero
Noosfero1 é uma plataforma desenvolvida pela Colivre (Cooperativa de Tecnologias
Livre)2, possui licença AGPL e é utilizado, principalmente em universidades públicas, para
desenvolvimento de redes colaborativas. 3 O noosfero foi desenvolvido na linguagem de pro-
gramação Ruby, versão 1.8.7, e utiliza o framework Model-View-Controller (MVC) para
aplicações web Ruby on Rails, versão 2.3.5. A escolha destas tecnologias, por parte dos
criadores do Noosfero foi baseada fato de que o Ruby possui sintaxe simples, elegante e de
fácil leitura, o que aumenta a manutenibilidade do sistema, uma característica importante
num projeto de software livre que visa atrair desenvolvedores externos (MEIRELLES,
2013).
5.1.1 Desenvolvimento no processo de colaboração ao noosfero
Por tratar de um software livre, a plataforma Noosfero possui uma grande quanti-
dade de colaboradores, formado por equipes de desenvolvimento como na Universidade de
Brasília, ou por desenvolvedores independentes. Assim, para que haja sucesso na colabo-
ração, são feitas exigências durante o desenvolvimento, assim como testes bem definidos
para aprovar novas funcionalidade.
Além da utilização da linguagem de programação Ruby, o desenvolvimento da
plataforma noosfero também se baseia em JavaScript, CSS, dentre outras linguagens,
como pode-se ver na figura abaixo:
O desenvolvimento para a plataforma Noosfero é realizado em ciclos e, pela Colivre,
possui as seguintes fases: desenvolvimento, release 1, release 2 e release final.
1 noosfero.org2 colivre.coop.br3 http://softwarelivre.org/colivre/blog/projeto-noosfero
62 Capítulo 5. Observações do Estudo
Figura 7 – Desenvolvimento noosfero
5.1.1.1 Fase de Desenvolvimento
Antes da fase de desenvolvimento for iniciada é necessário que seja feita a do-
cumentação do que será desenvolvido. Os desenvolvedores responsáveis criam um action
item (item de ação), contendo a história de usuário ou os requisitos do novo recurso. Um
action item pode ser descrito como uma feature (novo recurso) ou como um bug (defeito)
encontrado, como demonstrado nas figuras abaixo:4
Figura 8 – Descrição de feature - noosfero
Além da documentação, é necessário o envio de um email a comunidade descre-
vendo o que será desenvolvido. A partir deste email, a comunidade irá avaliar a funcio-
nalidade descrita e decidir se é um funcionalidade importante para se incorporar ou não.
Este processo de avaliação tem a duração de uma semana, geralmente.5
Com a aprovação da comunidade são feitas as revisões do ciclo de desenvolvimento,
que deve seguir os seguintes passos:
1. Criar um ‘merge request’ juntamente com o código;
2. Código é revisado pela comunidade;4 noosfero.org5 noosfero.org
5.1. Estudo de Caso - Noosfero 63
Figura 9 – Descrição de bug - noosfero
3. Código é bom?
Se sim:
Vá para o passo 4;
Se não:
‘Merge request’ é rejeitado e as razões por tal são comentadas e respondidas;
Desenvolvedores revisam o que está errado;
4. Código é incluido no código principal.
5.1.1.2 Fase de Release 1
A entrega da release consiste na instalação da nova versão do código no repositório
de testes, assim como no código principal quando não houver mais defeitos, ou todos
os defeitos encontrados forem tratados devidamente. Porém se algum erro crítico for
encontrado e não for tratado a tempo da release final, o lançamento pode ser adiado para
a próxima release.
5.1.1.3 Fase de Release 2
A release 2 não é obrigatória, so ocorre se houver muitas mudanças na release 1 e
requerer novos testes. Vale lembrar que os procedimentos realizados para aprovar a release
2 são os mesmos da release 1
5.1.1.4 Release Final
A versão final do código é lançada após todos os testes serem aprovados nas releases
1 e 2, assim o código pode ser atualizado para o código principal do noosfero, encerrando
64 Capítulo 5. Observações do Estudo
o ciclo de desenvolvimento.6
5.1.2 Aplicações
O estudo deste trabalho é baseado em duas aplicações que utilizam a plataforma
noosfero, o portal Participa Br e o Comunidade UnB.
O Portal da participação Social é um portal que agrega informações sobre oportu-
nidades de participação social no governo federal e estimula a formação de comunidades
em torno de temas ligados à participação. Informa sobre as consultas públicas, oferece
ambientes para interação em vídeo e chat em eventos de governo. É um repositório das me-
todologias das conferências de políticas públicas. O Portal capta demandas da sociedade
que não passem, necessariamente, pelos fluxos formais de participação. É uma plataforma
para ampliar o debate entre a sociedade civil e o governo. [Citar fonte]
A rede Comunidade UnB, que se encontra em ambiente de testes, porém dispo-
nível para acesso externo, contando com aproximadamente 160 usuários ativos. A rede
Comunidade UnB é uma instância do noosfero instalada através de um pacote em um
servidor do Centro de Difusão de Tecnologia e Conhecimetno (CDTC)7 da UnB. O pro-
pósito da rede Comunidade UnB é tornar-se um ambiente de colaboração entre os alunos
da Universidade de Brasília, tanto de graduação quanto de pós-graduação, possibilitando
criação comunidades e blogs para discussões, ou a disponibilização de artigos, trabalhos
de graduação e pós-graduação onde qualquer membro da universidade tenha acesso.
5.2 Estudo sobre Usabilidade - Portal da Participação Social
5.2.1 Introdução
O Portal da Participação Social 8 é um portal que agrega informações sobre opor-
tunidades de participação social no governo federal e estimula a formação de comunidades
em torno de temas ligados à participação. Informa sobre as consultas públicas, oferece
ambientes para interação em vídeo e chat em eventos de governo. É um repositório das me-
todologias das conferências de políticas públicas. O Portal capta demandas da sociedade
que não passem, necessariamente, pelos fluxos formais de participação. É uma plataforma
para ampliar o debate entre a sociedade civil e o governo.
6 noosfero.org7 www.cdtc.org.br8 participa.br
5.2. Estudo sobre Usabilidade - Portal da Participação Social 65
5.2.2 Justificativa
No ano 2000 foi criado o programa de Governo Eletrônico (e-GOV) 9 que têm como
principais objetivos democratizar o acesso a informação e dinamizar a prestação de servi-
ços públicos eletrônicos com foco em eficiência e efetividade das funções governamentais
prestadas ao cidadão.
O Governo Federal adotou várias práticas de padrões para melhorar o acesso e
a divulgação das informações e dos serviços do governo eletrônico, respeitando as parti-
cularidades de cada cidadão. Por isso foi criado o Modelo de Acessibilidade do Governo
Federal (e-MAG) 10 que contém um conjunto de recomendações para tornar os sítios e
portais acessíveis para uma maior quantidade de pessoas possíveis.
O objetivo era de estabelecer padrões de qualidade de uso, desenho, arquitetura
da informação e navegação, desenvolvimento e manutenção na gestão dos sítios governa-
mentais. O e-PWG 11, como ficou conhecido, são padrões web para o Governo eletrônico.
Foi feita uma análise do sítio participa.br em parceria com o Instituto Federal do
Rio Grande do Sul (IFRS) onde foi criado um relatório para orientar e sugerir correções
que facilitarão o acesso ao seu conteúdo quanto as recomendações sobre o Modelo de
Acessibilidade em Governo Eletrônico (e-MAG) e com os Padrões Web em governo Ele-
trônico (e-PWG). Essas recomendações buscam levantar problemas que impactarão na
experiência de uso do portal pelo cidadão.
A ideia de fazer esse estudo experimental era de conhecer e aplicar as técnicas
existentes na engenharia de usabilidade em um contexto real de uso para verificar como
funcionam as técnicas utilizadas na engenharia de usabilidade para avaliação de um web-
site.
Como já existia um estudo referente sobre a Acessibilidade do portal participa.br
o nosso estudo se deu em avaliar a qualidade em uso do portal no sentido de verificar a
satifação dos usuários ao utilizar o portal.
Primeiramente foi preciso realizar um checklist de usabilidade para verificar os
possíveis problemas no portal antes de realizar os testes com os usuários. Foi utilizado as
heurísticas de Nielsen para identificação dos problemas de usabilidade.
9 www.governoeletronico.gov.br10 e-MAG: Cartilha de acessibilidade do governo eletrônico11 e-PWG: Padrões web para o governo eletrônico
66 Capítulo 5. Observações do Estudo
5.2.3 Definição do Estudo Experimental
5.2.3.1 Objetivo Global
Analisar a interação dos usuários com o portal participa.br a fim de avaliar a
qualidade em uso dos usuários com este portal.
5.2.3.2 Objetivos de Medição
• Conhecer quem são os usuários do Portal da Participação Social.
• Verificar problemas de usabilidade no Portal da Participação Social
• Avaliar de forma subjetiva o grau de satisfação dos usuários com a utilização do
portal participa.br.
5.2.3.3 Objetivo do Estudo
Analisar Portal da Participação Social (participa.br)Com propósito de Avaliar Qualidade em Uso (ISO/IEC 9126-4)Com respeito ao Satisfação do usuárioDo ponto de vista de UsuárioNo contexto de Portais Governamentais
Tabela 1 – Objetivos do Estudo
5.2.3.4 Questões
A partir do objetivo de medição estabelecido no quadro 1 foram definidas questões
sobre o que é preciso saber de forma a apoiá-la a entender se o objetivo específico foi
alcançado, e para cada questão foram definidas as métricas relacionadas no quadro 2:
Questões MétricasDiretrizes parainterpretação
Q1. Qual o perfil do usuárioque utiliza o portal participa.br?
PerfilAnálise de Dados Estatísticos,criação de personas, análisedos dados qualitativos.
Q2. Qual o grau de satisfaçãodo usuário que utiliza o portalparticipa.br
Grau de satisfaçãodo usuário
Escore da satisfação globalpelo usuário (OVERALL)
Q3. Quantidade de tempo gastopara realizar as tarefas
Duração Tempo gasto
Tabela 2 – Questões de Pesquisa
5.2. Estudo sobre Usabilidade - Portal da Participação Social 67
5.2.4 Metodologia
5.2.4.1 Análise do Perfil dos Usuários
Foram levantadas algumas técnicas na qual podemos identificar o perfil dos usuá-
rios do portal da Participação Social.
1. Dados Estatísticos (Google analytcs, Piwiki, entre outros): Através dos dados
estatisticos é possível identificar algumas informações sobre o perfil dos usuários que
acessam o portal. Nas pesquisas quantitativas não são necessários o contato direto
com o usuário. Esses dados estatísticos podem ser coletados de base de dados, redes
sociais ou sistemas de análises de sites.
2. Questionário de identificação de perfil dos usuários: Para identificar o perfil
dos usuários do Portal da Participação social é necessário realizar uma pesquisa qua-
litativa para levantamento das principais caracterísiticas contextuais dos usuários
típicos, de modo a comprender quem são, qual o conhecimento e experiência com
a internet e como utilizam para realizar seu trabalho acadêmico ou profissional. A
realização dessa pesquisa será feita com os usuários do Portal da Participação Social12
A análise do questionário servirá para entender o perfil dos usuários do Portal da
participação social, através da investigação de seus interesses. Foi levantado também
algumas questões referentes ao uso das funcionalidades do portal da participação
social.
3. Identificação de Personas: Para a definição de usuários podemos utilizar a téc-
nica de “Persona” que são personagens fictícios criados com base em dados reais.
Os Personas atuam como representantes dos usuários reais e representam as neces-
sidades de um grupo maior.
A utilização de Personas permite ter um maior foco no usuário, deixando o pro-
jeto centrado no usuário. É utilizado para a identificação de requisitos, criação de
cenários e user stories.
Para podermos identificar os personas primeiramente temos que realizar uma pes-
quisa quantitativa no qual podemos identificar os grupos de usuários. Após a identi-
ficação dos grupos de usuários é realizado a pesquisa qualitativa (entrevistas, coleta
de dados) na qual podemos identificar as necessidades dos usuários de um determi-
nado portal.
Para criação do persona será necessário realizar entrevista com 3 pessoas de cada
grupo alvo (universitários, ativistas políticos, servidores públicos, etc).
12 participa.br
68 Capítulo 5. Observações do Estudo
5.2.4.2 Paradigma e Técnica de Avaliação
As medidas de usabilidade do sistema foram obtidas considerando-se três fatores:
eficácia, eficiência e satifação de uso.
Neste experimento foi adotado como paradigma de avaliação o Teste de Usabilidade
que consiste em avaliar o desempenho dos usuários na execução de tarefas cuidadosamente
preparadas, tarefas estas dentro do escopo do sistema. Esse desempenho pode ser avaliado
no quesito, número de erros e tempo de execução da tarefa.
A avaliação da usabilidade coletará tantos dados subjetivos em um cenário real
como dados objetivos. Os dados subjetivos serão coletados através de opiniões dos partici-
pantes, comentários em relação ao uso do portal da participação social. Os dados objtivos
consistem em medidas de tempo e desempenho dos participantes.
Para avaliar a usabilidade do portal participa.br serão utilizadas as técnicas:
Técnica DescriçãoObservar Usuários Um observador irá registrar o tempo gasto por cada par-
ticipante para concluir o estudo de caso, avaliar a ferra-menta e se necessitou de alguma ajuda
Perguntar aos usuários Os questionários ASQ e PSSUQ de satisfação dos usuá-rios será utilizado para coletar as opiniões dos partici-pantes.
Tabela 3 – Técnicas de avaliação para os testes com usuários
5.2.4.3 Heurísticas de Usabilidade
Segundo as pesquisa realizadas é necessário que antes que execute um teste de
usabilidade seja feito uma avaliação da usabilidade por parte de especialistas de usabili-
dade. Através das heurísticas de Nielsen identificamos os problemas inerentes ao portal
da participação social.
5.2.4.4 Instrumentos para coletas de dados
Os intrumentos de coletas de informações utilizados são dois questionários que são
amplamentes utilizados para medir a satisfação do usuário com produtos interativos e
fornecem medidas padronizadas. São eles o After-Scenario Questionnaire (ASQ) 13 e o
Post-Study System Usabiliy Questionnaire (PSSUQ).
Optamos por não utilizar um questionário de satisfação próprio, pois necessitaria
validar antes de ser utilizado. Utilizamos então questionários já validados, o que facilitaria
em nossa análise dos resultados.
13 ASQ: Proposto por Lewis
5.2. Estudo sobre Usabilidade - Portal da Participação Social 69
O ASQ é destinado ao uso em testes de usabilidade baseados em cenários. Em
nosso trabalho definimos 6 cenários de uso com o objetivo de medir a satisfação relativa a
cada tarefa. Possui três itens que abordam os seguintes componentes de usabilidade: (1)
facilidade de conclusão da tarefa, (2) tempo necessário para completar uma tarefa e,(3) a
adequação das instruções ou materiais de apoio fornecidos.
O PSSUQ é aplicado apois a conclusão de todos os cenários com o próposito de
fornecer uma avaliação geral geral da usabilidade do sistema. pois permite uma avalia-
ção de usabilidade mais ampla, podendo avaliar 4 fatores e usabilidade (satifação geral,
utilidade do sistema, qualidade da interface e qualidade da informação).
O objetivo do teste de usabilidade é exibir os problemas de usabilidade por meio da
voz dos usuários típicos. Como cada um dos usuários participantes do teste se comporta
na realização das atividades.
5.2.4.5 Cenários para teste de Usabilidade
Foram levantadas algumas tarefas que devem ser executadas para a realização do
teste de usabilidade. As tarefas foram pensadas levando em consideração as necessidades
dos usuários do portal da participação social. Tarefas que os usuários-alvo executariam
mais frequentemente e tarefas que poderiam apresentar problemas para a compreensão e
execução do usuário.
1. Faça seu cadastro no portal participa.br e ative sua conta.
2. Personalize o seu perfil inserindo uma foto, escolha 5 categorias de interesse.
3. Localize e adicione Jônatas Medeiros de Mendonça à sua rede.
4. Localize e ingresse na comunidade Participação Social. Informe a quantidade de
membros.
5. Localize a pessoa Henrique Parra Filho e infome a quantidade de amigos, no de
comunidades.
6. José deseja criar um artigo para seu blog. Ele possui o texto já criado em doc, mas
precisa inserir alguns outros detalhes em seu artigo como: links, imagens, tamanhos
de fonte e subtítulos e inserir a licença de uso.
7. João necessita criar um outro artigo e inserir a mesma imagem.
8. Visualizar galeria de imagens, remova a imagem adicionada e adicione novas ima-
gens.
9. Entre no portal e acesse o painel de controle e modifique a aparência de seu perfil.
70 Capítulo 5. Observações do Estudo
10. Escreva uma descrição para o seu blog e inseria uma imagem.
11. Crie um conteúdo para sua página e adicione um item de menu para esse novo
conteúdo.
12. Adicione um novo bloco na página de seu perfil.
13. Crie um questionário Pairwise.
5.2.5 Planejamento
5.2.5.1 Definição de Hipóteses
Hipótese Nula (H0): A média do grau de satisfação dos usuários que já utiliza-
ram o portal seria maior do que quem nunca utilizou?
Hipótese Alternativa (H1): O grau de satisfação dos usuários que já tinha
contato com o portal é diferente dos que nunca tiveram acesso?
5.2.5.2 Seleção dos Indivíduos
Na primeira fase do experimento serão escolhidos pessoas com diferentes perfis
que trabalham na Presidência da República e que já utilizaram o Portal da Participação
Social. Na segunda fase seriam escolhidas pessoas que nunca utilizaram o portal.
5.2.5.3 Variáveis
a. Independentes
Foram identificadas as seguintes váriavéis idependentes:
• A interface do Portal da Participação Social
• Os cenários/tarefas para realização
• Perfil do usuário
• Contexto da avaliação
b. Dependentes
5.2. Estudo sobre Usabilidade - Portal da Participação Social 71
Nome Abreviação EntidadeFaixade Contagem
Regra decontagem
Grau deSatisfaçãodo Usuário
OVERALL Satisfação
DiscordoFortemente /ConcordoFortemente
Avalia ositens 1 até 19.
Grau deUtilidadedo sistema
SYSUSE Utilidade
DiscordoFortemente /ConcordoFortemente
Avalia ositens 1 até 8.
Grau deQualidadeda Informação
INFOQUALQualidadeda Informação
DiscordoFortemente /ConcordoFortemente
Avalia ositens 9 até 15.
Grau deQualidadeda Interface
INTERQUALQualidadeda Interface
DiscordoFortemente /ConcordoFortemente
Avalia ositens 16 até 18.
Tempo deduração deuma tarefa
Tempo Hora* Minutos Cronometro
Taxa deconclusãoda tarefa
Conclusão Conclusão 0 a 100 %
(Tarefas nãoconcluidas/tarefasconcluídas)100
Tabela 4 – Tabela de variáveis dependentes
5.2.5.4 Recursos
• Estação de trabalho para cada participante.
• Navegador de Internet.
• Questionário para a avaliação da usabilidade.
• Software de Vídeo (Camtasia - versão trial) ou outro.
5.2.5.5 Validade dos Resultados
72 Capítulo 5. Observações do Estudo
Ameaça Tipo Descrição da ameaça Tratamento
O esforço por pessoasque já conhecem o portalpoderá ser maior do que compessoas que nunca tevecontato com o portal.
Externa
Participantes que játenha conhecimento doportal terá uma maiorfacilidade de usopois já conhecema ferramenta.
Realizar também apesquisa com pessoasque nunca tiveramcontato com o portal.
Questionário não preen-chido
ConclusãoParticipantes nãopreencherem todos ositens dos questionários.
Avisar aos participantessobre a importânciade preencher todoo questionário.
Quantidade de participantesinsuficiente para obteruma melhor amostrados resultados
ExternaAmostra muito pequenapara análise dos dados.
Realizar outro testecom pessoas dediferentes lugares
Tabela 5 – Validade dos Resultados
5.2.6 Procedimentos para a execução
• Para a execução do experimento serão testados alguns cenários de teste na qual os
participantes devem executar um a um. Todos irão testar os mesmos cenários.
• O estudo se inicia com a leitura da descrição do estudo de caso e como será a agenda
de atividades. Serão explicados os cenários que cada um irá executar.
• Após o período de exploração do portal e finalizada o estudo de caso (cerca de 30
min), os participantes devem responder o questionário geral. Enquanto o partici-
pante realiza as atividades, um observador registra se o participante completou os
cenários sem assistência e produziu a saída completa do caso de uso.
• No final os participantes preenche um formulário de feedback.
5.2.7 Avaliação dos Resultados
A avaliação dos resultados do experimento deve considerar o uso de técnicas es-
tatísticas para analisar os dados e responder as questões referentes ao objetivo específico
estabelecido no planejamento deste estudo.
5.3 Estudo sobre Testes Automatizados - Rede Comunidade UnB
O processo de desenvolvimento de software, assim como o desenvolvimento de tes-
tes deste trabalho de conclusão de curso teve seu enfoque na rede colaborativa baseada
no noosfero desenvolvida para a Universidade de Brasília (UnB)14. Ao decorrer deste tra-14 www.unb.br
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 73
Técnica Descrição
Avaliação da FerramentaAplicação do questionário de usabilidadepara o portal participa.br
Registro de ocorrênciasDurante o experimento, um observador irá registrartodas as ocorrências referentes à avaliação das ferramentas.
Avaliação do ExperimentoAo final da avaliação das ferramentas os participantes irãopreencher um questionário geral, avaliando o andamentodo experimento
Relatório de análise dos dadosNo final do estudo será feito um relatório com a análisedos dados e lições aprendidas no que diz respeito àatuação da sua equipe durante a execução do experimento.
Tabela 6 – Avaliação dos resultados
balho de graduação, foram desenvolvidos, juntamente com seus respectivos testes, alguns
plugins que serão descritos nesta seção. Alguns testes automatizados são realizados no
noosfero para validação de novos recursos de software, dentre eles estão: testes funcio-
nais, testes de aceitação e testes unitários, testes estes que são executados na própria
plataforma do noosfero.
5.3.1 Testes de aceitação - Cucumber
Os testes de aceitação, que possuem uma visão mais voltada para o usuário, fazem
parte de uma fase do processo de teste em que um teste de caixa-preta é realizado num
sistema antes de sua disponibilização. Para isso utilizamos o cucumber, uma ferramenta
que pode executar documentação de funcionalidades escrita em texto puro. Com base
nesta especificações, o cucumber executa testes. O cucumber proporciona uma melhor co-
municação entre equipe de desenvolvimento e cliente, por utilizar uma linguagem em texto
puro. No cucumber, uma feature é um requisito de alto nível expressado da pespectiva de
uma pessoa e possui uma estrutura similar as histórias de usuário do XP Chelimskky et al.
(2010). Essa estrutura é proposta da seguinte forma:
1. Título: Palavra-chave ‘feature’ e um título curto que representa o objetivo da fea-
ture.
2. Narrativa: um texto curto que demonstre os cenários de execução, exatamente
como a narrativa de uma história de usuário:
Figura 10 – Descrição do título (feature) de um teste
74 Capítulo 5. Observações do Estudo
3. Pré condições: representado pela palavra-chave ’background’, define os passos pre-
cedem cada cenário de teste.
Figura 11 – Descrição de pré condições (background) de um teste
4. Cenários: representam parte concreta de como o software deve se comportar, e
sendo a parte essencial do teste realizado no cucumber. Após a palavra-chave ‘sce-
nario’ define-se o nome do cenário em questão:
5. Passos: Cada cenario possui uma série de passos que demontram o seu compor-
tamento, que são linhas simples iniciadas com as seguintes palavras-chaves: Given,
When, Then, And, But.
6. Given: Indica uma condição inicial para que o cenário seja executado, trata-se das
pré-condições do cenário.
7. When: Indica o evento do cenário
8. Then: Indica o que é esperado após o evento ocorrer.
Figura 12 – Descrição do cenário (scenario) de um teste
Além do cucumber, também é utilizado um software chamado selenium, que é uma fer-
ramenta usada para desenvolver casos de testes a partir de web browsers, como o mozilla
firefox. Estas duas ferramentas, cucumber e selenium, utilizadas em conjunto, proporciona
ao desenvolvedor a facilidade ao escrever os casos de testes em linguagem pura simular a
execução automática destes testes em um web browser. Porém o cucumber não faz tudo
em linguagem pura, é necessário que outro código seja desenvolvido, em Ruby, fazendo
par por baixo dos panos com a linguagem pura e executando os testes (AKITA, 2011).
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 75
5.3.2 Testes Funcionais e Unitários
Os testes funcionais tem como objetivo no desenvolvimento na plataforma noosfero,
verificara integraçao da aplicação desenvolvida. Os testes unitários são executados em
conjunto com os testes funcionais, porém com o objetivocde verificar trechos menores de
códigos. Assim os testes funcionais e unitários são escritos da seguinte forma:
Setup: indica as condições inciais dos testes, setando variáveis de ambiente e de
configuração por exemplo.
Figura 13 – Descrição do setup de um teste
Título: título do teste iniciado com a palavra ‘should’ e finalizado com ‘do’
Passos: código que define o comportamento do teste
Verificação: Assertiva que verifica se a ação foi realizada como esperada.
Figura 14 – Código de teste
5.3.3 Plugin Ldap UnB
Como rede colaborativa dos membros da Universidade de Brasília, o Comunidade
UnB necessita possuir restrição de acesso aos usuários, para que somente membros ativos
da universidade tenham acesso ao conteúdo da rede colaborativa. Para que esta necessi-
dade fosse satisfeita foi desenvolvido um plugin no noosfero, que efetuasse as restrições
necessárias, utilizando o protocolo de autenticação da UnB, o LDAP. Lightweight Direc-
tory Access Protocol (LDAP) é um protocolo de aplicação aberto para acesso e manu-
tenção de serviços de informação de diretório distribuídos na internet (SERMERSHEIM,
2006). Os serviços de diretório desempenham um papel importante no desenvolvimento
de aplicativos de intranet e internet, permitindo o compartilhamento de informações so-
bre os usuários, sistemas, redes, serviços e aplicações em toda a rede (ORACLE, 2000).
Um cliente inicia uma sessão de LDAP através da ligação a um servidor LDAP, chamado
76 Capítulo 5. Observações do Estudo
Directory System Agent (DSA), por padrão, a porta TCP e UDP porta 389. Após a cone-
xão,é requerida ao servidor uma operação do cliente, e o servidor responde a mesma. Para
o usuário, o plugin desenvolvido modifica a seção de cadastro de novos usuários e a seção
de login de usuários. Na seção de cadastro o usuário agora deve cadastrar a matrícula e
senha que o mesmo usa no matricula web da UnB15, além dos dados que já eram cadastra-
dos anteriormente. Na seção de login o usuário também pode entrar no Comunidade UnB
através de sua matrícula e senha do matrícula web da UnB (além do email e username -
entradas normalmente utilizadas) Nas camadas mais inferiores, o plugin é responsável por
modificar o modelo de dados do sistema, para que o usuário possa assim cadastrar sua
matrícula. Assim o plugin também é responsável por configurar a conexão com o LDAP
server da UnB e finalmente verificar se os dados do usuário estão corretos no momento
do seu cadastro. Abaixo encontra-se descritas as histórias de usuário referente ao plugin
Ldap UnB:
1. Plugin Ldap UnB - Cadastro:
Como aluno da UnB e novo usuário
Gostaria de cadastra-me no Comunidade UnB através da minha matrícula e senha
do sistemas da UnB
para utilizar o Comunidade UnB.
Cenário:
Dado que não estou autenticado
Quando eu entrar em “Novo Usuário”
E preencher os campos “nome de usuário”, “senha”, “confirmação de senha”, “nome
completo”, “e-mail” e “matrícula”
E clicar no botão “Registrar”
Então eu devo ser redirecionado ao perfil “nome de usuário”
2. Plugin Ldap UnB - Login:
Como aluno da UnB usuário do sistema
Gostaria acessar Comunidade UnB através da minha matrícula e senha do sistemas
da UnB
para facilitar a utilização do Comunidade UnB.
Cenário:
Dado que não estou autenticado
Quando eu preencher os campos “nome de usuário” e “senha”15 matriculaweb.unb.br
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 77
E clicar em “entrar”
Então eu devo ser redirecionado ao perfil “nome de usuário”
5.3.3.1 Testes com plugin LDAP
Foram realizados os seguintes testes com o plugin LDAP UnB: testes funcionais
e testes unitários. Os testes funcionais e unitários foram executados através do próprio
noosfero, já os testes de aceitação foram executados com auxílio das ferramentas cucumber
e selenium.
5.3.3.2 Testes Funcionais
Os testes funcionais do plugin LDAP foram divididos em duas categorias, sendo
estas compostas por testes que não dependem do LDAP está configurado e os testes
que dependem do LDAP configurado. Os testes independentes do LDAP são simples,
basicamente verificando as possíveis mensagem de errro ou de notificações durante o
login. Os testes que dependem do LDAP verificam os seguintes fatores:
1. Autenticação de usuário com LDAP;
2. Autenticação de usuário a partir da sua matrícula;
3. Exibição de mensagens de logs
4. Criação de usuário utilizando as propriedades do LDAP;
5. Não autenticação de usuário registadro localmente, mas não com LDAP;
6. Não autenticação de usuário não registrado localmente, mas com LDAP;
7. Criação e autenticação de um novo usuário a partir do plugin LDAP;
Também foram executados testes na interface de administrador do sistema, onde o usuário
tem a opção de ativar o plugin e informar dados de configuração do mesmo, estes testes
verificam os seguintes fatores:
1. Acesso à página de administrador;
2. Exibição de mensagens de sucesso e de erro;
3. Atualização do LDAP;
4. Atualização do host do LDAP;
5. Atualização da porta do LDAP;
78 Capítulo 5. Observações do Estudo
6. Atualização da conta do LDAP;
7. Atualização da senha do LDAP;
8. Atualização da base dn;
9. Atualização do atributo de login;
10. Atualização do atributo de email;
11. Atualização do filtro do LDAP;
12. Atualização de TLS;
5.3.3.3 Testes unitários
Os testes unitários do plugin verificam a definição dos parâmetros do LDAP, veri-
ficação esta que é realizada tanto na passagem dos parâmentros quanto na verificação dos
valores de default, outra verificação destes parâmetros que também é feita é a tentativa
de criação de uma autenticação no LDAP. Dentre estes parâmetros estão os seguintes:
• Host do LDAP;
• Porta do LDAP;
• Conta do LDAP;
• Senha da conta;
• Base DN do LDAP;
• atributo de login do LDAP;
• atributo de nome do LDAP;
• atributo de email do LDAP;
• filtros do LDAP;
• TLS do LDAP;
Não foram desenvolvidos testes de aceitação para o plugin LDAP UnB, pelo fato
de ser uma aplicação que opera a maior parte das suas funcionalidades nas camadas mais
baixas do sistema, alterando muito pouco a percepção do usuário.
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 79
5.3.4 Plugin para submissão de trabalho
Este plugin também foi desenvolvido para a plataforma Noosfero, porém em uma
aplicãção diferente, o Portal da FGA. A ideia deste plugin surgiu da necessidade de existir
um ambiente virtual em que os trabalhos de conclusão de curso pudessem ser submetidos
aos professores e compartilhados com a comunidade acadêmica, buscando assim manter
uma forma de versionamento dos trabalhos desenvolvidos. Este plugin é responsável por
criar uma atribuição de trabalhos, chamada de work assignment. Atribuição que possui
algumas funcionalidades específicas como possibilitar que os usuários envolvidos sejam no-
tificados via email sobre a submissão de um certo trabalho. Para tal foi necessário subir um
servidor de email para executar estas notificações, assim como criar uma página no Portal
FGA16 para que o usuário pudesse submeter seu trabalho. O processo de desenvolvimento
deste plugin ocorreu juntamente com uma transição da equipe de desenvolvimento, o que
prejudicou o desenvolvimento de testes do mesmo. Para validar o desenvolvimento desta
funcionalidade foram desenvolvidos os seguintes tipos de testes: funcionais, unitário e de
aceitação. Abaixo encontra-se descrita a história de usuário referente plugin submissão de
trabalho:
1. Plugin submissão de trabalho
Como usuário
Gostaria de submeter um trabalho para uma comunidade, seguindo um formulário
(título, nome do remetente, email do destinatário, nome do destinatário e descrição)
enviando um aviso para ambas as partes
para manter um versionamento do trabalho.
Cenário:
Dado que estou autenticado como “usuário”
Quando eu entrar no painel de controle da “Minha Comunidade”
E entrar em “Gerenciar Conteúdo”
E entrar em “Novo Conteúdo”
E entrar em “Trabalho a ser entregue”
E preencher o campo “Título”
E clicar em “Salvar”
Então eu devo ser redirecionado à pagina de “Gerenciar Conteúdos”
E visualizar o campo “Título”
Quando eu entrar em “Carregar Arquivo”
16 urlwww.fga.unb.br
80 Capítulo 5. Observações do Estudo
E marcar o campo “Enviar notificação”
E preencher o campo “Assunto”
E preencher o campo “Destinatário”
E clicar em “Enviar”
Então eu devo visualizar “Enviando com sucesso”
5.3.4.1 Testes Funcionais
Os testes funcionais do plugin para submissão de trabalho são responsáveis por
verificar os seguintes fatores:
• Permissão para enviar trabalhos somente para usuários autorizados;
• Capacidade de enviar um arquivo ou mais;
• Capacidade de atualizar um arquivo enviado;
• Validação de arquivos;
• Capacidade de enviar email aos usuários envolvidos;
• Tratamento do redirecionamento das páginas;
• Capacidade de deletar arquivos por usuários autorizados;
• Capacidade de carregar arquivos por usuários envolvidos;
5.3.4.2 Testes Unitários
Os testes unitários do plugin para submissão de trabalho são responsáveis por
verificar os seguintes parâmetros:
• Nome do plugin;
• Descrição do plugin;
• Possibilidade de submissão de um arquivo por um usuário;
• Nome do arquivo;
• Versão do arquivo;
• Autor do arquivo;
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 81
5.3.4.3 Testes de Aceitação
Os testes de aceitação do plugin para submissão de trabalho são responsáveis por
verificar os seguintes fatores:
• Capacidade de criar, editar e deletar uma atribuição de trabalhos (work assignment);
• Validação de parâmetros durante a criação e edição de uma atribuição de trabalhos;
• Capacidade de enviar e receber emails sobre o envio de um trabalho;
• Capacidade de postar comentários sobre uma atribuição de trabalhos;
• Capacidade de reportar problemas;
Abaixo estão descritos os testes desenvolvidos para o plugin:
Feature: send work plugin
As an user
I want to send work with notification email
Background:
Given “Work Assignment” plugin is enabled
Given the following users
| login | name |
| joaosilva | Joao da Silva |
| josesilva | Jose da Silva |
And the following community
| identifier | name |
| mycommunity | My Community |
And “Joao da Silva"is admin of “My Community"
And I am logged in as admin
And I go to /admin/plugins
And I check “Work Assignment"
And I press “Save changes"
Then I should see “Plugins updated successfully."
1. Scenario: Upload a file to work assignment and send a email
82 Capítulo 5. Observações do Estudo
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “test"
And I press “Save"
Then I should be on /mycommunity/test
When I follow “Upload files"
And I check “Send notification"
And I attach the file “public/images/rails.png"to “uploadedfiles"
And I press “Upload"
Then I should be on /myprofile/mycommunity/cms/sendemail
When I fill in “Title"with “Work"
And I fill in “Receiver"with “[email protected]"
And I fill in “Message"with “test"
And I press “Send"
Then I should see “Contact sent successfully"
2. Scenario: Create a work assignment and continue edition
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “test"
And I press “Save and continue"
Then I should be on /myprofile/mycommunity/cms/edit/13
5.3. Estudo sobre Testes Automatizados - Rede Comunidade UnB 83
3. Scenario: Can’t create work assignment without name
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “"
And I press “Save"
Then I should see “There were problems with the following fields:"
4. Scenario: Can’t create work assignment without file
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “test"
And I press “Save"
Then I should be on /mycommunity/test
When I follow “Upload files"
And I press “Upload"
Then I should be on /myprofile/mycommunity/cms/uploadfiles
5. Scenario: Cancel create work assignment
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
84 Capítulo 5. Observações do Estudo
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “test"
And I press “Save"
Then I should be on /mycommunity/test
When I follow “Upload files"
And I follow “Cancel"
Then I should be on /mycommunity/test
6. Scenario: Edit work assignment
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
When I fill in “Title"with “test"
And I press “Save"
Then I should be on /mycommunity/test
When I follow “Edit"
And I fill in “Title"with “test2"
And I press “Save"
Then I should be on /mycommunity/test2
7. Scenario: Delete a work assignment
Given I am logged in as “joaosilva"
When I follow “My Community"
When I go to mycommunity’s control panel
And I follow “Manage Content"
And I follow “New content"
And I follow “Work Assignment"
Then I should be on /myprofile/mycommunity/cms/new
5.4. Considerações finais 85
When I fill in “Title"with “test"
And I press “Save"
Then I should be on /mycommunity/test
When I follow “Edit"
And I follow “Delete"
And I confirm the browser dialog
Then I should see /“test"was removed./
5.4 Considerações finais
O desenvolvimento de testes automatizados é uma prática constante no desenvolvi-
mento da plataforma noosfero e importante na validação de novos recursos desenvolvidos.
Assim conseguimos verificar que a utilização de práticas de TDD e BDD como base para o
desenvolvimento trouxe resultados satisfatórios, como será mostrado no capítulo a seguir.
Com a proposta de algumas técnicas de avaliação da usabilidade para o Portal
da Participação Social, verificamos que muitas delas precisam ser adaptadas para uma
melhor adoção nos ambientes de software livre e em métodos ágeis. O teste de usabilidade
proposto foi planejado pensando nas práticas clássicas de avaliação da usabilidade que é
considerada por vários autores como uma das melhores maneiras de avaliar uma interface.
87
6 Considerações finais
Durante esta primeira parte do trabalho de conclusão de curso estudamos o de-
senvolvimento de software empírico e suas características, assim como a forma que este
desenvolvimento está ligado com testes automatizados e como as práticas de testes po-
dem ser aplicadas ou não em um ambiente real de desenvolvimento que já se encontra
estabelecido.
6.1 Resultados Prelimirares
Com o estudo sobre testes, usabilidade e o desenvolvimento dos plugins, chegamos
a alguns resultados iniciais que serão descritos nesta seção.
6.1.1 Plugins
O plugin que faz comunicação com o Ldap da UnB encontra-se em fase de homo-
lagação. Com o auxílio de uma ferramenta de análise de código para Ruby chamada Rcov,
foi obtida a taxa de cobertura de código do plugin desenvolvido, além de alguns dados
sobre a execução dos testes funcionais e unitários que seguem abaixo:
• Quantidade de testes executados: 96 testes;
• Quantidade de assertivas executadas: 111 assertivas;
• Quantiadde de falhas obtidas: 0 falhas;
• Tempo de execução dos testes: 7.8 segundos;
Na imagem abaixo existem dois gráficos de cobertura de código, o primeiro definido
como ’total coverage’ representa a contagem realizada com as linhas em branco e os
comentários do código, já o ’code coverage’ representa a contagem realizada sem as linhas
em branco e os comentários do código.
A ferramenta Rcov também foi utilizada para dimensionar a taxa de cobertura de
código do plugin para submissão de trabalho, segue os dados sobre a execução dos testes
funcionais e unitários:
• Quantidade de testes executados: 28 testes;
• Quantidade de assertivas executadas: 84 assertivas;
88 Capítulo 6. Considerações finais
Figura 15 – Cobertura de código do plugin LdapUnb
• Quantiadde de falhas obtidas: 0 falhas;
• Tempo de execução dos testes: 10,5 segundos;
Na imagem abaixo está representado a cobertura de código, extraída da ferramenta
Rcov:
Figura 16 – Cobertura de código do plugin para submissão de trabalho
Para este plugin também foram desenvolvidos testes automáticos de aceitação,
afim de validar a experiência do usuário em diferentes cenários possiveis:
• Quantidade de cenários executados: 6 cenários;
• Quantidade de passos executadas: 130 passos;
• Quantiadde de falhas obtidas: 0 falhas;
• Tempo de execução dos testes: 7 minutos e 18 segundos;
A partir da cobertura dos testes do plugin de submissão de trabalho, foi verifi-
cado que existe uma necessidade de refatoração desta funcionalidade, considerando al-
guns aspectos que dificultaram o desenvolvimento de testes desta funcionalidade, como a
duplicação de código.
6.1. Resultados Prelimirares 89
Porém estes resultados preliminares foram considerados satisfatórios, considerando
que outros plugins desenvolvidos pela comunidade do Noosfero e já homolagados apresen-
tam métricas semelhantes.
• Plugin Stoa: Plugin que inclui funcionalidades ao Stoa, rede colaborativa da USP
(Universidade de São Paulo)
Figura 17 – Cobertura de código do plugin Stoa
• Plugin Ldap: Plugin que permite autenticação via Ldap;
Figura 18 – Cobertura de código do plugin Ldap
• plugin Statistics: Plugin que permite adicionar um bloco de estatísticas ao perfil do
usuário
Figura 19 – Cobertura de código do plugin Statistics
90 Capítulo 6. Considerações finais
6.1.2 Usabilidade no desenvolvimento de software empírico
Com as pesquisas realizadas podemos notar que existe estudos na área onde foram
criadas metodologias que unem tanto as abordagem ágeis com a abordagem centrada no
usuário.
De acordo com os autores pesquisados é possível fazer a integração das abordagens,
mas é necessário que tenha algumas adaptações.
Os testes de usabilidade clássico, no qual observa-se uma pessoa enquanto utiliza
o software, naturalmente é uma das melhores maneiras de avaliar a usabilidade. Mas,
especialmente em ambientes de software livre muitos outros métodos são mais viáveis
(BORCHARDT, 2010). Cada técnica e método servem como padrões e sua utilidade
depende da estrutura do projeto que a pessoa responsável pelo teste se encontra.
Segundo Siegel (2010) para ser defensor de UX você não precisa criar mockups
perfeitos no Inkscape 1 e nem ter um bom conhecimento de HCI. Para ele tudo que você
precisa é de amor por um projeto open source e as pessoas que a usam, sendo paciente,
persistente e persuasivo.É útil ter alguém com conhecimento em experiência do usuário
mas muitas vezes é desnecessário. É melhor para um projeto open source ter um defensor
UX novato do que nenhum.
Os defensores em usabilidade não precisam ser desenvolvedores e nem sequer pre-
cisa ser um especialista em usabilidade. É preciso tempo, energia e diposição para obter
uma boa experiência do usuário. O defensor de UX pode filtrar e priorizar erros UX,
pesquisar problemas de design e realizar testes com os usuário (DAY, 2010).
Muitos desenvolvedores de software livre já sabem da importância da usabilidade,
mas não sabem como melhorá-la. Andreasen et al. (2006) diz que um grande problema
de se trabalhar com eles é a falta de confiança e por isso é preciso comunicar abertamente
suas descobertas e métodos.
Gravação de testes de usabilidade ou entrevistas para ter citações de usuários
para apresentação é uma prática comum em agências de usabilidade no qual é necessário
assinar um formulário de concessão de uso da imagem. Para Borchardt (2010) em projetos
de software livre independentes, as gravações de participantes são bastante inúteis, pois
criam muito trabalho apenas para apresentação, além de que rever as gravações levaria o
dobro de tempo.
No desenvolvimento de software livre uma das vantagens na apresentação dos re-
sultados de forma rápida e sem a necessidade de elaborar um relatório um uma apresenta-
ção. A comunicação pode ser feita diretamente com os desenvolvedores sobre os problemas
encontrados e fazer iterações rápidas com base em sugestões (BORCHARDT, 2010).
1 Inkscape - Aplicativo de edição de imagens
6.2. Próximos Passos 91
6.1.3 Portal da Participação Social
A ideia do estudo de caso proposto era conhecer como funciona algumas técnicas
de avaliação da usabilidade. Foi escolhido o Portal da Participação Social por ser um dos
projetos apoiados pela faculdade.
Primeiramente precisou conhecer quem são os usuários do portal e quais são seus
interesses. Para isso foi proposto algumas técnicas para análise do perfil do usuário: como
aplicação de questionário de perfil de uso, análise de dados estatísticos e criação de persona
do usuário.
A Persona foi criada analisando alguns usuários cadastrados no portal e através
de informações tanto no perfil do portal, como de informações em redes sociais e sites
pessoais conseguimos captar algumas informações de um determinado público do site.
Com a persona identificada é possível criar alguns cenários de uso do sistema, na
qual as tarefas levantadas farão parte do teste de usabilidade.
Antes de realizar o teste de usabilidade com o usuário é importante que sejam
verificadas as tarefas que serão executadas pelos participantes.Essas tarefas podem ser
encontradas através da avaliação por heurísticas de usabilidade onde podemos descobrir
antecipadamente os principais problemas na interface do sistema.
Para analisar o grau de satisfação do usuário foi feito uma pesquisa com os princi-
pais questionários existentes e escolhemos o PSSUQ por acharmos que era o questionário
que possuia maior grau de confiabilidade e que retornava quatra fatores (Satisfação Geral,
Qualidade da Interface, qualidade da informação e utilidade do sistema).
Também foi escolhido o questionário ASQ que é aplicado depois de cada tarefa
executada. Além disso ao aplicar o teste de usabilidade é preciso observar atentamente os
passos que os usuário está realizando para concluir cada tarefa.
6.2 Próximos Passos
A partir da pesquisa realizada e do processo iniciado neste trabalho, chegamos nas
seguintes hipóteses, que serão respondidas próximo trabalho:
• É possível inserir os princípios de usabilidade dentro do processo ágil de desenvol-
vimento de software.
• É possível alcançar melhores resultados em testes de usabilidade utilizando práticas
do BDD e TDD, durante o desenvolvimento de software.
Nesta seção está descrita suscitamente a proposta dos próximos passos deste tra-
balho de conclusão de curso. Basicamente, buscamos aplicar as técnicas de usabilidade
92 Capítulo 6. Considerações finais
pesquisadas durante o trabalho, em um processo baseado em BDD e TDD, a fim de ve-
rificar problemas de usabilidade, e satisfação e uso em um estudo de caso específico, no
caso plataforma Noosfero.
Outro passo a ser realizado é verificar os padrões de design e usabilidade adotados
pelo Noosfero, propor e implementar possíveis melhorias.
6.2.1 Portal do Software Público
Criado em 12 de abril de 2007, o portal do SPB já conta com mais de 60 solu-
ções voltadas para diversos setores. Para a SLTI (Secretaria de Logística e Tecnologia da
Informação), o portal já se consolidou como um ambiente de compartilhamento de softwa-
res. Isso resulta em uma gestão de recursos e gastos de informática mais racionalizada,
ampliação de parcerias e reforço da política de software livre no setor público 2.
As tecnologias de informação e comunicação estão se consolidando como meios de
expressão do conhecimento, de expressão cultural e de transações econômicas. Na soci-
edade em rede, baseada em comunicação feita através de computadores, não é possível
aceitar que as linguagens usadas nessa comunicação fiquem sob o poder de apenas al-
guns gigantes. No desenvolvimento de software que apresenta código aberto, como o SPB,
as inovações são compartilhadas entre todos, permitindo que as melhorias sejam adota-
das por qualquer um, assim o conhecimento passa a ser sempre disseminado, ajudando
principalmente as pequenas e médias empresas 3.
A evolução do software público ja passou por três etapas de desenvolvimento e está
na sua quarta etapa, contando com seus usuários para desenvolver novas funcionalidades
e melhorias, a partir de sugestões dadas pelos mesmos.
o portal foi desenvolvido baseado na plataforma Noosfero, e a partir disso planeja-
mos aplicar no Portal os estudos que foram desenvolvidos neste trabalho, a avaliação de
usabilidade a partir do desenvolvimento baseado em testes automatizados, a fim de res-
ponder se o processo de desenvolvimento utilizando práticas do BDD e TDD apresentam
melhores resultados em testes de usabilidade.
6.2.2 Cronograma
Esta seção descreve o planejamento inicial dos próximos passos a serem realizados
no trabalho de conclusão de curso 2. Abaixo estão descritas as atividades planejadas:
1. Estudar o plugin: Será realizado um estudo sobre o plugin assets do portal do
software público, que já encontra-se em desenvolvimento.
2 www.softwarepublico.gov.br3 www.softwarepublico.gov.br
6.2. Próximos Passos 93
2. Levantar testes: Levantamento de possíveis testes a serem incorporados ao plugin.
3. Aplicar estudo de usabilidade: Aplicação do estudo de usabilidade realizado
neste trabalho.
4. Levantar problemas: Levantamento de problemas do plugin, a partir do estudo
aplicado.
5. Propor melhorias: Propor melhorias a partir dos testes de aceitação, a fim de
verificar hipóteses levantadas.
6. Executar melhorias: Realizar execução das melhorias propostas para o plugin.
7. Verificar melhorias: Verificar se as melhorias na usabilidade a partir dos testes
de aceitação.
8. Relatar resultados: Descrever os resultados obtidos.
9. Iniciar novo plugin:
10. Inserir práticas: Inserir as práticas estudadas no início do desenvolvimento de um
novo plugin.
11. Avaliar práticas bem sucedidas: Avaliar o desenvolvimento e definir quais prá-
ticas obtiveram resultados positivos.
Fase Atividade PrazoPlanejamento Estudar o plugin (mes)
Levantar testes (mes)Execução Aplicar estudo de usabilidade (mes)Relatos Levantar problemas (mes)Planejamento Propor melhorias (mes)Execução Executar melhorias (mes)Relatos Relatar resultados (mes)Planejamento Iniciar novo plugin (mes)Execução Inserir práticas (mes)Relatos Avaliar práticas bem sucedidas (mes)
95
A Apêndice
A.1 Questionário de Perfil do Usuário
Este questionário foi utilizado para identificar o perfil do usuário e algumas de
suas necessidades.
Figura 20 – Questionário de perfil do usuário
96 Apêndice A. Apêndice
A primeira parte do questionário mostra perguntas gerais referentes ao perfil social
dos usuários como idade, ocupação/profissão, gênero, formação adadêmica e áreas de
interesse.
Figura 21 – Questionário de perfil do usuário - Continuação
A.1. Questionário de Perfil do Usuário 97
Na seção dois do questionário, as informações sobre o uso dos meios de comunicação
que cada usuário. Informações sobre locais de acesso à internet, velocidade de conexão,
principais redes sociais e as principais atividades que realiza na internet.
Figura 22 – Informações sobre o uso dos meios de comunicação
98 Apêndice A. Apêndice
Na terceira seção do questionário são feitas perguntas referentes ao engajamento
político/social dos usuários como atuações em movimentos políticos e sociais e partici-
pações em manifestações, além de saber sobre o meio de informação na qual se informa
sobre os movimentos.
Figura 23 – Participações sociais
A.1. Questionário de Perfil do Usuário 99
Depois que foram preenchidas a primeira parte do questionário, os usuários que já
usavam o portal da participação social iriam preencher algumas outras questões referente
a utilização do portal, tentando entender as principais atividades e funcionalidades que
cada usuário utilizava.
Figura 24 – Portal da Participação Social
100 Apêndice A. Apêndice
Na seção cinco do questionário, as questões servem para conhecer o tempo e o
local de acesso dos usuários do portal da participação social
Figura 25 – Ambiente e tempo de acesso no portal
A.2 Questionário de Satisfação
Levantamos informações sobre alguns questionários de satisfação de uso existentes
na literatura e foi feito uma comparação entre cada um deles.
A.2.1 QUIS - Questionnaire for User Interaction Satisfaction
O QUIS mede a satisfação do usuário quanto â usabilidade do produto de maneira
padronizada, segura e válida, a fim de obter informações precisas em relação à reação dos
usuários a novos produtos (QUIS, 2009);
A versão atual é a QUIS 7.0 (Norman e Shneiderman, 2010), contém um questi-
onário onde possui a avaliação da satisfação geral e avaliações de fatores específicos de
interfaces organizadas hierarquicamente: tela, terminologia e retroalimentação do sistema,
aprendizado, capacidades do sistema, manuais técnicos, tutoriais online, multimídia, te-
leconferência e instalação de software. Pode ser configurado de acordo com a necessidade
e interesse do usuário.
É um questionário proprietário, é sugerido o uso de planilhas eletrônicas e softwares
estatísticos até que se implementem recursos de análise no servidor web dos proprietários.
A.2. Questionário de Satisfação 101
A.2.2 SUS – System Usability Scale
O SUS é uma escala de usabilidade do tipo Likert que possui uma visão global
e subjetiva em suas avaliações de usabilidade. Ele apresenta ao entrevistado uma lista
de perguntas que devem ser respondidas em uma escala de satisfação (indica o grau de
concordância ou discordância do usuário) (BROOKE, 1996).
O autor se baseou na afirmação de que no contexto industrial, as avaliações com-
pletas não são práticas e requerem muito esforço e custo. O SUS foi criado pela necessidade
de se ter uma avaliação de usabilidade simples e rápida. Os métodos de avaliação foram
simplificados e o número de questões reduzidas, pois uma quantidade grande de questões
desanima os usuários que possivelmente não preencheria todas as questões, resultando
assim problemas na captura de reações subjetivas do usuário. Foi então proposto um
questionário com 10 questões que utiliza a escala Likert de cinco ou sete pontos. Este
questionário abrange vários aspectos da usabilidade, tais como: necessidade de suporte,
treinamento e complexidade. (PREECE; ROGERS; SHARP, 2007)
A.2.3 SUMI – Usability Measurement Inventory
O SUMI proposto por Kirakowski e Corbett (1988) é um questionário para medi-
ção da qualidade de um software do ponto de vista do usuário, é um método consistente
usado para avaliar a qualidade de uso de um produto de software ou protótipo, e pode
ajudar na descoberta de falhas de usabilidade. É mencionado na norma ISO 9241 como
um método reconhecido para testar a satisfação do usuário. O SUMI é um questionário
comercial.
Inicialmente continha 150 itens onde o participante escolhia se (concordo forte-
mente, concordo, não sei, discordo ou discordo totalmente). Atualmente são 50 itens divi-
didos em 5 grupos de 10 itens. Os grupos de itens são: eficiência, afeto, eficácia, controle e
aprendizado. Os entrevistados preenchem o questionário no seu local de trabalho e devem
decidir entre as opções: concordo, não sei ou discordo totalmente.
A.2.4 ASQ – The After-Scenario Questionnaire
O ASQ é um questionário de três itens que são utilizados para avaliar a satisfação
do usuário após a conclusão de cada cenário/tarefa. São realizadas umas séries de tarefas
que estão de acordo com a realidade do usuário.Este questionário aborda questões como:
facilidade de conclusão da tarefa, tempo para completar uma tarefa e adequação das
informações de suporte.São questões do tipo Likert, aplicando uma escala de 1 a 7, onde
1 representa “Concordo totalmente” e 7 para “Discordo totalmente”. (LEWIS, 1995)
O participante gasta em média 1 hora pra realizar cada cenário, no fim de cada
cenário é preenchido o questionário ASQ. Após completar todos os cenários, no fim de 1 dia
102 Apêndice A. Apêndice
de trabalho (8 horas), os participantes preenchem o questionário PSSUQ para avaliação
geral do sistema.O ASQ foi aplicado na IBM por diferentes tipos de usuários, cada grupo
possuía um tempo de experiência com sistemas de computador, o que permitiu a análise
psicométrica do questionário.
Figura 26 – ASQ - The After-Scenario Questionnaire
A.2.5 PSQ – The Printer-Scenario Questionnaire
O PSQ é uma versão inicial do ASQ, mas difere no formato e numero de itens. São
escalas de 5 pontos com os termos “Aceitável” com nota 1 e “Precisa de muita Melhoria”
com nota 5, e não marcado “Para Avaliar” (LEWIS, 1995).
A.2.6 PSSUQ – The Post-Study System Questionnaire
O PSSUQ fornece uma avaliação global do sistema utilizado. Esse questionário
possui 19 itens para avaliação da satisfação do usuário com a usabilidade do sistema. É
gasto em média 10 minutos para completar o questionário, mas só é preciso completar
uma vez o questionário no fim do estudo de usabilidade. (LEWIS, 1995)
A.2. Questionário de Satisfação 103
Este questionário ajuda a entender quais aspectos do sistema o usuário está mais
preocupado. Ele avalia as características como facilidade de uso e de aprendizado, simpli-
cidade, eficácia, informação e a interface com o usuário.
Existem 4 tipos de pontuações para as respostas aos itens do PSSUQ: Escore da
satisfação geral (OVERALL), a utilidade do sistema(SYSUSE), a qualidade da informação
(INFOQUAL) e a qualidade da interface (INTERQUAL).
A escala Global está relacionada com a soma das classificações ASQ que os parti-
cipantes deram após completar cada cenário.
Figura 27 – PSSUQ – The Post-Study System Questionnaire
104 Apêndice A. Apêndice
Figura 28 – PSSUQ: The Post-Study System Questionnaire - Questões de 8 à 19
A.2.7 CSUQ - Computer System Usability Questionnaire
Este questionário é parecido com o PSSUQ, mas a sua redação e diferente. En-
quanto no PSSUQ afirma que “Eu poderia efetivamente realizar as tarefas e cenários
usando este sistema” o CSUQ escreve: “Eu posso terminar meu trabalho de forma eficaz
usando esse sistema?”. Na IBM, este questionário foi aplicado através de e-mail, enviado
para funcionários de diferentes locais, o que houve uma maior quantidade de participantes,
do que feito com grupos reduzidos presencialmente. (LEWIS, 1995) O CSUQ é utilizado
A.2. Questionário de Satisfação 105
quando o estudo de usabilidade é em um ambiente fora do laboratório. A confiabilidade
relatada foi de 0,93.
A.2.8 Comparativo dos questionários
Os questionários ASQ e PSQ são utilizados após a realização de um cenário. Con-
tém os mesmos itens, mas possuem escalas diferentes. O ASQ possui uma maior confia-
bilidade em relação ao PSQ.
PSSUQ e CSUQ são ambos os questionários de satisfação global. O PSSUQ uti-
liza itens adequados para uma situação de teste de usabilidade, já o CSUQ são apro-
priados para uma situação de teste de campo. Os questionários possuem propriedades
psicométricas aceitáveis de usabilidade e podem ser usados com confiança como medidas
padronizadas de satisfação. É interessante utilizar o PSSUQ junto com o ASQ.
O ideal é que o questionário seja mais genérico possível. Cada questionário possui
um nível de confiança.
Nome Criador Questões Licença Interface AvaliadaConfiab. Escala
ASQ IBM 3 Aberto Qualquer 0,93
DiscordoFortemente /ConcordoFortemente
CSUQ IBM 19 AbertoBaseado emcomputador
0,95
DiscordoFortemente /ConcordoFortemente
PSSUQ IBM 19 AbertoBaseado emcomputador
0,96
DiscordoFortemente /ConcordoFortemente
SUMI HERG 27 Proprietário Software 0,89
DiscordoFortemente /ConcordoFortemente
SUS DEC 10 Aberto Qualquer 0,85
DiscordoFortemente /ConcordoFortemente
QUIS UMD 50 Proprietário - - 0 a 9
Tabela 7 – Comparativo dos questionários
106 Apêndice A. Apêndice
A.3 Cenários
Os cenários foram levantados através de uma análise do que era permitido de
realizar no portal e quais seriam mais importantes para as principais atividades de um
usuário.
Através das redes sociais e do perfil do usuário no portal da participação social foi
identificado que uma das atividades mais realizadas pelos usuários são de edição de textos
no blog do perfil, além da criação de mecanismos de participação social como a votação
em pares (parwise).
Entender o perfil do usuário é um dos principais pontos que devem ser levados em
consideração pelos desenvolvedores de software em geral. Cada perfil de usuário tem suas
particularidades e suas expectativas quanto a utilização do sistema.
107
Referências
ACOSTA, A. E. Agilus: Construcción ágil de la usabilidad. Citado na página 54.
AGNER, L. Arquitetura da informação: Testes de sabilidade. Citado na página 35.
AKITA, F. A controvérsia test::unit vs rspec/cucumber. 2011. Citado na página 72.
ANDREASEN, M. S. et al. Usability in open source software development: Opinionsand practice. 2006. Disponível em: <http://itc.ktu.lt/itc353/Stage353.pdf>. Citado napágina 88.
AVRITZE, A.; WEYUKER, E. J. Generating test suites for software load testing ininternational symposium on software testing and analysis (issta). 1994. Disponível em:<http://dl.acm.org/citation.cfm?id=186258.186507>. Citado na página 28.
BARBOSA, D. F.; FURTADO, E. S.; GOMES, A. S. Uma estratégia de apoioà institucionalização da usabilidade em ambientes de desenvolvimento ágil. In:SOCIEDADE BRASILEIRA DE COMPUTAçãO. Proceedings of the VIII BrazilianSymposium on Human Factors in Computing Systems. [S.l.], 2008. p. 214–223. Citado 2vezes nas páginas 52 e 53.
BARBOSA, S. D. J.; SILVA, B. S. Interação Humano-computador. [S.l.: s.n.], 2010.Citado na página 52.
BECK, K. Test-Driven Development by Example. [S.l.]: Addison-Wesley Prefessional,2002. Citado 3 vezes nas páginas 9, 29 e 30.
BERNARDO, P. C. Padrões de testes automatizados. Dissertação (Mestrado) —Instituto de Matemática e Estatística – Universidade de São Paulo, 2011. Disponível em:<http://www.teses.usp.br/teses/disponiveis/45/45134/tde-02042012-120707/>. Citado2 vezes nas páginas 19 e 30.
BERVIAN, P. A.; CERVO, A. L.; SILVA, R. d. Metodologia científica. São Paulo, 2002.Citado na página 39.
BORCHARDT, J.-C. Usability in free software - freedom 4: The freedom touse the program effectively, efficiently and satisfactorily. 2010. Disponível em:<http://jancborchardt.net/usability-in-free-software>. Citado na página 88.
BROOKE, J. Sus-a quick and dirty usability scale. Usability evaluation in industry,London: Taylor and Francis, v. 189, p. 194, 1996. Citado na página 99.
CHAUí, M. Convite a filosofia. [S.l.: s.n.], 2003. Citado na página 23.
CHELIMSKKY, D. et al. The RSpeec Book: Behaviour-Driven Development with RSpec,Cucumber, and Friends. [S.l.: s.n.], 2010. Citado 3 vezes nas páginas 30, 31 e 71.
COHEN, D.; LINDVALL, M.; COSTA, P. An introduction to agile methods. In Advancesin Computers. [S.l.: s.n.], 2004. Citado na página 25.
108 Referências
CONSTANTINE, L. L.; LOCKWOOD, L. Process agility and software usability: Towardlightweight usage-centered design. Information Age, v. 8, n. 8, p. 1–10, 2002. Citado napágina 53.
CYBIS, W.; BETIOL, H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos, Métodose Aplicações. [S.l.: s.n.], 2010. Citado 12 vezes nas páginas 35, 36, 37, 39, 41, 42, 43, 44,45, 49, 52 e 55.
DAY, A. User experience advocates. 2010. Disponível em:<http://afaikblog.wordpress.com/2010/07/08/user-experience-advocates>. Ci-tado na página 88.
DIAS, C. Usabilidade na Web: Criando websites mais acessíveis. [S.l.: s.n.], 2006. Citadona página 33.
DICKINSON, J.; KUNAMA, D. How user-centered design can put user stories in propercontex. New Riders Press, Pearson Education, 2010. Citado na página 55.
EASON, K. D. User-centred design: for users or by users? 2005. Citado na página 51.
EVERETT, G. D. et al. Software Testing. [S.l.: s.n.], 2007. Citado na página 27.
FERREIRA, J.; NOBLE, J.; BIDDLE, R. Interaction designers on extreme programmingteams: Two case studies from the real world. In: Proceedings of the Fifth New ZealnadComputer Science Research Student Conference. [S.l.: s.n.], 2007. Citado na página 55.
GARRET, J. The Elements of user experience. [S.l.: s.n.], 2003. Citado na página 35.
GIL, A. C. Métodos e técnicas de pesquisa social. 3. ed. São Paulo:r. [S.l.: s.n.], 1991.Citado na página 21.
GOULD, J. D.; LEWIS, C. Designing for usability: key principles and what designersthink. Communications of the ACM, ACM, v. 28, n. 3, p. 300–311, 1985. Citado napágina 51.
GUIMARAES, C. P.; CHAVES, C. v. F. G. Xplus: Integrando o design de interfacescentrado na experiência do usuário ao processo de desenvolvimento de software comextreme programming. Citado na página 55.
HARING, R. Behavior driven development: Beter dan test driven development. JavaMagazine, 2011. Citado na página 30.
HIX, D.; HARTSON, H. R. Developing User Interfaces: Ensuring Usability ThroughProduct &Amp; Process. New York, NY, USA: John Wiley & Sons, Inc., 1993. ISBN0-471-57813-4. Citado na página 49.
HODGETTS, P. Experiences integrating sophisticated user experience design practicesinto agile processes. In: IEEE. Agile Conference, 2005. Proceedings. [S.l.], 2005. p.235–242. Citado na página 53.
ISO/IEC 9126-1. NBR ISO/IEC 9126-1: Engenharia de software - Qualidade de produto,Parte 1: Modelo de qualidade. [S.l.], 2003. Citado na página 33.
Referências 109
ISO/IEC 9241-11. NBR ISO/IEC 9241-11: ERequisitos ergonômicos para o trabalhocom dispositivos de interação visual Parte 11: Orientações sobre usabilidade. [S.l.], 2003.Citado na página 33.
KIRAKOWSKI, J.; CORBETT, M. Measuring user satisfaction. In: CAMBRIDGEUNIVERSITY PRESS. Proceedings of the Fourth Conference of the British ComputerSociety on People and computers IV. [S.l.], 1988. p. 329–338. Citado na página 99.
KOSKELA, L. Test Driven: Pratical TDD and Acceptance TDD for Java Developers.[S.l.]: Manning Publications, 2007. Citado na página 29.
KRUG, S. Simplificando coisas que parecem complicadas. [S.l.: s.n.], 2010. Citado 2vezes nas páginas 46 e 47.
LEE, J. C.; JUDGE, T. K.; MCCRICKARD, D. S. Evaluating extreme scenario-baseddesign in a distributed agile team. In: CHI ’11 Extended Abstracts on Human Factors inComputing Systems. New York, NY, USA: ACM, 2011. (CHI EA ’11), p. 863–877. ISBN978-1-4503-0268-5. Disponível em: <http://doi.acm.org/10.1145/1979742.1979681>.Citado na página 53.
LEITE, S. F. C. Inspeção de usabilidade aplicada a métodos ágeis: Um estudo de caso.2013. Citado na página 54.
LEWIS, J. R. Ibm computer usability satisfaction questionnaires: psychometricevaluation and instructions for use. International Journal of Human-ComputerInteraction, Taylor and Francis, v. 7, n. 1, p. 57–78, 1995. Citado 3 vezes nas páginas99, 100 e 102.
LIU, H. H. Software Performance and Scalability: A Quantitative Approach (QuantitativeSoftware Engineering Series). [S.l.: s.n.], 2009. Citado na página 28.
LOWDERMILK, t. Design Centrado no Usuário: Um guia para o desenvolvimento deaplicativos amigáveis. [S.l.: s.n.], 2013. Citado 2 vezes nas páginas 37 e 51.
MARTIN, R. C. The test bus imperative: Architectures thatsupport automated acceptance testing. 2005. Disponível em:<http://www.martinfowler.com/ieeeSoftware/testBus.pdf>. Citado na página28.
MASSOL, V.; HUSTED, T. JUnit in Action. [S.l.]: Manning Publications, 2003. Citadona página 29.
MAYHEW, D. The usability engineering lifecycle: a practitioner’s handbbok for userinterface design. [S.l.: s.n.], 1999. Citado na página 49.
MCINERNEY, P.; MAURER, F. Ucd in agile projects: dream team or odd couple?Interactions, ACM, v. 12, n. 6, p. 19–23, 2005. Citado na página 55.
MEIRELLES, P. R. M. Monitoramento de métricas de código-fonte em projetos desoftware livre. Tese (Doutorado) — Instituto de Matemática e Estátistica – Universidadede São Paulo (IME/USP), 2013. Citado na página 59.
110 Referências
MEMMEL, T.; GUNDELSWEILER, F.; REITERER, H. Agile human-centered softwareengineering. In: Proceedings of the 21st British HCI Group Annual Conference on Peopleand Computers: HCI...But Not As We Know It - Volume 1. Swinton, UK, UK: BritishComputer Society, 2007. (BCS-HCI ’07), p. 167–175. ISBN 978-1-902505-94-7. Disponívelem: <http://dl.acm.org/citation.cfm?id=1531294.1531317>. Citado na página 53.
MESZAROS, G.; WESLEY, A. XUnit Test Patterns: Refactoring Test Code. [S.l.: s.n.],2007. Citado na página 27.
MOARES, A. M. Design e Avaliação de Interface. [S.l.: s.n.], 2002. Citado na página 35.
MOGGRIDGE, B. Design Interactions. [S.l.: s.n.], 2006. Citado na página 36.
MOLINARI, L. Teste de Software. Produzindo Sistemas Melhores e Mais Confiáveis.[S.l.: s.n.], 2003. Citado na página 27.
MUGRIDGE, R.; DCUNNINGHAM, W. Fit for Developing Software: Framework forIntegrated Tests. [S.l.: s.n.], 2005. Citado na página 28.
NAJAFI, M.; TOYOSHIBA, L. Two case studies of user experience design and agiledevelopment. In: Agile, 2008. AGILE ’08. Conference. [S.l.: s.n.], 2008. p. 531–536.Citado na página 54.
NERUR, S.; MAHAPATRA, R.; MANGALARAJ, G. Challenges of migrating to agilemethodologies. [S.l.: s.n.], 2005. Citado na página 24.
NIELSEN, J. Usability engineering. [S.l.: s.n.], 1994. Citado 5 vezes nas páginas 9, 33,44, 45 e 47.
NIELSEN, J.; LORANGER, H. Usabilidade na web: Projetando websites com qualidade.[S.l.: s.n.], 2007. Citado na página 33.
NIELSEN, L.; MADSEN, S. The usability expert’s fear of agility: An empirical studyof global trends and emerging practices. In: Proceedings of the 7th Nordic Conferenceon Human-Computer Interaction: Making Sense Through Design. New York, NY, USA:ACM, 2012. (NordiCHI ’12), p. 261–264. ISBN 978-1-4503-1482-4. Disponível em:<http://doi.acm.org/10.1145/2399016.2399057>. Citado na página 53.
NORMAN, D. O design do dia-a-dia. Rocco, 2006. ISBN 9788532520838. Disponível em:<http://books.google.com.br/books?id=8zd8PgAACAAJ>. Citado na página 36.
ORACLE. Oracle8i integration server overview. 2000. Disponível em:<http://docs.oracle.com/cd/A87860 01/doc/ois.817/a83729/adois09.htm>. Ci-tado na página 73.
POTEL, M.; COTTER, S. Inside Taligent Technology. [S.l.]: Taligent Press, 1995.Citado na página 27.
PREECE, J.; ROGERS, Y.; SHARP, H. Design de Interação: Além do homemcomputador. [S.l.: s.n.], 2007. Citado 11 vezes nas páginas 19, 33, 34, 35, 36, 39, 46, 48,49, 58 e 99.
ROSA, S. J. G.; MORAES, A. Avaliação e projeto no design de interface. [S.l.: s.n.],2012. Citado na página 38.
Referências 111
ROSENFELD, L.; MORVILLE, P. Information architecture of the world wide web. [S.l.:s.n.], 1998. Citado na página 35.
SAFFER, D. Designing for Interaction: Creating Innovative Applications and Devices.New Riders, 2010. (Voices that matter). ISBN 9780321643391. Disponível em:<http://books.google.com.br/books?id=k28yVW3SEyYC>. Citado na página 36.
SANTOS, A. P. Aplicação de práticas de usabilidade ágil em software livre. 2012. Citado8 vezes nas páginas 20, 44, 46, 47, 51, 52, 54 e 55.
SATO, D. T. Uso eficaz de métricas em métodos Ágeis de desenvolvimento de software.2007. Citado na página 25.
SCHWABER, K. Agile Project Management with Scrum. [S.l.]: Microssoft Press, 2004.Citado na página 23.
SERMERSHEIM, J. Lightweight directory access protocol (ldap): The protocol. TheInternet Society, 2006. Disponível em: <https://tools.ietf.org/rfc/rfc4511.txt>. Citadona página 73.
SIEGEL, D. Announcing the user experience advocates project. 2010. Citado na página88.
SPENDOLINI, M. J. Benchmarking. [S.l.: s.n.], 1994. Citado na página 43.
STALLMAN, R. M. Free Software: Freedom and Cooperation. 2001. Disponível em:<http://www.gnu.org/events/rms-nyu-2001-transcript.txt>. Citado na página 23.
SY, D. Adapting usability investigations for agile user-centered design. Journal ofusability Studies, New Riders Press, Pearson Education, v. 2, n. 3, p. 112–132, 2007.Citado na página 54.
UNGER, R.; CHANDLER, C. O Guia para projetar a experiência do usuário (UX) paraprojetistas de contéudo digital, aplicações e web sites. [S.l.: s.n.], 2009. Citado 2 vezesnas páginas 46 e 47.
VASCONCELOS, C.; GARCIA, F.; TURNELL, M. Integrando usabilidade e engenhariade software: um modelo para o desenvolvimento de sistemas centrado no usuário.WIHC-ES2003, Rio de Janeiro, 2003. Citado na página 56.
VICENTE, A. A. Definição e gerenciamento de métricas de teste no contexto de métodoságeis. Dissertação (Mestrado) — USP - Universidade de São Paulo, 2010. Citado napágina 19.
WHITTAKER, M. A. J. A. How to break Web software: functional and security testingof Web applications and Web services. [S.l.: s.n.], 2006. Citado na página 28.
WINTER, J. et al. Meeting organisational needs and quality assurance through balancingagile and formal usability testing results. In: Proceedings of the Third IFIP TC 2 Centraland East European Conference on Software Engineering Techniques. Berlin, Heidelberg:Springer-Verlag, 2011. (CEE-SET’08), p. 275–289. ISBN 978-3-642-22385-3. Disponívelem: <http://dl.acm.org/citation.cfm?id=2040660.2040689>. Citado na página 53.
112 Referências
WOLKERSTORFER, P. et al. Probing an agile usability process. In: ACM. CHI’08Extended Abstracts on Human Factors in Computing Systems. [S.l.], 2008. p. 2151–2158.Citado 2 vezes nas páginas 53 e 55.
WURMAN, R. S. Ansiedade de Informação. [S.l.: s.n.], 1991. Citado na página 35.