NQA-1

Quality Assurance Requirements for Nuclear Facility Applications

NQA-1

A regulatory standard created by the American Society of Mechanical Engineers (ASME) governing the supply of items or services, which provide a safety function for nuclear facilities. Software is considered an "item".

INL's contract with DOE requires us to abide by NQA-1 standards where applicable.

NQA-1: SQA Program at INL

The Software Quality Assurance (SQA) program at Idaho National Laboratory (INL) implements the contractual requirements and Department of Energy (DOE) expectations of 10 CFR 830 Subpart A, "Quality Assurance Requirements;" DOE Order 414.1D, "Quality Assurance;" and the American Society of Mechanical Engineers (ASME) NQA-1-2008/1a-2009 and 2017 editions, "Quality Assurance Requirements for Nuclear Facility Applications," which apply to software.

These requirements are implemented in the following INL documents: PDD-13610, "Software Quality Assurance Program;" and LWP-13620, "Managing Information Technology Assets," and the associated templates and forms.

NQA-1: SQA Program at INL

SQA is a set of activities whereby software engineering and quality processes and methods are followed to ensure proper quality is achieved. A graded approach is applied commensurate with the consequence of failure of the software:

• more rigor is applied with respect to controls and other work activities if the software meets the DOE definition of safety software and has a high consequence of failure; and

• less rigor is applied if the software is non-safety software and has a lower consequence of failure.

NQA-1: SQA and MOOSE

• MOOSE and many MOOSE-based applications are moving beyond being "research" projects.

• These tools must be developed following the NQA-1 process as defined by the DOE and INL.

NQA-1: Process

• The NQA-1 process is designed around traditional "waterfall" software development model.

NQA-1: Standard

• The NQA-1 is a standard to be satisfied, how it is satisfied is not defined.

• It is possible to use modern software development processes and satisfy the standard.

NQA-1: Traceability

The connection (traceability) between four items is the key to satisfying the NQA-1 standard.

1. Change Request (CR): Why is the code being changed?

2. Requirement: What is the required function of the code?

3. Design: What is the design of the code for the change?

4. Test: How is the requirement shown to be satisfied?

NQA-1: Requirement

• Unitary (Cohesive): addresses one item
  

• Complete: fully stated in one place with no missing information
  

• Consistent: does not contradict another and is consistent with all documentation
  

• Non-Conjugated (Atomic): must be atomic, i.e., it does not contain conjunctions
  

• Traceable: meets a business need
  

• Current: has not been made obsolete by the passage of time
  

• Unambiguous: concisely stated without recourse to technical jargon
  

• Verifiable: implementation can be determined through inspection, test, or analysis

PLN-4005

Software Quality Assurance Plan (SQAP) for MOOSE and MOOSE-based Applications

PLN-4005: Purpose

• Static document created to detail the process and the rigor required for development of MOOSE and MOOSE-based applications to meet the NQA-1 standard using INL templates and procedures.

• Required reading associated with this training.

PLN-4005: Assumptions

• MOOSE and MOOSE-based applications are designated as Quality Level 2 (QL-2) non-safety software but are managed following processes that implement Quality Level 1 (QL-1) safety software.

• We follow the most stringent processes; however, we do not provide "safety software." Users are responsible for following their organization's processes if MOOSE or a MOOSE-based application is used to perform a safety function.

PLN-4005: Roles

• Line Manager: Manages the overall project ensuring that work scope is defined and adequate resources exist (time, talent, funding, etc.).

• Project Lead: Manages day-to-day development of the code to ensure that work is being performed as defined by the Line Manager, and performs software releases.

• Software Quality Assurance Lead: Manages SQA processes and ensures that PLN-4005 is being implemented.

• Change Control Board (CCB): Perform reviews of Change Requests (CRs) to ensure that code changes are necessary and that testing and documentation conforms to PLN-4005.

PLN-4005: Documentation

Three classes of documentation are defined for MOOSE and MOOSE-based applications:

• static

• repository

• development

PLN-4005: Static Documentation

• Software Quality Assurance Plan (SQAP; PLN-4005): Defines SQA processes implemented including Configuration Management Plan (CMP) and Verification and Validation Plan (VVP).

• Safety-software Determination (SSD): INL tool that asks a series of questions to determine and document if the software application meets the DOE definition of Safety Software.

• Quality-level Determination (QLD): INL tool that asks a series of questions to determine and document the quality level of the software application. The quality level is used to apply a graded approach and the rigor with which the software is developed and managed.

• Enterprise Architecture (EA) Entry: INL tool that maintains an inventory of all INL software applications and their associated attributes. These attributes include software application name and version, description, technical point of contact, the associated SSD and QLD, and the software management plans that are in place to manage the software application.

PLN-4005: Static Documentation

PLN-4005: Repository Documentation

Defined as all documentation stored in the repository, the following SQA specific documents must be included to conform to PLN-4005.

• Software requirements specifications (SRS)

• Software design descriptions (SDD)

• Requirements traceability matrix (RTM)

• Software test plan (STP)

• Failure-analysis report (FAR)

• Communication and contact information (CCI)

• Software coding standards (SCS)

PLN-4005: Development Documentation

The following records shall be maintained to document the change control process leading to a release:

• Change Requests (Pull/Merge Requests)

• Issues (GitHub/GitLab)

• Test results (CIVET)

• Release logs (create as part of release)

PLN-4005: Reviews

• Static Documentation Review: Changes to the static documentation follow the review procedure native to the INL system (SQA Lead will handle these).

• Design Verification Review: "A review shall be conducted by an independent reviewer. The reviewer may rely on assistance from any individual, but the final approval or disapproval is the sole responsibility of the independent reviewer. All comments are retained in the GitHub/GitLab system."

• Release Review: A release requires an additional release review to ensure compliance with the approved software requirements. Test results from CIVET are considered part of the review.

PLN-4005: Software Configuration Management

• Static Documentation is managed using INL tools.

• Items included in the repository are uniquely identifiable for all revisions or releases by the inherent capabilities of the version control system.

PLN-4005: Software Acquisition

INL's procedure for acquiring hardware and software resources (LWP-1305) has been modified to specifically exclude zero dollar open-source software from the requirement to submit an iBuy request for acquisition. This means that libraries like PETSc can be acquired, accepted and maintained as git submodules, and follow the normal change control process.

PLN-4005: Software Engineering Method

There is little restriction on how code shall be developed; the independent reviewer will be the gate-keeper regarding the specifics of the implementation for each change.

Every registered MooseObject requires a "design" page to describe the use of the object, and every test case must:

1. Define the requirement that the test satisfies

2. Reference one or more design documents

3. Reference at least one of the following:

   • An issue that motivated the test case

   • The CR that implemented the test case

   • The revision when it was created

PLN-4005: Software Test Execution

Five steps must exist between a change request and a release.

1. Change Request Testing: Pull/Merge Request testing

2. Code Review: Independent review of changes by Change Control Board (CCB) member

3. Development Branch Testing: Ensure the changes work together

4. Documentation: Build current website/documentation

5. Release: Final review and release by Project Lead (covered in INL course 0INL1862)

PLN-4005: Standards, Practices, Conventions, and Metrics

MOOSE and MOOSE-based applications must follow a coding standard that is defined in the Software Coding Standard (SCS) document.

Software development of MOOSE and MOOSE-based applications relies on an continuous agile integration process using test-driven development through pull/merge requests...

PLN-4005: Support Software

• GitHub/GitLab: repository service, change requests, and issue tracking.

• System Software: identified by the project lead, documented within the test results, and is associated with a release (e.g., operating system, compiler).

• Software tools: Continuous Integration for Verification, Enhancement, and Testing (CIVET) and Multiphysics Object Oriented Simulation Environment (MOOSE) testing and documentation systems.

PLN-4005: Records Collection, Maintenance, and Retention

Quality records identified in Section 5 will be held within the GitHub/GitLab record-keeping system and EDMS as specified. All records of MOOSE and MOOSE-based applications are managed per PLN-4653.

PLN-4005: Training

Line Manager: 0INL1631, Read PLN-4005, RDHERD01

Project and SQA Lead: OINL1631, QNSQASSQ Qualification, Read PLN-4005, RDHERD01, 0INL1862

CCB: 0INL1631, QNSQASSQ Qualification, Read PLN-4005, RDHERD01