1 estimativas de projeto de software principal referência: software estimation: demystifying the...
TRANSCRIPT
1
Estimativas de Projeto de Software
Principal referência:SOFTWARE ESTIMATION:Demystifying the Black Art
Steve McConnel, 2006Microsoft Press
Adaptação de Rodrigo Nin sobre trabalho de Márcio Pecegueiro
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”
• O uso de dados históricos e métodos estatísticos reduz muito a dispersão das estimativas
Boeing Company
-150
-50
50
150
1 2 3 4 5
CMMI Level
Err
o n
a es
tim
ativ
a %
6
Estimativa e gerência de projeto
P R O J E T O
Falta equipe quando planejado
Requisitos retirados
Recursos desviados Funcionalidades
removidas
Requisitos acrescentados
Equipe menos experiente
Novos recursos acrescentados
estimativa
Equipe atendendo
outro projeto
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çãoProcrastinar = 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
EsforçoCustoPrazo
Crescimento exponencial por precipitação na codificação, práticas de alto risco e reuniões
Crescimento linear devido à
lei de Parkinson, à procrastinação
e ao pavão
Apertada 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
1x
2x
4x
0,5x
0,25x
InícioDefinição
OKRequisitos
OK
Projeto interfaceProjeto detalhado
Acu
ráci
a
14
CONE DE INCERTEZA
0.1
10
TEMPO
IMP
RE
CIS
ÃO
Cone de incerteza
Início
DefiniçãoRequisitos
Interface Projeto detalhado
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
0.1
10
TEMPO
IMP
RE
CIS
ÃO
Cone de incertezaFontes adicionais de variação
Início
DefiniçãoRequisitos
Interface Projeto detalhado
• Requisitos mal definidos
• Requisitos voláteis
• Não envolvimento do cliente
• Projeto ruim (gera erros futuros)
• Práticas de codificação
• Inexperiência
• Falta de planejamento
• “Prima donna”
• Abandonar o processo (pressão)
• 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
P R O J E T O
Falta equipe quando planejado
Requisitos retirados
Recursos desviados Funcionalidades
removidas
Requisitos acrescentados
Equipe menos experiente
Novos recursos acrescentados
estimativa
Equipe atendendo
outro projeto
23
Outros fatores influentes no projeto
Tipo de software
TIPO 10 KLOC 100 KLOC 250 KLOCAero-espacial 100 a 1.000 20 a 300 20 a 200
Comercial 800 a 18.000 200 a 7.000 100 a 5.000Embarcado 100 a 2.000 300 a 500 20 a 400
Internet 600 a 10.000 100 a 2.000 100 a 1.500Intranet 1.500 a 18.000 300 a 7.000 200 a 5.000
Controle de processos 500 a 5.000 100 a 1.000 80 a 900Real-time 100 a 1.500 20 a 300 20 a 300Científico 500 a 7.500 100 a 1.500 80 a 1.000
Sistema/drivers 200 a 5.000 50 a 1.000 40 a 800
LOC / Homem-mês
(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:
(fonte: Software Estimation, McConnel, 2006)
-30 -20 -10 0 10 20 30 40 50
Coesão da equipe
Experiência na plataforma
Experiência na linguagem e feramentas
Experiência no dominio
Turnover
Programador
Analista de requisitos
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 GrupoRegras:• 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. O coordenador envia a especificação e o formulário;
2. Reunião de discussão de questões;
3. Cada membro estima separadamente;4. Coleta-se as estimativas anônimas;5. O coordenador consolida e redistribui;6. Reunião para discutir as variações e votação anônima de
aceitação da média;7. Não havendo consenso volta-se à etapa 3;8. O resultado pode ser um valor único ou um intervalo e
um valor esperado.
37
Processo de estimativa
Processo ad hoc
Processo ad hoc
Entradas definidas para esta avaliação
específicaEstimativas não
confiáveis
Processo padronizado
Processo padronizado
Características técnicas
Prioridades
Restrições
Dados históricos
Produtos estimados
Esforço estimado
Prazo estimado
Custo estimado
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% +100%
-10% +50%
-5% +25%
+10% -30%
+20% -50%
+30% -65%Measures for Excellence (Putnam & Meyers, 1992)
44
Estimando redução do prazo
0
5
10
15
20
25
30
35
40
45
50
1,5-3 3-5 5-7 9-11 15-20
EQUIPE
PR
AZ
O (
mes
es)
ESFORÇO
PRAZO
300
150
250
200
100
50
0
ES
FO
RÇ
O (
hom
em
-mê
s)
(Putnam & Meyers, 1992)
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 ProbabPrazo (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