软件项目配置管理计划案例

本案例选自《软件项目管理案例教程》（韩万江，机械工业出版社）一书，项目案例为《校务通管理系统》，该项目的配置管理计划如下：

1.  引言

包括目的、缩写词和参考资料，具体内容略。

2．组织及职责

配置管理的角色和职责见表1。

表1：配置管理角色职责表

3.配置管理环境

由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。

3.1配置库目录结构

表2：配置库的目录结构

3.2用户及权限

表3：配置库的用户权限

4．配置管理活动

4.1 配置项标志

4.1.1 命名规范

本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。

图1：配置项命名规范

4.1.2 主要配置项

表4：配置项列表

4.1.3 项目基线

在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。

表5

4.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 配置状态统计

利用配置状态统计，可以记录和跟踪配置项的改变。状态统计可用于评估项目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被执行。为跟踪工作产品基线，配置管理者需手机下列信息：

● 基线类型                         ● 工作产品名称

● 配置项名称/标识符                ● 版本号

● 更改日期/时间                    ● 更改请求列表

● 需要更改的配置项                 ● 当前状态

● 当前状态发生日期

项目组每周提交配置项清单及其当前版本。

配置管理人员每半个月提交变更请求的状态统计。

      

第二篇：软件配置管理计划

水利工程建设注册造价工程师继续教育系统

软件配置管理计划

中水环球（北京）科技有限公司

二零壹零年伍月份

目 录

1 引言. 1

1.1 目的. 1

1.2 定义. 1

1.3 参考资料. 1

2 管理. 2

2.1 机构. 2

2.2任务. 2

2.3职责. 3

2.4接口控制. 4

2.5 软件配置管理计划的实现. 6

2.6 适用的标准、条例和约定. 7

3 软件配置管理活动. 7

3.1 配置标识. 7

3.1.1 文档. 7

3.1.2 程序. 8

3.1.3各类基线. 8

3.2 配置控制. 8

3.3 配置状态审计. 9

3.4配置的检查和评审. 9

4 工具、技术和方法  是否有? 10

5.记录的维护和保存. 11

1 引言 

1.1 目的

本计划的目的在于对所开发的水利工程建设注册造价工程师继续教育系统软件规定各种必要的配置管理条款，以保证所交付的水利工程建设注册造价工程师继续教育系统软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。

软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。

1.2 定义

本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。

1.3 参考资料

GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
GB/T 12504 计算机软件质量保证计划规范
GB/T 12505 计算机软件配置管理计划规范

《计算机软件工程规范国家标准汇编2000》

国家、水利部、信息产业部相关标准

相关国际标准和水利行业标准

2 管理

2.1 机构

在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。 软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。

2.2任务

在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要修改前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第3.2条中详细规定。

2.3职责

在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下：

A． 组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；

B． 软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范；

C． 项目的专职配置管理人员负责检查配置更改时的质量保证措施；

D． 各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

E． 用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况；

F． 项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。

2.4接口控制

对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。整个软件项目及其各子系统都必须进行严格的控制。在工程化软件系统中，主要的接口有如下五类：

A． 用户界面：用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。同时还指实现这些操作约定的物理部件的功能与性能特性。

B． 系统内部接口：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。

C． 标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。

D． 设备接口：设备接口是指各子系统与各种设备（包括终端和其他各种输入/输出设备）之间的连接约定。

E． 软件接口：软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。 以上五类接口是一个软件系统各项配置的重要组成部分。对接口修改进行合理的控制，是软件配置管理的重要任务之一。这五类接口都涉及到水利工程建设注册造价工程师继续教育软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，都必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定（可参阅表1）。

表1 两类修改的审批程序

         

2.5 软件配置管理计划的实现

在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑：

A． 建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组。

 B． 建立各阶段的配置基线：随着水利工程建设注册造价工程师继续教育软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的《水利工程建设注册造价工程师继续教育软件需求规格说明书》的批准，建立起指派基线；随着水利工程建设注册造价工程师继续教育工程化软件系统的集成与系统测试的完成，建立起产品基线。

C． 建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。

2.6 适用的标准、条例和约定

除应奠定本计划第1.3条中指出的参考资料以及本计划中的其他章条所作的各项规定外，还应该遵守如下标准、条例和约定：

A． 软件开发库、软件受控库与软件产品库的操作规程与管理规程；

B． 系统、子系统、模块和程序单元的命名约定；

C． 文档和测试用例的命名和管理规程。

命名约定、操作规程与管理规程应由该项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第3.2条中规定。

3 软件配置管理活动

3.1 配置标识

3.1.1 文档

所有为本项目编制的文档，都要符合GB 8567中的规定。造价工程师继续教育软件系统及其所属的各个子系统所编写的文档数目，可根据GB 8567的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。

3.1.2 程序

所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。

3.1.3各类基线

所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。

3.2 配置控制

软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下：

A． 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为A类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为B类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。

B． 修改审批程序：上述两类修改的审批程序如表1。

C． 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。

3.3 配置状态审计

利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。 注：本计划在此处应给出软件问题报告单与软件修改报告单的具体格式，并作出必要的说明。鉴于本计划拟采用附录B（参考件）中建议的格式，因而这两个报告单的格式及其说明可参阅附录B。

3.4配置的检查和评审

项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。

在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由该软件质量计划规定。配置修改的审批程序按本计划第3.2条的规定处理（见表1）。

4 工具、技术和方法  是否有?

在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。有吗？

A． 软件测试工具：它支持用C语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖C0和分支覆盖率C1的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。

B． 软件配置管理工具：它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

C． 文档辅助生成工具与图形编辑工具：它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与软件文档编制大纲适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质量。

有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。

5.记录的维护和保存

在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。

A． 基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每6个月拷贝一次，以免意外损伤与自然老化。

B． 上述这些软件的文档也应送入软盘或磁带，至少必须一式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔6个月拷贝一次，以免意外损伤与自然老化。

C． 软件产品的源程序、测试数据、测试报告及其他有关文档，除了按A、B规定妥善存放外，要在项目结束后再保存2年，或在条件成熟时转交给这些软件产品的生产系统。

注：具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。

D． 上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。

E． 鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放5-7年，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。