1
Estimativas de Projeto de Software
Adaptação de Rodrigo Nin sobre trabalho de Márcio Pecegueiro
Principal referência:
SOFTWARE ESTIMATION:
Demystifying the Black Art
Steve McConnel, 2006
Microsoft Press
2
Conceitos básicos
•
•
•
•
•
•
Estimativa
Meta
Compromisso
Relação entre estimativa e planejamento
Divulgação, negociação e aceitação
Estimativa acurada e precisa
3
Conceitos básicos
O que se quer estimar?
» Tamanho
» Esforço
» Custo
» Prazo
4
Conceitos básicos
TAMANHO
ESFORÇO
CUSTO
PRAZO
5
Estimativa “boa”
Boeing Company
150
Erro na estimativa %
• O uso de dados
históricos e
métodos estatísticos
reduz muito a
dispersão das
estimativas
50
-50
-150
1
2
3
CMMI Level
4
5
6
Estimativa e gerência de projeto
Recursos
desviados
Falta equipe
quando planejado
Funcionalidades
removidas
Requisitos retirados
estimativa
PROJETO
Requisitos
acrescentados
Equipe menos
experiente
Equipe
atendendo
outro projeto
Novos recursos
acrescentados
7
Perigos das estimativa com folgas
excessivas
•Lei de Parkinson
"O trabalho expande-se de modo a preencher o tempo disponível para sua
realização.“ C. N. Parkinson, A Lei de Parkinson, ou a Busca do Progresso (1957)
•Procrastinação
Procrastinar = adiar, protelar, deixar para depois
•“Enfeitar o pavão”
Aperfeiçoar além do necessário; Procurar o ótimo que, como se sabe, é
inimigo do bom...
8
Perigos das estimativas apertadas
• Desenvolvedores são 20% a 30% “otimistas” em
suas estimativas
• Menos investimento na fase inicial
• Dinâmica destrutiva:
– Mais reuniões
– Mais desculpas
– “Cortes” (de funcionalidades do software; de práticas
saudáveis de trabalho; de pessoas...)
– Adoção de práticas de “alto risco”
9
Estimativas apertadas X com folga
Crescimento
exponencial por
precipitação na
codificação, práticas
de alto risco e
reuniões
Apertada
Esforço
Custo
Prazo
Crescimento
linear devido à
lei de Parkinson,
à procrastinação
e ao pavão
Folgada
10
Benefícios de boas estimativas
•
•
•
•
•
•
Visibilidade do projeto (viabiliza controle efetivo)
Maior qualidade do produto
Melhor coordenação entre equipes (just in time)
Melhor orçamento
Credibilidade da equipe (externa e interna)
Identificação prematura de riscos (pois viabiliza
controle efetivo)
11
O que você prefere?
Previsão para desenvolvimento do projeto A:
1) Prazo previsto de 4 meses, podendo ser 1
mês antes ou 4 meses depois.
2) Prazo previsto de 5 meses, podendo ser
uma semana antes ou uma semana depois.
12
Origens dos erros em estimativas
•
•
•
•
Falta de informação sobre o projeto;
Falta de informação sobre a organização;
Tentativa de estimar o caos (alvo móvel);
Processo de estimativa inadequado.
13
Cone de incerteza
Acurácia
4x
2x
1x
0,5x
0,25x
Projeto interface
Início
Projeto detalhado
Definição Requisitos
OK
OK
14
Cone de incerteza
CONE DE INCERTEZA
IMPRECISÃO
10
Interface Projeto
detalhado
Requisitos
Definição
Início
0.1
TEMPO
Ações gerenciais que reduzem a variabilidade das estimativas.
Na falta delas, cria-se uma zona de incerteza de contornos
desconhecidos.
15
Cone de incerteza
Fontes adicionais de variação
CONE DE INCERTEZA
• Requisitos mal definidos
• Requisitos voláteis
10
• Não envolvimento do cliente
• Projeto ruim (gera erros futuros)
IMPRECISÃO
• Práticas de codificação
Interface Projeto
detalhado
Requisitos
Definição
Início
• Inexperiência
• Falta de planejamento
• “Prima donna”
• Abandonar o processo (pressão)
0.1
TEMPO
• Falta de controle (automatizado)
16
Requisitos funcionais
freqüentemente esquecidos
•
•
•
•
•
Instalação e configuração
Conversão de dados
Adaptadores para produtos de terceiros
Help
Interfaces com outros sistemas
17
Requisitos de qualidade
freqüentemente esquecidos
•
•
•
•
•
•
Acurácia e precisão
Interoperabilidade
Manutenibilidade
Desempenho
Portabilidade
Confiabilidade
•
•
•
•
•
Reusabilidade
Escalabilidade
Segurança
Recuperabilidade
Usabilidade
18
Atividades freqüentemente esquecidas
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tempo de adaptação de novos membros
Mentoring
Gerência e coordenação, reuniões
Conversão de dados
Instalação
Customização
Elicitação de requisitos
Revisões e ajustes
Suporte
Manutenção de scripts / builds
Geração / Manutenção de testes
automáticos
Revisões e reuniões técnicas
Integração de tarefas
Processamento de pedidos de mudanças
Coordenação com sub-contratados
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Suporte técnico a antigos sistemas
Manutenção em sistemas antigos
Retrabalho e correção de defeitos
Ajustes de desempenho
Aprendizagem de novas ferramentas / técnicas
Tarefas administrativas
Coordenação com testadores
Coordenação com desenvolvedores
Garantia da qualidade
Preparação e revisão de documentação
Demonstrações a clientes, eventos, etc.
Demonstrações a alta gerência
Contatos com clientes
Revisões de planejamento, estimativas, etc.
Revisões por pares
Tarefas extra-profissionais
19
Outras atividades freqüentemente
esquecidas
•
•
•
•
Férias, feriados, feriadões
Doenças e faltas
Treinamento
Eventos organizacionais, encontros,
congressos
• Instalações e configurações do PC
• Problemas de hardware e software
20
Fatores influentes na estimativa
• Otimismo e expectativas conscientes ou não
• Métodos com muitos fatores de ajuste (p. ex.
COCOMO II: 17 multiplicadores e 5 fatores de escala – 22 ajustes!)
•
•
•
•
•
•
Estimativas precipitadas
Desconhecimento do domínio ou tecnologia
Orçamentação prematura
Conversão de tamanho em esforço
Conversão de esforço em prazo e custo
Transmissão, divulgação e comunicação
21
Fatores influentes no projeto
O fator mais influente é o tamanho.
• O esforço aumenta muito com o tamanho
• Incrementos no tamanho refletem-se
dramaticamente nos custos, esforço e prazo
• Redução de tamanho tem efeito menos
expressivo
22
Estimativa e gerência de projeto
Recursos
desviados
Falta equipe
quando planejado
Funcionalidades
removidas
Requisitos retirados
estimativa
PROJETO
Requisitos
acrescentados
Equipe menos
experiente
Equipe
atendendo
outro projeto
Novos recursos
acrescentados
23
Outros fatores influentes no projeto
Tipo de software
LOC / Homem-mês
TIPO
Aero-espacial
Comercial
Embarcado
Internet
Intranet
Controle de processos
Real-time
Científico
Sistema/drivers
10 KLOC
100 a 1.000
800 a 18.000
100 a 2.000
600 a 10.000
1.500 a 18.000
500 a 5.000
100 a 1.500
500 a 7.500
200 a 5.000
100 KLOC
20 a 300
200 a 7.000
300 a 500
100 a 2.000
300 a 7.000
100 a 1.000
20 a 300
100 a 1.500
50 a 1.000
250 KLOC
20 a 200
100 a 5.000
20 a 400
100 a 1.500
200 a 5.000
80 a 900
20 a 300
80 a 1.000
40 a 800
(fonte: Software Estimation, McConnel 2006, Putman&Meyers 1992, Putman&Meyers 1997, Putman&Meyers, 2003)
(portanto, evite os projetos “grandes”...)
24
Outros fatores influentes no projeto
Fatores pessoais x percentual de variação introduzido:
Analista de requisitos
Programador
Turnover
Experiência no dominio
Experiência na linguagem e feramentas
Experiência na plataforma
Coesão da equipe
-30
-20
-10
0
10
20
30
40
50
(fonte: Software Estimation, McConnel, 2006)
25
Outros fatores influentes no projeto
•
•
•
•
•
•
Linguagem de programação adequada
Complexidade do produto
Documentação exigida
Maturidade do processo
Gerência de riscos
Gerência do projeto
26
Técnicas de estimação
Depende de
• Tamanho do projeto (pequeno a grande)
• Paradigma de desenvolvimento
– Cascata (inclui RUP)
– Iterativo
– Evolucionário por prototipação
• Estágio do desenvolvimento (cedo a tarde)
27
Como estimar
• Medir (recomendável)
• Calcular (razoável)
• Julgar (se não tiver outro jeito)
Geralmente uma combinação dessas
28
Como medir (o mínimo)
•
•
•
•
•
Tamanho do produto (Pontos por função; Linhas de código, etc.)
Esforço (Homens/Hora, etc.)
Tamanho da equipe (Quantidade de pessoas)
Prazo (dias, meses)
Defeitos (classificados por severidade)
29
Por que medir ?
• Para calibrar seu modelo preditivo
• Para monitorar os projetos
• Para monitorar os processos
30
Estimativa por especialista
• O que é o “especialista”?
• Quem melhor prediz é geralmente o
responsável por fazer o trabalho
• Melhora muito com a granularidade do item
estimado
• Estimativa obtida por agregação de outras
mais detalhadas quase sempre é melhor
31
Decomposição e recomposição
• Lei dos grandes números na estatística diz
que o resultado é mais acurado se obtido
pela recomposição a partir de partes
menores.
• Ou seja, vamos decompor o objeto da
estimativa em partes menores, estimá-las e a
partir daí construir a estimativa global.
32
Checklist para estimativa por especialista
•
•
•
•
•
•
•
•
Objeto bem definido?
Inclui todo o trabalho necessário?
Base em fatos anteriores documentados?
Aprovação dos interessados?
A produtividade é realista?
O pior caso é realmente o pior?
Registro de tudo que foi assumido?
A situação não mudou?
33
Estimativa por analogia
• Obtenha os valores para tamanho, esforço e custo em
projetos semelhantes;
• Se possível, obtenha esses dados detalhados por WBS
(work breakdown structure), tipo de item, etc.;
• Estime o tamanho do novo projeto proporcionalmente;
• Estime o esforço com base na relação de tamanhos entre
os projetos;
• Avalie a consistência do resultado.
34
Estimativa por analogia
Cuidados:
• Analogia só se aplica a projetos de porte
semelhante (cerca de 3 vezes o tamanho);
• Considerar diferenças de tecnologia;
• Considerar diferenças de equipe;
• Considerar diferenças no tipo de software.
35
Estimativa Individual x Grupo
Regras:
• Cada membro estima separadamente e depois comparam-se
os resultados e discute-se as diferenças no grupo;
• Não se faz a média ou coisa do gênero;
• É necessário atingir um consenso.
Resultados observados:
• Na maior parte das vezes a estimativa é bem melhor;
• Basta um grupo de 3 a 5 membros;
• Melhor quando têm diferentes especialidades.
36
Estimativa Delphi
Etapas:
1.
2.
3.
4.
5.
6.
7.
8.
O coordenador envia a especificação e o formulário;
Reunião de discussão de questões;
Cada membro estima separadamente;
Coleta-se as estimativas anônimas;
O coordenador consolida e redistribui;
Reunião para discutir as variações e votação anônima de
aceitação da média;
Não havendo consenso volta-se à etapa 3;
O resultado pode ser um valor único ou um intervalo e
um valor esperado.
37
Processo de estimativa
Entradas definidas
para esta avaliação
específica
Processo
ad hoc
Características técnicas
Prioridades
Restrições
Dados históricos
Processo
padronizado
Estimativas não
confiáveis
Esforço estimado
Prazo estimado
Custo estimado
Produtos estimados
38
Ajuste da estimativa
• O primeiro marco, previsto para 4 semanas,
foi alcançado em 6 semanas, num projeto de
26 semanas. O que você faria:
• Manteria o prazo de 26 semanas e trataria
de compensar o atraso;
• Reajustaria o prazo para 28 semanas;
• Reajustaria o prazo para 39 semanas
(considerando um erro de 50%).
39
Como apresentar estimativas
Etapa
Estimativa Estimativa
Concepção
10
3-40
Definição do produto
10
5-20
Requisitos aprovados
13
9-20
Projeto da interface
14
12-18
Primeira iteração
16
15-18
FINAL
17
17
40
Recomendações para processo padronizado
• Enfatizar contagem e cálculo sempre que possível, em vez
de usar o julgamento;
• Usar diferentes técnicas e comparar os resultados;
• Planejar reestimativas em pontos pré-definidos do projeto;
• Mudar a abordagem à medida em que dados reais ficam
disponíveis;
• Descrever claramente a faixa em que a estimativa é
acurada;
• Especificar quando usar a estimativa para orçamento;
• Especificar quando usar a estimativa para assumir
compromissos internos e externos.
41
Melhorar o processo padronizado
• Quanto acurada foram as estimativas? A faixa contém o
valor efetivamente realizado?
• A largura de faixa é adequada ou deve ser aumentada ou,
preferencialmente, reduzida?
• O processo é neutro ou observa-se tendência a ficar sempre
abaixo ou acima do valor realizado?
• Há fatores subjetivos e preconceitos influenciando o
processo?
• Quais as técnicas que estão dando melhores resultados?
• Os momentos de revisão estão adequados?
• O processo pode ser simplificado sem prejuízo?
42
Estimando redução do prazo
• Reduzir o prazo aumenta desproporcionalmente o
esforço
• Não tente reduzir mais do que 25%!
• Aumentar o prazo e reduzir a equipe reduz o
custo
• Não use mais do que 7 desenvolvedores em
projetos de médio porte – 35 a 100 KLOC
43
Estimando redução do prazo
VARIAÇÃO DO
PRAZO
VARIAÇÃO DO
ESFORÇO
-15%
-10%
-5%
+10%
+20%
+30%
+100%
+50%
+25%
-30%
-50%
-65%
Measures for Excellence (Putnam & Meyers, 1992)
44
300
PRAZO (meses)
50
45
ESFORÇO
40
PRAZO
250
35
200
30
25
150
20
15
100
10
50
5
0
0
1,5-3
3-5
5-7
9-11
15-20
EQUIPE
(Putnam & Meyers, 1992)
ESFORÇO (homem-mês)
Estimando redução do prazo
45
Estimando o custo
• Multiplica-se a medida de esforço pelo “custo unitário”
• Considerar o tratamento das horas-extras
• O que está incluído no custo?
• Apenas os custos diretos
• Inspeções, revisões por pares, qualidade
• Gerência, homologação e suporte a implantação
• Infra-estrutura, escritório, impostos
• E quanto a outros custos?
• Viagens
• Treinamento, mentoring, auto-desenvolvimento
• Congressos, visitas ao cliente, apresentações
• Férias, doença, licença, feriados, comemorações
46
Estimando Riscos e Contingenciando
Risco
Probab
Prazo (semanas) Custo R$ 1000
Severidade Exposição
Severidade Exposição
1
5%
15
0,75
150
7,5
2
25%
2
0,5
20
5
3
25%
8
2
80
20
4
50%
2
1
20
10
TOTAL
4,25
42,5