O documento discute estimativas de esforço para projetos de software e apresenta três abordagens: Análise de Pontos de Função, Pontos de Caso de Uso e métricas ágeis como Pontos de Estórias de Usuário. O autor também discute como calcular o esforço usando essas métricas e quais fatores influenciam as estimativas.
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
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
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
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
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
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
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?
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
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
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
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.
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
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
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