The value of $/FP will vary in accordance with the work required for the delivery of soft-ware functionality, in accordance with the TECHNICAL standard and quality required by customers, as well as the amount of deliverables (artifacts, documents, models, etc) required by the customer. In summary, everything that affects significantly the cost but has no direct relation to the size measured by the Function Point Analysis (FPA), is computed on the function point price.

Example 1: when you hire a company just for coding and testing a system, it is expec-ted that the function point price would be lower than if you hire the same firm to con-duct the entire lifecycle of software development, from requirements gathering through development.

Example 2: the function point price only for software delivery is certainly lesser than the function point price where, besides the software, several papers MUST be delive-red (subproducts) as : UML models, user’s manual, online helpdesk, prototypes, test plans and cases, etc.

Example 3: Nowadays the range of available technologies for developing systems is huge, and each one can directly influence in the productivity (either positively or nega-tively) of the work to be done. Thus it is quite common in the market to have differentia-tion of $/FP in regards to the technological platform (mainframe, web, client-server, etc) and/or programming language (COBOL, C, Java,. Net, etc).

Example 4: Function Point Analysis, according to the IFPUG standard, measures the maintenance ignoring the size of the maintenance that the function will go through. Usually, the effort to maintain a function tends to be lower than to develop it. Thus, there may be a function point price differentiation in improvement projects for new, modified and deleted features.

In summary, there is not one price for a function point and also there is no public and updated price list available, where the function point price could be seen. Also because this information is considered proprietary or strategic for most organizations. But it is possible to obtain price information from government contracts through a rese-arch on the biddings that occurred in the past, through the official brazilian gazette or directly with the government organanization.

Another possibility to get this price list is using organizations that maintain the histori-cal data of software projects (e.g. ISBSG — www.isbsg.org) and provide a delivery rate indi-cators conversion (H/PF) to price ($/FP). But even if we could get a list of the $/FP value, the variation in numbers is so significant that it is easy to find a range of values whose variation between minimum and maximum can be up to 10 times, for example $ 100/FP to $ 1.000/FP.

For a more realistic price information (or cost) of the FP, it is better to derive this from projects that have already been undertaken. For projects already completed, informa-tion that is certainly available is how much was paid or charged for each project and what activities were included. If the projects functional size (FP) is not available, it could be attained through a measurement or an estimate, just by REVIEWING the require-ments. Having the price of the project and its size in function points, the price per func-tion point ($/FP) can be attained. However, it is LIKELY that your organization undertakes projects of different types. In this case, an analysis of the $/FP should be done for each category of projects, because a single price point is hardly representative for projects of different types.

The value of $/FP will vary in accordance with the work required for the delivery of soft-ware functionality, in accordance with the technical standard and quality required by customers, as well as the amount of deliverables (artifacts, documents, models, etc) required by the customer. In summary, everything that affects significantly the cost but has no direct relation to the size measured by the Function Point Analysis (FPA), is computed on the function point price.

Example 1: when you hire a company just for coding and testing a system, it is expec-ted that the function point price would be lower than if you hire the same firm to con-duct the entire lifecycle of software development, from requirements gathering through development.

Example 2: the function point price only for software delivery is certainly lesser than the function point price where, besides the software, several papers must be delive-red (subproducts) as : UML models, user’s manual, online helpdesk, prototypes, test plans and cases, etc.

Example 3: Nowadays the range of available technologies for developing systems is huge, and each one can directly influence in the productivity (either positively or nega-tively) of the work to be done. Thus it is quite common in the market to have differentia-tion of $/FP in regards to the technological platform (mainframe, web, client-server, etc) and/or programming language (COBOL, C, Java,. Net, etc).

Example 4: Function Point Analysis, according to the IFPUG standard, measures the maintenance ignoring the size of the maintenance that the function will go through. Usually, the effort to maintain a function tends to be lower than to develop it. Thus, there may be a function point price differentiation in improvement projects for new, modified and deleted features.

In summary, there is not one price for a function point and also there is no public and updated price list available, where the function point price could be seen. Also because this information is considered proprietary or strategic for most organizations. But it is possible to obtain price information from government contracts through a rese-arch on the biddings that occurred in the past, through the official brazilian gazette or directly with the government organanization.

Another possibility to get this price list is using organizations that maintain the histori-cal data of software projects (e.g. ISBSG — www.isbsg.org) and provide a delivery rate indi-cators conversion (H/PF) to price ($/FP). But even if we could get a list of the $/FP value, the variation in numbers is so significant that it is easy to find a range of values whose variation between minimum and maximum can be up to 10 times, for example $ 100/FP to $ 1.000/FP.

For a more realistic price information (or cost) of the FP, it is better to derive this from projects that have already been undertaken. For projects already completed, informa-tion that is certainly available is how much was paid or charged for each project and what activities were included. If the projects functional size (FP) is not available, it could be attained through a measurement or an estimate, just by reviewing the require-ments. Having the price of the project and its size in function points, the price per func-tion point ($/FP) can be attained. However, it is likely that your organization undertakes projects of different types. In this case, an analysis of the $/FP should be done for each category of projects, because a single price point is hardly representative for projects of different types.