Software Product Lines
Framework Home
Product Line Essential Activities
Core Asset Development
Product Development
All Three Together
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Core Asset Development

The goal of the core asset development activity is to establish a production capability for products. The following figure illustrates the core asset development activity along with its outputs and influential contextual factors.

Core Asset Development

This activity, like its counterparts, is iterative. The rotating arrows suggest that there is no one-way causal relationship from the context to outputs; the activity of producing core assets might change the context. For example, expanding the product line scope (one of the outputs) may admit whole new classes of systems to examine as possible sources of legacy assets (part of the context). Similarly, a production constraint (such as the need to rapidly assemble products) may lead to restrictions on the product line architecture (an output). This restriction, in turn, will determine which preexisting assets (another contextual factor) are candidates for reuse or mining.

Core asset development does not happen in a vacuum; rather, it happens within a situational context of existing constraints and resources. This context influences how core asset development is carried out and the nature of the outputs it produces. Four of the most important contextual factors are

  1. product constraints: What commonalities and variations exist among the products that will constitute the product line? What behavioral features do they provide? What features do the market and technology forecasts say will be beneficial in the future? What commercial, military, or company-specific standards apply to the products? What performance limits must they observe? With what external systems must they interface? What physical constraints must be observed? What quality requirements (such as availability and security) are imposed? The core assets must capitalize on the commonalities and accommodate envisioned variation with minimal tradeoff to product quality drivers such as security, reliability, usability, and so forth. These constraints may be derived from a set of preexisting products that will form the basis for the product line, they may be generated anew, or some combination of the two.

    The "Requirements Engineering," "Scoping," and "Understanding Relevant Domains" practice areas, which are described later, are concerned with gathering the relevant product constraints. These constraints affect the design of the core assets during, for example, architecture definition and component development.

  2. production constraints: Must a new product be brought to market in a year, a month, or a day? What production capability must be given to engineers in the field? What company-specific standards for software development processes must be followed in during product production? Who will be building the products and what environments will they use? Answering these and similar questions will drive decisions about, for example, whether to invest in a generator environment or rely on manual coding. These answers, in turn, will drive decisions about what kind of variation mechanisms to provide in the core assets and what production process will be used for products and eventually codified in the production plan.

    Architecture definition and component development reflect the production constraints in the variation mechanisms the designers choose. And make/buy/mine/commission analysis is carried out under the influence of those constraints. The "Process Discipline" and "Technical Planning" practice areas, which are described later, are concerned with how production constraints are addressed in the production plan.

  3. production strategy: The production strategy is the overall approach for realizing both the core assets and products. Will the product line be built proactively (starting with a set of core assets and spinning products off of them), reactively (starting with a set of products and generalizing their components to produce the product line core assets), or using some combination of the two (see "All Three Together")? What will the transfer pricing strategy be–that is, how will the cost of producing the generic components be divided among the cost centers for the products? Will generic components be produced internally or purchased on the open market? How will the production of core assets be managed? The production strategy dictates the genesis of the architecture and its associated components and the path for their growth. Informed by the product constraints and the production constraints, the production strategy also drives the process by which products will be developed from core assets. Will products be generated automatically from the core assets, or will they be assembled?

    The production strategy is most closely tied to the "Funding," "Launching and Institutionalizing," "Market Analysis," "Building a Business Case," "Process Discipline," "Technical Planning," "Scoping," "Architecture Definition," and "Make/Buy/Mine/Commission Analysis" practice areas.

  4. preexisting assets: Legacy systems and existing products embody an organization's domain expertise and/or define its market presence. The product line architecture, or at least pieces of it, may borrow heavily from proven designs of related legacy systems or existing products. Components may be mined from legacy systems. Such components may represent key intellectual property of the organization in relevant domains and therefore become prime candidates for components in the core asset base. What software and organizational assets are available at the outset of the product line effort? Are there libraries, frameworks, algorithms, tools, components, and services that can be used? Are there technical management processes, funding models, and training resources that can be adapted easily for the product line? Through careful analysis, an organization determines what is most appropriate to use. However, preexisting assets are not limited to assets that were built by the product line organization. Externally available software such as COTS, Web services, and open source products, as well as standards, patterns, and frameworks, are prime examples of preexisting assets that can be imported from outside the organization and used to good advantage.

    The "Make/Buy/Mine/Commission Analysis," "Mining Existing Assets," and "Using Externally Available Software" practice areas are most closely related to exploiting preexisting assets.

Three things, which are the outputs of the core asset development activity, are required for a production capability to develop products:

  1. product line scope
  2. core asset base
  3. production plan

