Platform strategies, originating from pure hardware platforms, have proven effective in optimizing development processes in the automotive domain. Over time, software-driven innovations have emerged as the primary origin of novel features in automotive systems, as exemplified by functionalities like lane-keeping assistants, traffic-sign recognition, and the prospect of autonomous driving. To address the growing importance of software, automotive manufacturers progressively incorporate principles of software-platform engineering, for instance, by adopting software product lines. However, a notable gap still persists in thoroughly managing all facets of a cyber–physical automotive system, which involves hardware, software, electronics, variability, and their complex interactions. Efforts to address this gap and to achieve holistic platform management have resulted in electrics/electronics platforms to emerge in the automotive domain; but these platforms and transitioning towards them have not been fully worked out, yet. In this article, we contribute to addressing this gap by proposing a methodology for holistic electrics/electronics platform release management. We present detailed explanations of our methodology and its individual guidelines, which we derived from practical requirements and subsequently validated through expert assessments. Specifically, we conducted a series of workshops involving eight practitioners at a large international automotive manufacturer. Our methodology and insights can help other researchers and practitioners who work on adopting electrics/electronics platform management and emphasize possible directions for future research.

• Software has become a primary concern in the automotive industry. • There is a lack of decision-making support for managing automotive platforms. • Practitioners need efficient processes and tools for product-structuring concepts. • We prioritize requirements for decision making for electrics/electron platforms. With modern vehicles becoming increasingly software driven, long-standing automotive manufacturers face challenges in integrating software into their historically hardware-centered platforms. Even though hardware and software platforms leverage the same ideas, manufacturers must still unify hardware, software, and electrics/electron components; as well as their intricate interconnections and variability. To address this challenge, automotive manufacturers are adopting product-structuring and variant-management concepts from different areas to develop a holistic platform perspective. Here, particularly decision making has manifested as a key problem to inform the involved stakeholders and assess different options. Specifically, simply adding software to a static hardware platform is insufficient to address the current digital transformation in the automotive industry: the new platform dimensions must be understood, changes balanced against each other, and necessary rework defined to achieve holistic platform management. In this article, we contribute to tackling this problem by presenting a mixed-method study through which we derived a set of requirements to support decision-making for today’s automotive electrics/electron platforms. We used requirements and insights from our previous work, which we refined and validated via expert workshops and a questionnaire with 76 experts from the automotive industry. Besides confirming and validating our previous work, we contribute a new consolidated overview of requirements and criteria together with a prioritization by practitioners. The findings of our work offer valuable guidance for automotive practitioners, particularly for adopting product-structuring concepts like electrics/electron platforms and making decisions in the process. Our contributions further substantiate existing evidence and can guide research on developing decision-making techniques for complex electrics/electron platforms.

The rapidly growing number of scientific publications poses numerous challenges for researchers engaged in literature analyses. Structured methodologies like systematic literature reviews are becoming increasingly expensive, considering their attempt to cover all relevant publications. Despite the increasing efforts needed, the importance of literature reviews also leads to an increasing growth in their number. While there are support techniques (e.g., guidelines, tools, checklists) for conducting literature analyses, a concise and clear overview of such techniques for assessing the quality of the analysis itself is missing. Such an overview can help researchers identify techniques for their work, understand ambiguities between them, support peer reviews, and guide future research by highlighting open gaps. In this paper, we address this lack of an overview by identifying existing techniques for assessing the quality of systematic literature reviews, comparing their properties, and discussing their pros and cons. For this purpose, we elicited 14 techniques through a systematic literature search covering 15 years (2007–2021). Overall, our contributions can help researchers identify feasible techniques for assessing the quality of literature analyses and can guide the development of new techniques, thereby facilitating the conduct and improving the quality of literature analyses.

