FATTO

Arquivo Lógico Interno (ALI) ou Internal Logical File (ILF)

É um grupo logicamente relacionado de dados ou informações de controle, identificados pelo usuário, mantido dentro da fronteira da aplicação. Sua principal intenção é armazenar dados mantidos pela execução de um ou mais processos elementares da aplicação sendo contada.

Grupo lógico de dados permanentes, vistos da perspectiva do usuário. É um arquivo lógico interno (ALI) ou um arquivo de interface externa (AIE).

Esforço para manter uma aplicação executando conforme suas especificações, geralmente sem modificar sua funcionalidade (ou contagem de pontos de função). Inclui reparo, melhorias menores, conversão, atividade de suporte ao usuário e manutenção preventiva. Atividades incluem remoção de defeitos (veja reparo), atualização de hardware ou software (veja conversão), otimização ou melhoria de qualidade (veja manutenção preventiva) e suporte ao usuário.

Como um nome, um número que atribui valor relativo. Alguns exemplos podem incluir volume, altura, pontos de função ou esforço. Como um verbo, verificar ou avaliar pela comparação com um padrão.

Uma das 14 características gerais de sistema que descreve o grau pelo qual arquivos lógicos internos são atualizados de forma on-line. 

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Não há nenhuma atualização on-line.
1 - Existe a atualização on-line de um a três arquivos. Volume de atualização é pequeno e a recuperação é fácil.
2 - Existe a atualização on-line de quatro ou mais arquivos. Volume de atualização é pequeno e a recuperação é fácil.
3 - A atualização da maioria dos arquivos internos é on-line.
4 - Adicionalmente, a proteção contra a perda de dados é essencial e foi especialmente projetada e programada no sistema.
5 - Adicionalmente, o alto volume de processamento torna necessária a análise do custo do processo de recuperação. São incluídos procedimentos altamente automatizados com um mínimo de intervenção do operador.

Modificação de um produto de software depois da entrega para detectar e corrigir falhas latentes no produto de software antes que ele manifeste estas falhas. Manutenção perfectiva fornece melhorias para usuários, melhorias de documentação de programas e recodificação para melhorar a performance do software, manutenibilidade e outros atributos do software. Contrastar com : Manutenção adaptativa e manutenção corretiva. (ISO/IEC 14764:2006).

Qualquer requisito especificamente solicitado pelo usuário para completar um processo elementar, como validações, algorítmos, cálculos, leitura ou manutenção de um arquivo.

Deve – A transação deve obrigatoriamente executar este tipo de lógica de processamento
Deve* – A transação deve executar pelo menos uma das lógicas de processamento classificadas como deve*
Pode – A transação pode executar este tipo de lógica de processamento, mas não é obrigatório
Não – A transação não pode executar este tipo de lógica de processamento

Um Tipo de Registro Elementar é um subgrupo de dados reconhecido pelo usuário dentro de uma função de dados. Pode ser um subgrupo opcional ou subgrupo obrigatório. Também chamado de registro lógico referenciado - RLR ou record element type - RET. A complexidade funcional de cada arquivo lógico é definida com base no número de tipos de dado (DET) e tipos de registro (RET) associados a ele.

No contexto de modelagem de dados, é um grupo de itens de dados relacionados que são tratados como uma unidade.

Existem para suportar regras de negócio para a manutenção de Dados de Negócio. Representam um pequeno percentual das entidades identificadas. Possuem poucos atributos e são dados pouco dinâmicos. Devem ser contados como ALIs ou AIEs.

Por exemplo, em uma aplicação de folha de pagamento ele seria o dado armazenado sobre as alíqüotas de imposto de renda na fonte para cada faixa salarial e sua data de vigência.

Características lógicas incluem:
• Obrigatório para a operação da área funcional do usuário
• Identificável pelo usuário (normalmente por um usuário do negócio)
• Normalmente mantido pelo usuário (normalmente por um usuário administrativo)
• Normalmente criado quando a aplicação é instalada pela primeira vez e mantido intermitentemente
• Armazena os dados para auxiliar nas atividades centrais do usuário
• Pouco dinâmico – ocasionalmente altera em resposta a mudanças no ambiente das áreas funcionais, processos funcionais externos e/ou regras de negócio.
• Transações processando Dados de Negócio freqüentemente necessitam acessar os Dados de Referência

