基于DO－178B的軟件配置管理技術研究*

毛 佳，胡林平

(中國航空計算技術研究所，西安710068)

1 概述

隨著航空工業的飛速發展，航空軟件產品的安全性與穩定性已經成為研制單位進行市場抗衡的重要砝碼。而軟件過程能力的高低往往對其起著決定性的作用。軟件過程管理中，配置管理技術無疑又是重中之重:混亂的配置管理可以使所有軟件工程師長期的心血毀于一旦;更嚴重者，可以造成機毀人亡。

為規范軟件研發過程，提高軟件產品的安全性，美國航空無線電技術委員會(RTCA)提出了DO－178B《機載系統和設備合格審定中的軟件考慮》，它用于建立開發人員、安裝人員和用戶在使用計算機技術設計航空系統及設備時遵從的軟件要求［2］。該標準并成為美國聯邦航空管理局(FAA)和歐洲聯合航空管理局(JAA)進行機載軟件開發的標準。DO－178B采納了由JAA所使用的五級失效狀的分類模式將機載軟件安全級別劃分為災難性、危險性、較重要、次要級和無影響級5個類型，并由此確立了對安全性方面的具體細則［2］。DO－178B制定了軟件生命周期各個過程的目標;闡述了達到目標所應進行的活動。

軟件配置管理技術主要解決的是軟件開發過程中的資源管理問題［4］。它作為軟件過程管理中的一項重要內容，在DO－178B中具有明確的目標與要求。本文作者在進行充分研究之后，對滿足DO－178B研發過程的軟件配置管理技術進行了探討，并從實踐出發，為如何開展滿足DO－178B的軟件配置管理活動提出了很好的建議。

2 配置管理組成

在滿足DO－178B的軟件研發過程中，軟件配置管理過程應該涉及的活動如圖1所示。其中，建立組織機構與配置庫設置為其它活動的基礎。

圖1 軟件配置管理活動組成

3 配置管理實施

3.1 組織機構

軟件配置管理活動需要全體項目成員的參與。CCB(配置控制委員會)作為一個集中控制機構，它建立的目的是為了保證每個基線變更都經過項目相關成員的考慮與確認，每個變更在實施前都經過授權［5］。CCB一般由項目負責人、開發組、測試組、質量保證組、配置管理組等項目相關成員組成。

CCB應至少設置兩級:系統級與項目級。系統級CCB成員中應增加硬件開發方等系統級相關人員。系統級CCB負責:需求基線、產品基線的審批以及這兩類基線數據的變更;產品發布的審批。項目級CCB則負責其他基線的審批以及基線數據的更改。項目級CCB也可根據軟件模塊的分包情況再次細分。

多層次的CCB可以提高項目組內部解決問題的效率;而且對于涉及項目組外部的一切問題又保證了溝通的有效性及問題分析與解決的權威性。

3.2 配置庫設置

配置庫的設置一般有兩種形式:按產品模塊的劃分建庫和按產品建庫。按產品模塊的劃分建庫適合于工具統一、對并行開發有一定需求的大規模軟件研發。這種配置庫的建立模式能提高配置項的編譯和發布效率。但這種庫結構并不是面對整個軟件產品，因此，在維護各模塊版本的一致性方面成本較高。按產品建庫適用于開發模式為線性的中小型專業軟件的研發，維護方便，但不利于提高配置項的編譯效率。配置庫的設置應根據項目情況結合所使用的工具進行靈活選擇、合理規劃。

無論采用哪種方式進行配置庫設置，都需要對不同穩定程度的數據版本進行區別控制，以防止重要版本的丟失或肆意篡改。因此，“開發庫+受控庫+產品庫”的三庫管理機制應運而生。區別于以往物理分開的三庫管理，建議使用物理上的一庫實現邏輯上的三庫管理。三庫物理統一，通過基線的創建來實現邏輯的分割。開發庫負責收集所有軟件研發過程中的電子數據，受控庫保存基線數據。產品庫保存所有產品基線。配置管理員設置配置庫中的讀、寫權限，以維護數據的安全性與穩定性。物理一庫的優勢:避免由于物理上的隔離導致數據在三庫間(主要是開發庫與受控庫)的頻繁出入，減少了工作負荷，防止數據在傳遞過程中出錯;再者，避免了為建立三庫間數據的對應關系而付出的不必要成本。

