配置管理在AFC系统中的应用与实践

栗兰林

摘 要： 地铁是城市公共交通的重要组成部分，其设备的安全、稳定、可靠直接影响地铁运营的安全、稳定，因此保障设备的可靠运行是整个安全生产工作的首要环节，为保障AFC系统的正常运营，保证产品版本的正确性，保证变更后的正确性，在AFC系统的使用维护中引入配置管理机制，实施配置管理活动是对工作成果的一种有效保护形势，是形成组织资料和数据的重要来源。

关键词： 地铁；AFC系统；配置管理；变更控制过程；发布控制过程

引言

地铁是城市公共交通的重要组成部分，其车站AFC设备的运行情况将直接影响地铁服务水平，随着地铁运营线路和运营里程的增加，客流逐渐增长，保障AFC系统的正常运营，保证产品版本的正确性，保证软件变更后的正确性，实践证明解决这些问题的有效手段就是AFC系统中引入软件配置管理活動。

配置管理活动的目的是通过执行版本控制、变更控制、软件测试等规程，借助配置管理工具的使用，来保证软件产品的完整性、一致性、可用性。配置管理是对工作成果的一种有效保护形势，是形成组织资料和数据的重要来源。本文根据配置管理活动在AFC系统中的实践中经验，给出一种软件配置管理模型的具体实施方案。

一、概述

1配置管理简介

配置管理（Configuration Management，简称CM）是通过技术或行政手段对产品及其研发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录产品的演化过程，确保产品设计者在产品生命周期中各个阶段都能得到精确的产品配置。

2配置管理在AFC系统中的地位和作用

地铁公司承担着保障AFC系统的正常运营的职责。随着新线路的不断开通，新设备的添入，不断提供多样性的业务模式和提升乘客体验的满意度，AFC系统在提供全业务需求基础上不断提升和修正自身存在的缺陷，怎样才能管理好AFC系统每一个变更后的子系统能够正确无误在正线上运行？怎样保证所有站点的不同终端设备都在运行变更后同一版本的软件？怎么保证修改的软件部分不影响其他功能的正常运行？

通常，保持软件产品的完整性、一致性、可用性，是交给软件开发商在开发过程中来保障的。然而，软件开发商和我们做运营管理的根本上，目标不同，所以对待的做法和态度也就会有差异。软件开发商的维护人员的目标是，执行合同中质保期内的对软件的改进和完善，以尽快完成修改任务为目的；而作为AFC系统的使用方和管理方，目标是保障正常运营的前提下，做有效变更。在双方的目标和责任不一样的情况下，会存在终端设备运行的软件版本不一致，导致提供的功能不一致；为修改一个小问题，因为软件开发人员没有运营环境做回归测试，即修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。装入正线系统后，导致问题层出不穷。

实践证明解决这些问题的有效手段就是软件的使用人员在AFC系统中开展配置管理活动。通过执行版本控制、变更控制、软件测试等规程，借助配置管理工具的使用，用于实现贯穿产品生命周期的产品配置过程管理。

二、配置管理在AFC系统中的应用实践

1AFC系统简介

AFC（Automatic Fare Collection .AFC）系统是城市轨道交通自动售检票系统的简称，是融合计算机软件技术、大型数据库技术、机电一体化技术、模式识别技术、传感技术、紧密机械技术、网络技术等多项高新技术于一体的自动化大型系统。AFC系统是轨道交通最基本、最重要的系统之一，实现轨道交通售票、检票、计费、收费、统计、清分、管理等票务运营全过程。随着城市轨道交通网络化发展，客流量的日趋增加，AFC系统安全运营的压力与日剧增，对系统运营的稳定性、可靠性以及故障响应及处理时间的要求也越来越高。

昆明轨道交通AFC系统主要由以下软件产品构成：车站终端设备（Station Level Equipment.SLE）软件包含有半自动售票机（Booking Office Machine.BOM）、自动售票机（Ticket Vending Machine.TVM）、自动检票机（Automatic Gate Machine.AGM）和车站计算机系统（Station Computer.SC）、线路中央计算机系统（Line Central Computer.LCC）、清分系统（AFC Clearing Center.ACC）、储值票管理系统、票卡发行管理系统、老年卡发行管理系统、员工卡发行管理系统等软件产品。尤其车站运营一线的SLE设备，将直接关系到广大乘客进出站、购票和更新车票的功能实现。特别是新功能相继出现以后，SLE设备的应用软件程序也随之频繁变更、升级，由于工期紧、涉及范围广、联调要求高等实际因素的限制，导致软件质量难以得到保障。因此，加强对AFC系统软件管理尤为重要，将原本的事后分析评价转向为事前的管理控制，无论对整个项目工程还是对软件质量本身而言都是十分重要和必要的。

2基于AFC系统的配置管理平台系统开发及应用

2.1AFC系统配置管理模型

配置管理平台由配置库和配置管理系统功能组成，配置管理平台配置库由“环境库”、“源代码库”、“产品库”构成。用于存放系统开发、测试、维护的数据环境，如操作系统、编译环境、编译器、数据库管理系统、开发工具、测试工具等。AFC系统维护环境用于运行各AFC系统软件。集成商开发完成后，软件源代码需在该维护环境中通过编译生成最终目标程序，生成最终目标程序的源代码进入配置库的“源代码库”用于将来源代码查询和使用。最终目标程序进入配置库的“产品库”，作为正式发布的软件，正线的所有应用软件部署需从“产品库”中签出，保障在正线部署的软件出自配置管理的“产品库”，而不是软件集成商未经控制管理自行编译部署的软件。

环境库内容

