FATTO

Método padrão para medir software do ponto de vista do usuário pela quantificação da funcionalidade fornecida. 

Objetivos da Técnica:
- Medir a funcionalidade que o usuário solicita e recebe;
- Medir o desenvolvimento e manutenção de software de forma independente da tecnologia utilizada para sua implementação.

Objetivos do Processo de Contagem:
- Ser simples o suficiente para minimizar o esforço adicional envolvido no processo de medição;
- Uma medida consistente entre vários projetos e organizações.

Benefícios da APF:
- Determinar o tamanho de um pacote adquirido;
- Ajudar usuários a determinar os benefícios de um pacote para sua organização;
- Suportar a análise de produtividade e qualidade;
- Estimar custos e recursos para desenvolvimento e manutenção de software;
- Fator de normalização para comparação de software.

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

Um conjunto coeso de procedimentos automatizados e dados suportando um objetivo de negócio. Consiste de um ou mais componentes, módulos ou subsistemas. Frequentemente usado como sinônimo para Sistema, Sistema de Informação ou Sistema Aplicativo.

Exemplos: contas a pagar, contas a receber, folha de pagamento, compras, produção de loja, controle de linha de montagem, radar de busca aérea, acompanhamento de alvo, acionamento de armas, programação de aeronaves e reservas de passagens.

Um arquivo de interface externa (AIE) é um grupo de dados ou de informações de controle logicamente relacionados, reconhecido pelo usuário, referenciado pela aplicação que está sendo contada, porém, mantido dentro da fronteira de uma outra aplicação. A intenção primária de um AIE é armazenar dados referenciados através de um ou mais processos elementares dentro da fronteira da aplicação que está sendo contada. Isto significa que um AIE contado para uma aplicação deve ser um ALI em outra aplicação.

Exemplo: o sistema de Faturamento possui algumas transações que precisam buscar informações relativas a cliente. Mas os dados de cliente não são mantidos pelo sistema de Faturamento, isto é responsabilidade do sistema de Cadastro. Logo para o sistema de Faturamento, Cliente é um AIE. Para o sistema de Cadastro, Cliente é um ALI.

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)

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).

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.

É um arquivo lógico interno (ALI) lido ou mantido pela função transacional ou um arquivo de interface externa (AIE) lido pela função transacional. Também chamado de Arquivo Lógico Referenciado (ALR) ou File Type Referenced (FTR). A complexidade funcional de cada EE, SE e CE é atribuída com base no número de arquivos referenciados e tipos de dados.

Regras para contagem:
- Conte um arquivo referenciado para cada arquivo lógico interno (ALI) mantido pela transação;
- Conte um arquivo referenciado para cada arquivo lógico interno (ALI) ou arquivo de interface externa (AIE) lido pela transação;
- Caso o arquivo lógico interno (ALI) seja tanto lido quanto mantido, conte-o apenas uma vez.

Observações:
- Mesmo que o ALI/AIE tenha vários tipos de registro, conte-o apenas uma vez.
- NÃO conte o mesmo arquivo mais de uma vez, mesmo que seja utilizado pela transação várias vezes.
- NÃO conte arquivos que não são classificados como ALI ou AIE (exemplo: entidades do tipo dados de código).

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.

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

Características Gerais do Sistema (CGS) ou General System Characteristics (GSC)

São um conjunto de 14 questões que avaliam a complexidade geral da aplicação. São elas:

1. Comunicação de Dados
2. Processamento Distribuído
3. Performance
4. Configuração Intensamente Utilizada
5. Volume de Transações
6. Entrada de Dados On-Line
7. Eficiência do Usuário Final
8. Atualização On-Line
9. Processamento Complexo
10. Reusabilidade
11. Facilidade de Instalação
12. Facilidade de Operação
13. Múltiplos Locais
14. Facilidade de Mudança

Copiar instruções ou dados de computador de um armazenamento externo para armazenamento interno. (IEEE)

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 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.

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).

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)

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.

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

