NUCLEAR ENERGY INSTITUTE NUCLEAR INFORMATION TECHNOLOGY STRATEGIC LEADERSHIP POLICY FOR SOFTWARE QUALITY ASSURANCE IN THE NUCLEAR POWER INDUSTRY NITSL-SQA-2005-01 Revision 0 March 7, 2005
ACKNOWLEDGEMENTS Nuclear Information Technology Strategic Leadership (NITSL) is a NEI Community of Practice (COP) that provides a forum for information technology decision-makers and professionals to sponsor, empower, and promote overall coherence of activities, which support the Nuclear Information Technology community. NITSL sponsored the working group to develop this policy in support of its mission to coordinate a consistent direction for Software Quality Assurance. Stephen A Deskevich, Duke Energy Brooks M. Boylston, Progress Energy Robert Haverkamp, Southern California Edison Mark Draxton, Constellation Energy Randall Tate, Exelon Corp Greg Przyjemski, NITSL Program Manager NITSL Steering Committee Sponsor Mark Draxton, Constellation Energy Team Members NITSL STEERING COMMITTEE Cynthia Broadwell, Team Lead, Progress Energy Rich Buell, Entergy James Jones, Duke Energy Alan Lord, AmerenUE Independent Reviewers Daniel Bierbrauer, Constellation Energy Steve DeGange, Duke Energy Tom Duke, Duke Energy Jim Heilman, SC Electric and Gas Bob Quay, Energy Northwest Bill Higgins, Southern California Edison John Prehn, AEP Keith Morrell, Westinghouse, Savannah River Site Dave Valley, STP Rick Hackett, Arizona Public Service Company NITSL-SQA-2005-01 2 of 6 Rev. 0
POLICY FOR SOFTWARE QUALITY ASSURANCE IN THE NUCLEAR POWER GENERATION INDUSTRY Table of Contents 1.0 PURPOSE...4 2.0 SCOPE...4 3.0 DEFINITIONS...4 4.0 SOFTWARE POLICY...5 5.0 SQA PROGRAM ELEMENTS...5 6.0 SOFTWARE QUALITY CLASSIFICATION...6 7.0 REFERENCE(S)...6 NITSL-SQA-2005-01 3 of 6 Rev. 0
1.0 Purpose 2.0 Scope This document provides guidance for the management of software in support of the total nuclear quality assurance program. This document establishes minimum quality assurance program requirements for software used in safety systems covered by 10CFR50 Appendix B. The guidance contained herein may be applied using the graded approach to other software. 2.1 This policy applies to software used in safety systems covered by 10CFR50 Appendix B. 3.0 Definitions 3.1 Graded Approach The selective assignment of the quality assurance elements that the software must comply with based on its assigned quality classification. The quality classification is determined by the evaluation of the functional process(es) the software provides. 3.2 Software Life Cycle The period of time that begins when a software product is conceived and ends when the software is no longer available for use. Phases associated with software management including the following: Planning evaluation of options and coordination of activities to assure successful deployment of software Requirements specific and measurable characteristics that describe the intended use and performance of software Design the collection of information (requirements, architecture, etc.) that define software Implementation Implementation the process of translating the Design into software components Integration the process of combining software components with other software and/or systems and to reduce the introduction of undesirable characteristics (errors, anomalies, hazards, security threats) Validation (Testing) specific and measurable tests to demonstrate the software meets its Requirements Installation and Checkout placing software into the operational computing environment, documenting its baseline configuration, and performing final acceptance testing Operation and Maintenance on-going use of software and control of changes Retirement activities associated with the permanent removal of software from its operational computing environment 3.3 Software Quality Assurance (SQA) The program that establishes quality controls for the development, procurement, operation, use, maintenance, and retirement of software commensurate with its importance to nuclear safety. NITSL-SQA-2005-01 4 of 6 Rev. 0
4.0 Software Quality Assurance Policy Senior Management should establish the policy for software quality assurance. The policy should define the: 4.1 Scope and applicability of the software quality assurance program. 4.2 Authority and responsibility for implementing and governing software quality assurance. 4.3 Oversight of the Software Quality Assurance Program to insure regulatory compliance. 5.0 SQA Program Elements Software quality assurance procedures should define requirements and controls to be applied to software consistent with its importance to safety (the graded approach to quality). These should include: 5.1 Organization Responsibility 5.1.1 Define accountability for ownership of the software quality assurance procedure. 5.1.2 Define accountability for ownership of the software 5.2 SQA Program 5.2.1 Define SQA program interfaces with the overall Quality Assurance Program. 5.2.2 Define SQA program indoctrination and training requirements for software governed by this policy. 5.3 Design, Development, Modification and Testing 5.3.1 Apply controls to software, according to its quality classification, from the time specifications are approved until the system is retired. 5.3.2 Define procedures that identify processes for implementing the phases of the software life cycle as specified in section 3.2. The processes should specify the expected controls and documents based on the software quality classification and nuclear safety. 5.4 Procurement 5.4.1 Develop procurement documents that specify the software Requirements to assure the vendor meets the design intent. 5.4.2 Specify any special shipping, storage, and handling requirements in procurement documents. 5.4.3 Establish the conditions in procurement documents to assure the control of quality by vendor to provide software and/or services. 5.5 Procedures and Instructions Procedures governing software should be reviewed, approved and controlled. NITSL-SQA-2005-01 5 of 6 Rev. 0
5.6 Reviews and Inspections 5.6.1 Define measures to assure that the software meets procurement specification requirements before the software is accepted. 5.6.2 Establish controls to assure reviews, testing and inspection of software and documentation are performed prior to use. 5.7 Documentation and Records 5.7.1 Define document control and records management requirements for software life cycle documentation. 5.7.2 Develop documentation sufficient to prove the quality of the software during its life cycle. 5.8 Configuration Management 5.8.1 Describe software to assure unique identification necessary to maintain configuration. (name, version, platform). 5.8.2 Establish baselines for software to define the basis for further development, allow control of configuration items, and permit traceability between configuration items. 5.8.3 Use configuration activities to control and document changes to baselines. 5.9 Provisions for Error Management 5.10 Audits Use the corrective action program to manage software errors and subsequent resolution. Perform audits of the quality assurance programs governing software. 6.0 Software Quality Classification Criteria to classify software for meeting the requirements of 10 CFR Part 50, as applied to software, should be established and reflected in quality levels using a graded approach. 7.0 References 7.1 10CFR50, Appendix B - Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants 7.2 NUREG 0800, Section 7, BTP HICB-14, Guidance on Software Reviews for Digital Computer-Based Instrumentation and Control Systems NITSL-SQA-2005-01 6 of 6 Rev. 0