配置管理规范
文件修改控制

修改记录编号 修改
状态 修改页码及条款 修改人 审核人 批准人 修改日期
目录
1. 目的
2. 适用范围
3. 术语和缩略语
4. 规范内容
5. 引用文件

1. 目的
指导配置管理人员如何建立配置库，并利用配置库管理所有配置项，从而提供配置项的存取和检索功能，有利于配置项的更改控制，保证配置项的完整性和可跟踪性。

2. 适用范围
适用于所有软件产品和软件项目的配置项管理。配置管理可采用各种工具及手工办法，本文件以Source safe配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。

3. 术语和缩略语
本文件采用NP601100《配置管理》程序使用的术语和缩略语的定义。

4. 规范内容
4.1 配置管理的范围
软件配置可包括以下几方面：项目文档，源代码，执行程序，相关设备及资料等。
1） 项目文档主要指：立项建议报告、项目启动计划、可行性分析报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、技术报告、总结报告、验收报告以及上述文档的评审记录。
2） 相关设备主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中使用的专用仪器设备，如读卡机、扫描仪等。
3） 相关资料主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电话记录等。
4.2 各配置项的获得
项目立项之后，软件配置管理负责人SCML即可建立项目配置库，并着手收集各配置项。
1） 项目文档。开发各阶段结束时，软件配置管理负责人SCML可向开发人员索要相关文档及对应评审记录，归到配置库。
2） 开发人员在出差前应带好与客户会谈的准备材料。根据出差的任务不同，还应准备客满意度调查表，交付书，验收报告等。返回之前应和客户确认，并在出差回来时交给软件配置管理负责人SCML一份备份，如有客户提供的文献资料、有关设备仪器须进行登记。对于任何正在进行的项目，如有客户来访须做好会议纪要。
3） 开发部门发给客户的传真件或客户发来传真至少应在项目档案中保存一份备份。
4） 对于源代码和执行程序的管理最好使用工具，条件不具备时，要注意对配置库的目录分配。各开发人员分别建立自己的工作目录，完成后的模块再放到项目相关目录下。
5） 在项目结束归档时电子邮件也应作为项目的相关资料进行归档。
4.3 配置库的建立
所有项目应建立一配置库，以便管理前面提到的各配置项。一般的可视化开发环境都有自带的配置管理工具，可以用管理工具来建立配置库，也可以在机器的某目录下建立配置库，手工管理。下面以Source Safe为例描述配置管理库的建立及各配置项的控制方法。各项目在开始时，均应建立以下几项子项目，进行分阶段管理。
4.3.1 项目启动
配置项包括立项建议报告及其评审结果、合同草案及评审结果、合作协议、项目任务书等。项目立项通过后应封锁该子项目，如后期须增加或修改应征得软件配置管理负责人SCML的认可，并作好标记。项目启动计划部门内部评审通过后，版本为0.7版，当启动计划生效执行后，版本升为1.0。
4.3.2 需求分析
针对合同项目，按系统所处理的业务不同，需求分析可分为客户业务描述、业务流程图、系统功能点提取、系统数据流图等子项目。系统调研后开发人员进行系统分析，并整理需求分析报告。需求分析报告通过部门内部评审时，版本定为0.7，取得客户的确定后为1.0版本。在需求分析报告取得客户的确认后，封锁该子项目，如后期需要修改，须征得管理员的认可，并作好修改说明，如需升版则必须通过部门评审并得到客户的确认，以1.0版本为基准按0.1单位增加版本。
4.3.3 软件功能规格说明书
针对公司自立项目，在项目启动阶段需要编写软件功能规格说明书，通过内部评审后，版本定为0.7，公司评审通过后版本定为1.0，如无须公司评审，则由0.7版自动升为1.0版，如后期需要修改，须征得软件配置管理负责人SCML的认可，并作好修改说明，如需升版则必须通过部门评审，以1.0版本为基准按0.1单位增加版本。
4.3.4 开发计划
需求分析或软件功能规格说明书完成后即可制定项目的开发计划，包括项目总体进度说明，及进度跟踪，计划修改，配置管理计划等。开发计划的修改按项目文档来处理。进度跟踪一般使用Project管理编制，由于修改较频繁，可只对作为进度基准的进度标记修改说明。开发计划通过部门内部评审后版本为0.7，批准执行后版本为1.0。
4.3.5 系统设计
系统设计可分为CDM、PDM和数据字典设计，功能模块划分及算法描述等部分。针对需求分析报告或软件功能规格说明书进行系统设计，系统设计报告部门评审通过后的版本为0.7，系统测试修改完成后其版本升为1.0，配置时应说明系统设计的版本与需求分析或软件功能规格说明书版本的对应关系。
4.3.6 编码
编码可分为前台业务处理和后台过程，也可按功能模块或人员再分子项目。编码实现过程应注意与客户需求系统设计相一致，否则须修改设计报告。在配置管理活动中工程项目的源程序代码版本控制一般指内部版本，新项目的系统测试结束后其版本为0.7，试运行阶段验收通过后版本为1.0，并以此版本为基准将来每次升级时，以0.1为单位增加。产品项目的源代码版本控制也可参照执行。
4.3.7 测试
功能测试阶段应提供测试问题卡与测试总结；系统测试阶段应提供测试大纲、测试用例、测试所发现的问题和修改说明，及测试总结报告等。
4.3.8 验收与项目总结
项目验收最好能分为两个阶段，即安装试运行验收和项目最终验收。除验收报告外，验收期间与客户会谈纪要也应作为验收材料之一。项目总结由项目组成员共同编制，并应经过部门内部评审。
4.3.9 相关资料与培训
此部分包括相关法律、法规，必须遵照或项目组约定的技术规范，必要的业务或技术培训等。
4.3.10 分承包商（可选）
如果项目需要分包，须要提供分包方的背景说明，分包协议要求，以及分包括商合格评定材料等。
4.3.11 日常事务
与项目相关的日常事务，如项目组内的规定，项目周报、日报、人员的增减、出差事务等。

5. 引用文件
（无）
配置管理规范