In the era of 6G, developing and managing software requires cutting-edge software engineering (SE) theories and practices tailored for such complexity across a vast number of connected edge devices. Our project aims to lead the development of sustainable methods and energy-efficient orchestration models specifically for edge environments, enhancing architectural support driven by AI for contemporary edge-to-cloud continuum computing. This initiative seeks to position Finland at the forefront of the 6G landscape, focusing on sophisticated edge orchestration and robust software architectures to optimize the performance and scalability of edge networks. Collaborating with leading Finnish universities and companies, the project emphasizes deep industry-academia collaboration and international expertise to address critical challenges in edge orchestration and software architecture, aiming to drive significant advancements in software productivity and market impact.

Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). The minimal documentation emphasis may be beneficial in reducing time-to-market for software. However, it can also be a concern, especially with QRs, since they are challenging to specify and document and are crucial for software success. Therefore, understanding how practitioners perceive the importance of QR documentation is valuable because it can provide insight into how they approach this task. It also helps in developing models and guidelines that support the documentation of QRs in ASD, which is a research gap. We aim to understand practitioners’ perceptions of QR documentation and factors influencing this task to derive a model that supports optimal QR documentation in ASD. We conducted a multiple case study involving 12 participants from three cases that apply ASD. Practitioners identify QR documentation as important and perceive it as contributing to ensuring quality, clarifying QRs, and facilitating decision-making. Time constraints, QR awareness, and communication gaps affect QR documentation. Missing and outdated QR documentation may lead to technical debt and a lack of common understanding regarding QRs. We introduce a model to support optimal QR documentation in ASD by focusing on the factors: time constraints, QR awareness, and communication gaps. The model provides a representation and explanation of the factors affecting QR documentation in ASD and identifies mitigation strategies to overcome issues that may occur due to these factors. The study reveals the importance of documenting QRs in ASD. It introduces a model that is based on empirical knowledge of QR documentation practices in ASD. Both practitioners and researchers can potentially benefit from the model. For instance, practitioners can analyze how time constraints or QR awareness affect documentation, see potential issues that may arise from them, and utilize strategies suggested by the model to address these issues. Researchers can learn about QR documentation in ASD and utilize the model to understand the topic. They can also use the study as a baseline to investigate the topic with other cases.

In despite of agile and rapid software development (ARSD) being researched and applied extensively, managing quality requirements (QRs) are still challenging. As ARSD processes produce a large amount of data, measurement has become a strategy to facilitate QR management. This study aims to survey the literature related to QR management through metrics in ARSD, focusing on: bibliometrics, QR metrics, and quality-related indicators used in quality management. The study design includes the definition of research questions, selection criteria, and snowballing as search strategy. We selected 61 primary studies (2001–2019). Despite a large body of knowledge and standards, there is no consensus regarding QR measurement. Terminology is varying as are the measuring models. However, seemingly different measurement models do contain similarities. The industrial relevance of the primary studies shows that practitioners have a need to improve quality measurement. Our collection of measures and data sources can serve as a starting point for practitioners to include quality measurement into their decision-making processes. Researchers could benefit from the identified similarities to start building a common framework for quality measurement. In addition, this could help researchers identify what quality aspects need more focus, e.g., security and usability that have surprisingly few metrics reported.

Abstract Agile methods can deliver software that fulfills customer needs rapidly and continuously. Quality requirements (QRs) are important in this regard; however, detailed studies on how companies applying agile methods to manage QRs are limited, as are studies on the rationale for choosing specific QR management practices and related challenges. The aim of this study was to address why practitioners manage QRs as they do and what challenges they face. We also analyzed how existing practices mitigate some of the found challenges. Lastly, we connect the contextual elements of the companies with their practices and challenges. We conducted 36 interviews with practitioners from four companies of varying sizes. Since each company operates in different domains, comparing QR management strategies and related challenges in different contexts was possible. We found that the companies apply proactive, reactive, and interactive strategies to manage QRs. Additionally, our study revealed 40 challenges in six categories that companies applying agile methods may face in QR management. We also identified nine contextual elements that affect QR management practice choices and which, importantly, can explain many related challenges. Based on these findings, we constructed a theoretical model about the connection between context, QR management practices, and challenges. Practitioners in similar contexts can learn from the practices identified in this study. Our preliminary theoretical model can help other practitioners identify what challenges they can expect to face in QR management in different developmental contexts as well as which practices to apply to mitigate these challenges.