Standardized connections are intended to reduce implementation time. This is achieved through approaches such as the Asset Administration Shell (AAS). Although there is a substantial amount of literature on how this can be accomplished with solutions like the AAS, there are no quantitative studies indicating the extent to which standardization can reduce implementation time. We aim to demonstrate this through an experiment. We believe it is important to engage the community in a critical discussion about the experiment design before we proceed with its execution. This paper examines two designs of experiments to measure implementation time in comparison to manufacture-specific interfaces.Many issues concerning the setup are open for discussion. It becomes clear that to achieve a valid measurement, multiple experiments must be conducted at various field levels and with different experimental subjects. We want to encourage researchers to engage this dialogue and these studies. Future research will execute the presented experiments.

In the past years, a growing number of highly-automated systems has build on Artificial-Intelligence (AI) capabilities, for example, self-driving vehicles or predictive health-state diagnoses. As for any software system, there is a risk that misbehavior occurs (e.g., system failure due to bugs) or that malicious actors aim to misuse the system (e.g., generating attack scripts), which can lead to safety and security incidents. While software safety and security incidents have been studied in the past, we are not aware of research focusing on the specifics of AI incidents. With this paper, we aim to shed light on this gap through a case survey of 240 incidents that we elicited from four datasets comprising safety and security incidents involving AI from 2014 to 2023. Using manual data analyses and automated topic modeling, we derived relevant topics as well as the major issues and contexts in which the incidents occurred. We find that the topic of AI incidents is, not surprisingly, becoming more and more relevant, particularly in the contexts of autonomous driving and process-automation robotics. Regarding security and its intersection with safety, most incidents connect to generative AI (i.e., large-language models, deep fakes) and computer-vision systems (i.e., facial recognition). This emphasizes the importance of security to also ensure safety in the context of AI systems, with our results further revealing a high number of serious consequences (system compromise, human injuries) and major violations of confidentiality, integrity, availability, as well as authorization. We hope to support practitioners and researchers in understanding major safety and security issues to support the development of more secure, safe, and trustworthy AI systems.

Modern production systems demands advanced data networking. Concepts like the unified namespace help in reconfiguring the data flow of different hierarchy levels into a centralized data space. This data space connects data stakeholders, including Manufacturing Execution System and Supervisory Control and Data Acquisition systems on one side, and assets, sensors, and actuators on the other. The lack of standardization leads to individualistic solutions in the existing solutions. The concept of the Asset Administration Shell provides standardization for asset-specific data. This paper presents the design and implementation of a “AAS-based Unified Namespace” concept leveraging the Asset Administration Shell, along with a standardized structure based on ISA-95. The focus of this work is on the effective handling of event data for its relevance in real-time decision-making. Therefore, we focus on the effective handling of event data.

The COVID-19 virus has caused a global pandemic that has heavily impacted daily life. Rapid advances in testing and vaccinating led to an additional use case besides the well-known contact-tracing apps: certificate-verification systems. Verification systems are often commissioned by local authorities to enable more public life, and are often developed by smaller organizations or startups. So, the development of verification systems differs from other software projects, featuring interesting and unique properties. In this article, we present an experience report on the development of one verification system by a German startup, focusing on three properties: working in a pandemic, developing a product for handling a pandemic, and the startup context. To this end, we surveyed nine startup developers and analyzed the results with two experts from the startup. We found that the developers focused on fast delivery to cope with the time pressure of releasing the verification system, which is why some phases of typical development processes were hardly carried out. As a result, while the verification system is successful, we also identified negative effects of the properties (e.g., programming mistakes, well-being). We discuss our findings to guide researchers and practitioners in preparing for software engineering in future emergencies. Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.

Academic research, by its nature, is notorious for being a challenging and demanding field. However, these challenges may become more complicated for certain groups of researchers rather than others. For instance, junior researchers who make up a large group of the current scientific community, particularly in the computer science domain, may face various types of impediments. A notable hindrance to realizing the impediments is the difficulty of precisely delineating them. In this paper, we report an empirical investigation to measure the level of awareness of any kind of obstacles that might hinder junior researchers’ publishing ability and disturb their involvement. For this purpose, we conducted a survey targeting active researchers from the Software Engineering field with a total of 52 respondents. We mainly focus on two types of aspects: peer reviewing models and collaboration. Our findings indicate that junior researchers seem to be more comfortable with double-blind reviewing models with more than half (approximately 67.2%) of them voting in favor of this model. The results also show a significant agreement that a lack of experience especially in academic writing and supervision problems constitute the most influential barriers to publishing. Our findings can help understand the needs of junior researchers and provide insights into our research community and its specific groups.

