基于GJB5000A三級的軍用軟件技術狀態管理方法

史亭文 趙琳

摘要：航空軟件的技術狀態管理是保證軟件技術狀態正確性，提高軟件質量的有效技術保障。為了更好地管理軟件技術狀態，做好軟件工程化工作，該文基于GJB5000A三級標準，提出了一種適用航空軟件項目的軟件技術管理方法，該方法經項目實踐證明，有效提高了軟件技術狀態的正確性，保證了軟件質量。

關鍵詞：GJB5000A;技術狀態管理

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2019）24-0082-02

開放科學（資源服務）標識碼（OSID）：

1 引言

在航空軟件的整個研制過程中，為了確定和維護各個階段的軟件功能特性、性能特性和用戶要求的一致性，技術狀態管理活動必不可少。技術狀態管理主要內容包括技術狀態標識、技術狀態控制、技術狀態紀實和技術狀態審核四個過程[1]。隨著航空軟件重要性日趨增大，規模日益擴大及研制周期越來越復雜，其研制周期內的技術狀態管理工作顯得非常重要。

GJB5000A規定了軟件開發和維護活動中主要軟件管理過程和工程過程的實踐[2]。配置管理是GJB5000A三級體系中的一個支持類過程域，與質量保證過程一起保證軟件的技術狀態管理活動，配置管理過程通過建立基線、變更控制以及維護基線的完整性來對軟件的技術狀態進行管理，確保軟件的質量。

本文提出一套基于GJB5000A三級的軍用軟件技術狀態管理方案，詳細描述了技術狀態管理的各個活動。

2 航空軟件研制特點及存在問題

近年來，隨著航空事業的發展，航空軟件研制特點及問題日益顯著，主要體現在如下幾個方面：

1）研制階段時間長。航空軟件項目的研制階段包括需求獲取和策劃、軟件需求分析、軟件設計、軟件實現、軟件測試、軟件驗收與確認、軟件交付以及軟件維護。對于一個軟件配置項來說，時間越長，中間的產生的技術狀態就會越多，航空軟件有時候一個項目包括幾十個甚至幾百個配置項，這樣會導致產生的軟件技術狀態呈指數增加，控制其整個過程的技術狀態難度大大增大。

2）部門協作多。一個軟件項目，需要多個科室之間相互合作，這樣子容易導致溝通不充分，造成技術狀態混亂，不好管理。

3）需求變化多，其變更控制難度增加。在航空軟件的研制過程中，往往用戶需求前期不明確，屬于邊研制邊更改的過程，這樣會導致技術狀態經常發生變化，軟件項目技術狀態管理困難。

4）時間進度緊。航空的軟件研制都是有周期的，由于前期需求不明確，往往到軟件研制后期，會有頻繁的現場研制及調試工作，容易導致項目軟件的技術狀態不穩定。

綜上所述，急需一種實施合理且有效的技術狀態管理方案，來解讀上述問題，否則會引發軟件狀態多、版本管理混亂、變更控制不到位、文檔與源程序不符等問題，最終導致產品技術狀態失效。

3 基于GJB5000A三級的技術狀態管理方法

本文基于GJB5000A三級標準結合航空軟件開發特點，提出了一種技術狀態管理方案。從配置庫建立、階段審核控制、基線管理、變更控制幾個方面具體闡述了該方法的具體方法。

3.1 配置庫建立

軟件項目負責人在項目剛開始時，依據項目信息，申請建立配置管理庫，由所級配置管理人員負責創建，并根據項目情況設置相應人員權限。本方案采取開發庫、受控庫、產品庫物理隔離的策略進行管理。

在實施配置庫管理的時候，需要注意如下方面：

1）開發庫和受控庫的目錄盡量保持一致，因為受控庫中存放的內容是開發庫中項目達到指定狀態后，平移到受控庫中，這樣有助于項目CM入受控庫時審核。

2）項目成員向開發庫公共區域提交的工作產品應當可以供項目質量保證人員進行符合性檢查，且已完成評審缺陷的修改。

3）項目開展過程中產生的評審記錄、配置管理記錄、驗證及測試記錄、測量分析記錄等過程數據，應當及時入開發庫進行管理，待項目結項時，辦理受控庫入庫手續。

4）項目的工作產品完成相應的驗證工作后，及時辦理相應的受控庫入庫手續，文檔需經過評審且評審問題已歸零，源程序需通過項目規定的測試或產品用戶認可。

3.2 階段審核

在項目的生存期內，依據適用的標準、過程和規程，按照質量保證計劃審核項目的過程活動和工作產品，向項目組和相關領導提供審核結果，標識并文檔化不符合項，進行跟蹤，直至不符合項得到解決[2]。在該過程中，應當注意如下事項：

