Anchoring the Product Line Process – Tailoring the RUP Life-Cycle ...

kettleproduceΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

127 εμφανίσεις






Anchoring the Product Line Process 
Tailoring the RUP Life-Cycle Model to
Software Product Line Development
Magnus Eriksson, Jürgen Börstler and Kjell Borg
UMINF-07.18
ISSN-0348-0542













UMEÅ UNIVERSITY
Department of Computing Science
SE-901 87 UMEÅ
SWEDEN


Abstract
In this paper we present an extended life-cycle
model tailored to the specific needs of domain- and
application engineering projects using the unified
process. The purpose of this work was to provide a
basis for product line organizations to perform
systematic phase reviews. Tailored phase reviews will
help organizations to anchor the product line process
over the product line life-cycle. As a basis for our
work we utilized SEIs framework for product line
practice as well as our experiences applying the
unified process in a product line context.

1. Introduction

The IBM-Rational Unified Process
1
(RUP) [11] is
a commercial product which provides a framework
for a software development process. RUP is well
established and has become widely used in the
software industry.
As BAE Systems Hägglunds
2
transitioned towards
software product line development, we noticed a
number of shortcomings in the RUP life-cycle model.
These shortcomings are a result of RUPs restricted
scope on single system development projects. There-
fore there are no built-in mechanisms for managing
the coordination between different development
projects and post-delivery maintenance activities.
In this paper, we therefore propose an extended
RUP life-cycle model tailored towards the specific
needs of software product line development.

1.1. The RUP Life-Cycle Model

RUP is an iterative and incremental development
process. The basic idea of iterative development is to
develop systems incrementally by applying the
waterfall model [12] on portions of the system several
consecutive times. These miniature waterfalls are
referred to as iterations (see Figure 1). Incremental
development enables teams to work more risk-driven,
since the most critical parts of a system can be
developed and tested early in a project. It furthermore
helps to find contradictions in requirements, design
and implementations early, since an executable subset
of the system is developed in each iteration.



1
RUP is an instance of the Unified Software Development
Process (USDP) [10].
2
BAE Systems Hägglunds is a leading developer and
manufacturer of defense vehicles and a supplier of various
turret systems.

Figure 1. An overview of RUP [11].

The RUP life-cycle model divides project
iterations into four phases: Inception, Elaboration,
Construction and Transition. Each phase ends with a
major project milestone (see Table 1 for milestone
evaluation criteria). These RUP milestones are based
on the Life-Cycle Objectives (LCO), Life-Cycle
Architecture (LCA), and Initial Operational
Capability (IOC) milestones proposed by Boehm [3]
to anchor the software development process.
The goal of the Inception Phase is to achieve
concurrence among the system stakeholders on the
life-cycle objectives for the project. A major part of
this is to determine scope and boundaries for the
software to be developed. The phase ends with the
Life-Cycle Objectives (LCO) milestone.
The goal of the Elaboration Phase is to baseline
the software architecture, to provide a stable basis for
the bulk of the design and implementation work in the
construction phase. The elaboration phase ends with
the Life-Cycle Architecture (LCA) milestone.
The goal of the Construction Phase is to clarify
the remaining requirements and to develop the
operational software based on the baselined software
architecture. The construction phase end with the
Initial Operational Capability (IOC) milestone.
The goal of the Transition Phase is to ensure that
the software is readily available to its end-users. This
includes activities such as testing and making minor
adjustments based on user feedback. The transition
phase ends with the Product Release (PR) milestone.
After the transition phase the project life-cycle
ends. The product could either die (from the
development organizations perspective), or evolve
into a new generation. If the product evolves into a
new generation the four phases are applied again as
part of a new development project (see Figure 2).



Inception
Inception
Elaboration
Elaboration
Construction
Construction
Transition
Transition
Evolution
Evolution
Inception
Inception
Elaboration
Elaboration
Construction
Construction
Transition
Transition
Evolution
Evolution
Generation 1
Generation 2
Time
Time
Initial development cycle
Next evolution cycle

Figure 2. An example of a RUP Evolution cycle [13].
Table 1: An overview of the RUP milestone criteria [13].
Inception
RUPLCO
Elaboration
RUPLCA
Construction
RUPIOC
Transition
RUPPR
1. Stakeholder concurrence
on scope definition and
cost/schedule estimates
3,4
.
2. Agreement that the right
set of requirements have
been captured and that
there is a shared
understanding of these
requirements
3,4
.
3. Agreement that the
cost/schedule estimates,
priorities, risks, and
development process are
appropriate
3,4
.
4. All risks have been
identified and a mitigation
strategy exists for each of
them
3,4
.
1. The product Vision and requirements are stable
4
.
2. The architecture is stable.
3. The key approaches to be used in test and evaluation are
proven
3,4
.
4. Test and evaluation of executable prototypes have
demonstrated that the major risk elements have been
addressed and have been credibly resolved
3,4
.
5. The iteration plans for the construction phase are of
sufficient detail and fidelity to allow the work to proceed
3,4
.

