Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06

para esse documento é descrita na Figura 4.1. 
Figura 4.1: Estrutura de um plano de projeto 
Planejamento e Gerenciamento de Projetos de Software 
 
41
4.2.2 A Seleção de Pessoal 
Nem sempre é possível conseguir as pessoas ideais para trabalharem num 
projeto devido a limitações, tais como: 
• Orçamento de projeto pode não permitir o uso de pessoal altamente 
qualificado e, conseqüentemente, bem pago; 
• Pessoal com experiência apropriada pode não estar disponível; 
• Pode fazer parte da política da organização desenvolver as habilidades dos 
empregados durante um projeto de software. Ou seja, projetos podem ser usados 
como forma de treinar o pessoal. 
Assim, gerentes têm de alocar o pessoal disponível, dentro das restrições 
impostas. Muitas vezes, também é papel do gerente participar da seleção para a 
contratação de pessoal para um projeto. 
4.2.3 O Gerenciamento de Riscos 
Um risco é uma probabilidade de que alguma circunstância adversa aconteça. O 
gerenciamento de riscos trata da identificação dos riscos e da preparação de planos 
para minimizar os seus efeitos no projeto. Riscos podem ser classificados de acordo 
com vários critérios. Uma possível classificação seria: 
• Riscos de projeto: afetam cronogramas ou recursos; 
• Riscos de produto: afetam a qualidade ou desempenho do software que é 
desenvolvido; 
• Riscos de negócio: afetam a organização que está desenvolvendo ou 
adquirindo o software. 
O processo de gerenciamento de riscos pode ser dividido nas seguintes 
atividades: 
• Identificação dos riscos: identificar os riscos de projeto, produto e negócio. 
Esses riscos podem estar associados à escolha da tecnologia, das pessoas, 
mudanças de requisitos, estimativas do projeto etc.; 
• Análise dos riscos: avaliar a probabilidade e as conseqüências dos riscos. 
Uma possível classificação para a probabilidade e para as conseqüências pode 
ser: 
Probabilidade: muito baixa, baixa, moderada, alta ou muito alta. 
Conseqüência: catastrófica, séria, tolerável ou insignificante; 
• Planejamento dos riscos: preparar planos, definindo estratégias para 
gerenciar os riscos. As estratégias podem ser: 
EDITORA - UFLA/FAEPE – Introdução à Engenharia de Software e Qualidade de Software 
 
42 
- Estratégias para evitar o risco: a probabilidade de que o risco surja é 
reduzida. 
- Estratégias para minimizar o risco: O impacto do risco no projeto ou no 
produto será reduzido. 
- Planos de contingência: se o risco surgir, os planos de contingência 
tratarão aquele risco; 
• Monitoramento dos riscos: monitorar os riscos ao longo do projeto. Avalia 
cada risco identificado regularmente para decidir se ele está se tornando menos 
ou mais provável. Também avalia se as conseqüências do risco têm se 
modificado. Cada risco-chave deve ser discutido nas reuniões de progresso do 
gerenciamento. 
4.2.4 A Definição das Atividades, Marcos de Referência e Produtos Entregues ao 
Usuário 
Associados às atividades, podem existir marcos de referência (“milestones”) ou 
produtos. Um marco de referência é um ponto final, bem definido, de uma etapa ou 
atividade. A escolha dos marcos de referência e das suas freqüências de produção 
está relacionada ao modelo de ciclo de vida utilizado no projeto. Por exemplo, num 
projeto desenvolvido utilizando o ciclo de vida em cascata, ao final de cada etapa de 
desenvolvimento, pode haver um marco de referência. Nesse caso, um possível marco 
de referência seria o modelo de análise e projeto, o qual seria produzido ao final da 
etapa de mesmo nome. 
Os marcos de referência podem ser também associados à conclusão de uma 
atividade. Nesse caso, um marco de referência associado a uma atividade da etapa de 
análise e projeto poderia ser a produção de um diagrama específico do modelo, como, 
por exemplo, um diagrama de classes, produzido por uma atividade associada a essa 
etapa de desenvolvimento. 
Por outro lado, um produto a ser entregue ao cliente (“deliverable”) diferencia-se 
do marco de referência justamente pelo fato de que nem todos os marcos de 
referência são entregues ao cliente. Ou seja, produtos são marcos de referência, mas 
marcos de referência não são necessariamente produtos. 
4.2.5 A Definição do Cronograma 
O cronograma divide o projeto em tarefas e estima o tempo e os recursos 
requeridos para completar cada tarefa. Sempre que possível, devem ser definidas 
tarefas concorrentes de modo a fazer o melhor uso do pessoal. Outra premissa que 
deve ser levada em conta é tentar definir as tarefas que são independentes umas das 
outras. Isso evita atrasos causados por uma tarefa que está esperando por uma outra 
Planejamento e Gerenciamento de Projetos de Software 
 
