Applying Function Point Analysis To Data Warehouse Analytics Systems

Applying
Function Point
Analysis to Data Warehouse
Analytics Systems
IFPUG FSSC White Paper

(version # 1.0 08/10/2018)
Authors: Roopali Thapar, E. Jay Fischer, Peter Thomas
Reviewers:
Bonnie S. Brown Tammy Preuss Adri Timp
Steve Keim Daniel French Charles Wesolowski
Diana Baklizsky
Applying Function Point Analysis to Data Warehouse Analytics Systems
Table of Contents
1. INTRODUCTION .............................................................................................................................. 3
2. AUDIENCE ......................................................................................................................................... 4
3. ENVIRONMENT ................................................................................................................................ 4
3.1 SCHEMAS........................................................................................................................................ 4
3.2 OBJECTS ......................................................................................................................................... 5
3.2.1 Types of objects ................................................................................................................. 6
3.3 CLASSES......................................................................................................................................... 6
3.4 HIERARCHY ..................................................................................................................................... 6
4. EXAMPLE SCENARIO ..................................................................................................................... 6
5. FUNCTION POINT ANALYSIS APPROACH............................................................................. 9
5.1 DEFINING THE APPLICATION BOUNDARY ......................................................................................... 9

5.2 HINTS FOR MEASURING DATA AND TRANSACTIONAL FUNCTIONS .................................................. 11
5.2.1 Measuring the Universe and its Maintenance ............................................................ 11
5.2.2 Counting Components within the Universe for data function sizing..................... 14
5.2.3 Counting Components within the Universe for logical function sizing ................. 15
5.2.4 Creating and Maintaining the Stored Procedures ..................................................... 18
5.2.5 Free Hand SQL provision ............................................................................................... 18
5.2.6 Counting User Management and Security Access .................................................... 18
5.2.7 Counting Enhancements to Universe Functionality .................................................. 18
6. SUMMARY ........................................................................................................................................ 19
7. REFERENCES .................................................................................................................................. 20
8. GLOSSARY ....................................................................................................................................... 21
Page 2
© IFPUG 2018
1. Introduction
The white paper from IFPUG New Environments Committee in 2007 – “Function
Points and Counting Enterprise Data Warehouses” provided guidance to the users
on how to apply the Function Point rules in Data Warehouse environments. Since
then, the rising popularity of data analytics and Big Data has driven an evolution in
Data Warehouse technology. Users request more complex business analytics and
reporting requirements, along with a growing need to simplify the information
access within the Data Warehouses.
As a result, new “user friendly” components have evolved for pulling data from Data
Warehouses, irrespective of underlying data structures. One such component is the
Universe (also known as the Semantic Layer). The Universe is an abstraction
created for the user to simplify access to the information required or for
downstream consumption, without needing to know the details of the database
implementations. Thus, the Universe facilitates an integrated query, reporting and
analysis solution for business users via the abstraction layer for the application
data that represents business functions.
From the application maintenance and development perspective, there is also a

need to quantify the effort spent by the teams to plan, maintain, test, and publish
these components to the user.
As highlighted in the diagram below (Figure 1), this paper focuses on sizing the
Universe creation and its maintenance in this environment. The paper also helps to
understand the impacts on the sizing of reporting requirements where Universe is
present in the Data Warehouse environment.
Figure 1.
This paper acts as a reference for those complex scenarios in Business Analytics,
which are not covered in prior IFPUG white paper on Data Warehousing [6].
____________________________________________________________________________________________________________
Page 3
© IFPUG 2018
2. Audience
This paper addresses the requirements of experienced IFPUG function point
analysts who need to size the Universe and its components – business objects in a
data warehousing solution for business analytics. It is assumed that the reader is
aware of the data warehousing concepts like Fact Tables, Extract – Transform –
Load jobs (ETL), and data transformation, et al.
3. Environment
Terminology in this paper is based on SAP terms and definitions [1]. If you are
using a different tool, your terminology may be different. The glossary will help you
resolve this. Though the paper is based on SAP - related business data analytics
tool, please note that IFPUG doesn’t endorse SAP or SAP products.
Reporting Data Warehouse solutions often include a Universe between the end user
and the database. The Universe holds the logical mapping of the data in the
physical database to data terminology in business terms. Users can connect to a
Universe to analyze and run queries against the physical database without getting
into details of database implementation.
For example, Car Manufacturing Company creates and maintains a Universe for
car categories and models launched as shown below (INT_** in the following table
represents the physical table name in the Data Warehouse)
Universe Component Mapped to Table/Column

Car Category INT_Car_Details/Car_Category_Name
Model Name INT_Car_Details/Car_Model_Identifier
Launch Year INT_Car_Details/Manufacturing_Year
Units sold till date INT_Car_Sales/Total_Sale
With the help of above Universe components, the user can view a report on car
models launched in a particular year without knowing the database details. But for
a Function point analyst, it is important to understand the mapping of
these user identifiable components to the underlying environment logical
components to assess the application size impacts correctly.
A Universe contains the following structures:
 Schemas
 Classes
 Objects
 Hierarchy
3.1 Schemas
As noted in the prior Car Category Universe example, the user may not be aware of
all the physical tables of the Data Warehouse, but may be interested in a subset of
the tables or their columns of the database for the reporting requirements. A
____________________________________________________________________________________________________________
Page 4
© IFPUG 2018
schema is a graphical representation of database structures [1]. It represents the

part of the database being represented via the Universe based on the reporting
requirements. The schema contains tables and joins. The tables contain columns
that eventually map to objects that end users use to create reports. The joins link
the tables so that the correct data is returned for queries that are run on more than
one table. The schema is not visible to end users who use reporting tools to create
reports.
For example, Company ‘ACME’ publishes and maintains an AP Performance

Universe that supports Asia Pacific performance reporting dashboard requirements:
Figure 2.
3.2 Objects
An object is a named component that maps to data column in the database [1]. The
object representation should map to an entity, calculation or fact used in end user
business environment. For example, objects used in a university Universe for use by
an administrator could be Course Number, Start Date, and Course Grade.
____________________________________________________________________________________________________________
Page 5
© IFPUG 2018
3.2.1 Types of objects

The objects are qualified as one of three types: dimension, detail, or measure [1]
Object Description Function
Type
Dimension Parameters for analysis [1]. Maps to one or more Association
columns or functions in the database that are key
to a query. For example, Service Category,
Country
Detail Provides a description of the dimensions, but are Attribution

not a focus of analysis [1]. A detail is always
attached to a dimension. It maps to one or more
columns or functions in the database that provide
detailed information related to a dimension. For
example, Actual Amount, User Access
Measure Convey numeric information which is used to Aggregation

quantify a dimension object [1]. For example,
Active Project Count, Percentage Variance
Measure objects differ according to which Dimension Objects they are

combined with; they are not normally used with Detail Objects.
3.3 Classes
A class is a logical grouping of objects within a Universe [1]. It represents a category
of related objects, in which the user is interested, for data analysis. A class can be
divided hierarchically into subclasses. A subclass is a class within a class.
Subclasses are used to help organize groups of objects that are related. A subclass
can itself contain other subclasses or objects.
3.4 Hierarchy
A hierarchy is a collection of related data members, usually organized in a
hierarchical structure [1]. It is an ordered sequence of dimension objects. For
example, a location hierarchy could be Country-> State -> City. Hierarchies can be
default or custom. A default hierarchy is set based on the order in which dimensions
are placed in the class. In a custom hierarchy the sequence of dimensions is defined
by the developer based on analysis of business needs. For example, an end user
might want to drill down a performance report based on the status of the project. So
the corresponding dimension objects may be added accordingly to create a new
hierarchy (Country -> Year-> Project Status).
4. Example Scenario
Company ‘ACME’ publishes and maintains an Asia Pacific Performance Universe
that supports Asia Pacific performance reporting dashboard requirements. A
Dashboard shows reports related to delivery performance for a particular month or
____________________________________________________________________________________________________________
Page 6
© IFPUG 2018
for a set of projects executed at a particular location. Only restricted users have
access to view the performance reports.
To meet the above requirement, the reports are designed in the AP Performance
Universe to pull the data from following tables in the Data Warehouse:
i. Delivery Performance FACT (which has dimensions as Country and

Time)
ii. User_Profile_tbl
iii. Proj_Info_tbl
iv. Proj_Loc_tbl
v. Proj_Fin_tbl
Using the tool for designing the Universe, the data pulled from above tables is
logically grouped into Classes as follows:
i. Project Information
ii. User Access Details
iii. Delivery Performance
Further, the following objects are defined within each of the above classes so as to
meet data requirements of the reports.
Class/sub Class Object Name Database Mapping Table/column
Project Project Id PROD_Project_Info_tbl/Proj_ID

Information
Project Project Name PROD_Project_Info_tbl/Proj_NAME

Information
Project Project Start Date PROD_Project_Info_tbl/Proj_START_DATE

Information
Project Project End Date PROD_Project_Info_tbl/Proj_END_DATE

Information
Project Current Status PROD_Project_Info_tbl/Proj_CURRSTAT

Information
Project Location Country PROD_Project_Info_tbl/Proj_CNTY

Information
Project Location City PROD_Project_Info_tbl/Proj_CITY

Information
Project Actual Cost PROD_Project_Fin_tbl/Proj_ACT_COST

Information/
Project Financials
____________________________________________________________________________________________________________
Page 7
© IFPUG 2018
Class/sub Class Object Name Database Mapping Table/column
Project Budgeted Cost PROD_Project_Fin_tbl/Proj_BUD_COST

Information/
Project Financials
Project Percentage Variance PROD_Project_Fin_tbl/Proj_COST_VAR

Information/
Project Financials
Project Project Health Status PROD_Project_Fin_tbl/Proj_HLTH_STAT

Information/
Project Financials
User Access Detail User ID PROD_User_tbl/User_ID
User Access Detail User Group PROD_User_tbl/User_GRP
User Access Detail User Access PROD_User_tbl/User_ACCESS_PERM
Delivery Service Category PROD_Delivery_Perf_FACT_tbl/Service_CAT

Performance
Delivery Service Level PROD_Delivery_Perf_FACT_tbl/Service_LVL

Performance
Delivery Country PROD_Delivery_Perf_Country_Dim/Service_COU

Performance NTRY
Delivery City PROD_Delivery_Perf_City_Dim/Service_CITY

Performance
Delivery Month PROD_Delivery_Perf_Time_Dim/Report_MONTH

Performance
Delivery Total Number of Count of projects from PROD_Project_Info_tbl for

Performance Reported Projects the reporting month.
Delivery Active Projects Count PROD_Delivery_Perf_City_Dim/ACT_PRJ_CNT

Performance
Delivery Closed Projects Count PROD_Delivery_Perf_City_Dim/CLOSED_PRJ_C

Performance NT
Delivery Cancelled Projects PROD_Delivery_Perf_City_Dim/CANC_PRJ_CNT

Performance Count
Delivery Number of Projects PROD_Delivery_Perf_City_Dim/RED_STAT_PRJ_

Performance with Health Status CNT
as Red
Delivery Total Revenue Loss PROD_Delivery_Perf_City_Dim/REV_LOSS

Performance
____________________________________________________________________________________________________________
Page 8
© IFPUG 2018
5. Function Point Analysis Approach

The Universe and its components can be created with a set of tools like SAP
Universe Designer, SAP Universe Builder, etc. Creating and maintaining the
Universe requires multiple steps involved as below [2].
 Analysis of business problem and planning the Universe solution

 Designing a schema
 Building the Universe
 Distributing the Universe to users
For this white paper, it is assumed that the purpose of the count is to size the
functionality required for the creation and the maintenance of the Universe along
with the delivered functionality such as reports, alerts, et al. For sizing, the next
step is to identify the application boundary to which the Universe belongs.
The FP analyst should be cautious to not include any functionality that is part of
the designer tool itself and is not customized to meet user needs. If the functionality
of the tool is being used as-is, typically it cannot be included in the
development/enhancement counts. If the project tracks the re-use functionality of
the third party software, then the ‘as-is’ functionality requested in the Functional
User Requirements can be counted and tracked separately.
5.1 Defining the Application Boundary

For a Data Warehouse scenario with Universe enabled information access, a
challenge comes in defining the application boundary. Multiple approaches are
possible based on user perspective.
The following rule must apply for boundaries:
The boundary is determined based on the user’s view. The focus is on what the
user can understand and describe. The boundary between related applications
is based on separate functional areas as seen by the user, not on technical
considerations.
The initial boundary already established for the application or applications

being modified are not influenced by the counting scope.1
Based on this rule, the following criteria will assist the function point analyst to
determine the proper boundary for the application(s) under review:
1 IFPUG CPM part 1, 5.3 d
____________________________________________________________________________________________________________
Page 9
© IFPUG 2018
Case 1: Universe and Data Warehouse are separate application boundaries
Business Environment: This situation is frequently observed where the user may
want to track the productivity of the Data Warehouse maintenance and Business
Analytics & Reporting (which holds the Universe or the semantic layer) team
separately or there are two different functional teams for these two areas (Figure 3).
Example could be multi-vendor support scenarios, where each vendor is responsible
for functionality in their respective area only.
Figure 3.
Case 2: Universe and Data Warehouse are part of same application

boundary
Business Environment: This situation is frequently observed when the entire

Data Warehouse and its reporting functionality is observed as a single functional
unit by the user (Figure 4).
____________________________________________________________________________________________________________
Page 10
© IFPUG 2018
Figure 4.
5.2 Hints for Measuring Data and Transactional Functions

5.2.1 Measuring the Universe and its Maintenance
The Universe provides business users with the capability to define and create their
own reports using data fields that are available from the ILFs and EIFs. The
Universe is like placeholder for various templates of the reports or the queries. All
the functionality required to create and maintain this ‘report template’ place holder
shall be FP counted as mentioned in following sections in this white paper.
Further, based upon the user requirement for reporting needs, a schema is created
for the Universe. The schema specifies which tables are being referenced and how
the resulting data is created by joins from different tables. CPM rules for logical
data function identification can be used to identify and size the data components.
Moreover, the classification of logical data depends upon where the application
boundary exists for the Universe.
Hence, it is very important for the analyst to fully understand the user view of the
Data Warehouse Application. If the end user is aware of Universe and its creation
and maintenance is part of the user requirements, then it can be assessed using
Function point rules. If the Universe is created to meet the non-functional
requirements like performance, then refer SNAP [2] to size the Universe.
It should also be noted that if the purpose of the Universe is to provide the data via
an extract to end users (instead of reports), then an EQ/EO shall be counted (based
on rules mentioned in CPM for EQ/EO identification). Else, if the purpose of it is for
information access for end user reporting flexibility, then it can be accounted as
____________________________________________________________________________________________________________
Page 11
© IFPUG 2018
mentioned in following cases, depending whether Universe is part of Data

Warehouse boundary or not.
Transactions for Creating and Maintaining the Universe Data
 The data function (Universe itself) that contains the rules selected and
entered by the user and the mapping of objects should be counted as 1 ILF.
 The feeds to the Universe are considered as EIs. 1 EI per unique user
identifiable feed should be counted for creating the data in the Universe.
 An EI for changing the properties of objects in the Universe.
 An EQ for viewing the Universe details
 An EI each for creating and editing custom hierarchies.
 Any extracts from Data Warehouse to Universe shall be counted as EOs/EQs
____________________________________________________________________________________________________________
Page 12
© IFPUG 2018
Counting Data Model
a) If the data function is an exact copy of the source table, then count it as an
EIF.
b) If the table data stores manipulated data or derived data from a set of tables,
which is available to the user for reporting requirements, then count this
data function as an ILF.
c) If the table is a staging data table, which does not meet the user
requirements directly, but acts as input to another table, then it is not
countable. For example, an interim transformed data table may be created.
Then this acts as an input to another table which shows a value based on
interim data. Since the staging data table is a temporary table, it would not
be counted.

