某农村商业银行《软件配置管理差距分析及诊断报告》

 引子：

         本报告为公司给某农商行实施配置管理服务时，在初期的调研诊断报告，基本代表了国内大部分农商行的软件配置管理现状，供参考。

文中涉及术语：

CMMI：全称Capability Maturity Model Integration，即软件能力成熟度模型集成模型。分为5个级别，25个过程域（Process Area，PA） 

PA：Process Area（过程域）

SCM：Software Configuration Management（软件配置管理）

UCM：Unified Configuration Management（统一变更管理）

 

目录

一、差距分析的目的

二、访谈时间和范围

三、差距分析过程说明

四、当前配置管理现状级问题调研分析

（一）流程制度层面：

（二）人员角色层面：

（三）工具使用层面：

（四）应用环境：

（五）反馈的问题和期望

五、与配置管理过程域目标及活动差距分析

（一）配置管理（CM）目标及实践执行情况评估

（二）配置管理（CM）的强弱项分析

六、初步建议

七、资源补充建议

---

• 一、差距分析的目的

通过差距分析报告使项目组相关人员进一步了解当前项目配置管理水平与CMMI成熟度三级的差距，了解项目组在配置管理过程中的优点和不足，为更好地构建和实施配置管理做好前期准备。

• 二、访谈时间和范围

依据CMMI成熟度三级的要求，软件服务公司咨询人员于2018年多次分别对某农商行信息科技部开发中心各科室开发组代表进行了配置管理活动的自我评估和访谈，参与访谈调研的人员主要为各组组长及关键项目负责人,同时也对各科室领导，包括开发各开发科室、需求测试管理科、以及运维、生产调度科的领导进行了访谈，对我们的项目实施提出了要求和期望。

为了确保此次项目实施的正确方向和重点，特此先后专门访谈了信息科技部的多位高层领导，对我们此次的配置管理系统项目的实施提出了宝贵的意见。

• 三、差距分析过程说明

通过项目组自我评估和现场访谈，对某农商行的配置管理现状有了基本的了解，本报告列出以所发现的主要问题和建议为主，对某农商行的诸多成绩和强项不多加举例。自我评估和访谈中所作的访谈记录，不应作为评价各科室项目或人员能力的依据。

在访谈前，发给各科室项目组评估表进行自我评估，共收回《软件配置管理系统自我评估表》50+张，50+人参与自我评估，涉及被评估调研的系统有30+个。直接面对面访谈（不包括后期的流程梳理访谈）的项目组有10个小组代表参与，共计20+人，分三批次进行。

以下调研评估结果则是针对上述《软件配置管理系统自我评估表》、以及和各科室代表面对面沟通访谈的结果综合分析得出。

• 四、当前配置管理现状级问题调研分析

通过一周的自我评估和访谈，对某农商行当前配置管理活动有了较为深入的了解。某农商行目前配置管理活动现状和问题大体从以下几方面进行描述。

• • （一）流程制度层面：

1. 目前开发中心尚未有统一成文的组织级配置管理制度规范，各开发科室也没有科室级别的配置管理规范；

2. 目前尚未成立变更控制委员会CCB；

3. 部分版本管理系统采用了开发库/测试库/受控库/产品库的“三库”管理模式，使得开发活动、测试活动中的版本存储可以无干扰进行，但大部分系统的版本管理没有划分不同阶段的版本库，均放在统一主干中进行版本管理，目前尚未有统一的存储分支管理规范；

4. 大部分科室各系统的软件资产存放目录尚未统一，各自由项目经理自行进行存放管理；

5. 目前各项目均尚未有配置管理审计的做法，没有定期的配置管理报告机制；

6. 目前尚未有明确统一的变更管理（UCM）规范，在版本库提交更新的代码版本和变更标示大多做不到一一对应；大部分系统还没有完全做到每次的增量发布版本从开发、测试、生产的统一变更发布机制，没有完善的跟踪记录手段，这样会导致一旦上线出问题时，很难做到版本问题的反向追踪，追查问题的根源；