Uma das 14 características gerais de sistema que descreve em que nível o processamento lógico ou matemático influencia o desenvolvimento da aplicação. Os seguintes componentes estão presentes:
- Controle sensível e/ou processamento específico de segurança da aplicação. Exemplo: processamento especial de auditoria.
- Processamento lógico extensivo. Exemplo: sistema de gestão de crédito.
- Processamento matemático extensivo. Exemplo: sistema de otimização de corte de tecidos.
- Muito processamento de exceção resultando em transações incompletas que devem ser processadas novamente. Exemplo: transações incompletas em ATM em função de problemas de teleprocessamento, falta de dados ou de edição.
- Processamento complexo para manipular múltiplas possibilidades de entrada e saída, como, por exemplo, multimídia, ou independência de dispositivo. Exemplo: sistema de extrato de conta corrente que emite via terminal de retaguarda, auto-atendimento, web, e-mail, telefone celular.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Nenhum dos itens anteriores.
1 - Qualquer um dos itens anteriores.
2 - Quaisquer dois itens anteriores.
3 - Quaisquer três itens anteriores.
4 - Quaisquer quatro itens anteriores.
5 - Todos os cinco itens anteriores.

É a classificação da complexidade de um tipo de função em particular. Ela pode assumir o valor de baixa, média ou alta. Para as funções tipo dados, a complexidade é determinada pelo número de tipos de registro (registros lógicos referenciados - RLR - ou record element types - RET) e tipos de dado (dados elementares referenciados - DER - ou data element types - DET). Para as funções de tipo transacional, a complexidade é determinada pelo número de arquivos referenciados (arquivos lógicos referenciados - ALR - ou file type referenced - FTR) e tipos de dados.

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”.

Uma das 14 características gerais de sistema que descreve o grau pelo qual a aplicação comunica-se diretamente com o processador. Os dados ou informações de controle utilizados pela aplicação são enviados ou recebidos por meio de recursos de comunicação. Terminais conectados localmente à unidade de controle são considerados recursos de comunicação. Protocolo é um conjunto de convenções que permite a transferência ou intercâmbio de informações entre dois sistemas ou dispositivos. Todos os links de comunicação necessitam de algum tipo de protocolo.

Pontue o seu nível de influência de acordo com as seguintes orientações:
0 - A aplicação é puramente batch ou uma estação de trabalho isolada.
1 - A aplicação é puramente batch, mas possui entrada de dados ou impressão remota.
2 - A aplicação é batch, mas possui entrada de dados e impressão remota.
3 - A aplicação possui entrada de dados on-line, front-end de teleprocessamento para um processamento batch ou sistema de consulta.
4 - A aplicação é mais que um front-end, mas suporta apenas um tipo de protocolo de comunicação.
5 - A aplicação é mais que um front-end, e suporta mais de um tipo de protocolo de comunicação.

Uma das 14 características gerais de sistema que descreve o grau pelo qual as restrição de recursos computacionais influenciam o desenvolvimento da aplicação. Uma configuração operacional altamente utilizada, necessitando de considerações especiais de projeto, é uma característica da aplicação. Por exemplo, o usuário deseja executar a aplicação em um equipamento já existente ou comprado e que será altamente utilizado.

A questão que deve ser avaliada para esta CGS é "O quanto a infra-estrutura influencia o projeto?"

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Não existem restrições operacionais implícitas ou explícitas nos requisitos.
1 - Existem restrições operacionais, mas são menos restritivas que uma aplicação típica. Não há esforço especial necessário ao atendimento dessas restrições.
2 - Existem restrições operacionais, mas são restrições típicas da aplicação. Há esforço especial necessário ao atendimento dessas restrições.
3 - Existem requisitos específicos de processador para uma parte específica da aplicação.
4 - Restrições operacionais explícitas necessitam de um processador dedicado ou utilização pesada do processador central.
5 - Adicionalmente, existem limitações nos componentes distribuídos da aplicação.

Consulta Externa (CE) ou External Inquiry (EQ)

É um processo elementar cuja principal intenção é apresentar informação ao usuário pela simples recuperação de dados ou informações de controle de arquivos lógicos interno (ALIs) ou arquivos de interface externa (AIEs). Sua lógica de processamento não contém fórmula matemática ou cálculos, não cria dado derivado, não mantém arquivo lógico interno (ALI) durante o processamento nem modifica o comportamento do sistema.

