New Environments Committee Hints To Counting Third Party Software Applications

New Environments Committee
Hints to Counting Third Party Software Applications
Note: The NEC has established these White Papers in an effort to distribute
hints about a subject domain quickly to the counting community.
This document is based on the function point counting practices as described in the
current 4.2 series of the IFPUG Counting Practices Manual (CPM) and
demonstrates the applicability of IFPUG Function Points in the subject domain.
The contents of this paper are to be used exclusively as hints in the application of
function point counting in the domain described.
These hints do not constitute rule changes and should not be used as rules. While
this document has been reviewed and approved by the CPC, it does not constitute
IFPUG counting practice standards as contained in the CPM.
Introduction
Using current counting practices, as described in the CPM 4.2 series, this paper presents
a cohesive set of hints on how to apply Function Point Analysis (FPA) to establish the
function point size of a third-party software application; for example a Commercial-Off-
the-Shelf (COTS) or Enterprise Resource Planning (ERP) software product, etc.
The paper will present several scenarios within a third-party software environment. The
Function Point Counting procedures in the CPM are used to specifically address the
issues when counting an application in a third-party software environment. The results
of the function point count can be used to provide the criteria that support the decision of
whether to build an application or to buy a package that satisfies the functionality
required.
The function point count of candidate packages can also be used as criteria for selecting
an appropriate package by comparing the functionality provided by each. The package
function point counts can be used to help manage the ongoing support and maintenance
of the package after installation. Examples of how to analyze the results of the function
point count in decision making and management processes are provided for each
scenario.
The specific function point counting procedures addressed in this paper are:
• Scope of the count
• Identify the application boundary
• Determine the data and transactional functions
For the exact definitions of user, boundary and data or transactional functions, please see
the CPM.
Copyright IFPUG 2004 Hints to Counting Third Party Software Applications Page 1
New Environments Committee August 27, 2004
Purpose of this document

The purpose of this document is to demonstrate various approaches that can be used
when applying function point analysis techniques to third party software. This paper
does not address conversions required as part of the package implementation, embedded
software or component based development (CBD). These environments are addressed in
separate papers available through the IFPUG web site.
Third-Party Software Environment
In order to make an informed decision it is necessary to have a detailed understanding of

the stated user requirements and the functionality that third-party software packages
provide. The advantage of using FPA when evaluating and acquiring third-party software
is that attention is focused on the relationship between the functionality provided and the
cost of acquisition and customization.
With the help of FPA, a decision of creating an in-house application or buying a third-party
software solution is facilitated based on the user requirements and the costs involved to
either develop or buy the application. The implications of on-going support for either of
these choices should also be considered.
This paper describes three scenarios:
• Scenario A describes the use of FPA in a make or buy decision based on business
requirements. In order to determine the best decision, the functionality provided by
the packaged application is documented using FPA methods. After the count is
complete, the package requirements are compared to the user requirements and a
determination is made of whether they meet, partially meet or do not meet
expectations.
• Scenario B describes the use of FPA in evaluating different packages against each
other to determine the best purchase option for the desired functionality and
associated cost. In this case, each packaged application’s functionality is compared
against the other candidates as well as the stated user requirements and an analysis
of the cost per function point is completed.
• Scenario C describes the use of the FPA in sizing an installed purchased package.
In this case the information can be used to determine proper staffing levels needed
to support all application functionality installed in an organization, report the
developed versus acquired functionality and determine staffing requirements to
support software upgrades and maintenance from the third party provider .
In all 3 scenarios, partial and not met requirements must be evaluated to determine how
they will be addressed, either through modification of the package or software
development. There may also be additional functionality provided by the application
package that is beyond any stated user requirement.
Approach
The function point count carried out during the phase in which the specifications are
recorded is a reflection of the amount of functionality a user requires. This count is
independent of the solution to be chosen and is separate from whether the package is
implemented or not.
At the end of the specification phase, a decision needs to be made on whether to build an
application or to buy a package that satisfies the functional requirements. Multiple
packages can also be compared to determine which package represents the best cost
alternative. A package implemented in an organization represents a certain quantity of
functionality that (partly or in full) covers the user requirements and the appropriate support
resources must be determined.
The approach taken to establish the function point count for a package is highly
dependent on the availability and quality of the package documentation. Other than that,
the approach is no different than the one described in the CPM. Note: During analysis
for a make versus buy decision the actual packages are not normally acquired. Usually,
there is a demonstration of the software or an evaluation copy is made available users
manuals and or guides may or may not be made available. The analysis should be
completed utilizing the materials available.
Purpose of the count

