Gestão de Configuração & Mudanças 2. Estimativas de Esforços Márcio Aurélio Ribeiro Moreira [email protected]

Especialização em Engenharia

de Software

Gestão de Configuração & Mudanças2. Estimativas de Esforços

Márcio Aurélio Ribeiro [email protected]://si.lopesgazzani.com.br/docentes/marcio/

Márcio Moreira 2. Estimativas de Esforços – slide 2Gestão de Configuração & Mudanças - GCM

Como estimar o esforço do projeto?

Disciplina Elementos Disponíveis Qual a melhor opção?

Modelagem de NegócioCasos de Uso de NegócioProcessos ou OperaçõesCasos de Uso de Sistema

Requisitos Lista de FeaturesRequisitos

Análise & Projeto Arquitetura do SoftwareClasses & Diagramas

Implementação Modelo de ImplementaçãoCódigo Fonte

Testes Casos de Teste

Distribuição Plano de DistribuiçãoDiagrama de Distribuição

Gestão de Configuração e Mudanças Itens de ConfiguraçãoMudanças

Gestão do Projeto Plano de Desenvolvimento do Software

Ambiente Processo & Ferramentas


Margens de Erro por Fase do Ciclo de Vida

Fonte: Boehm 1995.

http://si.lopesgazzani.com.br/docentes/marcio/gcm/p_usccse95-508.pdf



Técnica Delphi (Empírica)

Delphi Criação:

1944: General Henry Arnold Popularização:

1964: Gordon e Helmer Ideia:

A visão de um grupo é melhor que a visão de uma pessoa

Método:Pelo menos 3 especialistas

estimam o esforço a partir da descrição do problema

PERT Criação:

1950: Marinha Americana Popularização:

Década 70 em projetos (PMI) Ideia:

Combinar visões Otimista, Realista e Pessimista

Equações:

A Média ± Desvio tem 90% de chance de ocorrer

http://en.wikipedia.org/wiki/Henry_H._Arnold

http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique

http://www.enotes.com/program-evaluation-and-review-technique-pert-reference/program-evaluation-review-technique-critical-path


Técnicas Formais

Análise de Pontos de Função (FPA):1979: Allan J. Albrecht na IBM1986: Criado o International Function Point User Group (IFPUG)Requer decomposição funcional

Pontos de Caso de Uso (UCP):1993: Gustav KarnerBaseada nos Pontos de FunçãoNão requer decomposição funcional

COCOMO II:COnstructive COst MOdel1981: Barry W. Boehm – 1ª versão1995: 2ª versão – COCOMO IIRequer definição dos requisitos

http://www.ifpug.org/Metric%20Views/2011WinterMV.pdf

http://se.linkedin.com/pub/gustav-karner/44/8b6/27

http://se.linkedin.com/pub/gustav-karner/44/8b6/27

http://en.wikipedia.org/wiki/Barry_Boehm

http://en.wikipedia.org/wiki/Barry_Boehm

http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html


Pontos de Função (Allan J. Albrecht)

Para cada função:Conte o número de parâmetros

utilizando os seguintes fatores:A: Número de entradas

externasB: Número de saídas externasC: Número de consultas

externas (entradas externas interativas)

D: Número de arquivos externos (permanentes)

E: Número de arquivos internos (temporários)

Decida a complexidade de cada fator utilizando as tabelas nos slides seguintes


Entradas, Saídas e Consultas Externas

A: Entradas Externas B: Saídas Externas

Tipos ≠ deArquivos

Tipos ≠ de Campos

1 a 4 5 a 15 ≥ 16

0 ou 1 Simples Simples Médio2 Simples Médio Complexo

≥ 3 Médio Complexo Complexo


Tipos ≠ de Campos

1 a 5 6 a 19 ≥ 20

0 ou 1 Simples Simples Médio2 ou 3 Simples Médio Complexo


C: Consultas Externas (entrada) C: Consultas Externas (saídas)


Tipos ≠ de Campos

1 a 4 5 a 15 ≥ 16

0 ou 1 Simples Simples Médio2 Simples Médio Complexo



Tipos ≠ de Campos

1 a 5 6 a 19 ≥ 20

0 ou 1 Simples Simples Médio2 ou 3 Simples Médio Complexo



Arquivos Externos e Internos

D: Arquivos Externos E: Arquivos Internos

Tipos ≠ deRegistros

Tipos ≠ de Campos

1 a 19 20 a 50 ≥ 51

