SP302-09软件项目配置管理计划

一个软件的系统系列
5
配置管理的必要性配置管理的必要性-2
如果没有有效的配置管理规程，就可能浪费精 力修改一个错误的系统版本或发放一个错误版 本给用户，甚至不知道系统源代码存放在什么 地方。
ቤተ መጻሕፍቲ ባይዱ
例如，配置管理不善，会导致软件测试陷 例如，配置管理不善， 泥潭” 入“泥潭”：
缺陷只能在测试环境出现，但是在开发环境中 无法重现； 已经修复的缺陷在测试时又重现； 发布程序在内部确认测试中测试通过，但是发 布时却发生系统运行失效的情况。
课件 SP302
软件工程项目管理
第9章 软件项目配置管理计划
北方民族大学 计算机科学与工程学院 陶铮 2009年9月 年 月
1
开头的话
回顾软件质量计划—— 回顾软件质量计划—— ——制定质量计划的依据是： ——制定质量计划的依据是 制定质量计划的依据是：
所谓软件质量管理主要是监控项目的交付物和 生产交付物的执行过程，目的是确保它们都是 符合相关标准的：这叫做质量保证过程； 同时，也要按照正确方法来排除那些不合格项 能够排除：这叫做质量控制过程。
○ 命名规范，适用于过程文档、生存期中各阶段的计
划、需求、设计、代码、测试、手册等文件。
○ 项目文件命名规范由5个字段组成，从左到右依次为：
公司、项目、类型、编号和版本号，如图9A-1所示。 这些字段用一横线（-）分隔。
17
图9A-1文档命名规范
18
类型 技术合同 计划 需求
主要配置项 控制项 主要配置项/控制项 配置项 《合同》 合同》 SOW 项目计划》 《项目计划》 质量保证计划》 《质量保证计划》 配置管理计划》 《配置管理计划》 需求规格说明书》 《需求规格说明书》 用户DEMO 用户 总体设计说明书》 《总体设计说明书》 数据库设计》 《数据库设计》 详细设计说明书》 《详细设计说明书》 设计术语及规范》 《设计术语及规范》 源程序 编码规则 测试计划》 《测试计划》 测试用例》 《测试用例》 测试报告》 《测试报告》 运行产品 验收报告》 《验收报告》 用户手册》 《用户手册》
21
基线配置项——可能包括所有的设计文档 基线配置项——可能包括所有的设计文档 和源程序等 非基线配置项——可能包括项目的各类计 非基线配置项——可能包括项目的各类计 划和报告等。 划和报告等。 注意：基线是一个或者多个配置项的集 注意： 因此它的形成往往需要一定的过程。 合，因此它的形成往往需要一定的过程。
内容和状态已经通过技术的复审，并在生存 期的某一阶段被接受了。
22
关于配置项复审
目标是验证配置项被接受之前的正确性和完整 性 一旦配置项经过复审，并正式成为一个初始基 线，那么该基线就可以作为项目生存期下面开 发活动的起始点。
23
基线的图示（1） 总体情况
思考：怎样得到基线4?
基线3 基线4 基线2
29
有变化才有产品的发布
30
9.2.3 配置控制委员会
配置控制委员会（ 配置控制委员会（Software configuration Control Board，SCCB） Board，SCCB）
可以是一个人也可以是一个小组，基本是由项目经 理及其相关人员组成。
SCCB承担变更控制的所有责任， SCCB承担变更控制的所有责任，具体责任 承担变更控制的所有责任 如下： 如下：
2
什么是交付物？交付物怎么管理？ 什么是交付物？交付物怎么管理？ 我们已经知道：质量管理对象， 我们已经知道：质量管理对象，是针对项 目过程中那些对最终产品起着重要的作用 的中间产品——这就是交付物 这就是交付物（ 的中间产品——这就是交付物（最终交付物 的前身），主要是： ），主要是 的前身），主要是：
将系统测试过程中发现的错误编写成文档，交给系统开发人员。他们在这 个组件的后续版本中修改这些错误。
11
9.1.2 配置管理的目标
配置管理的目标——软件配置的完整性和可追 配置管理的目标——软件配置的完整性和可追 溯性。 溯性。
达到这个目标，需要一个过程——控制某个配置项 及其后续变更，记录并报告配置项的状态以及变更 要求。
设计
编程 测试
提交
19
再看配置管理概念图
项目经理 关注的信 息集合
20
9.2.2 基线
基线（Basic Line）： Line）： 基线（
“已经正式通过复审和批准的某规约或产品，它 因此可作为进一步开发的基础，并且只能通过 正式的变化控制过程改变。” ——IEEE对基线的定义
为了管理变更，就要有所区别——所有需加 为了管理变更，就要有所区别——所有需加 基线配置项和 以控制的配置项分为基线配置项 以控制的配置项分为基线配置项和非基线 配置项两类 基线配置项最重要。 两类。 配置项两类。基线配置项最重要。
通过编译和连接这些组件使之形成一个完整的系统，这样系统的新版本就 建立起来了。
3.提交测试 3.提交测试
新版本的系统被提交到测试团队，由他们来完成预先确定好的一组系统测 试。 注意：在这期间，开发人员仍然在处理他们的组件，或增加组件的功能， 或修改测试中发现的错误。
4.测试后的工作 4.测试后的工作
基线1
图9.4基线图示 图9.4基线图示（转向）
24
基线的图示（2）：细节情况
《如何规划一个 如何规划一个UCM工程 工程》 如何规划一个 工程 /developerworks/cn/rational/r-sunzq/
25
基线的图示（3）产品情况 ——对基线图示（2）的解释
9
既然软件配置是管理大家做的软件和文档， 既然软件配置是管理大家做的软件和文档， 所以需要系统化、集成化管理——难点就 所以需要系统化、集成化管理——难点就 在这里！ 在这里！
统一标识在给定时间点上软件的配置； 系统地控制对配置的更改； 不间断地维护整个软件生存周期中的配置的完 整性和可追溯性。
10
28
基线不是不让变化！
怎样做到这一点？
变化意味着两个连续的版本之间的不同（如从配置 变化意味着两个连续的版本之间的不同（ 项中添加和去掉的线和图）。 项中添加和去掉的线和图）。
不能简单地认为变化就是改变。这里的关键词是“不同”。
基线是否可以改变，要看变化本身的特征 基线是否可以改变，
通常，修复一个系统错误或添加一个功能到系统上，要求 对几个配置项做变化——形成变化集。 如果两个变化集不重叠（ 如果两个变化集不重叠（即，如果它们用于不同的且无 关的配置项集合时）， ），它们能够以任意的顺序应用到同 关的配置项集合时），它们能够以任意的顺序应用到同 样的基线上， 样的基线上，这为选择配置的开发者提供了更多的灵活性。
什么是配置项？ 什么是配置项？ 配置管理的子目标
标识变更。 控制变更。 确保变更正确实现。 向有关的人员报告变更。
12
配置管理是一个复杂的信息管理
软件配置管理的主要思想和具体内容在 于版本控制。 于版本控制。
13
9.1.3 配置管理在软件开发中的作用
配置管理是对系统变更所做的管理。在维护一个系统时， 配置管理是对系统变更所做的管理。在维护一个系统时， 配置管理团队的作用是保证变更是在受控状态下完成的。 配置管理团队的作用是保证变更是在受控状态下完成的。
示例：每日构建——配置管理
1.开发机构规定好系统组件的提交时间 1.开发机构规定好系统组件的提交时间
比如下午2点——此时，如果开发者正在写这些组件的新版本，那么他们 必须在规定时间之前提交。组件可能不完备，但是必须具备一些基本的、 可以测试的功能。
2.规定代码编译和新版本软件的建立 2.规定代码编译和新版本软件的建立
版本问题——从需求描述开始： 版本问题——从需求描述开始： 从需求描述开始
系统需求在软件开发和使用的过程中总是不断地变 化着，我们不得不把这些需求合并到新的系统版本 中配置——对选定的软件工作产品的新的描述。
4
配置管理的必要性
进化中的系统之所以需要管理，是因为系统在进化时会产生 进化中的系统之所以需要管理， 许多不同的版本，这些版本包含了变更建议、错误修正以及 许多不同的版本，这些版本包含了变更建议、 对不同硬件和操作系统的适应等诸多内容。 对不同硬件和操作系统的适应等诸多内容。 对于可能同时开发、同期使用的几个版本，需要跟踪它们， 对于可能同时开发、同期使用的几个版本，需要跟踪它们， 可能同时开发 它们 明确已经实现的变更以及这些变更是怎样包含在软件产品中 明确已经实现的变更以及这些变更是怎样包含在软件产品中 的。
1. 需求规格、设计说明书 2. 源程序 3. 测试计划 4. 测试结果等。
3
交付物的演变情况——试想…
五个人一起编程开发，各有10个模块任务。一 五个人一起编程开发，各有10个模块任务。 个模块任务 个人一天一个模块，10天完成 天完成——问 个人一天一个模块，10天完成——问：
到第10天，每个人的10个模块有多少个版本? 10个人开发的100个模块共有多少个版本？ 集成这100个模块有多少个集成方案？ 每个集成方案有多少个版本？
33
34
9.3.2 配置管理环境的建立
配置管理环境——配置管理库，简称配置库。 配置管理环境——配置管理库，简称配置库。 配置管理库
是用于更好地进行软件配置管理的系统环境。
配置库存储内容——所有配置项的集合和配 配置库存储内容——所有配置项的集合和配 置项修改状态记录的集合
14
软件配置管理是软件项目管理中的一种非常有效 和现实的技术，它能非常有效地适应软件开发需 求。 版本控制不等于配置管理，版本控制，并不能解 决开发管理中的深层问题。 项目管理（需求、计划、进度、里程碑、变 更…） 对开发者工作空间的管理（资源、任务分配、 绩效…）
15
9.2 配置管理的相关概念
16
9.2.1 配置项