• What functionality required by the user can the package provide, and what is the
number of the function points of this functionality?
• What functionality required by the user can the package not provide, and what is the
number of function points of this functionality?
• What functionality not required by the user does the application package provide,
and what is the number of function points of this functionality?
• What functionality required by the user is provided by the package but requires
modification to meet the business need?
Scope of the count

To determine the scope of the function point count consider the following:
• What are the business requirements? This will provide input when establishing the
function point counts and boundaries for the application(s) to be counted.
The following is a diagram of the solution for a set of user requirements mapped to an
application package that was purchased as a partial solution.
Application package Application package

Required functions “used as Required functions modified
is” (group 2) Required functions to be
(group 1) added
(group 4)
Application package - not required functions

(group 3)
The following describes the contents of the diagram:
− Group 1 represents the function points counted as required that a package can
supply and can be “used as is”.
supply and can be modified.
− Group 3 represents the surplus functionality that an application package provides
that are not currently needed, but may satisfy future requirements. This may be a
reason to choose a package. The additional functionality, however, falls outside the
scope of the user requirements and is not part of the project function point count.
− Group 4 makes up the number of required function points not provided by the
package. These function points are not part of the function point count of the
package, because the function point count should reflect the required functionality
that is provided. However these additional function points are part of the overall
project function point count.
The scope of the count of the packaged application includes the functionality provided by
Groups 1, 2, and 3. For analysis purposes, the scope of the project count for the desired
functionality would include Groups 1, 2 and 4.
Application boundary
An application package often includes more than one application boundary. A complete
ERP-solution includes functions for Finance, Logistics, etc. Each is usually defined as a
separate boundary. For user requirements, establish the boundary of the application(s)
with the user as stated in the CPM. Note: It is strongly advised that all assumptions made
about the functionality provided by the package and those that went into the function
point count be documented. The documentation of assumptions and counting decisions
can provide insight as to the accuracy of the count (i.e., how much might have been
missed or over-counted).
Determine the data and transactional functions
Count the data functions of a package

When an application package is acquired, a conceptual data model is not typically supplied
as part of the documentation. In other cases, you will have a data model of the package at
your disposal. The data functions can be derived from this data model.
If a data model is not available, analyze the maintenance functions to determine the logical
files as described below.
By making a cross-reference (e.g., a CRUD-matrix1) with the identified transactional

functions you can either derive data functions from those transactional functions or check
the “completeness” of identified data functions or transactional functions. For example, the
transactional function “maintain employee” should at least yield a data function
“employee”.
Also the data function type can be derived from a cross-reference:

• Count an ILF when a transactional function Creates, (Reads), Updates or Deletes a
logical data group.
• Count an EIF when a transactional function only reads the logical data group.
Watch for data groups, which may be dependent on other data groups and should be
considered as RETs.
When information about DETs is not available from other sources, requirements, estimates
or educated guess, assume “average” for complexity of the data function.
Count the transactional functions of a package

Obtain a user manual of the application package. Sometimes it may lack the details needed
to carry out a function point analysis. If functional specifications are missing or are
1
CRUD = Create, Read, Update or Delete
insufficient, it may be necessary to derive (a part of) the logical functions from the physical
components of the application. One option is to start up the application concerned and
count from the screens. Also consider the batch-functions.
Consider the following when you derive functions in this fashion:

• Prevent double counting: The same transactional function can appear at several
places in a menu structure.
• Pay attention to subsequent screens: Screens bound together may define only
one transactional function.
• Identify the reports from the screens, the menu structure, or available
documentation. Count each individual report as one external output or an
external inquiry using the rules in the CPM.
• Sometimes a report with the same layout can be shown via different media; e.g.,
display screen and printer. When the logical processing is the same, only one
external output or external inquiry should be counted.
• Count list functions as separate external inquiries if data is read from an ILF or
EIF.
• Using the documentation or menu options, determine which transaction files
exist. Count these files accordingly as either external inputs or as external
outputs/inquiries. Also determine how many external inputs and external
outputs/inquiries should be identified per transaction file, which make up unique
elementary processes.
• Try to derive from the maintenance functions which logical files the user can
maintain; in other words, which internal logical files are present.
• Examine batch functions.
If only the menu structure is available, try to determine the functions from it. Assume
three external inputs (add, change, and delete) for a menu option such as maintain.
For a menu option such as display/browse/lookup, assume one external inquiry for
each summary list of data-records (like a drop-down selection list) and an additional
external inquiry for a detailed view of a data-record as indicated.
When information about DETs and referenced logical data groups is not available (or
cannot accurately be determined) from other sources, requirements or estimates,
assume “average” for complexity of the transactional function.
The Make/Buy Decision
Establish project estimates

