TCC 008

Faculdade de Tecnologia da Zona Leste
RAFAEL NISE PEREIRA
Melhores práticas para gerenciamento

do escopo de projetos baseado no
PMBOK
SÃO PAULO
2010
RAFAEL NISE PEREIRA
Monografia apresentada no curso

de Tecnologia em Informática
para Gestão de Negócios na
FATEC-ZL como exigência parcial
para obter o titulo de Tecnólogo
em Informática para Gestão de
Negócios.
Orientador: Prof. Mestre Joilson

de Souza Cardoso
SÃO PAULO
2010
PEREIRA, Rafael Nise
Melhores práticas para gerenciamento do escopo de projetos baseado no PMBOK /
Rafael Nise Pereira – Faculdade de Tecnologia da Zona Leste, São Paulo, 2010
73 p.
Orientador: Me. Joilson de Souza Cardoso

Trabalho de Conclusão de Curso – Faculdade de Tecnologia da Zona Leste
1. Gerenciamento de projetos. 2. Gerenciamento do escopo de projetos. 3. PMBOK.

PEREIRA, Rafael Nise
Melhores práticas para gerenciamento do escopo de projetos

baseado no PMBOK
Monografia apresentada no curso de

Tecnologia em Informática para Gestão de
Negócios na FATEC-ZL como exigência
parcial para obter o titulo de Tecnólogo em
Informática para Gestão de Negócios.
Aprovado em:
Banca Examinadora
Prof. Me Joilson de Souza Cardoso Instituição: FATEC-ZL
Julgamento: ________________Assinatura: ______________
Prof. Me Antônio Rodrigues Carvalho Neto Instituição: FATEC-ZL
Julgamento: _________________Assinatura: ______________
Prof. Glauber Rocha Romão Instituição: SENAC
Julgamento: ________________Assinatura: ______________
São Paulo, 10 de dezembro de 2010.

Dedico este trabalho às pessoas que sempre
estiveram ao meu lado em cada momento de
dificuldade e me auxiliaram a superá-los. Aos
meus irmãos, minha futura esposa, Elide e a
minha mãe Valdenis pela relação de amor,
amizade, companheirismo que temos e que tem
um valor inestimável.
Agradecimentos
A Deus por sempre estar presente em minha vida em todos os instantes.

Aos meus familiares, por todo amor e apoio.
À minha futura esposa por ser uma fonte inspiração.
Ao professor Joilson Cardoso pelo auxilio na solução das minhas
dúvidas e apresentar idéias valiosas para concluir este trabalho.
À professora Célia pela dedicação em revisar este trabalho na busca de
erros e pelos conselhos.
A todos os amigos e professores que me auxiliaram no desenvolvimento
deste trabalho.
Sumário
1. Introdução .................................................................................................... 12
2. O que é um projeto?..................................................................................... 14
2.1. Diferenças de operações correntes e projetos ...................................... 15
2.2. Subprojetos, programas e portfólios ...................................................... 15
2.3. Partes envolvidas no projeto (Stakeholders) ......................................... 16
2.4. Ciclo de vida do projeto ......................................................................... 17
2.5. Evoluções do gerenciamento de projetos .............................................. 21
2.5.1. PMI.................................................................................................. 22
2.5.2. PMBOK ........................................................................................... 23
2.6. Conceito de gerenciamento de projetos ................................................ 24
2.6.1. Gerenciamento de integração do projeto ........................................ 25
2.6.2. Gerenciamento do escopo do projeto ............................................. 25
2.6.3. Gerenciamento de tempo do projeto ............................................... 26
2.6.4. Gerenciamento de custo do projeto ................................................ 26
2.6.5. Gerenciamento de qualidade do projeto ......................................... 26
2.6.6. Gerenciamento de recursos humanos do projeto ........................... 27
2.6.7. Gerenciamento das comunicações do projeto ................................ 27
2.6.8. Gerenciamento de risco do projeto ................................................. 27
2.6.9. Gerenciamento de aquisições do projeto ........................................ 28
3. Controle integrado de mudanças e inter-relação entre escopo, qualidade,
tempo e risco.................................................................................................... 28
4. Como gerenciar o escopo do projeto ........................................................... 32
4.1. Coletar os requisitos .............................................................................. 32
4.1.1. Coleta de requisitos, entradas necessárias..................................... 33
4.1.2. Coleta de requisitos, ferramentas necessárias ............................... 34
4.1.3. Coleta de requisitos, saídas necessárias ........................................ 37
4.2. Definir o escopo..................................................................................... 39
4.2.1. Definir o escopo, entradas necessárias .......................................... 40
4.2.2. Definir o escopo, ferramentas necessárias ..................................... 41
4.2.3. Definir o escopo, saídas necessárias.............................................. 42
4.3. Criar a estrutura analítica do projeto (EAP ou WBS) ............................. 43
4.3.1. Criar a estrutura analítica do projeto, entradas necessárias ........... 44
4.3.2. Criar a estrutura analítica do projeto, ferramentas necessárias ...... 44
4.3.3. Criar a estrutura analítica do projeto, saídas necessárias............... 46
4.4. Verificar o escopo .................................................................................. 48
4.4.1. Verificar o escopo, entradas necessárias........................................ 49
4.4.2. Verificar o escopo, ferramentas necessárias .................................. 50
4.4.3. Verificar o escopo, saídas necessárias ........................................... 50
4.5. Controlar o escopo ................................................................................ 51
4.5.1. Controlar o escopo, entradas necessárias ...................................... 52
4.5.2. Controlar o escopo, ferramentas necessárias................................. 52
4.5.3. Controlar o escopo, saídas necessárias ......................................... 53
4.6.1. Vantagens do gerenciamento de escopo ........................................ 53
4.6.2. Principais causas de fracassos em projetos ................................... 54
5. Estudo de caso sobre o projeto do sistema de controle de palestras e
chamadas (SCPC) ........................................................................................... 55
5.1. Características principais do estudo de caso......................................... 55
5.2. Modelo de ciclo de vida iterativo incremental ........................................ 55
5.3. EAP do projeto SCPC............................................................................ 56
5.4. Documentação do escopo do projeto e produto .................................... 58
5.5. Considerações sobre o estudo de caso................................................. 59
6. Considerações finais .................................................................................... 61
Referências bibliográficas ................................................................................ 62
Anexos ............................................................................................................. 63
Anexo A. Documento de visão...................................................................... 63
Anexo B. Documento de caso de uso........................................................... 69
Anexo C. Diagramas de classe..................................................................... 70
Anexo D. Sugestão de continuidade deste trabalho diferença entre RUP e
PMBOK......................................................................................................... 72
Anexo E. Autorização de uso deste trabalho ................................................ 73
.
Lista de figuras
Figura 1. As áreas de abrangência de portfólios, programas, projetos e

subprojetos.......................................................................................................16
Figura 2. Possíveis partes envolvidas no projeto .............................................17
Figura 3. O ciclo de vida de um projeto subdividido em fases características..19
Figura 4. Exemplo do inter-relacionamento das fases de um projeto ou grupo
de processos .....................................................................................................21
Figura 5. As áreas de conhecimento do Gerenciamento de Projetos...............25
Figura 6. Visão geral dos processos de gerenciamento de projetos PMBOK 4
2008...................................................................................................................29
Figura 7. Relacionamento entre os fatores de qualidade, tempo, custo............30
Figura 8. Projetos com restrições de tempo..................................................... 31
Figura 9. Tempo X Custo relação mais importante.......................................... 31
Figura 10. Processos de Gerenciamento de Projetos distribuídos ao longo das
fases do projeto................................................................................................ 32
Figura 11. Mapa mental do processo de coletar requisitos...............................34
Figura 12. Mapa mental do processo de definir escopo.................................. .40
Figura 13. Mapa mental do processo de criar a EAP...................................... .43
Figura 14. Exemplo de EAP dividido por fases................................................. 45
Figura 15. Exemplo de EAP com primeiras entregas como primeiro nível de
decomposição.................................................................................................. 46
Figura 16. Mapa mental do processo de verificar o escopo............................ 49
Figura 17. Mapa mental do processo de controlar o escopo........................... 51
Figura 18. EAP do projeto SCPC..................................................................... 57
Figura 19. Fase de iniciação do projeto SCPC com seus processos divididos
em pacotes de trabalho necessário para conclusão do projeto....................... 57
Figura 20. Fase de elaboração do projeto SCPC com seus processos divididos
em atividades necessárias para conclusão do projeto.....................................58
Lista de siglas
PMI - Project Management Institute

PMBOK - Project Management Body of Knowledge
PMP - Project Management Professional
ISO - International Organization for Standardization
JAD - Joint Application Development
WBS - Work Breakdown Structure
PEREIRA, Rafael Nise. Melhores práticas para gerenciamento de escopo
de projetos baseado no PMBOK (Project Management Body of
Knowledge). 73 f. – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.
Resumo
O gerenciamento de escopo de projetos é essencial para as

organizações, que atuam num mercado a cada dia mais competitivo, com
recursos muitas vezes limitados e clientes mais exigentes, precisa de
processos que facilitem identificação das reais necessidades dos clientes e da
definição de atividades necessárias para realizar estes projetos com sucesso,
pois oportunidades de negócios que surgem a todo o momento são essências
para sobrevivências das empresas. O objetivo deste trabalho é conceituar as
melhores práticas de gerenciamento do escopo de projetos e os processos
necessários para desenvolver esta atividade. Em busca de responder a
seguinte pergunta, quais as principais causas de fracassos no processo de
gerenciamento do escopo do projeto e como é possível mitigá-los? Foram
levantadas as possíveis causas, falta de comunicação entre os envolvidos,
atrasos no cronograma, custos acima do orçamento, conflitos na equipe e com
os envolvidos, projetos com definições incompletas, ambiente instável,
retrabalhos para ajustar escopo. No estudo de caso deste trabalho foi realizada
uma análise entre os processos, ferramentas e documentos propostos pelo
PMBOK 4 para gerenciar o escopo de projetos e os que foram definidos como
necessários para desenvolver o projeto SCPC. A utilização dos conhecimentos
de gerenciamento de projeto proporciona resultados positivos, como a
definição de um canal único de comunicação entre os envolvidos e na
formalização de todas as informações, relevantes, estes documentos devem
constar de forma detalhada sem deixar nenhuma necessidade ou expectativa
como subentendida, incluindo cada solicitação de alteração e seu respectivo
impacto no projeto. Muitas mudanças devem ser adiadas para não
inviabilizarem a conclusão do projeto.
Palavras- chave: Gerenciamento de projetos; Gerenciamento do escopo de

