計算機化系統驗證基本要求的探討

王健明

（上海信誼藥廠有限公司制藥二廠，上海201200）

0 引言

隨著GMP（2010修訂版）有關計算機化系統附錄的生效日期的臨近，計算機化系統驗證的話題已經被人們經常提及，但大多對自己企業各類相關的計算機化系統應該如何驗證感到困惑，應該遵從怎樣的規范來實施驗證，本文希望就上述話題與同行一起學習和探討，分享我們多年來在工作實踐中的成果。

1 基本概念

GMP計算機化系統附錄第4章就驗證做出如下闡述：應使用科學的風險評估方法來決定計算機化系統的驗證范圍與程度，應當將驗證看作計算機化系統生命周期的一個組成部分，這個生命周期包括計劃、設定標準、編程、測試、試運行、文檔管理、運行、監控、修改更新等階段，要充分考慮計算機化系統的使用范圍，確定其屬于前驗證還是回顧性驗證，系統是否引入新的組件。

首先我們有必要將上述專業名詞用ISPEGAMP 5《良好自動化生產實踐指南》來做一下定義，以便明確其內涵。

1.1 風險評估方法

計算機化系統質量風險管理流程（圖1），采用了ICH Q9的一般原則來說明風險管理的“5個步驟”，該流程是實現與維護系統不可或缺的部分，對于簡單的低風險的系統可以進行組合。

圖1 計算機化系統質量風險管理流程

1.2 計算機化系統

計算機化系統框圖如圖2所示，其是由硬件、軟件、網絡組件以及可控的功能和相關文件組成。它可以包括：生產資源計劃系統、實驗室信息管理系統、自動化生產設備系統、生產執行系統、倉儲與配送系統、文件管理系統。

圖2 計算機化系統框圖

1.3 計算機化系統的生命周期

計算機化系統的生命周期由以下4個主要階段組成：概念提出、項目實施、系統運行、系統退役。

概念提出階段通常由監管公司根據自己的業務需求和收益來考慮階段需要實現的業務流程，并考慮可能的解決方法。

項目實施是充分考慮了自己的業務需求和收益后，根據項目的活動中的計劃，評估和選擇供應商，規范各層級的需求，并進行配置、驗證，直到項目的驗收和系統投入使用。

系統運行是4個階段中最長的階段，是由確定的及時更新的具有可操作性的規程來對其進行管理，期望保持系統可控、符合預定用途及合規等都是非常關鍵的方面，重點是對系統的影響、范圍和復雜性的變更進行管理。

當系統即將退出公司的業務不再使用時，就自然進入了退役階段，該階段決定對數據進行保留、遷移還是銷毀。

2 驗證實施

驗證通常使用國際制藥工程協會（ISPE）的《良好自動化生產實踐指南》（GAMP5）的V字模型（圖3），該模型是使系統在整個生命周期實現合規與符合預定用途的通用方法。該模型的驗證過程包括用戶需求規范、功能需求規范、設計規范、系統開發、安裝確認、運行確認和性能確認。測試階段的驗證活動用來確認規范階段的需求得到滿足。

2.1 驗證主計劃（VMP）

在項目實施前首先需要定義驗證計劃，它可以作為既定的時間段內或工作流的總體計劃，它應該是驗證項目的概述文件，必須清晰精確地表述和涵蓋設施、系統、流程的概述。

驗證過程是建立文件證據，為特定的計算機化流程可以持續地滿足預先定義的質量要求規范提供高度保證。其主要目標是通過文件、記錄系統可持續滿足需求。此驗證主計劃的目的是定義該系統的驗證活動，內容包含定義、驗證范圍、驗證角色和職責以及主要驗證產生文檔的描述。

圖3 GAMP5 V字模型

2.1.1 系統描述

系統是進行藥品生產質量控制的技術平臺，它是由多個子系統集成，主要涵蓋生產管理、質量管理等模塊。

2.1.2 功能范圍

驗證項目實施的范圍有生產流程、質量管理流程，功能模塊有生產管理模塊、質量管理模塊等。

2.1.3 系統的技術架構

系統主要由生產管理模塊、質量管理模塊以及其他業務模塊組成，涵蓋開發環境、驗證環境、運行環境以及備份服務器的架構及配置文件的描述等。

2.1.4 驗證方法

