Universidade Federal de Pernambuco Centro de Informática

UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMTICA
GRADUAO EM CINCIA DA COMPUTAO
CONSISTNCIA DE INTERFACES EM SOFTWARE LIVRE:

PROCESSO E GUIA DE RECOMENDAES PARA O LMS
AMADEUS
Paulo Henrique da Cruz Pereira

Trabalho de Graduao
Recife
FEVEREIRO DE 2015
UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO 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 EM

CINCIA DA COMPUTAO do CENTRO DE
INFORMTICA da UNIVERSIDADE FEDERAL DE
PERNAMBUCO como requisito parcial para obteno do
grau de CINCIA DA COMPUTAO.
Orientador(a): Prof Dr Alex Sandro Gomes
Recife
FEVEREIRO DE 2015
minha famlia.
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 a
oportunidade 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, me
ajudaram ou passaram pela minha vida de forma positiva, sou grato.
RESUMO
Neste trabalho iremos entender fenmenos relativos consistncia de interfaces em
contribuies s comunidades de software livre, 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 de guidelines, inspeo de consistncia.
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.
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 merge automtico atravs do GitHub ....................................................... 28
Figura 4. Merge da contribuio de MEDEIROS concludo.................................................... 28
Figura 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) ...... 34
Figura 10. Processo de integrao de contribuies da comunidade AMADEUS (Parte 5) .... 38
Figura 11. Processo de integrao de contribuies da comunidade AMADEUS (Parte 6) .... 39
Figura 12. Subprocesso de desenvolver alterao no cdigo ................................................... 40
Figura 13. Subprocesso de realizar anlise heurstica .............................................................. 40
Figura 14. Documento de diretrizes de usabilidade para aplicativos do FirefoxOS ................ 42
Figura 15. reas do grid com a finalidade proposta ................................................................ 44
Figura 16. Grid de duas colunas com dimenses de largura e espaamento............................ 46
Figura 17. Grid de trs colunas com dimenses de largura e espaamento ............................. 46
Figura 18. Grid com dimenses de altura e espaamento ........................................................ 47
Figura 19. Paleta de tons de verde ............................................................................................ 48
Figura 20. Paleta de tons de verde azulado .............................................................................. 48
Figura 21. Paleta de tons de cinza ............................................................................................ 49
Figura 22. Paleta de tons de vermelho ...................................................................................... 50
Figura 23. Exemplo de fonte sem serifa ................................................................................... 51
Figura 24. Formatao dos ttulos em textos ............................................................................ 52
Figura 25. Formatao das listas em textos .............................................................................. 52
Figura 26. Formatao das tabelas de contedo ....................................................................... 53
Figura 27. Formatao de pargrafos e links de texto .............................................................. 53
Figura 28. Formulrio de buscar um curso ............................................................................... 54
Figura 29. Formulrio de cadastrar usurio .............................................................................. 55
Figura 30. Exemplo de HTML para formulrio consistente .................................................... 55
Figura 31. Formulrio simplificado .......................................................................................... 56
Figura 32. Navegao global .................................................................................................... 56
Figura 33. Breadcrumb ............................................................................................................. 57
Figura 34. Navegao local ...................................................................................................... 57
Figura 35. Boto com layout quebrado no bloco de mensagens .............................................. 58
Figura 36. Feedback de mensagem enviada sendo exibido ...................................................... 59
Figura 37. Tela de exibir todas as mensagens .......................................................................... 59
Figura 38. Tela de integrar redes sociais .................................................................................. 60
Figura 39. Tela de monitorar redes sociais ............................................................................... 60
Figura 40. Menu da tela de grupos ........................................................................................... 61
Figura 41. Tela de criar grupo .................................................................................................. 62
Figura 42. Tela de visualizar grupos ........................................................................................ 62
Figura 43. Tela de relatrio de atividades ................................................................................ 63
Figura 44. Boto com layout corrigido no bloco de mensagens .............................................. 65
Figura 45. Tela de exibir todas as mensagens corrigida ........................................................... 65
Figura 46. Tela de monitorar redes sociais corrigida ............................................................... 66
Figura 47. Tela de integrar redes sociais corrigida ................................................................... 66
Figura 48. Menu e lista de grupos corrigidos ........................................................................... 67

Figura 49. Tela de criar grupo corrigida ................................................................................... 67
Figura 50. Tela de atividades do grupo ( esq) e tela de relatrio ( dir) corrigidas ................ 67
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 .................................................................... 63
Quadro 5. Resultado da reviso de guidelines .......................................................................... 64
SUMRIO
1
Introduo.......................................................................................................................... 11
1.1
Motivao .................................................................................................................. 11
1.2
Contexto ..................................................................................................................... 11
1.3
Objetivos .................................................................................................................... 12
Consistncia de interfaces em software livre .................................................................... 13

2.1
Projetos de software livre .......................................................................................... 13
2.2
Os problemas em projetos de software livre .............................................................. 13
2.3
Consistncia de interfaces em projetos de software livre .......................................... 14
2.4
Tentativas de soluo: Usabilidade em projetos de software livre ............................ 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 de software livre............. 18
2.5.1
Versionamento com Git ...................................................................................... 18
2.5.2
Colaborao por meio do GitHub....................................................................... 20
Mtodo .............................................................................................................................. 21
3.1
Objetivos .................................................................................................................... 21
3.2
Reviso da literatura .................................................................................................. 21
3.3
Estudos de caso .......................................................................................................... 22
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
4.3.5
Formulrios ......................................................................................................... 54
4.3.6
Navegao .......................................................................................................... 56
4.4
Reviso de guidelines e inspeo de consistncia ..................................................... 58
4.4.1
Anlise da contribuio de MEDEIROS (2013) ................................................ 58
4.4.2
Anlise da contribuio de PERRIS (2013) ....................................................... 61
4.4.3
Avaliao dos resultados .................................................................................... 63
4.5.
Reviso do cdigo para consistncia e publicao no Portal SPB ............................ 64
Discusso........................................................................................................................... 69
Concluso .......................................................................................................................... 71
6.1
Limitaes .................................................................................................................. 71
6.2
Trabalhos futuros ....................................................................................................... 72
Referncias Bibliogrficas ........................................................................................................ 73
11
INTRODUO
Em software livre, 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 de software
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. Dessa
forma os desenvolvedores podem tomar decises erradas, fazendo com que as interfaces sejam
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 de guidelines e 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.
13
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
software livre.
2.1
PROJETOS DE SOFTWARE LIVRE

Segundo a Free Software Foundation, software livre definido como um software que
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 de software proprietrio, no
qual uma corporao controla o programa e esse controla o usurio.
O acesso ao cdigo-fonte pr-requisito para um programa ser software livre, 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 de software livre 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 SOFTWARE LIVRE

