TCC - Automatização de Entrega de Software em Ambiente Ágil de Desenvolvimento

FUNDAO DE ASSISTNCIA E EDUCAO FAESA
FACULDADES INTEGRADAS ESPRITO-SANTENSE

CURSO DE GRADUAO EM CINCIA DA COMPUTAO
LEANDRO SOUZA NUNES
AUTOMATIZAO DE ENTREGA DE SOFTWARE EM

AMBIENTE GIL DE DESENVOLVIMENTO
VITRIA
2014
LEANDRO SOUZA NUNES

Trabalho de Concluso de Curso de

Graduao em Cincia da Computao
apresentado s Faculdades Integradas
Esprito-santenses, como requisito parcial
para obteno do ttulo de Bacharel em
Cincia da Computao, sob orientao da
profa. Denise Franzotti Togneri.
VITRIA
2014
LEANDRO SOUZA NUNES
Trabalho de Concluso do Curso de Graduao em Cincias da Computao

apresentado s Faculdades Integradas Esprito-santenses (FAESA), como requisito
parcial para obteno do ttulo de Bacharel em Cincia da Computao.

BANCA EXAMINADORA
Denise Franzotti Togneri

Orientadora
Eliana Cus Sampaio
Daniel Barbosa Oliveira
Vitria, 10 de dezembro de 2014
RESUMO
Software, por mais complexo que seja, no gera lucro ou valor at que esteja nas
mos de seus usurios. Para inibir riscos com perda de oportunidades no universo
web, a empresa objeto do estudo de caso deste trabalho evita os longos ciclos de
desenvolvimento tradicionais adotando as metodologias geis, fazendo uso das
prticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de
desenvolvimento, a execuo manual de tarefas importantes do processo de
desenvolvimento associa-se diretamente com o no cumprimento de prazos e a
baixa qualidade do software entregue. Diante desse cenrio, este trabalho realiza
uma pesquisa das boas prticas de desenvolvimento de software para efetuar a
entrega contnua de valor ao cliente e prope o desenvolvimento de um sistema
para realizar a automatizao dos processos com o auxlio de ferramentas testadas
e validadas h dcadas pela comunidade open source tais como Puppet, Git, Mina,
Jenkins, RSpec e Cucumber. O processo de entrega descrito atravs do padro
Pipeline de Implantao, permitindo a automatizao desde o desenvolvimento at a
entrega do software ao usurio final. O sistema desenvolvido tem o objetivo de
permitir que a equipe de desenvolvimento responda s mudanas de forma eficiente,
aumente a capacidade de gerar novas verses bem-sucedidas e de liber-las sob
demanda e de implantar o seu sistema em qualquer ambiente instantaneamente,
refletindo as mudanas de uma forma eficiente e com baixo custo.
Palavras-chave: Entrega Contnua de Software. Provisionamento de ambientes.
Integrao Contnua. Metodologias geis. Pipeline de Implantao.
LISTA DE QUADROS

QUADRO 1 REQUISITOS NO FUNCIONAIS. ................................................................... 55

QUADRO 2 FERRAMENTAS UTILIZADAS. ....................................................................... 60
QUADRO 3 COMPARATIVO OVENBIRD X GO X TOOL CLOUD X TRELLO. ........................ 64
QUADRO 4 DICIONRIO DE DADOS DO SISTEMA OVENBIRD............................................ 67
QUADRO 5 DICIONRIO DE DADOS DO SISTEMA OVENBIRD............................................ 68
LISTA DE FIGURAS
FIGURA 1 AGRUPAMENTO DAS PRTICAS DA XP. ......................................................... 20
FIGURA 2 FLUXO DE PROCESSO UTILIZANDO SCRUM. ................................................... 22
FIGURA 3 EXEMPLO DE UM GRFICO BURNDOWN CHAT. ............................................... 24
FIGURA 4 EXEMPLO DE UM QUADRO KANBAN............................................................... 25
FIGURA 5 EXEMPLO DE UM QUADRO KANBAN EM DESENVOLVIMENTO DE SOFTWARE....... 26
FIGURA 6 DIAGRAMA DE UM SISTEMA DE VERSO LOCAL............................................... 27
FIGURA 7 DIAGRAMA DE UM SISTEMA DE VERSO CENTRALIZADO. ................................. 28
FIGURA 8 DIAGRAMA DE UM SISTEMA DE VERSO DISTRIBUDO...................................... 29
FIGURA 9 QUATRO QUADRANTE DE TESTES DESCRITOS POR BRIAN MARICK. ................. 32
FIGURA 10 CICLO DO TDD ......................................................................................... 34
FIGURA 11 PROCESSO DE INTEGRAO CONTNUA COM O AUXILIO DE FERRAMENTAS. .... 35
FIGURA 12 - UM EXEMPLO DE MAPA DE FLUXO DE VALOR SIMPLES PARA UM PRODUTO ....... 37
FIGURA 13 - MUDANAS SE MOVENDO POR UM PIPELINE DE IMPLANTAO. ...................... 38
FIGURA 14 EQUIPES ENVOLVIDAS NO MOVIMENTO DEVOPS. ......................................... 41
FIGURA 15 - MAPA DO FLUXO DE VALOR DA EMPRESA OBJETO DESTE ESTUDO. ................. 44
FIGURA 16 MOVIMENTAO ATUAL DAS SOLICITAES NO QUADRO KANBAN. ................ 45
FIGURA 17 - FLUXO DO GERENCIAMENTO DO SISTEMA PELOS DESENVOLVEDORES. ........... 46
FIGURA 18 - DIAGRAMA DE CASO DE USO PRINCIPAL. .................................................... 50
FIGURA 19 - DIAGRAMA DE CASO DE USO CADASTRARGERAL. ........................................ 51
FIGURA 20 - DIAGRAMA DE CASO DE USO GERENCIARAMBIENTES................................... 52
FIGURA 21 - DIAGRAMA DE CASO DE USO GERENCIARSOLICITACOES. .............................. 53
FIGURA 22 - UTILIZAO DO PUPPET PELO SISTEMA OVENBIRD. ...................................... 57
FIGURA 23 - QUADRO KANBAN NO SISTEMA OVENBIRD. .................................................. 59
FIGURA 24 - FLUXO DO GERENCIAMENTO DO SISTEMA PELOS DESENVOLVEDORES APS A
APLICAO DAS SOLUES PROPOSTAS.
................................................................ 61
FIGURA 25 TELA DO PIPELINE DE IMPLANTAO NA FERRAMENTA GO. ........................... 62

FIGURA 26 PAINEL DE INSTALAO DA TOOLS CLOUD. ................................................. 63
FIGURA 27 QUADRO DO TRELLO. ................................................................................ 64
FIGURA 28 DIAGRAMA DE CLASSES DE ANLISE PARTE ESTTICA - DO SISTEMA
OVENBIRD. ........................................................................................................... 66
FIGURA 29 DIAGRAMA DE SEQUNCIA INCLUIRNOVOAMBIENTE. .................................... 69
FIGURA 30 DIAGRAMA DE SEQUNCIA CADASTRARPROJETO. ........................................ 69
FIGURA 31 DIAGRAMA DE SEQUNCIA INCLUIRSOLICITACAO. ........................................ 70

FIGURA 32 DIAGRAMA DE SEQUNCIA GERARNOVAIMPLANTAO. ................................ 70
FIGURA 33 DIAGRAMA DE ESTADO DE CLASSE FUNCIONALIDADE. .................................. 71
FIGURA 34 ARQUITETURA DE QUATRO CAMADAS DO SISTEMA OVENBIRD. ...................... 72
FIGURA 35 PROJETO DA ARQUITETURA WEB. .............................................................. 74
FIGURA 36 PROJETO DE NAVEGAO DO ATOR GERENTEPROJETOS. ............................ 75
FIGURA 37 PROJETO DE NAVEGAO DO ATOR DESENVOLVEDOR. ................................ 75
FIGURA 38 PROJETO DE NAVEGAO DO ATOR QUALIDADE. ......................................... 75
FIGURA 39 COMPONENTE DO DOMNIO DO PROBLEMA. ................................................ 77
FIGURA 40 COMPONENTE DE GERNCIA DE TAREFA. ................................................... 79
FIGURA 41 DIAGRAMA RELACIONAL DE DADOS. ............................................................ 81
FIGURA 42 TELA PARA VISUALIZAO DOS USURIOS CADASTRADOS. ........................... 88
FIGURA 43 TELA PARA CADASTRO DE USURIOS. ......................................................... 89
FIGURA 44 TELA PARA VISUALIZAO DOS CLIENTES CADASTRADOS. ............................ 89
FIGURA 45 TELA PARA CADASTRO DE CLIENTE. ............................................................ 90
FIGURA 46 TELA PARA CADASTRO DE ESPECIALISTA..................................................... 90
FIGURA 47 TELA PARA CADASTRO DE PROJETO. .......................................................... 91
FIGURA 48 TELA PARA CADASTRO DE AMBIENTE. ......................................................... 92
FIGURA 49 TELA PARA CADASTRO DE AMBIENTE. ......................................................... 92
FIGURA 50 TELA DO PIPELINE DE IMPLANTAO. .......................................................... 93
FIGURA 52 TELA PARA CADASTRO DE SOLICITAO. ..................................................... 94
LISTA DE SIGLAS
CSS Cascading Style Sheets
CI Continuous Integration
CVS Concurrent Versions System
DSL Domain-Specific Language
ERB Embedded Ruby
SSH Secure Shell
UML Unified Modeling Language
HTML Hyper Text Markup Language
HTTPS Hypertext Transfer Protocol Secure
RCS Revision Control System
SCCS Source Code Control System
SGBD Sistema de Gerenciamento de Banco de Dados
SIC Sistema de integrao Contnua
SQL Structured Query Language
TDD Test Driven Development
URL Uniform Resource Locator
VCS Version Control System
XP Extreme Programming
WEB Wolrd Wide Web
SUMRIO
1. INTRODUO ...................................................................................................... 11
1.1 O PROBLEMA ................................................................................................. 12
1.2 FORMULAO DO PROBLEMA ................................................................... 13
1.3 HIPTESE ....................................................................................................... 13
1.4 OBJETIVOS..................................................................................................... 13
1.4.1 Gerais ........................................................................................................ 13
1.4.2 Especficos ................................................................................................ 14
1.5 JUSTIFICATIVA .............................................................................................. 14
1.6 METODOLOGIA .............................................................................................. 15
1.7 ORGANIZAO DA MONOGRAFIA .............................................................. 15
2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE GIL ................... 16
2.1 MANIFESTO GIL .......................................................................................... 16
2.2 EXTREME PROGRAMMING........................................................................... 18
2.2.1 Prticas da XP ........................................................................................... 18
2.2.2 Adoo da XP............................................................................................ 20
2.3 SCRUM ............................................................................................................ 21
2.3.1 Papis e responsabilidades....................................................................... 23
2.3.2 Etapas da Sprint ........................................................................................ 23
2.3.3 Artefatos .................................................................................................... 24
2.4 KANBAN.......................................................................................................... 25
2.4.1 Kanban no desenvolvimento de software.................................................. 25
2.5 SISTEMA DE CONTROLE DE VERSO ....................................................... 26
2.5.1 Sistemas de Controle de Verso Locais ................................................... 27
2.5.2 Sistemas de Controle de Verso Centralizados ........................................ 28
2.5.3 Sistemas de Controle de Verso Distribudos ........................................... 29
2.6 GERNCIA DE CONFIGURAO ................................................................. 30
2.6.1 Provisionamento ........................................................................................ 31
2.7 TESTES AUTOMATIZADOS........................................................................... 32
2.7.1 Desenvolvimento guiado por testes .......................................................... 34
2.8 INTEGRAO CONTNUA ............................................................................. 35
2.9 PIPELINE DE IMPLANTAO ....................................................................... 36
2.9.1 Como criar um pipeline de implantao inicial .......................................... 39
2.9.2 Objetivos para utilizao do pipeline ......................................................... 40

2.10 MOVIMENTO DevOps .................................................................................. 41
3. UMA PROPOSTA PARA AUTOMATIZAO DE ENTREGA DE SOFTWARE 43
3.1 ESTUDO DE CASO ......................................................................................... 43
3.1.1 Processos relacionados ao desenvolvimento ........................................... 45
3.1.2 Dificuldades encontradas no desenvolvimento ......................................... 47
3.2 REQUISITOS FUNCIONAIS............................................................................ 49
3.2.1 Caso de uso CadastrarGeral ..................................................................... 50
3.2.2 Caso de uso GerenciarAmbientes............................................................. 51
3.2.3 Caso de Uso GerenciarSolicitacoes .......................................................... 53
3.3 REQUISITOS NO FUNCIONAIS................................................................... 55
3.4 PROPOSTA DE SOLUO ............................................................................ 56
3.4.1 Proposta de soluo para a Gerncia de Ambientes ................................ 56
3.4.2 Proposta de soluo para a Gerncia de Solicitaes .............................. 58
3.5 TRABALHOS CORRELATOS ........................................................................ 61
3.5.1 Go Continuous Delivery............................................................................. 62
3.5.2 Tools Cloud ............................................................................................... 62
3.5.3 Trello.......................................................................................................... 63
3.5.4 Quadro Comparativo ................................................................................. 64
4. ANLISE ORIENTADA A OBJETOS ................................................................... 65
4.1 DIAGRAMA DE CLASSES ............................................................................. 65
4.2 DICIONRIO DE DADOS................................................................................ 67
4.3 DIAGRAMAS DE SEQNCIA....................................................................... 68
4.4 DIAGRAMA DE ESTADO ............................................................................... 70
5. PROJETO E IMPLEMENTAO ......................................................................... 72
5.1 PROJETO ........................................................................................................ 72
5.1.1 Projeto de arquitetura ................................................................................ 72
5.1.2 Projeto de interface ................................................................................... 73
5.1.2.1 Projeto de arquitetura da aplicao web............................................. 73
5.1.2.2 Projeto de navegao ......................................................................... 74
5.1.3 Projeto de componente ............................................................................. 76
5.1.3.1 Componente de Domnio do Problema (CDP).................................... 76
5.1.3.2 Componente de Interao Humana (CIH) .......................................... 78
5.1.3.3 Componente de Gerncia de Tarefa (CGT) ....................................... 78

5.1.3.4 Componente de Gerncia de Dados (CGD) ....................................... 80
5.1.4 Projeto relacional de dados ....................................................................... 80
5.2 IMPLEMENTAO DO PROTTIPO ............................................................. 81
5.2.1 Tecnologias utilizadas no prottipo ........................................................... 82
5.2.1.1 Ruby e RubyOnRails .......................................................................... 82
5.2.1.2 Cucumber ........................................................................................... 82
5.2.1.3 Git ....................................................................................................... 83
5.2.1.4 Jenkins ................................................................................................ 84
5.2.1.5 Mina .................................................................................................... 84
5.2.1.6 MySQL ................................................................................................ 84
5.2.1.7 Nginx ................................................................................................... 85
5.2.1.8 Puma................................................................................................... 85
5.2.1.9 Puppet................................................................................................. 85
5.2.1.10 RSpec ............................................................................................... 86
5.2.1.11 Vagrant ............................................................................................. 86
5.3 RESTRIES DE IMPLEMENTAO ........................................................... 87
5.4 INSTALAO E FUNCIONAMENTO DO PROTTIPO................................. 87
5.5 INTERFACE COM O USURIO ...................................................................... 88
6. CONCLUSO E PERSPECTIVAS FUTURAS ..................................................... 95
REFERNCIAS ......................................................................................................... 98
ANEXOS.................................................................................................................. 100
11
1. INTRODUO
Com a globalizao e o aumento ao acesso banda larga, o mundo vive uma
interao em tempo real. Ideias, tendncias, necessidades, informaes, dentre
outros, navegam de continente a continente em uma velocidade jamais imaginada,
tendo o software como parte fundamental desse processo. Desenvolver software
nesse cenrio requer um processo onde uma ideia na mente do cliente vire cdigo
funcional e esteja disponvel para o usurio final de maneira rpida e confivel. O
tempo para efetuar o processo de entrega de software pode determinar o rumo dos
negcios diante da concorrncia.
Desde 1980, autores como Kent Beck, Martin Fowler, Paul Duvall, Ron Jeffries e
Dave Thomas, estudam prticas de desenvolvimento de software com o objetivo de
poder fornecer ao mundo alternativas melhores que as tradicionais, que so
altamente dirigidas por documentao. Conforme os 12 princpios do Manifesto gil
(2001), o software em funcionamento tem maior valor do que uma documentao
abrangente e software funcional a medida primria do progresso. Software que
no esteja em produo, fazendo o que deveria fazer, no tem valor algum para o
negcio.
Humble e Farley (2014, p. 3) fazem trs perguntas que permitem ter um enfoque em
aspectos do ciclo de vida de um software que, segundo eles, normalmente so
vistos como secundrios: O que acontece depois da identificao dos requisitos,
projeto, desenvolvimento e teste das solues? Como unir e coordenar todas essas
atividades para tornar o processo to eficiente e confivel quanto possvel durante
sua execuo? Como fazer desenvolvedores, testadores e pessoal de operao
trabalharem juntos de maneira eficiente?
O objetivo da automatizao de processos tornar a entrega de software confivel,
previsvel, com riscos quantificveis e bem entendidos, garantindo que quando for
preciso fazer alguma modificao, o tempo para realiz-las, coloc-las em produo
e em uso, seja o menor possvel e, que problemas sejam encontrados cedo o
bastante para que sejam fceis de corrigir. Isso permite que todos os envolvidos
possam executar tarefas (que at ento so manuais) de forma eficiente e repetvel,
melhorando a produtividade e a quantidade das entregas de valor dentro de um ciclo
12
de desenvolvimento e permitindo implantar o sistema para qualquer ambiente

instantaneamente, refletindo as mudanas de uma forma eficiente e com baixo
custo.
1.1 O PROBLEMA
Uma empresa sediada em Vitria ES especializada em solues para lojas virtuais
(SLV) que so o ponto de partida para o atendimento de um novo cliente. Para inibir
riscos com perda de oportunidades no universo web, a empresa evita os longos
ciclos de desenvolvimento tradicionais adotando as metodologias geis, fazendo uso
das prticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de
desenvolvimento a execuo manual de tarefas importantes do processo de
desenvolvimento associa-se diretamente com o no cumprimento de prazos e a
baixa qualidade do software entregue.
A forma como os processos relacionados ao desenvolvimento de software so
executados pela equipe no permite o atendimento das solicitaes dos clientes de
maneira satisfatria. Diversos problemas ocorrem durante o desenvolvimento, tais
como: os desenvolvedores codificam as funcionalidades em seus ambientes de
desenvolvimento paralelamente, mas no h controle sobre as verses das
ferramentas utilizadas e os testes automatizados so executados vrias vezes ao
dia no prprio computador do desenvolvedor, deixando-o sem poder continuar
trabalhando em outras atividades por um perodo de 15 min a cada execuo.
No trmino do ciclo de desenvolvimento, o sistema ter uma verso disponibilizada
para o usurio final em outro ambiente. O processo de levar o cdigo do repositrio
at o usurio demorado e possibilita a presena de erros se cada passo no for
executado perfeitamente;
Implantar novos cdigos ao sistema da loja j em funcionamento extremamente
crtico e erros podem ser includos gerando perda financeira aos negcios. Em
muitos casos, preciso esperar a prxima madrugada para fazer a juno da
funcionalidade que j est pronta.
13
1.2 FORMULAO DO PROBLEMA

Como coordenar atividades relacionadas com a entrega de software, tais como a
integrao de cdigo, a criao de ambientes, a implantao do sistema e a
validao e verificao dos requisitos, para permitir que processos complexos sejam
executados de forma confivel e repetvel atravs da colaborao de todos os
envolvidos no processo de desenvolvimento?
1.3 HIPTESE
Para apoiar a soluo dos problemas levantados, uma proposta de soluo o
desenvolvimento de uma ferramenta que permita a utilizao de prticas de
desenvolvimento de software includas nas metodologias geis, objetivando otimizar
o processo de entrega de software de valor ao cliente e o desenvolvimento de
software coeso mais rapidamente. O sistema proposto baseia-se no padro Pipeline
de Implantao para automatizar o fluxo do desenvolvimento de software at a sua
entrega, realizando para isso, a integrao de ferramentas j existentes no mercado.
Dessa forma, as atividades de toda equipe de desenvolvimento seria centralizada,
dando uma viso do estado atual do sistema a todos os envolvidos e fomentando as
prticas do movimento DevOps 1 para criar um relacionamento colaborativo entre as
equipes de desenvolvimento, qualidade, operaes e o prprio cliente.
1.4 OBJETIVOS
1.4.1 Gerais
Construir um software capaz de integrar ferramentas, tcnicas e boas prticas que
possam ajudar a implementar um padro passvel de automatizao para o
desenvolvimento de sistemas web, melhorando com isso o feedback de modo que
os problemas sejam identificados e resolvidos o mais cedo possvel, proporcionando
a reduo do custo de desenvolvimento e fazendo com que a entrega do software
seja de maneira confivel e repetvel.
DevOps um movimento que busca difundir a colaborao entre os envolvidos no

