abstract

Software product line techniques encourage the reuse and adaptation of software components for creating customized products or software systems. These different product variants have commonalities and differences, which are managed by variability modeling. Over the past three decades, both academia and industry have developed numerous variability modeling methods, each with its own advantages and disadvantages. Many of these methods have demonstrated their utility within specific domains or applications. However, comprehending the capabilities and differences among these approaches to pinpoint the most suitable one for a particular use case remains challenging. Thus, new modeling techniques and tailored tools for handling variability are frequently created. Transitioning between variability models through transformations from different approaches can help in understanding the benefits and drawbacks of different modeling approaches. However, implementing such transformations presents challenges, such as semantic preservation and avoiding information loss. TRAVART is a tool that helps with transitioning between different approaches by enabling the transformation of variability models into other variability models of different types. This paper discusses the challenges for such transformations between UVL and IVML. It also presents a one-way transformation from the UVL to IVML with as little information loss as possible

abstract

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 trade-offs between these CATs aiming at a systematic discussion of the range of multi-paradigm control for a SaS.

abstract

The EXPLAIN project (EXPLanatory interactive Artificial intelligence for INdustry) aims at enabling explainable Machine Learning in industry. MLOps (Machine Learning Operations) includes tools, practices, and processes for deploying ML (Machine Learning) in production. These will be extended by explainability methods as part of the project.

This study aims to determine to what extent MLOps is implemented by four project partner companies. Further, the study describes the ML use cases, MLOps software architecture, tools, and requirements in the companies perspective. Besides, requirements for a novel MLOps software architecture, including explainability methods, are collected.

As a result the interviews show that each of the interviewed industry partners use MLOps differently. Different tools and architectural patterns are used depending on the particular use case. Overall, most information we gathered focused on architecture decisions in the MLOps tool landscape used by the interviewed companies.

abstract

In this work, we summarize our journal paper published in Empirical Software Engineering(EMSE) in 2022 [Kr22]. Verification approaches for Software Product Lines (SPL) aim at detectingvariability-related defects and inconsistencies. In general, these analyses take a significant amountof time to provide complete results for an entire, complex SPL. If the SPL evolves, these resultspotentially become invalid, which requires a time-consuming re-verification of the entire SPL foreach increment.

However, in previous work we showed that variability-related changes occur rather infrequently andtypically only affect small parts of a SPL. In this paper, we utilize this observation and presentan incremental dead variable code analysis as an example for incremental SPL verification, whichachieves significant performance improvements. It explicitly considers changes and partially updatesits previous results by re-verifying changed artifacts only. We apply this approach to the Linuxkernel demonstrating that our fastest incremental strategy takes only 3.20 seconds or less for most ofthe changes, while the non-incremental approach takes 1,020 seconds in median. We also discussthe impact of different variants of our strategy on the overall performance, providing insights intooptimizations that are worthwhile.

abstract

The evolution of a Software Product Line (SPL) typically affects multiple kinds of artifacts. The intensity (frequency and amount) in which developers change variability information in them was unknown, until we introduced a fine-grained approach for the variability-centric extraction and analysis of changes to code, build, and variability model artifacts. Its application to the commits of the Linux kernel revealed that changes to variability information occur infrequently and only affect small parts of the analyzed artifacts. Further, we outlined how these results may improve certain analysis and verification tasks during SPL evolution. However, the sole analysis of a single SPL did not allow for generic conclusions.

In this paper, we extend our previous work to a comparative evolution analysis of four SPLs. We provide a detailed analysis of the individual intensities of variability changes by applying our updated approach to each SPL. A comparison of these results confirms our findings of infrequent and small changes to variability information in our previous study. However, differences in the details of these changes exist, which we cannot explain solely by the characteristics of the SPLs or their development processes. We  discuss their implications on supporting SPL evolution and on our previous optimization proposals.

abstract

Um den effektiven und effizienten Betrieb von Cyberphysischen Produktionssystemen (CPPSen) sicherzustellen, spielt Software eine zunehmend wichtige Rolle. Die enormen Fortschritte bei Softwareentwicklungsmethoden, welche in den letzten Jahren erzielt wurden, scheinen jedoch die aktuellen Herausforderungen der Industrie nicht zu erfüllen, weil diese die Industrie nicht oder nur langsam erreichen. In diesem Beitrag werden die Herausforderungen für die Softwareentwicklung in CPPSen aus Sicht von neun Industrievertretern aus acht europäischen Unternehmen unterschiedlicher Größe diskutiert. Um den digitalen Transformationsprozess für eine zukunftsfähige Produktion zu begleiten, wurden aus den beschriebenen Herausforderungen Perspektiven für die Forschung erarbeitet. Die Umsetzung dieser Ziele ist vor dem Hintergrund von ökonomischen, sozialen und Nachhaltigkeitsanforderungen notwendig.

abstract

An important part of the Industry 4.0 vision is the use of machine learning (ML) techniques to create novel capabilitiesand flexibility in industrial production processes. Currently, there is a strong emphasis on MLOps as an enabling collectionof practices, techniques, and tools to integrate ML into industrial practice. However, while MLOps is often discussed inthe context of pure software systems, Industry 4.0 systems received much less attention. So far, there is only little researchfocusing on MLOps for Industry 4.0. In this paper, we discuss whether MLOps in Industry 4.0 leads to significantly dif-ferent challenges compared to typical Internet systems. We provide an initial analysis of MLOps approaches and identifyboth context-independent MLOps challenges (general challenges) as well as challenges particular to Industry 4.0 (specificchallenges) and conclude that MLOps works very similarly in Industry 4.0 systems to pure software systems. This indicatesthat existing tools and approaches are also mostly suited for the Industry 4.0 context.

abstract

MLOps have become an increasingly important topic in the deployment of machine learning in production. While Machine Learning Operations was predominantly used as a buzzword for methods in Machine Learning (ML) for the time being, since 2019, they are increasingly used in the context of deploying ML algorithms. This report is a protocol for a systematic literature review (SLR) that aims to determine the MLOps terminology and identify related activities. A further goal of the SLR is to identify where MLOps can be linked to classical software engineering. In addition, related automation techniques are considered.

The projected literature review aims to draw conclusions from papers that explicitly use the term MLOps or Machine Learning Operations with the objective to provide the necessary common baseline for future MLOps research and practice. This report thoroughly documents the SLR method, processes, and data material. We also gathered all relevant data to comprehend MLOps fully. Through our comprehensive analysis, we hope to
provide valuable insights and recommendations for optimizing MLOps practices.

abstract

Distributed and central control are two complementary paradigms to establish self-adaptation in software systems. Both approaches have their individual benefits and drawbacks, which lead to significant trade-offs regarding certain software qualities when designing such systems. The significance of these trade-offs even increases the more complex the target system becomes. In this paper, we present our work-in-progress towards an integrated control approach, which aims at providing the best of both control paradigms. We present the basic concepts of this multi-paradigm approach and outline its inherent support for complex system hierarchies. Further, we illustrate the vision of our approach using application scenarios from the smart energy grid as an example for self-adaptive systems of systems.

abstract

An important part of the Industry 4.0 vision is the use of machine learning (ML) techniques to create novel capabilities and flexibility in industrial production processes. Currently, there is a strong emphasis on MLOps as an enabling collection of practices, techniques, and tools to integrate ML into industrial practice. However, while MLOps is often discussed in the context of pure software systems, Industry 4.0 systems received much less attention. So far, there is no specialized research for Industry 4.0 in this regard. In this position paper, we discuss whether MLOps in Industry 4.0 leads to significantly different challenges compared to typical Internet systems. We identify both context-independent MLOps challenges (general challenges) as well as challenges particular to Industry 4.0 (specific challenges) and conclude that MLOps works very similarly in Industry 4.0 systems to pure software systems. This indicates that existing tools and approaches are also mostly suited for the Industry 4.0 context.

abstract

This extended abstract summarizes our eponymous journal paper [1] published first in Empirical Software Engineering (EMSE).

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.

abstract

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.

abstract

Collective Adaptive Systems (CAS) achieve high resilience by providing distributed self-* properties through autonomous elements. While they are very beneficial for achieving high reliability, they are more difficult for dealing with targeted external inputs or ensuring globally optimal results. It is easier to achieve these properties with centralized approaches. Ideally, one could combine the benefits of collective adaptive systems with aspects of central control to achieve the best of both paradigms. While such combinations have already been shown in previous work, here, we aim at a systematic discussion of the range of approaches to integrate both control paradigms. As a result, we present a taxonomy of control action types, which describes how a central control unit can interact with a CAS to achieve the desired overall behavior, providing a first step towards CAS control patterns and identifying the involved trade-offs. Ideally, one could combine the benefits of collective adaptive systems with aspects of central control to achieve the best of both paradigms. While such combinations have already been shown in previous work, here, we aim at a systematic discussion of the range of approaches to integrate both control paradigms. As a result, we present a taxonomy of control action types, which describes how a central control unit can interact with a CAS to achieve the desired overall behavior, providing a first step towards CAS control patterns and identifying the involved trade-offs.

abstract

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.

abstract

Adaptive systems react to changes in their environment by changing their behavior. Identifying these needed adaptations is very difficult, but central to requirements elicitation for adaptive systems. As the necessary or potential adaptations are typically not obvious to the stakeholders, the problem is how to effectively elicit adaptation-relevant information. One approach is to use creativity techniques to support the systematic identification and elicitation of adaptation requirements. In particular, here, we analyze a set of creativity triggers defined for systematic exploration of potential adaptation requirements. We compare these triggers with brainstorming as a baseline in a controlled experiment with 85 master students. The results indicate that the proposed triggers are suitable for the efficient elicitation of adaptive requirements and that the 15 trigger questions produce significantly more requirements fragments than solo brainstorming.

abstract

This is a summary of an article published in the Information and Software Technology Journal in 2019 (see Bibliography) describing a domain model we developed to structure and systematize the field of software monitoring as well as a reference architecture to support developing software monitoring approaches.

abstract

Product line engineering emerged from a fruitful interaction of applied research in academia, industry research, and software engineering practice. SPLC was created as the primary venue to exchange ideas on this emerging topic and integrate the communities. Yet, today, SPLC is mostly regarded as an academic conference with little industry participation. Since a strong integration of academia and industry is often seen positive, here, we try to better understand motivations for practitioners to visit academic conferences like SPLC and the impact this has on such conferences. This analysis is based on nine systematic interviews with practitioners and researchers, who have been members of the SPLC community and other leading software engineering communities for a long time. Our preliminary results clarify the relevance and interest of practitioners and researchers to exchange knowledge and learn when attending scientific software engineering conferences such as SPLC. Yet, the results also highlight the differences between the goals of industry and academic conference participants, which often lead to inefficiencies and even barriers for constructive interaction at scientific conferences such as SPLC. We use this as a basis for pointing out further discussion points, both from the perspective of the interviewees as well as the authors.

abstract

[Context and motivation] Current and future systems have to operate in complex and dynamic environments. An adaptive system addresses these challenges as it monitors its environment and reacts by changing its behavior. [Question/Problem] Representations of adaptive requirements (e.g., at runtime) and strategies for decision-making have gained a lot of interest in past and current research. Yet, there is a lack of support for elicitation of requirements and environmental information for adaptive systems.

[Principal ideas/results] We suggest to apply creativity techniques to elicit adaptation requirements and make use of situations to negotiate them (a situation represents the state of the system and its environment at a particular instance of time). [Contributions] In this paper, we introduce AdaptationExplore, a process for the development of adaptive systems, which supports engineers in particular during the early phases. The results of a pilot study are reported. 37 Master students applied the process on different cases. The study provides first positive experiences on the effectiveness and applicability of the process.

abstract

Abstract. [Context & Motivation] Adaptive systems are an important research area. The dominant reason for adaptivity in systems are changes in the environment. Thus, it is an important question how to model the environment and how to determine the necessary information on this environment in the requirements engineering phase. [Question/ Problem] There is so far relatively little explicit study of the notion of environment models in software engineering research. [Principal ideas/ Results] In this paper, we present a systematic literature review with the goal to determine the state of the art in environment modeling for adaptive systems, in particular from a requirements perspective. We discuss the goals of the approaches, the modeling concepts, as well as the methodology aspects of environment modeling in our survey. [Contribution] As major result of our survey, we provide a meta-model of existing environment modeling concepts. As a negative finding – and a research opportunity – we find that so far methodological aspects of environment modeling have received very little attention.

abstract

Program slicing is an important technique for various follow-up activities like program understanding or feature identification. So far only little work exists on program slicing of product lines. A key challenge in this context is to identify a slice including the implementation as well as the (relevant) variability information. It is our goal to create a program slicing approach to identify semantically related lines of code in a C-based software product line, using the C-Preprocessor as the basis for variability implementation. However, at the time of our research no existing approach was able to produce a program slice that fully preserves the structure of the preprocessor code. Thus, the variability structure in the slice was no longer intact. This is problematic as the desired slice should be a real subset of the product line implementation without modification of the syntax. Thus, we had to create a new syntax-preserving variability-aware slicing technique. In this paper, we report our experiences with the conception and implementation of this technique. We highlight the key challenges and our proposed solutions to foster discussions and future research about the handling of variability in static analysis.

abstract

Context: Software metrics, as one form of static analyses, is a commonly used approach in software engineering in order to understand the state of a software system, in particular to identify potential areas prone to defects. Family-based techniques extract variability information from code artifacts in Software Product Lines (SPLs) to perform static analysis for all available variants. Many different types of metrics with numerous variants have been defined in literature. When counting all metrics including such variants, easily thousands of metrics can be defined. Computing all of them for large product lines can be an extremely expensive process in terms of performance and resource consumption.

Objective: We address these performance and resource challenges while supporting customizable metric suites, which allow running both, single system and variability-aware code metrics.

Method: In this paper, we introduce a partial parsing approach used for the efficient measurement of more than 42,000 code metric variations. The approach covers variability information and restricts parsing to the relevant parts of the Abstract Syntax Tree (AST).

Conclusions: This partial parsing approach is designed to cover all relevant information to compute a broad variety of variability-aware code metrics on code artifacts containing annotation-based variability, e.g., realized with C-preprocessor statements. It allows for the flexible combination of single system and variability-aware metrics, which is not supported by existing tools. This is achieved by a novel representation of partially parsed product line code artifacts, which is tailored to the computation of the metrics. Our approach consumes considerably less resources, especially when computing many metric variants in parallel.

abstract

