A Systematic Approach to Derive the Scope of Software Product Lines

A Systematic Approach to Derive the Scope of Software Product Lines Klaus Schmid Fraunhoftir Institute for Experimental Software Engineering (IESE) Sauerwiesen 6 D-67661 Kaiserslautern, Germany +49 (0) 6301 707 158 [email protected]

Jean-Marc DeBaud’ Lucent Technologies Software Product Line Engineering Laboratories 263 Shuman Boulevard Naperville, IL, 60563, USA +1 (630) :224 0383 [email protected]

A product line (PL) entails the construction of a reusable infrastructure from which family members can be constructed. A domain-specific software architecture usually acts as the main backbone of the PL reuse infrastructure but is often a very complex task to design, transition to an executable state, and evolve. Hence, the initial decision about which particular scope should be covered by the PL is fundamentally important. For the reusable infrastructure to fulfill its expected economic return, its scope should be optimal in the context of the enterprise situation.

ABSTRACT

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

Traditional scoping approaches (from domain engineering) [16, 171 have focused on the notion of application domains. However, domains proved difficult to optimally scope and engineer from an enterprise standpoint because a domain often captures extraneous elements (concepts and relationships) that from an epistemic sense may be part of the domain, but are not and will not be part of any product of the enterprise, whether existing, under development, or anticipated (short or long term). Hence, the domain view provides a flawed economic basis for making a scoping decision. On the other hand, a product centered view provides a sound basis because the products are the precise deliverables contracted for and which an enterprise cares about. The same mode of reasoning applies if one takes the point. of view that a product line spans multiple application domains.

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 definition and concerns achieved through the 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.

Yet, each of the potential products for a candidate PL, and moreover the detailed functionality of each of them, should not automatically be included within the reuse infrastructure. The list of candidate products within the PL, while sharing commonalities, may also share enough or even drastic differences that may make their engineering from a common infrastructure simply not economically feasible. Hence, there is a need to reliably and carefully filter PL candidate products both at the product as well as the inner functionality levels. The technique presented in this paper, PuLSE-Eco, is an attempt to provide such capabilities to PL eqgineers.

Keywords

software product line, product line engineering, reuse economic models

scoping,

domain

1 INTRODUCTION Problem

The basic rationale for constructing a software product line is to acquire an ability to more efficiently build members of the application family represented by the PL than would be the case if they were built one by one in isolation.

Context

1. This work was done while the first author was with the IESE. Permission to make digital or hard copies of all or part of this work fix personal or classroom USC is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies hear this notice and the full citation on the tirst page. TO copy otherwise, IO republish, to post on servers or to redistribute 10 lists. rcquircs prior specific permission andior a fee.

1. F’uLSETM is a registered trademark of the IESE.

ICSE ‘99 Los Angeles CA Copyright

ACM

and Approach

PULSE-Eco is part of PuLSETM (Pi;oduct Line Software Engineering)‘, a larger product line engineering framework currently under development [4]. PULSE-Eco is one of the technology components within PULSE. Its role is to scope the application area of a PL. To provide context, we SUCcinctly describe PULSE below.

1999 l-58113-074-0/99/05...$5.00

34

Architecting: how to develop the reference architecture while maintaining the traceability to the model [8] Instantiating: how to perform the Usage Phase Evolving and managing: how to integrate misfits in the PL, and deal with configuration management issues as products accrue over time The support components are packages of information, or guidelines, which enable a better adaptation, evolution, and deployment of the product line. These components are used by the other elements. They are: l

l l

Project Entry Points: customize PULSE to major project types. For instance, whether there are legacy assets to be reused or whether multiple projects are independently running and need to be integrated after one realized that much was shareable among them [7], [6] Maturity Scale: provide an integration and evolution path for product line adoption to enterprises using PULSE Organizational Issues: provide guidelines to set up and maintain the right organization structure for developing and managing product lines PULSE-Eco provides the scope of the PL that is then used by the CDA component to bound the realm of the PL model. That scope is also made available to the evolution and management functions of PULSE-EM. l

l

l

The PULSE methodology enables the conception and deployment of software PLs within a large variety of enterprise contexts. This is achieved via a strong productcentric focus throughout the phases of PULSE, the customizability of its components, an incremental introduction capability, a maturity scale for structured enterprise evolution, and adaptations to a few main product development situations. Figure 1 presents a decomposition of the PULSE method. PULSE is articulated around three main elements: the deployment phases, the technical components, and the support components. The deployment phases are logical stages a product line goes through during its inception. They describe the activities performed to set up and use the product line. The phases are: Initialization: baseline the enterprise and customize PuLSE as a result Infrastructure Construction: scope, model and architect the product line infrastructure Infrastructure Usage: use the infrastructure to create product line members Evolution and Management: evolve the infrastructure over time and manage it The technical components provide the technical know-how needed to operationalize the product line development. As Figure 1 denotes, they are used throughout the Deployment Phases. A different facet of each is often used in each of the phases - though some components directly correspond to phases. The technical components are: l

l

l

l

l l

l

Customizing: how to perform the Initialization Phase Scoping: how to effectively scope the infrastructure focussing on product definitions Modeling: how to model the product characteristics found within the scope of the product line and explicitly denote the product family members

Our approach was to develop a mechanism to represent product candidates for a PL and detail them to the desired (and manageable) level of granularity. This was achieved via product maps. In parallel, we also needed to adapt the approach so that we could integrate the separation of and achieved through the definition concerns operationalization of strategical business objectives. This enabled diverse types of analyses performed upon product maps allowing scoping decisions based on these objectives. Related Work While so far no directly comparable approaches for scoping software PLs have been defined, PULSE-Eco still draws upon much related work. In the field of software engineering, work on identifying the benefits of reuse is mostly centered around the notion of reuse economic models [9, 11, 14]. However, these mostly aim at determining the economic benefit of a reuse-based approach, but do not answer the question of how to maximize this benefit by choosing the scope for artifact reuse appropriately. Most approaches center around a fixed set of aspects. While this provides some foundation to different analysis types, only few approaches stress the importance of adaptability to the enterprise context [13] as we do via business objectives. On the other hand, work in domain engineering directly addressed the domain scoping issue. Thus, methods such as Synthesis [16] or Organizational Domain Modeling (ODM) [17] introduced scoping approaches. ODM was the most developed, yet could not quantitatively handle the different perspective and goals of stakeholders. Perhaps the most stringent approach for domain scoping is provided by the domain scoping framework [3], but this approach fails to link the derivation of the scope explicitly with the business

objectives. A major difference with our work is also that their work is strongly based on the notion of a domain while ours is based on the notion of pre.cise products. This, we believe, is a major distinction that needs to be made in order to truly address the business objectives as they are usually centered around products. Approaches based on ontological analysis [5] also suffer, in our view, from the same problem as domain focused approaches: an epistemic viewpoint of problem domains.

ments are rather clear, but development has not yet started), and potential products (i.e., products for which no clear requirements exist yet, but these products are seen as relevant, for example, because they address new market segments). Having developed an understanding of the relevant products, the list of characteristics is developed. This list provides a description of the different characteristics and identifies relations among them. At this point it should be noted that characteristics can describe both external and internal aspects of the systems. External characteristics (i.e., externally visible behavior aspects) can in turn be either of functional (features) or non-functional nature (e.g., performance). Internal characteristics that can be relevant to PULSE-Eco are, for example, modules in a system. What characteristics are relevant to a PULSE-Eco application depends both on the business objectives relevant to the evaluation and on the specific context of the project (e.g., “modules” will usually be only relevant in th.e case that systems that shall be part of the PL already exist).

