Automatizacao de Entrega de Software em

FUNDAÇÃO DE ASSISTÊNCIA E EDUCAÇÃO – FAESA
FACULDADES INTEGRADAS ESPÍRITO-SANTENSE

CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
LEANDRO SOUZA NUNES
AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM

AMBIENTE ÁGIL DE DESENVOLVIMENTO
VITÓRIA
2014
LEANDRO SOUZA NUNES

Trabalho de Conclusão de Curso de

Graduação em Ciência da Computação
apresentado às Faculdades Integradas
Espírito-santenses, como requisito parcial
para obtenção do título de Bacharel em
Ciência da Computação, sob orientação da
profa. Denise Franzotti Togneri.
VITÓRIA
2014
LEANDRO SOUZA NUNES
Trabalho de Conclusão do Curso de Graduação em Ciências da Computação

apresentado às Faculdades Integradas Espírito-santenses (FAESA), como requisito
parcial para obtenção do título de Bacharel em Ciência da Computação.

BANCA EXAMINADORA
Denise Franzotti Togneri

Orientadora
Eliana Cáus Sampaio
Daniel Barbosa Oliveira
Vitória, 10 de dezembro de 2014

RESUMO
Software, por mais complexo que seja, não gera lucro ou valor até que esteja nas
mãos de seus usuários. A empresa objeto do estudo de caso deste trabalho está
sediada em Vitória ES e é especializada em soluções para lojas virtuais (SLV) que
são 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
práticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de
desenvolvimento a execução manual de tarefas importantes do processo de
desenvolvimento associa-se diretamente com o não cumprimento de prazos e a
baixa qualidade do software entregue. Diante desse cenário, este trabalho realiza
uma pesquisa das boas práticas de desenvolvimento de software para efetuar a
entrega contínua de valor ao cliente e propõe o desenvolvimento de um sistema
para realizar a automatização dos processos com o auxílio de ferramentas testadas
e validadas há décadas pela comunidade open source tais como Puppet, Git, Mina,
Jenkins, RSpec e Cucumber. O processo de entrega é descrito através do padrão
Pipeline de Implantação, permitindo a automatização desde o desenvolvimento até a
entrega do software ao usuário final. O sistema desenvolvido tem o objetivo de
permitir que a equipe de desenvolvimento responda às mudanças de forma eficiente,
aumente a capacidade de gerar novas versões bem-sucedidas e de liberá-las sob
demanda e de implantar o seu sistema de loja virtual em qualquer ambiente
instantaneamente, refletindo as mudanças de uma forma eficiente e com baixo
custo. Este sistema foi desenvolvido utilizando-se o paradigma da orientação a
objetos e a linguagem de notação UML – Unified Modeling Language para a
modelagem. O protótipo foi desenvolvido na linguagem de programação Ruby, o
framework RubyOnRails e o SGBD MySQL. Este trabalho contribuiu para o
entendimento do mapa do fluxo de valor dos processos realizados na empresa do
estudo de caso, documentou os requisitos que devem ser atendidos por um sistema
de apoio à automatização da entrega de software em ambiente ágil de
desenvolvimento e o protótipo desenvolvido demonstrou a viabilidade da proposta.
Palavras-chave: Entrega Contínua de Software. Provisionamento de ambientes.

Integração Contínua. Metodologias Ágeis. Pipeline de Implantação.
LISTA DE QUADROS

QUADRO 1 – REQUISITOS NÃO FUNCIONAIS. ................................................................... 55
QUADRO 2 – FERRAMENTAS UTILIZADAS. ....................................................................... 60
QUADRO 3 – COMPARATIVO OVENBIRD X GO X TOOL CLOUD X TRELLO. ........................ 64
QUADRO 4 – DICIONÁRIO DE DADOS DO SISTEMA OVENBIRD............................................ 67
QUADRO 5 – DICIONÁRIO DE DADOS DO SISTEMA OVENBIRD............................................ 68
LISTA DE FIGURAS
FIGURA 1 – AGRUPAMENTO DAS PRÁTICAS DA XP. ......................................................... 20

FIGURA 2 – FLUXO DE PROCESSO UTILIZANDO SCRUM. ................................................... 22
FIGURA 3 – EXEMPLO DE UM GRÁFICO BURNDOWN CHAT. ............................................... 25
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 VERSÃO LOCAL............................................... 28
FIGURA 7 – DIAGRAMA DE UM SISTEMA DE VERSÃO CENTRALIZADO. ................................. 29
FIGURA 8 – DIAGRAMA DE UM SISTEMA DE VERSÃO DISTRIBUÍDO...................................... 30
FIGURA 9 – QUATRO QUADRANTE DE TESTES DESCRITOS POR BRIAN MARICK. ................. 33
FIGURA 10 – CICLO DO TDD ......................................................................................... 35
FIGURA 11 – PROCESSO DE INTEGRAÇÃO CONTÍNUA COM O AUXILIO DE FERRAMENTAS. .... 36
FIGURA 12 - UM EXEMPLO DE MAPA DE FLUXO DE VALOR SIMPLES PARA UM PRODUTO ....... 37
FIGURA 13 - MUDANÇAS SE MOVENDO POR UM PIPELINE DE IMPLANTAÇÃO. ...................... 39
FIGURA 14 – EQUIPES ENVOLVIDAS NO MOVIMENTO DEVOPS. ......................................... 42
FIGURA 15 - MAPA DO FLUXO DE VALOR DA EMPRESA OBJETO DESTE ESTUDO. ................. 44
FIGURA 16 – MOVIMENTAÇÃO ATUAL DAS SOLICITAÇÕES 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 - UTILIZAÇÃO DO PUPPET PELO SISTEMA OVENBIRD. ...................................... 57
FIGURA 23 - QUADRO KANBAN NO SISTEMA OVENBIRD. .................................................. 59
FIGURA 24 - FLUXO DO GERENCIAMENTO DO SISTEMA PELOS DESENVOLVEDORES APÓS A
APLICAÇÃO DAS SOLUÇÕES PROPOSTAS. ................................................................ 61
FIGURA 25 – TELA DO PIPELINE DE IMPLANTAÇÃO NA FERRAMENTA GO. ........................... 62
FIGURA 26 – PAINEL DE INSTALAÇÃO DA TOOLS CLOUD. ................................................. 63
FIGURA 27 – QUADRO DO TRELLO. ................................................................................ 64
FIGURA 28 – DIAGRAMA DE CLASSES DE ANÁLISE DO SISTEMA OVENBIRD......................... 66
FIGURA 29 – DIAGRAMA DE SEQUÊNCIA INCLUIRNOVOAMBIENTE. .................................... 69
FIGURA 30 – DIAGRAMA DE SEQUÊNCIA CADASTRARPROJETO. ........................................ 69
FIGURA 31 – DIAGRAMA DE SEQUÊNCIA INCLUIRSOLICITACAO. ........................................ 70
FIGURA 32 – DIAGRAMA DE SEQUÊNCIA GERARNOVAIMPLANTAÇÃO. ................................ 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 NAVEGAÇÃO DO ATOR GERENTEPROJETOS. ............................ 75
FIGURA 37 – PROJETO DE NAVEGAÇÃO DO ATOR DESENVOLVEDOR. ................................ 75
FIGURA 38 – PROJETO DE NAVEGAÇÃO DO ATOR QUALIDADE. ......................................... 75
FIGURA 39 – COMPONENTE DO DOMÍNIO DO PROBLEMA. ................................................ 77
FIGURA 40 – COMPONENTE DE GERÊNCIA DE TAREFA. ................................................... 79
FIGURA 41 – DIAGRAMA RELACIONAL DE DADOS. ............................................................ 81
FIGURA 42 – TELA PARA VISUALIZAÇÃO DOS USUÁRIOS CADASTRADOS. ........................... 88
FIGURA 43 – TELA PARA CADASTRO DE USUÁRIOS. ......................................................... 89
FIGURA 44 – TELA PARA VISUALIZAÇÃO 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 IMPLANTAÇÃO. .......................................................... 93
FIGURA 52 – TELA PARA CADASTRO DE SOLICITAÇÃO. ..................................................... 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 integração Contínua
SQL – Structured Query Language
TDD – Test Driven Development
URL – Uniform Resource Locator
VCS – Version Control System
XP – Extreme Programming
WEB – Wolrd Wide Web

SUMÁRIO
1. INTRODUÇÃO ...................................................................................................... 11
1.1 O PROBLEMA ................................................................................................. 12
1.2 FORMULAÇÃO DO PROBLEMA ................................................................... 13
1.3 HIPÓTESE ....................................................................................................... 13
1.4 OBJETIVOS..................................................................................................... 13
1.4.1 Gerais ........................................................................................................ 13
1.4.2 Específicos ................................................................................................ 14
1.5 JUSTIFICATIVA .............................................................................................. 14
1.6 METODOLOGIA .............................................................................................. 15
1.7 ORGANIZAÇÃO DA MONOGRAFIA .............................................................. 15
2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL ................... 16

2.1 MANIFESTO ÁGIL .......................................................................................... 16
2.2 EXTREME PROGRAMMING........................................................................... 18
2.2.1 Práticas da XP ........................................................................................... 18
2.2.2 Adoção da XP............................................................................................ 20
2.3 SCRUM ............................................................................................................ 21
2.3.1 Papéis 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.................................................. 26
2.5 SISTEMA DE CONTROLE DE VERSÃO ....................................................... 27
2.5.1 Sistemas de Controle de Versão Locais ................................................... 27
2.5.2 Sistemas de Controle de Versão Centralizados ........................................ 28
2.5.3 Sistemas de Controle de Versão Distribuídos ........................................... 29
2.6 GERÊNCIA DE CONFIGURAÇÃO ................................................................. 30
2.6.1 Provisionamento ........................................................................................ 31
2.7 TESTES AUTOMATIZADOS........................................................................... 32
2.7.1 Desenvolvimento guiado por testes .......................................................... 34
2.8 INTEGRAÇÃO CONTÍNUA ............................................................................. 35
2.9 PIPELINE DE IMPLANTAÇÃO ....................................................................... 36
2.9.1 Como criar um pipeline de implantação inicial .......................................... 39
2.9.2 Objetivos para utilização do pipeline ......................................................... 40
2.10 MOVIMENTO DEVOPS ................................................................................. 41
3. UMA PROPOSTA PARA AUTOMATIZAÇÃO 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 NÃO FUNCIONAIS................................................................... 55
3.4 PROPOSTA DE SOLUÇÃO ............................................................................ 56
3.4.1 Proposta de solução para a Gerência de Ambientes ................................ 56
3.4.2 Proposta de solução para a Gerência de Solicitações .............................. 58
3.5 TRABALHOS CORRELATOS ........................................................................ 61
3.5.1 Go Continuous Delivery............................................................................. 62
3.5.2 Tools Clound ............................................................................................. 62
3.5.3 Trello.......................................................................................................... 63
3.5.4 Quadro Comparativo ................................................................................. 64
4. ANÁLISE ORIENTADA A OBJETOS ................................................................... 65

4.1 DIAGRAMA DE CLASSES ............................................................................. 65
4.2 DICIONÁRIO DE DADOS................................................................................ 67
4.3 DIAGRAMAS DE SEQÜÊNCIA....................................................................... 68
4.4 DIAGRAMA DE ESTADO ............................................................................... 70
5. PROJETO E IMPLEMENTAÇÃO ......................................................................... 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 aplicação web............................................. 73
5.1.2.2 Projeto de navegação ......................................................................... 74
5.1.3 Projeto de componente ............................................................................. 76
5.1.3.1 Componente de Domínio do Problema (CDP).................................... 76
5.1.3.2 Componente de Interação Humana (CIH) .......................................... 78
5.1.3.3 Componente de Gerência de Tarefa (CGT) ....................................... 78
5.1.3.4 Componente de Gerência de Dados (CGD) ....................................... 80
5.1.4 Projeto relacional de dados ....................................................................... 80
5.2 IMPLEMENTAÇÃO DO PROTÓTIPO ............................................................. 81
5.2.1 Tecnologias utilizadas no protótipo ........................................................... 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 RESTRIÇÕES DE IMPLEMENTAÇÃO ........................................................... 87
5.4 INSTALAÇÃO E FUNCIONAMENTO DO PROTÓTIPO................................. 87
5.5 INTERFACE COM O USUÁRIO ...................................................................... 88
6. CONCLUSÃO PERSPECTIVAS FUTURAS......................................................... 95
REFERÊNCIAS ......................................................................................................... 97
ANEXOS.................................................................................................................... 99
11
1. INTRODUÇÃO
Com a globalização e o aumento ao acesso à banda larga, o mundo vive uma

interação em tempo real. Ideias, tendências, necessidades, informações, dentre
outros, navegam de continente a continente em uma velocidade jamais imaginada,
tendo o software como parte fundamental desse processo. Desenvolver software
nesse cenário requer um processo onde uma ideia na mente do cliente vire código
funcional e esteja disponível para o usuário final de maneira rápida e confiável. O
tempo para efetuar o processo de entrega de software pode determinar o rumo dos
negócios junto a concorrência.
Desde 1980, autores como Kent Beck, Martin Fowler, Paul Duvall, Ron Jeffries e
Dave Thomas, estudam práticas de desenvolvimento de software com o objetivo de
poder fornecer ao mundo alternativas melhores que as tradicionais, que são
altamente dirigidas por documentação. Conforme os 12 princípios do Manifesto Ágil
(2001), o software em funcionamento tem maior valor do que uma documentação
abrangente e software funcional é a medida primária do progresso. Software que
não esteja em produção, fazendo o que deveria fazer, não tem valor algum para o
negócio.
Humble e Farley (2014, p. 3) fazem três perguntas que permitem ter um enfoque em
aspectos do ciclo de vida de um software que, segundo eles, normalmente são
vistos como secundários: O que acontece depois da identificação dos requisitos,
projeto, desenvolvimento e teste das soluções? Como unir e coordenar todas essas
atividades para tornar o processo tão eficiente e confiável quanto possível durante
sua execução? Como fazer desenvolvedores, testadores e pessoal de operação
trabalharem juntos de maneira eficiente?
O objetivo da automatização de processos é tornar a entrega de software confiável,

previsível, com riscos quantificáveis e bem entendidos, garantindo que quando for
preciso fazer alguma modificação, o tempo para realizá-las, colocá-las em produção
e em uso, seja o menor possível e, que problemas sejam encontrados cedo o
bastante para que sejam fáceis de corrigir. Isso permite que todos os envolvidos
possam executar tarefas (que até então são manuais) de forma eficiente e repetível,
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 mudanças de uma forma eficiente e com baixo
custo.
1.1 O PROBLEMA
Uma empresa sediada em Vitória ES é especializada em soluções para lojas virtuais

(SLV) que são 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 práticas da XP, do Scrum e do Kanban. No entanto, durante o ciclo de
desenvolvimento a execução manual de tarefas importantes do processo de
desenvolvimento associa-se diretamente com o não cumprimento de prazos e a
baixa qualidade do software entregue.
A forma como os processos relacionados ao desenvolvimento de software são

executados pela equipe não permite o atendimento das solicitações dos clientes de
maneira satisfatória. Diversos problemas ocorrem durante o desenvolvimento, tais
como: os desenvolvedores codificam as funcionalidades em seus ambientes de
desenvolvimento paralelamente, mas não há controle sobre as versões das
ferramentas utilizadas e os testes automatizados são executados várias vezes ao
dia no próprio computador do desenvolvedor, deixando-o sem poder continuar
trabalhando em outras atividades por um período de 15 min a cada execução.
No término do ciclo de desenvolvimento, o sistema terá uma versão disponibilizada

para o usuário final em outro ambiente. O processo de levar o código do repositório
até o usuário é demorado e possibilita a presença de erros se cada passo não for
executado perfeitamente;
Implantar novos códigos ao sistema da loja já em funcionamento é extremamente

crítico e erros podem ser incluídos gerando perda financeira aos negócios. Em
muitos casos, é preciso esperar a próxima madrugada para fazer a junção da
funcionalidade que já está pronta.
13
1.2 FORMULAÇÃO DO PROBLEMA
Como coordenar atividades relacionadas com a entrega de software, tais como a

integração de código, a criação de ambientes, a implantação do sistema e a
validação e verificação dos requisitos, para permitir que processos complexos sejam
executados de forma confiável e repetível através da colaboração de todos os
envolvidos no processo de desenvolvimento?
1.3 HIPÓTESE
Para apoiar a solução dos problemas levantados, uma proposta de solução é o

desenvolvimento de uma ferramenta que permita a utilização de práticas de
desenvolvimento de software incluídas 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 padrão Pipeline
de Implantação para automatizar o fluxo do desenvolvimento de software até a sua
entrega, realizando para isso, a integração de ferramentas já existentes no mercado.
Dessa forma, as atividades de toda equipe de desenvolvimento seria centralizada,
dando uma visão do estado atual do sistema a todos os envolvidos e fomentando as
práticas do movimento DevOps 1 para criar um relacionamento colaborativo entre as
equipes de desenvolvimento, qualidade, operações e o próprio cliente.
1.4 OBJETIVOS
1.4.1 Gerais
Construir um software capaz de integrar ferramentas, técnicas e boas práticas que

possam ajudar a implementar um padrão passível de automatização para o
desenvolvimento de sistemas web, melhorando com isso o feedback de modo que
os problemas sejam identificados e resolvidos o mais cedo possível, proporcionando
a redução do custo de desenvolvimento e fazendo com que a entrega do software
seja de maneira confiável e repetível.
1
DevOps é um movimento que busca difundir a colaboração entre os envolvidos no
desenvolvimento de software e será abordado na seção 2.10.
14
1.4.2 Específicos
• Investigar o fluxo de desenvolvimento de software para a elaboração de uma

