1.

O Diagrama PERT
2. Diagrama de Gantt
3. Lista de Recursos

Todo engenheiro de software aprende a trabalhar sob significativa pressão do tempo. Parte da pressão provém
de prazos finais arbitrários, e às vezes irrealísticos, que são estabelecidos por quem não tem de construi o
produto. Mas parte da pressão é criada pelas pessoas que, em última análise, devem suporta-la.

Isto ocorre porque estes analisas acham que, como analistas, não deveriam ter conhecimento de técnicas de
gerência. Isto leva sempre aos mesmos erros, sendo que os mais comuns são :

• Um projeto é planejado e tem seu cronograma determinado casualmente, sem verificação de estimativas;
• Os riscos são considerados somente depois que eles se transformaram em problemas completos;
• As pessoas não são organizadas de uma forma que agilize o progresso.

Às vezes parece que, em nossa ansiedade para começar, não despendemos tempo para organizar nossas
ações ( em outras palavras, gerenciar o projeto ). Mas existem muitas razões por que você deveria se interessar
por ferramentas gerenciais de planejamento :

• Além de seu papel como analista de sistemas, você pode ser o gerente do projeto. Desse modo, você
mesmo pode desenvolver seus modelos gerenciais para apresentá-los aos níveis mais elevados da direção
ou pode solicitar a um dos seus subordinados que os desenvolva para você.
• Como o mais graduado técnico da equipe, o gerente do projeto pode solicitar-lhe que desenvolva
organogramas para ele. Nesse cenário, você pode ser o aprendiz de gerente de projeto.
• Mesmo que você não seja responsável pelo desenvolvimento dos modelos gerenciais, é importante
conhece-los, porque eles refletem a percepção da gerência sobre como esta o andamento dos trabalhos do
projeto.
• A organização do trabalho e a distribuição das pessoas para as diversas atividades, muitas vezes
conhecidas como a subdivisão do projeto, será habitualmente feita em paralelo com a subdivisão técnica do
projeto. Como você esta estreitamente envolvido com tudo isso, poderá Ter alguma influencia no modo
como o projeto será organizado.

Vamos apresentar algumas ferramentas de modelagem úteis para se gerenciar o projeto de desenvolvimento de
um sistema.

PRESSMAN, Roger S. Engenharia de Software. São Paulo : Makron Books, 1995.

1. O diagrama PERT
PERT é um acrônimo para Program Evaluation Review Technique. Essa técnica foi originalmente desenvolvida
nos anos 60 como uma ferramenta de gerenciamento para o projeto do submarino Polaris da Marinha dos EUA.

Os diagramas PERT tem sido amplamente usados em projetos industriais e governamentais desde então; muitos
os denominam atualmente de Diagramas de Atividades ou Redes de Tarefas.

Os diagramas PERT são compostos das seguintes figuras :

01/01/2000 Atividade - O retângulo representa uma tarefa ou atividade, isto é, uma parte
reconhecível do trabalho que precisa ser feito. A data que fica no alto do
quadrado, significa o dia em que aquela atividade deverá ser iniciada. O numero
que fica abaixo do quadrado significa o numero de dias que a atividade devera
demorar para ser completada.

05

Marcos de Referencia - Os quadros com cantos arredondados são conhecidos

como marcos. Eles servem para indicação regular do progresso do projeto. Um
marco de referencia é atingido assim que a documentação produzida como parte
de uma tarefa de engenharia de software é revisada e aprovada. Ela tem data
prevista para ser feita, que fica no alto do quadro.

Dependência - as linhas que interligam os quadros mostram as dependências

entre as tarefas. A natureza concorrente das atividades levam a uma necessidade
de determinar as dependências intertarefas para garantir o contínuo progresso
rumo à conclusão.

Caminho critico - as linhas mais grossas que formam um caminho continuo do

inicio ao fim do projeto representam o caminho critico, as atividades cujo prazo
atraso causará o atraso de todo projeto. As atividades fora do caminho critico tem
uma folga, elas podem ser iniciadas em data mais tardia que a prevista até o total
das folgas disponíveis, se assim for desejado, sem que isso ate o projeto inteiro.

Observe que o exemplo que será mostrado a seguir é bastante trivial, ele contem apenas dez atividades e
termina quando a atividade de analise de sistemas começa. Um projeto típico, naturalmente, prossegue após a
conclusão da atividade de analise de sistemas e despende um considerável volume de tempo na área de projeto,
codificação, teste, etc.

Na realidade um projeto típico terá provavelmente algumas centenas de atividades que serão mostradas em um
diagrama PERT. Um aspecto da maior importância e que a maioria dos projetos identifica as principais
atividades que são depois subdivididas em outras menores.

Por exemplo, a atividade "Conduzir atividade de analise de sistemas", como já podemos deduzir pelas apostilas
anteriores, é composta de inúmeras sub-atividades. Deveremos então, ter um diagrama PERT dedicado a
detalhar estas sub-atividades.

