Jil Klünder
email: jil.kluender@inf.uni-hannover.de

Fabian Kortum
email: fabian.kortum@inf.uni-hannover.de

Thorsten Ziehm
email: thorsten.ziehm@arvato.com

Kurt Schneider
email: kurt.schneider@inf.uni-hannover.de

Helping Teams to Help Themselves: An Industrial Case Study on Interdependencies During Sprints

Keywords: Process improvement, simulation, System Dynamics, agile software development teams, social aspects

Software process improvement is a very important topic. Almost all companies and organizations face the necessity for improvement sooner or later. Sometimes, there is obvious potential for improvement (e.g., if the number of developers does not fit the project size). Nonetheless, fixing all obvious issues does not necessarily lead to a "perfect" project. There are a lot of interdependencies between project parameters that are difficult to detect -sometimes due to the influences of social aspects which can be hardly grasped. We want to support the process of improving daily work by simulating and visualizing how project parameters evolve over time. Our approach is based on building a System Dynamics model that takes into account key performance indicators as well as assumptions about social aspects. In the present case, we chose parameters of capacity, customer satisfaction, and mood. The model uncovers interdependencies between the available parameters. Furthermore, it is able to simulate consequences of different preconditions and incidents during a sprint such as change requests. In this contribution, we present our approach and apply it in a case study with three agile teams in industry. We build a System Dynamics model and use it for sprint simulations. Our analysis determined, e.g., the teams' productivity during the sprint and their workload each day. The simulation increased the teams' awareness of the negative influences due to interventions during the sprint.

Introduction

Companies strive for a good rate of successful projects. To reach this aim, they often face the necessity for software process improvement. There are various existing approaches to improve the development process [START_REF] Kuhrmann | Software process improvement: A systematic mapping study on the state of the art[END_REF]. However, it does not necessarily suffice to apply the existing approaches. Implementing an agile environment is a commonly used possibility to overcome many problems. Hence, it is a common way to improve the process [START_REF] Kuhrmann | Software process improvement: A systematic mapping study on the state of the art[END_REF]. However, becoming agile is not always the key [START_REF] Klünder | Fake news: Simply agile[END_REF]. The same problem may occur when implementing other approaches to improve the development process. We expect that team members lack an understanding for the interdependencies within the entire software development process [START_REF] Kortum | Don't underestimate the human factors! exploring team communication effects[END_REF]. This lack can reduce the success when implementing existing approaches.

We assume that a simulation model can increase this understanding by simulating and visualizing the dependencies [START_REF] Kortum | Don't underestimate the human factors! exploring team communication effects[END_REF]. In this contribution, we present an objective, data-based approach for visualizing and discovering project dynamics and tendencies which may be too subtle to be found by humans or which are too obvious to recognize the major consequences. To facilitate the application of our technique, we base our approach on already existing or easily collectible data for example from tools like JIRA. Based on this data, we automatically calculate correlations and interdependencies between the variables like productivity (represented by finished story points), mood (represented by scales from psychology [START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF] or from a mood board with emoticons) or the capacity. These calculations result in a System Dynamics model simulating and visualizing the hypothetic state of a sprint with given preconditions. When a team is modeled with System Dynamics, that team can use the model to recognize factors hindering an optimal sprint or impediments that need to be resolved in order to be more successful.

In this paper, we present our approach and its application in a case study at Arvato SCM Solutions 3 . The company initiated a collaboration with the Leibniz University Hannover considering fundamentals about methods and toolchains. These fundamentals would reveal, e.g., the tendencies of sprint success criteria, customer satisfaction during a sprint, or factors influencing a positive impression by the client. The industry partner had already experienced general impediments such as changing the scope of a sprint which has negative effects to reach the sprint goal. During the kick-off of the collaboration, an interest in social interactions and dependencies in the teams arose. The Software Engineering Group at Leibniz University Hannover has some experiences in analyzing interactions in a team such as the FLOW method 4 for information flow analysis in developer teams or tools for the analysis of interactions in meetings [START_REF] Schneider | Positive affect through interactions in meetings: The role of proactive and supportive statements[END_REF]. Developers, manager, Scrum master and product owner 5 of the industry partner wanted to know if these tools can be applied in an agile environment and if they can help to get better results for a sprint if the teams know their social impediments.

Arvato SCM Solutions wanted to get a supportive tool helping a development team to identify its impediments to reach the goal of its sprints. In particular, such a tool would help Scrum master and product owner to realize which influences their behavior can have.

As a further requirement, the team members should be able to understand the outcome of the model, i.e. the result of the simulation needs to be reliable. Otherwise, the team may refuse the model.

Building such a model is not trivial. While some parameters such as productivity (in terms of finished story points) can be easily quantified, others such as mood cannot. Hence, we need to combine both qualitative and quantitative data. We can formulate our research question as follows:

RQ: Is it possible to build a System Dynamics model including both qualitative and quantitative data with comprehensible, i.e. traceable, results?

As a first step towards this aim, the researchers from Leibniz University Hannover analyzed three development teams at Arvato SCM Solutions. The teams had just started their agile transition to Scrum some months before the study began. One team was in sprint number 22, another in sprint number 13 and the third team in sprint number 8 (with a length of two weeks per sprint). The case study took place over a duration of 18 months starting with a data collection and ending with the presentation of the model and its application. The duration of the study was due to the explorative nature. Replications of this study will not take that much time.

The simulation of the sprint and the analysis with the System Dynamics model uncover i.a. the fact that the teams' productivity increases towards the end of a sprint. Some of the found issues can also be found in other teams. Nonetheless, the model does not adequately represent the process and the interdependencies between the variables in a team of another organization. Therefore, we describe our approach to build the model. This procedure can be applied to other teams with a different data set.

The paper is structured as follows: In the following section, we give an introduction to System Dynamics. Previous work related to our research topic is presented in Sec. 3. Section 4 gives an overview of the study we conducted at Arvato SCM Solutions. It also provides information on building the model. We discuss our results in Sec. 5 and conclude in Sec. 6.

Background: System Dynamics

System Dynamics was developed to understand the behavior of complex systems [START_REF] Forrester | World dynamics[END_REF]. In the 1950s, Forrester [START_REF] Forrester | World dynamics[END_REF] presented his approach for modeling different parameters in order to understand industrial processes. System Dynamics enables holistic analyses and simulations of complex and dynamic behaviors. The simulation is based on a model taking into account relationships between various project parameters. Forrester [START_REF] Forrester | World dynamics[END_REF] presented a strategy for identifying such relationships and for modeling and simulating the interdependencies. We use this approach to gain more profound insights into the interdependencies and the project's dynamics [START_REF] Forrester | System dynamics, systems thinking, and soft OR[END_REF].

Causal Loop Diagrams