desenvolvimento de software e ser abordado na seo 2.10.
14
1.4.2 Especficos
Investigar o fluxo de desenvolvimento de software para a elaborao de uma

pipeline de implantao;
Investigar a integrao de ferramentas para automatizar os processos de

entrega de software;
Possibilitar a comunicao entre cliente e equipe de desenvolvimento

continuamente;
Permitir a integrao contnua de cdigo de forma automatizada, reduzindo o

desperdcio de homem-hora;
Possibilitar a execuo do sistema durante o processo de desenvolvimento

em ambientes similares ao servidor de hospedagem;
Realizar o gerenciamento de configuraes e dependncias;
Desenvolver um sistema online para que todos os envolvidos possam efetuar

suas atividades de forma simples, rpida e confivel.
1.5 JUSTIFICATIVA
Software escrito que no entregue ao cliente no tem valor algum, mesmo que
seja uma aplicao das mais complexas que se pode codificar. A automao de
implantaes permite que novas entregas sejam feitas ou revertidas com o apertar
de um boto. Prticas tais como utilizar o mesmo processo de implantao em cada
ambiente e automatizar a gesto de ambientes, de dados e da infraestrutura so
projetadas para garantir que o processo de entrega seja excessivamente testado,
que a possibilidade de erro humano seja minimizada e que quaisquer problemas
(sejam funcionais, no funcionais ou de configurao) sejam descobertos muitos
antes de uma entrega (HUMBLE; FARLEY, 2014, p. 422).
Com o desenvolvimento de um software para a integrao de ferramentas,
automatizam-se os processos de forma que todos os envolvidos possam executar
tarefas (que at ento so manuais) com facilidade, aumentando a produtividade e a
quantidade de entregas de valor dentro de um ciclo, sendo possvel instalar o
sistema em qualquer ambiente instantaneamente, refletindo as mudanas para a
equipe de testes e o cliente de uma forma eficiente e com baixo custo.
15
1.6 METODOLOGIA
Inicialmente
ser
feita
uma
reviso
bibliogrfica
sobre
as
prticas
de
desenvolvimento inclusas nas metodologias geis, e do pipeline de implantao para

mapear os processos relacionados com a entrega de software. Em sequncia, um
estudo sobre as ferramentas de apoio ser realizado, efetuando a integrao entre
elas. Com isso, sero levantados os requisitos, documentando-os atravs de casos
de uso para modelar a ferramenta proposta. A anlise e o projeto sero feitos
utilizando-se o paradigma da orientao a objetos e seu prottipo ser construdo
utilizando-se a linguagem de programao Ruby.
1.7 ORGANIZAO DA MONOGRAFIA
Este trabalho contm, alm desta Introduo, mais 5 captulos.
O captulo 2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE GIL
apresenta
uma
viso
geral
das
metodologias
geis
das
prticas
de
desenvolvimento essenciais para o desenvolvimento deste trabalho.

O captulo 3 PROPOSTA PARA AUTOMATIZAO DE ENTREGA DE
SOFTWARE apresenta o estudo de caso e descreve os requisitos funcionais da
ferramenta a ser contruda atravs de casos de uso.
O captulo 4 ANLISE ORIENTADA A OBJETOS apresenta a anlise orientada
a objetos da ferramenta proposta.
O captulo 5 PROJETO E IMPLEMENTAO mostra como ser projetada e
implementada a ferramenta proposta.
O captulo 6 CONCLUSO PERSPECTIVAS FUTURAS onde so apresentadas
as concluses e perspectivas futuras do trabalho.
16
2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE GIL

Este captulo contextualiza o surgimento das metodologias geis utilizadas em
ambiente de desenvolvimento de software, abordando suas principais caractersticas
e princpios que proporcionaram sua adoo por diversas empresas nos ltimos
anos. Um conjunto de boas prticas de desenvolvimento testadas e validadas por
diversos autores so analisadas, com o objetivo de permitir efetuar a entrega de
software com maior qualidade em um curto perodo e promover a comunicao com
um ciclo de feedback constante entre todos os interessados.
2.1 MANIFESTO GIL
Em 2001, 17 pensadores de desenvolvimento de software, dentre eles: Martin
Fowler, Kent Beck, Kent Schwaber, Ron Jeffries e Dave Thomas, se reuniram para
que cada um explicasse como desenvolviam seus projetos de software, tendo como
objetivo, fornecer ao mundo uma alternativa s metodologias pesadas e altamente
dirigidas por documentao (LOPES, 2012, p. 16). Segundo Pressman (2006, p. 58),
em essncia, os mtodos geis foram desenvolvidos em um esforo para vencer as
fraquezas percebidas e reais da Engenharia de Software convencional.
Embora cada envolvido tivesse suas prprias prticas e teorias sobre como fazer um
projeto de software ter sucesso, cada qual com as suas particularidades, todos
concordavam que, em suas experincias prvias, um pequeno conjunto de
princpios sempre parecia ter sido respeitado quando os projetos davam certo.
Com base nesses princpios surgiu o Manifesto gil (2001). Ele valoriza a
importncia da interao entre os envolvidos e a entrega de software de valor ao
cliente a curto prazo. Os quatro valores defendidos pelo manifesto gil so:
Indivduos e interaes mais que processos e ferramentas;
Software em funcionamento mais que documentao abrangente;
Colaborao com o cliente mais que negociao de contratos;
Responder a mudanas mais que seguir um plano.
17
Os processos geis de desenvolvimento de software compartilham um conjunto de

premissas
fundamentais
que
diferem
daquelas
adotadas
pelos
processos
tradicionais de desenvolvimento.
Fowler (2005) descreve que a maioria dos projetos de software conta com trs
suposies chave que so justamente o que o processo gil de desenvolvimento
visa atender:
difcil prever antecipadamente quais requisitos de software vo persistir e

quais sero modificados e como as prioridades do cliente sero modificadas
durante o desenvolvimento do projeto.
Para muitos tipos de software, o projeto e a construo so intercalados, ou

seja, as duas atividades devem ser realizadas juntas de modo que os
modelos de projeto sejam comprovados medida que so criados. difcil
prever o quanto de projeto necessrio antes que a construo seja usada
para comprovar o projeto.
Anlise, projeto, construo e testes no so to previsveis (do ponto de

vista do planejamento) como gostaramos.
Pressman (2006, p. 61) levanta uma questo importante a partir das suposies:
como criar um processo que possa gerenciar a imprevisibilidade? A resposta, como
afirma Pressman, est na adaptabilidade do processo (as modificaes rpidas do
projeto e das condies tcnicas). Um processo gil, portando, deve ser adaptvel.
A
implementao
de
metodologias
geis
proporciona
desenvolvimento
cooperativo, que se baseia mais nas pessoas e suas iteraes em vez de grandes
esforos de planejamento e processo rgidos. Essas iteraes permitem a
visualizao contnua do desenvolvimento e o direcionamento do projeto para
atender seu propsito. Existem diversas metodologias geis de processo tais como
a Extreme Programming (XP), o Scrum e o Kanban que sero apresentadas a
seguir.
18
2.2 EXTREME PROGRAMMING

A XP foi uma das primeiras metodologias geis que revolucionou a forma como
software era desenvolvido (SATO, 2013, p. 116), diferenciando da forma tradicional
de desenvolvimento de software. Foi proposta por Kent Beck e publicada em seu
livro Extreme Programming Explained em 1999.
Kent Beck definiu os valores, princpios e prticas da metodologia, direcionando
seus objetivos para a alta qualidade no desenvolvimento de software, adaptando-os
a requisitos vagos ou em constante mudana. A XP engloba prticas de engenharia
gil alinhadas de tal forma a criar uma interdependncia entre elas, sendo
diretamente ligadas qualidade do software, tais prticas como: refatorao,
desenvolvimento guiado por testes, propriedade coletiva de cdigo, design
incremental, programao em pares, padres de cdigo e integrao contnua.
Segundo Teles (2006), a XP se baseia em cinco valores fundamentais para guiar o
desenvolvimento: Comunicao, simplicidade, feedback, coragem e respeito.
2.2.1 Prticas da XP
Prticas em XP representam aquilo que as equipes XP esto fazendo diariamente e
sua aplicao depende do contexto. Segundo Teles (2004, p. 28), as prticas XP
podem ser representadas da seguinte forma:
Jogo de Planejamento: nesta prtica existe uma grande interao entre o

cliente e a equipe, visando assegurar que se esteja trabalhando naquilo que
o mais importante para o cliente. Os programadores estimam o esforo
necessrio para implementar as histrias possibilitando conhecer o custo da
implementao e o cliente decide sobre o escopo e a durao das iteraes;
Releases Curtos: um incremento simples e funcional gerado rapidamente

de modo que o cliente j possa utilizar o software e se beneficiar dele. Desta
forma, possvel gerar um fluxo contnuo de valor, incorporar mudanas e
corrigir o produto em tempo hbil;
Metfora: elaborada uma descrio para permitir que todos os envolvidos

no projeto consigam explicar como o sistema funciona. Ela auxilia os
19
envolvidos a compreender os elementos bsicos do sistema e seus

relacionamentos, criando um vocabulrio comum para o projeto;
Projeto Simples: o sistema deve ser projetado da forma mais simples, de

modo a atender s necessidades da funcionalidade que se est
implementando;
Desenvolvimento Guiado por Testes: o desenvolvimento do software de

qualidade leva necessidade de ter diversos mecanismos de validao para
assegurar que esteja correto. A XP tambm utiliza a tcnica de
desenvolvimento guiado por testes (Test Driven Development ou TDD), sendo
descrita com mais detalhes na seo 2.7.
Refatorao: o ato de alterar um cdigo sem afetar a funcionalidade que

ele implementa. Isso permite a melhoria do sistema atravs da remoo de
duplicaes de cdigo, otimizao da comunicao, simplificao e
flexibilidade;
Programao em Par: dois programadores escrevem o cdigo em um nico

computador, permitindo uma reviso permanente, feedbacks e uma
implementao mais simples e eficaz;
Cdigo Coletivo: qualquer programador pode alterar qualquer parte do

cdigo em qualquer lugar do sistema a qualquer momento;
Integrao Contnua: uma nova funcionalidade pode afetar outras que j

estejam implementadas. Para garantir que o sistema esteja sempre
funcionando, a prtica de integrao contnua (Continuous Integration ou CI)
conduz os desenvolvedores a integrarem seus cdigos com o restante do
sistema diversas vezes ao dia. Essa prtica ser abordada na seo 2.8;
Cliente Presente: a XP trabalha com a premissa que o cliente deve conduzir

o desenvolvimento a partir do feedback que recebe do sistema. Um usurio
deve participar ativamente no processo de desenvolvimento junto equipe de
programadores. A sua presena viabiliza a simplicidade do processo em
diversos aspectos, especialmente na comunicao;
Cdigo Padronizado: os programadores escrevem todo o cdigo de acordo

com regras que enfatizam a comunicao durante a codificao. Antes do
incio do projeto deve ser definido um padro que dever ser seguido por toda
a equipe de programadores.
20
Ritmo Sustentvel: a qualidade do design, do cdigo, das metforas e do

sistema determinada pela qualidade dos desenvolvedores e a capacidade
que eles tm de se manter atentos, criativos e dispostos a solucionar
problemas. A XP recomenda que os desenvolvedores trabalhem oito horas
por dia, que estejam descansados a cada manha de modo a utilizar a mente
na sua plenitude.
A Figura 1 permite uma visualizao do agrupamento das prticas aplicadas com a

adoo da XP onde as prticas no crculo vermelho esto relacionadas com os
requisitos, no crculo verde, so prticas relacionadas com a qualidade do sistema
desenvolvido e no crculo azul, prtica relacionadas com o desenvolvimento, a
codificao do sistemas.
Figura 1 Agrupamento das prticas da XP.
Fonte: http://www.hiflex.com.br/v1/2014/07/scrum-sustenta-se-sozinho
2.2.2 Adoo da XP
Segundo Teles (2004, p. 21), a XP uma metodologia gil voltada para projetos
cujos requisitos so vagos e mudam com frequncia, desenvolvimento de sistemas
orientados a objetos, equipes pequenas, preferencialmente at 12 desenvolvedores
e desenvolvimento incremental (ou iterativo), onde o sistema comea a ser
21
implementado logo no incio do projeto e vai ganhando novas funcionalidades ao

longo do tempo.
Segundo Astels, Miller e Novak (2002, p. 181), a melhor maneira de adotar a XP
utiliz-la em organizaes recm-formadas, quando ainda no existe um modo prconcebido de desenvolvimento de software. So necessrios desenvolvedores
experientes, porque eles entendem como entregar projetos e podem ajudar os
novatos a entenderem esse importante princpio. Mas essa no a nica maneira:
algumas organizaes levam a XP para suas equipes que entra em operao de
forma transparente. Os desenvolvedores j podem estar utilizando as prticas da XP
no processo existente e eles simplesmente mudam sua forma de pensar sobre
desenvolvimento de software que suporte a XP.
A barreira cultural precisa ser vencida e os benefcios que a XP poder trazer
precisam ficar evidentes. Astels, Miller e Novak (2002, p. 182), descrevem que uma
outra maneira de adotar a XP experiment-la na sua forma bsica e ir descobrindo
maneiras de adapt-la e melhor-la para que os seus princpios possam
complementar o processo existente.
2.3 SCRUM
O Scrum teve sua definio em 1995 por Ken Schwaber, com o objetivo de
consolid-lo como um mtodo de desenvolvimento de software. No entanto, o termo
Scrum foi utilizado pela primeira vez para o desenvolvimento de software por Jeff
Sutherland em 1991.
Segundo Schwaber K. (2004), citado por Varaschim (2009, p. 2), o Scrum um
modelo aberto e de forma alguma previsvel. Ele oferece um conjunto de prticas
que tem como objetivo manter o gerenciamento do projeto visvel aos usurios do
modelo. A metodologia no detalha o que deve ser feito e no resolve os problemas
da empresa. O objetivo do Scrum dar visibilidade a estes problemas e servir como
guia na resoluo dos mesmos. De acordo com Pressman (2006, p. 69), a
metodologia Scrum utilizada para guiar as atividades de desenvolvimento dentro
de um processo que incorpora as atividades de requisitos, anlise, projeto, evoluo
e entrega. A Figura 2 ilustra o fluxo de processo utilizando Scrum.
22
Figura 2 Fluxo de processo utilizando Scrum.
Fonte: http://calvinx.com/2014/05/22/why-scrum-why-agile-development/
Varaschim (2009, p. 3) descreve o ciclo de desenvolvimento onde a primeira etapa

dentro da Sprint a reunio de planejamento (Sprint Planning). Nela, o time (Scrum
Team), em conjunto com o cliente (Product Owner), definem o que ser
implementado na iterao (Sprint Backlog), sendo responsabilidade do cliente
realizar a priorizao do trabalho a ser feito.
A prxima etapa a de execuo, onde o time detalha as tarefas necessrias para
implementar o que foi solicitado pelo cliente e posteriormente inicia a execuo das
mesmas. Durante a Sprint o time realiza reunies dirias (Daily Meeting) com no
mais de 15 minutos, para averiguar o acompanhamento do progresso do
desenvolvimento, usando para isto, o BurnDown Chart, um grfico usado para o
acompanhamento das tarefas a realizar, em andamento e j realizadas.
Ao final do Sprint realizada uma reunio para a validao da entrega (Sprint
Review), onde o cliente e quem mais tiver interesse no produto podem verificar se o
objetivo da Sprint foi atingido. Logo aps, realizada uma reunio apenas pelo time
(Sprint Retrospective), onde a Sprint avaliada sob a perspectiva de processo, time
ou produto. Relatam quais foram os acertos e os erros com o objetivo de melhorar o
processo de trabalho.
Ao invs de um grande grupo gastando um monte de tempo construindo uma grande
coisa, tem-se uma equipe pequena gastando um tempo curto construindo uma
pequena coisa, mas integrando regularmente para ver o todo (KNINGERG; SKARIN,
23
2009, p. 24). Empresas com projetos que possuem altas taxas de mudanas se
beneficiaro com as prticas do Scrum. A seguir sero descritos resumidamente os
papis, as etapas da Sprint e os artefatos que compem o Scrum.
2.3.1 Papis e responsabilidades
Os papis e responsabilidades associados ao Scrum so:
Scrum Master: atua como facilitador do Daily Meeting e torna-se responsvel

por remover quaisquer obstculos que sejam levantados pela equipe durante
essas reunies;
Scrum Team: a equipe de desenvolvimento. responsvel por atingir os

objetivos da Sprint, mostrando os resultados do trabalho para o cliente;
Product Owner: o cliente de um time Scrum, sendo responsvel pelo

retorno do investimento de um produto.
A responsabilidade pela qualidade do produto do time, que tem o dever de verificar

se suas prticas de desenvolvimento so compatveis com as necessidades de
qualidade e disponibilidade da aplicao.
2.3.2 Etapas da Sprint
Segundo Ken Schwaber citado por Varaschim (2009, p. 5), a Sprint definida como
um ciclo de desenvolvimento curto em que o time foca em atingir o objetivo proposto
pelo Product Owner e ao trmino, tem-se uma nova verso do sistema. Durante este
perodo o time realiza diversas atividades:
Sprint Planning: a primeira atividade dentro de uma Sprint; uma reunio

na qual esto presentes o Product Owner, o Scrum Master e todo o Scrum
Team, bem como qualquer pessoa interessada que esteja representando a
gerncia ou o cliente. Coletivamente, o Scrum Team e o Product Owner
definem um objetivo para a Sprint, que uma breve descrio daquilo que se
tentar alcanar. O Sprint Planning geralmente feito em um dia, mas de
acordo com o tamanho da Sprint, este tempo pode variar;
Daily Meeting: reunio diria realizada pela equipe a cada dia da Sprint, que
tem como objetivo disseminar conhecimento sobre o que foi feito no dia
24
anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia

que se inicia;
Sprint Review: realizada ao final de cada Sprint para que o Scrum Team
mostre o que foi alcanado e o Product Owner verifica se as condies
estabelecidas foram satisfeitas.
Sprint Restrospective: ocorre ao final de uma Sprint e tem como principal

foco o time. Serve para identificar o que funcionou bem, o que pode ser
melhorado e que aes sero tomadas para melhorar.
2.3.3 Artefatos
Os artefatos gerados pelo SCRUM so (VARASCHIM, 2009, p. 9):
Product Backlog: a lista que contem as funcionalidades de negcio, os

requisitos tcnicos e os erros encontrados no sistema que precisam ser
corrigidos;
Sprint Backlog: gerado a partir das estrias retiradas do Product Backlog e

que sero implementadas durante a Sprint;
Burndown Chat: a equipe monitora seu progresso a partir da informao das

tarefas realizadas no dia anterior atualizando um Burndown Chart, como
mostra a Figura 3. O grfico indica a completude de tarefas do Sprint e seu
andamento em comparao com o nmero de tarefas planejadas. O eixo
horizontal mostra o perodo em dias corridos; o eixo vertical mostra a
quantidade de trabalho que precisa ser feita no incio de cada Sprint.
Figura 3 Exemplo de um grfico Burndown Chat.
Fonte: http://www.brq.com/metodologias-ageis/
25
Alm do Burndown, pode-se utilizar para o acompanhamento de tarefas um quadro

visual onde as tarefas so divididas em a realizar, em andamento e j
realizadas. O Kanban ser abordado na prxima seo.
2.4 KANBAN
Kanban um termo de origem japonesa e significa literalmente carto. um sinal
visual com conceitos relacionados com cartes (post-it e outros) para indicar o
andamento do fluxo de produo em empresas de fabricao em srie.
Tipicamente usa-se um quadro em branco com post-its (Quadro Kanban), prximo
ao estoque de peas no setor de produo, conforme Figura 4.
Figura 4 Exemplo de um quadro Kanban.
Fonte: http://www.viso.com.br/produto/kanban-kanb-03-C149000.html
A transparncia que isso gera tambm contribui para a mudana cultural. O Kanban
expe gargalos, filas, variabilidade e desperdcio, tudo que impacta o desempenho
da organizao em termos de quantidade de trabalho de valor entregue e o tempo
de ciclo (tempo mdio para executar um item) necessrio para entreg-lo. Segundo
Anderson D. citado por Kningerg e Skarin (2009, p. 11), os primeiros estudos de
caso mostraram que o Kanban
muda o comportamento e incentiva uma maior
colaborao no trabalho. A utilizao de um sistema Kanban permite um controle

detalhado de produo com informaes sobre quando, quanto e o que produzir
(AGUIAR; PEINADO, 2007, p. 138).
2.4.1 Kanban no desenvolvimento de software
Segundo Anderson D. citado por Kningerg e Skarin (2009, p. 10), o Kanban uma
abordagem para introduzir mudanas em um ciclo de desenvolvimento de software
26
ou metodologia de gerenciamento de projetos. O entendimento do processo se d

