GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE

UNIVERSIDADE DO SUL DE SANTA CATARINA
CARLOS DOS SANTOS CADAVEZ
GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO
FERRAMENTAS OPEN SOURCE
FLORIANÓPOLIS
2014

CARLOS DOS SANTOS CADAVEZ
Trabalho de Conclusão de Curso apresentado ao Curso
de Sistemas de Informação da Universidade do Sul de
Santa Catarina, como requisito parcial à obtenção do
título de Bacharel em Sistemas de Informação.
Orientadora: Prof.ª Maria Inés Castiñeira, Dra.
Florianópolis
2014

Este Trabalho de Conclusão de Curso foi julgado
adequado à obtenção do título de Bacharel em Sistemas
de Informação e aprovado em sua forma final pelo
Curso de Graduação em Sistemas de Informação da
Universidade do Sul de Santa Catarina.

Aos meus pais, irmãs, minha namorada Carolina que, com
muito carinho e incentivo, não mediram esforços para que
eu chegasse até esta etapa de minha vida.

AGRADECIMENTOS
Agradeço à minha mãe Raquel, heroína que sempre me apoiou, incentivo em
todas as horas.
À minha namorada Carolina, pela paciência, incentivo, pela força e carinho.
À minha orientadora Maria Inês, pela paciência na orientação e incentivo que
tornaram possível a conclusão deste trabalho.

RESUMO
O processo de desenvolvimento de software é uma atividade bastante complexa e tem
aumentado muito com as necessidades cada vez maior por sistemas computacionais. Essa
demanda crescente traz consigo a preocupação em maximizar os resultados através de um
controle eficaz das aplicações de software, controle que permita a escalabilidade dos sistemas
e o acompanhamento de todo o seu ciclo de vida. Para um acompanhamento eficaz processos
e metodologias existem como forma de oferecer auxílio, utilizando para isso muitas
ferramentas. Com o intuito de oferecer uma solução que possa auxiliar essas necessidades foi
desenvolvida esta monografia. Neste trabalho é apresentada uma proposta de solução para o
gerenciamento do ciclo de vida das aplicações (Application Lifecycle Management ou ALM),
utilizando para isso um conjunto formado por ferramentas de software livre. Esse conjunto
oferece suporte a diversas etapas presentes no desenvolvimento de software e pode ser
aplicado a diferentes linguagens de desenvolvimento. É apresentado também uma descrição
de algumas das ferramentas que compõem o processo, dando uma visão geral de algumas de
suas funcionalidades e de como estas podem trabalhar em conjunto, conformando uma
solução de ALM. Concluindo percebe-se que a adoção do conjunto de ferramentas proposto
serve para solucionar muitos dos problemas encontrados no processo de desenvolvimento de
software, observa-se também que essa implementação de ferramentas e práticas pode ser feita
de forma gradual. Finalizando são apresentadas algumas sugestões para prosseguimento à
partir deste trabalho.
Palavras-chave: Gerenciamento do ciclo de vida das aplicações. ALM. Ferramentas open-
source.

LISTA DE ILUSTRAÇÕES
Figura 1 – Fases da engenharia de software.............................................................................19

Figura 2 – Classificação funcional das ferramentas CASE......................................................26

Figura 3 – Classificação de ferramentas CASE com base em atividades. ...............................27

Figura 4 – Os cinco estágios do processo de testes..................................................................31

Figura 5 – Etapas metodológicas..............................................................................................44

Figura 6 – Interface novo usuário.............................................................................................50

Figura 7 – Interface de usuários. ..............................................................................................51

Figura 8 – Interface de criação de novo papel..........................................................................51

Figura 9 – Interface de projetos................................................................................................52

Figura 10 – Interface para criação de projeto...........................................................................52

Figura 11 – Interface para criação de tarefa. ............................................................................53

Figura 12 – Interface de tarefas do projeto...............................................................................53

Figura 13 – Gráfico de Gantt....................................................................................................54

Figura 14 – Interface de relatório de tempo gasto....................................................................54

Figura 15 – Pastas criadas nos diretórios..................................................................................56

Figura 16 – Tela projeto Subversion. .......................................................................................56

Figura 17 – Tela Subversion, arquivo criado. ..........................................................................57

Figura 18 – Tela Subversion novo arquivo. .............................................................................57

Figura 19 – Interface Eclipse, integrando com Subversion......................................................58

Figura 20 – Interface Eclipse com projeto Subversio...............................................................59

Figura 21 – Integração Redmine com Subversion....................................................................59

Figura 22 – Arquivos integrados. .............................................................................................60

Figura 23 – Arquivo pom. ........................................................................................................60

Figura 24 – Arquétipos disponíveis..........................................................................................61

Figura 25 – Configuração projeto Maven.................................................................................62

Figura 26 – Arquivos pom gerado............................................................................................63

Figura 27 – Fases do ciclo de vida Maven. ..............................................................................64

Figura 28 – Eclipse, arquétipos disponíveis.............................................................................65

Figura 29 – Estrutura do projeto Maven gerado.......................................................................66

Figura 30 – Relatório Jacoco....................................................................................................67

Figura 31 – Arquivos não versionados.....................................................................................68

Figura 32 – Tela inicial Jenkins................................................................................................69

Figura 33 – Tela de configuração Jenkins................................................................................70

Figura 34 – Tela new job..........................................................................................................71

Figura 35 – Tela configuração do repositório. .........................................................................71

Figura 36 – Tela de projeto, build bem sucedido. ....................................................................72

Figura 37 – Interface build periódico. ......................................................................................72

Figura 38 – Interface build com problemas..............................................................................73

Figura 39 – Classe de testes JUnit............................................................................................74

Figura 40 – Codificação da classe de teste...............................................................................74

Figura 41 – Codificação classe Data. .......................................................................................75

Figura 42 – Resultado do teste. ................................................................................................76

Figura 43 – Resultado do build no Jenkins...............................................................................76

Figura 44 – Fluxograma da proposta de uso das ferramentas. .................................................79

LISTA DE QUADROS
Quadro 1 – Resumo da classificação da pesquisa. ...................................................................43

SUMÁRIO
1
INTRODUÇÃO..............................................................................................................................12

1.1
PROBLEMÁTICA........................................................................................................................14

1.2
OBJETIVOS .................................................................................................................................15

1.2.1
Objetivo geral ...........................................................................................................................15

1.2.2
Objetivos específicos ................................................................................................................16

1.3
JUSTIFICATIVA..........................................................................................................................16

1.4
ESTRUTURA DO TRABALHO..................................................................................................17

2
REVISÃO BIBLIOGRÁFICA......................................................................................................18

2.1
ENGENHARIA DE SOFTWARE................................................................................................18

2.1.1
Processo.....................................................................................................................................19

2.1.2
Métodos .....................................................................................................................................20

2.1.3
Ferramentas..............................................................................................................................20

2.2
FERRAMENTAS CASE ..............................................................................................................21

2.3
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE.......................................................27

2.3.1
Especificação de software........................................................................................................28

2.3.2
Projeto e implementação de software.....................................................................................29

2.3.3
Validação de software..............................................................................................................31

2.3.4
Evolução de software ...............................................................................................................32

2.4
GERENCIAMENTO DO CICLO DE VIDA DAS APLICAÇÕES.............................................33

2.4.1
Pilares da ALM ........................................................................................................................34

2.4.2
Disciplinas ALM.......................................................................................................................36

2.4.2.1
Gerenciamento de Requisitos (Requeriments Management) ..................................................36

2.4.2.2
Gerenciamento de configuração de software (Software configuration Management)............36

2.4.2.3
Montagem e integração (build and integration) .....................................................................37

2.4.2.4
Gerenciamento de Defeitos (Defect Management).................................................................38

2.4.2.5
Teste unitário, Integrado e de Regressão (Unit test, Integrated and Regression)...................38

2.4.2.6
Análise de Código (code analysis)..........................................................................................39

2.4.2.7
Teste de Sistema (System test) ................................................................................................39

2.4.2.8
Relatórios de Acompanhamento (Status Report)....................................................................40

3
MÉTODO DE PESQUISA............................................................................................................41

3.1
CARACTERIZAÇÃO DO TIPO DA PESQUISA.......................................................................41

3.2
ETAPAS METODOLÓGICAS ....................................................................................................43

3.3
DELIMITAÇÕES .........................................................................................................................45

4
FERRAMENTAS PARA O GERENCIAMENTO DO CICLO DE VIDA DAS
APLICAÇÕES......................................................................................................................................47

4.1
PESQUISA DAS FERRAMENTAS DE ALM ............................................................................47

4.2
DESCRIÇÃO DAS FERRAMENTAS.........................................................................................49

4.2.1
Gerenciamento de requisitos com Redmine ..........................................................................49

4.2.2
Controle de versões com Subversion......................................................................................55

4.2.3
Gerenciamento de dependências e builds com Maven..........................................................60

4.2.4
Integração contínua com Jenkins ...........................................................................................67

4.2.5
Testes unitários com JUnit ......................................................................................................73

4.2.6
Considerações sobre o uso das ferramentas no ciclo de vida das aplicações......................77

4.2.7
Relato de experiências..............................................................................................................80

5
CONCLUSÕES E TRABALHOS FUTUROS ............................................................................84

5.1
CONCLUSÕES.............................................................................................................................84

5.2
RECOMENDAÇÕES ...................................................................................................................85

12
1 INTRODUÇÃO
A demanda por soluções computacionais aumentou consideravelmente, devido à
competitividade cada vez maior entre as empresas, bem como à sociedade, que exige sistemas
a cada dia mais sofisticados. Alguns sistemas assumiram muita importância, como por
exemplo os encontrados nos smartphones, que se popularizaram e estão presente nas mãos de
muitas pessoas. Segundo pesquisa de eMarketer.com, “Até, 2017, o Brasil terá 70,5 milhões
de usuários de smartphones em uso” (de LUCA, 2014). Diante dessa demanda sempre
crescente de sistemas informatizados, diversos métodos, ferramentas e todo um corpo de
conhecimento têm sido criados ao longo dos anos, visando guiar o processo de
desenvolvimento de software. A disciplina mãe dessa área, e de todos os novos conceitos
relacionados que vão surgindo, é a “Engenharia de Software”. Ela foi proposta em 1968, em
um momento histórico conhecido como ‘crise de software’. Segundo Sommerville (2007, p.
5), “A engenharia de software é uma disciplina de engenharia relacionada com todos os
aspectos da produção de software, desde os estágios iniciais de especificação do sistema até
sua manutenção, depois que entrar em operação”.
Esta importante disciplina está delimitada, segundo o guia de engenharia de
software (Software Engineering Body of Knowledge - Swebok), em 10 áreas de
conhecimento, que são:
• requisitos de software: trata do levantamento, análise, especificação e
validação dos requisitos de software, bem como o gerenciamento deles durante
todo o ciclo de vida do produto. (SWEBOK, 2014);
• design de software: etapa em que são analisados os requisitos de software,
definindo a arquitetura. Nesta fase são descritos os componentes em um nível de
detalhe que permita a sua construção. (SWEBOK, 2014);
• teste de software: segundo o (SWEBOK, 2014):
Teste de software é uma atividade executada para avaliar a qualidade do produto, e
para melhorá-lo pela identificação de defeitos e problemas. Teste de software
consiste da verificação dinâmica do comportamento de um programa em um
conjunto finito de casos de teste, adequadamente selecionados de um domínio de
execução, usualmente infinito, contra o comportamento esperado;
• construção de software: conforme (SWEBOK, 2014), a construção de software

13
refere-se a criação detalhada do software, através da combinação da codificação,
verificação, testes unitários, testes de integração e depuração;
• manutenção de Software: atividades de suporte custo-efetivo a um sistema de
software, que podem ocorrer antes e após a entrega do software. Após a entrega
do software são feitas modificações com o objetivo de corrigir falhas, melhorar
seu desempenho ou adapta-lo a um ambiente modificado. Antes da entrega do
software são feitas atividades de planejamento (SWEBOK, 2014);
• gerência de configuração de software: em concordância com (SWEBOK,
2014) a gerência de configuração de software trata de identificar a configuração
do software em pontos distintos do tempo, com o propósito de controlar
modificações na configuração e manter a integridade durante o ciclo de vida do
sistema;
• gerência de engenharia de software: trata dos aspectos da Engenharia de
software, apontando mensuração e gerenciamento (SWEBOK, 2014);
• processo de engenharia de software: Esta etapa trata da implementação,
avaliação, mensuração, gerenciamento, alteração e melhora do processo de
software. (SWEBOK, 2014);
• ferramentas e métodos de engenharia de software: apresenta as ferramentas e
os métodos a serem aplicados na engenharia de software (SWEBOK, 2014);
• qualidade de software: De acordo com (SWEBOK, 2014) nessa fase se aborda
as considerações relativas à qualidade de software, esta etapa vai além dos
processos do ciclo de vida do software.
Mudanças de paradigma e a presença da tecnologia da informação dentro das
empresas fizeram surgir a necessidade de maior interação entre a gestão de negócios e a
engenharia de software. Surgiu, então, o conceito de gerenciamento do ciclo de vida dos
aplicativos, ou do inglês, ALM (Application Lifecycle Management). No entendimento de
(CARLOS, 2014 ), “ALM é todo processo que guia a vida útil de uma aplicação desde sua
concepção, passando pela construção, operação e evolução”.
Luciano Condé (2009) esclarece que o “ALM não apenas observa qual é o método de
construção, mas preocupa também em como a empresa está gastando o seu dinheiro no
gerenciamento daquele ativo corporativo”. O autor também afirma que um destaque
importante é a diferença entre ALM e o ciclo de vida do desenvolvimento de software ou

