Gerenciamento de Projetos e Gerência de Configuração

Prévia do material em texto

Indaial – 2023
Profª. Semíramis Ribeiro de Assis
1a Edição
Gerenciamento 
de Projetos e 
Gerência de 
confiGuraçã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
Impresso por:
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
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. 
APRESENTAÇÃO
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
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.
GIO
QR CODE
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.
ENADE
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!
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. Confi ra, 
acessando o QR Code a seguir. Boa leitura!
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 ...........................................................................................123.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 ..........................................................................2413 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
1
UNIDADE 1 -
PRINCIPAIS CONCEITOS 
PARA A GERÊNCIA 
DE PROJETOS E 
CONFIGURAÇÃO
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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;
• identifi car os conceitos fundamentais sobre Auditoria, as metodologias voltadas 
para sistemas de TI e seus princípios básicos.
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
Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure 
um ambiente que facilite a concentração, assim absorverá melhor as informações.
CHAMADA
2
CONFIRA 
A TRILHA DA 
UNIDADE 1!
Acesse o 
QR Code abaixo:
3
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. 
TÓPICO 1 - UNIDADE 1
4
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.
5
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 deuma 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ífi ca para defi niçã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 fi nal 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 fi nal de cada 
projeto, denominamos entregável. 
Maximiano e Veroneze (2022) classifi cam 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 modifi cações em 
ambientes Empresariais.
Figura 1 – Relação entre singularidade e volume de projetos
6
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. 
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, 
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.
INTERESSANTE
7
além dos que foram previstos para a respectiva fase na qual o projeto se encontra, 
seu sucesso terá uma menor classifi caçã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. 
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.
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 fi nal, o planejamento realizado.
ESTUDOS FUTUROS
8
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.
9
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.
Figura 2 – Etapas do projeto executadas pelo Gerente de Projetos
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 ofi cial 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.
O Gerente de Projetos deverá defi nir 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.
NOTA
IMPORTANTE
10
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 
11
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 
12
base de conhecimento será fundamental para o processo de melhoria contínua para 
projetos futuros que venham a ser desenvolvidos pelaequipe, 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.
13
Fonte: adaptada de Maximiano e Veroneze (2022)
A Figura 3 apresenta um resumo das fases da metodologia simplifi cada de 
gestão de projetos. Por ser um processo simplifi cado, que as pessoas envolvidas já 
possuem o conhecimento necessário para executar cada etapa, então o processo de 
planejamento se resume à defi niçã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 fi m, o produto é entregue e o projeto fi nalizado.
Apesar de ser uma versão simplifi cada de gestão de projetos, é necessário que 
alguma ferramenta de controle seja utilizada, como a elaboração de cronogramas e 
a defi nição de marcos de entregas (ou datas limites para que cada etapa possa ser 
fi nalizada) 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 classifi car 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 fi nalização, para a raia “Feito”. 
Figura 3 – Fases da metodologia simplifi cada de gestão de projetos
Estaremos abordando o método Kanban quando formos tratar sobre as 
metodologias ágeis para gerenciamento de projetos. 
IMPORTANTE
14
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.
15
Fonte: adaptada de Pressman e Maxim (2021) 
A Figura 4 apresenta um resumo das principais fases de uma metodologia 
preditiva. A primeira etapa é a defi niçã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 profi ssionais 
e perfi s 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.
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 efi cazes, 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 fi nal 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, asprioridades do que deve ser construído, em termos 
de funcionalidades, para as aplicações desejadas. 
Figura 4 – Etapas da metodologia preditiva
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.
ESTUDOS FUTUROS
16
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.
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, 
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.
INTERESSANTE
17
Acadêmico, estudaremos com mais detalhes sobre metodologias ágeis e sua 
estrutura interna na Unidade 2. Fique atento!
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.
ESTUDOS FUTUROS
DICA
que terão metas específi cas, conforme as necessidades que forem priorizadas pelo 
cliente, e que terão, ao seu fi nal, uma cerimônia de apresentação para que o cliente 
valide o que foi fi nalizado no ciclo. 
Sutherland (2016) afi rma que um dos principais métodos ágeis utilizados para 
construção de produtos, atualmente, é o framework SCRUM. Ele especifi ca 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 defi nidos 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. 
Valente (2021) e Sommerville (2011) apresentam outras metodologias ágeis, 
tais quais o eXtreme Programming (XP), voltado para aplicações que possuem muita 
incerteza na defi niçã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.
18
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.
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. 
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.
DICA
19
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.
RESUMO DO TÓPICO 1
20
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 etapasdo 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 
21
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ê.
22
23
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 
UNIDADE 1 TÓPICO 2 - T
24
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 
25
requisitos da aplicação irão compor o conjunto dos itens de confi guração que deverão 
ser gerenciados. Qualquer alteração em um desses itens deverá ser devidamente 
documentada e analisada, garantindo que a aplicação refl etirá as mudanças necessárias, 
seguindo as boas práticas recomendadas.
Figura 5 – Resumo dos itens de confi guração de um projeto
Fonte: adaptada de Humble e Farley (2014) 
Pressman e Maxim (2021) apresentam o conceito de objeto de confi guração
como sendo um conjunto de itens de confi guração agrupados por categorias, como 
especifi cação de desing (do inglês DesignSpecifi cation), modelo de dados (do inglês 
DataModel), componentes, código fonte (do inglês SourceCode) e especifi cação de 
testes (do inglês TestSpecifi cation). Estes conjuntos podem ser relacionados entre si, 
sendo interdependentes.
Abordaremos a importância do processo de gerência de confi guraçã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) afi rma que o processo de gerenciamento de confi guraçõ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 
geografi camente distribuídas, necessitando controlar todas as contribuições feitas por 
todos os colaboradores.
26
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? 
27
Segundo Pressman e Maxim (2021), é preciso identifi car 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, defi nido alterações 
nas regras do comércio;
• patrocinadores com necessidades distintas das informadas originalmente, 
acarretando modifi caçõ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, refl etindo 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 Tuffl ey (2017) 
As confi gurações apresentadas na Figura 6 devem ser geridas para que 
suas respectivas alterações possam ser rastreadas, quando necessário. Os itens 
de confi guraçã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 confi guradas 
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.
28
Figura 7 – Fases macro do processo de gerenciamento das confi guraçõ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 confi gurações. O primeiro passo será identifi car (ou 
mapear) os itens de confi guração considerados gerenciáveis, ainda no processo 
de planejamento ou execução do projeto. Após a identifi cação, os itens deverão ser 
aplicados em seus respectivos ambientes, como uma versão inicial. Por fi m, é feito o 
gerenciamento, identifi cando e mantendo o histórico de eventuais alterações, quem fez 
e quando fez. 
O processo de gerenciamento das confi guraçõ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 confi guração, o comportamento 
anterior ao momento da falha poderá ser revertido, já que o histórico da confi guração 
alterada é preservado.
A Figura 8 apresenta os tipos de confi guração que podem ser gerenciadas, de 
acordo com o tipo de servidor e o nível de abstração.
Figura 8 – Tipos de confi gurações gerenciáveis
Fonte: adaptada de Humble e Farley (2014)
29
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ísticasde 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.
30
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.
É possível que duas ou mais aplicações compartilhem as mesmas 
confi guraçõ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 confi gurações operacionais refl ita apenas nas aplicações que 
delas dependerem.
ESTUDOS FUTUROS
INTERESSANTE
Segundo Tuffl ey (2017), todo processo de gerenciamento de confi guraçõ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.
É esperado que, em algum momento, o projeto tenha que lidar com o controle 
de mudanças e confi guraçõ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 confi guraçõ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.
31
Acadêmico, apresentaremos as principais ferramentas para controle de 
versão em outro momento, durante esta disciplina.
ESTUDOS FUTUROS
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 
confi gurações poderão se benefi ciar dessa estratégia. Discorreremos, ainda, sobre o 
controle de mudanças em itens de confi guraçã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.
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 defi nido. Saber quais as confi gurações e o que 
representa uma versão de uma aplicação poderá, por exemplo, defi nir quais arquivos do 
código fonte deverão ser armazenados pela ferramenta de gerenciamento de versões, 
quais confi guraçõ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 Tuffl ey (2017), é considerado como controle de versão o 
procedimento executado para manter e, futuramente, recuperar o histórico do processo 
evolutivo de uma confi guraçã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 modifi cados, quem 
executou essas modifi cações e quando foram feitas. 
32
É 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 modifi cação indesejada. Então, a gestão de confi guraçõ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.
Pressman e Maxim (2021) afi rmam que o processo de gestão de confi guração 
de software (SCM) deve envolver cinco tarefas:
• identifi cação dos itens que serão gerenciados;
• controle de versão dos itens previamente identifi cados;
• controle de alteração, quando necessário;
• auditoria de confi guração;
• relatos para as partes interessadas no projeto sobre os itens que estão sob 
gerenciamento da confi guraçã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 confi guração, 
tendo em vista que essas ferramentasirão identifi car, armazenar, realizar o devido 
controle de acesso, além de registrar o histórico de alterações.
O conceito de controle de versão deverá englobar, absolutamente, todos 
os passos e confi guraçõ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 confi guraçõ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.
ATENÇÃO
33
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.
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/.
Traremos outras ferramentas focadas em controle de versão na Unidade 
3 desta disciplina.
DICA
ESTUDOS FUTUROS
34
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 identifi que 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 fi nal da codifi caçã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. 
35
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.
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.
ATENÇÃO
36
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 entregacontí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.
37
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 
38
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.
 