Causal loop diagrams visualize interrelations between different variables in a system [START_REF] Forrester | World dynamics[END_REF]. An example is visualized in Fig. 1. Mood (1), Productivity and Customer Satisfaction are considered. A positive marked directed edge (2), a so-called positive causal link, denotes a positive relation, i.e. if customer satisfaction increases, mood also increases. It is also possible to visualize negative relationships, i.e. if one parameter increases, the other one decreases and vice versa. Such links are called negative causal links. One example for this relationship is the influence of unexpected incidents during the sprint on mood: The more incidents, the more dissatisfied developers, i.e. the lower the amount of positive affect. A reinforcing feedback loop is defined to have an exponential increase or decrease. Mathematically, this is equivalent to having an even number of negative links (where 0 is also even). In Fig. 1, the reinforcing loop is visualized by [START_REF] Forrester | World dynamics[END_REF]. A balancing feedback loop is associated with reaching a plateau. This is equivalent to having an odd number of negative links. A balancing feedback loop is denoted as visualized with a "B" (instead of the "R" in (3)) and an arrow pointing counterclockwise [START_REF] Forrester | System dynamics, systems thinking, and soft OR[END_REF].

Stock and Flow Diagram

Stock and flow diagrams concretize causal diagrams by quantifying the system. They are used to study and analyze systems on a more detailed level. An example is visualized in Fig. 2. These diagrams consist of stocks (1) and flows (3). A stock represents an entity, i.e. parameter, that changes over time. A flow defines the rate of a change in a stock. So far unknown influences and parameters can be visualized by a cloud (2). In the given example, we have an influence of something not specified (2) on mood [START_REF] Abdel-Hamid | Software project dynamics: an integrated approach[END_REF]. The rate of the influence is defined by the flow (3). Each flow can be concretized by an equation. These equations and the feedback loops enable a simulation of the process. The better the equations define the influences, the more accurate is the simulation in the end.

Related Work

This paper aims at analyzing interdependencies between different parameters during a sprint. Some of these parameters are social aspects like communication behavior [START_REF] Klünder | Communication in teams -An expression of social conflicts[END_REF][START_REF] Klünder | Team meetings and their relevance for the software development process over time[END_REF]. Since soft factors can be hardly quantified, the commonly used methods to analyze human beings are rather subjective. In this approach, we use already established methods for modeling and simulating the specific context, for instance with System Dynamics [START_REF] Forrester | World dynamics[END_REF] to combine qualitative and quantitative data.

Klünder et al. [START_REF] Klünder | Communication in teams -An expression of social conflicts[END_REF] quantify communication behavior using the so-called FLOW distance. FLOW distance is a measure for indirections in information flow. Furthermore, the authors measure moods and social conflicts using scales which are established in psychology like the scale for positive and negative affect [START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF]. This way, the authors are able to find statistically significant relationships between communication behavior, mood, and social conflicts [START_REF] Klünder | Communication in teams -An expression of social conflicts[END_REF].

Herbsleb and Mockus [START_REF] Herbsleb | An empirical study of speed and communication in globally distributed software development[END_REF] also investigate on communication behavior. They analyze the behavior of co-located and distributed work teams. Their study is based on quantified data from the source code change management and a survey. The authors aim at finding causes for delay in distributed teams. Herbsleb and Mockus [START_REF] Herbsleb | An empirical study of speed and communication in globally distributed software development[END_REF] are able to uncover relationships between delay, communication, coordination, and geographical distance. They report a decrease in the frequency of communication with an increasing physical separation [START_REF] Herbsleb | An empirical study of speed and communication in globally distributed software development[END_REF].

These studies base on subjective quantified data which often depends on the perceptions of the team members (cf. [START_REF] Klünder | Communication in teams -An expression of social conflicts[END_REF]). All proposed metrics we are able to measure are integrated into our approach.

To find interdependencies between qualitative and quantitative parameters as well as to integrate assumptions, we modeled the results using System Dynamics.

The idea of simulating human factors and other project parameters is not new. Abdel-Hamid and Madnick [START_REF] Abdel-Hamid | Software project dynamics: an integrated approach[END_REF] investigated dynamic events in Software Engineering. They present different case studies of large software projects. Furthermore, they propose the use of metrics which help to measure the relevant aspects. Based on the data records and their experiences, the authors build system models with different complexities. Abdel-Hamid and Madnick [START_REF] Abdel-Hamid | Software project dynamics: an integrated approach[END_REF] give a detailed overview of various dynamic models underlining, for example, the influence of productivity on the motivation of a development team. Furthermore, they present an entire software project process chain.

Cao et al. [START_REF] Cao | Modeling dynamics in agile software development[END_REF] investigate dynamics in agile software development. They model interdependencies between various agile methods and practices such as pair programming, customer involvement or refactoring and organizational parameters such as productivity or cost. The authors also use System Dynamics to generate the simulation model [START_REF] Cao | Modeling dynamics in agile software development[END_REF].

Madachy [START_REF] Madachy | Software process dynamics[END_REF] models communication behavior and other team parameters. He simulates qualitative models to understand process dynamics. His work is based on formal boundary expressions with a wide range of parameter settings.

Hoegl et al. [START_REF] Hoegl | Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence[END_REF] present a concept about the quality of teamwork. They identify factors influencing the success of software projects. They consider aspects such as team performance and satisfaction. The relevant factors for teamwork are communication, coordination, a balance of contribution, mutual support, effort, and cohesion [START_REF] Hoegl | Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence[END_REF]. The authors base their results on an empirical study providing data from 575 developers and project leaders in 145 German software development laboratories [START_REF] Hoegl | Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence[END_REF].

Shiohama et al. [START_REF] Shiohama | Estimate of the appropriate iteration length in agile development by conducting simulation[END_REF] deal with the question of an appropriate iteration length. They present a procedure to calculate the recommended iteration length by simulating the sprint. They integrate parameters such as the development team, the probability of incidents during the sprint and the complexity of the project.

In previous studies, Kortum et al. [START_REF] Kortum | Early diagnostics on team communication: Experiencebased forecasts on student software projects[END_REF] have already explored team behavior in academic software projects. The first models [START_REF] Klünder | Forecasting communication behavior in student software projects[END_REF][START_REF] Kortum | Early diagnostics on team communication: Experiencebased forecasts on student software projects[END_REF] base on machine learning classifier and enable forecasts for key communication metrics. But these models only considered linear dependencies and few quantitative data. We want to extend these approaches by also considering non-linear interdependencies [START_REF] Kortum | Don't underestimate the human factors! exploring team communication effects[END_REF] and qualitative data.

In contrast to the already existing approaches, we do not want to answer a specific question using our simulation. Indeed, we want to explore team dynamics to uncover unexpected interdependencies. Nonetheless, we integrate results of already existing models such as measurements, metrics and best practices for setting up the model. Furthermore, we integrate data types which have -to the best of our knowledge -not yet been considered in related approaches. These are results from an interview study uncovering the information flow and results from a workshop representing subjective assumptions about the relationships to use unquantifiable data such as moods6 .

Study: Setting Up the Model

In order to examine the applicability of our approach, we conducted a case study in a company. The whole study based on a collaboration between Arvato SCM Solutions and the Leibniz University Hannover.

