Estimativas de Esforço

Apresentação sobre tipo de estimativas de esforço na Engenharia de Software.
Descrição de abordagens baseadas em modelos formais e julgamento de especialista.
Apresenta uma visão geral sobre Análise de Pontos de Função, Pontos de Casos de Uso e Pontos de Estórias de Usuário.
Breve comparação entre estas abordagens.

Transcript

1. Estimativas de Esforço Eduardo Mendes
2. Eduardo Mendes (edumendes@gmail.com) Agenda 1. Introdução 2. O Que é Estimativa 3. Abordagens Para Estimativas 4. Métricas para Estimativas Análise de Pontos de Função Pontos de Caso de Uso Pontos de Estórias de Usuário 5. Considerações Finais 2
3. Eduardo Mendes (edumendes@gmail.com) 1 2 3 4 5
4. Eduardo Mendes (edumendes@gmail.com) 1. Introdução 4
5. Eduardo Mendes (edumendes@gmail.com) Processo
 de Software 5
6. Eduardo Mendes (edumendes@gmail.com) 1 2 3 4 5
7. Eduardo Mendes (edumendes@gmail.com) 2. Estimativas 7
8. Eduardo Mendes (edumendes@gmail.com) 2. Estimativas 2.1 O que é 2.2 Benefícios 8
9. Eduardo Mendes (edumendes@gmail.com) O que é estimar? 9 determinar o valor de uma coisa
10. Eduardo Mendes (edumendes@gmail.com) O que é
 estimativa? 10 cálculo aproximado avaliação conjectura
11. Eduardo Mendes (edumendes@gmail.com) 11 previsão estimativa não é
 uma
12. Eduardo Mendes (edumendes@gmail.com) Estimar Uma das atividades ligadas ao planejamento de projeto Criação de cronogramas Análise de Riscos Gerenciamento da qualidade Gerenciamento de alterações 12
13. Eduardo Mendes (edumendes@gmail.com) Tradicional Ágil
14. Eduardo Mendes (edumendes@gmail.com) Benefícios 14 Prever o quanto é possível fazer em um determinado período de tempo Identificar perdas e ganhos em face da velocidade da equipe As estimativas auxiliam o processo de decisão do cliente
15. Eduardo Mendes (edumendes@gmail.com) Dificuldades 15 falta de métricas precisas falta de dados históricos quantidade de variáveis envolvidas imprevistos e mudanças de rumo
16. Eduardo Mendes (edumendes@gmail.com) Incerteza Concepção
 do projeto 16 400% Aprovação
 do projeto 150% 200% [FONTE: MANTEIGA, Sandro]
17. Eduardo Mendes (edumendes@gmail.com) 1 2 3 4 5
18. Eduardo Mendes (edumendes@gmail.com) 3. Abordagens para estimativas 18
19. Eduardo Mendes (edumendes@gmail.com) 3. Abordagens para Estimativas 3.1 Processos de Estimativa Baseados em Processos de Especialistas 3.2 Processos de Estimativas Baseados em Modelos 19
20. Eduardo Mendes (edumendes@gmail.com) Estimativa Baseada" em Julgamento" de Especialista Estimativas
 Baseadas em Modelos Indivíduo com competência para estimar esforço baseada na intuição e experiência Uso de fórmulas matemáticas que utilizam entradas como a quantificação de tamanho de projeto, o tipo de software que se quer construir e outros fatores
21. Eduardo Mendes (edumendes@gmail.com) Esforço = α x tamanho β x fator de ajuste fator constante que depende das práticas organizacionais locais e do tipo de software em desenvolvimento 21 varia geralmente
 entre 1 e 1,5 α medida tamanho da funcionalidade advinda da especificação de requisitos feita pelo cliente tamanho β valor vindo da combinação de atributos do processo, produtos de desenvolvimento fator de ajuste
22. Eduardo Mendes (edumendes@gmail.com) 1 2 3 4 5
23. Eduardo Mendes (edumendes@gmail.com) 4. Métricas para Estimativas 23
24. Eduardo Mendes (edumendes@gmail.com) 4. Métricas para Estimativas 4.1 Análise de Pontos de Função 4.1.1 A Estimativa de Esforço co APF 4.2 Pontos de Caso de Uso 4.2.1 A Estimativa de Esforço com PCU ! 4.3 Métricas em Processos Ágeis 4.3.1 Pontos de Estórias de Usuário 4.3.2 Planning Poker 4.3.3 Velocidade 24
25. Eduardo Mendes (edumendes@gmail.com) 4.1 Análise de Pontos de Função 25
26. Eduardo Mendes (edumendes@gmail.com) Foi proposta, inicialmente, por Albrecht e Gaffney Refinada pelo Ineternational Function Point Users Group (IFPUG) Foi o primeiro método para dimensionar software independente da tecnologia em que era desenvolvido 26 Análise
 de Pontos de Função
