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. reevelopers 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? Para 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. Por tanto, los propietarios del presupuesto have a measure to monitor the volume of their software and modifications thereof.
Valor de usuario
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. El propietario del producto 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. De ese modo function points connect better to faster and short cyclical delivery of software.
Esta entrada de blog se publicó originalmente en holandés como “Valor ágil en puntos funcionales” en Guía de automatización y se basa en un artículo de investigación publicado en la conferencia ICSSP (vea abajo). los trabajo de investigación completo “Un estudio exploratorio sobre la medición del tamaño funcional basado en el código” está disponible en el sección de artículos de este sitio web.
Sobre los autores
Frank Vogelezang es Oficial de Precios en Ordina Management & La externalización. Está especializado en la determinación del costo y valor de los sistemas y contratos de TI..
Hennie Huijgens es Software Analytics Specialist at Goverdson. He specializes in the measurement, analysis and benchmarking of IT projects.
Una publicación de blog representa la opinión personal de los autores.
y puede no coincidir necesariamente con las políticas oficiales de 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. En esta encuesta 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. En esa conferencia the results were presented to and discussed with an international company experts in the field of process automation. Main conclusions from the study:
– Una gran mayoría (87%) de los encuestados puntos de función llamados una herramienta importante para que los tomadores de decisiones apoyen o justifiquen las decisiones de inversión.
– La medición automatizada de puntos de función se ve por 44% de los encuestados como un gran paso adelante, tanto desde la perspectiva de los expertos como de los tomadores de decisiones.
– 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 tLa diferencia entre funcionalidad y contenido técnico. (26%), complejidad y variación en el código fuente (14%) y la gran cantidad de lenguajes de programación(10%).
– Como la mejor forma de automatizar la medición de tamaño funcional 25% de los encuestados indican que el método COSMIC es la mejor opción.