Você está na página 1de 56

THIAGO ANTÔNIO DA BOA VIAGEM LIMA

Orientadora: Amanda Sávio Nascimento e Silva

FEEDBACK: UM SISTEMA WEB PARA AUXILIAR OS


MORADORES DAS REPÚBLICAS ESTUDANTIS DE
OURO PRETO NA AUTOGESTÃO DAS MESMAS

Ouro Preto
Julho de 2016
Universidade Federal de Ouro Preto
Instituto de Ciências Exatas e Biológicas
Bacharelado em Ciência da Computação

FEEDBACK: UM SISTEMA WEB PARA AUXILIAR OS


MORADORES DAS REPÚBLICAS ESTUDANTIS DE
OURO PRETO NA AUTOGESTÃO DAS MESMAS

Monografia apresentada ao Curso de Bachare-


lado em Ciência da Computação da Univer-
sidade Federal de Ouro Preto como requisito
parcial para a obtenção do grau de Bacharel em
Ciência da Computação.

THIAGO ANTÔNIO DA BOA VIAGEM LIMA

Ouro Preto
Julho de 2016
2
Resumo
Morar com muitas pessoas pode ser complicado e muitas vezes gera
desentendimentos, principalmente quando as pessoas se envolvem em muitas
atividades, como é o caso dos moradores das repúblicas estudantis de Ouro Preto. As
repúblicas consomem certo tempo de seus moradores, seja para manter a organização e
bom convívio ou para simplesmente criar novos laços de amizades. Diante deste
cenário, este trabalho propõe um sistema Web para ajudar os moradores dessas
repúblicas na auto gestão das mesmas. Especificamente, o sistema ajuda os moradores
na distribuição de tarefas e na organização de todo o processo da reunião, pautando as
discussões e finalizando as conclusões das mesmas na ata. Além disso, o sistema
oferece uma página de perfil para as repúblicas, onde elas têm um espaço para
divulgação das vagas ociosas. O sistema foi desenvolvido através de tecnologias como
Java EE, Framework Spring MVC e Bootstrap, usando a metodologia eXtreme
Programming (XP).

3
Abstract
Live with a lot of people can be complicated and oftentimes cause
misunderstandings, mainly when the people engage in many activities, as is the case of
the residents of the Ouro Preto fraternities. The fraternities consume certain time of its
residents, is to keep the organization and good living or to simply create new
friendships ties. On this scenario, this paper proposes a Web system to help the
residents of these fraternities in self-managed of these. Specifically, the system helps the
residents in the tasks distribution and organization of the entire meeting process, guided
discussions and finalizing the conclusions of the same in record. In addition, the system
offers a profile page for the fraternities, where they have a space for dissemination of
unfilled vacancies. The system was developed through technologies like Java EE,
Spring Framework MVC and Bootstrap using the eXtreme Programming methodology
(XP).

4
Agradecimentos
Gostaria de agradecer o apoio e paciência que minha família teve comigo
durante esse tempo, a todos os meus amigos que ajudaram testando o sistema
desenvolvido neste trabalho, a prof. Amanda que me incentivou a fazer algo maior do
que imaginava, e a pensar grande. E claro gostaria de agradecer a Netflix, que me
proporcionou momentos de descontração e lazer durante este tempo, corroborando para
o desenvolvimento deste trabalho.

5
Sumário

Lista de Figuras ........................................................................................................................... 8


Lista de Tabelas ........................................................................................................................... 9
Capítulo 1 ................................................................................................................................... 10
Introdução.................................................................................................................................. 10
1.1. Definição do Problema e Justificativa ..................................................................... 10
1.2. Objetivo geral e Objetivos específicos ..................................................................... 11
1.3. Organização do documento ...................................................................................... 12
Capítulo 2 ................................................................................................................................... 13
Fundamentação Teórica ........................................................................................................... 13
2.1. Ferramentas de desenvolvimento............................................................................. 13
2.1.1. Java Enterprise Edition .................................................................................... 13
2.1.2. Hibernate............................................................................................................ 14
2.1.3. Arquitetura MVC e o Framework Spring ...................................................... 15
2.1.4. Bootstrap ............................................................................................................ 16
2.1.5. Metodologia XP - eXtreme Programing .......................................................... 16
2.1.6. Estudo de usabilidade: Avaliação SUS ............................................................ 18
2.2. Trabalhos relacionados ............................................................................................. 20
Capítulo 3 ................................................................................................................................... 24
Desenvolvimento ........................................................................................................................ 24
3.1. Pesquisa de mercado ................................................................................................. 24
3.2. Extração de requisitos ............................................................................................... 26
3.3. Modelagem da arquitetura do Sistema ................................................................... 29
3.3.1. Configurações .................................................................................................... 29
3.3.2. Modelos .............................................................................................................. 30
3.3.3. Apresentação...................................................................................................... 34
3.3.4. Controlador........................................................................................................ 40
Capítulo 4 ................................................................................................................................... 41
Avaliação do sistema ................................................................................................................. 41
4.1. Criação de usuário e república................................................................................. 41
4.2. Simular administrador do sistema........................................................................... 42
4.3. Gerência de tarefas.................................................................................................... 43

6
4.4. Gerência de reuniões ................................................................................................. 43
4.5. Pesquisa de repúblicas .............................................................................................. 44
Capítulo 5 ................................................................................................................................... 45
Considerações finais .................................................................................................................. 45
Apêndice A ................................................................................................................................. 47
Pesquisas de mercado ............................................................................................................... 47
A.1. Pesquisa sobre o funcionamento do sistema republicano ........................................ 47
A.2. Pesquisa sobre o perfil republicano ........................................................................... 48
Apêndice B ................................................................................................................................. 50
Planos de teste ............................................................................................................................ 50
B.1. Plano de teste I - Criação de usuário e república ..................................................... 50
B.2. Plano de teste II - Simular Administrador do sistema ............................................. 51
B.3. Plano de teste III – Gerenciar tarefas ........................................................................ 52
B.4. Plano de teste IV – Gerenciar reuniões...................................................................... 53
B.5. Plano de teste V – Pesquisa de repúblicas ................................................................. 54
Referência Bibliografia ............................................................................................................. 55

7
Lista de Figuras
Figura 2.1: Fluxo de requisição da arquitetura MVC .................................................................. 15

Figura 3.1: Atividades realizadas ................................................................................................ 24


Figura 3.2: Diagrama de camadas da aplicação .......................................................................... 30
Figura 3.3: Diagrama Entidade relacionamento .......................................................................... 32
Figura 3.4: Página de pesquisa de repúblicas. A pesquisa pode ocorrer por nome e localidade da
república, além disso, a exibição pode ser dar no mapa ou através de uma lista. ....................... 35
Figura 3.5: Essa é a página de perfil de uma república. Através dela as repúblicas podem
divulgar vagas, exibir informações de contato (inclusive localização no mapa), além de mostrar
os membros que fazem parte da mesma. ..................................................................................... 35
Figura 3.6: Tela com a lista de todos os membros. Essa visão é do administrador do sistema, que
tem a opção de deletar e editar os membros cadastrados. ........................................................... 36
Figura 3.7: Esta tela pode ser acessada através do item ajustes no sub menu República. Sua
função é controlar o nível de acesso dos usuários cadastrados no sistema, outra funcionalidade
seria ajustar os membros por ordem de hierarquia. ..................................................................... 36
Figura 3.8: Visão de um usuário administrador do sistema, que tem a opção de editar todas as
informações que aparecem na página de perfil da república, como informações de vagas,
informações de contato entre outras. ........................................................................................... 37
Figura 3.9: Tela para adicionar tarefas. Perceba que as algumas informações já vêm
preenchidas, como data de inicio e supervisor, que geralmente é membro que está adicionando a
tarefa............................................................................................................................................ 37
Figura 3.10: Visão de um usuário do sistema com lista de tarefas em sua responsabilidade. Ele
tem a opção de marcar a tarefa como finalizada. ........................................................................ 38
Figura 3.11: Visão de um usuário administrador do sistema com a lista das últimas reuniões da
república. Ele tem a opção de deletar a reunião, além de ver a pauta e atas da mesma. ............. 38
Figura 3.12: Esta é a tela da pauta de uma reunião especifica. A cor das letras dos itens esta
verde pelo fato de todos os itens já terem sido discutidos. Não é possível apagar ou editar os
itens pelo fato de a reunião já ter acontecido. ............................................................................. 39
Figura 3.13: Esta é a tela da ata de uma reunião especifica. Não é possível apagar ou editar
nenhum item da ata, pelo fato de a reunião já ter acontecido. A única opção de cada item da ata
é deixar, ou não, visível à informação para que o calouro possa ler. .......................................... 39

8
Lista de Tabelas
Tabela 2.1: Comparação das funcionalidades entre os trabalhos relacionados ........................... 23

Tabela 3.1: Requisitos funcionais para usuários não cadastrados no sistema ............................. 27
Tabela 3.2: Requisitos funcionais do módulo tarefas.................................................................. 27
Tabela 3.3: Requisitos funcionais do módulo repúblicas ............................................................ 27
Tabela 3.4: Requisitos funcionais do modulo reunião ................................................................ 28
Tabela 3.5: Requisitos não funcionais do sistema ....................................................................... 29

Tabela 4.1: Avaliação SUS para o plano de teste I ..................................................................... 42


Tabela 4.2: Avaliação SUS para o plano de teste II .................................................................... 42
Tabela 4.3: Avaliação SUS para o plano de teste III................................................................... 43
Tabela 4.4: Avaliação SUS para o plano de teste IV .................................................................. 43
Tabela 4.5: Avaliação SUS para o plano de teste V .................................................................... 44

9
Capítulo 1
Introdução

As repúblicas estudantis de Ouro Preto são bem diferentes das demais repúblicas
estudantis do país. Estas repúblicas em sua maioria apresentam um sistema hierárquico
quase que semelhante ao sistema hierárquico empresarial, i.e, cada membro da
hierarquia presta contas para seu superior. Assim como em empresas as repúblicas
também realizam reuniões com frequência, onde decisões são tomadas para definir o
futuro das mesmas. Outra semelhança entre as repúblicas de Ouro Preto e o sistema
Empresarial, esta relacionado ao recrutamento de novos membros.