boundary
Transactions for Creating and Maintaining the Universe Data
 The data function (Universe itself) that contains the rules selected and
entered by the user and the mapping of objects should be counted as 1 ILF.
 The feeds to the Universe are not counted as EIs.
 An EQ for viewing the Universe details.
 An EI each for creating and editing custom hierarchies.
____________________________________________________________________________________________________________
Page 13
© IFPUG 2018
Counting Data Model
a) In this case, the queries in the Universe on the logical files within the system
only. Unless a derived data table exists, for which the data is maintained, do
not count ILFs separately for the Universe tables referred.
b) In such a case, where the Universe is part of the Data Warehouse application
boundary itself, then transactions from Data Warehouse to the Universe
cannot be FP counted as data doesn’t cross the boundary itself.
c) SNAP [3] can be applied to count transactions crossing the partitions within
the application boundary
5.2.2 Counting Components within the Universe for data function sizing
The Universe creates an abstraction layer for the end user because of which
physical data model details may not be apparent and hence the FP Analyst needs to
understand the application specific terminology used in this environment for correct
size assessment.
5.2.2.1 Counting Classes
A class is a logical grouping of data that may be a logical data type in the Universe
schema. A class may also potentially represent a RET of a data function. The ILF,
EIF and RET identification rules, as described in CPM, are used to identify the
logical groups and sub-groups of data within a data function.
A class may contain subclasses. A subclass could be considered as an additional

