Gerência de Projetos

PROF.
RAFAEL VARGAS MESQUITA DOS SANTOS
LICENCIATURA EM INFORMÁTICA
Gerência de Projetos
CACHOEIRO DE ITAPEMIRIM
IFES
2012
Governo Federal
Ministro de Educação
Aloizio Mercadante
Instituto Federal do Espírito Santo - Ifes
Reitor
Denio Rebello Arantes
Pró-Reitora de Ensino
Cristiane Tenan Schlittler dos Santos
Diretor-geral do Campus Cachoeiro de Itapemirim
Mário Jorge de Moura Zuany
Diretora do Cead – Centro de Educação a Distância
Yvina Pavan Baldo
Coordenadoras da UAB – Universidade Aberta do Brasil
Marize Lyra Silva Passos
José Mario Costa Junior
Curso de Licenciatura em Informática
Coordenação de Curso
Alexandre Fraga de Araujo
Designer Instrucional
Marcelo Albuquerque Schuster
Professor Formador/Autor
Rafael Vargas Mesquita dos Santos
S237g Santos, Rafael Vargas Mesquita dos.

2012 Gerência de projetos. / Rafael Vargas Mesquita dos Santos. –
Cachoeiro de Itapemirim: Ifes campus Cachoeiro de Itapemirim, 2012.
96 p. : il.
Inclui bibliografia.
ISBN: 978-85-62934-52-0
1. Projetos – PMBOK. 2. Desenvolvimento de Software – Processo. 3.

Desenvolvimento de Software – Gerência de Processo. I. Santos, Rafael
Vargas Mesquita dos. II. Instituto Federal do Espírito Santo. III. Título.
CDD 658.404
DIREITOS RESERVADOS
Instituto Federal do Espírito Santo - Ifes
Av. Rio Branco, nº 50 - Santa Lúcia - Vitória - ES - CEP. 29056-255 – Vitória – ES - Telefone: (27) 3227-5564
Créditos de autoria da editoração

Capa: Juliana Cristina da Silva
Projeto gráfico: Juliana Cristina da Silva e Nelson Torres
Iconografia: Nelson Torres
Editoração eletrônica: Cead/Ifes
Revisão de texto:
Esther Ortlieb Faria de Almeida
COPYRIGHT – É proibida a reprodução, mesmo que parcial, por qualquer meio, sem autorização escrita dos
autores e do detentor dos direitos autorais.
Olá, Aluno(a)!
É um prazer tê-lo(a) conosco.
O Ifes – Instituto Federal do Espírito Santo – oferece a você, em parceria

com as Prefeituras e com o Governo Federal, o Curso de Licenciatura em
Informática, na modalidade a distância. Apesar de este curso ser ofertado
a distância, esperamos que haja proximidade entre nós, pois, hoje, graças
aos recursos da tecnologia da informação (e-mails, chat, web conferência,
etc.) podemos manter uma comunicação efetiva.
É importante que você conheça toda a equipe envolvida neste curso:

coordenadores, professores formadores, tutores, porque, quando
precisar de algum tipo de ajuda, saberá a quem recorrer.
Na EaD – Educação a Distância, você é o grande responsável pelo sucesso

da aprendizagem. Por isso, é necessário que se organize para os estudos
e para a realização de todas as atividades, nos prazos estabelecidos,
conforme orientação dos Professores Formadores e Tutores.
Fique atento às orientações de estudo que se encontram no Manual do Aluno!
A EaD, pela sua característica de amplitude e pelo uso de tecnologias

modernas, representa uma nova forma de aprender, respeitando,
sempre, o seu tempo.
Desejamos-lhe sucesso e dedicação!
Equipe do Ifes
ICONOGRAFIA
Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos.
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por você,

após a leitura dos textos.
Indicação de leituras complementares,

referentes ao conteúdo estudado.
Destaque de algo importante, referente ao

conteúdo apresentado. Atenção!
Reflexão / questionamento sobre algo

importante referente ao conteúdo apresentado.
Espaço reservado para as anotações que você

julgar necessárias.
APRESENTAÇÃO
Olá!
Meu nome é Rafael Vargas Mesquita, responsável pela disciplina de Gerência

de Projetos. Atuo como professor do IFES há seis anos. Sou graduado em
Ciência da Computação (2001) e Mestre em Gestão da Qualidade de
Software (2007), ambos pela UFLA, e atualmente estou cursando doutorado
na Universidade Estadual Norte Fluminense (UENF). Minhas áreas de
interesse são: Qualidade de Software, Melhoria de Processo de Software,
Medição de Software, Análise e Projeto de Sistemas Orientados a Objetos.
Nesta disciplina, você entenderá alguns conceitos importantes relacionados

a Projetos, bem como o papel de um Gerente de Projetos.
Os capítulos 1 e 2 são mais voltados à parte teórica da disciplina. É muito

importante que você entenda muito bem os conceitos apresentados para
conseguir compreender o capítulo seguinte. Nos capítulos 3 e 4 iremos
utilizar, na prática, um processo de gerência de projetos de software
elaborado especificamente para esta disciplina. Apesar deste processo
de gerenciamento ser utilizado com finalidades didáticas, também
apresentará uma ideia de mercado.
O objetivo deste material é auxiliá-lo no estudo da disciplina de Gestão

de Projetos, por meio de dicas e sugestões que destacam os pontos mais
importantes a serem estudados. Aqui você encontrará conceitos com os
quais trabalharemos ao longo de todo o Curso.
Há, na sala virtual, um processo de gerência de projetos de software que deve

ser utilizado, principalmente quando estivermos estudando o capítulo 3.
É importante esclarecer que, além deste material, você poderá encontrar

na sala virtual alguns tutoriais em vídeos, os quais irão facilitar tanto
a utilização do processo de gerência de projetos de software quanto a
utilização de suas ferramentas.
Bons estudos e sucesso!
Prof. Rafael Vargas Mesquita

Cap. 1 - VISÃO GERAL 9
1.1 O QUE É UM PROJETO 9
1.1.1 Antecedentes Históricos 9
1.1.3 Projetos versus Operações 10
1.1.4 Stakeholders 10
1.1.5 Características do Projeto 11
1.2 O QUE É GERÊNCIA DE PROJETOS? 12
1.2.1 Habilidades do Gerente de Projeto 14
1.3 CICLOS DE VIDA DO PROJETO 14
1.3.1 Ciclos e Fases do Projeto 15
cap. 2 - padrões de gerência de projeto 19

2.1 PMBOK 19
2.1.1 Gerência da Integração do Projeto 23
2.1.2 Gerência do Escopo do Projeto 24
2.1.3. Gerência do Tempo do Projeto 25
2.1.4 Gerência do Custo do Projeto 28
2.1.5 Gerência da Qualidade do Projeto 28
2.1.6 Gerência de Recursos Humanos do Projeto 29
2.1.7 Gerência das Comunicações do Projeto 31
2.1.8 Gerência de Risco do Projeto 31
2.1.9 Gerência de Aquisição do Projeto 32
cap. 3 - processos 35
3.1 ENTENDENDO PROCESSOS 35
3.1.1 Processo de Desenvolvimento de Software 35
3.1.2 Processo de Gerência de Projetos de Software 36
3.1.3 Interação entre os Processos de Desenvolvimento
e de Gerência de Projetos de Software 36
3.2 UTILIZANDO PROCESSOS 38
3.2.1 Processo de Desenvolvimento de Software 38
3.2.2 Processo de Gerência de Projetos de Software 42
cap. 4 - PROCESSO DE GERÊNCIA DE
PROJETO DE SOFTWARE 47
referências 95
VISÃO GERAL
Prezado aluno,
Começaremos o primeiro capítulo com uma visão geral de
Gerência de Projetos (GP). Para entendermos Gerência de Projetos,
primeiramente precisaremos definir alguns conceitos fundamentais,
tais como: o que é projeto e o que são seus ciclos de vida. Os dois
primeiros capítulos são mais teóricos, já no terceiro capítulo temos
a parte mais prática da disciplina. Em geral, esta disciplina é
acumulativa, ou seja, a compreensão dos conceitos estudados em
um capítulo é a base para o entendimento dos capítulos posteriores.
Bom estudo!
1.1 O QUE É UM PROJETO
1.1.1 Antecedentes Históricos
“Pois qual de vós, pretendendo construir

uma torre, não se assenta primeiro para
calcular a despesa e verificar se tem os meios
para a concluir? Para não suceder que,
tendo lançado os alicerces e não podendo
acabar, todos os que a virem zombem dele,
dizendo: Este homem começou a construir
e não acabou” (Lucas 14: 28-30)
1.1.2 Definição
Projeto é um instrumento fundamental

para qualquer atividade de mudança
e geração de produtos e serviços. Os
projetos podem envolver desde uma única pessoa a milhares de pessoas
organizadas em times e ter a duração de alguns dias ou vários anos [1].
Um projeto é um empreendimento único, com início e fim

definidos, que utiliza recursos limitados e é conduzido por pessoas,
visando atingir metas e objetivos pré-definidos estabelecidos
dentro de parâmetros de prazo, custo e qualidade [2].
10
Prof. Rafael Vargas Mesquita dos Santos
O projeto pode ser definido por características distintas, tais como:

temporário, único e progressivo. A característica de ser temporário é
muito importante, pois todo projeto tem um início e um fim definidos.
O projeto termina quando os objetivos para o qual ele foi criado são
atingidos ou quando se torna claro que os objetivos do projeto não
serão, ou não poderão mais ser, atingidos, ou, então, a necessidade do
projeto não existe mais [2].
Ser único significa que todo produto ou serviço gerado por um projeto é
diferente de outros produtos e serviços. Os projetos envolvem a realização
de algo jamais realizado anteriormente; logo, eles são únicos. Um
projeto é progressivo porque, à medida que é mais bem compreendido,
ele é progressivamente elaborado, ou seja, maior é o detalhamento das
características peculiares que o distinguem como único [2].
1.1.3 Projetos versus Operações
Os projetos têm natureza temporária e datas de início e fim definidas,

e estarão concluídos quando as respectivas metas e objetivos forem
cumpridos. Às vezes, terminam quando se chega à conclusão de
que não é possível cumprir suas metas e objetivos, o que determina,
então, seu cancelamento.
As operações são contínuas e repetitivas. Elas envolvem um trabalho

contínuo, sem data de término, e normalmente se repetem os mesmos
processos para a produção do mesmo resultado. O propósito das
operações é manter a organização funcionando, enquanto que o
objetivo do projeto é atingir as suas metas e ser concluído. Assim sendo,
as operações são contínuas, e os projetos são únicos e temporários.
1.1.4 Stakeholders
Um projeto é bem-sucedido quando atende (ou excede) às espectativas

dos stakeholders, que são as pessoas (ou organizações) que têm algum
interesse envolvido, ou seja, aquelas pessoas que têm algo a ganhar ou a
perder como consequência do projeto.
Stakeholder ou, em Português, parte interessada ou interveniente,

refere-se a todos os envolvidos num projeto, como por exemplo:
clientes, colaboradores, investidores, fornecedores, etc.
O termo “stakeholders” foi criado para designar todas as pessoas,
instituições ou empresas que, de alguma maneira, são influenciadas
pelas ações de uma organização.
11
Os principais stakeholders podem ser responsáveis tanto pelo êxito

quanto pelo fracasso de um projeto. Mesmo que todas as entregas
sejam concretizadas e os objetivos sejam atendidos, se seus principais
stakeholders não ficarem satisfeitos, de nada adiantará.
1.1.5 Características do Projeto
Acabamos de aprender que um projeto possui diversas características:
• os projetos são únicos;
• os projetos são de natureza temporária e têm datas definidas de

início e fim;
• os projetos estarão concluídos quando as metas forem alcançadas

ou quando for decidido que o projeto não é mais viável;
• um projeto bem-sucedido é aquele que atende ou excede as

expectativas dos stakeholders.
Vamos pensar na seguinte situação: o gerente de negócios da empresa

lhe faz a seguinte proposta: desenvolver um sistema de controle de
videolocadora para a locadora Visão que vai informatizar as funções
de empréstimo, devolução e reserva de fitas. O objetivo do sistema é
agilizar o processo de empréstimo e garantir maior segurança, e, ao
mesmo tempo, possibilitar um melhor controle das informações por
parte da gerência da videolocadora. A intenção do gerente de negócios é
entregar o software pronto até o final do ano. A melhor notícia é que ele
o indicou para coordenar o projeto.
Usando os critérios referentes às características do projeto, examinemos

a tarefa que lhe foi atribuída pelo gerente de negócio para saber se trata-
se ou não de um projeto:
É único? Sim, porque a locadora Visão ainda não possui sistema

computacional para controlar as locações realizadas. Mesmo que os
serviços fornecidos pela sua empresa não sejam uma novidade, pois
outras locadoras possuem sistemas computacionais, o sistema proposto
pela sua empresa é único.
O projeto tem prazo limitado? Sim, a data de início desse projeto é hoje
e a data de término é o final do ano. É um empreendimento temporário.
Existe uma maneira de saber se o projeto está concluído? Sim, o

software será instalado na locadora e as funcionalidades do mesmo serão
12
disponibilizadas para utilização. Tão logo o software esteja funcionando,

o projeto será finalizado.
É possível saber se os stakeholders estão satisfeitos? Sim, as expectativas

dos stakeholders serão documentadas sob forma de requisitos1 durante
os processos (etapa) de planejamento. Tais requisitos serão comparados
ao produto final para ver se este atende às expectativas dos stakeholders.
Enfim, temos um projeto.
SÃO exemplos de projetos:

• Construção de uma casa
• Redação de um livro
• Lançamento de um produto ou serviço
• Realização de uma viagem
• Desenvolvimento de um software
NÃO SÃO exemplos de projetos:

• Compra de materiais (quando operação regular)
• Fabricação de um carro
• Gerenciamento de um setor administrativo
• Venda de produtos ou serviços
• Pagamento de produtos ou serviços
1.2 O QUE É GERÊNCIA DE PROJETOS?
Você tem certeza de que tem um

projeto. E agora? As anotações feitas
em um guardanapo na lanchonete
podem ser um começo, mas não
são exatamente uma boa prática de
gerenciamento de projetos.
1
Uma condição ou capacidade que deve ser atendida ou possuída por um sistema,
produto, serviço, resultado ou componente para satisfazer um contrato, uma norma,
uma especificação ou outros documentos impostos formalmente. Os requisitos
incluem necessidades, desejos e expectativas quantificados e documentados do cliente
e de outras partes interessadas.
13
Existem muitas situações como esta: uma vez comunicada a tarefa,

a equipe parte para a execução do projeto e ocupa-se da criação do
produto ou serviço solicitado, sem dar muita atenção ao processo de
planejamento. Alguns ainda dizem: “Por que desperdiçar um tempo
valioso?” ou “Para que planejar em vez de colocar a mão na massa?”. O
andamento do projeto dificilmente é avaliado em termos das solicitações
do cliente – cujas expectativas, no fim das contas, acabam não sendo
atendidas pelo produto ou serviço final! É uma experiência frustrante
para todos os envolvidos e, infelizmente, inúmeros projetos seguem essa
trafetória deficiente.
O gerenciamendo de projetos abrange uma série de ferramentas e

técnicas utilizadas por pessoas para descrever, organizar e monitorar
o andamento das atividades do projeto. Os gerentes de projeto são
os responsáveis pela administração dos processos envolvidos e pela
aplicação das ferramentas e técnicas necessárias ao cumprimento das
atividades do projeto.
Todo projeto é composto por processos, por mais fortuita que seja a
abordagem empregada. Há muitas vantagens em organizar projetos e
equipes conforme os processos de gerenciamento endossados pelo Project
Management Institute (PMI) (conforme veremos no capítulo seguinte).
O gerenciamento de projetos consiste na aplicação de conhecimentos,

competências, ferramentas e técnicas às atividades do projeto, com vista
ao cumprimento dos requisitos em pauta. É responsabilidade do gerente
de projetos assegurar que tais técnicas sejam utilizadas e seguidas.
O gerenciamento de projetos abrange uma série de atividades, incluindo

planejar, colocar em ação o plano do projeto e acompanhar o progresso
e o desempenho. Dentre essas atividades, também estão a identificação
dos requisitos, a definição dos objetivos, a avaliação das restrições e a
apreciação das necessidades e expectativas dos principais stakeholders.
O planejamento é uma das atribuições mais importantes, visto que

vai definir o padrão a ser empregado no desenrolar do projeto e será
usado para acompanhar seu futuro andamento.
Nesta disciplina, iremos focar no planejamento. Os alunos formarão
equipes de projeto e, juntos, irão elaborar um plano de projeto para
um determinado projeto especificado. Isto será realizado quando
estivermos estudando o capítulo 3.
14
1.2.1 Habilidades do Gerente de Projeto
Muitas vezes, as organizações denominam especialistas técnicos de

gerentes de projeto. Acredita-se, erroneamente, que as habilidades e a
experiência graças às quais esses profissionais se destacaram em suas
áreas técnicas vão se traduzir em aptidão para o gerenciamento de
projetos. Entretanto, não é necessariamente o que acontece.
Os gerentes de projeto são profissionais generalistas, cujo repertório

compreende uma série de competências ou habilidades. Vejamos
uma visão geral de algumas destas habilidades necessárias aos
gerentes de projeto:
• Habilidades Organizacionais: são as aptidões para planejamento e

