基于GJB5000B的航空發動機健康管理軟件配置管理方法研究

王旗林

（中國航發湖南動力機械研究所，湖南株洲 412002）

0.引言

健康管理軟件是航空發動機健康管理系統的重要組成部分，軟件產品的質量直接關系到發動機狀態監視和故障診斷結果的準確性，進一步影響發動機的外場維護策略和飛行安全[1]。而隨著軟件功能需求的不斷增加，軟件架構越發復雜，開發難度越來越大，如何通過工程化方法有效地管理和規范軟件開發過程，避免開發活動混亂，保證軟件工作產品全生存周期的完整性、一致性和可追溯性，是目前各航空發動機科研院所健康管理軟件研制任務中面臨的實際問題。

配置管理是在軟件全生存周期內，通過技術及行政手段對軟件產品及其開發過程進行控制、規范的一系列措施和過程[2]。GJB5000B軍用軟件能力成熟度模型[3]給出了配置管理實踐域需要達到的目標和實踐要求，但沒有給出具體的執行方法。本文針對航空發動機健康管理軟件特點及開發過程中暴露的問題，以GJB5000B軍用軟件能力成熟度模型中配置管理(Configuration Management,簡稱CM)實踐域的要求為理論指導，結合2022年中國航發動研所軟件研制能力成熟度二級資質取證的工作實踐，總結了航空發動機健康管理軟件配置管理的一套有效方法。

1.GJB 5000B配置管理要求

2003年，總裝備部根據SEI的CMM軟件能力成熟度模型標準，制定了GJB 5000軍用軟件能力成熟模型，2008年，又以CMMI for Development V1.2為主要參考藍本，對GJB 5000進行了修訂，發布了GJB 5000A軍用軟件研制能力成熟度模型[4]。GJB5000B自2018年啟動修訂，總結了國內各家軍工單位GJB5000A的實踐經驗，吸收國外CMMI2.0的先進思想，至2021年12月獲批發布。GJB5000A在航空、航天、兵器等軍工科研院所已得到廣泛推廣和應用，以提高軍工企業軟件研制能力，GJB5000B自2022年3月開始實施，至2024年2月為標準換版過渡期。按照中央軍委裝備發展部要求，2024年3月后，將全部貫徹實施GJB 5000B標準，并按此進行軍用軟件研制能力評價。

軍用軟件能力成熟度模型是軍用軟件全生存周期過程技術和管理最佳實踐的集合。這些實踐按照實踐域進行分類，指導組織實施精細化過程管理，不斷改進組織過程，提高質量和過程績效，提升顧客滿意度[3]。模型分為5個等級，分別為一級初始級、二級規范級、三級全面級、四級量化級和五級卓越級，逐級遞進。GJB5000B適用于軍用軟件論證、研制、試驗和維護能力的評價和過程改進。相比于其前身GJB5000A“軍用軟件研制能力成熟度模型”，GJB5000B“軍用軟件能力成熟度模型”將適用范圍從研制擴展到全生存周期，對成熟度等級、實踐域名稱及其內容等進行了本地化改進，更加通俗易懂。通過新增、合并、調整，將原來的22個過程域更新為21個實踐域，劃分為組織管理、項目管理、工程、支持4類實踐域。

配置管理屬于支持類實踐域，來源于GJB5000A中的配置管理過程域。配置管理的目的是通過配置標識、配置控制、配置狀態記實、配置審核，建立并維護工作產品的完整性和一致性，以具備向顧客提供正確版本工作產品的能力。配置管理實踐域共分1個等級（成熟度二級）和6個實踐，如表1所示。

表1 配置管理實踐域等級說明表

2.健康管理軟件研制存在的問題

航空發動機健康管理軟件是健康管理系統的核心部分，通常包括機載嵌入式軟件和地面應用分析軟件。機載軟件對發動機運行數據進行記錄、分析，實時監視發動機健康狀態，對影響飛行安全的故障或異常進行告警。地面應用分析軟件，下載機載存儲數據，結合發動機歷史數據和人工錄入維護數據，對發動機故障進行深入分析和預測，對發動機的性能衰減進行趨勢分析。

