Estimativas de Projeto de Software

Apresentação em tema: "Estimativas de Projeto de Software"— Transcrição da apresentação:

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 Estimativa deve ser um processo frio, técnico, objetivo. Planejamento é um processo “quente”, impregnado de objetivos. Isto vai demorar 179 dias e 12 horas – é uma estimativa precisa. Isto vai demorar meio ano – se demorar 6 meses e 12 dias foi uma estimativa acurada.

3 Conceitos básicos O que se quer estimar? Tamanho Esforço Custo Prazo

4 Conceitos básicos TAMANHO ESFORÇO CUSTO PRAZO
Misturar planejamento com estimativa resulta em ambos mal feitos, impregnados de subjetividade. Primeiro estima-se, depois planeja-se, só então considerando objetivos a alcançar.

5 Estimativa “boa” O uso de dados históricos e métodos estatísticos reduz muito a dispersão das estimativas Notar a tendência para estimativas otimistas na maioria dos casos.

6 Estimativa e gerência de projeto
Falta equipe quando planejado Recursos desviados Funcionalidades removidas Requisitos retirados P R O J E T O estimativa Requisitos acrescentados Por erro de planejamento ou coordenação membros da equipe não estão disponíveis no momento necessário. Membro utilizados p.ex. em exposição, palestra, etc. ou enviado para um curso. Às vezes profissionais são substituídos por outros menos experientes. É comum dar atendimento a sistemas anteriores em operação, bugs, urgências. Quando se acrescenta um novo membro há um período de adaptação – dele e da equipe. Equipe atendendo outro projeto Equipe menos experiente 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... Parkinson: expansão para preencher toda a disponibilidade Procrastinação: deixar para depois Enfeitar: melhorias desnecessárias

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ço Custo Prazo 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) Visibilidade conseguida porque o planejamento é real e efetivamente comparável com o andamento. Qualidade é prejudicada pelo estresse, aflição, práticas de alto risco, precipitação, supressão de funcionalidades. Coordenação exige bom planejamento. Credibilidade porque alcança metas. Riscos apontados por desvios levados a sério.

11 O que você prefere? Previsão para desenvolvimento do projeto A:
Prazo previsto de 4 meses, podendo ser 1 mês antes ou 4 meses depois. 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
O erro no início pode variar entre 0,25 e 4 vezes o valor real, na definição entre 0,5 e 2 vezes, quando os requisitos estiverem definidos cerca de 0,67 a 1,5 vezes, quando os interfaces definidos entre 0,8 e 1,25. Quando o projeto estiver concluído, obviamente o erro é igual a 1. 0,25x Projeto interface Início Projeto detalhado Definição OK Requisitos OK

14 Cone de incerteza Projeto detalhado Interface Requisitos Definição Início O cone de incerteza se estreita com ações gerenciais concretas para reduzir as fontes de variação no projeto e revisão das estimativas com base em dados cada vez mais precisos e realistas. Se isso não ocorrer, em vez de um estreitamento do cone temos uma zona de incerteza de contornos desconhecidos. 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
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) Projeto detalhado Interface Requisitos Definição Início As estimativas podem ser ainda mais incertas se o projeto estiver sujeito aos problemas indicados no slide.

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 Desenvolvedores são de 20% a 30% otimistas (comprovado por pesquisas). Fatores de ajuste são pontos onde a direção pode forçar otimismo. Desconhecimento por definição não se identifica antecipadamente – descobre-se tarde demais. Orçamentação prematura cria compromissos forçados e limites de atuação. Cuidado com transmissão, divulgação e comunicação indevidas, pelo mesmo motivo.

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 Quando se inclui um novo requisito, o aumento de esforço não é linear em relação ao tamanho deste requisito! Quando se “corta” funcionalidades (geralmente no “sufoco”), a redução de esforço é menor do que a esperada!

22 Estimativa e gerência de projeto
Falta equipe quando planejado Recursos desviados Funcionalidades removidas Requisitos retirados P R O J E T O estimativa Requisitos acrescentados Por erro de planejamento ou coordenação membros da equipe não estão disponíveis no momento necessário. Membro utilizados p.ex. em exposição, palestra, etc. ou enviado para um curso. Às vezes profissionais são substituídos por outros menos experientes. É comum dar atendimento a sistemas anteriores em operação, bugs, urgências. Quando se acrescenta um novo membro há um período de adaptação – dele e da equipe. Equipe atendendo outro projeto Equipe menos experiente Novos recursos acrescentados

23 Outros fatores influentes no projeto
Tipo de software Recomendação: NÃO FAÇA PROJETOS GRANDES!!! (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: Um projeto com o pior analista de requisitos pode ter um aumento de 40% no esforço, enquanto o mesmo projeto, contando com o melhor analista de requisitos, pode ter um ganho de quase 30% no esforço. (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 Linguagem de programação não é, aqui, o domínio da equipe sobre ela, mas sua adequação ao tipo de software (p. ex. Que tal usar COBOL para um aplicativo embarcado em celular?).

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 Geralmente uma combinação dessas
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) Esforço: 1 programadora durante 9 meses não é igual a 9 programadoras em 1 mês!!!

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 Especialista no domínio, na tecnologia, no tipo de projeto, em formular estimativas... Estimadores concentram-se na sua especialidade e descuidam do que não entendem profundamente. Granularidade: elicitação de requisitos, definição e arquitetura, projeto, codificação, teste, homologação...

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. Isto acontece porque ao estimar partes menores às vezes erra-se para mais, às vezes para menos, e os erros de certa forma se compensam, produzindo um agregado mais acurado.

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? O estimador compreende perfeitamente seu objeto de estimativa. Cuidado com trabalhos escondidos Não se basear na memória (ela lembra a estimativa anterior, não o que aconteceu de fato). Quem vai realizar o trabalho deve concordar com a estimativa (mesmo que ele a tenha produzido). Quase sempre “espera-se” aumento de produtividade! Quase nunca é realmente o pior caso (desenvolvedores são otimistas). Convém documentar o que foi assumido, o embasamento.

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:
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. Método desenvolvido na Rand Corporation no final dos anos 40; O nome vem do oráculo da Grécia antiga; Este formato foi proposto por Boehm e outros em revisão do formato original, que, no caso de software, não provou ser melhor que um processo menos estruturado, e ficava muito sujeito a pressões políticas. Experiências do McConnel sugerem melhoria da ordem de 40% sobre a média original do grupo e cerca de 2/3 das estimativas foram mais acuradas. Uma qualidade é evitar erros extravagantes. Entretanto, outros estudos não mostraram resultados melhores do que a média inicial do grupo. É um método “caro”, pois gasta bastante tempo dos membros do grupo. Recomenda em casos de novo domínio ou tecnologia, para obter uma ordem de magnitude no início do projeto.

37 Processo de estimativa
Entradas definidas para esta avaliação específica Processo ad hoc Estimativas não confiáveis Características técnicas Esforço estimado Processo padronizado Prazo estimado Prioridades Custo estimado Restrições Produtos estimados Dados históricos

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%). Em mais de 300 projetos com a primeira opção, raros conseguiram compensar, a maioria atrasou mais ainda. O problema com a segunda opção é que as tendências costumam a ter causas sistêmicas. A resposta correta é a terceira... Mas é a mais dolorosa!

39 Como apresentar estimativas
Etapa Estimativa Concepção 10 3-40 Definição do produto 5-20 Requisitos aprovados 13 9-20 Projeto da interface 14 12-18 Primeira iteração 16 15-18 FINAL 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
300 150 250 200 100 50 ESFORÇO (homem-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 O importante é manter a consistência, estimando e controlando com o mesmo critério

46 Estimando Riscos e Contingenciando
Probab Prazo (semanas) Custo R$ 1000 Severidade Exposição 1 5% 15 0,75 150 7,5 2 25% 0,5 20 5 3 8 80 4 50% 10 TOTAL 4,25 42,5 Os valores apresentados são o VALOR ESPERADO, ou seja, estatisticamente há uma probabilidade de 50% de que a realidade fique abaixo e 50% de que fique acima. Isto dá uma base para escolha de um “buffer” de contingência (claro que se os riscos forem decentemente estimados). ATENÇÃO: Basta que ocorra o risco número 1 ou 3 para “estourar” o “buffer” básico!