RET of the data function from which the information is being presented. For
example, in the Asia Pacific Performance Universe, the Project Financial Details is
a subclass of Project Information and is identified as a RET of the Project
Information data function.
It should be noted that not all classes may be mapped to RET. If the class holds only
the technical /temporary/non user identifiable information, it should not be counted
at all.
5.2.2.2 Counting Objects
An object is a named component that maps to a data column in a database. It could
be in the form of dimension, detail or measure. All of these represent an attribute of
an entity. In FPA terms, each corresponds to a DET of a data function if it is
unique, user identifiable, and non-repeating.
____________________________________________________________________________________________________________
Page 14
© IFPUG 2018
Object In Business Object / Analytics In FPA terms

Type Terms
Dimension A dimension maps to one or more DET(S)
columns or functions in the
database that are key to a query.
It has the parameters for
analysis. For example Country
Name, Product_id
Detail Detail objects provide a DET(S)
description of the dimensions. A
detail is always attached to a
dimension. It maps to one or
more columns or functions in the
database that provide detailed
information related to a
dimension. For example Phone
number, Address
Measure Contains aggregate functions DET(S)
that map to statistics in the
database. For example Number
of products sold, Percentage
Market share
5.2.3 Counting Components within the Universe for logical function sizing
Each unique report generated from the Universe is a potential EQ or EO. It is
important to understand the logical data model of the system prior to being able to
properly and accurately identify the transactional functions.
5.2.3.1 Counting Reporting Functionality