驗證將使用國際制藥工程協會（ISPE）的《良好自動化生產實踐指南》（GAMP5）的V字模型，該模型是使系統在整個生命周期實現合規與符合預定用途的通用方法。該模型的驗證過程包括用戶需求規范、功能需求規范、設計規范、系統開發、安裝確認、運行確認和性能確認等。

2.1.5 風險評估

作為驗證方法的組成部分，企業將采取基于風險的方法，對系統功能的風險水平進行評估。風險評估將對系統驗證范圍內的流程或功能相關的法規和業務風險進行合理地評估并進行書面記錄。編制風險評估報告遞交決策層審批。

2.1.6 驗證交付

驗證交付的內容：驗證主計劃、設計需求規范、功能需求規范、用戶需求規范、確認階段（IQ、OQ、PQ）、標準操作程序、用戶培訓、偏差管理、驗證總結報告。

2.1.7 項目的角色與職責

驗證主管和信息系統質量保證主管需要對協議授權，對驗證結果和驗證總結報告進行審批。項目中需要對團隊的角色做出定義，如執行決策者（ES）、項目經理（PM）、開發團隊主管（DTL）、開發團隊成員（DTM）、業務部門主管/團隊成員（BTL/BTM）、驗證主管（VTL）、驗證團隊成員（VTM）、信息系統質量保證主管（ISQA）等，并按照上述角色，確定審批矩陣。

2.2 風險評估

該系統為企業的生產、質量控制的業務流程提供有效的運作支持，企業將采取基于風險的方法，對業務環境面臨的風險進行整體的風險評估。

2.2.1 目的

風險評估的目的是對系統功能的重要性和復雜性進行評價。風險評估對企業系統的相關功能的業務、技術和法規風險提供合理的評估結果，并進行文件記錄。

對系統的功能性風險評估將考慮系統對企業質量管理體系、產品的質量、安全和效用以及數據完整性方面的潛在影響。此外，系統功能所支持的業務的重要性以及系統解決方案的技術復雜程度也是風險評估考慮的因素。

2.2.2 范圍

文檔的范圍限于驗證主計劃中所列的業務流程涉及的各模塊。

2.2.3 角色與職責

定義驗證團隊業務部門主管、信息技術主管、項目經理的職責。

2.2.4 風險評估

2.2.4.1 系統風險評估

（1）GMP評估：用來判斷該系統是否應作為企業質量體系的一部分而被定義為一個GMP相關的系統。被判定與GMP相關就要求通過驗證以滿足GMP的要求。

（2）重要性評估：根據提出的問題所作的回答來判定其重要程度。

（3）復雜性評估：根據提出的問題所作的回答來判定其復雜程度。

（4）評估總結：對重要性和復雜性評估的結果作出判斷。

2.2.4.2 功能風險評估

如果模塊是與GMP相關的，則需要對每個功能進行進一步的評估。表1為功能風險評估表，功能風險評估方法參照ISPEGAMP5中的方法，由業務風險、技術風險、GMP風險3個維度組成。每個維度都有4個等級來表示風險的等級：高（3）、中（2）、低（1）、無（0）。每個功能最終的風險等級將由3個維度中風險等級最高的維度的風險等級決定。風險評估的結果將被用來定義驗證范圍和測試等級。驗證范圍將包括所有與GMP相關的功能。

表1 功能風險評估表

評估結果為高、中風險，需要做正式歸檔測試，正式歸檔測試時，所有的測試實例會被預先審批，然后執行、審核以及批準。

評估結果為低、無風險，需要做非正式歸檔測試，在非正式歸檔測試時，測試實例無需預先審批，只會在執行后被審批，但是測試總結報告會被審核以及批復。

2.3 用戶需求規范

2.3.1 目的

文檔的目的是為了定義企業實施并使用系統的業務/用戶需求。

2.3.2 范圍

文檔的內容包括生產管理、質量管理業務流程的用戶需求。

2.3.3 用戶需求定義

表2 為用戶需求定義，其包括子流程編號、用戶需求編號以及用戶需求描述。

表2 用戶需求定義

2.4 功能需求規范

2.4.1 目的

文檔的目的是為了定義企業實施并使用系統的功能需求。

2.4.2 范圍

文檔的內容包括企業生產、質量管理業務流程的功能需求。

2.4.3 子流程功能需求定義

