FATTO

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

Erro relativo:

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.

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

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.

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.

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.

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)

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.

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.

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.

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

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)

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.

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

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.

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

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.

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

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

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

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

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

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.

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)

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.

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.

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

É 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

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

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.

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.

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

É 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

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

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

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

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]

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

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.

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.