Embed Size (px)
Citation preview
Gabriel Guadalupe RodríguezMarcela Corrêa Santos Ramos
Desenvolvimento de um sistemaacadêmico-administrativo web com foco em
usabilidade e acessibilidade
Niterói04 de junho de 2018
Gabriel Guadalupe RodríguezMarcela Corrêa Santos Ramos
Desenvolvimento de um sistemaacadêmico-administrativo web com foco em usabilidade e
acessibilidade
Trabalho de Conclusão de Curso apresentadoao Curso de Bacharelado em Sistemas de In-formação, como parte dos requisitos necessá-rios para a obtenção do título de Bacharelem Sistemas de Informação.
Universidade Federal Fluminense
Instituto de Computação
Sistemas de Informação
Orientadora: Luciana Cardoso de Castro Salgado
Niterói04 de junho de 2018
Ficha catalográfica automática - SDC/BEEGerada com informações fornecidas pelo autor
Bibliotecária responsável: Fabiana Menezes Santos da Silva - CRB7/5274
R696d Rodriguez, Gabriel Guadalupe Desenvolvimento de um sistemaacadêmico-administrativo webcom foco emusabilidade e acessibilidade : / Gabriel GuadalupeRodriguez, Marcela Corrêa Santos Ramos ; Luciana Cardoso deCastro Salgado, orientadora. Niterói, 2018. 75 f. : il.
Trabalho de Conclusão de Curso (Graduação em Sistemas deInformação)-Universidade Federal Fluminense, Escola deEngenharia, Niterói, 2018.
1. Aplicação web. 2. Usabilidade web. 3. Interação homem-máquina . 4. Pessoa com deficiência visual. 5. Produçãointelectual. I. Ramos, Marcela Corrêa Santos. II. Salgado,Luciana Cardoso de Castro, orientadora. III. UniversidadeFederal Fluminense. Escola de Engenharia. IV. Título.
CDD -
Gabriel Guadalupe RodríguezMarcela Corrêa Santos Ramos
Desenvolvimento de um sistema acadêmico-administrativo web com foco em usabilidadee acessibilidade
Trabalho de Conclusão de Curso apresentadoao Curso de Bacharelado em Sistemas de In-formação, como parte dos requisitos necessá-rios para a obtenção do título de Bacharelem Sistemas de Informação.
BANCA EXAMINADORA
Prof. Dra. Luciana Cardoso de Castro Salgado -Orientadora, UFF
Prof. Dra Isabel Leite Cafezeiro, UFF
Prof. Dr. José Viterbo Filho, UFF
Niterói2018
Agradecimentos
Eu Gabriel, agradeço especialmente à minha mãe Isabel Cristina Rodriguez Lou-reiro e à minha vó materna Maria Teresa Loureiro Rodriguez que me apoiaram ao longodessa jornada, pois seus incentivos e conselhos de vida foram valiosos para atingir aconclusão desta etapa. Também agradeço a minha parceira de TCC, melhor amiga ecompanheira de todas as horas pela perseverança.
Eu Marcela, agradeço aos meus pais Marcos dos Santos Ramos e Regina SardinhaCorrêa que sempre me apoiaram e lutaram para que eu estivesse concluindo mais essaetapa da minha vida. Aos meus irmãos, e em especial ao meu irmão Marcos dos SantosRamos Júnior que sempre esteve disposto a ensinar e compartilhar todo o seu conheci-mento. Agradeço também ao meu melhor amigo, parceiro de TCC e companheiro nessajornada que me apoiou e ajudou em todos os momentos.
À nossa orientadora Luciana Cardoso de Castro Salgado, pela dedicação e conse-lhos valiosos durante o desenvolvimento deste trabalho.
Ao professor Leonardo Cruz da Costa, pelos conselhos e ensinamentos ao longo danossa graduação. Além de ter proporcionado a inspiração para o nosso projeto através doSolicitaSI, sistema de grande ajuda para todos os alunos de Sistemas de Informação daUniversidade Federal Fluminense.
Aos amigos pelos diversos momentos compartilhados e pelo apoio incondicionaldurante toda a nossa caminhada. Em especial ao querido Guilherme da Silva Alves Gon-çalves, pelas orientações e conhecimentos compartilhados.
À toda a equipe da STI-UFF pelo seu apoio e parceria na qual sem ela não seriapossível realizar este trabalho.
Resumo
A universidade têm se tornado cada vez mais informatizada, com isso a demandapela criação de sistemas acadêmicos-administrativos tem crescido. É importante queesses sistemas sejam acessíveis para todos, com isso a importância da acessibilidadee usabilidade desde o início do processo de desenvolvimento, entretanto, existe umacomplexidade para a criação de sistemas com foco em acessibilidade e usabilidade.Neste trabalho é demonstrado o desenvolvimento de um sistema no qual aplicam-seas diretrizes da Web Content Accessibility Guidelines (WCAG) e as 10 heurísticasde Nielsen. Juntamente com as necessidades de usabilidade e acessibilidade, foramidentificadas as necessidades e problemas dos estudantes e das coordenações paraque pudéssemos agilizar e informatizar alguns processos realizados por ambos. Destaforma nosso objetivo se tornou não somente solucionar os problemas identificadoscomo também garantir que a nossa solução seja acessível à todos. Para isso, foi feitauma análise de sistemas semelhantes além da utilização de questionários e entre-vistas para levantar requisitos e elaborar a criação de personas e cenários que nosajudaram a entender o problema e desenvolver o sistema. A fim de garantir queo resultado produzido estava correto, avaliamos o nível de acessibilidade e usabili-dade, através de ferramentas automáticas e um questionário proposto para avaliara usabilidade e acessibilidade. Ambos os métodos nos permitiram concluir que osistema desenvolvido está complacente com as diretrizes WCAG e as heurísticasde Nielsen. O sistema atende as necessidades dos alunos e das coordenações doscursos de graduação da Universidade Federal Fluminense, contemplando diversasatividades realizadas por ambos os citados, tendo o foco principal nas atividades doperíodo de ajustes, que foram as identificadas como as principais para os alunos. Eletambém foi desenvolvido visando ser acessível e responsivo para diversos dispositi-vos móveis. Concluímos através dos resultados obtidos que a metodologia utilizadafoi adequada, pois resultou em um sistema com boa acessibilidade, usabilidade eaderente as necessidades dos usuários.
Palavras-chaves: Acessibilidade web. Usabilidade web. Desenvolvimento desistemas web.
Abstract
Universities have become more and more computerized, and, because of that,there’s an ever higher demand on developing academic-administrative systems. It isimportant that these systems be accessible to everyone, therefore it is crucial thatsaid accessibility be in mind from the very beginning of the development process.There is, however, a further step of complexity in the creation of systems focusedon accessibility and usability. In this work, we demonstrate the development of oursystem, which follows the Web Content Accessibility Guidelines (WCAG) directivesand also Nielsen’s 10 Usability Heuristics. Interwoven with the two abovementionedneeds, we were able to identify some necessities and problems from students andcoordinations that could be improved by introducing an informational system. Ourgoal, then, became not only to solve those problems, but also to make sure that eachand every user is able to access every piece of content of the system. To achieve that,steps such as the analysis of similar systems, the application of questionnaires andthe interviewing of possible users were done, in order to elaborate system require-ments, user personas/scenarios, with the sole purpose of assisting us with the processof understanding the problems we faced and developing the system. With the pur-pose of guaranteeing the desired result, we evaluated the levels of accessibility andusability, through the use of automated tools and a questionnaire used to assess thetwo concepts. Both methods allowed us to reach the conclusion that the developedsystem is in agreement with the WCAG guidelines and Nielsen’s heuristics. Oursystem meets the needs of students and coordinations of the Federal FluminenseUniversity, contemplating many tasks labeled as being of high priority in our sur-vey, with the main focus being on the activities revolving around the beginning ofa semester. It also was developed to be responsive and accessible while browsingfrom mobile devices. Finally, we concluded through our results that the adoptedmethodology was suitable, as it guided us to develop a system with not only gooduser accessibility and usability, but also that meets user’s needs.
Keywords: Web accessibility. Web usability. Web systems development.
Lista de ilustrações
Figura 1 – Tela do plano de estudos . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figura 2 – Tela de inscrição em disciplinas . . . . . . . . . . . . . . . . . . . . . . 45Figura 3 – Detalhes da inscrição realizada . . . . . . . . . . . . . . . . . . . . . . 45Figura 4 – Tela do plano de estudos com o link para nova inscrição selecionado . . 46Figura 5 – Tela de nova solicitação de inscrição em disciplina com dados preenchi-
dos e botão de confirmação selecionado . . . . . . . . . . . . . . . . . . 46Figura 6 – Tela de detalhes da solicitação de inscrição em disciplina com alerta
selecionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 7 – Índice de solicitação de mudança de turma, visão do aluno. . . . . . . . 68Figura 8 – Nova solicitação de mudança de turma, visão do aluno. . . . . . . . . . 68Figura 9 – Detalhamento de solicitação de mudança de turma, visão do aluno. . . 69Figura 10 – Índice de solicitação de cancelamento de inscrição, visão do aluno. . . . 69Figura 11 –Nova solicitação de cancelamento de inscrição, visão do aluno. . . . . . 70Figura 12 –Detalhamento de solicitação de cancelamento de inscrição, visão do aluno. 70Figura 13 – Índice de solicitação de declarações personalizadas, visão do aluno. . . 71Figura 14 –Nova solicitação de declarações personalizadas, visão do aluno. . . . . . 71Figura 15 –Detalhamento de solicitação de declarações personalizadas, visão do
aluno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figura 16 – Índice de solicitação de aproveitamento de disciplina, visão do aluno. . 72Figura 17 –Nova solicitação de aproveitamento de disciplina, visão do aluno. . . . 73Figura 18 –Detalhamento de solicitação de aproveitamento de disciplina, visão do
aluno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figura 19 – Índice de solicitação de inscrição em disciplina, visão da coordenação. . 74Figura 20 –Alteração de solicitação de inscrição em disciplina, visão da coordenação. 74
Lista de tabelas
Tabela 1 – Esforço por ponto de história . . . . . . . . . . . . . . . . . . . . . . . 32Tabela 2 – Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Tabela 3 – Resultados da perspectiva de inspeção . . . . . . . . . . . . . . . . . . 39Tabela 4 – Resultados do ASES nas visão da coordenação . . . . . . . . . . . . . . 39Tabela 5 – Resultados do ASES na visão dos alunos . . . . . . . . . . . . . . . . . 40Tabela 6 – Qt e MHEUA do SolicitaUFF . . . . . . . . . . . . . . . . . . . . . . . 41
Tabela 7 – Questão 13 do questionário com alunos . . . . . . . . . . . . . . . . . . 58
Tabela 8 – Requisitos da questão 1 do HEUA e respostas . . . . . . . . . . . . . . 59Tabela 9 – Requisitos da questão 2 do HEUA e respostas . . . . . . . . . . . . . . 60Tabela 10 –Requisitos da questão 3 do HEUA e respostas . . . . . . . . . . . . . . 61Tabela 11 –Requisitos da questão 4 do HEUA e respostas . . . . . . . . . . . . . . 62Tabela 12 –Requisitos da questão 5 do HEUA e respostas . . . . . . . . . . . . . . 63Tabela 13 –Requisitos da questão 6 do HEUA e respostas . . . . . . . . . . . . . . 64Tabela 14 –Requisitos da questão 7 do HEUA e respostas . . . . . . . . . . . . . . 65Tabela 15 –Requisitos da questão 8 do HEUA e respostas . . . . . . . . . . . . . . 66Tabela 16 –Requisitos da questão 9 do HEUA e respostas . . . . . . . . . . . . . . 66Tabela 17 –Requisitos da questão 10 do HEUA e respostas . . . . . . . . . . . . . 67
Sumário
1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Motivações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Fundamentação Conceitual . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1 Acessibilidade na web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Recomendações de acessibilidade para conteúdo da web . . . . . . . 162.1.2 Acessibilidade web no Brasil . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Usabilidade na web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 O processo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1 Avaliação de usabilidade e acessibilidade em sistemas web . . . . . . . . . . 213.2 A importância da interface de sistemas acadêmicos . . . . . . . . . . . . . 22
4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1 Objetivos e Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Resultado da Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1 Definição de Personas . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.2 Criação de Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.3 Definição de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.3.1 Metas de usabilidade . . . . . . . . . . . . . . . . . . . . . 264.3.3.2 Metas de acessibilidade . . . . . . . . . . . . . . . . . . . 26
4.4 Avaliações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.1 Avaliações de Software . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.2 Avaliação de Usabilidade e Acessibilidade . . . . . . . . . . . . . . . 27
5 Processo de desenvolvimento do SolicitaUFF . . . . . . . . . . . . . . . . . 285.1 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1 Formulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.1.1 Informações coletadas . . . . . . . . . . . . . . . . . . . . 29
5.1.2 Elicitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.2.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . 30
5.1.2.2 Requisitos não-funcionais . . . . . . . . . . . . . . . . . . 315.1.3 Negociação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.1 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3.2 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.3 Cenários evidenciando a importância da acessibilidade . . . . . . . 35
5.4 Construção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4.1 Linguagem e Framework . . . . . . . . . . . . . . . . . . . . . . . . 365.4.2 Bancos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.3 Versionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4.4 Codificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4.4.1 Qualidade de código . . . . . . . . . . . . . . . . . . . . . 375.4.4.2 Testes unitários e de integração . . . . . . . . . . . . . . . 38
5.4.5 Método de avaliação ACCESSA . . . . . . . . . . . . . . . . . . . . 385.4.5.1 Avaliação de conformidade com as diretrizes do WCAG 2.0 385.4.5.2 Ferramenta automática ASES . . . . . . . . . . . . . . . . 39
5.4.6 Métrica HEUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 SolicitaUFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Cenários de Interação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Anexos 51
ANEXO A Entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.1 TCLE - Termo de Consentimento Livre e Esclarecido . . . . . . . . . . . . 52A.2 Roteiro das entrevistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
ANEXO B Questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.1 TCLE - Termo de Consentimento Livre e Esclarecido . . . . . . . . . . . . 54B.2 Perguntas do questionário . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ANEXO C Resultados do HEUA . . . . . . . . . . . . . . . . . . . . . . . . . 59C.1 Questão 1 - O sistema mantém o usuário sempre informado sobre o que
está ocorrendo por meio de feedbacks em tempo real? . . . . . . . . . . . . 59
SUMÁRIO 11
C.2 Questão 2 - O sistema utiliza a linguagem e o modelo mental do usuáriocom características na interface que são correspondentes ao mundo real? . . 60
C.3 Questão 3 - O sistema oferece controle e liberdade ao usuário para sair deestados indesejáveis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.4 Questão 4 - O sistema é consistente e segue o mesmo padrão em toda ainterface a fim de facilitar o reconhecimento do usuário? . . . . . . . . . . 62
C.5 Questão 5 - O sistema apresenta um projeto (design) preventivo e cuidadosoque pode ser capaz de evitar algum problema durante a interação do usuário? 63
C.6 Questão 6 - O sistema evita a sobrecarga de memória do usuário fornecendoinformações contextuais para cada ação? . . . . . . . . . . . . . . . . . . . 64
C.7 Questão 7 - O sistema oferece flexibilidade e eficiência aos usuários, agi-lizando o uso para usuários experientes e mantendo a facilidade para osnovatos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
C.8 Questão 8 - O sistema oferece estética e projeto (design) minimalista, man-tendo apenas informações úteis, diretas e claras? . . . . . . . . . . . . . . . 66
C.9 Questão 9 - O sistema ajuda o usuário a reconhecer, diagnosticar e corrigirerros? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
C.10 Questão 10 - O sistema fornece uma ajuda documentada que pode serfacilmente encontrada em caso de necessidade? . . . . . . . . . . . . . . . . 67
ANEXO D Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.1 Mudança de Turma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68D.2 Cancelamento de Inscrição . . . . . . . . . . . . . . . . . . . . . . . . . . . 69D.3 Declaração Personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71D.4 Aproveitamento de Disciplina . . . . . . . . . . . . . . . . . . . . . . . . . 72D.5 Inscrição em Disciplina - Visão da coordenação . . . . . . . . . . . . . . . . 74D.6 Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12
1 Introdução
Os sistemas de informação estão presentes em todos os âmbitos da nossa sociedadee cada vez mais fazem parte das tarefas que desempenhamos diariamente. Nesse contextoas interações das pessoas com as mais diversas interfaces computacionais são de grandeimportância para o aproveitamento eficiente dos recursos humanos disponíveis e para ainclusão de todos os indivíduos. Essas interações com as interfaces homem-máquina sãoobjeto de estudo discutido e de importância reconhecida (MELO, 2014), além de seremferramentas essenciais para a inclusão das pessoas com deficiência.
1.1 ContextualizaçãoPara atender as demandas acadêmicas e administrativas as universidades tem in-
vestido cada vez mais em tecnologia da informação, assim como em acessibilidade, afimde promover maior inclusão de pessoas com deficiência no ensino superior. (MELO, 2017).Neste trabalho abordaremos as questões e o cenário da Universidade Federal Fluminense,seus alunos, colaboradores e suas necessidades e sistemas.
“O problema a ser resolvido é encontrar uma boa forma de melhorar uma ou maiscaracterísticas da situação atual. Em outras palavras, resolver um problema de designsignifica responder a pergunta: Como melhorar a situação atual?” (BARBOSA; SILVA,2010). Devemos analisar a situação, buscando conhecer os elementos envolvidos e a relaçãoentre eles. Analisamos as pessoas, artefatos e processos. Deste modo, compreende-se asnecessidades dos usuários, encontrar problemas e características desagradáveis e algo quepodemos melhorar.
Na situação atual os processos desempenhados pelas coordenações e alunos sãobastante manuais e nada integrados com outros sistemas da universidade, com isso, gasta-se muito tempo processando informações. Neste caso, a análise da situação atual foiimportante para identificarmos que um sistema poderia ser empregado para melhorar oprocesso, e como consequência, este processo poderia ser executado mais rapidamente.Deste modo, a meta de design é aumentar a eficiência dessas tarefas, que é um dos fatoresde usabilidade.
Para suportar a análise dos processos desempenhados pelas coordenações e alunos,a técnica de cenários é de grande ajuda pois permite explicitar as ações do usuário esuas dificuldades. “Cenários são objetos de design orientados a tarefas. Eles descrevemsistemas em termos de tarefas que os usuários tentarão fazer quando utilizarem essessistemas, certificando-se que o design permanecerá focado nas necessidades e interesses
Capítulo 1. Introdução 13
dos usuários.” (CARROLL; ROSSON, 1990).
Além da técnica de cenários, utilizamos a técnica de personas, na qual, uma per-sona é um personagem fictício criado para descrever um usuário típico. A técnica depersonas foi utilizada para representar os usuários finais do sistema para nos auxiliar du-rante as discussões de design, mantendo o foco no mesmo alvo. Durante a investigaçãoinicial do domínio, definimos as personas por seus objetivos e perfis. (BARBOSA; SILVA,2010).
Percebemos que passar a utilizar um sistema para auxiliar as tarefas é uma soluçãopara o problema, é uma intervenção positiva.(BARBOSA; SILVA, 2010). No entanto, énecessário que esse sistema esteja integrado com outros sistemas da universidade e tenhamanutenção.
Finalmente, o processo de desenvolvimento de um sistema influencia na qualidadedo produto final. Vários aspectos devem ser avaliados em relação a um sistema, algunsrelacionados a construção do sistema (facilidade de manutenção e robustez) e outros como seu uso (usabilidade e acessibilidade). Para que os usuários possam usufruir do sistema,o designer deve remover as barreiras da interface que impedem o usuário de interagir(acessibilidade) e torne o uso fácil (usabilidade). (BARBOSA; SILVA, 2010).
1.2 MotivaçõesA relação entre alunos e coordenações da Universidade Federal Fluminense, no que
tange o requerimento de processos administrativos dá-se de modo pouco automatizado. Osalunos necessitam comparecer à coordenação para realizar pedidos como: requerimento deatividade complementar; dispensas em disciplinas; aproveitamento de disciplinas; ajustesno plano de estudos; pedidos de declarações diversas. Todas essas são tarefas que poderiamser facilitadas com um sistema que serviria de interface entre a coordenação e o aluno,tornando os processos mais rápidos, transparentes e auditáveis.
Para tanto, é necessário que tal sistema atenda o máximo possível de usuários,dessa forma precisamos abranger também os usuários com deficiência a fim de promovera inclusão desse grupo de pessoas. Portanto, o aspecto da acessibilidade se torna muitorelevante nesse contexto.
De acordo com um estudo realizado pela Web Accessibility in Mind (WEBAIM,2017), cerca de 40,4% e 18,8% dos respondentes deficientes tiveram, respectivamente, umapercepção neutra e ruim sobre acessibilidade dos conteúdos web que tiveram contato noano de 2016.
Há inúmeras dificuldades que os alunos com deficiência visual enfrentam ao li-dar com os sistemas da universidade, os sistemas não estão preparados para atendê-los e
Capítulo 1. Introdução 14
portanto deixam de ser uma oportunidade de inclusão dessas pessoas e passam a ser umobstáculo. “Lutar contra a evasão desses estudantes, possibilitando a sua permanência, in-vestindo esforços e recursos para que a acessibilidade deixe de ser tão somente um aspectogarantido na legislação e em documentos sobre a reforma universitária.” (OLIVEIRA,2018). O que significa que a universidade aceita a deficiência e investe em acessibilidade,assim, possibilitando a permanência de todos.
1.3 ObjetivosA fim de atender as demandas e as falhas identificadas na seção anterior, adqui-
rimos o conhecimento necessário através da pesquisa de acessibilidade e usabilidade e ainvestigação de trabalhos relacionados para aplicar as teorias estudadas e as avaliaçõesde usabilidade e acessibilidade em um sistema integrado com os demais da UniversidadeFederal Fluminense, que seja focado nas necessidades dos alunos e das coordenações.
A inexistência de sistemas acessíveis nas universidades e as políticas de inclusãono ensino superior (MELO, 2017) e a obrigação segundo o decreto de No 5.296 de 2 dedezembro de 20041, nos motivou para a nossa pesquisa.
O objetivo deste trabalho é a criação de um sistema acadêmico-administrativo comfoco em acessibilidade e usabilidade desde o seu desenvolvimento e com isso, mostrar queé possível melhorar os processos e sistemas da universidade para todos.
1.4 Organização do trabalhoAlém deste capítulo que apresenta a contextualização, motivações e objetivos, o
trabalho está organizado da seguinte forma: o Capítulo 2 expõe a fundamentação concei-tual; Expondo recomendações de acessibilidade, conceitos de usabilidade para conteúdoweb e o processo de desenvolvimento com foco em acessibilidade e usabilidade; O Ca-pítulo 3 apresenta alguns trabalhos relacionados que apresentam métodos de avaliaçãoda usabilidade e acessibilidade dos sistemas web, além de um estudo de usabilidade quepropõe o re-design da interface de um sistema semelhante; O Capítulo 4 mostra a me-todologia utilizada na pesquisa e criação do sistema; O Capítulo 5 descreve o processode desenvolvimento do sistema SolicitaUFF; O Capítulo 6 apresenta o sistema desenvol-vido e exemplifica alguns cenários de interação com o sistema; O Capítulo 7 apresenta asconsiderações finais, limitações e trabalhos futuros; Os anexos detalham a aplicação dealguns métodos de avaliação e as interfaces produzidas tanto para “desktop” quanto paradispositivos móveis.
1 http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm, acesso em:25/11/2018
15
2 Fundamentação Conceitual
Este capítulo tem como objetivo fundamentar a pesquisa, são apresentados con-ceitos sobre acessibilidade e usabilidade web. Abordamos as mais importantes fontes econceitos que se relacionam com o tema da pesquisa, apontam-se as principais diretrizesdocumentadas pela WCAG 2.0. O conteúdo desta seção nos ajudou a compreender maisprecisamente a problemática a ser estudada. Ao final, aborda-se como é o processo dedesenvolvimento focado em acessibilidade e usabilidade.
2.1 Acessibilidade na webPara um sistema ser considerado acessível os usuários deficientes devem ser capazes
de acessarem a interface do sistema e interagirem com ele, é necessário remover as barreirasque impedem esses usuários de utilizarem o sistema. Não podem existir barreiras que osimpeçam de interagirem com a interface. “Cuidar da acessibilidade significa permitir quemais pessoas possam interagir com o sistema, tenham elas alguma deficiência ou não. Aintenção é incluir, não excluir.” (BARBOSA; SILVA, 2010).
Para acessibilidade total, todos os usuários devem poder fazer três coisas para cadacontrole, instrução ou saída. Segundo Nirmita Narasimhan (NARASIMHAN, 2010) paraatingir a acessibilidade plena, todos os usuários devem ter os 3 princípios atendidos:
∙ Perceber - Estar ciente da existência e ser capaz de acessar a informação.
∙ Entender - Saber o significado e como usá-lo.
∙ Operar - Ser capaz de operá-lo fisicamente.
Para atingir esses 3 princípios podemos utilizar os seguintes métodos propostos:
∙ Responsividade - Diferentes tamanhos de texto se adéquam as pessoas com diferentescapacidades visuais.
∙ Diversidade de métodos de interação - Permitir a possibilidade da navegação peloteclado.
∙ Diversidade de saídas - Saídas visuais e sonoras podem abranger diversas formas dedeficiência.
Capítulo 2. Fundamentação Conceitual 16
Além disso, é necessário garantir a compatibilidade com as diversas tecnologiasassistivas, seguindo os padrões internacionais. Isso também pode resultar em melhoriasna experiência de todos os usuários.
Portanto, a interface não pode ser um obstáculo, é importante que o usuário sejacapaz de interagir com o sistema. Para que os usuários não encontrem barreiras, guiare-mos nossa solução de IHC de acordo com os padrões Web Content Accessibility Guidelines(WCAG), Modelo de Acessibilidade em Governo Eletrônico (eMAG) e Web AccessibilityInitiate (WAI-ARIA) - a WAI é uma iniciativa e ARIA é um padrão criados pelo WorldWide Web Consortium (W3C), a qual define princípios e regras de interface e desenvol-vimento de sistemas acessíveis a pessoas com deficiências.
2.1.1 Recomendações de acessibilidade para conteúdo da web
A WCAG está atualmente em sua segunda versão (2.0), focando-se em quatroprincípios (percepção, compreensão, operação e robustez) que se subdividem, totalizandodoze diretrizes principais:1
Princípio 1 - Percetível: A informação e os componentes da interface de usuário têmde ser apresentados de forma a que os usuários as possam perceber.
Diretriz 1.1 (Alternativas em Texto): Fornecer alternativas em texto para todoo conteúdo não textual de modo a que o mesmo possa ser apresentado de ou-tras formas, de acordo com as necessidades dos utilizadores, como por exemplo:caracteres ampliados, braille, fala, símbolos ou uma linguagem mais simples.
Diretriz 1.2 (Mídia Dinâmica ou Contínua): Fornecer alternativas para con-teúdo em multimídia dinâmica ou temporal.
Diretriz 1.3 (Adaptável): Criar conteúdo que possa ser apresentado de diferentesformas sem perder informação ou estrutura.
Diretriz 1.4 (Distinguível): Facilitar aos utilizadores a audição e a visão dosconteúdos nomeadamente através da separação do primeiro plano do plano defundo.
Princípio 2 - Operável: Os componentes da interface do usuário e a navegação têm deser operáveis.
Diretriz 2.1 (Acessível por Teclado): Fazer com que toda a funcionalidade fi-que disponível a partir do teclado.
1 http://emag.governoeletronico.gov.br/cursoconteudista/desenvolvimento-web/recomendacoes-de-acessibilidade-wcag2.html, accesso em: 25/11/2018
Capítulo 2. Fundamentação Conceitual 17
Diretriz 2.2 (Tempo Suficiente): Proporcionar aos utilizadores tempo suficientepara lerem e utilizarem o conteúdo.
Diretriz 2.3 (Convulsões): Não criar conteúdo de uma forma que se sabe quepode causar convulsões.
Diretriz 2.4 (Navegável): Fornecer formas de ajudar os utilizadores a navegar,localizar conteúdos e determinar o local onde estão.
Princípio 3 - Compreensível: A informação e a utilização da interface do usuário têmde ser compreensíveis.
Diretriz 3.1 (Legível): Tornar o conteúdo textual legível e compreensível.
Diretriz 3.2 (Previsível): Fazer com que as páginas web apareçam e funcionemde forma previsível.
Diretriz 3.3 (Assistência na Inserção de Dados): Ajudar os utilizadores a evi-tar e a corrigir os erros.
Princípio 4 - Robusto: O conteúdo deve ser suficientemente robusto para ser interpre-tado de forma concisa por uma ampla variedade de agentes do usuário, incluindo astecnologias de apoio.
Diretriz 4.1 (Compatível): Maximizar a compatibilidade com os agentes de uti-lizador atuais e futuros, incluindo as tecnologias de apoio.
2.1.2 Acessibilidade web no Brasil
No Brasil, temos o Modelo de Acessibilidade Brasileiro (eMAG 3.1), desenvolvidopara o governo brasileiro, focado em acessibilidade. Na parte 3 deste modelo existemseis sessões com recomendações de acessibilidade e diretizes baseadas na WCAG 2.0,totalizando 45 recomendações.2
∙ Marcação - HTML (9 recomendações)
∙ Comportamento (7 recomendações)
∙ Conteúdo e Informação (12 recomendações)
∙ Apresentação e Design (4 recomendações)
∙ Multimídia (5 recomendações)
∙ Formulários (8 recomendações)2 http://emag.governoeletronico.gov.br/cursoconteudista/desenvolvimento-web/
recomendacoes-de-acessibilidade-emag.html, acesso em: 05/10/2018
Capítulo 2. Fundamentação Conceitual 18
O eMAG é um documento com recomendações a serem consideradas no desen-volvimento e adaptação de conteúdos digitais de sites e portais de instituições públicasdo Brasil, garantindo o acesso a todos, para que o processo de acessibilidade desses sitesseja conduzido de forma padronizada e de fácil implementação. A versão atual 3.1 doeMAG apresenta partes do conteúdo em uma visão mais técnica do assunto, para aten-der aos profissionais da área de tecnologia, e uma visão mais superficial para atenderos usuários mais leigos, permitindo uma compreensão maior por qualquer cidadão. Alémdisso, o documento traz conteúdos extras referentes à acessibilidade, legislação e leiturascomplementares.
A preocupação com a inclusão de pessoas com deficiências é um tema de grandeimportância. Em 2004 , a criação do decreto de No 5.296 de 2 de dezembro de 20043 tor-nou obrigatória a disponibilização de sites do governo em conformidade com os padrõesde acessibilidade. Neste sentido, surgiu a necessidade de criar um modelo de acessibili-dade em governo eletrônico (eMAG) para adequar sites institucionais e governamentais,considerando a realidade brasileira. Podemos destacar o artigo 47 do decreto de No 5.296de 2 de dezembro de 2004:
“Art. 47. No prazo de até doze meses a contar da data de publica-ção deste Decreto, será obrigatória a acessibilidade nos portais e sítioseletrônicos da administração pública na rede mundial de computado-res (Internet), para o uso das pessoas portadoras de deficiência visual,garantindo-lhes o pleno acesso às informações disponíveis. ”
Como forma de avaliação de acessibilidade de páginas web de acordo com as re-comendações do Modelo de Acessibilidade em Governo Eletrônico (eMAG), o governobrasileiro disponibiliza a ferramenta Avaliador e Simulador de Acessibilidade em Sítios(ASES) que permite avaliar, simular e corrigir a acessibilidade de páginas, sites e portais.O ASES tem o propósito de auxiliar a construção de sites para que sejam acessíveis aqualquer pessoa, independente do seu tipo de deficiência e dispositivo de navegação.
2.2 Usabilidade na web“A usabilidade está relacionada com a facilidade de aprendizado e uso da inter-
face, bem como a satisfação do usuário em decorrência desse uso” (NIELSEN, 2012). Osistema deve executar as funções que os usuários necessitam para alcançar seus objetivos.A facilidade de aprendizado está diretamente ligada a velocidade com que os usuáriosconseguem aprender a executar determinada tarefa, em geral, procedimentos mais rápi-dos tendem a ser mais eficientes. É importante que o sistema possua uma interface quefacilite que o usuário resgate da memória o que aprendeu, portanto, os elementos devem3 http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm, acesso em:
05/10/2018
Capítulo 2. Fundamentação Conceitual 19
estar organizados de maneira que o usuário encontre facilidade em lembrar como utilizaro sistema e assim, executar suas tarefas.
As metas de usabilidade de segundo Jakob Nielsen (1993) são:
1. Eficácia
2. Eficiência
3. Segurança
4. Utilidade
5. Aprendizagem
6. Memorização
De acordo com a ISO (International Standard Organization):
∙ Usabilidade é a capacidade do produto de software de ser compreendido, aprendido,operado e atraente ao usuário, quando usado sob condições especificadas. (NBRISO/IEC 9126-1, 2003)4.
∙ A definição de qualidade de uso da ISO 9241-115 é o quanto um produto, utilizadopor usuários específicos, atende às necessidades desses usuários para que eles atinjamas metas especificadas com eficácia, produtividade e satisfação, em contextos de usodefinidos.
“A usabilidade é o critério de qualidade de uso mais conhecido e, por conseguinte, omais frequentemente considerado. Para muitas pessoas, inclusive, qualidade de uso chegaa ser sinônimo de usabilidade.” (BARBOSA; SILVA, 2010). Portanto, a interação e ainterface devem ser adequadas para que o usuário aprenda facilmente a utilizar o sistemae possa alcançar seu objetivo com satisfação.
“Na web, usabilidade é uma requerimento necessário para a sobrevivên-cia. Se um site é difícil de usar, as pessoas vão embora. Se uma páginafalha em expor claramente o que uma empresa oferece e o que os usuáriospodem fazer no site, as pessoas vão embora. Se os usuários se perdemno site, eles vão embora. Se a informação de um site é difícil de ler ounão responde as perguntas dos usuários, eles vão embora.” (NIELSEN,2012)
Observa-se a importância de IHC através das constatações de Jakob Nielsen. Se ainteração entre o sistema e o usuário não for fácil e intuitiva, o usuário abandona a tarefaque estava tentando realizar e procura outras alternativas.4 https://aplicacoes.mds.gov.br/sagirmps/simulacao/sum_executivo/pdf/fichatecnica_21.
pdf, acesso em: 25/11/20185 https://www.iso.org/obp/ui/#iso:std:iso:9241:-11:ed-2:v1:en, acesso em: 25/11/2018
Capítulo 2. Fundamentação Conceitual 20
2.3 O processo de desenvolvimentoAo longo de nossa jornada acadêmica, conhecemos metodologias ágeis, entre elas,
o Scrum 6, o qual temos bastante contato até hoje. Para o desenvolvimento de um sistemacom foco em usabilidade e acessibilidade, em nossas pesquisas, conhecemos o Processo deDesenvolvimento de sistemas web com Acessiblidade e Usabilidade (PDWAU), no qualvimos a possibilidade de utilizá-lo de forma adaptada junto com o Scrum.
De forma adaptada, utilizamos os pontos de histórias7, para estimar requisitos epara melhorar a previsão da quantidade de trabalho que somos capazes de realizar emcada sprint.
“O processo de desenvolvimento de sistemas web com acessibilidade e usabilidadefoi denominado PDWAU - Process for Developing Web system with Accessibility and Usa-bility.” (DIAS, 2014). O referido processo não é tido como uma versão final ou absolutade como se deve desenvolver um sistema levando em consideração as diretrizes de usabili-dade e acessibilidade, porém, segundo a autora, “o processo permite ter uma base sólidaem relação à sua construção sobre os aspectos de acessibilidade e usabilidade, visto quefoi desenvolvido sobre resultados de estudos que tinham esse tema como foco principal.”(DIAS, 2014).
Instanciamos no Capítulo 5 o processo de desenvolvimento do sistema web comfoco em acessibilidade e usabilidade e mostramos ao final o resultado do questionárioHEUA para avaliar o nível de usabilidade e acessibilidade do nosso sistema.
6 https://www.desenvolvimentoagil.com.br/scrum/, acesso em: 25/11/20187 https://confluence.atlassian.com/jsbr/estimar-em-pontos-de-historia-920354862.html,
acesso em: 25/11/2018
21
3 Trabalhos relacionados
Neste capítulo apresentam-se estudos que abordam como medir a usabilidade eacessibilidade em sistemas web. Na seção 3.1 temos um estudo da aplicação da métricaHEUA para um avaliação heurística, além de apresentar o método que avalia a acessibi-lidade e usabilidade de sistemas web através de quatro perspectivas. Por fim, na seção3.2 destacamos um estudo de usabilidade e re-design de um sistema web acadêmico-administrativo.
3.1 Avaliação de usabilidade e acessibilidade em sistemas webLópez e colegas (LÓPEZ et al., 2012) argumentam que o uso de ferramentas de
verificação automática já são suficientes para garantir boa acessibilidade, porém, segundoo artigo citado, essas ferramentas não conseguem verificar todos os casos e fazer umainterpretação contextualizada das regras propostas internacionalmente, como a WCAG,e portanto faz-se necessário um método capaz de avaliar a acessibilidade e usabilidademanualmente.
Para suprir essa necessidade, Dias e co-autores (DIAS; FORTES; MASIERO, 2014)propuseram o questionário HEUA1 capaz de mensurar a qualidade da usabilidade e aces-sibilidade dos sistemas web. Esse questionário consiste em 93 requerimentos classificadosem 10 perguntas que servem como guias para a avaliação heurística do requerimento quedevem ser respondidos com “sim”, “não” e “não se aplica”. Após o final a pontuação écalculada e é gerado um coefiente variando de -100 a +100 que classifica o sistema deacordo com o nível de adequação dele em termos de acessibilidade e usabilidade. Um coe-ficiente negativo significa pior acessibilidade e usabilidade, enquanto coeficientes positivosse aproximam mais de atender completamente o usuário.
Também é possível através do HEUA manter um histórico e realizar um acom-panhamento dos níveis de acessibilidade e usabilidade de determinado sistema, podendoser usado nas diversas fases do ciclo de vida de um sistema ou continuamente para ossistemas que estão em constante desenvolvimento.
Os autores (DIAS; FORTES; MASIERO, 2014) então concluem que o HEUA semostrou uma boa ferramenta para quantificar os níveis de usabilidade e acessibilidade,gerando resultados que apontam quais áreas devem receber mais atenção e permitindoaté mesmo a comparação de sistemas diferentes através da pontuação gerada.
Dias e co-autores (DIAS et al., 2013) também propõem um método chamado AC-1 HEUA: A heuristic evaluation with Usability and Accessibility requirements to assess web systems
Capítulo 3. Trabalhos relacionados 22
CESSA para a verificação de acessibilidade e usabilidade. Assim como no artigo “HEUA: Aheuristic evaluation with Usability and Accessibility requirements to assess web systems”(DIAS; FORTES; MASIERO, 2014), eles consideram que as ferramentas de verificaçãoautomática não são precisas o suficiente para serem usadas sozinhas, por terem falhas aocontextualizar as regras definidas nos padrões internacionais com a relevância do elementoque está sendo analisado.
Portanto o ACCESSA propõe 4 perspectivas diferentes que combinadas trazemresultados mais precisos na análise da acessibilidade e usabilidade do sistema. São elas:“Inspection’s perspective”, onde um especialista analisa a conformidade do sistema com osprincípios WCAG 2.0, “Tool’s Perspective”, onde são usadas as ferramentas de verificaçãoautomática, como Hera2 e daSilva3; “User’s Perspective”, que faz uma análise através dosrelatos do usuário, podendo utilizar questionários, entrevistas e as falas do usuário duranteo uso; “Expert’s perspective”, que consiste na análise das ações que os usuários fizeramao executar tarefas no sistema.
O estudo (DIAS et al., 2013) conclui que ao aplicar o ACCESSA no desenvolvi-mento da versão 2 do sistema AgendAloca, foi possível priorizar as regras do WCAG 2.0que trariam maior benefício de acessibilidade e usabilidade com o menor esforço. Dessaforma o tempo necessário para executar as tarefas atribuídas foi reduzido na maioria doscasos e a quantidade de erros ao executar as tarefas foi reduzida para todos os casos.Acredita-se que esses resultados são o reflexo de um sistema com melhor usabilidade eacessibilidade.
3.2 A importância da interface de sistemas acadêmicosBORGES, 2016, realizou um estudo de usabilidade e re-design de interface de
sistemas acadêmicos, que tem como objetivo descrever o processo de re-design de interfacede um sistema. O sistema em questão (SolicitaSI) visa auxiliar os processos de solicitaçõesque os alunos desejam realizar no período de ajustes. A cada semestre na universidade,os alunos podem trocar de turma, solicitar dispensas de disciplinas, cancelar disciplinasjá inscritas, entre outros. O sistema auxilia também os funcionários responsáveis porresponder essas solicitações. Além das solicitações que só podem ser feitas dentro doperíodo de ajustes, o sistema permite: solicitação de estagio; solicitação de carga horáriade atividades complementares; e cadastro de projeto final.
O foco do artigo foi reformular a interface desse sistema, seguindo diretrizes doW3C, para assim, tornar o conteúdo acessível. Na etapa de análise da situação atual,de forma anônima alunos do curso de sistemas de Informação da UFF, responderam a2 http://www.sidar.org/hera, acesso em: 25/11/20183 http://www.dasilva.org.br, acesso em: 25/11/2018
Capítulo 3. Trabalhos relacionados 23
um questionário que tinha como objetivo caracterizar o perfil do aluno mapeando suasexpectativas e problemas encontrados ao utilizar o sistema. Para compreender com maisprofundidade as dificuldades dos alunos, foi feito um teste de usabilidade e em seguidauma pequena entrevista.
Após a interface redesenhada e implantada a autora destaca que houve uma me-lhora na quantidade de acertos ao preencher os formulários, porém os problemas previ-amente relatados sobre o aviso da necessidade de impressão dos formulários não foramcompletamente resolvidos, pois, após o re-design a mensagem sumia após o pressionar deum botão.
Em suas considerações finais, a autora destaca que “Após o re-design da interface,foi possível comprovar que houve uma melhoria significativa na execução das atividadesrealizadas pelos alunos que executaram os testes de usabilidade.” (BORGES, 2016).
Durante o estudo dos trabalhos relacionados, verificamos que o trabalho de (BOR-GES, 2016) muito se assemelha com o nosso, porém, o nosso escopo se tornou maisabrangente pois foi necessário a implementação das funcionalidades do sistema, além deatender genericamente todas as coordenações da Universidade Federal Fluminense. Utili-zamos também os métodos propostos no trabalho de (DIAS; FORTES; MASIERO, 2014)e de (DIAS et al., 2013) para guiar o nosso projeto e análise do sistema produzido.
24
4 Metodologia
A pesquisa desenvolvida neste trabalho visa proporcionar uma maior familiari-dade no desenvolvimento de sistemas acessíveis. Além de criar de um sistema acadêmico-administrativo com foco em acessibilidade e usabilidade desde o início do seu desenvolvi-mento.
As técnicas de coleta de dados utilizadas nesta pesquisa foram principalmenteo questionário e as entrevistas, para assim, compreender as necessidades dos usuáriosfinais. “A entrevista é um importante instrumento para a coleta de dados na efetivaçãode uma pesquisa. Na entrevista o informante fala, no questionário o informante escreve.”(HEERDT; LEONEL, 2007).
4.1 Objetivos e MétodosAs questões que norteiam o desenvolvimento deste trabalho são:
∙ Como melhorar o processo de solicitações da coordenação?
∙ Como desenvolver um sistema com foco em usabilidade e acessibilidade?
∙ Como avaliar se um sistema é acessível e usável?
A metodologia iniciou-se com uma pesquisa bibliográfica, que foi fundamental paraampliar o grau de conhecimento da área de interface homem-computador, nos capacitandoa compreender melhor o foco de nossa pesquisa, construindo assim uma base teórica a fimde utilizá-la na construção do trabalho.
No segundo passo, utilizamos o método indutivo, no qual a partir da análise dosdados fornecidos pelo artigo (BORGES, 2016), o que nos fez perceber que um sistemacom essas funcionalidades seria de grande benefício para toda a universidade. Analisamosos dados dos questionários, o perfil dos usuários e seus objetivos, de que forma o sistemaauxilia os funcionários e de forma geral como o sistema funciona.
Capítulo 4. Metodologia 25
4.2 Coleta de Dados
1. Definir o objetivo:
∙ Como é hoje o processo de solicitações nas coordenações da universidade?
2. Definir a técnica:
∙ Entrevista semi-estruturada com o objetivo de coletar dados qualitativos.
∙ Questionários eletrônicos com o objetivo de coletar dados quantitativos.
Através de entrevistas e questionários com os usuários, coletamos informações parao levantamento dos requisitos, que será focado nas funcionalidades que o usuário necessita(requisitos funcionais) e nos critérios de qualidade de IHC: usabilidade e acessibilidade(requisitos não-funcionais).
4.3 Resultado da AnáliseEste trabalho utiliza-se de resultados quantitativos e qualitativos. Recorre ao quan-
titativo para encontrar problemas que os estudantes queixam-se. Já no qualitativo, visaaprofundar a compreensão sobre os processos e levantar requisitos. Além de buscar solu-cionar problemas de pessoas deficientes visuais.
Através das técnicas de coleta (entrevistas e questionários) obtivemos um entendi-mento a respeito dos problemas e frustrações dos usuários com o processo atual. Com issofoi possível definir as personas, criar cenários, definir requisitos funcionais e não-funcionais.
4.3.1 Definição de Personas
Com o objetivo de manter os usuários em mente durante todo o processo de de-sign, foi necessária a definição de personas que ajudaram a representar os interesses dosusuários, para isso foi necessário:
1. Definir o perfil dos usuários;
2. Elaborar cada persona e seus objetivos.
4.3.2 Criação de Cenários
Através da análise dos dados coletados com os usuários e a criação dos cenários,foi possível adquirir conhecimento sobre o usuário e suas necessidades para podermosgerar alternativas de design para este futuro usuário do sistema. Criamos cenários para
Capítulo 4. Metodologia 26
a análise do problema, a fim de compreender o que eles fazem, como, e quais problemasenfrentam, como pode ser visto no Capítulo 5. E em busca de detalhar as ações do usuárioe as respectivas respostas do sistema criamos cenário de interação, como pode ser vistono Capítulo 6.
4.3.3 Definição de Requisitos
A definição dos requisitos foi realizada através da análise dos dados coletados nasentrevistas e questionários com os usuários e a inspeção de sistema semelhante. Após alistagem dos requisitos, eles foram organizadas em requisitos funcionais e não-funcionaise serão apresentados na seção 5.1.2.
Com base nas pesquisas dos padrões eMAG, WCAG e WAI-ARIA, no estudo dos3 princípios de Nirmita Narasimhan (NARASIMHAN, 2010) e das 6 metas de Nielsen(NIELSEN, 2012), foi possível definir metas tangíveis de usabilidade e acessibilidade.
Nossa análise privilegia alguns dos critérios de qualidade de uso, com isso, defini-mos as metas de usabilidade e acessibilidade.
4.3.3.1 Metas de usabilidade
∙ Todo usuário deve ser capaz de encontrar as informações no sistema.
∙ Todo usuário deve ser capaz de entender as informações no sistema.
∙ O sistema deve prover retorno claro e preciso para o usuário após uma ação serefetuada.
4.3.3.2 Metas de acessibilidade
∙ Permitir que os usuários de leitores de tela tenham acesso a toda a informaçãodisponível no sistema e livre navegação entre as funcionalidades.
∙ Permitir que o sistema adéque-se às diversas configurações de tamanho de fonte dosusuários.
4.4 AvaliaçõesA avaliação de IHC tem como objetivo verificar se a implementação está correta e
se segue o design, além de avaliar o nível de acessibilidade e usabilidade do sistema. Temoscomo foco da nossa avaliação as funcionalidades do sistema, consideramos avaliações desoftware, usabilidade e acessibilidade.
Capítulo 4. Metodologia 27
4.4.1 Avaliações de Software
Para realizar os testes de software foram utilizadas ferramentas específicas da lin-guagem e framework escolhidos. Como o RSpec1 e o Rubocop2, capazes de testar o funcio-namento do código e as boas práticas de estilo de código, respectivamente. Esses testes sãoprogramados visando testar o comportamento do sistema avaliando cenários e contextosespecíficos, tanto definidos pelo diagrama de hierarquia de tarefas quanto pelas especi-ficidades da tecnologia, testando assim as saídas do sistema de acordo com as entradasoferecidas.
4.4.2 Avaliação de Usabilidade e Acessibilidade
Durante o desenvolvimento do sistema, utilizamos as 10 heurísticas de Nielsen(NIELSEN, 1995) que visam a usabilidade:
1. Visibilidade do estado do sistema
2. Compatibilidade entre o sistema e o mundo real
3. Controle e liberdade para o usuário
4. Consistência e Padronização
5. Prevenção de erros
6. Reconhecimento em vez de memorização
7. Eficiência e flexibilidade de uso
8. Estética e design minimalista
9. Ajudar os usuários a reconhecer, diagnosticar e recuperar-se de erros
10. Ajuda e documentação
Para avaliar a usabilidade e acessibilidade, aplicamos o questionário do HEUAno sistema web. Para agilizarmos o processo de avaliação de acessibilidade, utilizamos aferramenta de avaliação automática do governo brasileiro. Ainda que a avaliação por umavaliador humano ainda seja fundamental para verificar a qualidade de uso. O ASES3
permite avaliar, simular e corrigir em conformidade com as recomendações do Modelo deAcessibilidade em Governo Eletrônico (eMAG).
1 http://rspec.info, acesso em: 25/11/20182 http://batsov.com/rubocop/, acesso em: 25/11/20183 http://asesweb.governoeletronico.gov.br/ases/, acesso em: 25/11/2018
28
5 Processo de desenvolvimento do Solici-taUFF
O calendário escolar da Universidade Federal Fluminense é elaborado e aprovadoanualmente e contém os principais eventos do ano letivo da Universidade. No calendárioda UFF está previsto o chamado período de ajustes, no qual os alunos podem fazersolicitações à suas coordenações. Enumeramos algumas dessas solicitações e outras quepodem ser feitas em qualquer período.
1. Mudanças de turmas
2. Inscrição em disciplinas
3. Cancelamentos de inscrições em disciplinas
4. Aproveitamentos de disciplinas já cursadas na UFF
5. Declarações personalizadas
Levantamos os requisitos do sistema e seguimos de forma adaptada o processoPDWAU para que levássemos em conta questões de acessibilidade e usabilidade desde ocomeço do processo de desenvolvimento. As atividades desse processo são divididas daseguinte forma: Comunicação, Planejamento, Modelagem, Construção, Implantação.
As avaliações de usabilidade e acessibilidade realizadas durante o processo de de-senvolvimento estão descritas na atividade de Construção.
5.1 ComunicaçãoQueremos saber do usuário tudo e somente aquilo que tem a ver com o uso que ele
fará da tecnologia: sua propensão a aceitar ou rejeitar a tecnologia, as consequências que atecnologia pode trazer para a sua vida, e sua experiência objetiva e subjetiva ao interagircom a tecnologia. As ações da atividade de Comunicação são: Formulação, Elicitação eNegociação.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 29
5.1.1 Formulação
1. Identificamos os usuários:
∙ Alunos de graduação;
∙ Coordenadores de curso;
∙ Funcionários de coordenação.
2. Coletamos informações dos usuários identificados:
∙ Coordenadores de curso foram entrevistados.
∙ Alunos de diferentes cursos de graduação responderam a um questionário.
Com o objetivo de realizar o levantamento de requisitos e compreender as necessi-dades dos usuários, considerando requisitos de acessibilidade e usabilidade no desenvolvi-mento do sistema web, aplicamos entrevistas com coordenadores e questionários com osalunos.
Após a definição do objetivo das entrevistas, elaboramos um roteiro (ANEXO A) eum Termo de Consentimento Livre e Esclarecido (TCLE) (ANEXO A), o qual teve comobase o documento disponibilizado pelo Comitê de Ética em Pesquisa da Faculdade deMedicina da Universidade Federal Fluminense (CEP FM/UFF). Utilizamos também paraa coleta de informações, a gravação do áudio das entrevistas, o qual consta a autorizaçãopara gravá-la no termo previamente assinado pelos participantes.
Com os coordenadores, utilizamos entrevistas abertas presenciais, deste modo,adaptamos a ordem e teor das perguntas durante a entrevista com perguntas que deixamampla margem de resposta, sem induzir respostas.
Com os alunos, utilizamos o questionário online (ANEXO B) e um Termo de Con-sentimento Livre e Esclarecido (ANEXO B), para compreender problemas que ocorreramquando necessitaram fazer essas solicitações, além de levantar o perfil dos alunos de gra-duação, que foi utilizado para a elaboração da persona.
5.1.1.1 Informações coletadas
O questionário obteve 58 respostas de alunos de 21 cursos de graduação da UFF.Dentre os quais, podemos destacar: 22,4% de Sistemas de Informação, 15,5% de Engenha-ria de Telecomunicações e 10,3% de Ciência da Computação. Por meio das respostas, foipossível traçar o perfil médio dos alunos. Identificamos que 67,2% dos alunos se encontramabaixo dos 25 anos de idade e 31% entre 26 e 35 anos.
Percebemos que a incompatibilidade de horários com a coordenação está direta-mente ligada ao fato de 63,8% dos alunos estagiarem ou trabalharem e dentre esses, sua
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 30
maioria já cursaram mais de 5 períodos. Dos alunos que cursam noturno 84,2% trabalhamou estagiam. A incompatibilidade de horários foi o problema mais apontado pelos estu-dantes ao realizarem as solicitações presencialmente, com 73,2%, seguido de atendimentoburocrático com 53,6%.
Dentre os alunos consultados 98,3% utilizam aparelhos como smartphone diaria-mente, enquanto apenas 53,4% utilizam o computador diariamente. Esses dados corrobo-ram com a resposta de 79,3% dos alunos que consideram muito importante poder realizarsolicitações a sua coordenação através de uma plataforma digital.
Em sua maioria os alunos realizam de 1 a 2 solicitações por período, sendo as soli-citações de inscrição, cancelamento e troca de turmas as consideradas mais importantes,essas solicitações são específicas do período de ajuste do plano de estudos.
Esses dados foram sintetizados na criação da persona, nos cenários do aluno e nasfuncionalidades escolhidas para serem implementadas como pode ser visto na seção 5.3.
5.1.2 Elicitação
O sistema SolicitaUFF tem como objetivo facilitar e agilizar os processos onde osalunos interagem com a coordenação. Após a implantação que será realizada pela STI-UFF, os usuários poderão acessar o sistema através do Portal da UFF com as credenciaisjá utilizadas nos outros sistemas institucionais.
1. Área do coordenador e funcionário da coordenação: Possui a página inicial de cadatipo de solicitação, onde é possível visualizar as solicitações dos alunos e os detalhesda solicitação, onde o coordenador ou funcionário podem alterar o status de umasolicitação.
2. Área do aluno: Possui a página inicial de cada tipo de solicitação, onde é possívelcriar uma nova solicitação e visualizar o histórico de solicitações. Os detalhes dassolicitações, onde é possível acompanhar o andamento de uma solicitação ou cancelá-la desde que a solicitação ainda esteja como pendente. Além de uma parte ondeo aluno pode visualizar o seu plano de estudos, onde também é possível pedir ocancelamento ou mudança de turma para cada uma das inscrições.
5.1.2.1 Requisitos Funcionais
R01 O sistema deve permitir que os alunos solicitem inclusão de disciplinas no seu planode estudos desde que esteja dentro do período de ajuste da UFF.
R02 O sistema deve permitir que os alunos solicitem a alteração de turma do seu planode estudos desde que esteja dentro do período de ajuste da UFF.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 31
R03 O sistema deve permitir que os alunos solicitem o cancelamento de inscrição emturma desde que esteja dentro do período de ajuste da UFF.
R04 O sistema deve permitir que os alunos solicitem declarações personalizadas.
R05 O sistema deve permitir que os alunos solicitem aproveitamento de disciplinas jácursadas na UFF.
R06 O sistema deve armazenar a hora, o ip e o usuário do qual as ações forem executadas.
R07 O sistema deve permitir que os coordenadores e funcionários de coordenação possamalterar o status de uma solicitação, provendo o acompanhamento do andamento damesma.
R08 O sistema deve oferecer informação sobre o sistema a todos os usuários, tais como:versão do sistema, responsável pelo sistema, status e etc.
R09 O sistema deve exibir mensagens de erro que estejam em linguagem natural aosusuários para que sejam informados claramente sobre o resultado da ação realizada.
R10 O sistema deve permitir que o usuário possa visualizar as suas solicitações e o statusdas mesmas.
R11 O sistema deve ser integrado ao portal de autenticação de sistemas da UFF.
5.1.2.2 Requisitos não-funcionais
Usabilidade: De acordo com as 10 Heuristicas de Usabilidade de Nielsen (1990). Eutilizando o questionário HEUA que também atende requisitos de acessibilidade.
Acessibilidade: De acordo com Avaliador e Simulador de Acessibilidade em Sítios (ASES)do Governo Federal.
Confiabilidade: O sistema deve, em caso de falha, ter capacidade para recuperar osdados até a última operação que realizou.
Desempenho: O tempo de processamento de uma operação de consulta e o tempo deresposta para as operações de cadastro, alteração e exclusão de solicitações nãodevem exceder três segundos.
Manutenibilidade: O sistema deve ter mais de 80% de cobertura de testes e 100% decobertura do Rubocop1, como será explicado no Capítulo 5.
1 https://docs.rubocop.org, acesso em: 25/11/2018
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 32
5.1.3 Negociação
Para a realização deste projeto foi necessária uma colaboração entre os autorese a Superintendência de Tecnologia da Informação da Universidade Federal Fluminense(STI-UFF), a fim de poder integrar o sistema desenvolvido com o sistema de autenticaçãode usuários unificado da universidade e para realizar as diversas integrações com o bancode dados de alunos.
Como condições da negociação, foi definido que o código fonte produzido ficaráarmazenado no repositório interno da STI-UFF e que os padrões de projetos assim comoo Plano de Gerência de Configuração da STI-UFF deveriam ser seguidos.
Ao término, o projeto será avaliado pela STI-UFF para garantir que as condi-ções acordadas foram seguidas e, se necessário, ajustes serão realizados para garantir aaderência do sistema às necessidades e regras de negócio da Universidade.
5.2 PlanejamentoApós os requisitos básicos do sistema serem identificados na seção anterior, pode-
mos seguir para a atividade de planejamento. Nesse caso, adaptamos o ciclo incrementaldo processo PDWAU para uma abordagem mais ágil, planejamos através de “sprints” de15 dias, onde cada sprint possui tarefas designadas que deveriam iniciar e terminar juntocom o sprint. A dificuldade das tarefas foram estimadas através do “planning poker”2
utilizando como unidade de medida pontos de história, de modo que se chegasse em umconsenso para se encaixar dentro dos “sprints”.
Tabela 1 – Esforço por ponto de história
Pontos de história Esforço1 Trivial3 Baixo Esforço5 Médio Esforço8 Alto Esforço13 Praticamente impossível
2 https://en.wikipedia.org/wiki/Planning_poker, acesso em: 22/11/2018
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 33
Tabela 2 – Requisitos funcionais
Requisitos Pontos de históriaR01 05R02 05R03 05R04 03R05 05R06 03R07 08R08 01R09 03R10 03R11 03
5.3 ModelagemNesta atividade, optamos por criar personas e cenários de uso que descrevem como
são feitas as solicitações à coordenação.
5.3.1 Personas
Para compreender a perspectiva dos funcionários de coordenação e coordenadoresde cursos de graduação, optamos por realizar entrevistas individuais, a qual foi uma opçãoeficaz e qualitativa (BARBOSA; SILVA, 2010). No roteiro da entrevista, algumas ques-tões que possibilitaram compreender o processo, e com isso o que poderia ser melhoradoatravés de um sistema. Com os alunos utilizamos um questionário, que nos possibilitoucompreender os pontos relevantes para os alunos. Alunos de diversos cursos, responderame com isso vimos que há problemas relevantes e em comum, o qual o SolicitaUFF poderiaresolver de maneira segura, eficaz e eficiente. Para cada ator do processo, criamos umapersona para nos auxiliar no desenvolvimento do sistema.
1. Persona criada para o perfil funcionário da coordenação de graduação:
Samuel Almeida, 31 anos, técnico administrativo, há 2 anos na coordenação de cursode graduação.
Objetivos: Homologar as solicitações dos alunos de forma eficiente.
Desafios: Acha trabalhoso gerenciar os formulários em papel e além disso, achamuito burocrático homologar todas as solicitações.
Como o SolicitaUFF pode ajudá-lo: Poupando seu tempo ao disponibilizar for-mulários aos alunos. Proporcionando uma interface eficiente para seu uso cons-tante.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 34
2. Persona criada para o perfil coordenadora do curso de graduação:
Márcia Carvalho, 43 anos, coordenadora de curso de graduação há 5 anos.
Objetivos: Utilizar um sistema simples e que ajudará os funcionários da coorde-nação a ter controle dos pedidos feitos pelos alunos do curso de graduação.
Desafios: Acha burocrático realizar tarefas manualmente.
Como o SolicitaUFF pode ajudá-la: Provendo uma estrutura robusta, dimi-nuindo possíveis erros de processamento durante seu uso, diminuindo a quan-tidade de papel.
3. Persona criada para o perfil de aluno de curso de graduação:
Roberta Ferreira, 23 anos, aluna de curso de graduação há 5 períodos.
Objetivos: Solicitar inclusão, alteração e exclusão de turma durante o período deajustes. Além de solicitar declarações personalizadas e solicitar o aproveita-mento de disciplinas já cursadas na universidade.
Desafios: Conciliar seu horário com o horário da coordenação e acha burocráticorealizar essas tarefas, pois necessita preencher diversos papéis.
Como o SolicitaUFF pode ajudá-la: Removendo as restrições de horários paraa realização dos pedidos e reduzindo a burocracia, assim, economizando tempoe dinheiro.
5.3.2 Cenários
De acordo com o resultado do questionário e entrevistas, diversos cenários de pro-blema puderam ser criados para avaliar melhor as situações. A persona Roberta Ferreira,necessitou de diversas solicitações durante todo o período que cursou na universidade.
Para solicitações feitas presencialmente, temos:
1. Cenário: Alteração no plano de estudos
Na primeira semana de aula, Roberta, estudante de Graduação da Universidade Fe-deral Fluminense, deseja realizar uma alteração no seu Plano de Estudos. Para isso,ela necessita comparecer a coordenação de seu curso durante o horário estabelecidopor esta, e solicitar a mudança. Roberta faz estágio no Rio de Janeiro até as 17he tem que correr para chegar na coordenação antes do seu horário de fechamento,18h. Devido a possíveis complicações, como congestionamento, nem sempre ela con-segue chegar a tempo. Além disso, se ela precisar fazer outra alteração, ela precisacomparecer novamente à coordenação.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 35
2. Cenário: Aproveitamento de disciplinas
No final de seu curso, Roberta, estudante da Universidade Federal Fluminense,deseja aproveitar algumas disciplinas já cursadas na UFF. Para isso, ela necessitapreencher um formulário e entregar na coordenação do seu curso, no horário defuncionamento. Essa solicitação precisa ser aprovada para, só depois constar em seuHistórico. Depois de realizar o pedido até a aprovação, ou não, Roberta não sabe asituação de seu pedido. Além disso, ela terá que preencher um formulário para cadadisciplina que desejar aproveitar.
Também levantado pelo questionário e entrevista, identificamos que algumas coordenaçõesfazem uso de ferramentas de apoio informatizadas, como formulários online e e-mail,portanto elaboramos dois cenários para contemplar esses casos.
1. Cenário: Alteração no plano de estudos
Em determinado período de seu curso, sua coordenação decidiu utilizar GoogleFormspara facilitar as solicitações de alteração de plano de estudo. É disponibilizado nosite do seu curso um link para um formulário o qual Roberta pode solicitar o cance-lamento da disciplina que deseja. Ao acessar o link, Roberta se sente insegura, poiso formulário sugerido é um recurso não-oficial da universidade, mas como Robertanão poderia comparecer à coordenação, ela acaba preenchendo o formulário parasolicitar a alteração.
2. Cenário: Solicitar declaração personalizada
Roberta necessita solicitar declarações personalizadas, para um intercâmbio. Nossistemas da universidade, não há como fazer essa solicitação, ou pode ser feita pre-sencialmente ou por e-mail que é o que sua coordenação sugere. Portando Robertanecessita solicitar por e-mail essa declaração. Roberta se sente insegura com isso,pois terá que passar os seus dados pessoais e matricula por e-mail para que a suasolicitação seja atendida.
5.3.3 Cenários evidenciando a importância da acessibilidade
Nesses cenários, as limitações físicas dos usuários dificultaram ou impossibilitaramo acesso aos sistemas da universidade. A interação tornou-se pouco produtiva ou impos-sível devido as dificuldades para agir sobre o sistema através dos dispositivos de entrada,e para perceber e interpretar os resultados emitidos pelos dispositivos de saída. Abaixo,a persona Ana Júlia é deficiente visual e nos cenários 1 e 2 abordamos problemas que elaenfrenta.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 36
1. Persona: Ana Júlia é uma jovem de 20 anos estudante de curso de graduação daUFF e deficiente visual.
Objetivos: Solicitar inclusão de turma durante o período de ajustes.
Desafios: Interagir com sistemas web não acessíveis e preencher formulários empapel.
Como o SolicitaUFF pode ajudá-la: Conseguir navegar sem grandes barreiras(acessibilidade) pelo sistema web e obter as informações desejadas, tende aaumentar a sua motivação e satisfação (usabilidade), porque ela se torna ca-paz de realizar as solicitações sozinha, o sistema tornou-se fácil de aprender eutilizá-lo.
1. Cenário: Solicitar inscrição em disciplina presencialmente.
Ana Júlia está interessada em cursar uma disciplina, na qual não está inscrita parao semestre. Ela deve solicitar no período de ajuste da UFF a disciplina que desejacursar, para tanto, Ana Júlia necessita comparecer na coordenação de seu curso epreencher papéis referente a sua solicitação. Ela portanto necessitou que o funcio-nário da coordenação preenchesse os papéis para ela.
2. Cenário: Solicitar inscrição em disciplina por sistema próprio da coordenação.
No semestre seguinte a sua coordenação dispõe de um sistema próprio para solici-tações. Ela então consegue acessar esse sistema web utilizando um leitor de telas.No sistema web ela descobriu que precisava se cadastrar através do número da ma-tricula. Após o cadastro, Ana Júlia consegue acessar o sistema, mas não conseguiuencontrar um link para solicitar a inscrição em disciplina, e nem percebeu que operíodo de ajustes havia terminado. A informação de que o período de ajustes haviaterminado se encontrava dentro de uma figura e essa informação não pôde ser lidapelo leitor de tela, portanto, ela não teve acesso a essa informação.
5.4 ConstruçãoNas seções seguintes, falaremos sobre as soluções tecnológicas utilizadas no desen-
volvimento do SolicitaUFF. Utilizamos os padrões arquiteturais indicados pela STI -UFF,ou seja, as definições de qual linguagem e framework utilizar, bancos de dados, padrõesde testes e qualidade de código além das regras de versionamento.
5.4.1 Linguagem e Framework
Na implementação optamos por utilizar a linguagem de programação Ruby emsua versão 2.5.1, assim como o framework web Ruby on Rails na versão 5.2. A escolha
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 37
dessas tecnologias foi influenciada pela facilidade de abstração do código de baixo nível,permitindo maior foco nas regras de negócio e conceitos de usabilidade e acessibilidadeque deveriam ser implementados, assim como por serem tecnologias presentes no dia adia da STI-UFF.
5.4.2 Bancos de Dados
Como solução de armazenamento de dados foi obrigatório a utilização de doisbancos de dados relacionais distintos, sendo um deles para a integração do sistema com obanco já existente de alunos e o outro para dados pertinentes apenas ao sistema desenvol-vido, por exemplo as diversas solicitações realizadas pelos alunos. Foi utilizado tambémum banco de dados de chave-valor para realizar o cacheamento das permissões dos usuá-rios no sistema, tarefa muito onerosa para ser realizada pelos bancos relacionais a cadarequisição web.
5.4.3 Versionamento
Utilizamos Git como sistema de controle de versões, através de ferramenta emterminal e o GitLab como ferramenta para administrar o repositório remoto, em conjuntotambém utilizamos o versionamento semântico3 do código, no formato X.Y.Z, onde X, Ye Z são números e são incrementados de acordo com o tipo de modificação que é realizadano projeto.
5.4.4 Codificação
Nas seções seguintes, descrevemos como podemos manter a confiabilidade, desem-penho, e manutenibilidade do código que são requisitos não-funcionais do SolicitaUFF.
5.4.4.1 Qualidade de código
A fim de manter o estilo de código padronizado em todo o projeto e também comos demais projetos da STI-UFF, utilizamos a ferramenta Rubocop4 que analisa o códigoe o avalia de acordo com regras predefinidas de estilo e boas práticas, ao final da análiseum relatório é gerado indicando quantos problemas foram encontrados, onde estão e dequal natureza eles são.3 https://semver.org, acesso em: 25/11/20184 https://docs.rubocop.org, acesso em: 25/11/2018
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 38
5.4.4.2 Testes unitários e de integração
Para garantir a manutenibilidade e a qualidade do código, foram feitos testes uni-tários e de integração através das ferramentas RSpec5 e Capybara6. Com elas foi possíveltestar as regras de negócio implementadas e a corretude da implementação, além do re-torno que a aplicação daria aos usuários. Também foi utilizada a ferramenta SimpleCov7
que em conjunto com a RSpec é capaz de identificar as linhas de código que foram exe-cutadas durante o teste, gerando assim um relatório indicativo de cobertura do código.
5.4.5 Método de avaliação ACCESSA
O método de avaliação ACCESSA é apresentado sob quatro perspectivas: pers-pectiva de inspeção, perspectiva de ferramenta, perspectiva de usuário e perspectiva deespecialista (P1, P2, P3 e P4), baseado na avaliação experimental do PDWAU.
Na perspectiva de inspeção é necessário verificar a conformidade realizada por umespecialista8 do sistema com os princípios do WCAG 2.0, que são: perceptível, operável,compreensível e robusto.
Na perspectiva de ferramentas é dada por avaliar a acessibilidade de sistemas webcom ferramentas de avaliação automática. Para tanto, optamos por utilizar o ASES.
Na perspectiva do usuário são aplicados testes com usuário, a avaliação é feitaponto de vista do usuário durante a sua interação com o sistema.
Na perspectiva do especialista, é feita uma análise da interação que o usuáriodesempenhou no acesso ao sistema web. “Para que isso seja viável, é necessário que ainteração do usuário seja gravada e documentada.” (DIAS, 2014).
5.4.5.1 Avaliação de conformidade com as diretrizes do WCAG 2.0
Na realização da avaliação sob o ponto de vista de inspeção, foram avaliados aconformidade com as diretrizes do WCAG 2.0. Nessa perspectiva, o especialista seguiu oscritérios de sucesso de cada diretriz, atribuindo uma nota de 0 a 10, conforme apresentadona Tabela 3.
Com a avaliação realizada pelo especialista, pôde-se observar que o sistema So-licitaUFF satisfaz os critérios de sucesso de acessibilidade. Após aplicar a inspeção nosistema, o próximo passo é passá-lo por uma avaliação de ferramenta online, que seráexplicada na próxima subseção.5 http://rspec.info/, acesso em: 25/11/20186 http://teamcapybara.github.io/capybara, acesso em: 25/11/20187 https://github.com/colszowka/simplecov, acesso em: 25/11/20188 Um de nós assumiu o papel de especialista9 O SolicitaUFF não contém elementos em áudio/video.
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 39
Tabela 3 – Resultados da perspectiva de inspeção
Princípios Diretrizes SucessoPerceptível 1.1 (Alternativas em Texto) 10
1.2 (Mídia Dinâmica ou Contínua)9 01.3 (Adaptável) 101.4 (Distinguível) 10
Operável 2.1 (Acessível por Teclado) 102.2 (Tempo Suficiente) 102.3 (Convulsões) 102.4 (Navegável) 10
Compreensível 3.1 (Legível) 103.2 (Previsível) 103.3 (Assistência na Inserção de Dados) 10
Robusto 4.1 (Compatível) 10
5.4.5.2 Ferramenta automática ASES
Na realização da avaliação sob o ponto de vista de ferramenta, durante o processode desenvolvimento, o ASES teve papel importante para ajudar a validar a acessibilidadedo sistema. Através do envio do código-fonte da página, a ferramenta é capaz de apontarerros e avisos relacionados as regras do eMAG.
Existem páginas reservadas para cada grupo de usuário assim como páginas cujoconteúdo é alterado de acordo com o grupo no qual o usuário se encontra, portanto,algumas páginas foram testadas tanto na visão da coordenação quanto na visão dos alunos.
Tabela 4 – Resultados do ASES nas visão da coordenação
Página Porcentagem Erros AvisosPágina Inicial 100 0 6/ajuste/inscricao_disciplinas 100 0 7/ajuste/inscricao_disciplinas/edit 100 0 9/ajuste/cancelamento_inscricoes 100 0 7/ajuste/cancelamento_inscricoes/edit 100 0 9/ajuste/mudanca_turmas 100 0 7/ajuste/mudanca_turmas/edit 100 0 9/aproveitamentos_disciplina/ 100 0 7/aproveitamentos_disciplina/edit 100 0 9/declaracoes_personalizadas/ 100 0 7/declaracoes_personalizadas/edit 100 0 10
Através da análise dos resultados, podemos apontar que os avisos listados nãoafetam a usabilidade e a acessibilidade do sistema, sendo apenas alguns falsos positivoscomo por exemplo o uso de tabelas em dados não tabulares, mesmo que tenham sidoutilizadas apenas em dados tabulares. Também observamos uma repetição na quantidade
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 40
Tabela 5 – Resultados do ASES na visão dos alunos
Página Porcentagem Erros AvisosPágina Inicial 100 0 6/ajuste/planos_estudos 100 0 7/ajuste/inscricao_disciplinas 100 0 7/ajuste/inscricao_disciplinas/new 100 0 14/ajuste/inscricao_disciplinas/show 100 0 6/ajuste/cancelamento_inscricoes 100 0 7/ajuste/cancelamento_inscricoes/new 100 0 9/ajuste/cancelamento_inscricoes/show 100 0 6/ajuste/mudanca_turmas 100 0 7/ajuste/mudanca_turmas/new 100 0 12/ajuste/mudanca_turmas/show 100 0 6/ajuste/aproveitamentos_disciplina/ 100 0 7/ajuste/aproveitamentos_disciplina/new 100 0 13/ajuste/aproveitamentos_disciplina/show 100 0 6/ajuste/declaracoes_personalizadas/ 100 0 7/ajuste/declaracoes_personalizadas/new 100 0 9/ajuste/declaracoes_personalizadas/show 100 0 7
e nos tipos de avisos, isso de dá pela reutilização de elementos entre as páginas, tendocomo exemplo a barra de navegação ou as tabelas já citadas.
5.4.6 Métrica HEUA
A métrica MHEUA assim como o método ACCESSA, podem ser utilizados em sis-temas web, independentemente do processo PDWAU. Essas técnicas avaliam a usabilidadee acessibilidade, além de indicarem possíveis melhorias. (DIAS, 2014).
Aplicou-se o HEUA para o sistema SolicitaUFF, para isso, utilizou-se o questio-nário HEUA, onde, é necessário que um especialista10 siga alguns passos: verifique todosos requisitos contidos nas dez questões (Q) de HEUA, decidindo se o sistema atende,não atende ou se não se aplica; aplicar a fórmula Qt para todas as questões; encontrarMHEUA; e observar os resultados.
Seguindo o proposto no PWDAU, após aplicar o HEUA, um conjunto de medidasdeve ser calculado para obter um resultado quantitativo. Esse resultado vai indicar oquanto de requisitos de usabilidade e acessibilidade é contemplado pelo sistema web.
𝑄𝑡 = 𝐴 − 𝑁𝑆
𝑅𝐸𝑄 − 𝑁𝐴* 100 (5.1)
10 No nosso caso, um de nós adquiriu o papel de especialista para aplicar o HEUA
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 41
𝑀𝐻𝐸𝑈𝐴 =∑︀10
𝑖=1 𝑄𝑡
10 (5.2)
Onde:
∙ Qt são as questões (t variando de 1 a 10); e
∙ S é o total de requisitos que o sistema “atende”;
∙ NS é o total de requisitos que o sistema “não satisfaz”;
∙ NA é o total de requisitos que “não se aplica” ao sistema;
∙ REQ é a quantidade de requisitos existentes para cada questão a ser respondida(requerimentos);
∙ MHEUA é o resultado final.
Tabela 6 – Qt e MHEUA do SolicitaUFF
Questões Requisitos Atende Não Satisfaz Não se aplica QtQ1 10 2 1 7 67Q2 8 4 1 3 80Q3 13 6 1 6 86Q4 11 7 0 4 100Q5 19 10 4 5 71Q6 6 6 0 0 100Q7 14 6 4 4 60Q8 5 4 1 0 80Q9 3 3 0 0 100Q10 4 1 1 2 50
MHEUA 79,4
“O resultado obtido em MHEUA pode variar de -100 a +100, e, gra-dualmente, apresenta valores que correspondem a diferentes níveis deadequação em termos de acessibilidade e usabilidade. Assim, quando osvalores positivos aumentam, significa que um sistema tem um melhornível de acessibilidade e usabilidade. Por outro lado, quando os valoresnegativos diminuem, isso pode indicar que os requisitos de acessibilidadee usabilidade não foram bem empregados no sistema web sob avalia-ção. Portanto, um sistema web com um valor maior de MHEUA é maisacessível e usável, em comparação com outro com um valor menor deMHEUA.” (DIAS, 2014).
Capítulo 5. Processo de desenvolvimento do SolicitaUFF 42
5.5 ImplantaçãoA implantação ficará a cargo da STI-UFF, em seu ambiente, porém alguns cui-
dados tiveram que ser tomados no desenvolvimento para que a implantação ocorresse deforma padronizada, dentre eles: A configuração de um arquivo de compilação de imagensDocker11, do NGINX12 como servidor web e garantir que as requisições não dependam deestado (arquitetura “stateless”).
11 https://www.docker.com, acesso em: 25/11/201812 https://www.nginx.com, acesso em: 25/11/2018
43
6 SolicitaUFF
Neste capítulo a versão final do SolicitaUFF para este trabalho será exposta pormeio de suas funcionalidades. O sistema disponibiliza diferentes funcionalidades de acordocom o grupo do usuário que está realizando o acesso.
6.1 FuncionalidadesNa visão do aluno, durante o período de ajuste é possível realizar as solicitações
de inscrição em disciplinas, cancelamento de inscrição e mudança de turma. A qualquermomento pode-se solicitar o aproveitamento de disciplinas já cursadas na UFF, declara-ções personalizadas e visualizar recados da coordenação, assim como visualizar as listasdas solicitações já realizadas e o detalhamento de cada solicitação.
Para os usuários das coordenações, é possível listar as solicitações realizadas pelosalunos do curso, visualizar o detalhamento de cada solicitação e alterar o status da soli-citação, garantindo que ela não poderá mais ser cancelada ao sair do status de pendentee provendo acompanhamento para o aluno do andamento da sua solicitação. Dentre osstatus possíveis temos: pendente, executando, deferido e indeferido.
As telas das funcionalidades de solicitação de inscrição em disciplina, cancelamentode inscrição, mudança de turma, declaração personalizada e aproveitamento de disciplinaencontram-se expostas na visão do aluno do ANEXO D.1 ao D.4, enquanto a visão dacoordenação pode ser observada no ANEXO D.5. Optamos por não exemplificar todas astelas da coordenação pois as outras funcionalidades omitidas da coordenação podem serextrapoladas a partir das telas já exemplificadas na visão do aluno.
O SolicitaUFF foi desenvolvido utilizando técnicas de layout responsivo, ou seja, oconteúdo da página se adéqua ao tamanho da tela, para garantir a interação eficiente emdispositivos móveis e desktop. Com isso, conseguimos eliminar a necessidade de um apli-cativo distinto para cada plataforma de sistemas operacionais dos diferentes dispositivosmóveis, como mostrado no ANEXO D.6.
6.2 Cenários de InteraçãoOs cenários de interação buscam mostrar como o sistema ajuda a resolver os pro-
blemas apontados pelos cenários de problemas do Capítulo 5. No cenário 1 a personaRoberta interage com o SolicitaUFF, já no cenário 2 abordamos a interação de pessoascom deficiência visual, no caso, a persona Ana Júlia interage com o SolicitaUFF.
Capítulo 6. SolicitaUFF 44
Cenário 1: Alterar plano de estudos
Na primeira semana de aula, Roberta, estudante de Graduação, deseja realizaruma alteração no seu Plano de Estudos. Ela acessa o SolicitaUFF e percebe que o menude Período de Ajuste está liberado para acesso, em seguida ela clica em Plano de Estudospara conferir as disciplinas que está inscrita.
Figura 1 – Tela do plano de estudos
Capítulo 6. SolicitaUFF 45
Roberta, após visualizar o seu plano, decide inscrever-se em uma nova disciplinaatravés do botão solicitar inscrição. Ela preenche o formulário na nova página digitando onome da disciplina que deseja cursar e selecionando a opção correta dentre as retornadaspela busca, em seguida ela seleciona a turma escolhida.
Figura 2 – Tela de inscrição em disciplinas
Após a solicitação, Roberta verifica os dados que o sistema retornou como cadas-trados.
Figura 3 – Detalhes da inscrição realizada
Capítulo 6. SolicitaUFF 46
Cenário 2: Solicitar inscrição em disciplina pelo SolicitaUFF.
Após inspecionar seu plano de estudos, Ana Júlia resolve realizar uma solicitaçãode inscrição em disciplina.
Figura 4 – Tela do plano de estudos com o link para nova inscrição selecionado
Após realizar a busca pela disciplina e selecionar a turma, Ana Júlia confirma asua solicitação de inscrição.
Figura 5 – Tela de nova solicitação de inscrição em disciplina com dados preenchidos ebotão de confirmação selecionado
Capítulo 6. SolicitaUFF 47
Após a confirmação, a primeira mensagem que Ana Júlia recebe do sistema, é ainformação de que sua solicitação foi de fato realizada.
Figura 6 – Tela de detalhes da solicitação de inscrição em disciplina com alerta selecionado
48
7 Considerações Finais
Neste trabalho buscou-se desenvolver um sistema acadêmico-administrativo cujoobjetivo foi agilizar e informatizar as atividades realizadas pelos alunos e coordenações daUniversidade Federal Fluminense. Para atingir nosso objetivo, buscamos aplicar uma me-todologia focada no desenvolvimento de sistemas seguindo as diretrizes de acessibilidadee as heurísticas de usabilidade.
Para guiar o desenvolvimento do SolicitaUFF tivemos como metas permitir que osusuários de leitores de tela tenham acesso à toda a informação disponível no sistema e livrenavegação entre as funcionalidades, além de permitir que o sistema adéque-se às diversasconfigurações de tamanho de fonte dos usuários. Para as metas de usabilidade, todousuário deve ser capaz de encontrar as informações no sistema, de entender as informaçõesno sistema e o sistema deve prover retorno claro e preciso para o usuário após umaação ser efetuada. Dito isso, concluímos que as metas foram alcançadas com sucesso peloSolicitaUFF.
Através da metodologia escolhida, pudemos aprofundar nosso conhecimento dausabilidade e acessibilidade, pois aplicamos os conceitos desde o início do desenvolvimentodo sistema. Aprendemos a incluir personas e cenários no processo de desenvolvimento paracompreender a necessidade dos usuários e a incluir avaliações automatizadas e objetivaspara validar nossos resultados em conformidade com a WCAG 2.0 1 e eMAG2.
As limitações desse trabalho estão no fato de não termos conseguido aplicar ométodo ACCESSA3 em sua totalidade. A perspectiva do usuário e os testes com os usuá-rios finais não puderam ser feitas, assim como a perspectiva do especialista, não pôdeser aplicada, pois depende diretamente das perspectivas anteriores. Esta falta porém, foicompensada, em parte, com a aplicação do questionário HEUA4, pois este avalia objeti-vamente a usabilidade e a acessibilidade.
Como trabalhos futuros pode-se realizar testes com usuários para contribuir com oaprimoramento do sistema, além de ampliar o sistema para abranger outras necessidadesdas coordenações e alunos que sejam referentes às solicitações. Também seria interessanteexplorar os processos realizados entre coordenações que por vezes foram relatados duranteas entrevistas e que também são necessários para atender as necessidades dos alunos.
1 Web Content Accessibility Guidelines2 Modelo de Acessibilidade em Governo Eletrônico3 Approach to improve the aCCESsibility and uSAbility of existing web system4 A heuristic evaluation with Usability and Accessibility requirements to assess web systems
49
Referências
BARBOSA, S. D. J.; SILVA, B. S. da. INTERAÇÃO HUMANO-COMPUTADOR. [S.l.]:Elsevier Editora Ltda., 2010. 243-256 p. Citado 5 vezes nas páginas 12, 13, 15, 19 e 33.
BORGES, B. A. da S. Estudo de usabilidade e redesign de interface do sistema solicitasi.p. 3–5, 2016. Citado 2 vezes nas páginas 23 e 24.
CARROLL, J.; ROSSON, M. B. Human-computer interaction scenarios as a designrepresentation. [S.l.: s.n.], 1990. 555 - 561 vol.2 p. Citado na página 13.
DIAS, A.; FORTES, R.; MASIERO, P. Heua: A heuristic evaluation with usabilityand accessibility requirements to assess web systems. W4A 2014 - 11th Web for AllConference, 04 2014. Citado 3 vezes nas páginas 21, 22 e 23.
DIAS, A. et al. An approach to improve the accessibility and usability of existing websystem. p. 39–48, 09 2013. Citado 3 vezes nas páginas 21, 22 e 23.
DIAS, A. L. Um processo para sistemas web com foco em acessibilidade e usabilidade.2014. Citado 4 vezes nas páginas 20, 38, 40 e 41.
HEERDT, M. L.; LEONEL, V. Metodologia Científica e da Pesquisa. 5. ed. [S.l.]:UnisulVirtual, 2007. ISBN 9788578170295. Citado na página 24.
LÓPEZ, J. M. et al. Methodology for identifying and solving accessibility relatedissues in web content management system environments. ACM, New York, NY, USA,p. 32:1–32:8, 2012. Disponível em: <http://doi.acm.org/10.1145/2207016.2207043>.Citado na página 21.
MELO, A. M. Acessibilidade e inclusÃo digital. In: Companion Proceedings of the 13thBrazilian Symposium on Human Factors in Computing Systems. Porto Alegre, Brazil,Brazil: Sociedade Brasileira de Computação, 2014. (IHC ’14), p. 73–74.Disponível em: <http://dl.acm.org/citation.cfm?id=2738165.2738196>. Citado napágina 12.
MELO, M. D. P. e Francisco Ricardo Lins Vieira de. Estrutura e funcionamento dosnúcleos de acessibilidade e inclusão nas universidades federais da região sudeste. RevistaIbero-Americana de Estudos em Educação, v. 12, n. 3, p. 1610–1627, 2017. ISSN 1982-5587.Disponível em: <https://periodicos.fclar.unesp.br/iberoamericana/article/view/10354>.Citado 2 vezes nas páginas 12 e 14.
NARASIMHAN, N. e-Accessibility Policy Handbook for Persons with Disabilities.Elsevier Editora Ltda., 2010. 5-6 p. Disponível em: <http://www.e-accessibilitytoolkit-.org/toolkit/eaccessibility basics>. Acesso em: 23.5.2018. Citado 2 vezes nas páginas 15e 26.
NIELSEN, J. 10 usability heuristics for user interface design. 1995. Disponível em:<https://www.nngroup.com/articles/ten-usability-heuristics/>. Citado na página 27.
Referências 50
NIELSEN, J. Usability 101: Introduction to usability. 2012. Disponível em: <https:/-/www.nngroup.com/articles/usability-101-introduction-to-usability/>. Citado 3 vezesnas páginas 18, 19 e 26.
OLIVEIRA, C. B. de. Jovens deficientes na universidade: experiências de acessibilidade?Revista Brasileira de Educação, 2018. Disponível em: <http://uaeh.redalyc.org/articulo-.oa?id=27529319009>. Citado na página 14.
WEBAIM. 2017. Disponível em: <https://webaim.org/projects/screenreadersurvey7/>.Citado na página 13.
Anexos
52
ANEXO A – Entrevistas
A.1 TCLE - Termo de Consentimento Livre e EsclarecidoTítulo do Projeto: Portal do Aluno; Responsáveis: Gabriel Guadalupe Rodriguez
e Marcela Corrêa Santos Ramos, Graduandos em Sistemas de Informação - UFF; Ori-entadora: Professora Luciana Cardoso de Castro Salgado; Instituição a que pertence osResponsáveis: Universidade Federal Fluminense; Contato: Gabriel e Marcela
O(A) Sr.(a) está sendo convidado(a) a participar do projeto de pesquisa “Portaldo Aluno”, de responsabilidade dos Graduandos Gabriel Guadalupe Rodríguez e MarcelaCorrêa Santos Ramos. Esta entrevista tem como objetivo o levantamento de dados sobreos processos acadêmico-administrativos realizados pelas coordenações e alunos da Uni-versidade Federal Fluminense, a fim de identificar possíveis gargalos ou necessidades quepossam ser solucionadas pelo projeto de pesquisa. A entrevista ocorrerá nas dependênciasda Universidade Federal Fluminense, em um horário previamente definido. O áudio daentrevista será gravado para uma análise posterior dos dados coletados. A sua participa-ção nesta entrevista é voluntária (você não terá nenhum benefício financeiro), podendorecusar-se a participar ou retirar seu consentimento, em qualquer fase da entrevista, sempenalização alguma. Sua recusa não trará nenhum prejuízo em sua relação com os pes-quisadores, Instituição ou qualquer outra penalização. Os dados coletados na entrevistaserão confidenciais.
Este termo teve como base o documento disponibilizado pelo Comitê de Ética emPesquisa (CEPs) da Faculdade de Medicina da Universidade Federal Fluminense (CEPFM/UFF). E-mail: [email protected]
Eu, __________________________________, declaro ter sido in-formado e concordo em participar, como voluntário, do projeto de pesquisa acima descrito.
Niterói, ___ de ____________ de ______.
__________________________________
(assinatura do participante ou responsável legal)
(assinatura do responsável por obter o consentimento)
(assinatura do responsável por obter o consentimento)
ANEXO A. Entrevistas 53
A.2 Roteiro das entrevistasPerguntas centrais da entrevista semi-estruturada com coordenadores de curso
para levantamento de requisitos:
1. Como é o processo atual? Quem são os atores? Entradas? Saídas?
2. Ele pode ser automatizado?
3. Como ele seria automatizado?
4. Limitações? Regras?
5. Período de ajustes:
Processo de mudança de turma
Processo de inscrição em turma
Processo de cancelamento de inscrição em turma
6. Qualquer período:
Processo de pedido de declaração personalizada
Processo de pedido de inclusão de Atividade Complementar (Formulário padrão?)
Processo de pedido de aproveitamento de disciplina (equivalência, eletiva, optativa,AC)
7. Alunos com deficiência?
54
ANEXO B – Questionário
B.1 TCLE - Termo de Consentimento Livre e EsclarecidoPesquisa sobre solicitações dos alunos de graduação para a coordenação
Termo de Consentimento Livre e Esclarecido: Você está sendo convidado (a) paraparticipar, como voluntário, da pesquisa sobre solicitações de alunos para a coordenação.Após ser esclarecido (a) sobre as informações a seguir, no caso aceite fazer parte do estudo,concorde com os termos. Em caso de recusa você não sofrerá nenhuma penalidade.
Declaro ser esclarecido sobre os seguintes pontos:
1. Você está sendo convidado para participar, como voluntário, da pesquisa sobresolicitações de alunos para a coordenação.
2. Esta pesquisa tem por finalidade entender quais são os processos mais relevantesque envolvem os alunos e a coordenação e quais poderiam ser informatizados.
3. A minha participação nesta pesquisa consistirá em responder as perguntas deforma objetiva e de acordo com a minha realidade.
4. Ao participar desta pesquisa estarei contribuindo com o desenvolvimento de umtrabalho de conclusão de curso e com um possível desenvolvimento de um sistema desolicitações acadêmicas.
5. A minha participação nesta pesquisa deverá ter duração de tempo estimadoentre 5 minutos e 10 minutos.
6. Não terei nenhuma despesa ao participar da pesquisa e poderei deixar de par-ticipar ou retirar meu consentimento a qualquer momento, sem precisar justificar, e nãosofrerei qualquer prejuízo.
7. Fui informado e estou ciente de que não há nenhum valor econômico, a receberou a pagar, por minha participação.
8. Minhas informações serão mantidas em sigilo, assegurando a minha privacidade.
9. Fui informado que os dados coletados serão utilizados, única e exclusivamente,para fins desta pesquisa, e que os resultados poderão ser publicados.
10. Ao clicar no botão aceito você concorda com as informações aqui descritas,porém a qualquer momento você pode interromper a pesquisa sem ônus algum.
ANEXO B. Questionário 55
Para prosseguir com a pesquisa, por favor, concorde com os Termos.
( ) Concordo
( ) Não concordo
B.2 Perguntas do questionário* Requirido
1. Qual a sua faixa etária? *
( ) Entre 16 e 25 anos
( ) Entre 26 e 35 anos
( ) Entre 36 e 45 anos
( ) Mais que 45 anos
2. Qual turno você estuda? *
( ) Integral
( ) Noturno
( ) Diurno
3. Em qual curso você está matriculado(a)? *
(Opção contendo todos os cursos da UFF)
4. Quantos períodos você já cursou? *
( ) Entre 0 a 2 períodos
( ) Entre 3 a 5 períodos
( ) Entre 5 e 8 períodos
( ) Entre 9 e 10 períodos
( ) Mais de 10 períodos
5. Trabalha ou Estagia? *
( ) Sim
( ) Não
ANEXO B. Questionário 56
6. Com que frequência você utiliza aparelhos como o smartphone? *
( ) Nunca
( ) Uma vez por semana
( ) Duas a três vezes por semana
( ) Quatro a cinco vezes por semana
( ) Cinco a seis vezes por semana
( ) Todos os dias
7. Com que frequência você utiliza o computador? *
( ) Nunca
( ) Uma vez por semana
( ) Duas a três vezes por semana
( ) Quatro a cinco vezes por semana
( ) Cinco a seis vezes por semana
( ) Todos os dias
8. Com que frequência você realiza solicitações à coordenação de seu curso? *
( ) Nunca
( ) Uma vez por período
( ) Duas vezes por período
( ) Três vezes por período
( ) Mais de três vezes por período
9. Dentre os problemas abaixo, quais já ocorreram com você ao realizar solicitações àcoordenação de seu curso presencialmente?
( ) Atendimento burocrático
( ) Demora para concluir as solicitações
( ) Incompatibilidade de horários com a coordenação
( ) Lentidão no atendimento
( ) Enfrentou filas
( ) Outro:
ANEXO B. Questionário 57
10. Dentre os problemas abaixo, quais já ocorreram com você ao realizar solicitações àcoordenação de seu curso quando realizado por sistema?
( ) Instabilidade no sistema
( ) Lentidão do sistema
( ) Dificuldade de utilizar o sistema
( ) Insegurança ao utilizar o sistema
( ) Falta de familiaridade com o sistema
( ) Não conseguiu resolver o problema pelo sistema
( ) Outro:
11. Na sua opinião, qual a importância de poder realizar as solicitações através de umaPlataforma Digital?*
Nenhuma Importância ( ) 1 . ( ) 2 . ( ) 3 . ( ) 4 . ( ) 5 Muito Importante
12. Através de qual tipo de plataforma você gostaria de poder realizar as solicitações?*
( ) Navegador web (GoogleChrome, MozillaFirefox, InternetExplorer, entre outros)
( ) Aplicativo
( ) Ambas
( ) Nenhuma, prefiro realizar pessoalmente na própria coordenação
ANEXO B. Questionário 58
13. Classifique a importância das seguintes funcionalidades em um sistema de solicita-ções à coordenação *
Tabela 7 – Questão 13 do questionário com alunos
NenhumaImpor-tância
PoucoImpor-tante
Indiferente Importante MuitoImpor-tante
Trancamento de matrícula ( ) ( ) ( ) ( ) ( )Inscrição em disciplina ( ) ( ) ( ) ( ) ( )Cancelamento de disci-plina
( ) ( ) ( ) ( ) ( )
Troca de turma ( ) ( ) ( ) ( ) ( )Pedido de aproveitamentode disciplina da UFF
( ) ( ) ( ) ( ) ( )
Pedido de integralizaçãode atividades complemen-tares
( ) ( ) ( ) ( ) ( )
Pedido de integralizaçãode estágio
( ) ( ) ( ) ( ) ( )
Pedido de declaração per-sonalizada
( ) ( ) ( ) ( ) ( )
Formulário de TCC ( ) ( ) ( ) ( ) ( )Trancamento de matrícula ( ) ( ) ( ) ( ) ( )Inscrição em disciplina ( ) ( ) ( ) ( ) ( )Cancelamento de disci-plina
( ) ( ) ( ) ( ) ( )
Troca de turma ( ) ( ) ( ) ( ) ( )Pedido de aproveitamentode disciplina da UFF
( ) ( ) ( ) ( ) ( )
Pedido de integralizaçãode atividades complemen-tares
( ) ( ) ( ) ( ) ( )
Pedido de integralizaçãode estágio
( ) ( ) ( ) ( ) ( )
Pedido de declaração per-sonalizada
( ) ( ) ( ) ( ) ( )
Formulário de TCC ( ) ( ) ( ) ( ) ( )
14. Existe alguma funcionalidade não citada que você considera importante?
Qual? ________________
59
ANEXO C – Resultados do HEUA
C.1 Questão 1 - O sistema mantém o usuário sempre informadosobre o que está ocorrendo por meio de feedbacks em temporeal?
Tabela 8 – Requisitos da questão 1 do HEUA e respostas
Requisitos(R) Resposta1
1.1 O sistema deve fornecer o caminho percorrido (clicável) pelo usuário. NS1.2 O usuário deve ser capaz de perceber qual é a proposta do sistema. A1.3 O sistema deve informar qual é o idioma utilizado. A1.4 O sistema deve informar quais partes podem ser acessadas com ousem autenticação.
NA
1.5 O sistema deve informar aos usuários as condições de segurança. NA1.6 O sistema deve fornecer áudio descrição ou mídia alternativa paraconteúdos multimídia.
NA
1.7 O sistema deve fornecer áudio descrição para a totalidade do vídeo. NA1.8 O sistema deve fornecer áudio descrição estendida para vídeos quandoas pausas foram insuficientes.
NA
1.9 O sistema deve fornecer uma mídia alternativa para a totalidade doconteúdo multimídia.
NA
1.10 O sistema deve fornecer legenda de textos ao vivo para conteúdosmultimídia.
NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 60
C.2 Questão 2 - O sistema utiliza a linguagem e o modelo mentaldo usuário com características na interface que são correspon-dentes ao mundo real?
Tabela 9 – Requisitos da questão 2 do HEUA e respostas
Requisitos(R) Resposta1
2.1 O sistema deve utilizar uma linguagem simples e clara para o usuário. A2.2 O sistema deve oferecer ao usuário a possibilidade de compreendera finalidade de cada link a partir do texto do link ou juntamente com orespectivo contexto do link.
A
2.3 O sistema deve oferecer ao usuário a possibilidade de compreender afinalidade de cada link a partir do texto do link.
A
2.4 O sistema deve oferecer um mecanismo para identificar a forma com-pleta ou o significado de abreviaturas.
NA
2.5 O sistema deve fornecer cabeçalhos (headings) e rótulos (labels) quedescrevem a sua finalidade.
A
2.6 O sistema deve apresentar ícones que possam ser facilmente associa-dos a objetos do mundo real.
NS
2.7 O sistema deve apresentar conteúdo adicional para auxiliar a com-preensão de textos difíceis ou complexos.
NA
2.8 O sistema deve fornecer ao usuário linguagem gestual para multimí-dias.
NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 61
C.3 Questão 3 - O sistema oferece controle e liberdade ao usuáriopara sair de estados indesejáveis?
Tabela 10 – Requisitos da questão 3 do HEUA e respostas
Requisitos(R) Resposta1
3.1 O sistema deve oferecer opções de controle aos usuários. NA3.2 O sistema deve oferecer a possibilidade de que toda funcionalidadeseja operável utilizando somente o teclado sem necessidade de qualquerespaço de tempo.
NA
3.3 O sistema deve oferecer a possibilidade de navegação utilizando so-mente o teclado.
A
3.4 O sistema deve oferecer a possibilidade de navegação utilizando oteclado dentro de subseções de conteúdo do sistema.
A
3.5 O sistema deve oferecer suporte para que o usuário possa ignorarblocos de conteúdo (repetidos ou não) do sistema.
A
3.6 O sistema deve oferecer ao usuário a possibilidade de navegar se-quencialmente pelo sistema, com ou sem tecnologia assistiva, sem afetaro significado ou a operação dos elementos.
A
3.7 O sistema deve oferecer ao usuário a possibilidade de navegar sequen-cialmente utilizando a tabulação do teclado.
A
3.8 O sistema deve oferecer ao usuário a opção de alterar o idioma emque o conteúdo está escrito.
NS
3.9 O sistema deve oferecer um link (ou caminho direto) para que ousuário consiga voltar ao estado inicial do sistema.
A
3.10 O sistema deve oferecer opções para que o usuário possa controlarconteúdos multimídia.
NA
3.11 O sistema deve oferecer opções para áudio pré-gravado como somde fundo.
NA
3.12 O sistema deve oferecer controles para informações que estejam emmovimento, em modo intermitente.
NA
3.13 O sistema deve oferecer ao usuário maneira de interromper/desativaratualizações, exceto alertas de emergências (que incluem mensagens dealerta de perigo de saúde, segurança ou direito de propriedade, incluindoperda de dados, perda de conexão etc.).
NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 62
C.4 Questão 4 - O sistema é consistente e segue o mesmo padrãoem toda a interface a fim de facilitar o reconhecimento dousuário?
Tabela 11 – Requisitos da questão 4 do HEUA e respostas
Requisitos(R) Resposta1
4.1 O sistema deve fornecer informações sobre o tamanho de qualquerelemento que o usuário possa baixar (fazer download).
NA
4.2 O sistema deve destacar os elementos importantes. A4.3 O sistema deve utilizar outros meios além da cor para distinguir umelemento.
A
4.4 O sistema deve deixar visível o foco nos elementos quando eles sãoselecionados via teclado.
A
4.5 O sistema deve manter o contexto quando um elemento apenas recebeo foco.
A
4.6 O sistema deve diferenciar a apresentação de links de outros compo-nentes que não aceitam ativação.
A
4.7 O sistema deve fornecer um mecanismo para que o usuário possaidentificar a pronúncia de palavras específicas.
NA
4.8 O sistema deve alterar o contexto somente quando um elemento éativado.
A
4.9 O sistema deve garantir que todos os elementos dispõem de marcaçõesde início e fim completas.
A
4.10 O sistema deve garantir que toda mídia pré-gravada possua legenda. NA4.11 O sistema deve garantir que todo áudio ao vivo possua legenda. NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 63
C.5 Questão 5 - O sistema apresenta um projeto (design) preven-tivo e cuidadoso que pode ser capaz de evitar algum problemadurante a interação do usuário?
Tabela 12 – Requisitos da questão 5 do HEUA e respostas
Requisitos(R) Resposta1
5.1 O sistema deve inibir a entrada de dados incorretos pelos usuários. A5.2 O sistema deve utilizar cabeçalhos para organizar seções de conteúdos. A5.3 O sistema deve manter o foco quando o usuário faz uma seleção porfiltro.
A
5.4 O sistema deve permitir ao usuário revisar os dados de entrada antesde submetê-los para sistemas web com responsabilidades jurídicas outransações.
NA
5.5 O sistema deve permitir ao usuário revisar os dados de entrada an-tes de submetê-los para sistemas web que exijam que o usuário envieinformações.
NS
5.6 O sistema deve diferenciar links visitados de links não visitados. NA5.7 O sistema deve utilizar textos para transmitir informações ao invésde imagens de texto.
A
5.8 O sistema SEMPRE deve utilizar textos para transmitir informaçõesao invés de imagens de texto.
A
5.9 O sistema deve utilizar flash com frequência inferior a três vezes porsegundo ou abaixo dos limites de flash universal e flash vermelho.
NA
5.10 O sistema deve utilizar flash APENAS com frequência inferior a trêsvezes por segundo, independente do brilho ou do tamanho do elemento.
NA
5.11 O sistema deve ser independente do recurso de barra de rolagem. A5.12 O sistema deve evitar o uso de janelas pop-up. A5.13 O sistema deve apresentar menus do tipo drop-down com velocidadereduzida o suficiente para serem ativados por usuários que apresentampouca coordenação motora.
A
5.14 O sistema deve apresentar links adjacentes na interface com espaçosuficiente entre eles para evitar erros.
A
5.15 O sistema deve apresentar ícones ou imagens adjacentes na interfacecomo parte da área de ativação dos links.
NS
5.16 O sistema deve apresentar de forma distinta as opções de menu quejá foram visitadas daquelas que ainda não foram selecionadas.
NS
5.17 O sistema deve apresentar menus do tipo drop-down com apenasum nível de opções.
A
5.18 O sistema deve apresentar as opções intermediárias do menu, quandoselecionadas, em uma página com elementos subsequentes e elementosalternativos para o seu acionamento.
NS
5.19 O sistema deve oferecer ao usuário a opção de continuar com aatividade sem perder os dados quando uma sessão autenticada expirar.
NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 64
C.6 Questão 6 - O sistema evita a sobrecarga de memória do usuá-rio fornecendo informações contextuais para cada ação?
Tabela 13 – Requisitos da questão 6 do HEUA e respostas
Requisitos(R) Resposta1
6.1 O sistema deve utilizar a mesma terminologia para referenciar so-mente as mesmas ações.
A
6.2 O sistema deve utilizar as mesmas cores, fontes, localização de nave-gação e leiautes em toda a interface.
A
6.3 O sistema deve manter a mesma ordem de elementos que são repeti-dos.
A
6.4 O sistema deve utilizar nomes diferentes para referenciar URLs dis-tintas.
A
6.5 O sistema deve fornecer informações necessárias para a conclusão detarefas específicas.
A
6.6 O sistema deve fornecer ajuda contextualizada ao usuário. A
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 65
C.7 Questão 7 - O sistema oferece flexibilidade e eficiência aosusuários, agilizando o uso para usuários experientes e man-tendo a facilidade para os novatos?
Tabela 14 – Requisitos da questão 7 do HEUA e respostas
Requisitos(R) Resposta1
7.1 O sistema deve oferecer tempo suficiente para leitura e utilização deconteúdo
A
7.2 O sistema deve oferecer a opção de imprimir ou de salvar documentosgrandes.
NA
7.3 O sistema deve oferecer descrição textual em todos os seus elementosnão textuais.
NA
7.4 O sistema deve oferecer opção de contraste para textos e imagens detexto no mínimo de 4.5:1.
NS
7.5 O sistema deve oferecer opção de contraste para textos e imagens detexto no mínimo de 7:1.
NS
7.6 O sistema deve oferecer opção de zoom para textos e imagens detexto.
A
7.7 O sistema deve garantir que todos os elementos são acessíveis portecnologia de apoio.
A
7.8 O sistema deve garantir que todos os elementos estão disponíveismesmo se scripts forem desabilitados.
A
7.9 O sistema deve oferecer conteúdo independente de características sen-soriais.
A
7.10 O sistema deve oferecer uma ferramenta de busca para que os usuá-rios localizem as opções disponíveis
A
7.11 O sistema deve fornecer opções para que o usuário consiga informa-ções automaticamente.
NS
7.12 O sistema deve disponibilizar diferentes meios de preenchimento deinformações em campos de formulário além do teclado.
NA
7.13 O sistema deve oferecer ajustes de temporização para cada limite detempo definido pelo conteúdo
NS
7.14 O sistema deve oferecer ao usuário uma transcrição equivalente aoque é apresentado visualmente em vídeos.
NA
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 66
C.8 Questão 8 - O sistema oferece estética e projeto (design) mini-malista, mantendo apenas informações úteis, diretas e claras?
Tabela 15 – Requisitos da questão 8 do HEUA e respostas
Requisitos(R) Resposta1
8.1 O sistema deve utilizar cores adequadas nas fontes, fundos de tela eimagens.
A
8.2 O sistema deve utilizar um tamanho de fonte legível. A8.3 O sistema deve fornecer ferramentas ou informações necessárias paraque o usuário acesse no sistema web de modo adequado.
A
8.4 O sistema deve oferecer sugestões e novidades de uma maneira simplese intuitiva.
A
8.5 O sistema deve conter blocos de texto com largura inferior a 80 ca-racteres.
NS
C.9 Questão 9 - O sistema ajuda o usuário a reconhecer, diagnos-ticar e corrigir erros?
Tabela 16 – Requisitos da questão 9 do HEUA e respostas
Requisitos(R) Resposta1
9.1 O sistema deve detectar e avisar ao usuário se ele tem todos os plug-ins necessários para que o sistema funcione normalmente.
A
9.2 O sistema deve fornecer mensagens de erro ao usuário que devem seras mais específicas possíveis.
A
9.3 O sistema deve fornecer ao usuário uma descrição textual caso algumerro de entrada seja identificado.
A
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
ANEXO C. Resultados do HEUA 67
C.10 Questão 10 - O sistema fornece uma ajuda documentada quepode ser facilmente encontrada em caso de necessidade?
Tabela 17 – Requisitos da questão 10 do HEUA e respostas
Requisitos(R) Resposta1
10.1 O sistema deve fornecer informações sobre as tarefas que podem serrealizadas.
NA
10.2 O sistema deve fornecer ao usuário informações adicionais sobre oproprietário/desenvolvedor/responsável pelo sistema.
A
10.3 O sistema deve fornecer um canal simples e pragmático para que ousuário possa informar sobre erros verificados.
NA
10.4 O sistema deve fornecer recursos interativos para auxiliar o preen-chimento de campos de formulário.
NS
1 A - Atende; NS - Não satisfaz; NA - Não se aplica.
68
ANEXO D – Telas
D.1 Mudança de Turma
Figura 7 – Índice de solicitação de mudança de turma, visão do aluno.
Figura 8 – Nova solicitação de mudança de turma, visão do aluno.
ANEXO D. Telas 69
Figura 9 – Detalhamento de solicitação de mudança de turma, visão do aluno.
D.2 Cancelamento de Inscrição
Figura 10 – Índice de solicitação de cancelamento de inscrição, visão do aluno.
ANEXO D. Telas 70
Figura 11 – Nova solicitação de cancelamento de inscrição, visão do aluno.
Figura 12 – Detalhamento de solicitação de cancelamento de inscrição, visão do aluno.
ANEXO D. Telas 71
D.3 Declaração Personalizada
Figura 13 – Índice de solicitação de declarações personalizadas, visão do aluno.
Figura 14 – Nova solicitação de declarações personalizadas, visão do aluno.
ANEXO D. Telas 72
Figura 15 – Detalhamento de solicitação de declarações personalizadas, visão do aluno.
D.4 Aproveitamento de Disciplina
Figura 16 – Índice de solicitação de aproveitamento de disciplina, visão do aluno.
ANEXO D. Telas 73
Figura 17 – Nova solicitação de aproveitamento de disciplina, visão do aluno.
Figura 18 – Detalhamento de solicitação de aproveitamento de disciplina, visão do aluno.
ANEXO D. Telas 74
D.5 Inscrição em Disciplina - Visão da coordenação
Figura 19 – Índice de solicitação de inscrição em disciplina, visão da coordenação.
Figura 20 – Alteração de solicitação de inscrição em disciplina, visão da coordenação.
ANEXO D. Telas 75
D.6 Mobile
(a) Tela inicial, visão do aluno emdispositivos móveis.
(b) Índice de solicitações de inscrição em disci-plinas, visão do aluno em dispositivos móveis.
ANEXO D. Telas 76
(a) Tela de nova solicitação de inscrição emdisciplinas, visão do aluno em dispositivosmóveis.
(b) Tela de detalhamento da solicitação de ins-crição em disciplina, visão do aluno em disposi-tivos móveis.
![CENÁRIOS LOGÍSTICOS [ Fabiane Veras ]. DESCRIÇÃO / CONSTRUÇÃO DE CENÁRIOS LOGÍSTICOS](https://img.document.onl/doc/110x75/552fc0fb497959413d8b9541/cenarios-logisticos-fabiane-veras-descricao-construcao-de-cenarios-logisticos.jpg)
