城轨信号系统项目应用软件版本管理探讨

刘凯

摘 要：城轨信号系统功能复杂，涉及子系统繁多，涉及的项目应用软件版本多而杂。本文讨论城轨信号系统工程应用软件版本管理的重要性、分析工程应用软件版本管理工作内容，提出相关应对方法。

关键词：城轨信号;项目应用软件;版本管理

城轨信号系统实现列车运行的间隔控制、行车调度指挥、列车自动运行、设备监测及维护管理等，可保障列车运行安全、提高列车运输效率、减轻运营人员劳动强度。城轨信号系统覆盖运营场景多、实现功能多，系统构成复杂。

城轨信号系统需面对两方面矛盾的需求：一方面，城轨线路复杂、运营场景多样、运营规则定制化的现实，城轨信号系统需要按实际业务需求灵活调整;另一方面，信号系统直接指挥行车，系统任何变动都需谨慎小心，确保变动后依然可稳定安全运行。

为调和“应需求而变”和“为安全求稳”的矛盾需求，城轨信号系统按功能拆分为多个子系统，如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.