métricas e estimativas de projetos de software

Métricas e Estimativas de Projetos de Software

Métricas e Estimativas de Projetos de Software

Autor: Carla Alessandra Lima Reis

(Revisado por Roberto Petry)

Estimativas de Projetos – Carla A. Lima Reis

2

Objetivos Gerais

Abordar o assunto Estimativas de Projeto de software destacando as técnicas, heurísticas e ferramentas

necessárias para que o processo de estimativa seja incorporado à gerência

de projetos de software.

Parte IConceitos Fundamentais sobre Estimativas de Software


4

Introdução

O que é uma Estimativa? “avaliação ou cálculo aproximado de algo;

parecer sobre uma pessoa ou situação baseado nas evidências existentes.” (Houaiss)

É uma predição sobre quanto tempo um projeto levará ou quanto vai custar (McConnel, 2006)


5

Introdução

O que não é uma Estimativa?Metas e promessas não são estimativas

“Temos que terminar a versão 2 do sistema para a demonstração na feira de tecnologia...”

“Temos que concluir esses módulos em 1 de julho para atender as novas leis do governo.”

“O custo da próxima versão não pode passar de R$20.000, porque esse é o nosso orçamento aprovado...”


6

Introdução

Estimar projetos é um dos maiores desafios no desenvolvimento de software. Planejamento e controle adequados não são possíveis sem estimativas confiáveis

Em geral, a indústria de software não estima bem seus projetos


7

Introdução Relação entre Estimativa e Planejamento

Estimativa é um processo imparcial e analítico, enquanto planejamento é parcial e busca atingir uma meta.

Estimativa forma a base para o planejamento. Se as estimativas são diferentes das metas o planejamento

deve tratar essa diferença como um risco alto. Existem frequentes problemas de comunicação decorrentes

do relacionamento entre Estimativa e Planejamento.

Quando lhe pedirem uma estimativa, verifique se é para estimar ou descobrir uma forma de atingir a meta.


8

Introdução Toda estimativa é associada a uma probabilidade

Não existe estimativa com 100% de probabilidade

2 semanas

4 semanas

6 semanas

8 semanas

10 semanas

12 semanas

16 semanas

18 semanas

20 semanas

22 semanas

24 semanas90%

75%

50%

10%

0%

Probabilidade De sucesso

Tempo estimado


9

Introdução As estimativas tornam-se cada

vez mais precisas à medida em que aumenta o nível de maturidade da organização.

Apenas o uso de técnicas de estimativas não garante precisão. Deve haver efetiva gerência de projetos apoiando essa tarefa.

1 2 3Nível CMM

0%100%

200%

300%

400%

500%

Fonte:”A Correlational study of the CMM and Software Development Performance” (Lawlis, Flowe and Thordahl 1995)


10

IntroduçãoEstimativa e Controle de Projetos

Estimativa e Controle de ProjetosEstimar não é uma atividade puramente

preditiva “O ato de observar uma coisa já a modifica” (Princípio

da Incerteza de Heisenberg)

Projetos mudam bastante. Uma vez que produzimos uma estimativa e, com

base nisso, fazemos um planejamento para entregar o produto em uma data, então temos que controlar o projeto para que ele atinja a meta.


11

Estimativa e Controle de Projetos

O ProjetoSaída: 20 pessoas/mês

Estimativa: 20 pessoas/mês

Novos requisitos

adicionados

Equipe com pouca

experiência

Equipe não estava pronta

no prazo

Requisitos removidos

Equipe foi desviada para atender projeto

antigo (manutenção

urgente)

Equipe desviada para apoiar apresentação

em feira

Mais requisitos

adicionados

Funcionalidade instável

removida


12

Gestão de Projetos

Estimativa de:

- tamanho;- esforço;- custo;- prazo;- recursos computacionais;- riscos

(Re) Planejamento do Projeto

Acompanhamento do Projeto- resultados parciais x estimado- acompanhamento das atividades- ações corretivas- replanejamento

Análise de resultados (histórico do projeto)- resultados finais (estimado x realizado)- lições aprendidas

RequisitosRequisitos

Planejamento Inicial do ProjetoVisãoVisão


13

O que é uma Boa estimativa?

Uma boa estimativa provê uma visão suficientemente clara da realidade do

projeto para permitir que seu líder tome boas decisões sobre como controlá-lo

para atingir as metas

(Steve McConnel, 2006)


14

Precisão das Estimativas

“Estimativa é a previsão mais otimista com probabilidade não nula de se tornar realidade”(Tom DeMarco, 1982)

Sabemos que estimativas precisas são raras, então se vamos errar, devemos errar para mais ou para menos??


15

Por que não superestimar? Se o projeto for superestimado, o

trabalho ocupará todo o tempo disponível(Lei de Parkinson)

Se o gerente der 5 dias para o desenvolvedor fazer uma tarefa que pode ser feita em 4, o desenvolvedor vai encontrar alguma coisa pra fazer no dia extra.

Se as pessoas têm muito tempo pra fazer uma tarefa, elas irão adiar o início até chegar ao ponto de ter que correr pra terminar no prazo (e provavelmente não terminarão no prazo)

Para dar um sentimento de urgência no projeto.


16

Por que não subestimar?

Prejudica os planos do projeto Escolha de uma equipe menor que a necessária Problemas de integração entre grupos quando um

grupo não estiver pronto para integrar sua tarefa com outro

Reduz as chances de terminar no prazo Sabendo que tipicamente* as estimativas são de 20 a

30% inferiores ao realizado, subestimar o prazo reduz muito as chances do projeto terminar no prazo.

*(Van Genuchten, 1991)


17


Tendência a negligência de atividades técnicas importantes

Deixando de lado atividades importantes como requisitos e projeto para obter logo o produto, leva a necessidade de refazer tais atividades mais tarde, custando mais caro do que se fizesse bem feito de primeira**. O projeto assim leva muito mais tempo do que se tivesse sido estimado corretamente.

**(Boehm/Turner, 2004/McConnel 2004)


18


Um projeto no estado “atrasado” traz mais atraso. Mais reuniões são realizadas para discutir como concluir o

projeto Reestimativas frequentes são feitas para determinar quando o

projeto termina Pedidos de desculpas ao cliente (incluindo reuniões) Preparação de releases falsos para demonstração ao cliente

e a eventos Mais discussões sobre quais requisitos devem realmente ser

atendidos Conserto de bugs causados por implementações apressadas

devido à pressão do prazo.


19

O que fazer então?

As penalidades de subestimar o projeto são piores que as penalidades de superestimar.

Conselho de McConnel:Trate a superestimativa com

planejamento e controle.


20

Benefícios das estimativasprecisas Melhor visão do estado do projeto

é possível rastrear as ocorrências de acordo com o plano Aumento da qualidade

Aproximadamente 40% dos erros são causados por stress (Glass 1994)

Melhor gerência das outras tarefas do negócio Campanhas de marketing, treinamentos, projeções financeiras, etc.

Melhor definição de orçamento Aumento da credibilidade com a equipe de desenvolvimento Detecção antecipada de riscos

Diferenças entre as metas e as estimativas Ações corretivas podem ser tomadas mais cedo

Onde as estimativas erram?


22

Onde as estimativas erram?

Desenvolvimento de software consiste em tomar muitas decisões

A incerteza da estimativa resulta da incerteza da sobre como as decisões serão tomadas

Estudo do Cone da Incerteza


23

Cone da IncertezaGrau de erro nas estimativas de estimadores experientes

0,25x

0,5x

0,67x0,8x

1x1,25x

1,5x

2x

4x

Concepção Def. doprodutoaprovada

Def. de requisitoscompleta

Projeto de interfacecompleto

Projeto detalhadocompleto

Software completo

Variabilidadeda estimativa do escopo doprojeto (esforço,Custo, funcionalidade)


24

Cone da IncertezaCom controle de projetos efetivo o cone pode afinar

0,25x

0,5x

0,67x0,8x

1x1,25x

1,5x

2x

4x





Software completo



25

Cone da IncertezaComo o cone não afina sozinho, sem controle de projetos, as estimativas podem nunca convergir

0,25x

0,5x

0,67x0,8x

1x1,25x

1,5x

2x

4x





Software completo



26

Lições do Cone da Incerteza Devem ser tomadas decisões que diminuam a

variabilidade das estimativas, por exemplo: Definir os requisitos Definir o que não será feito Projetar a interface do usuário

Se o produto não estiver bem definido ou se for redefinido depois, o cone ficará mais aberto e a precisão da estimativa será menor.

Promessas somente podem ser feitas quando algumas decisões foram tomadas para o cone afinar


27

Lições do Cone da Incerteza Invista mais em gerência de projetos do que

em precisão de estimativa se: o desenvolvimento for caótico

Falta de def. de requisitos Falta de envolvimento do usuário Projeto mal feito Programação mal feita Equipe inexperiente Falta de planejamento Abandono dos planos sob pressão ...

os requisitos forem muito instáveis


28

Onde mais as estimativas erram?

Alguns requisitos são omitidos/esquecidos das estimativas, por exemplo: Funcionais:

Programa de instalação Conversor de dados Código para interface com outros sistemas Sistema de ajuda ao usuário

Não funcionais Interoperabilidade Portabilidade Reusabilidade Segurança usabilidade


29


Algumas atividades são omitidas/esquecidas das estimativas, por exemplo: Tarefas de coordenação e reuniões Instalação Criação de dados de teste Atendimento a pedidos de mudança Lidar com subcontratados Ajuste de performance Revisão de documentação técnica ...


30


Algumas atividades não relacionadas ao desenvolvimento são omitidas/esquecidas das estimativas, por exemplo:FériasFeriadosDoençaTreinamentosResolução de problemas de hardwareEncontros/confraternizações da empresa

Essas atividades devem ser mais

consideradas para projetos maiores


31


SubjetividadeExcesso de parâmetros subjetivos solicitados

pelos modelos de estimativas Estimativas informais (chutes)

Melhor não dar nenhuma estimativa informalE se o chefe insistir em uma estimativa na

hora???

O que influencia a estimativa de um software?


33

O que mais influencia na estimativa?

1. Tamanho do Software

2. Tipo de Software sendo desenvolvido

3. Fatores humanos

4. Linguagem de programação

5. Outros fatores


34

1-Tamanho do software O custo e esforço de um projeto são proporcionais ao

seu tamanho Não se pode estimar um software sem saber seu

tamanho Toda mudança no projeto deve ser contabilizada no

tamanho Métricas de tamanho:

Linhas de código (LOC) Pontos por função Pontos por caso de uso Quantidade de telas Quantidade de classes Quantidade de métodos por classe Média de Linhas de código por método


35

1-Tamanho do software

“Deseconomia” de escala Se o sistema A é 10 vezes maior que o sistema B,

isso não significa que o seu esforço será apenas 10 vezes maior que o de B.

Projetos maiores requerem coordenação de grupos maiores de pessoas, o que requer mais comunicação

O esforço do projeto aumenta exponencialmente com o tamanho do projeto por causa dos caminhos de comunicação


36

1-Tamanho do softwareCaminhos de comunicação entre pessoas


37

“Deseconomia” de escala para projetos típicos

Esforço(pessoas;mês)

Tamanho do projeto (LOC)

Crescimento típico

Crescimento linear

Fonte- Boehm, 2000


38

Como calcular “Deseconomia” de escala

Use ferramentas de estimativas para conhecer o impacto da deseconomia de escala

Se o projeto estimado for do mesmo tamanho dos anteriores, o novo pode ser estimado em função do primeiro


39

2-Tipo de Software

As taxas de produtividade variam muito em função do tipo de software.

Tipo de software 10KLOC 100KLOC 250KLOC

Aviação 100-1000 20-300 20-200

Sistemas de informação 800-18.000 200-7.000 100-5.000

Sistemas Web 600-10.000 100-2.000 100-1.500

Sistemas de tempo real 100-1.500 20-300 20-300

telecomunicações 200-3.000 50-600 40-500

LOC/Pessoa Mês (mín-máx)

Fonte: McConnell 2006


40

2-Tipo de Software

Como estimar levando isso em consideração?Usar modelos de estimativas como o

COCOMO II, que já incorpora esses ajustes;

Use dados históricos da sua empresa

Fonte: McConnell 2006

Proposto por Barry Boehm para estimativas


41

3-Fatores Humanos

De acordo com o modelo COCOMO II:

42%-29%

34%-24%

29%-19%

22%-19%

20%-16%

19%-15%

11%-14%

habilidade Análise de requisitos

habilidade programação

Rotatividade de pessoas

Experiência na aplicação (negócio)

Experiência na linguagem e ferramentas

Experiência na plataforma adotada

Coesão da equipe

Exemplo: pouca habilidade em análise de requisitos vai demandar

até 42% a mais de esforço no projeto

Melhor caso Pior caso


42

3-Fatores Humanos

Implicação:Não é possível estimar precisamente o

projeto sem conhecer quem vai trabalhar nele.


43

4-Linguagem de Programação

A experiência da equipe com a linguagem e ferramentas pode impactar em quase 40%

Algumas linguagens geram mais funcionalidade por linha que outras

Funcionalidade da ferramenta de apoio a programação (a escolha da linguagem determina a escolha da ferramenta)

Trabalhar com linguagens interpretadas tende a ser mais produtivo (fator 2).


44

5- Outros fatores que influenciam(Fatores do COCOMO)

Complexidade do produto Capacidade de análise de

requisitos Capacidade de programação Restrições de tempo Rotatividade de pessoal Desenvolvimento

descentralizado Confiabilidade requerida do

software Quantidade de documentação

requerida

Experiência da equipe no negócio

Uso de ferramentas de apoio Volatilidade da plataforma Restrições de

armazenamento Maturidade do processo Experiência com as

ferramentas Tamanho do banco de dados Resolução de riscos Desenvolvimento para

reutilização ...

Parte IITécnicas de Estimativas


46

Por que medir?

“Não se consegue controlar o que não se consegue medir". (Tom DeMarco)

“Medir é fundamental em qualquer disciplina da engenharia, e a engenharia de software não é uma exceção”. (Tom DeMarco)


47

Métricas de Software

Uso de métricas de software No Planejamento

Informações das medições de projetos anteriores poderão ser utilizadas na estimativa do novo projeto.

Durante o desenvolvimento Medições são coletadas e analisadas em relação às

estimativas propostas inicialmente

Ao término do desenvolvimento Medições são coletadas e analisadas (métricas do

produto) Taxa média de defeitos, custos, etc.


48

Planejamento Requisitos

AplicaçãoEntregue

ProjetoDetalhado

Estimativa

Inicial

Estimativas

Intermediárias

SoftwareImplantadoReal

Métricas x Estimativas


49

Métricas x Estimativas

100 PFs 120 PFs 130 PFs 135 PFs

Tela de entrada do código do estado alterada (3 PFs)

Acrescentada interface arquivo N&A (10 PFs)

Consulta N&A e ao código do estado acrescentadas (7 PFs)

• Nova tabela legal acrescentada (10 PFs)

• Relatório resumo incluído (5 PFs)

Impacto

EsforçoCronogramaCusto

+ 1 mês+ 2 semanas+ $5000

+ 0.5 meses+ 2 semanas+ $2500

+ 0.25 meses+ 2.5 dias+ $1250

Aplicativo Entregue

ProjetoDetalhado

ProjetoFuncionalRequisitos


50

Benefícios de manter métricas (dados históricos)

Principal: aumenta a precisão das estimativas Ajuste das influências no projeto Evita subjetividade e otimismo infundado

“produtividade não varia muito de projeto para projeto” (Putnam)

Evita que discussões políticas afetem a estimativa

métricasmétricas


51

Quais métricas coletar? Tamanho

Linhas de código, pontos por função, páginas web, tabelas de BD, classes, métodos

Esforço Pessoas/mês, pessoas/hora

Tempo Meses, dias, horas, semanas

Defeitos Defeitos em código, em documentação, em

especificação


52

Questões que influenciam métricas de tamanho:

Você conta todo o código fonte ou somente o código do produto final? (código de teste é contado?)

Como é contado o código reutilizado? Como é contado o código open-source? ...


53

Questões que influenciam o esforço Você conta tempo em horas, dias ou outra

unidade? Quantas horas por dia são contadas? 8 horas

ou somente as horas dedicadas ao projeto? Você conta feriados, treinamentos e férias? Você conta trabalho extra? Como se conta o tempo dividido em múltiplos

projetos? Como contar o tempo que se gasta trabalhando

em versões anteriores do mesmo software?


54

Questões de calendário

Quando o projeto inicia? Quando tem aprovação de orçamento? Ou quando começam as discussões sobre o mesmo?

Quando o projeto termina? Quando é entregue para o usuário?


55

Questões sobre métricas de defeitos

Você conta todos os pedidos de mudança como defeitos?

Múltiplas reclamações do mesmo defeito contam como um defeito ou vários?

Você contabiliza defeitos detectados pelos desenvolvedores ou somente os defeitos apresentados pelos testadores?

Você conta defeitos nos requisitos e projetos? São contados defeitos reportados pelo usuário


56

Lições sobre coleta de métricas

O gerente deve ter certeza que compreende o que está sendo coletado e que os dados coletados são consistentes

A coleta de dados deve ser feita periodicamente durante execução do projeto

Métricas do próprio projeto podem ser usadas para refinar as estimativas do restante do projeto ou de outros projetos

Se você não tem dados históricos, comece a coletar agora mesmo!


57

Exemplo de coleta

Projeto LOC Esforço

(pessoas mês)

$ (000) Pág. Doc.

Erros (antes da entrega)

Defeitos (depois da entrega)

Pessoas

Alfa 12.100 24 168 365 134 29 3

Beta 27.700 62 440 1.224 321 86 5

Gama 20.200 43 314 1.050 256 64 6

Principais técnicas de estimativas


59

Principais abordagens para estimar software

Julgamento individual de especialista Decomposição e recomposição Estimativa por analogia Estimativa Proxy-Based Julgamento em grupos


60

Julgamento de especialista

O que é? Mais comum forma de estimativa Não necessariamente é informal ou intuitivo

Quando? Pode ser usada do início ao fim do processo

Para que? Melhor usada em estimativa bottom-up

Por que? Quem tem mais experiência em uma atividade pode estimar

com mais precisão Como?

Deve ser solicitado o melhor e o pior caso da estimativa


61


O caso estimado pode ser calculado com fórmula PERT* Caso esperado = [Melhor caso + 4* caso_mais_provável) + pior caso] / 6

*Program Evaluation and Review Technique

Funcionalidade Melhor caso (dias)

Mais provável (dias)

Pior caso (dias)

Esperado (estimativa em dias)

Func. 1 1,25 1,5 2,0 1,54

Func. 2 1,5 1,75 2,5 1,83

... ... ... ... ...

Total 10,5 13,25 18,25 13,62


62


Importante: Compare seus resultados atuais com os

estimados para aperfeiçoar as estimativas individuais


63

Decomposição/Recomposição Decomposição: separar uma estimativa em

pedaços, estimar cada parte individualmente e depois recompor a estimativa

Também conhecida como bottom-up Estimar o esforço de um projeto inteiro é diferente

de estimar o esforço para cada funcionalidade do mesmo.

Quando se estima partes de um projeto, algumas estimativas erram para mais, outras para menos, e por isso em algum grau os erros são cancelados, melhorando a precisão da estimativa geral.


64

Exemplo de estimativa sem e com Decomposição

Funcio-nalidade

(Esforço)

Pessoas/Semana

Func 1 1.5

Func 2 4,5

Func 3 3

Func 4 1

Func 5 4

Func 6 6

Func 7 2

Func 8 1

Func 9 3

Func 10 1.5

Total 27

Esforço real

Erro

3 -1,5

2,5 2

1,5 1,5

2,5 -1,5

4,5 -0,5

4,5 1,5

3 -1,0

1,5 -0,5

2,5 0,5

3,5 -2,0

29 -2

Erro sem decomposição =24%, com decomp. = 7%

ProcurandoInformações sobreProjetos similares:Total de 22 pessoas/semana

Pedindo à equipePara estimar esforço para cada Funcionalidade:


65

Decomposição/Recomposição

O uso de estimativa por decomposição deve aumentar junto com o progresso do projeto No início: funcionalidades gerais Depois: requisitos detalhados Finalmente: atividades do desenvolvedor

Estruturar o projeto em atividades (processo) ajuda a estimar por decomposição (pode ser usada do início ao meio do projeto)

Cuidado com estimativas de melhor caso de desenvolvedores! Eles tendem a ser otimistas!


66

Estimativa por analogia

Comparar um projeto novo com outro anterior1. Obter detalhes sobre tamanho, esforço e custo,

juntamente com a decomposição de atividades2. Comparar o tamanho do novo parte a parte com o

antigo3. Construir a estimativa de tamanho do novo como

um percentual do antigo4. Estimar o esforço baseado no tamanho do novo,

que já foi comparado com o antigo5. Checar consistências


67

Exemplo de estimativa por analogia (Obtendo detalhes e comparando)

BD 5000LOC

Interface 14KLOC

Gráficos e relatórios

9KLOC

Classes 4,5kloc

Regras de negócio

11kloc

Total 43,5KLOC

Sistema ABD 10 tabelas

Interface 14 páginas web


10 gráficos + 8 relatórios

Classes 15

Regras de negócio

??

BD 14 tabelas

Interface 19 páginas web


14 gráficos + 16 relatórios

Classes 15

Regras de negócio

??

Sistema A

Sistema B (novo)

1

2comparando


68

Exemplo de estimativa por analogia (cont.)

Subsistema Tamanho do A

Fator de multiplicação

Tamanho estimado

do BBD 5KLOC 1,4 7kloc

Interface 14KLOC 1,4 19,6kloc


9KLOC 1,7 15,3kloc

Classes 4,5kloc 1,0 4,5kloc

Regras de negócio

11kloc 1,5 16,5kloc

Total 43,5KLOC - 62,9kloc

3


69


4esforço

Tamanho do projeto B (novo) 62,9KLOC

Tamanho do projeto A ÷ 43,5KLOC

razão =1,45

Esforço do A X 30 pessoas/mês

Esforço do B (novo) = 44 pessoas/mês

Calculando esforço do novo projeto


70


5checando A consistência da estimativa pode ser

influenciada por: Grande diferença de tamanho de um projeto para

outro Diferença de tecnologias (ex: proj A em C++ e

projeto B em Java) Diferenças grandes nos membros da equipe (para

projetos pequenos) e nas habilidades da equipe (para projetos grandes)

Diferença no tipo de aplicação (sistema de intranet versus sistema crítico embarcado)


71

Estimativa Proxy-Based

Usadas no início do processo (ou início de iterações)

Um bom estimador não faz estimativas precisas na parte mais ampla do cone da incerteza, mas precisa fazer alguma O cliente diz: “Como vou dizer se quero ou não

esse requisito se você não sabe me dizer quanto ele custa?”


72

Estimativa Proxy-Based São úteis para criar estimativas do projeto

como um todo ou de uma iteração completa.

Não servem para estimativas tarefa a tarefa ou por features (características) detalhadas

Consistem em identificar um proxy que esteja relacionado com o que se quer estimar e que seja mais fácil de estimar ou contar. Por exemplo, para estimar o número de casos

de teste, pode-se correlacionar com o número de requisitos.


73

Estimativa Proxy-BasedFuzzy Logic Para estimativa de projeto em LOC Cada feature (característica) é classificada em:

muito pequena, pequena, média, grande e muito grande.

Depende de dados históricos calibrados da organização

Dados históricos guardam quantas LOC em média uma feature de cada tipo precisa. Por exemplo:

Tamanho da feature

Média de LOC

No. De features

LOC estimado

Muito pequenas 127 22 2794


74

Estimativa Proxy-BasedFuzzy Logic Recomendações:

Todas as features devem ser classificadas precisamente

Os critérios para o tamanho da feature devem ser bem documentados e consistentes

Não deve ser usado para saber tamanho de cada feature, apenas uma média do total.

O método pode ser estendido para estimar esforço usando o mesmo raciocínio


75

Estimativa Proxy-BasedComponentes Padrão Útil para estimar tamanho quando se

desenvolve sistemas de arquitetura similar Como a estimativa é realizada:

São identificados elementos relevantes para contagem em sistemas anteriores.

Páginas web dinâmicas, páginas web estáticas, tabelas de BD, regras de negócio, gráficos, telas, diálogos, relatórios, etc.

Apenas a média de LOC para cada componente desse tipo é computada


76

Estimativa Proxy-BasedComponentes Padrão Exemplo de dados históricos:

Componentes padrão

Média de LOC por componente

Páginas web dinâmicas

487

Páginas web estáticas 58

Tabelas de banco de dados

2437

Regras de negócio 8327


77

Estimativa Proxy-BasedComponentes Padrão Exemplo de Estimativa:

Componente

padrão

LOC médio por

componente

Mínimo possível

Mais provável

Máximo possível

Número estimado

LOC estimado

Página web

dinâmica

487 11 25 50 26,8 13052

Pág. Web estática

58 20 35 40 33,3 1931

Tabelas de BD

2437 12 15 20 15,3 37286

Relatórios 288 8 12 20 12,7 3658

Regras de negócio

8327 - 1 - 1 8327

Total - 64254

Uso da fórmula PERT

Caso esperado = [Melhor caso + 4*

caso_mais_provável) + pior caso] / 6


78

Estimativa Proxy BasedStory Points Pode ser usada para estimar a cada iteração Para cada story (feature ou requisito) é dado

um valor que represente seu tamanho (1, 2, 4, 8, 16) – apenas uma escala

Após iteração 1:27 story points desenvolvidos

12 pessoas/semana de esforço já realizado

3 semanas se passaram

Calibragem:

Esforço = 27 sp ÷ 12 pessoas/sem. = 2,25 story points/ pessoa_semana

Cronograma = 27 ÷ 3(semanas) = 9 story points/semana

Story 1 2

Story 2 1

Story 3 4


79

Estimativa Proxy BasedStory Points

Fazendo estimativa preliminar do projeto baseado na iteração 1 e sabendo que o projeto/próxima iteração tem 180 story points:

Esforço = 180 sp ÷ 2,25story_points/pessoas_sem. = 80 pessoas_semana

Cronograma = 180 ÷ 9 story points/semana = 20 semanas


80

Estimativa Proxy BasedTamanho de camiseta (T-Shirt sizing) Usado para decidir quais features serão contratadas no

início do projeto Os desenvolvedores classificam o tamanho das features

necessárias como P, M, G, XG. Em paralelo, o cliente classifica o valor daquela feature

usando a mesma escala.

feature Valor para o negócio/cliente

Custo de desenvolvimento

Feature 1 G P

Feature 2 P G

Feature 3 G G

Permite que o cliente decida não contratar

feature 2


81

Julgamento em grupos

Técnica usada no início do projeto Dois tipos

Revisões de grupo (não estruturada)Wideband Delphi (estruturada)


82

Julgamento em gruposRevisões de Grupo

Cada membro do grupo estima separadamente partes do projeto

O grupo se reúne para discutir as estimativas, não somente para calcular sua média

Deve-se chegar a um consenso aceito pelo grupo todo

Dicas: 3 a 5 especialistas é suficiente Cada especialista deve ter formação ou cargo diferentes

ou usar diferentes técnicas de estimativa


83

Julgamento em gruposWideband Delphi (estruturado)

1. O coordenador apresenta a cada integrante a especificação do software e um formulário de estimativa

2. Estimadores preparam suas estimativas separadamente3. As estimativas são discutidas em uma reunião4. Estimadores entregam suas estimativas anônimas para o

coordenador5. O coordenador resume as estimativas

0 5 10 15 20

x x xxx x

média


84


Exemplo de Resumo


85


6. O coordenador pede que os estimadores discutam as diferenças

7. Estimadores votam anonimamente sobre aceitar ou não a média(se alguém disser não, voltar para passo 3)

8. A estimativa final é o caso esperado ou um intervalo a partir da discussão


86


Dicas:Não é útil para atividades detalhadasÉ útil para estimar trabalhos em áreas novas,

novas tecnologias ou novos tipos de softwareÉ útil na parte mais larga do cone da

incerteza

0,25x

0,5x

0,67x

0,8x

1x

1,25x

1,5x

2x

4x





Software completo

O processo de Estimativa de Software


88

Coletar requisitosiniciais

Estimar tamanho

Estimar esforço

Produzir o cronograma

Estimar os custos

Aprovarestimativas

Desenvolver oproduto

Re-estimar quando

necessário

Estimativasaprovadas

Tamanho, esforço, etc.

atuais

Analisar o processo de

estimativa

Custos atuais

Recursos disponíveis

Dadoshistóricos

Processo de Estimativa de

Software

Estimativa de tamanho

Linhas de código (LOC)Pontos por funçãoPontos por caso de uso...


90

Medidas de tamanho Requisitos Use Cases Pontos por função Páginas web Componentes de interface (janelas, formulários,

relatórios,...) Tabelas de BD Classes Funções/Métodos Linhas de código (LOC)


91

Linhas de Código (LOC)

Vantagens LOC é um item de todos os artefatos e projetos de

software Pode ser facilmente contado Muitos dados históricos já existem em LOC em várias

empresas Permite comparação entre projetos A maioria das ferramentas de estimativas se baseia

em LOC


92

Linhas de Código (LOC) Desvantagens:

Dependência da linguagem de programação adotada Dificuldades de utilização em atribuição de tarefa individual pois

produtividade é diferente entre pessoas Projetos que requerem maior complexidade podem ter a

precisão da estimativa prejudicada. Não parece natural contar LOC para estimar atividades de

requisitos, projeto e outras que ocorrem antes da implementação Projetos que utilizam várias linguagens são prejudicados

Por exemplo: como medir projetos envolvendo SQL e Java? Seu uso na estimativa requer detalhes que são difíceis de se

alcançar Isto é, o planejamento deve estimar o LOC a ser produzido muito

antes que a análise e projeto tenham sido completados


93

Linhas de Código (LOC)

Problema: qual o critério para medir? Empresa deve definir critério consistente

public static void main(String [] args) { try { ident_usuario = desenho.login(i, p, u); } /* endtry */ catch(Exception e) { e.printStackTrace(); } /* endcatch */ }}

public static void main(String [] args) {try {ident_usuario = desenho.login(i, p, u);}catch(Exception e) {e.printStackTrace(); }}}


94

Pontos por Função Métrica orientada a função

Medida do tamanho do software através da quantificação da funcionalidade oferecida aos usuários

Somente componentes solicitados e visíveis ao usuário são considerados para dimensionar a aplicação

Baseado nas informações do projeto de alto nível do sistema

Independente da tecnologia utilizada para implementação


95

Pontos por Função

Pergunta:Uma aplicação desenvolvida em C++

utilizando análise e projeto estruturado foi dimensionada em 1300 PF. Quantos PF terá a mesma aplicação desenvolvida em VB 6.0 com banco de dados Oracle e utilizando processo unificado? Por que?


96

Ponto por Caso de Uso

É uma métrica orientada a função tambémBase na constatação: medida com PF exige

expertsEm sistemas orientados a objetos os casos

de uso são a base do processo e são definidos desde o início do processo

Usuário

Efetuapagamento

Pagto comCartão de crédito

Pagto comDébito em Conta

Estimativa de esforço


98

Como calcular o esforço? Saiba:

a Produtividade esperada Como?

Tabela de produtividade padrão (ver tabela) Dados históricos

Em que formato? HH/PF (homem_hora/ponto por função) HH/KLOC (homem_hora/ linhas de código) Obs: o denominador deve ser o mesmo usado para medir o tamanho.

o tamanho do projeto (em PF ou KLOC ou outro) quantas horas por dia devem ser contadas (se o esforço for

estimado em dias Fórmula:

Esforço (homem/hora) = produtividade da equipe * Tamanho


99

Tabela de Produtividade


100

Exemplo de cálculo de esforço

Supondo:Tamanho = 87 pontos por funçãoprodutividade baixa (13,2HH/PF)

Esforço (HH) = 87 * 13,2 = 1149 pessoas_horas

Esforço(HD) = 87 * 13,2 /8 = 143 homens_dias

Estimativa de Prazo


102

Método para Estimativa de Prazo

- Estimativa de Esforço

- Tamanho da Equipe

- Consideração: 6 horas de trabalho/ dia

Prazo (em dias) = Esforço (horas) /(Tam. equipe * 6)


103

• Equipe: 1 analista e 1 programador (2 profissionais)• horas por dia: 6 horas /dia

Prazo = 1149 /(2 * 6) = 96 dias úteis (aproximadamente 4,4 meses)

(Considerando 22 dias úteis por mês)

Exemplo: sistema com 87 pontos por funçãoCom esforço calculado de 1149 HH

Exemplo de Estimativa de Prazo


104

Evitando a Região Impossível

Cus

to d

o E

sfor

ço

Tem po de D esenvolvim ento

Td To

Região Im possível(75% de Td)

Observações:1) Td é o tempo ótimo de desenvolvimento.2) To é o tempo que acarreta o menor custo.3) To = 2 Td.4) É impossível terminar em menos que 0,75 * Td.


105

Estimando Prazos e Recursos a partir do VolumeUsando a Aproximação de Capers Jones

Onde:1) Td é o tempo ótimo de desenvolvimento, em meses.

2) V é o volume em Pontos de Função.

3) t é um expoente que depende do ambiente computacional considerado.

Td (meses) = V ** t,


106

Ambiente Expoente tSistema Comum 0,32-0,35Sistema Orientado a Objeto 0,36Sistema Cliente/Servidor 0,37Sistema Terceirizado 0,38Sistema de Informações Gerenciais 0,39Programa Produto Comercial 0,40Programa de Sistema Operacional 0,41Software Militar 0,43-0,45

Estimando Prazos partir do VolumeUsando a Aproximação de Capers Jones

Td (meses) = V ** t, 4,2 mesesRegião Impossível: 0 - 3,1 meses

87

Estimativa dos custos


108

Exemplo de estimativa de custosfixo Calc. automático


109

Decomposição do Ponto por função por atividade do ciclo de vida – esforço (fonte: Serpro)*

*( Publicado em Vazquez et al, 2003)

Subprocessos % de distribuição

Análise de requisitos

20%

Análise e projeto 30%

Implementação e teste

40%

Disponibilização 10%

Atividades % de distribuição

Levantamento de dados

10%

Projeto lógico 20%

Projeto físico 25%

Construção e testes

35%

implantação 10%

Obs: pode servir para efeito de remuneração de sub-contratação


110

Exemplo de estimativa de custos

Parte IIIDetalhamentoPontos por função e pontos por caso de uso

Estimativa de TamanhoAnálise de Pontos por função

Estimativa de TamanhoAnálise de Pontos por função


113

Pontos por função É uma medida de dimensionamento de

software através da funcionalidade implementada em um sistema, sob o ponto de vista do usuário.

Uma Visão do Usuário representa uma descrição formal das necessidades do negócio do usuário na linguagem do usuário.

Proposto por (Albrecht 1979)


114

Objetivos da APF

Medir o software através da quantificação da funcionalidade solicitada e adquirida pelo cliente, tendo como base primária o projeto lógico

Medir o desenvolvimento e manutenção de software independentemente da tecnologia utilizada na implementação

Medir o desenvolvimento e manutenção de software consistentemente em todos os projetos e organizações


115

Paradoxo clássico de produtividade

Linhas de Código 10.000 3.000

Pontos de Função 25 25

Esforço Total (meses) 25 15

Custo Total $125.000 $75.000

Custo por Linha de Código $12,50 $25,00

Linhas por Pessoa-mês 400 200

PFs por Pessoa-mês 1,2 2

Custo por PF $5.000 $3.000


116

Análise de PF Requisitos da aplicação são examinados para

determinar a quantidade e complexidade das entradas, saídas, cálculos e bancos de dados necessários (características do sw)

A partir de uma tabela de valores pré-definida, pontos são determinados para os valores das características do software.

Telas

Relatórios

Arquivos Mestres Tamanho

Arquivos de Referência

Sinais

Arquivos de Controle


117

Visão Geral de APF

APLICAÇÃO

Arquivos Lógicos Internos

Fronteira da AplicaçãoFronteira da Aplicação

Entradas Externas

Saídas Externas

ConsultasExternas

Outra Aplicação

Arquivo Lógico Interno

Arquivos de InterfaceExterna

Funções de dadosFunções de dados

Funções transacionaisFunções transacionais

(Sem Dados Derivados) ( Com Dados Derivados)


118

DeterminarTipo de

Contagem

Identificar Escopo de

Contagem eFronteira da

Aplicação

Contar Funçõesde Dados

Contar Funções

Transacionais

Determinaros PF NãoAjustados

Determinaro Fator de

Ajuste

Calcular os PF

Ajustados

Contagem de PFContagem de PF


119

TIPOS DE CÁLCULO DE TIPOS DE CÁLCULO DE PONTOS DE FUNÇÃOPONTOS DE FUNÇÃO

• Contagem de PF de Projetos de Desenvolvimento - PF associados com a instalação inicial de um software novo

• Contagem de PF de Projetos de Manutenção - PF associados com a melhoria de um software já existente (inclui funcionalidade que é adicionada, modificada ou excluída)

• Contagem de PF de Aplicações - PF associados com uma aplicação instalada - Funcionalidade da aplicação no ponto de vista do usuário

DeterminarTipo de

Contagem



120

Contagem daAplicação

Inicializar

Atualizar

Contagem Estimada

Contagem Estimada

Contagem Final

Contagem Final

ProjetoCompleto

ProjetoCompleto

Projeto de Desenvolvimento

Projeto A Projeto A

Projeto de Desenvolvimento

Projeto de Manutenção

Projeto de Manutenção

Projeto B Projeto B

TIPOS DE CÁLCULO DE TIPOS DE CÁLCULO DE PONTOS DE FUNÇÃOPONTOS DE FUNÇÃO

DeterminarTipo de

Contagem



121



Aplicação

A fronteira da aplicação indica o limite entre o software sendo medido e o usuário.

Define o que é externo para a aplicação É a interface conceitual entre a aplicação

“Interna” e o mundo do usuário “externo” Ponto de vista do usuário Baseada na funcionalidade do negócio,

Não na implementação tecnológica



122

Outras Aplicações

APLICAÇÃO



Aplicação

Usuário



123

Funções de Dados

Arquivos LógicosInternos

Arquivos deInterface Externa




124


Representam a funcionalidade fornecida para o usuário relativa aos requisitos de dados Internos (Arquivos Lógicos Internos) e Externos (Arquivos de Interface Externa) a Aplicação.

Arquivo refere-se a um grupo de dados logicamente relacionados e não na implementação física deste grupo de dados.

Funções de Dados



125



São grupos de dados ou informações de controle especificados pelo usuário logicamente relacionados,cuja manutenção é efetuada dentro da fronteira da aplicação.

Armazenar dados mantidos através de um ou mais processos elementares da aplicação sendo contada.



126




Exemplos: Tabelas que armazenam dados mantidos pela aplicação;

Arquivos de configuração mantidos pela aplicação;

Arquivos de segurança de acesso (senha) mantidos pela aplicação;

Arquivos de help, desde que mantidos pela aplicação;

Arquivos de mensagens de erro mantidos pela aplicação;

Dados de Histórico mantidos separadamente dentro da aplicação;


127




Não Exemplo: Arquivos Temporários ou várias Interações do mesmo arquivo Arquivos de Trabalho Arquivos de Sort (Classificação) Arquivos de View Arquivos de Índices Arquivos introduzidos devido a tecnologia Dados de Backup mantidos para Backup corporativo Arquivos mantidos por outra aplicação e somente referenciados Arquivos de relacionamentos, a menos que contenham atributos

próprios mantidos separadamente


128

Arquivos de Interface Externa


São grupos de dados ou informações de controle especificados pelo usuário logicamente relacionados, cujamanutenção é efetuada dentro da fronteira de outra aplicação

Armazenar dados referenciados através de um ou mais processos elementares da aplicação sendo contada.



129




AIE - Exemplo:

Dados de referência externa utilizados pela aplicação;

Arquivos de help mantidos fora da aplicação;

Arquivos de mensagens de erro mantidos fora da aplicação;

Dados de password mantidos fora da aplicação


130




AIE – Não Exemplo:

Arquivos de movimento recebidos de outra aplicação para manter um ALI.

Dados mantidos pela aplicação e utilizados por outra aplicação

Dados formatados e processados para uso de outras aplicações


131

Classificação das Funções - de acordo com o número de Registros Lógicos e Itens de Dados:

Simples Média Complexa

Classificação das Funções - de acordo com o número de Registros Lógicos e Itens de Dados:





132

TABELA DE COMPLEXIDADETABELA DE COMPLEXIDADEContar Funçõesde Dados



133

SIMPLES MÉDIO COMPLEXO

7 PF 10 PF 15 PF

PONTUAÇÃO DOS ARQUIVOS LÓGICOS INTERNOS


5 PF 7 PF 10 PF

PONTUAÇÃO DOS ARQUIVOS DE INTERFACE EXTERNA

Pontuação das Funções de Dados




134

Contar Funções

Transacionais

Funções Transacionais

SaídaExterna

EntradaExterna

ConsultaExterna



135

Contagem de PFContagem de PFContar Funções

Transacionais

Uma Entrada Externa é um processo elementar que processa dados ou informações de controle que vem do lado de fora da fronteira da aplicação.

Manter um ou mais Arquivos Lógicos Internos e/ou alterar o comportamento do sistema.

Entradas Externas


136


Transacionais Entradas Externas

EE - Exemplo: Transações que recebem dados externos

para manutenção de ALI; Janela que permite adicionar, excluir e

alterar registros em ALI. Nesse caso são três EE’s.

Processamento em lotes de atualização de base cadastrais a partir de arquivos de movimento.


137


Transacionais Entradas Externas

EE – Não Exemplo:

Tela de filtro de relatórios e consultas; Menus; Telas de Login.


138


Contar Funções

Transacionais

Saídas Externas

Uma Saída Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação.

Apresentar informação para um usuário através de processamento lógico adicional a recuperação de dados ou informação de controle. O processamento lógico deve conter no mínimo uma fórmula matemática ou cálculo, ou criar dados derivados.


139


Contar Funções

Transacionais

Saídas Externas

SE - Exemplo:

Relatórios com totalizações;

Relatórios que também atualizam arquivos

Consultas com apresentação de cálculos ou dados derivados

Arquivo de movimento gerados para outra aplicação.

Informações Gráficas.


140


Contar Funções

Transacionais

Saídas Externas

SE – Não Exemplo:

Telas de help;

Consultas e relatórios sem totalizações e que não atualizam arquivos.


141

Contar Funções

Transacionais Saídas Externas

Uma Saída Externa PODE também manter um ou mais Arquivos Lógicos Internos e/ou alterar o comportamento do sistema.



142


Contar Funções

TransacionaisConsultas Externas

Consulta Externa é um processo elementar que envia dados ou informação de controle para fora da fronteira da aplicação.

Apresentar informação para o usuário através da recuperação de dados ou informação de controle de um ALI ou AIE. O processamento Lógico NÃO contém fórmulas matemáticas ou cálculos, NÃO cria dados derivados. Além disso, NÃO mantém Arquivos Lógicos Internos durante o processamento, nem altera o comportamento do sistema.


143


Contar Funções

TransacionaisConsultas Externas

CE - Exemplo: Telas de help; Telas de logon; Menu gerado dinamicamente com base em

configuração da aplicação.

CE – Não Exemplo: Menus estáticos; Relatórios e consultas com totalizações ou dados

derivados.


144

Classificação das Funções - de acordo com o número Arquivos Referenciados e Itens de Dados:


Classificação das Funções - de acordo com o número Arquivos Referenciados e Itens de Dados:


Contar Funções

Transacionais



145

FALE CONOSCO http://www.stn.fazenda.gov.br

Contar Funções

Transacionais

EXEMPLO:ENTRADA EXTERNA



146

http://www.stn.fazenda.gov.br

Contar Funções

Transacionais

EXEMPLO:CONSULTA EXTERNA



147


Contar Funções

Transacionais

EXEMPLO:SAÍDA EXTERNA



148



Contar Funções

Transacionais

EXEMPLO:CONSULTA EXTERNA

SAÍDA EXTERNA


149

1 a 4 5 a 15 16 ou maisitens de dados itens de dados itens de dadosreferenciados referenciados referenciados

1arquivo SIMPLE

SSIMPLES MÉDIA

referenciado

2arquivos SIMPLE

SMÉDIA

COMPLEXAreferenciados

3 ou maisarquivos MÉDI

ACOMPLEXA COMPLEXA

referenciados

TABELA DE COMPLEXIDADETABELA DE COMPLEXIDADE

Entradas ExternasContar Funções

Transacionais



150


Saídas ExternasContar Funções

Transacionais

TABELA DE COMPLEXIDADETABELA DE COMPLEXIDADE1 a 5 6 a 19 20 ou mais

itens de dados itens de dados itens de dadosreferenciados referenciados referenciados

1arquivo SIMPLES SIMPLES MÉDIA

referenciado

2 ou 3arquivos SIMPLES MÉDIA COMPLEXA

referenciados

4 ou maisarquivos MÉDIA COMPLEXA COMPLEXA

referenciados


151


Consultas Externas

Contar Funções

Transacionais

TABELA DE COMPLEXIDADETABELA DE COMPLEXIDADE1 a 5 6 a 19 20 ou mais

itens de dados itens de dados itens de dadosreferenciados referenciados referenciados

1arquivo SIMPLES SIMPLES MÉDIA

referenciado

2 ou 3arquivos SIMPLES MÉDIA COMPLEXA

referenciados

4 ou maisarquivos MÉDIA COMPLEXA COMPLEXA

referenciados


152


Contar Funções

Transacionais


3 PF 4 PF 6 PF


4 PF 5 PF 7 PF


3 PF 4 PF 6 PF

Pontuação das Funções Transacionais


153

Determinaros PF NãoAjustados


TIPO DE COMPLEXIDADE TOTAL TOTALFUNÇÃO FUNCIONAL COMPLEX. TIPO FUNÇÃO

SIMPLES X 7 =ARQUIVOLÓGICOINTERNO

MÉDIA X 10 = COMPLEXA X 15 =

SIMPLES X 5 =ARQUIVO DEINTERFACEEXTERNA


SIMPLES X 3 =ENTRADAEXTERNA MÉDIA X 4 =

COMPLEXA X 6 =

SIMPLES X 4 =SAÍDAEXTERNA MÉDIA X 5 =

COMPLEXA X 7 =

SIMPLES X 3 =CONSULTAEXTERNA


* * * TOTAL DE PONTOS DE FUNÇÃO NÃO - AJUSTADOS =

Tabela de Cálculo


154

Contagem de PFContagem de PFDeterminaro Fator de

Ajuste

Atribui-se um peso de 0 a 5 para cada característica: 0- Nenhuma Influência 3- Influência Média

1- Influência Mínima 4- Influência Significativa

2- Influência Moderada 5- Grande Influência

1. Comunicação de Dados 2. Processamento Distribuído 3. Performance 4. Utilização do Equipamento 5. Volume de Transações 6. Entrada de dados “on-line” 7. Eficiência do Usuário Final

8. Atualização “on-line” 9. Processamento Complexo 10. Reutilização de Código 11. Facilidade de Implantação 12. Facilidade Operacional 13. Múltiplos Locais 14. Facilidade de Mudanças

Características Gerais dos Sistemas


155

0 - O processamento da aplicação é puramente batch ou executado em um PC isolado.

1 - A aplicação é batch mas tem entrada de dados remota OU impressão remota.

2 - A aplicação é batch mas tem entrada de dados remota E impressão remota.

3 - Captura de Dados on-line via terminal de vídeo ou via um processador front-end , para alimentar processos batch ou Sistemas de Consultas

4 - Mais de um front-end, mas a aplicação suporta apenas um tipo de protocolo de comunicação.

5 - Mais de um front-end, mas a aplicação suporta mais de um tipo de protocolo de comunicação.

Comunicação de DadosComunicação de Dados


156

0 - A aplicação não efetua na transferência de dados ou processamento entre as CPUs da instalação.

1 - A aplicação prepara dados para o usuário final processar em outra CPU da instalação utilizando-se de software genérico (planilhas, editores de texto, banco de dados)

2 - Os dados são preparados para transferência, transferidos e processados em uma outra CPU da instalação. (Transferência de Arquivos)

3 - Processamento distribuído e transferência de dados on-line apenas em uma direção. (Processa numa CPU e transfere para outra CPU)

4 - Processamento distribuído e transferência de dados on-line em ambas direções.(Processamento cooperativo)

5 - A aplicação decide dinamicamente qual a CPU mais apropriada para executar a função.

Processamento DistribuídoProcessamento Distribuído


157

Atualização de Dados On-LineAtualização de Dados On-Line

0 - Nenhuma atualização. 1 - Atualização on-line de 1 a 3 Arquivos de Controle. O volume de

atualizações é baixo, e a recuperação de dados é fácil. 2 - Atualização on-line de 4 ou mais arquivos de controle. O volume de

atualizações é baixo , e a recuperação de dados é fácil. 3 - Atualização on-line da maioria dos Arquivos Lógico Internos. 4 - Além dos itens anteriores, a proteção contra perda de dados é

essencial, e foi especificamente projetada e codificada no sistema. 5 - Além dos itens anteriores, altos volumes de dados trazem

considerações sobre custo para o processo de recuperação. Exigem procedimentos de recuperação totalmente automatizados, com a mínima intervenção do operador


158

0 - Todas as transações são processadas em batch.

1 - 1% a 7% das transações são entradas dados interativas.

2 - 8% a 15% das transações são entradas de dados interativas.

3 - 16% a 23 % das transações são entradas de dados interativas.

4 - 24% a 30% das transações são entradas de dados interativas.

5 - Mais de 30% das transações são entradas de dados interativas

Entrada de Dados On-LineEntrada de Dados On-Line


159

0 - Nenhum período de pico de transações é esperado. 1 - Picos de transações mensais, quadrimestrais, sazonais e anuais

são esperados. 2 - Picos semanais de transações são esperados. 3 - Picos diários de transações são esperados. 4 - Altos volumes de transações foram fixados pelo usuário para a

aplicação, o que força a execução de tarefas de análise de performance na fase de projeto da aplicação.

5 - Além das considerações acima, requer o uso de ferramentas de análise de performance nas fases de projeto, desenvolvimento e/ou implantação.

Volume de TransaçõesVolume de Transações


160

As funções “on-line” fornecidas enfatizam um projeto da aplicação voltado para a eficiência do usuário. Incluindo o seguinte:

Navegação por Menus Documentação e/ou Help On-line Movimento automático do cursor Movimento da Tela (Scroll) vertical e horizontal Impressão remota (via transações on-line) Teclas de Função pré-definidas Seleção de dados na tela via movimentação do cursor

Eficiência do Usuário FinalEficiência do Usuário Final


161

Submissão de jobs para execução em batch a partir de transações on-line

Uso intensivo de vídeo reverso, brilho intensificado, sublinhado, cores e outros recursos de vídeo

Cópia física da documentação do usuário de transações on-line Interface para mouse Pop-up Windows O mínimo possível de telas para executar as funções do negócio Fácil navegação entre telas (por ex:,através de teclas de função) Suporte bilíngüe Suporte multilinge



162


0 - A aplicação não apresenta nenhum dos itens acima.

1 - Apresenta de 1 a 3 dos itens acima.

2 - Apresenta de 4 a 5 dos itens acima.

3 - Apresenta 6 ou mais itens acima, mas não há nenhum requerimento do usuário relacionado à eficiência.

4 - Apresenta 6 ou mais itens acima, e os requerimentos estabelecidos para eficiência do usuário são rigorosos o suficiente para que a fase de projeto da aplicação inclua fatores para minimizar a digitação, maximizar uso de defaults, templates etc.

5 - Apresenta 6 ou mais itens acima, e os requerimentos estabelecidos para eficiência do usuário são rigorosos o suficiente para que seja necessário o uso de ferramentas e processos especiais para demostrar que os objetivos de eficiência foram alcançados.


163

O processamento complexo é uma característica da aplicação, podendo ser dividido nas seguintes categorias: Processamento especial de auditoria e/ou

processamento especial de segurança. Processamento lógico extensivo. Processamento matemático extensivo. Grande quantidade de processamento de exceções,

resultando em transações incompletas que necessitam de reprocessamento, por exemplo, transações ATM incompletas causadas por interrupções de comunicação, valores de dados perdidos ou falha de edição.

Processamento complexo para manipular múltiplas possibilidades de entrada/saída, por exemplo, multimidia e independência de dispositivos.

Processamento ComplexoProcessamento Complexo


164

Processamento ComplexoProcessamento Complexo

Classificar o Nível de Influência de acordo com a tabela abaixo:

0 - Não apresenta nenhum dos itens acima. 1 - Apresenta um dos itens acima. 2 - Apresenta dois dos itens acima. 3 - Apresenta três dos itens acima. 4 - Apresenta quatro dos itens acima. 5 - Apresenta todos dos itens acima.


165

Facilidade de ImplantaçãoFacilidade de Implantação

0 - Nenhuma consideração especial foi feita pelo usuário, e nenhum procedimento especial foi requerido para a implantação.

1 - Nenhuma consideração especial foi feita pelo usuário, mas um procedimento especial foi requerido para a implantação.

2 - Requerimentos de implantação e conversão de dados foram fixados pelo usuário, e roteiros de implantação e conversão de dados foram preparados e testados. O impacto da conversão de dados no projeto não é considerado importante.

3 - Requerimentos de implantação e conversão de dados foram fixados pelo usuário, e roteiros de implantação e conversão de dados foram preparados e testados. O impacto da conversão da dados no projeto é considerado importante.

4 - Além do descrito no item (2), ferramentas automatizadas de implantação e conversão de dados foram fornecidas e testadas.

5 - Além do descrito no item (3), ferramentas automatizadas de implantação e conversão de dados foram fornecidas e testadas


166

Múltiplos LocaisMúltiplos Locais

0 - Nenhuma solicitação do usuário para considerar a necessidade de instalar a aplicação em mais de um local.

1 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar somente em ambientes idênticos de hardware e software.

2 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar somente em ambientes similares de hardware e software.

3 - Necessidade de instalação em múltiplos locais foi levada em consideração no projeto de sistema, e a aplicação foi projetada para operar inclusive em ambientes diferentes de hardware e/ou software.

4 - Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos locais, e a aplicação atende aos itens (1) e (2).

5 - Um plano de documentação e manutenção foi elaborado e testado para suportar a aplicação em múltiplos locais, e a aplicação atende ao item (3).


167

0 - Nenhum requerimento especial foi solicitado pelo usuário para projetar a aplicação, visando minimizar ou facilitar mudanças.

1-5 - Selecionar quais dos seguintes itens se aplicam à aplicação. É fornecido recurso de consulta/relatórios flexível capaz de manipular

solicitações simples de consulta (contar como um item). É fornecido recurso de consulta/relatórios flexível capaz de manipular

solicitações de consulta média complexidade (contar como dois itens). É fornecido recurso de consulta/relatórios flexível capaz de manipular

solicitações complexas de consulta (contar como três itens). Dados de controle são mantidos em tabelas que são atualizadas pelo

usuário através de processos on-line e interativos, mas as alterações só são efetivadas no próximo dia útil.

Dados de controle são mantidos em tabelas que podem ser atualizadas pelo usuário através de processos on-line e interativos, e as alterações só são efetivadas imediatamente (contar como dois itens).

Facilidade de MudançasFacilidade de Mudanças


168

Facilidade OperacionalFacilidade Operacional0 - Nenhuma consideração especial sobre facilidade operacional, além

dos procedimentos normais de backup, foi feita pelo usuário.

1 - 4 - Selecionar os seguintes itens que se aplicam à aplicação. Cada item selecionado possui o valor um. Procedimentos eficientes de inicialização, backup e recuperação

foram preparados, mas a intervenção do operador é necessária. Procedimentos eficientes de inicialização, backup e recuperação

foram preparados, mas nenhuma intervenção do operador é necessária (contar como dois itens).

A aplicação minimiza a operação de montagem de fitas magnéticas

A aplicação minimiza a necessidade de manuseio de formulários.

5 - A aplicação foi projetada para não precisar de intervenção do operador no seu funcionamento normal. Apenas a inicialização e parada do sistema ficam a cargo do operador. A recuperação automática de erros é uma característica da aplicação.


169

PerformancePerformance0 - Nenhuma exigência especial de performance foi fixada pelo usuário.

1 - Requerimentos de performance foram estabelecidos e revisados, mas nenhuma ação especial foi necessária.

2 - O tempo de resposta é crítico durante as horas de pico. Nenhuma consideração especial para utilização de CPU foi requerida.O intervalo de tempo limite do processamento é sempre p/ o próximo dia útil.

3 - O tempo de resposta é crítico durante todo o horário de utilização . Não foi necessário nenhum procedimento especial para utilização de CPU. Os requerimentos de prazo de processamento com outros sistemas são limitantes.

4 - Os requerimentos de performance estabelecidos pelo usuário são rigorosos o bastante para requerer tarefas de análise de performance na fase de análise e desenho da aplicação.

5 - Além do descrito no item 4, ferramentas de análise de performance foram usadas nas fases de desenho, desenvolvimento e/ou implementação a fim de proporcionar a performance estabelecida pelo usuário.


170

0 - Não há restrições operacionais explícitas ou implícitas. 1 - Existem restrições operacionais, mas são menos

restritivas do que aplicações típicas. Nenhum esforço extra é necessário para suplantar as restrições.

2 - Algumas considerações sobre tempo e segurança são necessárias.

3 - Necessidades especiais de processador para uma parte específica da aplicação.

4 - Restrições operacionais estabelecidas requerem atenção especial a nível de processador central ou processador dedicado para executar a aplicação.

5 - Além do descrito acima, existem sobrecargas a nível das unidades de processamento (CPUs) distribuídas da instalação.

Utilização do EquipamentoUtilização do Equipamento


171

0 - Não apresenta código reutilizável. 1 - O código reutilizável é usado somente dentro da

própria aplicação. 2 - Menos de 10% da aplicação foi feita, levando-se em

conta a sua utilização por outras aplicações. 3 - 10% ou mais da aplicação foi feita, levando-se em

conta a sua utilização por outras aplicações. 4 - A aplicação foi projetada e documentada para

facilitar a reutilização de código, e a aplicação é customizada pelo usuário a nível de código fonte.

5 - A aplicação foi projetada e documentada para facilitar a reutilização de código. Sua customização (parâmetros ) pode ser atualizada pelo usuário.

Reutilização de CódigoReutilização de Código


172

FA = ( NIT * 0,01 ) + 0,65

Nível de Influência Total (NIT) Nível de Influência Total (NIT)

FATOR DE AJUSTE (FA) FATOR DE AJUSTE (FA)

NIT = NI Características Gerais do Sistema


Determinaro Fator de

Ajuste

Cálculo do Fator de Ajuste


173


Calcular os PF

Ajustados

- Cálculo de PF de um Projeto de Manutenção

PF_MANUTENÇÃO = ((PF_INCLUÍDO + PF_ALTERADO)* FA_ATUAL) + (PF_EXCLUÍDO*FA_ANTERIOR)

- Cálculo de PF de um Projeto de Desenvolvimento

PF_DESENVOLVIMENTO = PF_NÃO_AJUSTADO * FATOR_AJUSTE

Cálculo de PFs Ajustados


174

Exemplo

TrabalhadorGerente

Efetuar Logon

Acompanhar Presença

Registrar Presença Emitir Relatório

de Presença

Registrar Justificativa

<<extend>>


175

Exemplo Ponto

DataHorário de EntradaHorário de Saída

Pessoa

SenhaNomeTipo

0..n

1

0..n

1

Justificativa

DataJustificativa

0..n11

0..n

Ponto

matriculadatahorario entradahorario saidaPessoa

matriculanomesenhatipo

0..n

1

0..n

1

Justificativa

matriculadatajustificativa

0..n

11

0..n

Modelo de Classes:

Modelo ER:

Pertencente ao sistema

“Controle de Segurança”


176

Exemplo

Pessoa (AIE) Campos: matricula, nome, senha e tipo (gerente/trabahador). Obs:

Esse arquivo pode ter outros campos, mas conta-se só os que são usados no sistema de ponto

Registros: 1 (o próprio)

Ponto (ALI) Campos: matricula, data, horário entrada, horário saída. Registros: 1 (o próprio)

Justificativa (ALI) Campos: matricula, data, justificativa. Registros: 1 (o próprio)

Determinação das Funções Tipo Dados:


177

Exemplo Logon (SE) – Saída externa por ter senha criptografada

Campos: matrícula, senha, mensagens, comando (ex: botão ok). Arquivo Referenciado: Pessoa.

Registro de Ponto (EE) Campos: Indicador de entrada ou saída, mensagens, comando. Arquivo Referenciado: Ponto.

Consulta Ponto Diário (CE) Campos: data do ponto, horário entrada, horário saída, mensagens,

comando. Arquivo Referenciado: Ponto.

Ponto com Justificativa (EE) Campos: Indicador de entrada ou saída , horário, justificativa,

mensagens, comando. Arquivo Referenciado: Ponto, Justificativa.

Determinação das Funções Tipo Transação:


178

Exemplo Exclusão de Ponto (EE)

Campos: mensagens, comando. Arquivo Referenciado: Ponto, Justificativa.

Alteração de Ponto (EE) Campos: Horário Anterior, Horário Novo, mensagens, comando. Arquivo Referenciado: Ponto, Justificativa.

Acompanhar Presença (SE) Campos: data inicial, data final, total de horas do período, nome do

trabalhador, data do ponto, horário do ponto, indicador de entrada ou saída, justificativa, mensagens, comando.

Arquivo Referenciado: Ponto, Justificativa, Pessoa. Emitir Relatório de Presença (SE)

Campos: data inicial, data final, matrícula, nome, total de horas do trabalhador, nº de justificativas, total de horas geral,mensagens, comando.

Arquivo Referenciado: Ponto, Justificativa, Pessoa

Determinação das Funções Tipo Transação (cont.):


179

Exemplo

Função Tipo TD AR/TR Complexidade

Contribuiçao

Pessoa AIE 4 1 Baixa 5

Ponto ALI 4 1 Baixa 7

Justificativa ALI 3 1 Baixa 7

Logon SE 4 1 Baixa 4

Consulta Ponto diário

CE 5 1 Baixa 3

Registro de Ponto

EE 3 1 Baixa 3

Ponto com Justificativa

EE 5 2 Média 4

Ponto - Exclusão

EE 2 2 Baixa 3

Ponto - Alteração

EE 5 2 Média 4

Acompanhar Presença

SE 10 3 Média 5

Emitir Relatório de Presença

SE 9 3 Média 5

50


180

Exemplo

Considerando FA = 0,9

PF = 50 * 0,9 = 45


181

Estimativas de TamanhoEstimativas de TamanhoResumo da Contribuição Funcional

Arquivo Lógico Interno

Arquivo de Interface Externa

FUNÇÃO SIMPLES MÉDIA COMPLEXA

7

Entrada Externa

Consulta Externa

Saída Externa 7

4

4

4

5

3 6

3 6

5 7 10

10 15


182

Contagem Indicativa - NESMASegundo o Modelo de Dados e Interfaces:

Utilizaremos a “Contagem Indicativa” (NESMA)

A técnica assume que cada arquivo lógico (10 ptos.) terá: inclusão, alteração e exclusão

(3 x 4 = 12 ptos.)

1 relatório (5 ptos.)

2 consultas (2 x 4 = 8 ptos.)


183

Contagem Indicativa - NESMA Fórmula 1 (sem Interfaces):

PF = Qtd Arquivos Lógicos * 35 Considerando que as Interfaces

(7 ptos.) tenham:2 consultas (2 x 4 = 8 ptos.)

Fórmula 2 (completa):

PF = (Qtd. Arq. Lógicos * 35) + (Qtd. Interfaces * 15)


184

Contagem Indicativa - NESMA

EXEMPLO: SISTEMA COM 3 ARQUIVOS INTERNOS

PF = Nº de ALIs x 35 + Nº de AIEs x 15

PF = 3 x 35 + 0 x15 = 105

TOTAL DE PONTOS DE FUNÇÃO NÃO-AJUSTADOS = 105Para simplificar, supondo FATOR DE AJUSTE = 1, TEMOS: PONTOS DE FUNÇÃO AJUSTADOS = 105 *1 = 105


