Universidade Federal do Estado do Rio de Janeiro

Centro de Cincias Exatas e Tecnologia

Escola de Informtica Aplicada

SISTEMA WEB DE ANNCIO DE VAGAS EM IMVEIS: UM EXEMPLO DE

DESENVOLVIMENTO GIL COM RUBY ON RAILS
Matheus Charif Penchel
Rodrigo Cantarela

Orientador
Asterio Kiyoshi Tanaka

RIO DE JANEIRO, RJ BRASIL.

JUNHO DE 2015

SISTEMA WEB DE ANNCIO DE VAGAS EM IMVEIS: UM EXEMPLO DE

DESENVOLVIMENTO GIL COM RUBY ON RAILS

Matheus Charif Penchel

Rodrigo Cantarela

Projeto de Graduao apresentado Escola

de Informtica Aplicada da Universidade Federal
do Estado do Rio de Janeiro (UNIRIO) para
obteno do ttulo de Bacharel em Sistemas de
Informao.

Aprovada por:

__________________________________________________
Asterio Kiyoshi Tanaka, Ph.D. (UNIRIO)

__________________________________________________
Luiz Carlos Montez Monte, D.C. (UNIRIO)

__________________________________________________
Geiza Maria Hamazaki da Silva, D.C. (UNIRIO)

RIO DE JANEIRO, RJ BRASIL.

JUNHO DE 2015

AGRADECIMENTOS

Agradecemos aos nossos queridos amigos que nos apoiaram

nesta jornada em busca do conhecimento. Aos familiares que sempre
estiveram ao nosso lado e a UNIRIO por ser uma universidade de
excelncia no ensino.
Rodrigo Cantarela e Matheus Charif Penchel

RESUMO

Este trabalho teve como objetivo aplicar conhecimentos adquiridos ao longo

do curso de Bacharelado em Sistemas de Informao para desenvolver uma
aplicao Web, usando prticas do processo de desenvolvimento gil Scrum. Foi
feita uma breve anlise do mercado de locao imobiliria no Estado do Rio de
Janeiro, que constatou uma oportunidade de criao de um sistema Web
especializado em anncios de vagas de imveis. O desenvolvimento do sistema
envolveu desde o levantamento de requisitos e modelagem de casos de uso e de
classes at a implementao usando o framework Ruby on Rails. A conjugao do
uso deste framework com as prticas do Scrum resultou em um desenvolvimento
rpido e eficaz do sistema, que pode ser replicado em outras aplicaes.

Palavras-chave: Desenvolvimento gil, Scrum, Ruby on Rails, Sistema de Aluguel

Imobilirio.

ABSTRACT

This work aimed to apply knowledge acquired during the Bachelor in

Information Systems course to develop a Web application using practices of the
Scrum agile development process. A brief analysis of the real state rental market in
the state of Rio de Janeiro was made, which found an opportunity to create a Web
system specialized on advertisement of vacancies in properties. The development of
the system involved from requirements gathering and modeling of use cases and
classes to implementation using the Ruby on Rails framework. The combination of
using this framework with Scrum practices resulted in a rapid and efficient
development of the system, which can be replicated in other applications.

Keywords: Agile Development, Scrum, Ruby on Rails, Real Estate Rental System.

NDICE

1 INTRODUO ................................................................................................................... 1
1.1 Motivao ..................................................................................................................... 1
1.2 Justificativa ................................................................................................................... 1
1.3 Objetivo do projeto ....................................................................................................... 2
1.4 Organizao do trabalho .............................................................................................. 2
2 ANLISE DE MERCADO ................................................................................................... 4
2.1 ndice FIPE-ZAP........................................................................................................... 4
2.2 Levantamento da situao atual ................................................................................... 5
2.3 Sobre a Lei do Inquilinato ............................................................................................. 5
2.4 Soluo esperada ........................................................................................................ 5
2.5 Possibilidades de arrecadao financeira..................................................................... 6
3 LEVANTAMENTO DE REQUISITOS E MODELAGEM DO SISTEMA ............................... 7
3.1 Levantamento de requisitos.......................................................................................... 7
3.1.1 Requisitos Funcionais ............................................................................................ 7
3.1.2 Requisitos no funcionais ...................................................................................... 8
3.2 Diagrama de Casos de Uso.......................................................................................... 8
3.3 Casos de Uso ............................................................................................................... 9
3.3.1 Cadastrar ............................................................................................................... 9
3.3.2 Preencher ............................................................................................................ 11
3.3.3 Buscar ................................................................................................................. 13
3.4 Diagrama de Classes ................................................................................................. 15
4 METODOLOGIA E DESENVOLVIMENTO GIL.............................................................. 18
4.1 Antecedentes ............................................................................................................. 18
4.2 O Manifesto gil ......................................................................................................... 18
4.3 Desenvolvimento gil com Ruby on Rails ................................................................... 20
4.3.1 Scrum .................................................................................................................. 20
4.3.2 Sprints ................................................................................................................. 21
4.3.3 Scrum points ........................................................................................................ 22
4.3.4 Product Backlog ................................................................................................... 22
4.3.5 Sprints ................................................................................................................. 24
4.4 Comparao entre Scrum points e Function points .................................................... 26
5 IMPLEMENTAO USANDO RUBY ON RAILS ............................................................. 27

5.1 Viso tcnica geral ..................................................................................................... 27

5.1.1 Ruby .................................................................................................................... 27
5.1.2 Rails..................................................................................................................... 27
5.1.3 Model-View-Controller (MVC) .............................................................................. 27
5.2 Criao do Projeto e Implementao do Primeiro Sprint ............................................ 28
5.2.1 Criao do Projeto ............................................................................................... 28
5.2.2 Primeiro Sprint ..................................................................................................... 29
5.3 Segundo Sprint........................................................................................................... 33
5.4 Terceiro Sprint ............................................................................................................ 34
5.5 Quarto Sprint .............................................................................................................. 39
5.6 Quinto Sprint .............................................................................................................. 41
6 CONCLUSO ................................................................................................................... 49
BIBLIOGRAFIA ................................................................................................................... 50

LISTA DE FIGURAS
Figura 1 - ndice FIPE-ZAP .................................................................................................... 4
Figura 2 - Caso de uso Cadastrar ....................................................................................... 8
Figura 3 - Caso de uso Preencher e Buscar ....................................................................... 9
Figura 4 - Diagrama de Classe ............................................................................................ 15
Figura 5 - Tabelas no PostgreSQL....................................................................................... 17
Figura 6 - Ciclo de desenvolvimento Scrum ......................................................................... 21
Figura 7 - Tela Principal ....................................................................................................... 46
Figura 8 - Cadastro de Quartos ........................................................................................... 46
Figura 9 - Formulrio de Reserva ........................................................................................ 47

LISTA DE TABELAS
Tabela 1 - Product Backlog .................................................................................................. 24

1 INTRODUO
1.1 Motivao
Com o grande aquecimento do mercado imobilirio no Estado do Rio de
Janeiro e com a realizao de um grande evento internacional

(Olimpadas de

2016), existe uma grande oportunidade de demanda para um sistema web de

divulgao de aluguel de vagas em imveis. Essa oportunidade motivou o
desenvolvimento de um sistema capaz de oferecer, de forma simples e de fcil
acesso, um mecanismo de busca de vagas em imveis que so cadastrados pelos
prprios proprietrios e sendo compatvel com os principais dispositivos existentes
no mercado, tais como tablets, smartphones e desktops.

1.2 Justificativa
O sistema proposto neste trabalho oferece uma soluo com software livre e
de fcil utilizao para os usurios, ajudando-os a buscar e anunciar vagas em
imveis disponveis no Estado do Rio de Janeiro.
O sistema Imobiliria Web deve possuir uma interface intuitiva e de fcil
acesso dando ao usurio opo de buscar vagas em imveis a partir de suas datas
de disponibilidade, preenchendo um formulrio de interesse, que ser enviado por email ao locador, com todos os dados do interessado. O usurio poder visualizar as
fotos dos cmodos do imvel e ter acesso a um FAQ onde ele poder obter ajuda
sobre a lei vigente do inquilinato, dicas de cuidados a serem tomados, como se
estabelecer um contrato de aluguel e dicas para se estabelecer um ambiente
saudvel.
Como a ferramenta utilizada para desenvolver o sistema se enquadra
perfeitamente em diversos mtodos de desenvolvimento gil, possvel acrescentar
funcionalidades ou refatorar o sistema de acordo com novas demandas e/ou
observaes dos locadores, podendo, no futuro, inclusive, oferecer outras
funcionalidades de controle e uso do sistema.
Financeiramente, a sua rentabilidade pode vir de publicidade, da anlise e
venda de dados em caso de grande procura de locatrios, ou at mesmo do sistema
ser personalizado para alguma empresa imobiliria.
1

1.3 Objetivo do projeto

O objetivo deste projeto consolidar conhecimentos adquiridos atravs das
disciplinas do Bacharelado em Sistemas de Informao (BSI): de desenvolvimento
(TP1, TP2, EDD1, EDD2, PCS, PCS-SGBD, PM, PS), de modelagem (FSI, AS), de
banco de dados (BD1, BD2), de empreendedorismo (AEA, Empreendedorismo) e de
front-end (DPW). Adicionalmente, o projeto busca demonstrar a possibilidade de
lanar um produto no mercado que respeite as metodologias e tcnicas aprendidas
no decorrer do curso de BSI.

1.4 Organizao do trabalho

O presente trabalho est estruturado em captulos e, alm desta introduo,
est organizado da seguinte forma:
Captulo 2: Anlise de Mercado
Neste captulo, so apresentados a breve anlise e o levantamento feito do
mercado imobilirio do Estado do Rio de Janeiro, levando em considerao as
oportunidades de criao do sistema Imobiliria Web e uma possvel forma de
capitalizao do sistema.
Captulo 3: Levantamento de Requisitos e Modelagem do Sistema
So descritos os requisitos funcionais e no funcionais do sistema, dos
principais casos de uso e do diagrama de classes resultante do banco de dados do
sistema.
Captulo 4: Metodologia e Desenvolvimento gil
So abordados os tpicos referentes ao uso de metodologia gil em
desenvolvimento de software, uma breve descrio do Scrum e de como ele ser
utilizado no desenvolvimento do sistema Imobiliria Web junto com a descrio dos
principais sprints de desenvolvimento.

Captulo 5: Implementao usando Ruby on Rails

2

A tecnologia utilizada no projeto e a construo do sistema so mostradas

neste captulo, com suas peculiaridades e com uma descrio detalhada das
bibliotecas adotadas para o desenvolvimento. Toda a infraestrutura utilizada
tambm explicitada e justificada neste captulo.
Captulo 6: Concluso
O captulo descreve o resultado final do trabalho, evidenciando a facilidade do
uso da ferramenta pelos usurios finais, os pontos fortes e fracos de todo o processo
adotado, contribuies, limitaes e trabalhos futuros.

2 ANLISE DE MERCADO
Este captulo relata uma breve anlise informal de mercado que, atravs de
consultas a pginas especializadas e buscas na Internet, justifica a relevncia do
sistema desenvolvido junto ao mercado imobilirio.

2.1 ndice FIPE-ZAP

O mercado imobilirio encontra-se muito aquecido no Brasil, principalmente
no Rio de Janeiro, o que aumenta a motivao para desenvolver um projeto nessa
rea. O ndice FIPE-ZAP fornecido por duas instituies conforme a descrio
abaixo:
FIPE, Fundao Instituto de Pesquisas Econmicas, uma
fundao de direito privado, sem fins lucrativos, criada em 1973, que
apoia o Departamento de Economia da Faculdade de Economia,
Administrao e Contabilidade da Universidade de So Paulo (FEAUSP) nas reas de pesquisa e ensino.
O ZAP, uma empresa do Globo, o mais completo, moderno e
eficiente portal de classificados da Internet brasileira [Globo, 2015]

Em uma consulta realizada em Janeiro de 2015, o grfico abaixo demonstra a

variao do ndice FIPE-ZAP sobre transaes de aluguel durante o perodo 20082014 na cidade do Rio de Janeiro.

Figura 1 - ndice FIPE-ZAP

fonte: http://www.zap.com.br/imoveis/fipe-zap-b/

possvel observar a valorizao dos aluguis aps o anncio do Brasil como

sede da Copa do Mundo de 2014, o que aconteceu no final de 2007. At a
realizao da Copa do Mundo, o grfico indica uma valorizao que chega a 150%
4

no incio do evento; aps a realizao deste evento, uma pequena desvalorizao

ocorre. Com a realizao das Olimpadas de 2016 na cidade do Rio de Janeiro, h
um possvel crescimento na valorizao do mercado imobilirio, indicando assim
uma oportunidade para o desenvolvimento do sistema Imobiliria Web.

2.2 Levantamento da situao atual

Conforme pesquisa feita em mecanismos de busca, no existe um sistema
gratuito e sem burocracias para o anncio de vagas em imveis por locadores. Para
que um locador anuncie seu imvel, ou paga uma taxa para a utilizao do sistema
ou paga um valor para o sistema ou pessoa responsvel por uma indicao. Todos
os sistemas encontrados tinham foco somente em anncios de vagas de imveis
inteiros.

2.3 Sobre a Lei do Inquilinato

Embora no haja uma pesquisa sobre esse tema, supe-se que pessoas
interessadas em alugar vagas em imveis, assim como locadores de vagas, no
possuam o perfil usual de locadores e locatrios de imveis. Assim, um sistema para
atender a esse pblico deve oferecer dicas aos seus usurios sobre as prticas e
cuidados a serem tomados ao se estabelecer um contrato de aluguel, com base na
Lei do Inquilinato (Lei no 8.245, de 18 de outubro de 1991). Essa Lei, que trata das
obrigaes e direitos tanto do locatrio quanto do locador, deve estar disponvel e
atualizada no sistema para consultas e esclarecimentos.

2.4 Soluo esperada

De acordo com o levantamento da situao atual, desejvel uma soluo de
fcil acesso e extremamente prtica, seguindo assim os requisitos levantados. Tratase de um sistema web, gratuito, que possua funcionalidades que facilitam o anncio
de vagas por parte do locador e tambm a busca de vagas por parte de possveis
locatrios.
O sistema deve permitir que um locador cadastre uma conta, sem qualquer
custo, podendo assim cadastrar seus imveis. Feito isto, deve ser possvel cadastrar
seus quartos, classificando-os de acordo com o tipo e adicionando os mveis nele
contidos.
5

Por parte de um possvel locatrio, basta que procure uma vaga de seu
agrado, preencha um formulrio de reserva e aguarde o contato do locador, j que
um e-mail com o formulrio ser enviado ao administrador do sistema e este fara o
contato notificando o interesse da vaga. Caso no encontre o que procura, pode
preencher um formulrio com as informaes da vaga que procura e o administrador
ao receber a notificao ir avisar a todos os locadores que tenham o perfil da vaga
desejada. O locatrio aps ser notificado pode entrar em contato com o interessado,
para verificar se ainda a interesse e estabelecer o contrato de aluguel.
Em caso de vaga preenchida por um locatrio, basta o locador alterar a data
de disponibilidade desta, para que outros potenciais locatrios no preencham os
formulrios de vagas ocupadas. Toda a parte jurdica e financeira deve ser feita fora
do sistema de aluguis de vagas.

2.5 Possibilidades de arrecadao financeira

A arrecadao financeira no modelo de negcio do sistema depende nica e
exclusivamente da forte adeso de locadores e locatrios, de forma que seja
possvel publicar propagandas no sistema. Alm disso, o sistema pode ser
personalizado para alguma imobiliria especfica, facilitando assim seus controles de
vagas e tambm modernizando sua publicidade.
Em caso de grande procura por algum tipo especfico de vaga, esta
informao poderia ser negociada com grandes imobilirias para lhes dar uma
vantagem no mercado imobilirio.

3 LEVANTAMENTO DE REQUISITOS E MODELAGEM

DO SISTEMA
Este captulo descreve o levantamento dos principais requisitos funcionais e
no funcionais, os principais casos de uso e o diagrama de classe referente ao
Banco de Dados utilizado para construo do sistema Imobiliria Web, aplicando as
melhores prticas de documentao.

3.1 Levantamento de requisitos

Abaixo seguem os requisitos funcionais; Requisitos que so traduzidos em
funcionalidades dentro do sistema; na seo seguinte, so apresentados os
requisitos no-funcionais, ou seja, os requisitos que independem da implementao
do sistema, mas que so necessrios para o seu uso.

3.1.1 Requisitos Funcionais

RF01: O sistema deve permitir que um usurio locador cadastre e altere seus
dados cadastrais.
RF02: O sistema deve permitir que um usurio locador cadastre o imvel,
altere dados do imvel ou exclua um imvel.
RF03: O sistema deve permitir que um usurio locador cadastre um quarto do
imvel cadastrado, altere os dados e exclua o quarto.
RF04: O sistema deve permitir que um usurio locatrio busque uma vaga.
RF05: O sistema deve permitir que um usurio locatrio preencha um
formulrio declarando interesse em uma vaga.
RF06: O sistema deve conter um formulrio que deve ser preenchido por um
locatrio caso ele mostre interesse por uma vaga.
RF07: O sistema deve permitir que um usurio tenha acesso Lei n 8.245
em formato digital.
RF08: O sistema deve permitir que o usurio administrador preencha as
mensagens de aviso e demais textos do sistema.
RF09: O sistema deve disponibilizar uma pgina de FAQ, com dicas para os
locatrios sobre boas prticas de convvio em quartos dentro de imveis e dicas de
como controlar despesas fixas e variveis.
7

3.1.2 Requisitos no funcionais

RNF01: O sistema deve ser desenvolvido para a web.
RNF02: O sistema deve poder ser acessado independentemente do
dispositivo.
RNF03: O sistema deve ter um design responsivo.
RNF04: O sistema deve ser desenvolvido em Ruby on Rails.
RNF05: O sistema deve utilizar o banco de dados PostgreSQL.
RNF06: O sistema deve ter uma interface de usurios que seja agradvel e
intuitiva.

3.2 Diagrama de Casos de Uso

Abaixo seguem os diagramas dos principais casos de uso do sistema
Imobiliria Web:

Figura 2 - Caso de uso Cadastrar

Figura 3 - Caso de uso Preencher e Buscar

3.3 Casos de Uso

Seguem as descries dos principais casos de uso do sistema, ilustrados nos
diagramas.

3.3.1 Cadastrar
3.3.1.1 Cadastrar-se no sistema
Descrio sucinta:
O sistema ir permitir que um usurio locador se cadastre no sistema de forma
gratuita e rpida.
Atores:
Locador.
Requisitos:
RF01
Pr-condies:
Usurio ter um email.
Ps-condies:
Um email de confirmao emitido para o usurio locador para verificao de conta.
9

