火龙果 整理
8.3 软件配置管理组织

8.3.1 软件配置管理组织构成 8.3.2 软件配置管理组织方针
火龙果 整理
8.3.1 软件配置管理组织构成
项目经理职责主要包括如下几项 :



制定和修改项目的组织结构和配置管理策略。 批准、发布配置管理计划。 决定项目起始基线和开发里程碑。 接受并审阅配置控制委员会的报告。

火龙果 整理
8.2.7 配置审计
配置审计的主要作用 : 是作为变更控制的补充 手段，来确保某一变更需求已被切实地执行和 实现。 在某些情况下，配置审计被作为正式的技术审 核的一部分，但当软件配置管理是一个正式的 活动时，配置审计活动就应该由软件质量管理 人员单独执行。
火龙果 整理
8.4.2 软件测试原则与策略
测试原则 :







应当把“尽早和不断地测试”作为开发人员的一个座右铭。 程序员和程序设计机构原则上不应该测试自己设计的程序。 制定严格的测试计划，并把测试时间安排得尽量宽松，不要希 望在极短的时间内完成一个高水平的测试。 在测试过程中，不仅要有确定的输入数据，而且也要确定预计 的输出数据。 在测试过程中，不仅要有合理的输入数据，而且也要有不合理 的输入数据。 在测试过程中，除了检查程序是否完成了预定的功能外，还要 测试程序是否还有不应该存在的功能和“后门”。 测试完成后，妥善保存一切测试过程文档和全部的测试用例 (数 据)，并作为软件和文档的一个组成部分，测试的重现性往往要 靠测试文档。 程序中存在错误的概率与该程序中已经发现的错误数一般是成 正比的。 重复测试一定要引起充分的重视，由于修改一个错误而引起更 多错误出现的现象并不少见。
软件测试的方法和技术是多种多样的。从测试是否针对系统 的内部结构和具体实现算法的角度看，通常可分为两类：白 盒测试法(结构测试)和黑盒测试法(功能测试)。


黑盒测试法一般称为功能测试或数据驱动测试，在测试 过程中，把系统看成是一个黑盒子，不考虑程序的内在 逻辑，而是只根据需求规格说明书的要求来检查程序的 功能是否符合它的功能需求说明。 白盒测试法又称为结构测试或逻辑驱动测试，在测试过 程中，允许测试人员对程序的内部逻辑结构及有关信息 来设计和选择测试用例，对程序的逻辑路径进行测试。
8.2.4 变更控制
变更提案所包括内容 :







项目名称 变更提案请求者，提案日期 变更内容 变更分析者，分析日期 被变更影响的部分 与变更相关的其他部分 对变更的评估 变更的优先级 变更的实现 变更的预测成本 变更提交给配置管理委员会(CCB)的日期 配置管理委员会决定，做出决定的日期 变更实现者，变更实现日期 提交给质量控制小组(QA)的日期 质量控制小组的决定 提交给项目经理的日期 项目经理的评价



火龙果 整理
8.2.3 版本管理
版本变迁演化 ：
Obj 1.3 Obj 1.0 Obj 1.1 Obj 1.2 Obj 1.4
Obj 2.0
Obj 1.1.1 图8.2 版本变迁演化
Obj 2.1 1 2 4 3 5
Obj 1.1.2 变体
火龙果 整理
火龙果 整理
8.4 软 件 测 试

8.4.1 8.4.2 8.4.3 8.4.4 8.4.5 8.4.6
软件测试的概念 软件测试原则与策略 软件测试完成的标准 软件测试步骤 软件测试工作流程 软件测试的自动化
火龙果 整理
8.4.1 软件测试的概念
火龙果 整理
8.3.1 软件配置管理组织构成
软件配置控制委员会SCCB主要负责以下工作 :


授权建立软件基线和标识配置项/配置单元。 代表项目经理和受到软件基线影响的所有小组 的利益。在 IT 项目管理中，受影响的组包括： 质量保证组、配置管理组、工程组(包括硬件工 程组、软件工程组)、系统测试组、合同管理组、 文档支持组等。 审查和审定对软件基线的更改。 审定由软件基线数据库中生产的产品和报告。
8.1 软件配置管理概念

8.1.1 软件配置及软件配置项 8.1.2 软件配置管理
火龙果 整理
8.1.1 软件配置及软件配置项





