软件设计评审检查单

很多企业在做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	类的访问权限是否合适？