【计算机】10 软件质量保证.doc

《【计算机】10 软件质量保证.doc》由会员分享，可在线阅读，更多相关《【计算机】10 软件质量保证.doc（55页珍藏版）》请在三一办公上搜索。

1、第十章 软件质量保证一、复习要求1. 了解软件质量保证、质量保证活动与质量检验的概念。2. 了解软件质量保证体系与质量保证的实施的概要。3. 了解正式技术评审概要。包括评审会议、设计质量和程序质量的评审。4. 了解软件配置管理的概念。包括配置项和基线概念、配置管理的主要工作。5. 了解软件工程标准化的概念。包括软件工程标准化意义、软件工程标准的制定与推行、软件工程标准的层次、软件工程的国家标准。6. 了解软件文档的概念。包括文档编制的要求、文档的作用、分类、文档的工作。7. 了解软件过程与过程改进的概念。包括过程分类与过程模型、剪裁过程、过程模型建造技术、软件过程改进。8. 了解软件过程能力评

2、估的CMM模型，包括过程成熟度的概念、软件机构的能力成熟度模型、关键过程域、关键实践的概念。9. 了解ISO 9000国际标准。包括质量管理、质量认证和质量审核的概念，ISO 9000系列标准的特点、科学依据、主要内容，以及ISO 9000-3标准。二、内容提要1. 软件质量保证(1) 质量保证的概念什么是质量保证？它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。软件的质量保证就是向用户及社会提供满意的高质量的产品。进一步地，软件的质量保证活动也

3、和一般的质量保证活动一样，是确保软件产品在软件生存期所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括的主要功能如： 制定和展开质量方针； 制定质量保证方针和质量保证标准； 建立和管理质量保证体系； 明确各阶段的质量保证业务； 坚持各阶段的质量评审； 确保设计质量； 提出与分析重要的质量问题； 总结实现阶段的质量保证活动； 整理面向用户的文档、说明书等； 鉴定产品质量，鉴定质量保证体系； 收集、分析和整理质量信息。(2) 软件质量保证(SQA)活动软件质量保证由各项任务构成，这些任务的参与者有两种人：软件开发人员和质量保证人员。前者负责技术工

4、作，后者负责质量保证的计划、监督、记录、分析及报告工作。软件开发人员通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产品。1993年美国SEI推荐了一组有关质量保证的计划、监督、记录、分析及报告的SQA活动。这些活动将由一个独立的SQA小组执行(或协助)： 为项目制定SQA计划。该计划在制定项目计划时制定，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动，其要点包括：需要进行哪些评价？需要进行哪些审计和评审？项目采用的标准；错误报告的要求和跟踪过程；SQA小组应产生哪些文档？为

5、软件项目组提供的反馈数量等。 参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与组织政策、内部的软件标准、外界所制定的标准(如ISO 9001）以及软件项目计划的其它部分相符。 评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。 审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。 确保软件工作及工作产品中的偏差已被记录在案，并根据预

6、定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。 记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。除了进行上述活动外，SQA小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息。(3) 质量保证与检验 检验在质量保证中的作用软件质量必须在设计和实现过程中加以保证。如果过程管理不力，软件开发环境或软件工具不够好，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。质量保证是面向消费者的，从质量保证的角度来讨论检查，下面几点应当明确： 用户要求的是

7、产品所具有的功能，这是“真质量”。靠质量检验，一般检查的是“真质量”的质量特性。 能靠质量检验的质量特性，即使全数检验，也只是代表产品的部分质量特性。 必须在各开发阶段对影响产品质量的因素进行切实的管理，认真检查实施落实情况。只有这样才能使产品达到用户要求，这比单靠检验来保证质量要有效、经济。 当开发阶段出现异常时，要从质量特性方面进行检验，看是否会给后续阶段带来影响，并对判断其好坏程度。从质量保证角度来看，此项工作极其重要。 虽然各开发阶段进展稳定，但由于工具支持不足等，软件产品不能满足用户要求的质量。这时可通过检验对该产品做出评价，判断是否能向用户提供该产品。 尽管各开发阶段进展稳定，但也

8、要以一定的标准检验产品，使其交付使用后保持稳定的质量水平。同时还要根据产品的质量特性，检查各个过程的管理状态。因此，检验的目的有二个。其一是切实搞好开发阶段的管理，检查各开发阶段的质量保证活动开展得如何；其二是预先防止软件差错给用户造成损失。 各个开发阶段中的检验为了切实做好质量保证，要在软件开发工程的各个阶段实施检验。检验的类型有： 供货检验：这是指对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件、规格说明、半成品或产品的检查。由于委托单位、委托时间等情况差别很大，往往与质量相关的信息不完全，要想只靠供货时检查，质量很难保证。因此要调查接受委托单位的开发能力，并且要充分交流情况。

9、 中间检验阶段评审：在各阶段的中途或向下一阶段移交时进行的检查叫做中间检验或阶段评审。阶段评审的目的是为了判断是否可进入下一阶段进行后续开发工作，避免将差错传播到后续工作中，给后续工作带来不良影响，造成损失。 验收检验：确认产品是否已达到可以进行“产品检验”的质量要求。 产品检验：这是软件产品交付使用前进行的检查。其目的是判定向用户提供的软件，作为产品，是否达到了令人满意的程度。检验的实施有两种形式：实际运行检验(即白盒测试和黑盒测试)和鉴定。可在各开发阶段中结合起来使用。各开发阶段及阶段中的检验如图10.1所示。图10.1 开发阶段与相应的检验项目2. 软件质量保证体系与质量保证的实施(1)

10、 软件质量保证体系软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还要调查软件实现过程的状况，并根据情况检查设计是否有误，不当之处加以改进，防止再次发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与协作的机构十分重要，这个机构就是质量保证体系。图10.2和10.3是软件质量保证体系的图例。在质量保证体系图上，用户、领导、各部门横向安排，而纵向则顺序列出软件质量保证活动的各项工作。制定质量体系保证图应注意以下一些问题： 必须明确反馈途径。 必须在体系图的纵向(纵

11、坐标方向)顺序写明开发阶段，在横向(横坐标方向)写明组织机构，明确各部门的职责。 必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。 必须明确决定是否可向下一阶段进展的评价项目和评价准则。 必须不断地总结系统管理的经验教训，能够修改系统。仅靠质量保证体系图很难明确具体工作，因此必须制定质量保证计划，在这个计划中确定质量目标，确定在每个阶段为达到总目标所应达到的要求，对进度做出安排，确定所需的人力、资源和成本等等。图10.2 质量保证体系图例(程序检查) 在这个质量保证计划中包括的软件质量保证规程和技术准则应当 指示在何时、何处进行文档检查和程序检查； 指示应当采集哪些数

12、据，以及如何进行分析处理，例如，在每次评审和测试中发现的错误如何修正； 描述希望得到的质量度量； 规定在项目的哪个阶段进行评审及如何评审； 规定在项目的哪个阶段应当产生哪些报告和计划； 规定产品各方面测试应达到的水平。在计划中，在说明各种软件人员的职责时，要规定为了达到质量目标他们必须进行哪些活动。其次，要根据这个质量保证体系图，建立在各阶段中执行质量评价的质量评价和质量检查系统及有效运用质量信息的质量信息系统，并使其运行。图10.3 质量保证体系图(文档检查)(2) 质量保证的实施软件质量保证的实施需要从纵向和横向两个方面展开。一方面要求所有与软件生存期有关的人员都要参加，另一方面要求对产品

13、形成的全过程进行质量管理，这要求整个软件部门齐心协力，不断完善软件的开发环境。此外还需要与用户共同合作。 质量目标与度量为了开发高质量的软件，从计划阶段开始，不但需要明确软件的功能，还要明确软件应达到什么样的质量标准，即制定软件的质量目标。为了达到这个目标，在开发过程中的各个阶段进行检查和评价。在做质量评价时，需要有对质量进行度量的准则和方法，但更重要的是，需要有在软件生存期中如何使用这些准则和方法的质量保证步骤，以及提高该项作业效率的工具。软件质量度量和保证的条件通常有以下几项： 适应性：必须制定能适应各种用户要求、软件类型和规模的质量标准，并能够度量。 易学性：不需要特殊技术，软件技术人员

14、人人都容易掌握。 可靠性：对同一软件的评价，尽管评价的人或场合可能不同，但评价结果必须一致。 针对性：不是在检查时才改进质量，而必须从设计阶段起就确立质量目标，在各个阶段实施落实。 客观性：从各种不同角度加以评价，并将评价结果定量地表示，使得人人都能理解。 经济性：考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。 软件质量度量与保证的实施图10.4给出软件质量度量和保证系统在质量保证活动中的五个实施步骤： Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。对各准则的重要程度可以设“特别重要”、“重要”、“一般”三级。 Plan：设定适合

15、于被开发软件的评测检查项目，与此同时还要研讨实现质量目标的方法或手段。 Do：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。在接受质量检查之前要先做自我检查。 Check：以Plan阶段设定的质量评价准则进行评价。算出得分，用质量图的形式表示出来，参看图10.5。比较评价结果的质量得分和质量目标，看其是否合格。 Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。Target研究质量特性及实现方法 设置质量度量准则 研究质量目标实现方法各阶段度量对象用户要求,开发方针设置

16、质量目标 设置质量特性指标 设置质量子特性指标Plan开发活动ActionDoCheck改进活动管理信息评测得分表质量图质量评价 设置质量度量准则 以得分和质量图表示 判断目标达到否？图10.5 软件质量度量与保证系统的管理图10.4 软件质量度量与保证体系的管理周期图10.5 质量图3. 正式技术评审（Formal Technical Review，FTR）人的认识不可能100符合客观实际，因此在软件生存期每个阶段的工作中都可能引入人为的错误。在某一阶段中出现的错误，如果得不到及时纠正，就会传播到开发的后续阶段中去，并在后续阶段中引出更多的错误。实践证明，提交给测试阶段的程序中包含的错误越多

17、，经过同样时间的测试后，程序中仍然潜伏的错误也越多。所以必须在开发时期的每个阶段，特别是设计阶段结束时都要进行严格的技术评审，尽量不让错误传播到下一个阶段。软件技术评审是软件开发人员实施的一种质量保证活动，FTR的目标是： 针对任一种软件范型，发现软件在功能、逻辑和实现上的错误。 验证经过评审的软件确实满足需求。 保证软件是按照已确定的标准表述的。 使得软件能按一致的方式开发。 使软件项目跟容易管理。此外，FTR还起到了提高项目连续性和训练软件工程人员的作用。FTR 包括了“走查”、“检查”、“循环评审”和其它的软件评审技术。每次FTR都以会议形式进行，只有在很好地计划、控制和参与的情况下，F

18、TR才有可能获得成功。(1) 评审会议每次评审会议都需遵守以下规定： 每次会议的参加人数3 5人。 会前应做好准备，但每个人的工作量不应超过2小时。 每次会议的时间不应超过2小时。按照上述规定，显然FTR关注的应是整个软件的某一特定(且较小)的部分。例如，不是对整个设计评审，而是逐个模块走查，或走查模块的一部分。通过缩小关注的范围，更容易发现错误。FTR的关注点集中于某个工作产品，即软件的某一部分(如部分需求规格说明、一个模块的详细设计、一个模块的源程序清单）。评审会议由评审负责人主持，所有评审人员和开发人员参加。FTR首先讨论日程安排，然后让开发人员“遍历”其工作产品，做简单介绍。评审人员根

19、据他们事先的准备提出问题。当问题被确认或错误被发现，记录员要将其一一记录下来。评审结束时，所有FTR的参加者必须作出决定： 接受该工作产品，不再做进一步的修改。 由于该工作产品错误严重，拒绝接受(错误改正后必须再次进行评审)。 暂时接受该工作产品(发现必须改正的微小错误，但不必再次进行评审)。当决定之后，FTR的所有参加者都必须签名，以表明他参加了会议，并同意评审组的决定。(2) 评审内容通常，把“质量”定义为“用户的满意程度”。为使得用户满意，有两个必要条件： 设计的规格说明要符合用户的要求； 程序要按照设计规格说明所规定的情况正确执行。我们把上述条件(1)称为“设计质量”，把条件(2)称为

20、“程序质量”。与上述质量的观点相对应，软件的规格说明可以分为外部规格说明和内部规格说明。外部规格说明是从用户角度来看的规格，包括硬件软件系统设计(在分析阶段进行)、功能设计(在需求分析阶段与概要设计阶段进行)，而内部规格说明是为了实现外部规格的更详细的规格，即程序模块结构设计与模块处理加工设计(在概要设计与详细设计阶段进行)。因此，内部规格说明是从开发者角度来看的规格说明。将上述两个概念联系起来，则可以说设计质量是由外部规格说明决定的，程序质量是由内部规格说明决定的。下面讨论针对外部规格说明进行的设计评审。评审对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明，在软件概要设计阶段产生

21、的软件概要设计说明书等。通常，需要从12个方面进行评审。 评价软件的规格说明是否合乎用户的要求： 评审可靠性措施是否能避免引起系统失效的原因发生，而一旦发生后能否及时采取代替手段或恢复手段。 评审保密措施是否能实现。 评审操作特性实施情况。可从4个方面检查：操作命令和操作信息的恰当性；输入数据和输入控制语句的恰当性；输出数据的恰当性和应答时间的恰当性。 评审性能实现情况。一般来说，因性能设计是需要考虑多方面因素的复杂工作，因此，应明确规定性能的目标值。性能目标设定条件的恰当性；明确性能的评价方法。 评审软件是否具有可修改性。需要考察系统是否具备以下功能：检测故障的功能，获取分析数据的功能；区分

22、问题根源的方法；故障修正的方法。 评审软件是否有可扩充性。 评审软件是否具有兼容性。 评审软件是否具有可移植性。 评审软件是否具有可测试性：为保证软件在修改或扩充后的正确性，不仅要测试被修改或被扩充的部分是否能按规格执行，而且还应对该软件原有的功能经修改或扩充后是否能按以前的规格正确运行进行测试。 评审软件是否具有可复用性。 评审软件是否具有互连性：要求软件与其它软件应有共同接口，与其它软件之间的接口部分应是模块化的。程序质量评审是着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。通常它是从开发者的角度进行评审，直接与开发技术有关。 软件的结构。需要检查的项目有：数据结构

23、、功能结构、数据结构和功能结构之间的对应关系。 功能的通用性。 模块层次。包括模块的层次结构，与功能层次的对应关系。 模块结构。检查的项目有：控制流结构、数据流结构、模块结构与功能结构之间的对应关系，包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系。以及每个模块的定义。 处理过程的结构。对它的检查项目有：要求模块的功能结构与实现这些功能的处理过程的结构应明确对应；要求控制流应是结构化的；数据的结构与控制流之间的对应关系应是明确的，并且可依这种对应关系来明确数据流程的关系。 与运行环境的接口。主要检查项目有：与其它软件的接口；与硬件的接口；与用户的接口；变更的影响范围问题。4.

24、 软件配置管理在软件建立时变更是不可避免的，而变更更加剧了项目中软件人员之间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。Babich曾经这样说过：“协调软件开发使得混乱减到最小的技术叫做配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产率”。软件配置管理，简称SCM，是一种“保护伞”活动，它应用于整个软件生存期。因为变更在任何时刻都可能发生，因此软件配置管理活动的目标就是为了标识变更，控制变更，确保变更正确地实现，向其他有关的人报告变更。软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，它们发生于软件已交付给用户

25、并已投入运行之后；软件配置管理是一组追踪和控制活动，它们开始于软件开发项目开始之时，结束于软件被淘汰之时。(1) 软件配置项(Software Configuration Item，简称SCI)软件工程过程的输出有三种信息：计算机程序(源程序及目标程序)，描述计算机程序的文档(包括技术文档和用户文档)，数据结构。在软件工程过程中产生的所有的信息项(文档、报告、程序、表格、数据)就构成了软件配置。软件配置是软件的具体形态在某一时刻的瞬时影像。这样的具体形态取两种形式： 不可直接执行的材料：如书写的文档、程序清单、测试数据、测试结果等。 可直接执行的材料：如目标代码、数据库信息等。它们可由计算机处

26、理，存于某种存储介质上。软件配置管理的对象就是软件配置项，它们是软件工程过程中产生的信息项。按照ISO 9000-3的说明，软件配置项可以是： 与合同、过程、计划和产品有关的文档和数据； 源代码、目标代码和可执行代码； 相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。软件工具包括编辑程序、编译程序、其它CASE工具的特定版本，都要做为软件配置的一部分加以“冻结”。如果编译程序的版本不同，可能产生的结果也不同。图10.6 配置对象随着软件工程过程的进展，软件配置项数目快速增加。如果每个配置项只是简单地产生其它软件配置项，造成的混乱可能微乎其微。然而在变更时会引入其它影响因素，

27、使得情况变得更加复杂。这时配置管理的作用就会充分显示出来。不仅如此，所有以上提到的软件配置项在不同时期，出于不同的要求进行了各种组合，如针对不同的硬件环境和软件环境的各种组合，这就是软件配置的概念。在实现软件配置管理时，把软件配置项组织成配置对象，在项目数据库中用一个单一的名字来组织它们。一个配置对象有一个名字和一组属性，并通过某些联系“连接”到其它对象，如图10.6所示。图中分别对配置对象进行了定义，每个对象与其它对象的联系用箭头表示。箭头标明了构成关系。如“数据模型”和“模块N”是“设计规格说明”的一部分。双向箭头则表明一种相互关系。如果对“源代码”对象作了一个变更，软件人员可以根据这种相

28、互关系确定其它哪些对象可能受到影响。(2) 基线 (Baseline)图10.7 软件开发各阶段的基线基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。由正式的技术评审而得到的软件配置项协议和软件配置的正式文本才能成为基线。它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。例如，明确规定不允许跨越里程碑修改另一阶段的文档。如图10.7所示，是软件开发各阶段的基线。一旦一个软件配置项成为基线，就把它存放到项目数据库(亦称项目信息库或软件仓库)中。当一位软件组织成员想要对基线配置项进行修改时，就把它从项目数据库中复制到该工程师的专用工作空间中，如

29、图10.8所示。图中把一个标号为B的配置项从项目数据库复制到工程师的专用工作空间中。这个活动记录在一个记事文件中。工程师可以在B(B的副本)上完成要求的变更，然后用B来更新B。有些系统中把这个基线配置项锁定，在变更完成、评审和批准之前，不许对它做任何操作。(3) 软件配置管理的过程软件配置管理除了担负控制变更的责任之外，它还要担负标识单个的软件配置项和软件各种版本、审查软件配置以保证开发得以正常进行，以及报告所有加在配置上的变更等任务。图10.8 基线SCI和项目数据库有关软件配置管理，需要考虑这样一些问题： 采用什么方式来标识和管理许多已存在程序(和它们的文档)的各种版本？ 在软件交付用户之

30、前和之后如何控制变更？ 谁有权批准和对变更安排优先级？ 如何保证变更得以正确地实施？ 利用什么办法来估计变更可能引起的其它问题？这些问题归结到软件配置管理的5个任务，即配置标识、版本管理、变更控制、配置审核和配置报告。(4) 配置标识软件配置实际上是一个动态的概念。一方面随着软件生存期的向前推进，软件配置项的数量在不断增多。另一方面又随时会有新的变更出现，形成新的版本。因此，整个软件生存期的软件配置就象一部不断演变的电影，而某一时刻的配置就是这部电影的一个片段。为了方便对软件配置的各个片段，即软件配置项进行控制和管理，不致造成混乱，首先应给它们命名，这就是配置标识的任务。我们可以用面向对象的方

31、法进行标识。通常需标识两种类型的对象：基本对象和复合对象。基本对象是由软件人员在分析、设计、编码和测试时所建立的“文本单元”。例如，基本对象可能是需求规格说明中的一节，一个源程序清单、一组用来测试一个等价类的测试用例。复合对象则是基本对象或其它复合对象的一个集合。如图10.6所示，“设计规格说明”是一个复合对象，它是一些基本对象，如“数据模型”、“模块N”的集合。每个对象可用一组信息来唯一地标识它，这组信息包括： （名字、描述、一组“资源”、“实现”）对象的名字是一个字符串，它明确地标识对象。对象描述是一个表项，它包括：对象所表示的配置项类型(如文档、程序、数据)、项目标识、变更和或版本信息。

32、资源是“由对象所提供的、处理的、引用的或其它所需要的一些实体”。例如，数据类型，特定函数，甚至变量名都可以看做是对象资源。而“实现”对于一个基本对象来说，是指向“文本单元”的指针，而对于复合对象来说，则为null。配置对象的标识还需考虑在命名对象间存在的联系。对象可以是一个复合对象的组成部分，用联系进行标识。这个联系定义了对象的层次。在对象层次中，对象之间的联系不仅存在于层次树的路径中，而且可跨越对象层次的分支相互关联。例如，数据模型与数据流图是相互关联的，而且它又与一个特定等价类的测试用例组相互关联。(5) 版本控制整个软件工程过程中所涉及的软件对象都必须加以标识。在对象成为基线以前可能要做

33、多次变更，在成为基线之后也可能需要频繁地变更。这样对于每一配置对象都可以建立一个演变图，这个演变图记叙了对象的变更历史。以图10.9为例，配置对象1.0经过修改成为对象1.1，又经历了小的修改和变更，产生了版本1.1.1和1.1.2。紧接对版本1.1做了一次更新，产生对象1.2，又持续演变生成了1.3和1.4版本。同时对对象1.2做了一次较大的修改，引出一条新的演变路径：版本2.0。已经开发出来许多工具来辅助标识工作。在某些工具中，当前保持的只是最后版本的完全副本。为了得到较早时期(文档或程序)的版本，可以从最后版本中“提取”出(由工具编目的)变更，使得当前配置直接可用，并使得其它版本也可用。

34、图10.10 版本的演变图和版本的变种在图10.9所示的演变图中，各结点都是聚合对象。软件的每一版本都是软件配置项(源代码、文档、数据)的一个集合，且各个版本都可能由不同的变种组成。例如，有一个简单的程序版本：它由1、2、3、4和5等部件组成，其中部件4在软件使用彩色显示器时使用，部件5在软件使用单色显示器时使用。因此，可以定义版本的两个变种： 部件1、2、3、4； 部件1、2、3、5。版本控制的主要功能有： 工作站 LAN 图10.10 档案的登入check infilename.cpv 1.2 1.1 1.0 1.3 1.4 filename.cpp 集中管理档案，安全授权机制：版本管理的

35、操作是将开发组的档案集中存放在服务器上，经系统管理员授权给各个用户。用户通过登入(check in)和检出(check out)的方式访问服务器上的文件，未经授权的用户则无法访问服务器上的文件。如图10.10所示。 软件版本升级管理：每次登入时，在服务器上都会生成新的版本，软件版本的管理采取增量存储的方式。任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。如图10.11所示。大型机版 PC 版 VMS 版工作站版初始系统版本 DEC 版 UNIX 版 SUN 版图10.11 软件版本升级管理 加锁功能：为了在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。某一文件

36、一旦被登入，锁即被解除，该文件可被其它用户使用。在更新一个文件之前锁定它，避免变更没有锁定的项目源文件。 提供不同版本源程序的比较：在文件登入和检出时，需要注意检入和检出的使用。 当某个时刻需要修改某个小缺陷或特征，应只检出完成工作必需的最少文件； 当需要对文件变更时，应登入它并加锁。这样可保留对每个变更的记录； 应避免长时间地锁定文件。如果需要长时间工作于某个文件，最好能创建一个分支，并在分支上做工作。这样别人可以地做缺省的“小”修改以更改较小的缺陷。稍后可通过合并，把所有操作结果集成在一起。 如果需要做较大的变更，可有两种选择： ）将需要的所有文件检出并加锁，然后正常处理； ）为需要修改的

37、版本创建分支，把变更与主干“脱离”，然后把结果合并回去。(6) 变更控制软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。变更控制包括建立控制点和建立报告与审查制度。对于一个大型的软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务。图10.12给出了变更控制的过程。图10.12 变更控制过程在此过程中，首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。然后由变更控制机构确定控

38、制变更的机制、评价其技术价值、潜在的副作用、对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式提交给变更控制负责人(最终决定变更状态和优先权的某个人或小组)。对每个批准了的变更产生一个工程变更顺序(ECO)，描述进行的变更、必须考虑的约束、评审和审计的准则等。要做变更的对象从项目数据库中检出，对其做出变更，并实施适当的质量保证活动。然后再把对象登入到数据库中并使用适当的版本控制机制建立软件的下一版本。图10.13 存取和同步控制“检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理人们存取或修改一个特定软件配置对象的权限；同步控制可

39、用来确保由不同的人所执行的并发变更不会产生混乱。unlock配置对象(提取版本)软件工程人员 配置对象(修改版本)审核信息lock配置对象(基线版本)检出配置对象(基线版本)项目数据库存取控制存取权信息存取和同步控制流如图10.13所示。根据经批准的变更请求和ECO，软件人员从项目数据库中检出要变更的配置对象。同步控制功能则封锁了项目数据库中的这个对象，使得当前检出的版本在没有被置换前不能再更新它。当然，对这个对象还可以检出另外的副本，但对其也不能更新。人们在对这种成为基线的对象做了变更，并经过适当的软件质量保证和测试之后，把修改版本登入项目数据库，再解除封锁。登入软件的变更通常有两类不同的情

40、况： 为改正小错误需要的变更。通常不需要从管理角度对这类变更进行审查和批准。但如果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，并修改所有受这个变更影响的文档。 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。应该把所做的变更正式记入文档，并相应地修改所有有关的文档。这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。需要注意的是，必须对每一项变更进行评价并对所有的变更进行跟踪和复审。(7) 配置状态

41、报告 为了清楚、及时地记载软件配置的变化，不致于到后期造成贻误，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。登录主要根据变更控制小组会议的记录，并产生配置状态报告。报告对于每一项变更，记录以下问题：发生了什么？为什么会发生？谁做的？什么时侯发生的？会有什么影响？图10.14描述了配置状态报告的信息流。配置标识配置状态报告 联机数据库软件配置项配置审核变更配置控制状态报告缺陷配置状态报告图10.14 配置状态报告每次新分配一个软件配置项或更新一个已有软件配置项的标识，或者一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加

42、一条变更记录条目。一旦进行了配置审核，其结果也应该写入报告之中。配置状态报告可以放在一个联机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件人员。配置状态报告对于大型软件开发项目的成功起着至关重要的作用。它提高了所有开发人员之间的通信能力，避免了可能出现的不一致和冲突。(8) 配置审核软件的完整性，是指开发后期的软件产品能够正确地反映用户所提出的对软件的要求。软件配置审核的目的就是要证实整个软件生存期中各项产品在技术上和管理上的完整性。同时，还要确保所有文档的内容变动不超出当初确定的软件要求范围。使得我们的软件配置具

43、有良好的可跟踪性。这是软件变更控制人员掌握配置情况、进行审批的依据。软件的变更控制机制通常只能跟踪到工程变更顺序产生为止，那么如何知道变更是否正确完成了呢? 一般可以用以下两种方法去审查：正式技术评审和软件配置审核。正式的技术评审着重检查已完成修改的软件配置对象的技术正确性，评审者评价软件配置项，决定它与其它软件配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审应对所有的变更进行，除了那些最无价值的变更之外。软件配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的软件配置项的特性。软件配置审核提出并解答以下问题： 在工程变更顺序中规定的变更是否已经做了? 每个附加修改是否已经

44、纳入? 正式技术评审是否已经评价了技术正确性? 是否正确遵循了软件工程标准? 在软件配置项中是否强调了变更? 是否说明了变更日期和变更者? 配置对象的属性是否反映了变更? 是否遵循了标记变更、记录变更、报告变更的软件配置管理过程? 所有相关的软件配置项是否都已正确地做了更新?在某些情形下，这些审核问题是作为正式技术评审的一部分提出的。但是当软件配置管理成为一项正式活动时，软件配置审核就被分开，而由质量保证小组执行了。5. 软件工程标准化(1) 软件工程标准化的意义在开发一个软件时，需要有许多层次、不同分工的人员相互配合；在开发项目的各个部分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把

45、这些错综复杂的关系协调好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，还需要进行阶段评审和验收测试。投入运行的软件，其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行为规范和衡量准则，使得各种工作都能有章可循。软件工程的标准化会给软件工作带来许多好处，比如： 可提高软件的可靠性、可维护性和可移植性； 可提高软件的生产率； 可提高软件人员的技术水平； 可提高软件人员之间的通信效率，减少差错和误解； 有利于软件管理；有利于降低软件产品的成本和运行维护成本； 有利于缩短软件开发周期。随着人们对计算机软件

46、的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写程序，扩展到整个软件生存期。诸如软件概念的形成、需求分析、设计、实现、测试、安装和检验。运行和维护，直到软件淘汰(为新的软件所取代)。同时还有许多技术管理工作(如过程管理、产品管理、资源管理)以及确认与验证工作(如评审和审核、产品分析、测试等)常常是跨越软件生存期各个阶段的专门工作。所有这些方面都应当逐步建立起标准或规范来。另一方面，软件工程标准的类型也是多方面的。根据中国国家标准GBT 155381995软件工程标准分类法，软件工程标准的类型有： 过程标准：如方法、技术、度量等。 产品标准：如需求、设计、部件、描述、计划、报告等。 专业标准：如职别、道德准则、认证、特许、课程等。 记法标准：如术语、表示法、语言等。(2) 软件工程标准的制定与推行软件工程标准的制定与推行通常要经历一个环状的生命周期, 如图10.15所示。最初，制定一项标准仅仅是初步设想，经发起后沿着环状生命期，顺时