Campos:
e-mail, senha
Fluxo principal:
A. O usurio ir clicar em cadastrar conta e preencher os campos solicitados.
Fluxo alternativo:
N/A.
Fluxo de exceo:
E1 - O sistema ir emitir uma mensagem de erro caso um email invlido seja
cadastrado.
E2 - O sistema ir emitir uma mensagem de erro caso usurio digite uma
confirmao de senha invlida e direcionado de volta ao campo senha.

3.3.1.2 Cadastrar imveis

Descrio sucinta:
O sistema permite que o usurio cadastre dados do imvel do qual pretende divulgar
vagas de quartos disponveis para aluguel.
Atores:
Locador.
Requisitos:
RF02.
Pr-condies:
O usurio locador deve possuir uma conta cadastrada no sistema.
Ps-condies:
O imvel cadastrado aparecer nas opes de apartamento ao cadastrar um quarto.
Campos:
Tamanho em m, quantidade de banheiros, quantidade de salas, quantidade de
reas de servio, cidade, rua, bairro, nmero e apartamento
Fluxo principal:
A. Usurio deve clicar em Registre-se no cabealho do site

preencher

os

dados do formulrio.
Fluxo alternativo:
N/A
Fluxo de exceo:
10

E1 - O sistema ir emitir erro caso o usurio coloque algum dado no formulrio que
no esteja de acordo com as regras definidas de cada campo.

3.3.1.3 Cadastrar quarto

Descrio sucinta:
O sistema permite que o usurio locador seja capaz de cadastrar os quartos
disponveis para aluguel em cada imvel cadastrado.
Atores:
Locador.
Requisitos:
RF03.
Pr-condies:
O usurio deve ter cadastrado um imvel no sistema.
Ps-condies:
O quarto cadastrado ser publicado no site como quarto disponvel para alugar.
Campos:
Descrio, data de disponibilidade, apartamento, preo, tipo de quarto, cdigo,
tamanho, mveis e foto principal.
Fluxo principal:
A. O usurio ao entrar na listagem de quartos clica em

cadastrar quarto.

B. O usurio aps clicar cadastrar quarto, preenche o formulrio com os campos

pedidos e clica em salvar.
Fluxo alternativo:
N/A
Fluxo de exceo:
E1 - Caso o usurio no cadastre algum campo obrigatrio do formulrio o sistema
ir emitir uma mensagem de erro.
E2 - Caso o usurio de preencha algum campo com algum caractere no permitido
ele ir emitir uma mensagem de erro.

3.3.2 Preencher
3.3.2.1 Preencher formulrio reserva
Descrio sucinta:
11

O usurio cliente poder preencher um formulrio onde ele demonstra interesse por
uma vaga, solicitando reserva por um perodo determinado de tempo.
Atores:
Cliente.
Requisitos:
RF05.
Pr-condies:
N/A
Ps-condies:
Um email ir ser enviado ao locatrio com os dados do interessado pela vaga.
Campos:
Nome completo, e-mail, telefone, data de nascimento, check-in, check-out e cpf.
Fluxo principal:
A. O usurio ao fazer a busca de quartos disponveis
B. Clicar no quarto desejado
C. Selecionar data de check-in e check-out
D. Clicar em Reserve agora.
Fluxo alternativo:
N/A.
Fluxo de exceo:
E1 - O sistema ir emitir uma mensagem de erro caso algum campo tenha sido
deixado em branco ou preenchido com algum caractere no permitido.

3.3.2.2 Preencher formulrio de interesse por vaga

Descrio sucinta:
O usurio cliente poder preencher um formulrio de interesse por vaga para ser
avisado quando alguma estiver disponvel.
Atores:
Cliente.
Requisitos:
RF06.
Pr-condies:
N/A
Ps-condies:
12

O usurio cliente ser avisado por email quando a vaga desejada estiver disponvel
no sistema.
Campos:
Nome completo, e-mail, telefone, data de nascimento, check-in, check-out, cpf, em
que cidade gostaria de ficar, valor mnimo e valor mximo.
Fluxo principal:
A. O usurio deve clicar no menu no consegue encontrar um quarto.
B. O usurio deve preencher os campos do formulrio.
Fluxo alternativo:
N/A.
Fluxo de exceo:
E1 - O sistema ir emitir uma mensagem de erro caso algum campo tenha sido
deixado em branco ou preenchido com algum caractere no permitido.

3.3.3 Buscar
3.3.3.1 Buscar vagas de quartos em imveis.
Descrio sucinta:
O usurio cliente poder realizar busca de vagas disponveis nos imveis
cadastrados no sistema.
Atores:
Cliente.
Requisitos:
RF04.
Pr-condies:
N/A
Ps-condies:
O usurio cliente ir visualizar todas as vagas disponveis no sistema referente aos
critrios de busca selecionados.
Campos:
Ms, ano, estado e Bairro
Fluxo principal:
A. O usurio deve selecionar os critrios de busca que ele deseja para a busca
de vaga.
B. O usurio deve clicar no boto busca.
13

Fluxo alternativo:
N/A.
Fluxo de exceo:
E1 - O sistema ir emitir uma mensagem de erro caso algum dos campos no forem
preenchidos.
E2 O sistema ir emitir uma mensagem de erro caso nenhuma vaga seja
encontrada com os critrios definidos pelo usurio.

14

3.4 Diagrama de Classes

Abaixo segue o diagrama de classes gerado a partir de uma biblioteca para
Ruby on Rails chamada RailRoady [Smaldone, 2008] que gera alguns diagramas
UML. As classes esto explicadas a seguir.

Figura 4 - Diagrama de Classe

15

A classe User utilizada para cadastrar e realizar o login de locadores, que

por sua vez podem possuir inmeros Apartments e, dentro destes, diversos Rooms,
que possuem RoomTypes. A classe Image armazena as fotos destes Rooms,
enquanto o BookingForm o formulrio, que fica armazenado no sistema, para
guardar o interesse de possveis locatrios em relao a algum quarto especfico.
Uma vez que um Room formalmente alugado, o User associado pode registrar
uma Reservation, com datas de check-in e check-out para que o sistema entenda
quando este quarto estar novamente disponvel.
O MessageForm um formulrio de mensagem que est disponvel na
pgina pblica de cada quarto, servindo para notificar o User associado de qualquer
dvida, observao ou crtica apresentada por algum visitante. Um Apartment est
ligado a uma City que por sua vez est ligado a um Country. A classe Content serve
para criar pginas estticas para cada cidade cadastrada no sistema, caso o
administrador ache interessante t-las; cada cidade possui tambm um Banner, que
mostrado na home do sistema.
Os Labels so mensagens e rtulos que esto espalhados pelo sistema e que
podem ser modificados a qualquer momento pelo administrador. Tanto o RentForm
quanto o RegistryForm so formulrios, onde o primeiro uma tabela que permite
que um possvel locador entre em contato com a administrao do website,
enquanto o segundo um formulrio que permite que possveis locatrios
descrevam os quartos que esto procurando caso no o encontrem no sistema.
Por ltimo, a tabela Ability responsvel por armazenar as informaes de
permisso de usurios.
A figura 5 apresenta as tabelas do banco de dados do sistema Imobiliria
Web, no PostgreSQL, visualizadas atravs da ferramenta PGAdmin III.

16

Figura 5 - Tabelas no PostgreSQL

17

4 METODOLOGIA E DESENVOLVIMENTO GIL

Depois de realizada a anlise de mercado e o levantamento de requisitos
descritos nos captulos precedentes, neste captulo abordamos a metodologia de
desenvolvimento gil que utilizada na implementao do sistema Imobiliria Web.
Ser apresentada uma breve introduo histrica da metodologia e sua vantagem na
aplicao deste projeto.

4.1 Antecedentes
A expresso Metodologias geis revelou-se mundialmente em 2001, por
meio de uma reunio entre 17 especialistas em processos de desenvolvimento de
software, onde foi criada a Aliana gil e, em consequncia, surgiu o to conhecido
Manifesto gil [Kent, 2001].
So estes os signatrios do Manifesto gil: Kent Beck, Mike Beedle, Arie van
Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning,
Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.
O Manifesto para o Desenvolvimento gil de Software, como foi definido,
estabelece alguns princpios e conceitos, como:
Pessoas e interaes, ao contrrio de processos e ferramentas.
Software executvel, ao contrrio de documentao extensa e confusa.
Colaborao do cliente, ao contrrio de constantes negociaes de contratos.
Respostas rpidas para as mudanas, ao contrrio de seguir planos
previamente definidos.

4.2 O Manifesto gil

Segundo o Manifesto gil, a maior prioridade satisfazer o cliente atravs da
entrega contnua e adiantada de software com valor agregado. Ao contrrio do que a
filosofia clssica de desenvolvimento de software sugere, as mudanas nos
requisitos so bem-vindas, mesmo que tardiamente no desenvolvimento. Isto porque
processos geis tiram proveito das mudanas visando vantagem competitiva para o
cliente.

18

Nele

consta

tambm

ideia

de

entrega

contnua,

pois

entregar

frequentemente software funcionando, de algumas semanas a poucos meses, com

