Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Frequently Asked Questions

  1. Concepts and Terminology
    • Isn't a product line just the group of products produced by a single business unit or profit/loss center?
    • If a product line is a set of products, does that mean I have to build them all?
    • What's the difference between a domain and a product line? For instance, I know there is a telecommunications domain, and I've heard of a telecommunications product line. What's the difference?
    • Isn't software product line practice the same as single-system development with reuse?
    • Vendors and other developers issue subsequent releases of single products all the time, and have been doing so for years. Each release is built in the same way-you would say from the same core asset base. Technically speaking, what's the difference between a software product line and multiple releases of the same product?
    • Isn't product line practice just another name for domain engineering?
    • Isn't product line practice just another name for component-based development?


  2. Are Product Lines Right for My Organization?
    • My organization is very small. Can we build a software product line?
    • My organization is very large. Can we build a software product line?
    • How can I make my organization build software product lines when people are busy in their own stovepipes? I don't have enough influence to change the way the organization does business.
    • The SEI Capability Maturity Model Integration® models (CMMI®) puts important aspects of product line practice at Level 4. Do I have to be at Level 4 before I can hope to field a software product line?
    • What are the various economic motivations for a software product line?
    • How long before the approach pays off?
    • We're doing okay. Why should I change the way I do business and undergo the upheaval that a product line will bring?
    • Can you really be competitive in the marketplace with a software product line? Doesn't it take away your flexibility if you're locked into a product line and, say, an architecture?


  3. Exploring the Issues More Deeply
    • Do successful software product line organizations have certain traits in common?
    • You have one practice area called 'Requirements Engineering' and another called 'Understanding Relevant Domains.' What's the difference between requirements analysis and domain analysis?
    • What is the relationship between process improvement and product line practice?
    • Must all products in the software product line share the same architecture? If my products have different architectures but make heavy use of other shared assets, isn't that a software product line?


  4. Using Software Product Lines with Other Approaches
    • Can I use open source software packages in my product line?
    • Does the software product line approach work in a globalization environment?
    • Can a product line approach be compatible with agile development methods?
    • Is a model-driven development (MDD) approach compatible with the software product line strategy?
    • Does a system-of-systems (SoS) context rule out the use of software product lines?
    • Is there any connection between service-oriented architectures (SOAs) and software product lines?
    • How are SOA and software product line approaches alike?
    • How are SOA and software product line approaches different?
    • Can SOA and software product lines be used together?
    • Can the framework provide guidance for a move to SOA?


  5. Product Lines in the Context of Acquisition
    • We're a U.S. government contractor, and our government customer wants to build a product line by buying core assets from us and then staging an open competition to build products using them. How can we possibly compete on the product-building side when all these new companies enter the fray and claim to be able to build products cheaper, because they didn't have to pay for the core assets?
    • We work for a government contractor that wants to bid on a competition to build products based on core assets developed by another contractor. How can we possibly compete given the intimate knowledge possessed by the asset development contractor?
    • I'm a government contractor, and the government wants me to supply reusable core components for other organizations to use in building a product line. Why should I open myself up to the legal liability? I'll be liable if they use my components incorrectly!
    • What acquisition strategies should a DoD or government organization consider when acquiring a product line? And what is their potential impact on the acquiring organization?


  6. Getting Started
    • All right, I want to start a software product line. What do I do first?
    • My company builds a broadly related group of products, each of which is a group of closely related products. Should I plan to build a single product line or a group of product lines?
    • I want to pilot software product lines in my organization. What are the criteria for a good pilot project?
    • Where is the resistance to adopting a product line approach usually found?
    • Where can I go to get more information?
    • Where can I read about other organizations that have successfully adopted the software product line approach?

Concepts and Terminology

Isn't a product line just the group of products produced by a single business unit or profit/loss center?

That is what some people mean when they use the term product line (see "A Note on Terminology"), but it's not what we mean. A product line is a set of products carefully chosen to take simultaneous advantage of commonality and market opportunities. These opportunities could span what is normally produced by a single business unit. For example, the software for commercial avionics and the software for military avionics could span separate business units in a company but be developed as a single product line by a software group that reports to both. Or, a single business unit may be responsible for developing and fielding more than one software product line. In general, a business unit is formed for organizational or financial reasons and may be responsible for (part of) one or more product lines.