27. Eduardo Mendes (edumendes@gmail.com) 27 entradas fornecidas à aplicação ! saídas da aplicação ! consultas dos usuários ! arquivos lógicos ou de dados a serem atualizados pela aplicação interfaces com outras aplicações as
 métricas
28. Eduardo Mendes (edumendes@gmail.com) O processo de contagem i. determina-se o tipo de contagem ii. identifica-se o escopo de contagem e a fronteira da aplicação iii. contam-se as funções de dados iv. contam-se as funções transacionais v. determinam-se os PF não ajustados vi. determinam-se os valores dos fatores de ajustes vii. calculam-se os PF ajustados 28
29. Eduardo Mendes (edumendes@gmail.com) ∑PFA = ∑PFNA * fator de ajuste 29
30. Eduardo Mendes (edumendes@gmail.com) Cálculo e Ponderação 30 (Adaptado de PRESSMAN, 2011)
31. Eduardo Mendes (edumendes@gmail.com) Fator de Ajuste 1. O sistema requer salvamento (backup) e recuperação confiável (recovery)? 2. São necessárias comunicações de dados especializadas para transferir informações para aplicação ou da aplicação? 3. Há funções de processamento distribuído? 4. O desempenho é crítico? 5. O sistema rodará em um ambiente operacional existente e intensamente utilizado? 6. O sistema requer entrada de dados online? 7. A entrada online de dados requer que a transação de entrada seja composta em múltiplas telas ou operações? 31 8. Os ALIs são atualizados online? 9. As entradas, saídas, arquivos ou consultas são complexas? 10. O processamento interno é complexo? 11. O código é projetado para ser reutilizável? 12. A conversão e instalação são incluídas no projeto? 13. O sistema é projetado para múltiplas instalações em diferentes organizações? 14. A aplicação é projetada para facilitar a troca e o uso pelo usuário?
32. Eduardo Mendes (edumendes@gmail.com) fator de ajuste = (0,01 x ∑ Pesos) + 0,65 32
33. Eduardo Mendes (edumendes@gmail.com) Esforço Esforço = PF de desenvolvimento x produtividade 33
34. Eduardo Mendes (edumendes@gmail.com) 34 20% 05 pessoas = 20h/PF > 8h/dia Esforço = 20 PF x 20h/PF = 400h Esforço/pessoa = 400h / 5 = 80h Dias de esforço = 80h / 8h = 10 dias
35. Eduardo Mendes (edumendes@gmail.com) 4.2 Pontos de Caso de Uso 35
36. Eduardo Mendes (edumendes@gmail.com) Pontos de Caso de Uso Após 10 anos da proposta dos Pontos de Função, surgiu a medida Pontos por Caso de Uso (PCU) proposta por KARNER (1993), que é uma adaptação da APF Foco fazer estimativa de tamanho sobre sistemas de software orientados a objeto Depende de uma padronização dos casos de uso, em razão desta contagem ser realizada a partir das transações identificadas nos fluxos de eventos. 36
37. Eduardo Mendes (edumendes@gmail.com) O processo de contagem i. contam-se os atores e atribui-se o grau de complexidade ii. contam-se os casos de uso e atribui-se o grau de complexidade iii. somam-se o total de atores com o total de casos de uso para obter o PCU não ajustado iv. determina-se a complexidade do fator técnico v. determina-se a complexidade do fator ambiental vi. calcula-se o PCU ajustado. 37
38. Eduardo Mendes (edumendes@gmail.com) Contagem dos Atores ∑ Peso dos Atores não ajustado = ∑ Fator dos Atores 38
39. Eduardo Mendes (edumendes@gmail.com) Ponderação dos Atores 39 Complexidade Descrição Fator Simples Aplicação com API definida 1 Intermediário Aplicação interface baseada em porotocolo ou interação de usuário por linha de comando 2 Complexo Usuário com interface gráfica 3
40. Eduardo Mendes (edumendes@gmail.com) Contagem dos Casos de Uso ∑ Peso dos Casos de Uso não ajustado = ∑ Fator dos Casos de Uso 40
41. Eduardo Mendes (edumendes@gmail.com) Ponderação dos Atores 41 Nível Descrição Fator Simples 03 ou mais transações 5 Intermediário de 04 a 07 transações 10 Complexo de 08 a 11 transações 15 N-Complexo além de 11 transações Fx* Fx = 15*(transações/11) + Fator(resto da divisão transações/11)!
42. Eduardo Mendes (edumendes@gmail.com) Transação 42 Na análise de PCU transação é um conjunto de atividades atômicas, que são executadas completamente, ou não ! Pode-se atribuir uma transação a cada passo do fluxo que precisa ser executado por completo, ou à realização de um processamento complexo [RIBU, 2001]
43. Eduardo Mendes (edumendes@gmail.com) O processo de contagem i. contam-se os atores e atribui-se o grau de complexidade; ii. contam-se os casos de uso e atribui-se o grau de complexidade; iii. somam-se o total de atores com o total de casos de uso para obter o PCU não ajustado; iv. determina-se a complexidade do fator técnico v. determina-se a complexidade do fator ambiental, e vi. calcula-se, então, o PCU ajustado. 43
44. Eduardo Mendes (edumendes@gmail.com) Fator Técnico (TCF) 44 TCF = 0,6 + (0,01 x FatorT) O Fator de Complexidade Técnica (TCF) é calculado utilizando a soma das multiplicações dos valores atribuídos a cada fator da Tabela de fatores técnicos pelos seus pesos, gerando a valor chamado de FatorT
45. Eduardo Mendes (edumendes@gmail.com) Fatores Técnicos 45 Fator Descrição Peso T1 Sistema distribuído 2 T2 Tempo de resposta 2 T3 Eficiência online 1 T4 Processamento complexo 1 T5 Código reutilizável 1 T6 Facilidade de instalação 0.5 T7 Facilidade de uso 0.5 T8 Portabilidade 2 T9 Facilidade de manutenção 1 T10 Acesso concorrente 1 T11 Aspectos relativos à segurança 1 T12 Acesso para terceiros 1 T13 Treinamento especial obrigatório 1
46. Eduardo Mendes (edumendes@gmail.com) Fator Ambiental (EF) 46 EF = 1,4 + (-0,03 x FatorE) O Fator Ambiental (EF) é calculado utilizando a soma das multiplicações dos valores atribuídos a cada fator da Tabela de Fatores ambientais pelos seus pesos
47. Eduardo Mendes (edumendes@gmail.com) Fatores Ambientais 47 Fator Descrição Peso A1 Familiaridade com o Processo de 1.5 A2 Experiência na aplicação 0.5 A3 Experiência em orientação a objetos 1 A4 Capacidade do líder de projeto 0.5 A5 Motivação 1 A6 Estabilidade dos requisitos 2 A7 Membros da equipe com tempo parcial -1 A8 Dificuldade da linguagem de programação 2
48. Eduardo Mendes (edumendes@gmail.com) PCUs ajustados PCU ajustados = Peso dos Casos de Uso não ajustado * TCF * EF 48
49. Eduardo Mendes (edumendes@gmail.com) Cálculo do Esforço De Sousa e Abreu (2011) apresentam um modelo para o cálculo do esforço utilizando PCUs Para isso eles utilizam mais 03 fatores: 49 produtividade, que representa a quantidade de horas necessárias para se produzir 01 ponto de caso de uso risco, que transmite o fator de incerteza do projeto gestão, que representa o esforço de planejamento e acompanhanento do desenvolvimento do sistema.
50. Eduardo Mendes (edumendes@gmail.com) Esforço = PCU x produtividade 50 Esforço = PCU x produtividade x risco x gestão
51. Eduardo Mendes (edumendes@gmail.com) 4.3 Métricas em processos ágeis 51
52. Eduardo Mendes (edumendes@gmail.com) Processo de gerenciamento diferenciado Scrum Product Owner Scrum Master Time 52
53. Eduardo Mendes (edumendes@gmail.com) Pontos de Estória de usuário Nas abordagens ágeis, os requisitos de usuário são descritos através de estórias de usuário O Ponto de Estória de Usuário é uma unidade de estimativa relativa É representado por um número inteiro que é a agregação de um conjunto de aspectos que interferem no tamanho potencial de uma estória 53
54. Planning Poker
55. Eduardo Mendes (edumendes@gmail.com) Planning Poker O planning poker (PP) é um método ágil que gera estimativas que são feitas pelo time como um todo, não partindo de uma só pessoa ! Estimativa coletiva 55
56. Eduardo Mendes (edumendes@gmail.com) Planning Poker todo os membros do time participam e são “estimadores”; o PO participa mas não opina nas estimativas; cada membro do time recebe um conjunto de cartas (baralho) com valores associados: 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 56
57. Eduardo Mendes (edumendes@gmail.com) Velocidade 57 Neste processo,
 a velocidade é uma medida para a taxa de progresso de uma equipe ! Através dela é que se é capaz de saber o quanto de esforço que uma equipe pode realizar