Background. The constantly increasing number of scientific publications poses challenges for researchers to monitor, select, and assess the publications relevant for their own research. Several guidelines for assessing publications manually during a literature analysis exist, with researchers proposing (semi-)automated techniques to facilitate such assessments. Aims. Still, research indicates that current techniques require further improvements to facilitate the analysis of large sets of publications. In this paper, we propose a semi-automatic technique with which we aim to improve in this direction by facilitating the selection and assessment of publications. Method. Our technique uses publicly available data of a publication, namely citation counts, article-level metrics, venue metrics, and altmetrics, to guide an analyst in assessing its relevance and impact. To evaluate the feasibility of our technique and the included metrics, we performed an experimental analysis to automatically assign ratings to the retrieved publications. Results. The results indicate that our technique can help an analyst in assessing publications, and reduce manual effort. Through our technique, we achieve an average accuracy of 53 % with a recall of 71 %. While precision (14 %) and F1-score (21 %) are—not surprisingly, due to the high number of irrelevant results returned by automatic searches in digital libraries—low, we see an improvement of these values for more recent reviews for which we could collect more complete data. However, some manual effort is still required for the final selection of papers. Conclusions. While it is not possible to achieve full automation for selecting and quality assessing publications, we can see that our metrics-based technique can be a helpful means to provide an initial rating for the analyst. Also, incorporating altmetrics seems to be a promising addition to rate comparably recent publications, helping researchers to further facilitate the execution of literature analyses.

The rapidly expanding corpus of scientific publications poses various types of challenges for researchers, mostly concerning the selection and assessment of publications relevant to their research topic. Therefore, the scientific community is actively involved in proposing solutions for effectively retrieving promising publications. Traditional bibliometrics, such as citations, are most commonly used for evaluating the research impact of a publication, in spite of rightful criticism. More recently, the newly introduced altmetrics (e.g., Tweets) have gained popularity and are constantly being investigated to understand their usefulness and potential benefits for assessing the significance of publications. Researchers argue that altmetrics can be used to reflect the importance of a publication beyond the boundaries of traditional bibliometrics. However, it is important to be aware of the limitations and threats arising from altmetrics, too. In this paper, we present a survey analysis to understand the usefulness of altmetrics and determine their ability of being used as quality indicators for scientific research. Based on the findings, we discuss whether altmetrics can support the quality assessment during literature analyses to assist the analyst by reducing the required time and manual effort.

Software features are intuitive entities used to abstract and manage the functionalities of a software system, for instance, in product-line engineering and agile software development. Nonetheless, developers rarely make features explicit in code, which is why they have to perform costly program comprehension and particularly feature location to (re-)gain knowledge about the code. In a previous paper, we conducted an experiment on how explicit feature traces impact developers' program comprehension by facilitating feature location. We found that annotating features in code improved program comprehension, while decomposing them into classes had a negative impact. Additionally, but not reported in that paper, we were concerned with understanding whether the different traces would impact developers' memory regarding the code and its features. To this end, we repeatedly asked our participants questions about the code on different levels of detail within time periods of two weeks. Since developers' memory decays over time, we expected that our participants would provide fewer correct answers over time, with differences depending on the feature traces in their code. Unfortunately, the actual results were inconclusive and up for interpretation, particularly due to challenges in designing an experiment on developers' memory. In this paper, we discuss our experimental design, the null results, and challenges for improving the methodology of future studies in this direction.