If a product line is a set of products, does that mean I have to build them all?

No. While the term product line usually brings to mind a specific set of fielded products, you can think of a product line as defining a virtual set of products, each sharing a set of common, managed features. Only those products that satisfy some specific market need are actually built. The others represent untapped capability that you would be willing to build should the opportunity arise.

What's the difference between a domain and a product line? For instance, I know there is a telecommunications domain, and I've heard of a telecommunications product line. What's the difference?

A domain is a specialized body of knowledge, an area of expertise, or a collection of related functionality. A product line is the set of software-intensive systems sharing a common, managed set of features that satisfy particular market or mission needs. The telecommunications domain is a set of telecommunications problems, which in turn consists of other domains (switching systems, protocols, telephony, networks, etc.). A telecommunications product line is a specific set of systems that addresses some of those problems. Some people use the term domain to refer to a set of systems that employ knowledge in a particular domain, but really that's an incorrect use of the term. It's hard to imagine any nontrivial software system that doesn't encompass knowledge from several domains.

Isn't software product line practice the same as single-system development with reuse?

No. It differs in two fundamental ways. First, building a software product line is all about planning a plurality of products that will exist in the field and be maintained simultaneously, not just one that evolves over time. And second, the reuse that's involved is carefully planned, strategic, and applies across the entire set. In fact, one of the primary distinguishing characteristics of product line practice is preplanned reuse rather than ad hoc or one-time-only reuse. Software product line practice encourages choices and options that are optimized from the beginning for more than a single system.

Vendors and other developers issue subsequent releases of single products all the time, and have been doing so for years. Each release is built in the same way–you would say from the same core asset base. Technically speaking, what's the difference between a software product line and multiple releases of the same product?

There are some similarities, but the differences are acute enough to matter. The primary difference is that vendors who release subsequent versions try to retire earlier versions as soon as they can. Also, later versions are usually supersets of earlier versions. The latest version is always the one of interest. In a software product line, all versions are of interest, because they provide different functionality and quality attributes, each serving different market segments or missions.

Isn't product line practice just another name for domain engineering?

Domain engineering addresses only half of the problem–core asset development and acquisition. Product line practice addresses both domain engineering and product development using the core assets–or what has been called application engineering.

Isn't product line practice just another name for component-based development?

Software product lines certainly rely on a form of component-based development. The typical definition of component-based development involves the selection of components from a library or the marketplace to build products. Though the products in software product lines certainly are composed of components, these components are all specified by the product line architecture. Moreover, the components are assembled in a prescribed way; the prescription comes both from the architecture and the production plan. Software product lines involve the strategic use of components. Component-based development usually is missing such a strategic and systematic approach.

Are Product Lines Right for My Organization?

My organization is very small. Can we build a software product line?

Yes. There is no reason why even a one-person software boutique cannot benefit from product line practices. Small organizations are well served by "lightweight" versions of the practices. And some of the organizational and role changes that come with product lines may, in fact, be easier to carry out in a smaller organization. Case studies show that small companies (even start-ups) have understood that in order to field a number of different systems, their severe resource constraints compelled them to exploit all possible commonality among the systems. They used a product line approach to leverage their small staffs and budgets across a successful blend of products. For an example of such a case study, see [Clements 2002c, Ch. 11].

My organization is very large. Can we build a software product line?

Yes, and there are many examples of success. The larger the organization, the more important it is to gain control over the costs and procedures for doing business and to effectively manage products.

How can I make my organization build software product lines when people are busy in their own stovepipes? I don't have enough influence to change the way the organization does business.

Nobody said it would be easy. It is necessary to make the business case for product lines (see the "Building a Business Case" practice area) and to find a champion above the level of all the stovepipe organizations. One of the missions of the SEI's Product Line Practice Initiative is to provide the ammunition needed to make the business case to potential champions. If case studies are documented and practices are defined within the context of a well-defined framework, convincing the decision makers should be easier. Also, many adoption strategies are possible. For example, you could find a part of the organization where people are open to cross-unit cooperation and begin building a small product line there. Incrementally grow the scope of the product line, and make sure you collect data to record the economies that you gain. The "Launching and Institutionalizing" practice area is especially relevant here.