This summary refers to the paper Enactment of adaptation in data stream processing with latency implications – A systematic literature review. This paper is a journal paper published in Information and Software Technology (IST) in July 2019. Runtime adaptation in stream processing plays a significant role in supporting the optimization of data processing tasks. In recent years, runtime adaptation, particularly its enactment, has received significant interest in scientific literature. However, so far no categorization of the enactment approaches for runtime adaptation in stream processing has been established. This paper presents a systematic literature review (SLR), where we identify and characterize different approaches towards the enactment of runtime adaptation in stream processing with a main focus on latency as quality dimension. We discovered 75 relevant papers out of 244 papers from the search. We identified 17 different enactment categories and developed a taxonomy to characterize all possible enactment approaches. We extracted the realization techniques of each identified enactment approach and classified them into categories. Furthermore, we identified 9 categories of processing problems, 6 adaptation goals, 9 evaluation metrics and 12 evaluation parameters from the identified enactment approaches. The research interest on enactment approaches has significantly increased in recent years. The most commonly applied enactment approaches are parameter adaptation to tune parameters or settings of the processing, load balancing used to re-distribute workloads, and processing scaling to dynamically scale up and down the processing.

abstract

This tutorial introduces the EASy-Producer product line environment. EASy-Producer is an open-source toolset for engineering product lines, variability-rich software ecosystems, and dynamic software product lines. In particular, it features a variability modeling and a variability implementation DSL. It has been applied in several industrial case studies and research projects showing its practical applicability both from a stability and a capability point of view. While the tool-set also includes an interactive approach to product line definition and configuration through DSLs, the focus of this tutorial will be on the DSL-based techniques. We cover both the modeling of software product lines using the Integrated Variability Modeling Language (IVML) and its underlying conceptual approach, which differs from traditional feature modeling, but we will also provide an overview of the approach to variability instantiation with EASy-Producer (using the Variability Instantiation Language (VIL)).

abstract

Product lines of software-intensive systems have a great diversity of features and products, which leads to vast design spaces that are difficult to explore. In addition, finding optimal product line system architectures usually requires a consideration of several quality trade-offs at once, involving both product-level as well as product-line-wide criteria. This challenge cannot be solved manually for all but the smallest problems, and can therefore benefit from automated support. In this paper we propose ADOOPLA, a tool-supported approach for the optimization of product line system architectures. In contrast to existing approaches where product-level approaches only support product-level criteria and product-line oriented approaches only support product-line-wide criteria, our approach integrates criteria from both levels in the optimization of product line architectures. Further, the approach can handle multiple objectives at once, supporting the architect in exploring the multi-dimensional Pareto-front of a given problem. We describe the theoretical principles of the ADOOPLA approach and demonstrate its application to a simplified case study from the automotive domain.

abstract

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 introduce its (textual) variability modeling capabilities realized by the Integrated Variability Modeling Language (IVML) and its model-based development and implementation capabilities, which are realized by the Variability Instantiation Language (VIL) and the Variability Template Language (VTL).

abstract

This summary refers to the paper Metrics for analyzing variability and its implementation in software product lines: A systematic literature review. It was online first in 2018 and was finally published 2019 in the Information and Software Technology (IST) journal.

The use of metrics for assessing software products and their qualities is well established in traditional Software Engineering (SE). However, such traditional metrics are typically not applicable to Software Product Line (SPL) engineering as they do not address variability management, a key part of product line engineering. Over time, various specialized product line metrics for SPLs have been described in literature, but no systematic description of these metrics and their characteristics is currently available.

This paper presents a systematic literature review, where we identify metrics explicitly designed for variability models, code artifacts, and metrics taking both kinds of artifacts into account. This captures the core of variability management for product lines. We discovered 42 relevant papers reporting 147 metrics designed for SPLs.We provide a categorization of these metrics and discuss problematic issues regarding their definitions. We also systematically assess the evaluation status of the metrics showing a current lack of high-quality evaluation in the field. Researchers and practitioners can benefit from the published catalog of variability-aware metrics

abstract

Acommonproblem in program analysis is to identify semantically related statements in programs, for example, which statements change the value of a variable, or implement a specific feature or functionality. This is a very challenging task for large programs and gets even more complicated in the presence of variability implementations like #ifdef-annotations. Program slicing is a technique that can be used to aid developers with this challenge. But while slicing is a well-established technique for individual programs, there has been so far only little work on program slicing of product lines.

Here,we introduce a static-analysis approach for semantic slicing of product lines. Our approach introduces the novel concept of a variability-aware code property graph, which combines information about code properties (like statement type) and syntactical structure with data- and control-flow information. This graph is then traversed to gather semantically-related lines of code for a given entry node.We demonstrate our approach with a C-example, including preprocessor statements.

abstract

We present preliminary insights into the perception of researchers and practitioners of the software product line (SPL) community on previous, current, and future research efforts. We were particularly interested in up-and-coming and outdated topics and whether the views of academics and industry researchers differ. Also, we compared the views of the community with the results of an earlier literature survey published at SPLC 2018. We conducted a questionnaire-based survey with attendees of SPLC 2018. We received 33 responses (about a third of the attendees) from both, very experienced attendees and younger researchers, and from academics as well as industry researchers. We report preliminary findings regarding popular and unpopular SPL topics, topics requiring further work, and industry versus academic researchers’ views. Differences between academic and industry researchers become visible only when analyzing comments on open questions. Most importantly, while topics popular among respondents are also popular in the literature, topics respondents think require further work have often already been well researched. We conclude that the SPL community needs to do a better job preserving and communicating existing knowledge and particularly also needs to widen its scope.

abstract

In automotive system design, system architects increasingly use model-based approaches for defining product line architectures (PLAs). This trend is strongly supported by the emergence of domain standards like EAST-ADL and AUTOSAR that facilitate a system design approach based on systematic reuse. In our work, we focus on the automated exploration of PLA design spaces by means of multi-objective optimization and ask what are challenges that stakeholders face as part of this design task. Optimizing PLA design spaces shares certain challenges with conventional architecture optimization, like conflicting quality goals and potentially vast design spaces. However, PLA optimization exacerbates these challenges by an additional layer of complexity in the system architecture, due to product line variability in the system. Our main focus in this paper is on achieving a better understanding of the stakeholder requirements on a support infrastructure for automated PLA design space exploration based on PLA system models. We also address the challenges that stakeholders must overcome when integrating such an approach into an existing process landscape. For that purpose, we conducted a study with automotive industry experts and analyzed the findings using the qualitative data analysis methods of Grounded Theory. Based on the study results, we derive a set of challenges for the realization and integration of automated and semi-automated PLA design space exploration in industrial environments.

abstract

This summary refers to the paper Metrics for analyzing variability and its implementation in software product lines: A systematic literature review [EYS19]. The paper was online first in 2018 and was finally published 2019 in the Information and Software Technology (IST) journal.

abstract

This extended abstract summarizes the paper Identifying the Intensity of Variability Changes in Software Product Line Evolution [KGS18] published in the proceedings of the SPLC 2018 [BBB+18].

abstract

Variability-aware metrics are designed to measure qualitative aspects of software product lines. As we identified in a prior SLR [6], there exist already many metrics that address code or variability separately, while the combination of both has been less researched. MetricHaven fills this gap, as it extensively supports combining information from code files and variability models. Further,we also enable the combination of well established single system metrics with novel variability-aware metrics, going beyond existing variabilityaware metrics. Our tool supports most prominent single system and variability-aware code metrics. We provide configuration support for already implemented metrics, resulting in 23,342 metric variations. Further, we present an abstract syntax tree developed for MetricHaven, that allows the realization of additional code metrics.

abstract

During the three decades since the invention of the first variability modeling approach [27], there have been multiple attempts to introduce advanced variability modeling capabilities. More recently, there has been increased attention on textual variability modeling languages. In this paper,we summarize the main capabilities of state of the art textual variability modeling languages, based on [23], including some updates regarding more recent work.We also provide a short discussion of some additional concerns that are relevant when designing (textual) variability modeling languages. From this perspective, the paper also summarizes relevant contributions the authors made to the field in earlier research.

abstract

Variation is central to today’s software development. There are two fundamental dimensions to variation: Variation in time refers to the fact that software exists in numerous revisions that typically replace each other (i.e., a newer version supersedes an older one). Variation in space refers to differences among variants that are designed to coexist in parallel. There are numerous analyses to cope with variation in space (i.e., product-line analyses) and others that cope with variation in time (i.e., regression analyses). The goal of this work is to discuss to which extent product-line analyses can be applied to revisions and, conversely, where regression analyses can be applied to variants. In particular, we discuss requirements to existing analyses and variability representations that are required for those applications. In addition, we discuss which combinationsof product-line and regression analyses are feasible. The overall goal is to increase the efficiency of analyses by exploiting the inherent commonality between variants and revisions.

abstract

Experimentation with software prototypes plays a fundamental role in software engineering research. In contrast to many other scientific disciplines, however, explicit support for this key activity in software engineering is relatively small. While some approaches to improve this situation have been proposed by the software engineering community, experiments are still very difficult and sometimes impossible to replicate.In this paper, we propose the concept of an experimentation workbench as a means of explicit support for experimentation in software engineering research.

In particular, we discuss core requirements that an experimentation workbench should satisfy in order to qualify as such and to offer a real benefit for researchers. Beyond their core benefits for experimentation, we stipulate that experimentation workbenches will also have benefits in regard to reproducibility and repeatability of software engineering research. Further, we illustrate this concept with a scenario and a case study, and describe relevant challenges as well as our experience with experimentation workbenches.

abstract

[Context] Complex and heterogeneous software systems need to be monitored as their full behavior often only emerges at runtime, e.g., when interacting with other systems or the environment. Software monitoring approaches observe and check properties or quality attributes of software systems during operation. Such approaches have been developed in diverse communities for various kinds of systems and purposes. For instance, requirements monitoring aims to check at runtime whether a software system adheres to its requirements, while resource or performance monitoring collects information about the consumption of computing resources by the monitored system. Many venues publish research on software monitoring, often using diverse terminology, and focusing on different monitoring aspects and phases. The lack of a comprehensive overview of existing research often leads to re-inventing the wheel. [Objective] We provide a domain model to structure and systematize the field of software monitoring, starting with requirements and resource monitoring. [Method] We developed an initial domain model based on (i) our extensive experiences with requirements and resource monitoring, (ii) earlier efforts to develop a comparison framework for monitoring approaches, and (iii) an earlier systematic literature review on requirements monitoring frameworks. We then systematically analyzed 47 existing requirements and resource monitoring approaches to iteratively refine the domain model and to develop a reference architecture for software monitoring approaches. [Results] Our domain model covers the key elements of monitoring approaches and allows analyzing their commonalities and differences. Together with the reference architecture, our domain model supports the development of integrated monitoring solutions. We provide details on 47 approaches we analyzed with the model to assess its coverage. We also evaluate the reference architecture by instantiating it for five different monitoring solutions. [Conclusions] We conclude that requirements and resource monitoring have more commonalities than differences, which is promising for the future integration of existing monitoring solutions.

abstract

[Context] Stream processing is a popular paradigm to continuously process huge amounts of data. Runtime adaptation plays a significant role in supporting the optimization of data processing tasks. In recent years runtime adaptation has received significant interest in scientific literature. However, so far no categorization of the enactment approaches for runtime adaptation in stream processing has been established. [Objective] This paper identifies and characterizes different approaches towards the enactment of runtime adaptation in stream processing with a main focus on latency as quality dimension. [Method] We performed a systematic literature review (SLR) targeting five main research questions. An automated search, resulting in 244 papers, was conducted. 75 papers published between 2006 and 2018 were finally included. From the selected papers, we extracted data like processing problems, adaptation goals, enactment approaches of adaptation, enactment techniques, evaluation metrics as well as evaluation parameters used to trigger the enactment of adaptation in their evaluation. [Results] We identified 17 different enactment approaches and categorized them into a taxonomy. For each, we extracted the underlying technique used to implement this enactment approach. Further, we identified 9 categories of processing problems, 6 adaptation goals, 9 evaluation metrics and 12 evaluation parameters according to the extracted data properties. [Conclusion] We observed that the research interest on enactment approaches to the adaptation of stream processing has significantly increased in recent years. The most commonly applied enactment approaches are parameter adaptation to tune parameters or settings of the processing, load balancing used to re-distribute workloads, and processing scaling to dynamically scale up and down the processing. In addition to latency, most adaptations also address resource fluctuation / bottleneck problems. For presenting a dynamic environment to evaluate enactment approaches, researchers often change input rates or processing workloads.

abstract

Context: Software Product Line (SPL) development requires at least concepts for variability implementation and variability modeling for deriving products from a product line. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but existing metrics are typically not applicable to SPLs as they do not address variability management. Over time, various specialized product line metrics have been described in literature, but no systematic description of these metrics and their characteristics is currently available.

Objective: This paper describes and analyzes variability-aware metrics, designed for the needs of software product lines. More precisely we restrict the scope of our study explicitly to metrics designed for variability models, code artifacts, and metrics taking both kinds of artifacts into account. Further, we categorize the purpose for which these metrics were developed. We also  analyze to what extent these metrics were evaluated to provide a basis for researchers for selecting adequate metrics. Method: We conducted a systematic literature review to identify variability-aware implementation metrics. We discovered 42 relevant papers reporting metrics intended to measure aspects of variability models or code artifacts. Results: We identified 57 variability model metrics, 34 annotation-based code metrics, 46 code metrics specific to composition-based implementation techniques, and 10 metrics integrating information from variability model and code artifacts. For only 31 metrics, an evaluation was performed assessing their suitability to draw any qualitative conclusions.

Conclusions: We observed several problematic issues regarding the definition and the use of the metrics. Researchers and practitioners benefit from the catalog of variability-aware metrics, which is the first of its kind. Also, the research community benefits from the identified observations in order to avoid those problems when defining new metrics.

abstract

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.

abstract

The creation of product line architectures is a difficult and complex task. The resulting architectures must support the required system variabilities as well as further quality attributes. In the automotive domain, product lines of software-intensive system models have a great diversity of products, which leads to vast design spaces. Finding optimal product line architectures as part of the system design process requires the consideration of a variety of trade-offs. In practice, this challenge cannot be solved manually for all but the smallest problems, therefore an automated solution is required. Our contribution is the generation of a sound mathematical formalization of the problem. This formalization makes the product line optimization problem accessible to various established multi-objective optimization techniques. The applicability of the chosen approach is shown by means of applying a commercial tool for multi-criteria decision making.

abstract

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.

abstract
Systematic exploration of hypotheses is a major part of any empirical research. In software engineering, we often produce unique tools for experiments and evaluate them independently on different data sets. In this paper, we present KernelHaven as an experimentation workbench supporting a significant number of experiments in the domain of static product line analysis and verification. It addresses the need for extracting information from a variety of artifacts in this domain by means of an open plug-in infrastructure. Available plug-ins encapsulate existing tools, which can now be combined efficiently to yield new analyses. As an experimentation workbench, it provides configuration-based definitions of experiments, their documentation, and technical services, like parallelization and caching. Hence, researchers can abstract from technical details and focus on the algorithmic core of their research problem. KernelHaven supports different types of analyses, like correctness checks, metrics, etc., in its specific domain. The concepts presented in this paper can also be transferred to support researchers of other software engineering domains. The infrastructure is available under Apache 2.0: github.com/KernelHaven. The plug-ins are available under their individual licenses. Video: youtu.be/IbNc-H1NoZU

