开发管理 · 质量管理三件套与软件评审准则

IEEE 729-1983 标准给了四条定义：软件产品满足给定需求的特性及特征的总体的能力；软件拥有所期望的各种属性组合的程度；顾客或用户认为软件满足他们综合期望的程度；软件组合特性在使用中，满足用户预期需求的程度。原文跟了一个关键结论：从上述定义可以看到质量不是绝对的，它总是与给定的需求有关。所以对软件质量的评价总是在将产品的实际情况与从给定的需求中推导出来的软件质量的特征和质量标准进行比较后得出的。判断题问「软件质量是绝对的客观标准」，错。

软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程，即总体管理功能中决定质量方针、目标与责任的所有活动，并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施。而软件质量管理着重于确定软件产品的质量目标、制订达到这些目标的计划，并监控及调整软件计划、软件工作产品、活动及质量目标以满足顾客及最终用户的需要及期望。

核心三分法来了：软件质量管理包括三个部分。质量计划——判断哪些质量标准与本项目相关，并决定应如何达到这些质量标准；质量保证——定期评估项目总体绩效，建立项目能达到相关质量标准的信心；质量控制——监测项目的总体结果，判断它们是否符合相关质量标准，并找出如何消除不合格绩效的方法。这三句每句都是一道匹配题：见「树立信心」选质量保证，见「消除不合格」选质量控制。

在正式进行软件开发前需要制订软件质量计划，用于说明项目管理团队将如何实施其质量方针。用 ISO9000 的话说，它应该说明项目质量体系，即用以实施质量管理的组织结构、责任、程序、过程和资源。较常用的国际质量标准是 ANSI/IEEE STOL730-1984、983-1986 标准。质量计划阶段的活动包括：对项目的软件质量活动做出计划；对软件产品质量的可测量的目标及其优先级进行定义；确定软件产品质量目标的实现过程是可量化和可管理的；为管理软件产品的质量提供适当的资源和资金；对相关人员进行培训；按照已文档化的规程制订和维护项目的软件质量计划；在整个软件生命周期要确定、监控和更新软件产品的质量目标。

质量保证，指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动，它应贯穿于项目的始终，在事件驱动的基础上对软件产品质量进行测量、分析，并将分析结果与既定的质量标准相比较。如果属于软件外包，还需要对软件产品的定量质量目标进行合理的分工，分派给承包商。

质量控制，指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何杜绝造成不合格结果的根源，也应贯穿于项目的始终。项目结果既包括产品结果例如可交付成果，也包括项目管理结果例如成本与进度绩效。质量控制通常由机构中的质量控制部或名称相似的部门实施。有一句必须背的定性：软件质量的控制不单单是一个软件测试问题，评审、调试和测试是保证软件质量的重要手段。

原文的原话：软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致开发的失败。判断题问「评审是开发完成后才做的事」，错，就考这句。

评审目标包括五条：发现任何形式表现的软件功能、逻辑或实现方面的错误；通过评审验证软件的需求；保证软件按预先定义的标准表示；已获得的软件是以统一的形式开发的；使项目更容易管理。

不止。评审过程应包括召开评审会议，会议结束时必须做出三个决策之一：第一，接受该产品，不需作修改；第二，由于错误严重，拒绝接受；第三，暂时接受该产品。然后是评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。三决策是高频考点——「接受、拒绝、暂时接受」，注意第二种拒绝的前提是「错误严重」。

有，准则第一条就是：对每个正式技术评审分配资源和时间进度表——评审不是临时拉个会，资源和时间表要事先分好。再补一个容易漏的：对每个被评审的产品建立评审清单，以帮助评审人员思考。这两个「事先动作」配上后面「评审产品不评审设计者、不脱离主题、为了发现问题」，就是完整的准则集。

对，这句是原文准则，一字不差：评审产品，而不是评审设计者，不能使设计者有任何压力。准则还有几条配套：对每个正式技术评审分配资源和时间进度表；会议不能脱离主题，应建立议事日程并维持它；评审会不是为了解决问题，而是为了发现问题，限制争论与反驳；对每个被评审的产品建立评审清单，以帮助评审人员思考。注意第三条的辨析——评审会「为了发现问题而不是解决问题」，判断题爱把方向反过来；干扰项里「只评审过程不评审产品」「同时评审产品和设计者」都不对，准则的落点就是产品本身。

软件测试是软件开发的一个重要环节，同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统或系统的构件。测试一般包括四个层次：单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致，则很可能是发现了系统中的错误。

测试过程中将产生三份基本文档。测试计划：确定测试范围、方法和需要的资源等。测试过程：详细描述与每个测试方案有关的测试步骤和数据，包括测试数据及预期的结果。测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生问题报告，并且必须经过调试解决所发现的问题。三份文档对三个问题——测什么怎么测、具体步骤、结果如何，配对记。

再顺一遍加抓手：第一发现任何形式表现的软件功能、逻辑或实现方面的错误，抓手「功能、逻辑、实现」三个词；第二通过评审验证软件的需求，抓手「验证需求」；第三保证软件按预先定义的标准表示，抓手「按标准表示」；第四已获得的软件是以统一的形式开发的，抓手「统一形式」；第五使项目更容易管理，抓手「好管理」。五个抓手连成一句话：发现错误、验证需求、按标准、统一形式、便于管理。

软件质量控制还包括这些活动：对软件产品进行测试，并将测试结果用于软件质量管理活动的状态；高级管理者定期参与评审软件质量管理的活动；软件项目负责人定期参与评审软件质量管理的活动；软件质量保证评审小组负责评审软件的质量管理活动和工作产品，并填写相关报告。注意两级管理者——高级管理者和项目负责人——都要「定期参与评审」，这句判断题问过。

记到能认出就行：目前国际上有许多质量标准，较常用的是 ANSI/IEEE STOL730-1984、983-1986 标准，还有前面说过的 ISO9000。考法一般是给「IEEE 729-1983」问你它定义的是软件质量还是配置管理——记住两个 729-1983：定义软件质量四条的是它，定义 SCM 七大功能的也是它，同一标准两处引用，别拆成两个东西。

本集必背：IEEE 729-1983 软件质量四条定义，质量不是绝对的、总与给定需求有关；质量管理三部分——质量计划判断哪些标准相关、质量保证树立信心并贯穿始终、质量控制监测结果消除不合格根源；评审在各个阶段都要进行、不是完毕后；评审目标五条；评审会议三决策——接受、错误严重拒绝、暂时接受；基本准则是评审产品而不是评审设计者，评审会为了发现问题而不是解决问题；测试四层次——单元、模块、集成、系统；测试三文档——测试计划、测试过程、测试结果。

对，下集专讲风险管理：风险的三段划分、四种类型、PMBOK 的四种应对策略，还有风险值等于概率乘影响的算例——「前 10 个风险列表」这个最有效的监控工具也在下集。