7. 目前各系统均未有配置管理计划；

8. 各科室对公共组件的开发和维护目前还未有具体的管理制度，存在多人混同开发造成版本被覆盖的情况；

9. 对于多需求的并行开发并没有很好地版本管理方法，有时会发生版本相互覆盖的情况；有时候计划需同时发布的多个需求中有个别需求临时不上线进行退版时，也会造成有些交叉文件（即多个需求会改到同一个文件的情况）退错版本的现象时有发生；

10. 目前大多数系统的测试/验证版本、生产发布版本并没有从版本工具中获取，很难保证生产版本和版本库版本的一致性，出了问题也很难追踪；

11. 目前缺乏统一的知识库管理，组织级和科室级资产文档尚未统一管理。

• • （二）人员角色层面：

1. 组织中目前正在筹划成立专职的配置管理管理层面的组织，负责全开发中心的配置管理制度的发布和工具的培训，以及配置管理活动过程的监督。

2. 目前某农商行刚确立组织级配置管理员角色，承担日后配置管理规范的发布和修订以及配置管理活动监督的职责，其具体职责还需要明确完善，并需要落实到配置管理工具层面。

3. 具体到各系统级别的项目级配置管理员（版本管理员）角色尚未明确，版本管理员基本由行方项目经理担任；

4. 大部分系统的开发、编译构建、部署测试环境、生产发布涉及到的版本传递过程活动基本都由项目经理或外包商自行管控处理，没有明确的各角色（比如行方项目经理、外包商项目经理、项目级配置管理员、构建人员等）职责权限。

• • （三）工具使用层面：

1. 不少系统至今长期没有纳入版本工具进行管理，包括核心系统，代码都放在各环境里进行管理，很难做到版本跟踪，存在较大代码版本管理风险；

2. 目前开发中心尚未有统一的配置（版本）管理工具，各开发科室、项目组自行部署开源版本管理工具如SVN、GIT管理各自版本，但即使同一科室内，版本工具也不统一，存在多台版本管理服务器。尚存在一些系统，依然未采用版本工具管理源代码，比如某些在HP-UX服务器端进行开发的系统；

3. 版本管理工具中的版本库数据基本没有专门做备份；

4. 版本管理工具在使用中几乎没有利用标记label功能来建立基线（Baseline），没有清晰标示版本的里程碑阶段；

5. 版本管理工具使用中几乎没有利用分支（Branch）功能来进行并行开发分流不同的工作区；

6. 版本管理工具大多数都未配置权限，存在版本被修改删除可能。

7. 个别系统采用了持续集成工具（Jenkins）自动从版本库获取代码进行编译，并部署到测试环境。

8. 开发工具：java语言类的系统以类似为Eclipse的终端开发工具为主，C语言的工具以VI或UE为主，SQL以PL/SQL、UE、Notepad++工具为主。大部分没有集成版本管理工具提交代码版本。

• • （四）应用环境：

1. 目前不少系统均有三套左右环境，包括开发、测试、验证环境，分别开发、集成测试、上线前模拟测试；

2. 目前各环境的代码获取没有制度约束检查手段必须从从版本库获取；

3. 开发环境、编译环境和测试环境需要规范来明确是否由专人来维护，需要区分界定清晰，并且规划不同权限。

• • （五）反馈的问题和期望

此次访谈中，无论是信息科技部领导还是各科室负责人、以及项目组成员对于版本管理都有较强的认知意识，深知版本管理的重要性，对此次配置管理项目的实施效果均表示了较强的期待。并提出了一些需求：

1. 希望新流程和新工具的引入能提高效率、提高质量，正确发版；

2. 新流程要符合某农商行的实际情况，管理上要取得平衡。解放重复性简单的劳动；

3. 提供一个规范的工具操作标准，为一键部署和持续集成打好基础;

4. 新流程在推广之前要仔细验证一遍，确定其可行性，以及适用性，是否符合某农商行的实际情况；

5. 希望以后逐渐能把运维中心自主管理的开发项目一并统一管理起来；

6. 希望能做到可跟踪、有版本发布记录，出了版本问题能知道是怎么引起的？什么时候引入的？谁引入的？怎么引入的？是哪个环节出的问题？

7. 在实施过程中多考虑采用其他技术充分发挥工具的作用，不限于配置管理工具本身功能；

8. 希望为后续和项目管理工具集成提供思路；

9. 需要提供完善的流程规范，以及操作级别的操作手册；

10. 能起到开发中心的知识库作用，管理开发中心的常用文档手册等资料；

11. 希望能有效缓解并行开发和版本冲突的问题；

12. 希望能把现在及将来所有系统的代码都管理起来，包括HP-UX等Unix系统的版本，减少版本风险；

13. 希望不仅是管理源码和上线文档，整个开发过程文档都能管理起来，能知道中间的演变过程；

14. 希望能从版本系统中随时能抽取对应生产上的版本；

15. 希望能支持自动化定时编译，方便开发人员每天只需来检查编译出错结果并进行处理就行；

16. 代码并行修改时，希望工具能提供便利手段能很快捷地批量进行代码差异比对，减少人工比对的工作量；

17. 希望能支持跨团队协作开发，团队之间能获知对方的代码更新改动，通过类似链接的方式支持代码共享；

18. 希望提供直观的报表，可按不同维度统计代码修改量；

19. 希望能管理需求类的文档，包含需求变更内容，建立组织级的需求管理统一入口；

20. 测试缺陷比较多，希望每次版本更新能体现出缺陷信息；

21. 考虑和项目管理工具、代码扫描工具结合，以后能为某农商行筹备统一的信息管理平台，打破信息孤岛的建设提供方案思路；

22. 希望开发、测试、OA网段都能访问；希望在OA网段能看源码；

23. 希望以后运维发布能集中统一从指定的地方获取上线的内容，最终实现以后一键发布的愿景；希望能管理部署码；

24. 在实施中，希望版本管理系统的规划和流程规范能充分考虑到不同分支库版本和不同环境的之间对应融合；

25. 希望和组织的CMMI的CM PA(配置管理过程域)流程制度匹配兼容。

• •  

• 五、与配置管理过程域目标及活动差距分析

根据自我评估和访谈的情况，我们就配置管理的目标及其实践的执行情况进行了统计和分析，形成了配置管理活动的实现状况统计，详见如下：

颜色	实现比例	说明
红色	0-14	完全没有实现
黄色	15-64	部分实现
绿色	65-89	基本实现
蓝色	90-100	非常好

                                                                                                           图例

• • （一）配置管理（CM）目标及实践执行情况评估

具体与CMMI成熟度三级配置管理过程域（CM PA）的差距分析结果如下。

专用目标	专用实践	描述	子实践	参考分析说明	差距分析评估
专用目标1-建立基线 (建立所标识工作产品的基线	专用实践1.1- 标识配置项	标识将置于配置管理之下的配置项、配置部件和有关工作产品	a) 基于文档化的准则选择配置项和构成配置项的工作产品。 b) 对配置项赋予唯一的标识符。 c) 指定每个配置项的重要特征。 d) 指明每个配置项纳入配置管理的时机。 e) 标识负责每个配置项的所有者。	基本能把系统源码、部分文档作为基础配置项纳入版本库，但是大部分系统未进行基线化管理，未采用标记功能来标示每次大的版本更新	黄色
	专用实践1.2- 建立一个配置管理系统	为了控制工作产品，建立和维护配置管理和更改管理的系统	a) 建立配置管理的多级控制机制。 b) 存储和检索配置管理系统中的配置项。 c) 在配置管理系统中各控制级之间共享和传递配置项。 d) 存储和恢复配置项的归档版本。 e) 存储、更新和检索配置管理记录。 f) 从配置管理系统中生成配置管理报告。 g) 保护配置管理系统的内容。 h) 必要时，修改配置管理结构。	大部分系统基本都纳入版本工具进行管理，基本做到多级控制机制（多库模式）、基本能在各级库之间传递版本，但是尚未进行配置管理报告等管理，没有清晰的配置管理系统管理制度	黄色
	专用实践1.3- 生成或发布基线	生成或发布基线供内部使用或交付给顾客	a) 在生成或发布配置项的基线之前，从配置控制委员会（CCB）取得授权。 b) 仅从配置管理系统中的配置项生成或发布基线。 c) 文档化基线中的配置项。 d) 使当前这组基线就绪可用。	很少采用基线(版本工具里标记功能)的方式进行发布配置项，很少会有去类似配置控制委员会CCB的组织申请授权，部分能做到文档化基线中的配置项（类似文件清单）	黄色
专用目标2-跟踪和控制更改 （跟踪和控制对基线的更改）	专用实践2.1- 跟踪更改申请	跟踪配置项的更改申请	a) 启动并在更改申请数据库中记录更改申请。 b) 分析更改申请中所建议的更改和补救措施的影响。 c) 与利益相关方一起评审可能影响下一基线的更改申请，并取得一致意见。 d) 跟踪更改申请的状态，直至关闭。	基本能在项目管理系统或其他形式记录更改申请源（需求、缺陷或ITIL生产事件问题），基本能做到对更改需求进行影响分析，并获得组织批准，并跟踪其状态直至关闭，但目前变更源和变更代码并没有很好对应	绿色
	专用实践2.2- 控制配置项	控制对配置项的更改	a) 在整个产品生存周期控制对配置项的更改。 b) 在所更改的配置项进入配置管理系统之前取得适当的授权。 c) 为了以维持配置项正确性和完整性的方式纳入更改，从配置管理系统检入和检出配置项。 d) 执行评审以确保更改不会对基线引起意外的影响（例如，不会损害系统的安全性和保密性）。 e) 适当时，记录对配置项的更改，以及此更改的理由。	对配置项的更改大多没有进行权限控制，尚未有明确的对基线更改进行评审的流程规范，对配置项的修改的记录和理由说明也没有明确的规定	黄色
专用目标3-建立完整性 （建立和维护基线的完整性）	专用实践3.1- 建立配置管理记录	建立和维护描述配置项的记录	a) 足够详细地记录配置管理措施，使得每个配置项的内容和状态都已知，且可恢复以前的版本。 b) 确保利益相关方能存取和了解配置项的配置状态。 c) 指明基线的最新版本。 d) 标识构成特定基线的配置项的版本。 e) 描述逐个基线之间的差异。 f) 必要时，修订每个配置项的状态和历史（即，更改及其他措施）。	目前尚未有明确的建立和维护描述配置项的记录机制，很少使用基线标示记录最新版本，并对基线之间进行的差异形成报告说明	黄色
	专用实践3.2- 执行配置审核	执行配置审核以维持配置基线的完整性	a) 评估基线的完整性。 b) 确认配置管理记录正确地标识配置项的配置状态。 c) 评审配置管理系统中配置项的结构和完整性。 d) 确认配置管理系统中配置项的完备性和正确性。 e) 确认与可用的配置管理标准和规程的一致性。 f) 跟踪来自审核的措施项，直至关闭。	很少做到对基线内容是否完整和正确审计，尚未形成配置审核机制	黄色
专用实践数量				通过各科室项目组的自我评估和访谈，项目组对配置管理过程域约定的7个专用实践均有涉及	7
实现实践数量					7
本过程域实践实现比例					部分实现（黄色）