These items are described below.

  1. product line scope: The product line scope is a description of the products that will constitute the product line or that the product line is capable of including. In its simplest form, the scope may consist of an enumerated list of product names. More typically, this description is cast in terms of the products' similarities and differences. These similarities and differences might include the features or operations they provide, the performance or other quality attributes they exhibit, the platforms on which they run, and so forth.

    For a product line to be successful, its scope must be defined carefully. If the scope is too large and product members vary too widely, the core assets will be strained beyond their ability to accommodate the variation, economies of production will be lost, and the product line will collapse into an old-style, one-at-a-time product development effort. If the scope is too small, the core assets might not be built in a generic enough fashion to accommodate future growth, and the product line will stagnate: economies of scope will never be realized, and the full potential return on investment (ROI) will never materialize.

    The scope of the product line must target the right products, as determined by knowledge of similar products or systems, the prevailing or predicted market factors, the nature of competing efforts, and the organization's business goals for embarking on a product line approach (such as market agility or merging a set of similar but currently independent product development projects).

    The scope of the product line evolves as market conditions change, as the organization's plans change, as new opportunities arise, or as the organization, quite simply, becomes more adept at software product lines. Evolving the scope is the starting point for evolving the product line to keep it current.

    The scope definition of a product line is itself a core asset, evolved and maintained over the product line's lifetime. Because it determines so much about the other core assets-in particular, what products they can support-we call it out separately. Scope is covered in more detail in the "Scoping" practice area.

  2. core asset base: The core asset base includes all the core assets, which are the basis for the production of products in the product line. Not every core asset will necessarily be used in every product in the product line. However, all of them will be used in enough of the products to make their coordinated development, maintenance, and evolution pay off.

    As we already described, these core assets almost certainly include an architecture that the products in the product line will share, as well as software components that are developed for systematic reuse across the product line. Any real-time performance models or other architecture evaluation results associated with the product line architecture are core assets. Software components may also bring with them test plans, test cases, and all manner of design documentation. Requirements specifications and domain models are core assets, as is the statement of the product line's scope. Web services and commercial off-the-shelf (COTS) software, if adopted, also constitute core assets. So do management artifacts such as schedules, budgets, and plans. Also, any production infrastructure such as domain-specific languages, tools, generators, and environments are core assets as well.

    Each core asset should have an associated attached process that specifies how it will be used in the development of actual products. For example, the attached process for the product line requirements would give the process for expressing the requirements for an individual product. This process might simply say: (1) use the product line requirements as the baseline requirements, (2) specify the variation requirement for any allowed variation point, (3) add any requirements outside the set of specified product line requirements, and (4) validate that the variations and extensions can be supported by the architecture. The process might also specify the automated tool support for accomplishing these steps. Product constraints, production constraints, and the production strategy (contextual factors described above) influence the definition of attached processes. Those processes all follow an overall implementation approach, called the production method. The attached processes get folded into what becomes the production plan for the product line. The following figure illustrates this concept of attached processes and how they are incorporated into the production plan.

    Attached Processes

    There are also core assets of a less technical nature, such as the training specific to the product line, the business case for using a product line approach for this particular set of products, the technical management process definitions associated with the product line, and the set of identified risks for building products in the product line.

    Finally, part of creating the core asset base is creating a concept of operations (CONOPS) that describes how the organization operates as a product line organization. The CONOPS defines (among other things) how that core asset base will be updated as the product line evolves, as more resources become available, as fielded products are maintained, and as technology changes or market shifts affect the product line scope.

  3. production plan: A production plan prescribes how the products are produced from the core assets and fills two roles:

    • It includes the process to be used for building products (the production process). As noted above, each core asset should have an attached process that defines how it will be used in product development. The set of these attached processes, together with the necessary process "glue" to join them together into a coherent whole, define the production process for products. The attached processes and the (usually nontrivial) glue are designed to satisfy the production strategy and production constraints and reflect the chosen production method. The production method, which is the overall implementation approach, specifies the models, processes, and tools to be used in the attached processes across core assets. For example, variation could be achieved by selecting from an assortment of components or services to provide a given feature, by adding or deleting components, by tailoring one or more components via inheritance or parameterization, or by using aspects. It could also be the case that products are generated automatically, or at least in part. All of these are examples of production methods. The exact vehicle to be used to provide the requisite variation among products (by exercising the variation made available in the core assets) is described in the production process. Selecting incompatible variation mechanisms can undermine the efficiency of the production process. The "Technology Forecasting" and "Tool Support" practice areas influence the determination of the production method.

    • It lays out the project details to enable execution and management of the process and therefore includes such details as the schedule, bill of materials, and metrics. In practice, these details can be in a separate document but, conceptually, are a part of the production plan.

The next figure refines the intuitive notion of the production plan illustrated in the previous figure. It identifies the combined set of attached processes as the production process, calls out the project details, and explicitly shows the influence of the contextual factors (product constraints, production strategy, and production constraints) and the production method on the production plan. The "Process Discipline" and "Technical Planning" practice areas provide more information about the production plan and how to create it. It should be obvious that the production plan is, itself, an important core asset.

Production Plan

As described in Product Development , these three outputs (the product line scope, core asset base, and production plan) are necessary ingredients for feeding the product development activity, which turns out products that serve a particular customer or market niche.

Next Section Table of Contents Previous Section