Estimativas em projetos de software

8,884 views
8,660 views

Published on

Na indústria de desenvolvimento de software atual, fazer boas estimativas é essencial para a sobrevivência das organizações. Estimar muito acima do que será a realidade pode ocasionar propostas perdedoras em concorrências e estimar muito abaixo pode ocasionar enormes prejuízos financeiros. Nessa palestra veremos o que é uma estimativa, suas características, o processo de estimar e algumas técnicas, como o COCOMO II. Apresentaremos também alguns resultados de estudos realizados no Synergia.

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,884
On SlideShare
0
From Embeds
0
Number of Embeds
490
Actions
Shares
0
Downloads
0
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Estimativas em projetos de software

  1. 1. Estimativas em projetos de software Vitor Alcântara Batista Engenharia de Processos
  2. 2. Agenda O que é uma estimativa e conceitos relacionados Fatores que influenciam as estimativas Técnicas de estimativa – Wideband Delphi – COCOMO II – Composição/decomposição 2
  3. 3. 1. O que é uma estimativa e conceitos relacionados
  4. 4. O “Processo” usual de Estimativas de Software O quêee?! Tudo isso?? Mas precisamos disso pronto em Entrada “Processo” de Estimativa 2 meses! (?) estimativa (??) Não seja pessimista! Neste projeto tudo vai caminhar melhor Estimativa “melhor” “Readequação” (????) Gerencial
  5. 5. Por que ocorre essa “Revisão Gerencial”? Provavelmente pelo desconhecimento da diferença entre: – Estimativa – Meta – Objetivo de negócio de uma organização
  6. 6. Estimativa, meta e objetivo de negócio Objetivo de negócio Meta Estimativa Prazo
  7. 7. Risco do projeto Objetivo de negócio Meta Estimativa Risco Prazo
  8. 8. Estimativa x Meta Estimativa Meta
  9. 9. Exemplo de estimativa Pergunta: “Forneça uma estimativa da temperatura da superfície do Sol em ºC que tenha uma confiabilidade de 90%” Era esperado uma resposta do tipo: “Entre 500 ºC e 10.000 ºC” Resposta correta: aproximadamente 6000 ºC.
  10. 10. Agora que aprendemos... Estimar com 90% de confiança: – Qual a altura da torre Burj Dubai, o maior prédio do mundo? – Resp: aprox. 828m 10
  11. 11. O que é uma boa estimativa? 100% Mediana (50/50) Probabilidade Cronograma, Esforço, Custo Uma boa estimativa é aquela que tem 25% ou menos de erro, em pelo menos 75% dos casos [McConnell 2006]
  12. 12. A Lei de Parkinson “O trabalho expande-se de modo a preencher o tempo disponível para sua realização.” Cyril Northcote Parkinson, “Parkinson's law: The pursuit of progress”, John Murray, 1958
  13. 13. Subestimar x superestimar Nan, N., & Harter, D. E. (2009). Impact of Budget and Schedule Pressure on Software Development Cycle Time and Effort. IEEE Transactions on Software Engineering
  14. 14. O cone da incerteza 10 4 2 1,5 1,25 1,1 1 1 0,9 1 0,8 0,67 0,5 0,25 0,1 C on ce p ção A p r ovação da Re q u is itos De s e n h o d e De s e n h o Pr o du to in icial d e fin ição do co m ple tos in te r face s d e talh ado com p le to pr o d u to com p le to com p le to Fases do processo Barry Boehm, Software Engineering Economics, Prentice Hall, 1981.
  15. 15. Por que as estimativas dão errado? Excesso de alterações de requisitos (acertar um alvo que se move) Falta de conhecimento da organização sobre sua própria capacidade (dados históricos) Otimismo Requisitos imprecisos ou incompletos Estimativas só são confiáveis em fases adiantadas dos projetos, mas normalmente são requeridas na base do “cone da incerteza”
  16. 16. Influência de dados irrelevantes 2 Experimentos realizado com 165 profissionais Grupo Meta do cliente Mediana da estimativa Very_low 4 60 h Low 40 100 h High 800 300 h Control - 160 h Grupo Palavras usadas Mediana da estimativa Low Pequena melhoria 40 h High Nova 80 h funcionalidade Control melhoria 50 h M. Jørgensen, and S. Grimstad. Avoiding Irrelevant and Misleading Information When Estimating Development Effort, IEEE Software(May/June):78-83, 2008. Trabalhos semelhantes: http://simula.no/people/magnej/bibliography 16
  17. 17. Indicadores de acurácia de estimativas PRED(x) = % de erros menores que x ŷ = valor estimado, y = valor real 17
  18. 18. 2. Fatores que influenciam as estimativas
  19. 19. Alguns fatores que influenciam as estimativas Tamanho do projeto/produto sendo desenvolvido Tipo de produto Equipe do projeto
  20. 20. Tamanho do produto Em software há deseconomia de escala
  21. 21. Deseconomia de escala Porque há essa deseconomia?
  22. 22. Crescimento exponencial dos canais de comunicação 3 canais 6 canais E para uma equipe de 10 pessoas? 45 canais
  23. 23. Tipo do produto LOC/PM Tipo de Software 10,000-LOC 100,000-LOC 250,000-LOC Aeronáutica 200 50 40 Sistemas de Gestão 3.000 600 500 Sistemas embutidos 300 70 60 Sistemas para Internet 1.500 300 200 Sistemas para Intranet 4.000 800 600 Tempo real 200 50 40
  24. 24. Equipe
  25. 25. Outros fatores Requisitos de desempenho / tamanho da base de dados Requisitos de usabilidade Flexibilidade na proposição da solução Distribuição espacial da equipe Pressão pelo prazo de entrega
  26. 26. 3. Técnicas de estimativa
  27. 27. O Processo “correto” de estimativas Requisitos Estimar tamanho Tamanho do produto Estimar esforço de Produtividade Dados desenvolvimento históricos Distribuição de Recursos Estimar cronograma e esforço disponíveis alocação de recursos Indicadores de Estimar custo por recurso custo Verificar Estimativa [ e stimati vas estimativas aprovada reprovadas ] [ estimativas Analisar o processo aprovadas ] de estimativa [ obtenção de dados reais, alteração de requisitos ] Acompanhar Dados reais desenvolvimento do projeto [ sim ] Necessário reestimar? [ não ]
  28. 28. Técnicas de estimativa Utilização de dados históricos Wideband Delphi COCOMO II Decomposição e composição Outras
  29. 29. Tipos de dados históricos Dados da Indústria (ISBSG, COCOMO, etc). Dados da organização Dados do projeto em execução
  30. 30. Dados básicos a serem coletados Tamanho (LOC, PF, etc.) Esforço (PM ou horas) Prazo
  31. 31. Exemplo Projeto Tamanho (PF) Esforço (PM) Prazo (meses) A 1000 12,5 12 B 2000 29 22 C 500 6,25 4 D (novo) 3500 ? ?
  32. 32. Exemplo Produtividade Projeto Tamanho (PF) Esforço (PM) Prazo (meses) (PF/PM) A 1000 12,5 12 80,00 B 2000 29 22 68,97 C 500 6 4 83,33 Média 77,43 D (novo) 3500 45,20 ? 77,43
  33. 33. Dados ISBSG para novos desenvolvimentos
  34. 34. Wideband Delphi É uma técnica de estimativa em grupos de especialistas Útil principalmente quando o conceito do projeto ainda está muito indefinido Como funciona: 1. O coordenador distribui a “especificação do projeto/produto” e um formulário para estimativa a cada membro 2. Os membros são reunidos para discutir aspectos de estimativa relacionados ao projeto. 3. Cada participante faz a sua estimativa individual
  35. 35. Wideband Delphi (cont.) 4. O coordenador prepara um relatório com as estimativas: 5. O grupo se reúne e discute as variações 6. Os participantes votam anonimamente, se aceitam ou não a média. Se não houver unanimidade, recomeça do passo 3.
  36. 36. COCOMO II COnstrutive COst MOdel. – Método paramétrico proposto por Barry Boehm (e outros) para estimar tamanho e prazo de projetos. – Se baseia nas equações abaixo:
  37. 37. Destrinchando o COCOMO B = 0,91 SFj = Fatores de escala – Precedência – Flexibilidade na solução – Resolução de riscos/arquitetura – Coesão da equipe – Maturidade do processo
  38. 38. Fatores de escala Impactam no expoente da equação
  39. 39. Destrinchando o COCOMO, parte 2 A = 2,94 Size = tamanho em milhares de SLOC, mas pode-se usar pontos de função não ajustados ou pontos de objetos EMi = 16 (ou 5) multiplicadores de esforços, divididos em: – Produto – Plataforma – Pessoal – Projeto
  40. 40. Níveis dos fatores de escala
  41. 41. Níveis dos multiplicadores de esforço Para o parâmetro CPLX (complexidade do produto) Para ACAP (capacitação do analista de requisitos)
  42. 42. Resumindo A = 2,94 e B = 0,91 Com todos os parâmetros no nível nominal, teremos: E = 0,91 + 0,01 x 18,97 = 1,1 PM = 2,94 x Size^1,1 x 1
  43. 43. Resultados do COCOMO II no Synergia Sem calibração Calibrado
  44. 44. Composição e decomposição Dividir o projeto em partes menores, como módulos ou funcionalidades Funcionalidade Esforço estimado (PM) 1 2 2 2,5 3 1 4 0,5 5 1 6 3 Total 10 Qual a vantagem?
  45. 45. “Lei dos números grandes” Esforço Funcionalidade Esforço real Erro estimado 1 2 3 50,0% 2 2,5 2,1 -16,0% 3 1 0,5 -50,0% 4 0,5 1,2 140,0% 5 1 2 100,0% 6 3 2 -33,3% Total 10 10,8 8,0%
  46. 46. Experiência no Synergia 46
  47. 47. Resultado de estimativas feitas pelos executores das tarefas no Synergia MMRE = 21,8%. Anterior: 52,8%. PRED(0,25) = 69,6% . Anterior: 36,8%
  48. 48. Outras técnicas de estimativa Modelos baseados em Proxy – Utiliza tabelas de complexidade baseada em número de alguns componentes. Ex: telas, classes, relatórios, tabelas de banco de dados, etc. Técnicas de Aprendizado de máquina – redes neurais e redes neuro-fuzzy Técnicas estatísticas de regressão linear
  49. 49. Qual a melhor técnica? Não há uma resposta definitiva – Jorgensen, M., & Shepperd, M. (2007). A Systematic Review of Software Development Cost Estimation Studies. IEEE Transactions on Software Engineering. 49
  50. 50. Perguntas?
  51. 51. Contato Vitor Alcântara Batista Equipe de Engenharia de processos vitor@dcc.ufmg.br 51

×