Integrated Design of Production Strategy and Reuse
Scenario for Product Line Development
Zhiqiao WU, Jiafu TANG
Department of Systems Engineering, Key Lab of Integrated
Automation of Process Industry of MOE
Northeastern University
Shenyang, P. R. China
wuzhiqiao@hotmail.com
Abstract—One of the core problems of product line development is
the coordination efforts of product builder and core-asset developer.
More specifically, it is the integration of production strategy decision
and core asset implemention scenario selection. In this paper, we
have developed the CoFAQ (Cost Optimization under Functional
And Quality goal satisfaction constraints) framework which provides
a systematic mechanism for management to analyze all possible
products and evaluate various reuse alternatives at the
organizational level, based on an integrated decision model (IDM).
The solution of CoFAQ is provided to assist decision-maker in
optimizing design when developing a product line towards
minimizing cost, while satisfying system functional and quality
requirements to a certain degree. Considered the IDM model is NP-
complete problem, a two-phased algorithm with heuristic (TPA) is
developed to solve the model efficiently. Using the TPA, the IDM
boils down to a weighted set covering problem for production
strategy decision sub-problem (PSD) and knapsack problem for
reuse scenario selection sub-problem (RSS).
Keywords-software product line; optimization model; heuristic
I. INTRODUCTION
Software product line (SPL) have been regarded as a preferred
software development paradigm due to the large economic
improvements they bring compared to one-at-a-time software
system development [1]. The products in a SPL are assembled
from the organization’s core assets an attached process that
describes how the core asset is used in product. A design of
product line is a description of how the attached processes
cooperate to yield products, and it captures how the organization
builds any product in SPL [2]. Product line designs cover a wider
range of issues and is more complex than the typical project used
by single-product projects. One of the crucial and specific
activities is core assets development. Core-asset developers have
primary responsibility for this process (see Figure 1). The core-
asset developers contribute to the product line design from the
perspectives of having analyzed all products within the scope of
the product line and having developed or selected the
organization’s core assets. The core-asset developers provide
guidance to the product builders on how the assets should be used
by attaching a process to each core asset. Another specific
activities is production strategy charged by product builders. The
product builders contribute to a product line design from their
perspective of actually executing the product-building process
when they meet certain (typically functional) requirements. In this
process a domain model will be formated to tell what kind of
systems they can build based on a product-line architecture for
This work was financially supported by project of National Natural Science
Foundation of China (NSFC 70721001, 70625001) and project of Fundamental
Research Funds for the Central Universities (N090604004)
69
Xiaoqing WANG
IBM Research--China
Beijing, China
xqwangxq@cn.ibm.com
each specific developer. A domain model should also guide the
developers in selecting variants they wish to accommodate into a
system they build.
Although the core-asset developers have primary
responsibility for developing the product line design, the product
builders contribute as well. For effectively contrive a design, it
must be considered adequately from two processes. A
combination of the these processes will, however, have a different
character and different goals in different phases. One of the main
objectives that traverses each phase of a development process is
to select the “best” set of core assets and build the “best” set of
products, but with difference of goals in each phase. In the
product builders phase, it play at least two goals. First, during
domain analysis and product-line scoping, it identify and capture
common and variant requirements. The second goal is to
document a product line architecture, specify a range of variants
implemented by the architecture and document design decisions
related to variants. Since the satisfaction of quality requirements
depends also on the performance of software architecture and
component, it is obvious that the total quality control takes place
in a later phase. In the core-asset developers phase, the goal of the
core-asset builders is assessing core assets sufficiently in order to
estimate appropriateness of their inclusion into the product line.
Such a process may result in selecting several candidates or a
particular asset, or in finding that some desired functionalities
cannot be found in existing core assets and the functionalities
should be implemented in a new component or asset. They are
responsible for including sufficient information about each core
asset’s quality to allow the builders to understand the assets and
make informed choices considered on the total quality
requirements. In all phases, the choice may have significant
consequences on the development costs. Therefore, the tools that
support decisions that minimizing development cost, while
keeping the value of properties of the functional and quality
within a certain threshold, would be very helpful to the product
line practitioners’ tasks.
Figure 1. Relationships between core-asset developer and product builder.
 A significant breakthrough in this field is the first appearance
