Software Engineering Institute Carnegie Mellon

Control Channel Toolkit: A Software Product Line Case Study

4  Engineering the CCT Core Assets

CCT development consisted of six major software engineering processes:

  1. Domain engineering and architecture

  2. Component engineering

  3. Application engineering

  4. Test engineering

  5. Sustainment engineering

  6. Training

These processes incorporate many of the practices of Jacobson’s incremental and iterative reuse-based approach [Jacobson 97] and Kruchten’s "4+1 view" model of architecture [Kruchten 95], complemented by the test engineering process. As we have already noted, the engineering processes proceeded through six increments, delivering successively more complete versions of CCT assets. These processes map to the product line practice areas, but we will be faithful to CCT terminology for our description.

The domain engineering and architecture processes were responsible for defining and specifying the product line and creating the product line architecture.1 The component engineering process created the components of the toolkit. Application engineering was an internal reuse process designed to create a spacecraft command and control application for testing, deriving the application from the reusable assets delivered by the other processes. In particular, the application engineering team created demonstration architectures from the CCT assets and, with the test engineering group, created detailed test procedures for validating the reusability of the asset base after each increment was complete. The sustainment engineering process managed the maintenance and evolution of the CCT assets once they were baselined following delivery during each CCT increment.

The domain specification, reference architecture, and components addressed the common core functionality for systems in the product line. Together with the architecture model and Reuse Guide aimed at users of CCT assets, they comprised the major deliverables of the CCT project. The processes for creating and validating assets, the process outputs, and the process interactions evolved during the course of development. An example of this evolution was the addition of an architecture evaluation step to the architecture-creation process, and the creation of the architecture model as a separate deliverable. To a large extent, the documents produced during the CCT creation were a reflection of the processes.  

 

4.1  Domain Analysis

Although a formal domain analysis method was not used, the essential tasks of domain analysis were performed. They:

  • captured and analyzed common requirements and their variation across several systems

  • synthesized them into a set of common requirements for the product line

  • captured the essential terminology

The CCT domain analysis began with an analysis of the requirements of the three satellite command and control systems for which CCT was built: DCCS, SSCS, and the Spacecraft C2 System. This activity defined the scope of the product line and created a set of generalized common requirements for CCT. The final phase of the domain analysis created a specification of satellite ground-based command and control requirements, applying a use-case-driven approach to describe the commonality and variability across the product line.

The domain definition process classified product line requirements into the two domains: execution (the real-time or near-real-time activities that occur during a contact with a satellite) and planning (the non-real-time activities that occur before or after a contact). Within these two domains, the process identified categories of components to be provided by the toolkit (for example, handling of telemetry streams and orbit estimation) and the common services that support these categories (for example, persistent storage services and event notification services). This partitioning of the problem domain provided the basis for the logical view of the CCT architecture: a planning part and an execution part. Raytheon partitioned the requirements on the basis of the consensus of the domain analysts and the contractor’s own experience in building previous spacecraft command and control systems.

 

The domain definition process produced three documents that described the scope and general requirements of the product line:

  1. The Domain Definition Document provided an overview of the product line. It described the common features of related systems and defined the scope of the CCT assets for supporting those systems. A glossary of product line terminology was also provided. The scope of CCT was defined in terms of the mission and system characteristics that CCT supports, organized in terms of component categories. For example, CCT will support up to two simultaneous telemetry streams per spacecraft, but users have to provide their own persistence and archiving solution since CCT does not provide a standard database solution.

  2. The Generalized Requirements Specification documented the contractual requirements for CCT. To create this document, requirements from three different customer bases were examined: DCCS, the Spacecraft C2 System, and SSCS. The document captured common capabilities to be provided by the toolkit. Each requirement was briefly described and was classified as being in one of the domains identified by the domain definition process¾ execution or planning¾ or categorized among the common services. Variability in the common requirements was expressed in terms of variation points that were more fully described in the Domain Specification Document. This initial requirements process was supported using Rational’s Slate tool to create and maintain a matrix of requirements and textual descriptions mapped to unique identifiers and to the component categories. To maintain traceability from the generalized requirements back to their origins in the three analyzed systems, an additional document was created using Slate.

  3. The CCT Domain Specification Document contained use-case diagrams and descriptions for the common requirements. Variability was incorporated into the use cases as explicit variation points. This document also provided the design for each use case in terms of sequence diagrams that show the interactions among the blocks participating in the use case. It provided the top-level analysis model to be used by the subsequent domain engineering, component engineering, and application engineering processes.
 

 