表3 為子流程功能需求定義，其文檔應該具備功能需求編號及詳細描述。

2.5 設計需求規范

2.5.1 目的

文檔的目的是描述系統模塊的設計規范，簡述模塊中重要功能的輸入、輸出項及實現邏輯。

表3 子流程功能需求定義

2.5.2 范圍

文檔的內容包括模塊業務流程中識別的被評估為高風險的系統功能的設計需求。本文檔記錄的系統功能已對業務風險、技術風險、GMP風險進行了功能性風險評估，3個維度均被評估為高風險系統功能編寫設計需求。

2.5.3 功能描述

表4 為功能描述，其包括：（1）設計需求編號；（2）所實現的功能；（3）功能的輸入項目；（4）功能的輸出項目；（5）邏輯流程描述；（6）其他功能的接口和限制條件；（7）功能所需達到的性能要求；（8）測試要點。

表4 功能描述

2.6 安裝確認

安裝確認是指檢查、測試或其他核實，從而證明軟件和硬件的安裝、配置是正確的。

2.6.1 安裝確認協議

2.6.1.1 目的

編寫本安裝確認協議的目的是為了描述系統進行安裝確認將要執行的各項任務。

2.6.1.2 方法

針對系統應用的階段，可以將驗證分為前驗證或回顧性驗證，驗證系統生產運行環境或驗證環境范圍內的硬件和軟件是否符合IT基礎設施和軟件規范定義的標準。

2.6.1.3 范圍

該安裝確認協議適用范圍為系統的驗證環境和生產環境的基礎設施和軟件。

該安裝確認協議的測試實例，在被執行之前，需要經過審批，審批通過之后將被用來檢驗驗證。

該安裝確認協議需要在進行安裝確認測試活動開始之前被審批。完成安裝確認測試之后，安裝確認報告將會被撰寫，其中將會包括安裝的滿意度和發現的問題。

2.6.1.4 風險評估

本風險估會在執行此協議時被執行。對于軟硬件的風險評估，將基于該軟硬件是否對運行確認測試和性能確認測試產生影響和該軟硬件是否將應用于生產環境。如果符合以上2種情況中的任何一種，將判定該軟硬件的風險等級為高。

2.6.1.5 角色與職責

定義項目參與人員及需要的角色，如質量職責、信息系統職責、測試職責、驗證團隊等。

2.6.1.6 測試實例內容

IT基礎設施驗證包括：（1）物理環境；（2）系統崩潰；（3）訪問安全；（4）數據完整。

2.6.1.7 系統管理流程驗證

系統管理流程驗證包括：（1）服務器運行（時鐘驗證）；（2）系統狀態檢查；（3）定期維護；（4）系統清理；（5）系統診斷，性能評估；（6）系統電力供應和后備電源。

2.6.1.8 物理安全流程驗證

物理安全流程驗證包括：（1）緊急情況條例；（2）訪問者/承包商條例；（3）機房訪問。

2.6.1.9 邏輯安全流程驗證

邏輯安全流程驗證包括：（1）系統訪問控制；（2）密碼變更方式和頻率；（3）病毒防護/探查方法和頻率；（4）自動注銷功能；（5）訪問復原要求流程。

2.6.1.10 培訓

所有參加安裝確認的人員，都應該參加足夠的培訓，以完成所分配的任務并明確培訓的內容。

2.6.1.11 流程

在執行安裝確認測試實例之前，以下工作必須完成：（1）安裝確認協議需要被批準；（2）軟硬件的風險評估需被確認；（3）每一個測試實例需要被批準。

2.6.1.12 測試執行

在正式測試前，需要對以下問題作出說明：系統訪問、閱讀測試實例、測試命令或數據輸入、系統截屏、測試結果、測試者姓名以及測試日期、測試員錯誤、非預期結果。

2.6.1.13 測試偏差

如果某種測試結果不能滿足之前提供的期望結果，測試員由于某種原因不能完成整個測試，或者驗證團隊主管決定某個測試結果不滿足預期結果則驗證團隊主管需要記錄該測試偏差，測試員需要填寫測試偏差記錄。內容應包括：測試偏差描述、偏差文檔、測試偏差分類、測試偏差調查、重新測試說明、重新測試、測試審核和結束、測試事件匯報和跟蹤。

2.6.1.14 測試結果審查