Colaboradores 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
software livre.
As barreiras encontradas foram divididas em categorias, e a principal categoria
encontrada na pesquisa [1] foi a de problemas com documentao, j que novos colaboradores
necessitam aprender aspectos sociais e tcnicos do projeto para contribuir. Especificamente os
14
problemas relatados foram relacionados ausncia de documentao sobre: 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, respostas
indelicadas, 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 de
cdigo.
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 bugs defasada; e encontrar uma tarefa para comear. E
por fim, na categoria de comportamento do colaborador foram encontradas duas barreiras:
ausncia de commits e subestimar o desafio.
2.3
CONSISTNCIA DE INTERFACES EM PROJETOS DE SOFTWARE LIVRE

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 de software livre tendem a ter
maior resistncia na adoo desse tipo de filosofia. RAJANEN [9] enumerou as caractersticas
15
da filosofia do software livre, das quais Talk is cheap, show me the code (Falar fcil,
mostre-me o cdigo, em portugus) um indicativo de que o desenvolvimento centrado no
usurio e preocupado com a consistncia de interfaces no prioridade.
A afirmativa de que sistemas de cdigo aberto tem interfaces pouco refinadas, em partes
verdade, pois geralmente esses projetos so feitos de engenheiros para engenheiros [10].
Existem poucos profissionais especialistas em usabilidade dentro desse ecossistema, por isso
um nmero reduzido de prticas de usabilidade aplicado.
Ainda assim h exemplos de projetos de software livre que elaboram aes de modo a
mitigar problemas relacionados usabilidade e mais especificamente consistncia de
interfaces. Na seo 2.4 sero descritas algumas dessas tentativas em projetos e pesquisas
relacionados.
2.4
TENTATIVAS DE SOLUO: USABILIDADE EM PROJETOS DE SOFTWARE

LIVRE
Como garantir a qualidade no desenvolvimento de interfaces de colaboraes da
comunidade? Existem tentativas de solucionar ou ao menos reduzir esse problema, tais quais
diretrizes de produto, anlise heurstica e outras solues, que sero detalhadas a seguir.
2.4.1 Diretrizes de usabilidade

Documentos de diretrizes de usabilidade, tambm chamados de guidelines em ingls,
tm como principal objetivo melhorar a usabilidade na interao humano-computador [11].
Guidelines so baseadas em teorias, dados empricos e experincias prticas, que unidos so
capazes de aconselhar as pessoas de como algo deve ser feito ou como deve ser [12].
Em software livre h alguns projetos que j utilizam esse tipo de documentao. Este
o caso do Openredu [13], plataforma educacional que possui no documento de guidelines os
princpios nos quais a interface se baseou, especificaes de cores, modelo de corpo, tipografia,
tabelas, listas, formulrios, botes, navegao, alertas, janelas e cones.
No caso do FirefoxOS [14], sistema operacional para dispositivos mveis, h guidelines
bem definidas para o desenvolvimento de aplicaes que rodem nessa plataforma, como
informaes sobre paleta de cores, tipografia, cabealhos, planos de fundo, listas, botes, barras
de ferramenta, campos de texto, seletores e cones.
J para o Android Lollipop [15], outro sistema operacional mvel, existe uma vasta
documentao sobre o estilo de interfaces Material Design. Por meio do site oficial [15],
possvel entender quais os objetivos e princpios desse novo design, bem como conhecer estilos
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
em software livre.
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 esto
de acordo com esses princpios. Essas heursticas muito se assemelham s recomendaes ou
aos princpios de design de 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 design
minimalista; 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 design como 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
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 de software
livre. 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 a
identificao 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 de software a documentao tem papel fundamental para uma evoluo
coerente, e ainda mais quando falamos em desenvolvimento distribudo, porm a ausncia de
documentao 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
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 do software livre 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 mesmo
com 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 design muito particular, possuem design legado ou
tm conflitos tcnicos que dificultam a aplicao do framework.
2.5
TENTATIVAS DE SOLUO: FLUXO DE COLABORAO EM PROJETOS DE

SOFTWARE LIVRE
Em software livre 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 Git

Controle 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
Disponvel em <https://twitter.com/ >. Acesso em 7 de novembro de 2014.
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 <command> [<args>]. O primeiro passo com o Git iniciar um repositrio,
com o comando git init, ou clonar um repositrio existente com o git clone <repo>,
no qual tambm passamos a url do 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]
<pathspec>, sendo mais comum da seguinte forma git commit -am <message> 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] <pathspec>, 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 A ou --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 commits ao repositrio remoto necessrio executar o comando git
push origin master, no qual origin a branch local atual e master a branch principal
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 branches podem ser unidas (merge) ou substituir outras a qualquer momento. Para crilas necessrio o comando git checkout b <name> 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.
20
2.5.2 Colaborao por meio do GitHub
GitHub [22] um servio web que 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, wiki e 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 requests e merges automticos, 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 no site do 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 bem
documentados 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.
21
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 de software livre; 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 de software livre e usabilidade; e por meio de livros
relacionados usabilidade, anlise heurstica, software livre 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 e
software livre. O quadro 1 relaciona cada tpico com palavras-chave em ingls.
22
Quadro 1. Tpicos e palavras-chave usados na reviso de literatura
Tpico
Anlise heurstica
Diretrizes de usabilidade
Fluxo de contribuio do Git
Processo de integrao
Software livre
Palavras-chave
heuristic analysis;
heuristic evaluation;
usability guidelines;
product guidelines;
user interface guidelines;
git contributions workflow;
git workflow;
integration process;
free software;
open source;
floss;
Fonte: O autor.
Todas as palavras-chave foram pesquisadas na biblioteca digital do ACM. De forma

isolada os tpicos de anlise heurstica, diretrizes de usabilidade e processo de integrao
trouxeram dezenas de milhares de opes. Dessa forma foi feito uma restrio adicionando
palavras-chave relacionadas ao tpico de software livre, como por exemplo heuristic analysis
floss que retorna 80 artigos mais bem relacionados ao tema deste trabalho.
Ainda assim, artigos relacionados ao fluxo de contribuio do Git em geral no
possuam informaes relevantes. Dessa forma a pesquisa foi estendida para a web, atravs de
buscadores, onde foi possvel encontrar contedo detalhado sobre o tpico na documentao
oficial do Git [21].
De forma complementar foram utilizados dois livros clssicos relacionados
Engenharia de Software e Usabilidade. O primeiro deles foi Software Engineering: A
Practitioner's Approach de PRESSMAN (2009) [23], e o segundo foi Design de Interao Alm da Interao Homem-computador de PREECE (2005) [8].
Ainda na reviso de literatura as conferncias se mostraram teis como forma de
encontrar trabalhos relacionados de forma mais prtica. H exemplos como a
AcademicMindTrek '13 no qual RAJANEN (2013) [9] publicou um artigo discutindo as
prticas de usabilidade em projetos de software livre, sendo esse um trabalho fundamental para
aprofundar conhecimentos no tema.
3.3
ESTUDOS DE CASO
Para realizar o estudo de caso foram analisadas contribuies dos colaboradores
MEDEIROS [24] e PERRIS [25], ambas integradas verso 0.9.x do AMADEUS, disponvel
23
no portal do Software Pblico Brasileiro [26], possibilitando vivenciar atividades realizadas por
um gerente de configurao durante a integrao de contribuies.
Com o objetivo de aprofundar o entendimento nas interaes sociais, o trabalho de
MEDEIROS prope formas de monitoramento das redes sociais dentro do ambiente
educacional [24]. Nesse contexto foram desenvolvidas trs ferramentas: frum de discusso,
mensagens e integrao s redes sociais (Facebook2 e Twitter3). Essas ferramentas foram
desenvolvidas com base nos requisitos funcionais listados abaixo:
Frum de discusso:
o Somente o professor ou tutor cria um tpico, inicialmente. Os aprendizes
comentam o tpico ou os comentrios dos outros aprendizes, dependendo do seu
objetivo;
o Estruturar o frum atravs do aninhamento das mensagens comentadas, de
forma a ficar claro para o usurio quem respondeu quem. Possibilitar que
somente o professor ou tutor criem o primeiro tpico e todos os envolvidos no
processo de ensino aprendizagem possam comentar de forma irrestrita qualquer
um dos comentrios postados naquele frum, promovendo um aumentodas
interaes sociais;
o Apresentar na descrio do frum a quantidade de mensagens ainda no lidas
naquele frum;
o Possibilitar que o aprendiz ou o professor possam transportar, por meio de um
simples clique, uma postagem do frum para a rede social Twitter e/ou
Facebook. Haver a necessidade de uma configurao das associaes do login
na plataforma, com o login do Twitter ou Facebook;
Mensagens:
o Percepo em tempo real dos usurios online e dos usurios que no esto
online. O primeiro nome que aparece Todos. A lista no deve aparecer
totalmente na tela. Dever ser reservado um espao para uma quantidade de
nomes e o restante seria alcanados por meio de scrollbars;
o Ao clicar em um dos usurios da lista, esteja online ou no, uma caixa de
mensagem aberta abaixo do nome do usurio para que seja possvel enviar uma
mensagem. H um espao para colocar o ttulo e outro para o corpo da
2
3
Disponvel em <https://www.facebook.com/>. Acesso em 30 de janeiro de 2015.

