The software architecture and the gamification engine are based on a model composed of three main elements: behaviors, achievements, and game rules. The gamification engine will receive behaviors carried out by the users in their respective tools, and will evaluate these according to the game rules defined by a designer (administrator), to assign the corresponding achievements to those behaviors if the game rules consider them successful.

\ This model is a central component of our architecture, since it allows the designers of the gamified environments to define behaviors, achievements, and evaluation rules using concepts that are independent of any particular SE work environment we would consider. Although the details of the gamification engine we have implemented are presented in Section 4, some screenshots are included in this section, as they may clarify how the designer can use the concepts of the gamification model in a real case.

\ In this section we will use a simple guiding example. For the sake of simplicity, let us assume that a generic software development organization wants to gamify its SE environment, focusing on the areas of project management, requirements, and testing. Employee actions receiving awards would include those, such as finishing development tasks, registering requirements in the system, commenting on existing requirements, creating test cases, writing unit tests, or closing the project.

\ The rest of this section presents the details of the gamification model.

\ 3.2.1 Behaviours

\ Different types of behavior can occur in a software development environment. Instead of trying to identify and model all those particular and specific behaviors, however, we have extracted the features they have in common, and have aggregated them in three types of behavior (summarized in the diagram shown in Fig. 2):

\ ● Simple behaviors: This type of behavior is designed for those behaviors where we are only interested in knowing that they have actually happened, as well as who has carried out the behavior, and when there is no need for any other data about the action.

\ For example, we could define simple behaviors for requirement management actions as being those of registering a new requirement into the system, commenting on an existing requirement to clarify its description, changing its state, or labeling the requirement as completed. These are simple behaviors if we assume that we would not need other data from those actions, apart from the fact that they have happened and who carried them out.

\ ● Task behaviors: They are those behaviors in which we are also interested in parameters related to the development and completion of typical tasks in an SE environment, such as the effort, cost, quality, or the completion date. More specifically, the task behaviors currently include the following attributes:

\ – Planned completion date: completion date for the task in the project plan.

\ Fig. 2 Behavior model.

\ – Real completion date: date on which the task was actually completed.

\ – Estimated effort: estimated effort, in hours, to complete the task.

\ – Real effort: real number of hours needed to complete the task.

\ – Estimated work units: work units refer to tangible results of the task, such as lines of code, classes, or requirements, for example. This attribute corresponds to the estimated number of work units for the task, if this has been estimated.

\ – Real work units: real number of work units completed during the task. – Unit type: the name of the work units that are being considered.

\ – Grade: this attribute, which takes values between 0 and 100, allows us to take into account the quality of the results obtained during the task.

\ As we will see later, these attributes of a task behavior can be used in the definition of the gamification rules. For example, we could reward the finishing of a task only if it has been completed by the planned completion date, with the estimated effort, and with a given quality level. None of these attributes is mandatory, so we can use just those ones that are of interest in each particular case.

\ Task behaviors are designed mainly for those tasks that would appear in a project plan, or in a product backlog, for example. The most obvious example for task behaviors is development tasks. That is, when a developer marks a task as completed, the system would notify that action to the gamification engine, indicating the estimated and real dates and effort. However, task behaviors may also apply to other actions.

\ ● Interaction behaviors: They represent actions in which two people have collaborated in some way. This type of behaviors is concerned with rewarding the collaboration in the workplace. For example, we could use it to record that two people have interacted because one of them has created a task and has assigned it to the other, or because one of them has registered a requirement in the system, and the other person has commented on that requirement.

\ As we will see in the next section, these classes of behaviors will also allow us to derive an interaction graph from which important information can be extracted, such as the interaction network of each user, relevant users that act as hubs or links, and the existence of communities that can be automatically identified from this information.

\ Figure 2 shows a class diagram summarizing the behavior types. As we can see in the diagram, the model also considers maintaining who has carried out the task, the tool from which the behavior was received, the project in which it has been carried out, and the date and hour on which the action has taken place. These attributes allow the gamification engine to keep a persistent log of all the actions carried out by team members in each project, which is a valuable information.

\ Notice also that all behavior types include two more attributes: artifactId and artifactName. Most tasks in an SE environment give as a result a project artifact, such as a document, or a task in the project plan, for example. These attributes allow us to include in each behavior the identifier and name of the resulting artifact. For example, in the behavior “Task completed”, we could indicate the identifier and name of the task. As we will see in the presentation of the gamification rules, the attributes can also be used in the definition of the rules, as well as in the messages that will be shown to the user when receiving a reward. These three types of behavior cover most actions that could take place in an SE development environment. Although the model currently considers these types of behaviors, it could be easily extended to support new ones, if we detected a kind of action that does not fit in to these three types.

