ApostilaGP_UniAcademia2022_2

Prévia do material em texto

1 
Centro Universitário - Academia 
Curso Bacharelado em Sistemas de Informação e 
Engenharia de Software 
 
 
 
 
 
Gestão de 
Projetos 
 
 
 
 
 
 
 
 
 
 
Prof. Carlos Alberto Ribeiro 
Versão 2022/2 
 2 
Bibliografia 
 
1. Fernandes, Aguinaldo Aragon 
Gerência de Software através de Métricas. 
Editora LTC. 1995 
 
2. Vargas, Ricardo Viana 
Gerenciamento de Projetos - Estabelecendo um diferencial 
Competitivo. 
Editora Brasport, 2000 
 
3. Martins, José Carlos Cordeiro 
Gestão de projetos de desenvolvimento de Software 
Editora Brasport, 2002 
 
4. Vieira, Marconi Fábio 
Gerenciamento de Projetos de Tecnologia da Informação 
Editora Campus, 2007 
 
5. Quadros, Moacir. 
Gerência de Projetos de Software, Técnicas e ferramentas 
Editora Visual Books, 2002 
 3 
 
6. Molinari, Leonardo 
Gestão de Projetos, Técnicas e Práticas com ênfase em WEB. 
Editora Érica, 2004 
 
7. Rocha, Ana Regina Cavalcanti 
Qualidade de Software, Teoria e Prática. 
Editora Prentice Hall, 2001 
 
8. Pressman, Roger S. 
Engenharia de Software. 
Editora McGraw-Hill, 2011 
 
9. Vargas, Ricardo Viana 
Microsoft Project 2000. 
Ed. Brasport, 2000 
 
10. Boehm, Barry w. 
Software Cost Estimation with cocomo II. 
Ed. Prentice Hall, 2000 
 
 4 
Visão Geral 
1 - Gerenciamento dos Recursos de Informações 
1.1 - O ambiente de Análise e Desenvolvimento de Sistemas 
1.2 - Problemas no Desenvolvimento de Sistemas 
1.3 - Gerência de Projeto de Sistemas 
1.4 – Conceito de Projeto e Gerenciamento Projeto 
1.5 – Modelo de Gerência, Práticas Gerenciais 
 
2 – Gerenciamento de Projetos com o PMI(Project 
Management Institute) 
2.1 – Os envolvidos no Projeto 
2.2 – O PMBOK Guide 
2.3 – O PMP (Project Management Professional) 
2.4 – O PMO (Project Management Office) 
2.5 – Estudo Áreas de conhecimento e dos Processos da 
Gerência de Projetos 
 
3. Análise e Gestão de Riscos 
3.1 – Conceito de análise e gestão de riscos 
 3.2 – Estratégias de prevenção de riscos 
 3.3 – Identificação, avaliação, componentes e fatores de risco 
 3.4 – Avaliação, impacto e probabilidade do risco 
3.5 – Previsão de Risco 
3.6 – Atenuação, Monitoração e Administração de Risco 
 
4 - Planejamento de Projetos 
4.1 - Modelos Algoritmos 
4.2 - Método Baseado no julgamento de Especialistas 
4.3 - Método Baseado em analogias 
 
5 - Métodos de Estimativas de Esforço, Prazo, Custo de 
Projetos de Sistemas. 
5.1 - Método COCOMO (COnstrutive COst MOdel) 
5.2 - Método Análise de Pontos de Função (F.P.A.) 
5.3 - Análise Comparativa dos Métodos 
 
 5 
 
6 - Softwares de Gerenciamento de Projetos. 
 6.1. Microsoft Project, OPENPROJ, Primavera 
 6.2. Estudo de Caso usando o OPENPROJ 
 
7 - Trabalhos Específicos 
7.1 – Proposta de Desenvolvimento 
7.2 – Especificação de Requisitos 
 
8 - Anexos 
 8.1 – Tabelas 
 8.2 – COCOMO II 
 8.3 - UCP (Use Case Points) 
 8.4 – Comparação FPA e UCP 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 6 
1. O GERENCIAMENTO DOS RECURSOS DA INFORMAÇÃO 
 
RELACIONAMENTO 
ANALISTA SISTEMAS 
E USUÁRIO 
 
GERÊNCIA DE 
PROJETOS 
RELAÇÃO 
CUSTOS X 
BENEFÍCIOS 
LIMITAÇÕES DE 
SOFTWARE E 
HARDWARE 
ADMINISTRAÇÃO 
DE DADOS 
RELACIONAMENTO 
ANALISTA DE 
SISTEMAS E 
PROGRAMADORES 
 
“CULTURA” 
ORGANIZACIONAL 
AFERIÇÃO DE 
PROGRESSO 
DO PROJETO 
TÉCNICAS, 
 FERRAMENTAS 
E 
METODOLOGIAS 
PRAZO DE 
IMPLANTAÇÃO 
CONSTRUÇÃO 
DE UM 
SISTEMA DE 
INFORMAÇÃO 
 7 
1.1. O Ambiente de Análise e Desenvolvimento de 
Sistemas 
A construção de sistemas de informações (Análise e Projeto) 
tem sido realizada, tradicionalmente, mediante a ação dos 
seguintes componentes básicos: 
 
 O problema/necessidade a ser solucionado (a); 
 O Usuário, técnico da área que conhece o problema, mas 
não sabe especificá-lo e transformá-lo numa solução em 
termos de processamento de dados; 
 O Analista de Sistemas/Métodos, que conhece metodolo-
gias de abordagem de sistemas; 
 O Programador de Computador, especialista em lingua-
gens capazes administrar os recursos computacionais 
para a solução do problema; 
 O Gerente de Projetos/Desenvolvimento, que mantém a 
coordenação, o comando e o controle de projetos; 
 A Cúpula da Empresa, que estabelece as diretrizes sobre 
o uso da informática (prioridade, recursos, prazos, 
etc...); 
 O conjunto de metodologias, técnicas e ferramentas, 
que apoiam e orientam o desenvolvimento das soluções 
projetadas; 
 O conjunto de arquivo de dados, que constituem a 
principal ferramenta de uso das pessoas na empresa; 
 O conjunto de Hardware necessário ao processamento, 
armazenamento e comunicação de dados; 
 O prazo de implantação, fato gerador de tensões e 
expectativas. 
 
 8 
Este espectro de componentes humanos, físicos, cognitivos 
e tecnológicos corresponde ao ambiente de desenvolvimento 
de sistema, onde muitos problemas existem por uma série de 
fatores a seguir descritos. 
1.2. Problemas no Desenvolvimento de Sistemas 
No ambiente de análise e projeto de sistemas, surge uma 
gama de problemas de natureza e origem diferentes, que 
condicionam a eficiência e eficácia dos sistemas de 
informação. 
1.2.1. Relacionamento entre Analistas de Sistemas e 
Usuários 
A crise estabelecida entre estes agentes de modernização da 
empresa é de natureza técnica e comportamental. 
Entre os analistas de Sistemas e Usuários, os problemas 
têm como origem os seguintes fatores: 
 Formação escolar; 
 Metodologia de trabalho; 
 Dificuldade na especificação lógica do problema; 
 Descrença do usuário em relação ao computador como 
ferramenta de solução de seus problemas, experiências 
frustradas, sistemas mal especificados ou de difícil 
operação; 
 Demora na implementação de modificações de 
processos/funções; 
 Receio de perder autoridade e poder 
 Receio de esvaziamento de suas tarefas administrativas 
e do emprego; 
 Prazo excessivo para o desenvolvimento e implantação 
do aplicativo; 
 Resistência à mudança. 
 9 
1.2.2. Relacionamento entre Analistas e Programadores 
 
 Dificuldade na comunicação escrita (especificação de 
procedimentos lógicos de forma estruturada); 
 Falta de visão do sistema como um todo por parte do 
programador; 
 Luta pela conquista de melhores soluções operacionais 
de um microproblema. 
1.2.3. Gerência de Projetos 
 
 Limitações pessoais de liderança de pessoas (planejar, 
coordenar, comandar e controlar); 
 Não utilização de ferramentas e técnicas de controle, 
tais como: cronogramas, pontos de controle, relatórios 
de progresso, comitê de coordenação, plano operacional 
do projeto, check-lists, etc...; 
 Dificuldade de mensuração de prazos e recursos; 
 Seleção e treinamento da equipe-projeto (qualificação 
de técnicos); 
1.2.4. Aspectos Organizacionais 
 
 Fraca compatibilidade entre as políticas da empresa com 
a área de informática (planejamento de informática); 
 Cultura da organização. 
 
 10 
1.2.5. Exigüidade de Prazo para a Implementação 
 
 A síndrome do “é para ontem”. O sistema sempre deu 
problemas, mas, de repente, alguém o aponta como 
prioritário; 
 Mudanças constantes da política da empresa; 
 Receio do turnover da equipe-projeto; 
 O prazo “político” estabelecido pela gerência de 
desenvolvimento e/ou cúpula da organização 
(características das empresas públicas); 
 Período letivo, exercício financeiro, eventos com datas 
tradicionalmente fixadas, etc... 
 
1.2.6. Relação Custo X Benefício 
 
 Dificuldade na apropriação de custos; 
 Dificuldade na mensuração dos benefícios; 
 Alternativas de automação x manualização. 
 
1.2.7. Dificuldade na Aferição de Progresso 
 
 A síndrome dos 99%; 
 O mito homem-mês; 
 
 11 
1.2.8. Limitações de Software e Hardware 
 Linguagens de programação complexas; 
 Limitações e dificuldades de uso do sistema operacional; 
 Métodosineficientes de armazenamento e recuperação 
de dados; 
 Quantidade de terminais para desenvolvimento; 
 Portabilidade/compatibilidade de software. 
1.2.9. Limitações e Complexidade de Metodologias e 
Ferramentas 
 
 O maior problema é definir o problema; 
 Dificuldade para atualizar a documentação; 
 Manualização excessiva para especificação de 
componentes sistêmicos; 
 Dificuldade de modificação de especificações; 
 Dificuldade em derivar a especificação lógica em física; 
1.2.10. Centralização da Administração de Dados 
 Dificuldade na implementação de regras padronizadas 
para evitar redundância de dados; 
 A insegurança do usuário em abandonar seus arquivos 
manuais; 
 O fator “arquivos de proprietários”; 
 Aumento de custos de implementação de redes de 
comunicação de dados; 
 Segurança física e lógica dos dados. 
 12 
1.3. Gerência de Projetos de Sistemas 
1.3.1. Considerações Iniciais 
 
 Gerenciar é decidir em situação de informação 
incompleta; 
 Gerentes servem para avaliar e interpretar informações, 
propor e comparar ações, decidir com base em múltiplos 
critérios, assumir riscos e para barganhar e negociar 
soluções que frequentemente não são “ótimas” do ponto 
de vista puramente tecnológico ou econômico, mas que 
são factíveis (ou satisfatórias) sob a perspectiva 
organizacional. 
 Na prática, o Gerente de Projeto muitas vezes se vê às 
voltas com um Sistema do qual apenas conhece o 
“RÓTULO” (isto é, o nome do Sistema), seus objetivos 
gerais, e a data “desejada” para a instalação. 
 Baseado em tais fatores, o Gerente empreende então 
um esforço de Negociação, visando a obtenção de 
Recursos Humanos e Técnicos para o Projeto, e um 
esforço de “Planejamento” destinado a produzir um 
cronograma detalhado. Que se encaixa, o mais possível, 
dentro das restrições técnicas e organizacionais 
impostas pelo prazo “desejado”. 
 13 
