Applying Function Points to COTS applications

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 2^nd phase are also not considered while calculating initial baseline count. These functions once deployed in 2^nd 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.

 

NESMA and IFPUG - Main Difference

Main Differences in FP Analysis using NESMA and IFPUG

 

Preface

Although IFPUG and NESMA have worked closely since their inception, they do have some differences which make them derive different FP count for the same application or project.

This document describes the present-day differences in the NESMA and IFPUG counting guidelines.

IFPUG CPM 4.3 and NESMA CPM 2.1 versions are considered for the comparison. NESMA CPM 2.2 is the Dutch version of NESMA CPM 2.1 and both are completely interchangeable.

Please note that the NESMA counting guidelines have been stable since version 1.0 of the manual was published in 1989. IFPUG had 4 releases over the years.

Practically the same guidelines

NESMA and IFPUG both use the same terminology, albeit in a different language. The NESMA maintains

a list of English-language words related to FPA. Both NESMA and IFPUG differentiate the same five types of user functions: ILGV (ILF), KGV (EIF), IF (EI), UF (EO), OF (EQ).

The rules for determining the type and complexity of a function are the same, with a few exceptions:

•       External Inquiry vs. External Output

•       Complexity of an External Inquiry

•       Implicit Inquiry

•       Code data (Code tables)

•       Physical media

•       Queries with multiple selections (“and/or” situations)

In the following each topic is highlighted.

1.     External Inquiry vs. External Output

For IFPUG, an External Inquiry is defined as a function that presents data to a user from a logical file (ILF or EIF) without undergoing additional processing (such as calculations, updates to an ILF, etc.). In all other cases it is considered an External Output.

For NESMA, the same rules apply, but in addition, a unique selection key must have been entered and the output must be fixed in scope. In some cases, therefore, IFPUG will count an External Inquiry, while

NESMA counts the same function as an External Output (e.g. “Show all customers”).

The impact of this difference is marginal for the number of function points for a system or project because only the type of function (External Inquiry or External Output) is affected; not the number of counted functions.

 

2.     Complexity of an External Inquiry

For NESMA the functional complexity of the input part of an External Inquiry is based on the complexity rules for an External Input function; the complexity of the output part is based on the rules for an External Output function. The more complex of the two will be used as the complexity of the External Inquiry.

For IFPUG the functional complexity is determined in the same way as all other transactions, by counting the number of data-element-types crossing the application boundary and identified in the data-functions.

In practice the impact of this difference is marginal for the number of function points for a system or project.

3.     Implicit Inquiry

While modifying or deleting data, it is often being first presented to the user for viewing. This is known as an “implicit inquiry”.

For NESMA, the underlying goal of a function is always the primary objective. NESMA therefore does not consider the implicit inquiry as a separate transactional function, but as an integral part of the “modify- or delete” function. The data element types presented to the user by the implicit inquiry are therefore added to those counted in the “modify- or delete” function. NESMA will only count the External Inquiry if it is specifically identified by the user for the purpose of querying data.

IFPUG has included one example in CPM 4.3 which explains in detail “an implicit enquiry”. IFPUG considers it as an External Inquiry.

The impact of this difference is marginal for the number of function points in a system or project. Usually the user will have defined this function as an (explicit) inquiry (and it will thus be counted). The implicit inquiry will then not be counted (again) because the same function cannot be counted twice.

4.     Code tables

In general, entities can be seen as being composed of primary data ( “business objects”) or composed of secondary data (supportive data).

In the case of primary data, both NESMA and IFPUG follow the same counting guidelines.  Secondary data usually consist of code-tables, also called “FPA-tables” by NESMA.

As an example, consider the “translation table”: article code _ article description.

During data function counting, NESMA will classify all code tables as one ILF and/or one EIF. The number of record types will be set equal to the number of identified code tables. Altogether, the FPA table-ILF will also count for one External Input, one External Inquiry and one External Output. For the

FPA-table-EIF no transactional functions are counted, even though External Inputs or External inquiries may be present.

Since IFPUG CPM 4.3, IFPUG considers code tables to be an implementation of technical or quality requirements for the user, and not part of the functional requirements. In accordance with the ISO FSM standard, IFPUG has therefore decided that code tables and the transactional functions associated with them, are not to be counted using function points.