The SEI Capability Maturity Model Integration® models (CMMI®) puts important aspects of product line practice at Level 4. Do I have to be at Level 4 before I can hope to field a software product line?

No, but certain Level-2 and -3 practices are key. For example, an organization must have well-developed configuration management and product planning skills before it can have much hope of fielding a product line. Moreover, successful product line practice requires process discipline. That's why "Process Discipline" is one of the practice areas. Organizations that are at Level 4 can transition to product line practices with fewer risks, but the risks can be managed at lower maturity levels as long as they are identified and mitigated.

What are the various economic motivations for a software product line?

Many organizations that have started software product lines in recent years have done so out of economic necessity. They have found that they simply could not continue to do business as they had in the past and still be competitive. Chief among the economic benefits are reduced time to market, greater market agility, opportunities for mass customization, and lower unit costs. These factors are driven by greater productivity from scarce or costly worker resources. Many organizations are finding that they simply cannot find enough qualified people to expand their business without embracing product line practices or afford to hire them even if they were available. In the realm of acquisition, the government may commission a product line to eliminate wasteful duplication among programs or to enable it to assemble more cost-effective systems by more easily obtaining products from a range of vendors. See the "Building a Business Case" practice area for more information.

How long before the approach pays off?

That's a hard question to answer, because it depends on too many organization-specific conditions. If you have decided to build products for which there is no market, no matter how efficiently you build them, you will not make money. However, a slightly different form of the question can be asked: How many products are required before building them as a product line is more cost-effective than building them as separate systems? The answer to that question lies somewhere in the neighborhood of two or three systems. That is, if your product set is expected to be populated by three or more systems, you're almost certainly better off to build them as a software product line than as separate systems. (See "It Takes Two," [Clements 2002c, p. 226].)

We're doing okay. Why should I change the way I do business and undergo the upheaval that a product line will bring?

First of all, it's not a foregone conclusion that product line practice brings upheaval. Some adoption strategies prescribe starting small and growing incrementally. New technologies are emerging that are allowing companies to quickly extract and manage commonality among systems they've already fielded; these systems can form the foundation for a product line that can be grown over time. But no organization should begin to build a product line without understanding the costs and benefits. Even if you're doing fine now, circumstances that motivate an organization are often based on long-term vision and not the status quo. You should also ask yourself whether your competition is standing still. The choice to adopt product line practices should be a strategy for achieving specific business goals. That's why it's important to build a business case before you decide to launch a product line.

Can you really be competitive in the marketplace with a software product line? Doesn't it take away your flexibility if you're locked into a product line and, say, an architecture?

Competitiveness should be sharply increased, because you're gaining the ability to respond quickly to opportunities that fall within the product line's scope–a response time sometimes measured in days instead of years. Also gained is increased ability to respond to user needs. What is lost is unbounded variability. The key is to understand which variations are needed and which variation mechanisms can best support them. Early steps are understanding the relevant domains, building a business case for a set of products, and product line scoping. If domain analysis has captured the requirements of the application domain, the product line has been scoped commensurately, and the architecture and other core assets reflect those needs through preplanned variation mechanisms, new products can be brought to market far faster than before with minimal loss of flexibility as compared to one-of-a-kind systems. However, a product line organization needs to beware of complacency and should always keep an eye on the horizon for new technologies, new user needs, and new opportunities that might compel a shift in the product line's scope to keep it vigorous into the future. Finally, you're never "locked" into a product line, as the question implies. If a business case so warrants, you can always build a product outside the product line. For example, if an opportunity to enter a new market comes up, that first product can be used to test the waters and could even become the basis for a new product line.

Exploring the Issues More Deeply

Do successful software product line organizations have certain traits in common?

They do indeed. The best ones are comfortable with process discipline, have a strong and tireless champion for the approach in a position of leadership while the effort is being launched, and have long and broad experience in the application areas covered by the product line. Less tangibly but just as observable is one other aspect, something we've nicknamed the "e pluribus unum effect." E pluribus unum is Latin, of course, for "out of many, one." All the most successful product line organizations we've observed regard their primary mission as building and maintaining the product line (singular) or (equivalently) a production capability. Organizations still climbing the product line hill tend to describe themselves as turning out products (plural). The difference in mindset is subtle but powerful. Companies with the singular outlook realize that they have built a product capability that transcends any one product or even any several products. To them, turning out products is the easy part.