abstract
Development of Software Product Lines (SPLs) requires additional implementation concepts to manage variability and to facilitate the derivation of individual products based on a common platform. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but are typically not applicable to SPLs as they do not address variability management. Over time, a number of specialized product line metrics have been described in literature. However, no systematic description of the characteristics of these metrics is currently available. We conducted a systematic literature review to identify variability-aware implementation metrics, designed for the needs of SPLs. We list these metrics according to the measured artifact types: variability models, code artifacts, and combined metrics measuring both artifact types. Further, we analyze to what extent these metrics were evaluated as a basis for qualitative conclusions.

abstract

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.

This paper introduces an approach to convert integer-based variability conditions to propositional logic. Running this approach as a preparation on an integer-based product line allows the existing SAT-based analyses to work without any modiications. The pure Boolean formulas, that our approach builds as a replacement for the integer-based conditions, are mostly equivalent to the original conditions with respect to satisfiability. Our approach was motivated by and implemented in the context of a real-world industrial case-study, where such a preparation was necessary to analyze the variability.

Our contribution is an approach to convert conditions, that use integer variables, into propositional formulas, to enable easy usage of SAT-solvers on the result. It works well on restricted variables (i.e. variables with a small range of allowed values); unrestricted integer variables are handled less exact, but still retain useful variability information.

abstract

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. Its design follows the principle of an experimentation workbench [13] 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.

Here, we describe KernelHaven as a product line analysis research tool and highlight its basic approach as well as its fundamental capabilities. In particular, we describe available information extraction and processing plug-ins and how to combine them. On this basis, researchers and interested professional users can rapidly conduct a first set of experiments. Further, we describe the concepts for extending KernelHaven by new plug-ins, which reduces development effort when realizing new experiments.

abstract

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.

abstract

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.

abstract

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.

abstract

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 overtime. 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.

abstract

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.

We extended the concept of feature effect synthesis [18] to extract domain knowledge from code artifacts of the Bosch PS-EC product line. We present an application of the approach to a large-scale industrial product line and discuss its required modifications to obtain meaningful results in an industrial case.

abstract
Ideally the variability of a product line is represented completely and correctly by its variability model. However, in practice additional variability is often represented on the level of the build system or in the code. Such a situation may lead to inconsistencies, where the actually realized variability does not fully correspond to the one described by the variability model. In this paper we focus on configuration mismatches, i.e., cases where the effective variability differs from the variability as it is represented by the variability model. While previous research has already shown that these situations still exist even today in well-analyzed product lines like Linux, so far it was unclear under what circumstances such issues occur in reality. In particular, it is open what types of configuration mismatches occur and how severe they are. Here, our contribution is to close this gap by presenting a detailed manual analysis of 80 configuration mismatches in the Linux 4.4.1 kernel and assess their criticality. We identify various categories of configuration issues and show that about two-thirds of the configuration mismatches may actually lead to kernel misconfigurations.

abstract
Development of Software Product Lines (SPLs) requires additional implementation concepts to manage variability and to facilitate the derivation of individual products based on a common platform. These variability implementation concepts are not required for the development of single systems and, thus, are not considered in traditional software engineering. Metrics are well established in traditional software engineering, but are typically not applicable to SPLs as they do not address variability management. Over time, a number of specialized product line metrics have been described in literature. However, no systematic description of the characteristics of these metrics is currently available. We conducted a systematic literature review to identify variability-aware implementation metrics, designed for the needs of SPLs. We list these metrics according to the measured artifact types: variability models, code artifacts, and combined metrics measuring both artifact types. Further, we analyze to what extent these metrics were evaluated as a basis for qualitative conclusions.

abstract
Software Product Line (SPL) evolution affects a variety of artifact types, each containing their artifact-specific information as well as variability information. While the former information type defines the basic content of an artifact, like the general program definition in code artifacts, the latter supports the customization of these artifacts for different products of the SPL. Existing work that aims at characterizing the state and evolution of a product line identifies general SPL evolution scenarios or evaluates the (co-)evolution of variability information in different types of artifacts. However, these results are typically based on a feature perspective, which abstracts from the SPL evolution at large. We argue that an artifact-based analysis of product line evolution will complement existing work by analyzing the intensity of changes to different artifact and information types. In this report, we therefore present an approach for and the results of the extraction and analysis of changes introduced to artifact-specific and variability information in code, build and variability model artifacts. This approach has been developed for and applied to the Linux kernel. In order to broaden our analysis, we also apply the approach to the Coreboot firmware. The results reveal the intensity of changes over the evolution history of both SPLs. Further, we compare the intensity of changes across both SPLs with respect to the size of the changes as well as over time.

abstract
Developing Big Data applications implies a lot of schematic or complex structural tasks, which can easily lead to implementation errors and incorrect analysis results. In this paper, we present a model-based approach that supports the automatic generation of code to handle these repetitive tasks, enabling data engineers to focus on the functional aspects without being distracted by technical issues. In order to identify a solution, we analyzed different Big Data stream-processing frameworks, extracted a common graph-based model for Big Data streaming applications and developed a tool to graphically design and generate such applications in a model-based fashion (in this work for Apache Storm). Here, we discuss the concepts of the approach, the tooling and, in particular, experiences with the approach based on feedback of our partners.

abstract
Product Line Engineering is a software engineering approach that aims at maximizing reuse by handling variation in a systematic and disciplined manner. Its power has been widely proven in industrial practice. However, the approach is sometimes regarded as too restrictive and leading even to additional development complexity. Here, we introduce a number of underlying principles for product line engineering along with an open-source toolset. The principles can also be (partially) applied independently of a specific tool support. Here, we discuss both the underlying principles as well as the realization of the toolset.

abstract
In large and complex systems there is a need to monitor resources as it is critical for system operation to ensure sufficient availability of resources and to adapt the system as needed. While there are various (resource)-monitoring solutions, these typically do not include an analysis part that takes care of analyzing violations and responding to them. In this paper we report on experiences, challenges and lessons learned in creating a solution for performing requirements-monitoring for resource constraints and using this as a basis for adaptation to optimize the resource behavior. Our approach rests on reusing two previous solutions (one for resource monitoring and one for requirements-based adaptation) that were built in our group.

abstract
Um die Variabilität einer Software-Produktlinien zu handhaben, wird bei Verwendung einer C-basierten Sprache oftmals der integrierte Präprozessor genutzt. Eine bereits bewährte Methode [Sn96], um Zusammenhänge zwischen Präprozessorvariablen zu erkennen, ist der Einsatz der formalen Begriffsanalyse (FCA)3. Die aus der FCA resultierenden Verbände können jedoch sehr umfangreich sein. Daher schlagen wir ein neues Verfahren für Software-Produktlinien vor, mit dem die Größe der Verbände durch Berücksichtigung des Variabilitätsmodells reduziert werden kann. Mit Hilfe dieses neuen Verfahrens wird die FCA in unserer Arbeit zum ersten mal auf den Linux-Kernel angewendet. Dieser Beitrag erschien als Vollbeitrag bei der International Conference on Software Maintenance and Evolution (ICSME) 2016 [Lü16]

abstract
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.

abstract
In contrast to traditional software systems, the evolution of a Software Product Line (SPL) affects not only artifacts like source code or requirements, but also variability information, which supports the customization of these artifacts across different products of the SPL. While some work exists that aims at characterizing the state and evolution of a product line from a feature perspective, this abstracts away the details of code evolution, hence, ignoring aspects like the difference in size of features. In this paper, we present an approach for the extraction and analysis of changes introduced to code, build and variability model artifacts. This approach has been developed for and applied to the Linux product line.

abstract
Context. Software product line engineering has been established to minimize costs and efforts, while maximizing the quality of products in a family of software products. Software product lines typically contain a variability model, which supports the derivation of permissible variants. These variability models may contain expert/domain knowledge in the form of constraints. These constraints are used during the configuration process to avoid the selection of unsupported product variants. Problem. Developers must encode their knowledge about supported product variants and restrictions, otherwise the variability model becomes ineffective or even incorrect. The initial development of the variability model as well as the evolution of the product line implementation bear the risk that model and implementation drift apart. In this report, we introduce the notion of mismatched configuration information to describe the situation if the variability model does not react the dependencies of the implementation. This may indicate an incomplete variability model or undesired dependencies between code artifacts. Solution. We discuss the impact of mismatched configuration information and show how to detect this conceptually. Subsequently, we focus on mismatched hierarchical configuration information and present an effective heuristic for their detection. These results serve as an input to complete variability models or a code review to remove undesired implementation dependencies. We discuss the application of our approach on a Linux case study. The analysis of the x86 architecture of the Linux kernel takes only around 30 minutes and revealed mismatched configuration information, which was not treated by prior work.

abstract
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).

abstract
Big Data aims at the efficient processing of massive amounts of data. Performance modeling is often used to optimize performance of systems under development. Based on experiences from modeling Big Data solutions, we describe some problems in applying performance modeling and discuss potential solution approaches.

abstract
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.

abstract

The software product line engineering paradigm promotes sharing common core assets for building similar software systems. Researchers have argued that the deployment of product line techniques can lead to lower development costs as well as improved delivery time. There has also been some indication that, if systematically executed, products derived from a software product line can enjoy higher quality levels given repeatedly tested core assets are used in the development process (van der Linden et al. 2007). Researchers have explored many exciting research challenges at different levels of abstraction ranging from high-level metamodels for commonality and variability representation (Chen et al. 2009) to low-level pre-processor directives for incorporating variability in the code base (Liebig et al. 2010).

There is also a significant body of knowledge on experiences in practically transferring or deploying software product line research outcomes to industrial partners and real-world settings (van der Linden et al. 2007). However, recent systematic reviews of the literature reveals that there is space for more comprehensive and inclusive research that would provide empirical evidence on the practicality and applicability of research outcomes. For instance, Ahnassay et al. (2013) observed that within product line research published between 2006 and 2011 that had an empirical evaluation component only 34 % of the papers interacted or involved industrial practitioners. This can point to the need for more in-depth study of the practicality of the approaches that are proposed by the product line community that would involve the target audience of the research outcomes. This observation can be complemented with the fact that the majority of the papers did not provide any concrete foundation for their problem statement. In other words, the problem definition was taken for granted and only the solution was described.

abstract
Reproducibility and repeatability are key properties of benchmarks. However, achieving reproducibility can be difficult. We faced this while applying the micro-benchmark MooBench to the resource monitoring framework SPASS-meter. In this paper, we discuss some interesting problems that occurred while trying to reproduce previous benchmarking results. In the process of reproduction, we extended MooBench and made improvements to the performance of SPASS-meter. We conclude with lessons learned for reproducing (micro-)benchmarks.

abstract
The Linux Kernel is often used as real world use case to demonstrate novel Software Product Line Engineering techniques. The large open source repository facilitates the analysis of the variability model, the instantiation process, the instantiable artefacts, and the evolution of all of them. This report focusses on the analysis of undocumented KConfig functionalities. These functions have to be considered while applying any variability management technique to the Linux Kernel. Hence, this report will contribute to a better understanding how variability is handled in KConfig files. Further, we analyse existing work, which also analysed KConfig. Based on the weak documentation of KConfig, these works contain errors. These errors threat the validity of many existing analysis of the Linux Kernel.

abstract
Software Product Line Engineering (SPLE) is a systematic approach for the development of related software products. These products share a common infrastructure but vary with respect to their individual capabilities, called variabilities. Variability management is a key part of SPLE and is responsible for developing, combining and configuring such variabilities. As these activities are inherently complex, SPLE significantly benefits from tool-support. We developed a customizable Eclipse extension for SPLE that consists of around 38 plug-ins. The resulting tool, called EASy-Producer, extends the Eclipse IDE by the capability to support the creation and management of software product line projects. To provide this capability, EASy-Producer utilizes the extension concepts of the Eclipse platform and integrates additional frameworks, like Xtext. In this paper, we share our experience while applying the Eclipse technologies and, in particular, realizing specific capabilities of our tool using the Eclipse framework. The focus of this paper is on our lessons learned regarding managing workspace information and conflicting build mechanism as well as using Eclipse extensions outside of Eclipse. These lessons serve as an input to the Eclipse community and may help other developers in realizing a complex Eclipse extension.

abstract
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.

abstract
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.

abstract
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.

abstract
Big data applications with their high-volume and dynamically changing data streams impose new challenges to application performance management. Efficient and effective solutions must balance performance versus result precision and cope with dramatic changes in real-time load and needs without over-provisioning resources. Moreover, a developer should not be burdened too much with addressing performance management issues, so he can focus on the functional perspective of the system For addressing these challenges, we present a novel comprehensive approach, which combines software configuration, model-based development, application performance management and runtime adaptation.

abstract
Variability modeling is a major part of modern product line engineering. Graphical or table-based approaches to variability modeling are focused around abstract models and specialized tools to interact with these models. However, more recently textual variability modeling languages, comparable to some extent to programming languages, were introduced. We consider the recent trend in product line engineering towards textual variability modeling languages as a phenomenon, which deserves deeper analysis. In this article, we report on the results and approach of a literature survey combined with an expert study. In the literature survey, we identified 11 languages, which enable the textual specification of product line variability and which are sufficiently described for an in-depth analysis. We provide a classification scheme, useful to describe the range of capabilities of such languages. Initially, we identified the relevant capabilities of these languages from a literature survey. The result of this has been refined, validated and partially improved by the expert survey. A second recent phenomenon in product line variability modeling is the increasing scale of variability models. Some authors of textual variability modeling languages argue that these languages are more appropriate for large-scale models. As a consequence, we would expect specific capabilities addressing scalability in the languages. Thus, we compare the capabilities of textual variability modeling techniques, if compared to graphical variability modeling approaches and in particular to analyze their specialized capabilities for large-scale models.

abstract
In an information system ecosystem customers integrate features, which are independently developed and evolved by multiple organizations. These features need to work together although there is little to no coordination among developer organizations. The handling of such ecosystems becomes the more challenging, the more the solutions provided by the different parties are intertwined. In this paper, we propose to handle implementations on a per-feature basis, and introduce an approach towards this goal, which we call feature packs. We discuss the requirements on such an approach and emphasize in particular the kind of analysis relevant to ensure that the system resulting from a corresponding aggregation of feature packs works reliably. We also illustrate a realization of the approach using a real-world ecosystem case study.

