and the distribution of digital products.
How a Gamification Engine Integrates Multiple Software Tools
:::info Authors:
(1) Oscar Pedreira, Universidade da Coruna, Centro de Investigacion CITIC, Laboratorio de Bases de Datos, Facultade de Informatica;
(2) Felix García, Universidad de Castilla-La Mancha, Grupo Alarcos, Escuela Superior de Informatica, Paseo de la Universidad;
(3) Mario Piattini, Universidad de Castilla-La Mancha, Grupo Alarcos, Escuela Superior de Informatica, Paseo de la Universidad;
(4) Alejandro Cortinas, Universidade da Coruna, Centro de Investigacion CITIC, Laboratorio de Bases de Datos, Facultade de Informatica;
(5) Ana Cerdeira-Pena, Universidade da Coruna, Centro de Investigacion CITIC, Laboratorio de Bases de Datos, Facultade de Informatica.
:::
Table of Links3 A Software Architecture for the Gamification of SE Environments and 3.1 Software architecture
4 Gamification Engine for SE Environments
4.1 System architecture and design
4.4 Support of game mechanics and elements and 4.5 Player’s site
5.3 Subjects and analysis units and 5.4 Field procedure and data collection
5.6 Analysis of results from the case study
5.7 Validity threats and limitations of the case study
Conclusion and Future Work, Acknowledgment, and References
5.6 Analysis of results from the case studyIn this section, we analyze the results and conclusions
\
\ we can extract from the case study, following the secondary research questions of the case study.
\ 5.6.1 Tool integration
\ Although the case study focused on the case of one single company, the tool suite we considered presented a representative example of what we can find in most software development organizations. This suite mixes custom developments with COTS tools, and it presented a case as particular as the gamification of JUnit.
\ The conclusion we extract from the execution of the case study is that the REST API provided by the engine is feasible for integrating the variety of tools that can be used in a real company. As regards the engine, its REST API does not force them to use any particular technology. With respect to the SE tools, most of them also provide some API that allows us to access their information. Even if they did not provide such an API, we could develop a mediator that would obtain their information by directly accessing their databases.
\ So far, we have focused on the integration of gamified tools with the gamification engine for the purpose of data gathering in the engine, mainly because SWComp made the decision of showing all gamification data to employee in a central player’s site. However, gamification data could also flow in the opposite direction, that is, the tools could get data from the engine (such as results, rewards, etc.) to show them directly to the players. For example, this would have been interesting in the project management tool, or in the development IDE.
\ 5.6.2 Support of gamification
\ Regarding the second research question, from this case study we conclude that the gamification abstraction on which the engine is based would support the gamification mechanisms of most companies. Actually, in the case of SC, the behaviors and rules defined did not even require all the features provided by the engine.
\ 5.6.3 Integration effort
\ The integration of the SE tools into the gamified environment proceeded following the design and development of the engine we have just presented. The integration took 141.5 work hours. Figure 11 shows the distribution of this effort in the three areas considered in the case study. Project management was the first one to be developed, and therefore needed a greater effort because it includes the integration component of SC-Manage. Once that component was developed, the effort for integrating the other areas was significantly
\
\ smaller. The effort required by the testing area (which includes JUnit, Redmine, and TestLink) is greater than that required by the requirements management area, because of the integration of SC-Manage with the testing tools.
\ From these results, and although we cannot estimate the effort of gamifying those tools separately, we can conclude that the effort required to integrate the ecosystemof SE toolsinto the gamified environment was low. We could also point out that, once these tools have been integrated with the gamification engine, it would be easy to add new tools to the gamified environment, since the integration component of SC-Manage is already developed and complete.
5.7 Validity threats and limitations of the case studyIn order to address potential threats to the validity of the case study, we considered the following:
\ ● Construct validity: Before starting the execution of the business case, training sessions were held with employees of SC in charge of the design and development of the gamified environment, to avoid misunderstandings about the goals or scope of the project, or about the functioning of the gamification engine.
\ ● Internal validity: To avoid other factors affecting the results of the case study, the training sessions included general knowledge about gamification; the authors of this work participated in the execution of the case study, providing support both in gamification design and in the use and configuration of the gamification engine.
\ ● External validity: Although the results might be different in other companies, we have chosen an organization with a typical and varied tool suite that could prove how the gamification engine can support most tools present in software development companies.
\ ● Reliability: The use of the gamification engine depends on its technical design and features, so its application in other settings should not be affected by the particular researcher applying it.
\
:::info This paper is available on arxiv under CC BY 4.0 DEED license.
:::
\