organização. Dentre outros fatores, incluem: organização do tempo,
planejamento de reuniões, registros de experiências, contratos, etc.
• Habilidades para Finanças e Contabilidade: é importante que

o gerente de projetos tenha conhecimento sobre como fazer
estimativas de custos para a elaboração do orçamento.
• Habilidade de Liderar: esta habilidade envolve as funções de

direcionar, envolver, motivar e inspirar as pessoas interessadas
no projeto.
• Habilidades de Negociar e Influenciar: envolve o ato de dialogar

com outras pessoas com o objetivo de obter o consenso ou chegar a
um acordo para que alguma atividade seja realizada.
• Habilidade de Comunicação: é, talvez, a principal habilidade de

um gerente de projeto. Deve-se assegurar que as informações sejam
explícitas, claras e completas, para que os envolvidos não tenham
dificuldades de compreendê-las
1.3 CICLOS DE VIDA DO PROJETO
Uma analogia interessante feita por Heldman [5] diz que os ciclos de
vida do projeto são semelhantes aos ciclos experimentados pelos pais ao
acompanhar o crescimento de seus filhos até a fase adulta. Ou seja: os
filhos começam como bebês e dão muitas alegrias aonde quer que eles
vão. Entretanto, no princípio não os conhecemos muito bem. Assim, nós
os acompanhamos em seu crescimento e avaliamos suas necessidades;
com o passar do tempo, eles amadurecem e crescem (e custam muito
dinheiro nesse processo), até o dia em que a responsabilidade dos pais
em relação a eles termina.
15
Os projetos começam exatamente do mesmo modo e percorrem uma

trajetória semelhante. Alguém apresenta uma excelente ideia para um
projeto e solicita apoio para tal. Depois de aprovado, o projeto passa pelas
fases intermedirárias até a fase final, quando é concluído e encerrado.
1.3.1 Ciclos e Fases do Projeto
Todos os projetos são dividos em fases e, sejam grandes ou pequenos,

têm um ciclo de vida parecido. No mínimo, um projeto terá um estágio
inicial ou de iniciação, uma fase (ou fases) intermediária(s) e uma
etapa final – o número depende da complexidade do projeto e do setor
da indústria. Os projetos de tecnologia da informação, por exemplo,
podem passar por fases como: concepção (definição dos requisitos),
elaboração (análise e projeto), construção (programação e teste) e
transição (implantação do sistema).
O conjunto das fases coletivas atravessadas pelo projeto é

denominado de ciclo de vida do projeto.
O término de cada estágio representa para o gerente do projeto, e seus

stakeholders, uma oportunidade de avaliar se o projeto deve avançar
para a fase seguinte, a qual só deve ser iniciada quando as entregas da
fase anterior tiverem sido revisadas e aprovadas. E assim as etapas se
sucedem, percorrendo o ciclo de vida numa série de estágios encadeados.
Vamos resumir o conteúdo visto neste capítulo: Aprendemos

que os projetos existem para trazer luz a algum produto ou serviço
único; são temporários e têm data de início e fim definidas.
Os stakeholderes são as pessoas físicas ou jurídicas que têm interesse
no resultado do projeto, e aí se incluem o cliente, os principais
integrantes da gerência, o gerente do projeto, os profissionais
contratados, os fornecedores, entre outros. Os projetos são
considerados concluídos quando atendem ou ultrapassam as
expectativas dos stakeholders.
O gerenciamento de projetos é uma disciplina que reúne um
conjunto de ferramentas e técnicas para descrever, organizar
e monitorar a execução das atividades do projeto, o que é
responsabilidade dos gerentes de projeto.
16
1. Descreva um exemplo de projeto ainda não mencionado na

apostila. Lembre-se de considerar as características de um projeto.
2. Descreva a diferença entre projetos e operações.
3. O vice-presidente de marketing o procura para solicitar que
você mude a tela de entrada do Website da empresa, de modo a
incluir um nome de usuário com, no mínimo, seis caracteres Isso
é considerado:
a. Iniciação do projeto
b. Operações continuadas
c. Um projeto
d. Execução do projeto
4. Sua empresa fabrica pequenos eletrodomésticos de cozinha e
está lançando uma nova linha de produtos em cores elegantes,
com recursos próprios para cozinhas pequenas, que serão
oferecidos indefinidamente a partir do lançamento do catálogo de
primavera. Qual das seguintes afirmações é verdadeira?
a. Trata-se de um projeto, porque a nova linha de produtos
nunca foi fabricada nem vendida por essa empresa.
b. Trata-se de uma operação continuada, porque a empresa atua
no ramo de fabricação de eletrodomésticos de cozinha. O
lançamento das novas cores e recursos é apenas uma variação
de um processo já existente.
c. Trata-se de uma operação continuada, porque a nova linha de
produtos será vendida sem prazo definido. Não é temporária.
d. Não se trata de um projeto nem de uma operação continuada.
É o lançamento de um novo produto, o que não afeta as
operações continuadas.
5. Um projeto é considerado bem-sucedido quando:
a. Seu produto é fabricado.
b. Seu patrocinador anuncia seu término.
c. Seu produto é transferido para a área de operações, que
cuidará dos aspectos contínuos do projeto.
4. O projeto atende ou excede as expectativas dos stakeholders.
6. Você é o gerente de um grande projeto de construção cujo
objetivo é construir instalações para acomodar a equipe de apoio
dos Jogos Olímpicos, que chegará à cidade 18 meses a partir da
data de início do projeto. Os recursos não estão disponíveis de
17
imediato porque estão alocados, no momento, em outros projetos.

Jorge, especializado na operação de guindastes, será necessário
neste projeto daqui a 2 meses. De qual das seguintes habilidades
você lançará mão para conseguir que Jorge seja designado para o
seu projeto?
a. Negociação e Influência
b. Comunicação e Organização
c. Comunicação
d. Liderança
[1] PROJECT MANAGEMENT INSTITUTE - PMI. A guide to

the project management body of knowledge. Syba: PMI Publishing
Division, 2004 – Capítulos 01 e 02.
[2] HELDMAN, Kim. Gerência de Projetos: guia para o exame
oficial do PMI. Rio de Janeiro: Elsevier, 2006 – Capítulo 01.
18
padrões de gerência
de projeto
Prezado aluno,
agora que você já tem uma visão geral de Gerência de Projeto,
apresentaremos neste capítulo alguns padrões de Gerência de
Projeto amplamente utilizados.
Serão mencionados alguns padrões. Todavia, nesta disciplina
iremos focar no PMBOK.
Bom estudo!
Ao longo do tempo, houve diversas tentativas para desenvolver padrões

internacionais de gerência de projetos. Dentre elas, destacam-se:
• Project Management Body of Knowledge (PMBOK), um conjunto

de conhecimentos gerenciado pela organização Project Management
Institute (PMI). Este tem-se tornado, de fato, um padrão em diversas
indústrias, como a da Construção Civil, e em diversos setores da
Indústria de Software.
• ISO 10006: 1997, Quality management - Guidelines to quality in

project management, é um padrão internacional desenvolvido pela
ISO e específico para gerência de projetos.
Nas seções a seguir, aprofundar-nos-emos no PMBOK.
2.1 PMBOK
Nas últimas décadas, emergiu uma série de abordagens na indústria em

geral. Dentre essas, destaca-se a abordagem do PMBOK, que, de fato,
tem se tornado um padrão em diversas indústrias.
O PMI – Project Management Institute é uma associação de profissionais

de gerenciamento de projetos que existe desde 1969. Esta associação
criou em 1986 a primeira versão do PMBOK – Project Management
Body of Knowledge. O PMBOK é um guia que descreve a somatória
de conhecimentos e as melhores práticas dentro da profissão de
gerenciamento de projetos. É um material genérico que serve para
20
todas as áreas de conhecimento, ou seja, tanto para a construção de um

edifício como para a produção de software.
A meta do gerenciamento de projetos, segundo o PMBOK, é conseguir

exceder as necessidades e expectativas dos stakeholders. Todavia,
satisfazer ou exceder estas necessidades envolve um balanceamento
entre as várias demandas concorrentes em relação a:
• escopo2, tempo, custo e qualidade (objetivos do projeto);
• stakeholders com necessidades e expectativas diferenciadas; e
• requisitos identificados (necessidades) e requisitos não identificados

(expectativas).
O PMBOK [2] organiza os processos de gerenciamento de projetos

em cinco grupos de processos (Figura 1): processos de inicialização,
processos de planejamento, processos de execução, processos de
controle e processos de finalização.
Figura 1 - Grupos de processos do gerenciamento de projetos

do PMBOK
Processos de Processos de
Inicialização Planejamento
Processos de Processos de
Controle Execução
Processos de
Finalização
Fonte: Cead/Ifes © - 2012
Os processos de inicialização autorizam ou o início do projeto ou o

início de uma de suas fases. Os processos de planejamento definem e
refinam os objetivos do projeto, selecionando as melhores alternativas
para realizá-lo. Os processos de execução coordenam pessoas e outros
recursos para a realização do projeto, baseando-se no planejamento.
Os processos de monitoramento e controle monitoram e medem o
progresso do que está sendo executado, com o intuito de tomar ações
2
A soma dos produtos, serviços e resultados a serem fornecidos na forma de projeto.
21
corretivas quando necessárias. Os processos de finalização formalizam

o aceite e a finalização do projeto ou de uma de suas fases.
Não confunda fases e ciclos de vida do projeto (vistos no capítulo 1)

com os grupos de processos de gerenciamento do projeto. O Guide
to the PMBOK [2] faz uma distinção bastante clara a respeito
disso. As fases e ciclos de vida do projeto descrevem como será
concluído o trabalho associado ao produto do projeto. Por exemplo,
um projeto de software pode passar por fases como concepção
(estudo da viabilidade), elaboração (análise e projeto), construção e
transição. Os cinco grupos de processo do gerenciamento de projetos
(Iniciação, Planejamento, Execução, Monitoramento e Controle,
Encerramento) organizam e descrevem como serão conduzidas as
atividades para que os requisitos do projeto sejam atendidos. Em
projetos grandes, esses processos normalmente são executados em
cada uma das fases. Os cinco grupos de processos compõem o cerne
do Guide to the PMBOK. Em sua leitura desta apostila, empenhe-se
por compreender cada um desses processos.
Existe, ainda, outra maneira de classificar os processos do PMBOK:

organizados por áreas de conhecimento, que se referem a um aspecto a
ser considerado dentro do gerenciamento de projetos. Dentro destas áreas
de conhecimento, os cinco grupos de processos acima descritos podem
ocorrer. A Figura 2 mostra as 9 áreas de conhecimento do PMBOK.
Figura 2 - Áreas de conhecimento do gerenciamento de projetos

do PMBOK
Gerência de Projeto
Gerência de Gerência de Gerência de

Integração Escopo Tempo

Curso Qualidade Recursos Humanos

Comunicação Risco Aquisição
Fonte: Cead/Ifes © - 2012
Descrevemos na Figura 2, os processos de cada área de conhecimento do

PMBOK. Todos os processos descritos, das áreas acima, interagem uns com
os outros e também com os processos das demais áreas de conhecimento.
22
Cada processo pode envolver esforço de um ou mais indivíduos ou grupos

de indivíduos, dependendo das necessidades do projeto. Cada processo,
geralmente, ocorre pelo menos uma vez em cada fase do projeto.
1. Que organização definiu os padrões válidos para as técnicas do

gerenciamento de projetos?
a. PMBOK
b. PMO
c. PMI
d. PMA
2. Qual das seguintes opções reúne um conjunto de ferramentas e
técnicas usadas para descrever, organizar e monitorar a execução
das atividades do projeto?
a. Gerentes de projeto
b. Guide to the PMBOK
c. Gerenciamento de projetos
d. Stakeholders
3. Quais os cinco grupos de processos do gerenciamento de
projetos, na ordem?
a. Iniciação, Execução, Planejamento, Monitoramenteo e
Controle, e Encerramento
b. Iniciação, Monitoramento e Controle, Planejamento, Execução
e Encerramento
c. Iniciação, Planejamento, Monitoramento e Controle, Execução
e Encerramento
d. Iniciação, Planejamento, Execução, Monitoramento e
Controle, e Encerramento
4. Você é um gerente de projetos que está trabalhando no
levantamento de requisitos e na elaboração de estimativas para o
projeto. Em que grupo de processos você se encontra?
a. Planejamento
b. Execução
c. Iniciação
d. Monitoramento e Controle
23
2.1.1 Gerência da Integração do Projeto
A gerência da integração do projeto inclui os processos requeridos para

assegurar que os diversos elementos do projeto estão adequadamente
coordenados. Ela envolve fazer compensações entre objetivos e
alternativas eventualmente concorrentes, a fim de atingir ou superar as
necessidades e expectativas.
A área de conhecimento Gerência da Integração

do Projeto trata da coordenação de todos os
aspectos do plano do projeto e envolve um
elevado nível de interação. Essa área envolve
a identificação e definição do trabalho do
projeto e a combinação, unificação e integração
dos processos apropriados. Ela também se
preocupa em atender, satisfatoriamente, os requisitos do cliente e dos
stakeholders e gerenciar suas expectativas.
Essa área de conhecimento inclui os seguintes processos principais:
• Desenvolvimento do Termo de Abertura - desenvolver o termo

de abertura do projeto, o qual autoriza formalmente um projeto ou
uma fase do projeto.
• Desenvolvimento da Declaração de Escopo - desenvolver a

declaração do escopo preliminar do projeto, o qual fornece uma
descrição de alto nível do escopo.
• Desenvolvimento do Plano de Gerenciamento do Projeto -

documentar as ações necessárias para definir, preparar,
integrar e coordenar todos os planos auxiliares em um plano de
gerenciamento do projeto.
• Orientação e Gerenciamento da Execução do Plano - executar o

trabalho definido no plano de gerenciamento do projeto para atingir
os requisitos definidos na declaração do escopo do projeto.
• Monitoramento e Controle do Trabalho do Projeto - monitorar

e controlar os processos usados para iniciar, planejar, executar e
encerrar um projeto para atender aos objetivos de desempenho
definidos no plano de gerenciamento do projeto.
• Controle Integrado de Mudanças - revisar todas as solicitações

de mudança, aprovação de mudanças e controle de mudanças nas
entregas e nos ativos de processos organizacionais3.
3
Saídas/Entradas. Esses ativos de processos incluem planos formais ou informais,
políticas, procedimentos e diretrizes.
24
• Encerramento do Projeto - finalização de todas as atividades em

todos os grupos de processos de gerenciamento de projetos para
encerrar formalmente o projeto ou uma de suas fases.
2.1.2 Gerência do Escopo do Projeto
A gerência do escopo do projeto inclui os

processos requeridos para assegurar que o
projeto inclua todo o trabalho necessário,
e tão somente o trabalho necessário, para
complementar de forma bem sucedida
o projeto. A preocupação fundamental
compreende definir e controlar o que está
ou não incluído no projeto.
O Gerenciamento do Escopo do Projeto refere-se à definição de todas

as atividades do projeto necessáras ao cumprimeento das metas. Essses
processos, altamente interativos, definem e controlam o que faz ou não
parte do projeto. Eles ocorrem pelo menos uma vez – e, com frequência,
várias vezes – durante o ciclo de vida do projeto.
O Gerencimento do Escopo do Projeto compreende tanto o escopo do

produto4 quanto o escopo do projeto5. O escopo do produto refere-se
às características do produto ou serviço do projeto, e é contraposto
aos requisitos do projeto para determinar sua conclusão; em geral é
a área de aplicação que determina quais ferramentas e técnicas serão
usadas para definí-lo e gerenciá-lo. Já o escopo do projeto envolve a
administração da execução do projeto, e só a execução do projeto; é
confrontado com plano do projeto, declaração de escopo e estrutura
analítica do projeto (EAP6).
Na área de tecnologia de informação, o escopo do produto

normalmente é especificado em um documento denominado:
Documento de Requisitos. Neste documento encontram-se todas as
funcionalidades do sistema especificadas pelo cliente.
Utiliza-se este documento como contrato entre as partes: cliente e a
empresa de software responsável pelo desenvolvimento do sistema.
4
As características e funções que descrevem um produto, serviço ou resultado.
5
O trabalho que deve ser realizado para entregar um produto, serviço ou resultado
com as características e funções especificadas.
6
Estrutura Analítica de Projetos (EAP), do Inglês Work breakdown structure (WBS), é
uma ferramenta de decomposição do trabalho do projeto em partes manejáveis
25
Resumindo, na área de tecnologia de informação teríamos dois

documentos principais para detalhar o escopo do produto e do projeto:
• Escopo do Produto: Documento de Requisitos
• Escopo do Projeto: Plano de Projeto
• Planejamento do Escopo - desenvolver uma declaração escrita do

escopo como base para decisões futuras do projeto.
• Definição do Escopo - desenvolver uma declaração do escopo

detalhada do projeto como base para futuras decisões do projeto.
• Criação da EAP - subdividir as principais entregas do projeto

e do trabalho do projeto em componentes menores e mais
facilmente gerenciáveis.
• Verificação do Escopo - formalizar a aprovação do escopo do projeto.
• Controle de Mudanças de Escopo - controlar as mudanças do

escopo do projeto.
2.1.3 Gerência do Tempo do Projeto
A gerência do tempo do projeto inclui os

