为了开发高质量的软件,从计划阶段开始,不但需要明确软件的功能,还要明确软件应 达到什么样的质量标准,即制定软件的质量目标。为了达到这个目标,在开发过程中的各个 阶段进行检查和评价。在做质量评价时,需要有对质量进行度量的准则和方法,但更重要的 是,需要有在软件生存期中如何使用这些准则和方法的质量保证步骤,以及提高该项作业效 率的工具。 软件质量度量和保证的条件通常有以下几项 ■适应性:必须制定能适应各种用户要求、软件类型和规模的质量标准,并能够度量 易学性:不需要特殊技术,软件技术人员人人都容易掌握。 可靠性:对同一软件的评价,尽管评价的人或场合可能不同,但评价结果必须一致 ■针对性:不是在检查时才改进质量,而必须从设计阶段起就确立质量目标,在各个阶 段实施落实 客观性:从各种不同角度加以评价,并将评价结果定量地表示,使得人人都能理解。 经济性:考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内 ②软件质量度量与保证的实施 图104给出软件质量度量和保证系统在质量保证活动中的五个实施步骤 Target:以用户要求和开发方针为依据,对质量需求准则、质量设计准则的各质量特性 设定质量目标。对各准则的重要程度可以设“特别重要”、“重要”、“一般”三级 Plan:设定适合于被开发软件的评测检查项目,与此同时还要研讨实现质量目标的方 法或手段。 Do:在开发标准和质量评价准则的指导下,制作高质量的规格说明书和程序。在接受 质量检查之前要先做自我检查 Check:以Plan阶段设定的质量评价准则进行评价。算出得分,用质量图的形式表示 出来,参看图10.5。比较评价结果的质量得分和质量目标,看其是否合格 Action:对评价发现的问题进行改进活动,如果实现并达到了质量目标就转入下一个 工程阶段。这样重复“Plan”到“ Action”的过程,直到整个开发项目完成 用户要求 设置质量目标 开发方针 ·设置质量特性指标 设置质量子特性指标 各阶段度量对象 研究质量特性及实现方法 Plan 设置质量度量准则 ·研究质量目标实现方法 Do 开发活动 质量评价 Check 设置质量度量准则 管理信息 以得分和质量图表示 评测得分表 判断目标达到否? 质量图 改进活动
6 为了开发高质量的软件，从计划阶段开始，不但需要明确软件的功能，还要明确软件应 达到什么样的质量标准，即制定软件的质量目标。为了达到这个目标，在开发过程中的各个 阶段进行检查和评价。在做质量评价时，需要有对质量进行度量的准则和方法，但更重要的 是，需要有在软件生存期中如何使用这些准则和方法的质量保证步骤，以及提高该项作业效 率的工具。 软件质量度量和保证的条件通常有以下几项： ▪ 适应性：必须制定能适应各种用户要求、软件类型和规模的质量标准，并能够度量。 ▪ 易学性：不需要特殊技术，软件技术人员人人都容易掌握。 ▪ 可靠性：对同一软件的评价，尽管评价的人或场合可能不同，但评价结果必须一致。 ▪ 针对性：不是在检查时才改进质量，而必须从设计阶段起就确立质量目标，在各个阶 段实施落实。 ▪ 客观性：从各种不同角度加以评价，并将评价结果定量地表示，使得人人都能理解。 ▪ 经济性：考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。 ② 软件质量度量与保证的实施 图 10.4 给出软件质量度量和保证系统在质量保证活动中的五个实施步骤： ▪ Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性 设定质量目标。对各准则的重要程度可以设“特别重要”、“重要”、“一般”三级。 ▪ Plan：设定适合于被开发软件的评测检查项目，与此同时还要研讨实现质量目标的方 法或手段。 ▪ Do：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。在接受 质量检查之前要先做自我检查。 ▪ Check：以 Plan 阶段设定的质量评价准则进行评价。算出得分，用质量图的形式表示 出来，参看图 10.5。比较评价结果的质量得分和质量目标，看其是否合格。 ▪ Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个 工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。 设置质量目标 ▪ 设置质量特性指标 ▪ 设置质量子特性指标 用户要求 Target , 开发方针 各阶段度量对象 研究质量特性及实现方法 ▪ 设置质量度量准则 ▪ 研究质量目标实现方法 开发活动 质量评价 ▪ 设置质量度量准则 ▪ 以得分和质量图表示 ▪ 判断目标达到否？ 改进活动 管理信息 评测得分表 质量图 Plan Do Check Action
图104软件质量度量与保证体系的管理周期 质量设计准则评价得分 ID I SI I 度量者[宋明华 名[设计工程 度量日[97/7/1 度量单位PR0L 设计质量[0.7691 质量需求准则质量设计准则得分图示 追踪性 0.916 正确性完备性 致性 0.872 致性 可靠性简单性 0.812 容错性 准确性 0.616 可维护性 0.872 模块性 806 质量设计准则评价得分 系统ID[sI 度量者[宋明华 工程名[设计工程] 度量日[9771] 度量单位PROL 设计质量[0.769 正确性90% 互连性 不适用 可靠性71% 保密安全性 可维护性 30% 效率85% 灵活性85% 目标 可使用性93% 图10.5质量图 3.正式技术评审( Formal Technical review,FTR) 人的认识不可能100%符合客观实际,因此在软件生存期每个阶段的工作中都可能引入 人为的错误。在某一阶段中出现的错误,如果得不到及时纠正,就会传播到开发的后续阶段 中去,并在后续阶段中引出更多的错误。实践证明,提交给测试阶段的程序中包含的错误越 多,经过同样时间的测试后,程序中仍然潜伏的错误也越多。所以必须在开发时期的每个阶 段,特别是设计阶段结束时都要进行严格的技术评审,尽量不让错误传播到下一个阶段 软件技术评审是软件开发人员实施的一种质量保证活动,FTR的目标是: ■针对任一种软件范型,发现软件在功能、逻辑和实现上的错误。 验证经过评审的软件确实满足需求。 保证软件是按照已确定的标准表述的。 使得软件能按一致的方式开发。 使软件项目跟容易管理。 此外,FTR还起到了提高项目连续性和训练软件工程人员的作用。FTR包括了“走查”、 检查”、“循环评审”和其它的软件评审技术。每次FTR都以会议形式进行,只有在很好地 计划、控制和参与的情况下,FTR才有可能获得成功
7 图 10.4 软件质量度量与保证体系的管理周期 图 10.5 质量图 3. 正式技术评审（Formal Technical Review，FTR） 人的认识不可能 100％符合客观实际，因此在软件生存期每个阶段的工作中都可能引入 人为的错误。在某一阶段中出现的错误，如果得不到及时纠正，就会传播到开发的后续阶段 中去，并在后续阶段中引出更多的错误。实践证明，提交给测试阶段的程序中包含的错误越 多，经过同样时间的测试后，程序中仍然潜伏的错误也越多。所以必须在开发时期的每个阶 段，特别是设计阶段结束时都要进行严格的技术评审，尽量不让错误传播到下一个阶段。 软件技术评审是软件开发人员实施的一种质量保证活动，FTR 的目标是： ▪ 针对任一种软件范型，发现软件在功能、逻辑和实现上的错误。 ▪ 验证经过评审的软件确实满足需求。 ▪ 保证软件是按照已确定的标准表述的。 ▪ 使得软件能按一致的方式开发。 ▪ 使软件项目跟容易管理。 此外，FTR 还起到了提高项目连续性和训练软件工程人员的作用。FTR 包括了“走查”、 “检查”、“循环评审”和其它的软件评审技术。每次 FTR 都以会议形式进行，只有在很好地 计划、控制和参与的情况下，FTR 才有可能获得成功
(1)评审会议 每次评审会议都需遵守以下规定 每次会议的参加人数3~5人 会前应做好准备,但每个人的工作量不应超过2小时 每次会议的时间不应超过2小时 按照上述规定,显然FTR关注的应是整个软件的某一特定(且较小)的部分。例如,不是 对整个设计评审,而是逐个模块走查,或走查模块的一部分。通过缩小关注的范围,更容易 发现错误 FTR的关注点集中于某个工作产品,即软件的某一部分(如部分需求规格说明、一个模 块的详细设计、一个模块的源程序清单)。评审会议由评审负责人主持,所有评审人员和开发 人员参加。FTR首先讨论日程安排,然后让开发人员“遍历”其工作产品,做简单介绍。评 审人员根据他们事先的准备提出问题。当问题被确认或错误被发现,记录员要将其一一记录 下来。评审结束时,所有FTR的参加者必须作出决定: 接受该工作产品,不再做进一步的修改 由于该工作产品错误严重,拒绝接受(错误改正后必须再次进行评审) 暂时接受该工作产品(发现必须改正的微小错误,但不必再次进行评审 当决定之后,FTR的所有参加者都必须签名,以表明他参加了会议,并同意评审组的决 (2)评审内容 通常,把“质量”定义为“用户的满意程度”。为使得用户满意,有两个必要条件: 设计的规格说明要符合用户的要求 ■程序要按照设计规格说明所规定的情况正确执行。 我们把上述条件(1)称为“设计质量”,把条件(2)称为“程序质量”。 与上述质量的观点相对应,软件的规格说明可以分为外部规格说明和内部规格说明。外 部规格说明是从用户角度来看的规格,包括硬件/软件系统设计(在分析阶段进行)、功能设 计(在需求分析阶段与概要设计阶段进行),而内部规格说明是为了实现外部规格的更详细的 规格,即程序模块结构设计与模块处理加工设计(在概要设计与详细设计阶段进行)。因此, 内部规格说明是从开发者角度来看的规格说明。将上述两个概念联系起来,则可以说设计质 量是由外部规格说明决定的,程序质量是由内部规格说明决定的 下面讨论针对外部规格说明进行的设计评审。评审对象是在需求分析阶段产生的软件需 求规格说明、数据要求规格说明,在软件概要设计阶段产生的软件概要设计说明书等。通常, 需要从12个方面进行评审 评价软件的规格说明是否合乎用户的要求: 评审可靠性措施是否能避免引起系统失效的原因发生,而一旦发生后能否及时采取代 替手段或恢复手段 评审保密措施是否能实现。 评审操作特性实施情况。可从4个方面检查:操作命令和操作信息的恰当性;输入数 据和输入控制语句的恰当性:输出数据的恰当性和应答时间的恰当性。 评审性能实现情况。一般来说,因性能设计是需要考虑多方面因素的复杂工作,因此, 应明确规定性能的目标值。性能目标设定条件的恰当性;明确性能的评价方法。 ■评审软件是否具有可修改性。需要考察系统是否具备以下功能:检测故障的功能,获 取分析数据的功能:区分问题根源的方法;故障修正的方法。 评审软件是否有可扩充性。 评审软件是否具有兼容性
8 (1) 评审会议 每次评审会议都需遵守以下规定： ▪ 每次会议的参加人数 3 5 人。 ▪ 会前应做好准备，但每个人的工作量不应超过 2 小时。 ▪ 每次会议的时间不应超过 2 小时。 按照上述规定，显然 FTR 关注的应是整个软件的某一特定(且较小)的部分。例如，不是 对整个设计评审，而是逐个模块走查，或走查模块的一部分。通过缩小关注的范围，更容易 发现错误。 FTR 的关注点集中于某个工作产品，即软件的某一部分(如部分需求规格说明、一个模 块的详细设计、一个模块的源程序清单）。评审会议由评审负责人主持，所有评审人员和开发 人员参加。FTR 首先讨论日程安排，然后让开发人员“遍历”其工作产品，做简单介绍。评 审人员根据他们事先的准备提出问题。当问题被确认或错误被发现，记录员要将其一一记录 下来。评审结束时，所有 FTR 的参加者必须作出决定： ▪ 接受该工作产品，不再做进一步的修改。 ▪ 由于该工作产品错误严重，拒绝接受(错误改正后必须再次进行评审)。 ▪ 暂时接受该工作产品(发现必须改正的微小错误，但不必再次进行评审)。 当决定之后，FTR 的所有参加者都必须签名，以表明他参加了会议，并同意评审组的决 定。 (2) 评审内容 通常，把“质量”定义为“用户的满意程度”。为使得用户满意，有两个必要条件： ▪ 设计的规格说明要符合用户的要求； ▪ 程序要按照设计规格说明所规定的情况正确执行。 我们把上述条件(1)称为“设计质量”，把条件(2)称为“程序质量”。 与上述质量的观点相对应，软件的规格说明可以分为外部规格说明和内部规格说明。外 部规格说明是从用户角度来看的规格，包括硬件／软件系统设计(在分析阶段进行)、功能设 计(在需求分析阶段与概要设计阶段进行)，而内部规格说明是为了实现外部规格的更详细的 规格，即程序模块结构设计与模块处理加工设计(在概要设计与详细设计阶段进行)。因此， 内部规格说明是从开发者角度来看的规格说明。将上述两个概念联系起来，则可以说设计质 量是由外部规格说明决定的，程序质量是由内部规格说明决定的。 下面讨论针对外部规格说明进行的设计评审。评审对象是在需求分析阶段产生的软件需 求规格说明、数据要求规格说明，在软件概要设计阶段产生的软件概要设计说明书等。通常， 需要从 12 个方面进行评审。 ▪ 评价软件的规格说明是否合乎用户的要求： ▪ 评审可靠性措施是否能避免引起系统失效的原因发生，而一旦发生后能否及时采取代 替手段或恢复手段。 ▪ 评审保密措施是否能实现。 ▪ 评审操作特性实施情况。可从 4 个方面检查：操作命令和操作信息的恰当性；输入数 据和输入控制语句的恰当性；输出数据的恰当性和应答时间的恰当性。 ▪ 评审性能实现情况。一般来说，因性能设计是需要考虑多方面因素的复杂工作，因此， 应明确规定性能的目标值。性能目标设定条件的恰当性；明确性能的评价方法。 ▪ 评审软件是否具有可修改性。需要考察系统是否具备以下功能：检测故障的功能，获 取分析数据的功能；区分问题根源的方法；故障修正的方法。 ▪ 评审软件是否有可扩充性。 ▪ 评审软件是否具有兼容性
评审软件是否具有可移植性 评审软件是否具有可测试性:为保证软件在修改或扩充后的正确性,不仅要测试被修 改或被扩充的部分是否能按规格执行,而且还应对该软件原有的功能经修改或扩充后是否能 按以前的规格正确运行进行测试。 评审软件是否具有可复用性 评审软件是否具有互连性:要求软件与其它软件应有共同接口,与其它软件之间的接 口部分应是模块化的 程序质量评审是着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的 评审活动。通常它是从开发者的角度进行评审,直接与开发技术有关 ■软件的结构。需要检査的项目有:数据结构、功能结构、数据结构和功能结构之间的 对应关系 功能的通用性 模块层次。包括模块的层次结构,与功能层次的对应关系 ■模块结构。检査的项目有:控制流结构、数据流结构、模块结构与功能结构之间的对 应关系,包括功能结构与控制流结构的对应关系:功能结构与数据流结构的对应关系。以及 每个模块的定义。 处理过程的结构。对它的检查项目有:要求模块的功能结构与实现这些功能的处理过 程的结构应明确对应;要求控制流应是结构化的:数据的结构与控制流之间的对应关系应是 明确的,并且可依这种对应关系来明确数据流程的关系。 与运行环境的接口。主要检查项目有:与其它软件的接口:与硬件的接口:与用户的 接口:变更的影响范围问题。 4.软件配置管理 在软件建立时变更是不可避免的,而变更更加剧了项目中软件人员之间的混乱。之所以 产生混乱,是因为在进行变更前没有仔细分析,或没有进行变更控制。 Babich曾经这样说过 协调软件开发使得混乱减到最小的技术叫做配置管理。配置管理是一种标识、组织和控制 修改的技术,目的是使错误达到最小并最有效地提高生产率” 软件配置管理,简称SCM,是一种“保护伞”活动,它应用于整个软件生存期。因为 变更在任何时刻都可能发生,因此软件配置管理活动的目标就是为了标识变更,控制变更, 确保变更正确地实现,向其他有关的人报告变更 软件维护和软件配置管理之间的区别是:维护是一组软件工程活动,它们发生于软件已 交付给用户并已投入运行之后:软件配置管理是一组追踪和控制活动,它们开始于软件开发 项目开始之时,结束于软件被淘汰之时。 (1)软件配置项( Software Configuration Item,简称SCI) 软件工程过程的输出有三种信息:计算机程序(源程序及目标程序),描述计算机程序的 文档(包括技术文档和用户文档),数据结构。在软件工程过程中产生的所有的信息项(文档、 报告、程序、表格、数据)就构成了软件配置。软件配置是软件的具体形态在某一时刻的瞬时 影像。这样的具体形态取两种形式 不可直接执行的材料:如书写的文档、程序清单、测试数据、测试结果等。 ·可直接执行的材料:如目标代码、数据库信息等。它们可由计算机处理,存于某种存 储介质上。 软件配置管理的对象就是软件配置项,它们是软件工程过程中产生的信息项。按照ISO 90003的说明,软件配置项可以是: 与合同、过程、计划和产品有关的文档和数据
9 ▪ 评审软件是否具有可移植性。 ▪ 评审软件是否具有可测试性：为保证软件在修改或扩充后的正确性，不仅要测试被修 改或被扩充的部分是否能按规格执行，而且还应对该软件原有的功能经修改或扩充后是否能 按以前的规格正确运行进行测试。 ▪ 评审软件是否具有可复用性。 ▪ 评审软件是否具有互连性：要求软件与其它软件应有共同接口，与其它软件之间的接 口部分应是模块化的。 程序质量评审是着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的 评审活动。通常它是从开发者的角度进行评审，直接与开发技术有关。 ▪ 软件的结构。需要检查的项目有：数据结构、功能结构、数据结构和功能结构之间的 对应关系。 ▪ 功能的通用性。 ▪ 模块层次。包括模块的层次结构，与功能层次的对应关系。 ▪ 模块结构。检查的项目有：控制流结构、数据流结构、模块结构与功能结构之间的对 应关系，包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系。以及 每个模块的定义。 ▪ 处理过程的结构。对它的检查项目有：要求模块的功能结构与实现这些功能的处理过 程的结构应明确对应；要求控制流应是结构化的；数据的结构与控制流之间的对应关系应是 明确的，并且可依这种对应关系来明确数据流程的关系。 ▪ 与运行环境的接口。主要检查项目有：与其它软件的接口；与硬件的接口；与用户的 接口；变更的影响范围问题。 4. 软件配置管理 在软件建立时变更是不可避免的，而变更更加剧了项目中软件人员之间的混乱。之所以 产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。Babich 曾经这样说过： “协调软件开发使得混乱减到最小的技术叫做配置管理。配置管理是一种标识、组织和控制 修改的技术，目的是使错误达到最小并最有效地提高生产率”。 软件配置管理，简称 SCM，是一种“保护伞”活动，它应用于整个软件生存期。因为 变更在任何时刻都可能发生，因此软件配置管理活动的目标就是为了标识变更，控制变更， 确保变更正确地实现，向其他有关的人报告变更。 软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，它们发生于软件已 交付给用户并已投入运行之后；软件配置管理是一组追踪和控制活动，它们开始于软件开发 项目开始之时，结束于软件被淘汰之时。 (1) 软件配置项(Software Configuration Item，简称 SCI) 软件工程过程的输出有三种信息：计算机程序(源程序及目标程序)，描述计算机程序的 文档(包括技术文档和用户文档)，数据结构。在软件工程过程中产生的所有的信息项(文档、 报告、程序、表格、数据)就构成了软件配置。软件配置是软件的具体形态在某一时刻的瞬时 影像。这样的具体形态取两种形式： ▪ 不可直接执行的材料：如书写的文档、程序清单、测试数据、测试结果等。 ▪ 可直接执行的材料：如目标代码、数据库信息等。它们可由计算机处理，存于某种存 储介质上。 软件配置管理的对象就是软件配置项，它们是软件工程过程中产生的信息项。按照 ISO 9000-3 的说明，软件配置项可以是： ▪ 与合同、过程、计划和产品有关的文档和数据；
源代码、目标代码和可执行代码 相关产品,包括软件工具、库内的可复用软件、外购软件及用户提供的软件 软件工具包括编辑程序、编译程序、其它CASE工具的特定版本,都要做为软件配置的 部分加以“冻结”。如果编译程序的版本不同,可能产生的结果也不同 随着软件工程过程的进展,软件配置项数目快速增加。如果每个配置项只是简单地产生 其它软件配置项,造成的混乱可能微乎其微。然而在变更时会引入其它影响因素,使得情况 变得更加复杂。这时配置管理的作用就会充分显示出来 不仅如此,所有以上提到的软件配置 项在不同时期,出于不同的要求进行了各 数据模型 种组合,如针对不同的硬件环境和软件环 设计规格说明 境的各种组合,这就是软件配置的概念 在实现软件配置管理时,把软件配置项组 体系结构设计 织成配置对象,在项目数据库中用一个单 模块设计 的名字来组织它们。一个配置对象有 界面设计 个名字和一组属性,并通过某些联系“连 模块N 接”到其它对象,如图106所示。图中分 测试规格说明 界面描述 算法描述 别对配置对象进行了定义,每个对象与其 测试过程 它对象的联系用箭头表示。箭头标明了构测试用例 成关系。如“数据模型”和“模块N”是 设计规格说明”的一部分。双向箭头则 表明一种相互关系。如果对“源代码”对 象作了一个变更,软件人员可以根据这种 相互关系确定其它哪些对象可能受到影 图106配置对象 (2)基线( Baseline) 基线是软件生存期中各开发阶段末尾的特 定点,又称里程碑。由正式的技术评审而得到的 系统工程 软件配置项协议和软件配置的正式文本才能成 系统规格说明 为基线。它的作用是把各阶段工作的划分更加明 需求分析 软件需求规格说明 确化,使本来连续的工作在这些点上断开,以便 一设计规格说明 于检验和肯定阶段成果。例如,明确规定不允许 程序编写 源代码 跨越里程碑修改另一阶段的文档。如图10.7所 示,是软件开发各阶段的基线。 测试计划过程数据一测试 操作系统 旦一个软件配置项成为基线,就把它存放 到项目数据库(亦称项目信息库或软件仓库)中。 当一位软件组织成员想要对基线配置项进行修 图107软件开发各阶段的基线 改时,就把它从项目数据库中复制到该工程师的 专用工作空间中,如图10.8所示。图中把一个标号为B的配置项从项目数据库复制到工程师 的专用工作空间中。这个活动记录在一个记事文件中。工程师可以在B(B的副本)上完成要 求的变更,然后用B来更新B。有些系统中把这个基线配置项锁定,在变更完成、评审和批 准之前,不许对它做任何操作 (3)软件配置管理的过程 软件配置管理除了担负控制变更的责任之外,它还要担负标识单个的软件配置项和软件 各种版本、审查软件配置以保证开发得以正常进行,以及报告所有加在配置上的变更等任务
10 ▪ 源代码、目标代码和可执行代码； ▪ 相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。 软件工具包括编辑程序、编译程序、其它 CASE 工具的特定版本，都要做为软件配置的 一部分加以“冻结”。如果编译程序的版本不同，可能产生的结果也不同。 随着软件工程过程的进展，软件配置项数目快速增加。如果每个配置项只是简单地产生 其它软件配置项，造成的混乱可能微乎其微。然而在变更时会引入其它影响因素，使得情况 变得更加复杂。这时配置管理的作用就会充分显示出来。 不仅如此，所有以上提到的软件配置 项在不同时期，出于不同的要求进行了各 种组合，如针对不同的硬件环境和软件环 境的各种组合，这就是软件配置的概念。 在实现软件配置管理时，把软件配置项组 织成配置对象，在项目数据库中用一个单 一的名字来组织它们。一个配置对象有一 个名字和一组属性，并通过某些联系“连 接”到其它对象，如图 10.6 所示。图中分 别对配置对象进行了定义，每个对象与其 它对象的联系用箭头表示。箭头标明了构 成关系。如“数据模型”和“模块 N”是 “设计规格说明”的一部分。双向箭头则 表明一种相互关系。如果对“源代码”对 象作了一个变更，软件人员可以根据这种 相互关系确定其它哪些对象可能受到影 响。 (2) 基线 (Baseline) 基线是软件生存期中各开发阶段末尾的特 定点，又称里程碑。由正式的技术评审而得到的 软件配置项协议和软件配置的正式文本才能成 为基线。它的作用是把各阶段工作的划分更加明 确化，使本来连续的工作在这些点上断开，以便 于检验和肯定阶段成果。例如，明确规定不允许 跨越里程碑修改另一阶段的文档。如图 10.7 所 示，是软件开发各阶段的基线。 一旦一个软件配置项成为基线，就把它存放 到项目数据库(亦称项目信息库或软件仓库)中。 当一位软件组织成员想要对基线配置项进行修 改时，就把它从项目数据库中复制到该工程师的 专用工作空间中，如图 10.8 所示。图中把一个标号为 B 的配置项从项目数据库复制到工程师 的专用工作空间中。这个活动记录在一个记事文件中。工程师可以在 B'(B 的副本)上完成要 求的变更，然后用 B'来更新 B。有些系统中把这个基线配置项锁定，在变更完成、评审和批 准之前，不许对它做任何操作。 (3) 软件配置管理的过程 软件配置管理除了担负控制变更的责任之外，它还要担负标识单个的软件配置项和软件 各种版本、审查软件配置以保证开发得以正常进行，以及报告所有加在配置上的变更等任务。 图 10.6 配置对象 图 10.7 软件开发各阶段的基线