航空發動機健康管理系統為滿足飛行用戶、維護用戶、機群管理用戶、技術支持用戶等各方使用要求，軟件整體復雜度高，研制周期長，因需求變化而引起的變更頻繁。且健康管理軟件涉及發動機氣路、振動、滑油、壽命、運維等多專業、多學科人員間的協調合作。人員能力水平，專業技術成熟度參差不齊，難免產生某些缺陷和錯誤，導致軟件開發過程混亂，代碼版本修改頻繁，文檔內容錯漏、軟件維護困難等一系列問題，無法保證軟件工作產品全生存周期的可追溯性、正確性、完整性和一致性[5]，給軟件開發活動和項目管理過程帶來一定的困難，進而影響軟件產品的質量和開發進度。目前，各軍用航空發動機型號均要求裝備健康管理系統，且通過軟件來實現的功能越來越多，對軟件質量和可靠性的要求不斷提高，為避免軟件研制過程混亂，提高軟件產品的可維護性，實現有效的軟件技術狀態全生存周期管理，必須引入工程化的軟件配置管理方法。

3.基于GJB 5000B的配置管理方法研究

依據GJB5000B配置管理實踐域要求，除設置項目配置管理人員和組織及配置管理人員外，組織應成立配置控制委員會（CCB），對配置及其管理具有決策權限和職責。配置控制委員會一般由來自不同領域的項目利益相關方的代表組成，而且有能力在管理上作出承諾，對提出的配置項的變更進行評價、批準或否決[6]。

3.1 建立和維護軟件配置庫

項目建立軟件配置庫（開發庫、受控庫、產品庫），用來對軟件配置項進行入庫、訪問、出庫、維護、更改、發布、備份等活動實施管理，以確保軟件產品的正確性、完整性、可控性和可追溯性。

在軟件項目立項后，軟件負責人組織項目軟件組人員建立軟件開發庫，內容包括項目軟件開發過程中產生的工作產品和軟件過程管理數據，包括過程記錄表單、出入庫單等。項目配置管理人員按照項目標準規范要求建立軟件受控庫，用于存放項目軟件開發過程中產生的不同控制等級的配置項及基線，并為項目軟件組成員分配合適的受控庫權限，將權限生成結果告知項目軟件組成員及項目質量保證人員。組織級配置管理人員建立軟件產品庫并設置產品庫權限。產品庫用于存放在完成系統測試后作為最終交付物或等待用戶現場安裝運行的軟件產品。在項目的實際運行中，配置管理人員可根據需要修改配置庫目錄結構和人員權限，以及對受控庫進行備份。

3.2 制訂和維護《軟件配置管理計劃》

項目配置管理人員與軟件負責人根據《軟件開發計劃》及項目應遵循的標準、規范、約定要求編制《軟件配置管理計劃》，確定將置于配置管理之下的配置項（包括各類文檔、源代碼、執行程序以及各類數據等），明確配置項納入配置管理的時機和配置庫的人員訪問權限，并根據產品開發和交付的要求定義將建立的基線（包括功能基線、分配基線和產品基線）及其包含的配置項和基線建立時機。項目配置管理人員為每個配置項和基線分配唯一標識，根據軍用航空發動機健康管理軟件研制任務特點，結合GJB5000B中軟件配置項分級管理和分級受控要求，配置項（或基線）標識按圖1格式進行定義，包含軟件代號、研制階段、配置項（基線）簡號，版本標識等重要特征。通過組織評審后的《軟件配置管理計劃》納入受控庫進行管理。

圖1 標識定義格式

3.3 配置項出入庫及變更控制

配置項出入庫及變更控制是配置管理活動中的重要內容，需要配置管理人員、軟件開發人員及測試人員共同協作。

（1）配置項入庫。入庫申請人填寫并提交“入庫申請單”，提出配置項入庫申請。若配置項入受控庫，由項目配置管理人員執行物理配置審核，執行配置項入受控庫操作；若配置項入產品庫，由組織級配置管理人員執行物理配置審核，執行配置項入產品庫操作。對要進入軟件產品庫的配置項，需軟件驗收通過后才能將配置項入庫。軟件開發庫由項目軟件開發人員在軟件研制過程中內部控制維護。

（2）配置項出庫。出庫申請人填寫并提交“出庫申請單”，提出配置項出庫申請，經配置控制委員會批準后，由項目軟件配置管理人員執行配置項出受控庫操作。軟件開發階段，軟件產品庫只進行配置項入庫操作，不進行配置項出庫。