1.3.2. Questões para reflexão 
 
 A Metodologia para desenvolvimento de Sistemas de sua 
organização está bem definida? 
 É feito um plano de trabalho no início do projeto? 
 As estimativas de Prazo, custo e esforço são feitos com 
base em Métodos quantitativos ou no Histórico de 
Projetos da instalação? 
 A Coordenação do projeto é conjunta com o Usuário? As 
responsabilidades são bem definidas? 
 No projeto, existem pontos de controle? 
 Para cada ponto de controle existe relatório de 
progresso? 
 É feita a avaliação do risco de um projeto? 
 São levadas em consideração abordagens diferenciadas 
de desenvolvimento em função das características dos 
projetos? 
 Existe o registro dos projetos já desenvolvidos e 
implantados em termos de prazo, custo, esforço, 
consumo de Hardware, produtividade da equipe? 
 A organização tem um processo de planejamento de 
informática? 
 14 
1.3.3. Requisitos básicos de um bom gerente 
 
 Conhecimentos Obrigatórios 
o Ter uma sólida formação acadêmica ou uma 
experiência profissional equivalente em termos de 
lógica de desenvolvimento de sistemas (algoritmos e 
estruturas de dados) 
o Já ter participado de algum projeto de 
desenvolvimento de software como programador. 
o Já ter participado de algum projeto de 
desenvolvimento de software como analista. 
o Conhecer o mínimo das ferramentas de desenvol-
vimento (ferramenta CASE, SGBD, linguagem de 
programação) 
 15 
 Conhecimento Desejáveis 
o Conhecer a área de networking, envolvendo aspectos 
tais como planejamento e montagem de infra 
estrutura de redes 
o Conhecer razoavelmente bem outras linguagens de 
desenvolvimento para poder acompanhar as 
evoluções do mercado de informática. 
o Capacidade de delegar e cobrar 
o Gostar de estudar (reciclagem constante) 
o Leitura de livros 
o Participação de congressos e feiras de tecnologia 
o Assinatura de revistas especializadas 
1.3.4. Ferramentas de gerência de projetos 
 
No mercado , o profissional tem a sua disposição um série 
de ferramentas para auxiliá-lo no desenvolvimento e 
acompanhamento do seu projeto. Dentre várias alternativas 
listamos Três: 
 
 Primavera: Uma das mais antigas e conhecidas nesta área 
de planejamento. Grandes empresas dentro do Brasil e 
fora dele utilizam essa ferramenta em projetos complexos 
para facilitar o seu planejamento e acompanhamento. 
www.primavera.com 
 Microsoft Project: É um dos componentes opcionais do 
Microsoft Office com recursos bastante avançados para o 
planejamento e acompanhamento. 
OpenProj: É um dos mais populares entre os programas 
open source existentes e sua interface é bastante similar 
à solução Microsoft. 
http://www.primavera.com/
 16 
1.4. Conceito de Projeto e Gerenciamento de Projeto 
1.4.1. Conceito de Projeto 
 
. “Empreendimento ou evento NÃO REPETITIVO, caracterizado 
por uma SEQUÊNCIA clara e lógica de EVENTOS, com INÍCIO, 
MEIO e FIM, que se destina a atingir um OBJETIVO claro e 
definido, sendo conduzido por PESSOAS dentro de parâmetros 
pré-definidos de TEMPO, CUSTO, RECURSOS envolvidos e 
QUALIDADE”. 
Ricardo Viana Vargas 
 
• Evento NÃO REPETITIVO: algo que não faz parte da rotina 
da empresa. É algo novo para as pessoas que o realizarão; 
Exemplo: Filme “Tempos Modernos” de Charles Chaplin 
 
• SEQUÊNCIA clara e lógica de EVENTOS: é composto de 
atividades lógicas encadeadas que permitem 
acompanhamento e controle durante a execução; 
 
• Com INÍCIO, MEIO e FIM: possuem um ciclo de vida bem 
definido (se for uma atividade sem um fim definido, não é 
um projeto, mas uma rotina de trabalho); 
 
• Atingir um OBJETIVO claro e definido: possui metas e 
resultados a serem atingidos em sua finalização; 
 
• Conduzido por PESSOAS: sem o homem não existe projeto; 
 
 Parâmetros pré-definidos de TEMPO, CUSTO, RECURSOS 
envolvidos e QUALIDADE: são restrições de projeto que 
devem ser identificadas e mapeadas no decorrer do plano de 
projeto; 
 17 
1.4.2. Conceito de Gerenciamento de Projetos 
 
“A Gerência de Projetos é um ramo da ciência da 
administração que trata do planejamento e controle de 
projetos”. 
Darci Prado 
 
Gerenciar um projeto significa, resumidamente, planejar a 
sua execução antes de iniciá-lo e , posteriormente, 
acompanhar a sua execução e controle 
. Planejar : os objetivos são definidos e refinados 
. Executar : coordenar as pessoas e outros recursos 
. Controlar : garantia de que os objetivos são alcançados 
 
1.5. Modelo de Gerência e Práticas Gerenciais 
 
O modelo de gerência proposto em nosso curso é o 
modelo do triângulo de Joiner que é uma composição do 
modelo do Espiral em camadas (Pressman) com a Teoria-W 
proposta por Boehm. 
Este modelo é representado por meio de um triângulo, no 
qual o vértice superior representa a QUALIDADE do software 
definida pelo cliente, ou seja o que o cliente espera e os 
vértices inferiores representam ABORDAGEM CIENTÍFICA e 
COESÃO DA EQUIPE. 
 18 
Algumas práticas gerenciais quando bem aplicadas, 
contribuem para a melhoria da qualidade da gerência de um 
projeto de software. Os processos de desenvolvimento 
modernos sugerem a adoção de abordagens iterativas, 
incrementais e em casos de uso. A ideia central é liberar o 
mais cedo possível versões operacionais capazes de agregar 
valor ao negócio. Para esta definição de versões, é apropriado 
o princípio de Pareto (80% do objetivo é atingido com 20% do 
esforço necessário) 
 19 
2. GERENCIAMENTO DE PROJETOS COM O PMI 
 
2.1. Os Envolvidos no Projeto 
 
 Os envolvidos no projeto, também denominados 
stakeholders, são as pessoas e as organizações diretamente 
ligadas ao projeto, ou aqueles indivíduos afetados pelo 
projeto. Esse envolvimento pode ocorrer em todas as fases do 
ciclo de vida do projeto. 
 
A gerência deve identificar todos os envolvidos no projeto 
antes de iniciá-lo, conhecer suas necessidades e expectativas. 
 
 
Alguns envolvidos do projeto são: 
 
. o patrocinador 
. o cliente 
. ogerente do projeto 
. a organização executora 
. os membros da equipe do projeto 
 
Pessoas diferentes pensam diferente e possuem objetivos e 
expectativas diferentes. Uma das tarefas desafiadoras de um 
gerente é saber encontrar soluções adequadas para tais 
conflitos entre os envolvidos no projeto. 
 20 
2.2. PMI – Project Management Institute: 
 
• Fundado em 1969 na Filadélfia, EUA; Instituição sem fins 
lucrativos; 
• Missão: “Promover o profissionalismo e a ética em 
gerenciamento de projetos”; 
• No Brasil existem 16 capítulos (Chapters) e no mundo 304 
capítulos do PMI; 
• Conta com mais de 680 mil membros em mais de 180 
países; Estatísticas PMI: http://blog.pmtech.com.br/dados-
estatisticos/ 
 
 PMBOK Guide, 6ª edição – 01/10/2017 (Conformidade com 
a ISO 21500[2012] – Orientações para Gerenciamento de 
Projetos). 1ª edição do PMBOK foi 1996, depois 
2000,2004,2008,2012. 
Saiu em Julho/2021 7ª Edição do PMBOK. 
 
O livro: “ A Guide to the Project Management Body of 
Knowledge” ou “Guia para o universo do conhecimento de 
Gerenciamento de Projetos” é um marco na história do 
gerenciamento de Projetos. 
 
É de autoria do Standards Commite (Comite de Padronização) 
do PMI e procura contemplar os principais aspectos que 
podem ser abordados no gerenciamento de projetos genérico. 
Este livro consta de uma proposta de padronização para o 
processo de gerenciamento de projetos, propondo uma 
padronização, identificando e nomeando processos, áreas de 
conhecimento, técnicas, regras e métodos. 
Aceito desde 1999, como padrão de gerenciamento de 
projetos pelo ANSI (American National Standards Institute) 
• www.pmi.org 
• www.pmiUF.org.br 
http://blog.pmtech.com.br/dados-estatisticos/
http://blog.pmtech.com.br/dados-estatisticos/
http://www.pmi.org/
http://www.pmiuf.org.br/
 21 
2.3. O PMP(Project Management Professional) 
• O PMI, possui a certificação de Gerência de Projetos mais 
difundida no mundo: 
• PMP – Project Management Professional; 
. Certificação de qualidade profissional individual 
fornecida pelo PMI, 
Requisitos para se candidatar: 
Categoria I : 
. Nível superior de no mínimo 4 anos. 
. Mínimo de 4500 horas de trabalho na liderança em 
gestão de projeto. 
. Mínimo de três anos de experiência em 
gerenciamento de Projetos. 
. 35 horas de formação em gerenciamento de 
Projetos. 
 Categoria II : 
. Diploma de ensino médio o equivalente 
. Mínimo de 7500 horas de trabalho na liderança em 
gestão de projeto 
. Mínimo 5 anos de experiência 
. 35 horas de formação em gerenciamento de 
Projetos. 
https://brasil.pmi.org/brazil/CertificationsAndCredentials/PMP.aspx 
Se você não atende os requisitos do PMP, avaliar a 
certificação CAPM. 
 
• CAPM - Certified Associate Project Manager 
. Certificação de Profissional Técnico Certificado em 
Gerenciamento de Projetos, 
Requisitos para se candidatar: 
. Diploma de ensino médio ou equivalente E 
(Mínimo de 1500 horas de experiência em Projeto OU 
23 horas de formação em gerenciamento de 
projetos). 
https://brasil.pmi.org/brazil/CertificationsAndCredentials/CAPM.aspx 
 
 22 
2.4. O PMO(Project Management Office) 
 
Ou o Escritório de Gerenciamento de Projetos, é um dos 
aspectos organizacionais de gerenciamento de projetos que 
vêm recebendo muita atenção ultimamente, quando a 
empresa toca muitos projetos ao mesmo tempo, aliviando o 
trabalho dos gerentes de projetos ao compartilhar a execução 
de tarefas de planejamento e acompanhamento. 
 
Dentre as funcões, podemos citar: 
 
.Produzir a padronização e normatização dos projetos da 
empresa 
.Fornecer treinamento e consultoria em gerência de 
projetos e no uso de softwares dentro da empresa 
.Participar, junto com o gerente de cada projeto, da 
avaliação inicial de riscos 
.Acompanhar a performance de execução 
.Analisar as contramedidas para eliminação de riscos, com 
o gerente de cada projeto 
.Efetuar auditoria sobre os resultados obtidos pelos 
projetos 
.Funcionar como interface entre os projetos e a alta 
administração da empresa 
 
 
 O PMBOK analisa o gerenciamento de um projeto da 
seguinte maneira: 
 
