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

ZusammenfassungSystematic 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZusammenfassungLately, 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.

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

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

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

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

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

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

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

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

Zusammenfassung[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.

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

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

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

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

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

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

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

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

ZusammenfassungThe 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZusammenfassungCurrently, 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.

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

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

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

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

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

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

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

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

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

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

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

ZusammenfassungIn 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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