Context: Cultural aspects are of high importance as they guide people’s behaviour and thus, influence how people apply methods and act in projects. In recent years, software engineering research emphasized the need to analyze the challenges of specific cultural characteristics. Investigating the influence of cultural characteristics is challenging due to the multi-faceted concept of culture. People’s behaviour, their beliefs and underlying values are shaped by different layers of culture, e.g., regions, organizations, or groups. In this study, we focus on agile methods, which are agile approaches that focus on underlying values, collaboration and communication. Thus, cultural and social aspects are of high importance for their successful use in practice. Objective: In this paper, we address challenges that arise when using the model of cultural dimensions by Hofstede to characterize specific cultural values. This model is often used when discussing cultural influences in software engineering. Method: As a basis, we conducted an exploratory, multiple case study, consisting of two cases in Japan and two in Germany. Contributions: In this study, we observed that cultural characteristics of the participants differed significantly from cultural characteristics that would typically be expected for people from the respective country. This drives our conclusion that for studies in empirical software engineering that address cultural factors, a case-specific analysis of the characteristics is needed.

As Machine Learning (ML) becomes more prevalent in Industry 4.0, there is a growing need to understand how systematic approaches to bringing ML into production can be practically implemented in industrial environments. Here, MLOps comes into play. MLOps refers to the processes, tools, and organizational structures used to develop, test, deploy, and manage ML models reliably and efficiently. However, there is currently a lack of information on the practical implementation of MLOps in industrial enterprises. To address this issue, we conducted a multiple case study on MLOps in three large companies with dedicated MLOps teams, using established tools and well-defined model deployment processes in the Industry 4.0 environment. This study describes four of the companies' Industry 4.0 scenarios and provides relevant insights into their implementation and the challenges they faced in numerous projects. Further, we discuss MLOps processes, procedures, technologies, as well as contextual variations among companies.

Machine learning (ML) has become popular in the industrial sector as it helps to improve operations, increase efficiency, and reduce costs. However, deploying and managing ML models in production environments can be complex. This is where Machine Learning Operations (MLOps) comes in. MLOps aims to facilitate this deployment and management process. One of the MLOps challenges is understanding how ML models reason, which is key to trust and acceptance. Here, explainable AI (XAI) can help. Better error identification and improved model accuracy are only two resulting advantages. An often neglected fact is that deployed models are bypassed when model performance or explanations do not meet user expectations. In this paper, we provide a novel reference architecture to address the challenge of integrating explanations and feedback capabilities into MLOps. Our architecture is implemented in a series of industrial use cases in the project EXPLAIN. The proposed MLOps software architecture has several advantages. It provides an efficient way to manage ML models in production environments. Further, it allows for integrating explanations into the development and deployment processes.

Agile methods are well-known approaches in software development and used in various settings, which may vary wrt. organizational size, culture, or industrial sector. One important facet for the successful use of agile methods is the strong focus on social aspects. We know, that cultural values influence the behaviour of humans. Thus, an in-depth understanding of the influence of cultural aspects on agile methods is necessary to be able to adapt agile methods to various cultural contexts. In this paper we focus on an enabler to this problem. We want to better understand the influence of cultural factors on agile practices. The core contribution of this paper is MoCA: A model describing the impact of cultural values on agile elements.

A Self-adaptive System (SaS) modifies its domain functionality according to changes in its environment autonomously. Distributed control and central control represent two complementary paradigms to establish this capability. The selection of one of them leads to significant trade-offs regarding certain software qualities when designing a SaS. A promising approach to minimize these trade-offs is an integration, which combines the individual benefits to achieve the best of both paradigms. However, establishing such a multi-paradigm control requires comprehensive knowledge about control options and their interactions, which is hardly available.In this paper, we present patterns for integrating distributed and central control. We introduce them by a schema of Control Action Types (CATs). Each CAT describes a unique type of interaction between a central controller and a distributed controlled SaS to achieve a desired adaptation. Further, we identify involved tradeoffs between these CATs aiming at a systematic discussion of the range of multi-paradigm control for a SaS.