É 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.

É 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

A contribuição dos tipos de função (ALI,AIE,EE,SE,CE) aos pontos de função da aplicação.

O termo "contribuição" no que se refere a uma função em especial ou ao conjunto de funções de determinado tipo corresponde à quantidade de pontos de função apurados para essa função em especial ou ao conjunto de funções de determinado tipo, conforme o caso.

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.

IEEE: (1) Ler dados de uma fonte, mantendo os dados da fonte intactos e gravar os mesmos dados em outro local em forma física que pode diferir daquela da fonte. Por exemplo,  copiar dados de um disco magnético para uma fita magnética. (2) O resultado de um processo de cópia como acima exposto. Por exemplo, uma cópia de um arquivo de dados.

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.

Informação criada a partir da transformação de dados existentes. Requer outro processamento além da recuperação, conversão, formatação e/ou edição direta de dados de um arquivo lógico interno e/ou arquivo de interface externa.

Ou seja, é um dado que é apresentado pelo sistema mas que não está armazenado em um arquivo lógico. Ele é criado através de uma lógica de processamento (cálculo, por exemplo). Exemplos de dados derivados podem ser todos os campos apresentados pela transação que sejam resultados de cálculos: total de faturamento, tempo médio entre falhas, % de participação do produto X nas vendas, etc.

São dados que surgem em resposta a requisitos técnicos como: normalização de dados, garantia da integridade de dados ou melhoria na entrada de dados. Em geral são dados essencialmente estáticos que possuem poucos atributos, tipicamente código e descrição. Estes dados não contribuem para o tamanho funcional do software, nem as transações que os manipulam.

Também chamados de dados de lista ou dados de tradução. O usuário nem sempre os especifica diretamente. Em outros casos, são identificados pelo desenvolvedor em resposta a um ou mais requisitos técnicos do usuário. Provêem uma lista de valores válidos que um atributo descritivo pode assumir. Tipicamente seus atributos são código, descrição e/ou outros atributos "padrão" descrevendo o código; por exemplo, abreviação padrão, datas de início e término de vigência, dados de auditoria, ativo/inativo, etc.

A diferença chave entre Dados de Código e Dados de Referência é:
• Com Dados de Código, você pode substituir um pelo outro sem alteração do significado dos Dados do Negócio. Ex.: Código do Aeroporto X Nome do Aeroporto, Código da Cor X Descrição da Cor.
• Com Dados de Referência você não pode substituir (Ex.: Código do Imposto com a Alíquota do Imposto)

Características lógicas incluem:
• Dados são obrigatórios para a área funcional, mas armazenado opcionalmente como um arquivo de dados
• Geralmente não identificado como parte dos requisitos funcionais; ele é normalmente identificado como parte do projeto para satisfazer requisitos técnicos
• Às vezes mantidos pelo usuário (normalmente por um usuário do suporte)
• Armazena dados para padronizar e facilitar atividades do negócio e transações do negócio
• Essencialmente estático – apenas alterado em resposta a mudanças na maneira que o negócio é operado
• Transações do negócio acessam Dados de Código para melhorar casos de entradas de dados, melhorar a consistência de dados, garantir integridade de dados, etc.

Quando reconhecido pelo usuário:
• As vezes é considerado como um grupo do mesmo conjunto de dados
• Pode ser mantido utilizando a mesma lógica de processamento

Características físicas incluem:
• Possui campos chave e normalmente um ou dois atributos apenas
• Tipicamente tem um número estável de registros
• As vezes desnormalizado e armazenado em uma tabela física com outros Dados de Código
• Pode ser implementado de diferentes formas (ex.: em uma aplicação separada, dicionário de dados ou diretamente no código fonte do software)

Exemplos:
• Dados estáticos
• Dados de substituição (código + descrição)
• Dados de domínio de valores

Representam dados centrais para o negócio da aplicação. Representam um percentual significativo das entidades identificadas. Possuem muitos atributos e são dados dinâmicos (regularmente lidos e mantidos). Devem ser contados como ALIs ou AIEs.

