第 8 章 IT软件项目配置管理 （2次、4课时）.

Presentation on theme: "第 8 章 IT软件项目配置管理 （2次、4课时）."— Presentation transcript:

1 第 8 章 IT软件项目配置管理 （2次、4课时）

2 第8章 IT软件项目配置管理 8.1 软件配置管理概念 8.2 软件配置管理基本活动 8.3 软件配置管理组织 8.4 软件测试
8.1 软件配置管理概念 8.2 软件配置管理基本活动 8.3 软件配置管理组织 8.4 软件测试 8.5 配置管理工具 8.6 思考题

3 8.1 软件配置管理概念 软件配置及软件配置项 软件配置管理

4 8.1.1 软件配置及软件配置项 配置管理(Configuration Management，CM)的目的是建立和维护在整个软件生命周期中软件项目产品的完整性和一致性。 CM的主要目标是使修改部分更容易被适应，并减少变化中所花费的工作量。 配置管理在一个IT软件项目中是必须的，特别是对那种规模大且周期较长的项目。软件配置管理是始终贯穿整个软件过程的保护性活动。 软件配置管理的一系列活动被设计成为：标识变化、控制变化和保证变化被适当地实现，以及向其他可能的人员报告变化的一个有力和有效工具。 随着软件过程的进展，软件配置项(Software Configuration Items，SCI)迅速增长。一般，系统的软件规格说明了产生软件项目计划和软件需求说明以及与硬件相关的文档资料，然后在这些文档基础上又产生了其他的一些文档，从而形成了一个信息层次。

5 软件配置管理 软件配置管理活动： 软件配置管理(Software Configuration Management，SCM)是软件过程的关键要素，是开发和维护各个阶段管理软件演进过程的一种方法和规程。 软件配置管理使得整个软件产品的演进过程处于一种可视的状态。 软件配置管理作为CMM第2级上的一个关键域(Key Practice Area，KPA)，在整个软件的开发活动中占有很重要的位置。 及多少识别和修改，多少错误仍然未被发现等；也可以用于对费用和进度参数的预测。

6 软件配置管理 软件配置管理功能： 软件配置管理 配置标识 变更控制 配置状态统计 配置审核 图8.1 软件配置管理功能

7 8.2 软件配置管理概念 8.2.1 制定软件配置计划 8.2.2 确定配置标识 8.2.3 版本管理 8.2.4 变更控制
8.2 软件配置管理概念 制定软件配置计划 确定配置标识 版本管理 变更控制 系统整合 状态报告 配置审计

8 8.2.1 制定软件配置计划 软件配置管理的主要流程如下： 项目经理和配置管理委员会(CCB)根据项目的开发计划确定各个里程碑和开发 策略。
制定软件配置计划 软件配置管理的主要流程如下： 项目经理和配置管理委员会(CCB)根据项目的开发计划确定各个里程碑和开发 策略。 根据CCB的规划，制定详细的配置管理计划，交CCB审核。 CCB通过配置管理计划后交项目经理批准，发布实施。

9 8.2.1 制定软件配置计划 在已建立了要管理的文档后，配置管理计划必须定义以下问题： 文档命名约定。
制定软件配置计划 在已建立了要管理的文档后，配置管理计划必须定义以下问题： 文档命名约定。 正式文档的关系(项目计划书、需求定义、设计报告、测试报告都是正式文档)。 确定负责验证正式文档的人员。 确定负责提交配置管理计划的人员。

10 8.2.1 制定软件配置计划 制定配置管理计划中，必须定义以下问题：
制定软件配置计划 制定配置管理计划中，必须定义以下问题： 根据已文档化的规程为每个软件项目制定软件配置管理计划。这个规程一般规定： 在整个项目计划的初期制订软件配置管理计划，并与整个项目计划并行；由相关小组审查软件配置管理计划，管理和控制软件配置管理计划。 将已文档化且经批准的软件配置管理计划作为执行配置管理活动的基础。该计划应该包括：需要被执行的配置管理活动、活动的日程、指派的责任和需要的资源(包括人员、工具、计算机设施等)；配置管理的需求和由软件开发小组和其他相关小组执行的配置管理活动一样。