1 Simples Simples Médio2 a 5 Simples Médio Complexo≥ 6 Médio Complexo Complexo

Tipos ≠ deRegistros

Tipos ≠ de Campos

1 a 19 20 a 50 ≥ 51

1 Simples Simples Médio2 a 5 Simples Médio Complexo≥ 6 Médio Complexo Complexo

Identifique os Pontos de Cada Fator na TabelaFator Simples Médio Complexo

A 3 4 6B 4 5 7C 3 4 6D 7 10 15E 5 7 10


Pontos de Função Não Ajustado

Complexidade Simples Médio ComplexoTotal dePontos

Fatores Número Peso Número Peso Número Peso

A: Entradas Externas S 3 M 4 C 6 Sx3 + Mx4 + Cx6

B: Saídas Externas 4 5 7

C: Consultas Externas 3 4 6

D: Arquivos Externos 7 10 15

E: Arquivos Internos 5 7 10

Pontos de Função Não Ajustado (UFP: Unadjusted Function Points): ∑


Fator de Complexidade Técnica(Technical Complexity Factor)Fator Descrição Grau de Influência

1 Nível de comunicação de dados

Defina o grau de influência do fator utilizando a escala:

0: Irrelevante1: Baixa2: Moderada3: Média4: Alta5: Crítica

2 Nível de distribuição das funções

3 Nível de performance requerido (desempenho)

4 Nível de padronização da configuração utilizada

5 Taxas de transação utilizadas

6 Nível de entrada de dados online

7 Nível de adequação do projeto à eficiência do usuário

8 Nível de atualizações online

9 Nível de complexidade de processamento

10 Nível de reutilização esperada deste software

11 Nível de facilidade de instalação

12 Nível de facilidade de uso

13 Nível de utilização em locais (sites) diferentes

14 Nível de facilidade de mudança necessário

TCF = 0,65 + 0,1 x DI DI = ∑ Grau de Influência


Pontos de Função & Linhas de Código

Pontos de Função Calculando os pontos das

funções (FP):FP = UFP × TCFOnde:

UFC: Pontos de Função Não Ajustado

TCF: Fator de Complexidade Técnica

Cálculo do Esforço:Esforço = FP x 16 horas (média)Duração = Esforço / PessoasPessoas = Esforço / Duração

Linhas de Código (LOC)Linguagem Média de LOC ou FPAssembler 300COBOL 100FORTRAN 100Pascal 90Ada 70PL/1 65Orientadas a Objeto 304ª Geração (4GL) 20Gerador de Código 15

Nota:

Entretanto, a correlação entre FP e LOC não é tãoadequada. Isto foi provado num estudo de 1985da Xerox (XER85).


Limitações e benefícios dos Pontos de Função

Limitações da FPA No começo foi amplamente

usada. Charles Symons reportou limitações

A complexidade das funções e o peso não é suficientes

A forma de utilizar arquivos evoluiu muito nestes anos

A interação humana é muito mais online do que batch

Faltam fatores ambientais nos fatores técnicos

Benefícios da FPA Foi padronizado pela ISO/IEC

20926Manual de contagem dos

pontos Uma das primeiras métricas a

medir o tamanho do software com alguma precisão

Mesmo com as limitações, a técnica é bem melhor que as previsões por linha de código


Pontos Por Casos de Uso (Karner)

Extensão dos métodos:Pontos de Função e Pontos de Função MK II

Era parte integrante do RUP até a versão 6 O método permite a estimativa de esforço já à partir do desenho

dos Casos de Uso Ideia:

Ponderar o peso de cada Caso de Uso e de cada Ator envolvidoConsiderar a complexidade técnica e ambientalConsiderar a produtividade da empresa

Pontos dos

Atores

Pontos dos

Casos de Uso

Complexidade

Técnica

Fatores Ambient

ais

Produtividade

Estimativa de

Esforço


Peso dos Casos de Uso (Use Case Weight)

Complexidade Número de Transações Peso

SimplesAté 3 transações [ Realizáveis com até 5 objetos de análise (classes) e 1 entidade de Banco de Dados ]

5

MédioDe 4 a 7 transações [ Realizáveis com 6 a 10 objetos de análise e até 2 entidades de Banco de Dados ]

10

ComplexoAcima de 7 transações [ Realizáveis com mais de 10 objetos de análise e até 3 entidades de Banco de Dados ]

15

Peso Não Ajustado dos UC (UUCW) = UC Simples x 5 + UC Médios x 10 + UC Complexos x 15