39
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 identifi caçã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 confi gurar 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 fl uxo apresentado irá, ao seu fi nal, 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çãocriadas contendo as modifi cações recentemente 
integradas pelo time, sendo útil para identifi car 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 identifi cação e tratamento de eventuais 
problemas encontrados;
40
• 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.
41
Pressman e Maxim (2021) ainda afi rmam 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 fi nanceiro com 
eventuais multas ou descumprimento de acordos fi rmados com o cliente (ou demais 
partes interessadas). 
Gonçalves et al. (2019) afi rma que é necessário que um plano de gestão de 
confi guraçã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. 
Segundo Humble e Farley (2014) e Tuffl ey (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.
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.
INTERESSANTE
42
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 aofinal 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 
43
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.
44
É 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ê.
INTERESSANTE
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 
45
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 
deRecovery 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. 
46
É possível que sejam defi nidas janelas de manutenção em uma aplicação, 
com periodicidade defi nidas, a fi m de agrupar a execução de mudanças 
nas confi guraçõ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.
Acadêmico, abordaremos as principais ferramentas disponíveis para 
a implantação de um fl uxo 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!
NOTA
ESTUDOS FUTUROS
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 confi guraçã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 confi gurações adequadas, em uma máquina física já existente. 
Após a instalação e confi guração do novo servidor, é preciso garantir que 
o seu gerenciamento será efetuado de forma correta e transparente, o que signifi ca 
que todas as alterações que se mostrarem necessárias terão que, obrigatoriamente, 
serem validadas e controladas. Ter o controle, nessa situação, signifi ca 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.
Braga (2015) afi rma 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 identifi cação e correção de problemas 
no processo de implantação. Esses problemas podem estar relacionados com 
confi gurações de ambiente, como o sistema operacional, por exemplo.
47
É 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.
ATENÇÃO
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. 
 
48
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. 
49
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 entregacontí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.
50
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 
51
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.
52
53
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.
 
UNIDADE 1
54
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 
timee, 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.
55
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 fi nalidade de 
certifi car 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 é defi nida como um framework, ou 
seja, como um arcabouço, contendo defi niçõ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 defi niçõ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 fl uxo de produção da aplicação, 
identifi cando quais dados devem ser produzidos e gerenciados em cada etapa dos 
processos mapeados.
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.
Estudaremos a importância da defi nição do escopo de uma auditoria e 
sua relação com o processo de auditoria como um todo em momento 
futuro.
Acadêmico, abordaremos outras normas voltadas para o apoio ao 
processo de gerência de confi guração, com maiores detalhes, na Unidade 
3 desta disciplina.
ESTUDOS FUTUROS
ESTUDOS FUTUROS
56
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á certifi car 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) afi rmam 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 fi nal do 
projeto, o produto corresponda ao que é esperado pelos patrocinadores.
NOTA
INTERESSANTE
Pressman e Maxim (2021) afi rmam 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.
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.
57
Abordaremos a defi nição de escopo e a importância de sua correta defi nição 
em cada ciclo de auditoria no próximo subtema.
ESTUDOS FUTUROS
• 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 signifi ca 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.
Uma Empresa de desenvolvimento de softwares, por exemplo, poderá ter um 
setor específi co 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 
identifi car 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 acercado projeto, como alocação de 
novos recursos ou revisão do planejamento efetuado.
58
Sommerville (2011) afi rma 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.
Acadêmico, abordaremos as técnicas de revisão (ou auditoria) no Tema de 
Aprendizagem 3, ainda nesta Unidade de ensino.
IMPORTANTE
ESTUDOS FUTUROS
Pressman e Maxim (2021) afi rmam 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 fi nalização 
da inspeção em um artefato específi co, os resultados precisam ser documentados e 
avaliados pela equipe, que decidirá se aprovará ou não a funcionalidade avaliada. 
Uma das principais atividades, para que a realização da avaliação de uma 
aplicação seja realizada, é a defi niçã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.
59
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 
60
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:
61
• 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 justifi ca pelo fato de equipes com poucos 
membros conseguirem fi rmar 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ífi co, indicando apenas que uma ferramenta efi caz para esse 
tipo de validação: os testes de mesa. Por não existir um planejamento prévio para essa 
revisão, a efi ciê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 verifi caçã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 codifi caçã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 fi nal) 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.
Ainda neste tema de estudos, estudaremos as principais metodologias para 
cada tipo de auditoria apresentado.
ESTUDOS FUTUROS
62
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.
63
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.
64
Quadro 1 – Exemplo de planilha de auditoria
 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 exibindoo 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.