\ When configuring the gamified environment, the administrator will start by defining the behaviors that are subject to being evaluated and rewarded. For each of them, the administrator will have to indicate for each behavior only its identifier (a string), its type (simple, task, or interaction behavior), its name, its description, and its category. The identifier is a key point, since it will be used by the gamified tools when communicating behaviors to indicate what action they are communicating.

\ Example: Figure 3 shows a screenshot of the behavior definition screen in the gamification engine we have implemented. In this example, we have defined just four behaviors: create a task (GSE CREATE TASK), complete a task (GSE TASK COMPLETED), detect an error (GSE ERROR DETECTED), and comment on a project requirement (GSE COMMENT REQ).

\ 3.2.2 Achievements

\ When the rules of the game determine that a user has successfully completed a behavior, the system will reward that user with an achievement. The model has been designed to provide a flexible range of achievements. Three classes of achievements are currently supported:

\ ● Points (also called experience points): They are the basic reward mechanism, with a role analogous to what this type of achievement has in classic games. The number of points is a measure of the amount of successful behaviors completed by each user. In addition, the experience points also determine the level of the player

\ The environment designer could even define more than one type of points (in order to distinguish between clearly different groups of behaviors). However, one of them must be used as the basis for computing the level of each player.

\ ● Badges: They are a classical achievement type in gamification. Badges are usually granted when a significant milestone in the gamified environment is reached.

\ The designer of the gamified environment can define as many badges as needed. For example, we could grant a badge on a developer’s first 100K line of code, or

\ Fig. 3 Screenshot of the behavior definition screen.

\ establish badges for the best analyst, best developer, and best tester of the month. Other badges could be created, depending on the design of the gamified environment.

\ ● Resources: They meant to represent real-world rewards for the players. For example, resources could be used to reward the players with physical gifts, or time packages they can devote to personal projects or training, for example.

\ This set of achievements will allow us to apply the most typical game mechanics used in gamification. Experience points, badges, and resources are all direct rewards, but we can also use them to implement levels, leaderboards, social status, and even quests.

\ The diagram shown in Fig. 4 summarizes the achievement classes currently considered in our gamification model. The model allows the environment designer to define as many achievement types as needed, each of them belonging to one of the achievement classes we have just established. That is, although the gamification model currently provides the three types of achievement we have presented, it allows the designer of the gamified environment to define new types of achievements, like currencies.

\ Levels: although levels are not a particular class of achievement, they are directly derived from the experience points of the players through an exponential function that can be customized by the environment administrator,

\ where l is the level, and f(l) returns the number of experience points necessary to achieve level l. For example, with values a = 1, b =1.4, and c = 2, the number of points necessary to achieve the first nine levels are shown in Table1.

\ In this way, the difficulty of getting to the next level is completely customizable. It can be made linear, or

\ Table 1 Exponential function for levels.

\ exponential, as in our example, making it increasingly difficult to get to the next level.

\ 3.2.3 Gamification rules

\ The link between the user’s behaviors and the achievements is established by the gamification rules. The model provides a gamification rule system that allows the environment designer to define a complete set of rules in a flexible way. This is the most important component of the model, since it removes the logic of gamification from the gamified tools, and it allows centralizing it in a gamification engine.

\ A game rule maps behaviors to achievements. Each rule has a source type of behavior and many target types of achievement. Every time a behavior from the source type is received at the engine, all game rules with that source type of behavior are activated and evaluated by the gamification engine. Each rule is associated to its types of achievement through an achievement modifier, which represents the condition that uses the behavior’s attributes to define the criteria determining whether the achievement is granted or not.

\ Example: In the example we are using for presentation of the gamification model, the organization could be interested in defining a rule for the behavior “Task completed”, which is a task behavior. On receiving such a behavior, we would like to reward the user in different ways depending on whether or not the task has been completed within the parameters of estimated effort. The definition of such a rule is shown in Table 2.

\ As we can see in the example shown in Table 2, the rule “Task completion” is activated when a “Task

\ Fig. 4 Achievement model.

\ Table 2 Example of a gamification rule. The rule name is “Task completion” and the source type of behavior is “Task completed”.

