Product Line Adoption in a CMMI Environment

Lawrence G. Jones
Linda M. Northrop

CMU/SEI-2005-TN-028
July 2005

Product Line Practice Initiative

Unlimited distribution subject to the copyright.

[Abstract] [1 Introduction] [2 Background] [3 The Adoption Factory Pattern and CMMI-Based Process Improvement] [4 Details on CMMI Model Support for Software Product Line Practice] [5 Conclusion] [Appendix: Acronym List] [References] [PDF File]

1 Introduction

Software process improvement (SPI), based on the quality concepts pioneered by Crosby [Crosby 79], Deming [Deming 86], and others, has been a widely accepted practice for roughly the past decade. Articles on SPI appear regularly in technical and trade journals [McConnell 02], and impressive return on investment (ROI) figures are routinely reported [Ferguson 99, Goldenson 95, Zahran 97]. More recently, many organizations are finding that the practice of building sets of related systems together can yield remarkable quantitative improvements in productivity, time to market, product quality, and customer satisfaction. These organizations are adopting a product line approach for their software systems. Evidence of the increased benefits achieved when a product line approach is coupled with SPI has been particularly exciting [Vu 00].

Previous technical reports written by the Carnegie Mellon Software Engineering Institute (SEI) have provided the following information relating software process improvement and software product line initiatives:

Jones and Soule provide background on both the Capability Maturity Model (CMMI) models and A Framework for Software Product Line Practice, and a broad description of the support CMMI provides for product line practice [Jones & Soule 02].
Jones describes how typical process improvement infrastructure elements could be adapted to support software product line adoption [Jones 04].
Northrop provides a pattern-based approach to software product line adoption [Northrop 04].

Building on those reports, this technical note is intended to provide

linkage among these previous reports, emphasizing product line adoption in an organization that has adopted CMMI-based process improvement
additional information on CMMI support for product line practice, specifically relating selected CMMI process areas to certain practice areas in A Framework for Software Product Line Practice
a brief look at the relationships between these software technologies and hardware engineering

Following this brief introduction, Section 2 gives contextual information including some fundamental information about software product lines and the CMMI models. Section 3 describes the Adoption Factory pattern that provides a blueprint for product line adoption in terms of product line practice subpatterns and examines high-level CMMI support for that pattern. Section 4 provides more detailed information on how a process improvement effort based on CMMI models can be leveraged in product line adoption. Section 5 summarizes this report.

2 Background

2.1 Process Discipline and Software Product Line Practice

Software engineering process discipline has a significant relationship to product line practice. Product line practice is strategic in nature. A strategic effort requires more coordination, discipline, and commonality of approach than a more independent effort. Dependencies within an organization are greater, and predictability and quality become even more critical. Process discipline can provide the basis for a strategic effort and has proven that it can provide better predictability and quality. Thus, an organization with a culture of process discipline is much better poised for product line success, and there is a distinct overlap of activities between software process improvement efforts and software product line efforts.

Figure 1 summarizes the complementary nature of software engineering process discipline and software product line practice. It also illustrates a "multiplier" effect, namely that the two technologies can operate in concert to achieve business goals through a complementary focus on both process and product. This focus makes it natural to extend process discipline beyond just the engineering processes and explicitly brings in nontechnical processes and organizational aspects that are emphasized in A Framework for Software Product Line Practice but to a lesser extent in the CMMI models.

Figure 1: Process and Product Line Relationships

Figure 1: Process and Product Line Relationships

Moreover, many of the activities involved in software engineering process improvement have relevance in hardware engineering. For example, improved requirements management in software will definitely have a relationship to requirements management in the hardware associated with the software. Also, many of the software product line practices can be applied to hardware in the case where the systems being developed involve software embedded in hardware.

Figure 2 illustrates notionally the concept of the overlap among hardware engineering, software process improvement, and a software product line approach. The figure is not drawn to scale; that is to say, it depicts overlap but not degrees of overlap.

Figure 2: Overlapping Activities

Figure 2: Overlapping Activities

If a business is involved in all three activities, it is useful to understand as much as possible about what constitutes the overlap. Section 3 and Section 4 of this report are intended to shed light on that topic.

2.2 The Software Product Line Practice Framework

A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [Clements & Northrop 02]. The SEI has codified the essential product line activities and practices in A Framework for Software Product Line Practice (henceforth referred to as the Framework). Version 4.0 of the Framework is published in the book titled Software Product Lines: Practices and Patterns [Clements & Northrop 02]. Version 4.2 is located on the SEI’s Web site [Clements & Northrop 04].

The Framework describes the essential practice areas for software engineering, technical management, and organizational management, where these categories represent disciplines rather than job titles. A practice area is a body of work or a collection of activities that an organization must master to successfully carry out the essential work of a product line. The software engineering practice areas include those practices necessary to apply the appropriate technology to create and evolve both core assets and products as follows:

Architecture Definition
Architecture Evaluation
Component Development
COTS ¹ Utilization
Mining Existing Assets
Requirements Engineering
Software System Integration
Testing
Understanding Relevant Domains

