Paulo Henrique da Cruz Pereira. Consistência de Interfaces em Software Livre: Processo e Guia de Recomendações para o LMS AMADEUS. 2015. Trabalho de Conclusão de Curso. (Graduação

7/21/2019 Paulo Henrique da Cruz Pereira. Consistncia de Interfaces em Software Livre: Processo e Guia de Recomendaes para o LMS AMADEUS. 2015. Trabalh

1/75

UNIVERSIDADE FEDERAL DE PERNAMBUCOCENTRO DE INFORMTICA

GRADUAO EM CINCIA DA COMPUTAO

CONSISTNCIA DE INTERFACES EM SOFTWARE LIVRE:

PROCESSO E GUIA DE RECOMENDAES PARA O LMSAMADEUS

Paulo Henrique da Cruz Pereira

Trabalho de Graduao

RecifeFEVEREIRO DE 2015


2/75

UNIVERSIDADE FEDERAL DE PERNAMBUCOCENTRO DE INFORMTICA

Paulo Henrique da Cruz Pereira

CONSISTNCIA DE INTERFACES EM SOFTWARE LIVRE:PROCESSO E GUIA DE RECOMENDAES PARA O LMS

AMADEUS

Trabalho apresentado ao Programa de GRADUAO EMCINCIA DA COMPUTAO do CENTRO DE

INFORMTICA da UNIVERSIDADE FEDERAL DEPERNAMBUCO como requisito parcial para obteno dograu de CINCIA DA COMPUTAO.

Orientador(a):Prof Dr Alex Sandro Gomes

RecifeFEVEREIRO DE 2015


3/75

minha famlia.


4/75

AGRADECIMENTOS

Meu primeiro agradecimento a Deus, por ter, em meio a tantas presses e incertezas,

me dado possibilidades de chegar na reta final da graduao, e com foras suficientes para

executar bons trabalhos.

Tambm agradeo minha famlia, a quem devo minha vida, pois sempre possibilitaram

seguir com minhas escolhas e nunca deixaram de me apoiar, mesmo nos momentos mais

crticos. minha me Ecilda, que com seus abraos me d a confiana da qual preciso para

seguir em frente e alcanar meus objetivos. minha av Ins, que junto ao meu av Jos fez e

faz o impossvel para criar essa bela famlia. Ao meu irmo Jnior, que com suas curiosidades

cientficas me fez despertar um novo mundo nas exatas. Ao meu tio Elcy, que desde sempre

uma grande influncia e me fez perceber que os estudos podem levar a um bom caminho. Ao

meu pai Paulo e a minha av Creuza, que tambm so muito importantes pra mim.

Agradeo Cynthia, minha namorada, por todo seu apoio e companheirismo, por

levantar minha cabea e me fazer persistir, por ter pacincia e me dar os conselhos certos nas

horas certas, e por estar esse tempo todo ao meu lado, sem ela toda essa jornada teria sido mais

difcil. Te amo m!

Aos amigos de colgio, Daniel, Diogo, Felipe, Hugo, Inaldo e Luciano, os quais tive aoportunidade de passar bons momentos juntos, e apesar da vida nos distanciar tenho a certeza

que nos reencontros a amizade sempre a mesma. Aos amigos da universidade, Alberto, Bruna,

Filipe, Luiz, Marcos, Jonatas e Tomaz, com quem pude compartilhar os bons momentos e os

desafios que esse curso nos props.

Agradeo ao meu orientador Alex Sandro, que me guiou de forma atenciosa e esteve

sempre disposto a ajudar no desenvolvimento desse trabalho.

E a outros tantos amigos e familiares que de alguma forma me influenciaram, meajudaram ou passaram pela minha vida de forma positiva, sou grato.


5/75

RESUMO

Neste trabalho iremos entender fenmenos relativos consistncia de interfaces em

contribuies s comunidades desoftwarelivre, como tambm estudar gargalos no processo de

integrao no ambiente de desenvolvimento do LMS AMADEUS. Por meio de um estudo de

caso, no qual ser realizada a integrao de duas contribuies ao projeto em um ambiente

colaborativo, iremos propor um processo de integrao e um documento de diretrizes de

interface. O processo ser capaz de guiar as integraes realizadas por meio de um ambiente de

desenvolvimento colaborativo, favorecendo a consistncia de interfaces ao final da execuo.

J o documento de diretrizes ser necessrio para padronizar a criao de novas telas no LMS

AMADEUS, definindo pontos como princpios de usabilidade, posicionamento na tela e paleta

de cores. Por fim faremos uma anlise heurstica nessas contribuies, com foco na reviso de

guidelines e na inspeo de consistncia, e com esse resultado revisaremos o cdigo para

corrigir os problemas encontrados.

Palavras-chave: floss, diretrizes de usabilidade, processo de integrao, anlise heurstica,

reviso deguidelines, inspeo de consistncia.


6/75

ABSTRACT

In this work, we will understand phenomena related to the consistency of interfaces in

contributions to free software communities, as well as studying bottlenecks in the integration

process in the development environment of LMS AMADEUS. Through a case study, where we

will integrate two contributions to the project in a collaborative environment, we will propose

a process of integration and interface guidelines document. The process will be able to guide

the integrations performed through a collaborative development environment, favouring the

consistency of interfaces at the end of the process. The guidelines document will be necessary

to standardize the creation of new screens in LMS AMADEUS, defining points as usability

principles, positioning on the screen and colour palette. Finally, we will perform a heuristic

analysis in such contributions, focusing on the revision of guidelines and inspection of

consistency, and with this result, we will review the code to fix any problems found.

Keywords: consistency of interfaces, free software, floss, usability guidelines, integration

process, heuristic analysis, guidelines revision, consistency inspection.


7/75

LISTA DE FIGURAS

Figura 1. Tela do repositrio do Amadeus no GitHub ............................................................. 26

Figura 2. Mdulos das contribuies a serem adicionados no projeto ..................................... 27

Figura 3. Opo de mergeautomtico atravs do GitHub ....................................................... 28

Figura 4.Mergeda contribuio de MEDEIROS concludo.................................................... 28Figura 5. Comandos do Git para realizar merge com a contribuio de PERRIS .................... 29

Figura 6. Processo de integrao de contribuies da comunidade AMADEUS (Parte 1) ...... 34Figura 7. Processo de integrao de contribuies da comunidade AMADEUS (Parte 2) ...... 35Figura 8. Processo de integrao de contribuies da comunidade AMADEUS (Parte 3) ...... 36Figura 9. Processo de integrao de contribuies da comunidade AMADEUS (Parte 4) ...... 37Figura 10. Processo de integrao de contribuies da comunidade AMADEUS (Parte 5) .... 38

Figura 11. Processo de integrao de contribuies da comunidade AMADEUS (Parte 6) .... 39Figura 12. Subprocesso de desenvolver alterao no cdigo ................................................... 40Figura 13. Subprocesso de realizar anlise heurstica .............................................................. 40

Figura 14. Documento de diretrizes de usabilidade para aplicativos do FirefoxOS ................ 42Figura 15. reas dogridcom a finalidade proposta ................................................................ 44Figura 16. Gridde duas colunas com dimenses de largura e espaamento ............................ 46Figura 17. Gridde trs colunas com dimenses de largura e espaamento ............................. 46Figura 18. Gridcom dimenses de altura e espaamento ........................................................ 47Figura 19. Paleta de tons de verde ............................................................................................ 48

Figura 20. Paleta de tons de verde azulado .............................................................................. 48Figura 21. Paleta de tons de cinza ............................................................................................ 49Figura 22. Paleta de tons de vermelho ...................................................................................... 50

Figura 23. Exemplo de fonte sem serifa ................................................................................... 51

Figura 24. Formatao dos ttulos em textos ............................................................................ 52Figura 25. Formatao das listas em textos .............................................................................. 52Figura 26. Formatao das tabelas de contedo ....................................................................... 53Figura 27. Formatao de pargrafos e linksde texto .............................................................. 53Figura 28. Formulrio de buscar um curso ............................................................................... 54

Figura 29. Formulrio de cadastrar usurio .............................................................................. 55Figura 30. Exemplo de HTML para formulrio consistente .................................................... 55

Figura 31. Formulrio simplificado .......................................................................................... 56Figura 32. Navegao global .................................................................................................... 56Figura 33.Breadcrumb ............................................................................................................. 57

Figura 34. Navegao local ...................................................................................................... 57Figura 35. Boto com layoutquebrado no bloco de mensagens .............................................. 58

Figura 36. Feedback de mensagem enviada sendo exibido ...................................................... 59Figura 37. Tela de exibir todas as mensagens .......................................................................... 59Figura 38. Tela de integrar redes sociais .................................................................................. 60Figura 39. Tela de monitorar redes sociais ............................................................................... 60Figura 40. Menu da tela de grupos ........................................................................................... 61Figura 41. Tela de criar grupo .................................................................................................. 62Figura 42. Tela de visualizar grupos ........................................................................................ 62Figura 43. Tela de relatrio de atividades ................................................................................ 63Figura 44. Boto com layoutcorrigido no bloco de mensagens .............................................. 65

Figura 45. Tela de exibir todas as mensagens corrigida ........................................................... 65

Figura 46. Tela de monitorar redes sociais corrigida ............................................................... 66Figura 47. Tela de integrar redes sociais corrigida ................................................................... 66


8/75

Figura 48. Menu e lista de grupos corrigidos ........................................................................... 67Figura 49. Tela de criar grupo corrigida ................................................................................... 67Figura 50. Tela de atividades do grupo ( esq) e tela de relatrio ( dir) corrigidas ................ 67


9/75

LISTA DE QUADROS

Quadro 1. Tpicos e palavras-chave usados na reviso de literatura ....................................... 22

Quadro 2. Paleta de cores para o AMADEUS ......................................................................... 50

Quadro 3. Especificaes de formatao para componentes HTML no AMADEUS .............. 53

Quadro 4. Resultado da inspeo de consistncia .................................................................... 63Quadro 5. Resultado da reviso deguidelines .......................................................................... 64


10/75

SUMRIO

1 Introduo.......................................................................................................................... 11

1.1

Motivao .................................................................................................................. 11

1.2 Contexto ..................................................................................................................... 11

1.3 Objetivos .................................................................................................................... 12

2 Consistncia de interfaces em software livre .................................................................... 13

2.1 Projetos desoftwarelivre .......................................................................................... 13

2.2 Os problemas em projetos desoftwarelivre .............................................................. 13

2.3 Consistncia de interfaces em projetos desoftwarelivre .......................................... 14

2.4 Tentativas de soluo: Usabilidade em projetos desoftwarelivre ............................ 15

2.4.1

Diretrizes de usabilidade .................................................................................... 15

2.4.2 Anlise heurstica ............................................................................................... 16

2.4.3 Outras solues ................................................................................................... 17

2.5 Tentativas de soluo: Fluxo de colaborao em projetos desoftwarelivre ............. 18

2.5.1

Versionamento com Git ...................................................................................... 18

2.5.2 Colaborao por meio do GitHub ....................................................................... 20

3 Mtodo .............................................................................................................................. 21

3.1 Objetivos .................................................................................................................... 21

3.2

Reviso da literatura .................................................................................................. 21

3.3 Estudos de caso .......................................................................................................... 22

4 Resultados ......................................................................................................................... 26

4.1 Anlise das contribuies .......................................................................................... 26

4.1.1 Integrao da contribuio de MEDEIROS (2013) ............................................ 27

4.1.2 Integrao da contribuio de PERRIS (2013)................................................... 28

4.2 Processo de integrao de contribuies da comunidade AMADEUS ..................... 29

4.2.1 Atores ................................................................................................................. 29

4.2.2 Ambiente ............................................................................................................ 30

4.2.3 Documentos ........................................................................................................ 31

4.2.4

Ferramentas ........................................................................................................ 31

4.2.5 Etapas ................................................................................................................. 32

4.2.6 Modelo ................................................................................................................ 33

4.3 Documento de diretrizes do AMADEUS .................................................................. 42

4.3.1

Princpios ............................................................................................................ 43

4.3.2

Grid ..................................................................................................................... 44

4.3.3 Cores ................................................................................................................... 47

4.3.4 Tipografia ........................................................................................................... 51


11/75


12/75

11

1 INTRODUO

Emsoftwarelivre, o desenvolvimento distribudo traz dificuldades no que diz respeito

manuteno de interfaces consistentes [1], acarretando na criao de problemas de usabilidade

ao usurio comum. Este trabalho visa apreciar meios de evitar inconsistncias de interfaces,

bem como propor um processo de integrao e um documento de diretrizes que corroborem

com o objetivo.

1.1 MOTIVAO

O software livre e de cdigo aberto (F/LOSS) unindo-se ao desenvolvimento

colaborativo ganha mais adeptos a cada dia, sendo crescente o nmero de projetos passando a

usar esse modelo [2]. Dessa forma alguns problemas se tornam mais evidentes, como o de

manter a organizao dos cdigos e arquiteturas pr-definidas, ou mesmo o de manter a

consistncia de novas interfaces que sero desenvolvidas pelos colaboradores. Tudo isso se d

por, comumente, no existir um processo de integrao definido dentro dos projetos desoftware

livre [3].

A ausncia de diretrizes que definam padres visuais e de comportamento da interface

responsvel pela dificuldade em manter a consistncia das novas telas em relao ao que era

esperado, e isso ocorre apenas durante a integrao das colaboraes realizadas por terceiros.Esse problema se agrava principalmente quando lidamos com sistemas de uso amplo,

nos quais o usurio espera aes comuns do sistema, mas uma colaborao pode no responder

da forma esperada. Para reduzi-lo, as dez (10) Heursticas de Nielsen [4] podem ser tomadas

como referncia, ou mesmo podem ser usadas diretrizes de mais alto nvel como as definidas

pelo Departamento de Sade e Servios Humanos (HHS) do governo dos Estados Unidos, o

Usability.gov [5].

1.2 CONTEXTO

O Amadeus um ambiente de ensino a distncia inicialmente desenvolvido pelo grupo

de Cincias Cognitivas e Tecnologias Educacionais (CCTE), do Centro de Informtica da

Universidade Federal de Pernambuco (CIn-UFPE), e posteriormente se tornou um software

livre e de cdigo aberto [6].

Nesse sistema os problemas citados anteriormente so realidade, pois no existe um

processo de integrao nem diretrizes definidas para o desenvolvimento de interfaces. Dessaforma os desenvolvedores podem tomar decises erradas, fazendo com que as interfaces sejam


13/75

12

inconsistentes com o todo, principalmente em pontos especficos relacionados ao Amadeus que

no esto contemplados em diretrizes mais gerais.

1.3

OBJETIVOS

Este trabalho tem como principal objetivo sugerir um processo e artefatos para

contribuir com a manuteno da consistncia de interfaces que sero desenvolvidas pela

comunidade Amadeus.

Os objetivos especficos da proposta so:

Estudar inconsistncias de interface nas colaboraes mais recentes ao Amadeus;

Aplicar o novo ambiente de desenvolvimento colaborativo, GitHub, para gerenciamento

do cdigo do LMS AMADEUS;

Identificar necessidades de processo para manuteno da consistncia de interfaces do

projeto;

Definir um processo de manuteno da consistncia de interfaces do LMS AMADEUS

a partir da identificao das necessidades;

Desenvolver um documento diretrizes para consistncia de interfaces do LMS

AMADEUS;

Analisar contribuies mais recentes para o LMS AMADEUS por meio de avaliao

heurstica, com foco na reviso deguidelinese inspeo de consistncia.

O resultado esperado um documento de diretrizes para formalizar um padro s novas

interfaces e um processo para guiar as integraes realizadas por meio de um ambiente de

desenvolvimento colaborativo. A partir disso faremos a avaliao em duas colaboraes ao

LMS AMADEUS para identificar problemas na consistncia de interfaces.


14/75

13

2 CONSISTNCIA DE INTERFACES EM SOFTWARE LIVRE

Neste captulo apresentaremos o estado da arte sobre o problema da manuteno da

consistncia em produtos de cdigo aberto. A reviso da literatura tem como objetivos

compreender o contexto no qual est inserido o LMS AMADEUS e explorar conceitos de

usabilidade, como anlise heurstica e consistncia de interfaces, dentro das comunidades de

softwarelivre.

2.1 PROJETOS DE SOFTWARELIVRE

Segundo aFree Software Foundation,softwarelivre definido como um softwareque

respeita a liberdade e senso de comunidade dos usurios[7].Dessa forma possvel executar,

estudar, copiar, distribuir e melhorar os cdigos livremente. Essa filosofia torna a comunidade

capaz de controlar os programas e o que feito por eles, diferente desoftwareproprietrio, no

qual uma corporao controla o programa e esse controla o usurio.

O acesso ao cdigo-fonte pr-requisito para um programa sersoftwarelivre, mas alm

disso necessrio permitir outras aes, como:

Executar o programa como desejar, para qualquer propsito;

Estudar como o programa funciona, e adapt-lo s necessidades particulares;

Redistribuir cpias de modo que seja possvel ajudar ao prximo; e

Distribuir cpias de suas verses modificadas a outros.

Esses projetos desoftwarelivre so movimentados por comunidades de pessoas que se

unem com o objetivo de evoluir a soluo. Geralmente as interaes entre indivduos dessas

comunidades ocorre por meio de fruns ou diretamente em ferramentas de gerenciamento de

projeto e controle de cdigo.

2.2

OS PROBLEMAS EM PROJETOS DE SOFTWARELIVREColaboradores de projetos de software livre lidam diariamente com uma srie de

problemas, principalmente quando so recm chegados comunidade. REDMILES [1] estudou

as dificuldades desse perfil de colaborador, no qual ele destaca as barreiras que so comumente

enfrentadas, mapeadas em de uma pesquisa com desenvolvedores novos nas comunidades de

softwarelivre.

As barreiras encontradas foram divididas em categorias, e a principal categoria

encontrada na pesquisa [1] foi a de problemas com documentao, j que novos colaboradoresnecessitam aprender aspectos sociais e tcnicos do projeto para contribuir. Especificamente os


15/75

14

problemas relatados foram relacionados ausncia de documentaosobre: a estrutura do

projeto; a configurao do ambiente de trabalho; o processo de colaborao; e os padres de

design. Ainda assim houve relatos sobre dificuldades com a falta de comentrios em cdigo e

documentao pouco clara ou defasada.

A categoria com segunda maior ocorrncia de barreiras foi relacionada ao

conhecimento tcnico dos novos colaboradores [1]. E dentre as barreiras relatadas esto:

conhecimento prvio sobre ferramentas usadas no projeto; conhecimento prvio em sistemas

de controle de verso; falta de conhecimento nas tecnologias utilizadas; curva de aprendizado

nas ferramentas do projeto; e o uso correto da linguagem de programao usada.

Em seguida foram encontrados problemas na interao social desses novos

colaboradores com a comunidade j estabelecida [1]. Atraso nas respostas, respostasindelicadas, dificuldade de encontrar algum para ajudar, uso de termos intimidadores e

problemas de comunicao so as barreiras relatadas nessa categoria.

Nesse trabalho [1] houve relatos de problemas relacionados configurao do ambiente

de trabalho, assim como dependncia de plataformas especficas ou bibliotecas e

dificuldade em encontrar o cdigo correto. Tambm foram percebidos problemas de cdigo,

relacionados m qualidade dos cdigos existentes, ao tamanho da base de cdigos, existncia

de cdigos defasados, aos problemas no entendimento dos cdigos e ausncia de padres decdigo.

Ainda houve uma categoria sobre a dificuldade dos novos colaboradores em encontrar

uma forma de comear a contribuir[1]. Nela as barreiras relatadas foram: encontrar o melhor

trecho de cdigo para trabalhar; lista de bugsdefasada; e encontrar uma tarefa para comear. E

por fim, na categoria de comportamento do colaborador foram encontradas duas barreiras:

ausncia de commitse subestimar o desafio.

2.3 CONSISTNCIA DE INTERFACES EM PROJETOS DE SOFTWARELIVRE

A manuteno da consistncia de interfaces significa que novas telas esto de acordo

com o todo do projeto, tanto visualmente quanto em termos de fluxo de telas e usabilidade [8].

Por exemplo: botes que so esperados em um lado da tela devem ser mantidos do mesmo lado

em novas telas onde se faa necessrio; e cores usadas representando sucesso em uma tela

devem ser usadas como sucesso em todas as telas onde tambm seja preciso.

Apesar de ser crescente o pensamento de que a usabilidade tem papel fundamental na

concepo e desenvolvimento de projetos de TI, as comunidades desoftwarelivre tendem a ter

maior resistncia na adoo desse tipo de filosofia. RAJANEN [9] enumerou as caractersticas


16/75


17/75

16

de cor e fontes pr-definidos, padres de interao por meio da tela de toque e componentes

disponveis na plataforma.

Com isso fica entendido que diretrizes de usabilidade so um caminho coerente e aceito

por grandes plataformas como meio para a manuteno da consistncia de interfaces. Portanto

as diretrizes devem ser consideradas como parte de uma soluo para problemas de usabilidade

emsoftwarelivre.

2.4.2 Anlise heurstica

A anlise heurstica uma tcnica de avaliao de usabilidade desenvolvida por

NIELSEN [16]. Nela os especialistas so orientados a partir de uma srie de princpios de

usabilidade chamados de heursticas, de modo a avaliarem se os componentes de interface estode acordo com esses princpios. Essas heursticas muito se assemelham s recomendaes ou

aos princpios de designde alto nvel e o conjunto original surgiu a partir da anlise de duzentos

e quarenta e nove (249) problemas de usabilidade [8].

PREECE [8], destacou dez (10) dessas heursticas, so elas: visibilidade de status do

sistema; compatibilidade do sistema com o mundo real; controle do usurio e liberdade;

consistncia e padres; ajudar os usurios a reconhecer, diagnosticar e corrigir erros; preveno

de erros; reconhecer, em vez de relembrar; flexibilidade e eficincia no uso; esttica e designminimalista; e ajuda e documentao.

Porm a especificidade de alguns produtos torna necessrio a escolha de um outro

subconjunto de heursticas ou a elaborao de novas heursticas. possvel adaptar as

heursticas de Nielsen, ou mesmo usar documentos de requisitos, pesquisas de mercado e

recomendaes de designcomo base na criao de heursticas [8]. Em seguida reunido um

conjunto de heursticas que se encaixa no contexto do produto e com a finalidade de obter um

melhor resultado na anlise.Definido o conjunto de heursticas, os avaliadores passam a utilizar o produto se

apropriando da viso de um usurio comum, e anotam todos os problemas encontrados. Durante

esse processo as heursticas tm como finalidade focar a ateno dos especialistas em

determinados pontos, por isso a escolha de heursticas apropriadas fundamental na anlise.

possvel usar uma infinidade de avaliadores nessa tcnica, porm existem evidncias

empricas indicando que cinco avaliadores detectam 75% dos erros de usabilidade existentes

no produto [8]. Os restantes dos erros so tidos como os mais crticos e geralmente s so

identificados pelo usurio, por isso importante o uso de outras tcnicas que o incluam. A


18/75

17

principal vantagem desse mtodo o baixo custo, pois no necessrio nenhum contato direto

com o usurio, reduzindo assim questes ticas e logsticas.

A anlise heurstica possui trs estgios [8]. No primeiro, os especialistas so orientados

sobre o que fazer. Nessa fase importante garantir que todos tenham as mesmas informaes.

Na segunda etapa a avaliao ocorre. Nela cada especialista inspeciona independentemente o

produto durante uma ou duas horas, usando as heursticas como guia. importante que os testes

sejam realizados ao menos duas vezes: a primeira para entender o fluxo do produto e a segunda

com um olhar mais atento aos componentes de interface e aos possveis problemas de

usabilidade. Tudo o que for encontrado deve ser anotado detalhadamente, pois na terceira etapa

os especialistas discutem esses problemas, priorizam e sugerem solues.

RAJANEN [17], props a introduo de tcnicas de usabilidade em projetos desoftwarelivre. Nele executou um experimento com um jogo desenvolvido em cdigo aberto. Nesse

experimento os desenvolvedores puderam executar uma anlise heurstica usando um formato

pr-definido, resultando em 30 erros de usabilidade encontrados. Isso aconteceu sem passar por

uma validao com usurios reais, ou seja, em casos similares a esse, quando o usurio real

fosse acionado para realizar testes o produto conteria menos erros comuns e o foco estaria no

refinamento da usabilidade.

A anlise heurstica se mostra um mtodo barato e eficaz no que diz respeito aidentificao de erros mapeados previstos por princpios e diretrizes de usabilidade. Mesmo

no sendo uma soluo completa para problemas em software livre, esse mtodo se mostra

vivel para entender se novas interfaces esto consistentes com os padres pr-definidos.

2.4.3 Outras solues

Em um projeto desoftwarea documentao tem papel fundamental para uma evoluo

coerente, e ainda mais quando falamos em desenvolvimento distribudo, porm a ausncia dedocumentao uma barreira nesse processo, sendo esse um dos principais problemas,

conforme citado no seo 2.2. Existem propostas que objetivam melhorar o processo da

elaborao de documentos nesse tipo de projeto, como no trabalho de MEDEIROS [18], no

qual analisado o impacto do uso de storyboards, tcnica de prototipao que descreve de

forma visual e narrativa o fluxo de aes, como meio de melhorar a qualidade das atividades

de documentao e validao de requisitos.

Nessa pesquisa o storyboard funcionou como guia durante a etapa de elicitao de

requisitos. A partir do ponto que ele no sofreu mais modificaes, essa etapa foi dada como

concluda. Tendo esse storyboard como entrada para a fase de documentao foi possvel


19/75

18

compartilhar o entendimento de forma mais efetiva entre equipes que trabalham a distncia

[18]. Porm, apesar de ser uma boa soluo para projetos distribudos de corporaes, no

ambiente dosoftwarelivre h dificuldades de aplicao, pois no h um cliente especfico e o

grau de distribuio dos desenvolvedores elevado [19].

Ainda h solues como o Bootstrap [20], um framework criado pelo Twitter1 que

facilita a implementao de interfaces mais amigveis e modernas, inclusive adaptveis para

smartphones e tablets, por meio do recurso de responsividade. Nele h uma documentao

extensa sobre componentes e classes CSS disponveis para utilizao, tambm h exemplos do

uso desses componentes tanto de forma visual como a implementao em cdigo HTML.

Dessa forma o framework permite a manuteno da consistncia de interfaces pelo

padro visual pr-determinado ou por meio de temas adicionados posteriormente. Mas mesmocom a padronizao h projetos que no podem usar o Bootstrap e portanto tm mais

dificuldade em desenvolver interfaces consistentes. So exemplos projetos que necessitam da

criao de novos componentes, possuem designmuito particular, possuem designlegado ou

tm conflitos tcnicos que dificultam a aplicao doframework.

2.5 TENTATIVAS DE SOLUO: FLUXO DE COLABORAO EM PROJETOS DE

SOFTWARELIVREEmsoftwarelivre o processo de colaborao descentralizado, ocorrendo por meio das

comunidades, e por isso existe uma grande dificuldade no controle do que est sendo feito.

Porm existem formas de mitigar esse problema, podendo ser pelo uso de sistemas de controle

de verso e/ou de ferramentas que integram o cdigo de forma social. A seguir detalhamos

algumas formas.

2.5.1

Versionamento com GitControle de verso um sistema que grava mudanas feitas em arquivos durante o

tempo, dessa forma possvel recuperar verses anteriores de um momento especfico [21]. H

vrios mtodos para realizar esse controle, podendo ser feito localmente (Local Version Control

Systems), numa base centralizada em um servidor (Centralized Version Control Systems) ou de

forma distribuda (Distributed Version Control Systems). Essa ltima abordagem foi a escolhida

para o Git e permite uma srie de fluxos impossveis em outros mtodos, pois o usurio mantm

1Disponvel em . Acesso em 7 de novembro de 2014.


20/75

19

uma base local com suas mudanas e pode sincroniz-la com a base do servidor a qualquer

momento.

Depois de instalado, o Git passa a funcionar na linha de comando do sistema operacional

por meio do git []. O primeiro passo com o Git iniciar um repositrio,

com o comando git init, ou clonar um repositrio existente com o git clone ,

no qual tambm passamos a urldo repositrio como parmetro do comando [21].

Com isso as contribuies j podem ser desenvolvidas no ambiente de trabalho do

desenvolvedor, que deve enviar as modificaes para a base local medida que houver

progressos funcionais. Isso deve ser feito por meio do comando git commit [options]

, sendo mais comum da seguinte forma git commit -am no qual

todas as modificaes so enviadas (-a) e uma mensagem (-m) descreve o commit [21].

Para adicionar novos arquivos ao controle de verso necessrio executar o comando

git add [options] , no qual para um arquivo especfico necessrio passar

o caminho aps o add. J para adicionar todos os novos arquivos encontrados no repositrio

deve ser passada apenas opo Aou --all[21]. Tambm possvel conhecer o status da base

local, obtendo um relatrio de arquivos modificados, adicionados ou removidos, e isso pode ser

feito por meio do git status.

Para enviar os commitsao repositrio remoto necessrio executar o comando git

push origin master, no qual origin a branchlocal atual e master a branchprincipal

no servidor. Quando se deseja obter novos arquivos do servidor deve ser executado o git pull

origin master. J para manter o repositrio local atualizado com arquivos de um repositrio

acima deve ser feito o rebase, geralmente por meio de git pull --rebase upstream

master.

Nesse contexto ainda h o conceito de branch, que so caminhos nos quais o

desenvolvimento pode se dar de forma paralela, sendo um deles o principal, a branch master.Essas branchespodem ser unidas (merge) ou substituir outras a qualquer momento. Para cri-

las necessrio o comando git checkout b indicando o nome da nova branch

como argumento.

Todos esses recursos objetivam um melhor controle de cdigo, facilitando a integrao

e a evoluo do projeto. Porm no existe uma garantia que novas interfaces integradas sejam

consistentes com as anteriores. Portanto, o Git no pode ser considerado uma soluo completa,

mesmo sendo uma importante ferramenta no desenvolvimento de aplicaes.


21/75

20

2.5.2 Colaborao por meio do GitHub

GitHub [22] um servio webque permite o armazenamento de repositrios de projetos

com o controle de verso Git. Nele tambm existe uma grande interao entre os membros das

comunidades, pois so disponibilizados fruns, wikie gerenciamento de falhas e melhorias em

uma rea chamada de issues.

No servio h uma srie de recursos que facilitam o uso do Git, como a criao de

branches,pull requestse mergesautomticos, alm de ser possvel editar arquivos diretamente

pelo site, no qual j efetuado um commit com as mudanas realizadas [22]. Alm disso,

quando commits so realizados o GitHub cria threads, ou conversas, no qual possvel

comentar as modificaes do cdigo e interagir com outros desenvolvedores.

Ao acessar repositrios pblicos nositedo servio possvel visualizar a opo fork,que ao ser acionada cria uma verso paralela do projeto administrada pelo prprio usurio [22].

Dessa forma melhorias podem ser realizadas mesmo sem o acesso de edio ao repositrio

original, com isso as contribuies podem ser submetidas posteriormente por meio do pull

request, notificando ao administrador do repositrio original que existem novas contribuies

aguardando integrao.

Sozinho o GitHub no garante que todos os problemas de software livre sejam

resolvidos, principalmente os relacionados usabilidade, que dependem muito de padres bemdocumentados e anlise das contribuies por especialistas. Portanto a adoo desses padres

de diretrizes e processos uma deciso de projeto, cabendo aos administradores do software

definir ou no de que forma os colaboradores devem contribuir.


22/75

21

3 MTODO

O desenvolvimento deste trabalho ocorreu em diversas etapas. O primeiro passo foi

realizar uma reviso de literatura sobre os tpicos trabalhados, em seguida foi feito um estudo

de caso de duas contribuies ao LMS AMADEUS. A partir disso foram elaborados um

processo, representando de forma estruturada o que deve ocorrer durante a integrao das

contribuies, e um documento de diretrizes, detalhando os padres de interface seguidos pelo

software.

3.1 OBJETIVOS

Cada um dos mtodos descritos as sees 3.2 e 3.3 foi importante para atingir os

objetivos dessa etapa:

Entender fenmenos relativos proposio de contribuies da comunidade e perceber

gargalos no processo de integrao por meio do ambiente de desenvolvimento

escolhido;

Elaborar e avaliar um processo gesto de configurao que corresponda estrutura de

prticas em comunidade desoftwarelivre; e

Conceber um documento de diretrizes para o produto LMS Amadeus de modo a permitir

a realizao da anlise heurstica, com foco na reviso de guidelines e inspeo de

consistncia.

3.2 REVISO DA LITERATURA

A reviso de literatura deste trabalho foi feita de trs formas: a partir da busca, usando

palavras-chave relacionadas ao tema, em pginas que renem publicaes acadmicas; por

meio publicaes aceitas em conferncias desoftwarelivre e usabilidade; e por meio de livros

relacionados usabilidade, anlise heurstica,softwarelivre e gerncia de cdigo.A principal base de publicaes usada na reviso de literatura foi a biblioteca digital do

portal ACM, que se autodescreve como a maior sociedade informtica educativa e cientfica do

mundo. Por meio dele foi possvel encontrar publicaes feitas em workshops, conferncias e

revistas em todo o mundo, e neste trabalho mais de 70% da reviso de literatura foi encontrada

nele.

Dentro do tema abordado alguns tpicos so os considerados mais relevantes: anlise

heurstica, diretrizes de usabilidade, fluxo de contribuio do Git, processo de integrao esoftwarelivre. O quadro 1 relaciona cada tpico com palavras-chave em ingls.


23/75


24/75


25/75

24

mensagem. Dever haver um boto Enviarabaixo da caixa de mensagem e

tambm um Cancelar;

o Possibilidade de enviar uma mensagem para todos os usurios do curso. Basta

clicar no nome Todose enviar a mensagem como se estivesse enviando para

somente um usurio;

o As mensagens recebidas estaro disponibilizadas em uma caixa abaixo dos

participantes do curso. Em cada mensagem aparece quem a enviou, a data e a

hora. Nesta caixa aparecem somente as 10 ltimas mensagens. Abaixo das

mensagens, h um link para visualizao de todas as mensagens, que sero

abertas em outra tela. Quando uma mensagem for clicada, o corpo da mensagem

aparece. Abaixo da mensagem aberta h botes para Excluir e Responder ao

emissor;

Integrao s redes sociais:

o Integrar o AMADEUS com ferramentas de redes sociais online, oferecendo

meios de associar o logindo usurio do AMADEUS com os loginsdas redes

sociais online;

o Devido integrao, ao entrar no AMADEUS, o usurio automaticamente e

individualmente visualiza os posts relacionados rede social cadastrada. Aatualizao da visualizao dentro do AMADEUS deve ser automtica.

J no outro trabalho, como forma de criar novos meios de interao no ambiente de

ensino a distncia, PERRIS contribuiu com um mdulo de grupos para o LMS AMADEUS

[25]. Dessa forma foram definidos uma srie de requisitos funcionais e no-funcionais com os

quais o desenvolvimento da colaborao foi pautado:

Requisitos no-funcionais:o Indicar integrantes nos grupos; e

o Status da atividade (grupo ou usurio);

Requisitos funcionais:

o Habilitar a opo de criar grupos para o discente;

o Criar grupos;

o Habilitar tutor/moderador aos grupos;

o Modificar/editar grupo;

o Deletar grupo;

o Dar percepo ao desempenho ou participao do grupo;


26/75

25

o Comparao de desempenho entre grupos;

o Listar usurios cadastrados no curso;

o Log de acessos;

o

Andamento das atividades;

o Timeline(linha do tempo); e

o Relatrio das atividades.

Comparando os cdigos dessas colaboraes com o cdigo da verso 0.9.x do

AMADEUS foi possvel identificar, em termos de cdigo, o tamanho das contribuies, o que

nos ajudou a decidir qual seria a primeira a ser integrada. Dessa forma vimos que o cdigo de

PERRIS modificou cinquenta e sete (57) arquivos no projeto. J o de MEDEIROS modificou

mais de cem (100) arquivos de cdigo.Tambm foi analisada a consistncia das contribuies entre si e com a ltima verso

de modo a perceber se havia um padro de interfaces coerente. Esse tipo de informao

contribuiu para a elaborao de um processo de integrao e de um documento de diretrizes

para ser usado como base de uma anlise heurstica executada dentro da integrao.


27/75

26

4 RESULTADOS

Neste captulo sero apresentados os resultados obtidos na pesquisa, sendo eles o estudo

de caso de duas contribuies recentes da comunidade, um processo para manuteno da

consistncia de interfaces e um documento de diretrizes para o LMS AMADEUS.

4.1 ANLISE DAS CONTRIBUIES

De modo a aprofundar o entendimento do processo de colaborao e integrao do LMS

AMADEUS, realizamos um estudo de caso com duas contribuies recentes da comunidade,

baseadas na verso 0.9.x disponvel no Portal SPB [26]. Todo o fluxo ocorreu com o uso do Git

e da plataforma GitHub, sugeridos como novas ferramentas para a evoluo e integrao de

cdigos.

No estudo de caso foram executados todos os passos necessrios para realizar a

integrao de cdigos por meio do ambiente escolhido. Primeiro foi criada a organizao

ProjetoAmadeus para abrigar o repositrio AmadeusLMS, como pode ser visto na Figura 1,

onde foi colocada a ltima verso estvel do AMADEUS, disponvel no portal do Software

Pblico Brasileiro.

Figura 1. Tela do repositrio do Amadeus no GitHub

Fonte: Repositrio do LMS AMADEUS no GitHub4.

Como as contribuies eram baseadas na mesma verso foi necessrio criarmos umfork

para cada uma delas e adicionar as contribuies (ver Figura 2). Aps isso executamos umpull

requestque foi integrado ao repositrio principal aps a resoluo de uma srie de conflitos.

4Disponvel em . Acesso em 17 de outubro de 2014.


28/75

27

Figura 2. Mdulos das contribuies a serem adicionados no projeto

Fonte: O autor.

Todos os passos citados anteriormente foram executados com base nas prticas de uso

do GitHub e na documentao do Git. Dessa forma foi possvel vivenciar a integrao de um

projeto sem a anlise da consistncia, perceber de que forma isso se encaixa no fluxo e propor

um processo para a manuteno da consistncia dessas interfaces. A seguir detalhamos os

resultados do estudo de caso de cada contribuio.

4.1.1 Integrao da contribuio de MEDEIROS (2013)

Para realizar o estudo de caso da contribuio de MEDEIROS [24], foi necessrio criar

umforkdo repositrio oficial na conta temporria franciscotemp.A partir disso realizamos

um clonepara a mquina local de modo a possibilitar a manipulao do projeto. Em seguida

todos os arquivos do projeto foram substitudos pela verso da contribuio, o projeto foi

testado e um commit foi realizado localmente. Aps isso houve a sincronizao com o

repositrio mastere foi realizado um pedido de integrao por meio da funopull requestnoGitHub.

A partir disso nos colocamos na posio de gerente de configurao e comeamos a

analisar a solicitao por meio do relatrio de diferenas fornecido pelo servio. Essa primeira

anlise foi bastante confusa, j que houve apenas um commitcom todas as mudanas e muitos

dos arquivos no tiveram as diferenas identificadas, tendo sido dados como totalmente

modificados.


29/75

28

Figura 3. Opo de mergeautomtico atravs do GitHub

Fonte: Repositrio do LMS AMADEUS no GitHub.

Como a verso do repositrio oficial no tinha modificaes, o pedido de integrao da

contribuio de MEDEIROS pde ser integrado automaticamente por meio do GitHub (ver

Figura 3). Dessa forma a branchprincipal do repositrio passou a conter uma nova verso, com

um mergecontendo o mdulo social (ver Figura 4). Nesse ponto percebemos que poderia ser

importante criar uma branchpara realizar a integrao antes de colocar na master, j que em

uma situao real a contribuio poderia no ter sido devidamente testada.Figura 4. Mergeda contribuio de MEDEIROS concludo

Fonte: Repositrio do LMS AMADEUS no GitHub.

4.1.2 Integrao da contribuio de PERRIS (2013)

No segundo caso realizamos o estudo da contribuio de PERRIS, no qual tambm foi

preciso criar umforkdo repositrio oficial (ainda sem a integrao da verso de MEDEIROS)

com a conta temporria perristemp, em seguida fizemos um clone na mquina local para

adicionar as contribuies.

A partir disso todos os arquivos do projeto foram trocados pelos novos arquivos e testes

locais foram realizados. Nesse caso foi preciso alterar informaes de conexo com o banco de

dados, j que no estavam no padro do projeto original. Por fim, fizemos um commitcom toda

a contribuio, sincronizando com a mastere realizando o pedido de integrao.

Passando para o papel do gerente de configurao foi preciso ter maior cautela, pois a

integrao anterior j havia sido feita, acarretando a mudana de verso, ou seja, a verso base

da contribuio de PERRIS estava defasada. Nesse caso haviam duas solues possveis:

solicitar ao colaborador que realizasse o rebase, atualizando seu projeto com o que h de novo


30/75

29

no repositrio oficial, ou realizar um merge e corrigir possveis problemas numa branch

alternativa.

A escolha nesse caso foi criar uma novabranchpara realizar o merge, pois os problemas

de merge seriam idnticos nos dois casos, a nica mudana em quem realizaria o

procedimento. O prprio GitHub identificou essa necessidade por conta da verso defasada e

sugeriu executar os comandos da Figura 5, primeiro realizando o download da verso master

(com as contribuies de MEDEIROS) para a branchalternativa perristemp-master e depois

executando um merge(git pull) com a verso do repositrio de PERRIS.

Figura 5. Comandos do Git para realizar merge com a contribuio de PERRIS

Fonte: O autor.

Ao final desse processo, executado por meio do terminal, o Git informou quantos

conflitos ocorreram, no caso oitenta e trs (83). Dessa forma iniciamos as correes dos

conflitos para obter uma verso estvel do projeto com as duas contribuies, o que foi

alcanado aps alguns dias. Por fim essa verso integrada foi colocada na branch master,

gerando assim uma nova verso, com as duas contribuies.

4.2 PROCESSO DE INTEGRAO DE CONTRIBUIES DA COMUNIDADE

AMADEUS

A integrao das contribuies com foco em manter consistncias de interfaces

extensa, o que torna importante a elaborao de um processo para destacar as atividades dos

envolvidos nas colaboraes e do gerente de configurao.

O processo de integrao detalhado abaixo explicita o fluxo de aes para que uma

contribuio seja desenvolvida e integrada com o repositrio principal do LMS AMADEUS.Tambm so destacados os atores que participam desse processo, o ambiente utilizado e os

documentos e ferramentas relevantes para a execuo do mesmo. Esta elaborao foi realizada

com base no fluxo tradicional de colaboraes do ambiente previamente definido para ser usado

no projeto.

4.2.1 Atores

Dentro desse processo de integrao h dois atores principais, mas um terceiro pode serconsiderado: o gerente de configurao, o colaborador externo e o colaborador interno.


31/75

30

O gerente de configurao detm o controle sob o repositrio oficial e normalmente

um grande entendedor do cdigo e da arquitetura do sistema. Porm, no caso do AMADEUS,

ele tambm precisa estar atento a detalhes relacionados interface, com o auxlio de uma

documentao especfica. A principal funo desse ator integrar cdigos das contribuies de

terceiros, garantindo a qualidade e a integridade do sistema, tanto em termos funcionais quanto

em relao interface.

Pressman, em Software Engineering: A Practitioner's Approach[23],define de forma

mais abrangente o conceito de gerncia de configurao como:

...conjunto de atividades projetadas para controlar as mudanas pela identificaodos produtos do trabalho que sero alterados, estabelecendo um relacionamentoentre eles, definindo o mecanismo para o gerenciamento de diferentes verses destes

produtos, controlando as mudanas impostas, e auditando e relatando as mudanasrealizadas.

O colaborador externo aquele que cria uma verso particular do repositrio oficial, por

meio dofork, no qual desenvolve todas as alteraes que achar necessrio para corrigir um bug

ou acrescentar uma nova funcionalidade. A principal funo dele evoluir o cdigo tendo em

vista os interesses globais do projeto, de tal forma que essas mudanas podem eventualmente

ser includas na verso oficial aps uma avaliao positiva do gerente de configurao.

J o colaborador interno est ligado diretamente ao repositrio oficial. Assim, ele

capaz de publicar alteraes sem a necessidade de passar pelo crivo do gerente de configurao.

Nesse caso de extrema importncia que o colaborador tenha amplo conhecimento sobre o

sistema, desde a arquitetura at a padres de desenvolvimento e de interfaces.

4.2.2 Ambiente

O ambiente de colaborao usado nesse processo o GitHub [22], um servio webque

permite o armazenamento de repositrios de projetos, open sourceou proprietrios, com o

controle de verso Git. O servio tambm possibilita grande interao entre os membros das

comunidades, pois so disponibilizados fruns, wikie gerenciamento de issues.

Sendo assim os atores podem se comunicar em caso de dvidas ou correes, como por

exemplo: um colaborador realiza alteraes indevidas e as submete ao repositrio oficial,

consequentemente o gerente de configurao no aceita a colaborao e tem a possibilidade de

informar ao colaborador que alteraes precisam ser realizadas por meio de um frum criado

apenas para essa contribuio.

Outra possibilidade de um colaborador obter acesso aos objetivos, a viso e s

necessidades do projeto para manuteno e evoluo, isso por meio da wiki que possui


32/75

31

documentos criados pelos colaboradores internos. Para um acompanhamento detalhado o

gerente de configurao pode obter acesso a todas as operaes j realizadas dentro do

repositrio e a relatrios sobre a atividade dos colaboradores.

4.2.3 Documentos

Durante o processo, os colaboradores iro se confrontar com um conjunto de issuesno

GitHub, que so erros e pontos de melhorias do sistema. Em cada issue registrada h uma

conversa no qual possvel entrar em contato com os desenvolvedores oficiais e a comunidade,

tirar dvidas e sugerir solues. A anlise dessa documentao e do histrico de conversas com

outros colaboradores, principalmente sobre as issues das quais deseja tratar, so de grande

importncia para gerar colaboraes pertinentes.Os cdigos tambm podem ser considerados documentos e so fundamentais para o

entendimento do projeto em termos tcnicos. Dessa forma todos os cdigos esto disponveis

para acesso por meio do ambiente de colaborao, assim como o histrico de modificaes

realizadas em cada um deles.

Alm disso estar disponvel um documento de diretrizes do AMADEUS, necessrio

para que os colaboradores entendam de que forma devem usar determinados componentes e

qual o padro visual adotado pelo sistema. O intuito desse documento, que ser detalhado maisadiante, na seo 4.3, minimizar problemas com a inconsistncia das novas interfaces a serem

desenvolvidas.

4.2.4 Ferramentas

Nesse cenrio as ferramentas so usadas como facilitadores para a execuo do

processo, auxiliando o desenvolvimento, os testes e a integrao. Porm, antes de definir as

ferramentas necessrio citar as tecnologias que o AMADEUS usa, so elas: Java 75: linguagem de programao usada na camada de negcio;

JSP6: tecnologia para criao desitesdinmicos com Java;

Hibernate7: tecnologia usada para fazer conexes e executar comandos no banco de

dados; e

PostgreSQL8: sistema de banco de dados usado pelo projeto.

5Disponvel em . Acesso em 18 de novembro de 2014.6Disponvel em . Acesso em 18 de novembrode 2014.7Disponvel em . Acesso em 18 de novembro de 2014.8Disponvel em . Acesso em 18 de novembro de 2014.


33/75

32

Como ferramenta de desenvolvimento, recomendado o uso do Eclipse9, por haver

integrao com todas as tecnologias usadas no projeto. Tambm primordial ter Java

Development Kit 7 (JDK 7) completo e instalado no computador. Como servidor local

interessante o uso do TomCat 610, pois o projeto j est configurado prevendo o uso do mesmo.

Em termos de sistema de banco de dados importante ter disponvel o PostgreSQL na

verso 4 ou mais recente e ter a ferramenta PGAdmin 311 para gerenciar. Alm disso

necessrio configurar uma base de dados chamada amadeus_web, funcionando na porta 5432

e com administrador padro postgres com senha postgres. Em caso de divergncias

necessrio alterar os arquivos de configurao localmente.

4.2.5

EtapasO primeiro passo para se tornar um colaborador o entendimento das reais necessidades

do sistema, dos objetivos e da viso do projeto. A partir disso o desenvolvedor cria umforkdo

repositrio oficial para trabalhar de forma isolada. Assim a cada progresso commitsdevem ser

realizados nesse repositrio local, de modo a manter um histrico da evoluo do cdigo.

Com o desenvolvimento de melhorias ou correes em fase de concluso, o colaborador

deve executar testes exploratrios, verificando os fluxos criados ou modificados para reduzir

as possibilidades de erro. Caso encontre problemas ser necessrio corrigi-los at que os fluxosestejam funcionando dentro do esperado, mas ainda assim podem ocorrer erros que sero

tratados mais adiante. Ainda antes de submeter as contribuies, o desenvolvedor deve atualizar

a base do repositrio para a ltima verso oficial (rebase) e corrigir possveis erros.

Aps concludas as alteraes, o colaborador as submete para o repositrio oficial por

meio de umpull request, no qual ter espao para descrever o que foi realizado. Em seguida o

gerente de configurao notificado sobre a submisso e inicia a anlise da colaborao, tanto

observando os cdigos quanto os executando. A cada problema encontrado ele informa aodesenvolvedor por meio do frum dessa contribuio. O colaborador pode aceitar prontamente

a anlise ou prosseguir com a discusso at que cheguem numa concluso sobre o que deve ser

feito com a modificao.

A partir do momento que todas as modificaes passem por essa primeira anlise com

sucesso, o gerente de configurao inicia a etapa de integrar os cdigos com o projeto oficial.

O primeiro passo para isso criar uma branchsecundria para realizar a operao, em seguida

9Disponvel em . Acesso em 19 de novembro de 2014.10Disponvel em . Acesso em 19 de novembro de 2014.11Disponvel em . Acesso em 19 de novembro de 2014.


34/75

33

realizar o mergeautomtico da verso oficial com a nova contribuio, por meio do ambiente,

e verificar se existem conflitos possveis de serem resolvidos localmente ou que precisam voltar

para o desenvolvedor. No segundo caso o uso do frum ocorre novamente, no qual discutida

a soluo do impasse para uma integrao ser bem sucedida.

Tambm existe a possibilidade de ocorrer de vrias submisses com base na verso

atual, e dessa forma apenas a primeira integrada de forma automtica, tendo poucos ou

nenhum problema. Porm a partir da todas as outras contribuies no tm a mesma verso

base, j que gerada uma nova aps a integrao. Dessa forma o ambiente sugere a realizao

do merge via linha de comando. Nesse caso tambm necessrio criar uma branch para

executar a integrao. Depois disso realizar um mergeda verso oficial com a contribuio

atravs do comandopull. Ao fim do mergeser informado quantos conflitos ocorreram. Todosdevem ser corrigidos diretamente nos arquivos.

Em seguida a integrao deve estar funcional. Assim possvel executar a anlise

heurstica para manuteno da consistncia de interfaces do AMADEUS e verificar se as novas

interfaces esto dentro do esperado para o projeto. Se encontrar falhas, o gerente de

configurao sugere melhorias para o desenvolvedor por meio do frum e aguarda as

modificaes. Assim que a contribuio estiver apta, ou seja, sem falhas, sem conflitos de

integrao e com a interface consistente, o gerente de configurao a transfere para a branchprincipal (master).

4.2.6 Modelo

Para sintetizar o processo descrito anteriormente foi utilizada a notao BPMN

(Business Process Model and Notation) [27] com a ferramenta Bizagi Modeler12. Dessa forma

o fluxo exibido em eventos (crculos), tarefas (retngulos) e decisores (losangos) [27]. Por

conta da extenso da imagem, a mesma foi dividida em seis partes e os fluxos entre as partes

foi numerado.

12Disponvel em . Acesso em 10 de dezembro de2014.


35/75


36/75


37/75

36

Figura 8. Processo de integrao de contribuies da comunidade AMADEUS (Parte 3)

Fonte: O autor.

Na terceira parte (ver Figura 8) h um decisor, pois se o colaborador no concordar

possvel entrar em contato com o gerente, que recebe a reposta e pode no concordar, realizando

um ciclo de comunicao, at chegarem a uma deciso final com todas as alteraes realizadas.


38/75

37


Fonte: O autor.

Na Figura 9 o gerente de configurao cria uma branch temporria para executar a

integrao, e aps isso realiza o merge e verifica se h conflitos. Em caso positivo v o nvel de

criticidade para informar ou no ao desenvolvedor.


39/75

38


Fonte: O autor.

Na Figura 10 o gerente pode informar os conflitos ao desenvolvedor e aguardar a

soluo ou pode resolver os conflitos localmente. Caso no existam conflitos a anlise

heurstica ser a subtarefa a ser realizada (melhor descrita na figura 13), e por fim verificado

se essa anlise encontra inconsistncias.


40/75

39


Fonte: O autor.

Na ltima parte (ver Figura 11) o gerente pode informar as inconsistncias ao

desenvolvedor ou se no houver nenhuma ento ir mover o projeto para o repositrio oficial e

ter a contribuio integrada.


41/75


42/75

41

mudanas realizadas na colaborao a ser integrada. Em seguida os problemas so

identificados, priorizados e solues so propostas, concluindo assim a anlise.


43/75

42

4.3 DOCUMENTO DE DIRETRIZES DO AMADEUS

O ponto de partida para a elaborao do documento se deu com uma anlise em

documentos de diretrizes de outros projetos de software livre, dos quais o principal foi o

Openredu [13], uma plataforma educacional desenvolvida na UFPE. Na documentao constam

princpios nos quais a interface se baseou e especificaes de cores, modelo de corpo,

tipografia, tabelas, listas, formulrios, botes, navegao, alertas, janelas e cones.

Figura 14. Documento de diretrizes de usabilidade para aplicativos do FirefoxOS

Fonte: Firefox OS Guidelines13.

Ainda assim foi analisada a documentao do Firefox OS (ver Figura 14) [14], um

sistema operacional para dispositivos mveis que permite o desenvolvimento de aplicaes por

meio de um padro visual muito bem definido. Nessa especificao h sees sobre paleta decores, tipografia, cabealhos, planos de fundo, listas, botes, barras de ferramenta, campos de

texto, seletores e cones.

Com base nisso foi percebido uma estrutura que se repete nas duas documentaes.

Sendo assim esse formato foi parcialmente adotado na elaborao da primeira verso do

documento de diretrizes do LMS Amadeus. Nesse caso alguns tpicos no eram necessrios e

outros foram unidos. No fim, os tpicos definidos foram: princpios, grid(modelo de corpo),

cores, tipografia, formulrios e navegao.

O desenvolvimento do contedo da documentao se deu com a anlise de folhas de

estilo do projeto para cada componente necessrio e com o estudo de documentao legado do

projeto. Nela h wireframes (prottipos) para todas as telas desenvolvidas no sistema,

implementando casos de uso tambm definidos em documentao.

Nesse documento de diretrizes so destacados os princpios utilizados na elaborao de

interfaces do projeto, o esquema de cores e fontes, como os mdulos esto organizados na tela

e como se estruturam formulrios, botes e a navegao.

13Disponvel em < https://www.mozilla.org/en-US/styleguide/products/firefox-os/>. Acesso em: 13 de novembrode 2014.


44/75

43

4.3.1 Princpios

Considerando o contexto da elaborao de interfaces para webh dez (10) princpios

bsicos, definidos por NIELSEN [16] e selecionados por PREECE [8], que podem ser seguidos

na elaborao de uma interface web:

1. Visibilidade de status do sistema - o sistema deve manter o usurio informado sobre o

que est acontecendo, incluindofeedbackspara as aes do usurio em tempo hbil. Na

prtica podemos citar o uso de mensagens de sucesso e erro como recursos-chave para

seguir esse princpio;

2. Compatibilidade do sistema com o mundo real - as pginas devem possuir linguagem

simples e acessvel para o pblico alvo. Por isso importante usar um vocabulrioadequado ao contexto;

3. Controle do usurio e liberdade - necessrio permitir que o usurio possa voltar de

pginas indesejadas. Como forma de atingir esse princpio se faz til o uso de botes

para voltar pgina anterior e caminhos de pgina (breadcrumbs), nos quais o usurio

tem a noo do que percorreu para chegar quela tela;

4. Consistncia e padres - tambm importante manter as aes consistentes dentro do

sistema, de modo que aes similares sempre ocorram de modo esperado, com umretorno visual coerente. Para isso importante o uso de documentao de padres

visuais, como por exemplo o guia de diretrizes para web do governo americano,

Usability.gov [5], ou documentos especficos para um sistema, como este em

desenvolvimento;

5. Ajudar os usurios a reconhecer, diagnosticar e corrigir erros - necessrio que o

sistema exiba mensagens claras em casos de erro, e que d possibilidades ao usurio

para solucion-lo de forma adequada;6. Preveno de erros - na elaborao das telas necessrio analisar a facilidade do usurio

cometer erros e entender o porqu. Geralmente caixas de confirmao e botes de

cancelar so boas sadas para que menos erros ocorram;

7. Reconhecer, em vez de relembrar - significa reduzir a necessidade da memria

permanente do usurio guardar informaes sobre caminhos complexos ou comandos

para acessar determinada pgina ou funcionalidade. Portanto, necessrio estimular o

reconhecimento, de modo que o usurio realize atividades de forma intuitiva;

8. Flexibilidade e eficincia no uso - importante que o sistema disponha de atalhos para

que usurios experientes realizem tarefas de forma mais gil. De modo a atingir esse


45/75

44

objetivo, o uso de menus de contexto ou de sugestes a itens relacionados so

possibilidades;

9. Esttica e design minimalista - nas telas do sistema necessrio manter apenas

informaes relevantes, de modo que o usurio no encontre barreiras por conta de uma

infinidade informaes desnecessrias; e

10.Ajuda e documentao - em todos os pontos dositedevemos manter acesso s pginas

de ajuda ou s dicas que auxiliem o usurio na execuo de uma tarefa. Dessa forma

possvel usar pginas deF.A.Q.(perguntas frequentes), para esclarecer as dvidas mais

comuns sobre a pgina, e tooltips(dicas flutuantes), como forma de explicar o que deve

ser preenchido em um campo, por exemplo.

4.3.2 Grid

A partir dos wireframesdo projeto foi construdo ogridque representa a estrutura geral

das pginas. Tambm foram calculados os tamanhos de largura, altura e espaamento das reas.

Esse tipo de informao orienta o desenvolvimento de novas funcionalidades que exijam o uso

de uma ou mais regies dositedentro do layoutpadro. Na Figura 15 destacada a finalidade

de cada rea dogridcuja funcionalidade ser descrita adiante.

Figura 15. reas do gridcom a finalidade proposta

Fonte: O autor.

Logine dados do usurio: nessa regio esto contidas informaes referentes ao usurio,

como o nome, alm de prover acesso ao perfil e ter uma opo para sair do sistema, porm no


46/75

45

caso de no haver sesso ativa ser exibido formulrio de login. Portanto essa rea contempla

funcionalidades diretamente associadas ao usurio e no deve ser usada para outro fim.

Logotipo: essa rea contm o logotipo da verso atual do sistema e deve ser alterada a

cada novo release.

Navegao global: um menu horizontal que contm opes relacionadas ao projeto,

como por exemplo um linkde acesso a uma pgina sobre a comunidade do AMADEUS. Esse

menu tambm pode conter opes de configurao geral do sistema e deve ser fixo para todas

as pginas. Portanto, no deve ter informaes contextualizadas com o estado atual.

Ttulo da pgina: contm o ttulo da pgina que est sendo exibida e no deve ser exibido

caso esteja na pgina inicial.

Caminho (breadcrumb): exibe uma lista horizontal das pginas percorridas para chegarna pgina atual, no qual todas as pginas anteriores devem conter um linkde acesso direto.

Navegao local: essa coluna deve conter informaes e/ou menusverticais referentes

pgina exibida no momento. O intuito dessa regio prover opes contextualizadas.

Portanto, no devem haver funes gerais do sistema.

Contedo: a principal regio da pgina, no qual exibido o contedo escolhido pelo

usurio. Tem fins gerais e deve ser usada na criao de novas funcionalidades que exijam uma

grande rea de tela.Bloco opcional: essa regio no possui opes previstas e pode ser usada para fins

quaisquer em uma melhoria ou um novo recurso. Portanto essa rea pode no ser exibida em

uma pgina, permitindo assim mais espao para o contedo.

Texto de rodap: contm informaes sobre licena de uso e verso dosoftware. Dessa

forma, no deve ser usada em outra situao, e sim atualizada quando necessrio.


47/75

46

Figura 16. Gridde duas colunas com dimenses de largura e espaamento

Fonte: O autor.

Alm disso h componentes que possuem largura fixa, conforme pode ser observado na

Figura 16. Sendo px o smbolo da unidade pixel, navegao local possui 139px de largura e

espaamento 5px e contedo possui largura de 501px e 15px de espaamento. J a largura total

da pgina de 680px.

Figura 17. Gridde trs colunas com dimenses de largura e espaamento

Fonte: O autor.


48/75

47

Tambm existe a possibilidade de haver um bloco opcional, com largura e espaamento

idnticos a navegao local, dessa forma a rea de contedo reduzida para 350px de largura,

como ilustrado na Figura 17.

Figura 18. Gridcom dimenses de altura e espaamento

Fonte: O autor.

Do mesmo modo a altura fixada em algumas regies da pgina, conforme visto na

Figura 18. A regio de logotipo possui altura 66px e espaamento 2px, j a navegao globalpossui 13px de altura e espaamento de 1px, a rea de ttulo da pgina e caminho possui 36px

de altura e 2px de espaamento e o texto de rodap possui 40px de altura e 8px de espaamento.

4.3.3 Cores

A paleta de cores foi definida principalmente como forma de manter a identidade visual

do projeto, mas tambm para destacar informaes relevantes com base no senso comum, como

por exemplo em mensagens de sucesso e erro. Quatro conjuntos de cores foram usados, duasescalas de verde, uma escala de cinza e uma de vermelho.

Nas imagens das Figura 19, Figura 20, Figura 21 e Figura 22 esto representadas as

cores definidas na paleta, onde o quadrado contm a cor de fato. Ao lado de cada um h o valor

hexadecimal e os valores no modo RGB (vermelho, verde, azul). Antes, porm, necessrio

definir que textos pequenos so compostos por at trinta (30) palavras e textos mdios so

compostos por at cem (100) palavras. Alm disso as reas pequenas representam at 10% da

tela e as reas mdias representam at 30% da tela.


49/75

48

Figura 19. Paleta de tons de verde

Fonte: O autor.

Os tons de verde da Figura 19 tm uso genrico no sistema. So recomendados quando

se deseja destacar reas e textos menores. O verde mdio dessaturado (primeira cor) mais

recomendado na definio de planos de fundo. J o verde mdio (segunda cor) pode ser usado

para definir bordas e o verde-escuro (terceira cor) pode ser usado em outras situaes que seja

necessrio destacar uma palavra ou texto curto.

Figura 20. Paleta de tons de verde azulado

Fonte: O autor.

Os tons de verde azulado da Figura 20 podem ser usados para definir detalhes, como

bordas, e alteraes de estado em botes, por exemplo. A cor verde-clara (primeira cor) podeser usada como plano de fundo de uma regio clara, possibilitando mais destaque ou maior


50/75

49

sensao de organizao na pgina. O verde mdio (segunda cor) pode ser usado em textos,

destacando informaes relevantes ou trechos de tamanho mdio e a cor verde-escura (quarta

cor) usada no texto de mensagens de sucesso. No entanto o verde mdio mais saturado

(terceira cor) possui uso padro no sistema, sendo usado nos linksno estado em que o mouse

est sobre o texto.

Figura 21. Paleta de tons de cinza

Fonte: O autor.

Os tons de cinza da Figura 21 so usados de forma menos restrita no sistema.

Basicamente, o contedo de todas as interfaces possui fundo base branco (primeira cor) e a

maior parte dos textos est em cor preta (sexta cor), inclusive os linksem estado normal (quando

o mouseno est sobre a regio).

J os tons intermedirios tm uso mais especfico. O cinza mais claro (segunda cor)

usado como plano de fundo em partes do contedo, quando se deseja dar uma noo de diviso

ou de continuidade em uma linha. O cinza mdio (terceira cor) usado no plano de fundo

externo do site e de bordas em geral. Da mesma forma, o cinza escuro (quinta cor) usado em


51/75

50

bordas, mais especificamente em bordas de janelas sobrepostas e notificaes gerais. O outro

cinza mdio (quarta cor) usado em planos de fundo de formulrios, preferencialmente nas

linhas das etiquetas.

Figura 22. Paleta de tons de vermelho

Fonte: O autor.

Os tons de vermelho da Figura 22 indicam situaes que podem ter um resultado

indesejado, como por exemplo em aes de excluso ou de cancelamento. Tambm

recomendado que notificaes de erro usem esse conjunto cores. O vermelho mais claro

(primeira cor) deve ser usado como plano de fundo e o vermelho escuro (terceira cor) como cordo texto regies de alerta. Caso o plano de fundo dessas regies necessite ser branco, ento o

vermelho forte (segunda cor) usado como cor do texto.

Ao definir uma cor importante pensar que o texto deve contrastar com o plano de

fundo definido para no dificultar a leitura. Dessa forma caso o plano de fundo seja claro ento

o texto deve ser escuro. Alm disso o uso das cores deve ser feito com cautela, sempre buscando

manter a finalidade para que foram definidas e evitando exageros. Como forma de consulta o

quadro 2 resume a finalidade de cada cor, junto aos valores hexadecimal e RGB.Quadro 2. Paleta de cores para o AMADEUS

Cor Hexadecimal RGB Finalidade

#AAC46C (170, 196, 108)Planos de fundo em reas pequenas ou mdiasde contedo.

#94C92E (148, 201, 46)Bordas em reas pequenas ou mdias decontedo.

#009900 (0, 153, 0)Textos curtos ou palavras em destaque.

#AED1AD (174, 209, 173)

Plano de fundo em linhas de tabelas, etiquetas

de formulrios, ttulos de contedo ou em outrasregies de destaque.


52/75

51

#52A07E (82, 160, 126)Textos mdios em destaque.

#2CA457 (44, 164, 87)Links em estado ativo ou com o mousesobreposto.

#35784C (53, 120, 76) Texto de mensagens de sucesso.

#FFFFFF (255, 255, 255)Plano de fundo geral de contedo.

#E7E7E7 (231, 231, 231)Planos de fundo em reas pequenas ou mdiasde contedo.

#CCCCCC (204, 204, 204)Plano de fundo externo e bordas de layoutdosite.

#C7C7C7 (199, 199, 199)Plano de fundo em formulrios,

preferencialmente nas linhas das etiquetas.

#999999 (153, 153, 153) Bordas de janelas sobrepostas e bordas denotificaes genricas.

#000000 (0, 0, 0)Texto padro e de linksem estado normal.

#FFB8B0 (255, 184, 176)Plano de fundo em regies de alerta e erro.

#FF1800 (255, 24, 0)Cor do texto em regies de alerta caso o planode fundo seja branco, possivelmente em reasde contedo.

#990000 (153, 0, 0)Cor do texto em regies de alerta e erro quandoo plano de fundo for vermelho claro.

Fonte: O autor.

4.3.4 Tipografia

A tipografia o processo de organizar e definir estilos em fontes de texto, e tem papel

importante dentro do design do projeto. Atravs dela possvel estabelecer hierarquias e

adicionar uma ordem estrutural dentro da pgina, os artifcios mais comuns para isso so a

variao de tamanhos, pesos e tipos de fonte.

Figura 23. Exemplo de fonte sem serifa

Fonte: DaFont14.

No projeto AMADEUS a famlia de fontes escolhida foi Sans Serif (do latim, sem

serifa), que possui traos mais simples como a da Figura 23. Na folha de estilos foi definida

uma ordem de prioridade em que a primeira a fonte Arial, disponvel em computadores com

o sistema operacional Windows. Em segundo a fonte Helvetica, disponvel em computadores

14Disponvel em < http://www.dafont.com/coolvetica.font?text=AaBbCc> Acesso em 29 de dezembro de 2014.


53/75

52

com o MacOS, s ser aplicada se no for possvel a opo anterior. Ainda assim, caso nenhuma

das duas esteja presente no dispositivo, outra fonte da mesma famlia (escolhida pelo

navegador) ser encarregada de compor a pgina.

Em toda a folha de estilos as fontes esto personalizadas com tamanhos na unidade em,

muito aplicada na rea de tipografia e teve o uso considerado uma boa prtica no CSS2

(Cascading Style Sheets Level 2)15. Como principal vantagem essa unidade possui dimenses

relativas (por vezes expressas em notao decimal), tornando as fontes adaptveis ao tamanho

da tela. O tamanho relativo calculado com base em um tamanho raiz definido em pixels,

geralmente no seletor bodyda folha de estilos da pgina. Caso no seja definido, o navegador

definir qual o melhor tamanho de referncia.

Figura 24. Formatao dos ttulos em textos

Fonte: O autor.

Os ttulos das pginas devem estar em proporo a Figura 24 , ttulo 1 refere-se tag

HTML , ttulo 2 e ttulo 3 . Os ttulos 1 e 2 possuem tamanhos relativos

de 1,4em e 1,3em, respectivamente, peso negrito e no possuem espaamento nem margem. J

o ttulo 3 possui tamanho relativo 1em, peso negrito, margem inferior de 1px e margem superior

de 2px.

Figura 25. Formatao das listas em textos

Fonte: O autor.

15Disponvel em < http://www.w3.org/TR/CSS21/>. Acesso em 15 de dezembro de 2014.


54/75

53

As listas referentes tagdevem estar conforme a Figura 25, na qual a lista possui

um marcador do tipo disco e as fontes tm tamanho 0,7em. O espaamento esquerda de

40px e as margens superior e inferior possuem 12px.

Figura 26. Formatao das tabelas de contedo

Fonte: O autor.

J as tabelas no possuem espaamento nem margem no container, mas as

clulas possuem espaamento de 1px e margem de 2px. Alm disso, o tamanho de fonte

usado nas tabelas de 0,9em. O estilo padro proposto para o projeto no define borda nem

plano de fundo para as tabelas, mas isso pode ser feito por meio de classes customizadas

seguindo o padro de cores definido anteriormente.

Figura 27. Formatao de pargrafos e l inksde texto

Fonte: O autor.

Os pargrafos possuem margem superior e inferior de tamanho 12px, mas no possuem

espaamento. O tamanho de fonte dessas reas de 0,7em com peso normal, mas caso haja

necessidade de destacar alguma palavra, como na Figura 27, o recurso de negrito pode ser usado

por meio da tag, alterando a palavra para deixa-la em evidncia. Ainda na Figura

27 exibido um link(na palavra CCTE) em estado de mouse sobreposto, identificado como

hoverno CSS, no qual aparece sublinhado e com cor verde de hexadecimal #2CA457. J o

estado normal dos linksdeve manter o padro do texto, com fontes de tamanho 0,7em, cor preta

e sem sublinhado.

No quadro 3 so apresentadas as especificaes referentes a cada item de forma

resumida:

Quadro 3. Especificaes de formatao para componentes HTML no AMADEUSItem TagHTML Especificaes

Ttulo 1 Tamanho 1,4em, peso negrito, sem margem e semespaamento.


55/75

54

Ttulo 2 Tamanho 1,3em, peso negrito, sem margem e semespaamento.

Ttulo 3 Tamanho 1em, peso negrito, margem inferior de1px, margem superior de 2px e sem espaamento.

Lista Marcador tipo disco, fonte de tamanho 0,7em,espaamento esquerda de 40px e margenssuperior e inferior de 12px.

Tabela Sem margem, sem espaamento e sem bordas.

Clula da tabela Fonte de tamanho 0,9em, espaamento de 1px emargem de 2px.

Pargrafo

Tamanho 0,7em, peso normal, margem superior einferior de tamanho 12px e sem espaam

Documents

Paulo Henrique da Cruz Pereira. Consistência de Interfaces em Software Livre: Processo e Guia de Recomendações para o LMS AMADEUS. 2015. Trabalho de Conclusão de Curso. (Graduação