i. Predefined Reports
Apply the CPM rules to identify the pre-defined reports being delivered from
the Universe created. These could be classified as an EQ or EO depending
upon the set of requirements and conditional logic mentioned for report
generation. If the report involves only reading the data and displaying on the
report, then it is an EQ. Otherwise if it involves calculations as part of its
processing logic, updates an ILF or creates derived data, then it is an EO.
The complexity of EO and EQ is determined based upon the associated DETs

and FTRs. Reports may involve the display of dimension or measure objects
containing data from various logical data functions in the Universe. Be sure
to count all unique, user identifiable FTRs referenced for the DETs required
in the report, whether it is a business object or dimension object or a measure
object. For example, a report for Broadband subscription for a given customer
shows the following –
____________________________________________________________________________________________________________
Page 15
© IFPUG 2018
Month Bill Plan Total Usage Total Charge
…….. …………. ………… …………
Bill Plan details are retrieved from the Subscription logical data file. Total
usage and Total charge are measure objects with data aggregated from
Subscription, Bill Statement and Broadband Usage history detail. Hence, the
FTR count for this report is 3 (Subscription, Bill Statement, and Broadband
History).
ii. Ad hoc Reports
If functionality is provided to the user to generate ad hoc reports, then it
should be counted using function points. Function Point Analysts should
identify any functions provided to the user to produce and manage the ad hoc
(user defined) reports only and not count every possible report scenario or
permutation.
5.2.3.2 Considering Hierarchies for Report Generation
Hierarchies are collections of dimension objects required for multi-dimensional data
analysis. Custom hierarchies exist where the user wants analysis or reporting in a
particular order. For example Region -> Country -> State -> City.
If a hierarchy is used to create report functionality with other business objects, then
the presence of unique EO/EQ can be assessed for each level of hierarchy, as per the
rules defined in the CPM. For example, in AP Universe, a report may be requested
by the user showing the delivery performance at the Country level and provide the
ability to drill down (view data at) to the City level. The report includes the
following fields:
At Hierarchy Location = Country
Service Active Closed Number of Total

