Estimativas de Esforço - Engenharia de Software

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

mailto:[email protected]


1 2 3 4 5



1. Introdução

4



Processode Software

5



1 2 3 4 5



2. Estimativas

7



2. Estimativas2.1 O que é

2.2 Benefícios

8



O que é estimar?

9

determinar o valor de uma coisa



O que éestimativa?

10

cálculo aproximado

avaliação

conjectura


Eduardo Mendes ([email protected])11

previsãoestimativa não éuma



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



Tradicional Ágil



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



Dificuldades

15

falta de métricas precisas

falta de dados históricos

quantidade de variáveis envolvidas

imprevistos e mudanças de rumo



Incerteza

Concepçãodo projeto

16

400%

Aprovaçãodo projeto

150% 200%

[FONTE: MANTEIGA, Sandro]



1 2 3 4 5



3. Abordagens para estimativas

18



3. Abordagens para Estimativas

3.1 Processos de Estimativa Baseados

em Processos de Especialistas

3.2 Processos de Estimativas Baseados

em Modelos

19



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



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



1 2 3 4 5




23




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



4.1 Análise de Pontos de Função

25



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



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



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



∑PFA = ∑PFNA * fator de ajuste

29



Cálculo e Ponderação

30

(Adaptado de PRESSMAN, 2011)



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?



fator de ajuste = (0,01 x ∑ Pesos) + 0,65

32



Esforço

Esforço = PF de desenvolvimento x produtividade

33



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



4.2 Pontos de Caso de Uso

35



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




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



Contagem dos Atores

∑ Peso dos Atores não ajustado = ∑ Fator dos Atores

38



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



Contagem dos Casos de Uso

∑ Peso dos Casos de Uso não ajustado = ∑ Fator dos Casos de Uso

40



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)!



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]




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



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



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



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



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



PCUs ajustados

PCU ajustados = Peso dos Casos de Uso não ajustado * TCF * EF

48



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.



Esforço = PCU x produtividade

50

Esforço = PCU x produtividade x risco x gestão



4.3 Métricas em processos ágeis

51



Processo de gerenciamento diferenciado

Scrum

Product Owner

Scrum Master

Time

52



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


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



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



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



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



01 iteração

04 !estórias



20 SPs/Iteração

04 !estórias



15 SPs/Iteração

03 !estórias



Velocidade

62

Utiliza-se a velocidade para planejar a quantidade de estórias a serem realizadas nas iterações seguintes



1 2 3 4 5



5. Considerações Finais

64



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



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



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



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



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



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



+ 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



+ 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



• Refinamento das comparações entre abordagens

• Pontos de Função Cosmic

• Wideband Delphi

Continuação da pesquisa

73



Obrigado

74
