Glossário da Análise de Pontos de Função


Glossário sobre Análise de Pontos de Função

FATTO Consultoria e Sistemas - www.fattocs.com

Este glossário foi compilado pela FATTO com termos usados no Manual de Práticas de Contagem do IFPUG, versão 4.3, e complementados com outros termos comumente usados pelos praticantes da APF.


Critério de ordenação atual: Por data de atualização crescente Por ordem cronológica: Por data de atualização Mude para decrescente | Por data de criação

Página: (Anterior)   1  ...  10  11  12  13  14  15  16  17  18  19
  Todos

Contagem de Pontos de Função do Projeto de Melhoria

(Última edição: sexta, 10 Ago 2012, 16:46)
É 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.
É também chamada de Enhanced Function Point (EFP). Sendo assim, temos:

EFP = ADD + CHGA + CFP + DEL

Utilize a seguinte formula para calcular o tamanho funcional ajustado do Projeto de Melhoria.

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

Componente Funcional Básico

(Última edição: segunda, 8 Out 2012, 14:03)

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


Lógica de Processamento

(Última edição: segunda, 4 Fev 2013, 23:09)

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.

Sumário das Lógicas de Processamento Usadas Pelas Transações

Tipos de Lógica de Processamento (LP)

EE

SE

CE

01. Validações

Pode

Pode

Pode

02. Cálculos e fórmulas matemáticas

Pode

Deve*

Não

03. Conversão em valores equivalentes

Pode

Pode

Pode

04. Filtro e seleção de dados com base em critérios específicos na comparação de vários conjuntos dados

Pode

Pode

Pode

05. Análise de condições para que se determinem quais se aplicam

Pode

Pode

Pode

06. Atualização de pelo menos um ALI

Deve*

Deve*

Não

07. Referencia a pelo menos um ALI ou AIE

Pode

Pode

Deve

08. Recuperação de dados ou informações de controle

Pode

Pode

Deve

09. Criação de dados derivados

Pode

Deve*

Não

10. Alteração do comportamento do sistema

Deve*

Deve*

Não

11. Preparação e apresentação de informação para fora da fronteira

Pode

Deve

Deve

12. Capacidade de aceitar dados ou informações de controle que entram pela fronteira

Deve

Pode

Pode

13. Ordenação, reclassificação ou rearrumação de um conjunto de dados

* Esta é a única lógica que não serve para garantir que uma transação seja diferente de outra

Pode

Pode

Pode


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


CFPS

(Última edição: segunda, 18 Mar 2013, 22:49)

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


Requisito Funcional

(Última edição: quinta, 11 Abr 2013, 14:54)

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]


Fronteira

(Última edição: terça, 11 Jun 2013, 10:48)

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

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.


Função de Dados

(Última edição: quarta, 12 Jun 2013, 12:07)

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

(Última edição: quarta, 12 Jun 2013, 12:07)

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

(Última edição: terça, 25 Jun 2013, 17:26)

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

(Última edição: quinta, 22 Ago 2013, 08:21)

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.



Página: (Anterior)   1  ...  10  11  12  13  14  15  16  17  18  19
  Todos