14
Software Development Lifecycle (SDLC). Segundo ele o SDLC pode ser definido como um
processo focado no desenho, criação e manutenção de aplicações. Já o ALM é um guia que
acompanha toda a vida da aplicação, sendo que o ciclo de vida do desenvolvimento do
software (SDLC) é uma das fases do ALM.
Esta prática envolve diferentes papéis, chamados de “Pilares da ALM”. A união
destes pilares fornece os recursos necessários para que as empresas possam gerenciar os
ciclos de vida de suas aplicações (CONDÉ, 2009).
Ainda, no entendimento de Condé (2009), para identificar as entradas, resultados
esperados e os envolvidos em cada etapa, a ALM é dividida em disciplinas. Todo ciclo de
vida está compreendido e separado em fases. As fases da ALM são: definição, construção e
operação, sendo que cada fase possui ainda subdivisões ou subfases.
A implantação de ALM é realizada através da utilização de ferramentas. Essas
ferramentas atuam de forma integrada e auxiliam nas seguintes etapas: gerenciamento de
requisitos, arquitetura, codificação, testes, controle e gerenciamento de versões. Empresas
como: Microsoft, HP, Borland, IBM, Xerox possuem ferramentas para implantação de ALM.
(GARTNER, 2012).
1.1 PROBLEMÁTICA
Um dos grandes desafios das empresas de software é como modernizar o processo
de desenvolvimento. A estratégia considerada para isso deve estar presente durante todo o
ciclo de desenvolvimento. As aplicações modernas estão focadas em um novo perfil de
usuário. Esse novo consumidor está conectado diariamente, conhece aplicativos, utiliza
serviços on-line, busca mudanças muito mais rapidamente, faz com que os sistemas atuem
como serviços, desta forma a qualidade precisa estar presente durante todo o ciclo de vida.
Assim, as respostas devem ser geradas mais rapidamente, e isto obriga as empresas a
repensarem o modelo de construção de aplicações.
Novos modelos devem permitir a entrega de atualizações constantes e a
integração da equipe, seja ela grande ou pequena.
Hoje em dia, muitas organizações têm grandes equipes de desenvolvimento,
trabalhando em software para suportar o negócio. Muitas vezes, as equipes estão espalhadas

15
no mundo. Isto coloca muitos problemas potenciais, tais como as questões de colaboração,
manutenção do código fonte, gerenciamento de requisitos e, assim, por diante. Sem processos
para suportar o desenvolvimento de software moderno, o negócio provavelmente vai sofrer.
(ROSSBERG e OLAUSSON, 2012).
A ALM surge como alternativa para esse novo modelo de desenvolvimento.
Diversas ferramentas auxiliam nesse processo, algumas proprietárias e outras de software
livre ou código aberto, do inglês (open source). Nesse sentido, software livre consiste em um
programa que pode ter seu código fonte alterado por qualquer usuário e não exige licença para
distribuição. (ASSOCIAÇÃO DE SOFTWARE LIVRE.ORG, 2014).
Entre as diversas dificuldades das organizações para adotar essas estratégias de
ALM, podem ser mencionadas a falta de conhecimento sobre esse modelo e sobre as
ferramentas que facilitam a sua aplicação.
Dessa forma, as perguntas de pesquisa deste trabalho se resumem em: como a
estratégia de ALM pode auxiliar à organização no gerenciamento do processo de software?
Quais ferramentas de software livre/código aberto suportam essa alternativa? Quais as
diferenças entre essas diversas ferramentas e quais os objetivos de cada uma delas?
1.2 OBJETIVOS
A seguir, são apresentados os objetivos deste trabalho.
1.2.1 Objetivo geral
• Definir um conjunto (ou pilha) de ferramentas open source, que oferecem auxilio no
gerenciamento das diversas etapas do ciclo de vida das aplicações.

16
1.2.2 Objetivos específicos
Os objetivos específicos são:
• apresentar o conceito de ALM explicitando suas características principais;
• apresentar a importância de ALM no cenário de desenvolvimento de software
atual;
• pesquisar e selecionar ferramentas de código aberto usadas no processo de
ALM;
• descrever a utilização de ferramentas de código aberto utilizadas no processo de
ALM, demonstrando algumas de suas funcionalidades.
1.3 JUSTIFICATIVA
A adoção de ALM é importante para toda a empresa que deseja automatizar seus
processos de desenvolvimento e acompanhar sua aplicação durante todo o ciclo de vida. Este
conceito permite uma série de possibilidades de integração entre os setores de
desenvolvimento, além de se adaptar à empresa de acordo com seu nível de maturidade. ALM
deve ser implantada após uma análise de nível de maturidade da organização.
Neste trabalho, serão apresentados os passos de implantação utilizando
ferramentas open source, abordagem que é muito apropriada para times pequenos e médios
(SOUZA, 2013), assim como pequenas e médias empresas. Além disso, a opção pelo uso de
ferramentas de código aberto permite uma independência maior de fornecimento do software,
o cliente não fica preso a nenhum fornecedor específico, proporcionando uma maior
personalização . Essa prática proporciona maior segurança, visto que o cliente tem acesso ao
código e pode saber como é realizado o acesso aos dados. (MENDONÇA, 2012).

17
A grande quantidade de interessados, em software livre ou de código aberto,
compõem a chamada comunidade de usuários e desenvolvedores de software livre. Quando
há algum problema, seja invasão por vírus ou qualquer outro bug, esta comunidade se une em
busca da solução. Muitas vezes, a solução é encontrada antes mesmo de a maioria dos
usuários terem tido o problema. (BERNARDO, 2012). Outro diferencial, no uso de software
livre ou de código aberto, é o fato de suas ferramentas estarem sempre sendo melhoradas,
tornando muito baixa a probabilidade de erros desconhecidos, o que aumenta a longevidade.
Os usuários de software livre/código aberto, esta comunidade é, neste caso, produtora e
consumidora do sistema e ela mesma busca assegurar a sua longevidade. (FERREIRA, 2005).
1.4 ESTRUTURA DO TRABALHO
Esta monografia está estruturada da seguinte forma:
• o capítulo 1 apresenta uma introdução a ALM, procurando demonstrar sua
aplicação e ideia geral do modelo, assim como os objetivos e justificativa
deste trabalho;
• o capítulo 2 evidencia os aspectos da ALM descrevendo cada passo e
subdivisões de cada etapa, e, sua relação com a engenharia de software;
• o capítulo 3 apresenta o método;
• no capítulo 4, são descritos os passos para implantação de ALM
utilizando pilha de ferramentas open source. Também há um
detalhamento das ferramentas;
• O capítulo 5 apresenta as conclusões indicando a motivação para
implantação de ALM nas empresas.

18
2 REVISÃO BIBLIOGRÁFICA
Este capítulo apresenta a revisão bibliográfica. Para Silva e Menezes (2005 p.37),
a revisão bibliográfica refere-se a fundamentação teórica adotada para tratar o tema e o
problema de pesquisa por meio da literatura publicada, criando assim a estrutura conceitual
que dará sustentação ao desenvolvimento da pesquisa. Desta forma será descrito neste
capítulo a teoria que fundamenta alguns dos aspectos da Engenharia de Software e suas
ferramentas. Em seguida é apresentada a fundamentação teórica relativa ao gerenciamento do
ciclo de vida das aplicações.
2.1 ENGENHARIA DE SOFTWARE
A engenharia de software é um ramo da engenharia focada no desenvolvimento
dentro de custos adequados, de sistemas de software. Esta é a disciplina que esta associada a
todos os aspectos envolvidos na produção de software, desde a etapa de especificação do
sistema até a sua fase de manutenção. O conceito de engenharia de software surgiu em 1968
em uma conferência para discutir a então chamada ‘crise de software’. Esta crise era resultado
direto da introdução de um novo hardware baseado em circuitos integrados. As aplicações de
computador, até então consideradas não realizáveis, passaram a ser vistas como propostas
viáveis. (SOMMERVILLE, 2007).
Na visão de (BAUER, 1969 apud KECHI, 2012, p. 7) “A engenharia de software
é o estabelecimento e uso de sólidos princípios de engenharia a fim de obter um software que
seja confiável e que funcione de forma econômica e eficiente em maquinas reais”. O autor
ainda afirma que os sistemas deveriam ser construídos em módulos, e em níveis.
Para Pressman (2011, p. 39), a engenharia de software é uma tecnologia em
camadas, como pode ser visto na figura 1. O autor afirma que: qualquer abordagem de
engenharia deve estar fundamentada em um comprometimento organizacional com a
qualidade.

19
Figura 1 – Fases da engenharia de software
Fonte: Pressman (2011, p. 39)
A camada “foco na qualidade” está presente em qualquer engenharia e, dá ênfase
a preocupação com a qualidade. Qualidade em engenharia de software está baseada nos
conceitos de gerenciamento da qualidade total para melhoria dos processos. Esta é uma
abordagem de gerenciamento organizacional para obter sucesso em longo prazo através da
satisfação dos clientes (BAUER, 1969 apud KECHI, 2012, p. 8).
2.1.1 Processo
Para a engenharia de software a camada de processos é a base. Nas palavras de
Pressman (2011, p. 39), o processo de engenharia de software é a liga que mantém as
camadas de tecnologia coesas e possibilita o desenvolvimento de software de forma racional e
dentro do prazo. Nesta camada se define a metodologia que deve ser estabelecida para a
entrega efetiva de tecnologia de engenharia de software. Sob o ponto de vista de Kechi (2012,
p. 8): “A camada de processos permite integrar as camadas de métodos e de ferramentas para
que se possa desenvolver um software nos prazos acordados e de maneira adequada. Um
processo permite que se planeje e se controle projetos de software”.
No entender de Pressman (2011, p. 40), uma metodologia de processo para a
engenharia de software compreende cinco atividades:
• comunicação: antes de qualquer trabalho é de vital importância a comunicação
entre o cliente e todos os interessados, visando compreender a intenção e levantar
as necessidades que ajudarão a definir as funções e características do software;

20
• planejamento: esta atividade cria um mapa, que guiará a jornada da equipe. O
mapa é chamado de ‘plano de projeto de software’ e define o trabalho
descrevendo as tarefas técnicas a serem conduzidas, os riscos, recursos
necessários, produtos resultantes e um cronograma de trabalho;
• modelagem: criação de modelos para melhor entender as necessidades do
software e o projeto que irá atender essas necessidades;
• construção: combinação de geração de código (manual ou automatizada) e
testes necessários para revelar erros na codificação;
• emprego: software como unidade completa ou como um incremento
parcialmente efetivado entregue ao cliente, que avalia o produto e fornece
feedback baseado na avaliação.
Essas cinco atividades podem ser utilizadas para desenvolvimento de programas
simples, bem como para grandes e complexos projetos. Os detalhes serão diferentes para cada
um dos casos, mas as atividades metodológicas serão as mesmas (PRESSMAN, 2011, p. 40).
2.1.2 Métodos
Esta camada, no entender de Pressman (2011, p. 40): fornece as informações
técnicas para o desenvolvimento de software, envolve ampla gama de tarefas, que incluem:
comunicação, análise de requisitos, modelagem de projeto, construção de programa, testes e
suporte. Para Kechi (2012, p. 12), métodos são importantes pois definem, por meio de suas
notações, um canal de comunicação uniforme entre os membros da equipe.
2.1.3 Ferramentas
As ferramentas de engenharia de software fornecem o suporte automatizado ou
semi-automatizado para o processo e para os métodos. Quando uma ferramenta usa as
informações geradas por outra, é estabelecido um sistema de suporte ao desenvolvimento de

21
software, denominado: engenharia de software com o auxilio de computador ou, do inglês,
Computer Aided Software Engineering, abreviado como CASE (PRESSMAN, 2011, p. 40).
2.2 FERRAMENTAS CASE
Como visto no fim da seção anterior, as ferramentas CASE, ou engenharia de
software com o auxilio de computador, é o nome que se dá ao sistema utilizado para apoiar
atividades de processo de software, entre as quais ferramentas para: engenharia de requisitos,
projeto, dicionário de dados, compiladores, depuradores, ferramentas de construção de
sistemas entre outros (SOMMERVILLE, 2004 p. 33).
Ainda no entendimento de Sommerville (2004, p. 53), o auxilio de computador na
engenharia de software apoia o processo, automatizando algumas atividades e fornecendo
informações sobre o software que está sendo desenvolvido.
A seguir algumas atividades que podem ser automatizadas utilizando CASE
(SOMMERVILLE, 2004, P.56):
• desenvolvimento de modelos gráficos de sistemas, como parte das
especificações de requisitos ou de projeto de software;
• dicionário de dados contendo informações sobre suas entidades e sua relação em
um projeto;
• geração de interface de usuário a partir de descrição gráfica da interface, que é
criada interativamente junto com o usuário;
• depuração de programas, pelo fornecimento de informações sobre um programa
em execução;
• tradução automatizada de programas a partir de uma antiga linguagem de
programação, como cobol, para uma versão mais recente.
No guia de engenharia de software (Software Engineering Body of Knowledge -
Swebok), as ferramentas são definidas de acordo com cada área de conhecimento:

22
a) ferramentas de requisitos de software são as ferramentas para lidar com os
requisitos de software e podem dividir-se em duas categorias: ferramentas para
modelagem e ferramentas para gerenciamento de requisitos. Ferramentas para
gerenciamento de requisitos suportam normalmente atividades como:
documentação, rastreamento e gerenciamento de mudanças (SWEBOK, 2014);
b) ferramentas de design de software de acordo com o Swebok (2014), são criadas
para apoiar a criação dos artefatos de projetos de software durante o processo de
desenvolvimento. Podem suportar as seguintes atividades: tradução do modelo de
requisitos em uma representação de design, fornecer apoio para a representação de
componentes funcionais e sua interface, fornecer diretrizes para avaliação de
qualidade;
c) ferramentas de teste de software apoiam o projeto de testes gerando casos de
testes e os tornando mais eficazes. São categorizadas de acordo com a suas
funcionalidades (SWEBOK, 2004);
d) ferramentas de construção de software são as que oferecem auxilio no
processo de construção de software. Como os exemplos a seguir, de acordo com o
Swebok (2004):
• ambiente de desenvolvimento, do inglês, Integrated Development
Environment (IDE), oferece auxilio na construção de software integrando
um conjunto de ferramentas de desenvolvimento. A escolha destes
ambientes pode afetar a eficiência na qualidade da construção do
software. As IDEs modernas apresentam recursos para: compilação,
detecção de erros, controle de código fonte, teste, depuração e suporte
para refatoração;1
• construtor de Interface gráfica: essa ferramenta fornece auxilio na criação
de interfaces de usuário, chamada em inglês de Graphical User Interface
(GUI). Ela inclui normalmente um editor visual com o qual é possível
criar formulários, janelas e gerenciadores de layout, clicando e arrastando
(drag and drop). Alguns destes construtores geram automaticamente o
1
De acordo com Fowler (1999), por refatoração entende-se o processo de mudança do código sem alteração do
comportamento do sistema, melhorando seu comportamento para minimizar a ocorrência de erros.

23
código fonte correspondente ao projeto GUI visual. Estas ferramentas
podem ser integradas a IDEs através de plug-ins.2
e) ferramentas de manutenção de software são as importantes para a manutenção
de software, como por exemplo, analisadores estáticos, que apresentam resumos
de conteúdo do programa, analisadores dinâmicos, permitem traçar o caminho de
execução de um programa, analisadores de dependência, permitem analisar e
compreender as inter-relações entre os componentes de um programa,
ferramentas de engenharia reversa, gerando artefatos como descrições e
especificações de projetos. Fundamenta o Swebok (2004);
f) ferramentas de gerenciamento de configuração de software. Contempla o
Swebok (2004) a este respeito que, essas ferramentas podem ser divididas em três
classes de acordo com seu escopo, sendo que podem oferecer, suporte individual,
de apoio relacionado com o projeto, e de apoio ao processo. As ferramentas de
apoio individual são suficientes para pequenas organizações ou grupos de
desenvolvimento, oferecem o suporte ao controle de versão, manipulação e
controle de mudanças. As de apoio relacionado com o projeto auxiliam na gestão
do espaço de trabalho para as equipes de desenvolvimento, são adequadas para
pequenas e médias organizações. As que fornecem o apoio ao processo podem
automatizar partes de um processo da empresa, criando suporte para o fluxo de
trabalho e gerenciando papeis e responsabilidades;
g) ferramentas de gerenciamento de engenharia de software: conforme o Swebok
(2004), essas ferramentas são muitas vezes utilizadas para dar visibilidade e
controle aos processos de gestão de engenharia de software. Podem ser
automatizadas ou manualmente implementadas. Ainda segundo o guia elas podem
ser divididas em categorias:
• ferramentas de planejamento e acompanhamento de projetos: podem ser
usadas para estimar esforço e custo do projeto, bem como preparar
2
Segundo Prada (2008), plug-in é todo o programa, ferramenta ou extensão que se encaixa a outro programa
principal para adicionar mais recursos ou funções a ele. Normalmente são leves, de fácil instalação e não
comprometem o funcionamento do programa principal.

24
cronogramas de projetos. Podem ser automatizadas, recebendo o tamanho
estimado e outras características de um produto de software, produzindo
uma estimativa de esforço, cronograma e custo. Ferramentas de
planejamento incluem também ferramentas automatizadas de
agendamento que verificam as tarefas, durações estimadas, relação de
precedência gerando gráfico de Gantt, ressalta o Swebok (2004);
• ferramentas de controle: utilizadas para rastrear os marcos do projeto,
reuniões de status do projeto, ciclos de iteração, demonstração de
produtos e itens de ação (SWEBOK, 2004);
• ferramentas de gestão de risco: Segundo o Swebok (2004), são as
ferramentas de controle e identificação de riscos, estimativa e
monitoramento. Incluem abordagens como árvores de decisão ou
simulação, para analisar o custo de acordo com os riscos;
• ferramentas de comunicação: podem incluir notificação de e-mail,
reuniões diárias de stand-up, gráficos mostrando progresso, entre outros
(SWEBOK, 2004);
• ferramentas de medição: citando o Swebok (2004): são as ferramentas
relacionadas com a medição do software, podendo ser automatizadas,
usadas para coletar, analisar e relatar os dados de medição do projeto.
Pode ser baseado em planilhas desenvolvidas por membros da equipe do
projeto ou empregados da organização.
h) ferramentas de processo de engenharia de software: segundo o guia Swebok
(2004), as ferramentas de processo são as que apoiam muitas das notações usadas
para: definir, implementar e gerenciar processos de software individuais, e
modelos de ciclo de vida do software. Incluem editores para anotações como:
diagrama de fluxo de dados, gráfico de estado, notação de modelagem de processo
de negócio, ou do inglês Business Process Modeling Notation (BPMN), redes de
Petri, e diagramas de atividades UML. As ferramentas de processo podem apoiar
projetos com equipes distribuídas geograficamente;
i) ferramentas de qualidade de software: essas ferramentas incluem ferramentas de
análise estática e dinâmica. Na estática é realizada uma análise sintática e

25
semântica sem executar o código fonte. As ferramentas de análise dinâmica são as
descritas nas outras áreas (SWEBOK, 2014).
As ferramentas CASE estão disponíveis para grande parte das atividades de rotina
no processo de software, o que melhora a qualidade e produtividade de software. Estas
ferramentas podem ser classificadas de acordo com o papel de apoio a cada atividade do
processo de software, mas existem diversas formas de classificar as ferramentas CASE. Cada
modo de categorização oferece uma perspectiva diferente.
Abaixo três perspectivas, segundo Sommerville, (2004, p. 54.):
• perspectiva funcional: as ferramentas são classificadas de acordo com sua
função especifica;
• perspectiva de processo: as ferramentas são classificadas de acordo com a
atividade de processo que elas apoiam;
• perspectiva de integração: as ferramentas CASE são classificadas de acordo
com a maneira como são organizadas em unidades integradas que fornecem apoio
a uma ou mais atividades de processo.
A figura 2 apresenta a classificação das ferramentas de acordo com sua função.
Nessa categorização não foram incluídas ferramentas especializadas, como as ferramentas de
apoio ao reuso.

26
Figura 2 – Classificação funcional das ferramentas CASE.
Fonte: SOMMERVILLE (2004, p. 55).
O apoio ao processo de software, proporcionado pela tecnologia CASE é outra
possível dimensão de classificação. Para Fuggetta (1993, apud SOMMERVILLE, 2004 p. 54)
os sistemas CASE devem ser classificados em três categorias:
1. ferramentas oferecem apoio as tarefas de processo individuais, verificação
da consistência de um projeto, a compilação de um programa, comparação
de resultados de testes entre outras. Ferramentas podem ser de uso geral,
uso restrito (processador de texto) ou agrupadas em workbenches;
2. workbenches apoiam fases ou atividades de processo, como a
especificação e o projeto, consiste em conjunto de ferramentas com menor
ou maior grau de integração;
3. ambientes oferecem apoio à todo, ou parte substancial do processo de
software. Incluem normalmente vários workbenches diferentes.
A seguir é apresentado, na figura 3, uma classificação das ferramentas de acordo
com as fases de processo. Por exemplo as ferramentas para planejamento e estimativa, edição
de textos, preparação de documentos e gerenciamento de configuração podem ser utilizadas
ao longo do processo de software, enquanto que ferramentas de reengenharia são usadas
somente na fase de implementação.

27
Figura 3 – Classificação de ferramentas CASE com base em atividades.
2.3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
As etapas envolvidas no desenvolvimento de software são muitas e envolvem uma
série de atividades. Não existe um método de desenvolvimento qualificado como ideal para
qualquer projeto. As organizações utilizam abordagens diferentes umas das outras, as vezes
dentro de uma mesma organização é adotado diferentes procedimentos para cada projeto
(SOMMERVILLE, 2004).
Na visão de Pressman (2010, p. 14), um processo de desenvolvimento software é
uma abordagem adaptável que tem como premissa a entrega de software em tempo e com
qualidade que satisfaça a necessidade. A estrutura de um processo identifica um grupo de
atividades fundamentais, presentes em todo o projeto de desenvolvimento de software. Esse
grupo de atividades é descrito a seguir.

28
2.3.1 Especificação de software
Aqui são estabelecidas quais funções são requeridas pelo sistema, bem como as
restrições desse sistema. Esta etapa é de grande importância pois os erros ocorridos aqui
podem ocasionar problemas nas fases seguintes. Esta atividade tem sido comumente chamada
de engenharia de requisitos (SOMMERVILLE, 2004, p. 46). Em concordância com Pressman
(2010 p. 120), a engenharia de requisitos é uma importante atividade da engenharia de
software, que começa durante a atividade de comunicação e se estende até a atividade de
modelagem.
O processo de engenharia de requisitos resulta em um documento de requisitos,
que é a documentação do sistema. Este documento possui dois níveis de detalhamento, um
para os clientes e usuários finais, com um detalhamento de mais alto nível, e outro com uma
especificação mais detalhada do sistema, para os desenvolvedores. Explica Sommerville
(2004, p. 46) .
Ainda de acordo com Sommerville (2004, p. 46) esta etapa de especificação de
software possui quatro fases principais, que são:
a) estudo de viabilidade: é verificado se as necessidades dos usuários podem ser
satisfeitas com a tecnologia atual. Bem como se é viável comercialmente e se é
possível ser desenvolvido com o orçamento disponível. Este estudo deve ser
rápido, barato e informar se a decisão é prosseguir com uma análise mais
detalhada;
b) levantamento e análise de requisitos: consiste na obtenção dos requisitos de
acordo com os sistemas existentes, conversa com usuários e possíveis
compradores (SOMMERVILLE, 2004, p. 46). Os interessados trabalham em
conjunto para identificar o problema, propor elementos para solução, negociar
abordagens diferentes e especificar o conjunto de requisitos da solução
(PRESSMAN, 2010, p. 128);
c) especificação de requisitos: é a formalização das informações coletadas durante
a fase de análise em um documento definindo um conjunto de requisitos. Aqui

29
podem ser gerados os dois tipos de documentos, um para o usuário final e outro
com as informações do sistema detalhadas (SOMMERVILLE, 2004, p. 46);
d) validação de requisitos: de acordo com Sommerville (2004, p. 46) esta
atividade verifica a pertinência, consistência e integridade dos requisitos. Nesta
etapa são encontrados erros na documentação, que devem ser corrigidos. Na
visão de Pressman (2010, p. 144) esta fase deve abordar questões como:
• O requisito é realmente necessário?
• Cada requisito está bem limitado?
• Não há ambiguidade? o requisito pode ser testado se implementado?
Essas e outras perguntas devem ser respondidas para garantir que o modelo de
requisitos é um reflexo preciso das necessidades das partes interessadas e que fornece uma
base sólida para o projeto.
Conforme Sommerville (2004, p. 47) essa atividade continua durante a definição e
especificação, novos requisitos vão surgindo ao longo do processo.
2.3.2 Projeto e implementação de software
Esse estágio consiste na conversão de uma especificação de sistema em um
sistema executável. Essa etapa envolve processos de projeto e programação de software
(SOMMERVILLE, 2004, p. 46). O processo pode envolver o desenvolvimento de vários
modelos do sistema em diferentes níveis de abstração.
Muitos projetos de software são desenvolvidos informalmente, e vão sendo
modificados a medida que a implementação ocorre, quando este estágio se completa o projeto
foi tão modificado que o documento original do projeto é uma descrição incoerente e
incompleta do sistema (SOMMERVILLE, 2004, p. 46). Uma abordagem mais metódica é
proposta por métodos estruturados, esses métodos envolvem a produção de modelos gráficos
resultando em grande quantidade de documentação de projeto, a criação de modelos deste tipo

30
recebem apoio de ferramentas CASE. Na compreensão de Sommerville (2004, p. 49) os
métodos estruturados podem suportar os seguintes modelos de um sistema:
• Modelo de fluxo de dados, onde o sistema é modelado utilizando
transformação de dados a medida que são processados;
• Modelo de relacionamento de entidades descrevendo as entidades básicas
do projeto e as relações entre elas. Essa é a técnica normal utilizada para
descrever estruturas de base de dados;
• Um modelo estrutural onde são documentados os componentes do sistema
e suas interações;
• Métodos orientados a objetos, que incluem um modelo de herança dos
sistemas, modelos de relacionamento estáticos e dinâmicos entre objetos e
um modelo de como os objetos interagem.
Os métodos são notações padronizadas e incorporações de boas praticas
(SOMMERVILLE, 2004, p. 49).
A partir dos métodos é realizado a implementação do sistema. A programação de
sistemas é uma atividade pessoal e normalmente os programadores tem liberdade de escolher
os componentes que desenvolverão primeiro. Alguns começam desenvolvendo os
componentes conhecidos primeiro, e então prosseguem com os componentes menos
compreendidos. Alguns programadores realizam testes de seus códigos, esses testes podem
revelar defeitos do programa, que devem ser removidos. Esse processo é chamado de
depuração, e consiste na identificação e correção de defeitos. Apos a realização do processo
de depuração os testes são executados novamente para garantir que as correções foram
realizadas corretamente (SOMMERVILLE, 2004, p. 49). A etapa de depuração pode ser
realizada com o auxilio de ferramentas, que mostram os valores intermediários das variáveis
do programa, ressalta Sommerville (2004, p.49).