6. The iteration plans for the construction phase are
supported by credible estimates
3,4
.
7. All stakeholders agree that the current vision can be met
if the current plan is executed to develop the complete
system, in the context of the current architecture
4
.
8. Actual resource expenditure versus planned expenditure
is acceptable
3,4
.
1. Is this product
release stable and
mature enough to
be deployed in the
user
community
3,4
?
2. Are all the
stakeholders ready
for the transition
into the user
community
3,4
?
3. Are actual
resource
expenditures
versus planned
still acceptable
3,4
?
1. Is the user
satisfied
3,4
?
2. Are actual
resource
expenditures
versus
planned
expenditures
acceptable
3,4
?



3
Criterion applicable also in domain engineering projects (see section 3.3).
4
Criterion applicable also in application engineering projects (see section 3.4)
1.2. Related Work

We found little guidance in literature on tailoring
the RUP life-cycle model to product line develop-
ment. Boehm [3] suggested that the LCO and LCA
milestones could be extended and utilized to also
anchor the management of software product lines. He
suggested that for the LCO milestone the breadth of
the product line domain need to be determined (i.e.
scoping), and for the LCA milestone a product line
architecture must be developed. These criteria are
technically sound but not detailed enough to be useful
from a practical project management perspective.
Zhang and Kunz [15] mapped some product line
development activities to the phases of RUP, but
provided no guidance on how to tailor the milestone
evaluation criteria.
Gooma [8] mapped domain engineering and
application engineering activities to the phases of the
Unified Process, but focused on modeling and artifact
development rather than product maturity and project
management.
Ambler [1] also recognized the need to expand the
scope of the unified process to also include opera-
tions, support and maintenance processes. He added a
Production Phase to the life-cycle. Furthermore,
Ambler added an Operations and Support- and an
Infrastructure management workflow to the
process. The purpose of the infrastructure
management workflow was to add portfolio
management, organization-wide models, etc. to the
process. However, Ambler did not focus on the
specific needs of the software product line approach.

1.3. Contributions

This paper aims to provide a basis for phase
reviews for software product line development
projects. As a basis for our work we have used SEI s
framework for product line practice [7]. We have also
utilized experiences from our own product line


adoption efforts, and to some extent Goomas work as
discussed above.
Hägglunds utilizes the domain engineering unit
organizational model [6] (see Figure 3). The
proposed life-cycle model is therefore likely to be
best suited for organizations utilizing a similar model.
However, results are expected to be interesting also to
organizations utilizing other organizational models.

Business unit
Business unit
Business unit
Domain engineering unit
Reusable Core Assets
Architecture Components
Product 1
Product 2
Product n

Figure 3: The  Domain Engineering Unit
organizational model [6].
The remainder of the paper is structured as
follows: Section 2 discusses some of the issues with
the RUP life-cycle model from a software product
line perspective. Section 3 presents an extended RUP
life-cycle model tailored towards software product
line development. Section 4 concludes the paper.

2. Shortcomings of RUP Life-Cycle Model

As mentioned in section 1, the RUP life-cycle
model targets a single system development project.
This is a serious issue form a software product line
perspective, since (technical) coordination is a
cornerstone of the product line approach. Another
problem is that the RUP life-cycle model does not
support post-delivery maintenance. This is important,
since product line engineering actually focuses more
on maintaining the core assets than on developing
products. Section 2.1 and 2.2 will elaborate on these
shortcomings.

2.1. Project coordination

As illustrated by Figure 4, software product line
development consists of two major process flows:
Domain engineering and Application engineering.
Utilizing the  Domain Engineering Unit
organizational model (see Figure 3) this typically
translates to two different types of projects that need
to be managed and coordinated within a product line
organization. Domain engineering projects producing
core assets and application engineering projects
producing actual products based on the core assets.

Domain
Analysis
Domain
Design
Domain
Implementation
Application
Requirements
Application
Design
Application
Coding
Requirements
Components
Architecture
Reference Architecture Reusable Components
Domain Technology
Reference Requirements
Traceability
Traceability
Feedback / Adaptations / Reverse Architecting
Legacy Code,
Domain
Expertise
New
Requirements
Domain
Engineering
Application
Engineering

Figure 4. The PRAISE Software Product Line
Reference Process [14].

2.2. Maintenance