\ completed” behavior is received, and three possible achievements are evaluated. In the first one, if the user has completed the task with an effort less than the estimated one, he or she is rewarded with as many experience points as the effort estimation of the task. In the second achievement, if the real effort is greater than or equal to that estimated, the user is rewarded with a number of points equal to what was estimated, minus a penalization for the number of hours he/she has exceeded the estimation. Finally, in the third achievement, if the user has completed the task in less than half the estimated effort, he is rewarded with an extra badge of “Star performer”. It is important to notice that all the conditions and modifiers used in this example can be specified in the gamification engine using the behaviors attributes.

\ The gamification engine could now receive “Task completed” behaviors from any tool, such as Jira, or Redmine, for example, which would communicate those behaviors with the real attributes of how a user has completed a task in that tool. Let us look now at what would happen in the following three cases:

\ ● Case 1: John completes a task with 20 estimated hours in just 18. In this case, he is rewarded with the Achievement 1; that is, 20 experience points.

\ ● Case 2: John completes that task in 22 hours. In this case he receives the Achievement 2, that is, 18 experience points (20 – (22 – 20)).

\ ● Case 3: John completes the same task in just 8 hours. In this case, John will receive two Achievements, the first and the third. For the first one he receives 20 experience points, and for the third one he receives a “Star performer” badge, since he has completed the task in less than half the estimated time.

\ Figure 5 shows a screenshot of the rule definition screen in our gamification engine implementation, with the same example we have just presented. As we can see in the screenshot, this rule, “Task completion”, will be activated when a “Task completed” behavior is received, with three possible achievements for the

\ Fig. 5 Screenshot of the rule definition screen.

\ \ user who has completed the task. In Fig. 5, we can also see that, in addition to the definition of the conditions for each achievement, the administrator of the gamified environment can introduce messages that will be shown to the user who completed the task, when obtaining each of the achievements. Notice that the messages like “Congrats! You’ve completed a task! (Task #id, #name)” can also use the attributes of the behavior that has been evaluated. In this example, #id and #name correspond to the attributes artifact and artifactName of the task behavior. When evaluating a particular behavior, the message template would be transformed into a real message, such as “Congrats! You’ve completed a task! (Task 45, User authentication)”. These messages can be shown on the player’s site or in the tools that have communicated the behavior to the gamification engine. The example shown in Fig. 5 demonstrates that the designer also has the option of awarding a given achievement to a type of behavior only the first time that a behavior of that type is evaluated. This would allow us to define a rule that, for example, awards a “First task completed!” badge to a player only the first time he/she carries out a task in the system. It is worth highlighting that the conditions of the rules are established through the graphical interface of the engine, that is, without modifying its source code.

\ Although this example is simple, it shows the flexibility of the rule system of the gamification model. As we have just seen, the designer of the gamified environment can establish any condition on the received behaviors, and can also use its attributes when awarding achievements. This provides us with a high degree of flexibility in rule definition. We should also point out that the tool in which the user carries out the behavior knows nothing about how the action is gamified; it simply has to communicate it to the engine. This allows us to integrate and therefore to gamify as many heterogeneous SE tools as required. The example we have just shown considers the simplest type of rule supported by the engine. Actually, we distinguish between three types of rules:

\ ● Simple rules: They are gamification rules that evaluate just the condition of each achievement on the received behaviors, determining if an achievement must be awarded to the player.

\ ● Repetitive rules: These rules award the achievements only when the conditions are evaluated successfully a given number of times; in other words, a number of behaviors that fulfill the required condition were received. Besides, it can be specified that the behaviors must be received within a closed period of time, defined by start and end dates.

\ ● Interval repetitive rules: These are also repetitive rules, but instead of defining start and end date, a generic interval of time (i.e., week, month) is selected, so a number of behaviors that fulfill the condition must be received within this period.

\ These types of rules allow us to reward behaviors not just when they happen, but when they happen repeatedly in time. For example, we could reward a developer for completing one hundred tasks, or for completing those one hundred tasks in a month.

\ Figure 6 shows a class diagram summarizing the design of the gamification rules in the model. Since a complete gamified environment can have a large set of rules; these can be grouped into games. In this context, therefore, a game is defined as a set of related rules. The designer can even configure that only some particular games are played in a project.

\ Notice that although the examples we have used in the description of the rules involved mainly task completion time, the types of rules we have considered allow us to reward behaviors more than just finishing on time or in cost. In addition, that the TaskBehavior type of behavior includes a grade attribute, intended to reflect the quality of the work.

\ \

:::info This paper is available on arxiv under CC BY 4.0 DEED license.

:::

Feed: Hacker Noon - Medium

View: Original article

Tags: application management option personal social testing