Também chamados de core user data ou objetos de negócio.

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)
• Mantido pelo usuário (normalmente por um usuário do negócio)
• Armazena Dados Centrais do Usuário para auxiliar as transações do negócio
• Muito dinâmico – operações normais do negócio fazem com que eles sejam regularmente referenciados, incluídos, alterados e excluídos rotineiramente.
• Reportável

Características físicas incluem:
• Têm campos chave e normalmente muitos atributos
• Podem ter de zero a infinitos registros

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

Um problema o qual, sem sua correção, poderia causar uma aplicação falhar ou produzir um resultado incorreto. A falta de uma funcionalidade que foi especificada ou solicitada também é considerada um defeito.

É 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)

É 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.

É 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.

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).

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.

Uma das 14 características gerais de sistema que descreve em que nível considerações sobre fatores humanos e facilidade de uso pelo usuário final influenciam o desenvolvimento da aplicação. As funções interativas fornecidas pela aplicação enfatizam um projeto para o aumento da eficiência do usuário final. O projeto inclui:
- Auxílio para navegação, como, por exemplo, teclas de função, saltos, menus gerados dinamicamente;
- Menus;
- Ajuda on-line e documentação;
- Movimentação automática de cursor;
- Paginação;
- Impressão remota por meio de transações on-line;
- Teclas de função predefinidas;
- Tarefas em lote submetidas a transações on-line;
- Seleção feita por posicionamento de cursor em tela de dados;
- Uso intenso de vídeo reverso, brilho, cores e outros indicadores;
- Documentação impressa das transações;
- Interface de mouse;
- Janelas pop-up;
- Utilização de número mínimo de telas para executar uma função do negócio;
- Suporte a dois idiomas (conte como quatro itens);
- Suporte a mais de dois idiomas (conte como seis itens).

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Nenhum dos itens anteriores.
1 - De um a três dos itens anteriores.
2 - De quatro a cinco dos itens anteriores.
3 - Seis ou mais dos itens anteriores, mas não existem requisitos específicos do usuário associados à eficiência.
4 - Seis ou mais dos itens anteriores e requisitos explícitos sobre a eficiência para o usuário final são fortes o bastante para necessitarem de tarefas de projeto que incluam fatores humanos, como, por exemplo, minimizar o número de toques no teclado, maximizar padrões de campo e uso de modelos.
5 - Seis ou mais dos itens anteriores e requisitos explícitos sobre a eficiência para o usuário final são fortes o bastante para necessitarem do uso de ferramentas e processos especiais para demonstrar que os objetivos foram alcançados.

É um tipo de entidade que contém atributos que completam a descrição de um relacionamento de muitos-para-muitos entre duas outras entidades. É usada para associar duas ou mais entidades como uma forma de definir o relacionamento de muitos-para-muitos. Entidades deste tipo são geralmente criadas por quem modela os dados para resolver algumas das regras de negócio necessárias à associação entre duas entidades distintas.

É um tipo de entidade que descreve complementarmente uma ou mais características de uma outra entidade. Por definição, é uma extensão lógica de uma outra entidade. Normalmente os dados em entidades deste tipo são contados como um tipo de registro da entidade que descreve.

Entidade por si só não significativa ou importante para o negócio sem a presença de outras entidades, de modo que:

• uma ocorrência da entidade X deve estar ligada a uma ocorrência da entidade Y, e
  
• a exclusão de uma ocorrência da entidade Y resulta na exclusão de todas as ocorrências relacionadas da entidade X.

Uma entidade que é significativa e importante por si mesma sem a presença de outras entidades.

Uma subdivisão de uma entidade. Um subtipo herda todos os atributos e relacionamentos de sua entidade pai e pode ter atributos e relacionamentos únicos adicionais.

Uma das 14 características gerais de sistema que descreve o grau pelo qual dados são informados pela execução de transações interativas.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Todas as transações são processadas em lote.
1 - De 1% a 7% das transações são entradas de dados on-line.
2 - De 8% a 15% das transações são entradas de dados on-line.
3 - De 16% a 23% das transações são entradas de dados on-line.
4 - De 24% a 30% das transações são entradas de dados on-line.
5 - Mais de 30% das transações são entradas de dados on-line.