processos necessários para assegurar que o
projeto será implementado no prazo previsto.
Essa área de conhecimento envolve a

estimativa da duração das atividades do plano
do projeto, a elaboração do cronograma do projeto e o monitoramento
e controle dos desvios do cronograma. Em termos gerais, essa área trata
da conclusão do projeto em tempo hábil. O gerenciamento do tempo é
um aspecto importante do gerenciamento de projetos, pois envolve a
manutenção das atividades do projeto em dia e a contraposição dessas
atividades ao plano do projeto para garantir que ele seja concluído
dentro do prazo.
• Definição das Atividades - identificar as atividades específicas

que devem ser realizadas para produzir os diversos subprodutos
do projeto.
26
• Sequenciamento das Atividades - identificar e documentar as

relações de dependência entre as atividades.
• Estimativa da Duração das Atividades - estimar a quantidade de

períodos de trabalho que serão necessários para a implementação
de cada atividade.
• Estimativa de Recursos das Atividades - estimar o tipo e a quantidade

de recursos necessários para realizar cada atividade do cronograma.
• Desenvolvimento do Cronograma - analisar a sequência e as

durações das atividades, e os requisitos de recursos para criar o
cronograma do projeto.
• Controle do Cronograma - controlar as mudanças no

cronograma do projeto.
5. A área de conhecimento Gerenciamento da Integração do

Projeto é composta por quais processos?
a. Iniciação, Desenvolvimento do Plano do Projeto, e Controle
Integrado de Mudanças
b. Desenvolvimento do Plano do Projeto, Execução do Plano do
Projeto e Controle Integrado de Mudanças
c. Desenvolvimento do Plano do projeto, Iniciação e
Planejamento do Escopo
d. Iniciação, Planejamento do Escopo e Controle Integrado de
Mudanças
6. Você é gerente de projetos dos pacotes de viagem da BrasilTur
e está responsável por gerenciar a abertura do novo resort da
empresa em Florianópolis, Santa Catarina. Você está calculando
as estimativas de duração das atividades, criando o cronograma do
projeto e monitorando e controlando os desvios no cronograma.
Em qual das áreas de conhecimento está trabalhando?
a. Gerenciamento do Escopo do Projeto
b. Gerenciamento da Qualidade do Projeto
c. Gerenciamento da Integração do Projeto
d. Gerenciamento do Tempo do Projeto
7. Qual alternativa abaixo corresponde a um processo de
gerenciamento da integração do projeto?
a. Desenvolvimento do cronograma
27
b. Verificação do escopo
c. Desenvolver a equipe do projeto
d. Monitorar e controlar o trabalho do projeto
8. Complete corretamente a informação com um dos itens
indicados a seguir: “ ______ documenta as ações necessárias para
definir, preparar, integrar e coordenar todos os planos auxiliares.”
a. Plano de gerenciamento do projeto
b. Informações sobre o desempenho do projeto
c. Documento de caso de uso
d. Análise de viabilidade
9. O que é escopo de projeto?
a. Todos os requisitos de um produto.
b. A ideia inicial do projeto a partir da qual serão retiradas as
características do sistema.
c. Todo trabalho necessário para se realizar um projeto.
d. Todas as métricas de um projeto.
10. O que é escopo de produto?
a. Requisitos de um sistema.
b. Proposta inicial para o desenvolvimento de um produto.
c. Características e funcionalidades que caracterizam um
produto.
d. Características e funcionalidades que dão origem a um projeto.
11. O que significa EAP?
a. Estudo e análise de projeto
b. Especificação da avaliação do projeto
c. Estrutura analítica do projeto
d. Estrutura analítica do produto
12. Qual das alternativas abaixo contém APENAS processos que
dizem respeito à gestão de tempo do projeto?
a. Estimativa de recursos da atividade, estimativa de duração da
atividade, criar estrutura analítica do projeto.
b. Definição das atividades, sequenciamento das atividades,
desenvolver o plano de projeto.
28
c. Desenvolvimento do cronograma, controle do cronograma e

encerrar o projeto.
d. Definição das atividades, sequenciamento das atividades,
estimativa de duração da atividade.
2.1.4 Gerência do Custo do Projeto
A gerência do custo do projeto inclui os

processos necessários para assegurar
que o projeto será concluído dentro do
orçamento aprovado.
As atividades dessa área de conheci-

mento definem estimativas de custos e
recursos e controlam tais custos para
garantir que o projeto permaneça dentro do orçamento aprovado. O
centro de suas atenções é o custo dos recursos, embora outros custos
também possam ser levados em conta.
• Estimativa dos Custos - desenvolver uma estimativa dos custos dos

recursos necessários à implementação das atividades do projeto.
• Elaboração de Orçamento de Custos - agregar os custos

estimados de atividades individuais para estabelecer uma linha
de base7 dos custos.
• Controle dos Custos - controlar as mudanças no orçamento

do projeto.
2.1.5 Gerência da Qualidade do Projeto
A gerência da qualidade do projeto inclui os

processos requeridos para garantir que o projeto
irá satisfazer às necessidades para as quais ele foi
empreendido.
A área de conhecimento Gerenciamento da

Qualidade do Projeto assegura que o projeto
7
A linha de base (baseline) do custo é o orçamento referencial que será utilizado para
medir e monitorar o desempenho do custo do projeto. É desenvolvido através da
totalização das estimativas de custo por período.
29
atenda aos requisitos com os quais se comprometeu, concentrando-se

na qualidade do produto e na qualidade do processo de gerenciamento
de projeto empregado durante o ciclo de vida do projeto.
• Planejamento da Qualidade - identificar quais padrões de qualidade

são relevantes para o projeto e determinar a forma de satisfazê-los.
• Garantia da Qualidade - avaliar periodicamente o desempenho

geral do projeto buscando assegurar a satisfação dos padrões de
qualidade relevantes.
• Controle da Qualidade - monitorar os resultados específicos do

projeto para determinar se eles estão de acordo com os padrões de
qualidade relevantes e identificar as formas para eliminar as causas
de desempenhos insatisfatórios.
2.1.6 Gerência de Recursos Humanos do Projeto
A gerência dos recursos humanos do

projeto inclui os processos requeridos para
possibilitar o uso mais efetivo das pessoas
envolvidas com o projeto.
O Gerenciamento de Recursos Humanos do

Projeto abrange todos os aspectos do gerenciamento e da interação das
pessoas, incluindo liderança, orientação, resolução de conflitos, avaliações
de desempenho e muito mais.
• Planejamento de Recursos Humanos - identificar e documentar as

funções, responsabilidades e relações hierárquicas do projeto, além
da criação do plano de gerenciamento de pessoal8.
• Montagem da Equipe - conseguir que os recursos humanos

necessários sejam designados e alocados ao projeto.
• Desenvolvimento da Equipe - desenvolver habilidades individuais

e do grupo para aumentar o desempenho do projeto.
• Gerenciamento da Equipe - acompanhar o desempenho de
8
Documento que descreve quando e como os recursos humanos necessários serão
atingidos. Ele faz parte ou é um plano auxiliar do plano de gerenciamento do projeto.
30
membros da equipe, fornecendo feedback9, resolvendo problemas e

coordenando as mudanças para melhorar o desempenho do projeto.
13. O baseline (linha de base) do custo é o orçamento referencial

que será utilizado para medir e monitorar o desempenho do custo
do projeto. É desenvolvido através da totalização das estimativas
de custo por período.
a. Em que processo do Gerenciamento do Custo do Projeto é
gerada a linha de base do custo?
b. Estimativa de custos
c. Elaboração de Orçamento de Custos
d. Controle de custos
e. Planejamento de custo
14. Qual alternativa abaixo define requisitos de maneira mais completa:
a. Necessidades, desejos e expectativas quantificados e
documentados do cliente e de outras partes interessadas.
b. Datas de entrega do produto levantadas junto ao cliente na
finalidade de estabelecer prazos.
c. Padrões de qualidade utilizados no processo de desenvolvimento
do projeto.
d. Planejamento da qualidade, garantia da qualidade e controle
da qualidade.
15. Não é um processo de gerenciamento de recursos humanos:
a. Planejamento de recursos humanos
b. Contratar ou mobilizar a equipe de projeto
c. Estimativas de recursos das atividades
d. Desenvolver a equipe do projeto
16. Qual desses é o processo de obtenção dos recursos humanos
necessários para terminar o projeto?
a. Planejamento de recursos humanos
b. Montagem da equipe de projeto
c. Estimativas de recursos das atividades
d. Desenvolver a equipe do projeto
9
Feedback é o procedimento que consiste no provimento imediato, específico e
factível de informação a uma pessoa sobre o desempenho, conduta ou eventualidade
executada por ela e objetiva reprimir, reorientar e/ou estimular uma ou mais ações
determinadas, executadas anteriormente.
31
2.1.7 Gerência das Comunicações do Projeto
A gerência das comunicações do projeto

inclui os processos requeridos para garantir
a geração apropriada e oportuna, a coleta, a
distribuição, o armazenamento e o controle
básico das informações do projeto.
Essa área de conhecimento inclui os seguintes

processos principais:
• Planejamento das Comunicações - determinar as informações e

comunicações necessárias para os interessados: quem necessita de
qual informação, quando necessitarão dela e como isso será fornecido.
• Distribuição das Informações - disponibilizar as informações

necessárias para os interessados no projeto no momento adequado.
• Relatório de Desempenho10 - coletar e disseminar as informações

de desempenho. Isso inclui relatórios de situação, medição de
progresso e previsões.
• Gerenciamento dos Stakeholders - gerenciar as comunicações para

satisfazer os requisitos das partes interessadas no projeto e resolver
problemas com elas.
2.1.8 Gerência de Risco do Projeto
A gerência de risco é o processo sistemático

de identificar, analisar e responder ao
risco do projeto. Ele inclui maximizar a
probabilidade e consequências dos eventos
positivos e minimizar a probabilidade e
consequências dos eventos adversos para
o objetivo do projeto.
Os riscos representam, ao mesmo tempo, ameaças e oportunidades.

Os processos dessa área de conhecimento referem-se à identificação,
análise e planejamento de riscos potenciais que podem afetar o
projeto – incluída aí a minimização de sua probabilidade e suas
consequências. Também são úteis para identificar as consequências
positivas do risco e explorá-las.
10
Os relatórios de desempenho organizam e sintetizam as informações coletadas e
apresentam os resultados de qualquer análise comparados com a linha de base da
medição de desempenho.
32
• Planejamento do Gerenciamento de Riscos - decide como abordar e

planejar as atividades de gerência de risco para um projeto.
• Identificação de Riscos - determina quais riscos podem afetar o

projeto e documenta suas características.
• Análise Qualitativa de Riscos - realiza uma análise qualitativa dos

riscos e as condições para priorizar seus efeitos nos objetivos do projeto.
• Análise Quantitativa de Riscos - mede a probabilidade e as

consequências dos riscos e estima suas implicações para os
objetivos do projeto.
• Planejamento de Respostas ao Risco - desenvolve procedimentos e

técnicas para melhorar as oportunidades e reduzir as ameaças para
os objetivos do projeto.
• Monitoramento e Controle de Riscos - monitora riscos residuais11,

identifica novos riscos, executa planos de redução de riscos e avalia
sua eficácia durante todo o ciclo de vida do projeto.
2.1.9 Gerência de Aquisição do Projeto
A gerência de aquisição tem por objetivo principal

obter bens e serviços externos à organização
executora. Consistem no planejamento de
aquisições, planejamento de solicitações,
solicitação de resposta dos fornecedores, seleção
de fornecedores, gerenciamento de contratos e
encerramento de contratos.
• Planejamento de Aquisições - determinação do que comprar ou

adquirir e de quando e como fazê-lo
• Planejamento de Solicitações - documentação dos requisitos

de produtos, serviços e resultados e identificação de possíveis
fornecedores.
• Solicitação de Respostas dos Fornecedores - obtenção de informações,

cotações, preços, ofertas ou propostas, conforme adequado.
11
Riscos que se espera que permaneçam após a realização das respostas planejadas,
além dos que foram deliberadamente aceitos.
33
• Seleção de Fornecedores - análise de ofertas, escolha entre

possíveis fornecedores e negociação de um contrato por escrito
com cada fornecedor.
• Gerenciamento de Contratos - gerenciamento do contrato e da

relação entre o comprador e o fornecedor.
• Encerramento de Contratos - terminar e liquidar cada contrato,

inclusive a resolução de quaisquer itens em aberto, e encerrar cada
contrato aplicável ao projeto ou a uma fase do projeto.
Vamos resumir o conteúdo visto neste capítulo: Aprendemos que

os projetos percorrem um ciclo de vida, composto por fases, ao
longo do qual os grupos de processos descritos no Guide to the
PMBOK (Iniciação, Planejamento, Execução, Monitoramento e
Controle, e Encerramento) são realizados. Além disso, existem
nove áreas de conhecimento que agrupam os processos com
características comuns.
17. Relacione os processos com suas respectivas áreas de

conhecimento:
Processos Áreas de Conhecimento
( ) Gerência da Integração do
(a) Planejamento de Solicitações
Projeto
(b) Estimativa dos Custos ( ) Gerência do Escopo do Projeto
(c) Definição das Atividades ( ) Gerência do Tempo do Projeto
(d) Criação da EAP ( ) Gerência do Custo do Projeto
( ) Gerência da Qualidade do
(e) Identificação de Riscos
Projeto
( ) Gerência de Recursos Humanos
(f ) Distribuição de Informações
do Projeto
( ) Gerência das Comunicações do
(g) Planejamento da Qualidade
Projeto
(h) Des. do Termo de Abertura ( ) Gerência de Risco do Projeto
( ) Gerência de Aquisição do
(i) Montagem da Equipe
Projeto
18. Qual dos citados abaixo não faz parte dos processos do
gerenciamento das comunicações do projeto?
a. Planejamento das comunicações
b. Distribuição das informações
c. Desenvolver a equipe do projeto
d. Relatório de desempenho
34
19. Leia o texto abaixo:

“...é a área de conhecimento que emprega os processos necessários
para garantir a geração, coleta, distribuição, armazenamento,
recuperação e destinação final das informações sobre o projeto de
forma oportuna e adequada.”
Esse texto refere-se a uma área de gerenciamento, que é:
a. Gerenciamento de Tempo do projeto
b. Gerenciamento de Escopo do projeto
c. Gerenciamento de Comunicação do projeto
d. Gerenciamento de Recursos Humanos do projeto
20. Os riscos ...
a. representam apenas ameaças ao bom desenvolvimento do
projeto.
b. representam, ao mesmo tempo, ameaças e oportunidades
relacionadas ao projeto.
c. representam apenas oportunidades que contribuem ao bom
desenvolvimento do projeto.
d. existem em todos os projetos, por isso não precisamos
identificá-los.
[1] PROJECT MANAGEMENT INSTITUTE - PMI. A guide to the

project management body of knowledge. Syba: PMI Publishing
Division, 2004 – Capítulos 03, 04, 05, 06, 07, 08, 09, 10, 11 e 12.
processos
3.1 ENTENDENDO PROCESSOS
Não confunda estes processos com os processos mencionados

no Capítulo 2. Os processos mencionados anteriormente são
atividades das áreas de conhecimento do padrão de Gerência
de Projetos - PMBOK. Os processos aqui mencionados estão
relacionados a um conjunto de atividades a serem realizadas para
a elaboração de um produto.
Normalmente utilizamos processos para concretizarmos um projeto.

Isso significa dizer que utilizamos processos para gerar produtos ou
realizarmos serviços.
As engenharias comumente descrevem processos como sendo diversas

operações pelas quais passa um produto até ele ficar pronto. O IEEE
(Institute of Electrical and Electronic Engineers) define processo como
uma sequência de passos realizados para um determinado propósito [3].
Esta definição pode ser aplicada a qualquer atividade, seja ela da

manufatura ou não.
Agora vamos voltar um pouco para uma realidade mais próxima,

na qual nossos projetos têm normalmente a finalidade de produzir
softwares como produtos. Para tais tipos de projetos, utilizamos
processos de desenvolvimento de software. E, associado à execução
de processos de desenvolvimento de software, devemos ter processos
de gerência de software na finalidade de garantir que o projeto
atenda às espectativas do cliente.
3.1.1 Processo de Desenvolvimento de Software
Processo de Software é um conjunto de atividades, métodos,

práticas e tecnologias que as pessoas utilizam para desenvolver e
manter software e seus produtos relacionados [4].
36
Figura 3 - Processo e seus componentes
Definição de Processo de Software
Procedimentos
e métodos que definem o
relacionamento de tarefas
A D
PROCESSO
Pessoas com habilidades

treinamento e motivação Ferramentas e
Equipamentos
Fonte: [4] – Paulk et al. , 1995. Adaptação.
A Figura 3 ilustra a definição de Processo de Desenvolvimento de Software.
Considerando que o software é resultado do processo de desenvolvimento,

espera-se que a sua qualidade seja altamente influenciada pela qualidade
do processo que o gera.
3.1.2 Processo de Gerência de Projetos de Software
Podemos entender o Processo de Gerência de Projetos de Software

como sendo um conjunto de atividades que descrevem, organizam e
monitoram as atividades do desenvolvimento do software, na finalidade
de fazer com que o software elaborado no projeto atenda ou supere as
expectativas do cliente.
3.1.3 Interação entre os Processos de Desenvolvimento e