The technical management practice areas include those management practices necessary to engineer the development and evolution of the core assets and products as follows:

Configuration Management
Data Collection, Metrics, and Tracking
Make/Buy/Mine/Commission Analysis
Process Definition
Scoping
Technical Planning
Technical Risk Management
Tool Support

Organizational management refers to the management of the business issues that are visible at the enterprise level, as opposed to those at the project level. Organizational management includes those practice areas necessary to position the enterprise to take fullest advantage of the product line capability. The organizational management practices include

Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Funding
Launching and Institutionalizing
Market Analysis
Operations
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Training

2.3 Product Line Practice Patterns

The SEI also defined a collection of product line practice patterns [Clements & Northrop 02]. Such patterns address recurring product line problems that arise in specific software product line situations and present solutions to them. The collection of 12 patterns and 11 variants characterize common product line contexts and problem/solution pairs that we have observed.

The product line practice patterns span various ranges of abstraction, scale, and purpose. The context for some of the patterns is universal--that is, they apply in all situations. The context for other patterns is particular to specific organizational conditions. Some of the patterns are related in that they solve a part of the overall software product line approach and that a pattern hierarchy makes sense. The Factory pattern is of particular interest in that it is a composite pattern that describes the entire product line organization. It provides a picture of what an organization would look like if it had product line capability. In Section 3 we will describe in detail an important variant of this pattern, the Adoption Factory pattern.

2.4 CMMI Models

A major organizing element for all CMMI models is the process area. A process area is a group of related activities that is performed collectively to achieve a set of goals. A process area specifies two things: (1) goals that describe the result of successful application and (2) practices that describe the required (and expected) activities to achieve those goals. Some goals and practices are specific to the process area; others are generic and apply across all process areas. These generics describe essential ways in which a process can be institutionalized. Institutionalization refers to a process’s degree of repeatability, standardization, and sophistication of control.

Structurally, each CMMI model comes in two representations: (1) a staged representation and (2) a continuous representation. These two representations are really just different views into the same content; they differ in how they organize both the process areas and the generics’ application to those areas. A staged representation focuses on the organization’s processes as a whole, provides a roadmap for process improvement with proven predefined groupings of process areas, and provides an easy migration path from the CMM for Software (SW-CMM). A continuous representation focuses on improving individual process areas chosen to align with specific organizational needs and provides an easy migration path from Electronic Industries Alliance Interim Standard (EIA/IS) 731 [Menezes 02].

Unique to the staged representation is the major organizing element of the maturity level--an indicator of the extent to which a set of processes is implemented and institutionalized. Maturity levels and their process area groupings for CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing (CMMI-SE/SW/IPPD/SS) are shown in Table 1.

Table 1: CMMI-SE/SW/IPPD/SS Staged Representation Process Areas

Level	Focus	Process Area
5 Optimizing	Continuous Process Improvement	Organizational Innovation and Deployment Causal Analysis and Resolution
4 Quantitatively Managed	Quantitative Management	Organizational Process Performance Quantitative Project Management
3 Defined	Process Standardization	Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis Resolution Organizational Environment for Integration
2 Managed	Basic Project Management	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management
1 Initial	N/A	N/A

The continuous representation uses the concept of capability level to measure process improvement within individual process areas. Capability levels represent the application of the generics to a single process area and indicate the process area’s degree of institutionalization. Apart from the application of generics to an individual process area, continuous representation models do not recommend a particular implementation order. Also, though they recognize relationships within general CMMI categories (see Table 2), the models generally treat process areas as independent. While, in theory, this treatment implies freedom of implementation order when using a continuous representation, key associations among the process areas preclude totally arbitrary ordering or implementations.

Table 2: CMMI Process Area Categories

Category	Process Areas
Process Management	Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment
Project Management	Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Quantitative Project Management
Engineering	Requirements Management Requirements Development Technical Solution Product Integration Verification Validation
Support	Configuration Management Process and Product Quality Assurance Measurement and Analysis Decision Analysis and Resolution Organizational Environment for Integration Causal Analysis and Resolution

Experienced implementers often take advantage of the strengths of both representations. For example, when relying on a staged ordering as a "first cut" prioritization, you might vary the basic implementation ordering based on business needs or "where it hurts most."

Finally, when we talk about CMMI-SE/SW/IPPD, V1.1 and CMMI-SE/SW/IPPD/SS, V1.1, we need to consider that the model implementation now extends beyond the engineering organization to more overtly include other corporate functions such as procurement, marketing, human resources, and support in the product or system development effort. As in the characterization of the Framework’s organizational implementation that’s described above, the addition of these domains requires a strategic understanding of the ways process improvement affects these functions within the organization. Therefore, most of the attributes that underpin a strategic effort such as product line management (coordination, discipline, commonality of approach, etc.) are supported by a robust set of cross-functional process best practices that help organizations better manage dependencies and provide for improvements in predictability and quality.

3 The Adoption Factory Pattern and CMMI-Based Process Improvement

3.1 The Adoption factory Pattern