abstract
In software product line engineering, the design of assets for reuse and the derivation of software products entails low-level and high-level decision making. In this process, two major types of decisions must be addressed: variability decisions, i.e., decisions made as part of variability management, and architectural decisions, i.e., fundamental decisions to be made during the design of the architecture of the product line or the products. In practice, variability decisions often overlap with or influence architectural decisions. For instance, resolving a variability may enable or prevent some architectural options. This inherent interdependence has not been explicitly and systematically targeted in the literature, and therefore, is mainly resolved in an ad hoc and informal manner today. In this paper, we discuss possible ways how variability and architectural decisions interact, as well as their management and integration in a systematic manner. We demonstrate the integration between the two types of decisions in a motivating case and leverage existing tools for implementing our proposal.

abstract

Zusammenfassung: Der Begriff Technical Debt bezeichnet Entwicklungsaltlasten, die in der Weiterentwicklung von Software zu Problemen führen können. Diese Problematik ist von großer praktischer Bedeutung, vor allem in der inkrementellen Entwicklungsprozessen, und gewinnt aktuell auch in der wissenschaftlichen Community stark an Bedeutung. Hier betrachten wir die Frage welche Bedingungen eine optimale Strategie zur Behandlung von Technical Debt erfüllen muss, ob eine solche Strategie überhaupt möglich ist und wie realistische Strategien ausschen können. Dabei ergibt sich, dass eine optimale Strategie auf fundamentale Probleme stößt. Wir fuhren daher Approximationen ein, die eine optimale Auswahl ermöglichen. Daraus leiten wir einen Ansatz zur Auswahl von Technical Debt items ab. Dieser erlaubt die effiziente Behandlung von Technical Debt in beliebigen, insbesondere iterativen und gar agilen Entwicklungsprozessen.

abstract

Requirements engineering is a core part of the software engineering lifecycle with tremendous leverage on software development success. It becomes particularly difficult in the context of global software engineering due to the need to coordinate many different stakeholders in a distributed setting. In this paper we survey some main results in global requirements engineering. We will address both the development of systems with internationally distributed customers as well as the situation of globally distributed development.

abstract

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.

abstract

Erfolgreiches Requirements Engineering benötigt die Mitwirkung der Projekt-Stakeholder. Wenn Projekte in einem globalen Kontext stattfinden, dann ergeben sich jedoch besondere Herausforderungen, da die Kommunikation durch die räumlichen, zeitlichen und kulturellen Unterschiede massiv erschwert wird. Die massiven Auswirkungen, die ein globalisiertes Umfeld auf die Software-Entwicklung haben kann, werden bereits seit einiger Zeit unter dem Blickwinkel des Global Software Engineering (GSE) untersucht. In einer Literaturübersicht haben wir versucht die RE-spezifischen Ergebnisse zusammen zu tragen

abstract

This issue of IEEE Software discusses where the mobile computing has brought us today and where it could be taking us in the future. It provides a glimpse into the near future of mobile computing by focusing on proximate software challenges coupled with promising techniques, infrastructure, and research from academia, government, and industry. The first Web extra at youtu.be/iLnNHwp-H8E is a video demonstration of the Group Autonomy for Mobile Systems (GAMS) project, which is an extension of a research project called Self-governing Mobile Adhocs with Sensors and Handhelds (SMASH) that investigated human-in-the-loop autonomy at Carnegie Mellon University. The project created Android interfaces to a drone swarm that tried to autonomously search for survivors in a disaster scenario using the Parrot AR.Drone and custom GPS and thermal sensors. The second Web extra at youtu.be/lW1dqsrdRHU is a video demonstration of HD4AR mobile augmented reality technology that was commercialized through PAR Works. The third Web extra at youtu.be/M4w5oPqrMRo is an audio interview in which James Edmondson talks with Suzanne Miller about autonomous systems, specifically as they relate to robotic systems. In particular, Edmondson's research focuses on partial autonomy with an aim of complementing human users and extending their reach and capabilities in mission-critical environments. From the SEI Podcast Series "Conversations in Software Engineering."

abstract
Development of software product lines requires tool support, e.g., to define variability models, to check variability models for consistency and to derive the artifacts for a specific product. Further capabilities are required when product lines are combined to software ecosystems, i.e., management and development of distributed product lines across multiple different organizations. In this paper, we describe EASy-Producer, a prototypical tool set for the development of software product lines in general and variant-rich ecosystems in particular. To support the product line engineer, EASy-Producer differentiates between simplified views limiting the capabilities and expert views unleashing its full power. We will discuss how these two views support the definition of variability models, the derivation of product configurations and the instantiation of artifacts.

abstract
The resource requirements of Big Data applications may vary dramatically over time, depending on changes in the context. If resources should not be defined for the maximum case, but available resources are mostly static, there is a need to adapt resource usage by modifying the processing behavior. The QualiMaster project researches such an approach for the analysis of systemic risks in the financial markets.

abstract
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 this paper, we provide a systematic analysis of the capabilities of current textual variability modeling languages, in particular regarding variability management in the large. Towards this aim, we define a classification schema consisting of five dimensions, classify ten different textual variability modeling languages using the classification schema and provide an analysis. In summary, some textual variability modeling languages go beyond textual representations of traditional variability modeling approaches and provide sophisticated modeling concepts and constraint languages. Three textual variability modeling approaches already support mechanisms for large-scale variability modeling such as model composition, modularization, or evolution support.

abstract
In this report, we discuss the notion of Technical Debt and formalize the concept as a basis of disciplined study. This formalization allows us to characterize and measure Technical Debt independent of its source. We will then introduce approximations to measuring Technical Debt that can be more easily applied in practice. As a result we arrive at a method for deciding on tackling Technical Debt, which relies on a formal approach, with clearly identified approximations. We will also illustrate our approach with an example.

abstract
As more and more companies shift to a product line approach, supporting the evolution of software product lines becomes increasingly important. While today already significant work exists along the lines of quality analysis for software product lines, there is much less work that addresses the evolution scenario. In this paper, we briefly describe different categories of approaches for identifying problems in product lines. Based on this we describe a new research direction for identifying problems in product line evolution scenarios.

abstract
We present an approach that supports the customization and evolution of a database schema in a software ecosystem context. The approach allows for the creation of customized database schemas according to selected, supported feature packs and can be used in an ecosystem context, where third-party providers and customers augment the system with their own capabilities. The creation of the final database schema is automatic and also the relevant updates of individual feature packs can be automatically handled by the system.

abstract
Variability modeling is a core activity of software product line engi-neering. Over the years, many different approaches to variability modeling have been proposed. Typically, the individual approaches have been designed with-out a detailed justification on why certain modeling concepts should be used. This yields a rather unfunded selection of modeling approaches in practice, e.g., selecting approaches that provide higher modeling concepts than actually need-ed, but less analyses capabilities than required. Thus, we propose that the focus of an analysis should not be to determine the best modeling language, but rather to provide a characterization on when to use what kind of approach. In particu-lar, the selection of one approach for a specific situation should be driven from the required modeling concepts (expressiveness) and the required analyzability. In this paper, we propose a classification of core concepts of variability model-ing based on expressiveness and analyzability. We discuss the methodology for and the classification of variability modeling concepts illustrated by a running example. The contribution of this paper is a modeling approach-independent classification of variability modeling concepts and their dependencies to pro-vide a systematic and rationale basis to anyone designing, standardizing, im-plementing or selecting a specific variability modeling approach.

abstract
The notion of technical debt attracts significant attention, especially in the context of reconciling architecture and agile development. However, most work on technical debt is still largely informal and if it provides a formalization it is often ad-hoc. In this paper, we provide a detailed, formal analysis of decision making on technical debt in development. Using this formalization, we show that optimal decision making is not effectively computable in real-world situations and provide several well-defined approximations that allow to handle the problem nevertheless in practical situations. Combining these approximations in a single method leads to a light-weight approach that can be effectively applied in iterative software development, including agile approaches.

abstract
Lately, software ecosystems have generated a lot of attention as they are very important to modern software industry. Over the course of several research projects, we addressed the problem of variability-rich software ecosystems and their relation to software product lines in our research group. This paper summarizes some of the problems we identified and describes some solutions we created both on a conceptual level and implemented in a prototype tool environment.

abstract

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.

PLE4G was designed as a special approach to enrich classical product line engineering with considerations of globalization issues. As we will assume that participants are mostly familiar with the basics of product line engineering, we will focus in particular on those issues that are specific to globalization.

abstract

Why does it change?

How does it change?

Ultra-large scale systems [Northrop, 2006 1] exceed our ability to manage and tax our ability to understand and yet the infrastructure modern society needs, such as the power grid, is in fact at this scale. How does this new scope affect software product line organizations? Some have suggested that ecosystems are a natural follow on to software product lines, but what is the transition and which concerns does this address? And what changes as the scale increases even more?

abstract

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.

abstract

Architecting systems of systems is well known to be a formidable challenge. A major aspect in this is defining the integration among the systems that constitute the system of systems. In this paper, we aim to support the SoS architect by systematically developing a way to characterize system of systems integration patterns. These characteristics at the same time support the architecting process by highlighting important issues a SoS architect needs to consider. We discuss the consolidated template and illustrate it with an example pattern. We also discuss the integration of this novel pattern approach into the overall architecting process.

abstract

Over recent years the topic of technical debt has gained significant attention in the software engineering community. The area of technical debt research is somewhat peculiar within software engineering as it is built on a metaphor. This has certainly benefited the field as it helps to achieve a lot of attention and eases communication about the topic, however, it seems it is to some extent also sidetracking research work, if the metaphor is used beyond its range of applicability. In this paper, we focus on the limits of the metaphor and the problems that arise when over-extending its applicability. We do also aim at providing some additional insights by proposing certain ways of handling these restrictions.

abstract

[Context & Motivation] Developing new software systems based on a software product line (SPL) is still a time-consuming task and the benefits of using such an approach are often smaller than expected. One important reason for this are difficulties in systematically mapping customer requirements to characteristics of the SPL. [Question/problem] Even though it has been recognized that the success of reuse strongly depends on how requirements are treated, it remains unclear how to perform this in an optimal way. [Principal ideas/results] In this paper, we present a controlled experiment performed with 26 students that compared two requirements elicitation approaches when instantiating a given SPL. [Contribution] Our findings indicate that a novel, problem-oriented requirements approach that explicitly integrates the reuse of SPL requirements into the elicitation of customer-specific requirements is more effective than a traditional SPL requirements approach, which distinguishes requirements reuse and additional elicitation customer-specific requirements.

abstract

[Context & Motivation] Developing new software systems based on a software product line (SPL) is still a time-consuming task and the benefits of using such an approach are often smaller than expected. One important reason for this are difficulties in systematically mapping customer requirements to characteristics of the SPL. [Question/problem] Even though it has been recognized that the success of reuse strongly depends on how requirements are treated, it remains unclear how to perform this in an optimal way. [Principal ideas/results] In this paper, we present a controlled experiment performed with 26 students that compared two requirements elicitation approaches when instantiating a given SPL. [Contribution] Our findings indicate that a novel, problem-oriented requirements approach that explicitly integrates the reuse of SPL requirements into the elicitation of customer-specific requirements is more effective than a traditional SPL requirements approach, which distinguishes requirements reuse and additional elicitation customer-specific requirements.

abstract

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 throughout its lifetime.

abstract

This report documents the program and the outcomes of Dagstuhl Seminar 13171 "Customizing Service Platforms". The aim of the seminar was to bring together researchers from different areas of academia and industry that are related to the seminar topic and typically do not intensively interact with each other. These communities are Product Line Engineering, Software Architecture, Service Engineering, and Cloud Computing. The ambition of the seminar was to work on the topic of "Customization of Service Platforms", which is related to all of these areas, in a synergistic and cooperative way to identify new research challenges and solution approaches. As part of the seminar, we identified a number of key areas which provided the basis for highly interactive working groups.

abstract
Service-Oriented Computing (SoC) has been established as an important paradigm over the last decade. A particularly important part in a service-oriented solution is the service-oriented platform. This provides an environment and infrastructure for a number of service-oriented applications. An important challenge in complex application areas is the need to customize these platforms to the demands of a specific context. Product line technologies can support this by providing the concept of variability management to SoC. In this paper, we will provide a reference model for (domain-specific) service platforms and describe different approaches that provide customization possibilities in a service platform context. The complexity of handling the customization of large-scale service platforms in an integrated manner will be addressed by introducing the concept of production strategies for variability implementation techniques.

abstract
In service-oriented systems services can be easily reused and shared without modification. However, there are business situations where a variation of services is needed to meet the requirements of a specific customer or context. Variation of software systems has been well researched in product line engineering in terms of Variability Implementation Techniques (VITs). While most VITs focus on the customization of traditional software systems, several VITs have been developed for service-oriented systems. In this paper, we discuss the problem of service customization and provide an overview of different VITs for service variability. For this purpose, we will define four dimensions to describe, characterize and analyze existing VITs: the technical core idea, the object of variation, the forms of variation, and the binding time.

abstract
Die Erfassung von Produktmetriken zur Laufzeit ist ein wesentlicher Baustein einer Qualitätsstrategie in der Produktentwicklung. Die Erfassung von Produktmetriken in der Entwicklung ist jedoch oft mit signifikantem Aufwand verbunden, da viele Werkzeuge nur bestimmte Eigenschaften erfassen können und ihre Verwendung oft sehr komplex ist. Darüber hinaus entsteht durch die Durchführung der Messung meist ein signifikanter Laufzeit-Overhead. Das Ziel des SPASS-meter-Werkzeugs ist die integrierte Erfassung einer Vielzahl von Metriken bei einfacher Konfiguration und geringem Laufzeit-Overhead. In diesem Beitrag stellen wir SPASS-meter vor und vergleichen es mit bekannten ähnlichen Werkzeugen wie Kieker, OpenCore, Xprof und HPROF. Eine Übersicht der Stärken und Schwächen schließt den Vergleich ab.

abstract
Variability modeling is essential for defining and managing the commonalities and variabilities in software product lines. Numerous variability modeling approaches exist today to support domain and application engineering activities. Most are based on feature modeling (FM) or decision modeling (DM) but so far no systematic comparison exists between these two major classes of approaches. Over the last two decades many new features have been added to both FM and DM and it is a tough decision which approach to use for what purpose. This paper clarifies the relation between FM and DM. We aim to systematize the research field of variability modeling and to explore potential synergies. We compare multiple aspects of FM and DM ranging from historical origins and rationale, through syntactic and semantic richness, to tool support, identifying commonalities and differences. We hope that this effort will improve the understanding of the range of approaches to variability modeling by discussing the possible variations. This will provide insights to users considering adopting variability modeling in practice and to designers of new languages, such as the new OMG Common Variability Language.

abstract
The open variability of software product line ecosystems allows customers and third party organizations to create extensions to a system which may refine the variability model. In this paper we will describe an approach to evolution support, which was developed in the context of one specific company, HIS GmbH. However, the approach is much more generic than this. In particular, it is based on the formalization of modifications to configuration values and constraints on both the model and the data in the context of the evolution of multi-level configurations. Our approach supports the identification of inconsistencies in evolution.