ao mapear o fluxo de valor conforme a Figura 5 e ao concordar em limitar as
atividades em andamento (Work-In-Progress ou WIP).
Atualmente, o Kanban muitas vezes usado em conjunto com o Scrum, porque so
duas metodologias usadas no desenvolvimento gil de software.
Figura 5 Exemplo de um quadro Kanban em desenvolvimento de software.
Fonte: http://tatihelo.wordpress.com/2011/10/03/kanban/
Kningerg e Skarin (2009, p. 11) descrevem a seguinte forma de implantar o Kanban:
Visualize o fluxo de trabalho. Divida o trabalho em partes, escreva cada item

em um carto e coloque na parede e use colunas nomeadas para ilustrar
onde cada item est no fluxo de trabalho;
Limite o trabalho em progresso (WIP). Associe limites explcitos para quantos

itens podem estar em progresso a cada estado do fluxo de trabalho;
Acompanhe o tempo de execuo da tarefa. Otimize o processo para tornar o

tempo de execuo o menor e mais previsvel possvel.
2.5 SISTEMA DE CONTROLE DE VERSO

Sistemas de controle de verso (VCS version control system) so um mecanismo
de guardar mltiplas verses de arquivos, de modo que, quando se modifica um
deles, ainda possvel ter acesso s verses anteriores (HUMBLE; FARLEY, 2013,
p. 32). Para Chacon e Straub (2014, p. 13), sistemas de controle de verso so
sistemas que registram as mudanas feitas em um arquivo ou em um conjunto de
arquivos ao longo do tempo de forma que se possa recuperar verses especficas.
27
Um VCS permite reverter arquivos ou um projeto inteiro para um estado anterior,

comparar mudanas feitas ao decorrer do tempo, ver quem foi o ltimo a modificar
algo que pode estar causando problemas, saber quem e quando um erro foi
introduzido. Segundo Humble e Farley (2014, p. 33), ele tem basicamente dois
objetivos. Em primeiro lugar, ele deve guardar cada verso de cada arquivo
armazenado nele e garantir acesso a ela. Em segundo lugar, ele permite que
equipes distribudas no tempo e no espao colaborem. Existem trs maneiras de
efetuar o gerenciamento de verses, que sero apresentadas a seguir.
2.5.1 Sistemas de Controle de Verso Locais
Alguns
programadores
desenvolveram
muito
tempo
VCSs
locais
que
armazenavam todas as alteraes dos arquivos, conforme o diagrama da Figura 6.

Figura 6 Diagrama de um sistema de verso local.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Verso.
Basicamente, essa ferramenta mantm conjuntos de patches (ou seja, as diferenas

entre os arquivos) entre cada mudana em um formato especial; a partir da
qualquer arquivo em qualquer ponto na linha do tempo pode ser recriado ao juntarse todos os patches.
28
2.5.2 Sistemas de Controle de Verso Centralizados

Quando se trabalha em conjunto com outros desenvolvedores surge a necessidade
de compartilhar o que est sendo criado. Para lidar com isso, foram desenvolvidos
Sistemas de Controle de Verso Centralizados (CVCS - Centralized Version Control
System). Esses sistemas, como por exemplo o CVS, Subversion e Perforce,
possuem um nico servidor central que contm todos os arquivos versionados e
vrios clientes que podem resgatar (check-out) os arquivos do servidor. A Figura 7
apresenta o diagrama desse sistema.
Figura 7 Diagrama de um sistema de verso centralizado.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Verso
O diagrama demonstra algumas vantagens, especialmente sobre VCSs locais. Por

exemplo: todos podem ter conhecimento razovel sobre o que os outros
desenvolvedores esto fazendo no projeto; Administradores tm controle especfico
sobre quem faz o qu; e bem mais fcil administrar um CVCS do que lidar com
bancos de dados locais em cada cliente.
Uma desvantagem que o servidor central um ponto nico de falha. Se ele ficar
fora do ar por uma hora, ningum pode trabalhar em conjunto ou salvar novas
verses dos arquivos durante esse perodo.
29
2.5.3 Sistemas de Controle de Verso Distribudos

Em um Sistema de Controle de Verso Distribudo (DVCS - Distributed Version
Control System), os clientes no apenas fazem cpias das ltimas verses dos
arquivos mas eles so cpias completas do repositrio. Assim, se um servidor falhar,
qualquer um dos repositrios com os desenvolvedores podem ser copiados de volta
para o servidor para restaur-lo. Cada check-out na prtica um backup completo
de todos os dados, conforme a Figura 8.
Figura 8 Diagrama de um sistema de verso distribudo.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Verso
Muitos desses sistemas lidam muito bem com o aspecto de ter vrios repositrios
remotos com os quais se pode colaborar, permitindo que se trabalhe em conjunto
com diferentes grupos de pessoas, de diversas maneiras, simultaneamente no
mesmo projeto. Isso permite estabelecer diferentes tipos de fluxo de trabalho que
no so possveis em sistemas centralizados, como por exemplo o uso de modelos
hierrquicos.
30
2.6 GERNCIA DE CONFIGURAO