Item / Pergunta Resposta esperada Resposta obtida Conclusão
• Representa uma 
sequência de 
passos para o 
teste de uma 
funcionalidade 
do sistema.
• Também pode 
se referir a 
uma pergunta, 
em caso da 
avaliação de 
um evento ou 
processo.
• Resposta esperada 
a partir da execução 
da sequência de 
passos mencionada 
na coluna Item. 
É obtida através 
da análise da 
documentação 
estudada.
• Resposta 
apresentada 
pelo sistema, 
após a execução 
dos passos 
mencionados na 
coluna item.
• Para eventos ou 
processos, indica o 
que efetivamente 
aconteceu 
no evento 
ou processo, 
como resposta 
à pergunta 
elaborada.
• Indica se houve ou 
não divergência 
entre a coluna de 
resposta obtida e 
resposta esperada, 
caracterizando 
um desvio. Em 
caso de desvios, é 
importante mencionar 
o que diferiu entre 
o esperado e o 
efetivamente obtido, 
encaminhando esta 
planilha à equipe 
responsável pelos 
ajustes necessários.
65
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 fi nal 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 defi nidos 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 fi nalização 
dos itens que serão analisados.
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 fi nal 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.
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 identifi car pontos 
falhos e pontos de melhoria para eventos futuros ou, em caso de processos, 
otimização das etapas.
IMPORTANTE
66
É 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.
ATENÇÃO
As etapas do processo de auditoria, de forma resumida, seguirão um fl uxo 
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 defi niçã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)
67
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: 
68
• 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 processode 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.
69
Quadro 2 – Resumo das principais características das técnicas de auditoria de sistemas
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. 
Item
Técnica 
Testes em 
qualquer 
funciona-
lidade do 
sistema?
Necessi-
dade de 
preparação 
de grande 
massa de 
dados
Alto custo de 
desenvolvi-
mento
Necessi-
dade de 
habilidade 
do auditor
Alto custo 
de implan-
tação na 
aplicação
Simulação 
paralela
Sim Não Sim Sim Não se aplica
Lógica de 
auditoria 
embutida no 
sistema
Sim Não Sim Sim Sim
Rastreamento 
e 
mapeamento
Sim Não Sim Sim Sim
Análise da 
lógica de 
programação
Sim Não Não Sim Nã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.
ATENÇÃO
70
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:
71
• 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.
72
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.
73
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. 
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/.
NOTA
74
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.
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.
ATENÇÃO
IMPORTANTE
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.
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õesde 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). 
 
