基于流程控制及過程改進的軟件技術狀態管理方法

劉萍等/空間物理重點實驗室

軟件技術狀態管理是確保軟件質量的重要手段之一，隨著型號軟件研制工作的不斷推進，在軟件研制任務龐雜、研制成本高、技術狀態變更頻繁的環境下，軟件研制面臨如下問題：一是型號配套軟件種類繁雜，軟件總體無法及時掌握各配套軟件當前的技術狀態，在系統試驗階段很難實現各軟件技術狀態的統一；二是型號系統試驗類型繁多，鑒于各自研軟件特點，軟件及配套技術文檔的受控時機未形成統一規范，導致某些軟件在試驗前不能及時受控，參加試驗的軟件技術狀態受控級別不一，管理混亂；三是非新研軟件在沿用或適應性更改時，可選擇的沿用軟件沒有進行合理管理，由于缺乏流程控制，導致沿用軟件時選擇了存在問題的不成熟軟件，致使后期返工工作量超出可承受范圍，嚴重影響型號研制進度。產品構件的沿用記錄不完整，當構件升級時，無法及時通知到沿用的軟件項目，使用的構件不是最新狀態，后期可能引發不可估量的問題；四是軟件研制過程中，經常發生多次不同類別的技術狀態更改，由于更改過程不規范，更改影響分析這一更改過程最重要的環節容易被忽視，導致更改影響分析不到位，系統試驗過程中頻頻出錯。

針對目前存在的問題，航天某總體單位成立了軟件過程改進小組，依托組織資產庫和過程改進模型開展了多輪流程現狀調研，對現有軟件技術狀態管理方法進行了改進，不僅規范了研制過程，而且提高了設計師隊伍的工作效率。

一、總體思路

流程控制是指計算機指令運行或求值的順序，引申到過程管理里，流程控制即過程的執行順序控制，是一種規范化構造端到端的卓越業務流程，是一種以持續提高組織業務績效為目的的系統化方法。軟件過程改進是指在軟件過程的實施中，為了更有效地達到優化軟件過程的目的所實施的改善或改變其軟件過程的系列活動。過程改進的實施是在認知現有軟件過程的基礎上，利用過程運作和監控中所獲得的反饋信息，發現軟件過程中存在的問題和缺陷，提出改進意見，進而實現對軟件過程的改進和完善。

本文結合GJB5000A體系建設工作，以軟件過程改進理論為指導，基于流程控制思想，構建了航天型號軟件系統數據包，從系統層面分別對各型號配套軟件進行技術狀態管理；建立以試驗線為導向的自研軟件技術狀態管理模型圖，融合各類試驗對軟件技術狀態的要求，使設計人員“一圖看懂”，及時把控軟件的各種狀態；運用組織資產庫對成熟軟件和產品化構件的技術狀態進行統一管理，固化產品沿用過程，使產品沿用時只能選擇資產庫中的成熟產品或構件；已受控文件的更改過程采用“線上+線下”結合的模式，強化線下更改影響分析，落實更改及驗證過程，以規范技術狀態更改過程。

二、軟件技術狀態管理方法與實踐

1.項目實施方案

（1）構建軟件系統數據包

型號軟件系統數據包是產品研制過程中各種相關記錄的集合，建立數據包的目的是對軟件系統下各種記錄進行技術狀態管理。數據包中的數據可以采取任何形式，包括可交付的數據和不可交付的數據。在型號軟件系統策劃階段，由部門型號負責人負責制定型號軟件系統數據管理計劃，作為后續型號數據技術狀態管理的依據。

型號初始階段，需在SVN中建立型號軟件系統數據包目錄，至少包括總體設計、型號管理、自研軟件管理和外協軟件管理4個部分。型號研制過程中，軟件系統產生的數據需及時納入數據包進行管理。

各型號數據包技術狀態管理過程中，可在重要研制節點建立型號級數據包管理基線，作為后續型號研制管理依據，具體可包括但不限于在方案階段結束時，將工程化大綱、軟件配套表、協議等軟件系統級文件納入基線管理，以此基線為依據開展后續工作。綜合試驗、匹配試驗、總裝試驗開始之前，分別建立試驗基線，作為試驗開展的依據。根據型號特點，在重要原理性驗證試驗、型號轉階段等節點建立相應系統級數據管理基線。每發次飛行試驗結束后，將軟件系統數據包進行歸檔管理，可在SVN開發庫中建立歸檔文件夾，或在配置管理工具中進行受控管理，作為組織資產積累。