Once again, the impact of this difference is marginal for the number of function points for a system or project. The difference will be at most 25 function points for an FPA table ILF, and 20 function points for an FPA table EIF.

5.     Physical media

Physical media is ignored in NESMA counting practices. NESMA looks at the underlying functionality. If the number of data element types and the logical processing are the same, input entered through different media will be counted as one External Input by NESMA. The same holds true for External Outputs. Reports that can be presented on different media (print, screen, etc.) are counted as one External Output function (when the number of data element types and the logical processing remain the same).

In IFPUG CPM 4.3 no specific counting guidelines are given for this situation.

6.     Inquiries containing multiple selection criteria (“and/or” situations)

In the NESMA counting guidelines only mutually exclusive selections are to be counted.

IFPUG has no specific guidelines for this situation. Some IFPUG counters therefore, count every conceivable combination of selection criteria as separate functions, which may result in large differences in function points among IFPUG counters.

Thumb Rules in FP sizing

Thumb Rules in FP sizing

The following Rules of Thumb offer ways of approximating the efforts, schedule, defects and some other important metrics using FP sizing method.

References - Seminars by Caper Jones and B Boehm

 

1. Unadjusted FP size of a software = 35 * Number of Logical Files (30-35% variation)
2. Use case points/ 1.25 would give us an approximate FP size
3. FP^1.15 ~ Number of page counts for paper documents associated with a software
4. FP^1.2 ~ Number of test cases
5. FP^1.25 ~ Defect potential for new software project
6. FP^ 0.4 ~ Development schedule in calendar months
7. FP/ 150 ~ Number of personnel required for development of the application
8. FP/750 ~ Number of personnel required for maintenance of the application


Apart from this, there are FP to LOC and vice versa conversions mentioned by both Caper Jones and B Boehm.
Example -
1 FP = 320 statements of basic assembly language
1 FP = 128 statements of C
1 FP = 107 statements of COBOL
1 FP = 53 statements of C++ and so on.

Use these conversion factors for deriving FP from LOC size alternatively you can first derive FP and then translate it into LOC to calculate other metrics based on LOC size. Most of the parametric tool use this method to estimate efforts, cost and schedule.


 

Function Point Calculator

FP Calculator

 
In this document, I have provided a couple of snapshots of an excel based Function Point calculator, developed by me. Please write to me to get a downloadable copy. My email id is fpxpdek@gmail.com
 
The calculator uses IFPUG Function Point Methodology and provides an unadjusted Function Point count.

It has two worksheets VIZ. "Details" - containing details of all functional components and "Summary" - summarizing FP data in tabular and graphical form.

The users are supposed to apply IFPUG rules to identify functional components, their types, their DETs and RETs/FTRs and then record those values in "Details" worksheet to get FP size calculated and summary displayed automatically. By default, the calculator takes "average" complexity of each functional component.

The same calculator can be used for calculating FP using NESMA method.

Fig 1 - Details Worksheet

 

 

Fig 2 - Summary Worksheet

 

 



 

Function Point Analysis for GUI applications

Function Point Analysis for GUI applications

 

When Alan Albrecht introduced Function Points sizing method to the world, most of the applications/ projects were data rich applications or MIS applications. In those days, first generation languages such as COBOL, Fortran etc. were in use. But when next generation languages were introduced, critics started slamming FP methodology citing its inability to size GUI, scientific, and complex applications. However, later it was proved by various practitioners that, Albrecht’s FP can be leveraged for sizing the entire spectrum of applications including GUI, and complex applications.

In this document, I will try to explain some of the rules for GUI functions using IFPUG FP. GUI is an on-line display and processing of graphical data presentation. 

Following rules can be applied.

1.    Menu bar – File

a.    Open – EO/EQ

b.    File Save/ Save as/ Edit/ Update/ Create/ Delete – EIs

c.    File Print – EO/EQ

2.    Help – EQ

3.    Selection of an item from the pick list is usually a DET on an EI or input side of an EQ/ EO and not a separate function

4.    Mutually exclusive choices on the same screen may count as unique EQ

5.    Command button may specify add/ delete or change actions. A button like “Ok” may invoke several types of transactions. Each command button would be counted as a data element for the action it invokes