Características físicas incluem:
• Têm campos chave e poucos atributos
• Normalmente pelo menos um registro ou um número limitado de registros

Uma das 14 características gerais de sistema que descreve em que nível a aplicação e seu código foram especificamente projetados, desenvolvidos e suportados para serem utilizados em outras aplicações.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Não há código reutilizável.
1 - Código reutilizável é utilizado na aplicação.
2 - Menos de dez por cento do código fonte da aplicação foi construído levando em consideração o uso em mais de uma aplicação.
3 - Dez por cento ou mais do código fonte da aplicação foi construído levando em consideração o uso em mais de uma aplicação.
4 - A aplicação foi especificamente empacotada e/ou documentada para fácil reutilização. Ela é customizada pelo usuário no nível de código.
5 - A aplicação foi especificamente empacotada e/ou documentada para fácil reutilização. Ela é customizada pelo usuário por meio de manutenção de parâmetros.

Funcionalidade adicional que não foi originalmente especificada nos requisitos do projeto, porém é identificada conforme o escopo vai sendo melhor esclarecido e as funções definidas.

Nível Total de Influência (NTI) ou Total Degree of Influence (TDI)

A soma dos níveis de influência (DI) das 14 características gerais de sistema (GSC).

Funcionalidade fornecida ao usuário para processar dados pela aplicação. São definidas como entradas externas (EE), saídas externas (SE) e consultas externas (CE).

Qualquer pessoa ou coisa que se comunica ou interage com o software em qualquer momento.

O termo reconhecido pelo usuário refere-se a requisitos definidos para processos e/ou grupos de dados que foram acordados e entendidos tanto pelo(s) usuário(s) quanto pelos desenvolvedor(es) de software. Por exemplo, usuários e desenvolvedores concordam que uma Aplicação de Recursos Humanos terá funcionalidade para manter e guardar informações do Funcionário na aplicação.

Representa uma descrição formal das necessidades de negócio do usuário em sua própria linguagem. Desenvolvedores traduzem a informação do usuário em linguagem de tecnologia da informação para fornecer uma solução. Ela:

- É uma descrição das funções do negócio.
- É aprovada pelo usuário.
- Pode ser usada para contar pontos de função.
- Pode variar em sua forma física (protótipos, atas de reunião, modelos, documento de visão, casos de uso, etc).

Nota 1: o termo desenvolvedor neste caso não se refere exclusivamente ao programador, mas a todos os profissionais envolvidos no processo de desenvolvimento do sistema (analista, documentador, testador, gerente de projetos, etc).

Nota 2: Um documento técnico (em linguagem de TI) gerado pelo desenvolvedor pode ser usado para contar pontos de função se for possível extrair do mesmo os requisitos funcionais, no entanto ele não representará a visão do usuário pois não usa a linguagem do negócio do usuário.

Indica a funcionalidade geral fornecida pela aplicação ao usuário. É um valor percentual calculado a partir do nível de influência de cada uma das 14 Características Gerais do Sistema. Pode produzir uma variação de +/- 35% no tamanho do sistema.

Uma das 14 características gerais de sistema que descreve em que nível o alto volume de transações de negócio influencia o projeto, desenvolvimento, instalação e suporte da aplicação.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Não é previsto nenhum período de pico de transações.
1 - Os baixos volumes de transações têm efeito mínimo nas fases de
projeto, desenvolvimento e instalação.
2 - O volume médio de transações tem algum efeito sobre as fases de
projeto, desenvolvimento e instalação.
3 - O alto volume de transações afeta as fases de projeto, desenvolvimento e instalação.
4 - O alto volume de transações declarado pelo usuário nos requisitos técnicos da aplicação ou no acordo de nível de serviço é suficientemente alto para requerer tarefas de análise de performance nas fases de projeto, desenvolvimento e/ou instalação.
5 - O alto volume de transações declarado pelo usuário nos requisitos técnicos da aplicação ou no acordo de nível de serviço é suficientemente alto para requerer tarefas de análise de performance e, adicionalmente, utilização de ferramentas de análise de performance nas fases de projeto, desenvolvimento
e/ou instalação.

