Product-Focused Software Process Improvement

The task board is an essential artifact in many agile development approaches. It provides a good overview of the project status. Teams often customize their task boards according to the team members’ needs. They modify the structure of boards, define colored codings for different purposes, and introduce different card sizes. Although the customizations are intended to improve the task board’s usability and effectiveness, they may also complicate its comprehension and use. The increased effort impedes the work of both the team and team externals. Hence, task board customization is in conflict with the agile practice of fast and easy overview for everyone.In an eye tracking study with 30 participants, we compared an original task board design with three customized ones to investigate which design shortened the required time to identify a particular story card. Our findings yield that only the customized task board design with modified structures reduces the required time. The original task board design is more beneficial than individual colored codings and changed card sizes.According to our findings, agile teams should rethink their current task board design. They may be better served by focusing on the original task board design and by applying only carefully selected adjustments. In case of customization, a task board’s structure should be adjusted since this is the only beneficial kind of customization, that additionally complies more precisely with the concept of fast and easy project overview.

Context: Agile software development (ASD) uses ‘agile’ artefacts such as user stories and product backlogs as well as ‘non-agile’ artefacts, for instance designs and test plans. Rationales for incorporating especially non-agile artefacts by an agile team mainly remain unknown territory. Goal: We start off to explore influences on artefacts usage, and state our research question as: To what extent does maturity relate to the usage of artefacts in ASD in software product organizations? Method: In our multiple case study 14 software product organizations were visited where software product management maturity was rated and their artefacts usage listed. Results: We found maturity to be negatively correlated with the non-agile/all artefacts ratio. In other words, the more mature software product management is, the fewer non-agile artefacts are used in ASD. Conclusions: This suggests that an organizational factor influences an agile team in its artefacts usage, contradictory to the concept of self-organizing agile teams.

Context: The current situation and future scenarios of the automotive domain require a new strategy to develop high quality software in a fast pace. In the automotive domain, it is assumed that a combination of agile development practices and software product lines is beneficial, in order to be capable to handle high frequency of improvements. This assumption is based on the understanding that agile methods introduce more flexibility in short development intervals. Software product lines help to manage the high amount of variants and to improve quality by reuse of software for long term development.Goal: This study derives a better understanding of the expected benefits for a combination. Furthermore, it identifies the automotive specific challenges that prevent the adoption of agile methods within the software product line.Method: Survey based on 16 semi-structured interviews from the automotive domain, an internal workshop with 40 participants and a discussion round on ESE congress 2016. The results are analyzed by means of thematic coding.Results: Two main expected benefits of merging agile practices and product line development are pushing the change in software development for future proof agile automotive organizations. Challenges that prevent agile adoption within software product lines are mainly of organizational, technical and social nature. Key challenges are related to transforming organizational structures and culture, achieving faster software release cycles without loss of quality, appropriate quality assurance measures for software variants, and the collaboration with suppliers and other disciplines such as mechanics.Conclusion: Significant challenges are imposed by specific characteristics of the automotive domain such as high quality requirements and many interfaces to surrounding rigid and inflexible processes.

[Context/Background] Innovation is seen as the basis of competitive economy and measuring the innovation process is important for organizations. In the literature, focus has been on innovation and innovation capabilities on an organizational level, while few studies has been placed on innovation at team level. Furthermore, organizations tend to focus on the measurement of innovation to input and outputs of the innovation process and ignoring the process in-between. [Goal] This paper explores how a team’s innovation capability is measured, and can be measured in practice in agile and lean software developing companies. [Method] It is based on data collected through semi-structured interviews with 28 practitioners from 11 software developing companies. [Results] The contribution of this study is twofold: First, it characterizes which metrics are used in industry to measure a team’s innovation capability. Second, it identifies which metrics that could be used in practice to measure a team’s innovation capability. [Conclusions] Measuring the performance of the innovation process is not seen as important during product planning and development.

Data science has the potential to create value and deep customer insight for service and software engineering. Companies are increasingly applying data science to support their service and software development practices. The goal of our research was to investigate how data science can be applied in software development organisations. We conducted a qualitative case study with an industrial partner. We collected data through a workshop, focus group interview and feedback session. This paper presents the data science process recommended by experienced data scientists and describes the key characteristics of the process, i.e., agility and continuous learning. We also report the challenges experienced while applying the data science process in customer projects. For example, the data scientists highlighted that it is challenging to identify an essential problem and ensure that the results will be utilised. Our findings indicate that it is important to put in place an agile, iterative data science process that supports continuous learning while focusing on a real business problem to be solved. In addition, the application of data science can be demanding and requires skills for addressing human and organisational issues.