Software development involves many activities, and decision making is an essential one. Various factors can impact a decision-making process, and by understanding such factors, one can improve the process. Since people are the ones making decisions, some human-related aspects are amongst those influencing factors. One such aspect is the decision maker’s personality. This research investigates the relationship between decision-making style and personality within the context of software project development. We conducted a survey in a population of Brazilian software engineers to gather data on their personality and decision-making style. Data from 63 participants was gathered and resulted in the identification of seven statistically significant correlations between decision-making style and personality (personality factor and personality facets). Furthermore, we built a regression model in which decision-making style (DMS) was the response variable and personality factors the independent variables. The backward elimination procedure selected only agreeableness to explain 4.2% of DMS variation. The model accuracy was evaluated and deemed good enough. Regarding the moderation effect of demographic variables (age, educational level, experience, and role) on the relationship between DMS and Agreeableness, the analysis showed that only software engineers’ role has such effect. This paper contributes toward understanding the relationship between DMS and personality. Results show that the personality variable agreeableness can explain the variation in decision-making style. Furthermore, someone’s role in a software development project can impact the strength of the relationship between DMS and agreeableness.

Context: Researchers from different groups and institutions are collaborating on building groups of experiments by means of replication (i.e., conducting groups of replications). Disparate aggregation techniques are being applied to analyze groups of replications. The application of unsuitable techniques to aggregate replication results may undermine the potential of groups of replications to provide in-depth insights from experiment results. Objectives: Provide an analysis procedure with a set of embedded guidelines to aggregate software engineering (SE) replication results. Method: We compare the characteristics of groups of replications for SE and other mature experimental disciplines such as medicine and pharmacology. In view of their differences, the limitations with regard to the joint data analysis of groups of SE replications and the guidelines provided in mature experimental disciplines to analyze groups of replications, we build an analysis procedure with a set of embedded guidelines specifically tailored to the analysis of groups of SE replications. We apply the proposed analysis procedure to a representative group of SE replications to illustrate its use. Results: All the information contained within the raw data should be leveraged during the aggregation of replication results. The analysis procedure that we propose encourages the use of stratified individual participant data and aggregated data in tandem to analyze groups of SE replications. Conclusion: The aggregation techniques used to analyze groups of replications should be justified in research articles. This will increase the reliability and transparency of joint results. The proposed guidelines should ease this endeavor.

Context: Quality requirements (QRs) have a significant role in the success of software projects. In agile software development (ASD), where working software is valued over comprehensive documentation, QRs are often under-specified or not documented. Consequently, they may be handled improperly and result in degraded software quality and increased maintenance costs. Investigating the documentation of QRs in ASD, would provide evidence on existing practices, tools and aspects considered in ASD that other practitioners might utilize to improve documentation and management of QRs in ASD. Although there are some studies examining documentation in ASD, those that specifically investigate the documentation of QRs in depth are lacking.

Background: Practitioners would like to take action based on software metrics, as long as they find them reliable. Existing literature explores how metrics can be made reliable, but remains unclear if there are other conditions necessary for a metric to be actionable. Context & Method: In the context of a European H2020 Project, we conducted a multiple case study to study metrics' use in four companies, and identified instances where these metrics influenced actions. We used an online questionnaire to enquire about the project participants' views on actionable metrics. Next, we invited one participant from each company to elaborate on the identified metrics' use for taking actions and the questionnaire responses (N=17). Result: We learned that a metric that is practical, contextual, and exhibits high data quality characteristics is actionable. Even a non-actionable metric can be useful, but an actionable metric mostly requires interpretation. However, the more these metrics are simple and reflect the software development context accurately, the less interpretation required to infer actionable information from the metric. Company size and project characteristics can also influence the type of metric that can be actionable. Conclusion: This exploration of industry's views on actionable metrics help characterize actionable metrics in practical terms. This awareness of what characteristics constitute an actionable metric can facilitate their definition and development right from the start of a software metrics program.

Agile software development (ASD) promotes minimal documentation and often prioritizes functional requirements over quality requirements (QRs). This may be beneficial in reducing the time to market of software. When considering QRs in ASD, the minimal documentation practice may be seen as a concern since QRs determine the success of software projects and are as well not easy to specify and document. Nevertheless, what do practitioners think of the necessity of documenting QRs in ASD? How do they perceive factors that may affect documentation of QRs in ASD? We conducted a multiple case study of three cases applying ASD, involving 12 participants. ASD practitioners identify that it is important to document QRs, and perceive that it contributes to ensuring quality, clarifying QRs, and helping in decision making. Time constraint, QR awareness and communication gaps on QRs influence the documentation of QRs in ASD. ASD teams may align their documentation practices to fit the sprint duration. The influence of QR awareness on documentation was dependent on project context and roles. Communication gaps can create confusion on QRs. Missing and outdated QR documentation may result in accruing technical debt, and lack of common understanding on QRs. The study synthesizes empirical evidence on the significance of documenting QRs in ASD and provides an insight into factors affecting documentation of QRs in ASD.