Category Project Project Project with Revenue
Count Count Health as Loss
Red
At Hierarchy Location = City A
Service Active Closed Number of Project with

Category Project Project Health as Red
Count Count
____________________________________________________________________________________________________________
Page 16
© IFPUG 2018
In the above case, there is one EO corresponding to each Hierarchy level (i.e., 1 EO
for hierarchy level as Country and 1 EO for hierarchy level as City). Note that even
if the DETS for each hierarchy are the same, they still would be considered as
separate unique elementary processes if there are different sets of processing logic
required for each level of aggregation.
5.2.3.3 Considering the Query Filters
A Query Filter limits what data is returned for a particular query. The functionality
is similar to the filter function in MS Excel. For example, in AP Universe a report
may be requested by the user to show the delivery performance at the Country level
and filter the results by month. The report shows up the following fields:
At Hierarchy Location = Country Select Month
Month Service Service Number of Total Revenue Loss

Category Level Project with
Health as Red
---- ------ -------- ----- ---
In FPA terms, query filters specify a condition for data display processing and hence
are considered part of the processing logic of the EQ or EO and are not counted as
separate unique elementary processes. The analysts should evaluate to determine if
there is filtering occurring or if there are unique reports being generated.
In another example, the above report may be filtered on basis of Service Level
(Gold, Silver, and Bronze) to display the requested Service Level performance data.
In this case, is not considered as a unique EO from the monthly transaction.
At Hierarchy Location = Country Select Service Level
Service Service Month Number of Total Revenue Loss