在每一個測試實例完成時，測試實例及其支持文檔應被測試員和驗證團隊主管獨立審查，以確保測試結果的完成，包括對于測試偏差報告的審核、安裝確認測試實例的審核等。

2.6.1.15 安裝確認報告

安裝確認報告將在測試完成后被編制和審批，該報告包含：（1）安裝確認測試的概要；（2）各安裝確認測試實例的結果；（3）產生的偏差事件以及結果；（4）與原測試計劃的偏離；（5）結果可接受性的結論。

2.6.2 安裝確認測試腳本

安裝確認測試腳本（表5）具體內容如下：

（1）需要明確測試的環境及服務器名稱、環境名稱等詳細描述。

（2）測試記錄應包括：規范描述、測試結果復核、步驟、操作/步驟描述、測試活動、預期結果、測試結果、測試結論、通過/不通過。

（3）總體測試結果：對測試結果作出判斷通過、不通過、在條件下通過的結論。

（4）審批矩陣。

（5）測試支持文檔：將測試過程中的主要結果以截圖方式提供。

表5 安裝確認測試腳本

2.6.3 安裝確認報告

文檔的目的是對安裝確認測試活動以及結果作出綜合性的評價。安裝確認測試已經執行，安裝確認的目的是確認系統的軟硬件已經按照需求安裝，并能支撐系統的運作。

2.6.3.1 詳細描述

記錄安裝測試腳本的實例匯總（表6），所有的測試腳本已經完成，并對所列項目以表格形式匯總測試結果，應包括：安裝確認編號、測試實例名、生產環境（通過/不通過）、驗證環境（通過/不通過）。

表6 安裝測試腳本的匯總

2.6.3.2 偏差記錄

測試員在IQ測試中發現的偏差已被記錄，驗證團隊已經對偏差進行了評估，并針對評估的結果制定了偏差處理的解決方案。根據解決方案，驗證團隊已經對系統進行了相應的變更并進行了重新測試。

2.6.3.3 偏差最終狀態

安裝協議中規定測試中出現的偏差需要重新測試，并在處理結果（表7）中顯示偏差描述、處理結果、偏差最終狀態，然后確認是否同意關閉。

表7 偏差最終狀態處理結果

2.6.3.4 結論

安裝確認已經按照安裝確認協議完整執行。安裝確認測試腳本已經完成編制，并經過審批和簽署。所有的偏差已經被記錄、報告、分析和處理，所有的偏差都已被關閉，可以進行運行確認測試。

2.7 運行確認

運行確認是指按照規范來進行的系統測試或其他核實活動，用來證明功能的正確運行能夠支持所有規定運行范圍內的具體業務流程。

2.7.1 運行確認協議

2.7.1.1 目的

運行確認協議的目的是記錄系統的運行與用戶要求及功能描述相一致的驗證過程。在批準和執行本運行確認協議并執行相關測試后，編制運行確認報告，管理層對運行確認報告的審批表示系統的功能運行已處于驗證狀態，可以進行下一步的性能確認。

2.7.1.2 范圍

運行確認測試的功能范圍為規范階段定義的系統功能需求，包括生產管理模塊、質量管理模塊等。

2.7.1.3 運行確認方法

文件定義了運行確認的目標、范圍、職責、方法、執行流程及驗收標準。對于GMP風險歸類被定義為“高”風險的功能需求，在運行確認測試中將進行重點測試。

（1）功能測試：運行確認單元功能測試是用來證明系統功能的運作符合項目的設計的，單元功能測試可以確認系統的運作功能是否能滿足企業在功能需求文檔中的要求。

（2）測試環境：運行確認單元測試會在信息系統的驗證環境中執行，該環境需要包括所有系統功能以及運行確認范圍下定制的對象。任何與單元測試、偏差/錯誤修復不相關的系統配置更新會被歸檔，且按照項目變更控制流程來評估。

（3）運行確認測試的建立和審批：每個編制完成的測試腳本會在執行之前被業務部門團隊主管及驗證團隊主管審批。對于已經審批的文檔如有任何更改，需要遵循文件控制流程。

（4）執行運行確認測試：經審批的運行確認測試腳本將被測試員執行測試，將執行運行確認單元測試腳本的結果以及相關的截屏打印出來，并在打印出的文件上簽署名字和日期。