.Divisão do projeto em etapas (Ciclo de vida) 
.Em cada etapa ocorrem processos 
.Em cada processo são executadas ações gerenciais que 
podem abranger até dez áreas de conhecimento 
 23 
2.5. Conceitos de Ciclo de vida, Áreas de conhecimento 
e os Processos da Gerência de Projeto 
 
A) Ciclo de Vida : 
 
Um ciclo de vida é caracterizado por várias fases distintas, 
certamente dependendo do tipo de projeto (construção, 
informática, etc), suas fases tem particularidades próprias. 
 
Em projetos de Tecnologia de Informação, principalmente de 
desenvolvimento de software, normalmente usamos nomes 
como: Levantamento de Requisitos, Análise, Projeto, 
Codificação, Teste, Implantação. 
 
Em cada fase de um projeto são executados diversos 
processos com o objetivo de produzir o resultado esperado 
daquela etapa 
 
O final de cada fase é caracterizado pela entrega, ou 
finalização, de um determinado trabalho/deliverable(produto 
ou serviço), tais como: 
. “Manual de Especificação de um software” 
. “Telhado de uma residência” 
. “Relatório dos resultados de testes de um software” 
 
É no final de cada etapa, na verificação da qualidade dos 
trabalhos produzidos, na análise de desempenho da execução 
e no julgamento das possibilidades de se terminar o projeto 
com sucesso, que se toma a decisão de continuar ou não o 
projeto. Quando a decisão é por continuar o projeto, é feito 
um melhor detalhamento do plano da próxima etapa. 
 
 
 
 
 
 24 
 
B) Áreas de conhecimento da Gerência de Projeto: 
 
 
As áreas do gerenciamento de projetos descrevem o 
gerenciamento em termos de seus processos componentes. 
Esses processos podem ser organizados em dez grupos 
integrados, como descrito na figura a seguir: 
 
 
 
 
 
 
 
 
 25 
. O Gerenciamento da integração 
Consiste em garantir que todas as demais áreas estejam 
integradas em um todo único. Seu objetivo é estruturar todo o 
projeto de modo a garantir que as necessidades dos 
envolvidos sejam atendidas. 
Para a integração gerencial harmônica do todo, é 
necessário o comprometimento da organização e o suporte 
dos altos executivos. 
O Gerenciamento do Escopo 
 A definição de escopo, desde descrição do produto e os 
requisitos dos usuários, deve ser feita sempre com a 
participação e consentimento formal de todos os envolvidos 
no projeto 
 
O Gerenciamento do Tempo.(Atenção na versão 6.0 o nome 
foi substituído para Gerenciamento do Cronograma, pois 
gerentes de projetos não gerenciam tempo e SIM gerenciam o 
cronograma do projeto.) 
Muitos projetos de TI não obtêm sucesso devido a 
problemas nas projeções de tempo, que normalmente ocorrem 
devido a um mal entendimento de requisitos do usuário , o 
que afeta diretamente a forma como o escopo do projeto será 
definido. 
O Gerenciamento do Custo 
Pelo fato de projetos custarem dinheiro e redirecionarem 
recursos que poderiam ser aplicados em outras áreas, é muito 
importante para os gerentes de projetos entenderem de 
gerenciamento de custos. 
O Gerenciamento da Qualidade 
É o gerenciamento EFICIENTE e EFICAZ de todos os 
processos necessários para garantir que o projeto satisfaça as 
necessidades para as quais foi empreendido. 
 26 
EEFFIICCÁÁCCIIAA éé eenntteennddiiddaa ccoommoo aa ccaappaacciiddaaddee ddee aatteennddeerr 
qquuaannttiittaattiivvaammeennttee ee qquuaalliittaattiivvaammeennttee aa ddeetteerrmmiinnaaddaa 
nneecceessssiiddaaddee ddoo aammbbiieennttee.. 
-- DDiizz rreessppeeiittoo aa rreessuullttaaddooss 
EEFFIICCIIÊÊNNCCIIAA rreeffeerree--ssee aa qquuaannttiiddaaddee ddee rreeccuurrssooss 
ddeessppeennddiiddooss nnoo pprroocceessssaammeennttoo iinntteerrnnoo aaoo ssiisstteemmaa 
ppaarraa pprroodduuzziirr uumm pprroodduuttoooouu sseerrvviiççoo.. 
 -- DDiizz rreessppeeiittoo aaoo mmooddoo cceerrttoo ddee ffaazzeerr aa ccooiissaa 
 
O Gerenciamento dos Recursos Humanos.(Atenção na 
versão 6.0 o nome foi substituído para Gerenciamento dos 
Recursos, ou seja pessoas, equipamentos e recursos físicos 
estão incluídos.) 
Além dos clientes e dos produtos, sem dúvida, os recursos 
humanos fazem parte dos principais ativos das organizações. 
O sucesso dos projetos e das organizações é determinado 
pelas atitudes profissionais das pessoas. 
Um aspecto importante que deve ser considerado na área 
de TI é que pessoas qualificadas são difíceis de se manter 
durante muito tempo nas organizações, principalmente 
quando se sentem insatisfeitas por salários abaixo do mercado 
ou por falta de investimento da organização em sua evolução 
profissional. Pessoas insatisfeitas geram improdutividade e má 
qualidade no produto a ser desenvolvido. 
O Gerenciamento dos Riscos 
Risco é a possibilidade de ocorrência de um resultado 
indesejável. 
O Gerenciamento das Comunicações 
Comunicação não é o que você quer falar, nem o que você 
fala, é o que o outro entende. 
 A comunicação como desafio para o gerente de projetos: 
 Há vários casos em que excelentes profissionais, 
com sólida formação técnica, por vezes se veem 
em dificuldades no exercício da gerência de 
 27 
projetos, porque descobrem que além do perfil 
técnico, precisam de uma série de habilidades 
para as quais não estão devidamente preparados: 
Estabelecimento de relacionamentos, satisfação 
dos clientes, motivação da equipe, tratamento de 
conflitos, tratamento de expectativas. 
 
O Gerenciamento das Aquisições 
Aquisição (Procurement) significa adquirir bens e serviço 
de uma fonte externa. 
O Gerenciamento das Partes Interessadas 
 Que são os stakeholders. Consiste em identificar e 
gerenciar e controlar os stakeholders. 
 
 28 
C) Os Processos da Gerência de Projetos: 
 
Em cada fase de um projeto são executados diversos 
processos com o objetivo de produzir o resultado esperado 
daquela etapa. Conforme padronizado pelo PMI, estes 
processos de enquadram nos seguintes grupos: 
 
. Processo de iniciação 
. Processo de planejamento 
. Processo de execução 
. Processo de monitoramento e controle 
. Processo de encerramento 
 
Estes processos ocorrem dentro de cada fase e estão 
interligados. Além disso, os processos de controle ocorrem 
simultaneamente com os processos de execução e, 
dependendo do resultado do processo de controle, pode-se 
refazer e voltar a executar as ações de planejamento. 
c.1) Processo de iniciação: 
 É a fase inicial do projeto, quando uma determinada 
necessidade é identificada e transformada em um problema. 
Objetivo é AUTORIZAR e obter o COMPROMETIMENTO da 
organização para a FORMALIZAÇÃO do início do projeto ou de 
uma nova fase. 
Ações envolvidas: 
• Avaliar solicitações de desenvolvimento 
• Realizar estudos de viabilidade 
• Decidir fazer ou não o projeto 
• Elaborar o Project Charter (PMBOK) 
• Iniciar a Gerência antecipada 
 
 
 
 
 29 
c.2) Processo de Planejamento: 
 
Após ter sido escolhido e designado o gerente para o 
projeto, elaborado o Project Charter, colhido e documentado 
todas as premissas e restrições, bem como todas as 
informações relevantes e pertinentes ao processo de iniciação, 
é hora de começar a planejar o projeto. 
 
Vamos detalhar o escopo de trabalho usando 
templates(modelos) de Estrutura Analítica de Projeto(EAP) 
ou Work Breakdown Structure(WBS) ou EDT(Estrutura de 
Decomposição do Trabalho) que ajuda para o conhecimento 
das partes do projeto e também na montagem do Diagrama 
de Gantt ou PERT. 
 
O WBS é uma ferramenta de gerenciamento do escopo do 
projeto. Cada nível descendente do projeto representa um 
aumento no nível de detalhamento do projeto, como se fosse 
um organograma. O detalhamento pode ser realizado até o 
nível desejado, apresentando dados genéricos ou detalhados. 
O detalhamento mais usual é até pacotes de trabalho (Work 
package). Estes pacotes podem ser mais tarde desdobrados 
no plano de projeto e no cronograma. 
São características do WBS: 
. Permite que se veja a contribuição dos pacotes de 
trabalho no projeto principal 
. Permite o direcionamento das equipes, dos recursos 
e das responsabilidades 
 Desvantagens do WBS: 
. Não diferencia, visualmente, o prazo e a duração de 
cada pacote, bem como a importância de cada um 
 . Não mostra as interdependências entre os pacotes 
 
 
 30 
Atividades a executar – WBS – Exemplo 
 
 
 
 
 
 
 
Tema Palestrante
Obter Materiais Preparar Kits
Material
Programa
Data Local Reserva
Realização
Produzir Folheto
Mala Direta Enviar Folheto
Brochura Registrar Inscrição
Marketing
Plano da Conferência
 31 
 
 Gráfico de Gantt 
 
É a ferramenta mais utilizada em gerência de 
projetos, criado pelo americano Henry Gantt, durante a 
primeira guerra mundial, substituindo os métodos até 
então utilizados de alfinetes coloridos e bandeirinhas. 
 
Na montagem do gráfico de Gantt, o projeto é 
decomposto em atividades (tarefas) que são 
posicionadas em uma escala de tempo. 
 
Sua montagem é bastante simples e bastante 
funcional em projetos pequenos (até 30 atividades), em 
projetos maiores tende a ficar bastante confuso. 
 
Deve-se inicialmente, levantar todas as tarefas 
necessárias para a realização do projeto com as suas 
respectivas durações. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 32 
Exemplo Gantt – WBS Exemplo 
 
 
 
 
 
 33 
Exemplo: 
 
Aplicação Projeto: construir uma casa 
 
Código Descrição Atividade Duração Dependência 
A Preparo do local 2 - 
B Fundações 4 A 
C Alvenaria 4 B 
D Esgotos 1 B 
E Telhado 2 C 
F Piso 1 D 
G Instalações Elétricas 3 E 
H Instalações Hidráulicas 3 E 
I Carpintaria 6 E,F 
J Pintura interna 4 G,H,I 
K Pintura externa 2 I 
L Limpeza 1 J,K 
 34 
Diagrama de Gantt : Projeto Construir uma casa 
 
Id Nome da tarefa
1 Preparação do local
2 Fundações
3 Alvenaria
4 Esgotos
5 Telhado
6 Piso
7 Instalações Elétricas
8 Instalação Hidráulica
9 Carpintaria
10 Pintura Interna
11 Pintura Externa
12 Limpeza
QSSDSTQQSSDSTQQSSDSTQQSSDSTQQSSDSTQQSSDS
28/Dez/03 04/Jan/04 11/Jan/04 18/Jan/04 25/Jan/04 01/Fev/04 08/Fev/04
 35 
 
 Diagramas PERT 
 