A estratgia de gerncia de configurao determina a forma de como o time de
desenvolvimento colabora pois ela registra a evoluo de seus sistemas e
aplicaes. Entende-se por configurao o estado em que um sistema se encontra
em um determinado momento.
As configuraes variam com o tempo de acordo com as atualizaes e correes
do ambiente e do sistema. Segundo Humble e Farley (2014, p. 280), neste contexto
o ambiente um conjunto de recursos que a aplicao precisa para funcionar. A
gerncia de configuraes trata os elementos como um todo, incluindo o hardware
necessrio para a manuteno do sistema e permite organizar todos os elementos
de forma a saber em qual estado o sistema se encontrava nos momentos chave do
desenvolvimento.
Conforme Humble e Farley (2014, p. 31), utilizar um sistema de controle de verso
apenas o primeiro passo para gerncia de configurao, uma vez que preciso dar
uma resposta afirmativa as seguintes questes: (1) possvel reproduzir exatamente
qualquer um dos ambientes? (2) possvel efetuar mudanas incrementais nesses
itens individuais e implant-las em quaisquer dos ambientes ou em todos eles? (3)
possvel identificar facilmente quais foram as mudanas ocorridas para um ambiente
especfico e rastre-las para ver quando, por que e para quem as mudanas foram
feitas? (4) possvel satisfazer todos os requisitos de conformidade
regulamentao aos quais se est sujeito? (5) qualquer membro da equipe pode
facilmente obter a informao de que precisa e fazer as mudanas que precisam ser
feitas?
Cada uma dessas perguntas corresponde a uma das atividades realizadas pela
gerncia de configurao para permitir manter a consistncia e a integridade do
software com as especificaes. Diante disso, importante guardar toda a
informao requerida para recriar os ambientes no controle de verso; isso inclui
arquivos de DNS, scripts de banco de dados, arquivos de compilao e implantao,
documentao, bibliotecas e arquivos de configurao para a aplicao e todas as
ferramentas relacionadas, e assim por diante, de modo que um novo membro da
equipe possa comear do zero a partir de um nico ponto.
31
2.6.1 Provisionamento
No caso dos servidores de redes de computadores, o processo de provisionamento
um conjunto de passos executveis que podem ser aplicados em uma imagem
inicial do sistema operacional para se ter tudo configurado corretamente (TAVARES,
2013). Esse conjunto de passos traz como benefcios a repetibilidade de gerar um
estado adequado do ambiente e uma documentao executvel dos procedimentos
para configurao.
Martin Fowler chama os servidores que dependem da ao humana de tentativa e
erro para provisionar de SnowflakeServer 2 , Essas mquinas geralmente no
possuem backup e, se houver alguma falha de disco, muito trabalho exigido para
colocar o projeto rodando em um computador novo.
Para Humble e Farley (2014, p. 290), o provisionamento de servidores comea
quando a nova mquina colocada em um datacenter, ligada alimentao e
rede; a partir deste ponto, praticamente todo o restante do seu ciclo de vida pode ser
feito remotamente por meio de automao.
Hoje, existe uma srie de ferramentas para provisionar uma mquina, cada uma
delas com seus diferentes benefcios e peculiaridades. Dentre as mais populares,
destacam-se:
Chef (http://www.opscode.com/chef);
Puppet (http://puppetlabs.com/puppet);
Ansible (http://www.ansibleworks.com/tech/);
Salt (http://saltstack.com/).
Todas elas esto contribuindo para a evoluo da comunidade DevOps (veja seo
2.10), e, apesar de competirem entre si, seu maior adversrio ainda a falta de uso
pelas empresas.
Sato (2013, p.60) relata uma caracterstica importante que essas ferramentas
especializadas possuem, a idempotncia. A idempotncia permite executar o cdigo
diversas vezes seguidas e as ferramentas s mudaro o que for necessrio. Se um
2
Acesse http://martinfowler.com/bliki/SnowflakeServer.html para mais detalhes sobre

Snowflake Server.
32
pacote estiver instalado, ele no ser reinstalado. Se um servio est iniciado, ele
no ser reiniciado. Diferentemente dos scripts proprietrios que s funcionam para
instalar e configurar o servidor pela primeira vez.
2.7 TESTES AUTOMATIZADOS
Muitos projetos contam com apenas testes manuais para a verificao da
conformidade dos seus requisitos funcionais e no funcionais. Desenvolver software
uma atividade complexa que envolve manipular uma grande quantidade de
elementos abstratos (TELES, 2004, p. 104). Enquanto codificam, desenvolvedores
tendem a verificar o programa, mas comum aparecer erros devido a situaes
completamente imprevistas ou devido a erros de lgica, falta de ateno,
interpretao incorreta de requisitos e, como consequncia, a ocorrncia de defeitos
uma realidade, sendo difcil ou impossvel evitar que aconteam durante o projeto.
Existem diversos tipos de teste que podem ser automatizados para garantir a
entrega de software com alta qualidade. Conforme Sato (2013, p.120), no existe
uma classificao ou terminologia amplamente aceita na indstria, mas a
comunidade gil geralmente se refere aos quatro quadrantes da Figura 9, descritos
por Brian Marick.
Figura 9 Quatro quadrante de testes descritos por Brian Marick.
Fonte: Entrega Contnua: Como entregar software de forma rpida e confivel
Na figura de Brian Marick, observa-se um agrupamento dos tipos de testes, sendo

que no lado esquerdo esto os testes que suportam a programao. Estes testes se
preocupam em avaliar a qualidade interna do sistema e so executados com
33
bastante frequncia pelos desenvolvedores para obter feedback sobre as mudanas

introduzidas.
No lado superior, esto os testes que so escritos do ponto de vista do negcio, com
uma linguagem que faz sentido para um especialista de domnio. No lado inferior
esto os testes voltados tecnologia, escritos do ponto de vista tcnico e com
termos que faro sentido para os programadores.
No lado direito existe testes que exigem a criatividade ou explorao e so
geralmente manuais, como os testes exploratrios. H tambm um conjunto de
testes passveis de automatizao que, conforme Humble e Farley (2014, p. 91), em
muitos projetos so ignorados ou no h uma preocupao em valid-los.
O conjunto de testes tambm atua como um conjunto de testes de regresso, no
testando apenas os requisitos funcionais do sistema, mas tambm a capacidade, a
segurana e outros requisitos no funcionais estabelecidos, sendo possvel garantir
que quaisquer problema que comprometa o cumprimento desses requisitos possam
ser identificados logo, quando o custo para corrigi-los baixo.
Conforme Humble e Farley (2014, p. 83), os testes automatizados devem ser
escritos em colaborao entre os testadores e os desenvolvedores desde o incio do
projeto, antes que os desenvolvedores iniciem seus trabalhos, para que o conjunto
de testes forme uma especificao executvel do comportamento do sistema. Com
os testes validam-se no somente se h um erro de lgica no cdigo mas tambm
se os requisitos esto bem definidos para que possam entregar aquilo que
esperado (LOPES, 2012, p.63).
Os testes manuais tambm so essenciais para adicionar qualidade como
demonstraes, testes de usabilidade e testes exploratrios, eles devem ser
realizados continuamente ao longo do projeto.
Os testes automatizados permitem que a mquina faa o que ela boa, a repetio,
enquanto os humanos faam o que eles so bons, explorar. Para a tarefa de escrita
dos testes automatizados, a XP traz em suas prticas como descrito na seo 2.2.3,
a prtica de desenvolvimento guiado por testes, que muito difundida na
comunidade de desenvolvimento de software e descrita na prxima seo.
34
2.7.1 Desenvolvimento guiado por testes

Desde a dcada de 90, quando Kent Beck escreveu a primeira biblioteca de testes,
o SUnit, em Smalltalk, existe a ideia de automatizar a tarefa de testes que muitas
vezes era efetuada manualmente. Como as prticas da XP ganharam notoriedade
no decorrer dos anos, o TDD ganhou ainda mais ateno, introduzindo o conceito de
que os desenvolvedores devam escrever os testes para as funcionalidades antes de
codific-las. Conforme Brana (2013, p. 4), isso permite um melhor entendimento
das necessidades do cliente, cria uma preocupao com as interfaces externas dos
mtodos e classes e permite contar com um conjunto de testes que podem ser
executados a qualquer momento para validar o sistema.
O ciclo aplicado prtica do TDD envolve trs passos, conforme a Figura 10.
Figura 10 Ciclo do TDD
Fonte: http://www.lagerweij.com/2014/04/04/outside-in-whatevers-at-the-core/
Os passos so:
A escrita do teste se d antes da codificao da funcionalidade, sendo que no

primeiro momento, o que esperado que o teste no passe;
O prximo passo codificar uma soluo para que o teste tenha sucesso ao
ser executado. Nesse momento, a primeira soluo encontrada pode ser
utilizada para atingir o objetivo;
No passo de refatorao, deve ser feita uma anlise no cdigo criado para
verificar se existe uma soluo mais otimizada que atinja o mesmo objetivo.
35
2.8 INTEGRAO CONTNUA

Em um ambiente de desenvolvimento, o software dividido de modo que cada
desenvolvedor fique responsvel por uma parte dele. Dessa forma, necessrio
integrar todas as partes para que o sistema funcione. Quanto mais longo for o tempo
entre uma integrao e outra, mais a equipe encontrar dificuldades para fazer o
sistema rodar e os testes funcionarem (TELES, 2004, P. 176).
Para Fowler (2006), Integrao Contnua (IC) uma prtica de desenvolvimento de
software onde os desenvolvedores integram seu trabalho pelo menos uma vez por
dia, podendo haver mltiplas integraes por dia. Assim que o desenvolvedor
termina sua tarefa, ele executa todos os testes para garantir que suas mudanas
funcionam isoladamente, atualizam o seu cdigo com as alteraes mais recentes
que esto no repositrio de cdigo e repetem todo o processo de testes, visando
certificar que suas mudanas funcionam com o cdigo que j est compartilhado. S
ento possvel integrar o seu cdigo ao repositrio de cdigo central.
Apesar de diminuir as chances de introduzir defeitos no sistema, esse ritual exige
que o desenvolvedor tenha a disciplina de fazer isso a cada alterao. Um servidor
de integrao contnua, conforme a Figura 11, permite o monitoramento do
repositrio constantemente. A cada alterao validada com sucesso no ambiente de
desenvolvimento, possvel efetuar o check-in no repositrio de cdigo, fazendo
com que o sistema de integrao contnua execute uma sequncia de verificaes,
como os testes automatizados, mantendo todos os membros do time atualizados
com o estado atual do projeto.
Figura 11 Processo de integrao contnua com o auxilio de ferramentas.
36
Cada alterao que tenha sido validada com sucesso pelo processo de integrao
contnua vira uma verso candidata a ir para produo e fica disponvel no
repositrio de artefatos. Essa prtica permite descobrir eventuais defeitos o mais
rapidamente possvel, acelerando a correo e diminuindo a probabilidade de que
pequenos erros se transformem em grandes dores de cabea no futuro.
2.9 PIPELINE DE IMPLANTAO
A Integrao Contnua abordada na seo anterior concentra-se principalmente no
time de desenvolvimento; ela precede o incio de vrios processos manuais, tais
como os testes exploratrios e a implantao do sistema. Conforme Humble e Farley
(2014, p. 105), h muitos gargalos no processo de entrega de software e comum
ver coisas tais como equipe de operaes esperando por documentao ou
correes, testadores esperando por verses boas de software, equipes de
desenvolvimento recebendo informaes sobre defeitos depois de j estarem
trabalhando h semanas em outras funcionalidades e a descoberta, j no fim do
processo de desenvolvimento, de que a arquitetura da aplicao no suporta os
requisitos no funcionais do sistema. Nesse cenrio, a equipe enfrenta um processo
de feedback longo, deixando o sistema impossibilitado de ir para produo.
O processo como um todo, de levar a funcionalidade da mente do cliente at o
usurio final, pode ser tratado com uma viso mais holstica, de ponta a ponta do
processo de entrega e modelado atravs de um fluxo de valor, mostrando uma
histria dos processos executado por uma organizao. O objetivo do fluxo de valor
mapear uma solicitao do cliente, do momento em que ela chega at que esteja
disponvel em produo (POPPERDIECK, 2011, p. 41). Conforme a Figura 12, todos
os passos para atender solicitao e o tempo mdio em cada passo pode ser
modelado, dando uma viso no tempo das atividades que agregam valor ao
processo e o tempo gasto em espera de outras atividades.
Essa espera entre um passo e outro pode se dar por exemplo, pelo tempo que se
leva para configurar e implantar o sistema em um ambiente. Em um processo
iterativo, a etapa de desenvolvimento incluiria vrios ciclos compostos de testes e
demonstraes e todo o processo seria repetido vrias vezes.
37
Figura 12 - Um exemplo de mapa de fluxo de valor simples para um produto
As alteraes efetuadas no sistema dependem de vrios indivduos, ou at mesmo

de vrias equipes at a sua entrega. Aps a codificao, preciso compilar o cdigo
gerando uma nova verso do sistema, fazer com que esse resultado seja validado
em cada estgio de teste, implantado em ambientes para testes exploratrios e
liberado em produo. O pipeline de implantao modela esse processo, e sua
inverso em uma ferramenta de integrao contnua e gerncia de verses o que
permite que uma equipe veja e controle o processo de cada mudana medida que
ela se move em direo a entrega ao usurio final (HUMBLE; FARLEY, 2014, p.
107). Com os aspectos tratados nas sees anteriores e com a automatizao, o
processo de entrega pode ser efetuado e executado regularmente e, portanto,
testado regularmente, agilizando o processo de feedback e reduzindo o risco de uma
nova verso em produo.
Duvall (2012) define o pipeline de implantao como um processo no qual diversos
tipos de tarefas so executadas com base no sucesso da tarefa anterior. Para
Humble e Farley (2014, p. 106) o pipeline de implantao uma manifestao
automatizada do processo de levar o software do controle de verso at os usurios.
Cada mudana passa de forma consistente no percurso de entrega atravs da
automao.
A parte gerenciada pelo pipeline de implantao no mapa de fluxo de valor a parte
que vai do desenvolvimento at a entrega da verso. O fato de ser possvel a
automatizao, no restringe a interao humana. A possibilidade de implantar o
sistema com o apertar de um boto encoraja testadores, desenvolvedores, analista e
usurios para seu uso frequente. A automatizao torna passos complexos e
suscetveis a erros em passos repetveis e confiveis.
38
Para chegar a este estgio, necessrio automatizar o processo de compilao,

automatizar um conjunto de testes que provam os critrios do sistema e automatizar
a implantao em ambientes de teste, aceitao e produo. Humble e Farley (2013,
p. 109) explicam como essas mudanas se movem pelo pipeline de implantao
atravs de um diagrama de sequncia, como mostrado na Figura 13.
A entrada do pipeline inicia-se com o check-in no sistema de controle de verso que
aciona o sistema de integrao contnua criando uma nova instncia do pipeline,
uma nova verso (verso candidata a ir para produo) que ir passar por uma
sequncia
de testes para provar que possvel uma entrega de verso. Cada
estgio de teste avalia a verso candidata de uma perspectiva diferente e a cada

teste que ela passa, aumenta a confiana em sua implementao, o que significa
que os ambientes do percurso se tornam progressivamente mais similares ao de
produo. O objetivo desse processo eliminar as verses candidatas que no
estejam prontas para produo o quanto antes e obter feedback sobre a falha o mais
rpido possvel (HUMBLE; FARLEY, 2014, p. 108).
Figura 13 - Mudanas se movendo por um pipeline de implantao.
Com a adoo dessa abordagem, no permitido efetuar implantao do sistema

em produo sem que a verso seja apropriadamente testada e regresses so
39
evitadas ao se fazer correes. As correes passam pelo mesmo processo que

quaisquer mudanas.
Quando a verso candidata passa pelo estgio de teste de aceitao automatizado,
ela se torna algo til e interessante no sendo mais prioridade da equipe de
desenvolvimento. prefervel que os estgios de implantao para os ambientes de
aceitao e produo no executem automaticamente. Os testadores devem ser
capazes de ver quais verses candidatas passaram com sucesso e implantar o
sistema em um ambiente configurado com um simples apertar de boto.
2.9.1 Como criar um pipeline de implantao inicial
Essa seo descreve uma estratgia para se chegar a um pipeline de implantao
conforme apresentado por Humble e Farley (2014, p. 133). Deve-se ter em mente
que, independente do estgio do projeto, a implementao do pipeline deve ser de
maneira incremental.
necessrio ter uma viso dos processos necessrios para permitir a entrega, isso
pode ser efetuado atravs do mapa de fluxo de valor conforme visto no incio deste
captulo. Com a participao de todos os envolvidos possvel descrever todos os
passos, obter estimativas do tempo decorrido e do tempo gasto nas atividades que
agregam valor. Modelar um pipeline de implantao exige entender seus processos
de entrega e balancear o nvel de feedback que voc quer receber (SATO, 2013, p.
182). Projetos anteriores podem servir de base se estiver trabalhando em um novo
projeto.
Pode-se iniciar com um fluxo bsico, um estgio para compilar a aplicao e rodar
os testes unitrios, um estgio para executar os testes de aceitao e um estgio
para implantar o sistema em um ambiente similar ao de produo. O primeiro
estgio executado sempre que se faz check-in no repositrio de cdigo, os testes
de aceitao devem utilizar o mesmo cdigo resultante da etapa anterior e comear
automaticamente depois que a compilao e os testes unitrios tiverem sidos
executados com sucesso. Os estgios de implantao utilizam as verses que
passaram com sucesso pelos testes de aceitao e devem poder ser executados
com o acionar de um boto. Na prtica de entrega contnua, conforme (SATO, 2013,
40
p. 181), a deciso de levar uma verso para produo de negcio e normalmente

requer pessoas com autorizao.
2.9.2 Objetivos para utilizao do pipeline
O objetivo ter o processo de entrega completamente automatizado para inibir risco
de negcio associados a cada entrega do sistema em produo. Fowler (2013)
acrescenta dizendo que o pipeline para detectar quaisquer mudanas que levem
os problemas para produo e para permitir a colaborao entre os envolvidos,
possibilitando a visibilidade de todo o fluxo de mudanas juntamente com uma trilha
de auditoria completa. Com a entrega sendo um resultado natural do pipeline de
implantao, possvel obter:
Um plano de entrega criado e mantido por todos os envolvidos, incluindo

desenvolvedores, testadores, operaes, infraestrutura e suporte;
Minimizao dos efeitos de erros cometidos por pessoas por meio da mxima
automao do processo possvel, comeando com os estgios mais sujeitos a
erros;
Ensaiar os procedimentos em ambientes similares ao de produo, de modo

que seja possvel depurar o sistema e a tecnologia que o suporta;
Ter a capacidade de executar um rollback3 de uma entrega se as coisas no

acontecerem de acordo com o plano;
Ter uma estratgia de migrao de dados e configurao de produo como

parte do processo de rollback.
Para que se consiga obter todos os benefcios do pipeline, Humble e Farley (2014,
p. 113) descrevem um conjunto de prticas, tais como:
Compile seus cdigos somente uma vez;
Faa a implantao da mesma maneira para cada ambiente;
Implante em uma cpia do ambiente de produo;
Cada mudana deve ser propagada pelo pipeline instantaneamente;
Rollback uma ao que desfaz a ao corrente, fazendo com que todas as modificaes
realizadas at o momento sejam rejeitadas. Para mais informaes acesse:
http://pgdocptbr.sourceforge.net/pg82/sql-rollback.html
41
Se qualquer parte do pipeline falhar, pare o processo e corrija o problema

antes de continuar qualquer coisa.
Possibilitar que qualquer indivduo (com permisso) envolvido no processo de

entrega implante uma verso do sistema em um ambiente no momento que deseja,
um dos resultados adquiridos com a criao do pipeline. Para auxiliar nessa tarefa,
existe no mercado um conjunto de ferramentas classificadas como ferramentas para
automao de implementao, dentre elas, destacam-se: Capistrano, Mina,
ControlTier, Glu e RunDeck.
2.10 MOVIMENTO DevOps
Em 2009 durante a conferncia Velocity da OReilly, John Allspan e Paul Hammond
apresentaram 10+ Deploys Per Day 4 , demonstrando como a Flickr5 efetuava 10
implantaes por dia e atravs da convergncia de outros movimentos adjacentes
como: o movimento infraestrutura como cdigo de Mark Burgess e Luke Kanies e o
movimento de administrao do sistema gil de Patrick Debois, deu-se origem ao
movimento DevOps. O movimento busca difundir em todo mundo a colaborao
entre todos os envolvidos na entrega do software, particularmente as equipes de
desenvolvimento, de testes e de operaes, conforme a Figura 14.
Figura 14 Equipes envolvidas no movimento DevOps.
Fonte: http://en.wikipedia.org/wiki/DevOps
Essa colaborao permite otimizar o fluxo do processo de desenvolvimento,

reduzindo o custo de criao de novas verses e possibilitando uma entrega
4
5
Acesse o video em: https://www.youtube.com/watch?v=LdOe18KhtT4

www.flickr.com
42
confivel de software. Com a adoo do movimento DevOps, consegue-se criar um

relacionamento colaborativo entre desenvolvimento e operaes; ampliar as taxas
de implementaes; e aumentar a confiabilidade, a resilincia e a segurana do
ambiente de produo.
Uma premissa simples do DevOps a aplicao de melhores prticas e padres do
desenvolvimento para as operaes e vice-versa (DUVALL, 2012). Para Hashimoto
(2013), DevOps serve para criar um ciclo de feedback rpido e reduzir o custo de
criao de novas verses de produtos, ao mesmo tempo que melhora a estabilidade
geral dos sistemas. A implementao na empresa no instantnea, pode-se
quebrar em uma srie de pequenas mudanas.
43
3. UMA PROPOSTA PARA AUTOMATIZAO DE ENTREGA DE SOFTWARE

Este captulo apresenta o estudo de caso realizado em um ambiente gil de
desenvolvimento de software, abordando as dificuldades relacionadas ao processo
de entrega. Atravs desse estudo de caso ser apresentado proposta de soluo,
os requisitos funcionais que devem ser atendidos e os trabalhos correlatos.
3.1 ESTUDO DE CASO
A empresa objeto deste estudo de caso est sediada em Vitria ES e possui mais de
5 anos de atuao no mercado de desenvolvimento de software. especializada em
solues para lojas virtuais e possui cerca de 20 colaboradores, sendo que sete
deles formam uma equipe dedicada exclusivamente para seu Sistema de Loja
Virtual (SLV). Essa equipe, composta de 3 desenvolvedores, 1 gerente de
projetos, 2 suporte/qualidade e 1 comercial, que atendem lojistas de vrias regies
do pas no mercado de comrcio eletrnico.
O SLV da empresa o ponto de partida para o atendimento de um novo cliente.
Esse sistema possui mais de 30 implantaes em produo, ou seja, mais de 30
clientes que o utiliza para vender seus produtos atravs da internet.
Para inibir riscos com perda de oportunidades no universo web, onde as
informaes trafegam de continente a continente em fraes de segundos, a
empresa evita os longos ciclos de desenvolvimento tradicionais adotando as
metodologias geis, fazendo uso das prticas da XP, do Scrum e do Kanban. Dessa
forma, uma nova verso do sistema entregue a cada 10 dias de desenvolvimento,
no trmino de cada Sprint.
Para cada solicitao de um cliente, existe uma sequncia de procedimentos prdefinidos que so executados at a concluso do atendimento. Esses processos
foram especificados em um mapa de fluxo de valor conforme a Figura 15. Entendese como fluxo de valor o processo de levar uma necessidade da mente do cliente
at as mos de seus usurios finais (HUMBLE; FARLEY, 2014, p. 107).
Esse mapa executado sempre que h uma nova solicitao, seja de clientes novos
ou de clientes j existentes e composto das seguintes atividades:
44
Quando uma solicitao gerada pelo cliente, o responsvel pelo comercial

realiza um contato com o lojista para que seja feita a especificao de como a
loja dever funcionar, conforme o ramo de atuao da loja;
Comercial, gerente de projetos e desenvolvedores analisam os requisitos da

solicitao definindo um oramento;
Com o oramento aprovado, o gerente de projetos em conjunto com os

desenvolvedores,
realizam
uma
estimativa
de
esforo
conforme
complexidade dos requisitos para mensurar quantas Sprints essa nova

demanda ir ocupar no cronograma. Vrias Sprints podem ser agendadas at
o atendimento de todos os requisitos;
No perodo de desenvolvimento, onde o tempo total determinado de acordo

com a quantidade de Sprints necessrias para atender as solicitaes, vrias
atividades so executadas conforme descrito na seo 3.1.1;
No final de cada Sprint, criada uma nova verso do SLV para o cliente e as
funcionalidades so implantadas em seu ambiente de produo.
Figura 15 - Mapa do fluxo de valor da empresa objeto deste estudo.
Na execuo desse processo, um desenvolvedor alocado para desenvolver as

solicitaes de um determinado cliente. As solicitaes menores, as que no
ocupam uma Sprint, so alocadas a um desenvolvedor em uma Sprint chamada de
suporte, deixando o cronograma sempre com 3 Sprints ocorrendo paralelamente.
Para manter a competitividade frente aos concorrentes, a empresa constantemente
precisa efetuar atualizaes no SLV para introduo de novas funcionalidades,
atualizao de tecnologia ou otimizao de cdigo, de forma a proporcionar uma
melhor experincia de compras aos usurios. Sendo assim, Sprints para a
atualizao do SLV so adicionadas ao cronograma.
45
Devido s dificuldades dos processos de desenvolvimento, conforme seo 3.1.2, a

quantidade de entregas de software de valor no final de uma Sprint baixo, sendo
preciso o agendamento de vrias Sprints e, sendo assim, a estimativa de tempo
para o atendimento das solicitaes de um cliente elevada. Gasta-se
aproximadamente cerca de 45 dias para a disponibilizao de uma nova loja com
poucas customizaes. O fluxo de atendimento a pequenas solicitaes gira em
torno de 30 dias, deixando os clientes insatisfeitos com o atendimento.
3.1.1 Processos relacionados ao desenvolvimento
Durante uma Sprint, um conjunto de tarefas necessrias para o desenvolvimento de
software so executadas pela equipe. O conjunto de solicitaes a serem
desenvolvidas nesse perodo so gerenciadas manualmente fazendo uso do quadro
do Kanban, No quadro, o fluxo efetuado conforme a Figura 16.
Figura 16 Movimentao atual das solicitaes no quadro Kanban.
As solicitaes ficam disponveis na coluna A Fazer. Quando o desenvolvedor inicia

a codificao, ele move a solicitao que ir trabalhar para a coluna Fazendo e
quando termina, a move para coluna Verificao. Nessa coluna, a equipe de
qualidade tem a visualizao das solicitaes que j esto disponveis para serem
testadas no ambiente de aceitao. Um desenvolvedor disponibiliza a solicitao no
ambiente de aceitao para que a equipe de qualidade realize os testes. Quando os
testes terminam, a solicitao movida para a coluna Concludo e, ento, um
desenvolvedor efetua a implantao no ambiente de produo e arquiva a
solicitao, retirando-a do quadro.
Para a codificao das solicitaes, cada desenvolvedor configura seu ambiente de
desenvolvimento com as dependncias necessrias para o funcionamento do SLV.
Ao efetuar alteraes no SLV, o desenvolvedor efetua o gerenciamento de verso
de cdigo utilizando a ferramenta Git e escreve um conjunto de testes
automatizados com a utilizao da ferramenta RSpec, apresentada na seo
46
5.2.1.10. Esses testes so executados em seu ambiente de desenvolvimento para

certificar de que no foram inseridos defeitos no sistema. Os testes tambm so
executados quando se faz o check-out do repositrio, verificando que as alteraes
de outro desenvolvedor no afetaram o que foi codificado.
Devido a codificao ser em computadores separados, necessrio efetuar a
juno do cdigo produzido ao repositrio de cdigo fonte, permitindo que outros
desenvolvedores utilizem o que foi produzido.
O gerenciamento dos sistemas por cada desenvolvedor pode ser visualizado na
Figura 17, onde o ambiente de desenvolvimento o computador pessoal de cada
um. Os ambientes das lojas virtuais so acessados pelos desenvolvedores para a
realizao de configuraes e atualizaes manualmente. O processo de implantar a
loja efetuado atravs do acesso ao servidor e efetuado o check-out do cdigo fonte
no repositrio e reiniciado os servios necessrios, tambm de forma manual.
Figura 17 - Fluxo do gerenciamento do sistema pelos desenvolvedores.
Para um novo cliente, o incio do desenvolvimento possui uma etapa adicional

chamada de Setup do Sistema, que composta das seguintes tarefas:
Configurar o ambiente de aceitao onde o sistema ser disponibilizado para

que sejam efetuados os testes exploratrios, possibilitando ao cliente validar
suas solicitaes;
47
Configurar o ambiente de produo onde a futura loja virtual ficar disponvel

para os usurios finais,
Implantar a verso padro do sistema de loja virtual nos dois ambientes, ou

seja, implantar a verso inicial do sistema sem nenhuma customizao.
O sistema instalado inmeras vezes no ambiente de aceitao para que a equipe

de qualidade e o prprio cliente efetuem testes e validem as solicitaes no decorrer
da Sprint. No trmino da Sprint, a nova verso do SLV implantada em seu
ambiente de produo.
Na atualizao do SLV, os testes e validaes so efetuados somente pela equipe
de qualidade, porm, no trmino, as atualizaes so implantadas no ambiente de
produo de cada cliente.
3.1.2 Dificuldades encontradas no desenvolvimento
O principal problema enfrentado pelos profissionais da rea de desenvolvimento de
software como fazer para transformar uma boa ideia em um sistema e entreg-lo
aos usurios o quanto antes (HUMBLE; FARLEY, 2014, p. 3).
Com demonstrado na seo 3.1, h uma grande utilizao do SLV. Os clientes esto
sempre solicitando atualizaes e melhorias para acompanhar as novas tendncias
do mercado, fazendo com que a empresa receba uma grande demanda de
manutenes mensais.
Os novos clientes chegam empresa com um cronograma para o futuro lanamento
do seu e-commerce, porm, eles acabam frustrados ao saber que o lanamento de
sua loja virtual s poder ser realizado em um prazo bem maior daquele planejado.
De acordo com a anlise efetuada pela equipe, concluiu-se que o gargalo se d
devido a muitos processos manuais que existem no desenvolvimento. Muitas tarefas
so executadas manualmente sem um nvel de qualidade que impea a incluso de
defeitos no sistema.
48
Durante o ciclo de desenvolvimento, diversos problemas ocorrem, tais como:
Os desenvolvedores codificam as funcionalidades em seus ambientes de

desenvolvimento sem o controle sobre as verses das ferramentas utilizadas
e a compatibilidade com o ambiente de produo;
Para aumentar a qualidade, a empresa faz uso de tcnicas e conceitos do

TDD, onde testes so escritos para posteriormente codificar os requisitos.
Cada desenvolvedor executa os testes em seu prprio ambiente de
desenvolvimento vrias vezes ao dia, sempre que est desenvolvendo uma
nova funcionalidade e quando faz o check-out no repositrio. Cada vez que
este processo executado, preciso esperar aproximadamente 15 minutos,
desestimulando uma cobertura mais eficaz de testes e deixando o
desenvolvedor impossibilitado de continuar trabalhando em outras atividades;
O cdigo produzido paralelamente pelos desenvolvedores no adicionado

constantemente ao cdigo principal, permanecendo em seu ambiente de
desenvolvimento at que determinada tarefa seja finalizada. O custo da
correo de defeitos elevado devido ao ciclo de feedback ser longo.
Trabalhar em paralelo exige mais comunicao e coordenao entre os
membros da equipe, pois quanto mais tempo eles ficarem sem integrar suas
mudanas, maior o risco de criarem conflitos (SATO, 2013, p. 126);
Muitas solicitaes so desenvolvidas e o controle de qual verso de um

componente que cada cliente est utilizando no eficiente; defeitos so
gerados quando componentes incompatveis so adicionados a uma
determinada loja;
Atualizaes nos ambientes so efetuadas manualmente alterando o seu

estado. So executados vrios passos separados e atmicos sendo que
necessrio fazer julgamentos a cada passo do processo, o que o torna sujeito
a erro humano;
O processo de entrega manual e demorado, preciso copiar arquivos de

configuraes para o ambiente que a loja ser implantada, possibilitando a
presena de erros se cada passo no for executado perfeitamente;
Na fase de setup da plataforma, preciso disponibilizar o ambiente de

aceitao e o de produo. A instalao dos softwares que a plataforma
depende e suas configuraes so feitas manualmente, sem nenhum controle
49
de qualidade e em caso de erro, no possvel fazer um auditoria para

descobrir o motivo;
Implantar novos cdigos ao sistema da loja em operao extremamente

crtico. Em muitos casos, preciso esperar o momento de menor acesso,
geralmente pela madrugada para implantar a nova verso. Um sistema no
gera lucro ou valor at que esteja nas mo de seus usurios (HUMBLE;
FARLEY, 2014, p. 14).
3.2 REQUISITOS FUNCIONAIS

Conforme a descrio da seo 3.1.2, fica visvel que um dos pontos desafiadores
do projeto est na utilizao de ferramentas capazes de automatizar diversas tarefas
includas no processo de desenvolvimento e de prover uma forma simplificada de
utilizao pelos envolvidos.
Com base em reunies e discusses realizadas entre a equipe responsvel pelo
SLV, das observaes feitas dos processo executados diariamente e da pesquisa de
ferramentas utilizadas no mercado, foram levantados os requisitos para a iniciao
de um sistema. Esses requisitos foram documentados atravs de Diagrama de
Casos de Uso. Conforme Ramos (2006, p.32), o diagrama de casos de uso
descreve a relao entre atores e casos de uso de um determinado sistema,
permitindo uma viso global de alto nvel, sendo fundamental a definio correta da
sua fronteira. Um dos seus objetivos apresentar, de forma geral, as funes e
servios que o sistema oferecer, sem se preocupar em como estas sero
implementadas.
Os atores que interagem com o sistema so:
Desenvolvedor: ator responsvel por gerenciar as solicitaes, cadastrando e

movendo-as pelo quadro Kanban de acordo com o desenvolvimento e pelo
gerenciamento dos ambientes onde o SLV disponibilizado, cadastrando as
informaes
necessrias
para
acesso
executando
instalao
automatizada.
GerenteProjetos: ator responsvel por gerenciar as solicitaes dos clientes,

criando projetos, cadastrando e priorizando as solicitaes conforme o
cronograma de desenvolvimento. Responsvel pelo cadastro de informaes
50
dos usurios habilitados a utilizar o sistema e pelo cadastro das informaes

de cada cliente. Tambm responsvel gerencia dos ambientes e pela
deciso de atualizao de uma loja com uma nova verso disponvel;
Qualidade: ator responsvel por verificar o atendimento das solicitaes

atravs de testes exploratrios. Possui acesso as solicitaes para
disponibiliz-las em ambiente de aceitao medida que novas verses
ficam disponveis;
SIC: este ator o sistema de integrao contnua responsvel por efetuar o

monitoramento do repositrio de cdigo fonte e, ao perceber que uma
alterao foi efetuada pelo ator Desenvolvedor, executar todos os testes
automatizados, fornecendo feedback ao responsvel pelo desenvolvimento
da funcionalidade.
Este sistema est agrupado em trs subsistemas, os quais esto denominados:

GerenciarSolicitacoes, GerenciarAmbientes e CadastrarGeral e sero descritos a
seguir de forma sucinta. A Figura 18 apresenta o Diagrama de Casos de Uso
principal do sistema proposto. A descrio completa apresentada no Anexo A.
Figura 18 - Diagrama de Caso de Uso Principal.
3.2.1 Caso de uso CadastrarGeral

No caso de uso CadastrarGeral o gerente de projetos ir cadastrar todos os usurios
envolvidos na entrega de software, permitindo o acesso aos projetos e seus
51
ambientes. Nesse caso de uso tambm sero cadastradas as informaes dos

clientes. Um cliente poder ter mais que um SLV ativo. Consultas aos clientes
cadastrados podero ser realizadas por todos os atores no caso de uso
GerenciarSolicitacoes.
Este caso de uso decomposto nos casos de uso apresentados na Figura 19.
Figura 19 - Diagrama de Caso de Uso CadastrarGeral.
a) CadastrarUsuarios: caso de uso utilizado para gerenciar as informaes dos

membros da equipe responsvel pelo sistema de SLV, tais como o nome, email, descrio e data de incluso.
b) CadastrarClientes: caso de uso utilizado para gerenciar as informaes dos
clientes como o nome da empresa, telefone, e-mail e razo social; e dos
especialistas de domnio que participam do projeto, tais como o nome,
telefone, e-mail e descrio.
3.2.2 Caso de uso GerenciarAmbientes
O
caso
de
uso
GerenciarAmbientes
pode
ser
executado
pelos
atores
GerenteProjetos e Desenvolvedor e destinado ao controle das informaes de

configuraes para a criao dos ambientes para implantao do SLV.
Desenvolvedores com conhecimentos tcnicos de configuraes de servidor e
sistema operacional controlam essas informaes; os demais desenvolvedores
podem contribuir nas atualizaes das configuraes, de acordo com as mudanas
que so efetuadas no sistema.
Este caso de uso decomposto nos casos de uso CadastrarAmbiente,
InstalarPuppet e ProvisionarAmbiente, os quais so apresentados na Figura 20.
52
Figura 20 - Diagrama de Caso de Uso GerenciarAmbientes.
a) CadastrarAmbiente: caso de uso utilizado pelo desenvolvedor ou pelo gerente

de projetos com conhecimentos em configuraes de servidores e sistemas
operacionais para controlar os dados de acesso e configuraes dos pacotes
que devero ser instalados em um Cloud Hosting. Para criar um novo
ambiente, os atores devero selecionar para qual o projeto o ambiente
pertence e o tipo do ambiente (produo ou aceitao), o endereo IP do
servidor, usurio e senha de acesso ao ambiente, a URL de acesso ao
ambiente e a descrio.
b) InstalarPuppet: este caso de uso ser executado aps o caso de uso
CadastrarAmbiente, sendo responsvel por (1) verificar se as informaes
cadastradas do novo ambiente tais como endereo IP, login e senha esto
vlidas (atravs da execuo de um comando Unix ping); (2) instalar e ativar
no n 6 correspondente ao endereo IP a ferramenta Puppet Client e (3)
habilitar o boto de provisionamento de ambiente.
c) ProvisionarAmbiente: caso de uso que ser executado aps o caso de uso
InstalarPuppet ou a partir de uma lista de ambientes j cadastrados. As atores
Desenvolvedor ou GerenteProjetos podero executar o caso de uso
ProvisionarAmbiente, clicando no boto correspondente. Neste momento,
ser enviada uma solicitao de servio para a ferramenta Puppet Client que
executar os scripts de instalao de pacotes no sistema operacional tais
como nginx, mysql, redis, memcached e monit utilizados no ambiente de
destino. A execuo do caso de uso ProvisionarAmbiente deixa o ambiente
em um estado apropriado para implantao do SLV.
6
No contexto atual, n um servidor disponvel por um Cloud Hosting.
53
3.2.3 Caso de Uso GerenciarSolicitacoes

