Skip to content

SCAPA's SQA Guidance for Consequence Models that are not Safety Software

SCAPA’s Software Quality Assurance Guidance for Consequence Assessment Software Designed for Safety-Related and Other Non-Safety Applications incorporates the key elements found in the DOE guidance for safety software but does so using an appropriately graded approach that is readily implementable by DOE’s emergency management community and its software suppliers.  For software that does not have to meet the SQA requirements for safety software, this approach strikes an acceptable balance between the sometimes conflicting need to model complex environmental processes (e.g., atmospheric dispersion and deposition), permit timely innovation, and perform detailed SQA. 
The application of SCAPA SQA guidance does not supplant any applicable Quality Assurance Program (as require by DOE O 414-1C for each DOE organization).   All applicable requirements of an organization’s Quality Assurance Program must be implemented before or coincident with the application of SCAPA’s SQA guidance.  The SCAPA SQA guidance may be used in conjunction with other applicable SQA guidance (e.g., current or future guidance for non-safety software developed by the DOE Energy Facility Contractors Group or the American Society of Mechanical Engineers [ASME]), provided that it is not used to justify a reduction in SQA from what is specified here or in other applicable guidance documents or standards.

The SCAPA SQA guidance is based on the SQA framework for safety software described in DOE Guide 414.1-4.   For the development of new or the upgrading of existing safety-related and other non-safety consequence assessment software, SCAPA recommends minimum compliance levels for each of the ten SQA work activities described in DOE Guide 414.1-4.  Many applications are likely to require additional SQA beyond the minimum levels prescribed by SCAPA to meet any applicable DOE, site, contractor, and programmatic guidance.  For these applications, SCAPA presents guidance for prioritizing SQA work activities so that limited SQA resources can be allocated to activities that will provide the greatest cost benefit.  Additional SQA should in general be performed to first address higher-priority work activities before attempting to meet those with medium and low priorities.

SCAPA’s SQA guidance is applicable through all of the discrete life-cycle phases for a consequence assessment model:

  • Concept
  • Requirements
  • Design
  • Implementation
  • Test
  • Installation, Checkout, and Acceptance Testing
  • Operations
  • Maintenance
  • Retirement

Throughout the DOE complex, a number of relatively sophisticated consequence assessment models have been successfully and reliably used and tested over a period of many years.  These software products were developed under the SQA requirements that were spelled out in their original scopes of work and project management plans.  For most, this involved following a comprehensive set of good business SQA practices for model development, documentation, training, and testing.
In many cases, extensive SQA documentation (e.g., planning documents, verification and validation [V&V] testing records) are no longer available because of limited records retention periods, degradation of old electronic storage media, and limited storage space for hardcopy records.  It makes little sense from a cost-benefit standpoint to go through the expensive and time-consuming process of recreating discarded SQA documentation for time-tested “legacy” codes.  It makes even less sense to stop using time-tested models that are not used for nuclear safety applications simply because the original SQA information from the pre-operational phases of the software lifecycle were not retained.

As a result, SCAPA SQA guidance permits the continued use of existing consequences assessment software  products that have adequate technical and user documentation, an extensive history of use in the DOE complex (or for other government agencies), and a program to maintain appropriate SQA throughout the software’s remaining life cycle phases.  For a legacy code to remain in compliance with SCAPA’s SQA guidance all future development work (e.g., software updates and enhancements) must fully comply with the SQA guidance for all ten SQA work activities.