Abstract Software engineering (SE) research should be relevant to industrial practice. There have been regular discussions in the SE community on this issue since the 1980’s, led by pioneers such as Robert Glass. As we recently passed the milestone of “50 years of software engineering”, some recent positive efforts have been made in this direction, e.g., establishing “industrial” tracks in several SE conferences. However, many researchers and practitioners believe that we, as a community, are still struggling with research relevance and utility. The goal of this paper is to synthesize the evidence and experience-based opinions shared on this topic so far in the SE community, and to encourage the community to further reflect and act on the research relevance. For this purpose, we have conducted a Multi-vocal Literature Review (MLR) of 54 systematically-selected sources (papers and non peer-reviewed articles). Instead of relying on and considering the individual opinions on research relevance, mentioned in each of the sources, the MLR aims to synthesize and provide the “holistic” view on the topic. The highlights of our MLR findings are as follows. The top three root causes of low relevance, discussed in the community, are: (1) Researchers having simplistic views (or wrong assumptions) about SE in practice; (2) Lack of connection with industry; and (3) Wrong identification of research problems. The top three suggestions for improving research relevance are: (1) Using appropriate research approaches such as action-research; (2) Choosing relevant (practical) research problems; and (3) Collaborating with industry. By synthesizing all the discussions on this important topic so far, this paper aims to encourage further discussions and actions in the community to increase our collective efforts to improve the research relevance. Furthermore, we raise the need for empirically-grounded and rigorous studies on the relevance problem in SE research, as carried out in other fields such as management science.

Technological development and increasing personal data collection and utilization raise the importance of understanding individuals’ privacy behavior. Privacy behavior denotes the willingness to disclose personal data for services utilizing these data. The literature presents various privacy behavior models (PBMs). However, the research is incoherent, with inconsistencies among models. Therefore, the application and subsequent development of PBMs are challenging. Different background theories are used for model construction, and studies have been conducted in distinct application domains. We studied whether the models’ inconsistencies could be explained by these differences. Our in-depth analysis of PBMs was based on a systematic literature review of the most often cited key studies. Our findings indicate that the choice of theories and the application domains do not explain inconsistencies; instead, the models are often of an ad hoc type and constructed in an eclectic way. These results imply the need for more consistent research on privacy behavior.

Existing literature proposes success factors for establishing metrics programs. However, very few studies focus on factors that could ensure long-term use of metrics, and even fewer studies investigate such factors in the context of Agile Software Development (ASD). Motivated by this knowledge gap, we aim to identify success factors for operationalizing metrics in ASD, particularly, factors that could help in the long-term use of metrics. We conducted a multiple case study, where we operationalized process metrics at two software-intensive companies using ASD. We learned that data availability and development process are the two fundamental success factors for process metrics operationalization, albeit less prominent in literature. Companies prefer iterative and incremental operationalization of stable and functional process metrics, which is analogous to the agile way of working. Metrics trustworthiness plays a key role in successful operationalization of process metrics, and is potentially vital to ensuring their long-term use. By comparing the identified success factors with the existing literature, we conclude that success factors concerning data availability, development process, and metrics trustworthiness warrant greater attention, especially to maximize the chances of long-term use of process metrics.

Abstract Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process.

Requirements Engineering (RE) has established itself as a software engineering discipline over the past decades. While researchers have been investigating the RE discipline with a plethora of empirical studies, attempts to systematically derive an empirical theory in context of the RE discipline have just recently been started. However, such a theory is needed if we are to define and motivate guidance in performing high quality RE research and practice. We aim at providing an empirical and externally valid foundation for a theory of RE practice, which helps software engineers establish effective and efficient RE processes in a problem-driven manner. We designed a survey instrument and an engineer-focused theory that was first piloted in Germany and, after making substantial modifications, has now been replicated in 10 countries worldwide. We have a theory in the form of a set of propositions inferred from our experiences and available studies, as well as the results from our pilot study in Germany. We evaluate the propositions with bootstrapped confidence intervals and derive potential explanations for the propositions. In this article, we report on the design of the family of surveys, its underlying theory, and the full results obtained from the replication studies conducted in 10 countries with participants from 228 organisations. Our results represent a substantial step forward towards developing an empirical theory of RE practice. The results reveal, for example, that there are no strong differences between organisations in different countries and regions, that interviews, facilitated meetings and prototyping are the most used elicitation techniques, that requirements are often documented textually, that traces between requirements and code or design documents are common, that requirements specifications themselves are rarely changed and that requirements engineering (process) improvement endeavours are mostly internally driven. Our study establishes a theory that can be used as starting point for many further studies for more detailed investigations. Practitioners can use the results as theory-supported guidance on selecting suitable RE methods and techniques.