abstract

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.

abstract

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.

PLE4G was designed as a special approach to enrich classical product line engineering with considerations of globalization issues. As we will assume that participants are mostly familiar with the basics of product line engineering, we will focus in particular on those issues that are specific to globalization.

abstract

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.

abstract
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. We aim to provide a broad overview of the potential research landscape where we also discuss the actual coverage of the field by research work. As a result, we do not only provide an overview of the field, but do also describe several potential research approaches that have so far received very little attention.

abstract
The traditional focus of Product Line Engineering (PLE) 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. We also provide a discussion of different combinations of these approaches as a way to combine their strengths.

abstract

Requirements engineering is often a process within which an interdisciplinary group of people have to arrive at a novel and valuable solution to a complex design problem in which they all share a stake. In such situations, requirements engineering requires creativity, and typically involves intensive communication and negotiation. Collaborative creativity can thus be essential for effective requirements engineering in these cases. Few studies have concentrated on understanding the implications of this need for collaborative creativity, however, and there is limited advice for practitioners. This paper therefore explains the collaboratively creative nature of requirements engineering, based upon a literature review and the results of a survey of experts. It then develops a list of factors influencing collaborative creativity and provides advice for practitioners on how to deal with them.

abstract
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 spend to compare these concepts. In this paper, we compare the capabilities and expressiveness of basic feature modeling with basic decision modeling. In this paper, we also present a formalization of basic decision modeling and show that in combination with a powerful constraint language both approaches are equivalent, while in their very basic forms they are not equivalent. These results can be used to transfer existing research results between the two paradigms.

abstract
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. Stability of the product line architecture is very important to the successful long-term evolution of a product line. In this paper, we discuss how a form of domain decomposition, which we call conceptual architecture, can be used to guide product line engineering towards long-term viability. We will illustrate this approach in the context of a large-scale product line development and analyze the evolution properties of the product line. Transferability of the approach is suggested to other embedded software systems that drive mature, well-understood physical control system.

abstract

In the last decade, the Unified Modeling Language (UML) has become a de-facto standard as modeling language in software engineering. However, due to the complexity of the UML specification it is rather difficult for an individual tool to provide a faithful implementation of the entire breath of modelling elements defined by UML. Thus, tools differ significantly due to their individual support of the UML.

The decision for a software development organization regarding a specific modeling tool is important, in an extreme case for an entire company. Usually, such a decision leads to different kinds of costs such as training of the employees. Licensing costs are often only a small portion of the actual costs for such a tool. Thus, the decision for a modelling tool shall be done carefully. This study is probably the most comprehensive comparison of UML tools at the moment and, therefore, provides adequate support in making rational decisions on modeling tools.

The focus of this study is on the realization of modeling capabilities by individual tools, i.e. whether and how modeling elements of the UML have been implemented. As a basis for a detailed analysis of the modelling capabilities, we decomposed the UML specification into 476 features and inspected the tools for their individual support of these features. A detailed summary per tool links the identified capabilities to the requirements for individual diagram types as stated in the UML specification. This enables the reader to quickly check the appropriateness of a certain tool for a given application context. As a part of our analysis, we characterize each individual tool in terms of its UML compliance according to the classification schema of the OMG.

abstract
[Context and motivation] While requirements engineering earlier focused on gathering requirements, it has been recognized today that creativity and innovation are required as a basis for novel products. [Question/problem] We described earlier an approach to support creativity in requirements engineering. Here, we focus on a thorough validation of the approach. [Principal ideas/results] Our approach uses semantic-based technologies to derive new idea triggers. Here, we show an evaluation of this approach. We find that the approach provides better results than other existing creativity techniques like random triggers. [Contribution] The paper provides evidence for creativity enhancement using our approach. It also shows how a controlled experiment to analyze creativity in requirements engineering can be performed.

abstract
In a software ecosystem with open variability customers create their own products based on a reuse infrastructure provided by a development company. While an open approach has many benefits, it brings along a number of specific issues, especially related to evolution. In this problem statement we discuss some of the issues that arise in merging local variabilities with evolved versions of the reuse infrastructure of the development organization. In our discussion we focus on information systems, inspired by the situation of a specific company.

abstract
It has been shown that product line engineering can significantly improve the productivity, quality and time-to-market of software development by leveraging extensive reuse. Variability models are currently the most advanced approach to define, document and manage the commonalities and variabilities of reusable artifacts such as software components, requirements, test cases, etc. These models provide the basis for automating the derivation of new products and are thus the key artifact to leverage the flexibility and adaptability of systems in a product line. Among the existing approaches to variability modeling feature modeling and decision modeling have gained most importance. A significant amount of research exists on comparing and analyzing different feature modeling approaches. However, despite their significant role in product line research and practical applications, only little effort has been devoted to compare and analyze decision modeling approaches. In order to address this shortcoming and to provide a basis for more structured research on decision modeling in the future, we present a comparative analysis of representative approaches. We identify their major modeling concepts and present an analysis of their commonalities and variabilities.

abstract

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].

abstract

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten, von eingebetteten Systemen bis zu betrieblichen Informationssystemen. Sie ermöglichen höhere Produktivität, steigern die Qualität und verbessern die strategischen Positionen der Unternehmen. Dennoch bergen Produktlinien für viele Unternehmen noch bedeutende Herausforderungen und Risiken. Die Gründe liegen teilweise im technischen Bereich. So sind viele Produktlinien-Technologien für den breiten Einsatz in der Praxis noch nicht genügend ausgereift und miteinander integriert. Die wohl größten Herausforderungen stellen sich in den Wechselwirkungen zwischen den technischen Verfahren mit den Prozessen sowie dem organisatorischen und geschäftlichen Kontext der Produktlinienentwicklung.– Wie müssen die technologischen Ansätze auf diese Wechselwirkungen ausgerichtet sein? Welche Potenziale bieten neue technologische Entwicklungen in unterschiedlichen Einsatzfeldern?

abstract

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten. Dennoch bergen sie für viele Unternehmen noch bedeutende Herausforderungen und Risiken. Der Workshop beleuchtet aktuelle Erfahrungen mit Produktlinien und bietet ein Forum für den Dialog zwischen Praxis und anwendungsorientierter Forschung. Im Mittelpunkt steht das Wechselspiel zwischen technischen Fragestellungen und den geschäftlichen, organisatorischen und Prozessaspekten.

abstract
Im modernen Requirements Engineering werden Anforderungen nicht nur erfasst, sondern gestaltet. Entsprechend ist Innovation in der Anforderungsgewinnung eine wichtige Aufgabe, die entscheidenden Einfluss auf den Produkterfolg hat. Doch können innovative Ideen systematisch entwickelt werden? Frühere Fallstudien zeigten bereits, dass dies möglich ist. In diesem Beitrag zeigen wir, dass der kreative Nutzen einzelner Techniken mit empirischen Methoden systematisch analysiert und belegt werden kann.

abstract
In this paper, we describe EASy-Producer, a prototypical tool for complex and large-scale Software Product Line (SPL) development. The tool enables SPL engineers to reduce complexity by combining derivation and composition techniques to manage one large SPL as a combination of individual, but interrelated SPLs.

abstract
Software Product Line Engineering is inherently complex. This complexity increases further if multiple product line infrastructures are composed to yield the final products, an approach sometimes referred to as Multi Software Product Lines (MSPL). In this paper, we present an approach that targets this development scenario. The approach we present here aims at a lightweight, scalable, and practical approach to variability management for multi software product lines. Our approach explicitly supports heterogeneous product lines, i.e. situations where the various product lines use different generation approaches. The approach has been implemented in the EASy-Producer tool set and applied on some case studies.

abstract
The variability model is a central artifact in product line engineering. Existing approaches typically treat this as a single centralized artifact which describes the configuration of other artifacts. This approach is very problematic in distributed development as a monolithic variability model requires significant coordination among the involved development teams. This holds in particular if multiple independent organizations are involved. At this point very little work exists that explicitly supports variability modeling in a distributed setting. In this paper we address the question how existing, real-world, large-scale projects deal with this problem as a source of inspiration on how to deal with this in variability management.

abstract

As software systems increase in complexity and size their capabilities in adapting to a wide range of situations becomes increasingly important. Product line techniques can be used to successfully such flexibility even at after development time, like at initialization or even runtime. Over the last few years, this branch of software systems has established itself successfully as dynamic software product lines (DSPL).

abstract

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten, von eingebetteten Systemen bis zu betrieblichen Informationssystemen. Sie ermöglichen höhere Produktivität, steigern die Qualität und verbessern die strategischen Positionen der Unternehmen, u.a. aufgrund eines hohen Grades an Wiederverwendung und Standardisierung

abstract

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten. Dennoch bergen sie für viele Unternehmen noch bedeutende Herausforderungen und Risiken. Der Workshop beleuchtet aktuelle Erfahrungen mit Produktlinien und bietet ein Forum für den Dialog zwischen Praxis und anwendungsorientierter Forschung. Im Mittelpunkt steht das Wechselspiel zwischen technischen Fragestellungen und den geschäftlichen, organisatorischen und Prozessaspekten.

abstract
Softwareentwickelnde Unternehmen sind heute meist auf Produkte fokussiert, die sie immer wieder in ähnlicher Weise realisieren (Finanzinformationssysteme, Motorensteuerungen etc.). Entsprechend können diese Unternehmen signifikante Vorteile erzielen, falls es ihnen gelingt, ähnliche Funktionalität jeweils nur einmal zu entwickeln und in mehreren Produkten wiederzuverwenden. Produktlinienentwicklungsansätze unterstützen genau dies und führen so zu deutlichen Vorteilen in Bezug auf Kosten, Qualität und Entwicklungszeit, wie Industrieerfahrungen zeigen [3, 7]. Produktlinienansätze unterscheiden sich von anderen Softwareentwicklungsansätzen vor allem darin, dass sie auf die integrierte Entwicklung einer Menge von Systemen (Produkten) abzielen,während klassische Ansätze den Fokus auf Einzelsysteme legen.

abstract
Traditionell wird die Anforderungserhebung vor allem als eine reine Erfassung existierender Wünsche gesehen. In letzter Zeit setzt sich jedoch die Ansicht durch, dass Anforderungen für neue Produkte meist erst entwickelt werden müssen; Anforderungserhebung also mit Innovation verbunden ist. Damit ist auch das Interesse an der Unterstützung von Kreativität in der Anforderungserhebung stark gewachsen. Kreativitätsunterstützung wird meist im Zusammenhang mit moderierten Workshops gesehen. Hier stellen wir jedoch einen Ansatz dar, bei dem ein Assistenzsystem basierend auf modelliertem Wissen versucht zusätzliche Anhaltspunkte für die kreative Entwicklung von Anforderungen zu geben.

abstract
Die Anpassung von Anforderungswerkzeugen an den Projektkontext ist im Regelfall durch die Anpassungsfähigkeiten des jeweiligen Werkzeuges stark eingeschränkt. In diesem Beitrag stellen wir einen generativen Ansatz zur Anpassung von Anforderungswerkzeugen vor und demonstrieren den Ansatz im Rahmen einer Fallstudie. Unser Ansatz ermöglicht die einfache, zielgerichtete und weitreichende Anpassung an die Anwendungssituation.

abstract
Im letzten Jahrzehnt hat sich die Unified Modeling Language (UML) als Modellierungssprache für den praktischen Einsatz im Software Engineering weitgehend durchgesetzt. Aufgrund der Komplexität der UML Spezifikation ist es allerdings für ein einzelnes Werkzeug sehr schwierig, die gesamte Bandbreite der UML Modellierungselemente getreu der UML Spezifikationen umzusetzen. Werkzeugrealisierungen unterscheiden sich daher maßgeblich anhand der von ihnen unterstützten Teile der UML Spezifikation. Die Entscheidung einer Entwicklungsorganisation für ein konkretes Modellierungswerkzeug ist bedeutsam für das ganze Unternehmen. Im Regelfall zieht eine derartige Entscheidung empfindliche Kosten nach sich, z.B. für das Training der Mitarbeiter. Lizenzkosten stellen dabei oft nur einen geringen Anteil der tatsächlichen Kosten für ein Werkzeug dar. Folglich sollte eine Werkzeugauswahl mit großer Sorgfalt durchgeführt werden. Die vorliegende Studie ist zurzeit der wohl umfassendste Vergleich von UML Werkzeugen und stellt damit ein geeignetes Hilfsmittel dar, um zu einer rationalen Entscheidung über einzusetzende Werkzeuge zu gelangen. Der Schwerpunkt dieser Studie liegt auf der Umsetzung von Modellierungfähigkeiten durch die Werkzeuge, d.h. ob und wie Modellierungselementen und -eigenschaften der UML umgesetzt wurden. Um die UML Modellierungsfähigkeiten detailliert prüfen zu können, wurde die UML Spezifikation in 476 Merkmale aufgegliedert, die individuell für jedes betrachtete Werkzeug geprüft wurden. Eine detaillierte Aufschlüsselung verknüpft die für jedes Werkzeug identifizierten Fähigkeiten mit den Anforderungen, die von der UML für einzelne Diagrammtypen gemacht werden. Auf diese Weise kann die Anwendbarkeit eines konkreten Werkzeuges für einen gegebenen Anwendungskontext schnell überprüft werden. Als Bestandteil unserer Analyse charakterisieren wir jedes Werkzeug durch Angabe der individuellen UML compliance, einem Kategorisierungsschema der OMG.

abstract
In competitive markets product innovation becomes a major issue for companies. Many creativity techniques have been proposed over time to improve creativity.In this paper, we discuss a platform and a specific reasoning approach to support product innovation. This reasoning approach is based on a specific form of heuristic (or almost correct) reasoning, most instances rely on analogies.

abstract
Die Anpassung von Anforderungswerkzeugen an den Projektkontext ist im Regelfall durch die Anpassungsfähigkeiten des jeweiligen Werkzeuges stark eingeschränkt. In diesem Beitrag stellen wir einen generativen Ansatz zur Anpassung von Anforderungswerkzeugen vor und demonstrieren den Ansatz im Rahmen einer Fallstudie. Unser Ansatz ermöglicht die einfache, zielgerichtete und weitreichende Anpassung an die Anwendungssituation.

