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.

57

A ferramenta utilizada será o Puppet, descrita na seção 5.2.1.9, uma das primeiras

ferramentas criadas desse tipo, bastante popular e com uma grande comunidade

contribuindo com conteúdos, tais como tutoriais e módulos open source.

Pelo fato de estar trabalhando com um sistema base, o SLV, não há diferenças

complexas entre os ambientes dos clientes. As maiores mudanças concentram-se

em dados de configuração. Em cada projeto, deverá ser possível inserir informações

de configuração dos ambientes.

Serão utilizados dois pacotes do Puppet, o Puppet Master e o Puppet Client, como

mostra a Figura 22.

Figura 22 - Utilização do Puppet pelo sistema Ovenbird.

O Puppet Master será instalado junto ao Ovenbird e irá gerenciar as configurações

de cada ambiente. Para manter a gerência de ambientes centralizada, versionada e

passível de auditoria, os arquivos de configuração de ambiente, chamados de

manifestos e, utilizados pelo Puppet, serão escritos pelos desenvolvedores e

armazenados no repositório de código fonte.

Na criação do ambiente, após informar os dados necessários, o Ovenbird efetuará

as configurações iniciais no nó de destino para permitir o provisionamento. Nesse

processo, será instalado e configurado o Puppet Client. O provisionamento será

58

efetuado com a solicitação das configurações ao Puppet Master pelo Puppet Client.

O Puppet Client solicita suas configurações e aplica em seu ambiente.

As atualizações dos ambientes serão efetuadas a partir desse momento,

automaticamente pelo Puppet Client em um intervalo determinado de acordo com as

configurações ou pelo desenvolvedor ou gerente de projetos, através do botão

“Provisionar ambiente” disponibilizado no Ovenbird. Quando houver modificações

nos ambientes, elas serão versionadas e adicionadas ao repositório de código pelo

desenvolvedor, logo após, o Puppet Master será atualizado com essas modificações

e na próxima solicitação do Puppet Client, as alterações serão enviadas ao seu

ambiente para que sejam aplicadas.

A Figura 22 também ilustra a utilização da ferramenta Vagrant, apresentada na

seção 5.2.1.11, para a criação de ambientes de desenvolvimento. O Vagrant não é

gerenciado pelo Ovenbird, mas a sua utilização completa o processo de

automatização de ambientes ao permitir usufruir dos recursos do Puppet. O Vagrant

permite a utilização do Puppet Client em uma máquina virtual para solicitar as

configurações ao Puppet Master. Com isso, o ambiente de desenvolvimento será

idêntico entre todos os desenvolvedores e irá refletir o ambiente de produção,

utilizando o mesmo sistema operacional e as mesmas configurações.

Com a utilização do Puppet, as configurações necessárias para a criação de

qualquer ambiente (desenvolvimento, aceitação e produção), ficarão centralizadas

no Ovenbird. Dessa forma, não será necessário acessar um ambiente para efetuar

mudanças manualmente.

3.4.2 Proposta de solução para a Gerência de Solicitações

Para cada SLV um projeto no Ovenbird será criado para que as solicitações sejam

agrupadas. Um novo projeto cria uma área de trabalho onde as solicitações serão

visualizadas. Esta área de trabalho é um reflexo do quadro Kanban mostrado na

Figura 16, com a inclusão de novas colunas para permitir a visualização de todas as

etapas inclusas no processo de entrega de software. O novo quadro pode ser

visualizado na Figura 23.

59

Figura 23 - Quadro Kanban no sistema Ovenbird.

Após a definição da solicitação junto ao cliente, ela é cadastrada na coluna

Solicitações, iniciando o processo de entrega. Com o planejamento de uma nova

Sprint, todas as solicitações que deverão ser atendidas nesse período são

agrupadas na coluna A Fazer.

O desenvolvedor, para iniciar suas atividades, move a solicitação que irá

desenvolver para a coluna Fazendo e efetua o check-in no repositório de código

utilizando o Git, ferramenta para controle de versão apresentada na seção 5.2.1.3, e

inicia a codificação. Ao finalizar a solicitação, o desenvolvedor executa os testes de

suas alterações em seu ambiente de desenvolvimento e, após a validação, ele

adiciona o novo código no repositório através de um check-out.

O check-out gera um identificador para representar os arquivos modificados. O

identificador é adicionado à solicitação no Ovenbird e esta é movida para a coluna

Teste Unit.

O repositório de código será monitorado pelo sistema de integração contínua

Jenkins, apresentado na seção 5.2.1.4. Quando uma alteração for detectada, ela

será submetida ao fluxo de testes pelo Jenkins, que é instalado junto com o

Ovenbird. Os passos de testes unitários, testes de integração e testes de aceitação

são gerenciados de forma automática, sendo que o processo só avança ao teste

seguinte se o anterior for bem sucedido. Para fornecer feedback dos processos de

testes, o Jenkins irá atualizar o status da solicitação pelos vários tipos de teste, para

que o Ovenbird possa movimentá-la pelo quadro Kanban de forma automática. Os

testes são criados com a utilização da ferramenta RSpec.

Quando a solicitação passar por todas as etapas de testes automatizados, ela se

torna uma funcionalidade candidata a ir para produção e fica disponível para ser

implantada no ambiente de aceitação pela equipe de qualidade. A solicitação no

Ovenbird fica disponível na coluna Aceitação do quadro Kanban e poderá ser

disponibilizada no ambiente de aceitação clicando-se em um botão no Ovenbird,

60

executando-se a ferramenta Mina. Mina é uma ferramenta para automatização de

implantação apresentada na seção 5.2.1.5.

A automatização proporciona a consistência na execução, tornando o processo

repetível e confiável. Isso permite que a equipe de qualidade possua a liberdade de

implantar uma versão no momento que desejar, agilizando o processo de validação

do que foi desenvolvido junto ao cliente.

Se tudo estiver de acordo como foi especificado, a solicitação é liberada no Ovenbird

para ser implantada no ambiente de produção ficando disponível na coluna

Produção do quadro Kanban. O processo de implantação ocorre da mesma forma

descrita para o ambiente de aceitação.

A implantação de uma versão em ambiente de produção geralmente é uma decisão

do gerente de projetos, mas todos os envolvidos poderão efetuar esse processo

caso seja necessário.

O Quadro 2 lista todas as ferramentas utilizadas para a automatização do processo

de entrega.

Quadro 2 – Ferramentas utilizadas.

NOME DESCRIÇÃO

Puppet Automação de Infraestrutura

Vagrant Automação de Ambiente de Desenvolvimento

Git Sistema de Controle de Versão Distribuído

Mina Automação de Implantação

Jenkins Servidor de Integração Contínua

RSpec / Cucumber Automação de Testes

Conforme Humble e Farley (2014, p. 106), isso permite que equipes de testes

possam criar e implantar seu próprios ambientes de testes com o apertar de um

botão. Desenvolvedores podem ver quais versões passaram por quais estágios do

processo de entrega e quais problemas foram encontrados, e gerentes podem

verificar e monitorar métricas fundamentais como tempo de ciclo e qualidade de

61

software. Como resultado, todos os envolvidos no processo de entrega conseguem

acesso aquilo de que precisam e quando precisam, além de visibilidade sobre o

processo de entrega de modo a identificar, otimizar e remover gargalos. Isso leva a

um processo de entrega que não somente é mais rápido, como mais seguro.

A Figura 24 apresenta o novo fluxo de gerenciamento do sistema com a utilização

de ferramentas para automatizar as etapas do processo de entrega.

Figura 24 - Fluxo do gerenciamento do sistema pelos desenvolvedores após a aplicação das soluções propostas.

O novo fluxo de gerenciamento não permite que os acessos aos ambientes de

implantação sejam efetuados manualmente pelos desenvolvedores. Todo o código

de configuração, dos ambientes e das lojas virtuais, devem ser versionados e

enviados ao repositório. O Ovenbird efetua o check-out no repositório e, de forma

automatizada, com o auxílio das ferramentas apresentadas, envia as configurações

para os ambientes que as executam. No processo de implantação, a ferramenta

utilizada efetua o check-out no repositório e implanta o SLV no ambiente.

3.5 TRABALHOS CORRELATOS

Com o objetivo de não elevar o custo de desenvolvimento do SLV com o pagamento

de licenças de ferramentas enterprise tais como a Team Foundation Server