58. Eduardo Mendes (edumendes@gmail.com) Velocidade 58 A velocidade é obtida através do cálculo 
 
 da soma dos SPs de todas as estórias de usuário
 
 que foram realizadas por completo durante uma iteração
59. Eduardo Mendes (edumendes@gmail.com) 59 01 iteração 04 ! estórias
60. Eduardo Mendes (edumendes@gmail.com) 60 20 SPs/Iteração 04 ! estórias
61. Eduardo Mendes (edumendes@gmail.com) 61 15 SPs/Iteração 03 ! estórias
62. Eduardo Mendes (edumendes@gmail.com) Velocidade 62 Utiliza-se a velocidade para planejar a quantidade de estórias a serem realizadas nas iterações seguintes
63. Eduardo Mendes (edumendes@gmail.com) 1 2 3 4 5
64. Eduardo Mendes (edumendes@gmail.com) 5. Considerações Finais 64
65. Eduardo Mendes (edumendes@gmail.com) Processos de Estimativas Baseados em Modelos Rápidos e fáceis de aplicar Podem ser usados no início do projeto São objetivos e passíveis de repetição 65
66. Eduardo Mendes (edumendes@gmail.com) Processos de Estimativas Baseados em Modelos Muito específicos para um determinado contexto Em geral, não são muito precisos Estimam o esforço total, que depois precisa
 ser distribuído entre as diversas atividades/módulos Problemas técnicos difíceis podem
 não ser considerados Estimativas menos acuradas ! 66