O interrelacionamento entre as atividades do 
projeto compõe um todo organizado, denominado 
rede PERT(Program Evaluation and Review 
Technique). A rede PERT evidencia os inter-
relacionamentos entre as atividades no projeto global. 
Adequado em projetos nos quais o 
sequenciamento das atividades apresenta alguma 
complexidade. 
 
O mais conhecido é o Diagrama de 
Precedências, onde as atividades são representadas 
por blocos. 
 
 
 
 
IIInI 
 
 
 
* obs: 10,11 janeiro(sab/dom) 
 17,18 janeiro(sab/dom) 
 
 
 
 
 
 
Preparação do local 
 
Início: 06/01/04 id: 1 
 
Término: 07/01/04 dur: 2 dias 
Fundação 
 
Início: 08/01/04 id: 2 
 
Término: 13/01/04 dur: 4 dias 
Alvenaria 
 
Início: 14/01/04 id: 3 
 
Término: 19/01/04 dur: 4 dias 
Esgotos 
 
Início: 14/01/04 id: 4 
 
Término: 14/01/04 dur: 1 dias 
 36 
c.3) Processo de Execução: 
 
É a fase que materializa tudo aquilo que foi planejado 
anteriormente. Qualquer erro cometido nas fases anteriores 
fica evidente durante essa fase. Grande parte do orçamento e 
do esforço de projeto são consumidos nessa fase. 
 
c.4) Processo de Monitoramento e Controle: 
 
Servem para GARANTIR que os objetivos do projeto sejam 
alcançados através da MONITORAÇÃO e da MENSURAÇÃO do 
seu progresso, tomando ações corretivas e proativas sempre 
que houver necessidade 
 
O objetivo do controle é comparar o status atual do 
projeto com o status previsto pelo planejamento, tomando 
ações corretivas em caso dedesvio. 
c.5) Processo de Encerramento: 
Tem com o objetivo avaliar o resultado do projeto junto 
ao cliente ou patrocinador. 
 
Encerramento do Contrato: 
• Arquivos do contrato: cronogramas, documentos, 
aceites... 
• “Aceite Formal” impresso e assinado; 
Encerramento Administrativo: 
• Arquivos dos documentos: especificações, documentação 
técnica, modelo de dados (ferramentas case), manual do 
usuário, relatos de desempenho, e-mails (comunicações) 
 
2.6. Quais os fatores levaram a mudança do PMBOK? 
 7ª edição acompanha a evolução dos processos produtivos 
e as novas demandas de um mercado cada vez mais 
digitalizado. 
 37 
 Por isso, ela tem como escopo o gerenciamento de 
projetos com orientação para mudanças, em que a INOVAÇÃO 
é desruptiva (é aquela que produz nova solução, rompendo 
paradigma), para isso foram ampliados os princípios 
(sugestões/orientações) de gerenciamento de projetos de 7 
para 12 (PRINCE 2 : Metodologia baseada em princípios - 
criado pelo governo britânico). 
 Outra mudança bastante importante é a inclusão do 
conceito de SISTEMA DE ENTREGA DE VALOR, em busca 
definir parâmetros de valor agregado para a organização e os 
Stakeholders. 
Em Resumo o PMBOK 7ª = PMBOK Guide (8 Domínios 
desempenho) + ANSI STANDARD for Project Management (12 
Princípios) 
 E a mudança mais significativa é que os projetos não são 
mais orientados por processos e sim guiados por PRINCÍPIOS 
(Não diz o que você deve fazer e sim o que você deve levar 
em consideração) e a substituição das 10 áreas de 
conhecimento por DOMÍNIOS DE PERFORMANCE (Grupo de 
atividades relacionadas que são críticos para entrega de 
benefícios esperada). 
A importância destas alterações é que o foco agora além 
da entrega por valor, inclui também o aprimoramento do 
relacionamento em equipes e no entendimento que melhorias 
só acontecem quando existe abertura para mudanças. 
Os doze Princípios de Gerenciamento de Projetos segundo 
PMBOK 7ª (Eles são a fundação, a estrutura como você deve 
abordar alguma coisa. Eles orientam e direcionam nosso 
comportamento e ações (Não diz o que deve fazer e sim o que 
deve ser levado em consideração) 
1 – SERVIDÃO: (Pastoreio; Gestor + Líder) : Liderar um 
projeto requer além de competências técnicas, uma 
abordagem humilde, respeitosa e atenciosa com os membros 
de uma equipe. 
2 – COLABORAÇÃO: (Equipe colaborativa) : Para a 
entrega de valor é fundamental que as equipes trabalhem em 
regime colaborativo. 
 38 
3 – EMPATIA: É fundamental que os gestores e líderes 
interajam com os stakeholders para compreender a fundo suas 
expectativas e necessidades. 
4 – FOCO NO VALOR: Ainda mais importante do que 
entregar no prazo, respeitando o orçamento é agregar valor 
em cada projeto finalizado, (colocar a empresa em uma 
situação melhor (+), conceito de STOP LOSS(interromper as 
perdas). 
5 – PENSAMENTO SISTÊMICO (System Thinking) : 
Entender a relação do seu projeto com o ambiente, visão 
aberta: considerando interações externas, olhar a 
concorrência, mercado, clientes. 
6 – LIDERANÇA (Diferente de Autoridade) : O sucesso não 
vem sem um esforço contínuo em liderar, motivar, aprender e 
treinar. Precisamos desenvolver as pessoas que fazem parte 
da nossa equipe. 
7 – ADAPTAÇÃO (Tayloring) : Entender o projeto no seu 
contexto não só do produto, mas também do processo. 
Priorizar aumentar o benefício e maximizar valor. Hoje os 
projetos precisam ser adaptados a contextos mais específicos. 
8 – QUALIDADE : Enchergar qualidade como sinônimo de 
VALOR, é preciso garantir que as ENTREGAS atenderão aos 
padrões esperados pelos clientes. 
 Minimizar defeitos, aceitar desafios por exemplo 
produzir vinho bom com uvas ruins. 
9 – COMPLEXIDADE (Incerteza): Aceitar e gerenciar esta 
complexidade em um contexto onde os projetos são mais 
complexos em gerir. VUCA(acrônimo: V-Volatibilidade, U-
Uncertainy(incerteza), C-Complexidade e A-Ambiguidade) 
10 – RISCOS (Oportunidade e Ameaça) : Otimizar sua 
capacidade de responder aos riscos(proatividade). Atenção: 
Probabilidade e impacto mudam com o tempo. 
11 – ADAPTABILIDADE E RESILIÊNCIA: Líderes e equipes 
de projetos precisam de se adaptar focando na capacidade de 
se recuperar após um choque(Voltar melhor). 
12 – MUDANÇA (Change) : É a única certeza. Incentivar 
as mudanças e criar condições para que as pessoas se 
 39 
adaptem a essas mudanças (mudança não é algo 
necessariamente RUIM). 
 
Outra mudança no PMBOK 7. 
Foi a retirada das 10 áreas de conhecimento, que dão lugar 
aos DOMÍNIOS DE DESEMPENHO(8), nos quais busca 
compreender o que leva um projeto a ser eficaz. 
Outra questão importante é que o guia coloca em evidência a 
GESTÃO da MUDANÇA (ambiente não estável), que passa a 
ser tratada como parte fundamental no gerenciamento de 
projetos. 
Os oito DOMÍNIOS DE DESEMEPENHO: Grupo de atividades 
que são críticas para entregar os benefícios planejados 
1 – STAKEHOLDERS : Como vou tratar todos os Stakeholders 
(até os opositores). Estes Stakeholders mudam e podem ter 
diferentes visões. Ter um compromisso sólido com as partes 
interessadas; 
2–TEAM (Equipe) : Atribuir responsabilidades, como estimular 
(Inteligência emocional, pensamento crítico). Nova cultura: 
Todo TIME é responsável pela entrega. 
3 - CICLO DE VIDA: Escolher quais métodos vão ser usados. 
Definir se vou usar PREDITIVO (Baseado em requisitos claros, 
onde escopo, tempo e custo são determinados o mais cedo 
possível), INTERATIVO (Ciclo incremental e evolutivo, onde a 
cada incremento existe aumento funcionalidade, baseada em 
entregas parciais focadas na inovação e incerteza), MISTO. 
 4–PLANEJAMENTO(Ligado ao PMBOK 6ª): Quais as atividades 
associadas para você organizar e coordenar seu projeto para 
produzir as entregas e resultados esperados. 
 5-NAVEGAÇÃO NA INCERTEZA E AMBIGUIDADE: Tudo que 
você vai fazer para ter atividades que endereçam VUCA 
(Volatibilidade, Uncertainy, Complexidade, Ambiguidade), 
atividades e funções relacionadas associadas aos riscos. 
 6-ENTREGA: associado à entrega de valor. 
 7-MENSURAÇÃO (Desempenho): Tudo que você faz para 
mostrar o desempenho do seu projeto. Para avaliar resultado 
 40 
você tem que medir. O foco aqui é garantir que o desempenho 
planejado do projeto seja alcançado. 
 8-TRABALHO(Ligado ao PMBOK 6ª): Necessário para manter 
as operações do projeto funcionando perfeitamente, parte de 
aquisições, comunicações e lições aprendidas. 
 
Resumindo: principais mudanças no PMBOK 7 
A sétima edição do PMBOK traz como principais mudanças: 
 Princípios de Gerenciamento de Projetos em vez de 
Processos. Os 12 princípios resumem “o quê” e “o porquê” 
do gerenciamento de projetos. 
 Domínios de Desempenho do Projeto em vez de Áreas de 
Conhecimento. Os 8 domínios são fundamentais para uma 
entrega eficaz dos resultados do projeto. 
 O foco do trabalho do projeto não se concentra apenas 
nas entregas dos projetos, mas se estende também aos 
seus resultados, ou, ao valor. 
 Gestão na mudança como parte da gestão de projetos. 
 
 41 
3. ANÁLISE E GESTÃO DE RISCOS 
3.1. Conceito de Análise e Gestão de Riscos 
 
“Riscos Afetam acontecimentos futuros” 
 
Análise e Gestão de Riscos consiste em uma série de 
passos que ajudam uma equipe de software a entender e 
administrar os riscos. 
 
Um risco é um problema em potencial que envolve duas 
características: 
. Incerteza: pode ou não acontecer 
. Perda: se o risco tornar-se real, consequências 
indesejáveis ou perdas ocorrerão. 
 
 Independente do resultado, é importante: 
 . Identificá-lo 
 . Avaliar a probabilidade de ocorrência 
 . Estimar o seu impacto 
. Estabelecer um plano de contenção para 
acompanhar a tendência de ocorrência e um plano de 
contingência para caso de efetivamente ocorrer. 
 
 Normas de Gestão de segurança e de Riscos: 
 
 . Área da Segurançada Informação: 
 
 Norma ISO/IEC 27001: 2006 
. Descreve os requisitos necessários que devem ser 
implementados para criação do SGSI (Sistema de 
Gestão da Segurança da Informação) 
 Norma ISO/IEC 27002: 2005 
. Apresenta as melhores práticas para uma gestão 
adequada da segurança da informação. 
 
 
 42 
 
. Área da Gestão de Riscos: 
 
 Norma ISO/IEC 27005: 2011 
 . Apresenta as diretrizes para o gerenciamento da 
Tecnologia da informação e dos riscos de segurança da 
informação. 
 Norma ISO/IEC 31000: 2009 
 . Apresenta os princípios e diretrizes genéricas para 
qualquer indústria ou setor(Pode ser aplicada a qualquer 
ambiente organizacional) 
 
3.2. Estratégias de Prevenção de Riscos 
 
 
Riscos potenciais são identificados , suas possibilidade e 
impactos são avaliados, e eles são classificados por 
importância. 
 
 
 43 
Riscos de Software: 
 
Quando os risco são analisados, é importante quantificar o 
nível de incerteza e o grau de perda, associados com cada 
risco. 
 
Para isso, diferentes categorias de risco são 
consideradas (Riscos Prováveis de serem encontrados à 
medida que o software é construído) 
 
A) Primeira classificação: 
 
. Riscos de Projeto : 
 Ameaçam o plano de projeto, identificam problemas 
orçamentários, de cronograma, de pessoal , de recursos e 
de requisitos e seu impacto num projeto de software. 
 
. Riscos Técnicos : 
 Ameaçam a qualidade e a pontualidade do software a 
ser produzido, identificam problemas de Implementação, 
de Interface, de manutenção, de ambiguidade nas 
especificações, obsolescência técnica e tecnológica. 
 
. Riscos de Negócio : 
 Ameaçam a viabilidade do software a ser construído e 
comprometem o projeto e o produto. 
 1 – Construir um sistema excelente, mas que 
ninguem quer – Risco de mercado 
 2 – Construir um produto que não se encaixa mais na 
estratégia geral de negócios da empresa – Risco 
estratégico 
 3 –Construir um produto que a equipe de vendas não 
sabe como vender – Risco comercial 
 4 – Perda de apoio da gerência devido a mudança de 
enfoque – Risco gerencial 
 5 – Perda de comprometimento orçamentário - Risco 
de orçamento 
 44 
 
B) Outra categorização geral de riscos foi proposta por 
Charette, R.N. Software Engineering Risk Analysis and 
Management. McGraw-Hill, 1989. 
 