Uma das 14 características gerais de sistema que descreve em que nível a conversão de ambientes preexistentes influencia o desenvolvimento da aplicação. Um plano e/ou ferramentas de conversão e instalação foram fornecidos e testados durante a fase de teste do sistema.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - O usuário não definiu considerações especiais, assim como não é requerido nenhum setup para a instalação.
1 - O usuário não definiu considerações especiais, mas é necessário setup para a instalação.
2 - Requisitos de instalação e conversão foram definidos pelo usuário, e guias de conversão e instalação foram fornecidas e testadas. Não é considerado importante o impacto da conversão.
3 - Requisitos de instalação e conversão foram definidos pelo usuário, e guias de conversão e instalação foram fornecidas e testadas. É considerado importante o impacto da conversão.
4 - Além do item 2, ferramentas de instalação e conversão automáticas foram fornecidas e testadas.
5 - Além do item 3, ferramentas de instalação e conversão automáticas foram fornecidas e testadas.

International Software Benchmarking Standards Group (www.isbsg.org) é uma organização sem fins lucrativos responsável por criar e manter um repositório de dados históricos de projetos de TI com o intuito de ajudar a melhorar a gestão de TI no mundo.

Certified Function Point Specialist:

O programa de certificação CFPS - Certified Function Point Specialist - tem por objetivo reconhecer formalmente os profissionais capazes de realizar contagens de pontos de função precisas e consistentes e que também conheçam as práticas de contagem mais recentes do IFPUG.

Para ser certificado, o profissional deve ser aprovado em um exame elaborado pelo IFPUG cuja taxa de acerto mínima deve ser de 90%. Este exame consiste em aproximadamente 150 questões de múltipla escolha baseadas no seu Manual de Práticas de Contagem. A duração da prova é de 3 horas. É um exame de difícil aprovação em função do tempo disponível e também da exigência da taxa de acerto elevada, mas infelizmente o IFPUG não divulga nenhuma informação relativa à taxa de aprovação no exame.

O prazo de validade da certificação é de três anos, após o qual o profissional deve submeter-se novamente ao exame para renovação da certificação ou participar do programa de extensão de certificação (independente de ter havido alguma mudança na versão do manual). Este programa permite que se prorrogue em dois ou três anos a validade da certificação através da acumulação de créditos em diversas atividades como: realizar contagens de pontos de função, ministrar cursos, escrever artigos ou livros, participar como voluntário de algum dos comitês do IFPUG. Entretanto esta renovação somente pode ser realizada por duas vezes consecutivas, após as quais o profissional deverá obrigatoriamente submeter-se ao exame para renovar sua certificação.

Até o início de 2008 o exame de certificação era realizado em papel, com correção manual. A partir de Julho de 2008 o exame foi automatizado e pode ser aplicado por qualquer centro credenciado pela Prometric no mundo, na data agendada pelo interessado. Há a opção do exame em inglês e também em português. Para buscar a lista de centros autorizados a ministrar o exame CFPS, acesse http://www.prometric.com/IFPUG.

Não há a exigência de formação superior, comprovação de experiência com APF ou ter assistido qualquer curso para tentar a certificação. O único pré-requisito para prestar o exame CFPS é ser filiado ao IFPUG. Porém, sem uma preparação adequada, a chance de aprovação é pequena. Mesmo para o profissional que está fazendo o exame para renovar a certificação, é necessária uma preparação com estudo e exercícios. O nosso curso Preparação para o Exame CFPS foi elaborado especificamente para apoiar o candidato ao exame do IFPUG em sua jornada de preparação para a certificação (ou recertificação).

Manual de Práticas de Contagem (Counting Practices Manual) do IFPUG. Contém todas as definições e regras necessárias ao processo de contagem de pontos de função. Versão atual: 4.3.

Objetivos:

- Fornecer uma descrição clara e detalhada de como contar pontos de função;
- Promover a consistência nas contagens realizadas pelos membros do IFPUG;
- Fornecer orientação de como realizar contagens de pontos de função baseadas em artefatos das técnicas e metodologias mais populares de desenvolvimento de software e;
- Prover um entendimento comum que permita o desenvolvimento de ferramentas que forneçam suporte automático à contagem de pontos de função.

CHGA - Changed Functions After

Contagem do tamanho funcional das funções alteradas pelo projeto de melhoria, após a alteração.

Na fórmula do projeto de melhoria

EFP = ADD + CHGA + CFP + DEL

Na fórmula da aplicação após o projeto de melhoria