Abstract Feature models are a helpful means to document, manage, maintain, and configure the variability of a software system, and thus are a core artifact in software product-line engineering. Due to the various purposes of feature models, they can be a cross-cutting concern in an organization, integrating technical and business aspects. For this reason, various stakeholders (e.g., developers and consultants) may get involved into modeling the features of a software product line. Currently, collaboration in such a scenario can only be done with face-to-face meetings or by combining single-user feature-model editors with additional communication and version-control systems. While face-to-face meetings are often costly and impractical, using version-control systems can cause merge conflicts and inconsistency within a model, due to the different intentions of the involved stakeholders. Advanced tools that solve these problems by enabling collaborative, real-time feature modeling, analogous to Google Docs or Overleaf for text editing, are missing. In this article, we build on a previous paper and describe (1) the extended formal foundations of collaborative, real-time feature modeling, (2) our conflict resolution algorithm in more detail, (3) proofs that our formalization converges and preserves causality as well as user intentions, (4) the implementation of our prototype, and (5) the results of an empirical evaluation to assess the prototype’s usability. Our contributions provide the basis for advancing existing feature-modeling tools and practices to support collaborative feature modeling. The results of our evaluation show that our prototype is considered helpful and valuable by 17 users, also indicating potential for extending our tool and opportunities for new research directions.

Developing software systems in large organizations requires the cooperation of various organizational units and stakeholders. As software-development processes are distributed among such organizational units; and are constantly transformed to fulfill new domain regulations, address changing customer requirements, or adopt new software-engineering methods; it is challenging to ensure, measure, and steer—essentially monitor—the quality of the resulting systems. One means to facilitate such monitoring throughout whole software-development processes are key performance indicators, which provide a consolidated analysis of an organizations’ performance. However, it is also challenging to introduce key performance indicators for the software development of a large organization, as they must be implemented at and accepted by all relevant organizational units. In this paper, we report our experiences of introducing new key performance indicators for software-development processes at Volkswagen Financial Services AG, a large organization in the financial sector. We describe i) our methodology; ii) how we customized and use key performance indicators; iii) benefits achieved, namely improved monitoring and comparability, which help to define quality-improving actions; iv) and six lessons learned. These insights are helpful for other practitioners, providing an overview of a methodology they can adopt to assess the feasibility of key performance indicators as well as their benefits. Moreover, we hope to motivate research to investigate methods for introducing and monitoring key performance indicators to facilitate their adoption.

Program comprehension is an important, but hard to measure cognitive process. This makes it difficult to provide suitable programming languages, tools, or coding conventions to support developers in their everyday work. Here, we explore whether functional magnetic resonance imaging (fMRI) is feasible for soundly measuring program comprehension. To this end, we observed 17 participants inside an fMRI scanner while they were comprehending source code. The results show a clear, distinct activation of five brain regions, which are related to working memory, attention, and language processing, which all fit well to our understanding of program comprehension. Furthermore, we found reduced activity in the default mode network, indicating the cognitive effort necessary for program comprehension. We also observed that familiarity with Java as underlying programming language reduced cognitive effort during program comprehension. To gain confidence in the results and the method, we replicated the study with 11 new participants and largely confirmed our findings. Our results encourage us and, hopefully, others to use fMRI to observe programmers and, in the long run, answer questions, such as: How should we train programmers? Can we train someone to become an excellent programmer? How effective are new languages and tools for program comprehension?

Developers spend a substantial amount of their time with program comprehension. To improve their comprehension and refresh their memory, developers need to communicate with other developers, read the documentation, and analyze the source code. Many studies show that developers focus primarily on the source code and that small improvements can have a strong impact. As such, it is crucial to bring the code itself into a more comprehensible form. A particular technique for this purpose are explicit feature traces to easily identify a program’s functionalities. To improve our empirical understanding about the effects of feature traces, we report an online experiment with 49 professional software developers. We studied the impact of explicit feature traces, namely annotations and decomposition, on program comprehension and compared them to the same code without traces. Besides this experiment, we also asked our participants about their opinions in order to combine quantitative and qualitative data. Our results indicate that, as opposed to purely object-oriented code: (1) annotations can have positive effects on program comprehension; (2) decomposition can have a negative impact on bug localization; and (3) our participants perceive both techniques as beneficial. Moreover, none of the three code versions yields significant improvements on task completion time. Overall, our results indicate that lightweight traceability, such as using annotations, provides immediate benefits to developers during software development and maintenance without extensive training or tooling; and can improve current industrial practices that rely on heavyweight traceability tools (e.g., DOORS) and retroactive fulfillment of standards (e.g., ISO-26262, DO-178B).