3.3 配置標識及版本

配置標識主要包括:文檔標識、源代碼標識、產品標識。

文檔標識存在于文檔的封頁，通常采用的標識規則為:“項目簡稱_文檔名稱_版本號”，版本號可以表示為X.Y。X和Y均為整數，它們的變化反映出變更程度的大小。

源代碼是通過其電子文件的名稱進行標識的。如果不同路徑下存在有相同名稱的代碼，則可以通過“路徑名+文件名”的方式對源代碼進行標識。代碼的版本號規則可以與技術文檔的相同。

產品可以通過以下標識規則進行標識:“產品名稱/產品版本號”。產品的版本號由三部分組成，即主版本號+特征版本號+修復版本號［3］。主版本號代表產品的第幾代;特征版本號代表新功能的增加;而修復版本號的提升代表產品發布后對BUG的修復。

3.4 基線管理

傳統的基線管理策略大都是基于瀑布式開發模型的基礎上提出的:每個軟件研發階段結束即創建該階段的基線。可這對于大規模復雜軟件所采用的多模塊并行開發的方式并不適用?；诖耍瑢Χ嗄K并行開發模式的研發過程，軟件生命周期所產生的數據應采用兩級基線管理策略:

第一級基線(模塊級基線):各功能模塊在其軟件生命周期的每個階段結束時，產生該模塊的相應階段基線。

第二級基線(軟件級基線):整個軟件在其軟件生命周期的每個階段結束時，產生整個軟件的相應階段基線。

第二級基線由與其所處階段一致的所有模塊的第一級基線共同構成。一旦任意一個第一級基線的新版本形成，其構成的第二級基線也將自然形成新的基線版本。兩級基線的管理策略有利于并行開發中各模塊的狀態管理:通過基線信息的描述，不但能清楚地記錄整個軟件各種基線及同類基線中不同版本的差別，更能對模塊內各階段的狀態變遷進行詳細的記錄。依照兩級基線策略的思想，表1列舉了滿足DO－178B的軟件研發過程中軟件生命周期的基線列表。

軟件生命周期中的每條基線都應進行唯一的標識，并且基線的建立應該首先由項目負責人提交基線發布申請，經過相應級別的CCB批準后，由配置管理人員建立。

表1 軟件生命周期基線列表

3.5 變更控制

滿足DO－178B要求的軟件研發過程中，所有基線化數據的變更都應在有效的控制下進行。項目成員可以在進行任何活動的過程中將所發現的問題在變更管理系統中以問題報告(PR)的形式進行記錄。這包括開發過程，驗證過程，又或者是用戶使用過程。問題報告中需要記錄問題發現人、問題重現步驟。問題在經過分析、解決、驗證后，還應在報告中記錄問題影響域以及解決方案。介于需求基線與產品基線的重要性，有關這兩條基線的數據變更，進行PR分配及評審的必須是系統級CCB，而其它基線數據的變更評審則由項目級CCB執行。圖2顯示了滿足DO－178B變更要求的變更控制工作流程。

圖2 變更控制流程圖

從圖2中可以看出，滿足DO－178B的軟件變更流程較之一般軟件的變更更為嚴格:所有變更活動均被詳細記錄、每個問題都會被詳細評估和解決。對于評估與變更的實施也都需要經過獨立性驗證，項目成員可以對每個PR的任一環節進行回溯與跟蹤。

3.6 軟件發布

軟件發布的目的是為了保證所使用的軟件產品的有效性，以證明該產品是經過權威認可、授權使用的軟件。軟件發布應建立詳細的發布規程。規程中應規定發布時機、發布申請人、批準機構、申請及審批流程。

3.7 軟件歸檔、恢復

軟件歸檔與恢復是為了保證與軟件產品相關的生命周期數據在發生例如產品復制、重新生成、復測以及修改的需求時能夠被及時恢復［1］。因此，軟件的歸檔與恢復應建立相應規程。規程中應對數據歸檔及恢復的執行人、歸檔時機、歸檔媒介、媒介標識規則、歸檔及恢復的執行流程等內容進行約束。對于軟件的歸檔與恢復還應該配套對應的審查機制(一般由質量保證人員執行)，以保證工作能準確有效的開展。

