一张通用的评审检查单

同行评审是软件工程的最佳实践之一。CMMI 2.0和即将发布的GJB5000B中,都将同行评审作为独立的实践域实施。这表明同行评审实践越来越受到重视。

而要使得同行评审更加有效,一个实用的评审检查单是必不可少的。

那么,如何针对每个工作产品制定出一个实用、有效的检查单?

这并不是个一蹴而就的事情,一个实用、好用的检查单,往往需要不断地迭代才能获得。

这里无法给出一个适合你组织的好用的检查单,但是,可以给出一个通用的评审检查单,你可以在此基础之上做裁剪、迭代,直到形成适合你组织的检查单。

对工作产品的评审,主要从以下几个方面来进行:正确性、完整性、一致性、有效性、测试性、模块化、清晰性、可行性、可靠性、可追溯性。所以,制定通用的评审检查单只要覆盖从这些方面就可以了,而每个工作产品评审检查单则是根据被评工作产品的特性对具体的检查项进行调整即可。

通用的评审检查单示例:

  1. 正确性

  • 所有的内容(需求/计划/设计/测试项/测试用例/测试结果……)是否都是正确的?

  • 在各种条件下(正常或异常)的情况下的描述是否都是正确的?

  1. 完整性

  • 是否有漏掉的需求/计划/设计/测试项/测试用例/测试结果……?

  • 是否有漏掉的输入输出或条件?

  • 是否考虑了所有的可能情况?

  1. 一致性

  • 同一工作产品内或不同工作产品间使用的术语是否是唯一的?

  • 缩写词等的使用在同一工作产品内或不同工作产品间是否一致?

  1. 有效性

  • 是否所有的需求/设计都有明确的目的?

  • 是否存在对用户毫无意义的功能/设计?

  • 设计的测试用例是否能够充分验证对应的需求?

  1. 测试性

  • 需求描述是否定量,可测试?

  • 软件设计是否易于测试?

  • 代码是否满足可读性要求?

  1. 模块化

  • 软件功能描述是否深入到模块?

  • 模块设计是否符合高内聚低耦合的要求?

  • 模块的大小是否合适?

  • 模块结构是否分层?

  1. 清晰性

  • 工作产品中所有内容是否都是易于理解的?

  • 每项说明是否都是唯一的?

  • 每项的说明是否清晰?

  1. 可行性

  • 软件的功能/性能以及其他需求,在现有的资源和技术水平上是否可行?

  1. 可靠性

  • 软件需求/设计/测试是否考虑了可靠性要求?

  • 是否考虑了软件系统崩溃时会出现的问题?

  • 是否考虑了出现异常情况时软件如何响应?

  1. 可追溯性

  • 工作产品中每项内容是否都有输入来源?

这正是:

知道需要检查单,不会设计检查项

通用评审检查单,供你参考打个样

参考书目:软件质量保证和管理,作者:朱少民,出版社:清华大学出版社

作者简介:王小双,长期从事GJB5000推广、实施、评价、改进的工作,创建《软件工程之思》微信公众号,一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。

一张通用的评审检查单》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/3317.html