Applying
Function Points to COTS applications
My first project in Function Point Analysis
was to count a COTS (Commercial off the shelf) application. I must admit that,
initially, I have had a very tough time in leveraging FP principles to that
application. But in the end, I was able to manage it well. In this document I
will share some of my findings while applying Function Points to COTS
applications.
What
are COTS?
The traditional definition of COTS software
is the software sold by a commercial software vendor, usually with a
maintenance contract for a defined period of time.
The basic purpose of buying COTS software
is to reduce overall risk, complexity and costs associated with the development
of the product and maximize return on investment (ROI). The cost mainly includes,
1.
Development cost
2.
Resource costs
3.
Research costs
While
in many cases this may be a wise strategy towards fulfilling the business
needs, there is no guarantee that the use of COTS will result in a cheaper,
faster, and higher quality solution for meeting those needs over in-house
development.
There
is a prevailing belief, or rule of thumb, within the IT Industry that if a
software solution can be purchased that will provide at least 80% (the 80/20
rule) of the desired business functionality it will be more cost effective to
buy rather than build. However, this “rule of thumb” may not always hold true
and many programs end up being over budget, late or even ultimately cancelled.
The organizations can do cost benefit
analysis using Function Points to evaluate this decision.
Having said this, I would like to inform
readers that now days, there is a growing trend of buying a product from third
party vendor simply because it provides more value in terms of cost.
Important
Facts about COTS application –
Being developed by a third party vendor, many
times, most of the functions, components, and database are kept hidden to the
buyer. The software vendor due to its strategic, marketing and legal issues
tends to hide important/ core information from the buyer. So for the buyer, it appears to be a black
box. This adds to the complexity of counting such applications.
There are two ways in which these COTS
products can be bought – AS IS or With Customization. Most of the times, it
requires some customization, configuration of the COTS products to be able to
fit them into buyer organization’s environment.
All these aspects should be considered
while calculating Function Points.
Guiding
Principles –
Here are some of the guiding principles.
1.
COTS products can provide “n”
number of functions many of which may not be used by the buyer organization.
Such redundant functions are not considered while calculating FP.
2.
Functions which are customized
via modification, addition should be considered.
3.
Functions which are deleted or
disabled as part of customization are not considered.
4.
Functions which are planned to
be used in 2nd phase are also not considered while calculating
initial baseline count. These functions once deployed in 2nd phase
can be identified and retrofitted to the initial baseline count of the
application.
5.
The interfaces developed as
part of COTS fitment should be considered as appropriate.
6.
Functions which are built one
time for COTS fitment are also considered in the initial baseline count.
7.
The freebies or additional
modules which may come along with the COTS product but which are of no use to
the buyer organization can be skipped.
8.
The internal database created
or customized for COTS fitment should be considered.
9.
The database from COTS
application (if known) which is being used should only be considered. The
database related to the redundant functions should not be considered.
10.
If a function is repeated in
different modules of the COTS product, then it should be considered only once.
Simplifying
method –
While counting any COTS software, use
following steps
1.
Refer operational manual/ user
manual which would provide an insight on the functionality offered by the software
product.
2.
Request for an in-depth
demonstration of the software either from the vendor or Business Analyst/ SME.
3.
Study “Help” function to
understand the functionality provided by the software.
4.
Determine the functions in
scope.
5.
Understand and identify all transaction
functions after referring to the user manual and software demo.
6.
For each transaction function, identify
logical data base. This is not an easy step especially for any rookie counter.
Taking help from a business analyst or project manager for determining database
structure is advisable.
7.
After identifying data
functions and transaction functions, apply “Default” complexity method to
determine the complexity of those functions. The “Default” complexity method
assigns, “Average” complexity to transactional functions and “Low” complexity
for data functions. (This method is even supported by NESMA)
8.
You can also apply NESMA
indicative or estimated method to determine ballpark size in case detailed
information about data functions and transaction functions is unavailable
9.
However, stick to one approach/
method for both data and transaction functions
10.
Make and note assumptions
wherever possible with the help of SMEs or Business Analyst
I am sure above notes would help you fine
tune your approach in counting COTS applications.
Size
–
A caution of note to all the readers - FP
count of COTS applications may run into 50K or even 100K function points so it
is imperative to use a robust recording tool to minimize counting errors, time
and resources. Workbench tool from Charismatek and Scope from Total Metrics are
of good help.
Applicability
–
Forecasting applications, free and open
source softwares, SAP applications, Peoplesoft applications etc. can be counted
using above practices.
