See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/249665342

Product Line Management In Practice

Article · January 2005

CITATIONS READS

0 4,554

3 authors, including:

Dirk Muthig
Lufthansa Systems, Budapest, Hungary
109 PUBLICATIONS   3,456 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Refinement and Variability Techniques in Model Transformation of Software Requirements View project

All content following this page was uploaded by Dirk Muthig on 04 August 2014.

The user has requested enhancement of the downloaded file.

 PESOA
Process Family Engineering in Service-Oriented Applications

BMBF-Project

Product Line Management

In Practice

Authors:
Joachim Bayer
Theresa Lehner
Dirk Muthig

PESOA-Report No. 19/2005

June 30, 2005
PESOA is a cooperative project supported by
the federal ministry of education and research
(BMBF). Its aim is the design and prototypical
implementation of a process family engineer-
ing platform and its application in the areas of
e-business and telematics.
The project partners are:

· DaimlerChrysler Inc.
· Delta Software Technology GmbH
· eHotel AG
· Fraunhofer IESE
· Hasso-Plattner-Institute
· University of Leipzig

PESOA is coordinated by
Prof. Dr. Mathias Weske
Prof.-Dr.-Helmert-Str. 2-3
D-14482 Potsdam

www.pesoa.org
Abstract

Software systems provide to their users a number of accessible services.

For service-oriented applications the services an application provides to its
users are the major driver for understanding the requirements on the appli-
cation and also for developing it. A service-oriented application can then be
specified by selecting required services. The application is realized by com-
bining all required services using a service-oriented architecture that maps
services to software components.

The goal of the PESOA project is to design and implement a platform for
families of related service-oriented applications. The envisioned platform is
used to manage process variants for families of service-oriented applications
and to enable the process-based instantiation of such service-oriented appli-
cation families.

Product Line Management is used to manage, plan and control the life cycle
of the product line and its members. This report outlines the product line
management, especially the management of product line maintenance and
evolution.

Keywords: PESOA, Product Line Management, Product Management, Maintenance

and Evolution

v
Table of Contents

1 Introduction 1
1.1 Project Context 1
1.1.1 Goal 1
1.2 Outline 1

2 Product Line Management in Practice 3

2.1 Product Management 4
2.2 Product Line Management 5

3 Product Line Maintenance and Evolution 6

3.1 Servicing 6
3.2 Extension 7
3.3 Reengineering 9
3.4 Integration 10
3.5 Migration 11
3.6 Management Approach 13

4 Conclusion 15

5 References 16

vii
1 Introduction

1.1 Project Context

PESOA is a cooperative project financed by the German federal ministry of

education and research (BMBF). The goal of the PESOA project is to design
and implement a platform for families of related service-oriented applica-
tions. The envisioned platform is used to manage process variants for fami-
lies of service-oriented applications and to enable the process-based instan-
tiation of such service-oriented application families. This goal is addressed
by enhancing the approved technologies from the area of domain engineer-
ing, product line engineering, and software generation with new methods
from the area of workflow management.

1.1.1 Goal

The management of a product line is subdivided into product management

and product line management. Both have the challenge to manage, control
and plan the corresponding life cycle. Maintenance and evolution is an im-
portant phase in the product as well as in the product line life cycle.

The report presents the management of the product line, especially the
management of the product line maintenance and evolution phase. The re-
sult is one possible realization for the technical component “management
and evolution” in PuLSE (see Figure 1). The technical component is sup-
posed to manage product line development and evolution, thus the complete
product line life cycle. For more detail see [BFK99].

1.2 Outline

Chapter 2 outlines the management of product lines. The management of

the maintenance and evolution phase, including the projects being per-
formed is explained in chapter 3. One possibility of managing is also out-
lined.

1
 Deployment Phases Technical Components

Customizing
PuLSE Initialization

Product Line Infrastructure Evolution

Scoping

Modeling
Product Line
Infrastructure Architecting
Construction
Designing

Coding

Testing and Inspection

Product Line
Evolving and Managing
Infrastructure Usage
Instantiating

Project Entry Points Organizational Issues Maturity Scale

Support Components

Figure 1 PuLSE Overview

