Por que eu devo ler este artigo:Existem atualmente várias técnicas de medição de software com prós e contras. A Análise de Pontos de Função é uma métrica internacional de software padronizada com objetivo principal de descobrir o tamanho de um software. Ela tem como foco principal a visão do usuário, ou seja, somente são contados os requisitos funcionais (requisitos de negócio) e, por isso, não leva em consideração a linguagem de programação. Este artigo trata da teoria e da prática da contagem de pontos de função. Ele apresenta de forma clara e sucinta a parte teórica da contagem de pontos de função, além de apresentar dois exemplos práticos, sendo um deles envolvendo o uso do Scrum. Este artigo é útil para profissionais da área de Tecnologia da Informação que necessitam saber do tamanho de uma demanda e/ou funcionalidade, principalmente para calcular o prazo e custo de um projeto.

Uma métrica de software é uma característica de um sistema, documentação ou processo que pode ser objetivamente medido. Alguns exemplos são: tamanho do software, número de defeitos relatados, número de casos de teste por caso de uso, número de pessoas necessárias para desenvolver um módulo do sistema, entre outros. Métricas podem ser classificadas em de controle ou de previsão. As de controle são geralmente associadas a processos de software como: esforço médio e tempo necessário para corrigir um defeito. Já métricas de previsão estão diretamente relacionadas ao sistema em si. Exemplos são: complexidade ciclomática, linhas de código, tamanho das classes, entre outros.

Métricas de previsão podem influenciar a tomada de decisão dos gestores do projeto. Os gerentes usam métricas de processo para decidir se devem ser feitas alterações no processo. Já as de previsão são usadas para estimar o esforço necessário para construir ou fazer alterações no software. Neste artigo, quando nos referirmos a métricas de software, estaremos tratando das classificadas como de previsão.

Métricas de software são indicadores resultantes de atividades de medição do processo de desenvolvimento de software que auxiliam no gerenciamento de projetos. Existem diversas formas de se medir um sistema. Umas mais, outras menos eficazes e eficientes. Umas causam mais, outras menos impacto na equipe. Algumas podem ser aplicadas ao longo de todo o processo de software. Como exemplo, podemos citar: linhas de código (LOC em inglês), que medem o tamanho de um produto. Outro exemplo de métrica é o esforço homem-mês ou homem-hora (1 h/m é o volume de trabalho realizado por uma pessoa em um mês ou uma hora dependendo do acordado entre as partes). Rotatividade de mão de obra (a alta rotatividade afeta negativamente os projetos de uma empresa pois a cada novo funcionário, leva-se um tempo para adaptação e entendimento dos detalhes relevantes do projeto em que está inserido) também pode ser considerada uma métrica. Outros exemplos são ponto de caso de uso e ponto de função, sendo esse último uma das métricas mais usadas e difundidas.

A análise por ponto de função tem como principal objetivo medir a funcionalidade do sistema tendo como base a visão do usuário, de acordo com as seguintes características:

  • É independente da tecnologia utilizada;
  • Auxilia a produção de resultados consistentes;
  • Baseia-se na visão do usuário;
  • Tem significado para o usuário final;
  • Utiliza-se de estimativas;
  • Passível de automação;
  • Dificuldade por possuir relativa subjetividade por refletir a visão do usuário.

A análise por ponto de função (APF) é uma das técnicas mais usadas para se medir projetos de desenvolvimento de software. Seu principal objetivo é estabelecer um tamanho considerando a(s) funcionalidade(s) implementada(s), sempre sob o ponto de vista do usuário. A medida independe da tecnologia utilizada e/ou da linguagem de programação em que a(s) funcionalidade(s) foi implementada.

A APF foi criada em 1977 pelo funcionário da IBM Allan J. Albrecht. Ela basicamente quantifica as funções contidas no software em termos significativos para os usuários. A medida tem relação direta com os requisitos funcionais (requisitos de negócio). Apesar de muito popular, ela também é bastante criticada por diversos autores que acreditam que ela não seja uma medida objetiva.

Contagem de PF

Para se contar ponto de função é necessário seguir alguns passos, como mostra a Figura 1. O primeiro deles é determinar o tipo de contagem. É nesse passo que é determinado o que será medido, o tipo de contagem a ser usado para medir o projeto de software, tanto no processo como no produto. Três tipos de contagens são possíveis:

  • Contagem de projeto de desenvolvimento;
  • Contagem de projeto de melhoria (manutenção);
  • Contagem de aplicação.

