ML20017A145

From kanterella
Jump to navigation Jump to search

T9S900SQAP, Rev B, Software Quality Assurance Plan - Redacted
ML20017A145
Person / Time
Site: University of Lowell
Issue date: 01/06/2020
From:
General Atomics, Xerox Corp
To:
Office of Nuclear Reactor Regulation
References
GA/EMS-4791 T9S900SQAP, Rev B
Download: ML20017A145 (22)
v • d • e


Text

arseam xerox.

arseam T9S900SQAPB_Redacted.pdf 01 /06/20 1 O:Li2 AM Xerox WorkCentre 7855

+

GBN&RAI. ATOll,flCS

-..rnlOlffC...... -

Software Quality Assurance Plan TRIGA Control System NRAD Reactor Instrumentation and Control Console Replacement Project General Atomics ESI TS900SQAP, Rev.B Contract No. 99551 T9S900SQAP December 2010 Software Quality Assurance Plan 1

ISSUFJRELEASE

SUMMARY

T.J4SS <REV. IM9I Oit&P SAFE.CLS QALVLJCLS DOC. TYPE PROJECT DOCUMENT NO.

APPVL

~~ LEVEL EIS 2

. p 0!015*

T9S900SQAP B

ONIA SYSTEM SBIS.CLS.

SEIS.CAT.

8.CLASS 900 NIA NIA NIA TI1LE:

Software Quality Assurance Plan - NRAD React'?{ Instrumentation and Control Console CM APPROVAIJ REV.

PREPARED DATE BY F.NGINBERINO V.Dixon A

H. Staines H.'Walker 11/10/lO B

~~~).

H. Walker

~,t\\

USE CONTINUATION SHEET

  • See List of Effective Pages APPROVAL BY GENERAL ATOMICS APPROV AL(S)

A PROJECT M. Miller RRay M.Miller RJ

/I'/.~

