1. O documento discute conceitos e técnicas relacionadas a estimativas de projetos de software. 2. As técnicas de estimativa discutidas incluem Wideband Delphi, COCOMO II, decomposição/composição e uso de dados históricos. 3. Fatores que influenciam as estimativas incluem tamanho do projeto, tipo de produto, equipe e requisitos. É importante considerar esses fatores e usar múltiplas técnicas para melhorar a precisão das estimativas.

1. Estimativas em projetos
de software
Vitor Alcântara Batista
Engenharia de Processos

2. Agenda
O que é uma estimativa e conceitos relacionados
Fatores que influenciam as estimativas
Técnicas de estimativa
– Wideband Delphi
– COCOMO II
– Composição/decomposição
2

3. 1. O que é uma estimativa e conceitos
relacionados

4. O “Processo” usual de Estimativas de Software
O quêee?!
Tudo isso??
Mas precisamos
disso pronto em
Entrada “Processo” de Estimativa 2 meses!
(?) estimativa (??) Não seja
pessimista!
Neste projeto
tudo vai
caminhar melhor
Estimativa “melhor” “Readequação”
(????) Gerencial

5. Por que ocorre essa “Revisão Gerencial”?
Provavelmente pelo desconhecimento da diferença
entre:
– Estimativa
– Meta
– Objetivo de negócio de uma organização

6. Estimativa, meta e objetivo de negócio
Objetivo de negócio
Meta
Estimativa
Prazo

7. Risco do projeto
Objetivo de negócio
Meta
Estimativa
Risco
Prazo

8. Estimativa x Meta
Estimativa
Meta

9. Exemplo de estimativa
Pergunta: “Forneça uma estimativa da temperatura da
superfície do Sol em ºC que tenha uma confiabilidade
de 90%”
Era esperado uma resposta do tipo: “Entre 500 ºC e
10.000 ºC”
Resposta correta: aproximadamente 6000 ºC.

10. Agora que aprendemos...
Estimar com 90% de confiança:
– Qual a altura da torre Burj Dubai, o maior prédio do
mundo?
– Resp: aprox. 828m
10

11. O que é uma boa estimativa?
100%
Mediana
(50/50)
Probabilidade
Cronograma, Esforço,
Custo
Uma boa estimativa é aquela que tem 25% ou menos de
erro, em pelo menos 75% dos casos
[McConnell 2006]

12. A Lei de Parkinson
“O trabalho expande-se de modo a preencher o
tempo disponível para sua realização.”
Cyril Northcote Parkinson, “Parkinson's law: The pursuit of progress”, John Murray, 1958

13. Subestimar x superestimar
Nan, N., & Harter, D. E. (2009). Impact of Budget and Schedule Pressure on Software
Development Cycle Time and Effort. IEEE Transactions on Software Engineering

14. O cone da incerteza
10
4
2
1,5
1,25 1,1
1
1
0,9 1
0,8
0,67
0,5
0,25
0,1
C on ce p ção A p r ovação da Re q u is itos De s e n h o d e De s e n h o Pr o du to
in icial d e fin ição do co m ple tos in te r face s d e talh ado com p le to
pr o d u to com p le to com p le to
Fases do processo
Barry Boehm, Software Engineering Economics, Prentice Hall, 1981.

15. Por que as estimativas dão errado?
Excesso de alterações de requisitos (acertar um alvo
que se move)
Falta de conhecimento da organização sobre sua
própria capacidade (dados históricos)
Otimismo
Requisitos imprecisos ou incompletos
Estimativas só são confiáveis em fases adiantadas dos
projetos, mas normalmente são requeridas na base do
“cone da incerteza”

16. Influência de dados irrelevantes
2 Experimentos realizado com 165 profissionais
Grupo Meta do cliente Mediana da
estimativa
Very_low 4 60 h
Low 40 100 h
High 800 300 h
Control - 160 h
Grupo Palavras usadas Mediana da
estimativa
Low Pequena melhoria 40 h
High Nova 80 h
funcionalidade
Control melhoria 50 h
M. Jørgensen, and S. Grimstad. Avoiding Irrelevant and Misleading Information When Estimating
Development Effort, IEEE Software(May/June):78-83, 2008.
Trabalhos semelhantes: http://simula.no/people/magnej/bibliography
16

17. Indicadores de acurácia de estimativas
PRED(x) = % de
erros menores que x
ŷ = valor estimado, y = valor real
17

18. 2. Fatores que influenciam as estimativas

19. Alguns fatores que influenciam as estimativas
Tamanho do projeto/produto sendo desenvolvido
Tipo de produto
Equipe do projeto

20. Tamanho do produto
Em software há deseconomia de escala

21. Deseconomia de escala
Porque há essa deseconomia?

22. Crescimento exponencial dos canais de comunicação
3 canais 6 canais
E para uma equipe de 10 pessoas? 45 canais

23. Tipo do produto
LOC/PM
Tipo de Software 10,000-LOC 100,000-LOC 250,000-LOC
Aeronáutica 200 50 40
Sistemas de Gestão 3.000 600 500
Sistemas embutidos 300 70 60
Sistemas para Internet 1.500 300 200
Sistemas para Intranet 4.000 800 600
Tempo real 200 50 40

24. Equipe

