A Function point counting standard has been created by International Function Point Users Group (IFPUG). This group has standardised both the counting of business functionality with the Function Point Counting Practices Manual, and an evolving industry standard using the Software Non-functional Assessment Process.
Additionally, the cost (in dollars or hours) of a single unit can be estimated from past projects to allow an estimate of the total projects cost from function point counts of user requirements or functionally decomposed scoping documentation.
A good source of estimate information is the International Software Benchmarking Standards Group (ISBSG) database. ISBSG is a not-for-profit organisation that provides a database of project costs based on function point counts and other project parameters.
At the business case and tendering stage of the project it is not important that some functions used to create the estimates are not valid. At this stage of the project, the important issue is that the size of the project and its complexity is accurate to about + or – 20 per cent. This is the contract tolerance for the tendered function points and ensures there is enough flexibility in the contract to deliver a viable system.
Also, the non-functional requirements for the system need to be known at a high level to ensure the correct example estimates are selected from the benchmark database or additional fixed price costs added. Many of the non-functional requirements are covered in the benchmark database. A typical list of non-functional requirements for a project is shown below.
Some of these will be covered in the benchmark database but some will need to be added as extras in the request for tender document and separately priced.
Environment – the development environment and target production environment
Performance – response times for various functions
Code quality – the defect level of code and applicable standards
Security – security strategy and level should be defined this if often an enterprise document which is already available
Privacy – identification of PII and related data and the laws and standards for which compliance will be required
Accessibility – the standards and level of compliance
Availability – the mean recovery times and associated design implications also whether system operates 24x7 or is more 8x5
Reliability – the level of auto replication and redundancy before failure
Supportability – the level of documentation and other knowledge transfer requirements
Records Management – record keeping standards required
Auditable – documentation and audit trails and logs required
Documentation and Training – required to use and operate the system.
Tendering with function points
When organisations need to engage third party system integrators to deliver systems they need to ensure that the processes they use are fair and competitive.
Sign up for CIO Asia eNewsletters.