PLANEJAMENTO DE

PROJETO
PROF. RAUL SIDNEI WAZLAWICK
UFSC-CTC-INE
2010

CONTEXTO

Modelo de Processo (ciclo de vida)

Processo

Projeto

Como planejar um projeto no contexto de um

processo.

PLANO DE PROJETO

O objetivo do planejamento de projeto criar um

plano para o projeto como um todo

possivelmente mais detalhado para a fase ou ciclo

inicial.

Entre outras coisas, importante que o

responsvel por este planejamento utilize as
melhores ferramentas possveis para avaliar a
quantidade de esforo a ser despendido no projeto
como um todo e, possivelmente tambm, nas
atividades iniciais.

Tal estimativa poder dar origem tanto ao
cronograma do projeto quanto estimativa de
custo total do projeto.

Com o plano de projeto em mos, o gerente de

projeto poder ento atribuir responsveis s
tarefas previstas e verificar se so executadas nos
prazos produzindo os artefatos esperados.

Dependendo do ciclo de vida adotado, o plano de

projeto poder ser:
altamente detalhado j no incio (modelos estilo
Cascata)

ou um plano genrico de fases e um plano detalhado
apenas para o prximo ciclo ou iterao (mtodos
geis e Processo Unificado).

ATIVIDADES DE PLANEJAMENTO DO
PROJETO

Estabelecer os objetivos do projeto ou iterao.

De acordo com o processo definido e caractersticas do projeto

especfico, fazer o inventrio das tarefas necessrias para atingir
os objetivos, estimando o tempo para a realizao de cada tarefa.

De acordo com a descrio da tarefa dada pelo processo,

identificar os responsveis por cada tarefa (equipe).

Da mesma forma, identificar os recursos necessrios para realizar

cada tarefa.

De acordo com o workflow das tarefas, identificar as dependncias

entre elas. Essas dependncias usualmente ocorrem quando as
entradas de uma tarefa so as sadas de outras.

Construir o diagrama PERT para o projeto ou iterao,

encontrando o caminho crtico.

Construir o cronograma do projeto, usualmente com um diagrama

Gantt.

Estimar o custo de cada tarefa e do projeto ou iterao como um

todo.

OBJETIVOS DO PROJETO OU ITERAO

Inicialmente o planejador de um projeto deve
estabelecer quais so os objetivos finais do
projeto.

O produto nem sempre apenas o software
funcionando.

Outros elementos podem ser necessrios ou
desejveis.

Sem definir claramente onde o projeto vai chegar
muito difcil estabelecer um bom plano.

Como escolher o caminho se no se sabe onde se quer

estar?

Infelizmente, muitos planejadores de projetos
esquecem-se desta importante etapa.

O objetivo de um projeto ou iterao deve ser

sempre um conjunto de artefatos, ou seja, coisas
palpveis, que se possa pegar e dizer isso
aqui.

Um objetivo no pode ser descrito como executar
tal ao, porque isso no define um artefato
palpvel.

Gerar tal diagrama ou tal relatrio, seria muito
mais adequado neste sentido, ou ainda
implementar este e aquele requisitos.

OBJETIVOS NOS MTODOS GEIS

Se estiver trabalhando com um mtodo gil, os

objetivos da iterao sero definidos pelas
histrias de usurio ou requisitos a serem
implementados.

TIPOS DE OBJETIVOS NO UP:

Implementar total ou parcialmente um ou mais
casos de uso.

Mitigar um risco conhecido, gerando ou
executando um plano de reduo de
probabilidade, reduo de impacto ou ainda de
recuperao de desastre.

Implementar total ou parcialmente uma ou mais
modificaes solicitadas.

A medida que a arquitetura do sistema evolui nas

iteraes, modificaes podero ser solicitadas em
funo da no adequao aos requisitos ou ainda
mudana destes.

Incorporar ao software estas solicitaes de mudana
pode ser ento um dos objetivos de uma iterao.

INVENTRIO DAS TAREFAS (WBS)

A WBS (Work Breakdown Structure) uma
estrutura que apresenta as tarefas que devem ser
executadas para atingir os objetivos
determinados para o projeto ou iterao
(Tausworthe, 1980).

Vrias resolues de trabalho do Governo Norte
Americano exigem a apresentao de uma WBS
para a execuo de um projeto.

Se for usado um ciclo de vida prescritivo, os

workflows vo indicar quais as tarefas a serem
executadas e quais as dependncias entre elas.

Dependendo do processo adotado o workflow
poder at indicar formas de estimao de esforo
para cada tarefa.

