Control Of Design And Analysis Software - Rizzoassoc
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. CHANGE MANAGEMENT RECORD Procedure Name: Quality Procedure (QP)-7, Control of Design and Analysis Software REVISION NO. 0 1 4/25/07 5/5/08 2 8/31/09 3 10/28/10 4 04/05/11 QP-7, Rev. 5, 03/27/13 DATE DESCRIPTIONS OF CHANGES/AFFECTED PAGES Original Procedure Revised procedure to address software usage tracking, configuration control, and error notice documentation. Deleted Section 16.0; added effective date to header. Added reference to QP-29 in Paragraph 2.9. Removed definitions related to commercial grade dedication in Section 3.0 and revised those definitions from NQA-1-1994 to the NQA-1 2008 versions. Clarified software development in Paragraph 4.2. Clarified performance of commercial grade dedication in Paragraph 6.3. Clarified documentation of V&V in Paragraph 6.5. Added commercial grade dedication as part of configuration control in Section 9.0. Revised forms. Other minor editorial changes. /All pages affected. Revised Section 1.0. Deleted references 2.1 and 2.4. Added references to Forms QP-7-1, QP-7-2, and QP-7-8 and numbered remaining forms. Added references from NQA-1-1994 to Section 3.0. Added Section 4.0 to describe Responsibilities. Added Section 5.0 to describe the Software Design Process. Added Section 6.0 to describe Software Acquisition. Renumbered Sections 5.0 through 5.0. Revised Sections 7.0 through 13.0, 16.0 and 17.0./All pages affected. PERSON AUTHORIZING CHANGE1 N/A Margaret A. Pelcher Margaret A. Pelcher Margaret A. Pelcher Margaret A. Pelcher
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 1 of 20 QP-7, Revision 5 March 27, 2013 CONTROL OF DESIGN AND ANALYSIS SOFTWARE QP-7, REVISION 5 MARCH 27, 2013 1.0 OBJECTIVE AND SCOPE This Procedure addresses the following software life cycle activities: Software design. Software acquisition. Installation of design and analysis software on individual computers. Computer program verification and validation. In-use testing. Software usage. Configuration control. Error notice documentation, distribution, and corrective action. Software maintenance. Virus protection. Software retirement. Records. Change control. This Procedure applies only to design and analysis software. It does not apply to operating systems or software not used directly for analysis or design (e.g., financial, scheduling, database, word processing, web browsing, or e-mail software). This Procedure provides the details for implementing the requirements of Subpart 2.7, “Quality Assurance Requirements of Computer Software for Nuclear Facility Application,” of NQA-1-1994 and NQA-1-2008 (and the NQA-1a2009 Addenda). 2.0 REFERENCES 2.1 Title 10 of the Code of Federal Regulations, Part 21 (10 CFR 21), “Reporting of Defects and Noncompliance.” QP-7, Rev. 5, 03/27/13
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 2 of 20 QP-7, Revision 5 March 27, 2013 2.2 American Society of Mechanical Engineers, NQA-1, “Quality Assurance Requirements for Nuclear Facility Applications,” Subpart 2.7, Quality Assurance Requirements of Computer Software for Nuclear Facility Applications. 2.3 Paul C. Rizzo Associates, Inc. (RIZZO), “Quality Assurance Manual.” 2.4 RIZZO, QP-5, “Corrective Action, Preventive Action, and Continual Improvement.” 2.5 RIZZO, QP-6, “Procurement Source Evaluation, Selection, and Control.” 2.6 RIZZO, QP-15, “Calculation Preparation.” 2.7 RIZZO, QP-22, “Audit Procedure.” 2.8 RIZZO, QP-25, “Records Control.” 2.9 RIZZO, QP-29, “Commercial Grade Dedication.” 2.10 Form QP-7-1, Software Design Requirements. 2.11 Form QP-7-2, Computer Program Verification and Validation Information. 2.12 Form QP-7-3, Computer Program In-Use Test Information. 2.13 Form QP-7-4, Configuration Baseline Form. 2.14 Form QP-7-5, Software Usage Log. 2.15 Form QP-7-6, Error Notice Log. 2.16 Form QP-7-7, Software Error Documentation Form. 2.17 Form QP-7-8, Software Design Report Cover Page and Template. 2.18 Form QP-7-9, Verification and Validation Plan. 2.19 Form QP-7-10, Software Change Request. 2.20 Form QP-7-11, Log of Software Change Requests. 2.21 Form QP-7-12, Software Configuration Release Report. 2.22 Form QP-7-13, Log of Approved Software.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 3 of 20 QP-7, Revision 5 March 27, 2013 2.23 3.0 DEFINITIONS 3.1 1 Form QP-7-14, “Review of Pre-Existing Software Developed or Maintained by RIZZO for Conformance with NQA-1, Subpart 2.7.” Baseline1 – A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for use and further development, and that can be changed only by using an approved change control process. (NQA-1-2008 and NQA-1a-2009 Addenda) Software that has been formally reviewed and agreed upon, and that can only be changed through formal change control procedures. (NQA-1-1994) 3.2 Computer Software Validation – Tests and evaluation of software performed to ensure that the model embodied in a computer code is a correct representation of the process or system for which it is intended. 3.3 Computer Software Verification – Tests and evaluation of software performed to ensure that a computer code correctly performs the operations specified in a numerical model or the options specified in the user input. 3.4 Configuration Control1 – The process of identifying and defining the configuration items in a system, controlling the release and change of these items throughout the system life cycle, and recording and reporting the status of configuration items and change requests. (NQA-1-1994) 3.5 Configuration Management (software)1 – The process of identifying and defining the configuration items in a system (i.e., software and hardware), controlling the release and change of these items throughout the system life cycle, and recording and reporting the status of configuration items and change requests. (NQA-1-2008 and NQA-1a-2009 Addenda) 3.6 Configuration Item1 – A collection of hardware or software elements treated as a unit for the purpose of configuration control. Definition from Subpart 2.7 to NQA-1-1994 and/or NQA-1-2008 (and the NQA-1a-2009 Addenda).
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 4 of 20 QP-7, Revision 5 March 27, 2013 3.7 Error1 – A condition deviating from an established baseline, including deviations from the current approved computer program and its baseline requirements. (NQA-1-2008 and NQA-1a-2009 Addenda). A discrepancy between a computed, observed or measured value or condition and the true, specified, or theoretically correct value or condition. (NQA-1-1994). 3.8 Independent Design Reviewer – A competent individual(s) or group(s) other than those who performed the original design. If necessary, this may be the Originator’s supervisor, provided that the supervisor did not specify a singular design approach or rule out certain design considerations and did not establish the design inputs used in the design; or the supervisor is the only individual in the organization competent to perform the verification. 3.9 Pre-Existing Software – Software that meet one of the following criteria: Procured prior to issuance of Rev. 4 of QP-7 (04/05/11) from a supplier not having a Quality Assurance (QA) Program meeting NQA-1, Subpart 2.7, with RIZZO assuming responsibility for subsequent code maintenance. Obtained as part of the acquisition of International Civil Engineering Consultants, Inc. (ICEC) by RIZZO in 2008, with subsequent code maintenance by RIZZO. Developed by RIZZO prior to the formalization of a process for software development which meets the requirements of NQA-1, Subpart 2.7 as described in Rev. 4 of QP-7 (April 5, 2011). 3.10 Purchased Software – Software obtained from an outside source by RIZZO after the initial date of issue of RIZZO Procedure QP-7 (April 25, 2007). Purchased software includes public domain software that is obtained at no charge. 3.11 Software Life Cycle1 – The period of time that begins when a software product is conceived and ends when the software product is no longer available for use. The life cycle typically includes requirements phase, design phase, implementation phase, test phase, a concept phase, installation and checkout phase, operation and maintenance phase, and sometimes a retirement phase. These phases may overlap or be performed iteratively, depending on the software development approach used. (NQA-1-2008 and NQA-1a-2009 Addenda).
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 5 of 20 QP-7, Revision 5 March 27, 2013 4.0 The period of time that starts when a software product is conceived and ends when the software product is no longer available for routine use. The software life cycle typically includes a requirements phase, a design phase, an implementation phase, a test phase, an installation and checkout phase, an operation and maintenance phase, and sometimes a retirement phase. (NQA-1-1994) RESPONSIBILITIES 4.1 4.2 Software Administrator 4.1.1 The Software Administrator is responsible for maintaining documentation supporting the configuration of the software under their responsibility. This documentation shall be described on Form QP-7-4, “Configuration Baseline Form,” including any subsequent revisions. For software that is maintained/supported by RIZZO, the Software Administrator is also responsible for rejecting/approving and tracking proposed software change requests by completing Form QP-7-10, Part 2, “Software Change Request” and Form QP-7-11, “Log of Software Change Requests,” respectively, and formally releasing new software or updated software for use by completing Form QP-7-12, “Software Configuration Release Report.” 4.1.2 The Software Administrator shall receive and document any error notices for the software under their responsibility. This includes the completion of Forms QP-7-6 and QP-7-7, “Error Notice Log” and “Software Error Documentation Form,” respectively. 4.1.3 The Software Administrator shall submit the software records associated with the software under their responsibility (per Section 16.0 of this Procedure) for filing per RIZZO Procedure QP-25, “Records Control.” Business Unit Manager 4.2.1 Business Unit Managers shall assign a Software Administrator for each software package that is utilized for performance of nuclear safety-related work within their group. 4.2.2 The Business Unit Manager shall approve the software configuration and any subsequent revisions, as described on Form QP-7-4, “Configuration Baseline Form.”
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 6 of 20 QP-7, Revision 5 March 27, 2013 4.3 4.2.3 The Business Unit Manager shall approve the proposed resolution of software error notices, as described in Form QP-7-7, “Software Error Documentation Form.” 4.2.4 The Business Unit Manager shall approve software requirements as documented on Form QP-7-1, “Software Design Requirements.” 4.2.5 The Business Unit Manager shall approve the Software Design Report as documented on Form QP-7-8, “Software Design Report Cover Page.” 4.2.6 The Business Unit Manager shall approve the Verification and Validation Plan as documented on Form QP-7-9, “Verification and Validation Plan.” 4.2.7 The Business Unit Manager shall approve the Software Configuration Release Report as documented on Form QP-7-12, “Software Configuration Release Report.” IT Manager The IT Manager is responsible for installation of design and engineering software, software maintenance, virus protection, and software retirement, as described in this Procedure. 4.4 Director of Quality Assurance The Director of Quality Assurance (or designee) is responsible for filing software records per QP-25 and for maintaining Form QP-7-13, “Log of Approved Software.” 5.0 SOFTWARE DESIGN PROCESS Software QA requirements are summarized, in general, on Figure QP-7-1, with specific requirements related to software designed/developed by RIZZO summarized on Figure QP-7-2. The following sections discuss the software design process in greater detail. 5.1 Requirements Phase 5.1.1 During this phase, the requirements that the software must satisfy are specified including: Operating system. Functionality – the functions the software is to perform. Design Inputs.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 7 of 20 QP-7, Revision 5 March 27, 2013 5.2 Performance (if applicable) – the time-related issues of software operation such as speed, recovery time, response time, etc. Design Constraints Imposed on Implementation Phase Activities – any elements that will restrict design options. Attributes – non-time-related issues of software operation, such as portability, acceptance criteria, access control, maintainability, installation considerations, etc. External Interfaces – Interactions with people, hardware, and other software. Security Features – Includes vulnerability protection and cyber-security. 5.1.2 An item can be called a software requirement only if its achievement can be verified and validated. Software requirements shall be traceable throughout the remaining stages of the software development cycle. 5.1.3 The requirements listed in Paragraph 5.1.1 are documented by the Originator on Form QP-7-1, “Software Design Requirements.” These requirements are reviewed and approved by an Independent Design Reviewer meeting the requirements of Paragraph 3.8 and the Business Unit Manager. This review shall assure that the requirements are complete, verifiable, consistent, and technically feasible. This review shall also assure that the requirements will result in feasible and usable code. Design Phase 5.2.1 During this phase, a software design based on the requirements shall be developed, documented, and reviewed. 5.2.2 The design shall specify the overall structure (control and data flow), and the reduction of the overall structure into physical solutions (algorithms, equations, control logic, and data structures). The design may necessitate the modification of the requirements documentation. 5.2.3 A Software Design Report shall be prepared by the Originator(s) of the software to document the following information: Purpose for Developing the Software – A general description of the overall application(s) of the software.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 8 of 20 QP-7, Revision 5 March 27, 2013 Software Design Requirements – A description of the software component(s) or function(s) as they relate to the software design requirements, and identification of software requirements for the operating system, interfaces, and installation considerations, as well as the software security requirements. This section of the Software Design Report shall be consistent with the requirements documentation. Note: A Verification and Validation Plan, Form QP-7-9, shall also be completed by personnel independent from the software design, which shall address the generation of test plans and test cases based on the software design and the software design requirements. See Paragraph 5.4 for more details regarding the testing phase. 5.2.4 Description of Program Theory and Methodologies – A technical description of the software with respect to the theoretical basis and numerical methods/mathematical models. Assumptions – A description of the assumptions that were made when developing the program (if applicable). Program Control Flow/Control Structures – A technical description of the software with respect to control flow and control structures. Program Data Flow/Data Structures – A technical description of the software with respect to data flow and data structures, and the relationship between data structures and control structures. References – A list of references that includes references to drawings, specifications, codes, standards, regulations, procedures or instructions that establish software design requirement test, inspection, and acceptance criteria in addition to the numerical method, mathematical model, or equation references that were used to develop the software. Appendices – At a minimum, an appendix containing the software code shall be included in the Software Design Report. The Software Design Report is a design document meeting the requirements of Section 3.0 of the RIZZO QA Manual. An Independent Design Reviewer shall perform a design review of the Software Design Report per Section 3.5 of the RIZZO QA Manual. This review shall evaluate the technical adequacy of the design approach and assure internal completeness, consistency, clarity, and correctness of the software design, and shall verify that the software design is traceable to the requirements. In addition, the review of the software design shall ensure that the
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 9 of 20 QP-7, Revision 5 March 27, 2013 requirements are addressed. Upon completion of this review, the Originator shall address any resulting comments. This review of the Software Design Report shall be documented on Form QP-7-8, Part 3, “Software Design Report Cover Page.” 5.4 5.3 Implementation Phase 5.3.1 During this phase, the design shall be translated into a programming language, and the implemented software shall be analyzed by the Software Originator(s) to identify and correct errors. The software code, or computer program listings, shall be included in the Software Design Report. 5.3.2 During this phase, software verification activities shall consist of the examination of computer program listings by the Independent Design Reviewer to assure adherence to coding standards and conventions. This review of the Software Design Report shall be documented in Part 3 of Form QP-7-8, “Software Design Report Cover Page,” and the approval of the Software Design Report shall be documented in Part 4. 5.3.3 Software validation is performed at the end of the implementation phase to ensure that the code satisfies the requirements. Software validation activities, such as the development of test plans and test cases shall be integrated into each phase of the software life cycle. Testing shall be the primary method of software validation. The validation of modifications shall be subject to selective regression testing to detect errors introduced during the modification of the systems or system components, to verify that the modifications have not caused unintended adverse effects, or to verify that a modified system(s) or system component(s) still meets specified requirements. Testing Phase 5.4.1 During this phase, the design as implemented in the code shall be exercised by executing the test cases identified for each software function(s)/ module(s) in the Verification and Validation Plan, Form QP-7-9. 5.4.2 Failure to successfully execute the test cases shall be reviewed as described in Paragraph 8.5. 5.4.3 Testing phase activities shall consist of completion and implementation of the Verification and Validation Plan, Form QP-7-9, to validate the code to assure adherence to the requirements and to assure that the software
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 10 of 20 QP-7, Revision 5 March 27, 2013 produces correct results for the test cases. V&V shall be performed and documented, as described in Section 8.0. 5.5 Development of User Documentation The Business Unit Manager shall assign a technically qualified individual to prepare the User Documentation for the software. At a minimum, User Documentation shall include: User instructions that contain an introduction, a description of the user’s interaction with the software, and a description of any required training necessary to use the software. Input and output specifications. Input and output forms. A description of system limitations. A description of anticipated errors and how the user can respond. Information for obtaining user and maintenance support. Approval by the Originator and Independent Technical Reviewer Note: Software users shall perform and document In-Use Testing prior to software use, as described in Section 9.0. 5.6 6.0 The formal release of new software for use is documented by completing Form QP-7-12, “Software Configuration Release Report.” SOFTWARE ACQUISITION As shown on Figure QP-7-1, the requirements for software acquisition vary based on the method by which the software was procured, as well as the intended software application (i.e., nuclear safety-related application or non nuclear safety-related application). The following sections discuss software acquisition in greater detail. 6.1 Software that is acquired and used for design and analysis activities can either be pre-existing or purchased from a vendor. Purchased software shall be acquired in accordance with RIZZO Procedure QP-6. 6.2 For commercial grade software that is used in a nuclear safety-related application, Commercial Grade Dedication is required, as described in RIZZO Procedure QP-29. For this application, the Commercial Grade Dedication Plan is the test plan for the V&V. Development of the Commercial Grade Dedication Plan, and
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 11 of 20 QP-7, Revision 5 March 27, 2013 the performance of the V&V per the requirements of the Commercial Grade Dedication Plan, shall be completed prior to software use. Note: For procured software that is not used in a nuclear safety-related application, Form QP-7-9, :Verification and Validation Plan,” shall be completed in place of the Commercial Grade Dedication Plan in the event that V&V documentation or proof of V&V cannot be obtained from the software vendor as noted in Paragraph 8.1. 7.0 6.3 The applicable requirements of NQA-1, Subpart 2.7, as described in this Procedure, shall become the responsibility of RIZZO upon receipt of software from a supplier. In the event that software is purchased from a vendor as nuclear safety-related, a prequalification audit of the vendor shall be performed in accordance with RIZZO Procedures QP-6 and QP-22. If the vendor’s quality assurance program is acceptable, the software is acceptable for use, but RIZZO shall be responsible for documenting Software Use, Software Configuration Control, and error notices in accordance with Sections 10.0, 11.0, and 12.0. 6.4 For Pre-Existing Software, as defined in Paragraph 3.9, complete Form QP-7-14, “Review of Pre-Existing Software Developed or Maintained by RIZZO for Conformance with NQA-1, Subpart 2.7,” to document that a review of the software for conformance with NQA-1, Subpart 2.7 was performed. After the specified activities are performed, reviewed, and approved, the software shall be placed under configuration control. 6.5 Suppliers providing software services, such as verification and validation, shall have a plan(s) for software quality assurance that meets the requirements of NQA-1, Subpart 2.7, as specified in procurement documents. RIZZO shall determine the adequacy of the plan(s). INSTALLATION AND CHECKOUT 7.1 The IT Manager, or staff working under his direction, is responsible for control of software installation disks and for the installation of design and engineering software. Password control will limit computer access for the purpose of installing or removing software. 7.2 Upon installation of an updated version of a computer program, the IT Manager, or his staff, will remove all previous versions of the same computer program (if applicable). 7.3 The IT Manager shall maintain a database that lists computer programs installed on every computer within RIZZO. This database shall include the version number of each program and the date the program was installed or removed.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 12 of 20 QP-7, Revision 5 March 27, 2013 7.4 8.0 Upon installation of the computer program, computer program verification and validation or computer program in-use testing shall be performed in accordance with Sections 8.0 and 9.0 of this Procedure, respectively. In addition, Configuration Control is established per Section 11.0. These installation and checkout phase verification and validation activities consist of the: (a) Execution of tests to confirm that the computer program is functioning correctly within the computer’s operating system and (b) Documentation of the approval of the computer program for operational use. COMPUTER PROGRAM VERIFICATION AND VALIDATION 8.1 Computer program V&V shall be planned and performed for each system configuration which may impact the software and shall be performed prior to software use. Software verification shall be performed during the software development to ensure that the products of a given cycle phase fulfill the requirements of the previous phase or phases. Computer program V&V activities shall: Ensure that the software adequately and correctly performs all intended functions; and Ensure that the software does not perform any unintended function that either by itself or in combination with other functions can degrade the entire system. Note: Procured software that is not used in a nuclear safety-related application can be utilized without performance of V&V if it has been utilized extensively in the industry and has been verified by the software vendor. If such documentation is not available or is not released by the software vendor, V&V shall be performed in accordance with the Verification and Validation Plan (see Paragraph 6.2). 8.2 For software that was developed/designed by RIZZO, computer program V&V shall be performed in accordance with the Verification and Validation Plan, Form QP-7-9. Software V&V shall be performed and evaluated by technically qualified individual(s) or group(s) who were not involved with the development of the software. 8.3 V&V is accomplished by one or more of the following methods:
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. COPIES PRINTED OR SAVED LOCALLY ARE UNCONTROLLED. 13 of 20 QP-7, Revision 5 March 27, 2013 Hand Calculation – Program is shown to correctly solve a problem previously solved by a checked hand calculation (without computer assistance). Comparison of the computer output and calculation result is made by an independent person. Empirical Data and Information from Technical Literature – Program is shown to correctly solve an accepted, published benchmark problem, or results from the program match empirical data. Previously Verified and Validated Computer Program – Program is shown to correctly solve a problem solved by another previously verified and validated computer program. 8.4 V&V is documented on Form QP-7-2, “Computer Program Verification and Validation Information Form.” Computer Program Verification and Validation Information Forms shall be signed by the individuals who perform the verification and evaluation (validation). Supporting V&V calculations shall be attached to the Computer Program Verification and Validation Information Form. These calculations shall be prepared and checked in accordance with the procedures presented in RIZZO Procedure QP-15, except that the Computer Program Verification and Validation Information Form (Form QP-7-2) replaces the Calculation Cover Page (Form QP-15-1). Note: If V&V is not required, as noted in Paragraph 8.1, then the completion of the Computer Program Verification and Validation Information Form is also not required. 8.5 9.0 Failure to successfully execute the V&V test cases in accordance with the Verification and Validation Plan or the Commercial Grade Dedication Plan requires a review to determine if modifications of the requirements, the design, the implementation, or the test plans and test cases are required. If required, changes shall be implemented per Section 17.0. IN-USE TESTING If a program is installed on a computer other than that in which the program was verified, or if significant hardware or operation system configuration changes have been made since verification, tests shall be performed to confirm acceptable performance of the computer program on the new system. In-use testing is documented on Form QP-7-3, “Computer Program In-Use Test Information Form.” Supporting in-use test calculations shall be attached to the Computer Program In-Use Test Information Form. These calculations shall be prepared and checked in accordance with the procedures presented in RIZZO Procedure QP-15, except that the Computer Program In-Use Test Information Form replaces the Calculation Cover Page.
REFER TO THE CONTROLLED DOCUMENT LOCATED ON THE RIZZO EXTRANET FOR THE LATEST VERSION. C
3.10 Purchased Software - Software obtained from an outside source by RIZZO after the initial date of issue of RIZZO Procedure QP-7 (April 25, 2007). Purchased software includes public domain software that is obtained at no charge. 3.11 Software Life Cycle1 - The period of time that begins when a software product is conceived
Control theories commonly used today are classical control theory (also called con-ventional control theory), modern control theory, and robust control theory.This book presents comprehensive treatments of the analysis and design of control systems based on the classical control theory and modern control theory.A brief introduction of robust
3.3.2 Active suspension control 36 3.3.3 Optimal Control Design for a 3-nodal ABR Network . 38 3.3.4 Multiobjective H x, design 47 3.3.5 F16 longitudinal control design 48 3.3.6 X29 pitch axis control design 53 3.4 Conclusion Remarks 58 PART II INTEGRATED PARAMETER AND CONTROL (IPC) DESIGN 59
Present ICE Analysis in Environmental Document 54 Scoping Activities 55 ICE Analysis Analysis 56 ICE Analysis Conclusions 57 . Presenting the ICE Analysis 59 The ICE Analysis Presentation (Other Information) 60 Typical ICE Analysis Outline 61 ICE Analysis for Categorical Exclusions (CE) 62 STAGE III: Mitigation ICE Analysis Mitigation 47 .
37 Engine Control #5 38 Engine Control #6 39 Machine Control Module 40 Engine Control #7 41 Engine Control #8 42 Engine Control #9 43 Engine Control #10 47 Backup Engine Control 49 VIMS Main Module 50 VIMS Analysis Module 51 VIDS Main Module 52 Graphical Display Module #2 D6R Track-Type Tractor 9PN00001-UP (MACHINE) POWERED BY 3306 Engine(SEB .
ventional control theory), modern control theory, and robust control theory.This book presents comprehensive treatments of the analysis and design of control systems based on the classical control theory and modern control theory.A brief introduction of robust control theory is included in Chapter 10.
Research Design: Financial Performance Analysis In this study, financial performance analysis will be used. The analysis is based on three types of analysis methods which are horizontal analysis, trend analysis and ratio analysis. All data analysis is based on the items on the financial statement. A financial statement is a written record
Design and Analysis Software v2 file used as a template to contain primary analysis and secondary analysis settings. This option can be used for the analysis of legacy EDS or SDS files when a specific set of primary and secondary analysis settings are needed. The primary and secondary analysis settings will be used when the analysis (-a) option .
x Verilog HDL: A Guide to Digital Design and Synthesis . 7.3.1 Delay-Based Timing Control 124 Regulär delay control 125 Intra-assignment delay control 126 Zero delay control 127 7.3.2 Event-Based Timing Control 127 Regulär event control 128 Named event control 128 Event OR control 129