Methodology

Our general approach can be divided into several phases starting with the data collection and ending in the simulation model. An overview of these phases is visualized in Fig. 3. (1) Phase one starts with interview studies to get to know the culture of the company and the processes from an external viewpoint. We need to gain these insights in order to prepare the causality model. The structure of the interviews bases on the FLOW method [START_REF] Schneider | Beyond documents: visualizing informal communication[END_REF] which is an already established proceeding in software engineering to get an overview the information flow within an organization and to get to know the process from different viewpoints.

(2) Afterwards, we collect different kinds of easily available data records. It is necessary to receive as much data as possible influencing the main issues which should be analyzed with the simulation model. Later, it is possible to integrate assumptions for non-accessible data (see ( 4)). We recommend using data for example contained in JIRA such as productivity, finished and open story points, sprint interruptions and so on.

(3) In phase three, we create a potential process model also visualizing assumed dependencies between the collected data and other variables like mood. This model does not necessarily rely on the data. Calculations are also not necessary. This first instance of the process model only represents possible and intuitive interdependencies between the variables. It will be validated later.

(4) During phase four, we integrate subjective perceptions from different team members, Scrum master, and other involved persons. They are asked to rate the causal effects in the process model (for example the influence of customer satisfaction on team mood) and to specify and concrete the model. The more different persons the more reliable and the more complete the subjective results are. We recommend using a scale between -3 (for a strong negative relation) and +3 (for a strong positive relation). A rating of 0 indicates no relationship between the two variables. This way, the analyst gains an overview and a first idea of relationships and dependencies. This step is very important for the developers' awareness of the final model.

(5) Afterwards, the analysis starts with a visual preparation of the data with respect to history, temporal progressions and other effects. The analyst also looks for relationships between variables in the data set that are easy to detect. In the best case, these relationships also fit the interview study and the model resulting from step (4). ( 6) Phase six aims at creating the System Dynamics model. This step is the most time-consuming one. A description on how to set up the model can be found in [START_REF] Kortum | Characterizing relationships for system dynamics models supported by exploratory data analysis[END_REF] and [START_REF] Kortum | Don't underestimate the human factors! exploring team communication effects[END_REF]. We transfer the causality model into the System Dynamics model. The relationships between different project parameters can be retrieved using explorative data analysis for example with MINE [16]. This analysis helps to detect dependencies between the variables. Furthermore, the explorative analysis can detect relationships which have been unknown so far. Afterwards, we need to formalize the dependencies in order to include them into the System Dynamics model. We need further analyses, logical associations and a clean-up of the data set with respect to missing data. In this step, we can use the ratings from step (4). For example: In the case that all developers state that the presence of the product owner during the sprint is very important for their motivation, this fact needs to be considered in the model even if there exist no underlying data. This way, we conclude the model step by step. It gets more and more concrete and detailed. The whole model might be too large. Hence, irrelevant factors (according to the aim of the model) can be identified and eliminated. The model's behavior in seldom situations is also very interesting. Hence, the model should be analyzed by running the simulation 1000 times. [START_REF] Klünder | Forecasting communication behavior in student software projects[END_REF] In the last step, we validate the insights from the model by comparing them with the data sources, i.e. the development teams. This can be done best during a workshop with the developers, the managers and the persons who are responsible for the process. Presenting some behavior and structures with the model may or may not lead to a "wow"-effect. The model aims at increasing the awareness of the involved persons with respect to possibly unknown or forgotten interdependencies. Hence, it is very good if the persons agree with the model. (8) Now, the persons can start using and testing the model by changing some parameters like sprint interruptions. The more intuitively the model behaves, the more they will rely on it. But some unexpected issues are also important to show the impact of the model. It does not aim at forecasting exact values, but it aims at visualizing the system's behavior and increasing the transparency of consequences in order to enable some improvements.

Execution: Case Study in Industry

The whole study at Arvato SCM Solutions was performed as on-site research, where the researchers got to know the common behavior of managers, some Scrum master, and developers. By being involved in meetings with regular team members participating, the researchers could grasp a better understanding compared to an external person about the collaboration structures and company spirits. The collected impression and representative system data formed the fundamentals of the idea of a simulation model about the team's operational behavior in such this exemplary company.

(1) Some weeks later, the interview studies started according to the FLOW method [START_REF] Schneider | Beyond documents: visualizing informal communication[END_REF]. A FLOW interview has a generalized process starting with some general questions like tasks within the team or the years of experiences of the interviewed person. This way, a basic understanding of the internal processes in the Scrum teams and the information exchange with the product owner and the customer emerged. For each task, the interviewee reports about the outcome as well as incoming, controlling and supporting issues like templates, knowledge or checklists [START_REF] Schneider | Beyond documents: visualizing informal communication[END_REF]. The researchers interviewed three persons: one product owner, one developer and one SQL expert who is part of two teams. Descriptive data can be found in Table 1. The interviewees are members of the teams we considered in the further analysis. The team members were free to decide whether they wanted to give an interview or not. (2) One researcher from Leibniz University Hannover dedicated two weeks on-site at Arvato SCM Solutions to gain deeper insight into communication behavior and social aspects such as mood, productivity and the collaboration between the team and the product owner. The researcher observed three teams who agreed to participate in the study. Data from JIRA have also been collected from all sprints such as burndown charts, i.e. the reduction of unfinished story cards during the sprint. The researchers received data about sprint results, i.e. finished and not-finished story points, and the burndown charts. Furthermore, data about the teams' capacities and the customer satisfaction which have been collected in the company right from the beginning have also been included in the model. Unfortunately, there was no data representing the mood of a single team, because the "mood board" is used by all teams. Hence, it only represents the overall mood and it was impossible to distinguish between the data from the three observed teams and all the others in the company.

(3) Afterwards, the modeling phase started by drawing a causality diagram mainly resulting from the insights of the work shadowing. It only contains rather obvious dependencies and relationships. It was designed very light-weighted with some keywords like mood, motivation, productivity and capacity connected by directed arrows. The causality diagram is visualized in Fig. 4. The researchers expect an influence of HR-Capacity, i.e., the availability or absence of developers, on the sprint and the commitment constancy, i.e., the proportion of the story points the team wanted to finish during the sprint and the story points which are finished. This parameter influences customer satisfaction which influences the team mood. This, in turn, influences the whole sprint which also influences burndown charts and the customer satisfaction. The burndown chart represents the number of already finished story points and is hence an indicator of commitment constancy. (4) The model in Fig. 4 was the basis for the next step. Two researchers met some interested persons from the company in a two-hour-workshop. Two Scrum master and four developers attended the workshop. One manager also temporarily attended the workshop. The participants were asked to rate the relevance of the relationships and find other dependencies. In pairs, they completed the diagram, removed arrows, added weightings representing the number of influences of one parameter on another one, and so on. We used a scale as proposed in the previous subsection in step [START_REF] Forrester | System dynamics, systems thinking, and soft OR[END_REF]. At the end of this workshop, the researchers had an overall causality diagram representing the perceptions of the persons who are involved in the process. This step was important to increase the credibility of the model. The cumulated results of this step are visualized in Fig. 5. Compared to Fig. 4, we have much more parameters after this step. Most of the parameters from step (3) remain, but the developers and the Scrum master stated a strong influence of meetings like refinements, the retrospective and the review on other factors. Furthermore, they rated the availability of the product owner as important.