O gerenciamento das funcionalidades que sero customizadas no SLV, desde a sua
entrada at o momento em que so entregues conforme o quadro Kanban da Figura
23 na seo 3.4.2, ser apoiado pelo caso de uso GerenciarSolicitacoes. Nele, o
gerente de projetos ir cadastrar o projeto e as solicitaes (correo de defeitos,
novas funcionalidades ou customizaes) a serem atendidas. Os desenvolvedores,
medida que codificam, movero as funcionalidades at a etapa de verificao
automatizada e o SIC efetuar, ento, a execuo das etapas de testes
automatizados, certificando-se que a nova verso candidata a ir para produo. A
equipe de qualidade poder visualizar qual verso est disponvel para testes e
disponibiliz-la em ambiente de aceitao para demonstraes junto ao cliente. No
trmino, o gerente de projetos poder decidir qual verso dever ser implantada em
ambiente de produo.
Este caso de uso decomposto nos casos de uso apresentados na Figura 21.
Figura 21 - Diagrama de caso de uso GerenciarSolicitacoes.
54
a) CadastrarProjeto: caso de uso executado pelo ator GerenteProjetos para

incluir um novo projeto no sistema conforme fechamento de contrato pelo
comercial. No projeto ser includo todas as solicitaes que sero atendidas.
b) CadastrarSolicitacao: caso de uso executado pelos atores Desenvolvedor e
GerenteProjetos, sendo responsvel pelo gerenciamento das solicitaes que
devero ser desenvolvidas para a loja virtual, conforme a reunio de
planejamento apresentada na seo 3.1. As informaes de nome e
descrio so inseridas e a solicitao permanece na coluna Solicitaes do
quadro Kanban.
c) AgruparSolicitacoesSprint: caso de uso executado pelo ator GerenteProjetos
para agrupar na coluna A Fazer do quadro Kanban as solicitaes que sero
atendidas na prxima Sprint. Os usurios que atendero cada uma das
solicitaes so registrados, o status da solicitao atualizado e as
respectivas datas previstas para o incio e para o fim do desenvolvimento so
agendadas.
d) IniciarDesenvolvimento: caso de uso executado pelos atores GerenteProjetos
e Desenvolvedor para mover a solicitao que o desenvolvimento ser
iniciado, da coluna A Fazer para a coluna Fazendo do quadro Kanban,
atualizando o seu status.
e) EnviarParaVerificacao: caso de uso executado pelos atores GerenteProjetos
ou Desenvolvedor para mover a solicitao da coluna Fazendo para a coluna
Teste Unit. do quadro Kanban. Quando os atores finalizam a solicitao, eles
enviam o cdigo fonte para o repositrio manualmente atravs da utilizao
da ferramenta Git. Nesse processo, o Git efetua a compactao dos arquivos
alterados e gera um identificador nico no formato SHA17 que cadastrado
na solicitao, permitindo dessa forma, que o SIC faa a movimentao da
solicitao entre as colunas Teste Unit, Teste Integ. e Teste aceit. do quadro
Kanban, atualizando do status de acordo com que as etapas de testes sejam
executadas com sucesso.
f) ExecutarTestesAutomatizados: caso de uso executado pelo ator SIC. O SIC
estar monitorando o repositrio de cdigo em um intervalo pr-determinado.
Em criptografia, SHA-1 uma funo hash de criptografia projetado pela Agncia dos
Estados Unidos de Segurana Nacional. Veja mais em: http://en.wikipedia.org/wiki/SHA-1.
55
Quando for detectado alguma alterao no repositrio. O SIC executa ento,

os processos de testes automatizados.
g) DisponibilizarVersaoEmAceitacao: caso de uso executado por todos os
autores, exceto o SIC, para disponibilizar a verso que passou no processo
de testes automatizados e est na coluna Aceitao do quadro Kanban, para
o ambiente de aceitao. Neste ambiente, a equipe de qualidade realiza
demonstraes do SLV para o clientes.
h) ImplantarVersaoEmProducao: caso de uso executado por todos os autores,
exceto o SIC, para disponibilizar a verso que foi validada com sucesso no
item anterior no ambiente de produo.
3.3 REQUISITOS NO FUNCIONAIS
Segundo Humble e Farley (2014, p. 249), os requisitos no funcionais so o
equivalente em software ao construtor de pontes que tenta garantir que as vigas
escolhidas so fortes o suficientes para suportar o trfego e as condies
meteorolgicas esperadas. Esses requisitos so reais e precisam ser considerados,
esto associados com o estado do sistema e no expressam nenhuma funo
realizada pelo sistema. O Quadro 1 apresenta os requisitos no funcionais para o
sistema proposto.
Quadro 1 Requisitos no funcionais.
TTULO
DESCRIO
1 Segurana
O sistema deve garantir a segurana dos dados contidos no

sistema.
2 Navegabilidade
Deve possuir uma navegabilidade fcil e intuitiva para facilitar a

utilizao diria.
3 Multiacesso
O sistema deve possuir acesso a mltiplos usurios conectados

simultaneamente e executando tarefas distintas ou no.
4 Performance
O sistema deve atender aos requisitos de forma eficiente para

possibilitar um ciclo de feedbacks curtos.
5 Integrao
O sistema deve efetuar a integrao com as ferramentas

utilizadas de forma a facilitar a utilizao por todos os
envolvidos.
56
3.4 PROPOSTA DE SOLUO

Esse trabalho prope o desenvolvimento do sistema Ovenbird, baseado no padro
pipeline de implantao apresentado na seo 2.9. O objetivo do Ovenbird
gerenciar a transio das solicitaes pelos vrios estgios de desenvolvimento at
o momento da entrega ao usurio final, atravs de uma interface amigvel que
abstraia a complexidade das ferramenta disponveis no mercado e facilite, dessa
forma, a utilizao por qualquer membro da equipe responsvel pelo SLV.
O Ovenbird destina-se a gesto de atividades de Desenvolvimento, Entrega/Reviso
e Nova Verso do mapa de fluxo de valor da Figura 15, visando tratar da gerncia
de ambientes e gerncia de entrega.
O Ovenbird um sistema Web que ser implantado em um Cloud Hosting para
atender necessidade da execuo de processos de forma paralela ao
desenvolvimento e, para permitir o acesso dos membros da equipe que estiverem
fora das instalaes da empresa.
A utilizao do Ovenbird inicia-se com o cadastro das informaes de todos os
interessados na entrega do SLV; a equipe responsvel pelo sistema e o cliente. Um
cliente poder adquirir mais de um SLV.
Cada loja virtual ser representada no Ovenbird como um projeto, devidamente
associado a um cliente. Um projeto composto pelos ambientes para implantao e
das solicitaes que devero ser desenvolvidas. As propostas de soluo para a
gesto destes dois ambientes so descritas nas prximas sees.
3.4.1 Proposta de soluo para a Gerncia de Ambientes
Os processos de disponibilizar os ambientes na fase de setup (seo 3.1.1) e de
efetuar atualizaes, sero executados atravs de uma ferramenta de automao de
infraestrutura, conforme apresentado na seo 2.6.1, para permitir que o processo
de estabelecer ou restabelecer um estado do ambiente (apropriado para
implantao), seja uma tarefa previsvel e com o tempo conhecido.
57
A ferramenta utilizada ser o Puppet, descrita na seo 5.2.1.9, uma das primeiras
ferramentas criadas desse tipo, bastante popular e com uma grande comunidade
contribuindo com contedos, tais como tutoriais e mdulos open source.
Pelo fato de estar trabalhando com um sistema base, o SLV, no h diferenas
complexas entre os ambientes dos clientes. As maiores mudanas concentram-se
em dados de configurao. Em cada projeto, dever ser possvel inserir informaes
de configurao dos ambientes.
Sero utilizados dois pacotes do Puppet, o Puppet Master e o Puppet Client, como
mostra a Figura 22.
Figura 22 - Utilizao do Puppet pelo sistema Ovenbird.
O Puppet Master ser instalado junto ao Ovenbird e ir gerenciar as configuraes

de cada ambiente. Para manter a gerncia de ambientes centralizada, versionada e
passvel de auditoria, os arquivos de configurao de ambiente, chamados de
manifestos e, utilizados pelo Puppet, sero escritos pelos desenvolvedores e
armazenados no repositrio de cdigo fonte.
Na criao do ambiente, aps informar os dados necessrios, o Ovenbird efetuar
as configuraes iniciais no n de destino para permitir o provisionamento. Nesse
processo, ser instalado e configurado o Puppet Client. O provisionamento ser
58
efetuado com a solicitao das configuraes ao Puppet Master pelo Puppet Client.
O Puppet Client solicita suas configuraes e aplica em seu ambiente.
As atualizaes dos ambientes sero efetuadas a partir desse momento,
automaticamente pelo Puppet Client em um intervalo determinado de acordo com as
configuraes ou pelo desenvolvedor ou gerente de projetos, atravs do boto
Provisionar ambiente disponibilizado no Ovenbird. Quando houver modificaes
nos ambientes, elas sero versionadas e adicionadas ao repositrio de cdigo pelo
desenvolvedor, logo aps, o Puppet Master ser atualizado com essas modificaes
e na prxima solicitao do Puppet Client, as alteraes sero enviadas ao seu
ambiente para que sejam aplicadas.
A Figura 22 tambm ilustra a utilizao da ferramenta Vagrant, apresentada na
seo 5.2.1.11, para a criao de ambientes de desenvolvimento. O Vagrant no
gerenciado pelo Ovenbird, mas a sua utilizao completa o processo de
automatizao de ambientes ao permitir usufruir dos recursos do Puppet. O Vagrant
permite a utilizao do Puppet Client em uma mquina virtual para solicitar as
configuraes ao Puppet Master. Com isso, o ambiente de desenvolvimento ser
idntico entre todos os desenvolvedores e ir refletir o ambiente de produo,
utilizando o mesmo sistema operacional e as mesmas configuraes.
Com a utilizao do Puppet, as configuraes necessrias para a criao de
qualquer ambiente (desenvolvimento, aceitao e produo), ficaro centralizadas
no Ovenbird. Dessa forma, no ser necessrio acessar um ambiente para efetuar
mudanas manualmente.
3.4.2 Proposta de soluo para a Gerncia de Solicitaes
Para cada SLV um projeto no Ovenbird ser criado para que as solicitaes sejam
agrupadas. Um novo projeto cria uma rea de trabalho onde as solicitaes sero
visualizadas. Esta rea de trabalho um reflexo do quadro Kanban mostrado na
Figura 16, com a incluso de novas colunas para permitir a visualizao de todas as
etapas inclusas no processo de entrega de software. O novo quadro pode ser
visualizado na Figura 23.
59
Figura 23 - Quadro Kanban no sistema Ovenbird.
Aps a definio da solicitao junto ao cliente, ela cadastrada na coluna

Solicitaes, iniciando o processo de entrega. Com o planejamento de uma nova
Sprint, todas as solicitaes que devero ser atendidas nesse perodo so
agrupadas na coluna A Fazer.
O desenvolvedor, para iniciar suas atividades, move a solicitao que ir
desenvolver para a coluna Fazendo e efetua o check-in no repositrio de cdigo
utilizando o Git, ferramenta para controle de verso apresentada na seo 5.2.1.3, e
inicia a codificao. Ao finalizar a solicitao, o desenvolvedor executa os testes de
suas alteraes em seu ambiente de desenvolvimento e, aps a validao, ele
adiciona o novo cdigo no repositrio atravs de um check-out.
O check-out gera um identificador para representar os arquivos modificados. O
identificador adicionado solicitao no Ovenbird e esta movida para a coluna
Teste Unit.
O repositrio de cdigo ser monitorado pelo sistema de integrao contnua
Jenkins, apresentado na seo 5.2.1.4. Quando uma alterao for detectada, ela
ser submetida ao fluxo de testes pelo Jenkins, que instalado junto com o
Ovenbird. Os passos de testes unitrios, testes de integrao e testes de aceitao
so gerenciados de forma automtica, sendo que o processo s avana ao teste
seguinte se o anterior for bem sucedido. Para fornecer feedback dos processos de
testes, o Jenkins ir atualizar o status da solicitao pelos vrios tipos de teste, para
que o Ovenbird possa moviment-la pelo quadro Kanban de forma automtica. Os
testes so criados com a utilizao da ferramenta RSpec.
Quando a solicitao passar por todas as etapas de testes automatizados, ela se
torna uma funcionalidade candidata a ir para produo e fica disponvel para ser
implantada no ambiente de aceitao pela equipe de qualidade. A solicitao no
Ovenbird fica disponvel na coluna Aceitao do quadro Kanban e poder ser
disponibilizada no ambiente de aceitao clicando-se em um boto no Ovenbird,
60
executando-se a ferramenta Mina. Mina uma ferramenta para automatizao de

implantao apresentada na seo 5.2.1.5.
A automatizao proporciona a consistncia na execuo, tornando o processo
repetvel e confivel. Isso permite que a equipe de qualidade possua a liberdade de
implantar uma verso no momento que desejar, agilizando o processo de validao
do que foi desenvolvido junto ao cliente.
Se tudo estiver de acordo como foi especificado, a solicitao liberada no Ovenbird
para ser implantada no ambiente de produo ficando disponvel na coluna
Produo do quadro Kanban. O processo de implantao ocorre da mesma forma
descrita para o ambiente de aceitao.
A implantao de uma verso em ambiente de produo geralmente uma deciso
do gerente de projetos, mas todos os envolvidos podero efetuar esse processo
caso seja necessrio.
O Quadro 2 lista todas as ferramentas utilizadas para a automatizao do processo
de entrega.
Quadro 2 Ferramentas utilizadas.
NOME
DESCRIO
Puppet
Automao de Infraestrutura
Vagrant
Automao de Ambiente de Desenvolvimento
Git
Sistema de Controle de Verso Distribudo
Mina
Automao de Implantao
Jenkins
Servidor de Integrao Contnua
RSpec / Cucumber
Automao de Testes
Conforme Humble e Farley (2014, p. 106), isso permite que equipes de testes
possam criar e implantar seu prprios ambientes de testes com o apertar de um
boto. Desenvolvedores podem ver quais verses passaram por quais estgios do
processo de entrega e quais problemas foram encontrados, e gerentes podem
verificar e monitorar mtricas fundamentais como tempo de ciclo e qualidade de
61
software. Como resultado, todos os envolvidos no processo de entrega conseguem

acesso aquilo de que precisam e quando precisam, alm de visibilidade sobre o
processo de entrega de modo a identificar, otimizar e remover gargalos. Isso leva a
um processo de entrega que no somente mais rpido, como mais seguro.
A Figura 24 apresenta o novo fluxo de gerenciamento do sistema com a utilizao
de ferramentas para automatizar as etapas do processo de entrega.
Figura 24 - Fluxo do gerenciamento do sistema pelos desenvolvedores aps a aplicao das
solues propostas.
O novo fluxo de gerenciamento no permite que os acessos aos ambientes de