preferncia menor escala de tempo, ajuda o cliente a verificar se suas demandas
esto sendo atendidas. Para isso, pessoas de negcio e desenvolvedores devem
trabalhar diariamente em conjunto por todo o projeto.
fundamental que os projetos sejam construdos ao redor de indivduos
motivados que precisam de todo ambiente e suporte necessrio para que se sintam
confortveis; importante ressaltar que, para que isso acontea, preciso confiar
em suas capacidades.
A ideia que a medida primria de progresso do projeto seja software
funcionando, e para isso necessrio um desenvolvimento sustentvel, ou seja, que
os patrocinadores, desenvolvedores e usurios sejam capazes de manter um ritmo
constante indefinidamente.
O mtodo mais eficiente e eficaz de transmitir informaes para e entre uma
equipe de desenvolvimento atravs de conversa face a face: deve-se cortar
reunies prolongadas e principalmente demandas via e-mail ou alguma outra
ferramenta semelhante. Uma prtica muito utilizada por quem segue o Extreme
Programming e que atende a essa ideia, por exemplo, o Stand-up Meeting, que
deve ocorrer em poucos minutos e tem como objetivo manter toda a equipe
atualizada sobre o que cada um est fazendo, que problemas est encontrando e
qual ser sua prxima tarefa.
Se software funcionando a medida primria de progresso, deve-se ter
contnua ateno excelncia tcnica e bom design, para aumentar a agilidade do
processo, desta forma simplificando toda e qualquer refatorao de cdigo que
possa vir de novos requisitos.
tambm importante ter simplicidade, visto que as melhores arquiteturas,
requisitos e designs emergem de equipes auto organizveis, voltando ao ponto de
ter confiana e dar liberdade aos profissionais envolvidos no projeto.
Para melhorar a auto-organizao da equipe, sugerido que, em intervalos
regulares, a equipe reflita sobre como se tornar mais eficaz para ento refinar e
ajustar seu comportamento de acordo.

19

4.3 Desenvolvimento gil com Ruby on Rails

Segundo definio do site [Hansson, 2003] Ruby on Rails um framework de
desenvolvimento web (gratuito e de cdigo aberto) otimizado para a produtividade
sustentvel e a diverso do programador. Ele procura tornar mais fcil o
desenvolvimento e instalao dos sistemas web. focado em produzir sistemas
centrados no banco de dados, isto , seu principal trabalho manipular dados sem
que os utilizadores do sistema necessitem de utilizar a linguagem SQL. Para que
isso possa ser efetuado, o Rails utiliza o ActionPack, uma biblioteca para auxlio na
gerao das pginas que se comunicam com o banco de dados.
Neste projeto, o sistema Imobiliria Web foi desenvolvido utilizando o
framework Ruby on Rails e obedecendo arquitetura MVC (Model View Controller),
separando cada parte do cdigo em sua camada, de modo que estas partes
interagem de uma forma nica.

4.3.1 Scrum
Segundo definio de seus idealizadores [Schwaber, 2013], Scrum um
framework para desenvolvimento e manuteno de produtos complexos. Os
projetos so divididos em ciclos (tipicamente mensais) chamados de Sprints. O
Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser
executado. Metodologias geis de desenvolvimento de software so iterativas e
incrementais, ou seja, o trabalho dividido em iteraes incrementais, que so
chamadas de Sprints no caso do Scrum. A imagem abaixo exemplifica o ciclo de
desenvolvimento do Scrum.

20

Figura 6 - Ciclo de desenvolvimento Scrum

fonte: http://www.desenvolvimentoagil.com.br/scrum/

4.3.2 Sprints
No Scrum, o trabalho realizado em iteraes ou ciclos de at um ms. O
trabalho realizado em cada sprint deve criar algo de valor tangvel para o cliente ou
usurio. Sprints so timeboxed (isto , possuem durao fixa) para que tenham
sempre um incio e fim (datas fixas), e, idealmente, todos eles devem estar com a
mesma durao.
O Sprint Backlog uma lista de tarefas que o Scrum Team se compromete a
fazer em um Sprint como um potencial incremento de produto entregvel. Os itens
do Sprint Backlog so extrados do Product Backlog pela equipe, com base nas
prioridades definidas pelo Product Owner e a percepo da equipe sobre o tempo
que ser necessrio para completar as vrias funcionalidades; tal noo de tempo
est explicitada a seguir. A quantidade de itens do Product Backlog que sero
trazidos para o Sprint Backlog definida pelo Scrum Team que se compromete a
implement-los durante o Sprint. Os itens do Product Backlog so extrados a partir
de User Stories, que so quebradas e divididas em tarefas at que qualquer membro
da equipe de desenvolvimento seja capaz de entend-las e implement-las, desta
forma estando prontas para entrar em um Sprint Backlog.
21

4.3.3 Scrum points

Aps a diviso das User Stories em tarefas, prtica comum no framework
Scrum pontuar as tarefas. Diversos conjuntos de pontos so utilizados no mercado
de trabalho, geralmente se baseando na sequncia de Fibonacci, com algumas
modificaes; o usado ao invs do nmero 2 pois os decks de poker eram
comercializados com esta carta. O conjunto de pontos adotado neste projeto : , 1,
3, 5, 8, 13.
Segue a idia geral de cada um desses pontos:
: Tarefa de baixa complexidade e rapidamente executada.
1: Tarefa de baixa complexidade mas que exige algum tempo.
3: Tarefa de mdia complexidade ou que exija um tempo considervel.
5: Tarefa de mdia complexidade mas que exige bastante tempo.
8: Tarefa de alta complexidade ou que exija muito tempo.
13: Tarefa de alta complexidade, onde os desenvolvedores no tm muita
ideia de como execut-la ou de quanto tempo ir levar. Costuma significar
que a tarefa deve ser dividida em sub-tarefas.

4.3.4 Product Backlog

Abaixo segue o Product Backlog para o sistema Imobiliria Web, com as
histrias dos Usurios divididas em Tarefas e com seus respectivos pontos.

User Story

Tarefas

O locador deve ser capaz de CRUD1 de Apartamentos.

cadastrar
com

um

todas

disponveis

Pontos
3

apartamento
as

vagas

CRUD de Quartos.

dentro

dele, Conexo com o S3 da Amazon para 3

informando mveis existentes, armazenar fotos de Quartos.
preo e cadastrando fotos.
CRUD de Mveis.

O possvel locatrio deve ser Filtro de quartos por cidade, ms e 5

Para melhor entendimento CRUD o acrnimo de Create, Read, Update, Delete

22

capaz de encontrar um quarto ano.

que lhe interesse, de acordo
com a cidade, o ms e o ano
em que deseja ocupar a vaga.
Quando

encontrar

Formulrio de declarao de interesse 1

em um quarto especfico.

que Funcionalidade

que

altera

a 1

procura, deve poder avisar ao disponibilidade do quarto uma vez que

locador

seu

preenchendo
com

interesse, ele ocupado.

um

todos

formulrio

os

dados

relevantes.

Funcionalidade de envio de e-mail.

Formulrio de declarao de interesse 1

por quarto enviado por e-mail ao
locador.

Os possveis locatrios devem Desenvolver

encontrar

as

vagas

sistema,

preencher

assim
um

index

da

pgina 5

mais principal.

prximas na pgina principal

do

como

formulrio

Disponibilizar

quartos

livres

mais 3

recentes na pgina principal.

informando o seu interesse Formulrio

de

aviso

de

interesse 1

caso no tenha encontrado quando no encontra um quarto que

uma vaga que lhe interesse.

lhe interessa.
Desenvolver menu.

O possvel locatrio deve ter a Lei do Inquilinato disponvel em uma 1

Lei do Inquilinato disponvel a aba do sistema.
todo o momento, para que ele
saiba exatamente o que deve
e no deve fazer quando
ocupar uma vaga.
Um possvel locador deve ser Desenvolver classe de usurios.

capaz de criar uma conta de

Desenvolver permisses de usurios.

23

Permitir o sign up de qualquer locador.

maneira fcil e rpida.

O administrador do sistema Implementar

dever

ter

opo

melhor

adequar

de 1

de administrador.

modificar os textos do sistema

para

permisso

os

anncios de acordo com a

poca em que se encontra.

Renderizar

os

alertas

nas

views 1

corretas.
CRUD de alertas.

O sistema deve estar no ar, Fazer o deploy do sistema no Heroku.

com um layout agradvel e

com as informaes sendo
persistidas em um banco de
dados.

Incorporar as bibliotecas do Twitter 5

Bootstrap.
Configurar

banco

de

dados 1

PostgreSQL.
Fazer

design

das

pginas

do 8

sistema.
Total de pontos: 61
Tabela 1 - Product Backlog

4.3.5 Sprints
Abaixo segue a diviso de Sprints adotada no desenvolvimento do sistema:
Sprint 1 (12 pontos) - Janeiro: Desenvolver a Index (5), Configurar o banco
de dados PostgreSQL (1), Fazer o deploy do sistema no Heroku (3), Desenvolver a
classe de Usurios (3).
Motivao: A equipe achou interessante desenvolver primeiro a interface do
sistema, assim como preparar boa parte da sua infraestrutura. Ao criar o projeto, o
banco de dados automaticamente fica pronto, facilitando assim a criao da classe e
tabela de Usurios. Feito isto, foi hospedado o projeto no Heroku, deixando pronto
assim o deploy.
Sprint 2 (13 pontos) - Fevereiro: Fazer o design das pginas do sistema (8),
Incorporar as bibliotecas do Twitter Bootstrap (5).
24

