For selected MIS applications, implementing a packaged ‘off the shelf’ solution is the most cost effective and time efficient strategy to deliver necessary functionality to the business.
All of the benefits and uses of Function Point Analysis which applied to in-house development projects as described in the previous section can also apply to projects which tailor a vendor supplied package to an organisations specific business needs.
Experience shows that Function Point Counting of packages is not always as straightforward as sizing software developed in-house, for the following reasons:
The modelling of the logical business transactions often requires the function point counter to work with the client to identify the logical transactions. They do this by investigating the users functional requirements and interpreting the logical transactions from the package’s physical implementation.
In most cases the names of the logical files accessed by the application’s transactions are not supplied by the package vendor.
The function point counter will need to develop the data model by analysing the data items Processed by the application.
However, with sufficient care a reasonably accurate function point count of packaged applications can usually be obtained.
The project estimates for a package solution need to be refined for each implementation depending on the percentage of the project functionality which is:
The productivity rates for each of these different development activities (to implement, customise, enhance or build) are usually different. This complexity of assigning an appropriate productivity factor can be compounded when the package provides utilities which enable quick delivery based on changes to rule tables. Change Requests, which can be implemented by changing values in rule-based tables, can be implemented very efficiently compared to a similar user change request that requires source code modification. It is recommended that these different types of activities are identified and effort collected against them accordingly so that productivity rates for the different activity types can be determined.
The functions can be Flagged for their development activity type and their relative contributions to the Functional Size calculated. This will enable fine-tuning of the project estimates.
Another area of concern when developing estimates for package integration is the need to determine the extent that the application module needs to interface with existing functionality. The function point count measures the External Files accessed by transactions within this application. A high percentage of interface files (>10%) suggests a high degree of coupling between this application and existing applications. A high degree of interfacing tends to have a significant negative impact on productivity rates and needs to be considered when developing estimates.
Function Point Analysis is a technique that until now has been restricted within many organisations to only be used for better estimating or input into benchmarking productivity rates. The above examples illustrate a wider range of uses where it can contribute to the better management and control of the whole software production environment.