Comparing the purpose of each RUP phase to the
phases of the ISO/IEC 15288 standard [9] (see Figure
5) reveals that the RUP life-cycle model does not
cover the utilization/support (maintenance) and retire-
ment phases of a systems life-cycle (see Figure 6).
Examples of maintenance tasks in a domain
engineering context could be:
· Expanding the product line scope. If a new
product can be accommodated by the product
line architecture, even though it falls outside
of the product line scope.
· Modifying the product line architecture to
accommodate a new product, if it can not be
accommodated even though it falls within the
product line scope.
· Implementing quality improvements.
Feedback from application engineering
projects could lead to implementation of
quality improvements in core assets.
Examples of maintenance tasks in an application
engineering context could be:
· Propagate quality improvements. Replace
core asset components to propagate quality
improvements that have been identified in
other products in the product line.
· Update to a newer generation of the core
assets, to enable the domain engineering team
to retire the current generation.
To perform all such maintenance tasks by
initiating an evolution project (see section 1.1) is not
likely to be cost effective.



Life Cycle
Stages
Purpose Decision Gates
CONCEPT
 Identify stakeholders
needs
 Explore concepts
 Propose viable solutions
DEVELOPMENT
 Refine system
requirements
 Create solution
description
 Build system
 Verify and validate
system
PRODUCTION
 Produce systems
 Inspect and test (verify)
UTILIZATION
 Operate system to satisfy
users needs
SUPPORT
 Provide sustained system
capability
RETIREMENT
 Store, archive, or dispose
of the system
Decision Options:
 Execute next stage

 Continue this
stage
 Go to a preceding
stage
 Hold project
activity
 Terminate projects


Figure 5. ISO/IEC 15288 System life-cycle stages [9]

Utilization Stage
Concept
Stage
Development
Stage
Production
Stage
Support Phase
Retirement
Phase
Inception
Phase
Elaboration
Phase
Construction
Phase
Transition
Phase

Figure 6: An example of how the RUP life-cycle
could be mapped to the ISO/IEC 15288 life-cycle.

3. Proposed Life-Cycle Model Extensions

This section describes the extended RUP product
line life-cycle model and the analysis method
employed to develop it.
Sections 3.3 and 3.4 can be viewed as annotated
cross-reference lists between the original RUP lif e-
cycle model and our extended life-cycle model.
References to milestone criteria in these sections have
the form  RUP- ,  DE- ,  AE-  and refer to
the milestone criteria of Table 1, Table 2 and Table 3
respectively.

3.1. Analysis Method and Rationale

To address the RUP life-cycle model issues
discussed above, we analyzed how the specific needs
of domain engineering- and application engineering
would map to the original goals and milestones of
RUPs phases. During the analysis each milestone
criterion was classified as:
· No tailoring is needed. The criterion is
directly applicable also in the new domain- or
application engineering context.
· Criterion must be refined. The criterion is
replaced by one or more criteria specific to
domain- or application engineering projects.
· Criterion must be extended. The criterion is
applicable also in the new domain- or
application engineering context, but must be
supplemented by one or more criteria specific
to the new context.
We used the original RUP milestone criteria instead
of some more elaborate model (such as MBASE [5]
or the Enterprise Unified Process [2]), to maintain
traceability to the original process model.
To identify the specific product line development
needs, the different practices areas of SEIs frame-
work for product line practice [7] were analyzed. As
Boehm [4], we feel that SEIs framework contains
many useful guidelines regarding software product
line development. As the practice areas were analyzed
special attention was paid to the sections:  Aspects
Peculiar to Product Lines,  Application to Core
Asset Development, Application to Product
Development and  Practice risks which were
considered most relevant for the task. As mentioned
in section 1.3, we also incorporated our experiences
from using RUP in a software product line context.
As expected, the needs-analysis of domain- and
application engineering projects revealed several
criteria that could not be mapped to the original RUP
criteria. Some of these criteria could be added to
existing RUP milestones, while other criteria did not
fit within the original RUP life-cycle scope.
Therefore, we extended the original RUP life-cycle
model with an additional phase, the  Maintenance
Phase. As illustrated by Figure 7, the maintenance
phase ends with the End of Life (EoL) milestone.

Inception
Elaboration
Construction
Transition
Maintenance

Life-Cycle Objectives (LCO)
Life-Cycle Architecture (LCA)
Initial Operational Capability (IOC)
Product Release (PR)
End of Life (EoL)

Figure 7. The phases and milestones of the proposed
life-cycle model.

We chose to exclude an explicit retirement phase
as in for example the Enterprise Unified Process [2].
Since software is only a part of a typical product
within Hägglunds, a majority of system retirement
planning and analysis are performed by other parts of
the organization. It was therefore not considered
motivated to introduce an explicit retirement phase as
part of software engineering projects.



3.2. The Maintenance Phase