Test-Driven Development (TDD), an agile development approach that enforces the construction of software systems by means of successive micro-iterative testing coding cycles, has been widely claimed to increase external software quality. In view of this, some managers at Paf-a Nordic gaming entertainment company-were interested in knowing how would TDD perform at their premises. Eventually, if TDD outperformed their traditional way of coding (i.e., YW, short for Your Way), it would be possible to switch to TDD considering the empirical evidence achieved at the company level. We conduct an experiment at Paf to evaluate the performance of TDD, YW and the reverse approach of TDD (i.e., ITL, short for Iterative-Test Last) on external quality. TDD outperforms YW and ITL at Paf. Despite the encouraging results, we cannot recommend Paf to immediately adopt TDD as the difference in performance between YW and TDD is small. However, as TDD looks promising at Paf, we suggest to move some developers to TDD and to run a future experiment to compare the performance of TDD and YW. TDD slightly outperforms ITL in controlled experiments for TDD novices. However, more industrial experiments are still needed to evaluate the performance of TDD in real-life contexts.

Communication plays an important role in Agile Software Development (ASD).In each ASD practice (e.g., standup or retrospective meetings), different communication practices and channels are adopted by different companies.Several works have analyzed the impact of communication channels and practices.However, there are no secondary studies summarizing their impact on ASD.This study presents a Systematic Mapping Study (SMS) that aggregates, summarizes, and discusses the results of 25 relevant primary studies concerning the impact of communication channels and practices in ASD.We followed the well-known systematic mapping methodology in software engineering and analyzed empirical studies published before the end of June 2018.The results of our study have yielded several strategies that can be adopted by practitioners.Communication practices are context dependent.In the case of a distributed team, blended usage of rich-media communication tools, such as shared mind-map tools, videoconferencing, and promoting the exchange of team members between teams, is beneficial.In conclusion, communication can be expensive if teams do not apply the right strategies.Future research direction is to understand how to maximize product quality while reducing communication cost and how to identify the most beneficial communication strategy for the different stages of ASD.

This extended abstract summarizes an article, which has been published in the Empirical Software Engineering Journal and was selected for the Journal-First presentations at the International Conference on Software and System Process (ICSSP 2018).

[Context]: To remain competitive, innovative and to grow, companies should use a value-based decision-making where decisions are the best for that company's overall value creation. However, without tool support, the use of explicit value propositions and aggregation of different key stakeholders' decisions during decision-making may be a challenge for many companies. [Goal]: The goal of this paper is to investigate the extent to which a Web-based tool for value-based decision-making can successfully support stakeholders' decision-making process. [Method]: We conducted three case studies across four software projects, during six weeks, in the contexts of feature selection, test cases execution prioritization and user interfaces design selection. Prior to using the tool, stakeholders' value propositions were elicited via focus-group meetings; later, during a post-mortem phase, data was gathered via observation, semi-structured interviews and structured questionnaires. [Results]: Participants reported an improvement of their decision-making process and quality of decisions; further, they also felt confident about using the tool, and that it can be useful to their work. [Conclusions]: Results suggested that the use of tool support by the stakeholders in the investigated company for value-based decision-making improved their decision-making process and the quality of decisions.

Context: The alignment of different software engineering activities for coordinated functioning and optimized product development is of great importance, particularly in industrial-scale development. The link between intermediate activities has been researched extensively, but the link between requirements engineering (RE) and software testing (ST) is a relatively less explored area.

[Context and motivation] Due to lack of resources and teams with low levels of experience, startups face several challenges during their product development, such as product customization, attracting new customers, and mastering the technology uncertainty. To increase their market presence and compensate for their lack of resources, startups need to consider other options such as joint ventures and partnerships. [Question/problem] Some companies that share highly similar resources and businesses can be potential competitors with one another. The effect of interaction with such potential competitors with respect to startups to obtain expertise has not been often reported in the literature to date. [Principal ideas/results] In this study, we simulated two software startups in a controlled experiment to evaluate the effect of interaction with a potential competitor in the effort estimation process. A real startup case was also involved in analyzing the effect. The results of the study show that there is a statistically significant difference in the effectiveness when co-operating with a competitor in the process. Experiment participants also considered the interaction with the potential competitor useful based on the exchange of important information and ideas regarding the product domain. [Contribution] This paper contributes by demonstrating the effect of interaction with a potential competitor in the effort estimation process. In addition, our study encourages further research on startups working in with the competitors in other software engineering knowledge areas.