Cyber-Physical Production Systems (CPPSs) are envisioned as next-generation adaptive production systems combining modern production techniques with the latest information technology. A CPPS creates a complex environment between different domains (mechanical, electrical, software engineering), requiring multidisciplinary solutions to tackle growing complexity issues and reduce (maintenance) effort. Software plays an increasingly important role in assuring an effective and efficient operation of CPPSs. However, software engineering methods applied for CPPSs seem to lag behind modern software engineering methods, where tremendous progress has been made in the last years. We initiated the Software Engineering in Cyber-Physical Production Systems Workshop (SECPPS-WS) to analyze and overcome this gap. After two instances with mostly academic participants, we conducted a full-day workshop with nine industry representatives from eight companies that develop and maintain CPPSs. Each industry representative presented their current work and challenges. We collected these challenges and condensed a categorized list of challenges backed by industry statements and literature. This paper presents the resulting list and pointers to (partial) solutions to offer guidance for academia and identify promising research opportunities in this area.

The increasing importance of automation and smart capabilities for factories and other industrial systems has led to the concept of Industry 4.0 (I4.0). This concept aims at creating systems that improve the vertical and horizontal integration of production through (i) comprehensive and intelligent automation of industrial processes, (ii) informed and decentralized real-time decision making, and (iii) stringent quality requirements that can be monitored at any time. The I4.0 infrastructure, supported in many cases by robots, sensors, and algorithms, demands highly skilled workers able to continuously monitor the quality of both the items to be produced and the underlying production processes. While the first attempts to develop smart factories and enhance the digital transformation of companies are under way, we need adequate methods to support the identification and specification of quality attributes that are relevant to I4.0 systems. Our main contribution is to provide a refined version of the ISO 25010 quality model specifically tailored to those qualities demanded by I4.0 needs. This model aims to provide actionable support for I4.0 software engineers that are concerned with quality issues. We developed our model based on an exhaustive analysis of similar proposals using the design science method as well as expertise from seasoned engineers in the domain. We further evaluate our model by applying it to two important I4.0 reference architectures further clarifying its application.

Abstract Verification approaches for Software Product Lines (SPL) aim at detecting variability-related defects and inconsistencies. In general, these analyses take a significant amount of time to provide complete results for an entire, complex SPL. If the SPL evolves, these results potentially become invalid, which requires a time-consuming re-verification of the entire SPL for each increment. However, in previous work we showed that variability-related changes occur rather infrequently and typically only affect small parts of a SPL. In this paper, we utilize this observation and present an incremental dead variable code analysis as an example for incremental SPL verification, which achieves significant performance improvements. It explicitly considers changes and partially updates its previous results by re-verifying changed artifacts only. We apply this approach to the Linux kernel demonstrating that our fastest incremental strategy takes only 3.20 seconds or less for most of the changes, while the non-incremental approach takes 1,020 seconds in median. We also discuss the impact of different variants of our strategy on the overall performance, providing insights into optimizations that are worthwhile.

Scientific progress comes from creating sound theories. However, current software engineering still mostly falls short of this goal, although its importance is widely accepted. Thus, in this paper, we discuss the importance of a successful interaction of empirical research with a strong theoretical basis and the ramifications this has. In particular, we will extensively discuss the implications on theory building and the empirical vs. theory interaction, etc. While not everything we will discuss is novel, we present a number of insights, which we at least did not see in software engineering literature. We strongly believe that a careful consideration of the insights discussed in this paper has the potential to lead to a significant improvement in software engineering research.

Transforming a clone-and-own (i.e., new product variants are created by copying and modifying existing artifacts) code structure and development process to a Software Product Line Engineering (PLE) approach is a tedious and error-prone task. Holistic tool support for such a process is highly desirable, especially to lower efforts and to speed up the transformation. Unfortunately, such a holistic toolchain for reverse engineering of variability, supporting variant-centric and platform-centric extraction approaches is not available. In this paper, we present a toolchain covering the first steps for moving a clone-and-own product development to a PLE approach. We validate the first prototype of the toolchain on a case study consisting of industrial firmware for smart motor controllers and we show that even this early prototype reduces time and effort for moving to a configurable platform approach in the sense of PLE.