De maneira simplificada, o primeiro mede a funcionalidade fornecida aos usuários finais quando o projeto estiver pronto, no momento de sua instalação. Essa contagem também abrange conversão de dados necessários para implantação do software.

O segundo mede as modificações para uma aplicação já existente, o que inclui as funções incluídas, alteradas e excluídas do sistema pelo projeto, além das funções de conversão de dados. É importante lembrar que, sempre após uma contagem de manutenção e sua implantação, o número de pontos de função da aplicação deve ser atualizado de acordo com as alterações feitas na funcionalidade. Isso tem como objetivo manter a contagem de pontos de função (CPF) da aplicação sempre atualizada.

O terceiro e último tipo de contagem mede a funcionalidade fornecida ao usuário pela aplicação instalada e em produção para que a atual funcionalidade tenha uma medida.

Passos da contagem de Pontos de Função
Figura 1. Passos da contagem de Pontos de Função

O segundo passo para a contagem é a identificação do escopo da contagem e a fronteira da aplicação. É nesse passo que são delimitados o escopo do sistema objeto da avaliação e a sua fronteira. É nesse momento que são identificados todos os relacionamentos do sistema e/ou da funcionalidade que está sendo contada com o seu exterior (o que está fora da fronteira) e são identificadas as pertinências dos dados e os processos suportados pelo sistema/funcionalidade que está sendo contado (a).

A fronteira da aplicação define o que é externo para a aplicação. É a interface conceitual entre a aplicação e os usuários externos. O escopo define um conjunto ou subconjunto de software de tamanho conhecido.

O terceiro e quarto passos são a contagem das funções de dados e das funções de transação. São nesses passos que são contados os pontos de função não ajustados. Nessas etapas são consideradas:

  • Funções de dados:
    o Arquivos Lógicos Internos (ALIs);
    o Arquivos de Interface Externa (AIEs);
  • Funções de Transação:
    o Entradas Externas (EE);
    o Saídas Externas (SE);
    o Consultas Externas (CE).

Os ALIs são grupos de dados logicamente relacionados, ou informações de controle, mantidos dentro da fronteira da aplicação. A principal função de um ALI é agrupar os dados mantidos por um ou mais processos elementares da aplicação que está sendo contada. A Tabela 1 mostra a contribuição de ALI para a CPF.

Grau de Complexidade Funcional

Pontos de Função

Baixo

7

Médio

10

Alto

15

Tabela 1. Contribuição de ALI

Os AIEs são grupos de dados logicamente relacionados, ou informações de controle, referenciados pela aplicação, mas mantidos dentro da fronteira da outra aplicação. A principal função de um AIE é agrupar logicamente dados referenciados por um ou mais processos elementares da aplicação. Isso significa que um AIE contado para uma aplicação deverá ser um ALI em outra. A Tabela 2 mostra a contribuição de AIE para a CPF.

Grau de Complexidade Funcional

Pontos de Função

Baixo

5

Médio

7

Alto

10

Tabela 2. Contribuição de AIE

A complexidade dos ALIs e AIEs (Tabela 3) se dá em função do número de RLRs (tipos de registro elementar) e dos DERs (tipo de dado elementar).

1 a 19 DERs

20 a 50 DERs

51 ou mais DERs

1 RLR

Baixa

Baixa

Média

2 a 5 RLRs

Baixa

Média

Alta

6 ou mais RLRs

Média

Alta

Alta

Tabela 3. Complexidade de ALI e AIE

As EEs são processos elementares que processam dados ou informações de controle que vêm de fora das fronteiras da aplicação. A função primária de uma EE é manter um ou mais ALIs e/ou alterar o comportamento do sistema.

A complexidade da EE é dada em função do número de ALRs (tipos de arquivos referenciados ou arquivos referenciados) e dos DERs (tipo de dado elementar), como mostra a Tabela 4.

1 a 4 DERs

5 a 15 DERs

16 ou mais DERs

0 a 1 RLR

Baixa

Baixa

Média

2 RLRs

Baixa

Média

Alta

3 ou mais RLRs

Média

Alta

Alta

Tabela 4. Complexidade de EE

