Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como surgiu essas práticas, o que se deseja alcançar com a implantação, os principais pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica de software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão em sua organização para a implantação dessas técnicas e práticas com embasamento.

1. DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE USANDO
PRÁTICAS DO GERENCIAMENTO DO CICLO DE VIDA DA
APLICAÇÃO E DESENVOLVEDOR/OPERAÇÃO
Washington Clemente dos Santos Borges1
Orientador: Gustavo Monti Rocha2
RESUMO
Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção
de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da
Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura
Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como
surgiu essas práticas, o que se deseja alcançar com a implantação, os principais
pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica
de software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão
em sua organização para a implantação dessas técnicas e práticas com
embasamento.
PALAVRAS-CHAVE: ALM, DevOps, Desenvolvimento e Manutenção de Software.
INTRODUÇÃO
Segundo Durães (2012) estamos na era do engajamento, da tecnologia. Hoje
os consumidores de tecnologia estão cada vez mais exigentes com os produtos que
consomem, e se faz necessário que o mercado de software acompanhe essas
mudanças. Desta forma, as empresas que desenvolvem softwares tem a missão de
alinhar seus processos de desenvolvimento e a operação de tal forma que seja
possível entregar software de maneira rápida mantendo a continuidade dos serviços.
Washington Clemente dos Santos Borges, concluinte do curso de Pós-Graduação em
Engenharia de Software Centrada em Métodos Ágeis, Analista de Sistemas na Maxprocess
Consultoria, ton.borges@gmail.com.
Gustavo Monti Rocha, Analista de Sistemas no Serviço Federal de Processamento de
Dados - SERPRO

2. Sendo assim, existem atualmente algumas disciplinas e técnicas que podemos
aplicar para que seja possível atingir esses objetivos.
PROBLEMA
Atualmente o tamanho dos softwares desenvolvidos tem sido cada vez maior.
Há cerca de 30 anos eles eram setoriais, contudo, nos dias de hoje eles controlam
toda a operação de uma empresa. Devido a esta mudança, se faz necessário cuidar
melhor de toda a cadeia produtiva do software, ou seja, desde como e onde
armazenar os códigos fontes à maneira como ele é entregue.
JUSTIFICATIVA
Neste artigo vamos introduzir o leitor ao mundo do desenvolvimento ágil de
software, através do gerenciamento do ciclo de vida da aplicação (ALM) e
Operação/Desenvolvimento (DevOps). O leitor irá compreender as técnicas
utilizadas por essas disciplinas e verá como é possível unir estas de forma que
possa ajudar no processo de desenvolvimento/manutenção de software de forma a
atender o mercado de forma mais rápida e dinâmica.
DEVOPS
HISTÓRIA
O termo DevOps foi criado em 2009 na conferência Velocity da O'Reilly com a
apresentação do trabalho 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
por John Allspaw e Paul Hammond. Entretanto, Carvalho (2013) relata que em 2008
já se discutia sobre o assunto com o termo “infraestrutura ágil”.
Willis (2011) relata que no Agile 2008 surgiram conversas sobre como
incorporar a metodologia ágil na infraestrutura, e a lista de discussão agile-sysadmin
foi quem iniciou a construção da ponte entre desenvolvedores e administradores de
sistemas. Patrick Debois era um dos participantes desta lista e um grande entusiasta
do assunto. Após assistir a palestra de John e Paul ele ficou tão animado que criou

3. ainda em 2009 o evento chamado DevOpsDay. Para Carvalho (2013) foi nesse
encontro na cidade Ghent – Bélgica no final de 2009 que tudo começou. Esse
evento continua acontecendo em várias partes do mundo ano após ano.
COMO FUNCIONA A INFRAESTRUTURA E O DESENVOLVIMENTO DE
SOFTWARE HOJE
Carvalho (2013) faz um relato sobre as atividades desses departamentos hoje
em dia: a infraestrutura é responsável pela manutenção dos sistemas sendo ela
quem faz todos os deploys e rollbacks. É também responsável por monitorar cada
um, verificando disponibilidade, carga em servidores e se preocupar com os SLA
(acordo de nível de serviço). Como consequência, o impacto de uma parada na
aplicação é grande, podendo gerar grandes prejuízos financeiros.
Com esse cenário, Carvalho (2013) afirma que a preocupação da
infraestrutura é proteger o valor do negócio.
Os desenvolvedores estão constantemente criando e aprimorando suas
aplicações, com isto novas versões são criadas e precisam ser
disponibilizadas, assim seus clientes poderão usufruir dos recursos
solicitados. (CARVALHO, 2013)
Nesta citação de Carvalho (2013) é fácil perceber que irá existir um
conflito entre desenvolvimento e infraestrutura, pois o desenvolvimento precisa que
suas alterações tenham suas builds realizadas de maneira rápida de forma a
aumentar do valor do negócio.
Nessa cultura, a equipe de operações normalmente é isolada da de
desenvolvimento, e as interações entre as duas é evitada ou forçada. A
característica marcante desse extremo é que o desenvolvimento e as
operações têm objetivos marcadamente contrários. A equipe de
desenvolvimento é comprometida e recompensada com entregas de novas
funcionalidades e em levar o produto adiante. O objetivo da equipe de
operações é manter a estabilidade acima de tudo. Sem a comunicação
correta, os objetivos entram em conflito, pois o interesse da equipe de
operações é não entregar novas funcionalidades, e o maior interesse do
desenvolvimento é entregar novas funcionalidades o mais rápido possível.
(HASHIMOTO, 2013),