Transação:É o conjunto de atividades que devem ser executadas atomicamente.Normalmente, é o número de passos de um Caso de Uso (incluindo os

fluxos alternativos). Comentário:

Se um caso de uso está muito complexo é sinal que ele deve ser dividido.


Peso dos Atores (Actor Weight)

Complexidade Número de Transações Peso

SimplesSistema externo que se comunica com o nosso via interface bem definida. Ex.: API

1

MédioSistema externo que se comunica com o nosso via protocolos padrões. Ex.: TCP/IP, FTP, HTTP ou SQL[ Interação humana via interface clássica (texto, não gráfica) ]

2

ComplexoPessoas interagindo com nosso sistema via interface gráfica (GUI) orientada a eventos

3

Peso Não Ajustado dos Atores (UAW) = Atores Simples + Atores Médios x 2 + Atores Complexos x 3

Complexidade:A interface do ator com o software que está em desenvolvimento é o

determinante do esforço necessário para realizar a interface dos atores com os casos de uso do sistema

As interfaces gráficas, orientadas a eventos são as mais complexas


Fator de Complexidade Técnica(Technical Complexity Factor)

Fator Descrição Peso Valor Pontos

T1 Nível de distribuição do sistema 2,0

Defina aimportânciadeste fator

para osoftware

a serdesenvolvido:

0: Irrelevante1: Baixa2: Média3: Alta4: Muito alta5: Crítica

PesoX

Valor

T2 Agressividade dos tempos de resposta 1,0

T3 Nível de eficiência para o usuário 1,0

T4 Nível de complexidade interna de processamento 1,0

T5 Nível de reuso de código 1,0

T6 Facilidade de instalação necessária 0,5

T7 Facilidade de uso necessária 0,5

T8 Necessidade de portabilidade para outras plataformas 2,0

T9 Nível de facilidade de manutenção necessário 1,0

T10 Nível de processamento concorrente ou paralelo 1,0

T11 Nível dos recursos de segurança 1,0

T12 Nível de acesso externo para terceiros 1,0

T13 Nível de treinamento dos usuários 1,0

TCF = 0,6 + (TF / 100) TF = ∑ ( Peso x Valor)


Fator de Complexidade Ambiental(Environmental Complexity Factor)Fator Descrição Peso Valor Pontos

E1 Familiaridade com o processo de desenvolvimento 1,5

Defina onível de

experiênciada equipe:

0: Inexperiente1: Júnior2: Pleno3: Sênior4: Máster5: Especialista

PesoX

Valor

E2 Nível de experiência na aplicação 0,5

E3 Nível de experiência com a orientação a objeto 1,0

E4 Nível de capacidade do analista 0,5

E5 Nível de motivação da equipe 1,0

E6 Nível de estabilidade dos requisitos 2,0

E7 Nível de pessoas com dedicação parcial na equipe -1,0

E8 Nível de dificuldade da linguagem de programação -1,0

ECF = 1,4 + (-0,03 x EF) EF = ∑ ( Peso x Valor)


Pontos de Caso de Uso & Esforço

Pontos de UC Calculando os pontos dos Casos de

Uso (UCP):

UCP = (UUCW + UAW) x TFC x ECF

Onde: UUCW: Peso Não Ajustado dos

Casos de Uso UAW: Peso Não Ajustado dos

Atores TCF: Fator de Complexidade

Técnica ECF: Fator de Complexidade

Ambiental

Esforço Esforço = UCP x Horas Homem

Horas Homem (HH):Karner sugeriu 20 em 1993Schneider e Winters (1998):

P1 = Número de Pontos de E1 a E6 que são menores que 3

P2 = Número de Pontos de E7 a E8 que são maiores que 3

Se (P1 – P2) ≤ 2 então HH = 20Se (P1 – P2) = 3 ou 4 então HH = 28Se (P1 – P2) > 4 então reveja o

projeto ou use HH = 36


Exemplo: Sistema de Compras Online

SC

SM

M

CC

M

C

S

C

C

C

C


Peso dos Atores e Casos de Uso do Exemplo

Atores Casos de UsoComplexidade Peso Quantidade Pontos

Simples 1 1 1

Médio 2 0 0

Complexo 3 4 12

Peso Não Ajustado dos Atores - UAW: 13

Complexidade Peso Quantidade Pontos

Simples 5 2 10

Médio 10 3 30

Complexo 15 4 60

Peso Não Ajustado dos UC - UUCW: 100