(5) Afterwards, the data analysis started. The researchers used system records provided by JIRA and subjective responses about each sprints team capacity and the customer satisfaction. They derived metrics such as productivity as a Fig. 5. Causality Model with weighted relationships (+/-: positive/negative relationship (i.e. "the more, the more" / "the more, the less") in the direction of the arrow; 1/2/3: weak/medium/strong relationship) measure defined via finished story points per hour or the customer satisfaction index derived from the customers' ratings. The metrics were combined for example with timely delivery and resource balancing. Additionally, timestamps have been divided into weekdays, holiday breaks and other events that could influence the teams' regular performances. Due to the information on burndown charts, i.e. the relation of finished and remaining story points, unplanned work (e.g. bug fixing) has also been considered. These incidents could be recognized due to an increasing number of story points in the sprint. [START_REF] Hoegl | Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence[END_REF] In fact, all this information from the first five steps, especially the outcome presented in Fig. 5, allow to derive a first System Dynamics model based on the standardized stock-flow terminology [START_REF] Forrester | System dynamics, systems thinking, and soft OR[END_REF]. In its very first building step, it only gives a system overview of all involved endogenous and exogenous components [START_REF] Forrester | System dynamics, systems thinking, and soft OR[END_REF]. For the formalization of functional equations representing the interdependencies between various system components, we applied exploratory factor analysis to describe historical JIRA data in multi-functional equations. The dependencies and influencing factors without available objective data records become distinctively equalized through the rating from step (4).

The System Dynamics module for the productivity is visualized in Fig. 6 (marked with an (x)). This is one part of the whole System Dynamics model. Additionally, a dashboard user interface was built for exploratory simulation without a detailed need for knowing about every single module. A screenshot can be found in Fig. 7. The System Dynamics model and dashboard interface can be accessed and explored online 7 .

Performing this step for each of the variables and combining each of the modules leads to the model presented in Fig. 6.

Verification and Validation

(7) For a better validation of the model's functional units, the researchers modularized each central and relevant metric in a separate function block. The correct functional operating was approached with real input ranges, whereas the outcome passed a plausibility test due to realistic operational ranges. Each functional module such as the one for productivity (marked with an (x)) in Fig. 6 characterizes its internal factor and dependencies and become solely verified in its input and outcome behavior according to experts expectations and data records from the previous sprint.

To gain objective results, we performed a sensitivity analysis to consider the influence of a given set of starting parameters for the simulation. Fig. 8 visualizes the daily productivity dynamics within one sprint. The x-axis represents the day of the sprint, and the y-axis covers the productivity on a rational scale. Since the model also takes weekends into account: The productivity is 0 some days. We have run 9000 sample simulations with the System Dynamics model and randomly generated parameter settings within the realistic operating ranges. As visualized in Fig. 8, the 100 variations of parametric inputs show that the common productivity follows a constant level for the first week of a new sprint. The results also sample that most dynamics during a sprint occur during the second half of a two weeks sprint. The course of the curves is comparable. Sensitivity analysis, in particular, involved the parameter inserts for a sprint planning about available human resources (60-150 working hours) and story points (80-120). There is an obvious increase in productivity in the last days of the sprint which seems to keep its proportional distribution regardless of whether teams have to face a high workload or not. In fact, the simulations pointed out that the teams typically finish larger story cards upfront the end of a sprint. Furthermore, they seem to finish story cards even with double speed compared to tasks at the beginning of the sprint. The term "double speed" is relative since the results also can be interpreted as that teams work slower at the beginning of a sprint and increase their regular performance shortly before the due date. In fact, the simulation uncovered some of the real situations that could be also confirmed by the management about their perceived impression on the team's typical workload during a two weeks sprint. When teams faced real pressuring situations due to last minute changes, customer claims, or an inappropriate sprint planning, the resulted team atmosphere became strongly affected, whereas particular situations could be also matched within the system model. This analysis based on a regular sprint with ten days and without extraordinary events decreasing a team's productivity such as holiday breaks. During sprints with breaks, for example, due to holidays, the peak of maximum productivity appears to be more present right after the holidays, whereas the productivity tends to reach its minimum right before the break. [START_REF] Klünder | Fake news: Simply agile[END_REF] To ensure the credibility of the entire model, some developers, Scrum master, product owner, and manager used it with different inputs and decided on the reliability of the results. 8 The conjunctions of all function blocks with the system resulted in statistical measures and subjective experience ratings as well. They were also validated through data records. The practitioners tested the model using different preconditions of sprints they had in mind. Some of the sprints have been "regular" ones, i.e. sprints without incidents and a satisfying sprint result in terms of story points, customer satisfaction etc. Others of the sprints used for testing the model have been outliers, i.e. with many incidents like bugs, fluctuations in the capacity due to illness and company-wide both pleasant and unpleasant events. According to the practitioners in the three observed teams at Arvato SCM Solutions, the model and the visualization with System Dynamics simulates the sprints of the three teams very well. The visualization shows similar sprint results in the simulation and as expected (in futurespective) and as it has been (in retrospective) in real life.

The curve of mood during a sprint is also near to reality according to the product owner and the developers. This was checked with sprints out of the period of data collection, including sprints after this phase and also with sprints in other teams in the company environment at Arvato SCM Solutions. All in all, the model behaves intuitively in many points. This is very important for the reliability of the model. Nonetheless, there are some relationships which have been perceived to have a lower relevance for the development process.

Results and Implications

We, i.e. the researcher, manager, Scrum master, and other team members, detected some findings revealed by simulating real and potential sprints with the model. In Table 2, we present some of these weaknesses with suggestions for improvement. The suggestions and the causes for the findings are not complete. The causes need to be identified. This still requires manual effort and background knowledge. Combining the simulation with insights from the researcher's hospitation and the practitioners' experience led to the following result.

Discussion

According to our results, we can affirm our research question. It is possible to combine qualitative and quantitative data in a System Dynamics model and maintaining the credibility.

Threats to Validity

There are some aspects and limitations which may have to threaten the validity of our case study. According to Wohlin et al. [START_REF] Wohlin | Experimentation in software engineering[END_REF], we categorize these aspects as construct, internal, external and conclusion validity. ID Description F1 In the end of a sprint, the productivity increases. C1 The increase of productivity may be caused by too large story cards, the developers cannot finish earlier. S1 The developers need to break down the story cards into smaller ones. C2 The developers may forget to change the state of a story card (in JIRA and on the physical board). S2 It is important that both boards are synchronized (latest in the next daily).

