Plant Installed Software - Hanford Site



Ownership matrixRPP-27195TABLE OF CONTENTS TOC \o "1-2" \h \z 1.0PURPOSE AND SCOPE PAGEREF _Toc12876700 \h 22.0IMPLEMENTATION PAGEREF _Toc12876701 \h 23.0ROLES AND RESPONSIBILITIES PAGEREF _Toc12876702 \h 23.1Engineering Manager PAGEREF _Toc12876703 \h 33.2Design Authority PAGEREF _Toc12876704 \h 33.3Project Lead PAGEREF _Toc12876705 \h 43.4Technical Lead PAGEREF _Toc12876706 \h 43.5Technical Support Manager PAGEREF _Toc12876707 \h 43.6Plant Installed Change Control Board (PICCB) PAGEREF _Toc12876708 \h 53.7Training Department PAGEREF _Toc12876709 \h 54.0PROCEDURE PAGEREF _Toc12876710 \h 54.1Cyber Security PAGEREF _Toc12876711 \h 54.2Software Project Initiation PAGEREF _Toc12876712 \h 64.3Software Life Cycle PAGEREF _Toc12876713 \h 64.4Failure Modes and Effects Analysis PAGEREF _Toc12876714 \h 234.5Acquisition Activities PAGEREF _Toc12876715 \h 234.6Configuration Management PAGEREF _Toc12876716 \h 295.0DEFINITIONS PAGEREF _Toc12876717 \h 296.0RECORDS PAGEREF _Toc12876718 \h 307.0SOURCES PAGEREF _Toc12876719 \h 317.1Requirements PAGEREF _Toc12876720 \h 317.2References PAGEREF _Toc12876721 \h 31TABLE OF FIGURES TOC \h \z \c "Figure" Figure?1. WRPS Plant Installed Software Procedural Flowdown. PAGEREF _Toc12876722 \h 34Figure?2. Plant Installed Software Life Cycle Waterfall Method with Feedback and Rapid Prototyping Provision. PAGEREF _Toc12876723 \h 35TABLE OF ATTACHMENTS TOC \h \z \c "ATTACHMENT" ATTACHMENT?A - RAPID PROTOTYPING VORTEX DEVELOPMENT METHOD PAGEREF _Toc12876724 \h 36ATTACHMENT?B – PLANT INSTALLED SOFTWARE LIFE CYCLE MODEL PAGEREF _Toc12876725 \h 39ATTACHMENT?C – CROSS REFERENCE OF SQA WORK ACTIVITIES TO SOFTWARE LIFE CYCLE (SLC) PHASE DELIVERABLES PAGEREF _Toc12876726 \h 41ATTACHMENT?D - PLANT INSTALLED SOFTWARE COMPLIANCE MATRIX PAGEREF _Toc12876727 \h 42ATTACHMENT?E - PLANT INSTALLED SOFTWARE DOCUMENTATION REQUIREMENTS PAGEREF _Toc12876728 \h 45ATTACHMENT?F - FAILURE MODES AND EFFECTS ANALYSIS PAGEREF _Toc12876729 \h 46PURPOSE AND SCOPE( REF _Ref514046955 \n \h 7.1.1, REF _Ref514046962 \n \h 7.1.2, REF _Ref514046970 \n \h 7.1.3, REF _Ref514046975 \n \h 7.1.4, REF _Ref514046981 \n \h 7.1.5, REF _Ref514046987 \n \h 7.1.6)This procedure describes the software life cycle processes for acquisition, development, testing, maintenance, configuration management, and documentation of Plant Installed Software.This procedure is invoked from:Software Development, Implementation, and Management, TFC-BSM-IRM_HS-C-01.This procedure must work in conjunction with the related:Plant Installed Software Quality Assurance Procedure (PI-SQA), TFCENGDESIGN-P-59Associated Plant Installed Software Life Cycle (SLC) document templates as located at the WRPS Chief Information Officer (CIO) websiteEngineering processes, plans and procedures described in:TFC-PLN-03TFC-ENG-DESIGN procedures referenced in Section REF _Ref462316168 \r \h 7.2.Plant Installed Software is any software application, database, or computer program that is developed, configured or acquired, and maintained to support a structure, system, or component (SSC); or other productivity and job management tools supporting operations. This definition includes, but is not limited to, distributed control systems (DCS), programmable logic controllers (PLCs), human-machine interface (HMI) software, databases, and plant-related computer programs.This procedure is governed by Washington River Protection Solutions, LLC (WRPS) Company-level procedures including TFC-PLN-02, TFC-PLN-03, TFC-BSM-IRM-STD-01, TFC-BSM-IRM-STD-02, and TFCBSMIRM_HSC01. Plant Installed Software is categorized as “Configurable,” “Acquired” or “Custom Developed” in accordance with TFC-BSM-IRM-STD01. It is controlled at a level commensurate with its intended function and assigned software classification level. REF _Ref381620348 \h \* Caps Figure?1 shows the flow down of procedural requirements for Plant Installed Software.IMPLEMENTATIONThis procedure is effective on the date shown in the header.ROLES AND RESPONSIBILITIESRoles and Responsibilities are supplemental to those defined in TFC-BSM-IRM_HS-C-01 and/or TFCPLN-03. In some cases, responsibilities may vary based on applicability to certain environments or other external requirements or conditions. Variances or conditions of applicability are described within each role. REF _Ref462315951 \h \* Caps Table?1 is provided to assist in understanding the correlation of roles across varying governing requirements.Table? SEQ Table \* ARABIC 1. Role Mapping.TFC-ENG-DESIGN-P-12/TFC-ENG-DESIGN-P-59TFC-PLN-03TFC-BSM-IRM_HS-C-01Engineering ManagerEngineering ManagerSoftware OwnerDesign AuthorityDesign AuthorityN/AProject LeadResponsible EngineerSoftware Project LeadPICCBN/ASoftware Technical Support AnalystTechnical Support ManagerEngineering ManagerSoftware OwnerTechnical LeadSupport EngineerN/AEngineering ManagerAssigns Project LeadOversees tasks and execution of processes defined within this procedureEnsures all personnel qualifications are adequate to perform assigned activitiesSelects the Plant Installed Change Control Board (PICCB) in accordance with TFC-CHARTER-55Approves life cycle documentationApproves Software Change Requests (SCRs) (SPF-017).Design AuthorityEstablishes and maintains the design basis requirementsEnsures that design output documents accurately reflect the design basisIs responsible for design control and ultimate technical adequacy of the design processEnsures the SSCs are maintained within the Authorization BasisEstablishes and maintains the list of life cycle documents that are controlled as part of the Technical BaselineStays involved in the acquisition, design, development, verification and validation (including testing), configuration management, maintenance, and retirement of safety software as designated throughout the procedure.Project LeadDetermines the software life cycle (SLC) technical tasks and documentation.Is responsible for the identification and development of life cycle documentation.Coordinates with the Procurement (Buyer) for acquisition of all procured software packages and custom developed modules for Plant Installed Systems.Coordinates with Commissioning Test Director for Test Program Level 1 (TP-1) and Test Program Level 2 (TP-2) projects.Is responsible for maintaining HISI registration and HISI entries.Maintains configuration management of the deployed software.Is responsible for error reporting and evaluation.Notifies vendor or supplier of detected source code errors.Manages upgrades and patches from vendors.Manages passwords as required per the Software Management Plan (SMP) for deployed software.Approves and processes SCRs. Technical LeadLeads the software design/development effort.Supports development and implementation of the SMP and other SLC phase documentation and deliverables as requested by the Project Lead.Develops software to meet specified requirements.Ensures software is complete and ready for design verificationWorks with the Software Technical Support Analyst (STSA) for any guidance or assistance during any phase of the software lifecycle, including WRPS software template and document rendering. Technical Support ManagerProvides management oversight for SLC activities assigned to the Technical LeadReviews SLC documentation and provides guidance on additional documentation requirements, if anyProvides instruction for completing the HISI documentation process.Plant Installed Change Control Board (PICCB)Provides interpretive authority for the SLC process for plant installed software (reference TFC-CHARTER-55)Performs Verification and Validation (V&V) process of TFC-ENG-DESIGN-P-59Assures that the TFC-ENG-DESIGN-P-59 checklist items have been satisfied commensurate with software grade.Coordinates with the Project Lead for review and approval of all generated SLC deliverables and SCRs.Training DepartmentPrepares training plans and materials for Plant Installed SoftwareProvides user training identified in training plans.PROCEDURECyber SecurityMission Support Alliance (MSA) is the prime contractor responsible for the security of the Hanford Local Area Network (HLAN) and ICSN within the Hanford Accreditation Boundary (HAB). Approval by the Systems Engineering Change Control Board (SECB) for network-related hardware and all new and major versions of acquired software indicate adequacy for use within the HAB. Applications deployed on computers or servers directly connected to Hanford Local Area Network (HLAN) will be developed and deployed on standard HLAN hardware, using site standard software.Permission to utilize non-standard hardware or software connected to HLAN will be requested and approved via the Automatic Data Process (ADP) form. This hardware/software shall maintain HLAN-provided cyber security and virus scanning protection.Prior to the start of a project utilizing new technology, submit a Systems Engineering Change Board (SECB) questionnaire form for approval before the hardware/software is developed and/or acquired. Computers, servers, instruments, and network-related hardware not directly connected to HLAN shall utilize site standard hardware/software whenever possible. Permission to acquire non-standard hardware or software shall be requested and approved by the System Engineering Change Control Board (SECB). This hardware/software shall maintain an appropriate level of cyber security controls and virus scanning protection as described in HNF-53471, “Tank Farm Local Area Network (TFLAN) Supplemental System Security Plan.” Security requirements are imposed on software within the scope of this procedure by HAB in accordance with National Institute of Standards and Technology (NIST) 800 Series guidance.Software Project InitiationDuring project initiation, identification of the need for a software solution takes place. TFCBSM-IRM_HS-C-01 provides the procedural steps for these software project initiation activities and must be performed prior to proceeding. NOTE: All Plant Installed Software is documented in the HISI system, either as part of a larger HISI system, a grouping of like systems that may serve for repeatable use, or a standalone software system.If software is determined to be Grade Level A Safety Software using an ANSI/ISA 84.00.01-2004 Part 1 compliant Safety Instrumented System (SIS) Logic Solver, then development shall comply with TFC-ENG-DESIGN-P-43.All PersonnelFollow TFC-BSM-IRM_HS-C-01 and, if applicable, TFCENGDESIGN-P-43 during project initiation. NOTE: Training personnel in designing, developing, testing, or evaluating, a Safety Software or Quality Affecting application is critical for minimizing the consequences of software failure. This training is handled within the individual WRPS organizations that implement Plant Installed Software. Engineering ManagerAssign a Project Lead for the Plant Installed Software life cycle management activities for the software project.NOTE: If a Design Authority is not required for a software system, the steps in this procedure where they are designated an action are not applicable and the Design Authority action can be disregarded.Identify the designated Design Authority for software systems that are included in the technical baseline of structures, systems, and components (SSCs) defined in TFC-ENG-STD-43, and for any software designated as Safety Software.NOTE:? Applicability of the TOC Operational Readiness process for Pilot Projects is determined in accordance with TFC-PRJ-PM-C-06, which may require the use of an Operational Readiness Checklist or other achieving readiness tools.For a Pilot Project, request Readiness Representative (from the Commissioning organization) to prepare Operational Readiness Worksheet (Site Form A-6005-626) in accordance with TFC-PRJ-PM-C-04.Software Life CycleThe SLC model is represented by a modified waterfall that allows an iterative approach. Although the waterfall model is a theoretical model that is not practical to implement, it does represent the sequence of completion of life cycle deliverables. The SLC allows feedback to any previous SLC phase based on analysis and need for modification or approval to SLC phase products. The model also allows for rapid prototyping (refer to Attachment A) in lieu of the modified waterfall method. The elements of the SLC Model are described in Attachment B, and are to be utilized for this section (Section REF _Ref381626907 \r \h 4.3). REF _Ref381626919 \h \* Caps Figure?2 shows the Software Lifecycle graphically.Software PlanningDuring planning, life cycle phase deliverables are identified. Many of these deliverables are in the form of some type of document. Note that any deliverables generated through WRPS procurement activities by a third party outside of TFCENGDESIGNP12 (this procedure) control, are subject to the controls of TFC-BSM-IRM_DC-C-07. Selection of a third party to perform some or all SLC phase activities will affect the extent of application of this procedure, which will be identified in the SMP for that system.The software life cycle is implemented using a graded approach to quality that will be reflected in the SMP. The graded approach ensures that the level of analyses, documentation, and actions used to comply with requirements are commensurate with: a) the relative importance to safety, safeguards, and security; b) the magnitude of any hazard involved; c) the life cycle stage of a facility or item; d) the programmatic mission of a facility; e) the particular characteristics of a facility or item; f)?the relative importance to radiological and non-radiological hazards; and g) any other relevant factors. Refer to Attachment C for a listing of Software Quality Assurance (SQA) Work Activities and the graded approach. This implements the graded approach to quality described in TFC-PLN-112, as applicable, to the plant installed software development lifecycle.The graded approach does not allow required life cycle activities and associated deliverables to be omitted. However, for required work activities, the level or rigor applied to the activity or level of detail in the objective evidence or traceability of these required activities and deliverables can vary with consideration given to the level or risk or consequence of failure of the software.“Full” implementation of a particular SQA work activity requires that all essential deliverables are completed to the degree necessary to ensure and provide objective evidence that the work activity is performed in a traceable, planned, and orderly manner with thorough and detailed coverage of content. Recommended evidence at this level includes items such as diagrams, schemas, flowcharts, formalized and documented analysis techniques documented and released as a formal document. This is a high priority, detailed activity.“Graded” implementation allows for less formality in the work activity and associated deliverables. The same life cycle activities and deliverables are required for a “graded” implementation as for “full” implementation, but the objective evidence of compliance may include less detail, or mapping of equivalency to other documents with less structured format. “Optional” implementation allows for engineering determination whether documentation is required for the development process and/or business reasons. This determination is made in consultation with PICCB and Business Analyst concurrence, and if required, then managed as “Graded.”Attachment D contains the activities, the software life cycle phases, and associated SLC deliverables that are required for any Plant Installed Software application based on the classification grade of the software for its intended use and the type of software (Custom Developed, Configurable, or Acquired). Note that further guidance is available to support software grading criteria in DOE Publication SQASG-TP-14-01, “DOE Nuclear Safety Software Graded Approach Assessment Tool,” which should be considered when determining the depth of information that is required for each document.NOTE: The planning worksheets in Attachment D are not quality documents, but are, however, reviewed and approved by the PICCB in accordance with TFC-ENG-DESIGN-P-59 and controlled throughout the software life cycle.Project LeadDetermine the appropriate SLC documentation requirements for the project, based on the grade level determination and software type, using the planning worksheets in Attachment D.NOTE 1: Each document should contain a reference to the registered HISI index number, with the exception of a multi-case document.NOTE 2: As part of the documentation development, review, and approval process, the STSA/HISI Business Analyst, Technical Lead, Project Lead, Technical Support Manager, Quality Assurance Engineer, Information Resource Manager, SECB, and Software Review Board (SRB) are resources that are available to assist. These SLC tasks are outlined in the SMP verification and validation sections. NOTE 3: Configuration Management (CM) planning, or a Software Configuration Management Plan (SCMP), is typically part of the SMP. Section REF _Ref385232130 \r \h 4.6 can be referenced from a project’s SMP/SCMP for minimal CM activities, based on grade level. Otherwise, other acceptable processes and desk instructions, such as TFC-ENG-DESIGN-D-12.1, may be referenced from the SMP/SCMP.Design AuthorityIdentify the SLC documentation that is to be controlled as part of the Technical Baseline, if applicable.For software supporting SSCs, notify Commissioning Test Director of need to determine the test program level in order to prepare for proposed test scope. Refer to TFC-PRJ-SUT-C-08 for test program level definitions and process.Go to TFC-ENG-DESIGN-P-59, Section 4.1. DO NOT proceed until SLC planning worksheet is approved.Project Lead / Design AuthorityEnsure the SLC documentation is managed throughout the SLC as counterfeit items (CIs) and is uniquely identified and released, as specified, in accordance with TFCENG-DESIGN-C-25 and is maintained current as long as the software is in use and not retired.NOTE 1: The planning worksheet that was developed in Step 1, and approved by the PICCB in Step 2, identifies the SLC phase documents that are required for the software. Attachment E provides guidance on the documents to be produced.NOTE 2: Planning for the acquisition of any equipment, computer hardware and software, training, service contracts, etc., should start during initial planning, and may continue throughout the SLC phases, as needed. Requirements for acquisition activities are included in Section REF _Ref381628003 \r \h 4.5.NOTE 3: An SMP, based on project complexity and planning decisions, may also have other technical sections not related to planning that are added to the SMP as the software project progresses (e.g., System Requirements Specification).Project LeadDevelop appropriate planning phase documents in accordance with the grade and type of software specified in Attachment D using, if applicable, the “Software Management Plan (SMP) for Plant Installed Software ([release year]) Template,” located on the WRPS CIO Templates webpage. If a planning phase document is not required, enter a descriptive text entry that meets the general intent of template in the HISI Version Description (VDD) tab.Go to TFC-ENG-DESIGN-P-59, Section 4.2. DO NOT proceed until the SLC Planning Document(s) is approved.Once approved, place the planning document under configuration control with version control.Requirements PhaseNOTE 1: The required content of the Software Requirements Specification (SRS) is included in the templates, which reflects the minimum elements described in TFCBSMIRMSTD-01. Any omission of template content needs to be evaluated against the required content.NOTE 2: The SRS specifically addresses the software requirements separate from other system requirements.NOTE 3: Where both a Functional Requirements Document (FRD) and an SRS are required, the FRD can be a high level description of product functions within the SRS.Project LeadAs determined in the approved planning worksheet (see Section REF _Ref381626302 \r \h 4.3.1, Steps 1-2,) develop the FRD and/or SRS as instructed by the planning document (i.e., SMP) using the “Software Requirements Specification (SRS) for Plant Installed Software ([release year]) Template,” as appropriate, located on the WRPS CIO Templates webpage; or document in the SRS section of the SMP. Project Lead /Design AuthorityEnsure that the SRS :Addresses technical and software engineering requirementsIncludes, as applicable, the identification of operating system, function, interfaces, performance requirements, installation considerations, cyber security controls, design inputs, and any design constraints of the softwareContains specified requirements that are traceable throughout the software life cycle and testable.NOTE: The Acceptance Test Procedures (ATP) may have additional test cases developed (unit and system tests) and added in the design or development phase of the SLC.Project LeadIf required by Attachment D and reflected in the approved planning worksheet, develop ATP including:Test cases for all specified requirements and acceptance criteria; written in such a way as to demonstrate acceptance by successful test performanceAssurance that any resultant test data has sufficient detail for evaluation against acceptance criteriaTests that show performance over the range of operation for a controlled function and/or process per the SRS Evaluation, as appropriate, for technical adequacy through comparison of test results from alternative methods subject to the same acceptance criteria Demonstration that the software adequately and correctly performs all intended functions (i.e., specified software requirements)Demonstration, as appropriate, that the softwareProperly handles abnormal conditions and events as well as credible failuresDoes not perform adverse unintended functionsDoes not degrade the system either by itself, or in combination with other functions or CIs.If the software supports SSCs, and will involve installation at-field (other than HLAN locations), provide written requirements for software operations testing (e.g., Construction Acceptance Testing [CAT], Operational Acceptance Test [OAT]) to the Commissioning Test Director, in accordance with Test Program determined (e.g., TP-1, TP-2).If required by Attachment D and reflected in the approved planning worksheet, develop the Requirements Traceability Matrix (RTM), after completing the SRS, assuring that:The RTM reflects all requirements and software functions to be traceable and testableThe RTM is updated for any changes made to requirements.NOTE: SLC deliverables for the rapid prototyping method may include the requirements, design and a limited number of the testing deliverables (e.g.,?SRS, Software Design Description [SDD], and ATP) as defined in the planning document/SMP. These deliverables may remain in draft form until submitted for V&V of Development Phase activities as instructed by the planning document/SMP.Go to TFC-ENG-DESIGN-P-59, Section 4.3, to perform verification of FRD and/or SRS, unless the following condition is met:If the software life cycle methodology is specified as Rapid Prototyping in the planning documents/SMP, bypass this step as instructed by the planning document/SMP. DO NOT proceed until FRD and/or SRS is approved.If approved, place the FRD and/or SRS under configuration control with version control.If the FRD and/or SRS are included in the SMP, increment the version of the SMP and maintain under configuration control.Design PhaseProject LeadDetermine the design approach and develop the Software Design Description (SDD) using the appropriate template from the WRPS CIO?Templates webpage or, if specified in the SMP, document in the SDD section of the SMP. Ensure that the software’s operational environment is considered during the design phase.If desired, for Configurable and Custom Developed Plant Installed Software activities, perform design with the actual software development tools (e.g., Human Machine Interface screens, tag lists, functional logic diagrams, etc.) as part of the design process.If support software (i.e., software tools and system software) is utilized in plant installed software applications, identify these items as CIs AND keep them under version control, as part of the plant installed safety software.Design AuthorityFor Safety Software, perform Failure Mode and Effects Analysis (FMEA) for the software as described in Section REF _Ref369156544 \r \h 4.4.NOTE: SLC deliverables for the rapid prototyping method may include the requirements, design and a limited number of the testing deliverables (e.g.,?SRS, SDD, and ATP) as defined in the planning document/SMP. These deliverables may remain in draft form until submitted for V&V of Development Phase activities as instructed by the planning document/SMP.Go to TFC-ENG-DESIGN-P-59, Section 4.3 to perform verification of the SDD, unless the following condition is met. If the software life cycle methodology is specified as Rapid Prototyping in the planning documents/SMP, bypass this step as instructed by the planning document/SMP. DO NOT proceed until the SDD is approved.If approved, place the SDD under configuration control with version control.If the SDD is included in the SMP, increment the version of the SMP and maintain under configuration control.Development PhaseTechnical LeadUtilize software coding standards and standard practices as referenced in the SMP.Develop the software code in accordance with the SDD and other appropriate SLC documentation.Project LeadIf required by the SMP, develop unit, integration and system tests, collectively referred to in TFCENG-DESIGN-P-59 as “Software Test Procedures,” and, as appropriate, the code walk-through procedures, as instructed by the V&V plan.If additional test cases have been identified during the design or development phase of the SLC, make any necessary updates to the ATP (also referred to as “Software Test Procedures”).Technical LeadPerform and document the results of the applicable tests and, as appropriate, the code walk-through procedures, as instructed by the SMP.Project LeadIf required by the SMP, develop user documents (e.g., operating manual) and administrator documents (e.g., software installation procedures, maintenance manual) for the software.Include instructions for use within the limits of the software capabilities.If required by the SMP, develop a Software Installation Plan (SIP).TrainingIf required by the SMP, develop a training plan based on the training requirements.Project LeadAssist Training to develop training material per the training plan.NOTE 1: If permitted by the SMP, development may utilize Rapid Prototyping.NOTE 2: If utilizing Rapid Prototyping other deferred SLC deliverable are reviewed prior to verification and validation activities. Go to TFC-ENG-DESIGN-P-59, Section 4.3 to perform verification of the SDD, unless the following condition is met.DO NOT proceed until SLC development deliverables are approved.NOTE: Version control should be applied to in-process deliverables between formal releases.Technical LeadOnce approved, place deliverables under configuration control. Software Testing PhaseProject LeadEnsure that software forces, patches, or other changes added during software development or other phase documentation to accommodate verification and testing are controlled as described in the SCMP that is developed during planning in accordance with Section REF _Ref443577677 \r \h 4.6. NOTE: Testing performed at this phase is typically equivalent to Factory Acceptance Testing (FAT) for SSCs as described in TFCPLN26 and/or an Acceptance Test Procedure (ATP). In some instances, completions of these test(s) are suitable for turnover to operations, especially for HISI grade level E and N/A level Plant Installed Software—refer to the planning document/SMP for specific requirements.Ensure software testing is controlled, performed, and documented in accordance with the requirements in the “Software Test Procedures,” acceptance testing and/or instructions. This includes:Use of appropriate environmental conditions, tools and test equipment to ensure test requirements and acceptance criteria are satisfied.Testing is performed in an off-line test environment, whenever possible, or with software isolated from production and/or production areas.Assurance that test documentation generated during test performance contains, as applicable: software tested, associated hardware tested, test equipment and calibrations, date of test, indication of tester or data recorder, simulation models used, where applicable, test exceptions and problems, test results and applicability, and actions and resolution with any exceptions and/or problems noted.For Safety Software, testing shall be designed to demonstrate that the software properly handles expected normal conditions, abnormal conditions, events, and credible failures identified through the performed FMEA.If Otherwise Acquired Software, then any associated test procedure is to include test cases to demonstrate capabilities of software within its limitations of intended use.Design Authority For software supporting SSCs, determine or confirm the test program level in accordance with the SMP. Refer to TFC-PRJ-SUT-C-08 for test program level definitions and process.Project LeadIf the software involves installation at-field (other than HLAN locations), develop the software operations testing (e.g., Construction Acceptance Testing [CAT] Operational Acceptance Test [OAT]) documentation in accordance with the V&V Plan, TFC-PRJ-SUT-C-02 for test program Level 1 and 2 testing, and TFC-ENG-DESIGN-C-18, for test program Level 3 testing and from additional requirements documented within the SMP.Ensure that software forces, patches, or other changes used during software testing are controlled. Develop an Acceptance Testing Report (ATR) for V&V, or attach report of testing results to the SCR, if applicable.If an SCR, proceed to Section 4.3.8.3, step 11.NOTE: Approval of SLC software testing phase documents may also involve the review of operational test documents such as the CAT and OAT. These reviews can happen simultaneously or sequentially.Go to TFC-ENG-DESIGN-P-59, Section 4.3. If the ATR/testing results are acceptable (including minor exception reports with explanation of why acceptable without closure), proceed to next step.Otherwise, log test-related errors and/or issues as required, control the resolution of any errors and/or issues in accordance with the SMP, implement necessary SLC phases to be in compliance with the SMP, and proceed back to test as required.Once approved, place the testing deliverables under configuration control with version control.If the testing documentation is included in the SMP, increment the version of the SMP and maintain under configuration control.DO NOT proceed until SLC testing deliverables are approved.If the software application to be deployed is to be connected to the HLAN, obtain the required approvals from the Production Readiness Review Board (PRRB) using the HISI registration and approval process.If software is non-SSC and HLAN deployed, perform the following:Engineering ManagerReview the HISI Version Description section submitted by the Project Lead.Approve the HISI Version Description.Project LeadUpdate the baseline and store the software in accordance with the SCMP section of the SMPInstall software in accordance with the planning document/SMP Software Installation Plan.Proceed to Section REF _Ref381797198 \r \h \* MERGEFORMAT 4.3.7 since HLAN installation is managed by the site IRM Service Provider.Operational Testing PhaseProject LeadComplete a Process Hazard Analysis (PrHA) Screening in accordance with TFC-ENG-DESIGN-C-35. Obtain an Unreviewed Safety Question (USQ) evaluation for software in accordance with the requirements stated in TFCENGSBC03.Ensure that the USQ Screening Form is completed, and as required, the USQ Determination Form is also complete (all sections).NOTE: Some software changes require online edits of operational software rather than download of software. The control and acceptance of these online edits (e.g., independent visual verification of change) must be performed in accordance with work package.Download and/or online edit software, as applicable, with work packages per the Production Operations work control found in TFC-OPS-MAINT-C-01.NOTE: This step applies to the operational testing phase of the SLC, either for new Custom Developed or Configured Plant Installed Software. Testing at this phase is equivalent to CAT and OAT for SSCs as described in TFCPLN26.Deployment Test Team (as defined in SMP)Control, perform, and document the operational software testing in accordance with the requirements in the software test procedure (e.g.,?CAT, OAT, work package) and/or TFCPRJSUTC03. Ensure that all software forces, patches, or other changes used during software testing are controlled; for software associated with SSCs, use TFCPRJSUT-C-03 and the temporary modifications and bypasses procedure TFCOPSOPER-C-11, as applicable.Project LeadDevelop operational test report(s) which must include: the software program tested, software hardware tested, any test equipment and calibrations (where applicable), test dates, identification of tester or data recorder, and acceptability of testing performed.If the operational testing results are acceptable (including minor exception reports with explanation of why acceptable without closure), place the testing deliverables under configuration control with version control and proceed to next step. Otherwise, log test related errors and/or issues as required.Control the resolution of any errors and/or issues in accordance with the SMP.Implement necessary SLC phases to be in compliance with SMP, and proceed back to test as plete the Version Description section of the HISI entry and submit for approval.Engineering Manager Review the HISI Version Description section submitted by the Project Lead.NOTE: For testing of an SCR, the software version installed in the field may lead the approved software version stated in HISI by one increment until approvals are completed.Approve the HISI Version Description.Turnover for OperationsProject LeadComplete the Version Comments/Additional Information Summary section of the HISI Version Description, entering the Plant Installed Software release date for the implementation date and submit for approval.Prepare baseline configuration package for release, including:The source control process (such as MKS Source Integrity), and the formal baselines for all product versions of software and SLC documentation per the SCMPThe baseline release for the software Project as documented in the Project’s SMP For Quality Affecting software (grade level A-D), the CIs that must be released for a baseline numbered version include uniquely identifiable CIs to be controlled via the SCMP.Ensure that a periodic, in-use test procedure is developed to permit confirmation of acceptable performance of the computer program in the operating environment.For Safety Software (Levels A-C), update the Safety Software Inventory in HISI.Submit the baselined life cycle deliverables to Document Control for release in accordance with TFC-ENG-DESIGN-C-25.Training /Project LeadEvaluate whether the training materials are written as instructed in the Project’s SMP and in accordance with TFC-BSM-TQ_ADD-C-01. Safety software training must be coordinated with the WRPS Training Organization Training personnel to ensure that the following components are adequate:Budgeted cost and scheduleDesignDevelopment approachValidationCertification as required for use and/or administration and/or maintenance related to the Safety Software application. These areas are critical for minimizing the consequences of software failure.NOTE: Training personnel in using a Safety Software application is critical for minimizing the consequences of software failure. Designated Trainer (defined in Training Plan)Provide user training as identified in the SMP that implements the training plan with training materials, if it’s a Safety Software application: Conduct the training with documented and qualified instructors, as instructed via the project’s SMP. Keep records of the training sessions. Document requirements for recertification as specified in the training plan.If an SCR, proceed to Section 4.3.8.3, step 13.Operations and Maintenance PhaseProject LeadAfter the Plant Installed Software is approved for use and installed in the operating environment, control the use of the software in accordance with instruction in the project’s SMP, including control of the following , as a minimum:Application documentationAccess control specificationsSoftware problem reporting and corrective actionsIn-use testsConfiguration change control process.4.3.8.1Problem Reporting and Corrective ActionThe problem reporting and corrective action process ensures formal methods for software problem reporting, and corrective action for software errors and failures are established, maintained, and controlled. If there is a software error and/or failure, and it affects safety software (Levels A-C), complete a Problem Evaluation Request (PER), if one does not already exist, via TFC-ESHQ-Q_C-C-01 and reference the resulting SCR number in the PER. If there is a software error and/or failure, and it affects non-safety software (Levels D & E), follow guidance for problem resolution within the SMP for the affected software.4.3.8.2In-Use TestingProject LeadPerform in-use tests after the software is installed on a different computer, or when there are significant changes in the operating environment (e.g., operating system change, hardware changes).Identify frequency and perform periodic in-use manual or automatic self-check in-use tests for software in which software errors, data errors, computer hardware failures, or instrument drift can affect required performance. These considerations are a part of the FMEA for Safety Software.Generate records of in-use tests results that shall include the software program tested, software hardware tested, any test equipment and calibrations (where applicable), test dates, identification of tester or data recorder, and acceptability. 4.3.8.3Change ControlManage the software change control process as identified in the SMP. The method used for software change control will vary based on the affected CIs proposed for modification and the type of change requested.Plant Installed Software changes include software upgrades, error corrections, enhancements, and improvements to the baseline configuration, which affect software function, design, structure, or logic or a controlling function. Major changes to COTS and/or support software applications will require a new SECB request. An SCR is used to manage these software changes.Consideration needs to be given to the following:Type of change initiator (error, enhancement, improvement, upgrade, change in business practice, other)Baseline impact (Engineering Change Notice [ECN], Modification Traveler [MT], USQ, PrHa, FMEA)Potential for Grade Level impact – Change may affect the intended use and grade level assignment. All components must be controlled at the highest component grade level. Change RequesterInitiate an SCR, to document: Description of the changeBasis for the changeIdentification of impacted baseline elements.Project LeadEvaluate the impact of the proposed SCR including the impact to other CIs and complete the ANALYSIS section of the SCR. Ensure that for any changes, that the baseline CIs are evaluated, and if impacted, then manage per the SMP and add to the existing baseline. If the SCR impacts Safety Software using an SIS Logic Solver, use ANSI/ISA-84.00.01-2004, Part 1, for all SLC activities related to that device.If a Safety System is affected and the associated SCR was the result of other than a defined error, for example, a human factors issue, evaluate and assess the impact to the users and training and then alert users via a training update, or other mechanism identified in the SMP.If a Safety System is affected, ensure that the originator of the SCRs is kept informed of the SCR status via the method documented in the SCMP. For example, this is acceptable to be via email based on SCR updates.Go to TFC-ENG-DESIGN-P-59, Section 4.4 to perform ANALYSIS review of the SCR.DO NOT proceed until SCR ANALYSIS section?is completed and approved.If the SCR is not approved, retain the SCR for historical reference and exit this procedure.Evaluate affected baseline documentation (SLC document modification, reviews, and approvals) to determine the appropriate method for release and distribution in accordance with TFCENGDESIGN-C-25.NOTE:? Applicability of the TOC Operational Readiness process for Pilot Projects is determined in accordance with TFC-PRJ-PM-C-06, which may require the use of an Operational Readiness Checklist or other achieving readiness tools.For Pilot Projects, request Readiness Representative (from the Commissioning organization) to prepare Operational Readiness Worksheet (Site Form A-6005-626) in accordance with TFC-PRJ-PM-C-04.If the modification is associated with an SSC, determine the need for a MT in accordance with TFCENGDESIGNC-56.If applicable, for software modification supporting SSCs, notify Commissioning Test Director of need to determine the test program level in order to prepare for proposed test scope.? Refer to TFC-PRJ-SUT-C-08 for test program level definitions and process.?If the modification is associated with an SSC, and will involve installation at-field (other than HLAN locations), provide written requirements for software operations testing (e.g., Construction Acceptance Testing [CAT], Operational Acceptance Test [OAT]) to the Commissioning Test Director, in accordance with Test Program determined (e.g., TP-1, TP-2).Technical LeadImplement the software change by performing the affected life cycle activities and ensure appropriate completion of SCR Section DESIGN/DEVELOPMENT/TESTING.Update all affected SLC phase products per applicable subsections of Section REF _Ref443577741 \r \h 4.3 prior to closure of the SCR.NOTE: The test strategy may include reuse of previously validated test documentation and/or developed supplemental test documentation (e.g.,?from a validated test procedure/test case/test step library).Prepare an SCR acceptance test procedure to fully test the scope of the SCR.Ensure the SCR acceptance test procedure addresses successful problem resolution, any potential regression analysis and testing, and possible operational testing, and possible acceptance testing and deployment testing, as required per the Project’s SMP.Proceed to Section REF _Ref381776019 \r \h \* MERGEFORMAT 4.3.5 to perform appropriate testing per the SMP. Go to TFC-ENG-DESIGN-P-59, Section 4.4 to perform DESIGN/DEVELOPMENT/TESTING review of the SCR.DO NOT proceed until SCR DESIGN/DEVELOPMENT/ TESTING section is completed and approved.If operational testing is to be performed at the field prior to turnover to operations, then proceed to Section REF _Ref385236250 \r \h \* MERGEFORMAT 4.3.6 and REF _Ref381797198 \r \h \* MERGEFORMAT 4.3.7 to perform appropriate testing per the SMP.Go to TFC-ENG-DESIGN-P-59, Section 4.4 to perform DEPLOYMENT approval of the SCR.DO NOT proceed until SCR DEPLOYMENT section is completed and approved.Record the appropriate software release version number on the SCR and/or ECN.Submit the completed SCR, ECN, and/or MT to Document Control for release in accordance with TFC-ENG-DESIGN-C-25.Retirement PhaseProject LeadRefer to TFC-BSM-IRM_HS-C-01 for the Software Retirement procedure.End of sections related to SLC phases, exit procedureFailure Modes and Effects AnalysisProject Lead/Design AuthorityIf Grade Level A Software that is part of an SIS Logic Solver subject to ISA84, use TFC-ENG-DESIGN-P-43 for the guidance on the Failure Modes and Effects Analysis (FMEA) to evaluate the credible failure modes of Plant Installed Software in its operating environment to determine if the failure or improper performance could have an adverse impact on the safety function of equipment, materials, or facility operations. Otherwise, for Grade Level A (non-SIS), B and C software, use FMEA guidance in Attachment F.Create a list of abnormal conditions, abnormal events, and credible failures when the FMEA is performed.Update affected SLC documents (e.g., Software Requirements Specification, Acceptance Test Procedure), or project-specific SMPs as necessary.Acquisition ActivitiesAcquisition activities shall follow the acquisition plan initiated during the software planning activities specified in Section REF _Ref381626302 \r \h 4.3.1. Activities involving the use of the Hanford Local Area network (HLAN) will require contracted support from the IRM Service Provider in accordance with the WRPS contract. Instructions shall be included in the “Procurement and Supplier Management” section of the planning document/SMP.Project Lead or Technical LeadBefore purchasing or acquiring software, ensure the End User License Agreement (EULA), when required, allows for enterprise, commercial, and/or government use.If the EULA does not allow commercial/enterprise/government use, perform actions to gain approval for intended use or return to TFCBSMIRM_HS-C-01 to revisit Alternatives Analysis and select alternate software.Contact the Procurement group for assistance, if needed. NOTE 1: ALL software acquisitions made from non-Hanford sources, including freeware and shareware, must be documented and approved on an Automatic Data Process (ADP) Approval form. Although the word “form” is used, the ADP process is electronic.NOTE 2: ADP Points of Contact are maintained on the WRPS CIO – Software Acquisition webpage.NOTE 3: ALL new acquired software and major acquired software revisions must be submitted to SECB for plete the Automatic Data Process Approval Form in accordance with TFCBSMCP_CPR-C-01.Determine appropriate procurement method, applicable. Refer to TFCBSM-CP_CPR-C-01 for non-safety, non-quality affecting software, or TFCBSMCP_CPR-C-05 or TFC-BSM-CP_CPR-C-06 for quality-affecting software.Do NOT purchase quality-affecting software (Levels A-D) using TFCBSMCP_CPR-C-01 (P-Card).For Grades A, B, or C software or software services procured from a qualified NQA-1 supplier listed on the WRPS Evaluated Supplier List (ESL), or the Mission Support Alliance (MSA)/Acquired Verification Services (AVS) ESL, proceed to Section 4.5.1. For Grades A, B, or C software that is not procured from a qualified NQA-1 supplier listed on the WRPS ESL or the MSA/AVS ESL, and for Grade D non-safety quality affecting software and software services, proceed to Section REF _Ref369159160 \r \h \* MERGEFORMAT 4.5.2. For Grades D software or software services procured from a qualified NQA-1 supplier listed on the WRPS ESL, or the MSA/AVS ESL, utilize appropriate procurement method from step 3 above.For other types of non-safety, non-quality affecting software or software services (Grade E or N/A), perform per Section? REF _Ref369159169 \r \h \* MERGEFORMAT 4.5.3.Procured Software and Software Services (Grades A-C)NOTE: An NQA-1 approved supplier is acceptable only if the scope of the evaluation of the supplier for placement on the WRPS or MSA/AVS ESL included the flow down of software requirements to the supplier from TFC-PLN-02.Project Lead /Design AuthorityPrior to awarding a contract for procurement of acquired software from an NQA-1 approved supplier, verify that the supplier is on the WRPS ESL or MSA/AVS ESL in accordance with TFCESHQQ_ADMC09 for the specified capabilities and limitations for intended use of the software.If these requirements cannot be met, proceed to Section REF _Ref369159160 \r \h 4.5.2 and procure the software as Otherwise Acquired Software.NOTE: The Statement of Work (SOW) may serve as the Software Requirements Specification (SRS) as long as the content meets the requirements of this procedure and associated template for the SRS.When specifying requirements for procurement of services using a Statement of Work (SOW) in accordance with TFCBSMCP_CPR-C05, provide the Buyer’s Technical Representative (BTR) with sufficient software specifications for inclusion in the SOW including:Scope of workTechnical requirementsQuality Assurance (QA) Program requirementsDocumentation requirementsReporting of non-conformancesProcurement document review and changesSpecifications for requirements for safety, security, functionality, and performanceProcess steps used in developing and validating the software, including any documents to be deliveredRequirements for supplier notification of defects to WRPS, new releases or other issues that impact operation. Rights of Access to supplier’s sub-tier suppliers’ facilities and records (if applicable) are not included in a SOW but are addressed in the Subcontract General Provisions included in every subcontract issued by WRPS Procurement.Include mechanisms for WRPS to report defects to the supplier or means to actively check for supplier notices (errata, user notices, etc.) in the SMP.Ensure appropriate cyber security considerations are included in the SOW. Complete the “Acquisition” section of the SMP to identify the scope of work, controls, and deliverables contracted to non-WRPS organizations.NOTE: WRPS is responsible for the appropriate life cycle activities and associated deliverables upon acceptance of the software from the supplier.Receive the software and deliverables specified by the SOW from the supplier.Enter supplier documents as records in accordance with TFC-BSM-IRM_DC-C-07 or TFCBSMCP_CPR-C-05.Place the resulting documentation and associated software under configuration control to establish the current baseline per the configuration control section of the SMP.Continue development of the Software Life Cycle in the applicable section in accordance with the planning documentation of the SMP.Otherwise Acquired Quality Affecting Software (Grades A-D)Otherwise Acquired Software is software or software services that have NOT been previously approved under a program consistent with TFC-PLN-02 (not included on the WRPS ESL or MSA/AVS ESL) for use in its intended application. This includes software that is received through DOE distribution or other means not requiring procurement action. NOTE 1: Since the supplier is not expected to have an NQA-1 compliant program, there may or may not be any deliverables or interaction with the supplier.NOTE 2: Means to actively check for supplier notices should be included in the SMP.Project Lead / Design AuthorityWhen specifying requirements for procurement using an SOW in accordance with TFCBSMCP_CPR-C-05, provide the BTR, or assigned representative, with sufficient software specifications for inclusion in the SOW, ensuring appropriate cyber security considerations are included.Project LeadReceive the software and deliverables specified from the supplier.File any supplier documents in accordance with TFC-BSM-IRM_DC-C-07.In order to dedicate or evaluate the software, install software in a non-Production environment, whenever possible.Place the software and any documentation received under configuration control per the configuration control section of the SMP.If software is Safety Software (Grades A-C), proceed to Section 4.5.2.1.If software is Non-Safety, Quality Affecting Software (Grade D), proceed to Section 4.5.2.2.4.5.2.1Dedication of Safety Software (Grades A-C)Project Lead/Design AuthorityPlan and perform commercial grade dedication (CGD) of the otherwise acquired software in accordance with TFC-ENG-DESIGN-C-65 for software that affects performance of a SSC safety function or provide controls necessary for adequate protection from nuclear facility or radiological hazards; or TFC-ENG-DESIGN-C-15 for software that is installed or embedded in physical plant safety SSCs.Project LeadPlace the software and completed dedication package under configuration control to establish the current plete the Acquisition documentation section in the SMP to identify the scope of work, controls, and deliverables contracted to non-WRPS organizations.Re-dedicate subsequent modifications to dedicated software.4.5.2.2Evaluation of Non-Safety, Quality Affecting Software (Grade D)Project LeadDevelop a software evaluation plan, which may be included in the Acquisition section of the SMP, that identifies the activities to be evaluated that are necessary to ensure the adequacy and security of the otherwise acquired software to support operation and maintenance identified in the Acquisition Section of the SMP. PICCBConduct a review of the software evaluation plan.Project LeadOnce approved, place the software evaluation plan under configuration control with version control.Identify the capabilities and limitations for intended use of the software.NOTE: Test plans and test cases may be provided by the supplier and may be considered when developing internal test cases to fully exercise the capabilities within the limitations for intended use.Develop or utilize existing test plans and test cases as the method of acceptance to demonstrate the capabilities within the limitations. PICCBConduct a review of the test plans and test cases.Project LeadOnce approved, place the test plan(s) and test cases(s) under configuration control with version control.NOTE: Instructions for use are typically provided by the supplier.Develop or identify instructions for use (e.g., user manual) within the limits of the evaluated capabilities.Perform the evaluation of the software in accordance with the software evaluation plan.Software Technical Support AnalystReview the results of the evaluation and the actions necessary to accept the software.Document any exceptions from the documentation requirements and provide a justification for acceptance.Software Owner Approve the results of the evaluation.Software Owner or Project LeadComplete the Acquisition documentation in the SMP to identify the scope of work, controls, and deliverables contracted to non-WRPS organizations.Place the resulting documentation and associated software under configuration control to establish the current baseline.Otherwise Acquired Non-Safety, Non-Quality Affecting Software (Grades E, N/A)Project Lead or Technical LeadReceive the software and deliverables from the supplier.File supplier documents in accordance with TFC-BSM-IRM_DC-C-07 or TFCBSMCP_CPR-C-05.Run the software to ensure it functions properly.Evaluate any exceptions from the user documentation and determine acceptability.Software Owner or Project LeadComplete the Acquisition documentation in the SMP, if required to identify the scope of work, controls, and deliverables.Place the resulting documentation and associated software under configuration control to establish the current baseline, if required.Configuration ManagementConfiguration management (CM) activities span the software life cycle and provide objective evidence that SLC deliverables are properly controlled.NOTE: CM planning, or a SCMP, is typically part of the SMP. Section REF _Ref385232130 \r \h 4.6 can be referenced from a project’s SMP/SCMP for minimal CM activities, based on grade level. Otherwise, other acceptable processes and desk instructions, such as TFC-ENG-DESIGN-D-12.1, may be referenced from the SMP/SCMP.Project LeadIdentify CIs during software planning activities described in Section? REF _Ref381626302 \r \h \* MERGEFORMAT 4.3.1.Control changes to CIs during the operations and maintenance phase described in Section REF _Ref381626365 \r \h \* MERGEFORMAT 4.3.8.Engineering ManagerEnsure configuration status accounting activities are in place to track the status of CIs throughout the software life cycle and during changes.Ensure that configuration audits and reviews are conducted at a frequency defined in SMPs, to verify that CIs reflect required functional and physical characteristics; and that CIs are properly managed in the software baseline under configuration control.DEFINITIONSAcquired Software. Types of software that are procured by WRPS on the commercial market. This includes commercial off-the-shelf software (COTS), such as operating systems, database management systems, compilers, software development tools, and commercial calculation software and spreadsheet tools. Configurable software is a form of acquired software. Examples include freeware, shareware, procured commercial off-the-shelf, etc.Configurable Software. Software supplied with a system requiring specific configuration based on the process or machine-controlled functionality using the commands available within the supplied system. Configurable Software is a form of acquired software because the license is procured from the vendor with proven source code, which must be configured for the application.Custom Developed Software. Software developed for a specific application to achieve specific functionality not normally available from an acquired product or configurable software. Examples of custom developed software include material inventory and tracking database applications, management information systems, accident consequence applications, and control system applications.Otherwise Acquired Software. This includes any Acquired Software (procured) that was not developed under TFC-PLN-02 equivalent controls but will be commercially grade dedicated to support a safety function, or safety operational activity. This may include software that is procured in accordance with WRPS procurement processes in which procurement documents require reporting of software errors. Pilot Project. New activity, or modification to existing activity, of limited scope that will be developed and deployed as plant installed software for an evaluation period. Plant Installed Software. Any software, application, database, or computer program that is developed, procured, or maintained to support an SSC, or other management information system supporting operations. This definition includes, but is not limited to, DCS, PLCs, human-machine interface (HMI) software, databases, and similar computer programs. Plant Installed Software also includes computer programs or routines designed to perform some general support function required by other application software, by the operating system, or by system users (e.g., networking software, communications software, graphics development/editing software, maintenance or monitoring software, text editing software). Plant Installed Software will be acquired, configurable or custom developed, and does not include utility calculation software (spreadsheets) that are covered by TFC-ENG-DESIGN-C-32.Programmable Electronics (PE) (Ref. ANSI/ISA-84.00.01-2004 Part 1). This refers to a PE logic solver contained in equipment such as a PLC or a DDCS. Logic solvers used for safety applications are typically certified by third party testing organizations as being suitable for use.Safety Instrumented Systems (Ref. ANSI/ISA-84.00.01-2004 Part 1). Also referred to as SIS; a “system used to perform safety instrumented functions.” An SIS is composed of any combination of sensor(s), logic solver (s), and final elements(s), and may (or may not) include software.Software Test Procedures. Any procedure developed to test software during any given phase of software development or modification. Software test procedures include those procedures and documents prepared for test plans and cases, offline tests, unit tests, system tests, integration tests, acceptance tests, regression tests, factory acceptance tests, construction acceptance tests, operational acceptance tests, and in-use tests.RECORDSThe following records are generated during the performance of the procedure:Software media (in accordance with specific SMP)SLC Phase Documentation (as selected for software from Attachment D)SCRs (SPF-017).The record custodian identified in the Company Level Records Inventory and Disposition Schedule (RIDS) is responsible for record retention in accordance with TFCBSMIRM_DCC02.SOURCESRequirementsTFC-BSM-IRM_HS-C-01, “Software Development, Implementation, and Management.” HYPERLINK "" TFC-BSM-IRM-STD-01, “Software Life Cycle Standard.”TFC-BSM-IRM-STD-02, “Software Configuration Management Standard.” HYPERLINK "" TFC-PLN-02, “Quality Assurance Program Description.”TFC-PLN-03, “Engineering Program Management Plan.”TFC-PLN-50, “Quality Implementation Plan.”ReferencesANSI/ISA-84.00.01-2004 Part 1, “Functional Safety: Safety Instrumented.” Systems for the Process Industry Sector — Part 1: Framework, Definitions, System, Hardware and Software Requirements.”ASME NQA-1-2008, w/09a, “Quality Assurance Requirements for Nuclear Facility Applications.DOE Guide 414.1-4, “Safety Software Guide for Use with 10 CFR 830 Subpart A, Quality Assurance Requirements, and DOE O 414.1C, Quality Assurance.”HNF-1901, “Technical Baseline Summary Description for the Tank Operations Contractor.”IEEE Std 828-1998, “IEEE Standard for Software Configuration Management Plans.”IEEE Std 829-1998, “IEEE Standard for Software Test Documentation.”IEEE Std 830-1998, “IEEE Recommended Practice for Software Requirements Specifications.”IEEE Std 1012-1998, “IEEE Standard for Software Verification and Validation Plans.”SQASG-TP-14-01, “DOE Nuclear Safety Software Graded Approach Assessment Tool.”TFC-BSM-CP_CPR-C-01, “Purchasing Card (P-Card).”TFC-BSM-CP_CPR-C-05, “Procurement of Services.”TFC-BSM-CP_CPR-C-06, “Procurement of Items (Materials).”TFCBSMIRM_DC-C-02, “Records Management.”TFC-BSM-IRM_DC-C-07, “Vendor Processes.”TFC-BSM-IRM_SE-C-01, “Computer Security.”TFC-BSM-IRM-STD-02, “Software Configuration Management Standard.”TFC-BSM-TQ_ADD-C-01, “Conduct of Training Administration.”TFC-CHARTER-55, “Plant Installed Change Control Board.”TFC-ENG-DESIGN-C-06, “Engineering Change Control.”TFC-ENG-DESIGN-C-15, “Commercial Grade Dedication.”TFC-ENG-DESIGN-C-18, “Testing Practices.”TFC-ENG-DESIGN-C-25, “Technical Document Control.”TFC-ENG-DESIGN-C-32, “Utility Calculation Software Management.”TFC-ENG-DESIGN-C-34, “Technical Requirements for Procurement.”TFC-ENG-DESIGN-C-35, “Process Hazard Analysis Determination and Technique Screening.”TFC-ENG-DESIGN-C-47, “Process Hazard Analysis.”TFC-ENG-DESIGN-C-56, “Modification Traveler.”TFC-ENG-DESIGN-D-12.1, “Plant Installed Software Configuration Management.”TFC-ENG-DESIGN-P-43, “Control Development Process for Safety Significant Safety Instrumented Systems.”TFC-ENG-DESIGN-P-59, “Plant Installed Software Quality Assurance.”TFC-ENG-SB-C-03, “Unreviewed Safety Question Process.”TFC-ENG-STD-43, “TOC System Engineering Program Systems Identification.”TFC-ENG-STD-46, “Technical Baseline Management.”TFC-ESHQ-Q_ADM-C-09, “Supplier Quality Assurance Program Evaluation.”TFC-ESHQ-Q_C-C-01, “Problem Evaluation Request.”TFC-OPS-MAINT-C-01, “Tank Operations Contractor Work Control.”TFC-OPS-OPER-C-11, “Equipment Temporary Modifications and Bypasses.”TFC-PLN-26, “Test Program Plan.”TFC-PLN-112, “Graded Approach to Quality.”TFC-PLN-138, “Implementation Plan for ISA 84 (Safety Instrumented Systems).”TFC-PRJ-PM-C-04, “Startup Notification Report.”TFC-PRJ-PM-C-06, “Operational Readiness Process.”TFC-PRJ-SUT-C-02, “Operational Acceptance Test Preparation.”TFC-PRJ-SUT-C-03, “Conduct of Testing.”TFC-PRJ-SUT-C-04, “Test Results Report Preparation.”TFC-PRJ-SUT-C-08, “Test Program Worksheet Preparation.”Figure? SEQ Figure \* ARABIC 1. WRPS Plant Installed Software Procedural Flowdown.Figure? SEQ Figure \* ARABIC 2. Plant Installed Software Life Cycle Waterfall Method with Feedback and Rapid Prototyping Provision.ATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC A - RAPID PROTOTYPING VORTEX DEVELOPMENT METHODOverview:In a traditional waterfall method software project, the process is such that requirements lead to design, which leads to development. That is, the software requirements are first fully defined and released as a baseline document. This baseline document cascades to design definition and release of a design document. Finally, the design document leads the development phase coding and baseline code version release to testing per the Software Management Plan, and any associated V&V and planning documents, based on Grade Level A-E. There can also be ‘upstream’ movement in the waterfall method, for example, if an unachievable design element is identified this may necessitate movement back to the requirements phase to modify that requirement and thus the requirements document, and then re-release as a formal change to the baseline document for that phase.The waterfall method invokes tight formal control, and with this rigor, introduces additional formal V&V reviews for any phase deliverables, plus the overhead of generating V&V traveler documentation. If there is any documentation flux, this leads to a) increased resource costs and b) schedule impacts, based on the quantity of formal baseline document modifications required and the associated V&V activities to manage these requests to closure. An alternative to this classical method is the rapid proto-typing method, also referred to as the “Vortex” method. The rapid prototyping method is defined as a process of combining the Software Life Cycle (SLC) V&V management for the requirements, design and development phases and the associated SLC phase deliverables, for all Grade Levels of software. Rapid Prototyping Management of the SLC Requirements, Design, and Development Phases:The entry point for the rapid proto-typing method is just after software project management planning at the start of software requirements development. After the entry point, the SLC phases being managed are in the top cycle of the Vortex. The Vortex concept is shown in REF FigureE1 \h \* MERGEFORMAT Figure?A-1. The exit point is just before the software project’s SLC acceptance testing phase, and is referred to as the “Beta-point.” The Beta-point is defined as that point in the SLC where all baseline documents and baseline code are ready to be put under configuration management, and may be formally released as a baseline ready for the acceptance testing phase of the SLC waterfall. ATTACHMENT?A - RAPID PROTOTYPING VORTEX DEVELOPMENT METHOD (cont.)Figure?A-1. Rapid Prototyping Vortex Method Concept.ATTACHMENT?A – RAPID PROTOTYPING VORTEX DEVELOPMENT METHOD (cont.)The top cycle (also known as pre-Alpha, Vortex Stage 1) starts with a basic requirements document, leading to a basic design document, and then leading to initial coding of modules. Testing documents and Requirements Traceability Matrices (RTM) can also be prepared to allow for informal testing. Once the top cycle process is underway, it is permitted for feedback loops to be established between all elements of the SLC, without configuration management being invoked at any level, except for that dictated by the SMP. This methodology allows extremely agile development where straw models can be established in rapid fashion, and then team reviews lead to improvement and/or changes and/or modifications. A form of to-do lists is kept by the Technical Lead to track comments that are made, and any errors. The code level at this phase is termed ‘Pre-Alpha’ and is not ready for any formal changes or baselines due to the flux level. When the technical lead determines that the top cycle requirements and design are nearly complete (90%) and that the code has reached an acceptable level of issues being generated from the informal testing process, then the method enters the second cycle. The second cycle shown in REF FigureE1 \h \* MERGEFORMAT Figure?A-1 is smaller in diameter (as development is much closer to a Beta level product) and the shape starts resembling that of a tornado Vortex. In second cycle (also known as Vortex Stage 2) , the code enters an ‘Alpha’ level, when Pre-Release (PR) code baselines (e.g., PR.0.0.0 identification) are initiated and issues are tracked from any informal testing in a Pre-Release type of informal SCR (PR), preferably still with a unique number (e.g.,?PR-001). These PR code baselines and PR change request(s) are not under any configuration management per se, and are just used to manage the change process with a tighter regiment then pre-alpha code. More informal testing is performed to help assure that the system/acceptance testing shall proceed smoothly when that SLC acceptance and/or operational testing phase(s) is entered. When the technical lead determines that the second cycle requirements and design are nearly complete (99%) and that the code has reached a minimal level of issues being generated from the informal testing process, then the method enters the beta-point, or the point of the Vortex (Vortex-point). At this defined beta-exit-point (β), all SLC phase documents, including the requirements documentation, design documentation and code baseline are released for formal review, comment and comment incorporation and the controlled release. The SLC documentation and code baseline version release must consist of uniquely identifiable CIs to be controlled including the following categories 1) SLC phase documentation listing and location (e.g., SRS, SDD, ATP, etc.), 2) Project software items being released for test—including not only the binary library’s or compiled code but to the level required to completely compile that code and release for operation, including but not limited to source code, objects, development libraries, development configurations, backup files, including any 3) support software such as operating system utilities or framework (Windows Server, SQL, .NET Framework) with all version numbers. From this point on in the SLC (acceptance testing phase), the waterfall method is utilized, as is full configuration management until deployment. During maintenance, however, SCR(s) may utilize the Rapid Prototyping Vortex method to perform SLC tasks up to the point of acceptance testing of the SCR(s). The process described may be utilized for Plant Installed Software (custom-developed, configured, and acquired). Each of these software types has its own unique needs and definitions in the SLC process. Therefore, specific definitions to decide the a) exact implementation of the rapid proto-typing method, and b) Vortex entry and exit points may need to be further defined in a software project’s specific SMP.ATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC B – PLANT INSTALLED SOFTWARE LIFE CYCLE MODELPlanning/Requirements Phase –This phase consists of identifying the SLC phase planning activities, configuration management strategy, SLC documents and expected deliverables. After planning activities, the requirements definition activity begins. This starts with analyzing the problem or need for which an application is being developed. This analysis is used to develop and specify requirements and state what the computer program must do. In addition to stated requirements, requirements in this phase are derived from higher-level requirements and statements of need. (Engineering Standards, Functional Design Requirements, Software Requirements Specification). Requirements documentation must specifically address the software requirements separate from other requirements. For complex projects with Plant Installed Software, a separate software requirements specification may be necessary.Design Phase – In this phase, the software structure is defined. Technical approaches are chosen and problems are solved conceptually. This phase is often divided into a Preliminary Design Phase and a Detailed Design Phase. In the preliminary design the initial architecture is developed. In the detailed design, functional modules are defined, along with user interfaces and interfaces between modules.Development Phase – In this phase, the programming or coding takes place to execute the design. This phase is often iterative, with unit and integration testing being performed after a build, and the results used in another round of programming. Electronic files of the software and software tools required to maintain the software must be stored in the software configuration management software tool (e.g., secured storage area) or referenced. The initial software version is to be assigned prior to the completion of each software module. Changes to the software from the initial version must be controlled and documented.Testing Phase – In this phase, the computer program is tested for functionality and requirements compliance. Testing is often split into two parts; a) Part I being in a test environment that is not the operational environment and b) Part II being the actual operational environment, possibly with actual end users. Part I types of tests include: Unit Testing, Integration Testing, System Testing and Acceptance Testing. The first three testing types may be part of a repeated cycle of coding and testing, while acceptance testing verifies requirements compliance. During execution of Part I, the Part II tests, including CAT and OAT type Operations tests, are also (typically) developed and readied for V&V. Part II tests consists of Operations Testing and verifies the software meets operational requirements.Turnover to Operations Phase – In this phase, typically the software is installed in the intended system and users are trained in its operation. At this point, the development effort is considered complete.Operations and Maintenance Phase – This phase involves ongoing monitoring and control of the installed software, including in-use testing, fixing errors, and modifying or upgrading to provide additional functionality. Changes are made to specific modules to produce the desired effect without interfering with the rest of the program. Note that it has been found to be much easier to change requirements early in a project rather than to change code later.ATTACHMENT?B - PLANT INSTALLED SOFTWARE LIFE CYCLE MODEL (cont.)Retirement Phase – This phase involves the safe removal of Plant Installed Software from production. Retirement occurs as legacy systems are removed and replaced by new systems. This effort must be completed safely with minimal impact to operations. Systems are removed from production for several reasons, including: being replaced by a different product, the release is no longer supported by the supplier, the system is no longer needed, or the system has become redundant or obsolete. Quality records are disposed of or archived by correct procedural methods, e.g., RIDS and/or archival of electronic data per WRPS procedures.ATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC C – CROSS REFERENCE OF SQA WORK ACTIVITIES TO SOFTWARE LIFE CYCLE (SLC) PHASE DELIVERABLESThis cross-reference is derived from DOE Guide 414.1-4, Safety Software Guide for use with 10 CFR 830 Subpart A, Quality Assurance Requirements, and DOE?O 414.1C, Quality Assurance. The cross-reference identifies the required SQA work activities for all Software Grades. Table?C- SEQ Table \* ARABIC \r1 1. Cross Reference of SQA Work Activities to Software Life Cycle (SLC) Phase DeliverablesSoftware Grade-->A, B, or CDE or N/AFunctional Classification -->Safety Class or Safety SignificantDefense in Depth or General ServiceN/ASafety Designation -->Safety SoftwareNon-Safety SoftwareNon-Safety SoftwareSLC PhasePlanningIndex #Quality Affecting SoftwareQuality Affecting SoftwareQuality Affecting SoftwareNon-Quality Affecting SoftwareSQA Work ActivitiesSoftware Type -->CustomConfigureAcquiredCustomConfigureAcquiredCustomConfigureAcquiredSW Project Management and Quality PlanningPlanning1Planning documents/Software Management Plan (SMP)FullFullGradedGradedGradedGradedOptionalOptionalOptionalSW Configuration Management 2Software Configuration Management Plan (SCMP)FullGradedGradedGradedGradedGradedOptionalOptionalOptionalSW Risk Management3Risk Management PlanFullFullFullOptionalOptionalOptionalN/AOptionalOptionalVerification and Validation4Verification and Validation PlanAddressed by TFC-ENG-DESIGN-P-59SW Project Management and Quality Planning5Contingency PlanFullFullFullOptionalOptionalOptionalN/AN/AN/ASW Requirements Identification and ManagementRequirements6Functional Requirements Document (FRD)FullFullFullGradedGradedGradedOptionalOptionalOptionalSW Requirements Identification and Management7Software Requirements Specification (SRS)FullFullFullGradedGradedOptionalOptionalOptionalOptionalSW Safety8Failure Modes & Effects AnalysisFullFullFullN/AN/AN/AN/AN/AN/ASW Project Management and Quality Planning9Alternatives AnalysisAddressed by TFC-BSM-IRM_HS-C01N/AN/AN/AN/AN/AN/ASW Requirements Identification and Management10Requirements Traceability Matrix (RTM)FullFullFullGradedGradedGradedOptionalOptionalOptionalProcurement and Supplier Management11Acquisition DocumentsFullFullFullOptionalGradedGradedOptionalGradedGradedSW Design and ImplementationDesign12Software Design Description (SDD)FullGradedN/AGradedGradedN/AOptionalOptionalN/ASW Design and ImplementationDevelopment13Code WalkthroughFullGradedN/AOptionalN/AN/AOptionalN/AN/ASW Design and Implementation14User DocumentsFullFullFullGradedGradedGradedOptionalOptionalN/ASW Project Management and Quality Planning15Software Installation PlanFullFullGradedOptionalOptionalOptionalOptionalOptionalOptionalSW Design and Implementation16Unit TestingFullGradedN/AOptionalN/AN/AOptionalN/AN/AVerification and ValidationTesting17Software Test Procedures (e.g., Test Plan and Cases)FullFullFullGradedGradedGradedOptionalOptionalOptionalVerification and Validation18Acceptance Test ReportFullFullFullGradedGradedGradedOptionalOptionalOptionalTraining of…Safety SW19User QualificationFullFullFullOptionalOptionalOptionalN/AN/AN/ATraining of…Safety SW20User TrainingFullFullFullOptionalOptionalOptionalOptionalOptionalOptionalSW Configuration ManagementMaintenance21Operational / In-Use TestingFullFullFullGradedGradedGradedOptionalOptionalOptionalSW Configuration Management22Change Request / Problem ReportFullFullFullGradedGradedGradedOptionalOptionalOptionalSW Project Management and Quality PlanningRetirement23Retirement Plan/ChecklistFullFullFullGradedGradedGradedOptionalOptionalOptionalATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC D - PLANT INSTALLED SOFTWARE COMPLIANCE MATRIX REF TableB1 \h \* Caps Table?D-1, REF TableB2 \h \* Caps Table?D-2 , and REF TableB3 \h \* Caps Table?D-3 provide the graded approach to life cycle documentation required to implement software quality assurance requirements. These tables provide planning worksheets for the graded approach to Life Cycle documentation. The following are notes that apply to each Table.N/A – Not/ApplicableOptional – Project Lead determines with PICCB whether documentation is required in concurrence with Business Analyst.Graded – Required to be addressed in the SMP or as a standalone document. The level of detail will be based on the complexity of the software and will be applied at the point where WRPS control of the software occurs. Full – Required to be addressed in the SMP or as a standalone document. Details should be extensive and complete.Table?D- SEQ Table \* ARABIC \r1 1. Levels A-C Software Life Cycle Phase Deliverables Planning Worksheet.Software Grade-->A, B, or CFunctional Classification -->Safety Class or Safety SignificantSafety Designation -->Safety SoftwareIndex #Project ScheduleRPP/Other Document Ref. #Controls -->Quality Affecting SoftwareSLC PhaseStart Date (est.)End Date (est.)Software Type -->CustomConfigureAcquiredPlanning1Planning documents/Software Management Plan (SMP)FullFullGraded2Software Configuration Management Plan (SCMP)FullGradedGraded3Risk Management PlanFullFullFull4Verification and Validation PlanAddressed by TFC-ENG-DESIGN-P-595Contingency PlanFullFullFullRequirements6Functional Requirements Document (FRD)FullFullFull7Software Requirements Specification (SRS)FullFullFull8Failure Modes & Effects AnalysisFullFullFull9Alternatives AnalysisAddressed by TFC-BSM-IRM_HS-C-0110Requirements Traceability Matrix (RTM)FullFullFull11Acquisition DocumentsFullFullFullDesign12Software Design Description (SDD)FullGradedN/ADevelopment13Code WalkthroughFullGradedN/A14User DocumentsFullFullFull15Software Installation PlanFullFullGraded16Unit TestingFullGradedN/ATesting17Software Test Procedures (e.g., Test Plan and Cases)FullFullFullTurnover to Operations18Acceptance Test ReportFullFullFull19User QualificationFullFullFull20User TrainingFullFullFullMaintenance21Operational / In-Use TestingFullFullFull22Change Request / Problem ReportFullFullFullRetirement23Retirement Plan/ChecklistFullFullFullHISI #: Name:Instructionsi) Enter HISI # and Name Registered with SRB in upper left box above. Select with an ‘X’ in a SINGLE box above for the associated HISI Grading On-Record. This associates with a specific column for Software Deliverable phase requirements. ii) Refer to the PI-SQA, and if allowed, notate PI software deliverables that are to be grouped together using the RPP/Other Document Ref. #. Use the actual RPP document number, when possible. iii) Use the ‘Project Schedule’ to write a start date (mm/dd/yy) and end date (mm/dd/yy) for planning purposes, if known. This will be input into formal Project Schedules, and not modified here further.ATTACHMENT?D – PLANT INSTALLED SOFTWARE COMPLIANCE MATRIX (cont.)Table?D- SEQ Table \* ARABIC 2. Level D Software Life Cycle Phase Deliverables Planning Worksheet.Software Grade-->DFunctional Classification -->Defense in Depth or General ServiceSafety Designation -->Non-Safety SoftwareIndex#Project ScheduleRPP/Other DocumentRef. #Controls -->Quality Affecting SoftwareSLC PhaseStart Date (est.)End Date (est.)Software Type -->CustomConfigureAcquiredPlanning1Planning documents/Software Management Plan (SMP)GradedGradedGraded2Software Configuration Management Plan (SCMP)GradedGradedGraded3Risk Management PlanOptionalOptionalOptional4Verification and Validation PlanAddressed by TFC-ENG-DESIGN-P-595Contingency PlanOptionalOptionalOptionalRequirements6Functional Requirements Document (FRD)GradedGradedGraded7Software Requirements Specification (SRS)GradedGradedOptional8Failure Modes & Effects AnalysisN/AN/AN/A9Alternatives AnalysisAddressed by TFC-BSM-IRM_HS-C-0110Requirements Traceability Matrix (RTM)GradedGradedGraded11Acquisition DocumentsOptionalGradedGradedDesign12Software Design Description (SDD)GradedGradedN/ADevelopment13Code WalkthroughOptionalN/AN/A14User DocumentsGradedGradedGraded15Software Installation PlanOptionalOptionalOptional16Unit TestingOptionalN/AN/ATesting17Software Test Procedures (e.g., Test Plan and Cases)GradedGradedGradedTurnover to Operations18Acceptance Test ReportGradedGradedGraded19User QualificationOptionalOptionalOptional20User TrainingOptionalOptionalOptional21Operational / In-Use TestingGradedGradedGradedMaintenance22Change Request / Problem ReportGradedGradedGradedRetirement23Retirement Plan/ChecklistGradedGradedGradedHISI #: Name:Instructionsi) Enter HISI # and Name Registered with SRB in upper left box above. Select with an ‘X’ in a SINGLE box above for the associated HISI Grading On-Record. This associates with a specific column for Software Deliverable phase requirements. ii) Refer to the PI-SQA, and if allowed, notate PI software deliverables that are to be grouped together using the RPP/Other Document Ref. #. Use the actual RPP document number, when possible. iii) Use the ‘Project Schedule’ to write a start date (mm/dd/yy) and end date (mm/dd/yy) for planning purposes, if known. This will be input into formal Project Schedules, and not modified here further.ATTACHMENT?D – PLANT INSTALLED SOFTWARE COMPLIANCE MATRIX (cont.)Table?D- SEQ Table \* ARABIC 3. Level E or N/A Software Life Cycle Phase Deliverables Planning Worksheet.Software Grade-->E or N/AFunctional Classification -->N/ASafety Designation -->Non-Safety SoftwareIndex #Project ScheduleRPP/Other Document Ref. #Controls -->Non-Quality Affecting SoftwareSLC PhaseStart Date (est.)End Date (est.)Software Type -->CustomConfigureAcquiredPlanning1Planning documents/Software Management Plan (SMP)OptionalOptionalOptional2Software Configuration Management Plan (SCMP)OptionalOptionalOptional3Risk Management PlanN/AN/AN/A4Verification and Validation PlanAddressed by TFC-ENG-DESIGN-P-595Contingency PlanN/AN/AN/ARequirements6Functional Requirements Document (FRD)OptionalOptionalOptional7Software Requirements Specification (SRS)OptionalOptionalOptional8Failure Modes & Effects AnalysisN/AN/AN/A9Alternatives AnalysisAddressed by TFC-BSM-IRM_HS-C-0110Requirements Traceability Matrix (RTM)OptionalOptionalOptional11Acquisition DocumentsOptionalGradedGradedDesign12Software Design Description (SDD)OptionalOptionalN/ADevelopment13Code WalkthroughOptionalN/AN/A14User DocumentsOptionalOptionalN/A15Software Installation PlanOptionalOptionalOptional16Unit TestingOptionalN/AN/ATesting17Software Test Procedures (e.g., Test Plan and Cases)OptionalOptionalOptionalTurnover to Operations18Acceptance Test ReportOptionalOptionalOptional19User QualificationN/AN/AN/A20User TrainingOptionalOptionalOptional21Operational (Periodic) TestingOptionalOptionalOptionalMaintenance22Change Request / Problem ReportOptionalOptionalOptionalRetirement23Retirement Plan/ChecklistOptionalOptionalOptionalHISI #: Name:Instructionsi) Enter HISI # and Name Registered with SRB in upper left box above. Select with an ‘X’ in a SINGLE box above for the associated HISI Grading On-Record. This associates with a specific column for Software Deliverable phase requirements. ii) Refer to the PI-SQA, and if allowed, notate PI software deliverables that are to be grouped together using the RPP/Other Document Ref. #. Use the actual RPP document number, when possible. iii) Use the ‘Project Schedule’ to write a start date (mm/dd/yy) and end date (mm/dd/yy) for planning purposes, if known. This will be input into formal Project Schedules, and not modified here further.ATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC E - PLANT INSTALLED SOFTWARE DOCUMENTATION REQUIREMENTSDifferent SLC phase deliverables are defined in the SMP as appropriate for the safety and quality level for the software application. The PI-SQA also has additional guidelines and input to the SMP process, especially for Quality Affecting system applications.The SMP is typically a single document with sections that contain the following life cycle document requirements and therefore a unique document for each of the following is not required:Software Management Plan (SMP)Software Configuration Management Plan (SCMP)Risk Management Plan (RSKM)Retirement Plan/ChecklistContingency PlanVerification and Validation Plan.The following documents typically standalone, but may be included as a section in the SMP, at the discretion of the Project Lead:Functional Requirements Document (FRD)Alternatives AnalysisSoftware Requirements Specification (SRS)Software Design Description (SDD)Requirements Traceability Matrix (RTM)Software Test Procedures (e.g., Test Plan and Cases)Failure Modes and Effects Analysis (FMEA)User QualificationUser DocumentsUser TrainingSoftware Installation Plan.The following documents/activities typically stand-alone but may be combined at the discretion of the Project Lead:Unit TestingAcquisition DocumentsCode WalkthroughAcceptance Test ReportOperational (Periodic) TestingChange Request/Problem Report.Also, documents may be combined into a single document, other than the SMP, as appropriate to the software planning.ATTACHMENT? SEQ ATTACHMENT \* ALPHABETIC F - FAILURE MODES AND EFFECTS ANALYSISAn FMEA is part of the development and operations management for analysis of potential failure modes in a Plant Installed Software system. The FMEA tabulates failure modes and their effects on a system or plant as supported by Plant Installed Software. The FMEA should consider failures initiated by cyber security threats. The failure mode describes how equipment or software fails (open, closed, on, off, leaks, etc.). The effect of the failure mode is determined by the system’s response to the failure. An FMEA is well suited to identify single failure modes of automated system functions that either directly result in or contribute significantly to an accident. The FMEA aids in the classification by the severity and likelihood of the failures. FMEA can be used to identify potential failure modes based on past experience with similar products or processes, enabling the design of those failures out of the system. Failure modes are any errors or defects in a process, design, or item, and can be potential or actual. For details on the hazard analysis process, see TFC-ENG-DESIGN-C-47 for process hazard analysis.Preparing to perform an FMEA:Describe the system and its function.A good understanding of the system and safety function simplifies the determination of which uses of the system are desirable and which are not.It is important to consider both intentional and unintentional uses. Unintentional uses are a form of hostile environment.Create a block diagram of the system to give an overview of the major components or process steps and how they are related.Create an identification system to uniquely identify the different system elements.Develop a worksheet which contains the important information about the system (i.e.,?revision date, components).List the items or functions in a logical manner, based on the block diagram.Look at similar products or processes and any documented failure modes.Identify and document potential causes for a failure mode in technical terms (i.e.,?erroneous algorithms, excessive voltage, and improper operating conditions).Performing an FMEA:A typical FMEA will incorporate some method to evaluate the risk associated with potential problems. The risk components are identified through an analysis that identifies potential failure modes as well as the potential effect caused by the failure. These risks are then numerically rated using a ranking scheme. These rankings are used to arrive at a Risk Priority Number (RPN). The RPN can be used to compare issues within the analysis and to prioritize problems for corrective action as well as determine failure modes that are critical characteristics for the software.ATTACHMENT?F - FAILURE MODES AND EFFECTS ANALYSIS (cont.)The FMEA analysis may:Rate the severity of each effect of failure. (Severity Rating)For example: No Effect – 0, Low – 1, Moderate – 3, High – 5, Very High – 7Rate the likelihood of occurrence for each cause of failure. (Occurrence Rating)For example: Never – 0, Rare – 2, Frequent – 4, Continuous – 6Rate the likelihood of detecting the problem for each cause of failure (Detection Rating)For example: Always – 1, Most – 2, Few – 4, Never – 6Calculate the RPN by obtaining the product of the three ratings:RPN = Severity x Occurrence x Detection.Table?F- SEQ Table \* ARABIC \r1 1. Sample FMEA Worksheet.FMEA ElementsFlammable Gas Waste Group CalculationHISI ID: 1786 Acronym: FGWGCSafety Software Classification: Safety Management and Administrative Controls SoftwareItem/FunctionDetectorDetectorCodeCodePotential Failure ModeLoss of PowerSensor FailureIncorrect Alarm ValueDefect in Call to Alarm Subroutine Potential Effects of FailureLCOFaulty Reading, LCOExceed DSA, LCO, FireNo Mitigation, LCOPotential Cause(s)Breaker Trip,Terminal Fault, NPHMechanicalCoding ErrorCoding ErrorSeverity Rating(i.e., No Effect-0, Low-1, Moderate-3, High5, Very High-7)5553Occurrence Rating (i.e., Never-0, Rare-2, Frequent-4, Continuous-6)4222Detection Rating (i.e., Always -1, Most-2, Few-4, Never-6)1146Risk Priority Number (=Severity Rating X Occurrence Rating X Detection Rating)20104036Critical Characteristic?NoNoYesYesCurrent ControlsUPSMonthly SurveillanceSMPSMPRecommended ActionsAdd UPS Checking SubroutineNoneCode Alarm Value VerificationCode Walk Through ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download