Estimativas de Esforço - Engenharia de Software

Estimativas de Esforço
Eduardo Mendes

Eduardo Mendes (edumendes@gmail.com)
Agenda 1. Introdução
2. O Que é Estimativa
3. Abordagens Para Estimativas
4. Métricas para Estimativas
Análise de Pontos de Função
Pontos de Caso de Uso
Pontos de Estórias de Usuário
5. Considerações Finais
2

1 2 3 4 5

1. Introdução
4

Processo 
de Software
5

2. Estimativas
7

2. Estimativas
2.1 O que é
2.2 Benefícios
8

O que é estimar?
9
determinar o valor de uma coisa

O que é 
estimativa?
10
cálculo aproximado
avaliação
conjectura

Eduardo Mendes (edumendes@gmail.com)11
previsãoestimativa
não é 
uma

Estimar
Uma das atividades ligadas ao
planejamento de projeto
Criação de cronogramas
Análise de Riscos
Gerenciamento da qualidade
Gerenciamento de alterações
12

Tradicional Ágil

Benefícios
14
Prever o quanto é possível fazer
em um determinado período de tempo
Identiﬁcar perdas e ganhos em face
da velocidade da equipe
As estimativas auxiliam o processo
de decisão do cliente

Diﬁculdades
15
falta de métricas precisas
falta de dados históricos
quantidade de variáveis envolvidas
imprevistos e mudanças de rumo

Incerteza
Concepção 
do projeto
16
400%
Aprovação 
do projeto
150%
200%
[FONTE: MANTEIGA, Sandro]

3. Abordagens para estimativas
18

3. Abordagens para
Estimativas
3.1 Processos de Estimativa Baseados
em Processos de Especialistas
3.2 Processos de Estimativas Baseados
em Modelos
19

Estimativa Baseada"
em Julgamento"
de Especialista
Estimativas 
Baseadas em Modelos
Indivíduo com competência para
estimar esforço baseada na
intuição e experiência
Uso de fórmulas matemáticas
que utilizam entradas como a
quantiﬁcação de tamanho de
projeto, o tipo de software que se
quer construir e outros fatores

Esforço = α x tamanho β x fator de ajuste
fator constante que
depende das práticas
organizacionais locais e do
tipo de software em
desenvolvimento
21
varia geralmente 
entre 1 e 1,5α
medida tamanho da funcionalidade
advinda da especiﬁcação de
requisitos feita pelo cliente
tamanho
β
valor vindo da combinação de
atributos do processo, produtos
de desenvolvimento
fator de ajuste

4. Métricas para Estimativas
23

4. Métricas para
Estimativas
4.1 Análise de Pontos de Função
4.1.1 A Estimativa de Esforço co APF
4.2 Pontos de Caso de Uso
4.2.1 A Estimativa de Esforço com PCU
!
4.3 Métricas em Processos Ágeis
4.3.1 Pontos de Estórias de Usuário
4.3.2 Planning Poker
4.3.3 Velocidade
24

4.1 Análise de Pontos de Função
25

Foi proposta, inicialmente, por
Albrecht e Gaﬀney
Reﬁnada pelo Ineternational Function
Point Users Group (IFPUG)
Foi o primeiro método para
dimensionar software independente
da tecnologia em que era desenvolvido
26
Análise 
de Pontos de Função

entradas fornecidas à aplicação
!
saídas da aplicação
!
consultas dos usuários
!
arquivos lógicos ou de dados a serem
atualizados pela aplicação
interfaces com outras aplicações
as 
métricas

O processo de
contagem
i. determina-se o tipo de contagem
ii. identiﬁca-se o escopo de contagem e a fronteira da aplicação
iii. contam-se as funções de dados
iv. contam-se as funções transacionais
v. determinam-se os PF não ajustados
vi. determinam-se os valores dos fatores de ajustes
vii. calculam-se os PF ajustados
28

∑PFA = ∑PFNA * fator de ajuste
29

Cálculo e Ponderação
30
(Adaptado de PRESSMAN, 2011)

Fator de Ajuste
1. O sistema requer salvamento (backup) e
recuperação conﬁável (recovery)?
2. São necessárias comunicações de dados
especializadas para transferir informações para aplicação
ou da aplicação?
3. Há funções de processamento distribuído?
4. O desempenho é crítico?
5. O sistema rodará em um ambiente operacional
existente e intensamente utilizado?
6. O sistema requer entrada de dados online?
7. A entrada online de dados requer que a transação de
entrada seja composta em múltiplas telas ou operações?
31
8. Os ALIs são atualizados online?
9. As entradas, saídas, arquivos ou consultas
são complexas?
10. O processamento interno é complexo?
11. O código é projetado para ser reutilizável?
12. A conversão e instalação são incluídas no
projeto?
13. O sistema é projetado para múltiplas
instalações em diferentes organizações?
14. A aplicação é projetada para facilitar a troca e
o uso pelo usuário?

