VB.NET - Estimativa de preço com Análise de Pontos de Função - APF

Este é uma série de artigos onde você vai acompanhar todo o ciclo de desenvolvimento de um sistema completo em VB.NET.
Iremos acompanhar o ciclo de vida do projeto para Manutenção de clientes que será desenvolvido em VB.NET com acesso a uma base de dados Access. 

Como você já deve saber, o desenvolvimento de um projeto de software não é uma tarefa trivial, e, esta bem distante de sentar na frente de um terminal de vídeo e sair codificando a esmo. Se você não acredita no que eu estou falando talvez acredite em dados estatísticos; O CHAOS Report de 2003 apresentou as seguintes estatísticas:

• Somente 34% dos projetos de software são bem sucedidos;
• 15% dos projetos foram cancelados;
• 43% é o erro médio em relação ao orçamento do projeto daqueles que foram completados;
• 52% das características (requisitos não funcionais) e funcionalidades são entregues no produto.

Na verdade se você quiser desenvolver software com qualidade deverá adotar um processo de desenvolvimento de software.

Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1] trás a seguinte definição:

"[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software".

Jalote[7] conclui que um processo de software é :

"é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo. Obviamente , um processo que não aumenta a produção (não suporta projetos de software grandes) ou não pode produzir software com boa qualidade não é um processo adequado."

A partir destas definições podemos considerar que de forma geral um processo de software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um produto de software. Na definição de um processo de software devem ser consideradas as seguintes informações: atividades a serem realizadas, recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado [3].

