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.

Navegar usando este índice

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | Todos

Página: (Anterior)   1  2  3  4  (Próximo)
  Todos

C

Ciclo de Vida em Cascata

(Última edição: terça, 20 Abr 2010, 18:03)
Foi o primeiro modelo a ser conhecido em engenharia de software e está na base de muitos ciclos de vida utilizados hoje em dia. Este consiste basicamente num modelo linear em que cada passo deve ser completado antes que o próximo passo possa ser iniciado. Por exemplo, a análise de requisitos deve ser completada antes que o desenho do sistema possa ser iniciado.

CMMI

(Última edição: sexta, 9 Abr 2010, 15:53)

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.


COCOMO II

(Última edição: sábado, 10 Abr 2010, 22:23)
COnstructive COst MOdel é um modelo de estimativa paramétrico que envolve o uso de equações matemáticas para fazer estimativas de esforço, prazo e tamanho da equipe em projetos de software. Suas equações são baseadas em pesquisa e dados históricos e utilizam como entrada a quantidade de linhas de código (ou pontos de função) e a avaliação de outros aspectos relevantes para a estimativa chamados de cost drivers (ou vetores de custo).

Comitê de Práticas de Contagem

(Última edição: quinta, 9 Jul 2009, 00:54)

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


Complexidade de Processamento

(Última edição: terça, 12 Mai 2009, 23:55)

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.


Complexidade Funcional

(Última edição: sexta, 23 Abr 2010, 13:09)

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


Componente

(Última edição: sexta, 23 Abr 2010, 09:58)
No contexto da APF, o termo componente, tem o sentido de "partes de um conjunto" e não o sentido de "pedaço reutilizável de software", que é um termos mais técnico e ligado ao contexto do desenvolvedor de software.

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


Comunicação de Dados

(Última edição: quinta, 16 Nov 2006, 11:40)

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.


Cone da Incerteza

(Última edição: quinta, 22 Abr 2010, 14:04)
Teoria que explica o fenômeno onde nós da indústria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.


Página: (Anterior)   1  2  3  4  (Próximo)
  Todos