|
|
home | about Q/P | contact us | |
|
|||||
| article | ||||||||||||||||||||||
 |
by Lori Holmes Introduction Today many organizations are attempting to reduce software development effort and schedule by purchasing off-the-shelf solutions rather than building them in-house. This strategy can be very cost effective if the Commercial Off-The-Shelf (COTS) solution meets the customer requirements. Unfortunately in numerous situations, COTS solutions have proven to be a great disappointment. This is largely due to the lack of fit in meeting the required functionality. The result is a major COTS enhancement project comparable to a custom developed solution in terms of overall project schedule and cost. In one such situation, it was found that the COTS solution fit only 2% of the requirements. 98% of the solution would have to be delivered as new development and enhancements to the COTS package. Luckily in this situation, the problem was identified early in the process and the proposed COTS solution was rejected. The situation described above and similar experiences highlight the fact that it is important to conduct a complete and accurate assessment of how well a COTS solution fits the requirements and not rely on vendor claims of high compatibility. This article will discuss a technique that has proven to be successful for projects in evaluating the compatibility of COTS products to customer requirements. The technique, called Function Fit Analysis, is based on function point analysis. Function point analysis is the decomposition of an existing or planned system based on the user's perspective of functional requirements. Function points therefore can be used to evaluate various COTS solutions, select the best solution, and determine the degree of enhancement work necessary to meet customer requirements. Function Fit Analysis provides the ability to:
To count function points it is necessary to understand the counting rules as well as the user requirements of the project or system being assessed. For that reason it is important to have knowledgeable participants and supporting documentation available when conducting the count. The function point process as defined by the International Function Point User Group (IFPUG) follows: The Function Point Analysis Process  There are three types of function point counts; they are Development project count, Enhancement project count and Application count. Determining which count to be produced is the first step in the process. The different types of counts and how they are used in the Function Fit Analysis process are described below. Development project counts are used to size projects with totally new functionality and include all functions being developed. In Function Fit Analysis the development project count would compare to the 'custom developed' alternative. Enhancement projects are modifications to existing systems and include application functions that are added, changed, or deleted. This is the type of count used when evaluating specific COTS alternatives in the Function Fit Analysis Process. It identifies the enhancements necessary in the COTS product for it to meet customer needs. The final type of count is an Application count. This is the function point count of any installed system. Once a system is in existence this is the function point count of all the functions provided to the user regardless of how they were delivered (i.e. developed versus COTS). To complete a function point count, user recognizable functions are identified and evaluated. From a user's perspective, a computer application assists them in doing their job by providing five (5) basic functions. Two of these capabilities address the data requirements of the business and are referred to as data functions. Data functions consist of Internal Logical Files (ILF) and External Interface Files (EIF). Three of these capabilities address the user's need to access and manipulate data stored on the files and are referred to as transactional functions. Transactional functions consist of External Inputs (EI), External Outputs (EO), and External Inquiries (EQ). The Five Components of Function Points Data Functions
The second function of an application provided an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another application and is maintained by another user. The user of the application being counted requires the other application's data for reference purposes only. For example, a user may require the ability to access security information from the security application. The user does not have the responsibility for updating security information but must reference it to complete their job. Groupings of data from another application that are used only for reference purposes are defined as External Interface Files (EIF). The remaining functions address the user's capability to access the data contained in ILFs and EIFs. This capability includes maintaining, inquiring and outputting of data. These are referred to as transactional functions. The first transactional function allows a user to maintain Internal Logical Files through the ability to add, change and delete the data. For example, a user can add, change and delete employee information on the employee master file. In this case the user is utilizing a transaction referred to as an External Input (EI). An External Input gives the user the capability to maintain the data on ILFs through adding, changing and deleting its contents. The next function gives the user the ability to produce outputs that contain calculations. For example a user may require a report that contains expense data with derived information. The report is produced using information that they maintain and information that they reference. In function point terminology the resulting report is called an External Output (EO). The final capability provided to users through a computer application addresses the requirement to display specific data from files. In this situation there is no manipulation of the data, it is a direct retrieval of information contained on the files. For example a user can inquire on employee data by inputting a social security number and retrieving employee data. These transactions are referred to as External Inquiries (EQ). Two adjustment factors are applied to calculate the function point count. The first adjustment, functional complexity, assigns weights to each functional component based on data elements and processing logic. The second adjustment, the Value Adjustment Factor, evaluates the operational complexity of the application. Function points are just one piece of information that is used in the Function Fit Analysis process. The Function Fit Analysis process consists of five primary steps that are described below. Function Fit Analysis Process  Step 1: Requirements Function Point Analysis This step is used to identify and document exactly what functionality is necessary to meet the customer needs. This assessment should be completed early in the development life cycle to provide insight into the scope of the project. It can be completed early because it is based on what functions are to be delivered and not how they are to be delivered. During this step, a function point count is completed based on documented functional requirements or by analyzing the functions of an existing system to be replaced. It is important to focus on the 'to be' version of the system and to identify all of the functions necessary to meet the users' needs. The analysis should focus on quantifying user requirements only and not on potential COTS solutions. The result of this step will be a development function point count and a detailed listing of the functions necessary to meet the requirements. For example, a course registration application may contain the following functions:
Step 2: COTS Functional Evaluation This step involves reviewing the various COTS choices and comparing their functionality to the requirements documented in the first step. From a function point perspective, this is an enhancement project count since we are starting with a system and identifying changes necessary to meet the functional requirements. Using the function point count from step one as a guide, each database and panel in a COTS alternative is reviewed to identify functions that: A. Exist in the COTS with no change required [Unchanged] B. Exist in the COTS but require enhancements to meet the requirements [Change] C. Need to be added to the COTS product [Add] D. Exist in the COTS but are unrelated to the requirements and will not be used [Unused] The resulting enhancement function point count will summarize how well the COTS product matches the functional requirements. Using the example functions from above, the COTS evaluation function point count will contain the following:
The COTS enhancement project function point count will include the functions that are being added and changed. The first analysis of results should compare the function point size of the COTS enhancement project to the function point size of the custom develop solution. If the enhancement function point size is not significantly less than the custom develop solution then the COTS solution might not be the best 'fit'. The second step of the analysis is to evaluate the 'Unchanged' functions since this will represent what portion of the solution 'fits' the user requirements. The 'Unused' functions show how much of the COTS product is unusable and not related to the requirements. Step 3: Functional Fit Analysis This step is used to apply a percentage to the 'fit' between the requirements and the COTS product. By comparing the function point counts from the previous two steps a fit can be determined. One of the first tasks is to define what 'fit' means in the minds of all those involved in the assessment. There are different ways of looking at fit depending on the approach used. In Function Fit Analysis (FFA), 'fit' is defined as the amount of out-of-the-box functionality that can be utilized without any modifications. Using this definition, a comparison of the requirements function point count to the COTS function point count will result in calculating the 'fit' percentage of the COTS. (FFA fit = Unchanged FPs ¸ Total FPs from Step 1) In addition to the 'fit' calculation, analysis of the percentage of added and changed functions is also useful. These percentages can be calculated by identifying the 'Added' and 'Changed' functions from Step 2, calculating a function point count, and evaluating it against the total function point count from Step 1. The 'Added' function point count will show the amount of user requirements that are not supported at all in the COTS product. Obviously if this is a large number it may be better to look at a different alternative or consider a custom developed solution. Identifying 'Changed' functions is helpful in evaluating whether to enhance the COTS to meet the business requirements, modify the business process to meet the COTS, or a combination of both. This analysis provides an opportunity to revisit certain functions with the users to see if the requirements are flexible. The following table details the Added, Changed, and Unchanged Function Points for a project.  Identifying and quantifying the 'Unused' functions in the COTS product can be helpful in a couple of ways. First, they are used to determine how much of the purchase COTS solution will not be utilized. Second, reviewing these functions with users may help to generate ideas on how to improve the business process in the future. Knowing the 'fit' numbers is one piece of information that is helpful in the make/buy decision. The other piece of information is the estimate to deliver the functions in the various options. This leads us to the next step in the Function Fit Analysis Process, Project Estimates. Step 4: Project Estimates The function point data from the previous steps is used to develop the project estimates in Step 4. This step uses a top-down approach to estimate effort, staff, and schedule for each alternative under review. The first estimate will be for the 'custom developed' alternative. The are two components to developing an effort estimate. The first is project size, which is the function point count from step one of the Function Fit Analysis process. The second component is an evaluation of the project attributes. Project attributes are the factors that, in addition to project size, influence software development productivity. Four major categories of attributes are evaluated. Personnel and Management - focuses on knowledge and experience of I/S and user personnel involved in the project.
A similar process is followed for each COTS option under review. For this analysis the project size is based on the enhancement function point count completed in step two of the Function Fit Analysis Process. Project attributes should be reviewed to see if the previously completed assessment applies to the COTS alternatives. Enhancement productivity rates differ from development productivity rates depending on project size, so the effort estimates for the COTS alternatives may not use the same productivity rate (function points/hour) as the custom development option. At this point there is enough measurement data about the functional requirements to feed to the Make/Buy decision step. Step 5: Make/Buy Analysis The function point information and estimate data from Steps 1 through 4 is used in Step 5, the Make/Buy Analysis. The Make/Buy Analysis is the decision making process to determine whether to implement a COTS 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:
COTS Costs Make sure to include all the costs associated with the COTS product. This would include Evaluation costs, Initial purchase costs, Seat or Site license costs, and Annual support and operation costs. Access to package specifics Discuss with the COTS vendor what technical components of the product will be available to the in-house developers. For example, will they have access to the data model or process model? What 'hooks' are available to the developers for adding custom code? Is there a coding standard the COTS provides to ensure custom built components will have the same look and feel as the core product? Ownership of Customized Software Once the COTS solution has been purchased and customization is completed there may be a gray line defining who owns what. Make sure you understand the rules up front. Customization Responsibility Determine up front who will be making the changes to the COTS and what the associated costs will be. This may also dictate who owns the customized code. Existing Database Structure Some organizations have strict guidelines on naming conventions and structures. It is beneficial to examine the COTS database structure to see if it can easily comply with your organization. If it does not, a decision can still be made to change the organization rules to meet the COTS. Existing Computing Architecture This will be important if the COTS product needs to communicate with other in-house, non-COTS, applications. The compatibility should be examined to determine the amount of work necessary to integrate multiple systems. Once the above information is gathered and analyzed the Function Fit Analysis Process is complete and an appropriate Make/Buy decision can be made. The data and findings from the process should be documented and stored in a repository for reference. The information may be helpful in future analyses of this kind. Summary There is a great deal of information that is necessary to make an informed decision of whether to utilize COTS in development efforts or not. The Function Fit Analysis Process provides an excellent framework for information gathering, evaluation, and decision making. It communicates functional requirements in objective terms so the COTS can be evaluated from a 'fit' perspective and identifies functions to evaluate for possible business process reengineering efforts. Since Function Fit Analysis provides a size metric for the development options it enables estimates to be made in terms of effort, staff, and schedule. Without knowing 'what' needs to be delivered it is impossible to determine a good estimate of how long it will take to deliver it. Function Fit Analysis gives us the 'what'. In today's world of providing things better, faster, and cheaper it can be difficult to determine the best option. The use of COTS products has been touted as a faster and better method for software development, but that is not always the case. Function Fit Analysis is a valuable technique to help evaluate purchased/customized solutions and make the best and most appropriate decision for each organization and each project. About the author This article was written by Lori Holmes, a Managing Consultant with Q/P Management Group, Inc. and was first published in the STC Crosstalk publication February, 2000. © Copyright 2000-2002. Q/P Management Group, Inc. Proprietary and Confidential. All Rights Reserved |
|||||||||||||||||||||