通過構建型號軟件系統數據包對配套軟件進行統一管理，軟件總體單位可及時知悉各配套軟件當前狀態，并依此開展后續工作。

（2）以試驗線為導向的軟件技術狀態管理模型

以往對軟件技術狀態管理的要求是采取“一刀切”的模式，即軟件參加綜合試驗前必須受控，而并未對軟件的配套文檔何時受控作明確要求，導致代碼已多次出入受控庫，而作為軟件研制依據的技術文檔卻未受控的情況時常發生，軟件出現故障時，無法及時跟蹤到是研制過程的哪個環節出現的問題。

隨著本單位承擔的軟件研制任務越來越多，軟件研制類型（Ⅰ類、Ⅱ類、Ⅲ類、Ⅳ類，分別對應完全沿用、修改裝訂參數、適應性更改、新研）、軟件應用類別（嵌入式軟件、非嵌入式軟件等）和軟件安全關鍵等級（A級、B級、C級、D級）的不同，使軟件具有各自的特點，進而對軟件配套文檔和軟件開發方測試甚至對第三方測試的要求各不相同。針對各類型的軟件梳理了以試驗線為導向的軟件技術狀態管理模型（見圖1），以型號研制階段的各類試驗為主線，將軟件技術狀態管理要求融入各試驗環節中，實現“一圖看懂”，設計人員不用查閱相關標準要求，即可明確軟件何時應該處于何種狀態。

圖1 以試驗線為導向的軟件技術狀態管理模型

本單位自研軟件可劃分為新研軟件、非新研軟件兩大類。新研軟件未經過各種試驗驗證，參加第一輪綜合試驗時勢必會發現很多問題，為避免開發方回歸測試輪次太多造成測試效率低下、測試資源浪費，新研軟件入受控庫前按要求完成部分確認測試（見表1）即可，但初樣轉試樣前需完成全部開發方回歸測試。嵌入式新研軟件代碼入庫前要求任務書、需求規格說明、設計說明文檔通過評審（會議評審或文審）且已受控，或與代碼同時受控；非嵌入式軟件入庫前要求任務書、需求規格說明通過評審（會議評審或文審）且已受控，或與代碼同時受控。非新研軟件由于沿用了成熟的經試驗驗證的軟件，故必須完成開發方回歸測試才可入庫，對配套文檔的受控要求，與新研嵌入式、非嵌入式軟件的文檔要求相同。

表1 新研軟件首次入受控庫需滿足要求

為避免由于軟件頻繁改動導致第三方測試無法正常開展的情況，需開展第三方測試的軟件在初樣階段試驗全部完成后即可開展第三方測試，在軟件研制總結之前完成測試即可。

以試驗線為導向的軟件技術狀態管理模型在滿足型號試驗軟件需具備的狀態前提下，融合了開發方測試、第三方測試的要求，對不同類型的軟件“分而治之”，各類軟件對技術狀態管理要求進行了“本地化”。

（3）基于組織資產庫的成熟軟件和產品化構件沿用

一是組織資產庫的建立。

本單位在長期的型號磨礪中積累了非常豐富的軟件開發、管理經驗，這些經驗如果缺少有效的梳理與沉淀，在組織內部就很難實現系統化的經驗傳承。

本單位基于5000A理論自2018年開始策劃組織資產庫，基于知識標簽的專業知識萃取，完成涵蓋研制流程、最佳實踐的知識共享清單，并實現了初級共享，為組織資產庫建設奠定了堅實的基礎。后續，在完善組織資產架構的基礎上，明確組織資產管理標準，建立標準組織資產庫，同時立足組織資產價值的充分發揮，建立組織資產與科研流程雙向互動機制，推進組織資產庫建設與科研流程的雙向良性互動。

結合軟件研制流程，建立組織資產與軟件研制的良性互動機制，一方面，成功的軟件項目開發依賴于歷史數據和所借鑒的最佳實踐，依賴于具有豐富內容的組織過程資產庫的支持；另一方面，組織資產庫的建立、維護與項目開發運行是一個持續迭代的過程，需要在項目級管理、技術流程中不斷積累與挖掘，將個體知識轉化為組織資產，在海量知識庫中萃取有效信息，持續豐富組織過程資產，推進組織能力持續改進。

二是沿用經驗證的成熟軟件。