. Riscos Conhecidos : 
 Podem ser descobertos após a avaliação cuidadosa do 
plano de projeto, do ambiente técnico e comercial, no 
qual o projeto está sendo desenvolvido. 
 EX : Prazo de entrega irreal, falta de documentação 
de requisitos 
 
. Riscos Previsíveis : 
 São identificados de experiência de projetos 
anteriores 
 EX : Rotatividade de pessoal, má comunicação com o 
cliente 
 
. Riscos Imprevisíveis : 
 São o curinga do baralho. Eles podem e efetivamente 
ocorrem, mas são extremamente difíceis de identificar 
antecipadamente. 
 
 45 
3.3. Identificação, Avaliação, componentes e fatores 
de Risco 
 
3.3.1. Identificação de Riscos 
 
Identificação de riscos é uma tentativa sistemática de 
especificar ameaças ao plano de projeto (estimativas, 
cronograma, recursos, etc.) 
 
Pela identificação dos riscos conhecidos e previsíveis, o 
gerente de projeto dá um primeiro passo no sentido de 
evitá-los, quando possível, e controlá-los, quando 
necessário. 
 
Para cada categoria de risco apresentada: 
 
- Categoria A : Risco Projeto, Técnico, Negócio 
- Categoria B : Risco Conhecido, previsível, 
Imprevisível 
 
Há dois tipos distintos de riscos : Riscos Genéricos e 
Riscos Específicos. 
 
 Riscos Genéricos(Comuns) : são uma ameaça a todo o 
projeto de software. 
 Riscos Específicos(Únicos): Podem ser identificados 
somente pelos profissionais que tem claro entendimento 
da tecnologia , do pessoal e do ambiente que são 
específicos de cada projeto. Para identificar este tipo de 
risco a seguinte questão é levantada : “Que características 
especiais deste produto podem ameaçar nosso plano de 
projeto”. 
 
 
 
 46 
Exemplo: 
 
 Necessidade de desenvolver um software de treinamento 
a distância, apoiado na Web. 
 
 
1 – Riscos Comuns: 
 . Perda de Pessoal 
 . Custos mal planejados 
 . Não cumprimento do cronograma 
 . Especificações erradas 
 . Pessoal não capacitado 
 
 
2 – Riscos Únicos: 
 . Tecnologia Web pouco conhecida 
 . Usuários pouco familiarizados com a 
 comunicação virtual 
 . Suporte ao usuário 24 horas (vai exigir um 
 planejamento com previsão de pessoal) 
. Programadores não treinados em programação 
WEB 
 . Plano de navegabilidade inadequado(A má 
navegabilidade do site) 
 47 
Um método para identificação de riscos é a criação de 
uma Checklist de itens de risco com as seguintes 
subcategorias genéricas: 
 
 . Tamanho do produto : Riscos associados a 
dimensão do software que será construído ou modificado. 
 . Impacto no negócio : Riscos associados com 
restrições impostas pela gerência ou pelo mercado. 
 . Características do cliente : Riscos associados 
com a sofisticação do cliente e com a capacidade do 
desenvolvedor de se comunicar com o cliente. 
 . Definição do processo : Riscos associados com 
o grau em que o processo de software foi definido e é 
seguido pela organização de desenvolvimento. 
 . Ambiente de desenvolvimento : Riscos 
associados com a disponibilidade de ferramentas a serem 
usadas para construir o produto. 
 . Tecnologia para a construção : Riscos 
associados com a complexidade do sistema a ser 
construído e com a “novidade” da tecnologia que é 
incorporada ao sistema. 
 . Tamanho e experiência da equipe : Riscos 
associados ao tamanho da equipe e experiência no 
projeto. 
 
Cada um destes tópicos podem ser respondidos para cada 
projeto de software. As repostas a essas questões 
permitem ao planejador estimar o impacto do risco. 
 48 
3.3.2. Avaliação do Risco 
O projeto de software está correndo risco sério ? 
 A seguir algumas questões foram derivadas de dados 
de riscos obtidos por levantamento feito com gerentes de 
projeto de software experientes. 
1 – A alta administração do software e do cliente 
empenhou-se em apoiar o projeto? 
 
2 – Os usuários finais estão empenhados com relação ao 
projeto e ao sistema a ser construído? 
 
3 – Os requisitos estão plenamente entendidos pela 
equipe de engenharia de software? 
 4 – Os usuários finais têm expectativas realísticas ? 
 
 5 – O escopo do projeto é estável ? 
 
6 – A equipe de engenharia de software tem combinação 
de aptidões adequada? 
 
 7 – Os requisitos do projeto são estáveis? 
 
8 – A equipe de projeto tem experiência com a tecnologia 
a ser implementada ? 
 
9 – A quantidade de pessoal da equipe de projeto é 
adequada para fazer o serviço? 
 
10 – Todos os membros da equipe do cliente/usuário 
envolvidos concordam com a importância do projeto? 
 
Se qualquer dessas questões for respondida 
negativamente, os passos de atenuação, monitoração e 
gestão devem ser instituídos imediatamente. 
 
 49 
3.3.3. Componentes e Fatores de Risco 
 
O gerente de projeto deve identificar os fatores de risco 
que afetem os componentes de risco do software 
(desempenho, custo, apoio, cronograma), neste 
contexto os componentes de risco são definidos do 
seguinte modo: 
 
. Risco de desempenho : o grau de incerteza de que o 
produto atenda seus requisitos e seja adequado para seu 
uso planejado. 
 
. Risco de custo : o grau de incerteza de que o 
orçamento do projeto será mantido. 
 
. Risco de apoio : o grau de incerteza de que o software 
resultante será fácil de corrigir, adaptar e aperfeiçoar. 
 
. Risco de cronograma : o grau de incerteza de que o 
cronograma do projeto será cumprido e de que será 
entregue no prazo 
 
O impacto de cada fator de risco, no componente de 
risco, é dividido em uma das quatro categoriasde 
impacto seguintes: negligível, marginal, crítica ou 
catastrófica 
 
 50 
3.4. Avaliação, Impacto e Probabilidade 
Abordagem para avaliação Impacto e probabilidade 
dos riscos. Uma abordagem comum toma por base três 
fatores: 
 
. EVENTO : Condição que esta causando a incerteza 
Ex: Uso de uma leitora ótica em um processo entrada 
de dados 
 
. IMPACTO : Determinar as consequências 
Ex: Utilização incorreta, gerará erro no banco de 
dados 
 
. PROBABILIDADE : Chance de o risco ocorrer 
Ex : 50% por exemplo 
 
Os riscos sobre o projeto precisam ser reduzidos. 
Algumas Técnicas : 
 
. ACEITAR : Não fazer nada, pois as consequências 
custam menos que a CURA 
 
. EVITAR : Cancelar parte do projeto, após relação de 
custo/benefício 
 
. PLANO DE CONTINGÊNCIA: Criar caminhos 
alternativos, que deverão ser tomados quando um 
indicador específico acusar a ocorrência do problema. 
EX: Enviar operador para um curso específico ou 
contratar operador especializado. 
 
 .TRANSFERIR RISCO : Terceirizar parte do projeto, seja 
através de um contrato de preço fixo ou contratando mão 
de obra especializada de terceiros. 
 51 
O Resultado do planejamento de risco é um 
documento contendo a lista detalhada dos riscos do 
projeto, classificados por gravidade e probabilidade. 
Para cada risco, deverá ser documentado: 
 . Condição : descrição da situação que esta causando a 
incerteza 
 
 . Consequência : descrição dos possíveis resultados 
negativos e positivos que cada condição pode causar, 
quantificando impactos no prazo e orçamento. 
 
 . Ação : Como o risco será tratado e como o problema 
será abordado se ele ocorrer. 
 
 . Monitoramento : Designar uma pessoa para 
monitorar o risco e definir um ou mais critérios de 
medição, que permitam observar a evolução da 
condição de risco. 
 
 . Probabilidade : chance do risco ocorrer. 
3.5. Previsão de Risco 
 
A previsão de risco, também conhecida como estimativa 
de risco, tenta avaliar cada risco de dois modos: a 
probabilidade de que o risco seja real e as consequências 
associadas ao risco, se ele ocorrer. 
 52 
3.5.1. Desenvolvimento de uma tabela de Risco 
 
Uma tabela de risco fornece a um gerente de projeto uma 
técnica simples para previsão de risco 
 
Riscos Categ. Prob. Impacto RMMM 
Menor reutilização do que o planejado Tamanho 
Produto 
70% 2 
Usuários finais resistentes ao sistema Impacto 
negócio 
40% 3 
Prazo entrega será apertado Impacto 
Negócio 
50% 2 
Falta de treinamento uso ferramentas Ambiente 
desenvolvi
mento 
80% 3 
Pessoal inexperiente Tamanho e 
experiência 
equipe 
30% 2 
Cliente modificará os requisitos 
 
Tamanho 
produto 
80% 2 
Rotatividade do pessoal será alta Tamanho e 
experiência 
equipe 
60% 2 
 
 Valores de impacto 
1 – Negligível 
2 – Marginal 
3 – Crítico 
 4 – Catastrófico 
 
 Uma vez completadas as quatro primeiras colunas, a 
tabela é ordenada por probabilidade e por impacto. Riscos com 
alta probabilidade e alto impacto vão para o alto da tabela e 
riscos com baixa probabilidade vão para a parte de baixo. 
 
 Os riscos eleitos como prioritários, receberão na coluna 
RMMM(Risk Migration, Monitoring and Management) um 
ponteiro para um plano de Atenuação, monitoração e 
administração de risco. 
 
 
 53 