The Adoption Factory pattern, shown in Figure 3, is a variant of the Factory pattern [Northrop 04].

Figure 3: Dynamic Structure of the Adoption Factory Pattern

Figure 3: Dynamic Structure of the Adoption Factory Pattern

The Adoption Factory pattern can be used as a generic product line adoption roadmap. It provides the necessary abstraction of the major activities involved and their dependencies. In addition, by decomposing the pattern’s subpatterns into their composite practice areas, a more detailed adoption plan and dependent action plans can readily be developed. Even though there are "informs" relations that move from left to right in the pattern’s dynamic structure, note that the relations in the product line practice patterns are never strictly linear. Owing to the highly iterative nature of product line adoption and operations, the arrows should always be interpreted as denoting a shift in active emphasis but by no means exclusion.

The SEI has found it especially useful to examine the Adoption Factory pattern from multiple views, all described by Northrop [Northrop 04]. One such view shows phases and focus areas simultaneously. Figure 4 provides this perspective with the appropriate horizontal focus area delineations and the vertical phase delineations.

Figure 4: Adoption Factory Pattern Annotated with Adoption Phases and Focus Areas

Figure 4: Adoption Factory Pattern Annotated with Adoption Phases and Focus Areas

The detail beneath the Adoption Factory pattern’s subpatterns (as articulated by the practice areas associated with each one) is necessary for detailed product line adoption planning. Figure 5 shows the pattern and its constituent practice areas elaborated in a view that also shows the focus areas and adoption phases.

Figure 5: Adoption Factory Pattern and Its Associated Practice Areas

Figure 5: Adoption Factory Pattern and Its Associated Practice Areas

Notice that some practice areas appear in multiple phases. However, the actual practices will vary depending on the phase and overall objective of the associated pattern. For example, the "Architecture Definition" practice area in the Establish Production Capability Phase is associated with the Product Parts pattern and therefore involves defining the product line architecture that will be the structure of all products. The "Application to Core Asset Development" section of the "Architecture Definition" practice area’s description in the Framework contains relevant guidance. However, the "Architecture Definition" practice area in the Operate Product Line Phase is associated with the Product Builder pattern and therefore involves instantiation of product architecture from the product line architecture. In this case, the "Application to Product Development" section of the "Architecture Definition" practice area’s description in the Framework contains relevant guidance.

3.2 Relating the Adoption Factory Pattern to Hardware Engineering

A product line approach to software was inspired by product line approaches in manufacturing. Though the Framework was written for software product line practice, it is, at least in its structure, entirely applicable to non-software product lines or to the hardware engineering of product line systems that are combinations of software and hardware. The essential practice areas are not different, but how they apply to hardware would of course be different from how they apply to software. In terms of the Adoption Factory pattern, the greatest areas of similarity would be in the Organization focus area. What would be accomplished by the Cold Start, Monitor, and In Motion patterns (and hence their associated practice areas) would be virtually the same. In the Process focus area, there is also overlap, but the actual implementation of many of the practice areas would be quite different. For example, the processes and tool support for configuration management of the software in a product line would, in principle, be similar to that for the hardware but would be different in the specifics. The greatest departure in practice area implementation would occur in the Establish Production Capability and the Operate Product Line Phases of the Product focus area. What is done in terms of defining an architecture and developing components would be similar, but of course how it is done for software and hardware would differ.

3.3 The Adoption Factory Pattern in a CMMI-Based Improvement Context

Jones and Soule provide a comparison of the Framework and the CMMI models [Jones & Soule 02]. Included in that comparison is a table (reproduced below in Table 3) that draws some high-level associations between practice areas and process areas. In Table 2, process names in bold provide "fairly direct support" for Framework practice areas, while others are less strongly related.

Table 3: Associations Between Software Product Line Practice Areas and CMMI Process Areas

Software Product Line Practice Areas	CMMI Process Areas
Software Engineering
Architecture Definition	Technical Solution
Architecture Evaluation	Verification
Component Development	Technical Solution
COTS Utilization	Supplier Agreement Management Technical Solution Integrated Supplier Management
Mining Existing Assets	N/A
Requirements Engineering	Requirements Development
Software System Integration	Product Integration
Testing	Verification Validation
Understanding Relevant Domains	N/A
Technical Management
Configuration Management	Requirements Management Configuration Management
Data Collection, Metrics, and Tracking	Measurement and Analysis Project Monitoring and Control Integrated Project Management for IPPD
Make/Buy/Mine/Commission Analysis	Decision Analysis and Resolution Technical Solution Supplier Agreement Management Integrated Supplier Management
Process Definition	Organizational Process Definition
Scoping	N/A
Technical Planning	Project Planning
Technical Risk Management	Risk Management
Tool Support	N/A
*Organizational Management*
Building a Business Case	N/A
Customer Interface Management	Integrated Project Management for IPPD Integrated Teaming
Developing an Acquisition Strategy	Supplier Agreement Management Integrated Supplier Management
Funding	N/A
Launching and Institutionalizing	N/A
Market Analysis	N/A
Operations	N/A
Organizational Planning	Project Planning
Organizational Risk Management	Risk Management
Structuring the Organization	Organizational Environment for Integration Integrated Teaming
Technology Forecasting	Organizational Innovation and Deployment
Training	Organizational Training