4. Hashimoto (2013) confirma a visão de Carvalho sobre esse conflito existente
hoje entre infraestrutura e desenvolvimento onde cada setor somente se preocupa
com os resultados a serem entregues de seus respectivos setores.
MUDANÇAS NECESSÁRIAS
Carvalho (2013) relata sobre a necessidade da evolução na infraestrutura de
forma rápida e que o desenvolvimento precisa ter controle de todas as fases das
gerações das builds e deploy. Na infraestrutura isso se dá na parte de
automatização de tarefas, ela deve prover meios para que o desenvolvedor consiga
fazer deploy de forma automática, sem necessidade de interversão da infraestrutura.
Sete (2013) ainda comenta sobre a necessidade do feedback contínuo, seja
ele de pessoa ou de máquina, onde infraestrutura e desenvolvimento tenham uma
melhor comunicação.
CULTURA DEVOPS
Carvalho (2013) relata que Patrick Debois diz que DevOps é uma cultura, e
que essa seria dividida em 4 partes, a saber:
•
Cultura
o
o
Fim das divisões
o
Relação saudável entre as áreas
o
•
Colaboração
Mudança de comportamento
Automação
o
Deploy
o
Controle

5. o
o
Gerência de configuração
o
•
Monitoração
Orquestração
Avaliação
o
o
Medições
o
Performance
o
•
Métricas
Logs e integração
Compartilhamento
o
O feedback é tudo
o
Boa comunicação entre a equipe
APPLICATION LIFECYCLE MANAGEMENT (ALM)
HISTÓRIA
O ALM (Gerenciamento do Ciclo de Vida da Aplicação) surgiu da necessidade
de controlar toda a cadeia produtiva do software. Farias (2012) lembra que com o
avanço da tecnologia em diversos campos, o software tem ficado cada dia mais
complexo e gerando cada vez mais valor aos negócios dos clientes. Essa
complexidade a que Farias (2012) se refere vem da necessidade da integração do
software com outros softwares, e/ou alteração em softwares críticos que já estão em
produção.
Farias define todo esse processo de construção de novos softwares e
alteração dos que já existem de ALM.

6. PILARES PARA ALM
Condé (2009) define que o ALM é estruturado em cima de três pilares que se
complementam. São eles: pessoas, processos e ferramentas, que quando unidos
fornecem os recursos necessários para que as empresas possam gerenciar todo o
ciclo de vida de uma aplicação.
•
PILAR PESSOAS
Pessoas
bem
treinadas
e
capacitadas
formam
a
cola
que
unem
adequadamente as ferramentas e os processos do ALM.
•
PILAR PROCESSOS
O pilar “processos” é identificado como todo o conjunto de boas práticas,
artefatos, guias e manuais que conduzem a construção e manutenção de uma
aplicação.
•
PILAR FERRAMENTAS
Por último, as “ferramentas” são os meios/equipamentos/tecnologias que
automatizam e facilitam a condução dos processos pelas pessoas.
DISCIPLINAS PRESENTES NO ALM
Vamos analisar abaixo todas as disciplinas que Condé (2009) classifica como
disciplinas presentes e essenciais ao ALM.
GERENCIAMENTO DE REQUISITOS
Condé (2009) define o gerenciamento de requisitos como a prática de
documentar e manter a rastreabilidade dos requisitos ao longo do ciclo de vida da
aplicação. Dentro do gerenciamento de requisitos temos algumas funcionalidades:
•
Documentar os funcionais e não funcionais;
•
Identificar se estão aderentes com as necessidades de negócio;
•
Priorizar os requisitos;

