Product Line Acquisition in a DoD Organization--Guidance for Decision Makers
John Bergey
Sholom Cohen
Technical Note
CMU/SEI-2006-TN-020
Product Line Practice Initiative
Unlimited distribution subject to the copyright.
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
Acknowledgements
We want to thank Linda Northrop and Matt Fisher for their careful review and insightful comments and suggestions for improving this technical note. We also want to acknowledge Pennie Walters for her contributions in editing and improving this document.
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
1 Introduction
Today's Department of Defense (DoD) acquisition program managers (PMs) must be more and more "software savvy" as they deal with demands for software-intensive systems with greater capabilities and quality, fielded in shorter time, and customized to multiple platforms or situations. This situation is becoming increasingly common, for example
- A unit manager has two legacy systems in dire need of upgrade. Both perform roughly the same functions for different sets of users, but software maintenance on each system has become a nightmare. Their budget is barely sufficient for one upgrade, let alone two.
- A PM acquires a set of software products for other organizations that, in turn, integrate the products as a government-furnished item (GFI) to be used as part of a larger system. Traditionally, each product is developed as a new start, though they have a lot in common. How can they cut costs and get better delivery in terms of time to field?
- A PM has identified three customers from different organizations who need systems or upgrades to existing systems that have a lot in common. Generally, the customers look for unique systems to satisfy their needs, with no plans to capitalize on the commonality. The PM cannot meet the acquisition schedules or budgets for all three systems in parallel. Instead, the PM shop must adopt systematic methods that will allow it to field systems by sharing software across the three development efforts. How can the PM develop a multi-system acquisition approach that will satisfy all three customers without initiating totally unique acquisitions?
Issues in these situations include
- How can a DoD organization capitalize on known software commonalities and accommodate known variabilities within legacy or planned systems?
- How can a DoD organization work with a supplier(s) to build products that share software but deliver tailored capabilities to multiple customers?
- How can multiple DoD organizations benefit from a contractor's software product line?
PMs must address these issues to meet budgets, operational needs, and delivery schedules. They have multiple systems with common requirements, each satisfying the specific operational needs of a particular unit or mission. Yet the PM wants to achieve delivery of the systems without independent development of essentially the same software for each of the systems. The PMs may consider development from a common set of core software, but they need methods to develop the software for the systems in a prescribed way. This problem statement is really a classic definition of a software product line [Clements 04]. A product line approach allows a manager to avoid the classic stovepipe approach to acquiring and maintaining systems by exploiting commonality and managing variability across a family of systems. Within a product line, managers need ways to determine
- what products to develop to meet business goals and future mission demands
- what common software (or assets) to develop or acquire
- how to develop or acquire the assets
- how to develop or acquire the products
- how to manage the evolution of assets and products
In addition to these technical concerns, managers must create a business case [Cohen 01] to examine alternative product line approaches and to justify the costs of developing the software assets that will be used to develop derivative systems in the product line. The managers must also identify potential challenges and risks as part of organizational planning and risk management.
To help address these issues, this technical note provides guidance on four basic decisions a PM must make in adopting a product line approach for acquiring software-intensive systems:
- What is the definition of the software product line for an organization?
- What product line acquisition approaches can or should an organization take?
- What are the decisions a manager must make in adopting the product line approach?
- What are the benefits, challenges, and risks of the product line approach?
This technical note provides a hypothetical example (see Section 2) that describes a typical scenario—a PM with several related projects: some legacy, some under development, and others planned. The PM is trying to decide if adopting a product line approach would be an effective acquisition strategy. The example presents the questions a PM could or should ask about transitioning to a product line approach for acquiring these products. Section 3 identifies some of the key decisions the PM must make to cost-effectively acquire, develop, and maintain a set of related systems. Section 4 presents some alternative product line acquisition approaches for the PM to consider. Section 5 outlines a course of action, including a set of criteria to help the PM make the initial product line adoption decisions and provides a corresponding work breakdown structure (WBS) that lays out a set of tasks that the PM shop and its acquisition organization should undertake when adopting a product line approach. Section 6 is a summary that also identifies some follow-on considerations.
| As a cue to the reader, text that pertains only to the hypothetical situation appears in the Comic Sans font and has a special left-hand border—as shown in this paragraph. | |||||
 |
|
|
|
|
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
2 Hypothetical Organizational and System Context
|
Abe Chapnick is a fictitious PM for a DoD organization. He oversees the development of embedded systems (i.e., products1) that are deployed in a number of large command, control, and communication (C3) systems. His shop manages system acquisitions built around battle space situational awareness (SA) and message handling to update an operational picture for the warfighter. These systems run on a variety of platforms, and, if history is any indicator, the PM shop will be asked to develop new systems, each built around a common operational picture (COP). The word "common" should be placed in quotes, Abe's shop often says, because the current systems each require its own development and maintenance to create and sustain the "common" picture. The PM shop has an acquisition budget in the tens of millions of dollars for new development and a maintenance budget for fielded systems of approximately the same size. In the past month, four different COP projects have come to him with the same problem—how do we maintain the consistency of a COP among the onboard various combatant ships, aviation platforms, hand-carried units, and unmanned vessels in which our systems will be deployed? These parent systems also interoperate with other DoD systems, sharing information and higher level COP views. After reviewing this problem for the past month, Chapnick decided to meet with his staff and come up with a common, synergistic solution. "Each of your systems has its own SA and communication-processing subsystem," he told the project team leaders who were gathered around a conference table. "Every time we add information feeds, we go ahead and rewrite the onboard system four times—once for each of the combat information centers we support—and then we do the same for the handheld, aviation, and other shipboard platforms." "Make that five times for the vehicles," someone chimed in from the other side of the table. "Don't forget the unmanned undersea vehicle (UUV) control processing. We're scheduled to start working on the software portion of the request for proposal (RFP) next month." "That's what I mean," Chapnick said. "Why can't we have a single processing system, tailored to the needs of each individual system? Then, when change happens, we adjust the baseline, release it to each system for tailoring, and there's a single point of maintenance at lower cost and greater reliability." Various objections were raised:
No one objected in principle to the concept of a common architecture and subsystems. But the project team leaders were concerned because they had been down that path before, with shared routines, common object libraries, frameworks, and component-based solutions, and they had experienced only marginal success. So imagine being in Abe's position—you know you can't continue to maintain numerous systems cost-effectively, each using a unique set of components to support SA through a COP, but every software reuse approach you've tried has not improved the development or maintenance picture. What approaches could achieve improved results that have not already been tried and rejected? In preparing for this meeting, Chapnick had read up on software product lines as a new strategic approach to systematic reuse. His analysis confirmed that a software product line is an effective strategy to show that, at the very least, a common architecture using SA and messaging processors, capable of tailoring to accommodate system specifics, could be adopted. The architecture could be retrofitted during major upgrades to some of the legacy systems that were already fielded. If properly written, the RFP for the new UUV system, at least the COP for the controller side of the vehicle, could be designated as the source for assets for a product line of SA and messaging systems to support the UUV and other systems in the PM shop. That would be a tough sell, and acquisitions approaches might get in the way. But, Chapnick's PM staff could take his initial analysis, factor them into planning for the whole range of COP-based systems, and explore acquisition approaches to support a long-term incremental strategy. The next section describes Chapnick's analysis and the decisions he will face in transitioning to a software product line approach. |
||||
|
|
|
|
|
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
3 Analyzing a Product Line Approach
|
Chapnick's analysis began with a master schedule of systems (see Figure 1) showing variation in time (versions) across the space of systems his shop must develop or support. He currently supports a legacy of systems for combat information centers, a handheld device, and aviation platforms. His shop is also working on plans for new versions and releases of these systems plus a variety of related systems for use with UUVs and on aviation platforms. Each of these systems came from different contractors and responded to a variety of requirements, in terms of performance specifications and interoperability. For example, the handheld is to be used by Marine units. Aviation systems, currently under procurement, will interoperate with a variety of other airborne and some ground systems. The UUV is planned to come online in 2008 to provide autonomous, semi-autonomous, and pure manual operations through a handheld control processor. Chapnick wants to avoid risks that have plagued acquisition planning in the past such as
This master schedule gave Chapnick some idea of the scope of systems he was supporting and acquiring. They all shared a number of common capabilities but differed in the mission coverage—the COP of an aviation product might cover thousands of square miles; a handheld might cover only a few-mile radius but in much greater detail. They also differed in platform capabilities—a combat information center has more computing resources to draw on than an embedded, aviation product. The systems are in different stages of maturity and acquisition. In addition, there's the complex issue of supporting a system's operations while planning for the transition of future versions to a product line version.
Chapnick then attempted to characterize the acquisition approach currently used. He concluded that existing systems were largely developed one at a time, with uniquely defined features. Each customer of the PM requires a system that addresses unique mission segments and user needs. Chapnick had seen reuse in the past—the "clone and own" approach—where developers took an existing system, such as that used in combat information centers, and then copied and modified it for new uses. In fact, the handheld and shipboard developments were using exactly this approach. Finally, he knew that even within one development contractor organization, developers had adopted different development practices and technologies with each new system resulting in unique solutions. Table 1 summarizes Chapnick's analysis. Table 1: Characterization of Current Acquisition Approaches in Chapnick's DivisionNext, Chapnick focused on the definition of a product line to contrast the current approach with a product-line-based acquisition approach. A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way [Clements 02]. Chapnick parsed this definition into its constituent parts to see how the current approach, which represents the traditional way of doing business, aligns with a product line approach (see Table 2). Table 2: Contrast of Approaches: Current (Non-Product-Line) and Product Line
Finally, Chapnick wished to compare how the ongoing development activities of the PM shop today would differ from the development activities under a software product line approach (see Table 3). Table 3: Implications of Transition to a Product Line ApproachAt this point in the analysis, Chapnick had already made a few decisions about some basic questions: |
||||
|
|
|
|
|
Figure 1: Schedule for Planned Deployment of COP Systems
- What was the scope of the product line?
He knew the product line as defined by the set of products under current or planned acquisitions. |
||||
|
|
|
|
- Was there a sufficient market to justify a product line approach?
He knew his market or mission segment based on the need for one new system per year. |
||||
|
|
|
|
- Could he characterize the domains?
He knew that SA and messaging were key areas of expertise that could be captured within the product line. The COP-based product line would also require human-computer interaction (HCI) expertise. |
||||
|
|
|
|
- Was there a business case?
Chapnick knew he'd have to justify such a departure from the old way of acquiring systems using a business case. But the ability to maintain a number of systems from a single, common baseline seemed very appealing and compelling, even if a significant investment was needed to exploit the potential. |
||||
|
|
|
|
- Could a common architecture sustain the variability across the product line?
Chapnick considered ways to craft an RFP to see what solutions potential contractors could come up with including the current legacy system developers. |
||||
|
|
|
|
- What processes were needed to support product line development?
Chapnick had identified several key processes when he looked at the transition he'd need to make (Table 3) including ones for
Chapnick still needed to come up with the acquisition approach—his strategy for acquiring core assets to share across the product line and for use in building derivative products. The new UGV RFP presented some fascinating opportunities and challenges—development of a business case, technology forecasting, and other artifacts—that he would explore with his own staff and other individuals supporting the acquisition. He'd also draw on their expertise in cost estimation to craft a business case. He may not have had a complete roadmap yet, but at least he had a destination. Chapman did some research on these considerations and others that were puzzling him by visiting the Carnegie Mellon Software Engineering Institute (SEI) Web site2 and reading some of the publications he found there on software product lines. These reports included a case study of a DoD product line acquisition initiative [Clements 05] and a technical note [Jones 99] that presents the basics of product line practices and reports the results of two DoD product line workshops in which important issues and successful practices were shared. That technical note also provides other examples and sources of pertinent information in its "References" section. |
||||
|
|
|
|
The next section of this report focuses on acquisitions approaches that any PM must consider.
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
4 Possible Product Line Acquisition Approaches
A PM needs to consider a number of alternative acquisition approaches when contemplating adopting a product line approach. Three such approaches that are suitable for use by DoD organizations (and other government agencies) are
- Commission a government organization to develop the product line. This strategy involves acquiring a completely government-owned product line using the in-house capabilities3 of a designated government acquisition organization.
- Commission one or more suppliers to develop the product line. This strategy involves acquiring a complete product line production capability4 and developing derivative products by contracting with one or more suppliers.
- Commission a supplier to develop products using its own product line. This strategy involves acquiring products directly from a supplier that has an existing product line and a demonstrated capability to build derivative products.
A PM must carefully consider these alternative approaches and the implications of each in terms of organizational sophistication. In addition, he must address these questions:
- Does the PM shop have the experience, resources, skills, and commitment needed to implement the selected approach?
- Is the designated acquisition organization capable of implementing and managing the selected approach for RFP preparation, funding, source selection, contract deliverables, and technical oversight?
- Will program managers' technical and acquisition expertise be adequate to deal with the corresponding acquisition complexities and data-rights issues implicit in the approach they choose for delivering products to their customers?
These acquisition approaches are summarized in the following sections and include illustrative examples of the DoD and government projects that implemented them.
4.1 Commission a Government Organization to Develop the Product Line
In this approach, a PM negotiates an agreement to have an acquisition organization develop the product line. That organization is responsible for developing the core assets and a suitable product line production infrastructure. The result is a completely government-owned product line production capability that the acquisition organization can subsequently use to build and manage derivative products under the oversight of the PM shop. This approach is not commonly used today because most acquisition organizations lack the resources and skills needed to carry it out.
Two variations of this approach should be considered:
- The product line's core assets and the products built from them are exclusively developed and managed by elements of the acquisition organization in accordance with the PM's direction. Once delivered, the PM and customer may share the task of maintaining the product.
One example of this approach is the development of a software product line asset base called RangeWare, which the Naval Undersea Warfare Center (NUWC), Division Newport developed to support test range operations [Cohen 02]. After several pilot applications of RangeWare, NUWC is now taking RangeWare into a sustainment phase, expanding coverage of the asset base and applying the assets to new systems. NUWC handles maintenance through a cost-sharing agreement with its customers and uses customer experience to improve the asset base for future product line products.
- The product line asset base and one or more initial systems (i.e., products) are developed initially by the acquisition organization with PM oversight. As the product line matures, the PM has the option of transitioning the asset base to a contractor for use in developing other new systems.
This is the approach that the Software Engineering Center (SEC) at the U.S. Army's Communications and Electronics Command (CECOM) is taking in developing a product line for its Advanced Multiplex Test System (AMTS). The AMTS implements standardized test methods and procedures for electronic systems that use the MIL-STD-1553 data bus [CECOM/LRC 02]. Once the product line is fully mature, the SEC plans to transition the development and sustainment of the product line to one or more contractors.
4.2 Commission One or More Suppliers to Develop the Product Line
In this approach, PMs prepare an RFP—with help from their acquisition organization—for a competitive contract to have a supplier develop a complete product line capability. The supplier assumes responsibility for developing the asset base and building the products specified in the contract or included as future options. The PMs would require government-use data rights for all the contract deliverables that would include the asset base, essential elements of the production infrastructure, and products built from the asset base.
Two basic variations of this collaborative acquirer/supplier approach should be considered:
- A single contractor develops the core assets, maintains the asset base, and builds derivative products. This approach has the benefit of avoiding problems stemming from conflicting business interests that often arise when multiple contractors are involved.
A striking and very successful application of this approach is the Control Channel Toolkit (CCT), a software asset base for a software product line of ground-based spacecraft command-and-control systems built under the direction of the National Reconnaissance Office (NRO) [Clements 01]. The contractor that built the asset base was also the one (i.e., user) that developed the initial products using it. Nothing would preclude the NRO from providing the CCT as a GFI to other contractors that were commissioned to build spacecraft command-and-control systems by the NRO or another government office. Electing such a course of action would correspond to the next approach described.
- A prime contractor develops and maintains the core asset base, and other contractors build and maintain products using the core assets developed by the prime contractor. In this approach, the asset base developed by the prime contractor is a deliverable to the PM shop (or its acquisition organization) and is provided as a GFI to other contractors for use in building products. A complicating factor is that this approach thrusts the government into the role of being the system integrator. One approach for overcoming the potential problems that can arise from this arrangement is for the PM shop to let a single contract to a lead system integrator (LSI). The LSI, in turn, is responsible for contracting with other suppliers (e.g., domain experts) to develop derivative products using the asset base developed by the LSI (or another supplier commissioned by the LSI). Clements, Bergey, and Mason describe an example software development plan (SDP) for a DoD project that adopted such an approach [Clements 05].
4.3 Commission a Supplier to Develop Products Using Its Own Product Line
In this approach, a PM does not have to commission a supplier to develop a core asset base in order to realize the benefits of a product line approach. Instead, the PM lets a competitive contract to acquire products from a supplier with an existing product line capability that includes an extensible core asset base relevant to the PM's application domain. Before committing to this course of action, the PM should first perform a market analysis or formally issue a request for information (RFI) to determine that such an approach is truly viable. One concern associated with this approach is that the PM may not have as much clout in driving the product requirements and in how the product line evolves. As a result, government customers may want to consider forming a users' consortium to exert greater influence on the future direction of the product line. Another concern is that government data rights would need to be negotiated due to the proprietary nature of a supplier-owned product line, but this is not a show-stopper.
Two basic variations of this unique supplier-centric approach should be considered:
- A single product is acquired directly from a supplier that builds the product using its own proprietary product line production capability. Any follow-on products are acquired via a separate acquisition or as an option in the original contract that can be exercised at the government's discretion. Such an acquisition can be an effective way to realize the reduced cost and predictable delivery and product quality that a product line provides.
CelsiusTech Systems AB of Sweden, a developer of large, complex, embedded, real-time shipboard command-and-control systems, positioned itself along these lines. By implementing a product line approach, Celsius Tech found it could support its existing customer base and accommodate new customers, while improving its ability to market and deliver new systems with a reasonably certain schedule, cost, and required functionality [Brownsword 96].
- Multiple products (i.e., a preplanned family of related products) are acquired directly from a supplier that has an existing product line production capability with an extensible asset base. This acquisition strategy is predicated on letting an indefinite delivery, indefinite quantity (IDIQ) contract that includes funding for the first product and provisions and options for acquiring multiple products within the projected scope of the supplier's product line.
The U.S. Army's Technical Applications Program Office (TAPO) adopted such a product line approach to reduce development, maintenance, and integration costs for upgrading the avionics software for the Army's fleet of special operations helicopters [Clements 05]. This product line, which is based on Rockwell Collins' Common Avionics Architecture System (CAAS), is now evolving beyond special operations and being expanded to include Army aviation at large and other DoD rotary wing aircraft. Rockwell Collins proactively pursued a product line approach to address new business opportunities in a way that would significantly lower the cost of developing new software systems and give it a competitive edge in the marketplace.
Other aspects that a PM should consider in selecting a strategy for acquiring a product line—especially as they relate to DoD policy and the acquisition-program life cycle—are described in more detail by Campbell [Campbell 02]. And a case study of an example approach for developing a product line acquisition strategy for a DoD organization is described by Bergey and Goethert [Bergey 01]. That case study focuses on how one DoD organization answered these questions: "What does developing an acquisition strategy involve?" and "How does a DoD organization develop an effective strategy for acquiring a software product line?"
4.4 Considerations in Selecting an Acquisition Approach
PMs must establish a clear set of roles and responsibilities for what the PM shop must take on (or contract for)—whichever approach they select. Key roles and responsibilities are in the following areas:
- core asset development. Responsibilities include
- the mining and reengineering of legacy assets
- new asset development (e.g., architecture, core components, production plan)
- core asset sustainment and the development of new core assets. Responsibilities include the
- maintenance and enhancement of existing assets
- development of new assets (e.g., components, test cases, documentation artifacts)
- product development and sustainment. Responsibilities include
Figure 2 illustrates the key areas where collaborative roles and responsibilities have to be suitably defined for the DoD and contractor organizations commensurate with the product line approach that is adopted.
Figure 2: Key Areas for Defining Roles and Responsibilities of the DoD and Contractor Product Line Organizations
A PM must also tailor the selected acquisition approach to accommodate the needs of the PM shop commensurate with its ability to acquire and manage a product line. Table 4 provides some rule-of-thumb indicators for how the different acquisition approaches will affect a PM's choice, given these considerations.
Table 4: Impact of Selecting a Particular Acquisition Approach
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
5 Guidance for Key Decisions Regarding Product Line Adoption
Next, PMs must consider the decisions they must make to get the product line approach launched in the PM shop. They must also provide a corresponding WBS that lays out the set of tasks their PM shop will undertake to adopt a product line approach in their acquisition organization. Table 5 illustrates the kinds of decisions the PMs must make and the criteria they should use when making them.
Table 5: Decisions in Adopting a Product Line Approach
|
Decision |
Purpose |
Criteria |
Timing and Dependencies |
Results |
|
Scope |
To set bounds on the products the PM will be able to build from the product line |
PM's experience |
Earliest decision |
Drives business case and acquisition approach |
|
Market |
To understand the needs of the customer base and the ability of the PM shop to meet them |
Numbers of products per year for the range of current and future customers |
Developed jointly with the scope |
Drives business case and acquisition approach |
|
Domains |
To understand the product line assets needed to build the product line |
Technical experience and technology forecast. What can be built versus what can be mined versus what can be bought or commissioned. |
Based on the scope |
Specifies commonality and variability across products that are within scope |
|
Business case |
To characterize the benefits and risks of alternative approaches |
Cost benefit analysis |
Based on the scope, domain understanding, and review of acquisition alternatives |
Provides data for a go/no-go decision for the product line |
|
Acquisition approach |
To address the production strategy and acquire core assets and products |
Sophistication of the PM shop in both technical and managerial areas |
Based largely on the scope, market, and analysis of alternative acquisition strategies |
Is incorporated into the business case to weigh possible alternatives |
|
Training |
To ensure that the PM shop understands the basic concepts of the product line approach and the roles played by each participant |
Sophistication of the PM shop in both technical and managerial areas |
To understand product lines, all participants need training in basic product line concepts. To execute product lines, select individ-uals need training in advanced product line concepts. |
Staff is trained to work with contractors and customers. |
|
Architecture definition |
To create the structure for the construction of all future components and products in the product line |
Scope, domain understanding, and design constraints |
Dependent on the scope, commonalities/ variabilities, and design expertise |
PM reviews the designs for structuring the product line and the component assets to be used in building products. |
|
Processes |
To guide all operations (technical and management) within the PM shop and contractors |
Existing development and acquisition processes; product line framework practice areas [Clements 04] |
Based on the scope, acquisition approach, and concept of operations for the product line roles and responsibilities |
PM reviews processes proposed and adopted by contractors for creating the asset base and using it to build products. |
|
Customer interface management |
To create effective ways to work with new or existing customers under the product line approach |
Ongoing working relationships, customer satisfaction, growth areas |
Based on the scope Provides inputs to the business case |
Identification of the groups or individuals responsible for interfacing with customers Assignment of roles and provision of training |
|
Production strategy |
To provide overall guidance for creating and sustaining the asset base and using the asset base to build products |
Scope, domain understanding, and acquisition approach |
Dependent on early knowledge of the asset base structure and acquisition approach |
PM reviews proposed processes to create the asset base and generate a production plan for building future products |
|
Customer interface management |
To create effective ways to work with new or existing customers under the product line approach |
Ongoing working relationships, customer satisfaction, growth areas |
Based on the scope Provides inputs to the business case |
Identification of the groups or individuals responsible for interfacing with customers Assignment of roles and provision of training |
These activities and decisions are described in more detail in the Software Product Line Acquisition: A Companion to A Framework for Software Product Line Practice developed by the SEI [Bergey 04, Clements 04].
|
||||
|
|
|
|
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
6 Summary and Follow-On Considerations
A compelling case can often be made for adopting a product line approach because it addresses a problem facing many PMs today—how to cost-effectively acquire, develop, and maintain a set of related software-intensive systems. Managers can easily recognize the potential of capitalizing on commonality across the systems they support through a product line approach. However, they lack guidance on the decisions they need to make about the product line approach and on the information they need to assemble to make these decisions. The hypothetical acquisition scenario that is described is the basis for providing generic guidance for the activities a PM shop should pursue when considering adopting a product line approach. The technical reports and case studies cited under the alternative acquisition approaches provide additional information for the PM shop to consider when choosing the course of action that is best suited to its needs and those of its customers.
Another approach not discussed in this report is to have an outside organization conduct a product line diagnosis to evaluate a PM shop's (or supplier's) ability to launch a product line initiative. The SEI, with its Product Line Quick Look5 and Product Line Technical Probe,6 is just one organization that provides product line diagnoses. If the diagnoses show that there is potential for a product line approach, a plan should be developed that addresses identified shortcomings and capitalizes on organizational strengths.
|
References |
|
|
Bergey, John; Fisher, Matthew J.; & Jones, Lawrence G. DoD Acquisition Environment and Software Product Lines (CMU/SEI-99-TN-004, ADA244787). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1999. |
|
|
Bergey, John; Fisher, Matt; Gallagher, Brian; Jones, Lawrence; & Northrop, Linda. Basic Concepts of Product Line Practice for the DoD (CMU/SEI-2000-TN-001, ADA375859). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. |
|
|
Bergey, John K. & Goethert, Wolfhart B. Developing a Product Line Acquisition Strategy for a DoD Organization: A Case Study (CMU/SEI-2001-TN-021, ADA395202). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2001. |
|
|
Bergey, John; et. al. Software Product Line Acquisition: A Companion to A Framework for Software Product Line Practice, Version 3.0 (2004). |
|
|
Brownsword, Lisa & Clements, Paul. A Case Study in Successful Product Line Development (CMU/SEI-96-TR-016, ADA315802). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996. |
|
|
Campbell, Grady H. A Software Product Line Vision for Defense Acquisition (CMU/SEI-2002-TN-002, ADA403810). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002. |
|
|
Communications-Electronics Command (CECOM)/Logistics Readiness Center (LRC). 2002 Defense Standardization Program (DSP) Annual Awards: CECOM SEC & LRC Advanced Multiplex Test System (AMTS) (2002). |
|
|
Clements, Paul; Cohen, Sholom; Donohoe, Patrick; & Northrop, Linda. Control Channel Toolkit: A Software Product Line Case Study (CMU/SEI-2001-TR-030, ADA396286). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2001. |
|
|
Clements, Paul & Northrop, Linda. Software Product Lines: Practices and Patterns. Boston, MA: Addition-Wesley, 2002. |
|
|
Clements, Paul & Northrop, Linda. A Framework for Software Product Line Practice, Version 4.2 (2004). |
|
|
Clements, Paul; Bergey, John; & Mason, David. The U.S. Army's Common Avionics Architecture System (CAAS) Product Line: A Case Study (CMU/SEI-2005-TR-019). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2005. |
|
|
Cohen, Sholom. Case Study: Building and Communicating a Business Case for a DoD Product Line (CMU/SEI-2001-TN-020, ADA395155). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2001. |
|
|
Cohen, Sholom; Dunn, Ed; & Soule, Albert. Successful Product Line Development and Sustainment: A DoD Case Study (CMU/SEI-2002-TN-018, ADA407788). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002. |
|
|
Cohen, Sholom; Zubrow, Dave; & Dunn, Ed. Case Study: A Measurement Program for Product Lines (CMU/SEI-2004-TN-023). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004. |
|
|
Cohen, Sholom; Friedman, Seymour; Martin, Lorraine; Royer, Tom; Solderitsch, Nancy; & Webster, Robert. Concept of Operations for the ESC Product Line Approach (CMU/SEI-96-TR-018, ADA313952). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996. |
|
|
Jones, Lawrence. Product Line Acquisition in the DoD: The Promise, The Challenges (CMU/SEI-99-TN-011, ADA373184). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1999. |
|
|
Northrop, Linda. "SEI's Software Product Line Tenets." IEEE Software 19, 4 (July/August 2002): 32-40. |
|
|
|
1 This technical note uses the terms products and software-intensive systems interchangeably because the "products" in the example product line are software-intensive systems.
2 http://www.sei.cmu.edu/productlines/index.html
3 In this approach, acquisition is limited to using local support contractors or Systems Engineering and Technical Assistance (SETA) contractors.
4 This capability would include acquiring the core assets (e.g., the architecture, software components, production plan) and other artifacts that the government would need to operate, sustain, and enhance the product line capabilities and develop additional products.
5 For more information, go to http://www.sei.cmu.edu/productlines/plql.html.
6 For more information, go to http://www.sei.cmu.edu/productlines/pltp.html.
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]
This work is sponsored by the U.S. Department of Defense.
The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense.
Copyright 2006 Carnegie Mellon University.
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 252.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).
[3 Analyzing a Product Line Approach]
[5 Guidance for Key Decisions Regarding Product Line Adoption]
[References]