of optimization techniques [3, 4], and it rapidly draws a great deal
of scholars’ attention [5]. Jung [4] firstly proposed a 0-1 knapsack
model to select the set of software requirements to yield
maximum value while minimizing costs. The concept of value is
kept quite general and may be interpreted as an implementation
priority. Considering the reliability growth as a function of cost,
Berman and Cutler [3] introduced an optimization model to
maximize the reliability of an assembly of assignments under a
budget constraint. Thereafter, many scholars consider it as a cost-
minimization problem within reliability constraint. Taking
delivery time and product reliability into account, Cortellessa [6]
addresses a model that views it as a cost-minimization problem
under quality constraints, by building costs and quality attributes
on a common set of decision variables in a special framework.
They both are integrated solutions for cost management and
failure rate control in software development. Cortellessa [7].
further induces the goal-oriented requirements engineering. It
makes optimal tools sufficient to describe the satisfaction of
system requirements in a precise way.
However, none of the previous work provides an optimization
method extending production strategy determination to
component reuse scenario selection. In fact, there is complex and
nonlinear relation between the two issues, the models or
algorithms for product line reuse optimization considering them
simultaneously received little attention. This paper attempts to
tackle these still unsolved problems where the problem domain
broadly covers the work range of the product builder and the
core-asset developer by using optimization technique.
As integrated modelling of the feature-oriented for functional
requirements and goal-oriented for quality attributes would makes
developers and customers come up with realistic overall
requirements for the target system early, avoiding possible
expensive rework in later stages of the software lifecycle [8]. And,
a pre-selection of core assets and products at the requirements
phase, in particular related to a combination of functional and
quality requirements, can sensibly improve the efficiency of the
whole SPL development process [9] and decrease the
development costs [7], we have developed the CoFAQ framework.
For coordinates the efforts of product builders and core-asset
developers effectively, we first devise a non-linear optimization
model (IDM) where 0-1 variables select product and core-asset
instances, the special objective formulation represents the cost of
the whole software product line to be minimized, and each major
constraint represents the value of a property of the whole product
line to be kept under/over a certain threshold in order to meet
functional and quality requirements. Such formulation involves
further variables representing the number of reuses of the core-
asset in a pilot study. Since these combining variables enter the
cost objective and the requirement constraints formulation, the
model takes into consideration the production strategy’s costs and
functional requirements together with core assets’ costs and
quality requirements, and makes optimal decision in not only the
best reuse scenario to be implemented for each core asset, but also
the best production strategy to fulfill the functional and quality
constraints while minimizing development costs.
This paper is organised as follows. Section 2 gives integrated
decision (IDM) process. Then, considered the model is NP-
complete problem, a two-phased algorithm with heuristics (TPA)
is developed in section 3. Finally, concluding remarks are given in
section 4.
70
II. INTEGRATED DECISION MODEL
A. Problem Formulation and Notations
To formulate the problem, the following notations are used
throughout this paper.
L Number of products within a target SPL system;
J Number of modules within a target SPL system;
m j Number of reuse scenarios available for module j;
R Number of regions of target market;
j = 1,..., J Index of modules in a target system;
i = 1,..., m j Index of reuse scenario;
l = 1,..., L Index of products in a target system;
r = 1,..., R Index of regions of target market;
k = 1,..., K Index of quality goals of a target system;
t = 1,..., T Index of functional goals of a target system;
Gt The t-th group of functional goals;
cij Implementation cost of reuse scenarios i for module j;
τl The cost of the l-th assembly product, i.e., the cost of
integration and adaptation needed to build the product;
U Accepted level of satisfaction of requirements for the SPL
system;
Satij ( k ) Satisfaction level of quality goal k when module j is
implemented by using scenario i;
χ ijk The probability that test input occurs during the real use
of operation k when module j is implemented by using scenario i;
Fgl (t ) is equal to 1 if the t-th functional goal is satisfied by
the l-th product, and 0 otherwise;
M l The set of modules was included by product l;
Pj The set of products was made up by module j;
Ar The set of alternative group goals was belong to market
region r;
Cr The set of common group goals was belong to market
region r ;
xij Decision variable, it equals 1 when module j is
implemented by using scenario i, and 0, otherwise;
yl Decision variable, it equals 1 when product l is selected in
the platform, and 0, otherwise;
w j An integer decision variable, that represent the number
of reuses of the module j.
B. Cost Analysis and the Objective Function
In this section we try to setting out reuse cost from view
points of product line given in [10]. Clements [1] summarizes the
activities in product line. The issue of reuse strategies and their
costing policies in reuse-based development is introduced in [11].
In order to assign reuse cost from various scenarios efficiently
and identify operations without repeat costing, we reinvestigate
the operations categorization and contrive a 6-layers hierarchical
scheme for a common software product line process from the
perspectives of work range in the product builder and the core-
asset developer, as shown in Figure 2. And operations for each
layer are explained in the following subsections. For simplicity,
let C represent the cost regards to an operation, and W represent
the number of reuses of the asset in a pilot study.

