Search

Continuous deployment has been practiced for many years by companies developing web‐ and cloud‐based applications. To succeed with continuous deployment, these companies have a strong collaboration culture between the operations and development teams. In addition, these companies use AI, analytics, and big data to assist with time‐consuming postdeployment activities such as continuous monitoring and fault identification. Thus, the term AIOps has evolved to highlight the importance and difficulty of maintaining highly available applications in a complex and dynamic environment. In contrast, software‐intensive embedded systems often provide customer product‐related services, such as maintenance, optimization, and support. These services are critical for these companies as they provide significant revenue and increase customer satisfaction. Therefore, the objective of our study is to gain an in‐depth understanding of the impact of continuous deployment on product‐related services provided by software‐intensive embedded systems companies. In addition, we aim to understand how AIOps can support continuous deployment in the context of software‐intensive embedded systems. To address this objective, we conducted a case study at a large and multinational telecommunications systems provider focusing on the radio access network (RAN) systems for 4G and 5G networks. The company provides RAN products and three complementing services: rollout, optimization, and customer support. The results from the case study show that the boundaries between product‐related services become blurry with continuous deployment. In addition, product‐related services, which were conducted in sequence by independent projects, converge with continuous deployment and become part of the same project. Further, AIOps platforms play an important role in reducing costs and increasing postdeployment activities' efficiency and speed. These results show that continuous deployment has a profound impact on the software‐intensive system's provider service organization. The service organization becomes the connection between the R&D organization and the customer. In order to cope with the increased speed of releases, deployment and postdeployment activities need to be largely automated. AIOps platforms are seen as a critical enabler in managing the increasing complexity without increasing human involvement. [ABSTRACT FROM AUTHOR]

Artificial intelligence is increasingly becoming important to businesses because many companies have realized the benefits of applying machine learning (ML) and deep learning (DL) in their operations. ML and DL have become attractive technologies for organizations looking to automate repetitive tasks to reduce manual work and free up resources for innovation. Unlike rule‐based automation, typically used for standardized and predictable processes, machine learning, especially deep learning, can handle more complex tasks and learn over time, leading to greater accuracy and efficiency improvements. One of such promising applications is to use AI to reduce manual engineering work. This paper discusses a particular case within McDermott where the research team developed a DL model to do a quality check of complex blueprints. We describe the development and the final product of this case—AI‐based software for the engineering, procurement, and construction (EPC) industry that helps to find the design mistakes buried inside very complex engineering drawings called piping and instrumentation diagrams (P&IDs). We also present a cost‐benefit analysis and potential scale‐up of the developed software. Our goal is to share the successful experience of AI‐based product development that can substantially reduce the engineering hours and, therefore, reduce the project's overall costs. The developed solution can also be potentially applied to other EPC companies doing a similar design for complex installations with high safety standards like oil and gas or petrochemical plants because the design errors it captures are common within this industry. It also could motivate practitioners and researchers to create similar products for the various fields within engineering industry. [ABSTRACT FROM AUTHOR]

Artificial intelligence (AI) and the use of machine learning (ML) and deep learning (DL) technologies are becoming increasingly popular in companies. These technologies enable companies to leverage big quantities of data to improve system performance and accelerate business development. However, despite the appeal of ML/DL, there is a lack of systematic and structured methods and processes to help data scientists and other company roles and functions to develop, deploy and evolve models. In this paper, based on multi‐case study research in six companies, we explore practices and challenges practitioners experience in developing ML/DL models as part of large software‐intensive embedded systems. Based on our empirical findings, we derive a conceptual framework in which we identify three high‐level activities that companies perform in parallel with the development, deployment and evolution of models. Within this framework, we outline activities, iterations and triggers that optimize model design as well as roles and company functions. In this way, we provide practitioners with a blueprint for effectively integrating ML/DL model development into the business to achieve better results than other (algorithmic) approaches. In addition, we show how this framework helps companies solve the challenges we have identified and discuss checkpoints for terminating the business case. [ABSTRACT FROM AUTHOR]

Continuous experimentation (CE) refers to a set of practices used by software companies to rapidly assess the usage, value, and performance of deployed software using data collected from customers and systems in the field using an experimental methodology. However, despite its increasing popularity in developing web‐facing applications, CE has not been studied in the development process of business‐to‐business (B2B) mission‐critical systems. By observing the CE practices of different teams, with a case study methodology inside Ericsson, we were able to identify the different practices and techniques used in B2B mission‐critical systems and a description and classification of the four possible types of experiments. We present and analyze each of the four types of experiments with examples in the context of the mission‐critical long‐term evolution (4G) product. These examples show the general experimentation process followed by the teams and the use of the different CE practices and techniques. Based on these examples and the empirical data, we derived the HURRIER process to deliver high‐quality solutions that the customers value. Finally, we discuss the challenges, opportunities, and lessons learned from applying CE and the HURRIER process in B2B mission‐critical systems. [ABSTRACT FROM AUTHOR]

With digitalization and with technologies such as software, data, and artificial intelligence, companies in the embedded systems domain are experiencing a rapid transformation of their conventional businesses. While the physical products and associated product sales provide the core revenue, these are increasingly being complemented with service offerings, new data‐driven services, and digital products that allow for continuous value creation and delivery to customers. However, although there is significant research on digitalization and digital transformation, few studies highlight the specific needs of embedded systems companies and what it takes to transform from a traditional towards a digital company within business domains characterized by high complexity, hardware dependencies, and safety‐critical system functionality. In this paper, we capture the difference between what constitutes a traditional and a digital company and we detail the typical evolution path embedded systems companies take when transitioning towards becoming digital companies. [ABSTRACT FROM AUTHOR]

Digitalization is transforming industry to an extent that we have only seen the beginnings of. Across domains, companies experience rapid changes to their existing practices due to new technologies and new entrants that current businesses. While digitalization brings endless opportunities, it comes with challenges that require companies to strategically engage with partners in their surrounding ecosystems. In this paper, we study how companies in the embedded systems domain experience the process of transitioning from product‐based companies to businesses where software, data, and artificial intelligence (AI) play an increasingly important role. To manage this, these companies need to evolve their existing ecosystems while at the same time create new ecosystems around new technologies. This involves maintaining existing technologies such as mechanics and electronics while at the same time expanding these with software, data, and AI. We provide a strategic decision framework that helps software‐intensive embedded systems companies to successfully navigate the digital transformation. We do this in two steps. First, we present three models that provide the technical content of the strategic decision framework. Second, we provide an overview of the strategic alternatives that incumbents and new entrants have available when existing technologies are commoditizing and new technologies are introduced. [ABSTRACT FROM AUTHOR]

Background: In the prehospital triage of patients presenting with symptoms suggestive of acute myocardial ischemia, reliable myocardial ischemia detection in the electrocardiogram (ECG) is pivotal. Due to large interindividual variability and overlap between ischemic and nonischemic ECG-patterns, incorporation of a previous elective (reference) ECG may improve accuracy. The aim of the current study was to explore the potential value of serial ECG analysis using subtraction electrocardiography.Methods: SUBTRACT is a multicenter retrospective observational study, including patients who were prehospitally evaluated for acute myocardial ischemia. For each patient, an elective previously recorded reference ECG was subtracted from the ambulance ECG. Patients were classified as myocardial ischemia cases or controls, based on the in-hospital diagnosis. The diagnostic performance of subtraction electrocardiography was tested using logistic regression of 28 variables describing the differences between the reference and ambulance ECGs. The Uni-G ECG Analysis Program was used for state-of-the-art single-ECG interpretation of the ambulance ECG.Results: In 1,229 patients, the mean area-under-the-curve of subtraction electrocardiography was 0.80 (95%CI: 0.77-0.82). The performance of our new method was comparable to single-ECG analysis using the Uni-G algorithm: sensitivities were 66% versus 67% (p-value > .05), respectively; specificities were 80% versus 81% (p-value > .05), respectively.Conclusions: In our initial exploration, the diagnostic performance of subtraction electrocardiography for the detection of acute myocardial ischemia proved equal to that of state-of-the-art automated single-ECG analysis by the Uni-G algorithm. Possibly, refinement of both algorithms, or even integration of the two, could surpass current electrocardiographic myocardial ischemia detection. [ABSTRACT FROM AUTHOR]

A known problem in large software companies is to balance the prioritization of short-term and long-term business goals. As an example, architecture suboptimality (Architectural Technical Debt), incurred to deliver fast, might hinder future feature development. However, some technical debt generates more interest to be paid than other. We conducted a multi-phase, multiple-case embedded case study comprehending 9 sites at 6 large international software companies. We have investigated which architectural technical debt items generate more interest , how the interest occurs during software development and which costly extra-activities are triggered as a result. We presented a taxonomy of the most dangerous items identified during the qualitative investigation and a model of their effects that can be used for prioritization, for further investigation and as a quality model for extracting more precise and context-specific metrics. We found that some architectural technical debt items are contagious, causing the interest to be not only fixed, but potentially compound, which leads to the hidden growth of interest (possibly exponential). We found important factors to be monitored to refactor the debt before it becomes too costly. Instances of these phenomena need to be identified and stopped before the development reaches a crises. [ABSTRACT FROM AUTHOR]

Recently, business ecosystems have been recognized as one of the most interesting phenomenon in software engineering research. Companies experience a paradigm shift where product development and innovation is moving outside the boundaries of the firm and where networks of stakeholders join forces to co-create value. While there is prominent research focusing on the managerial perspective of business ecosystems, few studies provide strategic guidance for how to intentionally manage the different ecosystems that companies operate in. Therefore, and on the basis of multicase study research, we provide empirical evidence on the challenges that software-intensive companies experience in relation to the different types of business ecosystems they operate in. We conduct a 'state-of-the-art' literature review to identify strategies that are used to manage ecosystem engagements, and we develop a conceptual model in which we identify strategies for managing the innovation ecosystem, the differentiating ecosystem, and the commoditizing ecosystem. By categorising the different strategies in relation to the different types of ecosystems for which they are valid, the 'three-layer ecosystem strategy model' provides comprehensive support for strategy selection. We validate the use of the identified strategies in 6 software-intensive case companies, and we provide empirical insights on the 'relevance' and the 'desired use' of these strategies as experienced by the case companies. [ABSTRACT FROM AUTHOR]

An introduction is presents in which the editor discusses various reports within the issue on topics including use of Bayesian networks for assisting continuous improvement of Scrum projects, portfolio management and adoption level of scaled agile development.

Abstract: The introduction of Agile Software Development in large companies developing embedded systems aims at shortening the time‐to‐market for new business value for the customers. However, evidences show how system engineering needs to be integrated in the process in order to avoid the degradation of architectural system qualities. Such phenomenon has recently been identified with a financial metaphor, Architectural Technical Debt, which maps sub‐optimal architectural solutions to taking a debt, and its costly impact into an interest to be paid in the long term. Through a multiple case study in 5 companies, we show what are the current practical challenges related to the long‐term accumulation of Architectural Technical Debt, and how system engineers need to track and manage such phenomenon in order to avoid costly impact such as development crises and costly re‐design. [ABSTRACT FROM AUTHOR]

Many consumer electronics firms are adopting an ecosystem-centric approach for supporting third-party applications. In an emerging market, a consumer electronics firm may need to create a new ecosystem or adopt a newly developed platform, both which has significant commercial and technical implications. In this paper we identify three types of ecosystems that are used today: vertically integrated hardware/software platforms, closed-source software platforms, and open-source software platforms. We introduce a first step towards a multi-criteria decision support method, which determines what type of ecosystem is most suitable for a specific product category from a software engineering perspective. We use this method to analyze a wide range of consumer electronics products. The analysis shows that the vertically integrated platform type is most suitable for product with a high degree of innovation, and open-source software platforms are more suitable when a large amount of variants are needed. The closed-source software platform type is less suitable for most types of consumer electronics devices. This first step towards a full-fledged decision support method can be used by platform owners to decide whether their platform can also be successfully transferred to another product type. [ABSTRACT FROM AUTHOR]

The adoption of Agile Software Development in large companies is a recent phenomenon of great interest both for researchers and practitioners. Although intra-team interaction is well supported by established agile practices, the critical interaction between the agile team and other parts of the organization is still unexplored in literature. Such interactions slow down the development, hindering the achievement of business goals based on speed: short time to market, quick replication of products of a product-line, and reaction time for product evolution. We have employed a two-year long multiple-case case-study, collecting data through interviews and a survey in three large companies developing embedded software. Through a combination of qualitative and quantitative analysis, we have found strong evidence that interaction challenges between the development team and other groups in the organization hinder speed and are widespread in the organizations. This paper also identifies current practices in use at the studied companies and provides detailed guidelines for novel solutions in the investigated domain. Such practices are called boundary-spanning activities in information system research and coordination theory. We present a comparison between large embedded software companies employing agile and developing a line of products based on reused assets and agile companies developing pure software. We highlight specific contextual factors and areas where novel spanning activities are needed for mitigating the interaction challenges hindering speed. Copyright © 2015 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

The feedback and input of users have been an important part of product innovation in recent years. User input has been studied from different approaches and is applied through different methods in particular phases of the innovation process. However, these methods are not integrated into the whole innovation process and are used only in particular phases or on an ad hoc basis. New developments in technology, social media, and new ways of working closer with customers have opened up new possibilities for firms to gain user input throughout the whole innovation process. However, the impact that these new developments in technology offer for user input innovation in high-tech firms is unclear. Therefore, we study how high-tech firms collect and apply user feedback throughout the whole innovation process. The paper is based on a comparative case study of eight cases in the high-tech industry, in which qualitative data collection was applied. The key contribution of the paper is a conceptual framework on user data-driven innovation throughout the innovation cycle. This framework gives insight into user involvement types and approaches to collect and apply user feedback throughout the innovation process. [ABSTRACT FROM AUTHOR]

The ability to rapidly respond to customer interest and to effectively prioritize development effort has been a long-standing challenge for mass-market software intensive products. This problem is exacerbated in the context of software product lines as functionality may easily fall over software asset and organizational boundaries with consequent losses in efficiency and nimbleness. Some companies facing these problems in their product line respond with a new development process. In this paper we discuss the developments within a single case study, Intuit's Quickbooks product line that combined agile software development, design thinking and self-organizing teams in a successful approach, which provided a significant improvement in terms of responsiveness and accuracy of building customer value. Copyright © 2011 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

We present the results of two case studies we conducted at Baan in the Netherlands. At the time of conducting the case studies, Baan was part of Invensys plc. (Baan is now owned by SSA Global Technologies.) In these case studies we investigated how companies identify design erosion and address this in their software, a practice we call ‘design preservation’. In this study, we selected two sub-systems in Baan products that had recently been subjected to extensive maintenance activities because they were eroded. In this paper, we analyze the problems these systems had, how Baan identified that these systems were problematic, and the remedies that were used to address the problems. In addition to confirming some of our earlier conclusions, we have been able to extract some common causes for design erosion problems as well as a number of recommended design preservation practices, which, at least for Baan, have proven to be very effective in strengthening design preservation. Copyright © 2005 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Several approaches to implement the concepts of software product families exist, but there is a tendency towards a revolutionary adoption. A revolutionary adoption of software product families is, however, a high-risk undertaking that may easily fail. Even if an iterative, evolutionary adoption is applied, there is a substantial risk that mismatches may develop in the organization due to a sub-optimal adoption approach. Mismatches between the optimal approach and the one currently used by an organization may lead to several problems, such as a high degree of erosion, mismatches between product needs and shared components, organizational ‘noise’ and inefficient knowledge management. This article (1) presents the problems resulting from the aforementioned mismatch, (2) presents the relevant decision dimensions that define the space of alternatives, (3) discusses the advantages and disadvantages of each alternative and (4) presents a framework for selecting the best alternative for each decision dimension based on a three-stage adoption model. Copyright © 2005 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Usability is increasingly recognized as an essential factor that determines the success of software systems. Practice shows that for current software systems, most usability issues are detected during testing and deployment. Fixing usability issues during this late stage of the development proves to be very costly. Some usability-improving modifications such as usability patterns may have architectural implications. We believe that the software architecture may restrict usability. The high costs associated with fixing usability issues during late-stage development prevent developers from making the necessary adjustments for meeting all the usability requirements. To improve upon this situation, we have investigated the relationship between usability and software architecture to gain a better understanding of how the architecture restricts the level of usability. Our article makes a number of contributions; a framework is presented that expresses the relationship between usability and software architecture. The framework consists of an integrated set of design solutions such as usability patterns and usability properties that have been identified in various cases in industry, modern day software and literature surveys. These solutions, in most cases, have a positive effect on usability but are difficult to retrofit into applications because they have architectural impact. Our framework may be used to guide and inform the architectural design phase. This may decrease development costs by reducing the amount of usability issues that need to be fixed during the later stages of development. Copyright © 2004 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Object-oriented framework technology has become a common reuse technology in software development. As with all software, frameworks evolve over time. Once the framework has been deployed, new versions of a framework potentially cause a high maintenance cost for the products built with the framework. This fact, in combination with the high costs of developing and evolving a framework, make it important for organizations to achieve a controlled and predictable evolution of the framework's functionality and costs. We present a metrics-based framework stability assessment method, which has been applied on two industrial frameworks from the telecommunication and graphical user interface domains. First, we discuss the framework concept and the frameworks studied. Then, the stability assessment method is presented including the metrics used. The results from applying the method, as well as an analysis of each of the frameworks, are described. We continue with a set of observations regarding the method, including framework differences that seem to be invariant with respect to the method. A set of framework stability indicators based on the results is then presented. Finally, we assess the method against issues related to the management and evolution of frameworks, framework deployment, change impact analysis and benchmarking. [ABSTRACT FROM AUTHOR]

This paper discuss the results of two case studies from a technical perspective, concentrating on the evolution of software assets in two Swedish organizations that have employed a product-line architecture approach for several years. This paper describes and analyses the commonalities and differences of these two cases, emphasising categories of the evolution of the requirements, of the software architecture and of the software components. This paper concludes with three types of lessons learned about evolution In software product lines: three evolution categories are predominant, three other categories are less significant but still common, and seven guidelines for software product-line evolution emerge. [ABSTRACT FROM AUTHOR]

Introduces several articles that addresses the process and management activities surrounding computer software variability. Technique in modelling software lifecycle; Configurable software product families; Overall process of managing a software product family.

Based on 25 interviews with participants from four case study companies that develop large‐scale software embedded systems, this paper presents the Test Activity Stakeholders (TAS) model. The TAS model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The model is developed to show how each of the stakeholder interests are best supported by unit/component tests or system tests, by automated testing or manual testing and by tests executed in simulated environments or on real hardware. The TAS model may serve as a starting point for companies when evaluating and designing their continuous integration and delivery pipeline. The validation of the TAS model included twelve individuals from three case study companies. The validation showed that the TAS model is actionable and useful in practice, enabling the identification of stakeholders and showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. The Test Activity Stakeholders (TAS) model shows how the continuous integration and delivery pipeline can be designed to include test activities that support four stakeholder interests: "Check changes," "Secure stability," "Measure progress," and "Verify compliance." The validation of the TAS model showed that the model is actionable and useful in practice, showing where improvement efforts should be focused in order to support all stakeholder interests in the continuous integration and delivery pipeline. [ABSTRACT FROM AUTHOR]

Companies need to know how much value their ideas deliver to customers. One of the most powerful ways to accurately measure this is by conducting online controlled experiments (OCEs). To run experiments, however, companies need to develop strong experimentation practices as well as align their organization and culture to experimentation. The main objective of this paper is to demonstrate how to run OCEs at large scale using the experience of companies that succeeded in scaling. Based on case study research at Microsoft, Booking.com, Skyscanner, and Intuit, we present our main contribution—The Experiment Growth Model. This four‐stage model addresses the seven critical aspects of experimentation and can help companies to transform their organizations into learning laboratories where new ideas can be tested with scientific accuracy. Ultimately, this should lead to better products and services. [ABSTRACT FROM AUTHOR]

Today, companies operate in business ecosystems where they collaborate, compete, share, and learn from others with benefits such as to present more attractive offerings and sharing innovation costs. With ecosystems being the new way of operating, the ability to strategically reposition oneself to increase or shift power balance is becoming key for competitive advantage. However, companies run into a number of traps when trying to realize strategical changes in their ecosystems. In this paper, we identify 5 traps that companies fall into. First, the "descriptive versus prescriptive trap" is when companies assume that current boundaries between partners are immutable. Second, the "assumptions trap" is when powerful ecosystem partners assume that they understand what others regard as value‐adding without validating their assumptions. Third, the "keeping it too simple trap" is when companies overlooks the effort required to align interests. Fourth, the "doing it all at once trap" is when companies disrupt an ecosystem assuming that all partners can change direction at the same time. Finally, the "planning trap" is when companies are unable to move forward without a complete plan. We provide empirical evidence for each trap, and we propose an ecosystem engagement process for how to avoid falling into these. Key findings: Repositioning in the ecosystem is fraud with risks. We identify the key traps that companies fall into, as well as provide guidance on how to avoid them when transitioning from current to desired state by shifting power between ecosystem partners. [ABSTRACT FROM AUTHOR]