25. Outros fatores
Requisitos de desempenho / tamanho da base de dados
Requisitos de usabilidade
Flexibilidade na proposição da solução
Distribuição espacial da equipe
Pressão pelo prazo de entrega

26. 3. Técnicas de estimativa

27. O Processo “correto” de estimativas
Requisitos
Estimar tamanho Tamanho
do produto
Estimar esforço de Produtividade
Dados
desenvolvimento históricos
Distribuição de
Recursos Estimar cronograma e esforço
disponíveis alocação de recursos
Indicadores de Estimar
custo por recurso custo
Verificar Estimativa
[ e stimati vas estimativas aprovada
reprovadas ]
[ estimativas Analisar o processo
aprovadas ] de estimativa
[ obtenção de dados reais,
alteração de requisitos ] Acompanhar Dados reais
desenvolvimento do projeto
[ sim ] Necessário
reestimar?
[ não ]

28. Técnicas de estimativa
Utilização de dados históricos
Wideband Delphi
COCOMO II
Decomposição e composição
Outras

29. Tipos de dados históricos
Dados da Indústria (ISBSG, COCOMO, etc).
Dados da organização
Dados do projeto em execução

30. Dados básicos a serem coletados
Tamanho (LOC, PF, etc.)
Esforço (PM ou horas)
Prazo

31. Exemplo
Projeto Tamanho (PF) Esforço (PM) Prazo (meses)
A 1000 12,5 12
B 2000 29 22
C 500 6,25 4
D (novo) 3500 ? ?

32. Exemplo
Produtividade
Projeto Tamanho (PF) Esforço (PM) Prazo (meses)
(PF/PM)
A 1000 12,5 12 80,00
B 2000 29 22 68,97
C 500 6 4 83,33
Média 77,43
D (novo) 3500 45,20 ? 77,43

33. Dados ISBSG para novos desenvolvimentos

34. Wideband Delphi
É uma técnica de estimativa em grupos de
especialistas
Útil principalmente quando o conceito do projeto
ainda está muito indefinido
Como funciona:
1. O coordenador distribui a “especificação do
projeto/produto” e um formulário para estimativa
a cada membro
2. Os membros são reunidos para discutir
aspectos de estimativa relacionados ao projeto.
3. Cada participante faz a sua estimativa individual

35. Wideband Delphi (cont.)
4. O coordenador prepara um relatório com as
estimativas:
5. O grupo se reúne e discute as variações
6. Os participantes votam anonimamente, se aceitam ou
não a média. Se não houver unanimidade, recomeça
do passo 3.

36. COCOMO II
COnstrutive COst MOdel.
– Método paramétrico proposto por Barry
Boehm (e outros) para estimar tamanho e
prazo de projetos.
– Se baseia nas equações abaixo:

37. Destrinchando o COCOMO
B = 0,91
SFj = Fatores de escala
– Precedência
– Flexibilidade na solução
– Resolução de riscos/arquitetura
– Coesão da equipe
– Maturidade do processo

38. Fatores de escala
Impactam no expoente da equação

39. Destrinchando o COCOMO, parte 2
A = 2,94
Size = tamanho em milhares de SLOC, mas pode-se
usar pontos de função não ajustados ou pontos de
objetos
EMi = 16 (ou 5) multiplicadores de esforços, divididos
em:
– Produto
– Plataforma
– Pessoal
– Projeto

40. Níveis dos fatores de escala

41. Níveis dos multiplicadores de esforço
Para o parâmetro CPLX (complexidade do produto)
Para ACAP (capacitação do analista de requisitos)

42. Resumindo
A = 2,94 e B = 0,91
Com todos os parâmetros no nível nominal, teremos:
E = 0,91 + 0,01 x 18,97 = 1,1
PM = 2,94 x Size^1,1 x 1

43. Resultados do COCOMO II no Synergia
Sem calibração
Calibrado

44. Composição e decomposição
Dividir o projeto em partes menores, como módulos
ou funcionalidades
Funcionalidade Esforço estimado (PM)
1 2
2 2,5
3 1
4 0,5
5 1
6 3
Total 10
Qual a vantagem?

45. “Lei dos números grandes”
Esforço
Funcionalidade Esforço real Erro
estimado
1 2 3 50,0%
2 2,5 2,1 -16,0%
3 1 0,5 -50,0%
4 0,5 1,2 140,0%
5 1 2 100,0%
6 3 2 -33,3%
Total 10 10,8 8,0%

46. Experiência no Synergia
46

47. Resultado de estimativas feitas pelos executores das
tarefas no Synergia
MMRE = 21,8%. Anterior: 52,8%.
PRED(0,25) = 69,6% . Anterior: 36,8%

48. Outras técnicas de estimativa
Modelos baseados em Proxy
– Utiliza tabelas de complexidade baseada em número de alguns
componentes. Ex: telas, classes, relatórios, tabelas de banco de
dados, etc.
Técnicas de Aprendizado de máquina
– redes neurais e redes neuro-fuzzy
Técnicas estatísticas de regressão linear

49. Qual a melhor técnica?
Não há uma resposta definitiva
– Jorgensen, M., & Shepperd, M. (2007). A Systematic Review
of Software Development Cost Estimation Studies. IEEE
Transactions on Software Engineering.
49

50. Perguntas?

51. Contato
Vitor Alcântara Batista
Equipe de Engenharia de processos
vitor@dcc.ufmg.br
51