Figure 2. The6-layers hierarchical scheme of reuse scenario processes.
This article assumes that a core-asset repository has been
established in which assets are stored or cataloged for the benefit
of other products. From the core-asset developer perspective,
there are several acquisition ways of asset, including purchasing
asset from a source outside the organization, effort of investment
in seeking an appropriate asset, whether it is stored in a core-asset
repository or available elsewhere either in an organization or in
public domain, and a new asset from scratching. These operations
involved cost is presented as layer1 to 5.
Operations of layer-1 ○ 1 *External Utilization( C
EU
): It is
typically the activities of acquiring a Commercial Off-The-Shelf
(COTS) asset and cataloging it in the repository. The cost is
usually the purchase price.
Operations of layer-2 ○ 5 Copy and Paste( C
CP
): It is the
activity of acquiring a copy of a private asset for a specific
product. The source asset is not cataloged in the repository, and
awareness of its existence is based on personal knowledge. ○ 6
Made to order( CMD ): The activity of constructing a target private
asset directly from scratch.
Operations of layer-3 ○ 2 *Made for Reuse( C
MR
): The
activity of constructing a new repository asset from scratch. It is
expected that the asset will be developed in conformance with
applicable standards that make it effectively reusable. ○3
*Mining and Cataloging( CMC ): The activity of identifying and
derived from the direct effort invested in performing private
modifications to a certain artifact, at the specific product level, to
obtain a specific product. ○ 8 Black-Box reuse ( C ): Acquiring a
BB
copy of a repository asset “as is” (that is, with no modifications)
for a specific product as a private asset. Because the reused
artifact itself is not changed, there is no modification cost as such.
However, extra effort may be required to adapt the architecture,
interfaces, or other artifacts of the target product in order to
enable the asset to be integrated.
Operations of layer-6 From the perspective of the product
builder, an important phase is how to integrate the available assets
to develop a targeted application or a new asset. The operations
involved in this phase are the activities of analysis, design, and
coding of new or modified artifacts, as well as integration,
verification and validation activities performed directly on the
available asset. The cost incurred in this phase includes the effort
on integration, verification, validation and risk management [12].
The cost of operations in this layer are determined by the
assembly product τ l .
In summary of the aforementioned operations of an asset in
product line, one can generalize the product line process and lead
to six typical reuse modes from pure development to systematic
reuse. They are pure development (PD), opportunistic reuse (OR),
controlled reuse (CR), systematic reuse-COTS (SRC), systematic
reuse-adapted (SRA) and systematic reuse-new (SRN), as shown
in Figure 3. The node denoted by a circle in the Figure 3 shows an
operation with a specific number; an edge between two nodes
indicates there is an arc between operations from left to right, and
the star(*) indicates that operations were implemented one time,
without importing repeat in the same system.The reuse mode PD,
OR and CR are called opportunistic reuse, and the remains are
systematic reuse.
Figure 3. Typical reuse modes.

acquiring an existing private asset, from a certain product, and
then storing and cataloging formally as a repository asset. ○
Cataloged and Commission( CCC ): The activity of acquiring a
copy of a repository asset for a specific product as a private asset.
Although in most cases this cost is expected to be close to zero,
license or royalty fees may apply as well.
Operations of layer-4 ○7 *Adaptation for Reuse( C
AR
): It is
the operation of modifying an existing repository asset to
compatible with the reuse standards applicable for a special
purpose.
Operations of layer-5 Two types of operations are available
for software reuse, they are: ○ 9 White-Box reuse ( C ):
WB
Modifying an existing private asset into another private asset. It
The cost under the typical six reuse modes are given in detail
4
as follows.
1) Pure Development (PD): In this mode, each product
team responsible for one module is unaware of the existence
of core-asset and develops its target from scratch via white-
box reuse. Thus, the total cost composed of charge for scratch
effort and for modification, and of course the reliability is
product of the ones of the two operations, as formulated in (1).
PD cost c(w) = w × CMD + w × CWB (1)
2) Opportunistic Reuse (OR): Each group responsible for
some of the L modules knows that there exists a viable source,
but it is not stored in any shared repository or registered in a
public catalog. Therefore, each of the products invests

