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? Per un 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. Proprietari di bilancio quindi have a measure to monitor the volume of their software and modifications thereof.
Valore utente
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. Il proprietario del prodotto 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. In quel modo function points connect better to faster and short cyclical delivery of software.
Questo post sul blog è stato originariamente pubblicato in olandese come “Valore agile nei punti funzione” nel Guida all'automazione e si basa su un documento di ricerca pubblicato alla conferenza ICSSP (vedi sotto). Il documento di ricerca completo “Uno studio esplorativo sulla misurazione delle dimensioni funzionali basato sul codice” è disponibile dal sezione articolo di questo sito web.
Riguardo agli Autori
Frank Vogelezang è Pricing Officer presso Ordina Management & Esternalizzazione. È specializzato nella determinazione del costo e del valore di sistemi informatici e contratti.
Hennie Huijgens È Software Analytics Specialist at Goverdson. He specializes in the measurement, analysis and benchmarking of IT projects.
Un post sul blog rappresenta l'opinione personale degli autori
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.
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 questo sondaggio 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. In quella conferenza the results were presented to and discussed with an international company experts in the field of process automation. Main conclusions from the study:
– Una grande maggioranza (87%) dei punti funzione degli intervistati ha definito uno strumento importante per i responsabili delle decisioni per supportare o giustificare le decisioni di investimento.
– La misurazione automatica dei punti funzione è vista da 44% degli intervistati come un importante passo avanti, sia dal punto di vista degli esperti che dei decisori.
– 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 tdifferenza tra funzionalità e contenuto tecnico (26%), complessità e variazione nel codice sorgente (14%) e il gran numero di linguaggi di programmazione(10%).
– Come il modo migliore per automatizzare la misurazione delle dimensioni funzionali 25% degli intervistati indica il metodo COSMIC come la migliore opzione.