Motivao: Como a index tem um layout nico, pouca coisa dela pode ser
aproveitada para as demais pginas. Foi priorizado o design de todas as pginas
pensadas do sistema, assim como a incorporao das bibliotecas do Twitter
Bootstrap, que facilita a implementao deste design.
Sprint 3 (12 pontos) - Maro: CRUD de Apartamentos (3), CRUD de Quartos
(3), CRUD de Mveis (3), CRUD de Alertas (3).
Motivao: Com toda a parte visual pronta e com a infraestrutura
praticamente terminada, chega a hora da equipe dar ateno nica e exclusivamente
ao desenvolvimento. Os CRUDs de Apartamentos, Quartos, Mveis e Alertas para j
podermos mockar boa parte do sistema.
Sprint 4 (12 pontos) - Abril: Filtro de quartos por cidade, ms e ano (5),
Formulrio de declarao de interesse em um quarto especfico (1), Funcionalidade
que altera a data do quarto uma vez que ele ocupado (1), Formulrio de
declarao de interesse por quarto enviado por e-mail ao locador (1), Funcionalidade
de envio de e-mail (3), Desenvolver permisses de usurios (1).
Motivao: Com quase tudo desenvolvido para os locadores, o sprint de Abril focou
nos Locatrios. Foram escolhidos os filtros, os formulrios, os envios de e-mail e as
permisses de usurio, permitindo assim que os locadores s consigam ver seus
prprios apartamentos e quartos.
Sprint 5 (12 pontos) - Maio: Permitir o sign up de qualquer locador (1),
Implementar permisso de administrador (1), Renderizar os alertas nas views
corretas (1), Lei do Inquilinato disponvel em uma aba do sistema (1), Desenvolver
menu (1), Conexo com o S3 da Amazon para armazenar fotos de Quartos (3),
Formulrio de aviso de interesse quando no encontra um quarto que lhe interessa
(1), Disponibilizar quartos livres mais recentes na pgina principal (3).
Motivao: Toques finais. O sign up gratuito e simples para qualquer locador,
a Lei do Inquilinato disponibilizada em uma aba do sistema, os alertas sendo
renderizados de maneira correta em todo o sistema, o menu tanto para locatrios
quanto para locadores, a conexo com o S3 da Amazon para permitir upload de
fotos e o ltimo formulrio do sistema.

25

4.4 Comparao entre Scrum points e Function points

Em projetos de desenvolvimento de software, anlise de ponto de funo
uma tcnica que visa estabelecer uma medida em tamanho para que os gerentes
tenham um conjunto de dados teis e tangveis para dimensionar, estimar, planejar e
controlar projetos de software com rigor e preciso. Os pontos de funo consideram
as funcionalidades implementadas sob o ponto de vista do usurio. A medida
independente da linguagem de programao ou tecnologias que sero utilizadas
para implementao.
A metodologia gil de desenvolvimento SCRUM tambm possui maneiras de
medir o esforo de desenvolvimento, entretanto, no h um gerente de projeto que
ser responsvel por decidir como o software ser medido e sim uma equipe
consciente da importncia da medio para que a mesma consiga auxiliar nos
prazos e na execuo de tarefas, seguindo o processo SCRUM.
Uma vez calculados os pontos de funo de um sistema, cada ponto ser
equivalente a uma poro de uma funcionalidade que ir gerar um esforo em
pessoas x horas e um custo para empresa. Uma equipe de desenvolvedores
experientes atuando sobre esta funcionalidade do sistema no altera os pontos de
funo, o que no acontece na metodologia gil SCRUM onde os SCRUM points
so mtricas relativas que mudam conforme os sprints realizados e com a expertise
da equipe.
No desenvolvimento do projeto Imobiliria Web foi utilizada a metodologia
SCRUM, que foi mais conveniente j que no existiu a contratao de
desenvolvedores e por isso no foi necessrio estabelecer uma medida de custo por
funo desenvolvida e sim uma medida de produtividade da equipe, para ns
mesmos nos mantermos dentro do prazo que estipulamos.

26

5 IMPLEMENTAO USANDO RUBY ON RAILS

Este captulo tem como principal objetivo demonstrar toda a parte tcnica de
implementao de um sistema utilizando o framework Ruby on Rails e servir de guia
para aqueles que quiserem realizar a construo de um projeto utilizando esta
linguagem.

5.1 Viso tcnica geral

Para este projeto, foram adotadas as verses 2.1 do Ruby e 4.0.1 da gem
Rails. Gems so bibliotecas ou programas em um formato padronizado que podem
ser facilmente instaladas pelo gerenciador de pacotes RubyGems, para a linguagem
de programao Ruby. O sistema foi desenvolvido a partir de uma distribuio Linux,
o Ubuntu 14.04 LTS.

5.1.1 Ruby
Ruby uma linguagem de programao dinmica, reflexiva e orientada a
objetos. Foi criada por Yukihiro Matz Matsumoto, no Japo [Matsumoto, 2002].
Ruby foi influenciada pelas linguagens Perl, Smalltalk, Eiffel, Ada e Lisp. Suporta
mltiplos paradigmas da computao, incluindo os funcionais, orientados a objetos e
imperativos, e tem um sistema de tipagem dinmica e gerenciamento de memria
automtico.

5.1.2 Rails
Rails um framework model-view-controller (MVC) que prov estruturas
padro para banco de dados, servios web e pginas web. Ele encoraja e facilita o
uso dos padres da web, como XML ou jSON para transferncia de dados, e HTML,
CSS e JavaScript para exibio e interface de usurio. Alm do MVC, Rails enfatiza
o uso de alguns padres de engenharia de software, como Convention over
Configuration (CoC), Dont Repeat Yourself (DRY) e o Active Record.

5.1.3 Model-View-Controller (MVC)

MVC, ou model-view-controller, um padro de arquitetura de software para
implementao de interfaces de usurio. Ele divide uma aplicao de software em
trs partes (camadas) interconectadas, para diferenciar representaes internas de
27

informao da maneira que o usurio as percebe. Estas camadas so: View (as
telas, ou seja, o que de fato o usurio v do sistema), Controller (os controladores da
informao, ou seja, quem responsvel por fornecer as informaes relevantes
para cada view) e Model (onde fica toda a lgica do negcio da aplicao, e que
acessado pelos controllers).

5.2 Criao do Projeto e Implementao do Primeiro Sprint

5.2.1 Criao do Projeto
Para comear um novo projeto em Rails, dado que o Ruby e o Rails esto
instalados no sistema, basta digitar no terminal o comando:
$ rails new nome-do-projeto

Uma vez feito isso, toda a estrutura padro de uma aplicao Ruby on Rails
ser criada. O arquivo Gemfile lista todas as gems do projeto, inclusive a gem Rails,
enquanto o arquivo Gemfile.lock armazena as verses de cada uma destas gems. A
estrutura de pastas segue como descrito a seguir:
App: onde so armazenados os models, views, controllers, assets (onde ficam
armazenados os arquivos CSS e JavaScript), helpers (arquivos Ruby com
mtodos pblicos

para

utilizao

em

views)

mailers

(arquivos

responsveis por envio de e-mail).

Bin: onde so armazenados arquivos default de inicializao do Rails.
Config: onde so armazenados todos os arquivos de configurao do projeto.
Os arquivos application

(configuraes gerais da aplicao), boot (arquivo

padro de inicializao da aplicao), environment (arquivo padro de

ambientes da aplicao), routes

(arquivo onde so armazenadas todas as

rotas restful do projeto) e database (arquivo onde so armazenadas as

configuraes dos bancos de dados

utilizados para cada ambiente da

aplicao) esto na raiz da pasta. Alm deles, existem trs pastas:

environments (onde esto armazenados os arquivos de configurao para
cada ambiente utilizado pelo desenvolvedor, sendo estes geralmente
prodution, development e test),

initializers

(onde

esto

armazenados
28

arquivos que devem ser carregados na inicializao da aplicao) e locales

(onde esto armazenados os arquivos de internacionalizao do

Rails,

ou

dados

do

seja, de lnguas como Portugus, Ingls e etc.).

Db: onde so armazenados todas as migraes do banco

de

sistema, na pasta migrations, assim como um arquivo de seeds (com os

dados necessrios para o uso mnimo do sistema, prontos para serem
inseridos quando a aplicao lanada) e o schema (arquivo que contm
toda a estrutura do banco de dados, com todas as tabelas, chaves
estrangeiras e ndices) em sua raiz.
Lib: onde podem ser armazenados alguns dos assets do projeto, as tarefas
rake e templates da tarefa rake

j embutida no Rails, que a scaffolding

(no foi utilizada neste projeto, mas a gerao de models, views e

controllers padronizados).
Log: onde ficam armazenados os logs do sistema.
Public: a pasta pblica do projeto, que pode ser utilizada para armazenar
todas as imagens do projeto (s foram colocadas aqui as imagens gerais,
como para footer e header) e as pginas gerais de erro (404, 422 e 500).
Test: a pasta padro para os testes unitrios do Rails.
Vendor/assets: a pasta onde fica toda a pr-compilao dos assets do Rails.
O arquivo Gemfile contm todas as gems que sero usadas no sistema, e
pode ser alterado durante o processo de desenvolvimento de acordo com as
necessidades que os desenvolvedores encontram. Uma vez que o projeto acabou de
ser criado, necessrio executar um comando que baixa e instala todas as gems
listadas. Este o mesmo comando que deve ser utilizado toda vez que uma nova
gem adicionada ao arquivo:
$ bundle install

5.2.2 Primeiro Sprint

29

No primeiro sprint, foram priorizadas as seguintes tarefas: configurar o banco

de dados PostgreSQL, desenvolver a classe de usurios, desenvolver a index e
fazer o deploy do sistema no Heroku [Henry, 2007].
Para

