DI-IPSC-82042B
Software Reuse Plan and Analysis
The Software Reuse Plan and Analysis describes a developer's intent to reuse software products, highlighting assumptions, risks, and costs associated with the developer's design strategy.
Approval DateJune 11, 2026
AMSC NumberN10677
Preparing ActivityAS
Project NumberIPSC-2026-002
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Application & Interrelationship
—
Use & Relationship
The Software Reuse Plan and Analysis describes a developer's intent to reuse one or more software products, including the software portion of firmware. The Software Reuse Plan and Analysis provides the acquirer insight into the developer's intent for reusing software products in order to highlight any assumptions, risks, and costs that may be associated with the developer's overall design strategy or methodology.
This Data Item Description contains the format, content, and intended use information for the data product resulting from the work task described by the contract.
This DID supersedes DI-SESS-82042A.
Preparation Instructions
1Referenced 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.
2Format.The Software Reuse Plan and Analysis shall adhere to the format described under Content.
3Content:The Plan and Analysis shall contain the following:
3.1Provide a list, in tabular format, of the reuse software products at their lowest level available (CSCI, CSC, CSU, or software to be programmed into a firmware device), to include the size of the software products in source lines of code (SLOC).The list shall also indicate if the reuse software products are intellectual property (IP), government off-the-shelf (GOTS), commercial off-the-shelf (COTS), or open source.
3.2Detail the lineage of the reuse software products and how they compare or relate to the target system.The detail shall include: (1) the context in which the reuse software products were originally intended, (2) history of the reuse software products from their origin to their current state, (3) portions of the target system to which the reuse software products map, (4) similarities between the reuse software products and the portions of the target system to which they map, and (5) differences between the reuse software products and the portions of the target system to which they map.
3.3Detail the software development process and level of rigor that were applied to the reuse software products.
3.4Detail the ability of the reuse software products to provide the required capabilities and meet any constraints for the target system.
3.5Detail the ability of the reuse software products to provide the required safety, security and privacy for the target system.
3.6Identify the reuse software products that contain more functionality than necessary for the target system.
3.7Identify the reuse software products that are categorized as safety critical for the target system and whether the reuse software products are accompanied by safety artifacts.
3.8List of Cyber-Security requirements, architecture, design, integration and test artifacts for the reuse software products showing mitigation of:
3.8.1Embedded malicious code.
3.8.2Exploitable vulnerabilities.
3.9Detail open system characteristics of the reuse software products, including:
3.9.2Modularity containerization.
3.9.3Processor independence.
3.10Detail reliability and maturity of the reuse software products, as evidenced by established track records.
3.11Detail the defect history of the reuse software products.
3.12Detail the testability of the reuse software products, including the test environment.
3.13Detail the interoperability of the reuse software products with other systems and system-external elements.
3.14Detail all fielding issues associated with the reuse software products.
3.15Detail restrictions on copying/distributing the reuse software products themselves or associated artifacts, including documentation.
3.16Detail license or other fees applicable to the reuse software products.
3.17Detail maintainability of the reuse software products to include:
3.17.1Likelihood the reuse software products need to be changed.
3.17.2Feasibility of accomplishing that change, including the availability of the software development environment.
3.17.3Availability, currency, and quality of existing artifacts associated with the reuse software products, including requirements documents, design documents, interface documents, test plans, test procedures, and source files.
3.17.4Likelihood that the current version of the reuse software products continue to be supported.
3.17.5Impact on the target system if the current versions of reuse software products are not supported.
3.17.6The acquirer's data rights to the reuse software products and associated artifacts, including requirements documents, design documents, interface documents, test plans, test procedures, and source files.
3.17.7Warranties available for the reuse software products and any associated costs for the warranties.
3.18Detail the short and long term cost impacts of incorporating the reuse software products into the target system.
3.19Using the provided flowchart (section 3.20), associated questions (section 3.21) and table example (section 3.22) below, evaluate the reuse software products at their lowest level (CSCI, CSC, CSU, or software to be programmed into a firmware device) and provide the results as part of this deliverable.
3.21Questions from Flowchart:
3.21.1Do the software requirements for the system under development match or form a subset of the software requirements of the reuse code?
3.21.2Reuse code developed to an accepted standard (IEEE-12207, ISO 9000, MILSTD-498, DOD-STD-2167A)?
3.21.3Reuse code developed to the level of rigor as identified in MIL-STD-882E or Design Assurance Level (DAL) as identified in DO-178B/C to insure sufficient test activities executed during development of the reuse code?
3.21.4Other evidence of sufficient white and black box test rigor?
3.21.5Has the pedigree of the reuse code for mission critical functions, from other systems, been examined for embedded malicious code, exploitable vulnerabilities, and minimizing risk?
3.21.6Was the Common Attack Pattern Enumeration and Classification (CAPEC) used to assist with:
3.21.6.1Design and architecture considerations.
3.21.6.2Selection of programming language(s).
3.21.6.3Use of COTS and open source code.
3.21.7Was design-based evidence for cybersecurity functions/features documented?
3.21.8Are there features in the reuse code not necessary for the new system?
3.21.9Are there safety implications of inadvertently activating these features?
3.21.10Do the mitigation steps require the removal of code?
3.21.11Are there any cybersecurity implications of inadvertently activating those features?
3.21.12Do the mitigation steps require the removal of code?
3.21.13Are there anti-tamper implications of inadvertently activating those features?
3.21.14Do the mitigation steps require the removal of code?
3.21.15Is the design being reused?
3.21.16Is the software test environment being reused?
3.21.17Are the test procedures or automation testing scripts being reused?
3.21.18Does this code need to be refactored?
3.21.19Is this reuse to be part of an open system as defined by the NAVAIR Instruction?
3.21.20Does this reuse candidate contain IP or other restrictive provisions on government usage and/or data rights?
3.21.21Does the documentation (design, models, requirements, etc.) exist and is it available for use for the new program?
Figures

Figure . Flowchart

Figure . Sample Table
Schema v3.0Community-maintained · Verify against ASSIST