In some sense, the work of Whitey [ 181 served as an initial inspiration to the approach we present here. But, we felt when we tried to use it that we lacked a level of precise guidance. Too many details were left to interpretation and hence were opportunities to loose the right focus. More importantly, this approach is also restricted to the business objective of maximizing the return on investment (ROI). Yet, our definition of product maps has its root in this work though and we felt quite inspired by its general direction. While PLs are a rather recent topic in software engineering, they have existed for quite some time in other engineering disciplines. However, there the concept of PL was often not regarded from the perspective of the reuse it enables, but from the viewpoint of the sales options it provides [lo].

. ““.-”,-

Y’” system -) \ ---“-“J information

Only recently it became an issue to plan a PL and to scope its architecture from an economic perspective [15]. However, while [15] is closest to our work, it still centers around a predefined set of criteria, while our approach is open to a wide range of business objectives.

/-.“takeK--,T-.-.\ \ information / -t-------1

,“.““..”“. .“” “.II .x, ! business x3 iLwe_*ctives : ‘T- ‘-‘__I”-

Work on relating technical characteristics to external requirements is also relevant in this context. Quality Function Deployment (QFD) is probably the most wellknown approach in this area [2]. The notion of a product map as it is developed in this paper also shows some commonalities with QFD as do most tabular based methodologies. More recently, work by Yu et al. [19] also addressed how to derive an architecture based on external requirements. However, again the possibility to introduce further relevant business objectives was missing. This paper is structured as follows: in the following section we present an overview of PULSE-Eco. In Section 3, we detail the technique using a running example. In Section 4 we present an analysis of the technique and of our experience with it. Section 5 concludes. 2 PULSE-Eco

I I I

Overview

In this section, we present a short overview of the PuLSEEco process, which is shown in Figure 2. An illustration of how this process is applied in practice will be given in the following section.

+ to PULSE-CDA ;