projetos; PMBOK;
PEREIRA, Rafael Nise. Best practices for scope project management
based on the PMBOK (Project Management Body of Knowledge). 73 f. –
Faculdade de Tecnologia da Zona Leste, São Paulo, SP.
Abstract
Scope project management is critical for organizations that operate in a market

increasingly competitive, with often limited resources and more demanding
costumers, need processes that facilitate identification of customers' real needs
and definition of activities necessary to deliver these projects successfully, for
business opportunities that arise at any time are essential to business survival.
The objective of this work is to conceptualize best practices for scope project
management and processes required to develop this activity. In searching to
answer the following question, what are the main causes of process failures of
Scope Project management and how you can mitigate them? Were raised the
possible causes, lack of communication between those involved; Schedule
delays and costs over budget; Conflict in the team and with stakeholders;
Projects with incomplete definitions; Environment unstable; Rework scope to
adjust; This work has intention to analyze of the processes, tools and
documents proposed by PMBOK 4 to Scope Project manage and those
identified as necessary to develop the project SCPC. The use of knowledge of
the project management bringing positive results, as the definition of a single
channel of communication between those involved and the formalization of all
information, relevant, these documents must contain a detailed leaving no need
or expectation as implied, including every change request and its
corresponding impact on the project. Many changes must be postponed for not
foreclosing the project's completion.
Key words: Project Management, Project Scope Management, PMBOK;

12
1. Introdução
Toda a história da humanidade é repleta de grandes realizações, muitas

delas podem ser consideradas como projetos. É provável que os primeiros
projetos fossem voltados para solucionar problemas do dia a dia, como a
organizar uma caçada, implantar uma agricultura e desenvolver mecanismos
de segurança. Ainda que estes empreendimentos possam ser considerados
primitivos, também eram pressionados por prazos para atingir metas
predeterminadas. E durante toda a Antiguidade grandes construções foram
realizadas entre elas a grande muralha da China, as pirâmides do Egito e a dos
Maias, mesmo sem o auxilio de ferramentas, técnicas e metodologias
avançadas de que dispomos hoje, as pessoas criaram linhas de tempo,
alocaram materiais e recursos e avaliaram os riscos envolvidos em seus
projetos. (VALERIANO, 2001)
Atualmente, a globalização e os meios de comunicação têm diminuído

às barreiras geográficas, o que possibilita uma maior concorrência, várias
oportunidades de negócios, uma vez que, alcança um número maior de
mercados. Mas criou desafios a serem superados, ambientes em constantes
mudanças; pressões para acompanhar a velocidade do mercado; clientes
esclarecidos exigem cada vez mais produtos melhores e serviços mais rápidos;
Para atender a todas as expectativas as empresas estão descobrindo que
existem muitas vantagens na utilização do gerenciamento do projeto.
Objetivo deste trabalho é conceituar as melhores práticas de

gerenciamento do escopo de projetos e o processo necessário para
desenvolver está atividade. E como o gerenciamento do escopo de projetos
pode ajudar a controlar e monitorar os principais causadores de fracasso em
projetos.
Em busca de responder a seguinte pergunta, quais as principais causas

de fracassos no processo de gerenciamento do escopo do projeto e como é
possível mitigá-los?
13
Algumas hipóteses levantadas sobre as causas de fracasso no

gerenciamento do escopo do projeto:
A. Falta de comunicação entre os envolvidos;

B. Atrasos no cronograma;
C. Custos acima do orçamento;
D. Conflitos na equipe e com os envolvidos;
E. Projetos com definições incompletas;
F. Ambiente instável;
G. Retrabalhos para ajustar escopo.
Será utilizada a metodologia de pesquisa bibliográfica neste trabalho que

permite aumentar o conhecimento das melhores práticas descritas no PMBOK
4 versão 2008 sobre gerenciamento do escopo do projeto, e em livros, artigos,
revistas especializadas, publicações, sites relacionados ao assunto, estudo de
caso.
Este trabalho está organizado em cinco capítulos. Introdução; No capítulo

segundo são abordados os conceitos de projetos, formas de organização,
partes envolvidas no projeto, ciclo de vida do projeto, evoluções do
gerenciamento de projetos, PMI, PMBOK, conceito de gerenciamento de
projetos e áreas de conhecimento. No capítulo terceiro descreve a inter-relação
as principais causas de mudanças em projetos, o porquê da necessidade do
controle de mudanças. No capítulo quarto a definição de escopo, processos
necessários para gerenciar o escopo do projeto (coletar requisitos, definir
escopo, criar a EAP ou WBS, verificar escopo e controlar escopo). No quinto
capitulo encontra-se o estudo de caso sobre o projeto do sistema de controle
de palestras e chamadas (SPCP).
14
2. O que é um projeto?
Segundo o (PMBOK 2008, p.5) Projeto é um esforço temporário

empreendido para criar um produto, serviço ou resultado único.
De acordo com a definição apresentada na norma NBR ISO 10.006, que

trata das diretrizes para qualidade no gerenciamento de projetos, projeto é um
processo único, consistente com conjunto coordenado e controlado de
atividades com data de início e término, conduzida para atingir um objetivo com
requisitos especificados, incluindo restrições de tempo, custo e recursos.
Com base nos conceitos mencionados acima, um projeto é um esforço

temporário e não-repetitivo empreendido para alcançar um objetivo específico,
com limitações de recursos, prazos e devem ser planejados, executados e
controlados.
Temporário significa que todo projeto tem um início e um término bem

definidos, ao indicando curta duração de tempo, pois muitos projetos podem
duram anos. Um projeto é finalizado quando seus objetivos são alcançados ou
quando é evidente que não serão ou poderão ser atingidos por não cumprir um
dos acordos contratuais (prazos, custos e especificações) ou desinteresse dos
apoiadores do projeto (gerentes e empresa contratante do projeto). Não
repetitivo significa que o produto ou serviço é de algum modo, diferente de
todos os produtos e serviços semelhantes.
O termo temporário não se aplica ao serviço ou produto gerado pelo

projeto, pois muitos projetos têm resultados duradouros, a construção de um
monumento poderá durar séculos.
15
2.1. Diferenças de operações correntes e projetos
Segundo (VALERIANO, 2001), operações correntes são seqüências de

processos repetidamente executados, geralmente são distribuídos por órgãos
incumbidos da execução de tarefas especializadas, sob a denominação
genérica de departamentos. As equipes dos departamentos geralmente
pertencem a uma mesma especialidade profissional: marketing, contabilidade,
engenharia (com suas especializações), produção (obras, eletricidade,
mecânica, software), vendas, manutenção etc. O projeto, por ser temporário, é
executado por uma organização por uma organização transitória e tem inicio e
fins predeterminados. Em geral, e ao contrário das equipes funcionais,
especializadas e permanentes, as equipes de projeto congregam profissionais
de diversas especializações, formando equipes multifuncionais ou
multidepartamentais. A finalidade dos projetos é criar algo que ainda não
existe, seja produto ou serviço, enquanto que operação produz repetidamente
um dado produto ou presta um serviço. A operação é conseqüência do projeto
em outras palavras os projetos dão origem a uma nova operação, novo produto
ou ocorrem para significativos melhoramentos naqueles já existentes.
2.2. Subprojetos, programas e portfólios
Quando um projeto precisa ser dividido em várias partes de fácil

gerenciamento e controle, chamamos de subprojetos. Os subprojetos, são
responsáveis por partes do projeto ou fases extremante especificas, podem ser
desenvolvidos por um grupo especifico ou terceirizados.
O termo programa e utilizado para identificar um conjunto de projetos

relacionados entre si que, coordenados e gerenciados de forma integrada. O
interesse de organizar projetos em programas é tático, pois a vários benefícios
16
de controle que não seriam obtidos se eles fossem gerenciados de forma

individual.
Portfólios (carteira de projetos) são a organização de um grupo de

projetos, programas, subprojetos e outros trabalhos agrupados para facilitar o
gerenciamento eficaz desse trabalho a fim de cumprir os objetivos estratégicos
do negócio conforme demonstra a figura 1 abaixo.
Figura 1 – As áreas de abrangência de portfólios, programas, projetos e subprojetos.

Fonte: (VARGAS, 2009, p. 8)
2.3. Partes envolvidas no projeto (Stakeholders)
Segundo (XAVIER e CHUERI, 2008), as pessoas, grupo de pessoas e

organizações que estão ativamente envolvidas no projeto, ou cujos interesses
possam ser afetados de forma positiva ou negativa, direta ou indiretamente
com resultado da execução ou conclusão do projeto, são chamadas de partes
interessadas ou envolvidas. As partes envolvidas podem exercer influência
sobre o projeto e seus resultados. A equipe de gerenciamento deve assim
17
identificar esses interessados, determinar suas necessidades então gerenciar e

influenciar tais necessidades, a fim de assegurar um projeto bem sucedido. As
possíveis partes envolvidas no projeto são descritos na figura 2.
Figura 2 - Possíveis partes envolvidas no projeto

Fonte: (XAVIER e CHUERI, 2008, p. 17)
2.4. Ciclo de vida do projeto
A organização ou os gerentes de projetos podem dividir projetos em

fases para oferecer melhor controle gerencial com ligações adequadas com as
18
operações em andamento da organização executora. Coletivamente, essas

fases são conhecidas como o ciclo de vida do projeto. Muitas organizações
identificam um conjunto específico de ciclos de vida para serem usados em
todos os seus projetos (PMBOK, 2008).
Segundo (VARGAS, 2009) cada fase do projeto é caracterizada pela

entrega, ou finalização, de um determinado trabalho. Toda entrega deve ser
tangível e de fácil identificação, como, por exemplo, um relatório
confeccionado, um cronograma estabelecido ou um conjunto de atividades
realizado.
As atividades necessárias para criação de um produto são exclusivas de

cada empresa e do produto que será criado. As atividades do desenvolvimento
de um software são bem diferentes das utilizadas para obtenção de produtos
farmacêuticos. Mas o mesmo ciclo de vida pode ser utilizado para organizar e
monitorar tanto o desenvolvimento de produtos farmacêuticos como de
softwares.
A quantidade de fases em projeto está relacionada à sua natureza.