fator de ajuste = (0,01 x ∑ Pesos) + 0,65
32

Esforço
Esforço = PF de desenvolvimento x produtividade
33

20%
05 pessoas
= 20h/PF
> 8h/dia
Esforço = 20 PF x 20h/PF = 400h
Esforço/pessoa = 400h / 5 = 80h
Dias de esforço = 80h / 8h = 10 dias

4.2 Pontos de Caso de Uso
35

Pontos de Caso de Uso
Após 10 anos da proposta dos Pontos de Função,
surgiu a medida Pontos por Caso de Uso (PCU)
proposta por KARNER (1993), que é uma adaptação
da APF
Foco fazer estimativa de tamanho sobre sistemas
de software orientados a objeto
Depende de uma padronização dos casos de uso,
em razão desta contagem ser realizada a partir das
transações identiﬁcadas nos ﬂuxos de eventos.
36

O processo de
contagem
i. contam-se os atores e atribui-se o grau de complexidade
ii. contam-se os casos de uso e atribui-se o grau de
complexidade
iii. somam-se o total de atores com o total de casos de uso
para obter o PCU não ajustado
iv. determina-se a complexidade do fator técnico
v. determina-se a complexidade do fator ambiental
vi. calcula-se o PCU ajustado.
37

Contagem dos Atores
∑ Peso dos Atores não ajustado = ∑ Fator dos Atores
38

Ponderação dos Atores
39
Complexidade Descrição Fator
Simples Aplicação com API deﬁnida 1
Intermediário
Aplicação interface baseada em porotocolo ou
interação de usuário por linha de comando
2
Complexo Usuário com interface gráﬁca 3

Contagem dos Casos de Uso
∑ Peso dos Casos de Uso não ajustado = ∑ Fator dos Casos de Uso
40

Ponderação dos Atores
41
Nível Descrição Fator
Simples 03 ou mais transações 5
Intermediário de 04 a 07 transações 10
Complexo de 08 a 11 transações 15
N-Complexo além de 11 transações Fx*
Fx = 15*(transações/11) + Fator(resto da divisão transações/11)!

Transação
42
Na análise de PCU transação é um conjunto
de atividades atômicas, que são
executadas completamente, ou não
!
Pode-se atribuir uma transação a cada
passo do ﬂuxo que precisa ser executado
por completo, ou à realização de um
processamento complexo [RIBU, 2001]

O processo de
contagem
i. contam-se os atores e atribui-se o grau de complexidade;
ii. contam-se os casos de uso e atribui-se o grau de
complexidade;
iii. somam-se o total de atores com o total de casos de uso
para obter o PCU não ajustado;
iv. determina-se a complexidade do fator técnico
v. determina-se a complexidade do fator ambiental, e
vi. calcula-se, então, o PCU ajustado.
43

Fator Técnico (TCF)
44
TCF = 0,6 + (0,01 x FatorT)
O Fator de Complexidade Técnica (TCF) é
calculado utilizando a soma das multiplicações
dos valores atribuídos a cada fator da Tabela
de fatores técnicos pelos seus pesos, gerando
a valor chamado de FatorT

Fatores Técnicos
45
Fator Descrição Peso
T1 Sistema distribuído 2
T2 Tempo de resposta 2
T3 Eﬁciência online 1
T4 Processamento complexo 1
T5 Código reutilizável 1
T6 Facilidade de instalação 0.5
T7 Facilidade de uso 0.5
T8 Portabilidade 2
T9 Facilidade de manutenção 1
T10 Acesso concorrente 1
T11 Aspectos relativos à segurança 1
T12 Acesso para terceiros 1
T13 Treinamento especial obrigatório 1

Fator Ambiental (EF)
46
EF = 1,4 + (-0,03 x FatorE)
O Fator Ambiental (EF) é calculado utilizando a
soma das multiplicações dos valores atribuídos
a cada fator da Tabela de Fatores ambientais
pelos seus pesos

Fatores Ambientais
47
Fator Descrição Peso
A1 Familiaridade com o Processo de 1.5
A2 Experiência na aplicação 0.5
A3 Experiência em orientação a objetos 1
A4 Capacidade do líder de projeto 0.5
A5 Motivação 1
A6 Estabilidade dos requisitos 2
A7 Membros da equipe com tempo parcial -1
A8
Diﬁculdade da linguagem de
programação
2