7. •
Selecionar os que serão implementados no projeto ou em fase específica;
•
Identificar a dependência entre os mesmos;
•
Mapeá-los com a arquitetura;
•
Mapeá-los com as funcionalidades da aplicação;
•
Verificar se foram atendidos e estão em conformidade com as necessidades
dos usuários.
GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE
Dantas (2012) define a gerencia de configuração como uma disciplina que
controla e notificam as inúmeras correções, extensões e adaptações aplicadas
durante o ciclo de vida do software de forma a assegurar um processo de
desenvolvimento e evolução sistemático e rastreável, sendo indispensável quando
equipes manipulam, muitas vezes em conjunto, artefatos comuns.
Condé (2009) ainda define algumas funcionalidades realizadas pela gerencia de
configuração, a saber:
•
Controlar o acesso aos artefatos;
•
Armazenar as múltiplas versões de cada artefato;
•
Rastrear as modificações de cada versão;
•
Comparar versões;
•
Identificar a versão dos artefatos que estão diretamente ligados a uma
versão final da aplicação;
•
Restaurar versões especificas dos artefatos baseados em uma versão
específica da aplicação.
MONTAGEM E INTEGRAÇÃO
Para Condé (2009) A disciplina de Montagem e Integração consiste na prática de
unir todos estes componentes em apenas um único pacote, a fim de ser testado e
distribuído na infraestrutura de TI. Algumas das funcionalidades da disciplina são:
•
Recuperar todos os artefatos do repositório de código-fonte;
•
Mapear os artefatos com a nova versão da aplicação;

8. •
Compilar o código-fonte;
•
Organizar o código compilado em um específico layout conforme definido;
•
Criar um pacote de instalação (setup) para ser testado;
•
Abortar o processo de build caso encontre algum erro ou inconsistência
nos artefatos.
ENGENHARIA E DISTRIBUIÇÃO
Para Condé (2009) a disciplina de Engenharia de Distribuição é responsável
por garantir a consistência das diversas versões da aplicação:
•
Documentação das dependências externas de cada versão;
•
Minimizar o tempo entre as atualizações de versões;
•
Utilização de ferramentas para automatizar a distribuição das versões ou
correções;
•
Tratar rapidamente as falhas de distribuição.
GERENCIAMENTO DE DEFEITOS
Quintela e Araújo (2012) definem que a gerência de defeitos tem como
objetivo definir práticas para prevenir os defeitos e minimizar os riscos de um projeto.
Condé (2009) define algumas ações da disciplina de Gerenciamento de
Defeitos:
•
Descrever o comportamento esperado;
•
Descrever o comportamento ocorrido;
•
Descrever os passos necessários para reproduzir o defeito;
•
Priorizar os defeitos conforme a demanda;
•
Direcionar o defeito para ser corrigido por um desenvolvedor;
•
Registrar se o defeito foi corrigido.

9. TESTE UNITÁRIO, INTEGRADO E DE REGRESSÃO
O teste unitário é o teste isolado e exercido apenas sobre um componente,
que pode ser uma classe ou um método. Os testes integrados atuam sobre módulos,
é uma tarefa normalmente executada pelos programadores. Os testes de regressão
verificam se as alterações introduzidas a cada novo build não geraram novos
defeitos. O benefício de aplicar estes testes é o de garantir a qualidade do software
e sua conformidade com os requisitos definidos. Algumas ações:
•
Criação de testes unitários para cada componente;
•
Criação dos testes integrados no nível de módulos lógicos e casos de uso;
•
Os testes são também considerados artefatos, e assim devem ser
armazenados dentro do repositório;
•
Uso de ferramentas para automatizar a geração de relatórios e logs de
erros.
ANALISE DE CÓDIGO
A disciplina Análise de Código é responsável em identificar se o código escrito
está aderente a padrões e políticas da empresa. Algumas ações realizadas por esta
disciplina:
•
Validar o formato e estilo de codificação;
•
Verificar a documentação interna do código;
•
Garantir o uso de “design patterns”;
•
Detectar problemas de desempenho;
•
Identificar vulnerabilidades conforme as políticas de segurança;
•
Garantir a proteção e privacidade das informações que a aplicação
manipula;
•
Identificar a compatibilidade da aplicação em conformidade com normas
de mercado.