31
2.3.3 Validação de software
De acordo com Sommerville (2004, p. 50), a validação de software destina-se a
mostrar que o sistema esta de acordo com as suas especificações e atende as expectativas do
cliente. Em cada estágio do processo é realizado inspeções, desde a definição de requisitos até
o desenvolvimento do programa. Os testes são realizados incrementalmente, em conjunto com
a implementação do sistema.
O processo de testes é composto por cinco estágios, no qual são testados os
componentes do sistema, o sistema integrado e o sistema com os dados do cliente.
A figura 4 apresenta esses cinco estágios.
Figura 4 – Os cinco estágios do processo de testes.
Os estágios do processo de teste são descritos a seguir, na compreensão de
Sommerville (2004, p. 51):
1) teste de unidade: os componentes são testados individualmente, para garantir
que eles operam corretamente;
2) teste de módulo: módulo é definido como um conjunto de componentes
dependentes, desta forma pode ser testado sem outros módulos do sistema;

32
3) teste de subsistema: teste de um conjunto de módulos integrados em um
subsistema;
4) teste de sistema: aqui é realizada a integração dos subsistemas para verificar a
ocorrência de erros ocasionados pela interação desses subsistemas, nesta etapa
também é verificado se o sistema cumpre os requisitos do sistema;
5) teste de aceitação: nesta fase é realizado o teste final do sistema, com dados
fornecidos pelo cliente. Aqui pode ser revelado erros e omissões na definição dos
requisitos do sistema, bem como, recursos que não atendem a necessidade do
usuário e desempenho inaceitável do sistema.
Os testes de unidade, também chamados de testes unitários, são realizados
normalmente pelo programador responsável pelo componente, já os estágios posteriores, são
realizados por um conjunto de programadores, com testes previamente elaborados.
Segundo Sommerville (2004, p. 52), os testes de aceitação podem ser
denominados:
• alpha: quando desenvolvido para um cliente, essa fase de teste acaba quando a
equipe de desenvolvimento e cliente concordam que o sistema é uma
implementação aceitável dos requisitos do sistema;
• beta: quando é desenvolvido para uma série de clientes. Esse tipo de teste
envolve a entrega do sistema a uma série de possíveis clientes, que reportam o
problema quando encontrado, expondo dessa forma o sistema ao uso real.
2.3.4 Evolução de software
Cada vez mais o software está sendo incorporado a sistema grandes e complexos,
e as modificações podem ser onerosas mas, ainda assim menos do que as modificações
correspondentes no sistema de hardware. O desenvolvimento de software é a atividade
criativa na qual um sistema de software é desenvolvido a partir de um conceito inicial até
chegar ao sistema em operação. A manutenção é o processo de modificação desse sistema.

33
Poucos sistemas atualmente são completamente novos, assim tem muito mais sentido
considerar desenvolvimento e manutenção como estágios integrados e contínuos. Por esse
motivo é mais realista pensar o processo de software como evolucionário, em que o software
é continuamente modificado, em resposta a requisitos em constante modificação
(SOMMERVILLE, 2004, p. 52).
2.4 GERENCIAMENTO DO CICLO DE VIDA DAS APLICAÇÕES
Organizações modernas necessitam de sistemas de software de várias formas, até
mesmo pequenas empresas dependem de software para auxiliar seus processos. O mundo
mudou rapidamente e as empresas agora precisam lidar com um ambiente global, que
apresenta oportunidades e desafios, precisam se readaptar constantemente. Para as industrias
de desenvolvimento de software não foi diferente. Muitas vezes as equipes de
desenvolvimento estão espalhadas pelo mundo, fazendo surgir problemas como: as questões
de colaboração, manutenção de código fonte, gerenciamento de requisitos entre outros. Desta
forma sem processos que auxiliem, que forneçam apoio ao desenvolvimento de software
moderno, as empresas tendem a sofrer.
O gerenciamento do ciclo de vida das aplicações, ou do inglês, ALM (Application
Lifecycle Management), é o processo que uma organização usa para cuidar de um aplicativo
ou sistema de software desde a sua concepção até a sua aposentadoria. ALM une os processos
de desenvolvimento e define os esforços necessários para coordenar o processo (ROSSBERG
e OLAUSSON, 2012, p. 3).
Para Carlos (2014) ALM é o processo que guia toda a vida útil de uma aplicação
desde a sua concepção, passando pela construção, operação e evolução. Na concepção de
Birmelle (2007), o gerenciamento do ciclo de vida acompanha tudo aquilo que faz parte do
ciclo de vida dos aplicativos, destacando seu início a partir de uma ideia, uma necessidade,
um desafio ou um risco. O fim deste ciclo de vida segundo o autor não se dá ao fim da fase
de desenvolvimento, e sim no momento em que a empresa abandona o uso desse aplicativo.
Ainda no entendimento de Birmelle (2007) ALM não deve ser confundido com
ciclo de desenvolvimento de software, do inglês, Software Development Lifecycle (SDLC),
que abrange aquilo que esta relacionando com o desenvolvimento de um aplicativo de

34
software, como: requisitos, arquitetura, codificação, testes, gerenciamento de projetos e
gerenciamento de configuração. Etapas estas descritas na seção anterior. Após o
desenvolvimento de software ser finalizado e de estar em operação, o aplicativo continua
sendo monitorado, segundo o processo de ALM.
2.4.1 Pilares da ALM
No entender de Condé (2009) ALM está estruturado em cima de pilares, que se
complementam, sendo que um deles são as pessoas. Em um processo de desenvolvimento de
software varias etapas são desenvolvidas por pessoas, executando funções especificas
(ROSSBERG e OLAUSSON, 2012 p. 21).
De acordo com Rossberg e Olausson (2012 p. 22) as funções da ALM são as
seguintes:
• gerente de negócios: faz a análise das necessidades do negócio, decide o inicio
de um projeto de desenvolvimento de um aplicativo ou sistema. O gerente de
negócios esta diretamente envolvido no processo de aprovação de um novo
projeto;
•gerente de projetos: é o responsável pelo produto;
• escritório de projetos: esta é a função ocupada pelos tomadores de decisão, estão
envolvidos também no planejamento. De acordo com Condé (2009) é o escritório
de projetos que gerencia o portfólio dos projetos da empresa, além de divulgar
padrões e guias de suporte;
• analista de negócios: é o responsável por analisar as necessidades e requisitos do
negócio. Ajuda a identificar problemas de negócio e propõe solução
(ROSSBERG e OLAUSSON, 2012 p. 22);
• arquiteto: para Rossberg e Olausson (2012 p. 22) o arquiteto é quem desenha a
imagem inicial da solução, o projeto do sistema. As questões atribuídas a esta
função podem ser: escalabilidade, substituição de hardware, novas interfaces de
usuário, entre outras;

35
• experiência do usuário, ou do inglês User eXperience (UX), equipe de projeto:
de acordo com Rossberg e Olausson (2012 p. 22) esta função deve ser de
colaboração com a equipe de desenvolvimento durante todo o projeto. Pode ser
ocupada por apenas uma pessoa. De acordo com Unger e Chandler (2009 p. 3)
UX trata da criação e sincronização dos elementos que afetam a experiência dos
usuários, com a intenção de influenciar seu comportamento e percepção;
• administradores de banco de dados (DBAs): praticamente todos os sistemas de
negócio ou aplicativos utilizam algum tipo de banco de dados. É essencial os
conhecimentos de um DBA para um performático e correto funcionamento do
banco de dados (ROSSBERG e OLAUSSON, 2012 p. 22). Sob o ponto de vista
de Condé (2009) a função do DBA é dar suporte para a equipe na montagem do
banco de dados;
• desenvolvedores: citando Rossberg e Olausson (2012 p. 23) são as pessoas que
desenvolvem o sistema a partir do modelo e desenho da arquitetura. São eles
também que alteram o código quando mudanças são solicitadas;
• testador: na compreensão de Condé (2009) o objetivo do testador é verificar a
existência de problemas na aplicação e reporta-los para que seja feita a correção.
Este profissional deve realizar testes pré-definidos coletando amostras dos
resultados e comparando com a saída esperada. O teste deve ser realizado a partir
da codificação dos primeiros requisitos e continuar sendo feito durante todo o
processo, argumentam Rossberg e Olausson (2012 p. 23);
• operações e manutenção: quando um sistema ou aplicativo está concluído ele é
entregue para a equipe de operação e manutenção. Essa equipe cuida do sistema
até que deixe de ser usado. Este papel é um passo importante de ALM
(ROSSBERG e OLAUSSON, 2012, p. 23).
Os processos são descritos por Condé (2009) como outro pilar e caracterizam-se
pelo conjunto das boas práticas, artefatos, guias e manuais relacionados com a construção e
manutenção de uma aplicação. Os processos abrangem todos aspectos desde o levantamento
das necessidades, passando pelo desenvolvimento (SDLC), e o monitoramento das aplicações
já em ambiente operacional.
O ultimo pilar no entendimento de Condé (2009) são as ferramentas, que
automatizam e facilitam a condução dos processos. Para Rossberg e Olausson (2012 p. 28) as
ferramentas podem automatizar grande parte do processo de ALM.

36
2.4.2 Disciplinas ALM
As disciplinas permitem identificar as entradas e os resultados esperados em cada
fase da ALM, assim como os envolvidos em cada fase Condé (2009).
2.4.2.1 Gerenciamento de Requisitos (Requeriments Management)
Os requisitos representam as funcionalidades que o sistema deve executar. Dentro
dessa etapa existem as seguintes fases (CONDÉ, 2009):
• documentar requisitos funcionais e não funcionais;
• identificar se os requisitos estão de acordo com as necessidades do
negócio;
• priorizar os requisitos;
• selecionar os requisitos que serão implementados de acordo com cada
fase;
• identificar a dependência entre os requisitos;
• verificar se os requisitos foram atendidos.
Esta etapa é crucial para o sucesso do projeto, ressalta Condé (2009).
2.4.2.2 Gerenciamento de configuração de software (Software configuration Management)
Esta etapa, segundo Conde (2009), envolve a geração de diversos artefatos, como:
código-fonte, documentos, planilhas e apresentações. A disciplina é responsável por
gerenciar, gerar a rastreabilidade e versionamento dos artefatos.
De acordo com Condé (2009), algumas ações dessa disciplina são as seguintes:
• controlar acesso aos artefatos;

37
• armazenar as versões de cada artefato;
• rastrear modificações de cada versão;
• comparar versões;
• restaurar versões específicas dos artefatos de acordo com uma versão
especifica da aplicação.
Esta é, segundo Condé (2009), possivelmente a disciplina mais utilizada nas
organizações, pois possui apoio de diversas ferramentas disponíveis no mercado.
2.4.2.3 Montagem e integração (build and integration)
Os projetos atuais são compostos de vários módulos. A disciplina de montagem e
integração é a responsável por integrar todos os componentes em um único pacote (CONDÉ,
2009).
A seguir estão relacionadas algumas ações da disciplina de montagem e
integração, segundo Condé (2009):
• recuperar todos os artefatos do repositório de código-fonte;
• mapear os artefatos com a nova versão da aplicação;
• compilar o código-fonte;
• criar pacote de instalação para ser testado;
• organizar código compilado conforme layout definido.
O processo de montagem e integração é a tarefa que integra diversas partes
garantindo que todas elas estejam estáveis.

38
2.4.2.4 Gerenciamento de Defeitos (Defect Management)
Na concepção de Condé (2009), essa disciplina é a responsável por coletar os
defeitos e tratar como eles serão corrigidos, bem como, identificar de onde o erro surgiu para
tentar evitar uma nova ocorrência.
Algumas ações da disciplina de gerenciamento de defeitos podem ser observadas
abaixo, no entender de Condé (2009):
• descrever o comportamento esperado;
• descrever o comportamento ocorrido;
• descrever os passos necessário 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.
2.4.2.5 Teste unitário, Integrado e de Regressão (Unit test, Integrated and Regression)
O teste unitário é aquele realizado sobre apenas um componente, pode ser uma
classe ou um método. Esse teste é caracterizado por um programa que testa se a saída gerada
está de acordo com o esperado a partir de um conjunto de valores de entrada. Os testes
integrados são normalmente realizados sobre módulos e essa é uma tarefa realizada
normalmente pelos programadores. Nos testes de regressão são verificados se as alterações
introduzidas a cada build não geraram novos defeitos, fundamenta Condé (2009). Ainda
segundo o autor a vantagem de se aplicar esse teste é a garantia de que o software esta em
conformidade com os requisitos definidos.
Sob o ponto de vista de Luciano Condé (2009), são descritos a seguir algumas
ações:
• criação de teste unitário para cada componente;
• criação de testes integrados, em nível de módulos lógicos e casos de uso;
• armazenagem dos testes em repositório, pois também são considerados
artefatos;

39
• utilização de ferramentas para automatizar a geração de logs de erros.
Os testes unitários têm sido muito utilizados nos últimos tempos devido a sua
eficiência.
2.4.2.6 Análise de Código (code analysis)
Esta disciplina de ALM, é a responsável por analisar se o código esta de acordo
com os padrões da empresa (CONDÉ 2009).
Algumas das ações realizadas por essa disciplina, de acordo com Condé (2009):
• validar formato e estilo da codificação;
• garantir o uso de padrões de projeto;
• detectar problemas de desempenho;
• detectar vulnerabilidades conforme as politicas de segurança;
• identificar a compatibilidade da aplicação em conformidade com normas
de mercado.
2.4.2.7 Teste de Sistema (System test)
Essa disciplina envolve o teste da aplicação quando ela estiver pronta. Os testes
funcionais “caixa preta”, são executados por essa disciplina. Aqui verifica-se se a aplicação
esta de acordo com os requisitos. Esses testes são facilitados quando as etapas anteriores são
executadas corretamente, defende Condé (2009).
Para essa disciplina são descritas algumas ações:
• detectar problemas de desempenho;
• detectar se os requisitos estão presentes na aplicação.