Entrada Externa (EE) ou External Input (EI)

É um processo elementar que processa dados ou informação de controle que vêm de fora da fronteira da aplicação. Sua principal intenção é manter um ou mais arquivos lógicos internos (ALIs) e/ou modificar o comportamento do sistema.

Erro relativo:

O escopo da contagem define o conjunto de requisitos funcionais do usuário a ser incluído na contagem de pontos de função. Ele:

• Define um (sub)conjunto do software sendo medido;
• É determinado pelo próposito da contagem de pontos de função;
• Identifica quais funções serão incluídas na contagem de pontos de função
  para fornecer respostas relevantes ao propósito da contagem;
• Pode incluir mais de uma aplicação.

O escopo da contagem de:

• Uma contagem de projeto de melhoria inclui todas as funcionalidades incluídas, alteradas e excluídas. As fronteiras das aplicações impactadas permanecem as mesmas. A funcionalidade das aplicações refletem o impacto das funções sendo incluídas, alteradas e excluídas.
• Uma contagem de projeto de desenvolvimento inclui todas as funções impactadas (construídas ou customizadas) pelas atividades do projeto.
• Uma contagem de pontos de função da aplicação pode incluir, dependendo do propósito, apenas as funções sendo usadas pelo usuário ou todas as funcionalidades entregues. Por exemplo, fornecer um pacote como a solução de software.

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.

Uma das 14 características gerais de sistema que descreve em que nível a aplicação foi especificamente desenvolvida para facilitar a mudança de sua lógica de processamento ou estrutura de dados.
As seguintes características podem ser válidas para a aplicação:
- São fornecidos mecanismos de consulta flexível, que permitem a manipulação de pedidos simples; por exemplo, lógica de e/ou aplicada a apenas um arquivo lógico (conte como um item).
- São fornecidos mecanismos de consulta flexível, que permitem a manipulação de pedidos de média complexidade; por exemplo, lógica de e/ou aplicada a mais de um arquivo lógico (conte como dois itens).
- São fornecidos mecanismos de consulta flexível, que permitem a manipulação de pedidos complexos; por exemplo, lógica de e/ou combinadas em um ou mais arquivos lógicos (conte como três itens).
- Dados de controle do negócio são mantidos pelo usuário por meio de processos interativos, mas as alterações só têm efeito no próximo dia útil.
- Dados de controle do negócio são mantidos pelo usuário por meio de processos interativos, e as alterações têm efeito imediato (conte como dois itens).

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Nenhum dos itens anteriores.
1 - Qualquer um dos itens anteriores.
2 - Quaisquer dois itens anteriores.
3 - Quaisquer três itens anteriores.
4 - Quaisquer quatro itens anteriores.
5 - Todos os cinco itens anteriores.

Uma das 14 características gerais de sistema que descreve em que nível a aplicação atende a alguns aspectos operacionais, como: inicialização, segurança e recuperação. A aplicação minimiza a necessidade de atividades manuais, como montagem de fitas, manipulação de papel e intervenção manual pelo operador.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Não foi estabelecida pelo usuário outra consideração que não os procedimentos de segurança normais.
1-4 Um, alguns ou todos os seguintes itens são válidos para a aplicação. Selecione todos aqueles que sejam válidos. Cada item tem um valor de um ponto, a exceção de onde seja citado o contrário.
   - Procedimentos de inicialização, salvamento e recuperação foram fornecidos, mas é necessária a intervenção do operador.
   - Procedimentos de inicialização, salvamento e recuperação foram fornecidos, e não é necessária a intervenção do operador (conte como dois itens).
   - A aplicação minimiza a necessidade de montagem de fitas.
   - A aplicação minimiza a necessidade de manipulação de papel.
5 - Aplicação projetada para operação não-assistida. Isto é, não é necessário nenhuma intervenção do operador para operar o sistema, que não seja a inicialização e término da aplicação. A recuperação automática de erros é uma característica da aplicação.

É a interface conceitual que delimita o software que será medido e o usuário. A fronteira:

• Define o que é externo à aplicação
• Indica a fronteira entre o software que está sendo medido e o usuário
• Atua como uma ‘membrana’ através da qual os dados processados pelas transações (EEs, SEs e CEs) passam para dentro e para fora da aplicação
• Envolve os dados lógicos mantidos pela aplicação (ALIs)
• Auxilia na identificação dos dados lógicos referenciados mas não mantidos pela aplicação (AIEs)
• Depende da visão externa do negócio do usuário da aplicação. É independente de considerações de técnicas e/ou implementação

As seguintes regras devem ser válidas:

• A fronteira é determinada com base na visão do usuário. O foco está no que ele pode entender e descrever;
• A fronteira entre aplicações afins é baseada em diferentes áreas funcionais como visto pelo usuário, não em considerações técnicas;
• A fronteira inicial já estabelecida para a aplicação ou aplicações sendo modificadas não é influenciada pelo escopo da contagem.

Nota: Pode haver mais de uma aplicação incluída no escopo da contagem. Nesse caso, múltiplas fronteiras da aplicação deverão ser identificadas. Quando a fronteira não está bem definida (como no início da análise), ela deverá ser posicionada da forma mais exata possível.

Dicas para identificação da fronteira:

• Utilize as especificações externas do sistema ou obtenha um fluxo do mesmo e desenhe a respectiva fronteira, destacando as partes internas e as externas à aplicação.
• Verifique como os grupos de dados estão sendo mantidos.
• Identifique as áreas funcionais, alocando certos tipos de objetos da análise (tais como entidades ou processos elementares) a uma área funcional.
• Observe dados de medição correlatos, tais como esforço, custo e defeitos. As fronteiras consideradas para os pontos de função e para os outros dados de medição devem ser as mesmas
• Entrevistar os especialistas no assunto para auxiliar na identificação da fronteira.

Um artefato que ilustra bem o conceito de fronteira é o diagrama de contexto.

A funcionalidade fornecida ao usuário para atender requisitos por dados internos e externos. São Arquivos Lógicos Internos (ALI) ou Arquivos de Interface Externa (AIE).

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).

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 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.

Conjunto de registros afins tratados como uma unidade. Uma réplica exata de um outro objeto, arquivo ou tabela geralmente criada pelo uso de um utilitário. Por exemplo, um arquivo poderia consistir de um conjunto de registros de faturamento.

Dados que influenciam um processo elementar da aplicação sendo contada. Especifica o que, quando ou como os dados devem ser processados. Em resumo, são parâmetros.

Exemplos:

"O que" - determinado campo especifica que o cálculo da parcela deve contemplar somente o valor vencido ou o valor corrigido com juros e multa.

"Quando" - uma enquete pode ter um fechamento automático (votações finalizadas) definido pela data de encerramento da mesma.

"Como" - durante a compra de uma passagem aérea, o cliente informa em um campo como deseja receber a confirmação da compra: por e-mail, torpedo (SMS) ou fax.

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.

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

É 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.

Múltiplos arquivos com os mesmos elementos de dados consolidados em um único arquivo. (IEEE)

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).

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

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.

A modificação de um produto de software, executada depois da entrega,  para manter o produto de software utilizável em um ambiente alterado ou em vias de alteração. Manutenção adaptativa fornece as melhorias necessárias para acomodar mudanças no ambiente no qual um produto de software deve operar. Estas mudanças são as que devem ser feitas para manter-se em dia com o ambiente alterado. Por exemplo, o sistema operacional deve sofrer upgrade e algumas mudanças devem ser feitas para acomodar o novo sistema operacional.

A medição do tamanho funcional para manutenção é aplicável a um subconjunto de manutenções adaptativas. Isso inclui as funcionalidades do software adicionadas, alteradas ou excluídas bem como as funcionalidades do software fornecidas para converter dados e atender outros requisitos de conversão (ex.: relatórios de conversão).

Um projeto de melhoria é um projeto para desenvolver e entregar manutenção adaptativa.

Modificação reativa de um produto de software executada depois da entrega para corrigir problemas identificados. A modificação corrige os produtos de software para satisfazer os requisitos. (ISO/IEC 14764:2006)

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.

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).

