Auto contido | |
---|---|
Nenhum passo anterior ou subsequente é necessário para iniciar ou concluir o(s) Requisito(s) Funcional(is) do Usuário. EXEMPLO O Requisito Funcional do Usuário estabelece que um empregado deve ser incluído e atualizado. Poderiam existir várias partes que comporiam o conjunto completo de informações do empregado. Isto pode ser representado por telas físicas, janelas ou abas distintas, tais como — Identificação do empregado, — Localização do empregado, — Informações de dependentes, — Informações de salário e — Instrução. Para incluir um empregado, uma ou mais abas devem ser preenchidas, dependendo das regras de negócio. O processo de inclusão não estará auto contido até que todas as informações obrigatórias tenham sido digitadas e recebidas pelo sistema. Para atualizar um empregado, uma ou mais abas podem ser atualizadas a qualquer momento, mas todas elas constituem passos do processo que satisfaz o Requisito Funcional do Usuário, de atualização do empregado. Incluir, alterar ou excluir informações de cada aba individual não constituem processos elementares distintos, mas sim passos de processo envolvidos na atualização de um empregado. Embora seja possível entrar com informações adicionais no registro de empregado, o conjunto total de informações é considerado parte do único processo elementar: atualizar empregado. Incluir Empregado e Atualizar Empregado seriam, cada um, um processo auto contido. | |
Estado Consistente | |
---|---|
Ponto no qual o processamento foi totalmente executado; o Requisito Funcional do Usuário foi satisfeito e nada mais há a fazer. EXEMPLO 1 O Requisito Funcional do Usuário é imprimir um cheque e marcar como paga a conta correspondente. Se somente parte do Requisito Funcional do Usuário for satisfeita (por exemplo, apenas imprimir o cheque, ou apenas marcar a conta como paga) a aplicação não estará em um estado consistente. A impressão de um cheque sem marcar a conta como paga causa uma inconsistência na aplicação, assim como marcar a conta como paga sem imprimir o cheque. EXEMPLO 2 O Requisito Funcional do Usuário é ter um processo batch que recebe um arquivo de entrada para atualizar um depósito de dados, produz um relatório de controle de produção e retorna um relatório de erros para a aplicação chamadora. O processo não ficará em um estado consistente a não ser que todas essas partes sejam concluídas. EXEMPLO 3 O Requisito Funcional do Usuário é transferir um empregado para uma nova tarefa e validar o seu nível de autorização de segurança. Para executar isto, uma solicitação em tempo real é enviada à aplicação de segurança (a qual mantém as autorizações de segurança governamentais e não a segurança da aplicação) e uma resposta deve ser recebida antes que a transferência possa ser concluída. Todos os passos são necessários para criar um estado consistente. A interação com a aplicação de segurança não é uma ação ou passo independente. Não acontece por si só e, por outro lado, a transação para transferir um empregado não fica em um estado consistente sem ela. | |
Intenção primária | |
---|---|
Intenção que é a primeira em importância. | |
Significativo | |
---|---|
Reconhecido pelo usuário e satisfazendo um Requisito Funcional do Usuário. | |
Entidade Dependente | |
---|---|
Entidade por si só não significativa ou importante para o negócio sem a presença de outras entidades, de modo que:
| |
Entidade Independente | |
---|---|
Uma entidade que é significativa e importante por si mesma sem a presença de outras entidades. | |
Manutenção Corretiva | |
---|---|
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) | |
Escopo da Contagem | |
---|---|
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:
O escopo da contagem de:
| |
CPM | |
---|---|
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; | |
Manter | |
---|---|
O termo manter refere-se à habilidade de incluir, modificar ou excluir dados a partir de um processo elementar. Exemplos incluem, mas não estão limitados a, inclusão, modificação, exclusão, carga inicial, revisão, atualização, atribuição e criação. | |
Backlog | |
---|---|
É o estoque de funções identificadas, mas ainda não atendidas. Com as informações de produtividade é possível estimar qual o esforço ou custo de eliminar esse estoque; decidir sobre a necessidade de contratação de mais profissionais; ou contratar uma empresa para atender a essa necessidade não atendida... Enfim, tomar diversas decisões que envolvem projetos na organização. | |
Valor do Fator de Ajuste | |
---|---|
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. | |
Contagem de Pontos de Função da Aplicação | |
---|---|
Contagem que fornece uma medida da funcionalidade atualmente fornecida pela aplicação ao usuário. Também é chamada de baseline ou contagem de pontos de função instalados. É inicializada quando a contagem de pontos de função do projeto de desenvolvimento é concluído. É atualizada a cada vez que a conclusão de um projeto de melhoria altera a funcionalidade da aplicação. É importante saber que contagens preliminares de pontos de função são estimativas da funcionalidade entregue. Conforme o escopo fica mais claro e as funções são desenvolvidas, é comum identificar funcionalidade adicional que não estava especificada nos requisitos originais. Este fenômeno é chamado scope creep. É essencial atualizar a contagem da aplicação mediante a conclusão do projeto. Caso a funcionalidade mude durante o desenvolvimento, a contagem de pontos de função ao final do ciclo de vida deveria refletir toda a funcionalidade entregue ao usuário. Na fórmula: AFP = ADD A fórmula para calcular o tamanho da aplicação após um projeto de melhoria é: AFP = (AFPB + ADD + CHGA) - (CHGB + DEL) Utilize a fórmula desta seção para determinar o tamanho funcional inicial ajustado para uma Aplicação. aAFP = ADD * VAF Utilize a seguinte fórmula para calcular o tamanho funcional ajustado da Aplicação após o projeto de melhoria: aAFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA | |
AFPA | |
---|---|
É a contagem de pontos de função após o projeto de melhoria. AFPA (After Function Point Analisys) é usada na fórmula do tamanho funcional da aplicação após a melhoria . AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL). Utilize a seguinte fórmula para calcular o tamanho funcional ajustado da Aplicação após o projeto de melhoria: aAFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA | |
AFPB | |
---|---|
É a contagem de pontos de função antes o projeto de melhoria (Application Function Point Before - AFPB). Essa sigla é usada na fórmula para calcular o tamanho da aplicação após a melhoria. AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL). Utilize a seguinte fórmula para calcular o tamanho funcional AJUSTADO da Aplicação após o projeto de melhoria: aAFPA = [(AFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA | |
Arquivo Lógico | |
---|---|
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 | |
---|---|
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. | |
Arquivo Referenciado | |
---|---|
É 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: Observações: | |
CHGA | |
---|---|
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 Na fórmula da aplicação após o projeto de melhoria | |
CHGB | |
---|---|
CHGB - Changed Functions Before Contagem do tamanho funcional das funções alteradas pelo projeto de melhoria, antes da alteração. Na fórmula da aplicação após o projeto de melhoria | |
Consulta Externa | |
---|---|
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. | |
DEL | |
---|---|
É a contagem de pontos de função para as funções que foram excluídas (deleted) pelo projeto de melhoria. Na fórmula do projeto de melhoria EFP = ADD + CHGA + CFP + DEL Na fórmula da aplicação após o projeto de melhoria AFP = (AFPB + ADD + CHGA) – (CHGB + DEL) | |
Entrada Externa | |
---|---|
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 de 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 | |
Nível de Influência | |
---|---|
Nível de Influência (NI) ou Degree of Influence (DI) Valor (0 a 5) que corresponde ao peso que uma característica geral de sistema possui. | |
Tipo de Dado | |
---|---|
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). | |
Tipo de Registro | |
---|---|
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. | |
VAFB | |
---|---|
É 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) | |
HM | |
---|---|
Homem-mês é uma unidade, convencionada e subjetiva, que mede a quantidade de trabalho realizada por uma pessoa durante um mês. | |
ISO/IEC 20926 | |
---|---|
Padrão de medição de tamanho funcional de software de acordo com o IFPUG e aderente à norma ISO/IEC 14143. | |
Requisito | |
---|---|
Condição ou capacidade necessária para que um stakeholder resolva um problema ou satisfaça um objetivo. Condição ou capacidade que necessita ser satisfeita ou possuída por uma solução ou componente de solução para satisfazer um contrato, padrão, especificação ou outros documentos formais impostos. Definição baseada no IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology | |
Requisitos não Funcionais | |
---|---|
Os requisitos não funcionais descrevem condições de ambiente sob as quais a solução deve funcionar, bem como atributos de qualidade da solução. Em suma, abordam COMO as funcionalidades serão oferecidas ao usuário. Usualmente são organizados em Categorias (ISO/IEC 9126, FURPS e FURPS+), pelas quais, através de suas características, fornecem o suporte para elicitação dos Requisitos Não Funcionais. A ISO/IEC 14143 não oferece definição para Requisito Não-Funcional do Usuário, mas apresenta alguns exemplos em uma nota. Exemplos de requisitos do usuário que são Requisitos Não-Funcionais do Usuário incluem, mas não estão limitados aos seguintes:
| |
Consulta implícita | |
---|---|
É 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. | |
Manutenção Cosmética | |
---|---|
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. | |
Manutenção Perfectiva | |
---|---|
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). | |
Tabela de Contribuição | |
---|---|
Nível Total de Influência | |
---|---|
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). | |
Usuário | |
---|---|
Qualquer pessoa ou coisa que se comunica ou interage com o software em qualquer momento. | |
Contribuição | |
---|---|
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. | |
Arquivo de movimento | |
---|---|
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. 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) | |
ADD | |
---|---|
É a contagem de pontos de função das funções que foram instaladas pelo projeto de desenvolvimento, na fórmula: desenvolvimento: AFPA = ADD ou É a contagem de pontos de função para as funções que foram incluídas pelo projeto de melhoria, na fórmula: projeto de melhoria: EFP = ADD + CHGA + CFP + DEL aplicação, após melhoria: AFPA = (AFPB + ADD + CHGA) - (CHGB + DEL) ADD = added | |
CFPP | |
---|---|
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. | |
Conversão de Dados | |
---|---|
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 | |
---|---|
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). | |
VAFA | |
---|---|
É 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 | |
Medição de Tamanho Funcional | |
---|---|
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: | |
Tamanho Funcional | |
---|---|
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. | |
Manutenção Adaptativa | |
---|---|
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. | |
Medição de Pontos de Função | |
---|---|
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 | |
Contagem de Pontos de Função do Projeto de Desenvolvimento | |
---|---|
É 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. | |
Contagem de Pontos de Função do Projeto de Melhoria | |
---|---|
É a atividade de aplicar as regras do método de Medição de Tamanho Funcional (FSM) do IFPUG para medir o tamanho funcional de um projeto de melhoria.
Mede as modificações em uma aplicação existente que inclui, altera e/ou exclui funções do usuário entregues quando o projeto está completo. Também pode medir eventuais funções de conversão de dados.
| |
Componente Funcional Básico | |
---|---|
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. | |
Lógica de Processamento | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CFPS | |
---|---|
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. | |
Requisito Funcional | |
---|---|
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: Requisitos do usuário que não constituem Requisitos Funcionais do Usuário incluem, mas não estão limitados aos seguintes: [ISO/IEC 14143-1:2007, definition 3.8] | |
Fronteira | |
---|---|
É a interface conceitual que delimita o software que será medido e o usuário. A fronteira:
As seguintes regras devem ser válidas:
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:
Um artefato que ilustra bem o conceito de fronteira é o diagrama de contexto. | |
Função de Dados | |
---|---|
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). | |
Função de Transação | |
---|---|
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 | |
---|---|
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. | |
Orientação a Objeto | |
---|---|
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. | |