備份作為歸檔工作的一部分，能防止數據的丟失而帶來工作上的損失。備份周期不宜過長，最好做到當天的增量備份以及以星期或月為單位的全量備份。備份媒介在使用時應注意完好性及可用性檢查。備份媒介應一式兩份，分別存放在物理距離相距較遠的地方，進行防火防盜處理。

3.8 加載控制

軟件加載控制的目的是為了保證加載到系統的軟件是正確、完整的，且可以被完全加載的［1］。因此，開發者有必要對以下信息進行規范并詳細記錄:軟件的加載格式、協議、加載工具、加載流程以及軟件的完整性檢查(包括加載媒介的標識)。通常，這些信息會作為交付文檔中的重要組成部分交付給用戶。

3.9 配置狀態報告

配置狀態報告作為配置管理活動中一個重要的環節，可以幫助項目成員了解基線配置項的狀態、變更對項目進展的影響等情況。從而為開發決策提供參考依據。配置狀態報告應包括的內容有:基線建立的信息，基線數據的變更及變更狀態，軟件產品的發行狀況，對配置庫的重要操作以及因為過程改進所導致的一些既定的配置管理活動的變化。

軟件配置索引從某種程度上可以看作軟件生命周期里所有配置狀態報告的一個子集。它描述的是軟件產品形成后，組成該產品的相關配置數據的信息。

3.10 軟件生命周期環境控制

配置管理活動中，人們往往忽略一項重要的活動，那就是對用來開發、構建、驗證以及加載軟件的工具的配置控制，也稱為軟件生命周期環境的控制。DO－178B中對此有明確的要求［1］:即用來產生軟件產品的工具必須進行標識、控制，以保證其可恢復性。項目組內，應創建專門的工具庫，存放項目中使用到的所有工具及工具的不同版本。同時創建工具基線，基線中不僅包括工具軟件，對于需要進行質量鑒定的工具還需包括對應的鑒定數據。

4 軟件數據控制類別

在DO－178B中，軟件生命周期數據可以劃分為兩種類型［1］:控制類別1(CC1)和控制類別2(CC2)。兩種控制類別的數據在不同級別軟件的配置管理活動中具有不同的要求與目標。

以DO－178B A級軟件的研發過程為例，軟件的五個計劃(開發計劃、驗證計劃、配置管理計劃、質量保證計劃、合格審定計劃)、三個標準(需求標準、設計標準、編碼標準)、需求、設計、源代碼、可執行目標碼以及開發工具的工具鑒定數據屬于CC1;而軟件驗證結果、軟件驗證用例與程序、軟件配置管理記錄、質量保證記錄、問題報告以及驗證工具的質量鑒定數據屬于CC2。DO－178B中對于CC1、CC2的具體配置管理目標詳見標準的7.3節。

5 與DO－178B的符合性對照

表2提供了上述內容與DO－178B關于軟件配置管理各項活動的符合性說明。

表2 與DO－178B的符合性對照

［1］美國航空無線電技術委員會.RTCA DO－178B—機載系統和設備合格審定中的軟件考慮［S］.美國:航空無線電技術委員會，1992:45－50.

［2］陳紹宇，趙建軍.RTCA DO－178B標準與相關國軍標的對照分析［J］.航空電子技術，2009，40(1):48 －52.

［3］董勇.未雨綢繆理解軟件配置管理［M］.北京:電子工業出版社，2008.

［4］張海波.軟件配置管理及其過程實現［J］.艦船電子工程，2004，24(5):64 －68.

［5］瓦茨S漢弗萊.軟件過程管理［M］.北京:清華大學出版社，2002.

6 結束語

RTCA DO－178B作為民用航空領域軟件研發的標準，它的出現為提高航空軟件的安全性及可靠性提供了保障。上述內容探討了滿足DO－178B軟件研發過程要求的配置管理技術，詳細闡述了開展各項軟件配置管理活動的具體方法與策略，并提供了與DO－178B中相關要求的符合性說明，所有這些希望能為軟件行業的配置管理人員提供一定的借鑒和參考。