Requirements volatility is a major issue in software (SW) development, causing problems such as project delays and cost overruns. Even though there is a considerable amount of research related to requirement volatility, the majority of it is inclined toward project management aspects. The relationship between SW architecture design and requirements volatility has not been researched widely, even though changing requirements may for example lead to higher defect density during testing. An exploratory case study was conducted to study how requirements volatility affects SW architecture design. Fifteen semi-structured, thematic interviews were conducted in the case company, which provides the selection of software products for business customers and consumers. The research revealed the factors, such as requirements uncertainty and dynamic business environment, causing requirements volatility in the case company. The study identified the challenges that requirements volatility posed to SW architecture design, including scheduling and architectural technical debt. In addition, this study discusses means of mitigating the factors that cause requirements volatility and addressing the challenges posed by requirements volatility. SW architects are strongly influenced by requirement volatility. Thus understanding the factors causing requirements volatility as well as means to mitigate the challenges has high industrial relevance.

This paper addresses the design problem of providing cognitive support for workflow systems in software development. Software development is demanding knowledge work that requires creativity and adaptability to changing requirements and situations. This type of work involves cognitive actions that require substantial support in several forms in order to address needs such as collaboration, communication, knowledge management, awareness and transparency, and the coordination and structuring of the development processes. The literature and our empirical results show that there is a lack of cognitive support in current workflow models. Hence, we identify the need for a design theory for cognitive workflow systems (CWS). In this paper, such a theory is presented. The proposed design theory for CWS is validated through an action research intervention. This design theory has important implications from both research and practical perspectives. The results will help developers in their daily work, enhance the efficiency of the development processes, and facilitate decision-making activities.

Abstract Traditional portfolio management tools and methods are challenging for software companies that use agile and lean approaches, because of the complex pre‐planning activities required. In this paper, traditional portfolio management tools and methods that have been conventionally used in industry and presented in literature are reviewed. Findings concerning their use in agile and lean software companies are investigated, on the basis of the literature review and semi‐structured interviews conducted in 7 agile and lean software companies in Finland. The findings indicate that the studied companies do not use traditional portfolio management tools and methods in their entirety. The software companies adapted suitable components from traditional portfolio management tools and methods into their practices. They also apply new tools and methods to manage their portfolios of offerings, to cope with the dynamics required by agile and lean methods. The companies' emphasis is on using tools to facilitate immediate feedback from customers, to assess the value of offerings in their portfolio. The results showed a growing interest in using Kanban at the portfolio level to provide a visual overview of offerings.

Background: Test-driven development (TDD) is a technique that repeats short coding cycles interleaved with testing. The developer first writes a unit test for the desired functionality, followed by the necessary production code, and refactors the code. Many empirical studies neglect unique process characteristics related to TDD iterative nature. Aim: We formulate four process characteristic: sequencing, granularity, uniformity, and refactoring effort. We investigate how these characteristics impact quality and productivity in TDD and related variations. Method: We analyzed 82 data points collected from 39 professionals, each capturing the process used while performing a specific development task. We built regression models to assess the impact of process characteristics on quality and productivity. Quality was measured by functional correctness. Result: Quality and productivity improvements were primarily positively associated with the granularity and uniformity. Sequencing, the order in which test and production code are written, had no important influence. Refactoring effort was negatively associated with both outcomes. We explain the unexpected negative correlation with quality by possible prevalence of mixed refactoring. Conclusion: The claimed benefits of TDD may not be due to its distinctive test-first dynamic, but rather due to the fact that TDD-like processes encourage fine-grained, steady steps that improve focus and flow.

Context: Test-driven development (TDD) is an agile practice claimed to improve the quality of a software product, as well as the productivity of its developers. A previous study (i.e., baseline experiment) at the University of Oulu (Finland) compared TDD to a test-last development (TLD) approach through a randomized controlled trial. The results failed to support the claims. Goal: We want to validate the original study results by replicating it at the University of Basilicata (Italy), using a different design. Method: We replicated the baseline experiment, using a crossover design, with 21 graduate students. We kept the settings and context as close as possible to the baseline experiment. In order to limit researchers bias, we involved two other sites (UPM, Spain, and Brunel, UK) to conduct blind analysis of the data. Results: The Kruskal-Wallis tests did not show any significant difference between TDD and TLD in terms of testing effort (p-value = .27), external code quality (p-value = .82), and developers' productivity (p-value = .83). Nevertheless, our data revealed a difference based on the order in which TDD and TLD were applied, though no carry over effect. Conclusions: We verify the baseline study results, yet our results raises concerns regarding the selection of experimental objects, particularly with respect to their interaction with the order in which of treatments are applied.

Coordination in software projects is a challenge, particularly when it comes to distributed software development (DSD). Agile software development is a well-known paradigm for improving software development; however, there is little understanding of its impact on DSD projects. This paper describes an empirical study conducted within two Software Factory settings in Finland and Italy to investigate how Scrumban can impact coordination in geographically distributed software development. It provides the results from a project case that applied Scrumban to develop a web-based application for Time-banking. This study shows that aspects of Scrumban, such as iterative development, enhanced visibility, and limited work-in-progress, would alleviate the challenges of leveraging resources, synchronization between distributed sites, communication, and culture. It also explains that technical and security issues in the coordination of distributed projects may demand for solutions other than Scrumban.

Software companies that develop embedded systems following the principles of service-oriented architecture can anticipate various benefits from choreography modelling. Current choreography modelling languages, however, have a limited applicability in embedded systems development since they are not expressive enough to capture all the choreography-relevant aspects that are typical in this domain. We tackled this problem by analysing the needs of embedded systems for choreography modelling language. Our analysis was guided by design science and relied on expert interviews, company-specific documents and the relevant literature. The main results of the analysis presented in this paper are a) design requirements addressing the limitations of choreography modelling languages for embedded systems development and b) proposals for modelling language implementation technologies. The feasibility of these results is evaluated by redesigning an existing choreography modelling language and by implementing a prototype editor for the redesigned language.

In the last decade, Kanban has been promoted as a means for bringing visibility to work while improving the software development flow, team communication and collaboration. However, little empirical evidence exists regarding Kanban use in the software industry. This paper aims to investigate the factors that users perceive to be important for Kanban use. We conducted a survey in 2015 among Kanban practitioners in the LeanKanban LinkedIn community. The survey results consist of 146 responses from 27 different organisations, with all respondents being experienced in using Kanban. The results show that practitioners perceived Kanban as easy to learn and useful in individual and team work. They also consider organisational support and social influence to be important determinants for Kanban use. Respondents noted various perceived benefits for using Kanban, such as bringing visibility to work, helping to reduce work in progress, improving development flow, increasing team communication and facilitating coordination. Despite the benefits, participants also identified challenges to using Kanban, such as organisational support and culture, difficulties in Kanban implementation, lack of training and misunderstanding of key concepts. The paper summarises the results and includes a discussion of implications for effective deployment of Kanban before describing future research needs.

In the last two decades, Agile and Lean approaches have gained wide acceptance in the software industry. In this realm, Kanban emerged in 2004 with a strong practitioner-driven support movement and today, Kanban is increasingly adopted to complement Scrum and other Agile methods. Kanban tends to focus on fast production, rapid and continual user feedback and interaction. These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Background: In previous studies, a model was proposed that investigated how the developers' unit testing effort impacted their productivity as well as the external quality of the software they developed.