- 4{t f"41D{IO I,,(tt7 REVCSlON DESCRIPTION Initial 1ssue Incorporate customer comments NEXT JNDENTIJRED DOCUMENT (S)

NIA COMPU1ER PROGRAM

TABLE OF CONTENTS

1.

INTRODUCTION ***-***--*------*-**.. *-*--.. -*-*---**-**---**-***--***-*.. -*--*-*-**-**-**4 1.1 PuRPosE....................................................................................................................................................... 4 12 SCOPE............*....*..*....*.....................*................*..*....****...........***...............*.*.*..............*...***..*.*....*........*.... 4 1.3 SYSTEM OVERVIEW..................................................................................................................................*... 4 1.4 REGULATORY ANDSTANDARDSC0MPLIANCE...................................................................................*......... 5

2.

REFERENCE DOCUMENTS*-**********-*****--***--****--*.. -**-**-.. ****-***---**-.. --........ -............ __ 5 2.1 Go'VERNl\\.ffiNf REGULATIONS, GUIDANCE AND REPORTS................*.......................*.................................... 5 22 STANDARDS/PROCEDURES............................................................................................................................ 5 23 TRI GA CONTROL SYSTEM PROJECT Doc1.JMENTS......**....*..................................................*....................... 6 2.4 DEFINITIONS AND ACRONYMS...................................................................................................................... 6

2. 4.1 Definitions.......................................................................................................................................... 6 2 4.2 Acronyms.............................................................................................................................................. 8
3.

MANAGEMENT OF THE SOFTWARE QA FUNCTION........ ________... _____.. ___.... ___...... -8 3.1 0RGANIZAT10N...........................................................*................................................................................. 8 3.1.1 TRJGA Control System Project Roles and Responsibilities (Internal Structure).................................... 9 3.2 TASKS, GENERAL DESCRIPTJON.................................................................................................................... 9 3.2. J Task: Evaluate the Project Planning and Control Process.................................................................. 9 3.2.2 Task: Evaluate Software Tools and Compiaer Programs..................................................................... 9 3.2.3 Task: Evaluate the System Requirements Process................................................................................ 10 3.2.4 Task: Evaluate the System Design Process......................................................................................... 10 3.2.5 Task: Conduct Reviews of Software Products...................................................................................... IO 3.2. 6 Task: Evaluate the Software Requcrements Process.........,.................................................................. JO 3.2. 7 Task: Evaluate the Software Design Process..................................................................................... I 0 3.2.8 Task: Evaluate the Unit Coding/Unit Testing Process...................................................................... I 1 3.2. 9 Task: Evaluate the Software Integration Testing Process.................................................................. 11 3.2. IO Task: Evaluate the System Testing Process................................,................................................... 11 3.2_j 1 Task: Evaluate the Installation and Checkout Process................................................................ 12 3.2./2 Task: AudiJCyberSeC1D'ity........................................................................................................... 12 3.2.13 Task: Media Certification...................................................................................................... I 2 3.2.14 Task: Non-Deliverable Software Certification.............................................................................. 12 3.2.15 Task. Evaluate Storage and Handling Process............................................................................... 12 3.2.16 Task: Evaluate Subcontractor Control............................................................................................ 12 3.2.17 Task.* Evaluate Deviations and Waivers.......................................................................................... 13 3.2.18 Task: Evaluate Configuration Management Process....................................................................... 13 3.3 ROLES AND REsPONSIBILITIES IN QUALITY................................................................................................ 13 3.3.1 GA-ES] Director of Qualzty............................................................................................................... 13 3.3.2 TRJGA Control System Software Quality........................................................................................... 13 3.3.3 TR/GA Control System Verification and Validation Team.................................................................. 14 3.4 SOFrWAREQUALrrYREsoURCEREQUIREMENTS...................................................................................... 14

3. 4.1 F,quipment and Infrastructure...................................................................................................... 14 3.4.2 Personnel.................................................................................................................................... /4
4.

IXk:UMENT ATION--*-*-********-***-**--**-***-**--*.. **--*---****--*******----*-***-*******--*----14 4.1 MINWUM Docu11ENT ATION...................................................................................................................... 14 42 USER DoclJl'vffiNTATION 011ffiR DoclJMENTATJON.................................................................................... 14

5.

ST AND ARDS, PRACTICES, CONVENTIONS AND METRICS..... -*-*--********-*--*-**-*--*** 15 5 /.1 Documentation Standards............................................................................................................... I 5 5.1.2 Design Standards............................................................................................................................... I 5 5.1.3 Coding Standards............................................................................................................................... I 5 General Atomics ESI TS900SQAP,Rev. B Software Quality Assurance Plan 2

5.1.4 Commentary Standards................................................................................................................. 15 5.1.5 Testing Standards and Practices..................................................................................................... 15 5.1.6 Software Product Qualiiy Metrics............................................................................................... 15 5.1. 7 Software Process Quality Metrics..................................................................................................... 15

6.

SOFfW ARE REVIEWS......................... _.................... *------***-*-*-****-**-**---***-*-*-****-**-16 6.1 S0fTW ARE REVIEWS, GENERAL................................................................................................................. 16 62 MJN[l\\,flJM REQUIREMENTS.......................................................................................................................... 16 6.2 1 Software Specification Review (SSR)................................................................................................... 16 6.2.2 Architecture Design Review or Preliminary Design Review(PDR)....................................................... 16 6.2.3 De/ailed Design Review or Critical Design Review (PDR).................................................................. 16 6.2.4 Verification & Validation Plan Review................................................................................................ 16 6.2.5 Functional Configuration Audit (FCA)................................................................................................. 17 6.2.6 Physical Configuration Audit............................................................................................................. 17 6.2. 7 In-Process Audits.............................................................................................................................. 17 6 2.8 Managerial Reviews......................................................................................................................... 17 6.2.9 Software Configuration Management Plan Review........................................................................... 17 6.2.10 Post-Implementation Review............................................................................................................ 17 63 OTHER REY!EWS AND AUDITS................................................................................................................... 17

7.

SOFfW ARE TESTING............_... _.......... -.............................. *-****-..................................... -....... 17 7.1 TEsT AtrrOMATION.................................................................................................................................... 18

8.

PROBLEM REPORTING AND CORRECTIVE ACTION-................... _............. -

..................... 19

9.

TOOLS, TECHNIQUES AND METHODOLOGIES.......... -***-**.. -*-**-**-***-****-*---* 19 9.I TOOLS TO SUPPORT THE SOFIW ARE QUALITY EFFORT.............................................................................. 19 9.2 TEcHNIQUES TO SUPPORT THE SOFI'WARE QA EFFORT.............................................................................. 19

10.

MEDIA CONTROL......................... --.................................................................. --..................... 19

11.

SUPPLIER CONTROL.................. --................................................ -

.......................................... -.19 U.

PROCURED SOFIW ARE AND SOFTWARE SERVICES.................................... -

............ _... 20

13.

OTHERWISE ACQUIRED SOFTWARE.............. _............................................................................ 20

14.

RECORDS COLLECTION, MAINTENANCE AND RETENTION................................ -

............. 20

15.

TRAINING.. -

................................................................................................................................... -.... 20

16.

TRIGA CONTROL SYSTEM RISK MANAGEMENT... -

................................................................ 20

17.

GWSSARY....................................................................... -

.......................... -........................................ 20

18.

SQAP CHANGE PROCEDURE AND HISfORY.................................................................................. 20 TABLE OF FIGURES FIGURE 1: PROJECT ExTERNAL INTERFACES............................................................ 8 Table 1 Table 2 Project Responsibilities Project Control Tools General Atomics ESI TS900SQAP, Rev. B LIST OF TABLES 9

19 Software Quality Assurance Plan 3

1.

INTRODUCTION 1.1 PURPOSE The purposes of this Software Quality Assurance Plan (SOAP) are to define:

The Software Quality organization for TRIGA Control System General Atomics Electronic Systems Inc. (GA-ESI)

Software Quality tasks and responsibilities The standards, practices and conventions* used to perform Software Quality activities; and The tools, techniques, and methods to support Software Quality activities and Software Quality reporting.

The TRIGA Control System Project includes:

The CSC computer unit in master mode, which functions as a radiation data processor 1.2 SCoPE This SOAP articulates Software Quality activities Oncludin'g those of software quality engineering, software quality assurance and software testing) performed throughout the software development life cycle of the TRIGA Control System. This plan will define Software Quality functions for this project and specify the reporting activities of Software Quality to the GA-ESI Quality directorate, with communications links to the TRIGA Control System Project Manager and Engineering Manager.

A key goal of the Software Quality function is to verify that all software and documentation to be delivered meet all technical requirements. The Software Quality tasks defined herein shall be used to examine deliverable software and documentation to determine compliance with technical and regulatory compliance requirements.

1.3 SYSTEM OVERVIEW The TRIGA Control System shall include instrumentation for monitoring reactor parameters during all operational states and for recording all variables important to reactor operation. It also shall manage all control rod movements taking into account the choice of operating mode and interlocks. The TRIGA Control System is a computer-based system, but includes dedicated hardwired displays and controls so that safe operation can continue should the computers become unavailable. There are two major system components, the Control System Console (CSC), Data Acquisition and Control (DAC).

General Atomics ESI TS900SQAP,Rev. B Software Quality Assurance Plan 4

1.4 REGULATORY AND STANDARDS COMPLIANCE This SQAP Is written to comply with the Quality Assurance Requirements contained in Appendix D of document SOW-8330 which sites compliance to ASME NQA-1-2000. The TRIGA project will also comply with internal GA-ESI Quality procedures and RMS Engineering Operating procedures and Quality Manual.

Section C.2 of Nuclear Regulatory Commission document RG 1.152 describes:

A waterfall software development model A specific software development life cycle (SDLC) consisting of:

Concept phase Installation and Checkout phase Requirements phase Operation phase Design phase Maintenance phase Implementation phase Retirement phase Testing phase This SOAP is also written in accordance with the requirements of GA-ESI Quality Manual section 22 Software Control and GA-ESI Quality Assurance Procedure OAP 22-02 Software Quality Assurance Plan Implementation. It is applicable to the first six SDLC phases listed above, from the Concept phase through the Installation and Checkout phase.

2.

REFERENCE DOCUMENTS 2.1 GOVERNMENT REGULATIONS, GUIDANCE AND REPORTS ISSUED BY DOCUMENT IDENTITY NRC 10 CFR 50, Appendix B NRC RG 1.152, Rev 2 NRG RG 1.168, Rev. 1 NRG RG1.170 NRG RG 1.171 NRG RG 1.172 NRC RG 1.173 2.2 STANDARDSIPROCEDURES ISSUED BY DocUMENT IDENTITY GA-ESI S00008001 GA-ESI S00008004 GA-ESI SQAJ1-7,9, 10 GA-ESI QAP-16-01 GA-ESI QAP-22-02 General Atomics ESI TS900SQAP, Rev. B TITLE Quality Assurance Criteria for Nuclear Plants and Fuel Reprocessing Plants Criteria for Digital Computers In Safety Systems of Nuclear Power Plants Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants Software Test Documentation for Digital Computer Software Used in Safety Systems of Nuclear Power Plants Software Unit Testing for Digital Computer Software Used in Safety Systems of Nuclear Power Plants Software Requirements Specifications for Digital Computer Software used In Safety Systems of Nuclear Power Plants Development Software Life Cycle Processes for Digital Computer Software Used in Safety Systems of Nuclear Power Plants TITLE Quality Manual Rev. T Software Standards and Procedures Manual Software Quality Assurance Instructions Corrective and Preventive Actions Software Quality Assurance Plan Implementation Software Quality Assurance Plan 5

IEEE IEEE STD 7.4.3.2 Standard Cnteria for Digital Computers In Safety Systems of Section 5.3 Nuclear Power Generating Stations IEEE IEEE Std 610.12-1990 IEEE Glossary of Software Engineering Terminology IEEE IEEE Std 829-1998 IEEE Standard for Software Test Documentation IEEE IEEE Std 1008-1987 IEEE Standard for Software Unit Testing IEEE IEEE Std 1016-1998 IEEE Recommended Practice for Software Design Descriptions IEEE IEEE Std 730-2002 IEEE Guide to Software Quality Assurance Plans IEEE IEEE Std 16085-2006 Systems and Software Quality Engineering-life Cycle Processes-Risk Management GA-ESI OP-4.0-160 Authorization of Deviations Procedure ASME NQA-1-2000 Quality Assurance Requirements for Computer Software for Subpart 2.7, Nuclear Facility Applications Requirement 2, 3,11,13, 18 2.3 TRIGA CONTROL SYSTEM PROJECT DocUMENTS ISSUED BY DocUMENT IDENTilY TITLE GA-ESI TRP-1029-05 Technical Requirements & Approach BENINL SOW-8330, Rev 0 Replacement of the NRAD Instrumentation and Control Console GA-ESI T9S900SQAP, Rev. B Software Quality Assurance Plan GA-ESI GATR-E--03, rev C Validation Program GA-ESI T9S900CMP, Rev. A Configuration Management Plan 2.4 DEFINmONS AND ACRONYMS 2.4.1 Definitions Code (1) In software engineering, computer instructions and data definitions expressed in a programming language or In a form output by an assembler, compiler, or other translator. (2) To express a computer program in a programming language.

(IEEE 610.12-1990]

Component One of the parts that make up a system. A component may be hardware or software and may be subdivided into other components. Note:, The terms "module", "component", and ~unit" are often used interchangeably or defined to be sub-elements of one another in different ways depending upon the context.

The relationship of these terms is not yet standardized. (IEEE 610.12-1990]

Configuration A discipline applying technical and administrative direction and surveillance to:

Management identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE 610.12-1990]

Design (1) The process of defining the architecture, components, interfaces, and other characteristics of a system or component, (2) The result of the process in (1).

[IEEE 610.12-1990]

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 6

Design A document that describes the design of a system or component Typical specification (or contents include system or component architecture, control logic, data structures, design description)

Input/output formats, Interface descriptions, and algorithms. [IEEE 610.12-1990)

Engineering In configuration management, an alteration In the configuration of a configuration change Item or other designated item after formal establlshment of its configuration Identification. [IEEE 610.12-1990]

Functional An audit conducted to verify that the development of a configuration Item has configuration audit been completed satisfactorily, that the Item has achieved the performance and functional characteristics specified In the functional or allocated configuration identification, and that its operational and support documents are complete and satisfactory. [IEEE 610.12-1990]

Interface (1) A shared boundary across which Information Is passed. (2) A hardware or software component that connects two or more other components for the purpose of passing information from one to the other. [IEEE 610.12-1990]

Module (1) A program unit that Is discrete and Identifiable with respect to compiling, combining with other units, and loading; for example, the input to, or output from, an assembler, compiler, linkage editor, or executive routine. (2) A logically separable part of a program. [IEEE 610.12-1990]

Physical An audit conducted to verify that a configuration item, as built, conforms to the configuration audit technical documentation that defines it [IEEE 610.12-1990]

Project plan A document that describes the technical and management approach to be followed for a project The plan typically descnbes the work to be done, the resources required, the methods to be used, the procedures to be followed, the schedules to be met, and the way that the project will be organized. [IEEE 610.12-1990]

Requirements A document that specifies the requirements for a system or component specification Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards. PEEE 610.12-1990]

Software design A representation of software created to facilitate analysis, planning description or SOD Implementation, and decision making. The software design description is used as a medium for communicating software design information, and may be thought of as a blueprint or model of the system. [IEEE 610.12-1990]

Software A collection of material pertinent to the development of a given software unit or development folder set of related units. Contents typlcally include the requirements, design, orSDF technical reports, code listings, test plans, test results, problem reports, schedules, and notes for the units. [IEEE 610.12-1990)

Software library A controlled collection of software and related documentation designed to aid in software development, use, or maintenance. Types include master library, production library, software development library, software repository, system library. [IEEE 610.12-1990)

Test plan A document describing the scope, approach, resources, and schedule of intended testing activities. It Identifies test Items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning. [IEEE 829-1998]

Unit (1) A separately testable element specified in the design of a computer software component (2) A logically separable part of a computer program. (3) A software component that is not subdivided into other components. [IEEE 610.12-1990]

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 7

Version (1) An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item. (2) An initial release or complete re-release of a document, as opposed to a revision resulting from issuing change pages to a previous release.

[IEEE 610.12-1990]

2.4.2 Acronyms CDR Critical Design Review DIU Detector Interface Unit FCA Functional Configuration Audit GA-ESI General Atomics Electronic Systems Inc.

PCA Physical Configuration Audit PDR Preliminary Design Review QA Quality Assurance OAP Quality Assurance Procedure SCMP Software Configuration Management Plan SDLC Software Development Life Cycle SPMP Software Project Management Plan SQAI Software Quality Instructions SOAP Software Quality Assurance Plan SSR Software Specification Review V&V Verification & Validation

3.

MANAGEMENT OF THE SOFTWARE QA FUNCTION 3.1 0RGANIZA TION

Director, GA-ESI TRIGA Director, QuaUty I

Eng'rg Manager I

Eng'rg Project Manager Software Eng'rg Software Quality Hardware Eng'rg V&VTeam Figure 1: Project External Interfaces General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 8

3.1.1 TRIGA Control System Project Roles and Responsibilities (Internal Structure)

Pos~n "'

".f

~£'

¥

, Role/ResoonsibilHv '"

~

Project Manager Performs project management through the SDLC; manages project scope, schedule and resources; manages organizational, developmental and supporting processes.

Engineering Manager Provides software engineering and hardware engineering resources to the project. Reports to the project manager.

Software Quality Provides quality engineering, quality assurance and testing services to the project. Reports to the GA-ESI Director of Quality Software V&V Team Provides verification and validation services to the project.

Reports to the GA-ESI Director of Quality Table 1: Project Responsibilities Members of the TRIGA Control System development team shall have the ability to evaluate and/or monitor the quality of the software being developed. Also, the status and disposition of each item in the project anomaly database shall be available to members of the development team. This SOAP is authored and maintained by the TRIGA Control System Software Quality Engineer.

3.2 TASKS, GENERAL DESCRIPTION Software Quality tasks are performed on the software development process and on software development products.

Software Quality tasks are performed in relationship to the software development activities taking place and several Software Quality tasks may be performed concurrently. A task is considered complete when the required actions and report(s) are satisfactorily completed and/or action items have been closed. General task descriptions for Software Quality are provided in the subsections which follow.

The listed tasks and subtasks address the requirements set forth in the GA-ESI Quality Instructions and Procedures Volume 1 (Quality Manual Rev T), GA-ESI Software Quality Assurance Instructions and provides adherence to contractually prescribed software quality requirements.

3.2.1 Task: Evaluate the Project Planning and Control Process Project planning and control includes the creation of project management plans, measuring planned-versus-actual performance, and managing projects to successful conclusion. Software Quality will identify appropriate standards, guidelines, and other documents to support successful project execution. Software Quality will use a checklist to evaluate the Software Project Management Plan and report the results using a standard GA-ESI report form or a standard GA-ESI memorandum.

3.2.2 Task: Evaluate Software Tools and Computer Programs Software Quality shall evaluate software tools and computer programs used during development or formal verification and validation of the TRIGA Control System Project software.

Software tools and computer programs shall be assessed based on criteria described in ASME NQA-1 -2000 Requirement 3, paragraph 401 and 402, Requirement 11, paragraph 400 and Part II Subpart 2. 7 paragraph 601 and 602.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 9

3.2.3 Task: Evaluate the System Requirements Process The system requirements process includes: (1) Defining system requirements, (2) Analyzing requirements, and (3) Allocating functions to hardware and software. Software Quality shall:

Verify that appropriate participants are specified for this task.

Verify that system software requirements definition criteria are adequately specified.

Verify that system software requirements review criteria are adequately specified.

Verify that processes for defining, analyzing, and allocating system software requirements are followed.

Verify that system software requirements traceability is established and maintained.

Verify content, format and compliance of the SyRS.

3.2.4 Task: Evaluate the System Design Process The system design process includes: (1) Defining system architecture, (2) Partitioning the system into subsystems and components, and (3) Allocating functions to hardware and software. Software Quality shall:

Verify that appropriate participants are specified for this task.

Verify that system software design criteria are adequately specified.

Verify that system software design review criteria are adequately specified.

Verify compliance of the system software design review process.

Verify that the system software design change process is adequately specified.

Verify that system software design traceability is established and maintained.

Verify content, format and compliance of the system software design elements in the SyRS Review prototypes for content, format and compliance.

3.2.5 Task: Conduct Reviews of Software Products TRIGA Control System software products shall be reviewed using GA-ESI SQAI -2 Coding Standards and Conventions, SQAl-7 Coding/Design Walk-through Certification and SQAl-10 Review of Documentation Pending Release.

3.2.6 Task: Evaluate the Software Requirements Process The software requirements process includes: (1) Defining requirements, (2) Analyzing requirements, and (3) Allocating functions to hardware and software. Software Quality shall:

Verify that appropriate participants are specified for this task.

Verify that requirements definition criteria are adequately specified.

Verify that requirements review criteria are adequately specified.

Verify that processes for defining, analyzing, and allocating requirements are followed.

Verify that requirements traceability is established and maintained.

3.2.7 Task: Evaluate the Software Design Process The software design process includes: (1) Defining software architecture at the system level, and (2) Partitioning the software into subsystems, components, etc. The software design process is sometimes segregated Into: (1) Top-level design and (2) Detailed design. Software Quality shall:

Verify that appropriate participants are specified for this task.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 10

Verify that design criteria are adequately specified.

Verify that Software Development Folders (SDFs) are created.

Verify that design review criteria are adequately specified.

Verify compliance of the design review process.

Verify that the design change process is adequately specified.

Verify that software safety and hazards have been adequately addressed.

Verify that design traceability is established and maintained.

3.2.8 Task: Evaluate the Unit Coding/Unit Testing Process Software implementation is synonymous with "programming* or "coding." The Implementation Phase is the activity In the SDLC in which the design is coded and implemented. Unit (or module) coding normally includes unit testing tasks by programmers. Software Quality shall:

Verify that a complete set of testing documents exist for Component Testing.

Review all testing documents for content, format and compliance.

Verify that testing is performed In accordance with the Component test plan, test designs, test cases, test procedures and applicable standards.

Perform periodic surveillance of testing, witness tests, and certify test results.

Verify that defects found during testing are captured, verified, logged and developers are supported to resolve the defects.

Verify that test logs are established and maintained.

Verify that Software Development Folders (SDFs) are maintained.

Verify that code traceability is established and maintained.

3.2.9 Task: Evaluate the Software Integration Testing Process During this process software elements are combined and then tested to ensure that the combined software elements work together correctly. First, units/modules are incrementally-integrated and integration testing is repeatedly performed on incrementally-integrated units/modules. Eventually, integrated units/modules become software components. Software.

components are then incrementally combined and testing is performed on the incrementally-integrated software components. Integrated components eventually become software subsystems, and testing is performed on the incrementally-integrated subsystems. Subsystems eventually are combined to produce a system and the system testing is then possible. Software Quality shall:

Verify that complete sets of Integration testing documents exist.

Review all testing documents for content, format and compliance.

Verify that testing is performed in accordance with the Integration test plan, test designs, test cases, test procedures and applicable standards.

Perform periodic surveillance of testing, witness tests, and certify test results.

Verify that defects found during testing are captured, verified, logged and developers are supported to resolve the defects.

Verify that test logs are established and maintained.

3.2.10 Task: Evaluate the System Testing Process During this process, software is tested as an integrated system. In the event that all but one subsystem is complete, the remaining subsystems are integrated, the missing subsystem is simulated and testing is performed as though the entire system is present. Software Quality General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 11

shall:

Verify that complete sets of System testing documents exist.

Review all testing documents for content, format and compliance.

Verify that testing is performed in accordance with the System test plan, test designs, test cases, test procedures and applicable standards.

Perform periodic surveillance of testing, witness tests, and certify test results.

Verify that defects found during testing are captured, verified, logged and developers are supported to resolve the defects.

Verify that test logs are established and maintained.

3.2.11 Task: Evaluate the Installation and Checkout Process During the Installation and Checkout phase the software is installed into the target system, a checkout process is performed and acceptance testing is conducted. Software Quality shall:

Verify that complete sets of acceptance testing documents exist for the TRIGA Control System Project.

Review all testing documents for content, format and compliance.

Verify that testing is performed in accordance with the Acceptance test plan, test designs, test cases, test procedures and applicable standards.

Perform periodic surveillance of testing, witness tests, and certify test results.

Verify that defects found during testing are captured, verified, logged and developers are supported to resolve the defects.

Verify that test logs are established and maintained.

3.2.12 Task: Audit CyberSecurity Software Quafity shall conduct periodic audits to determine the effectiveness of the dJgital safety system security procedures for TRJGA Control System products as set discussed in RG 1.152.

3.2.13

  • Task: Media Certification Software Quality shall verify that the media used for source code and object code are identified correctly, that the media is readable, and [tf required) that the media autoloads properly.

3.2.14 Task: Non-Deliverable Software Certification The project may use non-deliverable software in the development of deliverable software as long as the operation and support of the deliverable software after delivery does not depend on the non-deliverable software. Software Quality shall certify that the use of deliverable software is not dependent on non-deliverable software to execute. Software Quality shall verify that ail non-deliverable software used on the project performs its intended functions.

3.2.15 Task: Evaluate Storage and Handling Process Software Quality shall verify that there is a plan or set of procedures for storage and handling of media. Software Quality shall evaluate the plan or procedures for adequacy.

3.2.16 Task: Evaluate Subcontractor Control Software Quality shall ensure that software development processes and products for deliverable software from subcontractors conform to contract requirements.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 12

3.2.17 Task: Evaluate Deviations and Waivers Software Quality shall be included in the review cycle of requests for deviations and waivers and support the processing of same in accordance with TRIGA Control SystemOP-4.0.160 Authorization of Deviations.

3.2.18 Task: Evaluate Configuration Management Process Software Configuration Management is separately addressed in the TRIGA Control System Software Configuration Management Plan (SCMP). Software Quality shall:

Ensure configuration baselines are established as planned and that Configuration Items include, but are not limited to:

Project Documentation Computer programs (source code, etc.)

support software Verify that an adequate set of configuration management documents are available to support the TRIGA Control System Project. These documents shall address:

Configuration Identification Configuration Status Accounting Configuration Control Configuration Audits Review configuration management documents for content, format and compliance.

Verify that the performance of configuration management complies with configuration management documents, including operation of the software development library.

Perform periodic configuration audits Perform periodic surveillance of the configuration management function to ensure the change control process includes:

- initiation, evaluation and disposition of change requests

- control and review/approval of changes prior to implementation or release.

- requirements for re-test and acceptance of test results.

3.3 ROLES AND RESPONSIBILITIES IN QUALITY

-3.3.1 GA-ESI Director of Quality The GA-ESI Director of Quality is responsible for:

Reviewing and approving the TRIGA Control System SOAP.

Supporting the implementation of the quality program defined in the TRIGA Control System SQAP.

Providing adequate resources for the performance of TRIGA Control System Software Quality and Software Testing functions.

Representing the Quality directorate at the executive level at TRIGA Control System SDLC phase reviews 3.3.2 3.3.2.1 TRIGA Control System Software Quality TR/GA Control System Software Quality TRIGA Control System software quality is responsible for:

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 13

providing objective insight into the maturity and quality of the software processes and associated work products on the TRIGA Control System Project Recording, monitoring and facilitating the resolution of TRIGA Control System Project quality issues.

Ensuring compliance with the contents of this SQAP Conducting training in software quality and software testing, as necessary.

Wrtnessing software testing and certifying the quality of deliverable software 3.3.3 TRIGA Control System Verification and Validation Team The TRIGA Control System Verification and Validation (V&V) Team is responsible for the performance of TRIGA Control System verification and validation tasks in accordance with the TRIGA Control System SVVP.

3.3.3.1 TR/GA Control System Software Testing The TRIGA Control System Software Testing group is responsible for.

Composing testing documents for component testing, integration testing, system testing and acceptance testing in accordance with GA TR-E-03 Instrumentation System Firmware Validation Program.

Executing testing of deliverable software and associated documentation in accordance with TRIGA Control System testing documents Documenting the performance of testing Identifying and logging defects found during the execution of testing Supporting software developers in the defect resolution process 3.4 SOFTWARE QUALITY REsoURCE REQUIREMENTS 3.4.1 Equipment and Infrastructure The GA-ESI Director of Quality shall ensure that adequate resources (work area, computing hardware, computing software, connectivity, etc.) to perform software quality and software testing tasks and functions.

3.4.2 Personnel The GA-ESI Director of Quality shall ensure that adequate staff Is available to perform software quality and software testing functions. Labor hour estimates for software quality and software testing, per task or per document, are enumerated In the previously-discussed appendices to the TRIGA Control System SPMP.

4.

DOCUMENTATION 4.1 MINIMUM DocUMENTATION The following are minimum software project documentation requirements at the first formal software release:

Software Requirements Specification Software Design Description Software Configuration Management Plan Software V&V Plan Software V&V Report 4.2 USER DOCUMENTATION OTHER DocUMENTATION Other Software Quality documents, either required by regulation or regulatory guide by the U.S.

Nuclear Regulatory Commission, or as derived requirements, are also listed in an appendix to the SPMP, and not duplicated herein.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 14

5.

STANDARDS, PRACTICES, CONVENTIONS AND METRICS 5.1.1 Documentation Standards TRIGA Control System Documentation will follow the existing GA-ESI engineering document review-and-approval process, and configuration-controlled versions will reside on a designated Document Control Center network directory.

5.1.2 Design Standards Unless otherwise specified or disclosed, IEEE Std 1016-1998 is the guideline used for software design descriptions.

5.1.3 Coding Standards The TRIGA Control System Project shall use GSA-ESI procedure S00008004 Software standards and Procedures Manual as a guide for software code development 5.1.4 Commentary Standards The commentary standard for the TRJGA Control System Project is:

Commentary shall follow the content and format of the respective standard for which the commentary is targeted.

Commentary shall be written in U.S. English 5.1.5 Testing Standards and Practices Unless otherwise specified or disclosed, NRC RG 1.171 is the standard for unit testing, and NRC RG 1.168 is the standard for integration, system and acceptance testing for the TRJGA Control System Project. Testing shall also conform to test requirements in ASME NQA-1-2000 Part 1 Requirement 3, 11 and subpart 2.7.

5.1.6 Software Product QuaJlty Metrics Unless otherwise specified or disclosed, IEEE Std 982.1-1988 and in IEEE Std 982.2-1988 are guidelines for software product quality metrics for the TRIGA Control System. Software product metrics are contained within six (6) subcategories:

Errors, Faults, and Failures Complexity Mean-time-to-failure Reliability Growth &

Completeness &

Projection Consistency Remaining Products faults Metrics from these subcategories will be selected and will be tailored, as needed, for the TRIGA Control System Project during project execution.

5.1. 7 Software Process Quality Metrics Unless otherwise specified or disclosed, IEEE Std 982.1-1988 and in IEEE Std 982.2-1988 are guidelines for software process quality metrics for the TRIGA Control System. Software process metrics are contained within (3) subcategories:

Management Control Coverage Measures,

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 15

Risk, Benefits, and Cost Evaluation Metrics from these subcategories will be selected and will be tailored, as needed, for the TRIGA Control System Project during project execution.

6.

SOFTWARE REVIEWS 6.1 SOFTWARE REvlEWS, GENERAL

  • Unless otherwise specified or disclosed, IEEE Std 1028-1997 and ASME NQA-1-2000 Part II Subpart 2. 7 paragraph 202 are the guidelines for software reviews for the TRIGA Control System Project: Planned software reviews are listed in the appendices to the SPMP and are scheduled from phase-to-phase during the SDLC. The standards specify:

The purpose for each type of review Entry criteria Attendees, roles and responsibilities Review processes Review preparation Exit criteria Review procedures Outputs Issues and action Items resulting from reviews shall be recorded and tracked to closure.

Meeting minutes, including issues and action items shall be documented and placed in the project folder.

6.2 MINIMUM REQUIREMENTS 6.2.1 Software Specification Review (SSR)

While alternate nomenclature from that of IEEE Std 730-2002 may be used to identify a review, a review is planned for several TRIGA Control System Project documents including:

System Requirements Specification Software Requirements Specification

  • Software Design Description 6.2.2 Architecture Design Review or Preliminary Design Review(PDR)

An Architecture Design Review is planned for the TRIGA Control System Software Design Description. This review may be alternatively described in the TRIGA Control System Project as a Preliminary Design Review (PDR). This review is cited in Appendices to the SPMP.

6.2.3 Detailed Design Review or Critical Design Review (PDR)

A Detailed Design Review is planned for TRIGA Control System Project Software Design Descriptions. This review may be alternatively described in the TRIGA Control System Project as a Critical Design Review (CDR). This review is cited in Appendices to the SPMP.

6.2.4 Verification & Validation Plan Review A review is planned for the TRIGA Control System Project Software Validation & Verification Plan (SWP). This review is cited in Appendix 1 to the SPMP.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 16

6.2.5 Functional Configuration Audit (FCA)

Functional configuration audits are planned for TRIGA Control System Project software. The audits shall follow SQAJ-3 Configuration Identification Audit procedure.

6.2.6 Physical Configuration Audit A physical configuration audit (PCA) is planned for TRIGA Control System Project software.

The audit shall follow SQAJ-3 Configuration Identification Audit procedure.

6.2.7 In-Process Audits The following in-process audits are planned for TRIGA Control System Software.

Code vs. design documents Interface specifications (hardware and software)

Functional requirements vs. design Functional requirements vs. test documents These audits are cited in the appendices to the SPMP.

6.2.8 Managerial Reviews SDLC phase reviews shall be presented as managerial reviews at the end of each development phase in accordance with IEEE 1028-1997. As the TRIGA Control System Project progresses, additional managerial reviews may be desired.

6.2.9 Software Configuration Management Plan Review A TRIGA Control System Project Software Configuration Management Plan review is intended.

This review is cited in Appendix 1 to the SPMP.

6.2.10 Post-Implementation Review A post-implementation review shall be held concurrently with the SDLC phase review for the Installation & Checkout Phase, and the agenda for that review shall encompass the content for both the respective phase review and for the post-implementation review.

6.3 OTHER RevlEWS ANO AUDITS In the event that other reviews and/or audits are deemed necessary, each additional review/audit shall be enumerated in the appropriate appendix to the SPMP, scheduled and performed.

7.

SOFTWARE TESTING During the TRIGA Control System Project four types of software testing shall be conducted and comply with the requirements defined in NRC RG 1.168 and ASME NQA-1-2000 Part II Subpart

2. 7 paragraph 402 and 402.1:

Component Testing Integration Testing System Testing Acceptance Testing Software Quality shall:

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 17

Verify that complete sets of testing documents for each category of testing are composed in accordance with applicable standards.

Review all testing documents for content, format and compliance.

Verify that testing is performed in accordance with each test plan, test design specification, test case, test procedure and standards.

Perform continuous surveillance of testing, witness tests, and certify test results.

Verify that defects found during testing are captured, verified, logged and developers are supported to resolve the defects.

Verify that test logs are established and maintained.

7.1 TEST AUTOMATION To effect cost reduction and improve schedule performance in component testing and in regression testing the software testing group shall establish and sustain a test automation environment. This shall include the acquisition, installation, configuration and operation of automated test tools.

General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 18

8.

PROBLEM REPORTING AND CORRECTIVE ACTION Problem Reporting and corrective actions shall follow GA-ESI OP-6.6-210 Software Discrepancy Reporting procedure for all software product related issues in development.

Software process issues shall follow GA-ESI QAP-16-01 Coffective and Preventive Action procedure.

9.

TOOLS, TECHNIQUES AND METHODOLOGIES 9.1 TOOLS TO SUPPORT THE SOFTWARE QUALITY EFFORT TooL Pu,-~sJ... ~

/

~

,~

Microsoft Excel Budgeting Microsoft Outlook eMail Communications Microsoft PowerPoint BriefinQs Microsoft Project Schedule Tracking Microsoft Word Issue Tracking Microsoft Word Software Defect Tracking Microsoft Word Team Collaboration/Groupware PolvPVCS Software Configuration ManaQement Microsoft Word ReoortinQ Visual Labor Tracking Table 2: Project Control Tools 9.2 TECHNIQUES TO SUPPORT THE SOFTWARE QA EFFORT The following techniques have been defined to support Software Quality:

Placing TRIGA Control System Project management tools on the network to facilitate project visibility, accountability and transparency of project execution Conducting periodic management reviews, performed as phase reviews, at the end of each development phase to provide management with project status at defined milestones Weekly activity reports submitted by each member of the TRIGA Control System development project Routine project status briefings in which members of the TRIGA Control System Project provide status regarding their efforts toward TRIGA Control System Project completion

10.

MEDIA CONTROL Media control includes:

Regularly scheduled backup of media Labeling and inventories of stored media in accordance with media storage procedures Adequate protection from unauthorized access.

TRIGA Control System Project software shall be located in a Microsoft Visual SourceSafe repository in TRIGA Engineering. The TRIGA software CM librarian shall perform routine backups of the repository to DVD media. Software Quality will conduct periodic checks of media control to verify adequacy of the performance of the backups.

11.

SUPPLIER CONTROL For those non-developmental items which are acquired to support the TRIGA Control System development project, supplier control shall follow GA-ESl's existing purchasing/materials General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 19

management operating procedures.

12.

PROCURED SOFTWARE AND S0F1WARE SERVICES There is no planned or intended procurement of software or software services for the TRIGA Control System project.

13.

OTHERWISE ACQUIRED SOFTWARE Software that has not been previously approved under a program consistent the ASME NQA 2000 standard for use In its intended application shall be evaluated using the criteria defined in Part 11, Subpart 2. 7 paragraph 302 of the standard.

14.

RECORDS COLLECTION, MAINTENANCE AND RETENTION Software Quality activities are documented by records and reports throughout the software development life cycle. Metrics collected will be periodically reviewed for trends and process improvement opportunities. Software Quality records will be collected and maintained in a designated Document Center network directory for a minimum of 1 O years. Guidance regarding records collection and retention is contained in GA-ESI operational procedures for the operation of the GA-ESI Document Center.

15.

TRAINING Training will be provided to the staff assigned to perform software quality functions for the TRIGA Control System Project. Some training will be performed in the dassroom; some as on-the-job-training. The training schedule will be compatible with the project schedule.

16.

TRIGA CONTROL SYSTEM RISK MANAGEMENT Risk management shall be conducted to satisfy the requirements of IEEE Std 1012-2004, generally following the content of IEEE Std 16085-2006, as elaborated in the TRIGA Control System Risk Management Plan. Risk analyses shall be performed and presented at development phase reviews.

17.

GLOSSARY See Section 2.4.2 herein.

18.

SQAP CHANGE PROCEDURE AND HISTORY The SOAP is a configuration-controlled document As such, changes to the SOAP after its initial release shall follow the GA-ESI formal change process.

Revision Section Description of Chan e B

Global U dated to address corrective actions identified by INL General Atomics ESI TS900SQAP, Rev. B Software Quality Assurance Plan 20

Retrieved from "https://kanterella.com/w/index.php?title=ML20017A145&oldid=4633492"