configurar

banco

de

dados,

basta

entrar

no

arquivo

config/database.yml e escrever o nome de usurio do banco, o nome dos bancos,

a senha deste usurio e escolher o adaptar a ser utilizado (por padro o sqlite3),
como segue:
development:
adapter: postgresql
encoding: unicode
database: meu-projeto-development
username: root
password: senha_root
test:
adapter: postgresql
encoding: unicode
database: meu-projeto-test
username: root
password: senha_root
production:
adapter: postgresql
encoding: unicode
database: meu-projeto-production
pool: 5
username: root
password: senha_root

Feito isto, necessrio executar o seguinte comando no terminal:

$ rake db:create

Ele criar todos os bancos especificados no arquivo, desde que os usurios e

senhas estejam corretos e tenham permisso para mexer no PostgreSQL instalado
na mquina ou servidor. Feito isso, criamos a classe User. Atravs do seguinte
30

comando, o Rails cria o modelo, a migrao do banco de dados e os arquivos de

teste responsveis:
$ rails g model User email:string

Ou seja, estamos criando a classe User, sendo que o Rails entende que o
nome das tabelas deve ser sempre no plural, criando assim uma migrao para a
tabela Users; o email:string representa o nome_do_campo:tipo_de_dado esperado.
Poderamos criar diversos campos nesta parte, todos separados por espao, mas no
momento foi decidido que criaramos apenas isso, pois no futuro utilizaremos a gem
Devise para tratar da autenticao de um usurio, e ela traz migraes prestabelecidas para a classe User.
A migrao foi feita, mas precisa ser executada. Para tal, basta executar no
terminal:
$ rake db:migrate

No prprio terminal ser avisado se a migrao foi rodada com sucesso ou se

houve algum problema. importante dizer que, uma vez que se queira preparar o
banco em uma outra mquina, basta rodar rake db:setup que o banco ser criado e
todas as migraes executadas.
Para

criao

da

index

do

sistema,

foi

criado

arquivo

app/views/pages/home.html.erb. A extenso .erb no fim da pgina html permite

que se utilize cdigo do Ruby on Rails em uma pgina HTML. Este arquivo no o
nico

responsvel

pela

index,

entretanto,

pois

existe

arquivo

app/views/layout/application.html.erb que executado em todas as pginas do

sistema. Segue uma parte como exemplo:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
31

<meta name="viewport" content="width=device-width, initial-scale=1">

<title>Imobiliria Web</title>
<%= stylesheet_link_tag "application", media: "all" %>
<%= javascript_include_tag "application" %>
<%= csrf_meta_tags %>
</head>
<body>
<%= yield %>
</body>
</html>

A tag <%= yield %> a responsvel por trazer o contedo da pgina sendo
de fato acessada. importante ressaltar que poderamos ter dado qualquer nome
pasta app/views/pages. Apesar de ela ter sido criada, ainda no existe uma rota
para deix-la acessvel. Como toda rota aponta para uma ao dentro de um
controller, precisaramos criar um controller para exibir a nossa homepage.
Entretanto, no incio do projeto foi definida a adoo da gem HightVoltage uma
biblioteca de gerao de pginas estticas [Thoughtbot,

2009], que ir gerar as

pginas de contedo. Desta forma, adicionamos a gem ao arquivo Gemfile e

executamos o comando mencionado anteriormente. Feito isto, seguindo a
documentao

da

gem,

criamos

arquivo

config/initializers/high_voltage.rb e inserimos o cdigo apontado.

Finalmente, podemos acessar nossa homepage atravs da url do projeto
acrescido de /home. Este o caso da nossa homepage, pois todas as outras pginas
criadas dentro do diretrio /pages precisar de /pages/nome_do_arquivo.
Para terminar as tarefas deste sprint, restou hospedar o sistema no Heroku
[Henry, 2007]. Depois de ter feito uma conta gratuita e ter instalado o git no sistema,
seguem os passos:
$ heroku login
$ heroku create
$ heroku push heroku master
$ heroku run rake db:setup

32

Com isso, o sistema est hospedado no Heroku e pronto para ser acessado.
Lembrando que, toda vez que uma nova verso for enviada ao Heroku, ser
necessrio rodar
$ heroku run rake db:migrate

Caso tenha alguma nova migrao.

5.3 Segundo Sprint

No segundo sprint, foram priorizadas as tarefas de layout do sistema. No
ser detalhado este processo, uma vez que foram utilizadas quase que unicamente
as bibliotecas do Twitter Bootstrap [Twitter, 2010]; nada disso especfico do Rails,
uma vez que esta estratgia pode ser aplicada sobre qualquer projeto web.
O que ser detalhado o asset pipeline da verso 4 do Rails. um
framework que concatena e minimiza os arquivos CSS e JavaScript, assim como
permite a escrita destes arquivos em outras linguagens e pr-processadores, como
CoffeeScript, Sass e ERB. Tecnicamente, o asset pipeline no faz mais parte do
core do Rails, ou seja, no est dentro da gem, sendo uma gem por si s. Mas
uma dependncia padro do Rails, vindo assim habilitado por padro. Para
desabilit-lo, basta adicionar a opo quando for criar a aplicao:
$ --skip-sprockets

A primeira caracterstica do asset pipeline concatenar os arquivos CSS e

JavaScript, desta forma diminuindo a quantidade de chamadas que um browser faz
ao servidor para renderizar uma pgina e, por consequncia, deixando a aplicao
mais rpida.
Todos arquivos CSS so reunidos em um nico arquivo mestre .css, e a
mesma coisa acontece para os arquivos JavaScript, reunidos em um arquivo .js. Em
produo, o Rails por padro aplica um cache sobre estes arquivos, sendo
descartado automaticamente quando algum deles modificado.

33

A segunda caracterstica minificar ou comprimir os arquivos. Esta

minificao do arquivo CSS feita removendo todos os espaos em branco e
comentrios; para o arquivo JavaScript, processos mais elaborados podem ser
realizados. O desenvolvedor pode escolher qual processo prefere adotar ou criar o
seu prprio em um arquivo de configuraes, mas para este projeto foi utilizada a
opo padro.

5.4 Terceiro Sprint

Para o terceiro sprint, foram escolhidas as tarefas de CRUD. Depois que o
primeiro CRUD feito, os demais so praticamente iguais, facilitando assim o
trabalho e permitindo a rpida execuo das tarefas. Para no deixar esta seo
repetitiva, ser demonstrada apenas a criao completa do CRUD de Apartamentos,
levando em considerao que a classe Quarto j est implementada, para que seja
possvel mostrar como os relacionamentos entre modelos funcionam no Rails.
Primeiro, fazemos como foi feito com a classe User:
$

rails

model

Apartament

neighborhood:string

street:string

number:string apartment:string dimensions:string bathrooms_quantity:integer

living_rooms_quantity:integer

service_areas_quantity:integer

user:references

Nada novo por aqui, com exceo do ltimo atributo. O parmetro references
serve para informar que o modelo gerado ter uma associao belongs_to com o
atributo informado, ou seja, gerar um user_id e o modelo ser criado com a
seguinte linha de cdigo j implementada:
$ belongs_to user

Isto significa que, em qualquer lugar do sistema, caso se tenha um objeto de

algum apartamento instanciado, pode-se utilizar
$ objeto.user

34

e obter assim o usurio associado. Considerando o que temos em mente para o

modelo de apartamentos, vejamos como ficou nosso modelo:
class Apartment < ActiveRecord::Base
belongs_to :user
has_many :rooms, :dependent => :restrict
validates_presence_of
:neighborhood,
:bathrooms_quantity,
:living_rooms_quantity,
:city_id

:street,
:number,
:service_areas_quantity,

def full_address
if number.present? && apartment.present?
neighborhood + ", " + street + " " + number + ", Apt " +
apartment
else
public_address
end
end
def public_address
neighborhood + ", " + street
end
def default_code
number + apartment
end
end

O belongs_to representa um relacionamento 1:1, enquanto o has_many um

1:N. Desta forma, levando em conta que temos um objeto de Apartment instanciado,
conseguimos a coleo de quartos de um apartamento atravs de:
$ objeto.rooms

Na classe Room, teremos um belongs_to tambm. Qualquer associao onde

uma classe possui a chave estrangeira de outra, entendido que esta pertence
outra, desta forma possuindo o belongs_to. No caso, has_many e has_one so
usados pelos donos das outras classes, sendo que no primeiro se obtm os
objetos associados atravs do nome da classe no plural e o segundo no singular.

35

Isto feito, temos nosso modelo pronto, com alguns mtodos que julgamos
interessantes para exibir os endereos completos e pblicos, alm de um cdigo que
adotamos como padro para todo apartamento do sistema. Percebe-se que pode
somar strings em Ruby, como fica evidenciado na implementao destes mtodos.
Agora, para podermos criar, editar, remover ou visualizar um apartamento,
precisaremos de um controller com todas estas aes implementadas. Para cri-lo,
basta executar o seguinte comando:
$ rails g controller apartaments

Segue como ficou nosso controller de Apartaments, por ao com as

explicaes em seguida:
def index
@apartments = current_user.apartments.order(:id)
end

A varivel apartments est precedida por um @ para que ela possa ser
acessada dentro da View correspondente desta ao. O mtodo current_user ser
explicado posteriormente, quando a gem devise for explicada. Toda coleo e todo
array tem o mtodo order implementado, onde se passa como parmetro o campo
pelo qual a coleo ser ordenada.
def show
@apartment = Apartment.find(params[:id])
end

