ML103610005
| ML103610005 | |
| Person / Time | |
|---|---|
| Site: | PROJ0773 |
| Issue date: | 12/23/2010 |
| From: | Burel J P Rolls-Royce Civil Nuclear SAS |
| To: | Document Control Desk, Office of Nuclear Reactor Regulation |
| Shared Package | |
| ML103610004 | List: |
| References | |
| TAC ME3600 | |
| Download: ML103610005 (96) | |
Text
Rolls-Royce Civil Nuclear SAS 23, Chemin du Vieux Chne 38246 Meylan Cedex - France Tél: +33 (0)4 76 61 15 00 www.rolls-royce.com Rolls-Royce Civil Nuclear SAS Société par actions simplifiée au capital de 1 040 000 Euros - rcs Grenoble 433 681 525 - code NAF 3320D Siret : 433 681 525 00021 - n.ident TVA : FR 77 433 681 525 Sige social : 23, Chemin du Vieux Chne - Meylan (Isre) 23 December 2010
U.S. Nuclear Regulatory Commission Document Control Desk 11555 Rockville Pike
Rockville, MD 20852 USA ATTENTION: To whom it may concern
SUBJECT:
Rolls-Royce submittal of new SPINLINE 3 licensing documents
REFERENCES:
(1) Project Number 0773:
SPINLINE 3 Digital Safety Instrumentation and Control Platform (TAC No. ME3600) (2) NRC letter dated December 8, 2010, "ACCEPTANCE FOR REVIEW OF ROLLS-ROYCE LICENSING TOPICAL REPORT "SPINLINE 3 DIGITAL SAFETY INSTRUMENTATION AND
CONTROL PLATFORM" (TAC NO. ME3600)" (ADAMS Accession No. ML1031301600)
Rolls-Royce hereby submits the follo wing documents in connection with the referenced NRC project.
Document Title Rolls-Royce Document Number V ersions: Proprietary (P), Non-proprietary (NP) Notes Rules for Verification and Validation of Software Components 1 207 107 D P Translated document Software Configuration Management Process 1 207 875 G P Translated document Safety Software Design Process 8 303 350 L P Translated document
At a public meeting between Rolls-Royce and the NRC at NRC Headquarters in
Rockville, Maryland, on November 2, 2010, Rolls-Royce committed to providing English translations of these three docum ents by December 31, 2010. This commitment is recorded in Reference 2.
Also submitted as part of this letter ar e updates of the complete set of mapping tables that originally were submitted to NRC as part of Rolls-Royce letter dated May 28, 2010 (ADAMS Accession No. ML101480946).
Rolls-Royce Civil Nuclear SAS 23, Chemin du Vieux Chne 38246 Meylan Cedex - France Tél: +33 (0)4 76 61 15 00 www.rolls-royce.com Rolls-Royce Civil Nuclear SAS Société par actions simplifiée au capital de 1 040 000 Euros - rcs Grenoble 433 681 525 - code NAF 3320D Siret : 433 681 525 00021 - n.ident TVA : FR 77 433 681 525 Sige social : 23, Chemin du Vieux Chne - Meylan (Isre)
Table # Table title Purpose of the table Table 1 Evolution of Selected SPINLINE 3 Software Life Cycle Documents This table identifies the key software life cycle documents for the following phases of
SPINLINE 3 evolution: Used in the original MC3 project platform software project Used in the 2000 SPINLINE 3 platform software upgrade project Used in the 2001 SPINLINE 3 platform software upgrade project Applicable to a future SPINLINE 3 platform software upgrade project Applicable to a future SPINLINE 3 plant-specific application software project Table 2 Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 Documents This table is a mapping of IEEE 1074-1995 software life cycle activities to the corresponding documents identified in Interim Staff Guide ISG-06 and to the Rolls-Royce licensing documents. This table attempts to harmonize two different views of what software documentation needs to be submitted to NRC and when the documents are due Table 3a Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content Guidance Table 3b Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content Guidance Table 3c Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content Guidance These tables map SPINLINE 3 documentation to the Software Quality Assurance Plan (SQAP) format and content guida nce in IEEE 730-1998, Section 4. The three tables provide maps for three distinctly different phases of SPINLINE 3 development: (1) the development of the original platform software in the mid-1990s, (2) future modifications of the generic platform software, and (3) future development of plant-specific application software.
Table 4a Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance Table 4b Mapping SPINLINE 3 Platform SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance Table 4c Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance These tables map SPINLINE 3 documentation to the Software Configuration Management Plan (SCMP) format and content guidance in IEEE 828-1998, Section 4. The three tables provide maps for three distinctly different phases of SPINLINE 3 development: (1) the development of the original platform software in the mid-1990s, (2) future modifications of the generic platform software, and (3) future development of plant-specific application software.
Table 5a Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content Guidance Table 5b Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content Guidance These tables map SPINLINE 3 documentation to the Software Verification & Validation Plan (SVVP) format and content guidance in IEEE 1012-1998, Section 7. The three tables provide maps for three distinctly different phases of SPINLINE 3 development: (1) the development
[m] Em3 Rol Is-Royce Rolls-Royce Civil Nuclear SAS 23, Chemin du Vieux Ch@ne, 38246 Meylan Cedex - France Tel: +33 (0)4 76 61 15 00 www.rolls-royce.com These updated tables provide additional details on how the content of the three new documents submitted herewith relate to the software plan content guidance in IEEE 730-1 998, IEEE 828-1 998, and IEEE 1012-1 998, and the software life cycle activities identified in IEEE 1074-1 995. As committed by Rolls-Royce, these updated tables will be included in the next edition of the SPINLINE 3 Licensing Topical Report (LTR), which is scheduled to be issued by January 31,201 1. All documents are submitted electronically. Rolls-Royce requests that the proprietary documents be withheld from public disclosure.
In accordance with 10 CFR 2.390, "Public inspections, exemptions, requests for withholding", an affidavit is enclosed identifying the specific portions of the above documents that are proprietary and the basis for making that determination. As noted in IN 2009-07, in instances in which a nonproprietary version would be of no value to the public because of the extent of the proprietary information, the agency does not expect a nonproprietary version to be submitted.
As identified in the following table, only proprietary versions of many documents are being submitted. Best regards, A Jean-Pierre Burel Deputy Technical Director Rolls-Royce Civil Nuclear SAS Rolls-Royce Civil Nuclear SAS Societe par actions simplifiee au capital de 1 040 000 Euros - rcs Grenoble 433 681 525 -code NAF 3320D Siret :433 681 525 00021 - n.identTVA
- FR 77 433 681 525 Siege social
- 23, Chemin du Vieux ChCne - Meylan (Isere)
App SW Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project Applicable to future SPINLINE 3 plant-specific application software Rolls-Royce Civil Nuclear SAS Quality Manual (former SES department Quality Assurance
Manual)8 303 186 A/B/C/D/E/F8 303 186 G8 303 186 H8 303 186 P8 303 186 PSoftware Quality Plan (SQP) - MC38 303 429 A/B/C/D/E8 303 429 E8 303 429 ENot applicableNot applicableSoftware Modification Quality PlanNot applicableNot applicable1 208 686 A1 208 686 BNot applicableSoftware Quality Plan - SCADE Operator LibraryNot applicable1 208 356 A1 208 356 A1 208 356 CNot applicable SPINLINE 3 Software Quality Assurance Plan -
SQAPNot applicableNot applicableNot applicableNot applicable8 307 208 B Software Qualit y Plan (SQP) - MC3 (This Plan + supporting instructions functioned as the SCMP)8 303 429 A/B/C/D/ENot applicableNot applicableNot applicableNot applicable Software Configuration Management Plan for
SPINLINE 3 Software Sub-assemblies Managed by CM ToolNot applicable1 208 878 A1 208 878 B1 208 878 DNot applicable SPINLINE 3 Software Configuration Management Plan - SCMPNot applicableNot applicableNot applicableNot applicable8 307 209 B Software Preliminary Design - Core System
Software 1 207 141 A/B/C/D/E1 207 141 F1 207 141 G1 207 141 HNot applicable Interface Specifications - Operational System
Software and Application Software1 207 110 A/B/C/D/E/F1 207 110 G1 207 110 H1 207 110 J1 207 110 J Comments Table 1. Evolution of Selected SPINLINE 3 Software Life Cycle Documents Corresponding Generic SPINLINE 3 Licensing Documents Available Upon Application Platform Software Rolls-Royce Document Title ISG-06 App B.3 Document Title ISG-06 App B.3 Item #ISG-06 Documents Expected Upon Application Quality Assurance Plan for
Digital Hardware and Software 1217aVendor Software CM Plan17bSoftware Design Specification App SW Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project Applicable to future SPINLINE 3 plant-specific application software Comments Table 1. Evolution of Selected SPINLINE 3 Software Life Cycle Documents Platform Software Rolls-Royce Document Title ISG-06 App B.3 Document Title ISG-06 App B.3 Item #Software Development Plan - MC31 207 102 ANot applicableNot applicableNot applicableNot applicableSoftware Development Plan (SDP) - 2000 changesNot applicable1 208 645 ANot applicableNot applicableNot applicable Software Development Plan (SDP) - 2001 changesNot applicableNot applicable1 208 908 A Not applicableNot applicable Software Development Plan (SDP) - FutureNot applicableNot applicableNot applicableProject-specific SDPNot applicable
SPINLINE 3 Software Development Plan - SDPNot applicableNot applicableNot applicableNot applicable8 307 210 B17eSoftware Integration Plan17kSoftware Test Plan15System Requirements 17h Platform Software Requirements Specification14Safety Analysis17jSoftware Safety Plan 17l Software Tool Verification ProgramRequirements for Software Development Tools1 206 747 A/B/C1 206 747 C1 206 747 C1 206 747 E Not applicable Software Qualit y Plan (SQP) - MC3 (This Plan + SVTP and supporting instructions
functioned as the SVVP)8 303 429 A/B/C/D/E8 303 429 ENot applicableNot applicableNot applicable Software Validation Test Plan (SVTP) -
Operational System Software for Safety Class
Units1 207 146 A/B/C/D1 207 146 E1 207 146 F1 207 146 GNot applicable Software Modification Qualit y Plan (This Plan + SVTP and supporting instructions
functioned as the SVVP)Not applicableNot applicable1 208 686 A1 208 686 BNot applicable SPINLINE 3 Software Verification and Validation Plan - SVVPNot applicableNot applicableNot applicableNot applicable8 307 210 B1 207 204 D1 207 204 D1 207 228 F1 207 228 G1 207 204 ENot applicable Software Integration Test Plan and Report (SITR) -
SCC (Core System Software) 1 207 204 A/B/C Software Development Plan 17c1 207 108 JNot applicable SPINLINE 3 Safety of Processing Unit Software1 207 228 A/B/C/D/E Software Requirement Specification - Operational
System Software1 207 108 A/B/C/D/E/F1 207 108 G1 207 108 H Software Verification and
Validation Plan 17m1 207 228 HNot applicable App SW Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project Applicable to future SPINLINE 3 plant-specific application software Comments Table 1. Evolution of Selected SPINLINE 3 Software Life Cycle Documents Platform Software Rolls-Royce Document Title ISG-06 App B.3 Document Title ISG-06 App B.3 Item #General Processes for Software Development
[IL_PROC_GEN]1 208 079 A/B/C/D1 208 079 E1 208 079 ENot applicableNot applicable Content of 1 208 079 was
incorporated into and
replaced by later revisions of
8 303 350.
Control of software design (safety systems)
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Rules for Verification and Validation of Software
Components1 207 107 A/B/C1 207 107 C1 207 107 C1 207 107 DNot applicable Content of 1 207 107
incorporated into application
software V&V template 8 307
210 Software Configuration Management Process
[IL_Gest_Conf]1 207 875 A1 207 875 B1 207 875 C1 207 875 G1 207 875 G Software Guideline: Software Document
Evaluation Process [IL_Verif_Doc]1 207 947 B/C1 207 947 C1 207 947 C1 207 947 E1 207 947 E This document is scheduled
to be delivered to NRC in
February 201119V&V Reports Software Validation Test Report (SVTR) -
Operational System Software for Safety Class
Units1 207 232 A/B/C1 207 232 D1 207 232 E1 207 232 FNot applicable This color code means the document has been submitted to the NRC 18a Software Management
Implementing Procedures Corresponding Generic SPINLINE 3 Licensing Documents Available Within 12 Months of Requested Approval ISG-06 Documents Expected Within 12 Months of Requested Approval App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Rolls-Royce Civil Nuclear SAS Quality Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H8 303 186 P8 303 186 P Software Quality Plan (SQP) - MC3 8 303 429
A/B/C/D/E8 303 429 E8 303 429 ENot applicableNot applicableSoftware Modification Quality PlanNot applicableNot applicable1 208 686 A1 208 686 BNot applicable Software Quality Plan - SCADE Operator LibraryNot applicable1 208 356 A1 208 356 A1 208 356 CNot applicable SPINLINE 3 Software Quality Assurance Plan - SQAPNot applicableNot applicableNot applicableNot applicable8 307 208 BUASeveralLicensing Topical ReportNot applicableNot applicableNot applicable 3 008 503B,
§ 6.1 & Figure 6.2-1 3 008 503B, Figure 6.4-1Software Development Plan - MC31 207 102 ANot applicableNot applicableNot applicableNot applicable Software Development Plan (SDP) -
2000 changesNot applicable1 208 645 ANot applicableNot applicableNot applicable Software Development Plan (SDP) -
2001 changesNot applicableNot applicable1 208 908 A Not applicableNot applicable Software Development Plan (SDP) -
FutureNot applicableNot applicableNot applicable Project-specific SDP Not applicable SPINLINE 3 Software Development
Plan - SDPNot applicableNot applicableNot applicableNot applicable8 307 210 B 12 17c Identify Candidate SW Life
Cycle Models X The software life cycle
model selected by Rolls-
Royce is integrated with
SPINLINE 3 industrial processes.
The project model developed by Rolls-
Royce is integrated with
SPINLINE 3 industrial processes.
UA UA Quality Assurance Plan for Digital Hardware and Software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design Software Development Plan X Software Life Cycle Process Select Project Model IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents 8 303 429 E 1 208 686 AUA17cSoftware Development PlanIncluded in the applicable SDP1 207 102 A1 208 645 A1 208 908 A Project-specific SDP 8 307 211 BUASeveralLicensing Topical ReportNot applicableNot applicableNot applicable 3 008 503B,
§ 6.1 & Figure 6.2-1 3 008 503B, Figure 6.4-1 The alignment of softwar e activities to the software life cycle model is
discussed in the
SPINLINE 3 LTR §6 General Processes for Software
Development [IL_PROC_GEN]1 208 079 A/B/C/D1 208 079 E1 208 079 ENot applicableNot applicable Content of 1 208 079 was
incorporated into and
replaced by later
revisions of 8 303 350.
Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 LUA17cSoftware Development PlanIncluded in the applicable SDP1 207 102 A1 208 645 A1 208 908 A Project-specific SDP 8 307 211 BLater14 Quality Assurance Procedures
for Digital Hardware and
SoftwareResources management processNot applicableNot applicable8 303 696 A 8 303 696 E8 303 696 EUA17cSoftware Development PlanIncluded in the applicable SDP1 207 102 A1 208 645 A1 208 908 A Project-specific SDP 8 307 211 BLater14 Quality Assurance Procedures
for Digital Hardware and
Software SPINLINE 3 technical instruction:
Description of development
environments [IT_SL3_Env_Dev]1 207 105 A/B/C1 207 105 D1 207 105 D1 207 105 DNot applicableUA17cSoftware Development PlanIncluded in the applicable SDP1 207 102 A1 208 645 A1 208 908 A Project-specific SDP 8 307 211 B General Processes for Software
Development [IL_PROC_GEN]1 208 079 A/B/C/D1 208 079 E1 208 079 ENot applicableNot applicable Content of 1 208 079 was
incorporated into and
replaced by later
revisions of 8 303 350.
Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Non Safety Software Design Process
[PRO_Concept_log_NC]Not applicableNot applicableNot applicable8 307 214 A8 307 214 A Software Guideline: Software
Management Process [IL_Gest_Proj]Not applicable1 208 055 B1 208 055 B1 208 055 E1 208 055 ELater18a Software Management
Implementing ProceduresLater18a Software Management
Implementing ProceduresEstablish Project EnvironmentXXAllocate Project ResourcesXXXXXX X Project Initiation ProcessUA12 Quality Assurance Plan for Digital Hardware and Software Included in the applicable SQAP 8 303 429
A/B/C/D/E X Map Activities to SLC Model Project Management ProcessesPlan Project ManagementXX8 303 429 E1 208 686 B8 307 208 B App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Rolls-Royce Civil Nuclear SAS Quality Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H 8 303 186 P, 5.3, 7.0, 8.5.3 8 303 186 P, 5.3, 7.0, 8.5.3 Risk analysis is included in applicable
Software Development Plan 1 207 102 A,
§ 8 1 208 645 A,
§ 8 1 208 908 A,
§ 8 Project-specific SDP 8 307 211 B, § 7 and more in the other application SW Plans Perform Contingency PlanningXXXXXXXUA17c Software Development Plan Contingency planning is part of risk
management See risk analysis above See risk analysis above See risk analysis above See risk analysis above See risk analysis aboveUA12 Quality Assurance Plan for
Digital Hardware and SoftwareUA17cSoftware Development Plan General Processes for Software
Development [IL_PROC_GEN]1 208 079 A/B/C/D1 208 079 E1 208 079 ENot applicableNot applicable Content of 1 208 079 was
incorporated into and
replaced by later
revisions of 8 303 350.
Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Non Safety Software Design Process
[PRO_Concept_log_NC]Not applicableNot applicableNot applicable8 307 214 A8 307 214 A Retain RecordsXXXXXXXUA12 Quality Assurance Plan for
Digital Hardware and Software Apply the process defined in the
applicable SQAP above 8 303 429
A/B/C/D/E 8 303 429 E,
§ 1.2.4 & 10.3 1 208 686 A 1 208 686 B,
§ 10 & 11.3 8 307 208 B,
§ 1.4 and 12UA12 Quality Assurance Plan for
Digital Hardware and Software Rolls-Royce Civil Nuclear SAS Quality
Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H 8 303 186 P,
§ 8.3 8 303 186 P,
§ 8.3Non conformity8 303 202 E8 303 202 F8 303 202 G8 303 202 M8 303 202 MClassified nonconformitiesNot applicableNot applicableNot applicable8 307 152 B 8 307 152 B Software Project Risk Management Plan 17g UA XXLater14 Quality Assurance Procedures
for Digital Hardware and
Software XXXX Analyze Risks There is no separate
Risk Management Plan.
Risk management (analysis and mitigation
planning) is integrated
with basic quality
management system
processes Manage the Project XXXXX X X Apply the processes defined in the
applicable SQAP, SDP and supporting
procedures X Project Monitoring and Control Process See SQAP and SDP listed above See SQAP and SDP listed above See SQAP and SDP listed above See SQAP and SDP listed above Software Management
Implementing Procedures Implement Problem Reporting
SystemXXXXXX See SQAP and SDP listed above 18a X Later App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Rolls-Royce Civil Nuclear SAS Quality Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H8 303 186 P8 303 186 P Software Quality Plan (SQP) - MC3 8 303 429
A/B/C/D/E8 303 429 E8 303 429 ENot applicableNot applicableSoftware Modification Quality PlanNot applicableNot applicable1 208 686 A1 208 686 BNot applicable Software Quality Plan - SCADE Operator LibraryNot applicable1 208 356 A1 208 356 A1 208 356 CNot applicable SPINLINE 3 Software Quality
Assurance Plan - SQAPNot applicableNot applicableNot applicableNot applicable8 307 208 B This document is a plan
template that will be
completed for each plant-
specific system.UA12 Quality Assurance Plan for
Digital Hardware and Software Rolls-Royce Civil Nuclear SAS Quality
Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H 8 303 186 P,
§ 8.2 8 303 186 P,
§ 8.2Later18a Software Management
Implementing Procedures Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Manage Software Quality XXXXXXXLater14 Quality Assurance Procedures
for Digital Hardware and
SoftwareSoftware Quality Control Process8 303 634 A8 303 634 A8 303 634 A8 303 634 E8 303 634 EXXXXXXXUA12 Quality Assurance Plan for
Digital Hardware and Software Rolls-Royce Civil Nuclear SAS Quality
Manual (former SES department
Quality Assurance Manual)8 303 186 A/B/C/D8 303 186 G8 303 186 H 8 303 186 P,
§ 8.5 8 303 186 P,
§ 8.5 XXXXXXXLater14 Quality Assurance Procedures
for Digital Hardware and
SoftwareContinuous improvement processNot applicableNot applicable8 303 695 A 8 303 695 E 8 303 695 E Software Quality Management Process Identify Quality Improvement
Needs X 12 Quality Assurance Plan for
Digital Hardware and Software Plan Software Quality
Management XXUADefine MetricsXX App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 DocumentsIdentify Ideas or NeedsXFormulate Potential ApproachesXX Conduct Feasibility StudiesXX Plan System Transition (if applicable)
XX Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Refine and Finalize the Idea or
Need X Non Safety Software Design Process
[PRO_Concept_log_NC]Not applicableNot applicableNot applicable8 307 214 B8 307 214 BAnalyze FunctionsXX General Processes for Software
Development [IL_PROC_GEN]1 208 079 A/B/C/D1 208 079 E1 208 079 ENot applicableNot applicableDevelop System ArchitectureXX Safety software design process
[PRO_Concept_log_C] (formerly
Software Design Control)Not applicableNot applicableNot applicable8 303 350 L8 303 350 L Non safety software design process
[PRO_Concept_log_NC]Not applicableNot applicableNot applicable8 307 214 B8 307 214 BUA18 Requirements Traceability
MatrixLicensing Topical ReportNot applicableNot applicableNot applicable 3 008 503B,
§ 3 Plant-specific RTMUA17bSoftware Design Specification Software Preliminary Design - Core
System Software 1 207 141
A/B/C/D/E1 207 141 F1 207 141 G1 207 141 HNot applicableUA17h Platform Software
Requirements Specification Software Requirement Specification -
Operational System Software 1 207 108 A/B/
C/D/E/F/1 207 108 G1 207 108 H1 207 108 JNot applicableUA17i Application Software
Requirements Specification None. This is a plant-specific
document for an application to be built
on the generic SPINLINE 3 platform.Not applicableNot applicableNot applicableNot applicable Plant-specific specificationDefine Interface RequirementsXXXUA17bSoftware Design Specification Interface Specifications - Operational
System Software and Application
Software 1 207 110 A/B/C/D/E/F1 207 110 G1 207 110 H1 207 110 J1 207 110 J Software Management
Implementing Procedures Requirements Process Pre-Development Processes X These activities primarily apply to a plant-specific
system General Processes for Software
Development [IL_PROC_GEN]Later18a Software Management
Implementing Procedures 1 208 079 A/B/C/D 18a Preliminary software
requirements typically are
established by the
licensee.X Later Development Processes System Allocation Process Concept Exploration Process Decompose System Requirements X Define and Develop Software
Requirements X X The concept exploration
process may be
performed by the licensee
in connection with their
development of the bid
specification for a new or
replacement digital safety
I&C system. If requested, Rolls-Royce can assist
the licensee in this
process.1 208 079 E1 208 079 ENot applicableNot applicable App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Software Integration Test Plan and Report (SITR) - SCC (Core System
Software)1 207 204 A/BC1 207 204 D1 207 204 D1 207 204 ENot applicable SPINLINE 3 Software Verification and
Validation Plan - SVVPNot applicableNot applicableNot applicableNot applicable8 307 210BPerform Architectural DesignXXDesign Data Base (if applicable)XXDesign InterfacesXXSelect or Develop AlgorithmsXX Safety Software Design Process
[PRO_Concept_log_C]Not applicableNot applicableNot applicable8 303 350 L8 303 350 LPerform Detailed DesignX Non Safety Software Design Process
[PRO_Concept_log_NC]Not applicableNot applicableNot applicable8 307 214 B8 307 214 BCreate Test DataXXNone Test data requirements are
established in the respective Test
Plans See Test Plans, below See Test Plans, below See Test Plans, below See Test Plans, below See Test Plans, belowCreate SourceXXXAudit8Software Code Listings SPINLINE 3 Technical Instruction:
Description of Development
Environments [IT_SL3_Env_Dev]1 207 105 A/B/C/D1 207 105 D1 207 105 D1 207 105 D1 207 105 DGenerate Object CodeXXXAudit8Software Code Listings Software Manufacturing File -
Programming Instruction document 1 207 287 A1 207 287 A1 207 287 B1 207 287 CNot applicable Create Operating
DocumentationXXXNone System Operations and Maintenance
PlanNot applicableNot applicableNot applicableNot applicable8 307 244 A This document is a plan
template that will be
completed for each plant-
specific system.
Software Integration Test Plan and
Report (SITR) - SCC (Core System
Software)1 207 204 A/B/C1 207 204 D1 207 204 D1 207 204 ENot applicable System Integration and Factory Test
Plan Not applicableNot applicableNot applicableNot applicable8 307 245 A This document is a plan
template that will be
completed for each plant-
specific system.Later18a Software management
Implementing ProceduresPlan IntegrationXX 17e Implementation Process A standard process
guides the design effort
for a modification to the
generic platform software
or for a plant-specific
system.General Processes for Software
Development [IL_PROC_GEN]
1 208 079 A/B/C/D Software Integration PlanUA17eSoftware Integration Plan UA Design Process Prioritize and Integrate Software Requirements X XX1 208 079 E1 208 079 ENot applicableNot applicable App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 DocumentsPerform IntegrationXUA16System Test Plan Apply the process defined in the Software Integration Test Plan above.
Produce the "Report" part of the SITR. See SITR aboveSee SITR aboveSee SITR aboveSee SITR aboveNot applicable System Integration and Factory Test
Plan (Generic)Not applicableNot applicableNot applicableNot applicable8 307 245 A System Installation and Site Test Plan (Generic)Not applicableNot applicableNot applicableNot applicable8 307 243 ALater12 Installation Test Plans and
Procedures System Installation and Site Test Plan (Generic)Not applicableNot applicableNot applicableNot applicable8 307 243 ADistribute SoftwareXXXLater18a Software Management
Implementing ProceduresInstall SoftwareXXXLater12 Installation Test Plans and
Procedures Accept Software in Operational
EnvironmentLater12 Installation Test Plans and
ProceduresSystem Installation and Site Test PlanNot applicableNot applicableNot applicableNot applicable8 307 243 A Licensee makes the
decision to accept the
system following
successful completion of
site acceptance test or
other criteria established
in the contract for the
system.Operate the System None System Operations and Maintenance
PlanNot applicableNot applicableNot applicableNot applicable8 307 244 A This document is a plan
template that will be
completed for each plant-
specific system. The
licensee operates the
systemOn-site activities processNot applicableNot applicableNot applicableNot applicable8 303 659 E Presentation and organization of On-site activities groupNot applicableNot applicableNot applicableNot applicable8 303 373 N On site Maintenance, Preparation, Follow-upNot applicableNot applicableNot applicableNot applicable8 303 382 K 14 Post-Development Processes X UA Plan Installation Later Provide Tech. Asst. & Consult X Quality Assurance Procedures
for Digital Hardware and
Software Software Installation Plan Software manufacturing process distributes
executable code to
EEPROMS that are
installed on the UC25+
CPU boards Not applicable 17d Operation and Support Process Installation Process The licensee may contract Rolls-Royce for
technical assistance
and/or consulting These documents are plan templates that will be
completed for each plant-
specific system.
Software Manufacturing File -
Programming Instruction document (one document per software)1 207 287 A1 207 287 A1 207 287 B1 207 287 C App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Establishment of on-site activities reportsNot applicableNot applicableNot applicableNot applicable8 303 384 LOn site non conformitiesNot applicableNot applicableNot applicableNot applicable8 303 647 G Reapply Software Life CycleNoneSoftware Modification Quality PlanNot applicableNot applicable1 208 686 A1 208 686 BNot applicable Notify User None The licensee will make
the decision to initiate
replacement and
retirement of a system.
Conduct Parallel Operations (if
applicable) None Rolls-Royce has
structured projects with
parallel operation of the
original system and the
new digital system. This i s captured in the SDP.
Retire System None The licensee will make
the decision to retire a
system. Retirement Process Maintenance Process Rolls-Royce maintains a log of customer support
activities.
Later Maintain Support Request Log Quality Assurance Procedures
for Digital Hardware and
Software 14 App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Software Quality Plan (SQP) - MC3 (This Plan + SITR, SVTP and
supporting instructions functioned as
the SVVP)8 303 429
A/B/C/D/E 8 303 429 E,
§ 5 & 9.1.6 8 303 429 E,
§ 5 & 9.1.6Not applicableNot applicable The MC3 SQP, 8 303
429 E, served the
function of the SVVP
where indicated.
Software Modification Quality Plan (This Plan + SITR, SVTP and
supporting instructions functioned as
the SVVP)Not applicableNot applicable1 208 686 A1 208 686 BNot applicable The SMQP, 1 208 686 A, served the function of the
SVVP where indicated.
SPINLINE 3 Software Verification and Validation Plan - SVVPNot applicableNot applicableNot applicableNot applicable8 307 210 B This document is a plan
template that will be
completed for each plant-
specific system.Later18a Software Management
Implementing Procedures Rules for Verification & Validation of
software components1 207 107 A/B/C1 207 107 C1 207 107 C1 207 107 DNot applicable Execute V&V Tasks XXXXXXXLater18a Software Management
Implementing Procedures Apply processes defined in the
applicable V&V Plan and proceduresSee SVVP aboveSee SVVP aboveSee SVVP aboveSee SVVP aboveSee SVVP above Collect and Analyze Metric Data XXXXLater18a Software Management
Implementing Procedures Apply processes defined in the
applicable V&V Plan and proceduresSee SVVP aboveSee SVVP aboveSee SVVP aboveSee SVVP aboveSee SVVP above UA 17e, 17k Software Integration Plan, Software Test Plan Software Integration Test Plan and
Report (SITR) - SCC (Core System
Software)1 207 204 A/B/C1 207 204 D1 207 204 D1 207 204 ENot applicable UA 17e, 17k Software Integration Plan, Software Test Plan Software Validation Test Plan (SVTP)
-Operational System Software for
Safety Class Units1 207 146 A/B/C1 207 146 E1 207 146 F1 207 146 GNot applicableDevelop Test RequirementsXXXAudit6 Test requirements included in
Test Plan Test requirements included in Test
Plan See Test Plan for test requirements See Test Plan for test requirements See Test Plan for test requirements See Test Plan for test requirements See Test Plan for test requirementsLater19V&V Reports Software Validation Test Report (SVTR) - Operational System
Software for Safety Class Units1 207 232 A/B/C1 207 232 D1 207 232 E1 207 232 FNot applicableAudit6 Individual Completed Test
Procedures & Reports Tests and test reports as required by
the applicable Test Plan See Test Plan for list of test reports See Test Plan for list of test reports See Test Plan for list of test reports See Test Plan for list of test reports See Test Plan for list of test reports UA X XX XX Execute the Tests Plan Testing X Verification and Validation Process 17m Software V&V Plan and Procedures Integral ProcessesPlan Verification and ValidationX App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents Software Quality Plan (SQP) - MC3 (This Plan + supporting instructions
functioned as the SCMP) 8 303 429
A/B/C/D/E 8 303 429 E,
§ 5 & 9.1.6 8 303 429 E,
§ 5 & 9.1.6Not applicableNot applicable Software Configuration Management
Plan for SPINLINE 3 Software Sub-assemblies Managed by CM ToolNot applicable1 208 878 A1 208 878 B1 208 878 DNot applicable SPINLINE 3 Software Configuration
Management Plan - SCMPNot applicableNot applicableNot applicableNot applicable8 307 209 B This document is a plan
template that will be
completed for each plant-
specific system.Software Maintenance and Changes1 206 624 ANot applicableNot applicableNot applicableNot applicable Software Configuration Management Process [IL_Gest_Conf]1 207 875 A1 207 875 B1 207 875 C1 207 875 G1 207 875 G Perform Configuration
Identification XXXXXXXLater10 Final System Configuration
Documentation Apply processes defined in the
applicable CM Plan and procedures 8 303 429
A/B/C/D/E 8 303 429 E,
§ 7.2, 7.3, 7.4 8 303 429 E,
§ 7.2, 7.3, 7.4 1 208 878 D,
§ 2.2, 2.5 & 3.1 8 307 209 B,
§ 4.1 & 5.2 The MC3 SQP, 8 303
429 E, served the
function of the SCMP
where indicated.
Perform Configuration Control XXXXXXXLater10 Final System Configuration
Documentation Apply processes defined in the
applicable CM Plan and procedures 8 303 429
A/B/C/D/E 8 303 429 E,
§ 8 8 303 429 E,
§ 8 1 208 878 D,
§ 2.3, 2.4, 2.7, 2.9, 3.3, 3.4 & 3.5 8 307 209 B,
§ 4.2, 5.3 & 6.3 The MC3 SQP, 8 303
429 E, served the
function of the SCMP
where indicated.
Perform Status Accounting XXXXXXXLater10 Final System Configuration
Documentation Apply processes defined in the
applicable CM Plan and procedures 8 303 429
A/B/C/D/E 8 303 429 E,
§ 10.3 8 303 429 E,
§ 10.3 1 208 878 D,
§ 2.8 8 307 209 B,
§ 4.3, 5.4 & 6.3.4 The MC3 SQP, 8 303
429 E, served the
function of the SCMP
where indicated.
18a UAPlan Configuration ManagementXX Software Management
Implementing Procedures Later Software Configuration Management Process Vendor Software CM Plan 17a App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 Documents 8 303 429 A/B/C/D/E 8 303 429 E,
§ 6 8 303 429 E,
§ 6Not applicableNot applicableNot applicableNot applicable1 208 686 A 1 208 686 B,
§ 4 8 307 208 B,
§ 4 Documents and reference files
management [Gest_Doc_Col_Ref]8 303 638 A8 303 638 A8 303 638 A8 303 638 B8 303 638 B Software Guideline: Software
Document Evaluation Process
[IL_Verif_Doc]1 207 947 B/C1 207 947 C1 207 947 C1 207 947 E1 207 947 E Implement Documentation XXXXXXX UA, Later and Audit Many Apply documentation processes
defined in the applicable SQAP and
other Plans identified above.
See Plan Documentation above See Plan Documentation above See Plan Documentation above See Plan Documentation above See Plan Documentation above Produce and Distribute
Documentation XXXXXXX UA, Later and Audit Many Apply documentation processes
defined in the applicable SQAP and
other Plans identified above.
See Plan Documentation above See Plan Documentation above See Plan Documentation above See Plan Documentation above See Plan Documentation above Later UAPlan DocumentationXX Documentation Development Process 12 14 Included in SQAP and other Plans identified above Quality Assurance Plan for
Digital Hardware and Software Quality Assurance Procedures for Digital Hardware and
Software App S W Used in original MC3 project platform software project Used in 2000 SPINLINE 3 platform SW upgrade project Used in 2001 SPINLINE 3 platform SW upgrade project Applicable to a future SPINLINE 3 platform SW upgrade project A pplicable to future SPINLINE 3 plant-specific application software Alignment to Rolls-Royce Documents Rolls-Royce Document Title ISG-06 Document TitleDoc Nr.Platform SoftwareUA, Later or Audit *SpecificationPreliminary Design IEEE 1074-1995 Software Life Cycle Activities SPINLINE 3 Life Cycle Phases Comments Table 2. Alignment of IEEE 1074-1995 Activities, ISG-06 Tier 3 Document Guidance, and SPINLINE 3 DocumentsValidationDetailed DesignCodingUnit TestIntegration Alignment to ISG-06 DocumentsUA12 Quality Assurance Plan for Digital Hardware and Software Rolls-Royce Civil Nuclear SAS Quality
Manual [PQM]8 303 186 A/B/C/D8 303 186 G8 303 186 H 8 303 186 P,
§ 6.2.2 8 303 186 P,
§ 6.2.2Training New Team Members1 207 104 A1 207 104 A1 207 104 ANot applicableNot applicableTraining of personnel8 303 3218 303 321 E8 303 321 E8 303 321 J8 303 321 J Training of personnel for on-site activities8 303 3868 303 386 F8 303 386 G8 303 386 J8 303 386 JCustomer training processNo informationNo information8 303 706 A8 303 706 D8 303 706 D Software Guideline: Software V&V Team Training Plan
[IL_Plan_Form_VV]1 208 210 B1 208 210 B1 208 210 B1 208 210 C1 208 210 CSystem Training Plan Not applicableNot applicableNot applicableNot applicable8 307 242 A This document is a plan
template that will be
completed for each plant-
specific system.
Develop Training Materials XXXXX None Apply processes defined in the
applicable Training PlanSee aboveSee aboveSee aboveSee aboveSee above Validate the Training Program XXXXX None Apply processes defined in the
applicable Training PlanSee aboveSee aboveSee aboveSee aboveSee above Implement the Training Program XXXXXXX None Apply processes defined in the
applicable Training PlanSee aboveSee aboveSee aboveSee aboveSee aboveUA=Documents Expected Upon Application This color code means the document has been submitted to the NRCLater=Documents Expected Within 12 Months of Requested ApprovalAudit=Documents Available for Audit XX Plan the Training Program Training Process X 14 Quality Assurance Procedures
for Digital Hardware and
Software A Training Center and
training materials exist at
the Rolls-Royce Meylan, France facility.
Later Training for Rolls-Royce
and EDF staff are in
place. Training for U.S.
licensee staff will be
planned in connection
with each plant-specific
project.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotesSQP MC38 303 429 E1Purpose, Scope and ResponsibilitiesThe MC3 SQP + the following software instructions also perform the functions of the SCMP and SVVP: (1)
1 207 875 A, "Software Configuration
Management Process"
[IL_Gest_Conf], and (2) 1 207 107
A/B/C, "Rules for Verification and
Validation of Software Components."
Later revisions of these instructions
are applicable to current CM and V&V
processes.1Project OverviewThis SDP supports the SQP MC3 with additional guidance for the MC3
project (for the original creation of
SPINLINE 3
). Some of the topics addressed in this SDP align with the
SQAP content guidance in IEEE 730-
1998.2Description of the Project2Reference Documents and Applicable Documents9.3Rules4.33Management:
This section shall describe organization, tasks, and responsibilities See 3.1 - 3.3 below4.3.13.1Organization:
This paragraph shall depict the organizational structure that influences and controls the quality of the software. This shall include a description of each major
element of the organization together with the delegated
responsibilities. Organizational dependence or independence
of the elements responsible for SQA from those responsible
for software development and use shall be clearly described
or depictedSQP MC38 303 429 E4Specific Organizational Structure Associated With Software Project Refer to organization chart 8 303 429 E SQP MC3 Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation 1 207 102 A SDP MC3 Purpose: This section shall delineate the specific purpose and scope of the particular SQAP. It shall list the name(s) of
the software items covered by the SQAP and the intended
use of the software. It shall state the portion of the software
life cycle covered by the SQAP for each software item
specified.
1 4.14.2Referenced documents:
This section shall provide a complete list of documents referenced elsewhere in the text of the SQAP 2
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation5Quality Control in the Design and Production of Software9.1Methods AppliedSDP MC31 207 102 A2Description of the Project4.3Duties of Members of the Software Team7.4 & 8Procedures for identification and entry into configuration; Management of changes to software and associated
documentation Software Project Manager is
responsible for CMSQP MC38 303 429 E6Project Documentation Guide to writing documentation1 207 139Referenced in SQP MC3 §6 Document and data control procedure Included in 8 303 186Referenced in SQP MC3 §6.36.1Project Management DocumentsRefer to table of document responsibilities (writing, checking, approval)6.2Documents specific to each software item embedded on a unit Refer to table of document
responsibilities (writing, checking, approval)Document drafting rules1 207 103Referenced in SQP MC3 §9.34.4.24.2Minimum documentation requirements
- To ensure that the implementation of the software satisfies requirements, the documentation in 4.4.2.1 through 4.4.2.6 is required as a
minimumSQP MC38 303 429 E6.1Project Management Documents 4 4.3.2 4.3.34.4Documentation 8 303 429 E 8 303 429 E 8 303 429 E SQP MC3 SQP MC34.4.14.1Purpose:
This section shall perform the following functions:
a) Identify the documentation governing the development, verification and validation, use, and maintenance of the
software.
b) State how the documents are to be checked for adequacy.
This shall include the criteria and the identification of the
review or audit by which the adequacy of each document
shall be confirmed, with reference to Section 6 of the SQAP.
SQP MC33.3Responsibilities:
This paragraph shall identify the specific organizational elements responsible for each task.3.2Tasks:
This paragraph shall describe a) That portion of the software life cycle covered by the
SQAP; b) The tasks to be performed with special emphasis on
software quality assurance activities; and
c) The relationships between these tasks and the planned
major checkpoints.
The sequence of the tasks shall be indicated.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation6.2Software Specifications (SRS)9.1.1Specifications6.2Preliminary Software Design (PSD), Detailed Software Design (DSD), Preliminary & Detailed Software
Design (PDSD), Software component
description file (BF or SAF), Software
Production File (SPF), Software
Validation Test Analysis (SVTP),
Software Validation Test Reports (SVTR)9.1.2Preliminary Design and Detailed Design Interface Specifications -
Operational System Software and Application Software1 207 110 JNot referenced in SQP MC3, but applicable.SQP MC38 303 429 E Software Design Description (SDD):
The SDD shall depict how the software will be structured to satisfy the
requirements in the SRS. The SDD shall describe the
components and subcomponents of the software design, including databases and internal interfaces. The SDD shall
be prepared first as the Preliminary SDD (also referred to as
the top-level SDD) and shall be subsequently expanded to
produce the Detailed SDD 4.4.2.24.2.24.4.2.14.2.1Software Requirements Specification (SRS
): The SRS shall clearly and precisely describe each of the essential requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces.
Each requirement shall be defined such that its achievement
is capable of being objectively verified and validated by a
prescribed method (e.g., inspection, analysis, demonstration, or test)8 303 429 E SQP MC3 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation5Quality Control in the Design and Production of Software9.1.6Software ValidationSVTP1 207 146 GSoftware Validation Test Plan (SVTP) -
Operational System Software for Safety Class Units SVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.34.4.2.44.2.4Software Verification and Validation Report (SVVR):
The SVVR shall describe the results of the execution of the
SVVP.SVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System
Software for Safety Class Units SVTR is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 4.4.2.54.2.5User documentation:
User documentation (e.g., manual, guide) shall specify and describe the required data and
control inputs, input sequences, options, program limitations, and other activities or items necessary for successful
execution of the software. All error messages shall be
identified and corrective actions shall be described. A method
of describing user identified errors or problems to the
developer or the owner of the software shall be described.
(Embedded software that has no direct user interaction has
no need for user documentation and is therefore exempted
from this requirement.)SQP MC38 303 429 E6.2Software User Manual (SUM) 8 303 429 E SQP MC3 Software Verification and Validation Plan (SVVP):
The SVVP shall identify and describe the methods (e.g.,
inspection, analysis, demonstration, or test) to be used to
a1) Verify that the requirements in the SRS have been
approved by an appropriate authority;
a2) Verify that the requirements in the SRS are implemented
in the design expressed in the SDD; and
a3) Verify that the design expressed in the SDD is
implemented in the code.
b) Validate that the code, when executed, complies with the
requirements expressed in the SRS4.4.2.34.2.3 There is no separate SVVP. The SQP
MC3, SVTP and subordinate V&V
guidance documents perform the
function of the SVVP.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7Configuration Management 8Management of Changes to Software and Associated Documentation Software Configuration Management Process
[IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicableUpgrade management8 303 197Referenced in SQP MC3 §8 Software maintenance and changes1 206 624Referenced in SQP MC3 §8SDP MC38 303 429 EDesign control8 303 334Referenced in SQP MC3 §9.3 General process for Software Development [IL_PROC_GEN]
1 208 079 A/B/C/D Not referenced in MC3 SQP, but applicable Development of safety class software1 206 076Referenced in SQP MC3 §9.3 Development of standard software1 206 077Referenced in SQP MC3 §9.3 Software Quality Assurance Handbook8 303 670Referenced in SQP MC3 §9.35Quality Control in the Design and Production of Software9Methods, Tools and Rules SQP MC3 SQP MC3 8 303 429 E 8 303 429 ECM is addressed in the MC3 SQP and supporting documents. There is no separate SCMP4.4.34.3Other:
Other documentation may include the following:
a) Software Development Plan;
b) Standards and Procedures Manual;
c) Software Project Management Plan;
d) Software Maintenance Manual4.2.6Software Configuration Management Plan (SCMP):
The SCMP shall document methods to be used for identifying
software items, controlling and implementing changes, and
recording and reporting change implementation status 4.4.2.65Standards, practices, conventions, and metrics 4.5 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation2.1Reference Documents5.1Procedure used for software development Refer to the diagram for the software development life cycle5.2Development process for software incorporating HMIs Refer to diagram showing the
development cycle for software with
HMI9.3Rules5.3Description of phases
- 1) Specification phase
- 2) Preliminary Design Phase
- 3) Detailed design phase
- 4) Production phase (coding and unit
tests)
- 5) Integration phase
- 6) Validation phase
- 7) System tests For each phase, identifies phase
inputs, phase outputs and conditions
for moving to the next phase10.3Quality Monitoring Documentation4.66Reviews and auditsSQP MC38 303 429 E10Quality Assurance Measures SES Department Quality Assurance Manual 8 303 1868.2.2Internal auditsReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]SQP MC38 303 429 E10.1PrinciplesSQP MC38 303 429 E 8 303 429 E SQP MC3 Purpose: This section shall a) Identify the standards, practices, conventions, and metrics to be applied;
b) State how compliance with these items is to be monitored
and assured.
4.5.14.6.16.1Purpose:
This section shall a) Define the technical and managerial reviews and audits to be conducted;
b) State how the reviews and audits are to be accomplished;
c) State what further actions are required and how they are to
be implemented and verified.
5.15.2Content:
The subjects covered shall include the basic technical, design, and programming activities involved, such as documentation, variable and module naming, programming, inspection, and testing 4.5.2 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation10.2Quality ActionsQuality Actions, including:
a) End of phase reviews b) Document design reviews, including:
- Software specification design review
- Software preliminary design
document review
- Software detailed design document
review
- Software validation test
documentation design review
c) Document peer review
d) Audits10.3Quality Monitoring Documentation4.6.36.3Other:
Other reviews and audits may include the user documentation review (UDR). This review is held to evaluate
the adequacy (e.g., completeness, clarity, correctness, and
usability) of user documentation.SQP MC38 303 429 E10.2.3Documentation Peer Review9.1.4Unit tests on software components9.1.5Software integration tests SES Department Quality Assurance Manual 8 303 1868.3Control of nonconforming productReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]SQP MC38 303 429 E1.2.5Procedure in the event of failure to apply the SQP Software maintenance and changes1 206 624Referenced in SQP MC3 §8SQP MC38 303 429 E9Methods, Tools and Rules List of tools and libraries used by software1 207 286Referenced in SQP MC3 §9.2.24.99Tools, techniques, and methodologies:
This section shall identify the special software tools, techniques, and
methodologies that support SQA, state their purposes, and
describe their use 4.8 4.7 8 4.6.2 Problem reporting and corrective action:
This section shall a) Describe the practices and procedures to be followed for
reporting, tracking, and resolving problems identified in both
software items and the software development and
maintenance process;
b) State the specific organizational responsibilities concerned
with their implementation.7Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall
state the methods to be used 6.2 SQP MC3SQP MC38 303 429 E 8 303 429 E Minimum requirements:
a) Software Requirements Review (SRR)
b) Preliminary Design Review (PDR)
c) Critical Design Review (CDR)
d) Software Verification and Validation Plan Review (SVVPR)
e) Functional audit
f) Physical audit
g) In-process audits
h Managerial reviews
i) Software Configuration Management Plan Review (SCMPR) j) Post-mortem review IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSQP MC38 303 429 E9.1.3Coding Software Instructions Handbook8 303 670Referenced in SQP MC3 §2.1Rules for programming in C1 207 106Referenced in SQP MC3 §9.3 Defensive programming application rules1 207 185Referenced in SQP MC3 §9.3 Development environment organization1 207 105Referenced in SQP MC3 §9.3 Basic and system access function management1 207 195Referenced in SQP MC3 §9.34.1111Media control:
This section shall state the methods and facilities to be used to a) Identify the media for each computer product and the
documentation required to store the media, including the
copy and restore process; and
b) Protect computer program physical media from
unauthorized access or inadvertent damage or degradation
during all phases of the software life cycle.
This may be provided as a part of the SCMP. If so, an
appropriate reference shall be made thereto.SQP MC38 303 429 E11Reproduction, Protection, Delivery4.1212Supplier control:
This section shall state the provisions for assuring that software provided by suppliers meets
established requirements. In addition, this section shall state
the methods that will be used to assure that the software
supplier receives adequate and complete requirements. For
previously developed software, this section shall state the
methods to be used to assure the suitability of the product for
use with the software items covered by the SQAP. For
software that is to be developed, the supplier shall be
required to prepare and implement an SQAP in accordance
with this standard. This section shall also state the methods
to be employed to assure that the developers comply with the
requirements of this standard.
SES Department Quality Assurance Manual 8 303 1867.4PurchasingReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]
Code control:
This section shall define the methods and facilities used to maintain, store, secure, and document
controlled versions of the identified software during all
phases of the software life cycle. This may be implemented in
conjunction with a computer program library. This may be
provided as a part of the SCMP. If so, an appropriate
reference shall be made thereto 10 4.1 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation SES Department Quality Assurance Manual 8 303 1864.2QMS DocumentsReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]1.2.4Revision of the SQP10.3Quality Monitoring Documentation SES Department Quality Assurance Manual 8 303 1866.6.2Competence, awareness and trainingReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]Training New Team Members1 207 104Referenced in SQP MC3 §9.3 SES Department Quality Assurance Manual 8 303 1864.2.4, 5.3, 7.0, 7.4.1, 7.5.5, 8.5.3, Embedded in quality management
system processes. No separate
section on risk management.Referenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]SDP MC31 207 102 A8Risk Assessment3Terminology, Abbreviations and Acronyms 5.1, 5.2, 5.3.6, 9.1.6 Definition of V&V activities embedded
in SQP processes No counterpart in IEEE 730 4.14 4.15 Records collection, maintenance, and retention:
This section shall identify the SQA documentation to be retained; shall state the methods and facilities to be used to assemble, safeguard, and maintain this documentation; and shall
designate the retention period.
13 4.1314Training
- This section shall identify the training activities necessary to meet the needs of the SQAP 15Risk management:
This section shall specify the methods and procedures employed to identify, assess, monitor, and
control areas of risk arising during the portion of the software
life cycle covered by the SQAPSQP MC38 303 429 ESQP MC38 303 429 E Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotesDevelopment of safety class software1 206 076Referenced in SQP MC3 §9.3Development of standard software1 206 077Referenced in SQP MC3 §9.3Software maintenance and changes1 206 624Referenced in SQP MC3 §8General software specifications (CSS)1 207 101Referenced in SQP MC3 §2.1SDP MC31 207 102 ASoftware Development PlanDocument drafting rules1 207 103Referenced in SQP MC3 §9.3Development environment organization1 207 105Referenced in SQP MC3 §9.3Rules for programming in C1 207 106Referenced in SQP MC3 §9.3Rules for Verification/Validation of Software Components1 207 107 A/B/C Referenced in SQP MC3 §9.3Guide to writing documentation1 207 139Referenced in SQP MC3 §6SVTP1 207 146 GSoftware Validation Test Plan (SVTP) -
Operational System Software for Safety Class UnitsDefensive programming application rules1 207 185Referenced in SQP MC3 §9.3Basic and system access function management1 207 195Referenced in SQP MC3 §9.3SVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System
Software for Safety Class UnitsList of tools and libraries used by software1 207 286Referenced in SQP MC3 §9.2.2Software Configuration Management Process [IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicableGeneral process for Software Development [IL_PROC_GEN]1 208 079 A/B/C/D Not referenced in MC3 SQP, but
applicableDocument and data controlIncluded in 8 303 186Referenced in SQP MC3 §6.3SES Department Quality Assurance Manual 8 303 186Referenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM],
document 8 303 186 PUpgrade management8 303 197Referenced in SQP MC3 §8Contract Function Quality Assurance Manual8 303 311Referenced in SQP MC3 §2.1Design control8 303 334Referenced in SQP MC3 §9.3SQP MC38 303 429 ESoftware Quality Plan (SQP) - MC3Engineering Function Quality Assurance Manual8 303 667Referenced in SQP MC3 §2.1 Software Instructions Handbook (Software Quality Assurance Handbook)8 303 670Referenced in SQP MC3 §2.1General software specifications - Amendment no. 1,9 437 049Referenced in SQP MC3 §2.1 Cooperation agreement for the development and improvement of nuclear power station reactor instrumentation and control systems TA 93061 (2/08/93)Referenced in SQP MC3 §2.1 Index of SPINLINE 3 Life Cycle Documents in Table 3a IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotesSMQP1 208 686 B1.1 & 1.2Purpose of Document; Scope of Application This SMQP, document 1 208 686 B, is the standard SQAP that is used in
connection with modifications to the
generic SPINLINE 3 platform software. Modifications may be
made on occasion to improve this
platform software. This SQMP
applies only to the modification
phase of the software life cycle.
When a modification is needed, a
project-specific SDP provides the
project-specific guidance for that
modification effort. Modification of
the platform software typically is not
required for plant-specific SPINLINE 3 systems. 1.1Origin and objectives of the project 1.2Contract Clauses SMQP1 208 686 B2Applicable Documents and Reference Documents Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A1.3Technical reference documents Use of a separate SDP for each modification project is explained in SQMP §1.2.1SMQP1 208 686 B5Management of SPINLINE 3 Software Modification[IL_Gest_Proj]1 208 055 ESoftware Project Management Process Instruction Referenced in SQMP §5.1SMQP1 208 686 B4Organization Development environment organization1 207 105Referenced in SMQP §8.4 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A5OrganizationUse of a separate SDP for each modification project is explained in
SQMP §1.2.1 Use of a separate SDP for each modification project is explained in
SMQP §1.2.14.22 Referenced documents:
This section shall provide a complete list of documents referenced elsewhere in the text
of the SQAP4.3.13.1 Organization:
This paragraph shall depict the organizational structure that influences and controls the
quality of the software. This shall include a description of
each major element of the organization together with the
delegated responsibilities. Organizational dependence or
independence of the elements responsible for SQA from
those responsible for software development and use shall
be clearly described or depicted Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation 1 208 645 A and 1 208 908 A 4.3 Modification-specific SDPs for 2000 & 2001 modification projects Purpose: This section shall delineate the specific purpose and scope of the particular SQAP. It shall list the name(s)
of the software items covered by the SQAP and the
intended use of the software. It shall state the portion of the
software life cycle covered by the SQAP for each software
item specified.
1 4.1 3 Management:
This section shall describe organization, tasks, and responsibilities IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation1.2Scope of Application5.2SPINLINE 3 Software Modification Process Process flow charts provide an integrated view of the software
modification process.7Standard development cycle for safety class software8Development of SPINLINE 3 type safety class software[PRO_Concept_log_NC]8 307 214 BNon safety software design processReferenced in SQMP §5.22Description of the Project2.1Technical tree2.2Software development cycle retained2.3Flowchart of tasks1.3Responsibilities and changes to Quality Plan4Organization Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.4Management ActivitiesUse of a separate SDP for each modification project is explained in SQMP §1.2.1SMQP1 208 686 B6Documentation[Pro_Etab_Doc]8 303 198 PProcedure: Establishment and application of engineering
documents Referenced in SMQP §6[Gest_Doc_Col_Ref]8 303 638 BDocuments and reference files management Referenced in SMQP §6 & 10 Use of a separate SDP for each modification project is explained in
SQMP §1.2.1SMQP1 208 686 B4.3.23.2 Tasks: This paragraph shall describe a) That portion of the software life cycle covered by the
SQAP; b) The tasks to be performed with special emphasis on
software quality assurance activities; and
c) The relationships between these tasks and the planned
major checkpoints.
The sequence of the tasks shall be indicated.
Modification-specific SDPs for 2000 & 2001 modification projects 3.3 1 208 645 A and 1 208 908 A
4.3.3 Responsibilities
This paragraph shall identify the specific organizational elements responsible for each task.
Documentation SMQP 4 4.48 303 350 LReferenced in SMQP §5.2.1 & 8.1 Control of software design (safety systems)
[PRO_Concept_log_C]
1 208 686 B IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B11.1.2Document Control Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.3.1Document controlUse of a separate SDP for each modification project is explained in SQMP §1.2.14.4.24.2 Minimum documentation requirements
- To ensure that the implementation of the software satisfies requirements, the documentation in 4.4.2.1 through 4.4.2.6 is required as
a minimum See 4.2.1 - 4.2.6 below.
This SMQP applies to modification to
the generic platform software and
associated documentation.SRS1 207 108 JSoftware Requirement Specification -
Operational System Software SRS may be updated in connection
with the software modification. See
SMQP §5.2.
Interface Specifications -
Operational System Software and Application Software1 207 110 JNot referenced in SMQP, but applicable.4.4.2.24.2.2 Software Design Description (SDD):
The SDD shall depict how the software will be structured to satisfy the
requirements in the SRS. The SDD shall describe the
components and subcomponents of the software design, including databases and internal interfaces. The SDD shall
be prepared first as the Preliminary SDD (also referred to
as the top-level SDD) and shall be subsequently expanded
to produce the Detailed SDD SDD1 207 141 HSoftware Preliminary Design - Core System Software SDD or similar documents may be
updated in connection with the
software modification. See SMQP
§5.2.4.4.2.14.2.1 Software Requirements Specification (SRS
): The SRS shall clearly and precisely describe each of the essential
requirements (functions, performances, design constraints, and attributes) of the software and the external interfaces.
Each requirement shall be defined such that its
achievement is capable of being objectively verified and
validated by a prescribed method (e.g., inspection, analysis, demonstration, or test)4.4.14.1 Purpose: This section shall perform the following functions:
a) Identify the documentation governing the development, verification and validation, use, and maintenance of the
software.
b) State how the documents are to be checked for
adequacy. This shall include the criteria and the
identification of the review or audit by which the adequacy
of each document shall be confirmed, with reference to
Section 6 of the SQAP.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation8.2.4Unit tests of software components (includes Static Code Analysis &
Functional Validation)8.2.6Software Validation11.1.1Phase reviewsSVTP1 207 146 G Software Validation Test Plan (SVTP)
- Operational System Software for
Safety Class Units SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.4Verification & validation processReferenced in SMQP §5.2.1 & 8.1 Rules for Verification &
Validation of software components1 207 107 DReferenced in SMQP §8.4[PGCL_SPINLINE 3]1 208 878 DSPINLINE 3 Software Configuration Management Plan Referenced in SMQP §7. This SCMP
may be updated in connection with
the software modification. See SMQP
§5.2.4.4.2.44.2.4 Software Verification and Validation Report (SVVR):
The SVVR shall describe the results of the execution of the SVVP.SVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System
Software for Safety Class Units SVTR is referenced in SMQP §8.2.6.
SVTR may be updated in connection
with the software modification. 4.4.2.54.2.5 User documentation:
User documentation (e.g., manual, guide) shall specify and describe the required data and
control inputs, input sequences, options, program
limitations, and other activities or items necessary for
successful execution of the software. All error messages
shall be identified and corrective actions shall be described.
A method of describing user identified errors or problems to
the developer or the owner of the software shall be
described. (Embedded software that has no direct user
interaction has no need for user documentation and is
therefore exempted from this requirement.)
Software User Manual (SUM) already exists User documents may be updated in
connection with the software
modification. See SMQP §5.2.
There is no separate SVVP. This SMQP, SVTP and subordinate V&V
guidance documents perform the
function of the SVVP.4.4.2.34.2.3 Software Verification and Validation Plan (SVVP):
The SVVP shall identify and describe the methods (e.g.,
inspection, analysis, demonstration, or test) to be used to
a1) Verify that the requirements in the SRS have been
approved by an appropriate authority;
a2) Verify that the requirements in the SRS are
implemented in the design expressed in the SDD; and
a3) Verify that the design expressed in the SDD is
implemented in the code.
b) Validate that the code, when executed, complies with the
requirements expressed in the SRSSMQP1 208 686 B IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B7Configuration ManagementInvokes CM process in
[IL_Gest_Conf] and
[PGCL_SPINLINE 3][PGCL_SPINLINE 3]1 208 878 DSPINLINE 3 Software Configuration Management Plan Referenced in SMQP §7. This SCMP
may be updated in connection with
the software modification. See SMQP
§5.2.Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.9Configuration management processReferenced in SMQP §5.2.1 & 8.1 Configuration Management Process [IL_Gest_Conf].1 207 875 GReferenced in SMQP §7 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.5Configuration management activities and changes Use of a separate SDP for each
modification project is explained in
SQMP §1.2.14.4.34.3 Other: Other documentation may include the following:
a) Software Development Plan;
b) Standards and Procedures Manual;
c) Software Project Management Plan;
d) Software Maintenance Manual Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A Use of a separate SDP for each
modification project is explained in
SQMP §1.2.14.55Standards, practices, conventions, and metricsSMQP1 208 686 B8Methods, Tools and RulesAlso see Tools, techniques, and methodologies4.5.15.1 Purpose: This section shall a) Identify the standards, practices, conventions, and
metrics to be applied;
b) State how compliance with these items is to be
monitored and assured.
See 5.2 below4.4.2.64.2.6 Software Configuration Management Plan (SCMP):
The SCMP shall document methods to be used for identifying
software items, controlling and implementing changes, and
recording and reporting change implementation status IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LSafety software design processReferenced in SMQP §5.2 & 8.1[PRO_Concept_log_NC]8 307 214 BNon safety software design processReferenced in SMQP §5.2 & 8.1[LOBUL_SL3]1 207 286List of Tools and Libraries used for the Software - SPINLINE 3 Referenced in SMQP §8.2 & 8.37.2Identify configurationAppendix 1Identification rules Rules for Verification &
Validation of software components1 207 107 DReferenced in SMQP §8 Development environment organization1 207 105Referenced in SMQP §8.4 Basic functions and system access functions management1 207 195Referenced in SMQP §8.43Rules, Methods and Tools3.1Development activities3.2Test Activities 3.3Control Activities4.66Reviews and audits See 4.6.1 - 4.6.3 below Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P8.2.2Internal auditsNot referenced in SMQP, but applicable.SMQP1 208 686 B11Monitoring Application of the Quality Plan Use of a separate SDP for each modification project is explained in
SQMP §1.2.1 1 208 645 A and 1 208 908 A Content: The subjects covered shall include the basic technical, design, and programming activities involved, such
as documentation, variable and module naming, programming, inspection, and testing 5.2 4.5.2 Modification-specific SDPs for 2000 & 2001 modification projects Purpose: This section shall a) Define the technical and managerial reviews and audits
to be conducted;
b) State how the reviews and audits are to be
accomplished;
c) State what further actions are required and how they are
to be implemented and verified.4.6.16.1 Configuration Management Process [IL_Gest_Conf].1 207 875 GReferenced in SMQP §7 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B11.1Quality Actions: Typical Quality Assurance actions are: Phase reviews, Document control
~ document reviews,
~ peer reviews, Regular monitoring of the Quality File.Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.3.2AuditsUse of a separate SDP for each modification project is explained in
SQMP §1.2.14.6.36.3 Other: Other reviews and audits may include the user documentation review (UDR). This review is held to
evaluate the adequacy (e.g., completeness, clarity, correctness, and usability) of user documentation.[Gest_Doc_Col_Ref]8 303 638 BDocuments and reference files management Referenced in SMQP §108.2.4Unit tests on software components8.2.5Software integration tests Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.2Test ActivitiesUse of a separate SDP for each modification project is explained in SQMP §1.2.1 Rules for Verification &
Validation of software components1 207 107 DReferenced in SMQP §8SITR1 207 204 ESoftware Integration Test Plan and Report (SITR) - SCC (Core System
Software)SIT is described in SMQP §6.2.5 Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P8.3Control of nonconforming productNot referenced in SMQP, but applicable.
Configuration Management Process [IL_Gest_Conf].1 207 875 G7.3.1Record (Non-conformity report)Referenced in SMQP §7 Rules for Verification &
Validation of software components1 207 107 D11Change reportReferenced in SMQP §8 Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall
state the methods to be used 1 208 686 B SMQP4.77 4.84.6.26.2 Minimum requirements:
a) Software Requirements Review (SRR) b) Preliminary Design Review (PDR)
c) Critical Design Review (CDR)
d) Software Verification and Validation Plan Review (SVVPR) e) Functional audit
f) Physical audit
g) In-process audits
h Managerial reviews
i) Software Configuration Management Plan Review (SCMPR) j) Post-mortem review 8 Problem reporting and corrective action:
This section shall a) Describe the practices and procedures to be followed for
reporting, tracking, and resolving problems identified in both
software items and the software development and
maintenance process;
b) State the specific organizational responsibilities
concerned with their implementation.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation4.99 Tools, techniques, and methodologies:
This section shall identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and
describe their useSMQP1 208 686 B8Methods, Tools and RulesSee details above, mapped to "Standards, practices, conventions, and metrics"5.2.1Upgrade campaign control process5.2.2Process for upgrading and technical management of a SPINLINE 3 software component8.2.3Coding8.4Rules7Standard development cycle for safety class software8Development of SPINLINE 3 type safety class software[PRO_Concept_log_NC]8 307 214 BNon safety software design processReferenced in SMQP §5.2.1 & 8.1[LOBUL_SL3]1 207 286List of Tools and Libraries used for the Software - SPINLINE 3 Referenced in SMQP §8.2 & 8.3 Basic functions and system access functions management1 207 195Referenced in SMQP §8.4SMQP1 208 686 B10Reproduction, Protection, DeliveryThis section of the SMQP also addresses document control.[Reg_SLI]1 204 971 GInformation Technology Support functioning rules Referenced in SMQP §10 Referenced in SMQP §5.2.1 & 8.1 Media control:
This section shall state the methods and facilities to be used to a) Identify the media for each computer product and the
documentation required to store the media, including the
copy and restore process; and
b) Protect computer program physical media from
unauthorized access or inadvertent damage or degradation
during all phases of the software life cycle.
This may be provided as a part of the SCMP. If so, an
appropriate reference shall be made thereto.SMQP1 208 686 B Code control:
This section shall define the methods and facilities used to maintain, store, secure, and document
controlled versions of the identified software during all
phases of the software life cycle. This may be implemented
in conjunction with a computer program library. This may be
provided as a part of the SCMP. If so, an appropriate
reference shall be made thereto 10 4.14.1111 Control of software design (safety systems)
[PRO_Concept_log_C]
8 303 350 L IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P7.4PurchasingNot referenced in SMQP, but applicable.SMQP1 208 686 B9Monitoring SuppliersThere are no subcontractors[IL_Outils]1 206 747 ESoftware Instruction: Requirements on software development tools Referenced in SMQP §9.2[IL_Ctrl_log_Ext]8 303 671 BSoftware Instruction: External software reception control Referenced in SMQP §9.2 Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P4.2QMS DocumentsNot referenced in SMQP, but applicable.10Reproduction, Protection, Delivery11.3Quality-related records[Gest_Doc_Col_Ref]8 303 638 BDocuments and reference files management Referenced in SMQP §6 & 10[Reg_SLI]1 204 971Referenced in SMQP §2 [Mait_Enr]8 303 320 LProcedure: Control of recordsReferenced in SMQP §10 SMQP4.1313 4.12 1 208 686 B 12 Records collection, maintenance, and retention:
This section shall identify the SQA documentation to be retained; shall state the methods and facilities to be used to
assemble, safeguard, and maintain this documentation; and
shall designate the retention period.
Supplier control:
This section shall state the provisions for assuring that software provided by suppliers meets established requirements. In addition, this section shall
state the methods that will be used to assure that the
software supplier receives adequate and complete
requirements. For previously developed software, this
section shall state the methods to be used to assure the
suitability of the product for use with the software items
covered by the SQAP. For software that is to be developed, the supplier shall be required to prepare and implement an
SQAP in accordance with this standard. This section shall
also state the methods to be employed to assure that the
developers comply with the requirements of this standard.
IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P6.6.2Competence, awareness and trainingNot referenced in SMQP, but applicable.[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training Plan Not referenced in SMQP, but applicable.5Reference documents (references 1 208 210, "Software instruction -
Software V&V Team Training Plan"6.7Sub-contract management process7.2.3Software development plan (references SDP as the location of
training requirements)[PRO_Concept_log_NC]8 307 214 BNon safety software design processReferenced in SMQP §5.2.1 & 8.1 Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P4.2.4, 5.3, 7.0, 7.4.1, 7.5.5, 8.5.3, Embedded in quality management
system processes. No separate
section on risk management.
Not referenced in SMQP, but
applicable.
Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A8Risk AnalysisUse of a separate SDP for each modification project is explained in
SQMP §1.2.13Terminology and Abbreviations5.1Budget and schedule controlInvokes process in [IL_Gest_Proj]11.2Scheduling Quality Assurance actions4Means (Resources)4.1Material means4.2Software means 4.3Human means 9.1Planning 9.2Table of costs Use of a separate SDP for each modification project is explained in
SQMP §1.2.1 Referenced in SMQP §5.2.1 & 8.1 1 208 645 A and 1 208 908 A 1 208 686 B No counterpart in IEEE 730 Modification-specific SDPs for 2000 & 2001 modification projects Training: This section shall identify the training activities necessary to meet the needs of the SQAP 4.1515 4.14 SMQP Control of software design (safety systems)
[PRO_Concept_log_C]
Risk management:
This section shall specify the methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portion
of the software life cycle covered by the SQAP 8 303 350 L 14 Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes[Reg_SLI]1 204 971 GInformation Technology Support functioning rulesReferenced in SMQP and SQP "Software Quality Assurance Handbook", document. 8 303 670[IL_Outils]1 206 747 ESoftware Instruction: Requirements on software development tools Referenced in SMQP §9.2Development environment organization1 207 105Referenced in SMQP §8.4 Rules for Verification & Validation of software components1 207 107 DReferenced in SMQP §8SRS1 207 108 JSoftware Requirement Specification - Operational System Software SRS may be updated in connection with the software modification. See SMQP §5.2.
Interface Specifications - Operational System Software and Application Software1 207 110 JNot referenced in SMQP, but applicable.
Software Preliminary Design - Core System Software 1 207 141 HSVTP1 207 146 G Software Validation Test Plan (SVTP) - Operational
System Software for Safety Class Units Basic functions and system access functions management1 207 195Referenced in SMQP §8.4SITR1 207 204 ESoftware Integration Test Plan and Report (SITR) -
SCC (Core System Software)SVTR1 207 232 FSoftware Validation Test Report (SVTR) -
Operational System Software for Safety Class Units[LOBUL_SL3]1 207 286List of Tools and Libraries used for the Software -
SPINLINE 3 Referenced in SMQP §8.2 & 8.3 Configuration Management Process
[IL_Gest_Conf].1 207 875 GReferenced in SMQP §7[IL_Gest_Proj]1 208 055 ESoftware Instruction: Software project management process Referenced in SQMP §5.1[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training Plan Not referenced in SMQP, but applicable.SDP 2000 Changes 1 208 645 A Software Development Plan. Per SQMP §1.2.1, a specific Software Development Plan is created for each upgrade
campaignSMQP1 208 686 BSoftware Modification Quality Plan Index of SPINLINE 3 Life Cycle Documents in Table 3b Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes Index of SPINLINE 3 Life Cycle Documents in Table 3b[PGCL_SPINLINE 3]1 208 878 DSPINLINE 3 Software Configuration Management PlanSDP 2001 Changes 1 208 908 A Software Development Plan. Per SQMP §1.2.1, a specific Software Development Plan is created for each upgrade campaign Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 PNot referenced in SMQP, but applicable.[Pro_Etab_Doc]8 303 198 PProcedure: Establishment and application of engineering
documents Referenced in SMQP §6[Mait_Enr]8 303 320 LProcedure: Control of recordsReferenced in SMQP §10 Control of software design (safety systems) [PRO_Concept_log_C]8 303 350 LReferenced in SMQP §5.2.1 & 8.1[Gest_Doc_Col_Ref]8 303 638 BDocuments and reference files managementReferenced in SMQP §10[IL_Ctrl_log_Ext]8 303 671 BSoftware Instruction: External software reception control Referenced in SMQP §9.2[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design ProcessReferenced in SMQP §5.2.1 & 8.1 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes4.11 Purpose: This section shall delineate the specific purpose an d scope of the particular SQAP. It shall list the name(s) of the software items covered by the SQAP and the intended use of
the software. It shall state the portion of the software life cycle
covered by the SQAP for each software item specified.SQAP8 307 208 B1.1 & 1.2PurposeNote that SQAP, document 8 307 208 B, is a generic template that establishe s the framework for completing the SQA P for plant-specific application software
that will interface with the SPINLINE 3 generic platform software.4.22 Referenced documents:
This section shall provide a complete list of documents referenced elsewhere in the text of
the SQAPSQAP8 307 208 B2Reference Documents SQAP8 307 208 B3Management[IL_Gest_Proj]1 208 055 ESoftware Project Management Process Instruction Referenced in SMQP §5.14.3.13.1 Organization:
This paragraph shall depict the organizational structure that influences and controls the quality of the softwar e This shall include a description of each major element of the organization together with the delegated responsibilities.
Organizational dependence or independence of the elements
responsible for SQA from those responsible for software
development and use shall be clearly described or depictedSQAP8 307 208 B3.1Organization3.2Tasks3.2.1Software life Cycle OverviewFigure provides an integrated view of software activities in each life cycle
phase3.2.1.1Document Relationship in the Software Life Cycle Figure provides an integrated view
input and output documents in each life
cycle phase3.2.2Software Management Activities3.2.3Software Development Activities3.2.4Software Safety and Security Activities3.2.5Software Verification and Validation Activities3.2.6Software Configuration Management Activities3.2.7Software Quality Assurance Activities Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation
4.3 Tasks
This paragraph shall describe a) That portion of the software life cycle covered by the SQAP; b) The tasks to be performed with special emphasis on
software quality assurance activities; and
c) The relationships between these tasks and the planned
major checkpoints.
The sequence of the tasks shall be indicated.
3 Management:
This section shall describe organization, tasks, and responsibilitiesSQAP8 307 208 B 3.2 4.3.2 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation1.4Creation and Update of the SQAP3.1, 3.3Organization; Responsibilities4.8Summary of Engineering Documents and Associated Responsibilities4Documentation4.8Summary of Engineering Documents and Associated Responsibilities4.1Introduction4.8Summary of Engineering Documents and Associated Responsibilities4.4.24.2 Minimum documentation requirements
- To ensure that the implementation of the software satisfies requirements, the documentation in 4.4.2.1 through 4.4.2.6 is required as a
minimumSQAP8 307 208 B4.2 to 4.8SQAP8 307 208 B4.3Software Requirements Specification (SRS)[IL_GD_CCL]1 207 854 BSoftware Guideline: SRS Documentation Guideline Referenced in SQAP §24.4.2.24.2.2 Software Design Description (SDD):
The SDD shall depict how the software will be structured to satisfy the requirements in the SRS. The SDD shall describe the components and
subcomponents of the software design, including databases
and internal interfaces. The SDD shall be prepared first as the
Preliminary SDD (also referred to as the top-level SDD) and
shall be subsequently expanded to produce the Detailed SDD SQAP8 307 208 B4.3Software Design Description (SDD)
Software Requirements Specification (SRS
): The SRS shall clearly and precisely describe each of the essential
requirements (functions, performances, design constraints, and
attributes) of the software and the external interfaces. Each
requirement shall be defined such that its achievement is
capable of being objectively verified and validated by a
prescribed method (e.g., inspection, analysis, demonstration, or test)4.1 4.4.1 Purpose: This section shall perform the following functions:
a) Identify the documentation governing the development, verification and validation, use, and maintenance of the
software.
b) State how the documents are to be checked for adequacy.
This shall include the criteria and the identification of the review
or audit by which the adequacy of each document shall be
confirmed, with reference to Section 6 of the SQAP.4.4.2.14.2.1 3.3 4.3.3 Responsibilities:
This paragraph shall identify the specific organizational elements responsible for each task.4.44Documentation 8 307 208 B SQAP 8 307 208 BSQAP8 307 208 B SQAP IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation4.4, 4.5Software Verification and Validation Plan (SVVP)
Software Validation Test Plan (SVTP)
Software Validation Test Plan and Report (SVTPR)
Software Integration Test Plan and Report (SITPR)
Verification and Validation Documents, listed below:
Verification Report Software Validation Test Report (SVTR)Software Validation Test Plan and Report (SVTPR)
Software Integration Test Plan and Report (SITPR)
Software Component Test Description
and Report V&V Final Report (VVFR)4.4.2.54.2.5 User documentation:
User documentation (e.g., manual, guide) shall specify and describe the required data and control inputs, input sequences, options, program limitations, and othe r activities or items necessary for successful execution of the
software. All error messages shall be identified and corrective
actions shall be described. A method of describing user
identified errors or problems to the developer or the owner of
the software shall be described. (Embedded software that has
no direct user interaction has no need for user documentation
and is therefore exempted from this requirement.)SQAP8 307 208 B4.3Software User Documentation Software Verification and Validation Plan (SVVP):
The SVVP shall identify and describe the methods (e.g., inspection, analysis, demonstration, or test) to be used to
a1) Verify that the requirements in the SRS have been
approved by an appropriate authority;
a2) Verify that the requirements in the SRS are implemented i n the design expressed in the SDD; and
a3) Verify that the design expressed in the SDD is
implemented in the code.
b) Validate that the code, when executed, complies with the
requirements expressed in the SRS4.4.2.34.2.3 4.4.2.4 Software Verification and Validation Report (SVVR):
The SVVR shall describe the results of the execution of the SVVP.
4.2.4SQAP8 307 208 B 4.5 4.5SQAP8 307 208 B IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Configuration Management Documents
, listed below:
Software Configuration Management
Plan (SCMP)
List of Software Documents (LSD)
Software Manufacturing File (SMF)
Software Configuration Management Report (SCMR)
Configuration Management Final
Report (CMFR)
Software Development Plan (SDP)
Software Project Tracking File (SPTF)
Network Design Description (NDD)
Software Component Specification
Source Code4.7Quality Assurance Documents4.55Standards, practices, conventions, and metricsSQAP8 307 208 B5Standards, practices, conventions, and metrics 8 307 208 B 4.3 4.4.3 Other: Other documentation may include the following:
a) Software Development Plan; b) Standards and Procedures Manual;
c) Software Project Management Plan;
d) Software Maintenance Manual4.4.2.64.2.6 Software Configuration Management Plan (SCMP):
The SCMP shall document methods to be used for identifying software items, controlling and implementing changes, and
recording and reporting change implementation statusSQAP4.2 4.3 4.6 8 307 208 B SQAP IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation
5.1 Purpose
This section shall a) Identify the standards, practices, conventions, and metrics to be applied;
b) State how compliance with these items is to be monitored
and assured.
See 5.2 below Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LVariousReferenced in SQAP §6[PRO_Concept_Log_NC]8 307 214 BNon Safety Software Design ProcessReferenced in SQAP §6 Configuration Management Process [IL_Gest_Conf].1 207 875 GVariousReferenced in SQAP §2 & 5[SDP]8 307 211 B SPINLINE 3 Software Development Plan - SDP Referenced in SQAP §2, 4.2 & 5[IL_Spec_IHM]1 208 592 BSoftware Guideline: Human-Machine Interface specification process Referenced in SQAP §2 & 5[IL_SCADE]1 208 250 ESoftware Guideline: SCADE Design Rules Referenced in SQAP §2 & 5[IL_Prog_C]1 208 954 CSoftware Guideline: C programming rules: synthesis Referenced in SQAP §2 & 5[IL_Prog_Def]1 208 605 CDefensive programming application rules Not referenced but applicable[SVVP]8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP Referenced in SQAP §2 & 7[SCMP]8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP Referenced in SQAP §2, 9 & 10[IL_GD_Intro]1 207 853 ESoftware Guideline : Documentation Guidelines Referenced in SQAP §2 & 5[IL_Vérif_Doc]1 207 947 ESoftware Guideline: Software Document Evaluation Process Referenced in SQAP §2 & 5[IL_Proc_Qual]8 303 634 DSoftware Guideline: Software Quality Assurance Process Referenced in SQAP §2 & 5[IL_Ctrl_Log-Ext]8 303 671 BSoftware Guideline: Requirements for commercial software Referenced in SQAP §2 & 5[IL_Outils]1 206 747 ESoftware Guideline: Requirements on tools used for software development Referenced in SQAP §6 4.5.1 5.2 Content: The subjects covered shall include the basic technical, design, and programming activities involved, such as
documentation, variable and module naming, programming, inspection, and testing IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation4.66Reviews and auditsSQAP8 307 208 B6Reviews and audits Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P8.2.2Internal auditsReferenced in SQAP §2.SQAP8 307 208 B6Reviews and audits Management reviews End of phase reviews Document reviews
Audits External audits Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LVariousReferenced in SQAP §6[PRO_Concept_Log_NC]8 307 214 BNon Safety Software Design ProcessReferenced in SQAP §6[IL_Proc_Qual]8 303 634 DSoftware Guideline: Software Quality Assurance Process Referenced in SQAP §64.6.36.3 Other: Other reviews and audits may include the user documentation review (UDR). This review is held to evaluate the adequacy (e.g., completeness, clarity, correctness, and
usability) of user documentation.
Software Guideline: Software Document Evaluation Process [IL_Verif_Doc]1 207 947 EReferenced in SQAP §6SQAP8 307 208 B7Testing ActivitiesSVVP8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP Referenced in SQAP §2, 7 & 8[IL_Plan_Test]1 208 304 ASoftware Guideline: Software Test PlanReferenced in SQAP §2 Test: This section shall identify all the tests not included in the SVVP for the software covered by the SQAP and shall state the methods to be used 4.7 6.1 7 4.6.2 4.6.1 Purpose: This section shall a) Define the technical and managerial reviews and audits to b e conducted; b) State how the reviews and audits are to be accomplished;
c) State what further actions are required and how they are to
be implemented and verified.SQAP6 8 307 208 B
6.2 Minimum
requirements:
a) Software Requirements Review (SRR)
b) Preliminary Design Review (PDR)
c) Critical Design Review (CDR)
d) Software Verification and Validation Plan Review (SVVPR)
e) Functional audit
f) Physical audit
g) In-process audits
h Managerial reviews
i) Software Configuration Management Plan Review (SCMPR)
j) Post-mortem review IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P8.3Control of nonconforming productReferenced in SQAP §2.SQAP8 307 208 B8Problem reporting and corrective actionSCMP8 307 209 B5.3 SPINLINE 3 Software Configuration Management Plan - SCMP Referenced in SQAP §2, 8, 9 & 10SVVP8 307 210 B5.1, 6.1 SPINLINE 3 Software Verification and Validation Plan - SVVP Referenced in SQAP §2, 7 & 84.99 Tools, techniques, and methodologies:
This section shall identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and
describe their useSQAP8 307 208 B9Tools, techniques, and methodologies4.1010 Code control:
This section shall define the methods and facilities used to maintain, store, secure, and document
controlled versions of the identified software during all phases
of the software life cycle. This may be implemented in
conjunction with a computer program library. This may be
provided as a part of the SCMP. If so, an appropriate reference
shall be made theretoSCMP8 307 210 B4.5 SPINLINE 3 Software Verification and Validation Plan - SVVP Referenced in SQAP §2, 8, 9 & 10SQAP8 307 208 B10Media controlSCMP8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP Referenced in SQAP §2, 8, 9 & 10 Problem reporting and corrective action:
This section shall a) Describe the practices and procedures to be followed for
reporting, tracking, and resolving problems identified in both
software items and the software development and maintenance
process; b) State the specific organizational responsibilities concerned
with their implementation.
8 4.11 Media control:
This section shall state the methods and facilities to be used to
a) Identify the media for each computer product and the
documentation required to store the media, including the copy
and restore process; and
b) Protect computer program physical media from unauthorized
access or inadvertent damage or degradation during all phases
of the software life cycle.
This may be provided as a part of the SCMP. If so, an
appropriate reference shall be made thereto.
4.8 11 IEEE 730 Section SQAP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 3c. Mapping SPINLINE 3 Application SQAP and Other Content to IEEE 730-1998 SQAP Content GuidanceIEEE 730-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P7.4PurchasingReferenced in SQAP §2.SQAP8 307 208 B11Supplier control Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P4.2QMS DocumentsReferenced in SQAP §2.1.4Creation and Update of the SQAP12Records collection, maintenance, and retentionSCMP8 307 209 B6.5ArchivingReferenced in SQAP §12.
Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P6.2.2Competence, awareness and trainingReferenced in SQAP §2.SQAP8 307 208 B13Training[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training Plan Referenced in SQAP §13.
Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P4.2.4, 5.3, 7.0, 7.4.1, 7.5.5, 8.5.3 Embedded in quality management system processes. No separate
section on risk management.
Referenced in SQAP §2.SQAP8 307 208 B14Risk Management[IL_Gest_Proj]1 208 055 ESoftware Guideline: Software Management Process Referenced in SQAP §14.1.2Relationship of this SQAP to the Plans Defined in BTP 7-141.3Definitions and Abbreviations4.14144.1515 Risk management:
This section shall specify the methods and procedures employed to identify, assess, monitor, and control areas of risk arising during the portion of the software
life cycle covered by the SQAP 8 307 208 B 8 307 208 B SQAP SQAP Records collection, maintenance, and retention:
This section shall identify the SQA documentation to be retained; shall state the methods and facilities to be used to assemble, safeguard, and maintain this documentation; and shall
designate the retention period.
No counterpart in IEEE 730 Training: This section shall identify the training activities necessary to meet the needs of the SQAP 4.13 Supplier control:
This section shall state the provisions for assuring that software provided by suppliers meets established requirements. In addition, this section shall state the methods
that will be used to assure that the software supplier receives
adequate and complete requirements. For previously
developed software, this section shall state the methods to be
used to assure the suitability of the product for use with the
software items covered by the SQAP. For software that is to be
developed, the supplier shall be required to prepare and
implement an SQAP in accordance with this standard. This
section shall also state the methods to be employed to assure
that the developers comply with the requirements of this
standard.13 12 4.12 Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes[IL_Outils]1 206 747 DSoftware Guideline: Requirements on tools used for software developmentReferenced in SQAP §6[IL_GD_Intro]1 207 853 ESoftware Guideline : Documentation GuidelinesReferenced in SQAP §2 & 5[IL_GD_CCL]1 207 854 BSoftware Guideline: SRS Documentation GuidelineReferenced in SQAP §2 Configuration Management Process
[IL_Gest_Conf].
1 207 875 G Referenced in SQAP §2 & 5 Software Guideline: Software Document Evaluation Process [IL_Verif_Doc]1 207 947 ESoftware Guideline: Software Document Evaluation ProcessReferenced in SQAP §6[IL_Gest_Proj]1 208 055 ESoftware Guideline: Software Management ProcessReferenced in SQAP §14.[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training PlanReferenced in SQAP §13.[IL_SCADE]1 208 250 CSoftware Guideline: SCADE Design RulesReferenced in SQAP §2 & 5[IL_Plan_Test]1 208 304 ASoftware Guideline: Software Test PlanReferenced in SQAP §2[IL_Spec_IHM]1 208 591 BSoftware Guideline: Human-Machine Interface specification processReferenced in SQAP §2 & 5[IL_Prog_Def]1 208 605 CDefensive programming application rulesReferenced in SQAP §2 & 5[IL_Prog_C]1 208 954 CSoftware Guideline: C programming rules: synthesisReferenced in SQAP §2 & 5 Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 PRolls-Royce Civil Nuclear SAS Quality ManualReferenced in SQAP §2.
Control of software design (safety systems) [PRO_Concept_log_C]
8 303 350 L Referenced in SQAP §14.[IL_Proc_Qual]8 303 634 DSoftware Guideline: Software Quality Assurance ProcessReferenced in SQAP §6[IL_Ctrl_Log-Ext]8 303 671 BSoftware Guideline: Requirements for commercial softwareReferenced in SQAP §2 & 5[SQAP]8 307 208 B SPINLINE 3 Software Quality Assurance Plan - SQAP[SCMP]8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP Referenced in SQAP §12.[SVVP]8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP Referenced in SQAP §2 & 7[SDP]8 307 211 B SPINLINE 3 Software Development Plan - SDP Referenced in SQAP §2, 4.2 & 5[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design ProcessReferenced in SQAP §6 Index of SPINLINE 3 Life Cycle Documents in Table 3c IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotesSQP MC38 303 429 E1Purpose, Scope and ResponsibilitiesThere is no separate SCMP. The SQP MC3, supplemented by software instruction 1 207 875 A, "Software
Configuration Management Process"
[IL_Gest_Conf], performs the function
of the SCMP. A later revision of this
instruction is applicable to current CM
processes.1Project Overview2Description of the Project List of tools and libraries used by software1 207 286Referenced in SQP MC3 §9.2.2SQP MC38 303 429 E7.1Purpose of Configuration Management (see SCM responsibilities below)
Software Configuration Management Process
[IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicable4.2.12.1Organization:
The organizational context, both technical and managerial, within which the planned SCM activities are to be implemented shall be described.SQP MC38 303 429 E4Specific organizational structure associated with the software project 4.3Duties of Members of the Software Team7.4 & 8Procedures for identification and entry into configuration; Management of
changes to software and associated
documentation Software Project Manager is
responsible for CMSQP MC38 303 429 E2Reference Documents and Applicable DocumentsGuide to writing documentation1 207 139NoReferenced in SQP MC3 §6Document drafting rules1 207 103NoReferenced in SQP MC3 §9.3 Table 4a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation4.2.22.2SCM responsibilities:
The allocation of SCM activities to organizational units shall be specified.SDP MC31 207 102 ASQP MC38 303 429 E4.11Introduction:
Describes the Plan's purpose, scope of application, key terms, and references Applicable policies, directives, and procedures:
Any external constraints placed on the Plan by other policies, directives, and procedures shall be identified. For each, its
impact and effect on the Plan shall be stated.
2.3 4.2.34.22SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation7Configuration management8Management of changes to software and associated documentation Software Configuration Management Process
[IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicable7.2Configuration Elements7.3Identification of Elements7.4Procedure for Identification and Entry Into ConfigurationList of documents for the CSS1 207 269 List of documents for the CD_LDU 1 207 282List of documents for the BF1 207 148 Software Configuration Management Report for the CSS 1 207 257 Software Configuration Management Report for the BF 1 207 277 Software Configuration Management Report for the CD_LDU 1 207 283 These documents contain the results of configuration identification for the
elements of the OSS.SQP MC38 303 429 ESQP MC38 303 429 E 3.14.33SCM activities:
(What?) Identifies all activities to be performed in applying to the project4.3.1Configuration identification:
The Plan shall identify the project configuration items (CI) and their structures at each project control point. The Plan shall state how each CI and its
versions are to be uniquely named and describe the activities
performed to define, track, store, and retrieve CIs.
IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentationSQP MC38 303 429 E8Management of changes to software and associated documentationDocument and data control8 303 186NoReferenced in SQP MC3 §6.3Upgrade management8 303 197NoReferenced in SQP MC3 §8 Software maintenance and changes1 206 624NoReferenced in SQP MC3 §84.3.33.3Configuration status accounting:
Configuration status accounting activities record and report the status of project CIsSQP MC38 303 429 E10.3Quality Monitoring Documentation10Quality assurance measures10.2.1End-of-phase reviews10.2.2Document design reviews10.2.3Document peer reviews10.2.4Audits Interface Specifications -
Operational System Software and Application Software1 207 110 JNot referenced in SQP, but applicable.SQP MC38 303 429 E4.3Duties of members of the software team Project Manager was responsible for coordination of work performed by the
project partners4.3.63.6Subcontractor/vendor control:
Subcontractor/vendor control activities incorporate items developed outside the project
environment into the project CIs. Included are software
developed by contract and software acquired in its finished
form.SES Department Quality Assurance Manual 8 303 1867.4PurchasingReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]3.4Cost and schedule management6Planning Software Configuration Management Process
[IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicable 8 303 429 E4.3.43.4Configuration audits and reviews:
Configuration audits determine to what extent the actual CI reflects the required
physical and functional characteristics. Configuration reviews
are management tools for establishing a baseline.4.3.53.5Interface control:
Interface control activities coordinate changes to the project CIs with changes to interfacing items
outside the scope of the Plan. Hardware, system software and
support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the
project.4.44 It is Rolls-Royce practice to put
schedule details in the SDP for each
project.
SQP MC3 1 207 102 A SDP MC34.3.2Configuration control:
Activities include request, evaluate, approve or disapprove, and implement changes to baselined
CIs. Changes encompass both error correction and
enhancement SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project 3.2 IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation4.55SCM resources: (How?) Identifies tools and physical and human resources required for execution of the PlanSDP MC31 207 102 A4Resources to be deployedIt is Rolls-Royce practice to put resource details in the SDP for each project. 4.66SCM plan maintenance:
Identifies how the Plan will be kept current while in effect SES Department Quality Assurance Manual 8 303 186Document and Data ControlReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM]
None No counterpart in IEEE 828 Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotesSoftware maintenance and changes1 206 624Referenced in SQP MC3 §8SDP MC31 207 102 ASoftware Development PlanDocument drafting rules1 207 103Referenced in SQP MC3 §9.3 Interface Specifications - Operational System Software and Application Software 1 207 110Guide to writing documentation1 207 139Referenced in SQP MC3 §6List of documents for the BF1 207 148 Software Configuration Management Report for the CSS 1 207 257List of documents for the CSS1 207 269Software Configuration Management Report for the BF1 207 277List of documents for the CD_LDU1 207 282 Software Configuration Management Report for the CD_LDU 1 207 283List of tools and libraries used by software1 207 286Referenced in SQP MC3 §9.2.2 Software Configuration Management Process
[IL_Gest_Conf]1 207 875 ANot referenced in MC3 SQP, but applicableSES Department Quality Assurance Manual 8 303 186Referenced in SQP MC3 §2.1 & 6.3. Now known as Rolls-Royce Civil Nuclear SAS Quality Manual [PQM], document 8 303 186 PUpgrade management8 303 197Referenced in SQP MC3 §8Design control8 303 334Referenced in SQP MC3 §9.3SQP MC38 303 429 ESoftware Quality Plan (SQP) - MC3Software Quality Plan (SQP) - MC3 Index of SPINLINE 3 Life Cycle Documents in Table 4a These documents contain the results of configuration
identification for the elements of the OSS.
- Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes4.11
Introduction:
Describes the Plan's purpose, scope of application, key terms, and references SCMP
[PGCL_SPINLINE 3]1 208 878 D11.1 Purpose of document; 1.2 Scope;
1.3 Reference
documents; 1.4 Glossar y and abbreviations This SCMP, document 1 208 878 D, is used in connection with modifications t o the generic SPINLINE 3 platform software. Modifications may be made
on occasion to improve this platform
software. This SCMP applies only to
the modification phase of the software
life cycle. When a modification is
needed, this SCMP provides the projec t specific guidance for that modification
effort. Modification of the platform
software typically is not required for
plant-specific SPINLINE 3 systems.
[PGCL_SPINLINE 3]1 208 878 D2.1Duties and responsibilities Configuration Management Process [IL_Gest_Conf].1 207 875 G6Duties and responsibilitiesReferenced in SCMP §2.1 & 2.9SMQP1 208 686 B4Organization Development environment organization1 207 105Referenced in SMQP §8.4 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A5OrganizationUse of a separate SDP for each modification project is explained in
SQMP §1.2.1 2 SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities
2.1 Organization
The organizational context, both technical and managerial, within which the planned SCM activities are to be
implemented shall be described.
Table 4b. Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation 4.2 4.2.1 IEEE 828 Section SCMP Section
- Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4b. Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation1.3Responsibilities and changes to Quality Plan4Organization Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.5Configuration management activities and changes Use of a separate SDP for each modification project is explained in
SQMP §1.2.1 SCMP
[PGCL_SPINLINE 3]1 208 878 D2.1Duties and responsibilities Configuration Management Process [IL_Gest_Conf].1 207 875 G6Duties and responsibilitiesReferenced in SCMP §2.1 & 2.91.3Reference documents3Tools, Techniques, and Methodology3.1Principle applied to the organization of development spaces Invokes process in [IT_SL3_Env_Dev][IT_SL3_Env_Dev]1 207 105 D SPINLINE 3 technical instruction:
Description of development
environmentsReferenced in SCMP §3.12.3Elements managed and associated levels of control3.2Configuration administration Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.5Configuration management activities and changes Use of a separate SDP for each
modification project is explained in
SQMP §1.2.1 1 208 686 B SCMP
[PGCL_SPINLINE 3]
1 208 878 D SCM activities:
(What?) Identifies all activities to be performed in applying to the project SMQP4.2.22.2 SCM responsibilities:
The allocation of SCM activities to organizational units shall be specified.
1 208 878 D SCMP
[PGCL_SPINLINE 3]4.33 Applicable policies, directives, and procedures:
Any external constraints placed on the Plan by other policies, directives, and procedures shall be identified. For each, its
impact and effect on the Plan shall be stated.4.2.32.3 IEEE 828 Section SCMP Section
- Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4b. Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation2.2Configuration breakdownRefer to tree diagram of configuration breakdown2.5Reference configuration3.1Configuration administration Configuration Management Process [IL_Gest_Conf].1 207 875 G7.2Identify ConfigurationReferenced in SCMP §2.1 & 2.9List of documents for the CSS1 207 269 List of documents for the CD_LDU 1 207 282List of documents for the BF1 207 148 Software Configuration Management report for the CSS 1 207 257 Software Configuration Management report for the BF 1 207 277 Software Configuration Management report for the CD_LDU 1 207 283 These documents contain the results of configuration identification for the
elements of the OSS.
Configuration identification:
The Plan shall identify the project configuration items (CI) and their structures at each
project control point. The Plan shall state how each CI and its
versions are to be uniquely named and describe the activities
performed to define, track, store, and retrieve CIs.
1 208 878 D SCMP
[PGCL_SPINLINE 3]
3.1 4.3.1 IEEE 828 Section SCMP Section
- Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4b. Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentationSMQP1 208 686 B7Configuration Management2.3Elements managed and associated levels of control2.4Control levels2.7Managing modifications 2.9Configuration controlInvokes process in [IL_Gest_Conf]
3.3Procedure for changing a SOURCE_1E type file3.4Work spaces under Unix for verification and unit tests3.5Initial migration and Control Configuration Management Process [IL_Gest_Conf].1 207 875 G7.3Control ChangesReferenced in SCMP §2.1 & 2.94.3.33.3 Configuration status accounting:
Configuration status accounting activities record and report the status of project CIs SCMP
[PGCL_SPINLINE 3]1 208 878 D2.8Monitoring the configurationSMQP1 208 686 B11.1Quality Actions: Typical Quality Assurance actions are: Phase reviews, Document control
~ document reviews,
~ peer reviews, Regular monitoring of the Quality File.
[PGCL_SPINLINE 3]1 208 878 D2.6Elements managed and associated levels of control 1 208 878 D
3.4 Configuration
audits and reviews:
Configuration audits determine to what extent the actual CI reflects the required
physical and functional characteristics. Configuration reviews
are management tools for establishing a baseline.
3.2 4.3.2 SCMP
[PGCL_SPINLINE 3]
Configuration control:
Activities include request, evaluate, approve or disapprove, and implement changes to baselined
CIs. Changes encompass both error correction and
enhancement 4.3.4 IEEE 828 Section SCMP Section
- Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4b. Mapping SPINLINE 3 Platform Software SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation4.3.53.5 Interface control:
Interface control activities coordinate changes to the project CIs with changes to interfacing items outside the scope of the Plan. Hardware, system software and
support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the
project.Interface Specifications -
Operational System Software and Application Software1 207 110 JNot referenced in SCMP, but applicable.SMQP1 208 686 B9Monitoring Suppliers[IL_Ctrl_log_Ext]8 303 671 BSoftware Instruction: External software reception control Not referenced in SCMP, but
applicable. Referenced in SMQP §9.24.44 SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A6ScheduleIt is Rolls-Royce practice to put schedule details in the SDP for each
project. Use of a separate SDP for
each modification project is explained
in SQMP §1.2.1 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A4MeansIt is Rolls-Royce practice to put resource details in the SDP for each
project. Use of a separate SDP for
each modification project is explained
in SQMP §1.2.1[For_Gcf]Configuration management tool training documentReferenced in SCMP §2.5, 2.64.66 SCM plan maintenance:
Identifies how the Plan will be kept current while in effect[Gest_Doc_Col_Ref]8 303 638 BNoDocuments and reference files management Not referenced in SCMP, but
applicable. Referenced in SMQP §6 &
10SCMP1 208 878 D2.6Archives4.55 SCM resources: (How?) Identifies tools and physical and human resources required for execution of the Plan4.3.63.6 No counterpart in IEEE 828 Subcontractor/vendor control:
Subcontractor/vendor control activities incorporate items developed outside the project
environment into the project CIs. Included are software
developed by contract and software acquired in its finished
form.
Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes[IT_SL3_Env_Dev]1 207 105 D SPINLINE 3 Technical Instruction: Description of Development EnvironmentsReferenced in SCMP §3.1 Interface Specifications - Operational System Software and Application Software 1 207 110 JList of documents for the BF1 207 148 Software Configuration Management Report for the CSS 1 207 257List of documents for the CSS1 207 269 Software Configuration Management Report for the BF 1 207 277List of documents for the CD_LDU1 207 282 Software Configuration Management Report for the CD_LDU 1 207 283 Configuration Management Process
[IL_Gest_Conf].1 207 875 GReferenced in SCMP §2.1 & 2.9SDP 2000 Changes 1 208 645 A Per SQMP §1.2.1, a specific Software Development Plan is created for each upgrade campaignSMQP1 208 686 BSoftware Modification Quality Plan SCMP
[PGCL_SPINLINE 3]
1 208 878 D Software Configuration Management Plan for SPINLINE 3 Software Sub-assemblies Managed by CM ToolSDP 2001 Changes 1 208 908 A Per SQMP §1.2.1, a specific Software Development Plan is created for each upgrade campaign Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 PNot referenced in SCMP or SMQP, but applicable.[Gest_Doc_Col_Ref]8 303 638 BDocuments and reference files managementNot referenced in SCMP, but applicable.
Referenced in SMQP §6 & 10[IL_Ctrl_log_Ext]8 303 671 BSoftware Instruction: External software reception controlNot referenced in SCMP, but applicable.
Referenced in SMQP §9.2[For_Gcf]Configuration management tool training documentReferenced in SCMP §2.5, 2.6 Index of SPINLINE 3 Life Cycle Documents in Table 4b These documents contain the results of configuration identification for the elements of the OSS.
IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes1.1Purpose2Reference documents2Scope4Introduction3Management Activities5.1Management of SCM activityFigure provides an integrated view of configuration management activities in each life cycle phase4.2.12.1Organization:
The organizational context, both technical and managerial, within which the planned SCM activities are to be
implemented shall be described.SCMP8 307 209 B3.1Organization1.4Creation and Update of the SCMP3.2Responsibilities5.1Management of SCM activityFigure provides an integrated view of configuration management activities in each life cycle phase Configuration Management Process [IL_Gest_Conf].1 207 875 G6Duties and responsibilitiesReferenced in SCMP §3.3, 4.1, 5 & 6.
4.1 Note that SCMP, document 8 307 209
B, is a generic template that
establishes the framework for
completing the SCMP for plant-
specific application software that will
interface with the SPINLINE 3 generic platform software.
8 307 209 B4.2.22.2SCM responsibilities:
The allocation of SCM activities to organizational units shall be specified.
Table 4c. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation SCM management: (Who?) Identifies the responsibilities and authorities for accomplishing the planned activities SCMP SCMP Referenced in SCMP §3.3, 4.1, 5 & 6.
1 207 875 G
==
Introduction:==
Describes the Plan's purpose, scope of application, key terms, and references 1 Configuration Management Process [IL_Gest_Conf].
8 307 209 B 4.2SCMP8 307 209 B 2
IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4c. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation2Reference documents3.3Applicable policies, directives, and procedures: 6.4Principles of development organization Configuration Management Process [IL_Gest_Conf].1 207 875 G3Reference documentsReferenced in SCMP §3.3, 4.1, 5 & 6.
Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LReferenced in SCMP §3.3[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design ProcessReferenced in SCMP §3.3[DSS_PEV]8 303 197 KDefinition of the Change Management ProcessReferenced in SCMP §3.3 & 5.3[Reg_SLI]1 204 971 GOperating Rules of the Computer Center Referenced in SCMP §6.2SCMP8 307 209 B4SCM activities Configuration Management Process [IL_Gest_Conf].1 207 875 G5Process characteristicsReferenced in SCMP §3.3, 4.1, 5 & 6.4.1Configuration identification5.2Configuration identification 7.2Identify configurationAppendix 1Identification rules[Help_DIMENSIONS]CD-DIMDOC-012ChangeMan DIMENSIONS user guideReferenced in SCMP §2, 4.1, 4.3, 6.5[CLARISSE_SUD]8 002 800 CCLARISSE SSDE user guideReferenced in SCMP §4.1 & 6.
Referenced in SCMP §3.3, 4.1, 5 & 6.
Configuration Items are managed
according to the three levels of controlSCMP8 307 209 B 4.3.14.33 Configuration identification:
The Plan shall identify the project configuration items (CI) and their structures at each
project control point. The Plan shall state how each CI and its
versions are to be uniquely named and describe the activities
performed to define, track, store, and retrieve CIs.
8 307 209 B4.2.32.3Applicable policies, directives, and procedures:
Any external constraints placed on the Plan by other policies, directives, and procedures shall be identified. For each, its
impact and effect on the Plan shall be stated.
SCMP Configuration Management Process [IL_Gest_Conf].
1 207 875 G SCM activities:
(What?) Identifies all activities to be performed in applying to the project 3.1 IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4c. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation4.2Configuration control5.3Configuration control 6.3Change management Configuration Management Process [IL_Gest_Conf].1 207 875 G7.3Control changesReferenced in SCMP §3.3, 4.1, 5 & 6.[DSS_PEV]8 303 197 KDefinition of the Change Management ProcessReferenced in SCMP §3.3 & 5.3[Help_DIMENSIONS]CD-DIMDOC-012ChangeMan DIMENSIONS user guideReferenced in SCMP §3.3, 4.1, 5 & 6.4.3Configuration status accounting5.4Configuration status accounting6.3.4Configuration Tracking7.4Track the configuration7.6Performm configuration administration tasks[Help_DIMENSIONS]CD-DIMDOC-012ChangeMan DIMENSIONS user guideReferenced in SCMP §3.3, 4.1, 5 & 6.4.4Configuration audits and reviews5.1.2Management Review of SCM5.1.3Configuration Audit Support 5.1.4Configuration Review Support Configuration Management Process [IL_Gest_Conf].1 207 875 G7.5Check the configurationReferenced in SCMP §3.3, 4.1, 5 & 6.4.3.33.3 3.4 4.3.4 8 307 209 B SCMP Configuration audits and reviews:
Configuration audits determine to what extent the actual CI reflects the required physical and functional characteristics. Configuration reviews
are management tools for establishing a baseline.
Configuration control:
Activities include request, evaluate, approve or disapprove, and implement changes to baselined CIs. Changes encompass both error correction and
enhancement 8 307 209 B SCMP Configuration status accounting:
Configuration status accounting activities record and report the status of project
CIs 8 307 209 B 1 207 875 G Configuration Management Process [IL_Gest_Conf].
Referenced in SCMP §3.3, 4.1, 5 & 6.4.3.23.2 SCMP IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4c. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation4.5Interface control5.5Interface controlInterface Specifications1 207 110 JInterface Specifications - Operational System Software and Application Software Not referenced in SCMP Rolls-Royce Civil Nuclear SAS Quality Manual [PMQ]8 303 186 P7.4PurchasingReferenced in SCMP §2.4.5.2Interface Between Rolls-Royce and External Companies: Company_X4.6Subcontractor/Vendor Control5.5.2Interface Between Rolls-Royce and External Companies: Company_X5.6Subcontractor/Vendor Control
[X_RRCN_INT]
Referenced in SCMP §4.5.2 & 5.5.2.
Defined specifically for each
subcontractor and project SCMP8 307 209 B5SCM schedulesSDP8 307 211 B6ScheduleIt is Rolls-Royce practice to put schedule details in the SDP for each
project. SDP is referenced in §2 of the
SCMP.SDP8 307 211 B9Resource requirementsIt is Rolls-Royce practice to put resource details in the SDP for each
project. SDP is referenced in §2 of the
SCMP.SCMP8 307 209 B6.1SCM Tools[Help_DIMENSIONS]CD-DIMDOC-012ChangeMan DIMENSIONS user guideReferenced in SCMP §3.3, 4.1, 5 & 6.[CLARISSE_SUD]8 002 800 CCLARISSE SSDE user guideReferenced in SCMP §4.1 & 6.1.4Creation and Update of the SCMP7SCM plan maintenance3.6Subcontractor/vendor control:
Subcontractor/vendor control activities incorporate items developed outside the
project environment into the project CIs. Included are softwar e developed by contract and software acquired in its finished
form.4.3.53.5 SCMP 8 307 209 B SCMP 8 307 209 B Interface control:
Interface control activities coordinate changes to the project CIs with changes to interfacing items
outside the scope of the Plan. Hardware, system software an d support software, as well as other projects and deliverables, should be examined for potential interfacing effects on the
project.6SCM plan maintenance:
Identifies how the Plan will be kept current while in effectSCMP8 307 209 B 4.64.55SCM resources: (How?) Identifies tools and physical and human resources required for execution of the Plan 4.3.6 44.4SCM schedules: (When?) Identifies the required coordination of SCM activities with the other activities in the project IEEE 828 Section SCMP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 4c. Mapping SPINLINE 3 Application SCMP and Other Content to IEEE 828-1998 SCMP Content Guidance IEEE 828-1998 GuidanceWhere found in SPINLINE 3 software life cycle documentation1.2Relationship of this SCMP to the Plans Defined in BTP 7-141.3Definitions and Abbreviations6.5ArchivingSCMP8 307 209 B No counterpart in IEEE 828 Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes
[X_RRCN_INT]
Referenced in SCMP §4.5.2 & 5.5.2.
Defined specifically for each subcontractor and
project [Reg_SLI]1 204 971 GOperating Rules of the Computer Center Referenced in SCMP §6.2Interface Specifications1 207 110 JInterface Specifications - Operational System Software and Application
Software Configuration Management Process
[IL_Gest_Conf].1 207 875 GReferenced in SCMP §3.3, 4.1, 5 & 6.[CLARISSE_SUD]8 002 800 CCLARISSE SSDE user guideReferenced in SCMP §4.1 & 6.
Rolls-Royce Civil Nuclear SAS Quality Manual
[PMQ]8 303 186 PRolls-Royce Civil Nuclear SAS Quality Manual[DSS_PEV]8 303 197 KDefinition of the Change Management ProcessReferenced in SCMP §3.3 & 5.3 Control of software design (safety systems)
[PRO_Concept_log_C]
8 303 350 L[SQAP]8 307 208 B SPINLINE 3 Software Quality Assurance Plan - SQAP[SCMP]8 307 209 B SPINLINE 3 Software Configuration Management Plan - SCMP[SVVP]8 307 210 B SPINLINE 3 Software Verification and Validation Plan - SVVP[SDP]8 307 211 B SPINLINE 3 Software Development Plan - SDP[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design Process[Help_DIMENSIONS]CD-DIMDOC-012ChangeMan DIMENSIONS user guideReferenced in SCMP §3.3, 4.1, 5 & 6.
Index of SPINLINE 3 Life Cycle Documents in Table 4c IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotesSQP MC38 303 429 E1Purpose, scope and responsibilitiesThere is no separate SVVP. The SQP MC3, the SVTP, and software instruction 1 207 107 A, "Rules for
Verification and Validation of Software
Components," provided the needed
V&V process guidance for the MC3
project. A later revision of this
instruction is applicable to current
platform software V&V processes.1Project Overview2Description of the Project Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 G1.1PurposeSQP MC38 303 429 E2Reference documents and applicable documents Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 G1.2Reference documents and bibliographySVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 SQP MC38 303 429 E3Terminology, abbreviations and acronyms Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 G1.3Reference documents and bibliographySVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7.11Purpose:
The SVVP shall describe the purpose, goals, and scope of the software V&V effort, including waivers from this standard. The software project for which the Plan is being
written and the specific software processes and products
covered by the software V&V effort shall be identified.SDP MC31 207 102 A2Referenced documents:
The SVVP shall identify the compliance documents, documents referenced by the SVVP, and any supporting documents supplementing or implementing
the SVVP.7.33 7.2 Definitions:
The SVVP shall define or reference all terms used in the SVVP, including the criteria for classifying an anomaly as a critical anomaly. All abbreviations and notations used in the
SVVP shall be described.
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSQP MC38 303 429 E5.1Procedure used for software development Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SQP MC38 303 429 E4Specific organizational structure associated with the software project (project to create SPINLINE 3
)SDP MC31 207 102 A5Organization Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.33.4Cost and schedule management6Planning7.44V&V overview:
The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to
perform the software V&V.7.4.14.1Organization:
The SVVP shall describe the organization of the V&V effort, including the degree of independence required (See
Annex C of this standard). The SVVP shall describe the
relationship of the V&V processes to other processes such as
development, project management, quality assurance, and
configuration management. The SVVP shall describe the lines
of communication within the V&V effort, the authority for
resolving issues raised by V&V tasks, and the authority for
approving V&V products. Annex F provides an example
organizational relationship chart.7.4.24.2Master Schedule:
The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of V&V
tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality
assurance and configuration management). V&V tasks shall be
scheduled to be re-performed according to the task iteration
policy. If the life cycle used in the SVVP differs from the life
cycle model in this standard, this section shall describe how all
requirements of the standard are satisfied (e.g., by cross-
referencing to this standard).SDP MC31 207 102 A IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7.4.34.3Software integrity level scheme:
The SVVP shall describe the agreed upon software integrity level scheme established for the system and the mapping of the selected scheme to the
model used in this standard. The SVVP shall document the
assignment of software integrity levels to individual components (e.g., requirements, detailed functions, software modules, subsystems, or other software partitions), where there are
differing software integrity levels assigned within the program.
For each SVVP update, the assignment of software integrity
levels shall be reassessed to reflect changes that may occur in
the integrity levels as a result of architecture selection, detailed
design choices, code construction usage, or other development
activities.SQP MC38 303 429 E5.1Procedures used for software development The software to be produced belongs to
one of three categories:
- "standard" software
- "safety class" software
- HMI softwareSDP MC31 207 102 A4Resources to be deployedIt is Rolls-Royce practice to put resource information in the SDPSVTP1 207 146 G3Test resourcesSVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 SQP MC38 303 429 E4Specific Organizational Structure Associated With Software ProjectSDP MC31 207 102 A5OrganizationSQP MC38 303 429 E9Methods, Tools and Rules Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3 Software Guideline: Software V&V Team Training Plan
[IL_Plan_Form_VV]
1 208 210 B3Rules, Methods, ToolsRefers to SQP MC36Regression tests7.4.54.5Responsibilities:
The SVVP shall identify an overview of the organizational element(s) and responsibilities for V&V tasks.7.4.44.47.4.64.6 1 207 146 G Resources summary:
The SVVP shall summarize the V&V resources, including staffing, facilities, tools, finances, and special procedural requirements (e.g., security, access rights, and documentation control)
SVTP Tools, techniques, and methods:
The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in the
V&V process. Acquisition, training, support, and qualification
information for each tool, technology, and method shall be
included. Tools that insert code into the software shall be
verified and validated to the same rigor as the highest software
integrity level of the software. Tools that do not insert code shall
be verified and validated to assure that they meet their
operational requirements. If partitioning of tool functionscan be
demonstrated, only those functions that are used in the V&V
processes shall be verified to demonstrate that they perform
correctly for their intended use. The SVVP shall document the
metrics to be used by V&V, and shall describe how these
metrics support the V&V objectives.
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation5.1Procedure used for software development5.2Development process for software incorporating HMIs5.3Description of phasesIdentifies V&V tasks integrated into each phase Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.32Analysis of functions4Analysis of tests 5Coverage of tests7 to 10Analysis of Tests on Upgrade Software life cycle:
The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle phaseSQP MC38 303 429 E5.3Description of software life cycle phases
- 1) Specification phase
- 2) Preliminary Design Phase
- 3) Detailed design phase
- 4) Production phase (coding and unit
tests)
- 5) Integration phase
- 6) Validation phase
- 7) System testsSVTP1 207 146 G2.4Verification / validation sub-projectSVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3 8 303 429 E1 207 146 GSVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4
- 1) V&V Tasks 5.1 - 5.6 7.5.15V&V processes:
The SVVP shall identify V&V activities and tasks to be performed for each of the V&V processes described
in Clause 5 of this standard, and shall document those V&V
activities and tasks. The SVVP shall contain an overview of the
V&V activities and tasks for all software life cycle processes.
7.5 SVTP SQP MC3 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSQP MC38 303 429 E9Methods, tools and rules Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.33Rules, Methods, ToolsRefers to SQP MC36Regression testsSQP MC38 303 429 E5.3.1.1; 5.3.2.1; 5.3.3.1;
5.3.4.1;
5.3.5.1; 5.3.6.1 Phase inputs Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3 5.3.1.2;
5.3.2.2;
5.3.3.2;
5.3.4.2;
5.3.5.2; 5.3.6.2 Phase outputs 5.3.1.3;
5.3.2.3;
5.3.3.3;
5.3.4.3;
5.3.5.3; 5.3.6.3 Conditions for completing phase Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3 1 207 146 G
- 2) Methods and Procedures
- 4) Outputs
- 3) Inputs SVTP 8 303 429 E SQP MC3 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation3.4Cost and schedule management6PlanningSDP MC31 207 102 A4Resources to be deployedIt is Rolls-Royce practice to put resource details in the SDP for each project. SVTP1 207 146 G3Test resourcesSVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 7) Risks and AssumptionsSDP MC31 207 102 A8Risk assessmentSQP MC38 303 429 E4.3Duties of members of the software teamSDP MC31 207 102 A5Organization6.2Documents specific to each software item embedded on a unit Required V&V reports are (1) Software
Validation Test Analysis (SVTP) and (2)
Software Validation Test Reports (SVTR). See below for anomaly
resolution and reporting.9.1.6Software validation Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 GSVTR1 207 232 FSoftware Validation Test Report (SVTR
)- Operational System Software for
Safety Class Units. This constitutes the
V&V Final Report SVTR is referenced in SQP §8.2.6.
SVTR may be updated in connection
with the software modification.
It is Rolls-Royce practice to put schedule details in the SDP for each
project.
1 207 102 A
- 6) Resources
- 5) Schedule V&V reporting requirements:
V&V reporting shall consist of Task Reports, V&V Activity Summary Reports, Anomaly Reports, and the V&V Final Report.
6 8) Roles and Responsibilities SDP MC3 7.6 8 303 429 E SQP MC3 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3 Also see additional references in 7.1 - 7.5 below SES Department Quality Assurance Manual 8 303 1868.3Control of nonconforming productReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]SQP MC38 303 429 E8Management of changes to software and associated documentation7.7.27.2Task iteration policy:
The SVVP shall describe the criteria used to determine the extent to which a V&V task shall be
repeated when its input is changed or task procedure is
changed. These criteria may include assessments of change, software integrity level, and effects on budget, schedule, and
qualitySVTP1 207 146 G6Regression tests7.7.37.3Deviation policy:
The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information
required for deviations shall include task identification, rationale
, and effect on software quality. The SVVP shall identify the
authorities responsible for approving deviationsSQP MC38 303 429 E1.2.5Procedure in the event of failure to apply the SQP Anomaly resolution and reporting:
The SVVP shall describe the method of reporting and resolving anomalies, including the
criteria for reporting an anomaly, the anomaly report distribution
list, and the authority and time lines for resolving anomalies.
The section shall define the anomaly criticality levels.
Classification for software anomalies may be found in IEEE Std 1044-1993.7.7.17.17.77V&V administrative requirements:
Administrative V&V requirements shall describe anomaly resolution and reporting, task iteration policy, deviation policy, control procedures, and
standards, practices, and conventions IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation SES Department Quality Assurance Manual 8 303 1864.2QMS DocumentsReferenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]7Configuration Management 8Management of Changes to Software and Associated Documentation10.3Quality Monitoring Documentation11Reproduction, Protection, Delivery5.1Procedure used for software development9Methods, tools and rules General process for Software Development [IL_PROC_GEN]
1 208 079 A/B/C/D Not referenced in MC3 SQP, but applicable Control procedures
- The SVVP shall identify control procedures applied to the V&V effort. These procedures shall
describe how software products and V&V results shall be
configured, protected, and stored. These procedures may
describe quality assurance, configuration management, data
management, or other activities if they are not addressed by
other efforts. The SVVP shall describe how the V&V effort shall
comply with existing security provisions and how the validity of
V&V results shall be protected from unauthorized alterations.7.7.5Standards, practices, and conventions:
The SVVP shall identify the standards, practices, and conventions that govern
the performance of V&V tasks including internal organizational
standards, practices, and policies.7.7.47.4 SQP MC3 SQP MC3 8 303 429 E
8 303 429 E 7.5 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5a. Mapping SPINLINE 3 SQP MC3 and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation6.2Documents specific to each software item embedded on a unit. Required V&V reports are (1) Software Validation
Test Analysis (SVTP) and (2) Software
Validation Test Reports (SVTR)9.1.6Software validation Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 GSVTP is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 . SVTR1 207 232 FSVTR is referenced in SQP MC3 §5.3, 6.2, 9.1 & 10.2.2.4 V&V forms for the software components in configuration management.
These are V&V records produced in
accordance with the Plans.
None 8 7.8 8 303 429 E SQP MC3 No counterpart in IEEE 1012 V&V documentation requirements:
The SVVP shall define the purpose, format, and content of the test documents. A
description of the format for these test documents may be foun d in IEEE Std 829-1983]. If the V&V effort uses test
documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the
software V&V effort shall show a mapping of the proposed test
documentation and execution to the test items defined in this
standard. Test planning tasks defined in Table 1 shall be
implemented in the test plan, test design(s), test case(s), and
test procedure(s) documentation. The SVVP shall describe the
purpose, format, and content for the V&V test documents:
All V&V results and findings shall be documented in the V&V Final Report Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotesDevelopment of Safety Class Software1 206 076Referenced in SQP MC3 §9.3SDP MC31 207 102 ASoftware Development Plan Rules for Verification/Validation of Software Components 1 207 107 A/B/C Referenced in SQP MC3 §9.3SVTP1 207 146 GSoftware Validation Test Plan (SVTP) -
Operational System Software for Safety Class UnitsSVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System Software
for Safety Class Units General process for Software Development
[IL_PROC_GEN]
1 208 079 A/B/C/D Not referenced in MC3 SQP, but
applicable Software Guideline: Software V&V Team Training Plan [IL_Plan_Form_VV]
1 208 210 BSES Department Quality Assurance Manual 8 303 186Referenced in SQP MC3 §2.1 & 6.3.
Now known as Rolls-Royce Civil
Nuclear SAS Quality Manual [PQM],
document 8 303 186 PSQP MC38 303 429 ESoftware Quality Plan (SQP) - MC3 V&V forms for the software components in configuration management.
These are V&V records produced in
accordance with the Plans.
Index of SPINLINE 3 Life Cycle Documents in Table 5a IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotesSMQP1 208 686 B1.1 & 1.2Purpose of Document; Scope of Application There is no separate SVVP. The SMQP, SVTP and subordinate V&V
guidance documents perform the
function of the SVVP.
Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L1 & 2Objective & ScopeReferenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 D1 & 2Subject & ScopeReferenced in SMQP §8SVTP1 207 146 G1.1PurposeSVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification. 1.1Origin and objectives of the project 1.2Contract Clauses SMQP1 208 686 B2 A pplicable Documents and Reference Documents Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L5Reference documentsReferenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 D3Reference documentsReferenced in SMQP §8SVTP1 207 146 G1.2Reference documents and bibliography SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A1.3Technical reference documents Use of a separate SDP for each modification project is explained in
SQMP §1.2.1 Modification-specific SDPs for 2000 & 2001 modification projects7.22Referenced documents:
The SVVP shall identify the compliance documents, documents referenced by the
SVVP, and any supporting documents supplementing or
implementing the SVVP.
Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7.11Purpose:
The SVVP shall describe the purpose, goals, and scope of the software V&V effort, including waivers from this
standard. The software project for which the Plan is being
written and the specific software processes and products
covered by the software V&V effort shall be identified.
Use of a separate SDP for each
modification project is explained in
SQMP §1.2.1 1 208 645 A and 1 208 908 A IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B3Terminology and Abbreviations Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L4AbbreviationsReferenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 D4Glossary and terminologyReferenced in SMQP §8SVTP1 207 146 G1.3Reference documents and bibliography SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification. 8.2.4Unit tests of software components (includes Static Code Analysis &
Functional Validation)8.2.6Software Validation11.1.1Phase reviews Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.4Verification & Validation processReferenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 D7ApproachReferenced in SMQP §87.33Definitions:
The SVVP shall define or reference all terms used in the SVVP, including the criteria for classifying an
anomaly as a critical anomaly. All abbreviations and
notations used in the SVVP shall be described.7.44SMQP1 208 686 B V&V overview:
The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary
to perform the software V&V.
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B4Organization Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.2Parties involved and dutiesReferenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 D7ApproachReferenced in SMQP §8 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A5OrganizationUse of a separate SDP for each modification project is explained in SQMP §1.2.17Standard Development Cycle for Safety Class Software8Development of SPINLINE 3 type Safety Class Software6Schedule9.1Planning Master Schedule:
The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of
V&V tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality
assurance and configuration management). V&V tasks shall
be scheduled to be re-performed according to the task
iteration policy. If the life cycle used in the SVVP differs from
the life cycle model in this standard, this section shall
describe how all requirements of the standard are satisfied (e.g., by cross-referencing to this standard).7.4.24.2 Organization:
The SVVP shall describe the organization of the V&V effort, including the degree of independence
required (See Annex C of this standard). The SVVP shall
describe the relationship of the V&V processes to other
processes such as development, project management, quality assurance, and configuration management. The
SVVP shall describe the lines of communication within the
V&V effort, the authority for resolving issues raised by V&V
tasks, and the authorit y for approvin g V&V products. Annex F provides an example organizational relationship chart.7.4.14.18 303 350 LReferenced in SMQP §5.2 & 8 It is Rolls-Royce practice to put
schedule details in the SDP for each
project. Use of a separate SDP for
each modification project is explained
in SQMP §1.2.1 1 208 645 A and 1 208 908 A Control of software design (safety systems)
[PRO_Concept_log_C]
Modification-specific SDPs for 2000 & 2001 modification projects IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSMQP1 208 686 B1.2.2Software covered by the plan2ScopeIdentifies various international safety software classifications.3IntroductionDefines special case: Class B or C2 software7Standard Development Cycle for Safety Class Software Identifies the generic life cycle for safety software8Development of SPINLINE 3 type Safety Class Software Identifies the life cycle for SPINLINE 3 safety software Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A4MeansIt is Rolls-Royce practice to put resource details in the SDP for each project. Use of a separate SDP for
each modification project is explained
in SQMP §1.2.1SVTP1 207 146 G3Test resourcesSVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification. SMQP8 303 429 E4Organization Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.2Parties involved and dutiesReferenced in SMQP §5.2 & 8 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A5OrganizationUse of a separate SDP for each modification project is explained in
SQMP §1.2.1SVTP1 207 146 G2.4Verification / validation sub-projectSVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
Software integrity level scheme:
The SVVP shall describe the agreed upon software integrity level scheme established
for the system and the mapping of the selected scheme to
the model used in this standard. The SVVP shall document
the assignment of software integrity levels to individual
components (e.g., requirements, detailed functions, software modules, subsystems, or other software partitions), where
there are differing software integrity levels assigned within
the program. For each SVVP update, the assignment of
software integrity levels shall be reassessed to reflect
changes that may occur in the integrity levels as a result of
architecture selection, detailed design choices, code
construction usage, or other development activities.
Resources summary:
The SVVP shall summarize the V&V resources, including staffing, facilities, tools, finances, and special procedural requirements (e.g., security, access
rights, and documentation control) 7.4.5 4.3 Control of software design (safety systems)
[PRO_Concept_log_C]
8 303 350 L 7.4.3 4.57.4.44.4 Responsibilities:
The SVVP shall identify an overview of the organizational element(s) and responsibilities for V&V
tasks.
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation8Methods, Tools and Rules8.2Methods applied8.3Tools 8.4Rules8 to 13Documentation for each V&V activity is identified in the corresponding section and report templates are
provided in the appendices (Section
13)Aligns with IEEE 1012 SVVP Section
4.6 content
recommendation:
"Documents"10.1Tool used for code verification12.3Tool used for code validation8Specification verification9Design verification10Static verification of source code 11Change report 12Unit Test Validation 10Static verification of source code12.1Test analysis methods 12.2Devising the test program and conducting the tests10.2Verification reports Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L9Indicators of the Effectiveness of the Safety Class Software Design Process Software Guideline: Software V&V Team Training Plan [ILPlanFormVV]
1 208 210 C3Rules, Methods, Tools (refers to SQP MC3)6Regression tests 1 208 686 B SMQP 4.6 SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
Aligns with IEEE 1012 SVVP Section
4.6 content
recommendation:
"Hardware & software V&V tools" 1 207 146 G Aligns with IEEE 1012 SVVP Section
4.6 content
recommendation:
"Techniques, Methods" Tools, techniques, and methods:
The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in
the V&V process. Acquisition, training, support, and
qualification information for each tool, technology, and
method shall be included. Tools that insert code into the
software shall be verified and validated to the same rigor as
the highest software integrity level of the software. Tools that
do not insert code shall be verified and validated to assure
that they meet their operational requirements. If partitioning
of tool functions can be demonstrated, only those functions
that are used in the V&V processes shall be verified to
demonstrate that they perform correctly for their intended
use. The SVVP shall document the metrics to be used by
V&V, and shall describe how these metrics support the V&V
objectives.
Aligns with IEEE 1012 SVVP Section
4.6 content
recommendation:
"Operating
and test environment" Aligns with IEEE 1012 SVVP Section
4.6 content
recommendation:
"Metrics to be used by V&V" SVTP 7.4.6 Rules for Verification/Validation of Software Components 1 207 107 D IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation5.2SPINLINE 3 Software Modification Process8.2.4Unit tests of software components (includes Static Code Analysis &
Functional Validation)8.2.6Software Validation11.1.1Phase reviews Rules for Verification/Validation of Software Components1 207 107 D7ApproachReferenced in SMQP §82Analysis of functions4Analysis of tests5Coverage of tests7 to 10Analysis of Tests on UpgradeSMQP1 208 686 B SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
V&V processes:
The SVVP shall identify V&V activities and tasks to be performed for each of the V&V processes
described in Clause 5 of this standard, and shall document
those V&V activities and tasks. The SVVP shall contain an
overview of the V&V activities and tasks for all software life
cycle processes.
1 207 146 G SVTP7.55 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Software life cycle:
The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle phaseSMQP1 208 686 B5.2 SPINLINE 3 Software Modification Process Note: The focus of the SMQP is on
the maintenance phase of the
SPINLINE 3 software life cycle, which is addressed in §5.6 of IEEE 1012. Topics 1, 2, 3, 4 & 8 are
already addressed elsewhere in this
table. Refer to the SDP for Topics 5, 6&78Specification verification9Design verification10Static verification of source code 11Change report 12Unit Test ValidationSVTP1 207 146 G2.4Verification / validation sub-project8Specification verification 9Design verification10Static verification of source code 11Change report 12Unit Test Validation3Rules, Methods, Tools 6Regression tests3) InputsRules for Verification/Validation of Software Components1 207 107 D12.1.1Defining the inputs and outputs of the component to be tested Referenced in SMQP §84) OutputsRules for Verification/Validation of Software Components1 207 107 D12.1.1Defining the inputs and outputs of the component to be tested Referenced in SMQP §8
- 5) Schedule
- 6) Resources
- 7) Risks and Assumptions
- 8) Roles and ResponsibilitiesSee 4.5, above Referenced in SMQP §8 Rules for Verification/Validation of Software Components
- 1) V&V Tasks Referenced in SMQP §8 1 207 107 D Rules for Verification/Validation of Software Components 1 207 107 DSVTP1 207 146 G It is Rolls-Royce practice to put schedule, resource, and risk details in the SDP for each project.
5.1 - 5.6 7.5.1 2) Methods and Procedures IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation8.2.4Unit tests of software components (includes Static Code Analysis &
Functional Validation)8.2.6Software Validation11.1.1Phase reviews10.2Verification reports11Change report12.4Drawing up a validation reportAppendix 1Specification validation sheetAppendix 2Design verification report Appendix 3Code verification sheet Appendix 4Validation report sheet Appendix 5Description of testsSVTP1 207 146 GSoftware Validation Test Plan (SVTP) -Operational System Software for Safety Class Units SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification. SVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System
Software for Safety Class Units. This
constitutes the V&V Final Report SVTR is referenced in SMQP §8.2.6.
SVTR may be updated in connection
with the software modification. 7.77V&V administrative requirements:
Administrative V&V requirements shall describe anomaly resolution and
reporting, task iteration policy, deviation policy, control
procedures, and standards, practices, and conventions See below Rolls-Ro y ce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P8.3Control of nonconforming productNot referenced in SMQP, but applicable.
Rules for Verification/Validation of Software Components1 207 107 D11Change reportReferenced in SMQP §8 Configuration Management Process [IL_Gest_Conf].1 207 875 G7.3.1Record (Non-conformity report)Referenced in SMQP §7 6 1 208 686 B V&V reporting requirements:
V&V reporting shall consist of Task Reports, V&V Activity Summary Reports, Anomaly
Reports, and the V&V Final Report.1 207 107 DReferenced in SMQP §8 Rules for Verification/Validation of Software Components7.7.17.1Anomaly resolution and reporting:
The SVVP shall describe the method of reporting and resolving anomalies, including the criteria for reporting an anomaly, the anomaly
report distribution list, and the authority and time lines for
resolving anomalies. The section shall define the anomaly
criticality levels. Classification for software anomalies may
be found in IEEE Std 1044-1993.
7.6 SMQP IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7.7.27.2Task iteration policy:
The SVVP shall describe the criteria used to determine the extent to which a V&V task shall be repeated when its input is changed or task procedure is
changed. These criteria may include assessments of
change, software integrity level, and effects on budget, schedule, and qualitySVTP1 207 146 G6Regression testsSVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification.
7.7.3 Rolls-Ro y ce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P5.6Management ReviewNot referenced in SMQP, but applicable.
Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.2 and 6.4Referenced in SMQP §5.2 & 8 Rolls-Ro y ce Civil Nuclear SAS Quality Manual [PQM]8 303 186 P4.2QMS DocumentsNot referenced in SMQP, but applicable.7Configuration Management10Reproduction, Protection, Delivery11.3Quality-related records[IL_Ctrl_log_Ext]8 303 671 BNoSoftware Instruction: External software reception control Referenced in SMQP §9.2[PGCL_SPINLINE 3]1 208 878 D SPINLINE 3 Software Configuration Management Plan Referenced in SMQP §7. This SCMP
may be updated in connection with
the software modification. See SMQP
§5.2.Configuration Management Process [IL_Gest_Conf].1 207 875 G7.3Control ChangesReferenced in SMQP §7 Modification-specific SDPs for 2000 & 2001 modification projects 1 208 645 A and 1 208 908 A3.5Configuration management activities and changes Use of a separate SDP for each
modification project is explained in
SQMP §1.2.1 Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LSee 5.1 -
5.6, above Referenced in SMQP §5.2 & 8 Rules for Verification/Validation of Software Components1 207 107 DSee 5.1 -
5.6, above Referenced in SMQP §8 1 208 686 B SMQP7.3Deviation policy:
The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information
required for deviations shall include task identification, rationale, and effect on software quality. The SVVP shall
identify the authorities responsible for approving deviations7.7.57.5Standards, practices, and conventions:
The SVVP shall identify the standards, practices, and conventions that
govern the performance of V&V tasks including internal
organizational standards, practices, and policies.7.7.47.4Control procedures
- The SVVP shall identify control procedures applied to the V&V effort. These procedures shall
describe how software products and V&V results shall be
configured, protected, and stored. These procedures may
describe quality assurance, configuration management, data
management, or other activities if they are not addressed by
other efforts. The SVVP shall describe how the V&V effort
shall comply with existing security provisions and how the
validity of V&V results shall be protected from unauthorized
alterations.
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Section Title or Reference LocationNotes Table 5b. Mapping SPINLINE 3 SMQP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation8.2.4Unit tests of software components (includes Static Code Analysis &
Functional Validation)8.2.6Software Validation11.1.1Phase reviews Rules for Verification/Validation of Software Components1 207 107 DAppendices (Section 13)
Templates for verification and
validation report sheets Referenced in SMQP §8SVTP1 207 146 GSoftware Validation Test Plan (SVTP) -Operational System Software for
Safety Class Units SVTP is referenced in SMQP §8.2.6.
SVTP may be updated in connection
with the software modification. SVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System
Software for Safety Class Units. This
constitutes the V&V Final Report SVTR is referenced in SMQP §8.2.6.
SVTR may be updated in connection
with the software modification.
[PGCL_SPINLINE 3]
1 208 878 D SPINLINE 3 Software Configuration Management Plan Referenced in SMQP §7. This SCMP
may be updated in connection with
the software modification. See SMQP
§5.2.None SMQP No counterpart in IEEE 10127.88V&V documentation requirements:
The SVVP shall define the purpose, format, and content of the test documents. A
description of the format for these test documents may be
found in IEEE Std 829-1983]. If the V&V effort uses test
documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the software V&V effort shall show a mapping of the
proposed test documentation and execution to the test items
defined in this standard. Test plannin g tasks defined in Table 1 shall be implemented in the test plan, test design(s), test
case(s), and test procedure(s) documentation. The SVVP
shall describe the purpose, format, and content for the V&V
test documents:
A ll V&V results and findin g s shall be documented in the V&V Final Report 1 208 686 B Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes Rules for Verification/Validation of Software Components1 207 107 DReferenced in SMQP §8SVTP1 207 146 GSoftware Validation Test Plan (SVTP) -
Operational System Software for Safety Class UnitsSVTR1 207 232 FSoftware Validation Test Report (SVTR) - Operational System Software
for Safety Class Units Configuration Management Process [IL_Gest_Conf].1 207 875 GReferenced in SMQP §7SDP 2000 Changes 1 208 645 A Software Development Plan. Per SQMP §1.2.1, a specific Software
Development Plan is created for each
upgrade campaignSMQP1 208 686 BSoftware Modification Quality Plan SCMP
[PGCL_SPINLINE 3]1 208 878 DSPINLINE 3 Software Configuration Management Plan Referenced in SMQP §7. This SCMP
may be updated in connection with the
software modification. See SMQP
§5.2.SDP 2001 Changes 1 208 908 A Per SQMP §1.2.1, a specific Software Development Plan is created for each
upgrade campaign Rolls-Royce Civil Nuclear SAS Quality Manual [PQM]8 303 186 PNot referenced in SMQP, but applicable.
Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LReferenced in SMQP §5.2 & 8.1[IL_Ctrl_log_Ext]8 303 671 BSoftware Instruction: External software reception control Referenced in SMQP §9.2[PRO_Concept_log_NC]8 307 214 BNon safety software design processReferenced in SMQP §5.2 & 8.1 Index of SPINLINE 3 Life Cycle Documents in Table 5b IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes7.11Purpose:
The SVVP shall describe the purpose, goals, and scope of the software V&V effort, including waivers from this standard. The software project for which the Plan is being
written and the specific software processes and products
covered by the software V&V effort shall be identified.SVVP8 307 210 B1.1PurposeNote that SVVP, document 8 307 210 B, is a generic template that
establishes the framework for
completing the SVVP for plant-specific
application software that will interface
with the SPINLINE 3 generic platform software.7.22Referenced documents:
The SVVP shall identify the compliance documents, documents referenced by the SVVP, and any supporting documents supplementing or
implementing the SVVP.SVVP8 307 210 B2Reference Documents 7.33Definitions:
The SVVP shall define or reference all terms used in the SVVP, including the criteria for classifying an
anomaly as a critical anomaly. All abbreviations and notations
used in the SVVP shall be described.SVVP8 307 210 B1.3Definitions and Abbreviations3V&V OverviewFigures 3.2-1 & 3.2-1V&V Activities in the Software Life Cycle for Safety Software;
Software Life Cycle Process
for Nonsafety Software7.4.14.1Organization:
The SVVP shall describe the organization of the V&V effort, including the degree of independence
required (See Annex C of this standard). The SVVP shall
describe the relationship of the V&V processes to other
processes such as development, project management, qualit y assurance, and configuration management. The SVVP shall
describe the lines of communication within the V&V effort, the
authority for resolving issues raised by V&V tasks, and the
authority for approving V&V products. Annex F provides an
example organizational relationship chart.SVVP8 307 210 B3.1Organization Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7.44V&V overview:
The SVVP shall describe the organization, schedule, software integrity level scheme, resources, responsibilities, tools, techniques, and methods necessary to
perform the software V&V.
8 307 210 B SVVP IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSVVP8 307 210 B3.2Master ScheduleSDP8 307 211 B6ScheduleIt is Rolls-Royce practice to put schedule details in the SDP for each project. SDP is referenced in §2 of the
SVVP.7.4.34.3Software integrity level scheme:
The SVVP shall describe the agreed upon software integrity level scheme established
for the system and the mapping of the selected scheme to the
model used in this standard. The SVVP shall document the
assignment of software integrity levels to individual
components (e.g., requirements, detailed functions, software
modules, subsystems, or other software partitions), where
there are differing software integrity levels assigned within the
program. For each SVVP update, the assignment of software
integrity levels shall be reassessed to reflect changes that
may occur in the integrity levels as a result of architecture
selection, detailed design choices, code construction usage, or other development activities.SVVP8 307 210 B3.3Software Integrity Level SchemeSVVP8 307 210 B3.4Resources SummarySDP8 307 211 B9Resource requirementsIt is Rolls-Royce practice to put resource details in the SDP for each
project. SDP is referenced in §2 of the
SVVP.[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training Plan Referenced in SVVP §3.4 & 4.2.21.4Creation and Update of the SVVP3.5Responsibilities7.4.54.5 Master Schedule:
The SVVP shall describe the project life cycle and milestones. It shall summarize the schedule of V&V
tasks and task results as feedback to the development, organizational, and supporting processes (e.g., quality
assurance and configuration management). V&V tasks shall
be scheduled to be re-performed according to the task
iteration policy. If the life cycle used in the SVVP differs from
the life cycle model in this standard, this section shall
describe how all requirements of the standard are satisfied (e.g., by cross-referencing to this standard).7.4.24.2 Responsibilities:
The SVVP shall identify an overview of the organizational element(s) and responsibilities for V&V tasks.SVVP8 307 210 B7.4.44.4Resources summary:
The SVVP shall summarize the V&V resources, including staffing, facilities, tools, finances, and
special procedural requirements (e.g., security, access rights, and documentation control)
IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationSVVP8 307 210 B3.6Tools, techniques, and methods Software Guideline: Software Document Evaluation Process
[IL_Verif_Doc]1 207 947 EReferenced in SVVP §3.6, 4.3, 4.4 &
4.7[IL_Plan_Test]1 208 304 ASoftware Guideline: Software Test Plan Referenced in SVVP §3.6, 4.3, 4.4, 4.5, 4.6 & 4.7[IL_GD_ATVL]1 207 858 GSoftware Guideline : Guide for writing a SVTP Referenced in SVVP §3.6 & 4.3[IL_SCADE]1 208 250 CSoftware Guideline: SCADE Design Rules Referenced in SVVP §3.6 & 4.4[VERIF_CMU]3 002 593 AUser Manual for VERIF_CMU tool Referenced in SVVP §3.6 & 4.4[VERIF_ASA]3 002 594 AUser Manual for VERIF_ASA tool Referenced in SVVP §3.6 & 4.4[VERIF_COMP]3 003 769 AUser Manual for VERIF_COMP tool Referenced in SVVP §3.6 & 4.4 SCADE design evaluation checklists8 307 250 BChecklist for scade verification activities Referenced in SVVP §3.6 & 4.4[IL_Prog_C]1 208 954 CSoftware Guideline: C programming rules: synthesis Referenced in SVVP §3.6 & 4.5[IL_QAC]8 307 104 AGuideline : Source code static analysis process using QA-C Referenced in SVVP §3.6.[IL_GD_RTVL]1 207 859 ASoftware Guideline : Guide for writing a SVTR Referenced in SVVP §3.6 & 4.7[SP3_TST_BENCH]3 002 494 CUser Manual for SPINLINE 3 Test bench tool Referenced in SVVP §3.6.[IL_GD_TVL]1 208 535 ASoftware Guideline : Guide for writing a SVTPR Referenced in SVVP §3.6 & 4.3 Tools, techniques, and methods:
The SVVP shall describe documents, hardware and software V&V tools, techniques, methods, and operating and test environment to be used in
the V&V process. Acquisition, training, support, and
qualification information for each tool, technology, and metho d shall be included. Tools that insert code into the software shal l be verified and validated to the same rigor as the highest
software integrity level of the software. Tools that do not insert
code shall be verified and validated to assure that they meet
their operational requirements. If partitioning of tool functions
can be demonstrated, only those functions that are used in
the V&V processes shall be verified to demonstrate that they
perform correctly for their intended use. The SVVP shall
document the metrics to be used by V&V, and shall describe
how these metrics support the V&V objectives.7.4.64.6 IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation3.1.1V&V Tasks According to Equipment Technology3.1.2V&V Tasks According to Software Category Figures 3.2-1
& 3.2-3 V&V Activities in the Software Life Cycle for Safety Software;
Software Life Cycle Process
for Nonsafety Software4Life Cycle Verification and Validation Activity4.1Management of V&V Activity Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 L6.4Verification & validation process Referenced in SVVP §4.1.4.[Pro_Concept_Log_NC]8 307 214 BNon Safety Software Design Process Referenced in SVVP §4.1.4.5V&V processes:
The SVVP shall identify V&V activities and tasks to be performed for each of the V&V processes
described in Clause 5 of this standard, and shall document
those V&V activities and tasks. The SVVP shall contain an
overview of the V&V activities and tasks for all software life
cycle processes.
7.5SVVP8 307 210 B IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentationFigures 3.2-1 & 3.2-3V&V Activities in the Software Life Cycle for Safety Software; Software Life Cycle Process
for Nonsafety Software4.2 to 4.11* "Start of Software Project" Phase
- Requirements Phase
- Design Phase
- Coding Phase
- Test and Integration Phase
- Validation Phase
- "End of Software Project"
Phase
- Installation Phase
- Operation Phase
- Maintenance Phase It is Rolls-Royce practice to put
schedule, resource and risk analysis
details in the SDP for each project.[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training Plan Referenced in SVVP §3.4 & 4.2 Software Guideline: Software Document Evaluation Process
[IL_Verif_Doc]1 207 947 EReferenced in SVVP §3.6, 4.3, 4.4 &
4.7[IL_Plan_Test]1 208 304 ASoftware Guideline: Software Test Plan Referenced in SVVP §3.6, 4.3, 4.4, 4.5, 4.6 & 4.7[IL_GD_TVL]1 208 535 ASoftware Guideline : Guide for writing a SVTPR Referenced in SVVP §3.6 & 4.3[IL_GD_ATVL]1 207 858 GSoftware Guideline : Guide for writing a SVTP Referenced in SVVP §3.6 & 4.3[IL_SCADE]1 208 250 CSoftware Guideline: SCADE Design Rules Referenced in SVVP §3.6 & 4.4 SCADE design evaluation checklists8 307 250 BChecklist for scade verification activities Referenced in SVVP §3.6 & 4.47.5.15.1 - 5.6 8 307 210 B SVVP Software life cycle:
The SVVP shall include sections 5.1 through 5.6 for V&V activities and tasks in each life cycle
phase:
- 1) V&V Tasks
- 2) Methods and Procedures
- 3) Inputs
- 4) Outputs
- 5) Schedule
- 6) Resources
- 7) Risks and Assumptions
- 8) Roles and Responsibilities IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation[VERIF_CMU]3 002 593 AUser Manual for VERIF_CMU tool Referenced in SVVP §3.6 & 4.4[VERIF_ASA]3 002 594 AUser Manual for VERIF_ASA tool Referenced in SVVP §3.6 & 4.4[VERIF_COMP]3 003 769 AUser Manual for VERIF_COMP tool Referenced in SVVP §3.6 & 4.4[IL_Prog_C]1 208 954 CSoftware Guideline: C programming rules: synthesis Referenced in SVVP §3.6 & 4.5[IL_GD_RTVL]1 207 859 ASoftware Guideline : Guide for writing a SVTR Referenced in SVVP §3.6 & 4.7[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design Process Referenced in SVVP §4.1 & 4.87Standard development cycle for safety class software8Development of SPINLINE 3 type safety class software Rolls-Royce Civil Nuclear SA S Quality Manual [PMQ]8 303 186 PRolls-Royce Civil Nuclear SAS Quality Manual Referenced in SVVP §2 & 4.9SCMP8 307 209 BSoftware Verification and Validation Plan Referenced in SVVP §4.115V&V Reporting5.1Anomaly Reports5.2V&V Tasks Reports 5.3V&V Phase Summary Reports5.4V&V Final Report7.77V&V administrative requirements:
Administrative V&V requirements shall describe anomaly resolution and reporting, task iteration policy, deviation policy, control procedures, and
standards, practices, and conventionsSVVP8 307 210 B6V&V Administrative Procedures Referenced in SVVP §4.1 & 4.8 8 307 210 B V&V reporting requirements:
V&V reporting shall consist of Task Reports, V&V Activity Summary Reports, Anomaly
Reports, and the V&V Final Report.
6 7.6 Control of software design (safety systems)
[PRO_Concept_log_C]
8 303 350 L SVVP IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation Rolls-Royce Civil Nuclear SA S Quality Manual [PMQ]8 303 186 P8.3Control of nonconforming product Referenced in SVVP §2 & 4.95.1Anomaly Reports6.1Anomaly Reporting and Resolution7.7.27.2Task iteration policy:
The SVVP shall describe the criteria used to determine the extent to which a V&V task shall be repeated when its input is changed or task procedure is
changed. These criteria may include assessments of change, software integrity level, and effects on budget, schedule, and
qualitySVVP8 307 210 B6.2Task Iteration Policy7.7.37.3Deviation policy:
The SVVP shall describe the procedures and criteria used to deviate from the Plan. The information
required for deviations shall include task identification, rationale, and effect on software quality. The SVVP shall
identify the authorities responsible for approving deviationsSVVP8 307 210 B6.3Deviation Policy Rolls-Royce Civil Nuclear SA S Quality Manual [PMQ]8 303 186 P4.2QMS DocumentsReferenced in SVVP §2 & 4.9SVVP8 307 210 B6.4Configuration Control ProceduresSCMP8 307 209 B SPINLINE 3 Software Configuration Management
Plan - SCMP Referenced in SVVP §6.47.7.57.5Standards, practices, and conventions:
The SVVP shall identify the standards, practices, and conventions that govern
the performance of V&V tasks including internal
organizational standards, practices, and policies.SVVP8 307 210 B6.5Standards, Practices, and ConventionsSee SVVP §2 Control procedures
- The SVVP shall identify control procedures applied to the V&V effort. These procedures shall
describe how software products and V&V results shall be
configured, protected, and stored. These procedures may
describe quality assurance, configuration management, data
management, or other activities if they are not addressed by
other efforts. The SVVP shall describe how the V&V effort
shall comply with existing security provisions and how the
validity of V&V results shall be protected from unauthorized
alterations.
7.4 7.7.4 Anomaly resolution and reporting:
The SVVP shall describe the method of reporting and resolving anomalies, including the criteria for reporting an anomaly, the anomaly
report distribution list, and the authority and time lines for
resolving anomalies. The section shall define the anomaly
criticality levels. Classification for software anomalies may be
found in IEEE Std 1044-1993.
7.1 7.7.1SVVP8 307 210 B IEEE 1012 Section SVVP Section #Content Guidance Document (Shading means doc submitted to NRC)Doc #Section #Document or Section TitleNotes Table 5c. Mapping SPINLINE 3 Application SVVP and Other Content to IEEE 1012-1998 SVVP Content GuidanceIEEE 1012-1998 GuidanceWhere found in SPINLINE 3 generic platform software life cycle documentation7Documentation7.1Transverse V&V Documents* Software V&V Plan (SVVP)
- Network Detailed Design (NDD) V&V report
- V&V Final Report (VVFR)7.2Software Product V&V Documents for Safety
Software* Software Validation Test Plan (SVTP)
- Software Validation Test Report (SVTR)
- Verification reports
- Anomaly reports7.3Software Product V&V Documents for Nonsafety
Software* Software Integration Test Plan and
Report (SITPR)
- Software Validation Test Plan and
Report (SVTPR)
- Verification reports
- Anomaly reports1.2Relationship of this SVVP to the Plans Defined in BTP 7-143.7Risk Management8V&V documentation requirements:
The SVVP shall define the purpose, format, and content of the test documents. A
description of the format for these test documents may be
found in IEEE Std 829-1983]. If the V&V effort uses test
documentation or test types (e.g., component, integration, system, acceptance) different from those in this standard, the
software V&V effort shall show a mapping of the proposed
test documentation and execution to the test items defined in
this standard. Test planning tasks defined in Table 1 shall be
implemented in the test plan, test design(s), test case(s), and
test procedure(s) documentation. The SVVP shall describe
the purpose, format, and content for the V&V test documents:
All V&V results and findings shall be documented in the V&V Final Report 7.8 8 307 210 B SVVP No counterpart in IEEE 1012 8 307 210 B SVVP Document (Shading means doc submitted to NRC)Doc #Document or Section TitleNotes[IL_GD_ATVL]1 207 858 GSoftware Guideline : Guide for writing a SVTPReferenced in SVVP §3.6 & 4.3[IL_GD_RTVL]1 207 859 ASoftware Guideline : Guide for writing a SVTRReferenced in SVVP §3.6 & 4.7 Software Guideline: Software Document Evaluation Process [IL_Verif_Doc]1 207 947 EReferenced in SVVP §3.6, 4.3, 4.4 &
4.7[IL_Plan_Form_VV]1 208 210 CSoftware Guideline: Software V&V Team Training PlanReferenced in SVVP §3.4 & 4.2[IL_SCADE]1 208 250 CSoftware Guideline: SCADE Design RulesReferenced in SVVP §3.6 & 4.4[IL_Plan_Test]1 208 304 ASoftware Guideline: Software Test PlanReferenced in SVVP §3.6 & 4.3[IL_GD_TVL]1 208 535 ASoftware Guideline : Guide for writing a SVTPRReferenced in SVVP §3.6 & 4.3[SMQP]1 208 686 BSoftware Modification Quality PlanReferenced in SVVP §4.11[IL_Prog_C]1 208 954 CSoftware Guideline: C programming rules: synthesisReferenced in SVVP §3.6 & 4.5[SP3_TST_BENCH]3 002 494 C User Manual for SPINLINE 3 Test bench tool Referenced in SVVP §3.6.[VERIF_CMU]3 002 593 AUser Manual for VERIF_CMU toolReferenced in SVVP §3.6 & 4.4[VERIF_ASA]3 002 594 AUser Manual for VERIF_ASA toolReferenced in SVVP §3.6 & 4.4[VERIF_COMP]3 003 769 AUser Manual for VERIF_COMP toolReferenced in SVVP §3.6 & 4.4 Rolls-Royce Civil Nuclear SAS Quality Manual
[PMQ]8 303 186 PRolls-Royce Civil Nuclear SAS Quality ManualReferenced in SVVP §2 & 4.9 Control of software design (safety systems)
[PRO_Concept_log_C]8 303 350 LReferenced in SVVP §4.1 & 4.8[IL_QAC]8 307 104 AGuideline : Source code static analysis process using QA-CReferenced in SVVP §3.6.[SQAP]8 307 208 B SPINLINE 3 Software Quality Assurance Plan - SQAP[SCMP]8 307 209 B SPINLINE 3 Software Configuration Management Plan -
SCMP Referenced in SVVP §6.4[SVVP]8 307 210 B SPINLINE 3 Software Verification and Validation Plan -
SVVP[SDP]8 307 211 B SPINLINE 3 Software Development Plan - SDP[PRO_Concept_log_NC]8 307 214 BNon Safety Software Design ProcessSCADE design evaluation checklists8 307 250 BChecklist for scade verification activitiesReferenced in SVVP §3.6 & 4.4 Index of SPINLINE 3 Life C y cle Documents in Table 5c