de Gerência de Projetos de Software
Qual é a relação entre Processos de Desenvolvimento de Software e

Processos de Gerência de Projetos de Software?
Na tentativa de entender melhor esta interação, observe a Figura 4:

37
Figura 4 - Processo e seus componentes
PROCESSO DE DESENVOLVIMENTO
DE SOFTWARE - PDS - Ifes
Disciplina de Gerência de Projeto - Versão 1.0
CONCEPÇÃO ELABORAÇÃO CONSTRUÇÃO TRANSIÇÃO
Início Fim
PMBOK PROCESSO DE GERÊNCIA DE PROJETOS

DE SOFTWARE - PGPS - Ifes
Disciplina de Gerência de Projeto - Versão 1.0
Na Figura 4, observamos dois processos:
• Processo de Desenvolvimento de Software – PDS-IFES: Este processo

é composto pelas fases de concepção, elaboração, construção e
transição. Essas fases representam os ciclos de vida de um projeto,
e em cada uma delas existem diversas atividades a serem realizadas
para construção de um software.
• Processo de Gerência de Projetos de Software – PGPS-IFES: Este

processo é composto por diversas atividades na finalidade de planejar
e acompanhar o desenvolvimento de um software. Observe que este
processo foi elaborado tendo como base teórica os conhecimentos
do PMBOK (Capítulo 2 deste material).
Ainda na Figura 4, denota-se a interação existente entre um Processo

de Desenvolvimento de Software e o Processo de Gerência de Projetos
de Software por meio das setas, as quais indicam que as atividades de
ambos os processos se relacionam.
A principal ideia a ser entendida neste momento é a de que,

para construirmos um software, precisamos de um Processo de
Desenvolvimento de Software, ou seja, de um conjunto de atividades
com a finalidade em comum de elaboração de um software. Todavia,
para que este software atenda, ou mesmo supere, as espectativas do
cliente, dependemos da execução de atividades relacionadas à gerência
38
de projetos de software. Estas atividades podem ser detalhadas por meio

de um Processo de Gerência de Projetos de Software.
Estes processos interagem entre si à medida em que o software começa

a ser construído. Enquanto, de um lado, atividades do Processo de
Desenvolvimento de Software são executadas, de outro, atividades do
Processo de Gerência de Projetos de Software também são trabalhadas
pelo gerente de projeto. Estas últimas, planejam as atividades de
desenvolvimento de software e tentam garantir que este desenvolvimento
permaneça dentro do que foi planejado.
Entenderemos mais sobre Processo de Desenvolvimento de Software

e Processo de Gerência de Projetos de Software utilizando-os. Para
esta disciplina foram elaborados dois processos: PDS-IFES (Processo
de Desenvolvimento de Software) e PGPS-IFES (Processo de Gerência
de Projetos de Software). Iremos focar no PGPS-IFES, e a ideia é fazer
com que vocês planejem um projeto de software utilizando-o.
Na sua opinião, quais seriam as consequências da utilização de

um Processo de Desenvolvimento de Software sem nenhum tipo
de planejamento ou acompanhamento da gerência de software?
3.2 UTILIZANDO PROCESSOS
Nesta seção, vamos efetivamente utilizar o Processo de Gerência de

Projetos de Software elaborado especificamente para esta disciplina.
Assim, você poderá entender cada uma das atividades existentes no
Processo de Gerência de Projetos de Software.
Entendendo cada uma destas atividades e realizando-as na
prática para um determinado projeto, você compreenderá o que
faz um gerente de projeto.
3.2.1 Processo de Desenvolvimento de Software
É muito importante que você note que nosso foco não é o Processo
de Desenvolvimento de Software. As atividades desse processo estão
sendo trabalhadas em outras disciplinas do curso. Ex.: quando você
aprende a programar, você está, na verdade, aprendendo uma das
atividades de um Processo de Desenvolvimento de Software (Atividade
denominada Implementar).
39
Todavia, embora nesta disciplina não tenhamos o foco neste processo,

é muito importante entender, de uma maneira geral, quais são as
atividades desse processo, ou seja, de acordo com este processo, quais
atividades devem ser realizadas para a elaboração de um software
como produto.
A Figura 5 mostra as atividades identificadas para o PDS-IFES (Processo

de Desenvolvimento de Software do IFES).
Cada empresa pode ter um Processo de Desenvolvimento de Software

diferente. Ou seja, cada empresa, de acordo com a sua realidade, pode
optar por executar determinadas atividades, e deixar de realizar outras,
durante o desenvolvimento de um software.
Em cada uma das atividades, temos artefatos12 de entrada e de saída.

Alguns destes artefatos podem ser templates13. Além disso, cada atividade
do processo é caracterizada pelo responsável por sua realização.
Na Figura 6 temos a legenda para os símbolos utilizados no Processo de

Desenvolvimento de Software (PDS-IFES) e no Processo de Gerência de
Projetos de Software (PGPS-IFES):
Observe que algumas atividades estão em cinza na Figura 5. Isso

significa que não serão realizadas nesta disciplina, apenas estão
sendo mostradas para dar uma ideia real de quais atividades
normalmente são realizadas durante o desenvolvimento de um
software, dentro de uma empresa de desenvolvimento de software.
As atividades que nos interessam nesta disciplina são as atividades
da fase de concepção, a saber: Levantar Requisitos, Organizar
Requisitos e o Processo de Gerência de Projetos de Software. Este
último está representado de maneira diferente na Figura 5, pois
não se trata apenas de uma atividade, todavia de um conjunto de
atividades. Estas atividades, relacionadas ao Processo de Gerência
de Projetos de Software, representam as atividades que um gerente
de projetos deve executar para gerenciar um determinado projeto.
12
Documento produzido em uma determinada atividade.
Documento modelo com a finalidade de facilitar o preenchimento. Este docuemento
13
contém instruções de preenchimento para um determinado artefato, e deve ser

preenchido de acordo com tais instruções.
40
PDS - Processo de Desenvolvimento de Software baseado no Processo Unificado - RUP
Concepção Elaboração (i) Elaboração (ii) Construção Transição

Sub-Fase Análise Sub-Fase Projeto
Início
DES CO
DCP P
DCU P
DR A
A Elaborar Elaborar Diagrama Implementar Implantar
Levantar A
Casos de Uso de Classes de
Requisitos
Projeto DS
xDES
DP DR DC
xDR DOR
DOR BD
A DC P
Organizar P
Requisitos A Construir Elaborar Testar Fim
Modelo Bando de Dados
DP Conceitual
xDOR DCP
DES
Figura 5 - Processo de Desenvolvimento de Software
DR
Sim, ainda
existe requisitos
PP DS de Cadastros ou
GP Relatório/
P Elaborar Listagens
PROCESSO DE GERÊNCIA DE PROJETOS
DE SOFTWARE - PGPS - Ifes Diagramas de Existem mais
Disciplina de Gerência de Projeto - Versão 1.0 Sequência alterações?

DCP
DOR DES
Sim, ainda existem

requisitos de Casos de Uso
41
Figura 6 - Legenda para Processo de Desenvolvimento de Software
ARTEFATOS PAPÉIS
DP: Descrição de Projetos A: Análise de Sistemas

DOR: Doc de Organização de Req. P: Programador
DR: Documento de Requisitos GP: Gerente de Projeto
DES: Descrição de Caso de Uso
DCU: Diagrama de Casos de Uso SÍMBOLOS
DC: Diagrama de Classes
Início ou fim do processo
DS: Diagrama de Sequência
CO1: Código Fonte Alto Nível Atividade
CO2: Código Fonte com Interface Gráfica
Condição
CO3: Código Fonte Final do Requisito
BD: Banco de Dados Papel
PP: Plano de Projeto
Artefato de saída
OBS: Todo artefato precedido do “x” é um
template (modelo de preenchimento)
Artefato de entrada
A seguir, eis uma definição para cada uma das três atividades do Processo
de Desenvolvimento de Software (PDS-IFES) que iremos utilizar nesta
disciplina:
Tabela 1 - Atividades de Processo de Desenvolvimento de Software (Parte 1)

Fase do
Nome da
ID Ciclo de Finalidade da Atividade
Atividade
Vida
Identificar as necessidades do cliente
quanto ao sistema a ser desenvolvido,
Levantar documentando os requisitos em um
1 Concepção
Requisitos documento denominado Documento de
Requisitos, o qual representa o contrato
de comprometimento com o cliente.
Organizar todos os requisitos
identificados e documentados na
atividade anterior. Estes requisitos
devem ser organizados em: Casos
Organizar
2 Concepção de Uso (funcionalidades complexas),
Requisitos
Manutenção de Cadastros
(funcionalidades de inserção, alteração
e remoção) e Consultas (relatórios e
listagens).
42
Tabela 1 - Atividades de Processo de Desenvolvimento de Software (Parte 2)

Fase do
Nome da
ID Ciclo de Finalidade da Atividade
Atividade
Vida
Esta não é uma atividade simples.
Processo de
Representa um conjunto de atividades
Gerência de
3 Concepção relacionadas às atribuições de um
Projetos de
Gerente de Projetos. Trata-se do PGPS-
Software
IFES (Figura 7).
3.2.2 Processo de Gerência de Projetos de Software
A Figura 7 mostra as atividades definidas para o Processo de Gerência

de Projetos de Software.
Figura 7 - Processo de Gerência de Projetos de
Software
Integração
Fim
PP_09
Gerência de
9 - Planejar
Riscos
Riscos
PP_08
GP
PP_11
Comunicações
Comunicações
11 - Planejar
PP_10
GP
CP_02
PP_04
Recursos
4 - Planejar
Recursos
CP_01
PP_03
GP
PP_10
Qualidade
10 - Planejar
Qualidade
PP_09
GP
CP_05
PP_08
CP_03
PP_05
Infraestrutura
8 - Estimar
5 - Planejar
Custo
Custos
CP_04
PP_07
CP_02
PP_04
GP
GP
CP_01
PP_03
PP_06
TE_01
CP_04
PP_07
Cronograma
Desenvolver
Atividades
Duração de
3 - Definir
Tempo
PP_05 Atividades
6 - Estimar
7-
PP_02
CP_03
xCO
CP_03
PP_06
DR
xTE
GP
GP
GP
PP_02
PP_01
1 - Levantar
2 - Detalhar
Escopo
Escopo
Escopo
Início
PP_01
DOR
xPP
DP
GP
ou
GP
A
43
A seguir, podemos observar na Tabela 2 as finalidades de cada uma

das atividades do Processo de Gerência de Projetos de Software
(PGDS-IFES):
Tabela 2 - Atividades de Processo de Gerência de Projetos de Software (Parte 1)

Nome da Área do
ID Finalidade da Atividade
Atividade Conhecimento
Desenvolver uma
declaração escrita do
1 Planejar Escopo Escopo
escopo como base para
decisões futuras do projeto.
Subdividir os principais
subprodutos do projeto em
2 Detalhar Escopo Escopo
componentes menores e
mais fáceis de gerenciar.
Identificar as atividades
específicas que devem ser
3 Definir Atividades Tempo realizadas para produzir os
diversos subprodutos do
projeto.
Identificar, documentar
e designar as funções,
4 Planejar Recursos Recursos responsabilidades e
relacionamentos de reporte
dentro do projeto.
Determinar quais recursos
(equipamentos, materiais) e
Planejar que quantidade de cada um
5 Custo
Infra-Estrutura deles deve ser usada para
executar as atividades do
projeto.
Estimar a quantidade de
períodos de trabalho que
Estimar Duração
6 Tempo serão necessários para a
de Atividades
implementação de cada
atividade.
Analisar a sequência e as
durações das atividades, e
Desenvolver
7 Tempo os requisitos de recursos
Cronograma
para criar o cronograma do
projeto.
Desenvolver uma
estimativa dos custos
8 Estimar Custos Custo dos recursos necessários
à implementação das
atividades do projeto.
44
Tabela 2 - Atividades de Processo de Gerência de Projetos de Software (Parete 2)

Nome da Área do
ID Finalidade da Atividade
Decidir como abordar e
planejar as atividades de
gerência de risco para um
Planejar Gerência
9 Riscos projeto. Determina quais
de Riscos
riscos podem afetar o
projeto e documentar suas
características.
Identificar quais padrões de
Planejar qualidade são relevantes
10 Qualidade
Qualidade para o projeto e determinar
a forma de satisfazê-los.
Determinar as informações
e comunicações necessárias
para os interessados:
Planejar
11 Comunicações quem necessita de qual
Comunicações
informação, quando
necessitarão dela e como
isso será fornecido.
Os artefatos gerados em cada uma das atividades citadas na tabela

anterior estão mostrados na Tabela 3:
Tabela 3 - Artefatos do Processo de Gerência de Projetos de Software (Parte 1)

Nome da Área do
ID Artefatos de Saída
PP_01: Plano de Projeto -
1 Planejar Escopo Escopo
Versão 01
2 Detalhar Escopo Escopo
Versão 02
Versão 03
3 Definir Atividades Tempo
CP_01: Cronograma do
Projeto – Versão 01
Versão 04
4 Planejar Recursos Recursos
Planejar Versão 05
5 Custo
Infra-Estrutura CP_03: Cronograma do
45

Estimar Duração Versão 06
6 Tempo
de Atividades TE_01: Tabela de
Estimativas – Versão 01
Tabela 3 - Artefatos do Processo de Gerência de Projetos de Software (Parte 2)
Nome da Área do
ID Artefatos de Saída
Desenvolver Versão 07
7 Tempo
Cronograma CP_04: Cronograma do
Versão 08
8 Estimar Custos Custo
Projeto – Versão 05 *
Planejar Gerência PP_09: Plano de Projeto -
9 Riscos
de Riscos Versão 09
10 Planejar Qualidade Qualidade
Versão 10
Planejar PP_11: Plano de Projeto -
11 Comunicações
Comunicações Versão 11 *
* Representam as últimas versões do Plano de Projeto e Cronograma
Seguem as descrições para os artefatos de saída do PGPS-IFES:
• PP - Plano de Projeto: Este documento compreende informações

importantes a respeito do planejamento de um projeto. Inclui
informações sobre todas as áreas de conhecimento de gerência
de projetos, ajudando o Gerente de Projeto em suas atividades de
gestão do projeto.
• CP - Cronograma do Projeto: Este arquivo compreende o

cronograma do projeto, os recursos envolvidos, bem como as datas
de início e término para cada uma das atividades necessárias para a
concretização do projeto.
• TE - Tabela de Estimativas: Esta planilha contém o tempo estimado

para a realização das atividades do projeto.
46
PROCESSO DE GERÊNCIA DE
PROJETO DE SOFTWARE
As informações a seguir têm a finalidade de explicar cada uma das

atividades existentes no Processo de Gerência de Projetos de Software
– PGPS-IFES, elaborado para a disciplina de Gerência de Projetos do
Curso de Licenciatura em Informática com base no PMBOK.
1- Planejar Escopo
Finalidade
Desenvolver uma declaração escrita do escopo como base para
decisões futuras do projeto.
Artefatos de Entrada: Artefatos de Saída:
Documento de Requisitos Plano de Projeto – Versão 01
Documento de Organização de
Requisitos
Template do Plano de Projeto
Papel: Gerente de Projeto
Ferramentas: Word (Microsoft) ou Writer (OpenOffice)
Passos Resumidos:
Preencher a Seção 1 Introdução do Template do Plano de Projeto;
Preencher a Subseção 2.1 Planejamento do Escopo do Template do Plano

de Projeto: Subseção 2.1.1 Documentação dos Requisitos e Subseção
2.1.2 Plano de Iteração.
Passos Detalhados:
1. Ler o Documento de Requisitos;
1.1. Observar, neste documento, todas as funcionalidades identificadas

para o sistema a ser construído, ou seja, o escopo do sistema. Este
documento é a base para todo o desenvolvimento do sistema. O Plano de
Projeto (outro documento produzido pelo Gerente de Projetos) leva em
consideração tudo o que foi identificado no Documento de Requisitos;
1.2. Observar também, neste documento, que os Requisitos Funcionais

(Seção 3) estão divididos entre: 3.1 Requisitos de Cadastros, 3.2
Requisitos de Casos de Uso e 3.3 Requisitos de Listagens/Relatórios.
48
Isso será importante para os passos posteriores;
2. Ler o Documento de Organização de Requisitos;
2.1. Observar, neste documento, que todas as funcionalidades do

sistema são subdividas considerando as subseções mencionadas no item
1.2, descrito anteriormente;
2.2. Importante: Todo o desenvolvimento do nosso sistema levará

em consideração a subdivisão mostrada neste documento. Como boa
prática de Engenharia de Software, primeiramente serão considerados
no desenvolvimento os requisitos que representam casos de uso (ou
seja, as funcionalidades mais complexas do sistema); Posteriormente
serão considerados os requisitos relacionados a cadastros (ou seja,
as funcionalidades de manutenção de cadastros do sistema, tais
como: inserção, alteração, remoção e visualização); E, por fim, serão
considerados os requisitos relacionados a relatórios (ou seja, as
funcionalidades de listagens/relatórios identificadas do documento de
requisitos do sistema);
2.3. Importante: O Desenvolvimento de Software considerado pelo