（5）驗證：驗證主管需在執行測試腳本前審查和批準運行確認協議以及每個運行確認測試腳本，驗證團隊應確保測試環境已被正確安全地建立，確保驗證人員得到培訓并熟悉協議中所確定的流程。驗證主管需要評估運行確認的整體結果，來決定其是否滿足驗收標準。

（6）測試腳本的執行和審批：測試員需要遵循測試腳本中的測試步驟，記錄測試的實際結果，按需要提供系統截屏。測試員需要評估測試的實際結果，并確定它們是否滿足預期結果。如果滿足了預期結果，測試員需要標注該步驟為“通過”，如果沒有滿足預期結果，測試員需要標注該步驟為“未通過”，并且記錄為一個偏差。測試腳本應當在執行前由驗證主管審批。

（7）測試腳本執行后的審查：職能團隊主管需審查測試員的測試結果，也需要確認提供的相關文檔與腳本執行的結論（通過/未通過）相符，并提交驗證主管審查批準。

2.7.1.4 偏差管理

（1）偏差記錄。當測試結果與預期結果或者功能規范不符時，測試員需要記錄為一個偏差，并記錄相關的測試步驟編號。

（2）偏差分類。偏差可以分為嚴重、高、中、低4類。

（3）測試偏差調查：系統管理員、測試員和驗證團隊主管會評估每一個測試事件及其成因。

（4）重新測試。如果測試事件報告的結論是需要重新測試，驗證團隊主管將發布運行確認重新測試副本，需包含相關的測試實例，標記并簽名相關測試會被重新執行。測試完成后，測試人員將所有的文檔遞交給驗證團隊主管。

（5）最終協議審批及驗收標準。在測試執行結束后且執行性能確認測試前，必須滿足下列驗收標準：此協議下的所有測試腳本都被執行，且相關的系統截屏或者其他支持文檔都已提交。所有測試步驟被標注為“通過”，當標注為“未通過”時，相應的偏差被修復或已擁有合適的替代方案。偏差只有不影響用戶使用系統時，在結束運行確認后，才可以允許維持“未關閉”狀態。嚴重偏差和高偏差必須修復，或者至少有過渡時期的解決方案。中低偏差需要先確認分類是否準確，并提出相應的解決方案。

2.7.2 運行確認測試腳本

2.7.2.1 目的

文檔的目的在于確認系統滿足了功能需求，并且系統能夠用來執行性能確認測試。

2.7.2.2 測試范圍

文檔包括生產管理、質量管理流程的功能需求。

2.7.2.3 測試接受標準

測試結果與預期結果一致為通過，否則不通過。

2.7.2.4 測試環境描述

說明服務器名稱、測試環境、軟件版本等。

2.7.2.5 測試腳本

測試腳本中申明功能需求的編號、測試結果的復核，以及測試的步驟、操作描述、測試數據、預期結果、測試結果和測試結論。

2.7.2.6 偏差記錄

測試結果的審批。

2.7.3 運行確認報告

文檔目的是對運行確認測試活動以及結果給出綜合性的評價。運行確認測試已經完成，運行確認的目的是確認系統的功能需求已得到滿足，系統可以繼續執行性能確認的測試。

2.7.3.1 測試詳述

測試實例匯總，所有測試已經執行完畢。

2.7.3.2 偏差記錄（略）

2.7.3.3 結論

運行確認是已經按照運行確認協議被完整地執行。運行確認測試腳本已經完成編制，經過審批和簽署。所有的偏差已經被記錄、報告、分析和處理，所有的偏差都已被關閉，可以進行性能確認測試。

2.8 性能確認

通過測試和其他活動來證明系統符合預定用途，并允許按照所規定要求進行系統驗收。

2.8.1 性能確認協議

2.8.1.1 目的

性能確認是指通過文件記錄證明企業實施系統在業務流程和運行環境范圍內，能夠按照書面的預先已批準的用戶需求規范正確運行所要求的業務流程活動。性能確認將使用集成的測試業務場景。性能確認使用的是真實的業務數據，針對用戶角色安全功能的安全測試將被包含在性能確認中。

2.8.1.2 系統描述

系統包含生產管理模塊和質量管理模塊集成。

2.8.1.3 驗證范圍