Furthermore, at least the state of a story card in JIRA needs to represent the actual state of a story card. F2 There are often unfinished story points in the end of a sprint. C3 The goal of the sprint in the number of story points was unachievable. S3 Provide the possibility to learn from former sprints, e.g. how many story points have been finished C4 There have been too many incidents during the sprint leading to less capacity. S4.1 Try to keep the number of incidents (e.g. helping other teams) small. S4.2 Get to know about planned support in other teams before the sprint starts. C5 There have been undetected dependencies between story cards. S5 Spend as much time as necessary with planning the next sprint, i.e. backlog refinement, Sprint planning etc. F3 Incidents influence the motivation, the mood and the productivity. S6 An incident goes along with adapting the plan. Often, the developers lose focus and realize that they cannot reach their sprint goal. This mostly leads to dissatisfaction. C6 It is often impossible to have no incidents. But avoiding firefighting situations helps the team to keep focused. F4 Positive incidents such as story cards that are excluded from the sprint are not always good. C7 An exclusion of a story card creates the feeling of having much more time for the other story cards. Hence, the productivity decreases. S7 The team should be aware of possible negative impacts of positive incidents.

However, with an increasing agile maturity, the team will be satisfied with positive incidents without reducing the productivity.

Construct validity. The presented model based on both objective and subjective measures. The causality diagram completely depends on the perceptions of some team members and Scrum master. In the case where we do not have had any objective data for the simulation model, we indicated the dependencies and influences as supposed by the developers. This may have influenced the perceptions of the developers when seeing the overall model and its reliability.

Internal validity. In this contribution, we present the results of a case study with three agile working teams within one organization. We used the data from all teams simultaneously to create one overall diagram. Hence, we cannot make any statements with overall validity. The three teams do not represent the whole width of agile working teams. It is like a case study that generalizations are only limited possible.

Conclusion validity. The data analysis was completely computer-supported. It was based on the MINE[16] algorithm as presented in [START_REF] Kortum | Characterizing relationships for system dynamics models supported by exploratory data analysis[END_REF]. Hence, the analysis is objective and the results based on the data, too. But we do not have any objective data for mood. Since we wanted to include this parameter in the model, we used subjective perceptions of experienced team members and Scrum master reporting on the influences of mood on other parameters and vice versa. But this data is only little reliable.

External validity. The results may not be over-generalized. But the proceeding for the creation of the model may be applied to different kinds of teams, even working in different contexts and with other work-organizations like the V-model. Basing the model on the data of other teams or even on different kind of data (i.e., different variables) will surely lead to a different model. At this time, the model is team-specific. But including the data from other teams and extending the model will allow generalizations.

Limitations for the Use in Industry

The model has restrictions when a team has a high degree of agile maturity. It took more than a year to get the model and the visualization by System Dynamics. In between most of the teams improved their skills. They improved their technical skills, they improved the ability to handle impediments and interventions in the sprint, they improved estimations of the stories, and they improved the skills in team working, communication and other soft skills. In sum, they improved their level of agile maturity. With the new team constellations, the model is difficult to validate, because Arvato SCM Solutions does not collect all the data needed as a database for the model anymore. Because of the agile maturity, these teams do not need all kind of data for their continuous improvement process.

Now the teams can handle interventions and changes in a sprint very well, and they reached the defined goal of the sprint near to 100% defined as committed vs. achieved story points. Also, the product owner has high confidence in the development team and therefore the mood is good -mostly. Because of the combination of missing data and the stable mood, the model and the visualization do not work anymore for our teams -at least in the current version.

Retrospectively, Arvato SCM Solutions could identify the same tasks for improvement for a team through this simulation. For example, most of the stories in a sprint were set to state "done" during the last three days in a sprint. This could mean that the team is most productive only at the end of the sprint. But according to the experiences of the managers at Arvato SCM Solutions, in most cases, there are too many stories in a sprint with more than 13 story points for a story, which is the largest possible number of story points for a single story card. They are too big. The teams do not have a chance to finish this story earlier in a sprint. One solution is to increase the ability of the team to split bigger stories into smaller ones which require knowledge in story splitting.

A conclusion: The module and System Dynamics simulation is working very well for teams which are in the transition from an old work environment to an agile framework like Scrum. There is a need to collect a lot of data to use this model and tooling. But using a ticket system like JIRA, facilitates the selection. It is not easy to identify the correct actions for improvement. However, the simulation will support a team to make their challenges more visible. Finding the right solutions will depend on the team, and they have to try out different ways.

Interpretation

Software process improvement is an important topic for many teams and organizations. However, detecting the potential for improvement is not always easy since most processes are too complex to see the interdependencies "on the fly". Tools can support the detection of issues that may be improved.

Software development teams prefer support by tools and the management tends to use visualizations. Visualizations like burndown charts show the current state and the past progress of a sprint. This System Dynamics model can simulate the next sprint and visualize a sprint result under different circumstances such as added or deleted stories, added resources supporting the team, sick members or members of vacation, etc. Based on the results, the team and the Scrum master can identify the challenges and try different variants and find potential solutions.

This concrete model and the simulation are only helpful for teams when they use Scrum as a work environment and do not have a mixture of a classic work environment such as the waterfall model. The goal of a successful sprint should be nearby 100% of achieving the committed stories and story points. A permanent over-or under-commitment for a sprint does not help to get a stable team result. Two other preconditions for using this model is to have a stable team, and the sprints have to have a fixed length for a long time.

To use this model, it is important to have a good base of data and information. All data about the sprints (stories, story points and the states of the stories) should be in a ticket system like JIRA. The information about team capacity and mood factor should be tracked in parallel. When this data is available for a team, this model can be adopted by another organization.

In summary, this model can be a good addition to the general toolset for Scrum. By simulating future sprints and running sprints from the past with different circumstances, the challenges and impediments in a team can be better analyzed -and supported by a tool. All these information can help a team and the Scrum master to identify the next actions to increase their agile maturity and in the end the productivity and profitability of a team.

A foresight: This model and its simulation is a good base for full-service tooling which can be used by each Scrum team. All needed information for the sprint (stories, story points, length of a sprint, etc.), the number of team members, a capacity planning of the team and other parameters for soft factors should be tracked in one tool. JIRA is a system which handles most of the information when it is used as a ticket system by the development team. It is also possible to develop add-ons in JIRA to put additional data into a sprint. So an add-on for JIRA bringing in all needed parameters to the general sprint data can be used to visualize sprints with a different view.

Conclusion

In this contribution, we presented strong synergies between different techniques for analyzing teams. We combined statistical and information flow analysis to build a System Dynamics model simulating interdependencies between various team parameters in agile software development. We extended quantitative data from JIRA by subjective ratings from the teams. This combination of objective and subjective statements on interdependencies helped to form the simulation model with a good prescription of dynamic team behavior during sprints.