71
independently in searching for it, obtaining a copy of it as a
private source asset and then modifying it (white-box reuse) for
utilization in target component.
OR cost c( w) = w × CCP + w × CWB (2)
3) Controlled Reuse (CR): Under this mode, a copy of a
private component is first mined and cataloged as a repository
asset. Other than the mining and cataloging effort, no other effort
is invested in modifying it, and it is made available for other
products for acquisition in its original form. Thus, each of the
products will acquire a copy, similarly to the previous mode.
CR cost c( w) = CMC + w × CCC + w × CWB (3)
4) Systematic Reuse-adapted (SRA): In this case, it is
responsible for looking for code assets in specific products,
mining them, and cataloging them in the component. Then, it will
undergo modifications to convert it into a reusable asset.
SRA cost c( w) = CMC + C AR + w × CBB (4)
5) Systematic Reuse-new (SRN): In this mode, the acquisition
cost represents construction man-hours of the new component. It
is based on new for reuse development (instead of adaptation).
SRN cost c( w) = CMR + CAR + w × CBB (5)
6) Systematic Reuse-COTS (SRC): It is typically the activities
of acquiring a COTS asset form the market. Then, it will undergo
modifications to convert it into a reusable asset.
SRC cost c( w) = CEU + C AR + w × CBB (6)
In an industrial software projects, every alternative reuse
scenario can be derived from a special mode, regardless of the
specific costing policies used. Considered on the characteristic of
assets possessed by an organization, developer could directly
produce and weigh alternative implemented scenarios based on
the modes depicted in the former formulas. It obviously that
relation between reuse mode and scenario is not one one-to-one
correspondence in actual practice.
We devise the objective function F represents the combining
cost of the production strategy and reuse scenario to be minimized
simultaneously:
F ( xij , yl , w j ) = productionstrategy cost + reusescenario cost
n mj p
= ∑∑ c( w j )ij xij + ∑τ l yl
j =1 i =1 l =1
In next section, we try to provide a mathematical model for
making reuse scenario selection more effectively.
C. Goal Satisfaction Constraints
In this subsection, we try to model system functional and
quality requirements as a domain analysis for product-lines.
Feature-oriented domain analysis is a widely accepted domain
analysis method for modelling common and variant requirements
for product lines. Goal-oriented analysis, on the other hand,
focuses on quality attribute analysis in single system development.
Jarzabek [8] provides model integrating these two well-known
methods, in which requirements of a domain can be categorised
into features and quality attributes. In agreement with Jarzabek’s
work, we illustrate goal satisfaction constraints functional and
quality goal respectively.
1) Production Strategy Ddecision with Functional Goal
Constraint: In a product line, since goals should provide the
rationale for variations in domain requirements, it is used as a
72
discriminator that enables us to identify common and variant
requirements or variation points. Variant requirements are
identified in two ways [13]; first, alternative variation: from a set
of alternative goals, only one goal can be chosen to achieve a
specific domain product-defining as an exclusive relationship,
which means a “1 from n choice”. Second is optional variation
(goal): optional scenarios for a goal may or may not be integrated
into the system. This means that from a set of optional scenarios,
any number of scenarios can be chosen (from zero to all).
Consequentially, optional goal is less considered in first-order
cost models, but in economic models. In this paper, we try to
formulate production strategy assignment with constraint
functions for common and alternative goals satisfaction.
Functional requirements are referred as functional goals,
which can be effectively specified in “Available” or “N/A”. The
relationship between the functional goals and the products is
described by Fgl(t) where it equal to 1 if the t-th goal is satisfied
by the l-th product, and 0 otherwise. For addressing the method in
widely applicable, it assume the common and alternative relations
expressed by grouping goals. Certainly, single goal in a group is
allowed as a special case. For common goals, whatever the
products selected in product line a group of goal should be
implemented compulsorily for each special market region r,
formulated as constraint (7).
p
(7)
SCG = ∏ ∏ ∑ Fg (t ) × y l l = 1, ∀r
Gt ∈Cr t∈Gt l =1
On the contrary, the only one alternative group of goal with
an exclusive relationship can be chosen for each special market
region r, formulated as constraint (8).
p
(8)
SAG = ∑ ∏ ∑ Fg (t ) × y
Gt ∈Ar t∈Gt l =1
l l ≥ 1, ∀r
2) Reuse Sscenario Sselection to Ssatisfy Quality Goal
Constraint: Unlike functional goals, in most cases quality goals
should be not leveraged merely by satisfied and unsatisfied, i.e. (1,
0). As discussed in the former sections, the satisfaction of quality
requirements depends mainly on the performance of software
architecture and component, it is obvious that the total quality
control takes place in the core-asset developers level.
In light of the goal-oriented requirement engineering approach
[14], assuming that satisfaction level Satij(k) is available by
matching core-asset reuse scenario preference up to the pattern
and its value corresponds to integer number in [0,1]. Therefore, it
could explicitly formulate the overall performance of module j
was implemented by using scenario i can be evaluated in terms of
a weighted satisfaction of each goals, and thus is given as
K
Satij = ∑ χ ijk × Satij ( k ) (9)
k =1
Thus, no matter in which scenario a module is reused, the
targeted software system should meet an accepted overall
satisfaction level at least U. It is given as:
mj
n
(10)
SAT = ∑∑ ω j Satij xij ≥U
j =1 i =1
Where ω j is the weight of module j. The AHP is utilized to find
the module weights based on the access frequencies of the
modules[15].
D. Integrated Decisions Model
In summary of the above formula, one can conclude the
integrated decision on minimum product line cost consider
production strategy decision and reuse scenario selection Secondly, if the alternative sets have the same munber of the
simultaneously using the following model (IDM): elements, it cut down the set with more assembly cost. Due to the
n m p j
(11) ultimate aim of the IDM is cost minimization.
min F ( x , z ) =
ij c( w ) x + τ y
ij ∑∑ j ij ij ∑ l l
j =1 i =1 l =1 Based on the Cut Set Strategy (CSS), therefore, in order to
mj
n K deduce the optimal production strategy the following procedure is
s.t. SAT = ∑∑ ω j Satij xij ≥U , where Satij = ∑ χ ijk × Satij (k ) used:
j =1 i =1 k =1
(12) PS_Procedure: production strategy decision Heuristic (PS)
p for product line
SCG = ∏ ∏ ∑ Fg (t ) × y
Gt ∈C r t∈Gt l =1
l l = 1, ∀r (13)
Begin
p
Step1: Initiation t=0; set Gt unlocked
SAG = ∑ ∏ ∑ Fg (t ) × y
Gt ∈Ar t∈Gt l =1
l l ≥ 1, ∀r (14) Step2: Solve for set covering problem (Traditional Algorithm)
Step3: If find the unlocked smallest number of Gt, Cut Gt
mj
from Ar then go to Step5
yl ≤ ∑ xij , ∀j ∈ { j : j ∈ M l , l = 1,..., L} (15)
i
Else if the alternative sets have the same munber of
mj the elements, go to Step 4
∑x
i
ij ≤ 1, ∀j (16) Else go to Step 6
Step4: If find the unlocked Gt with max assembly cost, Cut
w j = ∑ yl , ∀j (17) Gt from Ar then go to Step5. Else go to Step 6
l∈Pj
Step5: If the alternative goal constraint is unsatisfacted then
xij , yl = 0 /1, ∀i, j (18) restore Gt and set it locked. Go to Step 3
Else go to Step 6
Constraint (15) shows if a product is selected in the Step6: Output the feasible solution or non-feasible solution,
production plan, all the composed modules of the product are then stop
also included. It is easy to find that the IDM problem here End
addressed is NP-complete. It can be hardly solved by traditional
nonlinear programming techniques such as GINO, gradient search B. Reuse Scenario Selection Sub-problem (RSS)
methods, and quasi-Newton method, where only the local optimal
solution may be found. However, the computation will also After the cover sets determining, the products and modules
become more complex and difficult with increased number of was assiged at the same time. At next step the core-asset builders
products, modules, and reuse scenarios. It is difficult to solve by need select the most effective reuse scenario for each module.
traditional nonlinear programming techniques. Thus a more Dantzig [16] showed that an optimal solution for the
effective method is needed to solve the IDM model. continuous 0-1 knapsack problem could be obtained by sorting
the items according to their non-increasing profit-to-weight ratios
III. A TWO-PHASED ALGORITHM(TPA) FOR THE IDM (also called efficiencies), and adding them to the knapsack until
the capacity is reached. It can be observed that the reuse scenario
It is easy to find that the IDM problem here addressed is NP- selection procedure is similar to 0-1 integer knapsack problem.
complete since it boils down to a weighted set covering problem Thus, this paper develops a reuse scenario selection Heuristic (RS)
for production strategy decision sub-problem (PSD) and knapsack method for this 0-1 integer programming.
problem for reuse scenario selection sub-problem (RSS). For
solving the two sub-problems effectively, production strategy RS_Procedure: reuse scenario selection Heuristic (RS) for
decision heuristic (PS) and reuse scenario selection heuristic (RS) module
has been provided respectively.
Begin
A. Production Strategy Decision Sub-problem (PSD) Step1: Initiation t=0; SolutionSet=“null”
There are two kinds of grouping goals (i.e. alternative and Step2: Sorting the scenarios according to their non-decreasing
common) for production strategy decision constraints. However, cost-to-satisfaction level ratios (i.e. efficiencies etj)
we can identify the common grouping goals which is compulsory Step3: Find xtj where min etj for all j
component for optional products and include them in the product Update SolutionSet with xtj
plans for satisfacting SCG constraint, that means we just focus on
the alternative grouping goals. Obviously, it can use the Step4: Loop the SolutionSet’s satisfaction to accepted level U
calculated by (2)
traditional greedy algorithm to get the minimum sets which cover
all alternative grouping goals. Still for selecting a minimum cost Loop up to find xt+1j with min (et+1j - etj ) and
of the modules to develop and satisfacting SAG constraint, we unlocked for all j
need cut the fungible alternative grouping goals. Considered If xt+1j = “null”, set xtj locked
component implementation cost and reusability, we define a Cut End loop
Set Strategy (CSS) for geting least sets (i.e. modules) and Update SolutionSet with xt+1j
minimum assembly costs solution as listed: End loop
Firstly, it cut the set with the smallest number of the elements. Step5: Output the solution with minimum cost calculated by
Due to get rid of a larger set may reduce the number of reuses and SolutionSet
make the solution infeasible, and the cost estimation functions End
indicate that the more times of reuse the less cost may pay.