CONTEXT: Studies have shown contradictory results on the effectiveness of using a moving window of only the most recent projects for effort estimation, compared to using the full history of past data. Moving windows improved the accuracy of effort estimates for a single-company subset of the ISBSG dataset (www.isbsg.org), but not for three single-company subsets of the Finnish dataset (www.4sumpartners.com). The contradiction may be caused by different characteristics of the data sets: in particular, they differ noticeably in heterogeneity of industry sector. GOAL: To investigate the effect on estimation accuracy of differences in the characteristics of the data sets. METHOD: Conduct an experiment with a virtual data set, composed from the three subsets of the Finnish dataset. The composite data set is similar to the ISBSG subset in that it includes data from multiple industry sectors; the largest group of projects in both data sets comes from the same industry sector; and in both data sets the projects are concentrated in a similar number of years. RESULTS: The conclusions is the same as in the past study using the individual Finnish subsets: in the composite data set, moving windows are of no help. CONCLUSIONS: In this instance, increased heterogeneity of projects does not explain the contradiction. It is still not clear when windows may be helpful. Practitioners and researchers should not assume automatically that only the most recent data is best for effort estimation.

This paper proposes an application of the survival analysis to bug-fix events occurred in source files. When a source file is modified, it has a risk of creating a bug (fault). In this paper, such a risk is analyzed from a viewpoint of the survival time—the time that the source file can survive without any bug fix. Through an empirical study with 100 open source software (OSS) projects, the following findings are reported: (1) Source files modified by new developers have about $$26\%$$ shorter survival time than the others. (2) The above tendency may be inverted if the OSS project has more developers relative to the total number of source files.

Context: Despite decades of research in software cost estimation (SCE), the task remains difficult and software project overruns are common. Many researchers and practitioners agree that organisational issues and methodologies are equally important for successful SCE. Regardless of this recent development, SCE research is revolving heavily around methodologies. At the same time project management research has undergone a major shift towards managerial issues, and it found that top management support can be the most important success factor for projects.Goal: This study sheds light on top management’s role in SCE by identifying real-life practices for top management participation in SCE, as well as related organisational effects. Also, the impact of top management actions on project success is examined.Method: The study takes a qualitative and explorative case study based approach. In total, 18 semi-structured interviews facilitated examination of three projects in three organisations.Results: The results show that top management takes no, or very little, direct actions to participate in SCE. However, projects can conclude successfully regardless of the low extent of participation.Conclusions: Top management actions may also induce bias in estimation, influencing project success negatively. This implies that senior managers must recognise the importance of seeking realism and avoid influencing the estimation.

Code review has been known to be an effective quality assurance technique for decades. In the last years, industrial code review practices were observed to converge towards “change-based/modern code review”, but with a lot of variation in the details of the processes. Recent research also proposed hypotheses on factors that influence the choice of process. However, all current research in this area is based on small and largely non-random samples of cases. Therefore, we set out to assess the current state of the practice and to test some of these hypotheses with a survey among commercial software development teams. We received responses from 240 teams. They support many of the stated hypotheses, e.g., that change-based code review is the dominating style of code review in the industry, and that teams doing change-based code review have a lower risk that review use fades away. However, other hypotheses could not be confirmed, mainly that the balance of effects a team tries to reach with code reviews acts as a mediator in determining the details of the review process. Apart from these findings, we contribute the survey data set as a foundation for future research.

A software architecture evaluation is a way to assess the quality of the technical design of a product. It is also a prime opportunity to discuss the business goals of the product and how the design bears on them. But architecture evaluation methods are seen as hard to learn and costly to use. We present DASE, a compact approach that combines carefully selected key parts of two existing architecture evaluation methods while making evaluation lean and fast. We have applied DASE in three industrial cases and the early results show that even a one-day evaluation workshop yields valuable results at a modest cost.

Context/Background: Process and practice adoption is a key element in modern software process improvement initiatives, and many of them fail.Goal: This paper presents a preliminary version of a usability model for software development process and practice.Method: This model integrates different perspectives, the ISO Standard on Systems and Software Quality Models (ISO 25010) and classic usability literature. For illustrating the feasibility of the model, two experts applied it to Scrum.Results: Metrics values were mostly positive and consistent between evaluators.Conclusions: We find the model feasible to use and potentially beneficial.

Companies developing autonomous and software-intensive systems show an increasing need to adopt experimentation and data-driven strategies in their development process. With the growing complexity of the systems, companies are increasing their data analytic and experimentation teams to support data-driven development. However, organizations cannot increase in size at the same pace as the system complexity grows. Experimentation teams could run a larger number of experiments by letting the system itself to coordinate its own experiments, instead of the humans. This process is called automated experimentation. However, currently, no tools or frameworks address the challenge of running automated experiments.This paper discusses, through a set of architectural design decisions, the development of an architecture framework that supports automated continuous experiments. The contribution of this paper is twofold. First, it presents, through a set of architectural design decisions, an architecture framework for automated experimentation. Second, it evaluates the architecture framework experimentally in the context of a human-robot interaction proxemics distance problem. This automated experimentation framework aims to deliver more value from the experiments while using fewer R&D resources.

Context: GoF design patterns are popular among both researchers and practitioners, in the sense that software can be largely comprised of pattern instances. However, there are concerns regarding the efficacy with which software engineers maintain pattern instances, which tend to decay over the software lifetime if no special emphasis is placed on them. Pattern grime (i.e., degradation of the instance due to buildup of unrelated artifacts) has been pointed out as one recurrent reason for the decay of GoF pattern instances. Goal: Seeking to explore this issue, we investigate the existence of relations between the accumulation of grime in pattern instances and various related factors: (a) projects, (b) pattern types, (c) developers, and (d) the structural characteristics of the pattern participating classes. Method: For that, we empirically assessed these relations through an industrial exploratory case study involving five projects (approx. 260,000 lines of code). Results: Our findings suggest a linear accumulation of pattern grime, which may depend on pattern type and developer. Moreover, we present and discuss a series of correlations between the accumulation of pattern grime and structural characteristics. Conclusions: The outcome of our study can benefit both researchers and practitioners, as it points to interesting future work opportunities and also implications relevant to the refinement of best practices, the raise awareness among developers, and the monitoring of pattern grime accumulation.

[Context] Model-based Systems Engineering (MBSE) comprises a set of models and techniques that is often suggested as solution to cope with the challenges of engineering complex systems. Although many practitioners agree with the arguments on the potential benefits of the techniques, companies struggle with the adoption of MBSE. [Goal] In this paper, we investigate the forces that prevent or impede the adoption of MBSE in companies that develop embedded software systems. We contrast the hindering forces with issues and challenges that drive these companies towards introducing MBSE. [Method] Our results are based on 20 interviews with experts from 10 companies. Through exploratory research, we analyze the results by means of thematic coding. [Results] Forces that prevent MBSE adoption mainly relate to immature tooling, uncertainty about the return-on-investment, and fears on migrating existing data and processes. On the other hand, MBSE adoption also has strong drivers and participants have high expectations mainly with respect to managing complexity, adhering to new regulations, and reducing costs. [Conclusions] We conclude that bad experiences and frustration about MBSE adoption originate from false or too high expectations. Nevertheless, companies should not underestimate the necessary efforts for convincing employees and addressing their anxiety.

[Context/Background]: With the increasing use of cyber-physical systems in complex socio-technical setups, mechanisms that hold specific entities accountable for safety and security incidents are needed. Although there exist models that try to capture and formalize accountability concepts, many of these lack practical implementations. We hence know little about how accountability mechanisms work in practice and how specific entities could be held responsible for incidents. [Goal]: As a step towards the practical implementation of providing accountability, this systematic mapping study investigates existing implementations of accountability concepts with the goal to (1) identify a common definition of accountability and (2) identify the general trend of practical research. [Method]: To survey the literature for existing implementations, we conducted a systematic mapping study. [Results]: We thus contribute by providing a systematic overview of current accountability realizations and requirements for future accountability approaches. [Conclusions]: We find that existing practical accountability research lacks a common definition of accountability in the first place. The research field seems rather scattered with no generally accepted architecture and/or set of requirements. While most accountability implementations focus on privacy and security, no safety-related approaches seem to exist. Furthermore, we did not find excessive references to relevant and related concepts such as reasoning, log analysis and causality.

Context: Software is no longer only supporting mechanical and electrical products. Today, it is becoming the main competitive advantage and an enabler of innovation. Not all software, however, has an equal impact on customers. Companies still struggle to differentiate between the features that are regularly used, there to be for sale, differentiating and that add value to customers, or which are regarded commodity. Goal: The aim of this paper is to (1) identify the different types of software features that we can find in software products today, and (2) recommend how to prioritize the development activities for each of them. Method: In this paper, we conduct a case study with five large-scale software intensive companies. Results: Our main result is a model in which we differentiate between four fundamentally different types of features (e.g. ‘Checkbox’, ‘Flow’, ‘Duty’ and ‘Wow’). Conclusions: Our model helps companies in (1) differentiating between the feature types, and (2) selecting an optimal methodology for their development (e.g. ‘Output-Driven’ vs. ‘Outcome-Driven’).

Background: In the context of a larger research project, we plan to automatically extract user needs (i.e., functional requirements) from online open sources and classify them using the principles of the Kano model. In this paper, we present a two-step method for automatically transforming feature related text extracted from online open sources into inputs for Kano-like models. Goal: The problem we are facing is how to transform requirements and related sentiments extracted from raw texts collected from an online open source into the input format required by our Kano-like models. To solve this problem, we need a method that transforms requirements and related sentiments into a format that corresponds to answers that would be given to either the functional or dysfunctional question of the Kano method on a specific requirement. Method: We propose a method consisting of two steps. In the first step, we apply machine learning methods to decide whether a text line extracted from an online open source corresponds to an answer of the functional or dysfunctional question asked in the Kano method. In the second step, we use a dictionary-based method to classify the sentiment of each statement such that we can assign an answer value to each text line previously classified as functional or dysfunctional. We implemented our method in the R language. We evaluate the accuracy of the proposed method using simulation. Result: Based on the simulation results, we found the overall accuracy of our method is 65%. We also found that data sources such as app store reviews are better suited to our analysis than question/answer sources such as Stack Overflow. Conclusion: The method we proposed can be used to automatically transform feature-related text into inputs for Kano-like models but performance improvements are needed.

Feedback communication channels enable end-users to express their needs and problems when using a software system. This feedback can increase a software company’s knowledge about real software usage and can positively affect software evolution and maintenance. However, research shows that gathering feedback can be cumbersome for software companies. In a pilot study with Truck Parking Europe, we explore how we can enable truckers to communicate feedback on an app for parking slots. Results of our pilot study, consisting of a small group of truckers, show that the truckers provided useful feedback through a dedicated, mobile, and screenshot-based feedback tool. As stated by the Truck Parking Europe team, the feedback received is understandable and relevant for improving the parking app. In our future work, we will investigate the extent to which an integrated feedback tool can allow many truckers to provide feedback simultaneously and the extent to which the gathered feedback can aid in improving software evolution and maintenance activities at Truck Parking Europe.

With the rapid development of technology and competitiveness of IT sectors, the speed of learning and evolving is vital for success of software startups. However, software startups often face with multiple technical and business challenges, which lengthen the duration of their idea-to-launch process. Little is known about the relation of entrepreneurial characteristics of software startups and their product development. We conducted an empirical study on twenty software startups to understand their challenges that leads long idea-to-launch processes. Six engineering-related challenges were identified and interpreted via a lens of an entrepreneurial behavior theory. Our main finding is that the effectuation-based approach of developing a startup business is mismatched with the iterative, evolutionary-oriented approach of developing a startup product. Software startups search for local optimal solutions, emphasize on short-run feedback rather than long-run strategies, which results in vague prototype planning, paradox of demonstration and evolving throw-away prototypes.

Background – Resource-based-view and human capital theories have been used for decades when studying firms, their strategies, organizations, businesses, and successes. The value of the theories as general frameworks has commonly been recognized, especially because of their flexibility in adopting new perspectives, such as the dynamic character of the resources and human capital. Startup companies represent an interesting area on a map of firms because of their specific characteristics and tendency not to strictly follow the processes common in more established companies. Despite the differences, it is reasonable to assume that startups face similar phenomena as established companies do when building up their firms and operations. Aim – In this research, we studied software startups from the perspective of resource-based-view and human capital theories. We examined what human capital resources, capabilities, knowledge, and skills, were needed in the early stages of software startups and how the startups acquired such human capital. Method – We conducted a multiple-case study on a group of software startups in Norway and Finland. Results – We identified six high-level capability areas, nine means to acquire those capabilities, and nine drivers affecting the utilization of different means. We concluded that the capabilities in software startups are dynamic, evolving by growth and learning from the basis of the founders’ prior capabilities, and the utilization of different acquiring means is a case-dependent thing with a varying set of drivers. We also found the uniqueness of the resources, as proposed by the resource-based-view theory, was not reached in our case startups, but replaced with a combination of commonly-available resources, innovation, and application-specific capabilities.

Software startups often make assumptions about the problems and customers they are addressing as well as the market and the solutions they are developing. Testing the right assumptions early is a means to mitigate risks. Approaches such as Lean Startup foster this kind of testing by applying experimentation as part of a constant build-measure-learn feedback loop. The existing research on how software startups approach experimentation is very limited. In this study, we focus on understanding how software startups approach experimentation and identify challenges and advantages with respect to conducting experiments. To achieve this, we conducted a qualitative interview study. The initial results show that startups often spent a disproportionate amount of time focusing on creating solutions without testing critical assumptions. Main reasons are the lack of awareness, that these assumptions can be tested early and a lack of knowledge and support on how to identify, prioritize and test these assumptions. However, startups understand the need for testing risky assumptions and are open to conducting experiments.

Scrum is an increasingly common approach to software development adopted by organizations around the world. However, as organizations transition from traditional plan-driven development to agile development with Scrum, the question arises as to which Scrum role (Product Owner, Scrum Master, or Scrum Team Member) corresponds to a Project Manager, or conversely which Scrum role should the Project Managers adopt?In an attempt to answer this question, we adopted a mixed-method research approach comprising a systematic literature review and a case study of a commercial software development team. Our research has identified activities that comprise the Scrum Master role, and which additional roles are actually performed by Scrum Masters in practice.We found ten activities that are performed by Scrum Masters. In addition, we found that Scrum Masters also perform other roles, most importantly as Project Managers. This latter situation results in tension and conflict of interest that could have a negative impact on the performance of the team as a whole.These results point to the need to re-assess the role of Project Managers in organizations that adopt Scrum as a development approach. We hypothesize that it might be better for Project Managers to become Product Owners, as aspects of this latter role are more consistent with the traditional responsibilities of a Project Manager .