2
2 Product Line Management in Practice

Investigations show that product line engineering is not profitable until more
than three products are instantiated from the product line infrastructure as
outlined in Figure 2 [WCT99]. Thus, a long life cycle of the product line is
crucial. The product line life cycle ends with the last concrete product devel-
opment that instantiates the product line infrastructure. The infrastructure is
instantiated as long as it provides the required functionality and quality.

Effort
Single System
Development

gs
in
PL Instance S av

Investment Product Line

Approach
Rule of thumb:
Savings begin
between 2nd and 3rd
product.
Single Rule of thumb:
System Investment ranges
between
development efforts
for 1 and 2 systems.

1 2 3 4 5 6
# Delivered System
Figure 2 Product Line Effort

The main management challenge is to provide always a product line infra-

structure with the required functionality and quality. To this end, the man-
agement is subdivided into product line management and product manage-
ment as presented in Figure 3. The product management is responsible for a
concrete product, thus it can provide direct feedback to the product line
management to maintain and evolve the required functionality and quality of
the product line infrastructure.

3
 Product Line Management

Feedback

Product Management

Figure 3 Product Line Management

This chapter gives an overview on the product management and product line
management, and their life cycle. The life cycle comprises small subprojects
that all have to be managed.

2.1 Product Management

Product Management

Application Maintenance &

Engineering Evolution

Figure 4 Product Life Cycle

The challenge of product management is to manage, control and plan the

product life cycle. The first phase in the life cycle as presented in Figure 4 is
application engineering which realizes the development of the concrete
product that reuses parts of the product line infrastructure. With the delivery
of the product the maintenance and evolution phase is initiated. There, dif-
ferent kinds of maintenance and evolution projects like reengineering, servic-
ing, and migration are performed as needed.

The management activities for application engineering are specified in more

detail in [BPM04]. The maintenance and evolution projects as well as their
management are described in [SGT05].

4
 As presented in Figure 3, the product management gives feedback to the
product line management. In application engineering as well as in the evolu-
tion and maintenance phase requests to maintain or evolve the product line
infrastructure can be identified. The processing of the request is explained in
section 2.2 and in more detail in chapter 3.

2.2 Product Line Management

The challenge of product line management is to manage, plan and control

the life cycle of the product line infrastructure. The first phase of the product
line life cycle is the introduction of knowledge on product line engineering in
the organization since nowadays software product lines are still not common
practice. The introduction is usually supported by pilot projects (see Figure
5). One pilot project could be for example the scoping for the planned prod-
uct line or the design of a generic component, both guided by (external)
product line experts.

Product Line Management

Pilot Domain Maintenance

Projects Engineering & Evolution

Figure 5 Product Line Life Cycle

If the organization has decided on product lines, the product line infrastruc-
ture is developed during domain engineering. With the delivery of the infra-
structure the maintenance and evolution phase is initiated. During this phase
different maintenance and evolution projects like servicing, reengineering,
extension, integration, and migration are performed.

The product line manager responsible for managing the life cycle has to plan
the pilot projects, the domain engineering project, as well as the mainte-
nance and evolution projects. For the pilot project the manager has to organ-
ize the contact to the experts and has to schedule the pilot project activities.
For the content and performance of the projects the experts are responsible.
The management of the second phase, the domain engineering project is
described in [BLM04]. The management of the maintenance and evolution
phase is presented in more detail in chapter 3.

5
3 Product Line Maintenance and Evolution

With the delivery of the product line infrastructure the maintenance and evo-
lution phase for the infrastructure is started. The delivered infrastructure has
certain aspects: functionality and quality, especially genericity. Functionality
covers the features realized in the infrastructure. The quality aspects con-
siders here characteristics like reliability, usability, efficiency, maintainability,
and portability, see [ISO01]. Genericity is a product line-specific quality
characteristic. It states the relation between common and variable features
(commonalities and variabilities) in the infrastructure.

The challenge for the product line maintenance and evolution is to correct
and improve the above mentioned aspects of the infrastructure as required
and aimed at. The requests on maintenance or evolution arise on the one
hand during the product life cycle, as mentioned in section 4; on the other
hand in product line management itself for economic reasons or regarding
defined business goals. According to a request a maintenance and evolution
project is selected.