185

Considerações sobre pontos por função Desafios

O aplicador deve ser treinadoDeve existir uma baseline

Baseline: linha básica com resultados históricos contextualizados do desempenho da organização de desenvolvimento de software avaliada

Ex: produtividade


186

Considerações sobre pontos por função

Pontos de Função: razões para sucesso Em 1986: Int’l Function Point Users Group

(IFPUG) Em 2002: Norma ISO 20926 Muitas organizações investiram no levantamento

e armazenamento de grande quantidade de dados sobre projetos envolvendo PFs

Nenhuma outra métrica alcançou o mesmo nível de utilização


187

Considerações sobre pontos por funçãoConsiderações sobre pontos por função

O que se pode obter com PF? Métricas de Produtividade

Produtividade = tempo gasto trabalhando / PFs Exemplo: 900 hs / 400 PFs = 2,25 hs de trabalho/ponto de função

Estimativas de Esforço/Duração Cálculo do esforço em PFs Tempo = produtividade x esforço

Custo Custo / Ponto de Função

Defeitos Defeitos / Ponto de Função


188

Considerações sobre pontos por função Relação entre LOC e PF (aproximada)

Linguagem de Programação LOC/FP (média)

Linguagem de máquina 320

C 128

COBOL 106

FORTRAN 106

Pascal 90

C++ 64

Ada95 53

Visual Basic 32

Java 22

SmallTalk 22

PowerBuilder 16

SQL 12

Estimativa de tamanhoPontos por caso de uso


190

Pontos por Caso de Uso

Criados por Gustav Karner em 1993 como uma adaptação específica de PFs

Ponto de partida: diagramas de caso de usoBase na constatação: medida com PF exige

experts

Usuário

Efetuapagamento

Pagto comCartão de crédito

Pagto comDébito em Conta


191


As contagens de UCP podem variar Entre organizações e indivíduos Em razão dos diferentes estilos de casos de uso O sucesso depende de um estilo comum para

especificação de casos de uso não existem padrões para construção de casos de uso Não há como garantir que UCP estão medindo a mesma

coisa se os critérios para construção de casos de uso forem diferentes


192


O processoPonderando AtoresPonderando Casos de UsoPonderando Fatores TécnicosPonderando Fatores de Equipe e do

Ambiente


193


Ponderando atores (1)Simples – originam programas simples de

interface (carga) com outros sistemas ou cadastros simples.

Exemplo: um ator “Sistema de Faturamento”, que será acessado pelo caso de uso “Repor Estoque” apenas para realizar uma consulta no cadastro de notas fiscais, exibindo os itens faturados e respectivas quantidades.


194

Pontos por Caso de Uso Ponderando atores (2)

Médio – são programas de interface com outros sistemas que envolvem a recepção, interpretação, tratamento e envio de informações e interfaces interativas (transações interativas médias); ou existe uma pessoa interagindo através de um terminal com interface não gráfica.

Exemplo: um ator “Sistema de Faturamento”, que será acessado pelo caso de uso “Repor Estoque”, realizando consulta no cadastro de notas fiscais para exibir os itens faturados e respectivas quantidades. Envolve também consulta ao estoque mínimo de cada produto listado, e apontamento dos itens que necessitam ter pedido de compra por atingir estoque mínimo.


195


Ponderando Atores (3) Complexo – interfaces gráficas com alta

interatividade com o usuário. Exemplo: um ator “Sistema de Faturamento”, que será

acessado pelo caso de uso “Repor Estoque”, realizando consulta no cadastro de notas fiscais para exibir os itens faturados e respectivas quantidades. Envolve também consulta ao estoque mínimo de cada produto listado, gerando um pedido de compra automático para os itens que atingiram o estoque mínimo, com posterior envio de solicitação de aprovação pelo responsável.


196


Ponderando Atores (4)Totalizando as informações


197

Pontos por Caso de Uso Ponderando Casos de Uso (1)

Complexidade do Caso de Uso está diretamente relacionado com o negócio e a implementação esperada do Caso de Uso.

Classificação: simples, médio e complexo. Não devem ser considerados Casos de Uso resultados de

“include” e “extend” (razão não muito clara) A base para a ponderação dos Casos de Uso deve ser o número

de transações em um Caso de Uso, incluindo aquelas definidas nos caminhos alternativos.

Exemplo: uma transação para um sistema de faturamento envolve a inclusão da nota fiscal e dos itens da nota fiscal: ou são incluídos registros em ambas as entidades de dados, ou não há inclusão.


198


Ponderando Casos de Uso (2)Alternativa para determinar a complexidade

do caso de uso: Número de Classes Envolvidas

Tipo de Caso de Uso Número de Classes

Simples Menos que 5

Médio 5 a 10

Complexo Mais do que 10


199


Ponderando Casos de Uso (3)Totalizando


200


Ponderando Fatores Técnicos


201

Pontos por caso de usoPonderando fatores técnicos T1 – Sistemas Distribuídos: avaliar se o desenvolvimento em questão será distribuído e requer alta interação

para a consolidação ou replicação de informações. Sistemas distribuídos podem ter esforço extra, por exemplo, para determinar e tratar chaves de distribuição do banco de dados, “espelhamento” de entidades para segurança, estratégias de distribuição, etc. Por exemplo, nota 1 – porque não se planeja distribuir o primeiro release.

T2 – Tempo de resposta/desempenho: ponderar a criticidade do tempo de resposta e requisitos de desempenho para o desenvolvimento em questão. Pode demandar tempo, por exemplo, para realização de testes/ensaios durante as primeiras iterações, que podem acarretar desnormalizações do banco de dados, alteração de rotinas, etc. Por exemplo, nota 3 – porque a velocidade será limitada pela entrada de dados humana.

T3 – Eficiência (on-line): ponderar a necessidade da eficiência das telas on-line. Avalia a expectativa do usuário final em relação à interface a ser criada para o desenvolvimento em questão. Por exemplo, nota 5 – porque necessita de muita eficiência.

T4 – Processamento interno complexo: avaliar se o processamento interno do desenvolvimento em questão é complexo ou mais trivial, por exemplo, cálculos, regras de consistências, lógica de decisão, análise de informações. Processamentos complexos demandam profissionais mais treinados/experientes e podem aumentar o esforço necessário para realização dos testes. Por exemplo, nota 1 – porque o processamento interno é trivial.

T5 – Código deve ser reutilizável: avaliar reusabilidade de rotinas ou serviços. Caso positivo, serão necessários esforços extras para garantir alta coesão e baixo acoplamento, além da necessidade de profissionais mais treinados/experientes. Por exemplo, nota 1 – seria interessante, mas houve avaliação tardia.

T6 – Facilidade de instalação: avaliar como será realizada a instalação do produto, uma vez construído. Pode demandar esforço extra para criação de dispositivos de instalação amigáveis, sendo replicado em várias instalações, ou o software deverá ser instalado sem apoio técnico local. Por exemplo, nota 5 – porque precisa ser de fácil instalação para pessoas sem conhecimento técnico de TI.


202

Pontos por caso de usoPonderando fatores técnicos T7 – Usabilidade: avaliar facilidade de uso. Caso sejam necessárias facilidades de uso por profissionais não

técnicos, pode necessitar esforço relativo a estudos de ergonomia. Por exemplo, nota 5 – porque precisa ser de fácil utilização por pessoas sem conhecimento técnico de TI.

T8 – Portabilidade: avaliar grau de relevância para troca de plataformas, pois pode impedir a utilização de padrões que simplificam codificação e aumentam produtividade, além de eventualmente provocarem problemas de performance, acarretando esforço extra. Um exemplo seria a necessidade de utilização do padrão ANSI para SQL, impedindo uso de dialetos SQL. Por exemplo, nota 1 – porque inicialmente não é necessário.

T9 – Facilidade de manutenção: o código deve ser gerado com clareza, estruturação, parametrização e documentação, permitindo um alto índice de manutenções evolutivas. Por exemplo, nota 3 – porque requer uma facilidade de manutenção relativa, uma vez que não é esperado um volume evolutivo grande, ou produto tem ciclo de vida relativamente curto.

T10 – Acessos simultâneos: avaliar se haverá muitos acessos simultâneos a bases de dados ou serviços de aplicação; neste caso, envolve esforço extra para projetar, desenvolver e testar transações concorrentes. Note que sistemas multi-usuários devem ser avaliados neste quesito. Por exemplo, nota 5 – porque a aplicação não tem acesso concorrente, mas é multi-usuário.

T11 – Aspectos especiais de segurança: avaliar se será necessário algum tratamento extra de segurança ou se será apenas o habitual. Pode acarretar esforço extra para projetar, desenvolver e testar os aspectos especiais de segurança, como controle de accesso, segregação de uso de comandos, controle de visibilidade de informações, etc. Por exemplo, nota 3 – porque requer grau de segurança padrão.

T12 – Acesso direto para terceiros: avaliar se será necessário, por exemplo, acesso por clientes. Em caso afirmativo, considerar bastante relevante, pois pode envolver aspectos de ergonomia – neste caso, seria um complemento ao item T7. Por exemplo, nota 5 – porque precisa ser acessado pelos clientes.

T13 – Facilidades especiais de treinamento: avaliar como será realizado o treinamento dos usuários do produto, pois pode demandar esforço extra para geração de material de treinamento diferenciado. Por exemplo, nota 1 – porque a aplicação é simples demais.


203


Ponderando Fatores de Equipe e do Ambiente


204

Pontos por Caso de UsoPonderando Fatores de Equipe e do Ambiente

F1 – Familiaridade com o processo: indica se a equipe do projeto conhece e já utiliza o Processo de desenvolvimento de software. Por exemplo, nota 1 – porque a maior parte da equipe do projeto não é familiar com o processo definido.

F2 – Experiência na Aplicação: indica se a equipe do projeto conhece a aplicação do desenvolvimento em questão. Por exemplo, nota 1 – porque a maior parte da equipe é de programadores juniores.

F3 – Experiência na Técnica Estruturada ou OO: indica se a equipe do projeto conhece a técnica que será utilizada no desenvolvimento. Por exemplo, nota 1 – porque a maior parte da equipe é de analistas juniores, que não têm experiência prática com Orientação a Objetos.

F4 – Experiência do Líder de Projeto em gestão: indica a experiência que o líder para o projeto em questão possui. Por exemplo, nota 5 – porque o José da Silva (líder do projeto) tem muitos projetos de sucesso que liderou no passado.

F5 – Motivação: indica se a equipe do projeto tem motivação para trabalhar no projeto em questão. Por exemplo, nota 5 – porque a equipe do projeto ficou bastante empolgada com a importância do projeto para os clientes.

F6 – Requisitos estáveis: indica a probabilidade de os requisitos serem estáveis. Por exemplo, nota 5 – porque não são esperadas mudanças para o projeto em questão.