CHGB - Changed Functions Before

Contagem do tamanho funcional das funções alteradas pelo projeto de melhoria, antes da alteração.

AFP = (AFPB + ADD + CHGA) – (CHGB + DEL)

É a contagem de pontos de função para as funções que foram excluídas (deleted) pelo projeto de melhoria.

Na fórmula do projeto de melhoria

EFP = ADD + CHGA + CFP + DEL

Na fórmula da aplicação após o projeto de melhoria

AFP = (AFPB + ADD + CHGA) – (CHGB + DEL)

É o fator de ajuste da aplicação depois que o projeto de melhoria estiver concluído (Value Adjustment Factor of the application After).

Na fórmula do projeto de melhoria

aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)

Na fórmula da aplicação após o projeto de melhoria

aAFPA = [(AFPB + ADD + CHGA) – (CHGB + DEL)] * VAFA

É o fator de ajuste da aplicação antes do projeto de melhoria ter iniciado (Value Adjustment Factor of the application Before).

Na fórmula do projeto de melhoria

aEFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)

É também chamada de DFP - Development Fuction Point

É a contagem de pontos de função do projeto de desenvolvimento. Mede as funções fornecidas ao usuário com a primeira instalação do software entregue e também qualquer eventual função de conversão de dados.

Segundo a fórmula, DFP = (ADD + CFP).

Utilize a seguinte fórmula para calcular o tamanho funcional ajustado do Projeto de Desenvolvimento.

aDFP = (ADD + CFP) * VAF

Também conhecida como chave substituta. São campos sequenciais gerados automaticamente pelo banco de dados usados como chave primária para uma tabela, e que não têm conteúdo semântico para a aplicação nem relação com outros dados da tabela.

Ele representa todo o sistema como um único processo e é composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades externas. O diagrama é uma forma de representar o objeto do estudo, o projeto, e sua relação com o ambiente.

Um diagrama de contexto permite identificar os limites dos processos, as áreas envolvidas com o processo e os relacionamentos com outros processos e elementos externos à empresa (ex.: clientes, fornecedores).

São funções de dados ou de transação providas para converter dados e/ou fornecer outros requisitos de conversão especificados pelo usuário, como relatórios de verificação da conversão. A característica destas funções é que elas são descartadas após o seu uso, não fazendo parte da aplicação após sua instalação. Quando o sistema entra em operação, essas funções não são mais necessárias.

Na fórmula do projeto de desenvolvimento:

DFP = (ADD + CFP)

Na fórmula do projeto de melhoria:

EFP = ADD + CHGA + CFP + DEL

Onde CFP é Pontos de Funcionalidade de Conversão ou Conversion Function Points.

Exemplo: Um novo sistema de contas a pagar será implantado. Como parte do projeto de desenvolvimento desse sistema é necessário um programa que leia dados de compromissos de dois outros sistemas e, observando uma série de regras estabelecidas, atualize a base de compromissos do novo sistema. Também é necessário uma entrada de dados para complementar alguns dados que não estão disponíveis nesses sistemas. Todas essas funcionalidades são descartadas ao final da implantação do sistema.

Mudança apenas na apresentação da função ao usuário ou na forma como a entrada de dados é realizada, sem nenhuma alteração na lógica de processamento. Exemplos: mudança de ordem (posicionamento ou tabulação) dos campos na tela, formatação de rótulos ou campos (cores, tipo de fonte, tamanho da fonte, etc).

Este tipo de manutenção não é medido pelo IFPUG.

Este tipo de manutenção é medido pela NESMA.

É um documento de uso interno a uma organização que orienta as medições feitas em pontos de função em projetos de software. Sua característica é de ter um enfoque bem específico das situações que uma organização vivencia nas suas contagens de pontos de função. Seu papel é traduzir os conceitos gerais do manual de práticas de contagem do IFPUG para as situações específicas de uma organização.

É a busca das melhores práticas na indústria que conduzem ao desempenho superior. Vide definição Wikipedia: http://pt.wikipedia.org/wiki/Benchmarking

O caso de uso é um documento que representa uma unidade discreta de interação entre o usuário e o sistema, ou seja, uma sequência de ações (com possíveis variações) que produz um resultado concreto. Ele descreve uma funcionalidade que o sistema possui do ponto de vista da interação usuário (ou ator) e o sistema. Não deve conter termos técnicos da área de desenvolvimento, apenas a linguagem do usuário. Também não deve descrever como o sistema será construído.