Processo de Desenvolvimento de Software PDS-IFES é do tipo iterativo
e incremental. Isso significa dizer que não vamos programar todos os
requisitos do sistema de uma vez só, mas sim que o nosso desenvolvimento
prescreve a construção de uma porção pequena, mas abrangente, do
projeto de software a cada etapa. Cada porção desta é desenvolvida
no que chamamos de iteração. Para o completo desenvolvimento do
sistema são necessárias n iterações. Em cada etapa de desenvolvimento,
vamos escolher uma determinada quantidade de requisitos para serem
desenvolvidos;
3. Preencher o Template, ou seja, o modelo não preenchido, do Plano de

Projeto – Capa;
3.1. Preencher a Capa;
3.1.1. Inserir o logotipo do cliente no espaço reservado para tal na capa e

no rodapé do Plano de Projeto. Cada grupo deverá escolher uma imagem
para o seu cliente, bem como o nome do cliente, a sigla do projeto, etc.
3.1.2. Substituir os trechos que estão em entre “<>” pelo que está sendo
solicitado.
3.1.3. Descrever o responsável pelo Plano (este deve ser o nome do aluno
escolhido no grupo para ser o Gerente de Projetos);
49
3.1.4. Preencher no rodapé do documento a Sigla do Projeto e a Versão 01;
4. Preencher o Template, ou seja, o modelo não preenchido, do Plano de

Projeto – Seção 1 Introdução;
4.1. Ler a Seção 1: Esta seção é introdutória sobre o Plano de Projeto. A

finalidade desta seção é explicar sucintamente sobre como está dividido
o Plano de Projeto.
4.2. Preencher a Seção 1: Apenas substitua os trechos que estão em entre

“<>” pelo que está sendo solicitado.
5. Preencher o Template, ou seja, o modelo não preenchido, do

Plano de Projeto – Seção 2 Gerenciamento do Escopo – Subseção 2.1
Planejamento do Escopo;
5.1. Ler a Subseção 2.1.1 Documentação dos Requisitos –Template

do Plano de Projeto;
5.2. Preencher a Subseção 2.1.1 Documentação dos Requisitos – Template

do Plano de Projeto: Nesta subseção não existe muita coisa a ser feita.
Esta subseção apenas deixa claro em qual documento estão contidas as
descrições dos requisitos levantados para o sistema a ser desenvolvido.
Basta, então, que você substitua o trecho “<Sigla do Projeto>” pela sigla
escolhida para o seu projeto;
5.3. Ler a Subseção 2.1.2 Plano de Iteração– Template do Plano de Projeto;
5.4. Preencher a Subseção 2.1.2 Plano de Iteração – Template do Plano

de Projeto: Nesta subseção, iremos planejar o desenvolvimento de todos
os requisitos do sistema. A ideia aqui é a de agrupar os requisitos em
iterações (etapas de desenvolvimento). Lembrando sempre da ordem
de desenvolvimento dos requisitos: 1) Casos de Uso; 2) Manutenção de
Cadastros e 3) Listagens / Relatórios;
5.5. Importante: A Tabela 4 mostra o Plano de Iteração elaborado

para o Sistema de Controle de Videolocadora – SCV, todavia o plano
de iteração do seu projeto pode ter mais do que quatro iterações. Cada
grupo tem liberdade de planejar suas iterações com a quantidade de
requisitos que achar mais adequada (considere para seu projeto no
mínimo 4 iterações).
5.5.1. É lógico que nossa principal ideia aqui é mostrar, didaticamente,

a importância de se planejar as iterações em projeto de software. Com a
prática no mercado de trabalho, cada um de vocês irá desenvolver um
maior senso crítico com relação a este tipo de planejamento, fazendo
50
com que a quantidade de requisitos abordados em cada iteração leve em

consideração outros fatores (experiência da equipe de desenvolvimento,
quantidade da equipe, complexidade do sistema, etc.), e não apenas
desta maneira simples como estamos fazendo. Todavia, nesta disciplina,
basta a cada grupo escolher a quantidade de iterações, bem como os
requisitos abordados em cada uma delas.
5.6. Importante: Cada iteração representa um ciclo de desenvolvimento.

Para compreender melhor o que isto significa, podemos observar a
Tabela 4 e perceber que o desenvolvimento do Sistema de Controle
de Videolocadora – SCV foi dividido em 4 iterações (etapas). Na
primeira iteração, temos os requisitos relacionados aos casos de uso
Emprestar Fitas e Devolver Fitas. Na segunda iteração, os requisitos
relacionados aos casos de uso Reservar Fitas, Entrar no Sistema e Sair
do Sistema. Posteriormente, na terceira iteração foram abordados
todos os requisitos de manutenção de cadastros. Por fim, na quarta
iteração, todos os requisitos de Relatórios/Listagem.
5.6.1. Isso indica que, em um primeiro momento, vamos desenvolver

os requisitos (ou funcionalidades) da iteração 1, e depois testá-los e
garantir que estão funcionando corretamente. Somente depois disso,
iremos desenvolver os requisitos da iteração 2, e assim por diante. Todo
o desenvolvimento será realizado de etapa em etapa, conforme foi
planejado no Plano de Iterações.
5.7. Importante: Outro fator importante a ser observado na Tabela

4 é que primeiro vamos desenvolver os requisitos de casos de uso, depois
de manutenção de cadastros e, por último, os requisitos de relatórios.
Estamos considerando esta ordem de desenvolvimento, pois é uma boa
prática de desenvolvimento de software começar o desenvolvimento pelos
requisitos mais complexos (casos de uso – as principais atividades, ou
regras de negócio, da empresa ligadas ao sistema que será implementado),
para depois chegar aos mais simples (relatórios).
5.7.1. A fim de tratar os maiores riscos do sistema nas fases iniciais,

sugere-se que sejam abordados primeiramente os casos de uso, depois
as operações de manutenção de cadastros e, por último, as consultas.
Os riscos maiores estarão fatalmente nos processos de negócio, por
isso inicia-se com os casos de uso. As operações de cadastro seguem
sempre um certo padrão e não apresentam riscos. Por fim, as consultas
não alteram dados no sistema, mas apenas apresentam a informação já
armazenada em um formato específico e apresentam pouquíssimo risco.
51
Figura 8 – Plano de Iteração
Casos de Uso
Iteração Nome Requisitos
1 Emprestar Fitas RF23, RF24, RF25
1 Devolver Fitas RF28
2 Reservar Fitas RF26, RF27
2 Entrar no Sistema RF21
2 Sair do Sistema RF21
Manutenção de Cadastros
3 Funcionário RF1, RF2, RF3, RF4
3 Cliente RF5, RF6, RF7, RF8
3 Funcionário RF9, RF10, RF11, RF12
RF13, RF14, RF15,
3 Filme
RF16
RF17, RF18, RF19,
3 Fita
RF20
Relatórios / Listagens
4 Funcionários RF29, RF30
4 Perfis RF31
4 Clientes RF32, RF33
4 Tipos de Filme RF34
4 Filmes RF35, RF36
4 Fitas RF37, RF38
Estatísticas de
4 RF39, RF40
Empréstimo
4 Estatísticas de Reserva RF41, RF42
4 Empréstimos RF43, RF44
4 Reservas RF45, RF46
6. Armazenar o Plano de Projeto;
6.1. Salvar com o nome <Sigla do Projeto>-PlanoDeProjeto_01.doc

52
2- Detalhar Escopo
Finalidade
Subdividir os principais subprodutos do projeto em componentes
menores e mais manejáveis.
Plano de Projeto – Versão 01 Plano de Projeto – Versão 02
Passos Resumidos:
1. Preencher a Subseção 2.2 Detalhamento do Escopo do Plano

de Projeto – Versão 01.
Passos Detalhados:
1. Preencher a Versão 01 do Plano de Projeto – Seção 2

Gerenciamento do Escopo – Subseção 2.2 Detalhamento
do Escopo;
1.1. Ler a Subseção 2.2 Detalhamento do Escopo do Plano de

1.2. Preencher a Subseção 2.2 Detalhamento do Escopo do Plano de

Projeto – Versão 01: Nesta Subseção elaboraremos a EAP (Estrutura
Analítica do Projeto), que é uma descrição alto nível do escopo do
projeto. Basta, então, que você substitua o trecho “<Sigla do Projeto>”
pela sigla escolhida para o seu projeto.
1.2.1. Importante: A EAP (Estrutura Analítica do Projeto) ou WBS

(Work Breakdown Structure) é uma ferramenta de decomposição
do trabalho do projeto em partes manejáveis. É estrutura em árvore
exaustiva, hierárquica (de mais geral para mais específica) de entregáveis
(deliverables) e tarefas que precisam ser feitas para completar um projeto.
Observe a Figura 9 que mostra a EAP para o Sistema de Controle da
Videolocadora – SCV;
2.1. Salvar com o nome <Sigla do Projeto>-PlanoDeProjeto_02.doc

53
Figura 9 - Estrutura Analítica do Projeto
SCV
Elaboração Elaboração
Concepção (i) (ii) Construção Transição
Sub-Fase Sub-Fase
de Análise de Projeto
Documento Descrição Diagrama Implemen- Implantação

de de Casos de Classes tação
Requisitos de Uso de Projeto
Documento Modelo Banco de Testes

de Conceitual Dados
Organização
de Req.
Plano de Diagramas
Projeto de
Sequência
3 - Definir Atividades
Finalidade
Identificar as atividades específicas que devem ser realizadas para
produzir os diversos subprodutos do projeto.

Documento de Requisitos Plano de Projeto – Versão 030
Plano de Projeto – Versão 02 Cronograma – Versão 01
Template do Cronograma
Ferramentas: Word (Microsoft) ou Writer (OpenOffice) e OpenProj
Passos Resumidos:
1. Preencher a Subseção 3.1 Definição das Atividades do Plano de

Projeto – Versão 02;
54
2. Preencher o Template do Cronograma com as atividades a
serem realizadas durante o desenvolvimento do projeto, bem como suas

relações de dependências mandatórias (aquelas inerentes à natureza do
trabalho que está sendo feito) entre si;
Passos Detalhados:

Gerenciamento de Tempo – Subseção 3.1 Definição das Atividades;
1.1. Ler Subseção 3.1 Definição das Atividades – Versão 02 do Plano

de Projeto;
1.2. Preencher a Subseção 3.1 Definição das Atividades – Versão 02 do

Plano de Projeto: Esta Subseção é apenas informativa, na finalidade
de documentar que a definição das atividades deverá ser realizada
no Cronograma do Projeto. Basta, então, que você substitua o trecho
“<Sigla do Projeto>” pela sigla escolhida para o seu projeto.
2.1. Salvar com o nome <Sigla do Projeto>-PlanoDeProjeto_03
3. Preencher o Template, ou seja, o modelo não preenchido, do

Cronograma do Projeto;
3.1. Ler Documento de Requisitos: Isto será necessário, pois quando

você for preencher o Cronograma do Projeto irá precisar saber o nome
dos requisitos;
3.2. Ler Subseção 2.1.2 Plano de Iteração – Versão 03 do Plano de

Projeto: Isto será muito importante para que você saiba em qual iteração
está cada uma dos requisitos;
3.3. Abrir o Template do Cronograma do Projeto
3.3.1.Importante: Observe as atividades já inseridas no Template

do Cronograma do Projeto. Estas são atividades padrões existentes
em todos os projetos que utilizam o PDS-IFES como processo padrão
de desenvolvimento. É muito importante notar que estas atividades
estão agrupadas por fases do processo de desenvolvimento PDS-IFES:
Concepção, Elaboração (i), Elaboração (ii), Construção e Transição.
Caso estivéssemos utilizando outro processo de desenvolvimento, estas
atividades, bem como as fases de desenvolvimento, seriam outras.
55
3.3.2. Importante: Observe também que as atividades existentes no

Template do Plano de Projeto estão com dependências mandatórias
definas entre elas. Isso significa que uma atividade somente pode ser
realizada se outra tiver sido realizada antes. Exemplo: O Documento de
Organização de Requisitos somente pode ser realizado se o Documento
de Requisitos tiver sido elaborado antes. As dependências são observadas
nas “setas” que ligam uma atividade a outra. Observe Figura 10:
Figura 10 – Setas Especificando Dependência entre Atividades
3.3.2.1. Para criar uma dependência entre atividades, basta clicar na barra
de uma atividade 1 e depois arrastar até a barra de uma atividade 2. Desta
forma você fará com que a atividade 2 somente seja realizada depois que
a atividade 1 tiver sido feita.
3.3.3 Ler todas as notas existentes que explicam algumas das atividades.
Basta dar um duplo clique em cada uma delas. As notas estão localizadas
à esquerda das atividades, conforme Figura 11:
Figura 11 – Localização das Notas Explicativas das Atividades
3.4 . Preencher o Template do Cronograma do Projeto considerando as

atividades detalhadas na Subseção 2.1.2 Plano de Iteração – Versão 03
3.4.1. Substituir <Sigla do Projeto> da primeira atividade do Cronograma

do Projeto pela sigla escolhida para o projeto;
3.4.2. Inserir cada uma das atividades no Cronograma do Projeto;

56
3.4.2.1. Importante: É muito importante notar que a maioria das

atividades já está identificada no Template do Cronograma de Projeto.
Todavia, você terá de inseri-las no Cronograma as atividades referentes
aos requisitos identificados no Documento de Requisitos. Para tal, basta
considerar a Subseção 2.1.2 Plano de Iteração – Versão 03 do Plano de
Projeto lida em passos anteriores. Comece então pela Iteração 1, e insira
as atividades, conforme Figura 11; posteriormente faça o mesmo para as
demais iterações, não se esquecendo de especificar as dependências entre
atividades, quando houver;
Figura 12 – Inserção de Atividades no Cronograma do Projeto a partir do Plano de

Iteração do Plano de Projeto
3.4.2.2 Importante: Quando você for inserir atividades para outras

iterações, por exemplo, a iteração 2, não pode se esquecer de identificar
a dependência existente entre as fases da iteração 1 e iteração 2. Para
entender melhor quais são estas dependências, observe a Figura 13;
57
Figura 13 – Dependência entre Fases de cada Iteração
Observamos, por intermédio da Figura 13, que a Fase de Concepção é

predecessora a Fase de Elaboração i – Análise, ou seja, para que a Fase
de Elaboração i – Análise seja realizada, deve-se terminar antes a Fase de
Concepção. Isso acontece para as outras fases, nas iterações. Note que:
Fase Elaboração ii – Projeto da Iteração 1 é predecessora da Fase

Construção da Iteração 1
Fase Construção – Projeto da Iteração 1 é predecessora da Fase

Elaboração ii - Projeto da Iteração 2
Fase Elaboração ii – Projeto da Iteração 2 é predecessora da Fase



Fase Construção – Projeto da Iteração 4 é predecessora da Fase Transição
3.4.2.3. Importante: Nem todas as iterações possuem a Fase Elaboração

ii – Projeto. No exemplo anterior da Figura 13, apenas as Iterações 1
e 2 possuíam esta fase. Isso significa dizer que apenas nas Iterações 1
e 2 existem as atividades relacionadas à Elaboração de Diagrama de
Sequência. Observe a Figura 14:
58
Figura 14 – Fase de Elaboração ii – Projeto nas Iterações 1 e 2
Assim acontece, pois as atividades de Elaboração de Diagrama de

Seqüência somente são realizadas para casos de uso. Ou seja, elaboramos
um Diagrama de Sequência para cada Caso de Uso identificado.
Diagramas de Sequência são desenhos em UML (Linguagem de

Modelagem Unificada) representando a sequência de passos num
programa de computador. O diagrama de sequência representa essa
informação de uma forma simples e lógica. Este diagrama é construído
a partir dos Casos de Usos.
As Iterações 3 e 4 tratam, respectivamente, de requisitos de

manutenção de cadastros e relatórios. Nestas Iterações não existem
mais Casos de Uso para serem abordados, pois todos foram abordados
nas Iterações anteriores.
3.4.2.4. Importante: Para inserir dependência entre as atividades

quando necessário, devemos proceder da seguinte forma: ir ao
gráfico que exibe as atividades no Cronograma do Projeto, clicar na
Atividade Predecessora e arrastar o mouse até Atividade que depende
da Atividade Predecessora.
3.5. Importante: Neste momento serão identificadas todas as atividades a

serem realizadas durante o desenvolvimento do sistema proposto. Ainda
não serão identificas o tempo de duração de cada uma delas (isso será
realizado em outra atividade do PGPS-IFES), apenas a lista das atividades.
59
4 Armazenar o Cronograma do Projeto;
4.1 Salvar com o nome <Sigla do Projeto>-CronogramaDoProjeto_01
4 - Planejar Recursos Humanos

Finalidade
Identificar, documentar e designar as funções, responsabilidades
e relacionamentos de reporte dentro do projeto.
Cronograma – Versão 01 Cronograma – Versão 02

Passos Resumidos:
1. Preencher a Subseção 6.1 Organograma e Subseção 6.2 Detalhamento

do Suporte do Plano de Projeto – Versão 03;
2. Preencher a Versão 01 do Cronograma do Projeto com os recursos
humanos que farão parte da equipe de desenvolvimento do projeto,

bem como com os treinamentos identificados como necessários para o
desenvolvimento do projeto;
Passos Detalhados:
1. Preencher a Versão 03 do Plano de Projeto – Seção 6 Gerenciamento

