Machine Learning Operations (MLOps), derived from DevOps, aims to unify the development, deployment, and maintenance of machine learning (ML) models. Continuous training (CT) automatically retrains ML models, and continuous deployment (CD) automatically deploys the retrained models to production. CT and CD are essential for maintaining ML model performance in dynamic production environments and, therefore, need to be considered when practicing MLOps. We present our CTCD-e MLOps pipeline, implemented mostly using existing open-source software, being able to autonomously adapt an ML system to changing production environments by enabling flexible model CT and CD. The pipeline can automatically trigger a model retraining round when the model performance degrades. Then it automatically conducts an A/B test for the retrained model and its predecessor in production to start serving the better one. The pipeline was evaluated by two experiments. In the pipeline, users can flexibly configure the model retraining, as well as the redeployment and production A/B test of the retrained models based on various requirements.

Issue trackers, such as Jira, have become the prevalent collaborative tools in software engineering for managing issues, such as requirements, development tasks, and software bugs. However, issue trackers inherently focus on the lifecycle of single issues, although issues have and express dependencies on other issues that constitute issue dependency networks in large complex collaborative projects. The objective of this study is to develop supportive solutions for the improved management of dependent issues in an issue tracker. This study follows the Design Science methodology, consisting of eliciting drawbacks and constructing and evaluating a solution and system. The study was carried out in the context of The Qt Company's Jira, which exemplifies an actively used, almost two-decade-old issue tracker with over 100,000 issues. The drawbacks capture how users operate with issue trackers to handle issue information in large, collaborative, and long-lived projects. The basis of the solution is to keep issues and dependencies as separate objects and automatically construct an issue graph. Dependency detections complement the issue graph by proposing missing dependencies, while consistency checks and diagnoses identify conflicting issue priorities and release assignments. Jira's plugin and service-based system architecture realize the functional and quality concerns of the system implementation. We show how to adopt the intelligent supporting techniques of an issue tracker in a complex use context and a large data-set. The solution considers an integrated and holistic system view, practical applicability and utility, and the practical characteristics of issue data, such as inherent incompleteness.

Machine learning (ML) provides us with numerous opportunities, allowing ML systems to adapt to new situations and contexts. At the same time, this adaptability raises uncertainties concerning the run-time product quality or dependability, such as reliability and security, of these systems. Systems can be tested and monitored, but this does not provide protection against faults and failures in adapted ML systems themselves. We studied software designs that aim at introducing fault tolerance in ML systems so that possible problems in ML components of the systems can be avoided. The research was conducted as a case study, and its data was collected through five semi-structured interviews with experienced software architects. We present a conceptualisation of the misbehaviour of ML systems, the perceived role of fault tolerance, and the designs used. Common patterns to incorporating ML components in design in a fault tolerant fashion have started to emerge. ML models are, for example, guarded by monitoring the inputs and their distribution, and enforcing business rules on acceptable outputs. Multiple, specialised ML models are used to adapt to the variations and changes in the surrounding world, and simpler fall-over techniques like default outputs are put in place to have systems up and running in the face of problems. However, the general role of these patterns is not widely acknowledged. This is mainly due to the relative immaturity of using ML as part of a complete software system: the field still lacks established frameworks and practices beyond training to implement, operate, and maintain the software that utilises ML. ML software engineering needs further analysis and development on all fronts.

Artificial intelligence (AI) has made its way into everyday activities, particularly through new techniques such as machine learning (ML). These techniques are implementable with little domain knowledge. This, combined with the difficulty of testing AI systems with traditional methods, has made system trustworthiness a pressing issue. This paper studies the methods used to validate practical AI systems reported in the literature. Our goal is to classify and describe the methods that are used in realistic settings to ensure the dependability of AI systems. A systematic literature review resulted in 90 papers. Systems presented in the papers were analysed based on their domain, task, complexity, and applied validation methods. The validation methods were synthesized into a taxonomy consisting of trial, simulation, model-centred validation, and expert opinion. Failure monitors, safety channels, redundancy, voting, and input and output restrictions are methods used to continuously validate the systems after deployment. Our results clarify existing strategies applied to validation. They form a basis for the synthesization, assessment, and refinement of AI system validation in research and guidelines for validating individual systems in practice. While various validation strategies have all been relatively widely applied, only few studies report on continuous validation.