As discussed in the previous section, PULSE-Eco aims at identifying the characteristics that shall be directly supported by the reference architecture. The step map out product candidates takes care of this. First, the products that might be supported by the PL are identified. Basically three types of products can be distinguished here: existing products (i.e., products that have been developed prior to the start of the PL project), future products (i.e., products where the require-

1 process 1 _ __ + 1-” Produce/Consume /T”““’ t product ,)

Figure

36

2. PULSE-Eco

+

to PULSE-EM process

product map in the corresponding columns (cf. Table 6).

Identifying the products first serves two purposes: 1) the products can be-used to limit the number of characteristics that are identified as characteristics that are conceptually inside the domain, but are not relevant to any product can be excluded; 2) the products serve as a completeness check as any characteristic which is seen as important for distinguishing between any two products should be included in the list.

The next step, bene$t analysis, is the core step of PuLSEEco. At this point the information gathered is used to derive the scope definition. The first substep is rather straightforward: based on the definition of the benefit functions, values for these functions are determined using the values assigned to the characterization functions. The second substep is much harder: the objectives expressed by the different benefit functions need to be balanced in order to come up with a single scope definition, This is a classical multi-objective decision problem. As a large number of techniques for addressing this type of problem have already been described in the literature [12], PULSE-Eco does not prescribe a certain technique, but is open to the introduction of any existing technique. Applying such a technique results in a raw scope definition. Usually this scope definition needs further refinement as some criteria have not been fully expressed by the operationalization. These refinements are based on human expertise. At this point, additional objectives may become clear which have so far not been expressed by the stakeholders. This may lead to iterations of the complete PULSE-Eco process.