Tipicamente um sistema terá vários casos de uso, cada um abordando uma parte do que o sistema irá fornecer ao seu usuário.

O Capability Maturity Model Integration (CMMI) é um modelo para avaliação e melhoria da maturidade dos processos de uma organização e também para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos. Criado pelo Software Engineering Institute-SEI da Carnegie Mellon University e patrocinado pelo Departamento de Defesa Norte Americano.

A ISO/IEC 14143-1 define o conceito fundamental de Medição de Tamanho Funcional (FSM - Functional Size Measurement) e descreve as normas gerais para aplicação de um método FSM. Ela NÃO fornece regras detalhadas em como fazer:
• Medição do Tamanho Funcional de software utilizando um método específico
• Utilizar o resultado obtido a partir de um método específico
• Escolha de um método específico

A ISO/IEC 14143-1 classifica os requisitos do usuário em dois subconjuntos:
• Requisitos Funcionais do Usuário
• Requisitos Não-Funcionais do Usuário

A orientação a objetos (OO) é um paradigma de análise, projeto e programação de sistemas baseado na composição e interação entre diversas unidades de software chamadas de objetos. A abordagem OO têm como meta identificar o melhor conjunto de objetos para descrever um sistema. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos. Cada objeto modelado possui um conjunto de atributos e métodos que definem o seu comportamento. Tenta-se assim tornar a construção do software mais próxima da realidade do problema que se quer tratar.

O PSM (Practical Software and Systems Measurement) é uma metodologia padrão para a implantação de processos de medição de software, compatível com o padrão ISO/IEC 15939 e com a Área de Processo “Measurement and Analysis” do CMMI. É patrocinado pelo Departamento da Defesa e pelo Exército dos EUA.

Fornece detalhamento de todos os passos e tarefas para implementação de um programa de medição de software, além de lições aprendidas, estudos de caso e um guia de implantação. Inclui também um conjunto de medidas já utilizadas com sucesso pela indústria, em categorias previamente definidas:

- Prazo e Progresso
- Recursos e Custo
- Tamanho e Estabilidade do Produto
- Qualidade do Produto
- Performance do Processo
- Eficácia da Tecnologia
- Satisfação do Cliente

É um padrão internacional para medição de processo de software. Define um modelo de informação e terminologia associadas. A ISO/IEC 15939 aborda atividades de medição, informações necessárias e análise de resultado das medições.

O Rational Unified Process - RUP (ou Processo Unificado Rational) é um modelo de processo de desenvolvimento de software iterativo. Ele é passível de ser adaptado por qualquer organização, que pode buscar os elementos do processo mais adequado à suas necessidades. A Rational é uma divisão da IBM desde 2003.

Contém a visão que os envolvidos têm do sistema a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, ela proporciona a base para requisitos mais detalhados.

Também pode conter uma especificação de requisitos formal. O documento de visão captura restrições de design e requisitos de alto nível para que o usuário possa compreender o sistema que será desenvolvido.

A Unified Modeling Language (UML) é uma linguagem de modelagem aberta que permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML.

A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz o que fazer primeiro e em seguida ou como projetar um sistema, mas ela auxilia a visualizar seu desenho e a comunicação entre objetos.

É importante distinguir entre um modelo UML e um diagrama (ou conjunto de diagramas) de UML----o último é uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente.

Também chamado de arquivo de transações ou arquivo de interface (não confundir com AIE). É um arquivo no contexto do sistema operacional, mas não no contexto da APF.

Este arquivo é fruto do processamento de uma aplicação e cujo objetivo é enviar dados para outra aplicação processar. Geralmente após seu processamento, ele é descartado.

Uma diferença entre o AIE e o arquivo de movimento é que no AIE o sistema que usa os dados pode (e geralmente é assim) consultar o mesmo dado mais de uma vez. No arquivo de movimento, uma vez que o dado é processado, o sistema nunca mais lerá este mesmo dado do arquivo de movimento.

Exemplo: um sistema de folha de pagamento, após o cálculo da folha, envia um arquivo para o banco efetuar o crédito do salário na conta dos funcionários. Este arquivo foi resultado de um processamento da folha de pagamento e será usado pelo sistema de pagamento do banco para efetuar o crédito dos salários. Após este processamento, o arquivo de movimento perde sua utilidade.