In recent years, the development of systems for processing and analyzing large amounts of data (so-called Big Data) has become an important sub-discipline of software engineering. However, to date there exits no comprehensive summary of the specific idiosyncrasies and challenges that the development of Big Data systems imposes on software engineers. With this paper, we aim to provide a first step towards filling this gap based on our collective experience from industry and academic projects as well as from consulting and initial literature reviews. The main contribution of our work is a concise summary of 26 challenges in engineering Big Data systems, collected and consolidated by means of a systematic identification process. The aim is to make practitioners more aware of common challenges and to offer researchers a solid baseline for identifying novel software engineering research directions.

Ideally, a variability model is a correct and complete representation of product line features and constraints among them. Together with a mapping between features and code, this ensures that only valid products can be configured and derived. However, in practice the modeled constraints might be neither complete nor correct, which causes problems in the configuration and product derivation phases. This paper presents an approach to reverse engineer variability constraints from the implementation, and thus improve the correctness and completeness of variability models.

A number of SAT-based analysis concepts and tools for software product lines exist, that extract code dependencies in propositional logic from the source code assets of the product line. On these extracted conditions, SAT-solvers are used to reason about the variability. However, in practice, a lot of software product lines use integer-based variability. The variability variables hold integer values, and integer operators are used in the conditions. Most existing analysis tools can not handle this kind of variability; they expect pure Boolean conditions.

KernelHaven is an open infrastructure for Software Product Line (SPL) analysis. It is intended both as a production-quality analysis tool set as well as a research support tool, e.g., to support researchers in systematically exploring research hypothesis. For flexibility and ease of experimentation KernelHaven components are plug-ins for extracting certain information from SPL artifacts and processing this information, e.g., to check the correctness and consistency of variability information or to apply metrics. A configuration-based setup along with automatic documentation functionality allows different experiments and supports their easy reproduction.

The evolution of a Software Product Line (SPL) typically affects a variety of artifact types. The intensity (the frequency and the amount) in which developers change variability information in these different types of artifacts is currently unknown. In this paper, we present a fine-grained approach for the variability-centric extraction and analysis of changes to code, build, and variability model artifacts introduced by commits. This approach complements existing work that is typically based on a feature-perspective and, thus, abstracts from this level of detail. Further, it provides a detailed understanding of the intensity of changes affecting variability information in these types of artifacts. We apply our approach to the Linux kernel revealing that changes to variability information occur infrequently and only affect small parts of the analyzed artifacts. Further, we outline how these results may improve certain analysis and verification tasks during SPL evolution.

The study presented in this paper aims to provide evidence for the hypothesis that software product line research has been changing and that the works in industry and academia have diverged over time. We analysed a subset (140) of all (593) papers published at the Software Product Line Conference (SPLC) until 2017. The subset was randomly selected to cover all years as well as types of papers. We assessed the research type of the papers (academic or industry), the kind of evaluation (application example, empirical, etc.), and the application domain. Also, we assessed which product line life-cycle phases, development practices, and topics the papers address. We present an analysis of the topics covered by academic vs. industry research and discuss the evolution of these topics and their relation over the years. We also discuss implications for researchers and practitioners. We conclude that even though several topics have received more attention than others, academic and industry research on software product lines are actually rather in line with each other.

EASy-Producer is an open-source research toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In this tutorial, we will focus on its model-based development and implementation capabilities, which are realized by the Variability Instantiation Language (VIL) and the Variability Template Language (VTL). Further, we will provide a basic introduction into the Integrated Variability Modeling Language (IVML) in order to use the provided information of IVML variability models and configurations during instantiation defined with VIL and as part of the templates created with VTL.

EASy-Producer is an open-source research toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In this tutorial, we will focus on its (textual) variability modeling capabilities as well as its configuration and validation functionality. Further, we will provide an outlook on how EASy-Producer can be applied to variability instantiation.

Software product lines often use preprocessor statements as a basis for representing variability, which makes understanding the artifacts rather complex. An approach that has been proposed in the past to improve the understanding of code with preprocessor statements is formal concept analysis. This approach has been applied to a number of causes in reengineering. However, the lattices constructed by this approach can become rather large and complex. Hence, any approach that helps to reduce them can be beneficial to understanding the preprocessor-dependencies contained in the code. Here, we show how consistency analysis both within code variability and between code and a variability model can be used to reduce the complexity of a lattice, supporting the analysis of product-line code. We apply our approach to Linux, one of the largest open-source product lines, and analyze both multiple versions and different architectures. We show that our approach typically leads to reductions of the concept lattice and identify situations in which the savings can be rather significant. This leads to a reduction of any efforts for followup analysis or reverse engineering.