Software productivity and effort estimationEvery software business has to be able to budget and plan its software development projects realistically.This is the prerequisite for professional project management, for competitive offers, and for a more objective assessment of the offers made by potential contractors.In order to achieve these objectives, a software business must be capable of estimating their own productivity in developing software at an appropriate level of quality and produce accurate estimates for the effort required to develop software.Since 1999, the International Conference on Product-Focused Software Process Improvement (PROFES) has established itself as one of the most recognized international conferences on professional software process improvement (SPI) motivated by product, process, and service quality needs.PROFES addresses both quality engineering and management topics, including processes, methods, techniques, tools, organizations, and enabling SPI.Both solutions found in practice and relevant research results from academia are presented.The 14 th instance of the conference -PROFES 2013was held in Paphos, Cyprus, from 12 June to 14 June 2013.The technical program was selected by a committee of leading experts in SPI, software process modeling, and empirical software engineering research.Overall, 41 papers were submitted, with each paper getting reviewed by at least three reviewers.After thorough evaluation, the Program Committee finally selected 22 technical full papers.The topics addressed in these papers indicate that SPI is a vibrant research discipline and is also of high interest for industry.Many papers report on case studies or SPI-related experience gained in industry.The technical program consisted of the following tracks: decision support in software engineering, empirical software engineering, managing software processes, safety-critical software engineering, software measurement, SPI, and software maintenance.We would like to thank all authors, presenters, and session chairs for their time and effort in making PROFES 2013 a success.Our special thanks go to our keynote speakers for highlighting the most recent findings and novel results in the area of process improvement.We were proud to have three keynote speakers: Stefan Wagner (University of Stuttgart, Germany) on 'Making Software Quality Visible', Alexis Ocampo (ECOPETROL S.A., Colombia) on 'ECO-MAPS: Information Quality Driven Enterprise Modeling', and Christos Xenis (LogiSoft, Cyprus) on the 'Implementation of an Online Multi-Level and Device-Independent Time & Attendance System'.Furthermore, we also would like to thank the organizers of the co-located tutorial sessions: Hermann Kaindl (Vienna University of Technology, Austria) on 'Model-based Transition from Requirements to High-level Software Design' and Jens Heidrich (Fraunhofer IESE, Germany) on 'Software Effort Estimation and Risk Management'.In addition, we sincerely thank all Program Committee members and reviewers who provided excellent support in reviewing the papers, Andreas Jedlitschka (Fraunhofer IESE, Germany) for his work as General Chair, and George Angelos Papadopoulos (

Context: Successfully addressing stakeholder concerns that are related to software system development and operation is crucial to achieving development goals. The importance of using a systematic approach to addressing these concerns throughout the software development life cycle is growing as more and more systems are employed to handle critical tasks. Objective: The goal of this study is to provide an overview of addressing concerns across the software development life cycle. Method: A systematic mapping study was conducted using a pre-defined protocol. Four digital databases were searched for research literature and primary studies were selected after a three round selection process conducted by multiple researchers. Results: The extracted data are processed and the results are reported from different viewpoints. The results are also analyzed against our research goals. Conclusion: We show that there is a considerable variation in the use of terminologies and addressing concerns in different phases of the software development life cycle.

Test-driven development (TDD) is an iterative software development technique where unit-tests are defined before production code. The proponents of TDD claim that it improves both external quality and developers' productivity. In particular, Erdogmus et al. (i.e., original study) proposed a two-stage model to investigate these claims regarding TDD's effects. Our aim is to enhance the model proposed in the original study by investigating an additional factor: TDD process conformance. We conducted a close, external replication of the original study accompanied by a correlation analysis to check whether process conformance is related to improvements for the subjects using TDD. We partially confirmed the results of the original study. Moreover, we observed a correlation between process conformance and quality, but not productivity. We found no evidence to support the claim that external quality and productivity are improved by the adoption of TDD compared to test-last development. Finally, conformance to TDD process improves the quality and does not affect productivity. We conclude that the role of process conformance is relevant in studying the quality and productivity-related effects of TDD.

Context: One limitation of the empirical studies about test-driven development (TDD) is knowing whether the developers followed the advocated test-code-refactor cycle. Research dealt with the issue of process conformance only in terms of internal validity, while investigating the role of other confounding variables that might explain the controversial effects of TDD. None of the research included process conformance as a fundamental part of the analysis.

Previous studies suggest that motivation is a critical factor in developer productivity and project outcome, i.e., software project failures are significantly associated with low motivation of software teams. Surveys with software engineers also indicate that culture can affect software development team motivation through differences in developers' motivational factors. In this study, we conduct a survey with 15 Finnish software engineers and 21 non-Finnish software engineers who live in Finland to investigate 1) the relationship between team motivation and project outcome, and 2) the factors that motivate Finnish software engineers. We compare the motivational factors found from the Finnish data with those identified in prior research with developers from four different countries. An analysis of the data from our 36 subjects indicates that project outcome is not associated with team motivation in Finland though this result contradicts prior research. There is a single motivational factor, “team work” that appears to be culturally independent. Unique team motivational factors for Finnish software engineers are found to be “the authority of project manager” and “the vision of project manager”. Our results indicate that cultural differences affect team motivation and that project managers need to consider these when working in a global environment.

The potential shown by Lean in different domains has aroused interest in the software industry. However, it remains unclear how Lean can be effectively applied in a domain such as software development that is fundamentally different from manufacturing. This study explores how Lean principles are implemented in software development companies and the challenges that arise when applying Lean Software Development. For that, a case study was conducted at Ericsson R&D Finland, which successfully adopted Scrum in 2009 and subsequently started a comprehensible transition to Lean in 2010. Focus groups were conducted with company representatives to help devise a questionnaire supporting the creation of a Lean mindset in the company (Team Amplifier). Afterwards, the questionnaire was used in 16 teams based in Finland, Hungary and China to evaluate the status of the transformation. By using Lean thinking, Ericsson R&D Finland has made important improvements to the quality of its products, customer satisfaction and transparency within the organization. Moreover, build times have been reduced over ten times and the number of commits per day has increased roughly five times.The study makes two main contributions to research. First, the main factors that have enabled Ericsson R&D’s achievements are analysed. Elements such as ‘network of product owners’, ‘continuous integration’, ‘work in progress limits’ and ‘communities of practice’ have been identified as being of fundamental importance. Second, three categories of challenges in using Lean Software Development were identified: ‘achieving flow’, ‘transparency’ and ‘creating a learning culture’.

Earlier empirical studies have demonstrated the interest that agile methods have generated in the software industry. Currently, lean approaches are increasingly adopted for complementing agile methods in software processes. With the goal of providing up-to-day results that can be used by organizations implementing or planning to implement agile and/or lean methods, we have conducted a study on the current stage of agile and lean adoption and usage in the software industry. For this purpose, we conducted an extensive survey among Finnish software practitioners in 2011, using the membership registry of The Finnish Information Processing Association (FIPA) as a sampling frame. 408 responses were collected from 200 software intensive organizations in the study. The survey included questions for identifying the rate of agile and lean usage in software organizations as well as the implementation of specific methods and practices, goals in adopting agile and lean, reasons for not applying these methods and effects of the agile and lean usage. The results of the survey reveal that a majority of respondents' organizational units are using agile and/or lean methods (58%). Furthermore, lean appears as a new player, being used by 24% of respondents, mainly in combination with agile (21%). The reasons and benefits for using agile and lean methods appeared to correspond in most parts to the findings of the earlier research. Generally, the experiences of using agile and lean methods seem to be rather positive, although challenges, such as obtaining management support and limitations for scaling agile in distributed settings, were also identified.

Business value analysis (BVA) quantifies the factors that provide value and cost to an organization. It aims at capturing value, controlling risks, and capitalizing on opportunities. GQM+Strategies is an approach designed to aid in the definition and alignment of business goals, strategies, and an integrated measurement program at all levels in the organization. In this paper we describe how to perform business value analysis (BVA) using the GQM+Strategies approach. The integration of these two approaches provides a coupling of cost-benefit and risk analysis (value goals) with operationally measurable business goals and supports the evaluation of business goal success and the effectiveness of the chosen strategies. An application of the combined approach is provided to illustrate the feasibility of the proposed method. It deals with the business goal of modernizing the product for the evolving market.

This paper presents the foundations for building mobile environmental information systems (MEISs) requiring an interdisciplinary approach. MEISs require expertise from the disciplines of environmental biology, geography, and mobile technology. MEISs show great promise for the acquisition of environmental information using different mobile devices. Automatic mobile acquisition enables the forwarding of the information to central databases for storage, further processing, and transmission to the mobile devices in a form that is useful to the users. Furthermore, these systems have the potential to be used both in the protection of nature, as well as in recreational use in a way that takes the constraints of nature into account. In this paper we describe the preliminary results of the MINNE project and the prototypes currently under research in the project.

IN the recent years, the wireless Internet has become reality. Access is wireless via personal (such as Bluetooth), local (Wi-Fi), or global (cellular) networks. A variety of mobile terminals can be used, PC-like (PDAs, laptops, tablet PCs), or phone-like (smart phones, mobile phones). Several applications are being and will be developed, either to adapt existing ones to the new infrastructure, or to support mobile services, such as travel information, roadside assistance, etc. This scenario raises new engineering challenges, both at the connectivity and at the application level. This special issue deals with the latter, and stems from work done by the guest editors in the domain. The key question is: What is the impact of the wireless Internet on building applications—or what is specific to software engineering for the wireless Internet, as pointed out in the title. From an application developer point of view the challenges include:

A methodology and a knowledge representation and reasoning framework for top-down goal-oriented characterization, modeling, and execution of software engineering activities is presented. A prototype system (ES-TAME) which demonstrates the underlying knowledge representation and reasoning principles is described. ES-TAME provides an object-oriented metamodel concept that provides support for tailorable and reusable software engineering models (SEMs). It provides the basic mechanisms, functions, and attributes for all the other models. It is based on interobject relationships, dynamic viewpoints, and selective inheritance in addition to traditional object-oriented mechanisms. Descriptive SEMs include representations for basic software engineering activities. They are controlled and made operational by active GQM (goal-question-metric paradigm) models which are built by a systematic mechanism for defining and evaluating project and corporate goals and using measurement to provide feedback in real-time.>