Summary Mutation testing is an approach to assess the quality of test cases. Mutants are modified versions of a system that ideally compose faulty behaviour. Test cases for a system are effective if they kill these mutants. For software product lines, several works have addressed mutation testing to inject variability faults, which may only exist in some variants. These works focus on variability models or specific implementation techniques. In contrast, feature‐oriented programming has been rarely investigated, wherefore, we (1) derive corresponding mutation operators, (2) investigate the feasibility of our proposed and conventional operators on 4 software product lines, and (3) discuss open challenges in mutation testing of software product lines. The results show that our proposed operators are suitable to cause variability faults and extend the capabilities of conventional operators. Nonetheless, mutation testing of software product lines is comparably expensive, due to a high number of variants and mutants—resulting in equivalence and redundancy.

Intel's novel Software Guard eXtensions (SGX) enable secure and trusted execution of services, thereby paving the way to outsource sensitive data processing to external data centers. While SGX promises trusted execution close to native speed, frequent I/O operations and memory usage beyond a hardware-dependent threshold of currently 92 MiB result in substantial performance degradation. For memory-intensive workloads such as key-value stores and databases these penalties can be prohibitively high. We present STANlite - an in-memory database engine for SGX-enabled secure data processing in rack-scale environments. STANlite performs efficient user-level paging, whenever a database workload requires more space than the performance-friendly in-memory state size. Furthermore, STANlite smartly combines the properties of Remote Direct Memory Access (RDMA) and SGX to reduce the overhead of network-based I/O operations. While SGX usually provides confidentiality and integrity at the same time, STANlite enables a purely integrity preserving data management mode for additional performance. Finally, STANlite features a small trusted computing base and is memory-efficient, as it extends SQLite, a database for embedded use. We evaluated STANlite in terms of query response time. It outperforms a vanilla SGX-based SQLite version by 1.79x for microbenchmarks and 2.44x for TPC-C.

Being familiar with the source code of a program comprises knowledge about its purpose, structure, and details. Consequently, familiarity is an important factor in many contexts of software development, especially for maintenance and program comprehension. As a result, familiarity is considered to some extent in many different approaches, for example, to model costs or to identify experts. Still, all approaches we are aware of require a manual assessment of familiarity and empirical analyses of forgetting in software development are missing. In this paper, we address this issue with an empirical study that we conducted with 60 open-source developers. We used a survey to receive information on the developers' familiarity and analyze the responses based on data we extract from their used version control systems. The results show that forgetting is an important factor when considering familiarity and program comprehension of developers. We find that a forgetting curve is partly applicable for software development, investigate three factors - the number of edits, ratio of owned code, and tracking behavior - that can impact familiarity with code, and derive a general memory strength for our participants. Our findings can be used to scope approaches that have to consider familiarity and they provide insights into forgetting in the context of software development.

In practice, organizations often rely on the clone-and-own approach to reuse and customize existing systems. While increasing maintenance costs encourage some organizations to adopt their development processes towards more systematic reuse, others still avoid migrating to a reusable platform. Based on our experiences, a barrier preventing the adoption of software product lines is the fear of introducing new and more problematic bugs---during the migration or later on. We are aware of several works that automate software-product-line adoption, but they neglect the migration and maintenance of test cases. Automating the refactoring of tests can help to facilitate the adoption barrier, compare the quality after migrations, and support maintenance. In this vision paper, we i) discuss open research challenges that are based on our experiences and ii) sketch a first framework to develop automated solutions. Overall, we aim to illustrate our idea and initiate further research to facilitate the adoption and maintenance of software product lines.