The outcome of running the simulation fits the first expectations of both the researchers and the developers as well as Scrum master, product owner, and manager. Despite the model simulates the reality very well and is easy to use, the time for the realization needs to be shortened to replicate this study. Currently, the model is limited in the possibilities for the application. It may be adapted to other teams and organizations, but at the moment, it is only applicable to the development teams at Arvato SCM Solutions or comparable ones. But within the scope of application, the model represents the reality very fine-grained and reveals interdependencies which have not been observed before.

Fig. 1 .

 1 Fig. 1. Exemplary causal loop diagram visualizing a positive reinforcing loop.

Fig. 2 .

 2 Fig. 2. Exemplary stock flow diagram.

Fig. 3 .

 3 Fig. 3. Overview of the process

Table 1 .

 1 Overview of the interviewees and the duration of the interviews Interviewee I Interviewee II Interviewee III Duration of

Fig. 4 .

 4 Fig. 4. First causality diagram in the end of step (3)

Fig. 6 .

 6 Fig. 6. System Dynamics Model. The productivity module is highlighted.

Fig. 7 .

 7 Fig. 7. Dashboard visualizing different sprint parameters after having entered given preconditions

(

Fig. 8 .

 8 Fig. 8. Productivity variance results from 100 sample simulations

Table 2 .

 2 Findings (F) revealed by the System Dynamics model, possible causes (C) and suggestions (S)

https://scm.arvato.com/en.html

http://www.se.uni-hannover.de/pages/en:projekte flow

At Arvato SCM Solutions, the manager, Scrum master, and product owner build a triumvirate for a team. The manager is responsible for the people management and their personal evolution, the Scrum master is responsible for the processes in the agile environment and the product owner is responsible for the enhancements of the product and the functional stories.

There are possibilities to measure moods (e.g. with the PANAS scale[START_REF] Watson | Development and validation of brief measures of positive and negative affect: The PANAS scales[END_REF]). But in our case study, it was not possible to measure moods retrospectively.

The System Dynamics model is available via http://www.goo.gl/Bnavhb.

For validity reasons and to test the generalizability (to some extent) of the model, we also asked team-external persons (but no company-external ones) to test the model.


Carmelo Ardito

Danilo Caivano

Lucio Colizzi

Loredana Verardi

Towards a Model to Address the Interplay Between IoT Applications and Users in Complex Heterogeneous Contexts

Keywords: Business processes, Knowledge model, Ontology

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction and Motivation

The Internet of Things (IoT) is the most pervasive technological trend of the last years, because it represents the contact point between the physical and the digital world through the use of Internet technology. IoT represents a global technological infrastructure, based on interoperable standards and protocols where objects, both physical and virtual, acquire attributes, identities and personalities, communicate with each other and modify their behavior according to rules, conditions and the evolution of the whole ecosystem. Thanks to the IoT, everything can take on new functions, collect and communicate information, receive commands, and support people in a multitude of old and new tasks.

The miniaturization of electronics, the speed of data transmission, the spread of mobile devices, the growing computational capacity and Internet-based communication protocols have transformed scenarios and frameworks, since the IoT systems perform functions that are widespread across the territory and involve a multitude of actors (as in Smart Cities), allowing contextual information to be provided to users (Smart Environments). The result is a transformation of traditional business processes, in which the IoT necessarily becomes a resource and a driver: the focus is on data and their exploitation through a pervasive use of digital technologies in order to connect, innovate and manage the whole business value chain.

Smart City projects aim at making urban area more efficient in terms of mobility, environment, economy, living, people, and governance. For this purpose, technology must be easily usable by citizens, as well as businesses and public institutions; it must be distributed, shared and horizontal, in order to foster citizens' participation. The digital process of city transformation, therefore, requires a strong and drastic paradigm shift compared to the past, putting the citizen at the center and the government at its services, with particular emphasis on their simplicity and usability. It is not only an issue of publishing some information in Open Data format, but of adopting a new paradigm based on the idea of citizens' active participation, moving from passive service consumers to Smart Citizens, who are actors in the definition of services and co-creators of new ideas. The typical culture of participation of a Smart City would be perfectly translated, at a technological level in the application development process, with the adoption of the User-Centered Design approach, which considers the stakeholders and the end users as co-designers of a solution, even if they do not have programming or technological skills [START_REF]Human-Centred Design Processes for Interactive Systems[END_REF].

However, in order to adopt a User-centered perspective, we have to provide answers to questions regarding the use of the most suitable semantics for an application, both for describing the application domain and for considering the different types of users that interact with it. In other words, we have to provide tools for solving the ambiguity of many terms and for representing the information with the most suitable constructs, not only for the application domain but also for the user that interacts with it. For example, the Public Administration (PA) domain is composed of numerous sub-domains representing the different operational areas of a city (Mobility and Traffic, Environment, Tourism, Health, etc.). A multitude of actors (e.g., administrative employees, politicians, citizens, companies, domain experts) are involved: they have different interests, technological skills and execute different tasks. The same IoT device could be used in several subdomains of the PA: the detected data can therefore assume a different semantic meaning according to the process in which they are used, or to the user type whether it is inside the same PA (e.g., a process manager) or outside the PA (e.g., a citizen).

The data collected through the IoT device must be appropriately enriched with attributes and semantic relations in order to be transformed into information useful and semantically comprehensible to the user, and this operation must necessarily be conducted by a domain expert, who knows the scenario and the environment in depth. However, to the best of our knowledge, the topics of semantics related to the integration of business process modeling and of IoT as a new process resource in data driven systems was investigated in [START_REF] Meyer | Internet of Things-Aware Process Modeling: Integrating IoT Devices as Business Process Resources[END_REF][START_REF] Suri | Semantic Framework for Internet of Things-Aware Business Process Development[END_REF] only. Semantic issues about the interplay between IoT-based applications and different types of users in complex and heterogeneous contexts, such as Smart Cities, are still neglected.

This paper aims to describe and explore issues related to the semantic characterization of IoT-based application development in the Smart Cities domain: it proposes a user-centered approach oriented to software developers, who must evaluate semantic issues related to user's interaction. The paper describes which ontologies are needed to support the development of an IoT application using a user-centered approach. A formal classification of attributes and semantic relations is proposed, to be used according to the considered user perspective, in order to:

 use the most appropriate subset of attributes and semantic relations extracted from different ontologies involved in the development of an IoT-based application in the Smart Cities domain;  solve conflicts or disambiguate concepts that are available in various of the considered ontologies;  encourage and support the reuse of ontology subsets in the development of IoTbased applications.

The paper is organised as follows. Section 2 provides a brief overview of the existing studies on ontology in the IoT domain. Section 3 illustrates the proposed approach and suggests a classification for the semantic structures involved in the development of IoTbased applications. Section 4 reports conclusions and future work.

Related Work

While the technological issues due to the variety of involved actors have been successfully addressed through the development of methods and techniques of participatory design and facilitated visual programming -from software design patterns such as Model-View-Controller (MVC) to Web mashups (see, for example, [START_REF] Ardito | Making mashups actionable through elastic design principles[END_REF][START_REF] Desolda | EFESTO: A Platform for the End-User Development of Interactive Workspaces for Data Exploration[END_REF]) -the questions regarding the use of the most suitable semantics for an application remain open, both for describing the application domain and for considering the different types of users that interact with it.

Studies related to the integration of IoT and business processes are already available in the literature [START_REF] Janiesch | The Internet-of-Things Meets Business Process Management: Mutual Benefits and Challenges[END_REF][START_REF] Meyer | The Things of the Internet of Things in BPMN[END_REF]. In particular, they address how to extend the standard process modelling approaches, such as the Business Process Model and Notation (BPMN), in order to include IoT as a process resource [START_REF] Meyer | Internet of Things-Aware Process Modeling: Integrating IoT Devices as Business Process Resources[END_REF][START_REF] Meyer | The Things of the Internet of Things in BPMN[END_REF]. However, such studies have mainly focused on process modelling and on technological aspects of the IoT. Further challenges are posed from a semantic point of view, but those authors who considered this aspect also approached it from an organisational and technological perspective. For example, Bauer et al. defined a common and unified ontology to overcome the problems related to the heterogeneity and interoperability of IoT devices [START_REF] Bauer | Internet of Things -Architecture IoT-A Deliverable D1.5 -Final architectural reference model for the IoT v3[END_REF].

In literature there are various studies about semantic technologies applied to the IoT domain, in order to enable interoperability and foster machine to machine communication [START_REF] Szilagyi | Ontologies and Semantic Web for the Internet of Things -a survey[END_REF]. Various research initiatives addressed the IoT domain, by proposing reference architectures (such us the European FP7 project "The Internet of Things Architecture" (IoT-A) [START_REF] Bauer | Internet of Things -Architecture IoT-A Deliverable D1.5 -Final architectural reference model for the IoT v3[END_REF]), and semantic models [START_REF] De | An Internet of Things Platform for Real-World and Digital Objects[END_REF]; the European H2020 FIESTA-IoT project provides a simplified semantic model called IoT-Lite [START_REF] Bermudez-Edo | IoT-Lite: A Lightweight Semantic Model for the Internet of Things[END_REF]. G. Bajai et al. [START_REF] Bajaj | A study of existing Ontologies in the IoT-domain[END_REF] propose a survey of the existing ontologies which include ontological IoT concepts (e.g., sensor capabilities and context-awareness) and identify the core concepts required for developing an IoT application.

Instead, there is a limited number of works about the integration of Business Process (BP) modeling techniques in the IoT domain. Mayer et al [START_REF] Meyer | Internet of Things-Aware Process Modeling: Integrating IoT Devices as Business Process Resources[END_REF] propose an integrated view of IoT concepts in BP modeling. Suri et al. [START_REF] Suri | Semantic Framework for Internet of Things-Aware Business Process Development[END_REF] introduce a semantic model (IoT-BPO) by re-using and extending concepts from IoT-Lite and build relationships between concepts of the BP domain (i.e., tasks) and concepts of the IoT domain (i.e. devices, service).

The Knowledge Stratification Model

Let we consider the use case of a municipality that is installing devices equipped with different sensors that provide data on traffic and air pollution. These raw data, that in Fig. 1 we call Real World Data, are:

 A (lat, long): coordinates of the location where the device is installed;  S 1 (vehicle counter sensor): numbers of vehicles passing through A at time t;  S 2 (CO 2 sensor): milligrams of CO 2 in A at time t.

Further data (S 3 , …, S n ) could be collected by additional sensors. S 1 , …, S n data represent the input data for one or more Business Processes of the Municipality. For example, the S 1 raw datum is one of the input, together with A, to process P 1 "Road congestion quantification" of the Mobility Department for determining road congestion levels (calculated as the number, exceeding a pre-established threshold, of vehicles passing through A in a time interval); A and S 1 data are also the input to process P 2 "Air pollution level measurement" of the Environment Department, which processes it together with S 2 to determine the pollution level in a time interval of a specific area of the city (to which point A belongs) due to the transit of vehicles.

The connections between elements of the same layer indicate interactions and/or combinations between these elements. For example, sensors S1 and S2 are in the same device D1; process P4 uses processes P1 and P2; User application A1 offers different views, as v1 and v2.

The connections between elements of different layers indicate how raw data produced by sensors are transformed first into information (through calculation procedures and algorithms), then into knowledge (through contextualization in the domain of knowledge, e.g. Environment or Mobility, and correlation/combination with other data), called Output Knowledge. The knowledge produced by the business processes is then represented through User Applications aimed at end users who can be both internal (employees, politicians, etc.) and external (citizens, businesses, associations, etc.) to the Municipality.

- The User Applications have to satisfy the needs of the different users who interact with them, through semantic and graphic constructs aimed at facilitating usability. In fact, appropriate visualization and interaction techniques support users in distilling knowledge, which becomes "awareness" of reality (or "wisdom" as defined by Ackoff in the DIKW architecture [START_REF] Ackoff | From data to wisdom[END_REF]) and in turn can generate further knowledge, which is the typical example of Open-data reuse (see Fig. 2). The model in Fig. 1 also shows the actors and their involvement in the different layers:

 Technical Experts are software developers, who define and implement procedures and constructs for interfacing the sensors with the Business Processes;  Domain Experts are experienced and representative users of the considered domain, who collaborate with the Technical Experts to formalize the domain knowledge at the level of both processes and terminology, as well as the semantic concepts most suitable for that domain;

 End Users are all users who can interact with the User Applications, differentiating them by their role with respect to the Public Administration (employees, citizens, businesses, politicians, etc.).

In order to support designers in creating IoT applications, the KSM model has to guide them in organizing the domain concepts, in identifying the data produced by IoT devices and in integrating them into business processes, thus making them meaningful for the user.

The EER schema reported in Fig. 3 shows how the concepts of IoT Resource, Process, Output Knowledge and User are related to each other. The schema implements a recursive structure of multi-graph type.

Each process has a specific classification or taxonomy (e.g. executive process, business process, generic process of domain, specialized process of domain, etc.) and, possibly, shares some phases (sub-processes) with other processes, as modelled by the selfrelation "Pr_hierarchy". The classification potentialities of recursive topological structures permit to semantically describe IoT resources (which can be simple sensors, devices, actuators or other complex systems) with the self-relation "Res_hierarchy". The ternary relationship "contributes" represents the transition from information to the knowledge gained from IoT data processing performed by business processes. The Output_Knowledge can also be organized according to a tree topology structure, which is suitable for building interface templates that depend on the characteristics and needs of the specific user: it is been modelling through the ternary relationship "know_hierarchy".

The EER model shows how the concepts of IoT Resource, Process, Output Knowledge and User are related to each other, but it cannot allow to infer new knowledge, because table instances generated from the EER model have values only when the process occurs. Moreover, EER does not consider some critical issues related to: 1) technology, e.g. interoperability between heterogeneous IoT resources; 2) process modelling, e.g. considering the IoT resource as a business process resource; 3) user interaction (disambiguation of terms, graphical constructs suitable to user skills, etc). Such criticalities can be addressed by adopting a semantic approach, based on a OWA(Open World Assumption) modelling and a specific ontology for each layer of the KSM and also for the interaction among layers (see Fig. 4) The ontological model is composed of the ontologies that Technical experts should use for developing IoT applications and it shows how the ontologies are connected each other: the arrows point towards the ontology to be imported. Technical experts must use a subset of these ontologies, creating or just importing the necessary ones, in order to consider all the layers of the KSM model:  Iot Ontology: an ontology, for example the IoT-Lite ontology [START_REF] Bermudez-Edo | IoT-Lite: A Lightweight Semantic Model for the Internet of Things[END_REF], is necessary due to the heterogeneous characteristics of the devices (different vendors, protocols, etc). The IoT ontology allows Techinical expert to standardize IoT Resources through semantic annotations avoiding technological issues, as interoperability. For example, the vehicle counter sensor could be associated with the geographical coordinates of the installation point and with the street name in the applications for the Mobility Department and for the Environment Department, respectively. The same "location" attribute could therefore be used in a different way, with some effects on automatic procedures based on attributes (e.g. geolocation on a map) or on the activation of internal processes within the public administration that uses them.  Business Process Ontology: in order to be meaningful for the business processes, which are often represented with BPMN, IoT Resources need to be integrated into business processes and not be considered as external to them. A suitable ontology is the IoT-BPO ontology [START_REF] Suri | Semantic Framework for Internet of Things-Aware Business Process Development[END_REF], which bridges IoT concepts with Business Process concepts. Moreover, it is necessary to take into consideration also an ontology to describe each subdomain of PA (Sub-Domain Ontology) to manage the semantic issues related to the domain knowledge. For this reason, the collaboration between domain experts and technical experts is fundamental, since the former can guide the latter in defining the most appropriate meaning for a concept which could also be found in multiple business processes.  User Application Ontology: the applications have to adopt a vocabulary comprehensible to its different users, so that they can benefit from the knowledge produced by business process execution. This could be represented in different ways according to the different users who interact with the application, due to their different interests and skills. In fact, some information on the underlying devices or processes may not be of interest or understandable by certain users due, for example, to very specific domain concepts. Thus, according to [START_REF] Shahzad | Ontology-based User Interface Development: User Experience Elements Pattern[END_REF], the design of the user application interfaces has to be based on specific ontologies (End User Interface Ontology) describing the most suitable graphical constructs for the specific user and on the vocabulary used in the domain (Sub Domain Ontology). For example, information on CO 2 and Pm 10 will inform the Environment Department employee about air pollution trend over time. The same information will be represented as an index of traffic congestion over time for the Mobility Department employee. Instead, a citizen, to correctly interpret the same information, needs a suitable representation, as a geochart1 (e.g, a map reporting colored circles according to the calculated values), a simple explanation (e.g., "high-medium-low pollution level") or a push notification service for his/her mobile device (e.g., by a Telegram channel).