67. Eduardo Mendes (edumendes@gmail.com) Estimativa Baseada em Julgamento de Especialista Pouca ou nenhuma necessidade de dados históricos Pode ser usado no início do projeto e em situações onde se lida com novas tecnologias, aplicações ou linguagens Bastante flexível com relação ao objeto das estimativas 67
68. Eduardo Mendes (edumendes@gmail.com) Estimativa Baseada em Julgamento de Especialista A opinião dos especialistas pode ser tendenciosa e/ou influenciável O conhecimento e domínio dos especialistas sobre o assunto pode ser questionável 68
69. Eduardo Mendes (edumendes@gmail.com) Evidências na literatura Jørgensen (2007) avalia diversas abordagens de estimativas de esforço e conclui: os modelos falharam sistematicamente ao tentar realizar estimativas melhores do que as dos especialistas 69
70. Eduardo Mendes (edumendes@gmail.com) Possíveis razões os especialistas podem ter mais informações sobre o contexto e a forma como a informação é processada é mais flexível a falta de estabilidade entre os dados que estão sendo relacionados em um modelo falta de precisão na calibragem dos modelos 70
71. Eduardo Mendes (edumendes@gmail.com) + literatura Fowler (2013) também aponta problemas nas estimativas por especialistas em processos ágeis, principalmente, quando há uma tendência há ser muito otimista isto tem sido relatado por muitos times ágeis, transformando a estimativa em uma cobrança 71
72. Eduardo Mendes (edumendes@gmail.com) + literatura Jørgensen aconselha a utilização das abordagens combinadas nesta situação de otimismo e também quando: • a quantidade de informações contextuais do especialista é baixa • quando os modelos utilizados estão bem calibrados 72
73. Eduardo Mendes (edumendes@gmail.com) • Refinamento das comparações entre abordagens • Pontos de Função Cosmic • Wideband Delphi Continuação da pesquisa 73
74. Eduardo Mendes (edumendes@gmail.com) Obrigado 74