驗證范圍僅限于在驗證主計劃（VMP-CN）中確定的企業實施的系統。性能確認測試的功能范圍為規范階段定義的用戶需求規范。在規范階段定義的用戶需求涉及生產業務流程、QA業務流程以及生產管理模塊、質量管理模塊等系統模塊。

2.8.1.4 性能確認方法（略）

2.8.1.5 測試數據需求

性能確認使用的是真實的業務數據，來確保每個單元模塊聯合起來操作后也能正常穩定地運作。

2.8.1.6 職責

定義性能確認的每個任務的執行和審核職責。

2.8.1.7 驗收標準

當下列條件滿足時，性能確認被認為滿足驗收標準：（1）用戶需求已得到滿足，系統能持續運作；（2）每個測試腳本的驗收標準已得到滿足；（3）所有性能確認的測試已經完成并圓滿通過；（4）異常情況被歸檔且解決；（5）性能確認報告圓滿完成，通過審核并得到審批。

2.8.1.8 測試的執行

（1）測試腳本審批：每個測試腳本在執行前需要得到職能團隊主管和驗證主管的批準。

（2）腳本執行：測試員需要遵循測試腳本中的測試步驟，記錄測試的實際結果，按需要提供系統截屏。測試員需要評估測試的實際結果，并決定它們是否滿足預期結果。如果滿足了預期結果，測試員需要標注該步驟為“通過”，如果沒有滿足預期結果，測試員需要標注該步驟為“未通過”，并且記錄為一個偏差。

（3）執行后審查：職能團隊主管需要對測試員提供的文檔以及測試結果進行審查。

2.8.1.9 偏差管理（略）

2.8.1.10 偏差記錄

當測試結果與預期結果或者功能規范不符時，測試員需要記錄為一個偏差，并記錄相關的測試步驟編號。

2.8.1.11 偏差分類（同運行確認測試協議）

2.8.2 性能確認測試腳本

2.8.2.1 目的

文檔的目的在于確認系統的生產管理、質量管理滿足了性能需求。

2.8.2.2 測試范圍

測試性能確認包括生產流程、質量管理流程系統性能需求。

2.8.2.3 測試條件的建立（略）

2.8.2.4 測試接受標準（略）

2.8.2.5 測試詳述

測試環境說明服務器名稱、測試環境、軟件版本等。

2.8.2.6 測試腳本

測試腳本中應申明功能需求的編號、測試結果的復核以及測試的步驟、操作描述、測試數據、預期結果、測試結果和測試結論。

2.8.2.7 偏差記錄（略）

2.8.2.8 測試結果審批（略）

2.8.3 性能確認報告

文檔的目的是對性能確認測試活動以及結果作出綜合性的評價，性能確認目的是確認系統的用戶需求已經得到滿足。

2.8.3.1 測試詳述

列出性能測試腳本的實例匯總，列出所有的測試腳本并已經執行完畢。

2.8.3.2 偏差記錄（略）

2.8.3.3 結論

性能確認已經按照性能確認協議被完整地執行。性能確認測試腳本已經完成編制，經過審批和簽署。所有的偏差已經被記錄、報告、分析和處理，所有的偏差都已被關閉。

2.9 驗證總結報告

2.9.1 項目概述（略）

2.9.2 驗證文件清單

驗證主計劃（VMP）、安裝確認協議（IQP）、安裝確認報告（IQR）、運行確認協議（OQP）、運行確認報告（OQR）、性能確認協議（PQP）、性能確認報告（PQR）。2.9.3 人員與職責（略）

2.9.4 驗證總結

驗證方法依據國際制藥工程協會（ISPE）的《良好自動化生產實踐指南》（GAMP5）中類別軟件產品（可配置軟件產品）適用的V字模型。驗證過程中編制的所有文檔均經過審批。

2.9.5 驗證主計劃描述

驗證主計劃描述包括：（1）業務流程描述；（2）用戶需求規范描述；（3）功能需求規范描述；（4）設計需求規范描述；（5）安裝確認；（6）運行確認；（7）性能確認；（8）用戶培訓驗證結果判定和結論。

3 結語

GMP附錄就驗證的定義可以看出，驗證是計算機化系統生命周期的一個組成部分，是持續地貫穿于整個生命周期的活動，在每一階段都需要產生驗證活動，尤其進入運行階段，從系統的變更管理活動而言，應更加注重基于風險評估的驗證活動，只有如此，才能使系統永久處于可驗證的良好運行狀態。