Mudanças no hardware ou software executadas para prevenir defeitos futuros ou falhas. Por exemplo, reestruturar programas ou dados para aumentar a facilidade de manutenção e para prevenir defeitos. 

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

É 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.

Uso de uma métrica para atribuir um valor (o qual pode ser um número ou categoria), obtido a partir de uma escala, a um atributo de uma entidade [ISO/IEC 9126-1]. Geralmente, no processo de melhoria, medidas obtidas nesta atividade são combinadas para gerar métricas. 

A medição de pontos de função de uma aplicação ou projeto em particular.

Contagem de Pontos de Função é a atividade de aplicar as regras do método de Medição de Tamanho Funcional (FSM) do IFPUG para medir o tamanho funcional de uma aplicação ou projeto.

NOTA: Existem três tipos de contagem de Pontos de Função: Aplicação, Projeto de Desenvolvimento e Projeto de Melhoria

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

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.

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

Uma das 14 características gerais de sistema que descreve em que nível a aplicação foi especificamente projetada, desenvolvida e suportada para diferentes ambientes de hardware e software.

Pontue o nível de influência de acordo com as seguintes orientações:
0 - Os requisitos do usuário não consideram a necessidade de mais de um usuário/local de instalação.
1 - Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi projetada para operar apenas nos mesmos ambientes de hardware e de software.
2 - Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi projetada para operar em apenas ambientes de hardware e de software similares.
3 - Necessidade de múltiplos locais foi considerada no projeto, e a aplicação foi projetada para operar em ambientes diferentes de hardware e de software.
4 - Adicionalmente aos itens 1 ou 2, plano de suporte e documentação são fornecidos e testados para suportar a aplicação em múltiplos locais.
5 - Adicionalmente ao item 3, plano de suporte e documentação são fornecidos e testados para suportar a aplicação em múltiplos locais.

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).

O processo pelo qual qualquer estrutura de dados pode ser transformada por um projetista de banco de dados em um conjunto de relações normalizadas que não têm grupos repetidos.

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.

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 das 14 características gerais de sistema que descreve o grau pelo qual considerações de tempo de resposta e performance de throughput influenciam o desenvolvimento da aplicação. Os objetivos estabelecidos ou aprovados pelo usuário, em termos de tempo de resposta ou taxa de transações, influenciam (ou influenciará) o projeto, desenvolvimento, instalação e suporte da aplicação.

A questão que deve ser avaliada para esta CGS é "Quão rápida deve ser a aplicação e o quanto isto influencia o projeto?"

Pontue o seu nível de influência de acordo com as seguintes orientações:
0 - O usuário não estabeleceu nenhum requisito especial sobre performance.
1 - Requisitos de performance e projeto foram estabelecidos e revisados, mas nenhuma ação em especial foi tomada.
2 - Tempo de resposta ou taxa de transações são críticos durante as horas de pico. Não é necessário nenhum projeto especial para a utilização de CPU. O limite para o processamento é o dia seguinte.
3 - Tempo de resposta ou taxa de transações são críticos durante todas as horas de trabalho. Não foi necessário nenhum projeto especial para a utilização de CPU. O limite de processamento é crítico.
4 - Adicionalmente, requisitos especificados pelo usuário são exigentes o bastante para que tarefas de análise de performance sejam necessárias na fase de projeto.
5 - Adicionalmente, ferramentas de análise de performance devem ser utilizadas nas fases de projeto, desenvolvimento e/ou implementação para que os requisitos de performance do usuário sejam atendidos.

É a unidade de medida da APF que representa o tamanho funcional de um software.

Uma das 14 características gerais de sistema que descreve o grau pelo qual a aplicação transfere dados entre seus componentes.

Pontue de acordo com as seguintes orientações:
0 - A aplicação não participa da transferência de dados ou processamento de funções entre os componentes do sistema.
1 - A aplicação prepara dados para processamento pelo usuário final em outro componente do sistema, como planilhas eletrônicas ou banco de dados.
2 - Dados são preparados para transferência, então são processados em outro componente do sistema (não para processamento pelo usuário final).
3 - Processamento distribuído e transferência de dados são feitos on-line e em apenas uma direção.
4 - Processamento distribuído e transferência de dados são feitos on-line e em ambas as direções.
5 - O processamento de funções é executado dinamicamente no componente mais apropriado do sistema. 

