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