TI - Questões de Gerência de Projetos

Prévia do material em texto

Questões comentadas
Gerência de Projetos
para concursos
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Prefácio
As pessoas têm planejado e gerenciado projetos desde o início dos tempos. Toda vez que uma
civilização criou suas raízes houve projetos a serem gerenciados: prédios a construir, estradas a
pavimentar e leis a serem escritas.
Com o passar do tempo, as pessoas perceberam que as técnicas para controle de custo, desen-
volvimento da programação, procura e compra de recurso e gerenciamento de riscos poderiam
ser aplicadas a uma variedade de projetos, seja erguendo pontes, decidindo como se governar,
preparando-se para concursos públicos ou desenvolvendo um projeto de TI. Essas ideias foram
a base para se estabelecer técnicas de gerenciamento que hoje conhecemos como Gerenciamento
de Projetos ou Gerência de Projetos.
Conforme PMBOK, Gerenciamento de Projetos é a aplicação de conhecimentos, habilidades,
ferramentas e técnicas nas atividades do projeto a fim de atender os requisitos do projeto. O
Gerenciamento de Projeto é utilizado globalmente e sem distinção por corporações, governos e
pequenas organizações. Isso se verifica ainda mais quando contextualizamos no ambiente de TI.
Em função disso, este tema é cobrado com muito afinco nos concursos.
Portanto, o Grupo Handbook de TI preparou para você o volume Gerência de Projetos, que
traz uma séria de questões comentadas sobre as diversas áreas da Gerência de Projetos.
Bons estudos,
Grupo Handbook de TI
Página 1 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Direitos Autorais
Este material é registrado no Escritório de Direitos Autorais (EDA) da Fundação Biblioteca
Nacional. Todos os direitos autorais referentes a esta obra são reservados exclusivamente aos
seus autores.
Os autores deste material não proíbem seu compartilhamento entre amigos e colegas próxi-
mos de estudo. Contudo, a reprodução, parcial ou integral, e a disseminação deste material de
forma indiscriminada através de qualquer meio, inclusive na Internet, extrapolam os limites da
colaboração. Essa prática desincentiva o lançamento de novos produtos e enfraquece a comuni-
dade concurseira Handbook de TI.
A série Handbook de Questões de TI Comentadas para Concursos � Além do Gabarito é uma
produção independente e contamos com você para mantê-la sempre viva.
Grupo Handbook de TI
Página 2 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Canais de Comunicação
O Grupo Handbook de TI disponibiliza diversos canais de comunicação para os concurseiros
de TI.
Loja Handbook de TI
Acesse a nossa loja virtual em http://www.handbookdeti.com.br
Serviço de Atendimento
Comunique-se diretamente conosco através do e-mail faleconosco@handbookdeti.com.br
Twitter do Handbook de TI
Acompanhe de perto promoções e lançamentos de produtos pelo nosso Twitter http://twitter.
com/handbookdeti
Página 3 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
1. Assuntos relacionados: Gerência de Projeto, Gerenciamento de Custos, Índice de De-
sempenho de Custo, Índice de Desempenho de Prazo, PMBOK,
Banca: CESGRANRIO
Instituição: BNDES
Cargo: Analista de Suporte
Ano: 2008
Questão: 39
Em determinado momento, um projeto apresenta as seguintes características:
• custo real (actual cost): R$1.000,00
• valor agregado (earned value): R$1.200,00
• valor planejado (planned value): R$1.600,00
Segundo o PMBOK, qual o índice de desempenho de custos (cost performance index) desse
projeto?
(a). 2,5
(b). 1,25
(c). 1,2
(d). 0,625
(e). 0,4
Solução:
O índice de desempenho de custos (IDC) mede a eficiência de custos em um projeto. Esse
índice é calculado a partir da divisão do valor agregado (VA) pelo custo real (CR). Assim,
para o projeto desta questão, teremos um IDC igual a 1,2 (1.2000/1.000). Esse resultado
nos informa que tal projeto encontra-se em uma condição favorável, pois o IDC é maior que
1,0. Caso o IDC fosse menor do que 1,0, diríamos, de acordo com o PMBOK, que o projeto
se encontraria em uma condição desfavorável.
Note que, para esta questão, o valor planejado (VP) fornecido não foi utilizado. Tal va-
lor é empregado no cálculo de outros índices, por exemplo, o índice de desempenho de
prazos (IDP), que ajuda a revelar se o projeto está adiantado ou atrasado em relação ao
planejado.
Página 4 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
2. Assuntos relacionados: Gerência de Projeto, Gerência de Custos, Gerenciamento de
Valor Agregado (GVA),
Banca: CESGRANRIO
Instituição: Petrobras
Cargo: Analista de Sistemas - Eng. de Software
Ano: 2008
Questão: 35
São enumeradas a seguir algumas métricas colhidas para determinado intervalo de tempo
ao longo da vida de um projeto.
I - Custo orçado do trabalho previsto.
II - Custo orçado do trabalho realizado.
III - Custo real do trabalho previsto.
IV - Custo real do trabalho realizado.
A técnica de Gerenciamento de Valor Agregado � GVA (em Inglês, Earned Value Manage-
ment � EVM ) se baseia nas métricas
(a). I e II, apenas.
(b). I e III, apenas.
(c). II e IV, apenas.
(d). I, II e IV, apenas.
(e). I, II, III e IV.
Solução:
A GVA é uma metodologia de gerenciamento usada para integrar o escopo, o cronograma e
os recursos de tal forma que se permita medir, objetivamente, o desempenho e o progresso
do projeto. Com essa metodologia é possível prever o desempenho do projeto com base no
desempenho passado.
Para utilizar a GVA, é importante seguir alguns processos essenciais a qualquer projeto,
como: definição e elaboração do escopo do projeto, incluindo a Estrutura Analítica do Pro-
jeto (EAP); elaboração do cronograma a partir da EAP; estimativa de custo, partindo da
alocação dos recursos às atividades do projeto; e monitoramento do projeto.
Uma vez que esses processos tenham sido realizados, é possível realizar estimativas baseando-
se nos princípios básicos da GVA:
• BCWS (Budgeted Cost for Work Scheduled ou Custo Orçado para Trabalho Planejado)
é o montante financeiro que o projeto, de acordo com o planejamento, deveria ter
consumido até um dado ponto do cronograma. O BCWS é conhecido também como
Valor Planejado (PV);
• BCWP (Budgeted Cost for Work Performed ou Custo Orçado para Trabalho Realizado)
reflete o valor do montante de trabalho que foi efetivamente realizado até uma data
específica. O BCWP é conhecido também como Valor Agregado (VA);
• ACWP (Actual Cost of Work Performed ou Custo Real do Trabalho Realizado) re-
presenta o custo efetivo do trabalho realizado até o momento. O ACWP é conhecido
também como Custo Real (CR).
Página 5 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Para medir o desempenho, o Custo Orçado do Trabalho Realizado é determinado e compa-
rado ao Custo Real do Trabalho Realizado. O progresso é medido pela comparação entre o
Valor Agregado e o Valor Planejado.
Conforme explicado anteriormente, a GVA se baseia nas métricas de Custo Orçado do Tra-
balho Previsto, Custo Orçado do Trabalho Realizado e Custo Real do Trabalho Realizado.
Logo, a alternativa correta é a letra d.
Página 6 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
3. Assuntos relacionados: Gerenciamento de Projetos, PMBOK, Gerenciamento Financeiro
de Projetos, Análise de Valor Agregado, EVA,
Banca: Cesgranrio
Instituição: Petrobras
Cargo: Analista de Sistemas Pleno - Processos
Ano: 2006Questão: 26
Um gerente espera que o desempenho do seu projeto continue apresentando no futuro o
mesmo tipo de variações ocorridas até então. Se o orçamento no término (ONT) = 390,
o valor agregado (VA) = 375 e o custo real (CR) = 325, qual é o valor da estimativa no
término (ENT)?
(a). 337,34
(b). 338,00
(c). 340,00
(d). 342,31
(e). 381,33
Solução:
A Análise do Valor Agregado (ou EVA, do Inglês, Earned Value Analysis) é um método de
avaliação de desempenho financeiro de projetos. No entanto, no PMBOK todas as referên-
cias ao termo EVA são substuídas pelo termo EVM (do Inglês, Earned Value Management),
pois EVA pode ser confundido com EVA (Economic Value Added), que é uma metodologia
uma metodologia patenteada pela consultoria Stern Stuart. Para efeitos de provas, os dois
acrônimos podem ser considerados equivalentes.
O EVA tem como objetivo a medida e a análise do desempenho obtido através da relação
entre os custos reais incorridos e o trabalho realizado no projeto dentro de um determinado
período de tempo. Em outras palavras, o EVA é a avaliação entre o que foi obtido (agregado)
em relação ao que foi realmente gasto e ao que se planejava gastar, sendo o valor agregado
a uma atividade, o valor orçado para ela.
Para alcançar a resposta da questão, primeiramente é necessário compreender o significado
de cada uma das métricas apresentadas na questão.
• VP (Valor Planejado): É o custo planejado para que se alcance uma determinada etapa
do projeto;
• CR (Custo Real): É o custo efetivamente desembolsado para o avanço do projeto.
Em outras palavras, é o quanto de fato se gastou para alcançar determinada etapa do
projeto;
• VA (Valor Agregado): É o custo planejado do projeto para o trabalho realizado até
o momento. Em outras palavras, o valor agregado é o valor dos serviços realmente
executados baseados nos custos orçados;
• ONT (Orçamento no Término): É o orçamento total do projeto, também conhecido
como baseline de custo. O ONT é a principal saída do processo de orçamentação;
• ENT (Estimativa no Término): É uma estimativa do custo total do projeto.
Página 7 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Neste ponto, vamos tentar compreender a essência da questão. O que precisamos determinar
é uma estimativa do custo total do projeto (ENT), tendo em vista que as atividades execu-
tadas até o momento tiveram custos diferentes dos custos planejados (VP é diferente de VA).
As atividades executadas até o momento estavam orçadas em 375 (VA). Porém, tais ati-
vidades foram executadas com um custo de apenas 325 (CR). Isso significa dizer que, até o
momento, gastou-se menos que o planejado. No EVA, tal variação é medida pelo Índice de
Desempenho de Custo, que é calculado pela seguinte fórmula:
IDC = VA/CR
Se IDC = 1 : Projeto está gastando exatamente o planejado
Se IDC > 1 : Projeto está gastando menos que o planejado
Se IDC < 1 : Projeto está gastando mais que o planejado
Portanto, no projeto em questão, o IDC vale 375/325. Como o gerente prevê que os �mesmos
tipos de variações� irão continuar ocorrendo no projeto, sabemos que no restante do projeto
será mantido o mesmo IDC. Por fim, para calcular o ENT, basta utilizar a seguinte fórmula:
ENT = CR + (ONT - VA)/IDC
E, aplicando a fórmula aos dados do problema, chegamos ao valor de 338, que corresponde
a alternativa B.
ENT = 325 + (390-375)/(375/325)
ENT = 325 + 13
ENT = 338
Página 8 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
4. Assuntos relacionados: Gerência de Projetos, PERT,GERT, CPM, Técnica de Avaliação,
Caminho Crítico,
Banca: Cesgranrio
Instituição: Petrobras
Cargo: Analista de Sistemas Pleno - Processos
Ano: 2006
Questão: 28
Você é gerente de um projeto para desenvolvimento de um novo pacote de software para
a área financeira de uma empresa. Neste projeto existem algumas atividades que exigem
testes especializados, e que talvez seja necessário repetir as atividades mais de uma vez.
Para o desenvolvimento do cronograma, qual das seguintes opções você deve escolher?
(a). A Técnica de Avaliação e Análise Gráfica (GERT), porque aceita o desvio condi-
cional e ciclos para a atividade do teste.
(b). A Técnica de Avaliação e Análise de Programas (PERT), porque aceita uma distri-
buição por média ponderada, que vai equilibrar o tempo necessário para a atividade
do teste.
(c). A Técnica de Avaliação e Análise de Programas (PERT), porque aceita o desvio
condicional e ciclos para a atividade do teste.
(d). O Método do Caminho Crítico, porque permite o cálculo da folga para a atividade
do teste.
(e). O Método do Caminho Crítico, porque aceita uma distribuição por média ponde-
rada, que vai equilibrar o tempo necessário para a atividade do teste.
Solução:
Vamos definir os termos citados das alternativas para que possamos entender as técnicas
utilizadas para desenvolvimento de cronograma.
Em um projeto, a duração de cada atividade pode ser diferente da prevista inicialmente. A
duração de uma atividade pode ser reduzida ou ampliada até por fatores que sequer podem
ser previstos como variações abruptas de indicadores econômicos, catástrofes, entre outros.
Para que essas variações nas durações das atividades possam ser levadas em consideração e,
consequentemente, que o planejamento seja mais confiável, o PERT (Program Evaluation
and Review Tecnique � Técnica de Avaliação e Revisão de Projetos) é utilizado. Neste caso,
cada atividade é entendida como uma variável aleatória e é assumido que a forma da distri-
buição de probabilidade dessa variável é a distribuição Beta.
Já o método CPM (Critical Path Method � Método do Caminho Crítico) utiliza valo-
res determinísticos e tanto o PERT quanto o CPM utilizam os conceitos de redes (grafos)
para planejar e visualizar a coordenação das atividades do projeto. Um caminho através
de uma rede é uma rota seguindo os arcos a partir de um nó inicial até um nó final e o
comprimento de um caminho é a soma das durações das atividades sobre o caminho. O
caminho com maior comprimento é o caminho crítico.
O GERT (Graphical Evaluation and Review Techniques � Técnica de Revisão e Avalia-
ção Gráfica) é um modelo parecido com PERT e CPM, no entanto, possui como caracte-
rística principal o controle relacionado aos loopings, como por exemplo, uma atividade de
inspeção do projeto que precisa ser repetida várias vezes. A técnica GERT combina a teoria
Página 9 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
de fluxo de sinais gráficos, das redes probabilísticas, do PERT/CPM e da árvore de decisões.
Como o GERT é justamente o método que leva em consideração a possibilidade de re-
petições de atividades, ele é o mais indicado para atender os requisitos do enunciado. Logo,
a alternativa correta é a letra (A).
Já alternativa (B) afirma que o PERT leva em consideração uma distribuição por média
ponderada. Essa afirmativa não deixa de ser verdade, mas não resolve, da mesma maneira
que o GERT, o problema da repetição das atividades.
A alternativa (C) se vale de uma afirmativa absolutamente falsa, pois quem aceita des-
vio condicional e ciclos é o GERT e não o PERT. As alternativas (D) e (E) também são
afirmativas falsas que atribuem, ao Método do Caminho Crítico (CPM), definições que são
válidas para outros métodos.
Página 10 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
5. Assuntos relacionados: Gerenciamento de Projetos, Análise de Viabilidade de Projetos,
Valor Presente Líquido, VPL,
Banca: Cesgranrio
Instituição: Petrobras
Cargo: Analista de SistemasPleno - Processos
Ano: 2006
Questão: 30
Uma analista está avaliando o VPL de um projeto. O projeto apresenta um investimento
inicial de R$ 24.000,00 e entradas esperadas de caixa de R$ 10.000,00, R$ 15.000,00 e R$
5.000,00 no final do primeiro, segundo e terceiro ano, respectivamente. Se o custo de capital
for de 10% ao ano, qual é o valor aproximado, em reais, do VPL do projeto?
(a). -1.244,18
(b). -3.272,73
(c). 1.244,18
(d). 3.272,73
(e). 3.768,60
Solução:
A análise do valor presente líquido (VPL) é um método tradicional de avaliação de viabi-
lidade de projetos. O método do VPL baseia-se no fato de que o valor do dinheiro está
relacionado com o tempo. Em um regime econômico inflacionário (ou seja, em que os preços
dos bens sobem com o passar do tempo), o dinheiro tende a perder o seu valor à medida que
o tempo passa. Em palavras bem simples, R$ 100,00 valem mais hoje do que os mesmos R$
100,00 daqui a 1 ano, por exemplo.
O segundo conceito fundamental que precisa ser compreendido é o conceito de fluxos de
caixa do projeto. Os fluxos do projeto são qualquer entrada ou saída de dinheiro que acon-
tece ao longo de um projeto. Quando o empreendor realiza o investimento inicial, ou realiza
pagamentos de fornecedores, por exemplo, temos um fluxo de caixa negativo. Já quando os
produtos produzidos pelo projeto são vendidos, e a empresa recebe algum pagamento, temos
um fluxo de caixa positivo. O somatório dos fluxos de caixa positivos e negativos para um
dado período é chamado fluxo de caixa líquido.
O objetivo do método VPL é �trazer� o valor de todos os fluxos de caixa do projeto para
uma data inicial, considerando o valor do dinheiro no tempo. Para realizar essa operação,
é necessário conhecer a taxa com a qual o dinheiro se desvaloriza ao longo do tempo. Tal
taxa é conhecida como Taxa de Desconto.
Quando todos os fluxos de caixa são trazidos para uma única data levando em conside-
ração o valor do dinheiro no tempo, passa a fazer sentido somar os fluxos de caixa. O
somatório de todos os fluxos de caixa de um projeto trazidos a data uma data base de ava-
liação (geralmente, a data inicial do projeto), é chamado Valo Presente Líquido do Projeto,
ou, simplesmente, VPL do Projeto.
A fórmula para cálculo do VPL do projeto é mostrada a seguir:
VPL = FC0 + FC1/(1+t)^1 + FC2/(1+t)^2 + FC3/(1+t)^3 + ... + FCn/(1+t)^n
Página 11 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
onde:
FC0 = Fluxo de caixa inicial. Geralmente, corresponde ao investimento inicial.
FCi = Fluxo de caixa do período i
t = Taxa de desconto
Cada uma das parcelas da fórmula mostra como o fluxo de caixa do período tem o seu
valor projetado para o presente. É importante frisar que no método VPL, utiliza-se juros
compostos. Portanto, no denominador de cada uma das parcelas utiliza-se o operador de
exponenciação, com o valor de acordo com o número de períodos.
Aplicando a fórmula nos dados do problema, teremos o seguinte resultado:
VPL = FC0 + FC1/(1+t)^1 + FC2/(1+t)^2 + FC3/(1+t)^3
VPL = -R$24000 + R$10.000/(1+0,1)^1 + R$15.000,00/(1+0,1)^2 + R$5.000/(1+0,1)^3
VPL = R$1.244,18
Logo, a resposta da questão é a alternativa C. Por fim, vale ainda mencionar mais uma
informação, que talvez seja ainda mais importante que a fórmula do VPL. Trata-se da
interpretação do valor obtido no cálculo do VPL. Em linhas gerais, o que temos é o seguinte:
VPL > 0 : O projeto é viável economicamente. Ou seja, o projeto gera valor.
VPL < 0 : O projeto é inviável economicamente. Ou seja, o projeto traz prejuízos.
VPL = 0 : A realização do projeto é indiferente. Não gera valor nem traz prejuízos.
Página 12 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
6. Assuntos relacionados: Gerência de Projeto, Gerência de Escopo, EAP,
Banca: CESGRANRIO
Instituição: Petrobras
Cargo: Analista de Sistemas - Eng. de Software
Ano: 2008
Questão: 34
A Estrutura Analítica do Projeto - EAP (em Inglês Work Breakdown Structure � WBS)
inclui
(a). estimativas de prazos.
(b). estimativas de custos.
(c). entregas internas e externas.
(d). alocação dos recursos às tarefas.
(e). estratégias para mitigação dos riscos.
Solução:
A área de gerenciamento do escopo compreende os processos necessários para assegurar que
o projeto inclua todo o trabalho necessário, e somente ele, para finalizar o projeto com
sucesso. A gerência de escopo tem como principal preocupação definir o que está ou não
incluído no projeto. A Estrutura Analítica do Projeto (EAP), elaborada pelo processo Criar
EAP, é uma das principais saídas da gerência de escopo.
(A) ERRADA
As estimativas de prazo são elaboradas pela área de gerenciamento de tempo com base
na estimativa de recursos necessários, sequenciamento e duração das atividades. O processo
responsável por realizar as estimativas de prazo é o Desenvolvimento do cronograma. Exis-
tem diversas ferramentas e técnicas para realizar o desenvolvimento do cronograma, como:
análise de rede do cronograma, método do caminha crítico, compressão do cronograma, ni-
velamento de recursos, software de gerenciamento de projetos (MS Project, Primavera), etc.
As estimativas de prazo são descritas no Plano de Gerenciamento do Cronograma e não na
EAP.
(B) ERRADA
As estimativas de custo são elaboradas pela área de gerenciamento de custos baseado na
estimativa dos recursos necessários para finalizar cada atividade do cronograma. Os cus-
tos das atividades do cronograma são estimados para todos os recursos cujos custos serão
lançados no projeto. As estimativas de custo podem ser geradas por meio de ferramentas
e técnicas, como: estimativa análoga, modelagem paramétrica, estimativa bottom-up, soft-
ware de gerenciamento de projetos, etc. As estimativas de custos estão descritas no Plano
de Gerenciamento de Custos e não na EAP.
(C) CORRETA
Uma entrega é qualquer produto ou serviço gerado pelo projeto. Segundo PMBOK, a
EAP é uma decomposição hierárquica orientada a entrega de trabalho a ser executado pela
equipe de projeto, para atingir os objetivos do projeto e criar as entregas necessárias. A
EAP subdivide o trabalho a ser realizado no projeto em partes menores, em que cada nível
Página 13 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
descendente representa uma definição mais detalhada do trabalho do projeto. O nível mais
baixo é conhecido como pacote de trabalho. É o ponto no qual o custo e o cronograma do
trabalho podem ser estimados de forma confiável. Enfim, todo o trabalho a ser executado
no projeto deve estar na EAP, e seus componentes auxiliam as partes interessadas (stakehol-
ders) a visualizar as entregas (internas ou externas).
(D) ERRADA
A alocação dos recursos às tarefas definidas na EAP é realiza pela área de gerenciamento
de recursos humanos e compreende a alocação propriamente dita da equipe ao projeto. Os
papéis e responsabilidades definidos serão destinados a uma pessoa ou grupo de pessoas. As
formas de alocação são: negociação, alocação prévia e contratação. A alocação de recursos
é descrita no Plano de Gerenciamento de Pessoal e não na EAP.
(E) ERRADA
Estratégia de mitigação de riscos é realizada pela área de gerenciamento de riscos e com-
preende planejar as respostas aos riscos de forma a reduzir as ameaças, ou seja, determinar
quais ações deverão ser tomadas para reduzir as ameaças aos objetivos do projeto. Várias
alternativas podem ser adotadas, como:
• evitar: mudar o plano do projeto para eliminar o risco;
• transferir: passar a resposta ao risco para terceiros;
• mitigar: estabelecer estratégias antecipadas para evitar que eventos causadoresdo
risco aconteçam;
• aceitar: não estabelece estratégias para lidar com os riscos.
As respostas aos riscos são incluídas no Registro de Riscos e não na EAP.
Página 14 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
7. Assuntos relacionados: Gerência de Projeto, WBS, PMBOK, Planejamento em Ondas
Sucessivas,
Banca: Cesgranrio
Instituição: BNDES
Cargo: Analista de Sistemas - Desenvolvimento
Ano: 2008
Questão: 68
Você montou a WBS (Work Breakdown Structure) do seu projeto e chegou ao seu nível
mais baixo, no qual foram especificadas as estimativas de custo e tempo. De acordo com o
PMBOK, esse nível da WBS é denominado
(a). subprojetos.
(b). pacotes de trabalho.
(c). entregas acordadas.
(d). entregas principais.
(e). fases do projeto.
Solução:
A WBS, em português traduzida para EAP - Estrutura Analítica do Projeto - integra o
conjunto de conhecimentos de gerenciamento de projetos voltado à gerência do escopo do
projeto. De acordo com o PMBoK, o gerenciamento do escopo do projeto inclui os processos
necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para
terminar o projeto com sucesso.
A WBS é um documento elaborado durante o planejamento do projeto. Sua função é
delimitar claramente todo o trabalho que deverá ser realizado e os entregáveis que o projeto
deverá gerar, sejam eles externos, internos ou intermediários. O objetivo não é limitar a
criatividade do trabalho, explicitando nos mínimos detalhes o que será feito, e sim permitir
que o trabalho possa ser acompanhado em termos de rendimento, custo, prazo.
Seguindo essas ideiaideias, a WBS é uma estrutura hierárquica, onde os níveis mais altos
representam entregáveis ou fases num aspecto mais amplo, e os mais baixos, vão descrevendo
as etapas necessárias para se atingir os níveis imediatamente superiores. Essa estrutura deve
seguir a regra dos 100%: a soma do percentual do trabalho previsto nos nós irmãos deve
completar 100% do trabalho necessário para alcançar o resultado previsto no nó pai. Esse
conceito serve em qualquer parte da estrutura. Com isso, garante-se que todo trabalho será
feito e apenas ele. Se o planejamento for a menor, o projeto não somará 100% ao final; se
for a maior, o somatório extrapolará os 100%, indicando que há algo a mais sendo feito.
A quantidade de níveis que podem ser gerados não é rígida. O importante é ter como
medida o contraponto entre uma estrutura pobre, que não dá suporte ao trabalho de geren-
ciamento do projeto e uma estrutura demasiadamente complexa, que gera um sobretrabalho
tão grande ao ponto de tornar-se inviável. Uma boa forma de medir o nível de detalhamento
ótimo é verificar se o patamar atual alcançado na hierarquia é suficiente para estimar custo
e cronograma do trabalho de forma confiável. Se for o caso, provavelmente este é um nível
de detalhe adequado de se descer. O último nível de um WBS é conhecido como pacote de
trabalho, e é caracterizado por possuir estas qualidades.
Página 15 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Pela sua característica de organizar o escopo de forma hierárquica, a EAP tem no topo
da árvore o projeto em si. Abaixo dela, não há regra que obrigue aparecerem apenas entre-
gáveis ou apenas fases. Todos os elementos de organização do trabalho podem ser incluídos,
inclusive de forma mesclada. Apesar disso, o mercado adota como prática trabalhar com
uma vertente ou com outra, evitando misturá-las no mesmo WBS. Projetos muito grandes
podem ter em níveis inferiores subprojetos, podendo estes, inclusive, serem planejados para
execução por outras empresas, em contratos do projeto. Um fato importante é lembrar de
colocar todas as fases e etapas do processo de gerenciamento do projeto dentro da WBSSe
estas etapas são necessárias para a execução do projeto, elas não podem ser negligenciadas
justamente no documento que trata do escopo do trabalho a ser realizado.
Alguns projetos grandes também podem ter fases muito distantes onde não seja possível
enxergar com clareza a estrutura do trabalho. Para esses casos, uma técnica comumente
aplicada é o planejamento em ondas sucessivas. Nesta técnica, a equipe de gerenciamento de
projetos espera até que a entrega ou subprojeto estejam esclarecidos para poder desenvolver
os detalhes da EAP.
No processo de criar a EAP, além da EAP propriamente dita, é gerado também o dici-
onário da EAP. Este documento de apoio à EAP descreve pormenorizadamente os detalhes
das etapas e entregáveis apresentados na EAP. Estes detalhes são apresentados com o ní-
vel de riqueza maior possível, permitindo que os devidos controles sejam mais eficientes.
Aqui, pode-se ter nos pacotes de trabalho, por exemplo, a descrição das etapas do traba-
lho esperadas, o prazo, custo e recursos envolvidos. Em fases e atividades, informações
como referências técnicas e de qualidade. Subprojetos desenvolvidos por terceiros podem
ter informações sobre o contrato, por exemplo.
Página 16 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
8. Assuntos relacionados: PMBOK,
Banca: Cespe
Instituição: ANAC
Cargo: Analista Administrativo - Tecnologia da Informação
Ano: 2009
Questão: 101�105
O PMBOK especifica nove áreas de conhecimento da gestão de projetos: escopo, tempo,
qualidade, custo, integração, recursos humanos, comunicação, riscos e aquisições. Como se
verifica na figura acima, há um grupo de processos de iniciação que procura facilitar a auto-
rização formal para se iniciar um novo projeto ou uma fase do projeto, enquanto os processos
de planejamento são utilizados pela equipe de gerenciamento de projetos para planejar ou
gerenciar um projeto para a organização. O grupo de processos de execução é relativo às
atividades utilizadas para se terminar o trabalho definido no plano de gerenciamento de
projeto e, dessa forma, cumprir os requisitos do projeto, enquanto o grupo de processos de
encerramento inclui todas as atividades necessárias para se entregar um produto terminado
ou encerrar um projeto cancelado.
Considerando as informações acima, julgue os itens de 101 a 105, a respeito das melho-
res práticas de gerenciamento de projetos.
101 O processo que consiste em desenvolver a declaração de escopo preliminar do projeto
trata principalmente da autorização do projeto ou, em um projeto com várias fases, de
uma fase do projeto; é usado para a documentação das necessidades de negócios e do
novo produto, serviço ou outro resultado que deva satisfazer esses requisitos.
102 Segundo o PMBOK, assim como nem todos os processos são necessários em todos os
projetos, nem todas as interações se aplicam a todos os projetos ou fases do projeto,
como o que ocorre quando os projetos que dependem de recursos exclusivos podem
definir funções e responsabilidades antes da definição do escopo.
103 O plano de gerenciamento do projeto determina qual trabalho deve ser realizado e quais
entregas precisam ser produzidas, e a declaração do escopo do projeto determina como
o trabalho deve ser realizado.
Página 17 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
104 O processo estimativa de custos, envolve a determinação dos recursos (pessoas, equi-
pamentos ou material), das quantidades de cada recurso que devem ser usadas e do
momento em que cada recurso deve estar disponível para que as atividades do projeto
sejam realizadas.
105 O sistema de controle de mudanças nos custos é documentado, controlado e monitorado
pelo plano de gerenciamento de custos e desvinculado do processo de controle integradode mudanças.
Solução:
Apesar do primeiro parágrafo deste grupo de questões abordar alguns aspectos importantes
sobre o PMBOK, é interessante aprofundarmos um pouco mais a descrição sobre o assunto.
PMBOK é o acrônimo de �Project Management Body of Knowledge�. Ele foi criado e
continua sendo mantido pelo PMI (Project Management Institute). Esse instituto foi con-
cebido em 1969 na Filadélfia (EUA).
A primeira versão oficial do PMBOK foi lançada em 1996 e, na verdade, tinha outro nome:
�A Guide to the Project Management Body of Knowledge�. Em 2000 e em 2004 foram lança-
das, respectivamente, as versões 2 e 3 do PMBOK. A quarta versão, lançada em 31/12/2008,
é hoje a mais atual. Ao longo dessas versões ajustes foram feitos e novos conceitos foram
agregados. Contudo, nenhuma modificação drástica foi feita na filosofia desse Guia.
O próprio Guia PMBOK v3 tem uma definição muito boa e que esclarece vários pontos
importantes para a resolução das questões a seguir. Vejamos:
�O principal objetivo do Guia PMBOK é identificar o subconjunto do Conjunto de conhe-
cimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática.
�Identificar� significa fornecer uma visão geral, e não uma descrição completa. �Ampla-
mente reconhecido� significa que o conhecimento e as práticas descritas são aplicáveis à
maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao
seu valor e sua utilidade. �Boa prática� significa que existe acordo geral de que a aplicação
correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em
uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento
descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de ge-
renciamento de projetos é responsável por determinar o que é adequado para um
projeto específico.�
Com relação a sua organização, o PMBOK se apresenta da seguinte forma. Esse Guia
de boas práticas prega um tipo de gerenciamento de projetos fortemente orientado a pro-
cessos. O número de processos varia em função da versão do PMBOK, mas para se ter uma
ideia geral, a sua versão 4 contém 42 processos. Esses processos são divididos entre 9 áreas
de conhecimento, são elas:
1. Integração
2. Escopo
3. Tempo
4. Custos
5. Qualidade
Página 18 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
6. Recursos humanos
7. Comunicações
8. Riscos
9. Aquisições
Os processos também são divididos, de acordo com as suas características comuns, em 5
grupos de processos, são eles:
1. Iniciação: define e autoriza o projeto ou uma fase do projeto;
2. Planejamento: define e refina os objetivos e planeja a ação necessária para alcançar
os objetivos e o escopo para os quais o projeto foi realizado;
3. Execução: integra pessoas e outros recursos para realizar o plano de gerenciamento
do projeto para o projeto;
4. Monitoramento e controle: mede e monitora regularmente o progresso para identi-
ficar variações em relação ao plano de gerenciamento do projeto, de forma que possam
ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto;
5. Encerramento: formaliza a aceitação do produto, serviço ou resultado e conduz o
projeto ou uma fase do projeto a um final ordenado.
Um erro muito comum é confundir os grupos de processos com as fases do projeto. Os
conceitos de grupo e fase não se equivalem nesse caso. Dependendo das características do
projeto, pode-se ter diversas fases e em cada uma delas diversos processos de vários grupos
podem ser executados. A Figura 1, do próprio Guia versão 3, nos auxilia nesse entendimento.
Figura 1: sequência típica de fases no ciclo de vida de um projeto.
Para concluirmos o entendimento da organização, podemos pensar que os processos são
dispostos em um plano de duas dimensões. Um eixo de grupos de processos e outro eixo de
área de conhecimento. A Figura 2, correspondente à versão 3 do PMBOK, traz justamente
essa disposição. É uma ótima prática ter essa disposição em mente.
Página 19 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
Figura 2: mapeamento entre os processos de gerenciamento de projetos e os grupos de processos
de gerenciamento de projetos e as áreas de conhecimento.
Página 20 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
101 ERRADO
Como pode ser visto na Figura 2, de fato existe na versão 3 do PMBOK um pro-
cesso chamado �Desenvolver a Declaração do Escopo Preliminar do Projeto�. Contudo,
o seu real objetivo é desenvolver uma descrição alto nível do escopo do projeto, cha-
mada de �Declaração do Escopo Preliminar do Projeto�.
Para a confecção deste documento, a equipe de gerenciamento geralmente utiliza como
entrada os seguinte documentos: Termo de Abertura do Projeto, Declaração do Traba-
lho do Projeto, Fatores Ambientais da Empresa e Ativos de Processos Organizacionais.
Mais adiante no projeto, durante a execução de outro processo (Definição do Escopo)
a Declaração Preliminar é refinada e dá origem a outro documento, chamado de �De-
claração do Escopo do Projeto�.
É importante destacar que o processo �Desenvolver a Declaração do Escopo Prelimi-
nar do Projeto� deixou de fazer parte do PMBOK em sua versão 4. Veja a seguir as
principais alterações entre as versões 3 e 4.
� o nome de todos os processos foram substituídos de substantivo para verbo;
� o número de processos foi reduzido de 44 para 42. Dois processos foram excluídos,
dois foram adicionados e seis foram reconfigurados. A saber:
∗ 4.2 Desenvolver a declaração do escopo preliminar do projeto - Eliminado;
∗ 4.7 Encerrar o projeto - Alterado para 4.6 Encerrar o projeto ou fase;
∗ 5.1 Planejamento do escopo - Eliminado;
∗ 5.1 Coletar os requisitos - Adicionado;
∗ 9.4 Gerenciar a equipe do projeto - Alterado de um processo de controle para
um processo de execução;
∗ 10.1 Identificar as partes interessadas - Adicionado;
∗ 10.4 Gerenciar as partes interessadas - Alterado para Gerenciar as expecta-
tivas das partes interessadas. Alterado de um processo de controle para um
processo de execução;
∗ 12.1 Planejar compras e aquisições e 12.2 Planejar contratações - Alterados
para 12.1 Planejar as aquisições;
∗ 12.3 Solicitar respostas de fornecedores e 12.4 Selecionar fornecedores - Alte-
rados para 12.2 Realizar aquisições.
O objetivo que o enunciado desta questão traz, na verdade, está relacionado a outro
processo: �Desenvolver o termo de abertura do projeto�. É justamente por isso que a
afirmação feita nesta questão está errada.
102 CERTO
Tendo em vista o exposto acima, principalmente a definição retirada do próprio PM-
BOK versão 3, não é difícil verificar que esta questão traz uma afirmação correta. Como
o PMBOK é um conjunto de boas práticas para gerenciamento de projetos, nem tudo
o que ele prega deve ser utilizado em todos os projetos. É função, principalmente, do
gerente de projetos alinhar as características do projeto, do organização, da equipe,
etc. às ferramentas e conceitos disponíveis no Guia.
Página 21 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
103 ERRADO
Um candidato desatente, mesmo conhecendo o assunto, pode se equivocar e marcar
esta questão como CERTO. Isso porque ela inverte os propósitos do Plano de Gerenci-
amento do Projeto e da Declaração do Escopo do Projeto.
O Plano de Gerenciamento do Projeto contempla tudo que é considerado necessá-
rio para definir como o projeto será executado, monitorado, controlado e encerrado.
Ele documenta quais serão as saídas de todos os processosconsiderados do grupo de
Processos de Planejamento. Além disso, ele inclui, dentre outros aspectos, o seguinte:
� o nível de implementação de cada processo selecionado;
� as descrições das ferramentas e técnicas que serão usadas para realizar esses pro-
cessos;
� como os processos selecionados serão usados para gerenciar o projeto específico,
inclusive as dependências e interações entre esses processos e as entradas e saídas
essenciais;
� como as mudanças serão monitoradas e controladas;
� a necessidade e as técnicas de comunicação entre as partes interessadas;
� o ciclo de vida do projeto selecionado e, para projetos com várias fases, as fases
associadas do projeto.
É interessante notar também que o Plano de Gerenciamento do Projeto pode ser cons-
tituído por planos auxiliares e outros tipos de documento. Alguns exemplos são:
� Plano de gerenciamento do escopo do projeto;
� Plano de gerenciamento do cronograma;
� Plano de gerenciamento da qualidade;
� Plano de gerenciamento das comunicações;
� Plano de gerenciamento de riscos;
� Plano de gerenciamento de aquisições;
� Lista de marcos;
� Linha de base do cronograma;
� Linha de base da qualidade;
� Registro de riscos.
Já a Declaração do Escopo do Projeto é uma das saídas do processo Definição do Es-
copo. Esse documento descreve detalhadamente quais devem ser as entregas do projeto
e qual é o trabalho necessário para que essas entregas sejam feitas. Ele também for-
nece um entendimento comum sobre qual é o escopo do projeto a todos os stakehouders.
104 ERRADO
Esta questão traz uma afirmação que confunde muitas pessoas. O processo que �envolve
a determinação dos recursos (pessoas, equipamentos ou material), das quantidades de
cada recurso que devem ser usadas e do momento em que cada recurso deve estar dis-
ponível para que as atividades do projeto sejam realizadas� é o chamado Estimativa de
Recursos da Atividade.
O processo Estimativa de Custos não determina nenhum aspecto relacionado a re-
cursos. Na verdade, ele obtém como entrada esse tipo de informação para desenvolver
Página 22 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
estimativas realistas dos custos dos recursos considerados necessários para terminar
cada atividades do projeto. Para isso, algumas das ferramentas utilizadas são: esti-
mativa análoga (projetos similares), estimativa paramétrica (modelos matemáticos),
análise de proposta de fornecedor, etc.
105 ERRADO
Ao ler com atenção a afirmação feita por esta questão, mesmo sem grandes conhe-
cimentos específicos sobre o PMBOK é provável que o candidato a julgue como errada.
Afinal de contas, se há um controle integrado de mudanças, ele certamente integra
vários processos concorrentes relacionados a mudanças. Esse tipo de leitura crítica é
muito importante para quem busca uma vaga em um concurso público.
De qualquer forma, vamos aos conceitos que aparecem nesta questão.
O Sistema de Controle de Mudanças nos Custos é uma das possíveis ferramentas uti-
lizadas no processo de Controle de Custos. Esse sistema é sim documentado no Plano
de Gerenciamento de Custos. Ele define os procedimentos, formulários, documentos e
níveis de aprovação necessários através dos quais é possível realizar mudanças na linha
de base dos custos.
Já o processo de Controle Integrado de Mudanças, como o próprio nome revela, trata
da rejeição ou aprovação, de forma centralizada, de todas as mudanças significativas no
projeto, indiferentemente da área de conhecimento envolvida. Sem esse tipo de controle
centralizado, equipes e processos correlacionados dificilmente se alinhariam novamente
depois de mudanças significativas.
Um exemplo trivial de problema seria o seguinte. Imagine que por algum motivo o
cronograma do projeto tivesse que ser reajustado, é claro para menos. Caso essa mu-
dança fosse feita de forma isolada, como os processos que lidam com custo e a qualidade
do projeto poderiam se adequar a esse novo cronograma? Em projetos grandes, onde
centenas ou talvez milhares de pessoas estão envolvidas, muito provavelmente isso não
seria feito, aumentando consideravelmente as possibilidades de fracasso no projeto. Por
outro lado, sendo o controle de mudanças centralizado, todas as equipes e processos que
podem sofrer impactos com as mudanças aprovadas são notificadas e, assim, podem
realizar seus ajustes necessários.
Página 23 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
9. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo, Monte Carlo,
Banca: FCC
Instituição: MPU
Cargo: Analista de Desenvolvimento de Sistemas
Ano: 2007
Questão: 54
De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise
de risco de prazos são possíveis utilizando
(a). o Arrow Diagramming Method.
(b). a técnica Monte Carlo.
(c). o modelo WBS.
(d). a análise de custo/benefício.
(e). o Project Charter.
Solução:
Análise de risco é o uso sistemático da informação disponível para determinar quão frequen-
temente eventos definidos podem vir a ocorrer e a magnitude de suas consequências.
A análise de risco pode ser realizada qualitativamente ou quantitativamente. A análise
de risco qualitativa envolve a avaliação de uma situação por ponderações subjetivas e é ca-
racteriza por declarações como Isto parece muito arriscado ou Nós provavelmente teremos
um bom retorno disto.
A análise de risco quantitativa busca associar valores numéricos aos riscos. Vamos focar
no estudo da análise quantitativa para resolvermos esta questão.
Os objetivos da análise quantitativa são:
• determinar a probabilidade de se conquistar um objetivo específico do projeto;
• quantificar a exposição do risco para o projeto, e determinar o tamanho da reserva
contingência do custo e cronograma que pode ser necessária;
• identificar riscos que requerem maior atenção, quantificando sua contribuição relativa
ao risco do projeto;
• identificar custo, cronograma, ou objetivos de escopo realístico e alcançável.
As técnicas e ferramentas para a análise quantitativa do risco são:
• Análise de sensibilidade: Essa análise quantifica as consequências associadas à va-
riação de cada elemento no projeto quando os outros elementos são mantidos em seus
valores iniciais;
• Análise da árvore de decisão: A árvore de decisão é um diagrama que descreve
uma decisão que está sendo considerada e as implicações da escolha de uma ou outra
das alternativas disponíveis. É usada quando alguns futuros cenários ou resultados de
ações são incertos. Ela incorpora as probabilidades e os custos ou premiações de cada
caminho lógico de eventos e decisões futuras;
• Análise do valor monetário esperado: É um conceito estatístico que calcula o
resultado médio quando o futuro inclui cenários que podem ou não acontecer;
Página 24 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
• Modelagem e simulação: Uma simulação utiliza um modelo que traduz as incertezas
em um nível detalhado do projeto para seu impacto potencial nos objetivos iniciais. As
simulações são normalmente realizadas usando a técnica de Monte Carlo.
Agora sabemos que a técnica de Monte Carlo é utilizada na análise quantitativa de riscos
para realizar simulações envolvendo tanto prazos quanto custos. A alternativa a ser marcada
é a letra (B).
Vamos conhecer os termos utilizados nas outras alternativas:
(A) Arrow Diagramming Method, também conhecido como Método do diagrama de se-
tas (MDS), é uma técnica de diagramação de rede do cronograma onde as atividades do
cronograma são representadas por setas. A extremidade final da seta representa o início, ea cabeça representa o término da atividade do cronograma.
(C) Work Breakdown Struct também conhecido como estrutura analítica do projeto (EAP).
Ela organiza e define o escopo total do projeto. Cada nível descendente representa uma
definição cada vez mais detalhada do trabalho do projeto.
(E) Project Charter é o documento que reconhece formalmente a existência do projeto,
menciona detalhes sobre os principais objetivos e razões pela existência deste projeto.
Página 25 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
10. Assuntos relacionados: Desenvolvimento de Sistemas, Gerenciamento de Projetos, Ge-
renciamento de Riscos, Árvores de Decisão,
Banca: Cesgranrio
Instituição: BNDES
Cargo: Analista de Sistemas - Desenvolvimento
Ano: 2008
Questão: 37
Observe a árvore de decisão abaixo relativa ao desenvolvimento de um projeto de software.
Os números decimais entre parênteses representam o valor da probabilidade da escolha do
ramo, enquanto que o valor em reais, o custo de cada opção.
Analisando a árvore acima, conclui-se que:
(a). o custo esperado para realizar o trabalho contratando desenvolvimento terceirizado
é de R$ 7.480,00.
(b). o custo estimado para Desenvolver internamente é menor do que o custo estimado
para Contratar desenvolvimento terceirizado.
(c). quando não há probabilidade associada ao primeiro nível da árvore de decisão,
pode-se assumir que essa probabilidade é de 50%.
(d). supondo que a opção Contratar desenvolvimento terceirizado seja escolhida, e que
uma equipe inexperiente assuma o trabalho, o custo esperado será de R$ 4.480,00.
(e). as probabilidades associadas à árvore de decisão estão inconsistentes.
Solução:
A questão mostra uma aplicação prática de uma árvore de decisão no contexto de um projeto
de software, em que se objetiva calcular o custo do projeto de acordo com as decisões que
podem ser tomadas. Antes de iniciarmos os cálculos, vamos primeiro introduzir basicamente
as árvores de decisão e suas utilidade básica.
As árvores de decisão são representações gráficas dos diversos caminhos que podem ser
seguidos no contexto de um problema de tomada de decisão. Em outras palavras, as árvo-
res de decisão procuram mostrar graficamente as consequências de decisões que podem ser
tomadas em uma determinada situação. Comumente, as árvores de decisão também exibem
as probabilidades associadas às decisões tomadas, sendo, portanto, ótimas ferramentas para
a avaliação quantitativa de riscos.
Página 26 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
É importante observar que, para serem consistentes, a soma das probabilidades das decisões
que podem ser tomadas a partir de um determinado nó da árvore sempre devem dar 1 (ou
100%). Isso pode ser observado na figura da questão no momento em que se opta por con-
tratar desenvolvimento terceirizado. A chance de contratar uma equipe experiente é de 30%,
enquanto a chance de que a equipe contratada seja inexperiente é de 70%. Como a árvore
apresentada obedece a essa regra em todos os seus pontos, podemos eliminar a alternativa E.
O valor esperado em um determinado nó da árvore pode ser calculado como a média dos
valores de cada uma de suas ramificações, ponderados pelas suas probabilidades. No caso da
contratação de desenvolvimento terceirizado de uma equipe inexperiente, o custo esperado
do projeto seria:
(R$7000 x 0.8) + (R$4000 x 0.2) = R$6400
Logo, a alternativa D está errada. Calculado o custo esperado do desenvolvimento tercei-
rizado com uma equipe inexperiente, podemos agora calcular o valor do nó imediatamente
acima, ou seja, o custo esperado do desenvolvimento terceirizado.
(R$6400 x 0.7) + (R$9000 x 0.3) = R$7180
Com isso podemos concluir que o custo esperado do desenvolvimento terceirizado, R$
7.180,00, é maior do que o custo esperado de se desenvolver internamente. Logo, a al-
ternativa A está errada, e a alternativa B está certa.
A alternativa C é falsa por definição. Se não se conhece a probabilidade de uma deter-
minada decisão, não há que se fazer considerações a respeito dela. No cenário apresentado,
pela falta dessa informação na primeira decisão tomada � desenvolver internamente ou ter-
ceirizar � torna-se impossível calcular o valor esperado do projeto como um todo. O máximo
que se poderia dizer é que o valor máximo esperado para o projeto seria de R$ 7.180,00 (no
caso de terceirização), e que o valor mínimo esperado para o projeto seria de R$ 7.000,00,
no caso de desenvolvimento interno.
Página 27 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
11. Assuntos relacionados: Gerenciamento de Projetos, Gerenciamento de Riscos, Matriz de
Probabilidade e Impacto de Riscos,
Banca: Cesgranrio
Instituição: Petrobras
Cargo: Analista de Sistemas Pleno - Processos
Ano: 2006
Questão: 29
Um gerente de projeto está construindo uma matriz de probabilidade e impacto de riscos
para o seu projeto. Assim, esta matriz multiplica:
(a). a probabilidade do risco pelo custo do impacto para calcular o valor esperado do
evento de risco.
(b). a probabilidade do risco pela probabilidade de impacto � que caem no intervalo
de 0,0 e 5,0 � para calcular a probabilidade dos valores dos riscos.
(c). a probabilidade do risco pelo valor esperado do evento de risco para calcular o
impacto e atribuir uma pontuação ao risco, com base em um limiar pré-definido.
(d). as escalas de probabilidade do risco e as escaladas de impacto do risco � que caem
no intervalo 0,5 e 1,0 � para calcular a pontuação do risco.
(e). as escalas de probabilidade do risco � que caem no intervalo de 0,0 e 1,0 � pelas
escalas de impacto do risco para calcular a pontuação do risco.
Solução:
Em Gerência de Projetos, a área de gerenciamento de riscos é responsável por minimizar a
probabilidade de ocorrência de desvios ao longo do ciclo de vida do projeto. Relembremos
os processos do Gerenciamento de Riscos:
• Planejamento: definir qual será a abordagem aos riscos;
• Identificação: identificar, descrever e classificar os riscos;
• Análise Qualitativa: associar probabilidades e graus de impacto aos riscos através
de técnicas como Matriz de Graduação, Matriz Probabilidade x Impacto (nosso foco
nesta questão!);
• Análise Quantitativa: associar probabilidades e graus de impacto de forma numérica
utilizando técnicas como Análise de Sensibilidade, Árvore de Decisão e Simulações;
• Planejamento de Respostas: definir qual ação será tomada mediante os riscos iden-
tificados (ex: evitar, transferir, mitigar, aceitar);
• Controle e Monitoração: garantir a execução do plano, identificar novos riscos,
monitorar riscos residuais e realizar ajustes necessários.
Como dissemos acima, o nosso foco nesta questão é a Análise Qualitativa de Riscos, a qual
visa à detecção do impacto dos riscos identificados sobre os objetivos do projeto e sua pro-
babilidade de ocorrência, classificando, paralelamente, os riscos por prioridade, de acordo
com os efeitos sobre os objetivos do projeto (por exemplo, alto, médio ou baixo).
A ferramenta (e técnica) Matriz de classificação de Riscos por Probabilidade e Impacto
(PI) tem como objetivo atribuir uma classificação genérica a cada um dos riscos identifica-
dos do projeto, geralmente expressa como alta (�condição vermelha�), moderada (�condição
amarela�) ou baixa (�condição verde�). Em uma matriz em preto e branco, essas condições
podem ser indicadas pelos diferentes tons de cinza. Especificamente, na Figura 3, a área
Página 28 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
cinza escuro (com os números mais altos) representarisco alto; a área cinza médio (com os
números mais baixos) representa risco baixo; e a área cinza claro (com números intermediá-
rios) representa risco moderado. Esse tipo de classificação é denominado de escala ordinal,
porque os valores são ordenados de forma descendente. Ao fim desse processo, portanto, os
riscos podem ser enumerados por ordem de prioridade de atenção.
Figura 3: Matriz de Probabilidade e Impacto.
A pontuação do risco ajuda a orientar as respostas a riscos. Por exemplo, riscos que, se
ocorrerem, terão um impacto negativo nos objetivos (ameaças) e que se encontram na zona
de alto risco (cinza escuro) da matriz podem exigir ações prioritárias e estratégias agressivas
de resposta. As ameaças na zona de baixo risco (cinza médio) podem não exigir nenhuma
ação de gerenciamento pró-ativo, além da sua colocação em uma lista de observação ou da
sua adição a uma reserva para contingências. Isso ocorre de forma similar para as oportu-
nidades. Portanto, deve-se buscar primeiro as oportunidades na zona de alto risco (cinza
escuro) que podem ser obtidas mais facilmente e oferecem o maior benefício. As oportuni-
dades na zona de baixo risco (cinza médio) devem ser monitoradas.
A partir da Figura 3 podemos observar, facilmente, que a matriz de PI é determinada a
partir da multiplicação de dois valores: o valor da probabilidade do risco (eixo y) vezes
o valor do seu impacto (eixo x) (cada qual gerado na escala correspondente). Saiba
que antes de se chagar a matriz PI, são elaboradas a escala de probabilidades e a escala de
impacto dos riscos. O objetivo dessas escalas é desenvolver medidas predefinidas que deter-
minem que valor atribuir a determinado evento de risco.
Assim, concluímos que a alternativa A está errada porque na multiplicação não se utiliza
o valor da probabilidade e do custo do impacto de um risco diretamente, em vez disso são
adotados os valores associados às respectivas escalas (eixo x e eixo y, na Figura). Podemos
eliminar as alternativas B e C pelo mesmo motivo. Já a alternativa D está errada porque
não podemos saber, à priori, o valor da escala de impacto de risco (a avaliação de impacto
dos riscos costuma se dar por meio de técnicas de opinião especializada e entrevistas). Por-
tanto, a alternativa E está correta (lembre-se que a probabilidade de um evento é sempre
um número entre 0 e 1).
Página 29 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
12. Assuntos relacionados: Gerência de Projeto, Gerência de Integração, Controle Integrado
de Mudanças,
Banca: CESGRANRIO
Instituição: Petrobras
Cargo: Analista de Sistemas - Eng. de Software
Ano: 2008
Questão: 38
É recomendado que um projeto possua um mecanismo formal e documentado de controle
de mudanças. Sobre este mecanismo, são feitas as afirmativas a seguir.
I - O mecanismo deve rastrear e tratar mudanças em quaisquer fatores críticos de sucesso
do projeto, incluindo escopo, prazos e custos.
II - Para tornar o processo gerenciável, é recomendado que sejam rastreadas apenas mu-
danças que possuam impacto significativo no custo ou nos prazos do projeto e que não
sejam rejeitadas em primeira análise.
III - A avaliação e a aprovação de quaisquer solicitações de mudanças são atribuições
exclusivas do gerente de projeto, pois o mesmo detém a autoridade e a responsabilidade
sobre os resultados finais do projeto perante os stakeholders.
IV - Tipicamente, o mecanismo de controle de mudanças prevê algumas categorias de mu-
danças que são automaticamente aprovadas � tais como as resultantes de emergências
� as quais devem ser registradas e rastreadas, da mesma forma que as demais.
Estão corretas APENAS as afirmativas:
(a). I e II.
(b). I e III.
(c). I e IV.
(d). II e III.
(e). III e IV.
Solução:
O controle de mudanças ou controle integrado de mudanças é um dos processos da área de
gerenciamento de integração. Essa área compreende os processos necessários para garan-
tir a integração efetiva entre os processos das áreas de gerenciamento visando os objetivos
do projeto. A integração das áreas, por exemplo, consiste em escolher sobre quais pontos
concentrar recursos e esforço em quais dias específicos, antecipando possíveis problemas,
tratando-os antes de se tornarem críticos e coordenando o trabalho visando o bem geral do
projeto.
Mais especificamente, o processo controle integrado de mudanças consiste em registrar as
mudanças no projeto, seus motivos e respectivos impactos e realizar as alterações necessá-
rias de forma integrada visando o projeto como todo. O controle de mudanças é realizado
durante todo o projeto. Uma mudança pode exigir alteração nas estimativas de custos,
sequências de atividades, datas de cronograma e recursos necessários, e tudo isso deve ser
monitorado e controlado para o sucesso do projeto.
Uma das ferramentas ou técnicas para o controle integrado de mudanças é o sistema de
controle de mudanças: um conjunto de procedimentos formais e documentados que definem
como as entregas e a documentação do projeto serão controladas, alteradas e aprovadas.
Página 30 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
De acordo com as afirmações da questão, temos:
I � Conforme explicado anteriormente, o controle de mudanças deve monitor e tratar
todas as mudanças de forma integrada visando o sucesso do projeto. Isso inclui os
fatores críticos do projeto como escopo, prazo, custo, recursos necessários, orçamento
e requisitos de qualidade. Logo, afirmativa verdadeira;
II � As mudanças aprovadas devem ser monitoradas e avaliadas levando em consideração
não apenas o custo ou prazo do projeto, mas também o impacto no escopo, orçamento
e requisitos de qualidade. Logo, afirmação falsa;
III � Todas as mudanças solicitadas e documentas devem ser aceitas ou rejeitadas por uma
autoridade dentro da equipe de gerenciamento de projetos ou por uma organização ex-
terna que represente o patrocinador ou cliente. O sistema de controle de mudanças
muitas vezes inclui um comitê de controle de mudanças, responsável pela aprovação ou
rejeição das mudanças solicitadas. As funções e responsabilidades desses comitês são
definidas claramente nos procedimentos de controle de configuração e de controle de
mudanças e são acordadas com o patrocinador, com o cliente e com outras partes inte-
ressadas. Ou seja, a avaliação e aprovação das mudanças não dependem exclusivamente
do gerente de projetos, mas de um comitê. Logo, afirmação falsa;
IV � O sistema de controle de mudanças deve também incluir procedimentos para tratar
mudanças que podem ser aprovadas sem revisão prévia; por exemplo, como um re-
sultado de emergências. Tipicamente, um sistema de controle de mudanças tem uma
forma �automática� de aprovação de categorias específicas de mudanças. Essas mudan-
ças devem ainda ser documentadas e capturadas de forma que as transformações na
linha base do projeto possam ser registradas. Logo, afirmação verdadeira.
Conforme exposto acima, a alternativa correta é a letra c.
Página 31 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
13. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo, Desenvolvimento de
Cronograma,
Banca: CESGRANRIO
Instituição: Petrobras
Cargo: Analista de Sistemas - Eng. de Software
Ano: 2008
Questão: 33
Ao apresentar o cronograma de um projeto à diretoria da empresa, o gerente foi informado
de que a data de término do projeto deverá ser antecipada em 3 meses. Esta exigência
implicará, necessariamente, em
(a). refazer as estimativas de esforço para uma ou mais tarefas do projeto.
(b). reduzir a duração do caminho crítico doprojeto.
(c). alocar mais recursos ao projeto.
(d). fazer entregas diferentes das especificadas.
(e). aumentar o custo do projeto.
Solução:
(A) ERRADA
A antecipação da data final do projeto consiste, normalmente, em alterar a duração de
atividades que pertencem ao caminho crítico. O caminho crítico, geralmente, é a sequência
de atividades do cronograma que determina a duração do projeto, isto é, o caminho mais
longo do projeto. Dependendo da técnica de compreensão de cronograma utilizada, há a
necessidade de refazer as estimativas de esforço das atividades relacionadas ao caminho crí-
tico, mas não é uma implicação necessária para reduzir o prazo de um projeto.
(B) CORRETA
Antecipar a data final do projeto em 3 meses implica em alterar as estimativas de dura-
ção das atividades do caminho crítico, ou seja, reduzir a duração do caminho crítico. Isso
é realizado utilizando as técnicas de compressão de cronograma que consistem em redu-
zir o prazo do projeto definido inicialmente sem afetar o escopo para atender restrições
de cronograma. As técnicas utilizadas são a compressão e o paralelismo. Na comprensão,
as compensações entre custo e cronograma são analisadas para determinar o máximo de
compressão para o menor custo incremental. Essa técnica pode produzir uma alternativa
não viável devido ao aumento de custo. Na de paralelismo, as fases ou atividades que nor-
malmente serão realizadas em sequenciamento são realizadas em paralelo. Tal técnica pode
gerar retrabalho, devido a falta de informações mais detalhadas a respeito de uma atividade.
(C) ERRADA
Alocar mais recursos ao projeto não é implicação necessária para reduzir o prazo de um
projeto. Dependendo da técnica de comprensão de cronograma utilizada, há a necessidade
de alocar mais recursos para as atividades relacionadas ao caminho crítico do projeto, mas
para isso tem que ser analisado o impacto financeiro no projeto.
Página 32 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
(D) ERRADA
Algumas vezes, ao se diminuir um cronograma, altera-se também o escopo do projeto. É
certo que não será a gerência de tempo que fará a alteração do escopo. Será sim a gerência de
escopo, informada da diminuição do cronograma pela gerência de integração. De qualquer
forma, é importante perceber que uma alteração no cronograma não necessariamente gera
alterações das entregas.
(E) ERRADA
Aumentar o custo de um projeto depende da aprovação das pessoas interessadas, os sta-
keholders, no projeto, e não é uma negociação fácil. Além de que, o aumento de um custo
de um projeto não é uma implicação necessária para reduzir o prazo de um projeto, conforme
já descrevemos anteriormente.
Página 33 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
14. Assuntos relacionados: Gerência de Projeto, Gerência de Tempo,
Banca: FCC
Instituição: MPU
Cargo: Analista de Desenvolvimento de Sistemas
Ano: 2007
Questão: 55
Considerando o corpo de conhecimento de gerenciamento de projetos, são dependências
usadas no sequenciamento de atividades, inerentes à natureza do trabalho que está sendo
feito e que freqüentemente envolvem limitações físicas. Também chamadas de lógica rígida
(hard logic). Trata-se das dependências
(a). explícitas.
(b). externas.
(c). arbitradas.
(d). mandatórias.
(e). prioritárias.
Solução:
A Gerência de Tempo do Projeto inclui os processos necessários para assegurar que o projeto
será implementado no prazo previsto. Os seguintes processos principais:
1. Definição das Atividades;
2. Sequenciamento das Atividades;
3. Estimativa da Duração das Atividades;
4. Desenvolvimento do Cronograma;
5. Controle do Cronograma.
No sequenciamento de atividades, os relacionamentos lógicos entre as atividades do crono-
grama são identificados e documentados. O sequenciamento faz uso de relações de prece-
dência adequadas para dar suporte à elaboração do cronograma.
Para definir a sequência entre as atividades, são utilizados os seguintes tipos de depen-
dências:
• Dependências obrigatórias ou mandatórias: devem respeitar as limitações físicas
ou restritivas e precisam ser modeladas no planejamento. Ou seja, há fatores que
impossibilitam o início de determinada atividade. Por exemplo, antes de testar um
código, ele deve, antes, ser construído. Algumas vezes essas dependências são chamadas
também de lógica rígida (hard logic);
• Dependências arbitradas: são dependências estabelecidas com base no conheci-
mento das melhores práticas dentro de uma área de aplicação específica ou em algum
aspecto pouco usual do projeto. As dependências arbitradas podem, também, ser cha-
madas de lógica preferida (prefered logic), lógica preferencial (preferential logic) ou
lógica fina (soft logic);
• Dependências externas: são aquelas que envolvem relacionamento entre atividades
do projeto e atividades que não são do projeto. Por exemplo, a atividade de teste em
um projeto de software pode ser dependente da entrega de um hardware de fornecedor
externo.
Página 34 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
A letra a ser marcada é a letra (D), já que as dependências mandatórias respeitam as
limitações físicas e também são conhecidas como hard logic.
Página 35 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
15. Assuntos relacionados: Gerenciamento de Projetos, Método do Diagrama de Precedência
(MDP),
Banca: FCC
Instituição: TRT 15a Região
Cargo: Analista Judiciário - Tecnologia da Informação
Ano: 2009
Questão: 47
Os tipos de dependências ou de relações de precedência incluídos no MDP - Método do
Diagrama de Precedência são em número de
(a). 1.
(b). 2.
(c). 3.
(d). 4.
(e). 5.
Solução:
O MDP (Método do Diagrama de Precedência) é um método de construção de diagramas
de rede de cronograma do projeto. Esse diagrama usa retângulos, chamados de nós, para
representar as atividades, que são conectadas através de setas. Tais setas são utilizadas para
mostrar as dependências entre os nós conectados. A Figura 4 apresenta um MDP, como
exemplo, de um projeto relativamente simples.
Figura 4: exemplo de MDP.
Nesse tipo de diagrama, existem 4 tipos de relações dependência:
• Término para Início: a iniciação da atividade sucessora depende do término da
atividade predecessora. Este é o tipo mais comum;
• Término para Término: o término da atividade sucessora depende do término da
atividade predecessora;
• Início para Início: a iniciação da atividade sucessora depende da iniciação da ativi-
dade predecessora;
• Início para Término: o término da atividade sucessora depende da iniciação da
atividade predecessora.
Portanto, é a alternativa D a correta.
Página 36 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
16. Assuntos relacionados: Gerência de Projeto, PMBOK, Cronograma, Caminho Crítico,
Banca: Cesgranrio
Instituição: BNDES
Cargo: Analista de Sistemas - Desenvolvimento
Ano: 2008
Questão: 65
O diagrama de rede abaixo representa as atividades de um cronograma de um projeto, onde
a duração de cada atividade é mensurada em dias.
Se as durações das atividades H e I fossem alteradas, respectivamente, para 4 e 6 dias, qual
seria o caminho crítico?
(a). A-B-D-I
(b). A-C-E-I
(c). A-C-E-F-H
(d). A-G-F-H
(e). A-G-I
Solução:
A resolução dessa questão é simples e envolve o conhecimento do gerenciamento de tempo
previsto pelas melhores práticas contidas no PMBoK. O caminho crítico de um projeto é
considerado como a sequênciade atividades que levam o projeto do início ao fim cujas du-
rações, se sofrerem qualquer atraso, acarretarão em atraso no projeto como um todo.
Em um projeto onde não há paralelização de atividades, podemos considerar que a sequência
natural das atividades é o próprio caminho crítico. Entretanto, essa análise se altera quando
possuímos atividades que ocorrem concomitantemente. Nesses casos, teremos atividades que
durarão mais do que outras. As atividades com duração maior geram folgas para o início
das outras paralelas a ela. No caso do enunciado, olhemos os caminhos para chegar do ponto
2 ao 5. Veja que temos sequências de atividades paralelas:
• atividades B e D, com duração de 2 cada uma e duração de 4 no total;
• atividade G, com duração de 6;
• atividades C e E, com duração de 2 cada uma e duração de 4 no total.
Veja que, para chegarmos até 5, obrigatoriamente teremos que realizar todas as ativida-
des A, B, C, D, E e G. Como a atividade G tem duração de 6, ela dá uma folga para as
Página 37 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
sequências B->D e C->E de 2 unidades de tempo. Logo, um atraso compartilhado de até
2 unidades de tempo nas atividades B e D (entre si) e C e E (também entre si) não atra-
sará o cronograma. Entretanto, qualquer atraso na atividade G ocasionará atraso no projeto.
Assim, para facilitar, vamos analisar o diagrama já com os valores propostos pelo enun-
ciado na Figura 5:
Figura 5: diagrama de rede - durações alteradas.
Com a definição acima, podemos ver que o caminho crítico passa a ser A->G->F->H.
Página 38 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
17. Assuntos relacionados: Gerência de Projeto, Gerenciamento de Tempo, Gerenciamento
de Custos, Assuntos relacionados: SPI
Banca: Cesgranrio
Instituição: Petrobras
Cargo: Analista de Sistemas - Infraestrutura
Ano: 2008
Questão: 49
Um gerente, após realizar todos os ajustes necessários no cronograma do seu projeto, obteve
a tabela (figura) abaixo.
Sabe-se que para este projeto PV (Planned Value) = 400, AC (Actual Cost) = 480 e EV
(Earned Value) = 320.
Qual é a duração total, em dias, do projeto do gerente, sem considerar finais de semana
e feriados, e qual é o valor do SPI (Schedule Performance Index)?
(a). 134 e 0,67
(b). 134 e 0,80
(c). 138 e 0,67
(d). 138 e 0,80
(e). 138 e 0,83
Solução:
Duração total do projeto
A duração total de um projeto é dada é pela soma da duração das atividades críticas do
projeto. A duração das atividades e determinação de quais atividades críticas são definidas
no processo de Desenvolvimento do cronograma.
Segundo o PMBOK, o Desenvolvimento de cronograma é um dos processos da área de
conhecimento de Gerenciamento de Tempo. Esta área tem como objetivo determinar as
dependências e a duração das atividades do projeto, ou seja, elaborar o cronograma do pro-
jeto, e, ao longo do desenvolvimento, acompanhá-lo e controlá-lo.
A área de Gerenciamento de Tempo inclui os seguintes processos:
• definição da atividade: definição de quais as atividades necessárias para produzir as
várias entregas do projeto, isto é, os produtos e subprodutos identificados na EAP
(Estrutura analítica do projeto - Work Breakdown Structure (WBS));
Página 39 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
• sequenciamento de atividades: identificação e documentação das dependências entre as
atividades do cronograma;
• estimativa de recursos da atividade: estimativa do tipo e das quantidades de recursos
necessários para realizar cada atividade do cronograma;
• estimativa de duração da atividade: estimativa do número de períodos de trabalho que
serão necessários para terminar as atividades individuais do cronograma;
• desenvolvimento do cronograma: análise dos recursos necessários, restrições do cro-
nograma, durações e seqüências de atividades para criar o cronograma do projeto.
Ou seja, este processo consiste em formalizar o cronograma, identificando suas datas,
caminhos críticos e registrando os marcos e pontos de controle identificados;
• controle do cronograma: durante o desenvolvimento do projeto, o cronograma deve ser
comparado, analisado e revisto sempre que necessário.
O caminho crítico, geralmente, é a seqüência de atividades do cronograma que determina a
duração do projeto, isto é, o caminho mais longo do projeto. Atividade crítica é qualquer
atividade do cronograma em um caminho crítico. Qualquer atraso em uma atividade crítica,
pode resultar, em um aumento da duração total do projeto.
Para calcularmos a duração total do projeto, conforme a tabela desta questão, devemos
definir as atividades do caminho crítico. Para isso, verificamos as dependências entre as
atividades. De acordo com a tabela temos as seguintes dependências: a atividade #1 não
dependente de nenhuma atividade; o início da atividade #2 depende do término da atividade
#1, isto é, a atividade #2 não pode ser iniciada antes do fim da atividade #1; o início da ati-
vidade #3 depende do término da atividade #2; o início da atividade #4 depende somente
do fim da atividade #1, isto é, a atividade #4 pode ser iniciada junto com a atividade #2 (é
estranho testar um software antes de instalá-lo, mas relevemos isso); o início da atividade #5
depende do fim da atividade #4; o início da atividade #6 depende do fim da atividade #5; e
o início da atividade #7 depende do fim da atividade #3 e #6, isto é, a atividade #7 só pode
iniciar após o fim da atividade #6. Conforme as dependências existentes e a duração de cada
atividade, a alocação delas no cronograma é mostrada na Figura 6. Conforme a alocação das
atividades do cronograma apresentadas na Figura 6, a duração total do projeto é de 138 dias.
Schedule Performance Index
Os valores de VP, VA e CR são usados em conjunto para fornecer medidas de desempe-
nho que indicam se o trabalho está sendo realizado conforme planejado em algum momento
determinado. A técnica do valor agregado envolve o desenvolvimento destes valores-chave
para cada atividade do cronograma ou pacote de trabalho. Esta técnica é empregada no
processo Controle de Custos da área de conhecimento Gerenciamento de Custos do projeto.
O Valor Planejado (VP) ou Planned Value (PV) é o montante financeiro que o projeto,
de acordo com o planejamento, deveria ter consumido até um dado ponto do cronograma.
O VP também é conhecido como Budgeted Cost for Work Scheduled (BCWS) ou Custo
orçado para trabalho planejado (COTR).
O Valor Agregado (VA) ou Earned Value (EV) é o valor do montante de trabalho que
foi efetivamente realizado até uma data específica. O VA também é conhecido como Budge-
ted Cost for Work Performed (BCWP) ou Custo orçado para trabalho realizado (COTA).
O Custo Real (CR) ou Actual Cost (AC) é o custo efetivo do trabalho realizado até o
Página 40 de 58
www.handbookdeti.com.br
Handbook de Questões de TI Comentadas para Concursos Volume questões de TI
momento. O Custo Real às vezes pode representar somente as horas de mão-de-obra direta,
somente os custos diretos ou todos os custos, inclusive custos indiretos. O CR também é co-
nhecido como Actual Cost of Work Performed (ACWP) ou Custo real do trabalho realizado
(CRTR).
Figura 6: cronograma do projeto.
Esses dois valores, a VC e o VP, podem ser convertidos em indicadores de eficiência para
refletir o desempenho de custos e de prazos de qualquer projeto: Índice de Desempenho de
Prazos (IDP) e Índice de desempenho de custos (IDC).
O Índice de Desempenho de Prazos (IDP) ou Schedule Performance Index (SPI) é uma
medida de eficiência do cronograma em um projeto. É a relação entre o valor agregado (VA)