Desenvolvimento de um sistema acadêmico-administrativo web com foco em usabilidade e acessibilidade

(1)

Gabriel Guadalupe Rodríguez

Marcela Corrêa Santos Ramos

Desenvolvimento de um sistema

acadêmico-administrativo web com foco em

usabilidade e acessibilidade

Niterói

(2)

Gabriel Guadalupe Rodríguez

Marcela Corrêa Santos Ramos

Desenvolvimento de um sistema

acadêmico-administrativo web com foco em usabilidade e

acessibilidade

Trabalho de Conclusão de Curso apresentado ao Curso de Bacharelado em Sistemas de In-formação, como parte dos requisitos necessá-rios para a obtenção do título de Bacharel em Sistemas de Informação.

Universidade Federal Fluminense Instituto de Computação

Sistemas de Informação

Orientadora: Luciana Cardoso de Castro Salgado

Niterói

(3)

Ficha catalográfica automática - SDC/BEE Gerada 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 web com foco emusabilidade e acessibilidade : / Gabriel Guadalupe Rodriguez, Marcela Corrêa Santos Ramos ; Luciana Cardoso de Castro Salgado, orientadora. Niterói, 2018.

75 f. : il.

Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação)-Universidade Federal Fluminense, Escola de Engenharia, Niterói, 2018.

1. Aplicação web. 2. Usabilidade web. 3. Interação homem-máquina . 4. Pessoa com deficiência visual. 5. Produção intelectual. I. Ramos, Marcela Corrêa Santos. II. Salgado, Luciana Cardoso de Castro, orientadora. III. Universidade Federal Fluminense. Escola de Engenharia. IV. Título. CDD

(4)

-Gabriel Guadalupe Rodríguez Marcela Corrêa Santos Ramos

Desenvolvimento de um sistema acadêmico-administrativo web com foco em usabilidade e acessibilidade

Trabalho de Conclusão de Curso apresentado ao Curso de Bacharelado em Sistemas de In-formação, como parte dos requisitos necessá-rios para a obtenção do título de Bacharel em 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ói 2018

(5)

Agradecimentos

Eu Gabriel, agradeço especialmente à minha mãe Isabel Cristina Rodriguez Lou-reiro e à minha vó materna Maria Teresa LouLou-reiro Rodriguez que me apoiaram ao longo dessa jornada, pois seus incentivos e conselhos de vida foram valiosos para atingir a conclusão desta etapa. Também agradeço a minha parceira de TCC, melhor amiga e companheira de todas as horas pela perseverança.

Eu Marcela, agradeço aos meus pais Marcos dos Santos Ramos e Regina Sardinha Corrêa que sempre me apoiaram e lutaram para que eu estivesse concluindo mais essa etapa da minha vida. Aos meus irmãos, e em especial ao meu irmão Marcos dos Santos Ramos 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 nessa jornada 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 da nossa graduação. Além de ter proporcionado a inspiração para o nosso projeto através do SolicitaSI, sistema de grande ajuda para todos os alunos de Sistemas de Informação da Universidade Federal Fluminense.

Aos amigos pelos diversos momentos compartilhados e pelo apoio incondicional durante 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 seria possível realizar este trabalho.

(6)

Resumo

A universidade têm se tornado cada vez mais informatizada, com isso a demanda pela criação de sistemas acadêmicos-administrativos tem crescido. É importante que esses sistemas sejam acessíveis para todos, com isso a importância da acessibilidade e usabilidade desde o início do processo de desenvolvimento, entretanto, existe uma complexidade para a criação de sistemas com foco em acessibilidade e usabilidade. Neste trabalho é demonstrado o desenvolvimento de um sistema no qual aplicam-se as diretrizes da Web Content Accessibility Guidelines (WCAG) e as 10 heurísticas de Nielsen. Juntamente com as necessidades de usabilidade e acessibilidade, foram identificadas as necessidades e problemas dos estudantes e das coordenações para que pudéssemos agilizar e informatizar alguns processos realizados por ambos. Desta forma nosso objetivo se tornou não somente solucionar os problemas identificados como também garantir que a nossa solução seja acessível à todos. Para isso, foi feita uma 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 nos ajudaram a entender o problema e desenvolver o sistema. A fim de garantir que o 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 avaliar a usabilidade e acessibilidade. Ambos os métodos nos permitiram concluir que o sistema desenvolvido está complacente com as diretrizes WCAG e as heurísticas de Nielsen. O sistema atende as necessidades dos alunos e das coordenações dos cursos de graduação da Universidade Federal Fluminense, contemplando diversas atividades realizadas por ambos os citados, tendo o foco principal nas atividades do período de ajustes, que foram as identificadas como as principais para os alunos. Ele també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 utilizada foi adequada, pois resultou em um sistema com boa acessibilidade, usabilidade e aderente as necessidades dos usuários.