É a menor unidade de atividade significativa para o usuário, completa e que deixa o negócio da aplicação em um estado consistente. Pode ser classificado em entrada externa (EE), saída externa (SE) e consulta externa (CE). Também chamado de transação.

Para que um processo elementar seja único, ou seja, diferente de qualquer outro, ao menos um dos três itens abaixo deve ser ocorrer:

- conjunto de tipos de dados diferentes de outra transação;

- conjunto de arquivos referenciados diferentes de outra transação;

- lógica de processamento diferente de outra transação

Fornecer uma resposta para um problema de negócio. Determina o tipo e o escopo da contagem. Influencia o posicionamento da fronteira da aplicação.

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

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.

O processo de recriar um conjunto de dados para fazê-lo atualizado e em sincronia com a sua fonte original. 

A correção de defeitos que resultaram de erros no projeto externo, projeto interno ou código. Exemplos são a falta de funções que não resultem na falha da aplicação  (erro de projeto externo) ou erros que resultem em situações de exceção não previstas (erro de código).

Subconjunto dos requisitos do usuário especificando o que o software deverá fazer em termos de tarefas e serviços.

NOTA

Os Requisitos Funcionais do Usuário incluem, mas não estão limitados a:
— transferência de dados (por exemplo: Receber dados de entrada de cliente, Enviar sinal de controle);
— transformação de dados (por exemplo: Calcular juros bancários, Derivar temperatura média);
— armazenamento de dados (por exemplo: Armazenar pedido de cliente, Registrar temperatura ambiente ao longo do tempo);
— recuperação de dados (por exemplo: Listar empregados atuais, Recuperar posição de aeronave).

Requisitos do usuário que não constituem Requisitos Funcionais do Usuário incluem, mas não estão limitados aos seguintes:
— restrições de qualidade (por exemplo: usabilidade, confiabilidade, eficiência e portabilidade);
— restrições organizacionais (por exemplo: locais para operação, hardware-alvo e conformidade com os padrões);
— restrições ambientais (por exemplo: interoperabilidade, segurança e privacidade);
— restrições de implementação (por exemplo: linguagem de desenvolvimento, prazo para entrega).

[ISO/IEC 14143-1:2007, definition 3.8]

• 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)

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.

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.

Saída Externa (SE) ou External Output (EO)

É um processo elementar cuja principal intenção é enviar dados ou informações de controle para fora da fronteira da aplicação. Sua lógica de processamento deve conter pelo menos uma fórmula matemática ou cálculo, ou criar dados derivados, manter um ou mais arquivos lógicos internos (ALI) e/ou alterar o comportamento do sistema.

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.

Um dos dois tipos de subgrupos para um tipo de registro (registro lógico referenciado - RLR - ou record element type - RET). Subgrupo obrigatórios significa que o usuário deve usar um dos subgrupos durante um processo elementar que crie uma instância dos dados.

É aquele que o usuário tem a opção de não usar durante um processo elementar que inclui ou cria uma instância dos dados.

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.

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.

Campo único reconhecido pelo usuário e não repetido. Também chamado Dado Elementar Referenciado (DER) ou Data Element Type (DET).

Regras para contagem em um arquivo lógico:

- Conte um DER para cada campo único, reconhecido pelo usuário e não repetido, mantido ou recuperado pela função de dados durante a execução de todos os processos elementares no escopo da contagem.

Regras para contagem em uma transação:

- conte um tipo de dado para cada campo que entra ou sai pela fronteira da aplicação, na direção do usuário, e que seja necessário à execução do processo elementar.

- conte um tipo de dado para a capacidade de especificar uma ação

- conte um tipo de dado para a capacidade da transação de emitir uma mensagem para o usuário (seja de erro, aviso, alerta, confirmação, etc).

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.

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

Os cinco serviços de informação básicos fornecidos ao usuário pela aplicação e identificados na análise de pontos de função. São entradas externas, saídas externas, consultas externas, arquivos lógicos internos e arquivos de interface externa.

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.

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

É 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)

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.

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.

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.