3.6. Atenuação, Monitoramento e Administração de 
Risco 
 
Todas as atividades de análise de risco apresentadas até o 
agora têm uma única meta, ajudar a equipe de projeto a 
desenvolver uma estratégia para lidar com o risco, 
considerando três pontos: 
. evitar o risco 
. monitorar risco 
. gerenciar risco e planejar para a contingência. 
 
 - Plano de Atenuação de risco: 
Exemplo de Risco : Alta rotatividade da equipe 
 
. Reunião com a equipe para determinar as causas da 
 rotatividade(p. ex. más condições de trabalho, baixa 
 remuneração, mercado de trabalho competitivo) 
.Atenue as causas que estão sob controle antes do 
 início do projeto 
.Uma vez iniciado o projeto, considere que a 
 rotatividade vai ocorrer e desenvolva técnicas para 
 assegurar a continuidade quando as pessoas saírem 
.Organize as equipes de projetos de modo que a 
 informação sobre cada atividade de 
 desenvolvimento seja amplamente difundida 
.Defina padrões de documentação 
.Conduza revisões de todo o trabalho aos pares(de 
 modo que mais de uma pessoa esteja “por dentro”) 
.Designe um membro da equipe para dar retaguarda 
 a cada técnico essencial. 
 
 
 
 
 
 
 
 
 54 
- Monitoração de Risco : 
 
A medida que o projeto avança, as atividades de 
monitoração de riscos iniciam. O gerente de projeto 
monitora fatores que podem indicar se o risco é mais 
ou menos provável. 
 
No caso da alta rotatividade da equipe, os 
seguintes fatores podem sem monitorados: 
 
. Atitude geral dos membros da equipe com base nas 
pressões do projeto 
. Relacionamento interpessoal entre os membros da 
equipe 
. Disponibilidade de emprego fora da empresa 
 
 Além de monitorar estes fatores, o gerente de 
projeto deve monitorar a efetividade dos passos para 
atenuação de risco. Por exemplo, um passo da 
atenuação de risco mencionado anteriormente pedia 
a definição de padrões de documentação. O gerente 
de projeto deve monitorar cuidadosamente os 
documentos, para certificar-se de que cada um é auto 
suficiente e que contém as informações necessárias. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 55 
- Gestão de Risco e Planejamento de 
contingência: 
 
Considerando que os esforços para atenuação 
falharam e que o risco tornou-se realidade. 
Seja o exemplo da alta Rotatividade da equipe. 
O projeto já está bem avançado e algumas 
pessoas avisam que vão sair. Se a estratégia de 
atenuação foi bem seguida, o apoio está disponível, a 
informação está documentada e o conhecimento foi 
difundido por toda a equipe. As pessoas que estão 
saindo são solicitadas a interromper todo o trabalho e 
Passar seus últimos dias envolvidos em 
“transferência” de conhecimento. 
 
Atenção: é importante notar que os passos de RMMM 
implicam em custo adicional para o projeto. Por 
exemplo, gastar tempo para “dar apoio” para cada 
técnico essencial custa dinheiro. Assim , parte da 
gestão de risco é avaliar quando os benefícios, 
obtidos pelos passos RMMM, são superados pelos 
custos associados com sua implementação. 
 
 
 Gerência de Riscos: 
 
 O objetivo não é identificar todos os riscos 
possíveis, mas apenas aqueles mais prováveis de 
acontecer. É aconselhável que os membros da equipe 
com alta capacidade se envolvam neste processo, 
uma vez que eles normalmente agem como “Advogado 
do diabo”, questionando quase tudo. Contudo o foco 
não é apenas apontar o problema, mas também 
verifiquem como podem ser resolvidos e como devem 
ser monitorados 
 56 
4. PLANEJAMENTO DE PROJETOS 
 
Projetos de Sistemas tem geralmente duas características 
bastante desagradáveis: 
 
 Estão atrasados 
 Seu custo supera as estimativas 
 
O Gerente de Projeto enfrenta problemas: 
 
 Pressões Políticas 
 Falta talento 
 Inexperiência 
Planejamento está diretamente ligado com desenvolvimento 
de um plano, que especifique: 
 
 O que deve ser feito 
 Quem deve realizar cada tarefa 
 Qual é o custo previsto 
A diferença entre Projetos bem-sucedidos e projetos 
fracassados está no modo pelo qual o Projeto é gerenciado. 
 57 
 
. Sucesso vs Fracasso em Projetos: 
 
Atributos 
Sucesso Fracasso 
 Cumprimento de prazos  Cancelamento 
 Cumprimento do 
orçamento 
 Gastos excessivos e não 
previstos 
 Alto nível de qualidade  Baixa qualidade 
 Alto nível de satisfação 
do usuário 
 Baixo nível de satisfação 
do usuário 
 
. Porque os Projetos Falham: 
 
Estudo de Thamhain e Willemon 
 Entrevistas com 304 Gerentes de Projeto 
 Análises de 180 projetos de porte 
 Áreas: eletrônica,petroquímica, construção e 
farmacêutica 
 
 Falta de planejamento 
 Plano de projeto otimista (não realista) 
 Subestimar o escopo do projeto 
 Alterações no cliente ou na gerência 
 Falta de planejamento das contingências 
 Inabilidade para acompanhar o progresso 
 Inabilidade de detectar os problemas 
antecipadamente 
 Poucos pontos de controle 
 Poucas pessoas na equipe 
 Complexidade técnica do projeto 
 Mudanças de prioridade 
 Falta de comprometimento da equipe 
 Falta de motivação da equipe 
 Pessoal não qualificado 
 
 58 
. Porque os Projeto de TI Falham: 
 . Estudo de Capers-Jones 
. 500 empresas 
. 6700 projetos 
 
 Taxa de falhas é muito maior que nas outras 
atividades – projetos de TI são atividades de 
risco. 
 Falhas em projetos de TI são mais freqüentes do 
que os sucessos (risco maior que 50%) 
 Taxas de falhas em projetos: aumentam com o 
tamanho do projeto. 
 
. O que falta nos Projetos de TI que falham ? 
 . Estudo de Capers-Jones 
 dados históricos de outros projetos 
 ferramentas de planejamento e estimativa 
 acompanhamento contínuo 
 metodologia de desenvolvimento 
 revisões e inspeções periódicas 
 gerência de risco 
 gerência de requisitos 
 gerência de configuração 
 teste formal 
 
. O que existe em comum nos Projetos de TI que 
falham ? 
 . Estudo de Capers-Jones 
 pressão excessiva no cronograma 
 rejeição das estimativas pelos executivos 
 atritos com clientes 
 política interna 
 falta de comunicação na equipe 
 executivos ingênuos com problemas de SW 
 qualificação em gerência de projetos 
 qualificação técnica da equipe 
 
 59 
. O que existe em comum nos Projetos de TI de 
sucesso ? 
. Estudo de Capers-Jones 
 planejamento de projetos 
 estimativa de custo 
 acompanhamento de projetos 
 uso de métricas 
 controle de qualidade 
 gerência de alterações 
 metodologia de desenvolvimento 
 participantes qualificados e especializados 
 reuso de material 
 
 
 
 60 
Métodos para Estimar Custos de Desenvolvimento De 
Software 
A dificuldade de produzir estimativas confiáveis gerou um 
esforço no sentido de desenvolverem métodos para estimar. 
Existem, assim, vários Métodos Propostos: 
1 – Modelos Algorítmicos. 
2 – Métodos baseados em julgamentos de Especialistas. 
3 – Métodos baseados em analogias com Projetos anteriores 
(TOP/BOTTOM). 
4.1. Modelos Algorítmicos 
 
Fornecem um ou mais algoritmos, que produzem uma 
Estimativa do custo do software em função de um número de 
variáveis consideradas as principais responsáveis pelo custo. 
As formas mais comuns são: 
 
4.1.1. Modelos lineares 
 
E = a0 + a1x1 + a2x2 + ..... + anxn 
 
 onde x1...xn são variáveis que influenciam no custo, a0... 
an são um conjunto de coeficientes. 
 
 
4.1.2. Modelos multiplicativos 
 
E = a0a1x1 a2x2 a3x3..................... anxn 
 
 
4.1.3. Modelos analíticos 
 
E = F(x1..........xn) 
 
 61 
4.1.4. Modelos tabulares 
 
Que contem tabelas que relacionam os valores das variáveis 
do esforço de desenvolvimento do software, ou a 
multiplicadores usados para calcular o esforço estimado. 
 
4.1.5. Modelos compostos: 
 
Que são uma combinação dos anteriores. 
4.2. Métodos Baseados em Julgamento de Especialistas 
Envolve consultar um ou mais especialistas, que utilizam 
sua experiência e entendimento do projeto proposto para 
chegar a uma estimativa do seu custo. 
4.3. Métodos Baseados em Analogias 
Envolve em raciocinar por analogia com um ou mais 
projetos já terminados para relacionar seu custo atual e uma 
estimativa de custo de um projeto similar novo. 
 
 TOP-DOWN: O custo do projeto é derivado das 
propriedades gerais do software produto. 
 BOTTOM-UP: O custo de cada componente é estimado 
por um indivíduo em geral o responsável pelo 
desenvolvimento do sistema. 
 
OBS: Na realidade, nenhuma destas alternativas é melhor 
do que as outras. 
Os pontos fortes e fracos das Técnicas se completam. O 
melhor é se utilizar uma combinação das técnicas e comparar 
e interagir as estimativas obtidas de cada uma. 
 62 
5. MÉTODOS DE ESTIMATIVA DE ESFORÇO, PRAZO, 
CUSTO 
 
Para auxiliar o Gerente do Projeto, nesta tarefa de elabora-
ção de estimativas, vamos ver 3 Métodos de Estimativas para 
Projetos de Sistemas. 
5.1. Método COCOMO (Construtive Cost Model) 
É um Modelo Algorítmico, composto, proposto por BARRY 
BOHEM da TRW em 1981 para estimar esforço de desenvol-
vimento, prazo e tamanho de equipe para um Projeto, a partir 
de uma amostra de 63 projetos, cobrindo áreas de negócios, 
científica, suporte. 
O COCOMO estima o esforço em profissionais/mês. 
O principal fator de esforço é o número de linhas de código-
fonte (SLOC-Source Line of Code) expressas em milhares de 
instruções fontes disponibilizadas. 
5.1.1. Modelos 
 COCOMO BÁSICO 
É uma versão aplicável a grande maioria de Sistemas: 
Pequenos a Médios Softwares, Desenvolvidos IN HOUSE. 
As estimativas fornecidas são limitadas, pois desconsideram 
fatores tais como limitações de Hardware, qualificação e 
experiência do Pessoal, uso de modernas Técnicas e 
Ferramentas. 
 
 COCOMO INTERMEDIÁRIO 
Já adiciona estes fatores proporcionando estimativas mais 
acuradas. 
 
 COCOMO DETALHADO 
Apresenta Técnicas para se estimar tanto a nível de Módulo, 
Subsistema, e Sistema individualizando a cada Fase de Projeto 
os atributos de custo. 
 63 
5.1.2. Definições e premissas do COCOMO: 
O Método categoriza os projetos de Sistemas em três tipos 
fundamentais: 
 
 
 MODO ORGÂNICO (“Convencional”): 
Equipes pequenas desenvolvem Sistemas num ambiente 
familiar. 
A maior parte das pessoas envolvidas no Projeto tem 
experiência com sistemas similares na organização. 
Tamanho Sistema < 50 KDSI 
Obs: DSI = (Delivered Source Instructions) Instruções fonte 
entregues 
 
 
 MODO DIFUSO: 
Representa um estágio intermediário entre os modos 
Orgânico e Restrito. 
Características: 
Equipe Heterogênea experiência 
Tamanho Sistema < 300 KDSI 
 
 
 MODO RESTRITO: 
Fator que distingue um Projeto é a necessidade de operar 
conforme grandes restrições. 
O produto deve operar dentro de um contexto complexo de 
Hardware, Software e regras e procedimentos, tal como um 
Sistema de Transferência eletrônica de fundos, ou Sistema de 
Tráfego Aéreo. 
 64 
5.1.3. Equações do COCOMO Básico 
Para se estimar esforço de desenvolvimento em termos 
Homem/Mês, prazo, tamanho de equipe. 
 
 ESTIMATIVA DE ESFORÇO 
 
MODO DESENVOLVIMENTO EQUAÇÕES 
. ORGÂNICO ESFORÇO(H/M)=2,4(KDSI)1,05 
. DIFUSO ESFORÇO(H/M)=3,0(KDSI)1,12 
. RESTRITO ESFORÇO(H/M)=3,6(KDSI)1,20 
 
 ESTIMATIVA DE PRAZO 
 
MODO DESENVOLVIMENTO EQUAÇÕES 
. ORGÂNICO PRAZO=2,5(H/M)0,38 
. DIFUSO PRAZO=2,5(H/M)0,35 
. RESTRITO PRAZO=2,5(H/M)0,32 
 
 Determinação do tamanho da Equipe necessária para o 
Projeto 
 
Tamanho da equipe = H/M 
 Prazo 
 
 EXEMPLO 1 
 
Dado um Sistema a ser desenvolvido no qual o número 
estimado de linhas de código (15 kdsi) e deseja-se saber a 
equipe ideal para o desenvolvimento deste sistema? 
Sabe-se que os membros da equipe de desenvolvimento 
têm experiência com sistemas similares (Equipe Homogênea). 
 
 65 
SOLUÇÃO: 
 
o ESFORÇO DE DESENVOLVIMENTO(ORGÂNICO) 
 
H/M = 2,4 (KDSI) 1,05 
 
H/M = 2,4 (15) 1,05 = 41,22 profissionais/mês 
 
 
o PRAZO DE DESENVOLVIMENTO(ORGÂNICO) 
 
PRAZO = 2,5 (H/M)0,38 
 
PRAZO = 2,5 (41,22) 0,38 = 10,27 meses 
 
o TAMANHO DA EQUIPE 
 
T.E = 41,22 H/M 
 10,27 M 
 
T.E = 4 profissionais. 
 
 
 66 
 
5.1.4. Equações do COCOMO Intermediário 
 
 ESFORÇO DE DESENVOLVIMENTO 
 
MODO DESENVOLVIMENTO EQUAÇÕES 
. ORGÂNICO ESFORÇO(H/M)=3,2(KDSI)1,05 
. DIFUSO ESFORÇO(H/M)=3,0(KDSI)1,12 
. RESTRITO ESFORÇO(H/M)=2,8(KDSI)1,20 
 
 PRAZO 
 
MODO DESENVOLVIMENTO EQUAÇÕES 
. ORGÂNICO PRAZO=2,5(H/M)0,38 
. DIFUSO PRAZO=2,5(H/M)0,35. RESTRITO PRAZO=2,5(H/M)0,32 
 
 TAMANHO DA EQUIPE 
 
Tamanho da equipe = H/M 
 Prazo 
 
 
As equações de estimativa de esforços são chamadas de 
estimativa nominal, que devem ser reajustadas por 
multiplicadores de esforço que são representados por 15 
fatores, divididos em quatro tipos de atributos: 
 
 ATRIBUTOS DO PRODUTO 
 ATRIBUTOS COMPUTACIONAIS 
 ATRIBUTOS DA EQUIPE 
 ATRIBUTOS DO PROJETO 
 67 
 ATRIBUTOS DO PRODUTO 
- RELY : Confiabilidade requerida pelo software 
- DATA : Tamanho da base de dados 
- CPLX : Complexidade do produto 
 
 ATRIBUTOS COMPUTACIONAIS 
- TIME : Restrições de execução (tempo máquina) 
- STOR: Restrições quanto ao uso da memória 
principal 
- VIRT : Volatibilidade do ambiente virtual 
- TURN: Tempo de resposta 
 
 ATRIBUTOS DA EQUIPE 
- ACAP : Capacidade dos analistas 
- AEXP : Experiência na aplicação 
- PCAP : Capacidade dos programadores 
- VEXP : Experiência em máquina virtual 
- LEXP : Experiência na linguagem de programação 
 
 ATRIBUTOS DO PROJETO 
- MODP : Técnicas modernas de programação 
- TOOL : Uso de ferramentas 
- SCED : Prazo requerido para o desenvolvimento 
 
 
Cada um destes fatores tem um peso, que são os 
multiplicadores, que ajustam para mais ou para menos as 
estimativas iniciais. 
Multiplicar a estimativa de profissional/mês inicial por cada 
um dos multiplicadores de esforço, ou seja: 
 
 Homem/mês x RELY x DATA x CPLX x TIME x STOR x 
VIRT x TURN x ACAP x AEXP x PCAP x VEXP x LEXP x MODP x 
TOLL x SCED 
 68 
A escolha dos atributos ou fatores de custo (muito baixo, 
baixo, nominal, alto, muito alto, extra alto) é feita em função 
da TABELA 8 e da TABELA 9. 
Por fim, existe uma tabela de fatores multiplicativos de 
esforço (TABELA 10). 
 
Para realizar a distribuição do esforço e do prazo, o Método 
COCOMO utiliza uma tabela padrão. 
 
Conceitua: 
 
. PROJETO PEQUENO 2 KDSI 
. PROJETO INTERMEDIÁRIO 8 KDSI 
. PROJETO MÉDIO 32 KDSI 
. PROJETO GRANDE 128 KDSI 
. PROJETO MUITO GRANDE 512 KDSI 
 
E distribui as estimativas de esforço por fase, conforme a 
TABELA 11: 
 
- Plano e requisito (Definição) 
- Desenho do produto (Projeto de arquitetura) 
- Programação (Projeto detalhado, codificação) 
- Integração e teste 
 
 EXEMPLO: 
 
 
Supondo : 
- RELY : ALTO : 1,15 
- DATA : ALTO : 1,08 
- CPLX : NOMINAL : 1,00 
- TIME : MUITO ALTO : 1,30 
- STOR : MUITO ALTO : 1,21 
- VIRT : NOMINAL : 1,00 
- TURN : BAIXO : 0,87 
- ACAP : ALTO : 0,86 
 69 
- AEXP : ALTO : 0,91 
- PCAP : NOMINAL : 1,00 
- LEXT : NOMINAL : 1,00 
- VEXP : NOMINAL : 1,00 
- MODP : NOMINAL : 1,00 
- TOOL : BAIXO : 1,10 
- SCED : MUITO ALTO : 1,10 
 
Combinados estes multiplicadores de esforços, eles dão 
origem a um fator de graduação igual a 1,60. 
 
o ESFORÇO DE DESENVOLVIMENTO(ORGÂNICO) 
 
H/M = 3,2 (KDSI) 1,05 
 
H/M = 3,2 (15) 1,05 = 54,96 profissionais/mês 
 
Esf. Dês(H/M) = 54,96 * 1,60 = 87,94 
 
o PRAZO DE DESENVOLVIMENTO(ORGÂNICO) 
 
PRAZO = 2,5 (H/M)0,38 
 
PRAZO = 2,5 (87,94) 0,38 = 13,7 meses 
 
o TAMANHO DA EQUIPE 
 
T.E = 87,94 H/M = 7 profissionais 
 13,7 M 
 70 
5.1.5. Equações do COCOMO Detalhado 
 
. Distribuição de Esforço e Prazo . Tabela 11 – Modo Orgânico 
 
1 . Distribuição do Esforço 
 
FASES(Dist. Esforço) % PARTICIPAÇÃO ESPORÇO P/ FASE 
Plano e Requisitos 6 5,28 
Projeto de arquitetura 16 15,67 
Programação 62 54,53 
Integração e teste 22 19,35 
 
2. Distribuição do Prazo 
 
FASES(Dist. Prazo) % PARTICIPAÇÃO Prazo p/ FASE 
Plano e Requisitos 12 1,65 
Projeto de arquitetura 19 2,61 
Programação 55 7,54 
Integração e teste 26 3,57 
 
 
 71 
5.2. Análise de Pontos de Função 
FPA : Function Point Analysis 
Os Pontos de função são uma medida utilizada para 
determinar o TAMANHO DE UMA APLICAÇÃO. Ela se baseia nas 
funções executadas pela aplicação do ponto de vista do 
usuário. 
Foi desenvolvido pela IBM 1979, por Allan Albrecht. 
Este processamento padrão é então ajustado pelo seu nível 
de complexidade que é determinado por características da 
aplicação, tais como: Comunicação, performance, volume das 
transações, facilidade de instalação. 
Site oficial: 
https://www.ifpug.org/ifpug-annual-meetings/?lang=pt 
Reuniões anuais 2010, 2013,2018 no Brasil 
No Brasil: 
bfpug@bfpug.com.br 
https://bfpug.wordpress.com/ 
 
5.2.1. Definições e Premissas 
As funções referenciadas são: 
 
 ENTRADA EXTERNA: 
Processo elementar que processa dados ou informações 
de controle vindos de fora da fronteira da aplicação. A 
principal intenção de uma EE é manter um ou mais ALI e/ou 
alterar o comportamento do sistema. 
Exemplos: 
. Transações que recebem dados externos utilizados na 
manutenção de ALI. 
. Processamento em lotes de atualização em bases 
cadastrais a partir de arquivos de movimento. 
NÂO Exemplos: 
 . Telas de filtro de relatórios e consultas 
 . Telas de login 
https://www.ifpug.org/ifpug-annual-meetings/?lang=pt
mailto:bfpug@bfpug.com.br
https://bfpug.wordpress.com/
 72 
 
 SAÍDA EXTERNA: 
Processo elementar que gera dados ou informações de 
controle que saem pela fronteira da aplicação. 
Principal objetivo de uma SE é apresentar dados ao usuário 
por meio de lógica de processamento que não seja apenas 
recuperação de dados. A lógica de processamento deve 
obrigatoriamente conter ao menos uma fórmula matemática 
ou cálculo, ou criar dados derivados. Pode também 
manter um ou mais arquivos lógicos internos e/ou 
alterar o comportamento do sistema. 
Exemplos: 
 . Relatórios com totalização de dados 
 . Relatórios que também atualizam arquivos 
. Consultar com apresentação de dados derivados ou 
cálculos. 
. Geração de arquivos de movimento para outra aplicação. 
. Informações em formatos gráficos. 
 
NÃO Exemplos: 
. Consultas e relatórios sem nenhum totalizador, que não 
atualiza ALI, não tem dado derivado ou modificam o 
comportamento do sistema. 
 
 ARQUIVOS LÓGICOS INTERNOS: 
Grupos lógicos de dados do ponto de vista do usuário cuja 
manutenção é feita internamente na aplicação. 
 
Exemplos: 
 . Tabelas que armazenam dados mantidos pela aplicação 
 . Arquivos de configuração mantidos pela aplicação 