配置管理(Configuration Management，CM)的目的是建立和 维护在整个软件生命周期中软件项目产品的完整性和一致性。 CM的主要目标是使修改部分更容易被适应，并减少变化中所 花费的工作量。 配置管理在一个IT软件项目中是必须的，特别是对那种规模大 且周期较长的项目。软件配置管理是始终贯穿整个软件过程的 保护性活动。 软件配置管理的一系列活动被设计成为：标识变化、控制变化 和保证变化被适当地实现，以及向其他可能的人员报告变化的 一个有力和有效工具。 随着软件过程的进展，软件配置项(Software Configuration Items，SCI)迅速增长。一般，系统的软件规格说明了产生软 件项目计划和软件需求说明以及与硬件相关的文档资料，然后 在这些文档基础上又产生了其他的一些文档，从而形成了一个 信息层次。
火龙果 整理
8.2.2 确定配置标识
有效地配置管理，需要确定配置标识：
(1) 建 立 一 个 配 置 管 理 库 作 为 存 放 软 件 基 线 的 仓 库 。 基线是指已经通过正式评审和认可的标准，作为以后进一步开发的基础， 并且只有通过正式的更改控制规程才能进行更改的规程说明或者产品。当 软件基线生成时，就纳入软件基线库中。存取软件基线内容的工具和规程 就是配置管理库系统。 (2) 标 识 置 于 配 置 管 理 下 的 软 件 工 作 产 品 。 置于配置管理之下的软件工作产品，主要包括可交付给客户的软件产品(如 软件需求文档和代码等)，以及与这些软件产品等同的产品项或者生成这些 软件产品所需要的产品项(如编译程序、运行平台等)。所谓配置标识就是 为系统选择配置项，并在技术文档中记录其功能特征和物理特性。 (3) 根据文档化的规程，提出、记录、审查、批准和跟踪所有配置项 / 配置单元的更改要求和问题报告。 (4)根据文档化的规程记录配置项/ 配置单元的状态。该规程一般规定： 详细地记录配置管理行动，让每个成员都知道每个配置项/配置单元的内容 和状态，并且能够恢复以前的版本；保存每个配置项/配置单元的历史，并 维护其当前状态。

火龙果 整理
8.3.2 软件配置管理组织方针
方针主要包括如下内容 :



明确地分配每个项目的SCM责任。 在项目的在整个生命周期中实施SCM。 SCM为外部交付的软件产品、内部软件产品指定用于项目 内部的支持工具，如编译器、调试器等，以便实施配置 管理。 软件项目中，需要建立和使用一个仓库(如数据库)用于存 放配置项/配置单元和相关的 SCM记录。这个仓库的内容 将成为软件基线库。使用该仓库的工具和规程就是配置 管理库系统。置于配置管理之下的、并作为单独实体的 工作产品就成为配置项。通常，配置项分为若干配置组 件，配置组件分为若干配置单元。在一个硬/软件系统中， 可能把全部软件视为一个单独的配置项，也可能把软件 部分分为多个配置项。实际上，配置项/配置单元就是指 置于配置管理之下的元素。 定期审核软件基线和SCM活动。
8.2.4 变更控制
一般需要考虑以下因素 : 变更的预期效益如何？ 变更的成本如何？ 项目变更进程后，对项目成本的影响如何？ 变更对软件质量的影响如何？ 变更对项目资源分配的影响如何？ 变更可能会影响到项目后续的哪些阶段？ 变更会不会导致出现不稳定的风险？

火龙果 整理
火龙果 整理
8.1.2 软件配置管理
软件配置管理功能：
软件配置管理
配置标识
变更控制
配置状态统计
配置审核
图8.1 软件配置管理功能
火龙果 整理
8.2 软件配置管理概念

8.2.1 制定软件配置计划 8.2.2 确定配置标识 8.2.3 版本管理 8.2.4 变更控制 8.2.5 系统整合 8.2.6 状态报告 8.2.7 配置审计
火龙果 整理
8.2.5 系统整合
必须要考虑的问题有 : 是否所有组成系统的成分都包括在整合说明书 中？ 是否所有组成系统的成分都有合适的版本？ 是否所有的数据文件都是可以获得的？ 在组成系统的所有成分中，是否有数据文件命 名相同的？ 是否有合适版本的编辑器和其他工具？


制定配置管理计划中，必须定义以下问题：

根据已文档化的规程为每个软件项目制定软件配置管理 计划。这个规程一般规定： 在整个项目计划的初期制订 软件配置管理计划，并与整个项目计划并行；由相关小 组审查软件配置管理计划，管理和控制软件配置管理计 划。

将已文档化且经批准的软件配置管理计划作为执行配置 管理活动的基础。该计划应该包括：需要被执行的配置 管理活动、活动的日程、指派的责任和需要的资源(包括 人员、工具、计算机设施等)；配置管理的需求和由软件 开发小组和其他相关小组执行的配置管理活动一样。
火龙果 整理
8.2.1 制定软件配置计划
软件配置管理的主要流程如下：



项目经理和配置管理委员会(CCB)根据项目的开 发计划确定各个里程碑和开发 策略。 根据CCB的规划，制定详细的配置管理计划，交 CCB审核。 CCB通过配置管理计划后交项目经理批准，发布 实施。
火龙果 整理
8.2.1 制定软件配置计划
在已建立了要管理的文档后，配置管理计划必须定 义以下问题：



文档命名约定。 正式文档的关系(项目计划书、需求定义、设计 报告、测试报告都是正式文档)。 确定负责验证正式文档的人员。 确定负责提交配置管理计划的人员。