Background: Agile techniques recently have received attention from the developers of safety-critical systems. However, a lack of empirical knowledge of performing safety assurance techniques, especially safety analysis in a real agile project hampers further steps. Aims: In this article, we aim at (1) understanding and optimizing the S-Scrum development process, a Scrum extension with the integration of a systems theory based safety analysis technique, STPA (System-Theoretic Process Analysis), for safety-critical systems; (2) validating the Optimized S-Scrum development process further. Method: We conducted a two-stage exploratory case study in a student project at the University of Stuttgart, Germany. Results: The results in stage 1 showed that S-Scrum helps to ensure safety of each release but is less agile than the normal Scrum. We explored six challenges on: priority management; communication; time pressure on determining safety requirements; safety planning; time to perform upfront planning; and safety requirements’ acceptance criteria. During stage 2, the safety and agility have been improved after the optimizations, including an internal and an external safety expert; pre-planning meeting; regular safety meeting; an agile safety plan; and improved safety epics and safety stories. We have also gained valuable suggestions from industry, but the generalization problem due to the specific context is still unsolved.

Scrum based software development has become increasingly popular in recent years. Scrum requires teams following agile practices and their principles. One of them includes having room for the reflection of the team on how to become more effective. In this context, measuring and enhancing the performance of teams is still an area of interest for the Scrum community. Traditional Scrum metrics have often been used to measure the performance and productivity; however, individual contributions of team members to the project are often shaded by the team overall performance. In this paper, we propose a metric for measuring individual differences in project progress based on the traditional Burndown chart. We also show preliminary results of applying it in a particular training context, highlighting how learning-styles based instruction can improve the individual project progress of students.

To ensure the dependability and safety of spaceflight devices, rigorous standards are defined. Among others, one requirement from the European Cooperation for Space Standardization (ECSS) standards is 100% test coverage at software unit level. Different stakeholders need to have a good knowledge of the implications of such a requirement to avoid risks for the project that this requirement might entail. In this paper, we study if such a 100% test coverage requirement is a reasonable one. For this, we interviewed the industrial developers who ran a project that had the sole goal of achieving 100% unit test coverage in a spaceflight software. We discuss costs, benefits, risks, effects on quality, interplay with surrounding conditions, and project management implications. We distill lessons learned with which we hope to support other developers and decision makers when considering a 100% unit test coverage requirement.

In this paper, we show how exploratory testing plays a role as part of a continuous integration and delivery pipeline for large-scale and complex software products. We propose a test method that incorporates exploratory testing as an activity in the continuous integration and delivery pipeline, and is based on elements from other testing techniques such as scenario-based testing, testing in teams and testing in time-boxed sessions. The test method has been validated during ten months by 28 individuals (21 engineers and 7 flight test pilots) in a case study where the system under test is a fighter aircraft. Quantitative data from the case study company shows that the exploratory test teams produced more problem reports than other test teams. The interview results show that both engineers and test pilots were generally positive or very positive when they described their experiences from the case study, and consider the test method to be an efficient way of testing the system in the case study.

Software globalization is an inevitable step for many companies. Developing for a global market requires the internationalization of software products and their localization to different countries, regions, and cultures. Internationalization and localization testing verifies that localized variants of the software product work, look and feel as expected. The highly repetitive task of testing of multiple language variants makes localization testing a perfect candidate for automation with a high potential to reduce the involved human effort and to speed-up release cycles. However, there is surprisingly little support for localization testing by existing test automation tools. Furthermore, there are only few empirical results or practical insights available as the topic is rarely addressed in the scientific literature. In this paper we describe the process and tools applied for automated testing of the different localized variants of a large commercial software product, we report on the issues detected with automated localization tests, and we discuss our experiences and lessons learned.

Software and system development is complex and diverse, and a multitude of development approaches is used and combined with each other to address the manifold challenges companies face today. To study the current state of the practice and to build a sound understanding about the utility of different development approaches and their application to modern software system development, in 2016, we launched the HELENA initiative. This paper introduces the 2nd HELENA workshop and provides an overview of the current project state. In the workshop, six teams present initial findings from their regions, impulse talk are given, and further steps of the HELENA roadmap are discussed.

The way how software is developed in industry has considerably changed with the advent of the agile development paradigm about 20 years ago. The HELENA initiative tries to investigate the current state of practice in software and system development. This paper reports about initial results of an online survey that was conducted in 26 countries simultaneously, focusing on results from Estonia and comparing these results with results from Sweden as well as with the joint results from all participating countries worldwide.

Many organizations are adapting the use of hybrid software development approaches by combining traditional methods with flexible agile practices. This paper presents the initial results from the survey on the use of hybrid software and systems approaches. The results are from twenty one respondents from Sweden and Uganda. Our results show that the iterative model is the most widely used process model in both Sweden and Uganda. However, the traditional process models are also used in combination with the more agile models like Scrum. From the results, we also show that the large sized companies face the biggest problems during implementation of agility since they have to adhere to standards and control measures.

Since the early days of software engineering, a number of methods, processes, and practices to design and develop software systems have been proposed and applied in industry, e.g., the Rational Unified Process, Agile Software Development, etc. However, since no silver bullet exists, organizations use rich combinations of agile and/or traditional methods and practices, rather than following a single process by the book. To investigate this reality, an international exploratory multistage research project named HELENA (Hybrid DEveLopmENt Approaches in software systems development) was initiated. Currently, the HELENA survey is conducted globally (second stage of HELENA project). This short paper presents and discusses the results of the survey in Danmark compared to the global results based on the data from August 15, 2017.

Many software development teams face the problem of selecting a suitable development approach fitting to their specific context. According to them, the combination of agile and traditional approaches seems to be the solution to handle this problem. However, the current state of practice with respect to hybrid approaches is not sufficiently examined. Most studies focus either on traditional or on agile methods, but the combination of both is not well investigated yet. The “Hybrid dEveLopmENt Approaches in software systems development” (HELENA) study performs a large-scale international survey in order to gain insights into the distribution of hybrid approaches. So far, the study indicates several reasons why companies combine agile and traditional approaches. The hybrid approaches aim at improving the frequency of delivery to customers, the adaptability and the flexibility of the process to react to change. Furthermore, it is the aim to increase the productivity. In this publication, we present the current state of the German results and outline the next steps.

The application of software process models in industry includes traditional processes, agile processes, and process variants that aim at balancing traditional and agile with focus on specific industry needs. To investigate the characteristics of such hybrid software and system development approaches that combine agile and traditional approaches the HELENA project was initiated. HELENA is based on a large international survey. Based on the first HELENA survey, conducted in 2016, in 2017 a second round of surveys has been launched. This paper focuses on initial results and discussions of the data from Austria where 22 persons participated. Results showed a good balance of small and medium enterprises and large organizations. Iterative development processes and Scrum are widely spread in these organizations where traditional approaches are often combined with some agile practices.

HELENA Survey is a worldwide initiative that aims to investigate the use of hybrid software development approaches ranging from agile to traditional and how they combine. This article presents the initial results and observations on software development practice in Argentina, and briefly discusses two patterns of interest related to software development practice usage.

The two communities of Software Engineering and Human-Computer Interaction tackle issues related to the software development process differently although with the same final goal: that of developing high quality software most effectively. This workshop has reached its third edition and is continuing to pursue the positive results achieved in previous years. The research question discussed is: how can we assure high quality software from a HCI and SE perspective?

Team communication addresses a critical issue for software developments. Understanding human behavior and communication take an important role for cost optimized scheduling and adjustment of dysfunctional manner. But team phenomena are often not trivial to interpret. Empirical studies can disclose practical information. Many kinds of research with the focus on human factors justify findings solely through linear statistics. This leads to an estimation problem of formally interpreted effects, in particular for diagnosis models. In this paper, we investigate several team communication effects with data records from an empirical study with 34 academic software projects. In general, we want to increase the awareness for often insufficiently interpreted human factors. We apply conventional linear correlation statistics in comparison with the novel exploratory analysis MINE on three sample cases concerning team meetings and communication behavior. Both analyzing techniques approved to be capable in identifying the relevant team communication effects within the case studies, even though with different estimation of relevances. The study demonstrates how quickly e.g. group behavior and communication effects can be insufficiently interpreted with dangerous gaps for factor estimation in modeling approaches.

Companies of the defense sector use heavyweight methodologies such as the V-model to develop large systems in which reliability is a crucial factor. This model has well-known disadvantages but the necessity to maintain all the phases under control and its mandatory use by the public institutions prevent the companies from altering the methodology. This paper describes a process improvement proposal for the V-model based on the concepts of Extreme-Engineering, team creation and task allocation strategies that take into account the personality of workers and its impact on productivity and quality. The study has been performed in a real company of the defense sector. The proposal has been tested and validated using a multiparadigm simulation model that makes use of the company historical data.

Background. The proportion of older adults (OAs) is increasing throughout the developed world. Social isolation is a recognised problem for this sector. Technology is regarded as a possible way to create a more inclusive society, where for example social network systems (SNSs) can keep OAs in contact with local communities, create new communities, reduce adverse impact of geographic separation, reduced mobility and lifestyle changes. Objective. As end-users of SNSs, this paper looks at the current state of practice of SNSs for OAs. We explore what OAs think about SNSs, what they want from SNSs and whether these needs are met. Method. Taking a snowballing approach, we examined 51 primary studies on SNSs for OAs. Results. There is a discernible increase in SNSs designed for OAs since 2005, which claim to meet needs such as simplicity, ease of use, privacy and access to useful information. Yet, sustained use over time is unknown. Conclusion. SNSs remain a potential way to reduce the social isolation of OAs, however the extent to which SNSs can replace real human contact is largely unexplored, as is whether SNSs can trigger the creation of new supportive communities.

Software project success has various facets and definitions ranging from customer satisfaction over software quality to the degree of implemented vs. not implemented requirements. Customers, developers and project leaders strive for project success. During the development process, they try to pay attention to aspects which are perceived to be important for a satisfying project execution from their individual point of view. These aspects may vary according to the underlying definition and understanding of project success. Different views on the importance of aspects like communication can cause problems and complicate the collaboration due to different expectations and misunderstandings.In a study with 97 student participants and eight customers, we examine which factors are perceived to be important for a successful project execution. In order to unfold discrepancies, we analyze whether the views of customers and developers on the relevance of aspects like communication and fulfilling the requirements specification differ from each other. According to our results, communication is most important for both the team and the customer. But they have different ideas of the term: The correct exchange of information between the team and the customer as well as the team-internal communication.In particular rather inexperienced developers and customers should be aware of different ideas of terms like communication for a successful project execution. It is not sufficient to know that communication is important. Being aware of different ideas can facilitate the collaboration and avoid problems due to misunderstandings.

Optimal management of software quality calls for appropriate integration of quality management activities into the whole software (engineering) life-cycle. However, despite the competitive advantage of ensuring and maintaining high quality levels, software development methodologies still offer little support for the integration and management of quality. This is especially true for, and essential in, agile software development processes and the recent trends towards rapid and continuous software development. The premise is that faster and more frequent release cycles should not compromise quality. This workshop aims to exchange challenges, experiences, and solutions among researchers and practitioners to bring agile and rapid software processes a step further towards seamless integration of quality management activities into their practices.

Non-functional requirements (NFRs) are determinant for the success of software projects. However, they are characterized as hard to define, and in agile software development (ASD), are often given less priority and usually not documented. In this paper, we present the findings of the documentation practices and challenges of NFRs in companies utilizing ASD and propose guidelines for enhancing NFRs documentation in ASD. We interviewed practitioners from four companies and identified that epics, features, user stories, acceptance criteria, Definition of Done (DoD), product and sprint backlogs are used for documenting NFRs. Wikis, word documents, mockups and spreadsheets are also used for documenting NFRs. In smaller companies, NFRs are communicated through white board and flip chart discussions and developers’ tacit knowledge is prioritized over documentation. However, loss of traceability of NFRs, the difficulty in comprehending NFRs by new developers joining the team and limitations of documentation practices for NFRs are challenges in ASD. In this regard, we propose guidelines for documenting NFRs in ASD. The proposed guidelines consider the diversity of the NFRs to document and suggest different representation artefacts depending on the NFRs scope and level of detail. The representation artefacts suggested are among those currently used in ASD in order not to introduce new specific ones that might hamper actual adoption by practitioners.

Due to cost and time constraints, software quality is often neglected in the evolution and adaptation of software. Thus, maintainability suffers, maintenance costs rise, and the development takes longer. These effects are referred to as “technical debt”. The challenge for project managers is to find a balance when using the given budget and schedule, either by reducing technical debt or by adding technical features. This balance is needed to keep time to market for current product releases short and future maintenance costs at an acceptable level.Method: The project ProDebt aimed at developing an innovative methodology and a software tool to support the strategic planning of technical debt in the context of agile software development. In this project, we created quality models and collected corresponding measurement data for two case studies in two different companies. Altogether, the two case studies contributed 5–6 years of data, from the end of 2011, resp. mid-2012, until today. Using measurement and effort data, we trained a machine-learning model to predict productivity based on measurement data—representing the technical debt of a file at a given point in time.Result: We developed a prototype and a prediction model for forecasting potential savings based on proposed refactorings of key drivers of technical debt identified by the model. In this paper, we present the approach and the experiences made during model development.

The development of software within short timeframes calls for concepts like minimum viable products with lean development. An agile development setting allows software products to be put on the market in time. Nevertheless, quality, especially in terms of user requirements, suffers when the focus is on the speed of the development. Therefore, we have developed the approach Opti4Apps, which considers user feedback automatically. This automation enables rapid user feedback to be revealed, which is needed for lean development in order to achieve high software quality in accordance with the users’ needs. This paper shows how the approach can be applied smoothly in agile development settings by analyzing common agile practices with regard to our user-centric feedback approach Opti4Apps. It turned out that with most practices, the additional effort is low, and the positive influence can be highly beneficial.

Problems commonly observed in Big Data and Predictive Analytics projects that try to provide data-driven innovations motivate the need for a general paradigm shift from passive to active data collection. A possible active data collection framework based on Big Data technology is outlined and possible implications for research are identified.

Management of Quality Requirements (QRs) is determinant for the success of software projects. However, this management is currently under-considered in software projects and in particular, in agile methods. Although agile processes are focused on the functional aspects of the software, some agile practices can be beneficial for the management of QRs. For example, the collaboration and interaction of people can help in the QR elicitation by reducing vagueness of requirements through communication. In this paper, we present the initial findings of our research investigating what industrial practices, from the agile methods, can be used for better management of QRs in agile software development. We use Situational Method Engineering to identify, complement and classify a portfolio of best practices for QR management in agile environments. In this regard, we present the methodological approach that we are applying for the definition of these guidelines and the requirements that will lead us to compile a portfolio of agile QR management best practices. The proposed requirements correspond to the whole software life cycle starting in the elicitation and finalizing in the deployment phases.