dos Recursos – Subseção 6.1 Organograma; Preencher a Tabela 6.1 com
o nome de todos os recursos humanos que irão compor a equipe de
desenvolvimento do projeto. No caso específico desta disciplina, devem
ser descritos os nomes de todos os alunos que compõem o grupo. Um
dos alunos deve ser identificado como Gerente de Projeto, outro como
Analista de Sistemas, e os demais como Programadores (no total de
três para os grupos com 5 alunos, ou menos para grupos menores).
O Responsável pela Qualidade e o Diretor da Empresa devem ter os
nomes José da Qualidade e José da Diretoria, respectivamente.
1.1.1. Importante: Podem existir diversos outros Papéis dentro de uma

equipe de desenvolvimento de software. Isso irá depender do tamanho
do projeto e da empresa no qual este projeto está sendo desenvolvido.
1.2. Preencher a Subseção 6.1.1 Reuniões da Equipe Técnica: Para este

preenchimento, você deve substituir o trecho <semanal, quinzenal, mensal...
> pela periodicidade correta em que serão realizadas estas reuniões;
60
1.2.1. Importante: No caso específico da disciplina, esta periodicidade

deve ser semanal;
1.3. Preencher a Subseção 6.1.2 Reuniões de Qualidade: Para este

preenchimento você deve substituir o trecho <semanal, quinzenal, mensal...
> pela periodicidade correta em que serão realizadas estas reuniões;

deve ser quinzenal;
1.4. Preencher a Subseção 6.1.3 Reuniões de Apresentação de Status

do Projeto: Para este preenchimento você deve substituir o trecho
<semanal, quinzenal, mensal... > pela periodicidade correta em que
serão realizadas estas reuniões;

deve ser mensal;
2. Preencher a Versão 03 do Plano de Projeto – Seção 3 Gerência dos

Recursos – Subseção 6.2 Detalhamento do Suporte;
2.1. Preencher na Tabela 6.2 todos os treinamentos necessários para o

desenvolvimento do sistema;
2.1.1. Importante: No caso específico da disciplina de Gerência de

Projetos, vocês devem identificar pelo menos um treinamento como
atividade a ser realizada durante o desenvolvimento do sistema;
4. Preencher a Versão 01 do Cronograma do Projeto considerando os

treinamentos detalhados na Subseção 6.2 Detalhamento do Suporte –
Versão 04 do Plano de Projeto;
4.1. Ler Subseção 6.1 Organograma – Versão 04 do Plano de Projeto;
4.2. Abrir a Versão 01 do Cronograma do Projeto;
4.3. Clicar no ícone , conforme mostra a Figura 15.

61
Figura 15 – Ícone para Inserir Recursos no Projeto
4.4. Preencher os nomes de cada um dos recursos humanos identificados

na Subseção 6.1 Organograma – Versão 04 do Plano de Projeto;
Figura 16– Tela de Preenchimento de Recursos do OpenProj
4.5. Ler Subseção 6.2 Detalhamento do Suporte – Versão 04 do Plano

de Projeto;
4.6. Clicar abaixo da atividade denominada “Treinamentos” e preencher

como sub-atividades de “Treinamentos” todos os treinamentos a serem
realizados, conforme mostra a Figura 17:
4.7. Importante: Neste momento, não precisa ser definida a data do

Treinamento;
5. Armazenar o Cronograma do Projeto;
5.1. Salvar com o nome <Sigla do Projeto>-CronogramaDoProjeto_02

62
Figura 17 – Tela de Preenchimento dos Treinamentos
5 - Planejar Infraestrutura
Finalidade
Determinar quais recursos (equipamentos, materiais) e que quantidade
de cada de cada um deve ser usada para executar as atividades do
projeto.
Passos Resumidos:
1. Preencher a Subseção 4.1 Planejamento de Infraestrutura – Versão 04

2. Preencher a Versão 02 do Cronograma do Projeto com os recursos

referentes à infraestrutura que serão utilizados no desenvolvimento do
projeto;
Passos Detalhados:

do Custo – Subseção 4.1 Planejamento de Infraestrutura;
1.1. Ler Subseção 4.1 Planejamento de Infraestrutura – Versão 04 do

Plano de Projeto;
1.2. Preencher a Subseção 4.1 Planejamento de Infraestrutura – Versão 04

do Plano de Projeto: Esta Subseção é apenas informativa, na finalidade de
documentar que a definição dos recursos referentes a infraestrutura deverá
ser realizada no Cronograma do Projeto. Basta então que você substitua o
trecho “<Sigla do Projeto>” pela sigla escolhida para o seu projeto.

63
3. Preencher a Versão 02 do Cronograma do Projeto considerando os

treinamentos detalhados na Subseção 6.2 Detalhamento do Suporte –
3.2. Clicar no ícone e preencher os novos recursos materiais,

conforme mostra a Figura 18:
Figura 18 – Tela de Preenchimento dos Treinamentos
3.3. Importante: Neste projeto-exemplo foram identificados 5

equipamentos (um para cada recurso humano do projeto do tipo
programador, analista de sistema e gerente de projeto – foram
desconsideradas equipamentos para o responsável pela qualidade e
o diretor da empresa). Todavia, nenhuma licença de Ferramentas foi
necessária, pois todos os Softwares utilizados para o desenvolvimento
deste sistema são Softwares Livres. Você deverá fazer o mesmo no seu
Cronograma do Projeto: identifique um equipamento para cada um dos
recursos humanos identificados para formação de sua equipe de projeto;
4.1. Salvar com o nome <Sigla do Projeto>-CronogramaDo

Projeto_03
64
6 - Estimar Duração de Atividades

Finalidade
Estimar a quantidade de períodos de trabalho que serão necessários
para a implementação de cada atividade.
Cronograma – Versão 03 Plano de Projeto – Versão 06
Plano de Projeto – Versão 05 Tabela de Estimativa de Atividades
– Versão 01
Template da Tabela de Estimativa
de Atividades
Ferramentas: OpenProj; Word (Microsoft) ou Writer (OpenOffice);
Excel (Microsoft) ou Calc (OpenOffice)
Passos Resumidos:
1. Preencher a Subseção 3.2 Estimativa de Duração de Atividades –

2. Preencher todas as abas da planilha eletrônica referentes ao Template

da Tabela de Estimativa de Atividades, com os valores estimados em
horas necessárias para a elaboração de cada uma das atividades;
Passos Detalhados:

do Tempo – Subseção 3.2 Estimativa de Duração das Atividades;
1.1. Ler Subseção 3.2 Estimativa de Duração das Atividades – Versão 05

1.2. Preencher a Subseção 3.2 Estimativa de Duração das Atividades –

Versão 05 do Plano de Projeto: Esta Subseção é apenas informativa, na
finalidade de documentar que a estimativa da duração das atividades
do projeto deverá ser realizada na Tabela de Estimativa de Atividades.
escolhida para o seu projeto.
3. Preencher o Template da Tabela de Estimativa de Atividades

considerando todas as atividades identificadas no Cronograma do
Projeto – Versão 03;
65
3.2. Abrir o Template da Tabela de Estimativa de Atividades;
3.3. Preencher as estimativas seguindo as instruções das abas: Visão

Geral, Requisitos, Documentos, Treinamentos e Reuniões;
3.4. Importante: Leia atentamente as instruções localizadas na parte

inferior de cada aba. Estas instruções deixam claro que os preenchimentos
realizados nesta atividade são meramente didáticos. O objetivo principal
aqui é evidenciar a necessidade de se estimar a duração das atividades.
Todavia, estas estimativas, em uma situação prática de mercado, são
realizadas com base em experiências adquiridas em projetos anteriores,
ou, ainda, com auxílio de abordagens do tipo: Estimativas por Pontos de
Função e Estimativas por Pontos de Caso de Uso;
4. Armazenar a Tabela de Estimativa de Atividades;
4.1. Salvar com o nome <Sigla do Projeto>-TabelaDeEstimativaDe

Atividades_01
7 - Desenvolver Cronograma
Finalidade
Analisar a sequência e as durações das atividades, e os requisitos de
recursos para criar o cronograma do projeto.
Tabela de Estimativa de Atividades
– Versão 01
Ferramentas: OpenProj e Word (Microsoft) ou Writer (OpenOffice)
Passos Resumidos:
1. Preencher a Subseção 3.3 Desenvolvimento do Cronograma – Versão

06 do Plano de Projeto;
2. Preencher a Versão 03 do Cronograma do Projeto com as datas de

início e fim de cada atividade identificada, considerando as estimativas
de atividades realizadas em atividade anterior (Tabela de Estimativa de
Atividades – Versão 01), bem como identificando, para cada atividade,
o recurso humano responsável pela sua realização, e, por último, as
dependências arbitradas (definidas pela equipe de gerência do projeto)
entre as atividades;
66
Passos Detalhados:

do Tempo – Subseção 3.3 Desenvolvimento do Cronograma;
1.1. Ler Subseção 3.3 Desenvolvimento do Cronograma – Versão 06 do

Plano de Projeto;
1.2. Preencher a Subseção 3.3 Desenvolvimento do Cronograma –

Versão 06 do Plano de Projeto: Esta Subseção é apenas informativa, na
finalidade de documentar que a definição de data de início e fim das
atividades do projeto deverá ser realizada no Cronograma do Projeto.
escolhida para o seu projeto.
3. Preencher a Versão 03 do Cronograma do Projeto considerando

as estimativas das atividades detalhadas na Tabela de Estimativa de
Atividades – Versão 01;
3.1. Abrir a Versão 01 da Tabela de Estimativa de Atividades;
3.2. Configurar propriedades do projeto da Ferramenta OpenProj:
3.2.1. Clicar em Projeto >> Informações do Projeto, conforme Figura 19:
3.2.2.Preencher alguns campos da aba Geral: Nome (com o nome

do seu projeto), Gerente (com o nome do gerente do seu projeto),
Data Início (esta data deve ser a data de início do seu projeto; nesta
disciplina, iremos utilizar a data de início como 01/01/2013).
Observe a Figura 20 (Nesta figura temos a data como sendo 01/01/2009,

isso porque o arquivo exemplo da ferramenta openproj contendo o
cronograma do sistema de controle da videolocadora foi elaborado
anteriormente):
67
Figura 19 – Configurando informações do projeto
Figura 20 – Tela de Preenchimento de Informações do Projeto
3.2.3. Importante: O campo ‘Calendário Base’ pode ser alterado. Existem

outras opções, diferentes de Padrão, como: 24 horas e Noturno. No caso
do nosso projeto, manteremos o calendário denominado Padrão. O
Calendário Padrão considera 8 horas de trabalho por dia (De 8:00 às
12:00 – De 13:00 às 17:00), conforme mostra Figura 21;
3.3. Criar Calendários Específicos para cada Papel da Equipe

(Programador, Analista de Sistema, Gerente de Projeto, Responsável
pela Qualidade e Diretor da Empresa): Os calendários de cada Papel da
Equipe levarão em consideração os dias de Reuniões em que cada um
dos Papéis tem participação, conforme mostra a Tabela 4;
68
Figura 21 - Tela de Configurações de Duração do Período

de Trabalho Padrão
Tabela 4 – Reuniões x Participantes

Tipo de reunião Participantes
Reunião de Equipe de Analista de Sistema e Gerente de
Desenvolvimento Projeto
Gerente de Projeto e Responsável pela
Reunião de Qualidade
Qualidade
Reunião de Apresentação do Status do Gerente de Projeto, Responsável pela
Projeto Qualidade e Diretor da Empresa
3.3.1. Criar um calendário para cada papel da equipe do projeto;
3.3.1.1. Clicar no ícone (parte superior da Ferramenta);
3.3.1.2. Clicar no botão ‘Novo’, conforme Figura 22:
Figura 22 – Criando Novo Calendário

69
3.3.1.3. Nomear o Novo Calendário, conforme o exemplo da Figura 23

(para o Papel Programador):
Figura 23 - Definindo o Nome do Novo Calendário
3.3.1.4. Clicar no ‘S’ de sexta-feira (uma vez que foi defina a sexta-feira
como o dia da semana designado para reuniões), e definir o Horário
de Trabalho, conforme a Figura 24 (neste caso, o Horário de 15:00
horas às 17:00 horas ficou disponível para a realização das Reuniões
de Equipe Técnica):
Figura 24 – Definindo o Nome do Novo Calendário
3.3.1.5. Importante: Deve ser criado um calendário para cada papel

(Programador, Analista de Sistema, Gerente de Projeto, Responsável
pela Qualidade e Diretor da Empresa), conforme Figura 25:
70
Figura 25 – Criação de Calendários
3.3.1.5.1. Programador e Analista de Sistema (De 15:00 às 17:00 horas de

Sexta-Feira disponível para Reuniões de Equipe Técnica);
3.3.1.5.2. Gerente de Projeto (De 13:00 às 17:00 horas de Sexta-Feira
disponível para Reuniões de Equipe Técnica, Reuniões de Qualidade e
Reuniões de Apresentação de Status do Projeto);
3.3.1.5.3. Responsável pela Qualidade (De 13:00 às 15:00 horas de

Sexta-Feira disponível para Reuniões de Qualidade e Reuniões de
Apresentação de Status do Projeto);
3.3.1.5.4. Diretor da Empresa (De 13:00 às 15:00 horas de Sexta-Feira

disponível para Reuniões de Apresentação de Status do Projeto);
3.4. Atribuir Calendários aos Recursos Humanos;
3.4.1. Clicar no ícone ;
3.4.2. Escolher um dos Recursos Humanos (por exemplo, Jorge da Silva)

e clicar duas vezes no nome do recurso;
3.4.3. Escolher a aba ‘Geral’ e especificar o Calendário deste Recurso no

Campo ‘Calendário Base’ (neste caso, foi escolhido o Calendário
71
Programador, pois Jorge da Silva tem o Papel de Programador), conforme

mostra a Figura 26:
Figura 26 – Designando Calendário Base para Recurso Humano
3.4.3.1. Importante: A designação de Calendário Base deve ser realizada

para todos os Recursos Humanos, de acordo com o Papel de cada um na
equipe do projeto;
3.5. Preencher duração das atividades;
3.5.1. Clicar duas vezes em cada uma das atividades do Cronograma do

Projeto;
3.5.2. Escolher a aba ‘Geral;
3.5.3. Digitar o tempo estimado da duração da atividade, conforme

Figura 27:
Figura 27 – Tela de Informações da Tarefa – Aba Geral

72
3.5.4. Importante: Por padrão, a duração da atividade está em dias.

Basta que você digite ‘x horas?’, conforme Figura 27.
Desta forma, a Ferramenta OpenProj calcula automaticamente a

equivalência em dias. Exemplo: 2 horas = 0,25 dias.
3.6. Alocar recurso(s) para cada atividade;
3.6.1. Clicar duas vezes em cada uma das atividades do Cronograma do

Projeto;
3.6.2. Escolher a aba ‘Recursos’, conforme Figura 28:
Figura 28 – Tela de Informações da Tarefa – Aba Recursos
3.6.3. Clicar no ícone para alocar recurso(s) para a atividade,

conforme Figura 29;
Figura 29 – Tela de Alocação de Recursos
3.6.4. Clicar duas vezes no nome do(s) Recurso(s) escolhido(s) para

realizar a tarefa;
3.6.4.1. Importante: Para saber qual recurso alocar em cada atividade,

você deverá considerar os Papéis identificados em cada uma das
atividades no Processo de Desenvolvimento de Software PDS-IFES
e no Processo de Gerência de Projeto de Software PGPS-IFES. A
alocação de recursos para as atividades deve estar de acordo com os
73
papéis responsáveis por cada atividade. Observe a Figura 30 para

entender onde está identificado o papel do responsável pela atividade
‘Levantar Requisitos’ do PDS-IFES, que tem a finalidade de elaborar
o Documento de Requisitos, e a Figura 31 para saber como ficaria
a alocação de recursos para a mesma atividade: (Neste exemplo foi
escolhido o Recurso Bruna de Souza, pois este foi o Recurso identificado
como Analista de Sistemas na Subseção 6.1 Organograma do Plano de
Projeto). No caso de atividades onde o responsável pela realização é o
Programador, você deverá escolher um dentre os programadores para a
realização da atividade. Procure dividir bem as tarefas para não deixar
um programador com muito mais atividade que outro.
Figura 30 – Papel da atividade de Levantar Requisitos
DR PAPÉIS
A Levantar
A: Análise de Sistemas
Requisitos
P: Programador
DP GP: Gerente de Projeto
xDR
Figura 31 – Recurso Alocado em Consideração ao Papel de

Analista de Sistema
4. Importante: Durante este preenchimento, podemos observar

alguns aspectos importantes (Os valores de duração abaixo
são apenas ilustrativos, na finalidade de exemplificar alguns
pontos importantes). Observe a Figura 32:
Figura 32 – Detalhamento de Atividades

74
4.1. No campo Nome, vamos nos concentrar em três atividades:

Documento de Requisitos, Documento de Organização de Requisitos
e Plano de Projeto.
4.2. No campo Duração, observamos que todas essas três atividades
têm duração estimada em 0,25 dias, o que é o mesmo que 2 horas. A

Ferramenta OpenProj realizou a transformação de horas para dias,
automaticamente.
4.3. Início e Término: Dia e hora de Início da Atividade e Dia e hora de

Término da Atividade, respectivamente:
4.3.1. Documento de Requisitos: Início 01/01/09 08:00 – Esta é a hora

inicial de trabalho em um dia, segundo o calendário escolhido em
passos anteriores; Término 01/01/09 10:00 – Aqui não existe dúvidas.
Como a atividade começa às 8 horas e tem 2 horas de duração, então o
horário de término desta atividade deve ser 10 horas;
4.3.2. Documento de Organização de Requisitos: Início 01/01/09

