Exhibit E (5 Pages).pdf

DATA ITEM DESCRIPTION

Title: SOFTWARE SUSTAINABILITY PACKAGE

Number: DI-IPSC-82134 Approval Date: 20170615

AMSC Number: N9821 Limitation: N/A

DTIC Applicable: No GIDEP Applicable: No

Preparing Activity: AS Project Number: IPSC-2017-003

Applicable Forms: N/A

Use/relationship: The Software Sustainability Package (SSP) contains the superset of source code, design details, models, algorithms, processes, flow charts, formulae and related materials that would allow the software to be reproduced, recreated or recompiled, as needed for sustainment by non-developer(s) or the original equipment manufacturer (OEM). This includes all executable software, des ign model s , source files, and software sustainment information, including "as built" design information and compilation, build, and modification procedures, for each Computer Software Configuration Item (CSCI).

The SSP is to be used in conjunction with a Contract Line Item Numbers (CLINs) or CLIN

Options to procure the executable software and source files for a CSCI and is the primary software sustainment document for each CSCI which could be maintained by non-OEM(s). The

SSP is the line item description of the data and products that are to be procured through the

CLINs.

Note: Different organizations have different policies for ordering delivery of software. These policies should be determined before applying this Data Item Description (DID).

This DID is used when the developer is tasked, either by CLIN, Statement of Work (SOW) or Statement of Objectives (SOO), to prepare executable software, source files, "as built"

CSCI design, hardware and related sustainment information for delivery.

This DID contains the format, content, and intended use information for the data product resulting from the work task described in the contract SOW.

Requirements:

1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices and revisions, shall be as specified in the contract.

2. Format. The SSP shall be in contractor format. The SSP shall adhere to the format described under Content.

3. Content. The specification shall contain the following items:

Source: http://assist.dla.mil -- Downloaded: 2022-04-06T20:10Z Check the source to verify that this is the current version before use.

DI-IPSC-82134

3.1 Scope

a. A detailed and complete identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

b. Briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and sustainment agencies; identify current and planned operating sites.

c. Describe the relationship to other project management plans.

3.2 Provide a detailed listing of source files, including source code in its original language, batch files, build scripts, data files, and libraries necessary to successfully regenerate the software product from scratch and to be able to successfully execute the regenerated software product on the target hardware without any involvement from the software product’s OEM.

3.3 Identify and describe in detail the hardware and associated documentation needed to sustain the deliverable software. This hardware may include computers, peripherals, hardware simulators, stimulators, emulators, diagnostic equipment, programming equipment (e.g. erasure of software from, loading software onto, and verification of software on a hardware device), firmware devices, and non-computer equipment. The following shall be included in the description:

a. Specific models, versions and configurations.

b. Operator manuals or instructions for each item, as applicable.

c. Whether the item is furnished by the developer, by the OEM, as GFE/GFI, etc. and whether the item is still supported by that particular organization. If the item is no longer supported or manufactured, a plan for procuring replacements (e.g. new source of supply) should be identified.

d. Information about licensing, data rights, etc.

e. Security and privacy considerations, limitations, or any other items of interest.

f. Information about the operational and environmental limits to which the item may be subjected and maintain satisfactory operation.

3.4 Provide a detailed description of the complete software development environment (SDE) and software test environment. The following shall be included in the description:

a. All software tools (Cybersecurity, compilers, linkers, loaders, debuggers, scripts, etc).

b. Procedural documentation.

c. Operational data and settings, such as compiler flags and environmental variables required to regenerate and maintain the software product.

3.5 Provide a detailed listing and description of automated test tools associated with the software product.

DI-IPSC-82134

3.6 As an appendix to this document or as a standalone document, identify, detail and list all unit, component and CSCI level test procedures and all test scripts.

3.7 As an appendix to this document or as a standalone document, identify, detail and list all

CSCI, CSC, CSU and system integration procedures; hardware/software integration procedures; and instructions for use of integration procedures.

3.8 As an appendix to this document or as a standalone document, identify, detail and list all system development testing suites such as System Integration Lab (SIL) subsystems, and data acquisition, data reduction, and data analysis tools, along with all custom test equipment.

3.9 Provide a detailed description of problem tracking, software configuration management, and data management tools and licenses.

3.10 Provide a detailed description of requirements, design, source code and processes for devices and software which load software into the subsystems.

3.11 Provide a detailed description of licenses, including commercial and open source, which are utilized at the SDE, software test environment, and SIL.

3.12 As an appendix to this document identify and detail all software architecture artifacts, including Unified Modeling Language (UML) diagrams, UML modeling and executable code, and data models.

3.13 As an appendix to this document identify and detail training materials to teach the sustainers the complexities of the systems and the interfaces with other systems.

3.14 Identify and detail other items required for software development and sustainment that are not previously requested or identified in the previous sections.

4. Notes. This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.

5. Appendixes. Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling.

Appendixes shall be lettered alphabetically (A, B, etc.).

End of DI-IPSC-82134