城軌信號系統項目應用軟件版本管理探討

劉凱

摘 要：城軌信號系統功能復雜，涉及子系統繁多，涉及的項目應用軟件版本多而雜。本文討論城軌信號系統工程應用軟件版本管理的重要性、分析工程應用軟件版本管理工作內容，提出相關應對方法。

關鍵詞：城軌信號;項目應用軟件;版本管理

城軌信號系統實現列車運行的間隔控制、行車調度指揮、列車自動運行、設備監測及維護管理等，可保障列車運行安全、提高列車運輸效率、減輕運營人員勞動強度。城軌信號系統覆蓋運營場景多、實現功能多，系統構成復雜。

城軌信號系統需面對兩方面矛盾的需求：一方面，城軌線路復雜、運營場景多樣、運營規則定制化的現實，城軌信號系統需要按實際業務需求靈活調整;另一方面，信號系統直接指揮行車，系統任何變動都需謹慎小心，確保變動后依然可穩定安全運行。

為調和“應需求而變”和“為安全求穩”的矛盾需求，城軌信號系統按功能拆分為多個子系統，如ATS、ATP、CI、微機監測等。各相關子系統可獨立運行，分別實現各系統功能;各子系統功能通過接口聚合實現系統整體功能。信號系統可按大系統和子系統兩個層面進行版本管理，達到以下目標：

（1）縮小系統整體變更范圍，可更穩健進行變更分析和系統優化，保證“變”中求“穩”;

（2）子系統和系統可并行進行需求管理和功能優化，提高系統迭代開發效率，保證“穩”中促“變”。

在子系統層面，為減少子系統變更范圍和降低維護頻次，提高子系統穩定性，在各子系統產品應用到具體項目時，按功能通用化程度及與現場應用場景聯系密切程度，將各子系統進一步拆分為三部分：

（1）通用產品代碼，實現通用化功能，將產品定型;

（2）工程數據，實現特定應用場景密切相關功能;

（3）配置文件，實現多個通用化功能切換及相關定制化功能項。

子系統采用這種結構，可通過工程數據滿足各特殊站型條件或不同運營場景定制化需求，可降低通用部分變更范圍減少影響范圍，可通過配置文件銜接通用部分和特定場景、實現兩者的適配。按如此拆分，可同時兼顧通用產品代碼的較小迭代修改和通過工程數據及配置文件實現批量定制化應用需求。

按照系統與子系統、子系統與工程數據及配置這兩個邏輯層次的拆分，帶來兩個層次版本匹配要求。從總體而言，在滿足系統可變前提下降低變更帶來的安全風險，減少通用產品代碼變更版次，但系統與子系統、通用軟件、特定工程數據及配置文件的組合形成龐大版本規模，給項目應用軟件版本管理提出了很高的要求。

1 版本管理必要性分析

項目開展中，隨著從初步設計到詳細設計逐步深化，通用產品代碼、工程數據、配置文件并行開發升級，匹配構成子系統，從子系統層面逐步實現需求覆蓋和缺陷修復。三者需按子系統對其需求分配要求，同步匹配才可完整實現需求，任意版本不匹配，都無法實現子系統功能。

單一子系統升級同時，系統內其余子系統也在并行維護升級，實現子系統本身功能需求。各子系統功能按系統需求匹配更新時，系統才可完整發揮預期功能。

由此，設計階段要求系統子模塊并行匹配升級和各子系統匹配整體發布要求，帶來了2個層面的版本管理與2個層面需求版本匹配要求：

（1）單獨工程數據＼＼配置文件＼＼通用產品代碼維護時，需匹配子系統需求基準;

（2）三者整體升級時對于整體版本的匹配升級，需匹配大系統需求基準。

在詳細設計階段會進一步細化需求和引入變更，帶來項目大系統層需求版本和子系統層需求版本的變動，加大子系統之間和工程數據＼＼配置文件＼＼通用產品代碼兩個層面版本匹配的難度。為保障產品的順利交付，實現兩層面版本在每次變更時都能實現匹配，對需求版本、項目應用軟件版本和子系統軟件版本的有效管理成為必然。

2 版本管理工作內容

版本管理貫通于項目執行周期中各階段，分階段將前端需求分層次傳遞至后一階段：

（1）需求階段：與設計、建設方、運營方共同明確產品需求，產出相關技術規格書、手冊;需拆分、合并需求，對相關文件進行版本管理，跟蹤需求增減并對需求進行闡釋以方便后續環節追溯。（2）實現階段：根據需求階段產出，進行通用代碼、工程數據及配置文件開發，并給需求階段反饋細化修正要求，輸出相關工程設計文件;需進行需求＼＼缺陷跟蹤前提下的軟件＼＼數據＼＼配置版本管理、各產品間協議及接口文件版本管理，滿足子系統各部件級需求＼＼缺陷閉環管理要求。（3）子系統&系統確認階段：從子系統&系統角度，根據需求、實現階段產出，對子系統&系統進行確認，并給需求＼＼產品階段反饋細化修正要求，輸出相關過程記錄及報告;需進行需求匹配的確認及相關需求＼＼缺陷跟蹤，滿足子系統級&系統級需求＼＼缺陷閉環管理要求。