. Arquivos de mensagem de erro desde que mantidos pela 
aplicação 
 73 
NÃO Exemplos: 
. Arquivos temporários ou de classificação 
. Arquivos gerados para processamento em outra 
aplicação. (*Atenção : Normalmente são considerados 
como Saída) 
. Arquivos de índice (*Atenção : São utilizados somente 
para melhorar a performance na recuperação de dados. 
Implementa requisitos NÃO FUNCIONAIS. 
 
 ARQUIVOS DE INTERFACE EXTERNA: 
Grupo lógico de dados que passa de uma aplicação para 
outra cuja manutenção pertence a outra aplicação. 
Exemplos: 
. Dados de referência externos que são utilizados pela 
aplicação 
. Arquivos de mensagem de erro, desde que mantidos por 
outra aplicação. 
 
NÃO Exemplos: 
. Arquivos de movimento recebidos de outra aplicação 
para manter um ALI. (*Atenção : Normalmente são 
considerados como Entrada) 
 
 CONSULTA EXTERNA: 
Processo elementar que envia dados ou informações de 
controle para fora da fronteira da aplicação. 
A principal intenção de uma CE é apresentar informação ao 
usuário por meio de uma simples recuperação de dados de 
ALIs e/ou AIEs. A lógica de processamento não deve conter 
fórmula matemática ou cálculo, criar dados derivados, manter 
um ou mais ALI e/ou alterar o comportamento do sistema. 
 
Exemplos: 
 . Telas de Help 
 . Drop-down, desde que recuperem dados de um arquivo. 
 . Telas de Login 
 74 
OBS: A F.P.A. pressupõe que: 
» Com 130 horas a medida de esforço de trabalho 
de um indivíduo durante um mês. 
5.2.2. Cálculo dos Pontos de Função 
 
Existem duas vertentes para contagem dos pontos de Função: 
IFPUG/CPM - International Function Point Users Group (Grupo 
Intenacional de Usuário de Pontos de Função) / 
CountingPractices Manual (Manual de práticas de contagem)e 
o NESMA - Netherlands Software Metrics Association 
(Associação de Métricas de Software da Holanda) 
https://nesma.org/nesma-standard-2-3/ 
 
1ª) A NESMA é uma organização similar ao IFPUG, fundada 
em 1989, também composta por voluntários, que mantém seu 
próprio Manual de Práticas de Contagens. 
 
A NESMA reconhece três tipos de contagem de pontos de 
função: 
- Contagem de pontos de função indicativa 
- Contagem de pontos de função estimativa 
- Contagem de pontos de função detalhada 
 
Os métodos indicativo e estimativo para a contagem de pontos 
de função foram desenvolvidos pela NESMA para permitir que 
uma contagem de pontos de função seja feita nos momentos 
iniciais do ciclo de vida de um sistema. A contagem indicativa 
da NESMA é também conhecida no mundo como "método 
holandês", hoje na versão 2.3 de 2018. 
 
Contagem Indicativa: 
 
Determina-se a quantidade das funções do tipo dado (ALIs e 
AIEs) calcula-se o total total de pontos de função não 
ajustados da aplicação da seguinte forma: 
tamanho indicativo (pf) = 35 x número de ALIs + 15 x número 
https://nesma.org/nesma-standard-2-3/
 75 
de AIEs. Portanto esta estimativa é baseada somente na 
quantidade de arquivos lógicos existentes (ALIs e AIEs). A 
contagem indicativa é baseada na premissa de que existem 
aproximadamente três EEs (para adicionar, alterar, e excluir 
dados do ALI), duas SEs, e uma CE na média para cada ALI, e 
aproximadamente uma SE e uma CE para cada AIE. 
 
Exemplo: 
 Requisitos do Usuário: 
O Usuário deseja manter dados de Cliente e Produto e 
referenciar dados de Fornecedor(externo ao Sistema) 
 Contagem indicativa: 
ALI: Cliente e Produto 
AIE: Fornecedor 
 
 
 
 
Contagem Estimativa: 
 
Determina-se todas as funções de todos os tipos (ALI, AIE, EE, 
SE, CE) toda função do tipo dado (ALI, AIE) tem sua 
complexidade funcional avaliada como Baixa, e toda função 
transacional (EE, SE, CE) é avaliada como de complexidade 
média calcula-se o total de pontos de função não ajustados. 
Logo, a única diferença em relação à contagem usual de 
pontos de função é que a complexidade funcional não é 
determinada individualmente para cada função, mas pré- 
definida para todas elas. 
 
 
 76 
Exemplo: 
 Requisitos do Usuário: 
O Usuário deseja adicionar, alterar, excluir e consultar 
dados de Cliente, e também necessita quatro diferentes 
tipos de relatórios sobre Cliente contendo dados 
calculados. 
O Usuário deseja adicionar, alterar, excluir e consultar 
dados de Produto, deseja também um relatório de Produto 
com dados calculados , e também necessita consultar o 
Fornecedor através do seu numero e um relatório sobre 
fornecedor com totalização de resultados. 
 
 
 
 
 
 
 
 77 
 
Contagem Detalhada: 
 
Similar ao IFPUG/CPM, determina-se todas as funções de 
todos os tipos (ALI, AIE, EE, SE, CE) determina-se a 
complexidade de cada função (Baixa, Média, Alta) calcula-se o 
total de pontos de função não ajustados. 
 
 78 
 
 
2ª) IFPUG/CPM 
 
 Identificar e enumerar as funções da aplicação: 
o Número de Entradas Externas 
o Número de Saídas Externos 
o Número de Arquivos Lógicos internos 
o Número de Arquivos de interface Externa 
o Número de Consultas Externas 
 Classificar cada uma das funções identificadas no seu 
nível de complexidade 
o SIMPLES 
o MÉDIO 
o COMPLEXO 
 Ajustar o número de pontos de função brutos ao nível de 
complexidade de processamento. 
 
OBS: Para se definir o nível de complexidade das funções, a 
F.P.A. utiliza tabelas (no Anexo): 
 
o TABELA 1: Entrada 
o TABELA 2: Saída 
o TABELA 3: Arquivo Lógico Interno 
o TABELA 4: Arquivo Interface Externa 
o TABELA 5: Consulta Externa 
 
 
 79 
 EXEMPLO: 
Suponha uma aplicação na qual identificamos 
- 3 entradas Externos (3 simples) 
- 2 Saídas Externos (1 simples, 1 médio) 
- 4 Arquivos Lógicos (3 simples, 1 médio) 
- 3 Arquivos Interface (2 simples, 1 médio) 
- 5 Consultas Externas (1 simples, 3 médio, 
 1 complexo) 
Na F.P.A., cada nível de complexidade tem um peso. 
Devemos então multiplicar o número de ocorrências de uma 
função pelo peso correspondente ao nível de complexidade, 
como mostrado a seguir. 
 
FUNÇÃO N. OCOR. COMPLEX PESO RESULTADO 
 *obs: TABELA 6 - tabela de peso 
 
Entrada Externo 3 Simples 3 9 
 
Saída Externo 1 Simples 4 4 
 1 Médio 5 5 
 
Arquivo Lógico 
interno 
3 Simples 7 21 
 1 Médio 10 10 
 
Arquivo Interface 
Externo 
2 Simples 5 10 
 1 Médio 7 7 
 
Consulta Externa 1 Simples 3 3 
 3 Médio 4 12 
 1 Complexo 6 6 
 Total de Pontos por função Brutos : 87 
 
Depois de calculado o total de Pontos por Função Brutos, 
devemos ajustá-los a complexidade do processamento. 
Ajuste: mais ou menos 35% (0,65 a 1,35) 
 80 
Para achar o fator de ajuste, devemos estimar o nível de 
influência para cada uma das características da aplicação 
relacionadas. 
5.2.3. Características da Aplicação 
 
1. COMUNICAÇÃO DE DADOS 
2. FUNÇÕES DISTRIBUÍDAS 
3. DESEMPENHO 
4. CARGA DE CONFIGURAÇÃO 
5. VOLUME DE TRANSAÇÕES 
6. ENTRADA DE DADOS ON LINE 
7. EFICIÊNCIA DO USUÁRIO FINAL 
8. ATUALIZAÇÃO ON LINE 
9. PROCESSAMENTO COMPLEXO 
10. REUTILIZAÇÃO 
11. FACILIDADE DE IMPLANTAÇÃO 
12. FACILIDADE OPERACIONAL 
13. MÚLTIPLOS LOCAIS 
14. FACILIDADE DE MUDANÇA 
 
O Nível de influência de cada característica é dado por uma 
escala de 0 a 5: 
 
0 = Não existe nenhuma influência 
1 = Pouca influência 
2 = Influência moderada 
3 = Influência média 
4 = Influência significativa 
5 = Grande influência 
 
Uma característica só estará qualificada para entrar no 
cálculo do nível de influência quando afeta o projeto, a 
implementação e suporte da aplicação. 
 
 81 
1. Considerações sobre nível de influência para cada uma 
das características (Fernandes, Aguinaldo Aragon - Gerência 
de Software Através de Métricas) 
 
 1. COMUNICAÇÃO DE DADOS: 
Os dados e informações de controle usados na aplicação são 
enviados ou recebidos através de recursos de comunicação. Os 
terminais conectados diretamente a unidade de controle 
costumam utilizar os recursos de comunicação. 
 
2. FUNÇÕES DISTRIBUÍDAS: 
Os dados ou as funções distribuídas constituem uma 
característica da aplicação. 
 
3. DESEMPENHO: 
Os objetivos de desempenho da aplicação, tanto na resposta 
ou no output, que influenciam o projeto, o desenvolvimento, a 
instalação e o suporte da aplicação. 
 
4. CARGA DE CONFIGURAÇÃO: 
O Usuário deseja processar a aplicação no seu equipamento 
atual ou na expansão proposta. 
 
5. VOLUME DE TRANSAÇÕES: 
O volume de transações é alto e influencia o projeto, o 
desenvolvimento, a instalação e o suporte da aplicação. 
 
6. ENTRADA DE DADOS ON LINE: 
A aplicação promove a entrada de dados on-line e funções 
de controle. 
 
7. EFICIÊNCIA DO USUÁRIO FINAL: 
As funções on-line fornecidas enfatizam a eficiência do 
usuário final. 
 
8. ATUALIZAÇÃO ON LINE: 
 82 
A Aplicação possibilita a atualização on-line dos arquivos 
lógicos internos (Real Time). 
 
9. PROCESSAMENTO COMPLEXO: 
Muitas interações de controle e pontos de decisão. 
Equações matemáticas e lógicas extensas. 
Grande quantidade de processamento de exceções. 
 
10. REUTILIZAÇÃO: 
A aplicação, e o código da aplicação, ou um percentual dela 
foram especialmente projetados, desenvolvidos e receberam 
suporte para sua reutilização em outras aplicações e em 
outros locais. As seguintes percentagens são usadas: 
 
0 - 10% :0 
11 - 20% :1 
21 - 30% :2 
31 - 40% :3 
41 - 50% :4 
Acima 50% :5 
 
11. FACILIDADE DE IMPLANTAÇÃO: 
Um plano de implantação e conversão foi fornecido e 
testado durante a fase de teste do sistema. 
 
12. FACILIDADE OPERACIONAL: 
Métodos eficazes de inicialização, back-up e recuperação 
foram fornecidos e testados durante a fase de teste do 
sistema.