43
ser completada. No entanto, a definição de bons cronogramas depende da intuição e 
da experiência dos gerentes de projeto. Ou seja, não existe uma ciência exata que 
determine a melhor forma de se construir um cronograma. Dentre os principais 
problemas relacionados à confecção de um cronograma, pode-se citar: 
• Estimar o esforço associado à resolução dos problemas e, 
conseqüentemente, o custo do desenvolvimento de uma solução é difícil; A 
produtividade não é proporcional ao número de pessoas que estão trabalhando 
numa tarefa; 
• Adicionar pessoas a um projeto atrasado pode fazer com que ele se atrase 
ainda mais. Isso ocorre devido ao overhead da comunicação; 
• O inesperado sempre acontece. Sempre permita a contingência no 
planejamento e uma “folga” no cronograma; 
• As tarefas não devem ser muito pequenas, de modo que não haja uma 
interrupção constante dos desenvolvedores pelo gerente do projeto. Assim, é 
recomendado que as tarefas tenham a duração entre uma e duas semanas. 
4.3 A GERÊNCIA DE PROJETOS SOB A ÓTICA DO PMBOK 
Ao se abordar o planejamento e a gerência de projeto não se pode deixar de citar 
o PMBOK – Project Management Body of Knowledge, criado pelo PMI – Project 
Management Institute. 
O PMI (www.pmi.org) é uma associação de profissionais de gerenciamento de 
projetos que existe desde 1969. Essa associação criou em 1986 a primeira versão do 
PMBOK – Project Management Body of Knowledge. O PMBOK é um guia que 
descreve a somatória de conhecimento e as melhores práticas dentro da profissão de 
gerenciamento de projetos. É um material genérico que serve para todas as áreas de 
conhecimento, ou seja, tanto para construção de um edifício como para a produção de 
software. 
A meta do gerenciamento de projetos, segundo o PMBOK é conseguir exceder 
as necessidades e expectativas dos stakeholders7. Todavia, satisfazer ou exceder 
essas necessidades envolve um balanceamento entre as várias demandas 
concorrentes em relação a: 
• Escopo, tempo, custo e qualidade (objetivos do projeto); 
• Stakeholders com necessidades e expectativas diferenciadas; 
• Requisitos identificados (necessidades) e requisitos não identificados 
(expectativas). 
 
7 O PMBOK [PMBOK2000] define stakeholders como sendo os indivíduos ou as organizações que estão ativamente 
envolvidos em um projeto, cujos interesses podem afetar positivamente ou negativamente o resultado da execução 
do projeto. 
EDITORA - UFLA/FAEPE – Introdução à Engenharia de Software e Qualidade de Software 
 
44 
O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos 
em cinco grupos (Figura 4.2): processos de inicialização, processos de planejamento, 
processos de execução, processos de controle e processos de finalização. 
 
 
 
 
 
 
Figura 4.2: Processos do gerenciamento de projetos do PMBOK 
Os processos de inicialização autorizam o início do projeto ou de uma fase do 
projeto. Os processos de planejamento definem e refinam os objetivos do projeto 
selecionando as melhores alternativas para realizá-lo. Os processos