As in the support phase of ISO/IEC 15288 [9], the
goal of our maintenance phase is to provide continued
maintenance and support services throughout a
products life-time to ensure sustained operations.
The maintenance phase includes activities such as
those mentioned in section 2.2, but could also contain
planned upgrades throughout the life-cycle to enhance
product capabilities (so called mid-life improve-
ments). In such cases it is likely to be useful to start a
RUP evolution cycle as discussed in section 1.1.
The specific criteria for the EoL milestone depend
on the supplier responsibility for support and must be
tailored to each specific customer. The criteria could
range from  The product has reached the end of its
warranty period to  There are no more systems in
operation within the end-user organization.
However, there are also some general criteria for the
EoL milestone related to product line development
which will be discussed in section 3.3.5 and 3.4.5.

3.3. Domain Engineering (DE)

The following sections describe goals and
evaluation criteria tailored to the specific needs of
domain engineering projects.

3.3.1. DE  Inception Phase / LCO Milestone

As for a single system project, the major objective
of the inception phase is to determine scope and
boundaries for the software to be developed.
However, in a domain engineering project the
software to be developed is the core asset and the
scope includes all envisioned products in the product
line. To support the increased complexity of this goal
the LCO milestone is tailored as follows:
Achieving concurrence on scope and
cost/schedules for a product line is more complex
than for a single system, as more stakeholders are
involved and the scope concerns several products.
The RUP-LCO:1 criterion (scope/cost/schedule
concurrence) is therefore extended to ensure that the
scoping activity has valid input (DE-LCO:1-5), and
that the scope definition is stable (DE-LCO:6).
Since product line requirements span several pro-
ducts, they must capture anticipated variations over
the product lines anticipated lifetime. Therefore, a
more diverse set of stakeholders is involved in the
requirements review process. The RUP-LCO:2 crite-
rion (right requirements/common understanding) is
therefore extended to ensure that all relevant product
line stakeholders have a common understanding of
the terminology used (DE-LCO:7) and that the
requirements match the required variability (DE-
LCO:8).
Because the upfront investment is significant in a
product line effort, management commitment and
support are of vital importance. The RUP-LCO:3
criterion (estimate/priorities/risks/process agreement)
is therefore extended to emphasize such areas (DE-
LCO:9-13).
Standard risk management practices can be
tailored and applied in a product line context [7].
However, since several application engineering
projects depend on the same core assets they could
identify conflicting risk mitigation approaches. The
RUP-LCO:4 criterion (risk mitigation) is therefore
extended to ensure development of a strategy
managing such a situation (DE-LCO:14).

3.3.2. DE  Elaboration Phase / LCA Milestone

As in a single system project, the main goal of the
elaboration phase is to baseline the software archi-
tecture. However, in a domain engineering project the
developed software architecture must support an
entire product line using built-in variability
mechanisms. To support the increased complexity of
this goal, the LCA milestone is tailored as follows:
The RUP Vision document describes the why and
what for a project in terms of the key needs and
features of the project stakeholders. In the context of
a product line domain engineering project this would
translate to the Product Line Concept of Operations
(PL-CONOPS) document. The PL-CONOPS docu-
ments the decisions that form the operational concept
for a product line ([7], p 291-2). The RUP-LCA:1
criterion (vision/requirements stable) is therefore
refined (DE-LCA:1-2).
Because the product line architecture is of such
vital importance to the overall success of a product
line effort The RUP-LCA:2 criterion (stable
architecture) is refined. The details regard input to the
architecture effort (DE-LCA:3-5), architecture
definition (DE-LCA:6-7), architecture evaluation
(DE-LCA:8-11) and stability (DE-LCA:12).
No tailoring is needed to the RUP-LCA:3 criterion
(proven test & evaluation approaches). Test and
evaluation is equally important in product line
engineering
No tailoring is needed regarding the RUP-LCA:4
criterion (prototyping). The use of prototyping to
address technical risks is equally important in product
line engineering.
As discussed in section 2.1, domain engineering
projects must coordinate their efforts with application
engineering projects. The RUP-LCA:5 criterion (de-


tail/fidelity of construction plans) is therefore exten-
ded to provide such mechanisms (DE-LCA:13-14).
In a reuse driven organization it is important that
reuse is enforced and planned, rather than ad-hoc.
Management decisions weather core assets should be
reused, developed or purchased therefore form
important input to the construction-phase iteration
plans. The RUP-LCA:6 criterion (construction plans
supported by estimates) is therefore extended to en-
sure such analysis and enforcement (DE-LCA:15-16).
Following the discussion above regarding the RUP
Vision vs. the PL-CONOPS, the RUP-LCA:7
criterion (agreement that vision can be met) is refined
accordingly (DE-LCA:17).
No tailoring is needed regarding the RUP-LCA:8
criterion (acceptable resource expenditure).

3.3.3. DE  Construction Phase / IOC Milestone