73

Figure 4. Solution framework of the method with heuristics framework and
overall procedure of the TPA with heuristics.
To summarize the above analysis, the solution framework of
the two-phased algorithm (TPA) is illustrated as shown in Figure
4. The overall procedures of the TPA with heuristics are:
Framework of the two-phased algorithm (TPA)
Begin
Step1: Initiation t=0; set Gt unlocked
Step2: Solve for set covering problem (Traditional Algorithm)
Step3: If find an unlocked Gt using PS_Procedure go to Step 4
Else go to Step 7
Step4: Cut Gt from Ar
Step5: If the alternative goal constraint is unsatisfacted then
restore Gt and set it locked, go to Step 3
Else go to Step 6
Step6: If find the optimal reuse scenario for the selected modules
by using RS_Procedure, then storing the optimal solution.
Go to Step 3
Else restore Gt and set it locked, then go to Step 3
Step7: Output the globally optimal solution x*, y* by comparing
local optimal objective values, then stop
End
IV. CONCLUSIONS
The model described in this paper is a powerful tool for this
issue by integrating design of production strategy and reuse
scenario, when developing a SPL towards minimizing cost, while
satisfying systems functional and quality requirements to a certain
degree. The major contribution of this model is the clear
identification, evaluation and comparison all possible products,
together with alternative scenarios of core assets implemention in
a focused and accurate way. Therefore, it provides a systematic
mechanism for management to analyze products and evaluate
various reuse alternatives at the organizational level, viewed from
the standpoint of the entire product line. There are two other
contributions. Firstly, we describe a special formulation for the
case of cost minimization under functional and quality
requirement constraints. Such formulation involves further
variables representing the number of reuses of the core-asset in a
pilot study. Since these combining variables enter the cost
objective and the requirement constraints formulation, the model
takes into consideration the production strategy’s costs and
functional requirements together with core assets’ costs and
74
quality requirements. Secondly, it might be difficult to obtain
optimal solutions of large-scale instances due the non-linearity of
the model. In this cases approximate solutions can be obtained by
the TPA algorithm with heuristic. To a great extent, the parameter
estimation of the CoFAQ is based on evaluated data and is
therefore subject to the inaccuracies of evaluation. Moreover, in
different reuse factors (e.g. various units in an organization,
applying reuse at different opportunities, or even different
individuals using reuse technology), estimation might vary
significantly. However, when this model is applied consistently
within an organization, the accumulated data can be analyzed for
better estimates in the future. Recently, we are analyzing the data
obtained from a large number of companies in order to derive
organizational impact factors that can be applied for estimations
more precise.
REFERENCES
[1] P. C. Clements, L. G. Jones, and L. M. Northrop, Project management in
a software product line organization, the IEEE Computer Society, vol. 22,
no.5 pp. 54-62, 2005.
[2] F. Ahmed and L. F. Capretz, The software product line architecture: an
empirical investigation of key process activities, Information and
Software Technology, vol. 50, no.11 pp. 1098-1113, 2008.
[3] O. Berman and M. Cutler, Optimal software implementation considering
reliability and cost, Computers & Operations Research, vol. 25, no.10 pp.
857-868, 1997.
[4] H. W. Jung, Optimizing value and cost in requirements analysis, IEEE
Software, vol. 15, no.4 pp. 74-78, 1998.
[5] V. Cortellessa, F. Marinelli, and P. Potena, Automated selection of
software components based on cost/reliability tradeoff, in Lecture Notes
in Computer Science Heidelberg: Springer-Verlag Berlin, 2006, pp. 66-81.
[6] V. Cortellessa, F. Marinelli, and P. Potena, An optiization framework for
"build-or-buy" decisions in software architecture, Computers &
Operations Research, vol. 35, no.10 pp. 3090-3106, 2008.
[7] V. Cortellessa, I. Crnkovic, F. Marinelli, and P. Potena, Experimenting
the automated selection of COTS components based on cost and system
requirements, Journal of Universal Computer Science, vol. 14, no.8 pp.
1228-1255, 2008.
[8] S. Jarzabek, B. Yang, and S. Yoeun, Addressing quality attributes in
domain analysis for product lines, Iee Proceedings-Software, vol. 153,
no.2 pp. 61-73, 2006.
[9] S. S. Gokhale, W. E. Wong, J. R. Horgan, and K. S. Trivedi, An
analytical approach to architecture-based software performance and
reliability prediction, Performance Evaluation, vol. 58, no.4 pp. 391-412,
2004.
[10] B. Boehm, Managing software productivity and reuse, IEEE Computer
Society, no.9 pp. 111-113, 1999.
[11] A. Tomer, L. Goldin, T. Kuflik, E. Kimchi, and S. R. Schach, Evaluating
software reuse alternatives: a model and its application to an industrial
case study, IEEE Transactions on software engineering, vol. 30, no.9 pp.
601-612, 2004.
[12] Y. Peng, G. Kou, G. X. Wang, H. G. Wang, and F. I. S. Ko, EMPIRICAL
EVALUATION OF CLASSIFIERS FOR SOFTWARE RISK
MANAGEMENT, International Journal of Information Technology &
Decision Making, vol. 8, no.4 pp. 749-767, 2009.
[13] J. Kim, S. Park, and V. Sugumaran, DRAMA: A framework for domain
requirements analysis and modeling architectures in software product
lines, Journal of Systems and Software, vol. 81, no.1 pp. 37-55, 2008.
[14] A. v. Lamsweerde and E. Letier, Handling obstacles in goal-oriented
requirements engineering, IEEE Transactions on software engineering,
vol. 26, no.10 pp. 978-1005, 2000.
[15] H.-W. Jung and B. Choi, Optimization models for quality and cost of
modular software systems European Journal of Operational Research,
vol. 112, no.3 pp. 613-619, 1999.
[16] G. B. Dantzig, Discrete-variable extremum problems, Operations
Research, vol. 5, no.2 pp. 226–288, 1957.