Software-product-line engineering is an approach to systematically manage reusable software features and has been widely adopted in practice. Still, in most cases, organizations start with a single product that they clone and modify when new customer requirements arise (a.k.a. clone-and-own). With an increasing number of variants, maintenance can become challenging and organizations may consider migrating towards a software product line, which is referred to as extractive approach. While this is the most common approach in practice, techniques to extract variability from cloned variants still fall short in several regards. In particular, this accounts for the low accuracy of automated analyses and refactoring, our limited understanding of the costs involved, and the high manual effort. A main reason for these limitations is the lack of realistic case studies. To tackle this problem, we provide a set of cloned variants. In this paper, we characterize these variants and challenge the research community to apply techniques for reverse engineering feature models, feature location, code smell analysis, architecture recovery, and the migration towards a software product line. By evaluating solutions with the developer of these variants, we aim to contribute to a larger body of knowledge on this real-world case study.

The source code of highly-configurable software is challenging to comprehend, analyze, and test. In particular, it is hard to identify all configurations that comprise a certain code location. We contribute PCLocator, a tool suite that solves this problem by utilizing static analysis tools for compile-time variability. Using BusyBox and the Variability Bugs Database (VBDb), we evaluate the correctness and performance of PCLocator. The results show that we are able to analyze files in a matter of seconds and derive correct configurations in 95% of all cases.

Due to its fast and simple applicability, clone-and-own is widely used in industry to develop software variants. In cooperation with different companies for thermoelectric products, we implemented multiple variants of a heat monitoring tool based on clone-and-own. After encountering redundancy-related problems during development and maintenance, we decided to migrate towards a software product line. Within this paper, we describe this case study of migrating cloned variants to a software product line based on the extractive approach. The resulting software product line encapsulates variability on several levels, including the underlying hardware systems, interfaces, and use cases. Currently, we support monitoring hardware from three different companies that use the same core system and provide a configurable front-end. We share our experiences and encountered problems with cloning and migration towards a software product line---focusing on feature extraction and modeling in particular. Furthermore, we provide a lightweight, web-based tool for modeling, configuring, and implementing software product lines, which we use to migrate and manage features. Besides this experience report, we contribute most of the created artifacts as open-source and freely available for the research community.

FeatureIDE is an open-source framework to model, develop, and analyze feature-oriented software product lines. It is mainly developed in a cooperation between TU Braunschweig, University of Magdeburg, and Metop GmbH. Nevertheless, many other institutions contributed to it in the past decade. Goal of this tutorial is to illustrate how FeatureIDE can be used to clean variable code, whereas we will focus on dependencies in feature models and on variability implemented with preprocessors. The hands-on tutorial will be highly interactive and is devoted to practitioners facing problems with variability, lecturers teaching product lines, and researchers who want to save resources in building product-line tools based on the FeatureIDE infrastructure.

Summary Software product lines enable developers to derive similar products from a common code base. Existing implementation techniques can be categorized as composition‐based and annotation‐based approaches, with both approaches promising complementary benefits. However, annotation‐based approaches are commonly used in practice despite composition allowing physical separation of features and, thus, improving traceability and maintenance. A main hindrance to migrate annotated systems toward a composition‐based product line is the challenging and time‐consuming transformation task. For a company, it is difficult to predict the corresponding costs, and a successful outcome is uncertain. To overcome such problems, a solution proposed by the previous work is to use a hybrid approach, utilizing composition and annotation simultaneously. Based on this idea, we introduce a stepwise migration process from annotation‐based toward composition‐based approaches to lower the adoption barrier of composition. This process itself is independent of used implementation techniques and enables developers to incrementally migrate toward composition. We support our approach with detailed examples by partially migrating a real‐world system. In detail, we describe the following: (1) our migration process, (2) its application on a real‐world system, and (3) discuss practical challenges we face. We implemented the proposed approach and show that appropriate tool support helps to migrate toward composition‐based product lines. Based on the case study, we show that the hybrid product lines work correctly and can compete with the performance of the original annotated system. However, the results also illustrate open issues that have to be solved to apply such migrations in practice.