Disponvel em <https://twitter.com/ >. Acesso em 30 de janeiro de 2015.
24
mensagem. Dever haver um boto Enviar abaixo da caixa de mensagem e
tambm um Cancelar;
o Possibilidade de enviar uma mensagem para todos os usurios do curso. Basta
clicar no nome Todos e 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 login do usurio do AMADEUS com os logins das redes
sociais online;
o Devido integrao, ao entrar no AMADEUS, o usurio automaticamente e
individualmente visualiza os posts relacionados rede social cadastrada. A
atualizao 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;
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.
26
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 um fork
para cada uma delas e adicionar as contribuies (ver Figura 2). Aps isso executamos um pull
request que foi integrado ao repositrio principal aps a resoluo de uma srie de conflitos.
Disponvel em <https://github.com/ProjetoAmadeus/AmadeusLMS>. Acesso em 17 de outubro de 2014.
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
um fork do repositrio oficial na conta temporria franciscotemp. A partir disso realizamos
um clone para 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 master e foi realizado um pedido de integrao por meio da funo pull request no
GitHub.
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 commit com todas as mudanas e muitos
dos arquivos no tiveram as diferenas identificadas, tendo sido dados como totalmente
modificados.
28
Figura 3. Opo de merge automtico 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 branch principal do repositrio passou a conter uma nova verso, com
um merge contendo o mdulo social (ver Figura 4). Nesse ponto percebemos que poderia ser
importante criar uma branch para realizar a integrao antes de colocar na master, j que em
uma situao real a contribuio poderia no ter sido devidamente testada.
Figura 4. Merge da 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 um fork do 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 commit com toda
a contribuio, sincronizando com a master e 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
29
no repositrio oficial, ou realizar um merge e corrigir possveis problemas numa branch
alternativa.
A escolha nesse caso foi criar uma nova branch para 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 branch alternativa 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 ser
considerado: o gerente de configurao, o colaborador externo e o colaborador interno.
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 identificao
dos produtos do trabalho que sero alterados, estabelecendo um relacionamento
entre eles, definindo o mecanismo para o gerenciamento de diferentes verses destes
produtos, controlando as mudanas impostas, e auditando e relatando as mudanas
realizadas.
O colaborador externo aquele que cria uma verso particular do repositrio oficial, por
meio do fork, 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 web que
permite o armazenamento de repositrios de projetos, open source ou proprietrios, com o
controle de verso Git. O servio tambm possibilita grande interao entre os membros das
comunidades, pois so disponibilizados fruns, wiki e 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
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 issues no
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 mais
adiante, 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 de sites dinmicos 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.
Disponvel em <http://www.oracle.com/technetwork/pt/java/index.html>. Acesso em 18 de novembro de 2014.

Disponvel em <http://www.oracle.com/technetwork/java/javaee/jsp/index.html>. Acesso em 18 de novembro
de 2014.
7
Disponvel em <http://hibernate.org/orm/>. Acesso em 18 de novembro de 2014.
8
Disponvel em <http://www.postgresql.org/>. Acesso em 18 de novembro de 2014.
6
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 Etapas
O 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 um fork do
repositrio oficial para trabalhar de forma isolada. Assim a cada progresso commits devem 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 fluxos
estejam 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 um pull 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 ao
desenvolvedor 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 branch secundria para realizar a operao, em seguida
Disponvel em <https://eclipse.org/>. Acesso em 19 de novembro de 2014.