Palavras-chaves: Acessibilidade web. Usabilidade web. Desenvolvimento de

(7)

Abstract

Universities have become more and more computerized, and, because of that, there’s an ever higher demand on developing academic-administrative systems. It is important that these systems be accessible to everyone, therefore it is crucial that said 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 focused on accessibility and usability. In this work, we demonstrate the development of our system, which follows the Web Content Accessibility Guidelines (WCAG) directives and also Nielsen’s 10 Usability Heuristics. Interwoven with the two abovementioned needs, we were able to identify some necessities and problems from students and coordinations that could be improved by introducing an informational system. Our goal, then, became not only to solve those problems, but also to make sure that each and 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 and the 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 process of understanding the problems we faced and developing the system. With the pur-pose of guaranteeing the desired result, we evaluated the levels of accessibility and usability, through the use of automated tools and a questionnaire used to assess the two concepts. Both methods allowed us to reach the conclusion that the developed system is in agreement with the WCAG guidelines and Nielsen’s heuristics. Our system meets the needs of students and coordinations of the Federal Fluminense University, 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 of a semester. It also was developed to be responsive and accessible while browsing from mobile devices. Finally, we concluded through our results that the adopted methodology was suitable, as it guided us to develop a system with not only good user accessibility and usability, but also that meets user’s needs.

(8)

Lista de ilustrações

Figura 1 – Tela do plano de estudos . . . 44 Figura 2 – Tela de inscrição em disciplinas . . . 45 Figura 3 – Detalhes da inscrição realizada . . . 45 Figura 4 – Tela do plano de estudos com o link para nova inscrição selecionado . . 46 Figura 5 – Tela de nova solicitação de inscrição em disciplina com dados

preenchi-dos e botão de confirmação selecionado . . . 46 Figura 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. . . 68 Figura 8 – Nova solicitação de mudança de turma, visão do aluno. . . 68 Figura 9 – Detalhamento de solicitação de mudança de turma, visão do aluno. . . 69 Figura 10 – Índice de solicitação de cancelamento de inscrição, visão do aluno. . . . 69 Figura 11 – Nova solicitação de cancelamento de inscrição, visão do aluno. . . 70 Figura 12 – Detalhamento de solicitação de cancelamento de inscrição, visão do aluno. 70 Figura 13 – Índice de solicitação de declarações personalizadas, visão do aluno. . . 71 Figura 14 – Nova solicitação de declarações personalizadas, visão do aluno. . . 71 Figura 15 – Detalhamento de solicitação de declarações personalizadas, visão do

aluno. . . 72 Figura 16 – Índice de solicitação de aproveitamento de disciplina, visão do aluno. . 72 Figura 17 – Nova solicitação de aproveitamento de disciplina, visão do aluno. . . . 73 Figura 18 – Detalhamento de solicitação de aproveitamento de disciplina, visão do

aluno. . . 73 Figura 19 – Índice de solicitação de inscrição em disciplina, visão da coordenação. . 74 Figura 20 – Alteração de solicitação de inscrição em disciplina, visão da coordenação. 74

(9)

Lista de tabelas

Tabela 1 – Esforço por ponto de história . . . 32

Tabela 2 – Requisitos funcionais . . . 33

Tabela 3 – Resultados da perspectiva de inspeção . . . 39

Tabela 4 – Resultados do ASES nas visão da coordenação . . . 39

Tabela 5 – Resultados do ASES na visão dos alunos . . . 40

Tabela 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 . . . 59

(10)

Sumário

1 Introdução . . . 12 1.1 Contextualização . . . 12 1.2 Motivações . . . 13 1.3 Objetivos . . . 14 1.4 Organização do trabalho . . . 14 2 Fundamentação Conceitual . . . 15 2.1 Acessibilidade na web . . . 15

2.1.1 Recomendações de acessibilidade para conteúdo da web . . . 16

2.1.2 Acessibilidade web no Brasil . . . 17

2.2 Usabilidade na web . . . 18

2.3 O processo de desenvolvimento . . . 20

3 Trabalhos relacionados . . . 21

3.1 Avaliação de usabilidade e acessibilidade em sistemas web . . . 21

3.2 A importância da interface de sistemas acadêmicos . . . 22

4 Metodologia . . . 24 4.1 Objetivos e Métodos . . . 24 4.2 Coleta de Dados . . . 25 4.3 Resultado da Análise . . . 25 4.3.1 Definição de Personas . . . 25 4.3.2 Criação de Cenários . . . 25 4.3.3 Definição de Requisitos . . . 26 4.3.3.1 Metas de usabilidade . . . 26 4.3.3.2 Metas de acessibilidade . . . 26 4.4 Avaliações . . . 26 4.4.1 Avaliações de Software . . . 27