Figure 6 shows how the information in Figure 3 impacts the Adoption Factory pattern as shown in its practice area view. The practice areas that are supported by a CMMI-based improvement effort are shown in italics.

Figure 6: CMMI Support for the Adoption Factory Pattern

It is not surprising that the greatest leverage is in the Process focus area of the Adoption Factory pattern. The support given to the "Process Definition" practice area is explained below. A detailed description of the support provided for the rest of the italicized practice areas is given in Table 4 located in the next section of this report.

The "Process Definition" practice area is about an organization’s capability to define and document processes [Clements & Northrop 02]. An organization needs to have process discipline to succeed with a software product line approach because of the inherent plurality of the products and of the groups cooperating to develop those products. A software product line approach will work only if everyone does his or her job within agreed-upon parameters. Because product lines call for the repeated, ongoing, disciplined interaction of separate organizational entities, they rely heavily on the adherence to a process. Process definition represents an area of expertise that enables many other practice areas to be executed successfully. The Process pattern [Clements & Northrop 02, p. 386] includes all the other practice areas that involve defined processes and that consequently rely on the "Process Definition" practice area. The practice areas in the Process pattern are

Configuration Management
Data Collection, Metrics, and Tracking
Process Definition
Operations
Organizational Planning
Organizational Risk Management
Technical Planning
Technical Risk Management

In addition, the Each Asset pattern replicated for all the assets in the core asset base is part of the Process pattern because each asset in the core asset base should have an attached process that dictates how the asset will be used to produce a product in the product line. Process definition expertise is required to construct these attached processes. The relationships among the elements of the Process pattern are shown in Figure 7 below, which depicts the dynamic structure of the process pattern.

Figure 7: Dynamic Structure of the Process Pattern

4 Details on CMMI Model Support for Software Product Line Practice

4.1 Process Area Support for Selected Practice Areas

Practice areas and process areas are fundamentally different. Even when, at first glance, they appear to cover the same topic, similar names do not mean they cover the same ground. Practice areas also extend the realm of their coverage into the situation where product lines are the goal, which is not the focus of the process areas. Just because an organization has institutionalized the CMMI process area of Configuration Management, it does not mean that that organization has mastered the "Configuration Management" practice area for software product lines.

Institutionalization of any CMMI process provides at least some process discipline basis for product line practice. In CMMI terms, institutionalization involves the achievement of four goals through implementation of the generic practices (GPs). While not required, some GPs may be nicely supported by implementing certain CMMI process areas, in particular: Project Planning; Project Monitoring and Control; Configuration Management; and Organizational Training. In the CMMI model staged representation, the GPs are grouped into four common features:

Commitment to Perform groups the GPs related to creating policies and securing sponsorship.
Ability to Perform groups the GPs related to ensuring that the project/or organization has the resources it needs, including training.
Directing Implementation groups the GPs related to managing the performance of the process, managing the integrity of its work products, and involving relevant stakeholders.
Verifying Implementation groups the GPs related to higher level management’s review and objective evaluation of conformance to process descriptions, procedures, and standards.

In most cases, the Framework practice areas deal with practices that are essential for any successful software development. Thus, the Framework begins with the assumption that these basic development and management practices are fulfilled by the organization (or at least that detailed guidance is available elsewhere), and then it identifies practices that an organization must adopt to develop and manage a software product line successfully. In those cases where CMMI process areas align with the Framework, the CMMI defines processes in terms of what to do, and the Framework provides guidance in the form of how to actually do a related practice to support software product lines.

Organizations that plan to implement product lines should achieve CMMI capability level 2 (continuous representation) in at least the following process areas:

Requirements Management
Project Planning
Configuration Management
Requirements Development

These process areas will give the necessary capability to consider achievement of the Assembly Line pattern. Maturity level 2 and capability level 2 generally represent institutionalization at the project level. Because of the coordination required in a software product line approach across traditional project boundaries, it would be even more useful to standardize these process areas at the organizational level. Doing so implies achievement of capability level 3 for these process areas.

Figure 6 illustrated, using italics, all the Framework practice areas for which some CMMI process areas provided fairly direct support. Jones and Soule elaborate on what the phrase"fairly direct support" means for the "Configuration Management" practice area [Jones & Soule 02]. Table 4 provides a similar elaboration for the other italicized practice areas.

Table 4: How Framework Practice Areas Are Supported by CMMI Process Areas

Framework Practice Area

CMMI Process Area

CMMI PA Specific Goals (SGs) and Specific Practices (SPs)^a

Comments

Configuration Management (CMG)

Configuration Management (CM)

SG 1 Baselines of identified work products are established.

SP 1.1 Identify the configuration items, components, and related work products that will be placed under configuration management.

SP 1.2 Establish and maintain a configuration management and change management system for controlling work products.

