3.1.2 The project manager shall assess options for software acquisition versus development.

1. Confirm that the options for software acquisition versus development have been evaluated.

2. Confirm the flow down of applicable software engineering, software assurance, and software safety requirements on all acquisition activities. (NPR 7150.2 and NASA-STD-8739.8).

3. Assess any risks with acquisition versus development decision(s).

3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.

1. Confirm that all plans, including security plans, are in place and have expected content for the life cycle events, with proper tailoring for the classification of the software.

2. Develop and maintain a Software Assurance Plan following the content defined in NASA-HDBK-2203 for a software assurance plan, including software safety.

3.1.4 The project manager shall track the actual results and performance of software activities against the software plans.

1. 1. Corrective actions are taken, recorded, and managed to closure.
   2. Changes to commitments (e.g., software plans) that have been agreed to by the affected groups and individuals are taken, recorded, and managed.

1. Assess plans for compliance with NPR 7150.2 requirements, NASA-STD-8739.8, including changes to commitments.

2. Confirm that closure of corrective actions associated with the performance of software activities against the software plans, including closure rationale.

3. Confirm changes to commitments are recorded and managed.

3.1.5 The project manager shall define and document the acceptance criteria for the software. 

1. Confirm software acceptance criteria are defined and assess the criteria based on guidance in the NASA Software Engineering Handbook, NASA-HDBK-2203.

3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables.

3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. 

1. Confirm that milestones for reviewing and auditing software developer progress are defined and documented.

2. Participate in project milestones reviews.

3.1.8 The project manager shall require the software developer(s) to periodically report status and provide insight into software development and test activities; at a minimum, the software developer(s) will be required to allow the project manager and software assurance personnel to:

1. 1. Monitor product integration.
   2. Review the verification activities to ensure adequacy.
   3. Review trade studies and source data.
   4. Audit the software development processes and practices.
   5. Participate in software reviews and technical interchange meetings.

2. Monitor product integration.

3. Analyze the verification activities to ensure adequacy.

4. Assess trade studies, source data, software reviews, and technical interchange meetings.

5. Perform audits on software development processes and practices at least once every two years.

6. Develop and provide status reports.

7. Develop and maintain a list of all software assurance review discrepancies, risks, issues, findings, and concerns.

8. Confirm that the project manager provides responses to software assurance and software safety submitted issues, findings, and risks and that the project manager tracks software assurance and software safety issues, findings, and risks to closure.

3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics.

1. Confirm that software artifacts are available in electronic format to NASA.

3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format.

3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification.

3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.

1. Confirm that any requirement tailoring in the Requirements Mapping Matrix has the required approvals.

2. Develop a tailoring matrix of software assurance and software safety requirements.

3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 

3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, or reused software component is acquired or used: 

a. The requirements to be met by the software component are identified.

b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).

c. Proprietary rights, usage rights, ownership, warranty, licensing rights, transfer rights, and conditions of use (e.g., required copyright, author, and applicable license notices within the software code, or a requirement to redistribute the licensed software only under the same license (e.g., GNU GPL, ver. 3, license)) have been addressed and coordinated with Center Intellectual Property Counsel. 

d. Future support for the software product is planned and adequate for project needs.

e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.

f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.

1. Confirm that the conditions listed in "a" through "f" are complete for any COTS, GOTS, MOTS, OSS, or reused software that is acquired or used.

3.2.1 To better estimate the cost of development, the project manager shall establish, document, and maintain:

1. 1. Two cost estimate models and associated cost parameters for all Class A and B software projects that have an estimated project cost of $2 million or more.
   2. One software cost estimate model and associated cost parameter(s) for all Class A and Class B software projects that have an estimated project cost of less than $2 million.
   3. One software cost estimate model and associated cost parameter(s) for all Class C and Class D software projects.
   4. One software cost estimate model and associated cost parameter(s) for all Class F software projects.