11 8.2.2 确定配置标识 有效地配置管理，需要确定配置标识：
确定配置标识 有效地配置管理，需要确定配置标识： (1) 建立一个配置管理库作为存放软件基线的仓库。 基线是指已经通过正式评审和认可的标准，作为以后进一步开发的基础，并且只有通过正式的更改控制规程才能进行更改的规程说明或者产品。当软件基线生成时，就纳入软件基线库中。存取软件基线内容的工具和规程就是配置管理库系统。 (2) 标识置于配置管理下的软件工作产品。 置于配置管理之下的软件工作产品，主要包括可交付给客户的软件产品(如软件需求文档和代码等)，以及与这些软件产品等同的产品项或者生成这些软件产品所需要的产品项(如编译程序、运行平台等)。所谓配置标识就是为系统选择配置项，并在技术文档中记录其功能特征和物理特性。 (3) 根据文档化的规程，提出、记录、审查、批准和跟踪所有配置项/配置单元的更改要求和问题报告。 (4) 根据文档化的规程记录配置项/配置单元的状态。该规程一般规定：详细地记录配置管理行动，让每个成员都知道每个配置项/配置单元的内容和状态，并且能够恢复以前的版本；保存每个配置项/配置单元的历史，并维护其当前状态。

12 8.2.3 版本管理 版本变迁演化 ： Obj 1.0 Obj 1.1 Obj 1.2 Obj 1.4 Obj 2.0 Obj 2.1
版本管理 版本变迁演化 ： Obj 1.0 Obj 1.1 Obj 1.2 Obj 1.4 Obj 2.0 Obj 2.1 Obj 1.1.1 Obj 1.1.2 Obj 1.3 图8.2 版本变迁演化 1 2 3 4 5 变体

13 8.2.4 变更控制 一般需要考虑以下因素 : 变更的预期效益如何？ 变更的成本如何？ 项目变更进程后，对项目成本的影响如何？
变更控制 一般需要考虑以下因素 : 变更的预期效益如何？ 变更的成本如何？ 项目变更进程后，对项目成本的影响如何？ 变更对软件质量的影响如何？ 变更对项目资源分配的影响如何？ 变更可能会影响到项目后续的哪些阶段？ 变更会不会导致出现不稳定的风险？

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

15 8.2.5 系统整合 必须要考虑的问题有 : 是否所有组成系统的成分都包括在整合说明书中？ 是否所有组成系统的成分都有合适的版本？
系统整合 必须要考虑的问题有 : 是否所有组成系统的成分都包括在整合说明书中？ 是否所有组成系统的成分都有合适的版本？ 是否所有的数据文件都是可以获得的？ 在组成系统的所有成分中，是否有数据文件命名相同的？ 是否有合适版本的编辑器和其他工具？

16 8.2.5 系统整合 可执行文件 系统整合者 UNIX/NT/OS2 逻辑结构到物理 结构的映射 整合工具 文件1 文件2 …… 文件N
系统整合 可执行文件 系统整合者 UNIX/NT/OS2 逻辑结构到物理 结构的映射 整合工具 文件1 文件2 …… 文件N 系统逻辑描述 图8.4 系统整合逻辑过程

17 8.2.6 状态报告 主要内容 : 配置库结构和相关说明。 开发起始基线的构成。 当前基线位置及状态。 各基线配置项集成、分布的情况。
状态报告 主要内容 : 配置库结构和相关说明。 开发起始基线的构成。 当前基线位置及状态。 各基线配置项集成、分布的情况。 各私有开发分支类型的分布情况。 关键元素的版本演进记录。 其他应予报告的事项。

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

19 8.3 软件配置管理组织 软件配置管理组织构成 软件配置管理组织方针

20 8.3.1 软件配置管理组织构成 项目经理职责主要包括如下几项 : 制定和修改项目的组织结构和配置管理策略。 批准、发布配置管理计划。
软件配置管理组织构成 项目经理职责主要包括如下几项 : 制定和修改项目的组织结构和配置管理策略。 批准、发布配置管理计划。 决定项目起始基线和开发里程碑。 接受并审阅配置控制委员会的报告。

21 8.3.1 软件配置管理组织构成 软件配置控制委员会SCCB主要负责以下工作 : 授权建立软件基线和标识配置项/配置单元。
软件配置管理组织构成 软件配置控制委员会SCCB主要负责以下工作 : 授权建立软件基线和标识配置项/配置单元。 代表项目经理和受到软件基线影响的所有小组的利益。在IT项目管理中，受影响的组包括：质量保证组、配置管理组、工程组(包括硬件工程组、软件工程组)、系统测试组、合同管理组、文档支持组等。 审查和审定对软件基线的更改。 审定由软件基线数据库中生产的产品和报告。

