Tailoring the RUP Life-Cycle Model to Software Product ... - CiteSeerX

Download PDF
1 downloads 0 Views 196KB Size Report
Comment
waterfall model [12] on portions of the system several consecutive times. These “miniature waterfalls” are referred to as iterations (see Figure 1). Incremental.
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 Process1 (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ägglunds2 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. Therefore 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

Initial development cycle

Generation 1

Time Inception Inception

Elaboration Elaboration

Evolution Evolution

Construction Construction

Next evolution cycle Time

Transition Transition

Evolution Evolution Generation 2

Figure 2. An example of a RUP Evolution cycle [13]. Table 1: An overview of the RUP milestone criteria [13]. Inception RUP–LCO 1. Stakeholder concurrence on scope definition and cost/schedule estimates3,4. 2. Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements3,4. 3. Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate3,4. 4. All risks have been identified and a mitigation strategy exists for each of them3,4.

Elaboration RUP–LCA 1. The product Vision and requirements are stable4. 2. The architecture is stable. 3. The key approaches to be used in test and evaluation are proven3,4. 4. Test and evaluation of executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved3,4. 5. The iteration plans for the construction phase are of sufficient detail and fidelity to allow the work to proceed3,4. 6. The iteration plans for the construction phase are supported by credible estimates3,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 architecture4. 8. Actual resource expenditure versus planned expenditure is acceptable3,4.

1.2. Related Work We found little guidance in literature on tailoring the RUP life-cycle model to product line development. 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 3 4

Construction RUP–IOC 1. Is this product release stable and mature enough to be deployed in the user community3,4? 2. Are all the stakeholders ready for the transition into the user community3,4?

Transition RUP–PR 1. Is the user satisfied3,4? 2. Are actual resource expenditures versus planned expenditures acceptable3,4?

3. Are actual resource expenditures versus planned still acceptable3,4?

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 operations, 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

Criterion applicable also in domain engineering projects (see section 3.3). Criterion applicable also in application engineering projects (see section 3.4)

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. Domain engineering unit

Domain Analysis

Domain Design

Domain Implementation

Reference Architecture

Reusable Components

Domain Technology

Domain Reference Requirements Engineering

Architecture Traceability

Traceability

Requirements

Components

Application Engineering

Components

Architecture

Feedback / Adaptations / Reverse Architecting Legacy Code, Domain Expertise

New Requirements

Application Requirements

Application Design

Application Coding

Reusable Core Assets

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

Product 2

Product n

Business unit

Business unit

Business unit

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.

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 retirement 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 CONCEPT

DEVELOPMENT

PRODUCTION UTILIZATION SUPPORT RETIREMENT

Purpose

Decision Gates

− Identify stakeholders’ needs − Explore concepts − Propose viable solutions − Refine system requirements − Create solution description − Build system − Verify and validate system − Produce systems − Inspect and test (verify) − Operate system to satisfy users’ needs − Provide sustained system capability − 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] Inception Phase

Elaboration Phase

Construction Phase

Concept Stage

Development Stage

Production Stage

Transition Phase

Utilization Stage Retirement Phase Support 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 lifecycle 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 framework 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 improvements). 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 products, 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 criterion (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 (DELCO: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 (DELCO: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 architecture. 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 documents 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 extended 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 ensure 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 software 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 singlesystem 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 maintenance organization is available for the core assets.

Depending on how a specific organization chooses to manage maintenance of its core assets, a domain engineering project could be responsible for maintenance of several generations or the core assets. Such branching 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 engineering 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 application 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 management decision to add the specific to the product line. The RUP-LCO:1 criterion (scope/cost/schedule concurrence) 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 individual 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 management practices can be applied in application engineering 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 AELCO:3). Three criteria are added to the LCO milestone to ensure that the application engineering team will follow the selected product line approach (AELCO: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 RUPLCA: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 (AELCA: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 RUPIOC: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).

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

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 lifecycle model will likely need additional tailoring to fit a specific industrial context, for example depending on the level of automation in the application engineering 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. However, such a decision should always be an informed one, and not due to ignorance. Furthermore, it should also be recognized that deviations from these

1. Ambler S.: Enhancing the Unified Process – Software 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), Colocated with ICSE 2006, Lecture Notes in Computer Science (LNCS), Vol. 3966, 2006, Springer, pp. 142149.

Table 2: Milestone Criteria Specific to Domain Engineering. Inception DE–LCO 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)

Elaboration DE–LCA 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

Construction DE–IOC 1. Are there production plan(s) of acceptable quality which outlines the process of turning core assets into products by exercising builtin 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 preintegrated 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

Transition DE–PR 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

Maintenance DE–EoL 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 1. Has the business case for adding the requested product to the product line gained management approval? ([7], p. 222)

Elaboration AE–LCA 1. Have all variation points in included abstract product line requirements been exercised to create concrete product requirements? ([7], p. 112)

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)

2. Have new product specific requirements been verified by the right reviewers? ([7], p. 112)

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. Are the product requirements baselined?

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?

3. Have the complete set of product requirements been verified by the right set of reviewers? ([7], p. 112) 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?

Construction AE–IOC 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).

Transition AE–PR 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)

Maintenance AE–EoL 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?