Gerenciamento

de Projetos e
Gerência de
Configuração

Profª. Semíramis Ribeiro de Assis

Indaial – 2023
1a Edição
 Elaboração:
Profª. Semíramis Ribeiro de Assis

Copyright © UNIASSELVI 2023

Revisão, Diagramação e Produção:

Equipe Desenvolvimento de Conteúdos EdTech
Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada pela equipe Conteúdos EdTech UNIASSELVI

C397 CENTRO UNIVERSITÁRIO LEONARDO DA VINCI.

Núcleo de Educação a Distância. ASSIS, Semíramis Ribeiro de.

Gerenciamento de Projetos e Gerência de Configuração. Semíramis Ribeiro

de Assis. Indaial - SC: Arqué, 2023.

286p.

ISBN 978-65-5646-564-7
ISBN Digital 978-65-5646-565-4

“Graduação - EaD”.
1. TI 2. Projetos 3. Gerência

CDD 658.404
Bibliotecário: João Vivaldo de Souza CRB- 9-1679

Impresso por:
 APRESENTAÇÃO
Projetos estão presentes em diversos momentos do cotidiano, como, por
exemplo, a construção de um prédio, a preparação para a realização de um curso ou
para a construção de um produto de Tecnologia da Informação (TI).

Muitos projetos, por falta ou deficiência em seu planejamento, são abortados

antes de suas conclusões ou acabam extrapolando (e muito) os recursos, orçamentos
e prazos iniciais previstos, causando um grande prejuízo financeiro aos seus
patrocinadores. Portanto, saber gerenciar as variáveis envolvidas em um projeto é de
fundamental importância para evitar perdas financeiras.

Pressman e Maxim (2021) conceituam projetos de software como a atividade

que agregará as funcionalidades desejadas pelo cliente com o conhecimento técnico
necessário para construir um produto de software, com sua arquitetura, estruturas de
dados e integração entre componentes.

Morais e Zanin (2017), por outro lado, definem projeto como um estágio
intermediário entre o ramo do negócio que será explorado e a tecnologia que será
utilizada para construção de uma aplicação, que atenda às necessidades dos clientes
de forma a garantir qualidade (através da solidez), eficácia (o programa deverá atender
às expectativas para as suas funcionalidades) e possuir uma boa interface de utilização,
de modo a garantir uma boa experiência pelo usuário.

Conhecer técnicas e métodos que auxiliem no gerenciamento de um projeto é

uma peça fundamental para se atingir ao objetivo inicial dele. Saber planejar a quantidade
de recursos necessários, fazer uma estimativa de tempo e dos custos do projeto requer
o conhecimento e aplicação de técnicas, as quais abordaremos ao longo desta unidade.

Na Unidade 1, abordaremos o conceito de projetos e suas principais definições.

Além disso, iremos apresentar o papel do Gerente de Projetos e sua importância para o
andamento do projeto e gerenciamento de todas as variáveis envolvidas.

Ainda nesta unidade, serão apresentados os métodos utilizados para realizar o

processo de Gestão de Projetos, englobando os métodos ágeis, preditivos e a Gestão
Simplificada de Projetos, os principais conceitos sobre a Gestão de Configurações, assim
como a conceitualização de Auditoria e seus princípios básicos.

Na Unidade 2, estudaremos as principais técnicas para o gerenciamento de

projetos e configurações, detalhando cada etapa das técnicas de Gerenciamento de
Projetos previamente apresentadas.
 A Unidade 3, por sua vez, apresentará as principais ferramentas para o
Gerenciamento de Projetos, assim como as principais Normas vigentes para a Gestão
de Projetos e Configurações.

Lembrem-se, o conhecimento é uma estrada contínua, que deverá estar

sempre sendo percorrida e explorada para que novos horizontes se abram. Portanto,
bons estudos!

Profª. Semíramis Ribeiro de Assis

 GIO
Olá, eu sou a Gio!

No livro didático, você encontrará blocos com informações

adicionais – muitas vezes essenciais para o seu entendimento
acadêmico como um todo. Eu ajudarei você a entender
melhor o que são essas informações adicionais e por que você
poderá se beneficiar ao fazer a leitura dessas informações
durante o estudo do livro. Ela trará informações adicionais
e outras fontes de conhecimento que complementam o
assunto estudado em questão.

Na Educação a Distância, o livro impresso, entregue a todos

os acadêmicos desde 2005, é o material-base da disciplina.
A partir de 2021, além de nossos livros estarem com um
novo visual – com um formato mais prático, que cabe na
bolsa e facilita a leitura –, prepare-se para uma jornada
também digital, em que você pode acompanhar os recursos
adicionais disponibilizados através dos QR Codes ao longo
deste livro. O conteúdo continua na íntegra, mas a estrutura
interna foi aperfeiçoada com uma nova diagramação no
texto, aproveitando ao máximo o espaço da página – o que
também contribui para diminuir a extração de árvores para
produção de folhas de papel, por exemplo.

Preocupados com o impacto de ações sobre o meio ambiente,

apresentamos também este livro no formato digital. Portanto,
acadêmico, agora você tem a possibilidade de estudar com
versatilidade nas telas do celular, tablet ou computador.

Preparamos também um novo layout. Diante disso, você

verá frequentemente o novo visual adquirido. Todos esses
ajustes foram pensados a partir de relatos que recebemos
nas pesquisas institucionais sobre os materiais impressos,
para que você, nossa maior prioridade, possa continuar os
seus estudos com um material atualizado e de qualidade.

QR CODE
Olá, acadêmico! Para melhorar a qualidade dos materiais ofertados a você – e
dinamizar, ainda mais, os seus estudos –, nós disponibilizamos uma diversidade de QR Codes
completamente gratuitos e que nunca expiram. O QR Code é um código que permite que você
acesse um conteúdo interativo relacionado ao tema que você está estudando. Para utilizar
essa ferramenta, acesse as lojas de aplicativos e baixe um leitor de QR Code. Depois, é só
aproveitar essa facilidade para aprimorar os seus estudos.
 ENADE
Acadêmico, você sabe o que é o ENADE? O Enade é um
dos meios avaliativos dos cursos superiores no sistema federal de
educação superior. Todos os estudantes estão habilitados a participar
do ENADE (ingressantes e concluintes das áreas e cursos a serem
avaliados). Diante disso, preparamos um conteúdo simples e objetivo
para complementar a sua compreensão acerca do ENADE. Confira,
acessando o QR Code a seguir. Boa leitura!

LEMBRETE
Olá, acadêmico! Iniciamos agora mais uma
disciplina e com ela um novo conhecimento.

Com o objetivo de enriquecer seu conheci-

mento, construímos, além do livro que está em
suas mãos, uma rica trilha de aprendizagem,
por meio dela você terá contato com o vídeo
da disciplina, o objeto de aprendizagem, materiais complementa-
res, entre outros, todos pensados e construídos na intenção de
auxiliar seu crescimento.

Acesse o QR Code, que levará ao AVA, e veja as novidades que

preparamos para seu estudo.

Conte conosco, estaremos juntos nesta caminhada!

 SUMÁRIO
UNIDADE 1 - PRINCIPAIS CONCEITOS PARA A GERÊNCIA
DE PROJETOS E CONFIGURAÇÃO.................................................................... 1

TÓPICO 1 - PRINCIPAIS CONCEITOS PARA A GERÊNCIA DE PROJETOS............................3

1 INTRODUÇÃO .......................................................................................................................3
2 PROJETOS E MÉTODOS PARA GESTÃO DE PROJETOS ...................................................3
2.1 PROJETOS ............................................................................................................................................... 4
2.1.1 O papel do Gerente de Projetos.................................................................................................8
2.1.2 O Plano de Projetos e sua importância................................................................................. 10
3 MÉTODOS PARA GESTÃO DE PROJETOS ........................................................................ 12
3.1 GESTÃO SIMPLIFICADA DE PROJETOS............................................................................................12
3.2 MÉTODOS PREDITIVOS...................................................................................................................... 14
3.3 MÉTODOS ÁGEIS.................................................................................................................................. 15
RESUMO DO TÓPICO 1.......................................................................................................... 19
AUTOATIVIDADE.................................................................................................................. 20

TÓPICO 2 - GESTÃO DE CONFIGURAÇÕES........................................................................ 23

1 INTRODUÇÃO .................................................................................................................... 23
2 CONCEITO E IDENTIFICAÇÃO DE CONFIGURAÇÕES ..................................................... 23
2.1 CONCEITO E IDENTIFICAÇÃO DE CONFIGURAÇÕES ..................................................................24
2.2 PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO .........................................................................25
2.3 CONTROLE DE MUDANÇAS EM PROJETOS E CONFIGURAÇÕES ..........................................30
2.3.1 Controle de versões....................................................................................................................31
2.3.2 Controle de mudanças.............................................................................................................33
3 INTEGRAÇÃO E ENTREGA CONTÍNUA ............................................................................ 36
3.1 O PROCESSO DE ENTREGA E INTEGRAÇÃO CONTÍNUA ............................................................36
3.2 O PIPELINE DE IMPLANTAÇÃO.........................................................................................................38
3.3 MONTANDO O ECOSSISTEMA DE ENTREGA CONTÍNUA............................................................42
RESUMO DO TÓPICO 2......................................................................................................... 49
AUTOATIVIDADE.................................................................................................................. 50

TÓPICO 3 - AUDITORIA........................................................................................................ 53
1 INTRODUÇÃO .................................................................................................................... 53
2 CONCEITOS E PRINCÍPIOS BÁSICOS DE AUDITORIA .................................................... 53
2.1 PRINCÍPIOS DA AUDITORIA ...............................................................................................................56
2.2 DEFINIÇÃO DE ESCOPO ....................................................................................................................58
2.3 TIPOS DE AUDITORIA .........................................................................................................................59
3 O PROCESSO DE AUDITORIA ........................................................................................... 62
3.1 ESTUDO DA DOCUMENTAÇÃO .........................................................................................................63
3.2 OS CICLOS DE AUDITORIA.................................................................................................................65
3.3 METODOLOGIAS DE AUDITORIA...................................................................................................... 67
4 ELABORAÇÃO DO RELATÓRIO DE AUDITORIA E O PROCESSO DE FOLLOW UP ........... 71
4.1 CONCLUSÃO DA AUDITORIA E O RELATÓRIO FINAL DE AUDITORIA....................................... 72
4.2 A IMPORTÂNCIA DA AUDITORIA PARA SETORES ESTRATÉGICOS DA EMPRESA................ 73
4.3 O PROCESSO DE MELHORIA CONTÍNUA E O FOLLOW UP......................................................... 75
LEITURA COMPLEMENTAR..................................................................................................78
RESUMO DO TÓPICO 3......................................................................................................... 85
AUTOATIVIDADE.................................................................................................................. 86
REFERÊNCIAS...................................................................................................................... 88

UNIDADE 2 — TÉCNICAS PARA O GERENCIAMENTO DE

PROJETOS E CONFIGURAÇÕES.................................................................... 91

TÓPICO 1 — GESTÃO DE PROJETOS PREDITIVA................................................................ 93

1 INTRODUÇÃO .................................................................................................................... 93
2 GESTÃO DE ENTREGA ...................................................................................................... 94
2.1 GESTÃO DO ESCOPO ..........................................................................................................................95
3 GESTÃO DAS ATIVIDADES E CRONOGRAMA ................................................................. 101
3.1 GESTÃO DAS ATIVIDADES................................................................................................................102
3.2 GESTÃO DO CRONOGRAMA............................................................................................................108
4 GESTÃO DOS CUSTOS E DO ORÇAMENTO .....................................................................109
4.1 GESTÃO DE CUSTOS..........................................................................................................................109
4.2 GESTÃO DE ORÇAMENTO..................................................................................................................111
5 GESTÃO DA QUALIDADE ................................................................................................. 114
6 GESTÃO DA EQUIPE ........................................................................................................ 118
RESUMO DO TÓPICO 1........................................................................................................124
AUTOATIVIDADE.................................................................................................................125

TÓPICO 2 - GESTÃO ÁGIL DE PROJETOS.......................................................................... 127

1 INTRODUÇÃO ................................................................................................................... 127
2 PRINCÍPIOS DA GESTÃO ÁGIL......................................................................................... 127
2.1 O MANIFESTO ÁGIL ...........................................................................................................................128
3 METODOLOGIAS ÁGEIS ..................................................................................................128
3.1 Scrum ................................................................................................................................................... 129
3.2 EXTREME PROGRAMMING (XP).....................................................................................................130
3.3 LEAN.....................................................................................................................................................130
4 GESTÃO DAS ATIVIDADES ÁGEIS ..................................................................................132
2.3.1 Papéis dos membros............................................................................................................... 133
2.3.2 Mínimo Produto Viável (MVP)...............................................................................................134
2.3.3 O Product Backlog.................................................................................................................. 135
2.3.4 Equipes Autogerenciáveis e o Product Backlog............................................................. 136
2.3.5 Histórias do Usuário................................................................................................................ 137
2.3.6 Visibilidade das funcionalidades do produto.................................................................... 137
3 A IMPORTÃNCIA DA ADOÇÃO DE TIMEBOXES ............................................................. 140
3.1 STORY POINTS....................................................................................................................................140
3.2 A DINÂMICA DE UMA EQUIPE ÁGIL ...............................................................................................141
RESUMO DO TÓPICO 2....................................................................................................... 144
AUTOATIVIDADE.................................................................................................................145

TÓPICO 3 - A GERÊNCIA DE CONFIGURAÇÃO COMO ESTRATÉGIA PARA O

GERENCIAMENTO DE UM PROJETO DE SOFTWARE..................................... 147
1 INTRODUÇÃO ................................................................................................................... 147
2 DINÂMICA DA GESTÃO ESTRATÉGICA DE PROJETOS ................................................. 147
2.1 PILARES DA GESTÃO ESTRATÉGICA.............................................................................................. 149
2.1.1 Matriz SWOT ...............................................................................................................................150
2.1.2 Key Performance Indicator (KPI) .........................................................................................150
2.1.3 Gestão de ideias para novos projetos..................................................................................151
2.2 MÉTODOS DE AVALIAÇÃO............................................................................................................... 152
2.2.1 Método AHP ou Método Multicritério ................................................................................. 153
 2.3 FATORES CRÍTICOS DE SUCESSO ................................................................................................ 155
2.3.1 Liderança em equipes ágeis ................................................................................................. 156
3 GERENCIAMENTO DE CONFIGURAÇÃO ......................................................................... 157
3.1 PLANO DE GERENCIAMENTO DE CONFIGURAÇÃO .................................................................. 159
3.2 PLANO DE GERENCIAMENTO DE MUDANÇAS ...........................................................................161
3.2.1 Itens de Configuração............................................................................................................. 162
3.3 PRINCÍPIOS E TÉCNICAS DE MANUTENÇÃO DE SOFTWARE ................................................164
3.4 REFATORAÇÃO................................................................................................................................... 165
3.5 REENGENHARIA DE SOFTWARE.....................................................................................................167
3.6 MIGRAÇÃO DE CÓDIGO....................................................................................................................168
LEITURA COMPLEMENTAR.................................................................................................171
RESUMO DO TÓPICO 3........................................................................................................178
AUTOATIVIDADE................................................................................................................. 179

REFERÊNCIAS..................................................................................................................... 181

UNIDADE 3 — FERRAMENTAS E NORMAS DE APOIO AO

GERENCIAMENTO DE PROJETOS E CONFIGURAÇÕES.....................................189

TÓPICO 1 — FERRAMENTAS PARA APOIO AO GERENCIAMENTO

DE PROJETOS E CONFIGURAÇÃO................................................................. 191
1 INTRODUÇÃO ................................................................................................................... 191
2 FERRAMENTAS PARA CONTROLE DE VERSÃO ............................................................. 191
2.1 CONCURRENT VERSION SYSTEM (CVS) ......................................................................................201
2.2 GIT ....................................................................................................................................................... 202
2.3 MERCURIAL ....................................................................................................................................... 206
2.4 BITKEEPER......................................................................................................................................... 208
2.5 SOURCESAFE.....................................................................................................................................210
2.6 CLEARCASE........................................................................................................................................210
2.8 STARTEAM........................................................................................................................................... 212
2.7 SYNERGY.............................................................................................................................................. 212
3 FERRAMENTAS PARA CONTROLE DO CICLO DE VIDA DE PROJETOS.........................213
3.1 FERRAMENTAS PARA CONTROLE DE TAREFAS......................................................................... 217
3.1.1 Redmine ...................................................................................................................................... 217
3.1.2 Bugzilla........................................................................................................................................ 221
3.1.3 Trac...............................................................................................................................................222
3.1.4 Zendesk..................................................................................................................................... 223
3.1.5 TeamTrack................................................................................................................................. 224
4 FERRAMENTAS PARA PROJETOS BASEADOS EM METODOLOGIAS ÁGEIS............... 225
4.1 TRELLO..................................................................................................................................................227
4.2 JIRA..................................................................................................................................................... 228
4.3 DOCKER............................................................................................................................................... 231
5 MÉTODO KANBAN E O GERENCIAMENTO DE PROJETOS............................................ 232
RESUMO DO TÓPICO 1....................................................................................................... 236
AUTOATIVIDADE................................................................................................................ 238

TÓPICO 2 - FERRAMENTAS PARA INTEGRAÇÃO E ENTREGA CONTÍNUA......................241

1 INTRODUÇÃO ...................................................................................................................241
2 IMPORTÂNCIA DA UTILIZAÇÃO DE FERRAMENTAS PARA
INTEGRAÇÃO E ENTREGA CONTÍNUA ...........................................................................241
3 JENKINS.......................................................................................................................... 247
4 OUTRAS FERRAMENTAS................................................................................................ 249
RESUMO DO TÓPICO 2........................................................................................................251
AUTOATIVIDADE................................................................................................................ 252

TÓPICO 3 - NORMAS DE APOIO AO GERENCIAMENTO DE CONFIGURAÇÕES............... 255

1 INTRODUÇÃO .................................................................................................................. 255
2 VISÃO DO CMMI E MPS.BR SOBRE A GERÊNCIA DE
CONFIGURAÇÃO E NORMAS DE AUDITORIA................................................................. 255
3 NORMAS IEEE.................................................................................................................. 259
3.1 IEEE STD 828/1998 ......................................................................................................................... 260
3.2 IEEE STD 1042/1986 ........................................................................................................................ 261
4 NORMAS ISO/IEC ........................................................................................................... 263
4.1 ISO/IEC 10007 ................................................................................................................................... 264
4.2 ISO/IEC 12207.................................................................................................................................... 265
4.3 ISO/IEC TR 15846 ............................................................................................................................ 266
LEITURA COMPLEMENTAR............................................................................................... 268
RESUMO DO TÓPICO 3....................................................................................................... 275
AUTOATIVIDADE.................................................................................................................276

REFERÊNCIAS.................................................................................................................... 278
 UNIDADE 1 -

PRINCIPAIS CONCEITOS
PARA A GERÊNCIA
DE PROJETOS E
CONFIGURAÇÃO
OBJETIVOS DE APRENDIZAGEM
A partir do estudo desta unidade, você deverá ser capaz de:

• conhecer os principais conceitos sobre Projetos e Gerência de projetos;

• aprender sobre a importância do papel do Gerente de Projetos e sua atuação no

processo de gestão;

• apreender os principais métodos para Gerenciamento de Projetos;

• identificar os conceitos fundamentais sobre Auditoria, as metodologias voltadas

para sistemas de TI e seus princípios básicos.

PLANO DE ESTUDOS
A cada tópico desta unidade você encontrará autoatividades com o objetivo de
reforçar o conteúdo apresentado.

TEMA DE APRENDIZAGEM 1 – PRINCIPAIS CONCEITOS PARA A GERÊNCIA DE

PROJETOS
TEMA DE APRENDIZAGEM 2 – GESTÃO DE CONFIGURAÇÕES
TEMA DE APRENDIZAGEM 3 – AUDITORIA

CHAMADA
Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure
um ambiente que facilite a concentração, assim absorverá melhor as informações.

1
 CONFIRA
A TRILHA DA
UNIDADE 1!

Acesse o
QR Code abaixo:

2
UNIDADE 1 TÓPICO 1 -
PRINCIPAIS CONCEITOS PARA A
GERÊNCIA DE PROJETOS

1 INTRODUÇÃO
Em nosso cotidiano, é comum realizarmos planejamento para diferentes fins,
dentre eles para a execução de uma viagem, a construção de uma casa, a reforma em
um cômodo ou até para a comemoração de um aniversário. Todas estas situações, na
verdade, representam projetos que possuem início, meio e fim.

Larson e Gray (2016) conceituam um projeto por um conjunto de esforços

temporários para se atingir a um determinado objetivo. Pelo quesito temporário,
entende-se que terá um início, meio e fim, entregando um produto ou resultado ao final
da sua execução.

Saber gerenciar um projeto é uma tarefa que envolve diferentes conhecimentos,

sendo fundamental para que o empreendimento consiga atingir o sucesso esperado.
Todo o processo de gerenciamento precisa ter a metodologia adequada para o tipo de
projeto que será desenvolvido, assim como para garantir o sucesso esperado. Então,
é preciso que se tenha uma pessoa com o objetivo de realizar o planejamento e
acompanhamento das etapas necessárias para o projeto que será desenvolvido, que é
o gerente de projetos.

Estudante, no Tema de Aprendizagem 1, iremos abordar os principais conceitos

e características inerentes a um projeto, além dos métodos atuais utilizados para realizar
o gerenciamento de suas principais características.

O subtópico 2 apresentará o conceito de projetos e os métodos para efetuar a

gestão de projetos. O subtópico 3, por sua vez, apresentará os métodos para gestão de
projetos.

2 PROJETOS E MÉTODOS PARA GESTÃO DE PROJETOS

Acadêmico, neste subtema, iremos abordar o conceito de projeto, apresentando
o papel do Gerente de Projetos e a importância da elaboração de um Plano de Projetos.

3
 2.1 PROJETOS
Larson e Gray (2016) e PMI (2017) chamam atenção para a natureza temporária
de um projeto, indicando que toda a ação que possui prazos determinados para início
e fim, envolvendo um esforço específico para se atingir a um objetivo, é caracterizada
como um projeto.

Pressman e Maxim (2021) afirmam que as diversas variáveis que compõem

as necessidades da aplicação que será desenvolvida, como a definição do que será
preciso (recursos), em qual quantidade e por quanto tempo esses recursos deverão
estar à disposição do projeto, e qual o limite de orçamento existente e do prazo final para
entrega, é que irão definir o processo de Gerenciamento de Projetos.

Todo projeto surge de uma necessidade ou ideia que, após a sua conclusão,
deverá fornecer um benefício, muitas vezes em forma de melhorias ou mudanças. Por
exemplo, vamos imaginar que uma casa precise de reforma. Para isso, um novo projeto
deverá ser iniciado, fazendo um planejamento do que será melhorado, qual o resultado
esperado, qual a estimativa de prazos, materiais e custos, além de quantas pessoas
estarão envolvidas na execução desse processo de reforma.

Segundo Maximiano e Veroneze (2022), nem toda atividade pode ser considerada
como um novo projeto. Atividades que não tenham um prazo para sua finalização não
são consideradas projetos, mas sim operações. Como exemplo, podemos mencionar
o processo de fabricação de um produto, como um carro ou uma lâmpada. As ações
executadas no fluxo de produção desses itens são contínuas, ou seja, sem prazo para
finalização, descaracterizando, assim, a necessidade de um projeto.

Ainda conforme Maximiano e Veroneze (2022), um projeto, ao contrário de

uma operação, não tem a repetição constante como uma característica, sendo uma
ação voltada para executar uma tarefa única, específica e não repetitiva. Apesar disso,
existem projetos que são recorrentes, ou seja, que buscam entregar um objetivo em
comum com outros projetos já desenvolvidos anteriormente, como a construção de
uma aplicação ou site. Uma Empresa poderá ter uma equipe focada apenas em realizar
projetos de construção de softwares ou de manutenção evolutiva em produtos de TI já
existentes.

4
 Figura 1 – Relação entre singularidade e volume de projetos

Fonte: adaptada de Maximiano e Veroneze (2022)

A Figura 1 apresenta uma relação entre a singularidade de um projeto e o volume de

projetos de um mesmo tipo. Consideramos projetos singulares aqueles que são mais exclusivos, ou
seja, que buscam inovar em suas ideias ou na maneira de serem executados. Dessa forma, quanto
mais projetos de um mesmo tipo são executados por um time, menor será o nível de singularidade
desses projetos, tendo em vista que as mesmas etapas irão acontecer, culminando em um mesmo
objetivo (como a construção de uma aplicação). Projetos inovadores, ou seja, aqueles que diferem
dos projetos comumente executados, são considerados singulares, geralmente acontecendo em
menor número.

Uma pesquisa científica para definição de uma nova metodologia para construção de
softwares poderá ser considerada como um projeto inovador, tendo pouca recorrência (poucos
projetos iguais que são executados) e maior singularidade (projeto ímpar). Projetos voltados para
construção de aplicações, por exemplo, estão sempre acontecendo (alta recorrência) o que reduz
sua singularidade.

Quando é mencionado o termo singularidade, notem que estamos nos referindo

apenas à categoria de projetos e não ao produto entregue ao final de cada ciclo, já que cada
projeto se destinará à construção de um produto único com características próprias e diferentes
de outros produtos já construídos anteriormente. A esse produto entregue ao final de cada
projeto, denominamos entregável.

Maximiano e Veroneze (2022) classificam os entregáveis de um projeto nas

seguintes categorias:

• Produtos físicos – tudo aquilo que é tangível no mundo físico.

• Conceitos, conhecimentos e informações – conceitos e ideias que são tidas como
intangíveis, ou seja, não concretos.
• Eventos e serviços – preparação para a realização de um evento ou serviço.
• Instituições e organizações – projetos que envolvam criação ou modificações em
ambientes Empresariais.

5
 Quando um ou mais projetos estão correlacionados em uma Organização, é
constituído o conceito de programa. Então, podemos ter programas de aperfeiçoamento
técnico voltado para desenvolvedores, programa de atenção à saúde, programa de
pesquisa e desenvolvimento de novos produtos, dentre outros.

INTERESSANTE
A palavra projeto é derivada do termo em latim projectum, significando algo
lançado para a frente. O que nos remete às etapas iniciais, intermediárias
e finais para implementar uma ideia, ou seja, percorrer as etapas necessárias
para a construção da ideia que deu origem ao seu respectivo projeto.

Sommerville (2011) afirma que o processo de gerenciamento de um projeto

deverá englobar a gestão de recursos (pessoas, orçamento, cronograma, instalações
físicas) para que o objetivo pretendido seja alcançado, de modo que a progressão
aconteça. Esses recursos poderão alimentar gráficos de barra, como o de Gantt, que
apresentará a situação de cada recurso do projeto em um determinado período do
projeto, como quantos recursos humanos (desenvolvedores) estão trabalhando no mês
corrente, quantos estão de férias ou alocados em outros projetos, além de quais tarefas
estão sendo executadas.

Pressman e Maxim (2021), Sommerville (2011) e Morais e Zanin (2017) denominam

os gráficos de barra como gráficos de Gantt, homenageando seu criador, Henry Gantt.
Esses gráficos têm o objetivo de apresentar, com o uso de barras paralelas e baseadas
em um calendário cronológico, as tarefas do projeto de acordo com o período de
execução de cada tarefa, apresentando quem estará responsável pela execução de
qual atividade.

Segundo Pressman e Maxim (2021), uma característica importante de um

projeto é o seu desempenho, que poderá ser medido a partir da adoção de critérios
de desempenho, indicando qual a probabilidade de se obter sucesso com o propósito
pretendido ou não. Existem cinco níveis de medição para o sucesso de um projeto:

• Processo – O sucesso do projeto será indicado pela correta adoção de ferramentas

para gestão de projetos e pela escolha do projeto, ou seja, dentre os projetos
disponíveis para serem executados, a correta priorização do projeto atual o fez
entrar na “esteira de trabalho”.
• Projeto – O sucesso do projeto terá o termômetro da correta gestão de suas
principais variáveis (escopo, tempo e custo). Caso o projeto esteja consumindo
os recursos necessários para o tempo que ele está em andamento, ele terá uma
melhor classificação de sucesso. Caso mais recursos estejam sendo consumidos,

6
 além dos que foram previstos para a respectiva fase na qual o projeto se encontra,
seu sucesso terá uma menor classificação.
• Produto – O sucesso, para este critério, é medido pela aderência do produto aos
requisitos iniciais solicitados para sua construção e pela satisfação do cliente com
o que está sendo construído.
• Negócio – Para este critério, o nível do sucesso será medido pelo retorno sobre
o investimento (ROI), ou seja, se o produto resultante gerou o valor esperado, em
relação ao investimento feito, atendendo às expectativas do cliente.
• Sucesso estratégico – O desempenho do projeto, para este indicador, será
medido pelas partes interessadas (stakeholders) externas. Podemos considerar,
como exemplo, se o produto está atendendo às expectativas em termos de fatia de
mercado, se possui vantagens competitivas em relação aos produtos concorrentes,
dentre outros benefícios.

Segundo Larson e Gray (2016), todos os projetos já executados, ou ainda em

andamento por uma Empresa, irão compor o seu portifólio, ou seja, sua carteira de
experiências, para servir de referência aos clientes. A partir deste portifólio, um novo
cliente poderá, por exemplo, analisar as taxas de sucesso dos projetos, quantos foram
concluídos dentro do prazo esperado, quantos atrasaram, quantos tiveram boa aceitação
do mercado etc. PMI (2017), por sua vez, caracteriza um portfólio como o conjunto dos
produtos de TI (aplicações, serviços etc.) e operações que buscam atender às metas
estratégicas da Organização.

Segundo Pressman e Maxim (2021), o fato de um projeto seguir um processo de

software, não implica que o prazo acordado com as partes interessadas será cumprido
nem que as expectativas acerca das funcionalidades do projeto irão ser atendidas.
Também não é garantia que o projeto utilizou boas práticas em sua construção e que
terá facilidade de manutenção a longo prazo.

A condução do projeto e de suas variáveis, como escopo, orçamento, prazo e

recursos, deverá ser feita pela pessoa que ocupará o papel do gerente de projetos.

ESTUDOS FUTUROS
Acadêmico, detalharemos cada variável de um projeto na Unidade 2 deste
livro, apresentando em detalhes como o gerenciamento deverá ser feito,
enfatizando os pontos importantes em cada variável, de modo que o projeto
consiga cumprir, ao seu final, o planejamento realizado.

Abordaremos, no próximo subtópico, a função do Gerente de Projetos e a

importância do acompanhamento de um projeto, em todas as suas fases, pela pessoa
que ocupará este papel, sendo um fator importante de sucesso a boa gerência em todas
as etapas do projeto.
7
 2.1.1 O papel do Gerente de Projetos
Para que um projeto possa ser conduzido por todas as suas fases até sua
conclusão, é fundamental que uma pessoa tenha feito todo o planejamento necessário
e, também importante, o acompanhamento da evolução desse projeto, mensurando o
tempo gasto, verificando se está dentro do cronograma previsto, analisando os gastos
com os recursos e se está de acordo com o inicialmente previsto, dentre outras questões
que garantirão a entrega de valor ao cliente na etapa final.

Segundo PMI (2017), o Gerente de Projetos tem um papel muito mais além do
que apenas supervisionar o andamento dos processos, é o responsável por guiar um
projeto para que seu êxito seja alcançado, pelas etapas de escolha de qual projeto
deverá ser iniciado, pela elaboração de todo o planejamento e execução de um projeto,
pelo acompanhamento e encerramento do projeto.

Sommerville (2011) apresenta as seguintes atribuições ao papel do Gerente de

Projetos:

• Efetuar o planejamento do projeto, com elaboração do cronograma e estimativas de

início e fim de cada atividade, assim como levantar quais os recursos necessários
para a execução do projeto.
• Realizar atribuição de tarefas aos membros do time de desenvolvimento, com o
devido acompanhamento do andamento de cada tarefa.
• Gerar os relatórios necessários para apresentação às partes interessadas, contendo
dados atuais sobre a execução do projeto para diferentes públicos e abordando
diferentes níveis de detalhamento. Desenvolvedores, por exemplo, terão uma visão
técnica sobre o projeto, enquanto patrocinadores que não são da área técnica irão
visualizar informações em níveis macro.
• Analisar e gerenciar os riscos envolvidos no projeto.
• Gerenciar os membros do time de desenvolvimento, escolhendo as pessoas com os
melhores perfis, conforme a necessidade técnica.
• Elaborar propostas relativas ao projeto, como a proposta inicial para fechamento do
negócio com o cliente.

Conforme Melo et al. (2021) explicam que a função do Gerente de Projetos foi
profissionalizada a partir da criação do Project Management Institute (PMI), responsável
pela elaboração e publicação do guia Project Management Body of Knowledge (PMBOK),
voltado para as melhores práticas no processo de gerenciamento de projetos.

CMMI (2017) apresenta um modelo de medição da qualidade e maturidade

de uma Organização em relação aos processos de desenvolvimento de software, se
tornando uma forma complementar ao PMBOK. Enquanto o foco do CMMI é melhorar a
capacidade de uma organização em gerenciar seus processos de desenvolvimento de
software, o PMBOK se concentra nas etapas da gestão de projetos.

8
 NOTA
O PMBOK é um livro que possui as melhores práticas voltadas para o
gerenciamento de projetos, escrito pelo Project Management Institute (PMI).
Sua versão é atualizada periodicamente por este instituto, podendo ter seu
download efetuado no site oficial https://www.pmi.org/, mediante compra.
Suas práticas são amplamente difundidas e utilizadas por gerentes de projetos
para os mais variados tipos de projetos.

Figura 2 – Etapas do projeto executadas pelo Gerente de Projetos

Fonte: adaptada de Sommerville (2011)

A Figura 2 apresenta as etapas que o Gerente de Projetos deverá executar

para que um novo projeto possa ter seu andamento iniciado e seguir até seu completo
encerramento. Percebe-se que há uma sequência lógica das etapas, de modo que a
próxima etapa só acontecerá com o encerramento da etapa anterior.

IMPORTANTE
O Gerente de Projetos deverá definir quais os papéis desempenhados por
cada membro do time que trabalhará no projeto, delegar tarefas, além de
controlar eventuais riscos que apareçam ao longo do andamento do projeto.
Também é sua função garantir que toda a documentação do projeto será
construída e mantida corretamente.

9
 Todo o processo de gestão de um projeto visa assegurar o resultado, ou seja,
contornar eventuais atrasos ou situações adversas que venham a acontecer durante
a execução do projeto, garantindo que o esforço da equipe será direcionado para a
construção do produto, agregando o valor esperado ao negócio do cliente.

Segundo PMI (2017), cabe ao Gerente de Projetos unificar as diferentes

áreas inerentes a um projeto, como a comunicação entre todos os envolvidos, o
balanceamento entre as demandas e o prazo estimado para execução do projeto, que
acontecem ao longo de toda a existência do projeto. A este processo, denominamos de
gerenciamento da integração do projeto.

O próximo subtópico abordará o documento Plano de Projeto, fundamental

para o início e acompanhamento de todo e qualquer projeto, apresentando informações
importantes para que o projeto obtenha o êxito esperado.

2.1.2 O Plano de Projetos e sua importância

Segundo Pressman e Maxim (2021), para que todo o planejamento de um projeto
possa ser documentado e acompanhado, é fundamental a elaboração de um Plano
de Projeto pelo Gerente de Projetos, contendo todas as informações necessárias
sobre o projeto em pauta, como seu propósito, estimativa de cronograma, justificativa
do projeto, descrição para a solução proposta ao problema apresentado e as demais
estimativas (custos e recursos).

Maximiano e Veroneze (2022) e Larson e Gray (2016) definem este documento

inicial, também conhecido como termo de abertura do projeto (project charter),
como o documento que servirá de guia, após a conclusão de sua elaboração e aprovação,
para que as etapas do projeto se iniciem.

Cada conteúdo englobado por este documento inicial será de suma importância
para que os interessados no projeto (stakeholders) possam realizar a validação sobre a
aderência da solução proposta para o problema ou situação apresentada.

Segundo PMI (2017), a partir da elaboração de um documento que formalize

a inicialização de um projeto, o Gerente de Projetos se tornará apto a alocar recursos
para realização das atividades do projeto. Para que este documento seja elaborado, os
acordos firmados entre os stakeholders e o Gerente de projeto irão servir de subsídios de
entrada, assim como eventuais documentos que descrevam o negócio que representará
o domínio para a aplicação que será construída.

A justificativa do projeto deverá apresentar quais ganhos serão obtidos com

a solução proposta, comparando-a com outras soluções existentes e voltadas para a
mesma situação, exaltando os pontos fracos e fortes de cada solução, além de apresentar

10
qual o diferencial da solução proposta frente às demais. Com a justificativa, busca-se
realizar um trabalho de convencimento do stakeholder responsável pela escolha de qual
solução será a mais indicada a ser implementada e obter sua aprovação.

A descrição do projeto apresentará a solução de forma direta, porém com a

riqueza de detalhes suficiente para que não restem dúvidas sobre o que será feito e
quais benefícios serão obtidos após a conclusão da solução.

De acordo com PMI (2006), as estimativas devem constar no termo de abertura

do projeto, considerando os custos, cronograma e riscos identificados no projeto. O
Gerente de Projetos é a pessoa que analisará e calculará todas essas informações,
apresentando em detalhes as variáveis analisadas e seus relacionamentos.

Podem ser necessários ajustes nas versões iniciais do termo de abertura do

projeto, sendo necessária, então, nova rodada de avaliação, também conhecida como
filtros do processo de aprovação e avaliação do projeto.

Com a devida aprovação do termo inicial, o Gerente de Projetos deverá se

preocupar em mobilizar os recursos necessários, conforme o planejamento. Então,
caso sejam necessárias contratações de colaboradores com perfis técnicos específicos,
é nesta fase que esse processo será feito. As instalações físicas necessárias para
o desenvolvimento do projeto também serão providenciadas, assim como serão
definidas as ferramentas de trabalho dos membros da equipe e ferramentas oficiais de
comunicação.

A etapa de execução do projeto colocará em prática o planejamento feito, dando

início ao processo de acompanhamento do projeto, controlando os custos, os prazos
acordados e as entregas planejadas. É possível que o Gerente estabeleça marcos para
serem alcançados ao longo do andamento do projeto, indicando se o que foi planejado
terá condições de ser cumprido. Ao atingir um marco de controle, será possível perceber
se o projeto estará dentro do prazo estipulado, mantendo suas variáveis conforme o
planejamento inicial, ou se está desviando do que foi planejado, requerendo uma ação
de contorno rápida.

Segundo PMI (2006), o encerramento do projeto deverá entregar o resultado

acordado, liberar os recursos alocados para a execução do projeto, realizar todo o
processo de prestação de contas, além de elaborar todos os documentos e relatórios
necessários, seguindo as políticas organizacionais.

Pressman e Maxim (2021) apresentam a importância de se analisar os projetos

com uma visão crítica das lições aprendidas, como a relação entre o que foi planejado
e o que realmente foi executado, análise das métricas coletadas e a coleta de opinião
de todos os envolvidos (desenvolvedores e clientes), fazendo registros por escrito. Essa

11
 base de conhecimento será fundamental para o processo de melhoria contínua para
projetos futuros que venham a ser desenvolvidos pela equipe, buscando evitar pontos
de falha e evidenciar pontos que deram certo.

É possível que, após a conclusão de um projeto e entrega de seu produto,

um novo contrato seja firmado entre as partes interessadas, para, por exemplo, a
realização de manutenções evolutivas ou adaptativas (em caso de projetos voltados
para construção de aplicações). Nesse caso, um novo projeto deverá ser iniciado, tendo
seu escopo definido pelas alterações necessárias e solicitadas pelo cliente.

Acadêmico, no próximo subtema abordaremos os métodos para a gestão de

projetos, contemplando os detalhes importantes sobre as principais metodologias de
gestão.

3 MÉTODOS PARA GESTÃO DE PROJETOS

A gerência de projetos, por sua complexidade intrínseca e variáveis internas,
precisa da aplicação de métodos que visem auxiliar o processo de gestão, de modo
a garantir sua condução até a sua etapa final. Os métodos voltados para a gestão de
projetos podem ser classificados, de forma macro, em preditivos ou ágeis e, neste
subtema, abordaremos os principais.

Apresentaremos o método simplificado para gestão de projetos, seguindo para

a apresentação dos métodos preditivos e das metodologias ágeis.

3.1 GESTÃO SIMPLIFICADA DE PROJETOS

Segundo Maximiano e Veroneze (2022), o método de Gestão Simplificada de
Projetos foca em um processo de planejamento minimalista, concentrando seus esforços
nas fases de execução e entrega. Este método é mais indicado quando os envolvidos
no projeto, como o gerente de projetos e os membros da equipe de desenvolvimento,
já possuem um sólido conhecimento do negócio e de todos os processos necessários
para desenvolvimento e entrega do produto.

Poderemos considerar exemplos práticos de projetos nos quais é possível

aplicar essa técnica aqueles que já possuem fases bem estabelecidas e sem muitas
novidades, como as festas de modo geral, reparos ou ajustes em produtos já prontos,
construção de edificações, dentre outros.

12
 Figura 3 – Fases da metodologia simplificada de gestão de projetos

Fonte: adaptada de Maximiano e Veroneze (2022)

A Figura 3 apresenta um resumo das fases da metodologia simplificada de

gestão de projetos. Por ser um processo simplificado, que as pessoas envolvidas já
possuem o conhecimento necessário para executar cada etapa, então o processo de
planejamento se resume à definição do produto ou serviço que será entregue. A próxima
fase será montar uma equipe que receberá as tarefas, delegadas pelo gerente do projeto,
e executá-las. O gerente do projeto deverá fazer todo o acompanhamento das tarefas
delegadas, garantindo que o produto ou serviço será entregue em tempo hábil, com os
recursos e orçamento disponíveis. Por fim, o produto é entregue e o projeto finalizado.

Apesar de ser uma versão simplificada de gestão de projetos, é necessário que

alguma ferramenta de controle seja utilizada, como a elaboração de cronogramas e
a definição de marcos de entregas (ou datas limites para que cada etapa possa ser
finalizada) e estas datas precisam ser controladas para que o prazo possa ser cumprido.

Segundo Provinciatto e Caroli (2020), as tarefas também podem ser controladas

a partir do quadro Kanban, que utiliza raias com rótulos que irão apresentar o estado
atual de uma tarefa, objetivando classificar as tarefas do projeto de acordo com o estágio
atual de desenvolvimento delas, exibindo o andamento de cada tarefa com exatidão a
todos os interessados. Um exemplo de rótulos para as raias pode ser “Em preparação”,
“Fazendo” e “Feito”. A partir do momento que uma tarefa vai sendo executada por um
membro da equipe de desenvolvimento e concluída, ela vai sendo movida para a raia
“Fazendo” e, após sua finalização, para a raia “Feito”.

IMPORTANTE
Estaremos abordando o método Kanban quando formos tratar sobre as
metodologias ágeis para gerenciamento de projetos.

13
 Acadêmico, no próximo subtema apresentaremos as metodologias preditivas,
também conhecidas como tradicionais, para gestão de projetos.

3.2 MÉTODOS PREDITIVOS

Segundo Larson e Gray (2016), a metodologia preditiva, ao contrário da gestão
simplificada de projetos, que não dá muita ênfase à fase de planejamento, realizará
todo o planejamento minucioso do projeto, tentado prever e englobar todos os detalhes
necessários, além de todas as situações que envolvem produtos a serem entregues
(denominados entregáveis), antes que o projeto realmente se inicie. Esta fase tende a
levar bastante tempo, já que planejará todo o escopo do projeto, com todos os requisitos
e recursos necessários para sua conclusão.

Pressman e Maxim (2021) definem os métodos preditivos com a denominação

de métodos tradicionais, por terem suas aplicações iniciadas em áreas mais antigas
na condução de projetos, como as engenharias (civil, mecânica etc.). Para estas áreas,
porém, é fundamental que todos os detalhes sejam minuciosamente planejados, já que
serão necessários cálculos para a quantidade de material necessário para a realização
de uma obra, por exemplo, o tempo previsto de conclusão, a quantidade de homens que
irão realizar a força tarefa.

Projetos que são construídos baseados em métodos preditivos irão possuir

uma documentação bem estruturada sobre tudo que foi planejado e executado. Esta
documentação será necessária para que se faça um controle sobre todas as etapas do
projeto e seja possível perceber quando algo está sendo desviado do objetivo principal.

Pressman e Maxim (2021) afirmam que as etapas das metodologias preditivas

são sequenciais. Então, uma fase só será iniciada após o término da fase anterior, o que
indica a necessidade de completude dos documentos gerados e demais artefatos de
uma fase, antes que a próxima seja iniciada. Como as necessidades do cliente podem
mudar ao longo do tempo, é possível que, no momento que sejam necessárias todas as
definições dos requisitos para concluir o planejamento, o cliente não tenha esta definição
clara em relação ao projeto, o que pode acarretar frustração ao receber o produto, que
poderá não atender as suas reais necessidades.

Segundo Maximiano e Veroneze (2022) e Larson e Gray (2016), é possível que

uma fase que está em andamento tenha um nível maior de detalhamento, ou seja, uma
menor granularidade do que está sendo feito e de seu planejamento, do que as fases
que ainda não foram iniciadas (que podem possuir um planejamento a um nível maior
de granularidade). A esse processo de detalhamento apenas quando a fase está mais
próxima, denomina-se planejamento em ondas.

14
 Figura 4 – Etapas da metodologia preditiva

Fonte: adaptada de Pressman e Maxim (2021)

A Figura 4 apresenta um resumo das principais fases de uma metodologia

preditiva. A primeira etapa é a definição do produto que será entregue como objetivo do
projeto, e todo o planejamento desse produto deverá ser feito englobando seu escopo e
suas funcionalidades (ou requisitos). O planejamento do tempo (cronograma do projeto)
será feito logo em seguida, fazendo uma estimativa de prazo para conclusão de cada
etapa. Os recursos necessários serão levantados, como a quantidade de profissionais
e perfis desejados, seguindo-se da estimativa de custos e orçamento do projeto. A
execução do projeto será iniciada logo em seguida, e, ao concluí-lo, o produto será
entregue e a equipe desmobilizada, com a prestação de contas feita e respectivos
pagamentos aos fornecedores executados.

ESTUDOS FUTUROS
As metodologias ágeis, que serão apresentadas no próximo subtema,
surgiram como uma forma alternativa de gestão de projetos, alterando o foco
do processo (objetivo das metodologias preditivas) para o desenvolvimento
do produto.

3.3 MÉTODOS ÁGEIS

Segundo Pressman e Maxim (2021), o desenvolvimento dos métodos ágeis
procurou suprir uma necessidade das equipes de desenvolvimento de software
quanto a entregas mais eficazes, com menos burocracia em torno das documentações
extensas, possibilitando uma maior satisfação do cliente. Com os métodos preditivos,
por somente entregarem o produto ao final de todo o ciclo do projeto, muitas vezes o
tempo decorrido do início até a entrega ocasionava uma insatisfação do cliente com o
produto que era entregue, já que é comum que as necessidades mudem com o passar
do tempo e, consequentemente, as prioridades do que deve ser construído, em termos
de funcionalidades, para as aplicações desejadas.

15
 Entretanto, segundo Melo et al. (2021), é possível utilizar as metodologias
ágeis em conjunto com práticas adotadas pelas metodologias preditivas, como o
gerenciamento de riscos, custos e cronograma, já que estes processos são bem
definidos pelas metodologias tradicionais, em contraste com o alto dinamismo dos
métodos ágeis, que estão propensos a alterações constantes no escopo e priorização
de tarefas.

Segundo Maximiano e Veroneze (2022), métodos ágeis para desenvolvimento

de projetos e produtos visam focar mais no que será entregue do que na elaboração de
documentação extensa, manter o cliente sempre perto, dando feedbacks constantes
sobre o produto que está sendo desenvolvido, garantindo uma melhor aderência aos
requisitos necessários para satisfazer o cliente. As partes envolvidas no projeto devem,
então, manter uma comunicação constante e fluida, deixando alinhado sempre o que
está sendo construído com as expectativas acerca do produto.

Segundo Valente (2020) e Pressman e Maxim (2021), projetos construídos a

partir de metodologias preditivas não obtinham o retorno do cliente sobre o produto que
estava em construção antes que a entrega final acontecesse, além de não ser possível
alterar, após a inicialização da fase de codificação do produto, o escopo do que seria
construído. A utilização de metodologias ágeis, por outro lado, possibilita a alteração,
em tempo de execução do projeto, das funcionalidades que serão implementadas em
um primeiro momento, tendo em vista que a priorização é uma tarefa contínua, que
dependerá apenas da necessidade do cliente.

INTERESSANTE
Segundo Sutherland (2016), as metodologias ágeis surgiram a partir da
publicação, no ano de 2001, de um manifesto, conhecido como manifesto
ágil, por um grupo de dezessete desenvolvedores de software. Podemos
encontrar os princípios do manifesto em: https://agilemanifesto.org/iso/ptbr/
manifesto.html.

Ao se utilizar uma metodologia ágil, o produto poderá ser entregue em partes,

que consigam agregar valor ao negócio do cliente, conforme suas prioridades. A cada
entrega feita, é possível que o cliente valide, se certificando que o que está sendo
construído atenderá as suas expectativas.

Um outro ponto importante em projetos que utilizam metodologias ágeis é

a participação do cliente ao longo do processo de desenvolvimento da aplicação ou
objetivo do projeto. A equipe envolvida trabalhará em ciclos, conhecidos como sprints,

16
que terão metas específicas, conforme as necessidades que forem priorizadas pelo
cliente, e que terão, ao seu final, uma cerimônia de apresentação para que o cliente
valide o que foi finalizado no ciclo.

ESTUDOS FUTUROS
Acadêmico, estudaremos com mais detalhes sobre metodologias ágeis e sua
estrutura interna na Unidade 2. Fique atento!

Sutherland (2016) afirma que um dos principais métodos ágeis utilizados para
construção de produtos, atualmente, é o framework SCRUM. Ele especifica cerimônias
para que um projeto possa ser executado, facilitando a comunicação entre os membros
da equipe de desenvolvimento e o cliente (ou partes interessadas), assim como visa a
construir o produto em ciclos, com tempos bem definidos e acordados antes do início
do projeto. É possível que uma equipe adapte as cerimônias de acordo com sua cultura
e necessidade.

Segundo Caroli (2018) e Melo et al. (2021), existem outros métodos ágeis que
podem ser utilizados por uma equipe para construção de aplicações, como o Lean, que
objetiva construir um produto com o estritamente necessário, construindo uma versão
mínima (conhecida como MVP – Mínimo produto viável), que atenda às necessidades do
cliente, realizando melhorias contínuas até que o produto com os requisitos desejáveis
tenha sido construído, ou a metodologia Feature Driven Development (FDD), que
construirá o produto com base nas suas funcionalidades, executando apenas as etapas
de planejamento e implementação dos requisitos.

DICA
Recomendamos a leitura do Trabalho de Conclusão de Curso com tema
Gerenciamento de Projetos & Segurança da Informação: os impactos da gestão
de projetos na segurança da informação. Acesse em: https://dspace.uniceplac.
edu.br/handle/123456789/1612.

Valente (2021) e Sommerville (2011) apresentam outras metodologias ágeis,

tais quais o eXtreme Programming (XP), voltado para aplicações que possuem muita
incerteza na definição de seus requisitos, podendo sofrer mudanças repentinas em suas
funcionalidades. Diferente do SCRUM, o XP é baseado em valores, princípios e práticas.

17
 Sommerville (2011) apresenta uma característica em comum entre a
metodologia XP e o framework SCRUM: a necessidade de envolvimento do cliente em
todo o processo, sendo o responsável pela implementação ou não de uma mudança
em uma funcionalidade já existente ou da implementação de novos requisitos, além de,
também, definirem a ordem de prioridade para a implementação de cada item analisado.

Pressman e Maxim (2021) pontuam que a metodologia XP é voltada para o

paradigma da orientação a objetos, se baseando em quatro atividades básicas:

• planejamento do que será executado (escrevendo as histórias de usuário e quais

serão os critérios de aceitação);
• projeto (com construção de protótipos);
• implementação do projeto;
• avaliação (testes unitários).

Quando cliente e o time de desenvolvimento atuam em conjunto, é possível

firmar um compromisso do que será entregue no próximo ciclo de trabalho, atendendo
às necessidades pontuadas pelo cliente.

DICA
Além das metodologias apresentadas, indico a leitura da dissertação de
mestrado de título Integração da abordagem Domain-Driven Design e da técnica
Behaviour-Driven Development no Desenvolvimento de Aplicações web. Acesse
em https://repositorio.ufscar.br/bitstream/handle/ufscar/7588/DissECSS.
pdf?sequence=1&isAllowed=y.

Acadêmico, neste tema de aprendizagem foram apresentados os principais

métodos para gestão de projetos. Para projetos que possuem etapas bem definidas e
que os envolvidos já conheçam bem como realizar cada fase, a metodologia simplificada
de gestão de projetos será mais adequada. Metodologias preditivas, por sua vez, irão se
focar mais na fase de planejamento, se preocupando com todos os detalhes antes que o
projeto, de fato, seja iniciado. Já com as metodologias ágeis, o projeto será subdividido
em pequenas entregas, que serão validadas e utilizadas pelo cliente que, por sua vez,
deverá participar ativamente de todo projeto.

18
 RESUMO DO TÓPICO 1
Neste tópico, você aprendeu:

• Um projeto deve ser um empreendimento limitado, voltado para construção de

um produto.

• O gerenciamento de projetos é fundamental para que um projeto consiga ser

guiado do início ao fim, com todos os recursos necessários sendo alocados e
liberados conforme acontece sua finalização.

• O Gerente de Projetos é uma peça fundamental para planejar, acompanhar e,

caso necessário, tomar as devidas atitudes para que o objetivo do projeto seja
alcançado.

• A execução de um projeto precisa da adoção de metodologias, conforme o tipo de

projeto e o resultado que se deseja atingir.

• As metodologias preditivas necessitam que uma etapa tenha sua conclusão para
que a próxima etapa seja iniciada, enquanto as metodologias ágeis não precisam
esperar que uma fase esteja completamente pronta para iniciar a próxima fase do
projeto.

19
 AUTOATIVIDADE
1 Um projeto poderá ser definido para a execução de atividades que requeiram um
planejamento e acompanhamento dos recursos e entregáveis. A ideia por trás de
todo projeto é que ele possa seguir etapas do início ao final, alcançando o objetivo
proposto em seu planejamento e, então, concluído. Sobre o papel do Gerente de
Projetos na condução de um novo projeto, assinale a alternativa CORRETA:

a) ( ) O Gerente de Projetos é responsável apenas pela comunicação com o cliente e

levantamento de suas necessidades para construção do produto.
b) ( ) O Gerente de Projetos é a pessoa responsável pela condução de todas as fases do
projeto, desde seu planejamento inicial até o acompanhamento de sua execução
e a entrega do produto ao cliente.
c) ( ) O Gerente de Projetos será o responsável apenas pelo planejamento e
documentação do projeto, não se preocupando com sua fase de execução.
d) ( ) O Gerente de Projetos será responsável pela mobilização e desmobilização da
equipe, apenas delegando a etapa de planejamento e execução para os membros
dessa equipe, que executará o projeto.

2 Um projeto será responsável pela execução de uma tarefa, entregue ao seu final.
Todas as etapas de um projeto irão ter o objetivo de definir quais as necessidades da
tarefa, o que é necessário para sua execução, e executar o planejado até se atingir o
objetivo inicialmente proposto. Uma característica de um projeto, portanto, é possuir
entregáveis. Com base em seus conhecimentos, analise as sentenças a seguir:

I- Um produto ou serviço pode ser considerado como entregável de um projeto.

II- Um entregável poderá ser qualquer artefato gerado pelo projeto, como sua
documentação.
III- Um entregável pode ser representado por um processo que acontecerá ao longo
das etapas do projeto.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) Somente a sentença I está correta.
d) ( ) Somente a sentença III está correta.

3 Métodos de gestão são importantes para garantir que um produto ou serviço,

elaborado através de um projeto, seguirá uma sequência lógica de etapas do início
a sua conclusão. Existem diferentes métodos que podem ser utilizados para gerir

20
 as etapas necessárias para um projeto. Considerando seus conhecimentos sobre
metodologias de gestão de projetos, classifique V para as sentenças verdadeiras e F
para as falsas:

( ) A metodologia simplificada de gestão de projetos tem o foco maior nas fases de

execução e entrega do projeto, sendo considerada minimalista em relação ao
planejamento.
( ) Métodos ágeis irão executar uma fase apenas após a conclusão da fase anterior,
sendo considerados como métodos tradicionais.
( ) Métodos ágeis se diferenciam da metodologia preditiva, já que o cliente poderá
receber versões parciais do produto e dar feedback sobre o que está sendo
construído.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 Metodologias para a Gerência de Projetos devem ser utilizadas para garantir a fluidez
necessária no desenvolvimento de um projeto, a partir de sua inicialização até a sua
conclusão. A escolha da metodologia, no entanto, dependerá de uma série de fatores,
como o conhecimento prévio da equipe sobre as tarefas que devem ser executadas
e como esta execução deverá acontecer, assim como o tipo de projeto que será
desenvolvido. Com base em seus conhecimentos e no texto apresentado, disserte
sobre o motivo pelo qual essa metodologia é conhecida como tradicional.

5 Existem projetos que são repetitivos e já possuem suas fases conhecidas e bem
definidas, sem muitas variações. Dessa forma, ao se deparar com um projeto
desse tipo, o Gerente de Projetos poderá escolher a utilização de uma metodologia
específica para a gestão e acompanhamento do projeto específico. Disserte sobre a
metodologia mais adequada para à situação apresentada e o porquê.

21
22
UNIDADE 1 TÓPICO 2 - T
GESTÃO DE CONFIGURAÇÕES

1 INTRODUÇÃO
Acadêmico, neste tema de aprendizagem abordaremos os principais conceitos
sobre a gerência de configuração, como identificar uma configuração que necessita de
gerência e quais as formas de realizar controle de versão.

Segundo Pressman e Maxim (2021) e Sommerville (2011), é fundamental que

o trabalho da equipe que está envolvida em um projeto possa ser armazenado em
local seguro, evitando, assim, retrabalho e prejuízos financeiros, devido ao atraso no
cronograma de entrega e mais tempo necessário de alocação dos recursos (pessoas
e equipamentos). Além de garantir um armazenamento seguro, os repositórios de
armazenamento irão realizar uma função importante: o controle de versão, possibilitando
realizar um rastreamento de todas as alterações que foram efetuadas, quem as executou,
quando foram implantadas.

Também iremos abordar os conceitos de integração e entrega contínua em um

projeto, além de como o processo de gerenciamento de mudanças deverá ser feito. Um
processo de entrega manual de um pacote ou versão de uma aplicação está suscetível
a muitos problemas, já que possui a dependência direta de uma pessoa, que deverá
executar minuciosamente cada passo necessário para a implantação. A falha em um
dos passos resultará em erros ou comportamentos inesperados.

Ao final deste tema de aprendizagem, iremos aprender a importância de uma

implantação automatizada em detrimento a uma implantação manual de software em
um ambiente, assim como os passos necessários para realizar o controle de mudanças
e o processo de entrega.

Apresentaremos também o conceito de configurações e como identificar quais

as configurações que necessitarão de acompanhamento ao longo de um projeto.
Abordaremos o conceito de integração e entrega contínua e como este processo poderá
ser planejado e executado.

2 CONCEITO E IDENTIFICAÇÃO DE CONFIGURAÇÕES

Segundo Humble e Farley (2014), as configurações de um software ou aplicação
representam as características básicas desse software, em termos de infraestrutura
e requisitos funcionais ou não funcionais. Requisitos funcionais são aqueles que

23
 representam um serviço ou uma função provida pelo sistema, ou seja, tudo aquilo que
o usuário poderá executar, como os cadastramentos, extração de relatórios, dentre
outros exemplos. Já os requisitos tidos como não funcionais irão prover um suporte aos
requisitos funcionais, relacionados a questões de segurança, de auditoria, performance,
podendo englobar um ou mais dos requisitos funcionais disponíveis na aplicação.

Pressman e Maxim (2021), por sua vez, afirmam que as informações resultantes
dos processos de software constituem o conjunto das configurações desse software.
Essas informações podem se enquadrar nas categorias de programas de computador
(código fonte e executável), manuais de usuário ou documentos que descrevam a
aplicação construída e os dados mantidos pelo programa.

Todo projeto deverá ter suas configurações devidamente identificadas e

documentadas, de modo que, caso necessário, a aplicação resultante possa ser
replicada para um novo ambiente, quantas vezes forem necessárias.

Acadêmico, abordaremos os detalhes sobre o processo de identificação e

gerenciamento de configurações nos próximos subtemas. Também abordaremos
como o gerenciamento das configurações poderá ser planejado e executado e a sua
importância.

2.1 CONCEITO E IDENTIFICAÇÃO DE CONFIGURAÇÕES

Pressman (1995) define itens de configuração como tudo que é produzido a
partir das fases de desenvolvimento de um software, englobando toda documentação, a
especificação de requisitos, o plano de testes da aplicação e o próprio código produzido.
Muitas equipes incluem ferramentas de terceiros necessárias para o projeto, como
itens de configuração, armazenando versões específicas importantes para garantir o
funcionamento do produto.

Humble e Farley (2014) afirmam que todos os resultados do processo de

engenharia de software, também conhecidos como artefatos, serão considerados como
itens de configuração que deverão ser gerenciados ao longo do andamento do projeto.

Segundo Pressman e Maxim (2021), o objetivo de se gerenciar itens de

configuração é que mudanças podem e irão ocorrer em algum momento na aplicação,
precisando ser controladas para que o software não tenha sua qualidade prejudicada
com o passar do tempo.

A Figura 5 apresenta um resumo de artefatos do projeto que são considerados

itens de configuração. Configurações do ambiente no qual a aplicação executará,
documentos gerados durante as fases de engenharia de software do projeto, o próprio
código fonte construído pela equipe de desenvolvimento, o plano de testes e os

24
requisitos da aplicação irão compor o conjunto dos itens de configuração que deverão
ser gerenciados. Qualquer alteração em um desses itens deverá ser devidamente
documentada e analisada, garantindo que a aplicação refletirá as mudanças necessárias,
seguindo as boas práticas recomendadas.

Figura 5 – Resumo dos itens de configuração de um projeto

Fonte: adaptada de Humble e Farley (2014)

Pressman e Maxim (2021) apresentam o conceito de objeto de configuração

como sendo um conjunto de itens de configuração agrupados por categorias, como
especificação de desing (do inglês DesignSpecification), modelo de dados (do inglês
DataModel), componentes, código fonte (do inglês SourceCode) e especificação de
testes (do inglês TestSpecification). Estes conjuntos podem ser relacionados entre si,
sendo interdependentes.

Abordaremos a importância do processo de gerência de configuração e como

ele poderá ser implantado em uma Organização no próximo subtema.

2.2 PROCESSO DE GERÊNCIA DE CONFIGURAÇÃO

Sommerville (2011) afirma que o processo de gerenciamento de configurações
é importante para qualquer tipo de projeto, com o intuito de se manter um histórico das
mudanças que foram realizadas, quando elas aconteceram e quais seus respectivos
autores, considerando que há o risco de esquecimento dos ajustes efetuados
com o passar do tempo, além da tendência de as equipes trabalharem de forma
geograficamente distribuídas, necessitando controlar todas as contribuições feitas por
todos os colaboradores.

25
 O gerenciamento de configurações irá indicar a forma como a evolução de um
produto de software deverá acontecer, considerando as etapas de desenvolvimento
e manutenção, ao longo do ciclo de vida do produto (HUMBLE; FARLEY, 2014). O
processo de gerenciamento de configurações deverá identificar, de forma única, todos
os artefatos importantes ao projeto, indicando a forma como eles serão armazenados e
recuperados, assim como seus respectivos relacionamentos.

Esses autores contextualizam ainda que, para que o gerenciamento de

configurações aconteça, é necessário que todas as configurações que serão geridas
possam ser identificadas, incluindo componentes individuais, com o objetivo de
identificar qualquer alteração nessas configurações e realizar o devido controle das
modificações.

Segundo Pressman e Maxim (2021), mudanças podem acontecer a qualquer

momento, necessitando de etapas bem definidas para seu gerenciamento, tais quais
a identificação da mudança, o controle da alteração (através de sua documentação),
a execução da alteração e a comunicação dos ajustes efetuados aos interessados no
projeto.

Conforme explicado por Tuffley (2017), o gerenciamento de configurações

irá se basear em dois aspectos importantes, o planejamento e a implementação. O
planejamento irá englobar questões importantes para o projeto que será executado,
como o escopo, objetivos, gerenciamento de políticas, dentre outros. Os aspectos
de implementação, por outro lado, deverão seguir um plano de gerenciamento de
configurações e mudanças.

A maneira de conduzir o gerenciamento das configurações de um projeto, que

compreende o processo evolutivo do sistema em questão, também irá definir a interação
entre os membros da equipe de desenvolvimento, ditando a colaboração da equipe com
o projeto, o que é fundamental para seu sucesso.

Segundo Humble e Farley (2014), adotar uma boa estratégia de gerenciamento

irá depender da resposta a algumas questões balizadoras importantes:

• É possível reproduzir um ambiente exatamente como ele está configurado?

• É possível efetuar alterações em itens individuais e replicar estas alterações em
outros ambientes que possuam esses mesmos itens?
• É possível realizar o rastreio de mudanças que aconteceram e quando foram
executadas, além de quem as fez?
• Os requisitos de conformidade com as leis e normas internas podem ser satisfeitos?
• As mudanças e informações sobre o projeto podem ser encontradas facilmente
pelos membros da equipe e serem implementadas sem dificuldade?

26
 Segundo Pressman e Maxim (2021), é preciso identificar qual o gatilho que
originou a mudança que será implementada, sendo alguns exemplos:

• alteração nos negócios da empresa ou na dinâmica do mercado, definido alterações

nas regras do comércio;
• patrocinadores com necessidades distintas das informadas originalmente,
acarretando modificações nas informações e dados armazenados e/ou produzidos
pela aplicação;
• reestruturação organizacional, causando ajustes nas priorizações dos requisitos do
projeto ou na composição da equipe de desenvolvimento;
• limitações no prazo de entrega ou orçamento, refletindo em ajustes no produto.

Ao iniciar um projeto, os itens que deverão ser gerenciados podem ser resumidos
conforme apresentado na Figura 6:

Figura 6 – Itens que devem ser gerenciados em uma aplicação

Fonte: adaptada de Tuffley (2017)

As configurações apresentadas na Figura 6 devem ser geridas para que

suas respectivas alterações possam ser rastreadas, quando necessário. Os itens
de configuração do ambiente, considerados requisitos iniciais da aplicação, devem
englobar, por exemplo, o sistema operacional do servidor da aplicação e sua respectiva
versão, eventuais bibliotecas ou variáveis de ambiente que precisarão ser configuradas
para o correto funcionamento da aplicação. No que diz respeito à aplicação, os itens
que deverão ser gerenciados compreendem seu código fonte, o plano de testes dos
requisitos da aplicação, os requisitos mapeados para o software, assim como as versões
entregues ao cliente.

27
 Figura 7 – Fases macro do processo de gerenciamento das configurações

Fonte: adaptada de Sommerville (2011)

A Figura 7 apresenta os passos macros, ou seja, em nível mais abstrato, do

processo de gerenciamento de configurações. O primeiro passo será identificar (ou
mapear) os itens de configuração considerados gerenciáveis, ainda no processo
de planejamento ou execução do projeto. Após a identificação, os itens deverão ser
aplicados em seus respectivos ambientes, como uma versão inicial. Por fim, é feito o
gerenciamento, identificando e mantendo o histórico de eventuais alterações, quem fez
e quando fez.

O processo de gerenciamento das configurações é essencialmente importante

para manter em funcionamento uma aplicação, tendo em vista que, caso falhas
aconteçam após a aplicação de uma alteração em uma configuração, o comportamento
anterior ao momento da falha poderá ser revertido, já que o histórico da configuração
alterada é preservado.

A Figura 8 apresenta os tipos de configuração que podem ser gerenciadas, de

acordo com o tipo de servidor e o nível de abstração.

Figura 8 – Tipos de configurações gerenciáveis

Fonte: adaptada de Humble e Farley (2014)

28
 A Figura 8 apresenta um resumo dos tipos de configurações que podem ser
gerenciáveis nos diferentes tipos de servidores que dão suporte a uma aplicação.
Uma aplicação WEB, por exemplo, voltada para a utilização através da Internet, terá os
servidores de aplicação, banco de dados (para questão de armazenamento dos dados
fornecidos pelos usuários) e de infraestrutura, os quais darão todo suporte indispensável
para que a aplicação possa ser publicada na WEB e utilizada com o nível de segurança
necessário.

Em todos os tipos de servidores, questões de hardware são comuns, sendo

necessário que todos possuam as mesmas características de equipamentos físicos,
como quantidade de memória, fornecedor dos componentes e quantidade de espaço
em disco. A versão do sistema operacional também deve ser a mesma para todos
os ambientes, inclusive com instalação dos módulos necessários para execução da
aplicação e configuração das variáveis de ambiente.

Com configurações equalizadas, um desenvolvedor poderá encontrar e simular

eventuais problemas em produção, sem a necessidade de precisar criar um ambiente
paralelo apenas para realização de um teste, o que irá aumentar a produtividade da
equipe e aumentar o nível de satisfação do cliente com menos bugs descobertos
quando a aplicação estiver em ambiente de produção.

O processo de automação de um pipeline de integração deve considerar os

aspectos de hardware e software para que a implantação automatizada da aplicação
possa ser feita. Então, aspectos como a maneira pela qual novas configurações serão
implantadas (ou alteradas) e como o gerenciamento da infraestrutura será feito, devem
ser considerados para que a automação possa trazer benefícios, de fato.

Humble e Farley (2014) explicam que, para que o processo de entrega e

integração contínua seja configurado e mantido com sucesso, é necessário que o
gerente de configurações, juntamente com o gerente de projetos, possam mapear e
armazenar todas as configurações do processo de instalação do sistema operacional,
das ferramentas utilizadas para controle de versão e processo de automação de
implantação, dentre outras configurações que sejam importantes para a configuração
de um novo ambiente operacional, caso necessário.

Todas as configurações envolvidas na montagem do ambiente operacional,

como as anteriormente mencionadas, fazem parte dos dados de entrada para o pipeline
de implantação, juntamente com o código da aplicação que será implantado.

29
 ESTUDOS FUTUROS
Apresentaremos os detalhes e conceitos sobre o pipeline de implantação em
momento futuro. Por hora, é preciso entender apenas que ele representa
uma sequência de operações automatizadas para que uma nova versão da
aplicação seja implantada em um ambiente operacional.

Segundo Tuffley (2017), todo processo de gerenciamento de configurações

deverá ser mapeado pela própria equipe de desenvolvimento, durante as fases
iniciais do projeto, sendo repassado à equipe de operação, após a implementação em
ambiente de desenvolvimento. O momento da passagem de responsabilidade sobre os
parâmetros do ambiente operacional para a equipe de operação deve acontecer antes
da implantação da primeira versão da aplicação em ambiente de produção.

INTERESSANTE
É possível que duas ou mais aplicações compartilhem as mesmas
configurações de ambiente operacional, como sistema operacional,
variáveis de ambiente e bibliotecas. Nesse caso, é preciso criar scripts de
automação separados para cada aplicação, garantindo que uma alteração
em uma das configurações operacionais reflita apenas nas aplicações que
delas dependerem.

É esperado que, em algum momento, o projeto tenha que lidar com o controle
de mudanças e configurações. Apresentaremos como essas mudanças poderão ser
requisitadas e gerenciadas no próximo subtema.

2.3 CONTROLE DE MUDANÇAS EM PROJETOS E

CONFIGURAÇÕES
Neste subtema, iremos abordar como acontece a prática para o controle de
mudanças em projetos e configurações, apresentando os principais conceitos para o
controle de versões.

Equipes que possuem o gerenciamento das mudanças nas funcionalidades de

suas aplicações poderão, de forma fácil, reverter situações que causem problemas no
momento da implantação de uma nova versão. Esta manobra, porém, requer que um
controle de versões seja feito, para que, o histórico da mudança efetuada, em que data
e por quem foi feita, seja mantido e acessado quando necessário.

30
 O processo de auditoria também requer que essas informações sejam
armazenadas, efetuando um rastreamento de todas as alterações ocorridas na
aplicação, desde sua primeira versão até as versões atuais.

Acadêmico, abordaremos sobre a importância do controle de versões e quais

configurações poderão se beneficiar dessa estratégia. Discorreremos, ainda, sobre o
controle de mudanças em itens de configuração de um projeto.

2.3.1 Controle de versões

Para garantir que todos os itens gerenciáveis em um projeto possam ser
devidamente controlados, de modo a manter o histórico e, em caso de necessidade,
conseguir reverter a versões anteriores, ferramentas voltadas para o controle de versão
poderão ser utilizadas. Existem diferentes tipos de ferramentas voltadas para esse
propósito, mas iremos abordar, neste momento, a parte conceitual envolvida nessa
questão.

ESTUDOS FUTUROS
Acadêmico, apresentaremos as principais ferramentas para controle de
versão em outro momento, durante esta disciplina.

Antes de adotar qualquer ferramenta para a gerência do controle de versão

de um projeto, é importante que o conceito do que representa uma versão de um
produto ou aplicação seja corretamente definido. Saber quais as configurações e o que
representa uma versão de uma aplicação poderá, por exemplo, definir quais arquivos do
código fonte deverão ser armazenados pela ferramenta de gerenciamento de versões,
quais configurações do ambiente se enquadram como fundamentais para a reprodução
de uma versão da aplicação em um ambiente diferente do que está gerando essas
informações, além de quais ajustes e evoluções foram feitos para cada nova versão da
aplicação, quando foram feitas e por quem.

De acordo com Tuffley (2017), é considerado como controle de versão o

procedimento executado para manter e, futuramente, recuperar o histórico do processo
evolutivo de uma configuração, como acontece com as manutenções evolutivas em
um código fonte. Ao gerar a primeira versão de um código fonte para uma determinada
funcionalidade, a equipe de desenvolvimento poderá armazenar este código em um
repositório, de modo que, caso correções ou evoluções sejam executadas neste arquivo
armazenado, será possível saber, com exatidão, quais trechos foram modificados, quem
executou essas modificações e quando foram feitas.

31
 É possível realizar um controle de versão para todos os entregáveis de um
projeto, como sua documentação, os requisitos mapeados inicialmente, além do plano
de testes do projeto. Sem a realização desse versionamento, caso algum incidente de
segurança aconteça e, como consequência, um documento seja alterado de maneira
não autorizada, seria bem difícil conseguir recuperar sua versão correta, anterior ao
momento da modificação indesejada. Então, a gestão de configurações através da
utilização de controle de versão se mostra importante para que o projeto possa continuar
de maneira saudável, sem eventuais contratempos com retrabalhos ocasionados pela
perda de informações importantes que não puderam ser recuperadas.

Segundo Humble e Farley (2014), apesar da importância, não é imprescindível

que ferramentas apropriadas para a realização do controle de versão sejam adotadas
em um projeto. É possível que o controle de versão aconteça através da realização de
backups constantes e armazenados em máquinas diferentes das que deram origem aos
arquivos, mas é fundamental que haja uma política de backup bem institucionalizada e
sólida para que o controle das versões consiga ser feito da melhor forma.

ATENÇÃO
O conceito de controle de versão deverá englobar, absolutamente, todos
os passos e configurações necessários para que se consiga reproduzir um
clone de um ambiente de produção em um outro servidor ou máquina,
com todas as configurações de ambiente (como sistema operacional e
variáveis de ambiente) para a execução da aplicação. Portanto, não se
limita apenas ao armazenamento de versões do código fonte.

Pressman e Maxim (2021) afirmam que o processo de gestão de configuração

de software (SCM) deve envolver cinco tarefas:

• identificação dos itens que serão gerenciados;

• controle de versão dos itens previamente identificados;
• controle de alteração, quando necessário;
• auditoria de configuração;
• relatos para as partes interessadas no projeto sobre os itens que estão sob
gerenciamento da configuração.

Segundo Sommerville (2011), é fundamental a utilização de ferramentas

disponíveis no mercado para a realização do controle de versão dos itens de configuração,
tendo em vista que essas ferramentas irão identificar, armazenar, realizar o devido
controle de acesso, além de registrar o histórico de alterações.

32
 DICA
Uma das ferramentas em evidência, na atualidade, para a execução do
controle de versões é a Git digo aberto e funcionamento distribuído.
Acesse em: https://git-scm.com/.

Outra ferramenta bastante popular é a Apache Subversion, também de

código aberto. Acesse em: https://subversion.apache.org/.

ESTUDOS FUTUROS
Traremos outras ferramentas focadas em controle de versão na Unidade
3 desta disciplina.

A utilização das ferramentas que promovem o controle de versão será

fundamental para realizar o controle de mudanças, apresentado no próximo subtema.

2.3.2 Controle de mudanças

Segundo Pressman e Maxim (2021), uma vez que uma aplicação é construída,
ela sofrerá mudanças constantes ao longo de seu processo evolutivo. Essas mudanças
precisam ser analisadas, aprovadas e documentadas, tendo em vista que a falta de
controle das alterações pode gerar caos em um projeto.

Sommerville (2011) afirma que, caso novas funcionalidades de uma aplicação

sejam requisitadas pelo cliente, a implementação e integração desses requisitos devem
acontecer a partir da criação de uma nova versão da aplicação. Caso não exista um
controle efetivo das funcionalidades que são inseridas em cada nova versão criada para
a aplicação, se torna tarefa difícil conseguir gerenciar quais as alterações foram feitas
em cada versão, como quais bugs foram corrigidos e em qual versão, podendo acarretar
equívocos no momento de uma nova manutenção, como alterar a versão errada para
corrigir um bug que foi descoberto em versão diferente.

Tanto Pressman e Maxim (2021) quanto Sommerville (2011) chamam atenção

para a importância de implementação de técnicas que realizem o controle de mudanças
de forma efetiva, de modo que uma alteração feita em uma versão da aplicação não
interfira em suas demais versões, assim como o trabalho de um membro do time de
desenvolvimento não deve interferir no trabalho dos demais membros.

33
 Segundo CMMI (2017), se faz necessária a formação de um Comitê de Aprovação
das Mudanças, com o intuito de avaliar os impactos das alterações efetuadas em uma
aplicação, podendo aprovar ou rejeitar tais solicitações. O intuito desse grupo é manter a
aplicação íntegra em todo seu ciclo de vida. A aprovação de uma mudança só acontecerá
caso a requisição de mudança satisfaça aos critérios estabelecidos pelo cliente para a
próxima versão (ou release) da aplicação, ou seja, apenas as que, efetivamente, irão
agregar valor ao negócio do cliente.

Então, para que uma mudança em uma aplicação aconteça, é necessário que
alguns passos possam ser seguidos, garantindo a rastreabilidade dessa mudança,
conforme apresentado na Figura 9.

Figura 9 – Etapas do ciclo de mudanças

Fonte: adaptada de Pressman e Maxim (2021) e PMI (2017)

A Figura 9 apresenta as etapas básicas para a execução de um ciclo de mudanças

em uma aplicação. Uma vez que o cliente identifique uma mudança, conforme suas
necessidades, uma nova requisição de mudança deverá ser criada, sendo analisada e
implementada pelo time de desenvolvimento, que irá criar uma versão da aplicação para
incorporar essa solicitação. Ao final da codificação, o Comitê Gestor de Mudanças deverá
analisar as requisições de mudança abertas e, caso atendam e agreguem valor ao
negócio do cliente, aprovar para que a versão criada seja disponibilizada em produção.

34
Caso não seja de interesse do cliente que a funcionalidade se torne disponível, o Comitê
irá reprovar a mudança, informando às partes interessadas sobre a postergação para
distribuir a release contendo a modificação.

Conforme apresentado por Morais e Zanin (2017), existem três fatores que
podem desencadear a necessidade de mudança em uma aplicação:

• correção de bug encontrado, sendo denominada manutenção corretiva, se

tornando, muitas vezes, um impedimento ao uso da aplicação pelo usuário;
• ajustes de desempenho da aplicação. neste cenário, busca-se otimizar o código da
aplicação para prover um melhor desempenho ao cliente ou para facilitar o processo
de manutenção do código pelo time de desenvolvimento. as refatorações de código
se enquadram nessa categoria;
• adaptação de uma funcionalidade já implementada para atender a mudanças
em seu ambiente operacional ou regras de negócio, denominada manutenção
adaptativa. a característica deste tipo de mudança é que, em muitos casos, não
provém de uma solicitação do cliente, mas de uma imposição proveniente de fatores
externos, como mudança em Leis, regras de cálculo tributários ou formato de dados
de entrada mantidos pela aplicação.

Segundo Pressman e Maxim (2021), para cada solicitação de alteração feita para
uma aplicação, um relatório contendo a análise de impacto da alteração no software,
os prós e contras da implementação, os custos envolvidos na execução do processo de
mudança e o eventual impacto sobre outras funcionalidades ou itens de configuração
do sistema devem ser descritos e detalhados, para dar subsídios ao Comitê de avaliação
para aprovar ou não a mudança.

Filho (2019) explica que uma mudança não é somente um ajuste no código
ou uma mera inclusão de uma nova funcionalidade, pois irá refletir diretamente no
negócio, alterando as regras que serviram de base inicial para construção do produto.
Essa característica de alteração no negócio é o que difere uma solicitação de mudança
de uma manutenção corretiva ou adaptativa, por exemplo.

ATENÇÃO
Pressman e Maxim (2021) apresentam a necessidade de controle de
versão para as versões (ou releases) da aplicação que são criadas com
a inclusão de uma nova mudança aprovada. O versionamento irá garantir
duas características importantes para a gestão de configuração: controle de
acesso e de sincronização. É preciso garantir que apenas os membros do time
do projeto e as partes interessadas (patrocinadores) terão acesso às versões
geradas da aplicação, assim como evitar que as colaborações dos diferentes
membros do time não interfiram (nem sofram interferência) das efetuadas por
outros membros.

35
 Acadêmico, no próximo subtema estaremos abordando o processo de integração
e entrega contínua, muito importantes para a disponibilização em produção (ou demais
ambientes operacionais) de manutenções implementadas e aprovadas.

3 INTEGRAÇÃO E ENTREGA CONTÍNUA

Configurações de um software ou aplicação representam as características
básicas deste software, em termos de infraestrutura e requisitos funcionais ou não
funcionais. Requisitos funcionais são aqueles que representam um serviço ou uma
função provida pelo sistema, ou seja, tudo aquilo que o usuário poderá executar, como os
cadastramentos, extração de relatórios, dentre outros exemplos. Já os requisitos tidos
como não funcionais irão prover um suporte aos requisitos funcionais, relacionados a
questões de segurança, de auditoria, performance, podendo englobar um ou mais dos
requisitos funcionais disponíveis na aplicação.

Segundo Humble e Farley (2014), é comum que o processo de entrega de

versões manuais apresente falhas durante a execução desta entrega, o que poderá
comprometer o tempo de toda a equipe, além de, caso algum problema seja encontrado
durante a execução, ter a implantação da versão cancelada.

Acadêmico, abordaremos os detalhes sobre o processo de identificação e

gerenciamento de configurações nas próximas subseções, assim como o processo de
implantação, também conhecido como pipeline de implantação e como montar um
ecossistema de entrega contínua, apresentando sua importância para o processo de
CI/CD.

3.1 O PROCESSO DE ENTREGA E INTEGRAÇÃO CONTÍNUA

Ao longo do desenvolvimento de uma aplicação, uma equipe poderá ter seus
membros atuando em diferentes partes do código do software, seja na construção
de uma nova funcionalidade ou na manutenção de um trecho específico. Enquanto
a aplicação não estiver totalmente pronta, estas partes construídas separadamente
poderão não ser testadas em conjunto, no ambiente que será utilizado para seu
funcionamento final (também conhecido como ambiente de produção).

Humble e Farley (2014) explicam que, a partir do momento em que todos os

módulos (ou funcionalidades) diferentes precisam ser integrados para comporem a
aplicação que será entregue, se dá o processo de integração. Este processo deverá
acontecer, inclusive, com eventuais aplicações de terceiros (como webservices) que
são acessadas e trocam informações com o software que está no processo de entrega.

36
 Sommerville (2011) define a integração contínua como o ato de integrar uma
mudança implementada em uma aplicação ao código do software principal (que será
implantado em um ambiente operacional, como o de produção). A partir do momento que
a integração é feita, os testes de integração e demais testes (como os unitários) para a
funcionalidade integrada deverão ser realizados e os resultados devem ser compatíveis
com o esperado, ou seja, a nova parte integrada não deve interferir negativamente em
funcionalidades que já apresentavam o comportamento esperado, e deve produzir os
resultados coerentes com a sua especificação.

Segundo Pressman e Maxim (2021), o processo de integração contínua deverá

unificar o trabalho de todos os desenvolvedores do time, auxiliando a identificar eventuais
problemas de compatibilidade entre as soluções construídas e permitir que testes sejam
realizados, possibilitando encontrar e corrigir problemas antes que a versão integrada
possa ser disponibilizada ao usuário final.

De acordo com Tuffley (2017), o processo de entrega e integração contínua

também é conhecido pela sigla CI/CD, acrônimo para Continuous Integration/
Continuous Delivery, que irá fazer uso de monitoramento e automação em todas as
etapas do ciclo de vida da aplicação, desde o início do ciclo de desenvolvimento até o
final, com a disponibilização do código em ambiente produtivo. É importante mencionar
que as etapas de testes e validação estão inclusas no processo do CI/CD.

Conforme apresentado por Humble e Farley (2014), o processo de Integração

Contínua (CI) irá englobar o processo de codificação, testes e envio do código ao
repositório que está gerindo o código da aplicação, consolidando com os códigos
desenvolvidos pelos demais membros da equipe. Já o processo de entrega contínua
(CD), terá relação com a implantação do código que está armazenado no repositório da
aplicação em ambiente produtivo.

Em um projeto cuja entrega de versão é feita de forma manual, diferentes

problemas inesperados podem acontecer ao longo desse processo, podendo culminar
com o cancelamento da versão que será implantada, com a consequente restauração
do ambiente a um estado anterior ao da atualização. Este risco se dá, dentre outros
fatores, por etapas de atualização descritas de forma manual que, a cada nova entrega,
precisarão ser estritamente seguidas para que nenhum problema ocorra. Então, ajustes
nas configurações do ambiente operacional, caso não sejam totalmente documentadas,
podem ocasionar um comportamento inesperado da aplicação, cancelando a
implantação ou tornando o processo de entrega árduo e extremamente custoso para a
equipe.

A simples execução de testes manuais, que necessitam do parecer de um

membro da equipe para atestar que as funcionalidades estão com o comportamento
adequado ao esperado, já apresenta um ponto de falhas no processo de implantação

37
 de uma nova versão. Com testes automatizados, por outro lado, é possível repetir todos
os passos necessários para que uma funcionalidade seja considerada pronta para ser
implantada, de forma automática, sem erros humanos.

Neto (2022) conceitua como pipeline DevOps o processo de automação da

implantação em produção de uma versão da aplicação, de forma rápida e garantindo
a estabilidade e qualidade da versão implantada. Também chama atenção para a
inexistência de um pipeline padrão, de modo que cada Organização poderá definir as
etapas do seu pipeline de implantação de acordo com as tecnologias e ferramentas
disponíveis em seu ambiente operacional.

Abordaremos o pipeline de implantação com mais detalhes no próximo subtema.

3.2 O PIPELINE DE IMPLANTAÇÃO

Neto (2022), Humble e Farley (2014) afirmam que, para uma mudança em uma
configuração ser implantada em produção, é necessário percorrer uma sequência
de passos, conhecida como pipeline de implantação ou pipeline DevOps. Cada
Organização poderá definir os passos necessários para a sua realidade, mas as etapas
devem conter, de forma genérica, os arquivos binários necessários para implantação,
assim como os scripts de testes em diferentes níveis, como testes unitários, testes de
aceitação e a entrega da versão.

Sommerville (2011) apresenta um conceito importante para a gestão de

configuração e o pipeline de implantação: a definição de baselines. Uma linha base
(ou baseline) irá representar um conjunto de componentes que irão incidir, de forma
integrada, uma versão da aplicação. Esta versão deverá conter todos os documentos
necessários para sua implantação, tais quais:

• documentos de arquitetura, implantação e o plano de gerenciamento de

configuração elaborado;
• documento contendo as permissões das pastas e dos perfis de acesso, assim como
documentos contendo as regras de negócio implementadas e controle de versões
implantadas;
• documentos relacionados ao projeto, como o plano de projeto, documentos que
auxiliaram na estimativa de esforço e custos e documentos relacionados ao
processo de negócio.
• plano de testes e os checklists de avaliações efetuadas;
• documentos de encerramento do projeto.

Gonçalves et al. (2019) afirma que as baselines irão ser definidas em cada etapa
do projeto, apresentando documentos diferentes, conforme a fase atual que o projeto
se encontra, mas seguindo os documentos listados anteriormente.

38
 Segundo Humble e Farley (2014), os objetivos para a construção de um pipeline
de implantação são:

• Tornar o processo de implantação visível a todos os envolvidos – cada

participante do projeto terá a visão completa de todas as etapas existentes no
projeto até a entrega da versão em produção.
• Melhoria na identificação de erros durante o processo – como os passos são
automatizados, então um erro irá se tornar visível, o que poderá facilitar sua pronta
correção pela equipe.
• Facilidade na implantação de uma versão em qualquer ambiente já preparado
para a aplicação – é possível configurar o processo de automação para implantar
qualquer versão já gerada da aplicação em quaisquer de seus ambientes (produção,
homologação, desenvolvimento), sendo necessário apenas informar qual o ambiente
sofrerá a atualização e qual versão será implantada.

Figura 10 – Exemplo de etapas de um pipeline de implantação

Fonte: adaptada de Neto (2022)

A Figura 10 apresenta um exemplo de um pipeline simples para a entrega de

versão. As etapas de testes automatizados poderão se desdobrar em uma ou mais,
desde que consigam ser feitas de maneira automática, com a execução de scripts pré –
construídos. O fluxo apresentado irá, ao seu final, implantar as alterações obtidas a partir
do repositório de código fonte utilizado pela equipe no ambiente escolhido no momento
de sua execução.

Pressman e Maxim (2021) apresentam o processo de integração contínua como

parte essencial das metodologias ágeis, como a XP, sendo uma estratégia adotada
para possibilitar o que se conhece como teste fumaça, realizado diariamente com o
intuito de avaliar versões da aplicação criadas contendo as modificações recentemente
integradas pelo time, sendo útil para identificar problemas nas novas implementações
e, também, servindo de termômetro de avaliação da aplicação pelos desenvolvedores.

Ainda segundo Pressman e Maxim (2021), podemos listar alguns benefícios da

execução dos testes fumaça:

• redução dos riscos com a integração das funcionalidades agrupadas, já que a

recorrência diária dos testes irá possibilitar a identificação e tratamento de eventuais
problemas encontrados;

39
 • melhoria na qualidade da aplicação final entregue. já que problemas poderão ser
facilmente detectados, correções também poderão ser imediatamente aplicadas,
evitando que estes problemas perdurem na aplicação;
• correção de bugs se torna mais simples. se a periodicidade diária for respeitada para
execução dos testes fumaça, os erros que forem detectados estarão ligados aos
novos códigos integrados à aplicação, o que facilita o processo de correção;
• progresso da aplicação pode ser avaliada melhor. Como as funcionalidades vão
sendo integradas aos poucos e testadas, garantindo seu funcionamento, se torna
mais perceptível ao time e aos interessados que há progresso no desenvolvimento
da aplicação e andamento do projeto como um todo.

Quanto maior for o tempo levado para desenvolvimento de um pacote de

funcionalidades por uma equipe, mais chances terão de serem encontradas falhas
no momento da integração dessas funcionalidades e implantação em ambiente de
homologação, para validação pelo cliente (ou partes interessadas). Então, aplicações
que fazem uso de metodologias tradicionais, nas quais uma nova etapa só será iniciada
após a conclusão total da etapa anterior, poderão ter impactos maiores, quanto a
problemas de integração, do que projetos que fizeram uso de metodologias ágeis, nos
quais os ciclos de desenvolvimento são mais curtos e as entregas mais frequentes.

Conforme explicam Humble e Farley (2014), para cada alteração realizada em

um item de configuração gerenciável da aplicação (como configurações de ambiente ou
alterações no código fonte), uma nova instância do fluxo deverá ser criada, de modo que
todos os passos sejam executados, na ordem definida, para o ambiente escolhido no
momento da criação desta nova instância. Com isso, é possível realizar atualizações em
paralelo, em diferentes ambientes da aplicação, bastando que diferentes instâncias do
fluxo sejam criadas e configuradas para implantarem em todos os ambientes desejados.

É importante mencionar que faz parte do processo de integração e entrega

contínua a homogeneização dos ambientes nos quais a aplicação poderá ser executada,
como ambiente de desenvolvimento, homologação e produção. Um dos fatores cruciais
para a ocorrência de erros e falhas no processo de entrega manual de uma versão são
as diferenças entre as configurações dos diversos ambientes, que incluem diferenças
nas versões do sistema operacional implantado, nas variáveis de ambiente e, inclusive,
nas versões do servidor de banco de dados. Para que haja a minimização dos problemas
com implantação, a automação irá ter como premissa inicial que todos os ambientes
são estritamente iguais, com as mesmas bibliotecas instaladas, mesmos parâmetros de
configuração, mesmas versões para servidores de aplicação WEB e de banco de dados.

Segundo Pressman e Maxim (2021), uma versão criada com mudanças aprovadas
e que passaram nos testes de avaliação é denominada de versão candidata. É preciso
que a avaliação de uma versão candidata seja baseada em casos de teste desenvolvidos
juntamente com os protótipos funcionais da aplicação. Além da validação de requisitos
funcionais, é necessário que sejam realizados testes em requisitos não funcionais,
como avaliação de desempenho, auditoria, segurança ou usabilidade da aplicação.

40
 Pressman e Maxim (2021) ainda afirmam que, caso falhas ou bugs sejam
detectados ao se realizar os testes nas versões candidatas, é necessário que estas
falhas sejam documentadas, criando, assim, uma base de conhecimento. Existem
ferramentas disponíveis no mercado voltadas para a documentação dos problemas
detectados, permitindo que o time acompanhe suas respectivas correções.

De acordo com Humble e Farley (2014), a automação do processo de CI/CD terá

vantagem especial para os projetos nos quais a implantação de uma nova versão é feita
de forma manual, aumentando o risco a cada nova entrega. Com um processo manual
ocorrendo, a possibilidade de falhas acontecerem ao longo das etapas de entrega, e de
não serem corrigidas a tempo, é alta. Cada problema encontrado aumentará o risco de
a entrega não acontecer em tempo hábil, como planejado, ocasionando retrabalho por
parte da equipe de desenvolvimento e, em casos mais extremos, prejuízo financeiro com
eventuais multas ou descumprimento de acordos firmados com o cliente (ou demais
partes interessadas).

Gonçalves et al. (2019) afirma que é necessário que um plano de gestão de

configuração seja criado, de modo a controlar todo o processo de gestão de mudanças,
como a forma como uma requisição de mudanças é solicitada, relatórios são elaborados
e requisição de alteração da arquitetura da aplicação ou processos de engenharia são
construídas.

INTERESSANTE
Sommerville (2011) apresenta a diferença entre codelines e baselines. Enquanto
o primeiro conceito está relacionado à diferentes versões do código fonte
de uma aplicação, o segundo estará voltado para uma versão completa da
aplicação, podendo utilizar diferentes versões de codelines.

Segundo Humble e Farley (2014) e Tuffley (2017), um processo automatizado irá

reduzir a dependência humana para a implantação de uma nova versão, já que o script
criado irá realizar todo o processo. Se um funcionário possui a incumbência de executar
uma sequência de passos que, muitas vezes, são complexos e apenas se concentram
em uma pessoa, qualquer eventualidade que aconteça a esse funcionário irá deixar o
processo em apuros. Com a automação, esse risco será praticamente zero, tendo em
vista que não dependerá de alguém para que a entrega da aplicação continue. Todas as
etapas acontecerão de forma automática.

Mesmo que um processo de implantação manual seja devidamente documentado,

a validação de suas etapas só será feita com a sua execução, o que irá consumir tempo
de um membro da equipe, tornando o processo caro. Testes automatizados, que irão
acontecer com o processo de implantação contínuo, poderão ser validados de forma
mais rápida e barata, bastando executar o script criado e observar o resultado.
41
 Um outro ponto de atenção quanto à documentação do processo manual
de implantação é que a escrita desses artefatos irá depender, exclusivamente, do
conhecimento do autor que os elaborou, de modo que poderão ter mais ou menos detalhes
quanto ao processo de execução real. Dessa forma, um nível maior de granularidade na
escrita do documento poderá omitir detalhes importantes para a implantação de uma
nova versão, por exemplo, tornando o processo de entrega dependente diretamente
dos membros que codificaram as funcionalidades que serão entregues. Então, caso
o colaborador estiver ausente do ambiente de trabalho por qualquer motivo (férias,
desligamento da Empresa, doença ou morte), a entrega, simplesmente, não ocorrerá
dentro do tempo previsto, comprometendo todo o calendário acordado com o cliente,
além do orçamento previsto para a implementação do pacote em questão.

Tuffley (2017) chama atenção para a falta de garantias de que a documentação

foi seguida à risca durante a execução de processos manuais, o que torna difícil o
processo de auditoria nesses casos. Em scripts de automação, por já estarem prontos
e sempre executarem da mesma forma, o processo de auditoria ocorrerá de forma
mais fácil, garantindo, através da análise manual dos scripts criados, que as etapas
necessárias para a implantação estão ocorrendo na sequência correta, gerando o
resultado esperado ao final do processo.

No próximo subtópico abordaremos o processo de entrega contínua e como um

ambiente operacional poderá ser criado e gerido, também conhecido como ecossistema
de entrega contínua.

3.3 MONTANDO O ECOSSISTEMA DE ENTREGA CONTÍNUA

Uma aplicação, para ser implantada em um ambiente, precisa que ele esteja
previamente configurado com os requisitos mínimos para que a aplicação funcione. Tais
requisitos estão relacionados com a configuração de hardware da máquina (quantidade
de memória, velocidade do processador, capacidade do disco rígido), o sistema
operacional que será instalado, as variáveis de ambiente para o sistema operacional
escolhido e os programas auxiliares (servidores de aplicação, bibliotecas específicas).

Quando se automatiza um processo de entrega de versões da aplicação em

determinados ambientes, é importante garantir que todos os ambientes envolvidos terão
suas configurações iguais às do ambiente produtivo, garantindo que o funcionamento
do script de automação terá o mesmo resultado para todos os ambientes. Então, para
que este propósito seja alcançado, a primeira etapa será homogeneizar as configurações
básicas de todos os ambientes de teste (como desenvolvimento e homologação) com
as aplicadas em produção.

Conforme explicado por Humble e Farley (2014) e Tuffley (2017), é importante

que todos os ambientes possam estar padronizados quanto as suas respectivas
configurações, englobando hardware, sistemas operacionais, bibliotecas e softwares
42
auxiliares, configurações de redes e servidores de aplicação, além de firewalls, servidores
DNS, aplicações de monitoramento de tráfego, além de sistemas de segurança, como
sistemas de detecção de intrusão (IDS), sistemas de monitoramento, dentre outros.

Neto (2022) explica que as etapas de um pipeline de implantação (ou DevOps)

apesar de não serem estritamente iguais em todas as Organizações, apresentam etapas
similares, como a compilação automatizada com integração contínua à aplicação que
será implantada em produção, assim como testes automatizados serão executados,
validação e geração de relatórios. É possível que existam processos manuais ao longo
do fluxo. É importante mencionar que o fluxo só irá avançar para a próxima etapa após
a etapa anterior ter sido totalmente concluída e validada com sucesso.

Enquanto na abordagem tradicional, com separação de responsabilidades

entre as áreas de operação e desenvolvimento, é de responsabilidade da equipe de
desenvolvimento informar todas as configurações necessárias para que a aplicação
seja executada com sucesso em produção, os membros dessa equipe não possuem
autorização para realizar um ajuste em tempo de implantação da aplicação no ambiente
produtivo, fazendo com que um erro ou eventual ajuste de configuração demore muito
tempo para ser aplicado. Para o perfil de desenvolvedores DevOps, é possível que esses
ajustes em tempo de implantação sejam realizados, sem que, muitas vezes, o usuário
final seja impactado pela demora na aplicação das correções necessárias.

Segundo Pressman e Maxim (2021) e Humble e Farley (2014), os scripts

de automação, por sua vez, devem considerar aspectos que possam causar riscos
ao ambiente operacional ou à aplicação em si, como o impacto nas métricas de
performance utilizadas pelas equipes de operação. A cada nova entrega de versão, a
equipe de operação terá sua parcela de responsabilidade a ser feita, seguindo métricas
como o cálculo do tempo médio entre falhas (MTBF) ou o tempo médio de reparo (MTTR).
Como o intuito da criação de um script de automação é reduzir o tempo de interferência
humana, também deve ser considerado minimizar o impacto nessas métricas, caso uma
falha aconteça durante a execução do script para implantação de uma nova versão.

Segundo Terentim e Gonçalves (2020), um ponto de atenção na montagem do

ecossistema de entrega contínua é a definição de como uma requisição de mudança
será solicitada pelo usuário. O processo de abertura de uma requisição de mudança,
com sua consequente aprovação por um comitê responsável por gerir as mudanças na
aplicação e sua implantação em ambiente produtivo deve ser devidamente documentado
e acompanhado pelo Gerente de Projetos.

Ainda em concordância com Terentim e Gonçalves (2020), ações de contingência

também precisam ser descritas na requisição de mudança, de modo que, caso algum
problema aconteça, os passos informados auxiliarão no processo de reversão a um
estado anterior ao da falha.

43
 INTERESSANTE
É desejável que um comitê de mudanças seja criado para avaliar e aprovar
qualquer mudança nas configurações do ambiente operacional de uma
aplicação. Após os testes das alterações pela equipe de desenvolvimento,
as mudanças irão ser submetidas à aprovação do comitê que irá, caso
não detecte nenhum conflito ou risco para o correto funcionamento da
aplicação em ambiente produtivo, aprovar a execução em produção.
Para os demais ambientes operacionais, não é necessária a aprovação
do comitê.

Ao se entregar uma versão inicial de uma aplicação, todas as configurações

necessárias para o ambiente operacional deverão estar devidamente mapeadas e
monitoradas pela equipe de operações. Na eventual ocorrência de uma falha, o gerente
de operações poderá ser alertado, através da utilização de sistemas de monitoramento
das aplicações, que algo anormal aconteceu. Dessa forma, é importante que o gerente
de projetos conheça as formas de monitoramento das aplicações utilizadas pela equipe
de operações e possa interagir, quando novas versões da aplicação forem entregues,
preparando a equipe de operações para quaisquer eventualidades que surjam durante
o processo.

Baldo (2012) explica que, para que seja introduzido um pipeline de integração e
entrega contínua, é necessário que o processo passe pelas seguintes fases:

• Fase 1 – inexistência de um servidor central para construir a versão da aplicação

que será entregue, sendo esta tarefa executada de forma manual por um membro
do time de desenvolvimento. A equipe de desenvolvimento ainda não realiza envios
frequentes das contribuições implementadas ao repositório de código.
• Fase 2 – nesta etapa, um servidor central, que irá gerar a versão da aplicação, já
existe, mas realiza apenas o processo de compilação automatizado, geralmente
através de agendamentos em momentos fora do horário do expediente. Ainda não
são feitos testes unitários de forma automatizada.
• Fase 3 – esta fase se caracteriza por inserir alguns testes automatizados, além
do processo de compilação automatizada ser configurado para acontecer a cada
alteração do código no repositório central. Caso algum problema aconteça durante
o processo de compilação, a equipe poderá receber alertas para intervenção e
correção.
• Fase 4 – esta fase introduz o processo de medição do percentual de cobertura
dos testes, além de realizar análise da qualidade do código da aplicação. Relatórios
contendo as informações sobre as métricas encontradas podem ser produzidos,
mesmo que de forma automática pelas ferramentas utilizadas.
• Fase 5 – os testes se tornam ainda mais importantes, muitas vezes sendo
confeccionados antes mesmo da elaboração do código que implementará a
funcionalidade a ser integrada (como acontece com a abordagem direcionada aos
44
 testes, do inglês Test Driven Development (TDD)).
• Fase 6 – nesta etapa, além dos testes unitários, são feitos testes de aceitação
das funcionalidades integradas de forma automatizada, além do processo de
implantação em ambiente de testes da versão da aplicação.
• Fase 7 – esta etapa representa o maior nível de maturidade no processo de CI/
CD, na qual os testes unitários e de aceitação já dão segurança suficiente para
que a implantação da versão da aplicação aconteça diretamente em ambiente de
produção.

Segundo apresentado por Humble e Farley (2014), para que o gerenciamento

das configurações seja feito de forma efetiva, deverão ser elaborados os documentos
de Recovery Point Objective (RPO), representando o tempo anterior a um desastre no
qual é aceitável que aconteçam perda de dados, além do documento Recovery Time
Objective (RTO), que irá definir o limite máximo de tempo para recuperação de um
serviço. Esses dois documentos irão fazer parte do plano de recuperação de falhas e
desastres, fundamentais para o planejamento das soluções de contorno ao aplicar uma
nova versão de um sistema.

Em muitas situações, para que os objetivos descritos nos documentos RTO e

RPO possam ser cumpridos, um ambiente paralelo ao de produção precisa ser criado,
com o intuito de facilitar a recuperação ou reduzir o tempo de recuperação de uma
versão anterior àquela está apresentando falhas. Em caso de aplicações que necessitem
de um alto nível de disponibilidade, essa replicação de ambientes se faz fundamental,
sendo capaz de minimizar, ou até mesmo anular, eventuais indisponibilidades causadas
pelo processo de atualização de versão de uma aplicação.

Aplicações que demandam o armazenamento de grandes volumes de

informação precisam, para fins de auditoria, que os dados possam ser devidamente
armazenados, de modo que facilite o processo de auditoria e possibilite a inserção de
novas informações, sem estourar o espaço em disco dedicado à aplicação. Com isso,
faz-se necessário planejamento de políticas de backup, com a periodicidade conforme
o nível de importância para cada tipo de informação (classificação da informação) para
o negócio da Organização.

O ecossistema de implantação também deve englobar os direitos de acesso

dos integrantes, de modo a garantir que apenas quem tem acesso ao processo de
implantação de uma nova versão, assim o faça. Não se deve apenas negar o acesso
a pessoas externas à Organização, mas também limitar os acessos internos. Para que
esse controle seja efetivo, é preciso incluir no processo de auditoria essa análise, sendo
possível identificar eventuais alterações não autorizadas, a partir da geração de logs de
acesso.

Controle de acesso também é importante para garantir que as alterações

em variáveis operacionais irão acontecer apenas após sua aprovação, executada por
pessoas com o devido acesso concedido.

45
 NOTA
É possível que sejam definidas janelas de manutenção em uma aplicação,
com periodicidade definidas, a fim de agrupar a execução de mudanças
nas configurações operacionais ou para que uma nova versão da
aplicação possa ser implantada. Essa janela poderá englobar um conjunto
de implantações que já foram aprovadas, por exemplo, em uma mesma
semana.

Para que o ecossistema de entrega possa ser montado, é preciso realizar uma
ação para o provisionamento de servidores, ou seja, de máquinas que fornecerão o
suporte operacional necessário para a execução da aplicação, de modo que todo seu
processo de instalação e configuração possa ser executado, de forma remota, através
dos scripts já criados de automação para a aplicação em questão. Uma característica
importante é que existe a possibilidade que essas máquinas servidoras sejam
provisionadas de forma virtual, ou seja, que uma máquina virtual possa ser criada, com
as configurações adequadas, em uma máquina física já existente.

Após a instalação e configuração do novo servidor, é preciso garantir que

o seu gerenciamento será efetuado de forma correta e transparente, o que significa
que todas as alterações que se mostrarem necessárias terão que, obrigatoriamente,
serem validadas e controladas. Ter o controle, nessa situação, significa não permitir que
pessoas não autorizadas consigam realizar o login na máquina, além de permitir que as
alterações só aconteçam provenientes de scripts de automação.

ESTUDOS FUTUROS
Acadêmico, abordaremos as principais ferramentas disponíveis para
a implantação de um fluxo CI/CD na Unidade 3 deste livro. Também
apresentaremos o processo de auditoria de forma mais detalhada no
próximo tema de aprendizagem desta unidade. Mantenha o foco e bons
estudos!

Braga (2015) afirma que todos os ambientes operacionais de uma aplicação

precisam ser gerenciados, de modo a se manterem os mais similares possíveis em
relação ao ambiente de produção, facilitando a identificação e correção de problemas
no processo de implantação. Esses problemas podem estar relacionados com
configurações de ambiente, como o sistema operacional, por exemplo.

46
 ATENÇÃO
É importante perceber que, quando nos referimos a configurações idênticas
entre os diferentes servidores de uma aplicação, estamos incluindo todos os
detalhes! Então, se uma aplicação é utilizada para executar comandos em um
sistema operacional, essa mesma aplicação deverá ser utilizada em TODAS
as máquinas servidoras. O intuito da automação é, justamente, reproduzir
com exatidão todos os passos que forem necessários, partindo do zero, para
provisionar um novo servidor, em caso de falha em uma máquina.

Bahamdain e Alkazemi (2018) afirmam que existem alguns requisitos para que
uma equipe adote as práticas de CI/CD:

• Evitar entrega de versões aleatórias – em muitas situações, como requisições

do cliente ou do líder do projeto (ou gerente de projetos), uma nova versão da
aplicação deverá ser construída e entregue de forma instantânea, sem afetar o fluxo
de execução do projeto.
• Redução do custo de desenvolvimento – desenvolvimento é uma tarefa de alto
custo, já que envolverá tarefas de gerenciamento complexas e que levam tempo para
ficarem prontas, além de envolverem diferentes setores. É preciso que o ambiente
de desenvolvimento seja montado de forma a minimizar o impacto, caso alterações
aconteçam, facilitando o processo de gerenciamento e acompanhamento das
tarefas.
• Facilidade em encontrar e documentar erros – quanto mais cedo se identificam
e se resolvem os problemas, ao longo do fluxo de desenvolvimento de uma aplicação,
menos custoso será para a equipe e para o patrocinador do projeto. Dessa forma,
com a implementação de testes automatizados, o processo de encontrar eventuais
problemas se torna mais fácil e frequente.
• Melhor controle do ciclo de desenvolvimento – a partir da implantação de um
método que apresente, de forma visual, o andamento de todo o processo executado
pelo time de desenvolvimento, a atividade de gerenciamento de eventuais gargalos
identificados nas etapas de desenvolvimento, permitindo seu correto tratamento,
será facilitada.

Acadêmico, neste tema de aprendizagem apresentamos o conceito de Gerência

de Configuração, quais configurações são importantes para o controle de versão em um
projeto, assim como explicamos sobre o processo de Integração e Entrega contínua.
Toda e qualquer configuração necessária para que uma aplicação possa ser implantada
e executada corretamente deverá estar inserida no plano de Gestão de Configuração da
aplicação, de modo que, caso seja necessário montar um novo ambiente partindo do
zero, todas as configurações armazenadas deverão ser suficientes para que a aplicação
funcione ao final do processo.

47
 Segundo Pressman e Maxim (2021), o controle de versões das configurações é
importante para garantir que, na ocorrência de qualquer problema com a implantação
de uma alteração em uma das configurações geridas, seja possível retornar o sistema a
um ponto seguro de funcionamento, identificando qual a configuração que ocasionou
o problema.

48
 RESUMO DO TÓPICO 2
Neste tópico, você aprendeu:

• O processo de entrega automatizada é mais eficiente que o processo manual, por

este último ser propenso a falhas intrínsecas do entendimento de quem estará
executando, além de depender diretamente do conhecimento de quem elaborou a
documentação, necessitando de uma maior interferência humana.

• É necessário a elaboração de um pipeline de implantação para entrega e integração

contínua, mapeando as etapas de configuração, testes e implantação necessárias.

• Toda versão que será analisada para que possa ser implantada em algum ambiente,
através do processo de entrega contínua, é considerada uma versão candidata a
ir ao ambiente de produção, sendo implantada caso todas as etapas do fluxo do
pipeline sejam executadas com sucesso.

• É necessário padronizar todos os ambientes envolvidos no desenvolvimento,

homologação e produção de uma aplicação, tanto em aspectos de hardware quanto
de software e variáveis do ambiente operacional.

49
 AUTOATIVIDADE
1 O processo de Gestão de Configuração deverá englobar artefatos importantes do
projeto, gerados em todas as suas etapas. É importante que o gerente do projeto
saiba identificar e controlar corretamente os itens de configuração, garantindo
que o histórico do projeto será armazenado corretamente. Com base em seus
conhecimentos sobre o gerenciamento de configurações, assinale a alternativa
CORRETA:

a) ( ) O gerenciamento de configurações se baseia no planejamento e implementação

das mudanças necessárias nas configurações.
b) ( ) O gerenciamento de configurações tem o objetivo de planejar os requisitos do
projeto.
c) ( ) O gerenciamento de configurações irá se preocupar, apenas, com a execução do
propósito final do projeto.
d) ( ) O gerenciamento de configurações se baseia nos princípios da ética e
imparcialidade.

2 Identificar os itens de configuração que devem ser gerenciados não é uma tarefa tão
fácil, já que muitos itens irão ser elaborados à medida que o projeto será executado.
É de fundamental importância que o gerente de projetos saiba identificar quando um
item de configuração poderá ser considerado corretamente gerenciado. Com base
em seus conhecimentos, analise as assertivas a seguir:

I- Um item de configuração estará corretamente gerenciado quando puder ser

replicado com exatidão para outro ambiente capaz de executar a aplicação
construída pelo projeto.
II- Um item de configuração estará corretamente gerenciado quando o histórico de
suas alterações puder ser recuperado, caso necessário.
III- Um item de configuração estará corretamente gerenciado quando for implementado
no ambiente e/ou sistema operacional.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) Somente a sentença III está correta.

3 Artefatos de um projeto são representados pelos produtos de cada fase da construção

do produto, que poderá ser um software. Para que a gestão de configuração seja
realizada, o gerente de projeto deverá identificar e gerenciar os artefatos essenciais

50
 gerados por cada etapa do projeto. De acordo com seus conhecimentos sobre itens
que deverão ser gerenciados, classifique V para as sentenças verdadeiras e F para as
falsas:

( ) O código fonte da aplicação é um artefato que deverá ser gerenciado pelo processo
de gerenciamento de configurações.
( ) O plano de testes dos requisitos da aplicação representa um artefato que deverá
ser gerenciado pelo processo de gerenciamento de configurações.
( ) Os e-mails trocados com o cliente representam um artefato que deverá ser
gerenciado pelo processo de gerenciamento de configurações.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – V – F.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 O processo de gerenciamento de projeto inclui o gerenciamento das configurações

deste projeto. Uma das características do processo de gerenciamento de
configurações é a capacidade de manter e, caso necessário, recuperar, o histórico
de configurações importantes. Disserte sobre quais os itens de configuração que
poderão ter seu histórico armazenado e em quais situações o controle de versão se
mostrará imprescindível para o bom funcionamento da aplicação.

5 O processo de integração e entrega contínuas revolucionou a forma como as

aplicações são construídas, testadas e entregues ao usuário para uso em ambiente
produtivo. Enquanto em metodologias de desenvolvimento e entrega tradicionais
o cliente deve esperar até que toda a aplicação seja construída, testada e versões
completas entregues, o processo de entrega contínua veio trazer maior agilidade,
reduzindo o tempo de espera por uma versão. Nesse contexto, disserte sobre os
benefícios do pipeline de implantação para a entrega e integração contínua de uma
aplicação.

51
52
UNIDADE 1 TÓPICO 3 -
AUDITORIA

1 INTRODUÇÃO
Acadêmico, neste tema de aprendizagem, iremos abordar os princípios
fundamentais da auditoria, as principais metodologias e como é possível aplicar estes
conceitos ao processo de entrega e integração contínua.

É importante que cada projeto utilize somente os recursos estritamente

necessários para sua execução, seja de tempo, pessoas alocadas e materiais. Para
garantir que, ao longo do andamento do projeto, os recursos estejam sendo consumidos
conforme o esperado, ou caso sejam insuficientes, é necessário realizar um processo de
auditoria.

CMMI (2017) aborda as melhores práticas para garantia de qualidade de

processos e produtos, integrando atividades de garantia de qualidade em todas as fases
do projeto. Em engenharia de software, o processo de auditoria está intimamente ligado
à garantia de qualidade e aos processos relacionados à melhoria contínua da aplicação,
sempre buscando garantir a satisfação do cliente.

Imoniana (2016) afirma que existem diferentes tipos de metodologias para

realização de auditoria em Sistemas da Informação, sendo possível aplicar metodologias
de auditoria em tudo que for auditável, ou seja, que possuir uma documentação ou
especificação inicial e que o resultado possa ser validado quanto à corretude do que foi
especificado inicialmente, ou seja, é possível auditar eventos, produtos ou processos,
tanto em Organizações quanto para fins pessoais.

Acadêmico, neste tema de aprendizagem abordaremos os principais conceitos

sobre auditoria, seus princípios e como poderá ser aplicada a um projeto. Também
apresentaremos as etapas de um processo de auditoria e quais metodologias poderão
ser utilizadas para esta atividade em um projeto.

2 CONCEITOS E PRINCÍPIOS BÁSICOS DE AUDITORIA

Todo processo de auditoria tem por objetivo elaborar um relatório final de
auditoria, apresentando os resultados obtidos após a realização de uma inspeção no
objeto que está sendo auditado, analisando itens pré-determinados em busca de
resultados previamente esperados. Detalharemos estas informações ao longo deste
tema de aprendizagem.

53
 Segundo Sommerville (2011), o processo de auditoria em produtos, frutos da
indústria de manufatura, é feito através da garantia da qualidade (do inglês Quality
Assurance – QA), que tem o objetivo de inserir processos capazes de garantir a qualidade
dos produtos ao final de uma linha de produção, descartando aqueles produtos que não
atingem o nível mínimo, exigido, de qualidade.

Pressman e Maxim (2021) afirmam que a qualidade de software está relacionada

a três pontos de atenção: boa definição de infraestrutura para um projeto, englobando
análise do problema e definição de uma solução capaz de dar suporte ao problema de
forma robusta, com um processo para controle de mudanças; entrega de um produto
que atenda às necessidades, de fato, do usuário final, de forma confiável (corretude na
implementação das funcionalidades) e livre de erros (bugs); que seja capaz de agregar
valor ao negócio do cliente, sem exigir muitas manutenções corretivas e intuitivo ao
ponto de o usuário conseguir utilizar a aplicação de forma fácil (boa usabilidade).

CMMI (2017) explica que a garantia de qualidade de produtos e serviços de TI

deverá manter todos os envolvidos em um projeto informados a respeito dos processos
e produtos entregues por um projeto, ao longo de todo ciclo de vida desse projeto. Dessa
forma, busca-se implantar a qualidade em todo o processo de construção da aplicação,
desde as fases iniciais do projeto até sua entrega final.

Qualquer eventual não conformidade encontrada deverá ser solucionada pelo

time e, caso não seja possível uma solução, deverá ser escalada para os níveis superiores
(coordenadores, gerentes ou diretores) para que se providencie uma solução.

Ao se executar um processo de auditoria em um produto, antes que seja

entregue ao cliente que o encomendou, é possível que falhas na implementação
possam ser percebidas e corrigidas de forma a adequar o comportamento esperado de
uma funcionalidade com o comportamento obtido desta mesma funcionalidade, após
os devidos testes na aplicação.

Segundo Imoniana (2016), o relatório final de auditoria é o principal artefato

gerado pelo processo de auditoria, sendo necessária sua elaboração, mesmo que
todos os itens avaliados estejam corretos, ou seja, sem desvios no que diz respeito
à comparação entre o comportamento esperado para uma funcionalidade e seu
comportamento obtido, após a realização dos devidos testes no objeto que está sendo
alvo da auditoria.

Segundo Fontes (2016), o processo de auditoria tem o objetivo de registrar

eventuais acessos à informação para que seja possível realizar potenciais processos
de investigação em busca de se garantir a Segurança da Informação na Organização.
Então, as operações em uma aplicação, que geram dados mantidos em bancos de
dados sob supervisão da Empresa, podem ter seu histórico de operações armazenado,
conforme requisitado pelo cliente (patrocinador), a partir de lógica embutida no próprio
código do software.

54
 ESTUDOS FUTUROS
Estudaremos a importância da definição do escopo de uma auditoria e
sua relação com o processo de auditoria como um todo em momento
futuro.

Segundo Imoniana (2016), todo processo de auditoria em sistemas da informação,

para que seja feito de maneira correta, precisa se basear em normas técnicas, tais quais
a ISO/IEC 27001 e ISO/IEC 27002, voltadas para a Gestão da Segurança da Informação.

Pressman e Maxim (2021) indicam que normas voltadas para a garantia

da qualidade, como as normas da família ISO 9000 podem ser aplicadas a qualquer
Organização, independentemente do tipo de produto gerado, com a finalidade de
certificar que os produtos criados consigam satisfazer às necessidades reais dos
clientes. Os sistemas que implementam essas normas visam cobrir todas as fases do
ciclo de vida de uma aplicação, como o planejamento, construção, medição e testes. A
norma ISO 9001:2008 possui seu foco voltado para garantia de produtos de software.

Segundo Sommerville (2011), a norma ISO 9001 não representa um padrão,

de fato, para a construção de aplicações, mas é definida como um framework, ou
seja, como um arcabouço, contendo definições sobre quais os resultados esperados
para os processo de gestão da qualidade, além de quais padrões organizacionais e
procedimentos são necessários em uma Empresa.

Ao seguir as definições dessa norma, a Empresa elaborará seu manual de

qualidade, que deverá estar relacionado aos processos tidos como essenciais pela
norma, descrevendo todos os processos importantes no fluxo de produção da aplicação,
identificando quais dados devem ser produzidos e gerenciados em cada etapa dos
processos mapeados.

ESTUDOS FUTUROS
Acadêmico, abordaremos outras normas voltadas para o apoio ao
processo de gerência de configuração, com maiores detalhes, na Unidade
3 desta disciplina.

Um aspecto importante do processo de auditoria é que ele precisa ser periódico,

ou seja, ter uma realização frequente para garantir que os desvios já encontrados foram
devidamente ajustados, além de garantir que a qualidade esperada, para o que está
sendo construído, seja mantida.

55
 NOTA
Uma auditoria visa garantir uma melhoria contínua no objeto auditado, de
modo que o nível de qualidade acordado com o cliente possa ser atingido e
mantido. Caso um processo esteja sendo o alvo de um processo de auditoria,
por exemplo, sua melhoria contínua irá certificar que todas as etapas estão
sendo devidamente executadas, com os resultados obtidos em cada fase,
equivalendo aos resultados esperados, de acordo com o planejamento
desse processo.

Pressman e Maxim (2021) afirmam que a garantia da qualidade se dá através

de ações planejadas para avaliar as funcionalidades de um software, apresentando
aos interessados no projeto subsídios que demonstrem que as ações planejadas, para
atingir o nível de qualidade desejado para o produto, estão surtindo efeito. Dentre essas
ações planejadas, estão ciclos de auditoria, ou seja, de avaliação do que está sendo
construído, a forma como a construção está sendo feita, além de revisões técnicas e
estratégias para controle dos artefatos gerados pelas etapas do projeto.

INTERESSANTE
Pressman e Maxim (2021) afirmam que o setor de garantia da qualidade irá
defender o ponto de vista do cliente frente ao que está sendo construído,
garantindo que os interesses do cliente serão defendidos e que, ao final do
projeto, o produto corresponda ao que é esperado pelos patrocinadores.

Para o sucesso de um processo de auditoria, é importante que alguns princípios

sejam seguidos, conforme apresentados no próximo subtema.

2.1 PRINCÍPIOS DA AUDITORIA

Conforme apresentado por Imoniana (2016), para que o processo de auditoria
possa acontecer a contento, é preciso que alguns princípios sejam respeitados,
conforme nos apresenta:

• Ética – toda auditoria precisa ser feita de forma imparcial, ou seja, os membros da
equipe de auditoria não devem ter nenhum tipo de relação (não pode ter participado
de nenhuma fase da construção do projeto, por exemplo) com o produto que está
sendo auditado, garantindo que a realização dos testes (avaliação dos itens de
auditoria) não irá mascarar eventuais falhas conhecidas.

56
• Independência – o auditor precisa ter independência para realizar seus testes,
sem interferências dos membros da equipe que construíram o produto, de modo a
induzir como os testes deverão acontecer.
• Competência – o auditor deverá ter competência técnica para realizar um processo
de auditoria em um serviço ou produto de TI, o que significa que ele deverá conhecer
sobre o negócio que envolve a aplicação ou produto que será construído.
• Planejamento – é preciso que o auditor planeje, de forma adequada, todas
as atividades que serão executadas em um processo de auditoria, levando em
consideração o escopo do projeto que será auditado.
Evidência – todos os itens avaliados precisam ser devidamente comprovados com
vídeos, prints da tela ou meios que evidenciem os passos executados e a divergência
de resultado entre o esperado e o obtido. Este item é especialmente importante,
tendo em vista que podem existir divergências pessoais entre o auditor e algum
membro da equipe, de modo que o relacionamento entre os membros da equipe de
desenvolvimento e o auditor não pode interferir no processo de auditoria do produto.

ESTUDOS FUTUROS
Abordaremos a definição de escopo e a importância de sua correta definição
em cada ciclo de auditoria no próximo subtema.

Uma Empresa de desenvolvimento de softwares, por exemplo, poderá ter um

setor específico para apenas realizar as atividades relacionadas com auditoria, tendo em
vista que os membros desse setor não irão participar da construção de nenhum projeto
de TI, aplicando os princípios da ética, independência e, ao coletar as provas acerca dos
erros encontrados em um projeto (como através da gravação de vídeos ou extração de
imagens instantâneas da tela), terá seguido o princípio da evidência.

Sommerville (2011) menciona a necessidade de realizar atividades de revisão e

inspeções constantes para garantir a qualidade dos entregáveis de uma etapa do projeto.
Essa inspeção deverá englobar a documentação gerada, o código fonte construído, além
dos registros criados ao longo do processo pelo time de desenvolvimento, buscando
identificar eventuais desvios de comportamento ou falha na aderência dos padrões de
qualidade acordados com o time. O resultado dessa análise poderá dar subsídios ao
gerente de projetos para a tomada de decisões acerca do projeto, como alocação de
novos recursos ou revisão do planejamento efetuado.

57
 IMPORTANTE
Sommerville (2011) afirma que, durante os processos de inspeção de uma
aplicação, o intuito é melhorar continuamente o produto construído, não
sendo foco analisar a performance das pessoas envolvidas no time de
desenvolvimento. Para isso, é preciso que o gerente de projetos promova
o engajamento dos membros do time de modo que o sucesso ou fracasso
de um membro do time irá representar o de toda a equipe, não somente do
indivíduo.

Pressman e Maxim (2021) afirmam que cada membro do time de revisão técnica,
para garantia da qualidade, precisa ser independente do produto que está sendo
inspecionado (não ter participado de nenhuma fase de sua elaboração), tendo papéis
diferentes dentro do time de revisão, como o de liderança da equipe, de documentar as
descobertas efetuadas, de apresentar o material aos interessados etc. Após a finalização
da inspeção em um artefato específico, os resultados precisam ser documentados e
avaliados pela equipe, que decidirá se aprovará ou não a funcionalidade avaliada.

ESTUDOS FUTUROS
Acadêmico, abordaremos as técnicas de revisão (ou auditoria) no Tema de
Aprendizagem 3, ainda nesta Unidade de ensino.

Uma das principais atividades, para que a realização da avaliação de uma

aplicação seja realizada, é a definição do escopo que este ciclo de revisões englobará.
Discorreremos sobre isso no próximo subtema.

2.2 DEFINIÇÃO DE ESCOPO

Segundo Imoniana (2016), o escopo de uma auditoria irá dizer qual será o nível
de abrangência do ciclo de auditoria que está se iniciando, de modo que as fronteiras
dos itens a serem analisados serão delimitadas. Imaginemos um sistema grande
e complexo, com diferentes módulos e diferentes conjuntos de funcionalidades. É
possível que, para a realização do processo de auditoria, as funcionalidades possam ser
divididas em pacotes, sendo necessários vários ciclos de auditoria para que todas as
funcionalidades da aplicação possam ser devidamente analisadas e testadas.

58
 Quando se delimita um escopo, o auditor poderá priorizar o conjunto de
funcionalidades mais importantes (que agregam mais valor ao negócio do usuário) nos
primeiros ciclos de auditoria, garantindo que as funcionalidades vitais da aplicação
estarão com seu comportamento perfeito, conforme o especificado pelo cliente.

As fronteiras definidas pelo escopo serão importantes para que o auditor não
ultrapasse estritamente o conjunto de funcionalidades que foram definidas para testes
em cada ciclo, evitando trabalho desnecessário e concentrando esforços em testar
somente o que estiver no foco da auditoria em questão. Dessa forma, espera-se que o
auditor consiga reduzir o tempo gasto em cada ciclo, evitando ciclos longos e que, ao
seu final, podem não mais fazer sentido para atender às expectativas do usuário.

Pressman e Maxim (2021) afirmam que o foco de uma revisão que segue o
processo de revisão técnica formal (RTF), deverá ser um artefato específico da
aplicação. O desenvolvedor da parte que será analisada será o responsável pelo alerta
que indica que o artefato se encontra pronto para ser avaliado, ficando a cargo do líder
da equipe de revisão avaliar se o artefato está, de fato, completo (com o resultado
esperado, critérios de validação e documentação prontos), atribuindo a mais outros
dois ou três membros do time que realizem os devidos testes, documentando todos
os resultados obtidos. Ao final do processo, deve ser agendada uma reunião de revisão
com todos os envolvidos na avaliação, podendo escolher uma dentre as três situações
a seguir:

• artefato aprovado sem necessidade de novas intervenções;

• artefato apresenta erros impeditivos, considerados graves, por isso é rejeitado;
• artefato é aceito de forma parcial, até que eventuais ajustes necessários sejam
efetuados e outra revisão seja executada.

Os tipos e técnicas para realização do processo de auditoria ou revisões técnicas,

serão apresentados no próximo subtema.

2.3 TIPOS DE AUDITORIA

Segundo Imoniana (2016), além dos princípios básicos apresentados, é preciso,
também, definir os níveis ou tipos de auditorias que podem acontecer em uma Empresa.
Existem três níveis de auditoria, que são:

• Primeiro nível ou primeira parte – será realizada pelos próprios membros da

equipe de desenvolvimento do produto ou por uma equipe específica para realização
de auditorias internas. Objetiva identificar eventuais falhas do sistema ou serviço,
elaborando um plano de ação para contornar os problemas detectados.
• Segundo nível ou segunda parte – realizada em conjunto com o cliente (ou com
os interessados no projeto), este tipo de auditoria servirá como um termômetro da

59
 satisfação do cliente em relação ao produto que está sendo construído. O cliente,
desta forma, avaliará as funcionalidades implementadas, comparando-as com os
requisitos inicialmente especificados.
• Terceiro nível ou terceira parte – realizada por uma Organização externa, tem
o objetivo de avaliar os processos internos de uma Empresa que visa obter uma
certificação em alguma norma (como ISO/IEC 9001, para qualidade de serviços, ou
ISO/IEC 27001, para a segurança da informação ou a CMMI, voltada para a avaliação
da maturidade de processos de software). Não é um processo obrigatório, caso não
seja pleiteada uma nova certificação ou a evolução dos níveis de maturidade em
uma certificação anteriormente obtida pela Organização.

Segundo Pressman e Maxim (2021), a aplicação das técnicas de revisão pode

trazer uma eficácia de até 75% na detecção de falhas em um projeto. Algumas técnicas
que podem ser aplicadas para a detecção de problemas são listadas a seguir:

• Amplificação e eliminação de defeitos – nesta técnica, um processo de revisão

poderá ser executado, identificando erros que serão multiplicados pelo custo,
para sua correção, podendo repassar eventuais erros não detectados para etapas
posteriores do processo . Em cada etapa do fluxo de avaliação é calculado um
percentual da eficiência de detecção de erros, assim como são informados quantos
erros foram provenientes de etapas anteriores e quantos serão repassados às
próximas etapas do processo.
• Utilização de métricas de revisão – métricas podem ser definidas para avaliar
cada ciclo de revisão executado, tais quais medições de esforço (de preparação,
avaliação e correção de eventuais bugs encontrados), tamanho dos artefatos
avaliados (quantidade de linhas de código, páginas de documentos ou diagramas
UML), quantidade de erros graves encontrados (erros impeditivos de utilização das
funcionalidades) ou quantidade de erros secundários (problemas que não impedem
a utilização da aplicação, sendo considerados menos graves).
• Revisões informais – através do planejamento e execução de testes de mesa por
um ou mais membros do time de desenvolvimento.
• Revisões Técnicas Formais (RTF) – processo mais elaborado, que exigirá a
formação de uma equipe de avaliação, executando reuniões para avaliação formal
dos artefatos gerados pelo projeto.

Ainda segundo Pressman e Maxim (2021), revisões informais podem ser

realizadas com menos burocracia, como a execução de testes de mesa ou análise
em conjunto com outros colegas de time. Revisões formais, as RTFs, por sua vez,
necessitam da definição de membros de um time, podendo melhorar o processo
de desenvolvimento do time (para projetos futuros), além de servir de subsídio para
realização de treinamentos com usuários finais.

Sommerville (2011) menciona a importância de se elaborar um plano de qualidade

para projetos de grande porte ou de grande ciclo de vida, detalhando a execução das
revisões formais de auditoria, contendo as seguintes informações:

60
• breve descrição do produto que será analisado;
• planos de produto, apresentando as principais datas para as entregas acordadas
com os patrocinadores;
• descrição do processo que será utilizado para o desenvolvimento do produto;
• metas de qualidade que deverão ser alcançadas pelo processo de desenvolvimento,
garantindo que o produto atenda às exigências mínimas da empresa;
• riscos e gerenciamento de riscos, informando os principais riscos capazes de
interferir na qualidade do produto desenvolvido e quais ações poderão ser tomadas
para prevenir ou tratar/contornar tais riscos.

Sommerville (2011) indica a utilização de revisões informais para sistemas que

não sejam de grande porte. Essa indicação se justifica pelo fato de equipes com poucos
membros conseguirem firmar comunicação mais efetiva e com maior facilidade.

Pressman e Maxim (2021), por outro lado, não direcionam as revisões informais
a um tipo de projeto específico, indicando apenas que uma ferramenta eficaz para esse
tipo de validação: os testes de mesa. Por não existir um planejamento prévio para essa
revisão, a eficiência dessa forma de revisão, em comparação com as revisões formais,
é menor, mas pode-se melhorar com a elaboração de listas de verificação contendo os
itens que serão validados para cada artefato.

Imoniana (2016) apresenta diferentes tipos de auditoria voltados para análise

dos sistemas computacionais:

• Auditoria durante o desenvolvimento do sistema – nesse cenário, todo o

processo de codificação da aplicação será analisado, desde as boas práticas de
programação adotadas pela equipe até as ferramentas adotadas como padrão e
os processos inerentes à metodologia de desenvolvimento que irá guiar o projeto
(tradicional, ágil, espiral, incremental etc.).
• Auditoria de sistemas em produção – este tipo de auditoria se aplica a
produtos que já estão em produção (em uso pelo usuário final) e precisam ter suas
funcionalidades avaliadas.
• Auditoria no ambiente tecnológico – este tipo de auditoria irá analisar o ambiente
tecnológico, que englobará o local físico, disposição dos móveis, segurança de
acesso ao escritório, instalações elétricas e de internet e tudo que se referir ao
espaço físico, no qual a equipe estará alocada para desenvolver o projeto.

ESTUDOS FUTUROS
Ainda neste tema de estudos, estudaremos as principais metodologias para
cada tipo de auditoria apresentado.

61
 Pressman e Maxim (2021) apresentam uma outra forma de revisões do tipo RTF,
que é a revisão por amostragem. Neste processo, seriam selecionadas amostras de
todos os artefatos de engenharia de software produzidos em um projeto, com o intuito
de encontrar eventuais erros. Deve-se dar maior prioridade para os artefatos que podem
estar mais propensos a erros.

Fonseca, Nunes e Santana (2016) apresentam a técnica de amostragem como

capaz de analisar uma parte de um conjunto de dados (como parte de uma população
ou dos artefatos gerados por um projeto), tendo o resultado da análise deste conjunto
como representação do todo. Quando aplicado à um projeto de software, esta técnica
precisa dar maior prioridade em analisar artefatos considerados mais propensos a erros.

As técnicas apresentadas podem ser aplicadas em ciclos de auditoria, ou

revisões técnicas, conforme apresentaremos no próximo subtema.

3 O PROCESSO DE AUDITORIA
PMI (2017) define uma auditoria como um processo estruturado e independente,
capaz de verificar se o planejamento para as atividades executadas está sendo
efetivamente seguido. Esse processo deve ser executado por uma equipe que não se
envolveu com nenhuma etapa do planejamento e execução do projeto auditado, com o
intuito de validar a utilização das boas práticas acordadas entre as partes (patrocinador
e Empresa contratada), encontrar e documentar as falhas como não conformidades,
compartilhar o resultado com outros projetos, auxiliando no processo de melhoria
contínua.

A execução de uma auditoria requer a realização de etapas, que precisam ser

executadas seguindo metodologias específicas, conforme o propósito da auditoria em
questão. Serão realizadas auditorias em produtos de tecnologia da informação, conforme
a etapa na qual se encontra o produto (objeto da auditoria). É possível que uma aplicação,
por exemplo, já esteja em ambiente produtivo, ou em fase de desenvolvimento, ou ainda
em preparação para iniciar o desenvolvimento.

Para cada etapa de projeto, uma metodologia específica de auditoria poderá ser
utilizada, analisando os artefatos gerados em cada fase do projeto e, principalmente,
garantindo a aderência do produto aos requisitos inicialmente levantados pelas
necessidades do cliente.

Acadêmico, abordaremos as principais etapas de um processo de auditoria e as

principais metodologias voltadas para análise de produtos de TI, na sequência.

62
3.1 ESTUDO DA DOCUMENTAÇÃO
Sommerville (2011) afirma que é fundamental conhecer o produto que será
avaliado, sendo essa a primeira etapa da elaboração do plano de qualidade de um
projeto. É importante manter a descrição do artefato que será analisado de forma clara
e suscinta, de modo a evitar que os membros da equipe de gestão da qualidade percam
o interesse e não concluam a leitura do documento.

Segundo Imoniana (2016), a primeira etapa em um projeto de auditoria, seja qual

tipo for, é analisar os documentos disponíveis para o projeto, processo ou evento que
será auditado, procurando ambientar-se das funcionalidades esperadas para o produto,
conhecer as respostas esperadas para cada funcionalidade e, dessa forma, o auditor
conseguirá montar o seu plano de auditoria.

Como documentação, é possível encontrar diferentes artefatos, tais quais

documentos detalhados com a especificação de requisitos, diagramas diversos
(sequência, casos de uso, fluxogramas de classes), histórias de usuário (para as
metodologias ágeis), além de comentários feitos no próprio código do produto.

Durante esta fase de estudo, é importante dar ênfase às funcionalidades que

estão sendo englobadas pelo escopo da auditoria em questão, tendo em vista que
é possível realizar diferentes ciclos de auditoria em um mesmo projeto, analisando
diferentes partes em cada ciclo.

Pressman e Maxim (2021) se referem ao documento que servirá de guia para

uma RTF, como fundamental para que a reunião do ciclo de revisão aconteça. Essas
reuniões servirão de apresentação das funcionalidades para membros que, por terem
se envolvido com o desenvolvimento de outras funcionalidades, não possuem a visão
global do sistema. As questões que serão avaliadas derivam da apresentação da
funcionalidade, por parte de seu desenvolvedor, aos demais membros que estiverem
participando do ciclo de revisão.

Fontes (2016) apresenta como exemplo de uma planilha de auditoria o modelo

exibido no Quadro 1.

63
 Quadro 1 – Exemplo de planilha de auditoria

Item / Pergunta Resposta esperada Resposta obtida Conclusão

• Resposta • Indica se houve ou

apresentada não divergência
• Representa uma
pelo sistema, entre a coluna de
sequência de
após a execução resposta obtida e
passos para o • Resposta esperada
dos passos resposta esperada,
teste de uma a partir da execução
mencionados na caracterizando
funcionalidade da sequência de
coluna item. um desvio. Em
do sistema. passos mencionada
• Para eventos ou caso de desvios, é
• Também pode na coluna Item.
processos, indica o importante mencionar
se referir a É obtida através
que efetivamente o que diferiu entre
uma pergunta, da análise da
aconteceu o esperado e o
em caso da documentação
no evento efetivamente obtido,
avaliação de estudada.
ou processo, encaminhando esta
um evento ou
como resposta planilha à equipe
processo.
à pergunta responsável pelos
elaborada. ajustes necessários.

Fonte: adaptado de Fontes (2016)

O Quadro 1 apresenta as colunas necessárias para elaboração de um relatório

de auditoria. As duas primeiras colunas deverão ser preenchidas ainda na fase de
estudo da documentação, conforme o conjunto de funcionalidades que compõem o
escopo que será analisado. As duas últimas colunas, por sua vez, só poderão ter seus
respectivos conteúdos preenchidos após a fase de entrevistas de auditoria.

É importante mencionar que as perguntas a serem feitas a respeito do produto,

serviço ou evento que será auditado devem ter um nível de granularidade baixo, ou seja,
serem detalhistas, indicando a sequência de passos a serem seguidos, com exatidão,
para que um objetivo seja alcançado.

Outro ponto que deve ser considerado, também, é a importância de se englobar

todo o escopo, conforme os requisitos especificados, abrangendo os fluxos alternativos,
as exibições de mensagens de erro ou de validações específicas. É necessário, muitas
vezes, elaborar mais de uma pergunta para um item que será avaliado, tendo, cada
pergunta, graus de granularidade diferentes. Então, para uma funcionalidade de
extração de um relatório em um sistema, por exemplo, é possível elaborar uma pergunta
do tipo “Ao percorrer o caminho menu -> relatório -> relatório de contabilidade, uma
página está sendo aberta exibindo o relatório?” e, em outro item, avaliar se os campos
necessários para o relatório extraído estão presentes no resultado apresentado.

Acadêmico, abordaremos o funcionamento dos ciclos de auditoria no próximo

subtema.

64
3.2 OS CICLOS DE AUDITORIA
Segundo Pressman e Maxim (2021), em cada ciclo de uma RTF, o revisor
responsável por registrar as observações encontradas ao longo do processo de
avaliação deverá produzir, ao final do processo, uma lista de problemas de revisão,
além de um relatório resumido da RTF executada, capaz de responder aos três pontos
básicos: qual artefato foi analisado? Quem participou da revisão? Quais as observações
encontradas e conclusões obtidas? É importante manter esse relatório na base histórica
de documentos do projeto, mantendo-se um histórico dos ciclos efetuados.

Segundo Imoniana (2016), após a etapa de estudo e elaboração inicial do

relatório de auditoria, a próxima fase do processo será a realização de entrevistas (ou
avaliações) de auditoria, na qual os itens previamente definidos para análise deverão ser
testados e os resultado obtidos coletados para, então, preencher a coluna resultados
obtidos, do Quadro 1 apresentado anteriormente.

As entrevistas, quando necessárias, deverão acontecer com pessoas (membros

da equipe de desenvolvimento) que se envolveram diretamente com a funcionalidade
que estará sendo analisada ou, em caso de auditoria em processos ou eventos, que
tiveram participação direta na realização da etapa averiguada. Podem acontecer
diversas rodadas de entrevistas, tantas quantas forem necessárias para a finalização
dos itens que serão analisados.

IMPORTANTE
Não é necessária a participação de todos os membros da equipe de um
projeto, processo ou evento. A partir da realização da entrevista com um
membro que participou ativamente do processo, é possível identificar pontos
falhos e pontos de melhoria para eventos futuros ou, em caso de processos,
otimização das etapas.

Pressman e Maxim (2021) e Imoniana (2016) concordam que a lista de problemas

de revisão deverá ter seus itens sanados antes da execução do próximo ciclo, evitando
o acúmulo de problemas. Ao final do processo de correção dos problemas apontados,
um novo ciclo de auditoria deverá ser feito, garantindo que todas as correções surtiram
o efeito desejado.

65
 ATENÇÃO
É importante que o auditor, após a realização de todos os ajustes pela equipe
responsável, realize todos os testes feitos no conjunto de funcionalidades
novamente, garantindo que os erros foram devidamente corrigidos sem que
novos bugs tenham sido inseridos. É possível, por exemplo, que durante o
processo de correção de um defeito, uma funcionalidade que já tinha sido
testada e aprovada sofra impactos, tendo seu funcionamento comprometido.

As etapas do processo de auditoria, de forma resumida, seguirão um fluxo

contínuo ao longo da construção do projeto, tendo em vista que a realização de
auditorias deve ser feita de forma periódica.

A Figura 11 apresenta as etapas para um ciclo de auditoria em um produto, serviço

ou evento. Após a definição dos itens que serão analisados, feita a partir do estudo da
documentação disponível, é preciso iniciar o preenchimento do relatório de auditoria,
seguindo-se para a fase de entrevistas de auditoria. Durante e após as entrevistas, o
auditor será capaz de preencher as colunas de resultado obtido e conclusão, comparando
o resultado que se esperava obter com a funcionalidade com o que, de fato, foi obtido.
Ao se deparar com desvios no comportamento de funcionalidades, o auditor deverá
encaminhar a planilha para a equipe responsável, que terá um prazo para efetuar os
ajustes e retornar ao auditor, o qual fará uma nova rodada de testes nas funcionalidades.

Figura 11 – Etapas de um ciclo de auditoria

Fonte: adaptada de Fontes (2016)

66
 Para cada tipo de sistema, processo ou evento que será analisado, é importante
que a metodologia de auditoria adequada seja adotada, para garantir uma maior
abrangência nos requisitos analisados e dirimir eventuais dúvidas que surjam ao longo
do processo.

Sommerville (2011) afirma que os padrões para garantir que os ciclos de auditoria
aconteçam conforme esperado devem ser elaborados em conjunto com os engenheiros
de software envolvidos no time de desenvolvimento, devendo ser periodicamente
ajustados para acompanhar a evolução das tecnologias envolvidas, além de dar suporte
aos membros do time de desenvolvimento quanto à utilização desses padrões. Devem
ser executadas três atividades durante os ciclos de revisões:

• Atividades pré-revisão – caracterizando todo o planejamento para o ciclo de

revisão que irá acontecer, como qual artefato será avaliado, formação da equipe
que participará da revisão. Nesta fase, os membros da equipe deverão obter o
conhecimento necessário, a partir da leitura das documentações disponíveis, sobre
o produto que será avaliado.
• Reunião de revisão – nesta etapa, o responsável pelo desenvolvimento da
aplicação analisará, em conjunto com a equipe da revisão, o produto em busca de
falhas que deverão ser devidamente documentadas.
• Atividades pós-revisão – todos os problemas encontrados, ao longo da fase de
reunião da revisão, deverão ser apresentados e corrigidos, sendo necessário avaliar
a necessidade de inclusão de novos recursos no projeto para que os problemas
consigam ser sanados sem alterar o cronograma já planejado para o projeto. É
possível que um novo ciclo de revisão aconteça, após um tempo, para avaliar se as
correções já foram contempladas.

Para que um ciclo de revisão ou auditoria aconteça com sucesso, se faz

necessária aplicação de metodologias de auditoria, como as que apresentaremos no
próximo subtema.

3.3 METODOLOGIAS DE AUDITORIA

Para qualquer tipo de auditoria que se deseje fazer, um auditor precisará conhecer
e aplicar metodologias que, conforme o cenário e o objetivo da auditoria, poderão variar.
Caso o alvo da auditoria seja um produto de TI, existirão metodologias específicas para
cada um dos tipos de auditoria que apresentamos no subtópico 2.3. Caso o alvo da
auditoria seja um evento ou processo interno de uma Empresa, metodologias diferentes
das utilizadas para sistemas poderão ser aplicadas.

Segundo Imoniana (2016), as seguintes metodologias de auditoria, específicas

para a avaliação de sistemas de TI, podem ser aplicadas:

67
 • Simulação paralela – esta técnica tem o objetivo de montar um ambiente, com
as mesmas características do ambiente de produção, de forma paralela para que
os testes possam ser realizados pelo auditor e sua equipe. Caso não seja possível
efetuar uma cópia do código da aplicação, o auditor poderá executar uma engenharia
reversa e implementar uma nova aplicação, com as mesmas funcionalidades, para
realização dos testes. Nesta situação, é possível efetuar testes minuciosos dos
requisitos, o que não seria possível ser feito diretamente no ambiente de produção.
• Lógica de auditoria embutida no sistema – esta técnica irá inserir na aplicação,
durante seu processo de codificação, um código que possa realizar a auditoria de
operações efetuadas no sistema, como inclusões de dados, alterações e exclusões.
Por ser uma técnica aplicada durante a codificação, é possível auditar qualquer
funcionalidade do sistema. A grande ressalva, nesse caso, é a inclusão de lógica no
sistema após este já estar pronto, não sendo indicado, pela possibilidade de inclusão
de bugs em funcionalidades que já estavam com o comportamento correto.
• Rastreamento e mapeamento – o intuito desta técnica é armazenar rastros
de todas as principais funcionalidades disponibilizadas pelo sistema, através da
implementação de trilhas de auditoria. Sua principal aplicação é o levantamento de
estatísticas, como quantidade de acessos a determinadas páginas, arquivos etc.
• Análise da lógica de programação – esta técnica se baseia na análise manual, por
parte do auditor e sua equipe, do código de um sistema, em busca de divergências
na implementação das regras de negócio, em comparação com os requisitos
especificados. Também é possível avaliar a utilização dos itens combinados pela
equipe, como implementação de determinados padrões de projeto, utilização de
boas práticas de programação, dentre outros itens.
• Aquisição, desenvolvimento, manutenção e documentação de sistemas –
esta técnica visa estabelecer critérios para a avaliação de aplicações prontas, que
a Organização deseja adquirir, assim como estabelecer cláusulas contratuais entre
a Empresa e seus clientes que a contratam para dar manutenção em aplicações
já prontas ou para construir novos sistemas. Nessa técnica, é possível definir
ferramentas e formas para controle de versão na elaboração das documentações
dos sistemas que são mantidos e/ou codificados pela Empresa.
• Controles de desenvolvimento e manutenção de sistemas – esta técnica
apresenta o estudo da viabilidade econômica antes de estabelecer um contrato
para implementação e/ou manutenção de sistemas, avaliando questões como
tempo hábil, recursos necessários e sua disponibilidade, além de estabelecer regras
para a requisição de novas funcionalidades, por parte do usuário, ou requisição de
mudanças em requisitos já codificados.
• Controle de documentação de sistemas – visa estabelecer padrões para a
escrita e modificações em documentos elaborados pela Empresa, assim como
definir padrões para o armazenamento dessa documentação e o devido controle
de acesso.

O Quadro 2 apresenta um resumo das características para as principais técnicas

de auditoria apresentadas.

68
 Quadro 2 – Resumo das principais características das técnicas de auditoria de sistemas

Item Necessi-
Testes em
dade de Necessi- Alto custo
qualquer Alto custo de
preparação dade de de implan-
funciona- desenvolvi-
de grande habilidade tação na
lidade do mento
massa de do auditor aplicação
sistema?
Técnica dados

Simulação
Sim Não Sim Sim Não se aplica
paralela
Lógica de
auditoria
Sim Não Sim Sim Sim
embutida no
sistema
Rastreamento
e Sim Não Sim Sim Sim
mapeamento

Análise da
lógica de Sim Não Não Sim Não
programação

Fonte: adaptado de Imoniana (2016)

A partir do Quadro 2, é possível observar que as técnicas de auditoria possuem

características em comum. Quando uma técnica de auditoria é aplicada ao longo do
processo de desenvolvimento da aplicação ou um ambiente paralelo é montado
exclusivamente para a realização dos testes, praticamente todas as funcionalidades
da aplicação poderão ser analisadas, quanto ao comportamento. Caso não seja
possível criar um ambiente de testes separado, os testes irão se limitar apenas àquelas
funcionalidades que possam ser completamente revertidas, ou seja, totalmente
desfeitas, evitando inserir informações inconsistentes ou irreais (lixo) na base de dados
da aplicação em ambiente produtivo.

Dados que sejam derivados da realização de testes e não sejam excluídos

da base de dados poderão resultar em relatórios inconsistentes, podendo impactar
diretamente na elaboração de metas da Empresa.

ATENÇÃO
Relatórios extraídos de um sistema irão impactar diretamente na tomada de
decisões estratégicas pela diretoria da Empresa, por isso precisam estar com
seus dados coerentes com a realidade. A inclusão de dados mediante testes,
caso não sejam excluídos corretamente poderão acusar falsos positivos ou
negativos para operações estratégicas, impactando diretamente o negócio
da Organização.

69
 A auditoria também poderá acontecer no processo de desenvolvimento de uma
aplicação ou na metodologia adotada pela equipe para a construção do sistema. Nesse
caso, serão avaliadas se as etapas da metodologia estão sendo seguidas corretamente,
se os artefatos que devem ser gerados, assim o estão, se a forma de trabalho acordada
pela equipe está sendo seguida corretamente por seus membros.

Segundo CMMI (2017), existem diferentes formas de executar um ciclo de

auditoria em projetos, como a auditoria de configuração funcional (do inglês
Functional Configuration Audits - FCA), auditoria de configuração física (do inglês
Physical Configuration Audits – PCA) e auditoria de gestão de configuração. O
propósito da auditoria FCA é garantir que o requisito está de acordo com o planejado,
com suas documentações completas. A auditoria PCA, por sua vez, irá validar o item
de configuração com base em sua especificação, enquanto a auditoria da gestão de
configuração atestará a completude e consistência dos itens de configuração.

Sommerville (2011), Pressman e Maxim (2021) e Imoniana (2016) chamam

atenção para a importância de se manter uma periodicidade para a realização de ciclos
de auditoria, garantindo, assim, a qualidade dos sistemas construídos e do trabalho
realizado pelas equipes. É comum que exista um setor interno na Empresa que seja
responsável pelo processo de auditoria em todos os sistemas construídos por ela, ou
que existam contratos de manutenção firmados.

O processo de auditoria também poderá acontecer para as configurações

específicas de um projeto, como as configurações de hardware de um servidor de
aplicações ou banco de dados, configurações específicas para um sistema operacional
ou parâmetros de inicialização da aplicação.

Segundo Pressman e Maxim (2021), a técnica conhecida como Seis Sigma

se mostra como uma importante estratégia estatística para garantia da qualidade de
softwares. Essa técnica se baseia em três etapas fundamentais, que fazem uso de dados
e análise estatística para realizar a medição da qualidade de uma aplicação, assim como
promover sua melhoria contínua. Estas etapas são:

• Definir quais serão os artefatos que serão construídos e entregues pelo projeto,
assim como a lista de requisitos acordada com os patrocinadores do projeto.
Também podem ser definidas, nesta etapa metas que o projeto deverá cumprir.
• Medir o desempenho do processo que está sendo executado em um projeto,
fazendo coleta de prováveis pontos falhos (defeitos) do processo.
• Analisar os resultados das métricas obtidas na etapa anterior, determinando suas
possíveis causas.

Segundo PMI (2017), problemas podem surgir como resultado dos ciclos de
auditoria ou revisão técnica, podendo ser utilizados métodos que envolvam as seguintes
etapas para definir e aplicar as respectivas soluções:

70
• identificação e definição do problema;
• buscar definir a causa raiz dos problemas identificados;
• planejar as possíveis soluções;
• selecionar qual a melhor solução para cada problema, muitas vezes em comum
acordo com o cliente (ou partes interessadas);
• implementar a solução escolhida;
• avaliar a eficácia da solução, garantindo que o problema foi efetivamente sanado.

PMI (2017) ainda sugere o método Plan, Do, Check, Act (PDCA – Planejar,
Executar, Monitorar e Agir) como uma forma alternativa de melhoria da qualidade, além
do método seis sigma já mencionado. Cada sigla do método PDCA representa uma
etapa de execução de um ciclo contínuo de revisão e melhorias. O planejamento será
o marco inicial, seguindo da execução do que foi planejado, monitoramento das ações
implantadas com análise crítica de eventuais pontos de atenção e, por fim, a fase de
ação, que irá apresentar quais as soluções de contorno para os problemas encontrados,
assim como ações preventivas para garantir a melhoria contínua.

Pressman e Maxim (2021) e Imoniana (2016) apresentam a necessidade de

se elaborar um relatório final contendo todos os achados e informações relevantes
do processo de revisão técnica, no momento de sua conclusão. Abordaremos tal
documento no próximo subtema.

4 ELABORAÇÃO DO RELATÓRIO DE AUDITORIA E O

PROCESSO DE FOLLOW UP
Para que uma auditoria seja considerada concluída, é importante que o
auditor elabore um relatório final da auditoria, que deverá ser entregue para as partes
interessadas no projeto.

Segundo PMI (2017), o relatório final de auditoria, considerado como um relatório

de qualidade, deverá englobar ações corretivas e de melhoria para o projeto ou processo,
sendo necessário sua apresentação ao gerente de projeto e demais superiores para que
as ações que garantirão uma melhoria do projeto e/ou produto possam ser tomadas.

Um ponto de atenção é que a versão final do relatório de auditoria deverá

contemplar todos os ajustes realizados nos desvios de comportamento encontrados
para as funcionalidades, até que se alcance o nível acordado de qualidade, ou seja, de
adequação das funcionalidades do sistema ao comportamento esperado para elas.

71
 4.1 CONCLUSÃO DA AUDITORIA E O RELATÓRIO FINAL DE
AUDITORIA
Pressman e Maxim (2021) enfatizam a importância de manter, no relatório dos
ciclos de revisões técnicas, informações que apresentem uma ordem cronológica dos
problemas identificados e corrigidos no produto, apresentando uma visão global para
todos os envolvidos no time do projeto.

Segundo Imoniana (2016), as seguintes informações devem constar no relatório

final da auditoria ou revisão técnica:

• Observações gerais – observações que foram constatadas ao longo do processo

de auditoria.
• Consequências – riscos que a Empresa irá correr, caso não siga as sugestões de
melhorias e não realize as correções apontadas.
• Recomendações – sugestões de melhorias e correções para os itens englobados
no escopo da auditoria.
• Comentários da gerência – resposta da gerência a favor ou contra as sugestões
apontadas, além de definição de um prazo para execução das correções e melhorias.

Sommerville (2011) afirma que, para equipes geograficamente distribuídas, os

relatórios resultantes do processo de avaliação técnica podem ser elaborados a partir
de inserção de comentários no código fonte do produto, assim como ferramentas de
edição de texto podem ser utilizadas para apresentar comentários sobre problemas
identificados ou eventuais necessidades de ajustes em documentações. Para projetos
que fazem uso de metodologias ágeis, é possível que os problemas encontrados sejam
comunicados de maneira informal a todo o time, podendo fazer uso da reunião diária do
time para essa finalidade.

Imoniana (2016) apresenta algumas situações nas quais é possível que relatórios
parciais sobre o processo de revisão técnica ou auditoria sejam emitidos, contendo
informações parciais do processo, sendo elas:

• Ao se constatar um fato importante, que poderá causar prejuízos financeiros, deve

ser imediatamente comunicado à gerência ou diretoria. Estas situações irão requerer
intervenção imediata, por isso não podem esperar até a finalização de todo o ciclo.
• Reporte do andamento do processo, em versões parciais, aos membros da diretoria
ou gerência. Esses relatórios poderão auxiliar na tomada de decisões estratégicas
sem precisar aguardar a finalização de todo processo.
• Reporte de todo processo, porém antes da compilação do relatório final de auditoria.
• Parecer final do auditor sobre todo o processo, caracterizando o relatório final de
auditoria.

72
 Pressman e Maxim (2021) e Sommerville (2011) enfatizam a importância do
resultado apresentado ao final do processo de revisão técnica para a tomada de decisões
estratégicas da Empresa, além de servir como base de conhecimento para outros
projetos. Apresentaremos, no próximo subtema, a importância de tais informações para
os setores estratégicos da Organização.

4.2 A IMPORTÂNCIA DA AUDITORIA PARA SETORES

ESTRATÉGICOS DA EMPRESA
Sommerville (2011) índica a importância dos processos de auditoria e revisão
técnica para a tomada de decisões gerenciais em projetos pelos gerentes de projeto.
É possível identificar, por exemplo, a necessidade de inclusão de mais um membro
no time de desenvolvimento a partir dos dados coletados acerca do processo de
desenvolvimento, em comparação com o planejamento inicial. Apesar de serem úteis
para a tomada de decisões gerenciais, os dados resultantes do processo de revisão
técnica não irão substituir as revisões de progresso, necessárias para o acompanhamento
do progresso real do projeto em comparação com o planejado.

Todo processo de auditoria visa garantir uma qualidade mínima para um produto,
serviço ou evento realizado. Para produtos, como os de TI, é possível que a Empresa
tenha adotado um padrão de qualidade que reflita a não ocorrência de erros impeditivos
em aplicações desenvolvidas por ela. Dessa forma, os ciclos de auditoria irão garantir
que os sistemas sejam entregues dentro dos parâmetros acordados para a qualidade
esperada. Já para eventos, por exemplo, uma auditoria deverá garantir que pontos
falhos em uma edição possam ser melhorados para edições futuras nesse mesmo
evento. Para prestação de serviços, a auditoria garante que os serviços se mantenham
dentro de um padrão de qualidade, com a menor quantidade possível de insatisfações
dos clientes e retrabalho.

Em Empresas de Tecnologia da Informação, o processo de auditoria acontece

através de ciclos de Testes de Software ou de métodos de Garantia da Qualidade (do
inglês Quality Assurance – QA), podendo abranger análise manual do código ou através
da utilização de alguma ferramenta de automação, como a SonarQube.

NOTA
A ferramenta SonarQube tem o objetivo de realizar revisão de código de
forma automatizada, auxiliando na manutenibilidade do código, por manter
o código da aplicação limpo, ou seja, de fácil leitura e manutenção. Sendo
de código aberto, poderá ser encontrada para download em https://www.
sonarsource.com/products/sonarqube/.

73
 ATENÇÃO
Sommerville (2011) enfatiza que o setor responsável pela QA não deverá
se envolver com nenhuma etapa de nenhum projeto, tendo em vista que
deverá manter sua imparcialidade. Os testes executados nos produtos de
software têm como objetivo encontrar divergências quanto aos requisitos
inicialmente especificados.

Pressman e Maxim (2021) conceituam qualidade de software como a aderência

dos requisitos implementados em face aos planejados. Então, quanto mais perto do
objetivo planejado com os requisitos especificados para uma aplicação, maior será a
qualidade do software construído.

Segundo Sommerville (2011), a qualidade de um projeto é determinada por três

aspectos fundamentais:

• o estabelecimento de processos organizacionais para desenvolvimento de software

e os padrões adotados para elaboração da documentação necessária;
• a adoção de práticas que envolvam qualidade ao longo do andamento dos projetos,
entregando os documentos e demais entregáveis, conforme os padrões acordados
para cada projeto;
• estabelecimento de um plano de qualidade, com cumprimento das metas de
qualidade para cada projeto.

IMPORTANTE
Tanto Sommerville (2011) quanto Pressman e Maxim (2021) enfatizam
que a qualidade de um projeto deverá atender às expectativas do cliente,
agregando valor ao seu negócio e garantindo sua satisfação, pois, caso
contrário, o projeto se tornará inútil.

Também é possível que avaliações manuais do código aconteçam por membros

do time de QA, com o intuito de se certificar que as boas práticas acordadas (como
adoção de padrões de projeto) estejam sendo cumpridas pelo time, assim como é
possível inserir auditoria diretamente no código da aplicação, quando operações
essenciais (definidas pelo usuário) terão seu histórico armazenado (como operações de
inclusão, alteração e exclusão em registros).

74
 Como forma de tomada de decisões estratégicas, um processo de auditoria
poderá auxiliar, por exemplo, a definir quais produtos deverão ser produzidos para a
próxima estação do ano, conforme os resultados obtidos pelos processos de auditoria
da mesma estação do ano anterior, quais ações de marketing tiveram melhor aceitação
do público consumidor, quais produtos devem ter sua produção suspensa pela má
aceitação e assim por diante.

Empresas planejam metas para os próximos meses, semestres ou anos, de

modo que, ao longo do tempo, podem estar se distanciando das metas traçadas, sem
que os desvios sejam identificados de forma fácil. Os ciclos de auditoria, portanto, serão
fundamentais para identificar possíveis desvios de rota e ajustar os pontos necessários
para garantir que as metas a curto, médio e longo prazo possam ser alcançadas.

Segundo apresentado por Pressman e Maxim (2021) e Sommerville (2011),

todo ciclo de revisões técnicas de um produto fornecerá subsídios para a melhoria
contínua do processo de desenvolvimento ou do próprio produto. No próximo subtema,
apresentaremos o processo de melhoria contínua e a tarefa de acompanhamento do
projeto (follow up).

4.3 O PROCESSO DE MELHORIA CONTÍNUA E O FOLLOW UP

Imoniana (2016) afirma que todo ciclo de auditoria deverá ter como objetivo a
melhoria contínua do alvo que será auditado, seja projeto de construção de software,
processo ou realização de um evento. É importante que os pontos falhos detectados em
um ciclo de auditoria possam ser corrigidos e, para os próximos projetos, os erros sirvam
como lições aprendidas, compondo um banco de conhecimento.

Para serviços, o processo de auditoria deverá otimizar suas etapas, de modo

que recursos possam ser economizados e o resultado otimizado. Quando mencionamos
recursos, estamos falando em matéria prima, recursos humanos, tempo de produção e
entrega e pós-venda. Fazer o esperado, com os recursos estritamente necessários, sem
desperdícios e retrabalho.

Às vezes, são necessários diversos ciclos para que os problemas impeditivos

para a utilização de uma aplicação ou serviço possam ser corrigidos e as melhorias
possam ser implementadas. Este processo de análise – ajustes – reanálise é que
conhecemos como follow up. O auditor só terá seu trabalho finalizado após todos os
ciclos necessários de follow up terem sido efetivamente concluídos, indicando que a
qualidade básica necessária para entrega do produto ou serviço foi alcançada.

Segundo Pressman e Maxim (2021), a tarefa de acompanhamento do processo

de análise técnica é necessária para garantir que os itens apresentados na lista de
problemas detectados pela equipe envolvida no processo sejam efetivamente corrigidos,

75
 evitando que problemas previamente identificados sejam deixados de lado. Pode-se
atribuir ao líder da equipe de revisão técnica a tarefa de realizar esse acompanhamento.

Segundo Sommerville (2011), a utilização de técnicas para detectar falhas em

produtos pode servir como uma forma de melhoria contínua não só do produto avaliado,
mas também das próprias técnicas utilizadas para detecção de problemas. É possível
que defeitos sejam encontrados em diferentes partes de uma aplicação, como nos
dados gerados, na lógica de controle, no processo de entrada/saída, na interface com o
usuário, na etapa de armazenamento dos dados e no tratamento de exceções.

Pressman e Maxim (2021) apresentam algumas diretrizes básicas para a

realização das revisões técnicas:

• É preciso manter o foco no produto, não em quem o desenvolveu. Dessa forma,

espera-se que os problemas encontrados sejam apresentados aos membros do
time de desenvolvimento de maneira sutil e educada, evitando conflitos de egos e
debates acalorados.
• É necessário organizar um cronograma e o seguir efetivamente. Uma vez que a
reunião de apresentação dos resultados de um ciclo de revisão técnica tenha se
iniciado, é preciso manter o foco e evitar dispersões dos membros do time.
• Eventuais debates devem ser limitados e discutidos posteriormente. Isso evitará
gastar muito tempo e energia com debates nos quais não se chega a um acordo
entre as partes.
• Não tentar resolver todos os problemas identificados, mas mostrar ciência que eles
existem.
• A reunião de apresentação dos resultados do ciclo de revisão técnica não é o melhor
momento para resolução de eventuais problemas, que poderão acontecer em
momentos posteriores.
• Realizar apontamentos sobre as prioridades e os itens que necessitam de atenção.
• Definir um limite na quantidade de pessoas envolvidas na reunião, mantendo apenas
o mínimo necessário para que a reunião aconteça. Também é importante realizar
um planejamento prévio dos pontos que serão abordados (pauta da reunião).
• Definir critérios de avaliação específicos para cada item do projeto que será avaliado.
• Alocar os recursos necessários para os ciclos de revisão técnica, planejando um
tempo de execução para as reuniões.
• Garantir que todos os envolvidos nos ciclos de revisões técnicas tenham sido
previamente treinados.
• Executar uma revisão das diretrizes adotadas para os ciclos de revisões técnicas.

Nem sempre uma auditoria irá garantir que o produto (como uma aplicação, por
exemplo) está totalmente livre de bugs. Eventualmente, podem ainda existir ajustes a
serem feitos, como manutenções adaptativas, ajustes de ortografia ou no esquema de
cores acordado com o cliente. Todavia, esses problemas não são considerados erros
que impedirão o usuário final de utilizar o sistema construído, o que não configura um
impedimento para a entrega do produto e finalização do projeto.

76
 Acadêmico, neste tema de aprendizagem abordamos a importância de planejar
e implementar um ciclo de auditoria ao longo do andamento de projetos, com o objetivo
de acompanhar se o planejado está, de fato, sendo executado. Também foram explicados
os princípios básicos que o auditor deverá seguir, como a ética, coleta de evidências e
imparcialidade.

Segundo CMMI (2017), podemos resumir as etapas do ciclo de uma auditoria

com as atividades de preparação, execução, elaboração do relatório, identificação dos
eventuais pontos de melhoria dos processos de software e, por último, a realização do
acompanhamento (follow up) com a implementação das recomendações apresentadas
no relatório gerado.

77
 LEITURA
COMPLEMENTAR
A IMPORTÂNCIA DO GERENCIAMENTO DE CONFIGURAÇÃO PARA O CICLO DE
VIDA DO SOFTWARE: UM ESTUDO DE CASO BASEADO NAS DIRETRIZES DA
ENGENHARIA DE SOFTWARE

Mariana Magalhães Malhone

Mônica Frigeri

1 INTRODUÇÃO

A necessidade de uma Gestão de Qualidade (GQ) adequada atrelada à Gestão de

Projetos (GP) vem crescendo em grande escala nas empresas de desenvolvimento de
software. A manutenção do ciclo de vida do software em período de desenvolvimento,
a preocupação de relatar todos os problemas envolvidos, os artefatos modificados e a
manutenção de um histórico dessas mudanças demonstram uma preocupação com a
qualidade envolvida no produto.

Durante o período de desenvolvimento de um software, diversos fatores podem

levar à necessidade de alterações, desde bugs3 encontrados em testes de qualidade de
software, novos requisitos solicitados para o produto e até a modificação de dados. A
partir disso, entra em cena o Gerenciamento de Configuração de Software (GCS), com
a responsabilidade de identificar, organizar, controlar essas modificações e minimizar
esses erros.

Segundo Pressman e Maxim (2016, p. 624), a Primeira Lei de Engenharia de

Sistemas [Ber80] destaca que “não importa onde você esteja no ciclo de vida do sistema,
o sistema mudará, e o desejo de alterá-lo persistirá por todo o ciclo de vida”, porém
muitas empresas ainda não conseguem mensurar tamanha importância da inserção
do Gerenciamento de Configuração de Software em seu processo de GQ e GP. Com
isso, não ficam documentadas todas as mudanças realizadas e versões antigas podem
acabar ficando indisponíveis.

O processo de Gestão de Configuração de Software mostra-se, além de uma

preocupação do Projeto de garantir uma base de dados e rastreamento do produto,
uma garantia da qualidade do software aplicável em todo o processo do software. Esses
processos citados são tomados “quando um projeto de engenharia de software começa,
e terminados quando o software sai de operação” (PRESSMAN; MAXIM, 2016, p. 624).

78
 2 GERENCIAMENTO DE PROJETOS DE SOFTWARE

O gerenciamento de projetos de software é uma parte essencial da engenharia

de software, pois os projetos precisam ser gerenciados devido aos orçamentos
organizacionais e cronogramas a serem seguidos. O papel do gerente de projetos, nesse
contexto, é garantir que o projeto atenda essas questões e entregue um software de
qualidade. Segundo Sommerville (2011, p. 414), as metas para alcançar o sucesso são,
respectivamente:

• fornecer o software ao cliente no prazo estabelecido;

• manter os custos gerais dentro do orçamento;
• entregar o software que atenda às expectativas do cliente;
• manter uma equipe de desenvolvimento que trabalhe bem e feliz.

Tal planejamento mantém-se em um nível mínimo, onde a equipe escolhe sua

estratégia, limitada aos requisitos do projeto e padrões organizacionais. Um exemplo de
metodologia ágil muito utiliza hoje é a metodologia Scrum.

De acordo com Pressman e Maxin (2016, p. 78), “Scrum é um método de

desenvolvimento ágil de software concebido por Jeff Sutherland e sua equipe de
desenvolvimento no início dos anos 1990”. Os princípios do Scrum são utilizados
para orientar as atividades de desenvolvimento e incorporam as seguintes atividades
metodológicas: requisitos, análise, projeto, evolução e entrega.

• O Scrum pode ser dividido em três fases:

• planejamento geral, onde são estabelecidos os objetivos gerais e a arquitetura de
software;
• ciclos de sprint, onde cada ciclo desenvolve um incremento do sistema;
• e a última fase é responsável por finalizar a documentação exigida (manuais do
usuário, definições do sistema) e são avaliadas as lições aprendidas com o ciclo.

Em cada atividade, as tarefas são realizadas dentro de um padrão de processo,

denominado sprint. O trabalho em si é adaptado e definido de acordo com o problema
em questão e é modificado em tempo real pela equipe Scrum. A Figura 1 representa esse
fluxo:

79
 Figura 1 – Fluxo do processo Scrum

Fonte: adaptada de Pressman e Maxim (2016)

[...]

2.1 GARANTIA DE QUALIDADE DO SOFTWARE

A Garantia de Qualidade de Software (SQA, Software Quality Assurance), é uma

atividade universal aplicada em todo o processo de software e abrange os seguintes
parâmetros: um processo de SQA; tarefas específicas de garantia e controle da
qualidade, prática efetiva de engenharia de software; controle dos artefatos e mudanças
no software; garantia da conformidade com os padrões de software e mecanismos de
medição e geração de relatórios. A Garantia de Qualidade de Software possui atividades
que concentram na gestão de qualidade de software, sendo elas:

• padrões, como ISO e CMMI;

• revisões e auditorias;
• testes de software;
• coleta e análise de erros/defeitos;
• gerenciamento de mudanças;
• educação, como forma de melhorar suas práticas de engenharia de software;
• gerência dos fornecedores;
• administração da segurança;
• proteção, redução de riscos em defeitos ocultos;
• gestão de riscos.

Além disso, a Garantia da Qualidade de Software trabalha para garantir que

atividades como manutenção, suporte on-line, documentação e manuais sejam
produzidas de acordo com a qualidade exigida.

80
 2.1.1 ISO 9000/9001 e CMMI

Os sistemas de garantia de qualidade são criados com o objetivo de ajudar

as organizações a alcançar a satisfação de seus clientes diante das expectativas em
relação aos seus produtos e serviços por meio do atendimento as suas especificações
(PRESSMAN; MAXIM, 2016). Esses sistemas cobrem diversas atividades, como o ciclo de
vida do produto, planejamento, controle, medições, testes e geração de relatórios. A ISO
9000 descreve tais métricas de garantia de qualidade e pode ser aplicada em qualquer
organização, independentemente do ramo.

As empresas, além de estabelecerem as políticas e procedimentos, devem

documentar como seus processos funcionam, definindo e mantendo registros que
comprovem que os processos estão sendo seguidos. Além disso, o manual de qualidade
da organização deve descrever e coletar dados de processos relevantes. A Figura 2
exemplifica os processos essenciais da ISO 9001.

Figura 2 – Os processos essenciais da ISO 9001

Fonte: adaptada de Sommerville (2011)

O CMMI (Capability Maturity Model Integration), criado pelo Software Engineering

Institute, é um modelo de gerenciamento em que o enfoque é voltado para a maturidade
de processos de software. Como trata-se de maturidade, é necessário que tenha um
conhecimento sobre o nível de qualidade que o processo atinge em um resultado
esperado pela organização. Na Figura 3, é possível visualizar os níveis de maturidade:

81
 Figura 3 – Os cinco níveis de maturidade do CMMI

Fonte: adaptada de GROFFE (2019)

[...]

O CMMI possui soluções para as áreas de desenvolvimento, serviços e

gerenciamento. No desenvolvimento, especificamente, devido a criação de soluções
complexas, o ciclo de vida do desenvolvimento de software está se tornando cada dia
mais difícil de gerenciar, causando custos a mais para as organizações e atrasos nas
entregas para o cliente. Com isso, o CMMI utiliza do Gerenciamento de Configuração de
Software como uma KPI4 (Key Performance Indicator) em seu processo para sustentar
práticas que garantam o desenvolvimento do software com qualidade e entregas de
sucesso para os clientes.

2.2 GERENCIAMENTO DE CONFIGURAÇÃO DE SOFTWARE

Os sistemas de software estão em constante evolução e necessitam de

modificações ao longo do ciclo de vida. Estima-se que tais modificações cheguem a
consumir cerca de 75% do custo total de sua produção. 20% dos esforços são voltados
para a correção de erros e 80% são utilizados para a manutenção e adaptação das funções
do software. O Gerenciamento de Configuração surgiu da necessidade de controlar
essas mudanças por meio de métodos e ferramentas, maximizando a produtividade
do desenvolvimento da solução e minimizando erros durante sua evolução (DANTAS,
2018).

O Gerenciamento de Configuração de Software pode ser visto sob duas

perspectivas: na perspectiva gerencial e na perspectiva do desenvolvimento. Na
perspectiva gerencial, o GCS possui quatro atribuições, sendo elas: identificação;

82
gerenciamento de alterações; facilitação em versionamento; qualidade do produto. Já
na perspectiva do desenvolvimento, engloba três sistemas: controle de modificações,
controle de versões e gerenciamento de construção.

Tal metodologia é considerada como um suporte que beneficia a Gestão de

Projetos, desenvolvimento, atividades de manutenção, garantia de qualidade e os
clientes usuários da solução. A Figura 4 esquematiza o que o GCS abrange e suporta
como um todo.
[...]

Figura 4 – Divisão de Tópicos de Gerenciamento de Configuração de Software

Fonte: adaptada de Bourque e Fairley (2014)

[...]

4 RESULTADOS E DISCUSSÃO

Como resultado do estudo de caso, foi possível comprovar que o Gerenciamento

de Configuração é de extrema importância, sendo o ponto chave da garantia de
qualidade durante todo o ciclo de vida e desenvolvimento do software, o que também
garante a entrega da solução para o cliente de forma satisfatória e precisa, promovendo,
assim, um processo eficiente e eficaz. O GCS mostra-se em uma posição com grande
poder decisivo, onde desde o desenvolvedor até a gerência utiliza como referência para
a precisão de informações.
[...]

83
 Quando uma empresa insere o gerenciamento de configuração em seu
processo, mostra-se interessada em manter a qualidade de seu portfólio e ter uma
organização e controle como algo essencial, fazendo parte de sua identidade. Para o
Guia PMBoK (PROJECT MANAGEMENT INSTITUTE, 2017), a qualidade traduz o plano
de gerenciamento dela com atividades que incluam a política de qualidade no projeto
em si, assim, facilitando a identificação de causas da má qualidade e melhorando o
cumprimento dos objetivos.
[...]

Fonte: https://www.fateccampinas.com.br/rbti/index.php/fatec/article/view/29. Acesso em: 1 fev. 2023.

84
 RESUMO DO TÓPICO 3
Neste tópico, você aprendeu:

• A auditoria é um processo que pode ser realizado para averiguar um processo,

produto ou evento acerca do que foi especificado para tal, tendo o auditor papel
fundamental neste processo.

• Todo processo de auditoria precisa seguir os princípios básicos da ética,

imparcialidade, evidência, competência e planejamento para que o relatório final
seja válido para agregar valor ao produto auditado.

• É preciso seguir uma metodologia em conformidade com o propósito do que será

auditado, sendo necessário executar um planejamento do escopo abordado em
cada ciclo de auditoria.

• A auditoria em Empresas de desenvolvimento de software se dá através de

práticas de QA, que têm por objetivo garantir que os requisitos planejados estão em
concordância com os implementados.

85
 AUTOATIVIDADE
1 Um processo de auditoria tem o objetivo de avaliar um processo, evento ou
aplicação para garantir que os requisitos implementados estão apresentando um
comportamento coerente com o desejado. Para se iniciar um ciclo de auditoria, o
auditor deverá realizar diversas etapas preliminares. Sobre as etapas iniciais para a
execução de um ciclo de auditoria, assinale a alternativa CORRETA:

a) ( ) A configuração de variáveis de ambiente no sistema operacional que irá executar

a aplicação se mostra como uma etapa inicial do processo de auditoria.
b) ( ) As entrevistas de auditoria se mostram fundamentais para as etapas iniciais de
um ciclo de auditoria.
c) ( ) Dentre as etapas iniciais de um ciclo de auditoria, a definição do escopo se
mostra uma das mais importantes.
d) ( ) A configuração das ferramentas de apoio ao processo de auditoria se mostra
uma etapa importante no processo inicial da auditoria.

2 Os tipos de auditoria podem servir de balizadores para garantir a qualidade do

produto ou serviço que será entregue. Em muitas Organizações, equipes dedicadas
ao processo de auditoria são formadas, visando garantir os princípios básicos da
auditoria. Com base nas definições dos tipos de auditoria, analise as sentenças a
seguir:

I- A auditoria de terceiro nível tem o objetivo de capturar desvios de comportamento

das funcionalidades implementadas ainda na fase de codificação, sendo realizada
pelos próprios membros da equipe.
II- A auditoria de segundo nível visa homologar, junto ao cliente, as funcionalidades
desenvolvidas, garantindo que os requisitos atenderão às reais necessidades do
cliente.
III- Auditorias precisam ser realizadas periodicamente para que a qualidade acordada
com o cliente seja atingida.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças II e III estão corretas.
d) ( ) Somente a sentença III está correta.

3 O processo de auditoria precisa ser executado seguindo etapas bem definidas, de

forma a seguir um ciclo. Sobre o processo de auditoria, classifique V para as sentenças
verdadeiras e F para as falsas:

86
( ) Uma auditoria deverá ter as etapas de planejamento, entrevistas de auditoria e
elaboração de relatório final.
( ) Os ciclos de auditoria finalizam, para um projeto específico, quando os pontos
apontados como correções e melhorias forem devidamente implementados.
( ) Um processo de auditoria deverá seguir uma metodologia condizente com o atual
estado do produto ou serviço que será auditado.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – V – V.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 Técnicas de auditoria são especialmente úteis para cada situação em que o auditor
se deparar em sua vida profissional. Dessa forma, existem técnicas, especialmente,
voltadas para a análise de sistemas da informação e para cada propósito das partes
interessadas e o estado atual da aplicação que será analisada. Disserte sobre a técnica
de simulação paralela, apresentando quais os cenários mais indicados para utilização
dessa técnica e qual a vantagem para a execução dos testes nas funcionalidades do
sistema.

5 Existem diferentes situações nas quais um relatório de auditoria pode ser emitido,
sem esperar pela finalização do ciclo de auditoria. Nesse contexto, disserte sobre
quais as situações passíveis de emissão de relatórios parciais de auditoria.

87
 REFERÊNCIAS
BAHAMDAIN, S. S.; ALKAZEMI, B. Y. Toward a Reference Model for Adopting Software
Continuous Delivery: a Practical Approach. J. Software Eng., [s. l.], v. 12, n. 1, p. 12-19,
2018.

BALDO, D. Implantação da Integração Contínua e seus benefícios: um estudo de

caso, 2012, 60 p. TCC (Pós Graduação Lato Sensu em Qualidade de Software) – Uni-
versidade do Vale do Rio dos Sinos, São Leopoldo, 2012.

BRAGA, F. A. M. Um panorama sobre o uso de práticas DevOps nas indústrias de

software, 2015, 123 p. TCC (Pós-graduação em Ciência da Computação) – Universida-
de Federal de Pernambuco, Recife, 2015.

CAROLI, P. Lean inception: como alinhar pessoas e construir o produto certo. 1. ed.
Atualizada. São Paulo: Editora Caroli, 2018.

CMMI. CHANGE MANAGEMENT METHODS IMPLEMENTIATION. CMMI para Desenvolvi-

mento – Versão 1.2, 2006. Disponível em: https://resources.sei.cmu.edu/asset_files/
WhitePaper/2006_019_001_28945.pdf. Acesso em: 2 fev. 2023.

CMMI. CHANGE MANAGEMENT METHODS IMPLEMENTIATION. Process & Product

Quality Assurance (PPQA), 2017. Disponível em: http://cmmi.co.uk/cmmi/PPQA.htm.
Acesso em: 1 fev. 2023.

FILHO, W. P. P. Engenharia de Software – Projetos e Processos. V. 2. 4. ed. Rio de

Janeiro: LTC, 2019.

FONSECA, V. H.; NUNES, D. M. S.; SANTANA, C. M. AMOSTRAGEM: conhecimento e uso

em empresas de auditoria. RAGC, [s. l.], v. 4, n. 16, 2016.

FONTES, E. Segurança da Informação – Orientações práticas. São Paulo: Editora

Kindle, 2016. E-book.

HUMBLE, J.; FARLEY, D. Entrega Contínua: como entregar software de forma rápida
e confiável. Porto Alegre: Bookman, 2014.

IMONIANA, J. O. Auditoria de Sistemas de Informação. 3. ed. São Paulo: Atlas, 2016.

LARSON, E. W.; GRAY, C. F. Gerenciamento de Projetos – O processo gerencial. 6. ed.

Porto Alegre: AMGH Editora Ltda, 2016.

88
MAXIMIANO, A. C. A.; VERONEZE, F. Gestão de Projetos – Preditiva, ágil e estratégica.
6. ed. Barueri: Atlas, 2022.

MELO, J. L. et al. Gerenciamento Ágil De Projetos – Guia de referência com as prin-

cipais metodologias e frameworks ágeis do mercado. 1. ed. Rio de Janeiro: SF Editorial,
2021.

MORAIS, I. S. D.; ZANIN, A. Engenharia de software. Porto Alegre: SAGAH, 2017.

NETO, F. G. P. DevOps: CI e CD. Edição do Kindle, 2022. E-book.

PMI. A guide to the project management body of knowledge (PMBOK Guide).

Upper Darby: Project Management Institute, 2000.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissio-

nal. 9. ed. Porto Alegre: AMGH, 2021.

PRESSMAN, R. S. Engenharia de Software. 3. ed. São Paulo: Makron Books, 1995.

PROVINCIATTO, M.; CAROLI, P. Sprint a Sprint: erros e acertos na transformação cul-

tural de um time ágil. São Paulo: Editora Caroli, 2020.

SOMMERVILLE, I. Engenharia de Software. 9. Ed. São Paulo: Pearson Prentice Hall,

2011.

SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2.

ed. São Paulo: Leya, 2016.

TERENTIM, G.; GONÇALVES, V. Gestão de Mudanças em Abordagens Ágeis. Rio de

Janeiro: Brasport, 2020.

TUFFLEY, D. Software Configuration Management: A How To Guide for Project Sta-

ff. Ed. Altiora Publishing, 2017. E-book.

VALENTE, M. T. Engenharia de Software Moderna – princípios e práticas para de-

senvolvimento de software com produtividade. Edição do Kindle, 2020. E-book.

89
90
 UNIDADE 2 —

TÉCNICAS PARA O
GERENCIAMENTO DE
PROJETOS E CONFIGURAÇÕES

OBJETIVOS DE APRENDIZAGEM
A partir do estudo desta unidade, você deverá ser capaz de:

• conhecer as técnicas de gestão de projetos em detalhes;

• conhecer a dinâmica de uma equipe ágil e as principais cerimônias das metodologias

ágeis;

• identificar os fatores críticos de sucesso para a gestão de projetos e configuração;

• saber aplicar técnicas de auditoria voltadas para o gerenciamento de configurações;

PLANO DE ESTUDOS
A cada tópico desta unidade você encontrará autoatividades com o objetivo de
reforçar o conteúdo apresentado.

TEMA DE APRENDIZAGEM 1 – GESTÃO DE PROJETOS PREDITIVA

TEMA DE APRENDIZAGEM 2 – GESTÃO ÁGIL DE PROJETOS

TEMA DE APRENDIZAGEM 3 – A GERÊNCIA DE CONFIGURAÇÃO COMO ESTRATÉGIA

PARA O GERENCIAMENTO DE UM PROJETO DE SOFTWARE

CHAMADA
Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure
um ambiente que facilite a concentração, assim absorverá melhor as informações.

91
 CONFIRA
A TRILHA DA
UNIDADE 2!

Acesse o
QR Code abaixo:

92
UNIDADE 2 TÓPICO 1 —
GESTÃO DE PROJETOS PREDITIVA

1 INTRODUÇÃO
Segundo Pressman (2016), Sommerville (2011), Maximiano e Veroneze (2022), o
método de Gestão de Projetos Preditivo irá focar na fase do planejamento detalhado de
todas as nuances do projeto, antes que este se inicie.

Segundo Frame (1995), na gestão de projetos o foco principal é certificar que o

desenvolvimento das atividades seja executado respeitando o prazo, orçamento e o que
foi especificado, para atender as expectativas do cliente.

INTERESSANTE
Segundo PMI (2009), são investidos por ano cerca de US$ 12 trilhões em
projetos mundialmente, isso equivale a 25% do PIB mundial.

Dentre as instituições focadas em desenvolver técnicas para gerenciamento

de projetos, uma das mais conhecidas atualmente é o Project Management Institute
(PMI) que surgiu em 1969 e está localizada nos Estados Unidos (PMI, 2014); também
existem outas instituições como International Project Management Association (IPMA)
e Projects IN Controlled Environments (PRINCE). Ao longo deste tema de aprendizagem,
abordaremos cada um destes conceitos básicos em sua essência, apresentando os
principais pontos a serem observados e como o planejamento deve ser feito, seguindo
a metodologia preditiva.

Essas instituições visam difundir técnicas e padrões para gerenciar qualquer

tipo de projeto, além de construírem métodos de gerenciamento de projetos tradicionais
que também são denominados de preditivos.

Segundo Rabetti e Rodrigues (2021), o método de Gestão de Projetos Preditivo

foca em estruturar muito bem a fase do planejamento, contemplando todas as nuances
do projeto, antes que este se inicie, além de ser feito o controle e as documentações
para todas as decisões.

Dessa forma, será essencial planejar os recursos necessários, o custo (com

o respectivo orçamento), o cronograma e os riscos envolvidos no projeto, de modo a
garantir uma melhor previsibilidade em sua execução. O que reforça a categorização
desse método como tradicional ou clássico.
93
 Segundo Maximiano e Veroneze (2022), esse modelo de gestão irá se preocupar
também com três conceitos essenciais:

• ciclo de vida do projeto;

• processo de gerenciamento do projeto;
• desempenho do projeto.

Cada um destes conceitos básicos estará organizado nos próximos subtemas,

juntamente com os principais pontos a serem observados de como o planejamento
deve ser feito seguindo a metodologia preditiva. Acadêmico, ao longo deste Tema de
Aprendizagem iremos abordar a Gestão da Entrega (Subtema 2), seguindo da Gestão das
Atividades e cronograma (Subtema 3), da Gestão de Cursos e do Orçamento (Subtema
4), Gestão da Qualidade (Subtema 5) e Gestão da Equipe (Subtema 6).

2 GESTÃO DE ENTREGA
Segundo Sommerville (2011), ao se iniciar um novo projeto, um produto deverá
ser contemplado como resultado. Este produto é conhecido como entregável do projeto
e será o foco de todo trabalho que será desenvolvido pela equipe que trabalhará no
projeto, sendo construído etapa por etapa até sua finalização.

Sabendo que o método preditivo realiza o controle do planejamento do projeto

no seu início, mesmo que o plano de projeto seja revisto durante a execução, este
método não contempla mudanças durante a execução (CONFORTO, 2009). Logo, suas
entregas podem se tornar obsoletas e sem alto valor para o cliente.

A gestão de entrega no método preditivo, apresentou alguns problemas durante

sua utilização, dentre eles, as baixas taxas de sucesso, sendo um problema relacionado
à entrega, visto que decorre dos atrasos nas entregas, o que também tornava, em
diversas situações, essas entregas desnecessárias (AGILE BUSINESS CONSORTIUM,
2014).

Maximiano e Veroneze (2022) enfocam a importância, contudo, de que este

entregável tenha seus limites bem definidos, o que denominamos escopo do projeto,
devendo englobar todos os entregáveis do projeto. Um entregável, ao final de um
projeto, compreende toda a documentação que será gerada (como elaboração de
manuais de utilização), assim como eventuais treinamentos necessários e o próprio
produto construído. Estas necessidades, todavia, devem ser mapeadas ainda na etapa
de planejamento do projeto, quando se trata da utilização de métodos preditivos.

Apresentaremos o processo de Gestão do Escopo com maiores detalhes no

próximo subtema.

94
2.1 GESTÃO DO ESCOPO
Segundo Fleming e Koppelman (2005), a definição do escopo é a etapa de maior
importância para o sucesso de qualquer tipo de projeto. Tendo em vista que será a partir
de sua delimitação que todas as outras etapas de planejamento irão se basear, como o
cronograma, recursos necessários, dentre outras variáveis.

De acordo com Camargo (2007), o nível mais alto de abstração está nas primeiras
etapas do projeto, dessa forma é preciso maior empenho para o entendimento, por
causa da dinâmica complexa que ele apresenta.

Pressman (2016) afirma que tudo aquilo que não estiver previsto como
entregável ao final do projeto, não poderá ser inserido no planejamento após o projeto
ter sido iniciado.

Métodos preditivos precisam de muita previsibilidade em suas variáveis

analisadas, como a necessidade do orçamento, a quantidade e os tipos de recursos
alocados e disponíveis para o projeto e por quanto tempo estes recursos precisarão
estar disponíveis.

Qualquer alteração no escopo do projeto, após a finalização da etapa de

delimitação do escopo, irá impactar negativamente nessas variáveis, sendo totalmente
contraindicada. Esse escopo fechado pode prejudicar o projeto, porque nem sempre o
cliente tem conhecimento de todas as funcionalidades necessárias em seu produto ou
serviço, antes que o projeto tenha início.

INTERESSANTE
Sutherland (2016) afirma que, em metodologias ágeis, porém, é possível realizar
ajustes no escopo inicialmente definido, como a alteração na priorização
das funcionalidades que serão implementadas, conforme a necessidade do
cliente.

Quando nos referimos ao produto que será elaborado pelo projeto, seu escopo
estará se referindo às necessidades que serão entregues pela aplicação, ou seja, aos
requisitos funcionais e não funcionais que deverão constar no produto resultante.

Segundo Pressman (2016), a definição do escopo do produto deverá, por

consequência, delimitar até que ponto o produto irá englobar as funcionalidades
específicas de um determinado domínio de negócio.

95
 IMPORTANTE
Zasa e Pellizzoni (2021) explicam que é perfeitamente possível utilizar dos
métodos preditivos em situações que as organizações não pertencem a área
de desenvolvimento de softwares, uma vez que as demais áreas geralmente já
praticam, de forma consolidada, projetos mais tradicionais.

Os métodos preditivos podem ser melhor empregados quando o projeto não

precisa que os usuários estejam constantemente envolvidos durante sua execução ou
que o projeto não apresente um alto nível de certeza do que deve ser implementado,
por possuir seu objetivo claramente traçado e os requisitos já plenamente definidos no
início do projeto, sem que aconteçam mudanças neles (KERZNER, 2013b; CONFORTO;
AMARAL, 2008).

Segundo Papadakis; Tsironis (2020); Shenhar, Milosevic, Dvir e Thamhain (2007),

dois exemplos de projetos que utilizam do método são:

• projetos de rotina operacional;

• projetos de construção ou engenharia.

ATENÇÃO
Wysocki, Beck e Thomas (2014), afirmam que, quando se tratam de projetos
criativos e inovadores, tais como projetos de pesquisa, de desenvolvimento
de novos produtos ou mesmo de melhoria de processos, a abordagem ágil de
gerenciamento de projetos seria a mais adequada.

Figura 1 – Exemplo de entregáveis que compõem o escopo do projeto

Fonte: adaptada de Maximiano e Veroneze (2022)

96
 A Figura 1 apresenta um exemplo de entregáveis que poderão compor o escopo
de um projeto. Além da entrega do produto que será construído, o escopo do projeto
poderá englobar eventuais necessidades de treinamentos, elaboração de manuais de
utilização do sistema ou serviço, além de quaisquer outros documentos necessários
para que o projeto tenha seu estado considerado encerrado.

O escopo do projeto incluirá o escopo do produto, já que o produto é um dos

itens considerados entregáveis pelo projeto em andamento. O escopo do produto
irá incluir a descrição detalhada de todos os elementos e funcionalidades que serão
incluídos na entrega final, os requisitos funcionais e não funcionais necessários para a
codificação do sistema ou prestação do serviço.

ATENÇÃO
Segundo Maximiano e Veroneze (2022), é importante frisar a diferença entre
o escopo do produto e o escopo do projeto. Enquanto o primeiro irá refletir,
apenas, os limites das funcionalidades do produto que deverá ser construído
pelo projeto em andamento, o segundo irá englobar todos os entregáveis do
projeto, que vão além do produto pronto.

Figura 2 – Escopo do projeto X escopo do produto

etc.)

Fonte: adapatada de Pressman (2016)

A Figura 2 ilustra os itens que irão diferenciar o escopo do projeto do escopo

apenas do produto. Enquanto o do projeto terá variáveis para sua conclusão (como o
orçamento previsto, a quantidade de recursos necessários e o tipo desses recursos,
o tempo de alocação deles, o cronograma de entrega e de progresso do projeto), o
escopo do produto irá se preocupar apenas com o que o produto deverá oferecer
de funcionalidades e como estas funcionalidades deverão estar sendo providas

97
 (englobando questões de performance, segurança, auditoria, sistemas operacionais
e eventuais aplicações com as quais o software deverá ter integração, dentre outras
questões que estarão representando os requisitos não funcionais).

ATENÇÃO
O escopo do projeto engloba o escopo do produto, porém o inverso não
é verdadeiro, já que o escopo do projeto deverá englobar outros tipos de
informação, além apenas dos requisitos funcionais e não funcionais da
aplicação.

Em resumo, o escopo do produto é o que o produto deve fazer, enquanto o

escopo do projeto é como o trabalho será realizado para entregar o produto. A gestão do
escopo é um dos elementos-chave no método preditivo de gerenciamento de projetos.
Ela é responsável por definir e controlar os limites do projeto, inclusive pelo que está
incluído e o que não está incluído nas funcionalidades que serão implementadas no
produto.

Uma citação importante sobre a gestão do escopo no método preditivo pode ser
encontrada no livro Project Management: a systems approach to planning, scheduling,
and controlling em que PMI (2013 apud MAIA, 2017, p. 2) escreve: "a gestão do escopo
é a parte mais importante da gestão de projetos, pois é o processo que garante que o
projeto inclua apenas o trabalho necessário para alcançar seus objetivos".

O primeiro ponto de atenção que deve ser definido para o escopo de um projeto
é o objetivo geral do projeto. Isso inclui a definição clara dos resultados esperados e
dos entregáveis do projeto. É importante que todas as partes interessadas concordem
com essas definições para garantir que todos estejam alinhados com o objetivo geral
do projeto.

Segundo Lewis (2005), a primeira coisa que deve ser definida em um projeto
é o seu escopo. Sem um escopo claro, não é possível saber o que é necessário para
completar o projeto com sucesso. É importante utilizar linguagem clara e objetiva
através do verbo transitivo e direto no escopo do projeto, para evitar ambiguidades e
garantir que todos estejam alinhados quanto aos objetivos e entregáveis do projeto.

Como exemplo, podemos utilizar a forma apresentada no Quadro 1.

98
 Quadro 1 – Exemplo de descrição do escopo do projeto

Fonte: adaptada de Sommerville (2011)

Percebamos que, a partir da definição apresentada no Quadro 1, a declaração do

escopo do projeto terá o objetivo primário do projeto que será iniciado, o ganho obtido
com o fruto desse projeto, ou seja, com o produto que será implementado, e a definição
do cliente que será beneficiado, constituindo a parte interessada no projeto.

Essa declaração servirá de norte para que as etapas do projeto consigam ser
elaboradas e acompanhadas da melhor forma, sempre buscando a meta final do projeto:
a concretização do produto inicialmente previsto, que irá atender às necessidades das
partes interessadas, agregando o valor esperado e, consequentemente, obtendo a
satisfação do cliente.

Após a declaração do escopo ter sido elaborada e revisada em conjunto com o

cliente (ou seus representantes e demais partes interessadas no projeto), será necessário
realizar o detalhamento do escopo, destrinchando todas as partes necessárias para se
atingir ao resultado esperado, definido na declaração.

Segundo Larson e Gray (2016), o detalhamento do escopo do produto, por sua vez,
irá ter o objetivo de destrinchar os requisitos funcionais e não funcionais do entregável
principal, de modo a se atingir um nível micro de cada funcionalidade, capaz de ser
implementado pelos membros da equipe sem que hajam dúvidas no entendimento do
que deve ser feito e de como deve ser construído.

Conforme explicam Larson e Gray (2016), quando se atinge o nível máximo

de detalhamento de uma funcionalidade de um produto, fala-se que se definiram os
pacotes de entrega ou pacotes de trabalho. Os membros da equipe de desenvolvimento,
por sua vez, irão atuar em cima desse conjunto de pacotes, considerando o nível de
priorização definido pelo cliente (ou partes interessadas).

Pressman e Maxim (2021) afirmam que uma das formas de detalhamento do

escopo de um projeto é definir quais serão as entregas necessárias e quais as atividades
que devem ser feitas em cada entrega. De forma literal, a ferramenta Estrutura de
Subdivisão do Trabalho (do inglês Work Breakdown Structure – WBS), também
conhecida como Estrutura Analítica do Projeto (EAP), irá “quebrar”, de forma visual,
o trabalho que deverá ser executado em pequenas atividades, de modo que cada fase
ou etapa do projeto possa ter suas atividades bem definidas.

99
 Figura 3 – Exemplo de um WBS

Fonte: adaptada de Larson e Gray (2016)

Percebamos que, como apresentado na Figura 3, o exemplo de um WBS para o

projeto de uma festa de aniversário. O evento aniversário, o foco do projeto, é definido
logo no começo do diagrama, no primeiro nível, tendo suas etapas (ou fases) sendo
definidas no segundo nível, seguindo-se do detalhamento de cada etapa em atividades
que a irão compor.

Em um projeto de desenvolvimento de software, o nível dois deverá ser composto

pelas entregas combinadas com os stakeholders, sendo detalhadas em pequenos
marcos que deverão ser atingidos pela equipe para cada etapa que será concluída.

INTERESSANTE
Segundo Pressman (2016), o diagrama Estrutura Analítica do Projeto (EAP)
também poderá incluir informações sobre o custo e a duração de cada tarefa,
além de poder ser construído levando em consideração a fase do ciclo de
vida do produto que estará sendo desenvolvido pelo projeto em questão ou
o próprio produto.

100
 Segundo Maximiano e Veroneze (2022), quando se considera o critério do
produto para construção do diagrama EAP, deve-se listar todos os produtos que
deverão ser entregues ao final do projeto. Neste cenário, podemos identificar ao menos
três categorias de entregáveis:

• produto que será construído;

• infraestrutura necessária para construir o produto identificado;
• partes interessadas (pessoas envolvidas no projeto, como os clientes ou
participantes).

Conforme apresentado por Larson e Gray (2016), quando o critério utilizado para
construção do diagrama EAP é o produto, é possível listar, ao menos, dois entregáveis:

• o produto em si;
• o processo produtivo para sua construção.

Segundo Larson e Gray (2016), as fases de um projeto também poderão ser

utilizadas para construção do diagrama EAP. Nesse cenário, cada fase ou etapa do projeto
deverá ser descrita no segundo nível, seguindo-se do seu respectivo detalhamento em
atividades.

ESTUDOS FUTUROS
Acadêmico, estudaremos, ainda nesta unidade de ensino, a aplicação do
diagrama EAP para a identificação e análise dos riscos envolvidos em um
projeto.

É importante identificarmos quais as atividades necessárias para a execução

de um projeto, de modo a organizar, de modo sequencial, as tarefas do início ao fim.
Acadêmico, abordaremos com maiores detalhes como as atividades poderão ser
definidas e organizadas em um cronograma no Subtema 3.

3 GESTÃO DAS ATIVIDADES E CRONOGRAMA

Segundo o PMBOK (2004), gerenciamento de projetos é a aplicação de
conhecimento, habilidade, ferramentas e técnicas às atividades do projeto, a fim de
atender seus requisitos.

Portanto, durante a execução de um projeto existem atividades que precisam ser

gerenciadas juntamente com o gerenciamento do cronograma, principalmente quando
o orçamento é reduzido, é necessário qualquer forma de garantir que os projetos sejam

101
 realizados no prazo com qualidade garantida, atendendo a todo o escopo solicitado e
com o custo dentro do previsto (KNOB, 2007).

Abordaremos, no próximo subtema, como a atividade de Gestão das Atividades

de um projeto poderá ser realizada.

3.1 GESTÃO DAS ATIVIDADES

Segundo Pressman (1995), a gestão de atividades no método preditivo inclui
a coleta e análise de dados sobre o desempenho passado de atividades semelhantes,
bem como a identificação de padrões e tendências.

Com base nesses dados, os gerentes de projetos podem desenvolver previsões,

sobre o tempo e o custo, necessárias para concluir determinadas atividades no futuro.
Eles também podem identificar pontos de controle críticos e estabelecer planos de ação
para lidar com possíveis problemas antes que eles ocorram.

Maximiano e Veroneze (2022), afirma que, com a elaboração de um WBS ou

diagrama EAP, as atividades definidas precisarão ser analisadas, de forma detalhada,
para que todos os recursos necessários possam ser identificados, delimitando o tempo
de alocação desses recursos e definindo o tempo de trabalho da equipe em cada tarefa
do projeto.

Segundo Pressman (2016), a sequenciação das atividades, após a correta

identificação de todas as atividades necessárias, será importante para definir a ordem
de prioridade que a equipe deverá seguir para a construção do produto. Ainda é
relevante mencionar que tarefas podem depender de outras atividades ou tarefas, o
que implica que a ordem de execução das tarefas não é, necessariamente, linear. É
possível que algumas tarefas precisem ser executadas primeiro para que outras tarefas
que dependam dela possam ter a sua execução iniciada no tempo estimado pelo
cronograma.

Segundo Maximiano e Veroneze (2022), para se conhecer todas as tarefas

que precedem outras tarefas, uma tabela de precedências poderá ser elaborada,
indicando, de forma visual, todas as tarefas que vão ter precedência e quais as tarefas
que irão compor essas precedências.

A tabela de precedência deverá apresentar a duração de cada tarefa, além da

atividade que deverá preceder (servir de pré-requisito) para cada tarefa listada. É possível
numerar as tarefas para que o processo de identificação das tarefas precedentes possa
ser facilitado.

102
 Quadro 2 – Exemplo de tabela de precedência para as atividades do projeto da festa de aniversário

Tarefas precedentes e durações

Número Atividade Duração Atividade precedente
1 Lista de convidados 2 dias -
2 Elaboração dos Convites 5 dias 1
3 Entrega dos convites 2 dias 1;2
4 Controle de acesso 1 dia 1;2;3
Fonte: adaptado de Maximiano e Veroneze (2022)

O Quadro 2 apresenta um exemplo de tabela de precedência para a etapa de

público, do diagrama apresentado na Figura 3, para o planejamento do projeto da
festa de aniversário. Devemos perceber que cada atividade terá sua duração estimada
especificada, assim como a definição das atividades precedentes. É possível que exista
mais de uma atividade precedente para uma determinada tarefa, como acontece com
a tarefa número 3 (entrega dos convites), que irá depender da tarefa 2 (elaboração dos
convites) e, consequentemente, da tarefa 1 (elaboração da lista de convidados).

ATENÇÃO
Devemos perceber que cada atividade terá sua duração estimada especificada,
assim como a definição das atividades precedentes.

Segundo Pressman (2016), quanto mais tarefas dependerem de uma mesma

tarefa precedente, maior será a prioridade desta tarefa precedente em comum. Dessa
forma, a partir da elaboração da tabela de precedência, será possível definir quais os
níveis corretos de prioridade para cada tarefa, podendo estabelecer um encadeamento
entre as tarefas, através do diagrama de precedências.

O diagrama de precedências irá apresentar, visualmente, o encadeamento das

tarefas, já definido na tabela de precedência, porém em outra forma de visualização
(através de um gráfico). Conforme apresentado por Sommerville (2011), cada atividade
irá representar um nó no diagrama e os nós serão interligados por setas, que irão
representar as dependências entre as tarefas, assim como a ordem na qual cada tarefa
deverá ser executada.

103
 ATENÇÃO
Segundo Pressman (2016), um nó de um diagrama de precedência representa
uma atividade, ou tarefa, que deverá ser executada pelo time que está
envolvido no projeto, de modo a conseguir alcançar o objetivo esperado para
o projeto em andamento.

Figura 4 – Exemplo de diagrama de precedências

Fonte: adaptada de Sommerville (2011)

O diagrama de precedências apresentado na Figura 4 apresenta graficamente

as atividades e a precedência entre elas, definidas no Quadro 1. A precedência entre as
atividades significa um pré-requisito que precisará ser cumprido para que a próxima
atividade possa ser executada. Dessa forma, a atividade 3, por exemplo, só poderá ser
executada após a conclusão das atividades 1 e 2, enquanto a atividade 2 só poderá ser
executada após a conclusão da atividade 1 e assim sucessivamente.

ATENÇÃO
Segundo Sommerville (2011), é importante mencionar que a elaboração do
diagrama de precedências deverá acontecer simultaneamente à elaboração
da tabela de precedências, tendo em vista que o diagrama irá representar
visualmente a interligação entre as tarefas, mapeada na tabela. Caso alguma
falha seja detectada, a partir do diagrama visual, a tabela poderá ser ajustada
e vice-versa.

104
 Então, todas as tarefas que deverão acontecer, do início ao fim do projeto,
deverão estar listadas neste diagrama. Quando adicionamos os tempos estimados de
duração de cada atividade nos nós do diagrama de precedência, temos a capacidade
de calcular o tempo estimado da duração do projeto, a partir das somas dos tempos de
cada atividade.

Todas as tarefas que dependem de tarefas longas para serem executadas,

precisam esperar que essas tarefas longas finalizem, o que acarreta um tempo de folga
para as atividades que possuam durações menores que o tempo necessário das tarefas
com maior duração.

Segundo Maximiano e Veroneze (2022), considerando os maiores tempos para

conclusão de um projeto, temos o que é conhecido pelo método do caminho crítico
(do inglês Critical Path Method – CPM). Este método irá definir os prazos de conclusão
de um projeto com base nas tarefas que tiverem as maiores durações, partindo da tarefa
inicial até a total conclusão do projeto (última tarefa).

Deveremos considerar, utilizando o método CPM, dois caminhos: o caminho de

ida, que irá considerar datas de início e finalização do projeto mais cedo, com base na
duração estimada de cada tarefa; e o caminho de volta, que irá considerar um tempo
de folga entre as atividades, considerando que atrasos nos prazos estimados podem
acontecer.

Pressman (2016) afirma que o caminho de volta, caso todos os prazos estimados
sejam cumpridos rigorosamente, seria o menor prazo possível de início e finalização do
projeto.

Figura 5 – Cenário para aplicação do método do caminho crítico

Fonte: adaptada de Pressman (2016)

105
 A partir da análise da Figura 5, temos os prazos de duração de cada tarefa,
de modo que a tarefa A será a primeira do projeto a ser executada, iniciando no dia
1 e finalizando no décimo dia do andamento do projeto. A partir de então, no décimo
primeiro dia, a tarefa B será iniciada, seguindo até o décimo quinto dia (duração de 5
dias). A última tarefa, nomeada como E, será concluída apenas no quadragésimo terceiro
dia, o que irá indicar que o projeto como um todo terá duração de quarenta e três dias.

Considerando o conceito do caminho de ida apresentado, a menor duração

que o projeto poderá ter será a soma das durações mínimas de todas as tarefas, que,
conforme o apresentado na Figura 5, será de quarenta e três dias, considerando que
nenhum atraso irá impactar nos prazos estimados de cada tarefa.

Seguindo a explicação de Pressman (2016), para calcular o caminho de volta,

ainda considerando os prazos apresentados na Figura 5, deveremos partir do final do
projeto até seu início. Então, a última atividade a ser executada (tarefa E), terá duração
de 3 dias, devendo iniciar no dia 41 (43, 42, 41 – três dias), caso estivéssemos realizando
a contagem regressiva dos prazos para cada atividade, partindo da quantidade de dias
final estimada (43). Sendo assim, o prazo mais tardio que a atividade E poderá iniciar
será o dia 41 (43, 42, 41 – três dias). Deveremos fazer este mesmo procedimento para
todas as tarefas, encontrando os maiores prazos para que cada tarefa possa ser iniciada
e finalizada, conforme apresentado no Quadro 3.

Quadro 3 – Cálculo dos tempos tardios de início e finalização das tarefas

Tarefa Início mais tarde Finalização mais tarde

E Dia 41 Dia 43
D Dia 20 Dia 40
C Dia 16 Dia 19
B Dia 11 Dia 15
A Dia 1 Dia 10

Fonte: adapatada de Pressman (2016)

ATENÇÃO
Devemos observar que o tempo de duração de cada tarefa deverá ser
considerado para o cálculo do caminho de volta. A duração de uma tarefa
independe do dia estimado para seu início e fim, ou seja, é possível estimar
uma quantidade de dias para uma tarefa (período de execução estimado) e,
de modo independente, uma data específica na qual se pretende iniciar a
tarefa, dentro do cronograma do projeto.

106
 Segundo Sommerville (2011), um período de folga entre tarefas poderá existir,
representando dias nos quais não existem tarefas para serem iniciadas. Observemos
que a data da finalização deverá ser sempre considerada primeiro do que a data de
inicialização. A data de finalização de uma tarefa deverá sempre considerar a data de
início da tarefa anterior.

Considerando o apresentado no Quadro 3, é possível perceber que a duração

(em dias) das tarefas e o tempo de início e fim estimado no cronograma do projeto
indicam que, para o projeto exemplo, não existirão dias de folga, o que representa um
alto risco de falha para a execução do projeto, já que um atraso (por qualquer motivo),
irá extrapolar os prazos inicialmente previstos.

Segundo Black (1996), quando o projeto leva em consideração o caminho crítico,

qualquer atraso em uma tarefa (seja em sua finalização ou inicialização) irá impactar
diretamente no projeto, atrasando o cronograma inicialmente planejado.

Maximiano e Veroneze (2022) afirmam que, para saber o tempo de folga entre
tarefas, quando se utiliza o caminho de volta, deve-se calcular a diferença entre as
datas do caminho de volta – caminho de ida, ou seja, a tarefa E, pelo caminho de ida,
estaria iniciando no dia 41 (ES) e finalizando no dia 43 (EF), e, pelo cálculo do caminho
de volta, seu início se daria no dia 41 (LS) e sua finalização no dia 43 (LF). Portanto, a
folga da tarefa E será F = LS – ES = 41 – 41 = 0 (sem folgas), assim se repetindo para as
demais tarefas do projeto.

ATENÇÃO
Quando os prazos de início tardio e antecipado de uma tarefa coincidirem,
não existirá folga para a execução da tarefa.

Após o cálculo dos prazos do projeto tiver sido finalizado, é necessário que
o cronograma do projeto seja elaborado, apresentando a distribuição das atividades
ao longo do tempo, com as indicações dos respectivos marcos de entrega, conforme
explicado pelo mesmo autor.

IMPORTANTE
É importante que o planejamento leve em consideração as datas importantes
do calendário, como feriados, finais de semana e eventuais períodos de férias
dos membros da equipe, já que são fatos que irão impactar na execução do
projeto.

107
 No próximo subtema, apresentaremos o processo de Gestão do Cronograma,
próxima etapa após a finalização da definição do escopo do projeto.

3.2 GESTÃO DO CRONOGRAMA

Após a definição do escopo do projeto e do produto, é necessário elaborar o
cronograma para as atividades do projeto. Segundo Pressman (2016), o cronograma de
um projeto está diretamente relacionado com o orçamento disponível para o projeto.
Todo o planejamento do esforço e tempo necessário para a construção do produto deverá
considerar o orçamento disponível, tendo em vista que o orçamento será calculado com
base em uma expectativa de data de entrega do projeto e seus entregáveis.

Segundo Larson e Gray (2016), um dos fatores críticos do sucesso do projeto está
em se gerir com eficiência o cronograma inicialmente planejado, identificando a tempo
os possíveis desvios dos objetivos e corrigindo-os, de modo a manter o cronograma
sem atrasos. Eventuais descumprimentos do que foi planejado inicialmente poderão
resultar em abandono do projeto, consequência do alto custo que este poderá atingir,
estourando o orçamento previsto.

DICA
É possível, nesta etapa, utilizar softwares específicos para a elaboração do
cronograma, como o Microsoft Project, além de ferramentas gratuitas,
como a SmartSheet (https://pt.smartsheet.com/), OpenProj (https://www.
openproject.org/) e o Gantt Project (www.ganttproject.biz).

Pressman (2016) afirma que, quando se pensa no planejamento do cronograma

do projeto, temos que ter em mente dois cenários:

• Projeto com data fixa – Quando o projeto tem datas de início ou fim (ou ambas) fixas
e o seu planejamento deverá acontecer do fim para o começo. Um bom exemplo são
projetos voltados para uma determinada data comemorativa do ano (como Páscoa
ou Natal), que possui uma data fixa. Caso o projeto atrase a sua conclusão, neste
cenário, perderá o sentido.
• Projeto que deverá ter sua estimativa do início para o futuro – Neste caso, um
novo projeto deverá ser estimado, obtendo-se uma data de conclusão com base
nas estimativas de cada tarefa, seguindo a ordem de acontecimentos e precedência
entre elas.

108
 Todo projeto, quando planejado através de metodologias preditivas ou ágeis,
precisará ter seus custos calculados, de modo a não extrapolar um orçamento
previamente disponível, que os patrocinadores estarão dispostos a arcar. Sendo assim,
no subtema 4, discorreremos sobre a gestão dos custos e orçamento de um projeto.

4 GESTÃO DOS CUSTOS E DO ORÇAMENTO

Segundo Kwok (2018), a gestão de custos e orçamentos no método preditivo
envolve o uso de técnicas de análise de dados, atualmente também conta com a
utilização de inteligência artificial para prever despesas futuras e ajudar a tomar decisões
financeiras informadas. Essas técnicas podem incluir modelos de regressão, análise de
séries temporais e aprendizado de máquina.

Apresentaremos estes conceitos nos próximos subtemas.

4.1 GESTÃO DE CUSTOS

Pressman e Maxim (2021) afirmam que a Gestão de custos é uma área importante
da gestão empresarial que se concentra em controlar e minimizar os custos de produção
de uma empresa. O método preditivo de gestão de custos é uma abordagem que utiliza
modelos matemáticos e algoritmos para prever futuros custos, ajudando as empresas,
informadas sobre investimentos, planejamento financeiro e alocação de recursos, a
tomarem decisões mais assertivas.

Segundo afirma Kaplan e Cooper (1998), os gerentes de projeto se tornam

capazes de tomar decisões a respeito dos projetos a partir da gestão de custos preditiva,
o que permite que ações como a alocação de recursos, investimentos e planejamento
financeiro sejam feitas de forma mais efetiva.

Segundo Sommerville (2011), todo projeto deverá utilizar uma lista específica
de recursos que servirão de base para o seu desenvolvimento. A partir dos recursos
necessários para o desenvolvimento de um projeto, suas respectivas quantidades e
tempos de alocação, o orçamento do projeto será calculado.

Conforme frisado por Pressman (2016), o planejamento dos recursos necessários

para um projeto não é livre de alterações, podendo, ao longo do andamento do projeto
que será executado, sofrer alterações, o que irá impactar diretamente no cálculo do
orçamento. O autor explica ainda que, para cada etapa do projeto que será iniciada, é
preciso realizar uma avaliação dos recursos que serão necessários, analisando se algum
outro recurso, inicialmente não previsto, será necessário ou, caso nenhum novo recurso
seja identificado, se a quantidade dos recursos disponibilizados estará suficiente para a
realização da nova etapa.

109
 O Guia PMBOK (PMI, 2017) e Newell (2002) listam os recursos necessários para
executar uma tarefa de um projeto que pode incluir os seguintes elementos, embora
isso possa variar de acordo com a natureza da tarefa:

• Pessoal – pessoas envolvidas na realização da tarefa, incluindo equipes internas e

externas, contratados e voluntários.
• Tempo – duração estimada para a realização da tarefa, incluindo horas de trabalho
e prazos.
• Materiais – materiais e equipamentos necessários para a realização da tarefa,
incluindo papel, suprimentos de escritório, ferramentas, tecnologias etc.
• Financeiro – orçamento necessário para a realização da tarefa, incluindo gastos
com pessoal, materiais e outros recursos.
• Tecnológico – tecnologias e sistemas necessários para a realização da tarefa,
incluindo softwares, equipamentos e dispositivos.
• Espaço físico – espaço físico necessário para a realização da tarefa, incluindo
salas de reunião, espaços de trabalho, armazenamento etc.
• Conhecimento especializado – conhecimento e habilidades especializadas
necessários para a realização da tarefa, incluindo treinamento, experiência e
certificações.

O tempo de alocação dos recursos, no caso dos membros da equipe de

desenvolvimento, irá influenciar diretamente no orçamento do projeto, tendo em
vista que os profissionais serão remunerados por horas trabalhadas ou pelas entregas
realizadas em um determinado período (mensal, semanal, quinzenal). Então, quanto
mais tempo os recursos humanos permanecerem alocados no projeto, com dedicação
exclusiva, maior será o gasto e, consequentemente, o orçamento necessário.

IMPORTANTE
Segundo Xavier et al. (2005) e Rosenau (1996), as três grandezas – tempo,
recurso e escopo – formam a triple constraint (restrição tripla) de um
projeto e são essenciais para o sucesso. De acordo com Valle et al. (2010), é
imprescindível equilibrar essas três restrições.

Segundo Pressman (2016), uma vez que se determine qual será a métrica
utilizada para cálculo dos custos de cada recurso que será utilizado pelo projeto, o custo
total com cada recurso poderá ser obtido calculando o valor de uma unidade de tempo
de cada recurso em relação ao tempo total que o recurso será necessário ao projeto.

Então, no caso da mão de obra de um membro da equipe de desenvolvimento

de software, por exemplo, o custo homem/hora seja de R$ 100,00, considerando um
profissional sênior, e o tempo de alocação deste profissional no projeto for de 43 dias

110
úteis, com duração de 8 horas ao dia de trabalho, esse profissional passará 344 horas
alocado no projeto, tendo custo total de R$ 34.400,00 ao final do projeto.

Uma das variáveis fundamentais para a Gestão dos Custos de um projeto é a

Gestão de Orçamento, que abordaremos no próximo subtema.

4.2 GESTÃO DE ORÇAMENTO

Maximiano e Veroneze (2022) afirmam que o orçamento final de um projeto
é denominado orçamento global e deverá estar dentro dos parâmetros acordados
inicialmente com as partes interessadas. O orçamento global preditivo é um processo
que usa modelos estatísticos e algoritmos de aprendizado de máquina para prever o
resultado financeiro futuro de uma empresa ou projeto. Esse método se baseia na análise
de dados históricos e informações atuais para fazer previsões precisas e confiáveis
sobre o desempenho financeiro futuro.

De acordo com uma pesquisa publicada no Journal of Business Forecasting

(JBF), "o orçamento global preditivo é uma abordagem mais precisa e eficiente do que
os métodos tradicionais de orçamento, como o orçamento baseado em julgamento ou o
orçamento baseado em tendências históricas" (BOSSONG; SPILT, 2010).

Em muitos casos, a estimativa do orçamento previsto é utilizada pelos clientes

como o valor máximo a ser pago para a Empresa que irá desenvolver o projeto. Qualquer
atraso ou situações adversas que gerem aumento nesse orçamento poderão invalidar
o projeto.

INTERESSANTE
Segundo Chaves & Funes (2015), um estudo publicado na revista Harvard
Business Review afirma que a predição no cálculo do orçamento global de
um projeto pode ter um nível de acerto em cerca de 50%, se comparado aos
métodos tradicionais, permitindo que decisões financeiras sejam tomadas de
uma melhor forma, o que aumentará a eficiência do gasto do orçamento.

Em resumo, o orçamento global preditivo é uma abordagem avançada e eficiente

para a previsão financeira, que pode ajudar as empresas a tomarem decisões mais
assertivas através das informações disponíveis e aumentar a precisão do orçamento.

Para apresentar o orçamento calculado de um projeto, poderemos utilizar uma

tabela com a discriminação de cada recurso necessário, do tempo estimado de alocação
deste recurso por unidade e do custo total. Um exemplo desta apresentação poderá ser
visto no Quadro 4.
111
 Quadro 4 – Exemplo de apresentação do orçamento de um projeto

Tempo de alocação Quantidade

Item Custo unitário Custo Total
no projeto (horas) necessária
Equipe de
344 5 - R$ 123.840,00
desenvolvimento
Programador
2 R$ 50,00 hora R$ 34.400,00
Júnior
Programador
2 R$ 80,00 hora R$ 55.040,00
Pleno
Programador
1 R$ 100,00 hora R$ 34.400,00
Sênior

Fonte: adaptado de Pressman (2016)

Percebamos que, conforme apresentado no Quadro 4, a equipe de

desenvolvimento será composta por dois programadores júnior, dois programadores
plenos e um sênior, sendo que cada perfil terá custos unitários medidos em homem/
hora e com valores diferenciados por perfil.

O Custo total da equipe de desenvolvimento será, então, a soma dos custos totais
de cada perfil. Devermos fazer o mesmo com os demais recursos que serão necessários
para o projeto. Segundo James (2006), dessa forma, é construída a curva de custos do
projeto, que para o método preditivo é uma representação gráfica da relação entre os
custos de um projeto e a quantidade de recursos utilizados para realizá-lo. Ela pode ser
utilizada para avaliar a eficiência econômica de um projeto e para tomar decisões sobre
alocação de recursos.

Figura 6 – Exemplo de apresentação de custos por gráfico

Fonte: adaptada de James (2006)

112
 A Figura 6 apresenta um exemplo de utilização de gráfico para apresentar a
curva do orçamento de um projeto. O intuito deste formato de apresentação é detalhar,
mensalmente, os custos com os itens que compõem o orçamento do projeto. Os
custos poderão variar conforme a quantidade de dias úteis trabalhados pela equipe,
no exemplo apresentado, ou por conta de horas extras trabalhadas pelos membros da
equipe.

A visualização, utilizando tabelas, poderá seguir o exemplo apresentado no

Quadro 5 a seguir:

Quadro 5 – Exemplo de distribuição de custos mensais utilizando tabela

Item Janeiro Fevereiro Março Abril Maio Junho Custo Total

Equipe de R$ R$ R$ R$ R$ R$ R$
desenvolvimento 12.140,00 10.200,00 15.000,00 31.500,00 30.000,00 25.000,00 123.840,00

Fonte: adaptado de James (2006)

O Quadro 5 apresenta a distribuição mensal dos custos com a equipe de

desenvolvimento de um projeto de desenvolvimento de software. Devemos perceber que
o custo total deverá ser o mesmo que foi calculado com base nos recursos necessários
para o projeto. A variação mensal se dá devido aos feriados, quantidade de dias úteis
do mês que foram trabalhados pela equipe ou execução de horas extras, por exemplo.

Segundo Maximiano e Veroneze (2022), o orçamento do projeto, quando

distribuído em valores acumulados mensalmente (ou por outro período desejado, como
anualmente ou semanalmente), irá formar a curva S ou valor planejado para gastos com
cada recurso necessário no projeto.

ATENÇÃO
O custo estimado do projeto não irá representar o valor que será cobrado ao
cliente (ou partes interessadas) para a execução do projeto. Esse custo estará
embutido no valor cobrado, mas outras variáveis poderão ser analisadas e
incorporadas no valor acordado com o cliente para pagamento.

Sommerville (2011) afirma que a gestão da qualidade de um projeto é responsável

por garantir que o que foi solicitado inicialmente pelo cliente e refletido nos requisitos do
projeto é o que estará, de fato, sendo entregue ao final dele.

113
 Acadêmico, no Subtema 5 será apresentado com maiores detalhes como a
gestão da qualidade deverá ser feita, além de apresentarmos sua importância para o
sucesso do projeto.

5 GESTÃO DA QUALIDADE
Segundo Sommerville (2011), a gestão da qualidade é fundamental no método
preditivo, pois permite identificar e corrigir problemas antes que eles causem impactos
negativos nos resultados. Segundo Evans e Lindsay (2015), a implementação de uma
abordagem de gestão da qualidade baseada em dados pode aumentar significativamente
a eficiência e a efetividade do processo.

Já para Juran e Gryna (1993), a gestão da qualidade é uma parte integrante

do método preditivo, pois permite que a organização antecipe problemas e tome
medidas para preveni-los, garantindo, assim, a satisfação dos clientes e a eficiência
dos processos. A gestão da qualidade no método preditivo pode ser medida através de
indicadores como o número de ocorrências previstas versus ocorrências reais, tempo
médio entre falhas, índice de satisfação dos clientes e taxa de conformidade com os
padrões de qualidade estabelecidos.

Segundo Juran (1988) e Deming (1986), essas medidas destacam a importância

de monitorar continuamente o desempenho da qualidade para alcançar melhorias
contínuas. Quando se trata do produto, a qualidade poderá ser medida com base nos
requisitos especificados para sua construção: ao se analisar os requisitos especificados
e os devidamente construídos, quanto maior for o nível de satisfação do cliente com o
que era esperado em termos de comportamento do produto, maior será a qualidade do
que foi construído e entregue. Quando se trata de projeto, quanto mais próximo do que
foi planejado, uma etapa se concretizar, maior será a qualidade do planejamento desse
projeto.

Conforme Larson e Gray (2016), o desempenho de um projeto irá levar em

consideração fatores como tempo planejado versus tempo executado, quantidade
de recursos planejada versus quantidade de recursos efetivamente utilizada, escopo
planejado versus escopo executado, dentre outros pontos de gestão.

A gestão da qualidade está relacionada a três pilares principais, conforme

apresentados na Figura 7:

114
 Figura 7 – Pilares essenciais da gestão de qualidade

Fonte: adaptada de PMI (2017)

A partir da Figura 7, é possível compreender os pilares essenciais para a

gestão da qualidade de um projeto ou produto. O planejamento será essencial para
que se faça o que deve ser feito, de maneira eficaz e eficiente. O controle representa
o acompanhamento necessário para que o planejamento aconteça da melhor forma
possível, sem desperdícios e seguindo as variáveis planejadas (orçamento, custos,
cronograma etc.). A auditoria irá, por sua vez, fazer um levantamento do que foi planejado
e do que foi efetivamente executado, garantindo que os objetivos inicialmente previstos
foram alcançados e que as expectativas das partes interessadas foram devidamente
atendidas.

Segundo apresentado por PMI (2009), os pilares essenciais da gestão da

qualidade do projeto preditivo incluem:

• Planejamento da Qualidade – definição dos objetivos, políticas e estratégias de

qualidade para o projeto. Será essencial para que se faça o que deve ser feito de
maneira eficaz e eficiente.
• Garantia da Qualidade – implementação de processos e atividades de garantia
da qualidade ao longo do ciclo de vida do projeto. Faz-se um levantamento do que
foi planejado e do que foi efetivamente executado, garantindo que os objetivos,
inicialmente previstos, foram alcançados e que as expectativas das partes
interessadas foram devidamente atendidas.
• Controle da Qualidade – monitoramento e medição dos resultados do projeto
para avaliar se eles estão de acordo com os objetivos de qualidade estabelecidos.
Além disso, o controle representa o acompanhamento necessário para que o
planejamento aconteça da melhor forma possível, sem desperdícios e seguindo as
variáveis planejadas (orçamento, custos, cronograma etc.);
• Melhoria da Qualidade – identificação de oportunidades de melhoria contínua
para aumentar a eficiência e eficácia dos processos de qualidade do projeto.

115
 PMI (2009) afirma que esses pilares são amplamente aceitos e discutidos na
literatura da área de gerenciamento de projetos, como por exemplo, no guia PMBOK
(Project Management Body of Knowledge) da PMI (Project Management Institute).

Larson e Gray (2016) frisam que a qualidade do projeto deverá ser analisada
com base em indicadores que irão mensurar se as especificações ditadas pelo cliente
estarão no caminho de serem cumpridas ou não. Itens como o desempenho desejado
do produto, facilidade de uso e de manutenção são exemplos desses critérios, tidos
como critérios de sucesso do projeto.

A medida da qualidade em um projeto utilizando o método preditivo pode ser

realizada através de diversas formas, como o uso de indicadores-chave de desempenho
(KPIs, na sigla em inglês), avaliação de satisfação do cliente, análise de falhas e inspeções
de qualidade. De acordo com PMBOK, essas são algumas das ferramentas mais comuns
para avaliar a qualidade em projetos (PMI, 2017).

INTERESSANTE
Podem compor os critérios de sucesso de um projeto a contratação de
fornecedores de matérias primas que estejam dentro dos parâmetros de
qualidade esperados pela Empresa, a capacidade de atender a um pedido
dentro do prazo esperado, o material fornecido estar dentro de parâmetros
específicos para sustentabilidade, dentre outros fatores.

Apesar de esperar que um projeto atenda a determinados critérios de qualidade,

na prática nem sempre é o que acontece. Não se sabe se o produto que está sendo
construído está dentro dos padrões especificados no planejamento até que seja
analisada sua qualidade real.

Segundo Imoniana (2016) e Pressman (2016), a análise poderá ser executada

através de processos de auditoria, com o intuito de averiguar o que está sendo
consumido como recurso. Por exemplo, estar dentro do esperado para o período no qual
o projeto se encontra, se o cronograma está de acordo com a atual fase do projeto e se
os requisitos inicialmente especificados estão implementados com o comportamento
esperado.

Quando todos os requisitos se encontram construídos com o comportamento

adequado ao que era esperado, usamos o termo “em conformidade” ao nos referimos ao
produto. Segundo Imoniana (2016), caso algum tipo de não conformidade seja detectado,
ao longo do processo de análise, entendemos que há uma não conformidade ou desvio
de comportamento do que era esperado para o item (ou requisito) analisado.

116
 Imoniana (2016) ainda afirma que todo processo que tenha como finalidade
a averiguação entre o que foi planejado e o que está sendo executado no projeto
ou produto é tido como uma forma de verificação da qualidade do que está sendo
desenvolvido. Segundo Maximiano e Veroneze (2022), o controle da qualidade de um
projeto ou produto deve se basear em itens, como os padrões de qualidade desejados
para o produto, serviço ou processos desenvolvidos, os procedimentos detalhados
para executar um determinado processo (como implantação da aplicação em ambiente
de produção), de modo a manter a previsibilidade do processo e evitar surpresas
não planejadas, a contratação de pessoas com o perfil técnico necessário para o
desenvolvimento do projeto, a conscientização da equipe que a qualidade depende do
trabalho de todos e a realização de testes de maneira suficiente.

Quando nos referimos ao processo de realização de testes de maneira suficiente,

estamos querendo dizer da necessidade de englobar os mais variados cenários de testes
possíveis, com uma diversificação da massa de dados de entrada (no caso de sistemas
ou produtos de TI), das possibilidades de combinação de entrada e análise das respostas
obtidas (que devem ser compatíveis com as esperadas, conforme o planejamento dos
requisitos).

Conforme exposto por Pressman (2016), é desejável que mais de um profissional

esteja envolvido na realização de testes, além do desenvolvedor que construiu o
requisito.

ESTUDOS FUTUROS
Acadêmico, abordaremos os tipos de testes existentes e como estes podem
ser executados no processo de Gerenciamento de Projetos e Configuração
na Unidade 3 desta disciplina.

Segundo Sommerville (2011), é importante que um documento de Plano de

Gestão da Qualidade seja elaborado contendo as informações sobre os indicadores de
performance esperados para o projeto e o nível de importância desses critérios.

Para indicar o nível de importância, é possível utilizar escalas, como as numéricas,

ou baseadas na escala “Alta, média ou baixa” ou ainda em “importante, desejável ou
obrigatório”. Além disso, é importante que sejam indicadas formas de garantia da
qualidade para cada item especificado.

O Quadro 6 apresenta um exemplo de como este plano poderá ser elaborado:

117
 Quadro 6 – Exemplo de Plano de Gestão da Qualidade

Indicador a ser analisado Nível de importância Método de avaliação

Avaliação manual dos
Utilização de padrões de
códigos disponibilizados
projeto para implementação Alto.
pela equipe no repositório
da aplicação.
de códigos.
Execução de testes
Testes dos principais fluxos automatizados para os
Alto
da aplicação. principais requisitos do
sistema.
Acompanhar os marcos
parciais de entrega para
Cumprimento das entregas
Médio. garantir que a entrega final
parciais do projeto.
será realizada dentro do
prazo.
Fonte: adaptado de Sommerville (2011)

A partir do Quadro 6, percebemos que os itens que serão avaliados, descritos

na primeira coluna como indicadores a serem analisados, deverão ter seu nível de
importância para o projeto estimados (segunda coluna) e uma forma de garantir que
serão cumpridos ou controlados (terceira coluna).

A avaliação de cada item descrito irá indicar se o projeto está dentro do

estimado para sua execução ou se está apresentando algum tipo de desvio, que deverá
ser corrigido para que o planejamento retome seu andamento esperado.

Hackman (2002) afirma que a equipe é uma peça fundamental para o sucesso
de um projeto de método preditivo. Como afirma, em seu livro Leading Teams: Setting
the Stage for Great Performances, sem uma equipe coesa e eficaz, o projeto corre o
risco de fracassar, independentemente da qualidade do planejamento e da tecnologia
utilizada.

Dessa forma, realizar uma efetiva gestão de equipe se torna essencial.

Acadêmico, o Subtema 6 trará maiores detalhes sobre o processo de gestão da equipe
e seu impacto para todo o projeto.

6 GESTÃO DA EQUIPE
É importante que os membros da equipe tenham a consciência que estão, de
fato, trabalhando em equipe. Pode parecer algo óbvio, mas nem sempre é. A consciência
que o sucesso de um é o sucesso de todos e o fracasso de um será igualmente atribuído
a todos é fundamental para que os membros dediquem seus esforços para atingir o
objetivo.

118
 Quando se remete ao trabalho da equipe, eventuais impedimentos técnicos
precisarão ser compartilhados entre todos os membros, sendo a colaboração entre os
membros uma questão fundamental para o trabalho atingir o êxito esperado.

Sommerville (2011) atenta para o fato de que a motivação é outro ponto de atenção
fundamental, quando se está trabalhando em equipe, já que membros motivados irão
desempenhar suas funções da melhor forma, em prol do objetivo necessário, enquanto
membros desmotivados ou insatisfeitos não terão o mesmo empenho.

De acordo com Max Wideman (2021) em "A Guide to the Project Management
Body of Knowledge" (The PMBOK® Guide) a formação de equipes eficazes é uma das
práticas-chave da gestão de projetos bem-sucedidos. Portanto, é importante investir
na formação de uma equipe competente e motivada para alcançar os objetivos do
projeto de método preditivo.

A capacitação é a chave para o sucesso de qualquer equipe de projeto. É

importante manter ciclos de treinamento constantes para garantir que os membros
tenham as habilidades técnicas necessárias para realizar suas tarefas com eficiência,
bem como as habilidades interpessoais para trabalhar em conjunto de maneira
colaborativa e efetiva, como relata Kerzner (2013a).

ATENÇÃO
O sucesso de uma equipe poderá ser mensurado pela qualidade do
trabalho desempenhado por seus membros (objetivo do projeto) e pela
sinergia entre seus membros. É preciso que os membros da equipe tenham
confiança mútua, boa comunicação, que os conflitos sejam resolvidos e não
ocorram disputas de poder.

INTERESSANTE
Antes da ocorrência da pandemia do Covid–19, poucas eram as equipes
que não estavam localizadas no mesmo espaço físico, já que se acreditava
que a proximidade física entre os membros era um fator de sucesso para
o projeto.

Com a pandemia e o isolamento social consequente, a proximidade física

não se manteve como um item essencial de sucesso para o andamento de projetos,
podendo os membros estarem localizados em qualquer lugar que pudesse fornecer

119
 a infraestrutura básica para desempenhar suas funções (computador ou notebook e
conexão com a Internet).

Segundo Larson e Gray (2016), uma equipe, quando alocada para trabalhar em
um projeto, terá a característica de ser temporária, ou seja, enquanto durar o projeto.
Então, muitas vezes, a escolha de membros que já trabalharam juntos em outros projetos
poderá facilitar o trabalho da nova equipe montada, já que há uma curva de adaptação
entre a forma de trabalho dos diferentes membros.

Mesmo que os membros da equipe sejam colaboradores permanentes de uma

Empresa, ou seja, não apenas contratados para execução de um projeto específico,
montar uma equipe será uma das primeiras tarefas que o gestor de projetos irá executar
em um novo projeto.

A premissa para a escolha dos membros da nova equipe que será montada
deverá ser a capacitação e experiência técnica de cada futuro membro, além de
experiências prévias de trabalho com outros membros que serão pleiteados para
trabalharem em conjunto.

INTERESSANTE
Por tempos se acreditou que adicionar novos membros em uma equipe que
está com risco de atraso na entrega do produto e finalização do projeto era
uma forma de conseguir entregar o projeto dentro do prazo inicialmente
estimado. Esta premissa, por sua vez, não se mostra verdadeira, já que
pessoas que nunca trabalharam juntas, por mais conhecimento técnico
que tenham, podem não conseguir o mesmo desempenho apresentado
em outros projetos.

O ideal é sempre dar preferência para colaboradores que já tiveram experiência

de trabalho em conjunto em projetos anteriores. Segundo Heerkens (2010), a composição
de uma equipe é feita através de dois tipos de participantes:

Participantes diretos – membros diretamente envolvidos nas atividades e tarefas do

projeto, que construirão o objetivo do projeto.
Participantes eventuais ou acessórios – são aqueles que afetam ou são afetados
pelo projeto, mas não estão diretamente envolvidos nas atividades. Pessoas de
empresas fornecedoras de serviços ou suprimentos, que estarão eventualmente se
envolvendo no projeto, em demandas pontuais.

A composição de uma equipe de projeto é fundamental para o seu sucesso.

É importante considerar tanto os participantes diretos, que são aqueles que estão
diretamente envolvidos nas atividades e tarefas do projeto, quanto os participantes

120
indiretos, aqueles que afetam ou são afetados pelo projeto, mas não estão diretamente
envolvidos nas atividades.

Também podemos considerar os interessados no projeto (stakeholders) ou seus

representantes como membros da equipe. Isso indica que o time envolvido no projeto
não se limita apenas aos colaboradores que irão construir o produto, mas também
deverá envolver o cliente (patrocinador) e, caso exista mais de um patrocinador, serão
incluídos os representantes de cada um deles.

Caso o projeto que será iniciado seja visto como algo estratégico para a
Organização, esta poderá dedicar mais recursos e esforços para a concretização do
projeto, com a formação de equipes maiores e dedicadas. Se o projeto for de menor
porte, mas não menos importante e sem intenções futuras de manutenção de contrato
com o cliente interessado, a equipe poderá ser menor e formada por colaboradores já
presentes no quadro de funcionários da Empresa.

De acordo com o estudo de Hill e Jones (2001), podem existir três tipos de
configuração importância/tamanho do projeto versus Empresa:

• Empresa dominante x grandes projetos estratégicos – neste cenário, existirão

grandes equipes dedicadas a cada um dos projetos estratégicos para o portfólio da
Empresa.
• Projeto dominante x diversas Empresas – este cenário exige que membros
das diferentes Empresas trabalhem em conjunto para a realização do projeto.
Muitas vezes, os membros são multidisciplinares, voltados para projetos como da
construção civil.
• Empresa dominante x diversos pequenos projetos – neste cenário, diferentes
equipes estarão focadas em diferentes pequenos projetos de uma mesma área de
conhecimento, como a indústria de cosméticos, farmacêutica ou de desenvolvimento
de softwares.

Após a pandemia do Covid–19, a organização das equipes em diversas

Empresas migrou do ambiente de escritório presencial para o home office. Neste
cenário, é fundamental que os membros tenham características como disciplina, para
que eventuais dispersões do ambiente não prejudiquem o andamento do trabalho; e
confiança, principalmente dos gestores, quanto à manutenção da qualidade do trabalho
que será desenvolvido e ao cumprimento dos prazos acordados para as entregas.

121
 ATENÇÃO
Segundo Kerzner (2017), para montar uma equipe, o gerente de projetos
deverá analisar qual o perfil necessário de membros para sua composição, que
pode compreender:

• conhecimento técnico;
• contexto organizacional;
• soft–skills para trabalhar em equipe (boa comunicação, saber cumprir prazos,
comprometimento com as tarefas realizadas, dentre outras características
pessoais).

É importante que cada membro da equipe conheça suas responsabilidades,

assim que ingressarem na equipe, tendo em vista que cada um deverá cumprir com
seu respectivo papel conforme a matriz de responsabilidades, também conhecida como
matriz RACI.

Segundo PMI (2017), a Matriz RACI é uma ferramenta gerencial efetiva para
estabelecer as responsabilidades e as linhas de autoridade claras em projetos ou
processos empresariais. Ela é amplamente utilizada como uma abordagem simplificada
para garantir que todos os envolvidos estejam claramente conscientes de seus papéis
e responsabilidades.

Esta matriz tem por objetivo apresentar os papéis dos integrantes da equipe
e as tarefas que competem a cada papel. É importante que, na elaboração de uma
matriz de responsabilidades, sejam informados todos os papéis que irão compor a
equipe do projeto, direta ou indiretamente, seguindo do nome de cada colaborador que
irá desempenhar cada papel e, por último, as tarefas que devem ser elaboradas em cada
fase do projeto, com a responsabilidade de cada indivíduo.

Conforme apresentado por PMI (2017), como definição de responsabilidades,

podemos considerar que um membro poderá ter quatro tipos de atribuições:

• Responsável (R) – indicando que o membro terá a responsabilidade direta de

executar a tarefa ou através da supervisão de sua execução.
• Autoridade (A) – Indica que o membro poderá decidir sobre a aprovação ou rejeição
de uma tarefa.
• Consulta (C) – Indicando que o membro deve ser consultado antes que a tarefa
seja executada.
• Informado (I) – Indicando que o membro deverá ser informado sobre a execução
da tarefa ou sua conclusão.

O Quadro 7 apresenta um exemplo de construção de matriz de responsabilidades.

122
 Quadro 7 – Exemplo de matriz de responsabilidades

Levantamento de requisitos
Papel Colaborador
funcionais e não funcionais
Programador André I
Cliente Camila C
Analista de requisitos Flávia R
Fonte: adaptado de PMI (2017)

Acadêmico, neste tema de aprendizagem apresentamos os principais itens em

um projeto que necessitam de gestão, como o escopo do projeto, orçamento e custos,
cronograma, equipe e gestão da qualidade.

A partir do processo de gerenciamento dessas variáveis essenciais para o

início do projeto, será possível passar da fase de elaboração do planejamento para a de
execução (ou desenvolvimento do projeto).

Vimos as principais ferramentas para cada variável do projeto, como o diagrama

EAP, o caminho crítico (para cálculo do cronograma), a definição de responsabilidades
para a gestão de equipes e a elaboração do plano de gestão da qualidade.

123
 RESUMO DO TÓPICO 1
Neste tópico, você aprendeu:

• A gerência de projetos engloba diferentes etapas do projeto, como a entrega, as

atividades e cronograma, custos e orçamento, a qualidade e a equipe. Todas as
atividades de planejamento de um projeto terão a ferramenta de WBS ou diagrama
EAP como base inicial para cálculo das variáveis do projeto.

• Os objetivos e metas para a Gestão da Entrega, compreendendo o processo de

planejamento e logística da distribuição. A importância da garantia da qualidade e
integridade dos produtos entregues, bem como do monitoramento da conformidade
com prazos e orçamentos e a necessidade da comunicação efetiva com os clientes
e stakeholders.

• A Gestão do Escopo precisa ser clara e condizente com os objetivos e requisitos do

projeto. É necessário realizar o controle e monitoramento do escopo para garantir
a sua realização, assim como é importante manter uma comunicação clara e eficaz
com todos os interessados no projeto.

• A Gestão das Atividades deve iniciar com a identificação e definição das tarefas do
projeto, seguindo da atribuição das responsabilidades para os membros do time,
assim como dos prazos necessários para execução de cada tarefa.

• É importante realizar o monitoramento e a avaliação do progresso das tarefas de

forma constante, e, quando for preciso, fazer um gerenciamento de conflitos e
problemas na execução das atividades.

• Para garantir a sua realização, um plano de cronograma deve ser elaborado com
prazos e marcos, que deverão ser seguidos ao longo da execução do projeto.
Aprendemos técnicas que auxiliam na identificação de eventuais atrasos e
problemas no cronograma, sendo fundamental manter uma comunicação clara e
efetiva com todos os interessados no projeto.

• A importância de realizar uma gestão de custos e qualidade de forma efetiva,

realizando um planejamento detalhado dessas atividades e seu devido
acompanhamento. Também a importância de montar equipes com os perfis
adequados às necessidades do projeto, atribuindo responsabilidades de forma clara
aos membros do time.

124
 AUTOATIVIDADE
1 Uma das principais características de um projeto são os seus entregáveis. São estes
artefatos que deverão ser mantidos ao longo de todas as fases do projeto. Sobre os
entregáveis de um projeto, assinale a alternativa CORRETA:

a) ( ) Representam os itens que serão entregues ao final do projeto, não se limitando

apenas ao produto em si, mas a documentos, manuais e tudo que for necessário
ser entregue.
b) ( ) O entregável de um projeto se limita apenas ao produto que será construído.
c) ( ) Apenas os documentos do projeto são considerados entregáveis.
d) ( ) Artefatos e entregáveis de um projeto são conceitos diferentes.

2 A definição do escopo de um projeto irá definir até que ponto o projeto deverá
ser executado, representando suas fronteiras. No gerenciamento de projetos, o
planejamento do escopo de um projeto deverá englobar todas as ações necessárias
desde a etapa inicial do projeto até sua conclusão. Com base em seus conhecimentos
sobre o escopo do projeto e escopo do produto, analise as afirmativas a seguir:

I- O escopo do produto engloba todos os requisitos funcionais e não funcionais que

deverão ser implementados na aplicação.
II- O escopo do produto irá englobar o escopo do projeto.
III- O escopo do projeto engloba o escopo do produto, além de outros entregáveis
necessários para a conclusão do projeto.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) Somente a sentença III está correta.

3 O cronograma do projeto, assim como a identificação das atividades que deverão ser
executadas ao longo das etapas do projeto, são atividades que podem ser auxiliadas
por ferramentas visuais, como o diagrama EAP. Sobre a fase de gerenciamento do
cronograma e atividades de um projeto, classifique V para as sentenças verdadeiras
e F para as falsas:

( ) O cronograma de um projeto deverá ter sua elaboração finalizada apenas durante a

execução do projeto.
( ) O orçamento do projeto será impactado diretamente pela definição de seu
cronograma.

125
 ( ) As atividades do projeto poderão ter sua identificação auxiliada pelo diagrama EAP,
assim como o cronograma, já que dependerá da sequenciação correta dessas
atividades.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – V.
d) ( ) F – F – V.

4 O tempo de execução de um projeto irá depender da duração de todas as suas

atividades. Dessa forma, atividades mais longas irão aumentar o tempo final de
execução de um projeto, independentemente de quantas tarefas devam serem
executadas. Levando em consideração o método do caminho crítico para cálculo do
tempo de execução de um projeto, disserte sobre a diferença entre o cálculo do prazo
de conclusão utilizando o caminho de ida e o cálculo do prazo utilizando o caminho
de volta.

5 O gerenciamento dos custos de um projeto é algo crucial para o sucesso deste, tendo
em vista que uma extrapolação desse planejamento poderá acarretar a interrupção
abrupta do projeto. Existem diferentes variáveis capazes de influenciar o planejamento
dos custos de um projeto, sendo a mão de obra qualificada um deles. Com base no
apresentado, sobre as variáveis que podem impactar no cálculo e gerenciamento dos
custos de um projeto, disserte sobre a importância da variável recursos humanos no
planejamento e controle dos custos de um projeto.

126
UNIDADE 2 TÓPICO 2 -
GESTÃO ÁGIL DE PROJETOS

1 INTRODUÇÃO
Segundo PMI (2018), a gestão ágil de projetos é um enfoque iterativo e
incremental para a gestão de projetos que valoriza a flexibilidade, a colaboração e a
entrega frequente de valor. As metodologias tradicionais para desenvolvimento de
projetos tinham o ônus de necessitarem de todos os recursos, escopo e funcionalidades
bem definidas antes do início do projeto, o que tornava o projeto “engessado”, sem a
possibilidade de alterações ao longo do processo de execução, já que uma alteração
poderia inviabilizar todo o planejamento e, consequentemente, inviabilizar o projeto.

Segundo Sutherland (2016), como uma alternativa aos métodos preditivos de

gestão de projetos, os métodos ágeis surgiram para permitir que houvesse uma maior
interação entre o produto que será construído e o cliente (ou as partes interessadas),
através de feedbacks constantes que irão garantir uma maior satisfação do cliente ao
final do processo.

Acadêmico, no Tema de Aprendizagem 2 abordaremos os conceitos da gestão

ágil de projetos, sua importância e os motivos que levam as equipes a adotarem esta
metodologia de gestão. Apresentaremos os Princípios da Gestão Ágil no subtema 2,
seguindo das Metodologias Ágeis no subtema 3, e Gestão das Atividades Ágeis no
subtema 4.

2 PRINCÍPIOS DA GESTÃO ÁGIL

Beck et al. (2001) afirmam que os princípios da gestão ágil incluem priorizar
indivíduos e interações, entregar software funcionante, colaborar com os clientes e
ajustar a mudanças de necessidades.

Segundo PMI (2018), as vantagens da gestão ágil incluem aumento da satisfação

do cliente, aumento da colaboração e comunicação da equipe, melhoria da qualidade do
software e ajuste flexível a mudanças de necessidades. O gerente de projeto ágil tem
o papel de facilitador, em vez de controlador, e trabalha em estreita colaboração com a
equipe de projeto para alcançar os objetivos do projeto.

Alguns dos desafios da gestão ágil incluem a mudança de mentalidade dos

membros da equipe e do cliente, integração com processos de negócios existentes e
garantia de conformidade com regulamentos e leis.

127
 No próximo subtema, apresentaremos o Manifesto Ágil, a partir do qual todas as
metodologias ágeis foram originadas.

2.1 O MANIFESTO ÁGIL

Em meados do ano 2001, conforme explicado por Beck et al. (2001), a partir de
uma confraternização entre amigos desenvolvedores de software, a ideia de tornar o
processo de construção de aplicações menos burocrático, menos voltado ao processo
de documentação exaustiva e complexa, foi discutida. A partir daí, quatro princípios
foram listados como base para um documento que iria ditar as regras das metodologias
de desenvolvimento que estivessem focadas no produto, ao invés do processo (como
acontecia com as metodologias preditivas de desenvolvimento).

Segundo Beck et al. (2001, s. p.), o Manifesto Ágil surgiu, com base nestes quatro
princípios listados:

Indivíduos e interações são mais importantes que processos e

ferramentas.
Software em funcionamento é mais importante que documentação
abrangente.
Colaboração com o cliente é mais importante que negociação de
contratos.
Responder a mudanças é mais importante que seguir um plano.

Segundo Melo, Oliveira e Ribeiro et al. (2021) e Caroli (2020), a partir do

surgimento do manifesto, diversas metodologias ágeis foram desenvolvidas, tais quais
a Test Driven Development (TDD), Lean e o framework SCRUM, que é o mais difundido
entre as Empresas que adotaram agilidade em seus processos produtivos.

Segundo Melo, Oliveira e Ribeiro et al. (2021) e Maximiano e Veroneze (2022),

uma das características importantes em projetos que adotam metodologias ágeis é a
mudança cultural existente na dinâmica das equipes. Apresentaremos as principais
metodologias ágeis no subtema 3.

3 METODOLOGIAS ÁGEIS
PMI (2018) afirma que as metodologias ágeis mais populares incluem Scrum,
Kanban, XP (Extreme Programming) e Lean. Cada uma delas se concentra em diferentes
aspectos da gestão de projetos, como planejamento, controle de qualidade e gestão de
equipe. No subtema 3.1 apresentaremos a metodologia SCRUM.

128
3.1 Scrum
“Scrum é um framework ágil para gestão de projetos complexos que ajuda
equipes a entregar valor de forma eficiente e adaptativa." (SCRUM GUIDE, 2021, s. p.).
É um framework para gerenciamento de projetos de software desenvolvido por Ken
Schwaber e Jeff Sutherland.

O método Scrum foi concebido com a intenção de gerenciar o desenvolvimento

de projetos complexos extensíveis a outros domínios além da TI (CRUZ, 2013; SCHWABER;
SUTHERLAND, 2017).

Segundo Schwaber e Sutherland (2017), o Scrum não se trata de um processo

ou técnica, mas sim de um framework versátil e adaptável para que pessoas possam
tratar e resolver problemas, enquanto produtiva e criativamente entregam produtos
com o mais alto valor possível.

Além disso, o framework Scrum, diferentemente dos modelos preditivos, possui

a capacidade de corrigir o curso do projeto, “na medida em que todas as pessoas
envolvidas adquirem um melhor entendimento sobre o que precisa ser entregue como
parte do projeto e incorporando esse conhecimento de maneira iterativa” (SCRUMSTUDY,
2017, p. 39).

Segundo Schwaber e Sutherland (2017), dá-se a sustentação do Scrum por três

pilares fundamentais, quais sejam:

• a transparência do processo em relação aos responsáveis pelos resultados;

• inspeção frequente o suficiente para detectar variações sem atrapalhar a execução
das tarefas;
• adaptação que está relacionada com a capacidade de flexibilização das mudanças
necessárias em um projeto de forma a entregar o máximo valor para o cliente.

Conforme apresentado por Scrum Guide (2021), Scrum é uma metodologia

ágil de gerenciamento de projetos que foi desenvolvida para ajudar equipes a entregar
produtos complexos de forma eficiente. Aqui estão alguns dos tópicos principais sobre
Scrum:

• Valores Scrum – os valores Scrum são compromisso, coragem, foco, abertura e

respeito.
• Papéis Scrum – os papéis Scrum incluem Product Owner, Scrum Master e Equipe
Scrum.
• Cerimônias Scrum – as cerimônias Scrum incluem Planejamento da Sprint,
Revisão da Sprint, Retrospectiva da Sprint e Daily Scrum.
• Product Backlog – o Product Backlog é uma lista de itens não ordenados que
representam o trabalho a ser feito pelo time Scrum.

129
 • Sprint – uma Sprint é um período fixo de tempo durante o qual o time Scrum
trabalha para transformar itens do product backlog em incrementos entregáveis.

ESTUDOS FUTUROS
Abordaremos com maiores detalhes os papéis, as cerimônias e o fluxo de
trabalho de um time ágil, nos próximos subtemas. E o método Kanban com
mais detalhes na Unidade 3 desta disciplina.

3.2 EXTREME PROGRAMMING (XP)

Segundo Teles (2005), o Extreme Programming (XP) é um método ágil de
desenvolvimento de software com foco na entrega rápida e constante de valor ao
cliente, colaboração e feedback contínuo.

Dudziak (2000) afirma que o objetivo principal do XP é criar software de alta

qualidade, com entrega rápida e constante, e com uma equipe altamente motivada e
envolvida. Para isso, o Extreme Programming se baseia em cinco valores fundamentais:
comunicação, coragem, simplicidade, feedback e respeito.

A comunicação constante entre a equipe e o cliente é vista como fundamental

para o sucesso do projeto, assim como a coragem de tomar decisões difíceis e mudar de
direção quando necessário. A simplicidade é incentivada, pois acredita-se que soluções
complicadas são mais propensas a erros e menos fáceis de manter. O feedback contínuo
é visto como crucial para garantir que o projeto esteja no caminho certo e que possa
ser ajustado rapidamente quando necessário. Por fim, o respeito mútuo entre a equipe
e o cliente é visto como fundamental para criar uma atmosfera positiva e colaborativa.

Segundo afirmam Dudziak (2000) e Teles (2005), assim como o SCRUM, o XP

também se concentra em trabalhar em ciclos curtos de desenvolvimento, com entregas
frequentes e pequenas, ao invés de entregar tudo de uma vez no final do projeto. Isso
permite que o cliente experimente e avalie o software com mais frequência, e que a
equipe possa se adaptar rapidamente a mudanças no escopo ou nas necessidades do
cliente.

3.3 LEAN
Segundo Caroli (2020), a metodologia Lean, inicialmente criada a partir do
modelo de fábrica Toyota, é uma abordagem de gerenciamento de processos que se
concentra em maximizar o valor para o cliente e minimizar desperdícios. Apesar de

130
sua origem ter sido na indústria automotiva, tem sido amplamente aplicada em outras
indústrias, incluindo software. A metodologia Lean se baseia em cinco princípios
principais: identificar valor, mapear o fluxo de valor, criar fluxo, estreitar o ciclo e
estabelecer puxadores.

Ballard e Howell (2003) explicam que o primeiro princípio – identificar valor –

enfatiza a relevância de se compreender o que é realmente importante para o cliente
e de se concentrar na entrega desse valor. O segundo princípio – mapear o fluxo de
valor – envolve visualizar como o valor flui através do processo, desde a concepção
até a entrega ao cliente. O terceiro princípio – criar fluxo – incentiva a eliminação de
desperdícios e a criação de um fluxo de trabalho suave e eficiente. O quarto princípio –
estreitar o ciclo – enfatiza a importância de ciclos de feedback rápidos e frequentes para
melhorar a eficiência e a qualidade do trabalho. Por fim, o quinto princípio – estabelecer
puxadores – incentiva a criação de sistemas em que o trabalho flua naturalmente, sem
a necessidade de intervenção constante.

Além dos princípios mencionados, Ballard e Howell (2003) e Caroli (2020)

explicam que o método Lean se baseia em algumas ferramentas ágeis para realizar
seus propósitos, tais quais:

• Kaizen – filosofia de melhoria contínua que incentiva pequenas mudanças

constantes para melhorar a eficiência e a qualidade.
• SMED (Single-Minute Exchange of Dies) – técnica para reduzir o tempo de troca
de ferramentas e aumentar a eficiência da produção.
• Kanban – sistema visual de gerenciamento de trabalho que permite aos
colaboradores ver o status atual do trabalho e o que precisa ser feito a seguir.
• TAKT time – tempo ideal para produzir um item específico, baseado na demanda
do cliente.
• 5S – técnica de organização e limpeza que ajuda a mantê-lo o ambiente de trabalho
limpo, organizado e seguro.

Essas ferramentas e técnicas são usadas para ajudar a equipe a entender e

melhorar seu processo de trabalho e para ajudar a identificar e eliminar desperdícios.
Além disso, a metodologia Lean também se concentra na colaboração e no envolvimento
de todos os membros da equipe e na melhoria contínua do processo.

DICA
Além das metodologias ágeis abordadas, existem outras que podem ser
utilizadas em equipes de desenvolvimento. Para conhecer sobre as demais
metodologias, recomendamos assistir ao vídeo: Entenda o que são os métodos
ágeis em 5 minutos [Decifrando Agile 2]. Acesse em: https://www.youtube.com/
watch?v=ds_FydzsuO8.

131
 Além da adoção de metodologias ágeis, é preciso que o Gerente de Projeto
conheça sobre Gestão das atividades ágeis, que será abordada no próximo subtema.

4 GESTÃO DAS ATIVIDADES ÁGEIS

Segundo Caroli (2020), a gestão de atividades no método ágil é um processo
importante para garantir o sucesso de um projeto. No método ágil, as atividades são
gerenciadas de forma iterativa e incremental, permitindo uma flexibilidade maior e a
capacidade de adaptação a mudanças durante o desenvolvimento do projeto.

DICA
Uma das principais referências sobre o assunto é o livro Agile Estimating and
Planning de Mike Cohn.
Fonte: COHN, M. Agile Estimating and Planning. Rio de Janeiro: Prentice Hall,
2005.

Cohn (2005) descreve como a gestão de atividades no método ágil é uma

combinação de arte e ciência, que requer habilidades técnicas, conhecimento sobre
o projeto e habilidades de comunicação e colaboração. O autor também destaca a
importância de a equipe trabalhar junta para entender as necessidades do projeto e
estabelecer prioridades, além de monitorar continuamente o progresso e fazer ajustes
se necessário.

Em resumo, a gestão de atividades no método ágil é um processo importante

para o sucesso do projeto e requer habilidades técnicas, conhecimento do projeto,
habilidades de comunicação e colaboração, e uma abordagem iterativa e incremental,
conforme veremos nos próximos subtemas.

ESTUDOS FUTUROS
Abordaremos, com detalhes, a dinâmica de uma equipe que adota metodologias
ágeis, ainda nesta unidade. Neste momento, será explicado como uma equipe
poderá definir quais tarefas irão ser comportadas em cada sprint, de acordo
com o grau de complexidade de cada tarefa.

132
2.3.1 Papéis dos membros
Segundo Provinciatto e Caroli (2020), Sutherland (2016), em um time de
desenvolvimento Scrum, existem quatro papéis básicos a serem desempenhados:

• Desenvolvedores – desempenhado pelos membros que irão codificar ou

implementar o produto ao qual se destina o projeto.
• Product Owner (PO) – é o membro do time que irá representar a “voz” do cliente
(ou partes interessadas). Essa pessoa deverá ter um conhecimento sólido do
negócio e suas regras, de modo a explicar ao time de desenvolvimento o que deve
ser feito, quais as regras de negócio que deve respeitar, e tirar quaisquer dúvidas de
entendimento do time acerca do negócio.
• Scrum Master (SM) – membro responsável por resolver todo e qualquer
impedimento que o time de desenvolvimento venha a ter, ao longo do processo
de execução do projeto. Sua função poderá, por exemplo, ser um facilitador de
recursos que dependam de outras áreas, até a auxiliar tecnicamente o time com
eventuais dificuldades. Além disso, terá a responsabilidade de guiar o time para a
correta execução das cerimônias do Scrum, respeitando os timeboxes definidos
para cada atividade.
• Cliente (stakeholders) – é a parte interessada no projeto, sendo seu patrocinador.
Deverá estar sempre colaborando com o time, fazendo parte dele. Através de sua
constante colaboração e feedback, o produto poderá ter os ajustes necessários
para satisfazer suas reais necessidades.

Segundo Sutherland (2016) e Provinciatto e Caroli (2020), o Product Owner (PO)

é responsável por estar em contato direto com o cliente, absorvendo o conhecimento
sobre o negócio para que possa repassar ao time de desenvolvedores, esclarecendo as
possíveis dúvidas que existam ao longo do processo de codificação. Sua participação
na cerimônia de planejamento da sprint, assim como na cerimônia sprint review e sprint
retrospective é fundamental, apesar de não ser obrigatória a participação nas reuniões
diárias.

A reunião diária (dailyscrum) é uma reunião voltada, especificamente, para os

desenvolvedores, sendo fundamental a participação de todos desse time. O Scrum
Master (SM) tem papel importante para a daily, já que é o responsável por resolver os
eventuais impedimentos que possam existir para algum desenvolvedor.

A Figura 8 a seguir apresenta um resumo das cerimônias do SCRUM.

133
 Figura 8 – Resumo do ciclo de desenvolvimento SCRUM

Fonte: adaptada de Sutherland (2016)

ESTUDOS FUTUROS
Aprenderemos, nos próximos subtemas, a importância de se adotar tempos
fixos (timeboxes) para cada cerimônia ágil, com o intuito de focar o máximo
de tempo nas tarefas de construção do produto do que na elaboração de
documentações complexas.

Segundo Caroli (2020), em muitas situações, é comum que o cliente não

tenha ciência sobre todas as funcionalidades que deseja em um projeto que ainda
irá ser iniciado. Dessa forma, a construção de um produto inicial, com o mínimo de
funcionalidade que atenda às expectativas do cliente e possa ser validado por ele, pode
representar o ponto de partida para o desenvolvimento do produto. Abordaremos sobre
este conceito no próximo subtema.

2.3.2 Mínimo Produto Viável (MVP)

Segundo Provinciatto e Caroli (2020), muitas vezes, o cliente não sabe ao
certo quais funcionalidades quer que estejam implementadas no produto ainda nas
fases iniciais do projeto. Então, um conjunto limitado de funcionalidades, que irão
retratar apenas o essencial para atender às mínimas necessidades do cliente, serão
implementadas construindo o que se conhece como Mínimo Produto Viável (MVP).

“[...] o MVP é a versão mais simples de um produto que pode ser disponibilizada
para a validação de um pequeno conjunto de hipóteses sobre o negócio” (PROVINCIATTO,
M.; CAROLI, p., 2020). A partir desta afirmativa, temos o MVP como um produto que

134
poderá ser construído para uso, em ambiente produtivo, pelos usuários finais para sua
validação e, caso a ideia que deu origem ao produto seja validada, mais funcionalidades
poderão ser incorporadas ao produto, ao longo do tempo.

INTERESSANTE
Segundo Provinciatto e Caroli (2020), uma outra aplicação válida para
construção de um MVP é a limitação do orçamento disponível para o projeto.

Nessa situação, constrói-se um produto com as principais funcionalidades,

dentro do orçamento disponível, para que, com o passar do tempo e com a utilização
pelos usuários, possa ser incrementado com novas funcionalidades.

Contudo, para que qualquer projeto possa ser iniciado, mesmo que com um
conjunto básico de funcionalidades, é imprescindível que seja elaborado o product
backlog, ou seja, as funcionalidades necessárias para o produto, conforme explicaremos
no próximo subtema.

2.3.3 O Product Backlog

Segundo Sutherland (2016), em metodologias ágeis, os requisitos do produto
que será desenvolvido não precisam, em um primeiro momento, estarem totalmente
definidos para que a equipe possa iniciar seu trabalho, como explica. É necessário,
apenas, que se conheça a necessidade do cliente e as funcionalidades que irão agregar
valor ao seu negócio ou propósito, realizando um trabalho de refinamento dessas
funcionalidades em momento posterior.

Todas as atividades que deverão ser executadas para o desenvolvimento do

produto, ou seja, todas as suas funcionalidades, irão compor o que conhecemos como
product backlog ou backlog do produto.

Segundo Sabbagh (2013), o product backlog será como um repositório de

funcionalidades que deverão, ao final do projeto, ter sido totalmente consumidas,
ou seja, implementadas, para que o produto seja caracterizado como concluído e o
projeto possa, então, iniciar os trâmites necessários para sua conclusão. O conceito de
se criar um repositório para as funcionalidades do produto surgiu a partir do advento
das metodologias ágeis, mais precisamente do Manifesto Ágil, o qual abordamos no
subtema 2.1.

135
 Provinciatto e Caroli (2020) explicam que o tempo estimado para cada atividade
é acordado antes do início do projeto, não podendo ser modificado enquanto o projeto
estiver em andamento. Então, por exemplo, um ciclo de trabalho deverá ter o prazo
mínimo de uma semana e máximo de quatro semanas de trabalho. Segundo Sabbagh
(2013), uma das principais características de uma equipe ágil é ser autogerenciável.

Abordaremos este assunto no próximo subtema.

2.3.4 Equipes Autogerenciáveis e o Product Backlog

Em metodologias ágeis, as tarefas que irão compor o repositório do produto
irão, ao passo que o projeto caminha, ser detalhadas para que possam ser construídas
pelo time de desenvolvimento. Então, segundo Sutherland (2016) e Sabbagh (2013), o
refinamento das tarefas só irá acontecer quando elas estiverem próximas de serem
implementadas.

Segundo apresentado por Caroli (2020) e Sutherland (2016), cada membro da

equipe, após o processo do refinamento de um conjunto de funcionalidades extraído do
product backlog ter sido finalizado, irá se responsabilizar pelo desenvolvimento de uma
tarefa, de modo que não seja necessário que um membro se responsabilize pela tarefa
de atribuir uma ocupação a cada desenvolvedor. Caberá a cada programador, por sua
vez, informar aos demais membros da equipe qual a tarefa que cada um realizará, para
que todos tenham ciência do que estão trabalhando no momento.

Dizemos que uma equipe é autogerenciável quando, conforme explicado no

parágrafo anterior, cada membro tem a autonomia de analisar as tarefas prontas para
atuação e, seguindo a prioridade informada pelo cliente (ou partes interessadas), se
responsabilizar pela implementação de uma das tarefas, informando ao time qual a
tarefa que estará responsável.

IMPORTANTE
De acordo com Sutherland (2016), não existe, em equipes que adotam as
metodologias ágeis, o papel do líder técnico. Todos os membros irão possuir a
mesma autonomia, colaborando entre si para resolver eventuais impedimentos
técnicos. O papel do líder técnico, ou líder de projetos, será substituído por
outros papéis inerentes à metodologia ágil, que são o Product Owner (PO) e o
Scrum Master (SM).

Segundo Sabbagh (2013), para que os membros de um time ágil possam iniciar
o processo de implementação das tarefas, é preciso que sejam definidas as histórias
de usuário, que abordaremos no próximo subtema.

136
2.3.5 Histórias do Usuário
Scrum Alliance (2022), descreve que na metodologia ágil, as tarefas são
descritas como "histórias do usuário". Estas histórias descrevem o objetivo ou o valor que
o usuário espera obter com a realização da tarefa. Elas são escritas de forma concisa e
clara, utilizando um formato padrão, como apresentado no Quadro 8.

Quadro 8 – Modelo para escrita de Histórias de Usuário

Como [tipo de usuário]

Quero [realizar uma tarefa]
Para [obter um resultado desejado]

Fonte: adaptado de Scrum Alliance (2022)

Conforme apresentado no Quadro 8, para que um requisito possa ser listado, é

importante definir qual a persona (papel do usuário na aplicação), qual a tarefa que se
deseja realizar e qual o objetivo pretendido com a realização da tarefa. Essa abordagem
tem como objetivo manter o foco no valor que será entregue ao usuário final, em vez de
se concentrar apenas nas especificidades técnicas da tarefa. Isso permite que o time
de desenvolvimento tenha uma compreensão clara do que precisa ser feito e por quê,
o que pode ajudar a tornar o processo mais eficiente e envolver o usuário na tomada de
decisões.

Segundo Provinciatto e Caroli (2020), a descrição das tarefas como histórias

do usuário é uma prática comum em metodologias ágeis, como o Scrum e o Extreme
Programming (XP). Ainda segundo Provinciatto e Caroli (2020) e Sutherland (2016), ao
iniciar um novo ciclo (nova sprint), a equipe deverá trabalhar em cima de um conjunto
de tarefas que foram detalhadas para compor o backlog da sprint. A quantidade de
tarefas que a equipe poderá entregar, ao final de cada ciclo, irá depender da capacidade
de trabalho da equipe, que pode ser definida a partir dos ciclos anteriores de trabalho
neste mesmo projeto.

2.3.6 Visibilidade das funcionalidades do produto

Segundo Sutherland (2016) e Melo, Oliveira e Ribeiro et al. (2021), para que o
conjunto das funcionalidades do produto possa estar visível a todos os interessados no
projeto, além do time de desenvolvimento, pode-se utilizar a ferramenta kanban, que irá
representar a situação atual de cada tarefa, como: A fazer, Fazendo ou Feito.

137
 INTERESSANTE
Segundo Anderson (2011), existe o método de gerenciamento de projetos
Kanban (com K maiúsculo) e a ferramenta kanban (com K minúsculo). A diferença
entre os dois é que o método Kanban terá suas regras e particularidades,
além de utilizar a ferramenta kanban como forma visual de apresentação do
andamento do projeto.

Já a ferramenta kanban é um quadro visual, dividido em colunas que irão

representar o estágio de cada tarefa no processo de desenvolvimento, podendo ser
utilizado por qualquer metodologia ágil, como uma ferramenta auxiliar.

Conforme apresentado por Provinciatto e Caroli (2020), a partir do momento

que um desenvolvedor se torna responsável pelo desenvolvimento de uma tarefa, que
deve estar na coluna A Fazer do quadro kanban, este irá atribuir seu nome (ou avatar)
à tarefa, mudando-a para a coluna Fazendo. Após a conclusão de toda a tarefa, com
seus respectivos testes e disponibilização em algum ambiente para validação por outro
membro do time, a tarefa será movida para a coluna Feito e o desenvolvedor estará livre
para escolher uma nova tarefa para atuação.

Figura 9 – Exemplo de quadro kanban para um projeto

Fonte: adaptada de Sutherland (2016)

Segundo Anderson (2011), as raias do quadro kanban podem ser definidas

conforme o processo da Empresa, não se limitando apenas às três apresentadas na
Figura 9. Então, é possível que novos estágios do processo de cada equipe sejam
inseridos, como “Homologação: a fazer”, “Homologação: fazendo”, “Homologação: feito”
e assim por diante.

De acordo com Sutherland (2016) e Sabbagh (2013), o backlog do produto

poderá ser subdividido em etapas (ou ciclos) de implementação, também conhecidos
como sprints. Quando um novo ciclo começar, é necessário que um recorte das tarefas

138
disponíveis no backlog do produto seja extraído para o refinamento e, após a conclusão
de todos os detalhes necessários para que a equipe de desenvolvimento tenha
capacidade de iniciar a codificação das tarefas, esse conjunto refinado irá compor o que
conhecemos como backlog da sprint.

É a partir do conjunto de tarefas já refinadas, que comporão o backlog da sprint,

que a equipe de desenvolvimento buscará as novas tarefas para atuação de cada
membro do time. Nesta fase, as tarefas já deverão ter sido priorizadas para que aquelas
que tenham um maior valor agregado ao negócio do cliente possam ser posicionadas
primeiro na baia A fazer e tenham sua atuação iniciada pelos desenvolvedores.

Segundo Anderson (2011), o posicionamento das tarefas no quadro irá ditar a

ordem na qual as tarefas precisarão ser executadas pela equipe de desenvolvimento.
Tarefas mais prioritárias deverão estar nas primeiras posições da baia, enquanto as
menos prioritárias logo abaixo. Cada membro do time de desenvolvimento deverá, por
sua vez, obedecer a ordem de prioridade já definida para cada tarefa, pegando aquela
mais prioritária para execução.

ATENÇÃO
O intuito do quadro kanban, de acordo com Anderson (2011), é apresentar, em
tempo real, o andamento das tarefas para qualquer interessado que observe o
quadro. Portanto, é importante que os membros mantenham o status de cada
tarefa atualizado, efetuando a migração das tarefas entre as abas no exato
momento que cada fase finaliza.

Segundo Anderson (2011), Sabbagh (2013) e Caroli (2020), em abordagens ágeis,

o backlog do produto poderá ser alterado ao longo da execução do projeto, desde que
acordado com as partes interessadas. Da mesma forma, a priorização das atividades
poderá ser alterada, a qualquer momento, desde que mudem os interesses do cliente.
Esta é a grande diferença entre o método preditivo e as metodologias ágeis: enquanto
o primeiro não poderá sofrer alterações no planejamento, o segundo trata as alterações
como algo normal e bem-vindo.

ESTUDOS FUTUROS
Abordaremos as ferramentas voltadas para gerenciamento de projetos na
Unidade 3 desta disciplina.

139
 Acadêmico, abordaremos, no próximo subtema, a importância de se definir
prazos limites (timeboxes) para a realização das tarefas de um time ágil.

3 A IMPORTÃNCIA DA ADOÇÃO DE TIMEBOXES

Segundo Sabbagh (2013), a metodologia ágil adota o conceito de timebox
para definir o prazo limite de cada atividade. Dessa forma, a equipe deverá cumprir o
prazo estipulado, garantindo que as tarefas poderão ser avaliadas pelo cliente e terão o
feedback em tempo adequado, antes de serem efetivamente incorporadas ao produto
final.

Timebox é um conceito importante dentro do método ágil de gerenciamento de

projetos. O timebox se refere a um período fixo, geralmente uma semana ou um mês,
durante o qual um grupo de trabalho se concentra em concluir uma lista de tarefas
específicas. O objetivo é garantir que o progresso seja feito de forma consistente e que
os prazos sejam mantidos.

Sutherland (2014) descreve no livro Scrum: A Arte de Fazer o Dobro do Trabalho

na Metade do Tempo a utilização do timebox como uma parte fundamental do Scrum,
um dos principais frameworks ágeis para gerenciamento de projetos.

Segundo Sabbagh (2013), para que os membros do time de desenvolvimento

consigam estimar o esforço necessário para a execução de uma tarefa, uma pontuação
poderá ser atribuída a cada história, demonstrando sua complexidade. Abordaremos
essa pontuação no próximo subtema.

3.1 STORY POINTS

Segundo Radigan (2023), Story points é uma técnica utilizada no método ágil
para estimar o esforço necessário para completar uma tarefa ou história de usuário. Em
vez de estimar o tempo necessário para completar uma tarefa, os pontos de história
tentam medir a complexidade relativa de uma tarefa em comparação com outras tarefas.

De acordo com Sutherland (2014), os pontos de história fornecem uma medida

subjetiva da quantidade de trabalho necessário para completar uma tarefa. O livro
destaca que as equipes de desenvolvimento de software podem usar essa técnica
para alcançar uma compreensão comum do esforço necessário para completar uma
tarefa, o que ajuda a estabelecer expectativas realistas sobre o tempo necessário para
a conclusão do trabalho.

Agora que já apresentamos os principais conceitos utilizados por um time ágil,

abordaremos, no próximo subtema, como acontece a dinâmica de uma equipe ágil.

140
3.2 A DINÂMICA DE UMA EQUIPE ÁGIL
Segundo Sutherland (2016) e Provinciatto e Caroli (2020), uma equipe ágil irá
focar seu trabalho nos requisitos que mais agregam valor ao negócio do cliente, fazendo
entregas periódicas a cada finalização de sprint. O objetivo, com essas entregas, é ter
feedback constante das partes interessadas de modo que eventuais desvios no objetivo
do projeto poderão ser detectados e corrigidos a tempo, sem prejuízo ao projeto como
um todo.

Segundo Provinciatto e Caroli (2020), engana-se, porém, quem pensa que

adotar uma metodologia ágil representa rapidez. A adoção de tal metodologia terá o
objetivo de fazer a coisa certa, atendendo aos reais propósitos do cliente, aos seus
anseios, apresentando resultados parciais que serão validados (ou não) pelo cliente.
A agilidade, em si, está na forma de trabalho que será adotada pela equipe: pequenos
objetivos a serem cumpridos em pequenos ciclos de trabalho, que serão submetidos à
análise e ajustados, ou não, pelas partes interessadas.

Conforme explicado por Pereira, Torreão e Marcal (2007) e Sutherland (2016),

as entregas parciais que são realizadas são denominadas incrementos do produto.
Cada incremento entregue, ao final de cada sprint, será incorporado ao produto e
disponibilizado para uso em ambiente produtivo.

Pereira, Torreão e Marcal (2007) explicam que o processo de desenvolvimento em

uma equipe que adota metodologias ágeis começa com a cerimônia do planejamento,
que no SCRUM é denominada sprint planning. Nesta cerimônia, o objetivo será planejar
quais tarefas irão compor o sprint backlog, ou seja, o espaço de trabalho, recortado do
product backlog.

De acordo com Anderson (2011), para realizar a tarefa do planejamento, a equipe

poderá utilizar ferramentas auxiliares, como o planning poker, que utiliza a sequência
de Fibonacci para atribuir notas, que irão representar o nível de complexidade de cada
tarefa, conforme as experiências prévias e o nível de conhecimento de cada membro do
time de desenvolvimento. Cada desenvolvedor poderá atribuir um número diferente para
uma mesma tarefa, seguindo seu nível de compreensão do que deve ser feito e tendo
como parâmetro suas experiências passadas e seu conhecimento sobre o sistema que
está sendo construído. O intuito dessa ferramenta, contudo, é que se chegue a um
consenso sobre o nível de complexidade de cada tarefa, que terá um valor numérico
atribuído a ela.

DICA
Para conhecer como funciona a sequência de Fibonacci, recomendamos
assistir ao vídeo: https://www.youtube.com/watch?v=cHZWZhHQq4g.

141
 Segundo Anderson (2011), quanto maior o valor de cada tarefa, maior será seu
tempo de execução, pois entende-se que sua complexidade será maior. A equipe deve,
então, com base na produtividade de ciclos passados do projeto, decidir quantas tarefas
será possível executar no próximo ciclo, seguindo o número de pontos de história
(story points) que foi possível executar em sprints anteriores. Os pontos de história são
representados pelo número que foi atribuído à cada tarefa, na atividade de planejamento,
conforme explicado no subtema anterior.

IMPORTANTE
É comum que, em projetos recém iniciados nos primeiros ciclos de trabalho,
a equipe erre a estimativa de quantas tarefas será capaz de trabalhar e
entregar. Entretanto, com o passar dos ciclos e com o maior entrosamento
entre os membros do time e conhecimento do sistema que será construído,
as estimativas vão ficando mais certeiras. Errar nas primeiras sprints não é,
contudo, um indicativo que o tempo acordado para duração da sprint deverá
ser maior.

Conforme Schwaber e Sutherland (2020), após o planejamento ter sido finalizado,

a sprint terá seu início oficial, ficando a cargo de cada desenvolvedor se responsabilizar
por uma das tarefas que serão construídas. Um ciclo de trabalho poderá ter entre uma e
quatro semanas, de acordo com a definição inicial de cada equipe. Uma vez adotado um
timebox para a duração da sprint, esta não poderá ser modificada enquanto o projeto
estiver em andamento.

Segundo Provinciatto e Caroli (2020), conforme a metodologia ágil “Scrum” em

cada dia de trabalho de uma sprint, a equipe deverá fazer uma reunião diária, denominada
daily scrum, que terá o objetivo de saber o que cada membro fez no dia anterior, quais
suas expectativas de trabalho para o dia corrente e quais os seus impedimentos para
continuar a tarefa atual. A duração da daily deverá ser de quinze minutos e, para equipes
que trabalham presencialmente no escritório, feita em pé. É importante que seja sempre
executada no mesmo horário e local, todos os dias.

Schwaber e Sutherland (2020) afirmam que, ao final de cada sprint, o resultado

deverá ser apresentado para o cliente (ou seus representantes), de modo que possa ser
validado em termos de expectativas das necessidades do projeto. Essa apresentação
é feita em uma cerimônia, a sprint review, que deverá ter duração variável, conforme
o tempo de duração da sprint, tendo sua duração máxima de quatro horas para um
ciclo de quatro semanas. Para ciclos de durações menores, a review deverá ter duração
igualmente menor e proporcional.

142
 Eventuais ajustes poderão resultar da cerimônia de sprint review, tendo o time
de desenvolvimento a responsabilidade para realizar esses ajustes e disponibilizar
para validação do cliente, em ambiente apropriado para esta homologação.
Segundo Schwaber e Sutherland (2020) e Pereira, Torreão e Marcal (2007), a última
cerimônia de uma sprint, a ocorrer após a sprint review, é a sprint retrospective, ou
seja, a retrospectiva de tudo que aconteceu na sprint. Nesta cerimônia, os membros do
time devem expressar suas observações sobre tudo que deu certo e pontos a serem
melhorados para o próximo ciclo, garantindo, assim, a melhoria contínua do processo
de desenvolvimento do produto. Essa cerimônia deverá ter seu timebox máximo de
três horas para uma sprint com duração de quatro semanas, conforme dita. Ciclos com
durações menores devem realizar essa cerimônia mais breve, de forma proporcional.

143
 RESUMO DO TÓPICO 2
Neste tópico, você aprendeu:

• A Gestão de Projeto Ágil é uma abordagem de gerenciamento de projetos que

valoriza a flexibilidade, a adaptabilidade e a entrega de valor ao cliente.

• O Manifesto Ágil é um conjunto de valores e princípios que definem a filosofia da

gestão ágil de projetos. Inclui valores como indivíduos e interações, colaboração,
resposta a mudanças, entrega contínua e trabalho funcionante

• As metodologias ágeis representam uma abordagem para gerenciamento de

projetos que segue os princípios do manifesto ágil e se concentra na entrega
contínua de valor ao cliente, na colaboração e na resposta a mudanças, e que
adotar uma metodologia ágil não irá significar, necessariamente, rapidez, mas sim
eficiência e eficácia no que está sendo entregue, atendendo às reais expectativas
do cliente.

• O framework Scrum é uma metodologia ágil de gerenciamento de projetos que

se concentra em equipes multifuncionais que trabalham juntas para entregar
incrementos de produto em intervalos regulares, conhecidos como sprints. Além
disso, o framework scrum possui cerimônias que precisam ser seguidas pela equipe
de desenvolvimento durante a execução das atividades, para que o processo ágil
tenha sucesso.

• Existem diversas ferramentas de suporte aos times ágeis, como o método Kanban
e o quadro kanban, as Histórias de usuário e ferramentas de colaboração em tempo
real e rastreamento de bugs encontrados ao longo do ciclo de vida dos projetos.

144
 AUTOATIVIDADE
1 As metodologias ágeis surgiram como uma alternativa ao desenvolvimento utilizando
metodologias tradicionais, também conhecidas como preditivas. Essa mudança de
paradigma beneficiou tanto os stakeholders quanto as equipes de desenvolvimento,
tendo em vista que o usuário terá contato com o produto sendo desenvolvido mais
vezes ao longo do tempo, assim como os membros da equipe de desenvolvimento
gastarão menos esforços construindo o que, de fato, irá satisfazer os interesses do
cliente. Sobre as metodologias ágeis, assinale a alternativa CORRETA:

a) ( ) Sprint backlog irá conter todas as funcionalidades do produto que será

desenvolvido.
b) ( ) O sprint backlog irá ser um recorte do product backlog.
c) ( ) O Product backlog irá ser um recorte do sprint backlog.
d) ( ) Product backlog terá apenas as tarefas que serão implementadas no próximo
ciclo.

2 O manifesto ágil surgiu com o intuito de definir normas para as metodologias ágeis.
Seus princípios devem, então, ser o fundamento de toda e qualquer metodologia ágil
que venha a ser desenvolvida. Apesar do nome, as metodologias ágeis não significam
uma maior velocidade no processo de desenvolvimento, mas sim que o produto certo
será entregue ao cliente, focando nas funcionalidades que mais agreguem valor ao
negócio. Com base no manifesto ágil e seus princípios, analise as sentenças a seguir:

I- Equipes que adotam as metodologias ágeis para desenvolvimento de seus produtos

não devem produzir documentação do que será desenvolvido.
II- Uma equipe ágil deverá se preocupar mais em manter boas relações entre seus
membros e o cliente do que seguir processos burocráticos.
III- As equipes que seguem as metodologias ágeis devem serautogerenciáveis, ou seja,
não esperar que um membro da equipe atribua qual a próxima tarefa deverá ser tratada.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) As sentença II e III estão corretas.

3 O Mínimo Produto Viável deve refletir o menor conjunto de funcionalidades possíveis

de serem utilizadas, em produção, pelos clientes reais de um produto. De acordo com
o Mínimo Produto Viável e as metodologias ágeis, classifique V para as sentenças
verdadeiras e F para as falsas:

145
 ( ) O MVP servirá para a validação de uma e, caso aprovada, evoluções possam ser
feitas de forma periódica.
( ) Quando se tem uma limitação no orçamento para construção de um produto,
sugere-se o desenvolvimento de um MVP.
( ) A construção do MVP é um estágio obrigatório para todas as metodologias ágeis.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – V – F.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 Metodologias ágeis buscam otimizar o processo de desenvolvimento de um projeto

através do foco nas atividades que são, de fato, importantes e irão agregar valor
ao processo produtivo. Da mesma forma, o sucesso do produto irá depender,
diretamente, da participação do cliente, através de seus constantes feedbacks. Com
base no texto exposto e seus conhecimentos, disserte sobre a importância da adoção
de timeboxes para o sucesso na adoção de metodologias ágeis.

5 Diferente de uma equipe que segue as metodologias preditivas para desenvolvimento

de um projeto, equipes ágeis terão papéis e responsabilidades diferentes, assim como
uma dinâmica igualmente diferente para a construção do produto. Nesse contexto,
disserte sobre a cerimônia de sprint review, explicando seu propósito e em qual
momento do ciclo de desenvolvimento deverá acontecer.

146
UNIDADE 2 TÓPICO 3 - A
GERÊNCIA DE CONFIGURAÇÃO COMO
ESTRATÉGIA PARA O GERENCIAMENTO
DE UM PROJETO DE SOFTWARE

1 INTRODUÇÃO
Primeiramente, com base na literatura, precisamos definir o que é Gerência
de Configuração. Segundo Pressman (2016), é considerada uma estratégia vital para
o sucesso de um projeto de software, pois permite controlar e rastrear mudanças em
todo o ciclo de vida do projeto, garantindo a integridade e a consistência dos artefatos
produzidos. Já para Kerzner (2017), permite manter o projeto sob controle, assim como
garante a qualidade dos produtos entregues, o que aumenta a eficiência do time de
projetos.

Ainda, Konrad e Phillips (2018) definem a Gerência de Configuração como uma

abordagem que permite gerenciar, controlar e documentar as mudanças em todos
os aspectos que envolvem o projeto, como configurações de software, hardware,
documentação e demais artefatos produzidos no projeto.

A gestão estratégica é vital para a sobrevivência de qualquer organização,

diante das empresas concorrentes. A má elaboração de estratégias ou as metas mal
traçadas podem indicar graves prejuízos financeiros, além da falência da organização.
Um dos fatores que englobam a gestão estratégica é saber qual projeto deverá ser
implementado e em que ordem, dentro dos projetos existentes no portfólio de uma
Empresa.

Neste tema de aprendizagem, abordaremos a importância e os principais

conceitos da gestão estratégica de projetos e configuração, apresentando a diferença
entre este tipo de gestão e a gestão operacional. Em seguida, discorreremos sobre a
dinâmica da gestão estratégica de projetos, passando, por fim, pela apresentação do
gerenciamento de configurações.

2 DINÂMICA DA GESTÃO ESTRATÉGICA DE PROJETOS

Segundo o PMI (2017), a gestão estratégica de projetos é uma abordagem
sistêmica e integrada para a liderança e a gestão de projetos, que visa a alinhar o objetivo
do projeto às metas estratégicas da empresa.

147
 Ainda, segundo o PMI (2017), a gestão estratégica de projetos envolve a
identificação e a seleção dos projetos mais estratégicos para a organização, bem como
a garantia de que eles sejam gerenciados de modo a alcançar seus objetivos de maneira
eficaz.

Para Wysocki, Beck e Thomas (2014), a gestão estratégica de projetos é um

processo contínuo de tomada de decisão e de realinhamento, que permite aos gestores
de projetos se adaptarem às mudanças no ambiente externo e interno da organização.

Montar um plano estratégico, conforme o ramo de negócio explorado pela

empresa, é o que conhecemos como política de negócios, tendo em vista que poderá
auxiliar a organização a manter-se saudável, em termos de mercado, diante de seus
concorrentes.

Hitt, Ireland e Hoskisson (2016) apresentam alguns objetivos estratégicos que

podem interferir na política de negócios:

• Ambiente regulatório – as leis e as regulamentações governamentais podem

afetar as decisões de negócios, incluindo questões relacionadas à proteção do meio
ambiente, aos direitos trabalhistas, à propriedade intelectual e à concorrência.
• Concorrência – a estratégia da empresa deve considerar as ações e a posição de
seus concorrentes, bem como a dinâmica do mercado em que atua.
• Sustentabilidade – muitas empresas adotam práticas mais sustentáveis, para
melhorar sua imagem e atender às demandas dos consumidores e investidores.
• Responsabilidade social – as empresas também são pressionadas a demonstrar
seu compromisso com questões sociais e de impacto social, diversidade e inclusão,
direitos humanos e boas práticas de governança corporativa.
• Tecnologia e inovação – as empresas precisam estar atentas às novas tecnologias
e às tendências, para se manterem competitivas e relevantes.
• Demanda do mercado – a estratégia de negócios deve considerar as tendências
de mercado e as necessidades e os desejos dos consumidores.
• Objetivos financeiros – a política de negócios deve estar alinhada aos objetivos
financeiros da empresa, incluindo lucro, crescimento e retorno aos acionistas.

Esses são apenas alguns dos muitos fatores que podem influenciar a política
de negócios de uma empresa. É importante que as empresas avaliem cuidadosamente
todos os fatores relevantes, para garantir que sua estratégia de negócios seja bem-
sucedida e sustentável a longo prazo.

Todo o processo de gestão se baseia em pilares e, com a gestão estratégica,

não é diferente, conforme será abordado a seguir.

148
2.1 PILARES DA GESTÃO ESTRATÉGICA
Segundo Johnson, Scholes e Whittington (2017), a gestão estratégica se baseia
em quatro pilares básicos:

• Planejamento estratégico – consiste em definir o objetivo e o escopo da

estratégia, avaliar o ambiente interno e externo, identificar as forças, fraquezas,
oportunidades e ameaças e desenvolver a estratégia.
• Implementação da estratégia – envolve a alocação de recursos, a criação de
planos de ação e a implementação das iniciativas estratégicas.
• Monitoramento e controle – consiste em acompanhar o progresso da estratégia
e medir o seu sucesso, identificando pontos de melhoria e realizando ajustes
conforme necessário.
• Revisão e avaliação – envolve a avaliação dos resultados da estratégia e a revisão
da estratégia em si, levando em conta as lições aprendidas e as mudanças no
ambiente externo.

Figura 10 – Etapas do ciclo de uma gestão estratégica

Fonte: adaptada de Johnson; Scholes; Whittington (2017)

Na fase do planejamento, é fundamental observar o histórico estratégico

(ou a situação estratégica) da empresa, que irá refletir a situação atual da organização,
consequência das decisões tomadas no passado.

Segundo explica Francischini e Francischini (2017), é importante realizar uma

análise sobre os pontos fortes e fracos de um projeto, antes que este se inicie. A
ferramenta que pode ser aplicada para facilitar esse processo é a Matriz SWOT.

149
 2.1.1 Matriz SWOT
Segundo Francischini e Francischini (2017), ainda durante a fase do
planejamento, uma análise das oportunidades de mercado e do ambiente, por meio
da elaboração de uma matriz SWOT, deverá ser levantada. Também se deve fazer uma
análise do objetivo pretendido com a estratégia a ser executada, definindo-se os marcos
a serem alcançados. Após todo esse processo inicial, a fase de execução irá, então, pôr
em prática tudo que foi planejado, seguindo-se da avaliação, para garantir que o que é
executado está dentro do devido planejamento.

DICA
Uma matriz SWOT procura identificar os pontos fortes e fracos de uma
empresa e seus concorrentes, buscando a melhor forma de explorar uma
oportunidade e calcular os eventuais riscos existentes no processo. Para saber
mais sobre esse assunto, é indicada a leitura do livro Planejamento estratégico,
indicadores e processos: uma integração necessária, do autor Cláudio José Müller.

A seguir, abordaremos a definição dos indicadores, também conhecidos como

KPIs, importantes para o acompanhamento de projetos.

2.1.2 Key Performance Indicator (KPI)

Segundo Dakheel et al. (2020), por meio da utilização de indicadores de
performance, é possível identificar eventuais desvios de objetivo, sendo possível realizar
os ajustes necessários para que as metas traçadas possam ser atingidas com êxito.

Ferreira Junior (2020) define os marcos, que irão servir de balizadores, para que
o desempenho da meta a ser alcançada, pela gestão estratégica, possa ser medida,
conhecidos como Key Performance Indicator (KPI). Por meio desses indicadores,
é possível identificar eventuais desvios de objetivo, possibilitando realizar os ajustes
necessários para que as metas traçadas possam ser atingidas com êxito.

Dakheel et al. (2020) afirma que a fase de execução de uma estratégia irá
compreender o processo de implementação da tomada das decisões planejadas,
traçando o caminho até o objetivo pretendido. Ao longo desse caminho, eventuais
marcos (os KPIs) irão indicar se a estratégia planejada guia a organização para o resultado
esperado ou não. A avaliação desses marcos, à medida que são alcançados, traçará
novas estratégias, manter as já em andamento ou realizar os ajustes necessários para
que o objetivo pretendido seja alcançado.

150
 IMPORTANTE
Um KPI, por si só, de acordo com Ferreira Junior (2020) e Francischini e
Francischini (2017), não será capaz de indicar o quão longe uma organização
está de atingir seus objetivos. Ele será apenas um marcador, um número, sendo
necessária a sua análise pela fase de avaliação. É apenas durante a avaliação
dos marcos atingidos e de quão distante se está do resultado esperado para
aquele marco específico, que eventuais medidas corretivas poderão ser
adotadas para que a execução consiga atingir o resultado esperado.

Pressman e Maxim (2021) afirmam que não basta apenas definir marcos e
acompanhar para que um projeto tenha sucesso. É preciso saber escolher o projeto
certo, entre as ideias disponíveis, para compor o portfólio da empresa – assunto que
será abordado a seguir.

2.1.3 Gestão de ideias para novos projetos

Segundo Maximiano e Veroneze (2022), é comum que uma organização possua
um grande leque de ideias para novos projetos, mas isso não implica que todas as
ideias sejam, de fato, implementadas. Escolher a ordem de execução mais adequada
para as ideias que compõe um estacionamento de ideias pode fazer total diferença
para a composição do portfólio da empresa, sendo essencial o uso de técnicas para a
melhor tomada de decisões sobre quais projetos executar e em qual ordem possam ser
aplicadas.

Ideias para novos projetos podem partir tanto da alta cúpula da organização
(diretores, gerentes e demais cargos do alto escalão) quanto da necessidade de clientes,
dos próprios funcionários ou até da dinâmica do mercado, em relação aos concorrentes.

Sommerville (2011) afirma que a avaliação de um novo projeto, que pleiteia ser
implementado, dependerá de critérios que precisam ser bem definidos, para que um
correto alinhamento com o modelo de negócio da empresa. Esses critérios são:

• Viabilidade financeira – tendo seu principal indicador o retorno sobre o

investimento (ROI).
• Viabilidade produtiva – medido pela capacidade de produção da organização (por
exemplo, quantidade de produtos/dia).
• Viabilidade de mercado – público que tenha interesse em consumir o produto ou
o serviço que será produzido e/ou oferecido.
• Viabilidade legal – projeto alinhado com as legislações em vigor.
• Velocidade de construção/implementação – tempo decorrente entre o início do
projeto e a entrega do produto ou do serviço a ser construído.
151
 Com base nos critérios expostos, é possível realizar comparações entre
diferentes projetos, averiguando, por exemplo, qual projeto terá um maior retorno sobre
o investimento feito (qual dará maior lucro), qual projeto terá uma maior fatia de mercado
ou aquele que poderá ser construído de forma mais rápida e que servirá de vitrine para
que a empresa possa ser conhecida (exemplo de um projeto inovador).

Após escolher o projeto que deverá ser iniciado, a empresa deverá avaliar o
andamento dos projetos. Para isso, existem técnicas que podem ser aplicadas, conforme
discorreremos a seguir.

2.2 MÉTODOS DE AVALIAÇÃO

Segundo Cooper (2009), os métodos de avaliação, que podem ser utilizados
para validar uma ideia que poderá se tornar um projeto futuro, podem ser o stage – gate
(fase + portal) ou o processo analítico de hierarquização (Analytic Hierarchy
Process – AHP).

Charvat (2010) explica que, ao utilizar o método stage – gate, um ciclo de

avaliações será iniciado, englobando todas as ideias candidatas que pleiteiam se tornar
futuros projetos, com o objetivo de filtrar as melhores ideias. Para isso, são definidos três
portais que irão analisar as ideias, de acordo com os critérios já mencionados.

Entre os portais, estão as fases de cada ideia, como a análise dos riscos, dos
pontos fortes e fracos da empresa e de seus concorrentes, além do estudo de viabilidade
técnica e econômica do projeto.

Entre um portal e outro, uma das fases deverá ser analisada para todos os
projetos, servindo de filtro para o próximo portal, que irá receber apenas as ideias que
atenderem às expectativas definidas inicialmente pela empresa.

Ao final de todos os portais, as ideias aprovadas irão compor o portfólio de

projetos da empresa, em consonância com Cooper (2009).

Um exemplo dessa dinâmica é apresentado na Figura 11.

152
 Figura 11 – Funis do método stage – gate

Fonte: adaptada de Cooper (2009)

Cada funil, apresentado na Figura 11, representa um portal, a partir do qual serão
submetidas as ideias. Cada portal terá uma fase, que servirá de “peneira” para avaliar as
ideias de entrada no portal. Apenas as ideias que passarem pela fase analisada servirão
de entrada para o próximo funil, que irá analisá-las com base em outra fase. Ao final do
terceiro funil, as ideias que forem aprovadas na última fase irão compor o portfólio da
empresa (no exemplo da Figura 11, apenas a ideia 3 será aprovada).

2.2.1 Método AHP ou Método Multicritério

Segundo Saaty (1980), o método AHP ou o método multicritério se baseiam
no processo de ponderação de critérios de seleção de novos projetos, seguindo uma
hierarquização desses projetos já ponderados, executado em quatro etapas distintas:

• Seleção de critérios – deve-se selecionar uma lista de critérios que serão utilizados
para ponderação, com base nos valores e metas da empresa, como quantidade de
recursos envolvidos, custos do projeto e os riscos envolvidos.
• Ponderação dos critérios selecionados – os critérios selecionados na etapa
anterior deverão ter pesos atribuídos, como notas, que devem equivaler ao nível de
importância do critério para o negócio da organização.
• Defi nição da escala para avaliar as alternativas – é necessário definir uma
escala com cinco níveis, que irá avaliar o grau de importância de um projeto em
relação a um determinado critério. A escala poderá adotar valores muito baixos,
baixos, médios, altos, muito altos.
• Avaliação das propostas de projetos – fase em que os projetos terão notas
atribuídas para os critérios definidos, conforme a escala adotada na etapa anterior.
Ao final da avaliação de todos os projetos, o resultado será a nota final de cada
projeto, calculada conforme o peso de cada critério e o grau de importância para o
projeto, ordenada de forma crescente. Aquele projeto que obtiver a maior nota final
será o mais importante, e assim sucessivamente.

153
 O Quadro 9 apresenta um exemplo de aplicação do método AHP.

Quadro 9 – Exemplo de utilização do método AHP

Projetos Custos (0,5) Risco (0,3) Velocidade (0,2) Nota ponderada

5 10 10
1 7,5 (3º lugar)
2,5 3 2
10 5 8
2 8,1 (1º lugar)
5 1,5 1,6
9 7 6
3 7,8 (2º lugar)
4,5 2,1 1,2
Fonte: adaptado de Saaty (1980)

O exemplo apresentado envolve a análise de três projetos (Quadro 9), com base
nos critérios: custos (com peso de 0,5 ou 50%), risco (com peso de 0,3 ou 30%) e
velocidade (com peso de 0,2 ou 20%). Para cada projeto, deve-se atribuir uma nota
de 0 a 10 para cada critério (primeira linha de cada critério), cuja nota ponderada será
calculada conforme o peso do critério (segunda linha de cada critério). A coluna de nota
ponderada representará a soma de todas as notas ponderadas calculadas para cada
projeto e será utilizada em ordem decrescente, para indicar o nível de importância do
projeto para a organização.

ATENÇÃO
Acadêmico, devemos perceber que a soma dos pesos atribuídos para cada
critério deve ser igual a 100%.

Segundo Saaty (1980), após finalizar o processo de montagem do portfólio, com

a avaliação dos principais projetos, conforme os critérios selecionados pela empresa,
será necessário definir, para cada projeto, como acontecerá seu fluxo de trabalho dentro
da organização.

Nem sempre o mesmo fluxo poderá ser aplicado para diferentes projetos, então,
é importante que as peculiaridades de cada projeto sejam consideradas na elaboração
de seu fluxo específico.

154
2.3 FATORES CRÍTICOS DE SUCESSO
Para Pressman (2005), os fatores críticos de sucesso (FCS) são os
elementos-chave que determinam o sucesso ou fracasso de um projeto, programa ou
iniciativa. Já Sommerville (2011a) ressalta que os fatores críticos de sucesso são aqueles
aspectos que, se bem gerenciados, permitem que a organização atinja seus objetivos
e metas. Esses fatores críticos irão auxiliar na avaliação tanto de projetos que forem
desenvolvidos por métodos preditivos quanto utilizando metodologias ágeis.

Segundo Maximiano e Veroneze (2022), é possível agrupar os FCS em cinco

grupos, conforme apresentado no Quadro 9.

Quadro 9 – Resumo dos principais fatores críticos de sucesso

Fatores Fatores
Fatores técnicos Processos Projeto
organizacionais humanos
Estar de
Pessoas que Definição
Conhecimento acordo com o
Apoio da alta atendam ao clara sobre
técnico prévio da cronograma e
administração. perfil técnico os objetivos
equipe. planejamento
desejado. do projeto.
efetuado.

Participação
Aplicação de boas Capacitação
Ambiente efetiva do
práticas para da equipe e –
favorável. cliente ao longo
desenvolvimento. treinamento.
do processo.
Conhecimento
Aceitação
e aplicação de
Cultura do cliente e
metodologias – –
organizacional. feedbacks
ágeis para
constantes.
desenvolvimento.
Estratégia de
Interesses
– – entrega dos –
políticos.
resultados.

Fonte: adaptado de Maximiano; Veroneze (2022)

Como observamos a partir do Quadro 9, é importante que um projeto tenha,

por exemplo, o apoio da alta administração da empresa, assim como a participação
efetiva do cliente, com sua aceitação e validação constantes, além de uma equipe com
membros bem capacitados para efetuar as tarefas necessárias em todas as etapas do
projeto.

Maximiano e Veroneze (2022) afirmam que um fator crítico de sucesso

representará um “termômetro” do projeto, já que, caso muitos pontos, tidos como FCS,

155
 estejam ausentes de um projeto que se inicia, isso é um forte indicativo de que esse
projeto poderá não atingir seu objetivo final, podendo ser interrompido de forma abrupta
e gerando prejuízos aos patrocinadores e à empresa que o desenvolvia.

Segundo Anderson (2011), o responsável pela avaliação de um projeto é, muitas

vezes, o gerente de projetos, devido ao seu grau de liderança na equipe. Entretanto, em
equipes ágeis, é importante entender como funciona o processo de liderança.

2.3.1 Liderança em equipes ágeis

Segundo Anderson (2011) e Maximiano e Veroneze (2022), quando se trata de
um projeto que utilizará metodologias ágeis para sua execução, é importante que a
organização já possua a cultura ágil em andamento, pois se trata não apenas de adotar
novas ferramentas, mas de adaptar todo o fluxo de trabalho da empresa, que deverá
compreender e seguir, corretamente, os princípios ditados pelo manifesto ágil. A forma
de cooperação entre o cliente (patrocinadores) e a equipe se dá de modo diferente
quando comparado aos métodos preditivos, sendo esse apenas um exemplo da
mudança cultural necessária.

Segundo Anderson (2011) e Caroli (2020), a forma como a liderança deve

acontecer em equipes que adotam metodologias ágeis também se apresenta
diferenciada de equipes que seguem as metodologias tradicionais. Em equipes ágeis,
espera-se que estas sejam autogerenciáveis, sendo cada membro responsável por
analisar as demandas disponíveis e, de forma proativa, apropriar-se da resolução de
uma tarefa, conforme a ordem de prioridade acordada pelo time.

A figura autoritária do líder de projetos, em projetos ágeis, não se faz presente,

enquanto, em projetos que seguem as metodologias preditivas, ainda se prega a
necessidade de atribuição de tarefas ao time pelo líder (ou gerente de projetos).

Provinciatto e Caroli (2020) afirmam que, ao decidir adotar metodologias ágeis

em uma empresa, se dá muito mais liberdade ao profissional para que possa desenvolver
suas habilidades e suas potencialidades.

Estimula-se a troca de informações e o conhecimento entre os participantes

de uma equipe, por meio de seminários internos ou eventos nos quais cada um possa
passar seus conhecimentos aos demais, assim como é estimulada a cooperação entre
os membros na resolução de problemas durante o andamento de um projeto, como
acontece com a programação em pares.

Também há mudanças quando o assunto é responder a possíveis alterações no

escopo ou prioridade das tarefas em equipes que utilizam metodologias ágeis.

156
 Segundo Provinciatto e Caroli (2020), enquanto, nas metodologias tradicionais,
uma mudança após o início do projeto não é algo visto com bons olhos, pois irá
alterar todo o planejamento já concluído e que deve ser cumprido à risca até o final do
projeto, nas equipes ágeis, uma mudança é bem-vinda em qualquer etapa do projeto,
bastando ser acordada com as partes interessadas. A repriorização de atividades é algo
relativamente comum no dia a dia de uma equipe ágil, mantendo sempre o foco nas
tarefas que agregarem um maior valor ao negócio do cliente e satisfazerem suas reais
expectativas e necessidades.

Segundo Sutherland (2016), outro ponto importante que diferencia metodologias

ágeis das tradicionais são os valores que devem ser seguidos pelos membros das equipes,
pois, nas metodologias tradicionais, o cliente não acompanha o processo de execução
do projeto, tendo sua participação limitada apenas ao início (fase do levantamento de
requisitos) e ao final (fase de entrega do projeto já concluído). Já nas metodologias
ágeis, o cliente faz parte do processo de execução, sendo de fundamental importância
seu acompanhamento e feedback constantes para o sucesso do projeto.

Segundo Pereira, Torreão e Marcal (2007), enquanto todo o negócio do projeto

precisa ser completamente compreendido antes de seu início, em metodologias
tradicionais, as metodologias ágeis introduzem a figura do dono do produto (Product
Owner), que irá representar o cliente (e as demais partes interessadas) dentro da equipe
de desenvolvimento, sendo a pessoa que irá estar em contato direto com o cliente,
para o completo entendimento do negócio e de suas regras e posterior explicação aos
desenvolvedores.

Pereira, Torreão e Marcal (2007) e Sutherland (2016) afirmam que o processo de

documentação é outro fator que sofre alteração nas diferentes metodologias. Enquanto
sua elaboração é custosa e demanda tempo em demasia nas metodologias tradicionais,
em metodologias ágeis, ela se resume ao necessário para garantir que se entenda o
negócio a ser implementado e facilite a manutenção, tanto pelos atuais membros da
equipe quanto para os membros que venham, futuramente, a compor essa equipe.

Acadêmico, a seguir, apresentaremos o processo de gerenciamento de

configuração e quais as configurações necessárias para serem gerenciadas em um
projeto.

3 GERENCIAMENTO DE CONFIGURAÇÃO
Segundo Sommerville (2011), a gestão da configuração é uma técnica
fundamental para garantir a integridade do sistema ao longo de todo o seu ciclo de
vida, desde o planejamento até a manutenção, passando pela produção e pelo
desenvolvimento.

157
 A gerência de configuração de um projeto está relacionada com a forma como os
principais artefatos serão armazenados e, quando necessário, recuperados, de acordo
com Humble e Farley (2014). Nesse caso, os artefatos correspondem a documentação
produzida, código fonte da aplicação e demais configurações necessárias para garantir
o pleno funcionamento da aplicação, em caso de necessidade de montagem de novo
ambiente operacional.

Muitas vezes, o processo de gerenciamento de configurações pode ser

confundido apenas com o controle de versão dos artefatos tidos como essenciais,
mas não se resume apenas a isso, conforme pontuam Humble e Farley (2014). Para
que haja um gerenciamento efetivo, é necessário que um plano de gerenciamento
de configuração seja elaborado, indicando o local de armazenamento, o que deve ser
armazenado, qual a frequência de geração e gravação de novas cópias, entre outras
informações importantes para as configurações do projeto.

Para Humble e Farley (2014), as configurações armazenadas precisam ser

identificadas de forma única, a fim de que facilite o processo de recuperação e alteração,
conforme necessário. O processo de gerenciamento de configurações de um projeto
refletirá na sua evolução, já que irá acompanhar todo o ciclo de vida da aplicação
construída com o projeto, mapeando suas melhorias em termos de funcionalidades,
correção de erros e as versões produzidas ao longo do tempo.

Para auxiliar no processo de gerenciamento de configuração de um projeto,

existem ferramentas, porém adotar uma ferramenta deve ser uma ação seguida pela
elaboração de um plano, que possibilite que um novo ambiente operacional consiga
ser montado para o projeto em questão, de modo rápido, fácil e sem complicações
(HUMBLE; FARLEY, 2014).

Humble e Farley (2014) explicam que, ao montar um ambiente operacional

para o projeto, é preciso ter em mente que as configurações armazenadas devem
ser suficientes para que um membro da equipe técnica consiga montar, do zero, um
novo ambiente sem a necessidade de intervenção externa, ou seja, apenas seguindo
a documentação disponível no repositório que estará com o gerenciamento ativo, sem
que outras pessoas possam estar envolvidas e sem ajuda de outras documentações.

Outra questão importante para o processo de gerenciamento de configurações

é a facilidade de implantação de mudanças (HUMBLE; FARLEY, 2014). Um bom plano
de gerenciamento deve ser capaz de permitir que mudanças possam ser implantadas
nos diferentes ambientes operacionais do projeto (por exemplo, ambiente de
desenvolvimento, homologação ou testes e produção), de forma fácil e seguindo os
mesmos passos.

Quando o gerenciamento de configurações é implantado de modo correto em

um projeto, é possível, por exemplo, identificar a mudança que gerou um determinado
erro, podendo reverter a aplicação a um estado anterior, mantendo o funcionamento

158
da aplicação. Por isso, é importante que cada item seja identificado de maneira única,
já que, a partir desse identificador, a mudança poderá ser revertida, como mencionam
Humble e Farley (2014).

IMPORTANTE
O gerenciamento de configuração de um projeto é, especialmente, importante
quando existem diferentes equipes envolvidas no processo de execução do
projeto, sendo necessário manter um histórico de tudo que cada equipe fez,
com informações sobre autor de cada modificação e quando a modificação foi
feita e implantada.

ESTUDOS FUTUROS
Acadêmico, na Unidade 3 desta disciplina, abordaremos, com mais detalhes,
o processo de gerenciamento de configurações, além de apresentarmos as
ferramentas que podem ser utilizadas para essa finalidade.

Para que as configurações corretas possam ser armazenadas de forma eficiente,

de acordo com Humble e Farley (2014), é necessário que o gerente de projetos crie
um plano de gerenciamento de configuração, como apresentaremos no subtema
a seguir.

3.1 PLANO DE GERENCIAMENTO DE CONFIGURAÇÃO

Segundo Oliveira (2007), o plano de gerenciamento de configuração deve iniciar
com a fase de execução do projeto, indicando quais os artefatos que serão armazenados
(documentação, código fonte, configurações do sistema operacional e infraestrutura,
aplicativos de terceiros que serão utilizados etc.), qual a forma que essas configurações
serão identificadas e armazenadas, e como deverá acontecer o processo de atualização
dos artefatos já armazenados.

Conforme Humble e Farley (2014), à medida que o projeto tem andamento e

eventuais novos artefatos são identificados, é importante que sejam inseridos no plano
de configuração e passem, a partir de então, a serem monitorados.

159
 Segundo Maximiano e Veroneze (2022), o plano de gerenciamento de
configurações pode ser implementado por meio da utilização de ferramentas de controle
de versão, como algumas disponíveis no mercado, podendo-se citar três exemplos mais
utilizados pelas equipes de desenvolvimento:

• GIT – ferramenta de código aberto para controle de código fonte, com diversas
funcionalidades para garantir a correta utilização por diferentes equipes que
trabalhem em um mesmo projeto ou para equipes compostas por muitos membros
que possam trabalhar em um mesmo arquivo.
• CVS – primeira ferramenta amplamente difundida para controle de versão de código
fonte em equipes de trabalho, sendo também de código aberto. Perdeu bastante
popularidade após a ferramenta Git ter sido criada e seu uso, difundido.
• SVN – também de código aberto, não possui tantas funcionalidades como a
ferramenta Git, o que fez perder bastante sua fatia de mercado para controle de
versão.

ESTUDOS FUTUROS
Acadêmico, abordaremos, com mais detalhes, o funcionamento dessas
ferramentas de versionamento de código na Unidade 3. Também serão
apresentadas outras ferramentas de controle de versão, além das listadas
anteriormente.

Pressman (2016) afirma que, ao adotar uma ferramenta de controle de versão

como parte do plano de gerenciamento de configurações de um projeto, é importante
que a equipe utilize boas práticas para garantir que nenhum trabalho seja perdido. Isso
inclui atualizações periódicas do repositório pelos membros, sendo cada um responsável
pelas atualizações no repositório das tarefas em que havia trabalhado anteriormente.

Como o repositório poderá ser acessado a partir de qualquer máquina, desde

que se esteja conectado à rede da empresa (uma conexão VPN), é possível perceber
que os membros de uma equipe mantêm o repositório em dia quando, por exemplo,
uma máquina de um dos desenvolvedores apresenta um problema. Nesse caso, se o
repositório estiver atualizado conforme o esperado, não haverá prejuízo para o projeto,
em termos de retrabalho, para a tarefa que estava em desenvolvimento pelo membro.
Caso o repositório não esteja em dia com suas atualizações, todo o trabalho feito pelo
membro cuja máquina apresentou problema será perdido (pelo menos desde que a
última atualização aconteceu), causando prejuízos de tempo e esforço ao projeto.

160
 Além do gerenciamento das configurações de um projeto, outras variáveis
precisarão ser gerenciadas, como o escopo do projeto. Dessa forma, busca-se
garantir que as fronteiras estabelecidas de trabalho não serão transpostas. A seguir,
apresentaremos como as mudanças poderão ser controladas.

3.2 PLANO DE GERENCIAMENTO DE MUDANÇAS

A introdução ao controle de mudança, descrita pelo PMI (2017), consiste em
garantir que as mudanças propostas em um sistema, processo ou projeto sejam
gerenciadas de forma eficiente e eficaz, a fim de minimizar os riscos e maximizar os
benefícios. É uma parte importante da gestão de projetos, utilizada em vários setores,
como TI, construção, finanças e saúde.

IMPORTANTE
Segundo Pressman (2016), o conceito de controle de mudança pode ser
definido como o processo sistemático de identificar, avaliar e gerenciar as
solicitações de mudanças em um projeto ou em um ambiente de produção.

O objetivo é minimizar os impactos negativos das mudanças e maximizar os

resultados positivos, garantindo a entrega bem-sucedida do projeto dentro de prazo,
orçamento e escopo acordados.

Joglekar (2017) lista as seguintes etapas do processo de controle de mudança:

• Identificação da mudança – identificar a necessidade de uma mudança e avaliar

se é viável e se deve ser considerada.
• Análise de impacto – avaliar os impactos da mudança em termos de tempo,
orçamento, escopo e qualidade.
• Aprovação ou rejeição – decidir se a mudança será aprovada ou rejeitada com
base nas avaliações de impacto e nas políticas e nos procedimentos do projeto.
• Implementação – executar as atividades necessárias para implementar a mudança.
• Monitoramento e avaliação – monitorar e avaliar o progresso da mudança e os
impactos.
• Conclusão – concluir o processo de controle de mudança, documentar as mudanças
e garantir que elas sejam incorporadas ao gerenciamento de configuração do
projeto.

Para que o processo de gerenciamento de mudanças aconteça, é preciso

compreender o conceito dos itens de configuração, como apresentado a seguir.

161
 3.2.1 Itens de Configuração
Segundo Pressman (2016), a configuração é a coleção de itens que compõem
um sistema ou produto, incluindo hardware, software, documentação, dados e todas as
outras partes físicas ou lógicas necessárias para suportar o seu uso.

Pressman (2010) destaca, ainda, que um item de configuração (IC) é uma

unidade de informação criada durante o desenvolvimento de um software ou que seja
necessária para o desenvolvimento.

IMPORTANTE
Os itens de configuração podem incluir documentos, arquivos-fonte e
ferramentas de software utilizados no desenvolvimento. Cada item de
configuração é identificado de maneira única e pode ser rastreado ao longo do
tempo para acompanhar sua evolução.

Segundo ISO (2019), os princípios da configuração de itens incluem objetos,

aprovação, metadados e papéis:

• Objetos de configuração – são os itens físicos ou virtuais gerenciados ao longo

de todo o seu ciclo de vida. Podem incluir hardware, software, documentos etc.
É importante controlar e rastrear esses objetos, para garantir a qualidade e a
integridade do projeto.
• Aprovação – princípio que se refere à aprovação formal de mudanças em objetos
de configuração. Isso garante que as mudanças sejam revisadas e autorizadas
antes de serem implementadas, proporcionando, assim, qualidade e integridade ao
projeto.
• Metadados – são informações adicionais armazenadas com os objetos de
configuração, incluindo informações sobre a versão, o status, o autor, a data e
hora da modificação, entre outras informações relevantes. Esses metadados são
importantes para o rastreamento e o gerenciamento de objetos de configuração.
• Papéis – referem-se à atribuição de responsabilidades e autoridade a indivíduos ou
equipes, para garantir o controle efetivo dos objetos de configuração. Esses papéis
incluem, por exemplo, o proprietário do objeto, o revisor, o aprovador e o controlador
de configuração.
• Exercícios de revisão – são importantes para garantir que o processo de
configuração de itens funcione corretamente. Segundo o PMI (2017), podem incluir
revisões regulares de objetos de configuração, revisões periódicas de processos e
procedimentos e revisões formais antes da liberação de um produto.

162
 Em outras palavras, os itens de configuração são elementos importantes
para o gerenciamento de configuração do software, pois permitem a identificação e o
rastreamento das partes que compõem o produto de software.

ESTUDOS FUTUROS
Abordaremos os itens de configuração e as normas relativas ao processo de
gerenciamento de configurações na Unidade 3 desta disciplina.

Segundo Sommerville (2011) e Cabral (2015), a gerência de configuração é uma

prática importante em gerenciamento de projetos de software, engenharia de sistemas
e outras indústrias que lidam com produção e manutenção de sistemas complexos.
Entre as terminologias comumente usadas em gerência de configuração, estão:

• Item de configuração – qualquer coisa que pode ser identificada e controlada em

um projeto, como código-fonte, documentos, equipamentos, materiais etc.
• Identificação de configuração – um processo para identificar, numerar e nomear
os itens de configuração de um projeto.
• Controle de configuração – o processo de garantir que apenas versões
autorizadas de itens de configuração sejam usadas em um projeto e que mudanças
sejam registradas e avaliadas antes de serem implementadas.
• Mudança de configuração – qualquer modificação realizada em um item de
configuração, incluindo correções, melhorias e atualizações.
• Repositório de configuração – um local centralizado, onde todos os itens de
configuração de um projeto são armazenados e gerenciados.
• Histórico de configuração – um registro detalhado das mudanças realizadas em
cada item de configuração ao longo do tempo.
• Baseline de configuração – uma versão aprovada de um item de configuração
que serve como referência para futuras mudanças.
• Integração de configuração – o processo de combinar vários itens de configuração
em um sistema ou produto completo.
• Verificação de configuração – o processo de verificar se um item de configuração
ou sistema atende aos requisitos e às especificações.
• Validação de configuração – o processo de confirmar que um sistema ou produto
completo atende aos requisitos do usuário e está pronto para uso.
• Check-out – caracteriza-se pelo processo de retirada de uma versão de um item
de configuração do repositório de configuração para modificação ou uso.
• Check-in – definido como o processo de retorno de uma versão modificada de um
item de configuração para o repositório de configuração.
• Build – processo de compilação do software a partir dos códigos fontes e outros
itens de configuração.

163
 • Release – a entrega formal de um conjunto de itens de configuração para um
ambiente de produção ou para outro uso.
• Branch – uma cópia independente de um item de configuração, que permite a
evolução independente das versões.
• Merge – processo de combinar duas ou mais versões de um item de configuração
em uma única versão.

Essas ferramentas são importantes para garantir a integridade e a consistência

dos itens de configuração ao longo do ciclo de vida do software.

Um conceito que precisa ser apresentado são os princípios e as técnicas de

manutenção de software, tendo em vista que os itens de configuração são provenientes
desses processos.

3.3 PRINCÍPIOS E TÉCNICAS DE MANUTENÇÃO DE SOFTWARE

Sommerville (2011) afirma que os princípios e as técnicas de manutenção de
software são uma série de boas práticas e abordagens que visam a manter o software
funcionando de forma eficiente e correta, ao longo do tempo. Alguns dos princípios e
técnicas mais comuns incluem:

• Modularidade – segundo Pressman (2016) e Sommerville (2009), refere-se à

divisão do software em módulos independentes, que podem ser testados e mantidos
separadamente. Isso facilita a manutenção e melhoria da aplicação, uma vez que
é possível fazer alterações em um módulo sem afetar o funcionamento de outros.
• Documentação – Pressman (2016) afirma que a documentação é crucial na
manutenção de software, pois fornece informações sobre o funcionamento do
software e como ele foi desenvolvido. Isso permite que desenvolvedores possam
entender o programa e fazer alterações de forma mais eficiente, o que demonstra
que a documentação é uma das principais técnicas de manutenção de software.
• Testes – Royce (1970) explica que os testes são uma das técnicas mais importantes
de manutenção de software, pois ajudam a garantir seu pleno funcionamento e
corrigir problemas antes que eles causem danos;

IMPORTANTE
Esses são apenas alguns dos principais princípios e técnicas de manutenção
de software. A manutenção de software é uma tarefa complexa e contínua,
que requer uma abordagem cuidadosa, disciplinada e de melhoria contínua.

164
 Pressman (2005) afirma que, quando nos referimos ao processo de manutenção
de uma aplicação, precisamos compreender que, em determinados momentos, é
necessário ajustar a aplicação, para melhorar seu desempenho ou utilizar bibliotecas
mais atuais. Com isso, a refatoração se mostra um processo importante.

3.4 REFATORAÇÃO
Sommerville (2011) explica a refatoração como um processo de melhoria
contínua do código fonte de uma aplicação, a fim de reduzir a degradação resultante
dos diversos processo de intervenção ao longo do tempo. Dessa forma, o intuito de um
processo de refatoração em um código fonte será tornar o código mais legível (maior
facilidade de um programador ler e entender o propósito do código), além de reduzir sua
complexidade.

O processo de refatoração de código, conforme explica Fowler (2019), é

importante para garantir que o código de um projeto utiliza as melhores práticas de
programação e se apresenta de forma clara, possibilitando a outros desenvolvedores
realizarem manutenções (adaptativas, evolutivas ou corretivas), de forma intuitiva, no
projeto.

Segundo Pressman (2016), quando um projeto não passa por constantes

revisões em seu código e refatorações, a tendência é que o projeto acabe por entrar em
desuso, sendo, rapidamente, substituído por outro.

ATENÇÃO
Conforme Fowler (2019), é imprescindível que haja, periodicamente, ajustes na
forma como o código está escrito, garantindo que o menor trecho de código
possível esteja escrito da modo mais otimizado possível, trazendo clareza na
lógica e intuitividade na escrita, ou seja, o código precisa ser autoexplicativo.

Sommerville (2011) apresenta algumas situações nas quais se deve refatorar um

código:

• Código duplicado – é comum que, em diferentes partes de um mesmo projeto,

existam trechos de código que estejam duplicados, sendo necessário que as
duplicidades sejam removidas.
• Métodos longos – métodos muito extensos, muitas vezes com mais de uma
responsabilidade (funcionalidade) implementada, precisam ser quebrados em
pequenos métodos, cada qual com apenas um objetivo.

165
 • Múltiplas declarações do comando switch-case – caso um projeto possua, em
diferentes locais, muitas declarações de comandos switch-case, é possível que
essas múltiplas declarações sejam otimizadas por meio de polimorfismo, em caso
de linguagens de programação orientadas a objetos.
• Aglutinação de dados – quando muitos dados, associados a um mesmo grupo
de dados (objeto ou conceito, em caso de linguagens orientadas a objetos), são
utilizados em diferentes partes de um mesmo código, é possível substituir esse
conjunto de dados por uma classe que possua todos eles como atributos, conceito
conhecido como objeto.
• Generalidade especulativa – quando desenvolvedores, de forma preditiva,
criam generalidades em um código com a perspectiva (nem sempre real) de que
essas generalizações sejam utilizadas em momentos futuros (o que nem sempre
acontece), é possível otimizar o código removendo essas generalizações inutilizadas.

Fowler (2019) explica que o processo de refatoração deve acontecer sob

demanda, ou seja, à medida que novas intervenções são feitas em um projeto, caso o
time de desenvolvimento se depare com alguma das situações possíveis para aplicação
de refatoração, então, esta deverá ser feita. Desse modo, aos poucos. o código irá se
tornar limpo e intuitivo para novas manutenções, além de ter sua execução otimizada
em muitas vezes.

DICA
Fowler (2019) apresenta uma série de exemplos práticos e técnicas de
refatoração em sua obra Refactoring – improving the design of existing code, o
que torna a sua leitura indispensável para quem se interessa pela construção
de códigos otimizados e pela aplicação de boas práticas de programação.

Segundo Sommerville (2011), enquanto a refatoração tem o objetivo de melhorar

continuamente um código, por meio da reescrita de trechos considerados ineficientes,
mas mantendo a mesma estrutura arquitetural do projeto, a reengenharia, por outro
lado, tem o objetivo de reestruturar a arquitetura do projeto e sua documentação,
de maneira a facilitar o seu entendimento pelo time de desenvolvimento e facilitar o
processo de mudanças.

166
3.5 REENGENHARIA DE SOFTWARE
Segundo Pressman (2016), a reengenharia de software envolve análise de
inventário, engenharia reversa da aplicação, além da reestruturação dos dados. Então, a
partir de uma reengenharia, é possível atualizar as tecnologias envolvidas na construção
da aplicação original, a forma como os componentes da aplicação se comunicam e a
forma como os dados são organizados e mantidos.

IMPORTANTE
Segundo Sommerville (2011), por mais que sejam conceitos parecidos,
refatoração e reengenharia de software possuem nuances diferentes.
Enquanto a refatoração mantém a arquitetura, apenas se preocupando
com a legibilidade (facilidade de leitura), a manutenibilidade (facilidade de
manutenção) e a otimização do código já escrito, a reengenharia recria a
aplicação, podendo alterar sua linguagem de escrita original, os componentes
envolvidos na arquitetura, a forma de comunicação entre estes componentes,
além de refazer toda a documentação disponível.

Pressman (2016) apresenta como motivos para a execução da reengenharia em

uma aplicação a garantia de suporte (suportabilidade) do software-alvo, tendo em vista
que as tecnologias evoluem com o passar do tempo e, caso a aplicação não acompanhe
essa evolução, poderá se tornar obsoleto e entrar em desuso rapidamente.

ATENÇÃO
Outro ponto de atenção mencionado por Pressman (2016) é a diferença
entre reengenharia no processo de negócio e a realizada no software em si.
A reengenharia voltada ao processo de negócio está ligada às alterações nas
regras de negócio da aplicação, ou seja, ao domínio do problema de negócio,
enquanto a reengenharia no software objetiva atender às necessidades do
usuário final, tornando a aplicação mais intuitiva ao uso.

Sobre o processo de reengenharia no processo de negócio, Pressman (2016)

afirma existirem seis atividades cíclicas para que o processo se complete:

• Defi nição do negócio – quando os objetivos da reengenharia serão traçados,

como redução do custo, tempo, melhoria na qualidade do produto ou evolução
profissional dos membros da equipe.

167
 • Identificação do processo – fase em que os processos necessários para atingir
os objetivos traçados na etapa anterior são identificados e classificados em níveis
de importância para o processo de reengenharia.
• Avaliação do processo – o processo atual deverá ser analisado, medindo-se
custos, tempos de execução e eventuais problemas existentes, em termos de
performance.
• Especificação e projeto do processo – cada processo que precise ser reescrito
deverá ser especificado, de modo a identificar seus cenários de utilização e
os resultados esperados. As tarefas que deverão compor o processo após a
reengenharia deverão ser mapeadas.
• Prototipação – um protótipo visual deverá ser criado para o novo processo
mapeado, possibilitando a integração e o teste deste processo remodelado no
software e, caso necessário, os devidos refinamentos.
• Refi namento e instanciação – após todas as etapas anteriores terem sido
concluídas, o processo repaginado deverá ser implementado.

IMPORTANTE
Sommerville (2011) afirma que existem limites para que a reengenharia
aconteça em uma aplicação. Caso seja necessária a migração de paradigmas,
ou seja, uma aplicação inicialmente construída em uma linguagem procedural
que deverá ser migrada para o paradigma orientado a objetos, os custos
inerentes ao processo de reengenharia poderão não justificar o processo,
tornando mais barata a construção de uma nova aplicação.

Então, apesar da reengenharia de software ser uma solução viável para a

melhoria contínua de uma aplicação, alterações muito profundas em um código podem
não ter o efeito esperado de facilidade de manutenção, sendo mais indicada, nesses
casos, a construção de uma nova aplicação.

Segundo Pressman (2016), existem casos que uma organização necessita que
uma aplicação seja migrada, como resultado de uma atualização tecnológica, ou até de
pequenas mudanças efetuadas no processo corrente, para um novo modelo de negócio
ou que apenas os dados sejam transferidos entre diferentes bases de dados. A esse
processo de atualização, atribuímos o nome de migração de software.

3.6 MIGRAÇÃO DE CÓDIGO

Segundo Pressman (2016), diversos são os fatores que podem desencadear
uma migração de software, podendo-se incluir:

168
• Atualização na versão do sistema operacional de uma aplicação.
• Mudança na estratégia de negócios da empresa.
• Infraestrutura atual não suporta mais as necessidades da aplicação (capacidade de
processamento, espaço de armazenamento de dados etc.).
• Necessidade de integração entre sistemas de diferentes empresas que efetuaram
uma fusão.
• Reestruturação no negócio da organização, refletindo na necessidade de ajustes
em suas aplicações críticas.

A Figura 12 apresenta os três estágios de um processo de migração de aplicação,

conforme Pressman (2016).

Figura 12 – Etapas do processo de migração de uma aplicação.

Fonte: adaptada de Pressman (2016)

No primeiro estágio, denominado processo atual, busca-se entender como

funciona o processo em produção, suas regras de negócio e como deve ser constituído
o processo final.

Tendo essas informações esclarecidas, é criado um processo intermediário (ou

de transição), de modo que seja possível a adaptação do software ao processo final,
por meio de pequenas atualizações periódicas. Por fim, espera-se que a aplicação siga
o processo modelado, sem ônus para o funcionamento de seus requisitos e sem perda
de dados.

169
 GIO
Acadêmico, neste tema de aprendizagem, aprendemos que todas as
organizações possuem metas, de forma direta ou indireta, planejando ações
para alcançar esses objetivos, o que irá representar a importância da gestão
estratégica de projetos.

Executar os projetos corretos, na ordem mais adequada para atingir os objetivos

organizacionais, determinará o sucesso ou fracasso de uma empresa perante seus
concorrentes.

Assim, a gestão estratégica poderá utilizar a matriz SWOT para identificar as

fraquezas e as oportunidades de um projeto, antes de sua execução. O planejamento
estratégico também deverá englobar a definição de KPIs, isto é, os marcos intermediários
que indicam que o projeto caminha para o sucesso esperado.

Os fatores críticos de sucesso são fundamentais para filtrar os projetos

candidatos à execução, assim como identificar e gerenciar as configurações de um
projeto significa que deve ser possível criar um ambiente para a aplicação, partindo do
zero, utilizando apenas as configurações armazenadas em um repositório que possibilite
o controle de versões dos itens armazenados.

Para concluir, ressaltamos a importância e a diferença entre as técnicas

de refatoração e reengenharia de software, assim como o processo de migração de
aplicação.

170
 LEITURA
COMPLEMENTAR
IMPLANTAÇÃO DE GERÊNCIA DE CONFIGURAÇÃO EM EMPRESA DE
DESENVOLVIMENTO DE SOFTWARE PARA GESTÃO PÚBLICA: UM ESTUDO DE
CASO

Jullian Hermann Creutzberg

Nilson Ribeiro Modro
Luiz Cláudio Dalmolin

1 INTRODUÇÃO

O processo de desenvolvimento de software está se tornando cada vez mais

complexo, seja pelo aumento da complexidade da infraestrutura de tecnologia da
informação ou pela dependência das organizações em relação aos serviços dispostos
por estas tecnologias (MAGALHÃES; PINHEIRO, 2007).

Uma das possíveis abordagens para tentar lidar com a complexidade no

desenvolvimento de softwares é a adoção de práticas envolvendo o gerenciamento
de configuração, que visa controlar as mudanças, bem como as versões, ou releases,
entregues aos clientes. Por vezes este processo é considerado parte do gerenciamento
de qualidade (SOMMERVILLE, 2011).

Pressman (1995, p. 735) afirma que “toda mudança no software tem potencial
para introduzir erros ou criar efeitos colaterais que propagam erros”. Portanto, é
fundamental que o controle de mudanças seja bem definido, aliado ao processo de
qualidade de software.

Outro ponto envolvido nessa questão é o gerenciamento de releases, que para

Sommerville (2011) envolve definições sobre as datas, preparar todas as informações
para a distribuição e a documentação de cada versão do sistema. Pode conter, ainda,
uma fase de revisão, inspeção e testes de release, visando garantir a qualidade do
produto que será entregue aos usuários.

Durante o ciclo de vida de um sistema, inúmeras versões serão desenvolvidas

e liberadas aos clientes, sendo os processos de gerenciamento de configuração,
aliados ao gerenciamento de qualidade, importantes para a manutenção da vida útil do
software. Justifica-se também a adoção desses processos, pois é uma forma de garantir
que as mudanças realizadas sejam controladas, previamente analisadas e aprovadas

171
 pelos responsáveis, devidamente testadas para que não interfiram negativamente nas
funcionalidades já existentes e para que os usuários sejam informados das mudanças
ocorridas.

[...]

3.1 GERENCIAMENTO DE CONFIGURAÇÃO

O processo de gerenciamento de configuração define as atividades, mediante

aplicação de procedimentos administrativos e técnicos, nas distintas fases do
desenvolvimento do software, com o objetivo de identificar e controlar os itens
entregáveis de um software e controlar as solicitações e realizações de mudanças,
o armazenamento das versões e a distribuição dos itens do software em um release
(WEBER; ROCHA; NASCIMENTO, 2001).

Contudo, controlar as mudanças no software e seus efeitos em outros

componentes do sistema requer grande esforço. Quanto mais complexa a aplicação,
mais componentes estão sujeitos a serem afetados; sendo assim, a gerência de
configuração é importante durante o desenvolvimento e é fundamental na fase de
manutenção do sistema (PFLEEGER, 2004).

Os processos de gerenciamento de configuração são abrangentes e aplicados a

todas as atividades de engenharia de software, contudo o gerenciamento de mudanças
pode ocorrer a qualquer tempo, conforme afirma Pressman:

É importante fazer uma distinção clara entre manutenção de software

e gerenciamento de configuração de software. A manutenção é um
conjunto de atividades de engenharia de software que acontece
depois que o software é entregue ao cliente e posto em operação.
O gerenciamento de configuração de software é um conjunto de
atividades de controle e rastreamento que começa quando um
projeto de desenvolvimento de software se inicia e termina somente
quando o software é tirado de operação (PRESSMAN, 1995, p. 917).

Conforme Sommerville (2011), diversas circunstâncias podem requerer

mudanças nos sistemas, sejam novas versões de hardware, novas plataformas de
sistemas, concorrentes que implementam novas funcionalidades que precisam ser
correspondidas, ou ainda novas necessidades dos usuários. Dessa forma, “mudanças
são feitas para o software e cria-se uma nova versão de um sistema. Portanto, a maioria
dos sistemas pode ser pensada como um conjunto de versões, sendo que cada uma
delas necessita ser mantida e gerenciada” (SOMMERVILLE, 2011, p. 475).

Já Wazlawick (2013, p. 221) destaca que “uma configuração de software é o

estado em que o software se encontra em determinado momento”. Complementa ainda
que podem estar relacionados às versões, além dos programas (códigos-fonte), outros

172
documentos eletrônicos que fazem parte do projeto de software. Paula Filho (2003)
afirma que projetos e produtos de software sofrem inúmeras mudanças durante o seu
ciclo de vida, e que os procedimentos e as técnicas de gestão de configuração contêm
artefatos para administrar essas alterações de forma organizada.

Desse modo, o gerenciamento de configuração de um produto de sistema de

software envolve quatro atividades afins (SOMMERVILLE, 2011):

• Gerenciamento de mudanças: visa manter o acompanhamento das solicitações dos

usuários e desenvolvedores por mudanças no sistema, procura definir os custos e
o impacto de fazer tais mudanças, bem como decidir se, e quando, as mudanças
devem ser realizadas.
• Gerenciamento de versões: destina-se a manter o controle das diversas versões do
software e assegurar que as mudanças não interfiram umas nas outras.
• Construção de sistema: processo de desenvolvimento de componentes do sistema,
banco de dados e bibliotecas e a compilação e ligação destes elementos para criar
um sistema executável.
• Gerenciamento de releases: envolve a preparação de software para a atualização
nos clientes e o acompanhamento das versões do sistema que foram liberadas para
uso.

Sabendo que as mudanças são inerentes ao processo de desenvolvimento e

ciclo de vida de um software, Pressman (1995, p. 916) afirmou que “as mudanças são
inevitáveis quando um software de computador é construído”.

Portanto, é fundamental o controle dessas solicitações, bem como das

alterações efetivamente realizadas, das versões produzidas e das liberações aos
usuários finais do software, sendo ainda muito importante que o usuário seja informado
de tais alterações. Pressman mostra ainda que as confusões geradas pelas mudanças
entre os envolvidos em um projeto de software ocorrem quando os procedimentos de
gerência de configuração não são aplicados, ou seja, as alterações não são analisadas
antes de serem feitas, não são registradas antes de serem implementadas, não são
relatadas para quem precisa tomar conhecimento ou não são controladas de forma que
os erros sejam reduzidos e a qualidade do produto final aumentada (PRESSMAN, 1995).

3.1.1 Gerenciamento de mudanças

“O controle de mudanças é uma atividade procedimental que garante

a qualidade e a consistência à medida que são feitas mudanças num objeto de
configuração” (PRESSMAN, 1995, p. 937). Da mesma forma, para Sommerville (2011, p.
478), “o gerenciamento de mudanças destina-se a garantir que a evolução do sistema
seja um processo gerenciado e que seja dada prioridade às mudanças mais urgentes e
efetivas”.

173
 No controle de mudanças de um sistema de software estarão indicadas as
funcionalidades que foram adicionadas, removidas ou modificadas, contendo também
os problemas corrigidos e pendências que eventualmente restam para uma versão
posterior (WAZLAWICK, 2013). As mudanças são inevitáveis no ciclo de vida de um
software; possivelmente, não havendo mudanças no sistema, logo ele se torna obsoleto
e substituível por qualquer outro mais moderno e que atenda aos requisitos do usuário,
conforme afirma Sommerville (2011, p. 477):

As necessidades e requisitos organizacionais se alteram durante

a vida útil de um sistema, bugs precisam ser reparados e os
sistemas precisam se adaptar às mudanças em seus ambientes.
Para garantir que as mudanças sejam aplicadas ao sistema de uma
forma controlada, você precisa de um conjunto de processos de
gerenciamento de mudanças [...].

Segundo Pfleeger (2004), são quatro os aspectos principais quando tratamos

da evolução dos sistemas: manter o controle sobre as funções do sistema, manter
o controle sobre as modificações do sistema, aperfeiçoar as funções aceitáveis já
existentes e tomar medidas preventivas para manter o nível de desempenho do sistema,
ou seja, o gerenciamento de mudanças deve se preocupar tanto com o estado atual do
sistema, quanto com as mudanças que ocorrem, porém, sem afetar as funcionalidades
existentes, mantendo o desempenho em níveis aceitáveis.

O processo de gerenciamento de mudanças “está relacionado com a análise

de custos e benefícios das mudanças propostas, a aprovação dessas mudanças que
valem a pena e o acompanhamento dos componentes do sistema que foram alterados”
(SOMMERVILLE, 2011, p. 478). Contudo, o gerenciamento de mudança dentro de um
contexto de projeto de desenvolvimento de software, pode ainda auxiliar os envolvidos
a aceitarem e se adaptarem ao sistema que está sendo modificado sem demasiado
estresse (DENNIS; WIXON, 2012).

3.1.2 Gerenciamento de releases

Controlar as entregas realizadas aos clientes, mantendo um agrupamento de

informações sobre a versão liberada, faz parte do gerenciamento de releases. Para
Sommerville (2011, p. 488), “um release de sistema é uma versão de um sistema de
software distribuída aos clientes”. Da mesma forma, para Wazlawick (2013), um release,
ou entrega, consiste na distribuição de uma versão do sistema externamente, ou seja,
fora do ambiente controlado de desenvolvimento. Complementa ainda que “o controle
de versão vai rastrear todos os artefatos do projeto (itens de configuração) e manter
o controle sobre o trabalho paralelo de vários desenvolvedores” (WAZLAWICK, 2013, p.
222).

174
 Verifica-se que em softwares que possuem grande quantidade de usuários,
chamados também como softwares de mercado de massa, normalmente, é
possível verificar dois tipos de releases: os releases principais, que fornecem novas
funcionalidades ao software; e os releases menores, que corrigem bugs e problemas
relatados por clientes (SOMMERVILLE, 2011).

Nesse sentido, Pressman afirma que “o controle de versão combina procedimentos

e ferramentas para gerenciar diferentes versões de objetos de configuração que são
criadas durante o processo de engenharia de software” (PRESSMAN, 1995, p. 927).
Sommerville (2011) mostra que elaborar e distribuir um release é um processo que pode
envolver alto custo, pois além dos trabalhos de criação, testes, revisão, documentação,
podem estar envolvidos trabalhos de publicidade para convencer os clientes a comprarem
a nova versão, ou simplesmente para que eles conheçam as novas funcionalidades
atribuídas ao software.

Com a ocorrência de mudanças nos sistemas e com a liberação dos releases,

bugs podem ser gerados e liberados aos usuários. Visando reparar o software, as
empresas fornecem correções que geralmente são mantidas em sites para que
possam ser baixadas pelos clientes. Para Sommerville, o problema relacionado a essas
correções que dependem de uma ação do cliente baixar, é que muitas vezes eles
desconhecem a necessidade do reparo ou não entendem a necessidade dele. Por este
motivo, fornecedores de software de massa, geralmente, implementam atualizações
automáticas em seus sistemas (SOMMERVILLE, 2011).

Dessa forma, sucintamente, o gerenciamento de release consiste no controle

das diferentes versões dos componentes do software, bem como no processo de
liberação e atualização desta versão no ambiente de produção aos usuários.

3.2 GERENCIAMENTO DE QUALIDADE

O gerenciamento de qualidade tem por objetivo verificar se o produto que será

entregue ao cliente está consistente com os padrões e com os requisitos, fornecendo
uma análise independente do processo de desenvolvimento do sistema. Portanto, a
equipe responsável pela garantia de qualidade do sistema “deve ser independente da
equipe de desenvolvimento para que eles tenham uma visão objetiva do software. Isso
lhes permite reportar sobre a qualidade de software sem sofrer influências de questões
de desenvolvimento de software” (SOMMERVILLE, 2011, p. 455).

O produto de software que será entregue aos usuários precisa de um controle de

qualidade bem definido; nesse sentido, Pressman (1995, p. 733) destaca que “a garantia
de qualidade é uma atividade fundamental para qualquer negócio que gere produtos
que são usados por outros”. Segundo Weber, Rocha e Nascimento (2001), o processo de

175
 garantia da qualidade faz parte dos processos de apoio ao projeto de software, já que
auxiliam e contribuem para o sucesso e qualidade do produto final. Sobre este processo
de garantia da qualidade, destacam:

Define as atividades para fornecer a garantia adequada de que

os processos e produtos de software, no ciclo de vida do projeto,
estejam em conformidade com seus requisitos especificados e
sejam aderentes aos planos estabelecidos [...] inclui questões como
garantia da qualidade do produto, do processo e do sistema de
qualidade (WEBER; ROCHA; NASCIMENTO, 2001, p. 5).

Pfleeger afirma que os fabricantes e engenheiros de software buscam maneiras

de certificar que o produto que entregam aos clientes está dentro de níveis aceitáveis de
qualidade; dessa forma devem ser utilizadas estratégias para produção de sistemas com
qualidade (PFLEEGER, 2004). Nesse sentido, a gerência de qualidade procura fornecer
essas estratégias, juntamente com artefatos e boas práticas, de modo a assegurar a
qualidade dos sistemas entregáveis.

Contudo, os “padrões e processos são importantes, mas os gerentes de

qualidade também devem ter como objetivo desenvolver uma ‘cultura de qualidade’ em
que todos os responsáveis pelo desenvolvimento de software estejam comprometidos
em alcançar um alto nível de qualidade de produto” (SOMMERVILLE, 2011, p. 456).
Assim, é necessário que as equipes assumam a responsabilidade pelo seu trabalho,
independentemente da fase de desenvolvimento, iniciando com o levantamento de
requisitos, passando pela codificação, até os testes e entrega do sistema.

3.2.1 Qualidade de software

A qualidade de software pode ser medida de acordo com a “conformidade

a requisitos funcionais e de desempenho explicitamente declarados, a padrões de
desenvolvimento claramente documentados e a características implícitas que são
esperadas de todo o software profissionalmente desenvolvido” (PRESSMAN, 1995, p.
724).

Afirma Wazlawick (2013), que está incluída na engenharia de software a área de

qualidade de software que visa garantir bons produtos, baseados em bons processos,
e comenta que se pode falar, então, de dois aspectos da qualidade: a qualidade do
produto em si e a qualidade do processo.

[...]

176
 3.2.2 Revisões e inspeções

Pressman afirma que “as revisões de software são um ‘filtro’ para o processo de
engenharia de software”. Complementa ainda que essas revisões servem para descobrir
defeitos durante o desenvolvimento de software para que possam ser eliminados antes
da entrega (PRESSMAN, 1995, p. 736).

Segundo Sommerville (2011), no processo de revisão, uma equipe revisa o

software e a sua documentação em busca de possíveis problemas de não conformidade
com os padrões. O objetivo dessa atividade é favorecer a qualidade do software e não
avaliar o desempenho dos programadores e da equipe de desenvolvimento. Nesse
sentido, ressalta o autor:

Revisões e inspeções são atividades de controle de qualidade que verificam

a qualidade dos entregáveis de projeto. Isso envolve examinar o software, sua
documentação e os registros do processo para descobrir erros e omissões e verificar
se os padrões de qualidade foram seguidos. [...], revisões e inspeções são usadas junto
com teste de programa, como parte do processo geral de validação e verificação de
software (SOMMERVILLE, 2011, p. 462).

Pressman (1995, p. 745) destaca: “revise o produto, não o produtor”, com o intuito
de reforçar a atividade de revisão como parte do processo de qualidade de software, e
não avaliação da produtividade. Para o autor “o benefício óbvio das revisões técnicas
formais é a descoberta precoce dos defeitos de software, de forma que cada defeito
possa ser corrigido antes do passo seguinte do processo de engenharia de software”
(PRESSMAN, 1995, p. 737).

[...]

Fonte: adaptada de http://revistagt.fpl.edu.br/get/article/view/1023/706. Acesso em: 10 fev. 2023.

177
 RESUMO DO TÓPICO 3
Neste tópico, você aprendeu:

• A gerência de configuração é uma estratégia crucial para o gerenciamento de

projetos de software, pois ajuda a manter o controle de mudanças no projeto,
garantindo que o software seja entregue com qualidade e dentro do prazo.

• A gestão estratégica em projetos é uma abordagem que enfoca na estratégia,

planejamento e gerenciamento de recursos, bem como na gestão de risco, para
garantir o sucesso do projeto.

• Os pilares da gestão estratégica incluem planejamento, gestão de recursos,

gerenciamento de risco e controle de mudanças.

• O gerenciamento de configuração é a prática de controlar e documentar todas as

mudanças no projeto de software. Isso ajuda a garantir a integridade e a qualidade do
software, bem como a manter o controle de mudanças durante o desenvolvimento.

• Os itens de configuração são elementos do projeto de software que são controlados

e mantidos durante o desenvolvimento. Eles incluem código-fonte, documentação,
arquivos de configuração e artefatos de construção.

• As terminologias em gerência de configuração incluem a configuração, item de

configuração, baselines, mudanças e versões.

• Os princípios de manutenção de software incluem documentação completa,

rastreabilidade, testes rigorosos e gerenciamento de mudanças. As técnicas
incluem gerenciamento de configuração, gerenciamento de versões, controle de
mudanças e gestão de migração de código.

178
 AUTOATIVIDADE
1 A elaboração de estratégias está presente em todas as Organizações, seja de forma
explícita ou implícita. Através das estratégias, é possível se definir marcos que
auxiliarão a atingir um determinado objetivo empresarial. Sobre a gestão estratégica,
assinale a alternativa CORRETA:

a) ( ) Irá focar em construir histórias de usuário para iniciar a fase de execução.

b) ( ) Se baseia em três pilares, que são o planejamento, a execução e a avaliação.
c) ( ) Se baseia nos pilares planejamento, refinamento e documentação.
d) ( ) Elabora um product backlog para o processo de planejamento se iniciar.

2 Uma das atividades da gestão estratégica é definir quais projetos comporão o

portfólio de projetos da Organização. Com base em seus conhecimentos sobre
gestão estratégica, analise as sentenças a seguir:

I- Um dos motivos que uma Organização poderá escolher um projeto, dentre tantos
outros, para ser executado é a velocidade de implementação.
II- Para selecionar projetos que irão compor o portfólio de projetos, técnicas podem
ser utilizadas, como a MVP.
III- As técnicas fase + portal e AHP podem ser utilizadas para filtrar os processos que
deverão compor o portfólio de projetos de uma Empresa.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) Somente a sentença III está correta.

3 O método AHP para seleção de projetos que deverão compor o portfólio da Empresa
é conhecido por ser multicritério, ou seja, utilizar de mais de um critério para que a
seleção de projetos aconteça. Considerando seus conhecimentos sobre o método
AHP, classifique V para as sentenças verdadeiras e F para as falsas:

( ) A ponderação dos critérios deverá ser a primeira tarefa a ser executada no ciclo de
avaliação dos projetos.
( ) A seleção dos critérios deve seguir os valores e metas da Empresa, servindo de
balizadores para a filtragem dos projetos.
( ) A avaliação dos projetos irá considerar os critérios adotados, a ponderação deles e
a escala de importância do projeto em relação a cada critério.

179
 Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – V.
d) ( ) F – F – V.

4 Para que um projeto possa sair do campo das ideias e passar a compor o portfólio de
projetos da Empresa, é necessário que técnicas de filtragem possam ser utilizadas,
como o método multicritério e o stage-gate. Disserte sobre a diferença entre os dois
métodos.

5 Para que um projeto obtenha o êxito esperado, é importante que tenha sido escolhido
no momento certo, composto o portfólio de projetos da Empresa e que atenda aos
fatores críticos de sucesso. Um projeto que tenha uma baixa avaliação, quando
analisado perante os FCS, tenderá a não obter o sucesso esperado, não se mostrando
uma boa alternativa para o portfólio empresarial. Nesse contexto, disserte sobre os
principais fatores críticos de sucesso, no que se refere ao processo.

180
 REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 23081-1: Infor-
mação e documentação – Processos de gestão de documentos de arquivo – Metada-
dos para documentos de arquivo Parte 1: Princípios. Rio de Janeiro: ABNT, 2019.

AGILE BUSINESS CONSORTIUM. The DSDM Agile Project Framework Handbook.

2014. Disponível em: https://fliphtml5.com/glqi/jhlm/basic. Acesso em: 14 dez. 2022.

ANDERSON, D. J. Kanban – Mudança Evolucionária de Sucesso para Seu Negócio de

Tecnologia. Sequim: Blue Hole Press, 2011.

BALLARD, G.; HOWELL, G. A. Leanproject management. Building research & infor-

mation, [s. l.], v. 31, n. 1, p. 1-15, 2003.

BECK, K. et al. Manifesto para desenvolvimento ágil de software. 2001. Disponível

em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 29 dez. 2022.

BLACK, K. Causes of project failure: a survey of professional engineers, Rede PM, [s. l.],
v. 10, n. 11, p. 21-24, 1996.

BOSSONG, G.; SPILT, P. Predictive budgeting: A new approach to budgeting. Journal of

Business Forecasting, [s. l.], v. 29, n. 1, p. 37-45, 2010.

CAMARGO, F. R. Modelo para análise e seleção de alternativas na etapa concei-

tual de projeto. 2007. Dissertação (Mestrado em Engenharia Mecânica e de Materiais)
– Universidade Tecnológica Federal do Paraná, Curitiba, 2007.

CAROLI, P. O que é Manifesto Ágil? Cultura ágil. Caroli.org, jun. 2020. Disponível em:
https://caroli.org/manifesto-agil/. Acesso em: 2 fev. 2023.

CHARVAT, J. Stage-gate system for new product development: best practices and
cases. Product Innovation Management, [s. l.], v. 27, n. 1, p. 1-10, 2010.

CHAVES, R.; FUNES, M. The benefits of predictive budgeting. Harvard Business Re-
view, [s. l.], v. 9, n. 3, p. 61-66, 2015.

COHN, M. Agile Estimating and Planning. Rio de Janeiro: Prentice Hall, 2005.

CONFORTO, E. C.; AMARAL, D. C. Evaluating an Agile Method for Planning and Con-
trolling Innovative Projects. Project Management Journal, [s. l.], v. 41, n. 2, p. 73-80,
2008.

181
 CONFORTO, E. C. Gerenciamento ágil de projetos: proposta e avaliação de método
para gestão de escopo e tempo. 2009, 304p. Dissertação (Mestrado em Engenharia
de Produção) – Escola de Engenharia de São Carlos, Universidade de São Paulo, São
Paulo, 2009.

COOPER, R. G. Winning at new products: accelerating the process from idea to

launch. 3rd ed. Basic Books, 2000.

COOPER, R. G. How companies are reinventing their idea-to-launch methodologies.

Research Technology Management, [s. l.], v. 52, n. 2, p. 47-57, 2009.

CRUZ, F. Scrum e PMBOK unidos no gerenciamento de Projetos. Rio de Janeiro:

Brasport, 2013.

DAKHEEL, J. A.; PERO, C. D.; NICCOLÒ, A. et al. Smart buildings features and key
performance indicators: a review. Sustainable Cities and Society, [s. l.], v. 61, 2020.

DEMING, W. E. Out of the crisis. Cambridge: MIT Center for Advanced Engineering
Study, 1986.

DUDZIAK, T. EXtreme Programming an Overview. Métodos e ferramentas de pro-

dução de software WS, 1999/2000. Disponível em: http://csis.pace.edu/~marchese/
CS616/Agile/XP/XP_Overview.pdf. Acesso em: 12 fev. 2023.

EVANS, J. R.; LINDSAY, W. M. The management and control of quality. São Paulo:
Cengage Learning, 2015.

FERREIRA JUNIOR, F. Indicador Chave de Desempenho: KPI – Metas, objetivos e

indicadores. [S. l.]: eBook Kindle, 2020.

FLEMING, Q. W.; KOPPELMAN, J. M. Earned value project management. 3. ed. New-

town Square: Project Management Institute, 2005.

FOWLER, M. Refactoring – Improving the Design of Existing Code. 2. ed. London:

Pearson Education, 2019.

FRANCISCHINI, A. S. N.; FRANCISCHINI, P. G. Indicadores de Desempenho: dos

objetivos à ação – métodos para elaborar KPIs e obter resultados. Rio de Janeiro: Alta
Books, 2017.

HACKMAN, R. J. Leading Teams: setting the stage for great performances. Boston:
Harvard Business School Press, 2002.

HEERKENS, G. Project management team development. J Ross Publishing, 2010.

182
HITT, M. A.; IRELAND, R. D.; HOSKISSON, R. E. Strategic Management: concepts and
cases: competitiveness and globalization. 12th ed. Cengage Learning, 2016.

HILL, C.; JONES, G. Corporate strategy: vertical integration, diversification and stra-
tegic alliances. In Strategic Management Theory. New York: Houghton Mifflin Company,
2001.

HUMBLE, J.; FARLEY, D. Entrega contínua – como entregar software de forma rápida
e confiável. Porto Alegre: Bookman, 2014.

IMONIANA, J. O. Auditoria de Sistemas de Informação. 3. ed. São Paulo: Atlas, 2016.

JAMES, g.; PAGNUSSAT, J. L. (org.) Planejamento e orçamento governamental. Co-

letânea. Brasília: ENAP, 2006.

JOGLEKAR, A. Change Management: a guide to effective implementation. New York:

Springer, 2017.

JOHNSON, G.; SCHOLES, K.; WHITTINGTON, R. Fundamentos de estratégia. Londres:

Pearson, 2017.

JURAN, J. M.; GRYNA, F. M. Quality Planning and Analysis. Nova York: Mc-
Graw-Hill,1993.

JURAN, J. M. Juran on quality by design: the new steps for planning quality into
goods and services. New York: Free Press, 1988.

KAPLAN, R. S.; COOPER, R. Custo e desempenho: administre seus custos para ser
mais competitivo. São Paulo: Futura, 1998.

KERZNER, H. Gerenciamento de Projetos: estudos de casos. São Paulo: Bookman,

2013a.

KERZNER, H. Project Management Metrics, KPIs, and Dashboards: a guide to

measuring and monitoring project performance. 2nd ed. Hoboken: Wiley, 2013b.

KERZNER, H. Project Management: A Systems Approach to Planning, Scheduling,

and Controlling. USA: John Wiley & Sons, 2017.

KNOB, F. F. RiskFree4PPM: uma proposta de processo para o gerenciamento de

portfólios de projetos distribuídos.185p. Dissertação (Mestrado em Ciência da Compu-
tação) – Pontifícia Universidade Católica do Rio Grande do Sul, Porto Alegre, 2007.

KONRAD, T.; PHILLIPS, J. Configuration management principles and practices.

London: Addison-Wesley Professional, 2018.

183
 KWOK, F. Predictive analytics for dummies. Nova Jersey: John Wiley & Sons. 2018.

LARSON, E. W.; GRAY, C. F. Gerenciamento de Projetos – O processo gerencial. 6. ed.

Porto Alegre: AMGH, 2016.

LEWIS, J. P. Como gerenciar projetos com eficácia. 6. ed. Rio de Janeiro: Campus,
2005.

MAIA, R. P. A importância de um escopo bem definido no gerenciamento do proje-

to. Faculdade Ietec, 2017. Disponível em: https://www.ietec.com.br/clipping/2018/
05-maio/A-importancia-de-um-escopo-bem-definido-no-gerenciamento-do-projeto.
pdf. Acesso em: 28 fev. 2023.

MAXIMIANO, A. C. A.; VERONEZE, F. Gestão de Projetos – Preditiva, ágil e estratégica.

6. ed. Barueri: Atlas, 2022.

MELO, J. L.; OLIVEIRA, A. V.; RIBEIRO, M. C. T. Gerenciamento Ágil De Projetos – Guia

de referência com as principais metodologias e frameworks ágeis do mercado. Rio de
Janeiro: SF Editorial, 2021.

NEWELL M. Preparing for the Project Management Professional (PMP). [S. l.]:
AMACOM, 2002.

OLIVEIRA, V. N. P. Requisitos de Ferramentas de Gerenciamento de Configuração. DCC

Week, UFMG, 2007. Disponível em: https://homepages.dcc.ufmg.br/~rodolfo/dcc823-
2-07/Entrega4/Viviane4.pdf. Acesso em: 12 fev. 2023.

PAPADAKIS, E.; TSIRONIS, L. K. Towards a Hybrid Project Management Framework: A

Systematic Literature Review on Traditional, Aigle and Hybrid Techniques. Journal of
Modern Project Management, [s. l.], v. 8, n. 2, p. 124-139, 2020.

PEREIRA, P.; TORREÃO, P.; MARCAL, A. S. Entendendo Scrum para gerenciar projetos
de forma ágil. mundo PM, [s. l.], v. 1, p. 3-11, 2007.

PRESSMAN, R. S. Engenharia de Software. 3. ed. São Paulo: Makron Books, 1995.

PRESSMAN, R. S. Software engineering: a practitioner's approach. 7th ed. Nova York:

McGraw Hill, 2005.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Nova York:

McGraw-Hill, 2010.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 8. ed. Porto

Alegre: AMGH, 2016.

184
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Nova York:
McGraw-Hill Education, 2017.

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissio-

nal. 9. ed. Porto Alegre: AMGH, 2021.

PMI. PROJECT MANAGEMENT INSTITUTE. Um Guia do conjunto de conhecimentos

em gerenciamento de projetos (Guia PMBOK ®). Newtown Square: Project Mana-
gement Institute, 2004.

PMI. PROJECT MANAGEMENT INSTITUTE. PMI Today: the growing gap between proj-
ect manager and supply and demand. Newtown Square: Project Management Insti-
tute, 2009.

PMI – PROJECT MANAGEMENT INSTITUTE. Um Guia do Conjunto de Conhecimen-

tos em Gerenciamento de Projetos. (Guia PMBOK®). 5. ed. Globalstandard, 2013.

PMI. PROJECT MANAGEMENT INSTITUTE. Navigating complexity: a practice guide.

Newtown Square: Project Management Institute, 2014.

PMI. PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerencia-

mento de Projetos (Guia PMBOK®). 6. ed. Newtown Square: Project Management
Institute, 2017.

PMI. PROJECT MANAGEMENT INSTITUTE. PMI 2018 Pulse of the Profes-

sion® Relatório Detalhado. 2018. Disponível em: https://www.pmi.org/about/pres-
s-media/press-releases/pmi-2018-pulse-of-the-profession-in-depth-report. Acesso
em: 27 fev. 2023.

PROVINCIATTO, M.; CAROLI, P. Sprint a Sprint: erros e acertos na transformação cul-

tural de um time ágil. São Paulo: Editora Caroli, 2020.

RABETTI, D.; RODRIGUES, I. Gestão adaptativa de projetos: um levantamento dos arte-

fatos mais utilizados para gerenciar o escopo do projeto. GeP Revista de gestão de
projetos, [s. l.], v. 12, n. 1, p. 95-122, 2021.

RADIGAN, D. Atlassian, 2023. Story points and estimation, 2023. Disponível em:
https://www.atlassian.com/agile/project-management/estimation#:~:text=Story%20
points%20are%20units%20of,work%2C%20and%20risk%20or%20uncertainty. Acesso
em: 12 fev. 2023.

ROSENAU, M. D. The PDMA handbook of new product development. New York:

John Wiley & Sons, 1996.

185
 ROYCE. W. W. Managing the development of large software systems: concepts and
techniques, Proc. IEEE Wescon, [s. l.], v. 26, n. 12, 1970.

SAATY, T. L. The analytic hierarchy process. New York: McGraw-Hill, 1980.

SABBAGH, R. Scrum – gestão ágil para projetos de sucesso. Casa do Código. São
Paulo: 2013.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide – The Definitive Guide to Scrum:
The Rules of the Game. 2017. Disponível em: https://www.scrumguides.org/docs/
scrumguide/v2017/2017-Scrum-Guide-US.pdf. Acesso em: 8 fev. 2023.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide – the definitive guide to scrum:
the rules of the game, 2020. Disponível em: https://scrumguides.org/docs/scrumgui-
de/v2020/2020-Scrum-Guide-US.pdf. Acesso em: 31 dez. 2022.

SCRUM ALLIANCE. Scrum: A breathtakingly brief and agile introduction, 2022.

SCRUM GUIDE. Scrum.org, 2021. O guia do Scrum. Disponível em: https://www.scrum.

org/scrum-guide. Acesso em: 12 fev. 2023.

SCRUMSTUDY. A Guide to the Scrum Body of Knowledge. Avondale: SCRUMstudy,

2017.

SHENHAR, A. J.; MILOSEVIC, D.; DVIR, D.; THAMHAIN, H. Linking project manage-
ment to business strategy. Newtown Square, PA: Project Management Institute
(PMI), 2007.

SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2009.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall,

2011.

SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo.

Porto Alegre: Bookman Editora, 2014.

SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2.

ed. São Paulo: Leya, 2016.

TELES, V. M. Um estudo de caso da adoção das práticas e valores do Extreme

Programming. 145 p. Dissertação (Mestrado em Informática) – Universidade Federal
do Rio de Janeiro, Rio de Janeiro, 2005.

VALLE, A. B. et al. Fundamentos do gerenciamento de projetos. 2. ed. Rio de Ja-

neiro: FGV, 2010.

186
WIDEMAN M. A Guide to the Project Management Body of Knowledge (The PM-
BOK® Guide). [S. l.]: Project Management Institute, 2021.

WYSOCKI, R. K.; BECK, J.; THOMAS, D. Effective Project Management: traditional,

agile, extreme. 7. ed. Nova Jersey: Editora Wiley, 2014.

XAVIER, C. M. et al. Metodologia de gerenciamento de projetos. Rio de Janeiro:

Brasport, 2005.

ZASA, A. P.; PELLIZZONI, E. Managing the Hybrid Organization: how can agile and tradi-
tional project management coexist? Research-Technology Management, January/
February 2021.

187
188
 UNIDADE 3 —

FERRAMENTAS E NORMAS DE
APOIO AO GERENCIAMENTO DE
PROJETOS E CONFIGURAÇÕES
OBJETIVOS DE APRENDIZAGEM
A partir do estudo desta unidade, você deverá ser capaz de:

• compreender a importância da utilização de ferramentas de apoio ao processo

de gerenciamento de projetos, tais quais as voltadas para controle de versão,
acompanhamento do ciclo de vida dos projetos e ferramentas voltadas para
metodologias ágeis;

• compreender as etapas do processo de integração e entrega contínua, além de

conhecer quais as principais ferramentas disponíveis para executar esta função;

• conhecer as ferramentas para gerenciamento de tarefas e sua importância no

processo de gerenciamento de configurações e mudanças em projetos;

• conhecer as principais normas de apoio ao gerenciamento de configuração e sua

aplicação ao longo das etapas de gerenciamento dos itens de configuração de um
projeto.

• compreender a visão dos modelos mps.br e cmmi sobre as normas de apoio

ao gerenciamento de configuração e a importância destes modelos para as
Organizações.

PLANO DE ESTUDOS
A cada tópico desta unidade você encontrará autoatividades com o objetivo de reforçar
o conteúdo apresentado.

TEMA DE APRENDIZAGEM 1 – FERRAMENTAS PARA APOIO AO GERENCIAMENTO DE

PROJETOS E CONFIGURAÇÃO
TEMA DE APRENDIZAGEM 2 – FERRAMENTAS PARA INTEGRAÇÃO E ENTREGA CONTÍNUA
TEMA DE APRENDIZAGEM 3 – NORMAS DE APOIO AO GERENCIAMENTO DE
CONFIGURAÇÕES

CHAMADA
Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure
um ambiente que facilite a concentração, assim absorverá melhor as informações.

189
 CONFIRA
A TRILHA DA
UNIDADE 3!

Acesse o
QR Code abaixo:

190
UNIDADE 3 TÓPICO 1 —
FERRAMENTAS PARA APOIO
AO GERENCIAMENTO DE
PROJETOS E CONFIGURAÇÃO

1 INTRODUÇÃO
Sommerville (2011) afirma que gerenciar projetos não é uma tarefa tão simples.
Requer que o Gerente de Projetos consiga planejar e mensurar o andamento das etapas
do projeto de forma a garantir que o sucesso esperado será atingido.

Durante a execução de um projeto, diversos riscos precisam estar sendo

acompanhados para que, caso aconteça algo não esperado para o projeto, soluções de
contorno possam ser tomadas a tempo, evitando prejuízos maiores.

Para auxiliar o Gerente de Projetos a executar o planejamento e acompanhamento

do projeto, dos recursos que estão sendo utilizados, dos riscos envolvidos e, não menos
importante, facilitar o processo de mensuração do progresso do projeto, ferramentas
auxiliares poderão ser utilizadas.

Acadêmico, no Tema de Aprendizagem 1, abordaremos as principais ferramentas

de apoio ao gerenciamento de projetos, tanto para metodologias preditivas quanto ágeis.
Iniciaremos com a apresentação das ferramentas voltadas para controle de versão, no
Subtema 2, seguindo da apresentação das ferramentas voltadas para acompanhamento
do ciclo de vida de um projeto, no Subtema 3, das ferramentas voltadas para projetos
que seguem as metodologias ágeis, no Subtema 4 e, por fim, da apresentação do método
Kanban e sua relação com o gerenciamento de projetos, no Subtema 5.

2 FERRAMENTAS PARA CONTROLE DE VERSÃO

Sommerville (2011) conceitua as ferramentas de controle de versão como as
que devem prover formas de identificar, armazenar e controlar o acesso às diferentes
versões de um mesmo componente.

As funcionalidades fornecidas pelos sistemas de controle de versão centralizados

e distribuídos são similares, apesar de suas implementações serem feitas de formas
diferentes, conforme apresentado por Sommerville (2018). As principais características
de ambos os sistemas podem ser descritas como:

191
 • Identificação de versão e lançamento – Cada nova versão gerenciada de um
componente receberá um identificador único quando for armazenada. A partir
destes identificadores é possível diferenciar as versões armazenadas de um mesmo
componente, sem a necessidade de alterar o nome do componente.
• Registro do histórico de mudanças – As mudanças efetuadas em um componente
são gerenciadas com o propósito de criar uma nova versão deste componente, tendo
como base sua versão anterior. É possível marcar cada versão com identificadores,
como palavras-chave, possibilitando sua inclusão em uma baseline.
• Desenvolvimento independente – É possível que diferentes desenvolvedores
atuem em diferentes versões de um mesmo componente, sem que haja interferência
nos trabalhos dos demais desenvolvedores, que atuam em paralelo. O sistema
de controle de versão deverá controlar as contribuições de cada desenvolvedor
separadamente.
• Apoio de projeto – Vários projetos que compartilham componentes entre si
poderão ter suas versões de componentes gerenciados por um mesmo sistema
gerenciador de versões.
• Gerenciamento de armazenamento – O sistema de gerenciamento de versões
deverá garantir que não haverá duplicidade de arquivos idênticos armazenados. Caso
pequenas alterações sejam feitas em um arquivo, o mecanismo de armazenamento
poderá, por exemplo, armazenar apenas as diferenças, ao invés de guardar cópias
separadas do arquivo alterado.

Um dos principais pontos na gerência de configurações, como afirmam Humble

e Farley (2014), é o versionamento dos itens necessários para que um novo ambiente
possa ser criado, em caso de necessidade, do zero até o pleno funcionamento da
aplicação alvo.

Pressman e Maxim (2021) afirmam que a utilização de ferramentas que

promovam o controle de versão é fundamental para que itens de configuração, tidos
como objetos que tenham relação com outros objetos em um projeto, possam ser
corretamente identificados e mantidos, tendo suas respectivas manutenções agrupadas
em diferentes versões.

Segundo Sommerville (2011), quando um projeto faz uso de ferramentas que

promovam o controle de versão, a necessidade de espaço de armazenamento físico
nas máquinas dos membros do time de desenvolvimento se reduz, tendo em vista que
o gerenciador de versões será instalado e executado em um servidor central, que irá
criar e gerenciar ramificações para cada nova versão criada pelos membros do time de
desenvolvimento.

Um ponto importante, apresentado por Sommerville (2018), é a abordagem inicial

utilizada para sistemas de gerenciamento de versões baseada em deltas. Nos primórdios
do desenvolvimento de sistemas para controle de versão, o espaço de armazenamento
em disco era caro, tornando o gerenciamento de armazenamento uma das funções mais
importantes dessas ferramentas. Com isso, armazenar apenas as alterações efetuadas

192
em formato de deltas, era uma abordagem interessante. Para que uma nova versão
da aplicação fosse criada, bastava aplicar todos os deltas armazenados, o que poderia
demorar bastante.

Com o barateamento do armazenamento em disco, novas abordagens podem

ser utilizadas, como a compactação das alterações efetuadas, em conjunto com suas
metainformações. Então, para recuperar um arquivo armazenado, não se faz mais
necessário aplicar os deltas armazenados com suas alterações, mas apenas realizar o
processo de descompactação desse arquivo.

Tendo em vista os benefícios apresentados anteriormente, algumas ferramentas

foram construídas com o propósito de realizar o processo de gerenciamento de versões
de forma segura, de modo que uma equipe com diferentes membros, que estivessem
desenvolvendo o mesmo produto, pudesse contribuir sem interferir negativamente
(sobrescrever ou apagar) as contribuições feitas pelos demais membros da equipe.

A primeira aplicação desenvolvida com o propósito de realizar controle de

versões foi a Source Code Control System (SCCS), criada em 1972 no laboratório Bell
Labs, conforme apresentado por Freitas (2010). A partir desse sistema, uma nova
aplicação surgiu, de nome Revision Control System (RCS), introduzindo o conceito
de armazenamento em deltas intercalados, do inglês interleaved deltas, se tornando
fundamental para implementar técnicas de junção entre diferentes ambientes de
trabalho dos membros do time.

Podemos apresentar algumas ferramentas que podem ser utilizadas para

realizar o controle de versão de código fonte de uma aplicação:

• Concurrent Version System (CVS) – Se trata de uma ferramenta criada no

sistema operacional Unix, possuindo versão paga ou gratuita, como explicado por
TechTarget (2011). Utiliza como base a ferramenta RCS para realizar o processo de
gerenciamento de versões, sendo responsável pelo controle de versão de pedaços
de código construídos por cada membro do time de desenvolvimento.
• GIT – Atlasian (2022) explica que se trata de um projeto de código aberto que se
tornou o mais utilizado para controle de versão de código fonte na década de 2020,
criado para ser um sistema de controle de versão distribuído, diferindo, assim, das
demais ferramentas, como a CVS ou SVN.
• Subversion (SVN) – É um projeto de código aberto, em consonância com Apache
(2022), sendo muito utilizado por programadores no início dos anos 2000, perdendo
popularidade após a criação da ferramenta GIT, em 2005. Ainda assim, possui uma
comunidade ativa para evoluções e fórum de dúvidas.

193
 IMPORTANTE
Pressman e Maxim (2021) e Humble e Farley (2014) salientam que todas as
configurações que forem armazenadas em um projeto precisam ser identificadas
de forma única e recuperadas, quando se fizer necessário, através da ferramenta
que será utilizada para realizar o controle de versão.

ESTUDOS FUTUROS
Abordaremos outras ferramentas para controle de versão ainda neste Tema
de Aprendizagem. Também detalharemos estas ferramentas apresentadas
nos próximos subtemas.

Quando uma equipe adota uma ferramenta de controle de versão para

gerenciar as configurações dos projetos em andamento, uma das principais vantagens
apresentadas por Sommerville (2011), além das já mencionadas, é a possibilidade de os
membros estarem em localizações geográficas distintas, já que todos poderão estar
contribuindo com o projeto de forma remota, bastando estar conectado à rede privada
da Empresa para a qual trabalha.

INTERESSANTE
Pressman e Maxim (2021) chamam atenção ao fato que não é somente o
código fonte de uma aplicação que deverá ter suas versões armazenadas e
gerenciadas, mas todas as configurações mapeadas como importantes para
garantir o bom funcionamento do ambiente operacional de uma aplicação,
tais quais configurações de hardware, aplicativos de terceiros que sejam
essenciais para o funcionamento da aplicação que está sendo desenvolvida,
documentação base para o desenvolvimento, dentre outros itens que sejam
julgados importantes pelo time.

Humble e Farley (2014) afirmam que é desejável armazenar, inclusive, imagens

de servidores e sistemas operacionais já configurados para uma determinada aplicação,
sendo a ferramenta de gerenciamento de versão importante para que o tempo gasto na
montagem de ambientes operacionais possa ser reduzido, com a menor interferência
possível de uma pessoa para sua recriação.

194
 Para se fazer uma escolha dentre as ferramentas disponíveis para controle de
versão, o time precisará averiguar a experiência dos membros com a utilização de uma
ferramenta em detrimento das outras, o propósito de uso da ferramenta na equipe e as
funcionalidades oferecidas por cada ferramenta.

O gerenciamento de versões se divide na definição de baselines e codelines,

conforme apresentado por Sommerville (2011) e Sommerville (2018). Enquanto uma
versão de codeline se concentra em criar diferentes versões apenas para o código fonte
da aplicação que está sendo gerenciada, uma baseline irá englobar uma codeline e
todos os demais componentes envolvidos no sistema, com suas respectivas bibliotecas,
arquivos de configuração e outros itens necessários para que seja montada uma versão
funcional da aplicação.

A importância do controle das versões de cada componente de um Software é

enfatizada em Sommerville (2018), já que, caso não exista um sistema de gerenciamento
de configuração para controlar os itens de configuração, é possível que haja inclusão de
versões equivocadas de componentes no sistema.

IMPORTANTE
Sommerville (2011) denomina mainline a sequência das versões principais de
uma aplicação, criadas a partir de baselines específicos. Cada baseline criada
para uma aplicação deverá ter sua nomenclatura seguindo a versão dos
componentes utilizados e da codeline.

O gerenciamento de itens de configuração, de acordo com Freitas (2010), se

divide em duas perspectivas distintas, que são a gerencial e a de desenvolvimento.
A perspectiva gerencial irá se preocupar em identificar o item que terá suas versões
armazenadas e gerenciadas, o propósito pelo qual cada item terá suas versões
armazenadas, a avaliação (auditoria) do que está sendo armazenado e das permissões
atribuídas para cada item, além da liberação e entrega do item gerenciado, quando for
solicitado. Já a perspectiva de desenvolvimento se dividirá em três diferentes sistemas,
tais quais:

• Sistema de controle de versão – Irá armazenar cada item mapeado como

configuração de forma única, gerenciando seu processo de evolução e garantindo o
controle de concorrência, mantendo o item íntegro.
• Sistema de controle de alterações – Irá mapear as alterações efetuadas em
cada item, mantendo todos os membros da equipe de desenvolvimento informados
sobre as alterações efetuadas em um determinado item de configuração.

195
 • Sistema de gerenciamento de construção – Converte em arquivos executáveis
os artefatos de Software que estão prontos para liberação para implantação em um
ambiente operacional, de forma automatizada.

As funcionalidades básicas para uma ferramenta de controle de versão são

descritas, concordando com Oliveira (2007), como:

• Ramificação (Branch) – A ferramenta deverá permitir a criação de novas

ramificações, que se tornarão versões paralelas dos itens de configuração
armazenados inicialmente no repositório e poderão receber intervenções dos
diferentes membros do time de desenvolvimento.
• Fusão (Merge) – A ferramenta deverá ser capaz de efetuar a fusão das alterações
efetuadas por todos os membros que atuaram em intervenções nos itens de
configuração, juntando todas as ramificações criadas na etapa de ramificação.
Eventuais conflitos podem acontecer, caso mais de um desenvolvedor tenha
efetuado alterações em um mesmo item de configuração, sendo necessária sua
resolução.
• Diferenciação – É necessário que a ferramenta execute uma comparação entre
os itens alterados por um desenvolvedor que criou previamente uma ramificação
e a versão mais recente dos itens alterados que estão armazenadas no repositório
central. Este processo permitirá que o responsável analise as mudanças efetuadas,
decidindo sobre a aprovação da alteração ou sua reprovação.
• Compressão – Esta funcionalidade é necessária para garantir otimização no
armazenamento em disco das versões dos itens de configuração.
• Operações de check in / check out – Estas operações são importantes para que
um membro do time de desenvolvimento inicie e finalize seu trabalho. Ao realizar um
check out em um item de configuração armazenado no repositório, uma cópia deste
item será executada e armazenada na máquina local do desenvolvedor, montando
seu ambiente de trabalho. A operação de check in irá enviar as alterações efetuadas
nos itens trabalhados ao repositório central novamente.
• Hierarquia – Os arquivos armazenados devem ser organizados em grupos que irão
apresentar corretamente as diferentes visões do projeto.
• Controle de liberação – A ferramenta deve prover uma forma de se criar marcos
de identificação no sistema, de modo a identificar cada nova versão criada pelo time.
• Marcação de versões – A ferramenta deverá ter uma forma de marcar quais as
versões que foram liberadas, facilitando o trabalho paralelo pelos membros do time
de desenvolvimento.
• Permitir armazenamento de tipos diferentes de arquivos – Diferentes
formatos de arquivos devem ser armazenados pela ferramenta, não se limitando
apenas aos arquivos com formatos textuais.
• Trilha de auditagem – Todas as intervenções efetuadas nos itens de configuração
armazenados devem ser armazenadas, sendo possível identificar quem executou
qual alteração e quando essa operação aconteceu.
• Controle de acesso – Apenas usuários autorizados a acessar o repositório devem

196
 conseguir efetuar o acesso, sendo de responsabilidade da ferramenta realizar
este controle. É importante que diferentes níveis de acesso e permissões existam
para que os diferentes tipos de itens de configuração possam ter seus acessos
concedidos corretamente.
• Relacionamento entre os itens – Deve ser possível associar objetos, criando um
relacionamento entre eles de modo que uma mudança em um item de configuração
que possua relacionamento com outros itens possa identificar os itens que serão
impactados por esta mudança. A interligação entre itens é muito presente na fase
de documentação e especificação de requisitos, quando permite realizar o rastreio
entre os requisitos dependentes.
• Item de Configuração (IC) – Representa um elemento de Software, hardware ou
documentação, sendo controlado e gerenciado pela Gerência de Configuração de
Software. Cada IC é único e pode ser identificado e rastreado;
• Baseline - Representa um conjunto de ICs que são revisados, aprovados e fixados
em um determinado momento. As baselines são usadas como referência para
futuras alterações e evolução do Software.
• Baseline Control – Representa o processo de gerenciar e controlar as baselines do
Software, incluindo sua criação, armazenamento, distribuição e atualização.
• Baseline Identification – Processo de identificar os ICs que fazem parte de uma
determinada baseline. É usado para garantir que as baselines sejam consistentes
e completas.
• Baseline Review – Processo de revisar uma baseline para garantir que ela atenda
aos requisitos definidos e que todas as alterações estejam documentadas.
• Baseline Update – Processo de atualizar uma baseline existente com novas
alterações ou correções de bugs. É usado para manter a consistência e integridade
das baselines.
• Release Baseline – Conceituada como uma baseline que foi testada e aprovada
para ser lançada para produção ou para entrega ao cliente.
• Delta – Representa a diferença entre duas versões de uma baseline, que pode ser
usada para rastrear as alterações e o histórico de desenvolvimento do Software.
• Codeline – Sequência de versões de Software que foram desenvolvidas a partir de
uma mesma base de código-fonte. É usada para gerenciar o desenvolvimento de
diferentes funcionalidades ou correções de bugs em paralelo.
• Release Candidate – Versão de Software que está pronta para ser lançada para
produção, após ter sido testada e aprovada. É usada para validar e testar a versão
final antes do lançamento oficial.
• Mainline – Linha principal de desenvolvimento de Software, na qual as alterações
são integradas e testadas. É usada para manter a consistência e a estabilidade do
Software em desenvolvimento, evitando conflitos e problemas de integração. A
mainline geralmente é controlada por um sistema de controle de versão e é a linha
de desenvolvimento que é usada para criar as versões de lançamento e as baselines
do Software. As alterações são feitas em branches (ramificações) separados da
mainline para permitir o desenvolvimento paralelo de funcionalidades ou correções
de bugs sem afetar a estabilidade do Software em desenvolvimento. Quando as

197
 alterações são concluídas, elas são mescladas (merged) de volta para a mainline
para serem integradas e testadas.
• Repositório de Configuração – Local onde os ICs são armazenados e gerenciados.
Pode ser um sistema de controle de versão ou um repositório físico.
• Auditoria de Configuração – Processo de revisar e avaliar a qualidade e
conformidade do Software com os padrões e requisitos definidos. É usado para
garantir que o Software seja confiável e seguro.
• Rastreabilidade – Capacidade de rastrear a relação entre diferentes ICs e baselines,
permitindo rastrear as mudanças no Software e entender como as diferentes partes
do Software estão relacionadas.
• Matriz de Rastreabilidade (do inglês Traceability Matrix) – Tabela que mostra
a relação entre requisitos, ICs e testes, sendo usada para rastrear a conformidade
do Software com os requisitos definidos e para garantir que todas as suas partes
estejam sendo testadas;
• Integração Contínua (do inglês Continuous Integration – CI) – Processo de
integrar automaticamente as alterações do código-fonte em uma linha principal
de desenvolvimento, para garantir que o Software esteja sempre atualizado e sem
conflitos.
• Entrega Contínua (do inglês Continuous Delivery – CD) – Processo de
automatizar a entrega de Software em ambientes de teste e produção, para acelerar
o processo de entrega e garantir a qualidade do Software.
• Quadro de Controle de Configuração (do inglês Configuration Control Board
– CCB) – Grupo de pessoas responsável por avaliar, aprovar e gerenciar mudanças
na configuração do Software.

Segundo Chacon e Straub (2022) e Freitas (2010), os sistemas gerenciadores de

versão se dividem em três categorias:

Sistemas de controle de versão locais – Primeira forma de execução do

versionamento de itens de configuração, acontece quando um desenvolvedor cria
cópias locais, de forma manual, dos itens que se deseja armazenar o histórico de
versões. Apesar de fácil e comum, este esquema é altamente susceptível a falhas, já que
arquivos podem ser acidentalmente sobrescritos ou armazenados em pastas indevidas.
Sistemas centralizados de controle de versão – Neste sistema, existe
um servidor central que armazenará todos os itens de configuração que deverão ser
gerenciados, permitindo que clientes façam check out dos itens armazenados. Apesar
de se manter em evidência durante anos, principalmente por se mostrar mais vantajoso
que utilizar o sistema de controle local, apresenta sérias desvantagens, como um único
ponto de falha. Exemplo de ferramentas que implementam este modelo são a CVS,
Subversion e Perforce.
Sistemas distribuídos de controle de versão – Ao contrário dos sistemas
centralizados, os sistemas distribuídos para controle de versão executam um
espelhamento do repositório completo para a máquina do cliente, incluindo todo seu
histórico. Dessa forma, caso qualquer servidor tenha qualquer intercorrência, qualquer

198
cliente que tenha efetuado o clone desse repositório poderá servir de backup para a
aplicação (ou outros itens de configuração que estavam armazenados no repositório
central). Exemplo de ferramentas que utilizam esse formato de trabalho são a Git,
Mercurial, Bazaar e Darcs.

IMPORTANTE
Um ponto de atenção levantado por Chacon e Straub (2022) é o fato que
o modelo centralizado poderá representar um único ponto de falhas no
projeto, tendo em vista que, caso uma falha aconteça, poderá deixar os
itens gerenciados indisponíveis por um período. O modelo distribuído não
apresenta esse risco, por realizar clones do repositório para cada máquina
dos membros do time, que poderá servir de backup, em caso de problemas
com o repositório remoto.

Figura 1 – Modelo local para controle de versão

Fonte: adaptada de Chacon e Straub (2022)

A Figura 1 demonstra como o controle de versão feito na máquina local de cada

cliente funciona. Nesse esquema, o arquivo é obtido de um servidor inicial, ficando cada
cliente responsável por criar suas próprias versões e gerenciá-las, em sua máquina local.
Eventuais problemas de sobrescrita de arquivos podem acontecer, como mencionado
anteriormente.

O modelo de controle de versão centralizado é apresentado na Figura 2.

199
 Figura 2 – Esquema de funcionamento de um servidor de controle de versão centralizado.

Fonte: adaptada de Chacon e Straub (2022)

No modelo de controle de versão centralizado, apresentado na Figura 2, os

desenvolvedores fazem uma cópia do código mantido pelo servidor central, enviando
a este servidor apenas os arquivos que sofreram alteração, o qual, por sua vez, irá criar
deltas representando as alterações recebidas, mantendo os demais arquivos intactos
em suas versões originais.

A Figura 3 ilustra o modelo de controle de versão distribuído.

Figura 3 – Representação do controle de versão distribuído.

Fonte: adaptada de Chacon e Straub (2022)

A Figura 3 apresenta a forma de trabalho das ferramentas que implementam

o modelo de gerenciamento de versões distribuído. Cada desenvolvedor irá efetuar a
clonagem de todo o ambiente gerenciado pelo servidor, realizar suas contribuições
e, ao final do trabalho, sincronizar o código armazenado no servidor central com

200
suas alterações, o que irá criar uma nova versão completa contendo as alterações
codificadas. As sincronizações também acontecem com as versões armazenadas por
outros desenvolvedores.

Nas próximas subseções abordaremos as principais ferramentas utilizadas para

a execução de controle de versão, tanto de código aberto quanto soluções proprietárias.

2.1 CONCURRENT VERSION SYSTEM (CVS)

Pressman e Maxim (2021) apresentam a ferramenta Concurrent Version System
(CVS) como um sistema de controle de versão voltado, em sua especificação inicial,
para gerenciar apenas código fonte de aplicações, estendendo sua aplicação para o
armazenamento de qualquer arquivo do tipo texto.

Segundo explicam Humble e Farley (2014) e Freitas (2010), uma das principais
inovações apresentadas pelo CVS era o processamento concorrente dos arquivos por ele
gerenciados, o que implicava que um arquivo, ao ser manipulado por um desenvolvedor,
não seria bloqueado, tendo todas as alterações concorrentes mescladas quando este
arquivo fosse enviado ao servidor central.

Uma equipe que trabalha utilizando a ferramenta CVS como gerenciadora

de versões poderá criar diferentes versões de uma mesma aplicação, gerenciando
alterações em cada versão de forma separada, sem interferir em outras eventuais versões
anteriormente criadas, como apresentado em Techtarget (2011). Essa característica é a
responsável pelo termo concorrente na definição da sigla CVS, já que a ferramenta irá
armazenar uma versão principal de cada arquivo, gerenciando todas as alterações que
neles forem feitas ao longo de seu ciclo de vida.

Apesar de ter sido um sistema de gerenciamento de versões bastante popular

na época que foi lançado, a CVS ainda possuía diversos pontos de falha, que eram
considerados fatores críticos de sucesso para a ferramenta, o que fez com que uma
nova ferramenta pudesse ser implementada para corrigir estas falhas, culminando no
desenvolvimento da ferramenta Subversion (SVN) para sua substituição (GNU, 2023).

Apesar de ter apresentado inúmeras vantagens no momento de sua

disponibilização para uso público, a ferramenta CVS possuía algumas limitações, como
mencionado por Gnu (2023), sendo elas:

• Não é uma ferramenta que irá substituir o processo de gerenciamento, sendo este
de responsabilidade do Gerente de Projetos ou papel que desempenhe a função de
liderança na equipe.
• Não é uma ferramenta que irá substituir a comunicação entre os membros da equipe
de desenvolvimento.

201
 • A ferramenta não possui controle de modificações, não guardando referência sobre
a modificação de diversos arquivos que foram alterados e enviados ao repositório
em um mesmo momento.
• Não é um programa voltado para testes automatizados.
• Não é uma ferramenta baseada em um modelo de processos, de modo que, caso
uma alteração em um arquivo necessite da avaliação de diferentes pessoas da
equipe, esse processo não será possível.

Apesar da ferramenta CVS ter entrado em desuso após o lançamento de outras

ferramentas mais eficientes para o controle de versão, como a sua sucessora Subversion,
ainda existem equipes de desenvolvimento que fazem uso dessa ferramenta.

Chacon e Straub (2022) afirmam que a ferramenta Git é considerada como a

mais utilizada pelas equipes de desenvolvimento, atualmente. Descreveremos essa
ferramenta com mais detalhes no próximo subtema.

NOTA
Acadêmico, a ferramenta CVS poderá ser encontrada para download em
https://sourceforge.net/projects/ccvs/. Acesso em: 23 jan. 2023.

2.2 GIT
A ferramenta Git, como explanada por Chacon e Straub (2022), foi desenvolvida
por Linus Torvald, criador do Sistema Operacional Linux, em meados de 2005, com o
intuito de facilitar o processo de manutenção do kernel do Linux, após a ferramenta
utilizada pela comunidade Linux, de código aberto e livre de taxas, ter o status “livre de
taxas” suspenso devido ao rompimento da relação entre a empresa que desenvolvia
a ferramenta utilizada e a comunidade dos desenvolvedores que mantinham o kernel
do Linux. Dessa forma, a equipe de desenvolvimento do kernel Linux se viu forçada a
desenvolver sua própria ferramenta de controle de versão.

Buscou-se, então, desenvolver uma ferramenta que pudesse ser rápida, de

simples utilização, que conseguisse trabalhar com diversos ambientes de trabalho
paralelos, que fosse totalmente distribuída e comportasse grandes projetos.

A grande vantagem da ferramenta Git em relação a outras ferramentas, como

a CVS, era sua característica distribuída, o que iria alterar a forma como a Git iria lidar
com os arquivos gerenciados por ela. Enquanto outros sistemas de controle de versão

202
criam e mantém uma lista com as alterações que foram efetuadas em cada arquivo
gerenciado, a ferramenta Git armazena o histórico de alterações de um arquivo como
instantâneos deste arquivo ao longo do tempo (VALENTE, 2020).

ATENÇÃO
Enquanto as ferramentas centralizadas armazenam apenas as alterações, em
formato de deltas, a ferramenta Git armazena versões completas dos arquivos
gerenciados a cada nova atualização do repositório remoto. Sendo assim, um
arquivo terá seu histórico armazenado como uma sequência de instantâneos
em cada ramificação criada.

A Figura 4 apresenta como ferramentas que implementam o modelo

centralizado de versionamento de código lidam com os arquivos por elas gerenciados e
suas respectivas alterações ao longo do tempo.

Figura 4 – Visão das ferramentas de controle de versão centralizado sobre as versões dos arquivos geren-
ciados

Fonte: adaptada de Chacon e Straub (2022)

A Figura 4 apresenta como as ferramentas centralizadas enxergam e lidam

com os arquivos por elas gerenciados e suas respectivas alterações ao longo do tempo.
Para todos os arquivos que serão mantidos no repositório de controle de versão, uma
versão inicial é gerada. Qualquer alteração que aconteça nos arquivos inicialmente
armazenados será vista como uma mudança feita no arquivo inicial (denominada versão
delta X do arquivo).
203
 Figura 5 – Como a ferramenta Git enxerga os arquivos

Fonte: adaptada de Chacon e Straub (2022)

A Figura 5 apresenta a forma como a ferramenta Git mantém as diferentes

versões de um mesmo arquivo. Ao invés de armazenar apenas as alterações efetuadas
nos arquivos do projeto como deltas, como apresentado na Figura 4, a Git irá guardar
uma cópia completa de todos os arquivos alterados em cada nova versão gerada no
repositório.

NOTA
Acadêmico, a documentação do Git, assim como as versões da ferramenta
disponíveis para download poderão ser encontradas em: https://git-scm.com/.

INTERESSANTE
Caso um arquivo não tenha sido atualizado ao longo do tempo, a Git não irá
armazenar novas cópias de instantâneos deste arquivo, apenas referenciando
o instantâneo original.

204
 Os membros da equipe de desenvolvimento que utilizam a ferramenta Git como
solução para controle de versão irão fazer todo o trabalho de alterações nos arquivos do
projeto localmente, se encarregando de sincronizar seu repositório local ao repositório
remoto, ajustando eventuais conflitos que surjam devido à mesclagem de alterações em
um mesmo trecho de código por desenvolvedores distintos. Caso um mesmo arquivo
tenha sido modificado, mas em partes diferentes, as alterações serão mescladas de
forma automática pela ferramenta.

Seguindo as explicações de Vuorre e Curley (2018), ao alterar um arquivo

gerenciado utilizando a Git, o estado deste arquivo passará a ser modificado, mesmo
que ainda não tenha sido enviado ao repositório remoto. É possível, então, que o
desenvolvedor inclua este arquivo em uma área intermediária, denominada stage, que
irá salvar o estado atual do arquivo para ser enviado ao repositório remoto. Ao realizar
a operação de commit, o desenvolvedor irá armazenar, em seu repositório local, os
arquivos alterados por ele de forma segura e íntegra, podendo enviar esta versão
armazenada ao repositório remoto, sincronizando-o.

INTERESSANTE
A integridade, na ferramenta Git, é garantida em cada operação de commit
através da geração de um checksum. Esse hash irá identificar um commit
específico, podendo recuperar todas as alterações feitas em todos os arquivos
modificados nesta versão.

É possível criar um servidor central, denominado GitHub, que funcionará on-

line de modo integrado aos servidores Git locais das máquinas de cada desenvolvedor,
recebendo contribuições de todos os membros do time de desenvolvimento, como
apresentado em Valente (2020). Além dessa característica, uma outra vantagem
apontada é a existência de ferramentas visuais que podem facilitar a execução do fluxo
de buscar – alterar – enviar ao repositório, conforme apresentado na Figura 6.

205
 Figura 6 – Fluxo de trabalho básico utilizando um servidor GitHub centralizado

Fonte: adaptada de Vuorre e Curley (2018)

A Figura 6 apresenta um fluxo de comandos que devem ser seguidos pelos

desenvolvedores de um time. O primeiro passo deve ser a clonagem do repositório
remoto, criando o repositório de trabalho local. Após o término das codificações
necessárias, o desenvolvedor deverá adicionar os arquivos alterados à área intermediária
(ou stage), realizando um commit em sequência (o que criará uma versão local das
alterações). Caso algum outro desenvolvedor tenha feito alterações e as enviado ao
GitHub, o desenvolvedor que pretende enviar suas alterações deverá sincronizar seu
repositório local com um pull do servidor remoto, e, caso nenhum conflito aconteça,
suas alterações serão enviadas ao servidor central através do comando push.

IMPORTANTE
É importante que os membros do time de desenvolvimento adotem como
boas práticas o envio periódico dos códigos construídos ao final de cada dia
de trabalho, evitando retrabalhos em caso de falhas em alguma estação de
trabalho dos membros do time.

Além da ferramenta Git, existe uma outra também bastante utilizada, que será
abordada no subtópico 2.3, a Mercurial.

2.3 MERCURIAL
Segundo Freitas (2010), a ferramenta Mercurial, assim como a Git, funciona de
forma distribuída, tendo sua história se iniciado de forma paralela ao desenvolvimento
da ferramenta Git. Assim como a Git, a Mercurial teve sua primeira versão disponibilizada

206
no ano de 2005. Apesar de as duas ferramentas terem sido desenvolvidas por membros
do time mantenedor do kernel do Linux, a ferramenta Git acabou sendo a escolhida para
gerenciar as versões do código fonte do kernel Linux.

Uma vantagem da ferramenta Mercurial, concordando com Medeiros (2016), é

a baixa curva de aprendizado (facilidade de aprendizagem) e facilidade no processo de
instalação e configuração, sendo capaz de poder ser utilizado com sucesso em qualquer
porte de projetos, seja grande ou pequeno. Além disso, esta ferramenta pode ser
integrada com outras ferramentas voltadas para controle de versão, como a Subversion.

Apesar de não ter sido escolhida para o controle de versão do kernel Linux, a
ferramenta Mercurial acabou se popularizando após ser adotada por inúmeras equipes
de grandes projetos, como defendido por Freitas (2010).

Essa ferramenta possui um ciclo de trabalho bem similar ao ciclo da Git, como
a criação de um repositório local na máquina de cada desenvolvedor, a marcação dos
arquivos alterados e a operação de commit para salvar localmente os arquivos alterados,
seguindo-se da ação de propagação da alteração ao repositório remoto.

IMPORTANTE
A ferramenta Mercurial poderá ser obtida através do link https://www.
mercurial-scm.org/wiki/Download. Acesso em: 23 jan. 2023.

Freitas (2010) explica que, através da ferramenta Mercurial, é possível identificar

o autor de uma alteração, quando um arquivo foi alterado e analisar a linha do tempo de
um determinado arquivo, identificando as partes modificadas e quando cada modificação
aconteceu. Estas características também podem ser obtidas através da utilização de
outras ferramentas, como a Git e a Subversion.

Medeiros (2016) e Freitas (2010) concordam acerca de uma diferença entre a

funcionalidade de mesclagem implementada na ferramenta Mercurial em comparação
com a mesma ação realizada pela ferramenta Git. Quando um arquivo é renomeado
através da ferramenta Mercurial, tendo seu merge (ou mesclagem) feito com a versão
com nomenclatura anterior, a ferramenta irá identificar que se trata do mesmo arquivo
e irá realizar a mesclagem de forma correta. Contudo, caso algum conflito aconteça
durante a realização de uma mesclagem, a Mercurial não irá dispor de uma forma fácil
para sua resolução, necessitando de um esforço extra do desenvolvedor para que o
problema seja resolvido.

207
 INTERESSANTE
Medeiros (2016) e Freitas (2010) explicam que um conflito acontece quando
dois ou mais desenvolvedores alteraram o mesmo trecho de código em um
mesmo arquivo. Dessa forma, se torna necessário que seja decidido qual dos
trechos de código irá permanecer, qual será removido ou se existirá uma
mesclagem entre os códigos conflitantes, de forma manual.

2.4 BITKEEPER
A ferramenta BitKeeper, inicialmente com licença de utilização gratuita,
fornece um gerenciamento de código de maneira distribuída, voltada para o time de
desenvolvimento do kernel do Sistemas Operacional Linux, conforme Henson e Garzik
(2002). A característica distribuída da equipe responsável por manter o kernel do Linux,
muitas vezes com limitações na velocidade de conexão à Internet e tendo que gerenciar
múltiplos arquivos grandes, necessitava de um sistema de controle de versão que desse
suporte ao trabalho distribuído, não existindo uma, no ano de 2002, que pudesse suprir
essa necessidade.

Henson e Garzik (2022) explicam que, com a limitação das ferramentas

existentes, o time de desenvolvimento e manutenção do kernel Linux planejou e
desenvolveu uma ferramenta que pudesse suprir as suas necessidades, culminando no
desenvolvimento da ferramenta BitKeeper, que implementa os principais conceitos de
ferramentas similares, voltadas para o gerenciamento distribuído, como a Git.

O desuso da ferramenta BitKeeper, seguindo a explicação de Freitas (2010),

foi causado pela decisão de converter a ferramenta em proprietária, acarretando o
desenvolvimento de outra ferramenta que pudesse suprir a lacuna deixada pela BitKeeper
para o time de desenvolvimento do kernel Linux. A partir daí, os desenvolvedores
mantenedores do kernel Linux optaram pela implementação de uma nova ferramenta,
a Git, já que nenhuma das existentes naquele momento supriam as necessidades do
time.

Segundo BitKeeper (2023), porém, a ferramenta voltou a ser de licença livre

e código aberto em tempos recentes, sendo a ideal para algumas situações que a
ferramenta Git pode não apresentar a melhor solução, tais quais:

• projetos muito grandes;

• projetos que necessitem de boa performance e escalabilidade;
• segurança e integridade;
• times que querem medir a capacidade de execução de seus desenvolvedores;
• empresas que possuam múltiplos produtos e querem manter o gerenciamento de
todos eles;

208
• times com grande volume de arquivos binários (vídeos, fotos, arquivos CAD, dentre
outros).

A ferramenta BitKeeper, conforme explicado por Bonilla (2015), se caracteriza

como uma implementação híbrida entre o modelo centralizado e o distribuído, se
beneficiando da melhor parte dos dois modelos. A explicação para este modelo de
arquitetura se dá devido ao conceito de repositório encadeado implementado pela
ferramenta, consistindo em uma coleção de repositórios ligados por uma linha do tempo
única. Dessa forma, é possível fornecer a atomicidade necessária para a realização
dos commits pelos desenvolvedores, porém mantendo a flexibilidade de tratar cada
componente como um repositório individual.

A ferramenta BitKeeper, conforme mencionam Henson e Garzik (2002) e Bonilla

(2015), foi a primeira a introduzir o conceito de changesets, ou seja, de armazenar e
gerenciar as alterações efetuadas em cada arquivo do projeto de forma agrupada em
um conjunto de alterações, atribuindo um número de revisão aos arquivos alterados, da
mesma forma que todo o repositório também estará associado a uma revisão.

Bonilla (2015) afirma que o conceito de produto para a ferramenta BitKeeper

é traduzido como o repositório central, no qual irá se interligar todos os demais
repositórios dos desenvolvedores do time, que serão denominados componentes.
O relacionamento entre o produto e seus diversos componentes se assemelha ao
relacionamento entre o repositório e seus arquivos gerenciados. Ainda assim, alguns
conceitos são importantes serem apresentados, devido à natureza encadeada de um
produto mantido pelo BitKeeper, sendo eles:

• Produto – Representa a aplicação principal que será mantida pelo repositório.

• Componente – Representa cada repositório individual atrelado (associado) ao
produto, sendo que cada componente poderá estar relacionado com apenas um
único produto, não sendo possível se relacionar com outros componentes.
• Alias – Representando um nome simbólico, associado ao produto, e que faz
referência ao seu conjunto de componentes, tendo suas versões controladas,
permitindo, assim, que a coleção de componentes possa variar ao longo do tempo
sem que o histórico seja perdido.
• Gate – Representa um produto considerado seguro, ou seja, que está armazenado
em um servidor com backup realizado, de modo que alterações efetuadas em um
gate não possam ser desfeitas.
• Portal – Representando um produto completo, com todos seus componentes
populados.
• Operation – Operações efetuadas em componentes, que são armazenados em
arquivos do tipo manifest no repositório. Mesmo que um componente não tenha
sofrido alterações em um determinado momento, seu nome estará presente no
arquivo manifest.

209
 • Aliases – Representa uma forma de associar nomes lógicos, como resultado da
geração de uma nova versão, à um conjunto de componentes do produto.

No próximo subtema, abordaremos a ferramenta SourceSafe, também voltada

para o controle de versão de arquivos em um projeto.

2.5 SOURCESAFE
A ferramenta SourceSafe, proprietária, foi desenvolvida pela Microsoft,
possuindo integração com outras ferramentas também desenvolvidas pela mesma
Empresa, como a Visual Studio .NET, como explicam os autores Corrêa, Grein e Piske
(2005). Essa ferramenta disponibiliza três funcionalidades básicas, comuns a outras
ferramentas de controle de versão, que são o armazenamento de arquivos em um
repositório central, o controle de acesso e histórico das modificações.

Ainda segundo Corrêa, Grein e Piske (2005), a ferramenta SourceSafe implementa

o modelo centralizado, se diferenciando de outras ferramentas já apresentadas,
como a CVS, pela utilização de algoritmos de criptografia para os arquivos que serão
armazenados, descaracterizando-os durante esse processo de retenção.

A ferramenta SourceSafe não se mostra adequada para acesso remoto dos

membros do time de desenvolvimento, prejudicando a produtividade do time por
conta de sua extrema lentidão, como explicado por Dynamsoft (2007). Da mesma
forma, apresenta algumas questões importantes relacionadas a falhas de segurança,
instabilidade e falta de suporte a múltiplas plataformas (já que possui versão apenas
para o Sistema Operacional Windows), o que inviabiliza sua utilização por muitas equipes
que trabalham remotamente ou que utilizam Sistemas Operacionais baseados em Unix
(como o Linux).

No próximo subtema, apresentaremos a ferramenta ClearCase.

2.6 CLEARCASE
Segundo Wahli et al. (2004), a ferramenta ClearCase, de propriedade da IBM, faz
parte de um conjunto de soluções voltadas para o gerenciamento de configurações de
Software, de nome IBM Rational Team Unifying Platform. Um cliente que desejar adotar
esta solução, poderá iniciar com uma versão simples da ferramenta para gerenciamento
de configurações, evoluindo para outras ferramentas com mais funcionalidades sem que,
com isso, tenha gastos significativos com custos e esforço de migração e aprendizado.

210
 A ferramenta de entrada para o pacote é a ClearCase LT, como apresentado por
Wahli, Brown et al. (2004), que funciona como um repositório centralizado, sendo capaz
de gerenciar o histórico de qualquer elemento do projeto, ao longo de seu ciclo de vida.

Ross (2011) afirma que é possível migrar projetos que estão tendo seus artefatos
gerenciados por outras ferramentas de controle de versão, como a SourceSafe e a CVS,
para a ferramenta ClearCase, através da utilização de ferramentas específicas para este
fim.

A ferramenta ClearCase LT, concordando com Rational (2000), suporta apenas

pequenos times, apesar de oferecer as mesmas funcionalidades da ferramenta
ClearCase que, além de gerenciar versões das configurações de uma aplicação, é
capaz de executar builds tanto de programas individuais quanto de versões (release)
completas de uma aplicação, dependendo das configurações do usuário.

INTERESSANTE
Como explicam Oliveira, Vianna e Tanaka (2006), a ferramenta ClearCase
permite a criação de repositórios públicos ou privados. Os públicos podem
ser acessados por qualquer desenvolvedor que faça parte da comunidade
de desenvolvedores que utilizam a ClearCase, porém repositórios privados só
são acessíveis para seus criadores.

A ferramenta ClearCase poderá simplificar o processo de controle de mudanças

em um time com muitos membros, dando suporte ao controle de requisitos, modelos,
código fonte, documentação e scripts de teste, de acordo com Wahli et al. (2004). A
ferramenta também provê suporte ao desenvolvimento paralelo, gerenciamento de
workspace, configuração de projetos e gerenciamento de build, além de fornecer uma
interface WEB para acesso de dados e facilitar o processo de auditoria dos processos
de build da aplicação.

NOTA
A ferramenta ClearCase poderá ser obtida através do link: https://www.ibm.
com/support/pages/rational-ClearCase-902.

O próximo subtópico apresentará a ferramenta IBM Synergy, que implementa o

modelo centralizado para versionamento de arquivos.

211
 2.7 SYNERGY
Conforme explica Sampaio (2021), a ferramenta proprietária Synergy,
desenvolvida pela IBM, segue o modelo centralizado de implementação, sendo integrado
a uma outra solução IBM, a Rational Change, para permitir o controle de mudanças.

A ferramenta fornece algumas vantagens na utilização por times globalizados,

sendo elas apresentadas por IBM (2023) como:

• aumento de produtividade do time, através da utilização de redes de alta velocidade,

sem a necessidade de sincronizar múltiplos servidores;
• realiza a sincronização das alterações em artefatos em tempo real, o que facilita o
trabalho de times distribuídos;
• as manutenções no servidor central podem ser planejadas de acordo com o melhor
horário para o time, reduzindo o tempo de indisponibilidade do servidor.

Ainda segundo IBM (2023), a ferramenta Synergy permite o acompanhamento

de múltiplos projetos e versões de forma centralizada, além de fornecer um conjunto de
comandos em linguagem própria, permitindo que a comunicação entre os membros dos
times aconteça de forma consistente. Uma outra vantagem é a possibilidade de reuso
de componentes, já que cada componente terá seu identificador único atribuído para
cada versão criada e mantida, sendo possível reutilizar uma versão específica desse
componente na codificação de outro componente ou aplicação. Dessa forma, se reduz
as duplicidades de código.

IMPORTANTE
O suporte para as ferramentas Rational Synergy e Rational Change será
descontinuado em setembro de 2024, como explica IBM (2022).

Abordaremos a ferramenta StarTeam no próximo subtema.

2.8 STARTEAM
A ferramenta proprietária StarTeam tem o propósito de implementar o processo
de gerenciamento de alterações e versões para todo o ciclo de vida da entrega (MICRO
FOCUS, 2023b).

212
 Como explica Micro Focus (2023b), essa ferramenta provê um repositório único
centralizado para armazenar os artefatos dos projetos de uma Organização, além de
garantir a rastreabilidade dos artefatos armazenados e permitir a utilização por equipes
descentralizadas. O processo de fusão das contribuições de todos os membros da
equipe na versão principal da aplicação é feito de forma automatizada, identificando
exatamente quais as alterações efetuadas e quem as fez.

Em versões mais recentes da ferramenta, conforme apresentado por Micro

Focus (2019), funcionalidades de revisão de código (code review) e integração com a
ferramenta Git foram incorporadas, além da integração com ferramentas que auxiliam
equipes ágeis, como a Jira, provendo um gerenciamento unificado para ativos ágeis e
não ágeis.

IMPORTANTE
Acadêmico, apresentaremos a ferramenta Jira no próximo subtema.

Além das ferramentas de controle de versão, importantes para gerenciar os itens

de configuração de um projeto, é necessário que o Gerente de Projetos, Líder técnico
ou outro papel de gestão em uma equipe de projetos possa acompanhar as fases de
execução do projeto, garantindo que o andamento de cada etapa está conforme o
esperado, atingindo os marcos definidos ao longo da execução, a fim de obter o êxito
esperado ao final. Sendo assim, no próximo subtema abordaremos as ferramentas
voltadas para controle do ciclo de vida de um projeto.

3 FERRAMENTAS PARA CONTROLE DO CICLO DE VIDA DE

PROJETOS
Pressman e Maxim (2021) afirmam que a utilização de ferramentas de
gerenciamento de processos é importante para auxiliar os times a compreender os
elementos – chave do processo, assim como as ações que devem ser executadas ao
longo do ciclo de vida do projeto, podendo ser integradas a outras ferramentas de apoio,
quando necessário.

Um projeto é um empreendimento de período definido, o que indica que terá

um início e um fim. Além disso, deverá possuir um objetivo específico, que marcará a
finalização do ciclo do projeto e o êxito deste, seguindo os conceitos apresentados por
Maximiano e Veroneze (2022).

213
 O ciclo de vida do projeto, concordando com os conceitos apresentados por
CMMI (2006), é definido como o conjunto de todos os processos necessários para que
se estabeleça um ciclo do início ao final, de forma coerente com o objetivo que se deseja
alcançar. Esta atividade deve ser definida ainda na fase inicial do estabelecimento de
estimativas para o projeto que será executado.

Já Sommerville (2011) define o ciclo de vida de um projeto como o planejamento

das etapas deste novo projeto, se caracterizando por três fases básicas:

• A elaboração de uma proposta ou contrato que será apresentado ao cliente (parte

interessada), contendo uma visão sobre quais recursos serão necessários e o preço
que será cobrado para desenvolvimento do projeto.
• O planejamento inicial do projeto, contendo informações sobre o perfil de
desenvolvedores necessário para montar o time de desenvolvimento, quais artefatos
serão gerados e como ocorrerá a alocação dos recursos necessários. Nesta etapa
deverá ocorrer um refinamento sobre as estimativas calculadas anteriormente.
• Ajustes periódicos do planejamento inicialmente feito, após ter adquirido mais
conhecimento a respeito do negócio e mais experiência sobre o projeto, ao
acompanhar sua evolução. As estimativas se tornam mais precisas e os requisitos,
caso sejam ajustados, impactarão no aumento do orçamento e prazo estimados.

Todo o processo de planejamento das etapas que serão necessárias para

conclusão do projeto, assim como o planejamento dos detalhes de cada fase (como
a quantidade e os tipos de recursos necessários, a especificação de marcos que irão
determinar se o andamento do projeto está seguindo o rumo esperado, o orçamento
máximo para o projeto, assim como o prazo de início e finalização), poderão ser
realizados através da utilização de ferramentas, que terão o intuito de auxiliar e facilitar
o acompanhamento da execução do planejado.

As ferramentas que poderão ser utilizadas para auxiliar o gerenciamento de

um projeto irão depender do tipo de metodologia adotada para cada projeto. Dessa
forma, projetos que fazem uso das metodologias tradicionais (ou preditivas) poderão se
adequar melhor a determinadas ferramentas, enquanto projetos executados com base
em metodologias ágeis poderão utilizar uma combinação de ferramentas diferentes.

Segundo Santos (2021), para projetos que fazem uso de metodologias preditivas,
o cronograma do projeto poderá fazer uso de ferramentas proprietárias, como a Microsoft
Project, ou de ferramentas gratuitas, como o ProjectLibre ou ProofHub.

214
 IMPORTANTE
As ferramentas de auxílio ao gerenciamento de projetos poderão ser
combinadas para amparar, ainda mais, o Gerente de Projetos no preparo
e acompanhamento das fases do projeto. Dessa forma, é possível utilizar
uma ferramenta para executar o planejamento dos recursos, orçamento,
cronograma etc. e outra ferramenta para realizar o cadastramento e
acompanhamento das tarefas que deverão ser executadas pelo time de
desenvolvimento.

Através da utilização das ferramentas mencionadas anteriormente, para auxílio

na gestão de projetos com metodologias preditivas, é possível que o Gerente de Projetos
cadastre os recursos necessários (tanto humanos quanto tecnológicos ou demais
suprimentos), faça estimativa de orçamento e cronograma, além do cadastramento
dos marcos para avaliação do andamento do projeto. A partir dos dados informados
na aplicação, será possível acompanhar o progresso do projeto, aplicando soluções de
contorno, caso se perceba que algum atraso poderá acontecer (ou que o consumo de
recursos está acima do planejado para um determinado período).

IMPORTANTE
Acadêmico, a Microsoft, Empresa proprietária da solução MS Project,
disponibiliza orientações sobre como realizar o download e instalação da
aplicação através deste link: https://support.microsoft.com/pt-br/office/
instalar-o-project-7059249b-d9fe-4d61-ab96-5c5bf435f28.

O ProjectLibre, por sua vez, poderá ser encontrado no link https://projectlibre.

softonic.com.br/.

A ferramenta ProofHub é proprietária, mas conta com uma versão de testes

por quatorze dias, acesse em: https://www.proofhub.com/.

Segundo Pressman e Maxim (2021), a técnica de análise do valor agregado

(Earned Value Analysis), é voltada para a análise quantitativa do progresso de um
projeto, de modo que o tempo total para a execução e conclusão do projeto, assim como
o tempo necessário para a execução de cada tarefa, são estimados e associados a um
valor agregado, que representará a porcentagem de conclusão do projeto. Dessa forma,
é possível fazer uma leitura precisa do desempenho do projeto.

215
 A definição de metas e o acompanhamento do cumprimento desses objetivos
irão auxiliar no cálculo do conceito de valor realizado também conhecido pela sigla
Earned Value Management (EVM), em consonância com Maximiano e Veroneze (2022).
Esse conceito irá calcular o valor do trabalho que já foi realizado até um determinado
marco, indicando se o orçamento realizado até um certo ponto do projeto está dentro
do orçamento previsto para o projeto.

Com este indicador, é possível perceber se o orçamento irá extrapolar o valor

previsto, o que poderá causar uma interrupção abrupta do projeto, ou se está conforme
o esperado para o ponto no qual o projeto se encontra.

Ainda segundo Maximiano e Veroneze (2022), existem quatro situações

possíveis que um projeto poderá ser enquadrado, segundo o seu custo real e o custo
estimado:

• Atrasado e econômico – O projeto está progredindo a uma taxa menor que a

estimada, porém com execução efetiva maior que o estimado para cada $1,00 gasto.
• Dentro do prazo e do custo – O projeto está progredindo a uma taxa conforme
a estimada para o período avaliado, com execução também correspondendo ao
estimado para o período.
• Atrasado e com altos gastos – O projeto está progredindo a uma taxa menor que
a estimada e com execução menor que a estimada para cada $1,00 gasto.
• Rápido e com altos gastos – O projeto está progredindo a uma taxa conforme a
estimada, mas com execução menor que a estimada para cada $1,00 gasto.

INTERESSANTE
Pressman e Maxim (2021) afirmam que o valor do índice de desempenho
de custo, sendo representado pelo cálculo da razão entre o custo orçado
do trabalho programado (custo planejado) e o custo real do trabalho
executado deve ser próximo a 1, indicando, assim, que o projeto está com
custo real em concordância com o planejado. Esta análise irá possibilitar
identificar eventuais atrasos ou dificuldades no cronograma inicialmente
planejado, permitindo que ajustes sejam feitos.

Para o índice de variação do cronograma (do inglês Schedule Variance Index –

SPI), vale a mesma regra de ser maior ou menor que 1. Seu cálculo se dará pela razão entre
o valor entregue (do inglês Earned Value – EV) e o valor planejado (do inglês Planned
Value – PV), de modo que, para projetos que estejam dentro do prazo ou adiantados
(rápidos), o resultado deverá ser maior que 1, porém, para projetos atrasados, deverá ser
menor que 1.

216
 Como um resumo dos conceitos abordados neste tópico, temos que um projeto
é conceitualizado como as tarefas necessárias para se atingir a um objetivo inicial
pretendido, sendo possível gerenciar suas fases através de ferramentas que controlem
as etapas de seu ciclo de vida. Também mencionamos que um projeto poderá ser
classificado conforme seu orçamento inicialmente previsto e o efetivamente executado,
sendo a técnica de análise do valor agregado importante para o acompanhamento da
execução do projeto e dos gastos envolvidos.

Além de ferramentas para controlar o ciclo de vida do projeto, o time envolvido

em um projeto pode utilizar ferramentas para controle das tarefas corretivas, adaptativas
ou evolutivas em uma aplicação. Abordaremos as principais ferramentas para controle
de tarefas no próximo subtema.

3.1 FERRAMENTAS PARA CONTROLE DE TAREFAS

Neste subtema, abordaremos as principais ferramentas do mercado para o
controle de tarefas ao longo do ciclo de vida de um projeto.

Longuinho (2014) afirma que, em projetos realizados por pequenas empresas,

nem sempre os Gerentes de projeto são pessoas capacitadas para esta função, não
utilizando as melhores ferramentas para se obter o êxito dos projetos realizados, o que
pode culminar no fracasso de muitos projetos.

O processo de medição, como mencionado por Pressman e Maxim (2021),

quando feito de forma correta pelo Gerente de Projetos, irá auxiliar na tomada de
decisões importantes para o sucesso do projeto. Ferramentas de gerenciamento de
projetos, como as que serão apresentadas neste subtema, permitem o cálculo de
métricas importantes, como a capacidade de produção do time, a quantidade de
problemas reportados, dentre outros números importantes sobre o projeto.

3.1.1 Redmine

Segundo Heckler (2009), a ferramenta Redmine, de código aberto e extensível,
permite o controle dos artefatos gerados por um projeto, sendo possível efetuar o
rastreio desses artefatos, ou seja, o acompanhamento de todo processo de codificação,
testes e do histórico dos acontecimentos em cada tarefa. Além disso, é possível realizar
a interligação entre diferentes tarefas, o que permite que diferentes requisitos do projeto
sejam correlacionados.

Uma das vantagens da ferramenta Redmine em comparação a outras ferramentas

com o mesmo propósito, conforme apresentado por Moura e Nascimento (2009), é a
possibilidade desta ser integrada a outras ferramentas de apoio ao gerenciamento de

217
 projetos, como o suporte à integração a ferramentas de controle de versão (como a SVN,
Git, CVS, Mercurial, Bazaar e Darcs), possibilidade de criação de fórum e documentação
do projeto (através da ferramenta wiki), assim como a existência de uma equipe ativa no
processo de melhoria contínua da ferramenta.

Heckler (2009) enfatiza que a baixa curva de aprendizado da Redmine é um

ponto determinante para sua utilização por pessoas não habilitadas tecnicamente
para o papel de Gerente de projetos. Dessa forma, a ferramenta se mostra bastante
útil a qualquer tipo de projeto, de qualquer porte, não se limitando apenas a projetos de
construção de aplicações.

Quando há a integração entre a ferramenta Redmine e ferramentas de controle

de versão, como a Git, é possível associar commits realizados pelos membros do time
em tarefas específicas, possibilitando o rastreamento do trecho de código modificado
com as respectivas tarefas que provocaram as alterações no código, como enfatizado
por Longuinho (2014).

ATENÇÃO
Por experiência profissional da autora, a rastreabilidade das alterações em
código a partir das tarefas criadas e gerenciadas na ferramenta Redmine se
torna essencial para que sejam identificadas todas as tarefas englobadas na
geração de uma baseline da aplicação, facilitando o processo de comparação
com outras baselines do projeto ou o processo de aprovação para inclusão
na mainline que será implantada em produção.

Por ser uma ferramenta WEB, a Redmine se mostra adequada para times
geograficamente distribuídos, podendo ser acessada de qualquer local, desde que o
colaborador esteja conectado à rede da Empresa, através de uma VPN.

Segundo Santos e Hoffman (2016), a ferramenta Redmine permite a criação de

diferentes perfis de usuário, com diferentes níveis de acesso, possibilitando a associação
dos usuários aos projetos nos quais estão envolvidos. Para cada projeto, é necessário
indicar qual o papel de cada usuário associado, assim como seu nível de administração,
participação e visualização para cada atividade.

Os autores Santos e Hoffman (2016) e Moura e Nascimento (2009) concordam

sobre a definição de cronogramas para cada tarefa cadastrada na ferramenta,
possibilitando a visão global das tarefas ao longo do tempo, tanto para o Gerente de
projetos quanto demais membros do time.

218
 INTERESSANTE
A partir da experiência profissional da autora, para times ágeis, a ferramenta
Redmine, quando possui integração com plugins específicos, possibilita a
visualização das tarefas do projeto em um quadro kanban. Dessa forma, é
possível saber qual o progresso de cada tarefa e qual membro do time está
responsável por qual tarefa. A ferramenta também possibilita o agrupamento
de diferentes tarefas em pacotes (entregas), possibilitando a visualização de
informações sobre o progresso de implementação de cada pacote.

A Figura 7 apresenta um exemplo de visualização do calendário de tarefas

apresentado pela ferramenta Redmine.

Figura 7 – Calendário das atividades de um projeto gerenciado com a ferramenta Redmine

Fonte: adaptada de Santos e Hoffman (2016)

A partir da Figura 7, é possível visualizar todas as tarefas de um projeto em uma

semana de trabalho. As tarefas podem ser filtradas por situação ou outros filtros, como
o desenvolvedor responsável, períod etc. Além disso, é possível extrair alguns gráficos
criados pela ferramenta, com base nas informações de andamento das tarefas do time,
como a data de início e fim de cada tarefa, como apresentado pela Figura 8.

219
 Figura 8 – Algumas funcionalidades gráficas disponíveis na ferramenta Redmine

Fonte: adaptada de Heckler (2009)

Conforme apresentado na Figura 8, a velocidade do time pode ser calculada,

conforme as tarefas vão sendo cadastradas e concluídas, apresentando a média da
capacidade de execução do time ao longo do tempo. Um exemplo de como esse gráfico
é gerado e apresentado pela ferramenta se dá através da Figura 9.

Figura 9 – Gráfico de velocidade do time gerado pela ferramenta Redmine

Fonte: adaptada de Moura e Nascimento (2009)

A partir da Figura 9, é possível verificar a quantidade de tarefas criadas ao longo

do tempo, com a velocidade de resolução mensal do time, traçando-se uma métrica que
poderá ser acompanhada pelo Gerente de projetos para medição da produtividade da

220
equipe e dando-lhe subsídios para tomada de decisões estratégicas, como contratação
de novo membro para o time, identificação de gargalos no processo de desenvolvimento,
dentre outros fatores que podem impactar na produtividade da equipe.

NOTA
A ferramenta Redmine poderá ser obtida a partir do link https://www.
Redmine.org.

Além da ferramenta Redmine apresentada, outra ferramenta voltada para apoio

ao gerenciamento de projetos é a Bugzilla, que iremos apresentar no próximo subtema.

3.1.2 Bugzilla
Segundo Bugzilla (2023), a ferramenta de código aberto se mostra madura e
robusta para rastreamento de erros em aplicações. Algumas características importantes
desta ferramenta incluem a possibilidade de utilização por ambientes de alto volume
e complexidade, suporte realizado por um time dedicado, aprovado por líderes de
projeto experientes, suportado por diferentes sistemas operacionais, além de fornecer
funcionalidades disponibilizadas por ferramentas pagas.

Em comparação com a ferramenta Redmine, a Bugzilla também se mostra de

código aberto e voltada para WEB, além de contar com uma equipe que mantém sua
constante evolução. O propósito de criação da ferramenta Bugzilla, de acordo com
Quemello, Manduca e Fortes (2005), foi dar apoio ao projeto Mozilla, tendo sua utilização
estendida por diversas outras grandes Empresas, como a NASA, Motorola, Redhat,
dentre outras.

Ainda segundo Quemello, Manduca e Fortes (2005), as funcionalidades da

ferramenta Bugzilla são:

• cadastro e rastreamento de bugs;

• possibilidade de criação de contas e perfis de usuário;
• permite anexar arquivos às tarefas abertas;
• criação de inter-relacionamento entre bugs;
• extração de relatórios e gráficos apresentando dados estatísticos sobre os bugs
cadastrados.

221
 A ferramenta Bugzilla é voltada para o rastreio dos erros encontrados em
um sistema, sendo voltado para projetos mais simples, sendo de grande valia para
os membros do time de desenvolvimento, mas não executando tarefas inerentes
ao gerenciamento de projetos, como possibilitado pela ferramenta Redmine, como
defendido por Geraldes (2011).

NOTA
A ferramenta Bugzilla poderá ser encontrada no site https://www.Bugzilla.
org/.

No próximo subtema, apresentaremos a ferramenta TRAC, também de código

aberto e voltada para o apoio ao gerenciamento de mudanças em projetos.

3.1.3 Trac
Segundo Devmedia (2012), a ferramenta Trac, de código aberto, é voltada para
apoio ao gerenciamento de configuração e mudanças em um projeto, auxiliando em
processos como auditoria, metodologias de desenvolvimento e colaborando para que a
integridade do produto seja preservada. De interface simples e voltada para WEB, possui
fácil integração com ferramentas de controle de versão, como a SVN, Git ou outra voltada
para este fim, além de facilitar o processo de documentação através da ferramenta Wiki.

A partir da ferramenta Trac é possível rastrear todas as operações de commit

feitas pelos membros do time de desenvolvimento, como explica Primo (2014). Além
disso, é possível cadastrar comentários nas tarefas ou patches contendo trechos de
código voltados para corrigir um bug específico da aplicação, gerando uma discussão
entre os membros do time de desenvolvimento. É possível que uma tarefa seja aprovada
ou rejeitada por um desenvolvedor, após a análise da discussão em torno dela e dos
arquivos anexados.

A ferramenta Trac não dá suporte a multiprojetos, sendo destinada ao controle

de apenas um projeto por equipe, o que limita sua utilização por times que estão
envolvidos em múltiplos projetos (MOURA; NASCIMENTO, 2009).

A falta de suporte a múltiplos projetos se torna um limitador importante de

utilização dessa ferramenta frente à Git, por exemplo, tendo em vista que em Empresas
de desenvolvimento de Software é comum que equipes estejam envolvidas em mais de
um projeto simultaneamente.

222
 NOTA
A ferramenta Trac pode ser encontrada através do link: https://trac.edgewall.
org/.

Além de ferramentas específicas para times de desenvolvimento controlarem

o ciclo de vida de tarefas relacionadas a projetos (como mudanças e bugs), temos a
ferramenta Zendesk, voltada para controle de chamados relacionados a produtos ou
serviços, abertos através do setor de atendimento ao cliente, em Empresas de diferentes
portes. Abordaremos esta ferramenta no próximo subtema.

3.1.4 Zendesk
Segundo Zendesk (2023), ao contrário das demais ferramentas apresentadas
até o momento, esta é voltada para otimizar o processo de atendimento ao cliente em
empresas de diferentes portes, tendo a característica de ser uma ferramenta capaz
de criar e gerenciar demandas abertas pelos clientes nos mais diversos canais de
comunicação com uma Organização.

A ferramenta Zendesk não possui tanta flexibilidade no cadastramento de

solicitações customizadas (com campos específicos para o negócio da Organização),
porém permite a inserção de anotações a qualquer momento do andamento da solicitação,
além de dar suporte a múltiplos usuários, além de possibilitar o armazenamento do
histórico das solicitações cadastradas, como apresentado por Bacim (2016).

Uma diferença marcante entre a ferramenta Zendesk e ferramentas como a

Redmine, Trac e Bugzilla é sua característica de Software proprietário, sendo necessário
obter uma licença de uso para sua instalação e configuração em uma Empresa. Apesar
disso, uma variedade de pacotes de funcionalidades está disponível, com preços
variando conforme o pacote selecionado.

DICA
Para saber mais detalhes sobre a ferramenta Zendesk, acesse em: https://
www.youtube.com/watch?v=ly3j9eqz6cc.
https://www.youtube.com/watch?v=MhiG33XrRdo.

223
 NOTA
Mais informações sobre a ferramenta Zendesk podem ser obtidas, incluindo
os valores dos pacotes e suas respectivas funcionalidades, em seu site oficial:
https://www.Zendesk.com.br/.

No próximo subtema, abordaremos a ferramenta Serena TeamTrack, voltada

para uso genérico, em qualquer tipo de processo de negócio.

3.1.5 TeamTrack
Segundo Serena (2006), a ferramenta proprietária Serena TeamTrack se
caracteriza por ser uma plataforma WEB, voltada para o gerenciamento de tarefas e
processos de modo seguro e altamente configurável. Um processo de acompanhamento
de tarefas é criado ao longo de todo o ciclo de vida da aplicação.

Ainda conforme explica Serena (2006), a ferramenta possibilita o controle e

automação de qualquer tipo de processo de negócio, facilitando a interação entre as
partes interessadas. É possível, com o uso da ferramenta, obter as seguintes vantagens:

• elaboração de processos repetitivos e auditáveis;

• otimizar o fluxo de informação e colaboração entre os membros dos times;
• implantar processos consistentes de gerenciamento em setores da empresa,
garantindo um trabalho eficaz e eficiente;
• avaliar a eficiência de processos, buscando sua melhoria contínua;
• obter métricas de qualidade e informações relevantes para que os projetos tenham
a visibilidade adequada;
• garante que as melhores práticas e adequação às normas serão implementadas;
• rápido processo de deploy, tendo em vista que a ferramenta não requer nenhuma
instalação de aplicações clientes, se caracterizando como uma plataforma
independente.

A ferramenta TeamTrack permite que fluxos de processos customizados sejam

configurados por clientes, conforme suas necessidades, de acordo com Biggs (2004).
Com a criação de papéis diferentes, que possuem permissões diferentes na aplicação,
é possível garantir que cada membro do time terá acesso apenas às informações exatas
e necessárias para os seus interesses.

Biggs (2004) e Serena (2006) explicam que a arquitetura da aplicação se divide

em duas partes: o lado servidor, no qual estará o banco de dados responsável pelo
armazenamento das informações gerenciadas pela plataforma; e o lado cliente, que
poderá ser acessado a partir de qualquer navegador WEB.
224
 Apesar de ter sido uma ferramenta inovadora para a época do seu
desenvolvimento (início dos anos 2000), a ferramenta TeamTrack foi substituída
pela ferramenta Solutions Business Manager após a Empresa Serena, responsável
pela solução TeamTrack, ter sido adquirida pela Empresa Micro Focus em 2016, como
explicado por Micro Focus (2023a).

NOTA
A ferramenta Serena Team Track não se encontra mais disponível para
download em seu site oficial, tendo sido descontinuada.

No próximo subtema, abordaremos as ferramentas apropriadas para o

gerenciamento de projetos que fazem uso das metodologias ágeis. Apesar de as
ferramentas apresentadas no atual subtema estarem mais voltadas para projetos
executados a partir de metodologias preditivas, já que será necessário conhecer todas
as nuances de cada etapa do planejamento para cadastrar na ferramenta que será
utilizada, é possível que projetos ágeis também façam uso dessas mesmas aplicações,
conforme explicaremos mais adiante, ainda neste tema de aprendizagem.

4 FERRAMENTAS PARA PROJETOS BASEADOS EM

METODOLOGIAS ÁGEIS
Uma das características mais importantes de projetos ágeis é a possibilidade
de ajustes e alteração no escopo, mesmo após o início do projeto, além da possibilidade
de equipes serem autogerenciáveis, o que indica que cada membro do time de
desenvolvimento será responsável por analisar as tarefas que estão prontas para
atuação e se responsabilizar pela execução de uma tarefa.

Segundo Schwaber e Sutherland (2017), para que as equipes possam saber quais
as tarefas que estão sendo priorizadas e prontas para serem executadas, é necessário
que todas as atividades que precisam de algum tipo de atuação sejam expostas de
forma clara a todos os membros do time de desenvolvimento. Uma ferramenta útil para
esta função é o quadro kanban.

Anderson (2011) afirma que o objetivo do quadro kanban é apresentar as tarefas

em baias, que irão seguir o fluxo de trabalho da equipe, sendo estas tarefas posicionadas
conforme seu nível de prioridade para o projeto. Esta prioridade deverá ser acordada
com o cliente (ou partes interessadas), de modo que as tarefas posicionadas mais acima

225
 nas baias serão as consideradas mais prioritárias, enquanto as mais embaixo serão as
menos prioritárias. Os membros do time de desenvolvimento deverão buscar resolver as
tarefas mais prioritárias, sempre que estiverem disponíveis para atuar em nova tarefa.

Existem diversas ferramentas gratuitas que podem ser utilizadas por times
de desenvolvimento e que implementam o quadro kanban, como apresentado por
Santos (2021). Dentre elas temos a Trello e a Jira, que serão apresentadas nos próximos
subtemas. Com a utilização dessas ferramentas, todas as partes interessadas no projeto
poderão ter uma visão global do andamento do projeto, tendo em vista que será possível
saber a tarefa que cada membro está atuando em um determinado momento.

INTERESSANTE
É possível combinar a utilização de ferramentas voltadas para o
planejamento preditivo com ferramentas focadas em times ágeis, como
o quadro kanban. Dessa forma, os Gerentes de Projeto poderão ter o
benefício da previsibilidade, oferecida pelo método preditivo, com a dinâmica
da visualização do andamento do projeto em tempo real, oferecida pelas
ferramentas ágeis.

Em equipes ágeis, concordando com o apresentado por Beck et al. (2001), o

escopo do projeto poderá ser alterado, conforme a necessidade do cliente, em qualquer
etapa do projeto. Conforme explicado no Manifesto Ágil, um projeto que segue as
metodologias ágeis precisa estar pronto para responder às mudanças, que pode
significar uma alteração na priorização da implementação de funcionalidades, ajustes
nas regras de negócio já especificadas para um requisito individual ou exclusão de
tarefas previamente definidas para o projeto.

Segundo Pressman e Maxim (2021), eventuais alterações no escopo de um

projeto ou nos requisitos previamente definidos poderão surgir a partir da dinâmica
do negócio do cliente, já que uma necessidade tida como essencial em um momento
poderá já não fazer mais sentido em breve. Essa é a principal diferença entre projetos
que são construídos com base em metodologias preditivas ou ágeis: enquanto com
a primeira o foco e necessidade do cliente poderá mudar ao longo da execução do
projeto, sem que o cliente possa interferir ou ter contato com o produto que está sendo
desenvolvido, com a segunda o cliente está em contato constante e faz parte de todo
processo de forma ativa, moldando o produto às suas reais necessidades e provendo
constantes feedbacks.

Quando se trata de construir um Mínimo Produto Viável (MVP), a equipe poderá

utilizar a ferramenta de estacionamento de ideias, conforme descrito em Caroli
(2018). Com isso, ao invés de definir todos os requisitos em um único momento, antes
da inicialização do projeto, será possível anotar todas as necessidades do cliente

226
em um espaço visual (um quadro físico ou virtual), priorizando apenas o mínimo de
funcionalidades necessárias para que o produto possa ter uma versão inicial construída,
com o menor esforço, para que possa ser lançada em produção e disponibilizada para
usuários reais. As ideias que não foram contempladas em uma primeira versão, serão
executadas conforme o orçamento e recursos disponíveis.

Caroli (2018) apresenta uma outra forma de se definir quais as funcionalidades

que devem ser priorizadas para uma primeira versão de uma aplicação, através da
análise do “É – Não é” para as funcionalidades do produto. Para isso, os membros do
time de desenvolvimento precisam estar reunidos em um ambiente físico ou virtual com
ferramentas visuais (quadros ou post-it) para que se defina o que o produto deve ser
(ou quais funcionalidades deve prover em um primeiro momento) e o que ele não deve
fornecer (o que ele não é e não faz).

Abordaremos com maiores detalhes a ferramenta Trello no próximo subtema.

4.1 TRELLO
A ferramenta Trello, com foco em dar suporte ao processo de gestão de projetos
e tarefas, permite que equipes organizem e acompanhem suas atividades em um
quadro virtual, sendo este uma implementação do quadro kanban. Cada quadro da
Trello é composto por listas, que representam as diferentes etapas de um processo, e
cartões, que representam as tarefas que precisam ser executadas. Os cartões podem
ser movidos entre as listas conforme o progresso do trabalho, e é possível adicionar
informações como prazos, membros responsáveis, comentários e anexos (TRELLO,
2023).

A Trello, segundo explica Arun (2023), é uma ferramenta bastante flexível e

personalizável, permitindo que as equipes criem fluxos de trabalho que atendam as
suas necessidades específicas. Além disso, a ferramenta se mostra de fácil utilização,
possibilitando seu uso tanto através de navegadores WEB quanto em aplicativos para
dispositivos móveis.

Trello (2023) e Arun (2023) concordam que esta ferramenta é amplamente

utilizada por equipes de diferentes áreas, como marketing, desenvolvimento de
Software, recursos humanos e gerenciamento de projetos. Além disso, é especialmente
útil para equipes remotas ou distribuídas, que precisam de uma forma eficiente de
colaborar e manter-se atualizadas sobre o progresso do trabalho.

227
 NOTA
Acessea ferramenta Trello em: https://Trello.com/en.

A Figura 10 apresenta um exemplo de quadro criado a partir da ferramenta Trello

para gerenciamento de projetos e acompanhamento de tarefas.

Figura 10 – Exemplo de quadro criado a partir da ferramenta Trello para gerenciamento e acompanhamento
de tarefas

Fonte: Adaptada de Trello (2023)

A Figura 10 ilustra a divisão de tarefas em raias, que representarão os estados

pelos quais uma tarefa irá passar, do início de sua execução até sua finalização. À
medida que um desenvolvedor atua em uma atividade, ele irá atualizar o quadro, dando
visibilidade em tempo real aos demais membros do time de desenvolvimento.

Segundo Atlassian (2023), outra ferramenta bastante utilizada por equipes ágeis
é a Jira, que também apresenta as tarefas a serem atuadas pelo time de forma fácil,
através da implementação do quadro kanban, tendo as funcionalidades de ferramentas
voltadas para o gerenciamento de projetos com metodologias preditivas, como o
controle de linha de tempo das atividades, cronograma geral do projeto e orçamento,
além das cerimônias apresentadas pelo framework SCRUM.

Apresentaremos a ferramenta Jira no próximo subtema.

4.2 JIRA
Atlassian (2023) explica que a Jira é uma ferramenta de gerenciamento de
projetos e problemas, possibilitando que as equipes criem projetos, planos de trabalho,
tarefas, atribuam responsáveis e acompanhem o progresso em tempo real. Além disso,

228
a Jira é uma ferramenta altamente personalizável, permitindo que as equipes criem
fluxos de trabalho customizados para se adequarem às necessidades específicas de
seus projetos.

Ainda de acordo com Atlassian (2023), a ferramenta Jira, assim como acontece
com a ferramenta Trello, é comumente utilizada por equipes de desenvolvimento de
Software, porém não se limitando apenas a esta área, mas também sendo aplicável às
áreas de recursos humanos, marketing, suporte ao cliente e gerenciamento de projetos.
Se mostra especialmente útil para equipes geograficamente distribuídas e remotas, pois
permite a atribuição de tarefas, comentários e notificações aos membros do time.

Uma das principais vantagens do Jira, conforme apresentado por Hristovski

(2017), é a sua integração com outras ferramentas da Atlassian, como o Confluence (para
gerenciamento de conhecimento) e o Bitbucket (para gerenciamento de código fonte).
Além disso, o Jira possui uma grande variedade de plugins e extensões disponíveis
na sua loja de aplicativos, que permitem que as equipes adicionem funcionalidades
específicas à ferramenta.

Embora as ferramentas Trello e Jira sejam voltadas para o gerenciamento de

projetos e tarefas populares, cada uma tem suas próprias vantagens e desvantagens.
Algumas das vantagens da ferramenta Jira em relação à Trello incluem (ATLASSIAN,
2023):

• Personalização avançada – A Jira permite que as equipes personalizem fluxos de

trabalho complexos e adicionem campos personalizados, o que é útil para equipes
com necessidades específicas de gerenciamento de projetos.
• Gerenciamento de problemas – A Jira foi originalmente projetada para gerenciar
problemas de Software, o que a torna uma opção poderosa para equipes de
desenvolvimento de Software ou de tecnologia.
• Controle de acesso – A Jira oferece um controle de acesso mais granular,
permitindo que as equipes restrinjam o acesso a projetos, tarefas ou campos
específicos com base em funções ou permissões.
• Relatórios personalizados – A Jira oferece relatórios avançados e personalizados,
permitindo que as equipes gerem métricas precisas para avaliar o progresso do
projeto.
• Integrações com outras ferramentas – A Jira se integra com outras ferramentas
da Atlassian, como a Confluence (para gerenciamento de conhecimento) e a
Bitbucket (para gerenciamento de código fonte).

No entanto, Atlassian (2023) chama atenção para uma curva de aprendizagem

mais acentuada para a ferramenta Jira em comparação com a Trello, o que pode ser
um fator de complexidade importante para algumas equipes. Portanto, a escolha entre
a Jira e a Trello dependerá das necessidades específicas da equipe e de cada projeto.

229
 NOTA
A aplicação Jira poderá ser acessada em: https://confluence.atlassian.com/
jsbr/instalar-aplicacoes-jira-no-windows-920354877.html.

A Figura 11 apresenta um exemplo de criação de projeto que irá utilizar a

ferramenta Jira.

Figura 11 – Exemplo de criação de projeto que irá utilizar a ferramenta Jira

Fonte: adaptada de Atlassian (2023)

Ao criar um projeto na ferramenta Jira, como ilustrado na Figura 11, é possível

escolher entre a utilização de um quadro kanban ou a criação de um fluxo de processo
customizado, conforme os interesses da equipe e as necessidades do projeto que será
gerenciado.

Além de ferramentas para auxílio no processo de gerenciamento de projetos e

acompanhamento de tarefas, existem também ferramentas para criação de contêineres,
como a Docker, que será apresentada no próximo subtema.

230
4.3 DOCKER
Docker (2023) apresenta uma ferramenta útil para equipes que pretendem
otimizar seu processo de implantação e execução de aplicações: a criação de
contêineres. Através da criação de um contêiner, é possível empacotar todo o código
fonte e dependências de uma aplicação, facilitando o processo de migração desta
aplicação para qualquer arquitetura. Dessa forma, quando um membro do time
de desenvolvimento realiza uma alteração no código, o processo de compilação e
integração ao container que está dando o suporte de infraestrutura da aplicação é feito
de forma rápida, otimizando o tempo do desenvolvimento.

Uma grande vantagem em se utilizar contêineres, como explicado por Docker

(2023), é a garantia que a aplicação empacotada irá funcionar da mesma forma,
independentemente da configuração de hardware da máquina hospedeira, tendo
em vista que todas as configurações, pacotes, bibliotecas e aplicações necessárias
(incluindo Sistema Operacional), para a execução do Software que será empacotado,
estarão presentes e configurados no contêiner.

A Figura 12 apresenta como um contêiner pode ser utilizado com o Docker. Por
ser um contêiner que irá agrupar diferentes aplicações e todo o ecossistema necessário
para executar uma aplicação, o ícone que representa a ferramenta Docker é uma baleia.

Figura 12 – Exemplo de utilização de um contêiner de aplicações com Docker.

Fonte: adaptada de Docker (2023)

A Figura 12 apresenta a organização de contêineres dentro de um servidor

Docker. É possível criar toda a infraestrutura necessária em um contêiner, de modo que
o sistema operacional necessário para executar uma aplicação, assim como todas as
bibliotecas necessárias para seu funcionamento e outros Softwares auxiliares poderão

231
 estar armazenados em um mesmo contêiner. O servidor Docker permite que diferentes
contêineres sejam criados com diferentes configurações, facilitando o processo de
deploy da aplicação, já que basta executar o servidor Docker com as imagens dos
contêineres criados que a aplicação já poderá ser utilizada.

DICA
Para entender melhor a aplicação de um contêiner criado com Docker,
sugerimos assistir ao vídeo https://www.youtube.com/watch?v=ntbpIfS44Gw.

Acadêmico, no próximo subtema, abordaremos o método Kanban (que não

se resume apenas ao quadro kanban) e sua relação com o gerenciamento de projetos
(ágeis ou preditivos).

5 MÉTODO KANBAN E O GERENCIAMENTO DE PROJETOS

O método Kanban (com K maiúsculo), apresentado por Anderson (2011) como
um derivado do método Lean, introduzido por Caroli (2018), possui o intuito de trazer um
processo que fosse evolutivo e incremental, voltado para equipes que trabalham com
projetos de tecnologia.

Ainda segundo Anderson (2011), o método Kanban tem o quadro kanban (com
k minúsculo) como uma de suas ferramentas de trabalho, porém, com a vantagem de
poder ser utilizado por equipes de diferentes domínios do conhecimento. Qualquer
projeto poderá se beneficiar da utilização de um quadro visual que apresente, de forma
clara e objetiva, a todos os interessados, o real andamento das atividades pelo time de
desenvolvimento.

A Figura 13 apresenta um exemplo de um quadro kanban na prática de equipes

ágeis.

232
 Figura 13 – Exemplo de divisão em baias de um quadro kanban

Fonte: adaptada de Anderson (2011)

A Figura 13 apresenta um exemplo de quadro kanban utilizado por equipes

ágeis. Em cada raia são posicionadas tarefas que farão parte do escopo acordado com
o cliente. Na baia product backlog estarão todas as tarefas que serão contempladas
pelo projeto, mesmo que ainda não tenham sido devidamente refinadas para atuação
do time de desenvolvimento. A raia a fazer contemplará todas as tarefas que serão
trabalhadas pelo time em um ciclo (sprint), já com os devidos refinamentos. Ao iniciar o
desenvolvimento de uma tarefa, o desenvolvedor responsável deverá mover esta tarefa
para a raia fazendo, tornando a movê-la para a raia feito ao concluir sua implementação
e todos os testes necessários.

Silva e Anastácio (2019) afirmam que é comum que a introdução de novas

metodologias de trabalho, em um ambiente que já está “viciado” na utilização de
uma mesma forma de conduzir o processo, tenha resistência por parte das pessoas
envolvidas. O método Kanban tem o benefício de conseguir introduzir mudanças na
forma como uma equipe conduz seu processo de trabalho sem que haja uma resistência,
mantendo um ritmo de trabalho sustentável para a equipe.

Segundo Rocha e Sousa (2021), o método Kanban, quando adotado por uma
Organização, promove a redução dos custos globais de um projeto, tendo em vista que
irá evitar o desperdício, na medida que reduz a quantidade de insumos estocados e que
não serão utilizados. Desta forma, o método irá destacar as Empresas que dele fizerem
uso frente aos seus concorrentes que não utilizam da mesma metodologia.

Segundo Anderson (2011), o método Kanban é considerado um método puxado,

pois as tarefas que serão desenvolvidas em um determinado momento deverão coincidir
com a capacidade de execução do time, de modo que uma nova tarefa será inserida no
ciclo de execução apenas após a finalização de outra tarefa, o que deixaria um “espaço
sobrando”. Sendo assim, o time não ficará sobrecarregado, conseguindo ditar o ritmo de
trabalho de acordo com sua produtividade.

233
 Segundo Marinho (2020), uma característica importante do método Kanban
é a definição de Work In Progress (ou WIP), que irá indicar a capacidade máxima que
uma baia do quadro kanban poderá acomodar, em termos de quantidade de tarefas. O
objetivo é evitar que gargalos sejam formados em determinados estágios do processo,
como a fase de homologação de tarefas ou de tarefas em execução. Então, quando a
quantidade de tarefas equivale ao valor definido pelo WIP de uma baia, outras tarefas
que se encontram no estágio anterior deverão aguardar, até que vague um espaço na
baia que está com a quantidade de tarefas igual ao número de tarefas definidas no WIP.

INTERESSANTE
Segundo Marinho (2020) e Anderson (2011), o WIP é representado por um valor numérico
que deverá estar de acordo com a capacidade de execução dos envolvidos no time do projeto
em uma determinada fase do processo. Então, caso o time possua duas pessoas com
o papel de product owner, por exemplo, o número WIP deverá ser calculado com
base na produtividade desses membros.
O objetivo é conseguir dar vasão às tarefas de cada etapa do processo, sem
que se formem gargalos significativos em etapas específicas. Se o valor definido
foi muito pequeno, é possível que a etapa anterior se torne um gargalo,
principalmente se for de execução mais rápida que a próxima etapa. Se o
valor definido for muito grande, mas a capacidade de execução não conseguir
acompanhar o ritmo, muitas tarefas irão se acumular nesta etapa, não sendo
passadas para as próximas etapas.

Ao se utilizar o método Kanban para o acompanhamento de projetos, o Gerente

de Projetos poderá perceber, por exemplo, qual a capacidade de produção do time
de desenvolvimento, em termos de quantidade de tarefas sendo executadas em um
único ciclo, identificar pontos que estão atrasando a entrega das atividades previstas
(como uma homologação lenta), além de identificar eventuais deficiências da equipe,
como necessidade de inclusão de mais um membro para execução dos testes ou para
desenvolvimento do projeto.

É comum que equipes que trabalham com metodologias ágeis façam uso de
uma mescla de métodos ou ferramentas que auxiliem no andamento do projeto, como
o framework SCRUM e alguns conceitos do método Kanban ou apenas o quadro kanban
para acompanhamento das atividades do projeto, conforme apresentado na Figura 14.

234
 Figura 14 – Exemplo de utilização do quadro kanban por membros de um time ágil

Fonte: https://bit.ly/3GxKaIa. Acesso em: 10 abr. 2023.

A Figura 14 apresenta um exemplo de utilização do quadro kanban por times

ágeis. Os membros do time devem movimentar as tarefas, conforme seus estados atuais
de execução, entre as raias do quadro, dando transparência a todos os interessados no
projeto acerca do andamento real de cada tarefa que esteja em atuação pelos membros
da equipe de desenvolvimento.

Acadêmico, neste tema de aprendizagem foram apresentadas ferramentas que

podem auxiliar o Gerente de Projetos (ou outro papel responsável pelo acompanhamento
das etapas de um projeto) a realizar o processo de gestão, acompanhando a execução
de cada etapa, os recursos que estão sendo consumidos e a velocidade na qual a
utilização acontece, dentre outras questões importantes para garantir que o êxito do
projeto seja alcançado. Também apresentamos ferramentas próprias para equipes que
fazem uso das metodologias ágeis.

Pressman e Maxim (2021) afirmam que, apesar da utilização de ferramentas ser

de grande valia para o Gerente de Projetos, não é obrigatório que todos os projetos
façam uso das mesmas ferramentas ou até que uma ferramenta seja, necessariamente,
adotada pela equipe. Também é importante mencionar que a utilização de uma
ferramenta voltada para auxiliar o processo de gestão não irá substituir o papel do
Gerente de Projetos, nem reduzir sua responsabilidade.

235
 RESUMO DO TÓPICO 1
Neste tópico, você aprendeu:

• As ferramentas de gestão de projetos são importantes para auxiliar o Gerente de

Projetos a definir os itens planejados para o projeto e acompanhar seu andamento.
É possível utilizar ferramentas de gestão tanto em projetos executados com
metodologias preditivas quanto ágeis, ou até combinando ferramentas voltadas
para as duas metodologias.

• Ferramentas voltadas para metodologias tradicionais possuem maior previsibilidade,

fornecendo maior exatidão no planejamento, sendo importantes para projetos em
qualquer metodologia de desenvolvimento.

• As ferramentas de controle de versão são importantes para a dinâmica de

equipes geograficamente distribuídas ou que atuam em múltiplos projetos, sendo
classificadas de acordo com o algoritmo que implementa em locais, centralizadas
ou distribuídas.

• O controle de versão local não é recomendável, já que há um alto risco de perda de

versões por falha humana.

• O controle de versão centralizado cria uma versão de cada arquivo que será
gerenciado e armazena, a partir de então, apenas as alterações efetuadas em forma
de deltas.

• O controle de versão distribuído irá criar uma cópia de cada arquivo alterado para
cada nova versão criada, não armazenando apenas as alterações efetuadas, como
no modelo centralizado.

• Existem diferentes tipos de ferramentas para auxiliar projetos ágeis, sendo a maior
parte baseada no quadro kanban, como a Jira e a Trello.

• O Mínimo Produto Viável (MVP) poderá ser criado quando há uma grande incerteza
sobre os requisitos necessários para a aplicação ou quando há limitação de recursos
como orçamento e o cronograma de execução. Apenas o mínimo conjunto de
funcionalidades irá ser implementado, disponibilizando em produção para validação
do cliente a versão inicial do produto.

• Técnicas como o estacionamento de ideias auxiliam a identificar novas

funcionalidades para um produto ou melhoria nas funcionalidades já existentes.

236
• O método Kanban é capaz de implementar um fluxo de trabalho de acordo com a
capacidade de produção do time, através de métricas como a WIP, sendo considerado
como um método puxado, já que é o time que irá definir quantas tarefas serão
executadas em cada ciclo de trabalho.

237
 AUTOATIVIDADE
1 As ferramentas de controle de versão são importantes para o funcionamento de
equipes que trabalham geograficamente distribuídas, possibilitando que uma
mesma aplicação possa ter contribuições por diferentes membros do time de
desenvolvimento. Sobre as ferramentas de controle de versão, assinale a alternativa
CORRETA:

a) ( ) O modelo centralizado é o mais adequado para equipes distribuídas, já que

permitem que cada membro do time faça clonagem do projeto inteiro.
b) ( ) O modelo local é mais adequado para trabalho com times pequenos, tendo em
vista que apresenta segurança e confiabilidade.
c) ( ) O modelo descentralizado se mostra mais adequado para grandes times, já
que cada membro terá seu espaço de trabalho local, através da clonagem do
repositório completo.
d) ( ) O modelo mais adequado é uma combinação entre os modelos centralizado e local,
apresentando uma maior segurança e reduzindo o tempo de indisponibilidade do
servidor.

2 Ao se trabalhar com sistemas de controle de versão, alguns termos devem ser de

entendimento dos membros do time, alinhando o conhecimento sobre as técnicas de
gerenciamento de configuração e controle de versão. Com base no texto apresentado
e em seus conhecimentos, analise as sentenças a seguir:

I- Mainline representa uma versão de trabalho de um membro do time de

desenvolvimento, após a obtenção dos itens de configuração que serão trabalhados
do repositório.
II- Codeline representa uma versão do código fonte de uma aplicação, que poderá
compor uma baseline.
III- A mainline de uma aplicação é composta por diferentes baselines, ao longo do
processo do ciclo de vida da aplicação.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças II e III estão corretas.
d) ( ) Somente a sentença III está correta.

238
3 Para que uma ferramenta de controle de versão possa ser implementada, ela precisa
fornecer algumas funcionalidades básicas, que darão suporte a todo o processo.
De acordo com o texto e seus conhecimentos, classifique V para as sentenças
verdadeiras e F para as falsas:

( ) Uma ferramenta de controle de versão deve permitir a criação de ramificações, que

serão trabalhadas por um desenvolvedor.
( ) Uma ferramenta de controle de versão deve armazenar versões apenas por um
período limitado de tempo como.
( ) A ferramenta de controle de versão deve permitir que desenvolvedores acessem
apenas os projetos/itens para os quais tiver permissão.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – V.
d) ( ) F – F – V.

4 O gerenciamento de projeto inclui, dentre outras etapas, o processo de

acompanhamento das etapas iniciais de planejamento, caso seja adotado o modelo
tradicional de desenvolvimento de Software. Uma das variáveis que precisa ser
acompanhada é o orçamento do projeto. Com base no texto exposto e em seus
conhecimentos, explique como a utilização da técnica do valor agregado poderá
prevenir o fracasso de um projeto.

5 Implementar e seguir processos são importantes para garantir que um fluxo sempre
aconteça da mesma forma. Com o processo de gerenciamento de tarefas, uma forma
de garantir que as etapas da resolução de um bug possam ser acompanhadas é
fundamental. Diante disso, disserte sobre a importância da utilização de ferramentas
de controle de tarefas para projetos que seguem as metodologias ágeis.

239
240
UNIDADE 3 TÓPICO 2 -
FERRAMENTAS PARA INTEGRAÇÃO
E ENTREGA CONTÍNUA

1 INTRODUÇÃO
Segundo Valente (2020), a prática da integração contínua surgiu com as
metodologias ágeis, mais especificamente com a Extreme Programming (XP), com o
objetivo de fatiar uma tarefa grande em pequenas partes, que pudessem ser integradas
ao código da aplicação principal sem muitos problemas (conflitos) no momento da
integração.

Humble e Farley (2014) afirmam que o processo de integração e entrega

contínua poderá fazer uso de ferramentas que possibilitem a integração de código à
aplicação já em funcionamento a cada nova mudança implementada no código. Essas
ferramentas, por sua vez, devem fornecer três funcionalidades básicas: controle de
versão, automatização da compilação do código e utilização pela equipe. É preciso que
a equipe de desenvolvimento interiorize o processo e o siga, de modo a garantir que a
integração e entrega contínua aconteça.

Sommerville (2018) afirma que o processo de integrar continuamente faz

pequenas mudanças ao código da aplicação principal e irá causar constantes recriações
da mainline, que representa o sistema funcional definitivo (que se encontra em ambiente
produtivo).

Acadêmico, no Tema de Aprendizagem 2 abordaremos as ferramentas

voltadas para implementar a integração e entrega contínua em um projeto (subtema
2), apresentando alguns exemplos de ferramentas disponíveis no mercado, como a
Jenkins (subtema 3) e demais ferramentas (subtema 4).

2 IMPORTÂNCIA DA UTILIZAÇÃO DE FERRAMENTAS PARA

INTEGRAÇÃO E ENTREGA CONTÍNUA
Segundo Humble e Farley (2014), a entrega e integração contínua (do inglês
Continuous Integration/Continuous Delivery – CI/CD) representa uma prática, que
não torna obrigatório o uso de ferramentas específicas. Dessa forma, uma equipe que
deseja adotar esta prática em seu dia a dia de trabalho deve compreender as etapas e
como implementar cada uma, segundo sua cultura e necessidade, iniciando o ciclo de
execução e gerenciando todo o processo. Apesar da não obrigatoriedade da adoção de

241
 uma ferramenta voltada para a implementação do processo de CI/CD, existem diversas
ferramentas disponíveis no mercado, com instalação e configuração fáceis e que irão
gerenciar todo o processo, garantindo que todas as etapas sejam executadas com
sucesso.

Em um processo de entrega e integração contínua feita de forma manual, a

pessoa responsável pela junção de todas as intervenções no código realizadas por
todos os membros do time de desenvolvimento seria árduo e propenso a erros, tendo
em vista que processos manuais requerem mais atenção para sua execução acontecer
sempre da mesma forma (REDHAT, 2023).

Para que o processo de integração contínua aconteça, algumas etapas precisam

ser seguidas, sendo elas (SOMMERVILLE, 2011; SOMMERVILLE, 2018):

• Cada desenvolvedor deverá realizar o checkout da versão principal da aplicação

(mainline) para seu ambiente local.
• Os desenvolvedores deverão codificar as funcionalidades necessárias, executando
os devidos testes automatizados ao final do processo de implementação, se
certificando que todos os testes obtiveram êxito em suas execuções.
• Fazer as mudanças necessárias nos devidos componentes.
• Codificar as alterações necessárias e executar os devidos testes no ambiente de
trabalho local. Caso os testes falhem, a codificação deverá continuar para corrigir os
problemas apresentados.
• Com os testes obtendo o êxito esperado, realizar os devidos testes ao integrar o
trecho de código construído com a aplicação, sem aprovar ainda uma nova versão
de baseline.
• Atualizar o servidor de desenvolvimento com os trechos de código construídos
e integrados na aplicação principal, realizando os devidos testes. Caso sejam
necessários ajustes devido às modificações feitas por outros desenvolvedores,
efetuar os respectivos ajustes e repetir os testes.
• Caso todas as validações feitas no ambiente de desenvolvimento forem aprovadas,
então as mudanças construídas serão aprovadas para integrarem uma nova versão
de baseline do sistema, que será, então, incorporada à versão principal (mainline).

Uma vantagem do processo de integração contínua, conforme salientado por

Sommerville (2018), é a descoberta e a resolução antecipada de erros ocasionados pelo
processo de interação entre os membros do time de desenvolvimento. A versão do
sistema que comporá a mainline é caracterizada como a versão funcional da aplicação.

Nem sempre, contudo, é possível implementar o processo de integração

contínua em um projeto, segundo Sommerville (2018), caso alguma das seguintes
condições aconteça:

242
• caso o sistema seja muito grande e seja necessária integração com outras
aplicações;
• caso a plataforma de desenvolvimento e destino sejam diferentes, dificultando a
realização dos testes do sistema no ambiente local do desenvolvedor.

Nas situações descritas anteriormente, quando o processo de integração

contínua costuma ser praticamente impossível, é possível definir e seguir um roteiro
diário de atividades, buscando adaptar uma integração contínua ao projeto, como a
estipulação de um horário limite para entrega de componentes do sistema, a construção
de uma nova versão utilizando esses componentes entregues, a execução de testes
predefinidos em cima da nova versão gerada e a correção de eventuais erros, caso
detectados, pela equipe de desenvolvimento, ainda concordando com Sommerville
(2018).

IMPORTANTE
Sommerville (2011), Humble e Farley (2014) e Redhat (2023) chamam atenção para
a necessidade de utilização de ferramentas para controle de versão objetivando
realizar o processo de junção das contribuições dos diferentes membros de uma
equipe de forma automatizada, evitando, assim, falhas no processo manual.

Para se obter sucesso em um processo de integração contínuo, como afirmado por

Valente (2020), as intervenções realizadas no código da aplicação pelos desenvolvedores
precisarão ser testadas, após integradas à aplicação já em funcionamento, e, caso o
teste seja aprovado, enviadas ao repositório que realiza o controle de versão do código
de maneira periódica. Dessa forma, pretende-se evitar que outros membros do time de
desenvolvimento encontrem eventuais conflitos nos trechos de código onde efetuaram
alterações, acarretando mais trabalho para solucionar corretamente estes conflitos.

ATENÇÃO
Segundo Redhat (2023), a periodicidade ideal para atualização do repositório de
controle de versão do código da aplicação é ao final de cada dia de trabalho.
Dessa forma, caso algum problema físico na máquina de algum programador
aconteça, o volume de retrabalho será reduzido.

Algumas categorias de testes básicos devem ser executadas para garantir que
as mudanças implementadas em uma baseline que será integrada a uma mainline sejam

243
 avaliadas e aprovadas, prevenindo que problemas sejam detectados quando os ajustes
forem encaminhados para ambiente de produção. Podemos listar estas categorias de
testes como (IANCU, 2018):

• Testes unitários – Representam o menor nível de testes, específicos para avaliar

funções particulares. Não se preocupam em testar todo o comportamento da
aplicação, após a integração das mudanças e são feitos pelo desenvolvedor que
implementou o código fonte.
• Teste de integração incremental – Representam um processo contínuo de testes
em uma aplicação, à medida que novas funcionalidades vão sendo integradas,
podendo ser executados pelos desenvolvedores ou testadores.
• Testes de componentes – Irão avaliar se os componentes implementados estão
apresentando o comportamento esperado, também desconsiderando a aplicação
como um todo.
• Teste de regressão – Alteração no comportamento de uma funcionalidade devido
à adição ou modificação de um requisito, necessitando de uma retestagem das
funcionalidades que já foram previamente testadas e validadas. Visa garantir que
bugs não foram inseridos graças às integrações recentes realizadas na aplicação.
• Testes de aceitação – Devem analisar as regras de negócio implementadas e se
a aplicação está de acordo com as premissas necessárias para seu funcionamento,
como tempo de resposta adequado (performance), disponibilidade, questões de
segurança e demais requisitos não funcionais especificados para a aplicação.

IMPORTANTE
Segundo Pressman e Maxim (2021), a criação dos testes unitários deverá
possibilitar sua automatização e execução diária, além de facilitar a execução de
outros tipos de testes, como os testes de regressão.

O processo de compilação do código implementado pelos diferentes membros

do time de desenvolvimento deve acontecer de forma automatizada, através da
utilização de uma ferramenta de versionamento de código, que deverá ser integrada
com outras ferramentas que promovam o processo de CI/CD completo, como a
implantação da versão gerada, após a finalização com sucesso da compilação, em um
ambiente operacional, de acordo com Pizzaia e Malara (2022).

Segundo Redhat (2023) e Pizzaia e Malara (2022), o processo de CI/CD deverá

seguir um pipeline de implantação das alterações em produção, de modo que as
principais fases deste pipeline estão apresentadas na Figura 15.

244
 Figura 15 – Etapas do processo de CI/CD

Fonte: adaptada de Redhat (2023)

A Figura 15 apresenta as etapas básicas de um processo de integração, entrega

e implantação contínua. Enquanto no processo de integração contínua (CI) é feita a
compilação do código que será integrado, os testes unitários nas funcionalidades
implementadas e a mesclagem do código construído com a aplicação alvo, a fase de
entrega contínua (CD) será responsável pela atualização do repositório de código com
a versão da aplicação já com as alterações mescladas. O processo de implantação, por
sua vez, será responsável por atualizar o ambiente de produção com a nova versão da
aplicação, disponibilizando-a aos usuários finais.

Caso algum problema aconteça durante as etapas executadas pelo pipeline de

implantação, concordando com Humble e Farley (2014), é necessário que os responsáveis
sejam notificados, sendo possível o acesso aos logs contendo as informações a respeito
dos problemas detectados. As falhas deverão ser corrigidas e o processo repetido, até
que se obtenha sucesso e uma versão estável da aplicação possa ser disponibilizada ao
usuário.

O ciclo de entrega, integração e implantação contínua é definido por Neto

(2022) como um pipeline DevOps, cujo objetivo primordial é centralizar o processo de
compilação e implantação de uma versão da aplicação em um ambiente operacional
(que pode ser produção, homologação ou outro existente e configurado previamente
para suportar a aplicação alvo).

245
 INTERESSANTE
Redhat (2022) explica que a sigla DevOps é a junção das siglas developers
(desenvolvedores) com operations (operações), indicando que o próprio membro
do time de desenvolvimento será o responsável por construir o código, realizar os
devidos testes, compilar de forma integrada à aplicação e, por fim, implantar em
produção. Todo o processo acontecendo de forma automatizada.
A utilização de ferramentas que possibilitem a automatização de
todo processo possibilita que a equipe adote a metodologia DevOps,
aumentando a velocidade das entregas e a qualidade dos artefatos
construídos (NETO, 2022) e (REDHAT, 2022).

ATENÇÃO
Segundo Neto (2022), o termo contínuo, presente na sigla CI/CD, indica que
a implantação das tarefas construídas (ou manutenções efetuadas no código)
são realizadas sem a necessidade de uma data programada. À medida que
as alterações no código vão ficando prontas, ou seja, testadas e devidamente
integradas ao código principal, estas vão sendo liberadas para uso em produção,
pelo usuário final.

As tarefas que devem ser executadas, em um processo de integração e entrega

contínua, devem seguir os passos apresentados na Figura 16.

Figura 16 – Passos para o processo de CI/CD

Fonte: adaptada de Neto (2022)

246
 A Figura 16 apresenta os passos dos ciclos de CI/CD. Segundo Neto (2022),
as tarefas de codificação, processo de compilação e realização de testes (de todos os
níveis necessários) formam o processo de integração contínua, enquanto as etapas
de criação de nova versão (do inglês release) e o processo de implantação em produção
(do inglês deploy) compreendem o ciclo de entrega contínua.

Neto (2022), Redhat (2022) e Maximiano e Veroneze (2022) explicam que,

após a implantação do processo de CI/CD em uma equipe, os membros do time de
desenvolvimento devem sempre se preocupar em atualizar suas versões do código da
aplicação com as implementações feitas pelos demais membros, através da utilização
de um repositório de código que faça controle de versão.

Para facilitar o processo de implantação de um pipeline CI/CD, existem algumas

ferramentas disponíveis, como a Jenkins, que apresentaremos no próximo subtema.

3 JENKINS
A Jenkins como uma ferramenta de código aberto, escrito na linguagem Java
e que possui seu foco no processo de CI/CD para qualquer tipo de projeto, otimizando
o processo de compilação, testes automatizados e implantação da versão em um
ambiente operacional (REDHAT, 2022).

Segundo Rodrigues (2020), a partir da sua instalação e configuração, os

desenvolvedores do time poderão enviar suas contribuições em código para o repositório
central de controle de versão da aplicação que irá servir de subsídio de entrada para a
ferramenta Jenkins. Esta irá ler o nome da versão de trabalho (do inglês branch), também
conhecida como ramificação, indicada pelo responsável pela implantação da versão
atualizada em um ambiente e fará todo o processo de compilação, testes e implantação.

NOTA
A ferramenta Jenkins poderá ter seu download efetuado através do link
https://www.jenkins.io/.

A Figura 17 apresenta um resumo do funcionamento da ferramenta Jenkins.

247
 Figura 17 – Resumo do fluxo de um processo implantado via Jenkins

Fonte: adaptada de Rodrigues (2020)

A Figura 17 apresenta, de forma resumida, os passos realizados pela ferramenta

Jenkins para implantar o processo de CI/CD. Ao passo que os desenvolvedores do time
vão enviando ao repositório de controle de versão os códigos por eles construídos,
a ferramenta irá fazer, periodicamente, um processo de leitura deste repositório e
atualização da versão da aplicação que será implantada. Quando um desenvolvedor
decide aplicar, em um ambiente operacional, uma versão que está no repositório de
código, a ferramenta irá atualizar este ambiente. Caso algum problema seja encontrado,
durante a execução das etapas descritas na Figura 16, um relatório será gerado e
disponibilizado aos desenvolvedores do time, para que o problema possa ser solucionado.

INTERESSANTE
A ferramenta Jenkins, segundo Rodrigues (2020), é altamente extensível,
podendo se integrar com diferentes outras ferramentas e plugins, que irão
ampliar o leque de funcionalidades da ferramenta, além de ser possível
instalá-la em qualquer Sistema Operacional.

248
 A ferramenta irá construir um pipeline de execução, de forma automatizada,
formado a partir de um conjunto de plugins que darão o suporte necessário para as
tarefas de entrega contínua (CD). Para que o processo se complete, será necessário
que o código obtido da ferramenta de controle de versão passe por múltiplos estágios
de compilação e testes, até a implantação da nova versão em um ambiente operacional.
Todo este pipeline será descrito através de um arquivo texto que poderá ser armazenado
no repositório de código do projeto (JENKINS, 2023).

Além da ferramenta Jenkins, existem outras disponíveis no mercado, também

de código aberto (livre de licenças), as quais abordaremos no próximo subtópico.

4 OUTRAS FERRAMENTAS
Além da ferramenta Jenkins, mencionada no subtema anterior, ainda existem
outras ferramentas que também estão disponíveis no mercado, sendo muitas delas
de código aberto, assim como a Jenkins. Abordaremos algumas das principais neste
subtema.

Segundo Rodrigues (2022) e Pizzaia e Malara (2022), uma ferramenta tão

popular quanto a Jenkins é a GitLab. Esta ferramenta possui alta escalabilidade, de
modo que equipes com muitos membros são capazes de utilizar, simultaneamente, os
recursos da ferramenta, sem ônus na performance.

As etapas de versionamento de código, testes automatizados e publicação do

código em um ambiente operacional podem ser facilmente executadas pela GitLab, que
ainda possui uma robusta documentação e comunidade para solucionar dúvidas dos
usuários, como apresentado por Pizzaia e Malara (2022).

A ferramenta ArgoCD, como explicado por Kubernetes (2023), tem seu

propósito focado na implantação de aplicações no Kubernetes, que é definida como
uma ferramenta de orquestração, capaz de realizar o processo de implantação de novas
versões, de forma automatizada em contêineres.

INTERESSANTE
Redhat (2021) explica que um container de aplicação é o empacotamento de
todos os componentes que se fazem necessários para a execução de uma
aplicação, em um ambiente centralizado. Dessa forma, é possível migrar esse
container para qualquer ambiente operacional (com qualquer configuração
de hardware ou sistema operacional), sem a necessidade de ter que recriar
todo o ambiente operacional, com suas respectivas configurações.

249
 Outra ferramenta criada com o intuito de promover o CI/CD para Kubernetes é
a FluxoCD, se diferenciando da ArgoCD por ser um conjunto de ferramentas que irão
trabalhar em um cluster de execução, ou seja, atualizando diferentes contêineres ao
mesmo tempo, como menciona Rodrigues (2020).

Conforme explica Arrosi (2013), a ferramenta proprietária Team Foundation

Server (TFS) da Microsoft é voltada para o gerenciamento do ciclo de vida de uma
aplicação, auxiliando em todas as etapas de um projeto (planejamento, execução
e monitoramento do processo de desenvolvimento). Composta por cinco módulos
principais, a ferramenta possui algumas limitações para o gerenciamento de requisitos
e de portfólio, que podem ser solucionadas a partir da integração desta ferramenta
com outras soluções Microsoft, como o pacote Office e a o Software Microsoft Project
Server (específica para gerenciamento de portfólio). Os cinco módulos que compõem a
ferramenta Team Foundation Server são:

• gerenciamento de projetos;
• gerenciamento de tarefas;
• controle de versão;
• métricas;
• gerenciamento de construções.

Segundo Microsoft (2007), a ferramenta Team Foundation Server trabalha

através de um servidor centralizado, a partir do qual é possível criar ambientes individuais
de trabalho por cada membro do time de desenvolvimento. Sendo assim, ao realizar o
processo de envio das contribuições feitas, a ferramenta se torna responsável por efetuar
a mesclagem dessas atualizações com a versão principal da aplicação, possibilitando a
criação de versões da aplicação para avaliação por testadores. Ao concluir os testes, os
resultados serão armazenados no próprio servidor central, fornecendo feedback acerca
da qualidade da versão analisada.

DICA
Recomendamos assistir ao vídeo a seguir para entender, de forma sucinta,
o propósito da ferramenta na prática. Acesse em: https://www.youtube.com/
watch?v=GjZF5E8eCMk.

250
 RESUMO DO TÓPICO 2
Neste tópico, você aprendeu:

• O processo de entrega e integração contínua, apesar de não exigir a utilização de

ferramentas, pode ser facilitado caso alguma ferramenta seja adotada e devidamente
aceita pela equipe, ou seja, que os membros do time de desenvolvimento, de fato,
utilizem a ferramenta acordada.

• O processo de entrega e integração contínua está dividido em três etapas distintas:

compilação, testes e validação e implantação em ambiente operacional.

• Os testes unitários devem ser construídos, preferencialmente, de forma

automatizada, para que possam ser executados diariamente e sempre da mesma
forma, garantindo a consistência dos resultados. Também devem permitir a
execução de testes de regressão nas funcionalidades já existentes e aprovadas.

• Existem algumas etapas fundamentais de testes que precisam ser executadas em

uma alteração que será integrada à aplicação principal (mainline), sendo elas os
testes unitários, testes de integração incremental, testes de componente, testes de
aceitação e testes de regressão (quando necessário).

• A entrega e integração contínua pode ser implantada através da definição de um

pipeline de execução, no qual cada etapa irá ser responsável pela busca do código
no repositório de versionamento, compilação, testes e implantação em ambiente
operacional. Além disso, é importante que o script que implementa o fluxo CI/CD
seja armazenado no repositório de controle de versão.

• Algumas das ferramentas disponíveis para o processo de CI/CD são a Jenkins, a

GitLab, a ArgoCD e a FluxoCD, dentre outras.

251
 AUTOATIVIDADE
1 Em um processo de integração e entrega contínua, é importante garantir que seja
executado sempre de forma repetida, minimizando a possibilidade de falhas de
execução durante o processo, o que justifica a utilização de ferramentas que apoiem
este processo. Considerando o texto apresentado e seus conhecimentos, assinale a
alternativa CORRETA:

a) ( ) As ferramentas de apoio ao processo de entrega e integração contínua devem

ser capazes de realizar o processo de compilação, testes, envio ao repositório e
implantação em ambiente operacional.
b) ( ) As ferramentas de apoio ao processo de entrega e integração contínua podem
ser substituídas por documentos manuais, garantindo o mesmo nível de eficácia
do processo.
c) ( ) As ferramentas de apoio ao processo de entrega e integração contínua só podem
ser utilizadas por equipes que implementam as metodologias ágeis.
d) ( ) As ferramentas de apoio ao processo de entrega e integração contínua só
apresentarão bons resultados se forem integradas com outras ferramentas,
como a de controle de tarefas.

2 O processo de entrega e integração contínua de uma aplicação se mostra importante

para reduzir a latência, para o usuário final, na disponibilização das funcionalidades
em produção, típica das metodologias tradicionais de desenvolvimento. Com base no
conceito sobre entrega e integração contínua, analise as sentenças a seguir:

I- O intuito de ser contínuo significa que as tarefas, assim que ficarem prontas e com
os testes realizados com sucesso, podem ser implantadas em ambiente operacional
sem a necessidade de se programar uma data específica.
II- A entrega contínua significa que todos os membros do time de desenvolvimento
devem estar trabalhando, continuamente, em uma tarefa do projeto, sem que haja
um intervalo entre elas.
III- O processo de integração contínua deve seguir um fluxo que envolve a implantação
em ambiente operacional, de uma tarefa implementada pelo time.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença II está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) Somente a sentença III está correta.

252
3 A ferramenta Jenkins, voltada para entrega e integração contínua, se mostra como
uma das mais utilizadas no mercado atualmente. Considerando seus conhecimentos
sobre as características da ferramenta Jenkins, classifique V para as sentenças
verdadeiras e F para as falsas:

( ) A ferramenta possibilita a integração com outros plugins e ferramentas que podem

incrementar suas funcionalidades.
( ) Através da ferramenta Jenkins e sua integração com sistemas de controle de versão,
como o Git, é possível obter todas as contribuições realizadas pelos membros do
time em um projeto.
( ) A ferramenta só permite que o pipeline de implantação seja construído seguindo
um dos modelos prontos disponibilizados pelo Software.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – V – F.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 O processo de integração e entrega contínua é composto por diferentes tarefas, que

se dividem entre as etapas de integração e entrega. É importante que os membros
do time de desenvolvimento conheçam o propósito de cada tarefa. Disserte sobre as
tarefas que compõem cada etapa do fluxo de integração e entrega contínua, explicando
a importância de cada etapa para o processo como um todo.

5 A automação do processo de implantação de uma versão em um ambiente operacional

foi um marco importante para a evolução da melhoria contínua no processo de entrega
de novas versões aos clientes. Sendo mais utilizado por equipes ágeis, segue um
dos princípios do Manifesto Ágil, que é o foco em Software em funcionamento mais
que em documentação abrangente. Diante do excerto, disserte sobre a importância
dos testes para a implantação de uma versão de modo automatizado, explicando a
diferença entre os testes de regressão e os testes unitários.

253
254
UNIDADE 3 TÓPICO 3 -
NORMAS DE APOIO AO
GERENCIAMENTO DE CONFIGURAÇÕES

1 INTRODUÇÃO
Segundo ISO Standards (2023), adotar uma norma significa estar em conformidade
com padrões, muitas vezes internacionais, que representam a melhor forma de se fazer
alguma coisa. Assim, grupos em Organizações Normativas se preocupam em definir
quais as melhores práticas para se atingir um objetivo, garantindo sucesso ao final do
processo de implantação, através da obtenção dos resultados pretendidos.

Para que o processo de gerenciamento de configurações seja feito da melhor

forma, garantindo aplicação de boas práticas e, principalmente, aceitação do time de
desenvolvimento, normas que provêm suporte a este processo podem ser estudadas e
seguidas.

Acadêmico, no Tema de Aprendizagem 3 apresentaremos as principais normas

voltadas para o gerenciamento de configurações. No subtema 2, discorreremos sobre
a visão dos processos CMMI e MPS.BR sobre o processo de gerência de configuração
e normas de auditoria, seguindo das normas IEEE no subtema 3. No subtema 4,
apresentaremos as normas ISO/IEC voltadas para o gerenciamento de configuração.

2 VISÃO DO CMMI E MPS.BR SOBRE A GERÊNCIA DE

CONFIGURAÇÃO E NORMAS DE AUDITORIA
Segundo Softex (2021), o MPS.BR se caracteriza como um programa que
visa aumentar a competitividade das Empresas que dele fizerem uso. Sendo possível
sua adoção por Organizações de pequeno, médio e grande portes, objetiva implantar
padrões internacionais de boas práticas em processos, visando a melhoria contínua
destes processos.

Kalinowski, Reinehr, Santos et al. (2010) afirmam que o principal objetivo na

criação do MPS.BR foi desenvolver um modelo brasileiro para implantar a melhoria
contínua do processo de desenvolvimento de Software, considerando modelos
internacionais já consolidados (como o CMMI e normas técnicas), boas práticas na
engenharia de Software e as necessidades específicas da indústria brasileira de
Software, principalmente de pequenas e médias Empresas.

255
 Existem quatro modelos MPS, que são (SOFTEX, 2021):

• Guia Geral MPS para Software – Voltada para implantação de boas práticas no
processo de desenvolvimento de Softwares.
• Guia Geral MPS para Serviços – Apresentando as boas práticas relacionadas com
o fornecimento de serviços por Organizações.
• Guia Geral MPS de Gestão de Pessoas – Voltado para o processo de Gestão de
Pessoas.
• Guia de Avaliação – Voltado ao processo de auditoria e às variáveis envolvidas no
processo.

Kalinowski, Reinehr, Santos et al. (2010) chamam atenção para o fato que as
normas técnicas existentes, como o modelo CMMI, não apresentam uma forma detalhada
de implementação de suas definições, além de terem um alto custo na implementação
e aceitação pelas Organizações, o que foi facilitado com a criação do programa MPS.BR.

O modelo MPS.BS é dividido em sete níveis de maturidade de processos,

variando do nível G até o A, onde o nível inicial é o G e o maior nível de maturidade o A.
Quanto mais uma Empresa melhora seus processos, maior o nível que ela poderá atingir
de aderência ao programa, como explicam Softex (2021) e Kalinowski, Reinehr, Santos
et al. (2010).

O guia de avaliação do MPS-BR é destinado para avaliar a aderência dos

processos, serviços ou gestão de pessoas em uma Organização, com o intuito de obter a
certificação MPS.BR em um de seus sete níveis. O processo de avaliação da maturidade
se divide em quatro subprocessos (SOFTEX, 2021b):

• Subprocesso 1 – preparação do processo de avaliação.

• Subprocesso 2 – execução da avaliação inicial da Empresa.
• Subprocesso 3 – avaliação final.
• Subprocesso 4 – documentação dos resultados obtidos das avaliações.

Comparando o processo apresentado por Softex (2021b) e Pressman e Maxim

(2021), no que tange o processo de auditoria de configuração, percebemos que a etapa
de planejamento e realização das avaliações técnicas, denominada de revisão técnica
por Pressman e Maxim (2021), são etapas em comum para que a avaliação possa ter
seus resultados mensurados para a melhoria dos processos ou garantia da qualidade
do produto que será analisado.

Os membros da equipe que fará a avaliação de uma Organização serão tanto

externos quanto internos a ela, de modo que a escolha dos membros internos deverá
obedecer a alguns critérios, sendo eles (SOFTEX, 2021b):

256
• ser isento de julgamento e opinião;
• possuir amplo conhecimento da organização, seus processos e produtos;
• colaborar com a equipe que fará a avaliação;
• se comprometer com a exatidão dos dados coletados e resultados obtidos;
• conhecer os termos e jargões utilizados pela Organização.

O nível de maturidade F do MPS.BR, em consonância com Softex (2013), é

o responsável por analisar os processos envolvidos com a Garantia da Qualidade
(GQA) e Medição (MED), além do gerenciamento dos artefatos gerados e controlados
pelo processo de Gerência da Configuração (GCO). A gerência de configuração está
relacionada com outros processos, como a gerência de decisões, para avaliar as
solicitações de mudança em configurações, a gerência de mudanças, para analisar o
impacto das solicitações de mudança realizadas e a gerência de liberações, que deve
traçar um plano de implantação das mudanças aprovadas.

IMPORTANTE
Como frisado por Softex (2013), não se deve confundir a auditoria da Gerência
de Configuração com a auditoria que visa garantia da qualidade do produto,
tendo em vista que o processo realizado com os itens de configuração deve se
atentar a identificar se cada item possui um identificador único, se está tendo
suas alterações gerenciadas corretamente (garantindo sua rastreabilidade),
dentre outras questões específicas para o item de configuração.

Como explicado por CMMI (2006), o CMMI é um modelo de melhoria de processos

de Software que visa ajudar as organizações a melhorar a qualidade de seus processos
de desenvolvimento. Ele é composto por diferentes áreas de processo, cada uma com
seus objetivos específicos e práticas recomendadas. Uma das áreas de processo mais
importantes do CMMI é a Gerência de Configuração de Software (Software Configuration
Management – SCM), que é responsável por garantir que as mudanças no Software
sejam gerenciadas e controladas adequadamente.

Isaca (2023) enfoca que a Gerência de Configuração de Software é uma área

crítica do CMMI, pois permite que as organizações gerenciem e controlem as mudanças
nos artefatos de Software, tais como código fonte, documentação, requisitos, testes e
dados. Isso inclui o controle de versões, o rastreamento de mudanças e o gerenciamento
de baselines.

A Gerência de Configuração de Software também está relacionada a outras

áreas de processo do CMMI, como Desenvolvimento Integrado de Software (Integrated
Software Development – SSD) e Gerência de Projeto (Project Management – PM). A
integração entre essas áreas de processo permite que as organizações desenvolvam
um processo de desenvolvimento de Software mais maduro e eficiente (HUMPHREY,
2005).
257
 Para implementar efetivamente a Gerência de Configuração de Software, as
organizações precisam adotar as práticas recomendadas do CMMI, de acordo com
Davis e Riemenschneider (2008). Essas práticas incluem o estabelecimento de políticas
e procedimentos para gerenciamento de mudanças, a definição de um processo de
controle de versão para o Software e a realização de auditorias regulares para garantir
que o processo de gerenciamento de configuração está sendo seguido adequadamente.

Além disso, a Gerência de Configuração de Software também é importante para

atender a requisitos regulatórios e de conformidade, como a ISO/IEC 12207 e a norma
IEEE 828, concordando com ISO (2017) e IEEE (1998). Esses padrões definem práticas
recomendadas para a gerência de configuração de Software e ajudam as organizações
a garantir a qualidade e a segurança do Software produzido.

O processo de auditoria de gerência de configuração faz parte do nível de

maturidade 2 do CMMI, sendo responsável por (CMMI, 2006):

• identificar unicamente a configuração de produtos que compõem uma baseline em

um determinado momento;
• acompanhar o controle de mudança nos itens de configuração;
• acompanhar o processo de build de produtos a partir do sistema de gestão de
configuração;
• avaliar a integridade da baseline;
• acompanhar a situação de cada item de configuração para disponibilizar aos
desenvolvedores, usuários e clientes.

CMMI (2006) enfoca que devem ser considerados itens de configuração todos
os produtos que forem entregues ao usuário final, assim como aplicações adquiridas
que deem suporte ao produto construído e itens de trabalho interno da equipe que
sirvam de apoio ao processo de desenvolvimento (ferramentas auxiliares, IDE de
desenvolvimento, plano de requisitos ou histórias de usuário etc.).

Sommerville (2011) explica que uma baseline é definida visando se obter a

melhoria contínua de processos, através da medição dos atributos do produto ou
projeto. Essa linha de base pode ser considerada uma “linha de corte” para comparar o
resultado obtido após a implementação de ações de melhoria contínua com o resultado
esperado dessas ações.

CMMI (2006) concorda com o conceito apresentado por Sommerville (2011),

afirmando que uma baseline deve incluir versões já aprovadas de um produto, contendo
versões de seus requisitos, documentação e matriz de rastreabilidade de requisitos,
devendo ser adicionado ao sistema de gerenciamento de configuração ao passo que
vão sendo desenvolvidos.

258
 Tanto o modelo MPS.BR quanto o CMMI são baseados em normas técnicas,
aceitas internacionalmente, como as normas IEEE e ISO/IEC. Abordaremos algumas
normas importantes para o processo de gerenciamento de configuração no próximo
subtema.

3 NORMAS IEEE
Segundo IEEE (2023), ao se adotar uma norma reguladora, seja para um serviço
ou processo, busca-se garantir a excelência na prestação desse serviço ou as melhores
práticas para que o produto forneça a confiabilidade e segurança esperadas pelos seus
consumidores.

O Institute of Electrical and Eletronics Engineers (IEEE) é considerado a maior

organização profissional técnica a publicar normas para os mais diferentes setores de
tecnologia e engenharias, como a telecomunicação, tecnologia da informação e serviços
e produtos geradores de energia (IEEE, 2023).

As normas publicadas pelo IEEE, quando seguidas, garantem que as melhores

práticas sejam implementadas na construção de um produto ou serviço, sendo
considerado essencial o conhecimento de tais normas pelos profissionais das áreas
exatas.

Quando se trata do Gerenciamento de Configurações de Software, algumas

normas podem servir de guia para que as melhores práticas de implementação do
processo de gerenciamento aconteçam, assegurando que o processo de gerenciamento
irá atender a uma forma de execução padrão em todas as Organizações que seguirem
tais normas.

DICA
Para conhecer mais sobre o instituto IEEE, seu propósito, missão e as
respectivas normas publicadas, acesse em https://www.ieee.org/.

Neste subtema, abordaremos as principais normas IEEE voltadas para garantia

do gerenciamento de configurações, tais quais a IEEE STD 828 – 1998, no subtema 3.1,
e a IEEE STD 1042 – 1986, no subtema 3.2. Ambas as normas são complementares,
podendo ter as duas definições aplicadas em conjunto em uma Empresa.

259
 3.1 IEEE STD 828/1998
Conforme apresentado por IEEE (1998), a norma intitulada Padronização para
Planejamento do Gerenciamento de Configurações de Software (Standards for
Software Configuration Management Plans), tem o objetivo de instituir as melhores
práticas para a atividade de planejamento do gerenciamento de configurações de
Software (da sigla em inglês SCM).

De acordo com IEEE (1998), as atividades inerentes ao processo SCM incluem

a identificação, revisão, aprovação e controle de mudanças, que incluem o processo de
geração de relatórios acerca das mudanças efetuadas e processos de auditoria para
a evolução de Softwares. A partir das informações disponibilizadas em um fluxo SCM,
deve ser possível rastrear todas as modificações realizadas em uma aplicação, de modo
que seja possível identificar qualquer item que tenha sido eventualmente modificado
e tenha impactado negativamente nas funcionalidades da aplicação que está sendo
gerenciada, possibilitando a reversão dessa modificação.

Pacheco e Sanches (1997) afirmam que as orientações da norma IEEE STD

828/1998 não se aplicam a pequenas Empresas, tendo em vista que os tópicos
abordados pela norma não possuem o nível de clareza adequado para facilitar a
implantação, servindo mais de guia para implantação das atividades de gerenciamento
de configuração.

A norma IEEE STD 828/1998 é avaliada por Gonçalves (2008) como não
específica para definir a forma como as atividades de gerenciamento de configurações
deverão acontecer, se focando apenas no conteúdo necessário para a elaboração de
um plano de gerenciamento de configurações. Como estrutura mínima necessária para
o plano de gerenciamento de configurações, é necessário que ele apresente:

• uma forma de identificação e controle da documentação, código fonte, interfaces e

bancos de dados para prover suporte a todas as fases do ciclo de vida da aplicação;
• suporte à metodologia de desenvolvimento adotada pelo projeto, incluindo seus
requisitos, processos, políticas e gestão;
• descrição do gerenciamento do processo de criação de baselines do produto, como
o controle de mudanças, versões entregues, testes e auditorias.

Segundo Cunha et al. (2004), a atividade de gerenciamento dos itens de

configuração deverá seguir um plano que garanta:

• estrutura de identificação e controle dos itens de configuração, englobando

requisitos, documentação, código fonte, banco de dados etc.;
• definição de baselines e acompanhamento desses marcos, tendo especial
preocupação com o controle de mudanças, testes, distribuições de versões,
auditorias e controle da criação de novas baselines.

260
 A Figura 18 apresenta o fluxo do processo de identificação dos itens de
configuração, estabelecido pela norma IEEE STD 828/1998.

Figura 18 – Fluxo dos processos de identificação no Gerenciamento de configuração

Fonte: adaptada de IEEE (1998)

A Figura 18 apresenta as etapas que um projeto precisa seguir, apresentados

pela norma IEEE STD 828/1998, para que um item de configuração possa ser considerado
corretamente identificado e pronto para ser gerenciado. Na primeira etapa, é preciso
definir quais serão os itens de configuração que serão gerenciados no projeto, seguindo-
se da definição dos padrões de nomenclatura que serão utilizados para os itens, versões
e a forma como será implementada a identificação única para cada item. O próximo
passo é implementar a arquitetura que dará suporte ao armazenamento/recuperação,
garantindo como será implementada a segurança adequada aos itens de configuração.

No próximo subtema apresentaremos a norma IEEE STD 1042/1986, responsável

pelo processo de gerenciamento de configurações.

3.2 IEEE STD 1042/1986

Segundo IEEE (1987), a norma IEEE STD 1042/1986 está focada em apresentar as
atividades específicas para o gerenciamento de configurações de Software. Ela define o
significado de termos e conceitos comuns no setor de Software, ajudando a promover a
clareza e a precisão na comunicação entre profissionais envolvidos no desenvolvimento
de Software, incluindo desenvolvedores, gerentes de projetos, engenheiros de Software
e outros membros da equipe.

261
 Ainda conforme explicado por IEEE (1987), o planejamento elaborado para
o gerenciamento de configurações de Software é considerado o ponto central de
integração para o processo de manutenção e integração do processo de gerenciamento
de configuração de Software, tendo em vista que este processo engloba todas as etapas
do ciclo de vida de uma aplicação.

Os itens de configuração de um projeto são armazenados em bibliotecas

de Software (Software Library), a partir do qual as versões para liberação podem ser
obtidas. As técnicas para o gerenciamento do controle de configuração estão centradas
em manter o controle dessas bibliotecas, que podem ser dos seguintes tipos, como
apresentado por Cunha et al. (2004):

• Desenvolvimento – Utilizada pela equipe de desenvolvedores do projeto, concentra

os módulos e artefatos produzidos ao longo do processo de codificação.
• Produção – Armazenando os itens de configuração que já foram entregues para o
usuário final.

A norma IEEE STD 1042/1986 define alguns itens que devem ser considerados
para a elaboração de um plano de gerenciamento de configuração, tais quais (IEEE,
1987):

• definição do escopo, através da identificação de quais itens de configuração serão

necessários gerenciar para o projeto;
• definição do glossário de termos comuns ao projeto. é preciso apresentar a
contextualização dos principais termos utilizados no negócio do projeto, podendo
utilizar acrônimos, caso estes tornem mais fácil o entendimento do glossário
elaborado;
• referências às políticas e procedimentos utilizados no projeto;
• organização dos tipos de itens de configuração que serão necessários serem
gerenciados, tais quais configurações de Software e/ou hardware;
• definição de responsabilidade entre os membros do time de desenvolvimento.

Conforme explanado por Pacheco e Sanches (1997), a norma IEEE STD

1042/1986 deve ser implementada em conjunto com a IEEE STD 828/1998, por serem
complementares. Segundo explica Murta (2006), a norma IEEE STD 1042/1986 irá
definir a formalização dos termos para criação de etiquetas (tags), que irão identificar
cada versão de um conjunto de artefatos. Após uma baseline ter sido submetida a
um processo de auditoria e ter sido entregue ao cliente, passará a ser chamada de
liberação.

Murta (2006) afirma que há uma diferença entre os termos versão e revisão
nessa norma, que considera uma versão aquela baseline que sofreu evoluções,
enquanto as revisões são compostas por correções de falhas ou melhorias que não
alterem as funcionalidades já implementadas nos itens de configuração.

262
 Essa norma ainda indica a importância da definição de baselines para facilitar o
trabalho em conjunto de vários membros que estão fisicamente distantes entre si, mas
trabalham na mesma equipe de desenvolvimento. A forma de numeração das versões,
assim como o formato dos rótulos que serão aplicados a cada item de configuração
que será gerenciado também se mostra uma questão importante no processo de
armazenamento e recuperação dos itens gerenciados, como enfatizado por IEEE (1987).

A norma ISO 10007, concordando com Pontes (2019), se mostra complementar à

norma IEEE STD 1042 no âmbito de facilitar a identificação e documentação dos itens de
configurações, necessários ao processo de gerenciamento de configuração. Conforme
mencionado por Murta (2006), a norma IEEE STD 1042/1986, apesar de ser considerada
a mais completa para o gerenciamento de configuração, foi descontinuada no ano 2000.

Abordaremos as normas ISO/IEC, também consideradas padrões internacionais,

no próximo subtema.

4 NORMAS ISO/IEC
Segundo ISO Standards (2023), a Organização Internacional para Padronização
(International Organization for Standardization – ISO), se caracteriza por ser
independente, não governamental, formada por membros de 167 países que trazem o
conhecimento e práticas necessárias para que sejam definidos padrões internacionais
aos principais desafios globais.

Ainda segundo ISO Standards (2023), as normas ISO se concentram nos

seguintes grupos:

• normas para gerenciamento da qualidade;

• normas para gerenciamento do ambiente;
• normas para saúde e segurança;
• normas para gerenciamento energético;
• normas para segurança alimentar;
• normas para segurança de Tecnologia da Informação (TI).

Assim como a Organização IEEE, a ISO tem seu foco em elaborar e disponibilizar
normas que sigam as melhores práticas para as áreas abordadas, sendo um Instituto de
referência regulatória.

263
 NOTA
As normas ISO/IEC podem ser encontradas em seu site oficial para aquisição.
Acesse em: https://www.iso.org/home.html.

Nos próximos subtemas, abordaremos as principais normas ISO voltadas para o

processo de gerenciamento de configurações.

4.1 ISO/IEC 10007

A norma ISO 10007 é importante para garantir que as organizações possam
gerenciar eficazmente a configuração de seus sistemas de Software. Isso é importante
porque, como o Software é frequentemente um componente crítico de muitos sistemas
e processos empresariais, é importante garantir que ele esteja sob controle e que seja
possível rastrear e gerenciar mudanças com eficiência (ISO, 2017).

ISO (2017) também explica que são apresentadas diretrizes para a definição
da estrutura da configuração do Software, incluindo a identificação de elementos de
configuração, a definição de suas relações e a identificação de sua versão. Além disso,
a norma fornece diretrizes para o registro e o controle de mudanças na configuração,
incluindo a gestão de solicitações de mudança, a verificação de mudanças e a aprovação
de mudanças.

A norma ISO 10007, conforme explicado por Ionică (2005), considera que
processos são correlacionados quando são executados por diferentes funcionalidades,
de forma que gerenciar todos esses processos é a base para o gerenciamento da
qualidade.

Segundo Giannone et al. (2018) e ISO (2017), uma baseline de configuração

representa um conjunto aprovado de configurações do produto, que serve de referência
para as atividades ao longo do ciclo de vida da aplicação. Dessa forma, ao se aprovar
uma baseline, qualquer alteração que aconteça em algum item de configuração que
compõe essa baseline precisará seguir as etapas do processo de gestão de mudanças
adotado pela Organização.

Ferreira e Cagnin (2006) afirmam que a norma também inclui diretrizes para a
gestão de problemas relacionados à configuração, incluindo a identificação de problemas,
a solução de problemas e o rastreamento de soluções de problemas. E finalmente, a
norma apresenta diretrizes para a documentação da configuração, incluindo a garantia
de que a documentação da configuração esteja sempre atualizada e disponível para
consulta.
264
 No próximo subtema apresentaremos a norma ISO 12207, voltada para a gestão
do ciclo de vida de Softwares.

4.2 ISO/IEC 12207

A norma ISO 12207 cobre todas as fases do ciclo de vida do Software, desde a
concepção até o encerramento, incluindo a manutenção e o suporte pós-entrega. A
norma define processos e atividades para garantir que o Software seja entregue dentro
do prazo estimado, do orçamento previsto e com a qualidade esperada (ISO, 2017).

IMPORTANTE
Como destacado por Pavão (2009), a grande competitividade do mercado
atual é um fator importante para adoção de normas que garantem qualidade,
sendo um diferencial para as Empresas que buscam implantar a norma ISO
12207.

De acordo com ISO (2017), a norma inclui processos para gerenciamento de

requisitos, gestão de projetos, gestão de configuração, testes, gestão de mudanças,
garantia da qualidade, gerenciamento de problemas e gerenciamento de contratos. Ela
apresenta orientações para a gestão da documentação do Software e para a garantia
da segurança e privacidade dos dados.

A ISO 12207, em concordância com o destaque dado por Pavão (2009), enfatiza a
importância de uma boa comunicação e colaboração entre todas as partes interessadas,
incluindo usuários, desenvolvedores, fornecedores, proprietários do sistema e gerentes
de projetos.

Conforme apresentado por Pavão (2009) e ISO (2017), Empresas que estão
em conformidade com a ISO 12207 garantem que seus projetos de Software sejam
executados de forma eficiente, eficaz e com alta qualidade. Além disso, a conformidade
com a norma pode ser usada como uma forma de demonstrar a competência e a
confiança dos fornecedores de Software para os clientes e outras partes interessadas.

Júnior, Júnior e Silva (2009) afirmam que a estrutura da norma se apresenta

de forma flexível, para que cada Organização faça a implementação da melhor forma,
conforme suas necessidades. Dessa forma, a norma se divide em dois princípios:
modularidade, visando definir processos que possam ser minimamente acoplados (o
que facilita o reuso) e aumentando a coesão entre eles; e responsabilidade: definindo
qual membro do time terá responsabilidade sobre a execução de qual processo.

265
 É importante mencionar que a norma ISO 12207 tem o foco no desenvolvedor,
servindo-lhe de referência para que todas as etapas necessárias para construção de um
produto de Software sejam definidas e seguidas da melhor forma, como apresentado
pelos autores ISO (2017) e Júnior, Júnior e Silva (2009).

Abordaremos a norma ISO 15846 no próximo subtema, sendo esta norma

voltada para estabelecer diretrizes para a Gestão da Segurança da Informação.

4.3 ISO/IEC TR 15846

A ISO/IEC TR 15846 é um relatório técnico internacional que fornece diretrizes
e recomendações para a gerência de configuração em projetos de tecnologia da
informação. Ela define o que é gerência de configuração e como ele deve ser aplicado
em projetos de Software e sistemas de informação (ISO, 1998).

ISO (1998) afirma que o relatório define conceitos, processos e técnicas para
garantir que as configurações sejam identificadas, controladas, documentadas e
gerenciadas ao longo do ciclo de vida do projeto. Ainda destaca a importância de garantir
a consistência e integridade das configurações ao longo do tempo, o que é fundamental
para garantir a qualidade e a eficiência dos sistemas.

O documento ISO/IEC TR 15846 não é caracterizado como uma norma, conforme

os conceitos de Coelho (2007), mas como um relatório técnico que define os requisitos
necessários para que o processo de Gerenciamento de Configuração de Software,
apresentado na norma ISO/IEC 12207, possa ser implantado em uma Organização sem,
contudo, definir uma forma de realizar esta implementação.

O processo definido pelo relatório técnico ISO/IEC TR 15846 e ISO/IEC 12207 se

divide nas seguintes tarefas (COELHO, 2007):

• implementação do processo;
• identificação da configuração;
• controle da configuração;
• avaliação da configuração;
• gerência de liberação e distribuição.

ISO (2017) define o processo de liberação e distribuição de versões como uma

versão autorizada de um conjunto de funcionalidades de uma aplicação, que afetam a
disponibilidade de uma nova funcionalidade ou sistema para um público com ou sem
restrição de usuários. Dessa forma, uma nova versão só poderá ser liberada para uso
após todos os testes de validação forem aplicados e aprovados.

266
 De forma complementar, ISO (1998) afirma que, para que a liberação de uma
nova versão aconteça, é preciso que um plano de dependência entre atividades do
processo de gerência de configuração seja formulado para cada nova versão (ou marco)
da aplicação. Todo processo de gerenciamento de configuração de Software deve ser
devidamente acompanhado, garantindo sua aderência ao planejamento efetuado e,
conforme necessário, promovendo a melhoria contínua de todo processo.

Acadêmico, apresentamos as principais normas voltadas para o gerenciamento

de configuração neste Tema de Aprendizagem. Percebemos o quanto as normas são
complementares e precisam estar sendo aplicadas em conjunto para garantir que todo
o processo de identificação dos itens de configuração, gerenciamento de mudança e
versionamento desses itens acontecerá de forma adequada às necessidades de cada
projeto.

Também apresentamos a definição de baseline (ou linha base) para os itens de

configuração e que essas definições também precisam estar devidamente versionadas
e gerenciadas, garantindo a melhoria contínua de todos os itens de configuração
envolvidos e, consequentemente, do processo e do projeto.

Aprendemos o quanto a aplicação de normas é importante como um fator de

competitividade entre as Empresas e para adoção das melhores práticas, definidas a
partir de Organizações (como a IEEE e a ISO) que buscam homogeneizar a forma como as
atividades acontecem, favorecendo, assim, o entendimento entre diferentes Empresas
que fabricam produtos de Tecnologia da Informação. Também apresentamos o padrão
MPS.BR, voltado para incentivar as Empresas de Tecnologia a produzirem Softwares de
maior qualidade.

267
 LEITURA
COMPLEMENTAR
REQUISITOS DE FERRAMENTAS DE GERENCIAMENTO DE CONFIGURAÇÃO

Viviane Nogueira Pinto de Oliveira

Resumo: Este trabalho apresenta requisitos de ferramentas de gerenciamento

de configuração, guiando a escolha e uso efetivo de tais ferramentas pela comunidade
envolvida no desenvolvimento de Software. Este artigo contextualiza a disciplina de
gerenciamento de configuração, seguindo-se com a elucidação dos requisitos.

1 INTRODUÇÃO

No processo de desenvolvimento de Software mudanças ocorrem a todo

momento. As mudanças ocorrem por inúmeras razões, tais como, novas condições de
negócios e de mercado, novas necessidades de clientes, reorganização, crescimento
ou declínio dos negócios, restrições de tempo e custo. Tudo isso pode demandar
mudanças nas prioridades do Software, na estrutura do time de desenvolvimento,
nas informações produzidas pelo Software, nos requisitos de produto e nas regras de
negócio (PRESSMAN, 2001, p. 254).

Nesse contexto, surge o Gerenciamento de Configuração de Software (GCS)

como uma disciplina da engenharia de Software que é responsável pelo desenvolvimento
da gerência da mudança durante todo o ciclo de vida do Software (PRESSMAN, 2001, p.
255). O GCS é uma das ramificações mais sucedidas da engenharia de Software, tanto
que é atualmente considerado uma ferramenta essencial para o sucesso de qualquer
projeto de desenvolvimento de Software, sendo necessário para o atendimento do
segundo nível de maturidade do CMM (ESTUBLIER, 2002, p. 5). Facilidades para acomodar
mudanças, maior controle sobre os produtos e economia de tempo de desenvolvimento
são alguns dos benefícios da adoção da GCS, no entanto é importante considerar
também os custos associados, tais como treinamento e recursos computacionais (ITI,
2001, p. 22).

O GCS engloba as atividades de identificação da mudança, controle da mudança,

garantia de efetividade da implementação da mudança e divulgação das mudanças
para outros interessados (PRESSMAN, 2001, p. 253).

[...]

268
 Existem diversas ferramentas de GCS disponíveis no mercado, sendo que a
maioria possui foco no controle de versões e controle de liberações de arquivos-fonte,
negligenciando outros requisitos importantes do GCS; um exemplo é a atividade de
auditagem de configuração que tem recebido pouca atenção (CHAN; HUNG 1997), o qual
é um aspecto a ser tratado neste trabalho. A comunidade envolvida em processos de
desenvolvimento de Software em geral, tais como especificadores, implementadores,
testadores, arquitetos de Software etc., são os principais interessados neste trabalho,
no qual serão estabelecidas necessidades, restrições e expectativas em relação às
ferramentas de gerenciamento de configuração.

[...]

2 MODELOS E CARACTERÍSTICAS DE GERENCIAMENTO DE CONFIGURAÇÃO

[...]

O gerenciamento de configuração surgiu da necessidade de se controlar

mudanças ocorridas durante todo o processo de desenvolvimento de Software. O GCS
controla a evolução e integridade do produto pela identificação de seus elementos,
gerenciando e controlando mudança, verificando, gravando e reportando informação
de configuração.

As atividades de gerenciamento de configuração de Software são identificação,

controle, administração do estado, auditagem e gerenciamento de liberações e entrega
da configuração do Software. Estas atividades devem ser planejadas inicialmente,
provendo assim um plano a ser seguido durante todo o processo de GCS (SWEBOK,
2004, p. 108). Algumas características e considerações do processo de gerenciamento
de configuração serão apresentadas a seguir.

2.1 PLANEJAMENTO DO GCS (IEEE, 1987, p. 17-23)

Um efetivo processo GCS envolve planejamento de atividades a serem

executadas, o qual é essencial para o seu sucesso. O planejamento da GCS deve ser
consistente com o contexto organizacional, assim considerando as restrições e a
natureza do projeto. No planejamento são identificados responsabilidades, ferramentas,
cronogramas, marcos dos projetos, requisitos de treinamento. Também são planejados a
seleção e implantação de ferramentas, subcontratação, estabelecimento de interfaces
e dependências.

Ao final do planejamento é gerado um documento que servirá de base para todo

o processo de GCS, chamado Plano de Gerenciamento de Configuração de Software,
contendo escopo, propósito, definições e referências.

269
 2.2 IDENTIFICAÇÃO DOS ITENS

O processo de desenvolvimento de Software gera inúmeras saídas, que devem

ser identificadas para o estabelecimento da configuração inicial do Software. Exemplos
de itens de configuração, também denominados entidades, são (IEEE, 1987, p. 10):

• planos de gerenciamento;
• especificações de requisitos e desenho;
• documentação de usuário;
• projetos de teste, casos de teste;
• software de suporte;
• dicionários de dados;
• código-fonte;
• código executável;
• bibliotecas;
• bases de dados com dados processados ou aqueles que são parte de um programa;
• documentação de manutenção.

As ferramentas utilizadas na construção do Software também são itens

de configuração, pois elas são usadas para produzir artefatos do processo de
desenvolvimento de Software. Elas precisam ser controladas, pois também podem
ocorrer mudanças em suas versões (PRESSMAN, 2001, p. 229).

[...]

2.3 CONTROLE

Uma mudança normalmente se inicia com uma requisição. Uma pessoa ou um

time avalia a requisição, aprovando ou não a mudança. Se a mudança for aprovada, ela
é implementada, testada e então solucionada (ESTUBLIER, 2002, p. 13).

[...]

A atividade de controle é fortemente facilitada pelo uso de ferramentas que

proporcionam benefícios, por exemplo, rastreamento de soluções para problemas
reportados durante o processo de requisição de mudança e versionamento dos códigos
fonte no processo de implementação da mudança.

2.4 ADMINISTRAÇÃO DE ESTADO

Esta atividade visa o controle do estado da configuração do Software, por

meio da coleta de informações e a geração de relatórios. Pode ser comparada com um
sistema de contas, no qual muitos dos conceitos usados para rastrear o fluxo de fundos

270
através das contas podem ser usados para rastrear o fluxo de Software através de sua
evolução. O objetivo desta atividade é basicamente reportar transações que ocorrem
entre entidades controladas pelo GCS (IEEE, 1987, p. 30).

[...]

2.5 AUDITAGEM

Esta atividade está relacionada à verificação da conformidade dos produtos

e processos de Software aos padrões, guias, planos e procedimentos estabelecidos
(SWEBOK, 2004, p. 114). Dentre outras funções, verifica-se se itens de configuração
identificados estão presentes na linha de base e se cada um deles satisfaz as funções
definidas na especificação ou contrato para o qual foi desenvolvido (IEEE, 1987, p. 32).

O processo de desenvolvimento de Software deve ser verificado, validado por

meio de revisões formais e inspeções executadas em arquivos de código e documentos
(CHAN; HUNG, 1997).

2.6 GERENCIAMENTO E ENTREGA DE LIBERAÇÕES

O processo de integração do Software (building Software) e gerenciamento de

liberações são funções executadas nesta atividade do GCS. O processo de integração
do Software provê a combinação de versões de itens de configuração, usando dados
apropriados de configuração em um programa executável para entrega ao cliente
ou a outra atividade do processo de desenvolvimento, tal como a atividade de teste
(SWEBOK, 2004, p. 114).

Este processo executa passos numa sequência definida, permitindo assim

reproduzir um executável de uma versão anterior. Exemplos de ferramentas usadas
nesse processo são os compiladores (SWEBOK, 2004, p. 114).

[...]

2.7 CONTROLE DE VERSÕES

Controle de versões é usado no suporte à proliferação de itens gerados no

processo de desenvolvimento de Software, provendo o gerenciamento deles, gravando
seus relacionamentos e suas propriedades comuns (ESTUBLIER, 2002, p. 3). Controle
de versões combina procedimentos e ferramentas para gerenciar diferentes versões de
objetos de configuração que são criados durante o processo de Software, as quais são
identificadas por meio de atributos específicos. Um exemplo de atributo é o número da
versão que é guardado juntamente com o objeto. Exemplos de objetos foram citados
na seção 2.2.

271
 [...]

Existem muitos mecanismos que formam o controle de versões, ou seja, devem

ser providos para o eficiente gerenciamento de configuração. O controle de versões será
apresentado como um requisito de ferramentas de gerenciamento de configuração,
posteriormente.

3 REQUISITOS DE FERRAMENTAS

Para o controle efetivo e apoio às atividades relacionadas à mudança, o uso de

ferramentas é de suma importância. Existem ferramentas de GCS específicas para cada
tipo de atividade, por exemplo, para um efetivo processo de requisição de mudança
de Software é importante o uso de ferramentas de suporte para o recebimento de
requisições e o fluxo de processo de mudança, capturando decisões gerenciais e
reportando informações. Já na implementação da mudança as ferramentas utilizadas
são aquelas de suporte ao controle de versão e suporte ao armazenamento de código
(SWEBOK, 2004, p. 113).

O processo de seleção de uma ferramenta faz parte do processo de planejamento

visto na seção 2.1, no qual diversos fatores devem ser levados em consideração
(SCHAMP, 1995).

[...]

3.1 CONTROLE DE VERSÕES

O controle de versões em uma ferramenta deve prover basicamente mecanismos

de ramificação (branching), fusão (merge) e trancamento (locking), os quais são
inerentes ao conceito de versionamento, proporcionando comparação e impressão de
diferenças em versões do mesmo item de configuração (CHANG; HUNG 1997).

Alguns mecanismos serão mais bem exemplificados e outros que devem ser
suportados pela ferramenta serão apresentados a seguir:

• Ramificação (branching): A ferramenta deve prover a ramificação de objetos de

configuração. Mudanças em um objeto de configuração podem ocorrer paralelamente
a outras modificações e não sequencialmente. [...]
• Fusão (merge): A ferramenta deve prover a fusão dos objetos de configuração. [...]
• Diferenciação: A ferramenta deve prover a comparação de diferentes versões de
um mesmo objeto, pois é de grande utilidade para analisar mudanças realizadas em
sistemas complexos (SCHAMP, 1995).
• Compressão: A ferramenta deve prover esse mecanismo para o melhor uso do
espaço utilizado para o armazenamento de versões de itens (CHAN; HUNG, 1997).

272
• Check-in/check-out: A ferramenta deve suportar o mecanismo Check-in/check-
out. Antes de começar a trabalhar num item, o desenvolvedor executa um check-
out. [...]
• Hierarquia: A ferramenta deve organizar os arquivos em grupos que suportam as
visões dos projetos (SCHAMP, 1995).
• Controle de liberações: A ferramenta deve fornecer um mecanismo de identificação
de versões marco do sistema. [...]
• Marcação de versões: A ferramenta deve marcar de liberações do Software, sendo
de grande importância para o paralelismo em um ambiente (SCHAMP, 1995).
• Armazenamento de diferentes tipos de arquivos: A ferramenta deve permitir o
versionamento de arquivos com diferentes tipos e não apenas textuais (SCHAMP,
1995).
• Trilha de auditagem: A ferramenta deve gravar as atividades executadas em itens de
configuração sobre o controle de versões (SCHAMP, 1995).
• Controle de acesso: A ferramenta deve limitar ações de usuários não autorizados.
[...]
• Relacionamentos entre itens: A ferramenta deve suportar o registro de atributos e
relacionamentos entre objetos. Os relacionamentos permitem verificar o que pode
ser afetado se uma mudança no item ocorrer. [...]

3.2 INTEGRAÇÃO DE Software (BUILDING)

A ferramenta deve prover suporte à integração de Software (building), ou seja,

deve permitir que itens adequados sejam integrados, compilados e combinados para a
sua liberação.

• A ferramenta deve possuir integração com o controle de versões, ou seja, a

integração de Software deve referenciar os itens identificados para cada liberação
(SCHAMP, 1995).
• A ferramenta deve prover a integração de itens para múltiplos ambientes (SCHAMP,
1995).
• A ferramenta deve possuir mecanismo de geração automática de procedimentos
(scripts) (SCHAMP, 1995).

Este requisito se justifica pela automatização das tarefas relacionadas com a

compilação do Software de forma a produzir um sistema de Software e geração de
arquivos executáveis para colocá-lo em produção ou para outra destinação (SCHAMP,
1995).

[...]

273
 3.4 CONTROLE DE MUDANÇAS (ESTUBLIER, 2002, p. 13)

• A ferramenta deve prover suporte ao controle de mudanças, ou seja, os fluxos da

mudança devem ser registrados e acompanhados por meio da ferramenta.
•
• A ferramenta deve prover o controle das informações de estados da mudança, tais
como, requisitada, rejeitada, adiada, verificada, atribuída, resolvida e concluída.
• A ferramenta deve prover o armazenamento da requisição em um banco de dados.
• A ferramenta deve prover o registro e acompanhamento dos relacionamentos entre
a requisição e as mudanças atuais ocorridas no repositório de itens de configuração.

[...]

Fonte: adaptada de https://docplayer.com.br/5517655-Requisitos-de-ferramentas-de-gerenciamento-de-

-configuracao.html. Acesso em: 4 fev. 2023.

274
 RESUMO DO TÓPICO 3
Neste tópico, você aprendeu:

• O modelo MPS.BR, baseado nas principais normas internacionais, foi criado

para facilitar o processo de implantação da melhoria contínua em processos de
construção de Software por empresas brasileiras, aumentando sua competitividade
no mercado local e global.

• O modelo MPS.BR é divido em sete níveis de maturidade organizacional, sendo que,

quanto maior o nível de aderência de uma Empresa às normas apresentadas pelo
modelo, maior será sua possibilidade de alcançar níveis de certificação mais altos e
se destacarem no mercado, perante os concorrentes.

• O modelo CMMI não apresenta uma forma prática de implementação de suas

diretrizes, apesar de ditar normas importantes para a implantação e avaliação do
processo de maturidade de uma Organização para a construção de produtos de TI.

• A normas técnicas são importantes para garantir boas práticas já definidas por
membros experientes das principais instituições internacionais, como a IEEE e ISO,
garantindo competitividade para as Empresas que delas fizerem uso e melhoria
contínua nas etapas dos processos de gerenciamento de configuração, construção
e manutenção de Softwares dentre outras áreas importantes da Tecnologia da
Informação.

• As normas voltadas para o gerenciamento de configurações auxiliarão na

implantação de um processo de identificação dos itens de configuração que deverão
ser gerenciados, definição do padrão de nomenclatura para as versões e definição
do processo de controle de versão e liberação de novas releases para o usuário final.

275
 AUTOATIVIDADE
1 Uma baseline ou linha base é um conceito importante tanto para o controle de versão
de uma aplicação quanto para o controle dos itens de configuração de um projeto.
Com base em seus conhecimentos sobre baselines e itens de configuração, assinale
a alternativa CORRETA:

a) ( ) Uma baseline representa uma versão entregue de apenas um item de

configuração da aplicação.
b) ( ) Uma baseline só é definida para as configurações utilizadas pela equipe de
desenvolvimento, como código fonte e os requisitos das funcionalidades que
serão implementadas.
c) ( ) Uma baseline representa um controle de garantia de qualidade da aplicação.
d) ( ) Uma baseline representa um conjunto dos itens de configuração aprovados e
com o intuito de promover a melhoria contínua dos processos.

2 A norma IEEE STD 828/1998 é focada no planejamento do gerenciamento de

configurações de Software, apresentando as principais diretrizes para o processo ser
feito de forma eficiente e eficaz pelas Empresas de Tecnologia da Informação. Com
base em seus conhecimentos sobre esta norma, analise as sentenças a seguir:

I- Uma das atividades essenciais ao processo de gerenciamento de configuração de

Software é a geração de relatórios sobre as mudanças efetuadas em um item de
configuração.
II- A norma IEEE STD 828/1998 apresenta uma forma prática de implantação do
processo de gerenciamento de configurações em uma Organização.
III- O padrão de nomenclatura utilizado para identificar unicamente um item de
configuração não representa um item de responsabilidade desta norma.

Assinale a alternativa CORRETA:

a) ( ) As sentenças I e II estão corretas.

b) ( ) Somente a sentença I está correta.
c) ( ) As sentenças I e III estão corretas.
d) ( ) Somente a sentença III está correta.

3 As atividades específicas do processo de gerenciamento de configurações de Software

são definidas pela norma IEEE STD 1042/1986. De acordo com seus conhecimentos
sobre esta norma técnica, classifique V para as sentenças verdadeiras e F para as
falsas:

276
( ) A norma indica a elaboração de um plano de gerenciamento de configuração de
Software.
( ) A norma não fala sobre a distribuição de responsabilidades entre os membros do
time de desenvolvimento, por não ser uma tarefa pertencente ao processo de
gerenciamento de configurações.
( ) Uma liberação só acontecerá com baselines criadas nos últimos 30 dias.

Assinale a alternativa que apresenta a sequência CORRETA:

a) ( ) V – F – F.
b) ( ) V – F – V.
c) ( ) F – V – F.
d) ( ) F – F – V.

4 Normas técnicas são importantes para que se conheçam as melhores práticas

do mercado para um determinado setor ou serviço. Com o gerenciamento de
configurações não é diferente. Para que o processo seja executado seguindo
as etapas já consolidadas e obtendo os resultados esperados, normas técnicas
podem ser utilizadas como balizadoras. Explique como as normas voltadas para o
gerenciamento de configurações podem cooperar entre si para a implantação do
processo em uma Organização.

5 As normas técnicas focadas no processo de gerenciamento de configuração definem,

não só os processos, mas conceitos importantes para que haja um entendimento global
acerca dos conceitos e etapas que devem acontecer para que o gerenciamento de
configurações seja realizado com êxito. Nesse contexto, disserte sobre a importância de
se definir uma baseline para itens de configuração.

277
 REFERÊNCIAS
ANDERSON, D. J. Kanban – Mudança Evolucionária de Sucesso para Seu Negócio
de Tecnologia. Sequim: Blue Hole Press, 2011.

APACHE. Apache Subversion, 2022. Controle de versão centralizado de classe em-

presarial para as massas. Disponível em: https://subversion.apache.org/. Acesso em:
22 jan. 2023.

ARROSI, R. Team Foundation Server 2010 aplicado ao MPS.BR Nível F. 2013,

121 p. TCC (Bacharel em Ciência da Computação) – Universidade de Caxias do Sul,
Caxias do Sul, 2013. Disponível em: https://repositorio.ucs.br/xmlui/bitstream/hand-
le/11338/1503/TCC%20Reinaldo%20Arrosi.pdf?sequence=1&isAllowed=y. Acesso em:
10 fev. 2023.

ARUN, R. Simple Learn, c2023. What is Trello and How To Use It? Disponível em: ht-
tps://bit.ly/41d9ZWj. Acesso em: 28 mar. 2023.

ATLASIAN. Atlassian, 2022. O que é GIT? Disponível em: https://www.atlassian.com/

br/git/tutorials/what-is-git#version-control-with-git. Acesso em: 22 jan. 2023.

ATLASSIAN. Atlassian, 2023. Jira Software, 2023. Disponível em: https://bit.ly/3ZMrvij.

Acesso em: 25 jan. 2023.

BACIM, S. C. Plano de Projeto: processo de gerenciamento e controle de demandas

utilizando a biblioteca de boas práticas ITIL, 2016, 108 p. Dissertação (MBA em Gestão
de Projetos) – Universidade Vale do Rio dos Sinos, São Leopoldo, 2016. Disponível em:
https://bit.ly/41l0HaD. Acesso em: 8 fev. 2023.

BECK, K. et al. Manifesto para Desenvolvimento Ágil de Software, 2001. Disponível

em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 29 dez. 2022.

BIGGS, M. Infoword, 2004. TeamTrack keeps the business processes flowing. Disponí-
vel em: https://www.infoworld.com/article/2666505/TeamTrack-keeps-the-business-
-processes-flowing.html. Acesso em: 10 fev. 2023.

BITKEEPER. BitKeeper, 2023. Why use BitKeeper when there are lots of great alter-
natives? 2023. Disponível em: https://www.BitKeeper.org/why.html. Acesso em: 9 fev.
2023.

BONILLA, O. BitKeeper, 2015. The Advantages and Disadvantages of Monolithic,

Multiple, and Hybrid Repositories. Disponíve em: https://www.bitkeeper.org/BK_Nest-
ed_White_Paper.pdf. Acesso em: 5 abr. 2023.

278
BUGZILLA. Bugzilla, 2023. About – What is Bugzilla? Disponível em: https://www.Bug-
zilla.org/about/. Acesso em: 8 fev. 2023.

BROWN, J. et al. Software Configuration Management: A ClearCase for IBM Ratio-

nal ClearCase and ClearQuest UCM. [S. l.]: IBM Red book, dec., 2004.

CAROLI, P. Lean inception: como alinhar pessoas e construir o produto certo. 1. ed.
Atualizada. São Paulo: Editora Caroli, 2018.

CHACON, S.; STRAUB, B. Pro GIT, 2. ed. [S. l.]: Apress, 2022. E-book. Disponível em:
https://git-scm.com/book/en/v2. Acesso em: 23 jan. 2023.

CMMI. CMMI para Desenvolvimento – Versão 1.2. Pittsburgh, PA: CMU/

SEI-2006. Disponível em: https://resources.sei.cmu.edu/asset_files/WhitePa-
per/2006_019_001_28945.pdf. Acesso em: 2 fev. 2023.

COELHO, F. H. M. S. Processo de gerência de configuração de software. 2007, 41

p. Monografia (Curso de Engenharia de Computação) – Universidade São Francisco,
Itatiba, SP, 2007. Disponível em: https://lyceumonline.usf.edu.br/salavirtual/documen-
tos/1079.pdf. Acesso em: 11 fev. 2023.

CORRÊA, A. P.; GREIN, D. R.; PISKE, O. R. Sistemas de Controle de Versão, 2005.

Disponível em: http://www.angusyoung.org/arquivos/artigos/sistemas_de_contro-
le_de_versao.pdf. Acesso em: 9 fev. 2023.

CUNHA, J. R. dell D. et al. Uma Abordagem para o Processo de Gerenciamento de

Configuração de Software. Resi – Revista elet. de sist. de inf., [s. l.], v. 3, n. 1, 2004.
Disponível em: http://www.periodicosibepes.org.br/index.php/reinfo/article/view/145.
Acesso em: 10 abr. 2023.

DAVIS, A. M.; RIEMENSCHNEIDER, T. A. Information Systems Development: Bu-

siness Systems and Services: Modeling and Development. Boca Raton: CRC Press,
2008.

DOCKER. Docker telepresence, c2023. Use containers to Build, Share and Run your
applications, 2023. Disponível em: https://www.docker.com/resources/what-contai-
ner/. Acesso em: 10 fev. 2023.

DYNAMSOFT. Reasons to Switch from SourceSafe: How to Make Your Life Easier
with SourceAnywhere Standalone, 2007. Disponível em: https://www.dynamsoft.com/
products/Reasons%20to%20Switch%20from%20SourceSafe%20(SourceAnywhe-
re%20Standalone).pdf. Acesso em: 9 fev. 2023.

DEVMEDIA. Devmedia, 2012. Trac: Gerência de configuração e mudanças. Disponível

em: https://bit.ly/43FAnJR. Acesso em: 6 abr. 2023.

279
 FERREIRA, M. A. O.; CAGNIN, M. I. Proposta de um Modelo de Referência de Gerência de
Configuração para um Processo de Reengenharia baseado em Framework, In: Simpó-
sio Brasileiro de Sistemas de Informação. 3., Curitiba, PR, nov. 2006. Anais [...] Curitiba,
PR: Univem, 2006. Disponível em: https://sol.sbc.org.br/index.php/sbsi/article/downlo-
ad/14748/14593. Acesso em: 11 fev. 2023.

FREITAS, D. T. M. Análise Comparativa entre Sistemas de Controle de Versões,

2010, 56 p. Monografia (Bacharelado em ciência da computação) – Universidade Fede-
ral de Juiz de Fora, Juíz de Fora, MG, 2010. Disponível em: https://www.academia.edu/
download/45326396/Analise-Comparativa-entre-Sistemas-de-Controle-de-Versoes-
-Daniel-Tannure-Menandro-de-Freitas.pdf. Acesso em: 22 jan. 2023.

GERALDES, N. A. S. Gestão de Desenvolvimento de Software na área da Produ-

ção de Conteúdos Audiovisuais, 2011, 82 p. Dissertação (Mestrado Integrado em
Engenharia Electrotécnica e de Computadores) – Faculdade de Engenharia da Univer-
sidade do Porto, Porto, Porutgal, 2011. Disponível em: https://repositorio-aberto.up.pt/
bitstream/10216/61590/1/000148331.pdf . Acesso em: 8 fev. 2023.

GIANNONE, D. et al. Quality Assurance and Safety Conformity for the 4-metre
Multi-Object Spectroscopic Telescope (4MOST) Project, 2018. Disponível em:
http://www.eso.org/sci/libraries/SPIE2018/10702-264.pdf. Acesso em: 11 fev. 2023.

GNU. CVS – Concurrent Versions System v1.11.23, 2023. Disponível em: https://
www.gnu.org/ Software/trans-coord/manual/cvs/cvs.html#What-is-CVS_003f. Aces-
so em: 23 jan. 2023.

GONÇALVES, J. V. C. Gestão de configurações num processo de desenvolvimen-

to de Software – análise de uma situação real, 2008. Relatório de Projeto do MIEIC
2007/2008. (Mestrado Integrado em Engenharia de Informática e Computação) – Fa-
culdade de Engenharia da Universidade do Porto, Porto, 2008. Disponível em: https://
repositorio-aberto.up.pt/bitstream/10216/57850/5/DIGITOOL_FEUP_43050.pdf.
Acesso em: 8 fev.2023.

HECKLER, L. F. Redmine GCO: uma ferramenta de apoio. 2009, 56 p. TCC (Bachare-

lado em Ciência da Computação) – Universidade Federal do Rio Grande do Sul, Porto
Alegre, 2009.

HENSON, V.; GARZIK, J. BitKeeper for Kernel Developers, 2002. Disponível em:
https://www.kernel.org/doc/ols/2002/ols2002-pages-197-212.pdf. Acesso em: 9 fev.
2023.

HRISTOVSKI, T. Linkendin, 2017. Why Jira is #1 Software Development Tool for Agile
Teams? Disponível em: https://www.linkedin.com/pulse/why-jira-1-software-develop-
ment-tool-agile-teams-tome-hristovski/. Acesso em: 28 mar. 2023.

280
HUMBLE, J.; FARLEY, D. Entrega Contínua: como entregar Software de forma rápida
e confiável. Porto Alegre: Bookman, 2014.

HUMPHREY, W. S. A Discipline for Software Engineering. Chicago: Addison-Wesley

Professional, 2005.

IANCU, L. QA Quality Assurance & Software Testing Fundamentals, 2018. Edição

do Kindle. E-book.

IBM. Software support discontinuance: IBM Rational Synergy 7.2.x and IBM
Rational Change 5.3.x; Software withdrawal and support discontinance: Select
IBM Rational Synergy and Change Suite 7.2.x part numbers, 2022. Disponível em: ht-
tps://www.ibm.com/downloads/cas/AP-ENUSWP22-0007-CA/name/AP-ENUSWP22-
0007-CA.PDF. Acesso em: 10 fev. 2023.

IBM. IBM, c2023. IBM Rational Synergy, 2023. Disponível em: https://www.ibm.com/
products/rational-synergy. Acesso em: 10 fev. 2023.

IEEE. Guide to Software Configuration Management. ANSI/IEEE Std., [s. l.], p.1-93, 12
set. 1988. Disponível em: https://ieeexplore.ieee.org/document/89631. Acesso em: 10
abr. 2023.

IEEE. Standard for Software Configuration Management Plans. IEEE Std., [s. l.], v., n.,
p.1-24, 27 out. 1998. Disponível em: https://ieeexplore.ieee.org/document/720569.
Acesso em: 10 abr. 2023.

IEEE. IEEE SA, c2023. Developing Standards. Disponível em: https://standards.ieee.

org/develop/. Acesso em: 11 fev. 2023.

IONICĂ, A. Facts About The Relationship Between The Project Management (Pm) And
The Quality Management (Qm) In Compliance With The Present Standards. Annals of
the University of Petroşani, Economics, [s. l.], v. 5, p. 169-172, 2005. Disponível em:
https://www.academia.edu/download/32713624/Annals-2005.pdf#page=169. Acesso
em: 11 fev. 2023.

ISACA. Isaca, 2013. CMMI. Disponível em: https://cmmiinstitute.com/cmmi. Acesso em:

29 mar. 2023.

ISO. ISO, 1998. Information technology – Software life cycle processes – Configuration
Management – ISO/IEC TR 15846, 1998. Disponível em: https://www.iso.org/stan-
dard/30516.html. Acesso em:

ISO. ISO, 2017. Quality management — Guidelines for configuration management – ISO
10007, 2017. Disponível em: https://www.iso.org/standard/70400.html. Acesso em: 10
abr. 2023.

281
 ISO STANDARDS. ISO, 2023. Benefits of standards. Disponível em: https://www.iso.org/
benefits-of-standards.html. Acesso em: 30 jan. 2023.

JENKINS. Jenkins, 2023. Pipeline. Disponível em: https://www.jenkins.io/doc/book/

pipeline/. Acesso em: 8 fev. 2023.

JÚNIOR, W. M. P.; JÚNIOR, J. L. A. F.; SILVA, L. P. um estudo dos processos de ciclo de

vida de Software a partir da norma ISO 12207. Intercursos Revista Científica, [s. l.],
v. 8, n. 2, jul./dez. 2009. Disponível em: https://revista.uemg.br/index.php/intercursos-
revistacientifica/article/view/2317/1269. Acesso em: 11 fev. 2023.

KALINOWSKI, M. et al. MPS. BR: Promovendo a Adoção de Boas Práticas de Engenha-

ria de Software pela Indústria Brasileira. 2010. Disponível em: https://bit.ly/3MxgNcH.
Acesso em: 10 fev. 2023.

KUBERNETES. Kubernetes, 2023. Orquestração de contêineres prontos para produ-

ção, 2023. Disponível em: https://kubernetes.io/pt-br/. Acesso em: 30 jan. 2023.

LONGUINHO, A. G. Gerenciamento de projetos com Software livre: uso do Red-

mine em projetos “não – Software” para leigos em gerenciamento de projetos, 2014.
Disponível em: https://bit.ly/3Kg6G9p. Acesso em: 8 fev. 2023.

MARINHO, A. N. Metodologias ágeis: um ensaio comparativo acerca do método

Kanban e o framework Scrum. 2020, 56 f. TCC (Bacharelado em Administração) –Fa-
culdade de Administração e Ciências Contábeis, Universidade Federal do Rio de Janei-
ro, Rio de Janeiro, 2020.

MAXIMIANO, A. C. A.; VERONEZE, F. Gestão de Projetos – Preditiva, ágil e estraté-

gica. 6. ed. Barueri: Atlas, 2022.

MEDEIROS, G. C. Gerência de Configuração de Software: Análise prática de siste-

mas de Controle de Versão. 2016, 199p. TCC (Graduação em Ciência da Computação)
– Universidade do Sul de Santa Catarina, Palhoça, 2016. Disponível em: https://repo-
sitorio.animaeducacao.com.br/bitstream/ANIMA/11147/1/TCC_Guilherme_Francisco.
pdf. Acesso em: 6 fev. 2023.

MICROSOFT. Team Development with Visual Studio Team Foundation Server.

2007. Disponível em: https://www.assamrifles.gov.in/DOCS/ApplicationForm/tfsgui-
de2007-08-022.pdf. Acesso em: 10 fev. 2023.

MICRO FOCUS. Micro Focus, 2019. What’s new – StarTeam. Disponível em: https://ad-
mhelp.microfocus.com/starteam/en/latest/online/Content/GetStarted/wn_17.1.htm.
Acesso em: 10 fev. 2023.

282
MICRO FOCUS. Micro Focus, 2023a.Serena Is Now Part of Micro Focus. Disponível em:
https://www.microfocus.com/en-us/products/serena/overview. Acesso em: 10 fev.
2023.

MICRO FOCUS. Micro Focus, 2023b. StarTeam. Disponível em: https://www.microfo-

cus.com/pt-br/products/starteam/overview. Acesso em: 10 fev. 2023.

MURTA, L. G. P. Gerência de configuração no desenvolvimento baseado em com-

ponentes, 2006, 229 p. Tese (Pós-graduação em Engenharia) – Universidade Federal
do Rio e Janeiro, Rio de Janeiro, 2006. Disponível em: https://cos.ufrj.br/uploadfile/
publicacao/2043.pdf. Acesso em: 11 fev. 2023.

MOURA, M.; NASCIMENTO, H. do. Gerenciamento de Projeto com o Redmine. (apresen-

tação). Goiânia: Centro de Recursos Computacionais Universidade Federal de Goiás,
2009.

NETO, P. F. J. Sistema de Garantia da Qualidade para o Sistema Integrado de

Gestão Académica Fénix. 2022, 90 p. TCC (Mestrado em Engenharia Informática)
– Universidade de Lisboa, Lisboa, 2022. Disponível em: https://repositorio.ul.pt/bitstre-
am/10451/53719/1/TM_Jo%C3%A3o_Neto.pdf. Acesso em: 10 abr. 2023.

OLIVEIRA, S. B.; VIANNA, D. S.; TANAKA, A. K. Avaliação de Ferramentas para Con-

trole Automatizado de Versões de Artefatos e Requisitos de Software, 2006.
Disponível em: https://bit.ly/3Kcc3qd. Acesso em: 9 fev. 2023.

OLIVEIRA, V. N. P. Requisitos de Ferramentas de Gerenciamento de Configura-

ção, 2007. Disponível em: https://homepages.dcc.ufmg.br/~rodolfo/dcc823-2-07/
Entrega4/Viviane4.pdf. Acesso em: 5 fev. 2023.

PACHECO, R. F.; SANCHES, R. Gerenciamento de Configuração de Software.

Relatórios técnicos do ICMSC. São Carlos: Dedalus/acervo ICMSC, 1997. Disponível
em: https://repositorio.usp.br/bitstreams/c490ac0a-af15-4089-8c91-9c3a90d479cd.
Acesso em: 08/02/2023.

PAVÃO, I. C. Gestão de Qualidade para Testes de Software conforme NBR ISO/

IEC 12207, 2009, 102 p. Dissertação (Mestrado em Informática) – Universidade Ca-
tólica de Santos, Santos, 2009. Disponível em: https://tede.unisantos.br/bitstream/
tede/604/1/Ivan%20Carlos%20Pavao.pdf. Acesso em: 11 fev. 2023.

PIZZAIA, V. H.; MALARA, R. D. Garantia da Qualidade de Software com DEVOPS. Reci-

ma21 –revista científica multidisciplinar, [s. l.], v. 3, n. 11, p. 1-13, 2022. Disponível
em: https://recima21.com.br/index.php/recima21/article/view/2193. Acesso em: 7 fev.
2023.

283
 PONTES, R. M. STONE: um processo de gerência de configuração de Software para
projetos acadêmicos, 2019, 91 p. Monografia (Graduação em Engenharia de Software) –
Universidade Federal do Ceará, Russas, CE, 2019. Disponível em: https://repositorio.ufc.
br/bitstream/riufc/49802/1/2019_tcc_rmpontes.pdf. Acesso em: 4 fev. 2023.
PRESSMAN, R. S. e MAXIM, B. R. Engenharia de Software: uma abordagem profissio-
nal. 9. ed. Porto Alegre: AMGH, 2021.

PRIMO, R. Um estudo sobre processo de desenvolvimento de Software livre: o

caso do Word Press. Rio de Janeiro: COPPE/UFRJ, 2014. Disponível em: https://rodrigo.
utopia.org.br/files/Monografia_RodrigoPrimo.pdf. Acesso em: 8 fev. 2023.

QUEMELLO, L. J.; MANDUCA, A. M.; FORTES, R. P. M. Uma introdução ao Bugzilla.

Relatórios técnicos, São Carlos: USP/ICMC, 2005. Disponível em: https://repositorio.
usp.br/directbitstream/91b8eea1-400f-4e1c-8148-c45560eedf21/relatorio_253.pdf.
Acesso em: 8 fev. 2023.

RATIONAL. ClearCase Reference Manual – Release 4.1 and later, 2000. Disponível
em: http://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/software/rational/docs/
documentation/manuals/cc42unix/cc_ref_1.ux.pdf. Acesso em: 9 fev. 2023.

RECKLER, L. F. Redmine GCO: uma ferramenta de apoio para a Gerência de Configura-

ção, 2009. Disponível em: https://www.lume.ufrgs.br/handle/10183/18537. Acesso em:
8 fev. 2023.

REDHAT. Redhat, 2021. O que é conteinerização? Disponível em: https://www.redhat.

com/pt-br/topics/cloud-native-apps/what-is-containerization. Acesso em: 30 jan.
2023.

REDHAT. Redhat, 2022. Introdução ao DevOPs. Disponível em: https://www.redhat.

com/pt-br/topics/devops. Acesso em: 30 jan. 2023.

REDHAT. Redhat, 2023. O que é CI/CD? Disponível em: https://www.redhat.com/pt-br/

topics/devops/what-is-ci-cd. Acesso em: 29 jan. 2023.

ROCHA, D. P.; SOUSA, J. C. Gestão da Qualidade: A Importância do Método Kanban

como Ferramenta Gerencial. Id on Line Rev. Mult. Psic. [s. l.], v. 15, n. 55, p. 449-
468, maio 2021. Disponível em: https://idonline.emnuvens.com.br/id/article/
view/3085/4793. Acesso em: 6 fev. 2023.

ROSS, R. Pitfalls and Tips on Using ClearCase clearfsimport, 2011. Disponível em:
https://www.spkaa.com/wp-content/uploads/2013/12/SPK_clearfsimport.pdf. Acesso
em: 9 fev. 2023.

RODRIGUES, B. R. O2B, 2020. Simplificando suas pipelines Jenkins com Shared Libra-
ries. Disponível em: https://bit.ly/3of1b3r. Acesso em: 10 abr. 2023.

284
SAMPAIO, E. C. da. Uma abordagem para ajustar o controle de versão à natureza
das aplicações web. 2021, 84 p. TCC (Bacharelado em Ciência da Computação) –
Universidade Federal do Amapá, Macapá, 2021.

SANTOS, P. C. Quatro grandes alternativas ao MS Project para gestão de projetos. Blog

da engenharia, 2021. Disponível em: https://blogdaengenharia.com/secoes/colunis-
tas-blog-da-engenharia/quatro-grandes-alternativas-ao-ms-project-para-gestao-
-de-projetos/. Acesso em: 25 jan. 2023.

SANTOS, C. A. da S.; HOFFMANN, W. A. M. Gestão do conhecimento no instituto federal

de são paulo – campus araraquara: proposta de utilização do software Redmine como
ferramenta para gestão, armazenamento e compartilhamento da informação. Páginas
a&b: arquivos e bibliotecas, [s. l.], p. 98–114, jul. 2016.

SERENA. Serena TeamTrack, 2006. Process Creates Success. Disponível em: https://
www.yumpu.com/en/document/read/34777136/serena-TeamTrack-serena- Software.
Acesso em: 10 fev. 2023.

SILVA, J. B.; ANASTÁCIO, F. A. M. Método Kanban como Ferramenta de Controle de

Gestão. Id on Line Rev. Mult. Psic. [s. l.], v. 13, n. 43, p. 1018-1027, 2019. Disponível em:
https://scholar.archive.org/work/ezcjg7wlqza3pln4jfc5i6hc7i/access/wayback/https://
idonline.emnuvens.com.br/id/article/download/1575/2325. Acesso em: 6 fev. 2023.

SOFTEX. Guia de Implementação – Parte 2: Fundamentação para Implementação

do Nível F do MR-MPS-SV:2012, 2013. Disponível em: https://www.softex.br/wp-con-
tent/uploads/2013/07/MPS.BR_Guia_de_Implementacao_SV_Parte_2_20132.pdf.
Acesso em: 11 fev. 2023.

SOFTEX. Softex, 2021a. MPS.BR – Melhoria de Processo do Software Brasileiro. Dispo-

nível em: https://softex.br/mpsbr/. Acesso em: 10 fev. 2023.

SOFTEX. Softex, 2021b. Guia de Avaliação Processo e Método de Avaliação MA-MPS.

Disponível em: https://softex.br/download/guia-de-avaliacao-2021/. Acesso em: 11 fev.
2023.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,

2011.

SOMMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Pearson Education do

Brasil, 2018.

SCHWABER, K. SUTHERLAND, J. Guia do Scrum: um guia definitivo para o Scrum: as

regras do Jogo. 2017. Disponível em: http://fabiocruz.com.br/livros/2017-Scrum-Gui-
de-PtBR-v1.pdf. Acesso em: 6 abr. 2023.

285
 TECHTARGET. TechTarget, 2011. Concurrent Version System (CVS). Disponível em:
https://www.techtarget.com/whatis/definition/Concurrent-Versions-System-CVS.
Acesso em: 22 jan. 2023.

TRELLO. AtlassianTrello, c2023. Trello. Disponível em: https://Trello.com/. Acesso em:

28 mar. 2023.

WAHLI, U. et al. Software Configuration Management: A Clear Case for IBM Ratio-
nal. ClearCase and ClearQuest UCM. [s. l.]: IBM/Redbooks, dez. 2004.

VALENTE, M. T. Engenharia de Software Moderna – princípios e práticas para de-

senvolvimento de Software com produtividade, 2020. Edição do Kindle. E-book.

VUORRE, M.; CURLEY, J. P. Curating Research Assets: A Tutorial on the Git Version
Control System. Aps, [s. l.], v. 1, n. 2, p. 219–236, 2018. Disponível em: https://journals.
sagepub.com/doi/pdf/10.1177/2515245918754826. Acesso em: 6 fev. 2023.

ZENDESK. A era do cliente: como empresas transformam a experiência de seus clien-

tes com o Zendesk, Blog da Zendesk, 2023. Disponível em: https://www.zendesk.
com.br/blog/age-of-customer-ebook/. Acesso em: 8 fev. 2023.

286