Using the function point counts developed above define the different project scenarios that
will lead to making the make/buy decision. First define a project that includes the function
points that are defined in Groups 2 and 4 in the above model. This represents the size of the
development project for the functions that need to be enhanced as well as those that have to
be developed completely. Next define a project that represents the size of Groups 1, 2 and
4 in the above model. This represents the size of a “make” development effort. Utilize the
resulting function point project sizes to estimate the cost, effort, staffing and schedule that
would be created for each project alternative. These are the critical inputs into the
make/buy decision.
Make/Buy Analysis
The function point information and estimate data from above is used to conduct the
Make/Buy Analysis. The Make/Buy Analysis is the decision making process to
determine whether to implement a package solution or build a custom solution. Based on
the information from the previous steps the following are some initial decision points:
Buy “As Is” if:

1. The users are prepared to live with the package functionality.
2. The users are willing to change their business processes to adapt to the package
application.
3. The sensitive schedule is an overriding factor. This means delivering the
functionality in a certain time frame takes precedence over how the users would
like the business process to be. Basically, the schedule is the highest priority and
it drives the decision.
4. Development and future maintenance funding is limited. If there isn’t going to be
any money available to maintain or enhance a modified or developed system then
it may be best to rely on the package provider for enhancement and maintenance
support.
Customize Package if:

1. The cost to customize the package product is more viable than building.
Development costs as well as ongoing support and operation costs should be
included.
2. Minor customization is necessary to meet the user requirements.
3. The schedule is relatively sensitive. If developers can take advantage of existing
package functionality and modify a minimal number of functions, then the
development time frame will be shorter. If a short schedule is a requirement, then
business functions should be evaluated to determine if they could be changed to

utilize the package functionality, therefore limiting the customization.
Custom Develop (no package) if:

1. A significant number of requirements are not available. If the user requirements
are very specific and cannot be changed to use the existing package functionality,
then building them from scratch is the best option.
2. Initial cost of the package, including enhancement and support dollars, is higher
than developing and supporting the application in-house.
3. Ongoing upgrades are cost prohibitive. This point considers the cost of
implementing future upgrades to the package product. If installing the upgrades
requires rework of the customizations then it is possible that significant
development effort would be incurred each time an upgrade is installed. If this
situation occurs, it would not be cost effective.
Counting Scenario B – Evaluating Different Packages
The following diagrams represent the user requirements mapped to two competing
application packages that are being evaluated for purchase.
Application Package #1 being considered
Application package functions Application package

“used as is” functions requiring Application functions need to
(Group 1 = 100 FPs) modification be developed
(Group 2 = 75 FPs) (Group 3 = 100FPs)
Application Package #2 being considered
Application package Application package functions Application functions

functions “used as is” requiring modification need to be developed
(Group 1 = 75 FPs) (Group 2 = 125 FPs) (Group 3 = 75 FPs)
The following describes the contents of the diagram:
supply and can be “used as is”.
supply and can be modified.
− Group 3 makes up the number of required function points not provided by the
package. This represents the shortfall in functionality for this package.
Purpose and scope of the count

Scenario B describes the purpose of the count in evaluating different third-party packages
that provide similar functionality. In this case the baseline or function point count only
considers the actually utilized functions each application package as well as the functions
that have to be developed to meet the user’s needs.
Functionality provided by the package but not specifically requested by the user can be
included when determining the package's application function point count but it must not be
included in the user's baseline function point count.
• What are the business requirements?
• What functionality required by the user is provided by each package, and what is
the number of the function points of this functionality?
• What functionality required by the user does each package not provide, and what is
the number of function points of this functionality?
• What functionality required by the user that is provided by each package needs
modification? How will that modification be accomplished?
The boundary of each packaged application is defined as the functionality provided by
each application. By making a cross-reference of the user requirements against each
package’s identified functions; you can check the “completeness” of required data functions
or transactional functions. A package may consist of multiple applications and therefore
multiple application boundaries may need to be established.

The same process used in the Scenario A can be used when counting the data and
transactional functions. Refer to the previous discussion for hints in applying the FPA
procedures.
Analyzing the results

The basis of this decision is driven by how well the package meets the user’s needs as
well as the normalized cost of the project. The following formulas can be used to
evaluate how effectively the functionality provided by various packages meet the needs
of the organization.
Use the following formula to determine the degree to which a package meets the users
needs: Meets user needs = FPs “used as is” ÷ Total Project FPs. Using the example
from the diagrams above the percent of the package functionality that meets the user
needs is:
Package Meets user needs as Total Project Percent meeting

Number is FPs needs
Package 1 100 275 36%
Package 2 75 275 27%
Use the following formula to determine how much of the package will have to be
customized to meet the user’s needs: Needs modification = FPs “requires modification”
÷ Total Project FPs.
Package Package FPs needing Total Project Percent meeting

