软件设计评审检查单
很多企业在做CMMI 3级,都要求了项目组要写设计文档,做设计评审。按Watts S. Humphrey的建议,设计评审的工作量要大于设计工作量的1/2。很多企业也做了设计评审,但是很少发现实质性的问题。经过我的分析,发现缺少设计评审的检查单是其中一个很重要的原因,设计评审时专家使用的检查单是企业设计经验的总结,是企业的财富,代表了在企业里软件设计质量的价值观。而我看到的多个企业的设计评审检查单,要么是过于理论,要么纯粹是对设计文档格式的检查,都很难帮助评审专家真正的发现问题,这实际上是典型的“形式上达到了模型的要求,但实际上却未获得价值”,这种现象如果持续久了,势必会降低大家做设计评审的积极性,难以使技术评审成为企业的文化,反而助长公司的形式主义。
于是根据我对OOD的理解,设计了如下的检查单,在此检查单中,所有的数字其实可以根据公司的实际情况进行调整,所有的检查项回答为否也并非代表一定存在问题,需要进行专家判断。这些检查项背后隐藏了OO设计的一些基本原则。
序号
|
检查项
|
1
|
所有的功能需求与非功能需求是否都体现在了设计中?
|
2
|
在设计中是否增加了不必要的功能?是否为未来的变更进行了过度设计?
|
3
|
类的属性是否超过了公共方法的个数的2倍?
|
4
|
类提供的公共方法是否超过了7个?
|
5
|
某个类的方法是否即执行了修改又执行了查询?
|
6
|
方法的参数是否超过了3个?
|
7
|
每个方法估计的规模是否超过了200行代码?
|
8
|
类依赖的对象是否超过了5个?
|
9
|
类继承层次是否超过了6层?
|
10
|
是否有的子类并非父类的特殊种类,而是父类的角色?
|
11
|
是否存在某个基类不是抽象类?
|
12
|
继承自非抽象类的关系是否合适?
|
13
|
是否存在某个接口,某些客户仅仅使用其部分方法?
|
14
|
是否需要在运行时刻判断对象的类型?
|
15
|
类的访问权限是否合适?
|
http://blog.csai.cn/user1/15522/archives/2008/21386.html