abstract
Dynamic software product lines (DSPL) are software product lines (SPL) that support runtime variability. Runtime variability is typically interpreted as binding variation points at runtime. We emphasize meta-variability as an important dimension of runtime variability in DSPL. Whereas dynamic binding considers the runtime (de)activation of variants within the scope of a given variability model, meta-variability considers runtime changes to the variability model itself. Meta-variability is essential to support longlived software products that are subject to evolution. In this paper, we consider meta-variability in an industrial DSPL that is developed in a joint project with Egemin N.V., a leading company that provides full life cycle support for automated transportation systems (ATS). The contribution of this paper is threefold. First, we introduce a way to model meta-variability in DSPL in an explicit manner. Second, we put forward a meta-variability meta model that extends the variability meta model with concepts that explicitly support meta-variability. Third, we capture and apply metavariability in an industrial DSPL for automated transportation systems.

abstract
In this paper, we discuss creativity as a form of learning from the perspective of idea generation in the creative process. We analyze forms of creativity and present the statement-based creativity techniques. Based on these concepts a tool prototype IdeaTrigger is presented and verified. It shows the advantages for innovative activity, especially in collaborative environment.

abstract
The Unified Modeling Language (UML) has been widely adopted in industrial software engineering as the reference standard for software and systems modeling. A wide range of different tools have been developed both by industrial vendors as well as by the open source community. However, due to the complexity of the UML specification it is very difficult for a single tool to support the full range of UML standards faithfully. In practice tools differ significantly in terms of the parts of the UML specification they support

abstract
The Unified Modeling Language (UML) specification is widely adopted in software engineering. When tools do not fully implement the UML specification, the user might be locked-in to a modeling tool, e.g. when exported models are not compatible among tools or tools implement different subsets of the UML. These compatibility problems also have significant impact on the effectiveness of model-driven development approaches. Compliance, as defined by the UML standard, is intended to characterize tools and to highlight such problems. In this paper we describe an approach to asses the UML compliance levels of modeling tools. Using UML definition of compliance, we could only identify 4 out of 68 tools as being acceptable.

abstract
Dynamic Software Product Lines (DSPL) focuses on product lines where the resolution of variants happens at a later point in time, ideally at runtime. While runtime reconfiguration is still rather innovative, preconfiguration of software systems is well established and to some degree even standardized. Thus, we study such preconfiguration approaches to better understand how their capabilities relate to classical product line engineering on one hand and to dynamic software product lines on the other.

abstract
Die Evolution einzelner Systeme ist bereits relativ komplex, doch alle diese Probleme findet man potenziert in einer Produktlinienentwicklung. Zusätzlich zu den Einzelsystemproblemen treten weitere Schwierigkeiten hinzu. In diesem Beitrag gehen wir auf die Herausforderungen der Produktliniensituation ein und legen unser Augenmerk vor allem auf die Situation verteilter Evolution. Wir stellen einen möglichen Ansatz zur Lösung vor.

abstract
Developing innovative products is an important challenge for companies these days. Meanwhile it is in requirements engineering widely recognized that requirements elicitation has to go beyond mere recording of knowledge, rather is has to be an active process where new ideas are created. Thus, creativity is an important issue in requirements engineering. While so far tool support for creativity focused mainly on recording the creative outcome or providing relevant knowledge, we will describe an approach where tool support is used to actively support people in the creation of ideas.

abstract
Software product line engineering aims at achieving systematic reuse by exploiting commonalities among related products in order to reduce cost and time-to market. Before adopting this approach, organizations are likely to estimate the benefits they can expect to achieve and the level of investment required to transition to product line engineering. Several economic models and analysis approaches have been developed in order to help make a sound business case. There is a need to review the existing approaches in order to better understand the overall landscape of economic models. To this objective, this paper provides an overview of some existing economic models and discusses important issues and directions in product line economic modeling.

abstract

This tutorial provides an introduction to the basic concepts of software product line engineering: business orientation, variability management, architecture-driven development, and the two-lifecycle approach.

Based on this introduction the Families Evaluation Framework (FEF) is described. This is a systematic approach to evaluating a product line organization and its development approach. The material in this tutorial also provides the basis for the tutorial on inner source software product lines.

abstract

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.

abstract
In the past, formatting guidelines have proved to be a successful method to improve the readability of source code. With the increasing success of visual specification languages such as UML for model-driven software engineering visual guidelines are needed to standardize the presentation and the exchange of modeling diagrams with respect to human communication, understandability and readability. In this article, we introduce a new and encompassing taxonomy of visual guidelines capturing the aestheticquality of UMLclassdiagrams. We propose these guidelines as a framework to improve the aestheticquality and thus the understandability of UMLclassdiagrams. To validate this claim, we describe in detail a controlled experiment carried out as a pilot study to gather preliminary insights on the effects of some of the guideline rules on the understandability of UMLclassdiagrams.

abstract

Es gibt heute eine Vielzahl von Frameworks, die aus verschiedenen Perspektiven die Grundzüge des Requirements-Engineering und-Management beschreiben. Vereinzelt berücksichtigen sie auch Belange der Software-Produktlinienentwicklung. Der Arbeitskreis „Requirements-Engineering-Frameworks und Produktlinien “stellt die Frameworks einander gegenüber und bewertet sie hinsichtlich ihrer Eignung für die industrielle Produktlinien-Entwicklung. Dieser zweite Zwischenbericht stellt Ziele und Vorgehen dar und gibt einen Überblick über die bisherigen Ergebnisse des Arbeitskreises [5].

abstract
Ziel der Anforderungserhebung ist es Anforderungen des Kunden korrekt und vollständig zu erfassen. Doch oft ist auch dem Kunden nicht bewusst, wie eine Lösung aussehen kann. Hier haben sich Kreativitätstechniken als guter Ansatz gezeigt, um die Entwicklung einer Systemvision zu unterstützen. Hier stellen wir einen Ansatz vor, um aus der großen Zahl verfügbarer Techniken systematisch die für eine konkrete Situation passende Technik auszuwählen.

abstract
Die wirtschaftliche Bedeutung von Flexibilität und Adaptivität wächst. Viele Techniken wie Produktlinienentwicklung oder Service-orientierte Architekturen wurden entwickelt, um mit dieser Herausforderung umzugehen. Aber auch Fragestellungen der Softwareevolution sind von Bedeutung. Die genannten Techniken und Entwicklungsansätze haben auch Auswirkungen auf das Requirements Engineering. Diese Herausforderungen stehen im Mittelpunkt des Arbeitskreises Requirements Engineering für Adaptive Systeme.

abstract
Das Requirements-Engineering (RE) hat in den vergangenen Jahren viele RE-Frameworks hervor gebracht, die zentrale Konzepte des RE detailliert und umfassend beschreiben sowie Anleitungen für die RE-Praxis bieten wollen. Zugleich sind mit der Ausweitung der Software-Produktlinien(SPL)-Entwicklung in der Industrie neue Herausforderungen an das RE entstanden, für die RE-Frameworks Lösungen bieten sollten. Der Arbeitskreis "Requirements-Engineering-Frameworks und Produktlinien" der GI-Fachgruppe "Require-ments-Engineering" hat das Ziel, einen Überblick über die wichtigsten RE-Frameworks zu erstellen, die Relevanz aus Sicht der Industrie zu bewerten und ihre Anwendbarkeit in der Produktlinien-Entwicklung zu untersuchen [4][1]. Dies soll Software-Projekte, die Anleitung für Ihr RE suchen, unterstützen, das für sie passende Framework auszuwählen. Dieser Artikel stellt erste Ergebnisse dieser Arbeit vor.

abstract
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.

abstract
While the traditional focus of requirements engineering was mainly on the systematic, reliable and adequate translation of the customers intentions into requirements documentation, it became recently increasingly accepted that requirements engineering, especially for innovative and novel products, is probably more adequately described as a process of joint discovery of requirements that can be supported by creativity techniques. However, so far little work exists on how to systematically select techniques as a basis for requirements engineering. As part of the IdSpace Project, which focuses on collaborative product innovation, we are currently investigating this area. This paper provides a brief overview of our work in this domain.

abstract
Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten. Dennoch bergen sie für viele Unternehmen noch bedeutende Herausforderungen und Risiken. Der Workshop beleuchtet aktuelle Erfahrungen mit Produktlinien und bietet ein Forum für den Dialog zwischen Praxis und anwendungsorientierter Forschung. Im Mittelpunkt steht das Wechselspiel zwischen technischen Fragestellungen und den geschäftlichen, organisatorischen und Prozessaspekten.

abstract
In this paper, we introduce the concept of metavariability, i.e., variability with respect to basic variability attributes like binding time or constraints. While the main focus of this paper is on the introduction of the concept, we will also illustrate the concept by providing a case study. The case study will feature a simple implementation environment based on aspect-oriented programming and will include an example that will exhibit some key characteristics of the envisioned production process.

abstract

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.

abstract

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.

abstract

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.

abstract

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten. Sie bieten ein großes Potenzial zur Steigerung von Qualität und Produktivität in der Software-Entwicklung. Dennoch bergen sie für viele Unternehmen noch bedeutende Herausforderungen und Risiken. Der Workshop beleuchtet aktuelle Erfahrungen mit Produktlinien und fördert den Dialog zwischen Praxis und anwendungsorientierter Forschung.

abstract
Software product lines are, by their very nature, complex software systems. Due to the interconnectedness of the various products in the product line any form of evolution becomes significantly more complex than in a single system situation. So far most work on product line evolution has focused on specific approaches to supporting special cases of the evolution problem. In this paper, we take a different approach and provide a broad taxonomy of requirements-driven evolution in software product lines. This serves as a basis for the identification of requirements on evolution support.

abstract
Software ist ein entscheidender Wertschöpfungs- und Kostenfaktor in industriellen Produkten. Dies gilt sowohl für Informationssysteme als auch für eingebettete Systeme wie Anlagensteuerungen oder Automobilkomponenten. Systematische Produktlinienentwicklung hat sich als probates Mittel erwiesen, gleichzeitig Kosten und Fehlerzahl zu senken.

abstract
The Software Engineering Institute (SEI) defines an SPL as a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission. A fundamental principle of SPLs is variability management, which involves separating the product line into three parts - common components, parts common to some but not all products, and individual products with their own specific requirements - and managing these throughout development. Using SPLs seeks to maximize reusable variation and eliminate wasteful generic development of components used only once. 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.

abstract
Customer Relationship Management (CRM) ist eine komplexe Domäne und erfordert entsprechende ITUnterstützung. Die arvato direct services GmbH ist europaweit einer der größten Dienstleister in diesem Bereich. Die adäquate IT-Unterstützung wird in der Regel individuell entwickelt, daher ist das Requirements Engineering (RE) entscheidend für den Erfolg in diesen Projekten. Um das RE bei arvato direct services zu stärken, wurde eine systematische Auswahl eines RE-Werkzeugs durchgeführt. Ausgehend von den Herausforderungen eines ITDienstleisters im CRM, wird auf die erhobenen Anforderungen an das gesuchte RE-Werkzeug und die Vorgehensweise bei der Auswahl eingegangen. Anschließend werden sowohl die Erfahrungen bei der Werkzeugauswahl als auch bei der Einführung des Werkzeugs dargestellt. Diese sind zum Teil auch über den Bereich des CRM hinaus übertragbar.

abstract
Die wirtschaftliche Bedeutung von Flexibilität und Adaptivität wächst. Viele Techniken wie Produktlinienentwicklung oder Service-orientierte Systeme wurden entwickelt, um mit dieser Herausforderung umzugehen. Aber auch Fragestellungen der Softwareevolution sind von Bedeutung. Diese Techniken und Entwicklungsansätze haben auch Auswirkungen auf das Requirements Engineering. Diese Herausforderungen stehen im Mittelpunkt des Arbeitskreises Adaptive Entwicklung und Systeme.

abstract
Technical systems are increasingly becoming an imminent part of human life. A growing trend is that systems are embedded in technical devices and working continuously without human intervention. However, this implies that these systems run for a long time without human control. As the environment changes, the systems need to adapt themselves. One approach to address these challenges is the use of service-oriented development paradigms. This paper highlights the challenges and research issues in the context of engineering adaptable, service-oriented systems. Challenges are identified based on the development plane they might appear in (i.e., service-, application-, and infrastructure engineering). We finish by discussing in detail the expected benefits and open research issues.

abstract
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 will 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.

abstract
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.

abstract
The goal of this article is to call attention to an area that is yet not sufficiently researched: product management for software product lines (SPLs). Many companies developing standardized software products have adopted product management as a function that coordinates research and development, marketing, sales, and software development. Even though this function coordinates all of these areas, it is traditionally mainly a marketing function and often organized as part of the marketing department. This may be sufficient for "normal" software products, but not in a SPL context, as we will discuss here.

abstract
The first step of requirements engineering is always: deciding what to build. While it may seem trivial, it is sometimes the hardest step in the whole project. In this report, we illustrate some experiences with a miniature creativity session that focused on the what-to-build question. The very limited time frame allowed at the same time very detailed controlling of the overall results. Thus, we can provide here quantitative results on the success of the workshop.

abstract
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 lead to the REMAP tool.

abstract
This report describes the reference model underlying the transformation between different models and the traceability between the same.

abstract
This report describes mapping of several requirements engineering models to the ForPICS reference model.

abstract
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.

abstract
Software product lines can effectively facilitate large-scale reuse and can thus bring about order of magnitude improvements in terms of time to market (TTM), costs, and quality. This comes at the price of a more complex development environment in which many interdependencies are created through shared generic assets. Owing to this complexity, the specific strategy chosen for product line development can be expected to have a strong impact on the benefits that can be gained from product line development. This is systematically studied in this work, as we vary different strategies and apply them to various forms of products lines. On the basis of the analysis of the performed simulations, we were able to determine optimal, heuristic strategies to the integrated management of the product line. As a result of the analysis, we identify strategies and guidelines that can be employed by practitioners in order to improve the success of their management of a software product line.

abstract
This report describes an approach for extraction of product line requirements based on existing user documentation. The approach we describe in this report supports capturing of the information found in user documentation of legacy systems, e.g., user manuals, and the specification of this information in product line models, using, e.g., Use Cases. The main goal of the approach is expert load reduction; as we found out during our product line technology activities at IESE that the domain experts are a serious bottleneck during the product line scoping and modeling activities. The approach is based on a variability modeling approach that allows integrating arbitrary modeling formalisms to capture the extracted requirements in a product line model. We propose a conceptual model describing the transition from user documentation to product line artifacts describing common and variable elements of a product line model. The approach uses extraction patterns that allow an easyidentification of text elements in user documents. The pattern are then used to create a significant part of the requirements specification and product line model, respectively and we present an extraction process that guides the user in using the pattern. In this report we present the approach itself and show the application of our approach for three case studies, one from the embedded/ mobile phone domain, two from the information system domain. The case studies have shown that the approach is applicable to information systems and embedded systems and that it produces relatively complete and correct results. With one of our case studies that was performed in real industrial settings we could not only show expert load reduction when applying the approach but also an overall time saving when applying the approach for product line scoping. A predecessor of this report with a different focus can be found in [JD03b].