The goal of the construction phase in a domain
engineering project is to develop the core asset soft-
ware components. These components must implement
envisioned variability, specified by the product line
requirements and product line architecture, and be
usable for application engineering teams to develop
products. To support this goal the criteria for the IOC
milestone are tailored as follows:
Since the user community of the core assets
consists of development teams in application
engineering projects, the requirements for release
maturity are somewhat different compared to a single-
system project. The RUP-IOC:1 criterion (release
maturity) is therefore extended to include high quality
production plans (DE-IOC:1), flexible enough
components (DE-IOC:2), well documented interfaces
(DE-IOC:3) and pre-integrated core asset components
(DE-IOC:4).
Readiness for transition to the end-user community
in the context of a domain engineering project relates
to the policies, practices and mechanism for
coordination between the domain engineering project
and its corresponding application engineering
projects. The RUP-IOC:2 criterion (transition
readiness) is therefore extended to provide such
mechanisms (DE-IOC:5-7).
No tailoring is needed regarding the RUP-IOC:3
criterion (acceptable resource expenditure).

3.3.4. DE  Transition Phase / PR Milestone

As in the original RUP the goal of the transition
phase is to ensure that the software is available to its
end-users. However, an additional goal in a domain
engineering project is to ensure that a suitable mainte-
nance organization is available for the core assets.
Depending on how a specific organization chooses to
manage maintenance of its core assets, a domain engi-
neering project could be responsible for maintenance
of several generations or the core assets. Such bran-
ching of the core assets maintenance trajectories is
not desirable, since a double-maintenance problem is
inflicted on the product line. Therefore the domain
engineering team should employ strategies to retire
old generations of the core assets as soon possible.
One such strategy could be to update legacy products
to the latest generation of the core assets as part of
other product maintenance tasks. To support these
additional goals the PR milestone is extended:
No tailoring is needed regarding the RUP-PR:1
criterion (user satisfied).
No tailoring is needed regarding the RUP-PR:2
criterion (acceptable resource expenditure).
Three additional criteria related to maintenance
readiness are added to the PR milestone (DE-PR:1-3)

3.3.5. DE  Maintenance Phase / EoL Milestone

Reaching the EoL milestone in a domain engi-
neering project means that a specific generation of
core assets can be retired. Before retiring a generation
of the core assets, the domain engineering team must
be sure that the assets are no longer needed in any
application engineering project. As mentioned above
a domain engineering team could be responsible for
several generations of the core assets. If this is the
case, all generations of the assets must achieve their
EoL before the product line as a whole achieves its
EoL. The EoL criteria (DE-EoL:1-3) ensure such
mechanisms

3.4. Application Engineering (AE)

To ensure that core assets have a certain level of
maturity before they are used to develop products it is
important that domain engineering projects are one,
preferably two, phase(s) ahead of their corresponding
application engineering projects for the initial phases.
This means that a domain engineering project should
have achieved its LCO milestone before any appli-
cation engineering project in its domain is initiated.
Otherwise, the scope definition of the product line
would still be unclear. It would therefore be
impossible decide whether or not a new product
would fall within the scope of the product line.
The following sections describe the tailoring of the
evaluation criteria for the RUP milestones to the
specific needs of an application engineering project.

3.4.1. AE  Inception Phase / LCO Milestone



The key objective of the inception phase in an
application engineering project is to determine if the
product is a viable member of the product line [8]. If
not, a decision must be made whether the product
should be abandoned, developed as a stand-alone
product or to redefine the scope of the product line to
include the requested product. To meet this objective
the LCO criteria are tailored as follows:
Achieving concurrence on the scope definition in
an application engineering project includes a manage-
ment decision to add the specific to the product line.
The RUP-LCO:1 criterion (scope/cost/schedule con-
currence) is therefore extended to enforce such a
management decision (see AE-LCO:1).
Since the product line approach provides strong
means of cost estimates for implementation of indivi-
dual requirements, it is possible to guide the evolution
of the product line by communicating the economical
consequences of including certain requirements in a
particular product to the system stakeholders. To
ensure that this possibility is utilized, the RUP-LCO:2
criterion (right requirements/common understanding)
is extended (see AE-LCO:2).
No tailoring is needed regarding the RUP-LCO:3
criterion (estimate/priorities/risks/process agreement).
As for domain engineering, standard risk manage-
ment practices can be applied in application engineer-
ing projects. However, it is important that procedures
are set in place to ensure that risks related to the
development of core assets are communicated to the
domain engineering team, so that common mitigation
strategies can be developed. The RUP-LCO:4
criterion (risk mitigation) is therefore extended to
ensure development of such procedures (see AE-
LCO:3).
Three criteria are added to the LCO milestone to
ensure that the application engineering team will
follow the selected product line approach (AE-
LCO:4) and that coordination with the domain
engineering will succeed (AE-LCO:5-6).
To ensure that the product line architecture is
mature enough before being instantiated for the
product during the elaboration phase a final criterion
is added to the LCO milestone (AE-LCO:7)

3.4.2. AE  Elaboration Phase / LCA Milestone