Number modification FPs needs
Package 1 75 275 27%
Package 2 125 275 45%
The following formula is used to calculate how much functionality will have to be
developed: New development = FPs “needs to be developed” ÷ Total Project FPs
Package FPs needing Total Project Percent meeting

Number development FPs needs
Package 1 100 275 36%
Package 2 75 275 27%
Knowing how effectively a package meets the user’s needs is only one part of the
decision making process. It is also necessary to consider the normalized cost per
function point of the potential solutions. There may be situations where a package may
have a high percentage of the functions needed by the cost per function point is
significantly higher than an alternative solution. The following formula helps to evaluate
the cost impact of the potential solutions.
Project cost per function points = (Package Costs2 + Package Modification costs +
Software Development costs) ÷ Total Project FPs.
2
When evaluating the costs of packages be sure to consider not only the upfront acquisition costs but also
evaluation costs, seat or site license costs, and annual support and operation costs.
Counting Scenario C – Sizing Installed Package
Purpose and scope of the count

Scenario C describes the purpose of the count in sizing an installed purchased package. In
this case, the baseline or function point count only considers the actually utilized functions
of the application package. These baseline counts can be used in portfolio management
activities, etc.
Functionality provided by the package but not specifically requested by the user OR
functionality not recognized by the client must not be included when determining the
package's application function point count.
• What functionality is provided by this package, and what is the number of the
function points of this functionality?
The boundary of the packaged application is defined as the functionality provided by the
application. See also previous remarks about establishing the application boundary(ies)
of a packaged application.

The same process used in the Scenario A can be used when counting the data and
transactional functions. Refer to the previous discussion for hints in applying the FPA
procedures.
Summary
Once the size of an installed package is known the information can be used to help manage
the I/S organization. Various metrics can be developed including:
• Measuring maintenance productivity which can be useful in planning for
staffing needs, evaluating the cost savings of using the package or to compare
the maintainability of one package to another.
• Tracking and reporting the percent of developed versus delivered software.
• Tracking, reporting and comparing package quality (defects per function point)
Conclusion
Counting the size of third-party software packages may satisfy various objectives such as:
• Establish the price-performance ratio of a package solution. In other words, what
will be the package cost per function point? When this is assessed, only the
function points of the functionality that the user or customer requires and that the
package is going to provide are relevant. Also consider the costs for enhancing
the package for the user requirements not included in the package.
• Comparison of the price-performance of a packaged solution with the cost of

developing and maintaining an “in-house” application.
• Establish the ratio between the functionality provided by a package that a user or
customer requires and the total functionality the user or customer requires. This
would include the identification of both additional and changed functionality.
• Establish the support costs of the packaged applications and relate to the costs
associated to traditional “in-house” developed application support.
Works cited:
Definitions and Counting Guidelines for the Application of Function Point Analysis,
version 2.0 – The Netherlands Software Metrics User Association (NESMA)
www.nesma.org.
Evaluating COTS Using Function Fit Analysis – Lori Holmes – STC Crosstalk, February,
2000 http://www.stsc.hill.af.mil/crosstalk/2000/02/holmes.html.

New Environments Committee Hints To Counting Third Party Software Applications

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

New Environments Committee Hints To Counting Third Party Software Applications

Uploaded by

Copyright:

Available Formats

New Environments Committee

Hints to Counting Third Party Software Applications

Purpose of this document

Third-Party Software Environment

In order to make an informed decision it is necessary to have a detailed understanding of

Purpose of the count

Scope of the count

Application package Application package

Application package - not required functions

The following describes the contents of the diagram:

Determine the data and transactional functions

Count the data functions of a package

By making a cross-reference (e.g., a CRUD-matrix1) with the identified transactional

Also the data function type can be derived from a cross-reference:

Count the transactional functions of a package

Consider the following when you derive functions in this fashion:

The Make/Buy Decision

Establish project estimates

Buy “As Is” if:

Customize Package if:

business functions should be evaluated to determine if they could be changed to

Custom Develop (no package) if:

Counting Scenario B – Evaluating Different Packages

Application Package #1 being considered

Application package functions Application package

Application Package #2 being considered

Application package Application package functions Application functions

The following describes the contents of the diagram:

Purpose and scope of the count

Determine the data and transactional functions

Analyzing the results

Package Meets user needs as Total Project Percent meeting

Package Package FPs needing Total Project Percent meeting

Package FPs needing Total Project Percent meeting

Counting Scenario C – Sizing Installed Package

Purpose and scope of the count

Determine the data and transactional functions

• Comparison of the price-performance of a packaged solution with the cost of

You might also like