SP 1.3 Create or release baselines for internal use and for delivery to the customer.

SG 2 Changes to the work products under configuration management are tracked and controlled.

SP 2.1 Track change requests for the configuration items.

SP 2.2 Control changes to the configuration items.

SG 3 Integrity of baselines is established and maintained.

SP 3.1 Establish and maintain records describing configuration items.

SP 3.2 Perform configuration audits to maintain integrity of the configuration baselines.

CM provides a good basis for CMG, but product line CMG is considerably more complex. CMG is covered in detail by Jones and Soule; a sample excerpt from their work is shown below.

CMMI practices establish the foundations of a configuration management process. The Framework covers the issues associated with the complexity of software product line development. Examples include

versions of configuration items compared to versions of each item, for each product
separate management of configuration items compared to a single, unified configuration management process
control of the configuration while core assets are being developed and used by multiple team members simultaneously
the robustness of the configuration management tool and its ability to support product line development [Jones & Soule 02]

The CM process area also can be an excellent basis for implementing the CMMI institutionalization GP 2.6, Manage Configurations ("Place designated work products of the [process area] process under appropriate levels of configuration management").

Configuration Management (CMG)

Requirements
Management (RM)

SG 1 Requirements are managed and inconsistencies with project plans and work products are identified.

SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements.

SP 1.2 Obtain commitment to the requirements from the project participants.

SP 1.3 Manage changes to the requirements as they evolve during the project.

SP 1.4 Maintain bidirectional traceability among the requirements and the project plans and work products.

SP 1.5 Identify inconsistencies between the project plans and work products and the requirements.

The CMMI Configuration Management process area provides better support for Framework CMG than the RM process area does, but many organizations chose to implement RM as one of the first processes in their software process improvement effort. In this case, RM practices provide rudimentary support for CMG.

A number of RM work products need to be baselined and controlled. The premier work product consists of the requirements themselves. Managing changes to the requirements is addressed by SP1.3. The CMMI models do not call out many details about how to carry out this management, but they do refer readers to the "Configuration Management" process area for more information about baselines and controlling changes to the configuration documentation for requirements. Thus, at least by inference, if an effective RM process is instituted, there is some basis on which the CMG practice area can build. The degree of support depends on the robustness of the RM baselining and change process.

Data Collection, Metrics, and Tracking (DCM)

Measurement and Analysis (MA)

SG 1 Measurement objectives and activities are aligned with identified information needs and objectives.

SP 1.1 Establish and maintain measurement objectives that are derived from identified information needs and objectives.

SP 1.2 Specify measures to address the measurement objectives.

SP 1.3 Specify how measurement data will be obtained and stored.

SP 1.4 Specify how measurement data will be analyzed and reported.

SG 2 Measurement results that address identified information needs and objectives are provided.

SP 2.1 Obtain specified measurement data.

SP 2.2 Analyze and interpret measurement data.

SP 2.3 Manage and store measurement data, measurement specifications, and analysis results.

SP 2.4 Report results of measurement and analysis activities to all relevant stakeholders.

DCM is about quantitative decision making. MA provides a basis for such decision making by establishing measurement processes to provide the data used. MA does not cover the full scope of DCM because it does not address the management tracking and corrective actions taken in response to the comparison of expected and actual results during project execution. These activities are the province of the Project Monitoring and Control process area and/or the Integrated Project Management process area.

The Framework notes that techniques for collecting and tracking data are the same for a product line as for a single system. However, it also notes that the data needs to provide information from three perspectives: (1) core asset development, (2) product development, and (3) management. These perspectives should be taken into account when establishing measurement objectives (SP1.1) and specifying the measures to address the objectives (SP1.2). Example measures are given in the Framework, including

core asset measures; for example, frequency of use and usefulness of core assets; quality of the core assets; effort expended to adapt core assets
product development measures; for example, conventional product measures (same as for single systems); product line measures (generally a subset of the core asset measures)

It should be noted that a choice of measures without careful establishment of the measurement goals is not appropriate.

The rest of an MA-based measurement process follows naturally to support a product line effort.

Data Collection, Metrics, and Tracking (DCM)

Project Monitoring and Control (PMC)

SG 1 Actual performance and progress of the project are monitored against the project plan.

SP 1.1 Monitor the actual values of the project planning parameters against the project plan.

SP 1.2 Monitor commitments against those identified in the project plan.

SP 1.3 Monitor risks against those identified in the project plan.

SP 1.4 Monitor the management of project data against the project plan.

SP 1.5 Monitor stakeholder involvement against the project plan.

SP 1.6 Periodically review the project's progress, performance, and issues.

SP 1.7 Review the accomplishments and results of the project at selected project milestones.

SG 2 Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.

SP 2.1 Collect and analyze the issues and determine the corrective actions necessary to address the issues.

SP 2.2 Take corrective action on identified issues.

SP 2.3 Manage corrective actions to closure.