As in a traditional RUP project, the main goal of
the elaboration phase is to baseline the software
architecture. In an application engineering project the
software architecture is created by tailoring the
product line architecture to fulfill the specific product
requirements. The tailoring is done by exercising the
product line architectures built-in variation points. A
similar procedure is also performed for product
instantiation of included abstract product line
requirements. To support these activities the LCA
milestone is tailored as follows:
To ensure that the product aligns with the
envisioned scope of the product line, new product
specific requirements should be reviewed by domain
experts and other knowledgeable product line
stakeholders. The RUP-LCA:1 criterion (vision/
requirements stable) is therefore extended to ensure
concrete (AE-LCA:1), valid (AE-LCA:2-3) and stable
(AE-LCA:4) product requirements.
The RUP-LCA:2 criterion (stable architecture) is
refined to ensure proper evaluation (AE-LCA:5) and
stability (AE-LCA:6).
No tailoring is needed regarding the RUP-LCA:3
criterion (proven test & evaluation approaches).
No tailoring is needed regarding the RUP-LCA:4
criterion (prototyping).
As for domain engineering, coordination with
other development projects is important. The RUP-
LCA:5 criterion (detail/fidelity of construction plans)
is therefore extended to provide such mechanisms
(AE-LCA:7).
Planning and enforcing reuse is also important for
the development of product specific components as
part of application engineering projects. An important
input to the construction phase plans are decisions
whether the core assets should be reused, developed
or purchased. The RUP-LCA:6 criterion (construction
plans supported by estimates) is therefore extended to
ensure such analysis and enforcement (AE-LCA:8-9).
No tailoring is needed regarding the RUP-LCA:7
criterion (agreement that vision can be met).
No tailoring is needed regarding the RUP-LCA:8
criterion (acceptable resource expenditure).
To ensure that the core asset components are
mature enough before being instantiated for a product
during the construction phase, a final criterion (AE-
LCA:10) is added to the LCA milestone.

3.4.3. AE  Construction Phase / IOC Milestone

During the construction phase of an application
engineering project, core asset components are
configured and integrated with product specific
components. The result is a release of a customer
product as in a traditional RUP project. However,
also application engineering projects must be
managed with product line considerations. The IOC
milestone is therefore tailored as follows:
No tailoring is needed regarding the RUP-IOC:1
criterion (release maturity).


No tailoring is needed regarding the The RUP-
IOC:2 criterion (transition readiness).
No tailoring is needed regarding the RUP-IOC:3
criterion (acceptable resource expenditure).
To ensure that a possible promotion of product
specific components to core assets is smooth, two
final criteria are added (AE-IOC:1-2).

3.4.4. AE  Transition Phase / PR Milestone

In addition to the original purpose of the RUP
transition phase, application engineering projects
must also provide feedback to their corresponding
domain engineering projects (see Figure 4). The PR
milestone is therefore tailored as follows:
No tailoring is needed regarding the RUP-PR:1
criterion (user satisfied).
No tailoring is needed regarding the RUP-PR:2
criterion (acceptable resource expenditure).
Two additional criteria related to feedback to the
domain engineering team are added (AE-PR:1-2).

3.4.5. AE  Maintenance Phase / EoL Milestone

To achieve concurrence on the decision to retire a
specific product the AE-EoL:1 criterion is part of the
EoL milestone.
To ensure that the domain engineering team has
current information regarding the releases of the core
assets that must be supported, the AE-EoL:2 criterion
is part of the EoL milestone:

4. Summary and Conclusions

We have described how the RUP life-cycle model
can be tailored to the specific needs of domain- and
application engineering projects. As a basis for our
work we utilized SEIs framework for product line
practice.
The purpose of this work was to provide product
line organizations with a basis for phase reviews to
anchor their product line process. The proposed life-
cycle model will likely need additional tailoring to fit
a specific industrial context, for example depending
on the level of automation in the application engi-
neering process. If generative techniques are used to
automate large portions of the application engineering
process, some parts of application engineering phase
reviews might be handled less formally.
As a final note on phase reviews and milestones, it
is obviously sometimes necessary to move to the next
project phase without fulfilling each criterion, for
example to meet time-to-market requirements. How-
ever, such a decision should always be an informed
one, and not due to ignorance. Furthermore, it should
also be recognized that deviations from these
milestone criteria impose risks to the overall success
of the project and should be handled accordingly.
An empirical evaluation of the extended life-cycle
model is currently planned. The evaluation will
include data collection from both domain- and
application engineering projects.

5. References

1. Ambler S.: Enhancing the Unified Process  Softw are
Processes for the Post-2000 (P2K) World, Ronin White
Paper, Available at:
http://www.ronin-intl.com
(2000)
2. Ambler S.: Enterprise Unified Process (EUP),
Available at:
http://www.enterpriseunifiedprocess.com

3. Boehm B.: Anchoring the Software Process, IEEE
Software (July 1996) 73-82
4. Boehm B.: Managing Software Productivity and Reuse,
IEEE Computer (September 1999) 111-113
5. Boehm B., Port D. and Basili V.: Realizing the Benefits
of the CMMI with the CeBASE Method, Systems
Engineering, Vol.5 No. 1, 2002
6. Bosch J.: Design & Use of Software Architectures,
Addison-Wesley (2000)
7. Clements P. and Northrop L.: Software Product Lines,
Practices and Patterns, Addison-Wesley (2001)
8. Gooma H.: Designing Software Product Lines with
UML  From Use Cases to Pattern-Based Software
Architectures, Addison-Wesley (2004)
9. ISO/IEC 15288:2002(E)  Systems Engineering 
System life cycle processes
10. Jacobson I., Booch G., Rumbaugh J.: The Unified
Software Development Process, Addison-Wesley
(1999)
11. Kruchten P.: The Rational Unified Process: An
Introduction, Second Edition, Addison-Wesley (2000)
12. Royce W.: Managing the Development of Large
Software Systems: Concepts and Techniques,
Proceedings of IEEE Wescon (August 1970) 1-9
13. Rational Software Corporation, The Rational Unified
Process, version 2003.06.01.06, 2003
14. van der Linden F.: Software Product Families in
Europe: The Esaps & Café Projects, IEEE Software,
July/August, 2002, pp. 41-49.
15. Zhang W. Kunz T.: A Product Line Enhanced Unified
Process, Proceedings of Workshop on Software Process
Simulation and Modeling (SPW/ProSim2006), Co-
located with ICSE 2006, Lecture Notes in Computer
Science (LNCS), Vol. 3966, 2006, Springer, pp. 142-
149.


Table 2: Milestone Criteria Specific to Domain Engineering.
Inception DELCO
Elaboration
DELCA
Construction
DEIOC
Transition
DEPR
Maintenance
DEEoL
1. Has a credible market analysis been performed
to guide the product line scoping activity? ([7],
p. 286)
2. Have all relevant product line stakeholders
been identified (domain experts, market experts,
etc.)? ([7], p. 111)
3. Have all relevant stakeholders participated in
the scoping? ([7], p. 192)
4. Has a thorough search of existing products
been performed to identify commonality and
variability that is likely to occur across the
product line? ([7], p. 186)
5. Do we understand relevant domains (similar
systems) enough to make informed decisions
regarding product line scope, shared and unique
requirements, and architecture? ([7], p. 141)
6. Is the Scope definition document baselined
(specifies product line context, common parts
and bounds allowed variability)? ([7], p. 180)
7. Has a glossary explaining key terms and
concepts of the domain been developed? ([7], p.
143).
8. Have product line wide requirements been
documented using explicit variation points as
bounded by the Scope definition document? ([7],
p. 111)
9. Has the business case for developing a specific
product line gained management approval? ([7],
p. 222)
10. Is management committed to the product line
effort and does it provide the necessary support?
([7], p. 182,301)
11. Is the funding model stable and enduring so
that assets, practices and tools can be supported
and improved throughout their life-time? ([7], p.
255, 198)
1. Has the PL-CONOPS document been baselined?
2. Have the product line requirements been verified by
the right product line stakeholders and baselined? ([7],
p. 112)
3. Has a through technology forecasting been
performed? ([7], p. 329)
4. Have existing products in the organization been
mined to identify assets that can be made part of the
core assets? ([7], p. 107,187)
5. Have the selection criteria for COTS included
required variability, product and vendor stability and
legal arrangement for use in several products? ([7], p.
93-4, 98)
6. Have all allowed variation in the product line
architecture been identified? ([7], p. 64,77)
7. Have variability mechanisms been defined for all
identified variation points? ([7], p. 64)
8. Does the product line architecture provide necessary
support for testing (special test interfaces, self test
functions etc.)? ([7], p. 131)
9. Has the product line architecture been evaluated to
ensure that it is robust and general enough to serve as a
basis for all products in the product lines envisioned
scope? ([7], p. 77)
10. Does the architecture have the ability to provide all
required combinations of quality attributes? ([7], p. 77)
11. Have the right stakeholders (architects, developers,
customers, tool experts, domain experts, etc.) been
involved in the product line architecture evaluation?
([7], p. 81)
12. Is the product line architecture baselined?
13. If some core assets are developed as part of an
application engineering project, are they going to be
available on time? ([7], p. 199)
14. Have schedules of application engineering projects
1. Are there production
plan(s) of acceptable quality
which outlines the process of
turning core assets into
products by exercising built-
in component-level variability
mechanisms? ([7], p. 85, 177)
2. Are the components
installed in the core asset base
flexible enough to support the
variability defined by the
product line architecture and
the product line
requirements? ([7], p. 85)
3. Are the core asset
components integratable, that
is, are component interfaces
well defined and well
documented? ([7], p. 122)
4. Have as many as possible
of the core assets been pre-
integrated to make product
building as economic as
possible? ([7], p. 118)
5. Have change management
policies been set in place to
ensure systematic assessment
of product line change impact
of proposed changes to the
core assets? ([7], p. 112)
6. Have Configuration
Management (CM) practices
been set in place to keep track
of which release of the core
assets are used in which
product, and to ensure that
tasks such as making
appropriated core asset
1. Have core
asset
maintenance
plans
describing
how the
core asset
base will
grow and
evolve been
developed
and gained
management
acceptance?
([7], p.
195).
2. Have
strategies,
including
CM policies
and
processes,
been set in
place for
coordination
of
maintenance
and
evolution of
products
and core
assets? ([7],
p. 292)
3. Have
strategies
been
developed
on how to
1. Have all
products in
the product
line using the
specific
generation of
the core assets
reached their
EoL
milestone?
2. Are there
no more
envisioned
products in
the product
line that
would benefit
from using the
specific
generation of
the core
assets?
3. Have all
relevant
product line
stakeholders
agreed to
retire the
specific
generation of
the core
assets?