（3）配置項變更。項目軟件組成員根據發現的問題情況填寫“問題報告單”內容，明確需要變更的配置項、變更原因、影響范圍分析及修改建議。軟件負責人組織相關人員進行變更影響分析，主要包括管理影響分析和技術影響分析。管理影響分析主要分析變更所需的各種資源，包括人力、時間、設備等物質條件，同時還要分析變更對項目進度、內外承諾的影響，以及可能引入的風險；技術影響分析主要對軟件變更前后的功能、性能、狀態進行比較。由軟件負責人指定的修復人填寫“出庫申請單”，對出庫配置項進行修改，指定驗證人進行驗證或確認，確保配置項的功能和性能滿足要求，且變更未造成意外影響。驗證方法有單人復審、會議評審、回歸測試等方式。完成驗證后，變更申請人發起配置項入庫申請流程。軟件負責人跟蹤變更活動流程直至關閉。

3.4 建立和發布基線

軟件項目基線是在軟件項目生存周期中一個特定時刻正式指定的配置信息，至少包括功能基線、分配基線和產品基線。基線往往是軟件開發階段的各個里程碑[2]，每個基線都是下一步工作的基礎，并且只有通過更改控制過程才能進行修改。軟件產品基線所包括的配置項與軟件研制任務書中要求交付給用戶的交付物保持一致，產品基線下所有配置項均應納入產品庫。建立產品基線時，軟件測試人員應對納入產品庫的配置項進行功能配置審核。在用戶無額外交付物要求的情況下，各基線包含的最小集如表2所示。

表2 基線包含的最小集

項目建立的基線種類及基線構成的配置項，建立時機在軟件配置管理計劃中明確[7]。按照計劃節點要求，當某條基線的所有配置項已納入配置管理后，軟件負責人填寫“基線建立和發布申請單”，申請建立功能基線、分配基線或產品基線。經配置控制委員會審批通過后，項目配置管理人員負責創建功能基線、分配基線或產品基線并告知軟件負責人，項目軟件組成員、項目質量保證人員基線在庫中存放的位置及訪問權限。

3.5 配置審核

依據《軟件配置管理計劃》，對納入配置管理的工作產品進行審核，以保持配置項、基線、變更內容的完整性、一致性和正確性，驗證配置項是否符合規定的標準或需求。

（1）物理配置審核。項目配置管理人員在配置項入受控庫時，執行物理配置審核，組織級配置管理人員在配置項入產品庫時，執行物理配置項審核。物理配置審核包括配置項標識、基線的完整性和正確性，審核結果在“物理配置檢查單”中記錄。

（2）功能配置審核。在建立產品基線時，有軟件測試人員進行功能配置審核，功能配置審核的目的是驗證配置項的所有功能特性是否已達到其功能基線文件中所規定的需要，軟件文檔是否齊全且內容格式符合項目標準規范（如GJB 438B等）要求。審核結果在“功能配置檢查單”中記錄。對于審核發現的問題，由軟件負責人負責跟蹤解決。

3.6 配置狀態記錄和總結

項目配置管理員在配置項進入受控庫時開始記錄配置項出、入庫以及更改狀態，基線建立、標識、版本變更信息并填寫《軟件配置項狀態記錄表》，完成后存入開發庫。所級配置管理人員在配置項進入產品庫時開始記錄配置項入庫以及更改狀態，基線建立、標識、版本變更信息并填寫《軟件配置項狀態記錄表》，完成后存入開發庫。項目配置管理人員在階段會議或里程碑會議前根據《軟件配置項狀態記錄表》編寫《軟件配置狀態報告》，并發送給軟件負責人、項目軟件組成員、項目質量保證人員，以便查看配置項最新狀態。

在項目軟件驗收前，項目配置管理員根據配置管理過程中的各項記錄總結項目軟件配置管理工作，編寫《軟件配置管理報告》，納入配置管理。

4.結論

本文總結的航空發動機健康管理軟件配置管理方法，能夠規范軟件項目的開發過程，提高軟件開發團隊工作效率，降低軟件開發成本，對組織提高軟件研制能力和過程管理水平具有重要意義，該方法滿足GJB5000B標準的要求，為其他軍工軟件的研制工作提供技術參考。