Se for usado um mtodo gil, recomenda-se que a

equipe decida sobre as tarefas a serem
desenvolvidas.

Isso no impede que equipes usando mtodos
geis se baseiem em workflows existentes, se o
grupo entender que isso poder ser til ao
projeto.

Seja qual for o modelo de processo adotado, a

WBS pode ser definida em uma reunio de
planejamento com toda a equipe, para que as
vrias vises do projeto sejam pesadas no
momento de estabelecer tarefas e estimar esforo.

 importante que cada tarefa caracterize muito

bem o produto de trabalho ou artefato de sada a
ser entregue ao seu final.

Se um processo for usado, o prprio processo j
vai estabelecer quais artefatos so estes.

A WBS uma estrutura exaustiva, ou seja, ela

deve incluir todas as tarefas necessrias para a
execuo do projeto ou iterao.

A WBS poder ser estruturada com uma rvore,
sendo que tarefas podem ser aglutinadas ou
detalhadas e estabelecendo uma rvore de
decomposio entre elas.

As tarefas nas folhas desta rvore so as tarefas
terminais e estas devem seguir a regra 8-80
especificada adiante.

PLANEJE ARTEFATOS, NO AES

muito importante que o planejador do projeto
planeje artefatos de sada e no meramente
aes.

Tarefas devem necessariamente produzir algo
fsico e no apenas a execuo de aes por parte
do responsvel ou participantes.

Tentar modelar um projeto baseado em aes vai
necessariamente levar a um detalhamento
excessivo das atividades e conseqentemente
impossibilidade de gerenciar adequadamente o
trabalho.

Estilos de WBS que prevem diferentes estgios

de um artefato (por exemplo, verso inicial,
verso intermediria e verso final), devem
caracterizar exatamente o que esperam de cada
uma destas verses.

REGRA 8-80

Tarefas que se estima, levaro muito tempo para serem

completadas, devem ser quebradas em tarefas menores.

No se deve ter tarefas com durao muito longa porque
fica muito difcil gerenci-las e acompanhar seu
andamento.
Tarefas que se estima levaro pouco tempo, devem ser
aglutinadas com outras.

No se deve ter tarefas muito curtas porque
microgerenciar essas tarefas minsculas pode provocar
um overhead de gerenciamento que ao invs de ajudar
vai atrapalhar o projeto.
A Regra 8-80 estabelece que nenhuma tarefa deve durar
mais de 80 horas (duas semanas, ou dez dias de trabalho
ideais), nem menos de 8 horas (um dia de trabalho ideal).

REGRA DOS NVEIS

A estruturao de uma boa WBS no deve ter

mais de 3 ou 4 nveis de decomposio.

REGRA DO NMERO DE TAREFAS

O nmero total de tarefas terminais em uma

WBS no deve ultrapassar o limite de 100 a 200
elementos.

TAMANHO MXIMO DE PROJETO

GERENCIVEL

Considerando-se que cada tarefa poder ter no mximo 80 horas,

essa regra estabelece que um projeto gerencivel dever ter no
pior dos casos 80x200 = 16000 horas de trabalho.

Qualquer projeto com carga horria maior do que essa deve

necessariamente ser subdividido em projetos menores.

Neste sentido, as iteraes de duas semanas dos mtodos geis e

do UP garantem que o nmero de horas total nunca seja muito
grande.

Sero apenas 80 horas de atividade por funcionrio.

Seriam necessrios 200 funcionrios trabalhando numa
iterao para se atingir tal limite.

Neste caso tambm seria altamente recomendvel a
subdiviso da equipe em equipes menores.

Os mtodos geis usualmente no operam bem com equipes
to grandes.

REGRA DOS 100%

A regra dos 100% estabelece que uma WBS deve
incluir 100% de todo o trabalho que deve ser feito
no projeto ou iterao.

Nenhum artefato ser produzido se no estiver
definido como sada de alguma das tarefas da
WBS e nenhuma tarefa deixar de produzir
algum artefato de sada.

A regra dos 100% vale em todos os nveis da
hierarquia de decomposio da WBS.

Alm disso, quando uma tarefa se decompe em

subtarefas, o trabalho definido pela tarefa ser
exatamente igual a 100% do trabalho definido nas
subtarefas.

IDENTIFICAO DE RESPONSVEIS POR

TAREFAS

Um processo usualmente define que o responsvel por uma

