TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

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. Para inibir riscos com perda de oportunidades no universo
web, a empresa objeto do estudo de caso deste trabalho evita os longos ciclos de
desenvolvimento tradicionais adotando as metodologias ágeis, fazendo uso das
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 em qualquer ambiente instantaneamente,
refletindo as mudanças de uma forma eficiente e com baixo custo.
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................................................ 24
FIGURA 4 – EXEMPLO DE UM QUADRO KANBAN............................................................... 25
FIGURA 5 – EXEMPLO DE UM QUADRO KANBAN EM DESENVOLVIMENTO DE SOFTWARE....... 26
FIGURA 6 – DIAGRAMA DE UM SISTEMA DE VERSÃO LOCAL............................................... 27
FIGURA 7 – DIAGRAMA DE UM SISTEMA DE VERSÃO CENTRALIZADO.................................. 28
FIGURA 8 – DIAGRAMA DE UM SISTEMA DE VERSÃO DISTRIBUÍDO...................................... 29
FIGURA 9 – QUATRO QUADRANTE DE TESTES DESCRITOS POR BRIAN MARICK. ................. 32
FIGURA 10 – CICLO DO TDD......................................................................................... 34
FIGURA 11 – PROCESSO DE INTEGRAÇÃO CONTÍNUA COM O AUXILIO DE FERRAMENTAS..... 35
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. ...................... 38
FIGURA 14 – EQUIPES ENVOLVIDAS NO MOVIMENTO DEVOPS.......................................... 41
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 – PARTE ESTÁTICA - 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.................................................. 25
2.5 SISTEMA DE CONTROLE DE VERSÃO....................................................... 26
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 Cloud ............................................................................................... 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 E PERSPECTIVAS FUTURAS ..................................................... 95
REFERÊNCIAS......................................................................................................... 98
ANEXOS.................................................................................................................. 100

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 diante da 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. 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 onde as práticas no círculo vermelho estão relacionadas com os
requisitos, no círculo verde, são práticas relacionadas com a qualidade do sistema
desenvolvido e no círculo azul, prática relacionadas com o desenvolvimento, a
codificação do sistemas.
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

21
implementado logo no início do projeto e vai ganhando novas funcionalidades ao
longo do tempo.
Segundo Astels, Miller e Novak (2002, p. 181), a melhor maneira de adotar a XP é
utilizá-la em 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://calvinx.com/2014/05/22/why-scrum-why-agile-development/
Varaschim (2009, p. 3) descreve o ciclo de desenvolvimento onde a primeira etapa
dentro da Sprint é a 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.
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,

23
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
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

24
anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia
que se inicia;
• Sprint Review: realizada ao final de cada Sprint para que o Scrum Team
mostre o que foi 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.
Figura 3 – Exemplo de um gráfico Burndown Chat.
Fonte: http://www.brq.com/metodologias-ageis/

25
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
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

26
ou metodologia de gerenciamento de projetos. O entendimento do processo se dá
ao mapear o fluxo de valor conforme a Figura 5 e ao concordar em limitar as
atividades em andamento (Work-In-Progress ou WIP).
Atualmente, o Kanban é muitas vezes usado em conjunto com o Scrum, porque 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;
• 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.

27
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.
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.

28
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.
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.

29
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.
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.

30
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
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.

31
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.
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/);
• 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
2
Acesse http://martinfowler.com/bliki/SnowflakeServer.html para mais detalhes sobre
Snowflake Server.

32
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,
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

33
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.
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.

34
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.
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:
• 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;
• 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;
• 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.

35
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.
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.

36
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
desenvolvimento recebendo informações sobre defeitos depois de já estarem
trabalhando há semanas em outras funcionalidades e a descoberta, já no fim do
processo de desenvolvimento, de que a arquitetura da 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.

37
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
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.

38
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
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

39
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.
Ë 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,

40
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;
• 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;
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

41
• 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 Day4
, demonstrando como a Flickr5
efetuava 10
implantações por dia e através da convergência de outros movimentos adjacentes
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
4
Acesse o video em: https://www.youtube.com/watch?v=LdOe18KhtT4
5
www.flickr.com

42
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.

48
Durante o ciclo de desenvolvimento, diversos problemas ocorrem, tais como:
• Os desenvolvedores codificam as funcionalidades em seus ambientes de
desenvolvimento sem o controle sobre as 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:
GerenciarSolicitacoes, GerenciarAmbientes e CadastrarGeral 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,
InstalarPuppet 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 Cloud 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
1 Segurança
O sistema deve garantir a segurança dos dados contidos no
sistema.
2 Navegabilidade
Deve possuir uma navegabilidade fácil e intuitiva para facilitar a
utilização diária.
3 Multiacesso
O sistema deve possuir acesso a múltiplos usuários conectados
simultaneamente e executando tarefas distintas ou não.
4 Performance
O sistema deve atender aos requisitos de forma eficiente para
possibilitar um ciclo de feedbacks curtos.
5 Integração
O sistema deve efetuar a integração com as ferramentas
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.

TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (13)

Semelhante a TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO

Semelhante a TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO (20)

TCC - AUTOMATIZAÇÃO DE ENTREGA DE SOFTWARE EM AMBIENTE ÁGIL DE DESENVOLVIMENTO