1. Confirm that the required number of software cost estimates are complete and include software assurance cost estimate(s) for the project, including a cost estimate associated with handling safety-critical software and safety-critical data.

3.2.2 The project manager’s software cost estimate(s) shall satisfy the following conditions: 

a. Covers the entire software life cycle.
b. Is based on selected project attributes (e.g., programmatic assumptions/constraints, assessment of the size, functionality, complexity, criticality, reuse code, modified code, and risk of the software processes and products).
c. Is based on the cost implications of the technology to be used and the required maturation of that technology.
d. Incorporates risk and uncertainty, including end state risk and threat assessments for cybersecurity.
e. Includes the cost of the required software assurance support.
f. Includes other direct costs.

1. Assess the project's software cost estimate(s) to determine if the stated criteria listed in "a" through "f" are satisfied.

3.2.3 The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones.

1. Confirm that all the software planning parameters, including size and effort estimates, milestones, and characteristics, are submitted to a Center repository.

2. Confirm that all software assurance and software safety software estimates and planning parameters are submitted to an organizational repository.

3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:

1. 1. Coordinates with the overall project schedule.
   2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
   3. Reflects the critical dependencies for software development activities.
   4. Identifies and accounts for dependencies with other projects and cross-program dependencies.

1. Assess that the software schedule satisfies the conditions in the requirement.

2. Develop a software assurance schedule, including software assurance products, audits, reporting, and reviews.

3.3.2 The project manager shall regularly hold reviews of software schedule activities, status, performance metrics, and assessment/analysis results with the project stakeholders and track issues to resolution.

1. Confirm the generation and distribution of periodic reports on software schedule activities, metrics, and status, including reports of software assurance and software safety schedule activities, metrics, and status.

2. Confirm closure of any project software schedule issues.

3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

3.4.1 The project manager shall plan, track, and ensure project specific software training for project personnel.

1. Confirm that any project-specific software training has been planned, tracked, and completed for project personnel, including software assurance and software safety personnel.

2. Confirm that software assurance and software safety personnel have completed the appropriate software assurance and/or software safety training to satisfactorily conduct assurance and safety activities.

3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D. 

1. Perform a software classification or concur with the engineering software classification of software per the descriptions in NPR 7150.2.

3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project. 

1. Confirm that records of the software Requirements Mapping Matrix and each software classification are maintained and updated for the life of the project.

3.6.1 The project manager shall plan and implement software assurance, software safety, and IV&V (if required) per NASA-STD-8739.8, Software Assurance and Software Safety Standard.

3.6.2 For projects reaching Key Decision Point A, the program manager shall ensure that software IV&V is performed on the following categories of projects: 

a. Category 1 projects as defined in NPR 7120.5.
b. Category 2 projects as defined in NPR 7120.5, that have Class A or Class B payload risk classification per NPR 8705.4, Risk Classification for NASA Payloads.
c. Projects selected explicitly by the Mission Directorate Associate Administrator (MDAA) to have software IV&V.

1. Confirm that IV&V requirements (section 4.4) are complete on projects required to have IV&V.

3.6.3 If software IV&V is required for a project, the project manager, in consultation with NASA IV&V, shall ensure an IPEP is developed, approved, maintained, and executed in accordance with IV&V requirements in NASA-STD-8739.8.

3.6.4 If software IV&V is performed on a project, the project manager shall ensure that IV&V is provided access to development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively. 

1. Confirm that IV&V has access to the software development artifacts, products, source code, and data required to perform the IV&V analysis efficiently and effectively.

3.6.5 If software IV&V is performed on a project, the project manager shall provide responses to IV&V submitted issues and risks and track these issues and risks to closure.

3.7.1 The project manager, in conjunction with the SMA organization, shall determine if each software component is considered to be safety-critical per the criteria defined in NASA-STD-8739.8. 

2. Assess that the hazard reports identify the software components associated with the system hazards per the criteria defined in NASA-STD-8739.8, Appendix A.