Creating product lines of Big Data stream processing applications introduces a number of novel challenges to variability modeling. In this paper, we discuss these challenges and demonstrate how advanced variability modeling capabilities can be used to directly model the topology of processing pipelines as well as their variability. We also show how such processing pipelines can be modeled, configured and validated using the Integrated Variability Modeling Language (IVML).

No abstract available.

The Linux kernel is often used as a real world case study to demonstrate novel Software Product Line Engineering research methods. An important point in this is often the analysis of the Kconfig semantics. However, we detected that the semantics of Kconfig is rather unclear and has many special cases, which are not documented in its short specification. We performed a systematic analysis to uncover the correct behaviour of Kconfig and present the results, which are necessary for applying semantically correct analyses. Further, we analyse existing analysis tools of the research community whether they are aware of the correct semantics of Kconfig. These analyses can be used for improving existing analysis tools as well as decision support for selecting an appropriate tool for a specific analysis. In summary we contribute to a better understanding of Kconfig in the research community to improve the validity of evaluations based on Linux.

Variability-rich Software Ecosystems need configuration capabilities just as in any product line. However, various additional capabilities are required, taking into account the software ecosystem characteristics. In order to address these specific needs, we developed the Integrated Variability Modeling Language (IVML) for describing configurations of variability-rich software ecosystems. IVML is a variability modeling and configuration language along with accompanying reasoning facilities.

The EASy-Producer product line environment is a novel open-source tool that supports the lightweight engineering of software product lines and variability-rich software ecosystems. It has been applied in several industrial case studies, showing its practical applicability both from a stability and a capability point of view. The tool set integrates both, interactive configuration capabilities and a DSL-based approach to variability modeling, configuration definition and product derivation. The goal of the tutorial is to provide the participants with an overview of the tool. However, the main focus will be on a brief introduction of the DSLs. After participating in the tutorial, the participants will understand the capabilities of the toolset and will have a basic practical understanding of how to use it to define software ecosystems and derive products from them.

The concept of adaptation and self-adaptation of systems, in particular at runtime has caught the attention of the research community at large, both inside the area of SPL as well as outside SPL in areas like models-at-runtime, selfadaptive systems, ubiquitous computing, etc.

Requirements engineering (RE) often entails interdisciplinary groups of people working together to find novel and valuable solutions to a complex design problem. In such situations RE requires creativity in a form where interactions among stakeholders are particularly important: collaborative creativity. However, few studies have explicitly concentrated on understanding collaborative creativity in RE, resulting in limited advice for practitioners on how to support this aspect of RE. This paper provides a framework of factors characterising collaborative creative processes in RE. These factors enable a systematic investigation of the collaboratively creative nature of RE. They can potentially guide practitioners when facilitating RE efforts, and also provide researchers with ideas on where to focus when developing methods and tools for RE.

Industrial variability models tend to grow in size and complexity due to ever-increasing functionality and complexity of software systems. Some authors report on variability models specifying several thousands of variabilities. However, traditional variability modeling approaches do not seem to scale adequately to cope with size and complexity of such models. Recently, textual variability modeling languages have been advocated as one scalable solution.

In emerging domains such as ubiquitous computing, service robotics, unmanned space & water exploration, or medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality on tight schedules ever more economically.

Why does it change?

Globalization is a key challenge in the modern software industry. It covers issues like developing software in joint teams all around the world or developing software that needs to be used in many different countries and different cultural environments. In this tutorial, we focus on this second aspect of globalization: developing software, in particular variants of software for markets around the world.

In Software Product Line Engineering, variability modeling plays a crucial rule. Over the years, a couple of different modeling paradigms with a plethora of different approaches have been proposed. However, only little attention was spent to compare these concepts. In this paper, we compare the capabilities and expressiveness of basic feature modeling with basic decision modeling.

Most research in product line engineering focuses on the domain engineering phase. However, the ultimate reason of any Software Product Line Engineering (SPLE) activity is the derivation of products and thus application engineering. In this research we focus on how the configuration activity within application engineering can be supported to achieve sufficient efficiency.

