第十章 软件质量保证 一、复习要求 1. 了解软件质量保证、质量保证活动与质量检验的概念。 2. 了解软件质量保证体系与质量保证的实施的概要。 3. 了解正式技术评审概要。包括评审会议、设计质量和程序质量的评审。 4. 了解软件配置管理的概念。包括配置项和基线概念、配置管理的主要工作。 5. 了解软件工程标准化的概念。包括软件工程标准化意义、软件工程标准的制定与推行、软件工程标准的层次、软件工程的国家标准。 6. 了解软件文档的概念。包括文档编制的要求、文档的作用、分类、文档的工作。 7. 了解软件过程与过程改进的概念。包括过程分类与过程模型、剪裁过程、过程模型建造技术、软件过程改进。 8. 了解软件过程能力评估的CMM模型，包括过程成熟度的概念、软件机构的能力成熟度模型、关键过程域、关键实践的概念。 9. 了解ISO 9000国际标准。包括质量管理、质量认证和质量审核的概念，ISO 9000系列标准的特点、科学依据、主要内容，以及ISO 9000-3标准。 二、内容提要 1. 软件质量保证 (1) 质量保证的概念 什么是质量保证？它是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。 软件的质量保证就是向用户及社会提供满意的高质量的产品。进一步地，软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品在软件生存期所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括的主要功能如： ( 制定和展开质量方针； ( 制定质量保证方针和质量保证标准； ( 建立和管理质量保证体系； ( 明确各阶段的质量保证业务； ( 坚持各阶段的质量评审； ( 确保设计质量； ( 提出与分析重要的质量问题； ( 总结实现阶段的质量保证活动； ( 整理面向用户的文档、说明书等； ( 鉴定产品质量，鉴定质量保证体系； ( 收集、分析和整理质量信息。 (2) 软件质量保证(SQA)活动 软件质量保证由各项任务构成，这些任务的参与者有两种人：软件开发人员和质量保证人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。 软件开发人员通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产品。1993年美国SEI推荐了一组有关质量保证的计划、监督、记录、分析及报告的SQA活动。这些活动将由一个独立的SQA小组执行(或协助)： ① 为项目制定SQA计划。该计划在制定项目计划时制定，由相关部门审定。它规定了软件开发小组和质量保证小组需要执行的质量保证活动，其要点包括：需要进行哪些评价？需要进行哪些审计和评审？项目采用的标准；错误报告的要求和跟踪过程；SQA小组应产生哪些文档？为软件项目组提供的反馈数量等。 ② 参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过程，SQA小组则要评审过程说明，以保证该过程与组织政策、内部的软件标准、外界所制定的标准(如ISO 9001）以及软件项目计划的其它部分相符。 ③ 评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA小组识别、记录和跟踪所有偏离过程的偏差，核实其是否已经改正。 ④ 审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向项目负责人报告工作结果。 ⑤ 确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差可能出现在项目计划、过程描述、采用的标准或技术工作产品中。 ⑥ 记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解决。 除了进行上述活动外，SQA小组还需要协调变更的控制与管理，并帮助收集和分析软件度量的信息。 (3) 质量保证与检验 ① 检验在质量保证中的作用 软件质量必须在设计和实现过程中加以保证。如果过程管理不力，软件开发环境或软件工具不够好，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。 质量保证是面向消费者的，从质量保证的角度来讨论检查，下面几点应当明确： ( 用户要求的是产品所具有的功能，这是“真质量”。靠质量检验，一般检查的是“真质量”的质量特性。 ( 能靠质量检验的质量特性，即使全数检验，也只是代表产品的部分质量特性。 ( 必须在各开发阶段对影响产品质量的因素进行切实的管理，认真检查实施落实情况。只有这样才能使产品达到用户要求，这比单靠检验来保证质量要有效、经济。 ( 当开发阶段出现异常时，要从质量特性方面进行检验，看是否会给后续阶段带来影响，并对判断其好坏程度。从质量保证角度来看，此项工作极其重要。 ( 虽然各开发阶段进展稳定，但由于工具支持不足等，软件产品不能满足用户要求的质量。这时可通过检验对该产品做出评价，判断是否能向用户提供该产品。 ( 尽管各开发阶段进展稳定，但也要以一定的标准检验产品，使其交付使用后保持稳定的质量水平。同时还要根据产品的质量特性，检查各个过程的管理状态。 因此，检验的目的有二个。其一是切实搞好开发阶段的管理，检查各开发阶段的质量保证活动开展得如何；其二是预先防止软件差错给用户造成损失。 ② 各个开发阶段中的检验 为了切实做好质量保证，要在软件开发工程的各个阶段实施检验。检验的类型有： ( 供货检验：这是指对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件、规格说明、半成品或产品的检查。由于委托单位、委托时间等情况差别很大，往往与质量相关的信息不完全，要想只靠供货时检查，质量很难保证。因此要调查接受委托单位的开发能力，并且要充分交流情况。 ( 中间检验／阶段评审：在各阶段的中途或向下一阶段移交时进行的检查叫做中间检验或阶段评审。阶段评审的目的是为了判断是否可进入下一阶段进行后续开发工作，避免将差错传播到后续工作中，给后续工作带来不良影响，造成损失。 ( 验收检验：确认产品是否已达到可以进行“产品检验”的质量要求。 ( 产品检验：这是软件产品交付使用前进行的检查。其目的是判定向用户提供的软件，作为产品，是否达到了令人满意的程度。 检验的实施有两种形式：实际运行检验(即白盒测试和黑盒测试)和鉴定。可在各开发阶段中结合起来使用。各开发阶段及阶段中的检验如图10.1所示。   图10.1 开发阶段与相应的检验项目 2. 软件质量保证体系与质量保证的实施 (1) 软件质量保证体系 软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还要调查软件实现过程的状况，并根据情况检查设计是否有误，不当之处加以改进，防止再次发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与协作的机构十分重要，这个机构就是质量保证体系。图10.2和10.3是软件质量保证体系的图例。 在质量保证体系图上，用户、领导、各部门横向安排，而纵向则顺序列出软件质量保证活动的各项工作。制定质量体系保证图应注意以下一些问题： ( 必须明确反馈途径。 ( 必须在体系图的纵向(纵坐标方向)顺序写明开发阶段，在横向(横坐标方向)写明组织机构，明确各部门的职责。 ( 必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。 ( 必须明确决定是否可向下一阶段进展的评价项目和评价准则。 ( 必须不断地总结系统管理的经验教训，能够修改系统。 仅靠质量保证体系图很难明确具体工作，因此必须制定质量保证计划，在这个计划中确定质量目标，确定在每个阶段为达到总目标所应达到的要求，对进度做出安排，确定所需的人力、资源和成本等等。    图10.2 质量保证体系图例(程序检查) 在这个质量保证计划中包括的软件质量保证规程和技术准则应当 ( 指示在何时、何处进行文档检查和程序检查； ( 指示应当采集哪些数据，以及如何进行分析处理，例如，在每次评审和测试中发现的错误如何修正； ( 描述希望得到的质量度量； ( 规定在项目的哪个阶段进行评审及如何评审； ( 规定在项目的哪个阶段应当产生哪些报告和计划； ( 规定产品各方面测试应达到的水平。 在计划中，在说明各种软件人员的职责时，要规定为了达到质量目标他们必须进行哪些活动。其次，要根据这个质量保证体系图，建立在各阶段中执行质量评价的质量评价和质量检查系统及有效运用质量信息的质量信息系统，并使其运行。    图10.3 质量保证体系图(文档检查) (2) 质量保证的实施 软件质量保证的实施需要从纵向和横向两个方面展开。一方面要求所有与软件生存期有关的人员都要参加，另一方面要求对产品形成的全过程进行质量管理，这要求整个软件部门齐心协力，不断完善软件的开发环境。此外还需要与用户共同合作。 ① 质量目标与度量 为了开发高质量的软件，从计划阶段开始，不但需要明确软件的功能，还要明确软件应达到什么样的质量标准，即制定软件的质量目标。为了达到这个目标，在开发过程中的各个阶段进行检查和评价。在做质量评价时，需要有对质量进行度量的准则和方法，但更重要的是，需要有在软件生存期中如何使用这些准则和方法的质量保证步骤，以及提高该项作业效率的工具。 软件质量度量和保证的条件通常有以下几项： ( 适应性：必须制定能适应各种用户要求、软件类型和规模的质量标准，并能够度量。 ( 易学性：不需要特殊技术，软件技术人员人人都容易掌握。 ( 可靠性：对同一软件的评价，尽管评价的人或场合可能不同，但评价结果必须一致。 ( 针对性：不是在检查时才改进质量，而必须从设计阶段起就确立质量目标，在各个阶段实施落实。 ( 客观性：从各种不同角度加以评价，并将评价结果定量地表示，使得人人都能理解。 ( 经济性：考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。 ② 软件质量度量与保证的实施 图10.4给出软件质量度量和保证系统在质量保证活动中的五个实施步骤： ( Target：以用户要求和开发方针为依据，对质量需求准则、质量设计准则的各质量特性设定质量目标。对各准则的重要程度可以设“特别重要”、“重要”、“一般”三级。 ( Plan：设定适合于被开发软件的评测检查项目，与此同时还要研讨实现质量目标的方法或手段。 ( Do：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。在接受质量检查之前要先做自我检查。 ( Check：以Plan阶段设定的质量评价准则进行评价。算出得分，用质量图的形式表示出来，参看图10.5。比较评价结果的质量得分和质量目标，看其是否合格。 ( Action：对评价发现的问题进行改进活动，如果实现并达到了质量目标就转入下一个工程阶段。这样重复“Plan”到“Action”的过程，直到整个开发项目完成。 图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个方面检查：操作命令和操作信息的恰当性；输入数据和输入控制语句的恰当性；输出数据的恰当性和应答时间的恰当性。 ( 评审性能实现情况。一般来说，因性能设计是需要考虑多方面因素的复杂工作，因此，应明确规定性能的目标值。性能目标设定条件的恰当性；明确性能的评价方法。 ( 评审软件是否具有可修改性。需要考察系统是否具备以下功能：检测故障的功能，获取分析数据的功能；区分问题根源的方法；故障修正的方法。 ( 评审软件是否有可扩充性。 ( 评审软件是否具有兼容性。 ( 评审软件是否具有可移植性。 ( 评审软件是否具有可测试性：为保证软件在修改或扩充后的正确性，不仅要测试被修改或被扩充的部分是否能按规格执行，而且还应对该软件原有的功能经修改或扩充后是否能按以前的规格正确运行进行测试。 ( 评审软件是否具有可复用性。 ( 评审软件是否具有互连性：要求软件与其它软件应有共同接口，与其它软件之间的接口部分应是模块化的。 程序质量评审是着眼于软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。通常它是从开发者的角度进行评审，直接与开发技术有关。 ( 软件的结构。需要检查的项目有：数据结构、功能结构、数据结构和功能结构之间的对应关系。 ( 功能的通用性。 ( 模块层次。包括模块的层次结构，与功能层次的对应关系。 ( 模块结构。检查的项目有：控制流结构、数据流结构、模块结构与功能结构之间的对应关系，包括功能结构与控制流结构的对应关系；功能结构与数据流结构的对应关系。以及每个模块的定义。 ( 处理过程的结构。对它的检查项目有：要求模块的功能结构与实现这些功能的处理过程的结构应明确对应；要求控制流应是结构化的；数据的结构与控制流之间的对应关系应是明确的，并且可依这种对应关系来明确数据流程的关系。 ( 与运行环境的接口。主要检查项目有：与其它软件的接口；与硬件的接口；与用户的接口；变更的影响范围问题。 4. 软件配置管理 在软件建立时变更是不可避免的，而变更更加剧了项目中软件人员之间的混乱。之所以产生混乱，是因为在进行变更前没有仔细分析，或没有进行变更控制。Babich曾经这样说过：“协调软件开发使得混乱减到最小的技术叫做配置管理。配置管理是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产率”。 软件配置管理，简称SCM，是一种“保护伞”活动，它应用于整个软件生存期。因为变更在任何时刻都可能发生，因此软件配置管理活动的目标就是为了标识变更，控制变更，确保变更正确地实现，向其他有关的人报告变更。 软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，它们发生于软件已交付给用户并已投入运行之后；软件配置管理是一组追踪和控制活动，它们开始于软件开发项目开始之时，结束于软件被淘汰之时。 (1) 软件配置项(Software Configuration Item，简称SCI) 软件工程过程的输出有三种信息：计算机程序(源程序及目标程序)，描述计算机程序的文档(包括技术文档和用户文档)，数据结构。在软件工程过程中产生的所有的信息项(文档、报告、程序、表格、数据)就构成了软件配置。软件配置是软件的具体形态在某一时刻的瞬时影像。这样的具体形态取两种形式： ( 不可直接执行的材料：如书写的文档、程序清单、测试数据、测试结果等。 ( 可直接执行的材料：如目标代码、数据库信息等。它们可由计算机处理，存于某种存储介质上。 软件配置管理的对象就是软件配置项，它们是软件工程过程中产生的信息项。按照ISO 9000-3的说明，软件配置项可以是： ( 与合同、过程、计划和产品有关的文档和数据； ( 源代码、目标代码和可执行代码； ( 相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。 软件工具包括编辑程序、编译程序、其它CASE工具的特定版本，都要做为软件配置的一部分加以“冻结”。如果编译程序的版本不同，可能产生的结果也不同。 随着软件工程过程的进展，软件配置项数目快速增加。如果每个配置项只是简单地产生其它软件配置项，造成的混乱可能微乎其微。然而在变更时会引入其它影响因素，使得情况变得更加复杂。这时配置管理的作用就会充分显示出来。 不仅如此，所有以上提到的软件配置项在不同时期，出于不同的要求进行了各种组合，如针对不同的硬件环境和软件环境的各种组合，这就是软件配置的概念。在实现软件配置管理时，把软件配置项组织成配置对象，在项目数据库中用一个单一的名字来组织它们。一个配置对象有一个名字和一组属性，并通过某些联系“连接”到其它对象，如图10.6所示。图中分别对配置对象进行了定义，每个对象与其它对象的联系用箭头表示。箭头标明了构成关系。如“数据模型”和“模块N”是“设计规格说明”的一部分。双向箭头则表明一种相互关系。如果对“源代码”对象作了一个变更，软件人员可以根据这种相互关系确定其它哪些对象可能受到影响。 (2) 基线 (Baseline) 基线是软件生存期中各开发阶段末尾的特定点，又称里程碑。由正式的技术评审而得到的软件配置项协议和软件配置的正式文本才能成为基线。它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。例如，明确规定不允许跨越里程碑修改另一阶段的文档。如图10.7所示，是软件开发各阶段的基线。 一旦一个软件配置项成为基线，就把它存放到项目数据库(亦称项目信息库或软件仓库)中。当一位软件组织成员想要对基线配置项进行修改时，就把它从项目数据库中复制到该工程师的专用工作空间中，如图10.8所示。图中把一个标号为B的配置项从项目数据库复制到工程师的专用工作空间中。这个活动记录在一个记事文件中。工程师可以在B'(B的副本)上完成要求的变更，然后用B'来更新B。有些系统中把这个基线配置项锁定，在变更完成、评审和批准之前，不许对它做任何操作。 (3) 软件配置管理的过程 软件配置管理除了担负控制变更的责任之外，它还要担负标识单个的软件配置项和软件各种版本、审查软件配置以保证开发得以正常进行，以及报告所有加在配置上的变更等任务。 有关软件配置管理，需要考虑这样一些问题： ( 采用什么方式来标识和管理许多已存在程序(和它们的文档)的各种版本？ ( 在软件交付用户之前和之后如何控制变更？ ( 谁有权批准和对变更安排优先级？ ( 如何保证变更得以正确地实施？ ( 利用什么办法来估计变更可能引起的其它问题？ 这些问题归结到软件配置管理的5个任务，即配置标识、版本管理、变更控制、配置审核和配置报告。 (4) 配置标识 软件配置实际上是一个动态的概念。一方面随着软件生存期的向前推进，软件配置项的数量在不断增多。另一方面又随时会有新的变更出现，形成新的版本。因此，整个软件生存期的软件配置就象一部不断演变的电影，而某一时刻的配置就是这部电影的一个片段。 为了方便对软件配置的各个片段，即软件配置项进行控制和管理，不致造成混乱，首先应给它们命名，这就是配置标识的任务。 我们可以用面向对象的方法进行标识。通常需标识两种类型的对象：基本对象和复合对象。基本对象是由软件人员在分析、设计、编码和测试时所建立的“文本单元”。例如，基本对象可能是需求规格说明中的一节，一个源程序清单、一组用来测试一个等价类的测试用例。复合对象则是基本对象或其它复合对象的一个集合。如图10.6所示，“设计规格说明”是一个复合对象，它是一些基本对象，如“数据模型”、“模块N”的集合。 每个对象可用一组信息来唯一地标识它，这组信息包括： （名字、描述、一组“资源”、“实现”） 对象的名字是一个字符串，它明确地标识对象。对象描述是一个表项，它包括：对象所表示的配置项类型(如文档、程序、数据)、项目标识、变更和／或版本信息。资源是“由对象所提供的、处理的、引用的或其它所需要的一些实体”。例如，数据类型，特定函数，甚至变量名都可以看做是对象资源。而“实现”对于一个基本对象来说，是指向“文本单元”的指针，而对于复合对象来说，则为null。 配置对象的标识还需考虑在命名对象间存在的联系。对象可以是一个复合对象的组成部分，用联系<part of>进行标识。这个联系定义了对象的层次。在对象层次中，对象之间的联系不仅存在于层次树的路径中，而且可跨越对象层次的分支相互关联。例如，数据模型与数据流图是相互关联的，而且它又与一个特定等价类的测试用例组相互关联。 (5) 版本控制 整个软件工程过程中所涉及的软件对象都必须加以标识。在对象成为基线以前可能要做多次变更，在成为基线之后也可能需要频繁地变更。这样对于每一配置对象都可以建立一个演变图，这个演变图记叙了对象的变更历史。以图10.9为例，配置对象1.0经过修改成为对象1.1，又经历了小的修改和变更，产生了版本1.1.1和1.1.2。紧接对版本1.1做了一次更新，产生对象1.2，又持续演变生成了1.3和1.4版本。同时对对象1.2做了一次较大的修改，引出一条新的演变路径：版本2.0。 已经开发出来许多工具来辅助标识工作。在某些工具中，当前保持的只是最后版本的完全副本。为了得到较早时期(文档或程序)的版本，可以从最后版本中“提取”出(由工具编目的)变更，使得当前配置直接可用，并使得其它版本也可用。 在图10.9所示的演变图中，各结点都是聚合对象。软件的每一版本都是软件配置项(源代码、文档、数据)的一个集合，且各个版本都可能由不同的变种组成。例如，有一个简单的程序版本：它由1、2、3、4和5等部件组成，其中部件4在软件使用彩色显示器时使用，部件5在软件使用单色显示器时使用。因此，可以定义版本的两个变种： ① 部件1、2、3、4； ② 部件1、2、3、5。 版本控制的主要功能有： ① 集中管理档案，安全授权机制：版本管理的操作是将开发组的档案集中存放在服务器上，经系统管理员授权给各个用户。用户通过登入(check in)和检出(check out)的方式访问服务器上的文件，未经授权的用户则无法访问服务器上的文件。如图10.10所示。 ② 软件版本升级管理：每次登入时，在服务器上都会生成新的版本，软件版本的管理采取增量存储的方式。任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。如图10.11所示。 图10.11 软件版本升级管理 ③ 加锁功能：为了在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。某一文件一旦被登入，锁即被解除，该文件可被其它用户使用。在更新一个文件之前锁定它，避免变更没有锁定的项目源文件。 ④ 提供不同版本源程序的比较：在文件登入和检出时，需要注意检入和检出的使用。 ( 当某个时刻需要修改某个小缺陷或特征，应只检出完成工作必需的最少文件； ( 当需要对文件变更时，应登入它并加锁。这样可保留对每个变更的记录； ( 应避免长时间地锁定文件。如果需要长时间工作于某个文件，最好能创建一个分支，并在分支上做工作。这样别人可以地做缺省的“小”修改以更改较小的缺陷。稍后可通过合并，把所有操作结果集成在一起。 ( 如果需要做较大的变更，可有两种选择： ⅰ）将需要的所有文件检出并加锁，然后正常处理； ⅱ）为需要修改的版本创建分支，把变更与主干“脱离”，然后把结果合并回去。 (6) 变更控制 软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。 变更控制包括建立控制点和建立报告与审查制度。 对于一个大型的软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务。图10.12给出了变更控制的过程。   图10.12 变更控制过程 在此过程中，首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式提交给变更控制负责人(最终决定变更状态和优先权的某个人或小组)。对每个批准了的变更产生一个工程变更顺序(ECO)，描述进行的变更、必须考虑的约束、评审和审计的准则等。要做变更的对象从项目数据库中检出，对其做出变更，并实施适当的质量保证活动。然后再把对象登入到数据库中并使用适当的版本控制机制建立软件的下一版本。 “检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理人们存取或修改一个特定软件配置对象的权限；同步控制可用来确保由不同的人所执行的并发变更不会产生混乱。 存取和同步控制流如图10.13所示。根据经批准的变更请求和ECO，软件人员从项目数据库中检出要变更的配置对象。同步控制功能则封锁了项目数据库中的这个对象，使得当前检出的版本在没有被置换前不能再更新它。当然，对这个对象还可以检出另外的副本，但对其也不能更新。人们在对这种成为基线的对象做了变更，并经过适当的软件质量保证和测试之后，把修改版本登入项目数据库，再解除封锁。 软件的变更通常有两类不同的情况： ( 为改正小错误需要的变更。通常不需要从管理角度对这类变更进行审查和批准。但如果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，并修改所有受这个变更影响的文档。 ( 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。 应该把所做的变更正式记入文档，并相应地修改所有有关的文档。这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。需要注意的是，必须对每一项变更进行评价并对所有的变更进行跟踪和复审。 (7) 配置状态报告 为了清楚、及时地记载软件配置的变化，不致于到后期造成贻误，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录，并产生配置状态报告。报告对于每一项变更，记录以下问题：发生了什么？为什么会发生？谁做的？什么时侯发生的？会有什么影响？ 图10.14描述了配置状态报告的信息流。 图10.14 配置状态报告 每次新分配一个软件配置项或更新一个已有软件配置项的标识，或者一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目。一旦进行了配置审核，其结果也应该写入报告之中。配置状态报告可以放在一个联机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件人员。 配置状态报告对于大型软件开发项目的成功起着至关重要的作用。它提高了所有开发人员之间的通信能力，避免了可能出现的不一致和冲突。 (8) 配置审核 软件的完整性，是指开发后期的软件产品能够正确地反映用户所提出的对软件的要求。软件配置审核的目的就是要证实整个软件生存期中各项产品在技术上和管理上的完整性。同时，还要确保所有文档的内容变动不超出当初确定的软件要求范围。使得我们的软件配置具有良好的可跟踪性。这是软件变更控制人员掌握配置情况、进行审批的依据。 软件的变更控制机制通常只能跟踪到工程变更顺序产生为止，那么如何知道变更是否正确完成了呢? 一般可以用以下两种方法去审查：正式技术评审和软件配置审核。 正式的技术评审着重检查已完成修改的软件配置对象的技术正确性，评审者评价软件配置项，决定它与其它软件配置项的一致性，是否有遗漏或可能引起的副作用。正式技术评审应对所有的变更进行，除了那些最无价值的变更之外。 软件配置审核作为正式技术评审的补充，评价在评审期间通常没有被考虑的软件配置项的特性。软件配置审核提出并解答以下问题： ( 在工程变更顺序中规定的变更是否已经做了? 每个附加修改是否已经纳入? ( 正式技术评审是否已经评价了技术正确性? ( 是否正确遵循了软件工程标准? ( 在软件配置项中是否强调了变更? 是否说明了变更日期和变更者? 配置对象的属性是否反映了变更? ( 是否遵循了标记变更、记录变更、报告变更的软件配置管理过程? ( 所有相关的软件配置项是否都已正确地做了更新? 在某些情形下，这些审核问题是作为正式技术评审的一部分提出的。但是当软件配置管理成为一项正式活动时，软件配置审核就被分开，而由质量保证小组执行了。 5. 软件工程标准化 (1) 软件工程标准化的意义 在开发一个软件时，需要有许多层次、不同分工的人员相互配合；在开发项目的各个部分以及各开发阶段之间也都存在着许多联系和衔接问题。如何把这些错综复杂的关系协调好，需要有一系列统一的约束和规定。在软件开发项目取得阶段成果或最后完成时，还需要进行阶段评审和验收测试。投入运行的软件，其维护工作中遇到的问题又与开发工作有着密切的关系。软件的管理工作则渗透到软件生存期的每一个环节。所有这些都要求提供统一的行为规范和衡量准则，使得各种工作都能有章可循。 软件工程的标准化会给软件工作带来许多好处，比如： ( 可提高软件的可靠性、可维护性和可移植性； ( 可提高软件的生产率； ( 可提高软件人员的技术水平； ( 可提高软件人员之间的通信效率，减少差错和误解； ( 有利于软件管理；有利于降低软件产品的成本和运行维护成本； ( 有利于缩短软件开发周期。 随着人们对计算机软件的认识逐渐深入。软件工作的范围从只是使用程序设计语言编写程序，扩展到整个软件生存期。诸如软件概念的形成、需求分析、设计、实现、测试、安装和检验。运行和维护，直到软件淘汰(为新的软件所取代)。同时还有许多技术管理工作(如过程管理、产品管理、资源管理)以及确认与验证工作(如评审和审核、产品分析、测试等)常常是跨越软件生存期各个阶段的专门工作。所有这些方面都应当逐步建立起标准或规范来。另一方面，软件工程标准的类型也是多方面的。根据中国国家标准GB／T 15538－1995《软件工程标准分类法》，软件工程标准的类型有： ( 过程标准：如方法、技术、度量等。 ( 产品标准：如需求、设计、部件、描述、计划、报告等。 ( 专业标准：如职别、道德准则、认证、特许、课程等。 ( 记法标准：如术语、表示法、语言等。 (2) 软件工程标准的制定与推行 软件工程标准的制定与推行通常要经历一个环状的生命周期, 如图10.15所示。最初，制定一项标准仅仅是初步设想，经发起后沿着环状生命期，顺时针进行要经历以下的步骤： ( 建议：拟订初步的建议方案； ( 开发：制定标准的具体内容； ( 咨询：征求并吸取有关人员的意见； ( 审批：由管理部门决定能否推出； ( 公布：公布发布，使标准生效； ( 培训：为推行标准准备人员条件； ( 实施：投入使用，需经历相当期限； ( 审核：检验实施效果，决定修改还是撤消； ( 修订：修改其中不适当的部分，形成标准的新版本，进入新的周期。 为使标准逐步成熟，可能在环状生命周期上循环若干圈，需要做大量的工作。 (3) 软件工程标准的层次 根据软件工程标准制定的机构和标准适用的范围有所不同，它可分为五个级别，即国际标准、国家标准、行业标准、企业(机构)标准及项目(课题)标准。以下分别对五级标准的标识符和标准制定(或批准)的机构做一简要说明： ① 国际标准 由国际联合机构制定和公布，提供各国参考的标准。如ISO(International Standards Organization)──国际标准化组织。这一国际机构有着广泛的代表性和权威性，它所公布的标准也有较大的影响。1960年代初，该机构建立了“计算机与信息处理技术委员会”, 简称ISO／TC97，专门负责与计算机有关的标准化工作。这一标准通常冠有ISO字样，如ISO 8631－86 Information processing–program constructs and conventions for their representation《信息处理──程序构造及其表示法的约定》。该标准现已由中国收入国家标准。 ② 国家标准 由政府或国家级的机构制定或批准，适用于全国范围的标准，如： ( GB──中华人民共和国国家技术监督局是中国的最高标准化机构，它所公布实施的标准简称为“国标”。现已批准了若干个软件工程标准。 ( ANSI(American National Standards Institute)──美国国家标准协会。这是美国一些民间标准化组织的领导机构，具有一定的权威性。 ( FIPS(NBS) (Federal Information Processing Standards(National Bureau of Standards))──美国商务部国家标准局联邦信息处理标准。它所公布的标准均冠有FIPS字样。如1987年发表的FIPS PUB 132－87 Guideline for validation and verification plan of computer software (软件确认与验证计划指南)。 ( BS(British Standard)──英国国家标准。 ( DIN(Deutsches Institut für Normung)──德国标准协会 ( JIS(Japanese Industrial Standard)──日本工业标准 ③ 行业标准 由行业机构、学术团体或国防机构制定，并适用于某个业务领域的标准，如： ( IEEE(Institute of Electrical and Electronics Engineers)──美国电气与电子工程师学会。近年该学会专门成立了软件标准分技术委员会(SESS)，积极开展了软件标准化活动，取得了显著成果，受到了软件界的关注。IEEE通过的标准经常要报请ANSI审批，使之具有国家标准的性质。因此，日常看到IEEE公布的标准常冠有ANSI的字头。例如，ANSI／IEEE Str 828－1983《软件配置管理计划标准》。 ( GJB──中华人民共和国国家军用标准。这是由中国国防科学技术工业委员会批准，适合于国防部门和军队使用的标准。例如，1988年实施的GJB 437－88《军用软件开发规范》；GJB 438－88《军用软件文档编制规范》。 (3) DOD_STD(Department Of Defense_STanDards)──美国国防部标准，适用于美国国防部门。 ( MIL_S(MILitary_Standard)──美国军用标准，适用于美军内部。 此外，近年来中国许多经济部门(例如，原航空航天部、原国家机械工业委员会、对外经济贸易部、石油化学工业总公司等)都开展了软件标准化工作，制定和公布了一些适合于本部门工作需要的规范。这些规范大都参考了国际标准或国家标准，对各自行业所属企业的软件工程工作起了有力的推动作用。 ④ 企业规范 一些大型企业或公司，由于软件工程工作的需要，制定适用于本部门的规范。例如，美国IBM公司通用产品部(General Products Division)1984年制定的《程序设计开发指南》，仅供该公司内部使用。 ⑤ 项目规范 由某一科研生产项目组织制定，且为该项任务专用的软件工程规范。例如，计算机集成制造系统(CIMS)的软件工程规范。 (4) 软件工程的国家标准 1983年5月中国原国家标准总局和原电子工业部主持成立了“计算机与信息技术标准化技术委员会”，下设十三个分技术委员会。与软件相关的程序设计语言分委员会和软件工程技术分委员会。中国制定和推行标准化工作的总原则是向国际标准靠拢，对于能够在中国适用的标准一律按等同采用的方法，以促进国际交流。这里，等同采用是要使自己的标准与国际标准的技术内容完全相同，仅稍做编辑性修改。 从1983年起到现在，中国已陆续制定和发布了20项国家标准。这些标准可分为4类： 　　 ① 基础标准； ② 开发标准； ③ 文档标准； ④ 管理标准。 在表10.1所示的表中分别列出了这些标准的名称及其标准号。除去国家标准以外，近年来中国还制定了一些国家军用标准。根据国务院、中央军委在1984年1月颁发的军用标准化管理办法的规定，国家军用标准是指对国防科学技术和军事技术装备发展有重大意义而必须在国防科研、生产、使用范围内统一的标准。凡已有的国家标准能满足国防系统和部队使用要求的，不再制定军用标准。 表10.1 中国的软件工程标准 分类 标 准 名 称 标 准 号   信息处理——数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编辑符号及约定 GB 1526―89 ISO 5807―1985   软件工程术语 GB/T 11457―89    软件工程标准分类法 GB/T 15538―95 ANSI/IEEE 1002   信息处理——程序构造及其表示法的约定 GB 13502―92 ISO 8631   信息处理——单命中判定表的规范 GB/T 15535―95 ISO 5806   信息处理系统——计算机系统配置图符号及其约定 GB/T 14085―93 ISO 8790   软件开发规范 GB 8566―88    计算机软件单元测试 GB/T 15532―95    软件支持环境     信息处理——按记录组处理顺序文卷的程序流程  ISO 6593―1985   软件维护指南 GB/T 14079―93    软件文档管理指南     计算机软件产品开发文件编制指南 GB 8567―88    计算机软件需求说明编制指南 GB 9385―88 ANSI/IEEE 829   计算机软件测试文件编制规范 GB 9386―88 ANSI/IEEE 830   管 理 标 准 计算机软件配置管理计划规范 GB/T 12505―90 IEEE 828   信息技术 软件产品评价 质量特性及其使用指南 GB/T 12260―96 ISO/IEC 9126―91   计算机软件质量保证计划规范 GB 12504―90 ANSI/IEEE 730   计算机软件可靠性和可维护性管理 GB/T 14394―93    质量管理和质量保证标准 第三部分：GB/T 19001―ISO 9001在软件开发、供应和维护中的使用指南 GB/T 19000.3― 94 ISO 9000―3―93  6. 软件文档 (1) 什么是文档 文档(document)是指某种数据媒体和其中所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的东西。在软件工程中，文档常常用来表示对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信息。它们描述和规定了软件设计和实现的细节，说明使用软件的操作命令。 文档是软件产品的一部分，没有文档的软件就不成其为软件。文档的编制在软件开发工作中占有突出的地位和相当大的工作量。高质量、高效率地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要的意义。 (2) 软件文档的作用 在软件的生产过程中，总是伴随着大量的信息要记录、要使用。因此，软件文档在产品的开发生产过程中起着重要的作用。 ( 提高软件开发过程的能见度。把开发过程中发生的事件以某种可阅读的形式记录在文档中。管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据，实现对软件开发的工程管理。 ( 提高开发效率。软件文档的编制，使得开发人员对各个阶段的工作都进行周密思考、全盘权衡、从而减少返工。并且可在开发早期发现错误和不一致性，便于及时加以纠正。 ( 作为开发人员在一定阶段的工作成果和结束标志。 ( 记录开发过程中的有关信息，便于协调以后的软件、开发、使用和维护。 ( 提供对软件的运行、维护和培训的有关信息，便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解。使软件开发活动更科学、更有成效。 ( 便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合自己需要的软件提供依据。 文档在开发过程中起到了关键作用。从某种意义上来说，文档是软件开发规范的体现和指南。按规范要求生成一整套文档的过程，就是按照软件开发规范完成一个软件开发的过程。所以，在使用工程化的原理和方法来指导软件的开发和维护时，应当充分注意软件文档的编制和管理。 (3) 文档的分类 软件文档从形式上来看，大致可分为两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类是应编制的技术资料或技术管理资料，可称之为文档或文件。 软件文档的编制，可以用自然语言，特别设计的形式语言，介于两者之间的半形式语言(结构化语言)，各类图形表示。表格来编制文档。文档可以书写，也可以在计算机支持系统中产生，但它必须是可阅读的。 按照文档产生和使用的范围，软件文档大致可分为三类： ① 开发文档：这类文档是在软件开发过程中，作为软件开发人员前一阶段工作成果的体现和后一阶段工作依据的文档。包括软件需求规格说明、数据要求规格说明、概要设计规格说明、详细设计规格说明、可行性研究报告、项目开发计划。 ② 管理文档：这类文档是在软件开发过程中，由软件开发人员制定的需提交人员的一些工作计划或工作报告。使管理人员能够通过这些文档了解软件开发项目安排、进度、资源使用和成果等。包括项目开发计划、测试计划、测试报告、开发进度月报及项目开发总结。 ③ 用户文档：这类文档是软件开发人员为用户准备的有关该软件使用、操作、维护的资料。包括用户手册、操作手册、维护修改建议、软件需求规格说明。 (4) 软件文档的工作 国家标准局在1988年1月发布了《计算机软件开发规范》和《软件产品开发文件编制指南》，作为软件开发人员工作的准则和规程。它们基于软件生存期方法，把软件产品从形成概念开始，经过开发、使用和不断增补修订，直到最后被淘汰的整个过程应提交的文档归于以下十三种。下面对其中每一个文档做一些简要的说明： ( 可行性研究报告：说明该软件项目的实现在技术上、经济上和社会因素上的可行性，评述为合理地达到开发目标可供选择的各种可能的实现方案，说明并论证所选定实施方案的理由。 ( 项目开发计划：为软件项目实施方案制定出的具体计划。它应包括各部分工作的负责人员、开发的进度、开发经费的概算、所需的硬件和软件资源等。项目开发计划应提供给管理部门，并作为开发阶段评审的基础。 ( 软件需求规格说明：对所开发软件的功能、性能、用户界面机运行环境等作出详细的说明。它是用户与开发人员双方对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。 ( 数据要求规格说明：给出数据逻辑描述和数据采集的各项要求，为生成和维护系统的数据文件做好准备。 ( 概要设计规格说明：是概要设计工作阶段的成果。它说明系统的功能分配、模块划分、程序的总体结构、输入输出及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。 ( 详细设计规格说明：着重描述每个模块如何实现，包括实现算法、逻辑流程等。 ( 用户手册：详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。 ( 操作手册：为操作人员提供该软件各种运行情况的有关知识，特别是操作方法细节。 ( 测试计划：针对组装测试和确认测试，需要为组织测试制定计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ( 测试分析报告：测试工作完成以后，应当提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论性意见。 ( 开发进度月报：该月报是软件人员按月向管理部门提交的项目进展情况的报告。报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ( 项目开发总结报告： 软件项目开发完成之后，应当与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外，还需对开发工作作出评价，总结经验和教训。 ( 维护修改建议：软件产品投入运行之后，可能有修正、更改等问题，应当对存在的问题、修改的考虑以及修改的影响估计等做详细的描述，写成维护修改建议，提交审批。 以上这些软件文档是在软件生存期中，随着各个阶段工作的开展适时编制的。其中，有的仅反映某一个阶段的工作，有的则需跨越多个阶段。表10.2给出了各种文档应在软件生存期中哪个阶段编写。表10.3说明哪些人与哪些文档的编制有关。 表10.2 软件开发项目生存期各阶段与各种文档编制工作的关系 表10.3 人员与文档关系 阶 段 文 档             可行性研究报告             项目开发计划             软件需求规格说明             数据要求规格说明             测试计划             概要设计规格说明             详细设计规格说明             用户手册             操作手册             测试分析报告             开发进度月报             项目开发总结             程序维护手册 (维护修改建议)              (5) 对文档编制的质量要求 为使软件文档能起到多种桥梁的作用，使它有助于程序员编制程序，有助于管理人员监督和管理软件的开发，有助于用户了解软件的工作和应做的操作，有助于维护人员进行有效的修改和扩充，文档的编制必须保证一定的质量。 高质量的文档应当体现在以下几个方面 ① 针对性：文档编制以前应分清读者对象。按不同的类型、不同层次的读者，决定怎样适应他们的需要。例如，管理文档主要面向管理人员，用户文档主要面向用户，这两类文档不应像开发文档(面向开发人员)那样过多使用软件的专用术语。 ② 精确性：文档的行文应当十分确切，不能出现多义性的描述。同一课题几个文档的内容应当是协调一致，没有矛盾的。 ③ 清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。 ④ 完整性：任何一个文档都应当是完整的、独立的，它应自成体系。例如，前言部分应做一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。 同一课题的几个文档之间可能有些部分内容相同，这种重复是必要的。不要在文档中出现转引其它文档内容的情况。例如，一些段落没有具体描述，而用“见××文档××节”的方式，这将给读者带来许多的不便。 ⑤ 灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，能一律看待。 ( 应根据具体的软件开发项目，决定编制的文档种类。软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定。主要是：在不同条件下，应该形成哪些文档？这些文档的详细程度？该开发单位每一个项目负责人都应当认真执行这个实施规定。 ( 当所开发的软件系统非常大时，一种文档可以分成几卷编写。例如，项目开发计划可分写为：质量保证计划、配置管理计划、用户培训计划、安装实施计划等。系统设计规格说明可分写为：系统设计规格说明和子系统设计规格说明。程序设计规格说明可分写为：程序设计规格说明、接口设计规格说明和版本说明。操作手册可分写为：操作手册和安装实施过程。测试计划可分写为：测试计划、测试设计规格说明、测试规程、测试用例。测试分析报告可分写为：综合测试报告、验收测试报告。项目开发总结报告也可分写成：项目开发总结报告、资源环境统计。 ( 应根据任务的规模、复杂性、项目负责人对该软件的开发过程及运行环境所需详细程度的判断，确定文档的详细程度。 ( 对国标GB8567―88《计算机软件产品开发文件编制指南》所建议的所有条款都可以扩展，进一步细分，以适应需要；反之，如果条款中有些细节并非必需，也可以根据实际情况压缩合并。 ( 程序的设计表现形式，可以使用程序流程图、判定表、程序描述语言(PDL)、或问题分析图(PAD)等。 ( 对于文档的表现形式，没有规定或限制。可以使用自然语言、也可以使用形式化的语言。 ( 当国标《计算机软件产品开发文件编制指南》中所规定的文档种类不能满足某些应用部门的特殊需要时，可以建立一些特殊的文档种类要求。这些要求可以包含在本单位的文档编制实施规定中。 ⑥ 可追溯性：由于各开发阶段编制的文档与各个阶段完成的工作有密切的关系，前后两个阶段生成的文档，随着开发工作的逐步延伸，具有一定的继承关系，在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系。例如，某一项软件需求，必定在设计说明书、测试计划、甚至用户手册中有所体现。必要时应能做到跟踪追查。 7. 软件过程CMM标准与过程改进 软件过程是软件生存期中的一系列相关的过程，又称为软件生存期过程。过程是活动的集合，活动是任务的集合。任务是将输入变换为输出的操作。活动的执行可以是顺序的，重复的，并行的、嵌套的。 软件过程的考虑主要针对软件生产和管理。为了得到满足要求的软件产品，不但需要有好的开发方法，还需要有好的工程支持和工程管理。就是说，软件过程不仅要有工程观点，还应有系统观点、管理观点、运行观点和用户观点。 软件过程有多种分类。按照不同人员的工作内容来分，国际标准化组织在ISO∕IEC 12207―1995中将软件过程分为3类：基本过程、支持过程和组织过程。并且当把软件过程运用到相关组织，运用到具体应用论域和具体项目中时，可以根据特定情况。对各种过程和活动进行剪裁，形成所需要的软件过程模型。 (1) ISO∕IEC 12207―1995概要 图10.16给出了软件生存期的各种过程，其主要活动和使用者见表10.4。 图10.16 软件过程 表10.4 (a) 基本过程 1 获取过程(需方) (是需方为了获得一个软件产品所进行的一系列活动) 分析，确定，提出需求，准备招标，准备合同，监督供方，验收  2 供应过程(供方) (是供方为向需方提供软件产品所进行的一系列活动) 理解需求，准备投标，签定合同，制定及实施计划，评审及评价，交付  3 开发过程(开发者) (是软件开发者根据合同开发和交付软件的一系列活动) 准备实施：选择活动，制定计划，制定文档编制方式，安排支持过程 系统需求分析，系统结构设计 软件需求分析，体系结构设计，详细设计，编码，集成测试，确认测试 系统集成，系统确认，软件安装，软件验收支持  4 运行过程(运行者) (在软件开发过程完成后，将该软件从开发环境转移到用户的实际运行环境。在运行时对用户的要求提供帮助和咨询，并对运行效果进行评价) 准备实施：准备运行环境，制定运行过程实施计划和运行评价标准 系统运行，运行测试，对用户提供支持，系统运行评价，用户运行评价  5 维护过程(维护者) 准备实施：确定接受和反馈修改要求步骤，制定各支持过程实施方法 问题和变更分析，实施变更，维护评审和验收，移植，软件退役   表10.4 (b) 支持过程 1 文档编制过程 (是一个记录由某一过程或活动所产生的信息的过程) 制定文档编制计划，设计文档，制作文档，编辑，评审，批准，发行，维护  2 配置管理过程 制定配置管理计划，配置标识，版本控制，变更控制，配置报告，配置审核，发行管理和提交  3 质量保证过程 (是一个为使软件过程和软件产品符合规定需求，并按预定计划按时完成提供适当保证的过程) 过程剪裁，制定过程实施计划，产品、过程的质量保证  4 验证过程 (确定系统或软件的需求是否完备和正确, 以及每一阶段的软件产品是否达到前一阶段对它的要求和条件) 制定验证计划，合同、过程、需求、设计、代码、集成、文档的验证  5 确认过程 (确保最终产品满足预期的使用要求) 制定确认计划，准备测试需求、测试用例、测试规格说明 实施测试，确认度量标准，确认测试结果、软件产品用途的适用性  6 联合评审过程 (评审方与被评审方共同对某一活动或阶段的执行情况和产品进行评审) 项目管理评审，技术评审  7 审核过程 按项目实施计划定期举行，审核项目是否按需求、计划、合同完成 审核产品、测试数据和验收，审核测试报告和用户手册的完整性和适用性 审核进度和成本  8 问题解决过程 (分析和排除在开发、运行、维护或其它过程中发现的问题和不一致) 问题分类、排优先次序，启动有关活动指明问题原因，分析和解决问题 评价解决结果，确定是否引入新的问题   表10.4 (c) 组织过程 1 管理过程(管理者) (管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理，管理对象是进度、系统规模及工作量估算、经费、组织机构很人员、风险、质量、作业和环境配置等) 制定计划，实施和监控计划，评审和评价计划的完成程度，编写管理文档  2 基础设施过程 (建立、维护各个过程所需的基础设施的过程) 基础设施包括硬件、软件、工具、技术、标准, 以及开发、运行、维护所需的设施  3 改进过程 (建立、评估、度量、控制和改进软件生存期过程的过程) 制定组织计划，评估相关过程，实施分析，改进过程  4 培训过程 (为系统或软件产品提供人员培训的过程) 制定用人计划和培训计划，开发培训资料，实施培训活动   (2) 剪裁过程 为有效地实施软件过程，需要针对特定应用论域的软件工程，剪裁选定的软件过程模型和标准，以形成该工程的模型和标准，形成该工程的各个软件过程和活动。 剪裁过程是对软件过程和活动实施剪裁的过程。其主要活动有： ① 指明工程环境 指明影响剪裁的工程环境特征。如使用的工程模型和方法，软件需求，机构的政策和策略，软件规模、重要性和类型，参与人员和合作者的素质及人数。 ② 收集信息 向所有可能会影响剪裁的组织或个人收集信息。参与人员包括用户、工程支持人员、负责签定合同签定的人员、潜在的投标者。 ③ 选取过程、活动和任务 根据收集到的信息，确定要实施的过程、活动和任务。 ④ 编制文档 将所有的剪裁决策和作出这些决策的理由记入文档。 剪裁可分为两级：第一级，根据不同的应用论域进行剪裁；第二级，根据每一个具体项目或合同进行剪裁。 (3) 过程模型建造技术 软件过程建模是对实际软件过程的再工程。过程建模活动是软件过程中最主要的活动，所有其它的工程活动都是基于建模活动的结果进行的。过程建模技术包括建模目的、建模方法、建模语言、软件过程与过程模型的度量。其中，建模目的决定了建模活动的范围；建模方法和建模语言是对建模目的的支持和将过程模型形式化的手段，并决定了过程模型的质量；对过程模型的度量与评估是修改和演进过程模型的基础，使得过程模型能够更好地与软件工程相吻合，并充分地反映一个组织的过程成熟度。因而，建模方法与语言是过程建模技术的关键。 ① 过程建模的目的 ( 使人们易于理解软件过程并在此基础上进行交流。通过过程建模，可以使人们对过程达到一个共识，共享过程知识，并在此基础上进行交流。 ( 支持对过程的分析。通过对过程进行形式化或非形式化的建模，人么可以对过程活动和过程之间的相互关系进行分析、比较和预测，以评估和改善过程的有效性。 ( 支持过程中的通信。过程模型可以为有关人员、小组和项目提供必要的过程信息和通信支持，使人们之间的协同工作更加有效。 ( 支持过程的改进。对过程模型各部分的功效进行分析，找出可以改善的部分，对模型进行修改，并可在模型实际修改前估计修改产生的影响。从而支持严格管理下的过程进化。 ( 支持过程的管理。过程模型可以帮助人们制定项目计划，监控、管理和协调项目的实施过程，估算软件创建或演进时各活动的进展。过程模型还可以成为过程度量的基础。 ( 支持过程的复用。通过过程模型可以复用定义良好的软件过程。可以针对具体项目的特点，对已有的过程进行剪裁或扩充，使之适合特定项目的需要。 ( 提供对过程的自动执行支持。这需要一个基于过程驱动的软件工程环境。支持包括对用户的资源配置、提供各用户间的通信服务，组织和协调个人或小组间的工作等。 ② 过程建模方法 过程建模涉及到软件产品的开发和维护、软件项目管理、过程管理和过程改进等各个方面，涉及到过程的活动、角色、产品、资源和约束等各种过程实体，还涉及到建模所用的形式化方法，加上软件过程本身的复杂多样性，从而使得构造过程模型的方法也是多种多样的。考虑过程所涉及的实体和建模所采用的不同形式化方法，可以有两种不同的分类方法。 ( 考虑过程所涉及实体的分类方法 ⅰ) 以活动为中心的建模方法 首先考虑过程活动以及它们之间的执行顺序，再收集与各个活动相关的其它数据，如活动所涉及的角色、产品、资源和约束等，从而建立过程模型。这种方法能够直观地反映实际过程的工作流程，且无二义性，使人们可以很容易地理解、分析、计划、管理和控制过程的执行。缺点是，由于活动是动态实体，且实际流程也是动态多变的，因此，过程缺乏稳定性。实际过程中发生的任何变化都将影响原来的过程模型。此外，要求建模人员应具备所建模型的各种过程活动的知识，并在模型执行时进行一致性维护。这种模型适合于对实际过程的指导和控制。 ⅱ）以角色为中心的建模方法 首先确定各个角色的任务和角色之间的关系，再以角色为中心收集过程的其它数据，如活动、产品、资源和约束等，建立过程模型。由于角色是组织结构中的基本构成因素，是一个易于理解和接受的相对稳定的抽象实体，同时一个项目的任务通常是按角色进行分解的，所以，以角色为中心的缄默方法比较自然。而且角色是过程的一个不变的实体，因此，构造的过程模型比较稳定。这种方法还能够明确地描述过程的组织方面的信息，使得参与项目的人们易于明确自己的任务，便于对项目的计划、管理和控制。缺点是不能对过程的工作流程有一个显式的描述和定义，人们难以从整体上把握一个过程和他们在过程中的位置。另外，随着任务的逐步分解、细化，涉及的角色增多，角色之间的关系更加复杂，不利于低层次上的过程管理。 除了以上两种建模方法以外，还有以产品为中心的建模和基于过程模板的建模。 ( 考虑过程所采用的形式化方法的分类方法 ⅰ) 过程程序设计方法 这种建模方法的出发点是“软件过程也是软件”。Osterweil认为软件过程与软件产品具有广泛的类同性，对软件过程的描述也是一种程序设计形式。这种方法通过关系、谓词和触发器等机制对软件过程的功能、行为和对象进行详细、确定的算法描述。这种方法不是控制活动执行的方法，而是控制生产产品的交互过程。其优点是可以成功地进行交互控制，自动维护对象之间的一致性。缺点是严格过程化，不能支持大范围的兵法活动，无法描述软件过程的动态变化情况。 ⅱ) 功能分解方法 这种建模方法用一组反映输入∕输出关系的过程元素(数学函数)来表示软件过程。这组函数可以按照语法进一步层次分解，形成一个过程的多个子过程步。这种分解可以一直进行下去，直到产生的子过程步可以映射到一个外部工具或由人操作的过程为止。这种方法支持子过程步的并行执行、串行执行、迭代执行，还提供了控制过程状态行为的元操作，如创建、挂起、恢复执行等。 ⅲ) 基于Petri的建模方法 在当前的过程建模方法中，基于Petri网及其变种的建模方法较多。因为Petri网能够有效地形式化描述软件过程的并发性和活动与产品之间的关系，而且使用这种图形表示描述软件过程，易于理解和管理。其优点是较好地考虑了任务的激活条件、活动的执行顺序、活动产生的信息实体之间的转换情况。缺点是忽视了活动对内部状态所产生的影响。，另外，由于网络的全局相关性，使得对过程的任何改动都会影响到其它部分，不利于过程复用。 ⅳ) 基于规则的建模方法 基于规则的建模方法和语言是人们普遍看好的一种过程建模技术。这种方法提供了活动的动态链接机制，很自然地描述了过程的不可预见性，为人们控制过程提供了非常灵活的手段。基于规则的建模语言通常可提供回溯、向前链接、向后链接等自动执行机制，还可提供规则推理、调度和控制过程活动的机制，并可灵活方便地修改过程。其缺点是不利于人们理解软件过程，构造、分析过程模型时也比较困难，缺乏对并行工作与协同工作的支持。 ⅴ) 基于知识的建模方法 基于知识的建模方法提供了对过程模型的增量式形式说明能力和可复用能力。这种方法使用面向对象的技术把过程知识(如过程活动、过程实施者、产品对象和工具以及它们之间的关系等)抽象成不同的类，存放于知识库中。过程建模时，根据要求查询知识库，获取有关过程活动及其它成分的抽象描述，从中选取或构造所需的过程模型，并对其进行分析和推理，最后生成过程实例和相应的活动计划。用这种方法构造的过程模型是活动的类的层次结构，其中每个活动类与子类都对应有多种资源需求，如要加工的数据、所需工具、开发角色等。用类的继承关系描述可以表示各种过程关系，如控制流关系、任务的前置条件和后置条件、不同角色之间的上下级关系、产品的组成关系等。 一般来讲，建模是否成功，要看所建立的模型是否达到了建模目的。为了使建模方法具有通用性和适应能力，可以采用混合风格的建模方法，将多种风格形式化于一身。但这种方法要很好地处理各个模型成分之间的转换、通信、协调和相互作用等问题。 (4) 软件过程的改进 1983年美国TRW公司B.W.Boehm提出著名的软件工程七条原则： ( 按软件生存期分阶段制定计划并认真实施； ( 逐个阶段进行确认； ( 坚持严格的产品控制； ( 适用现代程序设计技术； ( 明确责任； ( 用人少而精； ( 不断改进开发过程。 由此可知，不断改进软件开发过程是软件工程的基本原理之一。 实践表明，软件过程需要不断完善。首先从非工程化的软件开发方式转变为工程化的软件开发方式，按照软件工程的系统方法进行软件的工程活动和管理活动，进而不断完善各个软件过程，不断提高软件过程能力。随着这种能力的提高，一个软件机构在完成软件产品时在预算、进度，特别是产品质量方面的风险不断降低。因此，软件过程能力的提高需要首先对当前的软件过程状况进行评估。 当前，在过程评估和过程改进方面已经做了很多工作，并制定出了具有指导意义的标准。表10.5列出了目前著名的几种软件过程评估和过程改进方案。 表10.5 几种软件过程评估和软件过程改进方案 推 出 机 构 名 称 时间 主 题  CMU―SEI 美国卡内基·梅隆大学软件工程研究所 CMM (Capability Maturity Model) 1987 软件过程能力成熟度模型  ISO 国际标准化组织 ISO 9001, ISO 9000―3 1994, 1997, 2000 建立和维持质量体系  ISO/IEC 国际标准化组织∕国际电工委员会 ISO/IEC TR15504 SPICE (Software Process Improvement and Capability dEtermination) 1997 软件过程改进和能力评估  DOD 美国国防部 MIL―STD―498 1984 软件过程改进  Bell 加拿大贝尔公司 TRILLTUM  软件过程评估(基于CMM)  德国联邦武装部队 V―Model 1992 软件过程定义  BOOTSTRAP Institute 欧共体 BOOTTSTRAP 1994 软件过程评估(基于CMM)   无论哪一种软件过程改进方案的实施都要从已有的软件过程开始，改进工作需经历一系列步骤。图10.17描述了这些步骤所构成的软件过程改进模式。 图10.17 软件工程改进的模式 ① 过程分析：考察和理解现有的过程。在一些情况下需要对过程的某些环节进行度量和定量分析，利用取得的数据来表明过程的状况。同时，这些数据可以用来与过程改进后的状况进行对比。 ② 确定改进：利用过程分析的结果，找出原有过程中质量、进度和成本的瓶颈。针对发现的问题，制定过程改进方案，提出需要采用什么规程、方法和工具的建议。 ③ 过程变更：实施过程变更，把新的规程、方法和工具安置于合适的过程环节上，并且与其它的软件过程活动集成起来。需要注意的是，要保证变更与其它的过程活动及更为广泛适用的机构规程和标准相协调。 ④ 培训：没有培训的过程变更在大多数场合注定要失败。有的单位在培训工作不够充分的情况下，强制推行过程变更，这样做也不会收到好的效果。 ⑤ 调整过程变更：在初步实施过程变更后，不可能立即收到完满的效果，在过程修改后还可能会出现一些小的问题，这就需要进行适当的调整。 过程改进的步骤需要反复进行。在完成调整后，又可能要返回去重新进行过程分析，再执行其后续步骤。此外，同时引入太多的变更是不切实际的。 8. 软件过程能力评估的CMM模型 (1) 软件机构的过程成熟度 软件开发的风险之所以大，是由于软件过程能力低。其中最关键的问题在于软件开发机构不能很好地管理其软件过程，从而使得一些好的开发方法和技术起不到预期的作用。当然，即使是在这样的机构中，个别软件项目仍能产生高质量的产品，但这是通过特定优秀软件人员的努力，而不是通过重复使用具有成熟软件过程的方法。在没有全机构范围的软件过程的情况下，能否继续成功地开发下一个项目，完全取决于能否留住这些优秀的软件人才。仅仅建立在特定人员上的成功不能为全机构的生产率和质量的长期提高打下基础，必须在建立有效的软件工程实践和管理实践的基础上，坚持不懈的努力，才能不断改进。 对于不同的软件开发机构，在组织人员完成软件项目中所依据的管理策略有很大差别，因而软件项目所遵循的软件过程也有很大差别。在此，我们用软件机构的成熟度(Maturity)加以区别。表10.6给出不成熟的软件机构和成熟的软件机构的比较。 表10.6 不成熟的软件机构和成熟的软件机构的比较 不成熟的软件机构 成熟的软件机构  软件过程 由参与开发的人员临时拼凑。有时即使确定了，实际上并不严格执行。 建立了软件开发和维护过程。人们对其有较好理解。一切活动均遵循过程的要求进行，做到工作步骤有次序，且有章可循。  管理方式 反应型：管理人员经常要集中精力去应付难以预料的突发事件。 主动型：软件过程不断改进，产品质量和客户满意程度负责质量保证的经理负责监控。  进度、经费估计 估计不切实际。在进度拖延情况下，不得不降低软件的质量。 根据以往项目取得的实践经验确定，因而比较符合实际情况。  质量管理 产品质量难以预测。质量保证活动，如质量评审、测试等，常被削弱或被取消。 产品质量有保证，软件过程有管理，具有必要的支持性基础设施。   在各个软件机构的过程成熟度有着相当大的差别面前，为了做出客观、公正的比较，需要建立一种衡量的标尺。使用这个标尺可以评价软件承包机构的质量保证能力，在软件项目评标活动中，选择中标机构。另一方面，这一标尺也必然成为软件机构改进软件质量，加强质量管理，以及提高软件产品质量的依据。 (2) 软件机构的能力成熟度模型CMM（Capability Maturity Model） 1987年美国卡内基―梅隆大学软件工程研究所(SEI)受美国国防部资助，提出了软件机构的能力成熟度模型CMM，经过几年的使用及1991年和1993年两次修改，现已成为具有广泛影响的模型。CMM将软件过程的成熟度分为5个等级，如图10.18所示。表10.7给出具有5个等级的软件机构的特征。 图10.18 软件过程成熟度模型 表10.7 各个等级的软件机构的特征 级别 1. 初始级 2. 可重复级 3. 已定义级 4. 已管理级 5. 已优化级   特 点 ·过程执行杂乱无序。 ·管理无章。 ·开发项目成效不稳定, 产品的性能和质量依赖于个人能力和行为。 ·管理制度化, 工作有章可循。 ·开发工作初步实现标准化。 ·变更基线化。 ·过程可跟踪。 ·新项目计划和管理基于过去实践经验, 具有重复以前成功项目的环境和条件。 ·开发过程标准化、文档化。 ·完善的培训和专家评审制度。 ·技术和管理活动稳定实施。 ·项目质量、进度和费用可控制。 ·项目过程、岗位和职责均有共同的理解。 ·产品和过程有定量质量目标。 ·过程的生产率和质量可度量。 ·有过程数据库。 ·实现项目产品和过程的控制。 ·可预测过程和产品质量趋势, 如预测偏差, 及时纠正。 ·不断改进过程, 采用新技术、新方法。 ·有防止缺陷, 识别薄弱环节及加以改进的手段。 ·可通过反馈取得过程有效性的统计数据并可据此进行分析, 改善过程。   (3) 跳跃成熟度等级的错误 处于较低等级的软件机构可以而且往往需要事实较高等级上的某些过程，例如，CMM中在等级3以前不讨论软件产品工程过程的活动，如需求分析、设计、编码、测试，但实际上处于等级1的软件机构都必须进行这些活动。又例如，处于等级1或等级2的机构可以组织同行专家评审，但这是属于等级3的。但是否可以得出一个结论：处于等级1的软件机构可以直接实施等级3的一些要求，从而它就可提升到等级3呢？这是不可以的。 跳跃等级是违反发展规律的。每个等级形成一个必要的基础，从此基础出发才能达到下一个等级。CMM划分5个等级，只是列出了在一个等级上占主导地位的问题。一个机构必须也必然逐步经历这些等级才能建立起优秀的软件工程文化。假如一个管理混乱的软件机构试图实施过程优化(等级5),由于没有可定量度量和跟踪的手段，对过程变更后可能产生的后果缺乏了解，这种过程优化最终会失败。 总而言之，软件能力成熟度等级的提高是一个循序渐进的过程，具有实施较高成熟度等级的某些活动的能力，并不表明可以跳跃成熟度等级。 (4) 关键过程域KPA（KPA，Key Process Area） 除去初始级以外，其它4 个等级都有若干个指导软件机构改进软件过程的要点，称为关键过程域。每一个关键过程域是一组相关的活动，且这些活动都有一些达标的标准，用以表明每个关键过程域的范围、边界和意图。为达到关键过程域的目标所采取的手段可能因项目而异，但一个软件机构为实现某个关键过程域，必须达到该关键过程域的全部目标。只有一个机构的所有项目都已达到某个关键过程域的目标，才能说该软件机构的以该关键过程域为特征的过程能力规范化了。 表10.8给出了各成熟度等级对应的关键过程域和主要工作。 表10.8 各成熟度等级对应的关键过程域 级别 1. 初始级 2. 可重复级 3. 已定义级 4. 已管理级 5. 已优化级   关 键 过 程 域  ·需求管理 ·软件项目策划 ·软件项目跟踪和监控 ·软件子合同管理 ·软件质量保证 ·软件配置管理 ·软件机构过程焦点 ·软件机构过程定义 ·培训大纲 ·集成软件管理 ·组间协调 ·软件产品工程 ·同行专家评审 ·定量过程管理 ·软件质量管理 ·过程变更管理 ·缺陷预防 ·技术变更管理   主 要 工 作 ·过程活动杂乱无序 ·开发过程的可重复性差 ·客户与软件项目间对客户要求有共同理解 ·制定软件工程和软件管理的合理的计划 ·建立适当的对实际进展的跟踪和监控 ·选择合格的软件承包方，并有效管理 ·提供对软件项目所采用的过程和产品质量的适当的可视性 ·需求变更和产品基线控制 ·规定软件机构在提高整体过程能力，改进软件过程活动方面的责任 ·开发和维持一批便于使用的软件过程财富 ·培训个人的技能和知识，以高效执行其任务 ·根据项目的要求裁剪和优化，将软件工程活动和管理活动集成为一个协调的定义良好的软件过程 ·制定组间合作的方法 ·一致地执行妥善定义的软件工程过程 ·通过设计评审、结构化走查或其它学院式评审方法实施同行评审 ·为已定义的过程建立一套详细的性能度量机制 ·为产品和过程设立质量目标，度量软件过程和产品 ·用第4级建立的度量机制，不断地改进软件机构中的软件过程 ·识别缺陷出现的原因，防止它们再次出现 ·识别能带来好处的新技术，以有序的方式引进这些新技术，能在不断变化的环境中高效率地创新   (5) 关键实践 关键实践是对关键过程域起关键作用的方针、规程、措施、活动以及相关基础设施的建立。为了达到关键过程域所规定的目标，必须实施相应的关键实践。每个关键过程域所包含的关键实践涉及5个方面：执行约定、执行能力、执行的活动、测量和分析、验证实施，人们统称为5个共同特征。关键过程域所包含的关键实践全部按这5个共同特征加以组织，如图10.19所示。 共同特征是表明一个关键过程域的实施和规范化是否有效、可重复且持久的一些属性。5个共同特征的含义如下。 ( 执行约定：描述一个机构在保证将过程建立起来并持续起作用方面所必须采取的行动。执行约定一般包括制定机构的方针和规定高级管理人员的支持。 ( 执行能力：描述为了实施软件过程，项目或机构中必须存在的先决条件。执行能力一般包括资源、组织机构和培训。 ( 执行的活动：描述为了实现一个关键过程域所必须的角色和规程(即描述必须由谁做什么)。执行的活动一般包括制定计划与规程、执行计划、跟踪执行情况，必要时采取纠正措施。 ( 测量和分析：描述对过程进行测量和对测量结果进行分析的需要。测量和分析一般包括一些为了确定所执行活动的状态及有效性所能采用的测量和分析。 ( 验证实施：描述保证遵照已建立的过程进行活动的措施。验证一般包括管理人员和软件质量保证部门所做的评审和审核。 国际上有一个公认的基本观点是：整个软件过程的改进是基于许多小的，进化的步骤，而不是通过一次革命性的创新来实现的。这些小的进化步骤就是通过关键实践来实现的。 (6) 软件人员能力成熟度模型 为了提高软件机构的生产能力，必须关注三个相关的因素：技术、过程和人员。软件人员能力成熟度模型采用了软件过程成熟度模型CMM的框架，帮助软件机构了解其劳动力管理活动的成熟度，将软件过程改进与劳动力管理的改进结合起来，指导软件机构管理和开发其劳动力资源。建立该模型的战略是： ( 通过提高劳动力的能力来提高软件机构的能力； ( 确保软件开发能力属于机构而不是个别人； ( 使员工的个人动机与机构的动机保持一致； ( 使机构能够留住人才(尤其是关键人才)。 软件人员能力成熟度模型(P-CMM)最早是由CMM小组成员Bill Curtis于1990年提出来的，1995年SEI正式公布了P-CMM的V1.0版。 作为成熟度模型，它是一个分级进化的模型，以作为机构循序渐进的指南。每一个成熟级别，既是机构发展的阶段性目标，又是评价机构能力水平的一个标准。 P-CMM包含了5个成熟度级别，如图10.20所示。 图10.20 软件人员能力成熟度模型的框架 ① 成熟度级别：是一个恰当定义的进化平台，反映软件机构在管理和开发人力资源能力方面所达到的水平。 ② 劳动力能力：软件开发机构中劳动力的知识和技能水平，以及劳动力用这些知识和技能提高业务工作绩效的能力。它直接决定企业的业绩和企业实现其商业目标的能力。 ③ 关键过程域：除了初始级，每个成熟度级别都可以由一组关键过程域组成，指明为达到该成熟度级别，机构应致力于在这几个领域内改善其工作。每一关键过程域又与一组目标相连接。当达到这些目标时，表明软件机构建立了该领域的劳动力的能力。 表10.9给出了P-CMM各成熟度等级对应的关键过程域和主要工作。 表10.9 P-CMM各成熟度等级对应的关键过程域 级别 1. 初始级 2. 可重复级 3. 已定义级 4. 已管理级 5. 已优化级   关 键 过 程 域  ·工作环境 ·交流与沟通 ·人员组织 ·业绩管理 ·培训 ·薪酬 ·知识与技能分析 ·劳动力规划 ·业务能力的开发 ·职业发展 ·基于资格能力的条例 ·建立参与和分享的企业文化 ·业务指导 ·团队建设 ·基于团队的条例 ·企业级的业务能力管理 ·企业级的业绩整合 ·个人业务能力的发展 ·教练 ·持续的劳动能力的创新   主 要 工 作 ·主管人员未经训练 ·员工业绩评估无计划 ·引进规章制度未经效率分析 ·不适当决策会引起员工不满 ·员工个人动机未与企业动机结合导致有更好工作环境或发展机会就会跳槽 ·建立和保持必须的工作环境，排除干扰 ·建立有利于沟通的氛围，确保上下通信渠道畅通 ·建立和实施一整套招聘、选拔、任命等人事制度 ·建立业绩考核体系和业绩汇报制度 ·明确培训需求，加强培训以保证员工掌握完成工作所需技能 ·根据员工对机构的价值和所做贡献来提供薪酬 ·明确企业关键业务过程所需的知识和技能，维持一定的知识和技能储备 ·为整个企业的劳动力能力发展建立目标和规划 ·制定培训计划或其它发展规划，从整体上提高企业的劳动力能力 ·激励员工，为员工学习薪技能、增长才干和追求更高目标提供机会 ·保证所有劳动条例都与劳动力知识与技能挂钩 ·在机构的各个层次上建立有效的通信渠道，使员工了解决策过程，并将决策结果告知员工 ·指定企业内有经验的人员作为个人或小组的业务指导 ·最大限度地集成并利用团队中不同的知识和技能为企业业务发挥作用 ·调整劳动力条例使其有利于促进团队的发展 ·增强企业关键业务的资格能力，建立资格能力增长的定量指标，定期收集数据，分析改进效果，利用分析结果指导有关工作的改进 ·建立个人、团队、部门、企业各级可度量目标，定期收集数据，分析发展趋势，处理例外情况，总结成果 ·为员工在业务上的自我发展奠定基础 ·选择合适的专家为指导，为个人或团队的业绩提高进行方法指导，评价业务进步情况 ·评价和确认有效的劳动力条例并保证其在全企业的贯彻执行。鼓励合理化建议，引进新的 条例并进行探索性的试验，推广有益的改革性措施   ④ 关键实践：每个关键过程域由关键实践构成，它是为保证关键过程域内容的有效实施和制度化而建立的基本活动。关键实践规定了在该领域的基本策略、步骤和活动。注意，关键实践只规定了做什么，不规定怎么做。 ⑤ 劳动力条例：在劳动力与员工管理领域中，为贯彻和实施企业内部政策而建立的程序和指南。如薪酬、业绩管理、团队建设、培训等方面的规定。 ⑥ 目标：目标概括了当关键过程域被有效而长久地实施后应达到的状态。完成目标的程度表明了机构在该成熟度级别上达到了何种能力。 ⑦ 共同特征：共同特征强调关键过程域的实施和制度化，关键过程域中的关键实践按共同特征分为5类。这5种共同特征是： ( 实施保证：涉及机构内部政策的制定和领导责任的确定。 ( 实施能力：描述先决条件、资源保证、组织结构和人员培训。 ( 实施活动：描述关键过程域的实施步骤和角色需要。一般包括工作规划、操作程序、具体实施、跟踪与调整。 ( 度量与分析：建立可操作的度量用例，以判定实施活动的状态和有效性。 ( 实施审核：检查所实施的活动是否符合已建立的政策和程序，涉及有关方面的审查和审核活动。 以上的5种特征中，以实施活动的比重最大，因为只有它具体描述了为建立劳动力能力所需要的实施过程。 ⑧ 软件人员能力成熟度模型的结构：按照SEI的定义，根据成熟度级别框架展开的P-CMM模型结构如图10.21所示。 P-CMM模型由5个成熟度级别构成，每个级别代表企业所达到的劳动力能力水平，每一级包含了若干个关键过程域，每一个关键过程域由一组相应的目标。为达到这些目标，应采取一系列基本措施和活动，这就是关键实践。应将这些关键实践的内容制度化，以保证其有效、长久地执行。为此，可用5种共同特征来概括和组织它们。根据不同侧重，这些特征中既有先决条件保证，又有具体实施操作程序，还有实施后的审查和审核等，从而保证了每个关键过程域目标的实现，进而实现向某一成熟度级别的进化。这样一个模型是可操作的，它对软件机构人员能力开发工作具有很大的指导意义。 ⑨ 主题：关键过程域是在每个级别上定义的，但是在跨越不同级别的关键过程域之间还存在着纵向的联系，这就是主题。所有关键过程域在P-CMM模型上可映射为4个主题，它们是发展能力、团队与文化建设、激励和管理业绩、形成劳动力。参看表10.10。 表10.10 主题及过程分类 主题 成熟度级别      5. 优化级 训练、个人业务能力发展   4. 已管理级 业务指导 团队建设 企业级的业务整合、基于团队的条例 企业级的业务能力 管理  3. 已定义级 业务能力、知识与技能分析 参与与分享的文化 基于业绩能力的条例、职业发展 劳动力计划  2. 可重复级 培训、交流与沟通 交流与沟通 薪酬、业绩管理、工作环境 人员组织  1. 初始级       在进行基于P-CMM的改进工作时，不应把它看作仅仅是人力资源部门的事情，尤其是和现行的软件过程改进项目一起实施时更是如此。SEI的P-CMM顾问委员会建议：在软件工程小组内加入人力资源管理人员，以进行基于P-CMM的改进工作。这样，带给软件机构管理层的信息就是：一个致力于改善整个软件过程能力的项目强调的是过程、技术和人员，缺一不可。基于P-CMM的改进工作和其它任何发展项目一样，第一要有计划，第二要跟踪其进展，第三要有专人负责。只有这样，才能保证P-CMM在企业的劳动力能力的发展方面发挥最大效益。 9. 在软件开发机构中贯彻ISO 9000国际标准 近年来，国际上影响最大的质量管理标准是国际标准化组织于1987年公布的ISO 9000系列标准。这一国际标准发源于欧洲经济共同体，但很快就波及美国。日本及世界各国。到目前为止，已有100多个国家在它们的企业中采用和实施这一系列标准。中国也采取了积极态度，确定对其等同采用，发布了与之相应的质量管理国家标准系列GB／T 19000；同时积极组织实施和开展质量认证工作。 (1) 质量管理 无论任何产业，其产品的质量如何都是生产者、消费者，以及中间商十分关注的问题。市场的竞争很大程度上反映了在质量方面的竞争，生产者(也称供方)为使自己提供给客户的产品达到并保持一定的质量水平，必须进行质量管理。质量管理包括以下的质量活动： ( 确定自己的质量方针和质量目标； ( 确定各个岗位的职责和权限； ( 建立质量体系，并使其有效运行。 质量体系是为实施质量管理所需的组织机构、程序、过程和资源。它包括：质量策划、质量控制、质量保证及质量改进等一系列活动。 质量管理的主要类型分为3种： ( 质量检验型：即对产成品进行检验。这是一种事后的、被动的方法。 ( 全面质量管理型：即从产品质量形成的全过程和企业全员努力两方面来提高工作质量以保证产品质量。这是一种积极的、主动的方法，但仅属于供方的活动。 ( 质量认证型：这是在全面质量管理基础上形成的质量管理手段，是从客户需要出发，以“确保顾客满意”为宗旨的消费者(也称需方)主导型的质量管理。目前在国际贸易中，往往是以对方是否通过了质量认证作为判断其产品质量水平和结成贸易伙伴的条件。 (2) 质量认证与质量审核 质量认证又称为合格认证。1986年国际标准化组织(ISO)定义质量认证为：由可以充分信任的第三方证实某一经鉴定的产品或服务符合特定标准或其它技术规范的活动。 质量认证的特点： ( 质量认证的对象是产品或服务，主要针对的是产品。其中对产品的质量认证分为对产品本身的质量认证和对产品生产过程的质量认证。 ( 认证的依据是标准。标准常常是被公认的或具有权威性的有关质量管理的国际标准或国家标准，也可能是行业标准或其它标准。认证审核就是检查对特定标准规定要求的符合性。符合标准要求就可通过审核，获得认证。 ( 通过审核、取得认证的标志是给予合格证书或准许使用合格标志。 ( 质量认证是第三方开展的活动。由具有专门技术、设备和人员的第三方，作为专门从事质量认证的机构，可以由国家权威机构授权，进行公正的、科学的质量审核和认证，因而是可以信赖的。供方和需方出具合格证明都不属于认证。 (3) ISO 9000系列标准的特点 ISO 9000系列标准的特点如表10.9所示。 表10.9 ISO 9000系列标准的特点 特点 主 要 表 现  国际性 国际组织制定，并向各国推荐，被100多个国家采纳为国家标准；多边互认。  完整性 从术语、质量保证、质量管理到支持性技术标准及实施指南，共计20个，形成完整体系。包括质量保证和管理的要求，质量体系建立，标准选用，审核人员条件，审核过程等。  兼容性 作为ISO 9000系列标准核心的3个质量保证标准不是互相孤立的，是互相包容的。ISO 9001标准最全面，ISO 9002和ISO 9003标准的适用范围依次缩小，如图10.20所示。  主动性 选用和实施ISO 9000标准，建立质量体系，出于自身提高机构内部质量管理水平的需要，叫做“管理者推动”。若出于客户要求，进而转变为供方意向，叫做“受益者推动”。无论哪一种情况向认证机构提出认证申请都是主动行为。  可信性 按ISO 9000标准建立的质量体系认证制度要求授权的认证机构对供方的质量体系进行公正全面、系统、公正的审核，且是独立进行。具有相当的说服力和可信性。  指导性 通常以标准为指导原则，结合机构自身的实际情况，特别是结合自身的企业文化，进一步发挥和创造，建立对自己有效的质量体系。  科学性 ISO 9000标准的背后隐藏着现代质量管理的科学原理。一些深刻的道理只有通过实践才能有所体会。  实践性 标准的文本不是空洞的条文，它与实际工作是密切结合的，可借以指导具体的实施和操作。此外，标准基于大量的质量管理实践。向前追溯，可知它源于英国国家标准和美国军用标准。认证制度则可追溯到20世纪初的英国质量管理机构。   ISO 9000质量保证标准的选择和使用 图10.20 ISO 9000质量保证系列标准之间的关系 (4) ISO 9000系列标准的科学依据 ISO 9000系列标准所体现的现代质量管理有其丰富的内涵，主要表现在以下几个方面： ① 产品质量并非在产品检验中得到，而是形成于生产的全过程。ISO 9000叙述了需方和供方应如何进行有组织的质量保证活动，才能得到较为满意的软件；规定了从双方签订开发合同到设计、实现以至维护整个生存期中应当实施的质量保证活动。 ② 为把握产品的质量，必须使影响产品质量的全部因素在生产全过程中始终处于受控状态。为使产品达到质量要求，ISO 9000要求开发机构建立质量体系。首先要求明确供需双方的职责，针对所有可能影响质量的各个因素都要采取有力措施，作出如何加强管理和控制的决定。对与质量有关的人员规定其职责和职权，使产品质量真正得到控制。 ③ 应使企业具有持续提供符合要求产品的能力。这正是质量保证的观念。在生产机构中建立质量体系，对所有影响产品质量的因素，包括技术、管理和人员，都进行有效的控制，可减少、消除和预防质量缺陷。如果能够向管理者和顾客表明，自己的质量体系具有持续稳定地满足质量要求的能力，就能取得两方面的信任。 ④ 质量管理必须坚持进行质量改进。产品质量取决于相关客户的满意程度。而这种满意程度与过程的合理组织和过程的效率直接相关。质量改进是一种以追求更高的过程效益和效率为目标的持续活动。质量改进是长期的任务。不断研究和改善质量管理制度是各级生产者的责任。 ⑤ 质量管理PDCA循环。任何管理工作，包括质量管理，都必须按照PDCA循环进行。该循环体现了管理的规律，参见图10.21。这4个方面缺一不可。当完成了4阶段的循环后，轮子已经前进，整个工作自然提升到一个新的阶段。 图10.21 PDCA循环 ⑥ 质量管理的核心是预防而不是补救。成熟的生产机构的良好素质表现在建立了有效的质量保证体系以后，可以及时纠正，特别是能够预防质量问题的发生。预防是主动的，是在质量事故之前；检验和补救是被动的，事后的，也必然是代价昂贵的。 (5) ISO 9000系列质量标准概要 ISO 9000系列质量标准现有20个，可分为5类，下面简要做一说明。 ① 质量术语标准 ·ISO 8402―1994 质量管理和质量保证──术语 ② 质量保证标准 ·ISO 9001 质量体系──设计／开发、生产、安装和服务中的质量保证模式； ·ISO 9002 质量体系──生产和安装中的质量保证模式； ·ISO 9003 质量体系──最终检验和测试中的质量保证模式； ·ISO 9004 质量管理和质量体系要素──导则。 ③ 质量管理标准 ·ISO 9004-1 质量管理和质量体系要素──第1部分：指南；―通用指南 ·ISO 9004-2 质量管理和质量体系要素──第2部分：服务指南；―针对服务业 ·ISO 9004-3 质量管理和质量体系要素──第3部分：流程性材料指南；―针对流体、气体、粒状等特定形态产品 ·ISO 9004-4 质量管理和质量体系要素──第4部分：质量改进指南； ④ 质量管理和质量保证标准的选用和实施指南 ·ISO 9000-1 质量管理和质量保证标准──第1部分：选择和使用指南； · ISO 9000-2 质量管理和质量保证标准──第2部分：ISO 9001、ISO 9002和ISO 9003的实施通用指南； ·ISO 9000-3 质量管理和质量保证标准──第3部分：ISO 9001：1994在计算机软件开发、供应、安装和维护中的使用指南； ·ISO 9000-4 质量管理和质量保证标准──第4部分：可信性大纲管理指南；―可信性包括可靠性、可维修性和可用性。 ⑤ 支持性技术标准 ·ISO 10005 质量计划指南 ·ISO 10007 技术状态管理指南 ·ISO 10011-1 质量体系审核指南──第1部分：审核； ·ISO 10011-2 质量体系审核指南──第2部分：质量体系审核员的评定准则； ·ISO 10011-3 质量体系审核指南──第3部分：审核工作管理； ·ISO 10012-1 测量设备的质量保证要求──第1部分：测量设备的计量确认体系； ·ISO 10012-2 测量设备的质量保证要求──第2部分：测量过程的控制； ·ISO 10013 质量手册编制指南。 从质量保证的要求来讲，ISO 9001是ISO 9000系列标准中一个很重要的质量保证标准，也是软件机构推行质量认证工作的一个基础标准。它于1994年由国际标准化组织公布，我国已及时将它转化为国家推荐标准，编号为GB∕T 19001―1。 ISO 9001标准在20个方面规定了供方在全部生产活动过程中的质量要求，有时人们将这20个方面称为20个质量体系要素。如表10.10所示。 表10.10 ISO 9001中的20个质量体系要素 编号 质量要素 主 要 职 责  1 管理职责 制定质量方针；对所有与质量相关的人员，包括执行人员和验证人员，规定职责、权限和相互关系；负责定期组织机构内的管理评审。  2 质量体系 建立质量体系；编制质量手册及一系列程序文件，并加以贯彻实施。  3 合同评审 在合同签订之前，对合同、标书或订单进行全面评审。使合同评审形成制度。  4 设计控制 供方在产品设计方面建立质量控制，保持稳定程序，并形成文件。其中包括：设计和开发的策划，组织上的接口和技术上的接口，确定设计输入，确定设计输出，对设计结果进行正式评审，实施设计验证和设计确认。  5 文件控制 对有关的所有文件和资料进行控制，包括审批适用性，防止使用失效或作废文件及审批更改，保证文件和资料适用、系统、协调和完整。  6 采购 供方对采购活动建立程序并加以保持。采购的质量控制包括：对分承包方的评价，对采购文件的要求和对采购产品的检验。  7 顾客提供产品的控制 供方应对顾客提供的产品建立及保持贮存和维护的控制程序并形成文件。  8 产品标识及可追溯性 供方应在接收和生产、交付及安装的各阶段以适当方式对产品进行标识，建立程序并形成文件。这种标识应具有唯一性和可追溯性。  9 过程控制 供方对直接影响质量的生产、安装和服务过程进行控制，制定程序并形成文件。  10 检验和试验 为使产品满足规定要求，供方应建立和保持检验和试验活动的程序并形成文件。包括进货、过程、最终的检验和试验以及对检验和试验的记录的要求。  11 检验、测量和试验设备 供方应对用以证实产品符合规定要求的检验、测量和试验设备建立并保持控制、校准和维修的程序，并形成文件。  12 检验和试验状态 对在检验和试验过程中处于不同状态(未检或待检、已检合格、已检不合格)的产品进行标识，防止不合格材料、半成品、部件和成品混入或误认。  13 不合格品的控制 供方应建立和保持对不合格品的控制程序并形成文件。，包括对不合格品的标识、记录、评审、隔离和处置，防止误用或安装。  14 纠正及预防措施 为消除实际已出现的不合格品及可能出现不合格品的根源，供方应建立并保持纠正和预防措施的程序并形成文件。  15 搬运、贮存、包装、防护及交付 供方应建立搬运、贮存、包装、防护及交付的程序并形成文件。  16 质量记录 供方应建立及保持对质量记录的标识、收集、编目、查阅、归档、储存、保管和处理的程序并形成文件。  17 内部质量审核 为验证质量活动和有关结果是否符合计划安排，确定质量体系的有效性，供方应对内部质量审核工作建立和保持程序并形成文件。  18 培训 对所有从事与质量有关工作的人员进行培训，要先明确培训要求并建立程序。  19 服务 在规定有服务要求的情况下，供方应建立和保持有关服务的实施、验证和报告的程序并形成文件。使服务能够满足规定要求。  20 统计技术 供方应建立并保持为分析过程能力和产品特性所采用的若干统计技术的实施程序并形成文件。   总而言之，上述各质量体系要素几乎都要求建立和保持程序并形成文件，此外还要求在执行程序的过程中保存记录。 为便于理解，将这20个质量体系要素分为5类，分别隶属于机构、管理者、工程、支持和顾客的类别下，如图10.22所示。图中括号内的数字表示质量体系要素的顺序号。 (6) ISO 9000-3标准 ISO 9000系列标准原是为制造硬件产品而制定的标准，不能直接用于软件制作。后来曾试图将ISO 9001改写用于软件开发方面，但效果不佳。于是，以ISO 9000系列标准的追加形式，另行制定出ISO 9000-3标准。这样，ISO 9000-3就成了用于“使ISO 9001适用于软件开发、供应及维护”的“指南”。不过，在ISO 9000-3的审议过程中，日本等国曾先后提出过不少意见。所以，在内容上与ISO 9001已有相当不同。此外，1997年公布的ISO 9000-3版本是又经过修改的版本，与我国的国家标准GB／T19000.3-94相比，其内容作了很大更改。 ISO 9000-3是一个指南性的标准，其指南性表现在： ( 从软件的角度对ISO 9001给出具体的说明和解释。在ISO 9001的20个质量体系要素的每一个要素后面，逐一对照作出说明和解释。 ( 指南性标准不是认证审核的依据，认证审核的依据是ISO 9001标准。就是说，在认证审核时，考察申请认证的软件机构针对ISO 9001的每一个质量体系要素的贯彻实施情况，审查有无与条文规定要求不符的情况，而不是考察有无违背ISO 9000-3的情况。 ISO 9000-3实际上是一个建议性的指南，而不是强制性的。它可以理解为：可以按此解释或建议去做，但如果有更好的做法，只要能够满足相关的ISO 9001标准规定的要求，也可以不按它的建议去做。ISO 9000-3对20个质量体系要素的解释如表10.11所示。 表10.11 理解ISO 9000-3对ISO 9001的20个质量体系要素的解释 编号 质量要素 解 释  1 管理职责 涉及质量方针、组织、管理评审。对软件无特殊要求。  2 质量体系 对质量策划提出6条建议，如用可测量的用语表示质量要求，指明适用的生存期模型，规定阶段的启动和结束准则，明确要执行的评审，测试等活动的类型，对配置管理进行详细的策划等。对质量计划做了较为详细的说明。  3 合同评审 对软件标书、合同或订单的评审提出几点建议。包括与顾客有关的事项，技术事项，管理事项，法律、安全和保密事项等。在合同修订与记录方面无特殊要求。  4 设计控制 软件的设计控制相当于软件开发，是软件质量保证的重点，说明有以下几点。 ① 总则：阐明软件开发中主要工作的质量控制。包括指明软件开发应涉及开发策划、需求分析、体系结构设计、详细设计和程序编码等活动；软件开发项目可按一个或多个生存期模型组织，并按模型计划和实施过程、活动和任务，至于采用何种模型不限；建立和保持软件开发形成文件的程序；建议考虑设计活动的若干方面；对编码建立形成文件的规则；工具、设施和技术可用于管理，也可用于开发和服务。 ② 设计和开发的策划：阐明软件开发计划或软件项目计划制定的有关问题。包括产品开发策划的活动；开发计划的评审与批准、提交；开发策划的内容等。 ③ 组织与技术接口：规定软件开发过程中有关方面在组织和技术上的关系。包括供方与分承包方之间确定职责范围、技术信息传递方式、分承包方开发计划的评审；顾客按合同规定的职责；供方和顾客联合评审的安排；还需考虑其它参与设计、安装、维护和培训的人员。 ④ 设计输入：设计输入是软件需求规格说明，需求最好由顾客提供要求，也可由供方提供，其内容要得到顾客认可；实现规定制定需求规格说明的方法；需求的更改应加以控制；制定需求规格说明的内容；要求需求能够在验收时确认。 ⑤ 设计输出：设计输出应包括设计规格说明、源代码、用户手册等。 ⑥ 设计评审：要求制定评审计划、设计评审内容、评审记录、评审程序、最终保存评审结果。 ⑦ 设计验证：是在开发过程中对阶段输出的检验。包括设计输出评审、原型和仿真演示或测试。此外，按质量计划或程序文件制定验证计划。 ⑧ 设计确认：在产品交付顾客验收之前，确认其预期的功能和性能。 ⑨ 设计更改：规定设计的更改应加以控制。  5 文件和资料控制 ① 总则：培植管理程序可用以实施文档和资料控制。包括软件文档、质量体系文件、开发管理文档等。 ② 文件和资料的批准和发布：若采用电子手段实现控制，要特别注意批准、存取、发放、媒体和归档程序。  6 采购 ① 总则：采购的产品应包括市售软件、分承包方开发的软件、硬件、工具软件、合同制工作人员、维护和顾客的支持服务、培训课程和教材。 ② 对分承包方的评价：无特殊要求。 ③ 采购资料：对软件开发的采购文档应有明确的要求。 ④ 对采购产品的验证：无特殊要求。  7 顾客提供产品的控制 顾客提供的产品可能包括软件产品、开发工具、开发环境、测试数据和运行数据、硬件及顾客专有信息。  8 产品标识及可追溯性 ① 任务：标识从规格说明到开发、复制与交付的所有软件项。若合同要求可适用于产品交付之后。 ② 实现方法是配置管理。包括配置管理定义；目标；提供功能；标识配置项时考虑；配置管理系统管理的产品；每一配置项应标识内容；配置管理计划内容。  9 过程控制 即对软件配置项或软件产品的复制、交付和安装的质量控制。包括复制规程；软件版本发行规程；安装和服务的考虑。  10 检验和试验 即对软件测试的质量控制。包括测试计划的内容；由第三方或顾客提供的软件产品的检验；验收前供方的确认测试；验收测试。  11 检验、测量和试验设备 即对软件测试工具的控制。包括对测试工具和测试技术的控制；对测试环境的测试。  12 检验和试验状态 即防止未经测试或测试有错的软件部件混入。应确定标识开发阶段和测试状态的方法。  13 不合格品的控制 即隔离不合格品。隔离方法：可从生产环境或测试环境转移到单独的环境；确定在哪些点控制和记录不合格品；可使用配置管理来实现；处置不合格品应注意的事项和方法。  14 纠正及预防措施 纠正措施涉及到变更，可使用配置管理控制变更；涉及软件生存期过程变更的纠正措施应经过评审；预防措施的依据是不合格品产生根源的分析和软件度量。  15 搬运,贮存,包装,防护及交付 重视防止病毒的侵害；防止静电和电磁环境的影响；防护的建议。  16 质量记录的控制 包括质量记录示例；在电子媒体上的质量记录的控制。  17 内部质量审核 包括审核在计划中对项目选择的考虑；项目质量计划与质量体系之间的协调。  18 培训 应考虑软件项目或产品开发和管理中用到的工具、技术、方法和计算机资源；考虑软件涉及的特定论域知识和技能的培训、资格认定培训。  19 服务 即软件的维护和对顾客的支持。包括软件维护的类型；合同中规定应维护的软件项；维护计划的内容；维护记录的内容。  20 统计技术 应考虑用统计技术的软件产品的特性；用统计技术的软件过程能力特性；量度的原则等。   三、例题分析 【例1】质量保证是为了保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向( A )的活动，是为了使产品实现( B )的功能。 软件质量保证活动即为了确定、达到和( C )需要的软件质量而进行的所有有计划、有系统的管理活动。为了提高软件的( D )和( E )，软件质量保证的主要任务主要有：正确定义用户要求；力争不重复劳动；掌握开发新软件的软件工程学方法和工具；组织外部力量协作开发；排除( F )；发挥每个开发者的能力；提高软件开发的( G )；提高( H )，即将评价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。 供选择的答案： A, B. ① 系统分析员 ② 开发者 ③ 消费者 ④ 软件需求 ⑤ 用户要求 C ( E. ① 测试 ② 维护 ③ 质量 ④ 价格 ⑤ 生产率 ⑥ 效率 F ( H. ① 冗余 ② 无效劳动 ③ 开发方法 ④ 工程过程能力 ⑤ 测试能力 ⑥ 计划和管理质量 ④ 测试和维护的效率 答案：A. ③, B. ⑤, C. ②, D. ③, E. ⑤, F. ②, G. ④, H. ⑥。其中，D、E的答案顺序可互换。 分析：软件质量保证是为保证产品和服务充分满足消费者要求的质量而进行的有计划、有组织的活动。质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上来掌握产品质量的。 软件的质量保证就是向用户及社会提供满意的高质量的产品。进一步地，软件的质量保证活动也和一般的质量保证活动一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括质量方针的制定和展开、质量体系的建立和管理等。为了提高软件的只链个和软件开发的生产率，软件质量保证的主要任务主要有： ( 熟练掌握正确定义用户要求的技术和支持工具； ( 力争不重复劳动，生产和使用可复用的软件； ( 掌握开发新软件的软件工程学方法和工具； ( 组织外部力量协作开发的方法，建立跟踪检查的体制； ( 排除无效劳动，力争减少因需求说明有误、设计有误而造成的返工以及重复劳动； ( 发挥每个开发者的能力，制定技术培训计划和技术水平标准； ( 提高软件开发的工程过程能力，即在软件开发环境的支持下，运用先进的开发技术、工具和管理方法开发软件的能力； ( 提高计划和管理质量，将评价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。 【例2】为了实现规定的质量特性，需要把这些质量特性转换为软件的( A )的特性。软件质量需求中的“性能”，可以转换成( A )中的( B )，即每一个程序模块和( C )各自应具有的性能特性。这些性能特性的累积就形成设计规格说明中的性能特性。这种情况也适用于( D )。在质量特性中，有一些特性与功能及用户界面有关，必须把这些功能或用户界面数据正确映射到( A )中来。这时，必须对软件的( E )进行评价。此外，决定软件“适用范围”的质量特性，取决于( A )中各种( F )部分是否实现( G )。 供选择的答案： A, B, C, E, F. ① 接口 ② 内部结构 ③ 结构特性 ④ 构成元素 ⑤ 结构单元 ⑥ 性能要求 ⑦ 物理数据 ⑧ 逻辑数据 D, G. ① 模块化 ② 可靠性 ③ 适应性 ④ 性能 ⑤ 结构化 答案：A. ②, B. ④, C. ⑦, D. ②, E. ③, F. ①, G. ①。 分析：为了实现规定的质量特性，就需要把这些质量特性转换为软件的内部结构的特性。软件质量需求中的“性能”，可以转换成软件内部结构中的构成元素，即每一个程序模块和物理数据各自应具有的性能特性。这些性能特性的累积就形成设计规格说明中的性能特性。这种情况也适用于“可靠性”。 在质量特性中，有一些特性与功能及用户界面有关，必须把这些功能或用户界面数据正确映射到内部结构中来。这时，必须对软件的结构特性进行评价。此外，决定软件“适用范围”的六个质量特性，取决于软件内部结构中各种接口部分是否实现模块化。 【例3】( A )是以提高软件质量为目的的技术活动。把( B )定义为“用户的满意程度”。为使得用户满意，有两个必要条件：(1)设计的规格说明要符合用户的要求；(2)程序要按照设计规格说明所规定的情况正确执行。把上述条件(1)称为( C )，把条件(2)称为( D )。与上述观点相对应，软件的规格说明可以分为( E )和( F )。( E )是从用户角度来看的，包括硬件／软件系统设计(在( G )阶段进行)、功能设计(在需求分析阶段与概要设计阶段进行)，而( F )是为了实现( E )的更详细的规格。 对( E )进行( A )时，( A )对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明，在软件概要设计阶段产生的软件概要设计规格说明等。 供选择的答案： A, B. ① 技术创新 ② 管理评审 ③ 技术评审 ④ 过程改进 ⑤ “质量” ⑥ “数量” C, D. ① 程序流程 ② 程序质量 ③ 设计要求 ④ 设计质量 E ( G. ① 内部规格说明 ② 外部规格说明 ③ 概要设计 ④ 详细设计 ⑤ 系统分析 ⑥ 需求分析 答案：A. ③, B. ⑤, C. ④, D. ②, E. ②, F. ①, G. ⑤。 分析：技术评审是以提高软件质量为目的的技术活动。为此，首先要明确什么是软件的质量。缺乏质量概念的技术评审只是一种拘于形式的为评审而评审的盲目工作。通常，把“质量”定义为“用户的满意程度”。为使得用户满意，有两个必要条件：(1)设计的规格说明要符合用户的要求；(2)程序要按照设计规格说明所规定的情况正确执行。我们把上述条件(1)称为“设计质量”，把条件(2)称为“程序质量”。优秀的程序质量是构成好的软件质量的必要条件，但不是充分条件。  与上述质量的观点相对应，软件的规格说明可以分为外部规格说明和内部规格说明。外部规格说明是从用户角度来看的规格，包括硬件／软件系统设计(在系统分析阶段进行)、功能设计(在需求分析阶段与概要设计阶段进行)，而内部规格说明是为了实现外部规格的更详细的规格，即程序模块结构设计与模块处理加工设计(在概要设计与详细设计阶段进行)。因此，内部规格说明是从开发者角度来看的规格说明。将上述两个概念联系起来，则可以说设计质量是由外部规格说明决定的，程序质量是由内部规格说明决定的。 针对外部规格说明进行设计评审时，评审对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明，在软件概要设计阶段产生的软件概要设计规格说明等。 【例4】评审软件是否有可扩充性，需要考虑可能的扩充、( A )和( B )。而软件的( C )是指当软件功能扩充了之后，其已有功能还能照原样使用的特性。注意( C )与( D )有区别。( D )是指软件运行环境改变时，可不改变软件的规格而能照原样工作的特性。( D )是与( C )相反的概念。 在评审( C )时，要考虑软件结构上的( E )，即如果一个软件由多个模块构成，在改变运行环境时，仅修改或更换因环境不同而受影响的那些( F )就可达到( C )。 供选择的答案： A, B. ① 结构化 ② 模块化 ③ 模块耦合性 ④ 模块通用性 C, D. ① 可移植性 ② 兼容性 ③ 可修改性 ④ 互操作性 E. ① 简明性 ② 清晰性 ③ 稳定性 ④ 结构性 F. ① 程序 ② 模块 ③ 语句 ④ 指令 答案：A. ②, B. ④, C. ②, D. ①, E. ③, F ②。其中，A、B的答案顺序可互换。分析：评审软件是否有可扩充性，需要考虑可能的扩充、模块化和模块的通用性。而软件的兼容性(或互换性)是指当软件功能扩充了之后，其已有功能还能照原样使用的特性。注意兼容性与可移植性有区别。，两者的比较参看图示。 可移植性是指软件运行环境改变时，可不改变软件的规格而能照原样工作的特性。可移植性是与兼容性相反的概念。兼容性表明在扩充了软件功能后，不影响(不改变)已有软件的运行环境；可移植性表明软件运行环境改变时，可不改变原有软件的规格说明而能照原样工作。 在评审兼容性时，要考虑软件结构上的稳定性，即如果一个软件由多个模块构成，在改变运行环境时，仅修改或更换因环境不同而受影响的那些模块就可达到兼容性。 【例5】按照软件配置管理的原始指导思想，受控制的对象应是( A )。( B )将软件配置管理定义成一门管理学科；( C )将软件配置管理定义成一种标识、组织和控制修改的技术；( D )指出配置管理过程是在整个软件生存期中实施管理和技术规程的过程。软件配置状态报告见图： 供选择的答案： A. ① 软件元素 ② 软件项目 ③ 软件配置项 ④ 软件过程 B ( D. ①《GB∕T 11457-1995 软件工程术语》 ②《ISO∕IEC 12207-1995 信息技术―软件生存期过程》 ③《ISO 9000-3：1997 质量管理和质量保证标准 第三部分：ISO 9001：1994在计算机软件开发、供应和维护中的使用指南》 ④ 巴比奇(W.Babich) E ( H. ① 配置审核 ② 配置标识 ③ 配置控制 ④ 配置状态报告 ⑤ 版本控制 ⑥ 基线与变更控制 答案：A. ③, B. ③, C. ④, D. ②, E. ②, F ③, G. ①, H. ④。 分析：在软件开发的各个阶段中得到的阶段产品并非是固定不变的。设计规格说明、程序，甚至需求规格说明都可能在开发过程的某些时刻出于某种原因需要变更。软件的这种经常变更的情况必须按一定的受控方式进行，否则就要出现混乱。这就是软件配置管理的原始指导思想。受控制的对象叫做软件配置项。 关于什么是软件配置管理，已出现多种定义。下面列出几种。 《ISO∕IEC 12207-1995 信息技术―软件生存期过程》：配置管理过程是在整个软件生存期中实施管理和技术规程的过程。它标识、定义系统中的软件项并指定基线；控制软件项的修改和发行；记录和报告软件项的状态和修改申请的完整性、协调性和正确性；以及控制软件项的储存、装载和交付。 《ISO 9000-3：1997 质量管理和质量保证标准 第三部分：ISO 9001：1994在计算机软件开发、供应和维护中的使用指南》：软件配置管理是一门管理学科，它对配置项的开发和支持生存期给予技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。 巴比奇(W.Babich)：软件配置管理能够协调软件的开发，使得混乱减小到最小。软件配置管理是一种标识、组织和控制修改的技术，其目的是最有效地提高生产率。 《GB∕T 11457-1995 软件工程术语》：软件配置管理是标识和确定系统中配置项的过程，在系统的整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 配置状态报告能够清楚、及时地记载软件配置的变化。每次新分配一个软件配置项或更新一个已有软件配置项的标识，或者一项变更申请被变更控制负责人批准，并产生了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目。一旦进行了配置审核，其结果也应当写入报告之中。配置状态报告可以放在联机数据库中，以便软件开发人员或软件维护人员可以对它进行查询或修改。此外，软件配置报告中新登录的变更应及时通知给软件管理人员和软件开发人员。 【例6】软件过程不断改进是( A )的基本原理之一，是( B )的基本过程之一。软件过程需要不断完善，首先从( C )的软件开发方式改变为( D )的软件开发方式，按照软件过程的系统方法进行软件的工程活动和管理活动，进而不断完善软件各个软件过程，从而不断提高( E )。( E )的提高首先需要对当前的软件过程状况进行科学的( F )。 供选择的答案： A, B. ① 软件过程 ② 软件工程七原理 ③ 软件生存期 ④ 软件需求 C, D. ① 工程化 ② 过程化 ③ 非过程化 ④ 非工程化 E. ① 软件工程能力 ② 软件过程能力 ③ 软件成熟度模型 F. ① 度量 ② 估算 ③ 评估 ④ 管理 答案：A. ②, B. ③, C. ④, D. ①, E. ②, F ③。 分析：软件过程不断改进是软件工程七原理的基本原理之一，也是软件生存期的基本过程之一。软件工程界的专家历来很重视软件过程的研究，20世纪70年代形成了软件生存期的概念，1995年正式发表了一个国际标准：ISO∕IEC 12207-1995 信息技术―软件生存期过程，这是软件工程过程研究的重要成果。实践表明，软件过程需要不断完善，首先从非工程化的软件开发方式改变为工程化的软件开发方式，按照软件过程的系统方法进行软件的工程活动和管理活动，进而不断完善软件各个软件过程，从而不断提高软件过程能力。随着这种能力的提高，一个软件机构在完成一个产品时在预算、进度，特别时产品质量方面的风险就会逐步降低。显然，软件过程能力的提高首先需要对当前的软件过程状况进行科学的评估。 【例7】CMM提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了( A )的基础。。这5个成熟度等级定义了一个( B )的尺度，用来衡量一个软件机构的( C )和评价其软件过程能力。每一个成熟度等级为继续改进过程提供了一个( D )。每一个等级包含了一组( E )，通过实施相应的一组( F )达到这一组( E )。5个成熟度等级各有其不同的行为特征，通过3个方面来表现，即一个机构为建立或改进软件过程所进行的活动，对每个项目所进行的活动和所产生的跨越各项目的过程能力。 供选择的答案： A, B. ① 无序 ② 有序 ③ 循环 ④ 循序渐进 C ( F. ① 基本特征 ② 关键实践 ③ 关键过程域 ④ 台基 ⑤ 过程目标 ⑥ 成熟度框架 ⑦ 软件过程成熟度 答案：A. ④, B. ②, C. ⑦, D. ④, E. ⑤, F ③。 分析：CMM提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了循序渐进的基础。。这5个成熟度等级定义了一个有序的尺度，用来衡量一个软件机构的软件过程成熟度和评价其软件过程能力，还能帮助软件机构自己对其改进工作排列优先次序。成熟度等级已得到确切定义，它是向成熟的软件机构前进途中的平台，每一个成熟度等级为继续改进过程提供了一个台基。每一个等级包含了一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标。当目标满足时，可使软件过程的一个重要成分稳定下来。每达到成熟度框架的一个等级，就建立起软件过程的一个相应成分，从而导致软件机构过程能力得到一定程度的提高。 5个成熟度等级各有其不同的行为特征，通过3个方面来表现，即一个机构为建立或改进软件过程所进行的活动，对每个项目所进行的活动和所产生的跨越各项目的过程能力。 【例8】P-CMM将软件人员能力成熟度模型的本质用于软件机构的劳动力能力发展工作，它可以更容易地集成到已有的软件过程改进的项目中，指导与人员管理有关的工作。P-CMM的价值取决于( A )，通常不外乎两种应用方式：一是作为( B )，评价劳动力工作的水平；二是作为( C )，用于改进和规范劳动力工作。当P-CMM评估与软件过程评估联合进行时，用于P-CMM评估的数据应( D )。因为软件过程评估的分析对象是( E )，而人员能力评估的分析对象是( F )。作为( C )，P-CMM的作用是为( G )提供框架，帮助企业找出劳动力条例体系中的( H )。 供选择的答案： A. ① 软件质量 ② 软件改进过程 ③ 软件企业如何使用它 ④ 软件企业目标 B, C. ① 发展的指南 ② 评估的标准 ③ 测试的目标 ④ 维护的方法 D. ① 集中收集 ② 分散应用 ③ 统一规划 ④ 单独收集 E ( H. ① 宏观发展 ② 微观应用 ③ 软件项目 ④ 薄弱环节 ⑤ 企业的部门和部门中劳动力条例的实施情况 ⑥ 关键过程域 答案：A. ③, B. ②, C. ①, D. ④, E. ③, F ⑤, G. ①, H. ④。 分析：P-CMM的价值取决于软件企业如何使用它，通常不外乎两种应用方式：一是作为评估的标准，评价劳动力工作的水平；二是作为发展的指南，用于改进和规范劳动力工作。当P-CMM评估与软件过程评估联合进行时，用于P-CMM评估的数据既单独收集，也可以结合企业内的其它评估一起进行，如软件过程评估、人员意向评估等。因为软件过程评估的分析对象是软件项目，而人员能力评估的分析对象是企业的部门和部门中劳动力条例的实施情况。作为企业劳动力能力发展的指南，P-CMM并不定义具体的劳动力条例。企业应根据自己的历史、行业特点及文化背景来选择、制定自己的劳动力条例。P-CMM的作用是为宏观发展提供框架，帮助企业找出劳动力条例体系中的薄弱环节。 【例9】所谓进行质量管理就是在自己的机构内开展下列的质量活动：确定自己的( A )和( B )；确定各个岗位的职责和权限；建立质量体系，并使其有效运行。( C )是为实施质量管理所需的组织机构、程序、过程和资源。( D )包括产品策划、管理和作业策划，以及质量计划的编制和( E )的准备工作。( E )是以追求更高的效益和效率为目标的持续性活动；( F )采取某些特定作业技术或展开某些活动以达到质量要求；( G )是供方为使用户确信能够满足质量要求所开展的有计划的和系统的活动，将所有影响质量的因素都得到有效的控制，从而证实确有减少、消除和预防出现质量缺陷的机制。 供选择的答案： A ( G. ① 质量改进 ② 质量保证 ③ 质量控制 ④ 质量体系 ⑤ 质量策划 ⑥ 质量方针 ⑦ 质量维护 ⑧ 质量目标 ⑨ 质量管理 答案：A. ⑥, B. ⑧, C. ④, D. ⑤, E. ①, F ③, G. ②。 其中，A、B的答案顺序可互换 分析：所谓进行质量管理就是在自己的机构内开展下列的质量活动： ( 确定自己的质量方针和质量目标； ( 确定各个岗位的职责和权限； ( 建立质量体系，并使其有效运行。 质量体系是为实施质量管理所需的组织机构、程序、过程和资源。它涉及到： ( 质量策划：包括产品策划、管理和作业策划，以及质量计划的编制和质量改进的准备工作。 ( 质量改进是以追求更高的效益和效率为目标的持续性活动； ( 质量控制：采取某些特定作业技术或展开某些活动以达到质量要求； ( 质量保证：是供方为使用户确信能够满足质量要求所开展的有计划的和系统的活动，将所有影响质量的因素都得到有效的控制，从而证实确有减少、消除和预防出现质量缺陷的机制。 四、习题 【10-1】软件质量必须在设计和实现过程中加以保证。为了确保每个开发过程的质量，防止把差错传播到下一个过程，必须进行( A )。( A )是质量保证活动的一个重要部分，其目的有两个：其一是切实搞好开发阶段的管理；其二是( B )软件差错给用户造成损失。( A )的实施有两种方式：( C )和( D )。( C )即白盒测试和黑盒测试。( A )的类型有( E )、( F )、( G )和( H )。 供选择的答案： A. ① 质量保证 ② 差错检测 ③ 质量检验 ④ 质量管理 B. ① 预先防止 ② 完全避免 ③ 减少 ④ 消除 C, D. ① 鉴定 ② 测试 ③ 实际运行管理 ④ 实际运行检验 E ( H. ① 供货检验 ② 集中测试 ③ 中间检验∕阶段评审 ④ 产品检验 ⑤ 用户检测 ⑥ 程序检测 ④ 验收检验 【10-2】为了开发高质量的软件，从计划阶段开始，不但要明确软件的功能，还要明确软件应当达到什么样的质量标准，即指定软件的质量指标。软件质量度量和保证的条件通常有以下几项：( A )，即必须制定能够适应用户要求、软件类型和规模的质量标准；( B ),即人人都容易掌握；( C )，即对于同一软件评价的结果必须一致；；( D )，即各阶段确立质量目标并落实；( E )，即从不同角度加以评价；( F )。软件的质量评价标准分为3级：( G )、( H )和( I )。( G )的着眼点是“是否满足用户的要求”；( H )的着眼点是“开发者在设计实现时是否按照软件需求保证了质量”；( I )是为定量度量软件质量而规定的一些检查项目。它们一级比一级( J )，一级比一级易于( K )。 供选择的答案： A ( F. ① 可靠性 ② 易学习性 ③ 适应性 ④ 针对性 ⑤ 客观性 ⑥ 经济性 ⑦ 主观性 ⑧ 多样性 G ( I. ① 子质量特性 ② 质量度量准则 ③ 质量特性 ④ 质量维护准则 ⑤ 质量管理准则 J, K. ① 抽象 ② 具体 ③ 检验 ④ 定量评价 【10-3】从技术上改进软件的开发过程，提高软件产品的质量无非是两个方面：一是提高( A )，二是改进( B )。在发现错误和排除错误方面更重要也是更困难的是( C )。由于软件测试技术方面没有多少新的突破，人们只能用加强阶段评审或是检查作为辅助手段。这是一个由同行人员小组( D )所开发的阶段产品的验证方法。至于改进( B )的新技术，是采用面向对象的开发技术或是建立( E )。一个诱人的说法是采用( F )技术，其基本思想在于( G )开发过程，使得差错或缺陷不可能有机可乘混入开发过程。 供选择的答案： A, B. ① 测试效率 ② 开发速度 ③ 开发过程 ④ 维护过程 ⑤ 测试方法 ⑥ 开发工具 C. ① 排除错误 ② 发现错误 D. ① 机器检查 ② 人工检查 ③ 集成测试 ④ 单元测试 E, F. ① 智能 ② 软件原型 ③ “净室”软件开发 ④ 基于构件的复用 G. ① 简化 ② 结构化 ③ 净化 ④ 强化 【10-4】软件配置项是软件配置管理的对象，指的是软件工程过程中所产生的( A )。不仅如此，而且在不同的时期，出于不同的要求，可进行各种组合，如针对不同的硬件环境和( B )的组合，这就是软件配置的概念。实施软件配置管理要做的事情有：制定( C )；实施( D )；实施版本管理和发行管理。制定适当的命名规则是( E )的重要工作，命名要求：( F )，目的在于避免出现重名，以免造成混乱；( G )，以反映命名对象之间的关系。 供选择的答案： A, B. ① 接口 ② 软件环境 ③ 信息项 ④ “版本” C ( E. ① 配置标识 ② 配置管理 ③ 配置管理计划 ④ 变更管理 ⑤ 版本变化 ⑥ 配置审核 F, G. ① 多态性 ② 唯一性 ③ 独立性 ④ 可追溯性 【10-5】在变更管理中，“检出”和“登录”处理实现了两个重要的变更控制要素，即( A )和( B )。( A )控制和管理各个软件技术人员存取或修改一个特定软件配置对象的权限；( B )可用来确保由不同的人所执行的并发的变更不会产生混乱。请选择适合的答案完成右图所示的存取和控制图。 供选择的答案： A, B. ① 异步控制 ② 同步控制 ③ 存取控制 ④ 基线控制 C, D. ① 登入 ② 检出 ③ 管理 ④ 填写变更请求 E. ① 审查人员 ② 配置人员 ③ 质量保证人员 ④ 软件工程人员 【10-6】软件工程标准的类型是多方面的。它可能包括( A )标准，如方法、技术、度量等；( B )标准，如需求、设计、部件、描述、计划、报告等；( C )标准，如职别、道德准则、认证、特许、课程等；( D )标准，如术语、表示法、语言等。根据中国国家标准GB∕T 15538-1995(软件工程标准分类法)规定，软件工程标准可用一张( E )来表示。 供选择的答案： A ( D. ① 专业 ② 产品 ③ 记法 ④ 过程 ⑤ 管理 E. ① 矩阵图 ② 一维的表格 ③ 二维的表格 ④ 帕列特图 【10-7】根据软件工程标准制定的机构和标准的适用范围有所不同，它可分为五个级别，即( A )、( B )、( C )、( D )和( E )。( A )由国际联合机构制定和公布，通常冠有ISO字样；而GB、ANSI、JIS等属于( B )；IEEE、GJB等属于( C )；( D )的实例是( F )；( E )是专用的软件工程规范，如( G )。 供选择的答案： A ( E. ① 国家标准 ② 国际标准 ③ 企业规范 ④ 项目规范 ⑤ 行业标准 F, G. ① DOD-STD ② FIPS(NBS) ③ BS ④ MIL-S ⑤ IBM的《程序设计开发指南》 ⑥ CIMS的《软件工程规范》 【10-8】下面关于标准和文档的叙述中正确的叙述为（ 、 、 、 、 ）。 ① 国家标准是由政府或国家级机构制定或批准，适用于全国的标准。这些标准都是强制性的，相关产品必须严格执行标准。 ② ISO9001是设计／开发、生产、安装和服务中的质量保证模式，ISO9000-3是使ISO9001适合于软件的质量保证指南。 ③ 软件工程标准化可提高软件的生产率。 ④ 软件质量保证体系是贯穿于整个软件生存期集成化过程体系，而不仅仅体现在最后产品的检验上。 ⑤ ISO9000-3与具体的开发模式有关。它将软件全过程工序从管理角度、合同角度和工程角度划分为三大类。 ⑥ 软件测试计划始于需求分析阶段，完成于软件设计阶段。 ⑦ 任何一个文档都应是完整的、独立的，它应自成体系。 ⑧ 在新文档取代旧文档后，管理人员应删去旧文档。 ⑨ 软件开发机构应保存一份完整的主文档，并允许开发人员可以保存主文档中的部分主文档，有自己的活动空间。 ⑩ 软件需求分析报告是给开发人员使用的，不是给其它人员，如维护人员，用户等使用的。 【10-9】从供选择的答案中选出同下列各条叙述关系最密切的字句。 (1) 在软件开发中以下几方面的内容应分别在哪个文档中得到阐明： A) 软件总体结构 B) 运行环境 C) 出错处理设计 (2) 以下两个文档应分别在哪两个阶段中开发： D) 初步的用户手册 E) 确认测试计划 供选择的答案： A ( C. ① 可行性研究报告 ② 项目开发计划 ③ 软件需求规格说明 ④ 数据要求规格说明 ⑤ 概要设计规格说明 ⑥ 详细设计规格说明 ⑦ 测试计划 ⑧ 测试报告 ⑨ 用户手册 D, E：① 可行性研究与计划 ② 需求分析 ③ 概要设计 ④ 详细设计 ⑤ 测试 ⑥ 维护 【10-10】从下列关于文档编制的叙述中选出五条正确的叙述。 ① 可行性研究报告应评述为了合理地达到开发目标而可能选择的各种方案，以便用户抉择。因此，编写者不必提出结论。 ② 操作手册的编写工作应该在软件测试阶段之前完成。 ③ 软件的开发单位应该建立本单位文档的标识方法，使文档的每一页都具有明确的标识。 ④ 为了使得文档便于修改保持一致性，各文档的内容不应有相互重复的地方。 ⑤ 用户手册要使用专门术语，并充分地描述该软件系统的结构及使用方法。 ⑥ 详细设计说明书中可以使用判定表及必要的说明来表示程序的逻辑。 ⑦ 概要设计说明书中可以使用IPO图来说明接口设计。 ⑧ 测试分析报告应把每个模块实际测试的结果，与软件需求规格说明书和概要设计说明书中规定的要求进行对照并作出结论。 ⑨ 软件需求规格说明书中可以对软件的操作人员和维护人员的教育水平和技术专长提出要求。 ⑩ 项目开发计划除去规定项目开发所需的资源、开发的进度等以外，还可以包括用户培训计划。 【10-11】 保证软件过程质量应包含的工作有：( A )过程标准，( B )开发过程，( C )软件过程。近年来，软件工程界的专家对过程评估和过程改进表现出浓厚的兴趣。其中有卡内基-梅隆大学SEI的( D )；ISO的( E )。( D )的主题是( F )，( E )的主题是( G )。Bell的( I )的主题是( H )。 供选择的答案： A ( C. ① 监控 ② 报告 ③ 定义 ④ 执行 D, E, I. ① ISO 9001, ISO 9000-3 ② CMM ③ ISO∕IEC TR15504 SPICE ④ MIL-STD-498 ⑤ TRILLTUM ⑥ V-Model ⑦ BooTSTRAP F ( H. ① 软件过程改进和能力评估 ② 建立和维持质量体系 ③ 软件过程能力评估 ④ 软件过程评估（基于CMM） ⑤ 软件过程定义 【10-12】人们用于开发和维护软件及其相关产品的一系列活动称为( A )；表示(开发组织或项目组)遵循其软件过程所获得的实际结果称为( B )；而描述通过遵循其软件过程能够实现预期结果的程度称为( C )；一个特定软件过程被明确和有效地定义、管理、测量和控制的程度称为( D )；表征( D )的平台称为( E )；对软件机构进化阶段的描述，随着软件机构定义、实践、测量、控制和改进其软件过程，软件机构的能力经过这些阶段逐步前进，称为( F )；互为关联的若干软件实践活动和有关基础设施的一个集合称为( G )；对( G )的实施起关键作用的方针、规程、措施、活动以及相关基础设施的建立称为( H )。 供选择的答案： A ( H. ① 关键过程域 ② 软件能力成熟度模型 ③ 关键实践 ④ 软件过程 ⑤ 软件过程能力 ⑥ 软件过程成熟度 ⑦ 软件过程性能 ⑧ 软件能力成熟度等级 【10-13】基于软件人员能力成熟度模型的评估的依据是成熟度级别上的( A )。一个企业的成熟度级别是所有( A )被实施的( B )级别。软件企业通过评估结果可以了解( A )方面的强项和弱项，明确努力的方向。P-CMM模型并不禁止处于较低成熟度级别上的企业在需要的时候实施高一级关键过程域的内容。但是，由于每一级都是向上一级进化的基础，所以，跳越成熟度级别的进化是( C )。基于P-CMM 的改进工作和其它任何发展项目一样，第一要有( D )，第二要( E )，第三要有专人负责。卡内基―梅隆大学SEI的P-CMM顾问委员会建议：在软件工程小组内加入人力资源管理人员，以进行基于P-CMM的改进工作。这样，带给软件机构管理层的信息就是：一个致力于改善整个软件过程能力的项目强调的是( F )，缺一不可。 供选择的答案： A, B. ① 最高 ② 最低 ③ 中间 ④ 关键过程域 ⑤ 实践 ⑥ 软件过程改进 C. ① 无风险的 ② 有风险的 ③ 盲目的 ④ 可预测的 D, E. ① 方法 ② 计划 ③ 跟踪其发展 ④ 加速其进程 F. ① 过程、技术和人员 ② 人力、软件和硬件 ③ 目标、方法和过程 ④ 计划、测试和维护 ⑤ 过程、评估和检验 【10-14】ISO 9000族标准是指国际标准化组织中的质量管理和质量保证技术委员会(ISO∕TC176)制定的标准，现有( A )个标准，可分为5类：质量术语标准，如( B )。( C ),如ISO 9001、ISO 9002、ISO 9003系列标准。( D )，如ISO 9004系列标准。( E )，如ISO 9000系列标准。( F )，如ISO 10005质量计划指南，ISO 10007技术状态管理指南等。 供选择的答案： A. ① 10 ② 25 ③ 20 ④ 30 B. ① ISO 9000-3 ② ISO 9004-4 ③ ISO 9001 ④ ISO 8402 C ( F. ① 支持性技术标准 ② 质量管理和质量保证标准的选用和实施指南 ③ 质量保证标准 ④ 质量管理标准 ⑤ 质量改进标准 【10-15】质量体系是一种( A )。质量体系是通过若干( B )来实现的。( B )是将( C )转化为( D )的一组彼此相关的资源和活动。( B )本身具有( E )的效果，是一种有效益的行为。( F )是通过质量体系来实现的。一个组织机构建立自己的质量体系，并使之有效地运行，使达到( F )目标的重要手段。请选择合适的答案，完成右图的质量体系文件。 供选择的答案： A. ① 体系结构 ② 管理手段 ③ 质量改进过程 ④ 质量管理制度 B ( E. ① 输出 ② 输入 ③ 接口 ④ 减少 ⑤ 增值 ⑥ 过程 ⑦ 扩充 F. ① 质量保证 ② 质量管理 ③ 质量检验 ④ 质量改进 G ( J. ① 质量记录 ② 程序文件 ③ 质量手册 ④ 作业指导书 【10-16】( A )是计算机软件机构实施ISO 9001的指南性标准。它的指南性主要表现在：ⅰ）对于针对的标准给予特定的( B )，ISO 9001提供了( C )个质量体系要素。ⅱ）指南性的标准不是( D )的依据。在ISO 9001的质量体系要素的每一条都强调了要求的强制性，而在( A )中是建议性指南。由于ISO 9001标准本来是针对传统的制造业制定的，而软件业又有许多不同于制造业的特性，所以，( A )起了桥梁作用。 此外，( E )将整个软件生存期分为17个过程，并且对每一个过程按( F )的三个层次具体做了解释，为我们进一步理解( A )提供了帮助。 供选择的答案： A, E. ① ISO 9001 ② ISO 9002 ③ ISO 9000-3 ④ ISO∕IEC 9126 ⑤ ISO 8402 ⑥ ISO∕IEC 12207 B, D. ① 说明与解释 ② 强制性 ③ 建议性 ④ 认证审核 C. ① 10 ② 20 ③ 25 ④ 30 F. ① “任务-活动-过程” ② “活动-任务-过程” ③ “过程-活动-任务” ④ “任务-过程-活动” 五、习题解答 【10-1】A. ③, B. ①, C. ④, D. ①, E. ①, F. ③, G. ④, H. ④。其中，E、F、G、H的答案顺序可互换。 软件质量必须在设计和实现过程中加以保证。如果工程过程能力不够，或由于各种失误产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把差错传播到下一个过程，必须进行质量检验。检验目的有两个：其一是切实搞好开发阶段的管理，检查各开发阶段的质量保证活动开展得如何；其二是预先防止软件差错给用户造成损失。质量检验是质量保证活动的一个重要部分。 检验的实施有两种方式：实际运行检验(白盒测试和黑盒测试)和鉴定。检验的类型有供货检验(指委托外单位承担的开发作业，而后买进或转让的产品)、中间检验∕阶段评审、产品检验和验收检验(确认是否已达到进行“产品检验”的质量要求)。 【10-2】A. ③, B. ②, C. ①, D. ④, E. ⑤, F. ⑥, G. ③, H. ①, I. ②, J. ②, K. ④。 为了开发高质量的软件，从计划阶段开始，不但要明确软件的功能，还要明确软件应当达到什么样的质量标准，即指定软件的质量指标。 为了达到这些质量指标，在开发过程的各个阶段需要进行检查和评价。软件质量度量和保证的条件通常有以下几项： ( 适应性：即必须制定能够适应用户要求、软件类型和规模的质量标准； ( 易学习性：即不需要特殊技术，软件技术人员人人都容易掌握； ( 可靠性：对于同一软件，尽管评价的人和场合不同，但结果必须一致； ( 针对性：即各阶段应确立质量目标并实施落实； ( 客观性：即应从不同角度加以评价； ( 经济性：即应考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内。 软件的质量评价标准分为3级：质量特性、子质量特性和质量度量准则。质量特性的着眼点是“是否满足用户的要求”；子质量特性的着眼点是“开发者在设计实现时是否按照软件需求保证了质量”；质量度量准则是为定量度量软件质量而规定的一些检查项目。它们一级比一级具体，一级比一级易于定量评价。 【10-3】A. ①, B. ③, C. ②, D. ②, E. ②, F. ③, G. ③。 从技术上改进软件的开发过程，提高软件产品的质量无非是两个方面：一是提高测试工作的效率，更有效地发现和排除软件开发过程中发生的各种差错；二是改进开发过程，使得各种差错不被引进或更少地被引进，从而减轻排错的工作量。 在发现错误和排除错误方面更重要也是更困难的是发现错误，也就是测试。因为只有发现了错误才能排除它。由于近年来软件测试技术方面没有多少新的突破，人们只能用加强阶段评审或是检查作为辅助手段。这是一个由同行人员小组人工检查所开发的阶段产品的验证方法，其目的在于发现阶段产品中的缺陷，继而加以排除。至于改进开发过程的新技术，可以采用面向对象的开发技术或是建立软件原型，多少会收到一些效果，但无论如何不能说从根本上解决了软件的质量问题。一个诱人的说法是采用“净室”软件开发技术，其基本思想在于净化软件开发过程，使得差错或缺陷不可能有机可乘混入开发过程。 【10-4】A. ③, B. ②, C. ③, D. ④, E. ①, F. ②, G. ④。 软件配置项是软件配置管理的对象，指的是软件工程过程中产生的所有信息项。包括计算机可执行的源代码、目标码、数据库等，以及计算机不可执行的文档、源程序清单、测试用例等。随着软件工程项目的进展，软件配置项会逐渐增多，于是配置管理的作用就会充分地按照显示出来。不仅如此，而且在不同的时期，出于不同的要求，可进行各种组合，如针对不同的硬件环境和软件环境的组合，这就是软件配置的概念。 实施软件配置管理要做的事情至少有： ( 制定配置管理计划。在软件工程项目制定开发计划时，应在开发计划中包括配置管理计划。在配置管理计划中规定配置标识规则，建立什么样的配置数据库及如何将配置项置于配置管理之下，配置管理人员职责及配置管理活动，采用的配置管理工具、技术和方法。 ( 实施变更管理。这是配置管理的一项重要内容，许多软件工程项目因为没有变更管理措施，而导致出现混乱。 ( 实施版本管理和发行管理。 实际上，软件配置时一个动态的概念。制定适当的命名规则是配置标识的重要工作，命名不能任意、随机地进行。对命名的要求有：唯一性：目的在于避免出现重名，以免造成混乱；可追溯性：使命名能够反映命名对象之间的关系。 【10-5】A. ③, B. ②, C. ②, D. ①, E. ④。 “登入”和“检出”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理各个软件工程人员存取或修改一个特定的软件配置对象的权限；同步控制用于确保由不同的人所做的并发变更不会产生混乱。 存取和同步控制如图所示。根据经批准的变更请求和变更工程顺序，软件工程人员从项目数据库中检出要变更的配置对象。存取控制功能保证了软件人员具有检出该对象的权限，而同步控制功能则封锁(lock)了项目数据库中的这个对象，使得当前检出的版本在没有被置换前不能再更新它。当然，对这个对象还可以检出另外的副本，但对它也不能更新。软件工程人员在对这种成为基线的对象做了变更，并经过适当的软件质量保证措施和测试之后，把修改版本登入项目数据库，再解除封锁(unlock)。 【10-6】A. ④, B. ②, C. ①, D. ③, E. ③。 软件工程标准的类型是多方面的。它可能包括过程标准，如方法、技术、度量等；产品标准，如需求、设计、部件、描述、计划、报告等；专业标准，如职别、道德准则、认证、特许、课程等；记法标准，如术语、表示法、语言等。根据中国国家标准GB∕T 15538-1995(软件工程标准分类法)规定，软件工程标准可用一张二维的表格来表示。 【10-7】A. ②, B. ①, C. ⑤, D. ③, E. ④, F. ⑤, G. ⑥。 软件工程标准是有层次的，根据软件工程标准制定的机构和标准的适用范围有所不同，它可分为五个级别，即国际标准、国家标准、行业标准、企业规范和项目(课题)规范。 国际标准是由国际联合机构制定和公布，供各国参考的标准，通常冠有ISO(国际标准化组织)的字样。国家标准是由政府或国家级机构制定或批准，适用于全国范围的标准，如GB、ANSI、FIPS、BS、DIN、JIS等。行业标准是由行业机构、学术团体或国际机构制定，并适用于某个业务领域的标准，如IEEE、GJB、DOD-STD、MIL-S等。企业规范是由一些大型企业或公司因软件工程工作的需要而制定的适用于本部门的软件工程规范，如IBM公司于1984年制定的程序设计开发指南，仅供公司内部使用。项目规范由某一科研生产项目，且为该项目专用的软件工程规范，如计算机集成制造系统(CIMS) 的软件工程规范。 【10-8】 ① 错 ② 对 ③ 对 ④ 对 ⑤ 错 ⑥ 对 ⑦ 对 ⑧ 错 ⑨ 错 ⑩ 错。 ① 有的标准是强制性的，有的标准是指南性的。虽然国家标准都是由政府或国家级机构制定或批准，适用于全国的标准。这些标准不都是强制性的。例如，GB/T 19000.3―94《质量管理和质量保证标准 第三部分：GB/T 19001―ISO 9001在软件开发、供应和维护中的使用指南》就是一个建议性的指南，而不是强制性的。 ⑤ ISO9000-3是一个指南性的标准，它针对ISO 9001标准的要素按照软件的特点逐条作了解释和说明。它在设计控制的总则中，要求软件开发项目应按照软件生存期模型来组织，要根据所采用的生存期特征来计划和实施过程、活动和任务。但并未涉及具体的开发模式，也未将软件全过程工序从管理角度、合同角度和工程角度划分为三大类。 ⑧ 从软件配置管理的角度来讲，在新文档取代旧文档后，管理人员不应删除旧文档。因为文档反映了某些时刻的软件版本信息，旧版本经过修改产生新版本，文档也需随之更新。由于软件的旧版本作为软件配置项仍然保留，反映其状态的旧文档也不能删去。 ⑨ 软件配置管理要求把软件生存期中的所有产生的程序、文档、资料等配置项都管理起来，软件开发人员需要修改其中部分文档，必须经过严格的变更控制，不能把主文档的一部分控制在自己手中而不纳入配置管理之下。 ⑩ 软件需求分析报告是给开发人员使用的，但其它人员，如管理者和用户等，也需要利用需求分析文档了解软件的需求，参与需求评审和监督软件需求的实现。维护人员在变更软件时也可能要参照需求理解软件、修改软件，甚至修改需求。 【10-9】A. ⑤, B. ③, C. ⑤, D. ②, E. ②。 软件的总体结构应当在概要设计规格说明书中正确定义并给出准确描述。软件的运行环境最初在软件需求规格说明中定义。出错处理设计应在概要设计规格说明中阐明。 初步的用户手册在需求分析阶段开始编写，确认测试计划也应在需求分析阶段开始编写。确认测试有两方面的任务：其一是做有效性测试，确认需求说明书中规定的所有需求是否已正确实现；其二是对所要求的软件配置进行审查，特别是合同中规定应交付的文档进行审查。因为在需求分析阶段已经明确软件的各种功能、性能和其它的质量需求，初步的用户手册也有了，可以针对这些需求和用户手册中的内容，编制如何逐项检查的确认测试计划，当然，这种测试计划只是初步的。测试实施的细节还需在体系结构、用户界面、数据库、出错处理、运行组合等设计完成后才能定下来。 【10-10】① 错 ② 对 ③ 对 ④ 错 ⑤ 错 ⑥ 对 ⑦ 对 ⑧ 错 ⑨ 错 ⑩ 对。 ① 可行性研究报告是为管理者提供该项目是否可以立项的决策依据，编写者在提出可能的后选方案并分析各种可行性后应当给出结论，说明该项目是否值得立项，能否获得成功。 ④ 编写文档时必须保持各个文档的独立性，不能写“参看××说明书××节”，所以如果各文档有重复的地方时，应从前一阶段的文档中复制过来。 ⑤ 用户手册应当使用用户熟知的术语，不应用专业术语。应阐明系统的使用方法，不必详细介绍系统的结构。 ⑧ 每个模块的实测结果是单元测试的结果，不应使用需求信息和概要设计(体系结构)信息来做结果比较。 ⑨ 软件需求规格说明是对待开发软件系统提出的要求，不包括对软件操作人员和维护人员的教育水平和技术专长的要求。 【10-11】A. ③, B. ①, C. ②, D. ②, E. ①, F. ③, G. ②, H. ④, I. ⑤ 保证软件过程质量应包含的工作有：定义过程标准；监控开发过程，报告软件过程。 近年来，软件工程界的专家对过程评估和过程改进表现出浓厚的兴趣。其中有卡内基-梅隆大学SEI的CMM；国际标准化组织(ISO)的ISO 9001, ISO 9000-3。CMM的主题是软件过程能力评估，ISO 9001, ISO 9000-3的主题是建立和维持质量体系。Bell的TRILLTUM的主题是软件过程评估(基于CMM)。参看表10.5。 【10-12】A. ④, B. ⑦, C. ⑤, D. ⑥, E. ⑧, F. ②, G. ①, H. ③。 此题是SEI CMM中涉及到的一些重要概念。人们用于开发和维护软件及其相关产品的一系列活动称为软件过程；表示(开发组织或项目组)遵循其软件过程所获得的实际结果称为软件过程性能；而描述通过遵循其软件过程能够实现预期结果的程度称为软件过程能力；一个特定软件过程被明确和有效地定义、管理、测量和控制的程度称为软件过程成熟度；表征软件过程成熟度的平台称为软件能力成熟度等级；对软件机构进化阶段的描述，随着软件机构定义、实践、测量、控制和改进其软件过程，软件机构的能力经过这些阶段逐步前进，称为软件能力成熟度模型；互为关联的若干软件实践活动和有关基础设施的一个集合称为关键过程域；对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的建立称为关键实践。 【10-13】A. ④, B. ②, C. ②, D. ②, E. ③, F. ①。 基于软件人员能力成熟度模型的评估的依据是成熟度级别上的关键过程域，应当考察特定级别上每个关键过程域的内容是否实施，关键过程域的目标是否达到，同时应考察相应的劳动力条例是否被广泛执行等。一个企业的成熟度级别是所有关键过程域被实施的最低级别。软件企业通过评估结果可以了解关键过程域方面的强项和弱项，明确努力的方向。P-CMM模型并不禁止处于较低成熟度级别上的企业在需要的时候实施高一级关键过程域的内容。但是，由于每一级都是向上一级进化的基础，所以，跳越成熟度级别的进化是有风险的。基于P-CMM 的改进工作和其它任何发展项目一样，第一要有计划，第二要跟踪其发展，第三要有专人负责。卡内基―梅隆大学SEI的P-CMM顾问委员会建议：在软件工程小组内加入人力资源管理人员，以进行基于P-CMM的改进工作。这样，带给软件机构管理层的信息就是：一个致力于改善整个软件过程能力的项目强调的是过程、技术和人员，缺一不可。 【10-14】A. ③, B. ④, C. ③, D. ④, E. ②, F. ①。 ISO 9000族标准是指国际标准化组织中的质量管理和质量保证技术委员会(ISO∕TC176)制定的标准，现有20个标准，可分为5类：质量术语标准，质量保证标准，质量管理标准，质量管理和质量保证标准的选用和实施指南、支持性技术标准。如下表所示。 ① 质量术语标准  ISO 8402  ④ 标准选用与实施指南 ② 质量保证标准 ③ 质量管理标准  ISO9000 -1 选择和使用 -2 实施 -3 计算机软件 -4 可信性大纲 ISO9001 ISO9002 ISO9003 设计、开发、生产、安装和服务 生产、安装和服务 最终检验和试验 ISO9004 -1 指南 -2 服务指南 -3 流程性材料 -4 质量改进  ⑤ 支持性技术标准  ISO 10005 质量计划 ISO 10007 技术状态 ISO 10011 -1 审核 -2 审核员 -3 审核管理 ISO 10012 -1 测量设备 -2 测量过程 ISO 10013 质量手册   【10-15】A. ④, B. ⑥, C. ②, D. ①, E. ⑤, F. ②, G. ③, H. ②, I. ①, J. ④。其中，I和J的答案顺序可互换。 质量体系是一种质量管理制度。质量体系是通过若干过程来实现的并有一组质量体系文件，如图所示。过程是将输入转化为输出的一组彼此相关的资源和活动。过程本身具有增值的效果，是一种有效益的行为。质量管理是通过质量体系来实现的。一个组织机构建立自己的质量体系，并使之有效地运行，使达到质量管理目标的重要手段。 为明确规定、系统地描述质量体系的各项要求，使得相关人员能够理解和方便地实施，有必要建立质量体系文件。质量体系文件大致可分为三个层次，如图所示。 【10-16】A. ③, B. ①, C. ②, D. ④, E. ⑥, F. ③。 ISO 9000-3是计算机软件机构实施ISO 9001的指南性标准。它的指南性主要表现在： ⅰ）对于针对的标准给予特定的说明与解释，即从软件的角度对ISO 9001标准的内容给出具体的说明和解释。ISO 9001提供了20个质量体系要素，ISO 9000-3则对照其每一个要素，逐一作出说明和解释。 ⅱ）指南性的标准不是认证审核的依据。ISO 9001是认证审核的依据。在认证审核时考察的是申请认证的软件机构贯彻实施ISO 9001的情况，而不考察有无违背ISO 9000-3 条文的情况。事实上，者两个标准文本的叙述语气也是有差别的。在ISO 9001的质量体系要素的每一条都强调了所提要求的强制性，使用了“应该(shall)”如何的用语，而在ISO 9000-3的各条解释中，由于是建议性指南，普遍使用了“最好(should)”如何的提法。 《ISO∕IEC 12207 ：1995信息技术―软件生存期过程》将整个软件生存期分为17个过程，并且对每一个过程按“过程-活动-任务”的三个层次具体做了解释，为我们进一步理解ISO 9000-3提供了帮助。