40
2.4.2.8 Relatórios de Acompanhamento (Status Report)
É nessa disciplina que se gera os diversos relatórios referentes ao ciclo de vida da
aplicação. Como exemplo: relatório de bugs, uso de recursos de infra estrutura de TI, retorno
sobre investimento, relatórios referentes a qualidade de software entre outros.

41
3 MÉTODO DE PESQUISA
Neste capítulo será abordado o método de pesquisa utilizado neste trabalho. Para
Jung (2011) o método consiste no conjunto de etapas, que quando executadas de forma
sistemática, facilitam a obtenção de conhecimentos sobre fenômenos físicos, químicos ou
biológicos, ou o desenvolvimento de novos produtos ou processos.
O capítulo destaca aspectos como a caracterização do tipo da pesquisa, etapas
metodológicas, e as delimitações. De acordo com Silva e Menezes (2005 p.32) nesta etapa se
define onde e como será realizada a pesquisa, definindo: tipo de pesquisa, população
(universo da pesquisa), amostragem, instrumentos de coleta de dados e a forma de analisar os
dados.
3.1 CARACTERIZAÇÃO DO TIPO DA PESQUISA
Conforme Silva e Menezes (2005 p.20), uma pesquisa consiste no conjunto de
ações realizadas para encontrar a solução para um problema, seguindo procedimentos
racionais e sistemáticos. Ainda de acordo com os autores uma pesquisa é realizada quando se
tem um problema e não se tem informações para solucioná-lo.
As pesquisas podem ser classificadas de diversas formas. Abaixo são apresentadas
as formas clássicas de classificação segundo Silva e Menezes (2005 p.20):
Pela natureza a pesquisa pode ser básica, quando tem por objetivo gerar novos
conhecimentos sem aplicação prevista, envolve verdades e interesses universais. Ou aplicada,
quando o conhecimento gerado dirige-se a solução de problemas específicos, envolvendo
verdades e interesses locais.
Da forma de abordagem do problema a pesquisa pode ser classificada como
quantitativa quando considera tudo que pode ser quantificável, traduzindo em números
opiniões e informações para classifica-las, envolve o uso de técnicas e recursos estatísticos.
Ou qualitativa, sem uso de métodos e técnicas estatísticas. Aqui o ambiente natural é a fonte
de coleta de dados, e os pesquisadores analisam os dados indutivamente, atribuindo
significado.

42
A classificação do ponto de vista de seus objetivos pode ser classificada de três
formas (GIL 1991, apud SILVA e MENEZES 2005 p.21):
• pesquisa exploratória: envolve levantamento bibliográfico, entrevistas com
pessoas que tiveram experiências práticas com o problema pesquisado, e análise
de exemplos que estimulem a compreensão. Em geral, pesquisas bibliográficas e
estudos de caso;
• pesquisa descritiva: descreve as características de determinada população ou
fenômeno ou o estabelecimento de relações entre as variáveis. Utiliza técnicas de
coletas de dados, como questionário e observação sistemática, assumindo em
geral a forma de levantamento;
• pesquisa explicativa: visa identificar os fatores que determinam ou contribuem
para a ocorrência dos fenômenos. Utiliza, quando realizada nas ciências naturais,
o método experimental e nas ciências sociais o método observacional.
Dos procedimentos técnicos podem ter as seguintes classificações segundo (GIL
1991, apud SILVA e MENEZES 2005 p.21):
• pesquisa bibliográfica: quando sua elaboração é realizada a partir de livros,
artigos ou periódicos encontrados na internet;
• pesquisa documental: realizada a partir de materiais que não sofreram
tratamento analítico;
• pesquisa experimental: aqui é determinado um objeto de estudo, seleciona-se as
variáveis capazes de influencia-lo e define-se a forma de controle e observação
dos efeitos que a variável produz no objeto;
• levantamento: quando envolve a interrogação direta das pessoas cujo
comportamento deseja-se conhecer;
• estudo de caso: envolve o profundo estudo de um ou mais objetos de modo que
se permita o seu amplo conhecimento;
• pesquisa expost-facto: o experimento se realiza depois dos fatos;
• pesquisa-ação: concebida e realizada com uma ação ou com a resolução de um
problema coletivo. Os pesquisadores e participantes da situação ou problema
estão envolvidos de modo cooperativo ou participativo;

43
• pesquisa participante: desenvolvida a partir da interação entre pesquisadores e
membros das situações investigadas.
No que se refere ao presente trabalho, ele se qualifica como uma pesquisa, pois
busca respostas para os problemas existentes no processo e gerenciamento do
desenvolvimento de software, bem como todo o ciclo de vida da aplicação.
A pesquisa esta classificada, pela natureza, como uma pesquisa aplicada, pois seu
conhecimento pretende solucionar um problema específico. Do ponto de vista da abordagem
do problema, ela se classifica como qualitativa, visto que não utiliza métodos estatísticos e
seus dados são analisados indutivamente. Na observação dos objetivos ela está classificada
como uma pesquisa exploratória, envolvendo levantamento bibliográfico. Quanto aos
procedimentos técnicos classifica-se como bibliográfica, já que sua elaboração é realizada a
partir de livros, artigos e periódicos encontrados na internet. A classificação da pesquisa
realizada neste trabalho é apresentada resumidamente no quadro a seguir.
Quadro 1 – Resumo da classificação da pesquisa.
Classificação da Pesquisa Categoria
Do ponto de vista da natureza Pesquisa aplicada
Da abordagem do problema Qualitativa
Dos objetivos Exploratória
Dos procedimentos técnicos Bibliográfica
Fonte: Elaboração do autor, 2014.
3.2 ETAPAS METODOLÓGICAS
A figura 5 apresenta o fluxograma das etapas metodológicas do presente trabalho,
que visam solucionar o problema proposto:

44
Figura 5 – Etapas metodológicas.
Fonte: Elaboração do autor, 2014.
A seguir são descritas cada uma das etapas:
a) revisão bibliográfica: é apresentado inicialmente o conceito de engenharia
de software, sua definição, e fases que a compõem. Após é realizado

45
através da literatura existente, a fundamentação teórica relativa às
ferramentas de apoio à engenharia de software, bem como a descrição das
etapas do processo de desenvolvimento de software. Por fim é apresentado
o conceito de gerenciamento do ciclo de vida de aplicações, os papéis e as
disciplinas envolvidas;
b) pesquisa das ferramentas que auxiliam as diferentes etapas do
gerenciamento do ciclo de vida;
c) selecionar, a partir da experiência e revisão bibliográfica, as atividades do
ciclo de desenvolvimento das aplicações que possuem ferramentas para
auxiliar o processo de ALM;
d) no “desenvolvimento da solução” é selecionado uma série de ferramentas
open source que auxiliam o processo de gerenciamento do ciclo de vida do
desenvolvimento de sistemas, realizando o detalhamento de cada
ferramenta, apontando os benefícios do seu uso e descrevendo a possível
integração dessas ferramentas conformando uma plataforma tecnológica;
e) validação: nesta etapa será pesquisada a possível eficácia da plataforma
proposta, através de entrevista com profissional da área. Caso seja
necessário se voltará a algumas das etapas anteriores;
f) nas conclusões é explicitado os resultados alcançados com a adoção do
gerenciamento de ciclo de vida das aplicações, demonstrando as vantagens
obtidas, bem como a motivação para utilização.
3.3 DELIMITAÇÕES
Nesta seção são definidas as delimitações do trabalho:
a) não será incluído no trabalho a análise, nem especificação, de ferramentas
de auxilio ao gerenciamento do ciclo de vida das aplicações de uso
proprietário. Somente serão consideradas ferramentas open source;

46
b) modelos de desenvolvimento ágil, por vezes presentes no gerenciamento
do ciclo de vida das aplicações, não serão descritos;
c) não será realizado o desenvolvimento de nenhum sistema, somente a
descrição das ferramentas, com imagem das interfaces da ferramenta.

47
4 FERRAMENTAS PARA O GERENCIAMENTO DO CICLO DE VIDA DAS
APLICAÇÕES
Este capítulo apresenta as atividades presentes no processo de ALM, bem como
os passos e ferramentas para sua utilização.
O gerenciamento do ciclo de vida das aplicações é realizado com o auxilio de
ferramentas sendo que cada ferramenta atua em uma ou mais áreas de ALM.
4.1 PESQUISA DAS FERRAMENTAS DE ALM
O processo de desenvolvimento de sistemas é uma atividade bastante complexa.
Grande parte dos projetos conta com uma equipe grande e diversificada de pessoas, que pode
incluir: desenvolvedores, designers gráficos, analistas de negócios, especialistas em
qualidade, entre outros. Estes profissionais devem trabalhar de forma harmoniosa em
conjunto. A utilização de diferentes ferramentas pode aumentar a complexidade, embora elas
sejam geralmente idealizadas para apoiar o processo e aumentar a qualidade e produtividade.
Desenvolvedores usam vários ambientes de desenvolvimento integrado (IDEs), os designers
escolhem suas ferramentas gráficas favoritas, e os analistas de negócios geralmente sentem-se
mais a vontade com planilhas. Projetos diferentes adotam comumente soluções diferentes para
controle de versão, gerenciamento de testes, entre outros. A diversidade nas ferramentas é
inevitável na maioria das organizações. Esta diversidade faz sentido. Pessoas em diferentes
papéis certamente precisam de diferentes ferramentas, não faria sentido um analista de
negócios utilizar uma IDE para realizar sua tarefa. Mesmo pessoas na mesma função podem
fazer escolhas diferentes. Para um desenvolvedor construindo um aplicativo Java
provavelmente não seria interessante utilizar o Visual Studio IDE (plataforma da Microsoft
para .Net), bem como, a escolha de uma IDE como Eclipse não seria apropriada para um
aplicativo .NET (CHAPPELL, 2011). As soluções open source em ALM são constituídas de
uma série de produtos de diversas comunidades ou empresas, sendo que, cada uma das
ferramentas atende uma necessidade específica no processo de ALM. (GILBERTO JUNIOR,
2012).

48
Para este trabalho as ferramentas são distribuídas de acordo com as seguintes
fases:
a) concepção inicial;
b) desenvolvimento;
c) qualidade;
d) produção.
No caso das ferramentas de testes unitários elas são dependentes da linguagem de
programação utilizada. Para exemplificar definiu-se a linguagem Java como sendo a
linguagem que seria utilizada na codificação.
A pesquisa inicial para esta monografia encontrou um conjunto de ferramentas
que oferecem auxilio no processo de ALM nas etapas que se pretende abordar. A seguir pode
ser observado o conjunto encontrado de acordo com cada fase:
• gerenciamento de requisitos: Mantis, BitBucket, Bugzilla, Redmine;
• controle de versões/repositório de código fonte: CVS, Git, Bazaar,
Subversion;
• gerenciamento de dependências e buids: Maven;
• integração contínua: Jenkins, Bamboo;
• testes: JUnit(unitários), Selenium(interface), Jmeter(carga).
Dentre o conjunto inicial de ferramentas encontrado na pesquisa, as ferramentas
foram escolhidas levando em consideração a capacidade de trabalharem juntas conformando
uma plataforma de ALM. Foi relevante também para essa escolha os conhecimentos do autor
e a sua familiarização com as ferramentas. A seguir são apresentadas as ferramentas
escolhidas:
• Redmine: é uma ferramenta web para gerenciamento de projetos que foi desenvolvida
utilizando o framework Ruby on Rails. Esta é uma ferramenta open source. Algumas
de suas características são: suporte a vários projetos, controle de acesso, gráfico de
gantt, wiki e calendário, suporte a vários bancos de dados e idiomas, entre outros;
• Subversion: é um sistema de controle de versão de código aberto. O Subversion
gerencia as alterações feitas ao longo do tempo em arquivos e diretórios. As equipes

49
de desenvolvedores usam esta ferramenta para acompanhar a evolução do seu código
fonte;
• Maven: ferramenta de integração de projetos que auxilia o gerenciamento de
dependências e automação de compilação. Esta ferramenta permite isolar as
bibliotecas em um repositório compartilhado pela equipe, ou por toda a internet no
caso do repositório central do Maven. As versões das dependências ficam
centralizadas em arquivos de configuração dos projetos chamados POM;
• Jenkins: ferramenta que fornece o suporte a integração continua. Essa ferramenta
trabalha como um agendador de tarefas para construção de software.
• JUnit: é uma ferramenta para testes unitários quando programando na linguagem
Java, muito importante para o desenvolvimento orientado a testes. O JUnit promove a
ideia de testar antes de codificar, testa-se uma parte de código e em seguida é realizada
a implementação, esta prática aumenta a produtividade do programador e a
escalabilidade, diminuindo o desgaste com o processo de depuração;
• Eclipse: é uma ferramenta de desenvolvimento com suporte à varias linguagens, entre
as quais: C/C++, PHP, Python, Scala. Ela foi desenvolvida na linguagem Java e hoje é
uma das IDEs mais utilizadas. Nesta monografia a ferramenta não será detalhada
separadamente, mais sim em conjunto com outras presentes no trabalho.
4.2 DESCRIÇÃO DAS FERRAMENTAS
A seguir cada uma das ferramentas escolhidas será descrita com maiores detalhes.
4.2.1 Gerenciamento de requisitos com Redmine
Esta ferramenta é a que trata do gerenciamento dos requisitos. Ela permite o
suporte a gestão de pendências, gerenciamento das horas gastas, a integração com um
repositório de código fonte, fornece gráfico de gantt, fórum, wiki, entre outros. O Redmine
apresenta entidades, sendo que as principais são apresentadas a seguir:

50
- projetos: representa a entidade principal;
- subprojetos: módulos de um projeto maior;
- requisitos: requisitos, bugs ou pendências do projeto;
- versões: representa o conjunto de requisitos desejados.
Outras entidades utilitárias são: membros, papeis e permissões, tipos de requisitos
e categoria de requisitos. No Redmine os membros são adicionados e posteriormente podem
ser relacionados a projetos e papéis e grupos. Grupos são constituídos de um conjunto de
usuários que possuem o mesmo papel em determinado projeto. Os papéis estão relacionados
com a função exercida no projeto, sendo que as permissões são atribuídas a eles, não é
possível atribuir permissões a um usuário diretamente.
Iniciando o Redmine, no menu Administração, é possível cadastrar os usuários. Através deste
cadastro podem ser inseridos todos os membros da organização envolvidos com os projetos,
visto que só depois eles serão associados a papéis e projetos.
A seguir são apresentadas as telas de cadastro e listagem de usuários. Esta ultima
interface apresenta um conjunto de membros fictícios.
Figura 6 – Interface novo usuário.
Fonte: O autor, 2014.

51
Figura 7 – Interface de usuários.
Na tela com os usuários cadastrados é possível observar à direita o menu de
administração. Lá podem ser criados grupos e pode-se associar membros a cada grupo. Neste
menu também se definem os papéis e permissões. Ao criar um novo papel se atribuem as
permissões, o Redmine oferece automaticamente alguns perfis, outros podem ser criados,
como demonstrado na interface a seguir:
Figura 8 – Interface de criação de novo papel.
Para adicionar um novo projeto seleciona-se na barra superior a opção projetos. A
seguir é exibido a página com os projetos cadastrados, como pode ser visto na imagem a
seguir:

52
Figura 9 – Interface de projetos.
Nesta tela é possível visualizar um projeto fictício denominado ”Sistema
Locadora de Veículos”, com dois subprojetos, “Locadora de veículos-modelo” e “Locadora
de veículos-web”. Selecionando o campo novo projeto, localizado na parte superior à direita,
é possível criar um novo projeto.
Figura 10 – Interface para criação de projeto.
Aqui são inseridos os dados, sendo que, aqueles destacados com asterisco
vermelho são obrigatórios, como por exemplo o nome e o identificador. Mais abaixo é
possível incluir os módulos desejados para o projeto. Cada módulo permite um conjunto de
ações.
Após a criação do projeto, são inseridas as tarefas, os requisitos do projeto. A descrição pode
ser acomodada de acordo com a metodologia empregada. Clicando no campo nova tarefa a
seguinte interface é exibida:

53
Figura 11 – Interface para criação de tarefa.
Na imagem seguinte é possível visualizar a tela com requisitos fictícios criados:
Figura 12 – Interface de tarefas do projeto.
Com a criação das tarefas, inserindo corretamente data de início e fim, o gráfico
de Gantt pode ser visualizado.

54
Figura 13 – Gráfico de Gantt.
As tarefas podem ser atualizadas, informando por exemplo de forma percentual
quanto do requisito já foi contemplado, bem como as horas gastas. O acompanhamento é feito
através de relatório apresentado, como pode ser visto a seguir:
Figura 14 – Interface de relatório de tempo gasto.
As tarefas podem ter relacionamentos. Os relacionamentos podem ser de bloqueio,
precedência e duplicidade, elas podem estar em projetos diferentes.

55
4.2.2 Controle de versões com Subversion
O controle de versões permite alterações e, revisões feitas por múltiplas pessoas.
Cria-se um repositório de código de fonte onde o código é armazenado e, a cada revisão,
atribui-se uma versão. Os sistemas de controle de versão possuem em sua maioria dois
métodos principais, o primeiro chama-se: lock-modify-unlock. Neste método o arquivo é
bloqueado, travado, permitindo sua alteração por apenas uma pessoa por vez, outro usuário
pode até fazer uma leitura mas realizar alterações, só após o primeiro destravar o arquivo.
Desta forma esta técnica apresenta desvantagens, um usuário pode esquecer-se de destravar o
arquivo, impedindo assim que outra pessoa possa trabalhar no mesmo. Outra desvantagem é o
tempo, já que só permite que uma pessoa trabalhe por vez. O outro método é denominado:
copy-modify-merge, este permite que mais de uma pessoa trabalhe em um mesmo arquivo ao
mesmo tempo. Após as alterações é feito um merge, uma mescla das alterações realizadas
pelos usuários.
O Subversion é um repositório cliente servidor não distribuído. Nesta ferramenta
o código é armazenado em um servidor. Grande parte dos projetos utilizam protocolo HTTP
ou HTTPS, mas os dados podem ser disponibilizados via outros protocolos também, como
svn, para os protocolos proprietários. O Subversion necessita de um servidor web, visto que
sua instalação não acompanha o produto. Após a instalação, realizada via terminal, o próximo
passo é a criação do repositório. A seguir um exemplo da criação de repositório:
- mkdir <caminho e nome do repositório>;
- cd <caminho e nome do repositório>;
- svnadmin create public;
- svnadmin create private.
Dentro de cada repositório criado, neste exemplo public e private, existe agora os arquivos
que podem ser visualizados na imagem a seguir, que foram criados após realizar o comando
create:

56
Figura 15 – Pastas criadas nos diretórios.
Para que estes repositórios estejam disponíveis via HTTP, é preciso configurar o
servidor, neste exemplo o Apache. O arquivo a ser editado se encontra no diretório: mods-
enabled. Este arquivo deve ser alterado substituindo a palavra svn por subversion. Após
reiniciar o Apache cria-se um projeto local e, dentro deste projeto, três diretórios: trunk,
branches e tags. Por fim deve-se importar o projeto passando a url, neste exemplo: svn import
tcc http://localhost/subversion/public/tcc -m “uma mensagem aqui, boa prática”. Agora o
repositório esta disponível para ser acessado via navegador, como pode ser visto a seguir:
Figura 16 – Tela projeto Subversion.
Na imagem a seguir é possível observar um arquivo com extensão txt criado de
forma genérica, sendo que o Subversion já adiciona como revisão um, (Revision 1).

57
Figura 17 – Tela Subversion, arquivo criado.
Para trabalhar neste projeto, é preciso realizar um checkout, que é a copia do
projeto. No exemplo foi criado um novo arquivo, chamado novo.txt. Para que esse arquivo
seja versionado é preciso realizar o comando: svn add novo.txt e após realizar um commit
com o comando: svn commit –m”uma mensagem aqui, boa prática”. Na figura 18 é possível
observar o novo arquivo, bem como a revisão que passou para 2.
Figura 18 – Tela Subversion novo arquivo.

