(高清版)GB∕T 37970-2019 軟件過程及制品可信度評估

ICS35.080L77中華人民共和國國家標準軟件過程及制品可信度評估T2019-08-30發(fā)布2020-03-01實施國家市場監(jiān)督管理總局ⅠGB／T37970—2019前言 引言 2規(guī)范性引用文件 3術語和定義、縮略語 3.1術語和定義 4軟件可信度模型 4.2軟件過程可信原則 4.3軟件制品可信原則 4.4軟件過程可信證據(jù) 4.5軟件制品可信證據(jù) 5軟件可信度等級 5.1軟件過程可信度等級 5.2軟件制品可信度等級 6軟件過程可信度評估 6.1軟件過程可信度評估過程 6.2過程證據(jù)的可信度評估 6.3可信原則的可信度評估 6.4軟件過程的可信度評估 7軟件制品可信度評估 7.1軟件制品可信度評估過程 7.2制品證據(jù)的可信度評估 7.3軟件制品的可信度評估 附錄A（資料性附錄）可信原則與CMMI過程域 附錄B（規(guī)范性附錄）軟件過程證據(jù) 附錄C（規(guī)范性附錄）軟件制品證據(jù) 附錄D（資料性附錄）軟件可信度評估示例 參考文獻 GB／T37970—2019本標準按照GB/T1.1—2009給出的規(guī)則起草。請注意本文件的某些內容可能涉及專利。本文件的發(fā)布機構不承擔識別這些專利的責任。本標準由全國信息技術標準化技術委員會(SAC/TC28)提出并歸口。本標準起草單位：中國科學院軟件研究所、中國電子技術標準化研究院、南京大學、中國科學院科技戰(zhàn)略咨詢研究院、廈門理工學院、上海計算機軟件技術開發(fā)中心、重慶郵電大學、北京拓爾思信息技術股份有限公司、羅普特（廈門）科技集團有限公司、北京知道未來信息技術有限公司。ⅢⅣGB／T37970—2019引言質量形成于過程。軟件可信的基本問題是需要有證據(jù)證明軟件產品能夠滿足用戶的需求，而這些證據(jù)散布于軟件開發(fā)的整個生存周期。所以，軟件是否可信不能僅依賴于對最終產品的測試，對軟件可信的評估和確認需要軟件開發(fā)過程中各類相關證據(jù)的支持。本標準旨在從軟件過程及制品的角度，建立系統(tǒng)化的可信度評估模型，指導軟件開發(fā)在過程中采集合適的數(shù)據(jù)，以形成證據(jù)，支持證據(jù)驅動下的軟件可信度評估。軟件可信并非一個新的質量特性，而是對軟件的功能性、安全性、可維護性、可靠性等各種質量特性滿足需求的程度的測量。受傳統(tǒng)行業(yè)全面質量管理理論的啟發(fā)，本標準提出面向過程的方法，通過關注和提高軟件開發(fā)過程的質量，來提高軟件的可信度。CMMI是被業(yè)界廣泛采用的軟件過程管理框架，目前運行的CMMIV1.3包括22個過程域，用軟件開發(fā)過程的知識技術解決軟件管理流程，強調改進軟件過程能力，提高軟件過程的成熟度，從而幫助企業(yè)有預期地、穩(wěn)定地在預算內按時交付滿足用戶要求的產品。本著兼容國際流行技術的準則，提出軟件過程可信原則覆蓋CMMIV1.3的22個過程域，另外擴充了對可信實體的保障，并通過制品可信原則對軟件過程的制品進行了可信增強。形成的軟件過程及制品可信證據(jù)體系，將軟件質量分解到軟件開發(fā)的各個階段和過程，有目標地采集過程數(shù)據(jù)，形成覆蓋軟件開發(fā)全過程的證據(jù)鏈，并最終對交付的軟件產品滿足預期質量目標的可信度進行評估。GB／T37970—2019軟件過程及制品可信度評估本標準規(guī)定了軟件過程和制品可信度評估使用的模型、可信等級和評估方法。本標準適用于指導開發(fā)軟件產品的組織建立可信的軟件過程，并采集數(shù)據(jù)，積累證據(jù)以支持對軟件產品質量的信心。同時也適用于第三方評估認證機構建立評估方法，對目標軟件產品及其開發(fā)組織開展第三方評估。2規(guī)范性引用文件下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T19001—2016質量管理體系要求GB/T25000.10—2016系統(tǒng)與軟件工程系統(tǒng)與軟件質量要求和評價(第10部分：系統(tǒng)與軟件質量模型GB/T25000.23—2019系統(tǒng)和軟件工程系統(tǒng)與軟件質量要求和評價(第23部分：系統(tǒng)與軟件產品質量測量3術語和定義、縮略語GB/T25000.10—2016、GB/T25000.23—2019和GB/T19001—2016界定的以及下列術語和定義適用于本文件。過程為給定目的所執(zhí)行的步驟序列，例如，軟件開發(fā)過程。[GB/T11457—2006,定義2.1183]3.1.2軟件過程由組織或項目使用的，用以計劃、管理、執(zhí)行、監(jiān)控和改進其軟件相關活動的過程或過程的集合。[GB/T11457—2006,定義2.1512]3.1.3軟件開發(fā)全過程軟件開發(fā)中的需求、設計、編碼和測試過程。注：與GB/T11457—2006中定義的開發(fā)過程相比，為便于可信指標的分類，軟件開發(fā)全過程專指需求、設計、編碼和測試四個過程。3.1.4制品由某一種軟件開發(fā)過程所使用的或產生的一種信息的物理件。制品的實例有模型、源文件、文字和12GB／T37970—2019二進制可執(zhí)行文件。制品可構成可部署構件的實現(xiàn)。[GB/T11457—2006,定義2.76]3.1.5過程可信度軟件過程能夠生產滿足期望產品的信心度。3.1.6制品可信度軟件過程產生的制品能夠滿足期望產品質量的信心度。3.1.7實體通過測量其屬性表述其特性的對象。例如，一個對象可能是過程、產品、項目或資源。[GB/T20917—2007,定義3.9]3.1.8可信原則由一組過程活動產生的證據(jù)來支持的，用于保障可信的通用要求。3.1.9可信過程域以可信保障目標為導向的一類可信原則。證據(jù)v針對軟件開發(fā)活動中留下的數(shù)據(jù)（如文檔、各種形式的記錄、證言等進行計算得到的，用于表明活動的表現(xiàn)是否滿足要求的測量數(shù)據(jù)。過程證據(jù)表征過程是否滿足期望的過程可信度的證據(jù)。注：該證據(jù)的數(shù)據(jù)類型分為布爾型、數(shù)值型、百分比型和等級型。制品證據(jù)v表征制品是否滿足期望的制品可信度的證據(jù)。注：該證據(jù)的數(shù)據(jù)類型分為布爾型、數(shù)值型、百分比型和等級型。軟件質量特性支撐軟件質量的軟件質量屬性的類別。[GB/T25000.10—2016,定義3.23]環(huán)境v支撐軟件開發(fā)的計算機、系統(tǒng)軟件、開發(fā)工具、網(wǎng)絡、基礎架構、數(shù)據(jù)管理設施等軟硬件條件或要求。依從性產品或系統(tǒng)遵循相關標準、約定或法規(guī)以及類似規(guī)定的程度。GB／T37970—2019形式化描述系統(tǒng)性質的基于數(shù)學的技術。規(guī)約為滿足某種需求而提供的解決方案。注：可稱為規(guī)格說明。下列縮略語適用于本文件。能力成熟度集成模型(過程域(4軟件可信度模型可信的基本要素包括可信的實體、可信的行為和可信的結果三個維度?？尚疟Ｕ夏繕藶椋簩嶓w可信、行為可信和結果可信。實體可信分解為開發(fā)活動中涉及的人、交互通道、環(huán)境以及使用的方法和工具；行為可信分解為開發(fā)過程中的行為管理、制品管理和文檔支持；結果可信分解為對過程產品的驗證和確認，其中“驗證”關注合適的過程制品檢驗方法，“確認”關注過程制品的質量滿足需求的程度。以可信保障目標為導向確定了七類可信原則，即7個可信過程域。其中實體安全、開發(fā)支持、文檔化、可管理、可追溯、可驗證關注過程的可信，定義為過程可信過程域，其對應的可信原則定義為軟件過程可信原則，共包含36個軟件過程可信原則；制品可信關注過程制品的可信，定義為制品可信過程域，其對應的可信原則定義為軟件制品可信原則，共包含1個可信原則?？尚旁瓌t與CMMI過程域的對比參見附錄A。每類可信過程域包含若干可信原則，每個可信原則由面向不同開發(fā)階段或軟件開發(fā)全過程的一組活動來保障，活動產生的數(shù)據(jù)形成證據(jù)來支持可信原則實現(xiàn)程度的評估。軟件可信度模型見圖1。圖1軟件可信度模型34GB／T37970—2019可信原則對應的證據(jù)結構見表1。其中證據(jù)等級表示該證據(jù)從該級開始要求，其滿足程度可不斷提高，最高等級大于或等于證據(jù)等級。注：一級可信等級表示有關的活動已執(zhí)行，但過程處于無定義和管理的狀態(tài)下，對活動的可信沒有要求，因此本模型沒有一級過程證據(jù)。表1可信原則的證據(jù)結構證據(jù)類型證據(jù)二級證據(jù)三級證據(jù)四級證據(jù)證據(jù)4.1、證據(jù)4.2……五級證據(jù)4.2軟件過程可信原則軟件過程可信原則共有36個，按照可信過程域類別和軟件開發(fā)階段兩個維度的分類組織見表2。橫向維度表示軟件過程可信原則涉及的軟件開發(fā)階段，包括需求、設計、編碼、測試等必要的典型階段，適合包括瀑布模型、敏捷開發(fā)在內的所有開發(fā)形式。各階段的具體內容如下：a)環(huán)境：指支撐軟件開發(fā)的計算機、系統(tǒng)軟件、開發(fā)工具、網(wǎng)絡、基礎架構、數(shù)據(jù)管理設施等軟硬件條件或要求，共8個可信原則；b)需求：軟件開發(fā)的需求階段，包括5個可信原則；c)設計：軟件開發(fā)的設計階段，包括5個可信原則；e)測試：軟件開發(fā)的測試階段，包括4個可信原則；f)軟件開發(fā)全過程：軟件開發(fā)的需求、設計、編碼和測試階段，這部分的可信原則貫徹軟件開發(fā)全過程，共9個可信原則。表2軟件過程相關的可信原則分類組織視圖過程域階段合計環(huán)境需求設計編碼測試軟件開發(fā)全過程實體安全安全政策4安全管理策略安全環(huán)境信息安全工具支持開發(fā)支持開發(fā)環(huán)境工具需求分析工具設計工具源代碼分析工具測試工具8重用支持開源支持采購支持5GB／T37970—2019過程域階段合計環(huán)境需求設計編碼測試軟件開發(fā)全過程可管理知識共享風險管理8管理制度化計劃環(huán)境完整性測量與分析配置管理過程審計文檔化需求分析文檔化設計文檔化源碼文檔化測試文檔化4可驗證形式化驗證要求形式化需求驗證形式化設計驗證形式化代碼驗證測試評審8需求分析評審設計評審源代碼評審可追溯需求可追蹤性設計可追蹤性源代碼可追蹤性測試可追蹤性4合計8555494.2.2實體安全過程域的可信原則實體安全過程域共有4個可信原則，包括：a)安全政策：所有的軟件開發(fā)者執(zhí)行開發(fā)活動應遵守明確定義的安全政策；b)安全管理策略：生存周期活動的執(zhí)行需要由至少兩個有資格的開發(fā)人員的認同和參與；c)安全環(huán)境：應明確安全機制，保證全生存周期活動不會受到未授權方法影響；d)信息安全工具支持：根據(jù)清晰定義的安全策略，所有確定的軟件生存周期活動應被軟件工程環(huán)境自動控制。4.2.3開發(fā)支持過程域的可信原則開發(fā)支持過程域共有8個可信原則，包括：a)開發(fā)環(huán)境工具：軟件工程環(huán)境和所有的軟件工具應根據(jù)一個明確的選擇策略來進行選擇，選擇策略中應考慮可信等級、成熟度、文檔和源碼的可獲取性等因素；b)重用支持：是否要構建可重用的組件以及可重用的程度；c)開源支持：開源軟件應接受選擇，清晰的選擇政策應考慮可信等級、成熟度、文檔、可獲取的源碼和軟件許可協(xié)議；d)采購支持：應與供應商建立采購合同以及評價采購產品質量的等級；e)需求分析工具：應使用需求分析工具以支持需求規(guī)約、一致性檢查和文檔生成；f)設計工具：在設計中應采用設計工具以維護設計／需求的跟蹤映射關系并生成設計文檔；g)源代碼分析工具：應使用測量復雜度和風格的源代碼分析工具和步驟來分析所有開發(fā)的代碼；h)測試工具：軟件工程環(huán)境應包含一個創(chuàng)造、執(zhí)行、文檔化和分析測試完整的測試工具集。6GB／T37970—20194.2.4可管理過程域的可信原則可管理過程域共有8個可信原則，包括：a)知識共享：每個軟件開發(fā)活動的組件，包括需求、源碼、設計、測試、軟件工具、方法和支撐活動等都應與至少兩個人員相關，這些人員非常熟悉這些組件的細節(jié)、隱含的意義和所考慮的選擇方案；b)管理制度化：根據(jù)管理文檔，應由有資格的人員對軟件工程環(huán)境、軟件工具和開發(fā)的軟件進行維護；c)環(huán)境完整性：對于識別軟件工程環(huán)境組件的變更應有一個明確的步驟，如果有需要，恢復環(huán)境的完整性；d)風險管理：與軟件開發(fā)活動相關的風險都應被明確地識別，風險移除策略應被文檔化；e)計劃：對于所有軟件開發(fā)活動的詳細計劃應在軟件開發(fā)計劃書中描述，軟件開發(fā)的管理也應遵循計劃書中所描述的方法；f)測量與分析：應對軟件過程和制品進行合適的測量和分析，以準確地理解過程和制品的狀態(tài)，及時了解過程的偏差，采取合理的糾正措施；g)配置管理：應建立一個配置管理系統(tǒng)，包括關于配置項識別、審核、控制和審計的明確機制和步驟。所有的配置項應保存在存放處以維護軟件版本、軟件修改請求和變更；h)過程審計：在全生存周期中負責軟件開發(fā)過程的總體和階段計劃、任務分配、溝通、協(xié)調、跟蹤、控制，保證任務質量和進度，并根據(jù)任務執(zhí)行情況追溯到每一個開發(fā)環(huán)節(jié)。4.2.5文檔化過程域的可信原則文檔化過程域共有4個可信原則，包括：a)需求分析文檔化：除了軟件需求規(guī)約和接口規(guī)約，所有幫助理解需求分析過程、重要的需求分析決策的原理等有用信息都應被文檔化；b)設計文檔化：除了軟件設計說明書和接口設計說明書外，設計活動的特性、考慮到的重要的設計選擇項和重要的設計理由都應被文檔化；c)源代碼文檔化：源碼和軟件編碼活動的特征應被文檔化；d)測試文檔化：除了軟件測試計劃書、軟件測試描述書和軟件測試報告以外，軟件組件和配置項測試活動的特征也應被文檔化。4.2.6可驗證過程域的可信原則可驗證過程域共有8個可信原則，包括：a)形式化驗證要求：按照形式化驗證要求，所有的形式化規(guī)約和驗證活動都應遵循一個合適的方法，包括使用形式化規(guī)約和驗證工具、文檔和同行評審等；b)形式化需求驗證：除了非形式化的需求規(guī)約以外，需求文檔應用一個形式化的框架來規(guī)約；c)需求分析評審：應由一個同行評審組對需求分析進行同行評審以保證軟件需求分析的完整性、一致性和正確性；d)形式化設計驗證：應對形式化的設計規(guī)約進行形式化設計驗證以確保滿足其需求；e)設計評審：應由一個同行評審組對設計進行同行評審以保證軟件設計的完整性、一致性和正確性；f)形式化代碼驗證：形式化驗證代碼是否滿足形式化規(guī)約，所有的形式化規(guī)約和驗證活動都應遵7GB／T37970—2019循一個包含了使用形式化規(guī)約和驗證工具、文檔、同行評審和可跟蹤映射的方法；g)源代碼評審：應由一個同行評審組對源碼進行同行評審以保證軟件源碼和計算機軟件單元測試的完整性、一致性和正確性；h)測試評審：應由一個同行評審組對測試進行同行評審以保證軟件測試的完整性、一致性和正確性。4.2.7可追溯過程域的可信原則可追溯域共有4個可信原則，包括：a)需求可跟蹤性：對于明確的系統(tǒng)需求或客戶來源，所有的軟件需求應保持可跟蹤性；b)設計可跟蹤性：設計的各方面和需求應是互相可跟蹤的；c)源代碼可跟蹤性：所有的源碼對于設計和計算機軟件單元測試應是可跟蹤的，設計對于源碼也應如此；d)測試可跟蹤性：所用軟件組件和配置項的測試對于需求應是可跟蹤的，源碼和需求對于組件和配置項的測試也應如此。4.3軟件制品可信原則軟件制品可信原則只有一項。按照軟件質量特性和軟件生存周期階段兩個維度，軟件制品可信原則對應證據(jù)的分類組織視圖見表3。橫向維度表示制品可信原則涉及的軟件全生存周期，包括設計、編碼、測試、交付、維護和軟件開發(fā)全過程。縱向維度表示GB/T25000.10—2016定義的8個軟件質量特表3軟件制品可信原則對應證據(jù)的分類組織視圖可信過程域可信原則質量特性階段合計設計編碼測試交付維護軟件開發(fā)全過程制品可信制品可信功能性226201性能效率00001兼容性2020015易用性103701可靠性301242信息安全性502401維護性109101可移植性0005016合計82494.4軟件過程可信證據(jù)由于不同軟件系統(tǒng)的可信要求不同，并不要求所有證據(jù)都要采集和測量，不同級別的證據(jù)支持不同級別的可信要求。例如，當軟件的可信要求為三級時，只需要評估各個原則三級及三級以下的證據(jù)。軟件可信度模型一共定義了133個過程證據(jù)，按照開發(fā)階段和可信過程域所對應的兩種等級分布，分別見8GB／T37970—2019表4和表5。具體證據(jù)見附錄B。表4按照軟件開發(fā)階段表示過程證據(jù)的等級分布開發(fā)階段可信原則證據(jù)等級一級二級三級四級五級證據(jù)數(shù)總計環(huán)境80900需求50010設計50020編碼50002測試40400軟件開發(fā)全過程90921總計053表5按照可信過程域表示過程證據(jù)的等級分布可信過程域可信原則證據(jù)等級一級二級三級四級五級總計實體安全40400開發(fā)支持80800可管理8021文檔化40000可驗證80031可追溯409001證據(jù)數(shù)總計053以下將從6個可信過程域的角度，提出軟件過程可信原則的證據(jù)要求。4.4.2實體安全過程域的可信證據(jù)實體安全過程域共有4個可信原則，涉及軟件開發(fā)全過程，共包含14個可信證據(jù)。軟件開發(fā)全過程可信原則下的可信證據(jù)如下：a)安全政策：安全政策的建立、安全相關政策的了解、培訓的開展；b)安全管理策略：背景調查、人員對可信知識了解程度、信息安全管理的程度、項目遵循安全要求的程度、安全管理相關培訓的開展、共享監(jiān)控機制；c)安全環(huán)境：安全工作環(huán)境標準的建立、軟件過程和資產訪問權限和環(huán)境的建立、網(wǎng)絡服務安全性；d)信息安全工具支持：自動化工具對權限控制的支持程度、組織結構對權限支持。9GB／T37970—20194.4.3開發(fā)支持過程域的可信證據(jù)開發(fā)支持過程域共有8個可信原則，涉及環(huán)境、需求、設計、編碼、測試五個階段，共包含33個可信證據(jù)。環(huán)境階段可信原則下的可信證據(jù)如下：a)開發(fā)環(huán)境工具：開發(fā)工具支持、工作環(huán)境標準的建立、環(huán)境與工具相關培訓的開展；b)重用支持：重用準則的建立、重用分析、支持和維護重用軟件架構的開發(fā)、重用部件的質量評價、可重用部件設計標準的建立；c)開源支持：對選擇的開源軟件的調研、對采用開源軟件的成本估算、開源軟件提供方持續(xù)的技術支持、開源軟件的質量評價、采用開源軟件的風險評估；d)采購支持：供應商目錄的建立、采購合同的建立和維護、采購產品質量的評價。需求階段的可信原則下可信證據(jù)主要為需求分析工具，即人員對需求分析工具的掌握程度、軟件需求分析自動化環(huán)境、自動化工具對需求分析的支持程度。設計階段的可信原則下可信證據(jù)主要為設計工具，即人員對設計工具的掌握程度、設計自動化環(huán)境。編碼階段的可信原則下可信證據(jù)主要為源代碼分析工具，即人員對代碼分析工具的掌握程度、自動化工具對源代碼分析的支持程度、源代碼庫。測試階段的可信原則下可信證據(jù)主要為測試工具，即測試工具類別的完整性、測試環(huán)境的搭建、人員對測試工具的掌握程度、測試數(shù)據(jù)和測試用例的設計、自動化工具對軟件測試的支持程度、單元測試策略、集成測試策略、配置項測試策略、組件測試策略。4.4.4可管理過程域的可信證據(jù)可管理過程域共有8個可信原則，涉及環(huán)境、軟件開發(fā)全過程，共包含41個可信證據(jù)。環(huán)境階段可信原則下的可信證據(jù)如下：a)知識共享：支持知識共享的組織資產庫覆蓋的范圍、共享知識的獲取方式、組織資產的改進與維護、組織培訓能力建立與維護；b)管理制度化：管理規(guī)程的建立、職責和權限的明確、培訓的開展、管理規(guī)程的覆蓋范圍、決策過程管理規(guī)范的建立；GB／T37970—2019c)環(huán)境完整性：軟件工程環(huán)境變更權限的配置、軟件工程環(huán)境變更的記錄、軟件工程環(huán)境的變更審查。軟件開發(fā)全過程可信原則下的可信證據(jù)如下：a)風險管理：風險管理計劃、發(fā)現(xiàn)識別和評價標準和指南的建立、風險管理策略的建立、項目風險管理的效果；b)計劃：軟件開發(fā)計劃書的編制、項目的人員配置和利益相關方的明確、項目過程制品和里程碑的明確定義和配置管理、風險的識別和評估、項目計劃的成熟程度、項目利用與貢獻組織資產的程度；c)測量與分析：測量目標的建立、相關的測量元和數(shù)據(jù)采集及測量和存儲方法的建立、測量體系覆蓋的程度、項目開展測量分析的程度、測量分析結果在組織級別的保存和分析、測量數(shù)據(jù)的采集、分析和存儲的工具支持、選擇的關鍵過程控制屬性在統(tǒng)計意義上的情況、過程異常的分析和改進、過程和產品持續(xù)改進機會的量化分析；d)配置管理：配置管理策略、配置基線管理、配置變更管理、配置狀態(tài)審計、軟件配置管理工具的使用、配置管理人員的成熟度；e)過程審計：內控制度的有效性、審計方法的充分性、審計過程的規(guī)范性、審計數(shù)據(jù)。4.4.5文檔化過程域的可信證據(jù)需求階段的可信原則下的可信證據(jù)主要為需求分析文檔化，即系統(tǒng)需求文檔化、用戶需求文檔化。設計階段的可信原則下的可信證據(jù)主要為設計文檔化，即過程設計文檔化、結構設計文檔化。編碼階段的可信原則下的可信證據(jù)主要為源代碼文檔化，即程序內部文檔化、數(shù)據(jù)說明文檔化。測試階段的可信原則下的可信證據(jù)主要為測試文檔化，即測試計劃書、集成測試文檔化、模塊測試文檔化、調試文檔化、驗收測試文檔化。4.4.6可驗證過程域的可信證據(jù)可驗證過程域共有8個可信原則，涉及環(huán)境、需求、設計、編碼、和測試五個階段，共包含24個可信證據(jù)。環(huán)境階段的可信要求下的可信證據(jù)主要為形式化驗證要求，即形式化可跟蹤性、形式化驗證同行評審。GB／T37970—2019需求階段可信原則下的可信證據(jù)如下：a)形式化需求驗證：形式化需求范圍、需求形式化程度、形式化需求規(guī)約；b)需求分析評審：操作概念和場景的評審、軟件需求的正式評審與審查、需求獲取階段的用戶介入、需求審計確認。設計階段可信原則下的可信證據(jù)如下：a)形式化設計驗證：形式化設計驗證范圍、形式化設計驗證、和形式化設計規(guī)約；b)設計評審：設計階段評審組的經(jīng)驗、設計階段的同行評審、設計審計策略。編碼階段可信下的可信證據(jù)如下：a)形式化代碼驗證：形式化代碼驗證范圍、形式化代碼驗證；b)源代碼評審：源碼評審標準、代碼評審的程度、代碼評審人員的經(jīng)驗。測試階段的可信原則下的可信證據(jù)主要為測試評審，即測試環(huán)境的評審、測試計劃的評審、測試用例的評審、測試標準的遵從。4.4.7可追溯過程域的可信證據(jù)可追溯域共有4個可信原則，涉及需求、設計、編碼和測試四個開發(fā)階段，共包含10個可信證據(jù)。需求階段的可信原則下的可信證據(jù)主要為需求可跟蹤性：軟件制品到需求的可跟蹤性等級。設計階段的可信原則下的可信證據(jù)主要為設計可跟蹤性：設計到需求的追蹤程度、需求到設計的追蹤程度。編碼階段的可信原則下的可信證據(jù)主要為源代碼可跟蹤性，即需求到原始需求和利益相關方的追蹤程度、需求到源代碼的可追蹤程度、源代碼到設計的可追蹤程度、設計到源代碼的可追蹤程度。測試階段的可信原則下的可信證據(jù)主要為測試可跟蹤性：測試到需求的可追蹤性、測試到設計的可追蹤性、測試到源代碼的可追蹤性。4.5軟件制品可信證據(jù)軟件制品可信證據(jù)共84個，隸屬于8個質量特性，覆蓋軟件開發(fā)全生存周期的制品。每個質量特GB／T37970—2019性由一組相關子特性組成，而每個子特性包含若干個證據(jù)。制品可信原則按照軟件開發(fā)階段和質量特性所對應的兩種等級分布，分別見表6和表7。表6按照軟件開發(fā)階段表示制品證據(jù)的等級分布開發(fā)階段證據(jù)場景等級一級二級三級四級五級總計設計13460編碼101002測試0551交付031維護004004軟件開發(fā)全過程810009證據(jù)數(shù)總計2表7按照質量特性分類表示制品證據(jù)的等級分布質量特性相關子特性證據(jù)場景等級一級二級三級四級五級證據(jù)數(shù)總計功能性430811性能效率410380兼容性3140005易用性613710可靠性512630信息安全性610920維護性611460可移植性3121116證據(jù)數(shù)總計2表6和表7中的證據(jù)場景指該證據(jù)在所屬的場景等級需要。在證據(jù)場景等級的界定方面借鑒了產品失效嚴重性分級體系，根據(jù)軟件產品可信程度下降可能導致的風險大小，從最低風險等級的一級（原型與實驗級）到最高風險等級五級（生命攸關級）逐級劃分見表8。表8產品失效嚴重性分級表級別類型一級二級三級四級五級系統(tǒng)級別原型與實驗級實用工具級一般產品級規(guī)模商業(yè)級生命攸關級失效損失級別微小損失可接受、可恢復的損失造成較大損失大規(guī)模危害性嚴重損失災難性損失典型系統(tǒng)實驗室級別系統(tǒng)辦公室級別辦公自動化軟件商業(yè)辦公軟件金融系統(tǒng)（支付寶、網(wǎng)銀系統(tǒng)）航空航天高鐵GB／T37970—2019具體證據(jù)見附錄C。以下將從8個質量特性的角度，提出軟件制品可信原則的證據(jù)要求。功能性質量特性共有13個證據(jù)，涉及設計、編碼、測試、交付和軟件開發(fā)全過程5個階段。設計階段的質量特性下可信證據(jù)如下：b)功能正確性：設計的正確與完整性。編碼階段的質量特性下可信證據(jù)如下：a)功能依從性：代碼中的注釋率；測試階段的質量特性下可信證據(jù)如下：a)功能完備性：需求覆蓋率和功能實現(xiàn)覆蓋率；b)功能正確性：功能正確性、計算正確性、估算的缺陷密度、實際的缺陷密度。交付階段的質量特性下可信證據(jù)如下：軟件開發(fā)全過程的質量特性下可信證據(jù)主要為功能性的依從性，包含一條證據(jù)：功能性的依從性。性能效率質量特性共有12個證據(jù)，處于交付和軟件開發(fā)全過程2個階段。交付階段的質量特性下可信證據(jù)如下：a)時間特性：平均響應時間、響應時間的充分性、平均周轉時間、周轉時間的充分性、平均吞吐率；b)資源利用性：平均處理器利用性、平均內存利用性、平均I/O設備利用性、帶寬利用性；軟件開發(fā)全過程的質量特性下可信證據(jù)主要為性能效率的依從性，包含一條證據(jù)：性能效率的依從性。GB／T37970—2019兼容性質量特性共有5個證據(jù)，涉及設計、測試和軟件開發(fā)全過程3個階段。設計階段的質量特性下可信證據(jù)如下：a)共存性：程序部件應用范圍的廣泛性；測試階段的質量特性下可信證據(jù)如下：軟件開發(fā)全過程的質量特性下可信證據(jù)主要為兼容性的依從性，包含一條證據(jù)：兼容性的依從性。易用性質量特性共有12個證據(jù)，涉及設計、測試、交付、軟件開發(fā)全過程4個階段。設計階段的質量特性下可信證據(jù)主要為可操作性，包含一條證據(jù)：撤銷能力。測試階段的質量特性下可信證據(jù)如下：b)用戶錯誤防范機制：抵御誤操作。交付階段的質量特性下可信證據(jù)如下：a)易用性的描述：描述的完整性和正確性；c)易學性：用戶指導完整性、錯誤理解率；d)用戶錯誤防范機制：用戶錯誤的修復。軟件開發(fā)全過程的質量特性下可信證據(jù)主要為易用性的依從性，包含一條證據(jù)：易用性的依從性。GB／T37970—2019可靠性質量特性共有12個證據(jù)，涉及設計、測試、交付、維護和軟件開發(fā)全過程5個階段。設計階段的質量特性下可信證據(jù)如下：a)成熟性：是否進行可靠性關鍵組件識別、是否進行關鍵組件可靠性分析；測試階段的質量特性下可信證據(jù)主要為成熟性，包含一條證據(jù)：測試覆蓋度。交付階段的質量特性下可信證據(jù)主要為易恢復性，包含兩條證據(jù)：平均恢復時間、數(shù)據(jù)備份的完成度。維護階段的質量特性下可信證據(jù)如下：軟件開發(fā)全過程的質量特性下可信證據(jù)如下：b)可靠性的依從性：可靠性的依從性。信息安全性質量特性共有12個證據(jù)，涉及設計、測試、交付和軟件開發(fā)全過程4個階段。設計階段的質量特性下可信證據(jù)如下：a)保密性：數(shù)據(jù)加密正確性、密碼算法的強度；b)抗抵賴性：唯一／特定身份鑒別方式的使用；c)可核查性：用戶審計跟蹤的完整性、系統(tǒng)日志的保留。測試階段的質量特性下可信證據(jù)如下：b)真實性：驗證規(guī)則的一致性。GB／T37970—2019交付階段的質量特性下可信證據(jù)如下：a)完整性：數(shù)據(jù)被破壞性、數(shù)據(jù)破壞保護、數(shù)據(jù)完整性保護；b)真實性：驗證機制的充分性。軟件開發(fā)全過程的質量特性下可信證據(jù)主要為信息安全性的依從性，包含一條證據(jù)：信息安全性的依從性。維護性質量特性共有12個證據(jù)，涉及設計、測試、交付和軟件開發(fā)全過程4個階段。設計階段的質量特性下可信證據(jù)主要為模塊化，包含一條證據(jù)：組件耦合度。測試階段的質量特性下可信證據(jù)如下：b)可重用性：資產可重用性、編碼規(guī)則一致性；c)易分析性：診斷功能的有效性、診斷功能的充分性；e)易測試性：測試功能的完整性、測試的自主性、測試的可重啟性。交付階段質量特性下可信證據(jù)主要為易修改性，包含一條證據(jù)：修改的正確性。軟件開發(fā)全過程的質量特性下可信證據(jù)主要為維護性的依從性，包含一條證據(jù)：維護性的依從性?？梢浦残再|量特性共有6個證據(jù)，處于交付和軟件開發(fā)全過程2個階段。交付階段的質量特性下可信證據(jù)如下：a)適應性：系統(tǒng)軟件環(huán)境的適應性、硬件環(huán)境的適應性、操作環(huán)境的適應性；軟件開發(fā)全過程的質量特性下可信證據(jù)主要為可移植性的依從性，包含一條證據(jù)：可移植性的依GB／T37970—2019從性。5軟件可信度等級5.1軟件過程可信度等級軟件過程可信度等級由一組可信原則和原則對應的證據(jù)組成，共有5個可信度等級，見圖2。圖2過程可信度等級自治級表現(xiàn)特征包括但不限于：a)軟件過程的特點是無秩序的，甚至是混亂的；b)軟件開發(fā)組織不能夠提供開發(fā)和維護軟件的穩(wěn)定環(huán)境；c)在開發(fā)中遇到危機時，一般項目組就會拋棄臨時拼湊的軟件開發(fā)過程，恢復到僅作代碼測試；d)項目的成功完全依賴于個人或團隊；e)進度、預算、功能性和產品質量不可預測；f)實施情況依賴于個人的能力，隨著個人技能、知識和動機的不同而變化，只能通過個人的能力而不是組織的能力去預測軟件項目的可信級別。管理級表現(xiàn)特征包括但不限于：a)軟件開發(fā)組織已建立了基本可信的項目管理過程，通過軟件管理和控制措施來保證軟件過程的可信；b)在點上建立了可信要求，可用于對成本、進度和功能特性進行可信度跟蹤；GB／T37970—2019c)軟件項目管理過程可信制度化，組織能重復在以前類似項目中的成功實踐；d)對項目實際可行的軟件管理和控制措施應根據(jù)以前項目總結出的經(jīng)驗和當前項目的實際需求而制定，進而保證其可信性。5.1.4過程可信度等級3：制度化管理級制度化管理級表現(xiàn)特征包括但不限于：a)用于管理的和工程的軟件過程均已文檔化、標準化，并形成了整個軟件組織的可信的標準過程；b)組織的全部項目均采用與實際情況相吻合的、適當修改后的標準軟件過程來進行操作；c)軟件組織通過已標準化的過程來保證對過程管理的控制和跟蹤是可信的；d)項目的過程能力是建立在整個組織的標準軟件過程的基礎上的，組織范圍內對項目定義的軟件過程中的活動、角色和職責具有共同的和一致的理解，進而保證了過程的可信。量化管理級表現(xiàn)特征包括但不限于：a)軟件開發(fā)組織對軟件產品和過程設置了定量的質量目標，并經(jīng)常對此進行測量和檢查；b)軟件過程均已配備有妥善定義的和一致的測量。優(yōu)化管理級表現(xiàn)特征包括但不限于：a)軟件過程在可管理、可驗證和可追溯上進一步加強，是一個持續(xù)優(yōu)化的過程；b)軟件組織為提高其軟件過程可信度等級進行著不懈的努力。5.2軟件制品可信度等級軟件制品可信度等級與軟件過程可信度等級是有聯(lián)系的，制品可信度等級的達成除與對應的制品證據(jù)可信度等級有關，也對軟件過程可信度等級有要求，具體見表9。表9制品可信度等級要求制品可信度等級過程可信度等級要求制品證據(jù)可信度等級要求制品可信度等級1制品可信度等級21級以上制品可信度等級31級以上制品可信度等級42級以上制品可信度等級52級以上5.2.2制品可信度等級1制品可信度等級1表現(xiàn)特征包括但不限于：在可信度等級1的基礎上，軟件組織的過程僅需要滿足一些制品的證據(jù)要求。這些制品是軟件開發(fā)最基本的；b)過程可信度等級要求達到1級。GB／T37970—20195.2.3制品可信度等級2制品可信度等級2表現(xiàn)特征包括但不限于：a)軟件開發(fā)過程中的制品需同時滿足1級和2級證據(jù)的可信要求；b)過程可信度等級要求達到1級以上；c)制品證據(jù)在兼容性、易用性、可靠性、可維護性和可移植性方面有增強。5.2.4制品可信度等級3制品可信度等級3表現(xiàn)特征包括但不限于：a)軟件組織已經(jīng)達到了第1、2和3級要求的制品證據(jù)的可信要求；b)過程可信度等級要求達到1級以上；c)制品證據(jù)在功能性、性能效率、易用性、可靠性、信息安全性、可維護性和可移植性上有可信的進一步要求。5.2.5制品可信度等級4制品可信度等級4表現(xiàn)特征包括但不限于：a)軟件組織達到了第1、2、3和4級的各個制品證據(jù)規(guī)定的可信要求；b)過程可信度等級要求達到2級以上；c)制品證據(jù)在功能性、性能效率、易用性、可靠性、信息安全性、可維護性和可移植性上定義了更高的可信要求。5.2.6制品可信度等級5制品可信度等級5表現(xiàn)特征包括但不限于：b)過程可信度等級要求達到2級以上；c)制品證據(jù)在功能性和可移植性上也有進一步要求。6軟件過程可信度評估6.1軟件過程可信度評估過程基于軟件開發(fā)過程中數(shù)據(jù)所形成的證據(jù)，量化評估軟件過程可信程度的模型，可有效支持軟件過程可信度評估的客觀性和全面性。軟件組織或項目可按以下6個步驟對軟件過程可信度進行評估：a)確定軟件開發(fā)要求的過程可信級別；b)基于模型的證據(jù)要求和項目實際情況，對證據(jù)進行裁剪，建立組織或項目適用的證據(jù)集合；d)評估證據(jù)達到的可信等級。對于未達到期望等級的證據(jù)所關聯(lián)的活動，應采取適當?shù)募m正措施，以管理和控制后續(xù)過程活動，保證整體目標的達成；e)評估可信原則達到的可信等級；f)評估軟件過程的實際可信級別。軟件過程可信度評估示例參見附錄D。6.2過程證據(jù)的可信度評估過程證據(jù)可信度的評估方法如下所述。GB／T37970—2019設表示某證據(jù)的可信等級，則：若該證據(jù)的測量值小于該證據(jù)的最小可信等級，則該證據(jù)的可信等級為1;若該證據(jù)的測量值介于其預定的最小可信等級和最大可信等級之間，則X表示其可映射到的可信等級；若該證據(jù)的測量值大于或等于該證據(jù)的最大可信等級，其可信等級即為最大可信等級。6.3可信原則的可信度評估在本模型中，可信原則滿足的可信程度取決于其下屬的證據(jù)所表征的可信級別?？尚旁瓌t達到的可信級別的評估方法如下所述。初始狀態(tài)下，可信原則的可信度為1。設表示某可信原則的可信等級，則：該原則下所有的2級證據(jù)，這些證據(jù)的可信等級都大于或等于2;該原則下所有的2級和3級證據(jù)，這些證據(jù)的可信等級：或者并且2級是該證據(jù)的最大可信等級；該原則下所有的2級、3級和4級證據(jù)，這些證據(jù)的可信等級：或者達到該證據(jù)的最大可信等級；該原則下所有的2級、3級、4級和5級證據(jù)，這些證據(jù)的可信等或者達到該證據(jù)的最大可信等級。6.4軟件過程的可信度評估基于對可信原則滿足程度的評估，進一步評估整個軟件過程實現(xiàn)的可信度水平。指定的可信范圍內，所有適用的原則應達到要求的可信級別。7軟件制品可信度評估7.1軟件制品可信度評估過程基于軟件開發(fā)過程中數(shù)據(jù)所形成的證據(jù)，評估軟件制品的可信程度。軟件組織或項目可按以下5個步驟對軟件制品可信度進行評估：a)確定軟件開發(fā)要求的制品可信級別。b)基于模型的證據(jù)要求和項目實際情況，進行證據(jù)裁剪，建立組織或項目適用的證據(jù)集合。d)評估證據(jù)是否達到要求。對于未達到期望等級的證據(jù)所關聯(lián)的制品，應采取適當?shù)募m正措施，保證整體目標的達成。e)結合過程可信度評估等級，評估軟件制品的實際可信度等級。軟件制品可信度評估示例參見附錄D。7.2制品證據(jù)的可信度評估制品證據(jù)可信度的評估方法如下所述。設T-表示某制品證據(jù)的可信等級，則：若該證據(jù)的測量值在該證據(jù)需要滿足的閾值之外，則該證據(jù)沒達到其適用的可信等級X,其可信度等級為1;若該證據(jù)的測量值在需要滿足的閾值范圍內，則該證據(jù)達到其適用的可信等級GB／T37970—2019X,其可信度等級為X。7.3軟件制品的可信度評估基于對制品證據(jù)滿足程度的評估，進一步評估整個軟件制品的可信度水平。對軟件制品的可信度評估遵循木桶原理，即在指定的可信范圍內，所有適用的原則應達到要求的可信級別。初始狀態(tài)下，軟件制品的可信度為1。設表示軟件制品的可信等級，則：所有的2級制品證據(jù)都達到了級要求在2級的基礎上，所有的3級制品證據(jù)都達到了3級要求，即在3級的基礎上，所有的4級制品證據(jù)都達到了4級要求，即在4級的基礎上，所有的5級制品證據(jù)都達到了5級要求，即對于在模型應用時判定為裁剪的制品證據(jù)，不做評估。GB／T37970—2019附錄A（資料性附錄）可信原則與CMMI過程域CMMI模型共有22個過程域，分為5個成熟度等級，表A.1詳細標注了每個過程域的名稱和成熟度等級。CMMI強調過程管理的制度化和過程的穩(wěn)定性，通過過程的改進不斷使得過程穩(wěn)定，并且在控制下持續(xù)改善能力。隨著成熟能力的提高，過程量化控制的能力越強。軟件可信的目標并不在于強調過程的穩(wěn)定可控，而是過程管理的可信性。穩(wěn)定的過程在測量分析的能力上具備更好的可信程度，但并不意味在所有的可信要求上都具備更好的可信程度。表A.1CMMI模型的22個過程域等級過程域(5.優(yōu)化級組織績效管理）原因分析與解決）4.量化級組織過程性能績效量化項目管理）3.定義級技術解決方案）產品集成）驗證確認）組織過程關注焦點組織過程定義）組織培訓）集成項目管理）風險管理）決策分析與解決）2.管理級項目計劃）項目監(jiān)督與控制）供應商協(xié)議管理）測量和分析）過程和產品質量保證）配置管理）1.初始級 為了敘述簡便，所有22個過程域PA均采用英文首字母簡寫的方式表示。可信原則與CMMI過程域的對應關系見圖A.1,其中實心圓點表示可信原則與過程域PA存在主要對應關系，而空心圓點表示該可信原則應該涵蓋的過程域PA,但實際并未與其存在主要對應關系?？尚旁瓌t覆蓋CMMIV1.3包含的22個過程域，并擴充了對可信實體、開源軟件的支持，以及對過程制品的可信增強。增加了實體安全類中的4個可信原則，擴充了CMMI模型在實體資源的實踐要求?？尚艑嶓w的保障則是由“實體安全可信”域的四個可信原則來保障。CMMI模型雖然也包括軟件GB／T37970—2019開發(fā)實體（實踐者）的活動以及工作環(huán)境的建立，譬如OPD中對過程和環(huán)境的要求，以及OT要求的培訓，但關注的主要焦點是工程師的技能是否可以勝任工作以及人員培訓、溝通、協(xié)同和承諾等，不能完全覆蓋本模型對實體可信的全部要求。此外，開源軟件是當前軟件開發(fā)組織中最常用到的資源，在CMMI模型中沒有專門的關注。圖A.1可信原則與CMMI過程域的對應關系GB／T37970—2019附錄B（規(guī)范性附錄）軟件過程證據(jù)B.1實體安全過程域的過程證據(jù)實體安全過程域共有14個過程證據(jù)，全部貫穿軟件開發(fā)全過程，見表B.1。表B.1實體安全過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級軟件開發(fā)全過程安全政策建立是否建立安全政策布爾型2是同二級要求同二級要求同二級要求安全相關政策的了解人員是否了解安全相關政策布爾型2是同二級要求同二級要求同二級要求培訓的開展是否對組織成員進行過軟件可信包括安全方面的培訓布爾型3—是同三級要求同三級要求軟件開發(fā)全過程安全管理策略背景調查人員入職前是否做過背景調查布爾型2是同二級要求同二級要求同二級要求人員對可信知識了解程度組織成員對于軟件程度等級型22一般了解3有專門的培訓4有專業(yè)的職業(yè)認證資格同四級要求信息安全管理的程度組織中針對信息安全管理的程序等級型22建立了規(guī)程3建立專門的信息安全體系4通過信息安全體系審核同四級要求項目遵循安全要求的程度安全要求的程度等級型22遵照執(zhí)行，但少數(shù)有弱項3遵照執(zhí)行，但多數(shù)有弱項4遵照執(zhí)行，沒有弱項同四級要求安全管理相關的培訓的開展是否開展了安全管理相關的培訓布爾型3—是同級三要求同三級要求共享監(jiān)控機制對于知識共享的方動是否有監(jiān)控機制布爾型3 是同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級軟件開發(fā)全過程安全環(huán)境安全工作環(huán)境標準的建立是否建立安全工作環(huán)境標準布爾型2是同二級要求同二級要求同二級要求軟件過程和資產訪問權限和環(huán)境的建立是否建立軟件過程和資產訪問權限和環(huán)境布爾型2是同二級要求同二級要求同二級要求全性常見的網(wǎng)絡服務有無可信信道來提供加密、認證或完整性等保護等級型22少部分保護3大部分保護4全部保護同四級要求軟件開發(fā)全過程信息安全工具支持自動化工具對權限控制的支持程度按照權限控制工具的自動化程度分級等級型22少部分支持3大部分支持4全部支持同四級要求組織結構對權限支持組織結構是否對權限支持布爾型3 是同三級要求同三級要求注：“—”表明該證據(jù)在該等級不做要求。B.2開發(fā)支持過程域的過程證據(jù)開發(fā)支持過程域共有33個過程證據(jù)，涉及環(huán)境、需求、設計、編碼、和測試五個階段，表B.2開發(fā)支持過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級環(huán)境開發(fā)環(huán)境工具開發(fā)工具支持是否有開發(fā)工具支持布爾型2是同二級要求同二級要求同二級要求工作環(huán)境標準的建立是否建立了工作環(huán)境標準布爾型3 是同三級要求同三級要求環(huán)境和工具培訓的開展是否開展了環(huán)境和工具的培訓布爾型3 是同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級環(huán)境重用支持建立是否建立了重用的準則布爾型2是同二級要求同二級要求同二級要求重用分析分析構建或使用重用模塊的成本和風險等級型22低成本風險3一般4高成本風險同四級要求支持和維護重用的軟件架構的開發(fā)開發(fā)支持和維護重程度等級型22建立了重用部件支持文檔3建立支持重用的軟件體系架構4建立自動化工具支持同四級要求重用部件的質量評價對重用部件質量評價的程度等級型22通過了系統(tǒng)測試3交付使用同三級要求同三級要求可重用部件設計標準的建立是否建立了可重用部件的設計標準布爾型3—是同三級要求同三級要求環(huán)境開源支持對選擇的開源軟件的調研是否對選擇開源軟件進行過調研布爾型2是同二級要求同二級要求同二級要求對采用開源軟件的成本估算是否對采用開源軟件的成本估算布爾型2是同二級要求同二級要求同二級要求開源軟件提供方持續(xù)的技術支持對開源軟件提供方持續(xù)的技術支持程度等級型22沒有3一般4強同四級要求開源軟件的質量評價對開源軟件的質量評價的要求等級型22內部評價3開源社區(qū)評價4可信評估同四級要求采用開源軟件的風險評估是否采用開源軟件的風險評估布爾型3 是同三級要求同三級要求環(huán)境采購支持供應商目錄的建立是否建立了供應商布爾型2是同二級要求同二級要求同二級要求采購合同的建立與維護是否建立和維護了采購合同布爾型2是同二級要求同二級要求同二級要求采購產品質量的評價評價采購產品質量等級等級型22驗收測試采購產品3對采購產品進行了可信評估同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級需求需求分析工具人員對需求分析工具的掌握程度根據(jù)需求分析工具在組織內的使用范開發(fā)人員掌握程度分級等級型22開發(fā)小組，半年以上，一般掌握3較熟練同三級要求同三級要求軟件需求分析自動化環(huán)境對軟件需求分析自動化程度的要求等級型22需求分析工具覆蓋少量需求開發(fā)和管理活動3需求分析工具覆蓋部分需求開發(fā)管理活動4需求分析工具覆蓋關鍵的需求規(guī)跟蹤和文檔生成活動5需求分析工具全面覆蓋需求致性檢跟蹤和文檔生成自動化工具對需求分析的支持程度按照需求分析工具的自動化程度分級等級型22少部分支持3大部分支持4全部支持同四級要求設計設計工具人員對設計工具的掌握程度根據(jù)設計工具在組織內的使用范圍、使用時間以及開發(fā)人員掌握程度分級等級型23開發(fā)小組，半年以上，一般掌握同二級要求4較熟練同四級要求環(huán)境使用集成文本、標準軟件圖形和數(shù)據(jù)字典的計算機化的工具等級型22只有文本自動化工具支持的半正式設計3具有文本/圖形工具支持的半正式設計4正式的設計方法和自動化的文本/圖形支持同四級要求編碼源代碼分析工具人員對代碼分析工具的掌握程度根據(jù)代碼分析工具在組織內的使用范開發(fā)人員掌握程度分級等級型22個人使用，半年以內，不太熟練3開發(fā)小組，半年以上，一般掌握4較熟練同四級要求自動化工具對源代碼分析的支持程度按照源代碼分析工分級等級型22有工具3工具可部署自動代碼分析同三級要求同三級要求源代碼庫對于正在開發(fā)的源代碼組件進行系統(tǒng)化的存儲和控制變更的手段等級型22有源碼庫3源碼庫有合理的配置管理策略4源碼庫可支持代碼分析工具同四級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級測試測試工具測試工具類別的完整性根據(jù)組織使用的測試工具的類型（實施軟件標準類、需性能分析類、產生測試腳本類將其完整級別分級等級型22完整性中（包括類別數(shù)同二級要求3完整性高（包括類別數(shù)同四級要求搭建根據(jù)測試環(huán)境的完整性分級等級型23有少量遺漏4較為完整5完整同四級要求人員對測試工具的掌握程度根據(jù)測試工具在組織內的使用范圍、使用時間以及開發(fā)人員掌握程度分級等級型23開發(fā)小組，半年以上，一般掌握4較熟練同三級要求5全公司用超過練掌握測試數(shù)據(jù)和測試用例的設計根據(jù)測試數(shù)據(jù)和測試用例的覆蓋程度分級等級型23有少量遺漏4覆蓋程度較高5覆蓋程度高同四級要求自動化工具對軟件測試的支持程度按照測試工具的自動化程度分級等級型22少部分支持同二級要求同二級要求3大部分支持單元測試策略是否有單元測試策略布爾型3 是同三級要求同三級要求集成測試策略是否有集成測試策略布爾型3 是同三級要求同三級要求配置項測試策略是否有配置項測試策略布爾型3 是同三級要求同三級要求組件測試策略是否有組件測試策略布爾型3—是同三級要求同三級要求注：“—”表明該證據(jù)在該等級不做要求。GB／T37970—2019B.3可管理過程域的過程證據(jù)可管理過程域共有41個過程證據(jù)，涉及環(huán)境、軟件開發(fā)全過程，見表B.3。表B.3可管理過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級環(huán)境知識共享支持知識共享的組織資產庫覆蓋的范圍支持知識共享的組織資產庫覆蓋的范圍的要求等級型22有知識共享3在組織級別建立了支持知識共享的資產庫同三級要求同三級要求共享知識的獲取方式組織對獲取共享知識的方式的要求等級型22隨機獲取3建立常態(tài)的收集改進建議和共享知識的機制4對重要建議部署的過程5對部署的改進有計劃、價和部署的過程組織資產的發(fā)改進與維護改進和維護組織資產的程度等級型3—3和監(jiān)督改進的過程資產4基于過程資產。量化分析持續(xù)的改進同四級要求組織培訓能力的建立和維護是否具備建立和維護組織的培訓能力布爾型3—是同三級要求同三級要求環(huán)境管理制度化建立是否建立管理規(guī)程布爾型2是同二級要求同二級要求同二級要求職責和權限的明確權限布爾型2是同二級要求同二級要求同二級要求培訓的開展是否開展了培訓布爾型2是同二級要求同二級要求同二級要求管理規(guī)程的覆蓋范圍組織中對管理規(guī)程的覆蓋范圍的要求等級型22建立項目估基本程序3建立了CMMI3級所有PA的管理規(guī)程4建立了量化管理過程的規(guī)程5建立改進組織業(yè)務性能的管理規(guī)程決策過程管理規(guī)程的建立是否建立決策過程的管理規(guī)程布爾型3 是同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級環(huán)境環(huán)境完整性軟件工程環(huán)境配置是否定義軟件工程環(huán)境變更權限布爾型2是同二級要求同二級要求同二級要求軟件工程環(huán)境變更的記錄是否有軟件工程環(huán)境組件變更識別的功能布爾型3 是同三級要求同三級要求軟件工程環(huán)境的變更審查是否對軟件工程環(huán)境變更的審查布爾型3 是同三級要求同三級要求軟件開發(fā)全過程風險管理風險管理計劃是否有風險管理計劃布爾型2是同二級要求同二級要求同二級要求發(fā)現(xiàn)識別和評價標準和指南的建立是否建立了發(fā)現(xiàn)識別和評價的標準和指南布爾型3—是同三級要求同三級要求風險管理策略的建立是否建立風險管理的策略布爾型3—是同三級要求同三級要求項目風險管理的效果項目風險管理的效果等級等級型3—3識別的高等級風險少量發(fā)生4識別的高等級風險無發(fā)生同四級要求軟件開發(fā)全過程計劃軟件開發(fā)計劃書的編制是否編制了軟件開發(fā)計劃書布爾型2是同二級要求同二級要求同二級要求項目的人員配置和利益相關方的明確是否明確了項目的人員配置和利益相關方布爾型2是同二級要求同二級要求同二級要求項目過程制品和里程碑的明確定義與配置管理項目過程制品和里程碑是否明確定義并建立合適的配置管理布爾型2是同二級要求同二級要求同二級要求風險的識別和評估是否識別和評估了風險布爾型2是同二級要求同二級要求同二級要求項目計劃的成熟程度的成熟程度等級型22項目做了估算3計劃變更受控4計劃執(zhí)行無重大偏差5計劃執(zhí)行在統(tǒng)計意義上受控項目利用與貢獻組織資產的程度和貢獻組織資產的程度等級型22參考組織資產進行估算3基于組織過程建立項目過程4項目的產出和知識貢獻到組織資產同四級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級軟件開發(fā)全過程測量與分析建立是否建立了測量布爾型2是同二級要求同二級要求同二級要求元、數(shù)據(jù)采集，以及測量和存儲方法的建立是否建立了相關的測量元、數(shù)據(jù)采集，以及測量和存儲方法布爾型2是同二級要求同二級要求同二級要求測量體系覆蓋的程度組織中測量體系覆蓋的程度等級型22有測量3在組織級別建立了測量體系4建立了關鍵過程的性能基線和量化管理的方法5建立原因分析和改進效果評價的測量方法項目開展測量分析的程度測量分析的程度等級型22部分項目有測量3全部項目按組織要求進行了測量同三級要求同三級要求測量分析結果在組織級別的保存和分析測量分析結果是否在組織級別進行保存和分析布爾型3 是同三級要求同三級要求測量數(shù)據(jù)的采儲的工具支持是否有工具支持測析和存儲布爾型3 是同三級要求同三級要求選擇的關鍵過程控制屬性在統(tǒng)計意義上的情況選擇的關鍵過程控制屬性是否在統(tǒng)計意義上穩(wěn)定布爾型4 是同四級要求過程異常地分析和改進是否對過程異常進行了分析和改進布爾型4 是同四級要求過程和產品持續(xù)改進機會的量化分析是否通過量化方法分析過程和產品持續(xù)改進的機會布爾型5 是配置管理配置管理策略配置管理策略的建立情況等級型22建立了配置管理策略3配置管理策略分區(qū)有作和資產管理同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級軟件開發(fā)全過程配置管理配置基線管理情況等級型22識別了配置配置基線3配置基線設置合理同三級要求同三級要求配置變更管理是否進行了配置變更管理布爾型2是同二級要求同二級要求同二級要求配置狀態(tài)審計是否進行了配置狀態(tài)審計布爾型2是同二級要求同二級要求同二級要求軟件配置管理工具的使用是否使用了軟件配置管理工具布爾型2是同二級要求同二級要求同二級要求配置管理人員的成熟度配置管理人員對配置管理工作的了解情況等級型22了解配置職能3專職配置人置智能同三級要求同三級要求軟件開發(fā)全過程過程審計內控制度的有效性控制系統(tǒng)資源的存的使用、建立按用戶職能分配資源的使用情況、確認處理過程的準確性、管理人員對系統(tǒng)的計算機病毒的襲擊等級型22審計覆蓋較少部分3審計覆蓋較多部分4審計覆蓋全部同四級要求審計方法的充分性字描述法、表格描述法、圖形描述法等級型22憑經(jīng)驗3有檢查單等資源4有多種審計方式同四級要求審計過程的規(guī)范性施階段和報告階段等級型22有審計計劃3有審計過程規(guī)程和指南同三級要求同三級要求審計數(shù)據(jù)程度等級型22有審計記錄3對審計進行測量分析同三級要求同三級要求注：“—”表明該證據(jù)在該等級不做要求。GB／T37970—2019B.4文檔化過程域的過程證據(jù)文檔化過程域共有11個過程證據(jù)，涉及需求、設計、編碼和測試四個開發(fā)階段，見表B.4。表B.4文檔化過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級需求需求分析文檔化檔化系統(tǒng)需求文檔應更詳細的描述系統(tǒng)的功能性需求和非功能性需求。如果可的更進一步的信息可添加。根據(jù)系統(tǒng)需求內容的完整性分級等級型22包含功能性需求和非功能性需求的描述3詳細包含上面所描述的內容同三級要求同三級要求用戶需求文檔化用戶需求定義文檔應描述系統(tǒng)為用戶系統(tǒng)的非功能性需求。這些描述可使或者其他用戶可以理解的形式。產品和過程標注也應被定義好。根據(jù)用戶需求定義內容的完整性分級等級型22至少要包含系統(tǒng)為用戶提供服務的能性需求的描述不是很完整和具體3詳細包含上面所描述的內容同三級要求同三級要求設計設計文檔化過程設計文檔化根據(jù)是否完整、準統(tǒng)的過程設計，將過程設計文檔化指標分級等級型22剛好滿足軟件項目活動正常進行的需要3同三級要求同三級要求過程設計信分滿足軟件項目活動需要結構設計文檔化根據(jù)是否完整、準統(tǒng)的體系結構設計文檔化分級等級型22剛好滿足軟件項目活動正常進行的需要3結構設計信分滿足軟件項目活動的需要同三級要求同三級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級編碼源代碼文檔化檔化程序內部文檔包含恰當?shù)臉耸痉⑦m當?shù)淖⑨尯统绦虻囊曈X組織等。根據(jù)這一概念，將程序內部文檔化指標分級等級型22程序內部文檔化使得源程序代碼恰好可讀3程序內部的文檔化使得源程序代碼邏輯簡明清懂同三級要求同三級要求檔化數(shù)據(jù)說明的次序應個復雜的數(shù)據(jù)結構時宜用注解說明。根據(jù)這個原則，將數(shù)據(jù)說明文檔化指標分級等級型22剛好滿足軟件項目活動正常進行的需要3記錄各種詳夠充分滿足軟件項目活動的需要同三級要求同三級要求測試測試文檔化測試計劃書是否有測試計劃書布爾型2是同二級要求同二級要求同二級要求集成測試文檔化根據(jù)是否對集成測試的方法選擇、具體執(zhí)行以及測試用例等信息進行詳細說明，將集成測試文檔化指標分級等級型22剛好滿足軟件項目活動正常進行的需要3記錄各種詳夠充分滿足軟件項目活動的需要同三級要求同三級要求模塊測試文檔化根據(jù)是否對模塊接口、局部數(shù)據(jù)結構、重要執(zhí)行通路、出錯處理通路、邊界條件的測試以及測試用例等信息進行詳細說明，將模塊測試文檔化指標分級等級型22剛好滿足軟件項目活動正常進行的需要3記錄各種詳夠充分滿足軟件項目活動的需要同三級要求同三級要求調試文檔化根據(jù)是否對調試的等信息進行詳細說檔化指標分級等級型22剛好滿足軟件項目活動正常進行的需要3記錄各種詳夠充分滿足軟件項目活動的需要同三級要求同三級要求驗收測試文檔化根據(jù)是否對驗收測試中方法選擇、具體執(zhí)行情況、用戶參與情況以及測試用例等信息進行詳試文檔化指標分級等級型22包含總體功能描述或如何融入到原有系統(tǒng)中的其中一個3詳細包含上面所描述的內容同三級要求同三級要求GB／T37970—2019B.5可驗證過程域的過程證據(jù)可驗證過程域共有24個過程證據(jù)，涉及環(huán)境、需求、設計、編碼和測試五個階段，見表B.5。表B.5可驗證過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級環(huán)境形式化驗證要求形式化可跟蹤性是否建立了從形式化需求規(guī)約—形式化設計—形式化設計驗證—形式化代碼驗證的跟蹤關系布爾型2是同二級要求同二級要求同二級要求形式化驗證同行評審在形式化規(guī)約和驗證的活動中是否有同行評審布爾型2是同二級要求同二級要求同二級要求需求形式化需求驗證形式化需求范圍組織對形式化需求的要求范圍等級型21化需求）同二級要求2鍵相關部分）3需求形式化程度組織對需求形式化程度的要求等級型21描述性需求同二級要求2半形式化需求3形式化需求形式化需求規(guī)約是否有形式化需求規(guī)約布爾型4 是同四級要求需求需求分析評審操作概念和場景的評審是否周期性評審操作概念和場景布爾型2是同二級要求同二級要求同二級要求軟件需求的正式評審與審查指本項目組所進行的正式評審和審查的有效性。這些質量驗證技術包括工致性和開發(fā)方針及標準的符合程度等級型23評審和審查是非正式有效4絕大多數(shù)評審和審查都是正式的，非常有效的5所有評審和審查都是正有效的同四級要求需求獲取階段的用戶介入最終用戶在需求收集階段的介入程度等級型23在需求獲取在一定程度上介入4在需求獲取數(shù)用戶全面介入5所有用戶都全面介入同四級要求需求審計確認是否有需求審計確認布爾型2是同二級要求同二級要求同二級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級設計設計評審形式化設計驗證范圍組織對形式化設計驗證范圍的要求等級型21化驗證）同二級要求2鍵相關部分）3形式化設計驗證是否有形式化設計驗證布爾型4——是同四級要求形式化設計規(guī)約是否有形式化設計規(guī)約布爾型4——是同四級要求設計形式化設計驗證設計階段評審組的經(jīng)驗指項目組成員在執(zhí)行正式設計評審方面的平均經(jīng)驗。這些從事質量驗證技是判斷完整性、正是否符合開發(fā)方針和標準等級型2平均2年同三級要求同三級要求設計階段的同行評審是否有同行評審布爾型2是同二級要求同二級要求同二級要求設計審計策略對設計階段的過程產品是否有審計制度布爾型2是同二級要求同二級要求同二級要求編碼形式化代碼驗證形式化代碼驗證范圍形式化代碼驗證范圍等級型21化驗證）同二級要求2鍵相關部分）3形式化代碼驗證是否有形式化代碼驗證布爾型5———是編碼源代碼評審源碼評審標準是否有源碼評審標準布爾型2是同二級要求同二級要求同二級要求程度組織對代碼評審的程度的要求等級型22同行評審3上級評審4管理評審5質量評審代碼評審人員的經(jīng)驗指項目組成員在執(zhí)行代碼審查方面的經(jīng)驗大小。這些從事質量驗證技術，包括工作產品的小斷完整性、正確性、一致性以及是否符合開發(fā)方針和標準數(shù)值型223平均2年4平均3年以上同四級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級測試測試評審評審是否對測試環(huán)境的評審布爾型2是同二級要求同二級要求同二級要求評審是否對測試計劃的評審布爾型2是同二級要求同二級要求同二級要求評審是否對測試用例的評審布爾型2是同二級要求同二級要求同二級要求遵從測試滿足的標準/計劃中所有測試標準260%80%90%95%注：“—”表明該證據(jù)在該等級不做要求。B.6可追溯過程域的過程證據(jù)可追溯域共有10個過程證據(jù)，涉及需求、設計、編碼和測試四個開發(fā)階段，見表B.6。表B.6可追溯過程域的過程證據(jù)階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級需求需求可跟蹤性軟件制品到需求的可跟蹤性等級軟件制品到需求的可跟蹤性情況等級型22部分軟件需求在概要設可用的跟蹤定效果同二級要求3對于關鍵的軟件需求在了較為完整同四級要求設計設計可跟蹤性設計到需求的追蹤程度一個設計是否可追蹤到對應的需求布爾型2是同二級要求同二級要求同二級要求需求到設計的追蹤程度一個需求是否可追蹤到對應的設計布爾型2是同二級要求同二級要求同二級要求GB／T37970—2019階段可信原則過程證據(jù)名稱描述類型適用等級二級三級四級五級編碼源代碼可跟蹤性需求到原始需求和利益相關方的追蹤程度一個需求是否能夠追蹤回溯到原始需求和提出需求的利益相關方布爾型2是同二級要求同二級要求同二級要求需求到源代碼的可追蹤程度一個需求是否可追蹤到至少一塊代碼布爾型2是同二級要求同二級要求同二級要求源代碼到設計的可追蹤程度一塊代碼是否可追蹤到至少一個對應的設計布爾型2是同二級要求同二級要求同二級要求設計到源代碼的可追蹤程度一個設計是否可追代碼布爾型5 是測試測試可跟蹤性測試到需求的可追蹤性所用軟件組件和配置項的測試對于需求是否是可跟蹤的布爾型2是同二級要求同二級要求同二級要求測試到設計的可追蹤性測試是否可追蹤到至少一個設計布爾型2是同二級要求同二級要求同二級要求測試到源代碼的可追蹤性測試是否可追蹤到至少一塊代碼布爾型2是同二級要求同二級要求同二級要求注：“—”表明該證據(jù)在該等級不做要求。GB／T37970—2019附錄