1） 項目質量保證人員應獨立于項目的開發和管理活動。

2） 項目質量保證人員對過程的審核可以采用評審或驗收的方式進行。

3） 對審核中發現的不符合項，應當及時記錄且文檔化，并進行跟蹤處理，直至不符合項關閉。

4） 項目質量保證人員在每月末或每周末、里程碑點處統計所發現過程和產品的不符合項總數及其關閉情況，總結質量保證活動，進行分析，通過郵件發送給項目相關人員。

3.3 基線管理

基線是正式通過復審和批準的某規約或產品，它可作為進一步開發的基礎，并且只能通過正式的變化控制過程改變[3]。基線建立的前提條件是基線配置項均已納入受控庫受控，且建立基線的審批手續已通過。軟件項目開發過程中可能形成的基線主要有：功能基線、分配基線、代碼基線和產品基線[2]。

航空軟件產品的生存周期一般分為方案階段（F）、初樣階段（C）、試驗階段（S）、定型階段（D）、批產階段（P）。該管理過程應注意如下幾個方面：

1）C階段轉S階段前，應已經形成功能基線和分配基線。在此基礎上，建立產品基線，通過轉段評審后，產品基線內容直接轉入產品庫并按照要求歸檔。

2）S階段轉D階段前，同樣應已經形成功能基線和分配基線，完成項目規定的軟件測試，才能建立產品基線，通過轉段評審后，產品基線內容直接轉入產品庫并按照要求歸檔。

3）定型前或者定型前轉入批產，應按照要求完定型測評，形成功能基線、分配基線和產品基線，通過轉段評審后產品基線內容轉入產品庫并按照歸檔要求歸檔。

4）代碼基線雖然只包含源程序和可執行程序，但是必須有與當前代碼基線版本一致的軟件任務書、需求、設計等文檔。

5）代碼基線主要是為了解決項目聯試時間緊張，未及時完成相應的回歸測試工作而建立的狀態，待狀態確定后，應及時完成對應的回歸測試工作，形成相應版本的產品基線，凍結狀態。

3.4 變更控制

實施軟件變更控制時需要注意如下問題：

1）變更的原因需明確，且在問題報告單中描述清楚;若是由于用戶需求變化導致軟件配置項變更，則需有用戶簽訂完成的技術協調單或協調紀要;或是由于軟件自測試或者三方測試問題修改發起的變更，則需在軟件問題單后附上測評機構提出的軟件問題報告，說明問題的來源、類別、級別和詳細內容;若由于外場聯試需發起變更，則需聯試版本的產品庫出庫手續完成后，才可辦理版更手續。

2）受控級別不同，審批級別不同。需要根據所變更配置項的級別，確定需審批的力度，審批人員應當重點關注變更的必要性、可行性及影響域，并權衡其他的變更策略和方法，變更所需的資源是否合理、充分，發起變更是否會對整個項目進度有影響[5]。

3）變更入庫時，確保待入庫版本正確;變更審批通過后，軟件項目負責人應確定待入庫的軟件版本是否正確，更改是否正確，確認版本無誤后，方可辦理入庫。

4）若重新建立基線，需詳細記錄;項目的配置管理員利用配置管理臺帳記錄軟件項目的變更、出入庫及建立基線情況，如果變更后需要重新建立基線，則需要項目配置管理員在臺賬上記錄清楚該基線修改的原因、內容及重新建立時間。重新建立基線后，應當及時通知項目成員知悉。

變更控制指的是在軟件生命周期中，被更改的配置管理項必須正式取自配置管理的受控庫、產品庫[4]。為了準確把控軟件技術狀態，需要規范軟件配置項的變更流程，變更控制的流程如圖1所示。

4 結束語

本文基于GJB5000A三級標準對技術狀態管理過程進行明細化，通過嚴格規范配置庫建立、階段審核控制、基線管理和變更控制過程等四個過程，確保軟件技術狀態正確、清晰;在航空軟件項目中，實施本文的軟件技術狀態管理方案后，軟件項目在管理力度和質量保證方面均有了明顯提高。

參考文獻：

[1] GJB3206A-2010. 技術狀態管理[S].北京：中國人民解放軍總裝備部， 2010： 1.

[2] 衛一芃.基于GJB5000A 三級的軟件配置管理技術研究[J].航空計算技術，2017，47（2）：101-104.

[3] 韓萬江.軟件項目管理案例教程[M].北京：機械工業出版社， 2012： 173.

[4] 周艷會，劉海，丁皓.軟件配置管理簡化實施方法[J].電子技術與軟件工程， 2016（6）： 51.

[5] 仇雯鈺，朱宏濤，楊羅蘭，等.基于GJB5000A的軟件技術狀態管理方法探討[J].遙測遙控，2018（2）：39.

【通聯編輯：代影】