(U) NGA_Data Item Description for Cost and Tech Data Report.pdf

UNCLASSIFIED

CTDR DID

DATA ITEM DESCRIPTION (DID) FOR

COST & TECHNICAL DATA REPORT

OFFICE OF THE NATIONAL GEOSPATIAL-INTELLIGENCE AGENCY

COST ASSESSMENT AND PERFORMANCE EVALUATION

(NGA CAPE)

VERSION 1.0

Table of Contents

1. Introduction

1.1 Data Use

1.2 Data Provider

1.3 Data Submission Process

1.4 Data Collection Intervals

1.5 Data Delivery Format

1.6 Data Content

1.7 Data Format

1.7.1 Cost Data Format 5

1.7.2 Year Data Format 5

1.8 Data Content

1.8.1 General Header and Contact Information Requirements 5

1.8.2 Color Coding 6

1.8.3 Dropdown Lists 6

2. Program Information

2.1 Scope

2.2 Instructions

3. Contract Information

3.1 Scope

3.2 Instructions

4. Work Breakdown Structure

4.1 Scope

4.2 Instructions

5. COTS-GOTS

5.1 Scope

5.2 Instructions

6. Agile Measures

6.1 Scope

6.2 Instructions

7. Agile Detail

7.1 Scope

7.2 Instructions

8. Code Counts

8.1 Scope

8.2 Instructions

9. Data Management

9.1 Scope

9.2 Instructions

10. Database

10.1 Scope

10.2 Instructions

11. Discrepancy Reports (DR)

11.1 Scope

11.2 Instructions

12. Appendix

12.1 Acronym List

1. Introduction

This document serves as a guide for providing information technology (IT), software, and ground segment cost and cost-related data for programs as defined in Intelligence Community Directive (ICD) 109, “Independent Cost Estimates”. The data workbook is used for any type of information technology, software , and ground segment program from beginning of development through operations and maintenance (O&M). This data item description is written to accompany the MS ExcelTM file, NGA-CTDR-Template-Final_(U) to be completed for data purposes.

Embedded instructions are also provided within the individual data sheets of the template for enhanced usability.

1.1 Data Use

When actual (historical) data on current and legacy systems are prepared in accordance with these instructions, the data are used for IC resource analysis efforts which may include development/update of cost estimating tools and methods, analysis of alternatives (AoA), and life cycle cost estimates to support NGA policy requirements.

1.2 Data Provider

Hereafter, the person or contractor completing the data workbook will be referred to as the data provider.

Whenever possible, the data provider shall be a person or persons actively performing contracted work on the named program, and more specifically on the work area in each named data sheet.

Each program office is expected to provide all relevant datasheets to each prime contractor and subcontractor whenever possible so that data may be provided by personnel actively performing work on contract.

1.3 Data Submission Process

The data provider will submit all data workbooks to NGA CAPE.

Upon successful receipt of the data submission, NGA CAPE will provide feedback to the data provider within 30 business days. Feedback may include, but is not limited to, requests for clarification, additional information or data, or re-formatting.

1.4 Data Collection Intervals

Unless specified otherwise, the data provider will deliver data annually at a pre-determined time agreed to by NGA CAPE and the program offices.

Additionally, based on scope of specific software development efforts, NGA CAPE may request data after a major software release. These requests will be a coordinated effort among NGA CAPE and the respective program offices.

1.5 Data Delivery Format

The data provider will provide responses in electronic media compatible with Microsoft ExcelTM or WordTM as required by the individual datasheet. Please see each individual datasheet for permissible format changes such as adding or deleting rows and columns.

The workbook tabs shall be used with the exception of cases where NGA CAPE and the respective program offices identify and agree to alternative forms of submission. Such acceptable alternative submissions may include, but are not limited to, an existing Bill of Material, Unified Code Counter-Government (UCC-G) generated outputs, an Agile system export (i.e., Jira, VersionOne, or Redmine), or billing statement (e.g., Cloud Service Provider).

The data provider shall classify completed data sheets as required in accordance with existing classification standards.

The data provider shall adhere to the specific instructions contained in this document.

The data provider shall complete all applicable data sheets. If an entire data sheet is not applicable, then in the first data field, enter “Data sheet is not applicable”. For cases where only certain fields are not applicable, the data provider should enter N/A for those text data fields.

1.6 Data Content

Unless specified otherwise, actual data values shall be provided, not estimated.

The data provider will complete a datasheet for each individual site if multiple sites exist. The data provider will additionally provide a complete set of datasheets for each configuration. Datasheets should be organized in accordance with the NGA CAPE provided Cost Element Structure (CES) or contractor’s work breakdown structure

(WBS).

1.7 Data Format

1.7.1 Cost Data Format

When completing the workbook, the data provider shall not inflate dollars. Rather, all data shall be specified as either current or then year dollars.

1.7.2 Year Data Format

All data that requires a date shall be provided in the following format: (MM/DD/YYYY).

1.8 Data Content

1.8.1 General Header and Contact Information Requirements

Some cells, including column headings, may contain explanatory notes, indicated by a red triangle in the upper right corner of the cell. Select the column heading cell to read the column-specific instructions. Other cells also may contain explanatory notes and comments. Mouse-over and/or select the cell to read the cell-specific instructions.

For each sheet, provide the following contact information:

a. Name: Identify the name of the individual who prepared the datasheet. If NGA CAPE has questions about a sheet, this is the person to whom the questions will be directed.

b. Phone Number (Secure): List the secure (if applicable) phone number of the preparer.

c. Phone Number (Non-Secure): List the non-secure (commercial) phone number of the preparer.

d. Organization: Indicate the name of the organization or company (or companies, if the preparer is a subcontractor) with which the preparer is affiliated.

e. E-mail: List the secure/unsecure e-mail address (if applicable) for the preparer. Use “N/A” if this information is not available.

f. Date Information Provided: Enter the date the datasheet was provided.

g. As of Date Information: Enter the as of date for the data in the datasheet. The as of date specifies the date through which the data is collected.

h. Site: Enter the site or location name for the place where the work described is being done.

i. Standard Hours: Provide the standard annual hours used for a full-time equivalent (FTE). For example, 1860 or 1920 hours per person-year.

1.8.2 Color Coding

The general color scheme within the data workbook is as follows:

• Dark blue cells are title fields for the datasheets

• Light blue cells are cells that require data entry

• Orange cells are cells that contain drop down lists

• Peach cells are calculated cells that are automatically populated from other entries

1.8.3 Dropdown Lists

Dropdown lists have been included in some cells in the datasheets where entries have been standardized for enhanced usability and data integrity. The source lists for these dropdowns are stored in the “Picklist Tables” sheet at the back of the workbook for reference.

2. Program Information

2.1 Scope

The purpose of this section is to capture the top-level data for each program being reported.

This datasheet shall be completed by the contractor associated with the program being reported.

2.2 Instructions

The data provider shall provide the following:

a. Program Name: Official program name for the development/maintenance effort

b. Program Functions: Each function being developed should be identified and captured within the functions/Subsystem functions identified below. NGA CAPE recognizes that some programs include multiple functions. The description of program functional capabilities to support the program should be reported. For those programs with multiple functions, identify each function separately.

Function Subsystem Function

Data Analysis & Exploitation

The Analysis and Exploitation function is responsible for examination of mission data (dissection, investigation, cross-referencing, etc.) and conversion of this data into finished intelligence. This includes manual and automated integration, evaluation and analysis of all available data. The process is completed with the preparation of intelligence products that include assessments of events and judgments about the implications of the information.

The Analysis and Exploitation subsystem functions include:

• Manage Need

• Manage Analytic Mission

• Perform Analysis

• Detection

• Change Detection

• Multi-INT Data Integration & Fusion

• Classification

• Identification

• Association

• Tracking

• Forecasting

• Tipping

• Exploit Data Sets

Command & Control/Mission Management

The Command and Control (CC) / Mission Management (MM) function provides CC/MM for the vehicle and payloads. CC decodes, demultiplexes, and decrypts telemetry, generates and encrypts commands for transmission and processes tracking data to generate ephemeris. Provides the capability to prepare and output commands to receive and process telemetry, tracking, and other non-mission data from the vehicle.

While MM functions receive tasking, generates and provides the system and mission plans, schedules and timelines for the vehicle and ground segment(s).

The Command and Control subsystem functions would include:

• Schedule Execution

• Command Generation

• Uplink Data Generation

• Telemetry Processing

• State Management

• Vehicle Maintenance

• Space Vehicle Simulation

The Mission Management subsystem functions would include:

• Task Management

• Mission Analysis

• Mission Plan Generation

• Collection Schedule Generation

• Real Time Schedule Management

• Orchestration

• Mission Execution

Dissemination

The Dissemination Function includes the timely distribution of intelligence products to departmental and agency intelligence consumers in a suitable form.

The Dissemination subsystem functions would include:

• Manage Enterprise Services

• Measure Content Access

• Visualize GEOINT

• Organize Content

Ground Terminals The Ground Terminal (GT) function receives, demodulates and conditions telemetry, tracking, command and mission (payload) data. In addition this system generates the radio frequency (RF) uplink, accepts tracking and command signals, and modulates them onto the RF uplink.

The Ground Terminal subsystem functions would include:

• GT Foundation / Field

• GT Antenna (a...n)

• GT Optical Communication Assembly (OCA)

• GT RF and Digital Electronics (GTEL) (Band a...n)

• GT Baseband Network and Data Handling Equipment (GTNW)

• GT Monitor and Control (GTMC)

Infrastructure & Framework

The Infrastructure & Framework (I&F) function includes hardware and/or software that supports multiple functions, supports engineering development of administrative networks, and/or supports development of systems required to interface to other ground segments (other programs) at the same Ground Site.

The Infrastructure & Framework subsystem functions would include:

• Compute

• Record

• Store

• Routing

• Distribution

• Service Broker

• Sharing

• Fusion

• Tools

Mission Data Processing

The Mission Data Processing function decodes, demultiplexes, decrypts and processes Mission data from the Payload(s) and provides usable data for analysis and exploitation.

The Mission Data Processing subsystem functions would include:

• Data Conditioning

• Mission Data Processing

• Processing Workflow Management

• Mission Data Management

• Quality Assurance

Tasking & Management

The Tasking and Management function includes generating requests for data, delivering instructions to a collection element, and subsequently tracking the fulfillment of each request.

The Tasking and Management subsystem functions would include:

• Manage Source Strategies

• Monitor Strategy Execution

• Determine Value

• Manage Supplier Needs

• Manage Source Models

c. Secondary Program Functions: Reference Section 2.2b. for Program Functions

d. Protection Level: The description of the appropriate Protection Level (PL) for Information Systems (IS) based on the required clearance(s), formal access approval(s), and need-to-know of all direct and indirect users who receive information from the IS without manual intervention and reliable human review. This indicates an implicit level of trust that is placed in the system’s technical capabilities.

PL1

An IS operates at Protection Level 1 when all users have all required approvals for access to all information on the IS. This means that all users have all required clearances, formal access approvals, and the need to know for all information on the IS.

PL2

An IS operates at Protection Level 2 when all users have all required formal approvals for access to all information on the IS, but at least one user lacks administrative approval for some of the information on the IS.

This means that all users have all required clearances and all required formal access approvals, but at least one user lacks the need to know for some of the information on the IS.

PL3

An IS operates at Protection Level 3 when at least one user lacks at least one required formal approval for access to all information on the IS. This means that all users have all required clearances, but at least one user lacks formal access approval for some of the information on the IS.

PL4

An IS operates at Protection Level 4 when at least one user lacks sufficient clearance for access to some of the information on the IS, but all users have at least a Secret clearance.

PL5

An IS operates at Protection Level 5 when at least one user lacks any clearance for access to some of the information on the IS.

Unknown Unknown Protection Level

e. Domain Level: Clearance Level for Domain

SECRET

TOP SECRET

CAP/SAP

f. # of Users: The number of active users on the Domain

g. # of Accounts: The number of accounts registered on the Domain

h. Retention Requirements: The requirement for retention of data for the program (Years)

i. Schedule Milestones: List of relevant program milestones

• For example (but not limited):

□ Authority To Proceed (ATP), System Design Review (SDR), System Requirements Review

(SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Operational Readiness Review (ORR), Spiral drop dates, Release dates, etc.

j. Current Schedule: The current dates (actual or planned) for the provided milestones (MM/DD/YYYY)

k. Comment/Notes: Any comments/notes necessary to provide clarification, additional detail, or context

l. Program Name: Official program name for the development/maintenance effort

m. Contract #: Regarding the prime contractor, the base or option contract number

n. Release / Delivery: Regarding the subsystem, the date that the product was released or delivered:

MM/DD/YYYY

o. Subsystem: Identify the top-level CSCI or components of the computer application

p. Total Users: The number of total users of the subsystem on the Domain

q. Number of Interfaces: The number of interfaces of the subsystem on the Domain

r. Number of Legacy Systems Replaced: The number of legacy systems replaced for the subsystem on the

Domain

Provide information consistent with DoDAF SV-6 Reporting Requirements:

s. Nature of Transaction: Type, Event, Interoperability Level, Criticality

t. Performance Attributes: Periodicity, Timeliness, Throughput, Size

u. Security: Protection, Classification, Caveat, Releasability, Security Standard

v. Data Description: Name/ID, Content, Format Type, Media Type, Accuracy, Units of Measurement, Data

Standard

w. Information Assurance: Access Control, Availability, Confidentiality, Dissemination Control, Integrity, Non-

Repudiation

x. Reference Document Name: Any applicable reference documents to refer

y. Comments/Notes: Regarding each subsystem, any comments/notes necessary to provide clarification, additional detail, or context. Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

3. Contract Information

3.1 Scope

The purpose of this section is to capture the contract data for each program being reported. This datasheet will provide insight into the various prime and sub contracts associated with each program.

An Engineering Change Proposal (ECP) is the management tool used to propose a configuration change to a government baseline performance requirement or configuration documentation during system acquisition.

The purpose of this section is to additionally capture the ECP data for each program being reported. This data table will provide insight into why a contract baseline was modified and from which future cost estimating analogies can be developed.

This datasheet shall be completed by the contractor associated with the program being reported .

The following instructions typically apply to cost and cost-related information provided for an actual system acquisition contract (referred to hereafter as the “contract”). The term “contract” may refer to the entire projected system or portions (contracted effort) of the system defined in other guidance documents. In some cases involving future systems, the scope of the projected contract may not be completely defined.

3.2 Instructions

The data provider shall provide the following:

a. Company Name: The name of the prime contractor company

b. Location of Contractor: Location of the prime contractor (City, State)

c. Contract Type: Regarding the prime contractor, indicate the type of contract identified below.

CPAF

CPFF

CPIF

CPIF (PI)

CS

FFP

FPIF

FPIST

FPIST (PI)

FPIFT (PI)

FPAF

FP/EPA

FP/PPR

FFP/LOET

FPIC

IDIQ

LC

T&M

OT (Other Transactions)

Other (Explain in Comments)

d. Contract Start Date: Regarding the prime contractor, the date that the contract started: MM/DD/YYYY

e. Contract End Date: Regarding the prime contractor, the date that the contract ended: MM/DD/YYYY

f. Total Contract Value: Regarding the prime contractor, the total contract value ($)(includes incentives and options)

g. % Subcontracted (according to dollar value): Regarding the prime contractor, % of contract that is subcontracted out to other parties

h. Comments/Notes: Regarding the prime contractor, any comments/notes necessary to provide clarification, additional detail, or context. Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

• For example (but not limited to):

o Another contract paid for a portion of development, Award of an option early in development changed development schedule/scope, Impacts of GFE/GFI

i. Contract #: Regarding the prime contractor, the base or option contract number

• The Row 18 should contain base contract data

• The Rows 22-26 should contain Option data

j. Base/Option Number: Regarding the prime contractor, the base and option years of the contract

k. Contact Start Date: Regarding the prime contractor option, the date that the option period of performance started: MM/DD/YYYY

l. Contract End Date: Regarding the prime contractor option, the date that the option period of performance started: MM/DD/YYYY

m. Option Executed: Regarding the prime contractor, has the option of the contact been executed?

Yes

No

n. Hours/FTE: Provide the number of hours per FTE used on the contract

• For example:

o 1860 hrs.

o 1920 hrs.

o etc.

o. Comments/Notes: Regarding the prime contractor, any comments/notes necessary to provide clarification, additional detail, or context. Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

• For example (but not limited to):

□ Another contract paid for a portion of development

□ Award of an option early in development changed development schedule/scope

p. Company Name: The name of each sub-contractor supporting the given contract number, one per row.

q. Location of Contractor: Location of each sub-contractor (City, State)

r. Contract Type: Regarding sub-contractor(s), indicate the type of contract identified below. Sub-contracts only need to be addressed if the contract’s value exceeds $50M in TY$s. This level of cost reporting will be discussed and agreed to between the NGA CAPE staff and the program office and can be tailored to meet necessary reporting requirements.

CPAF

CPFF

CPIF

CPIF (PI)

CS

FFP

FPIF

FPIST

FPIST (PI)

FPIFT (PI)

FPAF

FP/EPA

FP/PPR

FFP/LOET

FPIC

IDIQ

LC

T&M

OT (Other Transactions)

Other (Explain in Comments)

s. Contract #: Regarding each sub-contractor, the contract number

• The 1st row should contain base contract data

• The additional rows should contain Option data

t. Contract Start Date: Regarding each sub-contractor, the date that the contract started: MM/DD/YYYY

u. Contract End Date: Regarding each sub-contractor, the date that the contract ended: MM/DD/YYYY

v. Total Sub-Contract Value: Regarding each sub-contractor, the total contract value ($)

w. Comments/Notes: Regarding each sub-contractor, any comments/notes necessary to provide clarification, additional detail, or context. Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

• For example (but not limited to): Another contract paid for a portion of development, Award of an option early in development changed development schedule/scope

x. Contract #: Regarding each sub-contractor, the contract number (from Base to Option)

• The 1st row should contain base contract data

• The additional rows should contain Option year data

y. Base/Option Year Number: Regarding each sub-contractor, the base and option years of the contract

z. Contact Start Date: Regarding each sub-contractor, the date that the contract started: MM/DD/YYYY

aa. Contract End Date: Regarding each sub-contractor, the date that the contract started: MM/DD/YYYY

bb. Option Executed: Regarding each sub-contractor, has the option of the contact been executed?

Yes

No

cc. Hours/FTE: Provide the number of hours per FTE used on the sub-contract o 1860 hrs.

o 1920 hrs.

o etc.

dd. Comments/Notes: Regarding each sub-contractor, any comments/notes necessary to provide clarification, additional detail, or context. Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

• For example (but not limited to): Another contract paid for a portion of development, Award of an option early in development changed development schedule/scope

ee. Contract: Regarding each contract on the program, the contract number

ff. Contact Line Number: Regarding each contract, all of Contract Line Item Numbers (CLINs) related to the contract

gg. Contract Line Number Value: Regarding each contract on the program, the value of the CLIN ($) (with

Fee)

hh. Description: Regarding each contract on the program, details of the scope of the associated CLIN

ii. Comments/Notes: Any comments/notes necessary to provide clarification, additional detail, or context.

Describe any contractual situations that should be taken into account when evaluating the total cost of the program.

jj. Program Name: The name of the program for which the ECPs are being reported

kk. Contract #: The contract number (This should match a contract number listed in section (i) of the Contract

Information datasheet)

ll. ECP Number: The number assigned to the ECP based on program or contract naming conventions

mm. ECP Description: The description of the activities performed as part of the Engineering Change Proposal

(ECP)

• In addition to the ECP title, please provide information regarding the ECP scope and effort. Items may include, but are not limited to, performance upgrades or requirement changes, additional software or hardware development efforts, or descriptions of additional technical scope. Note any special circumstances.

• Include the unique ID of the agency Request For Change (RFC), if any, that triggered the ECP

nn. ECP Type: Type of ECP associated with changes to the contract baseline

Cost Overrun Overruns that are recognized and authorized via increasing contract value

Engineering Change Order Changes via Engineering Change Order (ECO), Engineering Change Proposal (ECP), Contract Change Proposal (CCP), or Special Contract Requirement (SCR)

Estimation Revision Estimating revision and proposal pricing errors

Schedule Impact Government-directed schedule slips and/or negotiated schedule extensions indirectly related to requirement and/or technical changes

Special Study Special studies and all related items

Other

Including, but not limited to, requests for equitable adjustments, economic price adjustments, GFE/GFP to CFE/CFP cost, overhead rate adjustment, inflation, costs due to natural disasters, unforeseen events not listed above

oo. ATP Date: The date upon which the ECP received authority to proceed (ATP) (MM/DD/YYYY)

pp. Negotiated Duration of ECP: Provide the negotiated duration (in months) of the ECP

qq. Negotiated ECP Value: The value of the ECP negotiated between the Government and the Contractor

4. Work Breakdown Structure

4.1 Scope

The purpose of this section is to capture the Contractor cost/effort for the program being reported at the Work Breakdown Structure (WBS) level.

This datasheet can be completed by the prime contractor and associated subcontractors.

4.2 Instructions

The data provider shall provide data by the WBS provided in the NGA CAPE datasheet. For clarification, definitions are provided for each WBS line item.

5. COTS-GOTS

5.1 Scope

For the purposes of this datasheet, hardware is defined as the machines, wiring, and other physical components of an information technology system. Commercial Off-The-Shelf (COTS) describes the software products that are ready-made and available for sale to the general public. Government Off-The-Shelf (GOTS) refers to software government products that are ready to use and which were created and are owned by government agency.

Typically GOTS are developed by the technical staff of the government agency for which it is created.

The purpose of this section is to capture the hardware, COTS, and GOTS data for each program being reported.

This datasheet will provide insight into actual hardware procurement data so that cost estimating relationships and analogies can be developed.

This datasheet shall be completed by the prime contractor and associated subcontractors for the program being reported.

5.2 Instructions

The data provider shall provide data via one of the following methods:

• NGA CAPE Datasheets

• Program Bill of Materials (if purchasing own hardware) o Provide as much detail as possible o If there is an existing Bill of Materials which provides all of this information but in a different order, submittal of that document is also acceptable.

o If the Bill of Materials provides only part of the information requested in the datasheet, then those fields in the datasheet must be completed as well.

• Cloud Provider Billing Statements and/or Pricing Model exports/printouts o Provide as much detail as possible.

The data provider will only provide Government Furnished Equipment (GFE) or COTS hardware/software in this section.

Provide the following information:

a. Program Name: The name of the program for which this hardware was purchased

b. Contract #: The contract number (This should match contract number listed in section (i) of the Contract

Information datasheet)

c. Location: The final physical site of the hardware

• CONUS: (City, State)

• OCONUS: (City, Country)

d. HW/SW: Selection of HW or SW

e. Name of Application: The description of the item

• For example:

o Microsoft Office 2010, Business Edition

f. Description: The description of the hardware being reported

• For example:

o Storage: "Corporation X" STORAGETEK 3320 RACK READY, 1500GB (5*300GB, 15KRPM

SCSI DRIVES) ULTRA 320 SCSI-JBOD, 2 AC Power o Networking: "Corporation X" CATALYST 3750E 24 10/100/1000+2*10GE(X2) o Workstation: "Corporation X" ULTRA 40 M2 WORKSTATION o Server: "Corporation X" FIRE V245, 2X1.5GHZ ULTRASPARC 3I, 16GB, 4X73GB DRIVE, 2XPSU o Other: Cabinet, "Corporation X" RACK

g. Original Equipment Manufacturer: The original manufacturer of the hardware.

h. Category: The type of hardware being reported

Networking

Security

Servers

Storage

Services

Workstations

Other

i. Sub-Category: The sub-category of hardware being reported

• The "Sub-Category" field options will change depending on the chosen option in the "Category" field.

• Servers:

Physical

Virtual

• Workstations:

Thick Client

Thin Client

• Networking:

Routers

Switches

• Security:

Protection

Classification

Caveat

Releasability

Security Standard

• Storage:

Solid State

Spinning Disk

Tape

RAID Array

Other (Clarify in comments)

• Services:

Managed By Service Description

CIA Commercial Cloud Enterprise (C2E) Current primary commercial cloud service contract with multiple vendors

CIA Commercial Cloud Services (C2S) Legacy commercial cloud service contract (as of 2017, provided by Amazon)

NSA IC GovCloud (ICGC) cloud service only offered at the classified level

Amazon Unclassified GovCloud (UGC) the government cloud service at the unclassified level (as of 2017, provided by Amazon)

ODNI IC Desktop Environment (DTE) the user-facing IC ITE component which establishes a common, standard user interface and associated business services

TBD

Agency Infrastructure Service Provider (AISP) any government entity providing a form of infrastructure service

Other Other (Clarify in comments) Cables, Peripherals, Racks, Other

j. COTS/GOTS/FOSS: Designate whether the item is COTS (Commercial-off-the-Shelf), GOTS / GFE

(Government-off-the-Shelf / Government Furnished Equipment) or FOSS (Free & Open Source Software)

COTS

GOTS

FOSS

k. Environment: The environment in which each piece of hardware or software is used

D: Development

T: Test

O: Operations

Tr: Training

• Denote X for the environment(s) that are applicable

• Separate each unique item on different lines to accurately capture each instance

l. Domain Level: Clearance Level for Domain

UNCLASSIFIED

SECRET

TOP SECRET

CAP/SAP

m. Pricing Strategy: The basis for determining the licensing cost

Price per # of Users

Price per # of Named Users

Price per # of Nodes

Price per # of Seats

Price per # of Processors

Price per Enterprise License

n. Unit Cost / Rate for Usage: The unit cost for item at time of purchase or rate for usage where applicable

o. Quantity: The quantity of item purchased.

• If a piece of equipment is shared between multiple programs, then provide the portion of the equipment (e.g., 0.5) that is allocated to each program.

p. Life Expectancy: The date the hardware was purchased (MM/DD/YYYY)

q. Warranty Period: The number of years that are covered under vendor maintenance (if included in unit cost).

r. Annual Maintenance Cost: The annual maintenance cost (if known)

• Only enter a maintenance cost if it is not captured in another line within the bill-of-materials and if it occurs outside of the Warranty Period.

s. Comments/Notes: Any comments/notes necessary to provide clarification, additional detail, or context

6. Agile Measures

6.1 Scope

Agile measures capture the sizing and effort related to Agile, a set of principles for software development under which requirements and solutions evolve through collaborative effort of self-organizing cross-functional teams.

The purpose of this section is to capture the agile software measures for each program being reported. This datasheet will provide insight into actual software measures and scope data so that cost estimating relationships and analogies can be developed.

This datasheet shall be completed by the contractor associated with the program being reported.

This specific datasheet should only be used when agile software development is being performed on program.

6.2 Instructions

The data provider shall provide data via one of the following methods:

• NGA CAPE Datasheets

• Direct export from VersionOne, Redmine, or equivalent Agile software development management and measurement tool in lieu of filling out any applicable fields in the NGA CAPE Datasheets

The data provider shall provide agile software development data on an annual basis. However, NGA CAPE may request additional data if there is a major release of software prior to annual data collection.

Provide the following information:

a. Planned Summary Totals: The total number of Epics/Capabilities, Features, Stories, Sprints, Story Points and Feature Hours recorded as “Planned Development.” This typically applies to the Initial and Interim Reports.

b. Actual Summary Totals: The total number of Epics/Capabilities, Features, Stories, Sprints, Story Points and Feature Hours recorded as “Achieved Development.” This typically applies to the Interim and Final Reports.

c. Epic ID: Identifier assigned to track the capability.

d. Epic Description: Description of the large body of work that can be broken down into a number of smaller tasks.

e. Feature ID: Identifier assigned to track the feature.

f. Feature Description: Description of the specific functionality or capability that will be delivered in a single increment.

g. Planned Story Points: The estimate for all of the Backlog tasks needed to complete each Feature.

h. Planned Feature Hours: Total Hours planned to complete the Backlog tasks for each Feature.

i. Actual Story Points: The known size of the Backlog tasks actually completed per Feature.

j. Actual Feature Hours: Total Hours required to complete the Backlog tasks for each Feature.

7. Agile Detail

7.1 Scope

Agile software development describes a set of principles for software development under which requirements and solutions evolve through collaborative effort of self-organizing cross-functional teams.

The purpose of this section is to capture the detailed agile software development data for each program being reported. This datasheet will provide insight into actual software development lifecycle and scope data so that cost estimating relationships and analogies can be developed.

This datasheet shall be completed by the contractor associated with the program being reported.

This specific datasheet should only be used when agile software development is being performed on program.

7.2 Instructions

The data provider shall provide data via one of the following methods:

• NGA CAPE Datasheets

• Direct export from JIRA, VersionOne, Redmine, or equivalent Agile software development management and measurement tool in lieu of filling out any applicable fields in the NGA CAPE Datasheets

The data provider shall provide agile software development data on an annual basis. However, NGA CAPE may request additional data if there is a major release of software prior to annual data collection.

The data provider shall:

• Provide information at the lowest level

• Ensure that agile software development data are, at a minimum, provided by Function, As discussed. The data provider may provide data based on their own hierarchy structure, as long as Function exists in that structure.

• Include actual hours for software developers and software engineers only

a. Program Name: The name of the program for which the Agile SW data is being reported

b. Contract #: The contract number (this should match contract number listed in section (i) of the Contract

Information datasheet)

c. Developer: The contractor that developed the code

d. Location of Developer: Location where all personnel related to the Software Development team will be working for each software development functional area (City, State)

• This includes management/support/development personnel

e. Description: Provide a description of what will be delivered for developed software. Include a concise, written description of capabilities that will be valuable to a user (or owner) and contain "the who, what, and why" necessary to describe the requirement. Additionally, provide a general description of higher level deliveries.

f. Function: Reference Section 2.2b. for Program Functions

g. SW Development Level 1: The name of the next software development level (below Function) at which data is provided.

• Multiple SW Development Level 1 entries per Function should be denoted on separate lines

• For example (a notional structure):

o Function->Release o where Release is SW Development Level 1

h. SW Development Level 2: The name of the next software development level (below Level 1) at which data is provided.

• Multiple SW Development Level 2 entries per Level 1 should be denoted on separate lines

• For example (a notional structure):

o Function->Release->Sprint o where Release is SW Development Level 1 o where Sprint is SW Development Level 2

i. SW Development Level 3: The name of the next software development level (below Level 2) at which data is provided.

• Multiple SW Development Level 3 entries per Level 2 should be denoted on separate lines

• For example (a notional structure):

o Function->Release->Sprint->Feature o where Release is SW Development Level 1 o where Sprint is SW Development Level 2 o where Feature is SW Development Level 3

j. SW Development Level 4: The name of the next software development level (below Level 3) at which data is provided.

• Multiple SW Development Level 4 entries per Level 3 should be denoted on separate lines

• For example (a notional structure):

o Function->Release->Sprint->Feature->User Story o where Release is SW Development Level 1 o where Sprint is SW Development Level 2 o where Feature is SW Development Level 3 o where User Story is SW Development Level 4

k. Start Date: The date upon which software development effort started (MM/DD/YYYY)

l. End Date: The date upon which software development effort ended (MM/DD/YYYY)

m. Activity: Designate whether the developed software covers new development, fixes/discrepancy report

(DR) work offs, or a combination of the two.

Development

DR Work offs

Combination

n. Baseline Deployment: Indicate the baseline in which this software will be incorporated.

o. Date Deployed to Operations: The date developed software was deployed to operations (MM/DD/YYYY)

p. DR UID: The number assigned to the Discrepancy Report based on program naming conventions (if applicable)

q. Actual Hours: Provide the total number of hours attributed to the software development.

• Includes the following activities:

o Software Requirements Analysis o Preliminary Design o Detailed Design o Code and Unit Test o Component Test and Integration o Configuration Item Test and Integration

• Do not include higher-level Systems Engineering hours, Program Management hours, etc.

r. Complexity: The number of story points or other measure of complexity

• Provides a unit of measure that expresses the development complexity of a user story relative to the other user stories).

• All complexity evaluations provided should be on a numeric scale (e.g., 1-5, Fibonacci, etc.).

• If you used an alternative method for assessment (e.g., T-shirt sizes), translate it to a numerical method and explain that translation in the Comments/Notes field.

• Include only the following activities:

o Software Requirements Analysis o Preliminary Design o Detailed Design o Code and Unit Test o Component Test and Integration o Configuration Item Test and Integration

s. Comments/Notes: Any comments/notes necessary to provide clarification, additional detail, or context

8. Code Counts

8.1 Scope

Code counts are used to measure the size of a computer program by counting the number of lines in the text of the program source code. Code counts have traditionally been the primary measurement used for software sizing.

Even as Function Points (FP) and Agile sizing measures have emerged, code counts remain an important touchstone for benchmarking, calibration, and even direct software development cost estimating.

The purpose of this section is to capture the software sizing data for each program being reported. This datasheet will provide insight into actual code counts data so that cost estimating relationships and analogies can be developed.

This datasheet shall be completed by the prime contractor and associated subcontractors for the program being reported. The required code counter is the Unified Code Counter – Government (UCC-G). For more information on UCC-G, see https://cade.osd.mil/tools/unifiedcodecounter.html.

8.2 Instructions

The data provider shall provide data via one of the following methods:

• NGA CAPE Datasheets

• UCC-G output o A UCC-G output should be provided for each existing software baseline

The data provider shall provide code counts data on an annual basis. However, NGA CAPE may request additional data if there is a major release of software prior to annual data collection.

• In this case, NGA CAPE will ask for code counts by release only (but will not ask for hours and cost data to be provided to reduce the burden on the data provider)

• In order to receive data by release, NGA CAPE will work with the program offices to setup a file structure that will allow the UCC-G output to capture data at levels agreeable to both parties.

The data provider shall:

• Provide information at the lowest level

• Provide logical code counts (not physical)

• Not include COTS/GOTS code in the code counts data.

o Only include operational software baseline code.

o Exclude any test and engineering code

• Ensure that all information aligns with the "Date Code Counted."

o For example, actual code counts provided should cover development that occurred over the same time period as the hours provided. Estimates at complete should also be relevant as of the indicated date

• Run the Diff Tool and Dup Tool when using the UCC-G.

o The data provider can provide code counts using a different code counter, but UCC-G assessed code counts must be provided.

• Ensure that code counts are, at a minimum, provided by Function. The data provider may provide data based on their own hierarchy structure, as long as Function exists in that structure.

a. Program Name: The name of the program for which the code counts are being reported

b. Contract #: The contract number (This should match contract number listed in section (i) of the Contract

Information datasheet)

• For all contracts that span multiple functions, provide data on separate line items for each function

c. Developer: The contractor or sub-contractor that developed the code

d. Location of Developer: Location where all personnel related to the Software Development team will be working for each software development functional area (City, State)

• This includes management/support/development personnel

e. SW Code Type:

Provide the SW Code Type being developed. For Example: Database Dev, Glue/Wrapper Code, Refactoring/Migration Code, Source Code

f. Function: Reference Section 2.2b. for Program Functions

g. SW Programming Language: The software programming language used (ie. JAVA, Python, R, etc)

h. CSCI Name: The names of the CSCI at which data is provided. Multiple Functions per CSCI should be denoted on separate lines

• For example:

o CSCI1 FunctionA o CSCI1 FunctionB o CSCI2 FunctionA

i. Description: The description of the capabilities delivered as part of the software development

j. Baseline Deployment: The baseline in which this software was incorporated o 4.5.1 o 2b

k. Development Strategy: The primary method used for software development

Agile

Incremental

Spiral

Waterfall

l. New Code:

a. Total New Code: Total logical developed Software Lines of Code (SLOC) categorized as new code by the UCC-G or other code counter applied (Column L), comprising Newly Developed, Open

Source/Reuse, and Autogenerated

b. New Code - %Newly Developed Code: Percentage of Total New Code (Column M) that is newly developed code

c. Open Source/Reuse Code - % of Total New Code: Percentage of Total New Code (Column N) that is Open Source or External code

d. Open Source/Reuse Code – Adaptation Adjustment Factor (AAF): For all open source / reuse code, indicate the level of effort (in %), if any, to incorporate the piece of code versus developing it from scratch. This % includes the effort for design, implementation, and test of the incorporated code

e. Autogenerated Code - % of Total New Code: Percentage of Total New Code (Column P) that is

Autogenerated code

f. Autogenerated Code – Adaptation Adjustment Factor (AAF): For all auto generated code, indicate the level of effort (in %), if any, to incorporate the piece of code versus developing it from scratch. This % includes the effort for design, implementation, and test of the incorporated code.

m. Unmodified Code:

a. Total Unmodified Code: Total Code that has been not been modified since the last time the UCC-

G was run on the delivered code

b. % Adaptation Adjustment Factor (AAF): For all unmodified code, please indicate the level of effort (in %), if any, to incorporate the piece of code versus developing it from scratch. This % includes the effort for design, implementation, and test of the incorporated code.

n. Modified Code:

a. Total Unmodified Code: Total code that has been modified from its original state since the last time the UCC-G was run on the delivered code

b. % Adaptation Adjustment Factor (AAF): For all modified code, please indicate the level of effort

(in %), if any, to incorporate the piece of code versus developing it from scratch. This % includes the effort for design, implementation, and test of the incorporated code.

o. Deleted Code:

c. Total Deleted Code: Total code that has been deleted since the last time the UCC-G was run on the delivered code

p. Comments/Notes: Any comments/notes necessary to provide clarification, additional detail, or context

9. Data Management

9.1 Scope

Data management is the development and execution of architectures, policies, practices, and procedures that properly manage the full data lifecycle needs of a system.

The purpose of this section is to capture the data management information for each program being reported. This datasheet will provide insight into actual lifecycle and scope of data so that cost estimating relationships and analogies can be developed. Note that the data being referred to here are generally Mission Data, whereas the data contained in this CTDR are generally Business Data. In this section (and the next), the CTDR is collection Business Data about Mission Data.

This datasheet shall be completed by the prime contractor and associated subcontractors for the program being reported.

9.2 Instructions

The data provided in this section should be based on data collected as part of the data migration and data conditioning process. Database development relevant data should be excluded from this datasheet.

Provide the following information:

a. Program Name: The name of the program for which the Data Management data is being reported

b. Contract #: The contract number (this should match contract number listed in section (i) of the Contract

Information datasheet)

c. Developer: The contractor or sub-contractor that developed the code

d. Location of Developer: Location where the majority of personnel performing Data Management are located

• CONUS: (City, State)

• OCONUS: (City, Country)

e. Task (Short Description): The short description of Data Management effort performed. Each task performed on the program and contract should be denoted on a separate line

• For example:

o MS Access to SQL o Program X to Cloud Provider ‘Y’ o Downgrading classification level for X from TBD to TBD o Normalizing data to USA (from United States, United State of America, USA, etc.)

f. Scope (Long Description): The detailed description of the Data Management performed

• Including, but not limited to:

o Database name o Data migration effort o Data Conditioning effort

g. Data Management Effort: The type of data management effort performed

Data Conditioning

Data Migration

h. Start Date: The date upon which the Data Management effort started or is projected to start

(MM/DD/YYYY)

i. End Date: The date upon which the Data Management effort ended or is projected to end (MM/DD/YYYY)

j. # of Hours (Total): Duration of the Data Management effort that is performed (Hours)

k. Size: The size of data that is being migrated or conditioned (in Terabytes)

l. % Manually Conditioned Data: The percentage (%) of data relative to the entire set of data in database that is being manually conditioned. Manual conditioning consists of labor intensive modifications and/or reviews

• This field is to be completed only if there is data conditioning effort being performed

m. % Automatically Conditioned Data: The percentage (%) of data relative to the entire set of data in database that is being automatically conditioned. Automatic conditioning is performed by software tools and applications

• This field is to be completed only if there is Data conditioning effort being performed

n. Migration From X: The description of the original format/platform/location/etc. that the data management migration effort is migrating from

• For Example:

o MS Access o Oracle o SQL o Location X

• This field is to be completed only if there is data migration effort being performed

o. Migration To Y: The description of the original format/platform/location/etc. that the data management migration effort is migrating to

• For Example:

o MS Access o Oracle o SQL o Location X

• This field is to be completed only if there is Data migration effort being performed

p. Database Name(s) if applicable:

q. Comments/Notes: Any comments/notes necessary to provide clarification, additional detail, or context

10. Database

10.1 Scope

A database is a structured set of data held in an information technology system.

The purpose of this section is to capture the database data for each program being reported. This datasheet will provide insight into actual lifecycle and scope data so that cost estimating relationships and analogies can be developed.

This datasheet shall be completed by the prime contractor and associated subcontractors for the program being reported.

10.2 Instructions

The data provider shall provide data via one of the following methods:

• NGA CAPE Datasheets

• Cloud Provider billing statement or pricing model export (in a format that can be parsed)

Provide the following information:

a. Program Name: The name of the program for which the Database data is being reported

b. Contract #: The contract number (this should match contract number listed in section (i) of the Contract

Information datasheet)

c. Database Name: The name of the…