Fator de Complexidade Técnica do Exemplo


T1 Nível de distribuição do sistema 2,0 5 10

T2 Agressividade dos tempos de resposta 1,0 5 5

T3 Nível de eficiência para o usuário 1,0 3 3

T4 Nível de complexidade interna de processamento 1,0 2 2

T5 Nível de reuso de código 1,0 3 3

T6 Facilidade de instalação necessária 0,5 1 0,5

T7 Facilidade de uso necessária 0,5 5 2,5

T8 Necessidade de portabilidade para outras plataformas 2,0 2 4

T9 Nível de facilidade de manutenção necessário 1,0 2 2

T10 Nível de processamento concorrente ou paralelo 1,0 3 3

T11 Nível dos recursos de segurança 1,0 5 5

T12 Nível de acesso externo para terceiros 1,0 1 1

T13 Nível de treinamento dos usuários 1,0 1 1

TFC = 0,6 + (TF / 100) = 0,6 + (42 / 100) = 1,02 TF: 42


Fator de Complexidade Ambiental do Exemplo


E1 Familiaridade com o processo de desenvolvimento 1,5 3 4,5

E2 Nível de experiência na aplicação 0,5 3 1,5

E3 Nível de experiência com a orientação a objeto 1,0 2 2,0

E4 Nível de capacidade do analista 0,5 5 2,5

E5 Nível de motivação da equipe 1,0 2 2,0

E6 Nível de estabilidade dos requisitos 2,0 1 2,0

E7 Nível de pessoas com dedicação parcial na equipe -1,0 0 0,0

E8 Nível de dificuldade da linguagem de programação -1,0 4 -4,0

ECF = 1,4 + (-0,03 x EF) = 1,4 + (-0,03 x 10,5) = 1,085 EF: 10,5


Pontos de Caso de Uso & Esforço do Exemplo

Calculando os pontos dos Casos de Uso (UCP):UCP = (UUCW + UAW) x TFC x

ECFUCP = (100 + 13) x 1,02 x 1,085

= 125,06 Calculando o esforço:

Esforço = UCP x Horas HomemKarner:

Esforço = 125,06 x 20 = 2501Schneider e Winters:

P1 = 5P2 = 1P1 – P2 = 4 suspender o

projeto ou utilizar HH = 36Esforço = 125,06 x 36 = 4502

Dicas de mercado sobre Horas Homem:Se tem histórico:

HH = ( ∑ Horas / ∑ UCP ) Reais

Se não tem histórico:Avalie a maturidade da equipe

como um todoConsidere HH:

Experts: HH = 15 Másters: HH = 20 Sênior: HH = 25 Pleno: HH = 30 Júnior: HH = 36


Limitações e benefícios do método de Karner

Limitações dos UCP Os UC não devem ultrapassar o nível

complexo Se necessário, quebre o UC

Devido à subjetividade, a padronização dos UC é impossível, isto dificulta a aplicação do método Alguns especialistas desaconselham

o método devido ao risco Os requisitos não-funcionais não são

tratados pelo método Não existem registros publicados de

testes com projetos grandes e médios

Benefícios dos UCP É baseado em escopo definido É de fácil utilização pelos técnicos É de fácil entendimento pelos

clientes e usuários finais É baseado em UC, que são muito

utilizados pela indústria de software

São mais estáveis que os pontos de função

Pode ser utilizado em tempo de concepção do projeto, ou seja, em tempo de proposta comercial


COCOMO II (Boehm)

Hierarquia de modelos de estimativas Mede: Esforço, Prazo e Custo Entradas: PF (Pontos de Função) e LOC (Linhas de Código)Avançado – Desenvolvimento

(Implementação)Esforço = função(anteriores, impacto deles por fase)

Intermediário – Arquitetura(Projeto Antecipado)

Esforço = função(tamanho, produto, hardware, pessoal e atributos)

Básico – Prototipação(Composição do Software)Esforço = função(tamanho em LOC)


Modelo Básico

Equações

Onde:Esforço: Horas mensais / PessoaDuração: Em mesesKLOC: Milhares de LOC estimadas

para o projeto. Estimadas pelo método Delphi e PERT

Fatores: Vide tabela ao lado, considerando o tipo do projeto

Tipo de ProjetoTipo a b c dOrgânico 2,4 1,05 2,5 0,38Semi-orgânico 3,0 1,12 2,5 0,35Embarcados 3,6 1,2 2,5 0,32

