软件项目配置管理计划案例本案例选自软件项目管理案例教程(韩万江，机械工业出版社)一书, 项目案例为校务通管理系统，该项目的配置管理计划如下：1.引言包括目的、缩写词和参考资料，具体内容略。2 .组织及职责配置管理的角色和职责见表1。表1 ：配置管理角色职责表角色人员职责和工作范围配置管理者岳好(1) 制定配置管理计划(2) 创建和维护配置库SCCB负责人韩万江(1) 审批配置管理计划(2) 审批重大的变更SCCB 成员韩万江(项目经理)，郭天 奇(质量保证人员)，岳好(配置管理者)审批某些配置项或基线的变更3.配置管理环境由于本项目属于中小型项目，工期也不很长，而且项目组人员对VisualSourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。3.1配置库目录结构表2:配置库的目录结构序号内容说明路径1:TCM技术合同管理$prj-SchoolTCM2RM需求管理$prj-SchoolRM3SPP软件项目规划$prj-SchoolSPP4:SPTO软件项目跟踪与管理$prj-SchoolSPTO5SCM软件配置管理$prj-SchoolSCM6SQA软件质量保证$prj-SchoolSQA7设计$prj-SchoolSPEDESIGN8软件产品源代码$prj-SchoolSPESOURCE9SPE工程目标代码$prj-SchoolSPEBUILD10测试$prj-SchoolSPETEST11发布$prj-SchoolSPERELEASE3.2用户及权限表3:配置库的用户权限类别人员权限说明配置管理者岳好负责项目配置管理，拥有所有权限项目经理韩万江访问、读质量保证人员郭天奇访问、读开发人员姜岳尊，孙泉访问、读高层管理访问、读4 .配置管理活动4.1配置项标志4.1.1命名规范本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类 型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。公司：3个字符项目：最长10个字符类型： 最长 5个字符编号：最长8位数字/字符版本号：V m.nQTD-School -RM -SRS-v1.0图1 :配置项命名规范4.1.2主要配置项表4:配置项列表类型主要配置项标识符预计正式发表时间技术合冋合同QTD-School-TCM-C on tract-V1.02003-4-11sowQTD-School-TCM-SOW-V1.02003-4-11计划项目计划QTD-School-SPP-PP-V1.02003-4-11质量保证计划QTD-School-SPP-SQA-V1.02003-4-11配置管理计划QTD-School-SPP-SCM-V1.02003-4-11需求需求规格说明书QTD-School-RM-SRS-V1.02003-4-18用户DEMOQTD-School-RM-Demo-V1.02003-4-18设计总体设计说明书QTD-School-Desig n-HL-V1.02003-4-22数据库设计QTD-School-Desig n-DB-V1.02003-4-22详细设计说明书QTD-School-Desig n-LL-V1.02003-4-25设计术语及规范QTD-School-Desig n-STD-V1.02003-4-22编程源程序QTD-School-Code-ModuleName-V1.02003-6-2编码规则QTD-School-Code-STD-V1.02003-4-22测试测试计划QTD-School-Test-Pla n-V1.02003-6-2测试用例QTD-School-Test-Case-V1.02003-6-2测试报告QTD-School-Test-Report-V1.02003-6-4提交运行产品QTD-School-Product-Exe-V1.02003-6-5验收报告QTD-School-Product-Report-V1.02003-6-6用户手册QTD-School-Product-Ma nual-V1.02003-6-64.1.3项目基线在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。表5基线名称/标识符基线包含的主要配置项预计建立时间需求需求规格说明书、用户DEMO2003418总体设计总体设计说明书、数据库设计2003411项目实现软件源代码、编码规则2003-6-2系统测试测试用例、测试报告2003-6-44.1.4配置项的版本管理配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实 际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时， 应及时做好基线的推进。对配置项的版本管理在不同分支具有不同的策略：（1）主干分支系统默认自动建立的物理分支一一主干分支（/main）,基线均以LABLE方 式出现在主干分支上。（2）私有分支如果多个开发工程师维护一个配置项时建议建立自己的私有分支。 配置管理 员对其基本不与管理，如个别私有空间上的版本树过于冗余， 将对其冗余版本进 行限制。（3）小组分支如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空 间，存放代码开发过程中的版本分支，由项目组内部控制。（4）集成分支集成测试时在主干分支的特定版本（由LABLE标志清晰）上建立集成分支， 测试工作在集成分支上完成。私有分支和小组分支均为可选，必要时建立。4.2变更管理变更管理的流程是：（1）由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复 审，以确定该请求是否为有效请求。典型的变更请求管理有需求变 更管理、缺陷追踪等。（2）配置管理者收到基线修改请求后，在配置库中生成与此配置项相关 的波及关系表。（3）配置管理者将基线波及关系表提交给 SCCB，由SCCB确定是否需 要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的 具体文件，并在波及分析表中标志出来。（4）配置管理者按照出库程序从配置库中取出需要修改的文件。（5）项目人员将修改后的文件提交给配置管理者。（6）配置管理者将修改后的配置项按入库程序放入配置库。（7）配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变 更记录表，并按入库程序放入配置库。4.3配置状态统计利用配置状态统计，可以记录和跟踪配置项的改变。 状态统计可用于评估项 目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被 执行。为跟踪工作产品基线，配置管理者需手机下列信息：基线类型工作产品名称配置项名称/标识符版本号更改日期/时间更改请求列表需要更改的配置项当前状态当前状态发生日期项目组每周提交配置项清单及其当前版本。配置管理人员每半个月提交变更请求的状态统计。