The product and characteristic information is then compiled in the form of a product map (cf. Table 6). Product maps are similar to the matrix diagram used in Quality Function Deployment (QFD) [2], but are more generally defined. In particular they are augmented with additional information, like the characterization functions, which are not present in their QFD-counterpart. The product characteristic information and the scope definition is forwarded to PULSE-CDA. The scope definition defines the realms of domain modeling, while the product characteristic information is used as a starting point for populating the domain model. The core idea of PULSE-Eco is to explicitly base the definition of the PL scope on the business objectives that are identified by the PL stakeholders. However, these objectives are usually identified in too general of a manner for using them directly towards this end. Consequently, our approach includes the concept of successively refining the business objectives towards more operational evaluation criteria, which can be applied on a single product/characteristic-combination. This bears some similarity to the concept of developing metrics from abstract measurement goals as it is used in the Goal-Question-Metric approach (GQM) [ 11. However, there are some substantial differences in purpose as PuLSEEco is not geared towards measurement, but aims at making scoping decisions. Yet, PULSE-Eco is still based on the use of successive refinement which has the advantage that an explicit and traceable relation between the business objectives and the identified scope is established. An example of such a refinement is shown in Table 3. This refinement is done in the step develop evaluation functions which produces benefit and characterization functions. The benefit functions describe the benefit of introducing a certain characteristic into the reuse infrastructure relative to a certain business objective. These functions are in turn defined in terms of the characterization functions. The characterization functions are applied on single product/characteristic-combinations (by the relevant stakeholders) and play a role analogous to metrics in the GQM-approach. It is a difficult task to come up with benefit functions that closely correspond to the business objectives and to define them in terms of characterization functions to which values can be assigned by experts. Consequently, this is a point where iterations often occur.

During PULSE-Eco a large amount of information about the products, their characteristics, and constraints among them are elicited. As PULSE-Eco is well integrated in the overall PULSE methodology, this information is supplied in the form of the product line planning information to the PULSE-EM component, which is responsible for the overall product line evolution and management. This workproduct identifies constraints on a project plan for the product line project leading to the identification of increments for the reuse infrastructure development and describes the relation between these increments and the envisioned products (e.g., some products can be developed with an earlier increment of the reuse infrastructure than others). As this paper concentrates on PULSE-Eco, we will not further discuss this interface to project planning. 3 USING PULSE-EC0 While in the previous section we gave a general overview of the PULSE-Eco process, we illustrate in this section how PULSE-Eco can be used to define a scope using a realistic example drawn from one of our industrial cooperation projects. The analysis presented here does not address the selection of products, but only of the product characteristics, as in this particular example the products were already selected through existing contracts. In order to protect the interests of our customer, we were asked not to name the company nor the projects. The customer specializes in developing merchandising software. The company aims at developing specialized variants of their software, specifically adapted to the requirements of individual sites. One variant (Pl) has already been fielded, a second one (P2) is currently under development. TWO additional variants (P3) and (P4) are in the requirements phase. The possibility of further variants for other customers is clearly perceived at this point. This potential led early on to the conclusion that a product line approach was necessary in order to manage the multitude of variants.

In the next step, characterize products, the characterization functions are applied on the product map. Usually this is done by those stakeholders who provided the different objectives (e.g., the project leader for development will usually supply the effort estimates, while a marketing expert will supply information on what characteristics may be helpful to gain market share), or other qualified personnel as identified earlier on. The information thus elicited is entered in the

37

The example we use here has been restricted to two subdomains from the domain of merchandising systems. These are: order recording and commissioning. (Commissioning is the activity of selecting and assembling goods requested by a specific customer out of the goods that are in stock or that arrive at the goods reception,) Mapping out product candidates As was explained in the previous section, the first step in PULSE-Eco is to identify the various products and their characteristics. The different products could be easily identified. The potential future applications were not included in the analysis, as their requirements were regarded as being too fuzzy at this point. Identifying the most adequate characteristics, however, was much harder as the various characteristics are not independent. This is illustrated in Table 1 for the subdomain of order recording. In this case, the vertical axis gives the different activities in this subdomain, while the horizontal axis provides the different types of orders. The crosses denote where special order types have a considerable impact on the definition of the activity. These intersections actually identify “sub’‘-characteristics. Such a table is termed a characteristic map, as it illustrates the relation among different characteristics (characteristics interaction). While in this case it can be simply displayed as a two-dimensional map, in the general case there can be an arbitrary number of dimensions. The interaction among characteristics can become a problem, as it may lead to an explosion of the number of characteristics (each combination with a cross in the table can be regarded as a new characteristic). In the given example, it was still practical to introduce the special order types as subcharacteristics of automatic ordering and check order data (cf. Table 2). At the same time, the product characteristic information is generated. It contains a description of the characteristics, relations among them (e.g., delivery related and ordering related are mutually exclusive, distance orders, express orders, etc. are independently optional, etc.), and other information about these characteristics that has been elicited during development of the product map. Table 1. Characteristic

Table 2. Product Map (initial) functional area order planning

automatic ordering

characteristic delivery related

Pl

P2

X

ordering related

X

distance orders

X

express orders ... check customer data ..

...

At this point, a first iteration of the product map that shows the interrelation among characteristics and pro’ducts can be developed. This is shown in Table 2. Due to space restrictions we show only a few characteristics. A more detailed example is shown in Table 6 (there this information corresponds to the req-function). Developing Evaluation Functions The second subprocess of PULSE-Eco aims at clarifying and operationalizing the business objectives that are relevant to the PL in the particular enterprise context. The following stakeholders were identified as relevant in general: company management, software development management, and marketing. In this specific case, each role was filled by a single person. By interviewing these persons, the following objectives were elicited: l

l

Map

Company management: a Maximize coverage of the domain (i.e., bring the company into a position where most merchandising system variants can be built readily by reusing existing assets) Software development management: a Reduce effort for developing new systems (i.e., develop those characteristics which may be relevant for various products in a way so that the assets can be readily reused) b Reduce variants of assets to the smallest possible number as managing them is seen as a ma+jorsource of problems in the software development.

l

As described in Section 2, PULSE-Eco uses a step-wise refinement approach in order to develop the evaluation functions. Here, we will use the “reduce effort” objective for illustrating this process. We chose this objective because it is an intuitive objective in the context of product line and because it has some interesting implications in the context of this study as we will see below.

Check customerdata Check order data

x

x

x

x

Marketing: a Optimize the number of characteristics included in each product in order to address as large a range of customers as possible.

x

38

Table 3. Developing Evaluation

Functions

basic characteristics into the generic architecture, as otherwise the introduction of these characteristics for specific products at a later time will lead to a large number of changes to the reference architecture.

Objective (cf. 2a)

inimize theeffortneededfordevelopingmerchandisingsvs~fromtheviewpointofsoftwaredeveloumentmananement the customer

Question!

How is effort defined? (person-months spent in design, coding and testing) What are regarded as influential factors for effort? - Effort needed for developing the characteristic in different systems - Effort for generic version of the characteristics - Encapsulation of characteristic (the more connections this characteristic has with other parts of the system, the more work needs to be done

Benefit functions

Effort saved by integrating characteristics as part of the generic architectureifonly therequiredcharacteristics are implemented El(c) = Credc,

p) .‘eff(c, PI - @.T(c, pRen)

pgc,, denotls the generic implementation of the character-

istic, i.e., an implementation that is compatible with all other potential characteristics Effort saved if products are enriched with potential characteristics J%(C)= C(redc, P Characterization functions

p) + podc, PI) eff(c, P) - df(c9 P,&

Is characteristic c required for product p req(c,p) - 1:yes, 0:no Can characteristic c be introduced in product p pos(c,p) - 1:yes, 0:no Effort for implementing c in the context of product p; eff(c,p) in person-moths

The first step is to make the goal more precise. Similar to GQM we use a goal schema of the form {minimize/maximize} . The purpose is always either minimize or maximize as PULSE-Eco aims at the definition of an optimization problem.

However, as this concern was well covered by the second objective raised by software development management “minimize the number of variants of assets”, the decision was made to not turn this aspect into an additional benefit function for this objective. For benefit function El it should be noted that its definition already entails the concept of a generic implementation, as it will usually be more complex to implement a characteristic for reuse across all the different products than implementing it just for a single system. Consequently the notion of a generic product needs to be introduced in the product map (cf. Table 6, column labeled DSSA). As this illustrates, coming up with a mathematical definition of the benefit functions and the identification of the characterization functions will usually be a highly iterative process. The other objectives are handled in a similar fashion. During this process it should be a major concern to reduce the overall number of characteristic functions as this otherwise leads to a large amount of knowledge elicitation work. In our experience, a good way to achieve this is to define benefit and characteristic functions together in such a way that a large amount of sharing of characterization functions among different objectives is possible. The example given here illustrates this particularly well, as the company management objective (la) can be completely defined in terms of the characterization functions given in .Table 3. Table 4 provides a list of the characterization functions we used in our example. Similarly, Table 5 describes the benefit functions relevant to our example. All benefit functions are defined in such a way that the higher the returned value the higher the benefit of introducing this characteristic into the core of the reference architecture. Table 4. List of Characterization

Table 3 summarizes the refinement of the effort objective into evaluation functions. The first step is based on questions that are used to elicit additional information about the objectives in order to capture them in a more precise manner. Two main categories of questions can be distinguished. First, goal related questions (such as what is meant by effort) are used to make the goal more precise. In our case, this for example lead to the information that the effort spent in requirements engineering for the individual products was not regarded as a concern by software development management. Second, contributing factors are identified using questions. Besides the obvious criteria of effort spent on developing the characteristics for individual systems respectively on developing a generic implementation, encapsulation of characteristics was identified as a major concern. For example, a characteristic like express orders may impact a large number of functions throughout the system, as it needs to be handled specially in order recording, commissioning, goods entry, etc. As a consequence of this it should be a goal of benefit analysis to introduce characteristics that are difficult to encapsulate as

Name req(c,p)

Description

Values

Is characteristic c required for product 1:yes, 0:no P

pos(c,p) Can characteristic c be introduced in product p eff(c,p)

Functions

l:yes, 0:no

Effort for implementing c in the con- L:low (O.lPM), text of product p (values should only M:medium (O.SPM),H: high(lPM),VH:very be regarded as rough estimates -

PM=person-month)

high (3PM)

enc(c,p) How well is this characteristic encap- 1: very low, 2: low, sulated, i.e., does it interact with oth- 3: high, 4: very high ers? WC)

Is this characteristic mutually exclusive with another one?

msg(c,p) Willinclusionofthischaracteristicina product help to gain market-share?

39

1:yes; 0:no 1: very low, 2: low, 3: high, 4: very high

Table 5. Benefit Functions

Objective la

Corresponding Benefit Function(s)

C(c)

2a

= Creq(c, P

3a

p) + pos(c,

p)

Difficulties that were found during knowledge elicitation for the characterization functions lead to modifications to the product map and the evaluation functions. Also the scales used were a matter of concern and were changed in subsequent iterations. The information resulting from these iterations is entered into the product map and leads to the documented product map. An excerpt of the resulting map is shown in Table 6.

El(c) = C(req(c, P) eff(c, PI) - esf(c, P~~J P -Q(c) = C(req(c, I'

2b

for each of the functions. This is basically a knowledge elicitation task centered around the characterization functions. In our example, we discussed the different product/characteristic-combinations with those stakeholders, who raised the objectives that were the basis for the different characterization functions.

p) + pdc,

p) eff(c, PI) - eff(c, P&

V(c) = enc(c, p) - 2&(c) ; x denotesthe averageover those products in which c is required M(c) = &gk I'

Benefit Analysis

At this point the relevant information has been gathered and needs to be analyzed in detail for defining the scope of the reuse infrastructure. The first step towards this is to identify the appropriate values for the benefit functions. This is done by simply applying the defining functions OII the values elicited for the characterization functions. The result is shown in the right-most columns of Table 6.

PI

At this point all the relevant functions have been defined so that their values can be elicited as described under characterizing the products. Based on this information, computation of the benefit functions is straight-forward. After this is done, the documented product map is complete.

At this point a remark about the different scales is warranted. The scales that are used for the different characterization functions are nominal (e.g., req, pos, alt) or ordinal (e.g., eff, enc, msg) in nature. Consequently, arithmetic operations are not truly defined on these values. However, we assign values (e.g., O/l for no/yes) and define the benefit functions in terms of arithmetic equations. While this is not in general possible, it is possible in our case, as the values and the functions were carefully designed in order to have resulting values that are meaningful. For example, multiplying with yes/no basically amounts to selecting those characteristics for which a “yes”

When identifying the characterization functions it may become clear that the existing structure of the characteristics needs to be changed. It may be actually not so simple to provide the appropriate values for the different characteristics based on this structure. This may lead to an additional iteration cycle. Characterizing

the Products

As shown in Figure 2, the next logical step is to derive values

cf. Table 4 s ‘G 3 i

req: X = yes; _ = no

‘g ‘$

eff: UMIHNH

E 2

enc: l-4

s

alt: O-l

\

Products

p

Product

1

Product 2

pos:x=yes;-=no

msg: l-4

cf. Table 5 g g

C(c): o-np

g ‘$

E,(c): -3-3nP [PM]

mi

E,(C):-3-3np V(c):-2-4 M(c):0-np

[PM]

scope for PL modeling m

scope for reusable Implementation

Table 6. Example

- Documented

40

Product

Map

Product

3

Product 4

was given. This problem is especially prominent with “eff’ where we actually get a numerical result out of nonnumerical values. This was done by using the typical effort required for characteristics of low, medium, etc. effort. Consequently, the result includes a certain fuzziness which could have been made explicit by providing a nominal scale again and defining, for example, M - M = zero. We refrained from this - formally more correct - procedure, as it is not necessary for our purposes.

tics that got a high overall evaluation (these are marked dark grey in Table 6). For the other characteristics only special implementations for specific products should be developed. Applying the weighting schema to customer-based commissioning lead to an inclusion of these characteristics in the raw scope definition. Yet, they were close to the boundary value. Thus, a reevaluation of these characteristics was performed. This lead to the decision that this functional area is so pervasive across systems that it should get full support for developing a generic solution, except for crossdocking which was not regarded as being relevant.

After values were assigned to the benefit functions, it was possible to determine a scope which is aligned with the business objectives. Many different multi-objective decision techniques are described in literature [ 121. In this particular case the application of a simple weighting scheme was sufficient as the number of benefit functions was rather small and could be easily combined.

On the other hand, evaluating article commissioning resulted in a close outsider. This, again, triggered a need to bring in additional human expertise. Closer examination confirmed this decision as article commissioning was found to be not very common and should thus be excluded from the scope.

Actually, if one scans Table 6 some patterns immediately emerge. We will now discuss each of them in turn and describe the decisions that were made for them to illustrate the overall process of scope definition.

In this way, the most appropriate scope can be identified both for domain analysis as well as for developing the architecture and the reuse infrastructure. While this can be done to a large extent directly based on the weighted result of the benefit functions, at some points it is necessary to introduce additional human expertise. There, further iterations may occur (e.g., additional objectives may become clear or the need to look at additional potential products may be raised).

The functional area of order entry consists of three characteristics, each of which was rated good on effort saving and domain coverage provided, leading to a high overall score of this area. Thus, the obvious decision was to include all these characteristics in the scope of the reference architecture and to build reusable assets for them. This was reinforced by the implementation expert who pointed out synergistic effects among the different order entry characteristics.

Further Applications of PULSE-Eco While so far we concentrated merely on determining the appropriate scope for a PL, this technique also provides a basis for other planning tasks in the context of software PLs. Most notably among them is the selection of products that should go into a PL. Some of these tasks can be directly addressed by introducing appropriate business objectives into the evaluation (e.g., deciding on what development to outsource, planning evolution and maintenance of systems). Other tasks need specific extensions of the technique, like the selection of COTS-products or NPV-analysis. We briefly discuss below some of these extensions.

The contrary holds for the functional area of automatic order generation. In this case, effort saving is often actually negative and the value accrued via covering the domain is actually estimated to be rather low. As marketing rates this area also as being only of limited interest, the weighted benefit was actually the lowest one of all functional areas. Thus, this functional area was deemed to be outside the reference architecture and only an interface of the reference architecture to the outside was defined, which supported this functionality for those products (P2) that needed it. As a consequence of this, the characteristics of this functional area were also outside the scope of domain analysis.

An example of a planning task that can be well addressed by PULSE-Eco is the decision of whether to outsource the development of a certain piece of software. This can be handled by introducing adequate objectives into the PuLSEEco process. Examples of business objectives that are relevant to such a decision are:

While the two above-mentioned cases were rather extreme cases, redistribution of goods was much more difficult. Some characteristics could provide a large effort saving (manual redistribution), while others would probably not provide an effort saving (at least not for the current core requirements), but were regarded as rather interesting from a marketing point of view (e.g., whole units). This led to average scores for them. Again other characteristics were not particularly interesting from any point of view (e.g., priority of order), leading to a very low overall evaluation. This lead automatically to the inclusion of only a subset of these characteristics in the raw scope definition. However, all these characteristics are somewhat related to each other. Consequently, it was agreed that all characteristics should be included in the PL scope and, thus, should be subject to PL modeling and be part of the reference architecture. However, reusable implementations should only be developed for those characteris-

1. Do not outsource technology that is critical, i.e., a group of characteristics which is outsourced may not contain a characteristic with criticality greater or equal to high. 2. Outsourcing the development of these characteristics should save substantial costs over in-house development. Another possible application of PULSE-Eco is for planning the evolution and maintenance of systems. In this case the different products of the PL would not necessarily correspond to individual products, but may relate to the same product seen at different points in time. While the above-mentioned applications can be conducted without any change of the technique, some types of analysis would require to extend it somewhat. A straight-forward extension of the current PULSE-Eco technique addresses the

41

products, which are critical information for NPV-analysis.

selection of candidate products for the PL. In this case one would also introduce business objectives for having certain products in the PL, e.g., overlap with reusable assets, contribution to domain coverage, etc. These can be refined in a manner similar to the charac:teristic-related business objectives we considered so far, i.e., they will be again refined into benefit functions describing the benefit of having a specific product as part of the product line. The values of these functions would then be displayed in additional rows below the product map shown in Table 6. In our example, we could introduce an objective like high overlap with reference architecture (large proportion of reuse-based effort savings) in the evaluation. In the example shown this might lead to the identification of P2 as an outsider, because major proportions of the functionality are unique (automatic order generation and article commissioning). However, the excerpt shown is a bit misleading, as in reality P2 is actually well integrated with the overall PL. If the decision would be made to exclude a product, this would also lead to an iteration of the whole process, re-computing the identified scope of the reference architecture, as products and scope definition are closely related in our approach.

4 ANALYSIS AND EXPERIENCE We have used PULSE-Eco several times so far - though a couple of times at the beginning not fully formally. During this experience, a number of advantages and disadvantages became apparent, some of which quickly resulted in modifications to the technique. Overall, the most striking reaction we felt from our customer was an appreciation of the structure and openness provided by the technique to scope the effort. Structure in the sense that the product map gives a broad view achieving a sense of cognitive control over the complexity of the space of variants and associated characteristics. This structure helped a lot to focus the elicitation activities. Openness in the sense that each stakeholder could precisely know what another stakeholder thought about a particular product characteristic wrt. a value function. And further openness as the benefit analysis functions could be negotiated and refined among them. In this way PULSE-Eco made the factors that impact the scoping decision communicable and negotiable among the stakeholders. A minor problem occurs as the table can grow and become unwieldy for large application areas, but this can be addressed by segmenting the table appropriately.

Another important form of analysis which can be supported by PULSE-Eco, is the problem of whether to use a COTSproduct as part of the product line architecture and which one in particular. To address this problem one would add in a first step the identification of a functional area that can be implemented using COTS as a business objective for applying PULSE-Eco. In a second step one could actually use a product-map-like mechanism for evaluating the various alternative COTS-products with respect to the business objectives that are the basis for introducing COTS.. Typical business objectives that play a role in this are:

As the different stakeholders may use different terminology for talking about the characteristics of the products, we found it difficult to define them in a way that simultaneously appeals to all the stakeholders. This problem is c:ompounded by characteristic interaction. While the latter can often be addressed as discussed in Section 3, this is not. always the case and we are still searching for a more general solution. Further, we also noticed that stakeholders may have a different understanding of what is included within one characteristic as opposed to being distributed within or to others. Hence, it can take a while to reconcile these views. But overall, the social process that this activity entails was found to be beneficial to all as long as there was clear leadership.

1. The COTS-product need to support the required characteristics (different levels of criticality may be assigned to the various characteristics). 2. Using COTS should result in a considerable effort saving. 3. The COTS-product should provide a solid basis for the future evolution of the PL. Another important type of analysis for PLs that can be built on top of PULSE-Eco is net present value (NPV)-analysis [9]. NPV-analysis is based on a forecast of the expenditures and revenues of the projects as they develop over time. PULSE-Eco does not by itself provide this information, but is a critical enabler for NPV-analysis as it provides a much sounder basis for expenditure estimations than other approaches. In particular, the exact definition of the scope is important in order to estimate the expenditures accurately at this early point in time.

The possibility of defining the scope of the PL in a way that is explicitly based on the business objectives and that is repeatable and understandable was found immediately appealing by all our project partners. In addition, the openness of the technique to a large variety of different business objectives proved to be very important. As discussed in the previous section, additional types of analysis are possible based on the PULSE-Eco overall structure. While so far we could not yet gather much solid experience with them, we believe they are very important and promising avenues for future research. Besides the different types of extension mentioned in the previous section, we also believe that PULSE-Eco can be extended towards a tool for project tracking by evolving the product map over time as the different phases of the product line project ace executed. Thus the information contained in the product map would become more and more accurate and thus the scope could be continuously validated and if necessary updated.

The product line planning information, which is developed as part of PULSE-Eco, is also an important asset for NPVanalysis as it helps to estimate the distribution of expenditures over time and the market-entry times of the various

42

Points and Reengineering. Proceedings of the Second

From a practical point of view, and as no surprise to us, we found knowledge elicitation to be the most time consuming activity within PULSE-Eco. This entails eliciting, refining, and reaching agreement on the goals, identifying an appropriate set of characteristics, and coming up with the values for the characterization functions. This is also the activity which triggers the most iterations. Consequently, we believe that the overall effort that needs to be spent on PULSE-Eco can be substantially lowered with more experience and adjacent ‘pre-built’ objective packages.

International Workshop on the Design-and Evolution of Software Architecture for Product Families. Las Pal-

mas, Spain, February 26-27, 1998.

WI Jean-Marc DeBaud, Oliver Flege and Peter Knauber. A Method for the Development of Software Reference Architectures. Proceeding of the 3nd International Software Architecture Workshop (ISAW-3), Orlando, FL. Nov. 1998, pp 25-28.

5 CONCLUSIONS In this paper, we introduced a technique for scoping software product lines. The principal advantage of the technique is to strongly ground the identification of the product line scope on business objectives. Further, we believe the technique to be open, repeatable and to provide full traceability to the different stakeholders objectives and values. Yet, the technique is only in its infancy. Much remains to be done.

[91 John Favaro. A comparison of approaches to reuse investment analysis. In Proceedings of the Fourth International Conference on Software Reuse, pages 136145, 1996.

In particular, we have been surprised by the flexibility of the technique when it came to extending it for further purposes, some of which have been described in Section 3.5. We are now orienting ourselves towards the extension and documentation of PULSE-Eco into a few particular areas such as a COTS/GOTS integration, an outsourcing, and a system integration decision models, of course still in the realm of PL enactment.

r.111Wayne C. Lim. Reuse economics: A comparison of sev-

6 REFERENCES [II Lionel C. Briand, Christiane Differding, and H. Dieter Rombach. Practical guidelines for measurement-based process improvement. Software Process Improvement and Practice Journal, 2(3), 1997.

[I31 Shari L. Pfleeger. Measuring reuse: A cautionary tale. IEEE Software, 13:118-127,1996.

PI

Lou Cohen. Quality Wesley, 1995.

Function

Deployment.

[lOI Paul E. Green and Abba M. Krieger. Models and heuristics for product line selection. Marketing 4( 1): 1-19, 1985.

enteen models and directions for future research. In Proceedings of the Fourth International Sojtware Reuse, pages 41-50, 1996.

Conference on

[121 Mansooreh Mollaghasemi and Julia Pet-Edwards. Making Multiple-Objective

Decisions.

IEEE Computer So-

ciety, 1997.

u41 Jeffrey Poulin. Measuring Wesley, 1997.

Software

Reuse. Addison

r151 David Robertson and Karl Ulrich. Planning for product

Addison

platforms. Sloan Management 1998.

131 Department of Defense - Software Reuse Initiative, Version 3.1. Domain Scoping Framework, Volume 2: Technical Description, 1995.

Review,

39(4): 19-3 1,

1161Software Productivity Consortium Services Corporation, Technical Report SPC-92019-CMC. Reuse-Driven Software Processes Guidebook,

Version 02.00.03, No-

vember 1993.

[41 Joachim Bayer et al. Pulse - Product Line Software Engineering. Technical report, Fraunhofer Institute foi Experimental Software Engineering (IESE), Sauerwiesen 6, D-67661 Kaiserslautern, Germany, 1999. [51

Science,

Software Technology for Adaptable, Reliable Systems (STARS), Technical Report STARS-VC-A025/001/00. Organization Domain Modeling Version 2.0, June 1996.

Jean-Marc DeBaud. The Construction of Software Systems using Domain-specifc Reuse Infrastructures. Ph.D. Dissertation, College of Computing, Georgia Institute of Technology, 1996.

(ODM)

Guidebook,

161 Jean-Marc DeBaud. Lessons from a Domain-based

Jim Whitey. Investment analysis of software assets for product lines. Technical report CMU/SEI-96-TR-010, Software Engineering Institute, Carnegie Mellon University, 1996.

Reengineering Effort. Proceedings of the 3rd Working Conference on Reverse Engineering (WCRE-3), Monterey, CA, November 8-10, 1996, pp.217-226.

Janet S. Yu, Javier P. Gonzalez-Zugasti, and Kevin N. Otto. Product architecture definition based upon customer demands. In Proceedings of 1998 DETC: 1998 ASME Design Theory and Methodology Conference, September 13-16, 1998 Atlanta, GA, 1998.

[71 Jean-Marc DeBaud and Jean-Francois Girard. The Relation between the Product Line Development Entry

43