As SEs são processos elementares que enviam dados ou informações de controle para fora das fronteiras da aplicação. A função primária de uma SE é apresentar informação para o usuário através de processamento lógico exceto em recuperação de dados ou informação de controle. O processamento lógico tem que possuir pelo menos uma fórmula matemática ou cálculo, gerar dados derivados, manter um ou mais ALIs ou alterar o comportamento do sistema. A Tabela 5 mostra a contribuição de SE para a CPF.

Classificação de Complexidade Funcional

Pontos de Função

Baixa

4

Média

5

Alta

7

Tabela 5. Tabela de Contribuição de SE

As CEs, como são conhecidas as Consultas Externas, são processos elementares que enviam dados ou informações de controle para fora das fronteiras da aplicação. A função primária de uma CE é apresentar informação para o usuário através da recuperação de dados ou informação de controle. O processamento lógico não deve possuir fórmula matemática ou cálculo e não deve gerar dados derivados. Nenhum ALI é mantido durante o processo ou o comportamento do sistema é alterado. A Tabela 6 mostra a contribuição de CE para a CPF.

A complexidade da SE e CE (Tabela 7) se dá em função do número de ALRs (tipos de arquivos referenciados ou arquivos referenciados) e dos DERs (tipo de dado elementar).

Classificação de Complexidade Funcional

Pontos de Função

Baixa

3

Média

4

Alta

6

Tabela 6. Tabela de Contribuição de EE e CE

1 a 5 DERs

6 a 19 DERs

20 ou mais DERs

0 a 1 RLR

Baixa

Baixa

Média

2 a 3 RLRs

Baixa

Média

Alta

4 ou mais RLRs

Média

Alta

Alta

Tabela 7. Complexidade de SE e CE

O quinto passo para a contagem é o cálculo do Fator de Ajuste. Estes fatores estão relacionados com as características da aplicação. Ele é responsável pela correção das distorções da etapa anterior (cálculo das funções de dados e das funções de transação) e baseia-se nas características gerais do sistema onde são relacionados 14 itens que determinam o valor do nível de influência de cada um desses itens do dimensionamento do sistema. São eles:

1. Comunicação de dados;

2. Processamento distribuído;

3. Performance;

4. Configuração do equipamento;

5. Volume de transações;

6. Entrada de dados on-line;

7. Interface com o usuário;

8. Atualização on-line;

9. Processamento complexo;

10. Reusabilidade;

11. Facilidade de implantação;

12. Facilidade operacional;

13. Múltiplos locais;

14. Facilidade de mudanças (Flexibilidade).

Um peso, que varia de 0 (sem influência) a 5 (forte influência) deve ser atribuído a cada uma das GSCs – Características Gerais do Sistema, e a soma deles resulta no valor do TDI – Grau Total de Influência. As características são resumidas no fator de ajuste, que, quando aplicado, corrige o valor de Pontos de Função não ajustados em cerca de +-35%, criando o Ponto de Função Ajustado.

O sexto e último passo da contagem é o cálculo dos pontos de função ajustados. É nesse passo que é feita a correção de possíveis distorções ocorridas durante o cálculo dos pontos de função não ajustados, aproximando as medidas da situação real. Normalmente e contratualmente, os fatores de ajuste são iguais a 1 para que não influenciem nos pontos de função não ajustados.

A métrica de software e o SCRUM

O Scrum é uma metodologia ágil para a gestão, planejamento e desenvolvimento de projetos de software. Ele não define nem impõe ferramentas e/ou técnicas de desenvolvimento de sistemas, mas mostra como os times devem trabalhar em ambientes com frequentes alterações e com o surgimento de novos requisitos.

Ele é dividido em ciclos (normalmente mensal, porém é parametrizável de acordo com a necessidade de cada empresa) chamados sprints. São nesses sprints que são realizadas as atividades do projeto. Os papéis e responsáveis pelo Scrum são os Product Owners (POs), Scrum Masters e Scrum Team. Suas práticas são realizadas por etapas conhecidas como Planning Meeting, Daily Scrum, Review Metting e Retrospective (todas feitas para cada sprint). Também existem o Product Backlog e o Sprint Backlog, onde são listadas as atividades do projeto e serão separadas por sprints.