在各階段版本管理過程中，按兩種版本類型管理：

（1）初版版本管理：建立基準版本，建立后續版本需求及缺陷跟蹤的基礎。初版版本管理需完成如下工作：

①定義初版對應的需求范圍。在需求階段，明確系統總基線，并將系統基線拆分至各子系統產品直至拆分到代碼、數據及配置，并按系統、子系統、接口等層面獨立為相關規格書及需求手冊;同時，后期維護時需實時評估各階段變動范圍，當范圍過大帶來較大變更管理成本時，需重新設定初版。

②按不同層次由頂至下、由內到外次序，分級別逐步固化需求并發布;

③按版本管理顆粒度大小，設計版本號格式，按不同的等級分配不同版本位及不同版本標識，并確立版本變更規則。

（2）變更版本管理：根據初版建立的基線，隨著新需求及缺陷的引入進行迭代升級。變更版本管理需完成如下工作：

①不同階段不同層級需求或缺陷變更帶來對前后階段或上下層級相關方變更的影響范圍完整性評估;

②各子系統變更同步變更檢查;

③外部用戶需求及時進入各階段版本跟蹤以及需求的及時發布。

3 版本管理問題

（1）子系統層面：

①通用軟件、工程數據、配置文件之間不兼容;

②子系統超前或滯后于子系統需求，變更范圍過大或過小;

③子系統變更范圍不準確，無法支撐對外部影響范圍分析。

（2）系統層面：

①系統需求整理不全面，遺漏;

②系統對子系統功能分配不全面;

③子系統版本不兼容。

4 版本管理推薦方法

按照不同版本管理成果物，可匹配不同方法：

技術文件成果物：

（1）采用標準化文件模板，將系統、產品相關需求各維度以章節固化，防止需求描述遺漏;

（2）組建變更控制委員會，對重大變更進行評估，確認是否啟動初版版本管理;

（3）采用自動化需求、缺陷跟蹤工具，對需求進行跟蹤和指派，保障需求和缺陷按期兌現;

（4）將需求＼＼缺陷按階段設定配置發布計劃，分層次對接發布節點;

（5）設置在線審批＼＼版本管控系統，建立相關版本基線，通過系統檢查相關文件成套基線發布與變更。

代碼＼＼數據＼＼配置成果物：

（1）采用靜態檢查＼＼走查方式保障需求和缺陷覆蓋;

（2）采用動態測試驗證方式保障需求和缺陷覆蓋;

（3）建立需求＼＼缺陷評審會議制度，版本升級前進行相關變更影響分析，管控各版次變更范圍;

（4）建立自動配置管理系統，并按階段分配開發庫、測試庫、受控庫，實現軟件＼＼數據＼＼配置各階段版本記錄及信息傳遞;

（5）建立變更履歷，記錄各版次實現情況，追溯需求和缺陷。

5 小結

版本管理不是單一文件、軟件的版本記錄，而是對需求版本和軟件實現版本的持續匹配檢查與進度跟蹤。是否能夠做好項目應用軟件版本管理，核心在于：能否合理整理和分配需求、能否合理設計架構以減少整體變更頻次、能否完整評估需求實現情況。在不同信號系統體系架構下，面對不同應用場景需求，需結合實際選擇恰當合適的版本管理方法。

總之，信號系統項目應用軟件版本管控方式需系統全面進行梳理，按需選擇合適措施才可達到有效版本管理。

參考文獻：

[1]馬永恒，滿化錄.北京市軌道交通亦莊線信號系統結構設計[J].市政技術，2010（S2）.

[2]郜春海.基于通信的軌道交通列車運行控制系統[J].現代城市軌道交通，2007（02）.

[3]張德明.CBTC制式下的ATS子系統研究[J].鐵道通信信號，2009（12）：1-4.

[4]張金山，張鴻，劉沅斌，郭金京，趙娜.軟件測試階段的版本管理研究[J].計算機光盤軟件與應用，2014（14）.

[5]秦友淑，尹永勝，曹化工.工程配置的版本管理[J].計算機與數學工程，1998（06）.

[6]周鵬，曹化工.項目管理中版本管理的探討[J].湖北汽車工業學院學報，2002，16（3）：19-25.

[7]梁禮方.版本管理[J].金融科技時代，2014，2：45-50.