No abstract

Abstract. In product line engineering various stakeholders like sales and marketing people, product managers, and technical writers are involved in creating and adapting documents such as offers, contracts, commercial conditions, technical documents, or user manuals. In practice stakeholders often need to adapt these documents manually during product derivation. This adaptation is, however, tedious and error-prone and can easily lead to inconsistencies. Despite some automation there is usually a lack of general concepts and there are "islands of automation" that are hardly integrated. Also, research on product lines has so far often neglected the handling of documents. To address these issues, we developed a flexible approach for automatically generating product-specific documents based on variability models. We applied the approach to two industrial product lines of different maturity using the decision-oriented product line engineering tool suite DOPLER.

This paper explains the challenges we experienced when introducing a software product family approach in Siemens business groups. Our vision is a complete and easily accessible cookbook with advice on how to start such an approach. In a first attempt, we identified a collection of more or less successful best practices. On the suggestions and the open questions we are going to present in this paper, we search validation by practitioners in the field.

Abstract. This paper summarizes our experience with introducing feature modelling into several product lines within Siemens. Feature models are used for solving various tasks in the product line lifecycle, starting with scoping the reusable asset base up to support for actual product configuration. Using feature models as primary artefacts for managing variability early in the lifecycle, we could improve the efficiency and transparency of scoping activities considerably and made the development efforts way easier to schedule. On the other end of the lifecycle, feature models lowered the engineering efforts in solution business in supporting product configuration and instantiation.

Code is modularized, for many reasons, including making it easier to understand, change, and verify. Aspect-oriented programming approaches extend the kind of code that can be modularized, enabling the modularization of crosscutting code. We conducted an inquisitive study to better understand the kinds of crosscutting code that soRware developers encounter and to better understand how the developers manage this code. We tracked eight participants: four from industry and four flora academia. Each participant was CmTently evolving a non-trivial soft, rare system. We interviewed these participants three times about crosscutting concerns ~cy had encountered and the strategies they used to deal with the concerns. We found that crosscutting concerns tended to emerge as obstacles that the developer had to consider to make the desired change. The strategy used by the developer to manage the concern depended on the form of the obstacle code. The results of this study provide empirical evidence to support the problems identified by the aspect-oriented programming community, and provide a basis on which to further assess aspect-oriented programming.