Orgânico: Projetos pequenos, simples, com

requisitos rígidos, equipe pequena e experiente na aplicação

Semi-orgânico: Projetos intermediários, com requisitos

semi-rígidos, equipes com diferentes níveis de experiência

Embarcados: Software para rodar no hardware


Modelo Intermediário - Fatores de Ajuste

Fatores de Ajuste do Esforço (FAE) MuitoBaixo Baixo Normal Alto Muito

Alto Altíssimo

Atributos do Produto:Confiabilidade do sistema 0,75 0,88 1,00 1,15 1,40Tamanho do aplicativo 0,94 1,00 1,08 1,16Complexidade do produto 0,70 0,85 1,00 1,15 1,30 1,65Atributos de Hardware:Restrições de performance 1,00 1,11 1,30 1,66Restrições de memória 1,00 1,06 1,21 1,56Máquina virtual 0,87 1,00 1,15 1,30Recuperação de falhas 0,87 1,00 1,07 1,15Atributo de Pessoal:Capacidade de análise 1,46 1,19 1,00 0,86 0,71Capacidade de engenharia de software 1,29 1,13 1,00 0,91 0,82Experiência no domínio 1,42 1,17 1,00 0,86 0,70Experiência com máquina virtual 1,21 1,10 1,00 0,90Experiência na linguagem de programação 1,14 1,07 1,00 0,95Atributos do Projeto:Disponibilidade de ferramentas para o uso 1,24 1,10 1,00 0,91 0,82Aplicação de métodos de engenharia de software 1,24 1,10 1,00 0,91 0,83Cronograma de desenvolvimento 1,23 1,08 1,00 1,04 1,10


Modelo Intermediário

Equação:

Onde:FAE: Fator de Ajuste de Esforço

Tipo de Projeto:

Calibragem dos Fatores:Os parâmetros originais vem

calibrados com base em 161 projetos de sucesso.

Estes projetos foram escolhidos entre 2000, seguindo critérios científicos e estatísticos.

O importante é calibrar estes fatores com dados históricos de sua empresa.

Tipo a bOrgânico 3,2 1,05Semi-orgânico 3,0 1,12Embarcados 2,8 1,20


Modelo Avançado de Pontos de Objeto

Ideias Calcular o Tamanho do

Objeto (TO) por meio de:Telas de interface com o

usuárioRelatóriosComponentes do software

Fatores adicionais:Ponderação de cada objeto

pelas tabelas do método% de reutilização de códigoProdutividade da equipe

Equações Pontos dos Objetos (PO):

Pontos Ajustados (APO):

Produtividade:

Utilize dados históricos Esforço:


Modelo Avançado - Esforço no Ciclo de Vida

É um modelo de várias variáveis que distribui o esforço ao longo do ciclo de vida de desenvolvimento

Equação:

Onde:Esforço: em pessoas por mêsKLOC: Milhares de linha de códigoB: Fator especial de habilidades (vide tabela no artigo original)P: Fator de produtividade


Exemplo de aplicação do COCOMO II

Contexto: Projeto complexo, mas conhecido Tamanho estimado = 96 KLOC Pouca experiência sobre a aplicação Conhecimento da linguagem de

programação: muito baixo Tamanho do DB elevado Metodologia de desenvolvimento:

nenhuma O custo do pessoal é $3K por mês

Pergunta: Usando estimativas intermediárias,

valeria a pena investir: $100K em metodologias $120K em treinamento em linguagem

de programação Objetivo: Alcançar o valor nominal para

tais características

Cálculos:O esforço é 762 pessoas mêsCusto em pessoal é $(762 * 3K) =

$2286K Treinamento em Metodologia:

Estimativas reduzidas em 70 pessoas mês = $210K

A economia é de $110K Treinamento em Linguagem de

Programação:Estimativas reduzidas em 94

pessoas mês = $282KA economia é de $162K


Quadro Comparativo das Técnicas

Parâmetro Delphi/PERT FPA UCP COCOMO II

É independente de linguagem de programação Sim Sim Sim Não

Fornece algum programa de certificação Não Sim Não Não

É independente de expertise humana Não Sim Sim Sim

Margem de Erro clássica (inferência empírica) ±40% Requisitos: ±30%Projeto: ±10% ±30% ±20%

Disciplina de entrada M. Negócio Requisitos M. Negócio Projeto

Nível de detalhamento Menor Médio Médio Maior

Principal fator limitante Necessidadede Expertise