6.    Dropdown or pick list can be considered as EQ if coming from an ILF/ EIF

7.    Informational and warning messages other than error or confirmation messages are considered as EQs/ EOs

8.    Functions which permit selection of one choice out of multiple choices such as radio button/s, one DET should be considered on the EI or EO/EQ

9.    If multiple selections can be accepted just like check boxes, then count each independent selection as a DET

10. Implied queries must be counted as EQs

11. Logon screens that facilitate entry to the application are counted as EQ

12. Pictures on the screen (if not hard coded) can be considered as DETs

13. A sound byte can also be considered as a DET

Do not count

1.    File – New option

2.    Exit

3.    Extract files/ view files as ILFs

4.    Separate EO/ EQ when same results are output to paper and screen

5.    Refresh/ Cancel

6.    Maximize/ minimize/ Zoom – Functions provided by OS

7.    Scroll bars, “Next”/ “Previous” buttons and other navigation devices/ functions

8.    Drop down list which displays data not maintained/ hard coded data

9.    Multiple screens as separate EOs/ EQs

10. Resorting or rearrangement of data as separate EO or EQ

11. Common print options as they are provided by the environment

12. Hyperlinks on webpages

 

 

Function Point analysis using NESMA method

Function Point Analysis using NESMA

NESMA is Netherlands Software Metrics Association group which was set up in 1989. NESMA’s Function point methodology is a derivative of Alan Albrecht’s (IFPUG FP) method. NESMA claims that its method is meant for everyone who performs function point counts. For those using IFPUG (International Function Point Users Group) rules, NESMA standard can be valuable supplement. It consists of additional guidelines, hints, and examples that can be of value to the FPA counter.

NESMA released its first version of FP manual in Dutch in 1990. English version was released in 1997. Currently NESMA FPA manual version 2.1 is in use. This version provides rules and guidelines to calculate unadjusted Function Point count and is recognized by ISO (International Organization for Standardization).

In this document, I will try to brief 3 NESMA methods of counting Function Points. These three methods are – Indicative function point count, Estimated function point count and Detailed function point count. The methods, Estimated and Indicative function point counts have been developed by NESMA to enable function point counting early in the system life cycle. The NESMA indicative function point count is well known in the world and is referred to as "the Dutch method".

1.    Indicative FP count – It indicates the size of an application or a project based on either conceptual data model or normalized data model

If the data model in conceptual form is available then formula for # of FP is

# of FP = # of ILFs*35 + # of EIFs*15

If the data model is third normal form then following formula is used

# of FP = # of ILFs*25 + # of EIFs*10

Indicative FP count can almost be carried out at the end of requirements phase. It is good for a ballpark estimate. However this count will give a deviation of up to 50%

2.    Estimated FP count – It determines the number of functions for each function type and uses a standard value for complexity: Average for transactional functions and Low for data functions

 

The formula for deriving estimated FP count is as below.

 

# of ILFs*7 + # of EIFs*5 + # of EI*4 + # of EOs*5 + # of EQs*4

 

This method can be used whenever

a.    A quick estimate is required

b.    Detailed information about data/ transactions is unavailable

c.    Quick turnaround time is expected

d.    Accuracy of the count is not a concern

 

3.    Detailed FP count

The detailed FP count is the most accurate count in which all specifications needed for FPA are known in detail. This means transactional function types have been specified up to the level of data element types and referenced logical files and data function types have been specified up to the level of record types and data element types. This detailed function point count is similar to the unadjusted function point count of IFPUG method. This count costs more time and needs more detailed specifications as compared to Indicative and Estimated FP counts.

 

Comparing various Function Point methods

We all know that, IFPUG Function Point method was the first one to get established as a functional sizing technique. But during 90's, many other groups, practitioners developed alternative methods. Today there are half a dozen well established functional sizing techniques which can be selected for estimation, benchmarking, balanced score card metrics analysis etc.

In this document, I will try to compare these methods for various parameters such as applicability/ scope, ease of understanding, flexibility, benchmarking usage, certification, geography, unit of measurement, ISO recognition and so on. The detailed comparison is embedded in the picture below.
The methods which got compared here are
IFPUG FP
NESMA FP
COSIMIC FFP
SPR Feature Points
Mark II FP
and
FiSMA FP