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