校务通管理系统软件项目配置管理计划案例

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

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

1. 引言

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

2.组织及职责

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

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

校务通管理系统软件项目配置管理计划案例

3.配置管理环境

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

3.1配置库目录结构

校务通管理系统软件项目配置管理计划案例

校务通管理系统软件项目配置管理计划案例

3.2用户及权限

4.配置管理活动

4.1 配置项标志

4.1.1 命名规范

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

公司:3个字符

项目:最长10个字符 类型:最长5个字符

编号:最长8位数字/字符 版本号:V m.n

QTD-School–RM–SRS-v1.0

图1:配置项命名规范

4.1.2 主要配置项

校务通管理系统软件项目配置管理计划案例

校务通管理系统软件项目配置管理计划案例

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.0>

? [注:以下提供的模板用于 Rational Unified Process。其中包括用方括号括起来并以蓝色斜体(样式=InfoBlue)显示的文本,它们用于向作者提供指导,在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式(样式=Body Text)。]

软件项目配置管理计划

修订历史记录

软件项目配置管理计划

Confidential

?<公司名称>, 1999 Page 2 of 6

软件项目配置管理计划

目录

1. 简介

1.1 目的 1.2 范围

1.3 定义、首字母缩写词和缩略语 1.4 参考资料 1.5

概述

2. 软件配置管理

2.1 组织、职责和接口

2.2 工具、环境和基础设施 3. 配置管理活动

3.1 配置标识

3.1.1 标识方法 3.1.2 项目基线 3.2 配置和变更控制

3.2.1 变更请求的处理和审批 3.2.2 变更控制委员会 (CCB) 3.3 配置状态统计

3.3.1 项目介质存储和发布进程 3.3.2 报告和审计 4. 里程碑 5. 培训和资源

6. 分包商和厂商软件控制

Confidential ?<公司名称>, 1999

4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 6 6 6

Page 3 of 6

软件项目配置管理计划

配置管理计划

1. 简介

? [配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、范围、定

义、首字母缩写词、缩略语、参考资料和概述。]

1.1 目的

? [阐明此配置管理计划的目的。]

1.2 范围

? [简要说明此配置管理计划的范围;它的相关模型,以及受到此文档影响的任何其他事物。]

1.3 定义、首字母缩写词和缩略语

? [本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。 这

些信息可以通过引用项目词汇表来提供。]

1.4 参考资料

? [本小节应完整列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告

号(如果适用)、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。]

1.5 概述

? [本小节应说明此配置管理计划中其他部分所包含的内容,并解释文档的组织方式。]

2. 软件配置管理

? [说明谁将负责执行 CM 工作流程中所述的各种配置管理 (CM) 活动。] 2.1 组织、职责和接口

2.2 工具、环境和基础设施

?

?

?

?

?

?

[说明在整个项目过程或产品生命周期中为实现 CM 功能而使用的计算环境和软件工具。 说明对整个项目过程或产品生命周期中生成的配置项进行版本控制时所需的工具和过程。 建立 CM 环境时所涉及的问题有: 产品数据量的预期大小 产品团队的分配 服务器和客户机的实际位置]

3.

3.1 配置管理活动 配置标识

3.1.1 标识方法

? [说明项目工件或产品工件的命名、标记和编号方法。标识方案中需包括硬件、系统软件、市售

?<公司名称>, 1999 Page 4 of 6 Confidential

软件项目配置管理计划

(COTS) 产品以及产品目录结构中所列的所有应用程序开发工件,例如计划、模型、构件、测试软件、结果与数据、可执行文件等。] 3.1.2 项目基线

?

? [基线提供一项正式标准,随后的工作都基于此标准,并且只有经过授权后才能对此标准进行变更。 说明要在项目或产品生命周期中的哪些时间点处建立基线。最常用的基线在先启阶段、精化阶

段、构建阶段和产品化阶段结束时建立。也可以在不同阶段中的各次迭代结束时生成基线,甚至可以更为频繁。

说明由谁来对基线授权,以及基线中包含的内容。] ?

3.2 配置和变更控制

3.2.1 变更请求的处理和审批

? [说明提交、复审和处理问题及变更时所遵循的流程。]

3.2.2 变更控制委员会 (CCB)

?

3.3 [说明 CCB 在处理和审批变更请求时所遵循的成员资格标准和过程。] 配置状态统计

3.3.1 项目介质存储和发布进程

?

? [说明保留策略、备份计划、事故处理计划和恢复计划。还应说明介质的保留方式:联机、脱机、介质类型和格式。 发布过程应说明此发布版的内容、它所针对的对象,以及是否有已知的问题和安装说明。]

3.3.2 报告和审计

?

? [说明所需报告和配置审计的内容、格式和目的。 报告用于在项目和产品生命周期中的任意给定时间对“产品质量”进行评估。如果根据变更请

求来报告缺陷,就可以提供一些有用的质量指标。因此,应提醒管理人员和开发人员多注意特别关键的开发领域。缺陷通常按其严重程度(高、中和低)分类。可以依据以下各项来报告缺陷:

龄期(基于时间的报告):各种缺陷已经打开了多久?在生命周期中,从发现缺陷到修复缺陷有多长的“滞后时间”?

分布(基于计数的报告):在按照拥有者、优先级或修复状态划分的不同类别中各有多少个缺陷? ? ?

Confidential

?<公司名称>, 1999 Page 5 of 6

软件项目配置管理计划

? 趋势(与时间和计数有关的报告):在一段时间内发现并修复的缺陷累计有多少个?缺陷发现率和修复率是多少?就打开的缺陷和关闭的缺陷而言,它们之间的“质量差距”有多大?解决缺陷所用的平均时间为多长?]

4. 里程碑

? [确定与项目或产品 CM 工作相关的内部里程碑和客户里程碑。本节应该包括有关何时更新 CM

计划本身的详细信息。]

5. 培训和资源

? [说明实施指定的 CM 活动时所需的软件工具、人员和培训。]

6. 分包商和厂商软件控制

? [说明将如何并入在项目环境外部开发的软件。]

Confidential ?<公司名称>, 1999

Page 6 of 6

相关推荐