Existem diversos modelos de ciclo de vida, desenvolvidos para fins específicos,
por diversas instituições, como o Departamento de Defesa dos Estados Unidos
(DOD), a Agência Espacial Americana (NASA), o Project Management Institute
(PMI), mas todas elas abrangem aproximadamente as mesmas quantidades de
atividades.
Na figura 3 podemos observar como o ciclo de vida de um projeto pode

ser dividido nas seguintes fases (iniciação, planejamento, execução,
monitoramento e controle, encerramento) de acordo com PMBOK 4:
19
Figura 3 - O ciclo de vida de um projeto subdividido em fases características.

Para (VARGAS, 2009) as principais características das fases do ciclo de

vida são as seguintes:
• Fase de iniciação, nesta fase as necessidades dos envolvidos são

identificadas e transformadas em problemas estruturados que devem
ser resolvidos pelo projeto. Também definimos nessa fase a missão
e o objetivo do projeto, a documentação inicial é produzida e as
melhores estratégias são identificadas e selecionadas.
• Fase de planejamento, nesta fase tudo que é necessário para

realização do projeto é detalhado, incluindo cronogramas,
interdependências entre atividades, alocação dos recursos
envolvidos, análise de custos etc., para que, no final dessa fase, ele
esteja suficientemente detalhado para ser executado sem dificuldade
e imprevistos. Nesta fase os planos de escopo, qualidade, tempo,
custo, recursos humanos, comunicação, riscos e aquisições são
desenvolvidos.
• Fase de execução, tudo que foi planejado anteriormente é colocado

em prática. Os erros cometidos nas outras fases ficam evidentes
20
nesta fase. Grande parte do orçamento e do esforço do projeto é

consumida nesta fase.
• Fase de monitoramento e controle acontece paralelamente ás

demais fases do projeto. Tem como objetivo controlar aquilo que está
sendo realizado pelo projeto, de modo a propor ações corretivas e
preventivas no menor espaço e de tempo possível após a detecção
da anormalidade. O objetivo do controle é comparar o status atual do
projeto com status previsto pelo planejamento, tomando ações
preventivas e corretivas em caso de desvio.
• Fase de encerramento é quando a execução dos trabalhos é

avaliada através de uma auditoria interna ou externa, os documentos
do projeto são encerrados e todas as falhas ocorridas durante o
projeto são discutidas durante o projeto e analisadas para que erros
similares não ocorram em novos projetos, por isso está fase é
conhecido como a fase de aprendizado.
Com o desenvolvimento do projeto, praticamente todas as fases são

realizadas quase que simultaneamente, constituindo um clico de vida conforme
a figura 4.
Figura 4. Exemplo do inter-relacionamento das fases de um projeto ou grupo de processos.

Fonte: (PMBOK 42, 2008, p. 19)
21
2.5. Evoluções do gerenciamento de projetos
Segundo (VALERIANO, 2001), a história da humanidade relata grandes

feitos podendo ser classificados como projetos. É muito provável, que os
projetos mais antigos deviam estar voltados para as necessidades mais
básicas, como o preparo e execução de uma campanha de caçada, instalação
de uma agricultura e criação de dispositivos e sistemas de segurança ou
defesa. Todos estes empreendimentos, ainda que primitivos, eram premidos
por prazos para alcançar objetivos preestabelecidos e tinham algum tipo de
organização e de administração. Durante a Antiguidade grandes construções
forma realizadas pirâmides do Egito e dos Maias, a grande muralha da China.
Mais atuais, citam-se canal do Panamá e de Suez, explorações submarinas e
espaciais.
Para (VARGAS, 2009), por mais tenhamos evoluído tecnicamente, nos

deparamos com ambiente que evolui muitas vezes mais, ou seja, hoje somos
muito mais capazes que no passado, porém, esse nosso aumento é cada vez
menor se comparado com o aumento na dinâmica do ambiente.
A evolução do gerenciamento de projetos pode ser dividida em três

períodos:
• Gerenciamento empírico, baseado nas qualidades inatas dos gerentes e

de seus auxiliares ou nos procedimentos precedentes, muito mais como
arte, do que como técnica. Foi o caso dos grandes construtores da
Antiguidade e Idade Média, os feitos dos grandes chefes militares ou
exploradores.
• Gerenciamento clássico ou tradicional, geralmente considerado aquele a

partir das décadas de 1949 ou 1950, com empreendimentos
predominantes de engenharia, nas áreas de defesa, na aeronáutica e
mais recentemente na espacial. Em geral, aqui os projetos são
22
essencialmente técnicos, de grande complexidade e caracterizados

pelos altos custos, pelo vulto dos problemas envolvidos e dos prazos
relativamente longos.
• Mais recentemente (inícios da década de 1990), teve o começo do

moderno gerenciamento de projetos. Voltado para uma ampla gama de
aplicações, esse tipo de abordagem gerencial perdeu o caráter
tipicamente técnico e vem sendo utilizado para todo tipo de problema
empresarial. É uma ferramenta extraordinária que permite as
organizações responderem com extrema rapidez as solicitações e
pressões dos ambientes próximos e remotos, devido principalmente ao
rápido ciclo de vida dos produtos, à velocidade da evolução tecnológica
é acirrada competição, já em caráter global.
2.5.1. PMI
O PMI (Project Management Institute) ou Instituto de Gerenciamento de

Projeto foi fundado em 1969, nos Estados Unidos, por cinco voluntários, com o
propósito de garantir o uso das melhores práticas, pois dentre as diversas
formas de se executar projetos nas mais variados segmentos, que após entre
as melhores praticas identificadas de gerenciamento de projetos, para ser
possível a aplicação não apenas em uma área de negócio especifica, para que
isso seja possível foi feito um extenso trabalho de catalogação em formato de
documentações descritivas das formas existentes na época, analisando os
resultados, as praticas que obtiveram melhores resultados passaram a ser
chamadas de melhores praticas.
Conforme (PMI-SP, 2010) o crescimento na quantidade de associados

foi criado um Código de Conduta Profissional (Code of Professional Conduct)
para os profissionais de gerenciamento de projetos e o primeiro certificado, o
PMP em 1984, sendo reconhecido pela ISO 9001 em 1999, para receber o
23
certificado é necessário preencher uma série de requisitos entre eles a

comprovação de experiência, aceite do Código de Conduta Profissional e
aprovação no Exame de Certificação PMP. A PMP certifica os profissionais
coordenadores de múltiplos projetos, para assegurar sucesso sendo
reconhecidos para tomada de decisão e traçar objetivos estratégicos. Essa
certificação se destaca pelos requisitos bem superiores as outras certificações
e pela forma diferenciada no processo de certificação, divido em três etapas
nas quais o candidato é avaliado em diversas competências, a quantidade de
experiência comprovada também é superior.
2.5.2. PMBOK
Segundo (PMI-SP, 2010) o PMBOK (Project Management Body of

Knowledge) é o guia que identifica o subconjunto do conjunto de
conhecimentos em gerenciamento de projetos, reconhecido como boa prática.
A boa prática é identificada pelo acordo geral de sua aplicação correta das
habilidades, ferramentas e técnicas para aumentam das chances de sucessos
do projeto, porém, as necessidades dos projetos são especificas, nem todas as
boas práticas precisam obrigatoriamente aplicadas, a equipe de gerenciamento
de projetos determina o que é adequado ao projeto. A primeira edição do
PKBOK foi publicada 1996, a segunda em 2000, a terceira em 2004 e a quarta
em 2008. O PMBOK é a maior e mais importante publicação do instituto PMI,
proveniente do resultado do esforço de diversas fontes, incluindo voluntários,
em pesquisas, revisões e aprimoramentos das melhores praticas no
gerenciamento de projetos.
24
2.6. Conceito de gerenciamento de projetos
Para o (PMBOK 4, 2008) o gerenciamento de projetos é a aplicação de

conhecimentos, habilidades e técnicas para projetar atividades que visem atingir
ou exceder as necessidades e expectativas das partes envolvidas com relação ao
projeto. Com intuito de satisfazer as necessidades e expectativas das partes
envolvidas o gerente de projetos deve encontrar o equilíbrio entre as atividades
inerentes ao projeto.
Segundo (KERZNER, 2004) uma gestão bem sucedida de projetos exige

planejamento e coordenação extensivos. Assim, o fluxo de trabalho e a
coordenação do projeto devem ser administrados horizontalmente, não mais
verticalmente como ocorria na gerencia tradicional. O fluxo de trabalho
horizontal de trabalho acarreta em produtividade, eficiência e eficácia. As
empresas que conseguiram se especializar em fluxo horizontal de trabalho é,
geralmente, mais lucrativo que aquelas que continuam a utilizar exclusivamente
o fluxo vertical.
Para o (PMBOK 4, 2008) organiza as áreas de conhecimento em

gerenciamento de projetos em quarenta e dois processos e que foram
agrupados em nove áreas de conhecimento: Integração, Escopo, Tempo,
Custo, Qualidade, Recursos Humanos, Comunicações, Riscos e Aquisições. A
coordenação destas áreas e responsabilidades da Integração conforme a figura
5.
25
Figura 5. As áreas de conhecimento do Gerenciamento de Projetos

Fonte: (XAVIER e CHUERI, 2008, p. 6)
2.6.1. Gerenciamento de integração do projeto
Descreve os processos e as atividades que integram os diversos

elementos do gerenciamento de projetos, que são identificados, definidos,
combinados, unificados e coordenados dentro dos grupos de processos de
gerenciamento de projetos. Ele consiste nos processos de gerenciamento de
projetos: Desenvolver o termo de abertura do projeto, desenvolver o plano de
gerenciamento do projeto, orientar e gerenciar a execução do projeto,
monitorar e controlar o trabalho do projeto, realizar o controle integrado de
mudanças e encerrar o projeto ou fase. (PMBOK 4, 2008)
2.6.2. Gerenciamento do escopo do projeto
Descreve os processos envolvidos na verificação de que o projeto inclui

todo o trabalho necessário, e apenas o trabalho necessário, para que seja
26
concluído com sucesso. Ele consiste nos processos de gerenciamento de

projetos: Coletar os requisitos, definição do escopo, criar EAP ou WBS,
Verificação do escopo e Controle do escopo. (PMBOK 4, 2008)
2.6.3. Gerenciamento de tempo do projeto
Descreve os processos relativos ao término do projeto no prazo correto.

Ele consiste nos processos de gerenciamento de projetos: Definir as
atividades, seqüenciar as atividades, estimativa de recursos das atividades,
estimativa de duração da atividade e desenvolver o cronograma. (PMBOK 4,
2008)
2.6.4. Gerenciamento de custo do projeto
Descreve os processos envolvidos em planejamento, estimativa,