Falta de FatoresAmbientais

Falta atualizaro método

SubjetivismoRequisitos Não

Funcionais eFalta Testes

Estimativatardia e

Dependedo KLOC

Principal benefício Simplicidade Padronizaçãoe adoção

Uso em tempode propostas Precisão


Tabela de Distribuição de Esforços x Fase

Projetos Típicos:

Projetos Complexos:

Planejamento da Elaboração:

Gastos x Fases Concepção Elaboração Construção TransiçãoTempo Gasto 10% 30% 50% 10%Recursos Gastos

5% 20% 65% 10%

Gastos x Fases Concepção Elaboração Construção TransiçãoTempo Gasto 20% 33% 40% 7%Recursos Gastos

8% 24% 60% 8%

FasesModelo deNegócios

Completado

Casos de Uso

Identificados Descritos AnalisadosProjetados,

Implementados e Testados

Concepção 50% a 70% 50% 10% 5%Uma pequena percentagem

Só as provas de conceito

ElaboraçãoPerto de

100%80% ou mais 40% a 80% 20% a 40% Menos de 10%

Construção

100% 100% 100%100% seMantido

100%


Resultados de Projeto Real

Distribuição de HorasResumo %

Gestão de Requisitos 10%

Análise & Projeto 16%

Implementação 24%

Testes 23%

CRs 10%

Gestão de Projetos/Config. E Mudança 6%

Ambiente e Distribuição 7%

Testes de Aceite 3%

Total: 100%

Premissas Concepção feita antes Modelagem de negócios

inclusa na Concepção Erro de estimativa: -5% Distribuição utilizada:

Disciplina %

M.Negócio/Requisitos 10%

Análise 8%

Projeto 22%

implementação 35%

Teste 16%

Gerenciamento 8%

Ambiente 1%


Referências

Sigla Referência

BBO95Barry Boehm, Bradford Clark, at al. Cost Models for Future Software Life Cycle Processes: COCOMO 2.0. Annals of Software Engineering. 1995.

S&W98 Geri Schneider & Jason P. Winters. Applying Use Cases: A Practical Guide. Addison Wesley. 1998

GKA93 Gustav Karner. Resource Estimation for Objectory Projects. Objective Systems SF AB. 1993.

JOS99 John Smith. A Estimativa de Esforço Baseada em Casos de Uso. Rational. 1999.

KRB01 Kirsten Ribu. Estimating Object-Oriented Software Projects with Use Cases. Master of Science Thesis, University of Oslo, Department of Informatics. 2001.

M&C08 Manfred Bundschuh & Carol Dekkers. The IT Measurement Compendium. Estimating and Benchmarking Sucess with Functional Size Measurement. Springer. 2008.

MTD09 Marlise There Dias. Um guia para estimativa de projetos de software em micro e pequenas empresas. Univali. 2009.

PVI03 Paul Vickers. An Introduction to Function Point Analysis. Computing UNN. 2003.

RKC06 Roy K. Clemmons. Project Estimation With Use Case Points. CROSSTALK. 2006.

XER85 Xerox. A Cooperative Industry Study: Software Development/Maintenance Productivity; Xerox Corporation. 1985.


http://si.lopesgazzani.com.br/docentes/marcio/gcm/p_Karner_ResourceEstimationForObjectoryProjects.pdf



http://si.lopesgazzani.com.br/docentes/marcio/gcm/p_TP171.pdf

http://books.google.com.br/books?id=7NDRFgpCqV8C&pg=PA401&lpg=PA401&dq=Schneider+Winters+use+case+points&source=bl&ots=cqbmsBIyGr&sig=qZV1OPV2LYNeqLJEj_NssJtVnbI&hl=pt-BR&sa=X&ei=JLo4UcX_CJPC9QSF-YGIBg&ved=0CCwQ6AEwAA#v=onepage&q=Schneider%20Winters%20use%20case%20points&f=false

http://si.lopesgazzani.com.br/docentes/marcio/gcm/p_Marlise_There_Dias.pdf

http://si.lopesgazzani.com.br/docentes/marcio/gcm/p_Marlise_There_Dias.pdf

http://computing.unn.ac.uk/staff/cgpv1/downloadables/fpa.pdf

http://www.bfpug.com.br/Artigos/UCP/Clemmons-Project_Estimation_with_UCP.pdf

Documents

Gestão de Configuração & Mudanças 2. Estimativas de Esforços Márcio Aurélio Ribeiro Moreira [email protected]