环境库存放AFC系统测试维护平台中环境类配置项，标识软件开发环境及软件维护环境、编译环境、操作系统、编译器、数据库管理系统、开发工具、测试工具等。用途：搭建AFC系统中任何一个测试环境时，均可通过环境库捡出一套准确、完整的配置项完成测试环境的建立。

源代码库内容

源代码库存放编码类配置项，编码及单元测试后得到的工作产品，源代码、单元测试数据、系统测试数据、系统测试结果、操作手册等。

源代码的演变过程形成版本树，采用层次命名规则反映树状结构。

产品库内容

产品库保存所有可向正线发行的产品版本以及已经发布的产品版本、目标代码、文档。

2.2配置管理平台系统主要包括如下功能模块

2.2.1配置标识

配置标识就是识别产品的结构、产品的构件及其类型，为其分配唯一的标示符，也就是说，每一个配置項要有一个唯一标识。一般说来，标识包括两个方面：一是文件名，二是版本。

2.2.2版本控制

版本控制就是对在软件变更过程中所变动的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。当前，这方面典型的工具有VSS和CVS。

由版本依次连接形成版本树，每个结点代表一个版本，根节点是初始版本，叶结点代表最新的版本。版本控制对软件开发过程中配置项的发展过程提供有效的追踪手段，保证在需要时可以找到旧版本，避免文件的丢失、修改的丢失和互相覆盖。对版本的控制，实际上就是对配置项各种操作的控制，检入检出、版本的分支和合并、版本的历史纪录版本控制就是对在软件变更过程中所变动的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。

2.2.3配置状态统计

当有变更请求时，触发配置状态统计活动，提交配置状态报告。状态报告要能够报告所有变更的配置项以及变更请求的状态，通过量化的数据和报表反映软件系统的状态。状态报告要回答所谓4W的问题：What：发生了什么事？Who：谁做的此事？When：此事是什么时候发生的？Why：为什么做此事？

2.2.4配置审核

配置审核要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。

2.3配置管理平台系统的流程管理

配置管理平台系统包含3个主要流程，基础配置管理过程、变更控制过程和发布控制过程。

2.3.1变更控制过程

变更控制就是对变更请求进行分类、追踪和管理的过程来实现的。处理变更的原则，必须采用规范的管理过程。对于所有的变更，由变更的提出到开发、测试、实施、跟踪、发布的全过程都需遵循变更控制机制，保证所有变更都是可控的、可跟踪的、可重现的。

运营过程中新的需求、软件的增强、存在的缺陷均会引起变更发生，变更发生时，相关责任人提出“变更申请”，配置管理委员会对“变更申请”进行研究和批复，批准后的变更由配置管理员登记记录后，通知相关责任人。相关责任人组织委外软件厂家按需求进行软件开发，开发完成后，需将源代码部署到我们的测试维护平台进行软件编译和目标代码部署，通过测试后，出具“测试报告”，配置管理员登记记录测试报告，并进行源代码入库和目标代码入库操作。

“变更申请”需解决以下6个问题：

1）谁提出变更？

变更的起源有3种：新需求、功能变更和缺陷修补。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。变更提出人员会是系统的使用人员、维修人员、运营管理人员、软件系统开发商本身。

2）什么时候提出变更？

即变更提出的时间，新的需求被提出或时缺陷被发现后，技术人员对需求进行可行性研究、相关需求分析后，提出变更的时间。

3）变更的内容是什么？

变更内容包括为什么变更、变更发生的位置以及变更的具体描述；变更内容复杂时，开发者和用户在需求问题上常常产生分歧，变更的实施是用户和开发者相互协作的过程，必要时需编制需求变更方案，双方对变更需求了解越深入，所提的需求变更就越合理，越有针对性。

4）变更的影响是哪些？

变更会是用户界面变更、现有功能变更（增加、增强、删除、修改）、业务逻辑变更等。做变更影响分析，即从对进度的影响、对项目成本的影响、本变更对其他功能需求的影响、变更涉及到集成、测试、安装等方面进行分析；变更对范围、性能、架构、内外接口、信息安全等方面的影响分析。

（5）变更的处理意见？

变更处理方案，说明具体处理办法及相关理由。对变更请求的有效管理可以提高软件产品管理的透明度，可以清楚的知道进展情况，比如有多少个新产生的变更，已经解决了多少变更等，有利于做出正确的决策。

（6）变更执行结果？

为修改一个小问题，导致问题层出不穷，这是软件修改中常遇到的，变更处理效果，描述变更执行前后系统发生的变化。

2.3.2发布控制过程

软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。变更完成后，要按照计划统一发布软件的新版本，覆盖变更方案中涉及的所有范围，把源代码、可执行文件、文档、数据中所有应该包含到这个版本中的正确配置项检出，进行正线系统的安装部署。将操作手册等文档发布给各相关人员知晓和使用，特别是使用人员和维护人员。

发布控制过程有2个关键点需把控，一个关键点是“发布申请”的批准，批准的前提条件是结论为测试通过的测试报告、配置管理员出具的此次变更后的配置状态报告，即源代码和目标代码，相关文档已正确入库；另一个关键点是部署于正线的执行程序必须由配置管理员从“产品库”中检出的正确版本。

三、结论与建议

地铁基于AFC系统的配置管理平台系统，作为提升地铁AFC产品研发的管理水平的过程，对产品研发管理有至关重要的作用。配置管理平台系统能够解决产品项目研发团队中所面临的问题，不仅对版本进行了有效控制，能够查询任一时间段内对产品的变更情况，使每个涉及到的部门都能参与到产品的变更管理中，规范了产品研发过程中的成果把控。

参考文献

[1] 董越.未雨绸缪—理解软件配置管理.电子工业出版社，2008年5月.

[2] 徐晓春 李高建.软件配置管理. 清华大学出版. 2002-07-01.