Assim, do mesmo modo como vimos o conceito de diagramas de fluxo de dados em níveis, podemos imaginar o
conceito de diagramas PERT em níveis para auxiliar a organizar a complexidade de muitas centenas, ou talvez
de milhares, de atividade de um grande projeto.
Exemplo de Diagrama PERT :

04/01/2000
Falar com
representante
s do usuário 11/01/2000
Visitar 01/02/2000
06 instalações Conduzir
do usuário atividades de
analise de
02 sistemas
25
04/01/200 01/02/2000 29/02/2000
0 01/02/2000
Apresentar10 Investigar Apresentar
Inicio resultados
estudo de alternativa
viabilidade da análise
s
de sistemas
10financeiras
04/01/2000
Desenvolver 01/02/2000
aspectos
Rever
iniciais do
procedimento
projeto s reguladores
20
10

Observe ainda que o diagrama PERT focaliza as atividades e interdependências entre as atividades, mas
informa pouco ou nada sobre muitos outros aspectos :

• que pessoa ou grupo de pessoas deve executar as diversas atividades;

• qual o tempo ( ou numero de homens-dias ) que cada atividade exige;
• quais produtos ou saídas são fornecidos em cada atividade;
• o diagrama PERT não contempla a possibilidade de volta a uma atividade anterior no caso de serem
encontrados problemas em algum estagio posterior.

Por outro lado, o diagrama PERT mostra com clareza, o fato de que muitas atividades podem ocorrer em
paralelo em um projeto do mundo real. Isso é importante, porque muitos dos outros modelos do projeto dão a
entender que as atividades devem ocorrer de modo seqüencial ( lembre-se do diagrama que representa o ciclo
de vida clássico ).

Os gerentes de projeto geralmente querem tirar o máximo proveito possível da possibilidade de atividades serem
desenvolvidas em paralelo, uma vez que ele pode abreviar o tempo necessário para o projeto.

O diagrama de Gantt também é conhecido como linha cronológica de tarefas. O diagrama de Gantt apresenta
quase o mesmo tipo de informações que o diagrama PERT, a principal diferença e que ele mostra a duração de
cada atividade de uma maneira mais clara.

Os diagramas de Gantt são compostos das seguintes figuras :

Atividade - O retângulo branco representa uma tarefa ou atividade com sua

duração definida pelo extensão da figura.
 Folga na atividade - O retângulo mais escuro representa a folga que ainda há
para o termino de certa tarefa.

Marcos de Referencia - Os diamantes são os marcos de referencia. Eles servem

para indicação regular do progresso do projeto.

Exemplo de Diagrama de Gantt :

01/01 10/01 20/01 01/02 10/02 20/02 01/03

Inicio
Falar com representantes do usuário
Desenvolver aspectos iniciais do projeto
Visitar instalações do usuário
Apresentar estudo de viabilidade
Rever procedimentos reguladores
Investigar alternativas financeiras
Conduzir atividades de analise de sistemas
Apresentar resultados da analise de sistemas

!"
A lista de recursos é o diagrama de Gantt modificado, que mostra qual o recurso disponível para realização de
cada atividade prevista.

Exemplo de Lista de Recursos :

01/01 10/01 20/01 01/02 10/02 20/02

C 01/03 Inicio
a
r Falar com representantes do usuário
o
l

B Desenvolver aspectos iniciais do projeto

e
t Apresentar estudo de viabilidade
h
Rever procedimentos reguladores
Investigar alternativas financeiras
D Visitar instalações do usuário
a
v Apresentar estudo de viabilidade
i
d Conduzir atividades de analise de sistemas

M Visitar instalações do usuário

a
r Conduzir atividades de analise de sistemas
i Apresentar resultados da analise de sistemas
a
Há um antigo ditado que diz : "Os projetos atrasam-se em seu cronograma um dia de cada vez". O atraso de um
dia na programação raramente será fatal para um projeto. Mas os dias se somam e, ao longo da extensão de um
projeto, pequenos atrasos podem resultar em grandes problemas.

Existem diversas atividades que o gerente de projeto de software pode realizar para evitar os atrasos :

• Realizar reuniões periódicas sobre a situação do projeto, em que cada membro da equipe relate o progresso
e os problemas;
• Avaliar os resultados de todas as revisões levadas a efeito ao longo do processo de desenvolvimento;
• Determinar se os marcos de referencia de projeto formais foram atingidos ate a data programada;
• Comparar a data de inicio real com a data de inicio planejada para cada tarefa de projeto relacionada na
tabela de recursos;
• Reunir informalmente com profissionais para se obter suas avaliações subjetivas do progresso até o
momento e os problemas que aparecem no horizonte.

O controle é empregado por um gerente de projetos de software para administrar os recursos do projeto,
enfrentar problemas e dirigir o pessoal de projeto.

Mas, quando ocorrerem problemas, o gerente de projetos deverá exercer o controle para saná-los o mais
rapidamente possível.

Depois que o problema tiver sido diagnosticado, recursos adicionais podem ser concentrados na área de
problema; o pessoal pode ser novamente disposto ou a lista de recursos, redefinida.