4.4.2 Avaliação de Usabilidade e Acessibilidade . . . 27

5 Processo de desenvolvimento do SolicitaUFF . . . 28

5.1 Comunicação . . . 28

5.1.1 Formulação . . . 29

5.1.1.1 Informações coletadas . . . 29

5.1.2 Elicitação . . . 30

(11)

5.1.2.2 Requisitos não-funcionais . . . 31 5.1.3 Negociação . . . 32 5.2 Planejamento . . . 32 5.3 Modelagem . . . 33 5.3.1 Personas . . . 33 5.3.2 Cenários . . . 34

5.3.3 Cenários evidenciando a importância da acessibilidade . . . 35

5.4 Construção . . . 36 5.4.1 Linguagem e Framework . . . 36 5.4.2 Bancos de Dados . . . 37 5.4.3 Versionamento . . . 37 5.4.4 Codificação . . . 37 5.4.4.1 Qualidade de código . . . 37

5.4.4.2 Testes unitários e de integração . . . 38

5.4.5 Método de avaliação ACCESSA . . . 38

5.4.5.1 Avaliação de conformidade com as diretrizes do WCAG 2.0 38 5.4.5.2 Ferramenta automática ASES . . . 39

5.4.6 Métrica HEUA . . . 40 5.5 Implantação . . . 42 6 SolicitaUFF . . . 43 6.1 Funcionalidades . . . 43 6.2 Cenários de Interação . . . 43 7 Considerações Finais . . . 48 Referências . . . 49

Anexos

51

ANEXO A Entrevistas . . . 52

A.1 TCLE - Termo de Consentimento Livre e Esclarecido . . . 52

A.2 Roteiro das entrevistas . . . 53

ANEXO B Questionário . . . 54

B.1 TCLE - Termo de Consentimento Livre e Esclarecido . . . 54

B.2 Perguntas do questionário . . . 55

ANEXO C Resultados do HEUA . . . 59

C.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

(12)

SUMÁRIO 11

C.2 Questão 2 - O sistema utiliza a linguagem e o modelo mental do usuário

com 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 de estados indesejáveis? . . . 61

C.4 Questão 4 - O sistema é consistente e segue o mesmo padrão em toda a interface a fim de facilitar o reconhecimento do usuário? . . . 62

C.5 Questão 5 - O sistema apresenta um projeto (design) preventivo e cuidadoso que 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 fornecendo informaçõ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 os novatos? . . . 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 corrigir erros? . . . 66

C.10 Questão 10 - O sistema fornece uma ajuda documentada que pode ser facilmente encontrada em caso de necessidade? . . . 67

ANEXO D Telas . . . 68

D.1 Mudança de Turma . . . 68

D.2 Cancelamento de Inscrição . . . 69

D.3 Declaração Personalizada . . . 71

D.4 Aproveitamento de Disciplina . . . 72

D.5 Inscrição em Disciplina - Visão da coordenação . . . 74

(13)

12

1 Introdução

Os sistemas de informação estão presentes em todos os âmbitos da nossa sociedade e cada vez mais fazem parte das tarefas que desempenhamos diariamente. Nesse contexto as interações das pessoas com as mais diversas interfaces computacionais são de grande importância para o aproveitamento eficiente dos recursos humanos disponíveis e para a inclusão de todos os indivíduos. Essas interações com as interfaces homem-máquina são objeto de estudo discutido e de importância reconhecida (MELO, 2014), além de serem ferramentas essenciais para a inclusão das pessoas com deficiência.

1.1 Contextualização

Para atender as demandas acadêmicas e administrativas as universidades tem in-vestido cada vez mais em tecnologia da informação, assim como em acessibilidade, afim de 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 mais características da situação atual. Em outras palavras, resolver um problema de design significa 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ção entre eles. Analisamos as pessoas, artefatos e processos. Deste modo, compreende-se as necessidades dos usuários, encontrar problemas e características desagradáveis e algo que podemos melhorar.

Na situação atual os processos desempenhados pelas coordenações e alunos são bastante manuais e nada integrados com outros sistemas da universidade, com isso, gasta-se muito tempo processando informações. Neste caso, a análigasta-se da situação atual foi importante para identificarmos que um sistema poderia ser empregado para melhorar o processo, 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 fatores de 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 e suas dificuldades. “Cenários são objetos de design orientados a tarefas. Eles descrevem sistemas em termos de tarefas que os usuários tentarão fazer quando utilizarem esses sistemas, certificando-se que o design permanecerá focado nas necessidades e interesses

