estimativas de esforço - engenharia de software
DESCRIPTION
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
Estimativas de EsforçoEduardo Mendes
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Dificuldades
15
falta de métricas precisas
falta de dados históricos
quantidade de variáveis envolvidas
imprevistos e mudanças de rumo
Eduardo Mendes ([email protected])
Incerteza
Concepçãodo projeto
16
400%
Aprovaçãodo projeto
150% 200%
[FONTE: MANTEIGA, Sandro]
Eduardo Mendes ([email protected])
3. Abordagens para Estimativas
3.1 Processos de Estimativa Baseados
em Processos de Especialistas
3.2 Processos de Estimativas Baseados
em Modelos
19
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Esforço = α x tamanho β x fator de ajustefator constante que depende das práticas organizacionais locais e do tipo de software em desenvolvimento
21
varia geralmenteentre 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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])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
asmétricas
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Fator de Ajuste1. 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?
Eduardo Mendes ([email protected])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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Contagem dos Atores
∑ Peso dos Atores não ajustado = ∑ Fator dos Atores
38
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Contagem dos Casos de Uso
∑ Peso dos Casos de Uso não ajustado = ∑ Fator dos Casos de Uso
40
Eduardo Mendes ([email protected])
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)!
Eduardo Mendes ([email protected])
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]
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Fatores Ambientais
47
Fator Descrição PesoA1 Familiaridade com o Processo de 1.5A2 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
A8Dificuldade da linguagem de
programação2
Eduardo Mendes ([email protected])
PCUs ajustados
PCU ajustados = Peso dos Casos de Uso não ajustado * TCF * EF
48
Eduardo Mendes ([email protected])
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.
Eduardo Mendes ([email protected])
Esforço = PCU x produtividade
50
Esforço = PCU x produtividade x risco x gestão
Eduardo Mendes ([email protected])
Processo de gerenciamento diferenciado
Scrum
Product Owner
Scrum Master
Time
52
Eduardo Mendes ([email protected])
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
Planning Poker
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
Velocidade
58
A velocidade é obtida através do cálculo da soma dos SPs de todas as estórias de usuárioque foram realizadas por completo durante uma iteração
Eduardo Mendes ([email protected])
Velocidade
62
Utiliza-se a velocidade para planejar a quantidade de estórias a serem realizadas nas iterações seguintes
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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 precisaser distribuído entre as diversas atividades/módulos
Problemas técnicos difíceis podemnão ser considerados
Estimativas menos acuradas
!66
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
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
Eduardo Mendes ([email protected])
+ 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
Eduardo Mendes ([email protected])
+ 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
Eduardo Mendes ([email protected])
• Refinamento das comparações entre abordagens
• Pontos de Função Cosmic
• Wideband Delphi
Continuação da pesquisa
73