Managing software projects gets more and more complicated with an increasing project and product size. To cope with this complexity, many organizations use issue tracking systems, where tasks, bugs, and requirements are stored as issues. Unfortunately, managing software projects might remain chaotic even when using issue trackers. Particularly for long lasting projects with a large number of issues and links between them, it is often hard to maintain an overview of the dependencies, especially when dozens of new issues get reported every day. We present a Jira plug-in that supports developers, project managers, and product owners in managing and overviewing issues and their dependencies. Our tool visualizes the issue links, helps to find missing or unknown links between issues, and detects inconsistencies.

Today’s dominant design for the Internet of Things (IoT) is a Cloud-based system, where devices transfer their data to a back-end and in return receive instructions on how to act. This view is challenged when delays caused by communication with the back-end become an obstacle for IoT applications with, for example, stringent timing constraints. In contrast, Fog Computing approaches, where devices communicate and orchestrate their operations collectively and closer to the origin of data, lack adequate tools for programming secure interactions between humans and their proximate devices at the network edge. This paper fills the gap by applying Action-Oriented Programming (AcOP) model for this task. While originally the AcOP model was proposed for Cloud-based infrastructures, presently it is re-designed around the notion of coalescence and disintegration, which enable the devices to collectively and autonomously execute their operations in the Fog by serving humans in a peer-to-peer fashion. The Cloud’s role has been minimized—it is being leveraged as a development and deployment platform.

Context: A software product line is a means to develop a set of products in which variability is a central phenomenon captured in variability models. The field of SPLs and variability have been topics of extensive research over the few past decades. Objective: This research characterizes systematic reviews (SRs) in the field, studies how SRs analyze and use evidence-based results, and identifies how variability is modeled. Method: We conducted a tertiary study as a form of systematic review. Results: 86 SRs were included. SRs have become a widely adopted methodology covering the field broadly otherwise except for variability realization. Numerous variability models exist that cover different development artifacts, but the evidence is insufficient in quantity and immature, and we argue for better evidence. SRs perform well in searching and selecting studies and presenting data. However, their analysis and use of the quality of and evidence in the primary studies often remains shallow, merely presenting of what kinds of evidence exist. Conclusions: There is a need for actionable, context-sensitive, and evaluated solutions rather than novel ones. Different kinds of SRs (SLRs and Maps) need to be better distinguished, and evidence and quality need to be better used in the resulting syntheses.

Background: Requirement engineering is often considered a critical activity in system development projects. The increasing complexity of software as well as number and heterogeneity of stakeholders motivate the development of methods and tools for improving large-scale requirement engineering. Aims: The empirical study presented in this paper aim to identify and understand the characteristics and challenges of a platform, as desired by experts, to support requirement engineering for individual stakeholders, based on the current pain-points of their organizations when dealing with a large number requirements. Method: We conducted a multiple case study with three companies in different domains. We collected data through ten semi-structured interviews with experts from these companies. Results: The main pain-point for stakeholders is handling the vast amount of data from different sources. The foreseen platform should leverage such data to manage changes in requirements according to customers' and users' preferences. It should also offer stakeholders an estimation of how long a requirements engineering task will take to complete, along with an easier requirements dependency identification and requirements reuse strategy. Conclusions: The findings provide empirical evidence about how practitioners wish to improve their requirement engineering processes and tools. The insights are a starting point for in-depth investigations into the problems and solutions presented. Practitioners can use the results to improve existing or design new practices and tools.

Requirements Engineering in open source projects such as ECLIPSE faces the challenge of having to prioritize requirements for individual contributors in a more or less unobtrusive fashion. In contrast to conventional industrial software development projects, contributors in open source platforms can decide on their own which requirements to implement next. In this context, the main role of prioritization is to support contributors in figuring out the most relevant and interesting requirements to be implemented next and thus avoid time-consuming and inefficient search processes. In this paper, we show how utility-based prioritization approaches can be used to support contributors in conventional as well as in open source Requirements Engineering scenarios. As an example of an open source environment, we use BUGZILLA. In this context, we also show how dependencies can be taken into account in utility-based prioritization processes.