Follow-the-sun is an approach to develop software by handing off the progress to different time zones as the day passes. Hence, this approach allows companies to work on a project 24 hours a day, potentially reducing its time-to-market. However, several challenges, such as time zone differences or handing off work, are often reported. In this paper, we describe a case study on a follow-the-sun approach that was applied in a German company. During the approach, we did rarely face the aforementioned challenges but experienced different ones. For this reason, the company put its approach on hold but benefited from the learned lessons. Overall, we report on a partly successful follow-the-sun approach and identify five important practices.

Program comprehension is an important aspect of developing and maintaining software, as programmers spend most of their time comprehending source code. Thus, it is the focus of many studies and experiments to evaluate approaches and techniques that aim to improve program comprehension. As the amount of corresponding work increases, the question arises how researchers address program comprehension. To answer this question, we conducted a literature review of papers published at the International Conference on Program Comprehension, the major venue for research on program comprehension. In this article, we i) present preliminary results of the literature review and ii) derive further research directions. The results indicate the necessity for a more detailed analysis of program comprehension and empirical research.

Most software systems are designed to provide custom functionality using configuration options. Testing such systems is challenging as running tests of a single configuration is often not sufficient, because defects may appear in other configurations. Ideally, all configurations of a software system should be tested, which is usually not applicable in practice due to the combinatorial explosion with respect to the configuration options. Multiple sampling strategies aim to reduce the set of tested configurations to a feasible amount, such as T-wise sampling, random configurations, and user-defined configurations. However, these strategies are often not applied in practice as they require manual effort or a specialized testing framework. Within our tool FeatureIDE, we integrate all aforementioned strategies and reduce the manual effort by automating the process of generating and testing configurations. Furthermore, we provide support for unit testing to avoid redundant test executions and for variability-aware testing. With this extension of FeatureIDE, we aim to make recent testing techniques for configurable systems applicable in practice.

Companies are often forced to customize their software products. Thus, a common practice is to clone and adapt existing systems to new customer requirements. With the extractive approach, those derived variants can be migrated into a software product line. However, changing to a new development process is risky and may result in unnecessary costs. Therefore, companies apply cost estimations to predict whether another development approach is beneficial. Existing cost models for software-product-line engineering focus on development from scratch. Contrarily, the extractive approach is more common in practice but specialized models are missing. Thus, in this work we focus on product-line extraction from a set of legacy systems. We i) describe according cost factors, ii) put them in context with the development process and cost curves, and iii) identify open challenges in product-line economics. This way, our work supports cost estimations for the extractive approach and provides a basis for further research.

FeatureIDE is an open-source framework to model, develop, and analyze feature-oriented software product lines. It is mainly developed in a cooperation between University of Magdeburg and Metop GmbH. Nevertheless, many other institutions contributed to it in the past decade. Goal of this tutorial is to illustrate how FeatureIDE can be used to clean variable code, whereas we will focus on dependencies in feature models and on variability implemented with preprocessors. The hands-on tutorial will be highly interactive and is devoted to practitioners facing problems with variability, lecturers teaching product lines, and researchers who want to safe resources in building product line tools.

Program comprehension is an important cognitive process that inherently eludes direct measurement. Thus, researchers are struggling with providing suitable programming languages, tools, or coding conventions to support developers in their everyday work. In this paper, we explore whether functional magnetic resonance imaging (fMRI), which is well established in cognitive neuroscience, is feasible to soundly measure program comprehension. In a controlled experiment, we observed 17 participants inside an fMRI scanner while they were comprehending short source-code snippets, which we contrasted with locating syntax errors. We found a clear, distinct activation pattern of five brain regions, which are related to working memory, attention, and language processing---all processes that fit well to our understanding of program comprehension. Our results encourage us and, hopefully, other researchers to use fMRI in future studies to measure program comprehension and, in the long run, answer questions, such as: Can we predict whether someone will be an excellent programmer? How effective are new languages and tools for program understanding? How should we train programmers?