(14)

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 perper-sonagem fictício criado para descrever um usuário típico. A técnica de personas 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. Dudu-rante a investigação inicial 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ção para o problema, é uma intervenção positiva.(BARBOSA; SILVA, 2010). No entanto, é necessário que esse sistema esteja integrado com outros sistemas da universidade e tenha manutenção.

Finalmente, o processo de desenvolvimento de um sistema influencia na qualidade do produto final. Vários aspectos devem ser avaliados em relação a um sistema, alguns relacionados a construção do sistema (facilidade de manutenção e robustez) e outros com o 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ções

A 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. Os alunos necessitam comparecer à coordenação para realizar pedidos como: requerimento de atividade complementar; dispensas em disciplinas; aproveitamento de disciplinas; ajustes no plano de estudos; pedidos de declarações diversas. Todas essas são tarefas que poderiam ser 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 promover a inclusão desse grupo de pessoas. Portanto, o aspecto da acessibilidade se torna muito relevante 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, uma percepção neutra e ruim sobre acessibilidade dos conteúdos web que tiveram contato no ano 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

(15)

Capítulo 1. Introdução 14

portanto deixam de ser uma oportunidade de inclusão dessas pessoas e passam a ser um obstá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 aspecto garantido 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 Objetivos

A 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 a investigação de trabalhos relacionados para aplicar as teorias estudadas e as avaliações de usabilidade e acessibilidade em um sistema integrado com os demais da Universidade Federal 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ão no ensino superior (MELO, 2017) e a obrigação segundo o decreto de No _{5.296 de 2 de}

dezembro de 20041, nos motivou para a nossa pesquisa.

O objetivo deste trabalho é a criação de um sistema acadêmico-administrativo com foco 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 trabalho

Alé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údo web 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ção da usabilidade e acessibilidade dos sistemas web, além de um estudo de usabilidade que propõ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 processo de 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 as considerações finais, limitações e trabalhos futuros; Os anexos detalham a aplicação de alguns métodos de avaliação e as interfaces produzidas tanto para “desktop” quanto para dispositivos móveis.

1

http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm, acesso em: 25/11/2018

(16)

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 e conceitos que se relacionam com o tema da pesquisa, apontam-se as principais diretrizes documentadas pela WCAG 2.0. O conteúdo desta seção nos ajudou a compreender mais precisamente a problemática a ser estudada. Ao final, aborda-se como é o processo de desenvolvimento focado em acessibilidade e usabilidade.

2.1 Acessibilidade na web

Para 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 barreiras que impedem esses usuários de utilizarem o sistema. Não podem existir barreiras que os impeçam de interagirem com a interface. “Cuidar da acessibilidade significa permitir que mais pessoas possam interagir com o sistema, tenham elas alguma deficiência ou não. A intenção é incluir, não excluir.” (BARBOSA; SILVA, 2010).

Para acessibilidade total, todos os usuários devem poder fazer três coisas para cada controle, instrução ou saída. Segundo Nirmita Narasimhan (NARASIMHAN, 2010) para atingir 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 diferentes capacidades visuais.

∙ Diversidade de métodos de interação - Permitir a possibilidade da navegação pelo teclado.

∙ Diversidade de saídas - Saídas visuais e sonoras podem abranger diversas formas de deficiência.

(17)

Capítulo 2. Fundamentação Conceitual 16

Além disso, é necessário garantir a compatibilidade com as diversas tecnologias assistivas, seguindo os padrões internacionais. Isso também pode resultar em melhorias na experiência de todos os usuários.

Portanto, a interface não pode ser um obstáculo, é importante que o usuário seja capaz 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 Accessibility Initiate (WAI-ARIA) - a WAI é uma iniciativa e ARIA é um padrão criados pelo World Wide 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 quatro princípios (percepção, compreensão, operação e robustez) que se subdividem, totalizando doze diretrizes principais:1

Princípio 1 - Percetível: A informação e os componentes da interface de usuário têm

de ser apresentados de forma a que os usuários as possam perceber.

Diretriz 1.1 (Alternativas em Texto): Fornecer alternativas em texto para todo

o 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 diferentes

formas sem perder informação ou estrutura.

Diretriz 1.4 (Distinguível): Facilitar aos utilizadores a audição e a visão dos

conteúdos nomeadamente através da separação do primeiro plano do plano de fundo.

Princípio 2 - Operável: Os componentes da interface do usuário e a navegação têm de

ser 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

(18)

Diretriz 2.2 (Tempo Suficiente): Proporcionar aos utilizadores tempo suficiente

para lerem e utilizarem o conteúdo.

Diretriz 2.3 (Convulsões): Não criar conteúdo de uma forma que se sabe que