3. Assess that hazard analyses (including hazard reports) identify the software components associated with the system hazards per the criteria defined in NASA-STD-8739.8, Appendix A.

5. Develop and maintain a software safety analysis throughout the software development life cycle.

3.7.2 If a project has safety-critical software, the project manager shall implement the safety-critical software requirements contained in NASA-STD-8739.8.

1. Confirm that the identified safety-critical software components and data have implemented the safety-critical software assurance requirements listed in this standard.

3.7.3 If a project has safety-critical software or mission-critical software, the project manager shall implement the following items in the software: 

a. The software is initialized, at first start and restarts, to a known safe state.
b. The software safely transitions between all predefined known states.
c. Termination performed by software functions is performed to a known safe state.
d. Operator overrides of software functions require at least two independent actions by an operator.
e. Software rejects commands received out of sequence when execution of those commands out of sequence can cause a hazard.
f. The software detects inadvertent memory modification and recovers to a known safe state.
g. The software performs integrity checks on inputs and outputs to/from the software system.
h. The software performs prerequisite checks prior to the execution of safety-critical software commands.
i. No single software event or action is allowed to initiate an identified hazard.
j. The software responds to an off-nominal condition within the time needed to prevent a hazardous event.
k. The software provides error handling.
l. The software can place the system into a safe state.

1. Analyze the software requirements and the software design and work with the project to implement NPR 7150.2 requirement items "a" through "l."

2. Assess that the source code satisfies the conditions in the NPR 7150.2 requirement "a" through "l" for safety-critical and mission-critical software at each code inspection, test review, safety review, and project review milestone.

6. Ensure the SWE-134 implementation supports and is consistent with the system hazard analysis.

3.7.4 If a project has safety-critical software, the project manager shall ensure that there is 100 percent code test coverage using the Modified Condition/Decision Coverage (MC/DC) criterion for all identified safety-critical software components.

1. Confirm that 100% code test coverage is addressed for all identified safety-critical software components or that software developers provide a technically acceptable rationale or a risk assessment explaining why the test coverage is not possible or why the risk does not justify the cost of increasing coverage for the safety-critical code component.

3.7.5 If a project has safety-critical software, the project manager shall ensure all identified safety-critical software components have a cyclomatic complexity value of 15 or lower. Any exceedance shall be reviewed and waived with rationale by the project manager or technical approval authority.

1. Perform or analyze Cyclomatic Complexity metrics on all identified safety-critical software components.

3.8.1 The project manager shall define the approach to the automatic generation of software source code including: 

a. Validation and verification of auto-generation tools.
b. Configuration management of the auto-generation tools and associated data.
c. Description of the limits and the allowable scope for the use of the auto-generated software.
d. Verification and validation of auto-generated source code using the same software standards and processes as hand-generated code.
e. Monitoring the actual use of auto-generated source code compared to the planned use.
f. Policies and procedures for making manual changes to auto-generated source code.
g. Configuration management of the input to the auto-generation tool, the output of the auto-generation tool, and modifications made to the output of the auto-generation tools.

1. Assess that the approach for the auto-generation software source code is defined, and the approach satisfies at least the conditions “a” through “g.”

3.8.2 The project manager shall require the software developers and custom software suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software.

1. Confirm that NASA, engineering, project, software assurance, and IV&V have electronic access to the models, simulations, and associated data used as inputs for auto-generation of software.

3.9.2 The project manager shall acquire, develop, and maintain software from an organization with a non-expired CMMI-DEV rating as measured by a CMMI Institute Certified Lead Appraiser as follows:

1. 1. For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software.
   2. For Class B software (except Class B software on NASA Class D payloads, as defined in NPR 8705.4): CMMI-DEV Maturity Level 2 Rating or higher for software.

1. Confirm that Class A and B software acquired, developed, and maintained by NASA is performed by an organization with a non-expired CMMI-DEV rating, as per the NPR 7150.2 requirement.

2. Assess potential process-related issues, findings, or risks identified from the CMMI assessment findings.

3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.

1. Confirm that the project has considered reusability for its software development activities.

3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

a. Software Title.
b. Software Description.
c. The Civil Servant Software Technical POC for the software product.
d. The language or languages used to develop the software.
e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
f. Release notes.

3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.

1. Confirm the project has performed a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.

3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems.

1. Confirm that cybersecurity risks, along with their mitigations, are identified and managed.

3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard.

3.11.5 The project manager shall test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis.

1. Confirm that testing is complete for the cybersecurity mitigation.

2. Assess the quality of the cybersecurity mitigation implementation testing and the test results.

3.11.6 The project manager shall identify, record, and implement secure coding practices.

1. Assess that the software coding guidelines (e.g., coding standards) includes secure coding practices.

3.11.7 The project manager shall verify that the software code meets the project’s secure coding standard by using the results from static analysis tool(s).

1. Analyze the engineering data or perform independent static code analysis to verify that the code meets the project’s secure coding standard requirements.

3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions.

1. Confirm that the software requirements exist for collecting, reporting, and storing data relating to the detection of adversarial actions.

3.12.1 The project manager shall perform, record, and maintain bi-directional traceability between the following software elements: 

1. Confirm that bi-directional traceability has been completed, recorded, and maintained.

2. Confirm that the software traceability includes traceability to any hazard that includes software.

4.1.2 The project manager shall establish, capture, record, approve, and maintain software requirements, including requirements for COTS, GOTS, MOTS, OSS, or reused software components, as part of the technical specification. 

1. Confirm that all software requirements are established, captured, and documented as part of the technical specification, including requirements for COTS, GOTS, MOTS, OSS, or reused software components.

4.1.3 The project manager shall perform software requirements analysis based on flowed down and derived requirements from the top-level systems engineering requirements, safety and reliability analyses, and the hardware specifications and design. 

1. Perform a software assurance analysis on the detailed software requirements to analyze the software requirement sources and identify any incorrect, missing, or incomplete requirements.

4.1.4 The project manager shall include software related safety constraints, controls, mitigations, and assumptions between the hardware, operator, and software in the software requirements documentation.

4.1.5 The project manager shall track and manage changes to the software requirements. 

1. Confirm the software requirements changes are documented, tracked, approved, and maintained throughout the project life cycle.

4.1.6 The project manager shall identify, initiate corrective actions, and track until closure inconsistencies among requirements, project plans, and software products. 

4.1.7 The project manager shall perform requirements validation to ensure that the software will perform as intended in the customer environment. 

1. Confirm that the project software testing has shown that software will function as expected in the customer environment.

4.2.3 The project manager shall transform the requirements for the software into a recorded software architecture.

1. Assess that the software architecture addresses or contains the software structure, qualities, interfaces, and external/internal components.

2. Analyze the software architecture to assess whether software safety and mission assurance requirements are met.

4.2.4 The project manager shall perform a software architecture review on the following categories of projects: 

a. Category 1 Projects as defined in NPR 7120.5.
b. Category 2 Projects as defined in NPR 7120.5, that have Class A or Class B payload risk classification per NPR 8705.4.

1. Assess the results of or participate in software architecture review activities held by the project.

4.3.2 The project manager shall develop, record, and maintain a software design based on the software architectural design that describes the lower-level units so that they can be coded, compiled, and tested.

1. Assess the software design against the hardware and software requirements and identify any gaps.

2. Assess the software design to verify that the design is consistent with the software architectural design concepts and that the software design describes the lower-level units to be coded, compiled, and tested. 

3. Assess that the design does not introduce undesirable behaviors or unnecessary capabilities.

4. Confirm that the software design implements all of the required safety-critical functions and requirements. 

5. Perform a software assurance design analysis.

4.4.2 The project manager shall implement the software design into software code.

1. Confirm that the software code implements the software designs. 

2. Confirm that the code does not contain functionality not defined in the design or requirements.

4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria.

1. Assure the project manager selected and/or defined software coding methods, standards, and criteria.

4.4.4 The project manager shall use static analysis tools to analyze the code during the development and testing phases to, at a minimum, detect defects, software security, code coverage, and software complexity.

1. Analyze the engineering data or perform independent static code analysis to check for code detects defects, software quality objectives, code coverage objectives, software complexity values, and software security objectives.

2. Confirm the static analysis tool(s) are used with checkers to identify security and coding errors and defects.

3. Assess that the project addresses the results from the static analysis tools used by software assurance, software safety, engineering, or the project.

4. Confirm that the software code has been scanned for security defects and confirm the result.

5. Per SWE-219 for safety-critical software, verify code coverage and approved waivers.

6. Per SWE-220 for safety-critical software, verify cyclomatic complexity and approved waivers.

4.4.5 The project manager shall unit test the software code.

1. Confirm that the project successfully executes the required unit tests, particularly those testing safety-critical functions.

4.4.6 The project manager shall assure that the unit test results are repeatable.

1. Confirm that the project maintains the procedures, scripts, results, and data needed to repeat the unit testing (e.g., as-run scripts, test procedures, results).

4.4.7 The project manager shall provide a software version description for each software release. 

1. Confirm that the project creates a correct software version description for each software release.

2. For each software release, confirm that the software has been scanned for security defects and coding standard compliance and confirm the results.

4.4.8 The project manager shall validate and accredit the software tool(s) required to develop or maintain software.

1. Confirm that the software tool(s) needed to create and maintain software is validated and accredited.

1. Confirm that software test plans have been established, contain correct content, and are maintained.

2. Confirm that the software test plan addresses the verification of safety-critical software, specifically the off-nominal scenarios.

1. Confirm that the project creates and maintains any code specifically written to perform test procedures in a software configuration management system.

1. Confirm that the project creates and maintains the test reports throughout software integration and test.

2. Confirm that the project records the test report data and that the data contains the as-run test data, the test results, and required approvals. 

3. Confirm that the project records all issues and discrepancies found during each test.

4.5.3 The project manager shall test the software against its requirements.

1. Confirm test coverage of the requirements through the execution of the test procedures.

4.5.4 The project manager shall place software items under configuration management prior to testing.

1. Confirm that software items to be tested are under configuration management before the start of testing. 

2. Confirm the project maintains the software items under configuration management through the completion of testing.

4.5.5 The project manager shall evaluate test results and record the evaluation.

1. Confirm that test results are assessed and recorded. 

2. Confirm that the project documents software non-conformances in a tracking system.

3. Confirm that test results are sufficient verification artifacts for the hazard reports.

4.5.6 The project manager shall use validated and accredited software models, simulations, and analysis tools required to perform qualification of flight software or flight equipment.

4.5.7 The project manager shall update the software test and verification plan(s) and procedure(s) to be consistent with software requirements.

1. Analyze that software test plans and software test procedures cover the software requirements and provide adequate verification of hazard controls, specifically the off-nominal scenarios.

4.5.8 The project manager shall validate the software system on the targeted platform or high-fidelity simulation.

1. Confirm that the project validates the software components on the targeted platform or a high-fidelity simulation.

4.5.9 The project manager shall ensure that the code coverage measurements for the software are selected, implemented, tracked, recorded, and reported.

1. Confirm that code coverage measurements have been selected, performed, tracked, recorded, and communicated with each release.

4.5.10 The project manager shall verify code coverage is measured by analysis of the results of the execution of tests.

1. Confirm that the project performs code coverage analysis using the results of the tests or a code coverage tool. 

3. Assess any uncovered software code for potential risk, issues, or findings.

4.5.11 The project manager shall plan and conduct software regression testing to demonstrate that defects have not been introduced into previously integrated or tested software and have not produced a security vulnerability.

1. Confirm that the project plans regression testing and that the regression testing is adequate and includes retesting of all safety-critical code components.

2. Confirm that the project performs the planned regression testing. 

3. Identify any risks and issues associated with the regression test set selection and execution.

4. Confirm that the regression test procedures are updated to incorporate tests that validate the correction of critical anomalies.

4.5.12 The project manager shall verify through test the software requirements that trace to a hazardous event, cause, or mitigation technique.

4.5.13 The project manager shall develop acceptance tests for loaded or uplinked data, rules, and code that affects software and software system behavior.  

1. Confirm that the project develops acceptance tests for loaded or uplinked data, rules, and code that affect software and software system behavior.

3. Confirm that loaded or uplinked data, rules, and scripts are verified as correct prior to operations, particularly for safety-critical operations.

4.5.14 The project manager shall test embedded COTS, GOTS, MOTS, OSS, or reused software components to the same level required to accept a custom developed software component for its intended use. 

1. Confirm that the project is testing COTS, GOTS, MOTS, OSS, or reused software components to the same level as developed software for its intended use.

4.6.2 The project manager shall plan and implement software operations, maintenance, and retirement activities.

2. Confirm that the project implements software operations, software maintenance, and software retirement plans.

4.6.3 The project manager shall complete and deliver the software product to the customer with appropriate records, including as-built records, to support the operations and maintenance phase of the software’s life cycle. 

4.6.4 The project manager shall complete, prior to delivery, verification that all software requirements identified for this delivery have been met or dispositioned, that all approved changes have been implemented, and that all defects designated for resolution prior to delivery have been resolved. 

1. Confirm that the project has identified the software requirements to be met, the approved changes to be implemented, and defects to be resolved for each delivery. 

2. Confirm that the project has met all software requirements identified for delivery. 

3. Confirm requirements once planned for delivery but no longer appearing in delivery documentation have been dispositioned. 

4.6.5 The project manager shall maintain the software using standards and processes per the applicable software classification throughout the maintenance phase.

1. Perform audits on the standards and processes used throughout maintenance based on the software classification.

4.6.6 The project manager shall identify the records and software tools to be archived, the location of the archive, and procedures for access to the products for software retirement or disposal.

1. Confirm that the project has identified the records and software tools for archival.

5.1.2 The project manager shall develop a software configuration management plan that describes the functions, responsibilities, and authority for the implementation of software configuration management for the project.

1. Assess that a software configuration management plan has been developed and complies with the requirements in NPR 7150.2 and Center/project guidance.

5.1.3 The project manager shall track and evaluate changes to software products.

1. Analyze proposed software and hardware changes to software products for impacts, particularly safety and security.

3. Confirm software changes follow the software change control process.

5.1.4 The project manager shall identify the software configuration items (e.g., software records, code, data, tools, models, scripts) and their versions to be controlled for the project.

1. Confirm that the project has identified the configuration items and their versions to be controlled.

5.1.5 The project manager shall establish and implement procedures to:

a. Designate the levels of control through which each identified software configuration item is required to pass.
b. Identify the persons or groups with authority to authorize changes.
c. Identify the persons or groups to make changes at each level.

1. Confirm that software assurance has participation in software control activities.

5.1.6 The project manager shall prepare and maintain records of the configuration status of software configuration items. 

1. Confirm that the project maintains records of the configuration status of the configuration items.

5.1.7 The project manager shall perform software configuration audits to determine the correct version of the software configuration items and verify that they conform to the records that define them.

1. Confirm that the project manager performed software configuration audits to determine the correct version of the software configuration items and verify that the results of the audit conform to the records that define them.

5.1.8 The project manager shall establish and implement procedures for the storage, handling, delivery, release, and maintenance of deliverable software products.  

1. Confirm that the project establishes procedures for storage, processing, distribution, release, and support of deliverable software products.

5.1.9 The project manager shall participate in any joint NASA/developer audits. 

1. Participate in or assess the results from any joint NASA/developer audits. Track any findings to closure.

5.2.1 The project manager shall record, analyze, plan, track, control, and communicate all of the software risks and mitigation plans.

1. Confirm and assess that a risk management process includes recording, analyzing, planning, tracking, controlling, and communicating all software risks and mitigation plans. 

2. Perform audits on the risk management process for the software activities.

5.3.2 The project manager shall perform and report the results of software peer reviews or software inspections for: 

a. Software requirements.
b. Software plans, including cybersecurity.
c. Any design items that the project identified for software peer review or software inspections according to the software development plans.
d. Software code as defined in the software and or project plans.
e. Software test procedures.

1. Confirm that software peer reviews are performed and reported on for project activities. 

2. Confirm that the project addresses the accepted software peer review findings.

3. Perform peer reviews on software assurance and software safety plans.

4. Confirm that the source code satisfies the conditions in the NPR 7150.2 requirement SWE-134, "a" through "l," based upon the software functionality for the applicable safety-critical requirements at each code inspection/review.

5.3.3 The project manager shall, for each planned software peer review or software inspection:

a. Use a checklist or formal reading technique (e.g., perspective-based reading) to evaluate the work products.
b. Use established readiness and completion criteria.
c. Track actions identified in the reviews until they are resolved.
d. Identify the required participants.

1. Confirm that the project meets the NPR 7150.2 criteria in "a" through "d" for each software peer review.

2. Confirm that the project resolves the actions identified from the software peer reviews.

3. Perform audits on the peer-review process.

5.3.4 The project manager shall, for each planned software peer review or software inspection, record necessary measurements. 

5.4.2 The project manager shall establish, record, maintain, report, and utilize software management and technical measurements.

1. Confirm that a measurement program establishes, records, maintains, reports, and uses software assurance, management, and technical measures. 

2. Perform trending analyses on metrics (quality metrics, defect metrics) and report. 

3. Collect any identified organizational metrics and submit them to the organizational repository.

5.4.3 The project manager shall analyze software measurement data collected using documented project-specified and Center/organizational analysis procedures.

1. Confirm software measurement data analysis conforms to documented analysis procedures.

2. Analyze software assurance measurement data.

5.4.4 The project manager shall provide access to the software measurement data, measurement analyses, and software development status as requested to the sponsoring Mission Directorate, the NASA Chief Engineer, the Center Technical Authorities, HQ SMA, and other organizations as appropriate. 

5.4.5 The project manager shall monitor measures to ensure the software will meet or exceed performance and functionality requirements, including satisfying constraints.

2. Monitor and track any performance or functionality requirements that are not being met or are at risk of not being met.

5.4.6 The project manager shall collect, track, and report software requirements volatility metrics.

1. Confirm that the project collects, tracks, and reports on the software volatility metrics.

5.5.1 The project manager shall track and maintain software non-conformances (including defects in tools and appropriate ground software). 

1. Confirm that all software non-conformances are recorded and tracked to resolution.

2. Confirm that accepted non-conformances include the rationale for the non-conformance.

5.5.2 The project manager shall define and implement clear software severity levels for all software non-conformances (including tools, COTS, GOTS, MOTS, OSS, reused software components, and applicable ground systems).

1. Confirm that all software non-conformances severity levels are defined.

2. Assess the application and accuracy of the defined severity levels to software non-conformances.

5.5.3 The project manager shall implement mandatory assessments of reported non-conformances for all COTS, GOTS, MOTS, OSS, and/or reused software components.

1. Confirm the evaluations of reported non-conformances for all COTS, GOTS, MOTS, OSS, or reused software components are occurring throughout the project life cycle.

5.5.4 The project manager shall implement process assessments for all high-severity software non-conformances (closed-loop process).

2. Confirm that the project analyzed the processes identified in the root cause analysis associated with the high severity software non-conformances.

3. Assess opportunities for improvement on the processes identified in the root cause analysis associated with the high severity software non-conformances. 

4. Perform or confirm tracking of corrective actions to closure on high severity software non-conformances.