In emerging domains such as ubiquitous computing, service robotics, unmanned space and water exploration, and medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality, on tight deadlines, and more economically.

Globalization is a key challenge in the modern software industry. It covers issues like developing software in joint teams all around the world or developing software that needs to be used in many different countries and different cultural environments. In this tutorial, we focus on this second aspect of globalization: developing software, in particular variants of software for markets around the world.

The traditional focus of Product Line Engineering (PIE) is on the customization of whole software solutions. So far, the combination of cloud computing with PLE techniques has hardly been discussed. In this paper, we discuss different approaches to cloud computing and their relation to product line technologies. We also describe both, specific opportunities and drawbacks, of these approaches.

Product lines are usually built for the long term in order to repay the initial investment. While long-term stable software systems are already hard, if they are developed individually, it is even harder for complete product lines. At the time a new product line is created, the details of future product line characteristics are typically not known, no matter how well and detailed scoping and planning is done. Thus, any product line needs to evolve and adapt over time to incorporate new customer requirements as well as new technology constraints.

This workshop on services, clouds, and alternative design strategies for variant-rich software systems brings together researchers and practitioners that are interested in or have been working on variant-rich software systems.

In emerging domains such as ubiquitous computing, service robotics, unmanned space and water exploration, and medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality, on tight deadlines, and more economically. In addition, modern computing and network environments demand a higher degree of adaptability from their software systems. Computing environments, user requirements, and interface mechanisms between software and hardware devices such as sensors can change dynamically during runtime. Because it's impossible to foresee all the functionality or variability an SPL requires, there is a need for dynamic SPLs that produce software capable of adapting to fluctuations in user needs and evolving resource constraints. DSPLs bind variation points at runtime, initially when software is launched, to adapt to the current environment, as well as during operation to adapt to changes in the environment. Although traditional SPL engineering recognizes that variation points are bound at different stages of development, and possibly also at runtime, it typically binds variation points before delivery of the software. In contrast, DSPL engineers typically aren't concerned with pre-runtime variation points. However, they recognize that in practice mixed approaches might be viable, where some variation points related to the environment's static properties are bound before runtime and others related to the dynamic properties are bound at runtime. In DSPLs, monitoring the current situation and controlling the adaptation are thus central tasks. The user, the application, or generic middleware can perform these tasks manually or automatically. Although dynamic software product lines build on the central ideas of SPLs, there are also differences. For example, the focus on understanding the market and letting the SPL drive variability analysis is less relevant to DSPLs, whose primary goal is to adapt to variations in individual needs and situations rather than market forces. In summary, a DSPL has many, if not all, of the following properties:• dynamic variability configuration and binding at runtime, • changes binding several times during its lifetime, • variation points change during runtime: variation point addition (by extending one variation point), • deals with unexpected changes (in some limited way), • deals with changes by users, such as functional or quality requirements, • context awareness (optional) and situation awareness, • autonomic or self-adaptive properties (optional), • automatic decision making (optional), and• individual environment/context situation instead of a "market." Given these characteristics, DSPLs benefits from research in several related areas. For example, situation monitoring and adaptive decision making are also characteristics of autonomic computing, and the DSPL approach can be seen as one among several to building self-adapting/managing/healing systems. In addition, dynamically reconfigurable architectures provide mechanisms to rebind variation points at runtime, while multiagent systems, which focus on the use of agents and communities of agents, are particularly useful for evolving systems such as DSPLs [1].

In this paper, we describe EASy-producer, a prototypical production environment for software product lines (SPL), in particular for the realization of adaptive systems and dynamic SPL.

In emerging domains such as ubiquitous computing, service robotics, unmanned space and water exploration, and medical and life-support devices, software is becoming increasingly complex with extensive variation in both requirements and resource constraints. Developers face growing pressure to deliver high-quality software with additional functionality, on tight deadlines, and more economically.

The SPLC doctoral symposium provides an opportunity for young researchers to get intensive feedback on their Ph.D. research. The symposium is open to all areas of product line engineering.

