Cost is a major concern and a driving factor in the development and operation of a system. Also of concern are the requirements of the system being planned and their relation to overall cost. Expressing this relationship between cost and requirements is not a simple problem. This paper will summarize the results of the most recent efforts to trace requirements to estimated costs of the Earth Observing System Data Information System (EOSDIS). These approaches use Commercial-Of-The-Shelf (COTS) tools to perform a combination of parametric and performance modeling to estimate costs including distribution, staffing, data production, for varying system architectures. The paper will also describe how some tools offer a unique advantage to trace requirements throughout the model. These recent efforts in cost modeling provide additional insight and justification into the EOSDIS approach.

Costs within the EOSDIS, as in any system, can be divided into two major categories: development costs and operational costs. Three major studies have been conducted to quantify these costs and associate them with system requirements. First, an Independent Cost Evaluation (ICE) was conducted to quantify and justify development costs of EOSDIS. A second effort calculated operational costs for a subsystem of EOSDIS, called Distributed Active Archive Centers (DAACs) and produced the EOSDIS Operational Cost Model. A third effort is now underway to produce an EOSDIS Lifecycle Cost Model that will borrow from the previous work and address both fixed and variable costs of the entire EOS Ground System (EGS), which is composed of EOSDIS and supporting ground system elements. In addition to estimating cost, this effort will demonstrate the relationship of system requirements to system design and system cost.

The EGS is shown in Figure 1 at a high level. It is composed of the EOSDIS, customers accessing the data, and elements involved with data receipt like the Space Network, and the EOS ground stations. EOSDIS comprises the EOS Data Operations System (EDOS), and a number of DAACs each with their own specialty in earth science. The EDOS performs Level 0 processing, stripping all transport protocol, and ordering the data packets for further processing. The Level 0 data sets produced by EDOS are then sent to the DAAC for Level 1 through Level 4 processing and final distribution to customers. The software associated with the DAACs is the Science Data Processing System (SDPS). The EOS Operations Center (EOC), together with widely distributed Instrument Support Terminals (ISTs), controls the operation of the spacecraft. The ISTs are located in Science Computing Facilities (SCFs) at the customer sites, and provide scientist input to the mission planning process. The software developed for this system is termed the Flight Operations Segment (FOS). The Communications and Systems Management Segment (CSMS) refers to software that performs systems monitoring of EOSDIS housed in the System Management Center (SMC) and also in the DAACs. Together, the FOS and SDPS and CSMS are called the EOSDIS Core System (ECS). The EOSDIS Backbone Network (Ebnet) provides communication support between EGS elements. The NASA Science Network (NSI) provides customer access to the DAACs via the Internet.

The ICE effort was commissioned by NASA management to justify costs of EOSDIS development. A group of consultants coordinated by Intermetrics was tasked to perform independent evaluations of EOSDIS costs. A leader in the field of estimation of software development costs, Software Productivity Research (SPR), turned its attention to EOSDIS. In particular, they examined the fixed costs of software development for the ECS. The heart of the software analysis centered on the concept of function point analysis to estimate system cost. This is a well known approach pioneered by IBM and used within the software industry of the past 20 years. It attempts to measure the functionality of a system, not the number of source lines.

In conducting the cost analysis for the ECS, SPR collected information through a series of management interviews and assessment questionnaires for each of the 39 subsystems included in the multiple releases of the system. Data was gathered on sizing in the form of function point counts skills, technology, process, and development environment. Once these data points were understood, the results were compared to a database of similar projects using a COTS tool called Checkpoint, and cost was derived from the data. NASA maintains a copy of this tool to perform similar estimates in the future.

Segment testing, both integration and acceptance performed by Hughes, the prime contractor for development of the ECS, was estimated as a percentage of the overall development based on industry averages for large government and military projects. Sustaining engineering was estimated using Checkpoint. The final step in developing the ECS cost estimate was to apply multiple cost factors to the projected estimate. These factors included industry average salary rates, burden rates, and award fee percentages.

Hardware estimates were conducted by the Gartner Group, a world leader in analysis on hardware, software, and information technology. They examined the Bill of Materials (BOM) associated with several EOSDIS facilities to track the hardware purchase of the project. This BOM listed workstations, servers, semiconductor memory, disk storage, and network interfaces and devices. The analysis started with FY1995 prices and was then projected out until FY2000. The Gartner group performed this extrapolation based on recent history modified by expert opinion and considered the possibility of revolutionary changes in technology.

ICE software development estimates for ECS fell within 4% of NASA estimates. The ICE study projects that hardware purchases will be about 25% less than currently estimated by NASA. Overall, the ICE effort showed that up-front, development EOSDIS costs were very reasonable when compared to other similar systems.

The EOSDIS Operational Cost Model was developed as a tool to determine the effects of fundamental architectural changes upon EOSDIS subsystem and system costs and for estimates for budget purposes.

The EOSDIS cost model contains two distinct components. One calculates communications costs and the other calculates operational staffing costs for the DAACs of the EOSDIS. The context of the model is shown in Figure 2.

The method undertaken to calculate transport costs (e.g., communications costs) associated with DAAC configurations was first to obtain the projected data volumes required for product generation. It is often a function of inter-DAAC data dependencies when data processed at a DAAC may be needed by other DAACs for generation of their products. This leads to increased communications connectivity and bandwidth to handle increasing data volumes for topologies with larger numbers of DAACs The communications costs were arrived at using a Commercial-Off-The Shelf (COTS) network modeling software package, Mind-Data, which utilized long distance tariffs and optimal routing algorithms to determine costs. The current operational DAAC network topology shown in Figure 3 is an example that illustrates inter-DAAC connectivity for processing and Quality Control (QC) nodes for the Version 0 EOSDIS. The diagram shows only the communication links that experience the highest traffic based on the Mind-Data model's optimization with dedicated leased lines for long-haul traffic for QC element of the system. The three QC nodes at the University of Miami, University of Montana and at the University of Wisconsin were selected by the model as the best locations most suited for placement of switches to handle high volumes of data.

Costs associated with the DAACs, were determined by identifying a set of static workload parameters and operational functions staffing requirements that were designed to look at nodal variations in the architecture. The workload parameters driving the models consisted of products; science instruments; data streams; granules produced each day; and gigabytes distributed over the course of a year of actual operations. The functional areas for DAAC operations comprising staffing were: management, science oversight, development and engineering, system and database administration, mission support, product generation, ingest and archive, distribution, and user services

The workload parameters were selected as the direct influencing factors for each individual category of the staffing functions. The equations developed for the staffing portion of the cost model were expressed in a weighted relationship of the driving workload parameters with the separate staffing functions. A minimum staff, based on FY1995 historical DAAC data was established and the model was used to produce estimates for FY2004 staffing requirements. Mathematical equations along with parametric data values were inserted into EXCEL spreadsheets and costs were calculated for the different number of DAAC network topologies examined.

Scenarios were developed for EOSDIS networked architectures that ranged from a two-hub arrangement, to the existing Version 0 DAAC baseline configuration, and to a larger set of 27 processing nodes that represented a hypothetical federated system. These configurations were considered to be discipline specific with respect to processing and generation of different levels of scientific data products. Data used for values of the DAAC staffing category parameters were obtained from the records of DAAC managers for a year of actual operations. The workload parameter values were obtained from baselined database information compiled under the direction of the EOSDIS scientists Product Ad Hoc Working Group.

Costs for hardware, software, and facilities were not included in this baseline operational cost model since research indicated that they were not significant in terms of total operational distributions costs over time, as were communications and staffing costs. Emphasis was placed on assessment of the variation in cost drivers that exhibited sensitivity to changes in location, size, and numbers of EOSDIS processing centers.

As explained previously, the Independent Cost Evaluation validated the development costs of EOSDIS by showing that they compared favorably with other government and commercial systems of similar functionality. The EOSDIS Operational Cost Model determined a set of variable costs associated with science operations and showed that the costs increase with the number of science data processing facilities.

While calculating development and variable costs, both studies did not attempt to demonstrate the direct connections between cost and requirements. A new study is underway to build a model that will relate system requirements with the costs of the EOSDIS during its lifecycle. When complete, it will then be possible to show the effects of changing requirements on overall EOSDIS costs.

Generally, the development, implementation, and operation of EOSDIS can be divided along a Work Breakdown Structure (WBS) by subsystem components, tasks, and project lifecycle activities as shown in Figure 4. For Example, EOSDIS could be broken down into EDOS which is then broken down by discipline showing project management; systems engineering; development; COTS; integration and test; training, and operations. In contrast with the WBS, is a Product Breakdown Structure (PBS) shown in Figure 5. EOSDIS is divided by element as before, but the following levels map to element subsystems. In the case of EDOS, this means a Level Zero Processing Facility (LZPF), three Ground Station Interface Facilities (GSIFs), and a Data Archive Facility (DAF). These subsystems have subsystems termed Configuration Items (CIs). These CIs are the hardware and software systems that comprise a subsystem. Cost modelers work with the hierarchical PBS in a bottoms-up manner defining, quantifying, and estimating cost for a configuration. Modelers will turn to a variety of methods to model these costs including statistical forecasting, statistical correlation, and discrete event simulation. As estimated under final costs, the PBS will be mapped and added to costs estimated under the WBS to obtain total lifecycle costs.

Without a COTS tool to assist modelers, developing the EOSDIS Lifecycle cost model would be expensive and time consuming. To facilitate this effort, modelers have selected a number of COTS tools to assist them. One such tool, the System Level Automation Tool for Engineers (SLATE), was originally developed for Texas Instruments as an automated systems engineering tool. It will allow cost modelers to organize system requirements the WBS and the PBS. SLATE is packaged with an object-oriented database which gives users the ability to import system documentation and link requirements with any portion of a hierarchical structure. Modelers can also directly access the SLATE database and populate it with results from other statistical or discrete-event modeling tools and link these results to calculated system costs.

An example, diagrammed in Figure 6, shows an EOSDIS requirement to archive all Level 0 data produced by instruments on board the EOS spacecraft. Using SLATE modelers attach the archive requirement to the element of the PBS that performs the archiving function. To quantify the cost of this requirement, cost modelers import data from performance models that estimate the number of tapes necessary for Level 0 production. Finally, the cost information is mapped to the WBS. With this information cost modelers can then estimate the cost of the tapes and the cost of distribution to the archival site and compare that cost to previous estimates.

Other cost categories will be dealt with in a similar fashion. Estimates of software development will use function point analysis theory combined with statistical correlation studies. Operational and hardware costs will be scoped using statistical forecasting methods and discrete-event simulations. Throughout the process modelers are in constant contact with knowledgeable sources within the project and within the community of users. Final validation of the cost modeling effort will also be conducted in accordance with domain knowledge from these same sources.

Developing the connection between requirements and cost quantification is not a trivial problem. Models customized for unique applications must often be changed when topologies change, so ad hoc methods do not work on a consistent basis when applied to different topologies. This paper has shown that the use of COTS tools enable modelers to develop system representations that are more adaptable to change and are more flexible in their application. The efforts undertaken in EOSDIS cost modeling indicate that by using available COTS tools, an integration of requirements to function, and hence to costs, can be realized.

1. IFPUG (1994). International Function Point Users Group "Function Point Counting Practices Manual" Release 4.0

2. Intermetrics (1996). Independent Cost Evaluation (ICE) of the EOSDIS, Greenbelt MD

3. NASA (1996). Models of Staff and Communications Costs for Different DAAC Configurations. Contract NAS5-31500, Task Assignment 76-001. Greenbelt, MD: NASA.

4. NAC (1995). MIND-Data for Windows, User's Guide. New York: Network Analysis Center.

5. Microsoft (1992). Microsoft Excel, Users Guide 1. United States: Microsoft Corporation.

6. T.D. Technologies, Inc. (1995). Slate,Users Guide, Version 2.1, Dallas TX