Técnicas de estimativa de esforço e custo

Prévia do material em texto

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 1/43
Técnicas de estimativa de esforço e custo
Prof. Bruno Freitas Braga
Descrição
Definição e aplicação de técnicas de estimativa de esforço e custo para o gerenciamento de projetos de
software.
Propósito
Compreender as técnicas de estimativa de esforço e custo é essencial para os profissionais de Tecnologia
de Informação (TI) escolherem a abordagem mais adequada para o gerenciamento de seus projetos de
software, em processos de desenvolvimento convencionais ou ágeis.
Objetivos
Módulo 1
Estimativas de esforço e custo utilizando COCOMO
Aplicar cálculos para fazer estimativas de esforço e custo utilizando COCOMO.
Módulo 2
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 2/43
Técnicas PERT e CPM
Empregar as técnicas PERT e CPM para estimar a duração de projetos de software.
Módulo 3
Métricas de estimativas em projetos ágeis
Analisar as métricas utilizadas para fazer estimativas em projetos ágeis.
Neste conteúdo, aprenderemos as principais técnicas utilizadas para fazer estimativas de esforço,
custo, duração e tamanho, as quais são essenciais para se fazer o planejamento e o acompanhamento
de projetos de software.
Iremos apresentar os modelos matemáticos e aplicar as equações derivadas de estudos e melhores
práticas realizados pelos principais Engenheiros de Software do segmento de métricas.
Vamos fazer cálculos utilizando fórmulas do modelo COCOMO (COnstructive COst MOdel) como
referência, para realizar estimativas de esforço e custo a partir de exemplos do cotidiano.
Utilizando os métodos PERT (Program Evaluation and Review Technique) e CPM (Critical Path Method),
iaprenderemos a fazer estimativas de duração do projeto que são essenciais para a elaboração de
cronogramas.
Finalmente, serão apresentadas as métricas utilizadas para o gerenciamento de projetos ágeis e como
aplicá-las.
Introdução
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 3/43
1 - Estimativas de esforço e custo utilizando COCOMO
Ao �nal deste módulo, você será capaz de aplicar cálculos para fazer estimativas de esforço e
custo utilizando COCOMO.
COCOMO I
O Modelo Construtivo de Custos ou COCOMO (COnstructive COst MOdel) foi desenvolvido e apresentado em
1981, por Barry W. Boehm. É um modelo empírico de custos, baseado no estudo de sessenta e três projetos
de software, nos quais se examinaram de 2.000 a 100.000 linhas de código em linguagens de programação
diversas, variando de Assembly a PL/I.
O COCOMO é um modelo matemático de base empírica utilizado para estimativa de esforço, custos e tempo
requerido para o desenvolvimento de um projeto. Os parâmetros básicos que definem a qualidade de
qualquer produto de software, que também são um resultado do COCOMO, são esforço e duração:
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 4/43
Quantidade de trabalho despendido nas atividades de um projeto de software, medido em unidades
de pessoas.mês (lê-se pessoas-mês), isto é, o número de pessoas multiplicado pelo número de
meses em que elas estiverem envolvidas.
Tempo necessário para o desenvolvimento do trabalho, isto é, o resultado da divisão do esforço pelo
número de pessoas, medido em meses.
Classi�cação dos sistemas para aplicação do COCOMO
A versão original do modelo COCOMO passou a ser designada como COCOMO I ou COCOMO 81 após o
advento de sua segunda versão, COCOMO II, em 1994. O COCOMO I define três modos de desenvolvimento,
ou tipos de projeto a estimar, segundo o tamanho e a complexidade do sistema, para adaptar as fórmulas
(que são sempre as mesmas), mudando somente os fatores e os expoentes. As classes de sistema são:
Esforço 
Duração 
Orgânico ou simples
Sistemas de complexidade relativamente baixa, com menos de 50 KLOC (mil linhas de
código), nos quais se possui experiência em projetos similares e que se encontram em
ambientes estáveis de desenvolvimento.
Semidestacado
Sistemas médios em complexidade e tamanho (menores do que 300 KLOC), em que a
experiência com esse tipo de projeto é variável e as restrições intermediárias.
( )
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 5/43
A fórmula para calcular o esforço de um projeto de software depende primeiramente da quantidade de
linhas de código expressas em KLOC (mil linhas de código), que define o tamanho físico do projeto que se
pretende desenvolver. A partir dela, podemos classificar o tipo do projeto, ou seja, Orgânico, Semidestacado
ou Embutido, derivando-se valores de constantes obtidas a partir de uma tabela desenvolvida por Boehm. A
equação para realizar esse cálculo é dada por:
$$\begin{equation} $$ \frac{\text { d_observado }}{\text { (d_max - d_min) }} $$ \end{equation}$$
pessoa.mês
Os valores das constantes a e b são derivados da tabela a seguir:
Projeto de Software a b c d
Orgânico 3,2 1,05 2,5 0
Semidestacado 3,0 1,12 2,5 0
Embutido 2,8 1,20 2,5 0
Tabela: Constantes para o cálculo de estimativas.
Traduzida e adaptada por Bruno Freitas Braga de Boehm, 1981, p. 209.
As constantes a e b são utilizadas para calcular o esforço, ou seja, a quantidade do trabalho necessário para
concluir o projeto, enquanto as constantes c e d são utilizadas para calcular o tempo de desenvolvimento do
projeto em meses. Por exemplo, se o meu projeto for Orgânico, ou seja, com menos do que 50 KLOC, irei
aplicar a seguinte fórmula:
$$E S F=3,2 * K L O C^{1,05}$$
Já, se o meu projeto for Semidestacado, isto é, entre 50 e 300 KLOC, irei aplicar a fórmula a seguir:
$$E S F=3,0 * K L O C^{1,12}$$
Embutido (embedded)
Sistema muito complexo, nos quais se tem pouca experiência e que se encontra em um
ambiente de grande inovação técnica. Ademais, o projeto trata de requisitos muito restritivos
e de grande volatilidade, problema único, difícil de se basear na experiência.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 6/43
E, se o meu projeto for muito complexo e único, como projetos que envolvem algoritmos genéticos, por
exemplo, ou um projeto militar de um software com Inteligência Artificial para teleguiar mísseis, podemos
aplicar a seguinte fórmula:
$$E S F=2,8 * K L O C^{1,20}$$
É importante salientar que nem sempre é possível se obter a quantidade de linhas de código nas fases
iniciais do projeto, mesmo utilizando bases de dados históricas de projetos da sua empresa ou obtidas no
mercado e, nesse caso, existe uma técnica que faz a previsão de linhas de código a partir do tamanho
funcional do projeto utilizando pontos de função, conhecida como Backfiring, que disponibiliza tabelas de
conversão entre pontos de função e linhas de código por linguagem de programação ou por área de
negócio. Nesse caso, pode-se utilizar essa técnica para estimar o tamanho físico do seu projeto (KLOC) e, a
partir dele, fazer as estimativas iniciais de esforço, tempo e custos. Baseado no esforço, que aprendemos a
calcular anteriormente, podemos estimar o tempo de desenvolvimento do projeto em meses, utilizando a
seguinte equação:
$$T D E S=c * E S F^{d}$$ meses
Os valores das constantes c e d são obtidos da Tabela 1 já apresentada. Por exemplo, se o meu projeto for
classificado como orgânico, irei aplicar a fórmula como está a seguir:
$$T D E S=2,5 * E S F^{0,38}$$
Se o projeto for classificado como semidestacado ou embutido, basta substituirmos os valores das
constantes c e d pelo seu respectivo valor obtido na Tabela 1. Finalmente, o número médio de pessoas na
equipe do projeto, distribuídas ao longo do tempo, pode ser calculado pelaseguinte fórmula:
Equipe média $$=\frac{E S F}{T D E S}$$ pessoas
Modelos de estimativa do COCOMO
Além da classificação dos projetos para fins de utilização do COCOMO (projeto: Orgânico, Semidestacado
ou Embutido), existem diferentes modelos de estimativa que podem ser aplicados dependendo do contexto
e da complexidade do projeto:
Modelo COCOMO básico
Trata de estimar, de uma maneira rápida, a maioria dos projetos pequenos e médios.
Modelo COCOMO intermediário
Introduz 15 atributos de custo para levar em consideração o ambiente de trabalho. Esses 15 atributos são
como perguntas sobre a viabilidade de desenvolvimento.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 7/43
Modelo COCOMO detalhado
Incorpora todas as características da versão intermediária e aqui se aplica toda a Engenharia de Software,
como o seu ciclo de vida e os modelos.
Aplicando o modelo COCOMO básico
Para entendermos melhor como fazer a estimativa de custos baseada nos modelos apresentados, faremos
um exemplo prático a seguir utilizando o modelo de estimativa básico.
1º passo: Estimativa da qualidade da instrução
$$L O C=120 * F D E / S$$
Em que:
LOC = Quantidade de linhas de código que o sistema terá.
FD E/S = Fluxo de entrada + fluxo de saída do sistema (pode-se usar diagrama de casos de uso).
O primeiro valor (120) é fixo e foi determinado por Boehm. Supondo que o nosso sistema possua 15 casos
de uso, para calcular LOC, substituiremos a variável FD E/S por esse valor, como demonstramos a seguir:
$$L O C=120 * 15=1800$$ linhas de código
Agora, iremos converter o LOC para a unidade de medida KLOC (mil linhas de código) aplicando a equação
abaixo:
$$K L O C=\frac{L O C}{1000}$$
Logo, dividindo 1.800 linhas de código, que foi o resultado que obtivemos, por 1.000, chegaremos ao valor
de 1,8 KLOC, ou seja, o nosso sistema terá 1,8 mil linhas de código-fonte.
2º passo: Estimativa do esforço ou equação de esforço
Como estimamos que o tamanho do nosso projeto será de 1,8 KLOC; então, classificamos o nosso projeto
como Orgânico, pois tem menos do que 50 KLOC. A partir dessa informação, podemos utilizar a Tabela 1
para calcular o esforço do projeto em pessoas.mês. Logo:
$$E S F=a * K L O C^{b} \rightarrow E S F=3,2 *(1,8)^{1,05} \rightarrow E S F=5,93$$ pessoas.mês
3º passo: Estimativa de tempo de desenvolvimento
Como estimamos que o esforço do nosso projeto será de 5,93; então, podemos aplicar a equação a seguir
para calcular o tempo de desenvolvimento do projeto em meses substituindo as constantes c e d pelos
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 8/43
valores contidos na tabela Constantes para o cálculo de estimativas, lembrando que o nosso projeto foi
classificado como Orgânico.
$$T D E S=c * E S F^{d} \rightarrow T D E S=2,5 *(5,93)^{0,38} \rightarrow T D E S=4,92$$ meses
4º passo: Estimativa do pessoal necessário
Tendo estimado o esforço e o tempo de desenvolvimento, para calcularmos a quantidade média de pessoas
necessárias ao longo do projeto, basta dividir o esforço em pessoas.mês pelo tempo em meses.
Equipe média $$=\frac{E S F}{T D E S} \rightarrow$$ Equipe média $$=\frac{5,93}{4,92} \rightarrow$$ Equipe
média $$=1,21$$ pessoas
Esse número médio de pessoas significa que, ao longo do tempo de desenvolvimento (aproximadamente 5
meses), a equipe necessária será formada por 1 a 2 pessoas, de modo que, na média, a equipe será de 1,21
pessoas.
5º passo: Estimativa de produtividade
Antes de estimar o custo do meu projeto, é importante calcularmos com que produtividade devo trabalhar e
a que velocidade estou trabalhando. Podemos calcular a produtividade, ou seja, a quantidade de linhas de
código que cada programador irá produzir em cada mês, utilizando a equação a seguir:
$$P=\frac{L O C}{E S F}$$
Como já estimamos que o nosso software terá 1.800 LOC (linhas de código) e que o esforço para o
desenvolver será de 5,93 pessoas.mês, aplicando a equação de produtividade, chegaremos ao resultado de
303,54, o que dá aproximadamente 304 linhas de código. Devemos nos basear nesse indicador para
controlar o que está acontecendo no projeto, ou seja, se a produtividade estiver mais baixa do que esse
valor, não iremos alcançar os objetivos do projeto e, se estiver muito superior a essa média, pode indicar que
há algum problema no projeto. Devemos procurar manter a produtividade do projeto próximo dessa média.
6º passo: Estimativa de custo
Para calcularmos o custo da equipe (em reais), iremos utilizar a fórmula a seguir:
Custo da equipe $$=E S F * C P$$
Sendo ESF igual ao esforço que já calculamos no valor de 5,93 pessoas.mês e a constante CP
correspondente ao custo da pessoa por mês, isto é, o salário mensal dos trabalhadores do projeto. Se
considerarmos um salário médio de desenvolvedor de software no Brasil, para efeito de cálculo, podemos
atribuir o valor de R$3.500,00 ao CP. O valor do CP pode variar e depende muito do nível e da especialidade
do profissional que irá ser contratado. A seguir, iremos aplicar a equação para obter o custo da equipe no
projeto:
Custo da equipe $$=5,93 * 3.500,00=R \$ 20.755,00$$
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 9/43
Atenção
É importante salientar que estamos aqui calculando somente o custo do desenvolvimento do software,
desconsiderando outros custos envolvidos, como o do investimento em marketing, o da compra de
computadores, dentre outros.
Veja, a seguir, um demonstrativo de como fazer uma estimativa de custo considerando os outros custos
envolvidos, em que se destaca o custo da mão de obra, até porque custos de equipamentos podem ser
diluídos em vários projetos.
Investimento do projeto
Custo da equipe R$20.755,00
1 computador i7 de 8ª geração R$5.000,00
Outros equipamentos R$3.000,00
Cartuchos de impressora R$300,00
Custo da implantação R$1.800,00
Total R$30.855,00
Estimativa de custos totais do projeto.
Elaborada por Bruno Freitas Braga
COCOMO intermediário
O modelo do COCOMO básico assume que o esforço é somente uma função baseada no número de linhas
de código e algumas constantes avaliadas de acordo com os diferentes tipos de software. Entretanto, na
realidade, o esforço e a duração do projeto não devem ser calculados baseando-se somente na quantidade
de linhas de código. Existem vários outros fatores que influenciam, como: confiabilidade, experiência,
capacidade, dentre outros. Esses fatores são conhecidos como cost drivers (ou fatores de custo) e o
COCOMO intermediário utiliza 15 fatores para realizar as estimativas de custos, que são classificados
conforme podemos observar na tabela a seguir:
Fatores de custo Muito baixo Baixo Nominal A
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 10/43
Fatores de custo Muito baixo Baixo Nominal A
Atributos do produto
Confiabilidade de
software exigida
0,75 0,88 1,00 1
Tamanho do banco
de dados
0,94 1,00 1
Complexidade do
produto
0,70 0,85 1,00 1
Atributos de hardware
Restrições de
desempenho de
tempo de execução
1,00 1
Restrições de
memória
1,00 1
Volatilidade do
ambiente da
máquina virtual
0,87 1,00 1
Tempo de retorno
necessário
0,87 1,00 1
Atributos pessoais
Capacidade como
analista
1,46 1,19 1,00 0
Experiência com
aplicações
1,29 1,13 1,00 0
Capacidade como
engenheiro de
software
1,42 1,17 1,00 0
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 11/43
Fatores de custo Muito baixo Baixo Nominal A
Experiência com
máquina virtual
1,21 1,10 1,00 0
Experiência em
Linguagem de
Programação
1,14 1,07 1,00 0
Atributos de projeto
Aplicação de
métodos de
Engenharia de
Software
1,241,10 1,00 0
Uso de ferramentas
de software
1,24 1,10 1,00 0
Cronograma de
desenvolvimento
necessário
1,23 1,08 1,00 1
Tabela: Fatores de custo do COCOMO Intermediário.
Traduzida e adaptada por Bruno de Freitas Braga, de Boehm, 1981, p. 210.
O gerente de projetos deve classificar esses 15 atributos para um projeto específico, na escala de valores
“muito baixo” a “muito alto”. Desse modo, o valor de cada fator de custo é obtido da tabela acima. Esses 15
valores são, então, multiplicados para calcular o EAF (fator de ajuste do esforço). Note que o fator de custo
de valor nominal será sempre igual a 1, significando que não influirá no valor final de EAF.
$$E A F=\prod_{i=1}^{i=15}(\text { Fator de custo })_{i}$$
A fórmula do COCOMO intermediário assume a seguinte forma:
$$E S F=\left(a * K L O C^{b}\right) * E A F$$
Os valores das constantes a e b no COCOMO intermediário são os mesmos valores utilizados no modelo
COCOMO básico.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 12/43
COCOMO II
O modelo COCOMO II é um modelo paramétrico, criado pela USC - University of Southern California, no
mesmo departamento do professor Barry Boehm, em meados de 1994. Esse modelo permite calcular o
esforço, o custo e o prazo de um projeto através de equações matemáticas complexas, que levam em
consideração particularidades de cada projeto, como: características do produto, processo, experiência da
equipe e plataforma de desenvolvimento.
Esses fatores são também denominados cost drivers (ou fatores de custo), como extensão ao modelo
intermediário do COCOMO I, sendo alguns fatores de efeito linear e outros de efeito exponencial. Para
implantar esse novo modelo, as organizações precisam de uma base histórica de projetos, suficiente para
estudos estatísticos. Normalmente, as empresas iniciam o uso do COCOMO II quando as técnicas de
estimativas de projetos, como APF (Análise de Pontos de Função) e Nesma (Netherlands Software Metrics
Association– Associação de Métricas de Software da Holanda), já estão consolidadas.
O modelo COCOMO II foi desenvolvido a partir do modelo COCOMO I, em virtude do surgimento de novas
linguagens de programação e de abordagens mais modernas para o desenvolvimento de software, tais
como os ambientes de desenvolvimento rápido (RAD – Rapid Application Development), processos ágeis,
componentização e novas tecnologias de banco de dados.
O COCOMO II é composto por quatro submodelos que são:
Modela o esforço necessário para desenvolver sistemas criados a partir de componentes reusáveis,
scripts ou programação de banco de dados. Suas estimativas de tamanho baseiam-se em pontos de
aplicação. Esses pontos são calculados de acordo com: o número de telas separadas que são
exibidas; o número de relatórios que são produzidos; o número de módulos em linguagens de
programação imperativas (como o Java); e o número de linhas de linguagem de script ou código de
programação de banco de dados (SOMMERVILLE, 2011).
Modelo de composição da aplicação 
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 13/43
Esse modelo é usado durante as fases iniciais de projeto do sistema, após os requisitos serem
estabelecidos. Suas estimativas são baseadas nos pontos de função, os quais são convertidos em
linhas de código, com uso de tabelas de correspondência dependendo da linguagem de
programação.
É usado para calcular o esforço necessário para integrar os componentes reusáveis e/ou códigos de
programa gerados automaticamente.
Esse modelo inclui um conjunto de 17 multiplicadores, refletindo a capacidade pessoal, o produto e
as características do projeto.
Na imagem a seguir, podemos visualizar os modelos de estimativa que acabamos de descrever:
Modelos de estimativa
Estimativa de esforço e custo de software usando o
Modelo de projeto preliminar 
Modelo de reuso 
Modelo de pós-arquitetura 

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 14/43
modelo COCOMO
No vídeo a seguir, descrevemos a aplicação de cálculos para estimativa de esforço e custo de
desenvolvimento de software usando o modelo COCOMO I (básico e intermediário) e abordamos as
extensões do COCOMO II.
Vem que eu te explico!
Os vídeos a seguir abordam os assuntos mais relevantes do conteúdo que você acabou de estudar.
COCOMO I básico
01:57 min.
COCOMO II
02:02 min.
MÓDULO 1
Vem que eu te explico!
COCOMO I básico
01:57 min.