Software Product Line Engineering is intimately connected with the need for optimizing the economic situation of an organization. The MESPUL workshop provides a forum for the exchange of practitioners and researchers on the economic dimension of software product lines like measurement, planning, or optimization of reuse potential.

Basically all companies today go beyond the development of single products and offer set(s) of similar and related products. In marketing, one such set is often called a product line. Nevertheless, still today most products are not yet engineered as product lines, i.e., they are not yet derived from a single platform. In this paper, we explore the relation of these two forms of product lines. It is shown that under certain circumstances engineered and marketed software product line subsume different products. This paper shows how these two perspectives differ and why a difference in products between these perspectives may be appropriate from a company perspective. Finally, it is argued that activities currently subsumed under product management and scoping should be closely coordinated, allowing companies to optimize their product portfolios since decision-making is facilitated

The key idea of software product lines is the integrated development of a set of products, exploiting commonalities and variabilities among the products to achieve high levels of reuse. The commercial potential of this approach has already been demonstrated in numerous case studies. However, while requirements management tools are already widespread, the range of professional tool support for product line development is still very poor. In this paper we analyze the question whether and how existing requirement management tools can be seamlessly extended to product line development. We present a general approach, which has been prototyped based on the DOORS requirements management tool and leads to the REMAP-tool extension.

Over the last few years, product line engineering has become a major theme in software engineering research, and is increasingly becoming a central topic of software engineering practice in the embedded domain.Migrating towards a product line approach is not an easy feat. It is even less so, if it is done under tight technology constraints in an embedded environment. It becomes even more difficult if the transition directly aims at integrating two product families into a single product population. In this paper, we discuss our experiences with a project where we successfully dealt with these difficulties and achieved a successful product line transition. In our paper we strongly emphasize the role of technology transfer, as many facets of product line know-how had to be transferred to guarantee a complete transition to product line engineering. From the experiences of this project many lessons learned can be deduced, which can be transferred to different environments.

Product Line Engineering is a recent approach to software development that specifically aims at exploiting commonalities and systematic variabilities among functionally overlapping systems in terms of large scale reuse. Taking full advantage of this potential requires adequate planning and management of the reuse approach as otherwise huge economic benefits will be missed due to an inappropriate alignment of the reuse infrastructure.Key in product line planning is the scoping activity, which aims at focussing the reuse investment where it pays. Scoping actually happens on several levels in the process: during the domain analysis step (analysis of product line requirements) a focusing needs to happen just like during the decision of what to implement for reuse. The latter decision has also important ramifications for the development of an appropriate reference architecture as it provides the reusability requirements for this step.In this paper, we describe an integrated approach that has been developed, improved, and validated over the last few years. The approach fully covers the scoping activities of domain scoping and reuse infrastructure scoping and was validated in several industrial case studies.

A key activity in product line development is to define and structure the product portfolio which shall be the basis for product line development. We present an approach that aims at supporting this activity. This approach also provides a conceptual structuring of the product line in terms of the features and technical domains that are relevant to it. This structure then provides a basis for the planning of the actual product line development and for architecture definition. We also discuss the validation of our approach in the context of some case studies.

Software Product Lines is still a new field within software reuse that aims at large-scale, systematic reuse. Huge benefits regarding the reduction of time-to-markets, reduction of effort, and quality improvement have been reported as a result of adopting a product line approach. Since a product line program involves major investments, considerable risks are associated with it. Thus, it is important to evaluate at the start of a product line project, i.e., before the major investments are performed, its potential benefits and risks. In this paper we describe an approach that allows to identify the benefits and risks in a systematic manner, thus enabling the early development of risk-avoiding measures. As opposed to other techniques our approach supports the identification of subdomains that are particular appropriate for systematic reuse and by means of the detailed evaluation enables trade-off decisions on where to invest for reuse.

Describes, using the Quality Improvement Paradigm (QIP), how an improvement project aimed at improving the modeling and documentation approach of a medium-sized company (Markant Su/spl uml/dwest Software und Dienstleistungs GmbH) was conducted. We discuss the new modeling approach, which may serve for other companies as a template for deriving their own adapted approach. Further, we illustrate our insights from this project that can help in future technology transfer projects. A major characteristic of this project was that it was embedded in a long-term consulting relationship.

S.34-43 : Ill., Lit.