• • （二）配置管理（CM）的强弱项分析

• 强项

1. 管理层领导对配置管理工作很重视，对此次配置管理实施提出了比较明确的目标和期望，并且项目组成员对配置管理认识比较清晰，有较强的改进配置管理过程的诉求，为此次配置管理实施提供了动力；

2. 项目组基本能做到对各自系统配置项进行识别并纳入各自的版本管理工具进行管理；

3. 不少系统做到了区分开发、测试、验证环境；

4. 目前已确定组织级配置管理员角色并开始筹建专门的配置管理组织，为配置管理工作的持续进行提供了组织保障；

5. 目前已开始开展包括CM域在内的CMMI 3级的过程改进工作，为整个软件应用开发过程提供了体系保障；

6. 个别系统采用了持续集成工具实现了部分自动化功能，为日后的全面持续集成提供了技术实践参考；

• 弱项

1. 尚未有明确统一的组织级配置管理规范制度，包括明确该活动角色与职责定义，包括存储库使用模式、权限规划等；

2. 各科室各自的独立配置管理服务器太多，没有集中管理，工具也不统一；

3. 核心系统等重要系统还未纳入版本管理，各系统亟需版本化；

4. 基线管控手段尚未做起来，版本工具的标记、分支功能很少用到；

5. 尚未有统一的版本发布、上线流程，使得生产服务器版本与投产基线一致。

• 六、初步建议

综合上述分析结果，我们提供以下建议：

1. 制定组织级配置管理活动目标和考核办法，从制度上确保配置管理的顺利推进和实现；并结合实际调研情况、差距分析，完善配置管理规范体系文件；

2. 设立组织级和项目级变更控制控制委员会（CCB）、明确组织级配置管理员和项目级配置管理员岗位，明确职责，完善配置审计和培训等事宜；

3. 统一组织级配置管理工具，逐步收归迁移所有应用系统的软件资产文件版本到组织级配置管理工具中，逐步关闭原有的版本管理工具；

4. 推广版本管理工具中“三库”分支管理模式，统一规范名称和使用流程；普及版本管理工具中“标记”功能的使用，按规范建立必要的基线。便于需求和版本追踪，也为以后的持续集成夯实系统基础；

5. 约定进入测试环境和进入生产环境的软件版本必须从组织级配置管理工具相应库分支中获取，保证生产版本和配置管理工具中配置库的版本保持一致。逐渐统一生产发布途径，由运维中心发布人员从组织级配置管理工具中按指定标记获取上线包；

6. 明确各个系统的项目级（系统级）配置管理员角色，强调和发挥项目级（系统级）配置管理员角色职能，保障各系统分支版本合并的正确操作；

7. 建立配置管理审计监控制度，保障日常各系统配置管理活动的规范和持续性。

• 七、资源补充建议

1. 组建独立的组织级构建团队，执行从UAT测试开始的版本构建和部署，以后可以考虑通过脚本或者持续集成工具实现从Firefly中自动获取版本，自动编译，自动部署环境，减少人工误操作，减少夹带，从而提高工作效率，提高质量，降低风险。

2. 设置独立的组织级QA团队，监控项目的过程和交付物质量，以及配套的QA管理体系制度；

3. 建设专门的应用系统版本构建环境，并保障各应用系统都有独立的构建环境，资源共享、不冲突；

4. 考虑引入持续集成工具，和配置管理工具、构建工具、代码测试工具集成，逐步实现持续构建、持续集成，持续部署，从而提高工作效率，减少人工误操作，减少夹带，提高开发质量。

 

作者同系列博客参考链接：

Git基础入门七：Git高级命令之Rebase

Git基础入门六：标签管理（git tag）

Git基础入门五：分支管理

Git基础入门四：版本回退（撤销修改）

Git基础入门三：创建版本库和添加修改文件基本命令

Git基础入门二：工作区和暂存区

Git基础入门一：起源与安装