04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 15/43
COCOMO II
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Sobre o modelo COCOMO (COnstructive COst MOdel) analise as seguintes alternativas e marque a opção
correta:
A O modelo COCOMO é um modelo empírico baseado em pontos de função.
B
O modelo COCOMO classifica os projetos em três classes que variam conforme o
tamanho do projeto, em linhas de código, e a sua complexidade.
C
Os projetos classificados como “Orgânicos” são aqueles que possuem complexidade
média e tamanho acima de 200 KLOC.
D
O modelo básico do COCOMO leva em consideração um fator de ajuste para realizar o
cálculo do esforço do projeto.
E
O modelo avançado do COCOMO é recomendado para projetos estáticos que possuam
até 50 KLOC.
Parabéns! A alternativa B está correta.
O modelo COCOMO classifica os projetos em três classes: Orgânico, Semidestacado e Embutido.
O tipo Orgânico é recomendado para projetos pequenos com até 50 KLOC (mil linhas de código),
enquanto o tipo Semidestacado é recomendado para projetos intermediários, com até 200 KLOC
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 16/43
e, por fim, o tipo Embutido é recomendado para projetos muito complexos, que demandem grande
inovação tecnológica.
Questão 2
O Modelo COCOMO II surgiu devido à evolução da área de Ciência da Computação. Sobre esse modelo,
analise as alternativas abaixo e marque a opção correta:
A
O modelo COCOMO II não é um modelo empírico e sim um modelo baseado em
algoritmos matemáticos.
B
O modelo COCOMO II incorpora quatro submodelos que produzem estimativas cada vez
mais detalhadas.
C
O submodelo de composição da aplicação se baseia no número de pontos de função da
aplicação.
D
O submodelo de reuso é usado por sistemas de protótipo desenvolvidos usando scripts e
programação de banco de dados.
E
O submodelo de pós-arquitetura utiliza número de pontos de aplicação para estimar o seu
tamanho.
Parabéns! A alternativa B está correta.
O modelo COCOMO II incorpora quatro submodelos: modelo de composição da aplicação, modelo
de projeto preliminar, modelo de reuso e modelo de pós-arquitetura. Cada um desses submodelos
é empregado de acordo com o perfil do projeto que se pretende desenvolver, como protótipo, ou
integração de componentes reusáveis ao sistema, dentre outros.

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 17/43
2 - Técnicas PERT e CPM
Ao �nal deste módulo, você será capaz de empregar as técnicas PERT e CPM para estimar a
duração de projetos de software.
Contextualização
A fase de estimativa da duração de um projeto é um dos principais desafios dos gerentes de projetos e, por
se tratar de uma atividade complexa, é um dos pontos que merecem atenção, pois falhas cometidas nessa
fase podem comprometer o sucesso do projeto.
O PMI (Project Management Institute ou Instituto de Gerenciamento de Projetos), desde as primeiras
publicações do seu guia PMBOK (Project Management Body of Knowledge ou Conjunto de Conhecimentos
em Gerenciamento de Projetos), atualmente na 7ªedição, vem dedicando uma área de conhecimento
exclusivamente ao gerenciamento do cronograma do projeto, que fornece as diretrizes e as técnicas mais
eficazes utilizadas pelas indústrias de Engenharia, TI, dentre outras.
Atenção
Antes de identificar e listar todas as atividades do projeto a partir das quais são criados o cronograma e o
orçamento do projeto, é importante conhecermos de onde são derivadas essas atividades, segundo o guia
PMBOK.
Uma área de conhecimento denominada gerenciamento do escopo do projeto descreve uma ferramenta
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 18/43
importante que nos fornece uma visão do projeto como um todo, conhecida como WBS (Work Breakdown
Structure ou Estrutura Analítica do Projeto).
Essa ferramenta utiliza uma técnica de decomposição que divide o projeto em partes menores e mais fáceis
de gerenciar. São dessas partes menores, conhecidas como entregáveis (deliverables), que derivamos as
atividades do projeto.
Para simplificarmos o entendimento, cada entregável do projeto possui um conjunto de atividades, e a soma
dos valores das atividades de cada entregável nos fornecem as estimativas de duração e de custos do
entregável em questão. Por fim, a soma das estimativas de todos os entregáveis nos fornecem as
estimativas do projeto. Segue um exemplo de uma WBS de um projeto de software organizado em fases de
desenvolvimento:
WBS de um Projeto de Software.
Essa abordagem mais tradicional proposta pelo PMI é recomendada para o gerenciamento de projetos
grandes e complexos como a construção de uma aeronave, a construção de foguetes espaciais ou a criação
de um software estratégico de satélite para monitoramento da floresta amazônica, por exemplo.
Gerenciar projetos desse porte envolve uma série de fatores complexos que
precisam ser identificados, planejados e monitorados.
Com o intuito de elaborar estimativas mais assertivas e gerenciá-los melhor, foram propostos os métodos
PERT (Program Evaluation and Review Technique ou Técnica de Revisão e Avaliação de Programa),
associado ao CPM (Critical Path Method ou Método do Caminho Crítico), os quais realizam suas análises e
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 19/43
avaliações partindo do nível das atividades do projeto. Ambos os métodos são essenciais nas fases de
planejamento e de controle do projeto.
Apesar das técnicas PERT e CPM terem sido desenvolvidas independentemente em torno de 1958, o forte
relacionamento entre elas fez com que o termo fosse utilizado corriqueiramente como apenas uma técnica,
denominada PERT/CPM.
Saiba mais
É importante salientar que existem outras técnicas para estimar as durações das atividades do projeto,
como a estimativa analógica, que obtém os parâmetros de projetos já realizados para realizar as estimativas
dos projetos futuros, a estimativa paramétrica, a análise de reservas, dentre outras. Nesse estudo, daremos
enfoque aos métodos PERT e CPM.
A técnica de Avaliação e Revisão de Programa (PERT)
A técnica PERT, conhecida também como estimativa de três pontos, foi criada em 1958 nos Estados Unidos
pela NASA e consiste em descobrir a duração de uma atividade, baseando-se em três estimativas possíveis
para a atividade que são: Otimista, Pessimista e Mais Provável. Essa técnica visa reduzir as chances de
falhas na implementação dos novos projetos, levando-se em consideração os riscos envolvidos em cada
etapa do projeto, para se chegar a uma estimativa mais precisa, e é preciso contar com a experiência de
especialistas para empregá-la.
A combinação das três estimativas possíveis é o grande diferencial do método
PERT, porque pondera os riscos e as incertezas pertinentes à atividade em questão
do projeto.
Primeiramente, devemos obter com os especialistas as estimativas Otimista, Pessimista e Mais Provável
para uma atividade. O PMBOK define esses três pontos da seguinte forma:
Mais Provável ($$t_{M}$$) 
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 20/43
A duração da atividade, dados os prováveis recursos a serem designados, sua produtividade,
expectativas realistas de disponibilidade para executar a atividade, dependências de outros
participantes e interrupções.
A duração da atividade é baseada na análise do melhor cenário para a atividade.
A duração da atividade é baseada na análise do pior cenário para a atividade.
Usando a média ponderada dessas três estimativas, a análise PERT calcula a duração esperada da atividade
($$t_E$$), utilizando a equação a seguir:
$$t_{E}=\frac{t_{O}+4 t_{M}+t_{P}}{6}$$
Como podemos observar, a fórmula PERT aplica um peso maior, igual a 4, para a estimativa Mais Provável
($$t_{M}$$), mas não deixa de considerar as estimativas Otimista($$t_{O}$$) e Pessimista($$t_{P}$$),
ambas com peso 1. É possível, inclusive, alterar os pesos nos seus projetos de acordo com a sua realidade,
porém os pesos não podem ultrapassar a soma total de 6.
Segundo o PMBOK, estimativas de duração baseadas nessa equação (ou até mesmo usando uma média
simples dos três pontos) podem fornecer mais precisão e os três pontos esclarecem a faixa de variabilidade
das estimativas de duração.
Exemplo de aplicação de PERT
Para entendermos a aplicação da técnica PERT, vamos a um exemplo muito simples. Suponhamos que um
profissional de TI seja designado para realizar a atividade de implantar o software da empresa em um novo
cliente. Essa atividade envolve tarefas, como: criar uma instância do Oracle no servidor de banco de dados
do cliente; criar um esquema de banco de dados; fazer a importação do arquivo (dump) nesse esquema; e,
por fim, instalar o software correspondente ao servidor de aplicação em um outro servidor reservado para
esse fim. Os especialistas de TI se reuniram e fizeram as seguintes estimativas:
Otimista ($$t_{O}$$) 
Pessimista ($$t_{P}$$) 
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 21/43
Estimativa Mais Provável ($$t_{M}$$) = 3 dias
Considera que o cliente não irá disponibilizar um profissional de TI para apoiar e acompanhar o
procedimento e que o Oracle já estará instalado no servidor de banco de dados, assim como um servidor
já estará disponível para instalar o software correspondente ao servidor de aplicação.
Estimativa Otimista ($$t_{O}$$) = 1 dia
Considera que o cliente irá disponibilizar um profissional de TI para apoiar e acompanhar o procedimento
e que o Oracle já estará instalado no servidor de banco de dados, assim como um servidor já estará
disponível para instalar o software correspondente ao servidor de aplicação.
Estimativa Pessimista ($$t_{P}$$) = 8 dias
Considera que o cliente não irá disponibilizar um profissional de TI para apoiar e acompanhar o
procedimento e que o Oracle não estará instalado no servidor de banco de dados, muito menos o cliente
terá disponibilizado um servidor de banco de dados e um servidor de aplicação para instalar o software.
Nesse caso, haverá a necessidade de tarefas adicionais para implantar o software, como instalar e
configurar o Oracle, dentre outras.
A seguir, vamos aplicar a fórmula PERT para estimarmos a duração dessa atividade:
$$t_{E}=\frac{1+(4 * 3)+8}{6}=3,5$$ dias
O tempo esperado para a atividade ser concluída é de 3,5 dias. Considerando que um dia de trabalho dura 8
horas, podemos converter o tempo esperado para a realização dessa atividade para 28 horas, ou seja, 3 dias
e 4 horas.
Calculando o desvio padrão da atividade
O método PERT leva em consideração também o quanto a duração estimada poderá variar para mais ou
para menos. Essa variação é conhecida como desvio padrão e podemos aplicar a fórmula a seguir para
efetuar o seu cálculo:
Desvio Padrão $$=\frac{t_{P}-t_{0}}{6}$$Aplicando o desvio padrão na atividade que utilizamos anteriormente como exemplo, onde $$t_{P}$$ = 8
dias e $$t_{O} = 1$$ dia, teremos como resultado um desvio padrão de 1,17 dia. Assim, essa atividade será
executada em 3,5 dias com um desvio padrão de +/- 1,17 dia, ou seja, tem duração estimada em um
intervalo entre 2,33 dias e 4,67 dias.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 22/43
Dica
Quanto maior for o desvio padrão, mais incerta é a sua estimativa para a atividade, pois a variação entre os
cenários otimista e pessimista é muito significativa.
Calculando a variância e o desvio padrão do projeto
A variância é uma medida de dispersão, que mostra o quão distante cada valor de um conjunto de dados
está do valor central (médio). No caso das estimativas de duração no PERT, calcula-se a variância aplicando
a fórmula abaixo:
Variância $$= (Desvio Padrão)_{2}$$
Para a atividade que estamos utilizando como exemplo, o valor da variância será,
portanto, igual a $$(1,17)_{2} = 1,37$$.
Para descobrir qual é o desvio padrão do projeto, não se deve somar os desvios padrões de todas as
atividades. Deve-se calcular a variância de cada atividade, somá-las e, por fim, tirar a raiz quadrada do
resultado para encontrar o Desvio Padrão do projeto, isto é:
$$$ \text { Desvio padrão do projeto }=\sqrt[2]{\sum_{i=1}^{n} \text { Variância }_{i}} $$$
Em que n é o número de atividades do projeto.
Dica
A técnica PERT pode ser utilizada para todas as atividades do projeto, ou somente para aquelas que
envolvam maior risco, quando não se tem muita certeza da estimativa e a variação entre o melhor e o pior
cenário é grande. Após você encontrar a estimativa PERT das atividades, estabelecer a sequência e a
dependência entre elas, você conseguirá chegar à duração do Projeto.
O método do caminho crítico (CPM)
Em um projeto, a maior parte das atividades possui relação de dependência umas com as outras e, para
entendermos esse conceito, vamos fazer uma analogia com uma situação real na área da construção civil.
Suponhamos que um engenheiro esteja construindo uma casa: quando a “atividade de fundação” for
concluída, a “atividade de levantar as paredes” se inicia, e posteriormente a “atividade de colocar o telhado”,
e assim por diante. Ou seja, há uma relação de dependência entre essas três atividades e uma não pode ser
iniciada sem a conclusão da outra. No mundo do software, essas relações funcionam da mesma maneira.
Não podemos implementar as linhas de código sem conhecermos o requisito em questão, por exemplo.
Essas atividades que possuem esse tipo de relação de dependência são fortes candidatas a estarem no
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 23/43
caminho crítico do projeto, pois, se ocorrer um atraso em uma delas, o cronograma do projeto será
prejudicado.
O CPM (Critical Path Method ou Método do Caminho Crítico) foi criado pela empresa norte-americana
Dupont, por volta do ano de 1958, com o objetivo de realizar as paradas de manutenção no menor prazo
possível e com o nível constante de utilização dos recursos. Esse método é considerado uma extensão da
técnica PERT, pois é utilizado no gerenciamento de projetos mais complexos e extensos, porém pode ser
também aplicado em projetos simples.
Segundo o PMBOK, 6ª edição:
o caminho crítico é a sequência de atividades que representa o caminho mais
longo de um projeto, que determina a menor duração possível dele.
(PMBOK 2017, p. 210)
Ou seja, em um projeto, há vários caminhos possíveis (sequência de atividades), até
que o projeto seja executado em sua totalidade, e o caminho crítico corresponda ao
percurso que impacta diretamente no sucesso do projeto, aquele que ofereça maior
risco.
Partindo do princípio de que um projeto é um conjunto de subprojetos, com inúmeras tarefas relacionadas a
eles, é preciso compreender qual a relação entre as atividades e como melhorar a interação entre elas. Isso
porque as atividades devem ser sequenciadas da melhor maneira para que o projeto flua e seja concluído
com o melhor prazo possível, e é justamente para isso que serve o caminho crítico do projeto.
O método basicamente consiste em criar um diagrama de rede, interligando as atividades em sequência
com as suas respectivas dependências. São analisados os caminhos de ida e de volta através da rede. Por
fim, o caminho crítico é o caminho percorrido através da sequência das atividades que não tem folga, ou
seja, caso uma delas atrase, todo o projeto estará atrasado. Contudo, caso uma atividade de um caminho
não crítico atrase, não há problema, pois entre elas há uma folga capaz de absorver esse atraso.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 24/43
O caminho crítico aponta quais atividades o gerente de projetos e responsáveis
devem ter a atenção redobrada.
Aplicando o Método do Caminho Crítico
Como pré-requisitos para analisarmos os caminhos possíveis das atividades, devemos primeiramente
estimar a duração de cada atividade, e a técnica PERT, como já vimos, possibilita que façamos essa
estimativa. Depois, iremos identificar as atividades predecessoras de cada atividade, conforme veremos no
exemplo a seguir:
Atividade Predecessora Duração
Início - 0
A Início 5
B A 5
C A 10
D B,C 15
Fim 15 0
Exemplo de lista de atividades.
Elaborada por Bruno Freitas Braga
Depois, devemos montar o diagrama de rede mostrando a sequência em que as atividades ocorrem e os
seus relacionamentos, para analisarmos os caminhos possíveis e encontrarmos o caminho crítico do
projeto, conforme podemos ver a seguir no diagrama de rede derivado do quadro anterior:
Exemplo de uso do Método do Caminho Crítico.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 25/43
Conforme observamos nesse exemplo, há dois caminhos que podem ser percorridos do início ao fim que
são os caminhos A-B-D e A-C-D. Vimos que as atividades A e B tem duração de 5 dias, enquanto a atividade
C tem duração de 10 dias, e a atividade D tem duração de 15 dias. Logo, o caminho A-B-D tem duração de 25
dias e o caminho A-C-D tem duração de 30 dias. Portanto, o caminho crítico para esse exemplo é o caminho
A-C-D, pois o caminho crítico corresponde ao caminho mais longo que deve ser seguido para que todas as
atividades sejam concluídas.
Outro dado importante que podemos extrair do exemplo anterior é a quantidade total de folga livre ou de
flexibilidade do cronograma, ou seja, a quantidade de tempo que uma atividade do cronograma pode atrasar
sem adiar a data de início da atividade sucessora. Vimos que a atividade B possui uma folga de 5 dias, isto
é, se a atividade B atrasar em até 5 dias não comprometerá o início da atividade D e, por fim, não afetará a
conclusão do projeto. Observando também as atividades que fazem parte do caminho crítico, ou seja, as
atividades A, C e D, notamos que todas elas possuem folga igual a zero, ou seja, um mínimo de atraso que
ocorra em uma delas impactará todo o cronograma.
Comentário
Agora, vamos aprender a calcular as datas dos caminhos de ida (início mais cedo, término mais cedo) e de
volta (início mais tarde, término mais tarde), utilizando o diagrama de rede do exemplo anterior. Lembrando
que essas datas não correspondem a uma data do calendário, e sim uma indicação dos períodos de tempo
dentro dos quais a atividade poderia ser executada.
Percorrendo o caminho de ida (início mais cedo, término mais cedo)
Obtemos o caminho de ida fazendo a leitura das atividades da esquerda para a direita no diagrama de rede,
do início ao fim. Durante essa travessia, preenchemos os quadrados superiores, correspondentes ao início
mais cedo e término mais cedo, em cada atividade.
Porconvenção, o início do projeto começa no dia 1, então, continuando com o exemplo anterior, colocamos
na atividade A o início mais cedo com o valor = 1. Para calcularmos o término mais cedo, iremos usar a
seguinte equação:
Término mais cedo = Início mais cedo + Duração -1
Subtraímos o resultado por 1, porque incluímos o próprio dia da data de início mais cedo nessa conta, ou
seja, consideramos o intervalo total entre as datas.
Para a atividade A, como o início mais cedo possui valor = 1 e a sua duração = 5, então, aplicando a
equação, teremos: término mais cedo = 1 + 5 – 1 = 5.
Para o início mais cedo das atividades sucessoras, nós adicionamos 1 dia após o término mais cedo da
atividade predecessora, pois assumimos que a atividade predecessora foi concluída até o final do dia (de
término mais cedo), logo:
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 26/43
Início mais cedo sucessora = Término mais cedo predecessora +1
Assim, as atividades B e C serão iniciadas com o valor = 6. Para descobrirmos o término mais cedo dessas
duas atividades, aplicamos a equação anterior e chegamos aos resultados de término mais cedo para as
atividades B = 10 e C = 15.
Para calcularmos o início mais cedo da atividade D, observamos que temos duas atividades predecessoras
a esta que são as atividades B e C. Nesse caso, há uma regra que define: quando uma atividade tiver mais
de uma predecessora, escolha sempre a predecessora que possua a maior data de término mais cedo como
a sua data de início mais cedo. Como a maior data de término está na atividade C, cujo valor = 15, então a
atividade D será iniciada um dia após este término, ou seja, valor = 16. Por fim, aplicando-se a equação para
encontrarmos o término mais cedo da atividade D, chegamos ao valor = 30. Dessa forma, descobrimos que
a duração do projeto é de 30 dias.
Percorrendo o caminho de volta (término mais tarde, início mais tarde)
O caminho de volta nós obtemos fazendo a leitura das atividades da direita para a esquerda no diagrama de
rede, do fim para o início. Durante essa travessia, nós preenchemos os quadrados inferiores,
correspondentes ao término mais tarde e início mais tarde, em cada atividade. Por convenção, assumimos
que o término mais tarde das atividades predecessoras ao fim corresponde ao maior valor do término mais
cedo das atividades ligadas ao fim, logo a atividade D terá o valor = 30 para o término mais tarde.
Para calcularmos o início mais tarde, iremos usar a seguinte equação:
Início mais tarde = Término mais tarde - Duração +1
Para o término mais tarde das atividades predecessoras, nós subtraímos 1 dia do início mais tarde da
atividade sucessora, logo:
Término mais tarde predecessora = Início mais tarde sucessora -1
Assim, as atividades B e C terão o valor = 15 no seu término mais tarde, considerando que o início mais
tarde da atividade D tem valor = 16. Aplicando a equação anterior para descobrirmos o início mais tarde das
atividades B e C, chegamos aos resultados de início mais tarde para as atividades B = 11 e C = 6.
Para calcularmos o término mais tarde da atividade A, observamos que temos duas atividades sucessoras a
esta que são as atividades B e C. Nesse caso, há uma regra que define que: quando uma atividade tiver mais
de uma sucessora, escolha sempre a menor data de início mais tarde entre as sucessoras como data de
término mais tarde da predecessora. Como a menor data de início mais tarde entre as atividades
sucessoras B e C está na atividade C cujo valor = 6, então o término mais tarde da atividade A terá o valor =
5. Por fim, aplicando-se a equação para encontrarmos o início mais tarde da atividade A, chegamos ao valor
= 1.
Calculando as folgas
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 27/43
Para calcularmos as folgas, basta subtrairmos os números de baixo pelos números de cima para cada
atividade, logo:
Folga $$=$$ Início mais tarde $$-$$ Início mais cedo
Ou
Folga $$=$$ Término mais tarde $$-$$ Término mais cedo
As atividades que possuírem a folga igual a zero são as atividades que fazem parte do caminho crítico.
Assim, a folga da atividade A será 5 - 5 = 0, então essa atividade faz parte do caminho crítico. Já a folga da
atividade B será 15 – 10 = 5, portanto essa atividade não faz parte do caminho crítico.
Dica
Para visualizarmos rapidamente o caminho crítico devemos, ainda, observar os números de cima e de baixo
em cada atividade do diagrama de rede, e as atividades que possuírem esses números iguais serão as
atividades que fazem parte do caminho crítico, ou seja, para o exemplo que vimos é o caminho A-C-D.
É importante destacar que existem softwares que fazem esses cálculos de forma
automatizada, associando a técnica PERT ao método CPM, como o MS-Project, o
ProjectLibre, o Primavera, dentre outros.
Aplicar o método PERT/com
No vídeo a seguir, abordamos a aplicação do método PERT/CPM no gerenciamento de projetos de software.
Vem que eu te explico!
Os vídeos a seguir abordam os assuntos mais relevantes do conteúdo que você acabou de estudar.