Para fazer parte da república, o calouro passa por um processo semelhante ao


processo de trainee das empresas, a fim de traçar o perfil do mesmo e ver seu
desempenho em tarefas básicas do dia a dia de uma república. Porém a quantidade de
pessoas que chegam ao final deste processo representa um número bem pequeno, o que
faz com que as repúblicas gastem bastante tempo e dinheiro com divulgação das vagas
remanescentes.

Essas semelhanças com o sistema empresarial se dão de forma simplificada, e


apresentam peculiaridades, o que torna a gestão de repúblicas controladas por softwares
empresariais inviável, além de complexa.

1.1. Definição do Problema e Justificativa

As repúblicas estudantis de Ouro Preto possuem um sistema atípico no qual os


membros dessas repúblicas são classificados em: ex-alunos, moradores e bichos. Os ex-
alunos são membros já graduados e que moraram em uma dessas repúblicas durante sua
fase da graduação, os moradores são membros que já passaram pelo processo de
aceitação da república a qual fazem parte e os bichos são membros em fase de
aceitação, comparável aos estagiários ou trainees das empresas atualmente.

10
Para identificar os problemas enfrentados pelas repúblicas estudantis de Ouro
Preto e seus respectivos membros, duas pesquisas de opinião foram realizadas1 no
âmbito deste trabalho, sendo 20 representantes de republicas na primeira pesquisa e 48
moradores de repúblicas falando de suas experiências na mesma. O resultado das
pesquisas em linhas gerais mostra que os moradores das repúblicas estudantis de Ouro
preto se sentem ou já se sentiram mais sobrecarregados de tarefas da casa do que os
demais membros. A pesquisa também mostrou que existe falta de comunicação entre
estes republicanos.

Outro problema enfrentado pelos republicanos, esta relacionado à alta evasão


por parte dos calouros recém-egressos nessas repúblicas. A UFOP soltou nota no jornal
“O Tempo” em 2014, afirmando haver 180 vagas de moradias nas repúblicas federais.
Apesar de haver inúmeros motivos para essa evasão, isso não tira o trabalho incessante
que os moradores dessas repúblicas têm na divulgação dessas vagas. Para preenchê-las é
necessário investir tempo e dinheiro.

Todos esses problemas mostram a falta de eficiência das repúblicas estudantis de


Ouro Preto em relação aos processos de gestão das mesmas. Para desenvolver uma
solução para os problemas mencionados, uma pergunta se faz necessária:

Como tornar mais eficiente o gerenciamento das atividades da república no que


tange a distribuição de tarefas, compartilhamento de atas e divulgação das vagas?

A hipótese que encoraja o desenvolvimento deste trabalho se baseia em um


sistema web para tornar mais eficiente à distribuição de tarefas, o compartilhamento de
atas e divulgação de vagas remanescentes das repúblicas estudantis de Ouro Preto.

1.2. Objetivo geral e Objetivos específicos

O objetivo deste trabalho se concentra em desenvolver um sistema web para


gerenciar as informações criadas a partir das atividades dentro de repúblicas estudantis
do município de Ouro Preto, assim como facilitar o processo de divulgação de vagas das
_____________________________
1
Os questionários usados na pesquisa são especificados no anexo A deste trabalho, e discutidos em mais
detalhes na seção 3.1.

11
mesmas.
A gestão proposta se baseará em um sistema web multiusuário, onde será
possível controlar as atividades dos membros ativos da república. O sistema
denominado FeedBack terá como premissa, conceitos como segurança das informações
e fácil interação com o usuário.

Dentre os objetivos específicos, temos:

 Identificar melhorias no processo de delegação de tarefas;


 Facilitar a transmissão de informações geradas a partir de reuniões;
 Facilitar controle de informações para tomada de decisões;
 Facilitar o processo de divulgação de vagas;

1.3. Organização do documento


O restante deste trabalho é organizado da seguinte forma: Capítulo 2 trata da
fundamentação teórica exigida para realizar este trabalho, abordando as principais
ferramentas de desenvolvimento utilizadas e trabalhos relacionados. O Capítulo 3
aborda o desenvolvimento do trabalho, dando ênfase nas pesquisas de mercado
realizadas, extração de requisitos e modelagem da arquitetura do sistema. O Capítulo 4
mostra como foi construído os planos de teste para verificar a usabilidade do sistema
web proposto, além de fazer uma análise dos testes realizados pelos usuários. O
Capítulo 5 discute os resultados dos testes de usabilidade, confrontando com os
objetivos específicos.

12
Capítulo 2
Fundamentação Teórica
Este capítulo descreve conceitos e definições assim como tecnologias utilizadas neste
trabalho na Subseção 2.1. Também é detalhado o estudo de trabalhos correlatos, a fim
de apresentar uma comparação com a abordagem proposta na Subseção 2.2.

2.1. Ferramentas de desenvolvimento


A qualidade deste trabalho esta intrinsecamente ligada às ferramentas que foram
utilizadas para desenvolvê-lo. Abaixo, temos as razões pela qual cada ferramenta foi
escolhida assim como as qualidades de cada uma destacadas.

2.1.1. Java Enterprise Edition


Java é hoje uma das linguagens mais populares do mundo, e sua comunidade de
desenvolvedores não para de crescer, o que torna muito fácil a obtenção de materiais de
estudo, além de sua ampla biblioteca para diversos tipos de aplicações.

Java Enterprise Edition mais conhecido como JEE, é uma plataforma robusta
desenvolvida para aplicações web de grande porte, com o intuito de controlar todo o
ciclo de vida das mesmas. Esse controle do ciclo de vida da aplicação garante certa
segurança da aplicação em certos aspectos, como o banco de dados por exemplo. Outras
características que o JEE oferece além da segurança são: escalabilidade e integridade do
sistema [22].

A plataforma Java EE funciona através de contêineres, que tem a função de


facilitar a vida do programador, de forma a manter o mesmo ocupado apenas com os
requisitos funcionais da aplicação. Os contêineres do Java EE se responsabilizam por
requisitos não funcionais como gerenciamento de threads, transações, persistência no
banco de dados entre outros, como explicitado em [1].

Algumas das tecnologias da plataforma Java EE utilizadas neste trabalho são


explicadas abaixo, de acordo com [1].

13
 JavaServer Pages – É também conhecida como JSP. Essa tecnologia permite
colocar trechos de código servlet em uma página escrita em HTML [1].
 JavaServer Pages Standard Tag Library – Para o código ficar mais legível e
de fácil manutenção, foram criadas as taglibs, que encapsulam as
funcionalidades comuns das aplicações, como verificações condicionais,
iterações entre outros. A intensão é escrever códigos que tornem as páginas
dinâmicas e que sejam similares às tags HTML, sem impactar na legibilidade
do código [1].
 Java Persistence API – Também conhecida como JPA, essa ferramenta
utiliza a abordagem de mapeamento objeto-relacional para persistir dados.
Uma das vantagens dessa ferramenta esta relacionada à sua habilidade de
trabalhar com qualquer banco de dados, i.e, ela consegue efetuar suas tarefas
sem a necessidade de escrever linhas de código SQL [21].

2.1.2. Hibernate
Hibernate é um framework baseado no mapeamento objeto-relacional, utilizado
para realizar consultas e persistir dados em um banco de dados em aplicações Java
como especificado em [3].

O mapeamento objeto-relacional faz uma ponte através das incompatibilidades


de classes orientadas a objetos e de suas respectivas representações nas tabelas
relacionais do banco de dados como explicado em [2].

A Hibernate Query Language é a linguagem própria para manipulação de dados


(DML) do Hibernate, através dela é possível, inserir, alterar, remover e pesquisar dados
em qualquer banco de dados, dando total liberdade para o desenvolvedor como
demostrado em [3].

O Hibernate, como uma das implementações do JPA foi utilizado neste trabalho
apenas para realizar consultas, já que através do JPA é possível realizar a persistência de
forma muito mais simples e com quantidade de código bem inferior.

14
2.1.3. Arquitetura MVC e o Framework Spring
O padrão Model View Controller, ou MVC, é muito utilizado em aplicações web
por sua capacidade de fácil manutenção do código, que esta relacionada às suas três
representações operacionais, como destacado em [5].

Figura 2.1: Fluxo de requisição da arquitetura MVC

O fluxo da troca de informações entre as representações mostrada na Figura 2.1


começa com o cliente realizando alguma requisição ao controlador, responsável por
toda a lógica de negócios. O controlador por sua vez e quando necessário, se utiliza de
classes responsáveis pela manutenção e representação do banco de dados a qual é
denominada modelo, para retornar um objeto que representa uma entidade no banco de
dados. Com o objeto em mãos, o controlador retorna este objeto ou parte dele para a
camada de apresentação, que decide como esses objetos serão mostrados para o usuário.
Ao final a camada de apresentação devolve uma página em HTML e/ou JavaScript para
o cliente.

Ladd frisa em [4] que o framework Spring MVC foi construído em cinco
camadas de abstração com base no padrão MVC. Ele explica que a intensão dessas
camadas é isolar o domínio do problema, como a persistência, navegação web e
interface do usuário, para criar uma aplicação flexível e testável.

15
“Esse isolamento é conquistado por minimizar a quantidade de dependências
entre as camadas. Quanto menor a dependência de que uma camada tem sobre
ela mesma, menor será o custo para altera-la.” (Ladd et al, 2006, p. 23)

As dependências se dão quando objetos têm a necessidade de serem instanciados


em outras classes, aumentando o grau de acoplamento entre as mesmas. Para resolver
esse problema o Spring MVC utiliza um contêiner de injeção de dependência. Esse
contêiner tem a responsabilidade de instanciar objetos e conectar as dependências da
aplicação, de modo que as classes que dependem de outras, possam se utilizar dos
objetos instanciados pelo contêiner, usando apenas a declaração dos mesmos como
destacado em [4].

