Personal tools


DOE G 414.1-4A, Software Quality Assurance Guide for Use with DOE O 414.1D, Quality Assurance

Functional areas: Software Quality Assurance, Safety

The revision to DOE G 414.1-4 will conform to the revised DOE O 414.1D and incorporate new information and lessons learned since 2005, including information gained as a result of the February 2011, Government Accountability Office (GAO) report, GAO-11-143 NUCLEAR WASTE: DOE Needs a Comprehensive Strategy and Guidance on Computer Models that Support Environmental Cleanup Decisions.

g414.1-4A_2-4-15.pdf -- PDF Document, 1274 KB

Comments on draft Directives must be submitted through the DOE Directives RevCom system. If you have questions or need RevCom training, please contact us.

Writer: Website Administrator
  • Management and Operations
  • Safety
  • Security
ID: DOE G 414.1-4A
Type: Guide
OPI: AU - Office of Environment, Health, Safety and Security
Status: Draft - for Review
Approved Date: Feb 04, 2015

Document Actions

Debra Williams - EFCOG SQA Task Group General Comments says:
Mar 17, 2015 05:39 PM

1. The intent of this guide is to provide supplemental information, but not violate the purpose of a GOCO contractual relationship. The intention is not to tell the contractor how best to do their job. DOE recognizes that it is impossible to give single guidance to the entire DOE complex that optimally applies to all situations. The contractor is ultimately responsible for selecting the most appropriate implementation of software quality and safety based on their professional judgment, experience, expertise, and budgets. It is critical that this guide is clear on that intent.
2. Extensive use of NQA-1 (cited and uncited) is used to detail the SQA work activities in this guide. The very nature of the wording and the examples has a perspective of software that interfaces with hardware and can directly cause hazards. This is unnecessary for the vast majority of software at an R&D laboratory. If followed for R&D activities, this guide would dramatically increase the cost of R&D and potentially create irreparable harm to R&D programs. Clarity needs to be added to the graded approach for non-nuclear functions, to be clear that NQA-1 is not the only option.
3. Bulleted lists give the impression that all bullets apply. Even though the guide talks of determining applicability, this is often overlooked for bulleted lists. Always include “, as applicable” in the introduction of the bulleted lists, unless it is the intent that all bullets will always apply.
4. It is incorrect to equate quality with safety. Software with no defects can be extremely dangerous depending on its interactions with the system. Software riddled with defects could prevent any useful functions from performing, including those functions that introduce hazards, and thus it is completely safe. The mind set of achieving safety through quality is in itself unsafe.
5. Instead of recommending grading levels (3 for safety software and 4 for other software) this guide should provide an approach for determining how many grading levels are appropriate for the risk/potential hazard consequences associated with software used by a facility based on mission, nuclear safety activities, other contract drivers for SQA, etc.
6. The guide reads more like a tutorial than a guide. It needs to be rewritten in the form of a guide.

7. Security of software is an important topic that can affect quality and safety. This section should address the inter-relationship and how to integrate existing cyber security requirements with the software quality assurance requirements from the various DOE orders.

Add feedback

To submit feedback about this document, fill out the form below. Submissions will be published on the page only after review and approval.

Question: What day of the week comes two days after Monday
Your answer: