Este artigo apresenta um modelo prático de como a aplicação do Guia PMBOK® pode ser realizada através de um fluxo de processo, que demonstra uma metodologia simplificada e objetiva para uso em projetos de engenharia de software. Este modelo tem o objetivo de definir um fluxo seqüencial e lógico, abrangendo a iniciação e o planejamento de um projeto de desenvolvimento de sistemas da tecnologia da informação, onde serão abordados principalmente os processos com seus documentos de entrada e saída, envolvendo principalmente as etapas de levantamento de requisitos, análise de negócios, análise de sistemas, modelagem de dados, estimativas de atividades, recursos e prazos que irão compor o cronograma de trabalho para a execução do projeto. Com esta demonstração o autor visa provocar o uso das boas práticas sugeridas pelo PMI, retirando impedimentos ainda existentes na área de tecnologia quanto ao uso destas práticas, e abrindo o caminho para novos estudos e aplicações da metodologia apresentada.

1. Como usar o Guia PMBOK® na engenharia de softwares
Aplicando os grupos de processos de iniciação e planejamento
Fábio Rodrigues Cruz1
1
Autor do artigo
FabioCruz.com/Gerenciamento de Projetos
Mantenedor/Gerente de Projetos
fabiorcruz@gmail.com
Resumo - Este artigo apresenta um modelo prático de como a aplicação do Guia PMBOK® pode ser
realizada através de um fluxo de processo, que demonstra uma metodologia simplificada e objetiva
para uso em projetos de engenharia de software. Este modelo tem o objetivo de definir um fluxo
seqüencial e lógico, abrangendo a iniciação e o planejamento de um projeto de desenvolvimento de
sistemas da tecnologia da informação, onde serão abordados principalmente os processos com seus
documentos de entrada e saída, envolvendo principalmente as etapas de levantamento de requisitos,
análise de negócios, análise de sistemas, modelagem de dados, estimativas de atividades, recursos e
prazos que irão compor o cronograma de trabalho para a execução do projeto. Com esta
demonstração o autor visa provocar o uso das boas práticas sugeridas pelo PMI, retirando
impedimentos ainda existentes na área de tecnologia quanto ao uso destas práticas, e abrindo o
caminho para novos estudos e aplicações da metodologia apresentada.
(Palavras-chave: gerenciamento de projetos, Guia PMBOK®, fluxo de processo, desenvolvimento de
software, metodologia)
Abstract – This article presents one practice model to apply of PMBOK® Guide through the process
flow that shows one simplified and straight methodology that useful in software development project.
This model has the goal to define one logic and sequential flow covering from initialize to planning of
information technology system. This will be mainly approached the process with its inputs and outputs
documents that involve stages of requirements, business analysis, system analysis, data models,
resources, activities and time estimate that will be compose work schedule to project execution.
(Keywords: Project
methodology)
management,
PMBOK®
Introdução
Muito se fala atualmente sobre a
necessidade de melhorar a forma de gerenciar
os projetos da área de tecnologia da
informação, principalmente os relacionados a
desenvolvimento de sistemas. Várias boas
práticas ou arcabouços de gerenciamento são
temas de casos de sucesso, porém, muitas
dúvidas ainda existem sobre qual é o melhor,
qual funciona mais facilmente, qual é mais
ágil, e até mesmo, como aplicar qualquer um
deles em um projeto?
Sendo assim, o objetivo principal
deste artigo é responder a este último
questionamento em relação ao Guia
PMBOK®, elucidando como aplicar os
processos sugeridos pelo guia e, como gerar
Guide,
process
flow,
software
development,
valor para a equipe envolvida, para o próprio
projeto em execução, e principalmente para o
cliente que aguarda ao final dos trabalhos, um
sistema desenvolvido com qualidade e dentro
das suas necessidades.
Um projeto de desenvolvimento de
sistemas abrange várias áreas, e geralmente
passa por inúmeras etapas até a sua
conclusão. No entanto, um fator muito
observado ao longo de vários projetos
fracassados, demonstra que os principais
motivos que levam ao insucesso são a
ausência de planejamento inicial, o mau
entendimento dos trabalhos que precisam ser
realizados,
e
as
falsas
estimativas
apresentadas como resultado dos péssimos
trabalhos anteriores.
Por isso este artigo visa demonstrar
um modelo funcional na engenharia de

2. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
software, que aplica de forma prática e
objetiva os processos de iniciação e
planejamento contidos no Guia PMBOK®,
objetivando identificar e registrar as partes
interessadas;
o
levantamento
e
o
detalhamento de requisitos através de
análises de negócio; o detalhamento do
escopo a partir de análises de sistemas,
modelagem de dados e protótipos; gerando
um material sólido e consistente para que se
alcance
uma
eficiente
estimativa
de
atividades, recursos e prazos, que possam por
fim ser evidenciados em um cronograma real
de trabalho.
Ao longo do fluxo de processos serão
gerados
artefatos
que
naturalmente
estimularão a comunicação clara, objetiva e
direta, entre a equipe do projeto, o cliente e
todos os envolvidos e interessados com o
projeto, aumentando e criando muitas
condições e oportunidades para se atingir o
sucesso ao final do projeto.
Contexto
O primeiro fator de influência negativa,
é que inúmeros profissionais da área de
sistemas da informação ainda não estão
convencidos de que as boas práticas do Guia
PMBOK® funcionam em projetos de
desenvolvimento de sistemas. Este conceito
se dá, principalmente pela velocidade em que
as aplicações precisam ser concluídas, e a
rapidez com que o mercado sofre mutações,
não dando tempo para que os projetos sejam
concluídos, e muito menos a aplicação de
práticas extensas, complexas e fora da
realidade dos projetos em questão.
Outro fator prejudicial e que bloqueia o
uso das boas práticas selecionadas, é que na
maioria das vezes os profissionais sabem o
que precisam utilizar para melhorar seus
projetos, principalmente após conhecerem as
ferramentas e técnicas de gerenciamento, e
descobrirem que as práticas são mais rápidas,
mais simples do que imaginavam e aplicáveis
a realidade dos projetos de engenharia de
software. No entanto, apesar de saberem o
que precisam fazer, se deparam com o
problema de não saberem como fazer. Isso
acarreta na dificuldade de decidir quando
aplicar uma determinada prática, ou qual o
momento correto de execução de uma ação
específica, ou até mesmo não saber quando
Confidencial
deve produzir ou recorrer a um documento de
entrada ou saída.
Assim este artigo visa demonstrar um
fluxo eficiente que permitirá em uma
sequencia lógica e realista, executar os
processos e utilizar seus documentos de
entrada e saída de forma eficaz para atingir o
objetivo do projeto, quebrando os maus
conceitos apresentados anteriormente, e
estimulando o uso mais adequado de uma
metodologia, que permite a reutilização de
práticas reconhecidas pelo mercado mundial
de gerenciamento de projetos.
Desenvolvimento
De acordo com o Guia PMBOK® - 4ª
edição, há 42 processos sugeridos para
aplicação em gerenciamento de projetos, e
estes são distribuídos em cinco grupos de
processos.
A metodologia sugerida por este artigo
aborda apenas os processos contidos nos dois
primeiros grupos de processos, que são o de
iniciação e o planejamento, sendo que o fluxo,
métodos e padrões apresentados não são os
únicos e não se propõem a ser os melhores,
apenas são uma forma prática e funcional de
fazer.
O fluxo
A partir da vivência do autor em
diversas experiências em projetos de
desenvolvimento de sistemas, sem dúvida, os
dois grupos de processos mais importantes
dentre os demais são os de iniciação e
planejamento. Simplesmente porque são os
primeiros a ocorrerem nos projetos de
qualquer natureza, e são os responsáveis por
definir e ditar o ritmo, realizar os
entendimentos, identificar as tarefas e a forma
com que as atividades e as comunicações vão
fluir ao longo de toda a execução do projeto.
Além de que, serão estes dois processos que
vão definir “COMO”, e o “O QUE” será
entregue ao final do projeto, acompanhados
inclusive dos critérios de aceitação final do
produto do projeto.
Por isso, se as etapas descritas no
fluxo não forem realizadas, possivelmente
ocorrerão problemas sérios no projeto em
questão, principalmente os ligados as
entregas, estimativas e entendimentos das
necessidades
do
cliente,
influenciando
©MundoPM, 2011
Pagina 2 of 12

3. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
diretamente na futura aceitação final do
projeto.
Em inúmeras ocasiões a equipe de
projeto se pergunta: “Porque tivemos tantos
erros na execução do projeto?”, ou “Porque
estamos demorando tanto para homologar
esta entrega?”, ou até “Porque o nosso cliente
está
tão
descontente
com
o
que
entregamos?”. Provavelmente foi porque os
processos
contidos
na
iniciação
e
planejamento do projeto foram negligenciados,
ou pior, simplesmente não realizados.
Com o propósito de demonstrar uma
eficiente maneira de colocar em prática estes
processos, em projetos de desenvolvimento
de sistemas e seguindo as boas práticas
sugeridas pelo Guia PMBOK®, o autor
apresenta o fluxo dos processos de iniciação e
planejamento, que pode ser visualizado na
figura 1.
A execução deste fluxo deve ser a
primeira realização do projeto, visando
abranger desde a primeira reunião do projeto,
aquela conhecida como kickoff, até a parte
que atinge o cronograma detalhado de todas
as atividades do projeto, incluindo estimativas,
esforços e recursos envolvidos.
Além é claro, de permitir a obtenção
de todo o escopo definido e devidamente
documentado ao final do fluxo.
Figura 1 – Fluxo de processos de iniciação e planejamento
Os elementos do fluxo
O fluxo possui os seis elementos a
seguir,
que
permitem
ao
utilizador
rapidamente identificar qual o caminho a
seguir, e quais os artefatos utilizados e
produzidos pelos processos.
Confidencial
1 - Entradas: As entradas são todos
os documentos, internos ou externos ao
projeto, necessários para se realizar o
processo com eficiência e eficácia. As
entradas são representadas no fluxo conforme
a figura 2. No exemplo, estão destacadas as
entradas do processo 1.1. Project Charter,
onde são sugeridos os documentos de
©MundoPM, 2011
Pagina 3 of 12

4. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
declaração de trabalho, contrato e business
case.
Figura 2 – Exemplo de entrada do fluxo
2 - Processos: São os processos
determinados para receber as entradas
sugeridas, e serem executados durante o
fluxo, contendo as atividades, ferramentas ou
técnicas específicas para atingir o objetivo de
cada processo.
Os processos são representados no
fluxo conforme a figura 3.
Figura 3 – Exemplo de processo do fluxo
3 - Saídas: As saídas são os
documentos produzidos pelas atividades
realizadas durante o processo, e podem ser
consideradas o resultado da execução do
processo. As saídas são mostradas no fluxo
conforme a figura 4.
Figura 4 – Exemplo de saída do fluxo
Os itens contidos na descrição da
saída podem representar tópicos de um
documento, ou o próprio documento, podendo
ser um ou vários, além de obrigatórios ou
opcionais. No exemplo da figura 4, estão
ilustradas as saídas do processo 1.1. Project
Charter. Este processo gera apenas um
documento, denominado Termo de abertura
do projeto, que contém todas as descrições
citadas como tópicos.
Confidencial
4 - Documentos: Ligados diretamente
as saídas, os documentos servem de
orientação para a composição das mesmas.
Conforme dito anteriormente, as saídas
podem ser representadas por um ou mais
documentos, e estes podem ser obrigatórios
ou opcionais, sendo que estas definições são
dadas por este elemento, e podem ser
apresentados no fluxo conforme figura 5.
Figura 5 – Exemplo dos documentos de saída
do fluxo
No exemplo da figura 5, os números 4
e 5 representam que uma determinada saída
deverá ser composto por pelo menos dois
documentos distintos e obrigatórios. Já o
número 3 significa que a saída terá um
documento que poderá ser subdividido em
vários outros documentos, seja para melhorar
a comunicação ou para estruturar a divisão
por áreas por exemplo.
Por fim, os números de 13 e 14,
definem que a saída deverá ser através de um
documento obrigatório (o 13, de cor amarela)
e um opcional (de cor rosa) que pode ser
subdividido
em
vários
documentos.
Lembrando que estes tipos podem estar
sozinhos ou combinados.
5 - Sequencia e sentido: As setas
com traço contínuo representam a sequencia
que deve ser seguida pelo fluxo, sendo que o
sentido deve ser da ponta sem a seta para a
ponta com a seta. A figura 6 mostra um
sentido indo da esquerda para a direita, de
baixo para cima.
Figura 6 – Exemplo de seta de sentido do
fluxo
6 - Atualizações: As setas com
tracejado em vermelho representam que um
documento de outro processo está sendo
atualizado, devido a uma atividade do
©MundoPM, 2011
Pagina 4 of 12

5. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
processo em execução. Este é um elemento
de fundamental importância para manter os
documentos do projeto atualizados e em
constante evolução, acompanhando os
produtos do projeto. Na figura 7 é dado um
exemplo de um processo sugerindo a
atualização do plano do projeto.
Figura 7 – Exemplo de atualização de
documento de outro processo
Processos do fluxo
O fluxo abrange os seguintes dez
processos, sendo dois contidos no grupo de
iniciação, e oito contidos no grupo de
planejamento. A separação dos grupos e
processos pode ser facilmente observada no
fluxo da figura 1, pelas divisões “1. Iniciação”
que está na cor rosa, e “2. Planejamento” que
está na cor azul.
1.1 - Project Charter: É o processo
responsável por desenvolver o termo de
abertura do projeto, e contempla o processo
de mesmo nome contido no Guia PMBOK®.
Deve ser realizado logo no início do projeto,
de preferência antes da reunião de kickoff.
Processo
realizado
pelos
patrocinadores, e/ou pelo gerente de projetos.
1.2 - Stakeholders: É o processo
responsável por identificar as partes
interessadas, e contempla o processo de
mesmo nome contido no Guia PMBOK®. Pode
ser iniciado já na reunião de kickoff, e
intensificado após a mesma terminar. Nesta
primeira etapa, é o processo mais importante,
pois os stakeholders serão os principais
influenciadores do projeto.
Processo realizado pela equipe de
gerenciamento, sendo possível, incluir neste
momento a equipe de análise de negócios.
2.1 - Plano de gerenciamento do
projeto: É o processo responsável por
desenvolver o plano de gerenciamento do
projeto, e contempla o processo de mesmo
nome contido no Guia PMBOK®. Deve ser
realizado como primeiro processo da etapa de
planejamento do projeto, e antes de qualquer
trabalho de execução, inclusive antes dos
trabalhos de análise de negócio e sistemas,
Confidencial
pois o(s) documento(s) de planejamento
gerado(s) neste processo guiarão todos os
trabalhos do projeto daqui para frente.
Processo realizado pela equipe de
gerenciamento, sendo possível, incluir as
equipes de análise e desenvolvimento, para
auxílio nas definições de execução e controle.
2.2 - Documentos de requisitos: É o
processo responsável por produzir os
primeiros documentos relacionados com os
requisitos do projeto, tais como matriz de
rastreabilidade e elicitação de requisitos.
Contempla o processo Coletar os requisitos
contido no Guia PMBOK®, e deve ser
realizado sempre após a identificação dos
stakeholders, pois estes é que alimentarão
este processo com os requisitos mais
importantes e fundamentais para atingir o
objetivo do projeto. Também podendo ser
realizado em conjunto com o processo 2.3.
Oficialmente é o primeiro trabalho de
análise de negócios, é será neste processo
que os analistas de negócios começarão a
conhecer o sistema que será desenvolvido.
Processo realizado pelos analistas de
negócio, podendo ser envolvidos os analistas
de sistema e desenvolvedores.
2.3 - Declaração do escopo: É o
processo responsável por produzir os
documentos detalhados e técnicos do projeto,
tais como especificações, protótipos e
modelos de dados. Contempla o processo
Definir o escopo contido no Guia PMBOK®, e
deve ser realizado sempre após a elicitação
de requisitos.
É um dos processos mais longos e
importantes da etapa de análise, pois envolve
um grande contato com os stakeholders, além
de um grande de trabalho de construção de
documentação adequada, com o objetivo de
determinar em detalhes todo o trabalho a ser
executado para terminar o projeto, definindo
inclusive a etapa de desenvolvimento.
Este processo pode ser realizado em
conjunto com o processo 2.2, e é onde os
analistas de negócio devem participar
detalhando as regras de negócio, e os
analistas de sistemas especificando todos os
componentes técnicos do sistema, incluindo
também regras, arquitetura, padrões de
interface, entre outras. Como apoio os
designers, desenvolvedores, analistas de
©MundoPM, 2011
Pagina 5 of 12

6. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
testes e administradores de banco de dados
devem ser envolvidos neste processo.
2.4 - EAP / WBS: É o processo
responsável por Criar a EAP do projeto, e
contempla o processo de mesmo nome
contido no Guia PMBOK®. Deve ser iniciado
quando se tem materiais produzidos de
requisitos e escopo, devendo ser mantido ao
longo de todos os trabalhos de análise do
projeto.
Este é um dos principais documentos
de controle e acompanhamento do projeto,
pois mostra claramente e em forma gráfica
todos os pacotes de trabalho que precisarão
ser desenvolvidos ao longo do projeto.
A EAP (estrutura analítica do projeto),
geralmente é produzida pelo gerente do
projeto e pelos analistas que participaram do
processo 2.3. Declaração do escopo.
2.5 - Atividades: É o processo
responsável por identificar, listar e seqüenciar
as atividades do projeto. Contempla os
processos
Definir
as
atividades
e
Sequenciar as atividades contidos no Guia
PMBOK®.
O momento mais indicado para
realizar este processo é após os trabalhos de
análises estarem concluídos, ou seja, após a
realização dos processos 2.2, 2.3 e 2.4. No
entanto, quando o projeto é muito grande ou
complexo e possui muitos requisitos para
serem analisados e detalhados, os processos
desde o 2.2 até o 2.7 podem ser realizados
por ciclos de ondas sucessivas, ou seja, por
ciclos menores que permitam o entendimento
completo de pequenas partes do projeto, até
completarem todo o trabalho contratado.
Este processo pode ser realizado em
conjunto com os processos 2.6 e 2.7, e o ideal
é que toda a equipe participe destes trabalhos,
pois é o momento onde se inicia o
entendimento de como as tarefas serão
realizadas. Caso não for possível, pelo menos
os analistas e os desenvolvedores devem ser
envolvidos nesta etapa.
2.6 - Estimativas: É o processo
responsável por estimar os recursos e as
durações das atividades. Contempla os
processos Estimar os recursos das
atividades e Estimar as durações das
atividades contidos no Guia PMBOK®. O
momento mais indicado para realizar este
Confidencial
processo é após o processo 2.5, ou
juntamente com ele e com o processo 2.7.
Neste processo também é o ideal que
toda a equipe do projeto participe dos
trabalhos de estimativa, principalmente o time
que será envolvido nas realizações de
execução. Este é o momento que se entende
completamente as tarefas que serão
realizadas, e quais os esforços necessários
para completá-las.
2.7 – Cronograma: É o processo
responsável por Desenvolver o cronograma
do projeto e contempla o processo de mesmo
nome contido no Guia PMBOK®. O momento
mais indicado para realizar este processo é
após os processos 2.5 e 2.6, ou juntamente
com eles.
Geralmente o cronograma do projeto é
montado pela equipe de gerenciamento
durante os processos 2.5 e 2.6.
2.8 – Plano de comunicação do
projeto: É o processo responsável por
Planejar as comunicações do projeto e
contempla o processo de mesmo nome
contido no Guia PMBOK®. É geralmente
iniciado a partir dos trabalhos do processo 2.1,
e pode ser finalizado a qualquer momento
dentro do fluxo, sendo o mais importante e
fundamental que esteja concluído e distribuído
antes dos trabalhos de execução iniciarem.
Este processo deve ser realizado pelo
gerente do projeto.
Documentos de saída
Cada um dos processos descritos no
fluxo gera um ou mais documentos. Alguns
são obrigatórios e outros opcionais, além de
que alguns também são utilizados como
entradas de processos subsequentes.
Todos
os
documentos
são
necessários para um melhor entendimento e
gerenciamento do projeto, porém como alguns
são opcionais podem ser descartados de
acordo com o projeto em questão e
necessidades da equipe de gestáo. No
entanto, como regra, os documentos
obrigatórios possuem um propósito importante
no fluxo e devem ser gerados.
Como foi descrito nos elementos do
fluxo, e pode ser visualizado no próprio
desenho do fluxo da figura 1, cada processo
possui suas saídas, e estas podem gerar
©MundoPM, 2011
Pagina 6 of 12

7. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
documentos que são mostrados no fluxo com
números únicos de identificação, a exemplos
dos mostrados na figura 5.
Para entender quando e como cada
um dos documentos é gerado ao longo da
execução dos processos, acompanhe no fluxo
cada documento através de seu número, e
relacione-os com os números abaixo e
entenda para que cada um deles serve.
1 – Project Charter – Termo de
abertura do projeto: Documento obrigatório,
que tem o objetivo de oficializar o início do
projeto,
determinando
seus
objetivos,
requisitos de alto nível, cronograma macro,
responsáveis e equipe envolvida.
Documento em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
2
–
Registro
das
partes
interessadas – Stakeholders: Documento
obrigatório, que visa listar as partes
interessadas que devem ser consideradas
durante o projeto, identificando também seus
respectivos
interesses,
tais
como:
expectativas, influência, relacionamento e
finalidade no projeto.
Documento em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
3 – Plano de gerenciamento do
projeto: Documento obrigatório, que tem
como finalidade guiar a execução do projeto e
servir como base para o controle de todo o
projeto, incluindo as etapas de planejamento e
gerenciamento. É um forte aliado na melhoria
da comunicação e da clareza com os
stakeholders.
Este documento pode ser dividido em
pequenos planos menores de acordo com o
tamanho do projeto e o detalhe desejado em
cada área de gerenciamento.
Sugere-se que contenha no mínimo as
seguintes sessões: Objetivo do projeto, Ciclo
de vida do projeto, Processos aplicáveis ao
projeto, Ferramentas a serem utilizadas na
gestão,
Plano
de
gerenciamento
de
mudanças, Plano de gerenciamento de
configuração, Plano de gerenciamento de
requisitos e Plano de comunicação do projeto.
Documento em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
Confidencial
4 – Documento de detalhamento de
requisitos de alto nível: Documento
obrigatório, que visa elicitar e detalhar de
forma
resumida
todos
os
requisitos
identificados para serem atendidos pelo
projeto, e que compõem o produto objeto final
do projeto. O foco do detalhe deve ser sempre
o negócio do cliente.
Este documento deve ser dividido em
duas partes distintas: (1) Elicitação e (2)
Detalhamento.
Documentos em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
5 – Matriz de rastreabilidade de
requisitos: Documento obrigatório, que visa
ser uma tabela de ligação entre os produtos a
serem realizados pelo projeto, e os seus
requisitos
de
origem,
mantendo
um
rastreamento durante todo o ciclo de vida do
projeto. Tendo como principal objetivo ajudar a
garantir que cada requisito seja atendido e
resulte em um valor adicionado ao projeto.
Documentos em formato tabular,
utilizando ferramenta Microsoft Excel ou
similar. Sendo que uma das características
desta matriz é a ligação entre o requisito
identificado como necessidade, com as
funcionalidades ou realizações (e.g. telas,
relatórios, integrações, apresentações, testes,
manuais,
treinamentos)
que
serão
completadas para atender a cada requisito.
Com isso é fácil acompanhar os requisitos
atendidos e não atendidos conforme pode ser
visualizado na figura 8.
Figura 8 – Exemplo de Matriz de
rastreabilidade de requisitos
©MundoPM, 2011
Pagina 7 of 12

8. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
6 – Protótipos de tela e relatórios:
Documento obrigatório, que tem como objetivo
mostrar de uma forma clara e direta como as
telas e relatórios do sistema ficarão
visualmente, e como será o comportamento de
cada
um
após
a
implementação
(desenvolvimento) do sistema.
Não é necessário que seja um
protótipo navegável, mas deve representar
características e arquiteturas visuais, bem
como as regras envolvidas com
o
funcionamento da tela ou relatório, conforme
pode ser visualizado no modelo da figura 9.
(relacionamentos), assim como o modelo
mostrado na figura 10.
Figura 10 – Exemplo de modelo de dados
O dicionário de dados deverá ser um
complemento do MER, contendo um descritivo
de todas as características das tabelas e
campos.
Normalmente ferramentas como Erwin
e Microsoft Visio permitem o desenho do MER
e o complemento do dicionário. No entanto,
utilize a ferramenta de sua preferência.
Figura 9 – Exemplo de protótipo de tela
Este documento pode ser dividido em
dois ou mais documentos.
Uma sugestão para criar os protótipos,
é o Microsoft Visio, porém o envio ao cliente
pode ser no corpo de um documento textual
em Microsoft Word, permitindo inclusive a
complementação de textos explicativos com o
objetivo de descrever os funcionamentos mais
importantes, ou atípicos do protótipo.
7 – Modelo de dados relacional e
Dicionário
de
dados:
Documentos
obrigatórios. O modelo de dados relacional,
também conhecido como MER, deverá ser um
desenho do modelo de dados, explicitando
todas
as
tabelas,
seus
campos
e
características que o banco conterá, além de
suas
integridades
referenciais
Confidencial
8 – Declaração do escopo –
Especificacão
detalhada:
Documento
1
opcional , que tem o objetivo de ser um
descritivo detalhado do funcionamento das
telas do sistema, relatórios, integrações e
eventuais rotinas ou processos implícitos,
contendo descrições o mais detalhadas
possíveis, principalmente, e no mínimo de
regras
de
negócio,
comportamentos,
validações e resultados esperados.
Este é o momento de detalhar e
registrar os critérios de aceitação, riscos e
premissas identificadas, além do que está
contido nas entregas, e principalmente o que
será excluído do projeto. Muitas vezes este
último ponto não é registrado como deveria,
gerando problemas em aceitações formais de
entregas do projeto.
Geralmente estes documentos são
suficientes para detalhar todo o trabalho que
deve ser feito no projeto, mas caso seja
1
De acordo com a complexidade do sistema,
o detalhamento pode estar contido nos
protótipos, ou serem descritos em documentos
separados. Podendo ainda ser
complementado por Casos de Uso e/ou
diagramas de sequência, porém, estes
geralmente não são realizados para todas as
funcionalidades, apenas para as mais críticas
ou complexas.
©MundoPM, 2011
Pagina 8 of 12

9. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
necessário podem ser adicionados outros
como complementação, e sendo considerados
como exceção, e não como regra.
A documentação em excesso é tão
ruim e prejudicial quanto à falta dela.
Documento em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
9 – EAP: Documento obrigatório, a
estrutura analítica do projeto é uma
representação gráfica e visual de todo o
escopo do projeto, definido a partir da
declaração do escopo. Deve representar
graficamente todo o trabalho do projeto
conforme ilustrado na figura 11.
Figura 11 – Exemplo de uma EAP
Esta é a principal ferramenta de
controle do trabalho do projeto, e somente o
trabalho, que deverá ser realizado durante a
etapa de implementação do sistema.
A técnica utilizada para montar a EAP,
apoiada no Guia PMBOK®, é a transcrição da
definição do escopo, decomposta em pacotes
de trabalho que serão representados
graficamente na EAP. Estes pacotes
normalmente são decompostos em unidades
menores que ficam entre 8 e 80 horas. Como
sugestão, não devem ser definidos pacotes
menores que 8 horas, ou maiores que 80
horas. Ou se for de preferência, pode-se
utilizar as referências de 4 ou 40 horas,
respectivamente.
A EAP tem outra importância, que é a
primeira estimativa mais concreta do esforço
total do projeto. Pois, ao definir todos os
pacotes de trabalho, considerando a regra do
8/80, se obtêm o tamanho de todos os pacotes
de trabalho, e ao agregá-los debaixo para
cima na estrutura da EAP, se consegue a
primeira previsão de esforço de todo o
trabalho do projeto.
Uma boa ferramenta para se construir
a EAP é a WBS Chart Pro ou a Freemind.
Confidencial
10 – Dicionário da EAP e Linha de
base do escopo: Documentos obrigatórios. O
dicionário da EAP deve ser um descritivo
resumido dos pacotes de trabalho e suas
características, principalmente a diferenciação
dos pacotes por um número de identificação,
que poderá ser usado futuramente em
cronogramas, status reports e outros relatórios
de acompanhamento.
A linha de base do escopo, nada mais
é do que uma marcação de todo o escopo
definido até o momento. A sua maior
importância é determinar o fechamento de
uma parte, ou de todo, o escopo do projeto.
Feita esta marca, esta linha de base será
utilizada para o controle das mudanças de
escopo no projeto, podendo servir de base
para negociações de prazo, custo e qualidade,
além do próprio controle integrado de
mudanças.
Ambos os documento podem ter o
formato textual, utilizando ferramenta Microsoft
Word ou similar. Sendo que a linha de base do
escopo pode ser um documento em forma de
termo de aceite, com solicitação de assinatura
do
cliente,
confirmando
a
validade,
entendimento e aceitação do escopo
detalhada por todos os processos até este
momento.
11 – Lista de atividades e Diagrama
de
rede:
Documentos
opcionais,
principalmente porque podem estar contidos e
realizados
no
mesmo
momento
do
cronograma do projeto. A lista de atividades
deve ser uma decomposição dos pacotes de
trabalho da EAP em tarefas menores, que
definam de forma objetiva os trabalhos que
precisam ser realizados para completar os
pacotes de trabalho da EAP do projeto. Este
documento pode ser em formato textual,
utilizando
ferramenta
Microsoft
Word,
Microsoft Excel ou similar, ou diretamente no
Microsoft Project contendo uma lista simples,
enumerada e ligada aos pacotes de trabalho
para rastreabilidade e acompanhamento. O
diagrama de rede tem a função de determinar
o seqüenciamento das atividades, bem como
o relacionamento e a dependência entre as
atividades. O ideal para este documento é que
ele seja gráfico como mostrado na figura 12,
utilizando ferramentas como Microsoft Visio.
©MundoPM, 2011
Pagina 9 of 12

10. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
Este documento apesar de obrigatório
pode ser realizado em conjunto, e estar
contido no cronograma do projeto.
Figura 12 – Exemplo de diagrama de rede
Outra boa opção é o Microsoft
Project, onde o diagrama de rede é montado
automaticamente ao se listar as atividades, e
definir as dependências e seqüenciamentos
entre elas. É uma ferramenta interessante pela
sua praticidade de uso e pela possibilidade de
extração do Gráfico de Gantt que expressa
graficamente o diagrama de rede, como pode
ser visualizado na figura 13.
Figura 13 – Exemplo de lista de atividades
e diagrama de rede no Project
12 – Estimativa de duração das
atividades: Documento obrigatório. Uma
forma de estimar corretamente, se dá ao
decompor os pacotes de trabalhos da EAP em
atividades menores, determinar para cada
atividade sua estimativa de duração. Uma das
maneiras mais seguras de se estimar a
duração das atividades é a opinião
especializada, ou seja, reunir a equipe que irá
realizar a atividade, explicar todos os detalhes
conhecidos sobre a tarefa, sanar todas as
dúvidas que podem influenciar no tempo e no
esforço, e por fim deixar a própria equipe dizer
qual o tempo estimado para a realização da
atividade exposta. Com isso a estimativa se
torna mais assertiva, por ser definida em uma
granularidade menor, por ser determinada por
quem é especialista no trabalho envolvido, e
por permitir a aplicação da estimativa bottomup para se estimar a duração total do projeto.
A bottom-up define que a soma de todas as
estimativas
das
atividades
menores,
determinam a duração total dos pacotes de
trabalho, e ao somar os pacotes de trabalho,
se obtêm a duração total do projeto.
Confidencial
13 – Requisitos de recursos e EAR:
Documentos opcionais. No entanto, como
parte do processo se torna obrigatória a
identificação dos recursos necessários para
realizar os trabalhos do projeto, principalmente
as pessoas. Após a lista de atividades, e
conseqüente estimativa de duração das
mesmas, pode-se montar uma lista objetiva
dos recursos necessários para se completar
as tarefas do projeto. Lembrando que esta
lista de requisitos de recursos deve conter
todos os recursos necessários, tais como
pessoas, máquinas, equipamentos, software,
entre outros.
A lista de requisitos de recurso pode
ser um documento em formato textual,
utilizando
ferramenta
Microsoft
Word,
Microsoft Excel ou similar. O mais importante
é conter o nome ou descrição do recurso, o
tempo que ele será necessário, e em vários
casos o custo do recurso.
A Estrutura Analítica de Recursos
(EAR) complementa a lista de requisitos de
recurso, representando graficamente como os
recursos se relacionam e estão organizados,
principalmente
organizacional
e
hierarquicamente como pode ser visualizado
no modelo da figura 14.
Figura 14 – Exemplo de EAR
14 – Cronograma do Projeto:
Documento obrigatório. Com a lista de
atividades, o diagrama de rede, as estimativas
e os recursos, o cronograma do projeto pode
ser montado.
Para este processo, o cronograma
pode ser detalhado na mesma granularidade
da lista de atividades, ou em um nível superior
e mais macro, o de pacotes de trabalho.
Porém no mais macro, as atividades devem
ser controladas fora do cronograma, esta
estratégia diminui a complexidade de
manutenção do cronograma, e tira o controle
©MundoPM, 2011
Pagina 10 of 12

11. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
do projeto deste artefato, que deve apenas
permitir o acompanhamento das datas mais
importantes do projeto, evitando um controle
orientado a cronograma, que geralmente não
é saudável aos projetos.
Lembrando que o controle em
separado das atividades deve permitir que a
equipe do projeto saiba exatamente quais
atividades precisam ser completadas para que
o pacote de trabalho definido no cronograma
esteja concluído. Sendo que a duração da
estimativa do pacote de trabalho destacado
como item do cronograma deve ser a soma de
todas as atividades contidas no mesmo pacote
de trabalho.
informação de cada parte interessada,
definindo qual será o meio, a abordagem e a
freqüência das comunicações do projeto.
Sugere-se também como complemento,
descrever como será o funcionamento das
reuniões de comitê e de acompanhamento,
bem como o conteúdo e o propósito dos
relatórios de Status Report.
Documento em formato textual,
utilizando ferramenta Microsoft Word ou
similar.
De acordo com o tamanho do projeto,
pode estar contido como uma sessão no plano
de gerenciamento do projeto.
Discussões e Conclusões
15 – Dados do cronograma:
Documento opcional, que tem a finalidade de
apoiar o cronograma realizado, melhorando o
entendimento
de
informações
que
influenciaram na determinação de prazos,
marcos, paralelismos, antecipações, esperas e
outros detalhes contidos no cronograma.
Este documento deve conter no
mínimo os atributos das atividades, detalhes
sobre as premissas e restrições que
influenciaram no cronograma, além de
requisitos de recursos por período de tempo, e
principalmente cronogramas alternativos, tais
como melhor ou pior caso, prevendo a
ocorrências de riscos já identificados.
Comumente não são realizados
cronogramas alternativos, dificultando o acerto
na previsão de conclusão dos marcos
importantes do cronograma. Primeiro porque
uma estimativa é somente, e simplesmente,
uma previsão, segundo porque uma estimativa
não deve ser considerada, a grosso modo, um
compromisso de conclusão das atividades.
Este compromisso geralmente não é
cumprido,
principalmente
pelos
fatores
influenciadores de um projeto que podem ser
vários.
Neste
caso
os
cronogramas
alternativos podem ser uma opção, pois
ajudam a equipe do projeto a prever, estudar e
avaliar vários destes fatores influenciadores,
mitigando os riscos de erro de estimativa, e
conseguindo obter e divulgar previsões de
conclusão mais reais e assertivas.
16 – Plano de comunicação do
projeto: Documento obrigatório, que tem
como objetivo identificar quais são as
necessidades de comunicação do projeto,
visando determinar quais as necessidades de
Confidencial
Este fluxo tem por objetivo sugerir
uma forma de aplicar os processos do Guia
PMBOK®, em projetos de desenvolvimento de
software, e principalmente estimular a reflexão
sobre o uso de boas práticas de gestão de
projetos em pequenas e médias empresas.
As variáveis influenciadoras que
podem gerar falhas ou fracassos em projetos
de tecnologia da informação, são inúmeras e
muitas vezes imprevisíveis, principalmente
quando não se tem gerenciamento.
Um dos principais artifícios e uma das
maiores vantagens de se aplicar técnicas de
gerenciamento em projetos, é prever a
ocorrência dos fatores influenciadores, e este
fluxo propõe justamente a realização de
processos, e a aplicação de ferramentas e
técnicas que contribuem muito para atingir a
meta de antecipar os riscos na execução de
projetos.
A experiência do autor na execução
deste processo, com o objetivo de obter os
documentos destacados e listados aqui,
comprovam que a aplicação, mesmo que
resumida ou minimizada, de boas práticas
reconhecidas por entidades como o Project
Management Institute, contribuem muito para
melhorar o entendimento do que precisa ser
realizado para o projeto atingir seu objetivo,
influencia muito na clareza e na disseminação
das informações colhidas e registradas
durante o planejamento do projeto, e
aumentam a transparência dos papéis e
responsabilidades dos envolvidos no projeto,
trazendo mais comprometimento de todas as
partes interessadas no projeto, especialmente
o cliente.
©MundoPM, 2011
Pagina 11 of 12

12. Mundo
PM Project Management
Artigo publicado na revista
Out/Nov 2011
Número 41
Edição
“Sob o ponto de vista do analista de
negócio, houve clareza dos objetivos desde o
início do projeto, e a aplicação deste modelo é
viável, trazendo uma melhoria notável na
comunicação e no acompanhamento do
levantamento de requisitos, sendo que sua
eficiência pode ser medida pela satisfação do
cliente. (CORÁ, 2011)''
Além deste modelo de processo
sugerido, que é de fácil entendimento e
aplicação, o autor finaliza provocando os
interessados a realizar adaptações a este
modelo de acordo com os seus próprios
projetos, organizações e características de
negócio envolvidas. Lembrando que esta não
é a única forma de fazer e de obter um bom
resultado no gerenciamento de projetos, mas
sim,
uma
maneira
já
utilizada
e
comprovadamente eficiente.
http://fabiorcruz.wordpress.com/pmo/. [21
jul. 2011].
Agradecimento: Aos meus filhos, por me
amarem mesmo quando estou a frente do
computador estudando, escrevendo ou
deixando de dedicar mais tempo a eles.
Sobre o Autor:
Referências
1. Project Management Institute. Um guia do
conhecimento em gerenciamento de
projetos (Guia PMBOK®). 4.º Edição.
Editora Global Standard PMI, 2008.
2. Cruz, Fábio Rodrigues (2011). PMBOK ®.
FabioCruz.com.
Available:
http://fabiorcruz.wordpress.com/pmbok%c
2%ae/. [21 jul. 2011]
3. Cruz, Fábio Rodrigues (2011). PMO
Virtual.
FabioCruz.com.
Available:
Confidencial
©MundoPM, 2011
Fábio Cruz
fabiorcruz@gmail.com
Graduado na área de TI e PMP
certificado com mais de 17 anos de
experiência profissional, atuando
sempre na área de desenvolvimento de
sistemas, sendo os últimos 10 dedicados à
liderança de equipes e à coordenação de
projetos.
Experiência em projetos
internacionais, resolução de conflitos,
estabilização de projetos críticos,
negociações com clientes e ciclo de vida
de projetos.
Atualmente gerente de projetos
na empresa catarinense Paradigma
Business Solutions, voluntário no PMI
Chapter de Santa Catarina e mantenedor
do http://www.fabiocruz.com, um blog
especializado em gerenciamento de
projetos.
Pagina 12 of 12