pode 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êm

de 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 funcionem

de 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 as tecnologias 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), desenvolvido para o governo brasileiro, focado em acessibilidade. Na parte 3 deste modelo existem seis 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

(19)

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úblicas do Brasil, garantindo o acesso a todos, para que o processo de acessibilidade desses sites seja conduzido de forma padronizada e de fácil implementação. A versão atual 3.1 do eMAG 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 atenaten-der os usuários mais leigos, permitindo uma compreensão maior por qualquer cidadão. Além disso, o documento traz conteúdos extras referentes à acessibilidade, legislação e leituras complementares.

A preocupação com a inclusão de pessoas com deficiências é um tema de grande importância. Em 2004 , a criação do decreto de No _{5.296 de 2 de dezembro de 2004}3

tor-nou obrigatória a disponibilização de sites do governo em conformidade com os padrões de 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.296

de 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ítios eletrô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 governo brasileiro 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 a qualquer 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). O sistema 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ários conseguem aprender a executar determinada tarefa, em geral, procedimentos mais rápi-dos tendem a ser mais eficientes. É importante que o sistema possua uma interface que facilite que o usuário resgate da memória o que aprendeu, portanto, os elementos devem

3

http://www.planalto.gov.br/ccivil_03/_ato2004-2006/2004/decreto/d5296.htm, acesso em: 05/10/2018

(20)

estar organizados de maneira que o usuário encontre facilidade em lembrar como utilizar o 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. (NBR ISO/IEC 9126-1, 2003)4_.

∙ A definição de qualidade de uso da ISO 9241-115 _{é o quanto um produto, utilizado}

por usuários específicos, atende às necessidades desses usuários para que eles atinjam as metas especificadas com eficácia, produtividade e satisfação, em contextos de uso definidos.

“A usabilidade é o critério de qualidade de uso mais conhecido e, por conseguinte, o mais frequentemente considerado. Para muitas pessoas, inclusive, qualidade de uso chega a ser sinônimo de usabilidade.” (BARBOSA; SILVA, 2010). Portanto, a interação e a interface devem ser adequadas para que o usuário aprenda facilmente a utilizar o sistema e 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ágina falha em expor claramente o que uma empresa oferece e o que os usuários podem fazer no site, as pessoas vão embora. Se os usuários se perdem no site, eles vão embora. Se a informação de um site é difícil de ler ou nã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 a interação entre o sistema e o usuário não for fácil e intuitiva, o usuário abandona a tarefa que 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/2018

5

(21)

2.3 O processo de desenvolvimento

Ao 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 sistema}

com foco em usabilidade e acessibilidade, em nossas pesquisas, conhecemos o Processo de Desenvolvimento de sistemas web com Acessiblidade e Usabilidade (PDWAU), no qual vimos a possibilidade de utilizá-lo de forma adaptada junto com o Scrum.

De forma adaptada, utilizamos os pontos de histórias7_{, para estimar requisitos e}

para melhorar a previsão da quantidade de trabalho que somos capazes de realizar em cada sprint.

“O processo de desenvolvimento de sistemas web com acessibilidade e usabilidade foi 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 absoluta de como se deve desenvolver um sistema levando em consideração as diretrizes de usabili-dade e acessibiliusabili-dade, porém, segundo a autora, “o processo permite ter uma base sólida em relação à sua construção sobre os aspectos de acessibilidade e usabilidade, visto que foi 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 com foco em acessibilidade e usabilidade e mostramos ao final o resultado do questionário HEUA para avaliar o nível de usabilidade e acessibilidade do nosso sistema.

6

https://www.desenvolvimentoagil.com.br/scrum/, acesso em: 25/11/2018

7

https://confluence.atlassian.com/jsbr/estimar-em-pontos-de-historia-920354862.html, acesso em: 25/11/2018

(22)

21

3 Trabalhos relacionados

Neste capítulo apresentam-se estudos que abordam como medir a usabilidade e acessibilidade em sistemas web. Na seção 3.1 temos um estudo da aplicação da métrica HEUA para um avaliação heurística, além de apresentar o método que avalia a acessibi-lidade e usabiacessibi-lidade de sistemas web através de quatro perspectivas. Por fim, na seção 3.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 web

Ló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, segundo o artigo citado, essas ferramentas não conseguem verificar todos os casos e fazer uma interpretação contextualizada das regras propostas internacionalmente, como a WCAG, e portanto faz-se necessário um método capaz de avaliar a acessibilidade e usabilidade manualmente.

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 classificados em 10 perguntas que servem como guias para a avaliação heurística do requerimento que devem 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 de acordo com o nível de adequação dele em termos de acessibilidade e usabilidade. Um coe-ficiente negativo significa pior acessibilidade e usabilidade, enquanto coecoe-ficientes positivos se 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, podendo ser usado nas diversas fases do ciclo de vida de um sistema ou continuamente para os sistemas que estão em constante desenvolvimento.