implantao sejam efetuados manualmente pelos desenvolvedores. Todo o cdigo
de configurao, dos ambientes e das lojas virtuais, devem ser versionados e
enviados ao repositrio. O Ovenbird efetua o check-out no repositrio e, de forma
automatizada, com o auxlio das ferramentas apresentadas, envia as configuraes
para os ambientes que as executam. No processo de implantao, a ferramenta
utilizada efetua o check-out no repositrio e implanta o SLV no ambiente.
3.5 TRABALHOS CORRELATOS
Com o objetivo de no elevar o custo de desenvolvimento do SLV com o pagamento
de licenas de ferramentas enterprise tais como a Team Foundation Server
(http://msdn.microsoft.com/en-us/library/ms181238(v=vs.90).aspx)
Borland
62
(http://www.borland.com/Home), a empresa busca solues na comunidade open

source. Esta seo apresenta trs ferramentas open source de integrao e as
compara com a ferramenta proposta neste trabalho.
3.5.1 Go Continuous Delivery
A Go uma ferramenta de integrao contnua voltada para o gerenciamento de
verses e a distribuio de software em vrios computadores. Desenvolvida pela
empresa ThoughtWorks, foi liberada como software livre em 2014.
A Go trabalha com o padro pipeline de implantao para permitir gerenciar as
alteraes no cdigo fonte da aplicao e obter um feedback rpido. A ferramenta
destina-se ao ambiente de desenvolvimento e emprega o ciclo build-test-release
para efetuar implantaes sob-demanda. A Figura 25 apresenta o processo de
entrega de uma verso, permitindo ver a evoluo e o estado do projeto.
Figura 25 Tela do pipeline de implantao na ferramenta Go.
Fonte: http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2
3.5.2 Tools Cloud

Tools Cloud uma ferramenta comercial que fornece a integrao de vrias
ferramentas de cdigo aberto, incluindo controle de verso, gerenciamento de
projetos e acompanhamento de problemas, integrao contnua e repositrios de
artefatos, hospedadas e gerenciadas na nuvem, para criar um ambiente completo
atravs da internet.
Cada cliente recebe um ambiente exclusivo e todas as ferramentas so instaladas
em uma nica mquina virtual na nuvem, com armazenamento virtual dedicado.
63
A Figura 26 apresenta o painel de instalao da ferramenta.
Figura 26 Painel de instalao da Tools Cloud.
Fonte: http://toolscloud.com/
O servio acessvel via HTTPS e se prope a resolver problemas de inatividade do

servidor, problemas de backup, problemas de configurao e falhas de segurana
em uma infraestrutura de desenvolvimento para organizaes de desenvolvimento
de software de classe mundial.
3.5.3 Trello
O Trello um sistema para gerenciamento de tarefas que segue o mtodo Kanban.
A empresa Fog Creek Software criou a ferramenta online em setembro de 2011,
para permitir a organizao de equipes e tarefas de forma muito mais dinmica e
facilitada.
Ele permite a criao de diversos quadros, nos quais pode-se criar diversas colunas,
como mostra a Figura 27. Dentro de cada coluna possvel adicionar uma ou mais
tarefas (cards), contendo o contedo que o usurio desejar.
64
Figura 27 Quadro do Trello.
Fonte: http://corporate.canaltech.com.br/dica/utilitarios/gerencie-equipes-e-tarefas-com-o-trello-e-de-adeus-aos-post-its/
3.5.4 Quadro Comparativo

O Quadro 3 mostra as diferenas entre as ferramentas apresentadas e o Ovenbird.
Quadro 3 Comparativo Ovenbird X GO X Tool Cloud X Trello.
GO
Gerncia de Tarefas
Integrao Contnua
Tools Cloud
Trello
Ovenbird
Provisionamento
X
X
Implantao Automatizada
Controle de Verso
Open Source
X
X
X
X
Com o quadro, pode-se observar que o Ovenbird possui um gerenciamento de

tarefas com os mesmos conceitos do Trello, porm, o Trello no oferece suporte aos
demais itens. A Tools Clound direcionada para o gerenciamento de ambiente e
instalao de ferramentas. O Ovenbird permite alm do provisionamento de
ambiente, uma gerncia automatizada do cdigo do sistema. A Go gerencia o cdigo
fonte do sistema e direcionada para desenvolvedores, enquanto o Ovenbird d
suporte tambm ao negcio, com o gerenciamento de solicitaes.
65
4. ANLISE ORIENTADA A OBJETOS

Esse captulo apresenta os diagramas derivados da anlise orientada a objetos
realizada para o desenvolvimento do sistema Ovenbird. Segundo Pressman (2006,
p. 152), o objetivo da orientao a objetos definir todas as classes relevantes ao
problema a ser resolvido, as operaes e os atributos relacionados a elas, as
relaes entre elas e o comportamento que elas exibem.
Na anlise orientada a objetos ser adotada a Unified Modeling Language (UML)
para especificar, construir, visualizar os artefatos do sistema proposto.
4.1 DIAGRAMA DE CLASSES
Aps a documentao dos requisitos no captulo 3 utilizando-se o Diagrama de
Casos de Uso, sero modeladas as classes necessrias que iro compor e
solucionar as questes levantadas e especificadas.
O diagrama de classes o diagrama encontrado com maior frequncia na
modelagem de sistemas orientados a objetos e mostra um conjunto de classes,
interfaces e colaboraes e seus relacionamentos. Uma classe corresponde a algo
tangvel, ou a uma abstrao conceitual, existente no domnio do usurio ou no
domnio do engenheiro de software (RAMOS, 2006, p. 80). A Figura 28 mostra o
diagrama de classes de anlise do sistema Ovenbird.
66
Figura 28 Diagrama de classes de anlise parte esttica - do sistema Ovenbird.
Segundo Bezerra (2003, p. 96), um modelo de classes de anlise no leva em

considerao restries inerentes tecnologia a ser utilizada na soluo de um
problema. Na Figura 28 os interessados pela entrega do sistema esto
representados na classe Membro, que especializada na classe Usurio,
representando as pessoas do time de desenvolvimento e, na classe Especialista,
representando
as
pessoas
designadas
pelo
cliente
para
descrever
as
funcionalidades.
Nos ambientes so efetuados vrias implantaes do sistemas, cada implantao
composta das solicitaes que esto disponveis. preciso saber qual verso do
sistema est em determinado ambiente. As solicitaes, de acordo com os
resultados dos testes, podem ser atualizadas. A verso de uma solicitao pode ser
alterada at o momento que ela vire uma verso candidata a ir para produo.
67
4.2 DICIONRIO DE DADOS

O Quadro 4 apresenta o dicionrio de dados referente s classes do sistema
Ovenbird.
Quadro 4 Dicionrio de dados do sistema Ovenbird.
(continua)
Classes
Ambiente
Cliente
Especialista
Membro
Atributos
Obrigatrio Descrio
tipo
Sim
Qual o tipo do ambiente

que se est criando
ip
Sim
O endereo IP para
acesso ao Cloud Hosting
usuario
Sim
O usurio de acesso
senha
Sim
A senha de acesso
url
Sim
A URL para acesso via

browser
descricao
No
Descrio sobre o
ambiente
nome
Sim
Nome do cliente
telefone
Sim
Telefone de contato
email
Sim
E-mail de contato
razaoSocial
No
Razo social da empresa
ocupacao
Sim
Gargo ocupado na
empresa
nome
Sim
Nome do especialista
telefone
No
Telefone para contato
email
Sim
E-mail para contato
descricao
No
Descrio sobre as
atividades do especialista
data
Sim
Data que foi realizada a

implantao
Sim
O status da implantao
versao
Sim
A verso da aplicao que

foi implantada
nome
Sim
Nome do projeto
Implantacao status
Projeto
urlRepositorio Sim
URL do repositrio de
cdigo fonte
Valor
Possveis
Aceitao /
Produo
sucesso /
erro
68
Quadro 5 Dicionrio de dados do sistema Ovenbird.

(concluso)
Classes
Solicitacao
Atributos
Obrigatrio Descrio
nome
Sim
O titulo da solicitao
descrio
No
A descrio da solicitao
a ser desenvolvida
dataInicio
No
Data prevista para o inicio

do desenvolvimento
No
Data prevista para o

trmino do
desenvolvimento
dataFim
Sim
O status da validao
normal/
sucesso /
falhou
coluna
Sim
A posio no quadro
Kanban
1/2/3/4
/5/6/7/
8
dataInclusao
Sim
Data de cadastro
login
Sim
Login para acesso ao

sistema
senha
Sim
Senha para acesso ao

sistema
tipo
Sim
Especifica qual o tipo de

usurio que est
acessando o sistema
codigo
Sim
O cdigo gerado pelo

sistema de controle de
verso
data
Sim
A data que gerou a nova

verso
status
Usuario
Valor
Possveis
Versao
Programad
or /
Gerente de
projetos /
Qualidade
4.3 DIAGRAMAS DE SEQNCIA

Os diagramas de sequncia ilustram interaes entre objetos em um determinado
perodo de tempo e a sequncia de eventos que ocorrem em um determinado
processo. Uma interao uma sequncia de mensagens entre tpicas instncias de
classes, componentes, subsistemas ou atores (RAMOS, 2006, p.32).
69
O diagrama de sequncia apresentado na Figura 29 tem como objetivo incluir um

novo ambiente e efetuar as configuraes iniciais no n de destino.
Figura 29 Diagrama de sequncia incluirNovoAmbiente.
O diagrama de sequncia apresentado na Figura 30 tem como objetivo incluir um

novo projeto para um determinado cliente.
Figura 30 Diagrama de sequncia cadastrarProjeto.
O diagrama de sequncia apresentado na Figura 31 tem como objetivo incluir uma

nova solicitao para um determinado projeto.
70
Figura 31 Diagrama de sequncia incluirSolicitacao.
O diagrama de sequncia apresentado na Figura 32 tem como objetivo executar o

processo de implantao de uma funcionalidade.
Figura 32 Diagrama de sequncia gerarNovaImplantao.
4.4 DIAGRAMA DE ESTADO

Segundo Bezerra (2003, p. 209), um estado uma situao na vida de um objeto
durante a qual ele satisfaz alguma condio ou realiza alguma atividade. Cada
estado de um objeto normalmente determinado pelos valores dos seus atributos
e/ou pelas suas ligaes com outros objetos.
A UML possui um conjunto de notaes para o diagrama de estado, que permite
modelar o comportamento interno de um determinado objeto, subsistema ou sistema
global. A Figura 33 apresenta o diagrama de estados de uma solicitao no pipeline
de implantao.
71
Figura 33 Diagrama de estado de classe funcionalidade.
Quando uma nova solicitao adicionada ao projeto, ela permanece em seu

estado inicial at aps o planejamento da prxima Sprint. Com a definio da Sprint,
a solicitao agrupada na coluna A Fazer com as demais solicitao que devero
ser atendidas. O desenvolvedor altera o estado da solicitao para Fazendo assim
que inicia o desenvolvimento. Os prximos estados, so os estados de testes
automatizados, a cada verificao bem sucedida, o estado da solicitao
atualizado para o prximos estado. Nesse processo de testes, quando ocorrer um
defeito, o estado da solicitao volta ao Fazendo para que seja efetuadas as devidas
correes.
Quando termina o processo de testes, a solicitao fica disponvel para ser
implantada no ambiente de aceitao para que a equipe de qualidade verifique os
requisitos especificados pelo cliente. Por fim, a solicitao liberada para ser
implantada no ambiente de produo, onde alcana o estado pretendido.
72
5. PROJETO E IMPLEMENTAO
Este captulo apresenta o projeto e a implementao da ferramenta Ovenbird
proposta.
5.1 PROJETO
O projeto de um sistema constri representaes de programas coerentes e bem
planejadas que se concentram nos inter-relacionamentos das partes de alto nvel e
nas operaes lgicas envolvidas nos nveis inferiores (PRESSMAN, 2006, p. 207).
O projeto aborda a arquitetura, a interface com o usurio, os componentes
orientados a objetos e o banco de dados da ferramenta. A implementao apresenta
as tecnologias e linguagens utilizadas, as restries de implementao, a instalao
e funcionamento do prottipo.
5.1.1 Projeto de arquitetura
Segundo Pressman (2006, p. 208), a arquitetura de software de um programa ou
sistema computacional a estrutura ou estruturas do sistema que abrangem os
componentes
de
software,
as
propriedades
externamente
visveis
desses
componentes e as relaes entre eles. O sistema foi desenvolvido orientado a

objetos para a Web na arquitetura Cliente/Servidor e construdo no modelo de quatro
camadas, conforme a Figura 34.
Figura 34 Arquitetura de quatro camadas do sistema Ovenbird.
As camadas da ferramenta proposta so:
Camada de Apresentao: Interaes na interface da aplicao so

realizadas diretamente no servidor Web que recebe a requisio e retorna
73
uma resposta como pgina web, desenvolvida em HyperText Markup

Language (HTML);
Camada Lgica: Nesta camada est no servidor de aplicao onde as regras

do negcio so executadas e determinam de que maneira os dados sero
utilizados;
Camada de Dados: Nesta camada tem-se o servidor de Banco de Dados, no

qual reside toda a informao necessria para o funcionamento da aplicao;
Camada Cliente: Neste caso, o cliente o navegador utilizado pelo usurio.
5.1.2 Projeto de interface

Para beneficiar toda a equipe responsvel pelo SLV, a interface foi desenvolvida de
forma a permitir acesso ao sistema via internet. Para permitir a compatibilidade entre
os navegadores web, a interface do prottipo foi desenvolvida com o auxlio da
biblioteca Bootstrap (http://getbootstrap.com/), fazendo-se uso do HTML e da
Cascading Style Sheets (CSS). O projeto de interface com o usurio relaciona-se
tanto com o estudo de pessoas quanto com aspectos tecnolgicos (PRESSMAN,
2006, p. 265). Em geral, decompe-se em Projeto de Arquitetura da Aplicao Web
e Projeto de Navegao, apresentados a seguir.
5.1.2.1 Projeto de arquitetura da aplicao web
O Projeto de Arquitetura para aplicao web deve descrever como ser realizada a
comunicao do usurio com o sistema. A utilizao da estrutura hierrquica permite
um fluxo de controle horizontal, por meio da ramificao de hipertexto, ao longo dos
ramos verticais da estrutura (PRESSMAN, 2006, p. 442). A Figura 35 apresenta o
projeto de arquitetura da aplicao web do Ovenbird.
74
Figura 35 Projeto da Arquitetura Web.
A partir da tela principal, os usurios podero acessar o menu do Ovenbird e

navegar para as reas de clientes, projetos e usurios. Na rea do cliente, o usurio
poder visualizar os clientes existentes ou cadastrar um novo. Na tela principal de
projetos, o usurio adquire permisso para cadastrar um novo projeto e visualizar
um projeto j existente. Quando o usurio visualiza um projeto, possvel o cadastro
e a visualizao das solicitaes e, quando o usurio cadastra um projeto,
permitido visualizar e cadastrar especialistas alm de visualizar e cadastrar
ambientes. Os membros da equipe responsvel pelo o SLV so gerenciados atravs
do menu Usurios. Na tela de usurio concebido o acesso para visualizar todos os
usurios e cadastrar um novo.
5.1.2.2 Projeto de navegao
A partir do momento que foi estabelecida a arquitetura do Ovenbird e identificados
os seus componentes, deve-se definir caminhos de navegao que permitam ao
usurio ter acesso ao contedo e aos servios oferecidos.
Conforme Pressman (2006, p. 444), o projeto de navegao comea com a
considerao da hierarquia do usurio e os casos de uso relacionados. Cada ator
pode usar a aplicao de forma um tanto diferente e assim ter diferentes
necessidades de navegao.
As Figuras 36, 37 e 38 apresentam os projetos de navegao dos atores
GerenteProjetos, Desenvolvedor e Qualidade, respectivamente.
75
Figura 36 Projeto de navegao do ator GerenteProjetos.
Figura 37 Projeto de navegao do ator Desenvolvedor.
Figura 38 Projeto de navegao do ator Qualidade.
76
5.1.3 Projeto de componente

De acordo com Ramos (2006, p. 128), um componente uma pea bsica na
implementao de um sistema. Ele consiste, na prtica, em um conjunto de artefatos
fsicos com formato digital, como por exemplo, arquivos de cdigo fonte ou
documentos relativos ao negcio.
Segundo Pressman (2006, p. 239), a abordagem de projeto orientado a objetos trata
no apenas da aplicao, mas tambm da infraestrutura da aplicao e focaliza a
representao de quatro componentes principais do sistema: Componente de
Domnio do Problema (CDP), Componente de Gerncia de Dados (CGD),
Componente de Gerncia de Tarefas (CGT) e Componente de Interao Humana
(CIH), que so apresentados a seguir.
5.1.3.1 Componente de Domnio do Problema (CDP)
O componente de domnio do problema corresponde aos subsistemas responsveis
por implementar diretamente os requisitos dos usurios (COAD; YOURDON, 1993).
A Figura 39 representa o componente de domnio de problema do Ovenbird.
77
Figura 39 Componente do Domnio do Problema.
78
5.1.3.2 Componente de Interao Humana (CIH)

O Ovenbird desenvolvido utilizando a linguagem de programao Ruby. As
classes de Interao Humana sero obtidas a partir do pr-processamento de
arquivos com a utilizao do sistema de template ERB. O ERB trabalha com as
marcaes HTML e cdigo Ruby embutido, permitindo gerar convenientemente
qualquer tipo de texto, em qualquer quantidade, a partir de modelos. (FUENTES,
2014, p. 114).
Os modelos combinam-se de texto simples com cdigo Ruby para a substituio de
variveis e controle de fluxo, o que os torna fcil de escrever e manter. Sendo assim,
no ser feito um projeto especfico para este componente j que a interface
gerada na medida em que os arquivos .erb so processados.
5.1.3.3 Componente de Gerncia de Tarefa (CGT)
O componente de Gerncia de Tarefas compreende a definio de tarefas e a
comunicao e coordenao entre elas. A Figura 40 representa o Componente de
Gerncia de Tarefas do Ovenbird.
79
Figura 40 Componente de Gerncia de Tarefa.
80
5.1.3.4 Componente de Gerncia de Dados (CGD)

O Componente de Gerncia de Dados fornece a infraestrutura para a recuperao e
armazenamento dos objetos no sistema (persistncia dos objetos). Sua finalidade
isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura do
software.
Para o desenvolvimento do Ovenbird foi utilizado o framework RubyOnRails
(http://rubyonrails.org). O RubyOnRails por padro utiliza a biblioteca ActiveRecord
(http://guides.rubyonrails.org/active_record_basics.html) para lidar com banco de
dados.
Segundo Urubatan (2012, p.123), a ActiveRecord uma camada de mapeamento
objeto-relacional que facilita a criao e a utilizao de objetos de negcios cujos
dados requerem armazenamento persistente para um banco de dados. uma
implementao do padro ActiveRecord8, um objeto que envolve uma linha em uma
tabela de banco de dados ou exibio, encapsula o acesso ao banco, e acrescenta
lgica de domnio sobre esses dados (FOWLER, 2010).
Dessa forma no existe o Componente de Gerncia de Dados, sendo que este
encontra-se implicitamente implementado na biblioteca ActiveRecord.
5.1.4 Projeto relacional de dados
Uma vez que os bancos de dados relacionais so os dispositivos de armazenamento
mais confiveis e utilizados atualmente, o Ovenbird foi construdo utilizando o
sistema gerenciador de banco de dados relacional MySQL, apresentado na seo
5.2.1.6. O projeto do banco de dados relacional apresentado na Figura 41.
http://www.martinfowler.com/eaaCatalog/activeRecord.html
81
Figura 41 Diagrama relacional de dados.
5.2 IMPLEMENTAO DO PROTTIPO

Esta seo apresenta as tecnologias utilizadas na implementao, as restries de
implementao, o procedimento para a instalao e funcionamento do prottipo e as
telas do mesmo.
82
5.2.1 Tecnologias utilizadas no prottipo

Para permitir a automatizao dos processos relacionados com a entrega de
software, foi selecionado um conjunto de ferramentas disponveis no mercado. Tais
ferramentas so apresentadas nas prximas sees.
5.2.1.1 Ruby e RubyOnRails
O prottipo proposto foi escrito utilizando a linguagem de programao Ruby
(https://www.ruby-lang.org/en/), por ser uma linguagem totalmente orientada a
objetos com algumas caractersticas funcionais, dinmica, open source e com foco
na simplicidade e produtividade.
Ruby uma linguagem de programao interpretada multiparadigma, de tipagem
dinmica e forte, com gerenciamento de memria automtico. Seu criador, Yukihiro
Matsumoto, queria uma linguagem que juntasse programao funcional e
imperativa, mas acima de tudo que fosse uma linguagem legvel. Esta uma das
grandes vantagens da linguagem, ser extremamente legvel.
Para uma melhor produtividade e desempenho do sistema, o framework
RubyOnRails foi utilizado por fornecer uma soluo de desenvolvimento completa e
com baixa curva de aprendizagem. RubyOnRails uma ferramenta open source
seguindo a arquitetura MVC (Model-View-Controler). Surgiu dentro da empresa
37signals9 e foi criado por David Heinemeier Hansson, que resolveu extrair parte da
lgica web de um projeto chamado Basecamp (FUENTES, 2014, p. 4).
Segundo Souza (2014, p. 10), o framework RubyOnRails permite a criao de
aplicaes web com extrema rapidez. Essa agilidade tem sido considerada por
vrias startups no momento da criao de seus produtos.
5.2.1.2 Cucumber
O Cucumber (http://cukes.info/) uma ferramenta de testes de aceitao utilizada
para automatizar testes do comportamento do software, levando em conta o ponto
de vista do usurio (BRANA, 2013, p.13). Segundo Humble e Farley (2014, p.
http://37signals.com/
83
189), testes de aceitao so voltados para o negcio, no para o desenvolvedor;

eles testam funcionalidades completas em uma verso do sistema.
Com o Cucumber, a especificao do sistema efetuada atravs de documentos em
linguagem natural (portugus), porm, com a possibilidade de executar essa
documentao para verificar o comportamento especificado no sistema real.
O Cucumber estimula a conversa com pessoas de negcio de modo a melhorar o
entendimento dos requisitos e, com o passar do tempo, a especificao criada com
o uso do Cucumber, conhecida como Living Documentation (documentao viva), se
torna uma das principais referncias do comportamento do sistema (BRANA, 2013,
p.13).
5.2.1.3 Git
O Git (http://git-scm.com/) uma ferramenta para registrar alteraes feitas em um
conjunto de arquivos ao longo do tempo, uma tarefa tradicionalmente conhecida
como controle de verso (SILVERMAN, 2013, p. 9). O Git um sistema de controle
de verso distribudo, conforme apresentado na seo 2.5.3 e teve sua concepo
em 2005 por Linus Torvalds, para gerenciar o cdigo do kernel do Linux.
Segundo Silverman (2013, p. 9), qualquer grupo de arquivos relacionados que sejam
alterados com o decorrer do tempo candidato ao uso do Git, podendo-se:
Verificar o estado do projeto em qualquer ponto do passado;
Mostrar as diferenas entre os diversos estgios do projeto;
Dividir o desenvolvimento do projeto em mltiplas linhas independentes, os

chamados branches, que podem ser desenvolvidos separadamente;
Recombinar periodicamente os branches em um processo chamado de

merge e reacomodar as alteraes feitas em dois ou mais branches;
Permitir que muitas pessoas trabalhem simultaneamente em um projeto,

compartilhando e combinando seu trabalho conforme necessrio.
84
5.2.1.4 Jenkins
A ferramenta Jenkins (http://jenkins-ci.org/), trabalha em conjunto com o Git para
apoiar diversas atividades no ciclo de desenvolvimento de um projeto. Atualmente
essa ferramenta concentra-se em duas vertentes:
Compilar e testar continuamente projetos de software. Jenkins fornece uma

maneira simples para a prtica de integrao contnua, tornando mais fcil
para os desenvolvedores integrar suas alteraes no projeto;
Monitorar a execuo de tarefas que so agendadas e configuradas, tais

como a execuo de testes automatizados.
Uma das vantagens do Jenkins, que ele altamente extensvel, podendo ser
configurado para se comunicar com diversas outras ferramentas, como a da gerao
de uma nova verso de software.
Jenkins trabalha com uma abordagem na qual prioriza as sadas e as informaes
de retorno referentes a cada tarefa pr-determinada. Com a utilizao da integrao
contnua, o desenvolvedor ter um feedback referente ao cdigo que efetuou checkin conforme definido na configurao de cada tarefa no Jenkins (SATO, 2013, p.
128).
5.2.1.5 Mina
Mina (http://mina-deploy.github.io/mina/) uma ferramenta para a automatizao de
implantao de sistemas com um fluxo de trabalho baseado em tarefas. Ela gera um
procedimento inteiro como um script e executa-o remotamente em um servidor. Mina
cria somente uma sesso SSH por implantao, minimizando a sobrecarga da
conexo SSH.
Com a utilizao do Mina, utiliza-se o mesmo processo para efetuar implantaes
em qualquer ambiente de maneira consistente e confivel (MINA, [2013?]).
5.2.1.6 MySQL
O MySQL (http://www.mysql.com/) um sistema gerenciador de banco de dados
relacional, multiusurio, multitarefa e open source. atualmente um dos bancos de
85
dados mais populares, com mais de 10 milhes de instalaes pelo mundo. Possui
verses disponveis para vrios sistemas operacionais, entre eles o Linux, Windows
e FreeBSD.
Para utilizar o MySQL, necessrio instalar um servidor e uma aplicao cliente. O
servidor o responsvel por armazenar os dados, responder s requisies,
controlar a consistncia dos dados, bem como a execuo de transaes
concomitantes entre outras. O cliente se comunica com o servidor atravs da SQL. A
verso gratuita do MySQL chamada de Edio da Comunidade e possui o servidor
e uma interface grfica cliente (TONSING, 2006, p. 46).
5.2.1.7 Nginx
O Nginx (http://wiki.nginx.org/Main) um servidor web rpido, gratuito e open
source, com inmeras possibilidades de configurao para melhor performance.
conhecido por sua estabilidade, configurao simples e baixo consumo de recursos.
Escrito por Igor Sysoev em 2002 e teve sua primeira verso pblica liberada em
2004. Segundo uma pesquisa da W3techs.com, em maro de 2009, o Nginx usado
em 39,4% dos sites mais acessados no mundo (NGINX, [2004?])
5.2.1.8 Puma
Puma (http://puma.io/) uma pequena biblioteca que fornece um servidor HTTP 1.1
muito rpido e concorrente para aplicaes web Ruby. Criado por Evan Phoenix no
final de 2011, Puma foi construdo para a velocidade e paralelismo (PUMA, [2011?].
5.2.1.9 Puppet
O Puppet (http://puppetlabs.com/) uma ferramenta de automao de infraestrutura
utilizada por diversas empresas que precisam gerenciar milhares de mquinas
fsicas e virtuais ao redor do mundo, tais como as empresas MediaWiki Fundation,
Google, e Mozilla Fundation.
Os scripts do Puppet so escritos atravs de uma linguagem declarativa, baseada
em Ruby. Cada comando que se declara na linguagem uma diretiva, chamada de
recurso e, possvel definir um conjunto de recursos em um arquivo chamado de
86
manifesto. Uma caracterstica importante dessa ferramenta a idempotncia que

permite executar o mesmo cdigo diversas vezes, fazendo com que a ferramenta
altere somente o que for necessrio, ou seja, se um pacote j estiver instalado, ele
no ser reinstalado.
O ponto positivo dessa abordagem declarativa poder ter algo bastante especfico,
e focado em um s trabalho. A ideia que se tenha a configurao centralizada em
um nico ponto, e essa configurao seja distribuda para diversos ns de uma rede
(PUPPET LABS, 2014).
5.2.1.10 RSpec
RSpec (http://rspec.info/) uma biblioteca de testes escrita em Ruby e projetada
para fazer o desenvolvimento orientado a testes uma experincia produtiva e
agradvel. Ela permite descrever a aplicao em uma DSL 10 muito simples e
elegante para manter uma documentao atualizada.
Muito usado para descrever aplicaes RubyOnRails, com o RSpec possvel testar
qualquer cdigo escrito em Ruby. Ele composto por diversos mdulos que
permitem expressar funcionalidades, cenrios e expectativas de como sua aplicao
e/ou objetos devem se comportar.
Embora o RSpec seja muito completo, permitido a criao de vrios tipos de testes,
tais como testes unitrios, testes de aceitao e testes de performance, possvel
estend-lo muito facilmente caso se queira adequar o modo como ele funciona. Isso
permite tornar os seus testes ainda mais expressivos e concisos (GEORGE, 2014, p.
11).
5.2.1.11 Vagrant
O Vagrant (https://www.vagrantup.com/) fornece uma forma fcil de configurar e
reproduzir ambientes de desenvolvimento portteis, construdos atravs de
mquinas virtuais e controlados por um nico fluxo de trabalho consistente,
ajudando a maximizar a produtividade e flexibilidade de toda a equipe.
10
http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
87
Para isso, as mquinas so provisionadas em cima do VirtualBox, VMware, AWS, ou

qualquer outro provedor. Ento, ferramentas de provisionamento padro da
indstria, tais como shell scripts, Chef, ou Puppet, podem ser usadas para instalar e
configurar o ambiente na mquina virtual automaticamente (HEIDI, 2014, p. 11).
5.3 RESTRIES DE IMPLEMENTAO
O projeto apresentado foi desenvolvido como um prottipo para o sistema Ovenbird.
Com um grau de importncia da qualidade da codificao baixo, sua utilizao em
produo no ser satisfatria.
O controle de acesso, a segurana e testes de usabilidade da interface no foram
observados com a importncia adequada, pois no se trata inicialmente do foco
proposto pelo projeto para este prottipo.
O prottipo no contempla a insero de imagens, utilizadas normalmente para
identificar visualmente um usurio e se restringe a sistemas desenvolvidos na
linguagem de programao Ruby e a atender os processos de desenvolvimento da
empresa apresentada no estudo de caso, sendo invivel sua utilizao por equipes
de desenvolvimento que no sigam o fluxo do quadro Kanban da Figura 23.
5.4 INSTALAO E FUNCIONAMENTO DO PROTTIPO
O Ovenbird foi desenvolvido utilizando a linguagem de programao Ruby em sua
verso 2.1.5, instalada em uma plataforma Unix11. A maior parte das distribuies
Linux possuem pacotes de Ruby para serem instalados. O Ruby possui um
gerenciador de pacotes chamado RubyGems (https://rubygems.org/). Com o
RubyGems possvel instalar as ferramentas utilizadas no Ovenbird, tais como o
framework RubyOnRails, a ferramenta Mina e o servidor de aplicao Puma.
O
sistema
operacional
utilizada
para
efetuar
implantao
durante
desenvolvimento do prottipo foi o Ubuntu Server 14.04 LTS, que uma distribuio
Linux. Ferramentas como o Mysql, Nginx e Jenkins, podem ser instaladas atravs do
gerenciador de pacotes do Ubuntu, o apt12.
11
12
http://www.unix.org/
http://linux.die.net/man/8/apt-get
88
Para a instalao o Ovenbird, necessrio ter um sistema operacional em

funcionamento. Para configurar um sistema operacional, o mais recomendado, um
n em um Cloud Hosting. Com a utilizao do Puppet pelo projeto, a instalao das
ferramentas necessrias ocorre de forma automatizada. No projeto existe uma pasta
chamada puppet contendo todos os manifestos (arquivos de configurao do
Puppet) necessrios criar um ambiente com o estado desejado.
Primeiramente necessrio efetuar a instalao do Puppet nesse n, depois, copiar
os manifestos para o novo ambiente e instruir o Puppet para que seja executado
utilizando esses arquivos.
O ultimo passo inserir o IP desse novo n no arquivo de configurao da
ferramenta Mina e executar a implantao.
5.5 INTERFACE COM O USURIO
Esta seo apresenta as principais telas prototipadas para ferramenta Ovenbird, de
forma a dar suporte aos requisitos apresentados na seo 3.2. A Figura 42
apresenta a tela com a lista de todos os usurios cadastrados no sistema.
Figura 42 Tela para visualizao dos usurios cadastrados.
Esta tela acessada atravs do menu Usurios e permite a visualizao da listagem

de todos os usurios cadastrados no sistema. Um novo usurio cadastrado pelo
gerente de projetos clicando no boto Cadastrar Usurio para exibir o formulrio de
cadastro conforme a Figura 43. Em cada usurio cadastrado, possvel editar e
visualizar
suas
respectivamente.
informaes
atravs
dos
botes
Editar
Visualizar
89
Figura 43 Tela para cadastro de usurios.
A Figura 44 apresenta a tela com a lista de todos os clientes cadastrados.

Figura 44 Tela para visualizao dos clientes cadastrados.
Esta tela acessada atravs do menu Clientes e permite a visualizao da listagem

de todos os clientes cadastrados no sistema. O boto Cadastrar Cliente utilizado
para exibir o formulrio de cadastro de um novo clientes conforme apresentado na
Figura 45. Em cada cliente cadastrado, possvel editar e visualizar suas
informaes atravs dos botes Editar e Visualizar respectivamente.
90
Figura 45 Tela para cadastro de cliente.
O formulrio para o cadastro de novos clientes tambm utilizado para exibir as

informaes que podero ser atualizadas, dessa forma, esta tela, de acordo com a
ao executada (cadastrar, editar e visualizar), ir possuir trs sees relacionadas.
A primeira seo o formulrio de cadastro de um novo cliente. A segunda seo
uma listagem de todos os projetos que determinado cliente possui com a
possibilidade de cadastrar, editar e visualizar. A terceira seo exibe a lista de todos
os especialistas indicados pelo cliente e permite o cadastro, a visualizao e a
atualizao. A segunda e a terceira seo, no aparecem no cadastro de um novo
cliente.
A Figura 46 apresenta a tela para cadastro de um novo especialista.
Figura 46 Tela para cadastro de especialista.
91
A Figura 47 apresenta a tela para cadastro de um novo projeto.

Figura 47 Tela para cadastro de projeto.
Esta tela apresenta o formulrio para cadastro de um novo projeto, sendo tambm
utilizada para exibir as informao que podero ser atualizadas de acordo com a
ao executada (cadastrar, editar e visualizar). A tela possui trs sees
relacionadas. A primeira seo o formulrio para cadastro das informaes de um
projeto. A segunda seo, a lista de todos os ambientes j configurados para este
projeto. Nota-se que nesta seo h dois botes em destaque; o boto Configurar
que executa o caso de uso InstalarPuppet e o boto Provisionar, responsvel por
executar o caso de uso ProvisionarAmbiente e deixar o ambiente em um estado
adequado para implantao. A terceira seo a lista dos especialistas que iro
contribuir para o desenvolvimento da loja virtual.
A Figura 48 apresenta a tela para cadastro de um novo ambiente, sendo possvel a
escolha do tipo aceitao ou produo.
92
Figura 48 Tela para cadastro de ambiente.
A Figura 49 apresenta a tela para a visualizao de todos os projetos, agrupados por

clientes.
Figura 49 Tela para cadastro de ambiente.
A partir dessa tela ser possvel acessar o quadro Kanban com as funcionalidades
clicando no boto Visualizar Projeto de cada projeto cadastrado.
A Figura 50 apresenta a tela do quadro Kanban onde ser possvel visualizar o
processo do pipeline de implantao.
93
Figura 50 Tela do pipeline de implantao.
94
Esta tela apresenta as solicitaes de um projeto agrupadas nas colunas que

representam as etapas do pipeline de implantao. Os botes para a implantao
automatizada do sistema so disponibilizados aps os testes automatizados. O
boto verde efetua a implantao no ambiente de aceitao e o boto laranja, efetua
a implantao no ambiente de produo.
A Figura 51 apresenta a tela para cadastro de uma nova solicitao pelo ator
GerenteProjetos.
Figura 52 Tela para cadastro de solicitao.
95
6. CONCLUSO E PERSPECTIVAS FUTURAS

O processo de desenvolvimento de software um conceito de mbito muito vasto e
pretende designar uma sequncia de atividades, normalmente agrupadas em fases
e tarefas, executadas de forma sistemtica e uniformizada, realizadas por pessoas
com responsabilidades bem definidas e que, a partir de um conjunto de entradas
produzem um conjunto de sada (RAMOS, 2006, p. 19).
No entanto, as atividades apresentam diversos problemas tais como o controle da
compatibilidade das ferramentas utilizadas entre os ambientes, onde comum ver
software funcionando em uma mquina e o mesmo no funcionando em outra; a
execuo de processos repetitivos, tais como os testes automatizados, que ocupam
demasiadamente a equipe de desenvolvimento; conflitos na juno dos trabalhos
realizados pelos desenvolvedores com o processo de integrao do cdigo
demorado, aumentando o custo para a correo de defeitos e gerando um ciclo de
feedback longo; a criao de vrios ambientes heterognicos oriundos de
configuraes manuais, sem auditoria e realizadas por pessoas diferentes e erros ao
efetuar a implantao de uma verso em produo, quando necessrio fazer
julgamentos a cada passo do processo por humanos.
A ferramenta proposta neste trabalho tem como objetivo gerenciar a transio das
solicitaes pelos vrios estgios do desenvolvimento at o momento da entrega ao
usurio final, para permitir que a equipe responsvel pelo SLV responda s
mudanas de forma eficiente, aumente a capacidade de gerar novas verses bemsucedidas e de liber-las sob demanda e implante o seu sistema de loja virtual em
qualquer ambiente instantaneamente para refletir as mudanas de uma forma
eficiente e com baixo custo. Para isso, a ferramenta proposta realiza a integrao de
ferramentas para a automatizao de infraestrutura, integrao continua do cdigo,
execuo de testes automatizados e a automatizao da implantao, abstraindo a
complexidade da utilizao atravs de uma interface amigvel e que permita a
manipulao por qualquer membro da equipe.
A metodologia adotada abrangeu uma reviso bibliogrfica sobre os principais temas
envolvidos no processo de entrega automatizada de software, das metodologias
96
geis de desenvolvimento, das ferramentas disponveis no mercado que do suporte

para a automatizao e do desenvolvimento de software.
A ferramenta foi desenvolvida utilizando o paradigma da orientao a objetos com a
linguagem de programao Ruby, o framework RubyOnRails e o SGBD MySQL,
efetuando a integrao entre as ferramentas Puppet, Git, Mina, Jenkins, RSpec e
Cucumber, para permitir a automatizao do pipeline de implantao.
Como contribuies deste trabalho pode-se citar o entendimento do mapa do fluxo
de valor obtido atravs de uma viso holstica dos processos realizados na empresa
do estudo de caso, a pesquisa, anlise e utilizao de ferramentas open source para
automatizar tarefas at ento manuais e, o levantamento e documentao dos
requisitos que devem ser atendidos por um sistema para permitir a integrao de
ferramentas e a utilizao por pessoas com diferentes nveis tcnicos.
O prottipo desenvolvido demonstrou a viabilidade da proposta. Dessa forma todos
os envolvidos no processo de entrega conseguem acesso quilo que precisam e
quando precisam. A equipe de qualidade consegue implantar uma verso no
momento que desejar, agilizando o processo de validao junto ao cliente.
Desenvolvedores podem ver quais verses passaram por quais estgios do
processo de entrega e quais problemas foram encontrados, gerando um ciclo de
feedback curto e gerentes de projetos podem verificar e monitorar mtricas
fundamentais como tempo de ciclo e qualidade de software. Resultados obtidos
atravs
da
utilizao
de
prticas
inclusas
nas
metodologias
geis
de
desenvolvimento tais como a integrao contnua, gerncia de configurao, testes

automatizados, gerncia de infraestrutura e ambientes e a visualizao do fluxo de
trabalho atravs do quadro Kanban, permitindo identificar, otimizar e remover
gargalos para tornar o processo de entrega confivel, rpido e mais seguro.
As perspectivas futuras deste trabalho incluem ajustes no software construdo para
incorporar requisitos de qualidade necessrios a software profissionalmente
desenvolvido
tais
como
testes
automatizados,
verificao
automtica
de
complexidade de cdigo e documentao, atravs de comentrios no prprio cdigo

e a criao de uma pgina web para referncias e tambm a implementao das
funes no contempladas nessa verso do prottipo tais como a visualizao do
97
andamento do projeto pelo cliente, o formulrio para confirmao dos testes em

ambiente de aceitao e a aceitao de plugins desenvolvidos por terceiros e, o
teste de performance da ferramenta com a criao de vrios projetos e a
implantao da mesma na empresa onde foi realizado o estudo de caso para
observao dos resultados de melhoria alcanados.
98
REFERNCIAS
AGUIAR, G. de F.; PEINADO, J. Compreendendo o Kanban: Um ensino
interativo ilustrado. Curitiba: Da Vinci, 2007
ASTELS, D.; MILLER, G.; NOVAK, M. Extreme Programming: Guia Prtico. Rio de
Janeiro: Campus, 2002. 333 p.
BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML, So
Paulo: Campus, 2003.
BRANA, Hugo. Cubumber e Rspec, So Paulo: Casa do Cdigo, 2013.
CHACON, S.; STRAUB, B. Pro Git. San Francisco, California: Apress, 2014. 729 p.
DESENVOLVIMENTO GIL. Aprenda Sobre Desenvolvimento gil de Software.
2013. On-line. Disponvel em: <http://desenvolvimentoagil.com.br/>. Acesso em: 2
nov 2014.
DUVALL, Paul. Agile DevOps: O Achatamento do Processo de Reliase de
Software.
2012.
On-line.
Disponvel
em:
<http://www.ibm.com/developerworks/br/library/a-devops1/>. Acesso em: 17 out
2014
FADEL, A. L.; SILVEIRA, H. da M. Metodologias geis no Contexto de
Desenvolvimento de Software: XP, Scrum e Lean. 2010. 26f. Trabalho de
Concluso de Curso UNICAMP, Limeira, 2010.
FOWLER,
Martin.
Active
Record,
2010.
On-line.
Disponvel
em:
<http://www.martinfowler.com/eaaCatalog/activeRecord.html>. Acesso em: 23 nov.
2014.
FOWLER, Martin. Continuous Integration, 2006. On-line. Disponvel em:
<http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 09 nov.
2014.
FOWLER, Martin. Deployment Pipeline. 2013. On-line. Disponvel em:
<http://martinfowler.com/bliki/DeploymentPipeline.html>. Acesso em: 17 out 2014
FOWLER, Martin. The New Methodology, 2005. On-line. Disponvel em:
<http://www.martinfowler.com/articles/newMethodology.html#N8B>. Acesso em: 01
nov. 2014.
FUENTES, V. B. Ruby On Rails: Coloque sua aplicao nos trilhos. So Paulo:
Casa do Cdigo, 2014. 360 p.
GEORGE, M. RSpec: Crie especificaes executveis em Ruby. So Paulo:
Casa do Cdigo, 2014. 176 p.
HEIDI, Erika. Vagrant CookBook. Canada: Leanpub. 2014. 125 p.
HUMBLE, J.; FARLEY, D. Entrega Contnua: Como entregar software de forma
rpida e confivel. Porto Alegre: Bookman, 2014. 464 p.
HUMBLE, Jez. Continuous Delivery e o Movimento DevOps. 2011. On-line.
Disponvel em: <http://www.infoq.com/br/articles/jezhumble-continuous-deliverydevops/>. Acesso em: 10 out 2014.
99
HASHIMOTO, Mitchell. DevOps de zero a 100%: Nveis e passos de adoo.

2013. On-line. Disponvel em: <http://www.infoq.com/br/articles/wide-range-devops>.
Acesso em: 09 nov. 2014.
KNINGERG, H. Scrum e XP Direto das Trincheiras: Como ns fazemos Scrum,
So Paulo: C4Media, 2007. 131 p.
KNINGERG, H.; SKARIN, M. Kanban e Scrum: Obtendo o Melhor de Ambos, So
Paulo: C4Media, 2009. 139 p.
LOPES, Camilo. TDD na prtica. Rio de Janeiro: Cincia Moderna, 2012. 116 p.
MANIFESTO GIL. Manifesto para o Desenvolvimento gil de Software. 2001.
On-line. Disponvel em: <http://manifestoagil.com.br/ >. Acesso em: 27 out 2014.
MINA. Really fast deployer and server automation tool. On-line. Disponvel em:
<http://mina-deploy.github.io/mina/upgrading.html>. Acesso em: 28 nov 2014.
NGINX. Nginx Community. On-line. Disponvel em: < http://wiki.nginx.org/Main>.
Acesso em: 28 nov 2014.
POPPENDIECK, Mary; POPPENDIECK, Tom. Implementando o Desenvolvimento
Lean de Software: Do Conceito ao Dinheiro. Porto Alegre: Bookman, 2011. 259 p.
PRESSMAN, R. S. Engenharia de Software, So Paulo: McGraw-Hill, 2006. 720 p.
PUMA. Built For Speed & Concurrency. On-line. Disponvel em: <http://puma.io/>.
Acesso em: 28 nov 2014.
PUPPET LABS. Puppet Labs Documentation. On-line.
<https://docs.puppetlabs.com/>. Acesso em: 28 nov 2014.
Disponvel
em:
RAMOS, Ricardo A. Treinamento Prtico em UML. So Paulo: Digerati Books,

2006, 144 p.
SATO, Danilo. DevOps na Prtica: Entrega de Software Confivel e
Automatizada. So Paulo: Casa do Cdigo, 2013. 230 p.
SILVERMAN, R. E. Git: Guia Prtico. So Paulo: Novatec, 2013. 207 p.
SOUZA, Lucas. Ruby: Aprenda a programar na linguagem mais divertida. So
Paulo: Casa do Cdigo, 2014. 285 p.
TAVARES, B. Puppet e Vagrant: Como provisionar mquinas para seu projeto.
2013. On-line. Disponvel em: http://www.thoughtworks.com/pt/insights/blog/puppetand-vagrant-how-provision-machines-your-project. Acesso em: 09 nov. 2014.
TELES, Vincius Manhes. Extreme Programming. 2006. On-line. Disponvel em:
<http://desenvolvimentoagil.com.br/xp/>. Acesso em: 29 out 2014.
TELES, Vincius Manhes. Extreme Programming. So Paulo: Novatec Editora,
2004.
TONSING, S. L. MySQL: Aprendendo na Prtica. Rio de Janeiro: Editora Cincia
Moderna. 2006.
URUBATAN, Rodrigo. Ruby on Rails. So Paulo: Novatec Editora, 2012
VARASCHIM, J. D. Implantando o Scrum em um Ambiente de Desenvolvimento
de Produtos para Internet. 2009. 21f. Monografias em Cincia da Computao
PUC, Rio de Janeiro, 2009.
100
ANEXOS
ANEXO A Casos de Uso do Sistema Proposto
Descrio de Caso de Uso

Projeto: Ovenbird
Subsistema:
Caso de Uso: Principal
Analista: Leandro Souza Nunes.
Data: 27/11/2014
Descrio: Esse caso de uso tem por objetivo o gerenciamento das solicitaes de
cada cliente, a criao dos ambientes para implantao do SLV e o gerenciamento
das informaes dos interessados no desenvolvimento do sistema, o cliente e a
equipe de desenvolvimento (usurio).
O Ovenbird possui os seguintes atores:
GerenteProjetos: representa a pessoa responsvel por controlar o fluxo de
desenvolvimento das solicitaes de cada cliente;
Desenvolvedor: responsvel pelo desenvolvimento das solicitaes bem
como a configurao dos ambientes e a implantao da loja;
Qualidade: responsvel por efetuar testes no ambiente de aceitao para
validar a entrega do desenvolvimento junto ao cliente.
101

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso Principal
Caso de Uso: CadastrarGeral
Data: 27/11/2014
Descrio: Esse caso de uso tem por objetivo o gerenciamento de todas
informaes referente aos interessados no desenvolvimento da loja virtual, contendo
todos os cadastros necessrios para que o gerente de projetos possa administrar o
desenvolvimento na empresa estudada. Sendo assim, ser contemplado nesse
subsistema os casos de uso CadastrarUsuarios e CadastrarClientes.
102

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso CadastrarGeral
Caso de Uso: CadastrarUsuarios
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que o gerente de projetos

cadastra um usurio. Este processo separado em quatro cenrios: cadastrar,
alterar, excluir e consultar um usurio.
Caso de uso: CadastrarUsuario
Ator: GerenteProjetos
Pr-condies: No se aplica.
Ps-condies: No se aplica.
Fluxo Principal:
1. O ator solicita cadastrar um novo usurio.
2. O ator informa os dados necessrios (nome, e-mail, descrio (opcional),
telefone, login, senha e tipo) para cadastro do usurio.
3. O sistema verifica se as informaes so vlidas.
4. O sistema informa que o usurio foi cadastrada com sucesso.
Fluxo Alternativo:
3a. Dados necessrios invlidos
3a. 1 O sistema informa qual ou quais dados esto incorretos.
3a. 2 O sistema retorna ao Fluxo Normal passo 2.
Caso de uso: AlterarUsuario
Pr-condies: O usurio deve estar cadastrado.
103
Fluxo Principal:
1. O ator solicita alterar um usurio.
2. O ator informa os dados necessrios (nome, e-mail, descrio (opcional),
telefone, login, senha e tipo) para alterar o usurio.
4. O sistema informa que o usurio foi alterado com sucesso.
Fluxo Alternativo:
3a. 1 O sistema informa qual ou quais dados esto incorretos
Caso de uso: ExcluirUsuario
Fluxo Principal:
1. O ator solicita excluir um usurio
2. O ator informa o usurio a ser excludo.
3. O sistema verifica se o usurio existe.
4. O sistema pede confirmao para excluso do usurio.
5. O sistema informa que o usurio foi excludo com sucesso.
Fluxo Alternativo:
3a. Usurio informado no existe
3a. 1 O sistema informa que o usurio no existe.
Caso de uso: ConsultarUsuario
104
Fluxo Principal:
1. O ator solicita consultar um usurio.
2. O ator informa o usurio a ser consultado.
3. O sistema verifica se o usurio existe.
4. O sistema mostra as informaes do usurio consultado.
Fluxo Alternativo:
3a. O usurio informado no existe
3a. 1 O sistema informa que o usurio no existe.
105

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso CadastrarGeral
Caso de Uso: CadastrarClientes
Data: 27/11/2014

cadastra um cliente. Este processo separado em quatro cenrios: cadastrar,
alterar, excluir e consultar um usurio.
Caso de uso: CadastrarCliente
Pr-condies: No se aplica.
Fluxo Principal:
1. O ator solicita cadastrar um novo cliente.
2. O ator informa os dados necessrios (nome, e-mail, razo social, telefone)
para cadastro do cliente.
4. O sistema informa que o cliente foi cadastrado com sucesso.
Fluxo Alternativo:
Caso de uso: AlterarCliente
Pr-condies: O cliente deve estar cadastrado.
106
Fluxo Principal:
1. O ator solicita alterar um cliente.
2. O ator informa os dados necessrios (nome, e-mail, razo social, telefone)
para alterar o cliente.
4. O sistema informa que o cliente foi alterado com sucesso.
Fluxo Alternativo:
Caso de uso: ExcluirCliente
Fluxo Principal:
1. O ator solicita excluir um cliente
2. O ator informa o cliente a ser excludo.
3. O sistema verifica se o cliente existe.
4. O sistema pede confirmao para excluso do cliente.
5. O sistema informa que o cliente foi excludo com sucesso.
Fluxo Alternativo:
3a. Cliente informado no existe
3a. 1 O sistema informa que o cliente no existe.
107
Caso de uso: ConsultarCliente

Fluxo Principal:
1. O ator solicita consultar um cliente.
2. O ator informa o cliente a ser consultado.
3. O sistema verifica se o cliente existe.
4. O sistema mostra as informaes do cliente consultado.
Fluxo Alternativo:
3a. O cliente informado no existe
3a. 1 O sistema informa que o cliente no existe.
108

Projeto: Ovenbird
Caso de Uso: GerenciarAmbientes
Data: 27/11/2014
Descrio: Esse caso de uso tem por objetivo o gerenciamento de todas
informaes referente aos ambientes onde a loja virtual ser implantada, contendo
todos os cadastros necessrios para que o gerente de projetos e o desenvolvedor
possa administrar a entrega do sistema SLV. Sendo assim, ser contemplado nesse
subsistema
os
InstalarPuppet.
casos
de
uso
CadastrarAmbiente,
ProvisionarAmbiente
109

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso GerenciarAmbientes
Caso de Uso: CadastrarAmbiente
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que o gerente de projetos ou

o desenvolvedor cadastra um ambiente. Este processo separado em quatro
cenrios: cadastrar, alterar, excluir e consultar um ambiente.
Caso de uso: CadastrarAmbiente
Ator: GerenteProjetos e Desenvolvedor
Pr-condies: O cliente e o projeto devem estar cadastrados.
Ps-condies:
Habilita
os
botes
para
executar
os
casos
de
uso
ProvisionarAmbiente e InstalarPuppet na tela.

Fluxo Principal:
1. O ator solicita cadastrar um novo ambiente.
2. O ator informa os dados necessrios (tipo, descrio, url, ip, usurio e
senha) para cadastro do ambiente.
4. O sistema informa que o ambiente foi cadastrado com sucesso.
Fluxo Alternativo:
110
Caso de uso: AlterarAmbiente

Pr-condies: O ambiente deve estar cadastrado.
Fluxo Principal:
1. O ator solicita alterar um cliente.
2. O ator informa os dados necessrios (tipo, descrio, url, ip, usurio e
senha) para alterar o ambiente.
4. O sistema informa que o ambiente foi alterado com sucesso.
Fluxo Alternativo:
Caso de uso: ExcluirAmbiente
Fluxo Principal:
1. O ator solicita excluir um ambiente
2. O ator informa o ambiente a ser excludo.
3. O sistema verifica se o ambiente existe.
4. O sistema pede confirmao para excluso do ambiente.
5. O sistema informa que o ambiente foi excludo com sucesso.
Fluxo Alternativo:
3a. Ambiente informado no existe
3a. 1 O sistema informa que o ambiente no existe.
111
Caso de uso: ConsultarAmbiente

Fluxo Principal:
1. O ator solicita consultar um ambiente.
2. O ator informa o ambiente a ser consultado.
4. O sistema mostra as informaes do ambiente consultado.
Fluxo Alternativo:
3a. O ambiente informado no existe
112

Projeto: Ovenbird
Caso de Uso: InstalarPuppet
Data: 27/11/2014

o desenvolvedor executa o processo para instalar o Puppet Client no novo ambiente.
Este processo descrito no caso de uso InstalarPuppet.
Caso de uso: InstalarPuppet
Fluxo Principal:
4. O sistema mostra o boto Configurar.
5. O ator clica no boto para executar o processo de instalao.
6. O sistema informa que o ambiente foi configurado com sucesso.
Fluxo Alternativo:
3b. Informaes de acesso ao ambiente erradas
3b. 1 O sistema informa que no conseguir acessar o ambiente.
3b. 2 O sistema retorna ao Fluxo Normal passo 4.
113

Projeto: Ovenbird
Caso de Uso: InstalarPuppet
Data: 27/11/2014

o desenvolvedor executa o processo para provisionar o novo ambiente. Este
processo descrito no caso de uso ProvisionarAmbiente.
Caso de uso: ProvisionarAmbiente
Fluxo Principal:
4. O sistema mostra o boto Provisionar.
5. O ator clica no boto para executar o processo de provisionamento.
6. O sistema informa que o ambiente foi provisionado com sucesso.
Fluxo Alternativo:
3b. Informaes de acesso ao ambiente erradas
3b. 1 O sistema informa que no conseguir acessar o ambiente.
3b. 2 O sistema retorna ao Fluxo Normal passo 4.
114

Projeto: Ovenbird
Caso de Uso: GerenciarSolicitacoes
Data: 27/11/2014
Descrio: Esse caso de uso tem por objetivo o gerenciamento de todas as
solicitaes de um cliente que devero ser atendidas, contendo todos os cadastros
necessrios para que os atores possam administrar o desenvolvimento na empresa
estudada. Sendo assim, ser contemplado nesse subsistema os casos de uso
CadastrarProjeto,
CadastrarSolicitacao,
IniciarDesenvolvimento,
EnviarParaVerificacao,
AgruparSolicitacoesSprint,
ExecutarTestesAutomatizados,
DisponibilizarVersaoEmAceitacao e ImplantarVersaoEmProducao.
115

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso GerenciarSolicitacoes
Caso de Uso: CadastrarProjeto
Data: 27/11/2014

cadastra um ambiente. Este processo separado em quatro cenrios: cadastrar,
alterar, excluir e consultar um projeto.
Caso de uso: CadastrarProjeto
Fluxo Principal:
1. O ator solicita cadastrar um novo projeto.
2. O ator informa os dados necessrios (cliente, nome e url do repositrio)
para cadastro do projeto.
4. O sistema informa que o projeto foi cadastrado com sucesso.
Fluxo Alternativo:
116
Caso de uso: AlterarProjeto

Pr-condies: O projeto deve estar cadastrado.
Fluxo Principal:
1. O ator solicita alterar um projeto.
2. O ator informa os dados necessrios (cliente, nome e url do repositrio)
para alterar o ambiente.
4. O sistema informa que o projeto foi alterado com sucesso.
Fluxo Alternativo:
Caso de uso: ExcluirProjeto
Fluxo Principal:
1. O ator solicita excluir um projeto
2. O ator informa o projeto a ser excludo.
3. O sistema verifica se o projeto existe.
4. O sistema pede confirmao para excluso do projeto.
5. O sistema informa que o projeto foi excludo com sucesso.
Fluxo Alternativo:
3a. O projeto informado no existe
3a. 1 O sistema informa que o projeto no existe.
117
Caso de uso: ConsultarProjeto

Fluxo Principal:
1. O ator solicita consultar um projeto.
2. O ator informa o projeto a ser consultado.
3. O sistema verifica se o projeto existe.
4. O sistema mostra as informaes do projeto consultado.
Fluxo Alternativo:
3a. 1 O sistema informa que o projeto no existe.
118

Projeto: Ovenbird
Caso de Uso: CadastrarSolicitacao
Data: 27/11/2014

o desenvolvedor cadastra uma solicitao. Este processo separado em quatro
cenrios: cadastrar, alterar, excluir e consultar um projeto.
Caso de uso: CadastrarSolicitacao
Fluxo Principal:
1. O ator solicita cadastrar uma nova solicitao.
2. O ator informa os dados necessrios (nome, data de incio, data da
finalizao e descrio) para cadastro de uma solicitao.
4. O sistema informa que a solicitao foi cadastrada com sucesso.
Fluxo Alternativo:
119
Caso de uso: AlterarSolicitacao

Pr-condies: A solicitao deve estar cadastrada.
Fluxo Principal:
1. O ator solicita alterar uma solicitao.
2. O ator informa os dados necessrios (nome, data de incio, data da
finalizao e descrio) para alterar a solicitao.
4. O sistema informa que a solicitao foi alterada com sucesso.
Fluxo Alternativo:
Caso de uso: ExcluirSolicitacao
Ator: GerenteProjetos e Desenvolvedor.
Pr-condies: A solicitao deve estar cadastrado.
Fluxo Principal:
6. O ator solicita excluir uma solicitao.
7. O ator informa a solicitao a ser excluda.
8. O sistema verifica se a solicitao existe.
9. O sistema pede confirmao para excluso da solicitao.
10. O sistema informa que a solicitao foi excluda com sucesso.
Fluxo Alternativo:
3a. 1 O sistema informa que a solicitao no existe.
120
Caso de uso: ConsultarSolicitacao

Ator: GerenteProjetos e Desenvolvedor.
Pr-condies: A solicitao deve estar cadastrado.
Fluxo Principal:
1. O ator solicita consultar uma solicitao.
2. O ator informa a solicitao a ser consultada.
3. O sistema verifica se a solicitao existe.
4. O sistema mostra as informaes da solicitao consultada.
Fluxo Alternativo:
3a. A solicitao informada no existe
3a. 1 O sistema informa que a solicitao no existe.
121

Projeto: Ovenbird
Caso de Uso: AgruparSolicitacoesSprint
Data: 27/11/2014

agrupa as solicitao que sero desenvolvidas na prxima Sprint.
Caso de uso: AgruparSolicitacoesSprint
Pr-condies: A solicitao deve estar cadastrada.
Fluxo Principal:
2. O ator move a solicitao da coluna Solicitaes para a coluna A Faze.
3. O sistema atualiza o status da solicitao.
122

Projeto: Ovenbird
Caso de Uso: IniciarDesenvolvimento
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que o desenvolvedor informa

qual a funcionalidade que ele ir desenvolver.
Caso de uso: IniciarDesenvolvimento
Ator: Desenvolvedor
Pr-condies: A solicitao deve estar na coluna A Fazer.
Fluxo Principal:
2. O ator move a solicitao da coluna A Fazer para a coluna Fazendo.
123

Projeto: Ovenbird
Caso de Uso: EnviarParaVerificacao
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que o desenvolvedor informa

a solicitao que acabou de desenvolver e libera a mesma para testes.
Caso de uso: EnviarParaVerificacao
Ator: Desenvolvedor
Pr-condies: A solicitao deve estar na coluna Fazendo
Fluxo Principal:
2. O ator adiciona o cdigo do Git na solicitao.
3. O ator move a solicitao da coluna Fazendo para a coluna Teste Unit.
124

Projeto: Ovenbird
Caso de Uso: ExecutarTestesAutomatizados
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que o SIC inicia o processo
de testes da solicitao informada.
Caso de uso: ExecutarTestesAutomatizados
Ator: SIC
Pr-condies: A solicitao deve estar na coluna Teste Unit.
Fluxo Principal:
1. O ator verificar se a solicitao est no repositrio de cdigo.
2. O ator faz o check-in no repositrio.
3. O ator executa os testes automatizados.
4. O sistema atualiza o status da solicitao em cada etapa dos testes.
125

Projeto: Ovenbird
Caso de Uso: DisponibilizarVersaoEmAceitacao
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que uma solicitao

instalado no ambiente de aceitao.
Caso de uso: DisponibilizarVersaoEmAceitacao
Ator: GerenteProjetos, Desenvolvedor, Qualidade
Pr-condies: A solicitao deve estar na coluna Aceitao.
Fluxo Principal:
2. O ator clica no boto para iniciar o processo.
3. O sistema executa a ferramenta de implantao.
126

Projeto: Ovenbird
Caso de Uso: ImplantarVersaoEmProducao
Data: 27/11/2014
Descrio: Este caso de uso descreve o processo em que uma solicitao

instalado no ambiente de aceitao.
Caso de uso: ImplantarVersaoEmProducao
Ator: GerenteProjetos, Desenvolvedor, Qualidade
Pr-condies: A solicitao deve estar na coluna Produo.
Fluxo Principal:
2. O ator clica no boto para iniciar o processo.
3. O sistema executa a ferramenta de implantao.

TCC - Automatização de Entrega de Software em Ambiente Ágil de Desenvolvimento

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC - Automatização de Entrega de Software em Ambiente Ágil de Desenvolvimento

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAO DE ASSISTNCIA E EDUCAO FAESA

FACULDADES INTEGRADAS ESPRITO-SANTENSE

LEANDRO SOUZA NUNES

AUTOMATIZAO DE ENTREGA DE SOFTWARE EM

LEANDRO SOUZA NUNES

AUTOMATIZAO DE ENTREGA DE SOFTWARE EM

Trabalho de Concluso de Curso de

LEANDRO SOUZA NUNES

Trabalho de Concluso do Curso de Graduao em Cincias da Computao

AUTOMATIZAO DE ENTREGA DE SOFTWARE EM

Denise Franzotti Togneri

Eliana Cus Sampaio

Daniel Barbosa Oliveira

Vitria, 10 de dezembro de 2014

QUADRO 1 REQUISITOS NO FUNCIONAIS. ................................................................... 55

FIGURA 25 TELA DO PIPELINE DE IMPLANTAO NA FERRAMENTA GO. ........................... 62

FIGURA 31 DIAGRAMA DE SEQUNCIA INCLUIRSOLICITACAO. ........................................ 70

2.9.2 Objetivos para utilizao do pipeline ......................................................... 40

5.1.3.3 Componente de Gerncia de Tarefa (CGT) ....................................... 78

de desenvolvimento e permitindo implantar o sistema para qualquer ambiente

1.2 FORMULAO DO PROBLEMA

DevOps um movimento que busca difundir a colaborao entre os envolvidos no

Investigar o fluxo de desenvolvimento de software para a elaborao de uma

Investigar a integrao de ferramentas para automatizar os processos de

Possibilitar a comunicao entre cliente e equipe de desenvolvimento

Permitir a integrao contnua de cdigo de forma automatizada, reduzindo o

Possibilitar a execuo do sistema durante o processo de desenvolvimento

Realizar o gerenciamento de configuraes e dependncias;

Desenvolver um sistema online para que todos os envolvidos possam efetuar

desenvolvimento inclusas nas metodologias geis, e do pipeline de implantao para

desenvolvimento essenciais para o desenvolvimento deste trabalho.

2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE GIL

Indivduos e interaes mais que processos e ferramentas;

Software em funcionamento mais que documentao abrangente;

Colaborao com o cliente mais que negociao de contratos;

Responder a mudanas mais que seguir um plano.

Os processos geis de desenvolvimento de software compartilham um conjunto de

difcil prever antecipadamente quais requisitos de software vo persistir e

Para muitos tipos de software, o projeto e a construo so intercalados, ou

Anlise, projeto, construo e testes no so to previsveis (do ponto de

2.2 EXTREME PROGRAMMING

Jogo de Planejamento: nesta prtica existe uma grande interao entre o

Releases Curtos: um incremento simples e funcional gerado rapidamente

Metfora: elaborada uma descrio para permitir que todos os envolvidos

envolvidos a compreender os elementos bsicos do sistema e seus

Projeto Simples: o sistema deve ser projetado da forma mais simples, de

Desenvolvimento Guiado por Testes: o desenvolvimento do software de

Refatorao: o ato de alterar um cdigo sem afetar a funcionalidade que

Programao em Par: dois programadores escrevem o cdigo em um nico

Cdigo Coletivo: qualquer programador pode alterar qualquer parte do

Integrao Contnua: uma nova funcionalidade pode afetar outras que j

Cliente Presente: a XP trabalha com a premissa que o cliente deve conduzir

Cdigo Padronizado: os programadores escrevem todo o cdigo de acordo

Ritmo Sustentvel: a qualidade do design, do cdigo, das metforas e do

A Figura 1 permite uma visualizao do agrupamento das prticas aplicadas com a

implementado logo no incio do projeto e vai ganhando novas funcionalidades ao

Figura 2 Fluxo de processo utilizando Scrum.

Varaschim (2009, p. 3) descreve o ciclo de desenvolvimento onde a primeira etapa

Scrum Master: atua como facilitador do Daily Meeting e torna-se responsvel

Scrum Team: a equipe de desenvolvimento. responsvel por atingir os

Product Owner: o cliente de um time Scrum, sendo responsvel pelo

A responsabilidade pela qualidade do produto do time, que tem o dever de verificar

Sprint Planning: a primeira atividade dentro de uma Sprint; uma reunio