A velocidade de um profissional de TI pode ser calculada a partir do número de horas que a equipe utiliza para implementar um trabalho equivalente a um Ideal Day, que corresponde à quantidade de trabalho que um profissional (gerente, analista, desenvolvedor, teste, etc.) consegue finalizar em um dia de trabalho. Para isso, o cálculo é feito utilizando a seguinte fórmula:

DE = IED / 1 – IED_REAL%

Onde:

  • DE = quantidade de dias estimada para concluir a tarefa;
  • IED = prazo necessário para implementar a funcionalidade (prazo definido pela própria equipe);
  • IED_REAL% = percentual que indica a estimativa de quanto tempo do dia o desenvolvedor ficará dedicado à implementação da funcionalidade.

Como aplicar isso em um caso real? Veja o Exemplo 2 da parte prática deste artigo.

Contagem Prática

Para uma visão mais prática do que foi apresentado até agora, serão feitas duas contagens: uma para exemplificar a técnica de análise por pontos de função com uma tela simples de cadastro de cliente e outra para exemplificar o relacionamento do Scrum à métrica de software através de uma tela de relatório de cadastro de cliente.

Exemplo 1 – Cadastro de Cliente

Este exemplo irá considerar a tela de Cadastro de Cliente apresentada na Figura 2.

Wireframe de cadastro de clientes
Figura 2. Wireframe de cadastro de clientes

Vamos passar por todos os passos somente a título de exemplificação.

1. Tipo da contagem

  • Projeto de Melhoria (considerando que é o desenvolvimento de uma nova funcionalidade de aplicação já existente);

2. Identificação da fronteira da aplicação

  • Cadastro de Clientes (Figura 2);

3. Contar Função de Dados

ALI -> Cliente -> Inclusão

DER (Nome, Tipo de Cliente – Física ou Jurídica, CNPJ, E-mail, Logradouro, Nº do Logradouro, Complemento, CEP, Cidade e UF);

Total de DER -> 10

RLR (Cliente);

Total RLR -> 1

4. Contagem das funções de transação

  • Cadastrar Cliente

EE (mantém ALI e/ou altera o comportamento do sistema);

ALR (Cliente – ALI contado no passo anterior);

Total ALR -> 1

DER (Nome, Tipo de Cliente – Física ou Jurídica, CNPJ, E-mail, Logradouro, Nº do Logradouro, Complemento, CEP, Cidade e UF);

Total DER -> 10

5. Contagem de PF não ajustado

Extraídas a complexidade e o total de pontos de função tanto das funções de dados (ALIs e/ou AIEs) quanto das funções de transação (EEs, CEs e/ou EEs), é preciso calcular os pontos de função não ajustados através da multiplicação do número de funções identificadas para uma determinada complexidade por sua contribuição. Por fim, soma-se todos os pontos de função encontrados. Vejamos nosso exemplo do Cadastro de Cliente na Figura 3.

Total de Pontos de Função Não Ajustados
Figura 3. Total de Pontos de Função Não Ajustados

6. Cálculo do Fator de Ajuste

O cálculo do Fator de Ajuste é feito para cada aplicação, para cada contagem. É importante lembrar que os fatores mostrados estão relacionados com características da aplicação e podem influenciar no seu tamanho:

1. Comunicação de dados ->1

2. Processamento distribuído ->2

3. Performance ->3

4. Configuração do equipamento ->4

5. Volume de transações ->5

6. Entrada de dados on-line ->1

7. Interface com o usuário ->2

8. Atualização on-line ->3

9. Processamento complexo ->4

10. Reusabilidade >1

11. Facilidade de implantação ->1

12. Facilidade operacional ->2

13. Múltiplos locais ->3

14. Facilidade de mudanças (Flexibilidade) ->3

Fator de Ajuste = (NI * 0,01) + 0,65

Onde NI é o somatório da pontuação atribuída (no nosso exemplo, 35);

Fator de Ajuste = (35*0,01) + 0,65 = 1

Cálculo dos Pontos de Função Ajustados

Após os cálculos dos pontos de função não ajustados e do fator de ajuste, será calculado o ponto de função ajustado de acordo com a fórmula:

PF ajustado = (PF não ajustado + PF incluído + PF alterado atual – PF alterado anterior – PF excluído) X Fator de ajuste atual