Os autores (DIAS; FORTES; MASIERO, 2014) então concluem que o HEUA se mostrou uma boa ferramenta para quantificar os níveis de usabilidade e acessibilidade, gerando resultados que apontam quais áreas devem receber mais atenção e permitindo até 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

(23)

Capítulo 3. Trabalhos relacionados 22

CESSA para a verificação de acessibilidade e usabilidade. Assim como no artigo “HEUA: A heuristic evaluation with Usability and Accessibility requirements to assess web systems” (DIAS; FORTES; MASIERO, 2014), eles consideram que as ferramentas de verificação automática não são precisas o suficiente para serem usadas sozinhas, por terem falhas ao contextualizar as regras definidas nos padrões internacionais com a relevância do elemento que está sendo analisado.

Portanto o ACCESSA propõe 4 perspectivas diferentes que combinadas trazem resultados 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 os princípios WCAG 2.0, “Tool’s Perspective”, onde são usadas as ferramentas de verificação automática, como Hera2 _{e daSilva}3_{; “User’s Perspective”, que faz uma análise através dos}

relatos do usuário, podendo utilizar questionários, entrevistas e as falas do usuário durante o uso; “Expert’s perspective”, que consiste na análise das ações que os usuários fizeram ao 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.0 que trariam maior benefício de acessibilidade e usabilidade com o menor esforço. Dessa forma o tempo necessário para executar as tarefas atribuídas foi reduzido na maioria dos casos 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 e acessibilidade.

3.2 A importância da interface de sistemas acadêmicos

BORGES, 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 interface de um sistema. O sistema em questão (SolicitaSI) visa auxiliar os processos de solicitações que 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 disciplinas já inscritas, entre outros. O sistema auxilia também os funcionários responsáveis por responder essas solicitações. Além das solicitações que só podem ser feitas dentro do período de ajustes, o sistema permite: solicitação de estagio; solicitação de carga horária de atividades complementares; e cadastro de projeto final.

O foco do artigo foi reformular a interface desse sistema, seguindo diretrizes do W3C, 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 a

2

http://www.sidar.org/hera, acesso em: 25/11/2018

3

(24)

Capítulo 3. Trabalhos relacionados 23

um questionário que tinha como objetivo caracterizar o perfil do aluno mapeando suas expectativas e problemas encontrados ao utilizar o sistema. Para compreender com mais profundidade as dificuldades dos alunos, foi feito um teste de usabilidade e em seguida uma 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 foram completamente resolvidos, pois, após o re-design a mensagem sumia após o pressionar de um 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 atividades realizadas 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 mais abrangente pois foi necessário a implementação das funcionalidades do sistema, além de atender 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.

(25)

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 principalmente o questionário e as entrevistas, para assim, compreender as necessidades dos usuários finais. “A entrevista é um importante instrumento para a coleta de dados na efetivação de uma pesquisa. Na entrevista o informante fala, no questionário o informante escreve.” (HEERDT; LEONEL, 2007).

4.1 Objetivos e Métodos

As 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 para ampliar o grau de conhecimento da área de interface homem-computador, nos capacitando a compreender melhor o foco de nossa pesquisa, construindo assim uma base teórica a fim de utilizá-la na construção do trabalho.

No segundo passo, utilizamos o método indutivo, no qual a partir da análise dos dados fornecidos pelo artigo (BORGES, 2016), o que nos fez perceber que um sistema com essas funcionalidades seria de grande benefício para toda a universidade. Analisamos os dados dos questionários, o perfil dos usuários e seus objetivos, de que forma o sistema auxilia os funcionários e de forma geral como o sistema funciona.

(26)

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 para o 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álise

Este trabalho utiliza-se de resultados quantitativos e qualitativos. Recorre ao quan-titativo para encontrar problemas que os estudantes queixam-se. Já no qualitativo, visa aprofundar 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 isso foi 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 dos usuá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 podermos gerar alternativas de design para este futuro usuário do sistema. Criamos cenários para

(27)

a análise do problema, a fim de compreender o que eles fazem, como, e quais problemas enfrentam, como pode ser visto no Capítulo 5. E em busca de detalhar as ações do usuário e as respectivas respostas do sistema criamos cenário de interação, como pode ser visto no 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 nas entrevistas e questionários com os usuários e a inspeção de sistema semelhante. Após a listagem dos requisitos, eles foram organizadas em requisitos funcionais e não-funcionais e serão apresentados na seção 5.1.2.