04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 28/43
Técnica PERT
05:12 min.
Método CPM
05:12 min.
MÓDULO 2
Vem que eu te explico!
Técnica PERT
05:12 min.
Método CPM
Falta pouco para atingir seus objetivos.
Vamos praticar alguns conceitos?
Questão 1
Sobre a técnica PERT, podemos afirmar que:
A
baseia-se somente na opinião de especialistas para fazer a estimativa de duração das
atividades.
B
baseia-se somente na aplicação de equações matemáticas para se obter a estimativa de
duração das atividades.



04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 29/43
C
baseia-se na análise de três cenários, que são: Otimista, Mais Provável e Pessimista para
cada atividade do projeto.
D
o resultado obtido durante a aplicação desta técnica não leva em consideração a variância
da duração da atividade que se está estimando.
E
para se obter o desvio padrão total do projeto, basta somarmos os desvios padrões de
cada atividade.
Parabéns! A alternativa C está correta.
A técnica PERT tem por objetivo estimar a duração de cada uma das atividades do projeto
baseando-se na avaliação dos especialistas, os quais analisam os cenários Otimista, Mais
Provável e Pessimista, e atribuem uma duração para cada um dos três, e aplicando uma equação
obtém o resultado da estimativa de duração da atividade. Esta técnica também utiliza um desvio
padrão para indicar o intervalo de tempo em que a atividade poderá ser realizada, para mais ou
para menos do que foi estimado.
Questão 2
Sobre o método do caminho crítico, podemos afirmar que:
A
busca identificar as tarefas de menor prioridade nas sequências de atividades a fim de
calcular a duração total do projeto.
B
a partir de uma lista de atividades este método identifica as atividades que são
independentes e calcula a duração total do projeto.
C
o caminho crítico corresponde à sequência das atividades que possuem folga superior a
zero.
D
utiliza um diagrama de rede para verificar as relações de dependência entre as atividades
e identificar o caminho crítico.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 30/43
3 - Métricas de estimativas em projetos ágeis
Ao �nal deste módulo, você será capaz de analisar as métricas utilizadas para fazer
estimativas em projetos ágeis.
Contextualização
Os métodos ágeis surgiram em 2001, quando Kent Beck e outros 16 renomados profissionais da área de
E
analisando apenas o caminho de ida, é possível calcular as folgas que têm por objetivo
identificar qual é o caminho crítico.
Parabéns!A alternativa D está correta.
O método do caminho crítico utiliza um diagrama de rede interligando as atividades em sequência
com as suas respectivas dependências. Utilizando PERT, estima-se a duração de cada uma das
atividades e, percorrendo os caminhos de ida e de volta no diagrama de rede, identificamos as
atividades que fazem parte do caminho crítico, ou seja, aquelas atividades que possuem folga
igual a zero.

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 31/43
Engenharia de Software se reuniram nas montanhas nevadas do estado norte-americano de Utah para
escreverem um documento, conhecido como Manifesto Ágil, o qual descrevia os valores e os doze
princípios da “filosofia” ágil.
Com o Manifesto Ágil, criou-se uma organização permanente que o representava e, assim, no final do ano de
2001, nasceu a Agile Alliance (Aliança Ágil). Dessa forma, cada método ágil existente hoje, como o Scrum, o
Kanban e o XP (eXtreme Programming ou Programação Extrema), carrega consigo os valores e os princípios
arraigados no Manifesto Ágil.
De acordo com Pressman (2016, p. 67), “em essência, os métodos ágeis se desenvolveram em um esforço
para sanar fraquezas reais e perceptíveis da engenharia de software convencional”.
Vamos analisar a imagem a seguir para entendermos essa declaração do Pressman.
Comparação Modelo Cascata x Modelo Iterativo.
Na comparação entre o Modelo de Desenvolvimento de Software Convencional (Cascata) e o Modelo Ágil
(Iterativo), podemos observar que:
Modelo Convencional (Cascata)
Organiza o projeto inteiro em fases, ou seja, para a fase seguinte começar, a fase anterior deve
terminar, e assim sucessivamente. O término de cada uma dessas fases pode durar meses.

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 32/43
Modelo Ágil (Iterativo)
Organiza o projeto em iterações, sendo que cada iteração ocorre como se fossem miniprojetos, ou seja,
realiza todas as fases contidas no modelo convencional em cada uma das iterações, que,
normalmente, ocorrem entre 15 e 30 dias.
Concluímos que, utilizando o método ágil, o custo de mudanças é menor, pois uma mudança nos requisitos,
por exemplo, pode ser implementada mais cedo, sem a necessidade de aguardar o término de uma fase,
que poderia durar meses, como ocorria nos métodos convencionais. Dessa forma, os métodos ágeis
priorizam as tarefas que agregam mais valor ao negócio para serem realizadas primeiro, isto é, desde as
primeiras iterações, a fim de reduzir os riscos que podem afetar o cronograma e o orçamento do projeto,
que, se detectados tardiamente, podem levar o projeto ao fracasso.
Como os métodos ágeis incentivam o desenvolvimento do software sem a necessidade de conhecer
detalhadamente todos os requisitos do projeto, como fazer, então, estimativas mediante esse cenário de
incertezas? Esse é o objetivo das técnicas que apresentaremos neste estudo.
Planning Poker
O Planning Poker (ou Planejamento de Pôquer) é uma técnica de obtenção de consenso, similar ao método
de Delphi, muito utilizada para se fazer estimativas em projetos ágeis. Consiste na combinação de três
técnicas: opinião de especialista, analogia e desagregação, destaca COHN (2005), o que a torna um método
bastante interativo e prático.
As estimativas são obtidas através de um jogo de cartas, que são distribuídas entre os membros da equipe
de desenvolvimento (programadores, testadores, analistas, dentre outros), e cada um dos membros utiliza
as cartas para avaliar a complexidade de uma história do usuário (user story), levando-se em consideração o
fator tempo e esforço.
Cada carta possui uma pontuação e as cartas que possuírem pontuação maior correspondem àquelas de
maior complexidade.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 33/43
É importante salientar que uma equipe ágil não deverá exceder a dez pessoas.
Para efeito de entendimento, a história do usuário corresponde a uma descrição curta e simples da
necessidade do usuário, ou seja, ela nada mais é do que a descrição de um requisito sob o ponto de vista do
usuário.
No Planning Poker, cada integrante tem à sua disposição um baralho com 12 cartas, numeradas numa
sequência similar à sequência de Fibonacci (que considera o número seguinte sempre a soma dos dois
números anteriores), conforme podemos ver na imagem a seguir:
Cartas de Planning Poker
Valores acima de 20 são considerados altos e, portanto, trata-se de uma história grande, que pode não ser
completamente finalizada numa única iteração (denominada Sprint na maioria dos métodos ágeis, como o
Scrum).
Dica
Uma alternativa é detalhar mais a história, quebrando-a em pedaços menores, com redução em suas
complexidades. O recomendável é que, ao final do Planning Poker, consiga-se fazer com que as histórias da
iteração possuam algum valor do intervalo de 1⁄2 a 13. No entanto, é necessário evitar outro problema que é
deixar que as histórias se tornem muito pequenas, pois isso provavelmente tornará a equipe vítima do
microgerenciamento, destaca Kniberg (2009).
Depois que os membros recebem as cartas, cada um mostra ao mesmo tempo a carta que corresponde à
sua avaliação sobre a complexidade da história em questão. Se elas são todas iguais, a história recebe a
estimativa; se não, os membros que propõem a estimativa mais alta e a mais baixa explicam seus pontos de
vista e novas rodadas são jogadas até a equipe chegar a um consenso.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 34/43
Se um participante atribuir a uma história o valor ‘0’ (zero), significa que a história está finalizada, ou que ela
é tão pequena que pode ser resolvida em questão de minutos. No entanto, se um participante levantar a
carta com ‘?’ (interrogação) indica que ele não tem o conhecimento necessário para estimar o esforço
daquela história. Essas cartas não são frequentemente utilizadas, porém devemos levá-las em consideração
durante o jogo e avaliar as opções para a resolução da história em questão, de modo que a equipe chegue
ao consenso.
Saiba mais
A grande vantagem de se utilizar essa técnica é que ela incentiva os membros da equipe a pensarem por si
próprio na hora de tomar uma decisão de estimativa, pois todos levantam uma carta ao mesmo tempo
durante uma rodada do jogo.
Após a equipe chegar ao consenso durante a avaliação de uma história, começa uma nova rodada do jogo
com a leitura da próxima história, e o processo se repete até que se conclua a estimativa de todas as
histórias do usuário dos itens do Product Backlog – lista com todos os requisitos que se tem conhecimento
e que precisam estar no produto.
Ao final do jogo, é possível priorizar quais histórias deverão ser realizadas primeiro, ou seja, aquelas que
possuem maior pontuação, e ordená-las no Product Backlog. Essas histórias correspondem àquelas que
oferecem maior risco ao projeto e que agregam maior valor ao negócio.
Durante a realização das primeiras iterações, é possível obter o indicador de produtividade da equipe,
conhecido no meio ágil como velocity (velocidade), que indica a quantidade de pontos que a equipe
consegue entregar ao final de cada iteração. A partir desse indicador, conseguimos prever quantos pontos
poderão ser entregues nas próximas iterações. Dessa forma, pode-se estabelecer o comprimento da
iteração.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 35/43
Para calcularmos o número de iterações necessárias para se concluir o projeto, nós dividimos o número
total de pontos pela velocidade. Assim, para estimarmos a duração do projeto, somamos a quantidade de
iterações pelo tempo estimadode realização de cada iteração, que normalmente ocorre entre 15 e 30 dias
nos projetos ágeis.
Atenção
Essa técnica não é a mais adequada para estimativas de prazo e de alocação de recursos, pois é uma
medida de complexidade subjetiva e particular de cada time. No entanto, ela reforça o comprometimento da
equipe com as entregas e aumenta a colaboração entre os membros do time, de modo que todos se
sentirão responsáveis pelo projeto.
Ideal Days
Cohn (2005) defende que um Ideal Day (Dia Ideal) corresponde à quantidade de trabalho que um profissional
de nível sênior, com fluência nas tecnologias e nas ferramentas envolvidas, consegue realizar em um dia de
trabalho sem interrupções. Trata-se de uma estimativa empírica, executada por especialistas para
desenvolvimento com base em exploração adaptativa (ALVES; FONSECA, 2008).
A produtividade da equipe (velocidade) é calculada a partir do número de horas que a equipe gasta para
implementar um trabalho equivalente a um Dia Ideal. Caso não seja possível implementar o item em
questão em um dia de trabalho, é sugerido decompor esse item em itens menores para que se consiga
implementar em apenas um dia. Segundo Martins (2007), para efetuar o cálculo dos dias estimados, utiliza-
se a seguinte fórmula:
$$D E=\frac{I E D}{1-I E D_{-} R E A L \%}$$
Em que:
DE: Quantidade de dias estimados para concluir a tarefa.
IED: Prazo necessário para implementar o item, definido pela equipe.
IED_REAL%: Percentual que indica a estimativa de quanto tempo do dia o desenvolvedor ficará
dedicado à implantação do item.
Caso prático de aplicação da técnica
Alves e Fonseca (2008) exemplificam um caso prático de aplicação da técnica Ideal Day:
Considerando que uma jornada de trabalho de uma equipe tem 4 horas diárias, estipula-se um
valor de referência, ou seja, 1 Ideal Day = 4 horas.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 36/43
Veja a lista a seguir com o planejamento dos requisitos que serão implementados nessa iteração (Sprint):
RF01 – Implementar carrinho de compras – 0,5 ID.
RF02 – Cadastrar Livros – 0,3 ID.
RF03 – Consultar livros por autor – 0,1 ID.
RF04 – Implementar recomendação automática de livros – 0,4 ID.
Observando a lista dos requisitos funcionais (RF), cada membro da equipe irá retirar uma tarefa e
implementá-la, apropriando as horas gastas para realizar esse desenvolvimento no final do dia, pois, ao final
da iteração, será possível determinar quantos Ideal Days foram concluídos, bem como o seu tempo de
execução.
Uma vez definido o valor do requisito em Ideal Days, este não poderá mais ser alterado durante a iteração,
somente o esforço para realizá-lo. Por exemplo, suponhamos que o recurso 1 (algum membro do time) irá
implementar o RF01, que tem 0,5 ID. Como estamos ainda na primeira iteração e não existem dados
históricos para determinar o esforço do recurso, iremos utilizar empiricamente o valor de 10 horas como a
velocidade do time, conforme determinamos anteriormente. Aplicando a equação a seguir, faremos uma
estimativa de duração da tarefa:
Esforço $$=$$ Tamanho * Velocidade
Isto é, como o tamanho = 0,5 ID e a velocidade = 10 horas, então chegaremos ao resultado de uma duração
prevista de 5 horas (meio Ideal Day) para fazermos o desenvolvimento desse requisito – RF01.
Depois, determina-se a velocidade média inicial dessa equipe, por exemplo, velocidade = 10
horas, sendo que este último dado é resgatado de um histórico ou inicialmente definido por
um especialista de maneira empírica.
Então, avalia-se a lista com os itens do Backlog fazendo as suas estimativas em Ideal Day, as
quais são atribuídas via Planning Poker.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 37/43
Recomendação
Caso a tarefa não seja concluída em 1 dia, será necessário decompor o requisito em partes menores, e
considerar a parte concluída até o final do dia como finalizada para, dessa forma, evidenciarmos o trabalho
que foi realizado.
Após a implementação, poderemos analisar a eficácia das nossas estimativas, comparando o que foi
planejado com o que foi realizado, ou seja, medido. Vide o quadro a seguir com os dados apurados após a
implementação:
Requisito Tamanho previsto Recurso Hora real
RF01 0,5 ID Recurso 1 4,5 horas
RF02 0,3 ID Recurso 2 2,5 horas
RF03 0,1 ID Recurso 1 1,5 horas
RF04 0,4 ID Recurso 2 3 horas
TOTAL 1,3 ID 11,5 horas
Quadro: Dados apurados.
Extraída de Alves e Fonseca, 2008, p. 12.
Analisando esses dados, verificamos que o recurso 1 implementou dois requisitos – RF01 e RF03 –
totalizando 0,6 ID, enquanto o recurso 2 implementou outros dois requisitos – RF02 e RF04 – totalizando 0,7
ID. Para calcularmos a nova velocidade, iremos utilizar os dados da tabela a seguir:
Velocidade inicial ID previsto ID realizado H
Recurso 1 10 0,6 0,6 6
Recurso 2 10 0,7 0,7 5
Tabela: Dados por recurso.
Extraída de Alves e Fonseca, 2008, p. 12.
Aplicando a equação a seguir, que considera as horas de retrabalho, ou seja, o tempo gasto com correções,
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 38/43
iremos calcular a velocidade da próxima iteração:
(Horas realizadas + (horas retrabalho * 1,3)) /ID_realizados
Assim, considerando 1 hora de retrabalho para cada recurso, teremos:
para o Recurso 1 => (6 + 1 * 1,3) / 0,6 = 12,2 horas
para o Recurso 2 => (5,5 + 1 * 1,3) / 0,7 = 9,8 horas
Portanto, a média da equipe foi de 11 horas, e essa média será considerada para planejar a próxima
iteração, ao invés do valor empírico de 10 horas que estávamos utilizando nessa primeira iteração. Já a
produtividade da equipe corresponde ao número de Ideal Days entregues ao final da iteração, que para essa
primeira foi de 1,3 ID.
Para calcularmos a produtividade da Release, isto é, a produtividade da entrega de uma versão do produto,
poderemos aplicar a seguinte equação:
$$ \text { Produtividade da Release }=\frac{\text { ID }_{-} \text {Realizados }}{\text { Número de Sprints }} $$
Por exemplo, se planejarmos que o nosso primeiro Release terá 3 iterações, então, como já temos a
produtividade do primeiro Sprint que foi de 1,3 ID, e a equipe entregar nos outros dois Sprints 0,9 ID e 1,1 ID
respectivamente, a produtividade média da equipe será de 1,1 ID, aplicando-se a equação anterior, ou seja:
$$ \text { Produtividade da Release }=\frac{1,3+0,9+1,1}{3}=1,1 \text { ID } $$
Resumindo
Assim como no Planning Poker, a utilização da técnica de Ideal Day para medir o tamanho de uma atividade
utilizando uma unidade de tempo (no caso, dias ideais) nem sempre é uma boa estratégia, pois utiliza
critérios subjetivos que podem variar de um time para o outro. Porém, combinando-se as técnicas ágeis com
as técnicas tradicionais, pode-se chegar a um denominador comum e obter-se estimativas mais assertivas.
Processos ágeis no desenvolvimento de software
Está na hora de abordarmos uma visão geral dos métodos ágeis no contexto da Engenharia de Software.
Vamos lá!

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 39/43
Vem que eu te explico!
Os vídeos a seguir abordam os assuntos mais relevantes do conteúdo que você acabou de estudar.
Planning poker
02:44 min.
Ideal days
02:04 min.
MÓDULO 3
Vem que eu te explico!
Planning poker
02:44 min.
Ideal days
Falta pouco para atingir seus objetivos.