O Spring MVC é um framework que teve o inicio de seu desenvolvimento em


2002, e hoje conta com uma grande comunidade de usuários, além de facilitar o
desenvolvimento de aplicações web através de injeções de dependência e possuir
implementação do padrão MVC.

2.1.4. Bootstrap
Bootstrap é um framework criado pela equipe do twiter para padronizar e
facilitar o desenvolvimento front-end [27]. O Bootstrap possui um conjunto de
componentes estilizados através de CSS (Cascading Style Sheets) de modo a tornar o
desenvolvimento do front-end muito mais elegante e agradável aos olhos do usuário. O
desenvolvedor precisa ter apenas um pouco de criatividade para relacionar os
componentes corretamente de forma a melhorar a experiência do usuário.

Alguns dos componentes CSS do Bootstrap trabalham em conjunto com código


javaScript, o que torna o desenvolvimento front-end ainda mais fácil, como é o caso do
componente pronto “carrossel” (componente para exibição de slides de imagens).

2.1.5. Metodologia XP - eXtreme Programing


Uma metodologia de desenvolvimento de software é um conjunto de atividades
que auxiliam a produção de software, resultando em um produto que reflete a forma
como todo o processo foi conduzido, conforme introduz Koscianski em [11].

16
As metodologias ágeis adotadas neste trabalho para gestão e planejamento do
desenvolvimento da solução proposta, se diferenciam das demais metodologias de
desenvolvimento de software por dar enfoque nas pessoas. Outro fator diferencial esta
em gastar menos tempo com documentação [13]. As metodologias ágeis são
adequadas para situações em que a mudança de requisitos é frequente, e para ser
realmente considerada ágil, a metodologia deve aceitar a mudança e se adequar para
atender os requisitos. Dentre as varias metodologias ágeis existentes, as mais
conhecidas são a Extreme Programming (XP) e a Scrum, conforme apresentado em
[11].

Em [12] o XP é destacado como metodologia que usa uma abordagem orientada


a objetos como seu paradigma de desenvolvimento predileto. O XP inclui um conjunto
de regras e práticas que ocorrem no contexto de quatro atividades de arcabouço, são
elas: planejamento, projeto, codificação e teste.

(Pressman, 2006, p. 63) explica as quatro atividades:

 Planejamento: A atividade de planejamento começa com a criação de um


conjunto de histórias (também chamado de histórias de usuário) que
descrevem as características e funcionalidades requeridas para o software a
ser construído.

 Projeto: O projeto XP segue rigorosamente o principio KIS (Keep it simple –


mantenha a simplicidade). Um projeto simples é sempre preferível em
relação a uma representação mais complexa.

 Codificação: O XP recomenda que depois que as histórias forem


desenvolvidas e o trabalho preliminar de projeto for feito, a equipe não
avance para o código, mas, em vez disso, desenvolva uma série de testes
unitários que exercitarão cada uma das histórias que devem ser incluídas na
versão atual.

17
 Teste: Os testes unitários que são criados devem ser implementados usando
um arcabouço que lhes permita ser automatizados. Isso encoraja uma
estratégia de teste de regressão sempre que o código é modificado.

2.1.6. Estudo de usabilidade: Avaliação SUS


Em meio a diversas ferramentas tecnológicas disponibilizadas no mercado atual,
medir a usabilidade de um sistema, torna-se cada vez mais interessante para as equipes
de desenvolvimento, visto que, é uma maneira efetiva de aplicar recursos visando
alcançar melhorias efetivas no produto avaliado.

“A usabilidade é um atributo de qualidade relacionado a facilidade do uso de algo.


Mais especificamente, refere-se à rapidez com que os usuários podem aprender a usar
alguma coisa, a eficiência deles ao usa-lá, o quanto lembram daquilo, seu grau de
propensão a erros e o quanto gostam de utilizá-la. Se as pessoas não puderem ou
utilizarem um recurso, ele pode muito bem não existir.” (Nilsen, p. 16, 2007)

Proposto em 1986, por John Brooke, o System Usability Scale (SUS), ou Sistema
de Escala de Usabilidade é uma ferramenta que possibilita medir o nível de usabilidade
de produtos, softwares, web sites, aplicações, dentre outros.

O SUS é composto basicamente de uma lista com 10 itens, sendo que, os itens
ímpares são redigidos num contexto positivo e os itens pares num contexto negativo
como seguem:

1. Acho que eu gostaria de usar este sistema com frequência;


2. Achei o sistema desnecessariamente complexo;
3. Acho o sistema fácil usar;
4. Acho que iria precisar de apoio técnico para ser capaz de usar este sistema;
5. Achei as diversas funções deste sistema bem integradas;
6. Achei o sistema muito inconsistente;
7. Acredito que a maioria das pessoas aprenderia a usar o sistema rapidamente;
8. Achei o sistema muito complicado de usar;
9. Senti-me muito confiante usando o sistema;
10. Precisei aprender muitas coisas antes de começar a usar o sistema
completamente.

18
Finalizando as avaliações com base na lista de itens acima, tem-se uma
interpretação de pontuação complexa, pois, segundo USABILITY.GOV em [14] as
pontuações do participante para cada pergunta são convertidos para um novo número,
somados e, em seguida, multiplicado por 2,5 para converter as partituras originais de 0-
40 para 0-100, a partir daí obtém-se um resultado final para o questionário.

As pesquisas indicam que a média de pontos é 68, isso significa que qualquer
resultado acima de 68 tem uma usabilidade que varia de boa a ótima, e qualquer
resultado abaixo de 68 tem uma usabilidade que varia de regular a fraca. Entre os
benefícios da utilização do SUS para a verificação do nível de usabilidade de um
sistema, três deles são destacados a seguir de acordo com [14]:

 É uma escala muito fácil de ser aplicada aos participantes;


 Pode ser usado em pequenos tamanhos de amostras com resultados confiáveis;
 É válido – pode-se efetivamente diferenciar os sistemas utilizáveis e não
utilizáveis.

Além dos benefícios anteriormente citados, Lewis e Sauro em [15] destacam que
o SUS tem resistido ao teste do tempo, tornando-se uma ferramenta altamente
significativa para o mercado. Os autores enfatizam que os profissionais que usam o SUS
devem continuar a fazê-lo, e, além disso, devem reconhecer que além de trabalhar com
a pontuação SUS geral padrão, pode-se decompor a mesma em seus componentes de
usabilidade e capacidade de aprendizado, extraindo informações adicionais a partir de
seus dados com pouco esforço adicional.

De acordo com Brooke em [17] a capacidade de utilização de qualquer


ferramenta ou sistema deve ser vista em termos do contexto em que é utilizada, e a sua
adequação a este contexto em que esta ferramenta está inserida, principalmente quando
se trata de sistemas de informação.

Ainda segundo Brooke em [17], quando a usabilidade é mensurada, deve-se


cobrir os seguintes aspectos:

 Eficácia - capacidade dos usuários para completar as tarefas que utilizam o


sistema e a qualidade da saída dessas tarefas;
 Eficiência - nível de recurso consumido na realização de tarefas;
 Satisfação - reações subjetivas dos usuários para utilizar o sistema.
19
O SUS destaca-se como, uma ferramenta amplamente utilizada, aspecto que
Brooke enfatiza em [16] que o SUS já se tratava de “um valioso instrumento de
avaliação, sendo robusto e fiável”.

2.2. Trabalhos relacionados


Esta seção trata dos trabalhos relacionados que apoiam funcionalidades básicas do
sistema FeedBack, a saber: gerenciamento de tarefas, gerenciamento de reuniões e
divulgação de vagas. As características essenciais das soluções relacionadas são
destacadas, sendo também apresentada uma tabela comparativa destas soluções (Tabela
2.1).

Todoist [6] é um serviço online de gerenciamento de tarefas e projetos com


ótima aceitação do mercado. Ele permite criar tarefas e subdividi-las assim como os
projetos de modo a aumentar a produtividade. Também e possível compartilhar a tarefa
ou projeto com outros usuário de forma a gerenciar o trabalho de sua equipe. As tarefas
podem receber prioridades diferentes, para que o usuário possa focar no que é mais
importante, além de datas de vencimento, notificando o usuário por e-mail quando as
mesmas estiverem perto do prazo de final. O serviço também atribui pontos aos
usuários, usando uma estratégia de gamificação [24], sendo possível avaliar a
produtividade destes com bases nestes pontos.

Runrunit [7] é um serviço de gerenciamento de tarefas para empresas com o


poder de controlar grandes equipes. Este serviço permite saber exatamente em que cada
membro da equipe esta trabalhando, e como o Todoist, ele permite a criação de itens
para a divisão de tarefas, estipular prioridades, além de datas de entrega de cada tarefa e
mensuração de produtividade baseada no tempo de entrega das mesmas. Em cada tarefa
é possível adicionar comentários e arquivos. O Runrunit também possui relatórios e
gráficos para ajudar na tomada de decisões do gerenciamento da equipe.

O Wunderlist [8] assim como os serviços acima tem a função de gerenciar


tarefas e apesar de possuir as mesmas funcionalidades, ele foi desenvolvido para
trabalhar com equipes menores. Com o Wunderlist é possível criar tarefas, subdividi-
las, aplicar prioridades em cima das mesmas, criar prazos de entrega assim como
receber notificações com base nestes prazos. Com o Wunderlist também é possível

20
compartilhar uma lista de tarefas com uma equipe, porém o software não dá a
possibilidade de mensurar a produtividade da equipe ou de cada individuo dela.

EATA [9] é um serviço online para gestão de reuniões, com o objetivo de tornar
as reuniões mais produtivas e transparentes. O usuário começa por descrever uma pauta,
agendar a data da reunião e convidar os participantes. Durante a reunião é possível
gravar áudio e vídeo, controlar pauta, votações e presença. Após o término da reunião, o
EATA dá a possibilidade do usuário de transcrever os áudios para a ata, além de
armazena-las juntamente com as gravações disponibilizando este conteúdo online.