Com base nas pesquisas dos padrões eMAG, WCAG e WAI-ARIA, no estudo dos 3 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 ser efetuada.

4.3.3.2 Metas de acessibilidade

∙ Permitir que os usuários de leitores de tela tenham acesso a toda a informação disponí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 dos usuários.

4.4 Avaliações

A 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. Temos como foco da nossa avaliação as funcionalidades do sistema, consideramos avaliações de software, usabilidade e acessibilidade.

(28)

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 Rubocop}2_{, capazes de testar o}

funcio-namento do código e as boas práticas de estilo de código, respectivamente. Esses testes são programados visando testar o comportamento do sistema avaliando cenários e contextos especí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 entradas oferecidas.

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 HEUA no sistema web. Para agilizarmos o processo de avaliação de acessibilidade, utilizamos a ferramenta de avaliação automática do governo brasileiro. Ainda que a avaliação por um avaliador 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 de Acessibilidade em Governo Eletrônico (eMAG).

1

http://rspec.info, acesso em: 25/11/2018

2

http://batsov.com/rubocop/, acesso em: 25/11/2018

3

(29)

28

5 Processo de desenvolvimento do

Solici-taUFF

O calendário escolar da Universidade Federal Fluminense é elaborado e aprovado anualmente e contém os principais eventos do ano letivo da Universidade. No calendário da UFF está previsto o chamado período de ajustes, no qual os alunos podem fazer solicitações à suas coordenações. Enumeramos algumas dessas solicitações e outras que podem 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 processo PDWAU para que levássemos em conta questões de acessibilidade e usabilidade desde o começo do processo de desenvolvimento. As atividades desse processo são divididas da seguinte 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ção

Queremos 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 a tecnologia pode trazer para a sua vida, e sua experiência objetiva e subjetiva ao interagir com a tecnologia. As ações da atividade de Comunicação são: Formulação, Elicitação e Negociação.

(30)

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 os alunos.

Após a definição do objetivo das entrevistas, elaboramos um roteiro (ANEXO A) e um Termo de Consentimento Livre e Esclarecido (TCLE) (ANEXO A), o qual teve como base o documento disponibilizado pelo Comitê de Ética em Pesquisa da Faculdade de Medicina da Universidade Federal Fluminense (CEP FM/UFF). Utilizamos também para a coleta de informações, a gravação do áudio das entrevistas, o qual consta a autorização para 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 deixam ampla 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 ocorreram quando 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, foi possível traçar o perfil médio dos alunos. Identificamos que 67,2% dos alunos se encontram abaixo 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

(31)

maioria já cursaram mais de 5 períodos. Dos alunos que cursam noturno 84,2% trabalham ou 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 atendimento burocrá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 considecorrobo-ram muito importante poder realizar solicitaçõ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 nas funcionalidades 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 os alunos 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 credenciais já utilizadas nos outros sistemas institucionais.

1. Área do coordenador e funcionário da coordenação: Possui a página inicial de cada tipo de solicitação, onde é possível visualizar as solicitações dos alunos e os detalhes da solicitação, onde o coordenador ou funcionário podem alterar o status de uma solicitação.

2. Área do aluno: Possui a página inicial de cada tipo de solicitação, onde é possível criar uma nova solicitação e visualizar o histórico de solicitações. Os detalhes das solicitaçõ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 onde o aluno pode visualizar o seu plano de estudos, onde também é possível pedir o cancelamento 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 plano

de 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 plano

(32)

R03 O sistema deve permitir que os alunos solicitem o cancelamento de inscrição em

turma 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 possam

alterar o status de uma solicitação, provendo o acompanhamento do andamento da mesma.

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 aos

usuá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 status

das 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). E

utilizando 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 os

dados até a última operação que realizou.

Desempenho: O tempo de processamento de uma operação de consulta e o tempo de

resposta para as operações de cadastro, alteração e exclusão de solicitações não devem exceder três segundos.

Manutenibilidade: O sistema deve ter mais de 80% de cobertura de testes e 100% de

cobertura do Rubocop1, como será explicado no Capítulo 5.

1

(33)

5.1.3 Negociação

Para a realização deste projeto foi necessária uma colaboração entre os autores e 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ção de usuários unificado da universidade e para realizar as diversas integrações com o banco de 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 como o 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 a aderência do sistema às necessidades e regras de negócio da Universidade.

5.2 Planejamento

Após os requisitos básicos do sistema serem identificados na seção anterior, pode-mos seguir para a atividade de planejamento. Nesse caso, adaptapode-mos o ciclo incremental do processo PDWAU para uma abordagem mais ágil, planejamos através de “sprints” de 15 dias, onde cada sprint possui tarefas designadas que deveriam iniciar e terminar junto com 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 um consenso para se encaixar dentro dos “sprints”.