orçamento e controle de custos, de modo que o projeto termine dentro do
orçamento aprovado. Ele consiste nos processos de gerenciamento de
projetos: Estimar os custos, determinar o orçamento e controlar os custos.
(PMBOK 4, 2008)
2.6.5. Gerenciamento de qualidade do projeto
Descreve os processos envolvidos na garantia de que o projeto irá

satisfazer os objetivos para os quais foi realizado. Ele consiste nos processos
de gerenciamento de projetos: Planejamento da qualidade, realizar a garantia
da qualidade e realizar o controle da qualidade. (PMBOK 4, 2008)
27
2.6.6. Gerenciamento de recursos humanos do projeto
Descreve os processos que organizam e gerenciam a equipe do projeto.

Ele consiste nos processos de gerenciamento de projetos: Desenvolver plano
de recursos humanos, mobilize a equipe do projeto, desenvolver a equipe do
projeto e gerenciar a equipe do projeto. (PMBOK 4, 2008)
2.6.7. Gerenciamento das comunicações do projeto
Descrevem os processos relativos à geração, coleta, disseminação,

armazenamento e destinação final das informações do projeto de forma
oportuna e adequada. Ele consiste nos processos de gerenciamento de
projetos: Identificar partes interessadas, planejar as comunicações, distribuição
das informações, gerencie as expectativas das partes interessadas e reportar
desempenho. (PMBOK 4, 2008)
2.6.8. Gerenciamento de risco do projeto
Descreve os processos relativos à realização do gerenciamento de

riscos em um projeto. Ele consiste nos processos de gerenciamento de
projetos: Planejamento do gerenciamento de riscos, Identificação de riscos,
realizar a análise qualitativa de riscos, realize a análise quantitativa de riscos,
planejar de respostas a riscos e monitor e controlar os riscos. (PMBOK 4, 2008)
28
2.6.9. Gerenciamento de aquisições do projeto
Descreve os processos que compram ou adquirem produtos, serviços ou

resultados, além dos processos de gerenciamento de contratos. Ele consiste
nos processos de gerenciamento de projetos: Planejar as aquisições, conduzir
as aquisições, administrar as aquisições, e encerrar as aquisições. (PMBOK 4,
2008)
3. Controle integrado de mudanças e inter-relação

entre escopo, qualidade, tempo e risco
Segundo o (PMBOK 4, 2008), mudanças são realizadas desde o início

do projeto até o seu término. O controle de mudanças é necessário porque
raramente a execução dos projetos segue com exatidão o plano de
gerenciamento do projeto. O plano de gerenciamento do projeto, a declaração
do escopo do projeto e outras entregas precisam ser mantidas através do
gerenciamento contínuo e cuidadoso das mudanças, rejeitando ou aprovando
essas mudanças, de forma que as mudanças aprovadas sejam incorporadas a
uma linha de base revisada. As mudanças propostas podem exigir estimativas
de custos, seqüências de atividades do cronograma, datas do cronograma,
recursos necessários e análise de alternativas de respostas a riscos, novas ou
revisadas. Essas mudanças podem exigir ajustes no plano de gerenciamento
do projeto, na declaração do escopo do projeto ou em outras entregas do
projeto. O nível aplicado de controle de mudanças depende da área de
aplicação, da complexidade do projeto específico, dos requisitos de contratos e
do contexto e ambiente em que o projeto é realizado.
29
A figura 6 demonstra os processos do PMBOK 4 2008 e suas

respectivas fases do ciclo de vida dos projetos.
Figura 6. Visão geral dos processos de gerenciamento de projetos PMBOK 4 2008.

Fonte: (SOTILLE, 2010, s/p)
O escopo do projeto pode ser afetado por três fatores básicos que
devem ser controlados e gerenciados para garantir que o projeto atinja seus
objetivos, a figura 7 é um modelo proposto por Kerzner (2002) que evidências
estes fatores.
30
Figura 7. Relacionamento entre os fatores de qualidade, tempo, custo.

Fonte: (BRUZZI, 2008, p. 16)
Para (BRUZZI, 2008), todo projeto precisa inter-relacionar fatores

relativos à qualidade, custo e tempo. É extremamente relevante determinar a
variável predominante no projeto. O escopo do projeto define o que será ou
não atendido e determina os limites. É interessante trabalhar com estas
variáveis dando peso e importância a cada uma delas.
Um projeto com prazo reduzido pode prejudicar a qualidade e aumentar

o custo. Ao ser trabalhar com projetos prematuros pode-se comprometer a
qualidade do processo e ao mesmo tempo o custo ao ser trabalhar dobrado,
mas com compras urgentes sem uma pesquisa prévia, compras fora de
estação ou com produtos em alta, quebra de regras legais, conforme a figura 8.
31
Figura 8. Projetos com restrições de tempo.

Quando um projeto precisa de mais tempo para ser executado do que o

combinado, acontece a relação mais importante (tempo x custo). Com prejuízo
direto a variável qualidade. Um projeto que tem seu tempo aumentado pode
trazer aumento de custo com mais horas trabalhadas e não ter mais qualidade
em sua execução, conforme a figura 9.
Figura 9. Tempo X Custo relação mais importante.

32
4. Como gerenciar o escopo do projeto
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. O gerenciamento do escopo do projeto
trata principalmente da definição e controle do que está e do que não está
incluído no projeto. Na figura 10, podem ser observados os processos de
gerenciamento de escopo nas suas respectivas fases.
Figura 10. Processos de Gerenciamento de Projetos distribuídos ao longo das fases do projeto.
4.1. Coletar os requisitos
Segundo o (PMBOK4, 2008) o processo de definir e documentar as

funções e funcionalidades do projeto e do produto necessários para atender às
necessidades e expectativas do patrocinador, cliente e outras partes
33
interessadas. O sucesso do projeto está diretamente influenciado pelo cuidado

na correta captura e gerenciamento dos requisitos do produto. Esses requisitos
precisam ser levantados, analisados e registrados em detalhe suficiente para
serem medidos durante a execução do projeto. Os requisitos são a base do
EAP( estrutura analitica do projeto). Custo, cronograma e planejamento da
qualidade são todos planejados com base nos requisitos. O desenvolvimento
do escopo do projeto começa com e análise das informações contidas no termo
de abertura do projeto.
A figura 11 , demonstra os documentos necessários para iniciar o

processo de coletar os requisitos , ferramentas que podem ser utilizadas na
extração dos requisitos e documentos gerados no final do processo.
Figura 11. Mapa mental do processo de coletar requisitos.

4.1.1. Coleta de requisitos, entradas necessárias
Para (PMBOK4, 2008) o termo de abertura do projeto é um documento

que autoriza formalmente um projeto ou uma fase inicial. Serve de linha base
34
para o trabalho do gerente do projeto. Contém uma descrição de ato nível dos
requisitos do projeto e produto que atenda as necessidades e expectativas das
partes interessadas, também possui estimativas iniciais de qual o prazo
destinado, recursos necessários e orçamento disponível. Usualmente o termo
de abertura do projeto contém:
• Título do projeto;
• Um resumo das condições que definem o projeto;
• Justificativa do projeto;
• Nome do gerente de projeto, suas responsabilidades e
autoridades;
• Necessidades básicas do trabalho a ser realizado;
• Principais partes interessadas;
• Descrição produto do projeto;
• Cronograma básico do projeto;
• Necessidades iniciais de recursos;
• Necessidades de suporte pela organização;
• Premissas e restrições;
• Controle e gerenciamento das informações do projeto;
• Aprovações com assinatura do executivo responsável pelo
documento (elemento externo ao projeto);
4.1.2. Coleta de requisitos, ferramentas necessárias
Entrevista é uma abordagem formal ou informal para descobrir

informações das partes interessadas, geralmente é realizado por meio de
perguntas preparadas ou espontâneas e anotação ou gravação das respostas.
As entrevistas são freqüentemente um entrevistador e um entrevistado, mas há
casos um entrevistador e vários entrevistados e vários entrevistadores e vários
entrevistados.
35
Dinâmica de grupo reuniu os interessados pré-qualificados e

especialistas no assunto para aprender sobre suas atitudes e expectativas
sobre um produto proposto, serviço ou resultado. O moderador guia o grupo
formado através de um debate interativo, criado para ser mais do que uma
conversa cara-a-cara.
Oficinas são focadas no encontro das principais partes interessadas das

diversas áreas envolvidas no projeto, para em conjunto definir os requisitos do
produto. Oficinas são consideradas técnicas básicas para definição de
requisitos inter funcionais e conciliar as partes interessadas. Devido a sua
natureza de interação em grupo promove relacionamento e melhora a
comunicação das partes interessadas. Outra vantagem desta técnica é que as
questões podem ser descobertas e resolvidas mais rapidamente do que em
entrevista individuais. Um exemplo de um método de oficina é o JAD (Joint
Application Development) que é usado na indústria de desenvolvimento de
software. Estas sessões facilitadas foco no usuário e trazer a equipe de
desenvolvimento em conjunto para melhorar o processo de desenvolvimento
de software.
Técnicas de criatividade em grupo, diversas atividades em grupo podem

ser organizadas para identificar os requisitos do projeto e do produto. Algumas
das técnicas de grupo criatividade que podem ser utilizados são:
• Brainstorming. A técnica usada para gerar e coletar idéias múltiplas

relacionadas ao projeto e requisitos do produto. Neste processo deve-se evitar
a censura pessoal as idéias geradas na devem ser avaliadas.
• Técnica de grupo nominal. Esta técnica aumenta a reflexão com um
processo de votação utilizado para classificar as idéias mais úteis para o
prosseguimento de brainstorming ou de priorização. Cada membro do grupo do
grupo é encorajado a melhorar as idéias apresentadas.
• Mapa mental, idéias criadas através brainstorming individual são
consolidados em um único mapa para refletir em comum e diferenças na
compreensão e gerar novas idéias.
36
• Diagrama de Afinidade, esta técnica permite um grande número de

idéias a serem classificados em grupos para revisão e análise.
Técnicas de tomada de decisão em grupo podem ser aplicadas com

