Keywords: Product Line Engineering, Technology Transfer,
Variability Modeling
Classification: 3-4 year´s work (PhD complete in Summer/Fall
2001)
1 Introduction
Reuse is seen as a solution for many problems that software development
organizations have. Unfortunately, it is hard to achieve in practice. The
reason is that there is no general solution that has been proven to work
in many different environments. Product line engineering is a solution
that works in environments that develop multiple systems in the same application
area. Its key idea is to define and build a product line infrastructure,
which is generic and thus can be reused across systems in the same application
area.
Unfortunately, existing product line engineering approaches are big
endeavors that require one big and radical shift within an organization:
nearly all processes and products, as well as the structure of the organization
itself, must be adapted with respect to product line development. Such
a shift towards product line engineering embodies huge risks for an organization
that are difficult to control. Consequently, product line engineering is
not an option for many organizations although it promises to tackle and
solve their major problems.
In this thesis, a technique for modeling variabilities and decision
modeling is defined and validated that enables the incremental introduction
of product line engineering into running organizations without high up-front
investments as it is typically required by traditional product line approaches.
The main goal of an incremental introduction is to minimize and control
the risks of introducing product line engineering and, thus, to enable
more organizations to profit from the offered benefits.
2 Problem
The potential market for product line engineering approaches is huge because
most of the environments develop product lines:
They typically develop applications in one application domain (in which
they are experts).
They start with one product and then develop successively other products
(or variants of former products). This is true independent whether the
environment develops individual systems for different customers, one standard
application, which is adapted to diverse contexts, or one professional
application that supports all features in a domain from which variants
with a limited functionality are derived .
Though there is this market for product line engineering approaches, they
are hard to find in practice. The reason is that existing product line
approaches require high and risky up-front investments without providing
sufficient support for managing the related risks. The investments include
adaptions of and changes to nearly all development activities and used
products. Initially, this introduces new problems instead of immediately
tackling and solving the concrete problems existing in an environment.
Additionally, the details are often missing that are esstential in eventually
applying an approach in a project environment. Last but not least, the
existing approaches do not sufficently describe strategies and ways for
introducing the approaches but describe the final (ideal) solutions only.
By focusing on the final solutions, the approaches ignore the fact that
environments cannot stop their current activities and start with something
new. A smooth transition from single system development towards product
line engineering (including the new and different way of thinking in terms
of common and variable things) is crucial for a successful introduction
of product line engineering into an organization.
A way out of the dilemma (i.e., the mismatch between existing product
line approaches and existing organizations) is to integrate the product
line apporach as much as possible with the existing practices, that is,
change existing practices only where necessary and only incrementally.
In the figure, the effort typically required for delivering systems in
a product line is illustrated. Three effort lines for three approaches
are shown. The traditional product line approach needs only a minimal effort
for delivering a particular instance. In comparison with a single system
approach (red line), the up-front investment pays back after a number of
systems has been delivered (rule of thumb: three to four systems). The
incremental approach proposed in this thesis aims at the green line: following
the effort distribution of single system development but at one point in
time benefit from the product line characteristics of the delivered systems.
3 Product Line Infrastructure
A product line approach that aims at minimizing the changes to an organization
must be customizable, especially with respect to the used types of generic
assets. Generic assets are part of the product line infrastructure. They
capture common and variable characteristics of a system family and,
thus, are the assets (re)used and tailored during application engineering.
In this thesis, a technique for modeling variabilities is developed that
modifies the assets already used for modeling single systems in an organization
by extending their meta models. Newly introduced elements (often for each
type of variability, an individual element must be defined) capture points
of variation in an explicitly visible manner and they encapsulate the knowledge
needed to instantiate this point of variation (i.e., how the assets must
be modified to represent each single alternative it provides). An investigation
of the published product line approaches shows that a product line infrastructure
contains, besides generic assets, a decision model that captures the domain
knowledge needed to systematically employ a product line infrastructure.
In this thesis, a technique for modeling decisions is developed that complements
the technique for modeling variability. Due to the limited space, no more
details of the two techniques are presented here (see [1]
and [2] for details)
4 Validation
The techniques for variability and decision modeling are validated within
projects and case studies.The incremental introduction of product line
engineering using these techniques is validated in an experiment in which
two groups of software developers are involved. The first group gets the
specifications of three variants of a component, which are required for
three members of a product line. Then, a generic component covering all
three variants is created and, then, instantiated (traditional product
line approach). The second group gets specification by specification and,
thus, subsequently develops generic components covering variant 1 only,
variant 1 and 2, and finally all three variants. The expected outcome is,
on one hand, that the effort used by the second group does not significantly
differ from the effort of the first group, and, on the other hand, that
the generic components covering all three variants are of similar quality.
Then, it has been shown that without the up-front investment, product line
concepts can be exploited (the investment is distributed (equally) among
the developed variants).
5 Conclusion
In the context of an applied research institute, it is of particular interest
to identify problems of industrial organizations. The interaction with
industry in the context of product line projects (project work and acquistion)
has shown that the necessary up-front investment and the required organizational
changes hinders most organizations to go towards product line engineering.
However, the benefits of product line approaches is exactly what they are
looking for. Hence, the main point of this thesis is to create the basis
for, as well as to validate, an alternative way towards product line engineering
and, thus, to enable also small companies to profit from the underlying
concepts.
References
[1] Atkinson, C., Bayer, J., Muthig, D, Component-Based
Product Line Development: The KobrA Approach, accepted by the First International
Software Product Line Conference, Denver, 2000
[2] Bayer, J., Muthig, D., and Widen, T. Customizable
Domain Analysis In Proceedings of Generative and Component-Based Software
Engineering Conference, September 1999
muthig@iese.fhg.de Last
modified: Sun Feb 27 12:20:03 CET 2000