The requirements for a system have many dependencies that can be expressed in the individual requirements managed in an issue tracker or a requirements management system. However, managing the entire body of requirements taking into account all complex dependencies is not well supported. We describe how a feature model based configurator can be used as a tool to help manage requirements data. Data transfer and constructing the needed requirements model can be carried out automatically by relying on a model generator. We implemented a prototype tool for requirements and release management that utilizes a knowledge-based configurator.

Within software product lines, customers may have different quality needs. To produce products with purposefully different quality attributes, several challenges must be addressed. First, one must be able to distinguish product quality attributes to the customers in a meaningful way. Second, one must create the desired quality attribute differences during product-line architecture design and derivation. To study how performance is varied purposefully in software product lines, we conducted a comparison and re-analysis of two industrial case studies in the telecommunication and mobile game domains. The results show that performance variants must be communicated to the customer in a way that links to customer value and her role. When performance or its adaptation are crucial for the customer, performance differences must be explicitly "designed in" with software or hardware means. Due to the emergent nature of performance, it is important to test performance and manage how other variability affects performance.

Finding a suitable time for a meeting is a common practical problem. The existing software solutions either cannot be used across heterogeneous calendar systems and organizations, or require manual effort and waiting. We employ design science to study how meetings can be scheduled over organizational and calendar system boundaries; the scheduling should be effortless while ensuring the user control and privacy of the calendar data. The resulting artifact utilizes heterogeneous calendar data from the mobile devices and the cloud calendars; the aim is to aid the organizer in making better decisions regarding the meeting times.

The success of software ecosystems highly depends on the variety and quality of end-user applications. Therefore, attracting third-party developers and facilitating application development is crucial. Platform boundary resources enable third-party developers to create the applications. Thus, the platform boundary resources expose and extend the platform architecture. We conducted an industrial case study on third-party developer experience, particularly on the role of platform boundary resources in exposing the platform architecture and facilitating development. The studied ecosystem is centered on managing end-users' content across devices, the ecosystem was in its pre-commercial phase. The results identify the platform boundary resources in the case study and propose a model for classifying the resources. Further, designing the platform boundary resources is not only about opening up the platform architecture. Instead, the platform boundary resources need to account for a rich variety of applications, or at least not limit too much the creativity of third-party developers, while still aiming at the ease of development. We conclude that the platform boundary resources need to be created for the third-party developers, rather than from the platform architecture.

Engineering large software-based systems in safety-critical domains is a challenging task despite extensive research on the topic. The software technologies and development processes are established, and basic safety principles are well known. However, demonstrating the safety of a software-based automation system remains a key challenge, particularly in the nuclear domain. In this paper, we describe our experiences from current nuclear projects featuring software-based automation. We observed a number of assumptions in regulation and standards related to safety principles, such as separation and diversity, which do not apply to software systems. The assumptions result in unrealistic expectations for software-based systems, making both design and safety demonstration challenging.

Nowadays, smart devices have excellent computing power and connectivity and at the same time are used for various purposes. This creates the possibility for complex, cooperative multi-device programs. However, current programming paradigms are not tailored for such a setting. This paper tackles the problem by introducing a new paradigm: an action-oriented programming model. Actions are proactively and pervasively initiated pieces of functionality, which provide synchronized and coordinated joint behavior between several devices. We show how the action-oriented programming model can be realized with a device cloud infrastructure. As a concrete example of an action-oriented infrastructure, we discuss the Social Devices Platform that demonstrates a socio-digital system between devices and people in proximity.

A hackathon (hacking marathon) is an event to innovate and develop prototypes, typically lasting at most a few days. Despite several innovations having been reported resulting from hackathons and the increasing popularity of hackathons, results about, organizing of, and experiences regarding hackathons have been scarcely reported. We studied a hackathon as a means to assess a device-centric cloud ecosystem in industrial settings. We provide a descriptive account of a three-days hackathon. The experience was that the hackathon was realistic as well as an efficient and effective assessment of the requirements and design of the ecosystem, providing guidance for future development. We also summarize the lessons learned about successfully organizing a hackathon. The results also highlight encouraging experience about the hackathon among the participants in terms of the social benefits, such as collaboration, inspiration, and work motivation, resulting in repeating hackathons for various purposes in the near future. In general, the results indicate a hackathon as a promising new approach in software engineering, where speed of development is becoming essential.

In the context of mobile devices, services from several devices can be composed. Such compassable services may include data and device resources, such as microphones or cameras. The services can be composed to create collaborative composite services, such as video streaming. The mobility of the devices makes the service compositions inherently dynamic. Further, the set of possible service compositions may be large, and thus finding a suitable service composition at runtime becomes a challenge. Recommender systems are intelligent information systems that propose items to a user based on the user preferences, they are particularly useful in under-constrained problems, where the most suitable item is recommended from a large set of possible items that satisfy the user preferences. The main contribution of this paper is the application of knowledge-based recommendation techniques for composing dynamic services for mobile devices. The contribution is exemplified and validated with the Social Device Platform, which provides interactive, proximity-based service compositions for mobile devices. Knowledge-based recommender systems were found to be applicable technologically and feasible in terms of performance for composing dynamic services in environments where runtime composition is necessary.

Online social media services, such as Facebook and Twitter, have set new standards on how people interact with each other online, share their everyday activities, and media services. While current mobile services supporting social interaction are typically primarily for remote communication, similar services can be introduced to co-located social interactions. In such a setting, people and proactive, context sensing mobile devices form a new kind of a socio-digital system where the mobile devices are active participants and can initiate interaction among the devices and people. Physical proximity of the devices becomes a key enabler to advance users' interaction with each other and the supporting mobile services. In this paper, we introduce the concept of Social Devices and its implementation. The Social Devices Platform facilitates autonomously composed cooperative services in co-located devices where the client part is simple and easily deployable to different kinds of devices.

Typically, products in a software product line differ by their functionality, and quality attributes are not intentionally varied. Why, how, and which quality attributes to vary has remained an open issue. A systematically conducted literature review on quality attribute variability is presented, where primary studies are selected by reading all content of full studies in Software Product Line Conference. The results indicate that the success of feature modeling influences the proposed approaches, different approaches suit specific quality attributes differently, and empirical evidence on industrial quality variability is lacking.

Currently users own and use many network-connected devices such as laptop, smart phone, or tablet. The user creates content using the default applications in these devices. One approach is to share and ubiquitously access the contents through a social media. Nevertheless, the contents residing in these devices should be available from anywhere, without any explicit user activity, even the contents residing in a remote location should also appear to be locally available in the operating device. With this approach we believe a user's content gets cloudified, while still remaining operable with the existing applications. In this paper we propose to cloudify a user's content in all her mobile devices. We present a middleware that allows a user to uniformly use the existing applications on local as well as remote content, and to also share the contents in a controlled way. The middleware hides all network activity to the user, it also makes the applications almost unaware while operating on a content residing in a remote location. To evaluate our approach in a mobile device context, we also present the efficiency measures of the middleware in terms of latency in content-retrieval, as well as in terms of resource usage viz. power consumption.

The successful practices of requirements engineering vary between application domains and are characterized by the nature of the application domain. One relatively peculiar application domain is the nuclear energy domain, which is characterized by the long life cycle of power plant operation and construction project, strict control of safety, and collaboration between several stakeholder groups including various branches of technology. We describe the state of the practice of requirements engineering in the nuclear energy domain in Finland on the basis of a descriptive case study focusing on the safety-related automation systems of the nuclear power plants. The results of the study indicate that explicit requirements engineering practices are becoming increasingly important due to the increasing complexity of the technology used, retirement of the older generation of experts, and construction of new power plants along with renewal of the existing nuclear power plants. The challenges of requirements engineering are especially within efficient communication and management of requirements. We highlight challenges that are emphasized by the characteristics of the nuclear energy domain but also discuss the more generic nature of these challenges. The identified challenges are in authority requirements, aging, communication, knowledge transfer, representation of requirements, and tool support.