Level Category Project with
Health as Red
----- ---- ------ ------ ------
Selecting a Service Level and pulling out data for that level shall not make it a
unique EO. For example, a report view of Service level = Gold or Service level=
Silver, will still make it same EO, as in this case ‘different content’ of same
processing logic is pulled in different views.
5.2.3.4 Counting Alerts
Alerts are messages generated by the schema software to highlight information that
meets multiple business criteria. An alert can be made up of multiple sub-alerts,
____________________________________________________________________________________________________________
Page 17
© IFPUG 2018
each containing one or multiple conditions. Sub-alerts allow the user to apply
different conditions and different formatting to a single business object like a
dimension or a measure. For example, in AP Performance Universe, an alert can be
set as notification to the management user whenever the Project Red count is > 3,
for a location. Further, a sub-alert can be set when the Project Red count exceeds
10.
Alerts are counted as an EO or an EQ in accordance with CPM rules. The DETs

counted are identified from the DETs present in the alerts. The FTR(s) counted
is/are the number of data functions read or updated. Do not count subordinate
alerts which are really a part of a parent alert but with variations within the same
set of processing logic.
5.2.4 Creating and Maintaining the Stored Procedures
A stored procedure is a Structure Query Language (SQL) script that accesses a
relational database based on user requirements. If the end user or another
application has the capability to invoke it, then the procedure should be counted as
an EI/EO/EQ using the CPM rules based upon the primary intent of each stored
procedure.
If the stored procedure does not provide data outside the application boundary or it
is part of an existing transaction, then it should not be counted.
5.2.5 Free Hand SQL provision
For administrative users, the business objects or database tool may have the
capability to execute SQL commands interactively within the data base directly.
This capability is provided by the tool itself and it is not to be considered countable
for the application being analyzed, unless the functionality of the tool itself is
within the counting scope.
5.2.6 Counting User Management and Security Access
User management functions such as add, update, delete user, user logon, password
maintenance or defining and maintaining role-based access should be counted.
Identify all the related user management or security features and classify all
functions based on the identification rules specified in the CPM.
5.2.7 Counting Enhancements to Universe Functionality
Counting enhancements:
For an enhancement, where new columns need to be added to the Universe to meet
the additional information requirement:
For the universe changes:
____________________________________________________________________________________________________________
Page 18
© IFPUG 2018
 A change to Universe ILF(s) are counted.
 A change in EI(s) to the Universe for the associated data load(s) are counted.
 When the ILFs referenced within the data warehouse have changed because