The possible maintenance and evolution projects are presented in this chap-
ter in more detail. The description comprises the requests driving the project,
the project process and the influence on the infrastructure. In section 3.6 the
management strategy for the maintenance and evolution phase is outlined.

3.1 Servicing

A product line infrastructure is the basis for the different products that are
shipped and put in production. For a product at the customers’ sites, a re-
quest to correct defects could arise. Servicing handles the request for the
product line infrastructure.

A servicing project has the purpose to correct the product line infrastructure
in case of defects detected in a derived product. In [SGT05] defects have
been defined as product anomalies not defined in the product requirements.
The input for a servicing project is a description of the defect. The output of
such a project is a product line infrastructure with higher quality.

Figure 6 outlines the different activities that are performed in a servicing pro-
ject. The input for the servicing project is a detailed description of the de-
fects. The description should contain at least the actual and the expected
behavior. Based on the description the defect is classified in the first step.

6
 Classified
Defect Change Change
Description Requests Requests

Quality

Classification Cause Location Defect Correction Product Line

Infrastructure

Product Line
Infrastructure

Figure 6 Servicing Process

A detected defect could be for example a non defined product requirement.

In such a case rather an extension project (see section 3.2) should be
planned.

If the defect is classified as a defect needed to be corrected, the cause of

the defect is located in the next step. This requires a lot of experience and
knowledge on the product line infrastructure. Furthermore available and suf-
ficient documentation of each product line artifact, especially code documen-
tation is needed. The activity starts with a program comprehension using dif-
ferent tools and a mixture of strategies. Cause of defects could be program-
ming defects, interface defects, design inconsistency, design defects, or
documentation defects. Thus, the program comprehension is extended to
the other artifacts if needed. The result of the location activity is a list of
change requests describing the task to eliminate the defect.

The last step, defect correction performs first the elimination, and subse-
quently tests all changed artifacts.

3.2 Extension

A product line infrastructure contains generic artifacts reusable for each

product line member development. Different reasons for the extension of the
product line infrastructure exist:

1. During application engineering, the development of a concrete product

line member, new common features are identified that have to be in-
cluded in the generic infrastructure.

2. In the roadmap of the organization new product line members and re-
lated new common and variable features are identified and planned.

7
 In the first situation the input for an extension project is the list of new prod-
uct features, in the second situation a product description for the new mem-
ber is required. The result of an extension project is a product line infrastruc-
ture with more functionality.

Figure 7 presents the different activities performed in the project and the in-
put/output artifacts. The process corresponds to domain engineering with the
difference that it is uses artifacts already existing in the infrastructure.

Scoping uses the product map already defined in the product line infrastruc-
ture as input. It contains all already identified product line members and their
related features. Introducing new identified features as described in the first

Product Feature
Description List

Extended Extended Extended Extended

Product Domain Domain Domain
Map Analysis Design Implementation

Functionality

Product Line
Scoping Domain Analysis Domain Design Domain Impl.
Infrastructure

Product Line
Infrastructure

Figure 7 Extension Process

situation, the product map is extended to embrace the new features. To ex-
tend the product line for a new product line member the general scoping is
performed as described in [BFL05].

Based on the extended product map the return of investment (ROI) of the
project can be evaluated. In the first situation the expected reusability of the
new feature is decisive, and in the second the benefit for the product reusing
the product line infrastructure. With the ROI analysis the product line man-
ager can decide on the realization of an extension project.

If the decision for an extension project is made, the project starts with the
domain analysis where the new identified features and their functionality are

8
 analyzed, for example using use cases. After the analysis the plan for the
extension project can be defined, the needed extension tasks and their re-
lated effort estimated. The next step in the project is to include the new fea-
tures/functionalities in the domain design [KG04]. Then the new features are
implemented and included in the existing domain implementation.

3.3 Reengineering

Besides functionality the product line infrastructure offers the aspects quality
and genericity, as mentioned above. The challenge of the product line man-
agement is to maintain and to improve the quality during the complete prod-
uct line life cycle. After some performed maintenance or evolution projects
improvement is getting more difficult. In this situation reengineering is a