22 8.3.1 软件配置管理组织构成 软件配置管理小组SCM负责协调和完成以下的工作: 创建和管理项目的软件基线库。
软件配置管理组织构成 软件配置管理小组SCM负责协调和完成以下的工作: 创建和管理项目的软件基线库。 制定、维护和发布SCM计划、标准和规程。 标识置于配置管理下的软件工作产品集合。 管理软件基线的库的使用。 更新软件基线。 生成基于软件基线的产品。 记录SCM活动。 生成和发布SCM报告。

23 8.3.2 软件配置管理组织方针 方针主要包括如下内容 : 明确地分配每个项目的SCM责任。 在项目的在整个生命周期中实施SCM。
软件配置管理组织方针 方针主要包括如下内容 : 明确地分配每个项目的SCM责任。 在项目的在整个生命周期中实施SCM。 SCM为外部交付的软件产品、内部软件产品指定用于项目内部的支持工具，如编译器、调试器等，以便实施配置管理。 软件项目中，需要建立和使用一个仓库(如数据库)用于存放配置项/配置单元和相关的SCM记录。这个仓库的内容将成为软件基线库。使用该仓库的工具和规程就是配置管理库系统。置于配置管理之下的、并作为单独实体的工作产品就成为配置项。通常，配置项分为若干配置组件，配置组件分为若干配置单元。在一个硬/软件系统中，可能把全部软件视为一个单独的配置项，也可能把软件部分分为多个配置项。实际上，配置项/配置单元就是指置于配置管理之下的元素。 定期审核软件基线和SCM活动。

24 8.4 软 件 测 试 8.4.1 软件测试的概念 8.4.2 软件测试原则与策略 8.4.3 软件测试完成的标准 8.4.4 软件测试步骤
8.4 软 件 测 试 软件测试的概念 软件测试原则与策略 软件测试完成的标准 软件测试步骤 软件测试工作流程 软件测试的自动化

25 软件测试的概念 软件测试的方法和技术是多种多样的。从测试是否针对系统的内部结构和具体实现算法的角度看，通常可分为两类：白盒测试法(结构测试)和黑盒测试法(功能测试)。 黑盒测试法一般称为功能测试或数据驱动测试，在测试过程中，把系统看成是一个黑盒子，不考虑程序的内在逻辑，而是只根据需求规格说明书的要求来检查程序的功能是否符合它的功能需求说明。 白盒测试法又称为结构测试或逻辑驱动测试，在测试过程中，允许测试人员对程序的内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。

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

27 8.4.2 软件测试原则与策略 测试策略 : C U 软件项目 S R D I V ST 需求分析 系统设计 编码 单元测试 集成测试
软件测试原则与策略 测试策略 : C U 软件项目 S R D I V ST 需求分析 系统设计 编码 单元测试 集成测试 确认测试 系统测试 图8.5 软件测试的策略

28 8.4.3 软件测试完成的标准 搞清楚完成的标准,以及软件故障模型: f(t)=(1/p)㏑(l0pt+1) 每小时错误数l0
软件测试完成的标准 搞清楚完成的标准,以及软件故障模型: f(t)=(1/p)㏑(l0pt+1) 测试时间 t 预期的错误密度，l(t) 在测试过程中收集的实测数据 图8.6 错误密度与测试时间的函数关系 每小时错误数l0

29 8.4.4 软件测试步骤 开发是自顶向下的,测试是自底向上的,测试内容有: 1. 单元测试 2. 集成测试 3. 确认测试 4. 系统测试
软件测试步骤 开发是自顶向下的,测试是自底向上的,测试内容有: 1. 单元测试 2. 集成测试 3. 确认测试 4. 系统测试 5. Alpha和Beta测试

30 8.4.5 软件测试工作流程 总过程： 立项阶段 需求分析阶段 设计阶段 编码阶段 单元测试阶段 集成测试阶段 系统测试阶段 验收测试阶段
软件测试工作流程 总过程： 立项阶段 需求分析阶段 设计阶段 编码阶段 单元测试阶段 集成测试阶段 系统测试阶段 验收测试阶段 结项阶段 图8.8 软件测试总的过程

31 8.4.5 软件测试工作流程 需求阶段的测试工作流程 : 需求阶段工作培训 变更需求 编写用户需求 总体测试方案 需求评审 需求说明书
软件测试工作流程 需求阶段的测试工作流程 : 需求阶段工作培训 编写用户需求 需求评审 需求变更 进入下一阶段 变更需求 图8.9 需求阶段的测试工作流程 需求说明书 需求变更记录 系统测试方案 总体测试方案