58
A estrutura de diretórios segue padrão convencionado com a criação de três
pastas: trunk, branch e tag. Na pasta trunk são adicionados os arquivos de código em
desenvolvimento do projeto, as atualizações do dia a dia são feitas nesta pasta. No diretório
branch são incluídos linhas independentes de desenvolvimento do projeto, normalmente é
utilizado para corrigir bugs ou testar uma nova tecnologia e depois são devolvidas ao trunk.
As tags são versões liberadas do projeto o podem ser geradas diretamente do trunk ou do
branch.
O Subversion pode ser integrado a outras ferramentas, como as IDE`s (Eclipse e
Netbeans), bem como as ferramentas de projetos/requisitos como o Redmine. Para utilização
da ferramenta integrada ao Eclipse é necessário a instalação de plugin. No caso do Netbeans
não se faz necessário essa instalação pois ele já possui suporte nativo ao Subversion.
Com a instalação do plugin Subclipse o Eclipse está pronto para ser usado com o
Subversion. Abrindo a ferramenta e buscando a aba window, show view, svn, svn repositories
deve ser inserido a url do Subversion, como pode ser visto na imagem a seguir:
Figura 19 – Interface Eclipse, integrando com Subversion.
A seguir é possível visualizar no canto direito o projeto criado no Subversion anteriormente.

59
Figura 20 – Interface Eclipse com projeto Subversion
O ambiente Eclipse torna-se uma opção mais amigável de interação com o
Subversion. Tudo aquilo que foi feito por linha de comando pode ser executado aqui por meio
da interface do Eclipse. Os projetos podem ser trazidos do Subversion para o Eclipse, ou do
Eclipse enviados para o Subversion.
No Redmine a integração deve ser realizada projeto a projeto. Acessando a
ferramenta, na aba configurações, repositório, deve se escolher o repositório desejado, para
este exemplo Subversion, passando a url, como pode ser visto a seguir:
Figura 21 – Integração Redmine com Subversion.

60
Navegando pelo projeto e acessando a aba repositório dentro do projeto, é
possível visualizar os arquivos que foram criados no Subversion.
Figura 22 – Arquivos integrados.
4.2.3 Gerenciamento de dependências e builds com Maven
Maven é uma ferramenta utilizada no gerenciamento de dependências e builds do
projeto. Pode ser utilizada em linguagens como: C#, Scala, Ruby, Java, entre outras. Sua
instalação é bastante simples, basta fazer o download no formato .zip e descompacta-lo.
Sendo que para ser utilizado via terminal é necessário configurar as variáveis de ambiente. É
possível verificar a instalação do Maven com o comando: mvn –version. Esta ferramenta
possui um arquivo de configuração chamado pom.xml (Project Object Model), que fica na
raiz do projeto, é nele que se declara a estrutura, dependências e as características do projeto.
A seguir é possível observar a estrutura básica de um arquivo pom.xml:
Figura 23 – Arquivo pom.

61
Nesse arquivo xml observa-se os seguintes elementos:
- groupId: identificador da empresa, instituição, normalmente o domínio ao contrário,
no exemplo foi utilizado o domínio ao contrário da Unisul (www.unisul.br);
- artifactId: identificador único do projeto na empresa ou instituição;
- version: a versão do projeto;
- packaging: tipo de empacotamento (jar, war, ejb...).
As funcionalidades do Maven podem ser estendidas utilizando plug-ins. Outra
possibilidade da ferramenta é a geração de arquétipos (archetype), que é uma espécie de
template, podendo ser utilizado em outros projetos.
Para se criar um novo projeto Maven via terminal, deve-se criar um novo
diretório, e estando dentro desse diretório realizar o comando: mvn archetype:generate. Na
imagem a seguir é possível visualizar uma série de arquétipos já existentes, nessa imagem
1160 arquétipos.
Figura 24 – Arquétipos disponíveis.
Neste exemplo será utilizado um arquétipo de projeto Java simples, para isso pode
ser utilizado um filtro, digitando a palavra quickstart onde parou o cursor. Será exibido uma

62
série de versões, para esse exemplo foi escolhido a ultima versão, 1.1. Será solicitado que
informe os elementos: groupId, artifactId, gerando automaticamente uma versão e sugerindo
um pacote, de acordo com o groupId, como pode ser visto na imagem a seguir:
Figura 25 – Configuração projeto Maven.
Acessando o diretório verifica-se que foi criado um novo projeto Java com alguns
sub-diretórios (src/main, src/test), bem como o arquivo pom, que pode ser visto a seguir:

63
Figura 26 – Arquivos pom gerado.
Verificando o arquivo gerado observa-se que o arquétipo escolhido já possui as
dependências do JUnit, não necessitando fazer download de nenhum elemento adicional
separadamente. Quando for iniciado ele fará o download das dependências declaradas no
pom. O download é feito à partir de um repositório publico na web chamado repositório
central do Maven, e adicionado a um repositório local na maquina, nas pasta do usuário,
chamado .m2. Se a mesma dependência for requerida em um outro projeto, a busca será feita
neste repositório local. Para que o download seja realizado de um repositório específico, é
preciso fazer a declaração no arquivo pom. No exemplo foi adicionado também a tag scope,
que informa em que fase o artefato será utilizado, neste caso na fase de teste.
Esta ferramenta possui um ciclo de vida, por vezes também chamado ciclo de
build, neste ciclo uma série de etapas são realizadas. Na imagem a seguir é possível visualizar
o ciclo de vida padrão do Maven, este ciclo pode sofrer alteração com a instalação de algum
plugin.

64
Figura 27 – Fases do ciclo de vida Maven.
Fonte: Apache Maven Project, 2014.
Se for realizado um comando mvn:package, o Maven realizará todas as etapas
anteriores até a fase package. A fase package gera um artefato, conforme declarado no
arquivo pom. O Maven pode ser integrado a alguma IDE. Para o Eclipse a integração é
realizada através do plugin m2eclipse, que deve ser instalado. Após instalado o plugin, é
possível criar um novo projeto e inserir as dependências com o auxilio de uma interface
gráfica. Na imagem a seguir foi criado um novo projeto Maven utilizando a IDE. Nesta
imagem pode ser visto a exibição dos arquétipos disponíveis.

65
Figura 28 – Eclipse, arquétipos disponíveis.
Semelhantemente ao processo via terminal, na próxima interface é exibido
formulário para inserção de groupId, artifactId... Ao final o projeto é criado, com a estrutura
do arquétipo webapp, que pode ser visto a seguir:

66
Figura 29 – Estrutura do projeto Maven gerado.
A estrutura gerada é a de um arquétipo Maven webapp, outro arquétipo pode
possui estrutura diferente.
Em projetos grandes e que possuam equipes grandes, é muito importante atentar
para a padronização, desta forma é utilizado muitas vezes repositórios locais, específicos da
empresa, nesses repositórios adiciona-se as dependências de projetos específicos da empresa,
com as versões específicas. Outra vantagem da utilização de repositórios locais é não
necessitar da web, já que esta rodando em um servidor local, na empresa. É neste repositório
também onde são depositados os artefatos produzidos no projeto.
O Maven fornece uma série de relatórios, criados à partir da utilização de plugins
declarados no arquivo pom. Estes relatórios apresentam informações de quanto do código
fonte está coberto por testes, se há duplicidade de código, tamanho de classe, se é muito

67
longa, entre outros. Para estes relatórios regras podem ser criadas, como por exemplo: se a
cobertura de testes no código for menor que 50% o build falhará. Essas regras são inseridas
também no arquivo pom. Na imagem a seguir é apresentado o exemplo de um pequeno
relatório com o plugin Jacoco, esse relatório mostra o quanto dos métodos está coberto por
testes. Esta informação traz segurança para realizar alterações pois sabe-se quanto do método
está todo coberto por testes.
Figura 30 – Relatório Jacoco.
Fonte: CodingByExample.org, 2014.
Na imagem observa-se os métodos com sua porcentagem do cobertura por testes.
Diversos outros plug-ins existem para gerar outros tipos de relatórios também utilizando o
Maven. Os relatórios na maioria das vezes são gerados em dois formatos, html e xml. A
vantagem de ter o relatório em xml é que este pode ser exibido por uma outra ferramenta,
como por exemplo o Jenkins, ferramenta que será apresentada a seguir.
4.2.4 Integração contínua com Jenkins
A integração contínua é uma prática em que os membros de uma equipe, as
diversas áreas envolvidas no desenvolvimento, integram seus trabalhos conforme as
funcionalidades forem sendo desenvolvidas. Esta integração normalmente acontece diversas
vezes ao dia e pode ser realizada manualmente, ou automatizada com auxilio de sistemas
específicos de automação de builds. A pratica de integração continua permite identificar os
problemas a medida em que eles vão surgindo, a cada build, que é a construção do artefato, é
quando o projeto passa pelas etapas de testes compilação e está pronto para ser usado,
problemas novos podem ser descobertos e resolvidos, não deixando desta forma, tudo para o

68
final. Esta importante prática exige o envolvimento de todos envolvidos para surtir o bom
efeito e tem como cultura a frase: “quebrou conserta!”. Neste capítulo será apresentado o
Jenkins, que é um servidor de integração contínua que permite, builds, testes, comunicação
com a equipe, feedback. No Jenkins o build pode ser agendado. Essa ferramenta pode ser
utilizada só ou junto de um servidor. Aqui será utilizado o Apache Tomcat. Sua instalação é
bastante simples, bastando copiar o arquivo jenkins.war para o diretório webapps do Tomcat.
No exemplo que segue, foi criado um novo projeto Java Maven no eclipse, com o
nome tccCarlos, e, arquétipo webapp, após a criação o projeto foi compartilhado com uma
ferramenta de versionamento, neste caso o Subversion. Na imagem a seguir uma importa
etapa do processo de integração pode ser vista. Devem ser excluídos os arquivos que não
pertencem a estrutura do projeto, pois estes não precisam ser versionados, são no caso
arquivos da IDE, Eclipse.
Figura 31 – Arquivos não versionados.
Após esta etapa é preciso dar um commit no projeto, para que seja enviado para o
repositório, em seguida pode-se iniciar o Jenkins. Com o servidor iniciado e acessando a url:
http://localhost:8080/jenkins/ a tela inicial da ferramenta é exibida, como pode ser visto a
seguir:

69
Figura 32 – Tela inicial Jenkins.
No primeiro acesso a ferramenta necessita ser configurada. O caminho para
configuração inicial é: Manage Jenkins, Configure System. Será mostrada a interface a seguir:

70
Figura 33 – Tela de configuração Jenkins.
Nesta interface é possível verificar, entre outros elementos configuráveis, o campo
JDK, onde deve ser informado o nome e caminho do pacote de desenvolvimento (JDK). Da
mesma forma deve ser feito para o sistema de automação de builds, nesse caso o Maven.
Após feita a configuração, retornando a tela inicial, cria-se um new Job, como visto a seguir:

71
Figura 34 – Tela new job.
Nesta tela deve ser informado um nome e tipo, no caso foi utilizado: tccCarlos e
tipo build a maven 2/3 project. Para utilizar falta somente configurar o repositório de código
fonte, sistema de versionamento, Subversion. É necessário voltar a opção configure para isto,
visto a seguir:
Figura 35 – Tela configuração do repositório.

72
Após esta etapa é possível realizar o primeiro build do projeto, selecionando a
opção build now. Na tela a seguir é exibido o status do build, o primeiro objeto azul informa
que o build foi bem sucedido, bem como o segundo, um sol, representa que tudo correu bem.
Quando houver problemas estes símbolos se modificam, exibindo nuvens e cores diferentes.
Figura 36 – Tela de projeto, build bem sucedido.
O Jenkins oferece a possibilidade de tornar os builds periódicos, não necessitando
que o usuário selecione a opção build now. Também pode ser configurado para em caso de
quebra do build ser enviado e-mail para a equipe. Como pode ser visto, na imagem a seguir
foi configurado um build periódico, com a periodicidade de um minuto, ou seja, a cada
minuto um novo build será realizado.
Figura 37 – Interface build periódico.
A seguir, com o objetivo de gerar uma quebra de build , foi criado no projeto uma
nova classe Java e incluído uma instrução com erro, instrução que não compila, e foi dado o

73
comando commit. É possível observar na imagem a seguir o resultado visual de um build com
problema. Esta interface é customizável.
Figura 38 – Interface build com problemas.
4.2.5 Testes unitários com JUnit
Nesta seção serão apresentados os testes unitários, utilizando a ferramenta JUnit.
Esta ferramenta facilita o desenvolvimento e execução dos testes unitários em código Java. O
JUnit verifica se cada unidade do código funciona da forma esperada. Sua instalação é
simples, bastando adicionar a dependência ao projeto. No caso dos exemplos deste trabalho a
dependência foi adicionada no arquivo pom.xml do projeto com Maven. Os testes com essa
ferramenta são automatizados, desta forma é escrito código para realizar o teste.
Com a ferramenta Eclipse, utilizando o projeto criado na seção anterior (tccCarlos), foi criado
um novo diretório (src/test/java), onde ficarão as classes de teste (test case), posteriormente
foi criada uma classe com o nome, TesteData, bem como um pacote denominado, tcc.data. Na
imagem a seguir é possível visualizar a estrutura do projeto com as alterações:

74
Figura 39 – Classe de testes JUnit.
Na imagem o teste ainda não foi implementado, de forma que assim este teste
falhará. A ideia é que os testes sirvam de modelo para a implementação do sistema. Seguindo
o processo será implementado a classe de teste, essa classe verificará se um ano é bissexto.
Pode ser visto a seguir o resultado da codificação:
Figura 40 – Codificação da classe de teste.

75
É possível verificar a existência de problemas nesta classe, a classe Data ainda
não foi criada, desta forma o código não compila. Deve ser criada esta classe. A instrução
assertTrue do JUnit, informa que o que está dentro dos parênteses, a chamada ao método
anoBissexto, da classe Data, deve ser verdadeiro, deve retornar um valor booleano true. Na
imagem a seguir pode ser visto o resultado da implementação da classe data com algoritmo
que verifica se o ano é bissexto:
Figura 41 – Codificação classe Data.
Agora já é possível realizar o teste. Clicando na opção run As, Maven test, é
possível visualizar a saída de console informando que o teste passou. Visto a seguir:

76
Figura 42 – Resultado do teste.
Posteriormente pode ser realizado o commit no projeto, enviando para o
repositório de código, ferramenta de versionamento Subversion, e após realizado o build com
o Jenkins. O teste passa e o build é bem sucedido, como pode ser visto a seguir:
Figura 43 – Resultado do build no Jenkins.
Nesta seção foi apresentado a classe de teste (test case), com apenas um cenário,
poderiam ser testados outros cenários, como o cenário de ano não bissexto, onde seria passado

77
um ano não bissexto, para isso outro método seria criado com o mesmo algoritmo só que
dessa vez retornaria um valor booleano do tipo false.
4.2.6 Considerações sobre o uso das ferramentas no ciclo de vida das aplicações
O ALM e as ferramentas apresentadas neste trabalho, propõem um processo que
não é finalizado com a entrega do projeto de software. Novas funcionalidades vão surgindo,
customizações vão sendo necessárias e desta forma o processo vai sendo realimentado. As
novas funcionalidades que podem ser adicionadas não devem prejudicar tudo aquilo que já
foi feito, ou seja, o build no Jenkins que estava certo não pode ser quebrado com a adição ou
customização de uma funcionalidade. Realizadas as mudanças, uma nova versão estará
disponível no repositório. Em alguns casos a empresa cliente possui um usuário restrito no
Redmine e a própria equipe cadastra diretamente na ferramenta as necessidades.
As ferramentas aqui apresentadas podem ser utilizadas de forma diferente de
acordo com cada empresa e os seus processos.
Entre as vantagens de uso de ferramentas, como as apresentadas, além do auxilio
no processo, elas incentivam a equipe à utilizar as boas práticas no desenvolvimento de
sistemas. Sem que seja percebido, muitas vezes, as boas práticas estão sendo atendidas.
A seguir são listados alguns benefícios específicos:
• comunicação e colaboração: troca de mensagem entre a equipe em uma
única interface, para resolver problemas na fase de desenvolvimento. O
Redmine oferece funcionalidades como fórum, wiki;
• rastreabilidade dos artefatos de trabalho: os artefatos gerados durante o
desenvolvimento são todos versionados, permitindo maior visibilidade e
organização em todo o desenvolvimento, isto é alcançado com o
Subversion, ferramenta de versionamento e repositório de código fonte;
• redução do tempo de manutenção: os testes permitem que os problemas
sejam identificados e tratados em seguida, a cada funcionalidade
adicionada os testes são refeitos para verificar se tudo continua

78
funcionando. Isto é possível através da utilização de ferramentas de testes
como o JUnit no caso da linguagem Java;
• tomada de decisão: relatórios podem ser gerados a cada interação
informando de condições diversas relativas ao desenvolvimento, desta
forma decisões podem ser tomadas. A ferramenta Maven oferece um
conjunto de possibilidades de relatórios que podem ser gerados. Outra
ferramenta importante é o Jenkins, que informa como está o
desenvolvimento, se tudo está bem ou se há problemas.
O conjunto formado pelas ferramentas apresentadas fornece uma solução de
ALM, sendo que outras mais poderiam ser adicionadas. Esta abordagem permite o deploy
contínuo da aplicação, e assim deixar a aplicação pronta para ser instalada em um servidor.
No fluxograma a seguir é demonstrado um exemplo de contexto em que esta
solução pode ser utilizada.

79
Figura 44 – Fluxograma da proposta de uso das ferramentas.
No fluxograma apresentado é sugerido um processo contínuo de gerenciamento
do ciclo de vida de um aplicativo, ou seja, um processo que permite a construção contínua do
sistema.

80
4.2.7 Relato de experiências
Como forma de avaliação da proposta de solução apresentada neste trabalho, foi
realizado um conjunto de perguntas e submetidas a um profissional da área de análise e
desenvolvimento de sistemas. O profissional escolhido possui vasta experiência em
desenvolvimento de software, atuando nesta área desde 1999, também é instrutor de cursos
em Java e práticas ágeis e na época de desenvolvimento deste trabalho estava cursando
mestrado em Engenharia de Software.
Diversas perguntas foram realizadas acerca das ferramentas escolhidas. A seguir a
formulação das questões e a transcrição das respostas.
a) Que conhecimento você possui da ferramenta Redmine? Já utilizou? Que
importância você vê na utilização da ferramenta?
“Para profissionais que utilizam práticas ágeis, a ferramenta Redmine costuma ser
utilizada para organização da demanda de suporte, de desenvolvimento e de
manutenção. Em uma proposta de ALM a importância dessa ferramenta é destacada
uma vez que ela pode ser facilmente integrada com outras incluindo a de
versionamento de código para viabilizar rastreabilidade. Eu tive oportunidade de
utilizar a ferramenta em 2 projetos e é uma boa alternativa para outras similares
incluindo JIRA Agile, Kanbanize, OnTrack e Agile Zen. Destaque à facilidade de
aprendizagem e recursos suficientes para promover visibilidade do progresso e do
planejamento de entrega. Nas versões que utilizei não tinha suporte a features ágeis
incluindo burndown, CFD, métricas entre outras.”
b) Com relação à ferramenta Subversion, que conhecimentos você tem? Já utilizou? Que
vantagens pode se obter em utiliza-la?
“Uma ferramenta de versionamento de código é de extrema importância no processo
de desenvolvimento de software. Hoje em dia não se entende profissional um
desenvolvimento que não utilize alguma. Tive oportunidade de utilizar o SVN em
apenas um projeto. Utilizei o CVS e o TFS, propostas mais antigas. Mas de 2010 pra
cá tenho usado em todos os projetos GIT. A diferença fundamental entre as primeiras

81
e essa última é a proposta distribuída de desenvolvimento. Ao invés de um repositório
centralizado, o código é versionado em várias máquinas, o que reduz o risco de não se
ter acesso aos fontes por falta de conexão de rede. Também uma ferramenta com
propostas mais modernas relacionadas a criação de tags, de branchs e merge de
conteúdo texto. Outra vantagem do GIT é a existência de vários provedores na
internet, com contas de uso público e privado como GitHub, BitBucket e GitLab.
Muitas ferramentas HTML 5 e IDEs online tem integração nativa com GIT e não
suportam CVS ou SVN. É importante de definir uma política simples e aplicada de
gestão de configuração de modo que se tenha poucas branchs estáveis.”
c) Que conhecimentos você tem do Maven? Em que cenários julga benéfico a utilização?
Que importância tem o Maven no processo de desenvolvimento atualmente? Utiliza
nos projetos que participa?
“O Maven popularizou a automação das fases de construção dos artefatos de software
com a proposta de convenção sobre configuração. Antes dele era necessário criar
scripts extensos usando ANT para obter as mesmas facilidades. Com Maven é
possível partir de um arquétipo popular ou criado pela empresa facilitando e
padronizando a organização de pastas e as fases desde a compilação até a instalação
dos artefatos em um repositório central de dependências. Aliás as dependências são
outra forte razão para usar Maven: são declaradas e podem ser resgatadas de
repositórios configurados, permitindo fácil atualização quando necessário. Utilizo a
ferramenta desde 2010 em todos os projetos java em que participei. Alguns plugins
utilizados nos projetos em que utilizei a ferramenta: Surefire, Sonar e Jenkins,
JBehave.”
d) De que forma a ferramenta Jenkins pode contribuir no processo de desenvolvimento
de software? Como se relaciona com as anteriores?
“A ferramenta Jenkins é a base da integração contínua. Através de seus jobs é possível
cumprir um dos principais princípios do Lean Software Development que é "Eliminate
Waste". Commits para a ferramenta de versionamento de código podem ser ouvidos
por uma job e disparar uma série de tarefas incluindo execução de testes
automatizados dos mais variados, atualização de migrações de bases de dados, geração

82
de documentação técnica, entre outros. É possível configurar limites que quebram a
build caso não sejam atendidos. Também é comum a criação de jobs para atualizar o
ambiente de homologação e o ambiente de produção fazendo com que uma nova
feature possa ser disponibilizada para o usuário final com facilidade e sem chance de
erros humanos.”
e) Qual importância você observa na utilização do JUnit? Que importância ele tem no
processo de ALM? Você vê vantagens claras na utilização?
“Testes automatizados com JUnit ou qualquer outra biblioteca atendem 2 dos 4
quadrantes possíveis de testes ágeis. Permitem que o desenvolvedor garanta a
responsabilidade das classes implementadas a medida em que as cria, reduzindo
significativamente os esforços para garantia de qualidade interna. Outra grande
vantagem quando utilizado em conjunto com o Jenkins ou outra ferramenta de
integração contínua é o suite de regressão. Novas versões da aplicação executam esse
suite para garantir que features já liberadas continuem funcionando adequadamente.
No desenvolvimento atual não é considerado profissional desenvolver sem escrita de
testes automatizados mesmo existindo uma equipe de testes no projeto. Tal equipe
deve ter foco apenas na qualidade externa. A qualidade interna fica para a equipe de
desenvolvimento. Utilizo a biblioteca desde 2007.”
f) Com relação à IDE eclipse, você utiliza? Que vantagen você percebe na sua
utilização?
“Utilizo o Eclipse a mais de 10 anos e sempre foi a minha principal ferramenta de
desenvolvimento. Quando iniciei a desenvolver com Java, era a ferramenta mais
estável e mais leve para utilização. Hoje em dia existem ferramentas tão boas quanto
em destaque o NetBeans e o IntelliJ IDEA. O primeiro tem a vantagem de oferecer
vários plugins pré instalados para desenvolvimento com Swing/JFC, JavaFX, JSF,
HTML5 e mobile. Também costuma ser a primeira IDE a suportar os novos recursos
de um JDK ou JEE. O IntelliJ é pago mas oferece suporte a vários recursos
interessantes incluindo refatoração avançada, testes automatizados, web standards
entre outros. O Eclipse ainda é muito usado devido ao histórico e a seu editor de
código bastante efetivo. Porém peca bastante no conjunto de plugins disponíveis e na

83
integração com ferramentas e tecnologias consagradas como Jenkins, Sonar, HTML 5,
Android, JEE e JS. O desenvolvimento com IDE na linguagem Java é bastante
produtivo. Outras linguagens como Ruby (on Rails) e Python acabam por minimizar a
necessidade do uso de IDEs o que é algo a se considerar ao definir o ambiente de
desenvolvimento de uma aplicação OO.”
g) Como você vê a solução de ALM apresentada nesta monografia?
“A solução de ALM apresentada na monografia oferece uma referência para equipes
que reconhecerão a importância do assunto e querem implantá-lo no seu dia a dia de
desenvolvimento. Os exemplos são simples permitindo que não seja requisito
conhecimento especializado de infra estrutura para colocar a aplicação em
funcionamento. Trabalhos como esse certamente podem contribuir para que o tema se
torne mais utilizado no mercado de trabalho nos próximos anos.”

84
5 CONCLUSÕES E TRABALHOS FUTUROS
A seguir são apresentadas as principais conclusões desta monografia e as
recomendações para trabalhos futuros.
5.1 CONCLUSÕES
Em busca de atingir o objetivo principal deste trabalho foi realizado profunda
pesquisa das ferramentas utilizadas atualmente por desenvolvedores de sistemas em diferentes
linguagens e que, atuam no auxílio ao gerenciamento do ciclo de vida das aplicações. A
pesquisa preocupou-se inicialmente em verificar as ferramentas para diferentes etapas do
ciclo.
Para as diferentes áreas pesquisadas mais de uma ferramenta foi encontrada,
sendo que para a escolha de cada uma delas foi levado em consideração a capacidade de
facilmente trabalhar em conjunto com as já escolhidas. Os conceitos de ALM apresentados na
fundamentação teórica apresentaram as características desse processo, trazendo os pilares e
as disciplinas de ALM. As disciplinas foram muito importantes pois foram elas que guiaram a
escolha das ferramentas. Foi tratado da importância da adoção de ALM no cenário atual,
cenário formado muitas vezes por equipes distribuídas e com necessidade de ferramentas
diferentes. A descrição das funcionalidades das ferramentas trouxe uma visão geral de cada
uma delas, sendo que não foi preocupação cobrir todas as possibilidades, que são inclusive
extensíveis através de plugins. Foi possível identificar na realização deste trabalho uma
possível solução para diversos problemas tratados nas disciplinas de Engenharia de Software
do curso, bem como daqueles problemas que surgiram na realização das diversas atividades
nas disciplinas que envolveram programação. A pouca bibliografia disponível ainda sobre
ALM fez com que a pesquisa se centrasse em autores chave no processo. Para a demonstração
de parte das funcionalidades das ferramentas foi utilizado uma máquina virtual com sistema
operacional Linux onde foram instaladas as ferramentas e feitos os testes.
Para a implantação de ALM, inicialmente é importante identificar as necessidades
da empresa, mapear seus processos e identificar as disciplinas do ALM que a empresa

85
necessita. Não necessariamente todo o conjunto de ferramentas sugerido precisa ser
utilizado, o ALM pode ser implantado em níveis, pode-se iniciar com uma ferramenta de
gerenciamento de projetos e ir avançando conforme as necessidades e adaptação da equipe, a
participação das pessoas é de total importância para o sucesso em um projeto com práticas de
ALM, não bastando simplesmente a aquisição de ferramentas.
A presente monografia apresentou uma solução de ALM que abrange parte dos
conceitos presentes na Engenharia de Software, essa solução oferece um ponto de partida à
toda equipe que deseja acompanhar o ciclo de vida de sua aplicação mitigando os tradicionais
problemas. A opção de implantação de ALM utilizando ferramentas open-source permite ser
testada sem a necessidade de investimentos financeiros. Consultando o trabalho é possível
iniciar a implantação e começar a trabalhar, podendo ser implantado por etapas como foi dito.
O trabalho apresenta as ferramentas incrementando o processo. Em um primeiro nível a
primeira ferramenta, Redmine, poderia ser adotada, em um segundo nível, incluído o
repositório de código Subversion, e assim progredindo.
5.2 RECOMENDAÇÕES
O processo de ALM apresenta conceitos importantes e modernos para o
gerenciamento do ciclo de vida das aplicações, desta forma sugere-se como prosseguimento
desse trabalho a inclusão de práticas ágeis de desenvolvimento, como por exemplo Scrum ou
XP. Sugere-se também realizar a validação da solução apresentada através da implementação
de um sistema, seguindo os passos propostos no trabalho.
Visto que na solução apresentada todas as ferramentas são de software livre, uma
outra sugestão para um trabalho futuro seria a realização de uma pesquisa verificando as
soluções de ALM existentes de software proprietário, realizando uma comparação com a
solução apresentada e demonstrando ambientes ideias para adoção de uma ou de outra.
Como última sugestão sugere-se ampliar o conjunto de ferramentas,
principalmente no que diz respeito à fase de testes, uma série de ferramentas podem ser
adicionadas tornando a solução ainda mais rica.

86
REFERÊNCIAS
APACHE MAVEN PROJECT. Lifecycles Reference. Disponível em:
<http://maven.apache.org/ref/3.2.3/maven-core/lifecycles.html>. Acesso em: set. 2014.
ASSOCIAÇÃO SOFTWARE LIVRE.ORG. Que é Software Livre? Disponível em:
<http://softwarelivre.org/portal/o-que-e>. Acesso em: Março de 2014.
BERNARDO, Barbara. Software livre traz segurança. Disponível em:
<http://textolivre.pro.br/blog/?p=118> Acesso em: 5 abr. 2014.
BIRMELE, Chris. ALM versus SDLC – two different things. Disponível em:
<http://blogs.msdn.com/b/chrisbirmele/archive/2007/04/23/alm-versus-sdlc-two-different-
things.aspx> Acesso em: 4 maio 2014.
BOURKE, P.; FAIRLEY, R. Guide to the Software Engineering Body of Knowledge
(Swebok V3.0). IEEE Computer Society, 2014
CARLOS. Alan. O que é o ALM – Application Lifecycle Management?. 2014. Disponível
em: <http://www.almbrasil.com.br/alm-aprendendo-mais-sobre-application-lifecycle-
management/>. Acesso em: 11 mar. 2014.
CHAPPELL. David. What is Application Lifecycle Management?. 2010. Disponível em:
<http://www.davidchappell.com/writing/white_papers/What_is_ALM_v2.0--Chappell.pdf>.
Acesso em: 11 mar. 2014.
CONDÉ, Luciano. Introdução ao Application Lifecycle Management (ALM). In Microsoft
Developer Network. Biblioteca MSDN. 2009. Disponível em: <http://msdn.microsoft.com/pt-
br/library/ee156630.aspx>. Acesso em: 20 mar. 2014.
DE LUCA, Cristina. Até 2017, Brasil terá 70,5 milhões de usuários de smartphones em
uso. 2014. Blog Circuito de Luca, IDGNow, Portal Terra. Disponível em:
<http://idgnow.com.br/blog/circuito/2014/01/22/base-de-usuarios-de-smartphones-na-
america-latina-vai-aumentar-283-em-2014/>. Acesso em: 11 mar. 2014.
FERREIRA, Alexandre. Open Source Software. 2004/2005. Disponível em:
<http://student.dei.uc.pt/~ajfer/CP/CP%20Artigo%20%20Open%20Source%20Software.pdf>
Acesso em: 5 abr. 2014.
FOWLER, Martin. Refactoring – Inproving the design of existing code. 1 ed. USA:
Addison Wesley Longman, 1999.
GARTNER. Magic Quadrant for Application Life Cycle Management. 2012. Disponível
em: <https://www.gartner.com/doc/2037115/magic-quadrant-application-life-cycle> Acesso
em: 17 mar. 2014.
HIRAMA, Kechi. Engenharia de Software – Qualidade e Produtividade com Tecnologia.
Rio de Janeiro: Elsevier, 2012.

87
JUNIOR, Gilberto Silveira. A liderança do mercado ALM é sua?. 2012. Disponível em:
<http://openalmbr.blogspot.com.br/> Acesso em: 20 jun. 2014.
LOPES, Carlos. Reduzindo o tamanho de classes. 2014. Disponível em:
<http://codingbyexample.wordpress.com/author/carlosaml/> Acesso em: 30 out. 2014.
MENDONÇA. Vera. Open Source – Vantagens e Desvantagens. Disponível em:
<http://igeirv.wordpress.com/author/veracm/> Acesso em: 4 abri. 2014.
PRADA. Rodrigo. O que é plugin. 2008. Disponível em:
<http://www.tecmundo.com.br/hardware/210-o-que-e-plugin-.htm> Acesso em: 27 abr. 2014.
PRESSMAN. Roger. Engenharia de Software – Uma abordagem profissional. 7 ed. São
Paulo: AMGH, 2011.
ROSSBERG, J.; OLAUSSON, M. Pro Application Lifecycle Management With Visual
Studio 2012.
SILVA, Edna Lucia da; MENEZES, Estera Musztak. Metodologia da pesquisa e elaboração
de dissertação. 4 ed. Florianópolis: UFSC, 2005.
SOMMERVILLE, Ian. Engenharia de Software. 8 ed. São Paulo: Pearson, 2007.
SOMMERVILLE, Ian. Engenharia de Software. 6 ed. São Paulo: Pearson, 2004.
SOUZA. Bruno. Application Lifecycle Management com ferramentas open source.
Disponível em:
<http://www.slideshare.net/brjavaman?utm_campaign=profiletracking&utm_medium=sssite
&utm_source=ssslideview> Acesso em: 17 mar. 2014.
UNGER, Russ; CHANDLER, Carolyn. A Project guide for to UX design: for user
experience designers in the field or in the making. USA: New Riders, 2009.

GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE

Mais conteúdo relacionado

Semelhante a GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE (20)

Último (20)

GERENCIAMENTO DO CICLO DE VIDA DE APLICAÇÕES, UTILIZANDO FERRAMENTAS OPEN SOURCE