AgreeDO [18] é uma ferramenta online para gestão de reuniões, com o objetivo
de tornar as reuniões mais objetivas e transparentes. Com este serviço, todos os
participantes que foram convidados por email podem adicionar itens à pauta, além
disso, o sistema também possui um sistema de busca que permite encontrar conteúdos
de reuniões anteriores, tornando a reunião mais produtiva. O AgreeDo também permite
atribuir tarefas com data limite aos membros da reunião, essas tarefas podem ser
compartilhadas com outros membros ou não.

MorarUFLA [19] é uma ferramenta online que foi desenvolvida para divulgar
vagas dentro da Universidade Federal de Lavras, com o intuito de gerar concorrência
entre as imobiliárias afim de garantir melhores preços e serviços. A ferramenta possui
vários filtros de pesquisa para as vagas como sexo, limite de preço, palavras chave e
tipo de moradia (república, pensionatos, casas, kitnets e apartamentos). Também é
possível ver a localização das moradias em um mapa do GoogleMaps.

Repúblicas do Brasil [20] é uma ferramenta online para quem quer divulgar
anúncios de vagas de moradia, tanto para quem oferece quanto para quem busca. A
ferramenta é bem ampla no quesito tipo de moradia, sendo possível anunciar desde
vagas em Albergues e Hostels até vagas em casas de família. A ferramenta também dá a
possibilidade de comunicação entre usuários que buscam ou ofertam vagas. Porém a
pesquisa por vagas no site é bem limitada, sendo possível pesquisar apenas por cidade.
Além disso a interface do site é bem fraca e confusa apesar de ter uma quantidade
significativa de usuários.

A Tabela 2.1 mostra o conjunto disjunto de todas as funcionalidades básicas que


compõem alguns dos trabalhos citados acima comparando estes com o sistema
proposto. A comparação foi realizada apenas quanto à possibilidade de se efetuar as
21
operações e não levou em consideração a qualidade das soluções propostas. O
diferencial da solução proposta se concentra em apoiar um sistema que agrupa um
conjunto de funcionalidades em apenas um software, de forma a integrar algumas
dessas funcionalidades facilitando a vida do usuário final.

22
Tabela 2.1: Comparação das funcionalidades entre os trabalhos relacionados

MorarUFLA

Repúblicas
Wunderlist

FeedBack
Runrun.it

AgreeDo

do Brasil
Todoist

EATA
Criação de tarefas X X X X X
Subdivisão de tarefas X X X
Trabalhar em equipe X X X X X
Aplicação de prioridade nas
X X X
tarefas
Notificação por e-mail de
X X X X
tarefas a vencer
Avaliação de produtividade
X X X
das tarefas
Descrição de pauta de
X X X
reuniões
Pauta Colaborativa X X
Agendamento de reunião X X X
Convidar participantes para
X X X
reuniões
Gravar áudio e vídeo de
X
reuniões
Controle de pauta de
X X X
reuniões
Controle de votação de
X X
reuniões
Controle de presença de
X X
reuniões
Transcrição de áudio para a
X
ata
Disponibilizar a ata online X X X
Sistema de busca de
X
Conteúdo de atas
Ofertar anúncio de vagas X X X
Localização no Mapa X X X

Comunicação entre usuários X

Sistema de busca de vagas X X

Página personalizada do
X X
anunciante de vagas

23
Capítulo 3
Desenvolvimento
As Etapas de realização deste trabalho são brevemente descritas na Figura 3.1.
Cada uma das atividades foi quebrada em sub tarefas para que fosse possível a
realização deste trabalho, que teve sua implementação segunda diretrizes do XP
(eXtreme Programming). As seções de desenvolvimento são explicadas em mais
detalhes abaixo.

Fundamentação Desenvolvimento Avaliação do


Teórica sistema

Estudo das ferramentas Pesquisa de Mercado Construção dos planos


de desenvolvimento de testes

Estudo de trabalhos Extração de requisitos


correlacionados Aplicação do método de
avaliação SUS

Modelagem da
Estudo de metodologias
arquitetura do sistema
de desenvolvimento e
avaliação de software Analise aprofundada

Implementação do
sistema

Figura 3.1: Atividades realizadas

3.1. Pesquisa de mercado


Duas pesquisas de opinião foram realizadas neste trabalho. A primeira pesquisa
(encontrada no Apêndice A.1) foi efetuada com um morador de cada república, de um
total de 20 repúblicas, variando entre particulares e federais de ambos os sexos, com o
propósito de levantar os problemas relacionados ao processo de gestão usados por essas
repúblicas. A segunda pesquisa foi realizada com 48 moradores de repúblicas, também
variando a amostra entre particulares e federais de ambos os sexos, com a intensão de
levantar os problemas enfrentados pelos moradores dessas repúblicas.

24
A primeira pesquisa mostrou que em 55% das repúblicas, quando uma tarefa é
alocada a um dos moradores, não existe responsável por realizar posterior cobrança
dessa tarefa, ou seja, nada garante que a tarefa será realizada. A primeira pesquisa
também mostrou que em 90% das repúblicas os calouros não participam das reuniões e
em 75% delas, esses calouros não tem acesso às atas das reuniões. O que se conclui é
que os calouros ficam prejudicados, já que nem sempre estão a par das discussões.

Gráfico 3.1: Os calouros participam de todas as reuniões na sua república?

A segunda pesquisa mostrou que 41,7% acham a distribuição de tarefas entre os


moradores de sua república injusta e 70,8% já se sentiu mais sobrecarregado de tarefas
do que os demais moradores de sua casa. Das 20 repúblicas entrevistadas, 55% não têm
politica de cobrança das tarefas entre os moradores das mesmas, havendo cobrança
apenas dos calouros, o que demonstra uma deficiência no sistema republicano, já que os
moradores têm a escolha de realizar ou não a tarefa.

Gráfico 3.2: Você acha a distribuição de tarefas entre os moradores da sua


república justa?

25
Gráfico 3.3: Como morador você já se achou mais sobrecarregado de tarefas do
que outros moradores?

A segunda pesquisa também revelou não haver boa comunicação entre os


moradores dessas repúblicas para 43,7% dos pesquisados e que apenas 48,9%
afirmaram ler as atas de reuniões com frequência. Os problemas identificados na leitura
da ata foram: a demora na confecção destes arquivos e dificuldades de acesso dos
mesmos. Quando questionados sobre os problemas enfrentados durante o processo de
aceitação na república, também conhecido como batalha, os moradores dessas
repúblicas destacaram haver má comunicação entre os moradores e calouros,
dificuldades na delegação das tarefas e conflitos de perfil dos calouros com o perfil da
república.

Gráfico 3.4: Você lê as atas das reuniões da sua república com frequência?

3.2. Extração de requisitos

A engenharia de requisitos traz todos os conceitos que abrangem os requisitos de


um software. Esses requisitos podem ser funcionais e não funcionais. Os requisitos
funcionais de um sistema estão relacionados ao que o mesmo deve realizar, i.e., dado
um conjunto de entradas para o software, quais saídas o mesmo deve produzir, levando-
se em consideração um determinado tipo de usuário. Os requisitos funcionais também
estão relacionados com o comportamento do sistema em situações particulares,
abrangendo até o que o mesmo não deveria fazer como destacado em [10].

Os requisitos funcionais do sistema Feedback foram construídos através de


histórias de usuários e são apresentados nas Tabelas 3.1, 3.2, 3.3 e 3.4, sendo cada
tabela relacionada à um módulo diferente do sistema, e uma tabela relacionada à
requisitos funcionais disponíveis para usuários não cadastrados no sistema.
26
Tabela 3.1: Requisitos funcionais para usuários não cadastrados no sistema

ID Requisitos funcionais Versão

RF001 Como republicano, gostaria de ser capaz de cadastrar minha BCC391


república no sistema.
Como republicano, gostaria de ser capaz de me cadastrar
RF002 como membro da república e usuário do sistema, afim de ter BCC391
uma página personalizada com os dados que envolvem a
mim e a minha república.
Como calouro ainda não cadastrado no sistema, gostaria de
RF003 poder utilizar um sistema de busca para pesquisar repúblicas BCC391
por localidade e por nome.
Como calouro não cadastrado no sistema, gostaria de poder
RF004 visualizar as páginas personalizadas das repúblicas BCC391
pesquisadas para saber mais sobre as mesmas.

Tabela 3.2: Requisitos funcionais do módulo tarefas

ID Requisitos funcionais Versão


Como usuário do sistema, gostaria de criar uma tarefa e
RF005 colocá-la sob minha responsabilidade ou de outros membros BCC391
da república.
Como usuário do sistema, gostaria de visualizar todas as
RF006 tarefas sob minha responsabilidade filtrando por: tarefas BCC391
pendentes ou tarefas concluídas.
RF007 Como usuário do sistema, gostaria finalizar uma das minhas BCC391
tarefas pendentes.
Como usuário do sistema, gostaria de visualizar todas as
RF008 tarefas sob minha supervisão filtrando por: tarefas pendentes BCC391
ou tarefas concluídas.
RF009 Como usuário do sistema, gostaria de finalizar tarefas sob BCC391
minha supervisão.
Como usuário do sistema, gostaria de reabrir tarefas com
RF010 novos prazos sob minha supervisão, com possibilidade de BCC391
alterar os responsáveis.

Tabela 3.3: Requisitos funcionais do módulo repúblicas

ID Requisitos funcionais Versão


RF011 Como usuário do sistema, gostaria de adicionar um membro BCC391
ao sistema.
RF012 Como administrador do sistema, gostaria de ordenar os BCC391
membros por hierarquia.

27
RF013 Como usuário do sistema, gostaria de alterar meus dados de BCC391
usuário e membro no sistema.
Como usuário do sistema, gostaria de utilizar um sistema de
RF014 busca de membros da minha república, filtrando por: nome, BCC391
apelido e tipo de membro.
RF015 Como usuário do sistema, gostaria de visualizar o perfil de BCC391
outros membros da minha república.
Como usuário administrador do sistema, gostaria de aceitar
RF016 ou deletar solicitações de membros cadastrados por usuários BCC391
do sistema da minha república.
Como administrador do sistema, gostaria de ser capaz de
RF017 gerenciar contas de usuários da minha república aplicando o BCC391
nível de acesso correto para cada membro.
Como administrador do sistema, gostaria de ser capaz de
RF018 personalizar a página da minha república para torna-la mais BCC391
atrativa para os calouros.