Expert
Knowledge Current State Target State

Genericity
Quality
Reverse Domain Product Line
Goal Definition
Engineering Engineering Infrastructure

Product Line
Infrastructure

Figure 8 Reengineering Process

costly, but efficient technique.

The input for a reengineering project is the expert knowledge as presented

in Figure 8; unfortunately it is not always given in practice. The output of a
reengineering project is a product line infrastructure with more quality re-
garding a specific characteristic like reliability, usability, and efficiency.

The first step in a reengineering project is to identify the current state of the
quality of the product line infrastructure. For that reverse engineering is used
which measures the quality using for example GQM [Bas92]. The reverse
engineering performs domain engineering reverse and analyzes each arti-
fact. Thus, it starts with the domain implementation and ends up in the do-
main analysis if necessary.

9
 Based on the quality analysis, in the process step goal definition the target
quality is specified, and then the needed quality improvement tasks are iden-
tified, estimated and planned.

The last step is the performance of the quality improvement tasks. During
domain engineering each artifact is improved regarding the defined tasks
and quality target.

3.4 Integration

Product line usually forms hierarchies. In practice, product line organizations

often integrate other component or different product lines into a new product
line hierarchy for economic reasons or regarding defined goals. Component
integration takes place if the product line wants to offer for example a new
feature provided by an external supplier. One example of integration of pro-
duct lines could be that the reusability of each product line alone is not
longer sufficient. The integration of product lines is also defined as product
line population. In [BMM03] different situations for product line populations
are described.

For the component integration the specification and the implementation of

the new component are needed as input. The integration of different product
lines is based on the existing product line infrastructures of each product
line. The output of each kind of integration is a product line infrastructure
with a higher quality, functionality and genericity.

To integrate a new (generic) component its specification as well as the im-

plementation has to be included in the product line infrastructure.

In case of integrating different product lines into a new more efficient product
line the process is more complex. Figure 9 presents the process explained in
the following in more detail for integrating/merging two product lines.

The first step, scoping, is the integration of the product line members and
their features of both product lines (A and B) in one common product map.
The resulting product map reflects the relation between the product lines; for
example, product line A is more mature than B, or both are equal. Based on

Product Line Product Line Product Map

Infrastructure Infrastructure
Genericity
Quality Functionality
Project Product Line
Scoping Project Selection
Execution Infrastructure

Figure 9 Integration Process

10
 New Technology
Documentation Experiences

Domain Domain Domain

Scoping
Analysis Design Impl.
Functionality
Quality
Product Line
Infrastructure

Product Line
Infrastructure

Figure 10 Migration Process

the product line relation two different projects can be selected and executed:

• The infrastructure of product line A is extended for the features and

product line members of product line B. Thus, the extension project (see
section 3.2) is selected and performed. In addition, the product line A
could be reverse engineered to assure a certain quality before extending
it.

• The second integration strategy is to develop from scratch a new product

line C containing features and products from product lines A and B, and
new C product line members. The integration project performs so the
common domain engineering.

3.5 Migration

The product line infrastructure is developed according to a specific technol-

ogy. For some reasons a transformation of the product line infrastructure us-
ing a new technology can be necessary. A migration project supports such a
transformation.

The input of the project could be a documentation of the new technology or

some experience gathered in prototypical implementations. The output is a
product line infrastructure with more quality or functionality implied by the
new technology.

The influence of the new technology on the product line infrastructure sets
the activities performed in the migration project. A technology transformation

11
 from Java to C++ needs for example only a new implementation. In contrast,
new hardware, e.g. a processor allowing more complex algorithms, forces a
new domain design as well as implementation, and perhaps even a new
domain analysis. Furthermore, the new technology implies new feature
which are realizable with the new technology. Thus, the migration project
could underlay following process as described in Figure 10.

12
3.6 Management Approach

The drivers for maintenance or evolution projects are the requests from the
product management as well as the internal strategy of the product line
management as already mentioned. The responsibility of the product line
manager is to manage, control and plan all different maintenance and evolu-
tion projects. In this section a way to support this management is outlined.