As noted in the discussion of the Measurement and Analysis (MA) process area, DCM is about quantitative decision making. MA provides a basis for such decision making by establishing measurement processes to provide the data used. MA does not cover the full scope of DCM because it does not address the management tracking and corrective actions taken in response to the comparison of expected and actual results during project execution. These activities are the province of the PMC process area and/or the Integrated Project Management process area.

The practices in PMC provide an excellent basis for the active management aspects of DCM.

Data Collection, Metrics, and Tracking (DCM)

Integrated Project Management (IPM)

SG 1 The project is conducted using a defined process that is tailored from the organization's set of standard processes.

SP 1.1 Establish and maintain the project's defined process.

SP 1.2 Use the organizational process assets and measurement repository for estimating and planning the project's activities.

SP 1.3 Integrate the project plan and the other plans that affect the project to describe the project's defined process.

SP 1.4 Manage the project using the project plan, the other plans that affect the project, and the project's defined process.

SP 1.5 Contribute work products, measures, and documented experiences to the organizational process assets.

SG 2 Coordination and collaboration of the project with relevant stakeholders is conducted.

SP 2.1 Manage the involvement of the relevant stakeholders in the project.

SP 2.2 Participate with relevant stakeholders to identify, negotiate, and track critical dependencies.

SP 2.3 Resolve issues with relevant stakeholders.

SG 3 The project is conducted using the project's shared vision.

SP 3.1 Identify expectations, constraints, interfaces, and operational conditions applicable to the project's shared vision.

SP 3.2 Establish and maintain a shared vision for the project.

SG 4 The integrated teams needed to execute the project are identified, defined, structured, and tasked.

SP 4.1 Determine the integrated team structure that will best meet the project objectives and constraints.

SP 4.2 Develop a preliminary distribution of requirements, responsibilities, authorities, tasks, and interfaces to teams in the selected integrated team structure.

SP 4.3 Establish and maintain teams in the integrated team structure.

As noted in the discussion of the Measurement and Analysis (MA) process area, DCM is about quantitative decision making. MA provides a basis for such decision making by establishing measurement processes to provide the data used. MA does not cover the full scope of DCM because it does not address the management tracking and corrective actions taken in response to the comparison of expected and actual results during project execution. These activities are the province of the Project Monitoring and Control (PMC) process area and/or the IPM process area.

In the staged representation of CMMI models, IPM may be thought of as a maturity level 3 evolution of PMC. The practices in IPM provide an excellent basis for the active management aspects of DCM.

Make/Buy/Mine/
Commission Analysis (MBM)

Decision Analysis and Resolution (DAR)

SG 1 Decisions are based on an evaluation of alternatives using established criteria.

SP 1.1 Establish and maintain guidelines to determine which issues are subject to a formal evaluation process.

SP 1.2 Establish and maintain the criteria for evaluating alternatives, and the relative ranking of these criteria.

SP 1.3 Identify alternative solutions to address issues.

SP 1.4 Select the evaluation methods.

SP 1.5 Evaluate alternative solutions using the established criteria and methods.

SP 1.6 Select solutions from the alternatives based on the evaluation.

DAR provides a very solid basis to support MBM.

As the Framework notes, "techniques from the discipline of decision analysis apply well here," and DAR is such a technique.

SP1.1 would determine when MBM decisions would be subject to formal evaluation.

The Framework notes that quality and fitness of purpose are key, high-level decision criteria. The Framework provides other ideas about evaluative criteria to invoke in SP1.2. Examples include capabilities of the organization; amortization of a solution over a number of products; availability of suitable COTS components; alignment with the product line requirements and architecture; support for variation; and suitability of a component for inclusion in the core asset base.

With this basis, the execution of a DAR-based process should produce satisfactory results.

Technical Planning (TPL)

Project Planning (PP)

SG 1 Estimates of project planning parameters are established and maintained.

SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.

SP 1.2 Establish and maintain estimates of the attributes of the work products and tasks.

SP 1.3 Define the project life-cycle phases upon which to scope the planning effort.

SP 1.4 Estimate the project effort and cost for the work products and tasks based on estimation rationale.

SG 2 A project plan is established and maintained as the basis for managing the project.

SP 2.1 Establish and maintain the project's budget and schedule.

SP 2.2 Identify and analyze project risks.

SP 2.3 Plan for the management of project data.

SP 2.4 Plan for necessary resources to perform the project.

SP 2.5 Plan for knowledge and skills needed to perform the project.

SP 2.6 Plan the involvement of identified stakeholders.

SP 2.7 Establish and maintain the overall project plan content.

SG 3 Commitments to the project plan are established and maintained.

SP 3.1 Review all plans that affect the project to understand project commitments.

SP 3.2 Reconcile the project plan to reflect available and estimated resources.

SP 3.3 Obtain commitment from relevant stakeholders responsible for performing and supporting plan execution.

PP provides a good basis for TPL.

The Framework notes that it is useful to distinguish between the planning process and the results of that process, that is, the plans themselves. There should be nothing fundamentally different about the planning process for a product line. However, certain types of technical management plans are unique to product lines such as product production plans. Even typical project plans will have product-line-unique aspects such as core asset creation, test, and maintenance; and product tailoring and testing of tailored core assets. Furthermore, product line plans will have a richer set of dependencies than in single-system development.