Delphi que é um método de tomada de decisão em grupo que se caracteriza
pelo fato de cada membro do grupo apresentar as suas idéias, mas nunca face
a face com os restantes elementos. Cada elemento é assim isolado da
influência dos restantes. Como não ocorre a presença física dos participantes
numa reunião, este método pode ser usado quando os elementos do grupo se
encontram distantes geograficamente. Apresenta, contudo, alguns
inconvenientes, entre os quais o maior consumo de tempo na tomada de uma
decisão e a perda dos benefícios associados ao intercâmbio pessoal de idéias
proporcionado por outros métodos. Características das atividades do método
Dephi:
• Identificação do problema, construção do questionário e apresentação

do mesmo cada um dos elementos do grupo;
• Resposta ao questionário de forma anônima e independente por cada
um dos elementos do grupo;
• Compilação das respostas e sua distribuição pelos membros do grupo
acompanhado do questionário revisto;
• Resposta ao novo questionário da mesma forma descrita na fase 2, isto
é, de forma anônima e independente;
• Repetição das terceira e quarta fases até se atingir uma solução de
consenso.
Questionários e pesquisas são conjuntos de questões destinadas a

acumular rapidamente informações de um número grande de entrevistados.
Questionários e / ou pesquisas são mais apropriados para grandes populações,
quando forma de obtenção dos dados é rápida e onde a análise estatística é
adequada.
37
Observações fornecem uma maneira direta de ver as pessoas em seu

ambiente e como eles realizam seus trabalhos ou tarefas e execução de
processos. É particularmente útil para os processos de execução quando as
pessoas que usam o produto têm dificuldade ou estão relutantes em articular
as suas necessidades. A observação, também chamado de "posto de
trabalho", geralmente é feito externamente pelo observador visualizando o
usuário que executa o trabalho dele ou dela. Também pode ser feito por um
"observador participante", que realmente executa um processo ou
procedimento para experimentar como é feito para descobrir necessidades
ocultas.
Protótipos é um método de obtenção de uma opinião inicial sobre os

requisitos, fornecendo um modelo de funcionamento do produto esperado
antes de realmente construir. Uma vez que os protótipos são tangíveis, que
permite aos interessados a experimentar com um modelo do seu produto final
em vez de apenas discutir representações abstratas das suas necessidades.
4.1.3. Coleta de requisitos, saídas necessárias
Para (VARGAS, 2009) o documento dos requisitos do projeto registra os

requisitos necessários para atender as necessidades do projeto. Os requisitos
podem começar em um nível alto e tornar-se progressivamente mais detalhado
conforme o projeto é desenvolvido. Antes da linha de base, os requisitos
devem ser inequívocas (mensuráveis e verificáveis), rastreável, completa,
consistente e aceitável para os principais interessados. O formato de um
documento de requisitos podem variar de um simples documento listando todos
os requisitos discriminados por partes interessadas e prioridade, para formas
mais elaboradas contendo resumo executivo, descrições detalhadas, e anexos.
Normalmente o documento contém:
• Titulo do projeto;
38
• Nome da pessoa que elaborou o documento;

• Descrição básica do projeto e da oportunidade;
• Objetivo do projeto;
• Requisitos funcionais desejáveis (priorizados);
• Requisitos não funcionais (relacionados ao desempenho,
segurança, confidencialidade etc.);
• Requerimentos principais de qualidade;
• Potenciais impactos do projeto em outras áreas;
• Critérios de aceitação do projeto;
• Potenciais impactos do projeto em outras áreas;
• Restrições consideradas na criação dos requerimentos;
• Premissas consideradas na criação dos requerimentos;
• Registro de alterações no documento de requisitos;
• Aprovações;
Segundo (VARGAS, 2009) o plano de gerenciamento de requisitos do

projeto é auxiliar ao plano de gerenciamento de projetos e descreve os
procedimentos que serão utilizados para documentar como os requerimentos
serão analisados, documentados e gerenciados através do projeto. No plano
de gerenciamento dos requisitos deve estar documentado:
• Critério de priorização dos requisitos;
• Critério de rastreabilidade dos requisitos;
• Sistema de controle de mudanças nos requisitos;
• Níveis de aprovação de mudanças nos requisitos;
• Outros assuntos relacionados ao gerenciamento de requisitos do
projeto não previstos no plano de gerenciamento dos requisitos;
• Registro de alterações no documento;
• Aprovações;
Matriz de rastreabilidade de requisitos é um documento em forma de

tabela que lista os requisitos do projeto de modo a permitir o rastreamento do
39
requisito dentro da EAP do projeto, determina seu status, teste e requisitos

relacionados. Tem como objetivo garantir que cada requerimento adicione valor
ao objetivo do projeto e esteja perfeitamente ligado ao escopo de atividades.
Este documento contém os seguintes campos:
• ID do requisito;
• Nome do requisito;
• Descrição do requisito;
• Tipo do requisito;
• Prioridade do requisito
• Elemento(s) da EAP onde o requisito está associado;
• Outros requisitos associados e relacionados (ID);
• Status do requisito;
• Critério de aceitação e conclusão;
• Comentários;
4.2. Definir o escopo
Para (PMBOK 4, 2008) definir o escopo é o processo de

desenvolvimento de uma descrição detalhada do projeto e do produto. A
preparação detalhada da declaração do escopo é crítica para o sucesso e
baseiam-se nas principais entregas, premissas e restrições que são
documentas durante a iniciação do projeto. Durante o planejamento, o escopo
do projeto é definido e descrito com maior especificidade à medida que mais
informações sobre o projeto são identificadas. Riscos existentes, premissas e
restrições são analisadas para a sua conclusão; riscos adicionais, suposições e
restrições são acrescentados conforme necessário. Figura 12 mostra as
entradas, ferramentas e técnicas, e saídas para a definição de escopo
processo.
40
Figura 12. Mapa mental do processo de definir escopo.

4.2.1. Definir o escopo, entradas necessárias
Termo de abertura do projeto descrição no capítulo 4.1.1 Coleta de

requisitos, entradas necessárias.
Documentação dos requisitos descrição no capítulo 4.1.3 Coleta de

requisitos, saídas necessárias.
Ativos de processos organizacionais que podem influenciar o processo

de definir o escopo incluem, mas não estão limitados a:
• Políticas, procedimentos e modelos para a declaração do escopo do

projeto;
• Arquivos de projetos anteriores;
• As lições aprendidas com as fases anteriores ou projetos;
41
4.2.2. Definir o escopo, ferramentas necessárias
Opinião especializada é freqüentemente usada para analisar as

informações necessárias para desenvolver a declaração do escopo do projeto.
Essa sentença e conhecimentos serão aplicados para todos os detalhes
técnicos. Tal habilidade é fornecida por qualquer grupo ou indivíduo com
conhecimento ou treinamento especializado e está disponível a partir de muitas
fontes, incluindo:
• Departamentos dentro da organização;

• Consultores;
• Partes interessadas, inclusive clientes ou patrocinadores;
• Profissionais e técnicos de associações;
• Grupos da Indústria;
• Especialistas no assunto;
Análise de produto para os projetos que têm como objetivo desenvolver

um produto, ao contrário de um serviço ou resultado, a análise do produto pode
ser uma ferramenta eficaz. Cada área de aplicação possui um ou mais
métodos geralmente aceitos para traduzir as descrições dos produtos de alto
nível em características mais detalhadas. A análise do produto inclui técnicas
como a repartição do produto, análise de sistemas, análise de requisitos,
engenharia de sistemas, engenharia de valor e análise de valor.
Identificação de alternativas é uma técnica usada para gerar diferentes

abordagens para executar e realizar o trabalho do projeto. Uma variedade de
técnicas de manejo geral pode ser utilizada, tais como brainstorming,
pensamento laterais, par de comparações múltiplas, etc.
Oficinas descrição no capítulo 4.1.2 coleta de requisitos, ferramentas

necessárias.
42
4.2.3. Definir o escopo, saídas necessárias
Para (VARGAS, 2009) a declaração do escopo do projeto é o

documento que formaliza o escopo de todos os trabalhos a serem
desenvolvidos no projeto, servindo de base para futuras decisões do projeto. É
possível que, ao longo do projeto, a declaração de escopo seja revisada, ou
refinada, para refletir as mudanças acontecidas nele. Normalmente a
declaração do escopo contém:
• Nome do patricionador;
• Nome do gerente do projeto e suas resposabilidades e
autoridades;
• Nome dos integrantes do time do projeto;
• Descrição do projeto;
• Objetivo do projeto;
• Expectativas do cliente/patrocinador;
• Fatores de sucesso do projeto;
• Restrições;
• Premissas;
• Exclusões especificas (tudo que não será abordado pelo projeto);
• Principais atividades e estratégias do projeto;
• Principais entregas do projeto;
• Orçamento básico do projeto;
• Plano de entrega e marcos do projeto;
• Registro de alterações no documento;
• Aprovações;
Atualização dos documentos do projeto que pode incluir, mas não estão
limitados a:
43
• Registros das partes interessadas;

• Requisitos de documentação;
• Requisitos da matriz de rastreabilidade.
4.3. Criar a estrutura analítica do projeto (EAP ou WBS)
Conforme (PMBOK 4, 2008) a EAP é o processo de subdivisão das

principais entregas do projeto e do trabalho do desenvolvimento do produto em
partes menores e mais gerenciáveis. A estrutura do EAP é decomposta
hierarquicamente orientada a determinar as atividades necessárias a serem
executadas pela equipe do projeto para realizar os objetivos do projeto, sendo
que cada nível descendente da EAP representa uma definição cada vez mais
detalhada do projeto. A EAP organiza e define o escopo total do projeto, e
representa o trabalho especificado na declaração do escopo aprovado do
projeto atual. Figura 13 mostra as entradas, ferramentas e técnicas, e saídas
para a criar a estrutura analitica do projeto.
Figura 13. Mapa mental do processo de criar a EAP.

44
4.3.1. Criar a estrutura analítica do projeto, entradas

necessárias
Declaração do escopo do projeto, descrição no capítulo 4.2.3 Definir o

escopo, saídas necessárias.
Documentação dos requisitos escopo do projeto, descrição no capítulo

4.1.3 Coleta de requisitos, saídas necessárias.
Ativos de processos organizacionais, descrição no capítulo 4.2.1 Definir

o escopo, entradas necessárias.
4.3.2. Criar a estrutura analítica do projeto, ferramentas

necessárias
Decomposição é a subdivisão das entregas do projeto em componentes

