For an increasing number of companies, the agile development and modification of their software has become the standard approach. Users are happier because they see the desired changes in the softwaremore quickly. Developers are happier because they are in direct contact with users to create software that is actually used.
For the budget owners and controllers it is a different story. How can they convince decision makers to free up budget for agile projects, and how can they ensure that agile developed software really adds value to the organization? Voor een large project, you can make a business case, but how do you do that for biweekly releases, let alone for continuous deployment? And what sort of value of the software do we want to measure? Agile is particularly concerned about user value, by giving stories with the highest user value the highest priority. Decision makers often think in balance sheet value, so notably the cost of realizing the software plays a major role in their decisions. The story points that the scrum teams use are well suited to plan sprints and determine which user value from the backlog is transformed into working software. They are not suitable to determine a price in a commercial contract or to compare the performance of different projects and releases in terms of money, time and quality.
Function points can be useful to meet that end (see the 2012 article by Jolijn Onvlee & Rini van Solingen). With the aid of function points the functionality of the software can be sized objectively. Since software development means that the functionality of the software is modified, function points can be used to measure the productivity of software development. Budgethouders dus have a measure to monitor the volume of their software and modifications thereof.
gebruiker Value
Why is it is not applied everywhere then? We see the following reasons:
- Function points measure the size of functionality. This is not exactly the same as the value of the functionality.
- Function Points are not suitable to plan sprints and therefore don’t fit into the flow of the iteration. Scrum Teams therefore see measuring function points as waste, because it does not contribute to the realisation of software.
- Function Points are determined on the basis of the documentation. In many scrum teams the documentation which is most suited to determine the function point size has become waste when an agile way of working has been adopted.
The first reason is the field of play of the product owner. De producteigenaar ensures that only functionality that is valuable for the organization is developed. If that prioritization works well, an increase of the functionality is also an increase in the value. But how does a product owner determine which functionality has a large value? That’s not as easy as it seems. Take the example of Whatsapp. The functionality of the app is not very large in terms of function points. But its value in terms of the number of users and the frequency of the use of the app is huge. Apparently there are also other aspects that influence value in addition to functionality.
User value is an important concept in agile software development, but what exactly determines the user value, has not been established conclusively. Research has shown that the traditional values on time and within budget hardly affect the perceived user value. The quality of the delivered software is the strongest predictor of user value. The quantity of delivered function points is a good predictor of cost, quality and schedule time, but has only limited influence on the perceived user value.
We think that a solution to point 2 and 3 is to automate the measurement of the volume of delivered software. This makes it a release activity in the flow of an iteration, and the absence or presence of other documentation than the code is no longer an issue. When you automate measurement, based on the delivered code, instead of on a document that may or may not be present, then the measurement of the delivered software is an integral part of an iteration, or a project.
One of the few solutions for the automatic counting of feature points that is used in the practice at this time is a commercial product of CAST. This is a bespoke solution, its operation and its quality can not be tested independently. The very fact that function points are independently audited, is the strength of this methodology. A bespoke solution does not fit well with that aspect.
Therefore, we investigate the possibility to create an open-source solution. There are parsers available in the market for the most common programming languages. Parsers convert the contents of a piece of software code, to a data structure that can be used to analyze the code. Also there are already several parties that published their algorithms to translate data structures to function points. OMG has already published a working standard for the IFPUG standard and Renault has released its algorithms based on the MATLAB documentation for the COSMIC standard. By using open-source software to implement these standards on data structures delivered by the parsers, the software code can be translated to function points in a testable way.
Research shows that many experts see in function points is an important tool to underpin and justify investment decisions and that automation of this is a major step forward. The main obstacles are seen here are:
- The difference between functionality and contents
- Complexity and variation in source code
- The large number of programming languages
We see that function points are an important tool for managing software development, in traditional but also in agile environments. It would be good if there is an open-source solution to measure the function points directly from the delivered code rather than from documentation. Op die manier function points connect better to faster and short cyclical delivery of software.
Deze blogpost is oorspronkelijk gepubliceerd in het Nederlands als “Waarde agile in functiepunten” in AutomatiseringGids en is gebaseerd op een onderzoeksartikel dat is gepubliceerd op de ICSSP-conferentie (zie hieronder). De volledig onderzoekspaper “Een verkennend onderzoek naar het meten van functionele afmetingen op basis van code” is verkrijgbaar bij de artikel sectie van deze website.
Over de Auteurs
Frank Vogelezang is Pricing Officer bij Ordina Management & Uitbesteding. Hij is gespecialiseerd in het bepalen van de kosten en waarde van IT-systemen en contracten.
Hennie Huijgens is Software Analytics Specialist at Goverdson. He specializes in the measurement, analysis and benchmarking of IT projects.
Een blogpost vertegenwoordigt de persoonlijke mening van de auteurs
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.
The International Conference on Software Engineering (ICSE) is the oldest and largest conference on software development, where the latest developments are presented and discussed. This year’s conference will be preceded by a host of specialized workshops and conferences. One of these is the International Conference on Software and System Processes (ICSSP) in which developments are shared on bringing together the rapidly changing business processes and processes to realize the supporting software. As a first step in the development of an open-source solution that measures function points directly from code rather than documentation we have, together with researchers from TU Delft, CWI and SIG, conducted a global survey amongst measurement specialists. In deze enquête 334 specialists from 40 countries took part. These specialists were given a detailed questionnaire on the utility, application, added value and feasibility of automating function point sizing. The results are analyzed and described in a publication that has been accepted after a thorough review process on the ICSSP conference. Op die conferentie the results were presented to and discussed with an international company experts in the field of process automation. Main conclusions from the study:
– Een ruime meerderheid (87%) van de respondenten functie punten genoemd een belangrijk instrument voor besluitvormers om investeringsbeslissingen te ondersteunen of te rechtvaardigen.
– De geautomatiseerde meting van functiepunten wordt gezien door 44% van de respondenten als een grote stap voorwaarts, zowel vanuit het perspectief van experts als besluitvormers.
– In terms of content, there are still some hurdles to take to get working the idea, according to 50% of respondents. Main obstacles to be seen are thet verschil tussen functionaliteit en technische inhoud (26%), complexiteit en variatie in broncode (14%) en het grote aantal programmeertalen(10%).
– Als de beste manier om functionele maatmetingen te automatiseren 25% van de respondenten geeft aan dat de COSMIC-methode de beste optie is.