pipeline de implantação;
• Investigar a integração de ferramentas para automatizar os processos de
entrega de software;
• Possibilitar a comunicação entre cliente e equipe de desenvolvimento
continuamente;
• Permitir a integração contínua de código de forma automatizada, reduzindo o
desperdício de homem-hora;
• Possibilitar a execução do sistema durante o processo de desenvolvimento
em ambientes similares ao servidor de hospedagem;
• Realizar o gerenciamento de configurações e dependências;
• Desenvolver um sistema online para que todos os envolvidos possam efetuar
suas atividades de forma simples, rápida e confiável.
1.5 JUSTIFICATIVA
Software escrito que não é entregue ao cliente não tem valor algum, mesmo que
seja uma aplicação das mais complexas que se pode codificar. A automação de
implantações permite que novas entregas sejam feitas ou revertidas com o apertar
de um botão. Práticas tais como utilizar o mesmo processo de implantação em cada
ambiente e automatizar a gestão de ambientes, de dados e da infraestrutura são
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, não funcionais ou de configuração) sejam descobertos muitos
antes de uma entrega (HUMBLE; FARLEY, 2014, p. 422).
Com o desenvolvimento de um software para a integração de ferramentas,

automatizam-se os processos de forma que todos os envolvidos possam executar
tarefas (que até então são manuais) com facilidade, aumentando a produtividade e a
quantidade de entregas de valor dentro de um ciclo, sendo possível instalar o
sistema em qualquer ambiente instantaneamente, refletindo as mudanças para a
equipe de testes e o cliente de uma forma eficiente e com baixo custo.
15
1.6 METODOLOGIA
Inicialmente será feita uma revisão bibliográfica sobre as práticas de

desenvolvimento inclusas nas metodologias ágeis, e do pipeline de implantação para
mapear os processos relacionados com a entrega de software. Em sequência, um
estudo sobre as ferramentas de apoio será realizado, efetuando a integração entre
elas. Com isso, serão levantados os requisitos, documentando-os através de casos
de uso para modelar a ferramenta proposta. A análise e o projeto serão feitos
utilizando-se o paradigma da orientação a objetos e seu protótipo será construído
utilizando-se a linguagem de programação Ruby.
1.7 ORGANIZAÇÃO DA MONOGRAFIA
Este trabalho contém, além desta Introdução, mais 5 capítulos.
O capítulo 2 – METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL –

apresenta uma visão geral das metodologias ágeis e das práticas de
desenvolvimento essenciais para o desenvolvimento deste trabalho.
O capítulo 3 – PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE

SOFTWARE – apresenta o estudo de caso e descreve os requisitos funcionais da
ferramenta a ser contruída através de casos de uso.
O capítulo 4 – ANÁLISE ORIENTADA A OBJETOS – apresenta a análise orientada

a objetos da ferramenta proposta.
O capítulo 5 – PROJETO E IMPLEMENTAÇÃO – mostra como será projetada e

implementada a ferramenta proposta.
O capítulo 6 – CONCLUSÃO PERSPECTIVAS FUTURAS – onde são apresentadas

as conclusões e perspectivas futuras do trabalho.
16
2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL
Este capítulo contextualiza o surgimento das metodologias ágeis utilizadas em

ambiente de desenvolvimento de software, abordando suas principais características
e princípios que proporcionaram sua adoção por diversas empresas nos últimos
anos. Um conjunto de boas práticas de desenvolvimento testadas e validadas por
diversos autores são analisadas, com o objetivo de permitir efetuar a entrega de
software com maior qualidade em um curto período e promover a comunicação 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 documentação (LOPES, 2012, p. 16). Segundo Pressman (2006, p. 58),
em essência, os métodos ágeis foram desenvolvidos em um esforço para vencer as
fraquezas percebidas e reais da Engenharia de Software convencional.
Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um
projeto de software ter sucesso, cada qual com as suas particularidades, todos
concordavam que, em suas experiências prévias, um pequeno conjunto de
princípios sempre parecia ter sido respeitado quando os projetos davam certo.
Com base nesses princípios surgiu o Manifesto Ágil (2001), Ele valoriza a
importância da interação entre os envolvidos e a entrega de software de valor ao
cliente a curto prazo e conta com doze princípios. Os quatro valores defendidos pelo
manifesto ágil são:
• Indivíduos e interações mais que processos e ferramentas;

• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças 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 três
suposições chave que são justamente o que o processo ágil de desenvolvimento
visa atender:
• É difícil prever antecipadamente quais requisitos de software vão persistir e

quais serão modificados e como as prioridades do cliente serão modificadas
durante o desenvolvimento do projeto.
• Para muitos tipos de software, o projeto e a construção são intercalados, ou
seja, as duas atividades devem ser realizadas juntas de modo que os
modelos de projeto sejam comprovados à medida que são criados. É difícil
prever o quanto de projeto é necessário antes que a construção seja usada
para comprovar o projeto.
• Análise, projeto, construção e testes não são tão previsíveis (do ponto de
vista do planejamento) como gostaríamos.
Pressman (2006, p. 61) levanta uma questão importante a partir das suposições:
como criar um processo que possa gerenciar a imprevisibilidade? A resposta, como
afirma Pressman, está na adaptabilidade do processo (as modificações rápidas do
projeto e das condições técnicas). Um processo ágil, portando, deve ser adaptável.
A implementação de metodologias ágeis proporciona o desenvolvimento

cooperativo, que se baseia mais nas pessoas e suas iterações em vez de grandes
esforços de planejamento e processo rígidos. Essas iterações permitem a
visualização contínua do desenvolvimento e o direcionamento do projeto para
atender seu propósito. Existem diversas metodologias ágeis de processo tais como
a Extreme Programming (XP), o Scrum e o Kanban que serão 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, princípios e práticas da metodologia, direcionando

seus objetivos para a alta qualidade no desenvolvimento de software, adaptando-os
a requisitos vagos ou em constante mudança. A XP engloba práticas de engenharia
ágil alinhadas de tal forma a criar uma interdependência entre elas, sendo
diretamente ligadas à qualidade do software, tais práticas como: refatoração,
desenvolvimento guiado por testes, propriedade coletiva de código, design
incremental, programação em pares, padrões de código e integração contínua.
Segundo Teles (2006), a XP se baseia em cinco valores fundamentais para guiar o

desenvolvimento: Comunicação, simplicidade, feedback, coragem e respeito.
2.2.1 Práticas da XP
Práticas em XP representam aquilo que as equipes XP estão fazendo diariamente e

sua aplicação depende do contexto. Segundo Teles (2004, p. 28), as práticas XP
podem ser representadas da seguinte forma:
• Jogo de Planejamento: nesta prática existe uma grande interação entre o

cliente e a equipe, visando assegurar que se esteja trabalhando naquilo que é
o mais importante para o cliente. Os programadores estimam o esforço
necessário para implementar as histórias possibilitando conhecer o custo da
implementação e o cliente decide sobre o escopo e a duração das iterações;
• 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, é possível gerar um fluxo contínuo de valor, incorporar mudanças e
corrigir o produto em tempo hábil;
• Metáfora: é elaborada uma descrição para permitir que todos os envolvidos
no projeto consigam explicar como o sistema funciona. Ela auxilia os
19
envolvidos a compreender os elementos básicos do sistema e seus

relacionamentos, criando um vocabulário 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 validação para
assegurar que esteja correto. A XP também utiliza a técnica de
desenvolvimento guiado por testes (Test Driven Development ou TDD), sendo
descrita com mais detalhes na seção 2.7.
• Refatoração: é o ato de alterar um código sem afetar a funcionalidade que
ele implementa. Isso permite a melhoria do sistema através da remoção de
duplicações de código, otimização da comunicação, simplificação e
flexibilidade;
• Programação em Par: dois programadores escrevem o código em um único
computador, permitindo uma revisão permanente, feedbacks e uma
implementação mais simples e eficaz;
• Código Coletivo: qualquer programador pode alterar qualquer parte do
código em qualquer lugar do sistema a qualquer momento;
• Integração Contínua: uma nova funcionalidade pode afetar outras que já
estejam implementadas. Para garantir que o sistema esteja sempre
funcionando, a prática de integração contínua (Continuous Integration ou CI)
conduz os desenvolvedores a integrarem seus códigos com o restante do
sistema diversas vezes ao dia. Essa prática será abordada na seção 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 usuário
deve participar ativamente no processo de desenvolvimento junto à equipe de
programadores. A sua presença viabiliza a simplicidade do processo em
diversos aspectos, especialmente na comunicação;
• Código Padronizado: os programadores escrevem todo o código de acordo
com regras que enfatizam a comunicação durante a codificação. Antes do
início do projeto deve ser definido um padrão que deverá ser seguido por toda
a equipe de programadores.
20
• Ritmo Sustentável: a qualidade do design, do código, das metáforas e do

sistema é determinada pela qualidade dos desenvolvedores e a capacidade
que eles têm 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 visualização do agrupamento das práticas aplicadas com a

adoção da XP.
Figura 1 – Agrupamento das práticas da XP.
Fonte: http://www.hiflex.com.br/v1/2014/07/scrum-sustenta-se-sozinho/
2.2.2 Adoção da XP
Segundo Teles (2004, p. 21), a XP é uma metodologia ágil voltada para projetos
cujos requisitos são vagos e mudam com frequência, desenvolvimento de sistemas
orientados a objetos, equipes pequenas, preferencialmente até 12 desenvolvedores
e desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades ao
longo do tempo.
21
Segundo Astels, Miller e Novak (2002, p. 181), a melhor maneira de adotar a XP é

utilizá-la em organizações recém-formadas, quando ainda não existe um modo pré-
concebido de desenvolvimento de software. São necessários desenvolvedores
experientes, porque eles entendem como entregar projetos e podem ajudar os
novatos a entenderem esse importante princípio. Mas essa não é a única maneira:
algumas organizações levam a XP para suas equipes que entra em operação de
forma transparente. Os desenvolvedores já podem estar utilizando as práticas 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 benefícios 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 básica e ir descobrindo
maneiras de adaptá-la e melhorá-la para que os seus princípios possam
complementar o processo existente.
2.3 SCRUM
O Scrum teve sua definição em 1995 por Ken Schwaber, com o objetivo de
consolidá-lo como um método 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 é previsível. Ele oferece um conjunto de práticas
que tem como objetivo manter o gerenciamento do projeto visível aos usuários do
modelo. A metodologia não detalha o que deve ser feito e não resolve os problemas
da empresa. O objetivo do Scrum é dar visibilidade a estes problemas e servir como
guia na resolução 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, análise, projeto, evolução
e entrega. A Figura 2 ilustra o fluxo de processo utilizando Scrum.
22
Figura 2 – Fluxo de processo utilizando Scrum.
Fonte: http://www.hatanaka.com.br/info/artigo/gerenciamento-de-projetos/ciclo-de-vida-scrum.php
Varaschim (2009, p. 3) descreve o ciclo de desenvolvimento onde a primeira etapa

dentro da Sprint é a reunião de planejamento (Sprint Planning). Nela, o time (Scrum
Team), em conjunto com o cliente (Product Owner), definem o que será
implementado na iteração (Sprint Backlog), sendo responsabilidade do cliente
realizar a priorização do trabalho a ser feito.
A próxima etapa é a de execução, onde o time detalha as tarefas necessárias para

implementar o que foi solicitado pelo cliente e posteriormente inicia a execução das
mesmas. Durante a Sprint o time realiza reuniões diárias (Daily Meeting) com não
mais de 15 minutos, para averiguar o acompanhamento do progresso do
desenvolvimento, usando para isto, o BurnDown Chart, um gráfico usado para o
acompanhamento das tarefas a realizar, em andamento e já realizadas.
Ao final do Sprint é realizada uma reunião para a validação da entrega (Sprint

Review), onde o cliente e quem mais tiver interesse no produto podem verificar se o
objetivo da Sprint foi atingido. Logo após, é realizada uma reunião 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.
23
Ao invés 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,
2009, p. 24). Empresas com projetos que possuem altas taxas de mudanças se
beneficiarão com as práticas do Scrum. A seguir serão descritos resumidamente os
papéis, as etapas da Sprint e os artefatos que compõem o Scrum.
2.3.1 Papéis e responsabilidades
Os papéis e responsabilidades associados ao Scrum são:
• Scrum Master: atua como facilitador do Daily Meeting e torna-se responsável

por remover quaisquer obstáculos que sejam levantados pela equipe durante
essas reuniões;
• Scrum Team: é a equipe de desenvolvimento. É responsável por atingir os
objetivos da Sprint, mostrando os resultados do trabalho para o cliente;
• Product Owner: é o cliente de um time Scrum, sendo responsável pelo
retorno do investimento de um produto.
A responsabilidade pela qualidade do produto é do time, que tem o dever de verificar

se suas práticas de desenvolvimento são compatíveis com as necessidades de
qualidade e disponibilidade da aplicação.
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 término, tem-se uma nova versão do sistema. Durante este
período o time realiza diversas atividades:
• Sprint Planning: é a primeira atividade dentro de uma Sprint; é uma reunião

na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum
Team, bem como qualquer pessoa interessada que esteja representando a
gerência ou o cliente. Coletivamente, o Scrum Team e o Product Owner
definem um objetivo para a Sprint, que é uma breve descrição daquilo que se
24
tentará alcançar. O Sprint Planning geralmente é feito em um dia, mas de

acordo com o tamanho da Sprint, este tempo pode variar;
• Daily Meeting: reunião diária realizada pela equipe a cada dia da Sprint, que
tem como objetivo disseminar conhecimento sobre o que foi feito no dia
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 alcançado e o Product Owner verifica se as condições
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 ações serão tomadas para melhorar.
2.3.3 Artefatos
Os artefatos gerados pelo SCRUM são (VARASCHIM, 2009, p. 9):
• Product Backlog: é a lista que contem as funcionalidades de negócio, os

requisitos técnicos e os erros encontrados no sistema que precisam ser
corrigidos;
• Sprint Backlog: é gerado a partir das estórias retiradas do Product Backlog e
que serão implementadas durante a Sprint;
• Burndown Chat: a equipe monitora seu progresso a partir da informação das
tarefas realizadas no dia anterior atualizando um Burndown Chart, como
mostra a Figura 3. O gráfico indica a completude de tarefas do Sprint e seu
andamento em comparação com o número de tarefas planejadas. O eixo
horizontal mostra o período em dias corridos; o eixo vertical mostra a
quantidade de trabalho que precisa ser feita no início de cada Sprint.
25
Figura 3 – Exemplo de um gráfico Burndown Chat.
Fonte: http://www.brq.com/metodologias-ageis/
Além do Burndown, pode-se utilizar para o acompanhamento de tarefas um quadro

visual onde as tarefas são divididas em “a realizar”, “em andamento” e “já
realizadas”. O Kanban será abordado na próxima seção.
2.4 KANBAN
Kanban é um termo de origem japonesa e significa literalmente “cartão”. É um sinal

visual com conceitos relacionados com cartões (post-it e outros) para indicar o
andamento do fluxo de produção em empresas de fabricação em série.
Tipicamente usa-se um quadro em branco com post-its (Quadro Kanban), próximo

ao estoque de peças no setor de produção, conforme Figura 4.
Figura 4 – Exemplo de um quadro Kanban.
Fonte: http://www.viso.com.br/produto/kanban-kanb-03-C149000.html
26
A transparência que isso gera também contribui para a mudança cultural. O Kanban
expõe gargalos, filas, variabilidade e desperdício, tudo que impacta o desempenho
da organização em termos de quantidade de trabalho de valor entregue e o tempo
de ciclo (tempo médio para executar um item) necessário 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
colaboração no trabalho. A utilização de um sistema Kanban permite um controle
detalhado de produção com informações 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 mudanças em um ciclo de desenvolvimento de software
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 são
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 cartão e coloque na parede e use colunas nomeadas para ilustrar
onde cada item está no fluxo de trabalho;
27
• Limite o trabalho em progresso (WIP). Associe limites explícitos para quantos

itens podem estar em progresso a cada estado do fluxo de trabalho;
• Acompanhe o tempo de execução da tarefa. Otimize o processo para tornar o
tempo de execução o menor e mais previsível possível.
2.5 SISTEMA DE CONTROLE DE VERSÃO
Sistemas de controle de versão (VCS – version control system) são um mecanismo

de guardar múltiplas versões de arquivos, de modo que, quando se modifica um
deles, ainda é possível ter acesso às versões anteriores (HUMBLE; FARLEY, 2013,
p. 32). Para Chacon e Straub (2014, p. 13), sistemas de controle de versão são
sistemas que registram as mudanças feitas em um arquivo ou em um conjunto de
arquivos ao longo do tempo de forma que se possa recuperar versões específicas.
Um VCS permite reverter arquivos ou um projeto inteiro para um estado anterior,

comparar mudanças 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 versão de cada arquivo
armazenado nele e garantir acesso a ela. Em segundo lugar, ele permite que
equipes distribuídas no tempo e no espaço colaborem. Existem três maneiras de
efetuar o gerenciamento de versões, que serão apresentadas a seguir.
2.5.1 Sistemas de Controle de Versão Locais
Alguns programadores desenvolveram há muito tempo VCSs locais que

armazenavam todas as alterações dos arquivos, conforme o diagrama da Figura 6.
28
Figura 6 – Diagrama de um sistema de versão local.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão.
Basicamente, essa ferramenta mantém conjuntos de patches (ou seja, as diferenças

entre os arquivos) entre cada mudança em um formato especial; a partir daí
qualquer arquivo em qualquer ponto na linha do tempo pode ser recriado ao juntar-
se todos os patches.
2.5.2 Sistemas de Controle de Versão 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 Versão Centralizados (CVCS - Centralized Version Control
System). Esses sistemas, como por exemplo o CVS, Subversion e Perforce,
possuem um único servidor central que contém todos os arquivos versionados e
vários clientes que podem resgatar (check-out) os arquivos do servidor. A Figura 7
apresenta o diagrama desse sistema.
29
Figura 7 – Diagrama de um sistema de versão centralizado.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão
O diagrama demonstra algumas vantagens, especialmente sobre VCSs locais. Por

exemplo: todos podem ter conhecimento razoável sobre o que os outros
desenvolvedores estão fazendo no projeto; Administradores têm controle específico
sobre quem faz o quê; e é bem mais fácil 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, ninguém pode trabalhar em conjunto ou salvar novas
versões dos arquivos durante esse período.
2.5.3 Sistemas de Controle de Versão Distribuídos
Em um Sistema de Controle de Versão Distribuído (DVCS - Distributed Version

Control System), os clientes não apenas fazem cópias das últimas versões dos
arquivos mas eles são cópias completas do repositório. Assim, se um servidor falhar,
qualquer um dos repositórios com os desenvolvedores podem ser copiados de volta
para o servidor para restaurá-lo. Cada check-out é na prática um backup completo
de todos os dados, conforme a Figura 8.
30
Figura 8 – Diagrama de um sistema de versão distribuído.
Fonte: http://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Versão
Muitos desses sistemas lidam muito bem com o aspecto de ter vários repositórios
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
não são possíveis em sistemas centralizados, como por exemplo o uso de modelos
hierárquicos.
2.6 GERÊNCIA DE CONFIGURAÇÃO
A estratégia de gerência de configuração determina a forma de como o time de

desenvolvimento colabora pois ela registra a evolução de seus sistemas e
aplicações. Entende-se por configuração o estado em que um sistema se encontra
em um determinado momento.
As configurações variam com o tempo de acordo com as atualizações e correções

do ambiente e do sistema. Segundo Humble e Farley (2014, p. 280), neste contexto
o ambiente é um conjunto de recursos que a aplicação precisa para funcionar. A
gerência de configurações trata os elementos como um todo, incluindo o hardware
necessário para a manutenção do sistema e permite organizar todos os elementos
31
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 versão é

apenas o primeiro passo para gerência de configuração, uma vez que é preciso dar
uma resposta afirmativa as seguintes questões: (1) é possível reproduzir exatamente
qualquer um dos ambientes? (2) É possível efetuar mudanças incrementais nesses
itens individuais e implantá-las em quaisquer dos ambientes ou em todos eles? (3) É
possível identificar facilmente quais foram as mudanças ocorridas para um ambiente
específico e rastreá-las para ver quando, por que e para quem as mudanças foram
feitas? (4) É possível satisfazer todos os requisitos de conformidade à
regulamentação aos quais se está sujeito? (5) qualquer membro da equipe pode
facilmente obter a informação de que precisa e fazer as mudanças que precisam ser
feitas?
Cada uma dessas perguntas corresponde a uma das atividades realizadas pela
gerência de configuração para permitir manter a consistência e a integridade do
software com as especificações. Diante disso, é importante guardar toda a
informação requerida para recriar os ambientes no controle de versão; isso inclui
arquivos de DNS, scripts de banco de dados, arquivos de compilação e implantação,
documentação, bibliotecas e arquivos de configuração para a aplicação e todas as
ferramentas relacionadas, e assim por diante, de modo que um novo membro da
equipe possa começar do zero a partir de um único ponto.
2.6.1 Provisionamento
No caso dos servidores de redes de computadores, o processo de provisionamento

é um conjunto de passos executáveis 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 benefícios a repetibilidade de gerar um
estado adequado do ambiente e uma documentação executável dos procedimentos
para configuração.
32
Martin Fowler chama os servidores que dependem da ação humana de tentativa e

erro para provisionar de SnowflakeServer 2 , Essas máquinas geralmente não
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 começa

quando a nova máquina é colocada em um datacenter, ligada à alimentação e à
rede; a partir deste ponto, praticamente todo o restante do seu ciclo de vida pode ser
feito remotamente por meio de automação.
Hoje, existe uma série de ferramentas para provisionar uma máquina, cada uma
delas com seus diferentes benefícios 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/) e Salt
(http://saltstack.com/). Todas elas estão contribuindo para a evolução da
comunidade DevOps (veja seção 2.10), e, apesar de competirem entre si, seu maior
adversário ainda é a falta de uso pelas empresas.
Sato (2013, p.60) relata uma característica importante que essas ferramentas
especializadas possuem, a idempotência. A idempotência permite executar o código
diversas vezes seguidas e as ferramentas só mudarão o que for necessário. Se um
pacote estiver instalado, ele não será reinstalado. Se um serviço está iniciado, ele
não será reiniciado. Diferentemente dos scripts proprietários 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 verificação da

conformidade dos seus requisitos funcionais e não 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 situações
completamente imprevistas ou devido a erros de lógica, falta de atenção,
2
Acesse http://martinfowler.com/bliki/SnowflakeServer.html para mais detalhes sobre
Snowflake Server.
33
interpretação incorreta de requisitos e, como consequência, a ocorrência de defeitos

é uma realidade, sendo difícil ou impossível evitar que aconteçam 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), não existe
uma classificação ou terminologia amplamente aceita na indústria, 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 Contínua: Como entregar software de forma rápida e confiável
Na figura de Brian Marick, observa-se um agrupamento dos tipos de testes, sendo

que no lado esquerdo estão os testes que suportam a programação. Estes testes se
preocupam em avaliar a qualidade interna do sistema e são executados com
bastante frequência pelos desenvolvedores para obter feedback sobre as mudanças
introduzidas.
No lado superior, estão os testes que são escritos do ponto de vista do negócio, com
uma linguagem que faz sentido para um especialista de domínio. No lado inferior
estão os testes voltados à tecnologia, escritos do ponto de vista técnico e com
termos que farão sentido para os programadores.
No lado direito existe testes que exigem a criatividade ou exploração e são

geralmente manuais, como os testes exploratórios. Há também um conjunto de
testes passíveis de automatização que, conforme Humble e Farley (2014, p. 91), em
muitos projetos são ignorados ou não há uma preocupação em validá-los.
34
O conjunto de testes também atua como um conjunto de testes de regressão, não

testando apenas os requisitos funcionais do sistema, mas também a capacidade, a
segurança e outros requisitos não funcionais estabelecidos, sendo possível 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 colaboração entre os testadores e os desenvolvedores desde o início do
projeto, antes que os desenvolvedores iniciem seus trabalhos, para que o conjunto
de testes forme uma especificação executável do comportamento do sistema. Com
os testes validam-se não somente se há um erro de lógica no código mas também
se os requisitos estão bem definidos para que possam entregar aquilo que é
esperado (LOPES, 2012, p.63).
Os testes manuais também são essenciais para adicionar qualidade como

demonstrações, testes de usabilidade e testes exploratórios, eles devem ser
realizados continuamente ao longo do projeto.
Os testes automatizados permitem que a máquina faça o que ela é boa, a repetição,
enquanto os humanos façam o que eles são bons, explorar. Para a tarefa de escrita
dos testes automatizados, a XP traz em suas práticas como descrito na seção 2.2.3,
a prática de desenvolvimento guiado por testes, que é muito difundida na
comunidade de desenvolvimento de software e descrita na próxima seção.
2.7.1 Desenvolvimento guiado por testes
Desde a década 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 práticas da XP ganharam notoriedade
no decorrer dos anos, o TDD ganhou ainda mais atenção, introduzindo o conceito de
que os desenvolvedores devam escrever os testes para as funcionalidades antes de
codificá-las. Conforme Braúna (2013, p. 4), isso permite um melhor entendimento
das necessidades do cliente, cria uma preocupação com as interfaces externas dos
métodos e classes e permite contar com um conjunto de testes que podem ser
executados a qualquer momento para validar o sistema.
35
O ciclo aplicado à prática do TDD envolve três 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 são: (1) A escrita do teste se dá antes da codificação da funcionalidade,

sendo que no primeiro momento, o que é esperado é que o teste não passe; (2) O
próximo passo é codificar uma solução para que o teste tenha sucesso ao ser
executado. Nesse momento, a primeira solução encontrada pode ser utilizada para
atingir o objetivo; (3) No passo de refatoração, deve ser feita uma análise no código
criado para verificar se existe uma solução mais otimizada que atinja o mesmo
objetivo.
2.8 INTEGRAÇÃO CONTÍNUA
Em um ambiente de desenvolvimento, o software é dividido de modo que cada

desenvolvedor fique responsável por uma parte dele. Dessa forma, é necessário
integrar todas as partes para que o sistema funcione. Quanto mais longo for o tempo
entre uma integração e outra, mais a equipe encontrará dificuldades para fazer o
sistema rodar e os testes funcionarem (TELES, 2004, P. 176).
Para Fowler (2006), Integração Contínua (IC) é uma prática de desenvolvimento de

software onde os desenvolvedores integram seu trabalho pelo menos uma vez por
dia, podendo haver múltiplas integrações por dia. Assim que o desenvolvedor
termina sua tarefa, ele executa todos os testes para garantir que suas mudanças
funcionam isoladamente, atualizam o seu código com as alterações mais recentes
que estão no repositório de código e repetem todo o processo de testes, visando
certificar que suas mudanças funcionam com o código que já está compartilhado. Só
então é possível integrar o seu código ao repositório de código central.
36
Apesar de diminuir as chances de introduzir defeitos no sistema, esse ritual exige

que o desenvolvedor tenha a disciplina de fazer isso a cada alteração. Um servidor
de integração contínua, conforme a Figura 11, permite o monitoramento do
repositório constantemente. A cada alteração validada com sucesso no ambiente de
desenvolvimento, é possível efetuar o check-in no repositório de código, fazendo
com que o sistema de integração contínua execute uma sequência de verificações,
como os testes automatizados, mantendo todos os membros do time atualizados
com o estado atual do projeto.
Figura 11 – Processo de integração contínua com o auxilio de ferramentas.
Cada alteração que tenha sido validada com sucesso pelo processo de integração
contínua vira uma versão candidata a ir para produção e fica disponível no
repositório de artefatos. Essa prática permite descobrir eventuais defeitos o mais
rapidamente possível, acelerando a correção e diminuindo a probabilidade de que
pequenos erros se transformem em grandes dores de cabeça no futuro.
2.9 PIPELINE DE IMPLANTAÇÃO
A Integração Contínua abordada na seção anterior concentra-se principalmente no

time de desenvolvimento; ela precede o início de vários processos manuais, tais
como os testes exploratórios e a implantação 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 operações esperando por documentação ou
correções, testadores esperando por versões “boas” de software, equipes de
37
desenvolvimento recebendo informações sobre defeitos depois de já estarem

trabalhando ha semanas em outras funcionalidades e a descoberta, já no fim do
processo de desenvolvimento, de que a arquitetura da aplicação não suporta os
requisitos não funcionais do sistema. Nesse cenário, a equipe enfrenta um processo
de feedback longo, deixando o sistema impossibilitado de ir para produção.
O processo como um todo, de levar a funcionalidade da mente do cliente até o

usuário final, pode ser tratado com uma visão mais holística, de ponta a ponta do
processo de entrega e modelado através de um fluxo de valor, mostrando uma
história dos processos executado por uma organização. O objetivo do fluxo de valor
é mapear uma solicitação do cliente, do momento em que ela chega até que esteja
disponível em produção (POPPERDIECK, 2011, p. 41). Conforme a Figura 12, todos
os passos para atender à solicitação e o tempo médio em cada passo pode ser
modelado, dando uma visão 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 vários ciclos compostos de testes e
demonstrações e todo o processo seria repetido várias vezes.
Figura 12 - Um exemplo de mapa de fluxo de valor simples para um produto
As alterações efetuadas no sistema dependem de vários indivíduos, ou até mesmo

de várias equipes até a sua entrega. Após a codificação, é preciso compilar o código
gerando uma nova versão do sistema, fazer com que esse resultado seja validado
em cada estágio de teste, implantado em ambientes para testes exploratórios e
liberado em produção. O pipeline de implantação modela esse processo, e sua
inversão em uma ferramenta de integração contínua e gerência de versões é o que
permite que uma equipe veja e controle o processo de cada mudança à medida que
38
ela se move em direção a entrega ao usuário final (HUMBLE; FARLEY, 2014, p.

107). Com os aspectos tratados nas seções anteriores e com a automatização, 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 versão em produção.
Duvall (2012) define o pipeline de implantação como um processo no qual diversos

tipos de tarefas são executadas com base no sucesso da tarefa anterior. Para
Humble e Farley (2014, p. 106) o pipeline de implantação é uma manifestação
automatizada do processo de levar o software do controle de versão até os usuários.
Cada mudança passa de forma consistente no percurso de entrega através da
automação.
A parte gerenciada pelo pipeline de implantação no mapa de fluxo de valor é a parte

que vai do desenvolvimento até a entrega da versão. O fato de ser possível a
automatização, não restringe a interação humana. A possibilidade de implantar o
sistema com o apertar de um botão encoraja testadores, desenvolvedores, analista e
usuários para seu uso frequente. A automatização torna passos complexos e
suscetíveis a erros em passos repetíveis e confiáveis.
Para chegar a este estágio, é necessário automatizar o processo de compilação,

automatizar um conjunto de testes que provam os critérios do sistema e automatizar
a implantação em ambientes de teste, aceitação e produção. Humble e Farley (2013,
p. 109) explicam como essas mudanças se movem pelo pipeline de implantação
através de um diagrama de sequência, como mostrado na Figura 13.
A entrada do pipeline inicia-se com o check-in no sistema de controle de versão que

aciona o sistema de integração contínua criando uma nova instância do pipeline,
uma nova versão (versão candidata a ir para produção) que irá passar por uma
sequência de testes para provar que é possível uma entrega de versão. Cada
estágio de teste avalia a versão candidata de uma perspectiva diferente e a cada
teste que ela passa, aumenta a confiança em sua implementação, o que significa
que os ambientes do percurso se tornam progressivamente mais similares ao de
produção. O objetivo desse processo é eliminar as versões candidatas que não
39
estejam prontas para produção o quanto antes e obter feedback sobre a falha o mais
rápido possível (HUMBLE; FARLEY, 2014, p. 108).
Figura 13 - Mudanças se movendo por um pipeline de implantação.
Com a adoção dessa abordagem, não é permitido efetuar implantação do sistema

em produção sem que a versão seja apropriadamente testada e regressões são
evitadas ao se fazer correções. As correções passam pelo mesmo processo que
quaisquer mudanças.
Quando a versão candidata passa pelo estágio de teste de aceitação automatizado,

ela se torna algo útil e interessante não sendo mais prioridade da equipe de
desenvolvimento. É preferível que os estágios de implantação para os ambientes de
aceitação e produção não executem automaticamente. Os testadores devem ser
capazes de ver quais versões candidatas passaram com sucesso e implantar o
sistema em um ambiente configurado com um simples apertar de botão.
2.9.1 Como criar um pipeline de implantação inicial
Essa seção descreve uma estratégia para se chegar a um pipeline de implantação

conforme apresentado por Humble e Farley (2014, p. 133). Deve-se ter em mente
que, independente do estágio do projeto, a implementação do pipeline deve ser de
maneira incremental.
40
Ë necessário ter uma visão dos processos necessários para permitir a entrega, isso
pode ser efetuado através do mapa de fluxo de valor conforme visto no início deste
capítulo. Com a participação de todos os envolvidos é possível descrever todos os
passos, obter estimativas do tempo decorrido e do tempo gasto nas atividades que
agregam valor. Modelar um pipeline de implantação exige entender seus processos
de entrega e balancear o nível 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 básico, um estágio para compilar a aplicação e rodar
os testes unitários, um estágio para executar os testes de aceitação e um estágio
para implantar o sistema em um ambiente similar ao de produção. O primeiro
estágio é executado sempre que se faz check-in no repositório de código, os testes
de aceitação devem utilizar o mesmo código resultante da etapa anterior e começar
automaticamente depois que a compilação e os testes unitários tiverem sidos
executados com sucesso. Os estágios de implantação utilizam as versões que
passaram com sucesso pelos testes de aceitação e devem poder ser executados
com o acionar de um botão. Na prática de entrega contínua, conforme (SATO, 2013,
p. 181), a decisão de levar uma versão para produção é de negócio e normalmente
requer pessoas com autorização.
2.9.2 Objetivos para utilização do pipeline
O objetivo é ter o processo de entrega completamente automatizado para inibir risco

de negócio associados a cada entrega do sistema em produção. Fowler (2013)
acrescenta dizendo que o pipeline é para detectar quaisquer mudanças que levem
os problemas para produção e para permitir a colaboração entre os envolvidos,
possibilitando a visibilidade de todo o fluxo de mudanças juntamente com uma trilha
de auditoria completa. Com a entrega sendo um resultado natural do pipeline de
implantação, é possível obter:
• Um plano de entrega criado e mantido por todos os envolvidos, incluindo

desenvolvedores, testadores, operações, infraestrutura e suporte;
41
• Minimização dos efeitos de erros cometidos por pessoas por meio da máxima
automação do processo possível, começando com os estágios mais sujeitos a
erros;
• Ensaiar os procedimentos em ambientes similares ao de produção, de modo
que seja possível depurar o sistema e a tecnologia que o suporta;
• Ter a capacidade de executar um rollback3 de uma entrega se as coisas não
acontecerem de acordo com o plano;
• Ter uma estratégia de migração de dados e configuração de produção como
parte do processo de rollback.
Para que se consiga obter todos os benefícios do pipeline, Humble e Farley (2014,
p. 113) descrevem um conjunto de práticas, tais como:
• Compile seus códigos somente uma vez;

• Faça a implantação da mesma maneira para cada ambiente;
• Implante em uma cópia do ambiente de produção;
• Cada mudança deve ser propagada pelo pipeline instantaneamente;
• Se qualquer parte do pipeline falhar, pare o processo e corrija o problema
antes de continuar qualquer coisa.
Possibilitar que qualquer indivíduo (com permissão) envolvido no processo de

entrega implante uma versão do sistema em um ambiente no momento que deseja,
é um dos resultados adquiridos com a criação do pipeline. Para auxiliar nessa tarefa,
existe no mercado um conjunto de ferramentas classificadas como ferramentas para
automação de implementação, dentre elas, destacam-se: Capistrano, Mina,
ControlTier, Glu e RunDeck.
2.10 MOVIMENTO DEVOPS
Em 2009 durante a conferência Velocity da O’Reilly, John Allspan e Paul Hammond

apresentaram 10+ Deploys Per Day 4 , demonstrando como a Flickr5 efetuava 10
implantações por dia e através da convergência de outros movimentos adjacentes
3
Rollback é uma ação que desfaz a ação corrente, fazendo com que todas as modificações
realizadas até o momento sejam rejeitadas. Para mais informações acesse:
http://pgdocptbr.sourceforge.net/pg82/sql-rollback.html
4
Acesse o video em: https://www.youtube.com/watch?v=LdOe18KhtT4
5
www.flickr.com
42
como: o movimento infraestrutura como código de Mark Burgess e Luke Kanies e o

movimento de administração do sistema ágil de Patrick Debois, deu-se origem ao
movimento DevOps. O movimento busca difundir em todo mundo a colaboração
entre todos os envolvidos na entrega do software, particularmente as equipes de
desenvolvimento, de testes e de operações, conforme a Figura 14.
Figura 14 – Equipes envolvidas no movimento DevOps.
Fonte: http://en.wikipedia.org/wiki/DevOps
Essa colaboração permite otimizar o fluxo do processo de desenvolvimento,

reduzindo o custo de criação de novas versões e possibilitando uma entrega
confiável de software. Com a adoção do movimento DevOps, consegue-se criar um
relacionamento colaborativo entre desenvolvimento e operações; ampliar as taxas
de implementações; e aumentar a confiabilidade, a resiliência e a segurança do
ambiente de produção.
Uma premissa simples do DevOps é a aplicação de melhores práticas e padrões do

desenvolvimento para as operações e vice-versa (Duvall, 2012). Para Hashimoto
(2013), DevOps serve para criar um ciclo de feedback rápido e reduzir o custo de
criação de novas versões de produtos, ao mesmo tempo que melhora a estabilidade
geral dos sistemas. A implementação na empresa não é instantânea, pode-se
quebrar em uma série de pequenas mudanças.
43
3. UMA PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE
Este capítulo apresenta o estudo de caso realizado em um ambiente ágil de

desenvolvimento de software, abordando as dificuldades relacionadas ao processo
de entrega. Através desse estudo de caso será apresentado à proposta de solução,
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 Vitória ES e possui mais de
5 anos de atuação no mercado de desenvolvimento de software. É especializada em
soluções 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 várias regiões
do país no mercado de comércio eletrônico.
O SLV da empresa é o ponto de partida para o atendimento de um novo cliente.

Esse sistema possui mais de 30 implantações em produção, ou seja, mais de 30
clientes que o utiliza para vender seus produtos através da internet.
Para inibir riscos com perda de oportunidades no universo web, onde as

informações trafegam de continente a continente em frações de segundos, a
empresa evita os longos ciclos de desenvolvimento tradicionais adotando as
metodologias ágeis, fazendo uso das práticas da XP, do Scrum e do Kanban. Dessa
forma, uma nova versão do sistema é entregue a cada 10 dias de desenvolvimento,
no término de cada Sprint.
Para cada solicitação de um cliente, existe uma sequência de procedimentos pré-

definidos que são executados até a conclusão do atendimento. Esses processos
foram especificados em um mapa de fluxo de valor conforme a Figura 15. Entende-
se como fluxo de valor o processo de levar uma necessidade da mente do cliente
até as mãos de seus usuários finais (HUMBLE; FARLEY, 2014, p. 107).
Esse mapa é executado sempre que há uma nova solicitação, seja de clientes novos
ou de clientes já existentes e é composto das seguintes atividades:
44
• Quando uma solicitação é gerada pelo cliente, o responsável pelo comercial

realiza um contato com o lojista para que seja feita a especificação de como a
loja deverá funcionar, conforme o ramo de atuação da loja;
• Comercial, gerente de projetos e desenvolvedores analisam os requisitos da
solicitação definindo um orçamento;
• Com o orçamento aprovado, o gerente de projetos em conjunto com os
desenvolvedores, realizam uma estimativa de esforço conforme a
complexidade dos requisitos para mensurar quantas Sprints essa nova
demanda irá ocupar no cronograma. Várias Sprints podem ser agendadas até
o atendimento de todos os requisitos;
• No período de desenvolvimento, onde o tempo total é determinado de acordo
com a quantidade de Sprints necessárias para atender as solicitações, várias
atividades são executadas conforme descrito na seção 3.1.1;
• No final de cada Sprint, é criada uma nova versão do SLV para o cliente e as
funcionalidades são implantadas em seu ambiente de produção.
Figura 15 - Mapa do fluxo de valor da empresa objeto deste estudo.
Na execução desse processo, um desenvolvedor é alocado para desenvolver as

solicitações de um determinado cliente. As solicitações menores, as que não
ocupam uma Sprint, são 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 atualizações no SLV para introdução de novas funcionalidades,
atualização de tecnologia ou otimização de código, de forma a proporcionar uma
melhor experiência de compras aos usuários. Sendo assim, Sprints para a
atualização do SLV são adicionadas ao cronograma.
45
Devido às dificuldades dos processos de desenvolvimento, conforme seção 3.1.2, a

quantidade de entregas de software de valor no final de uma Sprint é baixo, sendo
preciso o agendamento de várias Sprints e, sendo assim, a estimativa de tempo
para o atendimento das solicitações de um cliente é elevada. Gasta-se
aproximadamente cerca de 45 dias para a disponibilização de uma nova loja com
poucas customizações. O fluxo de atendimento a pequenas solicitações 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 necessárias para o desenvolvimento de

software são executadas pela equipe. O conjunto de solicitações a serem
desenvolvidas nesse período são gerenciadas manualmente fazendo uso do quadro
do Kanban, No quadro, o fluxo é efetuado conforme a Figura 16.
Figura 16 – Movimentação atual das solicitações no quadro Kanban.
As solicitações ficam disponíveis na coluna A Fazer. Quando o desenvolvedor inicia

a codificação, ele move a solicitação que irá trabalhar para a coluna Fazendo e
quando termina, a move para coluna Verificação. Nessa coluna, a equipe de
qualidade tem a visualização das solicitações que já estão disponíveis para serem
testadas no ambiente de aceitação. Um desenvolvedor disponibiliza a solicitação no
ambiente de aceitação para que a equipe de qualidade realize os testes. Quando os
testes terminam, a solicitação é movida para a coluna Concluído e, então, um
desenvolvedor efetua a implantação no ambiente de produção e arquiva a
solicitação, retirando-a do quadro.
Para a codificação das solicitações, cada desenvolvedor configura seu ambiente de

desenvolvimento com as dependências necessárias para o funcionamento do SLV.
Ao efetuar alterações no SLV, o desenvolvedor efetua o gerenciamento de versão

de código utilizando a ferramenta Git e escreve um conjunto de testes
automatizados com a utilização da ferramenta RSpec, apresentada na seção
46
5.2.1.10. Esses testes são executados em seu ambiente de desenvolvimento para

certificar de que não foram inseridos defeitos no sistema. Os testes também são
executados quando se faz o check-out do repositório, verificando que as alterações
de outro desenvolvedor não afetaram o que foi codificado.
Devido a codificação ser em computadores separados, é necessário efetuar a

junção do código produzido ao repositório de código 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 são acessados pelos desenvolvedores para a
realização de configurações e atualizações manualmente. O processo de implantar a
loja é efetuado através do acesso ao servidor e efetuado o check-out do código fonte
no repositório e reiniciado os serviços necessários, também de forma manual.
Figura 17 - Fluxo do gerenciamento do sistema pelos desenvolvedores.
Para um novo cliente, o início do desenvolvimento possui uma etapa adicional

chamada de Setup do Sistema, que é composta das seguintes tarefas:
• Configurar o ambiente de aceitação onde o sistema será disponibilizado para

que sejam efetuados os testes exploratórios, possibilitando ao cliente validar
suas solicitações;
47
• Configurar o ambiente de produção onde a futura loja virtual ficará disponível

para os usuários finais,
• Implantar a versão padrão do sistema de loja virtual nos dois ambientes, ou
seja, implantar a versão inicial do sistema sem nenhuma customização.
O sistema é instalado inúmeras vezes no ambiente de aceitação para que a equipe

de qualidade e o próprio cliente efetuem testes e validem as solicitações no decorrer
da Sprint. No término da Sprint, a nova versão do SLV é implantada em seu
Na atualização do SLV, os testes e validações são efetuados somente pela equipe

de qualidade, porém, no término, as atualizações são implantadas no ambiente de
produção 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 usuários o quanto antes (HUMBLE; FARLEY, 2014, p. 3).
Com demonstrado na seção 3.1, há uma grande utilização do SLV. Os clientes estão
sempre solicitando atualizações e melhorias para acompanhar as novas tendências
do mercado, fazendo com que a empresa receba uma grande demanda de
manutenções mensais.
Os novos clientes chegam à empresa com um cronograma para o futuro lançamento

do seu e-commerce, porém, eles acabam frustrados ao saber que o lançamento de
sua loja virtual só poderá ser realizado em um prazo bem maior daquele planejado.
De acordo com a análise efetuada pela equipe, concluiu-se que o gargalo se dá

devido a muitos processos manuais que existem no desenvolvimento. Muitas tarefas
são executadas manualmente sem um nível de qualidade que impeça a inclusão de
defeitos no sistema.
Durante o ciclo de desenvolvimento, diversos problemas ocorrem, tais como:

48
• Os desenvolvedores codificam as funcionalidades em seus ambientes de

desenvolvimento sem o controle sobre as versões das ferramentas utilizadas
e a compatibilidade com o ambiente de produção;
• Para aumentar a qualidade, a empresa faz uso de técnicas e conceitos do
TDD, onde testes são escritos para posteriormente codificar os requisitos.
Cada desenvolvedor executa os testes em seu próprio ambiente de
desenvolvimento várias vezes ao dia, sempre que está desenvolvendo uma
nova funcionalidade e quando faz o check-out no repositório. 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 código produzido paralelamente pelos desenvolvedores não é adicionado
constantemente ao código principal, permanecendo em seu ambiente de
desenvolvimento até que determinada tarefa seja finalizada. O custo da
correção de defeitos é elevado devido ao ciclo de feedback ser longo.
Trabalhar em paralelo exige mais comunicação e coordenação entre os
membros da equipe, pois quanto mais tempo eles ficarem sem integrar suas
mudanças, maior o risco de criarem conflitos (SATO, 2013, p. 126);
• Muitas solicitações são desenvolvidas e o controle de qual versão de um
componente que cada cliente está utilizando não é eficiente; defeitos são
gerados quando componentes incompatíveis são adicionados a uma
determinada loja;
• Atualizações nos ambientes são efetuadas manualmente alterando o seu
estado. São executados vários passos separados e atômicos sendo que é
necessário 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
configurações para o ambiente que a loja será implantada, possibilitando a
presença de erros se cada passo não for executado perfeitamente;
• Na fase de setup da plataforma, é preciso disponibilizar o ambiente de
aceitação e o de produção. A instalação dos softwares que a plataforma
depende e suas configurações são feitas manualmente, sem nenhum controle
49
de qualidade e em caso de erro, não é possível fazer um auditoria para

descobrir o motivo;
• Implantar novos códigos ao sistema da loja em operação é extremamente
crítico. Em muitos casos, é preciso esperar o momento de menor acesso,
geralmente pela madrugada para implantar a nova versão. Um sistema não
gera lucro ou valor até que esteja nas mão de seus usuários (HUMBLE;
FARLEY, 2014, p. 14).
3.2 REQUISITOS FUNCIONAIS
Conforme a descrição da seção 3.1.2, fica visível que um dos pontos desafiadores
do projeto está na utilização de ferramentas capazes de automatizar diversas tarefas
incluídas no processo de desenvolvimento e de prover uma forma simplificada de
utilização pelos envolvidos.
Com base em reuniões e discussões realizadas entre a equipe responsável pelo

SLV, das observações feitas dos processo executados diariamente e da pesquisa de
ferramentas utilizadas no mercado, foram levantados os requisitos para a iniciação
de um sistema. Esses requisitos foram documentados através de Diagrama de
Casos de Uso. Conforme Ramos (2006, p.32), o diagrama de casos de uso
descreve a relação entre atores e casos de uso de um determinado sistema,
permitindo uma visão global de alto nível, sendo fundamental a definição correta da
sua fronteira. Um dos seus objetivos é apresentar, de forma geral, as funções e
serviços que o sistema oferecerá, sem se preocupar em como estas serão
implementadas.
Os atores que interagem com o sistema são:
• Desenvolvedor: ator responsável por gerenciar as solicitações, cadastrando e

movendo-as pelo quadro Kanban de acordo com o desenvolvimento e pelo
gerenciamento dos ambientes onde o SLV é disponibilizado, cadastrando as
informações necessárias para acesso e executando a instalação
automatizada.
• GerenteProjetos: ator responsável por gerenciar as solicitações dos clientes,
criando projetos, cadastrando e priorizando as solicitações conforme o
cronograma de desenvolvimento. Responsável pelo cadastro de informações
50
dos usuários habilitados a utilizar o sistema e pelo cadastro das informações

de cada cliente. Também é responsável gerencia dos ambientes e pela
decisão de atualização de uma loja com uma nova versão disponível;
• Qualidade: ator responsável por verificar o atendimento das solicitações
através de testes exploratórios. Possui acesso as solicitações para
disponibilizá-las em ambiente de aceitação à medida que novas versões
ficam disponíveis;
• SIC: este ator é o sistema de integração contínua responsável por efetuar o
monitoramento do repositório de código fonte e, ao perceber que uma
alteração foi efetuada pelo ator Desenvolvedor, executar todos os testes
automatizados, fornecendo feedback ao responsável pelo desenvolvimento
da funcionalidade.
Este sistema está agrupado em três subsistemas, os quais estão denominados:

CadastrarGeral, GerenciarAmbientes e GerenciarSolicitacoes e serão descritos a
seguir de forma sucinta. A Figura 18 apresenta o Diagrama de Casos de Uso
principal do sistema proposto. A descrição 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 usuários

envolvidos na entrega de software, permitindo o acesso aos projetos e seus
51
ambientes. Nesse caso de uso também serão cadastradas as informações dos

clientes. Um cliente poderá ter mais que um SLV ativo. Consultas aos clientes
cadastrados poderão 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 informações dos

membros da equipe responsável pelo sistema de SLV, tais como o nome, e-
mail, descrição e data de inclusão.
b) CadastrarClientes: caso de uso utilizado para gerenciar as informações dos
clientes como o nome da empresa, telefone, e-mail e razão social; e dos
especialistas de domínio que participam do projeto, tais como o nome,
telefone, e-mail e descrição.
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 informações de
configurações para a criação dos ambientes para implantação do SLV.
Desenvolvedores com conhecimentos técnicos de configurações de servidor e
sistema operacional controlam essas informações; os demais desenvolvedores
podem contribuir nas atualizações das configurações, de acordo com as mudanças
que são efetuadas no sistema.
Este caso de uso é decomposto nos casos de uso CadastrarAmbiente e

ProvisionarAmbiente, os quais são 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 configurações de servidores e sistemas
operacionais para controlar os dados de acesso e configurações dos pacotes
que deverão ser instalados em um Cloud Hosting. Para criar um novo
ambiente, os atores deverão selecionar para qual o projeto o ambiente
pertence e o tipo do ambiente (produção ou aceitação), o endereço IP do
servidor, usuário e senha de acesso ao ambiente, a URL de acesso ao
ambiente e a descrição.
b) InstalarPuppet: este caso de uso será executado após o caso de uso
CadastrarAmbiente, sendo responsável por (1) verificar se as informações
cadastradas do novo ambiente tais como endereço IP, login e senha estão
válidas (através da execução de um comando Unix ping); (2) instalar e ativar
no nó 6 correspondente ao endereço IP a ferramenta Puppet Client e (3)
habilitar o botão de provisionamento de ambiente.
c) ProvisionarAmbiente: caso de uso que será executado após o caso de uso
InstalarPuppet ou a partir de uma lista de ambientes já cadastrados. As atores
Desenvolvedor ou GerenteProjetos poderão executar o caso de uso
ProvisionarAmbiente, clicando no botão correspondente. Neste momento,
será enviada uma solicitação de serviço para a ferramenta Puppet Client que
executará os scripts de instalação de pacotes no sistema operacional tais
como nginx, mysql, redis, memcached e monit utilizados no ambiente de
destino. A execução do caso de uso ProvisionarAmbiente deixa o ambiente
em um estado apropriado para implantação do SLV.
6
No contexto atual, nó é um servidor disponível por um Clound Hosting.
53
3.2.3 Caso de Uso GerenciarSolicitacoes
O gerenciamento das funcionalidades que serão customizadas no SLV, desde a sua

entrada até o momento em que são entregues conforme o quadro Kanban da Figura
23 na seção 3.4.2, será apoiado pelo caso de uso GerenciarSolicitacoes. Nele, o
gerente de projetos irá cadastrar o projeto e as solicitações (correção de defeitos,
novas funcionalidades ou customizações) a serem atendidas. Os desenvolvedores,
à medida que codificam, moverão as funcionalidades até a etapa de verificação
automatizada e o SIC efetuará, então, a execução das etapas de testes
automatizados, certificando-se que a nova versão é candidata a ir para produção. A
equipe de qualidade poderá visualizar qual versão está disponível para testes e
disponibilizá-la em ambiente de aceitação para demonstrações junto ao cliente. No
término, o gerente de projetos poderá decidir qual versão deverá ser implantada em
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á incluído todas as solicitações que serão atendidas.
b) CadastrarSolicitacao: caso de uso é executado pelos atores Desenvolvedor e
GerenteProjetos, sendo responsável pelo gerenciamento das solicitações que
deverão ser desenvolvidas para a loja virtual, conforme a reunião de
planejamento apresentada na seção 3.1. As informações de nome e
descrição são inseridas e a solicitação permanece na coluna Solicitações do
quadro Kanban.
c) AgruparSolicitacoesSprint: caso de uso executado pelo ator GerenteProjetos
para agrupar na coluna A Fazer do quadro Kanban as solicitações que serão
atendidas na próxima Sprint. Os usuários que atenderão cada uma das
solicitações são registrados, o status da solicitação é atualizado e as
respectivas datas previstas para o início e para o fim do desenvolvimento são
agendadas.
d) IniciarDesenvolvimento: caso de uso executado pelos atores GerenteProjetos
e Desenvolvedor para mover a solicitação 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 solicitação da coluna Fazendo para a coluna
Teste Unit. do quadro Kanban. Quando os atores finalizam a solicitação, eles
enviam o código fonte para o repositório manualmente através da utilização
da ferramenta Git. Nesse processo, o Git efetua a compactação dos arquivos
alterados e gera um identificador único no formato SHA17 que é cadastrado
na solicitação, permitindo dessa forma, que o SIC faça a movimentação da
solicitação 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 repositório de código em um intervalo pré-determinado.
7
Em criptografia, SHA-1 é uma função hash de criptografia projetado pela Agência dos
Estados Unidos de Segurança Nacional. Veja mais em: http://en.wikipedia.org/wiki/SHA-1.
55
Quando for detectado alguma alteração no repositório. O SIC executa então,

os processos de testes automatizados.
g) DisponibilizarVersaoEmAceitacao: caso de uso executado por todos os
autores, exceto o SIC, para disponibilizar a versão que passou no processo
de testes automatizados e está na coluna Aceitação do quadro Kanban, para
o ambiente de aceitação. Neste ambiente, a equipe de qualidade realiza
demonstrações do SLV para o clientes.
h) ImplantarVersaoEmProducao: caso de uso executado por todos os autores,
exceto o SIC, para disponibilizar a versão que foi validada com sucesso no
item anterior no ambiente de produção.
3.3 REQUISITOS NÃO FUNCIONAIS
Segundo Humble e Farley (2014, p. 249), os requisitos não funcionais são o

equivalente em software ao construtor de pontes que tenta garantir que as vigas
escolhidas são fortes o suficientes para suportar o tráfego e as condições
meteorológicas esperadas. Esses requisitos são reais e precisam ser considerados,
estão associados com o estado do sistema e não expressam nenhuma função
realizada pelo sistema. O Quadro 1 apresenta os requisitos não funcionais para o
sistema proposto.
Quadro 1 – Requisitos não funcionais.
TÍTULO DESCRIÇÃO
O sistema deve garantir a segurança dos dados contidos no
1 Segurança
sistema.
Deve possuir uma navegabilidade fácil e intuitiva para facilitar a
2 Navegabilidade
utilização diária.
O sistema deve possuir acesso a múltiplos usuários conectados
3 Multiacesso
simultaneamente e executando tarefas distintas ou não.
O sistema deve atender aos requisitos de forma eficiente para
4 Performance
possibilitar um ciclo de feedbacks curtos.
O sistema deve efetuar a integração com as ferramentas
5 Integração utilizadas de forma a facilitar a utilização por todos os
envolvidos.
56
3.4 PROPOSTA DE SOLUÇÃO
Esse trabalho propõe o desenvolvimento do sistema Ovenbird, baseado no padrão

pipeline de implantação apresentado na seção 2.9. O objetivo do Ovenbird é
gerenciar a transição das solicitações pelos vários estágios de desenvolvimento até
o momento da entrega ao usuário final, através de uma interface amigável que
abstraia a complexidade das ferramenta disponíveis no mercado e facilite, dessa
forma, a utilização por qualquer membro da equipe responsável pelo SLV.
O Ovenbird destina-se a gestão de atividades de Desenvolvimento, Entrega/Revisão

e Nova Versão do mapa de fluxo de valor da Figura 15, visando tratar da gerência
de ambientes e gerência de entrega.
O Ovenbird é um sistema Web que será implantado em um Cloud Hosting para

atender à necessidade da execução de processos de forma paralela ao
desenvolvimento e, para permitir o acesso dos membros da equipe que estiverem
fora das instalações da empresa.
A utilização do Ovenbird inicia-se com o cadastro das informações de todos os

interessados na entrega do SLV; a equipe responsável 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 implantação e
das solicitações que deverão ser desenvolvidas. As propostas de solução para a
gestão destes dois ambientes são descritas nas próximas seções.
3.4.1 Proposta de solução para a Gerência de Ambientes
Os processos de disponibilizar os ambientes na fase de setup (seção 3.1.1) e de

efetuar atualizações, serão executados através de uma ferramenta de automação de
infraestrutura, conforme apresentado na seção 2.6.1, para permitir que o processo
de estabelecer ou restabelecer um estado do ambiente (apropriado para
implantação), seja uma tarefa previsível e com o tempo conhecido.
57
A ferramenta utilizada será o Puppet, descrita na seção 5.2.1.9, uma das primeiras
ferramentas criada desse tipo, bastante popular e com uma grande comunidade
contribuindo com conteúdos, tais como tutoriais e módulos open source.
Pelo fato de estar trabalhando com um sistema base, o SLV, não há diferenças
complexas entre os ambientes dos clientes. As maiores mudanças concentram-se
em dados de configuração. Em cada projeto, deverá ser possível inserir informações
de configuração dos ambientes.
Serão utilizados dois pacotes do Puppet, o Puppet Master e o Puppet Client, como
mostra a Figura 22.
Figura 22 - Utilização do Puppet pelo sistema Ovenbird.
O Puppet Master será instalado junto ao Ovenbird e irá gerenciar as configurações

de cada ambiente. Para manter a gerência de ambientes centralizada, versionada e
passível de auditoria, os arquivos de configuração de ambiente, chamados de
manifestos e, utilizados pelo Puppet, serão escritos pelos desenvolvedores e
armazenados no repositório de código fonte.
Na criação do ambiente, após informar os dados necessários, o Ovenbird efetuará

as configurações 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 solicitação das configurações ao Puppet Master pelo Puppet Client.
O Puppet Client solicita suas configurações e aplica em seu ambiente.
As atualizações dos ambientes serão efetuadas a partir desse momento,

automaticamente pelo Puppet Client em um intervalo determinado de acordo com as
configurações ou pelo desenvolvedor ou gerente de projetos, através do botão
“Provisionar ambiente” disponibilizado no Ovenbird. Quando houver modificações
nos ambientes, elas serão versionadas e adicionadas ao repositório de código pelo
desenvolvedor, logo após, o Puppet Master será atualizado com essas modificações
e na próxima solicitação do Puppet Client, as alterações serão enviadas ao seu
ambiente para que sejam aplicadas.
A Figura 22 também ilustra a utilização da ferramenta Vagrant, apresentada na

seção 5.2.1.11, para a criação de ambientes de desenvolvimento. O Vagrant não é
gerenciado pelo Ovenbird, mas a sua utilização completa o processo de
automatização de ambientes ao permitir usufruir dos recursos do Puppet. O Vagrant
permite a utilização do Puppet Client em uma máquina virtual para solicitar as
configurações ao Puppet Master. Com isso, o ambiente de desenvolvimento será
idêntico entre todos os desenvolvedores e irá refletir o ambiente de produção,
utilizando o mesmo sistema operacional e as mesmas configurações.
Com a utilização do Puppet, as configurações necessárias para a criação de

qualquer ambiente (desenvolvimento, aceitação e produção), ficarão centralizadas
no Ovenbird. Dessa forma, não será necessário acessar um ambiente para efetuar
mudanças manualmente.
3.4.2 Proposta de solução para a Gerência de Solicitações
Para cada SLV um projeto no Ovenbird será criado para que as solicitações sejam
agrupadas. Um novo projeto cria uma área de trabalho onde as solicitações serão
visualizadas. Esta área de trabalho é um reflexo do quadro Kanban mostrado na
Figura 16, com a inclusão de novas colunas para permitir a visualização 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.
Após a definição da solicitação junto ao cliente, ela é cadastrada na coluna

Solicitações, iniciando o processo de entrega. Com o planejamento de uma nova
Sprint, todas as solicitações que deverão ser atendidas nesse período são
agrupadas na coluna A Fazer.
O desenvolvedor, para iniciar suas atividades, move a solicitação que irá

desenvolver para a coluna Fazendo e efetua o check-in no repositório de código
utilizando o Git, ferramenta para controle de versão apresentada na seção 5.2.1.3, e
inicia a codificação. Ao finalizar a solicitação, o desenvolvedor executa os testes de
suas alterações em seu ambiente de desenvolvimento e, após a validação, ele
adiciona o novo código no repositório através de um check-out.
O check-out gera um identificador para representar os arquivos modificados. O

identificador é adicionado à solicitação no Ovenbird e esta é movida para a coluna
Teste Unit.
O repositório de código será monitorado pelo sistema de integração contínua

Jenkins, apresentado na seção 5.2.1.4. Quando uma alteração for detectada, ela
será submetida ao fluxo de testes pelo Jenkins, que é instalado junto com o
Ovenbird. Os passos de testes unitários, testes de integração e testes de aceitação
são gerenciados de forma automática, sendo que o processo só avança ao teste
seguinte se o anterior for bem sucedido. Para fornecer feedback dos processos de
testes, o Jenkins irá atualizar o status da solicitação pelos vários tipos de teste, para
que o Ovenbird possa movimentá-la pelo quadro Kanban de forma automática. Os
testes são criados com a utilização da ferramenta RSpec.
Quando a solicitação passar por todas as etapas de testes automatizados, ela se

torna uma funcionalidade candidata a ir para produção e fica disponível para ser
implantada no ambiente de aceitação pela equipe de qualidade. A solicitação no
Ovenbird fica disponível na coluna Aceitação do quadro Kanban e poderá ser
disponibilizada no ambiente de aceitação clicando-se em um botão no Ovenbird,
60
executando-se a ferramenta Mina. Mina é uma ferramenta para automatização de

implantação apresentada na seção 5.2.1.5.
A automatização proporciona a consistência na execução, tornando o processo

repetível e confiável. Isso permite que a equipe de qualidade possua a liberdade de
implantar uma versão no momento que desejar, agilizando o processo de validação
do que foi desenvolvido junto ao cliente.
Se tudo estiver de acordo como foi especificado, a solicitação é liberada no Ovenbird

para ser implantada no ambiente de produção ficando disponível na coluna
Produção do quadro Kanban. O processo de implantação ocorre da mesma forma
descrita para o ambiente de aceitação.
A implantação de uma versão em ambiente de produção geralmente é uma decisão

do gerente de projetos, mas todos os envolvidos poderão efetuar esse processo
caso seja necessário.
O Quadro 2 lista todas as ferramentas utilizadas para a automatização do processo

de entrega.
Quadro 2 – Ferramentas utilizadas.
NOME DESCRIÇÃO
Puppet Automação de Infraestrutura
Vagrant Automação de Ambiente de Desenvolvimento
Git Sistema de Controle de Versão Distribuído
Mina Automação de Implantação
Jenkins Servidor de Integração Contínua
RSpec / Cucumber Automação de Testes
Conforme (HUMBLE; FARLEY, 2014, p. 106), isso permite que equipes de testes
possam criar e implantar seu próprios ambientes de testes com o apertar de um
botão. Desenvolvedores podem ver quais versões passaram por quais estágios do
processo de entrega e quais problemas foram encontrados, e gerentes podem
verificar e monitorar métricas 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, além de visibilidade sobre o
processo de entrega de modo a identificar, otimizar e remover gargalos. Isso leva a
um processo de entrega que não somente é mais rápido, como mais seguro.
A Figura 24 apresenta o novo fluxo de gerenciamento do sistema com a utilização

de ferramentas para automatizar as etapas do processo de entrega.
Figura 24 - Fluxo do gerenciamento do sistema pelos desenvolvedores após a aplicação das

soluções propostas.
O novo fluxo de gerenciamento não permite que os acessos aos ambientes de

implantação sejam efetuados manualmente pelos desenvolvedores. Todo o código
de configuração, dos ambientes e das lojas virtuais, devem ser versionados e
enviados ao repositório. O Ovenbird efetua o check-out no repositório e, de forma
automatizada, com o auxílio das ferramentas apresentadas, envia as configurações
para os ambientes que as executam. No processo de implantação, a ferramenta
utilizada efetua o check-out no repositório e implanta o SLV no ambiente.
3.5 TRABALHOS CORRELATOS
Esta seção apresenta três ferramentas de integração e as compara com a

ferramenta proposta neste trabalho.
62
3.5.1 Go Continuous Delivery
A Go é uma ferramenta de integração contínua voltada para o gerenciamento de

versões e a distribuição de software em vários computadores. Desenvolvida pela
empresa ThoughtWorks, foi liberada como software livre em 2014.
A Go trabalha com o padrão pipeline de implantação para permitir gerenciar as

alterações no código fonte da aplicação e obter um feedback rápido. A ferramenta
destina-se ao ambiente de desenvolvimento e emprega o ciclo build-test-release
para efetuar implantações sob-demanda. A Figura 25 apresenta o processo de
entrega de uma versão, permitindo ver a evolução e o estado do projeto.
Figura 25 – Tela do pipeline de implantação na ferramenta Go.
Fonte: http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2
3.5.2 Tools Clound
Tools Cloud é uma ferramenta comercial que fornece a integração de várias

ferramentas de código aberto, incluindo controle de versão, gerenciamento de
projetos e acompanhamento de problemas, integração contínua e repositórios de
artefatos, hospedadas e gerenciadas na nuvem, para criar um ambiente completo
através da internet.
Cada cliente recebe um ambiente exclusivo e todas as ferramentas são instaladas

em uma única máquina virtual na nuvem, com armazenamento virtual dedicado.
A Figura 26 apresenta o painel de instalação da ferramenta.

63
Figura 26 – Painel de instalação da Tools Cloud.
Fonte: http://toolscloud.com/
O serviço é acessível via HTTPS e se propõe a resolver problemas de inatividade do

servidor, problemas de backup, problemas de configuração e falhas de segurança
em uma infraestrutura de desenvolvimento para organizações de desenvolvimento
de software de classe mundial.
3.5.3 Trello
O Trello é um sistema para gerenciamento de tarefas que segue o método Kanban.

A empresa Fog Creek Software criou a ferramenta online em setembro de 2011,
para permitir a organização de equipes e tarefas de forma muito mais dinâmica e
facilitada.
Ele permite a criação de diversos quadros, nos quais pode-se criar diversas colunas,
como mostra a Figura 27. Dentro de cada coluna é possível adicionar uma ou mais
tarefas (cards), contendo o conteúdo que o usuário 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 diferenças entre as ferramentas apresentadas e o Ovenbird.
Quadro 3 – Comparativo Ovenbird X GO X Tool Cloud X Trello.
GO Tools Cloud Trello Ovenbird

Gerência de Tarefas X X X
Integração Contínua X X
Provisionamento X X
Implantação Automatizada X X
Controle de Versão X X X
Open Source X X
Com o quadro, pode-se observar que o Ovenbird possui um gerenciamento de

tarefas com os mesmos conceitos do Trello, porém, o Trello não oferece suporte aos
demais itens. A Tools Clound é direcionada para o gerenciamento de ambiente e
instalação de ferramentas. O Ovenbird permite além do provisionamento de
ambiente, uma gerência automatizada do código do sistema. A Go gerencia o código
fonte do sistema e é direcionada para desenvolvedores, enquanto o Ovenbird dá
suporte também ao negócio, com o gerenciamento de solicitações.
65
4. ANÁLISE ORIENTADA A OBJETOS
Esse capítulo apresenta os diagramas derivados da análise orientada a objetos

