第十章软件质量保证 复习要求 1.了解软件质量保证、质量保证活动与质量检验的概念 2.了解软件质量保证体系与质量保证的实施的概要。 3.了解正式技术评审概要。包括评审会议、设计质量和程序质量的评审。 4.了解软件配置管理的概念。包括配置项和基线概念、配置管理的主要工作 5.了解软件工程标准化的概念。包括软件工程标准化意义、软件工程标准的制定与推行、 软件工程标准的层次、软件工程的国家标准。 6.了解软件文档的概念。包括文档编制的要求、文档的作用、分类、文档的工作。 7.了解软件过程与过程改进的概念。包括过程分类与过程模型、剪裁过程、过程模型建 造技术、软件过程改进。 8.了解软件过程能力评估的CMM模型,包括过程成熟度的概念、软件机构的能力成熟 度模型、关键过程域、关键实践的概念。 9.了解ISO9000国际标准。包括质量管理、质量认证和质量审核的概念,ISO9000系 列标准的特点、科学依据、主要内容,以及ISO9000-3标准。 内容提要 1.软件质量保证 (1)质量保证的概念 什么是质量保证?它是为保证产品和服务充分满足消费者要求的质量而进行的有计划 有组织的活动。质量保证是面向消费者的活动,是为了使产品实现用户要求的功能,站在用 户立场上来掌握产品质量的。这种观点也适用于软件的质量保证。 软件的质量保证就是向用户及社会提供满意的高质量的产品。进一步地,软件的质量保 证活动也和一般的质量保证活动一样,是确保软件产品在软件生存期所有阶段的质量的活动 即为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。它包括 的主要功能如 制定和展开质量方针 制定质量保证方针和质量保证标准 建立和管理质量保证体系; 明确各阶段的质量保证业务 坚持各阶段的质量评审; 确保设计质量 提出与分析重要的质量问题 总结实现阶段的质量保证活动 整理面向用户的文档、说明书等 鉴定产品质量,鉴定质量保证体系 收集、分析和整理质量信息
1 第十章 软件质量保证 一、复习要求 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小组则要评审过程说明,以保证该过程与组织政策、内部的软件标准、外界所制定 的标准(如ISO9001)以及软件项目计划的其它部分相符。 ③评审各项软件工程活动,核实其是否符合已定义的软件过程。SQA小组识别、记录 和跟踪所有偏离过程的偏差,核实其是否已经改正。 ④审计指定的软件工作产品,核实其是否符合已定义的软件过程中的相应部分。SQA 小组对选出的产品进行评审,识别、记录和跟踪出现的偏差,核实其是否己经改正,定期向 项目负责人报告工作结果。 ⑤确保软件工作及工作产品中的偏差已被记录在案,并根据预定规程进行处理。偏差 可能出现在项目计划、过程描述、采用的标准或技术工作产品中 ⑥记录所有不符合部分,并向上级管理部门报告。跟踪不符合的部分直到问题得到解 除了进行上述活动外,SQA小组还需要协调变更的控制与管理,并帮助收集和分析软件 度量的信息。 (3)质量保证与检验 ①检验在质量保证中的作用 软件质量必须在设计和实现过程中加以保证。如果过程管理不力,软件开发环境或软件 工具不够好,或者由于各种失误导致产生软件差错,其结果就会产生软件失效。为了确保每 个开发过程的质量,防止把软件差错传递到下一个过程,必须进行质量检验 质量保证是面向消费者的,从质量保证的角度来讨论检查,下面几点应当明确 用户要求的是产品所具有的功能,这是“真质量”。靠质量检验,一般检查的是“真 质量”的质量特性。 能靠质量检验的质量特性,即使全数检验,也只是代表产品的部分质量特性 必须在各开发阶段对影响产品质量的因素进行切实的管理,认真检查实施落实情况 只有这样才能使产品达到用户要求,这比单靠检验来保证质量要有效、经济 ■当开发阶段出现异常时,要从质量特性方面进行检验,看是否会给后续阶段带来影响 并对判断其好坏程度。从质量保证角度来看,此项工作极其重要 虽然各开发阶段进展稳定,但由于工具支持不足等,软件产品不能满足用户要求的质 。这时可通过检验对该产品做出评价,判断是否能向用户提供该产品 尽管各开发阶段进展稳定,但也要以一定的标准检验产品,使其交付使用后保持稳定 的质量水平。同时还要根据产品的质量特性,检查各个过程的管理状态 因此,检验的目的有二个。其一是切实搞好开发阶段的管理,检査各开发阶段的质量保 证活动开展得如何;其二是预先防止软件差错给用户造成损失
2 (2) 软件质量保证(SQA)活动 软件质量保证由各项任务构成，这些任务的参与者有两种人：软件开发人员和质量保证 人员。前者负责技术工作，后者负责质量保证的计划、监督、记录、分析及报告工作。 软件开发人员通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的 软件测试来保证软件产品的质量。软件质量保证人员则辅助软件开发组得到高质量的最终产 品。1993 年美国 SEI 推荐了一组有关质量保证的计划、监督、记录、分析及报告的 SQA 活 动。这些活动将由一个独立的 SQA 小组执行(或协助)： ① 为项目制定 SQA 计划。该计划在制定项目计划时制定，由相关部门审定。它规定了 软件开发小组和质量保证小组需要执行的质量保证活动，其要点包括：需要进行哪些评价？ 需要进行哪些审计和评审？项目采用的标准；错误报告的要求和跟踪过程；SQA 小组应产生 哪些文档？为软件项目组提供的反馈数量等。 ② 参与开发该软件项目的软件过程描述。软件开发小组为将要开展的工作选择软件过 程，SQA 小组则要评审过程说明，以保证该过程与组织政策、内部的软件标准、外界所制定 的标准(如 ISO 9001）以及软件项目计划的其它部分相符。 ③ 评审各项软件工程活动，核实其是否符合已定义的软件过程。SQA 小组识别、记录 和跟踪所有偏离过程的偏差，核实其是否已经改正。 ④ 审计指定的软件工作产品，核实其是否符合已定义的软件过程中的相应部分。SQA 小组对选出的产品进行评审，识别、记录和跟踪出现的偏差，核实其是否已经改正，定期向 项目负责人报告工作结果。 ⑤ 确保软件工作及工作产品中的偏差已被记录在案，并根据预定规程进行处理。偏差 可能出现在项目计划、过程描述、采用的标准或技术工作产品中。 ⑥ 记录所有不符合部分，并向上级管理部门报告。跟踪不符合的部分直到问题得到解 决。 除了进行上述活动外，SQA 小组还需要协调变更的控制与管理，并帮助收集和分析软件 度量的信息。 (3) 质量保证与检验 ① 检验在质量保证中的作用 软件质量必须在设计和实现过程中加以保证。如果过程管理不力，软件开发环境或软件 工具不够好，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每 个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。 质量保证是面向消费者的，从质量保证的角度来讨论检查，下面几点应当明确： ▪ 用户要求的是产品所具有的功能，这是“真质量”。靠质量检验，一般检查的是“真 质量”的质量特性。 ▪ 能靠质量检验的质量特性，即使全数检验，也只是代表产品的部分质量特性。 ▪ 必须在各开发阶段对影响产品质量的因素进行切实的管理，认真检查实施落实情况。 只有这样才能使产品达到用户要求，这比单靠检验来保证质量要有效、经济。 ▪ 当开发阶段出现异常时，要从质量特性方面进行检验，看是否会给后续阶段带来影响， 并对判断其好坏程度。从质量保证角度来看，此项工作极其重要。 ▪ 虽然各开发阶段进展稳定，但由于工具支持不足等，软件产品不能满足用户要求的质 量。这时可通过检验对该产品做出评价，判断是否能向用户提供该产品。 ▪ 尽管各开发阶段进展稳定，但也要以一定的标准检验产品，使其交付使用后保持稳定 的质量水平。同时还要根据产品的质量特性，检查各个过程的管理状态。 因此，检验的目的有二个。其一是切实搞好开发阶段的管理，检查各开发阶段的质量保 证活动开展得如何；其二是预先防止软件差错给用户造成损失
②各个开发阶段中的检验 为了切实做好质量保证,要在软件开发工程的各个阶段实施检验。检验的类型有: 供货检验:这是指对委托外单位承担开发作业,而后买进或转让的构成软件产品的部 件、规格说明、半成品或产品的检查。由于委托单位、委托时间等情况差别很大,往往与质 量相关的信息不完全,要想只靠供货时检査,质量很难保证。因此要调査接受委托单位的开 发能力,并且要充分交流情况。 中间检验/阶段评审:在各阶段的中途或向下一阶段移交时进行的检查叫做中间检验 或阶段评审。阶段评审的目的是为了判断是否可进入下一阶段进行后续开发工作,避免将差 错传播到后续工作中,给后续工作带来不良影响,造成损失 验收检验:确认产品是否已达到可以进行“产品检验”的质量要求。 产品检验:这是软件产品交付使用前进行的检查。其目的是判定向用户提供的软件, 作为产品,是否达到了令人满意的程度。 检验的实施有两种形式:实际运行检验(即白盒测试和黑盒测试)和鉴定。可在各开发阶 段中结合起来使用。各开发阶段及阶段中的检验如图10.1所示 开发阶段 需需求分析①开发目的 ⑤各阶段的产品 ②目标值 作业内容 功能设计③开发量(程序、⑥开发体制 的合理性 文档). 析实施计划④所需资源 结构设计①产品的量(计划量 ⑤评审方法、覆盖性 际量) ⑥出错原因、处理情况及对 数据设计②评审量 该阶段的影响 计 ⑦评审结束、阶段结束的判 过程设计④检出差错的内容和倾向 所标准 程序编制①产品的量(计划量、实际⑥检出的差错内容及倾向 实 量),目标值完成情况.⑦评审方法、覆盖性 单元测试|②评审量 ⑧测试环境 ③检出的差错数 ⑨测试项目设定种类、测 组装测试④计算机使用时间 试用例设计方法 ⑤出错原因、处理情况及⑩评审结束、阶段结束的 现验收 确认测试 对该阶段的影响 判断标准 ①说明书检查—检查与被检查程序有关的用户文档等, 检查,评价②程序检查为了评价和保证程序质量,通过各种测试 测试成品进行检查 运行运行,维护①掌握用户使用产品的质量情况,并反馈到开发部门 维护 图10.1开发阶段与相应的检验项目 2.软件质量保证体系与质量保证的实施 (1)软件质量保证体系 软件的质量保证活动,是涉及各个部门的部门间的活动。例如,如果在用户处发现了软 件故障,产品服务部门就应听取用户的意见,再由检查部门调查该产品的检验结果,进而还 要调查软件实现过程的状况,并根据情况检查设计是否有误,不当之处加以改进,防止再次 发生问题。为了顺利开展以上活动,事先明确部门间的质量保证业务,确立部门间的联合与
3 ② 各个开发阶段中的检验 为了切实做好质量保证，要在软件开发工程的各个阶段实施检验。检验的类型有： ▪ 供货检验：这是指对委托外单位承担开发作业，而后买进或转让的构成软件产品的部 件、规格说明、半成品或产品的检查。由于委托单位、委托时间等情况差别很大，往往与质 量相关的信息不完全，要想只靠供货时检查，质量很难保证。因此要调查接受委托单位的开 发能力，并且要充分交流情况。 ▪ 中间检验／阶段评审：在各阶段的中途或向下一阶段移交时进行的检查叫做中间检验 或阶段评审。阶段评审的目的是为了判断是否可进入下一阶段进行后续开发工作，避免将差 错传播到后续工作中，给后续工作带来不良影响，造成损失。 ▪ 验收检验：确认产品是否已达到可以进行“产品检验”的质量要求。 ▪ 产品检验：这是软件产品交付使用前进行的检查。其目的是判定向用户提供的软件， 作为产品，是否达到了令人满意的程度。 检验的实施有两种形式：实际运行检验(即白盒测试和黑盒测试)和鉴定。可在各开发阶 段中结合起来使用。各开发阶段及阶段中的检验如图 10.1 所示。 图 10.1 开发阶段与相应的检验项目 2. 软件质量保证体系与质量保证的实施 (1) 软件质量保证体系 软件的质量保证活动，是涉及各个部门的部门间的活动。例如，如果在用户处发现了软 件故障，产品服务部门就应听取用户的意见，再由检查部门调查该产品的检验结果，进而还 要调查软件实现过程的状况，并根据情况检查设计是否有误，不当之处加以改进，防止再次 发生问题。为了顺利开展以上活动，事先明确部门间的质量保证业务，确立部门间的联合与
协作的机构十分重要,这个机构就是质量保证体系。图102和103是软件质量保证体系的图 在质量保证体系图上,用户、领导、各部门横向安排,而纵向则顺序列出软件质量保证 活动的各项工作。制定质量体系保证图应注意以下一些问题: 必须明确反馈途径 必须在体系图的纵向(纵坐标方向)顺序写明开发阶段,在横向(横坐标方向)写明组织 机构,明确各部门的职责 必须确定保证系统运行的方法、工具、有关文档资料,以及系统管理的规程和标准 必须明确决定是否可向下一阶段进展的评价项目和评价准则。 ■必须不断地总结系统管理的经验教训,能够修改系统。 仅靠质量保证体系图很难明确具体工作,因此必须制定质量保证计划,在这个计划中确 定质量目标,确定在每个阶段为达到总目标所应达到的要求,对进度做出安排,确定所需的 人力、资源和成本等等。 步骤用户领导计划组 开发组质量审查组售后服务组质量保证 市场需求 质量信息 计求 社会环境 用户意见信息 其他厂商产品动向 软件故障信息 产品计划 计划ⅸ 制定开发方案 技术审查 概要设计〈技术审查 质量保证体制的维持与完善 详细设计(技术审查 实 单元测试 技术审查〉 现 组装测试」 测试前质量检查 产品检查 交付 交 意见处理 质量改进窗议》 技术改进 质量改进促进问题的解决 防止再发生 图102质量保证体系图例(程序检查)
4 协作的机构十分重要，这个机构就是质量保证体系。图 10.2 和 10.3 是软件质量保证体系的图 例。 在质量保证体系图上，用户、领导、各部门横向安排，而纵向则顺序列出软件质量保证 活动的各项工作。制定质量体系保证图应注意以下一些问题： ▪ 必须明确反馈途径。 ▪ 必须在体系图的纵向(纵坐标方向)顺序写明开发阶段，在横向(横坐标方向)写明组织 机构，明确各部门的职责。 ▪ 必须确定保证系统运行的方法、工具、有关文档资料，以及系统管理的规程和标准。 ▪ 必须明确决定是否可向下一阶段进展的评价项目和评价准则。 ▪ 必须不断地总结系统管理的经验教训，能够修改系统。 仅靠质量保证体系图很难明确具体工作，因此必须制定质量保证计划，在这个计划中确 定质量目标，确定在每个阶段为达到总目标所应达到的要求，对进度做出安排，确定所需的 人力、资源和成本等等。 图 10.2 质量保证体系图例(程序检查)
在这个质量保证计划中包括的软件质量保证规程和技术准则应当 指示在何时、何处进行文档检查和程序检查 指示应当采集哪些数据,以及如何进行分析处理,例如,在每次评审和测试中发现的 错误如何修正 描述希望得到的质量度量: 规定在项目的哪个阶段进行评审及如何评审 规定在项目的哪个阶段应当产生哪些报告和计划: 规定产品各方面测试应达到的水平 在计划中,在说明各种软件人员的职责时,要规定为了达到质量目标他们必须进行哪些 活动。其次,要根据这个质量保证体系图,建立在各阶段中执行质量评价的质量评价和质量 检查系统及有效运用质量信息的质量信息系统,并使其运行 步骤用户开发组质量审查组售后服务组出版部门质量保证 分析,设计,评审 计划·设计执 规格说明设计 规格说明编写 设计书检查〉〈设计书检查)(计划书检查)质 说明书执笔 原稿审查」 说明书检查)〈说明书检查〉)〈说明书检查 量保证体制的维持与完善 查 K产品检查 原稿修改/审查 意见处理 付 维 文档质量改进会议D 技术改进 质量改进「促进问题的解决 防止再发生 图10.3质量保证体系图(文档检查) (2)质量保证的实施 软件质量保证的实施需要从纵向和横向两个方面展开。一方面要求所有与软件生存期有 关的人员都要参加,另一方面要求对产品形成的全过程进行质量管理,这要求整个软件部门 齐心协力,不断完善软件的开发环境。此外还需要与用户共同合作。 ①质量目标与度量
5 在这个质量保证计划中包括的软件质量保证规程和技术准则应当 ▪ 指示在何时、何处进行文档检查和程序检查； ▪ 指示应当采集哪些数据，以及如何进行分析处理，例如，在每次评审和测试中发现的 错误如何修正； ▪ 描述希望得到的质量度量； ▪ 规定在项目的哪个阶段进行评审及如何评审； ▪ 规定在项目的哪个阶段应当产生哪些报告和计划； ▪ 规定产品各方面测试应达到的水平。 在计划中，在说明各种软件人员的职责时，要规定为了达到质量目标他们必须进行哪些 活动。其次，要根据这个质量保证体系图，建立在各阶段中执行质量评价的质量评价和质量 检查系统及有效运用质量信息的质量信息系统，并使其运行。 图 10.3 质量保证体系图(文档检查) (2) 质量保证的实施 软件质量保证的实施需要从纵向和横向两个方面展开。一方面要求所有与软件生存期有 关的人员都要参加，另一方面要求对产品形成的全过程进行质量管理，这要求整个软件部门 齐心协力，不断完善软件的开发环境。此外还需要与用户共同合作。 ① 质量目标与度量
为了开发高质量的软件,从计划阶段开始,不但需要明确软件的功能,还要明确软件应 达到什么样的质量标准,即制定软件的质量目标。为了达到这个目标,在开发过程中的各个 阶段进行检查和评价。在做质量评价时,需要有对质量进行度量的准则和方法,但更重要的 是,需要有在软件生存期中如何使用这些准则和方法的质量保证步骤,以及提高该项作业效 率的工具。 软件质量度量和保证的条件通常有以下几项 ■适应性:必须制定能适应各种用户要求、软件类型和规模的质量标准,并能够度量 易学性:不需要特殊技术,软件技术人员人人都容易掌握。 可靠性:对同一软件的评价,尽管评价的人或场合可能不同,但评价结果必须一致 ■针对性:不是在检查时才改进质量,而必须从设计阶段起就确立质量目标,在各个阶 段实施落实 客观性:从各种不同角度加以评价,并将评价结果定量地表示,使得人人都能理解。 经济性:考虑如何才能把质量度量和保证所需要的费用控制在适当的范围内 ②软件质量度量与保证的实施 图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 软件开发各阶段的基线