技术评审检查表编制指南
目的本指南给出编制技术评审检查表的步骤和原则。
检查表（Checklist）是一种常用的质量保证手段。人们借助检查表以确认被检查对象的所有质量特征均得到满足。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。在正规技术评审中，检查表用来帮助评审员找出被审对象中可能的缺陷，评审过程由检查表驱动。因此，检查表是举行正规技术评审的必要工具。一份精心设计的检查表，对于提高评审效率、改进评审质量具有重要意义。
步骤
（1）根据以往积累的经验收集同类评审对象的常见缺陷，或者从现有检查表中选择合适的作为基础。
（2）按缺陷的类型和子类型进行组织，并为每一个缺陷类型指定一个标识码。标识码将在评审中被用来分类缺陷类型。
（3）以简单问句的形式表达每一种缺陷。所谓简单问句，其答句为“是”或“否”。答句为“是”表示存在此缺陷；答句为“否”表示未发现此缺陷。
（4）按照各种缺陷对软件影响的严重性和（或）发生的可能性从大至小排列缺陷类型和子类型。各种缺陷发生的可能性可以基于以往的软件问题报告和个人经验。
（5）根据本次评审对象的质量要求和其他特性，对检查表中的问题作必要的增、删、修改和前后次序调整。
原则
（1）不同类型的评审对象应编制不同的检查表。需求分析、概要设计、详细设计、程序代码、测试计划、测试案例、系统切换方案、用户操作手册等是不同类型的评审对象,应编制不同的检查表。C程序、JAVA、Visual Basic等也是不同类型评审对象，应使用不同的检查表。进而言之，被审对象采用不同的中间件和数据库管理系统，相应的检查表也可能不同。
（2）在检查表中，应排除文档编辑软件能够识别的拼写错误和编程语言编译器能够识别的语法错误。这类检查应由作者在提交被审对象前完成。正规技术评审的主持人负责检查被审文档是否经过文档编辑软件的拼写检查、被审程序代码是否通过编译。
（3）检查表应着重于“严重”（Major）缺陷。所谓“严重”缺陷，指会引起系统失败的错误、导致系统的功能不符合需求的错误，或者严重违反开发规范的错误。其余缺陷称为“次要”（Minor）缺陷。不要将次要缺陷包括在检查表中。
（4）仔细权衡检查表的长度与评审成本的关系。一般而言，检查表中列出的问题越多，从被审对象中找出问题的数量会越多，但总的评审花费也会越高。
（5）随着公司业务领域的拓展、软件开发质量的提高、开发人员技术水平的变化，检查表应经常加以更新，以反映最新的常见错误和质量目标，提高评审效率。
（6）检查表是评审的出发点，但在评审过程中不应局限于检查表中的问题。评审员应根据自己的经验和判断寻找其他可能的缺陷。
页:
[1]