10:00 – Para entendermos porque esta atividade começa as 10 horas,
devemos lembrar que esta atividade depende da realização da atividade
3 (Documento de Requisitos). Isso significa que ela só pode começar
depois que a atividade 3 terminar, e a hora estimada para o término
da atividade 3 é 10 horas; Término 01/01/09 13:00 – Nesta caso, seria
óbvio pensar que o término deveria ser 12:00 horas, pois as jornadas de
trabalho na Ferramenta OpenProj estão como 8:00 a 12:00 e 13:00 a 17:00.
Todavia, no caso de uma atividade terminar às 12 horas, a Ferramenta
OpenProj mostra o Término como 13:00. É muito importante notar
que a duração da atividade continua sendo de 2 horas ou 0,25 dias. Isso
porque de 12:00 horas às 13:00 horas é considerado horário de almoço,
ou seja, não contabilizado;
4.3.3. Plano de Projeto: Início 01/01/09 13:00 – Para entendermos porque

esta atividade começa as 13 horas, devemos lembrar que esta atividade
depende da realização da atividade 4 (Documento de Organização
de Requisitos). Isso significa que ela só pode começar depois que a
atividade 4 terminar, e a hora estimada para o término da atividade 4
é 13 horas; Término 01/01/09 15:00 – Aqui não existe dúvidas. Como a
atividade começa às 13 horas e tem 2 horas de duração, então o horário
de término desta atividade deve ser 15 horas;
4.4. Predecessoras: Este campo indica quais as atividades que devem ser
realizadas antes que a atividade em questão seja realizada. Exemplo:
A atividade 4 (Documento de Organização de Requisitos) tem a
75
atividade 3 (Documento de Requisitos) como predecessora. Isso

significa que a atividade 4 somente pode ser realizada depois do
término da atividade 3;
4.5. Nome do Recurso: Este campo armazena o nome do recurso

responsável pela realização da atividade. É interessante observar aqui
que as atividades 3 e 4 estão alocadas para o recurso Bruna de Souza,
isto porque, de acordo com o processo de desenvolvimento de software
– PSD-IFES, são atividades de responsabilidade do Analista de Sistema.
E no Sistema de Controle de Videolocadora, o Analista de Sistema é
Bruna de Souza. Já a atividade 5 está alocada para o Gerente de Projeto,
Rafael Vargas;
5. Identificar as dependências arbitrárias entre as atividades, ou seja,

as dependências definidas pela equipe de gerência de projeto. Para
entendermos melhor como estas dependências serão identificadas,
observe a Figura 33.
Figura 33 – Identificando Dependências Arbitrárias
5.1. Importante: Observando a Figura 33 podemos verificar que

o recurso Thiago Mesquita está alocado para as atividades 39 e 42,
ambas as atividades com 8 horas, ou um dia, de duração. Isso significa
que para um recurso como este, com 8 horas de trabalho por dia,
seriam necessárias 8 horas de trabalho extra para a elaboração das
duas atividades. Todavia, por um critério arbitrário (lembre-se das
dependências arbitrárias) foi definido pelo gerente de projeto que não
seriam utilizadas de horas extras, e que, para solucionar este problema,
a solução seria identificar a atividade 39 como predecessora da atividade
42, conforme mostra Figura 34:
Figura 34 – Identificando Dependências Arbitrárias

76
6. Observar as porcentagens de alocações dos recursos para com as

atividades. Isso, pois os recursos não devem estar sobrecarregados
ou seja, como estamos considerando o calendário padrão de trabalho,

cada recurso não deve estar alocado a mais de 8 horas de trabalho diárias
– isso significa que, em nenhuma atividade, o recurso humano pode
ter porcentagem de alocação superior a 100% (isso deve ser evitado ao
máximo);
6.1. Para verificar a porcentagem de alocações dos recursos nas

atividades, você deve clicar em uma atividade qualquer, e depois clicar
no ícone . Clicando neste ícone, após termos clicado em uma
atividade, como por exemplo, Documento de Requisitos, será exibido
um gráfico como o da Figura 35 (Os valores de duração abaixo são
apenas ilustrativos, na finalidade de exemplificar alguns pontos
importantes):
Figura 35 – Gráfico de Porcentagem de Alocação de Recurso por

Atividade
6.2. A explicação para o gráfico da Figura 35 é que o recurso humano

Bruna de Souza (mostrado à esquerda, e evidenciado por uma ‘bolinha’
verde) designado para a atividade de Documento de Requisitos está
alocado em 75% de seu tempo diário disponível, que é 8 horas por dia.
Isso é observado quando nos concentramos na coluna ‘Q’ do gráfico, a
qual representa o dia da semana quinta-feira (mesmo dia de realização
da atividade). Nesta coluna, observamos que uma parte está colorida
de verde e outra de azul. O azul significa a porcentagem de alocação do
recurso apenas considerando a atividade selecionada, ou seja, apenas a
atividade Documento de Requisitos que tem duração igual a 2 horas,
ou 25% (75% do total - 50% da parte verde) do total de horas diárias (8
horas) disponíveis do recurso Bruna de Souza. Já a parte verde considera
a alocação do recurso humano nas demais atividades do projeto, ou
seja, Bruna
77
de Souza está alocada na quinta-feira em mais 50% do seu tempo diário

disponível em outras atividades do projeto.
7. Alocar recursos materiais a atividade ‘Equipamentos’;
7.1. Clicar na atividade denominada ‘Equipamentos’, escolher

a aba ‘Recursos’ e alocar todos os equipamentos identificados
anteriormente como necessários ao projeto, conforme a Figura 36:
Figura 36 – Alocação de Recursos Materiais para Atividade Equipamentos
7.2. Importante: Esta atividade deve ter duração igual a zero dias. O
início da atividade pode permanecer como sendo o primeiro dia útil do
projeto;
8. Estimar a data de início e término das reuniões, bem como a

alocação de recursos humanos para tais;
8.1. Ler Seções 6.1.1, 6.1.2 e 6.1.3 na finalidade de verificar a

periodicidade definida para ocorrência de reuniões da equipe técnica,
de apresentação do status do projeto e de qualidade, respectivamente;
8.2. Calcular a quantidade necessária de cada tipo de reuniões

levando em consideração a duração estimada do projeto. Para isto,
observe em seu projeto o Término estimado, conforme Figura 37;
Figura 37 – Término Previsto do Projeto

78
8.2.1. Importante: Considerando que neste caso a duração do

projeto é de aproximadamente um mês e nove dias, teremos então,
aproximadamente, cinco reuniões de equipe técnica (pois são reuniões
semanais – identificadas no cronograma para as sextas-feiras), duas
reuniões de qualidade (pois são reuniões quinzenais – poderiam ser
em quaisquer dias, no caso do sistema de controle da videolocadora foi
escolhida também a sexta-feira) e apenas uma reunião de apresentação
do status do projeto (pois são reuniões mensais - poderia ser em
quaisquer dias, no caso do sistema de controle da videolocadora foi
escolhida novamente a sexta-feira);
8.3. Criar nova atividade para cada ocorrência de reunião de acordo

com a Figura 38:
Figura 38 – Criação das Atividades de Reuniões
8.4. Configurar as atividades de reuniões: As reuniões de equipe

técnica devem ocorrer as sextas-feiras, de 15:00 às 17:00, isso porque o
Calendário Base dos recursos envolvidos nesta reunião foi configurado
nesta finalidade. As demais reuniões foram configuradas para
acontecerem as sextas-feiras, de 13:00 às 15:00, lembrando sempre de
considerar a periodicidade de cada tipo de reunião.
8.4.1. Clicar duas vezes na reunião, por exemplo, Reunião 01, e escolher
a aba ‘Geral’ para especificar a duração (2 horas?) e as datas de início e
término (incluindo hora, início – 15:00 e término – 17:00), conforme
mostra Figura 39.
8.4.2. Escolher aba ‘Avançado’ e marcar opção Ignorar Recurso

do Calendário (pois estas reuniões estão marcadas fora do horário
normal do Calendário dos Recursos), conforme Figura 40.
79
8.4.3. Alocar recursos para as atividades de reuniões: Clicar na Aba

‘Recursos’ e alocar os recursos humanos participantes da reunião,
considerando as seguintes informações:
Figura 39 – Preenchendo Duração, Início e Término da Atividade de

Reunião
Figura 40 – Aba Avançado - Marcando Opção Ignorar Recurso do

Calendário
8.4.3.1. Reunião da Equipe Técnica: Equipe de Desenvolvimento –

Programadores e Analista de Sistemas (Jorge da Silva, João Victor, Thiago
Mesquita, Bruna de Souza) e o Gerente de Projeto (Rafael Vargas);
8.4.3.2. Reunião de Apresentação de Status do Projeto: Gerente de

Projeto (Rafael Vargas), o Responsável pela Qualidade (José da
Qualidade) e o Diretor da Empresa (José da Diretoria);
8.4.3.3. Reunião da Qualidade: Gerente de Projeto (Rafael Vargas) e

Responsável pela Qualidade (José da Qualidade);
80
9. Estimar a data de início e término da atividade de

acompanhamento diário;
9.1. Esta atividade deve iniciar um dia depois do término da

atividade ‘Plano de Projeto’. Isso porque a finalidade
principal desta atividade é a de acompanhar o andamento do projeto

garantindo que este esteja dentro do previsto no plano de projeto e
cronograma do projeto. No caso do cronograma exemplo, referente
ao sistema da videolocadora, a data de término da atividade Plano
de Projeto foi estimada para 07/01/2009. Logo, a data de início
da atividade de acompanhamento, neste caso, deve ser igual a
08/01/2009.
9.2. A data de término da atividade deve ser a mesma data de término

do projeto, conforme Figura 37, mostrada anteriormente, na qual a Data
de Término do projeto é 10/02/2009.
10. Estimar a data de início e término dos treinamentos, bem como

a alocação de recursos humanos para tais;
10.1. Especificar data de início e término das atividades de treinamentos:

No caso do sistema da videolocadora foi identificado apenas um
treinamento a ser realizado. Normalmente, os treinamentos relacionados
a Linguagens de Programação, como foi neste caso, são realizados no
início do projeto, quando o mesmo ainda está em sua fase de análise.
Neste momento, os recursos humanos com o papel de programadores
estão com um tempo mais livre. Isso porque, no início do projeto, as
pessoas que têm um maior número de atividades são o analista de sistema
e o gerente de projetos;
10.2. Importante: A duração dos treinamentos foi estimada para

quatro horas, de acordo com a Tabela de Estimativa de Atividades;
10.3. Alocar recursos para a atividade de treinamento: Neste caso,

você deve seguir o que foi especificado na Seção 6.2 do Plano de Projeto
sobre o Detalhamento do Suporte. Para o caso do sistema de controle
de videolocadora, foram escolhidos os seguintes recursos: Jorge da
Silva, João Victor, Thiago Mesquita (programadores) e Bruna de Souza
(responsável pelo treinamento);

Projeto_04
81
8 - Estimar Custos
Finalidade
Desenvolver uma estimativa dos custos dos recursos necessários à
implementação das atividades do projeto.
Ferramentas: OpenProj ; Word (Microsoft) ou Writer (OpenOffice)
Passos Resumidos:
1. Preencher a Subseção 4.2 Estimativa de Custo – Versão 07 do

Plano de Projeto;
2. Preencher a Versão 04 do Cronograma do Projeto com os valores

para as taxas padrões de cada um dos recursos do tipo trabalho, e os
custos/uso para os recursos do tipo material;
Passos Detalhados:

Gerenciamento do Custo – Subseção 4.2 Estimativa de Custo;
1.1. Ler Subseção 4.2 Estimativa de Custo – Versão 07 do Plano de

Projeto;
1.2. Preencher a Subseção 4.2 Estimativa de Custo – Versão 07 do

Plano de Projeto: Esta Subseção é apenas informativa, na finalidade de
documentar que a estimativa de custo das atividades do projeto deverá
ser realizada no Cronograma do Projeto. Basta, então, que você substitua
o trecho “<Sigla do Projeto>” pela sigla escolhida para o seu projeto.
3. Preencher a Versão 04 do Cronograma do Projeto considerando

as taxas padrões e custos/uso dos recursos identificados anteriormente;
3.2. Clicar no ícone ;
3.3. Clicar duas vezes em cada um dos recursos do tipo ‘Trabalho’,

82
Figura 41 – Recursos do Tipo Trabalho
3.4. Escolher a aba ‘Custos;
3.5. Especificar a ‘Taxa Padrão’ (valor em reais correspondente à

hora de trabalho do recurso), conforme a Figura 42:
Figura 42 – Especificando a Taxa Padrão do Recurso do Tipo Trabalho
3.5.1. Importante: Este valor varia de empresa para empresa. Quando

for preencher em seu projeto, siga as seguintes instruções: Recursos
Programadores >> Taxa Padrão = R$ 50,00; Recurso Analista de
Sistemas >> Taxa Padrão = R$ 70,00; Recurso Gerente de Projeto
>> Taxa Padrão == R$ 100,00; Responsável pela Qualidade >> Taxa
Padrão = R$ 70,00; Recurso Diretor da Empresa >> Taxa Padrão =
R$ 200,00;
3.5.2. Importante: Apesar de algumas vezes (não no nosso caso-

exemplo do sistema da videolocadora, pois tratamos essa questão por
meio dos calendários específicos criados para cada tipo de recurso) o
recurso necessitar trabalhar algumas
83
horas extras (mais do que 8 horas por dia) em algum projeto, a

Ferramenta OpenProj não considera por padrão as horas acima
de 8 horas como tendo custo de taxa de hora extra – para que isso
aconteça são necessárias outras configurações na ferramenta, e por
isso não iremos considerar a taxa de hora extra. Um exemplo para
esta situação: Rafael Vargas está alocado em um dia para trabalhar 10
horas (2 horas a mais do que o padrão). Neste caso, o cálculo do custo
deveria levar em consideração a taxa padrão para 8 horas e a taxa de
hora extra para 2 horas. Todavia, por padrão, a Ferramenta OpenProj
calcularia o custo apenas considerando a taxa padrão.
3.6. Clicar duas vezes em cada um dos recursos do tipo ‘Material,

Figura 43 – Recursos do Tipo Material
3.7. Escolher a aba ‘Custos;
3.8. Especificar a ‘Custo/Uso’ (valor em reais correspondente ao

custo por utilização do material), conforme a Figura 44:
Figura 44 – Especificando a Taxa Padrão do Recurso do Tipo Material
3.8.1.Importante: No caso de recursos materiais, estamos

considerando apenas os equipamentos (computadores)utilizados
84
pelos recursos humanos do projeto. Todavia, poderíamos considerar

muitos outros materiais dentre os recursos materiais utilizados pelo
nosso projeto. A finalidade principal aqui é trazer ao entendimento
sobre a necessidade de identificação de recursos materiais no projeto.
3.8.2. Importante: O valor do custo/uso mostrado na Figura 44,

anteriormente, foi baseado no Cálculo da Depreciação do Equipamento.
Devemos entender depreciação como sendo o custo ou a despesa
decorrentes do desgaste ou da obsolescência dos ativos imobilizados
(máquinas, veículos, móveis, imóveis e instalações) da empresa.
De acordo com o art.25 da IN SRF nº 11/96 equipamentos como
computadores são bens depreciáveis. Existem vários métodos para se
calcular a depreciação de um bem. Neste caso iremos utilizar o método
linear. O método linear consiste na aplicação de taxas constantes durante
o tempo de vida útil estimado para o bem e é o mais frequentemente
utilizado. Exemplo: Um bem tem vida útil de 10 anos, com taxa de
depreciação de 10%.
Taxa de Depreciação = 100% dividida por tempo de vida útil.
100% dividido por 10 anos = 10% a.a.
3.8.3. Importante: Foram fixados em 5 anos, pela IN SRF nº 4, de

1985, o prazo de vida útil para fins de depreciação de computadores e
periféricos (hardware), taxa de 20% (vinte por cento) ao ano;
3.8.4. Fazendo os cálculos para nosso projeto, teremos:
Tabela 5 – Cálculo de Depreciação para cada Equipamento (Computador)

Utilizado no Projeto
Descrição Valor
Valor do Equipamento R$ 2.000,00
Taxa de Depreciação Anual 20%
Taxa de Depreciação Mensal 1,67%
Quantidade de Meses do Projeto 1
Valor Total da Depreciação R$ 33,33
3.9. Salvar linha base;
3.9.1. Importante: Após termos especificado os custos do projeto,

bem como anteriormente as datas estimadas para as atividades, é muito
importante salvarmos a linha base, ou baseline,
em inglês. Linhas-base ou Baseline é um conceito de gerenciamento de

configuração de software que nos ajuda a controlar as mudanças, sem
85
impedir seriamente as mudanças justificáveis. Segundo PRESSMAN, no

contexto de engenharia de software, definimos uma linha básica como
um marco de referência no desenvolvimento de um software. Salvando
nossa linha-base, estamos armazenando nossa estimativa inicial, tanto
de tempo como de custo, para o projeto. Desta forma, quando o Gerente
de Projeto for acompanhando diariamente o cronograma do projeto,
e, porventura, tiver de alterar a data de término de alguma atividade
por conta de um atraso no desenvolvimento, por exemplo, este gerente
poderá comparar o cronograma atual com o cronograma da linha-base
e observar o quão distante está da previsão inicial.
3.9.2. Clicar em Ferramentas >> Salvar Linha de Base..., conforme