10. TESTE DE SISTEMA
Condé (2009) afirma que a disciplina Teste de Sistema envolve o teste da
aplicação quando completada. Os testes funcionais, conhecidos como testes “de
caixa preta”, são executados por esta disciplina. Eles procuram identificar se a
aplicação está aderente aos requisitos, além de serem usados como ferramentas
para aceitação ou não da aplicação construída. Os testes de sistema são facilitados
quando as disciplinas de gerenciamento de requisitos, configuração de software,
análise de código e gerenciamento de defeitos são executadas corretamente.
Algumas ações típicas desta disciplina:
•
Detectar problemas em desempenho;
•
Detectar se os requisitos estão presentes na aplicação.
METODOLOGIA
Criar um roteiro de implantação do ALM e DevOps para uma fábrica de
software de Belo Horizonte, Minas Gerais, que trabalha com tecnologia Microsoft e
Eclipse com o SDK Android.
Atualmente na empresa já existe uma instalação do Team Foundation Server
(TFS) na versão 2012 que é usado como controle de versão, sem nenhum benefício
adicional.
Para o rastreamento de defeitos e lançamentos de tarefas, hoje é usado o
Redmine, que posteriormente será substituído pelo TFS usando a estrutura de itens
de trabalho.
Abaixo serão descritos 7 passos para a implantação deste roteiro,
considerando a realização de apenas um passo por mês.
Passo 1:
Configuração do Controle de Versão: Será configurado para cada projeto
específico, branchings, garantindo assim, que sempre exista um branching para
Produção, Homologação e Desenvolvimento. Cada projeto especifico receberá suas

11. configurações de segurança, ou seja, somente membros da equipe do projeto
poderão ter acesso aos arquivos, podendo também controlar quais arquivos terão
check outs exclusivos evitando que seja necessário realizar merge em arquivos com
alto grau de complexidade para essa operação.
Passo 2:
Configuração dos Itens de Trabalho: Nesta etapa serão lançadas todas as
tarefas, sejam de defeitos, implementação ou até mesmo de testes. Com o item de
trabalho configurado e sendo usado da maneira correta, será possível criar a
rastreabilidade do código, pois ao fazer o check in de alguma alteração no código,
será necessário informar a qual item de trabalho pertence determinada alteração
mantendo principalmente a rastreabilidade entre os mesmos.
Serão configurados alguns relatórios e gráficos, para que se possa saber: os
itens
de
trabalho
pendentes
de
implementação,
quantos
são
de
erros,
acompanhamento em tempo real do andamento dos itens de trabalho, product
backlog concluído e outros.
Passo 3:
Testes unitários: Serão realizados workshops sobre como implementar de
forma correta testes unitários, quando e onde aplicar para que com isso a qualidade
dos códigos sejam melhorada.
Passo 4:
Ainda referente a testes, será implementado o teste funcional, usando o Test
Manager do Visual Studio. Com ele é possível trabalhar com o conceito de defeitos
ricos, pois isso acaba com o dilema de que isso "funciona na minha máquina”. O
Test Manager coleta dados da aplicação enquanto realiza os testes, inclusive
criando um IntelliTrace, que é a pilha de execução da aplicação que em casos de
erros o desenvolvedor pode ver o que estava na memória no momento do erro.
Passo 5:
Configuração do Lab Manager: Esse passo terá um grande envolvimento da
equipe de Infraestrutura, onde será criada uma biblioteca de máquinas virtuais, para
que os testadores possam ter ambientes distintos para testes.

12. O Lab Manager é um gerenciador de ambientes virtuais, que estende o TFS,
onde os testadores de software podem criar e gerenciar seus ambientes, conforme a
necessidade de cada software a ser testado.
Com o Lab Manager a cada erro encontrado o testador pode realizar um
snapshot da máquina virtual e enviar para o desenvolvedor que irá receber a
máquina no estado que ocorreu o erro.
Passo 6:
Configuração de Testes de Interface: Até o momento já temos alguns
processos de testes implantados, agora deve-se aprimorar essas técnicas usando o
Coded UI Test.
Com o Coded UI Test é possível gravar uma macro com os itens a serem
testados na interface do aplicativo, com isso, é gerado o código de teste onde o
Visual Studio é capaz de executar.
Passo 7:
Configuração do Team Build: O build da aplicação será realizado de forma
automatizada, ou seja, a cada build que o TFS realizar será executada toda a bateria
de testes, sejam eles unitários ou funcionais. Ainda neste passo será configurado o
deploy continuo em ambiente de homologação. A cada build realizado com sucesso,
todos os itens de trabalhos que pertencem ao build gerado serão integrados no
branching de homologação e será realizado o deploy no servidor de homologação.
CONCLUSÃO
A implantação do ALM e DevOps, causa uma mudança de cultura muito
grande na empresa. Ela deve sempre ser realizada de forma que minimize os
impactos para a equipe de forma que não atrapalhe o andamento dos projetos e que
todos os envolvidos se sintam confortáveis com essa mudança. Ela deve ser
realizada e pensada à longo prazo, pois os resultados serão percebidos conforme o
avanço de cada etapa.
É importante ressaltar que, a implantação irá variar de empresa para empresa
conforme a demanda e/ou necessidade de cada uma. Sendo assim, é necessário