04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 40/43
Vamos praticar alguns conceitos?
Questão 1
Sobre a técnica de estimativa para projetos ágeis conhecida como Planning Poker, analise as alternativas
abaixo e marque a opção correta.
A
As estimativas baseiam-se nas opiniõesdos membros da equipe mais sêniores, a fim de
se obter resultados mais precisos e eficazes.
B
As estimativas são obtidas através de um jogo de cartas, as quais possuem uma
pontuação de acordo com a complexidade da história que está sendo avaliada.
C
Esta técnica foi desenvolvida para ser realizada por grandes equipes, maior do que 50
pessoas, e busca avaliar as histórias do usuário mais complexas, a fim de se economizar
tempo com planejamento que poderia ser despendido na execução do projeto.
D
As pontuações atribuídas às cartas do jogo de baralho não têm relação com a
complexidade da história que se está avaliando, e sim com o tempo que será utilizado
para desenvolvê-la.
E
Durante uma rodada do jogo, primeiramente, os membros mais sêniores da equipe
levantam as suas cartas e, depois, os outros membros mostram as suas, para assim, os
outros membros serem influenciados pela opinião dos especialistas e, consequentemente,
aprenderem a fazer melhores estimativas.
Parabéns! A alternativa B está correta.
O Planning Poker é uma técnica que consiste em avaliar as histórias dos usuários, ou seja, os
requisitos sob o ponto de vista deles, através de um jogo de baralho, em que cada rodada os
membros da equipe avaliam uma história e atribuem uma pontuação a ela, de acordo com a sua
avaliação individual sobre a complexidade da história que está sendo analisada. O consenso do
grupo será a pontuação final da história.
Questão 2
Sobre a técnica de estimativa ágil conhecida como Ideal Days (Dias Ideais), é correto afirmar que:
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 41/43
A
define que um dia ideal corresponde à quantidade de trabalho que todos os membros da
equipe conseguem entregar considerando o cenário ideal aquele em que a equipe trabalha
continuamente sem interrupções.
B
considera que a produtividade da equipe corresponde à média dos dias ideais entregues
ao final da Iteração.
C
a métrica utilizada nesta técnica para avaliar o tamanho de um requisito é pontos de
função.
D
se um item equivalente a um dia de trabalho não for entregue ao final do dia, este não será
considerado finalizado, e continuará sendo desenvolvido no dia seguinte, não havendo a
necessidade de decompô-lo em partes menores.
E
um Ideal Day é uma unidade de medida empírica, equivalente ao trabalho produzido por
um profissional sênior, expert nas tecnologias e ferramentas usadas no projeto, ao longo
de um dia normal de trabalho.
Parabéns! A alternativa E está correta.
Na técnica Ideal Days (Dia Ideal), um dia ideal é considerado a quantidade de trabalho que um
profissional sênior entrega em um dia de trabalho. O valor de 1 ID (Dia Ideal) servirá de referência
para calcular o esforço necessário (em horas) para entregar cada um dos itens do Backlog do
produto, que correspondem aos requisitos do projeto. Durante a realização dos Sprints, este valor
é reestimado conforme os resultados que vão sendo obtidos ao final do Sprint e sendo utilizado
nas próximas iterações, a fim de se realizar estimativas mais precisas.