The semantic approach also permits to infer knowledge not explicitly defined in the model through a semantic reasoner, thus allowing Technical Experts to develop new services and applications. The schema in Fig. 5 applies the KMS model to the considered case study. In the Transportation domain, the procedures of BP 1 , on the basis of the number of vehicles passing through the point A in a time interval as detected by the sensor S 1 , compute the road congestion level. The output knowledge is related to the concepts "Road" and "Traffic". The User application A 1 "Vehicle flow monitoring" provides different views using user interface elements suitable to specific users, i.e., v 1 for Mobility Department employee and v 2 for citizens. In the Environment domain, the procedures of BP 2 compute the level of CO 2 and PM 10 thanks to the data returned by the sensors S 2 and S n located in the point A. The output knowledge is related to the concepts "Air Quality" and it is provided to users by the A 2 "Air quality monitoring", which shows a pollution level graph to the Environment Department employee (v 1 ) and a geochart to citizens (v 2 ), who can be possibly warned by an alarm notification service. The knowledge generated by BP 1 (concepts "Traffic" and "Road") and BP 2 ("Air Quality") permits to infer new knowledge about "Infrastructure" useful in the Urban Planning domain. In BP 4 "Territorial Planning", a procedure computes the less polluted areas and also allows users to infer the best place for building a school. A User application could represent this knowledge in a GIS platform or in a Decision Support System (DSS) for the Urban Planning Department.