32 8.4.5 软件测试工作流程 设计编码阶段的测试工作流程 : 需求相关文档 变更设计 集成测试计划 概要设计 设计方案评审 详细设计
软件测试工作流程 设计编码阶段的测试工作流程 : 图8.10 设计、编码阶段的测试工作流程 概要设计 集成测试计划 设计方案评审 详细设计 单元测试方案 系统测试验证标准 单元测试报告 进入下阶段 变更设计 需求相关文档 详细设计方案评审 编码 单元测试 修改

33 8.4.5 软件测试工作流程 集成测试、系统验收测试阶段工作流程 : 图8.11 集成测试、系统测试阶段工作流程 集成测试 集成测试计划
软件测试工作流程 集成测试、系统验收测试阶段工作流程 : 图8.11 集成测试、系统测试阶段工作流程 集成测试 集成测试计划 测试评估 系统测试 产品化工作报告 系统测试方案 系统测试报告 测试工作结束 产品化工作 验收测试 上一阶段 质量合格证书

34 8.4.6 软件测试的自动化 自动化的测试操作主要包括： 测试个案的生成，包括测试输入、标准输出、测试操作指令等。
软件测试的自动化 自动化的测试操作主要包括： 测试个案的生成，包括测试输入、标准输出、测试操作指令等。 测试的执行写控制，包括单机与网络分布运行、夜间及假日运行、测试个案调用控制、测试对象、范围、版本控制等。 测试结果与标准输出的对比。 不吻合的测试结果的分析、记录、分类和通报。 总测试状况的统计，报表的产生。

35 8.5 配置管理工具 配置管理工具选择 配置管理工具简介

36 配置管理工具选择 可以综合考虑以下因素 ： 首先是经费。市场上现有的商业配置管理工具，大多价格不菲。到底是选用开放源代码的自由软件、还是采购商业软件，如果采购商业软件，选择哪个档次的软件，这些问题的答案，都取决于可以获得的经费量。 工具的市场占有率。大家都选择的东西通常会是比较好的，而且市场占有率高也通常表明该企业经营状况会好一些。 工具本身的特性，如稳定性、易用性、安全性、扩展能力等。在投资前应当对工具进行仔细的试用和评估。比较容易忽略的是工具的扩展能力，在几个、十几个人的团队中部署工具是合适的，但当规模扩大到几百人在依赖这个工具时，这个工具还能不能提供支持。 厂商支持能力。工具使用过程中一定会出现一些问题，有些是因为使用不当引起的，但也有些是工具本身的毛病。这样就会影响到开发团队的工作进度。而如果厂商具备服务支持，那么就能随时找到厂商的专业技术人员帮助解决问题。

37 8.5.2 配置管理工具简介 1. Rational ClearCase介绍 ： 提供版本控制、工作区管理、Build管理及流程管理。
配置管理工具简介 1. Rational ClearCase介绍 ： 提供版本控制、工作区管理、Build管理及流程管理。 提供分布式、跨区域的并行开发模式。 可以与Rational 的全部线产品、Microsoft的Developer Studio、Powerbuilder、Oracle Developer 2000等集成。 提供离线模式，让用户可以在家工作，然后合并到开发流程中。 提供深入的build内核。 对执行文件和目录进行自动图形化合并，文件间的差异明显展现出来。 完整控制程序源代码、二进制代码、可执行码、测试项目、文档以及用户自定义的对象。 支持多平台，适合各种开发环境。

38 8.5.2 配置管理工具简介 2. Rational ClearQuest介绍 ： 提供用户弹性的变更需求管理环境。
配置管理工具简介 2. Rational ClearQuest介绍 ： 提供用户弹性的变更需求管理环境。 用户可根据开发工作流程和变更需求周期，通过图示工具定义处理流程。 提供预设的变更需求管理流程，用户可直接使用或进行特殊设置。 提供强大的图表功能，用户可深入分析开发现状。 有浏览器界面，可让远端的用户进行访问。 与业界标准的数据库和报表生成器集成。 与Rational的软件管理工具 ClearCase完全集成，让用户充分掌握变更需求情况。 支持数据库MS ACCESS和SQL SERVER。 优异的系统扩展性，提供将数据从ACCESS转移到SQL SERVER的功能。

39 8.6 思 考 题 参见教材148页