04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 42/43
Considerações �nais
Como vimos, as técnicas apresentadas para fazer estimativas de esforço, custos, produtividade, tempo e
pessoas ajudam os gerentes de projetos a fazer estimativas mais precisas e a obter um entendimento mais
claro sobre o andamento do seu projeto.
Apresentamos o modelo COCOMO (COnstructive COst Model ou modelo Construtivo de Custo), que calcula
as estimativas a partir do número de linhas de código e da complexidade do projeto, e utilizamos um
exemplo prático para facilitar o entendimento sobre como aplicar as equações matemáticas propostas por
esta técnica, adotando como referência o modelo básico.
Vimos como fazer estimativas de duração de um projeto com os métodos PERT/CPM, utilizando um
diagrama de rede para identificar o caminho crítico do projeto, e assim priorizar a realização dessas
atividades.
Para finalizar, analisamos as principais técnicas utilizadas para fazer estimativas em projetos ágeis, como
Planning Poker e Ideal Days, e como elas são utilizadas para fazermos o planejamento dos nossos projetos e
medirmos o seu progresso.
Podcast
Ouça o podcast. Nele, falamos sobre modelos, técnicas e métodos de estimativas de esforço e custo de
projetos de software.

Referências
ALVES, F.; FONSECA, M. Ideal day e priorização: Métodos Ágeis no planejamento. Revista Engenharia de
Software, n. 7, p. 8-13, 2008.
04/03/2022 23:30 Técnicas de estimativa de esforço e custo
https://stecine.azureedge.net/repositorio/00212ti/02814/index.html#imprimir 43/43
BOEHM, B. W. Software Engineering Economics. New Jersey: Prentice Hall, 1981.
COHN, M. Agile Estimating and Planning. New Jersey: Prentice Hall, 2005.
KNIBERG, H.; SKARIN, M., Kanban and Scrum – Making the most of both. InfoQ, 2009.
MARTINS, J. C. C. Técnicas para Gerenciamento de Projetos de Software. 1. ed. Florianópolis: Brasport
Editora, 2007. 465 p.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma Abordagem Profissional. 8. ed. Porto Alegre:
AMGH, 2016.
PROJECT MANAGEMENT INSTITUTE. PMI. Guia PMBOK: Um Guia para o Conjunto de Conhecimentos em
Gerenciamento de Projetos. 6. ed. Pennsylvania: PMI, 2017.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Education, 2011
Explore +
Para saber mais sobre os assuntos explorados neste conteúdo:
Pesquise no guia PMBOK 6ª edição (Project Management Body of Knowledge ou Conjunto de
Conhecimentos em Gerenciamento de Projetos), publicado pelo PMI (Project Management Institute), as
áreas de conhecimento Gerenciamento do Cronograma e Gerenciamento dos Custos do Projeto a fim de
conhecer outras técnicas utilizadas para fazer estimativas.
Veja como o modelo COCOMO é usado atualmente, pesquisando no site do Geeksforgeks sobre Software
Engineering - COCOMO Model.
Leia o Manifesto Ágil para entender a filosofia dos métodos ágeis.
 Baixar conteúdo
javascript:CriaPDF()