Tabela 3.4: Requisitos funcionais do modulo reunião

ID Requisitos funcionais Versão


RF019 Como usuário do sistema, gostaria de agendar uma reunião BCC391
na qual todos concordem com a data e horário.
RF020 Como usuário do sistema, gostaria de adicionar itens na BCC391
pauta da reunião marcada.
RF021 Como usuário do sistema, gostaria de marcar itens da pauta BCC391
que já foram discutidos.
RF022 Como usuário do sistema, gostaria de adicionar conclusões BCC391
das discussões da reunião à ata.
Como usuário do sistema, gostaria de criar uma enquete para
RF023 registrar a opinião dos membros da minha república sobre BCC391
determinado assunto.
RF024 Como usuário do sistema, gostaria de dar minha opinião BCC391
sobre determinada enquete ainda aberta.
RF025 Como usuário do sistema que criou uma enquete, gostaria de BCC391
encerrar a votação.

Os requisitos não funcionais são aplicados ao sistema como um todo, e estão


relacionados às propriedades e restrições aplicados ao mesmo como desempenho,
confiabilidade, usabilidade, segurança, tempo de resposta entre outros. Os requisitos
não funcionais estão diretamente ligados à arquitetura de software e por isso são mais
críticos do que os requisitos funcionais; uma vez ignorados eles podem levar o sistema à
inutilidade como explicado em [10]. Para garantir a qualidade e eficiência do sistema,
alguns destes requisitos não funcionais foram listados na Tabela 3.5.

28
Tabela 3.5: Requisitos não funcionais do sistema

ID Requisitos não funcionais Versão


RNF001 Como usuário do sistema, gostaria de ter um tempo de BCC391
resposta rápido.
Como usuário do sistema, gostaria que meus dados e os
RNF002 dados da minha república fossem armazenados em BCC391
segurança, impedindo o acesso destes dados de cunho
privativo por parte de outrem.
Como usuário do sistema, gostaria que o mesmo fosse
RNF003 portátil, dando a possibilidade de efetuar operações do site BCC391
através do meu celular.
RNF004 Como usuário do sistema, gostaria que o mesmo oferecesse BCC391
uma interface intuitiva e agradável, facilitando o meu uso.
RNF005 Como desenvolvedor, gostaria de assegurar boa BCC391
manutenibilidade do software.

3.3. Modelagem da arquitetura do Sistema

A arquitetura do sistema retrata a organização estrutural do software em


componentes e como esses componentes se comunicam entre si. A arquitetura do
sistema deve ser pensada com cuidado para garantir o desempenho esperado do sistema,
assim como a manutenibilidade do mesmo como destacado em [10]. Alguns dos
requisitos não funcionais do sistema proposto neste trabalho foram conquistados com a
arquitetura mostrada na Figura 3.2, que mostra como os componentes dos módulos do
sistema FeedBack estão divididos entre as camadas da arquitetura MVC. A Figura 3.2 é
explicada em mais detalhes nas seções seguintes.

3.3.1. Configurações

Para que todas as ferramentas trabalhem em conjunto são necessárias algumas


configurações. Nas aplicações Java EE, essas configurações são realizadas através de
um arquivo denominado web.xml. Esse arquivo é responsável por fazer a aplicação Java
EE trabalhar em conjunto com o framework Spring ou qualquer outro framework
semelhante que seja necessário na aplicação construída.

O Spring possui seu próprio arquivo de configurações, que neste trabalho foi
denominado de spring-context.xml. A princípio foi habilitado o recurso de anotações
dentro do código java, para tornar a configuração da aplicação mais dinâmica. As
29
anotações podem ser utilizadas com a configuração abaixo no arquivo spring-
context.xml:

<mvc:annotation-driven />

Figura 3.2: Diagrama de camadas da aplicação

Em seguida é configurado o local onde estão armazenados os arquivos


responsáveis pela camada de apresentação, assim como a extensão desses arquivos:

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property value="/WEB-INF/views/" name="prefix"/>
<property value=".jsp" name="suffix"/>
</bean>

Também é necessário estabelecer, onde serão encontrados as classes base do


projeto, i.e., as classes responsáveis pela logica de negócios.

<context:component-scan base-package="br.com.feedback.controller"/>

3.3.2. Modelos
Em Java EE utilizamos JavaBeans para modelar uma entidade e seu
comportamento. JavaBeans são classes com um construtor sem argumentos, além de
30
getters e setters; que representa uma entidade do banco de dados. A classe Reuniao que
representa a entidade de mesmo nome, responsável por armazenar os dados de reuniões
marcadas pelos membros de uma república é um exemplo de JavaBean:

@Entity
@Table(name = "reuniao")
public class Reuniao {
@Id
@GeneratedValue
private int id_reuniao;
private Date data;
private Time hora;
private String assunto;
@ManyToOne
@JoinColumn(name="id_republica")
private Republicas republica;

Gets & Seters


...
}

A anotação @Entity é responsável por dizer que esta classe é uma entidade que
deve ser mapeada no banco de dados. A anotação @Table juntamente com o atributo
name diz a qual tabela a entidade pertence. A anotação @ManyToOne juntamente com
a anotação @JoinColumn é responsável por realizar o mapeamento muitos para um, i.e.,
o mapeamento que diz que existem muitas reuniões para uma república.
Todas as entidades e seus relacionamentos podem ser vistos na Figura 3.3 que
representa o diagrama ER. O diagrama apresenta a entidade membro como centro de
todo o banco de dados, colocando sobre a mesma, responsabilidades como:
realizar/supervisionar tarefas, sugerir enquetes e itens de discussões na pauta da reunião,
dar opinião em uma votação. Além disso, o membro pertence a uma república e pode
ser um tipo de usuário do sistema. Uma enquete possui um ou mais itens que entram na
votação. Uma reunião pode possuir um ou vários itens de discussão na pauta assim
como um ou vários itens de conclusão na ata.
Além disso, para melhorar a manutenibilidade do código e torná-lo mais legível,
foi isolado todo o código que faz a manipulação do banco de dados em classes
apropriadas para este fim. O nome do padrão de projeto responsável por esse isolamento
é denominado Data Access Object também conhecido como DAO. A intenção é colocar
todo o código de inserção, alteração, remoção e consultas de um determinado objeto do
banco de dados nessas classes. Cabe ressaltar que o JPA possui vários métodos e classes
prontas para realizar essas tarefas com apenas algumas linhas de código, como pode ser
visto na classe ReunioDao logo abaixo.

31
Figura 3.3: Diagrama Entidade relacionamento

@Repository
public class ReuniaoDao {
@PersistenceContext
private EntityManager manager;

public void adiciona(Reuniao reuniao) {


manager.persist(reuniao);
}

public void alterar(Reuniao reuniao) {


manager.merge(reuniao);
}

public void remove(Reuniao reuniao) {


Reuniao reuniaoRemove = buscaPorId(reuniao.getId_reuniao());
manager.remove(reuniaoRemove);
}

public Reuniao buscaPorId(int id) {


return manager.find(Reuniao.class, id);
}
Consultas...

32
A anotação @Repository serve para dizer que uma classe pertence à camada de
persistência [25]. Já a anotação @PersistenceContext é utilizada para injetar o objeto
EntityManager, responsável por gerenciar objetos do tipo entidade [1].

3.3.2.1. Configurações do banco de dados no Spring e JPA

Configurações do banco de dados também são necessárias para que o Spring


possa realizar o acesso ao banco de dados, a integração do JPA com o mesmo e dizer
em quais classes o objeto EntityManager deve ser controlado para que transações sejam
realizadas de forma segura.

 Acesso ao banco de dados – é uma configuração realizada no arquivo xml do


framework Spring MVC para que o mesmo saiba como e quais informações usar
par acessar o banco de dados.

<bean class="org.apache.commons.dbcp.BasicDataSource" id="mysqlDataSource">


<property value="com.mysql.jdbc.Driver" name="driverClassName"/>
<property value="jdbc:mysql://localhost:3306/feedback" name="url"/>
<property value="root" name="username"/>
<property value="" name="password"/>
</bean>

 Gerenciamento do JPA pelo Spring – esta configuração é para dizer ao Spring


que ele deve controlar o objeto EntityManager, i.e., ele deve abrir e fechar
transações automaticamente.

<bean class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
id="entityManagerFactory">
<property name="dataSource" ref="mysqlDataSource"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"/>
</property>
</bean>

