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. D.evelopers 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? Für ein 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. Budgetbesitzer also have a measure to monitor the volume of their software and modifications thereof.

Benutzerwert

Why is it is not applied everywhere then? We see the following reasons:

  1. Function points measure the size of functionality. This is not exactly the same as the value of the functionality.
  2. 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.
  3. 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. Der Produktbesitzer 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. Auf diese Art function points connect better to faster and short cyclical delivery of software.

Dieser Blogbeitrag wurde ursprünglich auf Niederländisch veröffentlicht als “Wert agil in Funktionspunkten” im Automatisierungsleitfaden und basiert auf einem Forschungspapier, das auf der ICSSP-Konferenz veröffentlicht wurde (siehe unten). Das vollständige Forschungsarbeit “Eine explorative Studie zur funktionalen Größenmessung basierend auf Code” ist erhältlich bei der Artikelbereich dieser Website.

Über die Autoren

Frank Vogelezang ist Pricing Officer bei Ordina Management & Auslagerung. Sein Spezialgebiet ist die Ermittlung von Kosten und Wert von IT-Systemen und Verträgen.
Hennie Huijgens ist Software Analytics Specialist at Goverdson. He specializes in the measurement, analysis and benchmarking of IT projects.

Ein Blogbeitrag repräsentiert die persönliche Meinung der Autoren
und muss nicht unbedingt mit den offiziellen Nesma-Richtlinien übereinstimmen.
Research
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 dieser Umfrage 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. Auf dieser Konferenz the results were presented to and discussed with an international company experts in the field of process automation.

Main conclusions from the study:
– Eine große Mehrheit (87%) der Befragten bezeichnen Funktionspunkte als wichtiges Instrument für Entscheidungsträger, um Investitionsentscheidungen zu unterstützen oder zu rechtfertigen.
– Die automatisierte Messung von Funktionspunkten wird durch gesehen 44% der Befragten als einen großen Fortschritt, sowohl aus der Sicht von Experten als auch von Entscheidungsträgern.
– 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 tDer Unterschied zwischen Funktionalität und technischem Inhalt (26%), Komplexität und Variation im Quellcode (14%) und die große Anzahl an Programmiersprachen(10%).
– Als beste Möglichkeit, die funktionale Größenmessung zu automatisieren 25% der Befragten geben an, dass die COSMIC-Methode die beste Option sei.

Teile diesen Beitrag auf:

Hinterlasse eine Antwort