F7 – Trabalhadores com dedicação parcial: indica se haverá trabalhadores em período não integral. Para este quesito, nota (1) indica pouco ou nenhum colaborador de período não integral. Por exemplo, nota 1 – porque todos os trabalhadores estão alocados “full-time” ao projeto.

F8 – Dificuldade da Linguagem de Programação: indica a dificuldade da linguagem de programação que será utilizada pelo projeto em questão. Para este quesito, (1) indicará que a linguagem é de pouca complexidade e/ou que a equipe de projeto tem domínio completo sobre a mesma. Por exemplo, nota 2 – porque o projeto será codificado utilizando MS Visual Basic – a linguagem padrão da Organização.


205


Ponderando Fator de esforço


206

Pontos por Caso de Uso Ponderando Fator de esforço

A produtividade (horas-homem por ponto de caso de uso) é dada em função da soma dos fatores com valor “alto”.

Considerando: Quantidade de fatores F1 a F6 com nota menor que 3 = Q1 e Quantidade de fatores F7 a F8 com nota maior que 3 = Q2,

Quando: Q1 + Q2 <= 2, o valor sugerido é de 20 HH/PCUA; 3 <= Q1 + Q2 <= 4, o valor sugerido é de 28 HH/PCUA; Q1 + Q2 >= 5, a planilha exibe o Fator HH = 0, indicando que os riscos do

projeto estarão “acima do gerenciável”; neste caso, sugere-se ao gerente que as características do projeto sejam revistas em razão do alto risco

O número obtido em HH ou HD representa o valor total estimado para o esforço a ser demandado pelo projeto. Para saber o tempo dedicado a cada fase é importante ter uma idéia da distribuição percentual de esforço ao longo das fases do processo.


207

Exemplo de aplicação da técnicaPontos por caso de uso

Definição de Espaços

Gerar Planilhas

Gerarrecomendação

Analisar planilhas

SubmeterPlanilhas para

Avaliação

Gerar PI

Obter a APGerar Plano deMídia

Ranking

Gerar faturamento

Gerar reserva

Confirmarveiculação

Checking de Mídia

Mídia

Veículos

Preço

Audiência

Alcance&Frequencia /Planview

Faturamen

to

CLIENTE

Mídia

Mídia

Atendimento

<<uses>><<uses>>

<<extends>>

<<extends>>

<<uses>>valida<<extends>>

Faturamento

<<extends>>Inserção

<<extends>>mapa de reserva

<<extends>>aprovada

<<extends>>Planilhas Definidas


208

Exemplo de aplicação Pontos por caso de uso Os atores:

Cliente e o Mídia – complexos, pois são atores que interagem fortemente com o sistema e com o uso de Interfaces Gráficas dinâmicas

Checking de Mídia, Atendimento e Veículos – são atores de complexidade média, pois demandam interações com as GUI´s

Os sistemas FATURAMENTO/ AUDIÊNCIA / ALCANCE&FREQUENCIA / PLANVIEW são atores do tipo integração com outros sistemas que exigem programas de complexidade média para a sua integração

Os sistemas da PREÇO exige um programa simples de carga, logo é um ator do tipo simples


209

Exemplo de aplicação Pontos por caso de uso Quanto aos Casos de Uso classificamos:

Ranking, Geração do Plano de Mídia e Geração de PI – como Casos de Uso complexos do ponto de vista de negócio

Geração da Recomendação, geração das planilhas, obtenção das AP´s , a geração do faturamento e a Confirmação da Veiculação são Ucases de complexidade de negócio médias

A Análise das Planilhas e a Avaliação das planilhas são Casos de Uso de complexidade simples


210

Exemplo de aplicação Pontos por caso de uso


211



212


139

139

Recomendações finais


214

Estilos de apresentação de estimativas

Comunicando suposições Expressando incerteza Usando intervalos


215


Comunicando suposições Documentar as suposições do projeto:

Requisitos Não requisitos Necessidade de maior elaboração em alguns

requisitos Disponibilidade de recursos (pessoas) Dependência do trabalho de terceiros Principais itens desconhecidos Influências da estimativa Quão boa é a estimativa Para que ela pode ser usada


216


Comunicando suposições (exemplo)Estimativa do Projeto X

A estimativa de cronograma geral é de 6 meses, com 25% de precisão. Esta estimativa pode ser usada como base para o orçamento, porém não para fazer promessas fora da organização. A estimativa foi baseada nas seguintes suposições:

1. Os três principais líderes técnicos estarão alocados 100% ao projeto a partir de 15 de março.2. Toda a equipe de desenvolvimento e teste estará alocada para o projeto a partir de 15 de abril de

2006.3. O subsistema de formatação dos gráficos será sub-contratado e recebido com qualidade

adequada em 01 de agosto.4. Não serão requisitadas alterações nas regras do negócio.5. O tamanho da integração requerida com o sistema A é desconhecido. Esta estimativa alocou 250

pessoas-hora para esse serviço. Se for necessário mais do que isso a estimativa do projeto como um todo será alterada.

6. Não mais que 5 novos relatórios serão requeridos pelo cliente;7. Novas ferramentas de desenvolvimento a serem utilizadas nesse projeto melhorarão a

produtividade da equipe em 20% ou mais, comparado com outros projetos anteriores;8. A equipe terá menos dias sem trabalho por doença em média porque a maior parte do projeto

ocorre no verão.9. Após as datas de disponibilidade citadas nos itens 1 e 2, a equipe não será re-solicitada para

atender versões anteriores do software10.O projeto irá reutilizar pelo menos 80% do código de BD da versão 2.0 sem modificações.

Em caso de mudanças nessas suposições, a estimativa será revisada.


217


Expressando incerteza Usar quantificadores + e –

6 meses ± 2mesesR$600.000,00, + R$200.000,00, -

R$100.000,00 Incluir o desvio padrão nos quantificadores


218


Expressando incerteza Quantificando riscos (apenas os principais)

Combina quantificadores ± com as suposições

Estimativa: 6 meses, + 5 meses, - 1 mêsImpacto Descrição do risco

+1,5 mês A versão precisa de mais 20% de requisitos comparada a versão anterior

+1 mês Subsistema de formatação de gráfico entregue com atraso

+ 1 mês Novas ferramentas de desenvolvimento não funcionam conforme previsto

+ 1 mês Não é possível reutilizar 80% do BD da versão anterior

+0,5 mês Taxa de doença da equipe não é menor conforme suposição

-0,5 mês Todos os desenvolvedores alocados em 1 de abril

-0,5 mês Novas ferramentas de desenvolvimento funcionam melhor que o esperado


219


Expressando incerteza Fatores de confiança

Qual a chance de terminar em uma data?

Evitar usar 90% de confiança ou mais

Data de entrega

Probabilidade de entregar até essa data

15 de janeiro 20%

01 de março 50%

01 de novembro 80%


220


Expressando incerteza Fatores de confiança

Melhorando a visualizaçãoExemplo de apresentação de estimativa

jan

fev

mar

abrmai

jun jul ago set out nov

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

jan fev mar abr mai jun jul ago set out nov

data de entrega

nív

el

de

co

nfi

an

ça


221

Como defender suas estimativas?

Problema: Equipe técnica tende a ser introvertida Negociação ocorre entre técnico e executivos

Influências políticas Esteja ciente das influências externas da meta. Deixe

claro que compreende essa importância O que se pode negociar?

Não se negocia estimativa. É possível negociar promessas relacionadas à estimativa.


222

Como defender suas estimativas? Exemplo de negociação:

Técnico: “Nossa estimativa é de 5 a 7 meses. Estamos no início do cone da incerteza, então ainda podemos melhorar essa estimativa enquanto trabalhamos

Executivo: O intervalo de 5 a 7 meses é muito grande. Por que não usamos a estimativa de 5 meses?

Técnico: “É importante distinguir entre estimativa e promessa. A estimativa eu não posso mudar, porque foi resultado de análise e vários cálculos. Mas eu posso fazer com que minha equipe prometa terminar em 5 meses se concordarmos em levar em consideração esse risco.”

Executivo: “Não entendi. Qual a diferença?” Técnico: “o intervalo de 5 a 7 meses inclui um desvio padrão de 50/50 de

uma estimativa de 6 meses. Significa que temos 84% de chance de terminar em 7 meses. E apenas 16% de chance de terminar em 5 meses.”

Executivo: “Nós precisamos de mais de 50% de chance na data a prometer, porém 84% é muito conservador. Qual data seria seria 75% provável?

Técnico: mais ou menos 6,5 meses. Executivo: “Então vamos prometer esse prazo!”


223


Trate as discussões sobre estimativas como resolução de problemas e não negociação....Todos ganham ou todos perdem. (McConnel, 2006)

Ataque o problema, não as pessoas. Negocie a quantidade de funcionalidades

se a meta for rígida.


224


Dicas e opções Mova algumas funcionalidades para a versao 2 Use abordagem iterativa e faça primeiro as principais

funcionalidades Corte os requisitos mais caros Use o método do tamanho da camiseta para tratar os requisitos

mais importantes Adicione mais desenvolvedores e testadores somente no início do

projeto Adicione pessoal administrativo Aumente o nível de envolvimento do usuário Aloque recursos 100% para o projeto Calibre a produtividade da equipe em uma ou duas iterações e

então faça promessas baseado nisso


225


Insista em usar critérios objetivos

estimador Cliente/executivo não técnico

Estimativas Metas!

Promessas


226

Sites relacionados

http://www.ifpug.org/ http://www.stevemcconnell.com/home.htm http://sunset.usc.edu/research/cocomosuit

e/suite_main.html http://www.spc.ca/resources/index.htm


227

ReferênciasCenter for Software Engineering ( Barry Boehm): ttp://sunset.usc.edu/research/COCOMOII/Boehm, Barry, et al. Software Cost Estimation with Cocomo II. Addison Wesley, 2000.Project Management Institute: http://www.pmi.orgJones, C. Patterns of large software systems: failure and successComputer, Vol.28, Iss.3, Mar 1995; Pages: 86-87Jones, Capers. Applied Software Measurement. McGraw-Hill. 2nd Edition, 1996.Robert N. Charette. Why Software Fails. IEEE Spectrum (Set/2005). Stellman, A.; Greene, J. Applied Software Project Management. O’Reilly. 2005.Vazquez, C. E.; Simões, G.; Albert, R. Análise de Pontos por função: Medição, Estimativas e Gerenciamento de Projetos de Software. 2ª edição Ed. Erica, 2003.Florac, W.; Carleton, A. Measuring the Software Process. Addison Wesley, 1999.McConnel, Steve. Software Estimation: Desmystifying the Black Art. Microsoft Press, 2006.Software Project Estimation by Kathleen Peters, Software Productivity Center Inc., 1999Humphrey, Watts. A Discipline for Software Engineering. Addison Wesley, 1995. Software Productivity Center Inc. (SPC), http://www.spc.ca

métricas e estimativas de projetos de software

Documents