Tabela 1 – Esforço por ponto de história Pontos de história Esforço

1 Trivial 3 Baixo Esforço 5 Médio Esforço 8 Alto Esforço 13 Praticamente impossível 2

(34)

Tabela 2 – Requisitos funcionais Requisitos Pontos de história

R01 05 R02 05 R03 05 R04 03 R05 05 R06 03 R07 08 R08 01 R09 03 R10 03 R11 03

5.3 Modelagem

Nesta 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 coordenadores de cursos de graduação, optamos por realizar entrevistas individuais, a qual foi uma opção eficaz 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 melhorado através de um sistema. Com os alunos utilizamos um questionário, que nos possibilitou compreender os pontos relevantes para os alunos. Alunos de diversos cursos, responderam e com isso vimos que há problemas relevantes e em comum, o qual o SolicitaUFF poderia resolver de maneira segura, eficaz e eficiente. Para cada ator do processo, criamos uma persona 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 curso de 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, acha

muito 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.

(35)

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, dimidimi-nuindo 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 de

ajustes. 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ático

realizar essas tarefas, pois necessita preencher diversos papéis.

Como o SolicitaUFF pode ajudá-la: Removendo as restrições de horários para

a realização dos pedidos e reduzindo a burocracia, assim, economizando tempo e 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 estabelecido por esta, e solicitar a mudança. Roberta faz estágio no Rio de Janeiro até as 17h e 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 precisa comparecer novamente à coordenação.

(36)

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 necessita preencher um formulário e entregar na coordenação do seu curso, no horário de funcionamento. Essa solicitação precisa ser aprovada para, só depois constar em seu Histórico. Depois de realizar o pedido até a aprovação, ou não, Roberta não sabe a situação de seu pedido. Além disso, ela terá que preencher um formulário para cada disciplina que desejar aproveitar.

Também levantado pelo questionário e entrevista, identificamos que algumas coordenações fazem 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 GoogleForms para facilitar as solicitações de alteração de plano de estudo. É disponibilizado no site 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, pois o formulário sugerido é um recurso não-oficial da universidade, mas como Roberta não poderia comparecer à coordenação, ela acaba preenchendo o formulário para solicitar a alteração.

2. Cenário: Solicitar declaração personalizada

Roberta necessita solicitar declarações personalizadas, para um intercâmbio. Nos sistemas 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 Roberta necessita 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 sua solicitaçã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 impossibilitaram o 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 ela enfrenta.

(37)

1. Persona: Ana Júlia é uma jovem de 20 anos estudante de curso de graduação da UFF 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 em

papel.

Como o SolicitaUFF pode ajudá-la: Conseguir navegar sem grandes barreiras

(acessibilidade) pelo sistema web e obter as informações desejadas, tende a aumentar 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 e utilizá-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 para o semestre. Ela deve solicitar no período de ajuste da UFF a disciplina que deseja cursar, para tanto, Ana Júlia necessita comparecer na coordenação de seu curso e preencher 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 conseguiu encontrar um link para solicitar a inscrição em disciplina, e nem percebeu que o período de ajustes havia terminado. A informação de que o período de ajustes havia terminado se encontrava dentro de uma figura e essa informação não pôde ser lida pelo leitor de tela, portanto, ela não teve acesso a essa informação.

5.4 Construção

Nas 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ões de 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 em sua versão 2.5.1, assim como o framework web Ruby on Rails na versão 5.2. A escolha

(38)

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 acessibilidade que deveriam ser implementados, assim como por serem tecnologias presentes no dia a dia da STI-UFF.

5.4.2 Bancos de Dados

Como solução de armazenamento de dados foi obrigatório a utilização de dois bancos de dados relacionais distintos, sendo um deles para a integração do sistema com o banco 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ém um 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 cada requisição web.

5.4.3 Versionamento

Utilizamos Git como sistema de controle de versões, através de ferramenta em terminal e o GitLab como ferramenta para administrar o repositório remoto, em conjunto também utilizamos o versionamento semântico3 do código, no formato X.Y.Z, onde X, Y e Z são números e são incrementados de acordo com o tipo de modificação que é realizada no 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 com os demais projetos da STI-UFF, utilizamos a ferramenta Rubocop4 que analisa o código e o avalia de acordo com regras predefinidas de estilo e boas práticas, ao final da análise um relatório é gerado indicando quantos problemas foram encontrados, onde estão e de qual natureza eles são.

3 _{https://semver.org, acesso em: 25/11/2018} 4 _{https://docs.rubocop.org, acesso em: 25/11/2018}