abstract
This report provides insights into component-based product line engineering on the basis of a case study from the mobile phones domain. The reader follows the systematic creation of a hypothetical software product line according to the PuLSE and KobrA methods developed at Fraunhofer IESE. Scoping as well as Application and Framework Engineering are covered. Our goal was to provide as broad an overview as possible. For that reason many details haven been intentionally left out.

abstract
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.

abstract
In this paper we describe synergies and conflicts between the two at first sight incompatible fields Usability engineering and Product Line Engineering. We describe how both fields can benefit from each other and give requirements on an approach that covers both usability and product line aspects.

abstract
In diesem Artikel haben wir einen Ansatz zur effizienten Identifikation und Dokumentation von nichtfunktionalen Anforderungen vorgestellt, der insbesondere zur Erfassung von Zuverlässigkeits- und Sicherheitsanforderungen eingesetzt wird. Der Ansatz beruht auf erfahrungsoptimierten Qualitätsmodellen, Templates und Checklisten, die projektübergreifend eingesetzt werden. Diese werden in einer Tailoringphase an das jeweilige Projekt angepasst. Die Vorteile des Ansatzes gegenüber anderen Techniken zur Identifikation nichtfunktionaler Anforderungen sind: - Geringer Aufwand, durch Workshopformat, Fokussierung auf Kernanforderungen und vielfältige, erfahrungsbasierte Vorgaben - Verbesserungsorientierung durch die integrierte Iteration der Ausgangsdokumente - Testbarkeit durch die Fokussierung auf messbare NFRs.

abstract
In order to enable a smooth transition to product line development for an organization that so far only performed single system development, it is necessary to keep as many of the existing notations and approaches in place as possible.This requires adaptability of the basic variability management approach to the specific situation at hand. In this paper we describe an approach that enables homogenous variability management across the different lifecycle stages, independent of the specific notation. The approach is accompanied by a meta-model and a process for introducing the variability management approach by developing a notation-independent representation. This approach has so far been applied in several cases where our Product Line engineering method PuLSETM has been introduced into a software development organization.

abstract
Produktlinien-Ansätze bergen hohe Potentiale, um den Entwicklungsprozess und die Vermarktung ähnlicher Produkte zu optimieren. Die Einführung oder sogar die Umstellung auf eine Produktlinien-Entwicklung stellen jedoch eine große Herausforderung für jeden Geschäftsbereich einer Organisation dar. Diese wurden in einer Studie des GI-Arbeitskreises "Requirements Engineering für Produktlinien" untersucht. In diesem Artikel werden die Hauptprobleme analysiert und mögliche Lösungen vorgestellt.

abstract
Softwareproduktlinien unterstützen die Entwicklung mehrerer Produkte in Varianten. Diese Variantenbildung betrifft die Architektur der Software insgesamt, materialisiert sich für den Kunden aber vor allem in der Benutzungsoberfläche seiner" Lösung, bspw. durch die Unterschiede in der verfügbaren Funktionalität. Die Benutzungsfreundlichkeit der Features und Prozesse steht im Mittelpunkt des Usability Engineering, das Methoden zur Spezifikation und Bewertung der Benutzbarkeit von Software zur Verfügung stellt. Wir stellen hier ein integriertes Vorgehen zum Usability- und Produktlinienengineering im Rahmen der Anforderungsermittlung, -modellierung und -bewertung vor, das insbesondere für kleine und mittlere Unternehmen geeignet ist, für die eine integrierte Analyse aus Aufwands- und Kostengründen besonders angebracht ist.

abstract
Viele verschiedene Ansätze zur Modellierung von Anforderungen wurden im Verlauf der Zeit entwickelt. Doch der prinzipielle Zusammenhang zwischen diesen Notationen ist weitestgehend unklar. Im Rahmen der beschriebenen Arbeit wurde ein Referenzmodell abgeleitet, dass mehrere sehr verschiedene Notationen integriert. Das mittelfristige Ziel der beschriebenen Arbeiten ist eine Basis für die semi-automatische Transformation von Anforderungsmodellen zu bieten.

abstract
Product line engineering has become an important and widely used approach for efficiently developing portfolios of software products. The idea is to develop a set of products as a single, coherent development task from a core asset base (sometimes called a platform), a collection of artifacts specifically designed for use across a portfolio. This approach produces order-of-magnitude economic improvements compared to one-at-a-time software system development. Because the product line approach isn't limited to specific technical properties of the planned software but rather focuses on economic characteristics, high return on investment has become the anthem of the approach's protagonists. Our software product line cost model can calculate the costs and benefits (and hence the ROI) that we can expect to accrue from various product line development situations. It's also straightforward and intuitive.

abstract
BMW ist bekannt für seine Autos, Bosch für seine Motorensteuerungen und Microsoft für seine Betriebssysteme. Nahezu alle Firmen sind auf gewisse Bereiche spezialisiert und stellen nur eine kleine Zahl von Produktgruppen her. Je Produktgruppe kann die Zahl der Varianten jedoch gewaltig sein, so produziert Bosch alleine weit über tausend verschiedene Motorensteuerungen. Trotz dieser Vielzahl von Varianten überwiegen die Gemeinsamkeiten, da diese sie gerade zu einer Produktgruppe machen. Könnte man diese Gemeinsamkeiten systematisch ausnutzen indem man sie nur einmal entwickelt, so ergäbe sich hier ein enormes Wiederverwendungspotential! Genau das ist das Ziel der Produktlinienansätze wie PuLSE. Diese zielen darauf ab die Entwicklung einer Vielzahl von Systemen durch eine gemeinsame Referenzarchitektur zu integrieren. In der Praxis wurden so bereits Wiederverwendungsraten von 75% und mehr erreicht!

abstract
This paper summarizes the results of the "Gesellschaft für Informatik" (GI) working group on "Requirements Engineering for Software Product Lines" which is part of the requirements engineering group within in the GI. This work group met regularly to identify the key problems in product line engineering practice with potential (and proven) solutions. While this started originally as an effort focused purely on requirements engineering issues, we soon understood that we had to take a broader perspective due to the tight interconnection of requirements engineering with other issues in a product line context. We will provide a characterization of the different organizations that participated in this effort. This will demonstrate that overall a good coverage of different types of software organizations has been achieved. We will then provide an overview of the main problems in product line development. Based on both our own experience as well as our understanding of the technology,we derived and described potential solutions for the main problems.

abstract
The success of a product family depends greatly on the quality of its reference architecture. To achieve high-quality reference architectures, it is important to leverage the experience embodied in successful system from the same set of domains. However, the literature provides limited guidance on how to mine prior related systems for this specific purpose. This report addresses this issue by introducing an approach, which defines the views needed to express the architectures of a specific product family, recovers and analyzes these views, and provides a systematic process to define the reference architecture integrating the experience of past systems. This first version of this document focuses on architectural views: how they can be recovered, and how architectures can be analyzed and compared among themselves. The second version will emphasize the selection of reuse candidates and the development of the reference architecture for the product family.

abstract
This report summarizes the results of the GI working on "Requirements Engineering for Software Product Lines", a working of the GI 2.1.6. This work group met regularly to identify the key problems in product line engineering practice with potential (and proven) solutions. While this started originally as an effort focused purely on requirements engineering issues, we soon understood that we had to take a broader perspective due to the tight interconnection of requirements engineering with other issues in a product line context. We will provide a characterization of the different organizations that participated in this effort. This will demonstrate that overall a good coverage of organizational types has been achieved. In Section 3, we will then provide an overview of the main problems in product line development. These could be clustered in the following main problem categories: - Organization and Management - Requirements Engineering - Product-specific vs.Platform-specific Interests - Architecture These categories resulted from a systematic gathering of known problems along with a clustering. Based on both our own experience as well as our understanding of the technology we derived and described potential solutions for the main problems (cf. Section 5). As far as possible, we described necessary preconditions for the implementation of the solution approaches.

abstract
Software product lines (SPL) are a powerful concept for ensuring quality, economic efficiency, and manageability of families of software systems. SPL are relevant to large industrial enterprises that want to manage the development of their software-intensive systems well. It can also provide small start-ups with unique and striking business models. SPL is important for many companies in the software business. However, it is also a challenging technology, which is not always easy to implement and maintain. This article sheds light on SPL practices in today's software industry. Members from five different organizations have formed a workgroup that over a period of two years and a half have investigated and compared their SPL practices. The companies are as different as a global IT vendor (Hewlett-Packard), a leading supplier of automotive electronics (Robert Bosch GmbH), a large supplier of industrial energy solutions (represented by RWTH), a small company that develops softwarefor the on-line management of stock market information (Market Maker Software AG, this knowledge was provided by Fraunhofer IESE, a longstanding cooperation partner of the company) and a renowned software house (sd&m AG). Moreover, most workgroup members have contributed experience from more than one product family or business department allowing a rather broad overview of the state of software product line development in industrial practice. In the remainder of the article, company references are omitted to preserve anonymity of sensitive information. Clements and Northrop [4] define a software product line (SPL) as a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The workgroup, which met under the umbrella of the German Computer Society (GI, a sister organization of IEEE), set out to understand better howsoftware organizations can successfully set up and manage SPL. Key practice areas identified were: Organization and Support Practices, Practices of Balancing Platform versus Client Interests, Requirements Engineering Practices, Architectural Practices. For each area, the workgroup identified and compared the various practices found in their organizations. They also contrasted them with published reports of SPL practices. The result, which is reported in this article, provides a detailed look on the SPL state of practice.

abstract
Moderne Unternehmen bieten typischerweise eine stark diversifizierte Produktpalette an. Diese Notwendigkeit zur Entwicklung ähnlicher Systeme gilt natürlich auch für die Software. Der PuLSE-Eco1 Ansatz erlaubt es aus dieser Ähnlichkeit der Systeme maximalen wirtschaftlichen Nutzen zu ziehen. In dieser Zusammenfassung werden die Grundlagen des Ansatzes und seine wesentlichen Schritte erläutert. Der Ansatz wurde bereits erfolgreich in verschiedenen Unternehmen angewendet.

abstract
Product family development focusses on systematically developing reusable assets over time that are used in later projects to achieve benefits in terms of development effort, time-to-market reduction, and quality improvement. Consequently, the costs from the initial development for reuse are more than compensated by the derived benefits. The initial costs of development for reuse thus take the role of an investment in later product line benefits [CN01]. Therefore it is key to successful product family engineering to identify costs and benefits that are associated with product family development. This provides the basis for the subsequent optimization of the investment. In this deliverable we focus on the relationship between costs and benefits and show the implications and constraints on the associated investment decisions. We present a basic economic model, which provides the necessary background for understanding the impact of investments in a product family. This modelenables a systematic analysis of the product family situation and any consequences of product line investments. A key part of any investment decisions is to define the cost implications of these decisions. Unfortunately, there is no fixed model of product family development and consequently also no fixed model of product family development costs. Thus, we provide a reference model for product family costs in this deliverable together with a collection of the most important cost drivers that we could identify through expert interviews. This will support the organizations in systematically deriving product family cost models that are particularly adapted to their situation. In order to consistently and successfully evolve the product family infrastructure a strategy driven from a market point of view is required [KLD02]. This strategy is needed in order to decide on the appropriateness of an investment and to do so consistently over time. Thus product family strategy shouldbe the basis for any product family investment. In this deliverable we show approaches to derive such a product family strategy and combine it with the most advanced techniques for evaluating the potential benefits of the product family even when facing considerable uncertainties. As a result, this deliverable provides a basis for analyzing costs and benefits of product family development and enables to connect these aspects through an appropriate strategy that is optimally aligned with the existing product family and the company objectives.

abstract
Software organizations increasingly face the challenge to develop a large number of product variants for their customers. While many organizations still focus on a single product at a time, successful software organizations address the whole range of products in an integrated manner. If the existing reuse potential is adequately exploited, enormous cost savings and quality improvements can result. So far, the incremental introduction of a product line approach and the exploitation of the reuse potential mostly depended on the experience of the responsible personnel due to a lack of systematicapproaches. In this Ph.D. thesis we describe a disciplined approach for systematically planning the development of a software product line. This approach supports (1) identifying an incremental transitioning plan to product line development that determines the sequence and the scope of the introduction based on benefit-and-risk tradeoffs, and (2) determining the specific software components that should be developed for reuse, based on the specific development goals of the organization. The explicit link to the company goals guarantees that the resulting product line approach is optimally aligned to the strategy of the company.

abstract
In this paper we present a first-order cost model that describes the costs associated with developing products in a product line organization. The model addresses a number of issues that we present as a set of scenarios. The goal of this work is to develop models of varying granularity that support a manager"s decision-making needs at a variety of levels. The basis of these models is the relationships among the artifacts of the product line.

abstract
In order to enable a smooth transition to product development for an organization that so far did only perform single system development, it is necessary to keep as much of the existing notations and approaches in place as possible. In this position paper we propose a specific approach to the handling of variability which can be applied in the context of many different requirements engineering notations. This allows to extend existing requirements engineering notations to domain analysis notations.

abstract
In order to enable a smooth transition to product development for an organization that so far did only perform single system development, it is necessary to keep as much of the existing notations and approaches in place as possible. In this position paper we propose a specific approach to the comprehensive management of variability that enables to leave as much of the existing notations and approaches in place as possible. This approach has so far been applied in several cases where PuLSETM has been introduced into a software development organization.

abstract
As a relatively young discipline within software engineering, value-based software engineering does not yet have an established curriculum. The area draws on models and techniques in so many other disciplines that it is likely to be some time before a single individual is ready to prepare a course or a textbook. Several of the EDSER-4 participants expressed interest and enthusiasm for sharing the effort of developing curriculum and course materials. Inspired by the success of open source software development, especially the distributed collaboration, the free public access to the results, and the lack of administrative overhead; we decided to try to establish a similar community for curriculum development. This report describes progress to date, with emphasis on the community standards for cooperation and sharing.

abstract
Product line adoption is a key issue in product line development, as the right adoption approach is central to the overall success of product line de velopment. Thus, this is a strongly discussed area of product line engineering. While so far, guidelines and experiences on the best approach to product line adoption have been presented, no detailed quantitative model was provided. In this paper we present a quantitative model of the product line adoption problem. From this model we deduce general guidelines for product line adoption, particularly highlighting the role of the architecture in the cost-effective adoption of a product line.

abstract
Currently, the key approach to large-scale software reuse is product line development, an approach built upon the systematic development of building blocks for reuse. While most work on product lines focusses on technical issues, in the end they are built by by people. Winning them for product line development is a key issue in successfully introducing and institutionalizing product line development in an organization. This makes people issues a key concern in technology transfer. Based on our experience in technical transfer in the product line area we developed some hypotheses on how these people issues can be formed in a way favorable to product line development. In particular, we focus on the relation between the mind set of people, communication patterns, and the organizational structure. We then give concrete rules based on our own industrial experience as well as industry reports that support instutionalizing product line development.