組織資產庫對經過試驗驗證的成熟軟件進行了統一化管理，非新研軟件可從組織資產庫中選擇成熟軟件，沿用或沿用后進行適應性更改，并將此沿用過程進行流程化設計，固化到技術狀態管理的支持平臺配置管理工具中，通過此方式來規范沿用過程。

以研制類型為Ⅲ類的軟件項目為例，設計人員填寫沿用申請單，從組織資產庫中選定即將沿用的某型號某軟件，根據項目需要，選擇某軟件某個版本的產品基線中的一個或若干個配置管理項，并進行初步軟件更改影響域分析。該沿用申請單經型號副總師批準后，設計人員線下完成軟件更改可行性及影響域分析報告，并組織專家對更改報告進行評審。評審通過后，填寫更改申請單，對沿用后需要更改的軟件逐一進行分析、更改，并驗證更改是否滿足要求。

軟件研制完成后，經飛行試驗驗證軟件不存在問題，則可在軟件過程改進小組同意后納入組織資產庫。在繼承成功項目經驗和數據的同時又為組織資產庫提供了新的組織資產，以便后續其它型號軟件的沿用參考。

三是產品化構件的沿用，實現型號線與產品線共贏。

隨著本單位產品化工作的開展，非嵌入式軟件復用產品和嵌入式軟件復用產品構件已初具規模。組織資產庫對可復用產品化構件進行了統一化管理。型號軟件研制時可申請產品構件的沿用，形成構件引用清單。基于現狀，型號線與產品線的選用依賴關系及良性互動愈發重要，當構件進行優化升級時，可及時通知引用構件的項目，經分析軟件項目需要更新當前構件時，可重新進行構件的沿用申請。當各型號根據任務要求或者自身問題對軟件進行更改時，需要將信息傳達至產品化隊伍，同步開展分析，確認該項更改是否同樣需要反映至產品線，以保證產品庫構件的不斷完善和優化。型號線與產品線的雙向互動既能在保證質量的前提下縮短軟件研制周期，又能提升產品構件的成熟度，從而實現共贏。

組織資產庫對成熟軟件和產品化構件進行技術狀態管理，需要申請并批準通過后才可沿用成熟軟件或使用產品化構件。此過程已完成電子化流程設計，并固化到配置管理工具中，實現了組織資產沿用的流程控制。基于產品化構件自身標準化、通用化、低成本、高質量的特點，產品化構件適合大批量軟件研制的復用，不僅保證質量、降低研發成本，還能大大縮短軟件的研制周期。

軟件研制全生命周期內可充分利用組織資產庫，以組織標準為依據，以組織經驗為支撐，同時要求項目組向組織級資產庫做貢獻，鼓勵基于數據積累的設計創新，在盤活組織資產的同時實現其價值最大化，并促進組織過程能力與項目開發水平雙效提升。

（4）“線上+線下”結合的更改過程管理

軟件研制過程中，在受控庫經常發生多次不同類別的技術狀態更改，均需要遵循更改流程開展工作。因此，為加強技術狀態更改環節的控制，受控文件的更改過程采用“線上+線下”結合的模式，強化線下更改影響分析。

受控庫中文件原更改流程為：問題報告、更改申請、更改出庫、更改入庫，均在配置管理平臺中完成。經過試運行效果較好，但表單多且審批流程繁瑣，嚴重影響了效率。經過程改進小組討論后，將原流程中的問題報告、更改申請、更改出庫3張表單進行合并，在一個流程步驟中完成，簡化了原有工作。但運行一段時間后發現更改影響分析普遍在線上開展，即結合更改申請單開展，由于缺乏線下正式評審環節，各型號中發現多次更改影響域分析不全面導致的技術問題，影響了軟件產品質量。

經軟件過程改進小組進一步調研和分析，對更改流程進行優化，將優化后的更改過程在配置管理工具中進行流程固化控制，強制采用“線上+線下”結合的更改過程（見圖2）進行管理，步驟如下：線下開展更改影響分析評審（必須記錄時間及參與人員）；線上提交更改申請（受控庫中填寫更改申請單并附更改影響分析報告，需提供線下開展更改影響分析評審的證據）；更改申請通過后，線下開展更改（代碼需測試驗證）；線上更改入庫（受控庫中填寫更動入庫單，代碼需上傳測試記錄）。

圖2 軟件更改流程

另外，本單位制定了《軟件產品更改影響分析規范》和《十字傳播路徑更改影響項目分析方法》，目的是確保更改項目分析全面、工作產品無漏項、技術分析到位。同時，強化對更改影響域分析過程的審核及把關，成立由各產品線技術負責人組成的專家組，在變更申請環節，線下開展更改影響域分析，并形成完整的更改影響域分析報告，在變更申請單中除描述更改項目外，需要上傳更改影響域分析報告作為附件。

軟件更改完成后，需要提交開發方及第三方開展回歸測試，測試通過后，重新入受控庫，再出庫用于系統試驗。目的是確保軟件更改在進入系統試驗之前得到充分的測試及驗證。更改入庫需附開發方回歸測試記錄，由開發方測試技術負責人制定軟件測試記錄采集表，包含測試用例設計及執行情況統計，臨時代替冗繁的測試報告，待軟件狀態穩定后完成最終測試報告。

2.實施效果

軟件技術狀態管理方法陸續在某型號軟件研制工作中得到實施應用，該型號指控系統在研制過程中按照固化的流程沿用了組織資產庫的成熟軟件和產品化構件，并依據以試驗線為導向的軟件技術狀態管理模型開展軟件技術狀態管理，在保證軟件質量的前提下極大地縮短了軟件研制周期，采用“線上+線下”結合的更改過程管理軟件技術狀態的變化，對軟件更改進行了全面的更改影響分析，軟件系統技術狀態管理取得了顯著成果，為飛行試驗圓滿成功奠定了基礎。

三、創新成果

1.構建了型號軟件系統數據包

對型號軟件系統下所有相關文件進行管理，包括系統層文件、外協軟件、自研軟件，使軟件系統總體單位及時掌握當前各配套軟件的技術狀態，并依此開展驗收、試驗等各類型號任務，進一步提升了軟件總體單位的抓總能力。

2.建立了以試驗線為導向的軟件技術狀態管理模型

建立了以試驗線為導向的軟件技術狀態管理模型，在滿足型號試驗軟件需具備的技術狀態前提下融合了開發方測試、第三方測試等要求，對不同類型的軟件“分而治之”，各類軟件將技術狀態管理要求進行“本地化”，不僅滿足標準要求，也大大地提升了軟件研制工作效率。

3.基于組織資產庫的成熟軟件和產品化構件沿用

組織資產庫對成熟軟件和產品化構件進行技術狀態管理，新項目在繼承成功項目的經驗和數據的同時為組織資產庫提供了新的組織資產，有效提升了組織過程能力，軟件質量也逐步從依賴員工個人經驗向依賴組織能力轉變，團隊業務能力和軟件產能得到有效提升。另外，將資產庫中產品化構件合理規范地復用到大批量軟件研制中，多型號試驗驗證優化又進一步提升了構件的成熟度。型號線與產品線的雙向互動，既能在保證質量的前提下縮短軟件研制周期，又能提升產品性能，從而實現了共贏。

4.采用“線上+線下”結合的更改過程管理

改變原來線上開展更改影響分析的模式，采用“線上+線下”結合的方式，強化了更改影響分析過程的審核及把關，確保了更改項目分析全面、工作產品無漏項、技術分析到位。在更改驗證環節，測試人員制定的軟件測試記錄表包含測試用例設計及執行情況統計等內容，代替冗繁的測試報告，提高了更改后的測試驗證工作效率。

在未來飛行器工業化大生產模式下，本文提出的軟件技術狀態管理方法，基于通用的型號軟件系統研發標準過程，充分考慮了某裝備軟件系統工程研發特點，為開發高產量、高質量、低成本、易維護的軟件奠定了堅實的基礎，在規范管理、提高團隊工作效率、縮短產品周期及軟件的安全性和可靠性等方面有了很大的提高。其通用化的管理模式及研發過程同樣適用于其它軟件研制單位。

軟件技術狀態管理方法在應用過程中取得了一些成效，但同時也面臨以下問題：一是有多個分支的軟件在同一個項目中進行管理且變更較多時，難以區分各分支狀態；二是已交付的外來配套軟件技術狀態發生變化時，更改過程在各配套單位開展，軟件總體單位無法把控更改過程。

后續，需要對技術狀態管理方法進行深入的探索與思考，針對多分支狀態軟件、外來配套軟件的特點分別制定合理的技術狀態管理措施，在軟件研制過程中，加強對軟件技術狀態的監督控制，實現質量管控。