tarefa um perfil, ou seja, uma pessoa com uma ou mais
habilidades desejveis.
Quando um projeto for instanciado a partir deste processo
deve-se ento atribuir as tarefas a pessoas reais que
atendam a este perfil desejado sempre que possvel.
Cada tarefa do WBS dever ser atribuda a um ou mais
responsveis.
Essas atribuies podero ter efeito sobre o cronograma de
projeto, pois embora certas tarefas possam ser executadas
em paralelo, no possvel faz-lo assim caso estejam
atribudas ao mesmo responsvel.

IDENTIFICAO DO RECURSOS E CUSTO

possvel que a maioria das tarefas a serem
executadas, alm de recursos humanos
(responsveis e participantes) tambm tenham
recursos fsicos consumveis ou no consumveis a
serem alocados.

No momento do planejamento do projeto
necessrio prever o uso destes recursos.

O custo de uma tarefa individual ser ento o
custo das pessoas que se dedicam a ela somado ao
custo dos recursos alocados.

Somando-se os custos de todas as tarefas pode-se
estimar o custo total do projeto ou iterao
tambm.

ESTUDO DE VIABILIDADE
A partir da estimativa de custos pode-se decidir
se vale a pena desenvolver o projeto, ou seja, se
os benefcios a serem obtidos justificam os custos
com que se vai ter que arcar.

Se o estudo de viabilidade concluir que o projeto
impraticvel, pode-se cancel-lo ou ainda muda
seus objetivos, de forma a chegar a um projeto
mais enxuto e mais vivel.

IDENTIFICAO DE DEPENDNCIAS ENTRE

TAREFAS
A partir da estimativa de custos pode-se decidir
se vale a pena desenvolver o projeto, ou seja, se
os benefcios a serem obtidos justificam os custos
com que se vai ter que arcar.

Se o estudo de viabilidade concluir que o projeto
impraticvel, pode-se cancel-lo ou ainda muda
seus objetivos, de forma a chegar a um projeto
mais enxuto e mais vivel.

REDE PERT
O grafo de dependncias entre tarefas com a
durao prevista para cada tarefa constitui-se na
rede PERT do projeto ou iterao.

H vrias ferramentas que permitem a
elaborao quase automtica de um diagrama
PERT.

Nos exemplos adiante os grficos foram gerados
com a ferramenta free OpenProj.

http://openproj.org/

WBS NO OPENPROJ

WORKFLOW QUE DEU ORIGEM AO WBS

ANTERIOR

REDE PERT PARA A WBS

CAMINHO CRTICO

Um conceito importante no diagrama PERT o caminho

crtico, que consiste no mais longo caminho que leva do
incio ao fim do projeto.
Esse caminho crtico importante porque se qualquer
atividade prevista nele atrasar, por algum motivo, todo o
projeto ir atrasar.
Este o caminho sem folga.
As tarefas, entretanto, que no pertencem ao caminho
crtico podem atrasar at um certo limite sem prejuzo ao
projeto como um todo.
Na figura anterior as atividades do caminho crtico so
mostradas em vermelho.
As atividades que no esto no caminho crtico so
mostradas em azul.

Quando uma tarefa do caminho crtico atrasa

necessrio acelerar alguma atividade posterior no
caminho crtico para manter o projeto dentro do
cronograma.

FORMAS DE RECUPERAR UM CRONOGRAMA

ATRASADO

Aumentar a jornada da equipe (o que no pode se

transformar em rotina).
Aumentar o tamanho da equipe (o que pode causar
transtornos de gerncia em funo da colocao de pessoas
novas no projeto, possivelmente com menos experincia).
Eliminar algumas atividades ou tarefas inteiras do projeto
(nem sempre possvel devido s dependncias, mas s
vezes possvel reduzir a quantidade de elementos
abordados em uma tarefa. Por exemplo, ao invs de
implementar 3 casos de uso, caso haja atrasos, implementase apenas 2, deixando para outra iterao a implementao
do terceiro).

CRONOGRAMA DO PROJETO
O cronograma do projeto usualmente mostrado
em um diagrama Gantt, que consiste em uma
visualizao do tempo linear transcorrido e a
ocorrncia das diferentes tarefas ao longo deste
tempo.

Em relao ao diagrama PERT, o diagrama
Gantt apresenta o andamento das atividades ao
longo de uma linha de tempo permitindo
visualizar claramente quais atividades devem
estar sendo executadas a cada dia.

DIAGRAMA GANTT

BIBLIOGRAFIA

Tausworthe, R. C. (1980). The Work Breakdown

Structure in Software Project Management.
Journal of Systems and Software. 1(1979-1980):
181-186. Elsevier.