realizada para o desenvolvimento do sistema Ovenbird. Segundo Pressman (2006,
p. 152), o objetivo da orientação a objetos é definir todas as classes relevantes ao
problema a ser resolvido, as operações e os atributos relacionados a elas, as
relações entre elas e o comportamento que elas exibem.
Na análise orientada a objetos será adotada a Unified Modeling Language (UML)

para especificar, construir, visualizar os artefatos do sistema proposto.
4.1 DIAGRAMA DE CLASSES
Após a documentação dos requisitos no capítulo 3 utilizando-se o Diagrama de

Casos de Uso, serão modeladas as classes necessárias que irão compor e
solucionar as questões levantadas e especificadas.
O diagrama de classes é o diagrama encontrado com maior frequência na

modelagem de sistemas orientados a objetos e mostra um conjunto de classes,
interfaces e colaborações e seus relacionamentos. Uma classe corresponde a algo
tangível, ou a uma abstração conceitual, existente no domínio do usuário ou no
domínio do engenheiro de software (RAMOS, 2006, p. 80). A Figura 28 mostra o
diagrama de classes de análise do sistema Ovenbird.
66
Figura 28 – Diagrama de classes de análise do sistema Ovenbird.
Segundo Bezerra (2003, p. 96), um modelo de classes de análise não leva em

consideração restrições inerentes à tecnologia a ser utilizada na solução de um
problema. Na Figura 28 os interessados pela entrega do sistema estão
representados na classe Membro, que é especializada na classe Usuário,
representando as pessoas do time de desenvolvimento e, na classe Especialista,
representando as pessoas designadas pelo cliente para descrever as
funcionalidades.
Nos ambientes são efetuados várias implantações do sistemas, cada implantação é

composta das solicitações que estão disponíveis. É preciso saber qual versão do
sistema está em determinado ambiente. As solicitações, de acordo com os
resultados dos testes, podem ser atualizadas. A versão de uma solicitação pode ser
alterada até o momento que ela vire uma versão candidata a ir para produção.
67
4.2 DICIONÁRIO DE DADOS
O Quadro 4 apresenta o dicionário de dados referente às classes do sistema

Ovenbird.
Quadro 4 – Dicionário de dados do sistema Ovenbird.

(continua)
Valor
Classes Atributos Obrigatório Descrição
Possíveis
Qual o tipo do ambiente Aceitação /
tipo Sim
que se está criando Produção
O endereço IP para
ip Sim
acesso ao Cloud Hosting
usuario Sim O usuário de acesso
Ambiente
senha Sim A senha de acesso
A URL para acesso via
url Sim
browser
Descrição sobre o
descricao Não
ambiente
nome Sim Nome do cliente
telefone Sim Telefone de contato
Cliente
email Sim E-mail de contato
razaoSocial Não Razão social da empresa
Gargo ocupado na
Especialista ocupacao Sim
empresa
nome Sim Nome do especialista
telefone Não Telefone para contato
Membro email Sim E-mail para contato
Descrição sobre as
descricao Não
atividades do especialista
Data que foi realizada a
data Sim
implantação
sucesso /
Implantacao status Sim O status da implantação
erro
A versão da aplicação que
versao Sim
foi implantada
nome Sim Nome do projeto
Projeto URL do repositório de
urlRepositorio Sim
código fonte
68
Quadro 5 – Dicionário de dados do sistema Ovenbird.

(conclusão)
Valor
Classes Atributos Obrigatório Descrição
Possíveis
nome Sim O titulo da solicitação
A descrição da solicitação
descrição Não
a ser desenvolvida
Data prevista para o inicio
dataInicio Não
do desenvolvimento
Data prevista para o
Solicitacao dataFim Não término do
desenvolvimento
normal/
status Sim O status da validação sucesso /
falhou
1/2/3/4
A posição no quadro
coluna Sim /5/6/7/
Kanban
8
dataInclusao Sim Data de cadastro
Login para acesso ao
login Sim
sistema
Senha para acesso ao
senha Sim
Usuario sistema
Programad
Especifica qual o tipo de or /
tipo Sim usuário que está Gerente de
acessando o sistema projetos /
Qualidade
O código gerado pelo
codigo Sim sistema de controle de
Versao versão
A data que gerou a nova
data Sim
versão
4.3 DIAGRAMAS DE SEQÜÊNCIA
Os diagramas de sequência ilustram interações entre objetos em um determinado

período de tempo e a sequência de eventos que ocorrem em um determinado
processo. Uma interação é uma sequência de mensagens entre típicas instâncias de
classes, componentes, subsistemas ou atores (RAMOS, 2006, p.32).
69
O diagrama de sequência apresentado na Figura 29 tem como objetivo incluir um

novo ambiente e efetuar as configurações iniciais no nó de destino.
Figura 29 – Diagrama de sequência incluirNovoAmbiente.
O diagrama de sequência apresentado na Figura 30 tem como objetivo incluir um

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

nova solicitação para um determinado projeto.
70
Figura 31 – Diagrama de sequência incluirSolicitacao.
O diagrama de sequência apresentado na Figura 32 tem como objetivo executar o

processo de implantação de uma funcionalidade.
Figura 32 – Diagrama de sequência gerarNovaImplantação.
4.4 DIAGRAMA DE ESTADO
Segundo Bezerra (2003, p. 209), um estado é uma situação na vida de um objeto

durante a qual ele satisfaz alguma condição ou realiza alguma atividade. Cada
estado de um objeto é normalmente determinado pelos valores dos seus atributos
e/ou pelas suas ligações com outros objetos.
A UML possui um conjunto de notações 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 solicitação no pipeline
de implantação.
71
Figura 33 – Diagrama de estado de classe funcionalidade.
Quando uma nova solicitação é adicionada ao projeto, ela permanece em seu

estado inicial até após o planejamento da próxima Sprint. Com a definição da Sprint,
a solicitação é agrupada na coluna A Fazer com as demais solicitação que deverão
ser atendidas. O desenvolvedor altera o estado da solicitação para Fazendo assim
que inicia o desenvolvimento. Os próximos estados, são os estados de testes
automatizados, a cada verificação bem sucedida, o estado da solicitação é
atualizado para o próximos estado. Nesse processo de testes, quando ocorrer um
defeito, o estado da solicitação volta ao Fazendo para que seja efetuadas as devidas
correções.
Quando termina o processo de testes, a solicitação fica disponível para ser

implantada no ambiente de aceitação para que a equipe de qualidade verifique os
requisitos especificados pelo cliente. Por fim, a solicitação é liberada para ser
implantada no ambiente de produção, onde alcança o estado pretendido.
72
5. PROJETO E IMPLEMENTAÇÃO
Este capítulo apresenta o projeto e a implementação da ferramenta Ovenbird

proposta.
5.1 PROJETO
O projeto de um sistema constrói representações de programas coerentes e bem

planejadas que se concentram nos inter-relacionamentos das partes de alto nível e
nas operações lógicas envolvidas nos níveis inferiores (PRESSMAN, 2006, p. 207).
O projeto aborda a arquitetura, a interface com o usuário, os componentes
orientados a objetos e o banco de dados da ferramenta. A implementação apresenta
as tecnologias e linguagens utilizadas, as restrições de implementação, a instalação
e funcionamento do protótipo.
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 visíveis desses
componentes e as relações entre eles. O sistema foi desenvolvido orientado a
objetos para a Web na arquitetura Cliente/Servidor e construído no modelo de quatro
camadas, conforme a Figura 34.
Figura 34 – Arquitetura de quatro camadas do sistema Ovenbird.
As camadas da ferramenta proposta são:
• Camada de Apresentação: Interações na interface da aplicação são

realizadas diretamente no servidor Web que recebe a requisição e retorna
73
uma resposta como página web, desenvolvida em HyperText Markup