Onde:

  • PF ajustado: total de pontos de função da aplicação;
  • PF não ajustado: total de pontos de função não ajustados da aplicação antes do projeto de manutenção (calculados na Figura 3);
  • PF incluído: total de pontos de função não ajustados das funções que foram incluídas na aplicação;
  • PF alterado atual: total de pontos de função não ajustados das funções que foram modificadas (após a modificação);
  • PF alterado anterior: total de pontos de função não ajustados das funções que foram modificadas na aplicação (antes da modificação);
  • PF excluído: total de pontos de função não ajustados das funções que foram removidas da aplicação;
  • Fator de ajuste atual: valor do ajuste detectado após o projeto de manutenção (calculado no item anterior).

Pelo nosso exemplo:

PF ajustado = (13 + 0 + 0 – 0 – 0) X 1
  PF ajustado = 13

Dessa forma, teríamos que o tamanho da funcionalidade a ser implementada seria de 13 pontos de função.

Exemplo 2 – Relatório de Cadastro de Cliente

Para este exemplo (Figura 4), será utilizado apenas um sprint (definido com o prazo de 1 mês) para implementar a funcionalidade e entregá-la com teste concluído. A solicitação foi feita para um sistema já existente e em produção no cliente.

Será utilizado um Product Owner (PO) do cliente, um especialista que irá levantar, descrever e priorizar os requisitos e regras a serem desenvolvidos. O PO, junto com o stakeholder, definiu apenas 10 requisitos e o Scrum Master (SM) junto com o PO fizeram a lista de prioridades gerando, assim, o Product Backlog.

A previsão da métrica Ideal Day foi feita para cada atividade utilizando uma escala (0.25, 0.5, 0.75, 1, 1.25 e 1.5, etc.), por isso a definição de se fazer a funcionalidade em somente um sprint. Em codificação teremos 14,5 dias. O restante dos dias será para documentação, testes e eventuais correções de bugs encontrados pela equipe de testes.

Para o cálculo do Ideal Day, foi definido que seria considerada uma produtividade de 90% em uma jornada de 8 horas diárias. Com esses valores definidos, a fórmula apresentada na seção “A métrica de software e o SCRUM” foi aplicada e obteve-se:

  DE = 14,5/(1-90)
  DE = 16,29 dias

A métrica de Planning Poker foi aplicada e, após várias discussões, resultou em um total de 125 pontos. Para cada ponto, foi estimado um valor em hora com um total de 220 horas. O PO e o SM começaram o sprint e foi iniciada uma análise das informações discutidas na reunião de Sprint Planning Meeting para realizar a contagem de pontos de função. É muito importante lembrar que a análise, a contagem (feita normalmente pelo analista de requisitos, podendo muitas vezes exercer o papel de Scrum Master e/ou PO) e o desenvolvimento são realizados em paralelo e, portanto, enquanto a contagem de PF está sendo feita o desenvolvimento também está em andamento.

Relatório de Cadastro de Cliente
Figura 4. Relatório de Cadastro de Cliente

Agora veremos como ficaria nossa estimativa utilizando a APF. Por questões didáticas, a contagem será passada por todos os passos, como no Exemplo 1:

1. Tipo da contagem

  • Projeto de Melhoria (considerando que é o desenvolvimento de uma nova funcionalidade de aplicação já existente);

2. Identificação da fronteira da aplicação

  • Relatório de Cadastro de Clientes (Figura 4);

3. Contar Função de Dados

O ALI não é contado, pois já foi contado na contagem do cadastro do Cliente.

4. Contagem das Funções de Transação

  • Emitir Relatório de Cliente

CE (sem cálculo matemático nem dados derivados);

ALR (Cliente – ALI contado no cadastro do cliente);

Total ALR ->1

DER (Número do cliente, Nome completo do cliente, Telefone – com DDD, Celular – com DDD, Cidade, UF, Nome de Contato, Data de geração do relatório);

Total DER ->8

5. Contagem de PF não ajustado

Extraídas a complexidade e o total de pontos de função tanto das funções de dados (ALIs e/ou AIEs) quanto das funções de transação (EEs, CEs e/ou EEs), é preciso calcular os pontos de função não ajustados. Vejamos nosso exemplo do Relatório de Cadastro de Cliente na Figura 5.

Total de Pontos de Função Não Ajustados
Figura 5. Total de Pontos de Função Não Ajustados

6. Cálculo do Fator de Ajuste