75
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, 
76
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. 
77
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.
78
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 conseguemmensurar 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). 
LEITURA
COMPLEMENTAR
79
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:
 
80
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ífi cas 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. 
81
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:
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 especifi caçõ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, defi nindo 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 
exemplifi ca os processos essenciais da ISO 9001.
Figura 2 – Os processos essenciais da ISO 9001
82
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, especifi camente, 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 Confi guraçã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 
modifi cações ao longo do ciclo de vida. Estima-se que tais modifi caçõ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 Confi guraçã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 Confi guraçã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: identifi cação; 
83
gerenciamento de alterações; facilitação em versionamento; qualidade do produto. Já 
na perspectiva do desenvolvimento, engloba três sistemas: controle de modifi cações, 
controle de versões e gerenciamento de construção. 
Tal metodologia é considerada como um suporte que benefi cia 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 Confi guraçã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 Confi guraçã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 efi ciente e efi caz. O GCS mostra-se em uma posição com grande 
poder decisivo, onde desde o desenvolvedor até a gerência utiliza como referênciapara 
a precisão de informações. 
[...]
84
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. 
85
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.
86
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:
87
( ) 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.
88
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.
89
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 deJaneiro: 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.
90
91
TÉCNICAS PARA O 
GERENCIAMENTO DE 
PROJETOS E CONFIGURAÇÕES
UNIDADE 2 —
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
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;
• identifi car os fatores críticos de sucesso para a gestão de projetos e confi guração;
• saber aplicar técnicas de auditoria voltadas para o gerenciamento de confi gurações;
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
Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure 
um ambiente que facilite a concentração, assim absorverá melhor as informações.
CHAMADA
92
CONFIRA 
A TRILHA DA 
UNIDADE 2!
Acesse o 
QR Code abaixo:
93
TÓPICO 1 — 
GESTÃO DE PROJETOS PREDITIVA
UNIDADE 2
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.
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.
Segundo PMI (2009), são investidos por ano cerca de US$ 12 trilhões em 
projetos mundialmente, isso equivale a 25% do PIB mundial.
INTERESSANTE
94
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.
95
2.1 GESTÃO DO ESCOPO 
Segundo Fleming e Koppelman (2005), a defi niçã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) afi rma que tudo aquilo que não estiver previsto como 
entregável ao fi nal 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 fi nalizaçã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.
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 defi nição do escopo do produto deverá, por 
consequência, delimitar até que ponto o produto irá englobar as funcionalidades 
específi cas de um determinado domínio de negócio.
Sutherland (2016) afi rma que, em metodologias ágeis, porém, é possível realizar 
ajustes no escopo inicialmente defi nido, como a alteração na priorização 
das funcionalidades que serão implementadas, conforme a necessidade do 
cliente.
INTERESSANTE
96
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 geralmentejá 
praticam, de forma consolidada, projetos mais tradicionais.
Wysocki, Beck e Thomas (2014), afi rmam 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.
IMPORTANTE
ATENÇÃO
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 defi nidos 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.
Figura 1 – Exemplo de entregáveis que compõem o escopo do projeto
Fonte: adaptada de Maximiano e Veroneze (2022)
97
Segundo Maximiano e Veroneze (2022), é importante frisar a diferença entre 
o escopo do produto e o escopo do projeto. Enquanto o primeiro irá refl etir, 
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.
ATENÇÃO
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 fi nal, os requisitos funcionais e não funcionais necessários para a 
codifi cação do sistema ou prestação do serviço.
Figura 2 – Escopo do projeto X escopo do produto
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 
etc.)
98
(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).
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.
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.
ATENÇÃO
99
Fonte: adaptada de Sommerville (2011)
Percebamos que, a partir da defi niçã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 defi nição 
do cliente que será benefi ciado, 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 fi nal 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, defi nido 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 defi niram 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 defi nido pelo cliente (ou partes interessadas).
Pressman e Maxim (2021) afi rmam que uma das formas de detalhamento do 
escopo de um projeto é defi nir 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 defi nidas.
Quadro 1 – Exemplo de descrição do escopo do projeto
100
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, é defi nido 
logo no começo do diagrama, no primeiro nível, tendo suas etapas (ou fases) sendo 
defi nidas 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 etapaque será concluída.
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.
INTERESSANTE
101
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 fi nal do projeto. Neste cenário, podemos identifi car ao menos 
três categorias de entregáveis:
• produto que será construído;
• infraestrutura necessária para construir o produto identifi cado;
• 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.
É importante identifi carmos 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 fi m. 
Acadêmico, abordaremos com maiores detalhes como as atividades poderão ser 
defi nidas 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 fi m 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 
Acadêmico, estudaremos, ainda nesta unidade de ensino, a aplicação do 
diagrama EAP para a identifi cação e análise dos riscos envolvidos em um 
projeto.
ESTUDOS FUTUROS
102
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.
103
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 
especifi cada, assim como a defi niçã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).
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 defi nir 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á defi nido na tabela de precedência, porém em outra forma de visualização 
(através de um gráfi co). 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.
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
Devemos perceber que cada atividade terá sua duração estimada especifi cada, 
assim como a defi nição das atividades precedentes.
ATENÇÃO
104
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.
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.
ATENÇÃO
ATENÇÃO
Figura 4 – Exemplo de diagrama de precedências
Fonte: adaptada de Sommerville (2011)
O diagrama de precedências apresentado na Figura 4 apresenta grafi camente 
as atividades e a precedência entre elas, defi nidas no Quadro 1. A precedência entre as 
atividades signifi ca 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.
105
Então, todas as tarefas que deverão acontecer, do início ao fi m 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 fi nalizem, 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á defi nir 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 fi nalizaçã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) afi rma que o caminho de volta, caso todos os prazos estimados 
sejam cumpridos rigorosamente, seria o menor prazo possível de início e fi nalização do 
projeto.
Figura 5 – Cenário para aplicação do método do caminho crítico
Fonte: adaptada de Pressman (2016)
106
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
Fonte: adapatada de Pressman (2016)
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
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.
ATENÇÃO
107
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 fi nalização deverá ser sempre considerada primeiro do que a data de 
inicialização. A data de fi nalizaçã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 fi m 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 fi nalização ou inicialização) irá impactar 
diretamente no projeto, atrasando o cronograma inicialmente planejado. 
Maximiano e Veroneze (2022) afi rmam 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 fi nalizando no dia 43 (EF), e, pelo cálculo do caminho 
de volta, seu início se daria no dia 41 (LS) e sua fi nalizaçã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. 
Após o cálculo dos prazos do projeto tiver sido fi nalizado, é 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.
Quando os prazos de início tardio e antecipado de uma tarefa coincidirem, 
não existirá folga para a execução da tarefa.
É importante que o planejamento leve em consideração as datas importantes 
do calendário, como feriados, fi nais 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.
ATENÇÃO
IMPORTANTE
108
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.
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.
É 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).
DICA
109
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.
110
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.
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 
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.
IMPORTANTE
111
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.
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.
INTERESSANTE
ú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.
112
Quadro 4 – Exemplo de apresentação do orçamento de um projeto
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 perfi l terá custos unitários medidos em homem/
hora e com valores diferenciados por perfi l.
O Custo total da equipe de desenvolvimento será, então, a soma dos custos totais 
de cada perfi l. 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áfi ca 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 efi ciência econômica de um projeto e para tomar decisões sobrealocação de recursos.
Figura 6 – Exemplo de apresentação de custos por gráfi co
Fonte: adaptada de James (2006)
Item
Tempo de alocação 
no projeto (horas)
Quantidade 
necessária
Custo unitário Custo Total
Equipe de 
desenvolvimento 
344 5 - R$ 123.840,00
Programador 
Júnior
2 R$ 50,00 hora R$ 34.400,00
Programador 
Pleno
2 R$ 80,00 hora R$ 55.040,00
Programador 
Sênior
1 R$ 100,00 hora R$ 34.400,00
113
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
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.
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.
Item Janeiro Fevereiro Março Abril Maio Junho Custo Total
Equipe de 
desenvolvimento 
R$ 
12.140,00
R$ 
10.200,00
R$ 
15.000,00
R$ 
31.500,00
R$ 
30.000,00
R$ 
25.000,00
R$ 
123.840,00
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.
ATENÇÃO
114
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:
115
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 efi caz e efi ciente. 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 – defi niçã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 efi caz e efi ciente.
• 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 – identifi cação de oportunidades de melhoria contínua 
para aumentar a efi ciência e efi cácia dos processos de qualidade do projeto.
Figura 7 – Pilares essenciais da gestão de qualidade
116
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).
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 averiguaro 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.
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.
INTERESSANTE
117
Acadêmico, abordaremos os tipos de testes existentes e como estes podem 
ser executados no processo de Gerenciamento de Projetos e Confi guração 
na Unidade 3 desta disciplina.
ESTUDOS FUTUROS
Imoniana (2016) ainda afi rma que todo processo que tenha como fi nalidade 
a averiguação entre o que foi planejado e o que está sendo executado no projeto 
ou produto é tido como uma forma de verifi caçã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 perfi l 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 sufi ciente.
Quando nos referimos ao processo de realização de testes de maneira sufi ciente, 
estamos querendo dizer da necessidade de englobar os mais variados cenários de testes 
possíveis, com uma diversifi caçã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 profi ssional 
esteja envolvido na realização de testes, além do desenvolvedor que construiu o 
requisito.
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 especifi cado. 
O Quadro 6 apresenta um exemplo de como este plano poderá ser elaborado:
118
Quadro 6 – Exemplo de Plano de Gestão da Qualidade
Indicador a ser analisado Nível de importância Método de avaliação
Utilização de padrões de 
projeto para implementação 
da aplicação.
Alto.
Avaliação manual dos 
códigos disponibilizados 
pela equipe no repositório 
de códigos.
Testes dos principais fluxos 
da aplicação.
Alto
Execução de testes 
automatizados para os 
principais requisitos do 
sistema.
Cumprimento das entregas 
parciais do projeto.
Médio.
Acompanhar os marcos 
parciais de entrega para 
garantir que a entrega final 
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. 
119
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).
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 
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.
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. 
ATENÇÃO
INTERESSANTE
120
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.
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 
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.
INTERESSANTE
121
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.
122
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).
ATENÇÃO
É 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.
123
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.
Quadro 7 – Exemplo de matriz de responsabilidades 
Papel Colaborador Levantamento de requisitos funcionais e não funcionais
Programador André I
Cliente Camila C
Analista de requisitos Flávia R
124
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 interessadosno 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.
125
RESUMO DO TÓPICO 1 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.
126
( ) 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. 
127
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.
UNIDADE 2 TÓPICO 2 - 
128
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 
surgimentodo 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. 
129
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.
130
• Sprint – uma Sprint é um período fi xo de tempo durante o qual o time Scrum 
trabalha para transformar itens do product backlog em incrementos entregáveis.
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) afi rma 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 fi m, o respeito mútuo entre a equipe 
e o cliente é visto como fundamental para criar uma atmosfera positiva e colaborativa.
Segundo afi rmam 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 fi nal 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 
Abordaremos com maiores detalhes os papéis, as cerimônias e o fl uxo de 
trabalho de um time ágil, nos próximos subtemas. E o método Kanban com 
mais detalhes na Unidade 3 desta disciplina.
ESTUDOS FUTUROS
131
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.
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.
DICA
https://www.youtube.com/watch?v=ds_FydzsuO8
https://www.youtube.com/watch?v=ds_FydzsuO8
132
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óximosubtema.
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 fl exibilidade maior e a 
capacidade de adaptação a mudanças durante o desenvolvimento do projeto.
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.
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.
Abordaremos, com detalhes, a dinâmica de uma equipe que adota metodologias 
ágeis, ainda nesta unidade. Neste momento, será explicado como uma equipe 
poderá defi nir quais tarefas irão ser comportadas em cada sprint, de acordo 
com o grau de complexidade de cada tarefa.
DICA
ESTUDOS FUTUROS
133
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.
134
Figura 8 – Resumo do ciclo de desenvolvimento SCRUM
Fonte: adaptada de Sutherland (2016)
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 afi rmativa, temos o MVP como um produto que 
Aprenderemos, nos próximos subtemas, a importância de se adotar tempos 
fi xos (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.
ESTUDOS FUTUROS
135
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.
INTERESSANTE
poderá ser construído para uso, em ambiente produtivo, pelos usuários fi nais 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. 
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 
defi nidos 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 refi namento 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 fi nal 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.
136
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 comporo 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.
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.
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).
IMPORTANTE
137
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
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.
Como [tipo de usuário]
Quero [realizar uma tarefa]
Para [obter um resultado desejado]
138
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.
INTERESSANTE
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 defi nidas 
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 
139
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 fi naliza.
Abordaremos as ferramentas voltadas para gerenciamento de projetos na 
Unidade 3 desta disciplina.
ATENÇÃO
ESTUDOS FUTUROS
disponíveis no backlog do produto seja extraído para o refi namento e, após a conclusão 
de todos os detalhes necessários para que a equipe de desenvolvimento tenha 
capacidade de iniciar a codifi cação das tarefas, esse conjunto refi nado irá compor o que 
conhecemos como backlog da sprint. 
É a partir do conjunto de tarefas já refi nadas, 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á defi nida para cada tarefa, pegando aquela 
mais prioritária para execução.
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.
140
Acadêmico, abordaremos, no próximo subtema, a importância de se definir 
prazoslimites (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.
141
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 fi nalizaçã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 fi nal 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.
Para conhecer como funciona a sequência de Fibonacci, recomendamos 
assistir ao vídeo: https://www.youtube.com/watch?v=cHZWZhHQq4g.
DICA
142
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.
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.
 
É 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.
IMPORTANTE
143
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 seremmelhorados 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.
144
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.
145
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 ser autogerenciá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:
146
( ) 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.
147
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.
UNIDADE 2
148
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.
149
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 defi nir o objetivo e o escopo da 
estratégia, avaliar o ambiente interno e externo, identifi car 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, identifi cando 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á refl etir 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.
150
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, defi nindo-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.
A seguir, abordaremos a defi niçã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 identifi car 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) defi ne 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 identifi car 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) afi rma 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.
Uma matriz SWOT procura identifi car 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.
DICA
151
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.
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ãoser 
adotadas para que a execução consiga atingir o resultado esperado.
IMPORTANTE
152
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.
153
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 fi nal 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 defi nir 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 defi nidos, conforme a escala adotada na etapa anterior. 
Ao fi nal da avaliação de todos os projetos, o resultado será a nota fi nal 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 fi nal 
será o mais importante, e assim sucessivamente.
Figura 11 – Funis do método stage – gate
154
O Quadro 9 apresenta um exemplo de aplicação do método AHP.
Quadro 9 – Exemplo de utilização do método AHP
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.
Segundo Saaty (1980), após fi nalizar o processo de montagem do portfólio, com 
a avaliação dos principais projetos, conforme os critérios selecionados pela empresa, 
será necessário defi nir, para cada projeto, como acontecerá seu fl uxo de trabalho dentro 
da organização.
Nem sempre o mesmo fl uxo poderá ser aplicado para diferentes projetos, então, 
é importante que as peculiaridades de cada projeto sejam consideradas na elaboração 
de seu fl uxo específi co.
Projetos Custos (0,5) Risco (0,3) Velocidade (0,2) Nota ponderada
1
5 10 10
7,5 (3º lugar)
2,5 3 2
2
10 5 8
8,1 (1º lugar)
5 1,5 1,6
3
9 7 6
7,8 (2º lugar) 
4,5 2,1 1,2
Acadêmico, devemos perceber que a soma dos pesos atribuídos para cada 
critério deve ser igual a 100%.
ATENÇÃO
155
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
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, 
Fatores 
organizacionais
Fatores técnicos
Fatores 
humanos
Processos Projeto
Apoio da alta 
administração.
Conhecimento 
técnico prévio da 
equipe.
Pessoas que 
atendam ao 
perfil técnico 
desejado.
Estar de 
acordo com o 
cronograma e 
planejamento 
efetuado.
Definição 
clara sobre 
os objetivos 
do projeto.
Ambiente 
favorável.
Aplicação de boas 
práticas para 
desenvolvimento.
Capacitação 
da equipe e 
treinamento.
Participação 
efetiva do 
cliente ao longo 
do processo.
–
Cultura 
organizacional.
Conhecimento 
e aplicação de 
metodologias 
ágeis para 
desenvolvimento.
–
Aceitação 
do cliente e 
feedbacks 
constantes.
–
Interesses 
políticos.
– –
Estratégia de 
entrega dos 
resultados.
–
156
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 ágeisSegundo 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.
157
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.
158
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 
159
Para que as confi gurações corretas possam ser armazenadas de forma efi ciente, 
de acordo com Humble e Farley (2014), é necessário que o gerente de projetos crie 
um plano de gerenciamento de confi guração, como apresentaremos no subtema 
a seguir.
3.1 PLANO DE GERENCIAMENTO DE CONFIGURAÇÃO 
Segundo Oliveira (2007), o plano de gerenciamento de confi guração deve iniciar 
com a fase de execução do projeto, indicando quais os artefatosque serão armazenados 
(documentação, código fonte, confi gurações do sistema operacional e infraestrutura, 
aplicativos de terceiros que serão utilizados etc.), qual a forma que essas confi gurações 
serão identifi cadas 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 identifi cados, é importante que sejam inseridos no plano 
de confi guração e passem, a partir de então, a serem monitorados.
da aplicação. Por isso, é importante que cada item seja identifi cado de maneira única, 
já que, a partir desse identifi cador, a mudança poderá ser revertida, como mencionam 
Humble e Farley (2014).
O gerenciamento de confi guraçã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 modifi cação e quando a modifi cação foi 
feita e implantada.
Acadêmico, na Unidade 3 desta disciplina, abordaremos, com mais detalhes, 
o processo de gerenciamento de confi gurações, além de apresentarmos as 
ferramentas que podem ser utilizadas para essa fi nalidade.
IMPORTANTE
ESTUDOS FUTUROS
160
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.
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.
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.
ESTUDOS FUTUROS
161
Segundo Pressman (2016), o conceito de controle de mudança pode ser 
defi nido como o processo sistemático de identifi car, avaliar e gerenciar as 
solicitações de mudanças em um projeto ou em um ambiente de produção.
IMPORTANTE
Além do gerenciamento das confi guraçõ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 efi ciente e efi caz, a fi m 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, fi nanças e saúde.
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:
• Identifi cação da mudança – identifi car 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 confi guração do 
projeto.
Para que o processo de gerenciamento de mudanças aconteça, é preciso 
compreender o conceito dos itens de confi guração, como apresentado a seguir.
162
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.
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.
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.
IMPORTANTE
163
Abordaremos os itensde confi guração e as normas relativas ao processo de 
gerenciamento de confi gurações na Unidade 3 desta disciplina.
ESTUDOS FUTUROS
Em outras palavras, os itens de confi guração são elementos importantes 
para o gerenciamento de confi guração do software, pois permitem a identifi cação e o 
rastreamento das partes que compõem o produto de software.
Segundo Sommerville (2011) e Cabral (2015), a gerência de confi guraçã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 confi guração, estão:
• Item de confi guração – qualquer coisa que pode ser identifi cada e controlada em 
um projeto, como código-fonte, documentos, equipamentos, materiais etc.
• Identifi cação de confi guração – um processo para identifi car, numerar e nomear 
os itens de confi guração de um projeto.
• Controle de confi guração – o processo de garantir que apenas versões 
autorizadas de itens de confi guração sejam usadas em um projeto e que mudanças 
sejam registradas e avaliadas antes de serem implementadas.
• Mudança de confi guração – qualquer modifi cação realizada em um item de 
confi guração, incluindo correções, melhorias e atualizações.
• Repositório de confi guração – um local centralizado, onde todos os itens de 
confi guração de um projeto são armazenados e gerenciados.
• Histórico de confi guração – um registro detalhado das mudanças realizadas em 
cada item de confi guração ao longo do tempo.
• Baseline de confi guração – uma versão aprovada de um item de confi guração 
que serve como referência para futuras mudanças.
• Integração de confi guração – o processo de combinar vários itens de confi guração 
em um sistema ou produto completo.
• Verifi cação de confi guração – o processo de verifi car se um item de confi guração 
ou sistema atende aos requisitos e às especifi cações.
• Validação de confi guração – o processo de confi rmar 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 confi guração do repositório de confi guração para modifi cação ou uso.
• Check-in – defi nido como o processo de retorno de uma versão modifi cada de um 
item de confi guração para o repositório de confi guração.
• Build – processo de compilação do software a partir dos códigos fontes e outros 
itens de confi guração.
164
• Release – a entrega formal de um conjunto de itens de confi guração para um 
ambiente de produção ou para outro uso.
• Branch – uma cópia independente de um item de confi guração, que permite a 
evolução independente das versões.
• Merge – processo de combinar duas ou mais versões de um item de confi guração 
em uma única versão.
Essas ferramentas são importantes para garantir a integridade e a consistência 
dos itens de confi guraçã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 confi guração são provenientes 
desses processos. 
3.3 PRINCÍPIOS E TÉCNICAS DE MANUTENÇÃO DE SOFTWARE 
Sommerville (2011) afi rma 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 efi ciente 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) afi rma 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 efi ciente, 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;
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.
IMPORTANTE
165
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. 
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.
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.
ATENÇÃO
166
• 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. Dessemodo, 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.
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. 
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.
DICA
167
Sobre o processo de reengenharia no processo de negócio, Pressman (2016) 
afi rma 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 
profi ssional dos membros da equipe.
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.
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 fi nal, tornando a aplicação mais intuitiva ao uso.
IMPORTANTE
ATENÇÃO
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.
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.
168
• Identifi cação do processo – fase em que os processos necessários para atingir 
os objetivos traçados na etapa anterior são identifi cados e classifi cados 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.
• Especifi cação e projeto do processo – cada processo que precise ser reescrito 
deverá ser especifi cado, de modo a identifi car 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 refi namentos.
• Refi namento e instanciação – após todas as etapas anteriores terem sido 
concluídas, o processo repaginado deverá ser implementado.
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:
Sommerville (2011) afi rma 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 justifi car o processo, 
tornando mais barata a construção de uma nova aplicação.
IMPORTANTE
169
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 fi nal.
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 fi nal, 
por meio de pequenas atualizações periódicas. Por fi m, espera-se que a aplicação siga 
o processo modelado, sem ônus para o funcionamento de seus requisitos e sem perda 
de dados.
• 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, refl etindo 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.
170
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.
GIO
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.
171
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, sejapelo 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 
LEITURA
COMPLEMENTAR
172
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 
173
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”.
174
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 demudanç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).
175
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 
176
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. 
[...]
177
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.
178
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.
179
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.
180
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.
181
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.
182
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.
183
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.
184
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.
https://www.ietec.com.br/clipping/2018/05-maio/A-importancia-de-um-escopo-bem-definido-no-gerenciamento-do-projeto.pdf
https://www.ietec.com.br/clipping/2018/05-maio/A-importancia-de-um-escopo-bem-definido-no-gerenciamento-do-projeto.pdf
https://www.ietec.com.br/clipping/2018/05-maio/A-importancia-de-um-escopo-bem-definido-no-gerenciamento-do-projeto.pdf
https://homepages.dcc.ufmg.br/~rodolfo/dcc823-2-07/Entrega4/Viviane4.pdf
https://homepages.dcc.ufmg.br/~rodolfo/dcc823-2-07/Entrega4/Viviane4.pdf
185
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.
186
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