Harold van Heeringen, Sogeti Nederland
Hans Kuijpers, Software Improvement Group
Rini Scholten, Kadaster
Frans Schoot Uiterkamp, Rendeck automatisering
Dirk Muller, RDW
Jolijn Onvlee, Onvlee Opleidingen en advies
Hans Bernink, JIM Bernink B.V.
Marcel Pereboom, Mediaan
Using function points and quality metrics in contracts
Contracting of software development projects and maintenance continues to be a difficult task for many organizations. They struggle to determine which questions they need to ask in the ´Request for Proposal (RFP)´ phase. These organizations wish to find the questions that would enable them to compare the bidding suppliers in an objective, yet meaningful way and they wish to select the right supplier based on this comparison. In practice, the industry sees many RFPs that seem to achieve this goal at first glance, but which offer a comparison, which is not objective and meaningful at all. As a consequence, in many cases the wrong supplier is selected, which can (and often does) result in a failing project. Repeatedly, suppliers argue with client organizations about the objectivity of the reasons for missed offers and sometimes they even start legal action.
This publication zooms in on RFPs in which function points and quality metrics, such as productivity of the development team and quality of the software code, are used. Nesma presents this guideline to help client organizations ask the right questions during the bid phase and the contracting phase. But it is also meant for the supplier organizations, which it gives directions on which data should be collected and analyzed of completed projects and on which metrics should be calculated, stored and benchmarked. Furthermore, Nesma gives its vision on which metrics to use and how to use them during the contract phase. With this document, Nesma wishes to facilitate the industry in order to make the next move towards professionalism in outsourcing contracts. It is a reference for both client and supplier organizations.
Scope of the guideline
This document describes the way the Nesma feels that function point based metrics and quality metrics should be applied in contracting and in contracts regarding software realization projects and maintenance contracts. The scope therefore includes the following contract types:
• Software development projects, including new development, enhancements and (major) adaptive maintenance (releases);
• Maintenance and Support contracts, including for example user support, problem investigation and corrective, perfective and preventative maintenance;
• Framework agreements comprising the activities mentioned above.
The scope includes all kind of technologies and methods of implementation: Java, .Net, Oracle, and Prince2, agile, waterfall, package implementation, websites, mobile apps, data warehouses, etcetera.
The scope of this document is limited to function point based metrics (Nesma, IFPUG, COSMIC) and software product quality based metrics. These methods comply with the ISO standard for Functional Size Measurement Methods and for software quality (i.e. ISO/IEC 14143 and ISO/IEC 25010) and therefore these methods are objective, repeatable, verifiable and defensible. These are essential criteria in contracting, because it reduces/prevents discussions regarding the size of the project or the application delivered and the product quality. This means that size measures like source lines of code (slocs), IBRA points, SNAP points, Configuration points, Story points, Use Case points, nr. of pages of documentation, nr. of modules, number of RICEF objects, etcetera, are outside the scope of this document. Although these size measures may help organizations in some ways to estimate projects, or for other purposes, Nesma does not recommend to use these measures in contracts (or contracting) because of the fact that these metrics are either subjective (depending on the person doing the measurement), not repeatable, not verifiable and ultimately not defensible. As a result of this, benchmarking is not possible, therefore cross-company comparisons are not possible, thus the question, which is the best proposal cannot be answered (even worse: whether a proposal is good anyway cannot be ascertained).
The proposed workshop is divided into 4 parts:
1. Present the contents of the document to create a common reference of the participants;
2. Discuss the contents to find out if things are wrong or missing;
3. Discuss the ways we have to proceed to have the industry adopt the guideline and to promote it into an international standard;
4. Formulate ‘to do’ steps and assign action items for the participants.
If you want to participate in this workshop, you have to register to the conference for at least the day of the workshop. If you already registered to the conference, you can attend to this workshop free of charge.
Date & time
Tuesday, October 7
10.00 – 12.30 Statendam room (B-deck)
Note! This workshop coincides with another workshop: Measuring Performance Impact Factors for ICT Projects.