Dirk Muthig

PuLSE: a methodology to develop software product lines

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

Component-based product line development: the KobrA approach

The product line and component-based approaches to software engineering both hold the potential to significantly increase the level of reuse in industrial software development and maintenance. They also have complementary strengths, since they address the problem of reuse at opposite ends of the granularity spectrum; product line development essentially supports “reuse in the large” while component based development supports “reuse in the small.” This paper describes a method, Kobr A, that cleanly integrates the two paradigms into a systematic, unified approach to software development and maintenance. Key synergies resulting from this integration include support for the rapid and flexible instantiation of system variants, and the provision of methodological support for component-based framework development.

Static evaluation of software architectures

The software architecture is one of the most crucial artifacts within the lifecycle of a software system. Decisions made at the architectural level directly enable, facilitate, hamper, or interfere with the achievement of business goals, functional and quality requirements. Architecture evaluations play an important role in the development and evolution of software systems since they determine how adequate the architecture is for its intended usage. This paper summarizes our practical experience with using architecture evaluations and gives an overview on when and how static architecture evaluations contribute to architecture development. We identify ten distinct purposes and needs for static architecture evaluations and illustrate them using a set of industrial and academic case studies. In particular, we show how subsequent steps in architecture development are influenced by the results from architecture evaluations

Applying Product Line Concepts in Small and Medium-Sized Companies

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

A case study in refactoring a legacy component for reuse in a product line

This paper describes activities performed to systematically improve the design and implementation of an existing software component in order to reuse it in a software product line. The activities are embedded in the application of Fraunhofers PuLSE/spl trade/-DSSA approach for defining the architecture of a new product line. The component under investigation is the so called image memory handler (IMH) which is used in Ricohs current products of office appliances such as copier machines, printers, and multi-functional peripherals. It is responsible for controlling memory usage and compressing and decompressing image data. Both the improvement of the components design and implementation are based on a systematic analysis and focused on increasing maintainability and reusability and hence suitability for use in a product line.

A practical guide to product line scoping

Over the last years scoping has been established as the initial activity for starting product line engineering. To be successful in defining the right scope for more than 5 years in industrial projects, we always had to customize our generic scoping process to the organizational context, projects constraints, available artifacts, and resources. In this paper, we present an update of the scoping process that explicitly integrates 21 customization factors. In our experience customization of scoping is crucial to the overall product line success, since the scope is the basis for all further product line activities.

Feature-oriented variability management in product line engineering

Implementing feature-oriented variability modeling throughout the life cycle.

An Evaluation of Aspect-Oriented Programming as a Product Line Implementation Technology

A systematic approach for implementing software product lines is more than just a selection of techniques. Its selection should be based on a systematic analysis of technical requirements and constraints, as well as of the types of variabilities, which occur in a particular application domain and are relevant for the planned product line (PL). In addition, each technique should provide a set of guidelines and criteria that support developers in applying the techniques in a systematic and unified way. This paper presents a case study that was performed to evaluate aspect-oriented programming (AOP) as a PL implementation technology. The systematical evaluation is organized along a general evaluation schema for PL implementation technologies.

Guest Editors' Introduction: Successful Software Product Line Practices

A software product line is 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 in place. Organizations adopting product development strategies that include a software product line have achieved impressive results, reducing product cycle time and increasing productivity by an order of magnitude. The software product line strategy is a blend of business and technical actions that lets an organization satisfy a wide range of customers, gain leverage with suppliers, meet the threats of substitute products, and deter other companies seeking to enter the market. The strategy is robust over a wide range of technologies, domains, and organizations of different structures, cultures, and goals. Service-oriented architectures, agile development methods, and open source business models have all played roles in successful product line organizations.

Refactoring a legacy component for reuse in a software product line: a case study

Product lines are a promising approach to improve conceptually the productivity of the software development process and thus to reduce both the cost and time of developing and maintaining increasingly complex systems. An important issue in the adoption of the product-line approach is the migration of legacy software components, which have not been designed for reuse, systematically into reusable product-line components. This article describes activities performed to improve systematically the design and implementation of an existing software component in order to reuse it in a software product line. The activities are embedded in the application of Fraunhofer PuLSE™-DSSA—an approach for defining domain-specific software architectures (DSSA) and product-line architectures. The component under investigation is the so-called Image Memory Handler (IMH), which is used in Ricohs current products of office appliances such as copier machines, printers, and multi-functional peripherals. It is responsible for controlling memory usage and compressing and decompressing image data. Improvement of both the components design and implementation are based on a systematic analysis and focused on increasing maintainability and reusability and hence suitability for use in a product line. As a result of the analysis and refactoring activities, the documentation and implementation of the component has been considerably improved as shown by quantitative data collected at the end of the activities. Despite a number of changes to the code, the external behavior of the component has been preserved without significantly affecting the performance. Copyright