Sucintamente podemos definir o processo de software (defini-lo(o processo) como um conjunto de atividades uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir um certo objetivo.

Humphrey[4] define as seguintes razões para a definição de um processo padrão:

Fases de um processo de Software

Para Schwartz[5] as principais fases de um processo de software são :

  1. Especificação de Requisitos: tradução da necessidade ou requisito operacional para uma descrição da funcionalidade a ser executada.
  2. Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema.
  3. Programação (Codificação): produção do código que controla o sistema e realiza a computação e lógica envolvida.
  4. Verificação e Integração (Verificação): verificação da satisfação dos requisitos iniciais pelo produto produzido.

Ao contrário do que possa parecer não existe uma sequência obrigatória de fases, sendo que diversos autores apontam a natureza não-simultânea das fases como uma realidade na aplicação de processos de software, e também defendem que o processo de software é muito mais iterativo e cíclico do que a idéia de fases simples pode sugerir.[6]

Atividades do Processo de Software

Em cada fase de um processo de software definido são executadas as atividades básicas para que sejam atingidos os objetivos propostos. Segundo Pressman[2] estas atividades constituem um conjunto mínimo para se obter um produto de software.

Realizando uma combinação de classificações dadas por Schwartz[5] , Pressman[2] e Sommerville[1] podemos identificar as seguintes atividades[6]:

1. Especificação
    1. Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extra-software.
    2. Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento.
    3. Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.
2. Projeto
    1. Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.
    2. Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.
    3. Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudo-código.
3. Implementação
    1. Codificação: a implementação em si do sistema em uma linguagem de computador.
4. Validação
    1. Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado a nível das funções e módulos básicos do sistema.
    2. Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.
5. Manutenção e Evolução
    1. Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.

Desta forma as atividades relacionadas a um processo de software estão diretamente vinculadas com a produção do software como produto final . Afim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software.

Sistema de Manutenção de Clientes

Descrição do sistema:

- Em um sistema de manutenção de clientes um usuário (funcionário de empresa) registra as entradas, alterações, exclusões e saídas(relatório) dos dados relativos a um cliente da empresa no sistema. Qualquer usuário da empresa poderá acessar o sistema e efetuar o cadastramento.(Não haverá controle de acesso no sistema). Será emitido um relatório de todos os clientes cadastrados e dos dados de um determinado cliente.

Características do sistema:
- O sistema irá permitir o acesso sem restrições para qualquer usuário da empresa , não havendo portanto controle de acesso.
- Não existe qualquer interface com outros sistemas existentes
- Deverão ser cadastrados os seguintes dados de um cliente: Nome , endereço, Cidade , Cep , Telefone , Email e Observações.
- O nome do cliente , endereço , cidade ,  cep e email são obrigatórios e deverão ser sempre informados

Lista de ator(es):

Casos de uso identificados

  1. Exibir Clientes Cadastrados
  2. Efetuar Manutenção de clientes

Diagrama de caso de uso simplificado:

Para sobreviver no mercado você deve produzir um produto de qualidade com um preço competitivo. Não adiante trabalhar de graça e nem superestimar o preço do seu produto. Você tem que ser ágil para poder saber quanto cobrar a partir do tamanho do sistema que você vai desenvolver. Para saber o tamanho do sistema você deve realizar medições de tamanho do software a ser desenvolvido.

Uma das formas de alcançar este objetivo é realizar estimativas de tamanho, custo, esforço e qualidade de software. Geralmente esta estimativa é feita com base em um histórico de informações de experiências passadas que são usadas para embassar as tomadas de decisões feitas durante o ciclo de desenvolvimento do projeto. Para tornar tal procedimento confiável é necessário estabelecer um processo sistemático que pode ser repetido e ser usado para realizar comparações. O roteiro obtido com a sistematização destes passos se configura em uma métrica.

Dentre as métricas usadas a Análise de Pontos de Função tem obtido grande destaque nos últimos anos e vem sendo cada vez mais utilizada para estimativas de tamanho de um sistema de software com base na funcionalidade fornecida ao usuário.
"Análise de Pontos de Função-APF, ou FPA-Function Point Analysis, é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. Ponto de função é a unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a APF busca medir o que o software faz, e não como ele foi construído.

Portanto o processo de medição, ou a contagem de pontos de função, é baseada em uma avaliação padronizada dos requisitos lógicos do usuário. Este padrão está descrito pelo IFPUG em seu Manual de Práticas de Contagem.

Empiricamente as principais técnicas de estimativa de projetos de desenvolvimento de software assumem que o tamanho de um software é um vetor importante para a determinação do esforço para sua construção. Logo, saber o seu tamanho é um dos primeiros passos do processo de estimativa de esforço, prazo e custo.

Daí é importante destacar que pontos de função não medem diretamente esforço, produtividade ou custo. É exclusivamente uma medida de tamanho funcional do software. Este tamanho em conjunto com outras variáveis é que poderá ser usado para derivar produtividade, estimar esforço e custo." www.fattocs.com.br/faq.htm

Vamos então utilizar a técnica de análise de pontos de função para estimar o preço que você deverá cobrar do seu cliente para desenvolver o sistema para manutenção de clientes.

Encare a situação da seguinte forma : você foi solicitado a dar um orçamento para desenvolver o sistema e não pode demorar ou vai perder o serviço.

Você resolveu usar APF- Análise de Pontos de Função, como uma ferramenta de apoio para determinar o tamanho funcional da aplicação adotando os seguintes procedimentos:

  1. definição do escopo do sistema manutenção de clientes

  2. estimativa do tamanho funcional da aplicação

  3. estimativa do custo e esforço para desenvolvimento

Determinar o tamanho funcional do sistema a ser desenvolvido usando APF

Entidades e funções do processo de manutenção de clientes

1- Usuário (funcionário)
    - Gestão do cadastro de clientes
 
2- Cadastros
    - Clientes

A tecnologia usada no sistema para manutenção de cliente será a plataforma desktop usando a linguagem Visual Basic .NET envolvendo 3 camadas : camada de dados , camada de aplicação e camada de apresentação.

O propósito da contagem é verificar se é viável o desenvolvimento do sistema. Com a estimativa de tamanho do sistema pretende-se estimar o custo de desenvolvimento com objetivo de fornecer uma estimativa de orçamento ao cliente que solicitou o seu desenvolvimento.

Para alcançar o objetivo de estimativa de tamanho será feita uma contagem estimativa segundo o modelo proposto pelo IFPUG.

Vamos usar o processo de contagem conforme preconiza o manual do IFPUG para determinar o número de pontos por função de um projeto de software. Como não é objetivo deste artigo entrar nos detalhes do processo de contagem vou apenas descrever as etapas do processo.

Etapas do processo de contagem da APF:

A figura 2 apresenta uma visão geral dos tipos de função que são considerados na contagem da APF.(gráfico retirado de http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf )

1- Determinar o tipo de Contagem

Para o nosso caso estamos efetuando a medida de um projeto de desenvolvimento.

2- Identificar as fronteiras da aplicação

A fronteira separa o que é interno e externo a uma aplicação sendo contada. Confina os dados lógicos que são mantidos pela aplicação e ajuda na identificação dos dados lógicos que são referenciados, mas não mantidos por ela;

No nosso exemplo a aplicação manutenção de clientes é muito simples, e, portanto podemos representar a fronteira da aplicação da seguinte forma:

A fronteira da aplicação manutenção de clientes.

Nota: A aplicação não acessa nem é  acessada por programas externos.

3- Determinar Funções do tipo dado

O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que possui a seguinte estrutura:

Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas :

É um grupo lógico de dados identificável pelo usuário ? Sim.

É mantido por um processo elementar dentro da fronteira da aplicação ? Sim.

A aplicação possui somente um ALI.

Após identificar os ALI e AIE devemos classificar a função de acordo com sua complexidade funcional . Para alcançar este objetivo devemos determinar :

  1. Número de Tipos de Dados (TD) - é um campo único , reconhecido pelo usuário , não repetido
  2. Número de Tipos de Registros (TR) - é um subgrupo de tipo de dados , reconhecido pelo usuário, componente de um ALI ou AIE.

Após determinar as quantidades de tipos de dados e tipos de registros, devemos classificar a complexidade de acordo com a seguinte tabela:

  Tipos de Dados
Tipos de Registros  < 20  20 - 50  > 50
  1  Baixa  Baixa  Média
  2 - 5  Baixa  Média  Alta
  > 5  Média  Alta  Alta

Após determinar a complexidade dos arquivos , devemos calcular sua contribuição conforme a seguinte tabela:

Tipo de Função Baixa Média Alta
Arquivo Lógico Interno - ALI   7 PF   10 PF    15 PF
Arquivo de Interface Externa - AIE   5 PF    7 PF    10 PF

Determinação dos ALI

ALI - Arquivo Lógico Interno - é um grupo de dados logicamente relacionados ou de informações de controle identificáveis pelo usuário e mantido dentro das fronteiras da aplicação.

Para a aplicação todos os campos da tabela serão usados, com exceção do código do cliente, que será atribuição do sistema. O cliente visualiza portanto o conjunto de informação como um registro lógico. A aplicação apresenta portanto somente 1 Registro Lógico.

Como todos os campos da tabela serão usados pelo usuário , com exceção do CodigoCliente que será atribuição do sistema a aplicação apresenta 7 tipos de dados.

Chegamos a conclusão pela tabela ( 1 <--> 7 )  que nossa aplicação possui a definição de complexidade Baixa.

Pela tabela a contribuição será de 7 PF.

O total de pontos por função para as funções do tipo dado para a aplicação é igual a  7 PF

Determinação dos AIE

AIE - Arquivo de interface externa - é um grupo de dados logicamente relacionados que é usado pela aplicação mas sofre manutenção a partir de outra aplicação.

A aplicação não tem nenhum AIE.  Com contribuição de 0 PF.

4- Determinar as funções do tipo Transação

As funções do tipo transação representam a funcionalidade fornecida ao usuário para atender os requisitos da aplicação. São classificadas como :

  1. Entradas Externas - EE - Processa as informações e/ou dados recebidos de fora da fronteira da aplicação
  2. Saidas Externas - SE - Envia dados ou informações para fora da fronteira da aplicação
  3. Consultas Externas - CE - Envia dados ou informações de controle para fora da fronteira da aplicação.

Cada função do tipo transação deve ser classificada com relação a sua complexidade funcional em :

  1. Número de Arquivos Referenciados - AR - Um ALI lido ou mantido pela função do tipo transação ou um AIE lido pela função do tipo transação.
  2. Número de Tipos de Dado - TD -  Um campo único , reconhecido pelo usuário, não repetido.

Após determinar a quantidade de AR e TD da aplicação podemos definir a sua complexidade de acordo com as seguintes tabelas:

Tabela de complexidade para Entradas Externas:

 

Tipos de Dados
Arquivos Referenciados  < 5  5 - 15  > 15
 < 2  Baixa  Baixa  Média
   2  Baixa  Média  Alta
 > 2  Média  Alta  Alta

Tabela de complexidade para Saídas Externas e Consultas Externas:

 

Tipos de Dados
Arquivos Referenciados  < 6  6 - 19  > 19
 < 2  Baixa  Baixa  Média
 2 - 3  Baixa  Média  Alta
 > 3  Média  Alta  Alta

Determinando a quantidade de AR e TD da aplicação

Vamos criar uma tabela para indicar quais as funções do tipo transação identificada e  para cada uma delas a quantidade de AR e TD.

Função Tipo  AR  TD
Cadastro de Clientes      
 - Incluir EE      1     7
 - Alterar EE      1     7
 - Excluir EE      1     7
 - Listar SE      1     10 (*)
 - Consultar CE      1     8

(*) - além dos campos de dados estamos contando os comandos ( botão e mensagem ao usuário)

Após determinar a complexidade das funções de transação podemos calcular sua contribuição de acordo com a tabela abaixo:

Tipo de Função  Baixa  Média  Alta
Entrada Externa - EE  3 PF  4 PF  6 PF
Saída Externa - SE  4 PF  5 PF  7 PF
Consulta Externa - CE  3 PF  4 PF  6 PF

Determinando a contribuição em PF para as funções de transação da aplicação

Abaixo temos a tabela que exibe as funções do tipo Transação para a aplicação manutenção de clientes.

Função Tipo  Complexidade  PF
Cadastro de Clientes      
 - Incluir EE  Baixa   3
 - Alterar EE  Baixa   3
 - Excluir EE  Baixa   3
 - Listar SE  Baixa   4
 - Consultar CE  Baixa   3

Total dos Pontos de função para as funções de tipo transação da aplicação :  16 PF

O total geral dos pontos de função não ajustados para a aplicação é de 23 PF ( 16 + 7 )

Cálculo do fator de ajuste

O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo:

  1. COMUNICAÇÃO DE DADOS: Quando são utilizados recursos de Comunicação de Dados para o envio ou recebimento de dados e informações de controle utilizados pela aplicação;
  2. PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação;
  3. PERFORMANCE: Esta característica identifica os objetivos de performance da aplicação, estabelecidos e aprovados pelo usuário, que influenciaram (ou irão influenciar) o desenho, desenvolvimento, implantação e suporte da aplicação;
  4. UTILIZAÇÃO DO EQUIPAMENTO: Representa a necessidade de se fazer considerações especiais no desenho dos sistemas para que a configuração do equipamento não sofra degradação;
  5. VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela;
  6. ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas;
  7. EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final;
  8. ATUALIZAÇÃO "ON-LINE": Verifica o volume de arquivos lógicos internos que sofrem manutenção "on-line" e o impacto do processo de recuperação de seus dados;
  9. PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;
  10. REUTILIZAÇÃO DE CÓDIGO: Avalia se a aplicação e seu código foram especificamente projetados e desenvolvidos para serem reutilizados em outras aplicações;
  11. FACILIDADES DE IMPLANTAÇÃO: Considera o esforço gasto para o atendimento dos requerimentos de conversão de dados para a implantação da aplicação;
  12. FACILIDADE OPERACIONAL: Avalia o desenho da aplicação quanto aos requisitos estabelecidos para inicialização, "backup" e recuperação voltados à minimização da intervenção manual do operador;
  13. MÚLTIPLOS LOCAIS: Quando a aplicação for especificamente projetada e desenvolvida para ser instalada em múltiplos locais ou para múltiplas organizações;
  14. FACILIDADES DE MUDANÇAS: Quando os requisitos da aplicação prevêem o projeto e desenvolvimento de mecanismos que facilitem mudanças operacionais, tais como: capacidade de emissão de relatórios genéricos, de consultas flexíveis ou de alterações nos dados de controle do negócio (parametrização).

Cada uma destas características possui um nível de influência sobre a aplicação que pode variar em um intervalo de zero a cinco( 0 a 5):

0 - Nenhum Influência
1 - Influência Mínima
2 - Influência Moderada
3 - Influência Média
4 - Influência Significativa
5 - Grande Influência
Após determinar os níveis de influência das 14 características gerais o fator de ajuste é calculado com a seguinte fórmula:

VFA =  (Σ NI  x 0,01) + 0,65

Onde:
 Σ  - é o somatório dos níveis de influência para as 14 características
NI - NI é nível de influência  

Para ver cada uma das características sua definição e os valores para cada nível de influência clique neste link: 14 características

Uma sugestão de perguntas que podemos fazer para poder calcular o nível de influência pode ser:

Calculando a influência de cada característica ao nosso sistema temos:

Característica Influência Característica Influência
1 4 8 0
2 0 9 2
3 0 10 0
4 3 11 4
5 0 12 3
6 0 13 0
7 0 14 4
                                       Valor Total => 20

Chegamos portanto a um nível de influência igual a 20.

Calculando o fator de ajuste pela fórmula   VFA =  ( ΣNI  x 0,01) + 0,65  temos:

VFA = (20 x 00,1 ) + 0,65 = 0,85  O valor do fator de ajuste é igual a 0,85.

Portanto o número de pontos de função para o projeto é obtido da seguinte forma:

NPF = PFNA * VFA   onde temos    NPF = 27 * 0,85  = 22,95

Onde : NPF - número de pontos de função   PFNA - No de pontos de função Não ajustados   VFA - valor do fator de ajuste

Finalmente conseguimos obter uma medida para o tamanho da nossa aplicação. O seu tamanho é igual a 22,95 PF.

Lembre-se que é apenas uma estimativa pois estamos na fase inicial de desenvolvimento do projeto.

E agora o que eu faço com isto ???  Qual o preço de um ponto de Função ?

Os Pontos de Função (PF) são apenas uma unidade de medida , assim como eu digo que um projeto tem 100 PF , eu também digo que um imóvel tem 100 m2 de área construída.

Quanto tempo vai demorar para construir e quanto vai custar um imóvel com 100 m2 de área construída ?

Depende. Existem diversos fatores que podem afetar uma estimativa de prazo e custo.

Da mesma forma eu posso dizer : Quanto tempo vai demorar para construir e quanto vai custar o projeto "Cadastro de Clientes" com 100 PF ?

A resposta é a mesma.  Percebeu o significado dos Pontos de Função ?

Se um construtor fosse estimar o prazo e o preço do imóvel com 100 m2 de área a construir , ele poderia basear sua estimativa na sua experiência passada.  Fazendo uma comparação do imóvel atual com algum imóvel similar já construído. Diversos fatores teriam que ser levando em conta :  se é um imóvel térreo ou sobrado , quantos quartos , banheiros , janelas , portas , tipo de telhado , tipo de acabamento , tipo de material hidráulico , elétrico , se há a necessidade de aterro , etc..

Quanto mais informações o construtor puder obter melhor será a sua estimativa , ou seja, mais próxima da realidade ela será.

O prazo e valor correto , com 100 % de acerto , somente poderá ser estimado no final da construção.

Tudo o que foi dito para o construtor pode ser feito para um desenvolvedor ou gerente de projetos. Desta forma o ambiente de desenvolvimento , a experiência da equipe no projeto , os métodos usados no processo de software , etc. todos estes fatores influenciam na medida de estimativa a ser obtida.

Da mesma forma , ou ainda de forma ainda mais subjetiva, devido a natureza do projeto de software, um projeto de software requer primeiro que se determine o seu tamanho através de um processo de medição para que uma unidade de medida possa ser definida e usada para comparações com projetos similares.

Ao usar a APF se você obter uma medida de tamanho em pontos de função de um projeto mas tem uma base histórica de medidas para comparação terá que buscar isto em tabelas prontas de outras empresas afim de subsidiar sua estimativa.

A resposta para a pergunta referente a estimativa do projeto de software poderia ser dada da seguinte forma:

Como o esforço total necessário para executar um determinado projeto pode ser dado pela fórmula abaixo:

Esforço Total (horas ) =  PF * índice de produtividade

e os índices de produtividade podem ser expressos em Horas/PF ou PF/mês .

Para a aplicação em questão que possui 22,95 PF , se o índice de produtividade da empresa ou equipe for de 10 horas/PF o esforço demando seria algo em torno de 229,5 horas.

Assim o projeto demandaria 229 horas para ser desenvolvido.

Com base nisto , sabendo o valor pago pela empresa o custo seria de fácil obtenção.

Obs: O preço de um ponto de função varia conforme o trabalho exigido para sua construção e de seus subprodutos.

Conclusão:

Quanto mais cedo você começar a medir e a formar uma base histórica de medidas baseada em um métrica reconhecida e de fácil utilização (A APF é amparada pelo IFPUG e partir de 2002 passou a condição de padrão internacional através da norma ISSO/IEC 20926) , mais cedo você vai poder realizar estimativas com maior precisão.

Referências:

[CMMI02] CMMI Product Team. CMMI for Software Engineering, Version 1.1, Staged Representation (CMMI-SW, V1.1, Staged). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002. Available from World Wide Web: http://www.sei.cmu.edu/publications/documents/02.reports/02tr029.html

[IFPUG99] THE INTERNATIONAL FUNCTION POINT USERS GROUP, Princeton Junction. Function Point Counting Practices Manual release 4.1. [s.l.], 1999.

[ISO01] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15939; Software Engineering – Software Measurement Process. [s.l.], 2001.

[PAULK93] PAULK, Mark C. et al. Key Practices of the Capability Maturity Model SM , Version 1.1. (CMU/SEI-93-TR-025). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993. Available from World Wide Web: http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.025.html

GQM - http://sel.gsfc.nasa.gov/website/exp-factory/gqm.htm – acessado em 21 de setembro de 2005-09-21

HAZAN - Implatanção de um Processo de medições de software - http://www.bfpug.com.br/Artigos/Palestra%20_Medicoes%20Claudia%20Hazan.pdf

José Carlos Macoratti