DI-FNCL-80166C
Program Cost and Technical Data Reports
Program Cost and Technical Data Reports provide the contractor's cost associated with a Government contract issued to acquire a program, project, or system, reported by Cost Breakdown Structure, software, and hardware configuration item formats.
Approval DateJune 21, 2010
AMSC Number9126
Preparing Activity—
Project Number—
OPRNS/BA012
DTIC Applicable—
GIDEP Applicable—
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantNo
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
DI-FNCL-80166B
Related
—Description & Purpose
—
Application & Interrelationship
—
Use & Relationship
Program Cost and Technical Data Reports provide the contractor's cost associated with a Government contract issued to acquire a program, project, or system.
This Data Item Description (DID) is applicable to all cost-reimbursement, and all incentive based Research, Development, Test, and Evaluation (RDT&E) and Procurement funded contracts over $25 million in total value. Amounts shall be reported through cost to the Government including General & Administrative (G&A) cost, but shall not include cost of money or Fee, unless otherwise noted.
This DID requires the reporting of all contract costs to a level of detail comparable to that presented in the standard Cost Breakdown Structure (CBS) in Format 1. This CBS is applicable to a single program or increment as specified in the accompanying CDRL. Costs included in these reports shall be current as of sixty (60) calendar days (or less) prior to submission. Costs included in the initial submission shall reflect the final negotiated position between the Government and the prime contractor. Cost data for the final report(s) shall be from the prime contractor's internal financial accounting system. This DID requirement and all associated reporting requirements shall be flowed down to all subcontractors and other company divisions whose efforts comprise over $10 million or more than 25% of the total prime contract value. The prime contractor shall generate one consolidated report (Formats 1, 2 and 3) that shall be delivered to the Government that includes the prime contractor and all subcontractors/inter-divisions. In addition, all Formats 1 through 3 that were completed by subcontractors or other company divisions must also be provided to the Government.
The initial submission of the DID is due within 60 days of contract award (or exercise of option) of each increment. If a rebaselining of a program or increment or a major Engineering Change Proposal (ECP) is negotiated, all Formats 1 through 3 will be resubmitted with the rebaselined amounts within 60 days of the negotiated rebaseline date. The initial submission shall contain the latest Estimate-At-Completion (EAC). The final report is due within 60 days or less after each increment is delivered and accepted by the Government or is terminated by the Government. The final submission will include all costs for the increment to include any outstanding obligations/commitments. The reporting period for the DID shall be from the start date of the current increment to the end date of the current increment. Each submission will be subject to Government approval. Specifically, the NSA Cost Analysis and Earned Value Management (EVM) Office or the organization specified in the DID will be the final approval authority. This includes approval of the methods used to map lower level costs into end item costs of the prime, subcontractors and Government. A post award meeting shall be scheduled within 30 days of final contract award with the Government program office, the prime contractor, and representatives from the approving authority to ensure all DID reporting requirements are understood by the reporting contractor.
This DID supersedes DI-FNCL-80166B.
Preparation Instructions
1Reference documentsThe applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as cited in the current issue of the DODISS at the time of the solicitation.
2Content and FormatThe Program Cost and Technical Data Reports employ 3 types of formats containing cost and technical data elements. Format 1 (see Figure 1 - Cost Breakdown Structure) provides data to capture costs by CBS elements, while Format 2 (see Figure 2 - Computer Software Configuration Item (CSCI)) provides technical data on software and Format 3 (see Figure 3 - Hardware Configuration Items) provides data on hardware elements.
2.1Format 1The CBS contained in Format 1 was derived per MIL HDBK-881 guidance with high interest and critical items of interest to the Government expanded. For clarification and to expand any CBS elements to lower levels than that depicted in Format 1 refer to MIL HDBK-881. Since MIL HDBK-881 is Development and Production oriented and does not address Operations and Support (O&S) in sufficient detail, the Cost Element Structure found in the DoD Automated Information System Guide is utilized for the O&S sub elements of CBS paragraph 13.0.
If the Contract Work Breakdown Structure (CWBS) is not structured as a product-oriented CBS (i.e., one that identifies hardware and software end items) or does not isolate end item costs at the level of detail described above, then the CWBS shall be mapped into the CBS provided in this DID. In order to provide this information, the costs shall be isolated for each applicable hardware end item, software end item, and supporting elements. Information shall be provided tracing the downward allocation, upward aggregation, or lateral transfer of costs from the CWBS to the resulting end items, such that the contributions of each CWBS element to each end item are shown. Additionally, information tracing costs from the CWBS to the standard CBS shall be provided.
Software end item Computer Software Configuration Item (CSCI) or major single function costs shall be reported at CBS level 5 at a minimum. Systems Engineering Integration and Test, and Program Management costs are reported at various CBS levels, as displayed in the standard CBS. A CWBS dictionary to the lowest level available shall be provided by the contractor.
Although Format 1 in this DID depicts the complete lifecycle of a product, as the contractor, only fill in Format 1 entries for those CBS indented items pertinent to the Program, Project, or System phase supported by this contract/increment. Two submissions are required per increment, one at the beginning of the increment (Estimate at Completion (EAC)) and the second at the end of the increment (Actual Final Costs).
2.1.1Format 1 Section A Contractor/Project Information
2.1.1.1ContractorContractor's name and company division in 1A, primary work location in 1B.
2.1.1.2ContractName as assigned to the contract by the procuring agency in 2A, Contract designated number from the procuring agency in 2B, brief description of the contract in 2C, and Type (as CPIF, CPAF, etc.) in 2D.
2.1.1.3ProgramName of the program, project, or system, if different from the name entered in 2A, shall be entered into block 3A, otherwise enter "same". Place in block 3B a brief description of the program.
2.1.1.4Report PeriodEnter in 4A and 4B year, day, and month of the time interval covered by this report. Start Date in 4A should be the start date of the contract/Increment being reported.
2.1.1.5Date SubmittedActual date of report completion and release of information to the Government Program Office.
2.1.1.6Dollars inDenote entries that are factored down by thousands (K) or millions (M).
2.1.1.7Price to SellShall enter total price to include burdens, Cost of Money (COM) and Fee
2.1.2Format 1 Section B, Functional elements by CBS
2.1.2.1Labor HoursEnter the number of staff-hours (to include subcontractor, interdepartmental work transfer authorizations (IWTAs), consultant and purchase labor hours) devoted to each CBS item. Total labor hours (EAC for first submittal, final actual hours for last submittal) for each CBS may be further broken down into prime, subcontractor, IWTA, consultant, or purchase hours if desired but it is not required so long as the total includes them.
2.1.2.2Labor CostsEnter the direct fully burdened labor cost (EAC for first submittal, final actual cost for last submittal) for each CBS item. Labor costs shall be reported consistently with Labor Hours as described in the above paragraph. When reporting other than prime labor costs (e.g., subcontractor, IWTA, consultant, purchased labor) in this element do not include any non-prime, non-labor dollars (i.e., subcontractor or IWTA Other Direct Costs (ODCs) or material). These other than labor non-prime costs should be reported with the prime contractor dollars for the same elements (see material and ODC elements below). Do not enter values that include cost of money or Fee.
2.1.2.3Material CostsEnter the material cost (EAC for first submittal, final actual cost for last submittal) to include applicable burdens, for each CBS element. Material costs for subcontractors, consultants, and IWTAs should also be captured here. This includes the cost of all Commercial Off-The-Shelf (COTS) products purchased or licensed to develop this system. Do not enter values that include cost of money or Fee.
2.1.2.4Other Direct Costs (ODCs)Enter the total "other direct costs", to include applicable burdens, for each CBS element. ODC costs for subcontractors, consultants, and purchase labor should also be captured here. Identify the ODCs in block 8 Remarks, including burdens (i.e., Travel = $X,XXX). Do not enter values that include cost of money or Fee.
2.1.2.5Total CostsEnter the total cost (summation of labor, material, and ODCs) by CBS element. Do not enter values that include cost of money or Fee.
2.1.3Format 1 Section B (cont.): CBS Definitions
0.0Total SystemIncludes the top summary of all equipment, hardware, software, data, services, personnel, and facilities costs required to develop, produce, deploy, operate, upgrade, sustain and dispose of a product system. This is the total aggregation of the complex of equipment (hardware/software), data, services, and facilities required to develop and produce an electronic, automated, or software system capability such as a command and control system, radar system, communications system, information system, sensor system, navigation/guidance system, electronic warfare system, support system, etc..
1.0Prime Mission Product (PMP)Includes the hardware and software used to accomplish the primary mission of the Defense materiel item. This includes:
1.) All integration, assembly, test and checkout associated with individual hardware/software elements;
2.) The integration, assembly, test and checkout associated with the overall PMP. Note: When the electronic/automated software system comprises several PMPs, each will be listed separately at level 2.
3.) Any whole and partial prime contractor, subcontractor, and vendor breadboards, brass boards, and qualification test units;
4.) The design, development, and production of complete units (i.e., the prototype or operationally configured units that satisfy the requirements of their applicable specification(s), regardless of end use); and
5.) All factory special test equipment, special tooling, and production planning required fabricating the PMP.
1.1Hardware SubsystemThis element includes the hardware and embedded software of the specific electronic/automated software system. Embedded software is an integral part of a specific hardware system/subsystem/component (e.g., ASIC software). This element also includes:
1.) All associated special test equipment, special tooling, production planning, and all technical and management activities;
2) All in-plant integration, assembly, test, and checkout of hardware components and software into an electronic/automated software subsystem, including the subsystem hardware and software integration and test;
3.) interface materials and parts required for the in-plant integration and assembly of other level 4 components into the electronic/automated software subsystem and all materials and parts or other mating equipments furnished by or to an integrating agency or contractor;
4.) Cables, conduits, connectors, shelters, and other devices associated with the operational electronic/automated software subsystem; and
5.) The design, development, production, and assembly efforts to provide each electronic/automated software subsystem as an entity.
1.1.1...1.1.95Hardware Configuration Item (HWCI) 1...95 (Specify Name of HWCI)This element refers to those HWCIs in each system. This element should be replicated as required for each HWCI within the system. This WBS item includes all hardware units and components required to have functioning HWCIs, and conform to the planned configuration. Hardware warranties are also included with the hardware end item. Includes COTS and Government-Off-The-Shelf (GOTS) hardware incorporated into the design. Also includes any embedded software purchased as a package with the HWCI (e.g., a computer workstation with Operating System (OS)/software installed when purchased). Any integration, assembly, test, and checkout of hardware within the HWCI is included. Also, includes internal HWCI interface materials and parts required for the integration and assembly of hardware components. Element captures the engineering design, development, prototype/brass board manufacturing, and assembly efforts to provide each HWCI as an entity.
1.1.97System Engineering of Hardware Configuration Items (HWCIs)This WBS element contains the resources associated with all engineering from functional specialists (excluding checkout/ test and evaluation) in support of the Hardware Subsystem. This engineering support includes: System Engineering, Quality Assurance, Reliability and Maintainability, and Human Engineering associated with the HWCIs. This WBS element contains all the resources associated with integration and test verification and validation of the HWCIs. Representative activities include: generate input to hardware test plans, descriptions, and procedures; define hardware test cases; and perform hardware integration analysis.
1.1.98Program Management of Hardware Configuration Items (HWCIs)This WBS element includes the HWCIs program management, which includes management, direction and control of all effort contributing to the development, production, custom and COTS procurement, and integration of the HWCIs. It includes overall administration, project controls, product effectiveness, configuration management, warranty administration, subcontract management, vendor liaison, logistics management, and security management.
1.1.99Integration, Assembly, and Checkout of Hardware Configuration Items (HWCIs)Includes all effort directly associated with the hardware subsystem HWCI's integration, assembly, test and checkout as they are brought together into the subsystem.
1.2Prime Mission Product Applications SoftwareThis element includes software that is specifically produced for the functional use of a computer. This includes:
1.) Battle management, weapons control, and data base management.
2.) All effort required to design, develop, integrate, and checkout the PMP applications computer software configuration items (CSCIs), not including the non-software portion of PMP firmware development and production.
1.2.1...1.2.95Applications Software Build 1...95 (Specify Name for Build/Spiral)Includes in each software build an aggregate of one or more CSCIs that satisfies a specific set or subset of requirements. When incremental, spiral, or another software development method is used, multiple builds may be necessary to meet program requirements. A build is a separately tested and delivered product. Within builds are CSCIs. When a build is complete, a portion or all of one or more CSCIs will be completed. Therefore, a CSCI may appear in more than one build, but will be successively more functional as each build is completed.
1.2.1.1...1.2.1.95CSCI 1...95 (Specify Name for CSCI)Includes the aggregation of software or any of its discrete portions, which satisfies an end use function and has been designated by the Government for configuration management. CSCIs are the major software products of a system acquisition and are developed in accordance with standard DoD or commercial practices and process. This includes:
1.) Reusable software components, such as COTS software, Government furnished software, or software specifically developed for reuse.
2.) Glue code, which is used to ensure proper interface and operation of the COTS, GOTS and custom software.
3.) Effort associated with the requirements analysis, design, coding and testing, integration and testing of Computer Software Components (CSCs), CSCI formal qualification testing, and software problem resolution of each CSCI.
4.) Computer Software Components (CSCs) which are functionally or logically a distinct part of a CSCI, distinguished for convenience in designing and specifying a complex CSCI as an assembly of subordinate elements. Note that often CSC's may be further decomposed into Computer Software Units (CSUs) by a software organization.
Each CSCI is comprised of the six sub elements defined below. When it is impossible to associate a particular COTS software package with a particular CSCI (e.g., some COTS packages perform multiple functions and cross CSCI functionality), a separate WBS element at the CSCI level should be created to segregate the cost of such a COTS package. For example, if there are two CSCIs for the program numbered as 1.2.1.1 and 1.2.1.2 and there is a COTS software package that cannot be associated with only one of those CSCIs, the appropriate WBS element to isolate the COTS software package would be 1.2.1.3, COTS Software Package XX. If there are multiple COTS software packages that meet this criterion, one WBS element can be created at the level described above with multiple sub elements below it; one for each COTS Software package.
1.2.1.1.1Requirements AnalysisThis element contains all the resources associated with the software configuration item requirements analysis. This is the process by which a complete set of engineering and interface requirements are defined for each configuration item. Representative activities include: analysis of preliminary software requirements, identification and allocation of software requirements into configuration items, analysis of preliminary interface requirements, and identification and resolution of interface requirements.
1.2.1.1.2DesignThis element contains all the resources associated with the software configuration item design. This is the process of decomposing a high-level abstract requirement into lower level software elements. Preliminary design and detailed design activities are accomplished to map out high-level as well as low-level strategies for allocating requirements for each configuration item to design entities, e.g. objects, classes, modules, Computer Software Components (CSCs), etc. Representative activities include: creating and maintaining Software Development Files (SDF)s, analysis of preliminary software design(s), deriving and mapping out high (top) level software design specifications, devising and mapping out low level (detail) software design specifications, analysis of preliminary interface design specifications, defining and describing interface design specifications, generating input to software test planning, and formalizing test requirements for design entities.
1.2.1.1.3Coding and Design Entity TestingThis element contains all the resources associated with the software configuration item coding and design entity testing. This is the process of implementing the software design in a program language that may then be converted mechanically (i.e. by compilation) to an acceptable machine-executable representation. Each design entity is coded and subsequently tested to ensure that it satisfies its specific requirement. Representative activities include: maintaining SDFs, coding and compiling activities, conducting testing and analysis, code walk-through activities, performing compliance checks to coding conventions, and developing lower level design entities test and integration procedures.
1.2.1.1.4Design Entity Integration and TestThis WBS element contains all the resources associated with the software configuration item design entity integration and testing. This is the process of integrating or building design entities into a configuration item and the testing of lower level threads to verify that the algorithms and data employed in interfacing each design entity are correctly specified and implemented. Representative activities include: performing design entity integration analysis, performing design entity build and lower level thread testing, recording test results, and performing dry runs of formal qualification tests.
1.2.1.1.5Configuration Item TestingThis WBS element contains all the resources associated with the software configuration item testing. This is the process of demonstrating that the configuration item can perform correctly under the full range of operating conditions and that it satisfies its requirements. Representative activities include: conducting formal qualification tests, conducting test analysis and recording test results.
1.2.1.1.6CSCI COTS SoftwareThis WBS element contains all the resources associated with the procurement, integration, verification and test of any COTS software. Representative activities include: purchasing COTS software packages and evaluating their suitability to meet program requirements regardless of whether the COTS package is ultimately used in the end deliverable.
1.2.1.97System Engineering of Applications Software Build 1 CSCIs 1...95This WBS element contains the resources associated with all engineering by functional specialists (excluding checkout/ test and evaluation) in support of the Applications Software Build custom and COTS software. This engineering support includes: System Engineering, Quality Assurance, Reliability and Maintainability Engineering, and Human Engineering, that are associated with the Application Software Build custom and COTS software. This WBS element contains all the resources associated with integration and test verification and validation of the Applications Software Build custom and COTS software. Representative activities include: generating input to software test plans, descriptions, and procedures; defining software test cases; performing custom and COTS software integration analysis; performing software build and tests; and updating SDFs. This element also includes any build-specific algorithm development performed by the scientific/engineering/ mathematical team. Generally, the scientific/engineering/mathematical algorithm development and any rudimentary coding is performed as a level of effort task within the system engineering function. If mapping cannot be made at this level, then the algorithm development should be booked at the next higher level of System Engineering.
1.2.1.98Program Management of Applications Software Build 1 CSCIs 1...95This WBS element includes the Applications Software Build software PM, which includes management, direction and control of all effort contributing to the development, production, custom and COTS procurement, and integration of the Applications Software Build software. It includes overall administration, project controls, product effectiveness, configuration management, warranty administration, subcontract management, vendor liaison, logistics management, and security management.
1.2.1.99Integration and Checkout of Application Software Build 1 CSCIs 1...95In those instances in which an integration, assembly, test, and checkout element is needed at the build level, this element includes the effort of technical and functional activities associated with the design, development, and production of software required to assemble this level of equipment software elements into the next higher WBS level and not directly a part of any other individual WBS element.
1.2.99Integration, Assembly, Test & Checkout of All Application SW BuildsIncludes all effort directly associated with the software CSCI's integration, assembly, test and checkout of all software builds as they form into a complete software system.
1.3Prime Mission Product System SoftwareIncludes the software designed for a specific computer system or family of computer systems to facilitate the operation and maintenance of the computer system and associated programs. Includes:
1.) The Operating systems, compilers, and utilities.
2.) All effort required to design, develop, integrate, and checkout the PMP system software, including all hardware and software developed to support PMP-Applications-Software Development.
3.) PMP system software required to facilitate development, integration, and maintenance of any PMP software build and CSCI.
For lower level 1.3 elements, follow the same breakout as 1.2 PMP Applications Software.
1.3.96Software Development EnvironmentAny hardware or software necessary to facilitate the development of the application software/solution. Includes the development, purchase and maintenance of all hardware and software (COTS and custom) required to support the development of PMP application software. Development environment hardware/software is not used for deployment/fielding but only for development of the application software. Includes developer tools, compilers, specialized testing software, and specialized developer computer workstations, etc.
1.3.99Integration, Assembly, Test & Checkout of All System SW SpiralsIncludes all effort directly associated with the software CSCI's integration, assembly, test and checkout of all software Spirals as they form into a complete software system.
1.4PMP Integration, Assembly, Test and CheckoutThis element includes the effort of technical and functional activities associated with the design, development, and production of hardware and software required to assemble both the PMP Hardware, Application and System Software packages that are not directly a part of any other individual WBS element.
2.0System Engineering/Program ManagementThis element is a rollup of WBS sub elements that contain the overall management and technical direction costs associated with the program. Functions included in this element are: business, administrative, and engineering associated with planning, organizing, directing, coordinating, controlling, and accomplishing overall program objectives.
2.1System EngineeringThe system engineering function is responsible for the analysis, derivation, allocation, and traceability of derived system requirements and interfaces. This effort includes establishing system-level requirements; system/subsystem or subsystem/subsystem interfaces; system analyses, models and simulations; quality; configuration control; while also assessing performance, and technically managing the design, development, production, and integration of the system.
This element includes the following:
1.) Effort to define the system and the integrated planning and control of the technical program efforts of design engineering, specialty engineering, process and production engineering, and integrated test planning.
2.) Effort associated with developing the Systems Engineering Plan (SEP).
3.) Effort to transform an operational need or statement of deficiency into a description of system requirements and a preferred system configuration.
4.) Technical planning and control effort for planning, monitoring, measuring, evaluating, directing, and replanning the management of the technical program.
5.) Where applicable - value engineering, configuration management, human factors, maintainability, reliability, survivability/vulnerability, system safety, environmental protection, standardization, system analysis, logistic support analysis, etc.
6.) Technical baseline management and event based technical reviews with independent subject matter expertise participation.
7.) Cross Product Integrated Process Team (IPT) integration.
8.) Survivability/vulnerability analysis.
This element also includes support of functional specialists (excluding checkout/test and evaluation), who provide technical planning, technical management, analysis, and support efforts for the development of the system. This engineering support typically includes: Systems Engineering, Quality Assurance, Reliability and Maintainability, and Human Engineering associated with the overall system.
Algorithms developed specifically for and in support of the system that cannot be mapped to a lower level system engineering element are included in this element.
2.2Program ManagementIncludes the business and administrative planning, organizing, directing, coordinating, controlling, and approval actions designated to accomplish overall program objectives that are not associated with specific hardware elements and are not included in systems engineering. Includes, in particular,
1.) Cost, schedule, performance measurement management, warranty administration, contract management, data management, vendor liaison, subcontract management, engineering change proposal (ECP) preparation, risk management, travel, etc.
2.) Security
3.) Support element management, defined as the logistics tasks of management effort and technical control, and the business management of the support elements. The logistics management function encompasses the support evaluation and supportability assurance required to produce an affordable and supportable defense materiel system.
4.) Planning and management of all the functions of logistics such as maintenance support planning and support facilities planning; other support requirements determination; support equipment; supply support; packaging, handling, storage, and transportation; provisioning requirements determination and planning; training system requirements determination; computer resource determination; organizational, intermediate, and depot maintenance determination management; and data management.
Includes training manuals, software manuals, and other system-specific documentation. Training course materials are included in training, not program management.
Also includes all deliverable data required to be listed on a Contract Data Requirements List, DD Form 1423. It includes acquiring, writing, assembling, reproducing, packaging and shipping the data, as well as transforming them into Government format. Subcategories included are creation and production of Technical Publications, Engineering Data related to scientific or technical information and computer software documentation, Management Data covering configuration management, cost, schedule, contractual data management, program management, etc., required by the Government, Support Data related to data items designed to document support planning in accordance with functional categories selected, and the operation of a Data Depository as custodian to maintain a master engineering specification and establish a drawing depository service for Government approved documents that are the property of the U.S. Government.
2.3Mission Assurance (MA)Includes Mission Assurance (MA) planning and generation of measures intended to provide a defined and accepted level of confidence that the delivered system can meet expected mission objectives under a wide range of operating conditions. This includes disaster recovery planning, business continuity, and emergency preparedness. As a minimum, MA involves the following tasks:
2.3.1Defining Critical Objectives
2.3.2Providing a Continuum of Capabilities
2.3.3Defining the Range of Operating Conditions
2.3.4Measuring Confidence
2.3.5Enhancing Readiness planning
2.3.6Maintaining Continuity of Operations Planning/Preplanning often referred to as COOPThis element excludes procurement of additional hardware/software to support COOP as these items are included in PMP.
2.3.7Planning for Critical Infrastructure Protection (CIP)
2.4Information AssuranceIncludes the effort involved in assuring that information systems are protected from unauthorized access and that the confidentiality, integrity and availability of the systems is maintained. This includes providing for restoration of information systems by incorporating protection, detection and reaction capabilities.
3.0System Integration, Assembly, Test & CheckoutIncludes the effort involved in providing technical and engineering services to the host developer, manufacturer or integrator during the installation and integration of the PMP into the host's system. Support provided by the producer/integrator of the PMP is included in this WBS element. This includes Integration & Test (I&T) management - requirements definition, planning and scheduling; development of test plans and procedures; test preparations, conduct and teardown; conduct of product acceptance testing; development of software and hardware for supporting system I&T; and review, analysis and documentation of test results.
4.0System Test and EvaluationThe use of prototype, production, or specifically fabricated hardware/software to validate system performance. This includes detailed planning, conduct and test support, as well as engineering data collection, data reduction and reports (excluding the Contract Data Requirements List data) from such testing. Also includes all hardware/software items which are consumed or planned to be consumed in the conduct of such testing, as well as all effort associated with the design and production of models, specimens, fixtures, and instrumentation in support of the system level test program. Please note that test articles which are complete units (i.e., functionally configured as required by specifications) are excluded from this work breakdown structure element.
4.1Development Test and EvaluationTesting effort that is planned, conducted and monitored by the developing agency of the DoD component including system verification/certification. This includes test and evaluation conducted to demonstrate that the engineering design and development process is complete, the design risks have been minimized, the system will meet specifications, as well as to estimate the system's military utility when introduced, determine whether the engineering design is supportable (practical, maintainable, safe, etc.) for operational use, provide test data with which to examine and evaluate trade-offs against specification requirements, life cycle cost, & schedule, and to perform the logistics testing efforts to evaluate the achievement of supportability goals, and the adequacy of the support package for the system. Includes system verification/certification testing.
4.2Operational Test and EvaluationThis element includes test and evaluation conducted by National Security Agency/Central Security Service (NSA/CSS) Operational Testing Authority (NOTA) and its agents, e.g., Joint Interoperability Test Command(JITC), etc., using actual NSA analysts (operators) or elements other than the developing activity to assess the prospective system's military utility, operational effectiveness, operational suitability, logistics supportability (including compatibility, inter-operability, reliability, maintainability, logistic requirements, etc.), cost of ownership, need for any modifications, and complete acceptance testing. This element shall also include any contractor coordination effort with NOTA and JITC.
4.3Test and Evaluation SupportThe support elements necessary to operate and maintain, during test and evaluation, systems and subsystems that are not consumed during the testing phase and are not allocated to a specific phase of testing. Includes, for example, test and support equipment, test bed vehicles, drones, surveillance aircraft, tracking vessels and contractor technical support.
4.4Test FacilitiesThe special test facilities required for performance of the various developmental tests necessary to prove the design and reliability of the system or subsystem. Also includes test tank test fixtures, propulsion test fixtures, white rooms, and test chambers.
Includes System Integration Labs (SILs), namely, the design, build and test of facilities where software and hardware can be developed, integrated, tested and evaluated for both stand alone functionality and/or interoperability prior to being fielded. These facilities have special contractual or engineering significance and are not required solely for the conduct of one of the above elements of testing (i.e., DT vs. OT). They are used only for testing, not development of application software.
4.5Independent Verification and ValidationIncludes all contract support for Independent Verification and Validation. Independent Verification and Validation (IV&V) ensures that the software meets all performance standards and adheres to all stated requirements of the functional description and documentation procedures. Also includes reviewing and evaluating deliverable items, such as system specification, user manuals, program specifications, maintenance manuals, test plans, and operations manuals; accomplishing configuration audits; conducting validation testing; and establishing and maintaining the test database.
5.0TrainingIncludes deliverable training services, devices, accessories, aids, equipment, and parts used to facilitate instruction through which personnel will learn to operate and maintain the system with maximum efficiency. Includes also Equipment, Services, and Facilities devoted solely to training. Services includes training course materials, contractor-conducted training, and the materials and curriculum required to design, execute, and produce a contractor developed training program. Includes material, courses, and associated documentation (primarily the computer software, courses and training aids).
6.0Data MigrationThe effort to extract, translate and load data into the newly developed system from another system/environment. Migration can involve moving to new hardware, new software or both. Examples include migrating from one operating environment to another, one database to another or one storage device to another. Includes the effort to write customized programs or scripts to automatically transfer the data. This element should be further broken down into sub elements as necessary to isolate and identify the specific effort for a particular migration.
7.0Peculiar Support EquipmentIncludes the design, development, and production of those deliverable items and associated software required to support and maintain the system or portions of the system while the system is not directly engaged in the performance of its mission, and which are not common support equipment (See below). Also includes the peculiar or unique testing and measurement equipment and the peculiar Support and Handling Equipment.
8.0Common Support EquipmentIncludes the items required to support and maintain the system or portions of the system while not directly engaged in the performance of its mission, and which are presently in the DoD inventory for the support of other systems. This includes DoD inventory items of Test and Measurement Equipment, as well as DoD inventory Support and Handling Equipment.
9.0Operational/Site ActivationThe real estate, construction, conversion, utilities, and equipment to provide all facilities required to house, service, and install the prime mission equipment at the organizational and intermediate level. Includes:
1.) Conversion of site.
2.) System assembly, checkout, and installation (of mission and support equipment) into site facilities to achieve operational status including effort to pack and ship the system.
3.) Construction of new facilities/structures if required.
4.) Contractor support in relation to operational/site activation.
9.1Mission Equipment InstallationSystem assembly, checkout and installation of mission and support equipment into site facilities in order to achieve operational status. Contractor support in relation to operational activation is also included in this element. Also included in this element are site surveys and any packing and shipping costs associated with delivering the system to site.
9.2Facilities/ConstructionThe research, planning, development, design, construction, alteration, or repair of real property required to support the prime mission equipment.
9.2.1Site Preparation/Acquisition CostThis element includes the cost to acquire/buy land for the construction of facilities. It also includes conducting feasibility studies for selecting potential construction sites. Site preparation include grading and earth work; storm water drainage, retention ponds, and erosion control; road curbing and gutters; road construction including asphalt, paving resurfacing, seal coating and striping; and site utility work including water and sewer lines.
9.2.2DesignThe effort to design the facility/building and the site pre-planning and planning including drawings for grading, storm water and erosion control, roads, parking lots, site utilities and earth work.
9.2.3DemolitionThis element contains the cost to clear the land prior to building and renovation of the site.
9.2.4Building ConstructionThis element includes the cost of adding on, expanding or building a new structure/shell less any installed building equipment, air conditioning, etc.
9.2.5Building RenovationThis element includes the cost of renovating an existing building/structure. Renovation is the alteration or replacement of facilities solely to implement new or higher standards, to accommodate new functions, or to replace building components that typically last more than 50 years (such as framework or foundation). Renovation of any installed building equipment, air conditioning, etc. should be included in the appropriate WBS elements below.
9.2.6Special Security ProvisionsSecurity costs associated with construction projects typically include: Intrusion Detection Systems (alarms), Video Recording Systems, Access Control Systems, Exclusive Standoff Zone (ESZ) (note: size of ESZ directly impacts extent of protective security devices and systems), Security Communications Center (monitors all security systems), security data transfer systems, Construction Security (temporary site badges, cameras, recorders, badge systems, access control devices, contractor documentation review and processing etc., Construction Security Technician (CST) daily physical security oversight and inspection during entire construction period, Security Site Inspections and Reviews, Chemical/Biological/ Radiological/Nuclear (CBRN) Perimeter Detection Systems, and Physical Security Project Manager (local security assignee to oversee entire Construction Project). The acquisition and installation of the following items are considered supporting elements necessary to accredit and occupy the facility as an NSA SCIF:
1.) All security support infrastructure (communications & power) necessary to operate security devices & systems
2.) Any specialized lighting required for CCTV around the entire site
3.) Appropriate Antiterrorism Force Protection (AT/FP) rated fence and infrastructure (e.g., walls, barriers, trenches) required to protect the facility
4.) Visitor Control Center and Vehicle Inspection facilities
5.) K9 facilities (if required)
6.) Police support facilities (locker room, weapons storage, offices, etc.)
7.) Escorting Requirements during finish, fit up stages and occupancy phases.
9.3Power and CoolingThis element includes the hardware necessary to provide the Heating, Ventilation and Air Conditioning (HVAC) and electrical infrastructure necessary to support the system while it is performing its mission.
9.3.1Mechanical System EquipmentIncludes the design, development, procurement and enhancement of those mechanical infrastructure items necessary to support and maintain the system or portions of the system while the system is engaged in the performance of its mission.
9.3.1.1Fuel Oil SystemDiesel fuel oil system for emergency generator.
9.3.1.2PlumbingPipes used to distribute the water for cooling the system; usually steel, copper or plastic. Piping for chilled water must be provided below raised floors in processing areas with taps to allow connection of both air handling units and computer cooling.
9.3.1.3CRAC/CRAHComputer room air conditioning (CRAC)/Computer room air handling (CRAH) - provides cooling and humidity control to the system equipment room.
9.3.1.4Water Cooled CabinetsHigh-density server cabinets/racks cooled by circulating liquid through the cabinet.
9.3.1.5Chiller PlantSystem consists of a chiller, cooling tower, building cooling load, chilled water, and condensing water pumps and piping.
9.3.1.5.1ChillersChillers can be water-cooled, air-cooled or evaporatively cooled. Components include a compressor, evaporator, and condenser. Uses the majority of electricity.
9.3.1.5.2Cooling TowersRemove heat from the water discharged from the condenser so that the water can be discharged to a river or re-circulated and reused. Cooling towers are used in conjunction with water-cooled chillers. Air-cooled chillers do not require cooling towers.
9.3.1.5.3PumpsMaintain the required flow rate. To maintain redundancy, multiple pumps are used.
9.3.1.6Fire Protection SystemIncludes fire protection system components such as sprinklers, detection, alarm and communication systems, portable fire extinguishers, etc.
9.3.2Electrical System EquipmentElectrical system equipment required to provide power to the operating/mission equipment. Power is supplied by commercial/utility electrical service, generators, and batteries. Batteries provide backup power and are connected to the UPS system.
9.3.2.1UPS SystemUninterruptible Power Supplies (UPS) distribute power from the utility source of a building to the critical, computer/Information Technology (IT) loads. The UPS is installed between the commercial power source and IT equipment to provide a continuous supply of electricity. The UPS connects to the Power Distribution Unit (PDU). A UPS protects computers against voltage surges and spikes, voltage sags, total power failure, and frequency differences.
9.3.2.2Power Distribution SystemA power distribution unit converts high voltage electric power from a commercial source to levels more appropriate for data center equipment.
9.3.2.3SubstationsEquipment that switches or modifies voltage, frequency, or other characteristics of the primary power provided by the commercial/utility electrical service.
9.3.2.4GeneratorsProvides source of electrical power in instances when power from the main utility source is unavailable or interrupted. Emergency power generators are required to handle all computer, control equipment, chillers, air handling, heating, telecommunications, office equipment, normal lighting, and emergency lighting with enough fuel for at least 72 hours.
9.4Tenant Fit-UpThis element includes the interior office space construction and associated mechanical and electrical systems required for tenant use/occupation.
9.4.1Interior ConstructionConstruction of interior partitions, interior doors and windows, wall finishes, flooring and wall finishes, ceiling and ceiling finishes, specialties and casework. Specialties are items that are permanently fixed in place such as cabinetry, shelving, and counters. Interior wall structures are excluded.
9.4.2Mechanical SystemsIndividual plumbing (toilets, fixtures, sinks, etc.), HVAC branch ductwork, branch piping and sprinkler heads, and gas outlets.
9.4.3Electrical SystemsElectrical power service and distribution and lighting and branch wiring.
9.5Information Technology (IT)The hardware, software and firmware associated with the movement, control, display, switching, and transmission or reception of data or information. IT infrastructure wide area communications, telephones, networks, cable plant infrastructure, firewalls and Public Key Infrastructure (PKI), desktops and desktop servers, web servers, etc.
9.5.1Desktop ComputingWorkstations, printers, and copiers.
9.5.2Telephony & VTCTelephone instrumentation and Video Teleconferencing (VTC) equipment.
9.5.3Network DistributionRaceway, cabling and all devices necessary to direct, route and link network segments including, routers, switches, hubs, etc.
9.5.4Network AccessThe equipment necessary to provide connectivity at the site.
9.5.4.1Network Interface CardsThis element includes the network interface cards (NIC) that are installed in the computer or server and works with the operating system and appropriate device drivers to control the flow of information between the personal computer or server and the network.
9.5.4.2Network Encryption HardwareThis element includes hardware inserted between the user/workstation and the network. The encryption hardware performs access control and encryption, and transmits data over the network.
9.5.4.3Bandwidth LeaseThe cost to lease satellite or terrestrial network bandwidth capacity. This element includes the cost to lease bandwidth prior to Final Operational Capacity (FOC). After FOC, lease costs are included in O&S element 13.9, Communications.
9.5.5FirewallComputer or other equipment that monitors all traffic inbound or outbound from an enclave and requires certain criteria to be met before allowing passage of data. Firewalls are used between enclaves of the same security level within domains.
9.5.6OtherAny other unique IT equipment required to support the operating/mission equipment but not listed above.
10.0Industrial FacilitiesThe construction, conversion, or expansion of industrial facilities for production, inventory, and contractor depot maintenance required when that service is for the specific system. Includes equipment acquisition or modernization, where applicable, maintenance of these facilities or equipment, and industrial facilities for hazardous waste management to satisfy environmental standards.
11.0Initial Spares and Repair PartsIncludes deliverable spare components, assemblies and subassemblies used for initial replacement purposes in the materiel system equipment end item. This includes any repairable spares and repair parts required as initial stockage to support and maintain newly fielded systems or subsystems during the initial phase of service, including pipeline and war reserve quantities, at all levels of maintenance and support. Note it does not include development test spares and spares provided specifically for use during installation, assembly, and checkout on site.
12.0Government System Engineering/Program ManagementThis element is a rollup of Work Breakdown Structure (WBS) sub elements that contain the Government's expenses involved with the overall management and technical direction costs associated with the program up to FOC. Following FOC, costs for this function/WBS element are transitioned to WBS element 13.8, Sustaining Engineering and Program Management.
12.1System EngineeringThis element contains the Government, FFRDC, and support contractor resources associated with engineering activities in support of the overall system. Activities in this element include: 1.) Effort to create and manage technical/system requirements, architecture and documentation; 2.) System engineering management - oversight to include contract/technical task management, prepare Statement Of Works (SOWs), and monitor technical execution; 3.) Effort to develop and support independent modeling for systems engineering activities (i.e. modeling and simulation, failure recovery analysis, etc.). This element also includes any development performed by the Government, FFRDC, Universities, etc.
12.2Program ManagementIncludes the Government resources associated with the business and administrative planning, organizing, directing, coordinating, controlling, and approval actions designated to accomplish overall program objectives which are not associated with specific hardware elements and are not included in systems engineering. Includes:
1.) Cost, schedule, performance measurement management, warranty administration, contract management, data management, vendor liaison, subcontract management, travel, etc.
2.) Support element management, defined as the logistics tasks management effort and technical control, and the business management of the support elements. The logistics management function encompasses the support evaluation and supportability assurance required to produce an affordable and supportable defense materiel system.
3.) Planning and management of all the functions of logistics such as maintenance support planning and support facilities planning; other support requirements determination; support equipment; supply support; packaging, handling, storage, and transportation; provisioning requirements determination and planning; training system requirements determination; computer resource determination; organizational, intermediate, and depot maintenance determination management; and data management.
12.3Mission Assurance PlanningIncludes Government resources associated with Mission Assurance (MA) planning and generation of measures intended to provide a defined and accepted level of confidence that the delivered system can meet expected mission objectives under a wide range of operating conditions. Also, identified is the level of residual risk and the documentation of the conscious decision to accept that risk. As a minimum, MA involves:
12.3.1Defining Critical Objectives
12.3.2Providing a Continuum of Capabilities
12.3.3Defining the Range of Operating Conditions
12.3.4Measuring Confidence
12.3.5Enhancing Readiness planning
12.3.6Continuity of Operations Planning/Preplanning, often referred to as COOP
12.3.7Critical Infrastructure Protection (CIP) planning
12.4Information AssuranceIncludes the effort of Government resources involved in assuring that information systems are protected from unauthorized access and that the confidentiality, integrity and availability of the systems is maintained. This includes providing for restoration of information systems by incorporating protection, detection and reaction capabilities.
It includes all efforts to achieve security certification and accreditation (C&A) as defined by the NSA/CSS Information System Certification and Accreditation Process (NISCAP) for systems designed to process information.
System Verification demonstrates that all security- critical functions of an INFOSEC equipment or system are implemented in the manner that was intended as defined by NSA approved design specifications. Testing involves exercising an actual implementation of a system or product to determine certain characteristics of its operation. System Verification Testing (SVT) consists of three subtasks: test planning, actual testing, and test reporting. A "Security Verification Test Plan and Procedures" document is developed by the contractor based on the design specifications. The SVT plan describes the test conditions, data, coverage, and procedures for all of the tests to be performed. Reporting consists of analyzing each test and documenting the results along with a set of conclusions about the product's or system's conformance to its specifications and about the resultant security provided. Testing is typically done after working prototypes of the product or system exist, but before any are fielded.
13.0Operations and SupportOperations and Support of a system at all sites. Includes the management, operational personnel, and maintenance of all hardware and software elements throughout the life cycle after close of development and production or deployment fielding. Shall include the rollup of all sub-elements. Operation and Maintenance efforts start with development of Operations & Maintenance (O&M) operational procedures, training aids and courses and continue through system shut down and retirement. It includes the overall on-site and off-site maintenance of all system hardware and software.
13.1Hardware MaintenanceThis element is a summation of elements containing all costs to maintain and repair the system hardware. It includes personnel for functions such as troubleshooting, debugging, etc. plus long-term planning, and ground hardware and documentation updates. It includes maintenance personnel providing periodic, scheduled and unscheduled, maintenance of COTS or custom hardware. It also includes all maintenance materials and consumables used in the operation and maintenance.
13.1.1Licenses/Vendor Maintenance Agreements (COTS/GOTS)This element includes the cost of licenses/vendor maintenance agreements associated with the maintenance and repair of system hardware.
13.1.2Spares/RepairsThis element includes costs for site replenishment spares and fixes/repairs to system hardware. Fixes/repairs would include parts, labor and other materials that are required to repair and maintain the system hardware.
13.2Software MaintenanceIncludes all costs for software maintenance (e.g., version updates), including all costs for labor, materials, and contracts. Software maintenance consists of modifying existing software without changing its primary functions. Maintenance can include redesign and recoding of small portions of the original product, redesign and redevelopment of interfaces, and minor modifications of the product structure. Product repairs can classified as corrective (failures in processing, performance or implementation), adaptive (changes in the processing or data environment) or perfective (enhancing performance or maintainability).
13.2.1Licenses/Vendor Maintenance Agreements (COTS/GOTS)Includes costs of licenses/vendor maintenance agreements (e.g., annual software license fees for COTS software) associated with the maintenance and repair of system software.
13.2.2Custom Software MaintenanceThis element includes maintenance personnel providing periodic, scheduled and unscheduled, maintenance of custom software. Maintenance can be classified as either updates or repairs. Custom Software maintenance consists of modifying existing software without changing its primary functions. Maintenance can include redesign and recoding of small portions of the original product, redesign and redevelopment of interfaces, and minor modifications of the product structure. Product repairs can classified as corrective (failures in processing, performance or implementation), adaptive (changes in the processing or data environment) or perfective (enhancing performance or maintainability).
13.2.3Security Testing and IntegrationThis element includes the NISCAP recertification efforts during the operations and support period.
13.3Data MaintenanceIncludes the cost of any additional (over and above the current workforce) database administrators and resources incurred as a result of the system being fielded. Primarily responsible for monitoring, administrating, and implementing performance tuning on database systems. Duties may include developing shell scripts to load or dump database information, optimizing database performance (i.e. developing/changing database indices), and the loading/reloading data into the database.
13.4Tech RefreshThis element captures the cost of updating COTS/GOTS software/hardware to take advantage of the latest technological advances/versions and to address hardware and COTS Software obsolescence. Also included in this element are the system assembly, integration and checkout on site of the Hardware and Software.
Excluded from this element:
1.) Costs associated with increased system functionality which should be covered as an investment cost.
2.) Costs associated with Pre-Planned Product Improvements (P3I) investment costs.
3.) Costs associated with maintenance of existing software which are included in WBS element 13.2, Software Maintenance.
13.4.1COTS Software RefreshThis element is used to capture refresh costs associated specifically with software updates. It includes the purchase of software updates, however the engineering support required to make refresh determinations is excluded from this element and is included in 13.8, Sustaining Engineering and Program Management. Any refresh costs covered by the annual maintenance agreement are excluded from this element.
13.4.2COTS Hardware RefreshThis element captures refresh costs associated specifically with hardware updates. It includes the purchase of hardware updates, however the engineering support required to make refresh determinations is excluded from this element and is included in 13.8, Sustaining Engineering and Program Management.
13.5System SecurityIncludes all recurring security related costs, including personnel and physical security, directly related to the system.
13.6Recurring TrainingIncludes costs related to training and retraining on system specific tasks after the fielding of the operating system.
13.7Help DeskThis element includes all resources necessary to provide a centrally managed, tier-based customer support service. Tier levels are typically defined based on criticality, severity and type of problem resolution required (i.e., hardware versus software). Representative activities include: troubleshooting efforts, resolving user application issues, fail-overs, maintenance, file issues, basic system communication issues, data interface issues, installation problems, and system upgrade assistance. This element also includes administrative efforts such as maintaining a centrally managed support number, monitoring/managing system change requests/system incident reports (SCRs/SIRs), and managing the service desk and trouble ticket tracking system.
13.8Sustaining Engineering and Program ManagementThe labor, material and overhead costs incurred in providing continued systems engineering and program management oversight to manage the program and to determine the integrity of a system, to maintain operational reliability, to approve design changes to ensure conformance with established specifications and standards and the engineering support required to make hardware and software refresh determinations. When a separate program management office is established or is separately identifiable from the acquisition support management office, the costs of the support program management office will be included in this element.
Costs reported in this category may include, but are not limited to, Government and contract engineering services, studies, and technical advice continuing after FOC.
13.9CommunicationsThis cost element aggregates the cost of leasing and maintenance for the system communication costs. This element shall include leased long lines, long distance networks for data and voice, and other costs to interconnect components of the system. When communications are shared with other systems, costs will be prorated.
13.10Mission Assurance Peculiar Activity SupportIncludes Mission Assurance (MA) Peculiar Activity Support in this phase involved in the conduct of Continuity of Operations or COOP. This includes personnel and related costs required above and beyond the normal agency COOP directly linked to the system.
13.11Site OperationsIncludes all personnel and equipment specifically functioning to operate the system. Representative activities include training, security, communications, fuel, and facilities maintenance.
13.11.1PersonnelIncludes cost of Government (civilian & military) and contractor personnel required to operate the system including system administrators.
13.11.2ConsumablesThis element includes the cost of all expendable material or supply items (excluding replenishment spares and items included in Site Operations) consumed in operating and maintaining a system.
13.11.3Infrastructure MaintenanceIncludes the cost of maintenance required to operate and support the infrastructures, facilities, etc. It includes expenditures made to maintain physical plant, such as utilities, rents, etc. WBS element will contain direct Government expenditures, as well as Contractor expenditures, if applicable.
13.11.3.1Facilities LeaseThis element includes costs for leasing spaces and associated maintenance to be used by personnel or prime mission equipment.
13.11.3.2UtilitiesThis element includes the cost for utilities such as power, water, etc. used to power and cool all system equipment as well as other power costs incurred due to the presence of the system. Power and utility rates should include any applicable surcharges, etc. in the cost per unit.
14.0DisposalIncludes all costs associated with disposal management, dismantling, removal, site restoration, destruction of storage media, and salvage of decommissioned equipment or system. Includes any costs for demilitarization and disposal of hazardous materials.
2.2Format 2A/B - Technical Report: SoftwareThis report is to be delivered for each contract increment for each Computer Software Configuration Item (CSCI). Two submissions are required per increment, one at the beginning (Format 2A) of the increment representing the estimate and the second (Format 2B) at the end of the increment representing the actual. The Government will provide as Government Furnished Information (GFI) both report formats in Microsoft EXCEL along with a script to assist collection for Format 2B.
2.2.1Format 2A, Technical Report: Estimate (Due at increment start)This report is to be delivered for each contract increment for each Computer Software Configuration Item (CSCI). Two submissions are required per increment, one at the beginning (Format 2A) of the increment representing the estimate and the second (Format 2B) at the end of the increment representing the actual. The Government will provide as Government Furnished Information (GFI) both report formats in Microsoft EXCEL along with a script to assist collection for Format 2B.
2.2.1.1Section A: CSCI/Project Information
2.2.1.1.1ContractorEnter contractor's name and company division in 1a, primary work location in 1b, contractor role (prime/subcontractor) in 1c, and designated prime contract number from the procuring agency in 1d.
2.2.1.1.2ScheduleEnter in 2a year, month, and day of the estimated/actual start date for increment being reported. Enter in 2b year, month, and day of the estimated/actual completion date for increment being reported. Enter in 2c the date of report completion. Enter in 2d the current version number of the software being developed if applicable.
2.2.1.1.3Name of Computer Software Configuration Item (CSCI) or ProjectEnter the name of the CSCI, program, project or system being reported.
2.2.1.1.4Corresponding Contract Breakdown Structure (CBS) NumberEnter the corresponding CBS number for the CSCI being reported.
2.2.1.2Section B: Process Information/Requirements
2.2.1.2.1Application TypeIf CSCIs are designated, describe the planned primary generic function for the CSCI being reported, otherwise describe the planned primary generic function of the program. Possible descriptions could include Web, Management Information System (MIS), Database, Signal Process, Analytical, Cryptologic, etc.
2.2.1.2.2Development MethodDescribe the planned development method(s). Possible descriptions could include: None, Evolutionary, Incremental, COTS Integration, Prototype, Rapid Application Development, Spiral, Waterfall, Agile, etc.
2.2.1.2.3Percent Code Designed for Re-UseEnter the percentage of code that is planned to be developed for reuse in the future on other systems. Use in subsequent releases of the existing system shall not be considered reuse. If no formal requirement is documented for the CSCI or project, requiring the development of reusable code, enter 0%.
2.2.1.2.4CMM/CMMI LevelEnter the Software Engineering Institute's (SEI) Capability Maturity Mode (CMM) or Capability Maturity Model Integrated (CMMI) level, at the time of report generation, for the primary contractor responsible for the CSCI or project. Possible responses are Level 1, Level 2, Level 3, Level 4, Level 5 ONLY.
2.2.1.2.5CMM/CMMI Level based on Self Assessment or External AssessmentEnter Self-Assessment or External-Assessment to support SEI level entered in Format 2, Section B element 8.
2.2.1.2.6Total Number of RequirementsEnter an integer number representing the planned TOTAL number of requirements approved and allocated to this CSCI, and specify requirement source documents.
2.2.1.3Section C: Software MetricsComplete number 11 to describe the primary approach used to estimate the size of this CSCI or project. Provide Source Lines of Code (SLOC) and Object Oriented (OO) metrics in numbers 12 and 13.
2.2.1.3.1Project MetricsDescribe the method used to estimate the size of this CSCI or project.
2.2.1.3.1.1Sizing MethodologyEnter the primary estimating method (e.g. COSMIC, Mark II, IFPUG, Top-Down, Bottom-Up, Object Metrix, Object Points, Analogy, Expert Opinion, etc.) used to estimate the software size for this CSCI or program. If the method used to estimate this CSCI or program is Analogy, identify the analogous data point and provide its corresponding metrics in #15, Software Size Remarks.
2.2.1.3.1.2Unit of MeasureEnter the unit of measure (e.g. function points, SLOC, Use Cases, Object Points, etc.) for the methodology being used to estimate the software size of this CSCI or program.
2.2.1.3.1.3SizeEnter the estimated size in the same units-of-measure indicated in 11b.
2.2.1.3.2SLOC EstimateQuantify the estimated SLOC for this CSCI even if another sizing method was used for 11 above. If the unit of measure provided in 11b above is SLOC then the information in 12a should be consistent with the size provided in 11c.
2.2.1.3.2.1SLOC-Count TypeSpecify Physical SLOC, Delivered Source Instructions, Logical SLOC, or Other (if other is specified provide a description in #15, Software Size Remarks.)
2.2.1.3.2.2SLOC-Count MethodologyEnter the estimating methodology used to determine the software size for this CSCI or project. Specify Subject Matter Expert (SME), Analogy, Engineering Build, or Other (if other is specified provide a description in #15, Software Size Remarks. For analogy estimates, identify the analogous data point and its corresponding metrics in #15, Software Size Remarks. If the method used to estimate SLOC is a conversion of the size metric provided in 11c, provide the conversion algorithm in #15, Software Size Remarks.
2.2.1.3.2.3Estimated New Source Lines of Code (SLOC)Enter the estimated new source lines of code required to for this CSCI.
2.2.1.3.2.4Estimated Re-Used SLOCEnter the estimated re-used source lines of code that this CSCI will contain. If the methodology to determine Re-Used SLOC is different from that to determine New SLOC then specify in #15, Software Size Remarks.
2.2.1.3.3OO MetricsProvide any additional sizing metrics in numbers 13a through 13d if they are applicable to this CSCI or project.
2.2.1.3.3.1Number of Use CasesEnter the number of use cases. A use case describes a dialogue between an external actor and the system. A use case comprises a sequence of activities performed by an end user in the course of their work that results in measurable business benefit for the user. Essentially it forms a complete business transaction. The (Unified Modeling Language or UML) specification states that a use case is a kind of classifier representing a coherent unit of functionality provided by a system, as manifested by sequences of messages exchanged among the system and one or more outside inter-actors (called actors) together with actions performed by the system.
2.2.1.3.3.2Number of ClassesEnter the number of classes. Classes are the embodiment of key business concepts, which can be expressed in the vocabulary of the business domain. A class can model a physical real-world entity or an abstract concept. Classes contain information, support behavior and maintain relationships with other classes. Classes enforce business rules and provide integrity checking. The UML specification states that a class is the descriptor for a set of objects with similar structure, behavior, and relationships. Also describe the intention of the class, that is, the rules that define it.
2.2.1.3.3.3Number of Web PagesEnter the number of web pages developed to support this CSCI or project. If dynamic web pages are used, only count the base template as one web page.
2.2.1.3.3.4Number of InterfacesEnter the number of interfaces. Interfaces provide a well-defined programming specification to access the capabilities of a component, subsystem, or class. An interface separates external services from internal implementation, and defines a protocol that permits polymorphic design. The UML specification states that an interface is a specifier for the externally visible operations of a class, component, or other classifier (including subsystems) without specification of internal structure. Each interface often specifies only a limited part of the behavior of an actual class. Interfaces do not have implementation. They lack attributes, states, or associations; they only have operations. (An interface may be the target of a one-way association, however, but it may not have an association that it can navigate). Interfaces may have generalization relationships. An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations, but interface is a peer of class within the UML metamodel.
2.2.1.3.4Estimated EffortEnter the estimated hours and cost associated with developing, designing, coding, integrating and testing this CSCI or project. This information must correspond to the lowest level CSCI breakout in Format 1.
2.2.1.3.5Software Size RemarksDescribe the methodology used to estimate this CSCI or project. Identify analogous data points used for this estimate and provide their corresponding metrics.
2.2.1.3.6Programming LanguageEnter the programming language(s) that are planned for use in developing this CSCI.
2.2.1.3.7COTS/GOTSReplicate elements 17a -17e for each COTS/GOTS package used in this CSCI or project. If a COTS/GOTS package is used in multiple CSCIs or projects, then complete this section only once.
2.2.1.3.7.1Package NameEnter the name of the COTS package planned for use in this CSCI.
2.2.1.3.7.2Version NumberEnter the version number of the COTS package.
2.2.1.3.7.3Number of LicensesEnter the number of licenses that will be required for the COTS package.
2.2.1.3.7.4Cost per LicenseEnter the unit cost per license for the COTS package.
2.2.1.3.7.5Yearly Maintenance CostEnter the yearly maintenance cost associated with the COTS package.
2.2.1.3.7.6DescriptionProvide a brief description of the COTS functionality.
2.2.1.3.8RemarksThis space is provided to include any comments necessary to clarify or provide additional information to the entries on this form. For example, provide the percentage of functionality satisfied by each COTS/GOTS package.
2.2.2Format 2B, Technical Report: Actuals (Due at end of increment)
2.2.2.1Section A: CSCI/Project Information
2.2.2.1.1ContractorEnter contractor's name and company division in 1a, primary work location in 1b, contractor role (prime/subcontractor) in 1c, and designated prime contract number from the procuring agency in 1d.
2.2.2.1.2ScheduleEnter in 2a year, month, and day of the estimated/actual start date for increment being reported. Enter in 2b year, month, and day of the estimated/actual completion date for increment being reported. Enter in 2c the date of report completion. Enter in 2d the current version number of the software being developed if applicable.
2.2.2.1.3Name of Computer Software Configuration Item (CSCI) or ProjectEnter the name of the CSCI, program, project or system being reported.
2.2.2.1.4Corresponding Contract Breakdown Structure (CBS) NumberEnter the corresponding CBS number for the CSCI being reported.
2.2.2.2Section B: Process Information
2.2.2.2.1Application TypeIf CSCIs are designated, describe the planned primary generic function for the CSCI being reported, otherwise describe the planned primary generic function of the program. Possible descriptions could include: Web, MIS, Database, Signal Process, Analytical, Cryptologic, etc.
2.2.2.2.2Development MethodDescribe the planned development method(s). Possible descriptions could include: Evolutionary, Incremental, COTS Integration, Prototype, Rapid Application Development, Spiral, Waterfall, etc.
2.2.2.2.3Percent Code Designed for Re-UseEnter the percentage of code that that was developed for reuse in the future on other systems. Use in subsequent releases of the existing system shall not be considered reuse. If no formal requirement is documented for the CSCI or project, requiring the development of reusable code, enter 0%.
2.2.2.2.4CMM/CMMI LevelEnter the Software Engineering Institute (SEI) Capability Maturity Model (CMM)/ Capability Maturity Model Integration (CMMI) level, at the time of report generation, for the primary contractor responsible for the CSCI or project. Possible responses are: Level 1, Level 2, Level 3, Level 4, Level 5 ONLY.
2.2.2.2.5CMM/CMMI Level based on Self-Assessment or External AssessmentEnter Self-Assessment or External-Assessment to support SEI level entered in Format 2, Section B element 8.
2.2.2.3Section C: Requirements
2.2.2.3.1Total Number of RequirementsEnter an integer number of actual total requirements implemented by this CSCI or project, and specify requirement source documents.
2.2.2.3.2Requirements VolatilityDescribes the requirements volatility for the CSCI or project. Shall describe the volatility by entering one of the following definitions:
Extra High - Requirement Volatility >25%
Very High - Requirement Volatility > 15% and <= 25%
High+ - Requirement Volatility > 10% and <= 15%
High - Requirement Volatility > 3% and <= 10%
Nominal - Requirement Volatility > 1% and <= 3%
Low - Requirement Volatility <= 1%
Percentages used to quantify the requirements volatility for the CSCI or project shall be calculated based on the equation below.
requirement volatility = ((added + deleted + changed) / total # of requirements) * 100
Requirements volatility represents the total change traffic applied to an agreed-to release plan. It can be greater than 100% if more changes occurred than the number of requirements originally planned for the release.
2.2.2.4Section D: Software MetricsComplete number 11 to describe the primary approach used to measure the size of this CSCI or project. Provide SLOC and Object Oriented (OO) metrics in numbers 12 and 13.
2.2.2.4.1Project MetricsDescribe the method used to measure the size of this CSCI or project.
2.2.2.4.1.1Sizing MethodologyEnter the primary software sizing method (e.g. COSMIC, Mark II, IFPUG, Top-Down, Bottom-Up, Object Metrix, Object Points, SLOC count, etc.), used during the development of this CSCI or project.
2.2.2.4.1.2Unit of MeasureEnter the unit of measure (e.g. function points, SLOC, Use Cases, Object Points, etc.) for the methodology being used.
2.2.2.4.1.3SizeEnter the actual software size in the same units-of-measure indicated in 11b.
2.2.2.4.2SLOC MetricsQuantify the SLOC for this CSCI. If the unit of measure provided in 11b above is SLOC then the information in 12a should be consistent with the size provided in 11c. Specify Physical SLOC, Delivered Source Instructions, or Logical SLOC.
2.2.2.4.2.1SLOC-Count TypeSpecify Physical SLOC, Delivered Source Instructions, Logical SLOC, or Other (if other is specified provide a description in #15, Software Size Remarks).
2.2.2.4.2.2SLOC-Count MethodologyEnter the methodology used to measure the SLOC generated for this CSCI or project. If the method used to estimate SLOC is a conversion of the size metric provided in 11c, the conversion algorithm shall be provided in #15, Software Size Remarks. If a code-counting tool was used to measure SLOC, reference the tool used.
2.2.2.4.2.3New Source Lines of Code (SLOC)Enter the actual new source lines of code created for this CSCI. The SLOC entered for this element shall be consistent with the SLOC provided by programming language in section 16A of this form.
2.2.2.4.2.4Re-Used SLOCEnter number of actual re-used source lines of code for this CSCI. The SLOC entered for this element should equal the summation of the SLOC provided by programming language in section 17C of this form. If the methodology to determine Re-Used SLOC is different from that to determine New SLOC then specify in #15, Software Size Remarks.
2.2.2.4.3OO MetricsProvide the additional sizing metrics in numbers 13a through 13d if they are applicable to this CSCI or project.
2.2.2.4.3.1Number of Use CasesEnter the number of use cases. A use case describes a dialogue between an external actor and the system. A use case comprises a sequence of activities performed by an end user in the course of their work that results in measurable business benefit for the user. Essentially it forms a complete business transaction. The Unified Modeling Language (UML) specification states that a use case is a kind of classifier representing a coherent unit of functionality provided by a system, as manifested by sequences of messages exchanged among the system and one or more outside inter-actors (called actors) together with actions performed by the system.
2.2.2.4.3.2Number of ClassesEnter the number of classes. Classes are the embodiment of key business concepts, which can be expressed in the vocabulary of the business domain. A class can model a physical real-world entity or an abstract concept. Classes contain information, support behavior and maintain relationships with other classes. Classes enforce business rules and provide integrity checking. The UML specification states that a class is the descriptor for a set of objects with similar structure, behavior, and relationships. Also describe the intention of the class, that is, the rules that define it.
2.2.2.4.3.3Number of Web PagesEnter the number of web pages developed to support this CSCI or project. If dynamic web pages are used, only count the base template as one web page.
2.2.2.4.3.4Number of InterfacesEnter the number of interfaces. Interfaces provide a well-defined programming specification to access the capabilities of a component, subsystem, or class. An interface separates external services from internal implementation, and defines a protocol that permits polymorphic design. The UML specification states that an interface is a specifier for the externally visible operations of a class, component, or other classifier (including subsystems) without specification of internal structure. Each interface often specifies only a limited part of the behavior of an actual class. Interfaces do not have implementation. They lack attributes, states, or associations; they only have operations. (An interface may be the target of a one-way association, however, but it may not have an association that it can navigate). Interfaces may have generalization relationships. An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations, but interface is a peer of class within the UML metamodel.
2.2.2.4.4Actual EffortEnter the actual effort in terms of both hours and dollars for this CSCI or project. This information must correspond to the lowest level CSCI breakout in Format 1. For example, the hours and dollars for CSCI 1 include WBS elements 1.2.1.1.1 through 1.2.1.1.6.
2.2.2.4.5Software Size RemarksProvide any amplifying comments necessary to clarify the information provided in Format 2B.
2.2.2.4.6Programming LanguageProvide System Measures (16A), OO Measures (16B) and Re-Use Measures (16C) for each language (i.e. programmatic, shell, scripting, html, embedded, etc.) used to develop this CSCI or project. 16B, OO Measures, is only required if the language is object oriented (i.e., Java, C++, etc.). If the automated version of this DID is not used, replicate sections 16A, 16B and 16C for each programming language. Otherwise, the automated spreadsheet provided will facilitate the input of data by language.
Example: A program consists of two languages, JAVA and C++, with no reused code for JAVA and reused code for C++. Elements 16A-16C will be replicated twice, once for each language. For Java, element 16A and 16B will be completed with the actual values and element 16C will be completed with N/A. For C++ code, element 16A will be completed and element 16C will be completed for the reused part of the C++ code.
2.2.2.4.6.1System MeasuresThis element reports the total system measures by language for the entire CSCI or project, including reused code.
2.2.2.4.6.1.1Number of FilesEnter the number of files in the system for the specified language.
2.2.2.4.6.1.2Delivered Source InstructionsEnter the number of all Delivered Source Instructions (DSI) in the system. DSI includes executable and declarative lines of code such as control statements, mathematical statements, conditional statements, input/output & formatting, data declarations, function declarations, etc.
2.2.2.4.6.1.3Comment LinesEnter the sum of all lines of code in the system that contains some form of comments.
2.2.2.4.6.1.4Comment DensityEnter the sum of all comment lines that actually contain a comment (i.e. words) and are not simply separators.
2.2.2.4.6.1.5Blank LinesEnter the sum of all Blank lines of code in the system that contain no instruction or comment characters.
2.2.2.4.6.1.6Total LinesEnter the total number of all lines.
2.2.2.4.6.2OO MeasuresThis element, if applicable, reports the TOTALS by language for the entire CSCI or project, including reused code. 16B parameters only apply if object oriented code was used for this CSCI or project.
2.2.2.4.6.2.1Number of ClassesEnter the number of classes. Classes are the embodiment of key business concepts, which can be expressed in the vocabulary of the business domain. A class can model a physical real-world entity or an abstract concept. Classes contain information, support behavior and maintain relationships with other classes. Classes enforce business rules and provide integrity checking. The UML specification states that a class is the descriptor for a set of objects with similar structure, behavior, and relationships. Also describe the intention of the class, that is, the rules that define it.
2.2.2.4.6.2.2Number of Sub-SystemsEnter the number of subsystems. A subsystem is a logical partitioning of the business domain. It is a grouping of related system software that supports one or more complete business processes. A subsystem provides a meaningful and useful subset of end user functionality and typically supports the job activities for one or more user roles within an organization. A subsystem typically provides a consistent and well-formed user interface. The UML specification states that a subsystem represents a behavioral unit in the physical system, and hence in the model. The UML specification states that a subsystem offers interfaces and has operations, and its contents are partitioned into specification and realization elements. The specification of the subsystem consists of operations on the subsystem, together with specification elements such as use cases and stat machines. Apart from defining a namespace, a subsystem serves as a specification unit for the behavior of its contained model elements.
2.2.2.4.6.2.3Number of ComponentsEnter the number of components. A component is a physical and replaceable part of a system that conforms to, and implements, a set of interfaces. Components form the building blocks for systems. They can encapsulate environment specific details, implement business frameworks or wrap traditional technology. The UML specification states that a component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. A component conforms to the interfaces that one exposes, where the interfaces represents services provided by elements that reside on the component. One or more artifacts, such as binary, executable, or script files, may implement a component. A component may be deployed on a node.
2.2.2.4.6.3Re-Use MeasuresThis element is strictly for reused code; code used but not developed for this CSCI or project. Elements 16C is Not Applicable if no reused code exists for a specific language. Do not include COTS packages in these totals. Code is not considered reused simply because it is used in subsequent releases on the existing system. Element 16C refers only to code developed outside this CSCI or project. Element 16C is a subset of the totals reported in element 16A.
2.2.2.4.6.3.1Number of FilesEnter the number of files in the system for the specified language.
2.2.2.4.6.3.2Delivered Source InstructionsEnter the sum of all Delivered Source Instructions (DSI) in the system. DSI includes executable and declarative lines of code such as control statements, mathematical statements, conditional statements, input/output & formatting, data declarations, function declarations, etc.
2.2.2.4.6.3.3Comment LinesEnter the sum of all lines of code in the system that contains some form of comment.
2.2.2.4.6.3.4Comment DensityEnter the sum of all comment lines that actually contain a comment (i.e. words) and are not simply separators
2.2.2.4.6.3.5Blank LinesEnter the sum of all blank lines in the system that contain no instruction or comment characters.
2.2.2.4.6.3.6Total LinesEnter the total number of source lines of code.
2.2.2.4.6.3.7Percent Re-design effortEnter the amount of any re-design, re-work or coding modification done to the reused package for this CSCI/project. Express the amount as a percentage of the total code base of the reused package. For example, if the reuse package contains 1000 lines of code (LOC) and 125 LOC were modified then 12.5% would be entered ((# LOC modified / Total # of LOC) * 100)
2.2.2.4.7COTS/GOTSReplicate elements 17a -17e for each COTS/GOTS package used in this CSCI or project. If a COTS/GOTS package is used in multiple CSCIs or projects, then complete this section only once.
2.2.2.4.7.1Package NameEnter the name of the COTS package planned for use in this CSCI.
2.2.2.4.7.2Version NumberEnter the version number of the COTS package.
2.2.2.4.7.3Number of LicensesEnter the number of licenses that will be required for the one COTS package.
2.2.2.4.7.4Cost per LicenseEnter the cost per license for the one COTS package.
2.2.2.4.7.5Yearly Maintenance CostEnter the yearly maintenance cost associated with the COTS package.
2.2.2.4.7.6DescriptionProvide a brief description of the COTS functionality.
2.2.2.4.8RemarksThis space is provided to include any comments necessary to clarify or provide additional information to the entries on this form. For example, provide the percentage of functionality satisfied by each COTS/GOTS package.
2.3Format 3 - Technical Report: COTS and Custom Hardware
2.3.1Format 3A Technical Reports: COTS Hardware
2.3.1.1ProgramName of the program, project, or system.
2.3.1.2ContractorProvide name of prime contractor and name of hardware contractor if different.
2.3.1.3Prime Contract NumberEnter the designated prime contract number from the procuring agency.
2.3.1.4Dollars InDenote entries that are factored down by thousands (K) or millions (M).
2.3.1.5COTS Hardware InformationThe following elements provide details for each hardware item with a unit cost greater than or equal to $2,000
2.3.1.5.1CBS NoIndicate the CBS number where the HWCI is used.
2.3.1.5.2ElementProvide the Hardware Item name.
2.3.1.5.3Part DescriptionProvide the hardware nomenclature at appropriate indentures of the CBS (e.g., Command & Control (CBS element)/Server (HWCI) /Sun 450 (Specific Part)).
2.3.1.5.4SupplierIdentify the supplier/vendor of the item.
2.3.1.5.5QuantityIndicate the quantity required to satisfy the function, including initial spares.
2.3.1.5.6Unit CostProvide the cost for each item.
2.3.1.5.7Total CostCalculation of total cost based on quantity and unit cost provided.
2.3.1.5.8YearIndicate the year in which the item will be purchased or acquired.
2.3.1.5.9ParametersProvide parameters/values for key technical descriptors or descriptive data for each element (e.g., for the server example above, this could be processor speed, # of processors, memory.) Some examples of desired parameters by hardware type are shown in the table below. Other parameters may also be provided and other relevant parameters may be added for hardware items not shown in the table (e.g., switches, routers).
2.3.2Format 3B Technical Reports: Custom HardwareA Custom Hardware Data Sheet should be completed for all non-COTS/GOTS hardware elements of the proposed system. The elements listed on the Custom Hardware Data Sheet are provided as guidance for an example of a newly developed electronic box/chassis (terms used interchangeably here). Provide a similar level of detail for any newly developed hardware elements (i.e., relevant descriptive parameters). Enter N/A for any item within the data sheet that is not applicable to a particular entry. Use as many sheets as necessary to incorporate all boards within a box; use a separate sheet for each box. The terminology used herein is that boards roll up into boxes, which roll up into racks, which roll up into subsystems, which roll up into ground elements. Costs at each level should be traceable up to the next higher level.
2.3.2.1ProgramName of the program, project, or system.
2.3.2.2CBS NumberIndicate the CBS number where the HWCI is used.
2.3.2.3ContractorProvide name of prime contractor and name of hardware contractor if different.
2.3.2.4Rack NameProvide the name of the rack into which the boxes roll up (e.g., telemetry processor).
2.3.2.5Box NameProvide the name of the electronic box being developed (e.g., mass memory unit).
2.3.2.6ApplicationBriefly describe the function of the hardware item being developed.
2.3.2.7Identify Rack versus Chassis Power SupplyDoes the item have a built-in power supply or does it obtain power from a rack-mounted power supply?
2.3.2.7.1Installed Power Supply (watts)Identify the source and amount of power required. Also identify vendor, part number and power supply cost.
2.3.2.7.2Total Populated WeightIdentify total weight of the rack/item in pounds.
2.3.2.7.3Rack Dimensions (inches)Identify dimensions of the rack in inches.
2.3.2.8BoxProvide parameters of any individual boxes in the rack.
2.3.2.8.1Box Dimensions (inches)Identify dimensions of the box in inches.
2.3.2.8.2Installed Power Supply (watts)Provide installed power in watts.
2.3.2.9Custom Boards/CardsComplete one column for each board/card.
2.3.2.9.1Board nameEnter the name of the board.
2.3.2.9.2Number of boards/cards per boxEnter the number of boards or cards per box.
2.3.2.9.3Typical Power (watts)Amount of power used per board for heat dissipation.
2.3.2.9.4Board/Card Dimensions (inches)Enter the dimensions for the board or card in inches.
2.3.2.9.5Parts Technology Allocation (Percent of Area)Provide the percent of total board area that each part technology occupies (e.g., 50% analog, 13% VHSIC/VLSI, 2.2% SAW-Crystal, .8% GaAs MMIC C band, 34% unoccupied).
2.3.2.9.6Number of board layersEnter the number of board layers.
2.3.2.9.7Input type and speed (Mbps max)Analog or digital input? Identify key signal characteristics (e.g., bandwidth for analog; speed for digital).
2.3.2.9.8Output type and speed (Mbps max)Analog or digital output? Identify key signal characteristics (e.g., bandwidth for analog; speed for digital).
2.3.2.9.9Field Programmable Gate Array (FPGA) vendorProvide vendor, if board includes FPGA(s).
2.3.2.9.10FPGA part numberEnter the FPGA part number.
2.3.2.9.11FPGA costEnter the FPGA cost (thru General and Administrative (G & A), not including Fee or COM).
2.3.2.9.12FPGA gates/pinsEnter the FPGA gates and pins.
2.3.2.9.13Embedded Computer vendorProvide vendor, if board includes an embedded computer.
2.3.2.9.14Embedded Computer part numberEnter the part number for the embedded computer.
2.3.2.9.15Embedded Computer costEnter the cost for the embedded computer (thru G&A, not including Fee or COM)
2.3.2.10COTS BoardsComplete entries below if the box includes COTS boards, as well as custom boards
2.3.2.10.1VendorEnter the name of the vendor for the COTS board(s).
2.3.2.10.2Part NumberEnter the part number for the COTS board(s).
2.3.2.10.3Number of boards per boxEnter the number of boards per box.
2.3.2.10.4Cost per boardEnter the cost per board (thru G&A, not including Fee or COM).
2.3.2.11Board/Module CostTotal cost of each board (thru G&A, not including Fee or COM).
2.3.2.12Box CostRoll up of cost of all boards in the box named above (thru G&A, not including Fee or COM).
2.3.2.13Rack CostRoll up of cost of all boxes in the rack named above (thru G&A, not including Fee or COM).
References
—
Figures
Figure 1. Figure 1 - Format 1: Cost Breakdown Structure (part 1 of 2)
Figure 1. Figure 1 - Format 1: Cost Breakdown Structure (part 2 of 2)
Figure 2. Figure 2 - Format 2A: Software Technical Report: Estimate
Figure 3. Figure 3 - Format 2B: Software Technical Report: Actuals
Figure 4. Figure 4 - Format 3A: COTS Hardware Information
Figure 5. Figure 5 - Format 3B: Custom Hardware Information
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer
Verify against ASSIST·GitHub·About·Disclaimer