## Fixed price per unit delivered contracts

Iliis is often associated w ith function point (FP) counting. The size of the system to be delivered is calculated or estimated at the outset of the project. The size of the system to be delivered might be estimated in lines of code, but I Ps can be more easily and reliably derived from requirements documents. A price per unit is also quoted, The final price is then the unit price multiplied by the number of units. Table 10.1 shows a typical schedule of prices.

 Function point count Function design cost per FP Implementation cost per FP Total cost per FP Up to 2,000 \$242 \$725 \$967 2.001-2,500 \$255 \$764 \$1,019 2.501-3.000 \$265 \$793 \$1,058 3.001-3.500 \$274 \$820 \$1,094 3.501-4 .(XX) \$284 \$850 \$1,134

This Table comes from D. Garmus and D. Herron, Measuring The Software Process. Prentice Hall. 1996.

The company who produced this table. RDI Technologies of the USA. in fact charge a higher fee per FP for larger systems. For example, a system to be implemented contains 2,600 I Ps. The overall charge would be 2.000 x \$967. plus 500 x \$ 1. 1019. plus 100 x \$ 1,058.

One problem that has already been noted is that the scope of the system to be delivered can grow during development. The software supplier might first carry out the system design. From this design, an I P count could be derived. A charge could then be made for design work based on the figures in the 'Function design cost per FP' column. This, if the designed system was counted at I .(XX) FPs. would be I (XX) x \$242 = \$242.0(X). If the design were implemented, and the actual software constructed and delivered, then the additional I(XX) x \$725 = \$725.(XX) would be charged. If the scope of the system grows because the users find new requirements, these new requirements would be charged at the combined rate for design and implementation. For example, if new requirements amounting to l(X) extra I Ps were found, then the charge for this extra work would be \$967 x l(X) = \$96,700.

A system to be designed and implemented is counted as comprising 3.2(X) FPs. Exercise 10.2 What would be the total charge according to the schedule in Table 10.I?

The advantages of this approach are as follows.

• Customer understanding The customer can see how the price is calculated and how it will vary with changed requirements.

• Comparability Pricing schedules can be compared.

• Emerging functionality The supplier does not bear the risk of increasing functionality.

The impact of late changes will be further discussed in Chapter 12 on Software Quality.

The table comes from the draft Acquisition of customized software policy document, published by the Department of State Development, Victoria. 1996.

• Supplier efficiency The supplier still has an incentive to deliver the required functionality in a cost-effective manner (unlike with time and materials contracts).

• Life cycle range The requirements do not have to be definitively specified at the outset. Thus the development contract can cover both the analysis and design stages of the project.

### The disadvantages of this approach are as follows.

• Difficulties with software size measurement Lines of code can easily be inflated by adopting a verbose coding style. With FPs. there can be disagreements about what the I P count should really be: in some cases, I P counting rules might be seen as unfairly favouring either the supplier or customer. Users, in particular, will almost certainly not be familiar with the concept of FPs and special training might be needed for them. The solution to these problems might be to employ an independent I P counter.

• Changing requirements Some requested changes might affect existing transactions drastically but not add to the overall FP count. A decision has to be taken about how to deal with these changes. A change made late in the development cycle will almost certainly require more effort to implement than one made earlier.

To reduce the last difficulty, one suggestion from Australia has been to vary the charge depending on the point at which they have been requested - see Table 10.2.

 P re-acceptance Post-acceptance testing handover testing handover Additional I Ps I OOtf I00<* Changed IPs 130% 150«* Deleted FPs 25% 50%

Exercise 10.3 A contract stipulates that a computer application is to be designed, constructed and delivered at a cost of \$600 per I'P. After acceptance testing, the customer asks for changes to some of the functions in the system amounting to 500 I'Ps and some new functions which amount to 200 additional I'Ps. Using Table 10.2. calculate the additional charge.

In addition to the three payment methods above, there are other options and permutations of options. For instance, the implementation of an agreed specification could be at a fixed price, w ith provision for any additions or changes to the requirements to be charged for on a per FP basis. Another example could be where the contractor has to buy in large amounts of equipment, the price of which might fluctuate through no fault of the contractor. In this case it is possible to negotiate a contract where the final price contains a fixed portion for labour plus an amount that depends on the actual cost of a particular component used.

It is easy to see why passing on fluctuations in equipment costs can be Exercise 10.4 advantageous to the contractor. However, is there any advantage to the customer in such an arrangement?

An underlying problem with software can once again be seen when the questions of contractual obligations and payment are considered - namely its relative invisibility and its flexibility. These mean that system size and consequently development effort tends to be very difficult to judge. If contractors are realistically to quote firm prices for work, then the tasks they arc asked to undertake must be carefully constrained. For example, it would be unrealistic for a contractor to be asked to quote a single price for all the stages of a development project: how can they estimate the construction effort needed when the requirements are not yet established? For this reason it w ill often be necessary to negotiate a series of contracts, each covering a different part of the system development life cycle.

Another way of categorizing contracts, at least initially, is according to the approach that is used in contractor selection:

The concept ol IS adaptations' in Euromethod (see Appendix C) supports the idea of a series of separate contracts to implement a single system.

This categorization is based on European Union regulations.