Um arquivo como esse não é contado como um AIE porque não atende à regra de ser um ALI em outra aplicação.

Veja o cenário 8 do CPM (Dados Padrão de Transação) Capítulo 3, Parte 3, Pág (3-20)

É uma transação que apresenta dados para o usuário (geralmente precedendo outra transação a ser realizada), mas que não está claramente explícita nos requisitos ou no próprio sistema (nem em opções de menu, barras de ferramenta, etc). Isto é bem comum em telas para alteração ou exclusão de registros de um arquivo. Normalmente antes da alteração ou exclusão, os dados do registro são apresentados ao usuário, e na seqüência o usuário efetua a alteração ou exclusão. Esta função relativa à consulta implícita será classificada como CE ou SE.

Quando ela é idêntica a uma consulta explícita (e muitas vezes isto é comum), apenas uma destas funções deve ser contada.

Comitê do IFPUG responsável pela manutenção e publicação do Manual de Práticas de Contagem.

ISMA (International Software Measurement and Analysis Conference) - Conferência Internacional sobre Medição e Análise de Software promovida anualmente pelo IFPUG.

Profissional responsável pelas medições, pode ser ou não certificado CFPS.

É uma representação da estrutura e relações das classes que servem de modelo para objetos. É uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.

Pode ser Projeto de melhoria, Projeto de Desenvolvimento e Aplicação.

Um percentil é uma medida da posição relativa de uma unidade observacional em relação a todas as outras. O p-ésimo percentil tem no mínimo p% dos valores abaixo daquele ponto e no mínimo (100 - p)% dos valores acima.

É uma medida de tendência central, um número que caracteriza as observações de uma determinada variável de tal forma que este número (a mediana) de um grupo de dados ordenados separa a metade inferior da amostra, população ou distribuição de probabilidade, da metade superior.

O valor que aponta para onde mais se concentram os dados de uma distribuição.

É a medida mais comum da dispersão estatística. É definido desta forma de maneira a dar-nos uma medida da dispersão que:

1. seja um número não negativo;

2. use as mesmas unidades de medida que os dados.

Adicionar funcionalidades a um sistema que não foram solicitadas pelos usuários porque o desenvolvedor acha que o sistema fica melhor com as novas funcionalidades.

É um subconjunto do modelo de implementação que descreve a representação lógica e física dos dados persistentes no sistema.

• Restrições de qualidade (por exemplo, usabilidade, confiabilidade, eficiência e portabilidade)
• Restrições Organizacionais (por exemplo, locais de operação, hardware alvo e aderência a padrões)
• Restrições Ambientais (por exemplo, interoperabilidade, segurança, privacidade e sigilo)
• Restrições de Implementação (por exemplo, linguagem de desenvolvimento, cronograma de entrega)

Linhas de código fonte (SLOC - Source Line of Code) é uma medida de software usada para medir o tamanho de um programa de software, através da contagem do número de linhas em o texto do código fonte do programa. É também expressa em KSLOC ou KLOC (milhares de linhas de código).

Tamanho do software resultante da quantificação dos requisitos funcionais do usuário (ISO 14143-1:2007).

É a medida das funcionalidades de uma aplicação que o usuário solicita / recebe, tendo como base a Visão do Usuário.

Erro relativo:

Unidade elementar dos Requisitos Funcionais do Usuário definida por e utilizada por um método FSM para fins de medição. Um Componente Funcional Básico pode ser ALI, AIE, EE, CE e SE. 

EXEMPLOS Um Requisito Funcional do Usuário poderia ser “Manter Clientes”, o qual poderia consistir dos seguintes CFBs: “Incluir um novo cliente”, “Reportar Compras do Cliente” e “Alterar Detalhes do Cliente”. Outro exemplo poderia incluir uma coleção de dados do negócio logicamente relacionados, mantida pelo software em estudo, tal como “Detalhes do Cliente”.

O certificado CFPP ( Certified Function Point Practitoner) é concedido para aqueles que não obtiveram rendimento suficiente na prova de certificação CFPS, mas o rendimento médio foi maior ou igual a 80%. Lembrando que é necessário obter ainda uma nota mínima de 70% nas três partes do exame.