Attch_0004_TROPO_PWS_Appendix_C_v2_CDA_Input_Data.pdf

UNCLASSIFIED

AN/TRC-XXX

Troposcatter System

Appendix C

Core Depot Assessment (CDA) Input Data

Requirements

13 June 2017

Prepared by:

Project Manager, Tactical Network

ATTN: SFAE-CCC-TN

Aberdeen Proving Grounds, MD 21005

DISTRIBUTION A. Approved for public release: distribution unlimited. Other request for this document shall be referred to PEO C3T/PM Tactical Network, 6010 Frankford St., Aberdeen Proving Grounds, MD 21005.

C-1 HARDWARE INPUT DATA REQUIREMENTS.

C-1.1 Introduction:

The contractor shall provide access to, and in some cases deliver, a Support Package that will permit the

Government to establish complete organic depot-level repair capability for a system, assembly, subassembly, or Depot Level Repairable (DLR). The Support Package shall contain the actual repair procedures and documentation that the contractor employs in the factory repair process. The Government does not require repair data on a subassembly that the contractor discards after removing it during repair of a DLR. However, the Government would require repair data on a subassembly that the contractor repairs after removing it from a DLR. The Government does not require Level III drawings, or documentation that permits production of the DLR items. The Support Package shall contain the depot support elements (support equipment, facilities, spare parts, software, training, etc.) that are required to implement a depot-level repair program at an organic depot.

C-2 ORGANIC DEPOT SUPPORT PACKAGE (ODSP) FOR HARDWARE

C-2.1 The Contractor shall offer access to the support elements via low cost alternative arrangements

(e.g., Non-Disclosure Agreements, Lease Agreements, Licensing Arrangements, etc.,). The Contractor shall identify any restrictions in the ability to meet the access requirement. The Contractor shall offer a fixed price cost and firm delivery schedule to procure any support elements that the Government may require.

C-2.2 Details:

a. OEM Repair Procedures. The Contractor shall provide access to the minimum level of documentation that fully describes each depot-level repair task. All documentation shall be in contractor format and in accordance with the depth of maintenance employed at the OEM repair facility. Although not inclusive, a suggested listing of potential depot-level tasks is provided below:

Summary of Potential Depot-level Repair Tasks:

1. Inspection

2. Test

3. Troubleshooting

4. Disassembly

5. Diagnostics

6. Repair

7. Re-assembly

8. Environmental

9. Shock and Vibration

10. Acceptance Test Procedure (ATP)

11. Quality Control

12. Final Sell-Off

b. OEM Repair Documentation. The Contractor shall provide access to the technical documentation necessary to support depot-level repair. The documentation shall be in contractor format and contain a minimum level of detail congruent with the factory maintenance concept. Although not inclusive, a suggested listing of potential depot-level documentation types is provided below.

Summary of Potential Depot-level Documentation:

1. Drawings

2. Schematics

3. Interface Diagrams

4. Interconnect Diagrams

5. Part Lists

6. Software

7. Plant Facility Plans

8. Plant Installation Plans

9. Mounting and Alignment Requirements

10. Provisioning Data

c. Elements of Depot Level Support:. The Contractor shall provide Government access to the factory depot repair facility. This access shall permit Government review of all depot-level support elements

(spare parts, tools, facilities, TMDE, ATE, TPS, software, mounting fixtures, test jigs, test stations, and special equipment) used at the factory for depot-level repair. The Government may have to purchase some of the weapon system specific or special/peculiar depot support elements if the establishment of an organic repair facility is required. The extent of these purchases will be dependant on the inventory of like support elements within the organic depot system. The Contractor shall offer each weapon system specific or special/peculiar depot support element that the Government requires at a fixed price with a firm delivery schedule.

C-3 SOFTWARE INPUT DATA REQUIREMENTS.

C-3.1 The Contractor shall participate with the Government in the Integrated Process Team (IPT) approach to provide the input data that is necessary to conduct the required analyses. The Contractor shall identify the source from where the information for each input data element was obtained. The input data shall be provided in contractor format. The Contractor shall also make provisions for the Government to have access to the Contractor’s technical and software support related data files through an integrated data environment. The contactor shall identify any restrictions in the ability to meet the Government’s data needs and access requirements.

C-3.2 Input Data Requirements:

Part I – Architectural Information:

The following shall be provided:

• Description of the system and software architecture.

• Delineation and purpose of all current and planned CSCIs.

• All CSCI interface descriptions.

• CSCI versions.

• Characterization of CSCIs; COTS/GOTS/DII COE/ “Unique”, existing source of support, all licensing details for COTS/GOTS/DII COE, descriptions of modifications, if any, to GOTS/DII COE

CSCIs.

• For all “unique” CSCIs, an explanation of Government rights in data.

Part II – Post Deployment Software Support (PDSS) Workload Data:

• For each “unique” CSCI, employ a single standard software estimation model, (i.e., SoftESt, SECOMO, COCOMO, REVIC) to forecast annual PPSS labor hour workload from IOC to expected obsolescence.

• Document the input parameters to the model and provide a rationale for the selection of each parameter value.

• Document and provide rationale for any PPSS estimates different than that produced by the standard estimation model.

Part III – Skill Data:

• Identify all the skills necessary to perform PPSS on each “unique” CSCI such as functionality, unique algorithms, software design methodologies, programming languages, operating system, and security requirements.

Part IV – Development Software Support Environment (DSSE) Description:

• Provide a list and description of all hardware and software equipment/tools that are required to perform PPSS (which will include the correction of latent defects and the development of major software enhancements). The list should be segregated into two parts; commercially available or unique, and include the following:

o Computers and associated software.

o Software development tools.

o Special test equipment/software.

o Target environment (hot mock-up).

o Simulators/stimulators.

o Media replication equipment.

o Identify the manufacturer's name; model number, configuration, version, unit cost, availability, and procurement lead time and rationale/explanation of the equipment need for PPSS.

C-4 ORGANIC DEPOT SUPPORT PACKAGE (ODSP) FOR SOFTWARE

C-4.1 The Contractor shall offer access to the support elements via low cost alternative arrangements

(e.g., Non-Disclosure Agreements, Lease Agreements, Licensing Arrangements, etc.). The Contractor shall identify any restrictions in the ability to meet the access requirement. The Contractor shall offer a fixed price cost and firm delivery schedule to procure any support elements that the Government may require. For the purpose of this SOW, firmware includes firmware that may be expected to require some modification during the life of the system and is treated as a CSCI.

C-4.2 Details:

a. OEM Software Maintenance Procedures. The Contractor shall provide access to the minimum level of documentation that fully describes each depot-level software support task. All documentation shall be in contractor format and in accordance with the depth of software maintenance employed at the OEM support facility. Although not inclusive, a suggested list of potential depot-level software support tasks is provided below:

Summary of Potential Depot-level Software Support Tasks

1. Analyze the requirement

2. Design a solution

3. Source Code the solution

4. Compile, link and load new software into system

5. Unit Test

6. Integration Test

7. System Test

8. Regressive test

9. Develop new training material for the user

10. Replicate and distribute the new object code

The Contractor shall provide procedures and controls for changing the source code, generating the executable code form the source code, and creating and installing software for the target and host computer systems as well as replicating object software for all user sites. A document summary list of all

CSCIs referenced to the applicable paragraphs of the software requirements document shall be included with the build procedures.

b. OEM Software Maintenance Documentation. The Contractor shall provide access to the technical documentation necessary to conduct depot-level software maintenance. The Contractor will identify and transfer where appropriate all hardware and software licenses. The documentation shall be in contractor format and contain a minimum level of detail congruent with the factory software maintenance concept.

Although not inclusive, a suggested list of potential documentation types is provided below.

Summary of Potential Depot-level Documentation:

1. DSSE commercial computer documentation

a. Hardware

b. Software

2. Test Environment Documentation (simulators/stimulators)

a. Operational manuals

b. Hardware/software documentation

3. Weapon System operation manuals

4. Weapon System software documentation

a. Software requirements specification

b. Software design documentation

c. Software interface design documentation

d. Software product (as-built) documentation

e. Software development plan

f. Software WBS and requirements traceability matrix

g. Software user’s manual

h. Contractor design and coding standards

i. Software test plan, procedures and test data

j. Software quality assurance/configuration management program plan

k. Version description document

l. Software configuration management records e.g., records status of software; status of software trouble reports, ECP/RFWs/SCNs/NORs

5. Master Source and Object Code (on electronic media)

6. Training documentation

a. Operational

b. Software maintenance

7. Weapon System Diagnostic Software

a. Hardware (software utilized to determine if hardware is operating correctly)

b. Software (software utilized to gather data to help debug software)

c. Elements of Depot Level Software Support. The Contractor shall provide Government access to the factory software support facility. This access shall permit Government review of all depot-level support elements (development environment equipment, test environment equipment, target hardware, simulators/stimulators, software media, and documentation) used at the factory for software support. The

Government may have to purchase some of the weapon system specific or special/peculiar software support elements if the establishment of an organic software support facility is required. The extent of these purchases will be dependant on the inventory of like support elements within the organic depot system. The Contractor shall offer each weapon system specific or special/peculiar software support element that the Government requires at a fixed price with a firm delivery schedule.

The software support tools required for the DSSE shall include tools for software development, testing, analysis, documentation, and the creation and duplication of software master versions (object) used to field new software releases. The Contractor shall provide training for the utilization and maintenance of the system-unique DSSE hardware and support equipment. For the purposes of maintenance, system-unique hardware and equipment is defined as that for which the Government cannot purchase maintenance from the original manufacturer or ordinary third-party maintenance supplier.

The Contractor shall identify any commercial or system unique software products that require upgrade or creation in order to conduct depot-level software maintenance. The Contractor shall identify any proprietary or commercially available utilities or tools that are needed