In this paper, a new approach is proposed for automated software maintenance. The tool is able to perform 26 different refactorings. It also contains a large selection of metrics to measure the impact of the refactorings on the software and six different search based optimization algorithms to improve the software. This tool contains both mono-objective and multi-objective search techniques for software improvement and is fully automated. The paper describes the various capabilities of the tool, the unique aspects of it, and also presents some research results from experimentation. The individual metrics are tested across five different codebases to deduce the most effective metrics for general quality improvement. It is found that the metrics that relate to more specific elements of the code are more useful for driving change in the search. The mono-objective genetic algorithm is also tested against the multi-objective algorithm to see how comparable the results gained are with three separate objectives. When comparing the best solutions of each individual objective the multi-objective approach generates suitable improvements in quality in less time, allowing for rapid maintenance cycles.

Context: How to adopt, scale and tailor agile methods depends on several factors such as the size of the organization, business goals, operative model, and needs. The Scaled Agile Framework (SAFe®) was developed to support organizations to scale agile practices across the enterprise.Problem: Early adopters of SAFe® tend to be large multi-national enterprises who report that the adoption of SAFe® has led to significant productivity and quality gains. However, little is known about whether these benefits translate to small to medium sized enterprises (SMEs).Method: As part of a longitudinal study of an SME transitioning to SAFe we ask, to what extent are SAFe®practices adopted at the team level? We targeted all team members and administrated a mixed method survey in February, 2017 and in July, 2017 to identify and evaluate the adoption rate of SAFe® practices.Results: Initially in Quarter 1, teams were struggling with PI/Release health and Technical health throughout the organization as most of the teams were transitioning from plan-driven to SAFe®. But, during the transition period in Quarter 3, we observed discernible improvements in different areas of SAFe practice adoption.Conclusion: The observed improvement might be due to teams merely becoming more familiar with the practices over-time. However, management had also made some structural changes to the teams that may account for the change.

There is the widespread belief that Agile neglects the product quality. This lack of understanding how Agile processes assure the quality of the product prevents especially companies from regulated domains from an adoption of Agile. This work aims to identify which Agile Practices contribute towards product quality. Hence, data from a survey study is analyzed to identify Agile Practices which are beneficial or harmful for the quality of the product. From 49 practices that were used in the survey so far, 36 were perceived to have a positive impact on product quality, while four practices were rated as being harmful. The results enrich understanding of how product quality can be achieved in Agile, and support selection of practices to improve quality.

Recently, model checkers, such as SPIN, have played an important role in the enhancement of software reliability. To promote the use of model checkers, we propose a visual programming language for SPIN model checkers for educational use. Our prototype is based on Google Blockly.

Communication in teams is an important but difficult issue. In a Scrum development process, we use meetings like the Daily Scrum to inform others about important problems, news and events in the project. When persons are absent due to holiday, illness or travel, they miss relevant information because there is no guarantee that the content of these meetings is documented. We present a concept and a Twitter-like tool to improve communication in a Scrum development process. We take advantage out of the observation that many people do not like to create documentation, but they do like to share what they did. We used the tool in industrial practice and observed an improvement in communication.

Manual verification of the consistency between UML state machine diagrams and sequence diagrams is labor-intensive and prone to make mistakes. We provide an automatic tool written in Java that performs the verification by translating UML diagrams into a process description of CSP$$_M$$ language. The tool takes in a PlantUML file and verifies the consistency with a model-checker FDR.

Recent studies report that many Big Data projects fail due to insufficient alignment with the organization’s strategic objectives and no consideration of its operational capabilities. Our method for the analysis of the potentials of Big Data supports companies in making a rational decision to use Big Data as well as in systematically conceptualizing and realizing a specific Big Data strategy. The Potential Analysis helps to find a Big Data solution for a specific business innovation idea that promises to deliver the best trade-off between the potential business benefits and the investments required for deploying it. The development of a suitable solution happens in several iterations during which both the anticipated data-driven business solution and the required Big Data solution concept are revised. This tutorial addresses experts from business and IT. The participants will learn a systematic approach for developing a company-specific Big Data strategy.

Requirements are usually documented, and natural language is still the primary choice of syntax. However, in particular with natural language, the quality of the documentation is a key success factor for projects. To keep this risk in check, projects apply manual quality assurance in the form of reviews. Due to the shortcomings of manual reviews, more and more companies look into lightweight automatic support mechanisms to improve the quality of requirements documents.

The Finnish software intensive industry has renewed their existing business and organizational ways of working towards a value-driven, adaptive real-time business paradigm. The industry utilizes new technical infrastructures such as data visualization and feedback from product delivery. These new capabilities as well as various sources of data and information help in gaining and applying the deep customer insight. This tutorial has been created and adapted from 100+ concrete N4S consortia results in public domain with several successful examples of adjacency towards the new markets and business areas.

Process mining is an emerging area that synergically combines model-based and data-oriented analysis techniques to obtain useful insights on how business processes are executed within an organization. This tutorial aims at providing an introduction to the key analysis techniques in process mining that allow decision makers to discover process models from data, compare expected and actual behaviors, and enrich models with key information about the actual process executions. In addition, the tutorial will present concrete tools and will provide practical skills for applying process mining in a variety of application domains, including the one of software development.