本文讲述了配置管理的一些基本知识和一个具体的实例，以及从配置管理入手的过程改进策略。这里的软件过程改进是普通意义上的过程改进，并不局限于以通过CMM评估为目标的软件过程改进。
本文并不适合于正在实施过程改进的公司，因为过程改进是一个系统的工程，需要详细的规划、持续的实施和有效的支持。不过对准备实施过程改进的部门来说，具有一定的参考意义。
本文也不适合于项目组的所有成员，和过程改进一样，这会产生附加的工作量，他们只需要知道怎么做就行了。而本文讲述的更侧重于为什么这么做，是配置经理和项目经理等技术管理类角色需要关注的问题。
词汇：
SPI：Software Processes Improvement，软件过程改进
CM：Configuration Management，配置管理
CMI：Configuration Management Item，配置项
CMO：Configuration Management Officer ，配置管理员
CCB：Change Control Board，变更控制委员会。项目中负责对各种变更请求进行审核。由项目相关方组成，在不同项目组其组成会略有不同。
CMM：Capability Maturity Model ， 能力成熟度模型
KPA：Key Process Area ，关键过程域
RUP：Rational Unified Process，Rational统一过程
1. SPI，中国软件产业的必由之路
能够生存下来的物种，不是最强壮的物种，而是应变能力强的物种。软件过程改进，在同样是优胜劣汰的商海中，是软件公司的必修课，更是中国软件产业的必由之路。
好的软件开发过程，客户满意、高级经理放心、项目经理得意、开发人员轻松。但好的软件过程不是与生俱来的，需要不断的摸索和改进才能抓住关键。同时，软件过程应该是组织的软件过程，而不是某些员工的软件过程，应该在正常的人员流动下保持稳定。
软件过程改进是一个系统工程，从确立目标、确定工作内容、实施策略、进度安排、资源配置、最后的达标标准，到实施过程改进，到最后达标审计，其规模并不亚于一个大型的软件项目。
它需要充分的准备、良好的规划、系统的管理和相当的资源，需要充足的、高素质的资源支持
方能顺利开展，更需要公司高层的大力支持。在以上条件不完全具备的情况下，从某一个方面进行过程改进尝试，是一个不错的选择。
同时，过程改进会产生一定的附加工作量，也会改变很多员工的工作方式，甚至是他们一向认为行之有效的方法。过程改进需要提高的是组织的能力，因此需要牺牲一些个人的习惯，这也是过程改进的主要阻力之一。得不到公司充分的支持、短期成果的不明显等等，都是过程改进需要面对的困难。过程改进的阻力与降低阻力的有效实践不是本文的讨论范围，在此不赘述。
配置管理是项目管理的主要内容之一。配置管理中的版本控制是和开发人员最密切相关的项目管理活动，也是最容易发现问题、解决问题和最容易出成果的方面。从版本控制开始，润物细无声地将版本控制、配置管理等过程进行改进，并以相应的成果为推动力，将一些项目管理的基础理论和公司策略贯彻到日常工作中，为暴风骤雨般的全员过程改进打一个好的基础。
标题所说的“SPI从CM开始”，就在于此。
2. 配置管理基础 2.1 配置管理及其作用 2.1.1 配置管理
配置管理：标识和确定项目软件配置项（CMI）并在项目软件的整个生存周期中系统地控制这些配置项，记录、报告其版本和状态，并验证配置的完整性和正确性。
配置项是配置管理下作为单个实体对待的工件产品。如一个文档、一个源文件等。
2.1.2 配置管理的作用配置管理的作用是建立和维护在整个软件生命周期中项目产品的完整性、一致性和可追踪性。
它关注的不是软件的好坏，而是工件的有无。
变更控制保证项目范围可控，并保证项目产品与用户需求的一致和完整。
2.2 配置管理主要内容配置管理的主要活动很多，如编制、评审和批准SCM计划；SCM人力组织；建立配置环境；发布配置状态报告；基线发布；变更申请、审核与实施；发送变更结果给受影响方；配置审计；产品发布等。笔者将其概括为两大类：配置项管理和变更控制。
2.2.1 配置项管理配置项管理包括了非变更相关的全部内容。其核心是配置项的标识、访问控制、版本追踪和发布。由于篇幅关系，在此只说明一个较重要的概念：基线。
基线（Baseline）：多种解释。基线是已通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序才能进行更改。或者解释为，开发过程中工件集的一个有特殊意义的快照。基线可以分为非程序类（项目计划、需求规格说明、设计工件等）基线和程序类（代码类）基线两大类，前者的发布由配置经理或配置管理员发布，后者由集成员发布。
基线和里程碑的区别：里程碑面向管理，属项目管理范围，更关注时间；而基线是一些特定版本的工件的集合，属于配置项的范围，存在于配置库中。
2.2.2 变更控制变更控制的目的：通过变更控制机构（如CCB）对项目相关方提出的每一个变更进行审核，通过明确该变更对项目的影响，从而决定是否接受该变更，最终达到整个项目范围可控。
项目的任一相关方都可以向配置管理组提出变更请求，配置管理员组织变更控制机构及相关方召开变更控制会议，明确该次变更的受影响方，并明确决定（一般要求书面）是否接受本次变更。如果同意变更，则发布变更报告，通知受影响方实施变更，并跟踪变更直到全部变更实施完毕，并体现在配置状态报告中。
变更控制机构的组成以及变更控制会议的规模和具体形式可根据实际情况灵活处理。开发方和用户的变更都关系到项目的成败，所以变更控制机构在组建时需要充分考虑。
典型的变更控制流程如下图：
图1 典型变更控制流程
2.2.3 配置管理中几个主要文档的要点 2.2.3.1 配置管理计划配置管理计划是项目计划集的重要组成部分，是配置管理活动的基础。其制作以软件开发计划（SDP）为基础，根据SDP的生命周期和其它计划安排，编写配置管理计划。
其基本内容应包括：配置管理的基本策略；配置管理组织和职责；配置工具、环境；配置管理基本策略和工具培训安排；配置项标识方法；项目基线的工件组成；变更处理流程；CCB组成；工件、产品和报告的发布进程；配置审计计划等。
2.2.3.2 配置状态报告配置状态报告按时间段提交，项目经理结合其他报告完成项目状态报告。
其基本内容应该包括配置项状态（初始/已测试/已发布）、变更统计、基线发布信息、版本发布信息、备份信息等。
2.2.3.3 基线发布表基线发布表至少应包含如下信息：项目编号、发布人、基线号、发布时间、基线包括的工件以及工件的路径、版本、负责人等。
2.2.3.4 变更申请变更申请分文档类和非文档类两种，其主要变更流程基本相同。
变更申请单的信息一般由整个变更过程的变更信息组成，包括：变更申请人、申请时间、变更涉及工件、变更描述、受影响方（提请人和相关方共同确定）、变更审核结果、变更追踪等。
3. 项目版本控制实例
本部分以JBuilder + VSS，struts构架开发WEB应用为例，讲述了相应的配置项管理策略。其中大部分是CMO的事情，因为对开发人员而言，知道怎么做就行。
本部分内容不包括在JBuilder中设置和使用其直接从VSS签出签入工件的使用方法。笔者认为工具只是实现思路的手段，不应该是策略和方案的主体。所以即使你使用的配置管理工具不是VSS也没关系，重要的是思路。
本策略假设开发人员已经养成了修改前check out，修改后check in 或者undo check out（不成功修改）并选择“replace”的操作习惯。
图2 配置库
3.1 本节词汇
PL：Product Library，产品库，又叫发布库。存放阶段性的可发布产品版本。
CL：Controled Library，受控库，项目组范围内受控的工件库，其中工件的修改要求相对比较严格，需要向相关的变更控制机构提交申请并审核通过后方可修改。受控库由配置管理人员管理。
DL：Develop Library，开发库，开发组用来存放开发工件和进行版本跟踪的库，开发人员可以直接将相应的工件签出（check out），修改完后签入（check in）。
LP：Local Project，本地工程。
配置短路：开发人员之间的工件传递没有经过配置库，是配置管理的大忌。例如从共享的工程目录中复制文件、通过邮件发送工件等等。
受控范围：一次变更可能影响到的最大范围。开发组内协同开发但未提交的工件，其受控范围是开发组；提交到受控库后，其受控范围是整个项目组。
3.2 具体控制策略描述表一 工件获取与修改说明表
文件
角色
获取库
允许修改级别
修改流程
F1
P2
CL
1
变更提请人向CMO提交变更申请，CMO提请CCB审核通过后将相应工件check out，由工件开发者完成修改并经过变更提请方确认后再由CMO check in，并做好变更记录，通知受影响方，并在配置报告中发布。
P1,P3
CL
1
P4
CL
1
P5,P6
CL
1
—
F2
P2
CL
1
变更提请人向CMO提交变更申请，CMO提请CCB审核通过后将相应工件check out，由工件开发者完成修改并经过变更提请方确认后再由CMO check in，并做好变更记录，通知受影响方，并在配置报告中发布。
P1,P3
CL
1
P4
CL
1
P4向CMO申请，CMO提请CCB审核通过后将相应工件check out并交由开发组_1修改，P4确认后再由CMO check in，并作变更记录，通知P4及受影响方，并在配置报告中发布。
P5,P6
CL
0
—
F3
P2
DL
2
从DL中check out，修改后check in并作好修改注释，通知P1,P3
P1,P3
DL
2
向P2说明情况，组内讨论认为能修改，则由P2完成修改并记录
P4
—
0
—
P5,P6
—
0
—
F4
P2
LP
3
直接本地修改。
P1,P3
—
0
—
P4
—
0
—
P5,P6
—
0
—
对上表的说明：
1)、本表所描述的范围是指项目组范围。
2)、文件：是相对角色P2而言。
F1是全局相关的文件，如配置文件，*.xml，*.tld, *.mdl, *.pdm, 关键技术说明文档等。这些文件生来就在受控库（CL）中。还包括共用的javascript脚本、jar包等等。
F2是开发组_1通过组内单元测试并提交受控的工件。存在于受控库（CL）中，提交时开发组_1提供工作库（DL）中相应文件路径、版本号列表，由CMO将相应的工件share（选择Branched）到受控库（CL），并删除工作库中相应工件，保证开发库和受控库中只有一个文件拷贝。由于VSS不支持共享工件的某个历史版本，因此要求开发组提交了工件后、CMO添加到受控库前不能再直接增加版本号（check out修改并check in）。
F3是开发组_1正在协同开发的工件。由开发者本人或者开发组_1的组CMO添加（Add）到工作库（DL）。工作组_1组内人员通过check out/in 控制修改。
F4是本地工程中正在开发、未添加到工作库（DL）的工件。其版本控制由开发人员自己处理，可以使用JBuilder自带中文件的History选项。对较重要工件，开发人员可以考虑建一个本地VSS数据库进行版本记录。
3)、获取库：是指需要使用相应工件时从何处get。
“—”代表不能使用，如果一定要使用，则需要将相应工件上升到本范围内受控（工作组范围内体现为add到工作库、项目组范围内体现为提交到受控库），切记不可通过从共享的本地工程拷贝获取（配置短路）。
4)、许修改级别：是指是否允许修改以及相应的约束。
0：不允许修改
1： 有条件修改。变更方提交变更申请，CCB或者相关变更审核机构审核通过后，由CMO将相应工件check out，由工件的开发人员修改完毕后由CMO check in到受控库，并以合适的形式通知变更提请方和受影响方。
2：允许修改，本人check out，修改完毕后再check in。
3：本地修改：对本人本地工程文件，本地修改。
5)、流程：具体操作步骤。
3.3 本策略的基本原则1)、工件的修改只能由工件开发者完成。
2)、受控库（CL）+开发库（CL）组成一个完整的工程。一个工件在CL+DL中只能有一份拷贝。
3)、使用别人的工件只能使用本范围内受控的工件。
4) 、每次变更应该及时传递给受影响方。可以采用本地不保留工程文件的方案，每天都从VSS上get全部工程文件（CL+DL）。
4. 基于CMM的SPI之路 4.1 CMM与软件过程改进
软件过程改进是一项系统工程，所以需要选择一个合适的管理体系来指导改进。按照僵化、固化、优化的规律，软件过程改进之路有一定的可重复性。这种可重复性，笔者将它看作是开发管理体系中的主要组成部分。
体系本身无所谓优劣，但为什么相同的体系，在不同的公司其应用结果却差别巨大？CMM也好，ISO9000也好，都是前人总结和归纳出来的、具有可重复性的规律和一些已经证实的比较行之有效的方法。但体系的实行者和软件开发的主体依然是主观的人。要用好某种体系，关键是抓住根本，结合实际，灵活运用。做到是人用体系，而不是体系用人。
CMM称作能力成熟度模型，其核心内容包含若干KPA－Key Process Area，即关键过程域。不同级别包含不同的KPA，详细内容请查阅相关资料。但这些KPA只是讲述了在每个领域的基本原则和需要达到的目标，并没有给出具体的实施方案，因为在不同的开发体系中其具体实现并不相同。RUP凭借其管理和分析的完整性，成为绝大多通过CMM评估企业采用的软件开发体系。
CMM1－5级共计18个KPA，软件配置管理－SCM在CMM1.1中是Level 2可重复级的KPA，CMM2的另外5个KPA包括软件项目计划（SPP）、需求管理（RM）、软件项目跟踪监控(SPTO)、软件质量保证(SQA)、软件子合同（外包）管理(SSM)。
笔者从CMM和RUP开始关注软件开发管理体系，下面所列的是一点体会，并不具有系统性，供大家参考。实施的时候要结合公司的软件过程和研发管理体系灵活运用。
4.1.1 建立组织财富库、软件过程和研发管理体系很多公司在发展过程中已经积累了很多行之有效的工作方式，在此简称为“经验”。如何将个人的“经验”变为组织的软件能力，并使得公司在此基础上获得更大发展，建立软件过程和研发管理体系是非常重要的一步。虽然组织过程焦点和组织过程定义是CMM3的KPA，但这并不意味着没有通过CMM3评估的企业就不能有自己的组织过程。而且，软件企业要扩大研发规模，组织软件过程和研发管理体系必不可少。
建立组织过程的第一步就涉及到软件过程和研发体系版本管理和发布，以及相关文档、规范、指南的管理。良好的配置管理是基本要求。
4.1.2 评审和基线的发布加强过程控制CMM的提出者Watts Humphrey认为，软件系统的质量取决与用于开发和改进它的过程的质量。
关注了过程就关注了质量。CMM－2，可重复级与初始级的最大差别就是将整个过程划分为若干子过程，并在每个子过程的开始和结束点实施评审，保证每一个子过程都是受控制和有效的。只要将6个KPA都实现，基本上可以重复以前的成功，故称可重复级。
每阶段的评审和评审通过基线的发布，都与配置管理活动密切相关。基线组成工件作为下一子过程的入口工件，其质量好坏直接影响后续的全部子过程，从而影响到整个软件项目。所以，做好各个重要评审和阶段评审，直接关系到整个软件的进程。
4.1.3 CCB的运作确立风险意识，并有效控制项目范围随意接受变更是导致很多软件项目失败的直接原因。而且大多数时候并不是开发方愿意接受变更，而是无法说服用户，最终只有接受。CCB的引入很好地解决了这个问题。
CCB由项目相关方组成，至少应包括开发方项目经理和用户方项目负责人。通过变更控制会议的充分沟通和民主抉择，和审核结果的书面确认，使开发方和用户能很容易达成共识，明确了变更风险，并建立一种共同监督机制。
对开发方人员而言，也避免了需求镀金和不受控变更。
所以，CCB的有效运作，既可以保证项目可控，又能让用户的合理需求得到满足，是项目成功的最佳实践之一。成功的软件企业常常会把沟通管理和变更控制的相关内容写到合同中。
4.1.4 核心工件的标准化有利于抓住关键和沟通过程改进必然会有附加工作量。尽量减小此负面效应的有效方式是：对核心工件建立模板。软件项目计划（SPP）等核心工件的标准化有利于抓住关键和沟通交流，并进一步提高组织的软件能力。
4.1.5 受控提高全员责任感受控机制的建立，使得开发人员明确了变更的影响范围，不能象以前那样，开发时漫不经心，想起什么错误就可以很容易修改，而这种修改往或者不能及时体现给受影响方，或者对其他工件造成影响，形成无尽头的反复。
新机制下，对受控库中工件的修改必须提交申请，因此开发人员必然会在开发时加强责任感，提交受控以前尽量做好组内测试，在提请变更前慎重考虑，从而尽量地减小了因个人的差异对开发组造成的影响。
受控机制的建立既培养了好的工作习惯，又减小了测试组的工作量，降低了主观因素的影响，从而也提高了质量。
4.1.6 加强QA人员的服务意识QA的最终目标是保证和提高软件的质量，QA人员的职责不应该只是事后监督，他首先应该是一个服务者的角色。否则QA人员的工作最终因为没有足够的行政权限而很难开展。
在公司的软件研发管理体下QA人员除了关注各种评审和审计外，更多地应该关注如何提高软件的质量。将这些方法和有效实践及时地和项目经理沟通，共同提高软件质量，形成开发人员和QA人员为一个目标共同努力的氛围。
所以完善QA的服务职能，有利于QA工作的开展并最终提高质量。
5. 结语配置管理不是孤立的，它和软件质量保证（SQA）、项目管理、测试等很多软件开发活动都有重叠。配置管理策略和方法也会因不同的软件过程和研发管理体系而异。
《论语》有云：君子务本，本立而道生。本，一可理解为基本理论。但只有理论当然不够。学而时习之，不亦说乎。此“习”不妨作实习、练习解，亦可作为“本”字的第二种解释，意即理论联系实际。又曰：温故而知新，可以为师矣。结合实践和经验，再回头看这些理论，自然又是一番境界。
再者，根据2－8（关键性）原则，掌握了配置管理的关键理论和实践，自可以运筹帷幄、决胜千里。
组织软件能力的提高需要团队的力量；中国软件产业能力的提高，需要大家的努力！
每个人经历不尽相同，当然其体会也各异。本文旨在抛砖引玉，希望能引出更多更好的理论和观念来。或洋洋洒洒，或字字珠玑，都是我之所盼，应该也是所有同仁之所盼！
本文地址：http://com.8s8s.com/it/it34186.htm