4.2  Architecture

Prior to initiating the architecture activity, the architecture group conducted a survey of architecture techniques to provide early input to the architecture-creation process. They decided to follow the "4+1 view" model of Philippe Kruchten [Kruchten 95] and to use the Unified Modeling Language (UML) to represent it. The process for defining the software architecture evolved considerably during the development of the CCT assets; they were a bit late in getting "architecture religion." During the early increments, the architecture group considered the component categories as fully embodying the architecture. As their understanding matured, the group developed and maintained a CCT architecture model. They also agreed to two architecture evaluations¾ one for each of the execution and planning logical entities.  

4.2.1   Architecture Definition

There were two key documents that described the CCT architecture and its use:

  1. The CCT Architecture Model provided a complete description of the architecture. This model provided the philosophical underpinnings of the approach, architectural drivers and concepts, and architectural and design patterns. 2 It also included the architectural views: the logical view which consists of the static object model; the development view which showed layers; the dynamic view, which consisted of the component interaction model; and the process view, which consisted of the process interaction model. UML, as supported by the Rational Rose tool, was used. 3

  2. The CCT Reuse Guide documented the CCT assets that could be used to build a product in the product line. The audience for this document was software engineers responsible for selecting and utilizing CCT assets when building a product. The Reuse Guide helped compare capabilities of CCT with program requirements for a new command and control system. This was to assist product builders plan their use of CCT assets and determine modifications and extensions that would be needed. For extensions at variation points, the Reuse Guide provided and described the implementing mechanisms. The CCT Reuse Guide was the production plan for building products in the product line.

Architecture definition and component engineering were closely coupled. The architecture imposed constraints on the design of the components and their interactions. In particular, the less-is-more approach of successful architecture, which seeks to limit the number of different design elements and the permissible interaction mechanisms, was used. The CCT architecture definition process addressed these issues by explicitly listing permissible component interaction mechanisms (such as publish-subscribe, callback, event notification, and so on) in the Architecture Model. The model discussed their rationale and the constraints of these mechanisms as part of the description of the reference architecture concepts. The Reuse Guide provided the implementation view that explicitly identified the programming approaches associated with architectural components.

The Common Object Request Broker Architecture (CORBA) was chosen as the basis for the architecture’s intercomponent communication infrastructure. Mission-unique modification and feature extension could happen in several ways. Product builders could replace components at the architectural level by wrapping the new (or legacy) components with Interface Description Language (IDL) specifications and using the Object Request Broker (ORB) to integrate them into the runtime system. They could also use ORB common services to add their components to the architecture transparently by using common events or data. Finally, they could extend CCT component implementations at designated variation points using inheritance or parameters [Hollander 99].

Common services corresponded to CORBA services and facilities. These included naming and event services, object persistence services, and event notification and callback services. Other services included those for creating data-driven displays, printing, manipulating and translating time values, manipulating coordinate systems, activity logging, and managing application event loops. Services are also provided for controlling multiple threads in an application. CCT also provided wrappers for device drivers.

The CCT architecture organized software components into component categories; a category supported development of a specific subsystem within the product line. Within each component category lived related components that users might integrate together to achieve higher-order functionality. Components in different categories might use each other in well-defined ways, so that many system functions would be accomplished through the operating and interaction of components across different categories.

There were two primary subsystems in the CCT architecture: planning and execution. The planning architecture referred to the non-time-critical component categories that, for example, produced commands to send to a satellite at some future time. The execution architecture referred to the time-critical component categories that facilitate communication of commands to and reception of telemetry from a satellite. Component categories across these two subsystems did not interact except by reading data from and writing data in shared files. The most common form of interaction would occur when an execution component reads (and transmits to the satellite) a command sequence produced by a planning component.

4.2.1.1   Execution Architecture

Figure 2 shows the data flow view of a product architecture using the CCT architecture’s execution subsystem. The shaded area covers components provided by CCT. The arrows indicate control and/or data flow.

Figure 2: CCT Execution Architecture: Data Flow View
Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows.

Variation is supported by the addition of the components outside the shading. The CCT components within the five component categories provided common features and also supported variation as follows.  

 

Status Component Category

Status referred to the processes needed to receive telemetry data streams from either ground equipment or the spacecraft, perform integrity checks on the data stream, and decommutate the data into last recorded values (LRVs), which represent the latest and best estimate of the parameter’s raw value. Variation points included how the status component would recognize and respond to format changes, as well as how the component would perform validity checks.  

 

LRV Component Category

LRV received raw decommutated telemetry data from status processes. Processes in LRV then performed predefined conversion operations to generate engineering values for the decommutated data, performed limit checks on the data, generated alarms in response to undesired telemetry states, and provided LRV data to other processes. The logging of LRV data formed the key interface for providing data to the planning part of the system. A key variation point was the ease with which new LRVs could be defined and integrated into existing LRV processing. CCT provided LRV processing components that performed basic conversions, limit checking, and alarm generation and supported various forms of customization through parameters and inheritance.

  • New algorithm definitions were allowed, and a distribution service was provided.

  • Definition of new LRVs was supported.

  • LRVs could be defined in terms of other LRVs, providing the ability to define higher-level state information.
 

Control Component Category

Processes in the control component category encoded client commands to external devices (ground equipment or spacecraft) into data packets or streams with appropriate formatting. CCT provided a command request interface to process and release regular and time-critical commands. Basic formatting algorithms could be parameterized or replaced. Unique verification logic could be added. CCT also provided a procedural control language that can be used to automate complex commanding sequences.  

 

On-Board Processing Component Category

On-board processing referred to processes that model and help manage computer processor memory on board the spacecraft. Common capabilities included providing state information to clients and comparing the predicted memory map with telemetry-based snapshots of the actual memory map. CCT provided a memory map model with interfaces to support product extensions.  

 

History Component Category

History referred to the processes that log and retrieve data received or generated during contact with a spacecraft. CCT provided common logging and retrieval from short-term storage to flat files. Product builders would be responsible for providing alternative persistence strategies, such as database logs and data replication.  

 

4.2.1.2  Planning Architecture

Figure 3 shows the data flow view of a product architecture using the CCT architecture’s planning subsystem. The shaded area covers components provided by CCT. The arrows indicate control and/or data flow.

Figure 3: CCT Planning Architecture: Data Flow View
Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows.

The CCT components within the six component categories of planning provided common features and supported variation as follows.  

 

Orbit Component Category

Orbit referred to processes that estimate a spacecraft’s orbit parameters based on observed data (state determination) and then propagate the orbit through time. CCT provided a standard family of estimators and propagators, including those commonly used by systems for spacecraft command and control missions. Variation points permitted product-specific tools to generate orbit data or use outside sources to provide orbit data.  

 

Attitude Component Category

Attitude referred to processes that estimate a spacecraft’s attitude (orientation) based on observed sensor data and then propagate the attitude through time to accomplish prediction. CCT provided attitude estimators and propagators for spin-stabilized and three-axis-stabilized spacecraft. Products could integrate their own tools to generate attitude data or sources to provide attitude data.  

 

Maneuver Component Category

Maneuver referred to those processes that plan and generate maneuver sequences. These sequences use thruster (jet) firings to change a spacecraft’s orbit, attitude, or momentum rate. Maneuver is key to orbit and attitude maintenance, taking orbit and attitude information, along with vehicle-specific propulsion system models, and generating the necessary plan to maintain or achieve the desired orbit or attitude. Maneuver planning depends heavily on the specifics of the spacecraft and its mission. Since the variation in this area is so wide, CCT provided general component frameworks for developing maneuver-planning processes. CCT implemented a common solution for spin-stabilized and three-axis-stabilized spacecraft. These implementations could be further generalized as the product line matures.  

 

Vehicle Component Category

Vehicle referred to components that provide mission-unique spacecraft models to other components. The vehicle component captured several common interfaces of a spacecraft, with each parameter requiring user definition and implementation. These parameters included the following spacecraft characteristics:

  • A unique identifier

  • Mass properties as determined by the positions and mass properties of the spacecraft subsystems and appendages

  • Orbit, attitude, and time state

The vehicle component category provided extensibility so that users could capture their mission-unique spacecraft features. Users could freely extend the given vehicle model for their spacecraft by defining new spacecraft components and component relations.  

 

Schedule Component Category

Schedule referred to processes that plan spacecraft and ground system activities. The scheduling process results in a chronological set of scheduled activities from which plans are generated. The CCT architecture provided an extendable framework and a default implementation that accepted inputs through a timeline display, scheduled the activities, and then generated plans for a satellite pass. Variation points included selection (or addition) of scheduling and conflict-resolution algorithms as well as mission-unique requirements and data.  

 

Evaluation Component Category

Evaluation referred to the processing of previously collected telemetry and control data. This processing could generate trending or unit history data or be used to play back archived data through the execution telemetry and control component categories. Evaluation was performed in support of the needs of component categories in both the execution and planning subsystems. Variation points included inserting new algorithms for controlling playback speeds and processing data.  

 

4.2.1.3  Variation Summary

Within each of the CCT subsystems, use of individual components could vary, according to mission-unique requirements. Variation points were identified during domain specification, propagated through analysis and design, and supported by the CCT architecture. Depending on the type of variation point, CCT provided one of six standard mechanisms:

  • Dynamic attributes
    		•

  • Parameterization
    		•

  • Template
    		•

  • Function extension (callbacks)
    		•

  • Inheritance
    		•

  • Scripting

    •  

    Table 2 provides a summary of the breadth of variation CCT can accommodate [Shaw 00].

    Table 2: Component Variation Across CCT

    Domain

    Component Category

    Components

    Variation points

    Execution

    Status

    4

    1

    LRV

    4

    1

    Control

    6

    14

    On-board exec

    3

    2

    History

    5

    7

    Other (Playback)

    1

    1

    Planning

    Orbit

    7

    19

    Attitude

    4

    9

    Maneuver

    5

    12

    Vehicle

    3

    5

    Schedule

    3

    13

    Evaluation

    4

    3

    Object services

     

    10

    13

    Infrastructure

     

    42

    11

     

     

     

     

    TOTALS

     

    100

    110

     

    The process of starting with the architecture and reusable components and building specific applications included the following steps:

    1. Determine COTS and legacy usage in the end system.

    2. Identify real-time user interface products and database implementations.

    3. Select a CORBA vendor to provide the intrasystem communication infrastructure.

    4. Address security needs by adding security layers or secure gateways.

    5. Determine how to extend and vary the CCT components by means of inheritance or the use of parameters. Replacement components may take the form of COTS products, legacy code, or hardware.

    6. Package the components into executable applications and allocate them to the nodes of the end system’s physical network.

     

    4.2.2   Architecture Evaluation

    Both the planning and execution architectures underwent explicit evaluation led by the SEI using the Software Architecture Analysis Method (SAAM) [Bass 98]. SAAM gathers together stakeholders of a system and lets them brainstorm scenarios of usage and modification that the software architecture of that system should support with little or no change. For CCT, SAAM produced scenarios of usage for ground-based spacecraft command and control systems. The scenarios that the CCT architecture supports conveyed an idea of the scope of the product line for which CCT should prove useful. Some of the scenarios were aimed at illuminating the production plan by which systems are built from the CCT architecture and components.

    Neither the planning nor the execution architecture evaluations revealed any modifiability (extensibility, variability) problems with CCT. That is, no scenario adopted by the evaluation group revealed any problems that would require the CCT program or a user more than a few person-months to correct. Most scenarios either were already accommodated by CCT variation points or would require only minor changes to support.

    For the planning subsystem architecture, the scenarios were as follows:

    • A user wants to include mission management (payload planning, for example). How would CCT planning interact with and support mission management?

    • The database is replaced with a new database technology for which the existing abstract interface is insufficient.

    • The network and/or some computers go down, but users want the planning processes to continue operation.

    • A user wants to manage a constellation of satellites (for example, global positioning system [GPS], communication satellite). Replace the vehicle model with an abstraction to represent a constellation.

    • A user chooses to integrate another orbit package to replace one provided by CCT. More specifically, a user integrates a proprietary orbit package with different inputs (for instance, orbit packages are frequently optimized for a particular orbit).

    • A user adds a new vehicle and associated "stuff" to existing system (for example, go from a spin-stabilized to a three-axis-stabilized vehicle). Use CCT to support up to six different vehicle families simultaneously from the same installation.

    • Add continuous orbit management to component categories in the planning domain.

    • How well will CCT support flexible scheduling using more on-board intelligence? Suppose some kind of request for service comes from the satellite to CCT, (for instance, a message that says a data buffer is full).

    • A user requests testing of a legacy database for inclusion in CCT.

    • How will a CCT component utilize a service that didn’t exist when it was built?
     

    For the execution subsystem architecture, the scenarios were as follows:

    • Integrate an inference engine to perform constraint analysis.

    • Inhibit commands.

    • Change the computer platform, operating system, ORB, ORB version, operating system version, implementation language, or methodology. Change from a relational database management system to an object-oriented database management system.

    • Add a new command source.

    • Add telemetry-command synchronization (closed-loop control).

    • A software routine called "via callback" hangs up (perhaps becomes stuck in an infinite loop). How does the system recover?

    • The operator reconfigures a set of components dynamically.

    • Add more automated, finer control to component categories in the execution domain.

    • Increase the number of simultaneous telemetry streams.

    • Send high-priority emergency commands to save a spacecraft (support command prioritization).

    • Build a minimal execution application and add to it incrementally.

    • A user evaluates a CCT component with respect to dependencies. A system architect assesses CCT architecture. An application architect assesses CCT status components.

    • Have the telemetry stream update the on-board processor’s memory map in real time.

    Future users of the CCT assets would benefit from the evaluations and the increased attention paid to the architecture. The inclusion of software architecture evaluations in the CCT development process highlighted the need for a shared architectural vision; the creation of the Architecture Model and the Reuse Guide was a response to that need to document the architecture to make it more comprehensible to the stakeholders. The CCT architecture working group watched over the growth of the CCT architecture, and members continue to provide guidance during asset evolution.

    CCT processes, as robust product line processes should be, are centered on the architecture. The Architecture Model and Reuse Guide emerged as focal points for the integration of the development processes for CCT assets and for target systems derived from those assets. The architecture focus for the development processes greatly improved the documentation of the architecture for both developers and users alike and did much to dispel the original notion that CCT is "just a toolkit."  

     

    4.3  Component Engineering

    Component engineering produced the components within the various component categories. These categories were identified in the Domain Definition Document and specified in the Domain Specification Document. The reusable components created by component engineering constitute the development view of the "4+1 view" model. Component engineering was also responsible for unit testing of the components. There were two potentially conflicting goals related to component engineering:

    1. The reuse of DCCS components: CCT sought to use components from this legacy system as a starting point.

    2. The creation of reusable CCT components: CCT assets could not be limited to capabilities of any individual system.

    Coupled with these goals, the CCT program needed to provide components to support the first real CCT user, the Spacecraft C2 System, and to do so in line with that project’s schedule. They took a number of measures to achieve these goals. To the best of their ability, they strictly adhered to their development plan in the planned increments so that the Spacecraft C2 Project would not fall behind schedule. They built components that were capable of handling the variation points in the domain specifications and that met the interface specifications dictated by the architecture. DCCS code that was used was wrapped, reengineered, or thoroughly reviewed to ensure that it would work in the CCT context. The Spacecraft C2 team was involved in the review of all component development work. The Web access to all of the CCT artifacts gave Spacecraft C2 early visibility into the progress of the component development effort.

    The components in each component category were implemented to have the interfaces and interconnection mechanisms called for by the software architecture. However, component interaction in products was still a concern: the interconnection mechanisms provided were so rich that product builders could easily assemble components into a configuration not envisioned by the CCT architects. To prevent this, the Reuse Guide established restrictions on mechanisms that product builders should use for component interaction. The descriptions of component interfaces were included in the Architecture Model. The Architecture Model also contained use-case maps to illustrate how components should interact during a scenario.  

     

    4.4  Testing: Application and Test Engineering

    Application engineering and test engineering together built the system test architecture and executed detailed test procedures. The test engineers validated CCT reusability, including the architecture and other assets.

    Recall that for CCT, application engineering was an internal reuse process that assembled a spacecraft command and control application from the reusable assets delivered by the other processes. For each CCT increment, this application was called a system test architecture. Test engineering used the system test architecture to perform the formal testing of CCT components. The formal testing complemented the informal testing done during component and application engineering.

    CCT defined four levels of testing:

    • Level 0: Unit testing of components (informal, performed by component engineering)

    • Level 1: Requirements verification of components and component categories (formal, performed by test engineering)

    • Level 2: Integration testing: The test architecture was used to test the integration of CCT into an application development effort and to exercise the variation points defined in the use cases (informal, performed by application engineering)

    • Level 3: System-level performance requirements verification (formal, performed by test engineering)

    Level 3 testing, in particular, was the formal test engineering effort used to demonstrate to both the quality assurance staff and the customer that system and performance requirements were met. Specific performance goals (for example, the ability of the architecture to handle some specified number of LRVs) were levied by satellite programs such as the Spacecraft C2 System.

    The application engineering team was, in effect, the first user of the CCT assets. Their validation of the assets complemented the activities of the domain engineering group. For each defined CCT increment, the application engineering process attempted to create a "complete" spacecraft command and control system from the CCT assets. The testing process facilitated the exercise of the defined variation points and tested system-level requirements (such as, overall system-level runtime performance). Figure 4 represents the process of using assets first for building the system test architecture, then for building the first operational system. After the testing of the assets created for that increment, the production plan provided the steps for producing the appropriate increment of the Spacecraft C2 System. The CCT approach repeated this step for each increment.

    Figure 4: Production Plan for Building Test and Operational Systems from Assets
    Figures in this file are displayed in a separate browser window. This window will remain open to display figures in this file, although it might be hidden behind other browser windows.

    The Test and Integration Plan described the test methodology in generic terms for the first increment and then in more specific terms on a per-increment basis. The test engineering team created test plans and procedures based on the use cases in the Domain Specification and demonstrated the portability of the CCT assets across several platforms. They created test cases (high-level preliminary descriptions of how requirements were tested) and test procedures (elaboration of test cases in terms of specific inputs and steps) for the formal tests. The component engineering team created level 1 test drivers, whereas the application engineering team created the executable test system for level 3 testing. CCT used a discrepancy report process to document problems that occurred during testing. The discrepancy reports documented and tracked all problems discovered during testing. This process was documented in the Test and Integration Plan. As part of the testing process, peer groups reviewed and prioritized test cases and procedures.

    The test engineering process validated CCT’s reusability. The process integrated CCT assets into a spacecraft command and control application. It also exercised the variability of the components by adding mission-unique extensions to CCT just as a real-world user would. The test engineering group participated throughout the CCT development cycle and in all the standing meetings. There was a conscious effort to ensure that CCT testing for each increment was not an after-the-fact process.  

     

    4.5  Sustainment Engineering: Product Line Evolution

    The sustainment engineering process included tasks to maintain and evolve the CCT assets. A sustainment engineering team was the primary point of contact after an increment was delivered. Their work began after formal testing and delivery of an increment. The input they received included the following:

    • Requirements that could not be met during initial component development were communicated. The team oversaw the process to consider these as inputs for inclusion in later increments of CCT.

    • Post-deployment problems (discrepancy reports) on assets. Specific CCT review boards determined the impact of proposed changes in the CCT software baseline and determined the action that the sustainment engineers should take.

    • Issues raised by potential use of CCT assets by targeted users. Many of these issues were taken up by the Architecture Group, but were not addressed during the CCT development.
     

    The CCT Sustainment Support Plan documented the process for sustainment engineering.

    The sustainment engineering team continues to deal with discrepancy reports to this day. In this maintenance role, sustainment engineering is building a community of CCT users who depend on CCT for a significant portion of their control channel needs. Multiple satellite programs have different, and possibly conflicting, requests for modifications of the CCT baseline. The sustainment activity continues to determine which modifications to support and which modifications may affect the architecture.  

     

    4.6  Documentation

    Because it created assets for reuse, the CCT program produced some documents that are not found in typical government procurement cycles. Documents that exist because CCT was a product line effort include the following, some of which have been mentioned above but are collected here to highlight the special role documentation plays with software product lines.

    • CCT Domain Definition: This document described the boundaries of the command and control product line and the functions that CCT addresses. The Domain Definition also included a glossary of terms and acronyms used within the CCT products.

    • Generalized Requirements Specification: This document captured common capabilities to be provided by the toolkit. It was produced by examining requirements from three different customer bases: DCCS, the Spacecraft C2 System, and SSCS.

    • CCT Domain Specification: This document provided a requirements analysis, employing use-case-driven methodologies and documented using UML.

    • CCT System Test Architecture: This document described a test system architecture (design and implementation) used to verify CCT functionality. Users could use this document as a starting point for their designs, as an ad hoc implementation for factory testing, and as an example of CCT component integration.

    • CCT Portability Demonstration Plan: This document contained an assessment of portability to selected non-supported operating systems.

    • CCT Sustainment Support Plan: This document detailed maintenance and evolution management for the CCT assets. Users who wish active involvement in the CCT’s management would participate through the described plan.

    • CCT Program Concept of Operations: This document described the life cycle of the CCT product line, the stakeholders who have an interest in the product line over its lifetime, and business concerns such as qualifying a new subscriber (user) for the product line.

    • CCT Architecture Model: This model provided a complete description of the architecture. Future product developers use it to evaluate CCT capabilities with respect to target program requirements, to determine how to plan their use of CCT assets, and to evaluate what changes and extensions they need to provide.

    • CCT Reuse Guide: This document described and provided examples of the steps necessary to build a product line application from CCT assets. It was the CCT production plan. The CCT Reuse Guide did not prescribe a development process, but rather provided the process basis for reuse analysis and design. Users could determine how best to incorporate this basis into their own development standards and practices.
     

     

     

     

    1 In CCT parlance, domain engineering is distinguished from architecture creation, whereas elsewhere the creation of an architecture is regarded as being part of domain engineering. In this narrative, the process activities relating to the definition and specification of the domain will be described as domain analysis and the architecture-creation activities will be treated under the heading of software architecture. In addition, the term "reference architecture" was used in the CCT effort to describe what we have called the product line architecture.  

     
    2 A notable feature of CCT architecture is an abundant use of architectural and design patterns, which provided a vocabulary for describing and reasoning about the architecture.  

     
    3 The tool didn't support the capture of additional CCT architectural representations. Layer diagrams, use-case maps, and overall execution and planning architecture diagrams were created, but were captured on the CCT Web site pages and other documents delivered to the NRO.  

     
     

     

    [Title Page]     [Abstract]     [Figures]     [1 Introduction]    
    [2 Contextual Background]     [3 Launching CCT]    
    [4 Engineering the CCT Core Assets]     [5 Managing the CCT Effort]    
    [6 Early Benefits from CCT]     [7 Lessons and Issues]     [8 Summary]    
    [References]     [DTIC page]     [PDF file]