menores e mais gerenciáveis, estes componentes são definidos até o nível de
pacote de trabalho. O nível de pacote de trabalho é o nível mais baixo na EAP
é o ponto em que a duração e custo das atividades para o trabalho pode ser
estimados e gerenciados de formar mais confiável. O nível de detalhe dos
pacotes de trabalho irá variar de acordo com o tamanho e a complexidade do
projeto. Um pacote de trabalho pode ser repartido em atividades menores.
A decomposição do trabalho total do projeto em pacotes de trabalho

geralmente envolve as seguintes atividades:
• Identificar e analisar as atividades e trabalhos relacionados;

• Estruturação e organização da EAP;
45
• Decompondo os níveis superiores da EAP em componentes

detalhados de nível inferior;
• Desenvolver e atribuição de códigos de identificação para os
componentes da EAP;
• Verificação de que o grau de decomposição do trabalho é necessário e
suficiente;
A estrutura WBS pode ser criado em diversas formas, tais como:
• Usar as fases do ciclo de vida do projeto como o primeiro nível de

decomposição, com as entregas do produto e do projeto inserido no segundo
nível, como mostrado na figura 14;
Figura 14. Exemplo de EAP dividido por fases.

Fonte: (PMBOK 4, 2008, p. 119)
• Utilizar principais entregas como o primeiro nível de decomposição,

conforme mostrado na figura 15;
46
Figura 15. Exemplo de EAP com primeiras entregas como primeiro nível de decomposição.
Fonte: (PMBOK 4, 2008, p. 120)
• Usar os subprojetos que podem ser desenvolvidos por organizações

fora da equipe do projeto, tais como o trabalho contratado. O vendedor, então,
desenvolve o apoio contrato estrutura de divisão de trabalho como parte do
trabalho contratado.
4.3.3. Criar a estrutura analítica do projeto, saídas

necessárias
Segundo (PMBOK 4, 2008) a EAP é uma decomposição hierárquica

orientada a entrega do trabalho a ser executado pela equipe do projeto, para
realizar os objetivos do projeto e criar as entregas necessárias, com cada nível
descendente da EAP representa uma definição cada vez mais detalhada do
trabalho do projeto. A EAP é finalizada através da criação de contas de
controle para os pacotes de trabalho e um identificador exclusivo de um código
de contas. Esses identificadores fornecem uma estrutura para a somatória
hierárquica dos custos, cronograma e informações sobre recursos. Uma conta
47
de controle é um ponto de controle de gestão, onde o custo, escopo e

cronograma estão integradas e em comparação com o valor acumulado para a
medição de desempenho. contas de controle são colocados em pontos de
gerenciamento selecionados no EAP. Cada conta de controle pode incluir um
ou mais pacotes de trabalho, mas cada um dos pacotes de trabalho deve ser
associado a apenas uma conta de controle.
Para (PMBOK 4, 2008) o dicionário da EAP é um documento gerado

pelo processo de criação da EAP que da suporte as sua atividades. O
dicionário da EAP fornece uma descrição mais detalhada dos componentes da
EAP, inclusive pacotes de trabalho e contas de controle. Algimas informações
contidas no dicionário da EAP:
• Código de identificador de conta;

• Descrição do trabalho;
• Organização por responsável;
• Lista dos marcos do cronograma;
• Programar a atividades relacionadas;
• Recursos necessários;
• Estimativas de custos;
• Requisitos de Qualidade;
• Critérios de aceitação;
• Referências técnicas;
• Informações contratuais;
Linha base do escopo é um componente do plano de gerenciamento de

projetos. Componentes da linha de base escopo incluem:
• Declaração do escopo do projeto;

• EAP;
• O dicionário da EAP;
Atualização dos escopos do projeto os documentos que podem ser

atualizados incluem, mas não está limitada a documentação de requisitos. Se
48
aprovado resultado das solicitações de mudança a partir do processo de criar

EAP, então a documentação de requisitos pode precisa ser atualizada para
incluir as alterações aprovadas.
4.4. Verificar o escopo
Segundo (PMBOK 4, 2008) a formalização da aceitação das entregas do

projeto terminadas. A verificação do escopo é o processo de obtenção da
aceitação formal pelas partes Interessadas do escopo do projeto terminado e
das entregas associadas. A verificação do escopo do projeto inclui a revisão
das entregas para garantir que cada uma delas foi terminada de forma
satisfatória. Se o projeto foi finalizado antes do término (abortado), o processo
de verificação do escopo do projeto deve determinar e documentar o nível e a
extensão do término. A verificação do escopo difere do controle da qualidade
porque a verificação do escopo trata principalmente da aceitação das entregas,
enquanto o controle da qualidade trata principalmente do atendimento aos
requisitos de qualidade especificados para as entregas. Em geral, o controle da
qualidade é realizado antes da verificação do escopo, mas esses dois
processos podem ser realizados em paralelo. Figura 16 mostra as entradas,
ferramentas e técnicas, e saídas para a verificar o escopo do projeto.
49
Figura 16. Mapa mental do processo de verificar o escopo.

4.4.1. Verificar o escopo, entradas necessárias
Plano de gerenciamento do projeto é o processo de documentação das

ações necessárias para definir, preparar, integrar e coordenar todos os planos
auxiliares. O plano de gerenciamento do projeto define como o projeto será
executado, monitorado e controlado e encerrado. O projeto de plano de gestão
de conteúdo irá variar de acordo sobre a área de aplicação e complexidade do
projeto. O plano de gerenciamento de projeto é desenvolvido através de uma
série de processos integrados, até o encerramento do projeto. Este processo
resulta em um plano de gerenciamento de projetos que é progressivamente
elaborada por atualizações e controladas e aprovadas.

Matriz de rastreabilidade, descrição no capítulo 4.1.3 Coleta de

50
Entrega validada consiste em verificar e as entregas que foram

concluídas e a necessária correção para atender o processo de controle de
qualidade.
4.4.2. Verificar o escopo, ferramentas necessárias
A inspeção que inclui atividades como medição, exame e verificação

para determinar se o trabalho e as entregas atendem aos requisitos e critérios
de aceitação do produto. Inspeções são por vezes chamadas de revisões,
revisões do produto, auditorias e orientações. Em algumas áreas de aplicação
esses diferentes termos têm significado estreito e específico.
4.4.3. Verificar o escopo, saídas necessárias
Entregas aceitas que preenchem os critérios que devem ser

formalmente assinados e aprovados pelo cliente ou patrocinador. A
documentação formal recebida do cliente ou patrocinador reconhecendo a
aceitação formal das partes interessadas das entregas do projeto é
encaminhado para o fase de encerramento do processo.
Solicitações de mudança que são as entregas terminadas que não foram

formalmente aceitas são documentadas, juntamente com as razões da não
aceitação. Esses resultados podem exigir um pedido de mudança para o
reparo do defeito.As solicitações de mudança são processadas para revisão e
destinação pelo processo integrado de mudanças.
51
Atualizações dos documentos que inclui todos os documentos que

definem o escopo do produto ou do relatório sobre a conclusão do produto,
estes documentos são resultantes do processo de verificação de escopo.
4.5. Controlar o escopo
Controle das mudanças no escopo do projeto. Esses processos

interagem entre si e também com processos de outras áreas de conhecimento.
Cada processo pode envolver o esforço de uma ou mais pessoas ou de grupos
de pessoas, com base nas necessidades do projeto. Cada processo ocorre
pelo menos uma vez em todos os projetos e também em uma ou mais fases do
projeto, se ele estiver dividido em fases. Embora os processos estejam
apresentados aqui como componentes distintos com interfaces bem definidas,
na prática eles podem se sobre por e interagir de maneiras não detalhadas
aqui. Figura 17 mostra as entradas, ferramentas e técnicas, e saídas para a
controlar o escopo do projeto.
Figura 17. Mapa mental do processo de controlar o escopo.

52
4.5.1. Controlar o escopo, entradas necessárias
Plano de gerenciamento do projeto, descrição no capítulo 4.4.1 Verificar

Informação sobre o desempenho do trabalho contém dados sobre o

andamento do projeto, tais como atividades que tenham já iniciadas, os seus
progressos e resultados que já se acabaram.

Matriz de rastreabilidade, descrição no capítulo 4.1.3 Coleta de

Ativos de processos organizacionais, descrição no capítulo 4.2.1 Definir

4.5.2. Controlar o escopo, ferramentas necessárias
Análise de variação são medições de desempenho do projeto usadas

para avaliar as consequências das mudanças na linha base escopo.
Importantes aspectos de controle do escopo do projeto incluem a determinação
da causa e grau de variação em relação à base de escopo e decidir se uma
ação corretiva ou preventiva é necessária.
53
4.5.3. Controlar o escopo, saídas necessárias
Medições de desempenho do trabalho incluem análise do planejanto das

atividades, resultado da realização destas atividades ou outras medidas de
desempenho escopo. Estas informações são documentadas e comunicadas às
partes interessadas.
Atualização dos ativos de processos organizacionais inclui geralmente:
• Causas das variações;

• Ações corretivas escolhidas e as razões;
• Outros tipos de lições aprendidas do controle do escopo do projeto.
Solicitação de mudança, descrição no capítulo 4.4.3 Verificar o escopo,

saídas necessárias
Atualização do plano de gerenciamento do projeto consiste na

solicitação de mudanças forem aprovadas afetaram o escopo do projeto, a
declaração de escopo, a EAP, o dicionário da EAP, estes documentos devem
se revisados para atender as mudanças solicitadas. Mas estás mudanças
também afetaram custos e cronograma, que também deverem ser revisados.
Atualizações dos documentos do projeto consistem na documentação de

requisitos e na matriz de rastreabilidade de requisitos.
4.6.1. Vantagens do gerenciamento de escopo
O gerenciamento de escopo pode ser aplicado em diversos tipos de

projetos não estão restritos aos gigantescos, alta complexidade e custo
54
elevados. Qualquer linha de negócio terá benefícios pelo gerenciamento do

escopo, os principais são:
• Evita surpresas durante o ciclo de vida do projeto.

• Documenta e facilita as estimativas para futuros projetos.
• Permitem determinar as atividades, recursos e prazos necessários
para desenvolver o projeto e somente os necessários.
• Agilidade nas tomadas de decisões, já que as informações estão
organizadas e disponibilizadas.
Permite uma melhor divisão do trabalho.
4.6.2. Principais causas de fracassos em projetos
• O projeto inclui muitas atividades e pouco tempo para realizá-las;