(http://msdn.microsoft.com/en-us/library/ms181238(v=vs.90).aspx) e a Borland

62

(http://www.borland.com/Home), a empresa busca soluções na comunidade open

source. Esta seção apresenta três ferramentas open source de integração e as

compara com a ferramenta proposta neste trabalho.

3.5.1 Go Continuous Delivery

A Go é uma ferramenta de integração contínua voltada para o gerenciamento de

versões e a distribuição de software em vários computadores. Desenvolvida pela

empresa ThoughtWorks, foi liberada como software livre em 2014.

A Go trabalha com o padrão pipeline de implantação para permitir gerenciar as

alterações no código fonte da aplicação e obter um feedback rápido. A ferramenta

destina-se ao ambiente de desenvolvimento e emprega o ciclo build-test-release

para efetuar implantações sob-demanda. A Figura 25 apresenta o processo de

entrega de uma versão, permitindo ver a evolução e o estado do projeto.

Figura 25 – Tela do pipeline de implantação na ferramenta Go.

Fonte: http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2

3.5.2 Tools Cloud

Tools Cloud é uma ferramenta comercial que fornece a integração de várias

ferramentas de código aberto, incluindo controle de versão, gerenciamento de

projetos e acompanhamento de problemas, integração contínua e repositórios de

artefatos, hospedadas e gerenciadas na nuvem, para criar um ambiente completo

através da internet.

Cada cliente recebe um ambiente exclusivo e todas as ferramentas são instaladas

em uma única máquina virtual na nuvem, com armazenamento virtual dedicado.

63

A Figura 26 apresenta o painel de instalação da ferramenta.

Figura 26 – Painel de instalação da Tools Cloud.

Fonte: http://toolscloud.com/

O serviço é acessível via HTTPS e se propõe a resolver problemas de inatividade do

servidor, problemas de backup, problemas de configuração e falhas de segurança

em uma infraestrutura de desenvolvimento para organizações de desenvolvimento

de software de classe mundial.

3.5.3 Trello

O Trello é um sistema para gerenciamento de tarefas que segue o método Kanban.

A empresa Fog Creek Software criou a ferramenta online em setembro de 2011,

para permitir a organização de equipes e tarefas de forma muito mais dinâmica e

facilitada.

Ele permite a criação de diversos quadros, nos quais pode-se criar diversas colunas,

como mostra a Figura 27. Dentro de cada coluna é possível adicionar uma ou mais

tarefas (cards), contendo o conteúdo que o usuário desejar.

64

Figura 27 – Quadro do Trello.

Fonte: http://corporate.canaltech.com.br/dica/utilitarios/gerencie-equipes-e-tarefas-com-o-trello-e-de-adeus-aos-post-its/

3.5.4 Quadro Comparativo

O Quadro 3 mostra as diferenças entre as ferramentas apresentadas e o Ovenbird.

Quadro 3 – Comparativo Ovenbird X GO X Tool Cloud X Trello.

GO Tools Cloud Trello Ovenbird Gerência de Tarefas X X X Integração Contínua X X Provisionamento X X

Implantação Automatizada X X Controle de Versão X X X Open Source X X

Com o quadro, pode-se observar que o Ovenbird possui um gerenciamento de

tarefas com os mesmos conceitos do Trello, porém, o Trello não oferece suporte aos

demais itens. A Tools Clound é direcionada para o gerenciamento de ambiente e

instalação de ferramentas. O Ovenbird permite além do provisionamento de

ambiente, uma gerência automatizada do código do sistema. A Go gerencia o código

fonte do sistema e é direcionada para desenvolvedores, enquanto o Ovenbird dá

suporte também ao negócio, com o gerenciamento de solicitações.

65

4. ANÁLISE ORIENTADA A OBJETOS

Esse capítulo apresenta os diagramas derivados da análise orientada a objetos

realizada para o desenvolvimento do sistema Ovenbird. Segundo Pressman (2006,

p. 152), o objetivo da orientação a objetos é definir todas as classes relevantes ao

problema a ser resolvido, as operações e os atributos relacionados a elas, as

relações entre elas e o comportamento que elas exibem.

Na análise orientada a objetos será adotada a Unified Modeling Language (UML)

para especificar, construir, visualizar os artefatos do sistema proposto.

4.1 DIAGRAMA DE CLASSES

Após a documentação dos requisitos no capítulo 3 utilizando-se o Diagrama de

Casos de Uso, serão modeladas as classes necessárias que irão compor e

solucionar as questões levantadas e especificadas.

O diagrama de classes é o diagrama encontrado com maior frequência na

modelagem de sistemas orientados a objetos e mostra um conjunto de classes,

interfaces e colaborações e seus relacionamentos. Uma classe corresponde a algo

tangível, ou a uma abstração conceitual, existente no domínio do usuário ou no

domínio do engenheiro de software (RAMOS, 2006, p. 80). A Figura 28 mostra o

diagrama de classes de análise do sistema Ovenbird.

66

Figura 28 – Diagrama de classes de análise – parte estática - do sistema Ovenbird.

Segundo Bezerra (2003, p. 96), um modelo de classes de análise não leva em

consideração restrições inerentes à tecnologia a ser utilizada na solução de um

problema. Na Figura 28 os interessados pela entrega do sistema estão

representados na classe Membro, que é especializada na classe Usuário,

representando as pessoas do time de desenvolvimento e, na classe Especialista,

representando as pessoas designadas pelo cliente para descrever as

funcionalidades.

Nos ambientes são efetuados várias implantações do sistemas, cada implantação é

composta das solicitações que estão disponíveis. É preciso saber qual versão do

sistema está em determinado ambiente. As solicitações, de acordo com os

resultados dos testes, podem ser atualizadas. A versão de uma solicitação pode ser

alterada até o momento que ela vire uma versão candidata a ir para produção.

67

4.2 DICIONÁRIO DE DADOS

O Quadro 4 apresenta o dicionário de dados referente às classes do sistema

Ovenbird.

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

Classes Atributos Obrigatório Descrição Valor Possíveis

Ambiente

tipo Sim Qual o tipo do ambiente que se está criando

Aceitação / Produção

ip Sim O endereço IP para acesso ao Cloud Hosting

usuario Sim O usuário de acesso senha Sim A senha de acesso

url Sim A URL para acesso via browser

descricao Não Descrição sobre o ambiente

Cliente

nome Sim Nome do cliente

telefone Sim Telefone de contato email Sim E-mail de contato razaoSocial Não Razão social da empresa

Especialista ocupacao Sim Gargo ocupado na empresa

Membro

nome Sim Nome do especialista

telefone Não Telefone para contato email Sim E-mail para contato

descricao Não Descrição sobre as atividades do especialista

Implantacao

data Sim Data que foi realizada a implantação

status Sim O status da implantação sucesso / erro

versao Sim A versão da aplicação que foi implantada

Projeto nome Sim Nome do projeto

urlRepositorio Sim URL do repositório de código fonte

68

Quadro 5 – Dicionário de dados do sistema Ovenbird. (conclusão)

Classes Atributos Obrigatório Descrição Valor Possíveis

Solicitacao

nome Sim O titulo da solicitação

descrição Não A descrição da solicitação a ser desenvolvida

dataInicio Não Data prevista para o inicio do desenvolvimento

dataFim Não Data prevista para o término do desenvolvimento

status Sim O status da validação normal/ sucesso / falhou

coluna Sim A posição no quadro Kanban

1 / 2 / 3 / 4 / 5 / 6 / 7 / 8

Usuario

dataInclusao Sim Data de cadastro

login Sim Login para acesso ao sistema

senha Sim Senha para acesso ao sistema

tipo Sim Especifica qual o tipo de usuário que está acessando o sistema

Programador / Gerente de projetos / Qualidade

Versao codigo Sim

O código gerado pelo sistema de controle de versão

data Sim A data que gerou a nova versão

4.3 DIAGRAMAS DE SEQÜÊNCIA

Os diagramas de sequência ilustram interações entre objetos em um determinado

período de tempo e a sequência de eventos que ocorrem em um determinado

processo. Uma interação é uma sequência de mensagens entre típicas instâncias de

classes, componentes, subsistemas ou atores (RAMOS, 2006, p.32).

69

O diagrama de sequência apresentado na Figura 29 tem como objetivo incluir um

novo ambiente e efetuar as configurações iniciais no nó de destino.

Figura 29 – Diagrama de sequência incluirNovoAmbiente.

O diagrama de sequência apresentado na Figura 30 tem como objetivo incluir um

novo projeto para um determinado cliente.

Figura 30 – Diagrama de sequência cadastrarProjeto.

O diagrama de sequência apresentado na Figura 31 tem como objetivo incluir uma

nova solicitação para um determinado projeto.

70

Figura 31 – Diagrama de sequência incluirSolicitacao.

O diagrama de sequência apresentado na Figura 32 tem como objetivo executar o

processo de implantação de uma funcionalidade.

Figura 32 – Diagrama de sequência gerarNovaImplantação.

4.4 DIAGRAMA DE ESTADO

Segundo Bezerra (2003, p. 209), um estado é uma situação na vida de um objeto

durante a qual ele satisfaz alguma condição ou realiza alguma atividade. Cada

estado de um objeto é normalmente determinado pelos valores dos seus atributos

e/ou pelas suas ligações com outros objetos.

A UML possui um conjunto de notações para o diagrama de estado, que permite

modelar o comportamento interno de um determinado objeto, subsistema ou sistema

global. A Figura 33 apresenta o diagrama de estados de uma solicitação no pipeline

de implantação.

71

Figura 33 – Diagrama de estado de classe funcionalidade.

Quando uma nova solicitação é adicionada ao projeto, ela permanece em seu

estado inicial até após o planejamento da próxima Sprint. Com a definição da Sprint,

a solicitação é agrupada na coluna A Fazer com as demais solicitação que deverão

ser atendidas. O desenvolvedor altera o estado da solicitação para Fazendo assim

que inicia o desenvolvimento. Os próximos estados, são os estados de testes

automatizados, a cada verificação bem sucedida, o estado da solicitação é

atualizado para o próximos estado. Nesse processo de testes, quando ocorrer um

defeito, o estado da solicitação volta ao Fazendo para que seja efetuadas as devidas

correções.

Quando termina o processo de testes, a solicitação fica disponível para ser

implantada no ambiente de aceitação para que a equipe de qualidade verifique os

requisitos especificados pelo cliente. Por fim, a solicitação é liberada para ser

implantada no ambiente de produção, onde alcança o estado pretendido.

72

5. PROJETO E IMPLEMENTAÇÃO

Este capítulo apresenta o projeto e a implementação da ferramenta Ovenbird

proposta.

5.1 PROJETO

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

planejadas que se concentram nos inter-relacionamentos das partes de alto nível e

nas operações lógicas envolvidas nos níveis inferiores (PRESSMAN, 2006, p. 207).

O projeto aborda a arquitetura, a interface com o usuário, os componentes

orientados a objetos e o banco de dados da ferramenta. A implementação apresenta

as tecnologias e linguagens utilizadas, as restrições de implementação, a instalação

e funcionamento do protótipo.

5.1.1 Projeto de arquitetura

Segundo Pressman (2006, p. 208), a arquitetura de software de um programa ou

sistema computacional é a estrutura ou estruturas do sistema que abrangem os

componentes de software, as propriedades externamente visíveis desses

componentes e as relações entre eles. O sistema foi desenvolvido orientado a

objetos para a Web na arquitetura Cliente/Servidor e construído no modelo de quatro

camadas, conforme a Figura 34.

Figura 34 – Arquitetura de quatro camadas do sistema Ovenbird.

As camadas da ferramenta proposta são:

• Camada de Apresentação: Interações na interface da aplicação são

realizadas diretamente no servidor Web que recebe a requisição e retorna

73

uma resposta como página web, desenvolvida em HyperText Markup

Language (HTML);

• Camada Lógica: Nesta camada está no servidor de aplicação onde as regras

do negócio são executadas e determinam de que maneira os dados serão

utilizados;

• Camada de Dados: Nesta camada tem-se o servidor de Banco de Dados, no

qual reside toda a informação necessária para o funcionamento da aplicação;

• Camada Cliente: Neste caso, o cliente é o navegador utilizado pelo usuário.

5.1.2 Projeto de interface

Para beneficiar toda a equipe responsável pelo SLV, a interface foi desenvolvida de

forma a permitir acesso ao sistema via internet. Para permitir a compatibilidade entre

os navegadores web, a interface do protótipo foi desenvolvida com o auxílio da

biblioteca Bootstrap (http://getbootstrap.com/), fazendo-se uso do HTML e da

Cascading Style Sheets (CSS). O projeto de interface com o usuário relaciona-se

tanto com o estudo de pessoas quanto com aspectos tecnológicos (PRESSMAN,

2006, p. 265). Em geral, decompõe-se em Projeto de Arquitetura da Aplicação Web

e Projeto de Navegação, apresentados a seguir.

5.1.2.1 Projeto de arquitetura da aplicação web

O Projeto de Arquitetura para aplicação web deve descrever como será realizada a

comunicação do usuário com o sistema. A utilização da estrutura hierárquica permite

um fluxo de controle horizontal, por meio da ramificação de hipertexto, ao longo dos

ramos verticais da estrutura (PRESSMAN, 2006, p. 442). A Figura 35 apresenta o

projeto de arquitetura da aplicação web do Ovenbird.

74

Figura 35 – Projeto da Arquitetura Web.

A partir da tela principal, os usuários poderão acessar o menu do Ovenbird e

navegar para as áreas de clientes, projetos e usuários. Na área do cliente, o usuário

poderá visualizar os clientes existentes ou cadastrar um novo. Na tela principal de

projetos, o usuário adquire permissão para cadastrar um novo projeto e visualizar

um projeto já existente. Quando o usuário visualiza um projeto, é possível o cadastro

e a visualização das solicitações e, quando o usuário cadastra um projeto, é

permitido visualizar e cadastrar especialistas além de visualizar e cadastrar

ambientes. Os membros da equipe responsável pelo o SLV são gerenciados através

do menu Usuários. Na tela de usuário é concebido o acesso para visualizar todos os

usuários e cadastrar um novo.

5.1.2.2 Projeto de navegação

A partir do momento que foi estabelecida a arquitetura do Ovenbird e identificados

os seus componentes, deve-se definir caminhos de navegação que permitam ao

usuário ter acesso ao conteúdo e aos serviços oferecidos.

Conforme Pressman (2006, p. 444), o projeto de navegação começa com a

consideração da hierarquia do usuário e os casos de uso relacionados. Cada ator

pode usar a aplicação de forma um tanto diferente e assim ter diferentes

necessidades de navegação.

As Figuras 36, 37 e 38 apresentam os projetos de navegação dos atores

GerenteProjetos, Desenvolvedor e Qualidade, respectivamente.

75

Figura 36 – Projeto de navegação do ator GerenteProjetos.

Figura 37 – Projeto de navegação do ator Desenvolvedor.

Figura 38 – Projeto de navegação do ator Qualidade.

76

5.1.3 Projeto de componente

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

implementação de um sistema. Ele consiste, na prática, em um conjunto de artefatos

físicos com formato digital, como por exemplo, arquivos de código fonte ou

documentos relativos ao negócio.

Segundo Pressman (2006, p. 239), a abordagem de projeto orientado a objetos trata

não apenas da aplicação, mas também da infraestrutura da aplicação e focaliza a

representação de quatro componentes principais do sistema: Componente de

Domínio do Problema (CDP), Componente de Gerência de Dados (CGD),

Componente de Gerência de Tarefas (CGT) e Componente de Interação Humana

(CIH), que são apresentados a seguir.

5.1.3.1 Componente de Domínio do Problema (CDP)

O componente de domínio do problema corresponde aos subsistemas responsáveis

por implementar diretamente os requisitos dos usuários (COAD; YOURDON, 1993).

A Figura 39 representa o componente de domínio de problema do Ovenbird.

77

Figura 39 – Componente do Domínio do Problema.

78

5.1.3.2 Componente de Interação Humana (CIH)

O Ovenbird é desenvolvido utilizando a linguagem de programação Ruby. As

classes de Interação Humana serão obtidas a partir do pré-processamento de

arquivos com a utilização do sistema de template ERB. O ERB trabalha com as

marcações HTML e código Ruby embutido, permitindo gerar convenientemente

qualquer tipo de texto, em qualquer quantidade, a partir de modelos. (FUENTES,

2014, p. 114).

Os modelos combinam-se de texto simples com código Ruby para a substituição de

variáveis e controle de fluxo, o que os torna fácil de escrever e manter. Sendo assim,

não será feito um projeto específico para este componente já que a interface é

gerada na medida em que os arquivos .erb são processados.

5.1.3.3 Componente de Gerência de Tarefa (CGT)

O componente de Gerência de Tarefas compreende a definição de tarefas e a

comunicação e coordenação entre elas. A Figura 40 representa o Componente de

Gerência de Tarefas do Ovenbird.

79

Figura 40 – Componente de Gerência de Tarefa.

80

5.1.3.4 Componente de Gerência de Dados (CGD)

O Componente de Gerência de Dados fornece a infraestrutura para a recuperação e

armazenamento dos objetos no sistema (persistência dos objetos). Sua finalidade é

isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura do

software.

Para o desenvolvimento do Ovenbird foi utilizado o framework RubyOnRails

(http://rubyonrails.org). O RubyOnRails por padrão utiliza a biblioteca ActiveRecord

(http://guides.rubyonrails.org/active_record_basics.html) para lidar com banco de

dados.

Segundo Urubatan (2012, p.123), a ActiveRecord é uma camada de mapeamento

objeto-relacional que facilita a criação e a utilização de objetos de negócios cujos

dados requerem armazenamento persistente para um banco de dados. É uma

implementação do padrão ActiveRecord8, um objeto que envolve uma linha em uma

tabela de banco de dados ou exibição, encapsula o acesso ao banco, e acrescenta

lógica de domínio sobre esses dados (FOWLER, 2010).

Dessa forma não existe o Componente de Gerência de Dados, sendo que este

encontra-se implicitamente implementado na biblioteca ActiveRecord.

5.1.4 Projeto relacional de dados

Uma vez que os bancos de dados relacionais são os dispositivos de armazenamento

mais confiáveis e utilizados atualmente, o Ovenbird foi construído utilizando o

sistema gerenciador de banco de dados relacional MySQL, apresentado na seção

5.2.1.6. O projeto do banco de dados relacional é apresentado na Figura 41.

8 http://www.martinfowler.com/eaaCatalog/activeRecord.html

81

Figura 41 – Diagrama relacional de dados.

5.2 IMPLEMENTAÇÃO DO PROTÓTIPO

Esta seção apresenta as tecnologias utilizadas na implementação, as restrições de

implementação, o procedimento para a instalação e funcionamento do protótipo e as

telas do mesmo.

82

5.2.1 Tecnologias utilizadas no protótipo

Para permitir a automatização dos processos relacionados com a entrega de

software, foi selecionado um conjunto de ferramentas disponíveis no mercado. Tais

ferramentas são apresentadas nas próximas seções.

5.2.1.1 Ruby e RubyOnRails

O protótipo proposto foi escrito utilizando a linguagem de programação Ruby

(https://www.ruby-lang.org/en/), por ser uma linguagem totalmente orientada a

objetos com algumas características funcionais, dinâmica, open source e com foco

na simplicidade e produtividade.

Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem

dinâmica e forte, com gerenciamento de memória automático. Seu criador, Yukihiro

Matsumoto, queria uma linguagem que juntasse programação funcional e

imperativa, mas acima de tudo que fosse uma linguagem legível. Esta é uma das

grandes vantagens da linguagem, ser extremamente legível.

Para uma melhor produtividade e desempenho do sistema, o framework

RubyOnRails foi utilizado por fornecer uma solução de desenvolvimento completa e

com baixa curva de aprendizagem. RubyOnRails é uma ferramenta open source

seguindo a arquitetura MVC (Model-View-Controler). Surgiu dentro da empresa

37signals9 e foi criado por David Heinemeier Hansson, que resolveu extrair parte da

lógica web de um projeto chamado Basecamp (FUENTES, 2014, p. 4).

Segundo Souza (2014, p. 10), o framework RubyOnRails permite a criação de

aplicações web com extrema rapidez. Essa agilidade tem sido considerada por

várias startups no momento da criação de seus produtos.

5.2.1.2 Cucumber

O Cucumber (http://cukes.info/) é uma ferramenta de testes de aceitação utilizada

para automatizar testes do comportamento do software, levando em conta o ponto

de vista do usuário (BRAÚNA, 2013, p.13). Segundo Humble e Farley (2014, p.

9 http://37signals.com/

83

189), testes de aceitação são voltados para o negócio, não para o desenvolvedor;

eles testam funcionalidades completas em uma versão do sistema.

Com o Cucumber, a especificação do sistema é efetuada através de documentos em

linguagem natural (português), porém, com a possibilidade de executar essa

documentação para verificar o comportamento especificado no sistema real.

O Cucumber estimula a conversa com pessoas de negócio de modo a melhorar o

entendimento dos requisitos e, com o passar do tempo, a especificação criada com

o uso do Cucumber, conhecida como Living Documentation (documentação viva), se

torna uma das principais referências do comportamento do sistema (BRAÚNA, 2013,

p.13).

5.2.1.3 Git

O Git (http://git-scm.com/) é uma ferramenta para registrar alterações feitas em um

conjunto de arquivos ao longo do tempo, uma tarefa tradicionalmente conhecida

como “controle de versão” (SILVERMAN, 2013, p. 9). O Git é um sistema de controle

de versão distribuído, conforme apresentado na seção 2.5.3 e teve sua concepção

em 2005 por Linus Torvalds, para gerenciar o código do kernel do Linux.

Segundo Silverman (2013, p. 9), qualquer grupo de arquivos relacionados que sejam

alterados com o decorrer do tempo é candidato ao uso do Git, podendo-se:

• Verificar o estado do projeto em qualquer ponto do passado;

• Mostrar as diferenças entre os diversos estágios do projeto;

• Dividir o desenvolvimento do projeto em múltiplas linhas independentes, os

chamados “branches”, que podem ser desenvolvidos separadamente;

• Recombinar periodicamente os branches em um processo chamado de

“merge” e reacomodar as alterações feitas em dois ou mais branches;

• Permitir que muitas pessoas trabalhem simultaneamente em um projeto,

compartilhando e combinando seu trabalho conforme necessário.

84

5.2.1.4 Jenkins

A ferramenta Jenkins (http://jenkins-ci.org/), trabalha em conjunto com o Git para

apoiar diversas atividades no ciclo de desenvolvimento de um projeto. Atualmente

essa ferramenta concentra-se em duas vertentes:

• Compilar e testar continuamente projetos de software. Jenkins fornece uma

maneira simples para a prática de integração contínua, tornando mais fácil

para os desenvolvedores integrar suas alterações no projeto;

• Monitorar a execução de tarefas que são agendadas e configuradas, tais

como a execução de testes automatizados.

Uma das vantagens do Jenkins, é que ele é altamente extensível, podendo ser

configurado para se comunicar com diversas outras ferramentas, como a da geração

de uma nova versão de software.

Jenkins trabalha com uma abordagem na qual prioriza as saídas e as informações

de retorno referentes a cada tarefa pré-determinada. Com a utilização da integração

contínua, o desenvolvedor terá um feedback referente ao código que efetuou check-

in conforme definido na configuração de cada tarefa no Jenkins (SATO, 2013, p.

128).

5.2.1.5 Mina

Mina (http://mina-deploy.github.io/mina/) é uma ferramenta para a automatização de

implantação de sistemas com um fluxo de trabalho baseado em tarefas. Ela gera um

procedimento inteiro como um script e executa-o remotamente em um servidor. Mina

cria somente uma sessão SSH por implantação, minimizando a sobrecarga da

conexão SSH.

Com a utilização do Mina, utiliza-se o mesmo processo para efetuar implantações

em qualquer ambiente de maneira consistente e confiável (MINA, [2013?]).

5.2.1.6 MySQL

O MySQL (http://www.mysql.com/) é um sistema gerenciador de banco de dados

relacional, multiusuário, multitarefa e open source. É atualmente um dos bancos de

85

dados mais populares, com mais de 10 milhões de instalações pelo mundo. Possui

versões disponíveis para vários sistemas operacionais, entre eles o Linux, Windows

e FreeBSD.

Para utilizar o MySQL, é necessário instalar um servidor e uma aplicação cliente. O

servidor é o responsável por armazenar os dados, responder às requisições,

controlar a consistência dos dados, bem como a execução de transações

concomitantes entre outras. O cliente se comunica com o servidor através da SQL. A

versão gratuita do MySQL é chamada de Edição da Comunidade e possui o servidor

e uma interface gráfica cliente (TONSING, 2006, p. 46).

5.2.1.7 Nginx

O Nginx (http://wiki.nginx.org/Main) é um servidor web rápido, gratuito e open

source, com inúmeras possibilidades de configuração para melhor performance. É

conhecido por sua estabilidade, configuração simples e baixo consumo de recursos.

Escrito por Igor Sysoev em 2002 e teve sua primeira versão pública liberada em

2004. Segundo uma pesquisa da W3techs.com, em março de 2009, o Nginx é usado

em 39,4% dos sites mais acessados no mundo (NGINX, [2004?])

5.2.1.8 Puma

Puma (http://puma.io/) é uma pequena biblioteca que fornece um servidor HTTP 1.1

muito rápido e concorrente para aplicações web Ruby. Criado por Evan Phoenix no

final de 2011, Puma foi construído para a velocidade e paralelismo (PUMA, [2011?].

5.2.1.9 Puppet

O Puppet (http://puppetlabs.com/) é uma ferramenta de automação de infraestrutura

utilizada por diversas empresas que precisam gerenciar milhares de máquinas

físicas e virtuais ao redor do mundo, tais como as empresas MediaWiki Fundation,

Google, e Mozilla Fundation.

Os scripts do Puppet são escritos através de uma linguagem declarativa, baseada

em Ruby. Cada comando que se declara na linguagem é uma diretiva, chamada de

recurso e, é possível definir um conjunto de recursos em um arquivo chamado de

86

manifesto. Uma característica importante dessa ferramenta é a “idempotência” que

permite executar o mesmo código diversas vezes, fazendo com que a ferramenta

altere somente o que for necessário, ou seja, se um pacote já estiver instalado, ele

não será reinstalado.

O ponto positivo dessa abordagem declarativa é poder ter algo bastante específico,

e focado em um só trabalho. A ideia é que se tenha a configuração centralizada em

um único ponto, e essa configuração seja distribuída para diversos nós de uma rede

(PUPPET LABS, 2014).

5.2.1.10 RSpec

RSpec (http://rspec.info/) é uma biblioteca de testes escrita em Ruby e projetada

para fazer o desenvolvimento orientado a testes uma experiência produtiva e

agradável. Ela permite descrever a aplicação em uma DSL 10 muito simples e

elegante para manter uma documentação atualizada.

Muito usado para descrever aplicações RubyOnRails, com o RSpec é possível testar

qualquer código escrito em Ruby. Ele é composto por diversos módulos que

permitem expressar funcionalidades, cenários e expectativas de como sua aplicação

e/ou objetos devem se comportar.

Embora o RSpec seja muito completo, permitido a criação de vários tipos de testes,

tais como testes unitários, testes de aceitação e testes de performance, é possível

estendê-lo muito facilmente caso se queira adequar o modo como ele funciona. Isso

permite tornar os seus testes ainda mais expressivos e concisos (GEORGE, 2014, p.

11).

5.2.1.11 Vagrant

O Vagrant (https://www.vagrantup.com/) fornece uma forma fácil de configurar e

reproduzir ambientes de desenvolvimento portáteis, construídos através de

máquinas virtuais e controlados por um único fluxo de trabalho consistente,

ajudando a maximizar a produtividade e flexibilidade de toda a equipe.

10 http://www.martinfowler.com/bliki/DomainSpecificLanguage.html

87

Para isso, as máquinas são provisionadas em cima do VirtualBox, VMware, AWS, ou

qualquer outro provedor. Então, ferramentas de provisionamento padrão da

indústria, tais como shell scripts, Chef, ou Puppet, podem ser usadas para instalar e

configurar o ambiente na máquina virtual automaticamente (HEIDI, 2014, p. 11).

5.3 RESTRIÇÕES DE IMPLEMENTAÇÃO

O projeto apresentado foi desenvolvido como um protótipo para o sistema Ovenbird.

Com um grau de importância da qualidade da codificação baixo, sua utilização em

produção não será satisfatória.

O controle de acesso, a segurança e testes de usabilidade da interface não foram

observados com a importância adequada, pois não se trata inicialmente do foco

proposto pelo projeto para este protótipo.

O protótipo não contempla a inserção de imagens, utilizadas normalmente para

identificar visualmente um usuário e se restringe a sistemas desenvolvidos na

linguagem de programação Ruby e a atender os processos de desenvolvimento da

empresa apresentada no estudo de caso, sendo inviável sua utilização por equipes

de desenvolvimento que não sigam o fluxo do quadro Kanban da Figura 23.

5.4 INSTALAÇÃO E FUNCIONAMENTO DO PROTÓTIPO

O Ovenbird foi desenvolvido utilizando a linguagem de programação Ruby em sua

versão 2.1.5, instalada em uma plataforma Unix11. A maior parte das distribuições

Linux possuem pacotes de Ruby para serem instalados. O Ruby possui um

gerenciador de pacotes chamado RubyGems (https://rubygems.org/). Com o

RubyGems é possível instalar as ferramentas utilizadas no Ovenbird, tais como o

framework RubyOnRails, a ferramenta Mina e o servidor de aplicação Puma.

O sistema operacional utilizada para efetuar a implantação durante o

desenvolvimento do protótipo foi o Ubuntu Server 14.04 LTS, que é uma distribuição

Linux. Ferramentas como o Mysql, Nginx e Jenkins, podem ser instaladas através do

gerenciador de pacotes do Ubuntu, o apt12.

11 http://www.unix.org/ 12 http://linux.die.net/man/8/apt-get

88

Para a instalação o Ovenbird, é necessário ter um sistema operacional em

funcionamento. Para configurar um sistema operacional, o mais recomendado, é um

nó em um Cloud Hosting. Com a utilização do Puppet pelo projeto, a instalação das

ferramentas necessárias ocorre de forma automatizada. No projeto existe uma pasta

chamada “puppet” contendo todos os manifestos (arquivos de configuração do

Puppet) necessários criar um ambiente com o estado desejado.

Primeiramente é necessário efetuar a instalação do Puppet nesse nó, depois, copiar

os manifestos para o novo ambiente e instruir o Puppet para que seja executado

utilizando esses arquivos.

O ultimo passo é inserir o IP desse novo nó no arquivo de configuração da

ferramenta Mina e executar a implantação.

5.5 INTERFACE COM O USUÁRIO

Esta seção apresenta as principais telas prototipadas para ferramenta Ovenbird, de

forma a dar suporte aos requisitos apresentados na seção 3.2. A Figura 42

apresenta a tela com a lista de todos os usuários cadastrados no sistema.

Figura 42 – Tela para visualização dos usuários cadastrados.

Esta tela é acessada através do menu Usuários e permite a visualização da listagem

de todos os usuários cadastrados no sistema. Um novo usuário é cadastrado pelo

gerente de projetos clicando no botão “Cadastrar Usuário” para exibir o formulário de

cadastro conforme a Figura 43. Em cada usuário cadastrado, é possível editar e

visualizar suas informações através dos botões “Editar” e “Visualizar”

respectivamente.

89

Figura 43 – Tela para cadastro de usuários.

A Figura 44 apresenta a tela com a lista de todos os clientes cadastrados.

Figura 44 – Tela para visualização dos clientes cadastrados.

Esta tela é acessada através do menu Clientes e permite a visualização da listagem

de todos os clientes cadastrados no sistema. O botão “Cadastrar Cliente” é utilizado

para exibir o formulário de cadastro de um novo clientes conforme apresentado na

Figura 45. Em cada cliente cadastrado, é possível editar e visualizar suas

informações através dos botões “Editar” e “Visualizar” respectivamente.

90

Figura 45 – Tela para cadastro de cliente.

O formulário para o cadastro de novos clientes também é utilizado para exibir as

informações que poderão ser atualizadas, dessa forma, esta tela, de acordo com a

ação executada (cadastrar, editar e visualizar), irá possuir três seções relacionadas.

A primeira seção é o formulário de cadastro de um novo cliente. A segunda seção é

uma listagem de todos os projetos que determinado cliente possui com a

possibilidade de cadastrar, editar e visualizar. A terceira seção exibe a lista de todos

os especialistas indicados pelo cliente e permite o cadastro, a visualização e a

atualização. A segunda e a terceira seção, não aparecem no cadastro de um novo

cliente.

A Figura 46 apresenta a tela para cadastro de um novo especialista.

Figura 46 – Tela para cadastro de especialista.

91

A Figura 47 apresenta a tela para cadastro de um novo projeto.

Figura 47 – Tela para cadastro de projeto.

Esta tela apresenta o formulário para cadastro de um novo projeto, sendo também

utilizada para exibir as informação que poderão ser atualizadas de acordo com a

ação executada (cadastrar, editar e visualizar). A tela possui três seções

relacionadas. A primeira seção é o formulário para cadastro das informações de um

projeto. A segunda seção, é a lista de todos os ambientes já configurados para este

projeto. Nota-se que nesta seção há dois botões em destaque; o botão “Configurar”

que executa o caso de uso InstalarPuppet e o botão “Provisionar”, responsável por

executar o caso de uso ProvisionarAmbiente e deixar o ambiente em um estado

adequado para implantação. A terceira seção é a lista dos especialistas que irão

contribuir para o desenvolvimento da loja virtual.

A Figura 48 apresenta a tela para cadastro de um novo ambiente, sendo possível a

escolha do tipo aceitação ou produção.

92

Figura 48 – Tela para cadastro de ambiente.

A Figura 49 apresenta a tela para a visualização de todos os projetos, agrupados por

clientes.

Figura 49 – Tela para cadastro de ambiente.

A partir dessa tela será possível acessar o quadro Kanban com as funcionalidades

clicando no botão “Visualizar Projeto” de cada projeto cadastrado.

A Figura 50 apresenta a tela do quadro Kanban onde será possível visualizar o

processo do pipeline de implantação.

93

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

94

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

representam as etapas do pipeline de implantação. Os botões para a implantação

automatizada do sistema são disponibilizados após os testes automatizados. O

botão verde efetua a implantação no ambiente de aceitação e o botão laranja, efetua

a implantação no ambiente de produção.

A Figura 51 apresenta a tela para cadastro de uma nova solicitação pelo ator

GerenteProjetos.

Figura 52 – Tela para cadastro de solicitação.

95

6. CONCLUSÃO E PERSPECTIVAS FUTURAS

O processo de desenvolvimento de software é um conceito de âmbito muito vasto e

pretende designar uma sequência de atividades, normalmente agrupadas em fases

e tarefas, executadas de forma sistemática e uniformizada, realizadas por pessoas

com responsabilidades bem definidas e que, a partir de um conjunto de entradas

produzem um conjunto de saída (RAMOS, 2006, p. 19).

No entanto, as atividades apresentam diversos problemas tais como o controle da

compatibilidade das ferramentas utilizadas entre os ambientes, onde é comum ver

software funcionando em uma máquina e o mesmo não funcionando em outra; a

execução de processos repetitivos, tais como os testes automatizados, que ocupam

demasiadamente a equipe de desenvolvimento; conflitos na junção dos trabalhos

realizados pelos desenvolvedores com o processo de integração do código

demorado, aumentando o custo para a correção de defeitos e gerando um ciclo de

feedback longo; a criação de vários ambientes heterogênicos oriundos de

configurações manuais, sem auditoria e realizadas por pessoas diferentes e erros ao

efetuar a implantação de uma versão em produção, quando é necessário fazer

julgamentos a cada passo do processo por humanos.

A ferramenta proposta neste trabalho tem como objetivo gerenciar a transição das

solicitações pelos vários estágios do desenvolvimento até o momento da entrega ao

usuário final, para permitir que a equipe responsável pelo SLV responda às

mudanças de forma eficiente, aumente a capacidade de gerar novas versões bem-

sucedidas e de liberá-las sob demanda e implante o seu sistema de loja virtual em

qualquer ambiente instantaneamente para refletir as mudanças de uma forma

eficiente e com baixo custo. Para isso, a ferramenta proposta realiza a integração de

ferramentas para a automatização de infraestrutura, integração continua do código,

execução de testes automatizados e a automatização da implantação, abstraindo a

complexidade da utilização através de uma interface amigável e que permita a

manipulação por qualquer membro da equipe.

A metodologia adotada abrangeu uma revisão bibliográfica sobre os principais temas

envolvidos no processo de entrega automatizada de software, das metodologias

96

ágeis de desenvolvimento, das ferramentas disponíveis no mercado que dão suporte

para a automatização e do desenvolvimento de software.

A ferramenta foi desenvolvida utilizando o paradigma da orientação a objetos com a

linguagem de programação Ruby, o framework RubyOnRails e o SGBD MySQL,

efetuando a integração entre as ferramentas Puppet, Git, Mina, Jenkins, RSpec e

Cucumber, para permitir a automatização do pipeline de implantação.

Como contribuições deste trabalho pode-se citar o entendimento do mapa do fluxo

de valor obtido através de uma visão holística dos processos realizados na empresa

do estudo de caso, a pesquisa, análise e utilização de ferramentas open source para

automatizar tarefas até então manuais e, o levantamento e documentação dos

requisitos que devem ser atendidos por um sistema para permitir a integração de

ferramentas e a utilização por pessoas com diferentes níveis técnicos.

O protótipo desenvolvido demonstrou a viabilidade da proposta. Dessa forma todos

os envolvidos no processo de entrega conseguem acesso àquilo que precisam e

quando precisam. A equipe de qualidade consegue implantar uma versão no

momento que desejar, agilizando o processo de validação junto ao cliente.

Desenvolvedores podem ver quais versões passaram por quais estágios do

processo de entrega e quais problemas foram encontrados, gerando um ciclo de

feedback curto e gerentes de projetos podem verificar e monitorar métricas

fundamentais como tempo de ciclo e qualidade de software. Resultados obtidos

através da utilização de práticas inclusas nas metodologias ágeis de

desenvolvimento tais como a integração contínua, gerência de configuração, testes

automatizados, gerência de infraestrutura e ambientes e a visualização do fluxo de

trabalho através do quadro Kanban, permitindo identificar, otimizar e remover

gargalos para tornar o processo de entrega confiável, rápido e mais seguro.

As perspectivas futuras deste trabalho incluem ajustes no software construído para

incorporar requisitos de qualidade necessários a software profissionalmente

desenvolvido tais como testes automatizados, verificação automática de

complexidade de código e documentação, através de comentários no próprio código

e a criação de uma página web para referências e também a implementação das

funções não contempladas nessa versão do protótipo tais como a visualização do

97

andamento do projeto pelo cliente, o formulário para confirmação dos testes em

ambiente de aceitação e a aceitação de plugins desenvolvidos por terceiros e, o

teste de performance da ferramenta com a criação de vários projetos e a

implantação da mesma na empresa onde foi realizado o estudo de caso para

observação dos resultados de melhoria alcançados.

98

REFERÊNCIAS

AGUIAR, G. de F.; PEINADO, J. Compreendendo o Kanban: Um ensino interativo ilustrado. Curitiba: Da Vinci, 2007 ASTELS, D.; MILLER, G.; NOVAK, M. Extreme Programming: Guia Prático. Rio de Janeiro: Campus, 2002. 333 p. BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML, São Paulo: Campus, 2003. BRAÚNA, Hugo. Cubumber e Rspec, São Paulo: Casa do Código, 2013. CHACON, S.; STRAUB, B. Pro Git. San Francisco, California: Apress, 2014. 729 p. DESENVOLVIMENTO ÁGIL. Aprenda Sobre Desenvolvimento Ágil de Software. 2013. On-line. Disponível em: <http://desenvolvimentoagil.com.br/>. Acesso em: 2 nov 2014. DUVALL, Paul. Agile DevOps: O Achatamento do Processo de Reliase de Software. 2012. On-line. Disponível em: <http://www.ibm.com/developerworks/br/library/a-devops1/>. Acesso em: 17 out 2014 FADEL, A. L.; SILVEIRA, H. da M. Metodologias Ágeis no Contexto de Desenvolvimento de Software: XP, Scrum e Lean. 2010. 26f. Trabalho de Conclusão de Curso – UNICAMP, Limeira, 2010. FOWLER, Martin. Active Record, 2010. On-line. Disponível em: <http://www.martinfowler.com/eaaCatalog/activeRecord.html>. Acesso em: 23 nov. 2014. FOWLER, Martin. Continuous Integration, 2006. On-line. Disponível em: <http://martinfowler.com/articles/continuousIntegration.html>. Acesso em: 09 nov. 2014. FOWLER, Martin. Deployment Pipeline. 2013. On-line. Disponível em: <http://martinfowler.com/bliki/DeploymentPipeline.html>. Acesso em: 17 out 2014 FOWLER, Martin. The New Methodology, 2005. On-line. Disponível em: <http://www.martinfowler.com/articles/newMethodology.html#N8B>. Acesso em: 01 nov. 2014. FUENTES, V. B. Ruby On Rails: Coloque sua aplicação nos trilhos. São Paulo: Casa do Código, 2014. 360 p. GEORGE, M. RSpec: Crie especificações executáveis em Ruby. São Paulo: Casa do Código, 2014. 176 p. HEIDI, Erika. Vagrant CookBook. Canada: Leanpub. 2014. 125 p. HUMBLE, J.; FARLEY, D. Entrega Contínua: Como entregar software de forma rápida e confiável. Porto Alegre: Bookman, 2014. 464 p. HUMBLE, Jez. Continuous Delivery e o Movimento DevOps. 2011. On-line. Disponível em: <http://www.infoq.com/br/articles/jezhumble-continuous-delivery-devops/>. Acesso em: 10 out 2014.

99

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

100

ANEXOS

ANEXO A – Casos de Uso do Sistema Proposto

Descrição de Caso de Uso

Projeto: Ovenbird

Subsistema:

Caso de Uso: Principal

Analista: Leandro Souza Nunes.

Data: 27/11/2014

Descrição: Esse caso de uso tem por objetivo o gerenciamento das solicitações de

cada cliente, a criação dos ambientes para implantação do SLV e o gerenciamento

das informações dos interessados no desenvolvimento do sistema, o cliente e a

equipe de desenvolvimento (usuário).

O Ovenbird possui os seguintes atores:

• GerenteProjetos: representa a pessoa responsável por controlar o fluxo de

desenvolvimento das solicitações de cada cliente;

• Desenvolvedor: responsável pelo desenvolvimento das solicitações bem

como a configuração dos ambientes e a implantação da loja;

• Qualidade: responsável por efetuar testes no ambiente de aceitação para

validar a entrega do desenvolvimento junto ao cliente.

101


Projeto: Ovenbird

Subsistema: Diagrama de Caso de Uso Principal

Caso de Uso: CadastrarGeral


Data: 27/11/2014

Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas

informações referente aos interessados no desenvolvimento da loja virtual, contendo

todos os cadastros necessários para que o gerente de projetos possa administrar o

desenvolvimento na empresa estudada. Sendo assim, será contemplado nesse

subsistema os casos de uso CadastrarUsuarios e CadastrarClientes.

102


Projeto: Ovenbird

Subsistema: Diagrama de Caso de Uso CadastrarGeral

Caso de Uso: CadastrarUsuarios


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que o gerente de projetos

cadastra um usuário. Este processo é separado em quatro cenários: cadastrar,

alterar, excluir e consultar um usuário.

Caso de uso: CadastrarUsuario Ator: GerenteProjetos

Pré-condições: Não se aplica.

Pós-condições: Não se aplica.

Fluxo Principal: 1. O ator solicita cadastrar um novo usuário.

2. O ator informa os dados necessários (nome, e-mail, descrição (opcional),

telefone, login, senha e tipo) para cadastro do usuário.

3. O sistema verifica se as informações são válidas.

4. O sistema informa que o usuário foi cadastrada com sucesso.

Fluxo Alternativo: 3a. Dados necessários inválidos

3a. 1 O sistema informa qual ou quais dados estão incorretos.

3a. 2 O sistema retorna ao Fluxo Normal passo 2.

Caso de uso: AlterarUsuario Ator: GerenteProjetos

Pré-condições: O usuário deve estar cadastrado.

103


Fluxo Principal: 1. O ator solicita alterar um usuário.

2. O ator informa os dados necessários (nome, e-mail, descrição (opcional),

telefone, login, senha e tipo) para alterar o usuário.


4. O sistema informa que o usuário foi alterado com sucesso.


3a. 1 O sistema informa qual ou quais dados estão incorretos


Caso de uso: ExcluirUsuario Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita excluir um usuário

2. O ator informa o usuário a ser excluído.

3. O sistema verifica se o usuário existe.

4. O sistema pede confirmação para exclusão do usuário.

5. O sistema informa que o usuário foi excluído com sucesso.

Fluxo Alternativo: 3a. Usuário informado não existe

3a. 1 O sistema informa que o usuário não existe.


Caso de uso: ConsultarUsuario Ator: GerenteProjetos


104


Fluxo Principal: 1. O ator solicita consultar um usuário.

2. O ator informa o usuário a ser consultado.

3. O sistema verifica se o usuário existe.

4. O sistema mostra as informações do usuário consultado.

Fluxo Alternativo: 3a. O usuário informado não existe

3a. 1 O sistema informa que o usuário não existe.


105


Projeto: Ovenbird

Subsistema: Diagrama de Caso de Uso CadastrarGeral

Caso de Uso: CadastrarClientes


Data: 27/11/2014


cadastra um cliente. Este processo é separado em quatro cenários: cadastrar,

alterar, excluir e consultar um usuário.

Caso de uso: CadastrarCliente Ator: GerenteProjetos

Pré-condições: Não se aplica.


Fluxo Principal: 1. O ator solicita cadastrar um novo cliente.

2. O ator informa os dados necessários (nome, e-mail, razão social, telefone)

para cadastro do cliente.


4. O sistema informa que o cliente foi cadastrado com sucesso.




Caso de uso: AlterarCliente Ator: GerenteProjetos

Pré-condições: O cliente deve estar cadastrado.

106


Fluxo Principal: 1. O ator solicita alterar um cliente.

2. O ator informa os dados necessários (nome, e-mail, razão social, telefone)

para alterar o cliente.


4. O sistema informa que o cliente foi alterado com sucesso.




Caso de uso: ExcluirCliente Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita excluir um cliente

2. O ator informa o cliente a ser excluído.

3. O sistema verifica se o cliente existe.

4. O sistema pede confirmação para exclusão do cliente.

5. O sistema informa que o cliente foi excluído com sucesso.

Fluxo Alternativo: 3a. Cliente informado não existe

3a. 1 O sistema informa que o cliente não existe.


107

Caso de uso: ConsultarCliente Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita consultar um cliente.

2. O ator informa o cliente a ser consultado.

3. O sistema verifica se o cliente existe.

4. O sistema mostra as informações do cliente consultado.

Fluxo Alternativo: 3a. O cliente informado não existe

3a. 1 O sistema informa que o cliente não existe.


108


Projeto: Ovenbird


Caso de Uso: GerenciarAmbientes


Data: 27/11/2014

Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas

informações referente aos ambientes onde a loja virtual será implantada, contendo

todos os cadastros necessários para que o gerente de projetos e o desenvolvedor

possa administrar a entrega do sistema SLV. Sendo assim, será contemplado nesse

subsistema os casos de uso CadastrarAmbiente, ProvisionarAmbiente e

InstalarPuppet.

109


Projeto: Ovenbird

Subsistema: Diagrama de Caso de Uso GerenciarAmbientes

Caso de Uso: CadastrarAmbiente


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que o gerente de projetos ou

o desenvolvedor cadastra um ambiente. Este processo é separado em quatro

cenários: cadastrar, alterar, excluir e consultar um ambiente.

Caso de uso: CadastrarAmbiente Ator: GerenteProjetos e Desenvolvedor

Pré-condições: O cliente e o projeto devem estar cadastrados.

Pós-condições: Habilita os botões para executar os casos de uso

ProvisionarAmbiente e InstalarPuppet na tela.

Fluxo Principal: 1. O ator solicita cadastrar um novo ambiente.

2. O ator informa os dados necessários (tipo, descrição, url, ip, usuário e

senha) para cadastro do ambiente.


4. O sistema informa que o ambiente foi cadastrado com sucesso.




110

Caso de uso: AlterarAmbiente Ator: GerenteProjetos e Desenvolvedor

Pré-condições: O ambiente deve estar cadastrado.


Fluxo Principal: 1. O ator solicita alterar um cliente.

2. O ator informa os dados necessários (tipo, descrição, url, ip, usuário e

senha) para alterar o ambiente.


4. O sistema informa que o ambiente foi alterado com sucesso.




Caso de uso: ExcluirAmbiente Ator: GerenteProjetos e Desenvolvedor



Fluxo Principal: 1. O ator solicita excluir um ambiente

2. O ator informa o ambiente a ser excluído.

3. O sistema verifica se o ambiente existe.

4. O sistema pede confirmação para exclusão do ambiente.

5. O sistema informa que o ambiente foi excluído com sucesso.

Fluxo Alternativo: 3a. Ambiente informado não existe

3a. 1 O sistema informa que o ambiente não existe.


111

Caso de uso: ConsultarAmbiente Ator: GerenteProjetos e Desenvolvedor



Fluxo Principal: 1. O ator solicita consultar um ambiente.

2. O ator informa o ambiente a ser consultado.


4. O sistema mostra as informações do ambiente consultado.

Fluxo Alternativo: 3a. O ambiente informado não existe



112


Projeto: Ovenbird


Caso de Uso: InstalarPuppet


Data: 27/11/2014


o desenvolvedor executa o processo para instalar o Puppet Client no novo ambiente.

Este processo é descrito no caso de uso InstalarPuppet.

Caso de uso: InstalarPuppet Ator: GerenteProjetos e Desenvolvedor






4. O sistema mostra o botão “Configurar”.

5. O ator clica no botão para executar o processo de instalação.

6. O sistema informa que o ambiente foi configurado com sucesso.




3b. Informações de acesso ao ambiente erradas

3b. 1 O sistema informa que não conseguir acessar o ambiente.

3b. 2 O sistema retorna ao Fluxo Normal passo 4.

113


Projeto: Ovenbird


Caso de Uso: InstalarPuppet


Data: 27/11/2014


o desenvolvedor executa o processo para provisionar o novo ambiente. Este

processo é descrito no caso de uso ProvisionarAmbiente.

Caso de uso: ProvisionarAmbiente Ator: GerenteProjetos e Desenvolvedor






4. O sistema mostra o botão “Provisionar”.

5. O ator clica no botão para executar o processo de provisionamento.

6. O sistema informa que o ambiente foi provisionado com sucesso.




3b. Informações de acesso ao ambiente erradas

3b. 1 O sistema informa que não conseguir acessar o ambiente.

3b. 2 O sistema retorna ao Fluxo Normal passo 4.

114


Projeto: Ovenbird


Caso de Uso: GerenciarSolicitacoes


Data: 27/11/2014

Descrição: Esse caso de uso tem por objetivo o gerenciamento de todas as

solicitações de um cliente que deverão ser atendidas, contendo todos os cadastros

necessários para que os atores possam administrar o desenvolvimento na empresa

estudada. Sendo assim, será contemplado nesse subsistema os casos de uso

CadastrarProjeto, CadastrarSolicitacao, AgruparSolicitacoesSprint,

IniciarDesenvolvimento, EnviarParaVerificacao, ExecutarTestesAutomatizados,

DisponibilizarVersaoEmAceitacao e ImplantarVersaoEmProducao.

115


Projeto: Ovenbird

Subsistema: Diagrama de Caso de Uso GerenciarSolicitacoes

Caso de Uso: CadastrarProjeto


Data: 27/11/2014


cadastra um ambiente. Este processo é separado em quatro cenários: cadastrar,

alterar, excluir e consultar um projeto.

Caso de uso: CadastrarProjeto Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita cadastrar um novo projeto.

2. O ator informa os dados necessários (cliente, nome e url do repositório)

para cadastro do projeto.


4. O sistema informa que o projeto foi cadastrado com sucesso.




116

Caso de uso: AlterarProjeto Ator: GerenteProjetos

Pré-condições: O projeto deve estar cadastrado.


Fluxo Principal: 1. O ator solicita alterar um projeto.

2. O ator informa os dados necessários (cliente, nome e url do repositório)

para alterar o ambiente.


4. O sistema informa que o projeto foi alterado com sucesso.




Caso de uso: ExcluirProjeto Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita excluir um projeto

2. O ator informa o projeto a ser excluído.

3. O sistema verifica se o projeto existe.

4. O sistema pede confirmação para exclusão do projeto.

5. O sistema informa que o projeto foi excluído com sucesso.

Fluxo Alternativo: 3a. O projeto informado não existe

3a. 1 O sistema informa que o projeto não existe.


117

Caso de uso: ConsultarProjeto Ator: GerenteProjetos



Fluxo Principal: 1. O ator solicita consultar um projeto.

2. O ator informa o projeto a ser consultado.

3. O sistema verifica se o projeto existe.

4. O sistema mostra as informações do projeto consultado.


3a. 1 O sistema informa que o projeto não existe.


118


Projeto: Ovenbird


Caso de Uso: CadastrarSolicitacao


Data: 27/11/2014


o desenvolvedor cadastra uma solicitação. Este processo é separado em quatro

cenários: cadastrar, alterar, excluir e consultar um projeto.

Caso de uso: CadastrarSolicitacao Ator: GerenteProjetos e Desenvolvedor



Fluxo Principal: 1. O ator solicita cadastrar uma nova solicitação.

2. O ator informa os dados necessários (nome, data de início, data da

finalização e descrição) para cadastro de uma solicitação.


4. O sistema informa que a solicitação foi cadastrada com sucesso.




119

Caso de uso: AlterarSolicitacao Ator: GerenteProjetos e Desenvolvedor

Pré-condições: A solicitação deve estar cadastrada.


Fluxo Principal: 1. O ator solicita alterar uma solicitação.

2. O ator informa os dados necessários (nome, data de início, data da

finalização e descrição) para alterar a solicitação.


4. O sistema informa que a solicitação foi alterada com sucesso.




Caso de uso: ExcluirSolicitacao Ator: GerenteProjetos e Desenvolvedor.

Pré-condições: A solicitação deve estar cadastrado.


Fluxo Principal: 6. O ator solicita excluir uma solicitação.

7. O ator informa a solicitação a ser excluída.

8. O sistema verifica se a solicitação existe.

9. O sistema pede confirmação para exclusão da solicitação.

10. O sistema informa que a solicitação foi excluída com sucesso.


3a. 1 O sistema informa que a solicitação não existe.


120

Caso de uso: ConsultarSolicitacao Ator: GerenteProjetos e Desenvolvedor.

Pré-condições: A solicitação deve estar cadastrado.


Fluxo Principal: 1. O ator solicita consultar uma solicitação.

2. O ator informa a solicitação a ser consultada.

3. O sistema verifica se a solicitação existe.

4. O sistema mostra as informações da solicitação consultada.

Fluxo Alternativo: 3a. A solicitação informada não existe

3a. 1 O sistema informa que a solicitação não existe.


121


Projeto: Ovenbird


Caso de Uso: AgruparSolicitacoesSprint


Data: 27/11/2014


agrupa as solicitação que serão desenvolvidas na próxima Sprint.

Caso de uso: AgruparSolicitacoesSprint Ator: GerenteProjetos

Pré-condições: A solicitação deve estar cadastrada.



2. O ator move a solicitação da coluna Solicitações para a coluna A Faze.

3. O sistema atualiza o status da solicitação.

122


Projeto: Ovenbird


Caso de Uso: IniciarDesenvolvimento


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que o desenvolvedor informa

qual a funcionalidade que ele irá desenvolver.

Caso de uso: IniciarDesenvolvimento Ator: Desenvolvedor

Pré-condições: A solicitação deve estar na coluna A Fazer.



2. O ator move a solicitação da coluna A Fazer para a coluna Fazendo.


123


Projeto: Ovenbird


Caso de Uso: EnviarParaVerificacao


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que o desenvolvedor informa

a solicitação que acabou de desenvolver e libera a mesma para testes.

Caso de uso: EnviarParaVerificacao Ator: Desenvolvedor

Pré-condições: A solicitação deve estar na coluna Fazendo



2. O ator adiciona o código do Git na solicitação.

3. O ator move a solicitação da coluna Fazendo para a coluna Teste Unit.


124


Projeto: Ovenbird


Caso de Uso: ExecutarTestesAutomatizados


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que o SIC inicia o processo

de testes da solicitação informada.

Caso de uso: ExecutarTestesAutomatizados Ator: SIC

Pré-condições: A solicitação deve estar na coluna Teste Unit.


Fluxo Principal: 1. O ator verificar se a solicitação está no repositório de código.

2. O ator faz o check-in no repositório.

3. O ator executa os testes automatizados.

4. O sistema atualiza o status da solicitação em cada etapa dos testes.

125


Projeto: Ovenbird


Caso de Uso: DisponibilizarVersaoEmAceitacao


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que uma solicitação é

instalado no ambiente de aceitação.

Caso de uso: DisponibilizarVersaoEmAceitacao Ator: GerenteProjetos, Desenvolvedor, Qualidade

Pré-condições: A solicitação deve estar na coluna Aceitação.



2. O ator clica no botão para iniciar o processo.

3. O sistema executa a ferramenta de implantação.


126


Projeto: Ovenbird


Caso de Uso: ImplantarVersaoEmProducao


Data: 27/11/2014

Descrição: Este caso de uso descreve o processo em que uma solicitação é

instalado no ambiente de aceitação.

Caso de uso: ImplantarVersaoEmProducao Ator: GerenteProjetos, Desenvolvedor, Qualidade

Pré-condições: A solicitação deve estar na coluna Produção.



2. O ator clica no botão para iniciar o processo.

3. O sistema executa a ferramenta de implantação.


tcc - automatização de entrega de software em ambiente ágil de desenvolvimento

Documents