Por padro, a varivel params dentro de todo controller um hash com os

parmetros passados para a ao onde se encontra. No caso, foi passado como
parmetro o id do apartamento em questo, possibilitando assim encontr-lo da
forma mais rpida possvel. No Rails, todo id indexado.
def new
@apartment = Apartment.new
end

36

Na ao new, um novo apartamento instanciado a partir do mtodo .new.

possvel criar construtores para as classes, que so chamados quando o .new
invocado, mas para a classe Apartment no foi necessrio implementar um.
def create
@apartment = Apartment.new(apartment_params)
@apartment.user_id = current_user.id
if @apartment.save
redirect_to apartments_url, :notice => "O apartamento foi
criado com sucesso."
else
render :new
end
end

Na ao create, h algumas coisas interessantes para mostrar. O mtodo

new novamente chamado, desta vez com uma varivel passada como parmetro.
Esta varivel, como ser evidenciado mais tarde, um hash de valores. O mtodo
new aceita um hash para instanciar os objetos, lanando uma exceo caso exista
alguma chave que no corresponda nenhum atributo da classe. Temos um if no
momento que o apartamento salvo pois, caso apresente algum erro (como por
exemplo o campo street vazio, uma vez que no apartamento est sendo validada a
presena deste), renderizada a ao edit sem fazer uma nova requisio ao
servidor, desta forma mantendo os dados que foram preenchidos e exibindo as
mensagens de erro.
Caso seja salvo, o redirect_to redireciona para a index de apartaments, com a
mensagem contida no notice.
def edit
@apartment = Apartment.find(params[:id])
end

Nada novo a acrescentar nesta ao.

def update
@apartment = Apartment.find(params[:id])
if @apartment.update_attributes(apartment_params)
redirect_to apartments_url, :notice => "O apartamento foi
atualizado com sucesso."
37

else
render :edit
end
end

Muito semelhante ao mtodo create, as nicas diferenas do update so o

mtodo update_attributes que faz exatamente o que o mtodo sugere: atualiza os
atributos de acordo com um hash de parmetros; a outra que renderizada a ao
edit e no a new.
def destroy
@apartment = Apartment.find(params[:id])
if @apartment.destroy
redirect_to apartments_url, :notice => "O apartamento foi
removido com sucesso."
else
redirect_to apartments_url, :alert => "O apartamento no
foi deletado; verifique se ele possui quartos."
end
end

Na ao destroy, achamos relevante apenas acrescentar que o mtodo

