Posted on by Software Sustainmentin
by Robert Ferguson Senior Engineer Software Solutions Division
My prior blog post on product lines in DoD sustainment described the complexity of contractual relationships in a DoD software product line. Recall that a software product line is a collection of related products with shared software artifacts and engineering services that has been developed by a single organization in support of multiple programs serving multiple missions and different customers. A product line can reduce cost of development and support. In exchange, it can be a cause of conflicting priorities between customers, much like the similar problem in joint program management. This blog post describes a set of guidelines and goals for establishing governance and monitoring the product line for long-term success.
The Complexity of Sustaining a Software Product Line
In this article, I refer to the core components and services as the platform. In the context of DoD acquisition and sustainment, each independent DoD program serves a unique mission. Each program benefits from the use of the platform components. Each program also develops its own unique capability to support its mission. The Venn-diagram below illustrates the situation.
The central circle in the Venn-diagram represents the core platform components and services. Each of the three larger circles represents a single program. Each program uses some portion of the platform capability to develop its mission capability. A portion of the central platform may lie outside the context of a specific program that does not require some specific function. The programs may also overlap representing the potential for sharing additional capability across multiple programs. This shared capability also represents the potential to be captured into the platform components and services.
Analysis of the Venn diagram reveals the complexity of decisions in the product line:
Specific Goals of the Product Line Governance Function
Governance of the product line must support the following goals and identifiable measurable outcomes:
1. Quality: Core components have exceptionally high quality. Defect density of core components should be typical of best-in-class products when compared to industry benchmarks for software-intensive products. The required high quality of the core can be measured. Extra costs are associated with resolving core defects for two reasons. First, programs must demonstrate that bugs are not part of program software and should be resolved instead by the platform developer. Second, the platform developer must then apply the fixes to the other programs to maintain the integrity of the product line.
2. Cost of Sustainment: Sustainment costs of platform are reduced for participating programs. The program community should see the cost of sustaining the platform as a fraction of a benchmark estimate for the platform cost. Working our way through an example, suppose the core is 1 million lines of code (MLOC), and there are five programs using the product line. We estimate the annual benchmark cost of the platform is 16 people (10 for code, 4 for testing, 1 for configuration management, 1 for documentation). We estimate the cost of supporting a single program is two additional people for liaison and configuration. Supporting 5 programs the annual cost looks like the following.
Platform sustainment cost must include cost of support to programs:
Benchmark Cost + overhead*Number of programs=Platform Cost
Example: 16+2*5 = 26 people
Program cost of platform components is reduced by cost sharing but adds some overhead:
Platform Cost/number of programs + overhead = Program Cost
Example: 16/5 +2 = 5.2 people
3. Reduced time to add features to programs: New features in the core can be rapidly deployed to multiple programs in the product line. Rapid deployment is achieved by product design that isolates variability to a smaller number of specific components. It is also achieved because propagating an improvement to one program simplifies the effort required to provide the same functionality to another program. The high quality of the core platform contributes significantly to the reduced time to deliver.
4. Reduced time to distribute capability between programs. The core platform has the strategic capability to recapture newly developed program capabilities into the core platform. Capability captured by the core platform provides all the product line capabilities to other programs (documentation, testing, etc.). Cost of recapture should be weighed against the cost of changing multiple individual programs.
5. Releases occur on a regular schedule. Releases are synchronized within a reasonable timeframe to avoid increasing the difficulty of managing multiple different configurations of the core. Multiple configurations of the platform add complexity to the sustainment and support, and, thus, increase costs and cause quality problems.
Each of the five goals covered above suggests potential measures:
Developing a Governance Policy
Governance requires a high-level decision authority, which often contributes to a slower decision process. Governance policy must therefore be carefully articulated so that most decisions are made at the platform or program level to minimize the effects of the slower process. Policy should address the following:
Looking Ahead: A Shared Commitment
A product line in the DoD requires a shared commitment across a number of programs. Each program has its own program management office (PMO). Some governance structure is therefore needed to maintain the alignment of goals, thus keeping the product line viable across multiple releases of the products.
In the next post in this series, I will describe a decision process for release management. It is designed to support both a single product and the core program for a product line.
Read the first post in this series,
Read the series by Mike Phillips on Efficient and Effective Software Sustainment.
View the podcast Software Sustainment and Product Lines by Mike Phillips and Harry Levinson. Common Infrastructure and Joint Programs, Fourth in a Series
Read Common Infrastructure and Joint Programs, Fourth in a Series by Bill Novak