 Classes de manipulação do BD – ao dizer quais classes do projeto fazem


manipulação do banco de dados, estamos dizendo para que o Spring realize o
controle do objeto EntityManager dentro destas classes.

<bean id="taskDao" class="br.com.feedback.jdbc.dao.TarefasDao"/>


<bean id="memberDao" class="br.com.feedback.jdbc.dao.MembrosDao"/>
<bean id="userDao" class="br.com.feedback.jdbc.dao.UsuariosDao"/>
<bean id="repDao" class="br.com.feedback.jdbc.dao.RepublicasDao"/>
<bean id="sessionDao" class="br.com.feedback.jdbc.dao.ReuniaoDao"/>
<bean id="debateDao" class="br.com.feedback.jdbc.dao.PautaDao"/>
<bean id="surveyDao" class="br.com.feedback.jdbc.dao.EnqueteDao"/>

33
<bean id="surveyItemsDao" class="br.com.feedback.jdbc.dao.Itens_EnqueteDao"/>
<bean id="pictureDao" class="br.com.feedback.jdbc.dao.ImagemDao"/>
<bean id="ataDao" class="br.com.feedback.jdbc.dao.AtaDao"/>

O JPA também possui seu próprio arquivo de configuração XML, neste projeto
ele foi denominado de persistence.xml. Existem vários tipos de configurações, dentre as
mais avançadas temos controle de cache e transações como especificado em [1]. Neste
trabalho foram realizadas apenas configurações básicas do Hibernate e o mapeamento
das entidades.

<persistence-unit transaction-type="RESOURCE_LOCAL" name="feedback">


<provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>br.com.feedback.jdbc.bean.Membros</class>
<class>br.com.feedback.jdbc.bean.Usuarios</class>
<class>br.com.feedback.jdbc.bean.Tarefas</class>
<class>br.com.feedback.jdbc.bean.Republicas</class>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
<property name="hibernate.show_sql" value="true"/>
<property name="hibernate.format_sql" value="true"/>
<property name="hibernate.hbm2ddl.auto" value="update"/>
</properties>
</persistence-unit>

3.3.3. Apresentação

A camada de apresentação foi construída através de JavaServer Pages


conhecidas também como JSP (Seção 1.4.1). A intensão é separar código Java de
código HTML usando JSTL (JavaServer Pages Standard Template Library), para
tornar o código mais legível e dinâmico. JSTL é uma API que dá a oportunidade para o
desenvolvedor de escrever comandos condicionais, iterações, instanciação de objetos
entre outras funcionalidades através de tags, assim como no HTML.
Para construir a camada de apresentação foi utilizado o Framework Bootstrap.
Sua configuração é bem simples, basta colocar a pasta dentro do projeto, e mapear o seu
caminho no arquivo de configuração do framework Spring através do seguinte código:

<mvc:resources location="WEB-INF/bootstrap/" mapping="/bootstrap/**"/>

As figuras a seguir mostram alguns exemplos das telas construídas para o


sistema FeedBack.

34
Figura 3.4: Página de pesquisa de repúblicas. A pesquisa pode ocorrer por nome e
localidade da república, além disso, a exibição pode ser dar no mapa ou através de uma
lista.

Figura 3.5: Essa é a página de perfil de uma república. Através dela as repúblicas
podem divulgar vagas, exibir informações de contato (inclusive localização no mapa),
além de mostrar os membros que fazem parte da mesma.

35
Figura 3.6: Tela com a lista de todos os membros. Essa visão é do administrador do
sistema, que tem a opção de deletar e editar os membros cadastrados.

Figura 3.7: Esta tela pode ser acessada através do item ajustes no sub menu República.
Sua função é controlar o nível de acesso dos usuários cadastrados no sistema, outra
funcionalidade seria ajustar os membros por ordem de hierarquia.

36
Figura 3.8: Visão de um usuário administrador do sistema, que tem a opção de editar
todas as informações que aparecem na página de perfil da república, como informações
de vagas, informações de contato entre outras.

Figura 3.9: Tela para adicionar tarefas. Perceba que as algumas informações já
vêm preenchidas, como data de inicio e supervisor, que geralmente é membro
que está adicionando a tarefa.

37
Figura 3.10: Visão de um usuário do sistema com lista de tarefas em sua
responsabilidade. Ele tem a opção de marcar a tarefa como finalizada.

Figura 3.11: Visão de um usuário administrador do sistema com a lista das últimas
reuniões da república. Ele tem a opção de deletar a reunião, além de ver a pauta e atas
da mesma.

38
Figura 3.12: Esta é a tela da pauta de uma reunião especifica. A cor das letras dos itens
esta verde pelo fato de todos os itens já terem sido discutidos. Não é possível apagar ou
editar os itens pelo fato de a reunião já ter acontecido.

Figura 3.13: Esta é a tela da ata de uma reunião especifica. Não é possível apagar ou
editar nenhum item da ata, pelo fato de a reunião já ter acontecido. A única opção de
cada item da ata é deixar, ou não, visível à informação para que o calouro possa ler.

39
3.3.4. Controlador

Os controladores são responsáveis por efetuar toda a parte de regras de negócios


da aplicação. Os controladores recebem uma requisição HTTP, trabalham em cima
desta requisição e enviam uma resposta para o cliente. Essa camada trabalha em
conjunto com as classes DAO para realizar operações de inserção, alteração, remoção
ou recuperação de objetos no banco de dados.

Neste trabalho foram implementados sete controladores que foram divididos de


acordo com os módulos implementados no sistema. Cada controlador tem vários
métodos que são responsáveis por processar uma determinada requisição HTTP.

O exemplo abaixo mostra a um método do controlador ReuniaoController que


tem a responsabilidade de adicionar uma reunião ao banco de dados.

@RequestMapping("adicionarReuniao")
public String adicionarReuniao(HttpServletRequest request, Reuniao reuniao) {
Usuarios user = (Usuarios)request.getSession().getAttribute("usuario");

reuniao.setRepublica(user.getMembro().getRepublica());
sessionDao.adiciona(reuniao);

return "redirect:reunioes";
}

A anotação @RequestMapping é responsável por mapear o método com a String


“adicionarReuniao”, i.e., toda vez que uma requisição chegar ao servidor com a String
em questão no endereço url (acrônimo para Uniform Resource Locator), a aplicação irá
direcionar a requisição para o método correspondente para que a mesma seja tratada e
respondida de forma adequada para o cliente.

O método utiliza o usuário cadastrado na sessão para capturar a república a qual


o mesmo pertence, e relacioná-la a entidade reunião. O DAO responsável por tratar da
entidade reunião é o sessionDao. Por fim, o método redireciona a resposta do usuário
para outro método, a qual é responsável por retornar uma lista com todas as reuniões já
marcadas para o usuário de uma determinada república.

40
Capítulo 4
Avaliação do sistema
Para avaliar o sistema foram construídos cinco planos de teste com o objetivo de
cobrir o maior número de funcionalidades do sistema levando em consideração cenários
reais que os usuários iriam encontrar durante o uso do mesmo. Cada plano teve cinco
usuários diferentes para testá-los, totalizando uma quantidade de 25 testes realizados,
distribuídos entre 25 usuários diferentes. Os usuários participantes desta pesquisa de
usabilidade eram todos estudantes universitários que participavam do ambiente
republicano com idade entre 18 e 28 anos de ambos os sexos.

Abaixo será explicada a construção de cada plano de teste e avaliação SUS de


acordo o mesmo, assim como as dificuldades encontradas pelos usuários. Os planos de
teste são especificados no apêndice B em mais detalhes.

4.1. Criação de usuário e república

Este plano de teste solicita do usuário a criação de uma república e de um


usuário no sistema que esteja associado à mesma. O teste também requisita do usuário a
realização de configurações básicas da página de perfil da república no sistema, a fim de
configurar uma imagem de logotipo da república e as coordenadas geográficas da
mesma no sistema, para facilitar sua localização em um mapa do Google Maps.

As repúblicas cadastradas são fictícias e a localização das mesmas era a


localização do usuário que estava realizando o teste. Algumas informações foram
fornecidas ao usuário de teste para que ele pudesse realizar o mesmo, como: nome
fictício da república, logo tipo da mesma e etc.

O objetivo deste teste era saber se o usuário conseguiria além de realizar o


cadastro no sistema, encontrar a parte de configurações da página de perfil e realizar as
configurações requisitadas.

A soma dos resultados foi realizada de acordo com as normas propostas em [26],
onde a pontuação do usuário é convertida para a pontuação SUS de acordo com as
seguintes regras:

 Se o item for impar: subtraímos 1 da resposta do usuário;


41
 Se o item for par: 5 é subtraído da resposta do usuário;
 A soma dos resultados é multiplicada por 2,5;

Tabela 4.1: Avaliação SUS para o plano de teste I

Usuário Perguntas Soma


1 2 3 4 5 6 7 8 9 10
001 4 2 4 1 3 3 3 4 3 5 55
002 4 1 4 1 5 1 5 1 3 2 87,5
003 5 2 4 1 5 1 5 1 4 1 92,5
004 5 3 2 2 4 2 3 3 3 2 62,5
005 4 2 1 4 3 2 3 4 1 2 45
Total 68,5

A média das avalições dos cinco usuários foi 68,5. Apesar de o resultado estar
entre a média, apenas três usuários conseguiram completar todas as atividades deste
plano de teste. E todos tiveram dificuldades de encontrar o local para realizar as
configurações da página de perfil da república.

4.2. Simular administrador do sistema

Para realizar este teste, foi necessário criar quatro membros fictícios para cada
república fictícia. O objetivo deste teste era que o usuário de teste aceitasse as
solicitações de membros requeridas e fizesse alterações no nível de acesso de um
membro em especifico, além de uma correção no cadastro deste membro.

As únicas informações fornecidas a esses usuários de teste foram email e senha


de acesso ao sistema, além do nome do usuário cujo nível de acesso deveria ser
alterado.

Tabela 4.2: Avaliação SUS para o plano de teste II

Usuário Perguntas Soma


1 2 3 4 5 6 7 8 9 10
001 4 4 2 5 5 1 4 4 1 1 52,5
002 3 3 2 3 4 2 3 3 4 2 57,5
003 5 1 5 1 5 1 5 1 5 2 97,5
004 5 4 4 1 5 1 4 2 5 1 85
005 4 3 3 3 4 1 3 2 4 1 70
Total 72,5

A média das avaliações SUS para este plano de teste foi de 72,5. Porém todos os
usuários perderam muito tempo procurando o local onde se alterava o nível de acesso
dos usuários.
42
4.3. Gerência de tarefas

Para este teste, foi necessário criar três tarefas distribuídas entre os membros de
cada uma das cinco repúblicas. O objetivo do teste era fazer o usuário criar e alterar
uma tarefa e dar por encerrada duas das tarefas cadastradas sob sua responsabilidade.

As informações fornecidas para que o usuário realizasse o teste foram apenas


email e senha para realizar o login no sistema.

Tabela 4.3: Avaliação SUS para o plano de teste III

Usuário Perguntas Soma


1 2 3 4 5 6 7 8 9 10
001 5 1 4 5 3 5 3 4 1 87,5
002 5 1 5 1 5 4 5 1 5 1 92,5
003 5 3 4 1 5 2 4 3 4 1 80
004 4 1 5 1 5 1 4 1 5 1 95
005 4 1 4 1 3 1 5 1 4 1 87,5
Total 88,5

A média de 88,5 condiz com as avaliações dos usuários, pois nenhum deles teve
dificuldades de realizar as atividades deste plano de teste.

4.4. Gerência de reuniões

Neste plano de teste o usuário já encontrava três itens de discussões diferentes


cadastrados no sistema. O objetivo era criar uma reunião e incluir estes tópicos de
discussões já sugeridos por outros usuários fictícios do sistema, além de criar a ata com
as conclusões dessas discussões. O usuário também tinha que marcar os itens da pauta
que já tinham sido discutidos de acordo com a história contada. As informações
fornecidas foram às mesmas do plano de teste anterior.

Tabela 4.4: Avaliação SUS para o plano de teste IV

Usuário Perguntas Soma


1 2 3 4 5 6 7 8 9 10
001 5 1 3 4 5 1 4 3 2 1 72,5
002 4 5 2 5 3 4 1 5 3 4 25
003 4 1 5 1 4 1 5 1 4 2 90
004 4 3 4 1 4 2 4 3 4 1 75
005 5 2 5 4 5 1 5 1 5 2 87,5
Total 70

43
Este plano de teste também foi realizado sucesso, porém todos usuários
poderiam ter realizado um caminho mais fácil que existia no sistema e que não estava
bem sinalizado. A média das avaliações para este plano de teste foi de 70 pontos.

4.5. Pesquisa de repúblicas

Este plano de teste requisitou do usuário o telefone de uma república cadastrada


no sistema que oferecia vagas. Na história contada, o usuário era um calouro em busca
de repúblicas. A única informação fornecida ao usuário foi o site do sistema para que
ele pudesse realizar a busca.

Tabela 4.5: Avaliação SUS para o plano de teste V

Usuário Perguntas Soma


1 2 3 4 5 6 7 8 9 10
001 5 1 4 2 5 1 5 1 5 1 95
002 2 3 3 2 2 3 2 3 3 3 45
003 5 2 5 1 5 1 4 2 5 1 92,5
004 5 1 3 4 4 1 2 4 2 65
005 4 5 5 5 5 2 5 1 4 1 72,5
Total 74

A média para este plano de teste foi de 74 pontos, porém, dos cinco usuários que
realizaram os teste, apenas 4 conseguiram completar a tarefa, sendo que todos
demoraram muito tempo para descobrir onde encontrar a informação pedida.

44
Capítulo 5
Considerações finais
As repúblicas estudantis de Ouro Preto construíram um ambiente relativamente
complexo durante os últimos anos, onde todos os membros compartilham ou deveriam
compartilham, um sentimento de colaboração para o desenvolvimento contínuo das
mesmas. É através deste sentimento que as repúblicas melhoram sua infraestrutura e
constroem um ambiente sadio de convivência.

O objetivo deste trabalho de forma geral se tratava de identificar melhorias no


processo de gestão das repúblicas no que tange a distribuição de tarefas e
compartilhamento de atas, além de facilitar a divulgação de vagas das mesmas.

Neste trabalho foi desenvolvido um sistema Web, que apresenta algumas


melhorias no processo de gestão citados acima. Ao analisar especificamente os
objetivos, vemos algumas melhorias na distribuição de tarefas, pois ao utilizar o sistema
FeedBack para realizar essa distribuição, os membros da república colocam as tarefas a
serem realizadas sob a responsabilidade de um supervisor.

Na primeira pesquisa realizada neste trabalho sobre o funcionamento do sistema


republicano (apêndice A.1), em 55% das repúblicas entrevistadas não existia a prática
de colocar um responsável por cobrar as tarefas de outros membros. Como todas as
tarefas realizadas pelos membros ficam armazenadas, pode-se dizer também que a
tomada de decisões em relação à distribuição das tarefas foi simplificada.

Outro objetivo alcançado em foi simplificar a transmissão de informações


geradas a partir das reuniões. Pois através do sistema FeedBack é possível criar a ata em
tópicos, de forma que a mesma é imediatamente compartilhada com todos os membros
da república. A melhoria mais visível está em poder compartilhar a ata com os calouros
que não participam das reuniões, de modo a deixar ocultas todas as informações que os
mesmos não deveriam ter acesso.

Para facilitar a divulgação de vagas, seria necessário que o sistema ganhasse


visibilidade entre o público de estudantes universitários, tanto entre os que procuram
vagas quanto os que ofertam, portanto este objetivo não foi atingido. Porém o sistema
apresenta um ótimo espaço para as repúblicas divulgarem suas vagas, além de filtros de
45
pesquisa para que o calouro consiga encontrar uma república pelo nome ou por
localidade.

Apesar de todos os esforços, o sistema apresenta lacunas no que tange ao


atendimento de requisitos de usabilidade. Como apresentado no capitulo 4, os usuários
que realizaram alguns dos testes tiveram que ter paciência para procurar as
funcionalidades requisitadas no mesmo, o que nem sempre irá acontecer na prática.

O objetivo de trabalhos futuros será tratar todos os pontos falhos da usabilidade


identificados através da análise do teste de usabilidade (apêndice B) e por declarações
desses usuários. Os pontos falhos e possíveis soluções são identificados abaixo:

 Trocar a forma como as imagens são adicionadas no sistema, i.e., não


utilizar url’s para colocar imagens, pois nem todos os usuários são
familiarizados com este termo.

 Colocar as informações de edição da página de perfil na própria página de


perfil, pois segundo declarações dos usuários do plano de teste I (apêndice
B.1), todos tentaram recorreram primeiramente a esta página para editá-la.

 Criar um guia rápido para usuários de primeira viagem para mostrar todas as
funções de administrador do sistema, para deixar estes usuários à vontade
com o mesmo.

 Na página de pesquisa de república, colocar como opção primária a exibição


das repúblicas em lista, pois todos os usuários do teste V (apêndice B.5)
demoraram a descobrir que as repúblicas poderiam ser exibidas de outra
forma que não fosse no mapa. Isso dificultou os usuários entenderem que as
repúblicas tinham páginas de perfis que continham outras informações que
podia ser utilizadas pelos mesmos.

Além disso, pretendesse acrescentar um módulo para tratar de toda a parte


financeira da república, de forma a incentivar ainda mais as repúblicas a utilizarem o
sistema.

46
Apêndice A
Pesquisas de mercado
Este apêndice apresenta as pesquisas de mercado que foram realizadas nesse trabalho.

A.1. Pesquisa sobre o funcionamento do sistema republicano

1. Como a cobrança de tarefas dos bixos procede na sua república?

2. Quando as tarefas são distribuídas em reuniões entre os moradores, alguém fica


responsável por cobrar a tarefa um do outro?

3. Os bixos participam de todas reuniões na sua república?

47
4. Os bixos tem acesso às atas das reuniões da sua república?

5. Você acharia interessante que os bixos tivessem acesso às atas da sua república de
forma controlada, isto é, acesso apenas às informações escolhidas pelos moradores?

A.2. Pesquisa sobre o perfil republicano


1. Você acha a distribuição de tarefas entre os moradores da sua repúblicas justa?

2. Como morador você já se achou mais sobrecarregado de tarefas do que outros


moradores?

48
3. Marque os problemas que você enfrentou durante a(s) sua(s) batalha(s):

a. Má comunicação entre dos demais membros da república comigo


b. Dificilmente era informado do que deveria fazer, ou como fazer
c. O perfil da república parecia ser bem diferente do meu
d. Não tive problemas durante a minha batalha
e. Outro

4. Você lê as atas das reuniões da sua república com frequência?

5. Você acha que sua república possui uma boa comunicação entre seus membros?

49
Apêndice B
Planos de teste
Abaixo são apresentados em detalhes todos os planos de teste. Ao final de todos os
planos de teste foi requisitado para o usuário realizar a avaliação do sistema de acordo
com o questionário apresentado na seção 2.1.6. No início de cada teste era informado
para os usuários que eles não eram obrigados a terminar o teste, mas que tinham que
avaliar o sistema de acordo com o que suas tentativas na execução das atividades.

B.1. Plano de teste I - Criação de usuário e república


1) Sua função é criar uma conta no site FeedBack
(http://feedbackrepublicas.com.br/ ). Na criação do cadastro da república, utilize
o nome da república de acordo com o código que você recebeu:
a.
Código Nome da República
001 Betas
002 Sigma Beta Rho
003 Alpha delta phi
004 Sigma Gamma Rho
005 Phi Rho Eta

b. Complete o restante dos campos (Como endereço, telefones entre outros)


com informações fictícias, ou da sua república se você preferir. Porém
deixe as informações de cidade, estado e pais como estão: Ouro Preto,
MG, Brasil.
c. Preencha os campos de usuário (Como nome, apelido, endereços entre
outros) com informações fictícias ou as suas se você preferir e para o
campo Imagem de Perfil preencha com a seguinte URL:

http://icon-icons.com/icons2/11/PNG/256/person_user_customer_man_male_man_boy_people_1687.png

d. Preencha as informações de usuário com o código que você recebeu:

Código Email Senha


001 user.teste1@gmail.com xxx
002 user.teste2@gmail.com xxx
003 user.teste3@gmail.com xxx
004 user.teste4@gmail.com xxx
005 user.teste5@gmail.com xxx

50
Obs.: Observe que as senha são todas minúsculas.

2) Sua função agora é configurar a página de sua república. Para isso é necessário
estar logado no sistema. Você só precisa colocar a foto de perfil da república de
acordo com o código que recebeu, e preencher os campos de latitude e longitude
da república. Para preencher estes últimos use como referência a sua localização
atual. Esses dados podem ser adquiridos através do google maps
(https://www.google.com.br/maps/). Não esqueça de salvar as alterações.

Códig Logo da República


o
001 http://2.bp.blogspot.com/-
kvhMMZvNdAs/TuNub0B05sI/AAAAAAAAAOE/f-5ObpQ4-
0g/s1600/simbolo+beta.jpg
002 https://pbs.twimg.com/profile_images/380833576/Crest__CLEAR_.png
003 https://studentaffairs.duke.edu/sites/default/files/u110/alpha_delta_phi_c
rest.5.16.13.png
004 https://www.unf.edu/uploadedImages/sa/fraternity-
sorority/chapters/SGRho%20Crest.jpg
005 http://www.s4g.com/assets/images/phi-rho-eta-crest.jpg

B.2. Plano de teste II - Simular Administrador do sistema


Você é morador de uma república estudantil, e sua república esta cadastrada em um
sistema de gestão de repúblicas, e você é o administrador do sistema. Siga as instruções
abaixo:

1) Primeiramente faça login no sistema de acordo com o código que você recebeu,
o site é: http://feedbackrepublicas.com.br/