destroy chama os callbacks do Rails, enquanto o delete executa no banco de dados
um comando DELETE, assim ignorando qualquer callback da aplicao.
private
def apartment_params
params.require(:apartment).permit(:neighborhood,
:street,
:number,
:apartment,
:bathrooms_quantity,
:living_rooms_quantity,
:service_areas_quantity, :dimensions
end

No final de nosso controller, temos uma ao seguida de um private, ou seja,

uma ao privada que s pode ser acessada dentro do prprio controller. Este
mtodo, o apartment_params, um padro do Rails 4 para evitar uma injeo de
SQL na hora de criar ou editar um registro. Este cdigo significa que, para um
apartment, s so permitidos os parmetros passados dentro do permit.
Agora que temos nosso modelo e nossas aes do controller implementadas,
faltam apenas as telas e uma forma de avisar ao Rails que estas aes so
acessveis.

As

views

ficaro

em
38

app>views>apartaments>nome_do_arquivo.html.erb , ou seja, um arquivo HTML que

interpreta cdigo do Ruby on Ruby. As views precisam ter o mesmo nome das
aes, ou seja, index.html.erb, news.html.erb e edit.html.erb. Para executar o cdigo
exibindo o resultado, basta colocar o cdigo dentro de uma tag <%= %>; para
executar mas sem exibir o resultado, <% %>.
Para habilitar as rotas, basta ir at o arquivo routes.rb e adicionar a seguinte
linha de cdigo:
$ resources :apartaments

Ns poderamos dizer que s queremos que o index de apartments esteja

disponvel, que no o nosso caso, mas para isso bastaria colocar:
$ resources :apartments, :only => [:index]

Da mesma forma, poderamos dizer que queremos todas as aes, com

exceo da index. Para isso:
$ resources :apartments, :except => [:index]

5.5 Quarto Sprint

Neste sprint, sero detalhadas as duas funcionalidades que exigiram uma
maior ateno por parte dos desenvolvedores. A primeira delas o envio de e-mail.
Ns poderamos gerar o mailer atravs de um comando, mas muitos arquivos que
no sero utilizados seriam gerados por padro, ento foi decidido criar o arquivo
manualmente em app>mailers. Como o envio de e-mail neste projeto est associado
ao preenchimento de formulrios, criamos o form_mailer.rb.
A seguir estaro partes do arquivo, explicando como os mailers funcionam no
Rails.
default from: "usuario@dominio.com"

39

Esta linha significa que, por padro, em todos os e-mails aparecer que o
remetente o e-mail usuario@dominio.com.
def registry(formulario)
@formulario = formulario
mail(to: "outro.usuario@dominio.com", subject: 'Registry Form')
end

Os mailers funcionam de maneira semelhante aos controllers, onde cada

mtodo na realidade uma ao. A diferena que estas no precisam ser
declaradas no arquivo de rotas. Neste caso, a ao registry do mailer FormMailer
enviar um e-mail ao some.email@gmail.com com o assunto Registry Form. O corpo
do e-mail dever estar em app>views>form_mailer>registry.html.erb .
Para configurar o e-mail do qual sero enviadas as mensagens, basta entrar
no arquivo production.rb e adicionar o seguinte bloco de cdigo:
config.action_mailer.smtp_settings = {
address: 'smtp.dominio.com',
port: 25,
domain: 'domnio',
user_name: 'usuario@dominio.com',
password: 'my_password',
authentication: 'plain',
enable_starttls_auto: true }

Desta forma, o envio de e-mails est configurado. Para enviar um e-mail

atravs da ao registry, basta executar o seguinte comando:
FormMailer.registry(@formulario).deliver

Assim, dentro da view, o objeto @formulario estar acessvel para ser

utilizado para compor o corpo do e-mail.

40

A outra funcionalidade escolhida para ser evidenciada nesta seo a do

filtro de quartos por cidade, ms e ano. Segue a funo implementada na classe
Room:
def self.search(month, year, city_id)
last_date_of_month = Date.new(year, month+1, 1) - 1.day unless month
== 12
last_date_of_month ||= Date.new(year, 12, 31)
first_date_of_month = Date.new(year, month, 1)
joins(:apartment).where("availability_date <= ? and availability_date
>= ? and apartments.city_id = ?", last_date_of_month, first_date_of_month,
city_id)
end

A primeira coisa importante de se mostrar que o mtodo comea com self.,

ou seja, um mtodo de classe e no de objeto. Desta forma, para execut-lo, ser
sempre necessrio fazer Room.search(parametros). A segunda o unless, que
funciona justamente como um if invertido; possvel usar if e unless na prpria linha.
E por conta disso a segunda linha, ao invs de receber com = , recebe como ||=, ou
seja, s recebe o valor a seguir caso a varivel esteja vazia.
O joins(:apartment) faz um join com a classe Apartment atravs da chave
estrangeira especificada na prpria classe Room (belongs_to :apartment). Esse joins
est solto pois, uma vez dentro de um mtodo de classe, considera-se que um
mtodo destes est sendo executado dentro da classe; ou seja, self.where teria o
mesmo resultado. Dentro do where, colocamos uma string SQL normal, cuja nica
parte diferente so os pontos de interrogao, que ficam reservados para serem
substitudos pelas variveis a seguir da string.

5.6 Quinto Sprint

Para o ltimo sprint do projeto, sero detalhadas trs funcionalidades: a
conexo com o S3 da Amazon para hospedar as imagens, a implementao do
Devise que trata de autenticao e sign-up de usurios e, por ltimo, a
implementao do CanCan, que trata das permisses de usurio.

41

Diversas gems podem auxiliar na conexo com a S3 da Amazon, mas para o

projeto foi adotada a gem carrierwave. Aps adicion-la no Gemfile e executar o
comando para instal-la, devemos executar o seguinte comando:
$ rails g uploader Photo

Assim, um arquivo gerado em app>uploaders. No nosso caso, foi o

photo_uploader.rb. O arquivo j vem com muita coisa preenchida, e basta comentar
a linha de cdigo que aponta que as fotos sero armazenadas em arquivo e
descomentar a que afirma que eles sero armazenadas em fog.
Feito isto, basta ir em config>initializers e criar o arquivo carrierwave.rb.
Nele, colocar as credenciais da Amazon, da seguinte forma:
CarrierWave.configure do |config|
config.fog_credentials = {
:provider => 'AWS',
:aws_access_key_id => AWS_ACCESS_KEY_ID,
:aws_secret_access_key => 'AWS_SECRET_ACCESS_KEY'
}
config.fog_directory = 'my_bucket'
end

Assim, quase todo trabalho est feito. Agora basta rodar uma migrao para o
modelo que ter uma foto, desta maneira:
rails g migration add_avatar_to_rooms photo:string

Assim o atributo photo guardar todas informaes necessrias para ligar o

arquivo que estar hospedado no S3 da Amazon com a informao contida no
banco de dados. Feito isto, adicionar a seguinte linha no modelo Room:
mount_uploader :photo, PhotoUploader

E toda a infraestrutura para armazenar arquivos no S3 da Amazon para os quartos

do sistema est pronta.

42

A gem CanCan uma biblioteca de autorizao para Ruby on Rails, que restringe os
recursos e permisses que um determinado usurio possui [Ryan, 2010]
extremamente til e fcil de ser manipulada, reunindo todas as permisses de
usurio em um nico arquivo. Para ger-lo, basta executar o seguinte comando:
$ rails g cancan:ability

possvel criar diversos perfis de usurio, mas como nosso projeto no necessita de
tanto,

abaixo

est

demonstrado

como

ficou

arquivo

gerado

em

app>models>ability.rb:

class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new # guest user (not logged in)
if user.admin?
can :manage, :all
end
end
end

Isto significa que, se o usurio admin, ele tem permisso completa sobre os
seus apartamentos e quartos; nenhum usurio poder visualizar, editar ou excluir
apartamentos e quartos que no sejam seus, ou seja, que no estejam com seu
user_id.
Alm disso, para esconder um boto ou parte do sistema de acordo com a
permisso, basta adicionar o seguinte bloco de cdigo dentro de uma view:
<% if can? :update, @aparment %>
<%= link_to "Edit", edit_apartment_path(@apartment) %>
<% end %>

43

Dependendo da ao, basta trocar o :update por :create, :read ou :delete.

Nada disto funcionar a no ser que seja adicionado, dentro de cada controller, a
seguinte linha de cdigo:
load_and_authorize_resource

Desta forma, o CanCan estar habilitado para cada controller que possuir
este cdigo. Como nem todas as pginas do sistema precisam necessitam de
autorizao, este cdigo foi adicionado apenas nos lugares relevantes.
A gem Devise uma soluo de autenticao flexvel para Rails [Neighman,
2009] extremamente verstil, mas apenas uma pequena parcela de seu potencial
foi utilizado no projeto, dado sua baixa complexidade. Depois de adicionada ao
Gemfile e instalada, o primeiro passo executar o seguinte comando:
$ rails generate devise:install

Seria possvel gerar o modelo User com todas as funcionalidades do Devise,

mas como ele j foi criado no primeiro Sprint, ser preciso rodar uma migrao
especfica para adicionar os campos necessrios. Seja qual for o nome da migrao,
ela precisar ter o seguinte contedo:
class NomeDaMinhaMigracao < ActiveRecord::Migration
def change
change_table :users do |t|
t.encrypted_password
t.confirmable
t.recoverable
t.rememberable
t.trackable
t.token_authenticatable
t.timestamps
end
end
end

Dentro da classe User, adicionar a seguinte linha:

44

devise

:database_authenticatable,

:recoverable,

:rememberable,

:trackable, :validatable, :registerable

Estes so mdulos que o Devise oferece, mas no so todos; para melhor

entendimento, visitar a documentao oficial da gem no Github. Agora temos
implementado pelo devise o mtodo current_user, que foi exibido anteriormente. Ele
verifica se existe algum usurio logado no atual browser e, caso exista, retorna o
prprio com este mtodo.
Para fazer uso das views padronizadas do Devise, basta executar o seguinte
comando no terminal:
$ rails generate devise:views

De acordo com a complexidade e o tamanho desta biblioteca, um captulo

inteiro poderia ser dedicado a ela, mas, como foi dito anteriormente, ns utilizamos
uma pequena parcela de seu potencial. Para resumir do que ela capaz, e como ela
agiliza o desenvolvimento de um projeto, ser exibido como um usurio se cadastra
no sistema e como as rotas do devise so permitidas.
No arquivo de rotas, basta acrescentar:
devise_for :users

Assim, todas as rotas de todos os mdulos explicitados na classe de usurios

fica habilitada. Segue o cdigo que est no application.html.erb, mostrando como
fcil tratar de sign-up, sign-in e sign-out de usurios:
<% if current_user.present? %>
<%= link_to "Mude sua senha", edit_user_registration_path %></li>
<%= link_to "Sair", destroy_user_session_path %></li>
<% else %>
<%= link_to "Registre-se", new_user_registration_path %></li>
<%= link_to "Entrar", new_user_session_path %></li>
<% end %>

45

Todas estas rotas e telas j vm feitas pelo devise, podendo ser

customizadas em app>views>devise da forma que a equipe achar melhor.
A seguir, mostrado o resultado final do desenvolvimento com as principais
telas do sistema Imobiliria Web.

Figura 7 - Tela Principal

A imagem abaixo mostra o formulrio de cadastro de quartos que deve ser

cadastrado pelo usurio referente ao seu imvel.

Figura 8 - Cadastro de Quartos

Na prxima tela, o usurio do sistema Imobiliria Web poder efetuar o

cadastro de reserva de quartos caso ele deseje ser notificado quando uma vaga
estiver disponvel.

46

Figura 9 - Formulrio de Reserva

Estas so as funcionalidades mais complexas existentes no sistema

Imobiliria Web, desenvolvidas ao longo dos cinco meses e divididos em cinco
sprints.
O uso do framework Ruby on Rails apresenta inmeras vantagens que foram
observadas ao longo do desenvolvimento deste projeto sendo elas:

Abstrao de conhecimentos de query SQL para construo do banco

de dados devido ao Active Record que uma camada de mapeamento
objeto-relacional.

uma linguagem de rpido desenvolvimento, j que o framework

utiliza dois conceitos que visam aumentar a produtividade: o DRY e
Convention over Configuration, conceitos que buscam a reduo de
repetio de cdigo e tempo de desenvolvimento, fazendo com que o
desenvolvedor d preferncia a utilizao de componentes j
existentes, amplamente usados e testados pela comunidade.

uma

linguagem

de

cdigo

aberto

possibilitando

que

um

desenvolvedor seja capaz de alterar funcionalidades de acordo com a

sua necessidade.

Possui

forte

adeso

da

comunidade

com

usurios

ativos

participativos.
47

Tambm foram observados pontos negativos sobre o framework elas so

descritas abaixo:

Configurao de um ambiente de desenvolvimento complicado j que

existem inmeras verses do framework e caso um projeto seja
migrado de uma verso para outra erros podero ocorrer no projeto.

Difcil de se programar no MS Windows pois a instalao do framework

nesta plataforma complexa e com inmeros bugs relatados.

Plataformas de hospedagem de projetos em Ruby on Rails so mais

caras que as plataformas usadas para outras linguagens.

Fica claro que o desenvolvimento de pequenas aplicaes em Ruby on Rails,

com o auxlio das gems certas, simples e rpido, abstraindo toda complexidade de
montar um banco de dados e pensar em uma modelagem, graas s migraes, que
foram feitas diversas vezes ao longo do projeto.

48

6 CONCLUSO
Neste projeto, possvel observar todos os passos necessrios para a
construo de um sistema de informao que utiliza tcnicas mais recentes do
mercado de trabalho, tais como o uso de metodologias geis e linguagem de
programao utilizando o framework Ruby on Rails. No desenvolvimento do projeto,
foi possvel observar inmeras vantagens para a implementao em curtos perodos
de tempo e poucos recursos humanos.
O desenvolvimento do sistema envolveu desde o levantamento de requisitos
e modelagem de casos de uso e de classes at a implementao usando o
framework Ruby on Rails. A conjugao do uso deste framework com as prticas do
Scrum resultou em um desenvolvimento rpido e eficaz do sistema, que pode ser
replicado em outras aplicaes.
Este trabalho poder servir de guia para aqueles que desejam conhecer uma
pouco do framework Ruby on Rails e aprender o uso das principais gems, o uso do
sistema Heroku para deploy de sistemas de maneira prtica, a customizao do
front-end com auxlio do Twitter Bootstrap e o uso do Devise, uma ferramenta
verstil para autenticao.
No futuro, o projeto Imobiliria Web ir buscar uma popularizao em seu uso
no intuito de obter investimentos em patrocnios ou de venda de informaes para
grandes empresas imobilirias que buscam aprimorar sua base de inteligncia sobre
o perfil de usurios que estejam apenas querendo alugar um quarto em imvel.
O sistema Imobiliria Web estar no ar at o final de 2015, aproveitando a
realizao das Olimpadas do Rio de Janeiro. Uma possvel continuao deste
projeto seria a implementao de todos os testes unitrios e os testes de integrao,
que no foram previstos no escopo do sistema.

49

BIBLIOGRAFIA
Beck, Kent (2001) Manifesto gil, http://www.manifestoagil.com.br/, Janeiro
2015.
Globo (2015) FIPE-ZAP:NDICE http://www.zap.com.br/imoveis/fipe-zap-b,
Maio 2015.
Hansson, H. David (2003),Ruby on Rails, http://rubyonrails.org, Fevereiro
2015.
Henry, Orion. (2007),Heroko, https://www.heroku.com , Junho 2015.
Matsumoto, Yukihiro . (2002). Ruby In A Nutshell, Edition: 1st.
Neighman,

Daniel

(2009)

Gem

Divise,

https://github.com/plataformatec/devise, Junho 2015.

Schwaber, K. & Sutherland, J. (2013). Guia do Scrum - Um guia definitivo para
o
Scrum:
As
regras
do
jogo.
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf, Junho
2015.
Thoughtbot. (2009) HighVoltage, https://github.com/thoughtbot/high_voltage,
Janeiro 2015.
Twitter. (2010), Bootstrap, http://getbootstrap.com, Maio 2015.
Smaldone, Javier (2008) RailRoady, https://github.com/preston/railroady,
junho 2015.

50