Tradução não oficial de: Function Points & Counting – Entreprise Data
Warehouses - 2007
Maiores informações em:
The Internacional Function Point User Group
http://www.ifpug.org/
NEC - New Environments Committee
The Internacional Function Point User Group
Nota: A NEC (Comitê de Novos Ambientes) criou esses “White Papers”, em
um esforço para distribuir, rapidamente para a comunidade de contagem, dicas
sobre o assunto.
Este documento baseia-se nas práticas de contagem de
pontos de função, tal como descrito na atual série 4,2 do Manual IFPUG de
Práticas de Contagem (CPM), e demonstra a aplicabilidade de Pontos de Função
IFPUG para o assunto.
O conteúdo deste documento é para ser utilizado
exclusivamente como sugestões na aplicação da contagem de ponto de função no
domínio descrito.
Essas sugestões não constituem mudanças de regra e não
devem ser utilizados como regras. Embora este documento tenha sido analisado e
aprovado pelo CPC, não constitui normas IFPUG para prática de contagem como
contidas no CPM.
Introdução
Nos últimos anos vimos um
aumento dramático na implantação de Data Warehouses Empresariais, em todo o
mundo. Dada a natureza primária destes armazéns de dados como repositórios de
dados enviados a partir de outros aplicativos, a contagem de ponto de função
desses sistemas tem proporcionado grandes desafios para a comunidade.
O
objetivo deste trabalho é fornecer orientações para a aplicação das regras de
contagem de pontos de função especificadas na versão 4,2 do Counting Practices
Manual (CPM), datada de Janeiro de 2004. Este “White Paper” não conflita com as
regras oficiais do IFPUG especificadas no CPM.
Maiores informações em:
The Internacional Function Point User Group
http://www.ifpug.org/
NEC - New Environments Committee
_________________________________________________________________
Publicação original = Fórum SBGC-TIC 3/7/2008 6:45 PM
How should the functionality of a Data Warehouse
be counted?
FUNCTIONAL OVERVIEW
While it is recognised that Data Warehouse systems each have their own
unique characteristics, there are certain generic characteristics shared by the
family of systems known as Data Warehouses. These include:
1. The prime
purpose of a Data Warehouse is to store, in one system, data and information
that originates from multiple applications within, or across, organisations. The
data may be stored ‘as received’ from the source application, or it may be
processed upon input to validate, translate, aggregate or derive new
data/information.
2. Most of the data load functions are processed in
batch. There are few on-line data maintenance functions. The on-line functions
that do exist tend to update the reference files and data translation tables.
3. A database alone, does not constitute a Data Warehouse system. At a
minimum, a Data Warehouse system must include the database and corresponding
load functions. Data reporting functions are optional. They may, or may not be
an integral part of the Data Warehouse system.
4. The prime purpose of
storing the data is to support the information reporting requirements of an
organisation i.e. multiple users and multiple applications.
5. The Data
Warehouse may, or may not, provide the required reporting functions. In some
cases, external applications access the Data Warehouse files to generate their
own reports and queries.
6. Data Warehouse functions are often based
upon packaged software. An example is the Business Objects product.
7.
Where the data within the Warehouse supports the reporting requirements of
multiple applications and users, the data may be physically stored based upon
the user requirements. Separate database segments may store the ‘user views’ for
a particular user. This results in the physical storage of a considerable amount
of redundant data. The data storage approach is designed to optimise
data/information retrieval.
GENERAL DISCUSSION AND
RESOLUTION
Note: The following list of functions are intended
to be a generic guide for counting this type of application, there may be
instances where particular applications may offer more or less
functionality.
Files: Internal Logical Files
The
main issue with Data Warehouse (DW) systems is how to count the files. Typically
a DW is required to support the information needs of multiple
applications/users. Data is input to the systems from a number of source systems
(usually core systems). At the time the data is loaded it may be processed in
multiple ways and update multiple files, each of which supports a different
user’s needs. With DW files it is not possible to force a logical view of the
files. The same data can be stored in multiple physical files because it
supports that particular user’s view of their requirements.
Where they
exist, the following may be counted as ILFs for the Data Warehouse System:
• Master Data Files
These may store processed information or
data as received from the source core systems. Redundant data may be stored in
various physical tables that are required to support User Views of data. Count
each physical database table as a logical file. Count the redundant DETs as
DET’s in the files in which they occur. Do not count redundant DETs that occur
within the one file.
• Reference/Translation Tables
The
possibilities are many and varied. However under the recommended guidelines only
one Translation table is counted per application. See Section 3.4.7, Reference
tables – Identification Guidelines
• Log/Event Files
Files
may exist which maintain information about the currency of the data within the
DW. For example they may record when data was last refreshed from a particular
source application.
Transactions: External Inputs
The EI load
transactions are identified from a physical perspective as well.
Where
they exist, the following may be counted as EIs for the Data Warehouse System:
• Data Load Functions
Records in files are not necessarily
loaded as a complete record. It depends upon where the source data has come from
and how the load process has been designed i.e. the amount of pre-processing
that is done on the source data. For example, a load function may only load
certain attributes into a file or alternatively, one load process may load
multiple files at the same time. It is assumed that what is implemented, is what
the user requested, and there was a good business reason for adopting the
implemented approach.
In most cases the EI Load functions process the
data received. An exception situation occurs where the data is simply loaded as
received from the source system. In this case, theoretically, the Load should
not count as an EI and the file loaded should be counted as an EIF. This can
cause the unusual situation where the DW loads a file that is typed as an EIF.
The downstream reporting system reads the DW file and also types it as an EIF.
This situation is rare and it is recommended that the load function be counted
as an EI and the DW file as an ILF
• Maintenance functions for
Reference/Translation Tables
Count as per IFPUG 4.1.
Transactions: External Outputs and External Enquiries
Where they exist, the following may be counted as EOs and/or EQs for the
Data Warehouse System:
• Data Reporting Functions
DW systems
usually do not have their own reporting functions. They are not ‘reporting
users’ of their own files. Other external applications reference the DW files
(as EIFs) and produce the necessary reports. This can result in a considerable
amount of double counting of files across the portfolio, but, this is usual when
application boundaries are drawn in this way. Sometimes the DW does use a
reporting tool such as Business Objects to generate reports. If so, count as per
IFPUG 4.1
Note: When the bulk of the processing (i.e. derived and
calculated data) is performed as part of the data load processing, most of the
reports produced are technically EQ’s
• Data Enquiry Functions
Count as per IFPUG 4.1.
Nenhum comentário:
Postar um comentário