• O excesso de documentação pode tornar os processos de difícil
gerenciamento;
• As estimativas financeiras pobres ou incompletas;
• O projeto é baseado em dados insuficientes, ou inadequados;
• Sistema de controle inadequado.
• Treinamento e capacitação inadequados.
55
5. Estudo de caso sobre o projeto do sistema de controle de

palestras e chamadas (SCPC)
O sistema de controle de palestras e chamadas, que foi desenvolvido

com apoio e participação de estagiários, funcionários, professores, alunos e
voluntários em conjunto ao NDTI (Núcleo de Desenvolvimento de Tecnologia
da Informação) no segundo semestre de 2009, permite que os participantes se
cadastrem nas palestras de interesse, e que os coordenadores do evento
cadastrem os eventos que acontecerão, gerará listas de presença para os
alunos que participarem e certificados para todos os participantes. O sistema
no momento fornece um veículo de comunicação entre os alunos, comunidade
e o CTZL (Centro Tecnológico da Zona Leste) na informatização da instituição
com possibilidade de extensão para o World Wide Web.
5.1. Características principais do estudo de caso
Este estudo de caso sobre o do sistema de controle de palestras e

chamadas (SCPC) tem como objetivo demonstrar as fases do ciclo de vida do
projeto, processos de cada fase, documentos gerados e utilizados para
gerenciar este projeto e características em comum os descritos no PMBOK 4
2008.
5.2. Modelo de ciclo de vida iterativo incremental
Ciclo de vida utilizado no desenvolvimento do sistema de controle de

palestras e chamadas (SCPC) é baseado no modelo iterativo e incremental,
56
que está organizado nas seguintes fases (iniciação, elaboração, construção e

transição) projetos desenvolvidos segundo está abordagem dividem o
desenvolvimento de um produto de software em ciclos. Em cada ciclo é
alocado um subconjunto de requisitos que são desenvolvidos, no próximo ciclo,
outro subconjunto dos requisitos será desenvolvido e requisitos já finalizados
podem sofre alterações nos próximos ciclos. Por meio da construção
incremental e iterativa de novas funcionalidades são adicionadas até que o
sistema completo esteja construído.
É similar ao modelo de ciclo de vida proposto pelo PMBOK 4 2008 no

qual cada fase do projeto acontece à entrega, ou finalização, de um
determinado trabalho. Mas o ciclo de vida utilizado no desenvolvimento do
projeto SCPC não tem uma fase especifica de controle, e sim um processo
responsável por esta atividade o gerenciamento de configurações e mudanças
que é realizado durante todo o ciclo de vida do projeto. Este processo
geralmente é apoiado por softwares específicos, foi utilizado sistema de
controle de versões e mudanças SubVersion o que permitiu uma maior
interação entre os envolvidos no desenvolvimento do projeto, pois armazena as
mudanças nas informações, o que permiti comparar versões diferentes de
documentos, algo essencial para evitar o retrabalho, pois programadores
gastam horas fazendo pequenas alterações em seus aplicativos e então
precisão desfazer essas modificações ou verificá-las alguns dias depois. Em os
benefícios do processo de gerenciamento de configurações e mudanças é mais
evidente em projetos maiores onde vários programadores e analistas trabalham
juntos e simultâneos nos mesmos arquivos o que pode levar a uma grande
desordem.
5.3. EAP do projeto SCPC
Podemos notar que os processos utilizados para desenvolver o projeto

SCPC se repetem ao longo das fases do ciclo de vida uma característica do
57
modelo iterativo e incremental que pode ser observado na figura 16, mas em
cada fase os processos são decompostos até o nível de pacote de trabalho
específicos daquela fase como demonstra a figura 18, 19 e 20.
Figura 18. EAP do projeto SCPC.

Fonte: (SCPC, 2009, s/p)
Figura 19. Fase de iniciação do projeto SCPC com seus processos divididos em pacotes de
trabalho necessário para conclusão do projeto.
58
Figura 20. Fase de elaboração do projeto SCPC com seus processos divididos em atividades
necessárias para conclusão do projeto.
5.4. Documentação do escopo do projeto e produto
Muitos documentos, ferramentas, técnicas foram utilizados para

gerenciar o escopo do projeto e do produto SCPC, alguns se identificam com
os propostos pelo PMKOK 4 2008 e outros não. Os principais documentos
utilizados são os seguintes:
• Documento de visão define o que os envolvidos esperam do

produto a ser desenvolvido, em termos das necessidades e
características mais importantes. Por conter uma descrição dos
requisitos centrais pretendidos, proporciona a base contratual
para requisitos técnicos mais detalhados.
59
• Diagrama de caso de usos que corresponde a uma visão

extremamente de alto nível do sistema. Esse diagrama representa
graficamente os atores (envolvidos), casos de usos
(funcionalidades do sistema) e relacionamentos entre esses
elementos.
• Diagrama de classes é muito utilizado na construção do modelo

de classe desde o nível de analise até o nível de especificação. A
implementação do sistema é toda baseada nos modelos de
classe desenvolvidos nos processos de analise e design.
Estes documentos descritos acima podem ser encontrados nos anexos

deste trabalho.
5.5. Considerações sobre o estudo de caso
Um dos pontos que podem ser destacados no projeto SCPC é o fato de

que foi desenvolvido por uma equipe inexperiente em gerenciamento de
projetos formada por estagiários e voluntários, sem uma pessoa com
experiência no papel de gerente do projeto, a pessoa responsável por
gerenciar o projeto também tinha que realizar outras atividades, este
sobrecarga de trabalho em uma pessoa gerou algumas falhas durante o ciclo
de vida do projeto, alguns documentos não foram atualizados conforme as
mudanças ocorriam e outros documentos nem foram criados. Para evitar estes
problemas poderia utiliza as melhores práticas descritas no PMBOK 4 2008
para gerenciamento de escopo do projeto, dentre elas as descritas no processo
de verificar o escopo e controlar o escopo.
Uma pergunta que deve ser respondida depois da conclusão de um

projeto foi bem sucedido. Só que está pergunta é passível de pelo menos duas
respostas, uma delas seria que não foi bem sucedido por não realizou todo o
60
trabalho definido como necessário para conclusão do projeto e a outra resposta

é que foi bem sucedido, pois apesar dos imprevistos o projeto foi entregue
dentro do prazo e totalmente funcional. É importante ressaltar que os
processos responsáveis por avaliar os resultados obtidos com o termino do
projeto no PMBOK 4 2008 encontram-se na fase de encerramento do ciclo de
vida do projeto, está fase também é conhecida como fase de aprendizado
onde problemas ocorridos podem ser avaliados para que não ocorram nos
próximos projetos.
61
6. Considerações finais
Os processos de gerenciamento do escopo iniciam-se com sua

definição. Primeiramente, é necessário transformar as expectativas e desejos
dos clientes em documentos formais, que são os seguintes a declaração do
escopo, a documentação dos requisitos, o plano de gerenciamento dos
requisitos, a matriz de rastreabilidade dos requisitos e estrutura analítica do
projeto. Para definição destes processos é necessário o envolvimento dos
interessados no projeto, e podem ser auxiliados por técnicas JAD e DELPHI,
até o fechamento de cada documento. E nestes documentos devem constar de
forma detalhada e deixar nenhuma necessidade ou expectativa como
subentendida.
As mudanças são comuns em todos os projetos e inevitáveis. O mais

importante possuir o controle sobre elas. Devemos criar um único ponto de
contato entre as partes envolvidas, o gerente do projeto deve intermédia este
para sempre está informado do que acontece no projeto. Nenhuma alteração
deve ocorrer sem o consentimento do gerente do projeto e a devida análise de
impacto no prazo, custo e risco. Falhas de controle nem sempre estão
relacionadas com as atividades controlar o escopo também são afetados pelos
processos de comunicação. Um usuário pode solicitar uma alteração
diretamente ao programador, que as executa sem consultar o gerente do
projeto, deixando de lado outras atividades em andamento. O usuário não
percebe que seus pedidos desestabilizam o desenvolvimento, o que afeta a
produtividade e qualidade, com conseqüências nos prazos e custo.
O sucesso no gerenciamento do escopo está em utilizar um canal único

de comunicação entre os envolvidos e na formalização de todas as
informações, relevantes, incluindo cada solicitação de alteração e seu
respectivo impacto no projeto. Muitas mudanças devem ser adiadas para não
inviabilizarem a conclusão do projeto.
62
Referências bibliográficas
BRUZZI, Demerval Guilarducci. Gerenciamento de Projetos - 1ª Edição -

Distrito Federal: Editora SENAC Distrito Federal, 2008.
KERZNER, Harold. Gestão de Projetos As Melhores Práticas - 2ª Edição -

Bookman, 2004.
PMISP. Introdução aos conceitos do gerenciamento de escopo. Disponível em

< http://www.pmisp.org.br/instituto.asp>. Acessado em 15 de Setembro de
2010 às 14 horas
PMI. PMBOK - Um guia do Conjunto de Conhecimentos em Gerenciamento de

Projetos - 4ª Edição - Pensilvânia: PMI, 2008.
SOTILLE, Mauro. Visão geral dos processos do gerenciamento de projetos –

PMBOK 4ª Edição. Disponível em
<http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf>.
Acesso em 25 de Agosto de 2010 às 17 horas
VALERIANO, Dalton L. Gerenciamento Estratégico e Administração por

Projetos – 1ª Edição - Makron Books, 2001.
VARGAS, Ricardo Viana. Gerenciamento de Projetos - 7ª Edição - Rio de

Janeiro: Brasport, 2009.
XAVIER, Carlos Magno da Silva, CHUERI, Luciana de O. Vilanova.

Metodologia de Gerenciamento de Projetos no Terceiro Setor – 1ª Edição - Rio
de Janeiro: Brasport, 2008.
63
Anexos
Anexo A. Documento de visão
Versão 1.0
Histórico da Revisão
Data Versão Descrição Autor
6 de agosto de 1.0 Versão beta Glauber Rocha

2009 Romão
Índice Analítico
• Introdução
• Posicionamento
• Descrições dos Envolvidos e Usuários
• Visão Geral do Produto
• Características do Produto
• Restrições
• Limites de qualidade
• Precedência e Prioridade
• Outros Requisitos do Produto
• Requisitos da Documentação
Introdução
A finalidade deste documento é coletar, analisar e definir as características e

necessidades de alto nível do Sistema de Controle de Palestras e Chamadas. Ele se
concentra nos recursos necessários aos envolvidos e aos usuários-alvo e nas razões que
levam a essas necessidades. Os detalhes de como o sistema atinge essas necessidades
são descritos nos modelos de caso de uso e nas especificações suplementares.
64
Finalidade
A finalidade deste documento é definir os requisitos de alto nível do Sistema de