All the SPs in the PP process area are relevant for product line planning, but several have special "twists" for product lines; for example

SP1.1 through 1.4: Estimates must take into account the software product line approach. DCM activities should provide a basis for these estimates. Also, SP1.3 should account for the software product line approach in the definition of life-cycle phases.
SP2.2 should account for product-line-unique risks such as product dependencies on the delivery of a core asset.
SP2.5 should account for product line training needs.
SP2.6, SP3.1, and SP3.3: The set of stakeholders typically will be broad in a software product line approach.

Technical Risk Management (TRM)

Risk Management (RM)

SG 1 Preparation for risk management is conducted.

SP 1.1 Determine risk sources and categories.

SP 1.2 Define the parameters used to analyze and categorize risks, and the parameters used to control the risk management effort.

SP 1.3 Establish and maintain the strategy to be used for risk management.

SG 2 Risks are identified and analyzed to determine their relative importance.

SP 2.1 Identify and document the risks.

SP 2.2 Evaluate and categorize each identified risk using the defined risk categories and parameters, and determine its relative priority.

SG 3 Risks are handled and mitigated, where appropriate, to reduce adverse impacts on achieving objectives.

SP 3.1 Develop a risk mitigation plan for the most important risks to the project, as defined by the risk management strategy.

SP 3.2 Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

RM provides a very good basis for TRM.

The product-line-unique aspects are

Risks may affect more than one product.
Some sources of risk may be unique to product lines.

The impacts of the product line approach on RM include

SP1.1: If the organization has its own taxonomy of risks or "starter set" of risks, this set should be adapted to include risks due to the software product line approach. Each practice area in the Framework has a section on risks that should be examined for relevance.
SP2.1: Risk identification and communication processes should be adapted to ensure that potential cross-project risks are identified and communicated outside the projects. This communication is an important input to the "Organizational Risk Management" practice area.
SP3.1 and SP3.2: These SPs should incorporate cross-project considerations.

Training (TRA)

Organizational Training (OT)

SG 1 A training capability that supports the organization's management and technical roles is established and maintained.

SP 1.1 Establish and maintain the strategic training needs of the organization.

SP 1.2 Determine which training needs are the responsibility of the organization and which will be left to the individual project or support group.

SP 1.3 Establish and maintain an organizational training tactical plan.

SP 1.4 Establish and maintain training capability to address organizational training needs.

SG 2 Training necessary for individuals to perform their roles effectively is provided.

SP 2.1 Deliver the training following the organizational training tactical plan.

SP 2.2 Establish and maintain records of the organizational training.

SP 2.3 Assess the effectiveness of the organization's training program.

OT, which provides a very solid basis to support TRA, merely involves applying the process to software product line needs.

Execution of a process step based on SP1.1 would lead to the understanding that strategic training needs must focus on the creation and utilization of core assets in accordance with the product line adoption plan. The Framework provides guidance about the types of training to consider and their phasing. Once these considerations are explored, understood, and incorporated, competent execution of a process based on OT should lead to satisfactory support for product line needs.

a	There is a terminology clash between the CMMI models and the Framework. In CMMI models, a specific practice is an activity that is considered important in achieving an associated specific goal. In the Framework, a specific practice is an example of a particular way that organizations have accomplished the work associated with a practice area.

4.2 Leveraging Process Improvement Infrastructure to Support Product Line Practice

For completeness we note that an established process improvement infrastructure typically includes at least the following elements:

oversight and implementation
process assets
a training infrastructure
other change management assets

Each of these elements may be augmented (or emulated) to support software product line practice. Jones gives further details on this point [Jones 04].

5 Conclusion

This technical note provides guidance on product line adoption in the context of an organization using CMMI-based process improvement. Additional information is provided if the organization also develops hardware product lines. The Adoption Factory pattern was reexamined, and specific support for product line practice areas through CMMI process areas was described. While there is certainly more room for exploration of connections and specific guidance that could be provided to business units in their product line efforts, this report should provide a significant start in that direction.

Software engineering process discipline as specified in the CMMI models provides an important foundation for software product line practice, and there can be a uniformity of the general approach in a hardware/software product line. It is always the case, however, that even with a solid process foundation, more work is required for ultimate success with software product lines. Success in software product lines requires mastery of many other essential practice areas. Also, even though the blueprint provided by the Adoption Factory pattern is applicable to a hardware product line, the implementation of the practice areas would differ.

Appendix: Acronym List

Acronym

Definition

COTS

commercial off-the-shelf

configuration management in the context of a CMMI process area

CMG

configuration management in the context of a Framework practice area

CMM

Capability Maturity Model

CMMI

Capability Maturity Model Integration

CMMI- SE/SW/ IPPD

CMM Integration for Systems Engineering, Software Engineering, and
Integrated Product and Process Development

CMMI-SE/SW/ IPPD/SS