You have one practice area called 'Requirements Engineering' and another called 'Understanding Relevant Domains.' What's the difference between requirements analysis and domain analysis?

Remember that a domain is a specialized body of knowledge or area of expertise. Hence, domain analysis explores and captures the knowledge areas key to a product line and therefore tends to be broader in scope than requirements analysis. Requirements analysis usually focuses on specific applications. For example, domain analysis for a product line might identify areas of general commonality and variation across a body of relevant functionality (perhaps by examining and comparing legacy systems that have that functionality). Requirements analysis would identify a specific set of commonalities and variations for the family of products to be built.

What is the relationship between process improvement and product line practice?

Process improvement is broader in scope. Product line practice focuses on how to use a common set of core assets to modify, assemble, instantiate, or generate multiple products referred to as a product line. The focus is on improvement in product management. Process improvement addresses software engineering in general. While there is overlap between process improvement and product line practice in key practice areas, product line practices provide guidance for one particular approach to software development. However, experience shows that an organization with poorly defined software processes, or lacking the discipline to follow the processes it has defined, will not fare well in the transition to product line practice. Hence, at the very least, product line practice and process improvement need to be engaged hand in hand. As organizations improve their processes, they often enjoy increased productivity. Organizations with greater process maturity can continue to make productivity increases by turning their focus to product line practices.

Must all products in the software product line share the same architecture? If my products have different architectures but make heavy use of other shared assets, isn't that a software product line?

Only if that reuse is carried out in a "prescribed way," as required by the definition of a software product line. In all the software product lines we have studied, that prescription is most effectively carried out by using a common architecture where individual products either share the same architecture or permitted variations of the same architecture–an architecture we call the product line architecture. Variations might, for example, involve replacing one component with a similar one, instantiating a multiple component a different number of times, or exhibiting some subset of the overall architecture.

Using Software Product Lines with Other Approaches

Can I use open source software packages in my product line?

You can if all of the following conditions exist:

Also be aware that some open source licenses are crafted in such a way that would require you to make your products, when based on open source packages, also open source. Read the license agreements very carefully!

Does the software product line approach work in a globalization environment?

Globalization has two meanings. The first, also called internationalization or localization, refers to making a software product or software-intensive system work correctly around the world. You can easily see that the software product line approach applies straightforwardly in this case. Different locale requirements correspond directly to product line variation points, and, in fact, a scoping exercise and a product line perspective on requirements can greatly help in identifying those variations. Identifying variations can result in each member of the family being as lean as possible and perhaps letting developers concentrate more on global features as well as locale-specific features.

The second meaning of globalization involves separate development groups located around the world cooperating productively and correctly to build software. In this context, the question above asks whether product lines can be developed globally. They can. It is necessary to lay some groundwork before effective distributed development can occur, and product lines are not immune from this need. For example, it is very useful to first establish such things as a common development environment, a common configuration management system, and a minimum set of common processes (or at least crisp process interface points), so the exchange of information and artifacts can flow smoothly across site boundaries. Just as in global development for single systems, architecture plays a central role. It crisply defines the work assignments and responsibility boundaries, in the system but also among the development parties. In a product line situation, the responsibilities will include the design and development of variation mechanisms for core assets.

Can a product line approach be compatible with agile development methods?

The short answer is yes, as demonstrated by the successful use of eXtreme Programming (XP) in Salion's product line effort [Clements 2002d]. However, the larger point is that the applicability of agile methods is more strongly determined by whether a project's characteristics align with a method's "home ground." (See the example practices under the "Process Discipline" practice area.)

Boehm and Turner advocate a pragmatic, risk-driven approach to choosing appropriate aspects from both plan-driven and agile methods [Boehm 2004b]. For projects whose characteristics stray from agility's home ground, it may still be possible to partition off portions where agile methods can flourish.

One challenge to agile methods' applicability is the principle of simple design, de-emphasizing the importance of software architecture. Within XP, this concept is known as "You Aren't Going to Need It" (YAGNI). As Boehm says, YAGNI works fine when future requirements are largely unpredictable but can be highly inefficient where there is a reasonable understanding of future needs. Because a product line approach inherently means you set out to understand future needs, and indeed base your business strategy on that understanding, you are going to need a sufficiently defined product line architecture. However, once it's developed, the software architecture contributes very well to a team's tacit knowledge and can serve as a basis for other agile practices (e.g., for development activities within a partitioned area of the architecture).

Is a model-driven development (MDD) approach compatible with the software product line strategy?

Yes. The software product line strategy is compatible with a variety of technical approaches loosely grouped under the "model-driven" category including MDD, model-driven architecture, and model-driven engineering. The software engineering practice areas in the framework include the activities of a traditional development process but do not constrain how those activities are implemented. The model-driven techniques emphasize the disciplined use of a variety of models, whose currency is maintained throughout the product life cycle. A model-driven approach to software products lines would emphasize automatic product derivation [McGregor 2005b]. Models would be constructed that are capable of expressing the commonality and variations inherent in the product line's scope. A new product's requirements would be translated into product-specific configurations of the product independent models that are maintained as core assets. Tool-supported translation, laid out in a production plan, would be used to derive products. In fact, model-driven development could be thought of as a production strategy, as described in "Core Asset Development" of the framework.

Does a system-of-systems (SoS) context rule out the use of software product lines?

No. On the contrary, software product lines can help reduce the complexity of an SoS context. An SoS comprises independent, self-contained systems that, when taken as a whole, satisfy a specified need. Many software-intensive contexts today are SoSs. The complexity involved can be daunting. However, in many cases, there is considerable commonality among some of the self-contained systems. Suppose, for example, that the SoS involves 200 separate systems that must all interoperate. But suppose further (as is often the case) that there are some clusters within those 200 that have considerable commonality and whose variations could be handled economically. By making those clusters into software product lines, you can tame the interoperability issue into a smaller, more manageable set of interfaces and thereby reduce the complexity of the SoS. Moreover, the economic advantages and predictability associated with software product lines will be highly beneficial to the SoS in question.

Is there any connection between service-oriented architectures (SOAs) and software product lines?

SOAs and software product line approaches to software development share a common goal. They both encourage an organization to reuse existing assets and capabilities rather than repeatedly redeveloping them for new systems to achieve desired benefits such as productivity gains, decreased development costs, improved time to market, higher reliability, and competitive advantage.

How are SOA and software product line approaches alike?

Both approaches promote reuse by developing applications/products based on a set of reusable components. Those components are developed with well-defined interfaces and processes that specify how the components are to be used, which enables applications/products to be produced in less time.

Adopting either approach requires implementing similar organizational policies and practices necessary to adopt a new technology or a new way of doing business. SOA and software product lines share many of the same organizational issues such as planning, funding, tool support, training, and the need to change the organizational mindset towards reuse. When starting to use either approach, it is imperative for both SOA and software product line efforts to have organizational commitment and a champion.

Both approaches focus on identifying the application building blocks or reusable components associated with the application(s). In SOA, services represent the reusable building blocks. Core assets are the basis for production of products in a software product line. Separate teams may be employed to develop the reusable components and the applications. Small or pilot studies help develop skills to evolve the organization towards an SOA or software product line capability.

In both cases, the initial building blocks may come from legacy systems. Identifying and retrieving product line assets or services from existing systems in order to obtain the benefits of reuse are equally difficult. Documentation and tool support aid this effort.

Application/product development for both approaches is orchestrated in a similar manner. Inputs include the requirements for a particular application/product, reusable components, and the details of how these components are to be used to build the application/product.

How are SOA and software product line approaches different?

While the goals and the use of reusable components in the SOA and software product line approaches are very similar, the process by which the two compose systems are very different.

A software product line is, fundamentally, a set of related products. Each product is formed by taking applicable components from the base of common assets, tailoring them as necessary through preplanned variation mechanisms such as parameterization or inheritance, adding any new components that may be necessary, and assembling the collection according to the rules of a common, product-line-wide architecture under the auspices of a production plan. New or updated core assets are rolled back into the core asset base for future systems.

In SOA, it is not necessary for the reusable component(s) to come from a centralized, organization-controlled service base. Multiple organizations may provide the services leading to the possibility that services may change or disappear without notification. While multiple organizations can have responsibility for the core asset base in the software product line paradigm, that is not the usual case.

SOA addresses the issue of variation through orchestration (coordinating the participating services), service versioning, or extensible XML data types (a process of evolving from one format to another without requiring central control of the format).

The product line architecture is a software architecture that satisfies the needs of the products within the product line's scope. It is a key core asset. SOA is not the software architecture of the system; it is a design philosophy and an approach to software development where

The product line architecture establishes the quality goals for a system–its performance, reliability, modifiability, and so forth. Since SOA implementations may span enterprise boundaries, the quality attributes are dependent on the Quality of Service (QoS) of each of the included services. Desired end-to-end qualities may be achieved in specifically engineered applications. However, if the services are used in a different context, they may not meet the expected QoS. Service developers need to understand the functional and QoS requirements of potential service users.

In a software product line, an established process for updates to the core asset base is followed as the product line evolves, as more resources become available, as fielded products are maintained, and as technological changes or market shifts affect the product line's scope. Unlike SOA, the core assets in a software product line approach include non-software assets as well as software components. Product line requirements, domain models, test cases, and so on provide significant strategic advantage. Also included in the core asset base is a production plan prescribing how the products are produced from the core assets. SOA employs an SOA governance to facilitate planned reuse of services. SOA governance means the creation, deployment, enforcement, and verification of policies throughout the entire life cycle of SOA artifacts. SOA governance platforms may provide easy service discovery through a centralized service registry and management tools for planned reuse (on the service level), such as tracking subscribers to services, negotiating service level agreements (SLAs), communicating change requests and actual changes in service interfaces and data types.

Can SOA and software product lines be used together?

It is possible to build a stand-alone (i.e., non-product-line) application using SOA and to build a software product line without using SOA. In that sense, the two approaches are independent. However, it is also possible to combine the two approaches. In particular, it is possible and feasible for an organization to use services as a reusable core asset with which to build products in a software product line. That is a focus of the "Using Externally Available Software" practice area. Also, service providers and SOA application developers could take a product line approach to the development of services.

Can the framework provide guidance for a move to SOA?

Organizations moving to an SOA approach can benefit from software product line information captured in other practice areas as well. The practice areas related to organizational management could help organizations understand important issues in adopting a new reuse-based technology. And those related to technical management and software engineering could help organizations analyze legacy systems, determine make/buy/mine/commission decisions, use existing available software, and understand risk. Documents similar to the product line adoption plan (describing the desired state of the organization and a strategy for achieving that state) and the product line production plan (which prescribes how the products are produced from the reusable components) provide excellent templates for organizations moving to planned, reuse-oriented environments.

Planned and systematic reuse, exploiting economies of scope, and other important software product line issues could feed into the SOA design philosophy to help manage the growth of services and application developments, understand the dependencies between services, and determine the impact of service changes to the applications. The software product line approach would help control complexities created by the combinatorics of services and applications that occur over the entire life cycle of a system.

Product Lines in the Context of Acquisition

We're a U.S. government contractor, and our government customer wants to build a product line by buying core assets from us and then staging an open competition to build products using them. How can we possibly compete on the product-building side when all these new companies enter the fray and claim to be able to build products cheaper, because they didn't have to pay for the core assets?

First, other contractors can't necessarily build derivative products any cheaper. At best, they can probably build them as cheaply, but even that is questionable. In practice, the core asset contractor actually may have an inside track on follow-on product development by virtue of its domain knowledge, expertise, and intimate knowledge of the core assets. Other contractors may have a significant, and potentially steep, learning curve with regard to understanding the functionality and technical characteristics of the core assets, how to appropriately augment them with product-specific assets, and how to integrate and test them to create a finished product. In fact, it is usually those other contractors that are concerned about the unfair advantage the asset contractor has, because, under acquisition reform, contractor experience often plays a large part in the technical evaluation criteria. In fact, in some cases, the core asset contractor is excluded from bidding on follow-on product developments to avoid claims of having an unfair advantage.

What all this boils down to is the need to create a business strategy that effectively balances the interests of the core asset contractor and the acquisition organization (and other prospective product development contractors). The core asset contractor obviously has a vested interest in protecting the competitive edge it has in the marketplace. The core assets it owns are an instantiation of its domain knowledge and software expertise and may be a major factor in maintaining its competitive advantage. Accordingly, there are several options the core asset contractor, in conjunction with the acquisition organization, may want to pursue. They include

While there is no one answer to the question that is posed, the above list (which is non-exhaustive) demonstrates that there are many viable contracting options that can be pursued depending on the goals and acquisition strategy of the government agency and the business strategy of the core asset contractor.

Finally, if the core assets make it so straightforward to produce products based on them, the core asset contractor is in a perfect position to rapidly bring entirely new products to the commercial marketplace, thus taking advantage of the new production capability created courtesy of the government.

We work for a government contractor that wants to bid on a competition to build products based on core assets developed by another contractor. How can we possibly compete given the intimate knowledge possessed by the asset development contractor?

Combined with the previous question, this question shows that the grass is always greener on the other side of the fence. The fact that both of these questions are frequently asked suggests that product lines do not particularly tilt the playing field in either direction. In fact, this question is no different than if you had asked "How can I hope to compete, because I didn't build the commercial off-the-shelf (COTS) software or the government-furnished equipment (GFE) that I'm required to use under this contract?" Contractors compete successfully under those conditions all the time. So the premise behind the question–that a contractor can only compete successfully if it is tasked with building all the software–is just not valid. A pragmatic answer is that your company is no worse off than if the product line strategy had not been pursued.

I'm a government contractor, and the government wants me to supply reusable core components for other organizations to use in building a product line. Why should I open myself up to the legal liability? I'll be liable if they use my components incorrectly!

Liability issues can be tricky. They are negotiated between the acquisition organization and the development contractor(s) and often involve legal counsel. However, in the case cited, the government contractor would not be directly liable for how another (third-party) government contractor uses its product–especially if it uses the product incorrectly. A contractor who develops components for a government agency is liable to the government–not to another government contractor–to the extent stipulated in the expressed warranties that are part of the contract. There may also be implied warranties of fitness for use for the particular purpose for which the government will use the items. Contracting officers have to consult with counsel prior to asserting any claim for breach of an implied warranty.

The important thing to remember is that liability issues are not unique to product lines. The government often contracts for a piece of equipment from one manufacturer and then provides it as government-furnished equipment (GFE) to another contractor to integrate into its final product. In such cases, the liability for the GFE items rest with the government. However, the government may have recourse to go back to the original development contractor to have a defect corrected, depending on the particular contractual warranties that were negotiated and agreed to by both parties.

For commercial items (i.e., nondevelopmental items), liability considerations (expressed and implied) are described in Part 12 (Acquisition of Commercial Items) of the Federal Acquisition Regulations [FAR 2005a]. General and specific liability considerations that apply to both commercial items and developmental items are described in Part 46 (Quality Assurance) of the FAR.

Specific solicitation provisions and contract clauses on warranties and liabilities that may apply are described in Part 52 of the FAR and Part 252 of the of the Defense Federal Acquisition Regulation Supplement [DFARS 1998a] and include the following sections:

The bottom line is that, during the contract solicitation period, any contractor considering bidding on a government contract can formally request that the contracting officer define (in writing) the extent and limitation of the contractor's liabilities.

What acquisition strategies should a DoD or government organization consider when acquiring a product line? And what is their potential impact on the acquiring organization?

There are several alternative acquisition approaches that a program manager should consider when contemplating adopting a product line approach. Three such approaches are

The potential impact of these particular approaches on the acquisition organization is summarized in the table below.

Product Line Acquisition Approach

Relative degree of organizational sophistication needed by acquirer

Relative degree of acquisition complexity

1a. Development by acquisition organization

HIGH

LOW

1.b Development by acquisition organization and later transitioned to contractor

HIGH

MEDIUM

2.a Development involves one supplier

HIGH

HIGH

2.b Development involves multiple suppliers

HIGH+++

HIGH+++

3.a Single product acquired from supplier-owned product line

LOW

LOW

3.b Multiple products acquired from supplier-owned product line

LOW

MEDIUM

Bergey and Cohen describe these strategies in more detail and cite example product line applications [Bergey 2006a].

Getting Started

All right, I want to start a software product line. What do I do first?

Begin by learning. There are many resources available to you, many of which are available on or through the SEI's Web site. You can

Once you've done some of this suggested homework, you can take the following steps in your organization:

Other steps are involved, but the ones listed above will get you off to a good start.

My company builds a broadly related group of products, each of which is a group of closely related products. Should I plan to build a single product line or a group of product lines?

This question can be answered by making a business case for each alternative and weighing the costs and benefits. The SEI Structure Intuitive Model for Product Line Economics (SIMPLE) can help with this [Clements 2005a]. We've seen this situation in practice many times. Often, the choice is to go with the single, large product line. Examples come from avionics, missile software, embedded engine controllers, and shipboard command and control systems. However, other organizations have chosen separate product lines or even hierarchical product lines. A hierarchical product line is essentially a product line of product lines. The decision depends on the amount of commonality that can be extracted from the broadly related group, how expensive it is to accommodate the needed variation, and how easy it is to communicate and cooperate across the different groups involved. If the products "live" in separate business units, for instance, the organization might find separate product lines to be more manageable. If you're just beginning to use the product line concept, it will be much easier to launch one than several, but having a scope that is too broad will jeopardize success with the product line approach.

I want to pilot software product lines in my organization. What are the criteria for a good pilot project?

The general criteria are the same as for any pilot project. It should be manageable but not too complex. It should be strategic but not so central that the failure of the pilot will bring down the organization. It should build on strengths rather than weaknesses. Specific to product lines, a pilot should be in an established and well-understood problem area and be led by some of the best innovators. Starting with a legacy system rather than starting from scratch makes sense if the legacy system is in good health (that is, if it's architecturally sound, well documented, and uses modern technologies). If an established core asset base is available to jump-start the product line, so much the better. Finally, the scope of the pilot should be narrow enough for results to be achieved and assessed quickly. See the "Launching and Institutionalizing" practice area for more information.

Should I plan to take the proactive approach or the reactive approach to my software product line?

As described in "All Three Together," the proactive approach involves building the core assets first and then using them to spin out products, whereas the reactive approach calls for having products first and then extracting the core assets from them. These approaches are two extremes of a spectrum of possibilities in between. A likely compromise is to develop some core assets fresh while producing others from an existing product or stable of products. Key determinants are how well you can predict the future and your available time and resources. If you can, with high confidence, map out the scope of your software product line in detail (describing the commonalities and variations that your products will require), proactively building the core assets to serve that scope will probably pay off in terms of a rapid product-production capability. If, on the other hand, your scope is defined only in more general terms, trying to build the core assets ahead of time will probably result in a large amount of rework and frustration. In that case, it is better to refine the core assets as you field more products and gain more knowledge about your market. The rule of thumb is to use whatever information you have when you have it.

Where is the resistance to adopting a product line approach usually found?

Although it can come from almost anywhere, it often shows up at the middle-management level. Many times, the folks in the trenches recognize the benefits of doing things the new way, because they're the ones tasked with implementing and re-implementing almost identical applications multiple times. Conversely, senior management tends to have the vision and see the financial bottom lines. That is by no means always the case, however. We also know of an organization in which senior management was preoccupied with buyouts and mergers, and middle management stepped in and championed the transition to product line practice. When senior management turned their attention inward, they discovered to their surprise that their company was building software in an entirely new way.

Where can I go to get more information?

The SEI's Web site on product line practice (http://www.sei.cmu.edu/productlines) is a good place to start. There are several books on software product lines, including Software Product Lines: Practices and Patterns [Clements 2002c], Software Product-Line Engineering: A Family-Based Software Development Process [Weiss 1999a], Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach [Bosch 2000a], and Software Product Lines in Action [van der Linden 2007a]. In addition, Software Reuse: Architecture, Process, and Organization for Business Success [Jacobson 1997a] is oriented towards projects employing large-scale strategic reuse and is compatible in many ways with product line practice.

Conferences on software product lines are also emerging, leaving papers about both theory and practice in their wake. The flagship gathering for the field is the International Software Product Line Conference.

Where can I read about other organizations that have successfully adopted the software product line approach?

Case studies are excellent resources to help you get started, because they show you how other organizations tackled the product line issues they faced. Case studies are listed on the SEI's Web site. In addition, you should visit the Software Product Line Hall of Fame, where software product lines of lasting community value are inducted at each Software Product Line Conference. Each inducted product line is described, and references for more information are given. Finally, some of the product line books mentioned above include several case studies of successful product lines, especially Software Product Lines: Practices and Patterns [Clements 2002c] and Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering [van der Linden 2007a].