The basic concept therefore is the state of the product line infrastructure
which is defined by its aspects – functionality, quality and genericity. Influ-
ence on the management has now the actual state, the state after perform-
ing a specific maintenance and evolution project, and the state aimed by the
internal product line management strategy.

Functionality

Quality

Genericity

Actual state State achieved Target state

performing the specific
„maintenance and
evolution“ project

Figure 11 Management Support

With the information on the different states as presented in

13
 Figure 11 and the changes of states achieved by the projects as outlined in

Table 1 the product line manager can manage, plan and control the
maintenance and evolution phase. While planning and managing the man-
ager has to consider the higher prioritization of the product management re-
quests compared to the internal product line management strategy.

Project Functionality Quality Genericity

Servicing X
Reengineering X X
Extension X
Integration X X X
Migration X X

Table 1 Projects and their influence on the infrastructure aspects

14
4 Conclusion

In this report, management for product lines in practice is presented. In prac-

tice, a long life cycle is decisive for a profitable product line, as outlined in
chapter 2. A product line is profitable as long as it is efficient for the concrete
product development to reuse the product line artifacts. The assurance of
that is the challenge for the management.

To this end, management considers the complete life cycle of a product line.
Product management is responsible for the product life cycle that is for ap-
plication and for maintenance and evolution. Product line management is re-
sponsible for the product line life cycle. Thus, mainly the development and
the maintenance and evolution of the product line infrastructure is managed,
planned and controlled.

The management of the maintenance and evolution phase in the product

line life cycle is explained in chapter 3. The phase has different drivers, one
is the feedback of the product management and the another one is the inter-
nal strategy regarding the product line infrastructure. These different drivers
yearn all for a specific maintenance and evolution project. Thus, the chal-
lenge for the product line manager is to manage the different requests on
maintenance and evolution projects. One way of managing that is also de-
scribed in this chapter.

15
 5 References

[BMM03] Böckle, Günter; Clements, Paul; McGregor, John D.; Muthig, Dirk;
Schmid, Klaus: “A Cost Model for Software Product Lines”, in Pro-
ceedings of the Fifth International Workshop on Product Family
Engineering. Siena, 2003.
[SGT05] Sneed, Harry M.; Hasitschka, Martin; Teichmann, Maria-Therese:
“Software-Produktmanagement : Wartung und Weiterentwicklung
bestehender Anwendungssysteme“, Heidelberg : dpunkt.Verlag,
2005.
[KG04] Knodel, Jens; Girard, Jean-Francois: “Request-driven Reverse
Engineering for Product Lines”. In proceedings of Workshop
Reengineering Prozesse (RePro 2004). Fallstudien, Methoden,
Vorgehen, Werkzeuge, 2004.
[RB00] Rajlich, V; Bennett, K.: „A Staged Model fort he Software Life Cy-
cle“, IEEE Computer, July 2000.
[BLM04] J. Bayer, T. Lehner, and D. Muthig. Product Line Engineering and
Project Management – Base Practices; PESOA-Report No.
11/2004, October 30, 2004.
[BFK99] J. Bayer, O.Flege, P.Knauber, R.Laqua, D. Muthig, K. Schmid, T.
Widen: „PuLSE – Product Line Software Engineering“, IESE-
Report No.020.99/E, July 13, 1999.
[Bas92] Basili, Victor R.; University of Maryland - Dept. of Computer Sci-
ence: Software Modeling and Measurement. The
Goal/Question/Metric Paradigm, 1992.
[BFL05] J.Bayer, T. Forster, T. Lehner, A. Ocampo, J. Weiland, E. Richter,
S. Kiebusch: „Merkmalsmodellierung und Entscheidungsmodelle,
PESOA-Report No xx/2005 July 2005.
[ISO01] International Organization For Standardization/International Elec-
trotechnical Commission (Ed.) Software engineering – Product
Quality – Part 1: Quality Model“, ISO/IEC 9126:2001, Geneva
2001.
[WCT99] Weiss, David M.; Lai, Chi Tau Robert, “Software Product-Line En-
gineering. A Family-Based Software Development Process”, Addi-
son-Wesley, 1999.

16

View publication stats