PCUs ajustados
PCU ajustados = Peso dos Casos de Uso não ajustado * TCF * EF
48

Cálculo do Esforço
De Sousa e Abreu (2011)
apresentam um modelo para o
cálculo do esforço utilizando PCUs
Para isso eles utilizam mais 03
fatores:
49
produtividade, que representa
a quantidade de horas
necessárias para se produzir 01
ponto de caso de uso
risco, que transmite o fator de
incerteza do projeto
gestão, que representa o
esforço de planejamento e
acompanhanento do
desenvolvimento do sistema.

Esforço = PCU x produtividade
50
Esforço = PCU x produtividade x risco x gestão

4.3 Métricas em processos ágeis
51

Processo de gerenciamento
diferenciado
Scrum
Product Owner
Scrum Master
Time
52

Pontos de Estória de
usuário
Nas abordagens ágeis, os requisitos de
usuário são descritos através de estórias
de usuário
O Ponto de Estória de Usuário é uma
unidade de estimativa relativa
É representado por um número inteiro que
é a agregação de um conjunto de aspectos
que interferem no tamanho potencial de
uma estória
53

Planning Poker
O planning poker (PP) é um
método ágil que gera estimativas
que são feitas pelo time como
um todo, não partindo de uma
só pessoa
!
Estimativa coletiva
55

Planning Poker
todo os membros do time participam
e são “estimadores”;
o PO participa mas não opina nas
estimativas;
cada membro do time recebe um
conjunto de cartas (baralho) com
valores associados: 0, 1, 2, 3, 5, 8, 13,
20, 40, and 100
56

Velocidade
57
Neste processo, 
a velocidade é uma medida para a
taxa de progresso de uma equipe
!
Através dela é que se é capaz de
saber o quanto de esforço que
uma equipe pode realizar

Velocidade
58
A velocidade é obtida através do
cálculo  
 
da soma dos SPs de todas as
estórias de usuário 
 
que foram realizadas por completo
durante uma iteração

01 iteração
04 !estórias

20 SPs/Iteração
04 !estórias

15 SPs/Iteração
03 !estórias

Velocidade
62
Utiliza-se a velocidade para planejar
a quantidade de estórias a serem
realizadas nas iterações seguintes

5. Considerações Finais
64

Processos de Estimativas
Baseados em Modelos
Rápidos e fáceis de aplicar
Podem ser usados no início do
projeto
São objetivos e passíveis de
repetição
65

Processos de Estimativas
Baseados em Modelos
Muito especíﬁcos para um determinado contexto
Em geral, não são muito precisos
Estimam o esforço total, que depois precisa 
ser distribuído entre as diversas atividades/módulos
Problemas técnicos difíceis podem 
não ser considerados
Estimativas menos acuradas
!
66

Estimativa Baseada
em Julgamento de Especialista
Pouca ou nenhuma necessidade de dados
históricos
Pode ser usado no início do projeto e em
situações onde se lida com novas tecnologias,
aplicações ou linguagens
Bastante ﬂexível com relação ao objeto das
estimativas
67

Estimativa Baseada
em Julgamento de Especialista
A opinião dos especialistas pode ser tendenciosa
e/ou inﬂuenciável
O conhecimento e domínio dos especialistas
sobre o assunto pode ser questionável
68

Evidências na literatura
Jørgensen (2007) avalia diversas
abordagens de estimativas de
esforço e conclui:
os modelos falharam
sistematicamente ao tentar
realizar estimativas melhores
do que as dos especialistas
69

Possíveis razões
os especialistas podem ter mais
informações sobre o contexto e a forma
como a informação é processada é mais
ﬂexível
a falta de estabilidade entre os dados que
estão sendo relacionados em um modelo
falta de precisão na calibragem dos
modelos
70

+ literatura
Fowler (2013) também aponta
problemas nas estimativas por
especialistas em processos ágeis,
principalmente, quando há uma
tendência há ser muito otimista
isto tem sido relatado por muitos
times ágeis, transformando a
estimativa em uma cobrança
71

+ literatura
Jørgensen aconselha a utilização das
abordagens combinadas nesta
situação de otimismo e também
quando:
• a quantidade de informações
contextuais do especialista é baixa
• quando os modelos utilizados estão
bem calibrados
72

• Reﬁnamento das comparações
entre abordagens
• Pontos de Função Cosmic
• Wideband Delphi
Continuação da pesquisa
73

Obrigado
74

Estimativas de Esforço - Engenharia de Software

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Estimativas de Esforço - Engenharia de Software

Mais de Eduardo Mendes

Estimativas de Esforço - Engenharia de Software