O cálculo do fator de ajuste é feito para cada aplicação, para cada contagem. É importante lembrar que os fatores mostrados estão relacionados com características da aplicação e podem influenciar no seu tamanho:

1. Comunicação de dados ->1

2. Processamento distribuído ->4

3. Performance ->2

4. Configuração do equipamento ->3

5. Volume de transações ->4

6. Entrada de dados on-line ->1

7. Interface com o usuário ->2

8. Atualização on-line ->4

9. Processamento complexo ->4

10. Reusabilidade ->1

11. Facilidade de implantação ->1

12. Facilidade operacional ->2

13. Múltiplos locais >3

14. Facilidade de mudanças (Flexibilidade) ->4

Fator de Ajuste = (NI * 0,01) + 0,65

Onde NI é o somatório da pontuação atribuída (no nosso exemplo, 36)

Fator de Ajuste = (36*0,01) + 0,65 = 1,01

7. Cálculo dos Pontos de Função Ajustados

Após os cálculos dos pontos de função não ajustados e do fator de ajuste, será calculado o ponto de função ajustado de acordo com a fórmula apresentada no Exemplo 1:

Pelo nosso exemplo:

  PF ajustado = (3 + 0 + 0 – 0 – 0) X 1,01
  PF ajustado = 3,03

Dessa forma, teríamos que o tamanho da funcionalidade a ser implementada seria de 3,03 pontos de função.

Podemos concluir que o ponto de função é uma métrica focada no usuário (qualquer pessoa ou coisa que se comunica ou interage com o software a qualquer momento). O Scrum, por outro lado, foca basicamente na definição do prazo segundo informado pelo desenvolvedor e pode variar de um para outro. Dessa forma, seu uso não pode ser uma base para definição de prazo e/ou custo para a gerência.

O foco da contagem de PF é a visão do usuário, portanto somente são contados os Requisitos Funcionais, aqueles percebidos e reconhecidos por ele. Eles descrevem o que o software deverá fazer em termos de tarefas e serviços. O foco da estimativa do Scrum leva em consideração quanto tempo o profissional irá gastar para implementar, documentar e testar determinada funcionalidade.

Muitos profissionais de TI (desenvolvedores, gerentes, etc.) criticam a análise por pontos de função devido à abrangência da contagem. Mesmo assim, ela é uma métrica muito difundida, padronizada e uma das mais utilizadas atualmente. E o principal, não leva em consideração nem a linguagem de programação nem o “feeling” do profissional no tempo de desenvolvimento, como muitas outras estratégias.

Podemos concluir também que as contagens de PF foram bastante diferentes das obtidas através da técnica apresentada do Scrum, pois a estimativa do Ideal Day foi muito superior ao calculado pela APF. Contudo, é possível realizar uma junção das duas técnicas, onde poderia ser estimada a complexidade, levando em consideração as estimativas feitas pelos desenvolvedores, e o tamanho, levando em consideração a visão do usuário.

Links Úteis

Saiba mais ;)

  • Engenharia de Software:
    Engenharia de software é uma área da computação voltada à especificação, desenvolvimento, manutenção e criação de sistemas de software, com a aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade.
  • Gestão de Projeto:
    Neste guia você encontrará o conteúdo que precisa para saber como gerenciar projetos de software. Confira abaixo a sequência de posts que te guiarão do básico ao avançado em Gestão de Projetos.
  • Scrum:
    Com o aumento das exigências dos clientes e prazos cada vez mais curtos, encontrar opções para possibilitar o projeto, implementação e implantação de um sistema com mais qualidade e em menos tempo é fundamental.

Referências

[1] IFPUG. (2010). Function Point Counting Practices Manual Release 4.1.3. Princeton Junction.

[2] Martins, J. C. (2001). Técnicas para Gerenciamento de Projetos de Software. Florianópolis: Brasport Editora.

[3] Zanatta, A. L. (2004). XScrum: uma proposta de extensão de um Método Ágil para gerência e desenvolvimento de requisitos visando a adequação ao CMMI. Florianópolis.

[4] Engenharia de Software: Os paradigmas Clássico Orientado a Objetos – 7ª edição, Stephen R. Schach, Mc Graw Hill, 2010.

[5] Análise por Pontos de Função: uma técnica para dimensionamento de sistemas de Informação – Raquel Dias.