FATTO

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.

São dados que surgem em resposta a requisitos técnicos como: normalização de dados, garantia da integridade de dados ou melhoria na entrada de dados. Em geral são dados essencialmente estáticos que possuem poucos atributos, tipicamente código e descrição. Estes dados não contribuem para o tamanho funcional do software, nem as transações que os manipulam.

Também chamados de dados de lista ou dados de tradução. O usuário nem sempre os especifica diretamente. Em outros casos, são identificados pelo desenvolvedor em resposta a um ou mais requisitos técnicos do usuário. Provêem uma lista de valores válidos que um atributo descritivo pode assumir. Tipicamente seus atributos são código, descrição e/ou outros atributos "padrão" descrevendo o código; por exemplo, abreviação padrão, datas de início e término de vigência, dados de auditoria, ativo/inativo, etc.

A diferença chave entre Dados de Código e Dados de Referência é:
• Com Dados de Código, você pode substituir um pelo outro sem alteração do significado dos Dados do Negócio. Ex.: Código do Aeroporto X Nome do Aeroporto, Código da Cor X Descrição da Cor.
• Com Dados de Referência você não pode substituir (Ex.: Código do Imposto com a Alíquota do Imposto)

Características lógicas incluem:
• Dados são obrigatórios para a área funcional, mas armazenado opcionalmente como um arquivo de dados
• Geralmente não identificado como parte dos requisitos funcionais; ele é normalmente identificado como parte do projeto para satisfazer requisitos técnicos
• Às vezes mantidos pelo usuário (normalmente por um usuário do suporte)
• Armazena dados para padronizar e facilitar atividades do negócio e transações do negócio
• Essencialmente estático – apenas alterado em resposta a mudanças na maneira que o negócio é operado
• Transações do negócio acessam Dados de Código para melhorar casos de entradas de dados, melhorar a consistência de dados, garantir integridade de dados, etc.

Quando reconhecido pelo usuário:
• As vezes é considerado como um grupo do mesmo conjunto de dados
• Pode ser mantido utilizando a mesma lógica de processamento

Características físicas incluem:
• Possui campos chave e normalmente um ou dois atributos apenas
• Tipicamente tem um número estável de registros
• As vezes desnormalizado e armazenado em uma tabela física com outros Dados de Código
• Pode ser implementado de diferentes formas (ex.: em uma aplicação separada, dicionário de dados ou diretamente no código fonte do software)

Exemplos:
• Dados estáticos
• Dados de substituição (código + descrição)
• Dados de domínio de valores

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

Existem para suportar regras de negócio para a manutenção de Dados de Negócio. Representam um pequeno percentual das entidades identificadas. Possuem poucos atributos e são dados pouco dinâmicos. Devem ser contados como ALIs ou AIEs.

Por exemplo, em uma aplicação de folha de pagamento ele seria o dado armazenado sobre as alíqüotas de imposto de renda na fonte para cada faixa salarial e sua data de vigência.

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)
• Normalmente mantido pelo usuário (normalmente por um usuário administrativo)
• Normalmente criado quando a aplicação é instalada pela primeira vez e mantido intermitentemente
• Armazena os dados para auxiliar nas atividades centrais do usuário
• Pouco dinâmico – ocasionalmente altera em resposta a mudanças no ambiente das áreas funcionais, processos funcionais externos e/ou regras de negócio.
• Transações processando Dados de Negócio freqüentemente necessitam acessar os Dados de Referência

Características físicas incluem:
• Têm campos chave e poucos atributos
• Normalmente pelo menos um registro ou um número limitado de registros

Um problema o qual, sem sua correção, poderia causar uma aplicação falhar ou produzir um resultado incorreto. A falta de uma funcionalidade que foi especificada ou solicitada também é considerada um defeito.

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

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

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

Ele representa todo o sistema como um único processo e é composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades externas. O diagrama é uma forma de representar o objeto do estudo, o projeto, e sua relação com o ambiente.

Um diagrama de contexto permite identificar os limites dos processos, as áreas envolvidas com o processo e os relacionamentos com outros processos e elementos externos à empresa (ex.: clientes, fornecedores).