CMM Integration for Systems Engineering, Software Engineering,
Integrated Product and Process Development, and Supplier Sourcing

DAR

decision analysis and resolution

DCM

data collection, metrics, and tracking

EIA/IS

Electronic IndustriesAlliance Interim Standard

IPM

integrated project management

IPPD

integrated product and process development

generic practice

measurement and analysis

MBM

make/buy/mine/commission analysis

MSG

management steering group

organizational training

PMC

project monitoring and control

project planning

risk management

systems engineering

SEI

Software Engineering Institute

specific goal

specific practice

supplier sourcing

software

SW-CMM

CMM for Software

TPL

technical planning

TRA

training

TRM

technical risk management

WBS

work breakdown structure

[Abstract] [1 Introduction] [2 Background] [3 The Adoption Factory Pattern and CMMI-Based Process Improvement] [4 Details on CMMI Model Support for Software Product Line Practice] [5 Conclusion] [Appendix: Acronym List] [References] [PDF File] References
[Clements & Northrop 04]	Clements, P. & Northrop, L. A Framework for Software Product Line Practice, Version 4.2. (September 2004).
[Clements & Northrop 02]	Clements, P. & Northrop, L. Software Product Lines: Practices and Patterns.Reading, MA : Addison-Wesley, 2002.
[Crosby 79]	Crosby, P. Quality is Free.New York, NY : McGraw-Hill, 1979.
[Deming 86]	Deming, W. Out of the Crisis. Cambridge, MA :MIT Center for Advanced Engineering, 1986.
[Ferguson 99]	Ferguson , P. et. al. Software Process Improvement Works! (CMU/SEI-99-TR-027, ADA371804). Pittsburgh, PA : Software Engineering Institute,Carnegie Mellon University , 1999.
[ Goldenson 95]	Goldenson, D. & Herbsleb, J. After the Appraisal: A Systematic Survey of Process Improvement, Its Benefits, and Factors that Influence Success (CMU/SEI-95-TR-009, ADA302225). Pittsburgh, PA : Software Engineering Institute,Carnegie Mellon University , 1995.
[Jones 04]	Jones, L. Software Process Improvement and Product Line Practice: Building on Your Process Improvement Infrastructure (CMU/SEI-2004-TN-044). Pittsburgh, PA : Software Engineering Institute,Carnegie Mellon University , 2004.
[Jones & Soule 02]	Jones, L. & Soule, A. Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice (CMU/SEI-2002-TN-012, ADA403868). Pittsburgh, PA : Software Engineering Institute,Carnegie Mellon University , 2002.
[McConnell 02]	McConnell, Steve. “The Business of Software Improvement.” IEEE Software 19, 4 (July/August 2002): 5-7.
[Menezes 02]	Menezes, W. “To CMMI or Not to CMMI: Issues to Think About.” Crosstalk 15, 2 (February 2002): 9-11.
[Northrop 04]	Northrop, Linda. Software Product Line Adoption Roadmap (CMU/SEI-2004-TR-022). Pittsburgh, PA : Software Engineering Institute,Carnegie Mellon University, 2004.
[Vu 00]	Vu, J. “Findings of the Managing Software Innovation and Technology Change Workshop.” Proceedings of SEPG 2000 (CD-ROM).Seattle, WA, March 20-23, 2000. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000.
[Zahran 97]	Zahran, S. Software Process Improvement: Practical Guidelines for Business Success.Reading, MA: Addison-Wesley, 1997.

1 COTS stands for commercial-off-the-shelf.

The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works.

External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent.

This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013.

For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

REPORT DOCUMENTATION PAGE

Form Approved
OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. agency use only

(Leave Blank)

2. report date

July 2005

3. report type and dates covered

Final

4. title and subtitle

Product Line Adoption in a CMMI Environment

5. funding numbers

F19628-00-C-0003

6. author(s)

Lawrence G. Jones & Linda M. Northrop

7. performing organization name(s) and address(es)

Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213

8. performing organization
report number

CMU/SEI-2005-TN-028

9. sponsoring/monitoring agency name(s) and address(es)

HQ ESC/XPK
5 Eglin Street
Hanscom AFB, MA 01731-2116

10. sponsoring/monitoring agency report number

11. supplementary notes

12a distribution/availability statement

Unclassified/Unlimited, DTIC, NTIS

12b distribution code

13. abstract (maximum 200 words)

Many organizations with an existing process improvement initiative are also considering software product line adoption. Managers and technical leaders in these organizations often ask how they can build on their process improvement work and reconcile these two significant change initiatives.

This technical note addresses product line adoption in the context of an organization that is using the Capability Maturity Model Integration (CMMI) models to guide its process improvement effort. Details are provided to show how selected CMMI process areas provide a basis for certain important software product line practices.

14. subject terms

product line adoption, process improvement, CMMI

15. number of pages

16. price code

17. security classification of report

Unclassified

18. security classification of this page

Unclassified

19. security classification of abstract

Unclassified

20. limitation of abstract

NSN 7540-01-280-5500

Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. Z39-18 298-102