Control Channel Toolkit: A Software Product Line Case Study
3 Launching CCT
The primary motivation for adopting a product line approach is economic¾
the promise of long-term savings in return for some extra short-term effort. Thus, business issues often dominate any discussion about a particular product line. The resolution and handling of those business issues may determine the success or failure of the product line effort, as measured by its long-term costs and savings. The feasibility study team, which was already steeped in the understanding of the domain we just summarized, analyzed both business and technical issues. In getting started, they and the initial CCT team that followed exercised practices in the following software product line practice areas:
And it was the combination of practices from these areas that accomplished the "Launching" part of the "Launching and Institutionalizing" practice area.
The business goals for CCT were to reduce life-cycle costs and development risks, promote interoperability, and provide flexibility. For the government spacecraft community, flexibility translates into accommodating multiple implementation contractors and enabling the integration of both commercially available and legacy assets. The strategy was to develop a toolkit once, and have the three candidate programs share the development and maintenance costs.
The study team examined an array of government and commercial spacecraft command and control systems, including the three under primary investigation. They objectively examined the life-cycle cost data of the DCCS, the SSCS, and the Spacecraft C2 Program. Original program estimates were used; the validity of these estimates was not challenged, although the estimates were considered by the study team to be lower than the actual costs. Based on a domain requirements analysis, cost estimates were derived for implementing the three candidate systems using a product line approach. The commonality of requirements across these systems ranged from a low of 49% to a high of 89%, and the cost-benefit analysis showed significant life-cycle savings. The team also conducted a thorough risk identification and analysis activity. Mitigation strategies were defined for identified risks.
The feasibility study concluded that:
The business case for CCT, as expressed in the original CCT statement of work, described cost savings over multiple programs that were partially attributable to maximized reuse of DCCS assets and exploitation of DCCS experience. Interestingly, the cost analysis did not show major savings for CCT’s three candidate systems in terms of development; program sponsors were sold on the vision of greatly reduced risk and the promise of cost savings in the future. The concept of recruiting additional subscribers to the product line¾
that is, finding new satellite programs that could be built using CCT¾
was always a key part of the business strategy behind CCT.
Typically a command and control system is acquired as part of a larger procurement that includes whatever is being commanded and controlled. The contract for the entire procurement is usually awarded to a single prime contractor. In the case of CCT, three government programs formed a partnership to acquire software that could be used across those three programs, as well as others. The CCT acquisition strategy required that the government assume some responsibility development, because spacecraft software systems were becoming too complex to be acquired as stand-alone, one-of-a-kind systems. Otherwise, both the cost and the risk were too great.
Asset ownership was a key product line issue, because
the product line was commissioned by one organization but
developed by another. In the CelsiusTech example described
by Brownsword and Clements, a defense contractor developed
a product line on its own initiative and successfully sold
it to many governments around the world [Brownsword 96].
In that case, CelsiusTech made sure to retain all
intellectual rights to the product line.
In the case of CCT, however, the product line was commissioned by the U.S. Government, which wanted to recover its up-front investment in building the assets by realizing savings across other programs, some of which had not yet been identified. Therefore, it retained the rights to the asset base. In both the CCT and CelsiusTech cases, intellectual rights resided with the organization that (1) paid the up-front cost to build the asset base and (2) took it upon itself to find more customers for the product line to recoup that cost.
Although the NRO commissioned Raytheon for development of product line assets, the assets may be used by other government organizations. These organizations will commission contractors to build specific spacecraft command and control systems. The U.S. Government retains total rights to the CCT architecture and the components. However, Raytheon has full freedom to develop commercialized derivations that they can then bring to the marketplace.
There are four
organizational groups or stakeholders in the CCT effort; the NRO
(the sponsoring customer) and Raytheon (the commissioned
developer) have already been mentioned. The third set of
stakeholders consists of the organizations charged with
developing the systems for which the product line was launched:
the Spacecraft C2 System, DCCS, and SSCS. The fourth set of
stakeholders includes future CCT users¾ those organizations that may
subscribe to CCT as a basis for building or reengineering their
own systems in the future. Only the organizational units that
the NRO and Raytheon structured for CCT were important to the
initial CCT effort.
Raytheon’s CCT Program was divided into the organizational
units shown in Table 1 to accomplish the
CCT development tasks.
Table 1: Raytheon’s Organizational Structure for CCT Development
Organizational Unit Responsibilities Contractor program office Technical management of development effort; accountable to the NRO CCT Program Office Program support Technical management support functions—for example, configuration management, quality assurance, business operations Domain engineering and architecture Requirements engineering; architecture definition Component engineering Component development Application engineering Testing architecture that demonstrates the ability to build products from CCT Test engineering Component and assembly testing Training Training materials and internal training of CCT personnel Sustainment engineering Fixing and enhancing CCT baseline; working with application engineers and users to refine, deliver, and maintain the CCT assets CCT development was
structured into six overlapping increments with an integrated development team responsible for each. The members of the integrated teams came from a cross section of the organizational structure listed in Table 1 with the exception of the first increment, which involved only the Domain Engineering and Architecture group because this increment was primarily dedicated to scoping the CCT product line. The phases and the integrated teams make explicit the iteration we talk about as inherent in core asset development.
The NRO’s organizational unit for CCT was the CCT Program Office, which consisted of a small team of government management and technical personnel who managed CCT development at the organizational level. The CCT Program Office was augmented by a small number of technical personnel from two government research and development centers, the SEI and the Aerospace Corporation.
Every product line effort is dependent on strong
communication among the stakeholders
[Clements 01]. To ensure effective communication and to guide CCT’s development over the extended life cycle-¾
creation, usage in an initial product set, usage in a future product set, and evolution¾
the CCT Program Office created a variety of working groups. The main CCT working group coordinated project-level decisions for the CCT program and ran the stakeholder working groups. In turn, the stakeholder working groups provided direction for the CCT component and sustainment engineering groups. An architecture group advised the main working group on issues relating to the CCT architecture.
Raytheon’s integrated teams and the NRO’s working groups were a unique aspect of the CCT organizational structure that permitted productive cross-pollination and communication among the stakeholders.
The NRO and Raytheon partnered in the planning of CCT. CCT development was scheduled to begin in August 1997 and end on December 31, 1999. Plans were developed that spanned this time period. These plans addressed carefully the organizational management needs of the CCT Program Office for reviews and incremental deliveries, Raytheon’s technical management needs for plotting and tracking the development processes, and Spacecraft C2’s needs for requisite CCT assets for their system development effort. In addition, configuration management, risk management, and quality assurance plans were developed. There was also a transition plan to be used by developers of CCT-based systems, which describes the process for delivering and installing the CCT assets for use by developers of target systems. The formal process of maintaining the CCT assets was documented in a CCT Sustainment Plan.
All of these plans were accessible at the CCT Web site, and all were updated as the CCT effort progressed to depict the current status of the CCT development and integration process. The CCT effort scored high in the two planning practice areas; the development of the plans, the plans themselves, and their practice of religiously keeping the plans visible, accessible, and up-to-date make CCT an exemplar in these practice areas.
Operations for core asset development were governed by the plans set in motion. The integrated teams for each of the six development increments carried out the development tasks. The systematic reuse approach adopted by the CCT effort was process-driven and took advantage of what was available¾
legacy assets, proven algorithms, and commercial off-the-shelf (COTS) products. Value-adding operational processes included frequent technical interchange meetings, weekly status meetings with the CCT program office, and use of the CCT Web site to post all artifacts and documentation. The government designated more than 20 documents as deliverables in addition to supporting documents created to aid developers and users. Baselined versions of all deliverable documents and links to the CCT models and software development folders were available on the CCT Web site. The site also hosted the CCT master schedule, archives of reviews, and project status information.
The integrated teams and the working groups promoted sufficient community and stakeholder involvement to make traditional long, drawn-out government reviews unnecessary. The CCT Program Office established a modest number of review points at which increment deliverables and the status of development and technical management activities were reviewed. Metrics were defined and the corresponding data collected to track and evaluate progress. A proof-of-concept prototype was developed to show how long it would take to mine assets and integrate them with the architecture.
As for how the CCT effort would connect with the software product line it was to support, the NRO developed the CCT Program Concept of Operations, which documented operations for coordination with CCT users (those organizations developing products from the CCT assets). This concept of operation contained:
Also defined are three stages for using CCT to support the envisioned spacecraft command and control product line: asset development, asset sustainment and process refinement, and product line sustainment and improvement.
The CCT Concept of Operations called for a Senior Management Panel to provide "corporate oversight" of the product line and to guide its evolution by setting strategic goals (such as attracting particular new customers). The CCT Program Office was to take the lead in evaluating new subscribers. The sustainment costs were to be shared equally by all future partners, although it is easy to imagine variations on this allocation should all parties agree.
The Business Plan: Asset Development Phase, an addendum to the concept of operations, established procedures and criteria for working with potential CCT users. These procedures were designed to support evaluation of the ability of the CCT assets to accommodate the technical and programmatic requirements of new users. Also identified were organizational responsibilities, coordination processes, and timelines for conducting these evaluations and establishing agreements with new users. Specifically, the business plan addressed the qualification of new subscribers. A preliminary assessment to evaluate a prospective new program that inquires about using the CCT product line assets was defined. This assessment was designed to determine the answers to the following questions:
If the preliminary assessment was favorable, then a detailed evaluation would take place, based on the following criteria:
The concept of operations documents developed for CCT provide rich examples for organizations that will not be the product developers of the products in their product lines.
CCT also developed a concept of operations for the sustainment phase that contains:
[Title Page]
[Abstract]
[Figures]