Disponvel em <http://tomcat.apache.org/download-60.cgi>. Acesso em 19 de novembro de 2014.
11
Disponvel em <http://www.pgadmin.org/>. Acesso em 19 de novembro de 2014.
10
33
realizar o merge automtico 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 merge da verso oficial com a contribuio
atravs do comando pull. Ao fim do merge ser informado quantos conflitos ocorreram. Todos
devem 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 branch
principal (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.
12
Disponvel em <http://www.bizagi.com/en/bpm-suite/bpm-products/modeler>. Acesso em 10 de dezembro de

2014.
34
Figura 6. Processo de integrao de contribuies da comunidade AMADEUS (Parte 1)
Fonte: O autor.
A primeira parte (ver Figura 6) destaca as tarefas do colaborador de entendimento das

necessidades do projeto, criao do fork e da verso local do repositrio. Aps isso um subprocesso de desenvolver alterao (detalhado na Figura 12) executado, alm de um rebase e
da submisso das contribuies e recebimento pelo GitHub.
35
Fonte: O autor.
Na parte seguinte o GitHub (ver Figura 7) envia a notificao para o gerente do

repositrio, esse recebe a notificao, observa as modificaes e testa o projeto. Em caso de
problemas o colaborador contatado, recebendo informaes por meio do frum.
36
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.
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.
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.
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.
40
Figura 12. Subprocesso de desenvolver alterao no cdigo
Fonte: O autor.
Na Figura 12 exibido o fluxo de tarefas realizadas no subprocesso de desenvolver

alterao no cdigo. Primeiro as alteraes so realizadas e os commits executados (no
repositrio local), aps isso so realizados testes exploratrios a fim de encontrar problemas.
Caso passe nos testes a alterao ser enviada para a branch master. Caso contrrio os
problemas sero corrigidos at que tudo esteja funcionando.
Figura 13. Subprocesso de realizar anlise heurstica
Fonte: O autor.
J na Figura 13 est modelado o subprocesso da anlise heurstica, que se inicia com

um decisor, pois no caso do especialista no possuir conhecimento sobre a documentao ento
ele dever estud-la. Aps isso ser realizada a inspeo na interface, tendo como escopo as
41
mudanas realizadas na colaborao a ser integrada. Em seguida os problemas so
identificados, priorizados e solues so propostas, concluindo assim a anlise.
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 de
cores, 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.
13
Disponvel em < https://www.mozilla.org/en-US/styleguide/products/firefox-os/>. Acesso em: 13 de novembro

de 2014.
43
4.3.1 Princpios
Considerando o contexto da elaborao de interfaces para web h 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, incluindo feedbacks para 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 vocabulrio
adequado 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 um
retorno 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
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 do site devemos manter acesso s pginas
de ajuda ou s dicas que auxiliem o usurio na execuo de uma tarefa. Dessa forma
possvel usar pginas de F.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 wireframes do projeto foi construdo o grid que 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 do site dentro do layout padro. Na Figura 15 destacada a finalidade
de cada rea do grid cuja funcionalidade ser descrita adiante.
Figura 15. reas do grid com a finalidade proposta
Fonte: O autor.
Login e 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
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 link de 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 chegar
na pgina atual, no qual todas as pginas anteriores devem conter um link de acesso direto.
Navegao local: essa coluna deve conter informaes e/ou menus verticais 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 do software. Dessa
forma, no deve ser usada em outra situao, e sim atualizada quando necessrio.
46
Figura 16. Grid de 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. Grid de trs colunas com dimenses de largura e espaamento
Fonte: O autor.
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. Grid com 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 global
possui 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, duas
escalas 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.
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) pode
ser usada como plano de fundo de uma regio clara, possibilitando mais destaque ou maior
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 links no 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 links em estado normal (quando
o mouse no 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
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 cor
do 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
#AAC46C
(170, 196, 108)
#94C92E
(148, 201, 46)
#009900
(0, 153, 0)
#AED1AD
(174, 209, 173)
Finalidade
Planos de fundo em reas pequenas ou mdias
de contedo.
Bordas em reas pequenas ou mdias de
contedo.
Textos curtos ou palavras em destaque.
Plano de fundo em linhas de tabelas, etiquetas
de formulrios, ttulos de contedo ou em outras
regies de destaque.
51
#52A07E
(82, 160, 126)
#2CA457
(44, 164, 87)
#35784C
(53, 120, 76)
#FFFFFF
(255, 255, 255)
#E7E7E7
(231, 231, 231)
#CCCCCC
(204, 204, 204)
#C7C7C7
(199, 199, 199)
#999999
(153, 153, 153)
#000000
(0, 0, 0)
#FFB8B0
(255, 184, 176)
#FF1800
(255, 24, 0)
#990000
(153, 0, 0)
Textos mdios em destaque.

Links em estado ativo ou com o mouse
sobreposto.
Texto de mensagens de sucesso.
Plano de fundo geral de contedo.
Planos de fundo em reas pequenas ou mdias
de contedo.
Plano de fundo externo e bordas de layout do
site.
Plano
de
fundo
em
formulrios,
preferencialmente nas linhas das etiquetas.
Bordas de janelas sobrepostas e bordas de
notificaes genricas.
Texto padro e de links em estado normal.
Plano de fundo em regies de alerta e erro.
Cor do texto em regies de alerta caso o plano
de fundo seja branco, possivelmente em reas
de contedo.
Cor do texto em regies de alerta e erro quando
o 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
14
Disponvel em < http://www.dafont.com/coolvetica.font?text=AaBbCc> Acesso em 29 de dezembro de 2014.
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 body da 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 <h1>, ttulo 2 <h2> e ttulo 3 <h3>. 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.
15
Disponvel em < http://www.w3.org/TR/CSS21/>. Acesso em 15 de dezembro de 2014.
53
As listas referentes tag <ul> devem 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 <table>, mas as

clulas <td> 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 links de 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 <strong>, 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
hover no CSS, no qual aparece sublinhado e com cor verde de hexadecimal #2CA457. J o
estado normal dos links deve 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 AMADEUS
Item
Tag HTML
Ttulo 1
<h1>
Especificaes
Tamanho 1,4em, peso negrito, sem margem e sem
espaamento.
54
Ttulo 2
<h2>
Ttulo 3
<h3>
Lista
<ul>
Tabela
<table>
Clula da tabela
<td>
Pargrafo
<p>
Link normal
<a>
Link sobreposto
<a>
Tamanho 1,3em, peso negrito, sem margem e sem

espaamento.
Tamanho 1em, peso negrito, margem inferior de
1px, margem superior de 2px e sem espaamento.
Marcador tipo disco, fonte de tamanho 0,7em,
espaamento esquerda de 40px e margens
superior e inferior de 12px.
Sem margem, sem espaamento e sem bordas.
Fonte de tamanho 0,9em, espaamento de 1px e
margem de 2px.
Tamanho 0,7em, peso normal, margem superior e
inferior de tamanho 12px e sem espaamento.
Preserva as caractersticas do texto onde est
inserido.
Sublinhado e de cor verde (#2CA457).
Fonte: O autor.
4.3.5 Formulrios
Nas pginas do projeto so encontrados trs estilos de formulrios, que na maioria dos
casos so usados em cadastros e buscas. Nesses formulrios importante atentar a necessidade
de tudo estar dentro de uma tag <form> com atributos como o mtodo de envio e a ao a ser
executada.
Figura 28. Formulrio de buscar um curso
Fonte: Foto da tela do LMS AMADEUS.
O primeiro deles o formulrio horizontal, atualmente usado apenas na busca

simplificada e indicado para aes similares, com apenas um campo e um boto. Na Figura
28 pode ser visto um exemplo. Para aplicar esse estilo necessrio colocar o campo do boto
dentro de um mesmo container (por exemplo, uma <div>), o campo de texto deve conter a
classe formfield2 e o boto a classe button.
55
Figura 29. Formulrio de cadastrar usurio
Os formulrios extensos, como na Figura 29, so uteis para criao de cadastros. Nele
cada campo deve vir com uma etiqueta e opcionalmente com uma descrio. Na Figura 30 pode
ser vista a estrutura HTML necessria para criar um formulrio como esse:
Figura 30. Exemplo de HTML para formulrio consistente
A primeira tag um <form> que possui atributos especficos para o envio do

formulrio. Em seguida a etiqueta do campo, disposta em um <label> com a classe
youCanTitle. J o campo de texto <input> deve ter a classe formfield e ficar dentro de uma
<div> com a classe field. A descrio do campo deve estar em uma <div> com a classe
56
description e o boto <input> deve possuir a classe button e estar dentro de uma <div>
com a classe field.
Figura 31. Formulrio simplificado
Ainda h o formulrio simplificado (Figura 31), feito de forma tabular, no qual as

etiquetas esto em clulas da coluna esquerda e os respectivos campos esto em clulas da
coluna direita. A primeira coluna possui alinhamento direita, j a segunda est alinhada
esquerda, exceto no caso do boto pesquisar, que est na ltima linha alinhado direita.
4.3.6 Navegao
No AMADEUS toda a navegao est compartimentada em trs (3) reas distintas,
sendo uma delas referente navegao geral, outra com o caminho percorrido e a ltima com
um menu contextualizado.
Figura 32. Navegao global
A navegao global est localizada na barra horizontal acima do contedo, e composta

por um menu horizontal e separadores de texto. As opes desse menu esto ligadas a fatores
mais gerais como configuraes e informaes do produto e devem ser mantidas em todas as
pginas, no tendo necessariamente uma ligao direta com o contedo exibido na pgina.
Para adicionar opes adequadas a esse menu, necessrio inserir uma tag <span>
dentro da <div> identificada como institutional_menu com o link direcionando para a pgina
desejada e um separador de textos do tipo barra vertical, conforme visto na Figura 32.
importante destacar a necessidade de avaliar o alvo do link, pois caso direcione para fora do
sistema deve ser aberta uma nova janela.
57
Figura 33. Breadcrumb
O caminho, comumente chamado de breadcrumb, representa as pginas percorridas at

chegar no contedo atual. Isso possibilita um maior senso de localizao dentro do site e permite
que o usurio volte para as outras pginas, j que todas as pginas anteriores esto representadas
na forma de link.
Esse componente precisa ser criado dinamicamente em cada pgina. Para isso preciso
ter uma <div> com a classe pBreadCrumbs e dentro dessa rea ter uma lista <ul> com o id
breadcrumb. Com exceo do ltimo item, cada item <li> da lista tem um link para a pgina
referente, e como pode ser observado na Figura 33, na qual a pgina inicial est sobreposto pelo
mouse, os links possuem o mesmo estilo dos pargrafos.
Figura 34. Navegao local
A navegao local ou contextualizada composta de um menu vertical, localizado na

coluna esquerda da pgina. Na Figura 34 exibido o menu de Dados do Curso. Este s fica
disponvel para usurios com sesso ativa que esto na pgina de um curso. Nesse exemplo as
opes exibidas so referentes ao perfil do usurio ativo, no caso um administrador.
Para construir menus desse tipo necessrio apenas criar uma lista desordenada <ul>
com um id menu_sessoes, e cada item dessa lista ser um item do menu. Dessa forma o layout
definido por padro na folha de estilos do AMADEUS se mantm, com uma borda inferior
cinza e pontilhada em cada item. J os links em estado normal possuem cor preta e quando esto
com o mouse sobreposto passam a ter cor verde, como nos links de pargrafos, mas nesse caso
58
sem sublinhado. Se for preciso um ttulo para o menu, este deve vir como primeiro item da lista
e em negrito.
4.4
REVISO DE GUIDELINES E INSPEO DE CONSISTNCIA

Com o documento de diretrizes em mos foi possvel realizar a anlise heurstica, com
destaque a dois pontos principais: a reviso de guidelines, de modo a verificar a conformidade

das interfaces com a documentao proposta; e a inspeo de consistncia, possibilitando
identificar falhas mais gerais, relacionadas aos princpios bsicos, layouts incomuns, formatos
de entrada e sada inesperados [28].
4.4.1 Anlise da contribuio de MEDEIROS (2013)

A primeira contribuio analisada foi a de MEDEIROS, na qual os mdulos sociais
foram analisados. Em termos de posicionamento o mdulo de mensagens foi colocado na
coluna direita, correspondendo a uma deciso correta, j que essa regio do grid foi definida
para mdulos adicionais (ver Figura 35). A escolha de cores tambm est dentro do esperado
na paleta de cores definida anteriormente, na qual o verde usado para destacar um texto curto
e o cinza como plano de fundo desses textos.
Figura 35. Boto com layout quebrado no bloco de mensagens
Porm quando a altura a rea alocada para enviar mensagens estourada h uma quebra
na posio do boto Cancelar, Isso acontece porque a barra de rolagem passa a ser exibida e
reduz a largura disponvel para esses botes. Alm disso o campo Assunto possui uma cor
muito clara para texto escrito pelo usurio, podendo causar dificuldades aos usurios que
possuem monitor com um brilho alto ou baixo contraste.
59
Figura 36. Feedback de mensagem enviada sendo exibido
Ao enviar mensagens um retorno exibido na tela, respeitando o princpio que indica a

necessidade de fornecer feedback ao usurio para as aes executadas (ver Figura 36). Da
mesma forma, ao tentar enviar mensagens com campos vazios um alerta exibido no mesmo
local, porm com cores diferentes.
Figura 37. Tela de exibir todas as mensagens
Na pgina de visualizao de todas as mensagens (Figura 37) a rea de contedo da tela

utilizada de forma correta, exibindo as mensagens correspondentes. Nessa rea de contedo
as cores tambm foram usadas corretamente, o verde claro para plano de fundo e o verde mdio
para destacar uma regio especfica. Porm, no caso dos links a cor usada, azul, no est
presente na paleta de cores e tambm no encaixa na identidade visual do site. Tambm foram
usadas bordas arredondadas as reas em verde, algo que poderia ter sido evitado pois em todas
as outras telas no h nenhuma regio que use esse tipo de borda, fazendo com que a
consistncia seja comprometida.
60
Figura 38. Tela de integrar redes sociais
Na tela de integrao com redes sociais h poucos problemas (ver Figura 38). O
formulrio foi feito de forma correta e o boto Salvar manteve o padro usado nos outros
formulrios do sistema e definido na paleta de cores. Porm os cones usados para ilustrar o
Twitter e o Facebook esto em desacordo entre si. O primeiro possui borda quadrada e cor de
fundo chapada, j o segundo possui borda arredondada e cor de fundo com degrad. Alm disso
os cones esto desalinhados, quando deveriam estar alinhados esquerda.
Figura 39. Tela de monitorar redes sociais
J na parte de monitoramento de redes sociais (ver Figura 39) foi usado um formato de
telas totalmente diferente dos anteriores, com bordas pretas em uma tabela, quando a estrutura
usada deveria ser similar de um formulrio. O cone no Twitter est em um tamanho
desproporcional alm de ser desnecessariamente diferente do cone usado na tela de integrao
das redes sociais.
61
No quesito navegao houveram algumas ocorrncias de erro, pois os ttulos nas telas
de exibir todas as mensagens, integrao de redes sociais e monitoramento de redes eram
Dados do curso, Trocar senha e Dados do curso, respectivamente. A contribuio tambm
no previne erros em algumas situaes, como no caso de enviar mensagens para toda a sala,
quando apenas pressionando o boto enviar toda a sala notificada, mas nesse caso seria
importante uma mensagem de confirmao questionando se o professor realmente deseja entrar
em contato com toda a turma.
De uma forma geral a contribuio de MEDEIROS est compatvel com o esperado por
usurios do sistema: permite que o usurio tenha liberdade de cancelar, retornar ou iniciar aes
quando desejado e mantm um padro coerente com as diretrizes e a identidade visual. Os
problemas esto concentrados em dois princpios: preveno de erros e consistncia e
padres, esse ltimo com poucos erros referentes a cor e navegao.
4.4.2 Anlise da contribuio de PERRIS (2013)

A contribuio de PERRIS foi analisada em seguida, contemplando o mdulo de grupos,
no qual possvel criar, visualizar e obter relatrios de grupos. Na primeira tela de grupos
exibida uma lista com marcadores simbolizando o submenu de opes de grupo (ver Figura 40).
Nesse caso no h uma especificao no documento para tal. Porm, uma lista usada como
menu contraintuitivo, ferindo o princpio reconhecer, em vez de relembrar, j que o usurio
precisa identificar que a lista um menu, o que geralmente s acontece por tentativa e erro.
Figura 40. Menu da tela de grupos
Nessa tela tambm so exibidos os resultados das opes de criar grupo e visualizar
grupos, o que acontece sem o recarregamento da pgina, permitindo uma maior eficincia no
uso. Porm como a navegao no atualizada para a nova tela, isso pode gerar confuso por
parte do usurio, que deixa de entender onde est localizado. J ao acionar a opo desabilitar
62
criar grupos uma janela de confirmao exibida, questionando se o usurio realmente deseja
executar aquela ao, estando de acordo com o princpio da preveno de erros.
Figura 41. Tela de criar grupo
A tela de formulrios tambm est fora do padro, pois os nomes dos campos esto em
cor preta quando deveriam ser verdes. Ainda, h uma borda preta em parte da regio do
formulrio. Essa falta de continuidade cria a impresso de falha no carregamento. Alm disso
a ao de convidar est semanticamente incorreta, pois ao selecionar um usurio na tabela
direita e clicar em convidar ele adicionado ao grupo automaticamente, quebrando o princpio
de compatibilidade do sistema com o mundo real. Ainda assim notada a ausncia de um
boto cancelar, indo contra o princpio controle do usurio e liberdade, e faltam mensagens
de sucesso e erro, impedindo a visibilidade de status do sistema.
Figura 42. Tela de visualizar grupos
Na tela de visualizar grupos exibida uma tabela, que usa cores da paleta de forma
incorreta, como no cinza aplicado como plano de fundo das clulas de ttulo, quando no caso
deveria ser verde claro. Alm disso o preto deve ser usado apenas para textos, e no para definir
bordas em tabelas, como foi feito nessa pgina. No entanto a tela bastante objetiva, permitindo
que o usurio acesse as opes praticamente sem errar.
63
Figura 43. Tela de relatrio de atividades
J o relatrio de atividades exibido em uma nova tela, pois o objetivo a impresso.

Dessa forma, o design escolhido foi minimalista, sem exageros (ver Figura 43). Ainda assim o
cinza mdio escolhido para ser a cor das clulas de ttulo pode gerar problemas em algumas
impressoras, para isso um verde ou cinza mais claros seriam uma boa alternativa.
Dessa forma conclumos que a contribuio de PERRIS est em desacordo com o
esperado por um usurio do LMS AMADEUS. As interfaces no esto consistentes com o
padro estabelecido pelo software e ferindo vrios dos princpios definidos. Portanto, em uma
situao real essa contribuio necessitaria de uma srie de ajustes para ser integrada verso
oficial do projeto.
4.4.3 Avaliao dos resultados

Como resultado da inspeo de consistncia, que avalia as interfaces com base nos
princpios pr-definidos, podemos concluir que a avaliao de MEDEIROS est mais prxima
do ideal, pois houveram apenas duas quebras de princpios, j a contribuio de PERRIS teve
seis quebras de princpios. O Quadro 4 resume os resultados obtidos, no qual cada contribuio
est relacionada aos princpios por meio de um indicando aprovao ou um indicando
reprovao, ou seja, ao menos uma ocorrncia de falha relacionada.
Quadro 4. Resultado da inspeo de consistncia
Princpio
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
Contribuio
MEDEIROS
PERRIS
64
Reconhecer, em vez de
relembrar
Flexibilidade e eficincia no uso
Esttica e design minimalista
Ajuda e documentao
Fonte: O autor.
J na reviso de guidelines, que avalia as interfaces com base no documento de diretrizes

do produto, teve como concluso que a contribuio de MEDEIROS foi um pouco melhor, com
falhas em duas diretrizes, e a de PERRIS teve falhas em trs diretrizes. O rene todas os
resultados dessa reviso, relacionando as contribuies com as diretrizes e sinalizados no
mesmo formato do Quadro 4.
Quadro 5. Resultado da reviso de guidelines
Contribuio
MEDEIROS
PERRIS
Diretrizes
Grid
Cores
Tipografia
Formulrios
Navegao
Fonte: O autor.
A quantidade de erros identificados evidencia a necessidade de uma documentao mais

clara no que diz respeito a padres de interface, pois dessa forma os colaboradores teriam
condies de desenvolver interfaces consistentes com o projeto. Ainda assim, caso
inconsistncias fossem submetidas, essas seriam identificadas pelo gerente de configurao
aps realizar a anlise heurstica, que em seguida solicitaria correes ao colaborador, conforme
descrito no processo sugerido neste trabalho.
4.5. REVISO DO CDIGO PARA CONSISTNCIA E PUBLICAO NO PORTAL SPB

Com os erros delimitados no captulo anterior foi possvel revisar o cdigo para executar
correes com o objetivo de tornar as interfaces mais consistentes. Todas as correes seguiram
as observaes delimitadas na seo 4.4.
65
Figura 44. Boto com layout corrigido no bloco de mensagens
A primeira tela a ser corrigida na contribuio de MEDEIROS foi a de mensagens, na

qual antes era exibido um boto com o posicionamento quebrado e que agora est correto (ver
Figura 44). Tambm foi corrigida a ocorrncia de bordas arredondadas em todas as telas dessa
contribuio, deixando-as da forma vista na Figura 45.
Os links azuis foram corrigidos em todas as telas nas quais era exibido, passando a ter
um estilo padro do sistema, com cor preta e cor verde e sublinhado ao passar o mouse (ver
Figura 45). Alm disso, a tela de visualizar todas as mensagens teve o ttulo alterado de Dados
do Curso para Mensagens, como pode ser visto na Figura 45, pois era uma falha capaz de
gerar problemas de navegao ao usurio.
Figura 45. Tela de exibir todas as mensagens corrigida
A tela de monitorar redes sociais (ver Figura 46) tambm teve correo no ttulo, mas
alm disso todo o alinhamento foi refeito, colocando o cone do Twitter esquerda e o
formulrio com uma margem de 10 pixels direita. Alm disso a borda usada na tela para
66
delimitar as reas foi removida por no estar no padro do sistema, tornando a tela mais limpa
e confortvel.
Figura 46. Tela de monitorar redes sociais corrigida
J a tela de integrao com redes sociais teve os cones substitudos, que no caso do
Twitter o mesmo da tela da Figura 47, mantendo-a coerente entre as interfaces. A escolha foi
por cones sem bordas arredondadas e sem variaes de degrad ao fundo, seguindo o padro
visual adotado em todo o site. Tambm foi corrigido o alinhamento entre os cones, antes
desalinhados e, agora, alinhados direita.
Figura 47. Tela de integrar redes sociais corrigida
Na contribuio de PERRIS a correo iniciou pelo menu da tela de grupos, que antes
era exibido como uma lista no ordenada e agora est em formato de menu horizontal, como
visto na Figura 48. Dessa forma, ficando mais familiar ao esperado pelos usurios. Alm disso
a tabela exibida ao clicar em visualizar grupos tambm foi modificada para aderir ao estilo
adotado pelo site, tendo as cores de plano de fundo e bordas sido alteradas conforme a definio
do documento de diretrizes (ver Figura 48).
67
Figura 48. Menu e lista de grupos corrigidos
Na tela de criar grupo foram removidas as bordas irregulares e o alinhamento dos

campos foi melhorado (ver Figura 49). Alm disso foi corrigido o nome do boto Adicionar,
que representava uma adio de um participante ao grupo, que era nomeado como Convidar.
Nesse boto tambm foi adicionada uma seta para a esquerda, indicando para o usurio o
sentido da ao.
Figura 49. Tela de criar grupo corrigida
As telas de timeline e relatrio foram mantidas como pop-up, porm agora esto com o
padro de interfaces estabelecido no sistema, tanto em termos de tipografia quanto no esquema
de cores. Como pode ser visto na Figura 50, na qual esto dispostas lado a lado. Ainda assim
as telas se mantiveram simples o suficiente para o caso de ser necessrio imprimi-las.
Figura 50. Tela de atividades do grupo ( esq) e tela de relatrio ( dir) corrigidas
68
Com todas as modificaes e commits realizados, o projeto foi sincronizado com o
repositrio no GitHub. A partir desse ponto ns tnhamos uma verso com as duas contribuies
integradas e estvel. Portanto, a disponibilizamos no Portal do Software Pblico Brasileiro. Essa
nova verso foi publicada junto a um registro de alteraes (changelog) que disponibilizamos
abaixo:
Integrao da contribuio de MEDEIROS (2013), contemplando os mdulos de

redes sociais, mensagens e frum;
Integrao da contribuio de PERRIS (2013), contemplando o mdulo de grupos;
Correes de consistncia de interfaces nas duas contribuies;
Refatorao de cdigos do projeto; e
Correes de bugs e pequenas melhorias.
69
DISCUSSO
A manuteno de projetos de software livre de fato um grande desafio, tanto para os
administradores e gerentes de configurao quanto para os novos colaboradores das

comunidades. Para que isso acontea com eficcia preciso criar documentaes como as de
arquitetura, configurao, interfaces e viso do projeto, o que gera uma carga de trabalho
normalmente no aceita pelos desenvolvedores, que querem codificar. Como mapeado por
RAJANEN [9], a filosofia mais seguida em projetos de software livre falar fcil, mostreme o cdigo, e esse tipo de pensamento um dos grandes entraves para a adoo de
documentaes necessrias a uma evoluo consistente.
No entendimento de fenmenos relativos proposio de contribuies das
comunidades de software livre percebemos que a ausncia de documentao um dos fatores
para a gerao de inconsistncias. E essa ausncia tida como o principal problema encontrado
por novos colaboradores das comunidades de software livre, como identificado por
REDMILES [1], criando dificuldades at mesmo para encontrar uma forma de comear a
contribuir. Esse problema pode se desmembrar de diversas formas, mas nesse trabalho, tivemos
como objeto a consistncia de interfaces, assim passamos a estudar solues propostas por
comunidades preocupadas em evit-lo ou reduzi-lo.
Dentre as tentativas de solues listadas estava usar o GitHub como ambiente de
desenvolvimento
distribudo,
melhorando
fluxo
de
colaborao
atraindo
mais
desenvolvedores. Em seguida percebemos a necessidade de formalizar o processo a ser

executado nesse ambiente, o que fizemos por meio do estudo de caso de duas contribuies ao
projeto. Numa tarefa desse processo, antes da tarefa de integrao final, pudemos incluir a
realizao da anlise heurstica, que uma tcnica clssica e barata de usabilidade, sendo capaz
de definir se uma interface est ou no consistente com o padro definido nas diretrizes e
princpios.
Com o processo em mos, necessitvamos de um documento de diretrizes para executlo, o que foi feito por meio da anlise do estilo do prprio sistema e de documentos de outros
projetos. Dessa forma foi desenvolvida a primeira verso do documento de diretrizes de
interface do LMS AMADEUS, permitindo a todos os colaboradores elaborarem novas telas
mais prximas aos padres usados no sistema. Para esta documentao ainda cabe uma clara
evoluo, como a previso de novos formatos de tela. Porm, isso deve acontecer ao passo que
o cdigo das telas tambm evolua, mantendo sempre o documento atualizado e consistente com
o que j est incorporado ao sistema.
70
A partir da documentao fomos capazes de analisar as duas contribuies do ponto de
vista da consistncia de interfaces, e com isso o que j era claro na observao ficou claro
tambm em nmeros. As duas contribuies tiveram diversas falhas, considerando dez (10)
princpios e cinco (5) diretrizes a de MEDEIROS teve dois (2) problemas em cada. J a de
PERRIS teve seis (6) e trs (3) problemas, respectivamente. Porm as colaboraes no devem
ser desmerecidas, pois isso reflexo do principal problema citado neste trabalho, a ausncia de
documentao, fazendo com que os desenvolvedores no tenham material suficiente para
entender o que e como deve ser feito. Documentaes como essas resultam em desenvolvedores
mais engajados e dispostos a contribuir para a evoluo dos projetos em comunidades de
software livre.
71
CONCLUSO
Em projetos de software livre os colaboradores tm dificuldades de encontrar uma forma
de comear a contribuir, muito pela falta de entendimento das necessidades do projeto, pois
comum no haver documentao suficiente para tal. Tambm raro encontrar especificaes
do design usado no projeto, com isso, quando desenvolvedores decidem contribuir, no o fazem
mantendo as interfaces consistentes com o todo.
A elaborao de um processo de integrao, no qual previsto a necessidade de analisar
a consistncia de novas interfaces integradas ao projeto, significa um passo adiante no desafio
de manter um projeto de software livre. Dessa forma foi realizado um estudo de caso com a
integrao de duas contribuies ao LMS AMADEUS, a fim de obter um processo capaz de
representar de fato o novo ambiente de desenvolvimento colaborativo.
No processo de integrao h a tarefa de realizar anlise heurstica, necessria para
perceber se uma contribuio est consistente ou no, tanto por meio de princpios como atravs
de diretrizes especificadas. Assim analisamos folhas de estilo do LMS AMADEUS e
documentos de diretrizes de outros projetos de software livre, e com isso desenvolvemos um
guia para interfaces de novas contribuies ao projeto.
Por fim avaliamos as duas contribuies do estudo de caso por meio do novo documento
de diretrizes, como uma forma de valid-lo dentro do processo. Como resultado da avaliao
ficou claro que a ausncia de documentao gerou uma srie de erros facilmente evitveis, na
qual foram mais crticos os encontrados na contribuio de PERRIS [25]. Porm em ambos os
casos, o desenvolvedor no foi instrudo de forma correta em como se apropriar dos padres,
amplamente usados nas telas j presentes no sistema.
Entendemos que, com um processo bem definido e uma documentao de interfaces
disponvel para os colaboradores, possvel manter projetos de software livre com interfaces
consistentes em novas contribuies. E dessa forma o projeto pode se tornar mais atrativo a
novos colaboradores, fomentando a comunidade e permitindo uma melhor evoluo, tanto de
cdigos quanto de interfaces.
6.1
LIMITAES
A principal limitao deste trabalho que o documento de diretrizes no relata todos os
aspectos de interfaces que so possveis em pginas web. Alm disso o documento no possui
uma verso reduzida, no formato de especificao tcnica, similar as do Bootstrap [20]. J na
72
reviso do cdigo para consistncia no pudemos corrigir alguns dos problemas encontrados,
devido grande profundidade desses.
6.2
TRABALHOS FUTUROS
Alm de melhorar pontos definidos nas limitaes, podemos citar como trabalho futuro
um estudo de caso no qual sejam analisados dois projetos de software livre similares. Um deles
tendo um processo de integrao bem definido, e o outro sem processo de integrao
estabelecido. A partir desse estudo pode ser analisada na prtica a eficincia real de ter ou no
um processo definido.
Tambm podemos sugerir um estudo da comunidade do AMADEUS para a melhoria
do documento de diretrizes. Nesse estudo seria analisada a necessidade de incluir novos pontos
no documento, baseando-se nas dvidas da comunidade, em entrevistas com colaboradores e
na anlise dos problemas existentes nas contribuies.
73
REFERNCIAS BIBLIOGRFICAS
1. REDMILES, D. et al. The Hard Life of Open Source Software Project Newcomers.
CHASE 2014 Proceedings of the 7th International Workshop on Cooperative
and Human Aspects of Software Engineering, Hyderabad, India, 2-3 jun. 2014.
72-78.
2. MURILLO, L. F. Tecnologia, Poltica e Cultura na Comunidade Brasileira de
Software Livre e de Cdigo Aberto. 2009. 172 f. Dissertao (Mestrado) Curso de Antropologia Social, Instituto de Filosofia e Cincias Humanas, Ufrgs.
Porto Alegre, RS. 2009.
3. REIS, C. R. Caracterizao de um Processo de Software para Projetos de Software
Livre. 2003. 158 f. Dissertao (Mestrado) - Curso de Cincias da Computao e
Matemtica Computacional, Departamento de Instituto de Cincias Matemticas e
de Computao, USP. So Paulo, SP. 2003.
4. PEREIRA JR, C.; CAPETO, R. Indicadores para avaliao de websites. Anais do III
Workshop sobre Fatores Humanos em Sistemas Computacionais, IHC 2000,
Gramado, RS, 18-20 out. 2000. 75-80.
5. U.S. DEPT. OF HEALTH AND HUMAN SERVICES. Research-Based Web Design and
Usability Guidelines. Usability.gov. Disponivel em:
<http://guidelines.usability.gov/>. Acesso em: 9 out. 2014.
6. GOMES, A. S. et al. Amadeus: Novo modelo de sistema de gesto de aprendizagem.
Revista Brasileira de Aprendizagem Aberta e A Distncia, Recife, PE, v. 8, p.
10-27, 2009.
7. FREE SOFTWARE FOUNDATION. O que software livre? Free Software
Foundation. Disponivel em: <http://www.gnu.org/philosophy/free-sw.html>.
Acesso em: 29 out. 2014.
8. PREECE, J.; ROGERS, Y.; SHARP, H. Design de Interao: Alm da Interao
Homem-computador. 2. ed. So Paulo, SP: Bookman, 2005. 548 p.
9. RAJANEN, M.; IIVARI, N. Open Source and Human Computer Interaction Philosophies
in Open Source Projects Incompatible or Co-Existent?
AcademicMindTrek13, Tampere, Finland, 04 jan. 2013.
10. BENSON, C.; MLLER-PROVE, M.; MZOUREK, J. Professional Usability in Open
Source Projects: GNOME, OpenOffice.org, NetBeans. CHI 2004, Vienna,
Austria, 24-29 abr. 2004.
11. BURMESTER, M.; MACHATE, J. Creative Design of Interactive Products and Use of
Usability Guidelines a Contradiction? Proceedings of HCI international 2003.
Mahwah: Lawrence Erlbaum, Mahwah, USA, 2003.
12. CRONHOLM, S. The Usability of Usability Guidelines - a Proposal for MetaGuidelines. Proceedings of the 21st Australasian Computer-Human
Interaction Conference (OZCHI), Melbourne, Australia, 2009.
13. OPENREDU. Caractersticas. Openredu. Disponivel em:
<http://openredu.cin.ufpe.br/?page_id=700&lang=pt>. Acesso em: 06 jan. 2015.
14. MOZILLA. Firefox OS Guidelines. Mozilla Style Guide. ISSN
https://www.mozilla.org/en-US/styleguide/products/firefox-os/. Acesso em: 13
nov. 2014.
74
15. GOOGLE. Introduction. Material design. Disponivel em:
<http://www.google.com/design/spec/material-design/introduction.html>. Acesso
em: 13 jan. 2015.
16. NIELSEN, J.; MACK, R. L. Usability Inspection Methods. New York, USA: John
Wiley & Sons, 1994.
17. RAJANEN, M.; IIVARI, N.; KESKITALO, E. Introducing Usability Activities into
Open Source Software Development Projects a Participative Approach.
Proceedings of the 7th Nordic Conference on Human-Computer Interaction:
Making Sense Through Design, New York, USA, 2012.
18. MEDEIROS, L. et al. Uso de StoryBoards para a Documentao dos Requisitos no
Desenvolvimento Distribudo de Software. I Workshop de Desenvolvimento
Distribudo de Software (WDDS) - SBES 2007, Joo Pessoa, PB, 2007.
19. MEDEIROS, L. M. Proposta de Processo de Requisitos para Equipes de
Desenvolvimento Distribudas Visando Melhorar a Documentao e
Validao com Uso de Prottipos. UFPE. Recife, PE, p. 165. 2007.
20. TWITTER. About. Bootstrap. Disponivel em: <http://getbootstrap.com/about/>. Acesso
em: 26 jan. 2015.
21. CHACON, S.; STRAUB, B. ProGit. 2. ed. San Francisco, USA: Apress, 2014.
22. GITHUB. About. GitHub. Disponivel em: <https://github.com/about>. Acesso em: 14
nov. 2014.
23. PRESSMAN, R. Software Engineering: A Practitioner's Approach. 7. ed. New York,
USA: Mcgraw-hill, 2009. 976 p.
24. MEDEIROS, F. P. Uma abordagem de monitoramento abrangente da experincia do
usurio em ambientes colaborativos virtuais de aprendizagem como suporte
a presena docente. 2013. 205 f. Tese (Doutorado) - Curso de Cincia da
Computao, Centro de Informtica, Ufpe. Recife, PE. 2013.
25. PERRIS, P. A. Colaborao e coordenao de grupos em Ambiente LMS. 2013. 125
f. Dissertao (Mestrado) - Curso de Cincia da Computao, Centro de
Informtica, Ufpe. Recife, PE. 2013.
26. GOVERNO FEDERAL. Amadeus. Portal do Software Pblico Brasileiro. Disponivel
em: <http://www.softwarepublico.gov.br/vercomunidade?community_id=9677539>. Acesso em: 13 out. 2014.
27. SHAPIRO, R. et al. BPMN 2.0 Handbook. 2. ed. [S.l.]: [s.n.], 2012.
28. ROCHA, H.; BARANAUSKAS, M. Design e avaliao de interfaces humanocomputador. So Paulo, SP: IME-USP, 2000. 242 p.

Universidade Federal de Pernambuco Centro de Informática

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Universidade Federal de Pernambuco Centro de Informática

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAO EM CINCIA DA COMPUTAO

CONSISTNCIA DE INTERFACES EM SOFTWARE LIVRE:

Paulo Henrique da Cruz Pereira