Program managers have better success managing ground systems acquisitions when they understand the inherent cost and risks early in the process. Aerospace has developed a means of identifying such risks while generating meaningful estimates of system and component costs.
The Ground Systems Team is a specialized subgroup within the Concept Design Center created to develop and evaluate ground system architectures. Using this resource, Aerospace provides top-level designs for proposed ground stations as well as individual models that estimate software, staffing, processing, communications, facilities, and cost requirements. Studies have been conducted for components of AFSCN, GPS, Space-Based Infrared System, military satellite communications, and numerous classified programs.
The process begins with a model description. Each ground system node (e.g., mission control station, backup station, depot support facility) is characterized in terms of five subsystems: processing and information architecture, communications architecture, software, staffing, and facilities. The functions performed at each node are defined on a master function list, organized in terms of mission processing, mission management, ground command and control, ground system management, support, facility management, and miscellaneous functions.
The function-to-node mapping provides the top-level functional description, while the list and characteristics of the links between nodes help define the information and communications architectures. After the functions to be performed at a particular node are determined, complexity factors are assigned to help guide the design of the software subsystem. All the subsystems are then replicated for the other nodes, allowing customization of individual node characteristics.
Modeling of the five subsystems begins simultaneously, but some modules require inputs from others. For example, the initial staffing estimates provide the information architecture module with information on the number of users accessing each of the internal local area networks, allowing these networks to be partitioned in a reasonable manner. With the specification of the local area networks and the internode connections, the communications and processing modules can prepare lists of the necessary hardware. The staffing, communications, and processing information are fed to the facilities module to produce facility size estimates. Results from all five subsystems provide inputs to the cost module.
The process can be applied to numerous architectures to assist in architectural trades. In this case, a baseline architecture is first developed as a basis for comparison. Multiple ground architectures from competing contractors can be assessed based on such differences as manual versus automated implementation, redundant versus nonredundant processors, and other variations in technology. These trade-off studies indicate cost differences between competing architectures and identify risk areas, which in turn can result in further studies or provide a rationale for choosing one design over another.
The typical process used to conduct a study consists of three phases: predesign, design, and documentation. During the predesign phase, which can last from 6 to 12 weeks, the program manager provides relevant data, such as a concept of operations, a requirements specification, and any estimates of software size and staffing levels. Aerospace evaluates the proposed capabilities and then characterizes the system architecture. After a preliminary master function list and node structure are designed, a set of system and model assumptions are developed to constrain the modeling effort to only those data deemed relevant. The emphasis during this phase is on ensuring that the problem is scoped correctly.
During the design phase, which generally lasts from 2 to 4 days, the architectures and assumptions are further refined. The nodes are populated, and the final ground system model is reviewed to ensure that the results meet expectations.
Finally, Aerospace produces documentation outlining each of the modeling assumptions, definitions of the master function list and nodes, and data from each of the models. Examples of model outputs would include estimates of software size, facility sizes, and staffing needs for each node. Development costs and operations and maintenance costs are also provided for each node and for the ground system as a whole. The documentation would include a collection of mission requirements and study assumptions, an executive summary, functional and cost comparisons, and conclusions. More detailed reports can discuss the design, architecture comparisons, and risk factors for each subsystem. If desired, the cost section can describe the methodology and break down costs by architecture, phase, and work breakdown structure, with cost comparisons between nodes or alternative architectures. Because all studies are fully documented, the models themselves can be fine-tuned for additional studies.
—Donald E. Town