13. realizar uma análise do ambiente. Nem todas as políticas do ALM precisam ser
implantadas. Deve-se realizar uma análise empresarial para identificar os pontos de
carência e onde as práticas do ALM agregam maior valor.
Devido ao prazo estimado para implantação completa deste trabalho (em
torno de 7 meses), não será possível apresentar neste artigo os resultados obtidos
com a implantação aqui proposta.
REFERÊNCIAS
CARVALHO, J. A. 2013. Disponível em: <http://gutocarvalho.net/octopress/2013/03/
16/o-que-e-um-devops-afinal/> Acesso em: 10/10/2013
HASHIMOTO, M. 2013. Disponível em: <http://www.infoq.com/br/articles/wide-rangedevops> Acesso em: 13/10/2013
DURÃES, R. Disponível em: <http://www.microsoftvirtualacademy.com/Content/
ViewContent.aspx?et=2170&m=2166&ct=14599#?fbid=zloEhVZMcNU> Acesso em:
01/10/2013
SETE, M. 2013. Palestra ALM Pratices.
FARIAS, W. 2012. Disponível em: <https://www.ibm.com/developerworks/
community/blogs/rationalbrasil/entry/alm?lang=en> Acesso em: 16/11/2013
CONDÉ,
L.
2009.
Disponível
em:
<http://msdn.microsoft.com/pt-br/
library/ee156630.aspx#item2> Acesso em: 15/11/2013.
DANTAS, C. 2012. Disponível em: <http://www.devmedia.com.br/gerencia-deconfiguracao-de-software/9145#ixzz2kscbTc5z> Acesso em: 16/11/2013
QUINTELA, B 2012 E ARAÚJO, M. 2012. Engenharia de Software Magazine Edição
47.
WILLIS, J 2011. Disponível em: http://itrevolution.com/the-convergence-of-devops/
Acesso em: 16/11/2013.

14. TRABALHO DE CONCLUSÃO DE CURSO PÓS-GRADUAÇÃO LATO SENSU
Aluno (a):
Washington Clemente dos Santos Borges
Curso:
Turma:
Engenharia de Software Centrada em Métodos Ágeis
2013/4
Título do Artigo:
DESENVOLVIMENTO E MANUTENÇÃO DE SOFTWARE USANDO PRÁTICAS DO GERENCIAMENTO DO
CICLO DE VIDA DA APLICAÇÃO E DESENVOLVEDOR/OPERAÇÃO
Professor Orientador:
Gustavo Monti Rocha
Coordenador do curso:
Yoris Linhares
Data:
16 de Dezembro de 2013
Resumo:
Neste artigo o leitor será apresentado ao mundo do desenvolvimento e manutenção
de software envolvendo técnicas e práticas do Gerenciamento do Ciclo de Vida da
Aplicação ALM da sigla em inglês para Application Lifecycle Management e a cultura
Desenvolvedor/Operação (DevOps), será abordado um breve histórico de como
surgiu essas práticas, o que se deseja alcançar com a implantação, os principais
pilares de cada técnica e como implantar essas técnicas e práticas em uma fábrica de
software. Ao final deste artigo o leitor terá o conhecimento para iniciar a discursão em
sua organização para a implantação dessas técnicas e práticas com embasamento.
Total de pontos:
Situação Final: (
)Aprovado
(
)Reprovado
________________________
________________________
Professor Orientador
Coordenador

15. DECLARAÇÃO DE RECEBIMENTO DO TRABALHO DE CONCLUSÃO DE CURSO
Declaro, para os devido fins, que recebi a ata de avaliação com dados e resumo do TCCTrabalho de Conclusão de Curso do(a) aluno(a) Washington Clemente dos Santos Borges, da
turma 2013/4, do Curso de Pós-Graduação Lato Sensu Engenharia de Software Centrada em
Métodos Ágeis, devidamente datada e assinada pelo professor orientador, com indicação de
aprovação do aluno no TCC.
Declaro ainda ser de minha responsabilidade encaminhar ao NTCC (Núcleo de Trabalho
de Conclusão de Curso) o documento citado acima.
Belo Horizonte, ___ de _______________ de ______.
Nome do Coordenador(a): Yoris Linhares_____________________________
Recebido por:___________________________________________________
Assinatura: _____________________________________________________