Discussion and Conclusion

In this paper, we presented a three-layer model for organizing the elements of knowledge of an IoT application in complex heterogeneous contexts, such as Smart City. In such contexts, traditional business processes have been transformed, due to the need of integrating real world data through IoT and of considering a multitude of users, each of them having specific goals. Technical experts must take into account each layer and the relations between them, in order to solve both technological and semantic issues when developing an IoT application. In our model we propose a semantic approach based on a subset of ontologies that describe each layer of the KSM and the relations between them, in order to represent different contexts and different user interactions. We recognize that, at the current stage of our research, the proposed model has some limitations. In particular, we have to investigate some issues related to: security and reliability of the collected data (with regard to connection, network reliability, prevention of attacks and security of the transmitted data); compliance with privacy legislation (as EU Regulation 2016/679 GDPR-General Data Protection Regulation); processing of personal data and their representation. As future work, we are going to adopt the Web Ontology Language (OWL) and Description Logic (DL) languages to enrich the description of the model, in order to facilitate the reasoning about the concepts of the different application domains. Moreover, we are extending the Resource layer by including the typical resources of the Internet of Everything that, by including user-generated communications (such as citizen's smartphones, wearable devices, etc.) and interactions with networked devices, introduces further technological and semantic issues, for example new business processes must be defined to filter the collected data, to protocol citizens' alerts and include them in the administrative management. Our research group is already working on this topic, since the need of augmenting smart devices with semantic attributes emerged in our studies for proposing visual interaction paradigms to allow end users to define smart visit experience in the Cultural Heritage domain [START_REF] Ardito | From smart objects to smart experiences: An end-user development approach[END_REF].

Fig. 1 .

 1 Fig. 1. The Knowledge Stratification Model (KSM).

Fig. 2 .

 2 Fig. 2. Ackoff's DIKW Architecture.

Fig. 3 .

 3 Fig. 3. A EER schema modelling the KSM.

Fig. 4 .

 4 Fig. 4. Ontologies underlying the KSM model.

Fig. 5 .

 5 Fig. 5. Applying the KMS to the considered case study.

https://developers.google.com/chart/interactive/docs/gallery/geochart

Acknowledgments

. This work is funded by Italian Ministry of Education, University and Research (MIUR) through PON Ricerca e Innovazione 2014-2020 -Asse I "Investimenti in capitale umano" -Azione I.1 "Dottorati Innovativi con caratterizzazione industriale" (CUP H92H18000210006 and H92H18000200006 approved with D.R.n.991 on 29/03/2018 of University of Bari Aldo Moro).