Controle de Palestras e Chamadas em termos de necessidades dos usuários finais.
Escopo
Este Documento de Visão refere-se ao Sistema de Controle de Palestras e Chamadas,

que será desenvolvido pelo NDTI (Núcleo de Desenvolvimento de Tecnologia da
Informação). Esse sistema permitirá que os participantes se cadastrem na palestras de
interesse, e que os coordenadores do evento cadastrem os eventos que acontecerão,
gerará listas de presença para os alunos que participarem e certificados para todos os
participantes.
Definições, Acrônimos e Abreviações
Consulte o documento Glossário.
Referências
NA.
Posicionamento
Oportunidade de Negócios
O Sistema de Controle de Palestras e Chamadas no momento fornece um veículo de

comunicação entre os alunos, comunidade e o CTZL (Centro Tecnológico da Zona
Leste) na informatizado na instituição com possibilidade de extensão para a World
Wide Web.
Os benefícios previstos dessa abordagem incluem:
1. Isso colocará em relevo o poder do CTZL de formação profissional e

pólo gerador de tecnologia e conhecimento.
65
2. O network gerado pela divulgação de nossos eventos levará ao maior

número de correntes discentes e docentes para nossas vagas
disponíveis, aumentando assim a qualidade de nosso ensino.
3. A divulgação dos trabalhos realizados por nossos colaboradores contará
como uma vantagem competitiva no mercado de trabalho.
Descrição do Problema
O problema Divulgar os eventos acadêmicos do CTZL
Afeta Docentes, discentes e comunidade
O seu impacto é Que não participam de eventos, pois não têm meios fáceis para se
atualizarem e participarem dos eventos.
Uma solução ideal Manter um sistema online para divulgação e controle dos eventos que
seria acontecerão no CTZL.
Sentença de Posição do Produto

Para Docentes, discentes e comunidade
Quem Quiser acompanhar grupos ou eventos específicos de formação

profissional
Sistema de Controle é um software

de Palestras e
Chamadas
Que Divulga e mantém o cadastro dos participantes dos eventos.
Diferente de O estado atual que requer que eles verifiquem as notícias com
colegas e secretária regularmente para encontrar aqueles de seu
interesse.
Nosso produto Matem a divulgação dos eventos, assim os interessados podem

acompanhar nossos eventos e se inscreverem por ele.
Descrições dos Envolvidos e Usuários

66
Demografia do Público
O Público-alvo desse sistema compreende um segmento da sociedade de interesse

intelectual e acadêmico profissional.
Resumo dos Envolvidos

Nome Representa Papel
Diretor Diretor da FATEC. Aprova divulgação de novos

eventos, assinar certificados de
participação.
Coordenador de Coordenadores dos cursos da Entrar em contato com parceiros

Curso instituição. da FATEC, assinar certificados de
participação.
Parceiros Palestrantes e empresas Apresentar propostas de incentivo

interessadas no ao desenvolvimento do FATEC.
desenvolvimento do FATEC.
Resumo dos Usuários

Nome Representa Papel
Participante Alunos ou convidados, que Informar-se e inscrever-se em

participaram das palestras. novos eventos.
Coordenador Responsáveis pelos eventos Cadastrar novos eventos,

que acontecerão no CTZL. palestrantes e voluntários, que
poderão ser usuários do sistema.
Administrador Operador que determinará os Colocar conteúdo no site da Web,

perfis de acesso ao sistema, e categorizar o conteúdo, perfis e
suas características visuais. características do sistema.
Voluntario Quem participará de atividades Inscrever e marcar presença dos

voluntárias, como operador do participantes no dia do evento e
sistema ou não. gerar certificados.
Ambiente do usuário
67
As pessoas acompanharão as notícias sobre os eventos através da página web.Os

padrões de uso não são previsíveis nesse momento, embora haja previsão de volumes
maiores durante a última semana que antecede os eventos, como a Semana Tecnológica.
Os usuários apenas terão que ter um computador com acesso a internet para utilizarem
os serviços disponibilizados pelo Sistema de Controle de Palestras e Chamadas, sendo
que para os alunos a FATEC também disponibiliza de computadores conectados a
internet para este fim.
Necessidades dos Principais Envolvidos/Usuários

Necessidade Prioridade Preocupações Solução Soluções Propostas
Atual
Especificar perfil Alta Nível de Nenhuma Permitir vários níveis de

granularidade seleção de páginas
Receber resposta Alta Níveis de volume Nenhum Usar arquitetura em

quando cadastrar e tempo de camadas para permitir a
em nova palestra resposta escalabilidade
Divulgar as Alta Tempo de É feita Fornecer links em uma

palestras disponibilidade pessoalmente página da Web para os
com itens de eventos
comunicação
entre os
alunos
Divulgar o Alta Manter sistema Selecionar Estabelecer parcerias

endereço atualizado canais de com outros sites
eletrônico do propaganda
sistema para atingir
indiretamente
os segmentos
do mercado
Verificar a Média Nenhuma Nenhuma Fornecer relatórios aos

distribuição de anunciantes sobre o
publicidade para número de
estimar a visualizações do
eficiência conteúdo publicitário
68
Alternativas e Concorrência
No momento, não existe uma alternativa direta para esse serviço.
Visão Geral do Produto
Perspectiva do Produto
Este produto impulsionará a participação dos alunos e comunidade acadêmica em geral

nas atividades de toda a instituição, que forem divulgadas por ele. Graficamente, o
sistema pode ser visto desta forma:
69
Anexo B. Documento de caso de uso

70
Anexo C. Diagramas de classe
Manter inscriçãoTO
71
72
Anexo D. Sugestão de continuidade deste trabalho

diferença entre RUP e PMBOK
Como sugestão de continuidade deste trabalho, indico um estudo

comparativo entre gerenciamento do escopo de projetos de software com RUP
e PMBOK, quais vantagens, desvantagens, diferenças das duas abordagens.
73
Anexo E. Autorização de uso deste trabalho
Eu, Rafael Nise Pereira, autorizo a inserção deste trabalho na biblioteca

digital de trabalhos de conclusão de curso, no portal da FATEC-ZL
(www.fateczl.edu.br) bem como em qualquer meio eletrônico utilizado pela
instituição, para os fins educacionais, técnicos, culturais de divulgação
institucional e não comerciais.

TCC 008

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TCC 008

Diunggah oleh

Hak Cipta:

Format Tersedia

Faculdade de Tecnologia da Zona Leste

RAFAEL NISE PEREIRA

Melhores práticas para gerenciamento

Monografia apresentada no curso

Orientador: Prof. Mestre Joilson

Orientador: Me. Joilson de Souza Cardoso

1. Gerenciamento de projetos. 2. Gerenciamento do escopo de projetos. 3. PMBOK.

PEREIRA, Rafael Nise

Melhores práticas para gerenciamento do escopo de projetos

Monografia apresentada no curso de

Prof. Me Joilson de Souza Cardoso Instituição: FATEC-ZL

Julgamento: ________________Assinatura: ______________

Prof. Me Antônio Rodrigues Carvalho Neto Instituição: FATEC-ZL

Julgamento: _________________Assinatura: ______________

Prof. Glauber Rocha Romão Instituição: SENAC

Julgamento: ________________Assinatura: ______________

São Paulo, 10 de dezembro de 2010.

A Deus por sempre estar presente em minha vida em todos os instantes.

Figura 1. As áreas de abrangência de portfólios, programas, projetos e

PMI - Project Management Institute

O gerenciamento de escopo de projetos é essencial para as

Palavras- chave: Gerenciamento de projetos; Gerenciamento do escopo de

Scope project management is critical for organizations that operate in a market

Key words: Project Management, Project Scope Management, PMBOK;

Toda a história da humanidade é repleta de grandes realizações, muitas

Atualmente, a globalização e os meios de comunicação têm diminuído

Objetivo deste trabalho é conceituar as melhores práticas de

Em busca de responder a seguinte pergunta, quais as principais causas

Algumas hipóteses levantadas sobre as causas de fracasso no

A. Falta de comunicação entre os envolvidos;

Será utilizada a metodologia de pesquisa bibliográfica neste trabalho que

Este trabalho está organizado em cinco capítulos. Introdução; No capítulo

Segundo o (PMBOK 2008, p.5) Projeto é um esforço temporário

De acordo com a definição apresentada na norma NBR ISO 10.006, que

Com base nos conceitos mencionados acima, um projeto é um esforço

Temporário significa que todo projeto tem um início e um término bem

O termo temporário não se aplica ao serviço ou produto gerado pelo

2.1. Diferenças de operações correntes e projetos

Segundo (VALERIANO, 2001), operações correntes são seqüências de

2.2. Subprojetos, programas e portfólios

Quando um projeto precisa ser dividido em várias partes de fácil

O termo programa e utilizado para identificar um conjunto de projetos

de controle que não seriam obtidos se eles fossem gerenciados de forma

Portfólios (carteira de projetos) são a organização de um grupo de

Figura 1 – As áreas de abrangência de portfólios, programas, projetos e subprojetos.

2.3. Partes envolvidas no projeto (Stakeholders)

Segundo (XAVIER e CHUERI, 2008), as pessoas, grupo de pessoas e

identificar esses interessados, determinar suas necessidades então gerenciar e

Figura 2 - Possíveis partes envolvidas no projeto

2.4. Ciclo de vida do projeto

A organização ou os gerentes de projetos podem dividir projetos em

operações em andamento da organização executora. Coletivamente, essas

Segundo (VARGAS, 2009) cada fase do projeto é caracterizada pela

As atividades necessárias para criação de um produto são exclusivas de

A quantidade de fases em projeto está relacionada à sua natureza.

Na figura 3 podemos observar como o ciclo de vida de um projeto pode

Figura 3 - O ciclo de vida de um projeto subdividido em fases características.

Para (VARGAS, 2009) as principais características das fases do ciclo de

• Fase de iniciação, nesta fase as necessidades dos envolvidos são

• Fase de planejamento, nesta fase tudo que é necessário para

• Fase de execução, tudo que foi planejado anteriormente é colocado

nesta fase. Grande parte do orçamento e do esforço do projeto é

• Fase de monitoramento e controle acontece paralelamente ás

Julgamento: __Assinatura:

Julgamento: ___Assinatura:

Julgamento: __Assinatura: