ML101050349
| ML101050349 | |
| Person / Time | |
|---|---|
| Site: | 05000083 |
| Issue date: | 04/12/2010 |
| From: | Dugan E Univ of Florida |
| To: | Office of Nuclear Reactor Regulation |
| References | |
| UFTR-QA1-03 | |
| Download: ML101050349 (40) | |
Text
UF/NRE ProjectID: QA-1 UFTR QUALITY ASSURANCE DOCUMENT Revision 0 Copy 1 Page 1 of 40 Project
Title:
UFTR DIGITAL CONTROL SYSTEM UPGRADE' UFTR-QA1-03, Software Verification and Validation Plan (SVVP)
Prepared by,
- Reviewed by, Prof. Edward Dugan Dr. Gabriel Ghita
...................... (Signature) .......... (Signature)
Date: Date:..0. 1z Approved by, Prof. Alireza Haghighat J./. /. (Signature)
Date: ..Lll2/ -I-!
Preparedby Reviewed by QA-I, UFTR-QA 1-03 UFINRE Name: Name: Revision 0 Copy 1 UFTR Date: Initials: Date : Initials: Vol. 1 Page 2 of 40 THE DISTRIBUTIONLIST No. Name Affiliation Signature Date 1.
2.
3.
4.
5.
6.
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy 1 UFTR Date: Initials: Date: Initials: Vol. 1 Page 3 of 40 THE LIST OF THE REVISED PAGES Revision no. Reviewed by Approved by The Modified Pages Date
-I- I +
Preparedby Reviewed by QA-I, UFTR-QAJ-03 UFINRE UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Vol. I Page 4 of 40 TABLE OF CONTENTS
- 1. Purpose .................................................................................................................................... 6
- 2. Referenced docum ents ..................................................................................................... 7 2.1 U FTR D ocum ents ...................................................................................................... 7 2.2 Industry Standards ................................................................................................... 7 2.3 N RC D ocum ents ........................................................................................................ 7
- 3. D efinitions and A cronym s ................................................................................................. 8 3.1 D efinitions ....................................................................................................................... 8 3.2 A cronym s ...................................................................................................................... 12
- 4. V & V overview ...................................................................................................................... 14 4.1 Organization ............................................................................................................. 14 4.1.1 Project M anagem ent ................................................................................... 14 4.1.2 System Design and Analysis Group .......................................................... 15 4.1.3 Softw are D evelopm ent G roup .................................................................... 15 4.1.4 H ardw are and Installation G roup .............................................................. 15 4.1.5 Q uality Assurance (Q A ) Group .................................................................. 15 4.1.6 Independent Verification & Validation (IV&V) Group ........................... 15 4.2 M aster Schedule ...................................................................................................... .. 17 4.3 R esources sum m ary ................................................................................................. 18 4.4 IV & V Responsibilities ............................................................................................ 18 4.5 Tools, techniques, and m ethods .............................................................................. 19 4.5.1 Review s and Inspections .............................................................................. 20 4.5.2 Sim ulation and Acceptance Testing ........................................................... 20 4.5.3 Formal Checks of the Software Specification (supported by SPACE) ....... 21 4.5.4 Load Evaluations (supported by SPACE) ....................... 21 4.5.5 Software Identification (supported by SPACE) ........................................ 21 4.5.6 Softw are Functional Testing ....................................................................... 21 4.5.7 Acceptance T esting ..................................................................................... 22 4.5.8 Regression T esting ....................................................................................... 22 4.5.9 M etrics .......................................................................................................... 22
- 5. The V & V Processes ........................................................................................................ 24
5.1 Process
M anagem ent ............................................................................................... 24 5.1.1 A ctivity: M anagem ent of V & V .................................................................. 24
5.2 Process
Developm ent ............................................................................................... 25
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UF/NRE Name: Name: Revision 0 Copy I Date: Initials: Date : Initials: VoL. 1 Page 5 of 40
5.2.1 Activity
Concept Phase of V&V ................................................................ 25
5.2.2 Activity
Requirements Phase of V&V ...................................................... 27
5.2.3 Activity
Design Phase of V&V .............................. 29
5.2.4 Activity
Implementation Phase of V&V ................................................. 31
5.2.5 Activity
Test Phase of V&V ....................................................................... 33
5.2.6 Activity
Installation and Checkout Phase of V&V ................................... 34
5.3 Process
Operation and Maintenance .................................................................... 34
- 6. V&V Reporting Requirements ..................................................................................... 35 6.1 Summary of Concept phase of V&V activity Report (SCR) Outline .................. 35 6.2 Summary of Requirements phase of V&V activity Report (SRR) Outline ........ 35 6.3 Summary of Design phase of V&V activity Report (SDR) Outline ..................... 36 6.4 Summary of Implementation phase of V&V activity Report (SIR) Outline .......... 36 6.5 Summary of Test phase of V&V activity Report (STR) Outline ......................... 37 6.6 V&V Final Report Outline .......................................................................................... 37
- 7. V&V Administration Requirements .................................................................................. 38 7.1 Anomaly Resolution and Reporting ...................................................................... 38 7.2 Task Iteration Policy ............................................................................................... 38 7.3 D eviation Policy ........................................................................................................ 39 7.4 Control Procedures ................................................................................................. 39 7.5 Standards, Practices, and Conventions .................................................................. 39
- 8. V&V Documentation requirements .............................................................................. 40
Preparedby Reviewed by QA-I, UFTR-QA 1-03 UFINRE Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: VoL 1 Page 6 of 40
- 1. Purpose A Software Verification and Validation Plan (SVVP) is required for the safety system Application Software in accordance with IEEE 1012, Standard for Software Verification and Validation, /11/, and UFTR-QA1-QAPP, "Quality Assurance Project Plan (QAPP)," /3/.
This document establishes the SVVP for the UFTR Digital Control Systems Upgrade project and will specify and describe the Verification and Validation (V&V) activities that need to be performed for this project.
The SVVP specifies activities to be performed during the software management and development processes that will demonstrate high levels of quality and confidence in the software being developed and throughout the software life cycle. The V&V activities are the reviews, inspections, analyses, and tests conducted by competent individual(s) or group(s) to provide traceable documented evidence that a high level of quality and a low level of risk have been achieved.
This document is applicable to software developed for the University of Florida Training Reactor (UFTR) TELEPERM XS (TXS) Reactor Protection System (RPS) and its supporting applications. This SVVP does not apply to the TXS operating system software itself.
Development of TXS operating system software is performed under the guidance of the AREVA GmbH V&V plan and is out of the scope of this SVVP.
Preparedby Reviewed by QA-I, UFTR-QAI-03 UF/NRE Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. ) Page 7 of 40
- 2. Referenced documents 2.1 UFT R Documents
/1/ UFTR-QAP, "Quality Assurance Program (QAP)"
/2/ UFTR-QA1 -P, "Conduct of Quality Assurance"
/3/ UFTR-QA1 -QAPP, "Quality Assurance Project Plan (QAPP)"
/4/ UFTR-QA1 -01, "Software Quality Assurance Plan (SQAP)"
/5/ UFTR-QA1 -02, "Software Configuration Management Plan (SCMP)"
/6/ UFTR-QA1 -06.1, "Software Test-SIVAT Plan"
/7/ UFTR-QA1 -06.2, "Factory Acceptance Test (FAT) Plan"
/8/ UFTR-QA1 -10, "Software Training Plan"
/9/ UFTR-QAI -100, "Functional Requirements Specification (FRS)"
2.2 Industry Standards
/10/ IEEE Std 610.12-1990, "IEEE Standard Glossary of Software Engineering Terminology"
/11/ IEEE 1012-1998, "IEEE Standard for Software Verification and Validation"
/12/ IEEE 1028-1997, "IEEE Standard for Software Review" 2.3 NRC Documents
/13/ Regulatory Guide 1.168, Rev. 1, February 2004, "Verification, Validation, Reviews, and Audits for Digital Computer Software Used in Safety Systems of Nuclear Power Plants"
/14/ Digital Instrumentation and Controls Interim Staff Guidance (DI&C-ISG-06),
2009
UFINRE Preparedby Reviewed by QA-1, UFTR-QA1-03 Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. 1 Page 8 of 40
- 3. Definitions and Acronyms 3.1 Definitions This section defines some terms that are associated with the development of TXS related projects.
Acceptance Testing, [IEEE Std 1012-1998, /11/]/:
Testing conducted in an operational environment to determine whether a system satisfies its acceptance criteria (i.e., initial requirements and current needs of its user) and to enable the customer to determine whether to accept the system.
Anomaly, [IEEE Std 1012-1998, /11/]/:
Anything observed in the documentation or operation of software that deviates from expectations based on previously verified software products or reference documents.
Application Software The Application Software reflects the plant specific functionality of the TXS Instrumentation and Control (I&C) system. It is documented and generated by the Engineering SPACE Tool. The platform system software uses this configuration data in order to carry out the application specific functionality of the I&C system.
Audit An independent examination of a work product or a set of work products to assess its compliance with specifications, standards, contractual agreements, or other criteria.
CPUload A software that estimates the CPU load values from the specification data in the SPACE project database. The complete specification is always analyzed and an output is always created for the whole SPACE database.
Criticality, [IEEE Std 1012-1998, /11/]/:
A subjective description of the intended use and application of the system. Software criticality properties may include safety, security, complexity, reliability, performance, or other characteristics.
Discrepancies During the software development life cycle, any difference or perceived difference discovered by various organizations in the later documents or code with the earlier requirements found in the customer's specification, the Functional Requirements Specification (FRS) or the Software Requirements Specification (SRS). These discrepancies are initially documented on the open item list and are evaluated for further action.
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UFINRE UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. 1. Page 9 of 40 FunBase A design tool that administrates the naming of software modules, parameters, signals, data tables and other entities in the design so that each entity is uniquely and consistently named and properly connected in the Application Software.
Functional Requirement, [IEEE Std 610.12-1990, /10/]/:
A requirement that specifies a function that a system or system component must be able to perform.
Functional Requirements Specification (FRS)
A document provided by the customer or his agent that describes in detail the functions of the system to be installed new or replaced. The FRS will include both hardware and software functions of the system. This document can be called by a different name, but whatever document is provided by the customer to meet this function will fit this definition.
Functional Specification, [IEEE Std 610.12-1990,/10/]/:
A document that specifies the functions that a system or component must perform. Often part of a requirements specification.
Functional Testing, [IEEE Std 610.12-1990, /10/]/: "
(1) Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.
(2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements.
Independent Design Review A detailed line by line technical verification of a document by a competent individual, other than the preparer. The independence and technical competence of the reviewer is certified by the cognizant technical manager.
Independent Verification and Validation (IV&V) Group, [IEEE Std 1012-1998,
/11/]/..
An organization (Group) which performs V&V processes with a specified degree of technical, managerial, and financial independence from the development organization..
Integration Testing, [IEEE Std 610.12-1990, /10/]/:
Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them.
Netload Determines the expected loading for the network connections. For this, netloadanalyzes the data in the "Tables of the code generators" in the SPACE project database. These are
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Vol. 1 Page 10 of 40 used by the function diagram group (fdg) code generators and runtime environment (rte) to- store information on the generated code. The prerequisite for using netload is that source code has been previously generated from the specification.
Open Item Any item that constitutes an error or anomaly from the required status or condition of a properly completed project. Each Open Item is given an identifier that is unique to the project and unit as well as a record in a database. The entry contains information to track the life cycle of the item from initiation to final resolution.
Reflist A software that creates Cyclic Redundancy Check (CRC) sums recursively for the subdirectories and files within a directory and outputs them in a list, including the date of the last change for the file. This method is used for identification of the TXS system software, for project specific additions, for the application software implemented on an engineering platform (engineering workstation), and for software downloaded into the I&C system.
Review, [IEEE Std 610.12-1990, /10/]/:
A process or meeting during which a software product is presented to project personnel, managers, or users for comment or approval.
Scanmic The scanmic is a TXS software authentication tool. It analyzes the software configuration of loadable code (called MIC files). The scanmic is used to read the version strings of the Application Software components contained in a loadable MIC file from the MIC file itself, and calculate the CRC checksum for each software segment in the MIC file as well as the CRC checksum for the entire MIC file. This information can be output to a list which serves to document the generated software version. Differences in the software configuration between the old version and the new version can be determined from these lists and then verified.
SImulation Based VAlidation Tool (SIVAT)
SWAT allows the functionality of the I&C system engineered in SPACE to be tested via simulation. Simulation is based on the code generated by thefdg code generator and the rte code generator. This enables engineering errors to be detected at an early stage. The test verifies that the requirements have been translated without errors into function diagrams and that the software automatically generated from these function diagrams provides the functionality required in terms of I/O response. The tests confirm the interface to the rte, use of correct function blocks, and verification that the function blocks are correctly connected and parameterized. The failure of I/O modules, processing modules, and data messages can be simulated. These tests use scripts that define the input
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. 1 Page 11 of 40 signals of the I&C system and the simulation run. The test results are recorded in log files and plots for further evaluation. Process modules can also be linked into the simulator to perform closed-loop tests.
Software Component Software Components are a constituent element of a software system. For TXS Application Software, this usually means the modules, submodules, or I&C functions as described in the SRS. A specific collection of Software Components is assembled to form a Software System.
Software Engineering Refers to defining the TXS application software in the SPACE system. It is distinguished from traditional software development by the fact that the software is described by graphical means, automatically generating code.
Software Requirements Software requirements are those that must be met by the software system to satisfy a contract, standard, specification, procedure, or user need. The set of all software requirements form the basis for subsequent development of the software. Requirements include, but are not limited to: identification of needed software functions, the inputs, processes, and outputs required for each function, the design constraints and attributes of the software, performance requirements, interface requirements, and development standards. Each requirement is defined such that its achievement can be verified and validated objectively.
Software Requirements Specification (SRS), [IEEE Std 1012-1998, /11/]/:
Documentation of the essential requirements (i.e., functions, performance, design constraints, and attributes) of the software and its external interfaces. The software requirements are derived from the system specification.
Software Verification and Validation Report (SVVR), [IEEE Std 1012-1998, /11/]/:
Documentation of V&V results and software quality assessments, e.g. SCR, SRR, SDR, SIR, STR, SPecification And Coding Environment (SPACE)
The SPACE engineering system comprises tools used for the engineering and maintenance of the TXS I&C software. In this context, engineering refers to the overall process of creating and testing the Application Software:
- Specification of the I&C functions and hardware topology
" Automatic code generation
- Software authentication, using reflist and scanmic
- Software loading
UFINRE Preparedby Reviewed by QA-1, UFTR-QAI-03 UFTR Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Vol. 1 Page 12 of 40
- Load analysis tool
" Database administration System/Software life cycle The system/software life cycle encompasses all the activities related to the realization and the maintenance of a piece of system/software product. The UFTR system/software life cycle includes pre-application stage, initial application phase, continued review and audit stage, and an implementation and installation stage.
System Testing, [IEEE Std 1012-1998, /11/]/:
The activity of testing an integrated hardware and software system that verifies and validates whether the system meets its original objective.
Validation, [IEEE Std 1012-1998, /11/]/:
The process of evaluating a system or component at the end of the development process to determine whether it satisfies specified requirements.
Verification, [IEEE Std 1012-1998, /11/]/:
The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.
Verification and Validation (V&V), [IEEE Std 610.12-1990, /10/]/:
The process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements.
3.2 Acronyms CR Condition Report CRC Cyclic Redundancy Check FAT Factory Acceptance Test fdg function diagram group FRS Functional Requirements Specification GW Gateway GSM Graphic Service Monitor HRS Hardware Requirements Specification I&C Instrumentation and Controls IEEE Institute of Electrical and Electronic Engineers I/O Input/Output IV&V Independent Verification and Validation NRC Nuclear Regulatory Commission NL-A AREVA NP Inc. (US)
UFNRE Preparedby Reviewed by QA-I, UFTR-QAI-03 Name: Name: Revision 0 Copy 1 UFTR Date : Initials: Date : Initials: VoL 1 Page 13 of 40 NL-G AREVA NP GmbH (Germany)
QA Quality Assurance QAP Quality Assurance Program QAPP Quality Assurance Project Plan QDS Qualified Display System RPS Reactor Protection System rte runtime environment SCMP Software Configuration Management Plan SCR Summary of Concept phase of V&V activity Report SDD Software Design Description SDR Summary of Design phase of V&V activity Report SIR Summary of Implementation phase of V&V activity Report SIVAT SImulation Based VAlidation Tool SQAP Software Quality Assurance Plan SPACE SPecification And Coding Environment SRR Summary of Requirements phase of V&V activity Report SRS Software Requirements Specification STR Summary of Test phase of V&V activity Report SVVP Software Verification and Validation Plan SVVR Software Verification and Validation Report TXS TELEPERM XS UFTR University of Florida Training Reactor V&V Verification and Validation
Preparedby Reviewed by QA-I, UFTR-QAI-03 UF/NRE UFTRI Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: VoL 1 Page 14 of 40
- 4. V&V overview This section is an overview of the UFTR Digital Control System Upgrade Project V&V activities. Section 4.1 details the organization and responsibilities of the personnel, showing the independence of the Independent V&V (IV&V) Group within the Project Organization.
The following sections contain the Master Schedule, the resources involved, and the responsibilities related to the V&V activities.
The methods used by the IV&V Group consist of Design Review, Inspection, Walkthrough, Software Validation Testing and System Testing.
The processes described in this plan comply with IEEE 1012-1998, /11/, and IEEE 1028-1997, /12/, as endorsed by the NRC Regulatory Guide 1.168, /13/.
4.1 Organization Figure 1 identifies the organizational groups for the project as described in the UFTR QAPP, /3/.
Figure 1. Organizational Chart of UFTR Digital Control System Upgrade Project The following sections describe the responsibilities of the organizational components.
4.1.1 Project Management The Project Management (Project Manager and the Project Coordinator) is responsible for defining the project and maintaining the Master Schedule (Section 4.2). Project Management controls the overall process, including quality level, costs and schedule, as well as making all decisions relevant to project activities. The Project Management provides interfacing between the UFTR Digital Control Systems Upgrade Project Support Groups.
The Project Manager ensures that the design, V&V, and QA activities on the project are conducted in accordance with the QAPP, /3/. He processes and resolves any discrepancies and other Open Items that are found during reviews and tests.
The Project Coordinator is responsible for software planning, technical development, integration, installation, and manufacturing testing of the TXS application software, ensuring that the provisions of the QAPP, /3/, the supporting plans, and the implementing procedures are carried out in each of the phases of software development as specified. The Project Coordinator is responsible for correcting design errors and making software changes associated with discrepancies and other anomalies identified by V&V activities.
UFINRE Preparedby Reviewed by QA-1, UFTR-QAI-03 Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: VoL 1 Page 15 of 40 4.1.2 System Design and Analysis Group The System Design and Analysis Group is responsible for the basic (conceptual) system design as well as for the definition of the system requirements specifications presented in the UFTR "Functional Requirements Specification (FRS)," /9/.
The System Design and Analysis Group is responsible for the preparation of the system design related analysis technical documents and collaborates with the Software Development Group for preparing the software design and the related documents.
System Design and Analysis reports the progress of the development to the Project Manager.
4.1.3 Software Development Group The Software Development Group is responsible for the complete software design and software code generation using the TXS engineering tool SPACE. The TXS software simulation tool SIVAT will be used for software debugging.
The group is responsible for preparation of the SRS, related analyses, Software Design Description (SDD), and other software products. AREVA NP has the task of formal verification of incoming functional requirements.
The Software Development Group reports to the Project Manager.
4.1.4 Hardware and Installation Group The Hardware and Installation Group is responsible for the integration of hardware and software in the test field and for the execution of Factory Acceptance Tests (FAT).
The Hardware and Installation Group is responsible for installing the TXS components and hardware accessories, for installing the specified operating systems and other AREVA NP GmbH platform software, and for installing the completed application Software onto the TXS processors. The Hardware and Installation Group is responsible also for performing the hardware checkouts.
The Hardware and Installation Group reports to the Project Manager.
4.1.5 Quality Assurance (QA) Group The QA Group verifies that the implementation of QA requirements is in accordance with the UFTR Quality Assurance Program (QAP), /1/. For further information, consult with the QAPP, /3/.
4.1.6 Independent Verification & Validation (IV&V) Group The 1V&V Group is independent from the design Group and has sufficient resources and authority to ensure V&V activities are not adversely affected by commercial and schedule pressures.
UFINRE Preparedby Reviewed by QA-I, UFTR-QAI-03 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date : Initials: Vol. 1 Page 16 of 40 The 1V&V personnel shall not participate in any design preparation activities; however, they can perform independent design review for the System Design & Analysis and Software Development Groups. The IV&V Group Lead has a dotted line to the QA group. From a project management perspective, the IV&V Group is considered part of the overall project team.
The IV&V Group is responsible for preparation of the SIVAT, /6/, and FAT, /7/, validation test documents. The Group is also responsible for the Execution of the SWAT Tests. The IV&V Group may get assistance from the Design & Analysis Group, Software Development Group, and Hardware and Installation Group for the preparation of validation test specifications, procedures, and reports and the performance of the test tasks; however, these support personnel shall work under the supervision of the IV&V Group. These support personnel shall not develop nor perform independent review of software test documents for design work they prepared.
The IV&V Group is responsible for V&V Activities as described in Section
- 5. The IV&V Group performs V&V reviews and optional tests and may participate, as an observer, in design reviews. The 1V&V Group reviews and approves all the products from V&V activities, including SIVAT and FAT test plans, specifications, procedures, and reports. The IV&V Lead may delegate the approval authority to another member of the IV&V team.
The IV&V Group is also responsible for the organization of the V&V Activities and for developing the SVVP. The IV&V personnel shall have the following qualifications:
" The IV&V personnel shall be trained on the provisions of the UFTR-QAI-10, "Software Training Plan," /8/, and shall be sufficiently proficient in software engineering to ensure that software V&V activities are adequately implemented and are knowledgeable regarding nuclear safety applications. In addition, the IV&V personnel shall be familiar with the design principles and features of the TXS system.
" For verification of the SPACE Function Diagrams, the IV&V personnel shall be trained in the use and the output of this tool.
" For generation and verification of the SIVAT documents, the IV&V personnel shall be trained in the use and the output of this tool.
" For the validation processes, including testing, the personnel shall be familiar with acceptance test procedures, predicting and evaluating test results, and the form of the generated outputs from the TXS System.
- The IV&V verifier shall perform the independent design review for the System & Analysis and Software Development Groups.
" The IV&V Group is organized independently of Software Design &
Analysis, Software Development, and Hardware & Installation Groups.
The IV&V team members shall not participate in any design preparation
UFINRE Preparedby Reviewed by QA-I, UFTR-QA 1-03 UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. 1 Page 17 of 40 activities. The IV&V Lead reviews and approves all products from V&V activities, such as the SVVP, the Concept Phase V&V Activity Summary Report (SCR), Requirement Phase V&V Activity Summary Report (SRR), Design Phase V&V Activity Summary Report (SDR),
Test Phase V&V Activity Summary Report (STR), Implementation Phase V&V Activity Summary Report (SIR), etc.
4.2 Master Schedule Table 1 (the project master schedule) provides a basis for the relationship between IEEE Std 1012-1998, /11/, V&V Activities, the Project Phases, as defined in the QAPP,
/3/, and the V&V activities.
Table 1. The Project Master Schedule IEEE 1012 Installation &
Activities Concept Requirements Design Implementation Test Checkout Phase 0 Phase I Phase 2 Phase 3 Project Licensing Implementation Phases Pre-Application Initial Application Continued Reviewed Audit &Impem tion Inspection 11 Project Phases Phasel Conceptual EngisCneepting Engineering Phase 2 Basic Design
] Phase 3/Phase 4 Detail Design/Manufacturing Phase 5 jInstallation Testing Phase 6 Issionin Commissioning Project Project Management Management System Design & System Software Analysis Group Requirements Design Software Software Software Code Development Requirements Design Generation Group System Integration Hardware &
Installation Software System Installation Implementation Integration FAT Group Test Baseline Change Assessment/ Management Review of V&V/ Management and Technical Review Support Documentation Software Software Source Code Evaluation Requirements Design Evaluation Evaluation Evaluation SWAT Test FAT IV&V Group Plan, Specification Test activities Final V&V Requirements FAT Plan Specification and Procedure Report Analysis Generation and Procedure Generation Generation SIVAT Test Execution SVVP Generation SVVP Update SVVP Update SVVP Update SCR SRR SDR SIR STR The Project Licensing Phases which are inserted in Table 1 correspond to the actual NRC licensing processes guide, Digital Instrumentation and Controls Interim Staff Guidance (DI&C-ISG-06),/14/.
The table provides a generalized project overview to help visualize the sequence of V&V Activities in relation to project activities; a delineation of required V&V Activities and associated V&V Tasks is provided in Section 4.4.
UFINRE Preparedby Reviewed by QA-), UFTR-QA 1-03 Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: VoL 1 Page 18 of 40 The Master Project Schedule is maintained by the Project Manager, with input from the IV&V Group on V&V Tasks. The Master Project Schedule identifies the relationships between the group's activities.
4.3 Resources summary Table 2 summarizes IV&V resource requirements available for the project regarding staff, facilities, tools, finances, and other special procedural requirements.
Table 2. Summary of the IV&V Resources IV&V Resource Availability Requirement The Project Manager is responsible for the IV&V staffing and Staffing training.
- Normal office desk space and full access to normal shared office resources Facilities - Individual telephone
- Access to test field
- Desktop computer with same network access as design engineers
- Access to all available design input data
- SPACE tool set Tools - SIVAT simulation program 9 Requirements tracing database tool The Project Manager is responsible .for ensuring that adequate budget is available for V&V activities.
Special Any special procedural requirements will be identified in the Procedural project-specific V&V Plan.
Requirements 4.4 IV&V Responsibilities The IV&V Group is responsible for the V&V Activities and Tasks delineated in Table 3. Further discussion on these activities and tasks are given in Section 5.
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy 1 UFTR Date : Initials: Date : Initials: VoL 1 Page 19 of 40 Tahle 3- Tasks for V&V Activities 4.5 Tools, techniques, and methods Techniques and methods include document reviews, design reviews, and testing.
The project manager arranges and verifies the training in tools, techniques, and methods for software design, integration, and testing personnel, and verifies the training for the IV&V personnel. Depending on the different design steps, different techniques and
UF/NRE Preparedby Reviewed by QA-1, UFTR-QA 1-03 Name: Name: Revision 0 Copy )
Date: Initials: Date : Initials: Vol. 1 Page 20 of 40 methods are applied for V&V. The most common techniques are listed in Section 4.5.1.
Each technique or method should consider the following, as applicable:
" Completeness of information
" Correspondence of changes (between requirements and designs)
" Control and data correlation
" Category of identified anomalies
" Severity of identified anomalies
" Systematic or repeated deficiencies 4.5.1 Reviews and Inspections Reviews and inspections scrutinize the system documentation, implementation (i.e., code), or outputs by an independent person.
Inspections include independent verification reviews that are performed on software development products, including the FRS, SRS, SDD, test plans, test designs, test cases and test procedures. The document reviews verify that the information is correct, accurate, complete, consistent, and clear, and that safety, contractual and quality requirements are met. Inspections also include code reviews for software not generated by SPACE.
Deviations or discrepancies are recorded as Open Items (see Section 7.1).
4.5.2 Simulation and Acceptance Testing Simulation and Acceptance Testing executes the software using data representative of the actual system.
- The IV&V Group is responsible for preparation of the SWAT validation test plan and test procedures documents. The IV&V Group may get assistance from design and testing personnel for the preparation of the SWAT test documents and the performance of test tasks; however, these support personnel shall work under the supervision of the IV&V Group.
" Execution of simulation testing is performed by the WV&V Group to functionally test SPACE generated C code before compiling the C code and integrating it into the TXS processors. This testing uses the SIVAT tool to simulate the TXS processor environment. The SWAT test cases and test results review is performed by the IV&V Group.
" The IV&V Group is responsible for preparation of the Acceptance test plan and test procedures documents. The IV&V Group may get assistance from the Software Development Group for the preparation of the SIVAT test documents and the performance of test tasks; however, these support personnel shall work under the supervision of the IV&V Group.
" Execution of FAT is performed by the Hardware and Installation Group under the supervision of the IV&V Group. The FAT validates that the
UF/NRE Preparedby Reviewed by QA-I, UFTR-QA 1-03 Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. I Page 21 of 40 integrated hardware/software system meets the project-specific functional requirements. Independent verification and approval of the FAT results are performed by the IV&V Group.
4.5.3 Formal Checks of the Software Specification (supported by SPACE)
SPACE contains several tools for checking the integrity and consistency of the SPACE database. The checks are either on-line during manual entry into the database (e.g., check of unique ID code) or off-line by check tools (e.g. check of signal connections or parameter validity). All these automated verifications are carried out until all check tools are satisfied. No verification documentation is necessary as these are performed automatically by the SPACE tool. The software listings are generated from the SPACE database for each software release.
Training in the use of the SPACE tool shall be required for individuals performing this activity.
4.5.4 Load Evaluations (supported by SPACE)
SPACE provides tools (netload and cpuload) to evaluate the expected TXS processor and network loads. These evaluations are used during the software design process in order to check the feasibility of the design. The final loads are documented in a code configuration document at the end of the software design phase. The IV&V Group reviews the code configuration document.
4.5.5 Software Identification (supported by SPACE)
SPACE provides a tool (scanmic) to unambiguously identify the software that runs on the protection system processors and the project-specific portion of the Gateway through the use of CRC checksums. SPACE also provides a tool (reflist) to unambiguously identify the project-specific software that runs on the Service Unit (SU), e.g., the SPACE database and Graphic Service Monitor (GSM) Screens, through the use of CRC checksums. At the end of the design phase the final configuration of the Application Software developed through the use of the SPACE engineering tool is recorded in a code configuration document. The final configuration of the project-specific portion of GSM (i.e., the GSM Screens) is recorded in the GSM code listing document. The IV&V Group reviews the GSM code listing document.
4.5.6 Software Functional Testing 4.5.6.1 SPACE Generated Software The simulation tool, SWAT, provides the capability for functional testing of the SPACE generated C code in a simulated rte. These verification tests are applied to all algorithms of the FRS in order to fully test the functionality of the Application Software. Formal SIVAT testing is developed by the IV&V Group and is performed by design personnel. The IV&V Group
Preparedby Reviewed by QA-I, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. 1 Page 22 of 40 reviews SIVAT test reports. SIVAT test activities are included in the SRM to help, ensure that the Application Software satisfies its functional requirements.
SIVAT is sufficiently verified and validated by NL-G to ensure that it meets its operational requirements. Formal SWAT testing addresses the SPACE generated C code of the TXS Application Software. These formal tests are specified in test specifications and procedures, and the results are documented in test reports. Training in the use of the SWAT tool shall be required for individuals performing this task.
4.5.6.2 Project-Specific GSM Screens and TXS Gateway Software Project-specific GSM Screens and TXS Gateway (GW) Software are not developed using SPACE and therefore, are not subject to SIVAT testing (i.e., functional testing). Results generated by design personnel may be reviewed and verified by the IV&V Group.
4.5.7 Acceptance Testing Acceptance Testing comprises the fulfillment of application Software system tests in order to validate all system functional requirements. Acceptance tests are specified in test specifications and test procedures, and the results are documented in test reports. Furthermore, all acceptance tests are performed to acceptance criteria that are approved by AREVA NP and the IV&V Group.
4.5.8 Regression Testing Regression Testing has to be done after a modification to previously tested Application Software. After reviewing a modification, the IV&V Group determines whether the test plans, specifications and/or procedures require revision, and if all or part of the previously tested application software has to be retested. Regression testing may be documented by the IV&V Group, and is reviewed and executed by design personnel. This process is documented in accordance with the requirements of Section 7.1.
4.5.9 Metrics The following metrics are produced and maintained by the IV&V Group to indicate the effectiveness of the software development process.
- Number of Software Open Items. This metric trends the total number of software Open Items discovered in each phase of the project by either the development organization or IV&V organization. This provides a status indicator of the development effort and an alert of the potential risk to the project. For software development to be considered effective, this number should trend down.
- Age of V&V Open Items. These metric trends the age of Open Items identified during V&V activities. This can be presented graphically with
Preparedby Reviewed by QA-I, UFTR-QA 1-03 UFINRE Name: Nam e: Revision 0 Copy I UFTR Date : Initials: Date : Initials: VoL 1 Page 23 of 40 age on the horizontal axis and number of Open Items on the vertical axis.
This provides a status indicator of the V&V effort and an alert of the potential risk to the project.
" Fraction of V&V Open Items. This metric trends the number of software Open Items discovered by the IV&V organization compared to the total number of software Open Items. This metric provides an indication of the effectiveness of the development process reviews compared to the V&V process reviews.
- Test Anomalies. This metric identifies the number of test anomalies discovered during V&V testing and indicates the degree of effectiveness of the verification activities that preceded validation testing.
Metrics are published in the applicable V&V Activity Summary Report.
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UF/NRE Name: Name: Revision 0 Copy 1 Date: Initials: Date: Initials: Vol. 1 Page 24 of 40
- 5. The V&V Processes Table 1 shows for the relationship between UF project phases, the V&V activities, and how they relate to the Software Lifecycle described in IEEE 1012, /11/.
All Application Software life cycle V&V Activities, including Tasks, shall be documented in the applicable V&V Activity Summary Report. At the sole discretion of the IV&V Lead, individual Task Reports may be issued as stand-alone documents and referenced in the applicable V&V Activity Summary Report.
Unless stipulated in this SVVP, the IV& V personnel shall document all anomalies identified during execution of their assigned responsibilities in accordance with Section 7.1.
5.1 Process
Management The IV&V Lead prepares and initiates implementation of the SVVP and monitors progress of its execution. The IV&V Lead is responsible for ensuring the quality of the V&V effort.
5.1.1 Activity
Management of V&V The management of V&V activities is performed in all software life cycle processes and activities (Table 1). The three (3) main IV&V management tasks are described below:
Task 1) Baseline Change Assessment Software changes, which occur throughout the life cycle of the project, shall be evaluated by the IV&V Group for effects on previously completed V&V tasks. This evaluation may initiate new V&V tasks or cause previous V&V tasks to be repeated. The required inputs for this task are the proposed changes included in the Open Items and in accordance with the UFTR Software Configuration Management Plan (SCMP), /5/. The required output shall be used to update the SVVP and the respective V&V task report(s).
Task 2) Management Review of V&V Periodic review meetings shall be held with the representatives from the other groups to discuss progress, schedule, questions, and other V&V concerns. Management review of the on-going V&V activities shall include reviews of the Open Items, V&V Summary Reports, memos, etc., and V&V processes. These reviews shall occur throughout the life cycle of the V&V effort. Changes shall be defined and efforts redirected as needed, including revisions to the SVVP. Results of each management review shall be documented and issued to the project file.
Preparedby Reviewed by QA-I, UFTR-QA1-03 UFINRE -
Name: Revision 0 Copy 1 UFTR Name:
Date: Initials: Date: Initials: VoL 1 Page 25 of 40 Task 3) Management and Technical Review Support The IV&V Lead shall support project management reviews and technical reviews such as design reviews. Management shall assess the review materials and verify the timely delivery of software products and documents. The IV&V Lead shall provide task reports (SRR, SDR, etc.) and anomaly reports (i.e., Open Items).
5.2 Process
Development The Development Process encompasses the V&V activities associated with Application Software Development. The V&V activities are described in the following sections.
During any of the activities described in the following sections, the IV&V personnel may verify software user documentation as it becomes available from the Software Development group and the Hardware and Installation Group. Before release of the V&V Final Report, the IV&V Group shall ensure that instructions for installation, operation and maintenance of the TXS system are correct and complete. IV&V shall record the results of the review on a V&V Comment Sheet. The V&V Comment Sheet shall have the following minimum information:
" Document number of document being reviewed
" Document title
- Preparer's name
- IV&V Verifier's name
" Issue/Comment Description
" Page/Section of document that comment pertains to
- Date of comments
- Recommended Resolution
- Open Item Number (if applicabie)
The review shall be reported in the respective V&V Activity Summary Report.
5.2.1 Activity
Concept Phase of V&V The Concept Phase of V&V activity represents the delineation of a specific implementation solution to solve the user's problem. During the Concept Phase of V&V activity, the system architecture is selected, and system requirements are allocated to hardware, software, and user interface components. The Concept Phase of V&V activity addresses system architectural design and system requirements analysis. The objectives of the IV&V Group are to verify the allocation of system requirements, validate the selected solution, and ensure that no false assumptions have been incorporated in the solution. A baseline SVVP is developed during this activity. The following tasks are performed during the Concept Phase of V&V Activity:
Preparedby Reviewed by QA-I, UFTR-QAJ-03 UFINRE Name: Name: Revision 0 Copy 1 Date : Initials: Date: Initials: VoL. 1 Page 26 of 40 Task 1) Concept Phase Documentation Evaluation The IV&V Group shall verify that the concept documentation satisfies UFTR needs with regard to system functions and is consistent with acquisition needs, the functional requirements are feasible and testable, and overall performance can be achieved. This verification shall be performed on all requirements allocated as software functional requirements. The IV&V Group shall analyze system requirements and validate that the following user needs are satisfied:
" System functions
" End-to-end system performance
" Feasibility and testability of the functional requirements
" System architecture design
" Operation and maintenance requirements
" Migration requirements from an existing system where applicable Inputs to this task are:
- UFTR FRS, /9/
- Concept design documents The results of this task shall be documented in the SCR. The report shall identify any software requirements that are not feasible, or do not satisfy the review criteria.
Task 2) Hardware/Software/User Requirements Allocation Analysis The IV&V Group shall verify the Hardware Design Solutions and Software Design Solutions for correctness, accuracy, and completeness of the concept requirement allocation to hardware requirements, software requirements, or both as defined in IEEE 1012-1998, Table 1, Section 5.4.1,/11/. The Concept Phase Requirements allocation may be further refined in the Requirements Phase of V&V Activity. The results of this analysis shall be documented in the SCR.
Task 3) SVVP Generation The scope of the V&V effort shall be defined. A baseline SVVP shall be generated by the IV&V Lead during the Concept Phase V&V activity.
Changes may be made to the SVVP as the project progresses through its life cycle. The inputs to the plan are project-specific requirements. The required output is the SVVP and its updates through the life cycle.
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UFINRE UFTR Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: Vol. I Page 27 of 40 Task 4) Summary of Concept phase of V&V activity Report (SCR)
A summary report of the tasks completed during the Concept V&V Activity, including the associated metrics, shall be submitted to the IV&V Group for approval.
The Concept Phase of V&V Activity produces:
" SCR (see Section 6.5 for report outline)
" Open Items if necessary
" Initial V&V Plan
5.2.2 Activity
Requirements Phase of V&V The following tasks are performed during the Requirements Phase of V&V Activity. The SVVP generated in the Concept Phase of V&V Activity shall be updated as required prior to performing the tasks below:
Task 1) Software Requirements Evaluation The IV&V Group shall evaluate the SRS for correctness, consistency, completeness, accuracy, readability, and testability as defined in IEEE 1012-1998, Table 1, Section 5.4.2,/11/.
This ensures that the SRS adequately defines the software requirements necessary to perform the intended function. The input data used for software requirements evaluation includes, but is not limited to:
" UFTR FRS, /9/
" Background documentation (system drawings, technical specifications, etc.)
" UFTR procedures, Operating Instructions, etc.
The Software Requirements Evaluation consists of:
- Review the SRS against the input data above
" Other analyses required
" Coordinate resolutions of discrepancies (Open Items) with the IV&V Group and the design team.
The output from this task, along with any Open Items, shall be documented in the SRR.
Task 2) Interface Analysis The Software Requirements Interface Analysis V&V activity verifies and validates that requirements for interfaces to hardware, user, operator, and other software are correct, consistent, complete, accurate, and testable as defined in IEEE 1012-1998, Table 1, Section 5.4.2, /11/.
UF/NRE Preparedby Reviewed by QA-1, UFTR-Q.A1-03 Name: Name: Revision 0 Copy 1 UFTR Date : Initials: Date : Initials: Vol. 1 Page 28 of 40 The inputs to this task include, but are not limited to:
- FRS
- Concept design documents
- SRS The outputs from this task, along with the Open Items, shall be documented in the SRR.
Task 3) Configuration Management Assessment The 1V&V Group shall verify that the reviewed documentation is controlled in accordance with the applicable UFTR SCMP, /5/. Any discrepancies shall be documented as Open Items. The results of the assessment shall be documented in the SRR.
Task 4) The FAT Plan Generation and Verification The FAT Plan includes the hardware and software supplied by AREVA NP for the total system, from the cabinet input terminals to the output terminals, and peripheral items such as the SU, the Qualified Display System (QDS),
and the GW.
The FAT validates the software requirements are correctly implemented utilizing the fully integrated TXS system. The software encompasses system software including operating system software, communication software, rte software, and peripheral software such as GW Historical Application and GSM screens. The FAT shall address software functional requirements, timing and accuracy, performance at boundaries and under stress conditions, and interfaces to external systems.
The FAT Plan shall be generated by the IV&V Group. The Development and the Hardware and Installation Groups shall review the FAT Plan. The FAT Plan shall describe the software/hardware system, features to be tested, test approach, item pass/fail criteria, suspension criteria and resumption requirements, test deliverables, responsibilities, staffing and training needs, schedule, and risk and contingencies.
The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue the FAT Plan Verification.
Task 5) Summary of Requirements phase of V&V activity Report (SRR)
A summary report of the tasks completed during the Requirements Phase of V&V Activity shall be submitted to the IV&V Group, and the Software Development Group for approval.
Preparedby Reviewed by QA-), UFTR-QAI-03 UFINRE UFTR Name: Name: Revision 0 Copy I Date: Initials: Date : Initials: Vol. 1 Page29 of 40 Task 6) SVVP (update)
The Requirements Phase of V&V Activity produces:
- Open Items as necessary
- FAT Plan Generation and Verification
- SRR (see Section 6.2 for report outline)
5.2.3 Activity
Design Phase of V&V In the Detailed Design Phase, the Software Development Group converts the software requirements into a detailed design, including function blocks arranged into a particular architecture. The IV&V Group demonstrates that the design correctly, accurately, and completely reflects the software requirements and no unintended features are introduced. The following tasks are performed during the Design Phase of V&V Activity.
Task 1) Software Design Evaluation The IV&V Group shall evaluate the SDD for correctness, consistency, completeness, accuracy, readability, and testability as defined in IEEE 1012-1998, Table 1, Section 5.4.3, /11/.
The design shall be evaluated for compliance with established standards, practices and conventions. Design quality shall be assessed. Inputs for this task include, but are not limited to:
- SDD
- UFTR procedures, Operating Instructions, etc.
- Design Standards The output from this task, along with any Open Items, shall be documented in the Design Phase of V&V Activity Summary Report (SDR).
Task 2) Interface Analysis The JV&V Group shall verify and validate the software design for correctness, consistency, completeness, accuracy, and testability of the interfaces with hardware, user, operator, software, and other systems as defined in IEEE 1012-1998, Table 1, Section 5.4.3, /11/.
Inputs for this task include, but are not limited to:
- Concept design documents
- SDD The outputs from this task, along with any Open Items, shall be documented in the SDR.
Preparedby Reviewed by QA-I, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy I UFTR Date : Initials: Date : Initials: VoL 1 Page 30 of 40 Task 3) SWAT Test Plan Generation and Verification SWAT testing is the method used for testing TXS Application Software before integration with the TXS processors. The formal SWAT functional test is a test of the Application Software functionality, as specified in the SDD, to determine if software elements (e.g. input modules, output modules, and function modules) correctly implement software requirements.
The SWAT test shall encompass the software for all processors as part of the same test. The SWAT test is a formal validation of software components (consisting of qualified software modules from the SPACE tool) that comprise the software application. Timing, performance at boundaries, and interfaces are assessed under stress and error conditions using the SWAT tool.
The SWAT Test Plan shall be generated by the IV&V Group. The Software Development Group shall review the SIVAT Test Plan. The SWAT Test Plan, /6/, shall describe the software or software/hardware system, as applicable; identify the features to be tested, test approach, item pass/fail criteria, responsible group(s), the test administration and process for test anomaly handling, equipment, staffing and training needs, required test deliverables, and test schedule. The test plan shall address the component level of software functional requirements. The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the SIVAT Test Plan Verification.
Task 4) SWAT Test Specification Generation and Verification The SWAT Test Specification addresses both test design and test cases. The SWAT Test Specification describes the software features to be tested, approach refinements, and pass/fail criteria. The SWAT Test Specification provides a general description of the test cases. The specification of test cases identifies the test items, features to be tested, feature pass/fail criteria, input and output specifications, environmental needs, special procedural requirements, and intercase dependencies. Individual test cases may test one or more of the software features. Sufficient test cases to cover as many software features as practical shall be specified. The test cases shall be selected so that each input submodule, function module, and output submodule is tested for at least one set of input and output conditions. Test cases should be selected to demonstrate successful integration of software components and proper operation with interfaces and performance at boundaries. Test cases should cover as many testable software requirements as practical.
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy I UFTR Date: Initials: Date: Initials: VoL 1 Page 31 of 40 The SIVAT Test Specification shall be generated by the IV&V Group. The IV&V Group shall verify that the SWAT Test Specification is specified in the SIVAT test plan. Test case verification shall cover one case for each of the input, function, and output modules or submodules. The same test case need not be verified for more than one channel.
The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the SIVAT Test Specification Verification.
Task 5) SWAT Test Procedure Generation and Verification The IV&V Group shall verify the SIVAT Test Procedure based on test cases in the SIVAT Test Specification to ensure that the test objectives are achieved, if specified in the SWAT test plan. The same test case need not be verified for more than one channel. Testing of a requirement in SIVAT may be used as justification for excluding a test of this requirement in Acceptance Testing provided that tracing of the requirement to the SWAT Test documentation is performed. The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the SIVAT Test Procedure Verification.
Task 6) Summary of Design phase of V&V activity Report (SDR)
A summary report of the tasks completed during the Design Phase of V&V Activity, including the associated metrics, shall be submitted to the IV&V Group.
Task 7) SVVP (update)
The Design Phase of V&V Activity produces:
- Open Items as necessary
- FAT Plan Verification
- SWAT Test Plan Generation and Verification
- SWAT Test Specification Generation and Verification, if specified in the SIVAT Test Plan
- SWAT Test Procedure Generation and Verification, if specified in the SIVAT Test Plan
- SDR (see Section 6.3 for report outline)
5.2.4 Activity
Implementation Phase of V&V The Implementation Phase of V&V Activity verifies the software design is correctly translated into code. For TXS Application Software, source code generation is handled by the qualified SPACE tool.
The following tasks are performed during the Implementation Phase of V&V Activity.
UF/NRE .Preparedby Reviewed by QA-I, UFTR-QAI-03 Name: Name: Revision 0 Copy I UFTR Date :Initials: Date : Initials: Vol. I Page32 of 40 Task 1) Source Code and Source Code Documentation Evaluation Application Software generation is handled by qualified tools (SPACE).
The IV&V Group shall evaluate the source code components for correctness, consistency, completeness, accuracy, readability and testability.
They shall also verify the following:
"The SPACE Function Diagrams were prepared using the recommendations, conventions, and design constraints given in the TXS Function Block Manual corresponding to the version of the TXS System Software used for the project.
"The correct versions and revisions of SPACE Function Diagrams were used to assemble the Application Software release for each TXS subsystem using the reflist tool and Code Configuration document.
"The procedure used for generation of the Application Software release was followed.
"The qualified versions of code generators have been used
- Only qualified TXS System Software components have been used. For other codes such as third party software procured for a project, the software shall be evaluated for correctness, consistency, completeness, accuracy, readability, and testability as defined in IEEE 1012-1998, Table 1, Section 5.4.4, /11/. The IV&V Group shall include the results of the analysis in the SIR.
Task 2) The FAT Specification Generation and Verification The IV&V Group shall prepare the FAT Specification consistent with the requirements of the FAT Plan. The FAT Specification describes the test items, input and output specifications, environmental needs, special procedural requirements, and intercase dependencies, the software features to be tested, approach refinements, and pass/fail criteria. The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the FAT Specification Verification.
Task 3) The FAT Procedure Generation and Verification The IV&V Group shall prepare each FAT Procedure based on the FAT Plan and FAT Specification. The FAT Procedures describe the test cases, test equipment, prerequisites, test setup, and detailed test procedure steps. The IV&V shall validate that the FAT Procedures completely test the Application Software code and that the requirements in the FRS are met.
The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the FAT Procedure Verification.
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UFINRE UFTR Name: Name: Revision 0 Copy I Date: Initials: Date : Initials: Vol. 1 Page33 of 40 Task 4) Interface Analysis The IV&V Group shall verify and validate interfaces between SPACE Function Diagrams (or software source code as applicable for non-TXS software products) and hardware, user, operator, software, communication, and other applicable systems for correctness, consistency, completeness, accuracy, and testability as defined in IEEE 1012-1998, Table 1, Section 5.4.4,/11/.
The outputs from this task, along with any Open Items shall be documented in the SIR.
Task 5) SIVAT Test Execution and Report Generation The IV&V Group shall prepare the SIVAT Test to validate that the software satisfies the test acceptance criteria as defined in the Test Specification. The final SIVAT Test Report shall have no remaining unresolved test incidents.
The IV&V Group shall record the results of the review in a V&V Comment Sheet and issue as the SIVAT Test Execution Report Verification.
Task 6) Summary of Implementation phase of V&V activity Report (SIR)
A summary report of the tasks completed during the Implementation V&V Activity, including the associated metrics, shall be submitted to the IV&V Group for approval.
Task 7) SVVP (update)
The Implementation Phase of V&V Activity produces:
" Open Items as necessary
" The FAT Specification Generation and Verification
" The FAT Procedure Generation and Verification SSIVAT Test Execution and Report Generation
- SIR (see Section 6.4 for report outline)
5.2.5 Activity
Test Phase of V&V The Test Phase of V&V Activity consists of verifying acceptance test documentation. The objective of this activity is to validate that the requirements in the FRS are correctly implemented into the fully integrated TXS system. The test documentation is produced by the IV&V Group or the testing organization under the supervision of the IV&V Group.
The following tasks are performed during the Test V&V Activity:
Task 1) The FAT Specification Generation and Verification (update)
Task 2) The FAT Procedure Generation and Verification (update)
UF/NRE Preparedby Reviewed by QA-1, UFTR-QAI-03 Name: Name: Revision 0 Copy I Date: Initials: Date: Initials: VoL I Page 34 of 40 Task 3) The FAT Execution and Report Generation The IV&V Group shall verify the FAT results including the Test Item Transmittal Report, Test Log, Test Incident Report, and Test Summary Report to ensure that they demonstrate that the system satisfies the criteria of the FAT Plan and FAT Procedures. The 1V&V Group shall verify the correct versions of software were used in the FAT. The IV&V Group shall document the test results in a Test Phase V&V Activity Summary Report.
An outline of the STR is provided in Section 6.5.
Task 4) Summary of Test phase of V&V activity Report (STR)
A summary report of the tasks completed during the Test Phase of V&V Activity, including the associated metrics, shall be submitted to the IV&V Group for approval.
The Test Phase of V&V Activity produces:
- The FAT Execution and Report Generation
- Open Items forms as necessary
- STR (see Section 6.5 for report outline)
- V&V Final Report (see Section 6.6 for report outline)
5.2.6 Activity
Installation and Checkout Phase of V&V Task 1) V&V Final Report The 1V&V Group shall prepare the V&V Final Report that summarizes the V&V activities, tasks, and results. The report shall include the status and resolution of all software-related Open Items. The report shall provide an assessment of overall software quality and any recommendations. An outline of the V&V Final Report is provided in Section 6.6.
The Installation and Checkout Phase of V&V Activity produces:
- V&V Final Report (see Section 6.6 for report outline)
5.3 Process
Operation and Maintenance These processes are not applicable to TXS Application Software V&V activities.
The V&V effort is complete when the V&V Final Report is issued following the completion of the Installation and Checkout Phase of V&V Activity. Any modifications, enhancements, or additions to the software at a later date would follow the guidelines defined in Section 7.2.
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE UFTR Name: Name: Revision O Copy I Date : Initials: Date: Initials: Vol. 1. Page 35 of 40
- 6. V&V Reporting Requirements The V&V reporting requirements, content, and suggested outlines for the different reports are described below. For each of the documents, a suggested outline providing the required content of each document is given in this section. As a minimum, each document shall contain the following:
- V&V Activity identification
- Background information of standards, and source documents with revisions
- Synopsis of the review and confirmation that the plan was followed
- Open Items found
" Recommendations The descriptions of Open Items (see Section 7.1.1) identified in the report shall include as a minimum:
" Date Open Item was initiated
- Open Item number
- Description of the issue involved
- Document(s) of concern 6.1 Summary of Concept phase of V&V activity Report (SCR) Outline
" Background
- Identification of standards, regulations
- Identification of FRS and related documents
- Identification of background material required
- Review participants
" References
" Summary of Tasks (see Section 5.2.1 for guidance)
- Concept Phase Document Evaluation
- Hardware/Software/User Requirements Allocation Analysis
- SVVP Generation
" Summary of Review Results
" Summary of Open Items Issued and Status
" Attachment 1: Description of Open Items Identified 6.2 Summary of Requirements phase of V&V activity Report (SRR) Outline
" Background
- Identification of standards, regulations
- Identification of FRS and related documents
- Identification of background material required
- Review participants
- References
" Summary of Tasks (see Section 5.2.2 for guidance)
Preparedby Reviewed by QA-1, UFTR-QAI-03 UF/NRE Name: Name: Revision 0 Copy I Date: Initials: Date : Initials: Vol. 1 Page36 of 40
- Software Requirements Evaluation
- FAT Plan Generation and Verification
- Software Requirement Interface Analysis
- Configuration Management Assessment
- Summary of Review Results
- Summary of Open Items Issued and Status
" Attachment 1: Description of Open Items Identified 6.3 Summary of Design phase of V&V activity Report (SDR) Outline
- Background
- Identification of Design Documents Reviewed
- Identification of Other Material Considered
- Review Participants
- References
" Summary of Tasks (see Section 5.2.3 for guidance)
- Software Design Evaluation
- Software Design Interface Analysis
- SWAT Test Plan Generation and Verification
- SWAT Test Specification Generation and Verification
- SWAT Test Procedure Generation and Verification
" Summary of Review Results
- Summary of Open Items Issued and Present Status
" Attachment 1: Description of Open Items Identified 6.4 Summary of Implementation phase of V&V activity Report (SIR) Outline
" Background
- Identification of the SPACE Function Diagrams
- Identification of the TXS System Software
- Identification of the TXS Code Generators
- Identification of Other Material Considered
- Review Participants
- References
" Summary of Tasks (see Section 5.2.4 for guidance)
- Source Code and Source Code Documentation Evaluation (this section not applicable to TXS code)
- FAT Specification Generation and Verification
- FAT Procedure Generation and Verification
- Interface Analysis
- SWAT Test Execution and Report Generation
" Summary of Review Results
- Summary of Open Items and Present Status
" Attachment 1: Description of Open Items Identified
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE Name: Name: Revision 0 Copy 1 Date : Initials: Date: Initials: VoL 1 Page37 of 40 6.5 Summary of Test phase of V&V activity Report (STR) Outline
" Background
- Identification of the SPACE Function Diagrams
- Identification of the TXS System Software
- Identification of the TXS Code Generators
- Identification of Other Material Considered
- Review Participants
" References
" Summary of Tasks (see Section 5.2.5 for guidance)
- FAT Execution and Report Generation
" Summary of Review Results
" Summary of Open Items and Present Status
" Attachment 1: Description of Open Items Identified 6.6 V&V Final Report Outline
" Summary of V&V Plan
" Identification of V&V Documentation
" Summary of all Life Cycle V&V Activities
- Summary of Task Results
" Summary of Open Items and Resolutions
" Assessment of Overall Software Quality
- Lessons Learned/Process Improvements
" Recommendations
- Attachment 1: Open Item Forms
FNRE Preparedby Reviewed by QA-1, UFTR-QA I-03 Name: Revision 0 Copy I UFTR Name:
Date: Initials: Date: Initials: Vol. 1 Page38 of 40
- 7. V&V Administration Requirements 7.1 Anomaly Resolution and Reporting Whenever a member of the IV&V Group identifies a problem in a development document or activity (such as testing), that item is reported as a discrepancy in the Open Item database. Discrepancies may arise from the properties of the document being examined (such as ambiguity, incompleteness, or incorrect usage) or from inconsistencies with other available information. For example, a development document may be identified as having incorrect or missing translation of items established in previous development baselines; or a testing activity may produce a result that differs from the expected outcome. For such cases, the IV&V Group shall initiate an Open Item as described in the following sections. Open Items that involve conditions adverse to quality shall be entered into the Corrective Action Program.
Open Items For Open Items initiated as a result of testing activities (i.e., SIVAT and FAT), the Open Item shall include, as a minimum:
" Indication of the anomaly
" Identification of the affected test procedure step(s)
" Time and date the anomaly was discovered Resolution of Open Items initiated as a result of testing activities shall include a discussion of the need for Regression Testing in accordance with Section 4.5.8. The IV&V Group shall approve the "evaluations" of all Open Items initiated in accordance with the requirements of this SVVP.
7.2 Task Iteration Policy The system and the software products'that are inputs to the V&V activities may be modified throughout the system or software life cycle. These modifications may result, for instance, from anomaly corrections, quality enhancements or requirements changes.
When a system or a software product is modified, additional V&V activities are in general required: previous tasks must be repeated or new ones must be initiated. The policy to be respected is the following:
If an engineering document is modified, the new revision of the document is verified. However, the IV&V Lead can decide to limit the verification to the impacted portions.
The decision to organize a review for the modified version of the document is taken in accordance with the rules given in the UFTR "Software Quality Assurance Plan (SQAP)," /4/.
Preparedby Reviewed by QA-1, UFTR-QAI-03 UFINRE UFTR Name: Name: Revision 0 Copy I Date : Initials: Date:' Initials: VoL 1 Page39 of 40 If a software item is modified, an impact analysis is performed, as specified in the SQAP, /4/. The 1V&V Lead determines which additional tests are required to assess the software modification.
The V&V tasks are repeated until all anomalies are resolved, except for minor anomalies that are not critical. The decision to postpone the resolution of an anomaly must be approved by the IV&V Lead. In that case, uncorrected anomalies must be identified in the system and/or software files.
7.3 Deviation Policy Project changes or external factors may require deviating from the procedures for V&V described in the current plan.
The IV&V Lead is responsible for identifying the need of deviation and for preparing a deviation request. Deviation requests must be approved by the IV&V Lead and by the Project Manager.
Every deviation is documented by the IV&V Lead in a note that includes the following information:
" V&V task identification,
" Deviation rationale,
" Effect on system and/or software quality.
This note is recorded in the related design file, with the mention "approved" or "disapproved". Additionally, approved deviations are referenced in the V&V Report.
If a deviation is expected to be repeated, or if it significantly affects remaining activities, the current plan shall be revised.
7.4 Control Procedures The control procedures that shall be applied throughout the V&V activities are described in the UFTR "Conduct of Quality Assurance," /2/, and UFTR QAPP, /3/.
7.5 Standards, Practices, and Conventions Standards, practices and conventions that shall be applied throughout the V&V activities are described in the QAPP, /3/, and in the SQAP, /4/.
Preparedby Reviewed by QA-1, UFTR-QA 1-03 UFINRE Name: Name: Revision 0 Copy I Date : I Initials: Date : Initials: Vol. 1 Page 40 of 40
- 8. V&V Documentation requirements The V&V engineering documents are specified below:
UFTR Verification and Validation Plan, UFTR Input Data Review Report, UFTR Software Test Plan-SIVAT Plan, /6/
UFTR System Test Analysis, UFTR System Test Report, UFTR Factory Acceptance (FAT) Plan, /7/
UFTR FAT Report, UFTR V&V Report, TXS Software Components Validation Tests Analysis, TXS Software Components Validation Tests Report, TXS Software Validation Tests Analysis, TXS Software Validation Tests Report.