A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 Estimativas de Projeto de Software Principal referência: SOFTWARE ESTIMATION: Demystifying the Black Art Steve McConnel, 2006 Microsoft Press Adaptação.

Apresentações semelhantes


Apresentação em tema: "1 Estimativas de Projeto de Software Principal referência: SOFTWARE ESTIMATION: Demystifying the Black Art Steve McConnel, 2006 Microsoft Press Adaptação."— Transcrição da apresentação:

1 1 Estimativas de Projeto de Software Principal referência: SOFTWARE ESTIMATION: Demystifying the Black Art Steve McConnel, 2006 Microsoft Press Adaptação de Rodrigo Nin sobre trabalho de Márcio Pecegueiro

2 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 3 Conceitos básicos O que se quer estimar? » Tamanho » Esforço » Custo » Prazo

4 4 Conceitos básicos TAMANHO ESFORÇO CUSTOPRAZO

5 5 Estimativa boa O uso de dados históricos e métodos estatísticos reduz muito a dispersão das estimativas

6 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 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 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 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 ApertadaFolgada

10 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 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 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 13 Cone de incerteza 1x 2x 4x 0,5x 0,25x Início Definição OK Requisitos OK Projeto interface Projeto detalhado Acurácia

14 14 Cone de incerteza Início Definição Requisitos 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 15 Cone de incerteza Fontes adicionais de variação Início Definição Requisitos 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 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 17 Requisitos de qualidade freqüentemente esquecidos Acurácia e precisão Interoperabilidade Manutenibilidade Desempenho Portabilidade Confiabilidade Reusabilidade Escalabilidade Segurança Recuperabilidade Usabilidade

18 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 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 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 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 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 23 Outros fatores influentes no projeto Tipo de software (fonte: Software Estimation, McConnel 2006, Putman&Meyers 1992, Putman&Meyers 1997, Putman&Meyers, 2003) (portanto, evite os projetos grandes...)

24 24 Outros fatores influentes no projeto Fatores pessoais x percentual de variação introduzido: (fonte: Software Estimation, McConnel, 2006)

25 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 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 27 Como estimar Medir (recomendável) Calcular (razoável) Julgar (se não tiver outro jeito) Geralmente uma combinação dessas

28 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 29 Por que medir ? Para calibrar seu modelo preditivo Para monitorar os projetos Para monitorar os processos

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

38 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 39 Como apresentar estimativas EtapaEstimativa Concepção Definição do produto Requisitos aprovados Projeto da interface Primeira iteração FINAL17

40 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 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 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 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 44 Estimando redução do prazo ESFORÇO (homem-mês) (Putnam & Meyers, 1992)

45 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 46 Estimando Riscos e Contingenciando RiscoProbab Prazo (semanas)Custo R$ 1000 SeveridadeExposiçãoSeveridadeExposição 15%150,751507,5 225%20, % % TOTAL 4,2542,5


Carregar ppt "1 Estimativas de Projeto de Software Principal referência: SOFTWARE ESTIMATION: Demystifying the Black Art Steve McConnel, 2006 Microsoft Press Adaptação."

Apresentações semelhantes


Anúncios Google