Código Email Senha


001 user.teste1@gmail.com xxx
002 user.teste2@gmail.com xxx
003 user.teste3@gmail.com xxx
004 user.teste4@gmail.com xxx
005 user.teste5@gmail.com xxx

a. As pessoas que moram com você se cadastraram no sistema da sua


república, agora sua função como administrador do sistema é aceita-las
como membros da sua república.

51
b. Você quer alterar a ordem de exibição dos membros que aparecem na página
de perfil da sua república e ordena-lo pela hierarquia. Por isso coloque a
exibição dos membros da sua república como a seguir:

Nome Posição
Marcelo Oliveira 1
Vinicius Gomes Meneses 2
Dennis Pinheiro 3
Estevão Pereira Aguiar 4
Daniel Nogueira Resende 5

c. Daniel Nogueira Resende (Sussa) é Calouro, mas se cadastrou como


Morador, sua função é consertar isso. Por isso altere o tipo de membro de
Estevão para Bixo.
d. Verifique na página de perfil da república na sessão Membros -> Moradores,
se a configuração foi realizada com sucesso, ou seja, a ordem dos moradores
está como descrito na tabela acima?
e. Você também deve limitar a permissão de acesso do Daniel para que ele não
consiga acessar áreas restritas apenas para moradores. A permissão de acesso
dele deve ser compatível com a de bixo. Tenha em mente que a operação
executada na letra “c” é diferente desta.

B.3. Plano de teste III – Gerenciar tarefas


Você é morador de uma república estudantil, e sua república esta cadastrada em um
sistema de gestão de repúblicas, e você é um dos usuários deste sistema. Siga as
instruções abaixo:

1) Primeiramente faça login no sistema de acordo com o código que você


recebeu. O site é: http://feedbackrepublicas.com.br/

Código Email Senha


001 user.teste1@gmail.com xxx
002 user.teste2@gmail.com xxx
003 user.teste3@gmail.com xxx
004 user.teste4@gmail.com xxx
005 user.teste5@gmail.com xxx

a. Você se lembrou de que o encanamento da pia da cozinha esta estragado e como


já possui duas atividades sob sua responsabilidade gostaria de repassar a tarefa
52
para outra pessoa. Então coloque esta tarefa sob responsabilidade do Rasgado,
que não possui nenhuma responsabilidade no momento. Coloque a data de
término da tarefa para o dia 25/07/2016.
b. Você já realizou as compras do mês e fez a faxina da semana, por isso é hora de
dar essas tarefas por encerradas.
c. Você se esqueceu de que o Sussa é bixo, e não esta muito familiarizado com
todas as atividades da casa. Por isso é necessário colocar mais uma pessoa para
ajuda-lo a realizar a atividade de renegociação do contrato de locação. Coloque
o Bily Boy para ajuda-lo.

B.4. Plano de teste IV – Gerenciar reuniões


Você é morador de uma república estudantil, e sua república esta cadastrada em um
sistema de gestão de repúblicas, e você é um dos usuários deste sistema. Siga as
instruções abaixo:

1) Primeiramente faça login no sistema de acordo com o código que você recebeu.
O site é: http://feedbackrepublicas.com.br/index

Código Email Senha


001 user.teste1@gmail.com xxx
002 user.teste2@gmail.com xxx
003 user.teste3@gmail.com xxx
004 user.teste4@gmail.com xxx
005 user.teste5@gmail.com xxx

a. Você acessou a área de discussões e descobriu que já existem três itens a serem
discutidos, então é hora de marcar uma reunião para discutir todos estes itens.
Você também sabe que a data de hoje às 23:00 horas é um bom horário para
todos. Então marque a reunião para discutir a organização da casa.
b. Com a reunião já marcada, adicione todos os itens de discussão que você
(Bazinga) e os outros membros da sua casa propuseram à pauta da reunião que
foi marcada.
c. Você se lembrou de que gostaria de adicionar mais um item de discussão sobre
os problemas com a operadora de telefone que vocês estão tendo.

2) A reunião esta acontecendo e você deve ir marcando todos os itens de discussão


da pauta como já discutidos.
53
3) A reunião acabou e agora é hora de construir a ata da mesma, adicionando a
conclusão de todas as discussões. Dê sequência nos passos a seguir.
a. Vocês chegaram à conclusão de que:
i. “Quem largar roupa suja no banheiro, deixar pontas de cigarro
espalhadas pela casa ou fazer download fora do horário de
00:00 às 07:00 irão ter que lavar todas as vasilhas sujas da
cozinha durante todo o dia seguinte ao acontecimento”.
ii. “Será necessário trocar de operadora de telefone, então o sussa
ficará responsável trazer um orçamento de outras operadoras
pra próxima reunião”.

B.5. Plano de teste V – Pesquisa de repúblicas

Você é calouro da Universidade Federal de Ouro Preto e procura por repúblicas que
tenham vagas disponíveis. Você tem conhecimento sobre o sistema FeedBack onde
existem várias repúblicas cadastradas no mesmo. Siga as instruções abaixo:

1) Primeiramente acesse o site: http://feedbackrepublicas.com.br/index


2) Sua função a achar o telefone de uma das repúblicas que tenham vagas. Tenha
em mente que nem todas as repúblicas têm vagas disponíveis. Retorne o número
de telefone encontrado para o executor deste teste.

54
Referência Bibliografia

[1] Java Platform, Enterprise Edition - The Java EE Tutorial. Disponível em


<https://docs.oracle.com/javaee/7/JEETT.pdf> Acessado em: Maio de 2016
[2] O'Neil, Elizabeth J. "Object/relational mapping 2008: hibernate and the entity data
model (edm)." Proceedings of the 2008 ACM SIGMOD international conference on
Management of data. ACM, 2008.
[3] Hibernate User Guide. Disponível em
http://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.ht
ml> Acessado em Maio de 2016.
[4] Ladd, Seth, et al. Expert Spring MVC and Web Flow. Vol. 1. Berkeley, CA: Apress,
2006.
[5] Curry, Edward, and Paul Grace. "Flexible self-management using the model-view-
controller pattern." Software, IEEE 25.3 (2008): 84-90.
[6] Todoist – Gerenciador de tarefas. Disponível em <https://ptbr.todoist.com/>
Acessado em Junho de 2016.
[7] Runrun.it – Gerenciador de tarefas. Disponível em <http://runrun.it/pt-BR>
Acessado em Junho de 2016.
[8] Wunderlist – Gerenciador de tarefas. Disponível em
<https://www.wunderlist.com/pt/> Acessado em Junho de 2016.
[9] EATA – Gerenciador de reuniões. Disponível em <http://www.eata.com.br/>
Acessado em Junho de 2016.
[10] Sommerville, I. Software Engineering (9th Edition). São Paulo: Pearson Addison
Wesley, 2009.
[11] Koscianski, André, e Michel dos Santos Soares. "Qualidade de software: aprenda
as metodologias e técnicas mais modernas para o desenvolvimento de software." (2007).
[12] PRESSMAN, Roger S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill,
2006.
[13] dos Santos Soares, Michel. "Metodologias ágeis extreme programming e scrum
para o desenvolvimento de software." Revista Eletrônica de Sistemas de Informação
ISSN 1677-3071 doi: 10.5329/RESI 3.1 (2004).
[14] USABILITY.GOV. Disponível em <http://www.usability.gov/>. Acesso em 14 de
Junho de 2016.

55
[15] LEWIS, James R.; SAURO, Jeff. The factor structure of the system usability scale.
In: Human centered design. Springer Berlin Heidelberg, 2009. p. 94-103.
[16] BROOKE, John et al. SUS-A quick and dirty usability scale. Usability evaluation
in industry, v. 189, n. 194, p. 4-7, 1996.
[17] BROOKE, John. SUS: a retrospective. Journal of usability studies, v. 8, n. 2, p. 29-
40, 2013.
[18] AgreeDo – Gerenciador de reuniões. Disponível em <https://www.agreedo.com/>
Acessado em Julho de 2016.
[19] MorarUFLA – Divulgador de vagas. Disponível em <http://morarufla.com.br/>
Acessado em Julho de 2016.
[20] Repúblicas do Brasil – Divulgador de vagas. Disponível em
<http://republicasdobrasil.com/> Acessado em Julho de 2016.
[21] Goncalves, Antonio. Beginning Java EE 6 Platform with GlassFish 3: from novice
to professional. Apress, 2009.
[22] da Silva, Valéria Martins. "Revisão sistemática da evolução MVC na base ACM."
(2012).
[23] Nielsen, Jakob, and Hoa Loranger. Usabilidade na web. Elsevier Brasil, 2007.
[24] Deterding, Sebastian, et al. "Gamification. using game-design elements in non-
gaming contexts." CHI'11 Extended Abstracts on Human Factors in Computing
Systems. ACM, 2011.
[25] DevMedia - Introdução prática ao Spring Framework com uso de Anotações.
Disponivel em <http://www.devmedia.com.br/introducao-pratica-ao-spring-framework-
com-uso-de-anotacoes/27859 > Acessado em Julho de 2016.
[26] Measuring Usability With The System Usability Scale (SUS). Disponível em <
http://www.measuringu.com/sus.php> acessado em julho de 2016.
[27] About Bootstrap – Disponível < http://getbootstrap.com/about/> acessado em Julho
de 2016.

56