abstract
Softwareproduktlinien entstehen wo auch immer Produkte in Varianten entwickelt werden. Dies stellt ein gigantisches Wiederverwendungspotential dar, schafft aber auch Schwierigkeiten, vor allem für den Anforderungsprozess. Daher wurde vor zwei Jahren ein GI-Arbeitskreis zu diesem Thema gegründet, der sich mit Problemen und Lösungen des Requirements Engineering für Produktlinien beschäftigt.

abstract
Software product lines are powerful tools for ensuring quality, economic efficiency, and manageability of families of software systems. SPL is important for many companies in the software business, ranging from small start-ups to large industrial enterprises. However, SPL is also a challenging technology that's not always easy to implement and maintain. Members from five different organizations formed a work group that investigated and compared their SPL practices over a period of two and a half years. The group identified key practice areas including organization and support, balancing platform versus client interests, requirements engineering practices, and architecture. The investigation's results detail the SPL state of the practice.

abstract
Often requirements engineering for product lines is treated as just a kind of requirements engineering. However, the specific situation of a product family poses specific demands on the underlying requirements engineering approaches. Foremost among them is of course the need to capture the envisioned degree of variability in the product line. As a result of this other aspects change as well, like requirements traceability, requirements negotiation, requirements management, and of course tool support. In this introduction we provide an overview of these views and describe in more detail the impact of product lines on requirements engineering.

abstract
Product line engineering is usually a very beneficial, but sometimes also a very risky endeavor, as there is no guarantee for economic success. In this paper, we describe an assessment approach that is designed to address the problem of quantifying reuse risks by providing an efficient means for determining the benefits and risks associated with a specific product line development. In particular, the approach supports decomposition and individual assessment of the technical domains of the product line, thus also furthering the incremental introduction of product lines. At the core of this paper is the development of the underlying assessment technology and how this approach was evolved over time based on multiple case studies. This evolution approach is rather general. Thus, we see the potential of applying these techniques also for evolving other assessment approaches.

abstract
Existing software cost estimation methods are far from being suitable for the reuse of software in the context of product line development. This paper points out the product line specific aspects of reuse compared to opportunistic reuse in single product development. Implications for existing estimation approaches are drawn and important topics of work are identified.

abstract
Due to the specific approach to reuse in product line engineering, this approach brings a specific point of view to reuse economics. As a consequence some established assumptions and abstractions of reuse economics that are valid in most opportunistic approaches to reuse must be revisited. The list of issues ranges from the basic estimation models used as input to reuse economics models to real options used for valuing uncertainty and flexibility in reuse. Some of the issues we uncover are also relevant for reuse economics in general.

abstract
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.

abstract
When developing a product line, the definition of an appropriate reference architecture that supports the required variabilities is of crucial importance to the success of the product line. In this paper we present an approach to the identification of the key variabilities and to determining the economic benefit of packaging these variabilities in terms of reusable components. This approach provides reusability requirements that can then be taken as an input to product line development. The analysis is based on the economics of the product line. Thus, the approach ensures the optimization of the economic benefit of a product line that is based on a reference architecture that takes these reusability requirements into account. In this paper, we will describe our approach for deriving the reusability requirements, discuss its relationship to different possible investment scenarios, and study the results of the application of our approach in some case studies.

abstract
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.

abstract
An organization faces many challenging decisions when transitioning to product line development: What is the best way to adopt a product line approach? How can we avoid disrupting regular product development? Once adopted, how should we evolve the product line? The article discusses how to optimize a product line's economic benefits by considering the adoption context and using product line scoping techniques.

abstract
This report details the experience of a small company, Market Maker Software AG of Kaiserslautern, Germany, as they adopted and used the paradigm of software product lines to help their business grow successfully into a new market area. While software product lines are often associated with large, traditional software organizations, the experience of Market Maker and other small companies like it shows that software product lines represent an ideal development concept for companies of all sizes. This case study reports on the history of the company, how it came to adopt product lines as its prominent development strategy, the role of the key individuals involved, and how they met and overcame various technical challenges. The report concludes with a section analyzing the Market Maker approach.

abstract
Product Line Mapping is an approach for rapidly capturing and describing a line of products. However, the approach goes beyond the realms of traditional requirements.

abstract
Die mittelständische Wirtschaft kann mittel- und langfristig nicht mit den großen internationalen Firmen im Bereich der Massenfertigung oder durch das Angebot von Standardprodukten konkurrieren. Ihre Stärken liegen vielmehr im Angebot kundenspezifischer Speziallösungen in Einzel- bzw. Kleinserien. Im Rahmen dieses Forschungsvorhabens wurden existierende Forschungslösungen für die Anwendung ingenieurmäßiger Grundsätze auf die Entwicklung von Software übertragen. Besonderes Augenmerk lag dabei auf der ökonomischen Entwicklung kundenspezifischer Varianten.

abstract
Product line development requires a certain amount of up front investment in order to make assets reusable. This investment often keeps organizations from planning and realizing their products in a product line. But there are also major advantages of doing product line development which are often not taken into account when deciding for or against product lines. In this paper we present problems that need to be addressed in the strategic planning of transition towards product lines. These aspects include the involvement of uncertainty, the interdependence of technical solution and decision making, and the interdependence among the decision making and the market aspects. An approach which covers these aspects will determine an objective valuation of a product line.

abstract
In this paper we describe an initial model of product line economics, which aims at filling exactly this gap. The model integrates characteristics of the software process with aspects of the market, where the later are used for valuation. We present the model in three layers, each adding a layer of issues that are taken into account to the previous one. This layering mirrors the levels of complexity in existing models of reuse economics

abstract
Software Product Lines is still a new field within software reuse that aims at large-scale, systematic reuse. Hugh 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.

abstract
In this report, we described the basis for developing quality models that can be used by the PuLSE-Eco scoping approach to provide a quantitative basis for the scoping of the asset base. We described the general structure of these models as well as the necessary notation and terminology to discuss the specific models and perhaps needed deviations from the standard model. In particular, we discussed the process aspects of product line development, we discussed the general structure of product line quality models, and discussed how specific quality models can be developed. Further, we discussed in detail the relationship between the meta-quality model and the specific quality model guides and how these can be instantiated for the specific projects.

abstract
As opposed to traditional domain analysis approaches [Ara89, KCH+90,PD87], the product line mapping approach starts by thoroughly analyzing the product development plans. Thus it is akin to industrial strength domain analysis approaches like ODM [ODM96] or Synthesis [RSP93], but actually goes further in its product orientation. However, the approach given here is explicitly not meant as a full-fledged domain analysis approach, but aims at identifying solely the information necessary as a prerequisite to scoping. Thus, the aimed-at endresult is solely to identify the major products and how they differ in terms of features they support. For identifying the products, the relevant subdomains and their interrelationships the following approach is used: 1 Identify the existing and future systems that may be relevant to the product line. 2 Develop an overview plan of these products. 3 Identify the major functions/features that are relevant to the functionality of these systems. (Thisencompasses end-user features as well as internal functions.) 4 Group these functions into major functional areas (initial domains). 5 Develop an overview of the domains that shows the interrelations among them. 6 Analyze the information for the presence of additional internal domains. 7 Ensure consistency with existing systems. 8 Develop initial product/function matrix In the following sections we describe in more detail how to perform each of these steps.

abstract
In this paper we give a sketch of a new quantitative approach which can be used to identify and cluster system functionality that should be developed in a reusable fashion, for example, when starting product line development. We demonstrate the applicability of the approach and its validity in a case study.

abstract
Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in practice strong interactions between the individual phases become apparent. In particular, how implementation is done has a strong impact on economic aspects of the project and thus how to adequately plan it. Hence, assessing these relationships adequately in the beginning has a strong impact on performing a product line project right. In this paper we present a framework that helps in exactly this task. It captures on an abstract level the relationships between scoping information and implementation aspects and thus allows to quickly analyze implementation aspects of the project. We will also discuss the application of our framework to a specific industrial project.

abstract
It is well-known that software processes need to be adapted to the specifics of the organization, the application domain, and the development techniques of the environments in which they are used. This is particularly important for reuse processes as they impact the whole software life-cycle and the reuse of artifacts creates additional relationships among multiple process instances (projects). Nevertheless the support for tailoring existing reuse approaches is at best weak. As a consequence of this realization we made customization support for the method a first rate objective while developing the Product Line Software Engineering method (PuLSE). The technology used for customization is called PulSE Baselining and Customization (PuLSE-BC). This approach relies on an explicit characterization of the environment and the explicit connection of these characteristics to customizable properties of a process. In this paper, we describe the technical foundations of this approach and illustrate them with an example.

abstract
Determining the scope of a product line is a core activity in product line development, as it has a major impact on the economic results of the project. Only recently an approach was proposed that allows to base this decision explicitly on a detailed analysis of the relevant business goals [2]. As the approach requires gathering and evaluating a lot of data, tool support becomes mandatory. In this paper, we describe the tool PuLSE-BEAT, which was specifically developed to address this need.

abstract
Software Product Line development is a rather new topic area within domain-specific software engineering that builds on previous work in domain engineering. A crucial step in developing a product line is the scoping step, which aims at determining the boundaries for the product line. This is one of the core planning activities which may determine success or failure of the whole product line effort. In this paper, we aim at analyzing the existing body of knowledge on product line scoping. As the relation to domain engineering is very tight we will also include domain scoping approaches in our analysis. Further, we will look at product line scoping related activities in other fields of study besides software engineering. As a result of this survey we provide a taxonomy of existing approaches both on a problem level, as well as on a solution level, discuss the relative advantages of the various approaches, and show some ways on using the results of this paper for enhancing existing scoping approaches and developing new approaches.

abstract
Scoping is a core planning activity in product line development. It is central to determining and optimizing the economical benefits of product line development. In this position paper we discuss the requirements on a sound and practically useful product line development approach and will propose a specific approach which fulfills these requirements.

abstract
In this paper, we describe, using the Quality Improvement Paradigm (QIP), how an improvement project aimed at improving the modeling and documentation approach of a medium-sized company (MSuD) 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.

abstract
Small and medium-sized enterprises work under heavy constraints: They need to be very flexible and fast in their reaction to customer requests, thus limiting their possibility for long-term planning. In a partially publicly funded project, the authors have started to apply their Product Line Software Engineering method developed at Fraunhofer IESE, in six small and medium-sized companies addressing six different domains. The article presents first experience and lessons learned from 24 months of project work; including first results within the companies.

abstract
Product line scoping is a critical activity because it elicits the common realms upon which the different products of a product line can be optimally engineered with respect to economies of scope. This, in turn, upper bounds the overall economic benefits that can be accrued from product line based development. Inherently, product line scoping is difficult because of the complexity of the factors that must be taken into account. Many are not known a priori. Traditional scoping approaches (from domain engineering) have focused on the notion of application domains. However, domains proved difficult to optimally scope and engineer from an enterprise standpoint because a domain captures extraneous elements that are of no interest to an enterprise which must focus on particular products, whether existing, under development, or anticipated. Hence, the domain view provides a flawed economic basis for making a scoping decision. We introduce in this paper PULSE-Eco, a technique especially developed to address the aforementioned issues. Its main characteristics are: a complete product-centric orientation done via product maps, the separation of concerns achieved through the definition and operationalization of strategical business objectives, and last, diverse types of analyses performed upon product maps allowing scoping decisions based on these objectives. We illustrate the technique with a running example.

abstract
Software product lines have recently been introduced as one of the most promising advances for efficient software development. Yet upon close examination, there are few guidelines or methodologies available to develop and deploy product lines beyond existing domain engineering approaches. The latter have had mixed success within commercial enterprises because of their deployment complexity, lack of customizability, and especially their misplaced focus, that is on domains as opposed to products. To tackle these problems we developed the PuLSETM (Product Line Software Engineering) methodology for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. This is achieved via product-centric focus throughout the phases of PuLSETM, customizability of its components, incremental introduction capability, maturity scale for structured evolution, and adaptations to a few main product development situations. PuLSETM is the result of a bottom-up effort: the methodology captures and leverages the results (the lessons learned) from our technology transfer activities with our industrial customers. We present in this paper the main ideas behind PuLSETM and illustrate the methodology with a running example taken from our transfer experience.

abstract
In this paper, we discuss the view that planning software development - and particularly software reuse - should be based not on standardized criteria, but on those criteria that are particularly relevant to the environment for which the planning is done. We also describe how this tailoring of the decision-making process is performed in PuLSE-Eco, an approach for scoping software product lines developed at the Fraunhofer IESE.

abstract
When attempting to perform a domain analysis, practi tioners face a difficult choice. Which of the existing methods should be chosen and will it work in their particular envi ronment? A number of domain analysis approaches have been proposed in the literature. Most argue that they are appli cable to any domain and situation. Yet, we found that this was not always the case as illustrated by the practical situ ations our technology transfer group faced. We observed that depending on the context, each method possesses strengths and weaknesses. The optimal solution should then be to combine parts of these methods in a way specifically adapted to the project situation encountered. Using a case study where we applied three major ap proaches to a particular domain, we argue for a customiz able domain analysis approach that would be instantiated depending both on the nature of the domain(s) and on the project characteristics in which it would be applied.

abstract
Since we consider theory refinement (TR) as a possible key concept for a methodologically clear view of knowledge-base maintenance, we try to give a structured overview about the actual state-of-the-art in TR. This overview is arranged along the description of TR as a search problem. We explain the basic approach, show the variety of existing systems and try to give some hints about the direction future research should go.

abstract
In this article, a model of information processing in human creativity, called the IPC-model, is presented. This model has been developed based on a review of psychological studies and models. Using this model as a baseline deficiencies of current AI systems are identified and several approaches for providing them with a higher level of creativity are proposed. A discussion of the range of applicability of these approaches and their implications for the overall system behaviour is provided.

abstract
Since creativity is the ability to produce something novel and unexpected, it has always fascinated people. Consequently, efforts have been made in AI to invent creative computer programs. At the same time much effort was spent in psychology to analyze the foundations of human creative behaviour. However, until now efforts in AI to produce creative programs have been largely independent from psychological research. In this study, we try to combine both fields of research. First, we give a short summary of the main results of psychological research on creativity. Based on these results we propose a model of creative process that emphasizes its information processing aspects. Then we describe AI approaches to the implementation of the various components of this model and contrast them with the results of psychological research. As a result we will not only reveal weakness of current AI systems hindering them in achieving creativity, but we will also make plausible suggestions - based on psychological research - for overcoming these weaknesses.

abstract
We propose a method for constructing test sets for deciding whether a term is ground reducible w.r.t. an arbitrary, many-sorted, unconditional term rewriting system. Our approach is based on a suitable characterization of such test sets using a certain notion of transnormality. It generates very small test sets and shows some promise to be an important step towards a practicable implementation.