如何设计出一个有用的评审检查单?

评审检查单是专家对于设计经验的总结。一个好的评审检查单既可以在评审时为评审人员指出发现问题的方向,也可以在开发过程中给开发人员作为指南来使用。但是我们要如何设计出一个有用的评审检查单呢?

下面以某组织的设计评审的评审检查单为例,来看看什么样的检查单是好的检查单。

  • 所有的功能需求与非功能需求是否都体现在了设计中?

  • 在设计中是否增加了不必要的功能,是否为未来的变更进行了过度设计?

  • 类的属性是否超过了公共方法的个数的两倍?

  • 类提供的公共方法是否超过了7个?

  • 某个类的方法是否既执行了修改又执行了查询?

  • 方法的参数是否超过了三个?

  • 每个方法可能的规模是否超过了200行代码?

  • 类依赖的对象是否超过了5个?

  • 类继承的层次是否超过了6层?

  • 是否有的继承关系违背了coad法则?

  • 是否存在某个基类不是抽象类?

  • 继承自非抽象类的关系是否合适?

  • 是否存在某个接口,它的某些方法并不为实现它的子类所使用,需要在子类中退化实现?

  • 是否需要在运行时刻判断对象的类型?

  • 类的访问权限是否合适?

虽然这个评审检查单是针对面向对象设计的,对于面向结构的设计不太适用,但我们可以从中学习设计一个优秀的评审检查单要考虑的要素。比如:

  • 抓住评审的核心

设计评审的核心是评审“设计”,而不是评审《软件设计说明》文档。设计评审检查单的时候不要偏离这个核心。有些设计评审的评审检查单把它做成了《软件设计说明》的检查单,按照GJB438B中对软件设计说明的要求逐个章节去检查,这种做法偏离了“核心”,很难取得好的设计评审绩效。

  • 结合技术规范

我们希望通过技术评审找出设计开发中存在的问题,所以评审检查单不能只是一些模板符合性的检查项,它要结合相应的技术规范,关注更深层次的技术问题。比如:前面检查项中的“每个方法可能的规模是否超过了200行代码?”

  • 结合实践经验

评审检查项要能结合软件开发的实践经验。比如,我们要把历史项目中软件暴露的一些共性问题的解决措施可以放在检查单中,以预防这样的问题再次发生。

  • 不断优化和改进

评审检查单必须要不断地进行优化和改进。由于评审检查单与组织的技术规范和实践经验紧密结合,那么当技术规范改进了,或者有新的实践经验要纳入进来,就应该对评审检查单进行优化。

这正是:

评审绩效要提高,检查单子不能少

检查单子要有效,结合规范和实践

参考书目:术以载道:软件过程改进实践指南,作者:任甲林,出版社:人民邮电出版社

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

如何设计出一个有用的评审检查单?》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/532.html