Program comprehension is an often evaluated, internal cognitive process. In neuroscience, functional magnetic resonance imaging (fMRI) is used to visualize such internal cognitive processes. We propose an experimental design to measure program comprehension based on fMRI. In the long run, we hope to answer questions like What distinguishes good programmers from bad programmers? or What makes a good programmer?

Tools support is crucial for the acceptance of a new programming language. However, providing such tool support is a huge investment that can usually not be provided for a research language. With FeatureIDE, we have built an IDE for AHEAD that integrates all phases of feature-oriented software development. To reuse this investment for other tools and languages, we refactored FeatureIDE into an open source framework that encapsulates the common ideas of feature-oriented software development and that can be reused and extended beyond AHEAD. Among others, we implemented extensions for FeatureC++ and FeatureHouse, but in general, FeatureIDE is open for everybody to showcase new research results and make them usable to a wide audience of students, researchers, and practitioners.

Two programming paradigms are gaining attention in the overlapping fields of software product lines (SPLs) and incremental software development (ISD). Feature-oriented programming (FOP) aims at large-scale compositional programming and feature modularity in SPLs using ISD. Aspect-oriented programming (AOP) focuses on the modularization of crosscutting concerns in complex software. Although feature modules, the main abstraction mechanisms of FOP, perform well in implementing large-scale software building blocks, they are incapable of modularizing certain kinds of crosscutting concerns. This weakness is exactly the strength of aspects, the main abstraction mechanisms of AOP. We contribute a systematic evaluation and comparison of FOP and AOP. It reveals that aspects and feature modules are complementary techniques. Consequently, we propose the symbiosis of FOP and AOP and aspectual feature modules (AFMs), a programming technique that integrates feature modules and aspects. We provide a set of tools that support implementing AFMs on top of Java and C++. We apply AFMs to a nontrivial case study demonstrating their practical applicability and to justify our design choices.

Feature-Oriented Programming (FOP) decomposes complex software into features. Features are main abstractions in design and implementation. They reflect user requirements and incrementally refine one another. Although, features crosscut object-oriented architectures they fail to express all kinds of crosscutting concerns. This weakness is exactly the strength of aspects, the main abstraction mechanism of Aspect-Oriented Programming (AOP). In this article we contribute a systematic evaluation and comparison of both paradigms, AOP and FOP, with focus on incremental software development. It reveals that aspects and features are not competing concepts. In fact AOP has several strengths to improve FOP in order to implement crosscutting featuresSymmetrically, the development model of FOP can aid AOP in implementing incremental designs. Consequently, we propose the architectural integration of aspects and features in order to profit from both paradigms. We introduce aspectual mixin layers (AMLs), an implementation approach that realizes this symbiosis. A subsequent evaluation and a case study reveal that AMLs improve the crosscutting modularity of features as well as aspects become well integrated into incremental development style.

This article investigates aspects in the context of the incremental software development, i.e. software product lines. Specifically, we propose the integration of aspects into AHEAD, an architectural model for feature-based product line development. We introduce the notion of aspect refinement based on aspectual mixin layers, a novel technique for implementing features. Aspect refinement enables a programmer to evolve aspects over several product line development stages. This is novel since common AOP approaches do not have such an architectural model. We realize the idea of aspect refinement by introducing mixin-based inheritance to aspects. Furthermore, we propose bounding quantification that reduces the complexity and unpredictability of aspects in incremental software development. Our novel bounding mechanism exploits the natural order of the layered architecture introduced by the concept of aspect refinement. Aspect refinement and bounding quantification improve the incremental development of product lines using AOP techniques.