Figura 45:
Figura 45 – Salvando Linha Base
Figura 46 – Escolhendo Linha de Base
3.9.3. Importante: Depois de Salvar a Linha de Base, podemos observar

no gráfico das atividades que uma linha cinza apareceu abaixo de cada
atividade, conforme Figura 47.
Isso facilita a observação visual com respeito ao atraso, ou adiantamento,

de alguma atividade. Basta somente, em cada atividade, comparar a
parte cinza com a parte acima desta.
86
Figura 47 – Visualizando no Gráfico a Linha de Base
3.10. Gerar Relatórios (apenas para observação) depois de criar a

Linha de Base, por meio do ícone à sua esquerda. Existem vários
tipos de relatórios disponíveis. Iremos nos concentrar no principal
, conforme Figura 48:
Figura 48 – Relatório de Detalhe do Projeto
3.10.1. Importante: Concentre-se nas informações destacadas em

vermelho.
Dates – Informações sobre as datas do projeto: Start – Data de Início do

Cronograma Atual do Projeto; Finish – Data de Término Cronograma
Atual do Projeto; Baseline Start: Data de Início do Projeto de acordo
com a Baseline; Baseline Finish: Data de Término do Projeto de acordo
com a Baseline;
Duration – Informações sobre o tempo de duração do projeto: Scheduled

– Duração programada do projeto segundo o Cronograma Atual do
Projeto; Baseline - Duração programada do projeto segundo a
Linha
de Base do Projeto; Remaining – Duração restante do projeto segundo

o Cronograma Atual do Projeto; Actual – Tempo em dias gastos no
desenvolvimento do projeto até o presente momento;
87
Work: Estas informações referem-se ao tempo gasto no projeto em horas,

todavia deve ser desconsiderada. Isso, pois a Ferramenta OpenProj está
com um bug (erro) na geração deste relatório. A Ferramenta OpenProj
foi utilizada nesta disciplina em uma finalidade especificamente
didática. Em um ambiente de mercado, a Ferramenta mais utilizada
para gerenciamento de projetos é o MsProject da Microsoft, todavia, por
meio da utilização da Ferramenta OpenProj, conseguimos aprender os
conceitos e nos tornarmos aptos à utilização de quaisquer ferramentas
semelhantes, como o MsProject da Microsoft;
Costs: Informações sobre o custo do projeto: Scheduled – Custo

programado do projeto, segundo o Cronograma Atual do Projeto;
Baseline - Custo programado do projeto, segundo a Linha de Base do
Projeto; Remaining – Custo restante a ser gasto no projeto, segundo
o Cronograma Atual do Projeto; Actual – Custo em reais gastos no
desenvolvimento do projeto até o presente momento;
3.10.2. Importante: Outros relatórios são importantes. Gere outros

relatórios em seu projeto. Observe as informações geradas por cada
uma deles.
3.10.2.1. Relatório de Custos por Recursos . Permite ao Gerente

de Projeto saber quanto custa, em reais, cada recurso do projeto.
3.10.2.2. Relatório de Custos por Atividades . Permite ao Gerente

de Projeto saber quanto custa cada atividade do projeto.

Projeto_05
9 - Planejar Gerência de Riscos

Finalidade
Decidir como abordar e planejar as atividades de gerência de risco
para um projeto. Determina quais riscos podem afetar o projeto e
documenta suas características.
88
Passos Resumidos:
1. Preencher a Subseção 8.1 Análise dos Riscos e Subseção 8.2 Resposta

aos Riscos – Versão 08 do Plano de Projeto;
Passos Detalhados:

de Risco – Subseção 8.1 Análise dos Riscos e Subseção;
1.1. Ler Subseção 8.1 Análise dos Riscos – Versão 08 do Plano de Projeto;
1.2. Preencher a Subseção 8.1 Análise dos Riscos – Versão 08 do Plano de

Projeto: Nesta Subseção, você deverá informar os riscos do seu projeto,
bem como especificar probabilidade, impacto e exposição para cada um
dos riscos identificados.
1.2.1. Preencher a Tabela 8.1, conforme Tabela 6, com: Declaração de

Risco, P (Probabilidade), I (Impacto), E Exposição, Descritivo (Descrição
mais detalhada do risco); Responsável (pela identificação do risco –
normalmente o Gerente de Projeto), Data (de identificação do risco);
Tabela 6 – Tabela de Riscos (continua)
Gerenciamento de Risco
Declaração do Risco: condição e consequência do risco
P (Probabilidade): probabilidade de acontecer o risco (1-baixa, 2-média, 3-alta)
I (Impacto): perda ou prejuízo caso o risco aconteça (1-baixa, 2-média, 3-alta)
E (Exposição): P x I, escala utilizada para classificar os riscos (mais alto = mais
perigoso)
Data: data de identificação do risco
Declaração
# P I E Descritivo Responsável Data
do Risco
O gerente de
projeto gerencia
Recursos
outros projetos
compartilhados
da organização.
serem 07/01
1 2 3 6 Os recursos de Rafael Vargas
requisitados 2009
desenvolvimento
em outras
podem ser
atividades
alocados em
outros projetos
1.2.2. Importante: No caso do seu projeto da disciplina de Gerência

de Projetos, você deverá identificar pelo menos três riscos para o seu
projeto. Pensem em possíveis riscos para a realidade do seu projeto e
equipe. Não copie os riscos exemplos já preenchidos para o Sistema de
Controle da Videolocadora;
89
1.3. Ler Subseção 8.2 Resposta aos Riscos – Versão 08 do Plano de

Projeto;
1.4. Preencher a Subseção 8.2 Resposta aos Riscos – Versão 08 do

Plano de Projeto: Nesta Subseção, você deverá informar as respostas aos
riscos, ou ações corretivas, para cada um dos riscos identificados;
1.4.1. Preencher a Tabela 8.2,conforme Tabela 7:
Tabela 7 – Tabela de Respostas aos Riscos

# Ações Corretivas
Contratar pessoas para suprir as atividades fora do projeto que estariam
1
inviabilizando a participação do recurso no projeto
10 - Planejar Qualidade
Finalidade
Identificar quais padrões de qualidade são relevantes para o projeto e
determinar a forma de satisfazê-los.
Passos Resumidos:
1. Preencher a Subseção 5.1 Planejamento de Qualidade – Versão 09 do

Plano de Projeto;
Passos Detalhados:

da Qualidade – Subseção 5.1 Planejamento de Qualidade;
1.1. Ler Subseção 5.1 Planejamento de Qualidade – Versão 09 do

Plano de Projeto;
1.1.1. Preencher a Subseção 5.1 Planejamento de Qualidade – Versão

09 do Plano de Projeto:
1.1.1.1. Preencher a Subseção ‘Padrões de Nomeação de Arquivos’;

90
1.1.1.2.
Preencher a Subseção ‘Processo de Desenvolvimento de
Software’;
1.1.1.3. Preencher a Subseção ‘Processo de Gerência de Projeto de

Software’;
1.1.2. Importante: Em uma situação real poderiam existir vários

outros padrões adotados em um projeto. No entanto, para a disciplina
de Gerência de Projetos iremos apenas considerar estes padrões
anteriormente citados;
2.1.Salvar com o nome <Sigla do Projeto>-PlanoDeProjeto_10
11 - Planejar Comunicações
Finalidade
Determinar as informações e comunicações necessárias para os
interessados: quem necessita de qual informação, quando necessitarão
dela e como isso será fornecido.
Passos Resumidos:
1. Preencher a Subseção 7.1 Artefatos Gerados, Subseção 7.2 Controles

de Documentos e Dados e Subseção 7.3 Armazenamento, Cópia,
Recuperação e Preservação – Versão 10 do Plano de Projeto;
Passos Detalhados:

das Comunicações – 7.1 Artefatos Gerados;
1.1. Ler 7.1 Artefatos Gerados – Versão 10 do Plano de Projeto;
1.1.1. Preencher a 7.1 Artefatos Gerados – Versão 10 do Plano de Projeto,

conforme Tabela 8:
91
Tabela 8 – Lista de Artefatos do Projeto

Nome do
Descrição do Arquivo
Arquivos
Documentos Documento que apresenta os requisitos do sistema

de Requisitos específicos pelo cliente
Plano de Documento que apresenta diretrizes na finalidade de auxiliar

Projeto no desenvolvimento do projeto
Documento que contém as atividades a serem realizadas

Cronograma durante o desenvolvimento do projeto, bem como, datas
do Projeto estimadas de início e término, e recursos alocados, para cada
uma das atividades
Tabela de
Documento que auxilia na estimativa do tempo de elaboração
Estimativa de
das atividades do projeto
Atividades
1.1.2. Importante: Em uma situação real poderiam existir vários

outros artefatos (documentos) gerados em um projeto. No entanto,
para a disciplina de Gerência de Projetos iremos apenas considerar os
artefatos da Tabela 8;

das Comunicações – 7.2 Controles de Documentos e Dados;
2.1. Ler 7.2 Controles de Documentos e Dados – Versão 10 do Plano

de Projeto;
2.1.1 Preencher a 7.2 Controles de Documentos e Dados – Versão

10 do Plano de Projeto:
2.1.1.1 Substituir a Figura 7.1 do Plano de Projeto por uma figura que
represente a estrutura de pastas do seu projeto na disciplina;
3 Preencher a Versão 10 do Plano de Projeto – Seção 7 Gerenciamento das

Comunicações – 7.3 Armazenamento, Cópia, Recuperação e Preservação;
3.1. Ler 7.1 Artefatos Gerados – Versão 10 do Plano de Projeto;
3.1.1 Preencher a 7.3 Armazenamento, Cópia, Recuperação e Preservação

– Versão 10 do Plano de Projeto: Esta Subseção descreve a forma de
armazenamento dos arquivos do projeto. Considere a Figura 49 para o
preenchimento desta Subseção:
92
Figura 49 – Preenchimento da Subseção 7.3
7.3 Armazenamento, Cópia, Recuperação

e Preservação
Os arquivos relacionados ao projeto serão armazenados em
um projeto da Ferramenta de Gerência de Configuração
Subversion. Para acessar o repositório, deve ser utilizada a
ferramenta TortoiseSVN.
Serão realizados backups diariamente pelo Gerente de

Infraestrutura da Organização.
3.1.2. Importante: Em uma situação real, poderiam existir várias

outras ferramentas de gerência de configuração (ferramentas que fazem
controle de versão de documentos) adotadas em um projeto. No entanto,
para a disciplina de Gerência de Projetos iremos considerar o texto da
Figura 49;
Para simular o trabalho de uma equipe de projeto, as atividades a

seguir devem ser realizadas em grupo. Vocês devem realizar cada
uma das atividades abaixo em grupos formados por 5 alunos cada.
Um aluno deve ser identificado como o Gerente de Projeto, outro
como o Analista de Sistemas, e os demais como Programadores.
Na realidade, todos farão as mesmas atividades; esta divisão tem
apenas a finalidade de mostrar-lhes que, em um desenvolvimento
de software real, existem papéis diferentes para cada envolvido
com o projeto.
Quando estiverem utilizando o PGPS-IFES, vocês perceberão que,
para facilitar sua utilização, todas as atividades já foram realizadas
para um sistema de controle de videolocadora (SCV). Este sistema
foi utilizado como exemplo para esclarecer algumas dúvidas, bem
como mostrar o que deve ser realizado em cada atividade. Todavia,
vocês deverão elaborar as atividades do PGPS-IFES para um outro
sistema, diferente do sistema de controle de videolocadora (SCV).
93
1. Elabore as atividades do Processo de Gerência de Projetos de

Software (PGPS-IFES):
• Atividade 1: Planejar Escopo
• Atividade 2: Detalhar Escopo
• Atividade 3: Definir Atividades
• Atividade 4: Planejar Recursos
• Atividade 5: Planejar Infraestrutura
Envie os arquivos: PP_05: Plano de Projeto - Versão 05 e CP_03:
Cronograma do Projeto – Versão 03
2. Elabore as atividades do Processo de Gerência de Projetos de
• Atividade 6: Estimar Duração de Atividades
• Atividade 7: Desenvolver Cronograma
Envie os arquivos: PP_07: Plano de Projeto - Versão 07; CP_04:
Cronograma do Projeto – Versão 04 e TE_01: Tabela de Estimativas
– Versão 01
3. Elaborar as atividades do Processo de Gerência de Projetos de
• Atividade 8: Estimar Custos
• Atividade 9: Planejar Gerência de Riscos
• Atividade 10: Planejar Qualidade
• Atividade 11: Planejar Comunicações
Envie os arquivos: PP_11: Plano de Projeto - Versão 11 e CP_05:
Cronograma do Projeto – Versão 05
94
[1] DINSMORE, C., CAVALIERI, A. Como se Tornar um Profissional
em Gerenciamento de Projetos: Livro-Base de “Preparação para
Cerfiticação PMP - Project Management Professional”. Rio de Janeiro.
QualityMark, 2003.
[2] PROJECT MANAGEMENT INSTITUTE - PMI. A Guide to the

Project Management Body of Knowledge. Syba: PMI Publishing
Division, 2004.
[3] INSTITUTE OF ELETRICAL AND ELETRONICS AND

ENGINEERS. Std 610.12-1990. Standard Glossary of Software
Engineering Terminology. Piscataway: IEEE, 1990.
[4] PAULK, M. C.; WEBER, C. V.; CURTIS, B.; CHRISSIS, M. B. et

al. The Capability Maturity Model: Guidelines for Improving the
Software Process. Estados Unidos: A. Wesley, 1995.
[5] HELDMAN, Kim. Gerência de Projetos: Guia para o Exame

Oficial do PMI. Rio de Janeiro: Elsevier, 2006.

Gerência de Projetos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerência de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

PROF.

RAFAEL VARGAS MESQUITA DOS SANTOS

S237g Santos, Rafael Vargas Mesquita dos.

1. Projetos – PMBOK. 2. Desenvolvimento de Software – Processo. 3.

Créditos de autoria da editoração

É um prazer tê-lo(a) conosco.

O Ifes – Instituto Federal do Espírito Santo – oferece a você, em parceria

É importante que você conheça toda a equipe envolvida neste curso:

Na EaD – Educação a Distância, você é o grande responsável pelo sucesso

Fique atento às orientações de estudo que se encontram no Manual do Aluno!

A EaD, pela sua característica de amplitude e pelo uso de tecnologias

Desejamos-lhe sucesso e dedicação!

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por você,

Indicação de leituras complementares,

Destaque de algo importante, referente ao

Reflexão / questionamento sobre algo

Espaço reservado para as anotações que você

Meu nome é Rafael Vargas Mesquita, responsável pela disciplina de Gerência

Nesta disciplina, você entenderá alguns conceitos importantes relacionados

Os capítulos 1 e 2 são mais voltados à parte teórica da disciplina. É muito

O objetivo deste material é auxiliá-lo no estudo da disciplina de Gestão

Há, na sala virtual, um processo de gerência de projetos de software que deve

É importante esclarecer que, além deste material, você poderá encontrar

Bons estudos e sucesso!

Prof. Rafael Vargas Mesquita

cap. 2 - padrões de gerência de projeto 19

1.1 O QUE É UM PROJETO

1.1.1 Antecedentes Históricos

“Pois qual de vós, pretendendo construir

Projeto é um instrumento fundamental

Um projeto é um empreendimento único, com início e fim

O projeto pode ser definido por características distintas, tais como:

1.1.3 Projetos versus Operações

Os projetos têm natureza temporária e datas de início e fim definidas,

As operações são contínuas e repetitivas. Elas envolvem um trabalho

Um projeto é bem-sucedido quando atende (ou excede) às espectativas

Stakeholder ou, em Português, parte interessada ou interveniente,

Os principais stakeholders podem ser responsáveis tanto pelo êxito

1.1.5 Características do Projeto

Acabamos de aprender que um projeto possui diversas características:

• os projetos são únicos;

• os projetos são de natureza temporária e têm datas definidas de

• os projetos estarão concluídos quando as metas forem alcançadas

• um projeto bem-sucedido é aquele que atende ou excede as

Vamos pensar na seguinte situação: o gerente de negócios da empresa

Usando os critérios referentes às características do projeto, examinemos

É único? Sim, porque a locadora Visão ainda não possui sistema

Existe uma maneira de saber se o projeto está concluído? Sim, o

disponibilizadas para utilização. Tão logo o software esteja funcionando,

É possível saber se os stakeholders estão satisfeitos? Sim, as expectativas

Enfim, temos um projeto.

SÃO exemplos de projetos:

NÃO SÃO exemplos de projetos:

1.2 O QUE É GERÊNCIA DE PROJETOS?

Você tem certeza de que tem um

Existem muitas situações como esta: uma vez comunicada a tarefa,

O gerenciamendo de projetos abrange uma série de ferramentas e

O gerenciamento de projetos consiste na aplicação de conhecimentos,

O gerenciamento de projetos abrange uma série de atividades, incluindo

O planejamento é uma das atribuições mais importantes, visto que

1.2.1 Habilidades do Gerente de Projeto

Muitas vezes, as organizações denominam especialistas técnicos de

Os gerentes de projeto são profissionais generalistas, cujo repertório