Language (HTML);
• Camada Lógica: Nesta camada está no servidor de aplicação onde as regras
do negócio são executadas e determinam de que maneira os dados serão
utilizados;
• Camada de Dados: Nesta camada tem-se o servidor de Banco de Dados, no
qual reside toda a informação necessária para o funcionamento da aplicação;
• Camada Cliente: Neste caso, o cliente é o navegador utilizado pelo usuário.
5.1.2 Projeto de interface
Para beneficiar toda a equipe responsável 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 protótipo foi desenvolvida com o auxílio da
biblioteca Bootstrap (http://getbootstrap.com/), fazendo-se uso do HTML e da
Cascading Style Sheets (CSS). O projeto de interface com o usuário relaciona-se
tanto com o estudo de pessoas quanto com aspectos tecnológicos (PRESSMAN,
2006, p. 265). Em geral, decompõe-se em Projeto de Arquitetura da Aplicação Web
e Projeto de Navegação, apresentados a seguir.
5.1.2.1 Projeto de arquitetura da aplicação web
O Projeto de Arquitetura para aplicação web deve descrever como será realizada a
comunicação do usuário com o sistema. A utilização da estrutura hierárquica permite
um fluxo de controle horizontal, por meio da ramificação de hipertexto, ao longo dos
ramos verticais da estrutura (PRESSMAN, 2006, p. 442). A Figura 35 apresenta o
projeto de arquitetura da aplicação web do Ovenbird.
74
Figura 35 – Projeto da Arquitetura Web.
A partir da tela principal, os usuários poderão acessar o menu do Ovenbird e

navegar para as áreas de clientes, projetos e usuários. Na área do cliente, o usuário
poderá visualizar os clientes existentes ou cadastrar um novo. Na tela principal de
projetos, o usuário adquire permissão para cadastrar um novo projeto e visualizar
um projeto já existente. Quando o usuário visualiza um projeto, é possível o cadastro
e a visualização das solicitações e, quando o usuário cadastra um projeto, é
permitido visualizar e cadastrar especialistas além de visualizar e cadastrar
ambientes. Os membros da equipe responsável pelo o SLV são gerenciados através
do menu Usuários. Na tela de usuário é concebido o acesso para visualizar todos os
usuários e cadastrar um novo.
5.1.2.2 Projeto de navegação
A partir do momento que foi estabelecida a arquitetura do Ovenbird e identificados

os seus componentes, deve-se definir caminhos de navegação que permitam ao
usuário ter acesso ao conteúdo e aos serviços oferecidos.
Conforme Pressman (2006, p. 444), o projeto de navegação começa com a

consideração da hierarquia do usuário e os casos de uso relacionados. Cada ator
pode usar a aplicação de forma um tanto diferente e assim ter diferentes
necessidades de navegação.
As Figuras 36, 37 e 38 apresentam os projetos de navegação dos atores

GerenteProjetos, Desenvolvedor e Qualidade, respectivamente.
75
Figura 36 – Projeto de navegação do ator GerenteProjetos.
Figura 37 – Projeto de navegação do ator Desenvolvedor.
Figura 38 – Projeto de navegação do ator Qualidade.

76
5.1.3 Projeto de componente
De acordo com Ramos (2006, p. 128), um componente é uma peça básica na

implementação de um sistema. Ele consiste, na prática, em um conjunto de artefatos
físicos com formato digital, como por exemplo, arquivos de código fonte ou
documentos relativos ao negócio.
Segundo Pressman (2006, p. 239), a abordagem de projeto orientado a objetos trata

não apenas da aplicação, mas também da infraestrutura da aplicação e focaliza a
representação de quatro componentes principais do sistema: Componente de
Domínio do Problema (CDP), Componente de Gerência de Dados (CGD),
Componente de Gerência de Tarefas (CGT) e Componente de Interação Humana
(CIH), que são apresentados a seguir.
5.1.3.1 Componente de Domínio do Problema (CDP)
O componente de domínio do problema corresponde aos subsistemas responsáveis

por implementar diretamente os requisitos dos usuários (COAD; YOURDON, 1993).
A Figura 39 representa o componente de domínio de problema do Ovenbird.
77
Figura 39 – Componente do Domínio do Problema.

78
5.1.3.2 Componente de Interação Humana (CIH)
O Ovenbird é desenvolvido utilizando a linguagem de programação Ruby. As

classes de Interação Humana serão obtidas a partir do pré-processamento de
arquivos com a utilização do sistema de template ERB. O ERB trabalha com as
marcações HTML e código 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 código Ruby para a substituição de

variáveis e controle de fluxo, o que os torna fácil de escrever e manter. Sendo assim,
não será feito um projeto específico para este componente já que a interface é
gerada na medida em que os arquivos .erb são processados.
5.1.3.3 Componente de Gerência de Tarefa (CGT)
O componente de Gerência de Tarefas compreende a definição de tarefas e a

comunicação e coordenação entre elas. A Figura 40 representa o Componente de
Gerência de Tarefas do Ovenbird.
79
Figura 40 – Componente de Gerência de Tarefa.

80
5.1.3.4 Componente de Gerência de Dados (CGD)
O Componente de Gerência de Dados fornece a infraestrutura para a recuperação e

armazenamento dos objetos no sistema (persistência 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 padrão 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 criação e a utilização de objetos de negócios cujos
dados requerem armazenamento persistente para um banco de dados. É uma
implementação do padrão ActiveRecord8, um objeto que envolve uma linha em uma
tabela de banco de dados ou exibição, encapsula o acesso ao banco, e acrescenta
lógica de domínio sobre esses dados (FOWLER, 2010).
Dessa forma não existe o Componente de Gerência 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 são os dispositivos de armazenamento

mais confiáveis e utilizados atualmente, o Ovenbird foi construído utilizando o
sistema gerenciador de banco de dados relacional MySQL, apresentado na seção
5.2.1.6. O projeto do banco de dados relacional é apresentado na Figura 41.
8
http://www.martinfowler.com/eaaCatalog/activeRecord.html
81
Figura 41 – Diagrama relacional de dados.
5.2 IMPLEMENTAÇÃO DO PROTÓTIPO
Esta seção apresenta as tecnologias utilizadas na implementação, as restrições de

implementação, o procedimento para a instalação e funcionamento do protótipo e as
telas do mesmo.
82
5.2.1 Tecnologias utilizadas no protótipo
Para permitir a automatização dos processos relacionados com a entrega de

software, foi selecionado um conjunto de ferramentas disponíveis no mercado. Tais
ferramentas são apresentadas nas próximas seções.
5.2.1.1 Ruby e RubyOnRails
O protótipo proposto foi escrito utilizando a linguagem de programação Ruby

(https://www.ruby-lang.org/en/), por ser uma linguagem totalmente orientada a
objetos com algumas características funcionais, dinâmica, open source e com foco
na simplicidade e produtividade.
Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem

dinâmica e forte, com gerenciamento de memória automático. Seu criador, Yukihiro
Matsumoto, queria uma linguagem que juntasse programação funcional e
imperativa, mas acima de tudo que fosse uma linguagem legível. Esta é uma das
grandes vantagens da linguagem, ser extremamente legível.
Para uma melhor produtividade e desempenho do sistema, o framework

RubyOnRails foi utilizado por fornecer uma solução 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
lógica web de um projeto chamado Basecamp (FUENTES, 2014, p. 4).
Segundo Souza (2014, p. 10), o framework RubyOnRails permite a criação de

aplicações web com extrema rapidez. Essa agilidade tem sido considerada por
várias startups no momento da criação de seus produtos.
5.2.1.2 Cucumber
O Cucumber (http://cukes.info/) é uma ferramenta de testes de aceitação utilizada

para automatizar testes do comportamento do software, levando em conta o ponto
de vista do usuário (BRAÚNA, 2013, p.13). Segundo Humble e Farley (2014, p.
9
http://37signals.com/
83
189), testes de aceitação são voltados para o negócio, não para o desenvolvedor;
eles testam funcionalidades completas em uma versão do sistema.
Com o Cucumber, a especificação do sistema é efetuada através de documentos em

linguagem natural (português), porém, com a possibilidade de executar essa
documentação para verificar o comportamento especificado no sistema real.
O Cucumber estimula a conversa com pessoas de negócio de modo a melhorar o

entendimento dos requisitos e, com o passar do tempo, a especificação criada com
o uso do Cucumber, conhecida como Living Documentation (documentação viva), se
torna uma das principais referências do comportamento do sistema (BRAÚNA, 2013,
p.13).
5.2.1.3 Git
O Git (http://git-scm.com/) é uma ferramenta para registrar alterações feitas em um

conjunto de arquivos ao longo do tempo, uma tarefa tradicionalmente conhecida
como “controle de versão” (SILVERMAN, 2013, p. 9). O Git é um sistema de controle
de versão distribuído, conforme apresentado na seção 2.5.3 e teve sua concepção
em 2005 por Linus Torvalds, para gerenciar o código 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 diferenças entre os diversos estágios do projeto;
• Dividir o desenvolvimento do projeto em múltiplas linhas independentes, os
chamados “branches”, que podem ser desenvolvidos separadamente;
• Recombinar periodicamente os branches em um processo chamado de
“merge” e reacomodar as alterações feitas em dois ou mais branches;
• Permitir que muitas pessoas trabalhem simultaneamente em um projeto,
compartilhando e combinando seu trabalho conforme necessário.
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 prática de integração contínua, tornando mais fácil
para os desenvolvedores integrar suas alterações no projeto;
• Monitorar a execução de tarefas que são agendadas e configuradas, tais
como a execução de testes automatizados.
Uma das vantagens do Jenkins, é que ele é altamente extensível, podendo ser
configurado para se comunicar com diversas outras ferramentas, como a da geração
de uma nova versão de software.
Jenkins trabalha com uma abordagem na qual prioriza as saídas e as informações

de retorno referentes a cada tarefa pré-determinada. Com a utilização da integração
contínua, o desenvolvedor terá um feedback referente ao código que efetuou check-
in conforme definido na configuração 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 automatização de

implantação 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 sessão SSH por implantação, minimizando a sobrecarga da
conexão SSH.
Com a utilização do Mina, utiliza-se o mesmo processo para efetuar implantações

em qualquer ambiente de maneira consistente e confiável (MINA, [2013?]).
5.2.1.6 MySQL
O MySQL (http://www.mysql.com/) é um sistema gerenciador de banco de dados

relacional, multiusuário, multitarefa e open source. É atualmente um dos bancos de
85
dados mais populares, com mais de 10 milhões de instalações pelo mundo. Possui
versões disponíveis para vários sistemas operacionais, entre eles o Linux, Windows
e FreeBSD.
Para utilizar o MySQL, é necessário instalar um servidor e uma aplicação cliente. O

servidor é o responsável por armazenar os dados, responder às requisições,
controlar a consistência dos dados, bem como a execução de transações
concomitantes entre outras. O cliente se comunica com o servidor através da SQL. A
versão gratuita do MySQL é chamada de Edição da Comunidade e possui o servidor
e uma interface gráfica cliente (TONSING, 2006, p. 46).
5.2.1.7 Nginx
O Nginx (http://wiki.nginx.org/Main) é um servidor web rápido, gratuito e open

source, com inúmeras possibilidades de configuração para melhor performance. É
conhecido por sua estabilidade, configuração simples e baixo consumo de recursos.
Escrito por Igor Sysoev em 2002 e teve sua primeira versão pública liberada em
2004. Segundo uma pesquisa da W3techs.com, em março 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 rápido e concorrente para aplicações web Ruby. Criado por Evan Phoenix no
final de 2011, Puma foi construído para a velocidade e paralelismo (PUMA, [2011?].
5.2.1.9 Puppet
O Puppet (http://puppetlabs.com/) é uma ferramenta de automação de infraestrutura

utilizada por diversas empresas que precisam gerenciar milhares de máquinas
físicas e virtuais ao redor do mundo, tais como as empresas MediaWiki Fundation,
Google, e Mozilla Fundation.
Os scripts do Puppet são escritos através de uma linguagem declarativa, baseada

em Ruby. Cada comando que se declara na linguagem é uma diretiva, chamada de
recurso e, é possível definir um conjunto de recursos em um arquivo chamado de
86
manifesto. Uma característica importante dessa ferramenta é a “idempotência” que

permite executar o mesmo código diversas vezes, fazendo com que a ferramenta
altere somente o que for necessário, ou seja, se um pacote já estiver instalado, ele
não será reinstalado.
O ponto positivo dessa abordagem declarativa é poder ter algo bastante específico,
e focado em um só trabalho. A ideia é que se tenha a configuração centralizada em
um único ponto, e essa configuração seja distribuída para diversos nós 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 experiência produtiva e
agradável. Ela permite descrever a aplicação em uma DSL 10 muito simples e
elegante para manter uma documentação atualizada.
Muito usado para descrever aplicações RubyOnRails, com o RSpec é possível testar
qualquer código escrito em Ruby. Ele é composto por diversos módulos que
permitem expressar funcionalidades, cenários e expectativas de como sua aplicação
e/ou objetos devem se comportar.
Embora o RSpec seja muito completo, permitido a criação de vários tipos de testes,
tais como testes unitários, testes de aceitação e testes de performance, é possível
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 fácil de configurar e

reproduzir ambientes de desenvolvimento portáteis, construídos através de
máquinas 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 máquinas são provisionadas em cima do VirtualBox, VMware, AWS, ou

qualquer outro provedor. Então, ferramentas de provisionamento padrão da
indústria, tais como shell scripts, Chef, ou Puppet, podem ser usadas para instalar e
configurar o ambiente na máquina virtual automaticamente (HEIDI, 2014, p. 11).
5.3 RESTRIÇÕES DE IMPLEMENTAÇÃO
O projeto apresentado foi desenvolvido como um protótipo para o sistema Ovenbird.

Com um grau de importância da qualidade da codificação baixo, sua utilização em
produção não será satisfatória.
O controle de acesso, a segurança e testes de usabilidade da interface não foram

observados com a importância adequada, pois não se trata inicialmente do foco
proposto pelo projeto para este protótipo.
O protótipo não contempla a inserção de imagens, utilizadas normalmente para

identificar visualmente um usuário e se restringe a sistemas desenvolvidos na
linguagem de programação Ruby e a atender os processos de desenvolvimento da
empresa apresentada no estudo de caso, sendo inviável sua utilização por equipes
de desenvolvimento que não sigam o fluxo do quadro Kanban da Figura 23.
5.4 INSTALAÇÃO E FUNCIONAMENTO DO PROTÓTIPO
O Ovenbird foi desenvolvido utilizando a linguagem de programação Ruby em sua

versão 2.1.5, instalada em uma plataforma Unix11. A maior parte das distribuições
Linux possuem pacotes de Ruby para serem instalados. O Ruby possui um
gerenciador de pacotes chamado RubyGems (https://rubygems.org/). Com o
RubyGems é possível instalar as ferramentas utilizadas no Ovenbird, tais como o
framework RubyOnRails, a ferramenta Mina e o servidor de aplicação Puma.
O sistema operacional utilizada para efetuar a implantação durante o

desenvolvimento do protótipo foi o Ubuntu Server 14.04 LTS, que é uma distribuição
Linux. Ferramentas como o Mysql, Nginx e Jenkins, podem ser instaladas através do
gerenciador de pacotes do Ubuntu, o apt12.
11
http://www.unix.org/
12
http://linux.die.net/man/8/apt-get
88
Para a instalação o Ovenbird, é necessário ter um sistema operacional em

funcionamento. Para configurar um sistema operacional, o mais recomendado, é um
nó em um Cloud Hosting. Com a utilização do Puppet pelo projeto, a instalação das
ferramentas necessárias ocorre de forma automatizada. No projeto existe uma pasta
chamada “puppet” contendo todos os manifestos (arquivos de configuração do
Puppet) necessários criar um ambiente com o estado desejado.
Primeiramente é necessário efetuar a instalação 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 configuração da

ferramenta Mina e executar a implantação.
5.5 INTERFACE COM O USUÁRIO
Esta seção apresenta as principais telas prototipadas para ferramenta Ovenbird, de

forma a dar suporte aos requisitos apresentados na seção 3.2. A Figura 42
apresenta a tela com a lista de todos os usuários cadastrados no sistema.
Figura 42 – Tela para visualização dos usuários cadastrados.
Esta tela é acessada através do menu Usuários e permite a visualização da listagem

de todos os usuários cadastrados no sistema. Um novo usuário é cadastrado pelo
gerente de projetos clicando no botão “Cadastrar Usuário” para exibir o formulário de
cadastro conforme a Figura 43. Em cada usuário cadastrado, é possível editar e
visualizar suas informações através dos botões “Editar” e “Visualizar”
respectivamente.
89
Figura 43 – Tela para cadastro de usuários.
A Figura 44 apresenta a tela com a lista de todos os clientes cadastrados.
Figura 44 – Tela para visualização dos clientes cadastrados.
Esta tela é acessada através do menu Clientes e permite a visualização da listagem

de todos os clientes cadastrados no sistema. O botão “Cadastrar Cliente” é utilizado
para exibir o formulário de cadastro de um novo clientes conforme apresentado na
Figura 45. Em cada cliente cadastrado, é possível editar e visualizar suas
informações através dos botões “Editar” e “Visualizar” respectivamente.
90
Figura 45 – Tela para cadastro de cliente.
O formulário para o cadastro de novos clientes também é utilizado para exibir as

informações que poderão ser atualizadas, dessa forma, esta tela, de acordo com a
ação executada (cadastrar, editar e visualizar), irá possuir três seções relacionadas.
A primeira seção é o formulário de cadastro de um novo cliente. A segunda seção é
uma listagem de todos os projetos que determinado cliente possui com a
possibilidade de cadastrar, editar e visualizar. A terceira seção exibe a lista de todos
os especialistas indicados pelo cliente e permite o cadastro, a visualização e a
atualização. A segunda e a terceira seção, não 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 formulário para cadastro de um novo projeto, sendo também
utilizada para exibir as informação que poderão ser atualizadas de acordo com a
ação executada (cadastrar, editar e visualizar). A tela possui três seções
relacionadas. A primeira seção é o formulário para cadastro das informações de um
projeto. A segunda seção, é a lista de todos os ambientes já configurados para este
projeto. Nota-se que nesta seção há dois botões em destaque; o botão “Configurar”
que executa o caso de uso InstalarPuppet e o botão “Provisionar”, responsável por
executar o caso de uso ProvisionarAmbiente e deixar o ambiente em um estado
adequado para implantação. A terceira seção é a lista dos especialistas que irão
contribuir para o desenvolvimento da loja virtual.
A Figura 48 apresenta a tela para cadastro de um novo ambiente, sendo possível a

escolha do tipo aceitação ou produção.
92
Figura 48 – Tela para cadastro de ambiente.
A Figura 49 apresenta a tela para a visualização de todos os projetos, agrupados por

clientes.
Figura 49 – Tela para cadastro de ambiente.
A partir dessa tela será possível acessar o quadro Kanban com as funcionalidades
clicando no botão “Visualizar Projeto” de cada projeto cadastrado.
A Figura 50 apresenta a tela do quadro Kanban onde será possível visualizar o

processo do pipeline de implantação.
93
Figura 50 – Tela do pipeline de implantação.

94
Esta tela apresenta as solicitações de um projeto agrupadas nas colunas que

representam as etapas do pipeline de implantação. Os botões para a implantação
automatizada do sistema são disponibilizados após os testes automatizados. O
botão verde efetua a implantação no ambiente de aceitação e o botão laranja, efetua
a implantação no ambiente de produção.
A Figura 51 apresenta a tela para cadastro de uma nova solicitação pelo ator
GerenteProjetos.
Figura 52 – Tela para cadastro de solicitação.

95
6. CONCLUSÃO PERSPECTIVAS FUTURAS
O processo de desenvolvimento é um conceito de âmbito muito vasto e pretende

designar uma sequência de atividades, normalmente agrupadas em fases e tarefas,
executadas de forma sistemática e uniformizada, realizadas por pessoas com
responsabilidades bem definidas e que, a partir de um conjunto de entradas
produzem um conjunto de saída (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 máquina e o mesmo não funcionando em outra; a
execução de processos repetitivos, tais como a execução de testes, que ocupam
demasiadamente a equipe de desenvolvimento; conflitos na junção dos trabalhos
realizados pelos desenvolvedores com o processo de integração do código
demorado, aumentando o custo para a correção de defeitos e gerando um ciclo de
feedback longo; a criação de vários ambientes heterogênicos oriundos de
configurações manuais, sem auditoria e realizadas por pessoas diferentes e erros ao
efetuar a implantação de uma versão em produção, quando é necessário fazer
julgamentos a cada passo do processo por humanos.
A ferramenta proposta neste trabalho tem como objetivo gerenciar a transição das
solicitações pelos vários estágios do desenvolvimento até o momento da entrega ao
usuário final, para permitir que a equipe responsável pelo SLV responda às
mudanças de forma eficiente, aumente a capacidade de gerar novas versões bem-
sucedidas e de liberá-las sob demanda e implante o seu sistema de loja virtual em
qualquer ambiente instantaneamente para refletir as mudanças de uma forma
eficiente e com baixo custo. Para isso, a ferramenta proposta realiza a integração de
ferramentas para a automatização de infraestrutura, integração continua do código,
execução de testes automatizados e a automatização da implantação, abstraindo a
complexidade da utilização através de uma interface amigável e que permita a
manipulação por qualquer membro da equipe.
A metodologia adotada abrangeu uma revisão bibliográfica sobre os principais temas

envolvidos no processo de entrega automatizada de software, das metodologias
96
ágeis de desenvolvimento, das ferramentas disponíveis no mercado que dão suporte

para a automatização e do desenvolvimento de software.
A ferramenta foi desenvolvida utilizando o paradigma da orientação a objetos com a

linguagem de programação Ruby, o framework RubyOnRails e o SGBD MySQL,
efetuando a integração entre as ferramentas Puppet, Git, Mina, Jenkins, RSpec e
Cucumber, para permitir a automatização do pipeline de implantação.
Como contribuições deste trabalho pode-se citar o entendimento do mapa do fluxo

de valor obtido através de uma visão holística dos processos realizados na empresa
do estudo de caso, a pesquisa, análise e utilização de ferramentas open source para
automatizar tarefas até então manuais e, o levantamento e documentação dos
requisitos que devem ser atendidos por um sistema para permitir a integração de
ferramentas e a utilização por pessoas com diferentes níveis técnicos.
O protótipo desenvolvido demonstrou a viabilidade da proposta. Dessa forma todos

os envolvidos no processo de entrega conseguem acesso daquilo que precisam e
quando precisam. A equipe de qualidade consegue implantar uma versão no
momento que desejar, agilizando o processo de validação junto ao cliente.
Desenvolvedores podem ver quais versões passaram por quais estágios do
processo de entrega e quais problemas foram encontrados, gerando um ciclo de
feedback curto e gerentes de projetos podem verificar e monitorar métricas
fundamentais como tempo de ciclo e qualidade de software. Resultados obtidos
através da utilização de práticas inclusas nas metodologias ágeis de
desenvolvimento tais como a integração contínua, gerência de configuração, testes
automatizados, gerência de infraestrutura e ambientes e a visualização do fluxo de
trabalho através do quadro Kanban, permitindo identificar, otimizar e remover
gargalos para tornar o processo de entrega confiável, rápido e mais seguro.
As perspectivas futuras deste trabalho incluem ajustes para incorporar requisitos de

qualidade necessários a software profissionalmente desenvolvido, a implementação
das funções não contempladas nessa versão do protótipo, o teste da ferramenta e a
implantação da mesma na empresa onde foi realizado o estudo de caso para
observação dos resultados de melhoria alcançados.
97
REFERÊNCIAS
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 Prático. Rio de
Janeiro: Campus, 2002. 333 p.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML, São
Paulo: Campus, 2003.
BRAÚNA, Hugo. Cubumber e Rspec, São Paulo: Casa do Código, 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. Disponível 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. Disponível 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
Conclusão de Curso – UNICAMP, Limeira, 2010.
FOWLER, Martin. Active Record, 2010. On-line. Disponível em:
<http://www.martinfowler.com/eaaCatalog/activeRecord.html>. Acesso em: 23 nov.
2014.
FOWLER, Martin. Continuous Integration, 2006. On-line. Disponível em:
<http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 09 nov.
2014.
FOWLER, Martin. Deployment Pipeline. 2013. On-line. Disponível em:
<http://martinfowler.com/bliki/DeploymentPipeline.html>. Acesso em: 17 out 2014
FOWLER, Martin. The New Methodology, 2005. On-line. Disponível em:
<http://www.martinfowler.com/articles/newMethodology.html#N8B>. Acesso em: 01
nov. 2014.
FUENTES, V. B. Ruby On Rails: Coloque sua aplicação nos trilhos. São Paulo:
Casa do Código, 2014. 360 p.
GEORGE, M. RSpec: Crie especificações executáveis em Ruby. São Paulo:
Casa do Código, 2014. 176 p.
HEIDI, Erika. Vagrant CookBook. Canada: Leanpub. 2014. 125 p.
HUMBLE, J.; FARLEY, D. Entrega Contínua: Como entregar software de forma
rápida e confiável. Porto Alegre: Bookman, 2014. 464 p.
HUMBLE, Jez. Continuous Delivery e o Movimento DevOps. 2011. On-line.
Disponível em: <http://www.infoq.com/br/articles/jezhumble-continuous-delivery-
devops/>. Acesso em: 10 out 2014.
98
HASHIMOTO, Mitchell. DevOps de zero a 100%: Níveis e passos de adoção.

2013. On-line. Disponível em: <http://www.infoq.com/br/articles/wide-range-devops>.
Acesso em: 09 nov. 2014.
KNINGERG, H. Scrum e XP Direto das Trincheiras: Como nós fazemos Scrum,
São Paulo: C4Media, 2007. 131 p.
KNINGERG, H.; SKARIN, M. Kanban e Scrum: Obtendo o Melhor de Ambos, São
Paulo: C4Media, 2009. 139 p.
LOPES, Camilo. TDD na prática. Rio de Janeiro: Ciência Moderna, 2012. 116 p.
MANIFESTO ÁGIL. Manifesto para o Desenvolvimento Ágil de Software. 2001.
On-line. DisponÍvel em: <http://manifestoagil.com.br/ >. Acesso em: 27 out 2014.
MINA. Really fast deployer and server automation tool. On-line. Disponível em:
<http://mina-deploy.github.io/mina/upgrading.html>. Acesso em: 28 nov 2014.
NGINX. Nginx Community. On-line. Disponível 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, São Paulo: McGraw-Hill, 2006. 720 p.
PUMA. Built For Speed & Concurrency. On-line. Disponível em: <http://puma.io/>.
Acesso em: 28 nov 2014.
PUPPET LABS. Puppet Labs Documentation. On-line. Disponível em:
<https://docs.puppetlabs.com/>. Acesso em: 28 nov 2014.
RAMOS, Ricardo A. Treinamento Prático em UML. São Paulo: Digerati Books,
2006, 144 p.
SATO, Danilo. DevOps na Prática: Entrega de Software Confiável e
Automatizada. São Paulo: Casa do Código, 2013. 230 p.
SILVERMAN, R. E. Git: Guia Prático. São Paulo: Novatec, 2013. 207 p.
SOUZA, Lucas. Ruby: Aprenda a programar na linguagem mais divertida. São
Paulo: Casa do Código, 2014. 285 p.
TAVARES, B. Puppet e Vagrant: Como provisionar máquinas para seu projeto.
2013. On-line. Disponível em: http://www.thoughtworks.com/pt/insights/blog/puppet-
and-vagrant-how-provision-machines-your-project. Acesso em: 09 nov. 2014.
TELES, Vinícius Manhães. Extreme Programming. 2006. On-line. Disponível em:
<http://desenvolvimentoagil.com.br/xp/>. Acesso em: 29 out 2014.
TELES, Vinícius Manhães. Extreme Programming. São Paulo: Novatec Editora,
2004.
TONSING, S. L. MySQL: Aprendendo na Prática. Rio de Janeiro: Editora Ciência
Moderna. 2006.
URUBATAN, Rodrigo. Ruby on Rails. São Paulo: Novatec Editora, 2012
VARASCHIM, J. D. Implantando o Scrum em um Ambiente de Desenvolvimento
de Produtos para Internet. 2009. 21f. Monografias em Ciência da Computação –
PUC, Rio de Janeiro, 2009.
99
ANEXOS
ANEXO A – Casos de Uso do Sistema Proposto
Descrição de Caso de Uso

Projeto: Ovenbird
Subsistema:
Caso de Uso: Principal
Analista: Leandro Souza Nunes.
Data: 27/11/2014
Descrição: Esse caso de uso tem por objetivo o gerenciamento das solicitações de
cada cliente, a criação dos ambientes para implantação do SLV e o gerenciamento
das informações dos interessados no desenvolvimento do sistema, o cliente e a
equipe de desenvolvimento (usuário).
O Ovenbird possui os seguintes atores:

• GerenteProjetos: representa a pessoa responsável por controlar o fluxo de
desenvolvimento das solicitações de cada cliente;
• Desenvolvedor: responsável pelo desenvolvimento das solicitações bem
como a configuração dos ambientes e a implantação da loja;
• Qualidade: responsável por efetuar testes no ambiente de aceitação para
validar a entrega do desenvolvimento junto ao cliente.
100

Projeto: Ovenbird
Subsistema: Diagrama de Caso de Uso Principal
Caso de Uso: CadastrarGeral
Data: 27/11/2014
Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas

informações referente aos interessados no desenvolvimento da loja virtual, contendo
todos os cadastros necessários 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.
101

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

cadastra um usuário. Este processo é separado em quatro cenários: cadastrar,
alterar, excluir e consultar um usuário.
Caso de uso: CadastrarUsuario

Ator: GerenteProjetos
Pré-condições: Não se aplica.
Pós-condições: Não se aplica.
Fluxo Principal:
1. O ator solicita cadastrar um novo usuário.
2. O ator informa os dados necessários (nome, e-mail, descrição (opcional),
telefone, login, senha e tipo) para cadastro do usuário.
3. O sistema verifica se as informações são válidas.
4. O sistema informa que o usuário foi cadastrada com sucesso.
Fluxo Alternativo:
3a. Dados necessários inválidos
3a. 1 O sistema informa qual ou quais dados estão incorretos.
3a. 2 O sistema retorna ao Fluxo Normal passo 2.
Caso de uso: AlterarUsuario

Pré-condições: O usuário deve estar cadastrado.
102
Fluxo Principal:
1. O ator solicita alterar um usuário.
2. O ator informa os dados necessários (nome, e-mail, descrição (opcional),
telefone, login, senha e tipo) para alterar o usuário.
4. O sistema informa que o usuário foi alterado com sucesso.
Fluxo Alternativo:
3a. 1 O sistema informa qual ou quais dados estão incorretos
Caso de uso: ExcluirUsuario

Fluxo Principal:
1. O ator solicita excluir um usuário
2. O ator informa o usuário a ser excluído.
3. O sistema verifica se o usuário existe.
4. O sistema pede confirmação para exclusão do usuário.
5. O sistema informa que o usuário foi excluído com sucesso.
Fluxo Alternativo:
3a. Usuário informado não existe
3a. 1 O sistema informa que o usuário não existe.
Caso de uso: ConsultarUsuario

103
Fluxo Principal:
1. O ator solicita consultar um usuário.
2. O ator informa o usuário a ser consultado.
3. O sistema verifica se o usuário existe.
4. O sistema mostra as informações do usuário consultado.
Fluxo Alternativo:
3a. O usuário informado não existe
3a. 1 O sistema informa que o usuário não existe.
104

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 cenários: cadastrar,
alterar, excluir e consultar um usuário.
Caso de uso: CadastrarCliente

Pré-condições: Não se aplica.
Fluxo Principal:
1. O ator solicita cadastrar um novo cliente.
2. O ator informa os dados necessários (nome, e-mail, razão social, telefone)
para cadastro do cliente.
4. O sistema informa que o cliente foi cadastrado com sucesso.
Fluxo Alternativo:
Caso de uso: AlterarCliente

Pré-condições: O cliente deve estar cadastrado.
105
Fluxo Principal:
1. O ator solicita alterar um cliente.
2. O ator informa os dados necessários (nome, e-mail, razão 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 excluído.
3. O sistema verifica se o cliente existe.
4. O sistema pede confirmação para exclusão do cliente.
5. O sistema informa que o cliente foi excluído com sucesso.
Fluxo Alternativo:
3a. Cliente informado não existe
3a. 1 O sistema informa que o cliente não existe.
106
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 informações do cliente consultado.
Fluxo Alternativo:
3a. O cliente informado não existe
3a. 1 O sistema informa que o cliente não existe.
107

Projeto: Ovenbird
Caso de Uso: GerenciarAmbientes
Data: 27/11/2014
Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas

informações referente aos ambientes onde a loja virtual será implantada, contendo
todos os cadastros necessários para que o gerente de projetos e o desenvolvedor
possa administrar a entrega do sistema SLV. Sendo assim, será contemplado nesse
subsistema os casos de uso CadastrarAmbiente, ProvisionarAmbiente e
InstalarPuppet.
108

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

o desenvolvedor cadastra um ambiente. Este processo é separado em quatro
cenários: cadastrar, alterar, excluir e consultar um ambiente.
Caso de uso: CadastrarAmbiente

Ator: GerenteProjetos e Desenvolvedor
Pré-condições: O cliente e o projeto devem estar cadastrados.
Pós-condições: Habilita os botões 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 necessários (tipo, descrição, url, ip, usuário e
senha) para cadastro do ambiente.
4. O sistema informa que o ambiente foi cadastrado com sucesso.
Fluxo Alternativo:
109
Caso de uso: AlterarAmbiente

Pré-condições: O ambiente deve estar cadastrado.
Fluxo Principal:
1. O ator solicita alterar um cliente.
2. O ator informa os dados necessários (tipo, descrição, url, ip, usuário 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 excluído.
3. O sistema verifica se o ambiente existe.
4. O sistema pede confirmação para exclusão do ambiente.
5. O sistema informa que o ambiente foi excluído com sucesso.
Fluxo Alternativo:
3a. Ambiente informado não existe
3a. 1 O sistema informa que o ambiente não existe.
110
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 informações do ambiente consultado.
Fluxo Alternativo:
3a. O ambiente informado não existe
111

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 botão “Configurar”.
5. O ator clica no botão para executar o processo de instalação.
6. O sistema informa que o ambiente foi configurado com sucesso.
Fluxo Alternativo:
3b. Informações de acesso ao ambiente erradas
3b. 1 O sistema informa que não conseguir acessar o ambiente.
3b. 2 O sistema retorna ao Fluxo Normal passo 4.
112

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 botão “Provisionar”.
5. O ator clica no botão para executar o processo de provisionamento.
6. O sistema informa que o ambiente foi provisionado com sucesso.
Fluxo Alternativo:
3b. Informações de acesso ao ambiente erradas
3b. 1 O sistema informa que não conseguir acessar o ambiente.
3b. 2 O sistema retorna ao Fluxo Normal passo 4.
113

Projeto: Ovenbird
Caso de Uso: GerenciarSolicitacoes
Data: 27/11/2014
Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas as

solicitações de um cliente que deverão ser atendidas, contendo todos os cadastros
necessários para que os atores possam administrar o desenvolvimento na empresa
estudada. Sendo assim, será contemplado nesse subsistema os casos de uso
CadastrarProjeto, CadastrarSolicitacao, AgruparSolicitacoesSprint,
IniciarDesenvolvimento, EnviarParaVerificacao, ExecutarTestesAutomatizados,
DisponibilizarVersaoEmAceitacao e ImplantarVersaoEmProducao.
114

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 cenários: 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 necessários (cliente, nome e url do repositório)
para cadastro do projeto.
4. O sistema informa que o projeto foi cadastrado com sucesso.
Fluxo Alternativo:
115
Caso de uso: AlterarProjeto

Pré-condições: O projeto deve estar cadastrado.
Fluxo Principal:
1. O ator solicita alterar um projeto.
2. O ator informa os dados necessários (cliente, nome e url do repositório)
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 excluído.
3. O sistema verifica se o projeto existe.
4. O sistema pede confirmação para exclusão do projeto.
5. O sistema informa que o projeto foi excluído com sucesso.
Fluxo Alternativo:
3a. O projeto informado não existe
3a. 1 O sistema informa que o projeto não existe.
116
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 informações do projeto consultado.
Fluxo Alternativo:
3a. 1 O sistema informa que o projeto não existe.
117

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

o desenvolvedor cadastra uma solicitação. Este processo é separado em quatro
cenários: cadastrar, alterar, excluir e consultar um projeto.
Caso de uso: CadastrarSolicitacao

Fluxo Principal:
1. O ator solicita cadastrar uma nova solicitação.
2. O ator informa os dados necessários (nome, data de início, data da
finalização e descrição) para cadastro de uma solicitação.
4. O sistema informa que a solicitação foi cadastrada com sucesso.
Fluxo Alternativo:
118
Caso de uso: AlterarSolicitacao

Pré-condições: A solicitação deve estar cadastrada.
Fluxo Principal:
1. O ator solicita alterar uma solicitação.
2. O ator informa os dados necessários (nome, data de início, data da
finalização e descrição) para alterar a solicitação.
4. O sistema informa que a solicitação foi alterada com sucesso.
Fluxo Alternativo:
Caso de uso: ExcluirSolicitacao

Ator: GerenteProjetos e Desenvolvedor.
Pré-condições: A solicitação deve estar cadastrado.
Fluxo Principal:
6. O ator solicita excluir uma solicitação.
7. O ator informa a solicitação a ser excluída.
8. O sistema verifica se a solicitação existe.
9. O sistema pede confirmação para exclusão da solicitação.
10. O sistema informa que a solicitação foi excluída com sucesso.
Fluxo Alternativo:
3a. 1 O sistema informa que a solicitação não existe.
119
Caso de uso: ConsultarSolicitacao

Ator: GerenteProjetos e Desenvolvedor.
Pré-condições: A solicitação deve estar cadastrado.
Fluxo Principal:
1. O ator solicita consultar uma solicitação.
2. O ator informa a solicitação a ser consultada.
3. O sistema verifica se a solicitação existe.
4. O sistema mostra as informações da solicitação consultada.
Fluxo Alternativo:
3a. A solicitação informada não existe
3a. 1 O sistema informa que a solicitação não existe.
120

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

agrupa as solicitação que serão desenvolvidas na próxima Sprint.
Caso de uso: AgruparSolicitacoesSprint

Pré-condições: A solicitação deve estar cadastrada.
Fluxo Principal:
2. O ator move a solicitação da coluna Solicitações para a coluna A Faze.
3. O sistema atualiza o status da solicitação.
121

Projeto: Ovenbird
Caso de Uso: IniciarDesenvolvimento
Data: 27/11/2014
Descrição: 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é-condições: A solicitação deve estar na coluna A Fazer.
Fluxo Principal:
2. O ator move a solicitação da coluna A Fazer para a coluna Fazendo.
122

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

a solicitação que acabou de desenvolver e libera a mesma para testes.
Caso de uso: EnviarParaVerificacao

Ator: Desenvolvedor
Pré-condições: A solicitação deve estar na coluna Fazendo
Fluxo Principal:
2. O ator adiciona o código do Git na solicitação.
3. O ator move a solicitação da coluna Fazendo para a coluna Teste Unit.
123

Projeto: Ovenbird
Caso de Uso: ExecutarTestesAutomatizados
Data: 27/11/2014
Descrição: Este caso de uso descreve o processo em que o SIC inicia o processo
de testes da solicitação informada.
Caso de uso: ExecutarTestesAutomatizados

Ator: SIC
Pré-condições: A solicitação deve estar na coluna Teste Unit.
Fluxo Principal:
1. O ator verificar se a solicitação está no repositório de código.
2. O ator faz o check-in no repositório.
3. O ator executa os testes automatizados.
4. O sistema atualiza o status da solicitação em cada etapa dos testes.
124

Projeto: Ovenbird
Caso de Uso: DisponibilizarVersaoEmAceitacao
Data: 27/11/2014
Descrição: Este caso de uso descreve o processo em que uma solicitação é

instalado no ambiente de aceitação.
Caso de uso: DisponibilizarVersaoEmAceitacao

Ator: GerenteProjetos, Desenvolvedor, Qualidade
Pré-condições: A solicitação deve estar na coluna Aceitação.
Fluxo Principal:
2. O ator clica no botão para iniciar o processo.
3. O sistema executa a ferramenta de implantação.
125

Projeto: Ovenbird
Caso de Uso: ImplantarVersaoEmProducao
Data: 27/11/2014
Descrição: Este caso de uso descreve o processo em que uma solicitação é

instalado no ambiente de aceitação.
Caso de uso: ImplantarVersaoEmProducao

Ator: GerenteProjetos, Desenvolvedor, Qualidade
Pré-condições: A solicitação deve estar na coluna Produção.
Fluxo Principal:
2. O ator clica no botão para iniciar o processo.
3. O sistema executa a ferramenta de implantação.

Automatizacao de Entrega de Software em

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

Automatizacao de Entrega de Software em

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAÇÃO DE ASSISTÊNCIA E EDUCAÇÃO – FAESA

FACULDADES INTEGRADAS ESPÍRITO-SANTENSE

LEANDRO SOUZA NUNES

AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM

AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM

Trabalho de Conclusão de Curso de

Trabalho de Conclusão do Curso de Graduação em Ciências da Computação

AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM

Denise Franzotti Togneri

Eliana Cáus Sampaio

Daniel Barbosa Oliveira

Vitória, 10 de dezembro de 2014

Palavras-chave: Entrega Contínua de Software. Provisionamento de ambientes.

FIGURA 1 – AGRUPAMENTO DAS PRÁTICAS DA XP. ......................................................... 20

CSS – Cascading Style Sheets

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 integração Contínua

SQL – Structured Query Language

TDD – Test Driven Development

URL – Uniform Resource Locator

VCS – Version Control System

WEB – Wolrd Wide Web

2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL ................... 16

3. UMA PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE 43

4. ANÁLISE ORIENTADA A OBJETOS ................................................................... 65

5. PROJETO E IMPLEMENTAÇÃO ......................................................................... 72

6. CONCLUSÃO PERSPECTIVAS FUTURAS......................................................... 95

Com a globalização e o aumento ao acesso à banda larga, o mundo vive uma

O objetivo da automatização de processos é tornar a entrega de software confiável,

de desenvolvimento e permitindo implantar o sistema para qualquer ambiente

Uma empresa sediada em Vitória ES é especializada em soluções para lojas virtuais

A forma como os processos relacionados ao desenvolvimento de software são

No término do ciclo de desenvolvimento, o sistema terá uma versão disponibilizada

Implantar novos códigos ao sistema da loja já em funcionamento é extremamente

1.2 FORMULAÇÃO DO PROBLEMA

Como coordenar atividades relacionadas com a entrega de software, tais como a

Para apoiar a solução dos problemas levantados, uma proposta de solução é o

Construir um software capaz de integrar ferramentas, técnicas e boas práticas que

• Investigar o fluxo de desenvolvimento de software para a elaboração de uma

Com o desenvolvimento de um software para a integração de ferramentas,

Inicialmente será feita uma revisão bibliográfica sobre as práticas de

1.7 ORGANIZAÇÃO DA MONOGRAFIA

Este trabalho contém, além desta Introdução, mais 5 capítulos.

O capítulo 2 – METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL –

O capítulo 3 – PROPOSTA PARA AUTOMATIZAÇÃO DE ENTREGA DE

O capítulo 4 – ANÁLISE ORIENTADA A OBJETOS – apresenta a análise orientada

O capítulo 5 – PROJETO E IMPLEMENTAÇÃO – mostra como será projetada e

O capítulo 6 – CONCLUSÃO PERSPECTIVAS FUTURAS – onde são apresentadas

2 METODOLOGIAS DE DESENVOLVIMENTO EM AMBIENTE ÁGIL

Este capítulo contextualiza o surgimento das metodologias ágeis utilizadas em

2.1 MANIFESTO ÁGIL

Em 2001, 17 pensadores de desenvolvimento de software, dentre eles: Martin

• Indivíduos e interações mais que processos e ferramentas;

Os processos ágeis de desenvolvimento de software compartilham um conjunto de