12. Have relevant stakeholders been involved in
developing plans? ([7], p.201)
13. Has a credible Product Line Concept of
Operations (PL-CONOPS) document, outlining
the selected product line approach and its
supporting organizational structures, been
developed? ([7], p. 290)
14. Has a strategy been developed to address
conflicting risk mitigation approaches in
different application engineering projects? ([7],
p. 308-9)
that depend on the core assets been taken into account?
15. Have make/buy/mine/commission analysis been
performed for the core assets (including non-software
assets)? ([7], p. 171,2-3,250)
16. If new components are developed, have a thorough
search for existing assets been performed? ([7], p. 86)
17. Do all product line stakeholders agree that the core
assets can be successfully developed and maintained as
outlined in Product Line Concept of Operations in the
context of the baselined product line architecture?
available to application
engineering teams are easy?
([7], p. 159)
7. Have mechanisms been set
in place to enable actions in
response to feedback from
application engineering
projects on the use of the core
assets (see Figure 4)?
minimize
the number
of branches
of the core
assets that
have to be
maintained?

Table 3: Milestone Criteria Specific to Application Engineering.
Inception AELCO
Elaboration
AELCA
Construction
AEIOC
Transition
AEPR
Maintenance
AEEoL
1. Has the business case for adding the requested product
to the product line gained management approval? ([7], p.
222)
2. Have feedback been provided to system stakeholders
on how the particular system may achieve economies by
having more common and less unique requirements ([7],
p. 112,237)
3. Have procedures been set in place to ensure that risks
related to core assets development are communicated to
the domain engineering team to ensure common
mitigation strategies?
4. Have product development teams undergone
necessary training to know how to follow the process for
using the core assets and reporting problems? ([7], p.
336)
5. Have specific procedures been set in place for
ensuring use of the product line architecture and core
assets in product development projects? ([7], p. 292)
6. Have specific procedures been set in place for
ensuring feedback on the use of core assets from product
development teams to the core asset team? ([7], p. 292)
7. Has the corresponding domain engineering project
achieved its LCA milestone?
1. Have all variation points in included abstract product
line requirements been exercised to create concrete
product requirements? ([7], p. 112)
2. Have new product specific requirements been verified
by the right reviewers? ([7], p. 112)
3. Have the complete set of product requirements been
verified by the right set of reviewers? ([7], p. 112)
4. Are the product requirements baselined?
5. Has the product architecture been evaluated to ensure
that it can fulfill all behavioral- and quality requirements
of the specific product? ([7], p.77)
6. Is the product architecture baselined?
7. Is the interaction between core asset development and
maintenance planes, and product development plans
acceptable? ([7], p. 198)
8. Have make/buy/mine/commission analysis been
performed for new product specific components? ([7], p.
170)
9. If new components are to be developed, has a thorough
search for existing assets been performed? ([7], p. 86)
10. Has the corresponding domain engineering project
achieved its IOC milestone?
1. Do product
specific
components
align with the
rules defined
by the product
line
architecture?
([7], p. 85-6)
2. Have new
product
specific
components
been
developed
with the
possibility to
become a core
asset in mind?
([7], p. 86).
1. Have feedback
been provided to
the domain
engineering team
on problems
experienced using
of the core assets?
([7], p. 292)
2. Have feedback
been provided to
the domain
engineering team
regarding adopted
and new project
specific
components
which could be
beneficial to
promote to core
assets? ([7], p. 86)
1. Have all
relevant
product
stakeholders
agreed to
retire the
system?
2. Has the
domain
engineering
team been
notified that
the system is
being retired?