of addition of new data, then the corresponding Universe components (data
and transaction functions) using the new data shall are also counted
 A change to EQ(s) which view the Universe are also counted.
For the Data Warehouse changes:
 Change any associated EO/EQ(s) within the data warehouse.

boundary
Counting Enhancements:
For an enhancement, where new columns need to be added to the Universe to meet
the additional information requirement:
 A change to Universe ILF(s) are counted.
 When the ILFs referenced within the data warehouse have changed because
of addition of new data, then the corresponding Universe components (data
and transaction functions) using the new data are also counted.
 Changed EQ(s) which view the Universe are also counted.
6. Summary
Business Intelligence or Analytics tools provide the user with flexibility to access
information easily and without the need for knowing technical details of database.
The IFPUG Function Point Method is applicable for these systems. However, this
flexibility for information access in the software adds to the size of the application
and complexity of performing function appoint analysis on the functionally which is
developed or maintained by the software development teams. This white paper
provides guidance to the function point analyst in how to apply the IFPUG counting
rules to these systems.

____________________________________________________________________________________________________________
Page 19
© IFPUG 2018
7. References
1. http://help.sap.com/businessobject/product_guides/boexir4/en/xi4_universe_de
sign_tool_en.pdf
2. https://finance.vanderbilt.edu/fis/documents/bo/businessobjects_access_analys
is.pdfhttp://www.ifpug.org/snap-assessment-practices-manual-v-2-1-is-
released/http://help.sap.com/businessobject/product_guides/boexir31/en/xi3-
1_data_access_guide_en.pdf
3. http://help.sap.com/businessobject/product_guides/boexir31/en/xi31_designer_
en.pdf
4. http://www.ifpug.org/category/publications/ -“Function Points and Counting
Enterprise Data Warehouses”; white paper from IFPUG New Environments
Committee in 2007
____________________________________________________________________________________________________________
Page 20
© IFPUG 2018
8. Glossary
Aggregate tables
Aggregate tables are a special kind of fact table.
Alerts
Alerts are messages generated by the schema software to highlight information that
meets multiple business criteria
Classes
A class is a logical grouping of objects within a Universe
Data Warehouse Staging Area
The staging area is used to store a current version of data as it exists in the source
system.
Dimensional tables
Dimensional tables contain the descriptive information needed to allow analysis of

the fact related information and contain information to allow verification of data
loads.
Fact tables
The fact table is the main table of interest in a dimensional model. A fact table
contains business related measures, and each fact table can be connected to either
dimensional tables or other fact tables.
Hierarchy
Hierarchy is a collection of related data members, usually organized in a

hierarchical structure
Object
An object is a named component that maps to data column or a derivation of data

(function) in the database
Query Filter
A Query Filter limits what data is returned for a particular query
____________________________________________________________________________________________________________
Page 21
© IFPUG 2018
Schema
A schema is a graphical representation of database structures. It represents the

part of the database being represented via the Universe based on the reporting
requirements.
Universe
Universe holds the logical mapping of the data in the physical database to data
terminology in business terms.
____________________________________________________________________________________________________________
Page 22
© IFPUG 2018

Applying Function Point Analysis To Data Warehouse Analytics Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Applying Function Point Analysis To Data Warehouse Analytics Systems

Uploaded by

Copyright:

Available Formats

Applying

IFPUG FSSC White Paper

Authors: Roopali Thapar, E. Jay Fischer, Peter Thomas

Bonnie S. Brown Tammy Preuss Adri Timp

Steve Keim Daniel French Charles Wesolowski

2. AUDIENCE ......................................................................................................................................... 4

3. ENVIRONMENT ................................................................................................................................ 4

5. FUNCTION POINT ANALYSIS APPROACH............................................................................. 9

5.1 DEFINING THE APPLICATION BOUNDARY ......................................................................................... 9

7. REFERENCES .................................................................................................................................. 20

8. GLOSSARY ....................................................................................................................................... 21

From the application maintenance and development perspective, there is also a

Universe Component Mapped to Table/Column

A Universe contains the following structures:

schema is a graphical representation of database structures [1]. It represents the

For example, Company ‘ACME’ publishes and maintains an AP Performance

3.2.1 Types of objects

Detail Provides a description of the dimensions, but are Attribution

Measure Convey numeric information which is used to Aggregation

Measure objects differ according to which Dimension Objects they are

i. Delivery Performance FACT (which has dimensions as Country and

Class/sub Class Object Name Database Mapping Table/column

Project Project Id PROD_Project_Info_tbl/Proj_ID

Project Project Name PROD_Project_Info_tbl/Proj_NAME

Project Project Start Date PROD_Project_Info_tbl/Proj_START_DATE

Project Project End Date PROD_Project_Info_tbl/Proj_END_DATE

Project Current Status PROD_Project_Info_tbl/Proj_CURRSTAT

Project Location Country PROD_Project_Info_tbl/Proj_CNTY

Project Location City PROD_Project_Info_tbl/Proj_CITY

Project Actual Cost PROD_Project_Fin_tbl/Proj_ACT_COST

Class/sub Class Object Name Database Mapping Table/column

Project Budgeted Cost PROD_Project_Fin_tbl/Proj_BUD_COST

Project Percentage Variance PROD_Project_Fin_tbl/Proj_COST_VAR

Project Project Health Status PROD_Project_Fin_tbl/Proj_HLTH_STAT

User Access Detail User ID PROD_User_tbl/User_ID

User Access Detail User Group PROD_User_tbl/User_GRP

User Access Detail User Access PROD_User_tbl/User_ACCESS_PERM

Delivery Service Category PROD_Delivery_Perf_FACT_tbl/Service_CAT

Delivery Service Level PROD_Delivery_Perf_FACT_tbl/Service_LVL

Delivery Country PROD_Delivery_Perf_Country_Dim/Service_COU

Delivery City PROD_Delivery_Perf_City_Dim/Service_CITY

Delivery Month PROD_Delivery_Perf_Time_Dim/Report_MONTH

Delivery Total Number of Count of projects from PROD_Project_Info_tbl for

Delivery Active Projects Count PROD_Delivery_Perf_City_Dim/ACT_PRJ_CNT

Delivery Closed Projects Count PROD_Delivery_Perf_City_Dim/CLOSED_PRJ_C

Delivery Cancelled Projects PROD_Delivery_Perf_City_Dim/CANC_PRJ_CNT

Delivery Number of Projects PROD_Delivery_Perf_City_Dim/RED_STAT_PRJ_

Delivery Total Revenue Loss PROD_Delivery_Perf_City_Dim/REV_LOSS

5. Function Point Analysis Approach

 Analysis of business problem and planning the Universe solution

5.1 Defining the Application Boundary

The following rule must apply for boundaries:

The initial boundary already established for the application or applications

1 IFPUG CPM part 1, 5.3 d

Case 1: Universe and Data Warehouse are separate application boundaries

Case 2: Universe and Data Warehouse are part of same application

Business Environment: This situation is frequently observed when the entire

5.2 Hints for Measuring Data and Transactional Functions

mentioned in following cases, depending whether Universe is part of Data

Case 1: Universe and Data Warehouse are separate application boundaries

Transactions for Creating and Maintaining the Universe Data

Counting Data Model

Case 2: Universe and Data Warehouse are part of same application